From ulf at alameda.net Thu May 1 00:35:38 2014 From: ulf at alameda.net (Ulf Zimmermann) Date: Wed, 30 Apr 2014 17:35:38 -0700 Subject: Dealing with auditors (was Re: We hit half-million: The Cidr Report) In-Reply-To: References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <536169C5.6060607@cox.net> Message-ID: The auditors VMware sent to us were just as bad. To ensure we weren't running "rogue" ESX(i) servers or WorkStation, they made us provide full arp/cam tables. Then a list of the virtual machines. "Oh look, this MAC isn't listed as one of your virtual machines". It isn't because it was running on virtual box or something like that. Auditor didn't know you could export a virtual machine from VMware and load it into another visualization software and it would keep the VMware MAC .... On Wed, Apr 30, 2014 at 2:31 PM, William Herrin wrote: > On Wed, Apr 30, 2014 at 5:23 PM, Larry Sheldon > wrote: > > On 4/30/2014 11:30 AM, Valdis.Kletnieks at vt.edu wrote: > >> And in that discussion, we ascertained that what the PCI standard > actually > >> says, and what you need to do in order to get unclued boneheaded > auditors > >> to sign the piece of paper, are two very different things. > > > > I am no longer active on the battlefield but as of the last time I was, > it > > can't be did. > > > > For years I managed various aspect of a UNIVAC 1100 operation and the > audits > > thereof. EVERY TIME, we were dinged badly because we didn't look like an > > IBM shop (some may be surprised to learn that different hardware and > > different operating systems require very different operating procedures > (and > > it appeared to us that some of the things they wanted us to do would > weaken > > us badly, others just simply didn't make any sense, and we got dinged for > > things we DID do, because they were strange. > > I won the argument with PCI auditors about leaving telnet alive on my > exterior router (which at the time would have had to be replaced to > support ssh). It's not a chore for the timid. You'd better be a heck > of a guru before you challenge the auditors expectations and you'd > better be prepared for your boss' aggravation that the audit isn't > done yet. > > And I think we pretty well established that PCI auditors arrive > expecting to see NAT. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-396-1764 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From dhubbard at dino.hostasaurus.com Thu May 1 00:58:25 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 30 Apr 2014 20:58:25 -0400 Subject: Dealing with auditors (was Re: We hit half-million: The Cidr Report) References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <536169C5.6060607@cox.net> Message-ID: We just dealt with a vmware audit too; it was a joke. In any case, the thing I found curious with their auditor as well as a PCI QSA (fancy auditor), is that neither entity seemed to know IPv6 exists. The whole time I'm thinking okay, now why aren't you investigating these same attack vectors in IPv6? Just another reason PCI is not necessarily about security.... David -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ulf Zimmermann Sent: Wednesday, April 30, 2014 8:36 PM To: William Herrin Cc: nanog at nanog.org Subject: Re: Dealing with auditors (was Re: We hit half-million: The Cidr Report) The auditors VMware sent to us were just as bad. To ensure we weren't running "rogue" ESX(i) servers or WorkStation, they made us provide full arp/cam tables. Then a list of the virtual machines. "Oh look, this MAC isn't listed as one of your virtual machines". It isn't because it was running on virtual box or something like that. Auditor didn't know you could export a virtual machine from VMware and load it into another visualization software and it would keep the VMware MAC .... On Wed, Apr 30, 2014 at 2:31 PM, William Herrin wrote: > On Wed, Apr 30, 2014 at 5:23 PM, Larry Sheldon > wrote: > > On 4/30/2014 11:30 AM, Valdis.Kletnieks at vt.edu wrote: > >> And in that discussion, we ascertained that what the PCI standard > actually > >> says, and what you need to do in order to get unclued boneheaded > auditors > >> to sign the piece of paper, are two very different things. > > > > I am no longer active on the battlefield but as of the last time I > > was, > it > > can't be did. > > > > For years I managed various aspect of a UNIVAC 1100 operation and > > the > audits > > thereof. EVERY TIME, we were dinged badly because we didn't look > > like an IBM shop (some may be surprised to learn that different > > hardware and different operating systems require very different > > operating procedures > (and > > it appeared to us that some of the things they wanted us to do would > weaken > > us badly, others just simply didn't make any sense, and we got > > dinged for things we DID do, because they were strange. > > I won the argument with PCI auditors about leaving telnet alive on my > exterior router (which at the time would have had to be replaced to > support ssh). It's not a chore for the timid. You'd better be a heck > of a guru before you challenge the auditors expectations and you'd > better be prepared for your boss' aggravation that the audit isn't > done yet. > > And I think we pretty well established that PCI auditors arrive > expecting to see NAT. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-396-1764 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From john at linx.net Thu May 1 09:01:22 2014 From: john at linx.net (John Souter) Date: Thu, 01 May 2014 10:01:22 +0100 Subject: We hit half-million: The Cidr Report In-Reply-To: <12495.1398875451@turing-police.cc.vt.edu> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <12495.1398875451@turing-police.cc.vt.edu> Message-ID: <53620D62.6090408@linx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/04/14 17:30, Valdis.Kletnieks at vt.edu wrote: > ... > Anybody got recommendations on how to make sure the company you engage > for the audit ends up sending you critters that actually have a clue? (Not > necessarily PCI, but in general) If more auditors (of whatever type) were put in the street when they annoy their customer or act irrationally, the world might become a better place. John - -- John Souter, CEO, London Internet Exchange Ltd Trinity Court, Trinity Street, Peterborough PE1 1DA. Registered 3137929 in England. Mobile: +44-7711-492389 https://www.linx.net/ "Working for the Internet" sip:john at linx.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlNiDWIACgkQbwHoykR44Oc6QQCfZd2+62OqHEM9Ua04IWAUmXMO c1sAn2A2vLYDknI0hqbti9lDZXUoi1v/ =2Bwf -----END PGP SIGNATURE----- From ahebert at pubnix.net Thu May 1 10:29:35 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 01 May 2014 06:29:35 -0400 Subject: Dealing with auditors (was Re: We hit half-million: The Cidr Report) In-Reply-To: References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <536169C5.6060607@cox.net> Message-ID: <5362220F.3080201@pubnix.net> Well, Right now, 1/2 my day$ are spend doing PCI auditing, technical side, not as a QSA. There is not shortage of horror stories about my customers previous QSA... Best one to date... Firewalling the FC SANs from the pool of VMWares servers. Bill & Telnet... I hope that QSA didn't let you keep that telnet facing any public interface without any protection. PS: Same deal with SSH ... encryption != protection since keylogging is way easier than sniffing packets. But at least you can limit SSH authentication to public keys. ----- 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 04/30/14 20:58, David Hubbard wrote: > We just dealt with a vmware audit too; it was a joke. In any case, the > thing I found curious with their auditor as well as a PCI QSA (fancy > auditor), is that neither entity seemed to know IPv6 exists. The whole > time I'm thinking okay, now why aren't you investigating these same > attack vectors in IPv6? Just another reason PCI is not necessarily > about security.... > > David > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ulf Zimmermann > Sent: Wednesday, April 30, 2014 8:36 PM > To: William Herrin > Cc: nanog at nanog.org > Subject: Re: Dealing with auditors (was Re: We hit half-million: The > Cidr Report) > > The auditors VMware sent to us were just as bad. To ensure we weren't > running "rogue" ESX(i) servers or WorkStation, they made us provide full > arp/cam tables. Then a list of the virtual machines. "Oh look, this MAC > isn't listed as one of your virtual machines". It isn't because it was > running on virtual box or something like that. Auditor didn't know you > could export a virtual machine from VMware and load it into another > visualization software and it would keep the VMware MAC .... > > > > On Wed, Apr 30, 2014 at 2:31 PM, William Herrin wrote: > >> On Wed, Apr 30, 2014 at 5:23 PM, Larry Sheldon >> wrote: >>> On 4/30/2014 11:30 AM, Valdis.Kletnieks at vt.edu wrote: >>>> And in that discussion, we ascertained that what the PCI standard >> actually >>>> says, and what you need to do in order to get unclued boneheaded >> auditors >>>> to sign the piece of paper, are two very different things. >>> I am no longer active on the battlefield but as of the last time I >>> was, >> it >>> can't be did. >>> >>> For years I managed various aspect of a UNIVAC 1100 operation and >>> the >> audits >>> thereof. EVERY TIME, we were dinged badly because we didn't look >>> like an IBM shop (some may be surprised to learn that different >>> hardware and different operating systems require very different >>> operating procedures >> (and >>> it appeared to us that some of the things they wanted us to do would >> weaken >>> us badly, others just simply didn't make any sense, and we got >>> dinged for things we DID do, because they were strange. >> I won the argument with PCI auditors about leaving telnet alive on my >> exterior router (which at the time would have had to be replaced to >> support ssh). It's not a chore for the timid. You'd better be a heck >> of a guru before you challenge the auditors expectations and you'd >> better be prepared for your boss' aggravation that the audit isn't >> done yet. >> >> And I think we pretty well established that PCI auditors arrive >> expecting to see NAT. >> >> Regards, >> Bill Herrin >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> > > From bill at herrin.us Thu May 1 15:52:07 2014 From: bill at herrin.us (William Herrin) Date: Thu, 1 May 2014 11:52:07 -0400 Subject: Dealing with auditors (was Re: We hit half-million: The Cidr Report) In-Reply-To: <5362220F.3080201@pubnix.net> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <536169C5.6060607@cox.net> <5362220F.3080201@pubnix.net> Message-ID: On Thu, May 1, 2014 at 6:29 AM, Alain Hebert wrote: > Bill & Telnet... > > I hope that QSA didn't let you keep that telnet facing any > public interface without any protection. Hi Alain, The point I made, successfully, was that it was outside the firewall hence out of scope for the audit. What I do in a different security domain from the one which handles the credit card transactions is none of their business. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tglassey at earthlink.net Thu May 1 16:04:57 2014 From: tglassey at earthlink.net (TGLASSEY) Date: Thu, 01 May 2014 09:04:57 -0700 Subject: Dealing with auditors (was Re: We hit half-million: The Cidr Report) In-Reply-To: References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <536169C5.6060607@cox.net> <5362220F.3080201@pubnix.net> Message-ID: <536270A9.6000004@earthlink.net> Bill - anything that puts another routable network alongside of the card processing info is in scope. The real; issue is that the PCI-SSC decided to formally create a policy to hold the auditors harmless in their actions and that is about to change. Todd On 5/1/2014 8:52 AM, William Herrin wrote: > On Thu, May 1, 2014 at 6:29 AM, Alain Hebert wrote: >> Bill & Telnet... >> >> I hope that QSA didn't let you keep that telnet facing any >> public interface without any protection. > Hi Alain, > > The point I made, successfully, was that it was outside the firewall > hence out of scope for the audit. What I do in a different security > domain from the one which handles the credit card transactions is none > of their business. > > Regards, > Bill Herrin > -- ------------- Personal Email - Disclaimers Apply From owen at delong.com Thu May 1 16:41:07 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 1 May 2014 09:41:07 -0700 Subject: We hit half-million: The Cidr Report In-Reply-To: <53620D62.6090408@linx.net> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <12495.1398875451@turing-police.cc.vt.edu> <53620D62.6090408@linx.net> Message-ID: <2A8E2710-B45E-4510-AD57-790A33DF5FE0@delong.com> On May 1, 2014, at 2:01 AM, John Souter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 30/04/14 17:30, Valdis.Kletnieks at vt.edu wrote: >> ... >> Anybody got recommendations on how to make sure the company you engage >> for the audit ends up sending you critters that actually have a clue? (Not >> necessarily PCI, but in general) > > If more auditors (of whatever type) were put in the street when they > annoy their customer or act irrationally, the world might become a > better place. The problem with this theory is that if auditors can be so easily put to the street, you run into the risk of auditors altering behavior to increase customer satisfaction in ways that prevent them from providing the controls that are the reason auditors exist in the first place. If you don’t believe me, examine the history of Arthur Anderson and their relationship with a certain Houston-based company which failed spectacularly. Owen From john at linx.net Thu May 1 18:07:32 2014 From: john at linx.net (John Souter) Date: Thu, 01 May 2014 19:07:32 +0100 Subject: We hit half-million: The Cidr Report In-Reply-To: <2A8E2710-B45E-4510-AD57-790A33DF5FE0@delong.com> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <12495.1398875451@turing-police.cc.vt.edu> <53620D62.6090408@linx.net> <2A8E2710-B45E-4510-AD57-790A33DF5FE0@delong.com> Message-ID: <53628D64.4010205@linx.net> On 01/05/14 17:41, Owen DeLong wrote: > The problem with this theory is that if auditors can be so easily put to the > street, you run into the risk of auditors altering behavior to increase customer > satisfaction in ways that prevent them from providing the controls that are the > reason auditors exist in the first place. I disagree. And the power balance is generally tilted way in favour of the auditors, as many people on this thread have already commented. In my experience, most companies are afraid/inhibited to raise issues or challenge their auditors in any way. Nobody is asking auditors to roll over, but if their behaviour is unprofessional/illogical, then a short sharp shock should do the trick. > If you don’t believe me, examine the history of Arthur Anderson and their > relationship with a certain Houston-based company which failed spectacularly. Can't really comment, but it was financial auditing, and ISTR that many things failed in that situation - not just financial auditing. John -- John Souter, CEO, London Internet Exchange Ltd Trinity Court, Trinity Street, Peterborough PE1 1DA. Registered 3137929 in England. Mobile: +44-7711-492389 https://www.linx.net/ "Working for the Internet" sip:john at linx.net From owen at delong.com Thu May 1 18:34:03 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 1 May 2014 11:34:03 -0700 Subject: We hit half-million: The Cidr Report In-Reply-To: <53628D64.4010205@linx.net> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <12495.1398875451@turing-police.cc.vt.edu> <53620D62.6090408@linx.net> <2A8E2710-B45E-4510-AD57-790A33DF5FE0@delong.com> <53628D64.4010205@linx.net> Message-ID: On May 1, 2014, at 11:07 AM, John Souter wrote: > On 01/05/14 17:41, Owen DeLong wrote: >> The problem with this theory is that if auditors can be so easily put to the >> street, you run into the risk of auditors altering behavior to increase customer >> satisfaction in ways that prevent them from providing the controls that are the >> reason auditors exist in the first place. > > I disagree. And the power balance is generally tilted way in favour of > the auditors, as many people on this thread have already commented. In > my experience, most companies are afraid/inhibited to raise issues or > challenge their auditors in any way. Nobody is asking auditors to roll > over, but if their behaviour is unprofessional/illogical, then a short > sharp shock should do the trick. I’m not saying that auditors shouldn’t be accountable or that people shouldn’t be able to do something about auditors that are being irrational/stupid. Believe me, I cringe every time I hear “our auditors require NAT as a security mechanism” since NAT is a minor hindrance to security at best. I realize you’re not asking auditors to roll over, but finding a balance point is tricky. >> If you don’t believe me, examine the history of Arthur Anderson and their >> relationship with a certain Houston-based company which failed spectacularly. > > Can't really comment, but it was financial auditing, and ISTR that many > things failed in that situation - not just financial auditing. Many things failed in that situation. MOST of them should have been caught and stopped by financial auditing. Yes, it was financial auditing, but I don’t really see the difference. When you turn “pleasing the customer” into a potential conflict with “accurate audit results”, you create a recipe for trouble. As much as I want auditors accountable for unprofessional/illogical conduct (which does not yield “accurate results” anyway), I consider it critical to avoid putting auditors in the “a happy customer is a good customer with a happy audit” mentality because that leads to very bad places. The right place is somewhere between these extremes, but defining that location is quite difficult. Owen From ahebert at pubnix.net Thu May 1 19:56:23 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 01 May 2014 15:56:23 -0400 Subject: We hit half-million: The Cidr Report In-Reply-To: <53628D64.4010205@linx.net> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <12495.1398875451@turing-police.cc.vt.edu> <53620D62.6090408@linx.net> <2A8E2710-B45E-4510-AD57-790A33DF5FE0@delong.com> <53628D64.4010205@linx.net> Message-ID: <5362A6E7.8090105@pubnix.net> Hey, I worked for them (AA) in the early 90's =D ----- 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 05/01/14 14:07, John Souter wrote: > On 01/05/14 17:41, Owen DeLong wrote: >> The problem with this theory is that if auditors can be so easily put to the >> street, you run into the risk of auditors altering behavior to increase customer >> satisfaction in ways that prevent them from providing the controls that are the >> reason auditors exist in the first place. > I disagree. And the power balance is generally tilted way in favour of > the auditors, as many people on this thread have already commented. In > my experience, most companies are afraid/inhibited to raise issues or > challenge their auditors in any way. Nobody is asking auditors to roll > over, but if their behaviour is unprofessional/illogical, then a short > sharp shock should do the trick. > >> If you don’t believe me, examine the history of Arthur Anderson and their >> relationship with a certain Houston-based company which failed spectacularly. > Can't really comment, but it was financial auditing, and ISTR that many > things failed in that situation - not just financial auditing. > > John From blair.trosper at gmail.com Thu May 1 20:55:52 2014 From: blair.trosper at gmail.com (Blair Trosper) Date: Thu, 1 May 2014 15:55:52 -0500 Subject: YouTube contact? (IPv6 streaming broken) Message-ID: Can someone from YouTube/Google give me a shout off list? The HTML5 player is getting a "204 No Content" error when it sends the stream request via IPv6...but works fine on IPv4. Confirmed from multiple locations in the US. From blair.trosper at gmail.com Thu May 1 21:16:14 2014 From: blair.trosper at gmail.com (Blair Trosper) Date: Thu, 1 May 2014 16:16:14 -0500 Subject: YouTube contact? (IPv6 streaming broken) In-Reply-To: References: Message-ID: Specifically: - 2001:4860:400b:c01::64 returns a 204 - 2607:f8b0:4002:10::8 is about 50/50 between a 204 and 200 On Thu, May 1, 2014 at 3:55 PM, Blair Trosper wrote: > Can someone from YouTube/Google give me a shout off list? The HTML5 > player is getting a "204 No Content" error when it sends the stream request > via IPv6...but works fine on IPv4. > > Confirmed from multiple locations in the US. > From rdrake at direcpath.com Thu May 1 22:00:45 2014 From: rdrake at direcpath.com (Robert Drake) Date: Thu, 1 May 2014 18:00:45 -0400 Subject: We hit half-million: The Cidr Report In-Reply-To: <53606603.1070004@utc.edu> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> Message-ID: <5362C40D.4080609@direcpath.com> On 4/29/2014 10:54 PM, Jeff Kell wrote: > Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / > etc had been eliminated by process of "can't get there from here"... we > expose millions more endpoints... > > /me ducks too (but you know *I* had to say it) > Slammer actually caused many firewalls to fall over due to high pps and having to track state. I thought about posting in the super-large anti-NAT/statefull firewall thread a few weeks ago but decided it wasn't worth it to stir up trouble. Here is some trivia though: Back when Slammer hit I was working for a major NSP. I had gotten late dinner with a friend and was at his work chatting with him since he worked the night shift by himself. It became apparent that something bad was wrong with the Internet. I decided to drive to my office and attempt to do what I could to fix the issues. This was a mistake. Because of corporate reasons, my office was in a different city from the POP I connected to. I was 3 hops away from our corporate firewall, one of which was a T1. We had access lists on all the routers preventing people from getting to them from the Internet, so I thought my office was the only place I could fix the issue. Well, someone had put a SQL server in front of or behind the firewall, somewhere where it would cause fun. That DOS'd the firewall. It took 3-4 hours of hacking things to get to the inside and outside routers and put an access-list blocking SQL. Once that was done the firewall instantly got better and I was able to push changes to every 7500 in the network blocking SQL on the uplink ports. This didn't stop it everywhere because we had 12000's in the core and they didn't support ACLs on most of the interfaces we had. The access lists had to stick around for at least 6 months while the Internet patched and cleaned things up. Fun fact: the office network I was using pre-dated RFC1918 so we were using public IPs. The software firewall that fell over either did so because statefull rules were included for SQL even when they weren't needed, or it died due to pure packets/sec. Regardless, all of the switching and routing hardware around it were fine. This isn't an argument against firewalls, I'm just saying that people tend to put stock in them even when they're just adding complexity. If you have access lists blocking everything the firewall would block then you might think having both gives you defense in depth, but what it also does is gives a second place where typos or human error might cause problems. It also gives a second point of failure and (if state synchronization and load-balance/failover are added) compounded complexity. It depends on the goals you're trying to achieve. Sometimes redundant duties performed by two different groups gives you piece of mind, sometimes it's just added frustration. From owen at delong.com Thu May 1 22:43:08 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 1 May 2014 15:43:08 -0700 Subject: We hit half-million: The Cidr Report In-Reply-To: <5362A6E7.8090105@pubnix.net> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <12495.1398875451@turing-police.cc.vt.edu> <53620D62.6090408@linx.net> <2A8E2710-B45E-4510-AD57-790A33DF5FE0@delong.com> <53628D64.4010205@linx.net> <5362A6E7.8090105@pubnix.net> Message-ID: Care to comment on how you feel about the COI that developed between AA Consulting business at Enron and AA auditing Enron? Not asking you to disclose anything confidential, but if you have wisdom to impart about any sort of generic lessons learned, etc. that might be relevant to this discussion, I think that could be useful. Owen On May 1, 2014, at 12:56 PM, Alain Hebert wrote: > Hey, > > I worked for them (AA) in the early 90's =D > > ----- > 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 05/01/14 14:07, John Souter wrote: >> On 01/05/14 17:41, Owen DeLong wrote: >>> The problem with this theory is that if auditors can be so easily put to the >>> street, you run into the risk of auditors altering behavior to increase customer >>> satisfaction in ways that prevent them from providing the controls that are the >>> reason auditors exist in the first place. >> I disagree. And the power balance is generally tilted way in favour of >> the auditors, as many people on this thread have already commented. In >> my experience, most companies are afraid/inhibited to raise issues or >> challenge their auditors in any way. Nobody is asking auditors to roll >> over, but if their behaviour is unprofessional/illogical, then a short >> sharp shock should do the trick. >> >>> If you don’t believe me, examine the history of Arthur Anderson and their >>> relationship with a certain Houston-based company which failed spectacularly. >> Can't really comment, but it was financial auditing, and ISTR that many >> things failed in that situation - not just financial auditing. >> >> John From jfmezei_nanog at vaxination.ca Thu May 1 23:10:08 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 01 May 2014 19:10:08 -0400 Subject: We hit half-million: The Cidr Report In-Reply-To: References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <12495.1398875451@turing-police.cc.vt.edu> <53620D62.6090408@linx.net> <2A8E2710-B45E-4510-AD57-790A33DF5FE0@delong.com> <53628D64.4010205@linx.net> Message-ID: <5362D450.4050205@vaxination.ca> On 14-05-01 14:34, Owen DeLong wrote: > Believe me, I cringe every time I hear “our auditors require NAT as a security mechanism” Pardon my ignorance here. But in a carrier-grade NAT implementation that serves say 5000 users, when happens when someone from the outside tries to connect to port 80 of the shared routable IP ? you still need to have explicit port forwarding to specific LAN side hosts (like the web server) right ? Trying to be devil's advocate here: (and discussing only incoming calls) In a NAT setup for a company, wouldn't the concept be that you explicitely have to open a few ports to specific hosts ? (for instance 80 points to the web server LAN IP address) All the rest of the gazillion ports are blocked by default since the router doesn't know to which LAN host they should go. On the other hand, for a LAN with routable IPs, by default, all ports are routed to all computers, and security then depends on ACLs or other mechanisms to implement a firewall. Auditors probably prefer architecture where everything is blocked by default and you open specific ports compared to one where everything is open by default and you then add ACLs to implement security. (Not judging whether one is better, just trying to figure out why auditors might prefer NAT). Also, home routers have "NAT" which is really a combo of NAT with basic firewall, so if you don't have "NAT", they may equate this to not having a firewall. From rdrake at direcpath.com Thu May 1 23:46:05 2014 From: rdrake at direcpath.com (Robert Drake) Date: Thu, 1 May 2014 19:46:05 -0400 Subject: We hit half-million: The Cidr Report In-Reply-To: <5362D450.4050205@vaxination.ca> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <12495.1398875451@turing-police.cc.vt.edu> <53620D62.6090408@linx.net> <2A8E2710-B45E-4510-AD57-790A33DF5FE0@delong.com> <53628D64.4010205@linx.net> <5362D450.4050205@vaxination.ca> Message-ID: <5362DCBD.1030109@direcpath.com> On 5/1/2014 7:10 PM, Jean-Francois Mezei wrote: > > Pardon my ignorance here. But in a carrier-grade NAT implementation that > serves say 5000 users, when happens when someone from the outside tries > to connect to port 80 of the shared routable IP ? you still need to > have explicit port forwarding to specific LAN side hosts (like the web > server) right ? > > Trying to be devil's advocate here: (and discussing only incoming calls) That's the problem with your devil. The first outgoing connection negates every protection you've assumed with one-to-many NAT. What you really need is a policy that says explicitly what traffic is permitted in each direction. established/new outbound is the problem in this scenario, not what internal addresses you use. On a secure server LAN, the ideal configuration for outbound would only allow connections to update servers you control, and acknowledgement traffic for protocols you are allowing inbound. > In a NAT setup for a company, wouldn't the concept be that you > explicitely have to open a few ports to specific hosts ? (for instance > 80 points to the web server LAN IP address) All the rest of the > gazillion ports are blocked by default since the router doesn't know to > which LAN host they should go. > > On the other hand, for a LAN with routable IPs, by default, all ports > are routed to all computers, and security then depends on ACLs or other > mechanisms to implement a firewall. > > Auditors probably prefer architecture where everything is blocked by > default and you open specific ports compared to one where everything is > open by default and you then add ACLs to implement security. Blocked by default or allowed by default are just concepts on a firewall. People make the mistake of thinking that allowed by default is the default, but that's only true of the underlying host OS, and only if that host OS isn't hardened. Specifically, ip forwarding shouldn't be turned on until needed. Linux doesn't turn this on by default, so by default you don't permit routing no matter the source or destination IP addresses. The mistake that everyone is making is they think with NAT, secure rules are easier to write so getting the firewall online for the first time is easier, and maintaining it is easier. The problem with this statement is it's only true to a certain extent. If you care about whatever you're securing at a PCI/SOX level then NAT bought you nothing. You still need to write secure inbound and outbound rules. If whatever you're securing doesn't have to be that tightly controlled then NAT buys you a little, but it comes with a glaring false sense of security. I know at my office the IT department has dealt with several worm outbreaks that spread through email and then use the local LAN to send outbound port 25. I had to block port 25 outbound for the corporate network when it became apparent that IT was using "NAT is a firewall" as their security methodology. > (Not judging whether one is better, just trying to figure out why > auditors might prefer NAT). > > Also, home routers have "NAT" which is really a combo of NAT with basic > firewall, so if you don't have "NAT", they may equate this to not having > a firewall. > Auditors prefer NAT because everyone in the world understands security and computers on different levels. You don't know if you're getting an auditor that writes their own pen-test suites or just runs nessus and prints the results. They may have been trained by someone who developed the "intuitive" logical understanding that NAT systems fail-closed so they're better for defense in depth. The problem with this is, as stated above, it's not buying enough to be worth it and it causes a false sense of security. They may have even reached this conclusion themselves and it's hard to convince someone their ideas are wrong. Honestly they aren't even wrong, they're just picking a battle that shouldn't mean as much as they think it does. Ideally, your security group should have unit-tests or just a network monitoring process that nmaps from both directions. On inbound there are PCI compliance auditors that will do this for you regularly so that you can be assured the protection is still there. Outbound you need to be just as vigilant to make sure the rules are just as strict. Ultimately, things like CGNAT are completely ineffective for security because the outbound rules have to be wide open so people can use it. From fred at cisco.com Thu May 1 23:57:06 2014 From: fred at cisco.com (Fred Baker (fred)) Date: Thu, 1 May 2014 23:57:06 +0000 Subject: We hit half-million: The Cidr Report In-Reply-To: <5362D450.4050205@vaxination.ca> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <12495.1398875451@turing-police.cc.vt.edu> <53620D62.6090408@linx.net> <2A8E2710-B45E-4510-AD57-790A33DF5FE0@delong.com> <53628D64.4010205@linx.net> <5362D450.4050205@vaxination.ca> Message-ID: <3F9B9ED2-C78D-4073-9DC1-F494CE1B92B6@cisco.com> On May 1, 2014, at 4:10 PM, Jean-Francois Mezei wrote: > Pardon my ignorance here. But in a carrier-grade NAT implementation that > serves say 5000 users, when happens when someone from the outside tries > to connect to port 80 of the shared routable IP ? More to the point, your trust boundary includes 5000 people. Do you know them all? Who maintains their systems and software? Do you trust them? What happens if they approach you from behind the NAT? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Message signed with OpenPGP using GPGMail URL: From blakjak at blakjak.net Fri May 2 00:06:36 2014 From: blakjak at blakjak.net (Mark Foster) Date: Fri, 2 May 2014 12:06:36 +1200 Subject: We hit half-million: The Cidr Report In-Reply-To: <3F9B9ED2-C78D-4073-9DC1-F494CE1B92B6@cisco.com> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <12495.1398875451@turing-police.cc.vt.edu> <53620D62.6090408@linx.net> <2A8E2710-B45E-4510-AD57-790A33DF5FE0@delong.com> <53628D64.4010205@linx.net> <5362D450.4050205@vaxination.ca> <3F9B9ED2-C78D-4073-9DC1-F494CE1B92B6@cisco.com> Message-ID: <425b6cb08b3bb94e35d633a31229a496.squirrel@secure.blakjak.net> On Fri, May 2, 2014 11:57 am, Fred Baker (fred) wrote: > > On May 1, 2014, at 4:10 PM, Jean-Francois Mezei > wrote: > >> Pardon my ignorance here. But in a carrier-grade NAT implementation that >> serves say 5000 users, when happens when someone from the outside tries >> to connect to port 80 of the shared routable IP ? > > More to the point, your trust boundary includes 5000 people. Do you know > them all? Who maintains their systems and software? Do you trust them? > > What happens if they approach you from behind the NAT? > Strikes me as a red herring; CGNat is not shifting your security boundary, wheras the typical NAT device used on a shared IPv4 connection usually does. From owen at delong.com Fri May 2 04:01:52 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 1 May 2014 21:01:52 -0700 Subject: We hit half-million: The Cidr Report In-Reply-To: <3F9B9ED2-C78D-4073-9DC1-F494CE1B92B6@cisco.com> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <12495.1398875451@turing-police.cc.vt.edu> <53620D62.6090408@linx.net> <2A8E2710-B45E-4510-AD57-790A33DF5FE0@delong.com> <53628D64.4010205@linx.net> <5362D450.4050205@vaxination.ca> <3F9B9ED2-C78D-4073-9DC1-F494CE1B92B6@cisco.com> Message-ID: On May 1, 2014, at 4:57 PM, Fred Baker (fred) wrote: > > On May 1, 2014, at 4:10 PM, Jean-Francois Mezei wrote: > >> Pardon my ignorance here. But in a carrier-grade NAT implementation that >> serves say 5000 users, when happens when someone from the outside tries >> to connect to port 80 of the shared routable IP ? > > More to the point, your trust boundary includes 5000 people. Do you know them all? Who maintains their systems and software? Do you trust them? > > What happens if they approach you from behind the NAT? It’s unlikely that CGN changes this at all… Most CGN deployments will be a second layer of horror on top of the existing horrors already present. Owen From ahebert at pubnix.net Fri May 2 10:47:46 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 02 May 2014 06:47:46 -0400 Subject: We hit half-million: The Cidr Report In-Reply-To: References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <12495.1398875451@turing-police.cc.vt.edu> <53620D62.6090408@linx.net> <2A8E2710-B45E-4510-AD57-790A33DF5FE0@delong.com> <53628D64.4010205@linx.net> <5362A6E7.8090105@pubnix.net> Message-ID: <536377D2.3000903@pubnix.net> Well, I was just a suit drone into one of their 100 little IT firm around the world. The nearest I got to an actual AA associate was during a 1 month project in Chicago (: Wasted my time really... They billed 3 months to their clients, for a project that took 1 month, and I was asked to fill the cubicle for 2 month doing nothing. ----- 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 05/01/14 18:43, Owen DeLong wrote: > Care to comment on how you feel about the COI that developed between AA Consulting business at Enron and AA auditing Enron? > > Not asking you to disclose anything confidential, but if you have wisdom to impart about any sort of generic lessons learned, etc. that might be relevant to this discussion, I think that could be useful. > > Owen > > On May 1, 2014, at 12:56 PM, Alain Hebert wrote: > >> Hey, >> >> I worked for them (AA) in the early 90's =D >> >> ----- >> 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 05/01/14 14:07, John Souter wrote: >>> On 01/05/14 17:41, Owen DeLong wrote: >>>> The problem with this theory is that if auditors can be so easily put to the >>>> street, you run into the risk of auditors altering behavior to increase customer >>>> satisfaction in ways that prevent them from providing the controls that are the >>>> reason auditors exist in the first place. >>> I disagree. And the power balance is generally tilted way in favour of >>> the auditors, as many people on this thread have already commented. In >>> my experience, most companies are afraid/inhibited to raise issues or >>> challenge their auditors in any way. Nobody is asking auditors to roll >>> over, but if their behaviour is unprofessional/illogical, then a short >>> sharp shock should do the trick. >>> >>>> If you don’t believe me, examine the history of Arthur Anderson and their >>>> relationship with a certain Houston-based company which failed spectacularly. >>> Can't really comment, but it was financial auditing, and ISTR that many >>> things failed in that situation - not just financial auditing. >>> >>> John > From mgalgoci at redhat.com Fri May 2 14:36:11 2014 From: mgalgoci at redhat.com (Matthew Galgoci) Date: Fri, 2 May 2014 14:36:11 +0000 (UTC) Subject: oss netflow collector/trending/analysis Message-ID: Hey There, I was just wondering, for people who are doing netflow analysis with open source tools and who are doing at least 10k or more flows per second, what are you using? I know of three tool sets: - The classic osu flow-tools and the modern continuation/fork. - ntop - nfdump/nfsen Is there anything else I've missed? A few folks here really seem to like nfsen/nfdump. Thanks, Matt -- Matthew Galgoci Network Operations Red Hat, Inc 919.754.3700 x44155 ------------------------------ “Whatever you do will be insignificant, but it is very important that you do it.” -- Mahatma Gandhi From rdobbins at arbor.net Fri May 2 14:40:57 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 2 May 2014 14:40:57 +0000 Subject: oss netflow collector/trending/analysis In-Reply-To: References: Message-ID: <728748C4-6B96-463A-BF89-FDE06D5402B4@arbor.net> On May 2, 2014, at 9:36 PM, Matthew Galgoci wrote: > A few folks here really seem to like > nfsen/nfdump. The good thing about nfdump/nfsen is that you can customize it and do a lot with it, and it's easy to get set up and running. This is the canonical list of open-source NetFlow tools: ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From jeroen at massar.ch Fri May 2 14:44:01 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Fri, 02 May 2014 16:44:01 +0200 Subject: oss netflow collector/trending/analysis In-Reply-To: References: Message-ID: <5363AF31.6020405@massar.ch> On 2014-05-02 16:36, Matthew Galgoci wrote: [..] > Is there anything else I've missed? A few folks here really seem to like > nfsen/nfdump. For OSS that is pretty much it that really matters (maybe you could add Argus if you really want though). For a long long list, check out Simon Leinen's site: https://www.switch.ch/network/projects/completed/TF-NGN/floma/software.html Not all of that is OSS though. Lots of these netflow-analyzer tools are in-house / a bunch-of-scripts-upon-scripts that are to scary to let out in the open and/or do not scale... IMHO your best bet is to use nfsen/nfdump as that is the best thing publicly available. Greets, Jeroen From freedman at freedman.net Fri May 2 15:00:15 2014 From: freedman at freedman.net (Avi Freedman) Date: Fri, 2 May 2014 11:00:15 -0400 (EDT) Subject: oss netflow collector/trending/analysis Message-ID: <20140502150015.5950B55000087@freedman.net> There's also SiLK from CMU. It's powerful but has a learning curve. I also see pmacct being used both by some end networks and by some vendors as part of systems. Avi > Hey There, > > I was just wondering, for people who are doing netflow analysis with > open source tools and who are doing at least 10k or more flows per > second, what are you using? > > I know of three tool sets: > > - The classic osu flow-tools and the modern continuation/fork. > - ntop > - nfdump/nfsen > > Is there anything else I've missed? A few folks here really seem to like > nfsen/nfdump. > > Thanks, > > Matt From geekgirl at gmail.com Fri May 2 16:21:40 2014 From: geekgirl at gmail.com (Leslie) Date: Fri, 2 May 2014 09:21:40 -0700 Subject: oss netflow collector/trending/analysis In-Reply-To: <20140502150015.5950B55000087@freedman.net> References: <20140502150015.5950B55000087@freedman.net> Message-ID: pmacct (http://www.pmacct.net/) is another pretty awesome open source tool. Leslie On Fri, May 2, 2014 at 8:00 AM, Avi Freedman wrote: > > There's also SiLK from CMU. It's powerful but has a learning curve. > > I also see pmacct being used both by some end networks and by > some vendors as part of systems. > > Avi > >> Hey There, >> >> I was just wondering, for people who are doing netflow analysis with >> open source tools and who are doing at least 10k or more flows per >> second, what are you using? >> >> I know of three tool sets: >> >> - The classic osu flow-tools and the modern continuation/fork. >> - ntop >> - nfdump/nfsen >> >> Is there anything else I've missed? A few folks here really seem to like >> nfsen/nfdump. >> >> Thanks, >> >> Matt > From jloiacon at csc.com Fri May 2 16:37:52 2014 From: jloiacon at csc.com (Joe Loiacono) Date: Fri, 2 May 2014 12:37:52 -0400 Subject: oss netflow collector/trending/analysis In-Reply-To: <20140502150015.5950B55000087@freedman.net> References: <20140502150015.5950B55000087@freedman.net> Message-ID: "NANOG" wrote on 05/02/2014 11:00:15 AM: > From: freedman at freedman.net (Avi Freedman) > > There's also SiLK from CMU. It's powerful but has a learning curve. > SiLK is very good. See FlowViewer for a powerful front-end to the tool. http://sourceforge.net/projects/flowviewer/ Also supports flow-tools. Joe From cscora at apnic.net Fri May 2 18:12:23 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 3 May 2014 04:12:23 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201405021812.s42ICN4f007807@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 03 May, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 493507 Prefixes after maximum aggregation: 193714 Deaggregation factor: 2.55 Unique aggregates announced to Internet: 244007 Total ASes present in the Internet Routing Table: 46734 Prefixes per ASN: 10.56 Origin-only ASes present in the Internet Routing Table: 35795 Origin ASes announcing only one prefix: 16388 Transit ASes present in the Internet Routing Table: 6056 Transit-only ASes present in the Internet Routing Table: 170 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: 1837 Unregistered ASNs in the Routing Table: 459 Number of 32-bit ASNs allocated by the RIRs: 6508 Number of 32-bit ASNs visible in the Routing Table: 4883 Prefixes from 32-bit ASNs in the Routing Table: 16259 Number of bogon 32-bit ASNs visible in the Routing Table: 133 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 441 Number of addresses announced to Internet: 2678216965 Equivalent to 159 /8s, 162 /16s and 89 /24s Percentage of available address space announced: 72.3 Percentage of allocated address space announced: 72.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.3 Total number of prefixes smaller than registry allocations: 171214 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 117313 Total APNIC prefixes after maximum aggregation: 34942 APNIC Deaggregation factor: 3.36 Prefixes being announced from the APNIC address blocks: 120226 Unique aggregates announced from the APNIC address blocks: 50108 APNIC Region origin ASes present in the Internet Routing Table: 4923 APNIC Prefixes per ASN: 24.42 APNIC Region origin ASes announcing only one prefix: 1231 APNIC Region transit ASes present in the Internet Routing Table: 860 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 30 Number of APNIC region 32-bit ASNs visible in the Routing Table: 931 Number of APNIC addresses announced to Internet: 732419201 Equivalent to 43 /8s, 167 /16s and 212 /24s Percentage of available APNIC address space announced: 85.6 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: 168115 Total ARIN prefixes after maximum aggregation: 83465 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 169561 Unique aggregates announced from the ARIN address blocks: 79577 ARIN Region origin ASes present in the Internet Routing Table: 16243 ARIN Prefixes per ASN: 10.44 ARIN Region origin ASes announcing only one prefix: 6118 ARIN Region transit ASes present in the Internet Routing Table: 1663 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 96 Number of ARIN addresses announced to Internet: 1074634880 Equivalent to 64 /8s, 13 /16s and 160 /24s Percentage of available ARIN address space announced: 56.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 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: 123413 Total RIPE prefixes after maximum aggregation: 62512 RIPE Deaggregation factor: 1.97 Prefixes being announced from the RIPE address blocks: 127972 Unique aggregates announced from the RIPE address blocks: 80777 RIPE Region origin ASes present in the Internet Routing Table: 17675 RIPE Prefixes per ASN: 7.24 RIPE Region origin ASes announcing only one prefix: 8280 RIPE Region transit ASes present in the Internet Routing Table: 2868 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: 2698 Number of RIPE addresses announced to Internet: 657606020 Equivalent to 39 /8s, 50 /16s and 69 /24s Percentage of available RIPE address space announced: 95.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 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: 56426 Total LACNIC prefixes after maximum aggregation: 10071 LACNIC Deaggregation factor: 5.60 Prefixes being announced from the LACNIC address blocks: 62759 Unique aggregates announced from the LACNIC address blocks: 28862 LACNIC Region origin ASes present in the Internet Routing Table: 2095 LACNIC Prefixes per ASN: 29.96 LACNIC Region origin ASes announcing only one prefix: 550 LACNIC Region transit ASes present in the Internet Routing Table: 430 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 34 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1133 Number of LACNIC addresses announced to Internet: 159008128 Equivalent to 9 /8s, 122 /16s and 69 /24s Percentage of available LACNIC address space announced: 94.8 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: 11875 Total AfriNIC prefixes after maximum aggregation: 2687 AfriNIC Deaggregation factor: 4.42 Prefixes being announced from the AfriNIC address blocks: 12548 Unique aggregates announced from the AfriNIC address blocks: 4311 AfriNIC Region origin ASes present in the Internet Routing Table: 720 AfriNIC Prefixes per ASN: 17.43 AfriNIC Region origin ASes announcing only one prefix: 209 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: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 25 Number of AfriNIC addresses announced to Internet: 54232064 Equivalent to 3 /8s, 59 /16s and 132 /24s Percentage of available AfriNIC address space announced: 53.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 2947 11591 922 Korea Telecom 17974 2798 903 78 PT Telekomunikasi Indonesia 7545 2219 320 117 TPG Telecom Limited 4755 1852 396 198 TATA Communications formerly 9829 1622 1288 35 National Internet Backbone 9583 1327 103 546 Sify Limited 9498 1257 314 84 BHARTI Airtel Ltd. 7552 1219 1082 13 Viettel Corporation 4808 1210 2151 355 CNCGROUP IP network China169 24560 1126 385 175 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 2971 3688 53 BellSouth.net Inc. 22773 2417 2937 134 Cox Communications Inc. 1785 2201 700 135 PaeTec Communications, Inc. 18566 2047 379 178 MegaPath Corporation 20115 1706 1690 561 Charter Communications 4323 1628 1073 408 tw telecom holdings, inc. 701 1481 11158 750 MCI Communications Services, 30036 1400 302 546 Mediacom Communications Corp 6983 1327 800 307 ITC^Deltacom 22561 1302 402 232 CenturyTel Internet Holdings, 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 34984 1709 264 271 TELLCOM ILETISIM HIZMETLERI A 8402 1520 544 16 OJSC "Vimpelcom" 20940 1302 497 978 Akamai International B.V. 13188 1049 100 28 TOV "Bank-Inform" 31148 1018 45 19 Freenet Ltd. 8551 918 370 40 Bezeq International-Ltd 6849 825 357 28 JSC "Ukrtelecom" 6830 766 2333 427 Liberty Global Operations B.V 12479 720 797 56 France Telecom Espana SA 9198 574 344 25 JSC Kazakhtelecom 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 3739 1957 99 NET Servi�os de Comunica��o S 10620 2850 461 202 Telmex Colombia S.A. 18881 1967 972 21 Global Village Telecom 7303 1753 1174 228 Telecom Argentina S.A. 8151 1400 2930 405 Uninet S.A. de C.V. 6503 1111 434 60 Axtel, S.A.B. de C.V. 7738 914 1754 40 Telemar Norte Leste S.A. 27947 867 114 52 Telconet S.A 11830 842 364 15 Instituto Costarricense de El 26615 842 2325 35 Tim Celular S.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 1114 240 6 Sudanese Mobile Telephone (ZA 24863 961 280 26 Link Egypt (Link.NET) 6713 614 722 28 Office National des Postes et 8452 578 958 13 TE-AS 24835 304 144 9 Vodafone Data 36992 275 783 24 ETISALAT MISR 3741 248 921 209 Internet Solutions 29571 228 22 23 Cote d'Ivoire Telecom 37054 216 19 6 Data Telecom Service 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 3739 1957 99 NET Servi�os de Comunica��o S 6389 2971 3688 53 BellSouth.net Inc. 4766 2947 11591 922 Korea Telecom 10620 2850 461 202 Telmex Colombia S.A. 17974 2798 903 78 PT Telekomunikasi Indonesia 22773 2417 2937 134 Cox Communications Inc. 7545 2219 320 117 TPG Telecom Limited 1785 2201 700 135 PaeTec Communications, Inc. 18566 2047 379 178 MegaPath Corporation 18881 1967 972 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 2971 2918 BellSouth.net Inc. 17974 2798 2720 PT Telekomunikasi Indonesia 10620 2850 2648 Telmex Colombia S.A. 22773 2417 2283 Cox Communications Inc. 7545 2219 2102 TPG Telecom Limited 1785 2201 2066 PaeTec Communications, Inc. 4766 2947 2025 Korea Telecom 18881 1967 1946 Global Village Telecom 18566 2047 1869 MegaPath Corporation 4755 1852 1654 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 5.109.32.0/19 23456 32bit Transition AS 65456 PRIVATE 5.109.96.0/19 23456 32bit Transition AS 30662 UNALLOCATED 8.2.129.0/24 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 22511 UNALLOCATED 8.28.225.0/24 2828 XO Communications 22511 UNALLOCATED 8.36.68.0/24 2828 XO Communications Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.14.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 41.73.16.0/24 37004 >>UNKNOWN<< 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:12 /10:31 /11:90 /12:257 /13:481 /14:964 /15:1697 /16:12960 /17:6813 /18:11593 /19:24278 /20:34188 /21:36791 /22:52944 /23:46162 /24:262047 /25:785 /26:932 /27:395 /28:13 /29:15 /30:5 /31:0 /32:38 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2002 2047 MegaPath Corporation 6389 1692 2971 BellSouth.net Inc. 22773 1660 2417 Cox Communications Inc. 30036 1238 1400 Mediacom Communications Corp 8402 1197 1520 OJSC "Vimpelcom" 11492 1197 1240 CABLE ONE, INC. 1785 1165 2201 PaeTec Communications, Inc. 36998 1080 1114 Sudanese Mobile Telephone (ZA 6983 1043 1327 ITC^Deltacom 34984 1038 1709 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1028 2:680 3:3 4:15 5:983 6:19 8:736 12:1848 13:4 14:987 15:13 16:2 17:31 18:21 20:36 23:854 24:1735 25:1 27:1779 31:1477 32:40 33:2 34:5 36:131 37:1879 38:955 39:6 40:196 41:3181 42:247 44:10 46:2174 47:18 49:696 50:917 52:12 54:47 55:7 57:28 58:1229 59:601 60:403 61:1547 62:1234 63:1959 64:4378 65:2288 66:4147 67:2063 68:1035 69:3307 70:856 71:445 72:2011 74:2657 75:311 76:418 77:1529 78:935 79:711 80:1298 81:1165 82:743 83:756 84:728 85:1259 86:470 87:1172 88:482 89:1801 90:140 91:5703 92:694 93:1712 94:2042 95:1467 96:544 97:349 98:1075 99:48 100:54 101:789 103:4752 105:536 106:173 107:606 108:579 109:2049 110:968 111:1293 112:657 113:847 114:902 115:1119 116:1061 117:925 118:1393 119:1345 120:377 121:806 122:2041 123:1326 124:1414 125:1401 128:649 129:313 130:345 131:660 132:399 133:162 134:323 135:74 136:256 137:324 138:352 139:170 140:213 141:367 142:579 143:439 144:507 145:100 146:603 147:452 148:924 149:346 150:167 151:634 152:423 153:218 154:273 155:482 156:336 157:337 158:241 159:896 160:332 161:532 162:1367 163:218 164:688 165:598 166:278 167:610 168:1030 169:124 170:1393 171:191 172:22 173:1634 174:701 175:608 176:1415 177:2869 178:1961 179:612 180:1715 181:1132 182:1556 183:511 184:713 185:1569 186:2748 187:1533 188:1921 189:1470 190:7530 191:245 192:7250 193:5497 194:4039 195:3484 196:1398 197:640 198:5034 199:5581 200:6248 201:2703 202:9020 203:8885 204:4630 205:2709 206:2950 207:2945 208:3986 209:3718 210:3102 211:1678 212:2254 213:2068 214:921 215:86 216:5518 217:1685 218:575 219:318 220:1280 221:595 222:353 223:579 End of report From deepak at ai.net Fri May 2 19:44:33 2014 From: deepak at ai.net (Deepak Jain) Date: Fri, 2 May 2014 19:44:33 +0000 Subject: Best practices IPv4/IPv6 BGP (dual stack) Message-ID: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session? According to docs, obviously all of these are supported and if both sides are dual stacked, even the next-hops don't need to be overwritten. Is there any community-approach to best practices here? Any FIB weirdness (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc) that results with one solution over the other? Thanks in advance, DJ From jared at puck.nether.net Fri May 2 19:47:24 2014 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 2 May 2014 15:47:24 -0400 Subject: Best practices IPv4/IPv6 BGP (dual stack) In-Reply-To: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> References: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> Message-ID: <1F639726-BDE2-42A6-A848-60C2FC3D0AD5@puck.nether.net> On May 2, 2014, at 3:44 PM, Deepak Jain wrote: > > Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session? We use v4 transport for v4 routes and v6 transport for v6 routes only. This way if one plane is unstable the other is unaffected. - Jared From laszlo at heliacal.net Fri May 2 19:52:24 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Fri, 2 May 2014 19:52:24 +0000 Subject: Best practices IPv4/IPv6 BGP (dual stack) In-Reply-To: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> References: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> Message-ID: Two different sessions using two different transport protocols. The v4 BGP session should have address family v6 disabled and vice versa. Exchange v4 routes over a v4 TCP connection, exchange v6 routes over a v6 TCP connection. Just treat them as independent protocols. -Laszlo On May 2, 2014, at 7:44 PM, Deepak Jain wrote: > > Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session? > > According to docs, obviously all of these are supported and if both sides are dual stacked, even the next-hops don't need to be overwritten. > > Is there any community-approach to best practices here? Any FIB weirdness (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc) that results with one solution over the other? > > Thanks in advance, > > DJ From ryan at deadfrog.net Fri May 2 20:21:09 2014 From: ryan at deadfrog.net (Ryan Wilkins) Date: Fri, 2 May 2014 16:21:09 -0400 Subject: Best practices IPv4/IPv6 BGP (dual stack) In-Reply-To: References: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> Message-ID: > > Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session? > > According to docs, obviously all of these are supported and if both sides are dual stacked, even the next-hops don't need to be overwritten. > > Is there any community-approach to best practices here? Any FIB weirdness (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc) that results with one solution over the other? > > Thanks in advance, > > DJ For what it’s worth, my AboveNet and Cogent BGP peerings are v4 for v4 routes and v6 for v6 routes. Two separate sessions to each carrier. While I don’t have any BGP speaking IPv6 customers yet, I would set up this same way to keep the two protocols apart from each other. Best, Ryan Wilkins From mansaxel at besserwisser.org Fri May 2 20:35:00 2014 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Fri, 2 May 2014 22:35:00 +0200 Subject: Best practices IPv4/IPv6 BGP (dual stack) In-Reply-To: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> References: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> Message-ID: <20140502203459.GQ13966@besserwisser.org> Subject: Best practices IPv4/IPv6 BGP (dual stack) Date: Fri, May 02, 2014 at 07:44:33PM +0000 Quoting Deepak Jain (deepak at ai.net): > > Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session? Like others, yes, two sessions, v6 over v6 and v4 over v4. only the native AF is active. > According to docs, obviously all of these are supported and if both sides are dual stacked, even the next-hops don't need to be overwritten. It works, but might produce interesting side effects. I've had to resort to it when peering between different IOS versions; but that might have been the result of fat-fingering as well. > Is there any community-approach to best practices here? Any FIB weirdness (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc) that results with one solution over the other? If having MPLS bgp peers over v6 carrying vpnv4 routes all sorts of strange things can happen. There is no standard for it; so one should not expect it to work. But the failure modes are "interesting"; I've had the next-hop for a v6-carried vpnv4 peering be the first 32 bits of the v6 next-hop, interpreted as a v4 address.. It only works if there is a v4 route to that made-up address. This is a field where v4 next-hops are essential to make things work. In that context, allocating 100.64.0.0/10 to CGN was especially un-clever... -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Xerox your lunch and file it under "sex offenders"! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From cgrundemann at gmail.com Fri May 2 21:58:42 2014 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 2 May 2014 15:58:42 -0600 Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)] Message-ID: Hi Mans, On Fri, May 2, 2014 at 2:35 PM, Måns Nilsson wrote: > This is a field where v4 next-hops are essential to make things > work. In that context, allocating 100.64.0.0/10 to CGN was > especially un-clever... > Would you expound a bit on what you mean here? I don't quite follow but I am very interested to understand the issue. Thanks! ~Chris -- @ChrisGrundemann http://chrisgrundemann.com From cidr-report at potaroo.net Fri May 2 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 May 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201405022200.s42M00Rg023698@wattle.apnic.net> This report has been generated at Fri May 2 21:13:55 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 25-04-14 500177 282897 26-04-14 500200 282955 27-04-14 500300 283004 28-04-14 500709 283246 29-04-14 501078 282694 30-04-14 501121 282538 01-05-14 500741 282901 02-05-14 500388 283120 AS Summary 46968 Number of ASes in routing system 19152 Number of ASes announcing only one prefix 3690 Largest number of prefixes announced by an AS AS28573: NET Servi�os de Comunica��o S.A.,BR 119976960 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 02May14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 500620 283088 217532 43.5% All ASes AS28573 3690 174 3516 95.3% NET Servi�os de Comunica��o S.A.,BR AS6389 2970 56 2914 98.1% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2800 252 2548 91.0% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS4766 2947 931 2016 68.4% KIXS-AS-KR Korea Telecom,KR AS18881 1967 37 1930 98.1% Global Village Telecom,BR AS1785 2201 494 1707 77.6% AS-PAETEC-NET - PaeTec Communications, Inc.,US AS10620 2850 1352 1498 52.6% Telmex Colombia S.A.,CO AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation,US AS4323 2934 1512 1422 48.5% TWTC - tw telecom holdings, inc.,US AS7303 1758 457 1301 74.0% Telecom Argentina S.A.,AR AS4755 1852 582 1270 68.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS7545 2232 1070 1162 52.1% TPG-INTERNET-AP TPG Telecom Limited,AU AS7552 1243 142 1101 88.6% VIETEL-AS-AP Viettel Corporation,VN AS22561 1302 241 1061 81.5% AS22561 - CenturyTel Internet Holdings, Inc.,US AS6983 1327 314 1013 76.3% ITCDELTA - Earthlink, Inc.,US AS36998 1114 161 953 85.5% SDN-MOBITEL,SD AS9829 1622 726 896 55.2% BSNL-NIB National Internet Backbone,IN AS22773 2411 1564 847 35.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS24560 1126 295 831 73.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS4808 1214 394 820 67.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS4788 1036 251 785 75.8% TMNET-AS-AP TM Net, Internet Service Provider,MY AS18101 944 186 758 80.3% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS8151 1410 655 755 53.5% Uninet S.A. de C.V.,MX AS701 1482 751 731 49.3% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US AS7738 914 184 730 79.9% Telemar Norte Leste S.A.,BR AS26615 842 113 729 86.6% Tim Celular S.A.,BR AS855 760 57 703 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA AS6147 785 113 672 85.6% Telefonica del Peru S.A.A.,PE AS4780 1038 370 668 64.4% SEEDNET Digital United Inc.,TW AS9808 994 326 668 67.2% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN Total 51812 14325 37487 72.4% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.236.0/24 AS37290 -Reserved AS-,ZZ 41.78.237.0/24 AS37290 -Reserved AS-,ZZ 41.78.238.0/24 AS37290 -Reserved AS-,ZZ 41.78.239.0/24 AS37290 -Reserved AS-,ZZ 41.190.72.0/24 AS37451 CongoTelecom,CG 41.190.73.0/24 AS37451 CongoTelecom,CG 41.190.74.0/24 AS37451 CongoTelecom,CG 41.190.75.0/24 AS37451 CongoTelecom,CG 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos,US 63.247.0.0/24 AS27609 -Reserved AS-,ZZ 63.247.1.0/24 AS27609 -Reserved AS-,ZZ 63.247.2.0/24 AS27609 -Reserved AS-,ZZ 63.247.3.0/24 AS27609 -Reserved AS-,ZZ 63.247.4.0/24 AS27609 -Reserved AS-,ZZ 63.247.5.0/24 AS27609 -Reserved AS-,ZZ 63.247.6.0/24 AS27609 -Reserved AS-,ZZ 63.247.7.0/24 AS27609 -Reserved AS-,ZZ 63.247.8.0/24 AS27609 -Reserved AS-,ZZ 63.247.9.0/24 AS27609 -Reserved AS-,ZZ 63.247.10.0/24 AS27609 -Reserved AS-,ZZ 63.247.11.0/24 AS27609 -Reserved AS-,ZZ 63.247.13.0/24 AS27609 -Reserved AS-,ZZ 63.247.14.0/24 AS27609 -Reserved AS-,ZZ 63.247.15.0/24 AS27609 -Reserved AS-,ZZ 63.247.16.0/24 AS27609 -Reserved AS-,ZZ 63.247.17.0/24 AS27609 -Reserved AS-,ZZ 63.247.18.0/24 AS27609 -Reserved AS-,ZZ 63.247.19.0/24 AS27609 -Reserved AS-,ZZ 63.247.20.0/24 AS27609 -Reserved AS-,ZZ 63.247.21.0/24 AS27609 -Reserved AS-,ZZ 63.247.22.0/24 AS27609 -Reserved AS-,ZZ 63.247.23.0/24 AS27609 -Reserved AS-,ZZ 63.247.24.0/24 AS27609 -Reserved AS-,ZZ 63.247.25.0/24 AS27609 -Reserved AS-,ZZ 63.247.26.0/24 AS27609 -Reserved AS-,ZZ 63.247.27.0/24 AS27609 -Reserved AS-,ZZ 63.247.28.0/24 AS27609 -Reserved AS-,ZZ 63.247.29.0/24 AS27609 -Reserved AS-,ZZ 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.111.160.0/20 AS40551 -Reserved AS-,ZZ 64.111.160.0/24 AS40551 -Reserved AS-,ZZ 64.111.161.0/24 AS40551 -Reserved AS-,ZZ 64.111.162.0/24 AS40551 -Reserved AS-,ZZ 64.111.167.0/24 AS40551 -Reserved AS-,ZZ 64.111.169.0/24 AS40551 -Reserved AS-,ZZ 64.111.170.0/24 AS40551 -Reserved AS-,ZZ 64.111.171.0/24 AS40551 -Reserved AS-,ZZ 64.111.172.0/24 AS40551 -Reserved AS-,ZZ 64.111.173.0/24 AS40551 -Reserved AS-,ZZ 64.111.174.0/24 AS40551 -Reserved AS-,ZZ 64.111.175.0/24 AS40551 -Reserved AS-,ZZ 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc.,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.254.188.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 67.21.144.0/22 AS174 COGENT-174 - Cogent Communications,US 67.21.148.0/22 AS174 COGENT-174 - Cogent Communications,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.115.124.0/23 AS46540 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.119.236.0/23 AS26368 -Reserved AS-,ZZ 74.119.239.0/24 AS26368 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD,RU 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT 91.229.182.0/24 AS56960 -Reserved AS-,ZZ 91.229.186.0/24 AS56967 -Reserved AS-,ZZ 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 95.215.140.0/22 AS48949 -Reserved AS-,ZZ 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP 103.23.48.0/24 AS56194 103.23.49.0/24 AS56194 103.23.50.0/24 AS56194 103.23.51.0/24 AS56194 103.31.236.0/22 AS17941 BIT-ISLE Bit-isle Co.,Ltd.,JP 103.244.236.0/22 AS58794 103.247.52.0/23 AS4725 ODN SOFTBANK TELECOM Corp.,JP 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange,CN 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A.,EC 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc.,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.241.20.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.241.21.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.84.187.0/24 AS16276 OVH OVH SAS,FR 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.243.166.0/24 AS44093 -Reserved AS-,ZZ 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.69.203.0/24 AS5089 NTL Virgin Media Limited,GB 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 194.213.8.0/24 AS42845 BRETAGNETELECOM BRETAGNE TELECOM SAS,FR 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.39.252.0/23 AS29004 -Reserved AS-,ZZ 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.90.98.0/23 AS57511 OVALTECH-AS OvalTech Internet Ltd,GB 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL,RO 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.2.224.0/22 AS24863 LINKdotNET-AS,EG 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.13.201.0/24 AS2018 TENET-1,ZA 196.13.202.0/24 AS2018 TENET-1,ZA 196.13.203.0/24 AS2018 TENET-1,ZA 196.13.204.0/24 AS2018 TENET-1,ZA 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.45.0.0/21 AS26625 -Reserved AS-,ZZ 196.45.10.0/24 AS26625 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.72.78.0/23 AS3967 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.30.138.0/24 AS23319 -Reserved AS-,ZZ 199.30.139.0/24 AS23319 -Reserved AS-,ZZ 199.30.143.0/24 AS8100 IPTELLIGENT - IPTelligent LLC,US 199.68.72.0/24 AS174 COGENT-174 - Cogent Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.87.166.0/24 AS26368 -Reserved AS-,ZZ 199.87.167.0/24 AS26368 -Reserved AS-,ZZ 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.91.240.0/21 AS174 COGENT-174 - Cogent Communications,US 199.102.73.0/24 AS26368 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.9.40.0/24 AS56194 202.9.41.0/24 AS56194 202.9.42.0/24 AS56194 202.9.43.0/24 AS56194 202.9.44.0/24 AS56194 202.9.45.0/24 AS56194 202.9.46.0/24 AS56194 202.9.47.0/24 AS56194 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.10.94.0/23 AS30097 NUWAVE - NuWave,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp.,CA 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc.,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.74.224.0/22 AS174 COGENT-174 - Cogent Communications,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc.,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 212.119.32.0/19 AS12550 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US 216.24.176.0/20 AS19401 -Reserved AS-,ZZ 216.24.188.0/24 AS19401 -Reserved AS-,ZZ 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.203.80.0/20 AS27021 -Reserved AS-,ZZ 216.203.80.0/21 AS27021 -Reserved AS-,ZZ 216.203.87.0/24 AS27021 -Reserved AS-,ZZ 216.203.88.0/21 AS27021 -Reserved AS-,ZZ 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 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 May 2 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 May 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201405022200.s42M01Jj023715@wattle.apnic.net> BGP Update Report Interval: 24-Apr-14 -to- 01-May-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS7029 179743 8.1% 788.3 -- WINDSTREAM - Windstream Communications Inc,US 2 - AS9829 91957 4.1% 69.3 -- BSNL-NIB National Internet Backbone,IN 3 - AS4538 34300 1.5% 90.5 -- ERX-CERNET-BKB China Education and Research Network Center,CN 4 - AS8402 29550 1.3% 41.9 -- CORBINA-AS OJSC "Vimpelcom",RU 5 - AS29571 24924 1.1% 102.1 -- CITelecom-AS,CI 6 - AS41691 21703 1.0% 1085.2 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 7 - AS23752 21375 1.0% 164.4 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 8 - AS3816 20610 0.9% 36.3 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 9 - AS17557 19397 0.9% 323.3 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 10 - AS14259 15209 0.7% 760.5 -- Gtd Internet S.A.,CL 11 - AS28573 14291 0.6% 9.1 -- NET Servi�os de Comunica��o S.A.,BR 12 - AS4775 14187 0.6% 262.7 -- GLOBE-TELECOM-AS Globe Telecoms,PH 13 - AS6713 13895 0.6% 25.6 -- IAM-AS,MA 14 - AS10620 12372 0.6% 7.2 -- Telmex Colombia S.A.,CO 15 - AS35567 11996 0.5% 81.1 -- DASTO-BOSNIA-AS DASTO semtel d.o.o.,BA 16 - AS3475 11732 0.5% 120.9 -- DNIC-AS-03475 - Navy Network Information Center (NNIC),US 17 - AS48159 10346 0.5% 46.2 -- TIC-AS Telecommunication Infrastructure Company,IR 18 - AS6629 10142 0.5% 10142.0 -- NOAA-AS - NOAA,US 19 - AS647 8725 0.4% 74.6 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center,US 20 - AS52592 8708 0.4% 1741.6 -- CELINO RIBEIRO SERVICOS DE TELECOMUNICACOES LTDA -,BR TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6629 10142 0.5% 10142.0 -- NOAA-AS - NOAA,US 2 - AS18135 8062 0.4% 8062.0 -- BTV BTV Cable television,JP 3 - AS4 6846 0.3% 824.0 -- ISI-AS - University of Southern California,US 4 - AS34635 3997 0.2% 3997.0 -- LIBERTY-AS Liberty Poland S.A.,PL 5 - AS8039 2532 0.1% 2532.0 -- CCC-ASN-1 - Cinergy Communications,US 6 - AS54465 7083 0.3% 2361.0 -- QPM-AS-1 - QuickPlay Media Inc.,US 7 - AS52592 8708 0.4% 1741.6 -- CELINO RIBEIRO SERVICOS DE TELECOMUNICACOES LTDA -,BR 8 - AS3 1494 0.1% 1213.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 9 - AS3 1477 0.1% 1987.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 10 - AS33643 1388 0.1% 1388.0 -- JELLYBELLY - Jelly Belly Candy Company,US 11 - AS45590 1349 0.1% 1349.0 -- HGCINTNET-AS-AP Hutch Connect,HK 12 - AS7453 2595 0.1% 1297.5 -- ACCELERATION - ACCELERATED DATA WORKS, INC.,US 13 - AS60345 1282 0.1% 1282.0 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 14 - AS41691 21703 1.0% 1085.2 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 15 - AS37681 972 0.0% 972.0 -- Sunmail-AS,NG 16 - AS35093 1884 0.1% 942.0 -- RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 17 - AS1358 874 0.0% 874.0 -- HNSNET-AS - Hughes Network Systems, Inc.,US 18 - AS7029 179743 8.1% 788.3 -- WINDSTREAM - Windstream Communications Inc,US 19 - AS59137 1553 0.1% 776.5 -- IDNIC-KEMHAN-AS-ID PUSDATIN KEMHAN RI,ID 20 - AS14259 15209 0.7% 760.5 -- Gtd Internet S.A.,CL TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 89.221.206.0/24 21563 0.9% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 2 - 121.52.144.0/24 19623 0.8% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK AS45773 -- HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan,PK 3 - 87.250.97.0/24 11199 0.5% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o.,BA 4 - 192.58.232.0/24 10142 0.4% AS6629 -- NOAA-AS - NOAA,US 5 - 50.96.132.0/24 9207 0.4% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 6 - 205.247.12.0/24 8276 0.3% AS6459 -- TRANSBEAM - I-2000, Inc.,US 7 - 42.83.48.0/20 8062 0.3% AS18135 -- BTV BTV Cable television,JP 8 - 120.28.62.0/24 7348 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 9 - 206.152.15.0/24 7081 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.,US 10 - 186.237.56.0/22 6846 0.3% AS4 -- ISI-AS - University of Southern California,US 11 - 222.127.0.0/24 6355 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 12 - 67.140.240.0/20 6350 0.3% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 13 - 67.141.226.0/24 6310 0.3% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 14 - 67.141.236.0/24 6300 0.3% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 15 - 115.170.128.0/17 6028 0.2% AS4847 -- CNIX-AP China Networks Inter-Exchange,CN 16 - 71.28.104.0/21 5860 0.2% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 17 - 71.29.61.0/24 5851 0.2% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 18 - 71.29.38.0/24 5846 0.2% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 19 - 71.29.39.0/24 5845 0.2% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 20 - 71.30.87.0/24 5830 0.2% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 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 cgrundemann at gmail.com Fri May 2 22:07:05 2014 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 2 May 2014 16:07:05 -0600 Subject: Best practices IPv4/IPv6 BGP (dual stack) In-Reply-To: <1F639726-BDE2-42A6-A848-60C2FC3D0AD5@puck.nether.net> References: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> <1F639726-BDE2-42A6-A848-60C2FC3D0AD5@puck.nether.net> Message-ID: On Fri, May 2, 2014 at 1:47 PM, Jared Mauch wrote: > > > On May 2, 2014, at 3:44 PM, Deepak Jain wrote: > > > > > Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session? > > We use v4 transport for v4 routes and v6 transport for v6 routes only. +1 > This way if one plane is unstable the other is unaffected. This is the key point I believe: No protocol fate sharing! >From the draft BCOP on this topic[1]: ----8<---- Establish new, IPv6-Only peering sessions parallel to existing IPv4 peering. Individual IPv4 and IPv6 BGP peering sessions should be established between all BGP neighbors, particularly eBGP peers. While it is possible to use Multiprotocol BGP (MP-BGP)[2] to carry IPv6 Network Layer Reachability Information (NLRI) over existing (or new) IPv4 BGP peering sessions, this is not recommended. Both BGP sessions MAY use the same logical circuit, or, a new port MAY be used for IPv6 (separate physical or logical connections is NOT a requirement). [removed image] This maintains independent IPv6 and IPv4 topologies, rather than tying the two together unnecessarily. It prevents black holing of IPv6 traffic in the event of a protocol outage because the IPv6 session goes down when IPv6 reachability is lost. When an IPv4 BGP session carries IPv6 NLRI, IPv6 routes are only withdrawn if IPv4 connectivity is lost. Independent BGP sessions also facilitate protocol specific maintenance because the IPv4 and IPv6 sessions don’t affect each other (e.g. IPv6 can be “bounced” without effecting IPv4 and vice verse). Finally, establishing new, IPv6-only peering creates better operational clarity. It allows IPv4 and IPv6 configuration stanzas to be independent and easily recognizable. ----8<---- Cheers, ~Chris [1] - http://bcop.nanog.org/index.php/IPv6_Peering_Transit_BCOP_v0-6 [2] - Bates, T., Chandra, R., Katz, D., and Y. Rekhter, “Multiprotocol Extensions for BGP-4”, RFC 4760, January 2007 > > > - Jared -- @ChrisGrundemann http://chrisgrundemann.com From pymaunier+lists at gmail.com Fri May 2 15:58:47 2014 From: pymaunier+lists at gmail.com (Pierre-Yves Maunier) Date: Fri, 2 May 2014 17:58:47 +0200 Subject: oss netflow collector/trending/analysis In-Reply-To: References: Message-ID: 2014-05-02 16:36 GMT+02:00 Matthew Galgoci : > > Hey There, > > I was just wondering, for people who are doing netflow analysis with > open source tools and who are doing at least 10k or more flows per > second, what are you using? > > I know of three tool sets: > > - The classic osu flow-tools and the modern continuation/fork. > - ntop > - nfdump/nfsen > > Is there anything else I've missed? A few folks here really seem to like > nfsen/nfdump. > > Thanks, > > Matt > Hi Matt, I've been using pmacct for quite some time now and I'm more than happy with the results. Being able to store all infos in a *SQL db is a killer feature for me. Also it can speak BGP with your routers so it can grab the AS Path information which allow us for example to make traffic graphs for a destination AS aggregated by AS Path (one of my favorites feature I had with the Arbor peakflow in my previous company). Pierre-Yves From owen at delong.com Sat May 3 00:09:54 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 2 May 2014 17:09:54 -0700 Subject: Best practices IPv4/IPv6 BGP (dual stack) In-Reply-To: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> References: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> Message-ID: On May 2, 2014, at 12:44 PM, Deepak Jain wrote: > > Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session? Separate v4 and v6 sessions are the best practice. It is possible to have a single-protocol outage in which case you either take out the other protocol unnecessarily or you black-hole traffic. > According to docs, obviously all of these are supported and if both sides are dual stacked, even the next-hops don't need to be overwritten. Mostly true, but implementations vary and YMMV vendor to vendor and in some cases, model and/or software version to model and/or software version. Two sessions always works and unless you are somehow resource-constrained on sessions is really the simplest, easiest to manage, cleanest way to do things. > Is there any community-approach to best practices here? Any FIB weirdness (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc) that results with one solution over the other? See above for BCP. As to the rest, in my experience, the answers vary (see above). Owen From jfmezei_nanog at vaxination.ca Sat May 3 03:49:39 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 02 May 2014 23:49:39 -0400 Subject: CLEC and FTTP H.248/Megaco Message-ID: <53646753.7070305@vaxination.ca> I need a sanity check. An incumbent in Canada has revealed that its voice service on FTTP deployments is based on H.248 MEGACO (Media Gateway Controller). Are there any examples of CLEC access to such FTTP deployments ? (for instance, an area where the copper was removed, leaving only fibre to homes, do CLECs retain competitive access via fibre to homes, or is it going out of business or going with pure SIP/VoIP over the regular internet connection, instead of using the "quality" voice link in the GPON with garanteed bandwidth ? Can this protocol support the programming of one OLT/MG connecting to the Telco's MGC, while the OLT/MG next door connects to the CLEC's MGC ? Or does the protocol result in MG's "discovering" the nearest MGC and connecting to it (making it hard to have multiple MGCs from competing telcos). I have been lead to believe that most OLTs came with a SIP based ATA. It appears that H.248 is more telco friendly and scales better. Does this mean that H.248 is more widely deployed in FTTH ? From eugen at imacandi.net Sat May 3 06:01:52 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sat, 3 May 2014 09:01:52 +0300 Subject: Best practices IPv4/IPv6 BGP (dual stack) In-Reply-To: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> References: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> Message-ID: On Fri, May 2, 2014 at 10:44 PM, Deepak Jain wrote: > > Between peering routers on a dual-stacked network, is it considered best > practices to have two BGP sessions (one for v4 and one for v6) between > them? Or is it better to put v4 in the v6 session or v6 in the v4 session? > > According to docs, obviously all of these are supported and if both sides > are dual stacked, even the next-hops don't need to be overwritten. > > I've done it separately. IPv4 with IPv4, IPv6 with IPv6. From my point of view it's a cleaner configuration to have things decoupled completely: management, debugging. > Is there any community-approach to best practices here? Any FIB weirdness > (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc) that > results with one solution over the other? > > None that I've noticed. From contact at winterei.se Sat May 3 06:24:58 2014 From: contact at winterei.se (Paul S.) Date: Sat, 03 May 2014 15:24:58 +0900 Subject: Best practices IPv4/IPv6 BGP (dual stack) In-Reply-To: References: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> Message-ID: <53648BBA.4030404@winterei.se> As precaution, you should always deny ipv6 unicast on v4 sessions, and vice versa. On 5/3/2014 午後 03:01, Eugeniu Patrascu wrote: > On Fri, May 2, 2014 at 10:44 PM, Deepak Jain wrote: > >> Between peering routers on a dual-stacked network, is it considered best >> practices to have two BGP sessions (one for v4 and one for v6) between >> them? Or is it better to put v4 in the v6 session or v6 in the v4 session? >> >> According to docs, obviously all of these are supported and if both sides >> are dual stacked, even the next-hops don't need to be overwritten. >> >> > I've done it separately. IPv4 with IPv4, IPv6 with IPv6. From my point of > view it's a cleaner configuration to have things decoupled completely: > management, debugging. > > >> Is there any community-approach to best practices here? Any FIB weirdness >> (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc) that >> results with one solution over the other? >> >> > None that I've noticed. From mansaxel at besserwisser.org Sat May 3 09:26:27 2014 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sat, 3 May 2014 11:26:27 +0200 Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)] In-Reply-To: References: Message-ID: <20140503092627.GR13966@besserwisser.org> Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)] Date: Fri, May 02, 2014 at 03:58:42PM -0600 Quoting Chris Grundemann (cgrundemann at gmail.com): > Would you expound a bit on what you mean here? I don't quite follow but I > am very interested to understand the issue. The fact that you need v4 space to build a MPLS backbone is a very good reason to not waste a /10 on CGN crap. Ideally, we would have a solution where an entire MPLS infrastructure could be built without v4 space, demoting v4 to a legacy application inside a VRF, but the MPLS standards wg seems content with status quo. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I wish I was a sex-starved manicurist found dead in the Bronx!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From randy at psg.com Sat May 3 09:58:22 2014 From: randy at psg.com (Randy Bush) Date: Sat, 03 May 2014 11:58:22 +0200 Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)] In-Reply-To: <20140503092627.GR13966@besserwisser.org> References: <20140503092627.GR13966@besserwisser.org> Message-ID: a good number of us use that kinky /10 behind home nats and encourage everyone to do so. it was a sick deal and should be treated as such, just more 1918. randy From clayton at MNSi.Net Sat May 3 12:56:08 2014 From: clayton at MNSi.Net (Clayton Zekelman) Date: Sat, 03 May 2014 08:56:08 -0400 Subject: CLEC and FTTP H.248/Megaco In-Reply-To: <53646753.7070305@vaxination.ca> References: <53646753.7070305@vaxination.ca> Message-ID: <1399121772_43816@surgemail.mnsi.net> In my experience, where Bell Canada has installed FTTP facilities, CLECs are not given access to these deployments. The orders come back as "UNAVAILABLE FACILITIES" At 11:49 PM 02/05/2014, Jean-Francois Mezei wrote: >I need a sanity check. > >An incumbent in Canada has revealed that its voice service on FTTP >deployments is based on H.248 MEGACO (Media Gateway Controller). > >Are there any examples of CLEC access to such FTTP deployments ? > >(for instance, an area where the copper was removed, leaving only fibre >to homes, do CLECs retain competitive access via fibre to homes, or is >it going out of business or going with pure SIP/VoIP over the regular >internet connection, instead of using the "quality" voice link in the >GPON with garanteed bandwidth ? > >Can this protocol support the programming of one OLT/MG connecting to >the Telco's MGC, while the OLT/MG next door connects to the CLEC's MGC ? > >Or does the protocol result in MG's "discovering" the nearest MGC and >connecting to it (making it hard to have multiple MGCs from competing >telcos). > > > > >I have been lead to believe that most OLTs came with a SIP based ATA. It >appears that H.248 is more telco friendly and scales better. Does this >mean that H.248 is more widely deployed in FTTH ? --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From mark at amplex.net Sat May 3 13:27:49 2014 From: mark at amplex.net (Mark Radabaugh) Date: Sat, 03 May 2014 09:27:49 -0400 Subject: Paging HP DNS admin Message-ID: <5364EED5.1000801@amplex.net> Dear HP: If your not going to support IPv6 can you at least not return SRVFAIL when asked for an AAAA record: root at spoons:/etc/mail # dig AAAA onramp01.hpeprint.com ; <<>> DiG 9.8.3-P4 <<>> AAAA onramp01.hpeprint.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61583 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;onramp01.hpeprint.com. IN AAAA And what genius thought that emailing documents to printers was a good idea in the first place? Nothing like taking graphics, turning it into 7 bit text, and sending it through a system never intended for the purpose. Supporting luser email is a big enough pain in the arse, now I have to deal with your idiotic printers as well? Gee thanks! Mark From frnkblk at iname.com Sat May 3 13:48:58 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 3 May 2014 08:48:58 -0500 Subject: CLEC and FTTP H.248/Megaco In-Reply-To: <53646753.7070305@vaxination.ca> References: <53646753.7070305@vaxination.ca> Message-ID: <000501cf66d6$6eb1e320$4c15a960$@iname.com> We use H.248 in our CLEC area. The voice service for that ONT runs on a specified VLAN for that ONT, so if we had to share our infrastructure with other CLECs we could do that. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jean-Francois Mezei Sent: Friday, May 02, 2014 10:50 PM To: nanog at nanog.org Subject: CLEC and FTTP H.248/Megaco I need a sanity check. An incumbent in Canada has revealed that its voice service on FTTP deployments is based on H.248 MEGACO (Media Gateway Controller). Are there any examples of CLEC access to such FTTP deployments ? (for instance, an area where the copper was removed, leaving only fibre to homes, do CLECs retain competitive access via fibre to homes, or is it going out of business or going with pure SIP/VoIP over the regular internet connection, instead of using the "quality" voice link in the GPON with garanteed bandwidth ? Can this protocol support the programming of one OLT/MG connecting to the Telco's MGC, while the OLT/MG next door connects to the CLEC's MGC ? Or does the protocol result in MG's "discovering" the nearest MGC and connecting to it (making it hard to have multiple MGCs from competing telcos). I have been lead to believe that most OLTs came with a SIP based ATA. It appears that H.248 is more telco friendly and scales better. Does this mean that H.248 is more widely deployed in FTTH ? From cgrundemann at gmail.com Sat May 3 17:23:56 2014 From: cgrundemann at gmail.com (Chris Grundemann) Date: Sat, 3 May 2014 11:23:56 -0600 Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)] In-Reply-To: <20140503092627.GR13966@besserwisser.org> References: <20140503092627.GR13966@besserwisser.org> Message-ID: On Sat, May 3, 2014 at 3:26 AM, Måns Nilsson wrote: > The fact that you need v4 space to build a MPLS backbone is a very good > reason to not waste a /10 on CGN crap. Ah, so you're in the camp that a /10 given to one organization for their private use would have been better than reserving that /10 for _everyone_ to use. We'll have to agree to disagree there. > > Ideally, we would have a solution where an entire MPLS infrastructure > could be built without v4 space, demoting v4 to a legacy application > inside a VRF, but the MPLS standards wg seems content with status quo. We can agree on that. Thanks, ~Chris > > -- > Måns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE +46 705 989668 > I wish I was a sex-starved manicurist found dead in the Bronx!! -- @ChrisGrundemann http://chrisgrundemann.com From adam.vitkovsky at swan.sk Sat May 3 17:24:24 2014 From: adam.vitkovsky at swan.sk (=?iso-8859-2?Q?Vitkovsk=FD_Adam?=) Date: Sat, 3 May 2014 17:24:24 +0000 Subject: Best practices IPv4/IPv6 BGP (dual stack) In-Reply-To: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> References: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B011E9A3F@EX01.swan.local> Sure it's a different transport protocol altogether, anyways It's interesting to see how everybody tends to separate the IPv4 and IPv6 AFs onto a different TCP sessions and still run the plethora of other AFs on the common v4 TCP session, maybe apart from couple of the big folks, who can afford running separate control-plane and edge infrastructure for some of the AFs, IPv6 AF being the first ran separately. adam From cgrundemann at gmail.com Sat May 3 17:36:10 2014 From: cgrundemann at gmail.com (Chris Grundemann) Date: Sat, 3 May 2014 11:36:10 -0600 Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)] In-Reply-To: References: <20140503092627.GR13966@besserwisser.org> Message-ID: On Sat, May 3, 2014 at 3:58 AM, Randy Bush wrote: > a good number of us use that kinky /10 behind home nats and encourage > everyone to do so. it was a sick deal and should be treated as such, > just more 1918. A good number of folks use other folks IP space in all kinds of strange and kinky ways too - it's ALL just more 1918, right??? Or maybe standards exist for a reason. Perhaps enhancing coordination, cooperation, and *interoperability* are good things... I'll let you decide, Randy; is it sick to solve problems through community consensus and standardization, or is it sick to be the one intentionally getting in the way of those real world solutions? Cheers, ~Chris > > randy -- @ChrisGrundemann http://chrisgrundemann.com From swmike at swm.pp.se Sat May 3 18:23:43 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 3 May 2014 20:23:43 +0200 (CEST) Subject: Best practices IPv4/IPv6 BGP (dual stack) In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B011E9A3F@EX01.swan.local> References: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> <61DC6BC4ABA10E4489D4A73EBABAC18B011E9A3F@EX01.swan.local> Message-ID: On Sat, 3 May 2014, Vitkovský Adam wrote: > Sure it's a different transport protocol altogether, anyways It's > interesting to see how everybody tends to separate the IPv4 and IPv6 AFs > onto a different TCP sessions and still run the plethora of other AFs on > the common v4 TCP session, maybe apart from couple of the big folks, who > can afford running separate control-plane and edge infrastructure for > some of the AFs, IPv6 AF being the first ran separately. I know lots of people who run vpnv4 separately from ipv4 and ipv6 (so they have 3 sessions). The ones I talked to intends to run vpnv6 separately as well. -- Mikael Abrahamsson email: swmike at swm.pp.se From joelja at bogus.com Sat May 3 18:48:14 2014 From: joelja at bogus.com (joel jaeggli) Date: Sat, 03 May 2014 11:48:14 -0700 Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)] In-Reply-To: References: <20140503092627.GR13966@besserwisser.org> Message-ID: <536539EE.8090502@bogus.com> On 5/3/14, 10:36 AM, Chris Grundemann wrote: > On Sat, May 3, 2014 at 3:58 AM, Randy Bush wrote: >> a good number of us use that kinky /10 behind home nats and encourage >> everyone to do so. it was a sick deal and should be treated as such, >> just more 1918. > > A good number of folks use other folks IP space in all kinds of > strange and kinky ways too - it's ALL just more 1918, right??? Or > maybe standards exist for a reason. Perhaps enhancing coordination, > cooperation, and *interoperability* are good things... I'll let you > decide, Randy; is it sick to solve problems through community > consensus and standardization, or is it sick to be the one > intentionally getting in the way of those real world solutions? Any time you have two parties that have to interconnect who have overlapping usage of the same space you're going to have issues. The authors the 6598 were concerned about intersection with legacy CPE. 100.64.0.0/10 does not yet have that issue. The use cases being described here (randy causing pollution, numbering internal network resources (the intended purpose after all)) have no relationship to legacy CPE. characterizing it as shared was always a misnomer since by their nature collisions are not sharing. in a somewhat unrelated note this prefix is still leaking in some globally visible ways in some places. e.g. if you're as3303 you probably shouldn't be importing these prefixes from customers or exporting as part of your full table given that you also accept them from subsidiaries. that's likely to end in tears. > Cheers, > ~Chris > >> >> randy > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From carlos at race.com Sat May 3 19:51:06 2014 From: carlos at race.com (Carlos Alcantar) Date: Sat, 3 May 2014 19:51:06 +0000 Subject: CLEC and FTTP H.248/Megaco In-Reply-To: <000501cf66d6$6eb1e320$4c15a960$@iname.com> Message-ID: +1 here we do the same exact thing with our ftth and ont¹s separate vlan with h.248 gw¹s sitting on it and you just point the profile of the voice port to the gw. There is a reason why they are doing things this way, as current regulation does not force them to give you access to there fiber network. Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com On 5/3/14, 6:48 AM, "Frank Bulk" wrote: >We use H.248 in our CLEC area. The voice service for that ONT runs on a >specified VLAN for that ONT, so if we had to share our infrastructure with >other CLECs we could do that. > >Frank > >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jean-Francois >Mezei >Sent: Friday, May 02, 2014 10:50 PM >To: nanog at nanog.org >Subject: CLEC and FTTP H.248/Megaco > >I need a sanity check. > >An incumbent in Canada has revealed that its voice service on FTTP >deployments is based on H.248 MEGACO (Media Gateway Controller). > >Are there any examples of CLEC access to such FTTP deployments ? > >(for instance, an area where the copper was removed, leaving only fibre >to homes, do CLECs retain competitive access via fibre to homes, or is >it going out of business or going with pure SIP/VoIP over the regular >internet connection, instead of using the "quality" voice link in the >GPON with garanteed bandwidth ? > >Can this protocol support the programming of one OLT/MG connecting to >the Telco's MGC, while the OLT/MG next door connects to the CLEC's MGC ? > >Or does the protocol result in MG's "discovering" the nearest MGC and >connecting to it (making it hard to have multiple MGCs from competing >telcos). > > > > >I have been lead to believe that most OLTs came with a SIP based ATA. It >appears that H.248 is more telco friendly and scales better. Does this >mean that H.248 is more widely deployed in FTTH ? > > > > From scott at doc.net.au Sat May 3 20:18:02 2014 From: scott at doc.net.au (Scott Howard) Date: Sat, 3 May 2014 13:18:02 -0700 Subject: Paging HP DNS admin In-Reply-To: <5364EED5.1000801@amplex.net> References: <5364EED5.1000801@amplex.net> Message-ID: On Sat, May 3, 2014 at 6:27 AM, Mark Radabaugh wrote: > Dear HP: > > If your not going to support IPv6 can you at least not return SRVFAIL when > asked for an AAAA record: > They aren't. Your resolver is - or at least, that's what it looks like for me. Sending an AAAA query to their nameservers times out for me - no response at all. Sending the same query through certain resolvers (eg, Google) seems to result in the timeout being turned into a SERVFAIL. $ dig AAAA onramp01.hpeprint.com ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> AAAA onramp01.hpeprint.com ;; global options: +cmd ;; connection timed out; no servers could be reached Same via Google : $ dig AAAA onramp01.hpeprint.com @8.8.8.8 ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> AAAA onramp01.hpeprint.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26319 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 Scott From m.hallgren at free.fr Sat May 3 20:55:47 2014 From: m.hallgren at free.fr (Michael Hallgren) Date: Sat, 03 May 2014 22:55:47 +0200 Subject: Best practices IPv4/IPv6 BGP (dual stack) In-Reply-To: References: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> <61DC6BC4ABA10E4489D4A73EBABAC18B011E9A3F@EX01.swan.local> Message-ID: <536557D3.2030000@free.fr> Le 03/05/2014 20:23, Mikael Abrahamsson a écrit : > On Sat, 3 May 2014, Vitkovský Adam wrote: > >> Sure it's a different transport protocol altogether, anyways It's >> interesting to see how everybody tends to separate the IPv4 and IPv6 >> AFs onto a different TCP sessions and still run the plethora of other >> AFs on the common v4 TCP session, maybe apart from couple of the big >> folks, who can afford running separate control-plane and edge >> infrastructure for some of the AFs, IPv6 AF being the first ran >> separately. > > I know lots of people who run vpnv4 separately from ipv4 and ipv6 (so > they have 3 sessions). The ones I talked to intends to run vpnv6 > separately as well. > Voilà ! Question is rather ``why not''?... once you decide to support services... mh From jfmezei_nanog at vaxination.ca Sun May 4 00:04:31 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sat, 03 May 2014 20:04:31 -0400 Subject: CLEC and FTTP H.248/Megaco In-Reply-To: References: Message-ID: <5365840F.9030001@vaxination.ca> Based on asnwers so far: To put things in perspective The current regulations offer unbundled COPPER loops, as well as an aggregated wholesale last mile access for DSL/VDSL (wholesale also mandated for cable for data but not voice) This may change with the CRTC 2013-551 consultation which reviews a whole bunch of stuff on "essential services" nature, and this includes discussion on whether wholesale access to FTTH served homes should be mandated. As a result, knowing if the architecture of H.248 allows multiple voice service providers to co-exist on the same GPON (one house connected to ILEC voice, the next house connected to CLEC etc) becomes important. If the protocol is such that it does not permit co-existance, then a debate on wholesale voice access is moot. If the protocol does permit it, then providing soe form of evidence (either existing implementations or pointer to specs that show this was explicitely designed into the architecture) would be of great help. From mark at amplex.net Sun May 4 02:02:09 2014 From: mark at amplex.net (Mark Radabaugh) Date: Sat, 03 May 2014 22:02:09 -0400 Subject: Paging HP DNS admin In-Reply-To: References: <5364EED5.1000801@amplex.net> Message-ID: <53659FA1.9010107@amplex.net> Either way - it breaks Sendmail, some versions of Exchange, and possibly other MTA's. The proper answer to a non-existent AAAA record is NOERROR, with ANSWER 0. Hanging or refusing to answer doesn't result in another attempt to look for an A record since the name server failed to respond to a valid query. Given that the whole point of the domain is to enable email printing, HP isn't making it easy. Mark On 5/3/14, 4:18 PM, Scott Howard wrote: > On Sat, May 3, 2014 at 6:27 AM, Mark Radabaugh > wrote: > > Dear HP: > > If your not going to support IPv6 can you at least not return > SRVFAIL when asked for an AAAA record: > > > They aren't. Your resolver is - or at least, that's what it looks > like for me. > > Sending an AAAA query to their nameservers times out for me - no > response at all. Sending the same query through certain resolvers > (eg, Google) seems to result in the timeout being turned into a SERVFAIL. > > $ dig AAAA onramp01.hpeprint.com > > ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> AAAA onramp01.hpeprint.com > > ;; global options: +cmd > ;; connection timed out; no servers could be reached > > > Same via Google : > $ dig AAAA onramp01.hpeprint.com > @8.8.8.8 > > ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> AAAA onramp01.hpeprint.com > @8.8.8.8 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26319 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > > Scott > -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 x 1021 From morrowc.lists at gmail.com Sun May 4 02:42:15 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 3 May 2014 22:42:15 -0400 Subject: Paging HP DNS admin In-Reply-To: <53659FA1.9010107@amplex.net> References: <5364EED5.1000801@amplex.net> <53659FA1.9010107@amplex.net> Message-ID: On Sat, May 3, 2014 at 10:02 PM, Mark Radabaugh wrote: > Either way - it breaks Sendmail, some versions of Exchange, and possibly > other MTA's. The proper answer to a non-existent AAAA record is NOERROR, > with ANSWER 0. if I ask ns1/2/3/4/5/6.hp.com directly for AAAA for onramp01.hpeprint.com.: ; <<>> DiG 9.8.1-P1 <<>> AAAA onramp01.hpeprint.com. @ns6.hp.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30318 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 6 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;onramp01.hpeprint.com. IN AAAA (I get the same result for all ns hosts) if I ask my local bind (ubuntu package == 1:9.8.1.dfsg.P) though I get: $ dig AAAA onramp01.hpeprint.com @localhost ; <<>> DiG 9.8.1-P1 <<>> AAAA onramp01.hpeprint.com @localhost ;; global options: +cmd ;; connection timed out; no servers could be reached That's a bit weird and frustrating. > Hanging or refusing to answer doesn't result in another attempt to look for > an A record since the name server failed to respond to a valid query. > Given that the whole point of the domain is to enable email printing, HP > isn't making it easy. scott's request LOOKS like a request to 'some resolver' (not directly to them, perhaps his local bind instance? I wonder why 8.8.8.8 returns srvfail? I think one of the google-public-dns people reads nanog, perhaps he knows? (or could fix this which seems to be a bug, to me at least) -chris From cma at cmadams.net Sun May 4 03:13:51 2014 From: cma at cmadams.net (Chris Adams) Date: Sat, 3 May 2014 22:13:51 -0500 Subject: Paging HP DNS admin In-Reply-To: References: <5364EED5.1000801@amplex.net> <53659FA1.9010107@amplex.net> Message-ID: <20140504031351.GC12342@cmadams.net> Once upon a time, Christopher Morrow said: > if I ask ns1/2/3/4/5/6.hp.com directly for AAAA for onramp01.hpeprint.com.: > > ; <<>> DiG 9.8.1-P1 <<>> AAAA onramp01.hpeprint.com. @ns6.hp.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30318 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 6 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;onramp01.hpeprint.com. IN AAAA You left out the authority section that refers you to the correct DNS servers - ns[1-6].hp.com are not it. They delegate to another set of HP servers, which all time out (as stated by the OP) when asked for AAAA. Oddly, it seems to be specific to AAAA; any other type request I send comes back NOERROR correctly. It is like somebody tried to handle AAAA "special" and screwed it up. -- Chris Adams From scott at doc.net.au Sun May 4 03:20:39 2014 From: scott at doc.net.au (Scott Howard) Date: Sat, 3 May 2014 20:20:39 -0700 Subject: Paging HP DNS admin In-Reply-To: <20140504031351.GC12342@cmadams.net> References: <5364EED5.1000801@amplex.net> <53659FA1.9010107@amplex.net> <20140504031351.GC12342@cmadams.net> Message-ID: On Sat, May 3, 2014 at 8:13 PM, Chris Adams wrote: > You left out the authority section that refers you to the correct DNS > servers - ns[1-6].hp.com are not it. They delegate to another set of HP > servers, which all time out (as stated by the OP) when asked for AAAA. > Actually the OP said that it returned SERVFAIL, which the HP servers don't, but Googles public DNS server (and potentially others) does. > Oddly, it seems to be specific to AAAA; any other type request I send > comes back NOERROR correctly. It is like somebody tried to handle AAAA > "special" and screwed it up. > This isn't new. RFC 4074 from 2005 covers this exact issue. From memory, this is/was the default behavior for DJBDNS. Scott From morrowc.lists at gmail.com Sun May 4 04:10:14 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 4 May 2014 00:10:14 -0400 Subject: Paging HP DNS admin In-Reply-To: <20140504031351.GC12342@cmadams.net> References: <5364EED5.1000801@amplex.net> <53659FA1.9010107@amplex.net> <20140504031351.GC12342@cmadams.net> Message-ID: On Sat, May 3, 2014 at 11:13 PM, Chris Adams wrote: > Once upon a time, Christopher Morrow said: >> if I ask ns1/2/3/4/5/6.hp.com directly for AAAA for onramp01.hpeprint.com.: >> >> ; <<>> DiG 9.8.1-P1 <<>> AAAA onramp01.hpeprint.com. @ns6.hp.com >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30318 >> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 6 >> ;; WARNING: recursion requested but not available >> >> ;; QUESTION SECTION: >> ;onramp01.hpeprint.com. IN AAAA > > You left out the authority section that refers you to the correct DNS darned it :( yes. > servers - ns[1-6].hp.com are not it. They delegate to another set of HP > servers, which all time out (as stated by the OP) when asked for AAAA. > yup :( > Oddly, it seems to be specific to AAAA; any other type request I send > comes back NOERROR correctly. It is like somebody tried to handle AAAA > "special" and screwed it up. I remember nytimes doing something like this for a while, I believe they said their GSLB was just not happy doing AAAA, or if not configured would display similar behaviour. -chris From randy at psg.com Sun May 4 05:18:21 2014 From: randy at psg.com (Randy Bush) Date: Sun, 04 May 2014 07:18:21 +0200 Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)] In-Reply-To: References: <20140503092627.GR13966@besserwisser.org> Message-ID: > Ah, so you're in the camp that a /10 given to one organization for > their private use would have been better than reserving that /10 for > _everyone_ to use. We'll have to agree to disagree there. you forced an rfc allocation. that makes public space, and is and will be used as such. you wanted an 'owned' allocation that you and your friends control, you shoulda gone to the rirs. randy From dedelman at iname.com Sun May 4 17:02:45 2014 From: dedelman at iname.com (David Edelman) Date: Sun, 4 May 2014 13:02:45 -0400 Subject: oss netflow collector/trending/analysis In-Reply-To: References: <20140502150015.5950B55000087@freedman.net> Message-ID: Argus (qosient.com) is worth looking at. Dave Edelman > On May 2, 2014, at 12:21, Leslie wrote: > > pmacct (http://www.pmacct.net/) is another pretty awesome open source tool. > > Leslie > >> On Fri, May 2, 2014 at 8:00 AM, Avi Freedman wrote: >> >> There's also SiLK from CMU. It's powerful but has a learning curve. >> >> I also see pmacct being used both by some end networks and by >> some vendors as part of systems. >> >> Avi >> >>> Hey There, >>> >>> I was just wondering, for people who are doing netflow analysis with >>> open source tools and who are doing at least 10k or more flows per >>> second, what are you using? >>> >>> I know of three tool sets: >>> >>> - The classic osu flow-tools and the modern continuation/fork. >>> - ntop >>> - nfdump/nfsen >>> >>> Is there anything else I've missed? A few folks here really seem to like >>> nfsen/nfdump. >>> >>> Thanks, >>> >>> Matt >> From wbailey at satelliteintelligencegroup.com Sun May 4 17:10:38 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sun, 4 May 2014 17:10:38 +0000 Subject: oss netflow collector/trending/analysis In-Reply-To: References: <20140502150015.5950B55000087@freedman.net> , Message-ID: Ntop is somehow open source if I recall. Seemed to work well and was fairly cheap to license. Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: David Edelman Date: 05/04/2014 11:05 AM (GMT-07:00) To: Leslie Cc: nanog at nanog.org Subject: Re: oss netflow collector/trending/analysis Argus (qosient.com) is worth looking at. Dave Edelman > On May 2, 2014, at 12:21, Leslie wrote: > > pmacct (http://www.pmacct.net/) is another pretty awesome open source tool. > > Leslie > >> On Fri, May 2, 2014 at 8:00 AM, Avi Freedman wrote: >> >> There's also SiLK from CMU. It's powerful but has a learning curve. >> >> I also see pmacct being used both by some end networks and by >> some vendors as part of systems. >> >> Avi >> >>> Hey There, >>> >>> I was just wondering, for people who are doing netflow analysis with >>> open source tools and who are doing at least 10k or more flows per >>> second, what are you using? >>> >>> I know of three tool sets: >>> >>> - The classic osu flow-tools and the modern continuation/fork. >>> - ntop >>> - nfdump/nfsen >>> >>> Is there anything else I've missed? A few folks here really seem to like >>> nfsen/nfdump. >>> >>> Thanks, >>> >>> Matt >> From charles at thefnf.org Sun May 4 18:57:32 2014 From: charles at thefnf.org (Charles N Wyble) Date: Sun, 04 May 2014 13:57:32 -0500 Subject: What Net Neutrality should and should not cover In-Reply-To: <20140427203005.4853.qmail@joyce.lan> References: <20140427203005.4853.qmail@joyce.lan> Message-ID: <53668D9C.4030700@thefnf.org> On 4/27/2014 3:30 PM, John Levine wrote: >> That is, with CATV companies like HBO have to pay companies like >> Comcast for access to their cable subscribers. > > In a non-stupid world, the cable companies would do video on demand > through some combination of content caches at the head end or, for > popular stuff, encrypted midnight downloads to your DVR, and the > cablecos would split the revenue with content backends like Netflix. So why hasn't someone like he or cogent done this? Especially for delivery into campus/corporate environments (which is a decent amount of the customer base for the "smaller" providers I think). Seems like a good market opportunity. I happen to be quite interested in optimizing video delivery (triple play, and streaming content) to an access network in Kansas City. For streaming, I know that Netflix has: https://www.netflix.com/openconnect that I can stick in the colo that the access network already backhauls to. Does Amazon have something like this? Hmmm.... maybe we can just peer with them at the nearest AWS POP. What are folks doing for optimizing Amazon streaming? As for the traditional content (hbo etc), my understanding is these can be accessed via wholesale agreements? Satellite downlink (lots of cheap real estate where I could have a downlink station), then I just need to be able to send it to my IPTV distribution fabric (fiber/ long range microwave whatever). Though I understand there is much DRM involved, and I don't know anything about any accounting / viewer reporting that might be required. So it really seems to me, that even with an established competitive access network (located in Kansas City MO) , if I want to offer streaming/TV content (and have all the pain that the big boys have) I might not be able to do it? I can of course peer with netflix and deploy one of their fancy appliances. See, all of this is so locked up and non clear. It's very un tractable to me. I am curious about even generalities of how this all works, where the pain points are etc. I suppose the incumbents are annoyed with folks cutting the cord and bypassing that nice set of carefully engineered video delivery plant, for that pesky ip based stuff (but maybe keeping the ISP portion of the service)? Why don't the access network providers just raise the internet portion of the cost to match the lost revenue? Or work out a Pay Per View type deal with netflix? (Like you can buy apps via your cell phone provider, why don't netflix/time warner work out a Pay Per View that you could get on your monthly bill)? It all seems very complicated to me. Why not just work out deals with netflix behind the scenes to help cover port upgrade costs or something? Instead of all this circus nonsense. That way, you would get your costs covered (by the people who are forcing you to incur that cost), and you would still get your monthly transit revenue. If I work on a particular project for a specific customer, I bill that customer for my incurred expenses. No one outside of me and the customer knows that, or needs to know that. I still bill them a recurring (hourly/monthly whatever) rate, and I bill them for one time expenses. > But this world is mostly stupid, the cable companies never got VOD, so > you have companies like Netflix filling the gap with pessimized > technology. (I do see that starting tomorrow, there will be a Netflix > channel on three small cablecos including RCN, delivered via TiVo, > although it's not clear if the delivery channel will change.) Yeah that was interesting. I'm curious how that actually works. Will it be an app on the set top box? > > The other issue is that due to regulatory failure, cable companies are > an oligopoly, and in most areas a local monopoly, so Comcast has the > muscle to shake down Internet video providers. That's not a technical > problem, it's a political one. In Europe, where DSL is a lot faster > than here, carriage and content are separate and there are a zillion > DSL providers. We could do that here if the FCC weren't so spineless. Yes. Agreed. I'm (with the Free Network Foundation https://www.thefnf.org) helping folks in KC and Austin build alternative access networks (using wifi, backhauled to neutral NAP locations). That seems to be the only viable option in the US. From bill at herrin.us Sun May 4 19:25:46 2014 From: bill at herrin.us (William Herrin) Date: Sun, 4 May 2014 15:25:46 -0400 Subject: What Net Neutrality should and should not cover In-Reply-To: <53668D9C.4030700@thefnf.org> References: <20140427203005.4853.qmail@joyce.lan> <53668D9C.4030700@thefnf.org> Message-ID: On Sun, May 4, 2014 at 2:57 PM, Charles N Wyble wrote: > On 4/27/2014 3:30 PM, John Levine wrote: >> In a non-stupid world, the cable companies would do video on demand >> through some combination of content caches at the head end or, for >> popular stuff, encrypted midnight downloads to your DVR, and the >> cablecos would split the revenue with content backends like Netflix. > > > So why hasn't someone like he or cogent done this? Because 30 years later the big content owners still hate VCRs. Streaming doesn't bother them so much but they avail themselves of every opportunity to say no to the end-user recorded content. This is hardly a surprise... A century later they still hate the first sale doctrine too and avail themselves of every opportunity to undermine it. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mark.tinka at seacom.mu Sun May 4 21:37:03 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 4 May 2014 23:37:03 +0200 Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)] In-Reply-To: <20140503092627.GR13966@besserwisser.org> References: <20140503092627.GR13966@besserwisser.org> Message-ID: <201405042337.06575.mark.tinka@seacom.mu> On Saturday, May 03, 2014 11:26:27 AM Måns Nilsson wrote: > Ideally, we would have a solution where an entire MPLS > infrastructure could be built without v4 space, demoting > v4 to a legacy application inside a VRF, but the MPLS > standards wg seems content with status quo. There is work ongoing in the MPLS IETF WG on identifying the gaps that various MPLS applications have so they can be prepared for IPv6 MPLS control and data planes. Long overdue, if you ask me, but at least it's starting to get some attention. 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 Sun May 4 21:40:10 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 4 May 2014 23:40:10 +0200 Subject: Best practices IPv4/IPv6 BGP (dual stack) In-Reply-To: References: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> <61DC6BC4ABA10E4489D4A73EBABAC18B011E9A3F@EX01.swan.local> Message-ID: <201405042340.10407.mark.tinka@seacom.mu> On Saturday, May 03, 2014 08:23:43 PM Mikael Abrahamsson wrote: > I know lots of people who run vpnv4 separately from ipv4 > and ipv6 (so they have 3 sessions). The ones I talked to > intends to run vpnv6 separately as well. Except that VPNv6, today, relies on MPLSv4. So it's not "pure" yet. 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 Sun May 4 21:41:00 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 4 May 2014 23:41:00 +0200 Subject: Best practices IPv4/IPv6 BGP (dual stack) In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B011E9A3F@EX01.swan.local> References: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local> <61DC6BC4ABA10E4489D4A73EBABAC18B011E9A3F@EX01.swan.local> Message-ID: <201405042341.00712.mark.tinka@seacom.mu> On Saturday, May 03, 2014 07:24:24 PM Vitkovský Adam wrote: > Sure it's a different transport protocol altogether, > anyways It's interesting to see how everybody tends to > separate the IPv4 and IPv6 AFs onto a different TCP > sessions and still run the plethora of other AFs on the > common v4 TCP session, maybe apart from couple of the > big folks, who can afford running separate control-plane > and edge infrastructure for some of the AFs, IPv6 AF > being the first ran separately. We run separate AF's for each family-type, i.e., IPv4 separate from IPv6, separate from VPNv4 separate from BGP- based VPLS, e.t.c. 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 adam.vitkovsky at swan.sk Mon May 5 07:27:37 2014 From: adam.vitkovsky at swan.sk (=?iso-8859-2?Q?Vitkovsk=FD_Adam?=) Date: Mon, 5 May 2014 07:27:37 +0000 Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)] In-Reply-To: <201405042337.06575.mark.tinka@seacom.mu> References: <20140503092627.GR13966@besserwisser.org> <201405042337.06575.mark.tinka@seacom.mu> Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B011E9BEB@EX01.swan.local> > > Ideally, we would have a solution where an entire MPLS infrastructure > > could be built without v4 space, demoting > > v4 to a legacy application inside a VRF, but the MPLS standards wg > > seems content with status quo. > > There is work ongoing in the MPLS IETF WG on identifying the gaps that > various MPLS applications have so they can be prepared for IPv6 MPLS > control and data planes. > > Long overdue, if you ask me, but at least it's starting to get some attention. > > Mark. You mean the SR right? adam From mark.tinka at seacom.mu Mon May 5 07:34:01 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 5 May 2014 09:34:01 +0200 Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)] In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B011E9BEB@EX01.swan.local> References: <201405042337.06575.mark.tinka@seacom.mu> <61DC6BC4ABA10E4489D4A73EBABAC18B011E9BEB@EX01.swan.local> Message-ID: <201405050934.01315.mark.tinka@seacom.mu> On Monday, May 05, 2014 09:27:37 AM Vitkovský Adam wrote: > You mean the SR right? No, I mean: draft-george-mpls-ipv6-only-gap-05 The draft looks at issues that need to be fixed for MPLS to run in a single-stack IPv6 network. Of course, there is other work that is looking at fixing LDPv6 as well, as you know. At the recent MPLS SDN Congress in Paris, I asked some folk about leveraging SR to push native IPv6 support into MPLS, but they didn't seem like that was a key application yet. So while SR is promising, I think it's not a solution for this particular use-case yet. 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 a.harrowell at gmail.com Mon May 5 11:11:17 2014 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Mon, 5 May 2014 12:11:17 +0100 Subject: What Net Neutrality should and should not cover In-Reply-To: References: <20140427203005.4853.qmail@joyce.lan> <53668D9C.4030700@thefnf.org> Message-ID: On Sun, May 4, 2014 at 8:25 PM, William Herrin wrote: > On Sun, May 4, 2014 at 2:57 PM, Charles N Wyble wrote: >> On 4/27/2014 3:30 PM, John Levine wrote: >>> In a non-stupid world, the cable companies would do video on demand >>> through some combination of content caches at the head end or, for >>> popular stuff, encrypted midnight downloads to your DVR, and the >>> cablecos would split the revenue with content backends like Netflix. >> >> >> So why hasn't someone like he or cogent done this? > > Because 30 years later the big content owners still hate VCRs. > Streaming doesn't bother them so much but they avail themselves of > every opportunity to say no to the end-user recorded content. > > This is hardly a surprise... A century later they still hate the first > sale doctrine too and avail themselves of every opportunity to > undermine it. This UKNOF presentation gives another reason - the distribution of demand for content is such that "content bundling", i.e. pro-active push of content to users' machines based on predicted demand, doesn't provide much benefit compared to "historical cache", i.e. caching in the usual sense. https://indico.uknof.org.uk/materialDisplay.py?contribId=20&materialId=slides&confId=30 > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From clayton at MNSi.Net Mon May 5 13:09:37 2014 From: clayton at MNSi.Net (Clayton Zekelman) Date: Mon, 05 May 2014 09:09:37 -0400 Subject: CLEC and FTTP H.248/Megaco In-Reply-To: <5365840F.9030001@vaxination.ca> References: <5365840F.9030001@vaxination.ca> Message-ID: <1399295378_62215@surgemail.mnsi.net> We currently use MGCP on our ONTs. The configuration file is downloaded at boot, and contains the IP address of the our switch. In theory, the IP address could be set in the configuration file to point to a different service provider on a per ONT basis. Unbundling of FTTH access is still going to be painful. I would suspect the ILEC would demand that their ONT be used. This could lead to interop issues. If I were asking for unbundled FTTH, I'd probably want to run my own OLT, and have my own (or ILEC supplied, but designated) splitter in the ILEC cabinet. I would then lease feeder fibre from a POI to the splitter cabinet, then fibre subloops to the customer. The problem becomes that if too many competitors want access to the same cabinet, there is the possibility that there may not be enough room or feeder fibres. At 08:04 PM 03/05/2014, Jean-Francois Mezei wrote: >If the protocol is such that it does not permit co-existance, then a >debate on wholesale voice access is moot. If the protocol does permit >it, then providing soe form of evidence (either existing implementations >or pointer to specs that show this was explicitely designed into the >architecture) would be of great help. --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From jmcleod at musfiber.net Mon May 5 13:59:40 2014 From: jmcleod at musfiber.net (Joe McLeod) Date: Mon, 5 May 2014 13:59:40 +0000 Subject: CLEC and FTTP H.248/Megaco In-Reply-To: <1399295378_62215@surgemail.mnsi.net> References: <5365840F.9030001@vaxination.ca> <1399295378_62215@surgemail.mnsi.net> Message-ID: It would probably be simplest to allow the operator to run the physical network and provide the CLEC's access to service provisioning on that network. Thanks, Joe McLeod MUS FiberNET www.musfiber.com 919 Jarnigan Avenue, Morristown TN 37815 O: 423-317-6276 jmcleod at musfiber.net -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Clayton Zekelman Sent: Monday, May 05, 2014 9:10 AM To: Jean-Francois Mezei; nanog at nanog.org Subject: Re: CLEC and FTTP H.248/Megaco We currently use MGCP on our ONTs. The configuration file is downloaded at boot, and contains the IP address of the our switch. In theory, the IP address could be set in the configuration file to point to a different service provider on a per ONT basis. Unbundling of FTTH access is still going to be painful. I would suspect the ILEC would demand that their ONT be used. This could lead to interop issues. If I were asking for unbundled FTTH, I'd probably want to run my own OLT, and have my own (or ILEC supplied, but designated) splitter in the ILEC cabinet. I would then lease feeder fibre from a POI to the splitter cabinet, then fibre subloops to the customer. The problem becomes that if too many competitors want access to the same cabinet, there is the possibility that there may not be enough room or feeder fibres. At 08:04 PM 03/05/2014, Jean-Francois Mezei wrote: >If the protocol is such that it does not permit co-existance, then a >debate on wholesale voice access is moot. If the protocol does permit >it, then providing soe form of evidence (either existing >implementations or pointer to specs that show this was explicitely >designed into the >architecture) would be of great help. --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From cfp at ruxcon.org.au Mon May 5 10:17:03 2014 From: cfp at ruxcon.org.au (cfp at ruxcon.org.au) Date: Mon, 5 May 2014 20:17:03 +1000 (EST) Subject: Ruxcon 2014 Call For Papers Message-ID: <20140505101703.E6704E89D@ruxcon.org.au> Ruxcon 2014 Call For Presentations Melbourne, Australia, October 11th-12th http://www.ruxcon.org.au The Ruxcon team is pleased to announce the Call For Presentations for Ruxcon 2014. This year the conference will take place over the weekend of the 11th and 12th of October at the CQ Function Centre, Melbourne, Australia. .[x]. About Ruxcon .[x]. Ruxcon brings together the individual talents of the best and brightest security folk in the region, through live presentations, activities, and demonstrations. The con is held over two days in a relaxed atmosphere, allowing delegates to enjoy themselves whilst networking within the community and expanding their knowledge. Live presentations and activities will cover a full range of defensive and offensive security topics, varying from previously unpublished research to required reading for the security community. .[x]. Important Dates .[x]. May 1st - Call For Presentations Open September 30th - Call For Presentations Close October 6-7 - Ruxcon/Breakpoint Training October 8-9 - Breakpoint Conference October 11-12 - Ruxcon Conference .[x]. Topic Scope .[x]. o Topics of interest include, but are not limited to: o Mobile Device Security o Virtualization, Hypervisor, and Cloud Security o Malware Analysis o Reverse Engineering o Exploitation Techniques o Rootkit Development o Code Analysis o Forensics and Anti-Forensics o Embedded Device Security o Web Application Security o Network Traffic Analysis o Wireless Network Security o Cryptography and Cryptanalysis o Social Engineering o Law Enforcement Activities o Telecommunications Security (SS7, 3G/4G, GSM, VOIP, etc) .[x]. Submission Guidelines .[x]. In order for us to process your submission we require the following information: 1. Presentation title 2. Detailed summary of your presentation material 3. Name/Nickname 4. Mobile phone number 5. Brief personal biography 6. Description of any demonstrations involved in the presentation 7. Information on where the presentation material has or will be presented before Ruxcon * As a general guideline, Ruxcon presentations are between 45 and 60 minutes, including question time. If you have any enquiries about submissions, or would like to make a submission, please send an email to presentations at ruxcon.org.au .[x]. Contact .[x]. o Email: submissions at ruxcon.org.au o Twitter: @ruxcon From betty at newnog.org Mon May 5 17:15:28 2014 From: betty at newnog.org (Betty Burke ) Date: Mon, 5 May 2014 13:15:28 -0400 Subject: [NANOG-announce] NANOG Event Updates Message-ID: NANOGers: A few reminders regarding upcoming NANOG Events: - NANOG ON THE Road - LA is fast approaching, Tuesday, May 20, 2014. If you have not yet registered for this free one day event, consider doing so now. The agenda is now posted, the day is sure to be of value to all. If you know of someone local and not on the NANOG list, please pass along this information. - NANOG Education Classes in Bellevue, will be held on Sunday, June 1, 2014. Two classes will be offered, Routing Fundamentals, and IPv6 Routing Fundamentals. The classes will help prepare students for transition into current world operations of the Internet. If you know of someone who would benefit from the NANOG experience offered, please pass along this information. - Lastly, NANOG 61 in Bellevue is a few weeks away, June 2-4, 2014. The NANOG 61 Highlights page provides an over-view of what attendees should expect while attending the meeting. The NANOG Program Committee has been hard at work building another outstanding program. The Pre-agenda and Topics page is available and the full agenda will be posted soon. - The NANOG 61 meeting Registration fee will increase on Monday, May 12, 2014, and the NANOG Hotel Block will expire on Friday, May 16, 2014. If you have not yet registered, or made your room reservation, consider doing so this week! - NANOG 61 Fellowships are available. If you or a colleague are interested in attending NANOG 61 and need some travel assistance, please do consider applying. - Consider having your company join the growing number of NANOG 61 Sponsors in Bellevue. A few Sponsorship opportunities remain. If you are not currently a NANOG member , do consider joining the 556 NANOGers who find value in being a part of the NANOG governance process, joining is easy . Should you have any questions about NANOG, please do not hesitate to contact nanog-support at nanog.org or feel free to contact me directly. Sincerely, Betty -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 www.nanog.org -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From me at staticsafe.ca Mon May 5 17:37:57 2014 From: me at staticsafe.ca (staticsafe) Date: Mon, 05 May 2014 13:37:57 -0400 Subject: Observations of an Internet Middleman Message-ID: <5367CC75.10301@staticsafe.ca> http://blog.level3.com/global-connectivity/observations-internet-middleman/ -- staticsafe https://asininetech.com From rs at seastrom.com Mon May 5 19:42:04 2014 From: rs at seastrom.com (Rob Seastrom) Date: Mon, 05 May 2014 15:42:04 -0400 Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)] In-Reply-To: (Randy Bush's message of "Sun, 04 May 2014 07:18:21 +0200") References: <20140503092627.GR13966@besserwisser.org> Message-ID: <86ppjsf1wz.fsf@valhalla.seastrom.com> Randy Bush writes: >> Ah, so you're in the camp that a /10 given to one organization for >> their private use would have been better than reserving that /10 for >> _everyone_ to use. We'll have to agree to disagree there. > > you forced an rfc allocation. that makes public space, and is and will > be used as such. you wanted an 'owned' allocation that you and your > friends control, you shoulda gone to the rirs. Usually I manage to keep the Strangelove hand in check and not feed the troll, but the matter was raised (at least in the ARIN region). https://www.arin.net/policy/proposals/2011_5.html I believe that the arguments that shared transition space were IETF's purview were compelling. I'm no fan of non-globally-unique space in general, but forcing the RFC route was the least-worst route for things to move forward. Randy, I trust that you're also vigorously advocating people's use of UK-MOD-19850128 (aka net 25) as "just more 1918 space" inside their organizations too? After all, it's what I encourage *my* competitors to do. -r From andris at hpl.hp.com Mon May 5 21:08:30 2014 From: andris at hpl.hp.com (Andris Kalnozols) Date: Mon, 05 May 2014 14:08:30 -0700 Subject: Paging HP DNS admin In-Reply-To: References: <5364EED5.1000801@amplex.net> <53659FA1.9010107@amplex.net> <20140504031351.GC12342@cmadams.net> Message-ID: <5367FDCE.6090101@hpl.hp.com> On 5/3/2014 9:10 PM, Christopher Morrow wrote: > On Sat, May 3, 2014 at 11:13 PM, Chris Adams wrote: >> Once upon a time, Christopher Morrow said: ... >> Oddly, it seems to be specific to AAAA; any other type request I send >> comes back NOERROR correctly. It is like somebody tried to handle AAAA >> "special" and screwed it up. > > I remember nytimes doing something like this for a while, I believe > they said their GSLB was just not happy doing AAAA, or if not > configured would display similar behaviour. Thanks for reporting this. I passed it on to the corp-IT people and the issue appears to be fixed. The problem was that someone forgot to override the F5 default of *NOT* enabling a NODATA/NOERROR response for AAAA queries. I have no idea why an opt-in would be required for proper interoperability with RFC 1034 from 1987. Then again, I have zero experience with operating a load balancer appliance. ------ Andris From marka at isc.org Mon May 5 23:32:44 2014 From: marka at isc.org (Mark Andrews) Date: Tue, 06 May 2014 09:32:44 +1000 Subject: Paging HP DNS admin In-Reply-To: Your message of "Mon, 05 May 2014 14:08:30 -0700." <5367FDCE.6090101@hpl.hp.com> References: <5364EED5.1000801@amplex.net> <53659FA1.9010107@amplex.net> <20140504031351.GC12342@cmadams.net> <5367FDCE.6090101@hpl.hp.com> Message-ID: <20140505233244.E4FC11536F0F@rock.dv.isc.org> In message <5367FDCE.6090101 at hpl.hp.com>, Andris Kalnozols writes: > On 5/3/2014 9:10 PM, Christopher Morrow wrote: > > On Sat, May 3, 2014 at 11:13 PM, Chris Adams wrote: > >> Once upon a time, Christopher Morrow said: > ... > >> Oddly, it seems to be specific to AAAA; any other type request I send > >> comes back NOERROR correctly. It is like somebody tried to handle AAAA > >> "special" and screwed it up. > > > > I remember nytimes doing something like this for a while, I believe > > they said their GSLB was just not happy doing AAAA, or if not > > configured would display similar behaviour. > > Thanks for reporting this. I passed it on to the corp-IT people and > the issue appears to be fixed. The problem was that someone forgot > to override the F5 default of *NOT* enabling a NODATA/NOERROR response > for AAAA queries. I have no idea why an opt-in would be required for > proper interoperability with RFC 1034 from 1987. Then again, I have > zero experience with operating a load balancer appliance. > > ------ > Andris Can you please log a bug report with F5 about the defaults. It should answer all queries unless a backing nameserver has been configured. It should also sanity check the negative responses to ensure that they have the correct SOA record from the backing server but that is another issue. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From deepak at ai.net Mon May 5 23:59:06 2014 From: deepak at ai.net (Deepak Jain) Date: Mon, 5 May 2014 23:59:06 +0000 Subject: Residential CPE suggestions Message-ID: <40937dc98c534dd4b59987f320026f22@AINET-EX13-S02.ainet.local> Any recommendation for a residential CPE that supports dual SFP uplinks (WAN) with either a routing protocol or a resilient Ethernet solution? Ideally, LAN port should be 100/1000 CAT5. I've looking at Mikrotik, Draytek and others. Looking something in a lower three-digit price point. Otherwise I might have to do a pair of media converters on a copper switch/router that can do it (ugly!). Thanks in advance! DJ From gary.buhrmaster at gmail.com Tue May 6 00:13:34 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Tue, 6 May 2014 00:13:34 +0000 Subject: Residential CPE suggestions In-Reply-To: <40937dc98c534dd4b59987f320026f22@AINET-EX13-S02.ainet.local> References: <40937dc98c534dd4b59987f320026f22@AINET-EX13-S02.ainet.local> Message-ID: On Mon, May 5, 2014 at 11:59 PM, Deepak Jain wrote: > > Any recommendation for a residential CPE that supports dual SFP uplinks (WAN) with either a routing protocol or a resilient Ethernet solution? Ideally, LAN port should be 100/1000 CAT5. I've looking at Mikrotik, Draytek and others. Looking something in a lower three-digit price point. Otherwise I might have to do a pair of media converters on a copper switch/router that can do it (ugly!). > > Thanks in advance! (No personal experience, but...) Have you looked at the EdgeRouter Pro? 2 SFP links, routing capability. http://www.ubnt.com/edgemax From goemon at anime.net Mon May 5 23:50:59 2014 From: goemon at anime.net (goemon at anime.net) Date: Mon, 5 May 2014 16:50:59 -0700 (PDT) Subject: linkedin.com abuse admins around? Message-ID: If there is anyone from linkedin.com abuse around please let me know. I've been trying for 2 months to get an abuse issue resolved. -Dan From seitz at bsd-unix.net Tue May 6 00:27:00 2014 From: seitz at bsd-unix.net (Bryan Seitz) Date: Mon, 5 May 2014 20:27:00 -0400 Subject: Residential CPE suggestions In-Reply-To: References: <40937dc98c534dd4b59987f320026f22@AINET-EX13-S02.ainet.local> Message-ID: <20140506002700.GA4335@bsd-unix.net> On Tue, May 06, 2014 at 12:13:34AM +0000, Gary Buhrmaster wrote: > On Mon, May 5, 2014 at 11:59 PM, Deepak Jain wrote: > > > > Any recommendation for a residential CPE that supports dual SFP uplinks (WAN) with either a routing protocol or a resilient Ethernet solution? Ideally, LAN port should be 100/1000 CAT5. I've looking at Mikrotik, Draytek and others. Looking something in a lower three-digit price point. Otherwise I might have to do a pair of media converters on a copper switch/router that can do it (ugly!). > > > > Thanks in advance! > > (No personal experience, but...) > > Have you looked at the EdgeRouter Pro? 2 SFP links, > routing capability. http://www.ubnt.com/edgemax +1, hands down one of the better platforms for the money today. I have 3 ERLites in service and I know the pro is obviously a larger more powerful version so you should have pretty good success. -- Bryan G. Seitz From joe at nethead.com Tue May 6 01:26:55 2014 From: joe at nethead.com (Joe Hamelin) Date: Mon, 5 May 2014 18:26:55 -0700 Subject: linkedin.com abuse admins around? In-Reply-To: References: Message-ID: On Mon, May 5, 2014 at 4:50 PM, wrote: > If there is anyone from linkedin.com abuse around please let me know. > I've been trying for 2 months to get an abuse issue resolved. > That's not abuse, that's a feature. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From wbn at DrPeering.net Tue May 6 03:42:06 2014 From: wbn at DrPeering.net (wbn) Date: Mon, 5 May 2014 20:42:06 -0700 Subject: Reviewers needed: How Internet Peering Improves Security Message-ID: <75DD1F03-0B98-4420-B33F-F4886BDB488C@DrPeering.net> Hi fellow NANOGers - I recently spent some time with peering coordinators at industry events (NANOG, EPF, AFPIF, UKNOF, etc.) where I asked “How does Internet Peering affect Internet Security?” The result of this exercise is a white paper, currently in its draft 4-page form, entitled “How Internet Peering Improves Security.” What I need now are a handful of people that are interested in this subject and willing to let me talk through the draft in order to solicit direct feedback. If interested, please send email to wbn at DrPeering.net with subject: "Review How Internet Peering Improves Security" and I will reach out to schedule some time. Thanks in advance - Bill PS - Here is the abstract to help you decide if you are interested in helping me document this for the community, and yes, as usual, I will be happy to share the resulting white paper with anyone interested. How Internet Peering Improves Security William B. Norton Abstract Denial-of-Service attacks continue to flood the Internet at increasing scale. They attack specific targets, while, as a side affect, disrupt any traffic that traverses the network attack paths. During these attacks, impacted Internet users may experience intermittent problems, such as video freeze frames, garbled audio during phone or Skype calls, or error messages indicating that their Internet cloud service is unavailable. The ubiquitous and open nature of the Internet is both its value and its downfall. All one needs for access to cloud storage systems (DropBox, Box.net, etc.) is an Internet connection. This also means that attackers need only a few thousand broadband computers, infected with viruses and taken over as zombies, to exploit this open Internet ecosystem and overwhelm even the most robust Internet services. The attacks are not predictable in time, scope, or scale, and the impacts are far reaching, well beyond the source and destinations of the attacks. For these reason, the commodity Internet may not suitable for a subset of Internet applications. For example, some enterprise mission-critical applications require consistency simply unavailable from today’s Internet Transit services. There is however a well-known interconnection approach that improves this situation: an interconnection technique call “Internet Peering.“ This paper will introduce Internet Peering and discuss how Internet security is improved simply by using this common interconnection technique. From cryptographrix at gmail.com Tue May 6 00:14:52 2014 From: cryptographrix at gmail.com (Cryptographrix) Date: Mon, 5 May 2014 20:14:52 -0400 Subject: Residential CPE suggestions In-Reply-To: <40937dc98c534dd4b59987f320026f22@AINET-EX13-S02.ainet.local> References: <40937dc98c534dd4b59987f320026f22@AINET-EX13-S02.ainet.local> Message-ID: I've used both the Ubiquiti EdgeRouter and Cisco RV042G. The EdgeRouter runs a modified version of Vyatta that's incredibly versatile. The RV042G is your standard Cisco SOHO Dual-WAN router - it has telnet, but is limited, and otherwise is solid. On Mon, May 5, 2014 at 7:59 PM, Deepak Jain wrote: > > Any recommendation for a residential CPE that supports dual SFP uplinks > (WAN) with either a routing protocol or a resilient Ethernet solution? > Ideally, LAN port should be 100/1000 CAT5. I've looking at Mikrotik, > Draytek and others. Looking something in a lower three-digit price point. > Otherwise I might have to do a pair of media converters on a copper > switch/router that can do it (ugly!). > > Thanks in advance! > > DJ > From refresh.lsong at gmail.com Tue May 6 03:58:58 2014 From: refresh.lsong at gmail.com (Song Li) Date: Tue, 06 May 2014 11:58:58 +0800 Subject: bgp convergence problem Message-ID: <53685E02.7060309@gmail.com> Hi everyone, I have one bgp convergence problem which confused me. The problem is as follows: +--------+ | AS5 | +------+16.1/16 | | +-----+--+ | | +---+--+ | | AS4 | | | | | ++-----+ | | | | | | | +-----+--+ +-+-----+ | AS2 | | AS3 | 16.1/16 (5) | ISP | | ISP | +---^----+ +---^---+ | | | +--------+ | +-----+ AS1 +----+ |customer| +--------+ 16.1/16 (2 4 5) AS1 multihomed to AS2 and AS3, for some reasons AS1 disconnect from AS3, and as a resutl the route to 16.1/16 will be 16.1/16 (2 4 5). After a while, the BGP seesion between AS1 and AS3 reestablished but AS1 leaks the route 16.1/16 (2 4 5) to AS3. At this point, 1/ AS1 will have two bgp routes for prefix 16.1/16: 16.1/16(2 4 5)and 16.1/16(3 5), according to shorter AS_PATH it will select 16.1/16(3 5) as best route. 2/ AS3 also have two bgp routes: 16.1/16(2 4 5) and 16.1/16(5), according to local_pref it will select 16.1/16(2 4 5). in this case, AS1 and AS3 select each other as the best route to AS5, i wonder which route will be the final best route after bgp convergence in AS1 and AS3. Thanks! -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.lsong at gmail.com From mrp at mrp.net Tue May 6 04:41:36 2014 From: mrp at mrp.net (Mark Prior) Date: Tue, 06 May 2014 14:11:36 +0930 Subject: AusNOG 2014 Call for Presentations Message-ID: <53686800.10109@mrp.net> Call for presentations for AusNOG 2014 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Swissotel Sydney 4 & 5 September 2014 Topics =-=-=- Internet operations can be a broad topic and the programme committee will be short-listing presentations in the following focus areas: * Improving the redundancy/resiliency/sustainability of your network * Making leaps in service or network availability * Taking the network operations BCP to the next level * Using 'offline' communications tools to keep the network working * How technology is changing network architectures * Evolution in network architectures and scaling issues * Analysis of relevant major operational events of the year This year we will be reintroducing a "Peering Forum". In this part of the programme we hope to include: * Peering related talks * Peering personals from various networks * IX updates Additional topics that are of interest to the network operator community are also welcome at AusNOG 2014. Naturally, presentations of a marketing nature are not welcome at this technical event. Notes to presenters =-=-=-=-=-=-=-=-=-= Preference will be given to presentations that result in actual operational outcomes. Session speakers should be prepared to present for 30 minutes. Keynote speakers will be expected to present for 45 minutes to 1 hour. Short presentations of strong operational content are also acceptable. Once the final slides are submitted, changes will only be permitted where the presentation requires the most up to date information or data. By submitting a presentation for consideration in the AusNOG 2014 programme, and if selected the presenter will allow AusNOG to: * Take photographs of the presentation and presenter * Record and rebroadcast video and audio of the presentation and presenter * Redistribute the presentation slides, audio, video, and photographs electronically, on the AusNOG website, or otherwise but leaving all intellectual property in the hands of presenter or rightful property holder[1]. Deadlines =-=-=-=-= 09 June: Submission of presentation title, presentation description (300 words), and presenter biography (200-400 words) 04 July: Presenters notified of their acceptance status as an AusNOG 2014 presentation. 27 August: Submission of final presentation slides as Portable Document Format (pdf), PowerPoint, or Keynote. Provision of a recent digital photograph (<500k) of the presenter. All submissions must be sent to organisers at ausnog.net. A separate call for lightning talks will be made closer to the AusNOG 2014 event. As in previous years you must be registered to attend AusNOG 2014 in order to be considered for a lightning talk. [1]: AusNOG accepts that some speakers are unable to allow us to archive their presentation due to company or corporate policy, and if the situation arises AusNOG will delete all copies in its possession after the presentation. Mark. For the AusNOG Board From hb-nanog at bsws.de Tue May 6 07:22:37 2014 From: hb-nanog at bsws.de (Henning Brauer) Date: Tue, 6 May 2014 09:22:37 +0200 Subject: US patent 5473599 In-Reply-To: <535C1D57.2040506@foobar.org> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> Message-ID: <20140506072237.GI30611@quigon.bsws.de> * Nick Hilliard [2014-04-26 22:56]: > the situation was created by the openbsd team, not the ieee, the ietf or > iana. that's nothing short of a lie. > The openbsd foundation raised $153,000 this year. Why not invest $2500 of > this and fix the problem? good luck finding another project of our size running on such a small budget. how about putting your money where your mouth is? this is all open source. when you don't like something or see a problem, there are always two options: 1) whine which doesn't change anything 2) work out a solution -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting From rajiva at cisco.com Tue May 6 09:23:17 2014 From: rajiva at cisco.com (Rajiv Asati (rajiva)) Date: Tue, 6 May 2014 09:23:17 +0000 Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)] In-Reply-To: <20140503092627.GR13966@besserwisser.org> References: , <20140503092627.GR13966@besserwisser.org> Message-ID: <9CDEE261-48B8-492D-BA94-A38E9E8124FC@cisco.com> > inside a VRF, but the MPLS standards wg seems content with status quo. http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6 The WG is pretty close to wrap this up (back to the 3rd WGLC very soon). But frankly admitting, dual-stacking facilitated more issues than I expected early on. Cheers, Rajiv > On May 3, 2014, at 5:29 AM, "Måns Nilsson" wrote: > > Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)] Date: Fri, May 02, 2014 at 03:58:42PM -0600 Quoting Chris Grundemann (cgrundemann at gmail.com): > >> Would you expound a bit on what you mean here? I don't quite follow but I >> am very interested to understand the issue. > > The fact that you need v4 space to build a MPLS backbone is a very good > reason to not waste a /10 on CGN crap. > > Ideally, we would have a solution where an entire MPLS infrastructure > could be built without v4 space, demoting v4 to a legacy application > inside a VRF, but the MPLS standards wg seems content with status quo. > > -- > Måns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE +46 705 989668 > I wish I was a sex-starved manicurist found dead in the Bronx!! From rajiva at cisco.com Tue May 6 09:27:09 2014 From: rajiva at cisco.com (Rajiv Asati (rajiva)) Date: Tue, 6 May 2014 09:27:09 +0000 Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)] In-Reply-To: <201405050934.01315.mark.tinka@seacom.mu> References: <201405042337.06575.mark.tinka@seacom.mu> <61DC6BC4ABA10E4489D4A73EBABAC18B011E9BEB@EX01.swan.local>, <201405050934.01315.mark.tinka@seacom.mu> Message-ID: <3435ED71-4C64-4D0F-870F-37899F1C2138@cisco.com> Mark, > about leveraging SR to push native IPv6 support into MPLS, Segment routing (SR) could/would certainly work with single-stack v6 and enable MPLS forwarding. Cheers, Rajiv > On May 5, 2014, at 3:36 AM, "Mark Tinka" wrote: > >> On Monday, May 05, 2014 09:27:37 AM Vitkovský Adam wrote: >> >> You mean the SR right? > > No, I mean: > > draft-george-mpls-ipv6-only-gap-05 > > The draft looks at issues that need to be fixed for MPLS to > run in a single-stack IPv6 network. > > Of course, there is other work that is looking at fixing > LDPv6 as well, as you know. > > At the recent MPLS SDN Congress in Paris, I asked some folk > about leveraging SR to push native IPv6 support into MPLS, > but they didn't seem like that was a key application yet. So > while SR is promising, I think it's not a solution for this > particular use-case yet. > > Mark. From mark.tinka at seacom.mu Tue May 6 09:34:12 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 6 May 2014 11:34:12 +0200 Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)] In-Reply-To: <3435ED71-4C64-4D0F-870F-37899F1C2138@cisco.com> References: <201405050934.01315.mark.tinka@seacom.mu> <3435ED71-4C64-4D0F-870F-37899F1C2138@cisco.com> Message-ID: <201405061134.12525.mark.tinka@seacom.mu> On Tuesday, May 06, 2014 11:27:09 AM Rajiv Asati (rajiva) wrote: > Segment routing (SR) could/would certainly work with > single-stack v6 and enable MPLS forwarding. Certainly, but based on the Paris meeting, it was not high up on the agenda. So we will, likely, have to rely on other solutions and wait for SR to catch up later. At the moment, it seems SR is being pushed hard for PCEP as well as SDN. 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 nanog at isp-services.nl Tue May 6 10:13:16 2014 From: nanog at isp-services.nl (ISP Services) Date: Tue, 06 May 2014 12:13:16 +0200 Subject: bgp convergence problem In-Reply-To: <53685E02.7060309@gmail.com> References: <53685E02.7060309@gmail.com> Message-ID: <5368B5BC.4050200@isp-services.nl> Hi Song Li, As far as I know there are 2 mechanisms that should prevent this situation you describe from happening: - Not advertising routes that are not in the RIB Once AS1's peering with AS3 comes back up, the route through AS3 is learned and preferred. Therefore the route via AS2 is purged from the RIB. Once it is no longer in the RIB, AS1 cannot announce that path anymore. - AS Path loop prevention If AS1 still leaks the prefix to AS3, it can only announce the active path which points to AS3 itself. Therefore AS3 will see a prefix with its own ASN in the path and (should) drop the prefix. Crisis avoided. My textbook knowledge is a bit rusty though.. Dennis Hagens Song Li schreef op 5/6/14 5:58 AM: > Hi everyone, > > I have one bgp convergence problem which confused me. The problem is as > follows: > > +--------+ > | AS5 | > +------+16.1/16 | > | +-----+--+ > | | > +---+--+ | > | AS4 | | > | | | > ++-----+ | > | | > | | > | | > +-----+--+ +-+-----+ > | AS2 | | AS3 | 16.1/16 (5) > | ISP | | ISP | > +---^----+ +---^---+ > | | > | +--------+ | > +-----+ AS1 +----+ > |customer| > +--------+ > 16.1/16 (2 4 5) > > AS1 multihomed to AS2 and AS3, for some reasons AS1 disconnect from AS3, > and as a resutl the route to 16.1/16 will be 16.1/16 (2 4 5). > > After a while, the BGP seesion between AS1 and AS3 reestablished but > AS1 leaks the route 16.1/16 (2 4 5) to AS3. At this point, > > 1/ AS1 will have two bgp routes for prefix 16.1/16: 16.1/16(2 4 5)and > 16.1/16(3 5), according to shorter AS_PATH it will select 16.1/16(3 5) > as best route. > > 2/ AS3 also have two bgp routes: 16.1/16(2 4 5) and 16.1/16(5), > according to local_pref it will select 16.1/16(2 4 5). > > in this case, AS1 and AS3 select each other as the best route to AS5, i > wonder which route will be the final best route after bgp convergence in > AS1 and AS3. > > Thanks! > From adam.vitkovsky at swan.sk Tue May 6 10:50:39 2014 From: adam.vitkovsky at swan.sk (=?iso-8859-2?Q?Vitkovsk=FD_Adam?=) Date: Tue, 6 May 2014 10:50:39 +0000 Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)] In-Reply-To: <201405061134.12525.mark.tinka@seacom.mu> References: <201405050934.01315.mark.tinka@seacom.mu> <3435ED71-4C64-4D0F-870F-37899F1C2138@cisco.com> <201405061134.12525.mark.tinka@seacom.mu> Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B011EA264@EX01.swan.local> > From: Mark Tinka [mailto:mark.tinka at seacom.mu] > > On Tuesday, May 06, 2014 11:27:09 AM Rajiv Asati (rajiva) > wrote: > > > Segment routing (SR) could/would certainly work with single-stack v6 > > and enable MPLS forwarding. > > Certainly, but based on the Paris meeting, it was not high up on the agenda. > > So we will, likely, have to rely on other solutions and wait for SR to catch up > later. > > At the moment, it seems SR is being pushed hard for PCEP as well as SDN. > > Mark. I think the most revolutionary SR use case is the: 3.2. Protecting a node segment upon the failure of its advertising node. Of the now expired: draft-filsfils-rtgwg-segment-routing-use-cases-02. It's the first, complete and elegant FRR solution for the hierarchical MPLS implementations. adam From jared at puck.nether.net Tue May 6 11:16:30 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 6 May 2014 07:16:30 -0400 Subject: Residential CPE suggestions In-Reply-To: References: <40937dc98c534dd4b59987f320026f22@AINET-EX13-S02.ainet.local> Message-ID: I was also going to recommend the EdgeRouter Pro as it has dual SFP ports and the Vyatta/Linux stuff works quite well. I suspect you will be very surprised with the quality experience. If you've not used Vyatta, it's very JunOS-like. - Jared On May 5, 2014, at 8:14 PM, Cryptographrix wrote: > I've used both the Ubiquiti EdgeRouter and Cisco RV042G. > > The EdgeRouter runs a modified version of Vyatta that's incredibly > versatile. > > The RV042G is your standard Cisco SOHO Dual-WAN router - it has telnet, but > is limited, and otherwise is solid. > > > > > On Mon, May 5, 2014 at 7:59 PM, Deepak Jain wrote: > >> >> Any recommendation for a residential CPE that supports dual SFP uplinks >> (WAN) with either a routing protocol or a resilient Ethernet solution? >> Ideally, LAN port should be 100/1000 CAT5. I've looking at Mikrotik, >> Draytek and others. Looking something in a lower three-digit price point. >> Otherwise I might have to do a pair of media converters on a copper >> switch/router that can do it (ugly!). >> >> Thanks in advance! >> >> DJ >> From jgreco at ns.sol.net Tue May 6 07:01:33 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 6 May 2014 02:01:33 -0500 (CDT) Subject: Residential CPE suggestions In-Reply-To: Message-ID: <201405060701.s4671Xp4067636@aurora.sol.net> > I was also going to recommend the EdgeRouter Pro as it has dual SFP = > ports and the Vyatta/Linux stuff works quite well. > > I suspect you will be very surprised with the quality experience. If = > you've not used Vyatta, it's very JunOS-like. Does anyone have any practical experience with the EdgeRouter with a largish number of prefixes? http://dl.ubnt.com/datasheets/edgemax/EdgeRouter_DS.pdf The "2 million+ packets per second" leads me to believe that this is merely a highly optimized software based router, but under "Hardware Specs" it specifically says "hardware acceleration for packet processing". I have no idea what's being accelerated since the "layer 3 forwarding performance" specs for the FR-8 are 2Mpps (an 800MHz CPU) and the FRPro-8 are 2.4Mpps (1GHz) which suggests software lookup. Do these things suffer if you load them down with a full table? Or a handful of firewall rules? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From refresh.lsong at gmail.com Tue May 6 11:42:08 2014 From: refresh.lsong at gmail.com (Song Li) Date: Tue, 06 May 2014 19:42:08 +0800 Subject: bgp convergence problem In-Reply-To: <5368B5BC.4050200@isp-services.nl> References: <53685E02.7060309@gmail.com> <5368B5BC.4050200@isp-services.nl> Message-ID: <5368CA90.7020102@gmail.com> Hi Dennis, I think there are two possible convergence results: 1/ AS3 accepted route 16.1/16(2 4 5) from AS1, then it will withdraw announce of 16.1/16(5) towards AS1. And AS1 will remain 16.1/16 (2 4 5). 2/ AS1 accepted route 16.1/16(3 5) from AS3, then it withdraw 16.1/16(2 4 5), and AS3 will remain 16.1/16(5). I simulated this case in GNS3, and only got the first kind of result, i don't know why? Song 于 2014/5/6 18:13, ISP Services 写道: > Hi Song Li, > > As far as I know there are 2 mechanisms that should prevent this > situation you describe from happening: > > - Not advertising routes that are not in the RIB > Once AS1's peering with AS3 comes back up, the route through AS3 is > learned and preferred. Therefore the route via AS2 is purged from the > RIB. Once it is no longer in the RIB, AS1 cannot announce that path > anymore. > > - AS Path loop prevention > If AS1 still leaks the prefix to AS3, it can only announce the active > path which points to AS3 itself. Therefore AS3 will see a prefix with > its own ASN in the path and (should) drop the prefix. Crisis avoided. > > My textbook knowledge is a bit rusty though.. > > Dennis Hagens > > Song Li schreef op 5/6/14 5:58 AM: >> Hi everyone, >> >> I have one bgp convergence problem which confused me. The problem is as >> follows: >> >> +--------+ >> | AS5 | >> +------+16.1/16 | >> | +-----+--+ >> | | >> +---+--+ | >> | AS4 | | >> | | | >> ++-----+ | >> | | >> | | >> | | >> +-----+--+ +-+-----+ >> | AS2 | | AS3 | 16.1/16 (5) >> | ISP | | ISP | >> +---^----+ +---^---+ >> | | >> | +--------+ | >> +-----+ AS1 +----+ >> |customer| >> +--------+ >> 16.1/16 (2 4 5) >> >> AS1 multihomed to AS2 and AS3, for some reasons AS1 disconnect from AS3, >> and as a resutl the route to 16.1/16 will be 16.1/16 (2 4 5). >> >> After a while, the BGP seesion between AS1 and AS3 reestablished but >> AS1 leaks the route 16.1/16 (2 4 5) to AS3. At this point, >> >> 1/ AS1 will have two bgp routes for prefix 16.1/16: 16.1/16(2 4 5)and >> 16.1/16(3 5), according to shorter AS_PATH it will select 16.1/16(3 5) >> as best route. >> >> 2/ AS3 also have two bgp routes: 16.1/16(2 4 5) and 16.1/16(5), >> according to local_pref it will select 16.1/16(2 4 5). >> >> in this case, AS1 and AS3 select each other as the best route to AS5, i >> wonder which route will be the final best route after bgp convergence in >> AS1 and AS3. >> >> Thanks! >> > > -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.lsong at gmail.com From bedard.phil at gmail.com Tue May 6 12:08:17 2014 From: bedard.phil at gmail.com (bedard.phil at gmail.com) Date: Tue, 6 May 2014 08:08:17 -0400 Subject: Residential CPE suggestions In-Reply-To: <201405060701.s4671Xp4067636@aurora.sol.net> References: <201405060701.s4671Xp4067636@aurora.sol.net> Message-ID: <5368d0b9.040fec0a.1146.1424@mx.google.com> It uses a Cavium Octeon processor which does have dedicated HW packet processing. A moderate number of prefixes won't slow it down doing vanilla forwarding, not sure about 2 million though... I believe they have recently optimized some of the FW stuff to take advantage of the HW as well. Layering services like FW, NAT, and tunneling definitely drops the packet rate significantly, but it is still capable of 100+Mbps at IMIX packet sizes. I think there are a couple of in depth tests out there. In my experience the ERL works really well for a $99 device. Phil -----Original Message----- From: "Joe Greco" Sent: ‎5/‎6/‎2014 7:39 AM To: "jared at puck.nether.net (Jared Mauch)" Cc: "NANOG" Subject: Re: Residential CPE suggestions > I was also going to recommend the EdgeRouter Pro as it has dual SFP = > ports and the Vyatta/Linux stuff works quite well. > > I suspect you will be very surprised with the quality experience. If = > you've not used Vyatta, it's very JunOS-like. Does anyone have any practical experience with the EdgeRouter with a largish number of prefixes? http://dl.ubnt.com/datasheets/edgemax/EdgeRouter_DS.pdf The "2 million+ packets per second" leads me to believe that this is merely a highly optimized software based router, but under "Hardware Specs" it specifically says "hardware acceleration for packet processing". I have no idea what's being accelerated since the "layer 3 forwarding performance" specs for the FR-8 are 2Mpps (an 800MHz CPU) and the FRPro-8 are 2.4Mpps (1GHz) which suggests software lookup. Do these things suffer if you load them down with a full table? Or a handful of firewall rules? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From cryptographrix at gmail.com Tue May 6 12:47:25 2014 From: cryptographrix at gmail.com (Cryptographrix) Date: Tue, 6 May 2014 08:47:25 -0400 Subject: Residential CPE suggestions In-Reply-To: <201405060701.s4671Xp4067636@aurora.sol.net> References: <201405060701.s4671Xp4067636@aurora.sol.net> Message-ID: It also has support for some type of ipv4 and ipv6 offload. On Tue, May 6, 2014 at 3:01 AM, Joe Greco wrote: > > I was also going to recommend the EdgeRouter Pro as it has dual SFP = > > ports and the Vyatta/Linux stuff works quite well. > > > > I suspect you will be very surprised with the quality experience. If = > > you've not used Vyatta, it's very JunOS-like. > > Does anyone have any practical experience with the EdgeRouter with a > largish number of prefixes? > > http://dl.ubnt.com/datasheets/edgemax/EdgeRouter_DS.pdf > > The "2 million+ packets per second" leads me to believe that this is > merely a highly optimized software based router, but under "Hardware > Specs" it specifically says "hardware acceleration for packet > processing". > > I have no idea what's being accelerated since the "layer 3 forwarding > performance" specs for the FR-8 are 2Mpps (an 800MHz CPU) and the > FRPro-8 are 2.4Mpps (1GHz) which suggests software lookup. > > Do these things suffer if you load them down with a full table? Or > a handful of firewall rules? > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] > then I > won't contact you again." - Direct Marketing Ass'n position on e-mail > spam(CNN) > With 24 million small businesses in the US alone, that's way too many > apples. > From nanog at isp-services.nl Tue May 6 12:54:57 2014 From: nanog at isp-services.nl (ISP Services) Date: Tue, 06 May 2014 14:54:57 +0200 Subject: bgp convergence problem In-Reply-To: <5368CA90.7020102@gmail.com> References: <53685E02.7060309@gmail.com> <5368B5BC.4050200@isp-services.nl> <5368CA90.7020102@gmail.com> Message-ID: <5368DBA1.3080007@isp-services.nl> I suggest you work your way down :-) http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html Dennis Hagens Song Li schreef op 5/6/14 1:42 PM: > Hi Dennis, > > I think there are two possible convergence results: > > 1/ AS3 accepted route 16.1/16(2 4 5) from AS1, then it will withdraw > announce of 16.1/16(5) towards AS1. And AS1 will remain 16.1/16 (2 4 5). > > 2/ AS1 accepted route 16.1/16(3 5) from AS3, then it withdraw 16.1/16(2 > 4 5), and AS3 will remain 16.1/16(5). > > I simulated this case in GNS3, and only got the first kind of result, i > don't know why? > > Song > > 于 2014/5/6 18:13, ISP Services 写道: >> Hi Song Li, >> >> As far as I know there are 2 mechanisms that should prevent this >> situation you describe from happening: >> >> - Not advertising routes that are not in the RIB >> Once AS1's peering with AS3 comes back up, the route through AS3 is >> learned and preferred. Therefore the route via AS2 is purged from the >> RIB. Once it is no longer in the RIB, AS1 cannot announce that path >> anymore. >> >> - AS Path loop prevention >> If AS1 still leaks the prefix to AS3, it can only announce the active >> path which points to AS3 itself. Therefore AS3 will see a prefix with >> its own ASN in the path and (should) drop the prefix. Crisis avoided. >> >> My textbook knowledge is a bit rusty though.. >> >> Dennis Hagens >> >> Song Li schreef op 5/6/14 5:58 AM: >>> Hi everyone, >>> >>> I have one bgp convergence problem which confused me. The problem is as >>> follows: >>> >>> +--------+ >>> | AS5 | >>> +------+16.1/16 | >>> | +-----+--+ >>> | | >>> +---+--+ | >>> | AS4 | | >>> | | | >>> ++-----+ | >>> | | >>> | | >>> | | >>> +-----+--+ +-+-----+ >>> | AS2 | | AS3 | 16.1/16 (5) >>> | ISP | | ISP | >>> +---^----+ +---^---+ >>> | | >>> | +--------+ | >>> +-----+ AS1 +----+ >>> |customer| >>> +--------+ >>> 16.1/16 (2 4 5) >>> >>> AS1 multihomed to AS2 and AS3, for some reasons AS1 disconnect from AS3, >>> and as a resutl the route to 16.1/16 will be 16.1/16 (2 4 5). >>> >>> After a while, the BGP seesion between AS1 and AS3 reestablished but >>> AS1 leaks the route 16.1/16 (2 4 5) to AS3. At this point, >>> >>> 1/ AS1 will have two bgp routes for prefix 16.1/16: 16.1/16(2 4 5)and >>> 16.1/16(3 5), according to shorter AS_PATH it will select 16.1/16(3 5) >>> as best route. >>> >>> 2/ AS3 also have two bgp routes: 16.1/16(2 4 5) and 16.1/16(5), >>> according to local_pref it will select 16.1/16(2 4 5). >>> >>> in this case, AS1 and AS3 select each other as the best route to AS5, i >>> wonder which route will be the final best route after bgp convergence in >>> AS1 and AS3. >>> >>> Thanks! >>> >> >> > > From Valdis.Kletnieks at vt.edu Tue May 6 14:52:00 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 06 May 2014 10:52:00 -0400 Subject: bgp convergence problem In-Reply-To: Your message of "Tue, 06 May 2014 11:58:58 +0800." <53685E02.7060309@gmail.com> References: <53685E02.7060309@gmail.com> Message-ID: <5300.1399387920@turing-police.cc.vt.edu> On Tue, 06 May 2014 11:58:58 +0800, Song Li said: > I have one bgp convergence problem which confused me. The problem is as > follows: You may want to Google for 'BGP Wedgie'. https://www.nanog.org/meetings/nanog31/presentations/griffin.pdf http://www.rfc-base.org/txt/rfc-4264.txt Once you understand how and why they happen, your routing question will become clear. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Tue May 6 14:56:50 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 06 May 2014 10:56:50 -0400 Subject: US patent 5473599 In-Reply-To: Your message of "Tue, 06 May 2014 09:22:37 +0200." <20140506072237.GI30611@quigon.bsws.de> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> Message-ID: <5573.1399388210@turing-police.cc.vt.edu> On Tue, 06 May 2014 09:22:37 +0200, Henning Brauer said: > * Nick Hilliard [2014-04-26 22:56]: > > the situation was created by the openbsd team, not the ieee, the ietf or > > iana. > > that's nothing short of a lie. Umm.. remind me who chose the conflicting value and shipped product that used it, when they knew (or should have known) that it would be in conflict? I'd almost accept an assertion that the issue wasn't recognized as a problem, or was believed to be a hypothetical that wouldn't happen in the real world. But trying to deny who picked the number doesn't help the situation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From tony.li at tony.li Tue May 6 15:19:12 2014 From: tony.li at tony.li (Tony Li) Date: Tue, 6 May 2014 08:19:12 -0700 Subject: US patent 5473599 In-Reply-To: <535C1D57.2040506@foobar.org> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> Message-ID: On Apr 26, 2014, at 1:55 PM, Nick Hilliard wrote: > the situation was created by the openbsd team, not the ieee, the ietf or > iana. You squatted on an existing oui assignment used by an equivalent > protocol and in doing this, you created a long term problem with no > possible solution other than to change carp to use its own dedicated range > instead of someone else's. > > You had every choice in the world about what range to use and even if you > didn't have the $2500 at the time to register a perpetual OUI assignment, > almost any other OUI in existence would have been less detrimental to users > than the one you chose. > > The openbsd foundation raised $153,000 this year. Why not invest $2500 of > this and fix the problem? Sorry this is late… Might I suggest an even simpler and cheaper solution? Cisco has widely and repeatedly claimed that they will only use their patents defensively. Why not have someone on behalf of *BSD simply write them a letter/email requesting a royalty-free license to the patent for use in *BSD? Play up the non-profit and non-competitive angles. If they agree, then you can freely implement HSRP or VRRP directly. If they refuse, then you’re no worse off than you were before. The guy with his name on the patent, Tony From randy at psg.com Tue May 6 15:27:03 2014 From: randy at psg.com (Randy Bush) Date: Tue, 06 May 2014 17:27:03 +0200 Subject: bgp convergence problem In-Reply-To: <53685E02.7060309@gmail.com> References: <53685E02.7060309@gmail.com> Message-ID: > I have one bgp convergence problem which confused me. The problem is as > follows: > > +--------+ > | AS5 | > +------+16.1/16 | > | +-----+--+ > | | > +---+--+ | > | AS4 | | > | | | > ++-----+ | > | | > | | > | | > +-----+--+ +-+-----+ > | AS2 | | AS3 | 16.1/16 (5) > | ISP | | ISP | > +---^----+ +---^---+ > | | > | +--------+ | > +-----+ AS1 +----+ > |customer| > +--------+ > 16.1/16 (2 4 5) > > AS1 multihomed to AS2 and AS3, for some reasons AS1 disconnect from AS3, > and as a resutl the route to 16.1/16 will be 16.1/16 (2 4 5). > > After a while, the BGP seesion between AS1 and AS3 reestablished but > AS1 leaks the route 16.1/16 (2 4 5) to AS3. At this point, > > 1/ AS1 will have two bgp routes for prefix 16.1/16: 16.1/16(2 4 5)and > 16.1/16(3 5), according to shorter AS_PATH it will select 16.1/16(3 5) > as best route. > > 2/ AS3 also have two bgp routes: 16.1/16(2 4 5) and 16.1/16(5), > according to local_pref it will select 16.1/16(2 4 5). > > in this case, AS1 and AS3 select each other as the best route to AS5, i > wonder which route will be the final best route after bgp convergence in > AS1 and AS3. this is a bgp wedgie. is it real and caught in the wild? tim would be cheered. randy From drew.weaver at thenap.com Tue May 6 15:39:13 2014 From: drew.weaver at thenap.com (Drew Weaver) Date: Tue, 6 May 2014 15:39:13 +0000 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. Message-ID: Hi all, I am wondering if maybe we should make some kind of concerted effort to remind folks about the IPv4 routing table inching closer and closer to the 512K route mark. We are at about 94/95% right now of 512K. For most of us, the 512K route mark is arbitrary but for a lot of folks who may still be running 6500/7600 or other routers which are by default configured to crash and burn after 512K routes; it may be a valuable public service. Even if you don't have this scenario in your network today; chances are you connect to someone who connects to someone who connects to someone (etc...) that does. In case anyone wants to check on a 6500, you can run: show platform hardware capacity pfc and then look under L3 Forwarding Resources. Just something to think about before it becomes a story the community talks about for the next decade. -Drew From nick at foobar.org Tue May 6 16:11:22 2014 From: nick at foobar.org (Nick Hilliard) Date: Tue, 06 May 2014 17:11:22 +0100 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: Message-ID: <536909AA.3000205@foobar.org> On 06/05/2014 16:39, Drew Weaver wrote: > In case anyone wants to check on a 6500, you can run: show platform > hardware capacity pfc and then look under L3 Forwarding Resources. to fix the problem on sup720/rsp720: > Router(config)#mls cef maximum-routes ip 768 This requires a reload to take effect. If you don't recarve the TCAM and you accidentally hit the maximum number of prefixes, the entire chassis will go into software forwarding mode and will require a reboot to recover. IOW, there is no way of avoiding a reload, so best plan as soon as possible. More info here: > http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/116132-problem-catalyst6500-00.html This problem also affects ASR9000 boxes running typhoon line cards which by default will only set aside 500k slots for ipv4 prefixes. The fix for these boxes is: > 0/RSP0/CPU0:router# admin hw-module profile scale l3 ...followed by appropriate line card reloads. more information at: > http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-aggregation-services-routers/116999-problem-line-card-00.html Nick From jlewis at lewis.org Tue May 6 16:14:40 2014 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 6 May 2014 12:14:40 -0400 (EDT) Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: Message-ID: On Tue, 6 May 2014, Drew Weaver wrote: > Hi all, > > I am wondering if maybe we should make some kind of concerted effort to remind folks about the IPv4 routing table inching closer and closer to the 512K route mark. > > We are at about 94/95% right now of 512K. > > For most of us, the 512K route mark is arbitrary but for a lot of folks who may still be running 6500/7600 or other routers which are by default configured to crash and burn after 512K routes; it may be a valuable public service. > > Even if you don't have this scenario in your network today; chances are you connect to someone who connects to someone who connects to someone (etc...) that does. > > In case anyone wants to check on a 6500, you can run: show platform hardware capacity pfc and then look under L3 Forwarding Resources. > > Just something to think about before it becomes a story the community talks about for the next decade. I've been configuring 6500/Sup7203bxl's with mls cef maximum-routes ip 768 The only gotcha is, you have to reload for that to be effective. Speaking of which, I've had WS-X6708-10GE cards "go bad on reload" in a couple of 6500s. I see cisco finally released some more info on their "bad memory" announcement from several months back: http://www.cisco.com/c/en/us/support/docs/field-notices/637/fn63743.html It seems our "gone bad" 6708s may be included in this issue. If you don't have enough spare ports or spare cards, this puts you in a somewhat precarious situation. You need to reload to affect the v4/v6 route storage change, but you might lose some blades in the process. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jeff-kell at utc.edu Tue May 6 16:30:58 2014 From: jeff-kell at utc.edu (Jeff Kell) Date: Tue, 6 May 2014 12:30:58 -0400 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: Message-ID: <53690E42.9000305@utc.edu> On 5/6/2014 11:39 AM, Drew Weaver wrote: > Hi all, > > I am wondering if maybe we should make some kind of concerted effort to remind folks about the IPv4 routing table inching closer and closer to the 512K route mark. > > We are at about 94/95% right now of 512K. > > For most of us, the 512K route mark is arbitrary but for a lot of folks who may still be running 6500/7600 or other routers which are by default configured to crash and burn after 512K routes; it may be a valuable public service. Yes, a Sup720/PFC3CXL defaults to 512K IPv4 routes, and reconfiguring the FIB requires a reload. So I've been quietly expecting a somewhat serious meltdown when we hit 512K :) Jeff From vristevs at ramapo.edu Tue May 6 16:35:43 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Tue, 06 May 2014 12:35:43 -0400 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: Message-ID: <53690F5F.1050801@ramapo.edu> It would probably be a good time to upgrade the memory on my 7206 NPE-G1 as well (512MB). I was going to replace the router but am going to keep it around for the Fall Semester. Anyone know of any good 3rd party memory modules that are equivalent to the MEM-NPE-G1-1GB? I got a quote for the official Cisco ones last summer and it was around $5,000 lol On 5/6/2014 11:39 AM, Drew Weaver wrote: > Hi all, > > I am wondering if maybe we should make some kind of concerted effort to remind folks about the IPv4 routing table inching closer and closer to the 512K route mark. > > We are at about 94/95% right now of 512K. > > For most of us, the 512K route mark is arbitrary but for a lot of folks who may still be running 6500/7600 or other routers which are by default configured to crash and burn after 512K routes; it may be a valuable public service. > > Even if you don't have this scenario in your network today; chances are you connect to someone who connects to someone who connects to someone (etc...) that does. > > In case anyone wants to check on a 6500, you can run: show platform hardware capacity pfc and then look under L3 Forwarding Resources. > > Just something to think about before it becomes a story the community talks about for the next decade. > > -Drew > Vlad From drew.weaver at thenap.com Tue May 6 17:01:05 2014 From: drew.weaver at thenap.com (Drew Weaver) Date: Tue, 6 May 2014 17:01:05 +0000 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: <536909AA.3000205@foobar.org> References: <536909AA.3000205@foobar.org> Message-ID: -----Original Message----- From: Nick Hilliard [mailto:nick at foobar.org] Sent: Tuesday, May 6, 2014 12:11 PM To: Drew Weaver; 'nanog at nanog.org' Subject: Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. This problem also affects ASR9000 boxes running typhoon line cards which by default will only set aside 500k slots for ipv4 prefixes. The fix for these boxes is: >>> I believe you mean "This problem also affects ASR9000 boxes running ...trident... line cards". Please confirm? -Drew From nick at foobar.org Tue May 6 17:04:35 2014 From: nick at foobar.org (Nick Hilliard) Date: Tue, 06 May 2014 18:04:35 +0100 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: <536909AA.3000205@foobar.org> Message-ID: <53691623.1000006@foobar.org> On 06/05/2014 18:01, Drew Weaver wrote: > I believe you mean "This problem also affects ASR9000 boxes running > ...trident... line cards". Please confirm? er, yes, trident cards, not typhoon cards. typhoon cards are not affected by this. Nick From szmetal at gmail.com Tue May 6 17:30:46 2014 From: szmetal at gmail.com (Shawn Zandi) Date: Tue, 6 May 2014 10:30:46 -0700 Subject: linkedin.com abuse admins around? In-Reply-To: References: Message-ID: Dan, You can contact me offline, I'll connect you with postmasters. -Shawn On Mon, May 5, 2014 at 4:50 PM, wrote: > If there is anyone from linkedin.com abuse around please let me know. > I've been trying for 2 months to get an abuse issue resolved. > > -Dan > From bedard.phil at gmail.com Tue May 6 17:34:35 2014 From: bedard.phil at gmail.com (bedard.phil at gmail.com) Date: Tue, 6 May 2014 13:34:35 -0400 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: References: Message-ID: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> I would like to see Cisco send something out... -----Original Message----- From: "Drew Weaver" Sent: ‎5/‎6/‎2014 11:42 AM To: "'nanog at nanog.org'" Subject: Getting pretty close to default IPv4 route maximum for 6500/7600routers. Hi all, I am wondering if maybe we should make some kind of concerted effort to remind folks about the IPv4 routing table inching closer and closer to the 512K route mark. We are at about 94/95% right now of 512K. For most of us, the 512K route mark is arbitrary but for a lot of folks who may still be running 6500/7600 or other routers which are by default configured to crash and burn after 512K routes; it may be a valuable public service. Even if you don't have this scenario in your network today; chances are you connect to someone who connects to someone who connects to someone (etc...) that does. In case anyone wants to check on a 6500, you can run: show platform hardware capacity pfc and then look under L3 Forwarding Resources. Just something to think about before it becomes a story the community talks about for the next decade. -Drew From wbailey at satelliteintelligencegroup.com Tue May 6 17:35:06 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 6 May 2014 17:35:06 +0000 Subject: linkedin.com abuse admins around? In-Reply-To: References: , Message-ID: Tell them to stop emailing us for their free trial while you're at it! ;) Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Shawn Zandi Date: 05/06/2014 11:33 AM (GMT-07:00) To: goemon at anime.net Cc: NANOG list Subject: Re: linkedin.com abuse admins around? Dan, You can contact me offline, I'll connect you with postmasters. -Shawn On Mon, May 5, 2014 at 4:50 PM, wrote: > If there is anyone from linkedin.com abuse around please let me know. > I've been trying for 2 months to get an abuse issue resolved. > > -Dan > From mureninc at gmail.com Tue May 6 18:54:53 2014 From: mureninc at gmail.com (Constantine A. Murenin) Date: Tue, 6 May 2014 11:54:53 -0700 Subject: US patent 5473599 In-Reply-To: <5573.1399388210@turing-police.cc.vt.edu> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> Message-ID: On 6 May 2014 07:56, wrote: > On Tue, 06 May 2014 09:22:37 +0200, Henning Brauer said: >> * Nick Hilliard [2014-04-26 22:56]: >> > the situation was created by the openbsd team, not the ieee, the ietf or >> > iana. >> >> that's nothing short of a lie. > > Umm.. remind me who chose the conflicting value and shipped product that used > it, when they knew (or should have known) that it would be in conflict? > > I'd almost accept an assertion that the issue wasn't recognized as a problem, > or was believed to be a hypothetical that wouldn't happen in the real world. > But trying to deny who picked the number doesn't help the situation. The situation is actually very clearly documented in the commentary to OpenBSD 3.5 release song on the web-site: http://www.openbsd.org/lyrics.html#35 Let me quote some excerpts: >>>> As free software programmers, we therefore find ourselves in the position that these RAND standards must not be implemented by us, and we must deviate from the standard. We find all this rather Unreasonable and Discriminatory and we *will* design competing protocols. Some standards organization, eh? >>>> On August 7 2002, after many communications, Robert Barr (Cisco's lawyer) firmly informed the OpenBSD community that Cisco would defend its patents for VRRP implementations -- meaning basically that it was impossible for a free software group to produce a truly free implementation of the IETF standard protocol. >>>> We read the patent document carefully and ensured that CARP was fundamentally different. We also avoided many of the flaws in HSRP and VRRP (such as an inherent lack of security). And since we are OpenBSD developers, we designed it to use cryptography. >>>> To date, we have built a few networks that include as many as 4 firewalls, all running random reboot cycles. As long as one firewall is alive in a group, traffic through them moves smoothly and correctly for all of our packet filter functionality. Cisco's low end products are unable to do this reliably, and if they have high end products which can do this, you most certainly cannot afford them. >>>> As a final note of course, when we petitioned IANA, the IETF body regulating "official" internet protocol numbers, to give us numbers for CARP and pfsync our request was denied. Apparently we had failed to go through an official standards organization. Consequently we were forced to choose a protocol number which would not conflict with anything else of value, and decided to place CARP at IP protocol 112. We also placed pfsync at an open and unused number. We informed IANA of these decisions, but they declined to reply. Frankly, I don't really see what the huge loss is. Perhaps people should realise that OpenBSD has recently removed The Heartbeat Extension from TLS in libssl, and boycott the upcoming LibreSSL, since its likelihood of having another heartbleed has been so reduced, yet the API is still compatible with OpenSSL. ??? C. From mianosm at gmail.com Tue May 6 13:02:02 2014 From: mianosm at gmail.com (Steven Miano) Date: Tue, 6 May 2014 09:02:02 -0400 Subject: Residential CPE suggestions In-Reply-To: References: <201405060701.s4671Xp4067636@aurora.sol.net> Message-ID: You could also go Supermicro, and build out a 1U with SFP/Copper connections and put VyOS/vyatta as a linux based routing platform.... ....going that way you'll be strictly CPU/software bound though (Intel wrote up this interesting report: http://www.csit-sun.pub.ro/~cpop/Documentatie_SM/Intel_Microprocessor_Systems/Intel_ProcessorNew/Intel%20White%20Paper/Integrating%20Services%20at%20the%20Edge%20for%20Intel%20Xeon%205500.pdfwhich is no longer available on their site seemingly). Totally built out you'd be looking at high triple digits (the SFP PCIe card and chassis/motherboard would be your biggest hits). On Tue, May 6, 2014 at 8:47 AM, Cryptographrix wrote: > It also has support for some type of ipv4 and ipv6 offload. > > > > On Tue, May 6, 2014 at 3:01 AM, Joe Greco wrote: > > > > I was also going to recommend the EdgeRouter Pro as it has dual SFP = > > > ports and the Vyatta/Linux stuff works quite well. > > > > > > I suspect you will be very surprised with the quality experience. If = > > > you've not used Vyatta, it's very JunOS-like. > > > > Does anyone have any practical experience with the EdgeRouter with a > > largish number of prefixes? > > > > http://dl.ubnt.com/datasheets/edgemax/EdgeRouter_DS.pdf > > > > The "2 million+ packets per second" leads me to believe that this is > > merely a highly optimized software based router, but under "Hardware > > Specs" it specifically says "hardware acceleration for packet > > processing". > > > > I have no idea what's being accelerated since the "layer 3 forwarding > > performance" specs for the FR-8 are 2Mpps (an 800MHz CPU) and the > > FRPro-8 are 2.4Mpps (1GHz) which suggests software lookup. > > > > Do these things suffer if you load them down with a full table? Or > > a handful of firewall rules? > > > > ... JG > > -- > > Joe Greco - sol.net Network Services - Milwaukee, WI - > http://www.sol.net > > "We call it the 'one bite at the apple' rule. Give me one chance [and] > > then I > > won't contact you again." - Direct Marketing Ass'n position on e-mail > > spam(CNN) > > With 24 million small businesses in the US alone, that's way too many > > apples. > > > -- Miano, Steven M. http://stevenmiano.com From synack at live.com Tue May 6 15:55:35 2014 From: synack at live.com (Darin) Date: Tue, 6 May 2014 10:55:35 -0500 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. Message-ID: And since those puppies are going to need a reload after adjustment make sure your not exposed to the component decay issue for cards manufactured between 2005-2010 or you could have a interesting night. We've hit that issue on three different 7600 chassis. Darin -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Drew Weaver Sent: Tuesday, May 06, 2014 10:39 AM To: 'nanog at nanog.org' Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. Hi all, I am wondering if maybe we should make some kind of concerted effort to remind folks about the IPv4 routing table inching closer and closer to the 512K route mark. We are at about 94/95% right now of 512K. For most of us, the 512K route mark is arbitrary but for a lot of folks who may still be running 6500/7600 or other routers which are by default configured to crash and burn after 512K routes; it may be a valuable public service. Even if you don't have this scenario in your network today; chances are you connect to someone who connects to someone who connects to someone (etc...) that does. In case anyone wants to check on a 6500, you can run: show platform hardware capacity pfc and then look under L3 Forwarding Resources. Just something to think about before it becomes a story the community talks about for the next decade. -Drew From surfer at mauigateway.com Tue May 6 19:31:07 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 6 May 2014 12:31:07 -0700 Subject: Residential CPE suggestions Message-ID: <20140506123107.4466177D@m0005297.ppops.net> --- gary.buhrmaster at gmail.com wrote: From: Gary Buhrmaster On Mon, May 5, 2014 at 11:59 PM, Deepak Jain wrote: > > Any recommendation for a residential CPE that supports dual > SFP uplinks Have you looked at the EdgeRouter Pro? 2 SFP links, routing capability. http://www.ubnt.com/edgemax ----------------------------------------------- It looks like everyone here should start looking for a new career: "Next-generation user experience allows anyone to quickly become a routing expert." ;-) scott From drc at virtualized.org Tue May 6 19:31:38 2014 From: drc at virtualized.org (David Conrad) Date: Tue, 6 May 2014 12:31:38 -0700 Subject: US patent 5473599 In-Reply-To: References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> Message-ID: <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> Constantine, On May 6, 2014, at 11:54 AM, Constantine A. Murenin wrote: >>>>> As a final note of course, when we petitioned IANA, the IETF body regulating "official" internet protocol numbers, to give us numbers for CARP and pfsync our request was denied. Apparently we had failed to go through an official standards organization. Yes. The 8-bit IP protocol field is assigned by IANA according to "IESG Approval or Standards Action". >>>>> Consequently we were forced to choose a protocol number which would not conflict with anything else of value, and decided to place CARP at IP protocol 112. Protocol 112 was assigned by IANA for VRRP in 1998. When did OpenBSD choose to squat on 112? >>>>> We also placed pfsync at an open and unused number. We informed IANA of these decisions, but they declined to reply. I would imagine the reply was "IANA does not have discretion to assign those values, they are assigned by IESG or via a standards action." Indeed, IP protocol 240 is not yet allocated. Presumably the OpenBSD community expects everyone else to acknowledge the squatting on 240. > Frankly, I don't really see what the huge loss is. Not surprising. > Perhaps people > should realise that OpenBSD has recently removed The Heartbeat > Extension from TLS in libssl, and boycott the upcoming LibreSSL, since > its likelihood of having another heartbleed has been so reduced, yet > the API is still compatible with OpenSSL. ??? Sorry, the relationship between OpenBSD developers intentionally and childishly squatting on a protocol number and OpenBSD developers hacking apart OpenSSL is what exactly? 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 alumbis at gmail.com Tue May 6 19:48:04 2014 From: alumbis at gmail.com (Pete Lumbis) Date: Tue, 6 May 2014 15:48:04 -0400 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600routers. In-Reply-To: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> References: <53691d35.9215ec0a.5f2c.6e04@mx.google.com> Message-ID: There is currently a doc for the ASR9k. We're working on getting on for 6500 as well. http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-aggregation-services-routers/116999-problem-line-card-00.html On Tue, May 6, 2014 at 1:34 PM, wrote: > I would like to see Cisco send something out... > > -----Original Message----- > From: "Drew Weaver" > Sent: ‎5/‎6/‎2014 11:42 AM > To: "'nanog at nanog.org'" > Subject: Getting pretty close to default IPv4 route maximum for > 6500/7600routers. > > Hi all, > > I am wondering if maybe we should make some kind of concerted effort to > remind folks about the IPv4 routing table inching closer and closer to the > 512K route mark. > > We are at about 94/95% right now of 512K. > > For most of us, the 512K route mark is arbitrary but for a lot of folks > who may still be running 6500/7600 or other routers which are by default > configured to crash and burn after 512K routes; it may be a valuable public > service. > > Even if you don't have this scenario in your network today; chances are > you connect to someone who connects to someone who connects to someone > (etc...) that does. > > In case anyone wants to check on a 6500, you can run: show platform > hardware capacity pfc and then look under L3 Forwarding Resources. > > Just something to think about before it becomes a story the community > talks about for the next decade. > > -Drew > > From mureninc at gmail.com Tue May 6 20:15:45 2014 From: mureninc at gmail.com (Constantine A. Murenin) Date: Tue, 6 May 2014 13:15:45 -0700 Subject: US patent 5473599 In-Reply-To: <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> Message-ID: On 6 May 2014 12:31, David Conrad wrote: > Constantine, > > On May 6, 2014, at 11:54 AM, Constantine A. Murenin wrote: >>>>>> As a final note of course, when we petitioned IANA, the IETF body regulating "official" internet protocol numbers, to give us numbers for CARP and pfsync our request was denied. Apparently we had failed to go through an official standards organization. > > Yes. The 8-bit IP protocol field is assigned by IANA according to "IESG Approval or Standards Action". > >>>>>> Consequently we were forced to choose a protocol number which would not conflict with anything else of value, and decided to place CARP at IP protocol 112. > > Protocol 112 was assigned by IANA for VRRP in 1998. > > When did OpenBSD choose to squat on 112? If you don't use it, you lose it. > >>>>>> We also placed pfsync at an open and unused number. We informed IANA of these decisions, but they declined to reply. > > I would imagine the reply was "IANA does not have discretion to assign those values, they are assigned by IESG or via a standards action." Indeed, IP protocol 240 is not yet allocated. Presumably the OpenBSD community expects everyone else to acknowledge the squatting on 240. > >> Frankly, I don't really see what the huge loss is. > > Not surprising. > >> Perhaps people >> should realise that OpenBSD has recently removed The Heartbeat >> Extension from TLS in libssl, and boycott the upcoming LibreSSL, since >> its likelihood of having another heartbleed has been so reduced, yet >> the API is still compatible with OpenSSL. ??? > > > Sorry, the relationship between OpenBSD developers intentionally and childishly squatting on a protocol number and OpenBSD developers hacking apart OpenSSL is what exactly? This all has been discussed ad nauseam over the years, in every possible forum, many times over again. There are only so many protocol numbers; out of those potentially available and non-conflicting, it was deemed the best choice to go with the protocol number that was guaranteed to be useless otherwise. Any complaints for Google using the https port 443 for SPDY? C. From rs at seastrom.com Tue May 6 20:20:03 2014 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 06 May 2014 16:20:03 -0400 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: <53690F5F.1050801@ramapo.edu> (Vlade Ristevski's message of "Tue, 06 May 2014 12:35:43 -0400") References: <53690F5F.1050801@ramapo.edu> Message-ID: <86bnvay80c.fsf@valhalla.seastrom.com> I just recently got four sets off eBay. Purportedly genuine Cisco. A shade over $100. Raid the departmental beer fund. :) -r Vlade Ristevski writes: > It would probably be a good time to upgrade the memory on my 7206 > NPE-G1 as well (512MB). I was going to replace the router but am going > to keep it around for the Fall Semester. Anyone know of any good 3rd > party memory modules that are equivalent to the MEM-NPE-G1-1GB? I got > a quote for the official Cisco ones last summer and it was around > $5,000 lol > > On 5/6/2014 11:39 AM, Drew Weaver wrote: >> Hi all, >> >> I am wondering if maybe we should make some kind of concerted effort to remind folks about the IPv4 routing table inching closer and closer to the 512K route mark. >> >> We are at about 94/95% right now of 512K. >> >> For most of us, the 512K route mark is arbitrary but for a lot of folks who may still be running 6500/7600 or other routers which are by default configured to crash and burn after 512K routes; it may be a valuable public service. >> >> Even if you don't have this scenario in your network today; chances are you connect to someone who connects to someone who connects to someone (etc...) that does. >> >> In case anyone wants to check on a 6500, you can run: show platform hardware capacity pfc and then look under L3 Forwarding Resources. >> >> Just something to think about before it becomes a story the community talks about for the next decade. >> >> -Drew >> > Vlad From cb.list6 at gmail.com Tue May 6 22:04:45 2014 From: cb.list6 at gmail.com (Ca By) Date: Tue, 6 May 2014 15:04:45 -0700 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: Message-ID: On May 6, 2014 12:32 PM, "Darin" wrote: > > And since those puppies are going to need a reload after adjustment make sure your not exposed to the component decay issue for cards manufactured between 2005-2010 or you could have a interesting night. > > We've hit that issue on three different 7600 chassis. > > Darin > You are not the only one, major manufacturing defects... http://www.cisco.com/go/memory > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Drew Weaver > > Sent: Tuesday, May 06, 2014 10:39 AM > > To: 'nanog at nanog.org' > > Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 > routers. > > > > Hi all, > > > > I am wondering if maybe we should make some kind of > concerted effort to remind folks about the IPv4 routing table inching closer > and closer to the 512K route mark. > > > > We are at about 94/95% right now of 512K. > > > > For most of us, the 512K route mark is arbitrary but for > a lot of folks who may still be running 6500/7600 or other routers which are by > default configured to crash and burn after 512K routes; it may be a valuable > public service. > > > > Even if you don't have this scenario in your network > today; chances are you connect to someone who connects to someone who connects > to someone (etc...) that does. > > > > In case anyone wants to check on a 6500, you can > run: show platform hardware capacity pfc > and then look under L3 Forwarding Resources. > > > > Just something to think about before it becomes a story > the community talks about for the next decade. > > > > -Drew > > > From drc at virtualized.org Tue May 6 22:17:58 2014 From: drc at virtualized.org (David Conrad) Date: Tue, 6 May 2014 18:17:58 -0400 Subject: US patent 5473599 In-Reply-To: References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> Message-ID: <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> Constantine, On May 6, 2014, at 4:15 PM, Constantine A. Murenin wrote: >> Protocol 112 was assigned by IANA for VRRP in 1998. >> >> When did OpenBSD choose to squat on 112? > > If you don't use it, you lose it. Are you suggesting no one is running VRRP? Surprising given RFC 5798. By the way, according to Wikipedia, it would seem the OpenBSD developers decided to squat on 112 in 2003, 5 years after 112 was assigned. > There are only so many protocol numbers; out of those potentially > available and non-conflicting, Yes. That is exactly why most responsible and professional developers work with IANA to obtain the assignments they need instead of intentionally squatting on numbers, particularly numbers known to be already assigned. > it was deemed the best choice to go > with the protocol number that was guaranteed to be useless otherwise. Except it wasn't useless: it was, in fact, in use by VRRP. Further, the OpenBSD developers chose to squat on 240 for pfsync - a number that has not yet been allocated. If the OpenBSD developers were so concerned about making the best choice, it seems odd they chose an allocated number for one protocol and an unallocated number for another protocol. To be honest, it would seem from appearances that OpenBSD's use of 112 was deemed a "cute" (that is, unprofessional and irresponsible) way for the OpenBSD developers to say 'screw you' to the IETF, IANA, Cisco, network operators, etc. The fact that OpenBSD developers continue to defend this choice is one reason why I won't run OpenBSD (or CARP). > Any complaints for Google using the https port 443 for SPDY? AFAIK, the use of SPDY does not preclude the use of HTTPS on the same network. The fact that in addition to the OpenBSD developers choosing to use 112, they also chose to use the MAC addresses used for VRRP, thus making it impossible to run both VRRP and CARP on the same network due to MAC address conflicts would suggest you might want to pick a better analogy. 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 LarrySheldon at cox.net Tue May 6 23:01:57 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 06 May 2014 18:01:57 -0500 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: Message-ID: <536969E5.6080608@cox.net> On 5/6/2014 10:39 AM, Drew Weaver wrote: > Just something to think about before it becomes a story the community > talks about for the next decade. Like we have for the last two? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From dhc2 at dcrocker.net Tue May 6 23:16:36 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Tue, 06 May 2014 16:16:36 -0700 Subject: Anternet In-Reply-To: <533FA36D.3090709@trelane.net> References: <533F9825.3090300@cox.net> <533FA36D.3090709@trelane.net> Message-ID: <53696D54.7040307@dcrocker.net> On 4/4/2014 11:32 PM, Andrew D Kirch wrote: > So, if there's more than 4 billion ants... what are they going to do? get larger ants. (and the responses have now covered both pro forma responses.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mureninc at gmail.com Wed May 7 01:11:04 2014 From: mureninc at gmail.com (Constantine A. Murenin) Date: Tue, 6 May 2014 18:11:04 -0700 Subject: US patent 5473599 In-Reply-To: <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> Message-ID: On 6 May 2014 15:17, David Conrad wrote: > Constantine, > > On May 6, 2014, at 4:15 PM, Constantine A. Murenin wrote: >>> Protocol 112 was assigned by IANA for VRRP in 1998. >>> >>> When did OpenBSD choose to squat on 112? >> >> If you don't use it, you lose it. > > Are you suggesting no one is running VRRP? Surprising given RFC 5798. > > By the way, according to Wikipedia, it would seem the OpenBSD developers decided to squat on 112 in 2003, 5 years after 112 was assigned. Your point being? > >> There are only so many protocol numbers; out of those potentially >> available and non-conflicting, > > Yes. That is exactly why most responsible and professional developers work with IANA to obtain the assignments they need instead of intentionally squatting on numbers, particularly numbers known to be already assigned. > >> it was deemed the best choice to go >> with the protocol number that was guaranteed to be useless otherwise. > > Except it wasn't useless: it was, in fact, in use by VRRP. Further, the OpenBSD developers chose to squat on 240 for pfsync - a number that has not yet been allocated. If the OpenBSD developers were so concerned about making the best choice, it seems odd they chose an allocated number for one protocol and an unallocated number for another protocol. Can you explain why exactly do you find this odd? VRRP/HSRP have had only one protocol number allocated to it; it's not like it had two, so, another one had to come out of somewhere else. > > To be honest, it would seem from appearances that OpenBSD's use of 112 was deemed a "cute" (that is, unprofessional and irresponsible) way for the OpenBSD developers to say 'screw you' to the IETF, IANA, Cisco, network operators, etc. The fact that OpenBSD developers continue to defend this choice is one reason why I won't run OpenBSD (or CARP). > >> Any complaints for Google using the https port 443 for SPDY? > > AFAIK, the use of SPDY does not preclude the use of HTTPS on the same network. The fact that in addition to the OpenBSD developers choosing to use 112, they also chose to use the MAC addresses used for VRRP, thus making it impossible to run both VRRP and CARP on the same network due to MAC address conflicts would suggest you might want to pick a better analogy. Well, that's kinda the issue here -- the comparison with SPDY is actually quite valid. I haven't seen any facts that CARP actually precludes you from using VRRP on your network, unless you use broken VRRP/HSRP implementations (BTW, did you thank OpenBSD for forcing Cisco to fix those? or would you rather retain an extra attack vector for your routers?), or configure CARP and VRRP to use the same MAC addresses through the same Virtual ID setting (user error), when clearly a choice is available. On the contrary, it's actually clearly and unambiguously confirmed in this very thread that both could coexist just fine: http://mailman.nanog.org/pipermail/nanog/2014-April/066529.html . So, then the only problem, perhaps, is that noone has apparently bothered to explicitly document that both VRRP and CARP use 00:00:5e:00:01:xx MAC addresses, and that the "xx" part comes from the "Virtual Router IDentifier (VRID)" in VRRP and "virtual host ID (VHID)" in CARP, providing a colliding namespace, so, one cannot run both with the same Virtual ID on the same network segment. Why exactly is this not documented? You could always claim, "politics", and it probably was back then 10 years ago when this story developed; but, in today's reality, OpenBSD is quite well known for its minimalism in all things UNIX, just as Apple in all things visual design. The likelihood of someone mixing CARP and VRRP, on the same network segment / same VLAN, and with the same Virtual IDs, and without ever hearing of the controversies from which CARP had to be born (and being curious of the origins of the "cute" name), seems quite small to me. So, documenting it at this point would be quite pointless, if not only for the future generations or Google reference. So, just as always, much ado about nothing. If someone sends a good documentation patch, without making the change seem out of place, it'll probably be committed into the tree shortly. C. From mysidia at gmail.com Wed May 7 01:12:51 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 6 May 2014 20:12:51 -0500 Subject: Residential CPE suggestions In-Reply-To: <20140506123107.4466177D@m0005297.ppops.net> References: <20140506123107.4466177D@m0005297.ppops.net> Message-ID: On Tue, May 6, 2014 at 2:31 PM, Scott Weeks wrote: I wouldn't worry. A fancy GUI without intelligent engineering and design leveraged is just more rope for everyone to hang themselves with, esp. when something in the GUI inevitably doesn't work quite like it's supposed to. Network vendor GUIs never work 100% like they are supposed to; there's always eventually some bug or another, or limitation requiring some workaround. And IPv6 is a game-changer. > It looks like everyone here should start looking for a new > career: "Next-generation user experience allows anyone to > quickly become a routing expert." > ;-) > scott -- -JH From wmaton at ottix.net Wed May 7 01:27:54 2014 From: wmaton at ottix.net (William F. Maton Sotomayor) Date: Tue, 6 May 2014 21:27:54 -0400 (EDT) Subject: Anternet In-Reply-To: <53696D54.7040307@dcrocker.net> References: <533F9825.3090300@cox.net> <533FA36D.3090709@trelane.net> <53696D54.7040307@dcrocker.net> Message-ID: On Tue, 6 May 2014, Dave Crocker wrote: > On 4/4/2014 11:32 PM, Andrew D Kirch wrote: >> So, if there's more than 4 billion ants... what are they going to do? > > > get larger ants. No, no. The solution is far simpler than that, and would probably give a good example of real-world population control. Just get an ant-eater. > > > (and the responses have now covered both pro forma responses.) > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > wfms From jared at puck.nether.net Wed May 7 01:51:41 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 6 May 2014 21:51:41 -0400 Subject: US patent 5473599 In-Reply-To: References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> Message-ID: <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> On May 6, 2014, at 9:11 PM, Constantine A. Murenin wrote: > On 6 May 2014 15:17, David Conrad wrote: >> Constantine, >> >> On May 6, 2014, at 4:15 PM, Constantine A. Murenin wrote: >>>> Protocol 112 was assigned by IANA for VRRP in 1998. >>>> >>>> When did OpenBSD choose to squat on 112? >>> >>> If you don't use it, you lose it. >> >> Are you suggesting no one is running VRRP? Surprising given RFC 5798. >> >> By the way, according to Wikipedia, it would seem the OpenBSD developers decided to squat on 112 in 2003, 5 years after 112 was assigned. > > Your point being? That the "BSD" community sometimes doesn't play well with others, and certainly won't fess up when they make a mistake and cause collateral damage. It's clear to me this discussion is becoming a losing prospect for all sides, it reminds me of all the small ways the BSD community has frustrated me, from not fixing defects found in -RC images that would prevent successful upgrades due to driver bugs to lack of hardware support. > >> >>> There are only so many protocol numbers; out of those potentially >>> available and non-conflicting, >> >> Yes. That is exactly why most responsible and professional developers work with IANA to obtain the assignments they need instead of intentionally squatting on numbers, particularly numbers known to be already assigned. >> >>> it was deemed the best choice to go >>> with the protocol number that was guaranteed to be useless otherwise. >> >> Except it wasn't useless: it was, in fact, in use by VRRP. Further, the OpenBSD developers chose to squat on 240 for pfsync - a number that has not yet been allocated. If the OpenBSD developers were so concerned about making the best choice, it seems odd they chose an allocated number for one protocol and an unallocated number for another protocol. > > Can you explain why exactly do you find this odd? Because it's further polluting the ecosystem that we all depend on to operate properly. Asking for a number shouldn't be that hard and there are many people who can help shepherd these things through the community. The problem is when folks just squat on numbers and don't move. There have been collisions over the years that one can see documented in /etc/services on hosts that have been worked around, this isn't the first time, nor i'm sure will it be the last. > VRRP/HSRP have had only one protocol number allocated to it; it's not > like it had two, so, another one had to come out of somewhere else. Yes, I think the issue here is that CARP is the interloper. You don't mind me coming over and bringing my trash to your back yard do you? > >> >> To be honest, it would seem from appearances that OpenBSD's use of 112 was deemed a "cute" (that is, unprofessional and irresponsible) way for the OpenBSD developers to say 'screw you' to the IETF, IANA, Cisco, network operators, etc. The fact that OpenBSD developers continue to defend this choice is one reason why I won't run OpenBSD (or CARP). >> >>> Any complaints for Google using the https port 443 for SPDY? >> >> AFAIK, the use of SPDY does not preclude the use of HTTPS on the same network. The fact that in addition to the OpenBSD developers choosing to use 112, they also chose to use the MAC addresses used for VRRP, thus making it impossible to run both VRRP and CARP on the same network due to MAC address conflicts would suggest you might want to pick a better analogy. > > Well, that's kinda the issue here -- the comparison with SPDY is > actually quite valid. I haven't seen any facts that CARP actually > precludes you from using VRRP on your network, unless you use broken > VRRP/HSRP implementations (BTW, did you thank OpenBSD for forcing > Cisco to fix those? I'm certainly an advocate for fixing bugs in software. If OpenBSD has decided to participate in the community vs running off, I think you would have seen more "thanks" vs people being upset. I've been involved in a number of negative testing operations against router vendors that found defects. Did you work closely with a CERT or the PSIRT team? If not, that may be the sign of what is going on here. > or would you rather retain an extra attack vector > for your routers?), or configure CARP and VRRP to use the same MAC > addresses through the same Virtual ID setting (user error), when > clearly a choice is available. On the contrary, it's actually clearly > and unambiguously confirmed in this very thread that both could > coexist just fine: > http://mailman.nanog.org/pipermail/nanog/2014-April/066529.html . SPDY is sitting on the same well known port number but with a different protocol (udp vs tcp) so they can co-exist. There isn't really a true collision in the fact that an application listening to a socket will get the wrong packet. You either get SOCK_DGRAM or SOCK_STREAM. > So, then the only problem, perhaps, is that noone has apparently > bothered to explicitly document that both VRRP and CARP use > 00:00:5e:00:01:xx MAC addresses, and that the "xx" part comes from the > "Virtual Router IDentifier (VRID)" in VRRP and "virtual host ID > (VHID)" in CARP, providing a colliding namespace, so, one cannot run > both with the same Virtual ID on the same network segment. Or that CARP didn't get their OUI, ask for help from one of the vendors that supports *BSD for use of their space or something else. > Why exactly is this not documented? You could always claim, > "politics", and it probably was back then 10 years ago when this story > developed; but, in today's reality, OpenBSD is quite well known for > its minimalism in all things UNIX, just as Apple in all things visual > design. The likelihood of someone mixing CARP and VRRP, on the same > network segment / same VLAN, and with the same Virtual IDs, and > without ever hearing of the controversies from which CARP had to be > born (and being curious of the origins of the "cute" name), seems > quite small to me. So, documenting it at this point would be quite > pointless, if not only for the future generations or Google reference. > > So, just as always, much ado about nothing. If someone sends a good > documentation patch, without making the change seem out of place, > it'll probably be committed into the tree shortly. I think it's easy to interpret it as much ado about nothing, but clearly there are some scars on each side. - Jared From mureninc at gmail.com Wed May 7 02:43:11 2014 From: mureninc at gmail.com (Constantine A. Murenin) Date: Tue, 6 May 2014 19:43:11 -0700 Subject: US patent 5473599 In-Reply-To: <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> Message-ID: On 6 May 2014 18:51, Jared Mauch wrote: > > On May 6, 2014, at 9:11 PM, Constantine A. Murenin wrote: > >> On 6 May 2014 15:17, David Conrad wrote: >>> Constantine, >>> >>> On May 6, 2014, at 4:15 PM, Constantine A. Murenin wrote: >>>> Any complaints for Google using the https port 443 for SPDY? >>> >>> AFAIK, the use of SPDY does not preclude the use of HTTPS on the same network. The fact that in addition to the OpenBSD developers choosing to use 112, they also chose to use the MAC addresses used for VRRP, thus making it impossible to run both VRRP and CARP on the same network due to MAC address conflicts would suggest you might want to pick a better analogy. >> >> Well, that's kinda the issue here -- the comparison with SPDY is >> actually quite valid. I haven't seen any facts that CARP actually >> precludes you from using VRRP on your network, unless you use broken >> VRRP/HSRP implementations (BTW, did you thank OpenBSD for forcing >> Cisco to fix those? > > I'm certainly an advocate for fixing bugs in software. If OpenBSD has decided to participate in the community vs running off, I think you would have seen more "thanks" vs people being upset. I've been involved in a number of negative testing operations against router vendors that found defects. Did you work closely with a CERT or the PSIRT team? If not, that may be the sign of what is going on here. > >> or would you rather retain an extra attack vector >> for your routers?), or configure CARP and VRRP to use the same MAC >> addresses through the same Virtual ID setting (user error), when >> clearly a choice is available. On the contrary, it's actually clearly >> and unambiguously confirmed in this very thread that both could >> coexist just fine: >> http://mailman.nanog.org/pipermail/nanog/2014-April/066529.html . > > SPDY is sitting on the same well known port number but with a different protocol (udp vs tcp) so they can co-exist. There isn't really a true collision in the fact that an application listening to a socket will get the wrong packet. You either get SOCK_DGRAM or SOCK_STREAM. SPDY does not use UDP, it uses TCP. Check your facts. CARP uses a VRRP version number that has not been defined by VRRP, hence there is no conflict there, either. The link from the quote above has a quote from Henning. > >> So, then the only problem, perhaps, is that noone has apparently >> bothered to explicitly document that both VRRP and CARP use >> 00:00:5e:00:01:xx MAC addresses, and that the "xx" part comes from the >> "Virtual Router IDentifier (VRID)" in VRRP and "virtual host ID >> (VHID)" in CARP, providing a colliding namespace, so, one cannot run >> both with the same Virtual ID on the same network segment. > > Or that CARP didn't get their OUI, ask for help from one of the vendors that supports *BSD for use of their space or something else. Politics. Again, this is a non-issue for most users -- there's a very easy, straightforward and complete workaround. C. From sthaug at nethelp.no Wed May 7 04:14:01 2014 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 07 May 2014 06:14:01 +0200 (CEST) Subject: US patent 5473599 In-Reply-To: References: <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> Message-ID: <20140507.061401.74662183.sthaug@nethelp.no> > So, then the only problem, perhaps, is that noone has apparently > bothered to explicitly document that both VRRP and CARP use > 00:00:5e:00:01:xx MAC addresses, and that the "xx" part comes from the > "Virtual Router IDentifier (VRID)" in VRRP and "virtual host ID > (VHID)" in CARP, providing a colliding namespace, so, one cannot run > both with the same Virtual ID on the same network segment. RFC 2338, from April 1998: 7.3 Virtual Router MAC Address The virtual router MAC address associated with a virtual router is an IEEE 802 MAC Address in the following format: 00-00-5E-00-01-{VRID} (in hex in internet standard bit-order) The first three octets are derived from the IANA's OUI. The next two octets (00-01) indicate the address block assigned to the VRRP protocol. {VRID} is the VRRP Virtual Router Identifier. This mapping provides for up to 255 VRRP routers on a network. Also repeated in RFC 3768 (April 2004) and RFC 5798 (March 2010). Steinar Haug, Nethelp consulting, sthaug at nethelp.no From bygg at cafax.se Wed May 7 07:33:03 2014 From: bygg at cafax.se (Johnny Eriksson) Date: Wed, 7 May 2014 7:33:03 WET DST Subject: US patent 5473599 In-Reply-To: Your message of Tue, 6 May 2014 21:51:41 -0400 Message-ID: Jared Mauch wrote: > > Your point being? > > That the "BSD" community sometimes doesn't play well with others, > and certainly won't fess up when they make a mistake and cause > collateral damage. The "BSD" community is larger than OpenBSD, and larger than Theo's ego, much to said persons disappointment. There are other BSDs out there. > - Jared --Johnny From hb-nanog at bsws.de Wed May 7 06:34:23 2014 From: hb-nanog at bsws.de (Henning Brauer) Date: Wed, 7 May 2014 08:34:23 +0200 Subject: US patent 5473599 In-Reply-To: <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> References: <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> Message-ID: <20140507063423.GB26826@quigon.bsws.de> * David Conrad [2014-05-07 00:21]: > The fact that OpenBSD developers continue to defend this choice is > one reason why I won't run OpenBSD (or CARP). We won't miss you. And besides, you're running plenty of our code every day. It's probaby in your pocket right now. > > Any complaints for Google using the https port 443 for SPDY? > AFAIK, the use of SPDY does not preclude the use of HTTPS on the same > network. The use of CARP does not preclude the use of VRRP on the same network either. > The fact that in addition to the OpenBSD developers choosing > to use 112, they also chose to use the MAC addresses used for VRRP, > thus making it impossible to run both VRRP and CARP on the same network > due to MAC address conflicts would suggest you might want to pick a > better analogy. How about checking your facts before making wrong claims next time? carp and vrrp work prefectly fine next to each other on the same network. I explained what lead to the mac addr at least twice right in this thread. Amazing how many people here apparently have text understanding issues. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting From hb-nanog at bsws.de Wed May 7 06:44:00 2014 From: hb-nanog at bsws.de (Henning Brauer) Date: Wed, 7 May 2014 08:44:00 +0200 Subject: US patent 5473599 In-Reply-To: <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> References: <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> Message-ID: <20140507064400.GC26826@quigon.bsws.de> * Jared Mauch [2014-05-07 03:54]: > That the "BSD" community sometimes doesn't play well with others Translation: not bowing for corporate US america. Quite proudly so. > certainly won't fess up when they make a mistake wrong. I have no problem admitting mistakes. And that's true for most of our devs. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting From oscar.vives at gmail.com Wed May 7 09:11:19 2014 From: oscar.vives at gmail.com (Tei) Date: Wed, 7 May 2014 11:11:19 +0200 Subject: Anternet In-Reply-To: <533F9825.3090300@cox.net> References: <533F9825.3090300@cox.net> Message-ID: On 5 April 2014 07:44, Larry Sheldon wrote: > Offered for your amusement--no followup. > > http://kottke.org/14/04/the-anternet > -- >>>>>> A forager won't return to the nest until it finds food. If seeds are plentiful, foragers return faster, and more ants leave the nest to forage. If, however, ants begin returning empty handed, the search is slowed, and perhaps called off. <<<<<< No wonders ants don't govern us. This algorithm is atrocious. So if food is scarce, most ants will stay at home and play videogames all day, but if theres a lot of food, all of them will go around and return with mountains of food they can't store. Is a algorithm, from a madman, designed to kill the hive if theres very low food or too much food. I propose ants start using "food debts"/"food promises". Ants will print "food debts" to explorer ants, these explorer ants must "pay" these debts by finding food. If some ant need a lot of food, that ant will print more debt. The more food the hive need, more debt is printed. -- -- ℱin del ℳensaje. From nanog-post at rsuc.gweep.net Wed May 7 11:19:12 2014 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Wed, 7 May 2014 07:19:12 -0400 Subject: "Review How Internet Peering Improves Security" [Re: Reviewers needed: How Internet Peering Improves Security] In-Reply-To: <75DD1F03-0B98-4420-B33F-F4886BDB488C@DrPeering.net> References: <75DD1F03-0B98-4420-B33F-F4886BDB488C@DrPeering.net> Message-ID: <20140507111912.GA24751@gweep.net> This has always been the case, and traffic splay and origin/sink management has been more important than cost savings since at least 2002? Maybe 2001. Definitely before 2004. On Mon, May 05, 2014 at 08:42:06PM -0700, wbn wrote: > Hi fellow NANOGers - > > I recently spent some time with peering coordinators at industry events (NANOG, EPF, AFPIF, UKNOF, etc.) where I asked ?How does Internet Peering affect Internet Security?? > > The result of this exercise is a white paper, currently in its draft 4-page form, entitled ?How Internet Peering Improves Security.? > > What I need now are a handful of people that are interested in this subject and willing to let me talk through the draft in order to solicit direct feedback. If interested, please send email to wbn at DrPeering.net with subject: "Review How Internet Peering Improves Security" and I will reach out to schedule some time. > > Thanks in advance - > > Bill > > PS - Here is the abstract to help you decide if you are interested in helping me document this for the community, and yes, as usual, I will be happy to share the resulting white paper with anyone interested. > > > How Internet Peering Improves Security > > William B. Norton > > > > Abstract > > Denial-of-Service attacks continue to flood the Internet at increasing scale. They attack specific targets, while, as a side affect, disrupt any traffic that traverses the network attack paths. During these attacks, impacted Internet users may experience intermittent problems, such as video freeze frames, garbled audio during phone or Skype calls, or error messages indicating that their Internet cloud service is unavailable. > > The ubiquitous and open nature of the Internet is both its value and its downfall. All one needs for access to cloud storage systems (DropBox, Box.net, etc.) is an Internet connection. This also means that attackers need only a few thousand broadband computers, infected with viruses and taken over as zombies, to exploit this open Internet ecosystem and overwhelm even the most robust Internet services. > > The attacks are not predictable in time, scope, or scale, and the impacts are far reaching, well beyond the source and destinations of the attacks. For these reason, the commodity Internet may not suitable for a subset of Internet applications. For example, some enterprise mission-critical applications require consistency simply unavailable from today?s Internet Transit services. > > There is however a well-known interconnection approach that improves this situation: an interconnection technique call ?Internet Peering.? This paper will introduce Internet Peering and discuss how Internet security is improved simply by using this common interconnection technique. -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG From rea+nanog at grid.kiae.ru Wed May 7 07:36:02 2014 From: rea+nanog at grid.kiae.ru (Eygene Ryabinkin) Date: Wed, 7 May 2014 11:36:02 +0400 Subject: US patent 5473599 In-Reply-To: Message-ID: Constantine, Tue, May 06, 2014 at 06:11:04PM -0700, Constantine A. Murenin wrote: > On 6 May 2014 15:17, David Conrad wrote: > > Except it wasn't useless: it was, in fact, in use by VRRP. > > Further, the OpenBSD developers chose to squat on 240 for pfsync - > > a number that has not yet been allocated. If the OpenBSD > > developers were so concerned about making the best choice, it > > seems odd they chose an allocated number for one protocol and an > > unallocated number for another protocol. > > Can you explain why exactly do you find this odd? > > VRRP/HSRP have had only one protocol number allocated to it; it's not > like it had two, so, another one had to come out of somewhere else. VRRP/HSRP comes from Cisco (well, VRRP is RFC'ed for some time, but its origin is Cisco too), so there is a straight route for agreeing on the protocol versioning within the same protocol ID. And _I_ find this odd is because you'll probably find me very odd if I'll come into your house, find currently unused room and will say "oh, I'll live here; no one will be confused or troubled, the room is unused". Seriously, do you think that "we used same protocol number, but version field tells you what's going on" is a really good excuse? Had you ever run tcpdump on the CARP traffic to see that it thinks it to be VRRP and discover that you need '-T carp'? Do you think that in-hardware or in-software implementations really need to check an extra field in the packet's contents to judge if this is VRRP (or CARP) instead of just testing protocol number and leave packets for unsupported protocol out of the path? Do you think that extra coordination with Cisco for not to reuse VRRP/HSRP protocol version that was at that time unused (and picked by CARP) really worth that? Tue, May 06, 2014 at 07:43:11PM -0700, Constantine A. Murenin wrote: > On 6 May 2014 18:51, Jared Mauch wrote: > > On May 6, 2014, at 9:11 PM, Constantine A. Murenin wrote: > >> So, then the only problem, perhaps, is that noone has apparently > >> bothered to explicitly document that both VRRP and CARP use > >> 00:00:5e:00:01:xx MAC addresses, and that the "xx" part comes from the > >> "Virtual Router IDentifier (VRID)" in VRRP and "virtual host ID > >> (VHID)" in CARP, providing a colliding namespace, so, one cannot run > >> both with the same Virtual ID on the same network segment. > > > > Or that CARP didn't get their OUI, ask for help from one of the > > vendors that supports *BSD for use of their space or something > > else. > > Politics. Again, this is a non-issue for most users -- there's a very > easy, straightforward and complete workaround. If you hadn't seen the cases when same VRIDs in the same network were used for both VRRP and CARP doesn't mean that they aren't occurring in the real world. We use CARP and VRRP quite extensively and when we first were hit by this issue, it was not that funny. And our Cisco folks had no knowledge about CARP, because they are just Cisco-heads (and because there is no CARP specification of any kind). Becides, such "clever" choice of OUI limits total number of CARP + HSRP/VRRP instances in the same L2 network to 256 instead of being 256 + 256. When you're running many CARP and VRRP-based clusters, especially with ARP load-balancing (multiple VRIDs for the single IP), this somewhat pushes VRID space close to its limits. One may say that (all that I had seen in the real-world conversations) a. people who use CARP and VRRP should know what they are both and avoid having same VRIDs; b. no sane person will use CARP load-balancing; c. the probability of having same VRIDs (and, thus, MACs) is small, but choosing OUI from the VRRP space (hijacking that space) was clearly the poor design choice. Fullstop. You may rant about Google, SPDY and other stuff, but making examples of people doing more cruel things doesn't help to alleviate the problem we're talking about. That's just the polite way of saying "CARP developers were right, piss off". Getting the same protocol ID and reusing OUI assignment is a potential point of confusion and errors. It manifests itself in the real world. Such potential points of breakage tend to strike at the worst possible time and current networks are complicated enough even without this mess; I think if you had worked in a complex network environments, you know what I am talking about. If not, well, just think of OSPF, BGP, BFD, VRRP, MPLS, LACP, PAgP, ESRP, xSTP and other protocols that are running today in any kinda matured network (not saying about other fancy stuff like TRILL, SDN and other ones that tend to show up and be even neccessary for some cases, but not very broadly deployed just now). Does anyone wants to have other problem-originators here? You appear to believe that it isn't an issue; well, that's your mindset. Other people think that there is some level of controversy in all this. Having the same protocol ID and OUI, but bumping the protocol version looks like as "hey, we have better VRRP our here, let's use that", but that didn't worked well, as we see now, and we have what we have: two incompatible protocols that use same IDs and sometimes they clash. Just learn the lesson and do the relevant parts of a protocol design better next time. And the "next time" can mean CARPv2 ;)) My personal view (if someone is interested) is that CARP did and still does very good job and at the time of its appearence of was technically superior vs VRRP/HSRP, just by having authentication. And it is/was free and non-patented thing that is a good stuff for some environments. But some points in CARP design are very rough and tend to create network mess. One can learn and avoid them, but it would be much better if these points were eliminated from the beginning or, at least, will be eliminated in the course of its further life. Shutting up. -- Eygene "using CARP and VRRP extensively" Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. From antoine.meillet at gmail.com Wed May 7 13:11:59 2014 From: antoine.meillet at gmail.com (Antoine Meillet) Date: Wed, 7 May 2014 15:11:59 +0200 Subject: About NetFlow/IPFIX and DPI Message-ID: Hello, I'm currently writing a paper for school and I talk about net neutrality which brings the subject of NetFlow/IPFIX. Should those protocols be considered as tools to perform DPI ? Thanks, Antoine. From dwhite at olp.net Wed May 7 14:38:16 2014 From: dwhite at olp.net (Dan White) Date: Wed, 7 May 2014 09:38:16 -0500 Subject: About NetFlow/IPFIX and DPI In-Reply-To: References: Message-ID: <20140507143816.GC6200@dan.olp.net> On 05/07/14 15:11 +0200, Antoine Meillet wrote: >Hello, > >I'm currently writing a paper for school and I talk about net neutrality >which brings the subject of NetFlow/IPFIX. > >Should those protocols be considered as tools to perform DPI ? That question can be taken a couple of ways. Netflow is useful for calculating information useful to providers and operators through sampling of data on high bandwidth links, where performing DPI is not feasible or desired. It is not a robust solution for DPI - or analysis of higher layer packet data, which is typically performed by a mirrored interface or an inline box/firewall that can perform high speed forwarding. -- Dan White From rdobbins at arbor.net Wed May 7 14:44:58 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 7 May 2014 14:44:58 +0000 Subject: About NetFlow/IPFIX and DPI In-Reply-To: References: Message-ID: <4A9A87FC-E532-40FF-9299-07C84AE942D1@arbor.net> On May 7, 2014, at 8:11 PM, Antoine Meillet wrote: > Should those protocols be considered as tools to perform DPI ? No - they're flow telemetry exported by routers and switches, and they provide layer-4 information. It's possible with Cisco Flexible NetFlow and with PSAMP exported over IPFIX to get packet contents; however, few if any collection/analysis systems utilize either extended telemetry format, to date. I've never seen either implemented in a production network. NetFlow and IPFIX are primarily used for security purposes such as DDoS detection/classification/traceback and botnet C&C identification; for traffic engineering analysis; capacity planning analysis; for troubleshooting; and for billing purposes. Flow telemetry is an essential tool that ISPs and larger enterprises utilize in order to get a view into their network traffic, because it scales for large networks - and it does so because it doesn't typically include packet payloads, just the layer-4 information. It's sort of like a near-time mobile phone bill for the network. 'DPI' generally (but not always) refers to devices which are placed inline and perform full multi-packet payload reassembly and inspection. The term has been used (and misused) so broadly as to becoming essentially meaningless. NetFlow and IPFIX are merely telemetry formats used by network engineers for the purposes noted above. This presentation talks about how NetFlow is used by network operators: Network neutrality is largely an issue of policy and of economics, not of technology, per se. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From pl+list at pmacct.net Wed May 7 15:45:06 2014 From: pl+list at pmacct.net (Paolo Lucente) Date: Wed, 7 May 2014 15:45:06 +0000 Subject: About NetFlow/IPFIX and DPI In-Reply-To: References: Message-ID: <20140507154506.GA11696@moussaka.pmacct.net> Another role for IPFIX/NetFlow in the context of DPI (on top of PSAMP that was already mentioned by Roland) is to serve as a transport mechanism to travel flow data along with their DPI classification from probes to remote collectors, for persistent storage, analysis, etc. This model is supported on the export side by Cisco with their NetFlow/NBAR integration and on the collection side by some collector. Maybe this (*) recent university report from the good Tomasz Bujlov can be of interest to you. What i described above is specifically captured in chapters 3.4.6 and 3.5.6. Cheers, Paolo (*) http://vbn.aau.dk/files/78068418/report.pdf On Wed, May 07, 2014 at 03:11:59PM +0200, Antoine Meillet wrote: > Hello, > > I'm currently writing a paper for school and I talk about net neutrality > which brings the subject of NetFlow/IPFIX. > > Should those protocols be considered as tools to perform DPI ? > > Thanks, > Antoine. From rdobbins at arbor.net Wed May 7 16:15:44 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 7 May 2014 16:15:44 +0000 Subject: About NetFlow/IPFIX and DPI In-Reply-To: <20140507154506.GA11696@moussaka.pmacct.net> References: <20140507154506.GA11696@moussaka.pmacct.net> Message-ID: <5A3E2A55-8BAF-4A9F-A2A1-F755DAF1A1ED@arbor.net> On May 7, 2014, at 10:45 PM, Paolo Lucente wrote: > This model is supported on the export side by Cisco with their NetFlow/NBAR integration and on the collection side by some > collector. As you'll note in reading that report, NBAR didn't seem to work very well for them; I haven't run across its use in any ISP network, on ISP-grade hardware (i.e., not a small software-based router like a 7200), or even in a large-scale enterprise environment. Again, I haven't yet run across anyone actually using this on a production network. It would be very interesting to hear from someone with first-hand experience with NBAR exported over Flexible NetFlow in a production environment. Also, it's important to note that this sort of thing doesn't scale across networks of any real size/speed. There's a great deal of potential utility in the security, troubleshooting, and traffic engineering arenas for on-demand triggered packet sampling of this nature, but so far, the control-plane hooks aren't really there to do this in a programmatic manner (one presumes that SDN of one flavor or another might provide these capabilities). That was my biggest gripe about Flexible NetFlow when I was at Cisco, and one which I felt ensured the technology wouldn't make it into production networks - no organic control-plane interface. So, perhaps now we can de-conflate flow telemetry and 'DPI', since the real-life export, collection, and analysis of anything other than layer-4 information via flow telemetry isn't at all commonplace (if it in fact exists at all) on production networks), at this juncture. 'DPI' generally alludes boxes positioned at points of ingress/egress symmetry (either natural or purposely engineered) within a network. Flow telemetry per se is not really within the rubric of 'DPI'. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From pl+list at pmacct.net Wed May 7 16:43:38 2014 From: pl+list at pmacct.net (Paolo Lucente) Date: Wed, 7 May 2014 16:43:38 +0000 Subject: About NetFlow/IPFIX and DPI In-Reply-To: <5A3E2A55-8BAF-4A9F-A2A1-F755DAF1A1ED@arbor.net> References: <20140507154506.GA11696@moussaka.pmacct.net> <5A3E2A55-8BAF-4A9F-A2A1-F755DAF1A1ED@arbor.net> Message-ID: <20140507164338.GA12304@moussaka.pmacct.net> Please note NBAR/NetFlow integration wanted to be an example of using NetFlow/ IPFIX as a transport for DPI classification info (where classification could be performed with any other in-line technology than NBAR). Whether NBAR works or does not as a classification technology is out of scope for me here - and seems also out of the op request. Inline: On Wed, May 07, 2014 at 04:15:44PM +0000, Dobbins, Roland wrote: > So, perhaps now we can de-conflate flow telemetry and 'DPI', since the real-life export, collection, and analysis of anything other than layer-4 information via flow telemetry isn't at all commonplace (if it in fact exists at all) on production networks), at this juncture. I disagree if anybody conflates here. I don't. I see two disjoint pieces: classification technology and transport of classification info to a central location. IPFIX, for example, is general (and standardized) enough to transport/encapsulate other info than just flow info, this might include DPI classification or other stuff. You can also read this as: if you have to travel some info, why re invent the wheel and not leverage a general-enough, standardized transport protocol (that btw you can contribute at any point to enhance if not satisfactory enough)? And please it's nice to have different positions - no need to escalate. Cheers, Paolo From rs at seastrom.com Wed May 7 17:18:03 2014 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 07 May 2014 13:18:03 -0400 Subject: US patent 5473599 In-Reply-To: (Eygene Ryabinkin's message of "Wed, 7 May 2014 11:36:02 +0400") References: Message-ID: <86d2fpa4ok.fsf@valhalla.seastrom.com> Eygene Ryabinkin writes: > If you hadn't seen the cases when same VRIDs in the same network were > used for both VRRP and CARP doesn't mean that they aren't occurring in > the real world. We use CARP and VRRP quite extensively and when we > first were hit by this issue, it was not that funny. +1 > ... > but choosing OUI from the VRRP space (hijacking that space) was > clearly the poor design choice. Fullstop. +\infty Either it was an intentional conflict that was meant to cause operational problems or it was not. If it was, then a previous characterization of CARP as a trojan is spot on. If it was not (and I'm willing to be charitable here), then the take-away from this is that the folks who made this decision are utterly clueless about standards, the reason for standards, and operations. That would hardly be earth shattering news. Those wishing to decide for themselves which it is may wish to consider the fact that this tripping point remains undocumented in OpenBSD's man page ten years on. -r From tglassey at earthlink.net Wed May 7 20:44:54 2014 From: tglassey at earthlink.net (TGLASSEY) Date: Wed, 07 May 2014 13:44:54 -0700 Subject: US patent 5473599 In-Reply-To: <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> Message-ID: <536A9B46.1030400@earthlink.net> The issue Jared is needing a consensus in a community where that may be impossible to achieve because of differing agendas - so does that mean that the protocol should not exist because the IETF would not grant it credence? Interesting. Todd On 5/6/2014 6:51 PM, Jared Mauch wrote: > On May 6, 2014, at 9:11 PM, Constantine A. Murenin wrote: > >> On 6 May 2014 15:17, David Conrad wrote: >>> Constantine, >>> >>> On May 6, 2014, at 4:15 PM, Constantine A. Murenin wrote: >>>>> Protocol 112 was assigned by IANA for VRRP in 1998. >>>>> >>>>> When did OpenBSD choose to squat on 112? >>>> If you don't use it, you lose it. >>> Are you suggesting no one is running VRRP? Surprising given RFC 5798. >>> >>> By the way, according to Wikipedia, it would seem the OpenBSD developers decided to squat on 112 in 2003, 5 years after 112 was assigned. >> Your point being? > That the "BSD" community sometimes doesn't play well with others, and certainly won't fess up when they make a mistake and cause collateral damage. It's clear to me this discussion is becoming a losing prospect for all sides, it reminds me of all the small ways the BSD community has frustrated me, from not fixing defects found in -RC images that would prevent successful upgrades due to driver bugs to lack of hardware support. > > > >>>> There are only so many protocol numbers; out of those potentially >>>> available and non-conflicting, >>> Yes. That is exactly why most responsible and professional developers work with IANA to obtain the assignments they need instead of intentionally squatting on numbers, particularly numbers known to be already assigned. >>> >>>> it was deemed the best choice to go >>>> with the protocol number that was guaranteed to be useless otherwise. >>> Except it wasn't useless: it was, in fact, in use by VRRP. Further, the OpenBSD developers chose to squat on 240 for pfsync - a number that has not yet been allocated. If the OpenBSD developers were so concerned about making the best choice, it seems odd they chose an allocated number for one protocol and an unallocated number for another protocol. >> Can you explain why exactly do you find this odd? > Because it's further polluting the ecosystem that we all depend on to operate properly. Asking for a number shouldn't be that hard and there are many people who can help shepherd these things through the community. The problem is when folks just squat on numbers and don't move. There have been collisions over the years that one can see documented in /etc/services on hosts that have been worked around, this isn't the first time, nor i'm sure will it be the last. > >> VRRP/HSRP have had only one protocol number allocated to it; it's not >> like it had two, so, another one had to come out of somewhere else. > Yes, I think the issue here is that CARP is the interloper. You don't mind me coming over and bringing my trash to your back yard do you? > >>> To be honest, it would seem from appearances that OpenBSD's use of 112 was deemed a "cute" (that is, unprofessional and irresponsible) way for the OpenBSD developers to say 'screw you' to the IETF, IANA, Cisco, network operators, etc. The fact that OpenBSD developers continue to defend this choice is one reason why I won't run OpenBSD (or CARP). >>> >>>> Any complaints for Google using the https port 443 for SPDY? >>> AFAIK, the use of SPDY does not preclude the use of HTTPS on the same network. The fact that in addition to the OpenBSD developers choosing to use 112, they also chose to use the MAC addresses used for VRRP, thus making it impossible to run both VRRP and CARP on the same network due to MAC address conflicts would suggest you might want to pick a better analogy. >> Well, that's kinda the issue here -- the comparison with SPDY is >> actually quite valid. I haven't seen any facts that CARP actually >> precludes you from using VRRP on your network, unless you use broken >> VRRP/HSRP implementations (BTW, did you thank OpenBSD for forcing >> Cisco to fix those? > I'm certainly an advocate for fixing bugs in software. If OpenBSD has decided to participate in the community vs running off, I think you would have seen more "thanks" vs people being upset. I've been involved in a number of negative testing operations against router vendors that found defects. Did you work closely with a CERT or the PSIRT team? If not, that may be the sign of what is going on here. > >> or would you rather retain an extra attack vector >> for your routers?), or configure CARP and VRRP to use the same MAC >> addresses through the same Virtual ID setting (user error), when >> clearly a choice is available. On the contrary, it's actually clearly >> and unambiguously confirmed in this very thread that both could >> coexist just fine: >> http://mailman.nanog.org/pipermail/nanog/2014-April/066529.html . > SPDY is sitting on the same well known port number but with a different protocol (udp vs tcp) so they can co-exist. There isn't really a true collision in the fact that an application listening to a socket will get the wrong packet. You either get SOCK_DGRAM or SOCK_STREAM. > >> So, then the only problem, perhaps, is that noone has apparently >> bothered to explicitly document that both VRRP and CARP use >> 00:00:5e:00:01:xx MAC addresses, and that the "xx" part comes from the >> "Virtual Router IDentifier (VRID)" in VRRP and "virtual host ID >> (VHID)" in CARP, providing a colliding namespace, so, one cannot run >> both with the same Virtual ID on the same network segment. > Or that CARP didn't get their OUI, ask for help from one of the vendors that supports *BSD for use of their space or something else. > >> Why exactly is this not documented? You could always claim, >> "politics", and it probably was back then 10 years ago when this story >> developed; but, in today's reality, OpenBSD is quite well known for >> its minimalism in all things UNIX, just as Apple in all things visual >> design. The likelihood of someone mixing CARP and VRRP, on the same >> network segment / same VLAN, and with the same Virtual IDs, and >> without ever hearing of the controversies from which CARP had to be >> born (and being curious of the origins of the "cute" name), seems >> quite small to me. So, documenting it at this point would be quite >> pointless, if not only for the future generations or Google reference. >> >> So, just as always, much ado about nothing. If someone sends a good >> documentation patch, without making the change seem out of place, >> it'll probably be committed into the tree shortly. > I think it's easy to interpret it as much ado about nothing, but clearly there are some scars on each side. > > - Jared > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4577 / Virus Database: 3931/7451 - Release Date: 05/06/14 > > > -- ------------- Personal Email - Disclaimers Apply From leo.vegoda at icann.org Wed May 7 21:42:19 2014 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 7 May 2014 14:42:19 -0700 Subject: US patent 5473599 In-Reply-To: <536A9B46.1030400@earthlink.net> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <536A9B46.1030400@earthlink.net> Message-ID: <5648A8908CCB564EBF46E2BC904A75B1A3BEE30F02@EXVPMBX100-1.exc.icann.org> Hi, TGLASSEY wrote: > The issue Jared is needing a consensus in a community where that may be > impossible to achieve because of differing agendas - so does that mean > that the protocol should not exist because the IETF would not grant it > credence? Interesting. There are just 256 numbers available in https://www.iana.org/assignments/protocol-numbers. We could decide that we only assign them when there's a consensus or we could go with the alternative. Which do you prefer? There are a whole bunch of well-known policies. On the whole, the less limited the resource is the more liberal the policy. Maybe that's wrong and we should make everything FCFS. Regards, Leo -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5495 bytes Desc: not available URL: From jgreco at ns.sol.net Wed May 7 17:18:09 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 7 May 2014 12:18:09 -0500 (CDT) Subject: Residential CPE suggestions In-Reply-To: <5368d0b9.040fec0a.1146.1424@mx.google.com> Message-ID: <201405071718.s47HI9k7092712@aurora.sol.net> > It uses a Cavium Octeon processor which does have dedicated HW packet proce= > ssing. A moderate number of prefixes won't slow it down doing vanilla for= > warding, not sure about 2 million though... I believe they have recently o= > ptimized some of the FW stuff to take advantage of the HW as well. =20 > > Layering services like FW, NAT, and tunneling definitely drops the packet r= > ate significantly, but it is still capable of 100+Mbps at IMIX packet sizes= > .=20 > > I think there are a couple of in depth tests out there. > > In my experience the ERL works really well for a $99 device.=20 I sent them an inquiry and they sent a friendly but fact-free response so it is probably safe to assume that it is relatively good at basic packet forwarding but the services will kill it. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From drc at virtualized.org Wed May 7 21:57:01 2014 From: drc at virtualized.org (David Conrad) Date: Wed, 7 May 2014 17:57:01 -0400 Subject: US patent 5473599 In-Reply-To: <536A9B46.1030400@earthlink.net> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <536A9B46.1030400@earthlink.net> Message-ID: <6E38BC9A-9C95-46A1-8302-E6FB2AD4553E@virtualized.org> Todd, On May 7, 2014, at 4:44 PM, TGLASSEY wrote: > The issue Jared is needing a consensus in a community where that may be impossible to achieve because of differing agendas - so does that mean that the protocol should not exist because the IETF would not grant it credence? Interesting. Err, no. We're talking about a group that chose to squat on an existing assignment because they apparently didn't like the fact that the existing assignment had asserted intellectual property rights. As far as i can tell, it wasn't that the IETF would not grant CARP credence -- the IETF rules for IP protocol number assignment require either Standards Action or IESG Consensus. Did the OpenBSD developers even bother to document their protocol so the IESG could evaluate their request? However, assume that the OpenBSD developers did document their protocol and requested an IESG action and was refused. Do you believe that would justify squatting on an already assigned number? 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 Kevin.Irwin at cinbell.com Wed May 7 14:39:26 2014 From: Kevin.Irwin at cinbell.com (Irwin, Kevin) Date: Wed, 7 May 2014 14:39:26 +0000 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: <536969E5.6080608@cox.net> Message-ID: I¹m really surprised that most people have not hit this limit already, especially on the 9K¹s, as it seems Cisco has some fuzzy math when it comes to the 512K limit. Also make sure you have spare cards when you reload after changing the scaling, those old cards don¹t always like to come back. On 5/6/14, 7:01 PM, "Larry Sheldon" wrote: >On 5/6/2014 10:39 AM, Drew Weaver wrote: > >> Just something to think about before it becomes a story the community >> talks about for the next decade. > >Like we have for the last two? > > >-- >Requiescas in pace o email Two identifying characteristics > of System Administrators: >Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and destroy any copies of this document. From peteru at microsoft.com Wed May 7 17:28:46 2014 From: peteru at microsoft.com (Peter Rubenstein) Date: Wed, 7 May 2014 17:28:46 +0000 Subject: bgp convergence problem In-Reply-To: <53685E02.7060309@gmail.com> References: <53685E02.7060309@gmail.com> Message-ID: <4473ec67ca154791b977efe46c4d8ef9@BY2PR03MB505.namprd03.prod.outlook.com> Operationally speaking, AS1 should not be leaking routes from one upstream to the other. Bad route policy. Also, AS3 should not accept routes from AS1 that don't belong to it. Customer router filtering would prevent this. > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Song Li > Sent: Monday, May 5, 2014 11:59 PM > To: NANOG > Subject: bgp convergence problem > > Hi everyone, > > I have one bgp convergence problem which confused me. The problem is as > follows: > > +--------+ > | AS5 | > +------+16.1/16 | > | +-----+--+ > | | > +---+--+ | > | AS4 | | > | | | > ++-----+ | > | | > | | > | | > +-----+--+ +-+-----+ > | AS2 | | AS3 | 16.1/16 (5) > | ISP | | ISP | > +---^----+ +---^---+ > | | > | +--------+ | > +-----+ AS1 +----+ > |customer| > +--------+ > 16.1/16 (2 4 5) > > AS1 multihomed to AS2 and AS3, for some reasons AS1 disconnect from AS3, > and as a resutl the route to 16.1/16 will be 16.1/16 (2 4 5). > > After a while, the BGP seesion between AS1 and AS3 reestablished but > AS1 leaks the route 16.1/16 (2 4 5) to AS3. At this point, > > 1/ AS1 will have two bgp routes for prefix 16.1/16: 16.1/16(2 4 5)and > 16.1/16(3 5), according to shorter AS_PATH it will select 16.1/16(3 5) as best > route. > > 2/ AS3 also have two bgp routes: 16.1/16(2 4 5) and 16.1/16(5), according to > local_pref it will select 16.1/16(2 4 5). > > in this case, AS1 and AS3 select each other as the best route to AS5, i wonder > which route will be the final best route after bgp convergence in > AS1 and AS3. > > Thanks! > > -- > Song Li > Room 4-204, FIT Building, > Network Security, > Department of Electronic Engineering, > Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 > E-mail: refresh.lsong at gmail.com From owen at delong.com Wed May 7 22:12:23 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 7 May 2014 15:12:23 -0700 Subject: US patent 5473599 In-Reply-To: <20140507064400.GC26826@quigon.bsws.de> References: <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <20140507064400.GC26826@quigon.bsws.de> Message-ID: On May 6, 2014, at 23:44 , Henning Brauer wrote: > * Jared Mauch [2014-05-07 03:54]: >> That the "BSD" community sometimes doesn't play well with others > > Translation: not bowing for corporate US america. > Quite proudly so. Uh, no, Translation: Self appointed vigilantes with no regard for the rules by which everyone else has agreed to play. >> certainly won't fess up when they make a mistake > > wrong. I have no problem admitting mistakes. And that's true for most > of our devs. You seem to have a pretty big difficulty with it in this case. Owen From owen at delong.com Wed May 7 22:09:55 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 7 May 2014 15:09:55 -0700 Subject: US patent 5473599 In-Reply-To: References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> Message-ID: > CARP uses a VRRP version number that has not been defined by VRRP, > hence there is no conflict there, either. The link from the quote > above has a quote from Henning. Which means that in addition to squatting on the VRRP port, they are also squatting on a version number that I'm betting the IETF did not grant to them for that purpose and may use for another purpose at a later date. Owen From landonstewart at gmail.com Wed May 7 22:19:05 2014 From: landonstewart at gmail.com (Landon) Date: Wed, 7 May 2014 15:19:05 -0700 Subject: Does Telus traffic shape their DSL or Fibre subscribers at all? Message-ID: Hello, Before I go chasing this down does Telus traffic shape their DSL or Fibre subscribers? Customer using 50Mbps fiber gets excellent speeds on speedtest.net but looks like http and ssh (scp) transfers are capped at 1MBps (not 1Mbps) for non-popular hosts but uncapped for popular hosts. Just a hunch. Thank you for reading. -- Landon Stewart From gary.buhrmaster at gmail.com Wed May 7 22:39:57 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Wed, 7 May 2014 22:39:57 +0000 Subject: US patent 5473599 In-Reply-To: <86d2fpa4ok.fsf@valhalla.seastrom.com> References: <86d2fpa4ok.fsf@valhalla.seastrom.com> Message-ID: On Wed, May 7, 2014 at 5:18 PM, Rob Seastrom wrote: > > Eygene Ryabinkin writes: > >> If you hadn't seen the cases when same VRIDs in the same network were >> used for both VRRP and CARP doesn't mean that they aren't occurring in >> the real world. We use CARP and VRRP quite extensively and when we >> first were hit by this issue, it was not that funny. > > +1 > >> ... >> but choosing OUI from the VRRP space (hijacking that space) was >> clearly the poor design choice. Fullstop. > > +\infty > > Either it was an intentional conflict that was meant to cause > operational problems or it was not. > > If it was, then a previous characterization of CARP as a trojan is spot on. > > If it was not (and I'm willing to be charitable here), then the > take-away from this is that the folks who made this decision are > utterly clueless about standards, the reason for standards, and > operations. That would hardly be earth shattering news. To be slightly less charitable, since I am having hard time coming up with a third option, I am forced to choose between maliciousness and incompetence. And I never thought the OpenBSD team was incompetent. Perhaps I was wrong? But (presuming no adjustments) the patent is now expired, and the OpenBSD team could now release CARPv2 (or whatever they decide to call it) which would implement the standard, should they wish to work and play well with the standards bodies and community. Gary From shawnl at up.net Wed May 7 22:45:07 2014 From: shawnl at up.net (Shawn L) Date: Wed, 7 May 2014 18:45:07 -0400 Subject: Fwd: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: <536969E5.6080608@cox.net> Message-ID: Do the ASR1k routers have this issue as well? I searched around but couldn't find any information. ---------- Forwarded message ---------- From: Irwin, Kevin Date: Wed, May 7, 2014 at 10:39 AM Subject: Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. To: "nanog at nanog.org" I¹m really surprised that most people have not hit this limit already, especially on the 9K¹s, as it seems Cisco has some fuzzy math when it comes to the 512K limit. Also make sure you have spare cards when you reload after changing the scaling, those old cards don¹t always like to come back. On 5/6/14, 7:01 PM, "Larry Sheldon" wrote: >On 5/6/2014 10:39 AM, Drew Weaver wrote: > >> Just something to think about before it becomes a story the community >> talks about for the next decade. > >Like we have for the last two? > > >-- >Requiescas in pace o email Two identifying characteristics > of System Administrators: >Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and destroy any copies of this document. From mpalmer at hezmatt.org Wed May 7 23:19:53 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Thu, 8 May 2014 09:19:53 +1000 Subject: US patent 5473599 In-Reply-To: <6E38BC9A-9C95-46A1-8302-E6FB2AD4553E@virtualized.org> References: <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <536A9B46.1030400@earthlink.net> <6E38BC9A-9C95-46A1-8302-E6FB2AD4553E@virtualized.org> Message-ID: <20140507231953.GJ29444@hezmatt.org> On Wed, May 07, 2014 at 05:57:01PM -0400, David Conrad wrote: > However, assume that the OpenBSD developers did document their protocol > and requested an IESG action and was refused. Do you believe that would > justify squatting on an already assigned number? I'm going to go with "yes", just to be contrary. At the point that the IESG refused to deal with 'em, they've effectively been ostracised from "the Internet community", and thus they are under no obligation to act within the rules and customs of that community. - Matt From alex at pssclabs.com Wed May 7 23:20:36 2014 From: alex at pssclabs.com (Alex Lesser) Date: Wed, 7 May 2014 23:20:36 +0000 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: <536969E5.6080608@cox.net> , Message-ID: <43422CF2-24C3-47CC-87F1-6F19D7A89E1E@pssclabs.com> www.pssclabs.com > On May 7, 2014, at 6:47 PM, "Shawn L" wrote: > > Do the ASR1k routers have this issue as well? I searched around but > couldn't find any information. > > > > ---------- Forwarded message ---------- > From: Irwin, Kevin > Date: Wed, May 7, 2014 at 10:39 AM > Subject: Re: Getting pretty close to default IPv4 route maximum for > 6500/7600 routers. > To: "nanog at nanog.org" > > > I¹m really surprised that most people have not hit this limit already, > especially on the 9K¹s, as it seems Cisco has some fuzzy math when it > comes to the 512K limit. > > Also make sure you have spare cards when you reload after changing the > scaling, those old cards don¹t always like to come back. > >> On 5/6/14, 7:01 PM, "Larry Sheldon" wrote: >> >>> On 5/6/2014 10:39 AM, Drew Weaver wrote: >>> >>> Just something to think about before it becomes a story the community >>> talks about for the next decade. >> >> Like we have for the last two? >> >> >> -- >> Requiescas in pace o email Two identifying characteristics >> of System Administrators: >> Ex turpi causa non oritur actio Infallibility, and the ability to >> learn from their mistakes. >> (Adapted from Stephen Pinker) > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you receive > this in error, please contact the sender and destroy any copies of this > document. From alumbis at gmail.com Wed May 7 23:50:11 2014 From: alumbis at gmail.com (Pete Lumbis) Date: Wed, 7 May 2014 19:50:11 -0400 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: <536969E5.6080608@cox.net> Message-ID: ASR1k doesn't have fixed TCAM like the 6500 and has a little more wiggle room, but it depends on the ESP you have installed. For example ESP 20 supports around 1,000,000 routes. http://www.cisco.com/c/en/us/products/collateral/routers/asr-1000-series-aggregation-services-routers/data_sheet_c78-450070.html?cachemode=refresh -Pete On Wed, May 7, 2014 at 6:45 PM, Shawn L wrote: > Do the ASR1k routers have this issue as well? I searched around but > couldn't find any information. > > > > ---------- Forwarded message ---------- > From: Irwin, Kevin > Date: Wed, May 7, 2014 at 10:39 AM > Subject: Re: Getting pretty close to default IPv4 route maximum for > 6500/7600 routers. > To: "nanog at nanog.org" > > > I¹m really surprised that most people have not hit this limit already, > especially on the 9K¹s, as it seems Cisco has some fuzzy math when it > comes to the 512K limit. > > Also make sure you have spare cards when you reload after changing the > scaling, those old cards don¹t always like to come back. > > On 5/6/14, 7:01 PM, "Larry Sheldon" wrote: > > >On 5/6/2014 10:39 AM, Drew Weaver wrote: > > > >> Just something to think about before it becomes a story the community > >> talks about for the next decade. > > > >Like we have for the last two? > > > > > >-- > >Requiescas in pace o email Two identifying characteristics > > of System Administrators: > >Ex turpi causa non oritur actio Infallibility, and the ability to > > learn from their mistakes. > > (Adapted from Stephen Pinker) > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you receive > this in error, please contact the sender and destroy any copies of this > document. > From mureninc at gmail.com Thu May 8 00:10:32 2014 From: mureninc at gmail.com (Constantine A. Murenin) Date: Wed, 7 May 2014 17:10:32 -0700 Subject: US patent 5473599 In-Reply-To: References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> Message-ID: On 7 May 2014 15:09, Owen DeLong wrote: >> CARP uses a VRRP version number that has not been defined by VRRP, >> hence there is no conflict there, either. The link from the quote >> above has a quote from Henning. > > Which means that in addition to squatting on the VRRP port, VRRP protocol number, not port number. # fgrep carp /etc/protocols carp 112 CARP vrrp # Common Address Redundancy Protocol For the protocol which doesn't even leave the LAN. > they are also squatting on a version number that I'm betting the IETF did not grant to them for that purpose and may use for another purpose at a later date. Yeah, right! How dare they?! The OpenBSD Project should have just closed the shop instead of providing an alternative and free virtual router/host redundancy protocol when Cisco said they're going to sue them if they implement the VRRP from the standards track! Who cares about the freedom of religion or expression? Everyone has to be Catholic and X, since that's what the state says. You can't even be an atheist or Y in the privacy of your own home and on your own LAN! Prohibited by IETF, since they might come over and take out your LAN! Also, would you please be so kind as to finally explain to us why Google can squat on the https port with SPDY, but OpenBSD cannot squat on the VRRP protocol with CARP? Especially since in the case of CARP, all communication is limited to a LAN segment? I mean, it is as if this non-standards-compliant-but-free CARP is being forced down your throat! Please enlighten us all on who's forcing CARP upon you. C. http://www.openbsd.org/lyrics.html#35 From tony at wicks.co.nz Wed May 7 22:53:12 2014 From: tony at wicks.co.nz (Tony Wicks) Date: Thu, 8 May 2014 10:53:12 +1200 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: <536969E5.6080608@cox.net> Message-ID: <007901cf6a47$2005ff80$6011fe80$@wicks.co.nz> > Do the ASR1k routers have this issue as well? I searched around but couldn't find any information. Not really (according to Cisco) - ESP10 - 1,000,000 IPv4 or 500,000 IPv6 routes ESP20 - 4,000,000 IPv4 or 4,000,000 IPv6 routes ESP40 - 4,000,000 IPv4 or 4,000,000 IPv6 routes ESP100-4,000,000 IPv4 or 4,000,000 IPv6 routes (hardware is capable of 8,000,000 routes) ESP200-4,000,000 IPv4 or 4,000,000 IPv6 routes From Valdis.Kletnieks at vt.edu Thu May 8 00:56:30 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 07 May 2014 20:56:30 -0400 Subject: US patent 5473599 In-Reply-To: Your message of "Wed, 07 May 2014 17:10:32 -0700." References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> Message-ID: <45453.1399510590@turing-police.cc.vt.edu> On Wed, 07 May 2014 17:10:32 -0700, "Constantine A. Murenin" said: > Also, would you please be so kind as to finally explain to us why > Google can squat on the https port with SPDY, Because it doesn't squat on the port. It politely asks "Do you speak SPDY, or just https?" and then listens to what the other end replies. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mureninc at gmail.com Thu May 8 01:03:07 2014 From: mureninc at gmail.com (Constantine A. Murenin) Date: Wed, 7 May 2014 18:03:07 -0700 Subject: US patent 5473599 In-Reply-To: <45453.1399510590@turing-police.cc.vt.edu> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <45453.1399510590@turing-police.cc.vt.edu> Message-ID: On 7 May 2014 17:56, wrote: > On Wed, 07 May 2014 17:10:32 -0700, "Constantine A. Murenin" said: > >> Also, would you please be so kind as to finally explain to us why >> Google can squat on the https port with SPDY, > > Because it doesn't squat on the port. It politely asks "Do you speak SPDY, > or just https?" and then listens to what the other end replies. Same for CARP -- it has its own version number, so, there's no conflict with the VRRP spec, either. C. From ikiris at gmail.com Thu May 8 01:15:41 2014 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 7 May 2014 20:15:41 -0500 Subject: US patent 5473599 In-Reply-To: References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <45453.1399510590@turing-police.cc.vt.edu> Message-ID: Except for that whole mac address thing, that crashes networks... -Blake On Wed, May 7, 2014 at 8:03 PM, Constantine A. Murenin wrote: > On 7 May 2014 17:56, wrote: >> On Wed, 07 May 2014 17:10:32 -0700, "Constantine A. Murenin" said: >> >>> Also, would you please be so kind as to finally explain to us why >>> Google can squat on the https port with SPDY, >> >> Because it doesn't squat on the port. It politely asks "Do you speak SPDY, >> or just https?" and then listens to what the other end replies. > > Same for CARP -- it has its own version number, so, there's no > conflict with the VRRP spec, either. > > C. From tony.li at tony.li Thu May 8 01:25:22 2014 From: tony.li at tony.li (Tony Li) Date: Wed, 7 May 2014 18:25:22 -0700 Subject: US patent 5473599 In-Reply-To: References: Message-ID: <89A70958-40BF-4D72-82CF-B4363277D07D@tony.li> On May 7, 2014, at 12:36 AM, Eygene Ryabinkin wrote: > VRRP/HSRP comes from Cisco (well, VRRP is RFC'ed for some time, but > its origin is Cisco too), I’m sorry, but this is 100% incorrect. HSRP comes from Cisco, but Cisco originally decided to not release the protocol to the IETF. [Stupid play on their part, but water under the bridge.] The IETF, realizing that this was useful technology, designed VRRP as a competitor to HSRP. Once that was well on its way to standardization, Cisco realized it missed the boat and finally publicly documented HSRP. Please get your facts straight. Tony From laszlo at heliacal.net Thu May 8 01:30:58 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Thu, 8 May 2014 01:30:58 +0000 Subject: US patent 5473599 In-Reply-To: References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <45453.1399510590@turing-po lice.cc.vt.edu> Message-ID: <0E09BFF0-4165-4595-8267-426F6FA2AF81@heliacal.net> This CARP thing is the best troll I've seen yet. Over a decade old and people are still on about it. -Laszlo On May 8, 2014, at 1:15 AM, Blake Dunlap wrote: > Except for that whole mac address thing, that crashes networks... > > -Blake > > On Wed, May 7, 2014 at 8:03 PM, Constantine A. Murenin > wrote: >> On 7 May 2014 17:56, wrote: >>> On Wed, 07 May 2014 17:10:32 -0700, "Constantine A. Murenin" said: >>> >>>> Also, would you please be so kind as to finally explain to us why >>>> Google can squat on the https port with SPDY, >>> >>> Because it doesn't squat on the port. It politely asks "Do you speak SPDY, >>> or just https?" and then listens to what the other end replies. >> >> Same for CARP -- it has its own version number, so, there's no >> conflict with the VRRP spec, either. >> >> C. From rs at seastrom.com Thu May 8 01:47:54 2014 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 07 May 2014 21:47:54 -0400 Subject: US patent 5473599 In-Reply-To: <20140507231953.GJ29444@hezmatt.org> (Matt Palmer's message of "Thu, 8 May 2014 09:19:53 +1000") References: <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <536A9B46.1030400@earthlink.net> <6E38BC9A-9C95-46A1-8302-E6FB2AD4553E@virtualized.org> <20140507231953.GJ29444@hezmatt.org> Message-ID: <86d2fpdos5.fsf@valhalla.seastrom.com> Matt Palmer writes: > On Wed, May 07, 2014 at 05:57:01PM -0400, David Conrad wrote: >> However, assume that the OpenBSD developers did document their protocol >> and requested an IESG action and was refused. Do you believe that would >> justify squatting on an already assigned number? > > I'm going to go with "yes", just to be contrary. At the point that the IESG > refused to deal with 'em, they've effectively been ostracised from "the > Internet community", and thus they are under no obligation to act within the > rules and customs of that community. The bar for an informational RFC is pretty darned low. I don't see anything in the datagram nature of "i'm alive, don't pull the trigger yet" that would preclude a UDP packet rather than naked IP. Hell, since it's not supposed to leave the LAN, one could even get a different ethertype and run entirely outside of IP. Of course, the organization that has trouble coming up with the bucks for an OUI might have trouble coming up with the (2014 dollars) $2915 for a publicly registered ethertype too. Must be a pretty horrible existence ("I pity the fool"?) to live on donated resources but lack the creativity to figure out a way to run a special fund raiser for an amount worthy of a Scout troop bake sale. Makes you wonder what the OpenBSD project could accomplish if they had smart people who could get along with others to the point of shaking them down for tax-deductible donations, doesn't it? -r From joelja at bogus.com Thu May 8 02:00:37 2014 From: joelja at bogus.com (joel jaeggli) Date: Wed, 07 May 2014 21:00:37 -0500 Subject: Please moderate yourselves, was: Re: US patent 5473599 In-Reply-To: <86d2fpdos5.fsf@valhalla.seastrom.com> References: <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <536A9B46.1030400@earthlink.net> <6E38BC9A-9C95-46A1-8302-E6FB2AD4553E@virtualized.org> <20140507231953.GJ29444@hezmatt.org> <86d2fpdos5.fsf@valhalla.seastrom.com> Message-ID: <536AE545.1030608@bogus.com> Notwithstanding any legitimate or illegitimate grievance associated with the sordid history of carp / vrrp / the us patent system / BSD forks and their respective participants. It's time to take a long weekend. thanks joel On 5/7/14, 8:47 PM, Rob Seastrom wrote: > > Matt Palmer writes: > >> On Wed, May 07, 2014 at 05:57:01PM -0400, David Conrad wrote: >>> However, assume that the OpenBSD developers did document their protocol >>> and requested an IESG action and was refused. Do you believe that would >>> justify squatting on an already assigned number? >> >> I'm going to go with "yes", just to be contrary. At the point that the IESG >> refused to deal with 'em, they've effectively been ostracised from "the >> Internet community", and thus they are under no obligation to act within the >> rules and customs of that community. > > The bar for an informational RFC is pretty darned low. I don't see > anything in the datagram nature of "i'm alive, don't pull the trigger > yet" that would preclude a UDP packet rather than naked IP. Hell, > since it's not supposed to leave the LAN, one could even get a > different ethertype and run entirely outside of IP. Of course, the > organization that has trouble coming up with the bucks for an OUI > might have trouble coming up with the (2014 dollars) $2915 for a > publicly registered ethertype too. > > Must be a pretty horrible existence ("I pity the fool"?) to live on > donated resources but lack the creativity to figure out a way to run a > special fund raiser for an amount worthy of a Scout troop bake sale. > Makes you wonder what the OpenBSD project could accomplish if they had > smart people who could get along with others to the point of shaking > them down for tax-deductible donations, doesn't it? > > -r > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From owen at delong.com Thu May 8 02:33:45 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 7 May 2014 19:33:45 -0700 Subject: US patent 5473599 In-Reply-To: <20140507231953.GJ29444@hezmatt.org> References: <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <536A9B46.1030400@earthlink.net> <6E38BC9A-9C95-46A1-8302-E6FB2AD4553E@virtualized.org> <20140507231953.GJ29444@hezmatt.org> Message-ID: On May 7, 2014, at 4:19 PM, Matt Palmer wrote: > On Wed, May 07, 2014 at 05:57:01PM -0400, David Conrad wrote: >> However, assume that the OpenBSD developers did document their protocol >> and requested an IESG action and was refused. Do you believe that would >> justify squatting on an already assigned number? > > I'm going to go with "yes", just to be contrary. At the point that the IESG > refused to deal with 'em, they've effectively been ostracised from "the > Internet community", and thus they are under no obligation to act within the > rules and customs of that community. > > - Matt I don’t believe for one second that the IESG refused to deal with ‘em. I do believe the IESG did not hand them everything they wanted on a silver platter in contravention of the established consensus process and that they failed to gain the consensus they wanted as easily as they hoped. I’d say they are not, in fact ostracized or even disenfranchised and that their abrogation of their obligations to act within the rules and customs of the internet community in developing network protocols for IP is more like a temper tantrum than a legitimate grievance. Owen From blair.trosper at gmail.com Thu May 8 02:37:58 2014 From: blair.trosper at gmail.com (Blair Trosper) Date: Wed, 7 May 2014 21:37:58 -0500 Subject: AWS Outage Message-ID: Can someone from AWS contact me off-list? You have an entire availability zone completely offline at us-east-1 that hasn't been detected, and it's been down for 20 minutes. From mpalmer at hezmatt.org Thu May 8 02:39:57 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Thu, 8 May 2014 12:39:57 +1000 Subject: US patent 5473599 In-Reply-To: References: <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <536A9B46.1030400@earthlink.net> <6E38BC9A-9C95-46A1-8302-E6FB2AD4553E@virtualized.org> <20140507231953.GJ29444@hezmatt.org> Message-ID: <20140508023957.GO29444@hezmatt.org> On Wed, May 07, 2014 at 07:33:45PM -0700, Owen DeLong wrote: > On May 7, 2014, at 4:19 PM, Matt Palmer wrote: > > On Wed, May 07, 2014 at 05:57:01PM -0400, David Conrad wrote: > >> However, assume that the OpenBSD developers did document their protocol > >> and requested an IESG action and was refused. Do you believe that would > >> justify squatting on an already assigned number? > > > > I'm going to go with "yes", just to be contrary. At the point that the IESG > > refused to deal with 'em, they've effectively been ostracised from "the > > Internet community", and thus they are under no obligation to act within the > > rules and customs of that community. > > I don’t believe for one second that the IESG refused to deal with ‘em. Neither do I. That wasn't the question I was answering, though -- the scenario described was "assume that...". - Matt From rdrake at direcpath.com Thu May 8 03:58:08 2014 From: rdrake at direcpath.com (Robert Drake) Date: Wed, 7 May 2014 23:58:08 -0400 Subject: US patent 5473599 In-Reply-To: <86d2fpdos5.fsf@valhalla.seastrom.com> References: <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <536A9B46.1030400@earthlink.net> <6E38BC9A-9C95-46A1-8302-E6FB2AD4553E@virtualized.org> <20140507231953.GJ29444@hezmatt.org> <86d2fpdos5.fsf@valhalla.seastrom.com> Message-ID: <536B00D0.1030005@direcpath.com> On 5/7/2014 9:47 PM, Rob Seastrom wrote: > The bar for an informational RFC is pretty darned low. I don't see > anything in the datagram nature of "i'm alive, don't pull the trigger > yet" that would preclude a UDP packet rather than naked IP. Hell, > since it's not supposed to leave the LAN, one could even get a > different ethertype and run entirely outside of IP. Of course, the > organization that has trouble coming up with the bucks for an OUI > might have trouble coming up with the (2014 dollars) $2915 for a > publicly registered ethertype too. Meh.. it's open source. If I design a toaster that spits flames when you put bagels in it, then I put the design on github and forget about it, I shouldn't be held responsible for someone adding it to their network and setting fire to a router or two. A problem that the developer doesn't have isn't a problem. Oh, the user community noticed an interoperability issue? What user community? I was building this toaster for myself. I released the plans in case it inspires or helps others. If fire isn't what you need then maybe you can modify it to do what's needed.* Now, the bar for an informational RFC is pretty low. Especially for people who have written them before. Those people seem to think one is needed in this case so they might want to get started writing it. Then patches to the man pages covering the past issues can be added to document things, and a patch can be issued with the new OUI, ethertype, or port number, whichever the RFC decides to go for. > Must be a pretty horrible existence ("I pity the fool"?) to live on > donated resources but lack the creativity to figure out a way to run a > special fund raiser for an amount worthy of a Scout troop bake sale. > Makes you wonder what the OpenBSD project could accomplish if they had > smart people who could get along with others to the point of shaking > them down for tax-deductible donations, doesn't it? > > -r > The money could also be donated by parties interested in solutions. Open source is about people finding a problem and fixing it for their own benefit then giving the fix away to the community for everyone's benefit. I know in the past the OpenBSD community has been harsh with outsiders who submit patches. I honestly expect the same response in this case, especially because of the underlying drama associated with it, but without trying first it just seems like the network community is whining without being helpful at all. To be fair, we're used to dealing with vendors where we can't change things so we bitch about them until they fix code for us. In this case there is no "them" to bitch about. We (the community) wrote the code and it's up to us to fix it. If you don't consider yourself part of the OpenBSD community then you shouldn't be using their products and encountering problems, right? * yeah, that's a very insular view and not really acceptable in the grown up world, but everyone's been beating them down over this and sometimes you end up taking your ball and going home because you're tired of people criticizing your plays. From owen at delong.com Thu May 8 05:04:23 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 7 May 2014 22:04:23 -0700 Subject: US patent 5473599 In-Reply-To: <536B00D0.1030005@direcpath.com> References: <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <536A9B46.1030400@earthlink.net> <6E38BC9A-9C95-46A1-8302-E6FB2AD4553E@virtualized.org> <20140507231953.GJ29444@hezmatt.org> <86d2fpdos5.fsf@valhalla.seastrom.com> <536B00D0.1030005@direcpath.com> Message-ID: On May 7, 2014, at 20:58 , Robert Drake wrote: > > On 5/7/2014 9:47 PM, Rob Seastrom wrote: >> The bar for an informational RFC is pretty darned low. I don't see >> anything in the datagram nature of "i'm alive, don't pull the trigger >> yet" that would preclude a UDP packet rather than naked IP. Hell, >> since it's not supposed to leave the LAN, one could even get a >> different ethertype and run entirely outside of IP. Of course, the >> organization that has trouble coming up with the bucks for an OUI >> might have trouble coming up with the (2014 dollars) $2915 for a >> publicly registered ethertype too. > > Meh.. it's open source. If I design a toaster that spits flames when you put bagels in it, then I put the design on github and forget about it, I shouldn't be held responsible for someone adding it to their network and setting fire to a router or two. > > A problem that the developer doesn't have isn't a problem. Oh, the user community noticed an interoperability issue? What user community? I was building this toaster for myself. I released the plans in case it inspires or helps others. If fire isn't what you need then maybe you can modify it to do what's needed.* > > Now, the bar for an informational RFC is pretty low. Especially for people who have written them before. Those people seem to think one is needed in this case so they might want to get started writing it. Then patches to the man pages covering the past issues can be added to document things, and a patch can be issued with the new OUI, ethertype, or port number, whichever the RFC decides to go for. > >> Must be a pretty horrible existence ("I pity the fool"?) to live on >> donated resources but lack the creativity to figure out a way to run a >> special fund raiser for an amount worthy of a Scout troop bake sale. >> Makes you wonder what the OpenBSD project could accomplish if they had >> smart people who could get along with others to the point of shaking >> them down for tax-deductible donations, doesn't it? >> >> -r >> > The money could also be donated by parties interested in solutions. > > Open source is about people finding a problem and fixing it for their own benefit then giving the fix away to the community for everyone's benefit. I know in the past the OpenBSD community has been harsh with outsiders who submit patches. I honestly expect the same response in this case, especially because of the underlying drama associated with it, but without trying first it just seems like the network community is whining without being helpful at all. > > To be fair, we're used to dealing with vendors where we can't change things so we bitch about them until they fix code for us. In this case there is no "them" to bitch about. We (the community) wrote the code and it's up to us to fix it. If you don't consider yourself part of the OpenBSD community then you shouldn't be using their products and encountering problems, right? > > * yeah, that's a very insular view and not really acceptable in the grown up world, but everyone's been beating them down over this and sometimes you end up taking your ball and going home because you're tired of people criticizing your plays. If they take their ball and go home, that's fine. The problem is that they seem to occasionally have their ball brought (by systems administrators) to networks where the network engineers are already running VRRP on routers (for example) and because: 1. The systems administrators don't necessarily have in-depth knowledge of what the network is doing. 2. The network administrators don't necessarily get told about every detail of the Systems administrators intentions. 3. There's no knowledge among the two groups that either is using the other protocol (CARP vs. VRRP) 4. There's even less knowledge that the two are going to fight with each other. 5. You encounter a network outage where the network engineers spend a bunch of time chasing down rogue duplicate MAC addresses messing up the switch forwarding tables until they find the (recently activated) systems CRAP^H^H^HARPing all over their network and breaking it for everyone. OTOH, if the BSD folk had (or in the future did) fix CARP so that instead of trying to steal VRRP MAC addresses in a conflicting manner, it would either use a non-conflicting MAC prefix (how about one with the locally assigned bit set, such as the VRRP Mac | 0x02000:0000:0000) and make a legitimate attempt at getting CARP into an RFC with a legitimately assigned protocol number, everyone could get along without issue. Yes, you can work around the current issue ONCE YOU KNOW ABOUT IT. Unfortunately, the most common way of learning about this particular little lovely OpenBSD time-bomb is when it explodes all over a previously operational network, usually rendering it non-operational until the problem can be identified, usually by people who had no knowledge of how it got created. Owen From jfmezei_nanog at vaxination.ca Thu May 8 05:32:54 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 08 May 2014 01:32:54 -0400 Subject: Does Telus traffic shape their DSL or Fibre subscribers at all? In-Reply-To: References: Message-ID: <536B1706.7080005@vaxination.ca> On 14-05-07 18:19, Landon wrote: > Before I go chasing this down does Telus traffic shape their DSL or Fibre > subscribers? Customer using 50Mbps fiber gets excellent speeds on > speedtest.net but looks like http and ssh (scp) transfers are capped at > 1MBps (not 1Mbps) for non-popular hosts but uncapped for popular hosts. > Just a hunch. If Telus discriminates between some web site and others, it is a violation of ITMP rules http://crtc.gc.ca/eng/archive/2009/2009-657.htm I have not heard of of stories of Telus throttling. And any throttling/traffic shaping MUST be announced as part of the package you buy, and there is no mention of it (I could find) on the Telus web site. Is the speedtest on those unpopular sites always amost the same speed or does it vary from hour to hour/day to day ? aka: programmed speed limit, or just congestion on a link ? Note that purposefully buying insufficient capacity on a transit link to/from certain web sites would be an untested grey area under ITMP rules but could still make for a valid complain under both ITMP and 27(2) (undue preference) of the Telecom Act. You would have to report the performnce problem to Telus to see what they say. If they confirm it is a problem and it will be fixed, then you have no real recourse. If they confirm these links are purposefully kept congested, then time to sound the bell and muster the army :-) From mark.tinka at seacom.mu Thu May 8 05:51:13 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 8 May 2014 07:51:13 +0200 Subject: bgp convergence problem In-Reply-To: <4473ec67ca154791b977efe46c4d8ef9@BY2PR03MB505.namprd03.prod.outlook.com> References: <53685E02.7060309@gmail.com> <4473ec67ca154791b977efe46c4d8ef9@BY2PR03MB505.namprd03.prod.outlook.com> Message-ID: <201405080751.13601.mark.tinka@seacom.mu> On Wednesday, May 07, 2014 07:28:46 PM Peter Rubenstein wrote: > Operationally speaking, AS1 should not be leaking routes > from one upstream to the other. Bad route policy. > Also, AS3 should not accept routes from AS1 that don't > belong to it. Customer router filtering would prevent > this. How I wish this happened in real life. We are chasing route leaks several AS's down the path that are not even remotely connected to us on a weekly basis. But I guess that's what they pay us for :-(. 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 shopik at inblock.ru Thu May 8 06:15:26 2014 From: shopik at inblock.ru (Nikolay Shopik) Date: Thu, 8 May 2014 10:15:26 +0400 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: <536969E5.6080608@cox.net> Message-ID: <1D80627D-AF5C-4E2D-B93D-1EEF624BAC0E@inblock.ru> Asr1002-f may have problem as it limited to 512k iirc > On 08 мая 2014 г., at 2:45, Shawn L wrote: > > Do the ASR1k routers have this issue as well? I searched around but > couldn't find any information. > > > > ---------- Forwarded message ---------- > From: Irwin, Kevin > Date: Wed, May 7, 2014 at 10:39 AM > Subject: Re: Getting pretty close to default IPv4 route maximum for > 6500/7600 routers. > To: "nanog at nanog.org" > > > I¹m really surprised that most people have not hit this limit already, > especially on the 9K¹s, as it seems Cisco has some fuzzy math when it > comes to the 512K limit. > > Also make sure you have spare cards when you reload after changing the > scaling, those old cards don¹t always like to come back. > >> On 5/6/14, 7:01 PM, "Larry Sheldon" wrote: >> >>> On 5/6/2014 10:39 AM, Drew Weaver wrote: >>> >>> Just something to think about before it becomes a story the community >>> talks about for the next decade. >> >> Like we have for the last two? >> >> >> -- >> Requiescas in pace o email Two identifying characteristics >> of System Administrators: >> Ex turpi causa non oritur actio Infallibility, and the ability to >> learn from their mistakes. >> (Adapted from Stephen Pinker) > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you receive > this in error, please contact the sender and destroy any copies of this > document. From hb-nanog at bsws.de Thu May 8 07:35:00 2014 From: hb-nanog at bsws.de (Henning Brauer) Date: Thu, 8 May 2014 09:35:00 +0200 Subject: US patent 5473599 In-Reply-To: References: <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <45453.1399510590@turing-police.cc.vt.edu> Message-ID: <20140508073500.GH26826@quigon.bsws.de> * Blake Dunlap [2014-05-08 03:19]: > Except for that whole mac address thing, that crashes networks... this lie doesn't get any more true by repeating them over and over. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting From hb-nanog at bsws.de Thu May 8 07:45:02 2014 From: hb-nanog at bsws.de (Henning Brauer) Date: Thu, 8 May 2014 09:45:02 +0200 Subject: US patent 5473599 In-Reply-To: <536B00D0.1030005@direcpath.com> References: <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <536A9B46.1030400@earthlink.net> <6E38BC9A-9C95-46A1-8302-E6FB2AD4553E@virtualized.org> <20140507231953.GJ29444@hezmatt.org> <86d2fpdos5.fsf@valhalla.seastrom.com> <536B00D0.1030005@direcpath.com> Message-ID: <20140508074502.GI26826@quigon.bsws.de> * Robert Drake [2014-05-08 06:02]: > On 5/7/2014 9:47 PM, Rob Seastrom wrote: > Now, the bar for an informational RFC is pretty low. Especially for people > who have written them before. Those people seem to think one is needed in > this case so they might want to get started writing it. Then patches to the > man pages covering the past issues can be added to document things, and a > patch can be issued with the new OUI, ethertype, or port number, whichever > the RFC decides to go for. spot on. but apparently nanog is just about whining for the sake of whining. > >Must be a pretty horrible existence ("I pity the fool"?) to live on > >donated resources but lack the creativity to figure out a way to run a > >special fund raiser for an amount worthy of a Scout troop bake sale. > >Makes you wonder what the OpenBSD project could accomplish if they had > >smart people who could get along with others to the point of shaking > >them down for tax-deductible donations, doesn't it? > The money could also be donated by parties interested in solutions. again, spot on. > Open source is about people finding a problem and fixing it for their own > benefit then giving the fix away to the community for everyone's benefit. I > know in the past the OpenBSD community has been harsh with outsiders who > submit patches. I honestly expect the same response in this case, > especially because of the underlying drama associated with it, but without > trying first it just seems like the network community is whining without > being helpful at all. I think we are pretty damn open for patches from outside. And I have said it before, if somebody does the work and gives us a mac addr range to use without unreasonable terms and conditions attached, we'll almost certainly use it. Chances increased if it is a full patch with code for the transition period. Sorry, doesn't fit nanog, since that would require work instead of just whining and bitching. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting From hb-nanog at bsws.de Thu May 8 07:48:26 2014 From: hb-nanog at bsws.de (Henning Brauer) Date: Thu, 8 May 2014 09:48:26 +0200 Subject: US patent 5473599 In-Reply-To: References: <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <536A9B46.1030400@earthlink.net> <6E38BC9A-9C95-46A1-8302-E6FB2AD4553E@virtualized.org> <20140507231953.GJ29444@hezmatt.org> <86d2fpdos5.fsf@valhalla.seastrom.com> <536B00D0.1030005@direcpath.com> Message-ID: <20140508074826.GJ26826@quigon.bsws.de> * Owen DeLong [2014-05-08 07:16]: > If they take their ball and go home, that's fine. The problem is that they seem to occasionally have their ball brought (by systems administrators) to networks where the network engineers are already running VRRP on routers (for example) and because: > > 1. The systems administrators don't necessarily have in-depth knowledge of what the network is doing. nothing technology can solve > 2. The network administrators don't necessarily get told about every detail of the Systems administrators intentions. nothing technology can solve > 3. There's no knowledge among the two groups that either is using the other protocol (CARP vs. VRRP) nothing technology can solve > 4. There's even less knowledge that the two are going to fight with each other. that is a lie, they coexist just fine. even with "conflicting" mac addrs you just get log spam. > OTOH, if the BSD folk had (or in the future did) fix CARP so that instead of trying to steal VRRP MAC addresses in a conflicting manner, it would either use a non-conflicting MAC prefix (how about one with the locally assigned bit set, such as the VRRP Mac | 0x02000:0000:0000) and make a legitimate attempt at getting CARP into an RFC with a legitimately assigned protocol number, everyone could get along without issue. awaiting your diff. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting From hb-nanog at bsws.de Thu May 8 07:49:54 2014 From: hb-nanog at bsws.de (Henning Brauer) Date: Thu, 8 May 2014 09:49:54 +0200 Subject: US patent 5473599 In-Reply-To: References: <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <536A9B46.1030400@earthlink.net> <6E38BC9A-9C95-46A1-8302-E6FB2AD4553E@virtualized.org> <20140507231953.GJ29444@hezmatt.org> Message-ID: <20140508074954.GK26826@quigon.bsws.de> * Owen DeLong [2014-05-08 04:36]: > I don’t believe for one second that the IESG refused to deal with ‘em. you're free to believe whatever you want and ignore facts. > I do believe the IESG did not hand them everything they wanted on a > silver platter in contravention of the established consensus process > and that they failed to gain the consensus they wanted as easily as > they hoped. lie. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting From hb-nanog at bsws.de Thu May 8 07:54:02 2014 From: hb-nanog at bsws.de (Henning Brauer) Date: Thu, 8 May 2014 09:54:02 +0200 Subject: US patent 5473599 In-Reply-To: References: <86d2fpa4ok.fsf@valhalla.seastrom.com> Message-ID: <20140508075402.GM26826@quigon.bsws.de> * Gary Buhrmaster [2014-05-08 00:43]: > But (presuming no adjustments) the patent is now expired, > and the OpenBSD team could now release CARPv2 (or > whatever they decide to call it) which would implement the > standard, should they wish to work and play well with the > standards bodies and community. why would we give up authentication and adress family independence? the vrrp dilemma forced us to invent carp instead, but now carp is far superior. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting From saku at ytti.fi Thu May 8 10:10:40 2014 From: saku at ytti.fi (Saku Ytti) Date: Thu, 8 May 2014 13:10:40 +0300 Subject: US patent 5473599 In-Reply-To: <20140508075402.GM26826@quigon.bsws.de> References: <86d2fpa4ok.fsf@valhalla.seastrom.com> <20140508075402.GM26826@quigon.bsws.de> Message-ID: <20140508101040.GA8587@pob.ytti.fi> If OBSD can't afford MAC addresses but does not object to them in principle, I can give forever IRU for 256 MAC addresses to OBSD for 0USD one-time fee. -- ++ytti From hb-nanog at bsws.de Thu May 8 10:25:39 2014 From: hb-nanog at bsws.de (Henning Brauer) Date: Thu, 8 May 2014 12:25:39 +0200 Subject: US patent 5473599 In-Reply-To: <13Fy+KEwAS9ES4nJdbx3lzHXZjE@R6+CFZQ3w24cS9wlnBBSNDkcdZI> References: <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <45453.1399510590@turing-police.cc.vt.edu> <20140508073500.GH26826@quigon.bsws.de> <13Fy+KEwAS9ES4nJdbx3lzHXZjE@R6+CFZQ3w24cS9wlnBBSNDkcdZI> Message-ID: <20140508102539.GH32502@quigon.bsws.de> * Eygene Ryabinkin [2014-05-08 11:12]: > Henning, > Thu, May 08, 2014 at 09:35:00AM +0200, Henning Brauer wrote: > > * Blake Dunlap [2014-05-08 03:19]: > > > Except for that whole mac address thing, that crashes networks... > > this lie doesn't get any more true by repeating them over and over. > So, you insist that VRRP and CARP instances with the same VRID/VHID in > the same L2 segment will coexist peacefully? I had seen problems with > such setup, so if you can enlighten me how to overcome them (rather > than saying "you must choose different VRID/VHID") -- it will be very > good. you shouldn't see issues but log spam. I haven't seen anotehr issue and I haven't seen a single report claiming otherwise over the last 10 years either, minus the mentioned cisco 3600 "don't bother checking the version number field before parsing on" screwup. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting From hb-nanog at bsws.de Thu May 8 10:31:23 2014 From: hb-nanog at bsws.de (Henning Brauer) Date: Thu, 8 May 2014 12:31:23 +0200 Subject: US patent 5473599 In-Reply-To: <20140508101040.GA8587@pob.ytti.fi> References: <86d2fpa4ok.fsf@valhalla.seastrom.com> <20140508075402.GM26826@quigon.bsws.de> <20140508101040.GA8587@pob.ytti.fi> Message-ID: <20140508103123.GK32502@quigon.bsws.de> * Saku Ytti [2014-05-08 12:14]: > If OBSD can't afford MAC addresses but does not object to them in principle, I > can give forever IRU for 256 MAC addresses to OBSD for 0USD one-time fee. congratulations, that is far ahead of just whining. when/if we change the mac addrs, the new range should be utterly correct and not just "a little bit better". not sure this would qualify. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting From nick at foobar.org Thu May 8 11:00:00 2014 From: nick at foobar.org (Nick Hilliard) Date: Thu, 08 May 2014 12:00:00 +0100 Subject: US patent 5473599 In-Reply-To: <20140508102539.GH32502@quigon.bsws.de> References: <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <45453.1399510590@turing-police.cc.vt.edu> <20140508073500.GH26826@quigon.bsws.de> <13Fy+KEwAS9ES4nJdbx3lzHXZjE@R6+CFZQ3w24cS9wlnBBSNDkcdZI> <20140508102539.GH32502@quigon.bsws.de> Message-ID: <536B63B0.6070706@foobar.org> On 08/05/2014 11:25, Henning Brauer wrote: > you shouldn't see issues but log spam. maybe you misunderstand the problem. If you have vrrp and carp on the same vlan, using the same vrrp group ID as VHID, then each virtual IP will arp for the same mac address on that vlan. This messes up the switch's forwarding table for that particular vlan because it sees multiple entries from different ports for the same mac address. Switches will not do unicast replication in this situation, but instead will forward all traffic for a particular destination mac address to the port which announced the mac address most recently. In other words, this is much more serious than log spam: it is guaranteed to cause network downtime, because you cannot have two hosts on the same L2 domain using the same mac address, but doing different things. Nick From hb-nanog at bsws.de Thu May 8 11:09:38 2014 From: hb-nanog at bsws.de (Henning Brauer) Date: Thu, 8 May 2014 13:09:38 +0200 Subject: US patent 5473599 In-Reply-To: <536B63B0.6070706@foobar.org> References: <45453.1399510590@turing-police.cc.vt.edu> <20140508073500.GH26826@quigon.bsws.de> <13Fy+KEwAS9ES4nJdbx3lzHXZjE@R6+CFZQ3w24cS9wlnBBSNDkcdZI> <20140508102539.GH32502@quigon.bsws.de> <536B63B0.6070706@foobar.org> Message-ID: <20140508110938.GM32502@quigon.bsws.de> * Nick Hilliard [2014-05-08 13:03]: > On 08/05/2014 11:25, Henning Brauer wrote: > > you shouldn't see issues but log spam. > maybe you misunderstand the problem. If you have vrrp and carp on the same > vlan, using the same vrrp group ID as VHID, then each virtual IP will arp > for the same mac address on that vlan. correct. > This messes up the switch's forwarding table for that particular vlan > because it sees multiple entries from different ports for the same mac > address. correct. my switches seem to deal with that, wether they have special handling for that mac addr range or not i dunno. again, stress the fact that afair we have gotten zero reports about that "issue" for 10 years, it obviously means that either 1) a vast majority of switches deal with it just fine 2) people know that vhids shouldn't clash and avoid that -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting From job at instituut.net Thu May 8 11:11:27 2014 From: job at instituut.net (Job Snijders) Date: Thu, 8 May 2014 13:11:27 +0200 Subject: US patent 5473599 In-Reply-To: <20140508103123.GK32502@quigon.bsws.de> References: <86d2fpa4ok.fsf@valhalla.seastrom.com> <20140508075402.GM26826@quigon.bsws.de> <20140508101040.GA8587@pob.ytti.fi> <20140508103123.GK32502@quigon.bsws.de> Message-ID: <20140508111127.GZ9366@Eleanor.local> On Thu, May 08, 2014 at 12:31:23PM +0200, Henning Brauer wrote: > * Saku Ytti [2014-05-08 12:14]: > > If OBSD can't afford MAC addresses but does not object to them in principle, I > > can give forever IRU for 256 MAC addresses to OBSD for 0USD one-time fee. > > when/if we change the mac addrs, the new range should be utterly > correct and not just "a little bit better". not sure this would > qualify. I fail to see the issue with using these addresses, they are globally unique and correctly administrated at IEEE, Saku Ytti can do whatever he wants (like giving indefeasible rights of use to the OpenBSD Foundation). It won't come any cheaper than this (I am Dutch, I recognise a good deal when I see one!). If the team accepts I'll submit a patch to wireshark so decoded packets containing MACs from that block are properly identified as "OpenBSD". Kind regards, Job From nick at foobar.org Thu May 8 11:15:10 2014 From: nick at foobar.org (Nick Hilliard) Date: Thu, 08 May 2014 12:15:10 +0100 Subject: US patent 5473599 In-Reply-To: <20140508110938.GM32502@quigon.bsws.de> References: <45453.1399510590@turing-police.cc.vt.edu> <20140508073500.GH26826@quigon.bsws.de> <13Fy+KEwAS9ES4nJdbx3lzHXZjE@R6+CFZQ3w24cS9wlnBBSNDkcdZI> <20140508102539.GH32502@quigon.bsws.de> <536B63B0.6070706@foobar.org> <20140508110938.GM32502@quigon.bsws.de> Message-ID: <536B673E.7030407@foobar.org> On 08/05/2014 12:09, Henning Brauer wrote: > my switches seem to deal with that, wether they have special handling > for that mac addr range or not i dunno. I've seen this problem cause downtime on production networks. fyi, it will probably work fine on hubs, but not on switches. > again, stress the fact that afair we have gotten zero reports about > that "issue" for 10 years, it obviously means that either > 1) a vast majority of switches deal with it just fine > 2) people know that vhids shouldn't clash and avoid that https://www.google.com/search?q=vrrp+carp+incompatible Several of the results refer to openbsd mailing list postings. Nick From ahebert at pubnix.net Thu May 8 11:31:00 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 08 May 2014 07:31:00 -0400 Subject: US patent 5473599 In-Reply-To: <45453.1399510590@turing-police.cc.vt.edu> References: <5356279F.8020405@foobar.org> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <535C1D57.2040506@foobar.org> <20140506072237.GI30611@quigon.bsws.de> <5573.1399388210@turing-police.cc.vt.edu> <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <45453.1399510590@turing-police.cc.vt.edu> Message-ID: <536B6AF4.9060300@pubnix.net> And that's why C. should use a more appropriate example to defend his position. By this thread, I suspect, that whoever dealt with those different organization for OpenBSD & CARP, lacked the skills to accomplish the task and got shut down for being an ass. PS: Being of the Church of FreeBSD, I freely acknowledge that I got no clue about the scope of the drama that CARP was involved with. But I was aware of Cisco/VRRP/HSRP patent and CARP and found CIsco to be a bit of a bully to actually enforce it for such a simple technology. That being said, I was never attracted to OpenBSD for some "gut" reason... I know why now =D ----- 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 05/07/14 20:56, Valdis.Kletnieks at vt.edu wrote: > On Wed, 07 May 2014 17:10:32 -0700, "Constantine A. Murenin" said: > >> Also, would you please be so kind as to finally explain to us why >> Google can squat on the https port with SPDY, > Because it doesn't squat on the port. It politely asks "Do you speak SPDY, > or just https?" and then listens to what the other end replies. From geraint at koding.com Thu May 8 11:46:28 2014 From: geraint at koding.com (Geraint Jones) Date: Thu, 8 May 2014 23:46:28 +1200 Subject: US patent 5473599 In-Reply-To: <20140508110938.GM32502@quigon.bsws.de> References: <45453.1399510590@turing-police.cc.vt.edu> <20140508073500.GH26826@quigon.bsws.de> <13Fy+KEwAS9ES4nJdbx3lzHXZjE@R6+CFZQ3w24cS9wlnBBSNDkcdZI> <20140508102539.GH32502@quigon.bsws.de> <536B63B0.6070706@foobar.org> <20140508110938.GM32502@quigon.bsws.de> Message-ID: <83E73E8B-B8BE-4D3B-9F15-811760C12886@koding.com> > On 8/05/2014, at 11:09 pm, Henning Brauer wrote: > > * Nick Hilliard [2014-05-08 13:03]: >>> On 08/05/2014 11:25, Henning Brauer wrote: >>> you shouldn't see issues but log spam. >> maybe you misunderstand the problem. If you have vrrp and carp on the same >> vlan, using the same vrrp group ID as VHID, then each virtual IP will arp >> for the same mac address on that vlan. > > correct. > >> This messes up the switch's forwarding table for that particular vlan >> because it sees multiple entries from different ports for the same mac >> address. > > correct. > > my switches seem to deal with that, wether they have special handling > for that mac addr range or not i dunno. What make and model switches? I am sure someone here can easily verify their behaviour and if they have some baked in pixie dust to handle this. But a pure l2 switch should not be able to mask the issue given all it has to go on is MAC so you would either see excessive flooding of a unicast MAC, or black holing of VRRP or CARP. Neither of which are desirable and given that the flooding would lead to serious security issues worries me from such a security focused community as the OpenBSD community professes to be. > > again, stress the fact that afair we have gotten zero reports about > that "issue" for 10 years, it obviously means that either > 1) a vast majority of switches deal with it just fine > 2) people know that vhids shouldn't clash and avoid that > > -- > Henning Brauer, hb at bsws.de, henning at openbsd.org > BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de > Full-Service ISP - Secure Hosting, Mail and DNS Services > Dedicated Servers, Rootservers, VMs/PVS, Application Hosting From job at instituut.net Thu May 8 13:39:16 2014 From: job at instituut.net (Job Snijders) Date: Thu, 8 May 2014 15:39:16 +0200 Subject: US patent 5473599 In-Reply-To: <20140508074826.GJ26826@quigon.bsws.de> References: <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <536A9B46.1030400@earthlink.net> <6E38BC9A-9C95-46A1-8302-E6FB2AD4553E@virtualized.org> <20140507231953.GJ29444@hezmatt.org> <86d2fpdos5.fsf@valhalla.seastrom.com> <536B00D0.1030005@direcpath.com> <20140508074826.GJ26826@quigon.bsws.de> Message-ID: <20140508133916.GC9366@Eleanor.local> On Thu, May 08, 2014 at 09:48:26AM +0200, Henning Brauer wrote: > > awaiting your diff. http://marc.info/?l=openbsd-tech&m=139955603603070&w=2 Kind regards, Job From morrowc.lists at gmail.com Thu May 8 14:41:21 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 8 May 2014 10:41:21 -0400 Subject: bgp convergence problem In-Reply-To: <201405080751.13601.mark.tinka@seacom.mu> References: <53685E02.7060309@gmail.com> <4473ec67ca154791b977efe46c4d8ef9@BY2PR03MB505.namprd03.prod.outlook.com> <201405080751.13601.mark.tinka@seacom.mu> Message-ID: On Thu, May 8, 2014 at 1:51 AM, Mark Tinka wrote: > On Wednesday, May 07, 2014 07:28:46 PM Peter Rubenstein > wrote: > >> Operationally speaking, AS1 should not be leaking routes >> from one upstream to the other. Bad route policy. ideally it'd be nice to be valley-free... so to speak. >> Also, AS3 should not accept routes from AS1 that don't >> belong to it. Customer router filtering would prevent >> this. always with the route filtering... routes want to be free man, free! > How I wish this happened in real life. > > We are chasing route leaks several AS's down the path that > are not even remotely connected to us on a weekly basis. But > I guess that's what they pay us for :-(. if only there were some technology that could be used to thwart such things. From Kevin.Irwin at cinbell.com Thu May 8 14:45:09 2014 From: Kevin.Irwin at cinbell.com (Irwin, Kevin) Date: Thu, 8 May 2014 14:45:09 +0000 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: <1D80627D-AF5C-4E2D-B93D-1EEF624BAC0E@inblock.ru> Message-ID: It depends, you can put in a table-map to stop the routes from being installed into the FIB/RIB on an ASR-1K with 2GB of RAM you can then have up to 2 million IPv4 routes. Alternatively, if you are not using your ASR-1k to forward traffic, I think you could also just turn off CEF and have the same result. On 5/8/14, 2:15 AM, "Nikolay Shopik" wrote: >Asr1002-f may have problem as it limited to 512k iirc > >> On 08 мая 2014 г., at 2:45, Shawn L wrote: >> >> Do the ASR1k routers have this issue as well? I searched around but >> couldn't find any information. >> >> >> >> ---------- Forwarded message ---------- >> From: Irwin, Kevin >> Date: Wed, May 7, 2014 at 10:39 AM >> Subject: Re: Getting pretty close to default IPv4 route maximum for >> 6500/7600 routers. >> To: "nanog at nanog.org" >> >> >> I¹m really surprised that most people have not hit this limit already, >> especially on the 9K¹s, as it seems Cisco has some fuzzy math when it >> comes to the 512K limit. >> >> Also make sure you have spare cards when you reload after changing the >> scaling, those old cards don¹t always like to come back. >> >>> On 5/6/14, 7:01 PM, "Larry Sheldon" wrote: >>> >>>> On 5/6/2014 10:39 AM, Drew Weaver wrote: >>>> >>>> Just something to think about before it becomes a story the community >>>> talks about for the next decade. >>> >>> Like we have for the last two? >>> >>> >>> -- >>> Requiescas in pace o email Two identifying characteristics >>> of System Administrators: >>> Ex turpi causa non oritur actio Infallibility, and the ability to >>> learn from their mistakes. >>> (Adapted from Stephen Pinker) >> >> The information transmitted is intended only for the person or entity to >> which it is addressed and may contain confidential and/or privileged >> material. Any review, retransmission, dissemination or other use of, or >> taking of any action in reliance upon, this information by persons or >> entities other than the intended recipient is prohibited. If you receive >> this in error, please contact the sender and destroy any copies of this >> document. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and destroy any copies of this document. From mark.tinka at seacom.mu Thu May 8 14:51:41 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 8 May 2014 16:51:41 +0200 Subject: bgp convergence problem In-Reply-To: References: <53685E02.7060309@gmail.com> <201405080751.13601.mark.tinka@seacom.mu> Message-ID: <201405081651.41649.mark.tinka@seacom.mu> On Thursday, May 08, 2014 04:41:21 PM Christopher Morrow wrote: > if only there were some technology that could be used to > thwart such things. It's gotten to a point where a repeat offender has me wound up enough to prepend his AS into some of my paths. I wish there was a simpler way to "turn them off". 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 Thu May 8 14:51:32 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 8 May 2014 16:51:32 +0200 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: Message-ID: <201405081651.33077.mark.tinka@seacom.mu> On Thursday, May 08, 2014 04:45:09 PM Irwin, Kevin wrote: > It depends, you can put in a table-map to stop the routes > from being installed into the FIB/RIB on an ASR-1K with > 2GB of RAM you can then have up to 2 million IPv4 > routes. Helpful only if you don't want to forward traffic through the box, in which case running IOS XE on a VM on a server is a more lasting idea :-). 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 paveldimow at gmail.com Thu May 8 15:20:20 2014 From: paveldimow at gmail.com (Pavel Dimow) Date: Thu, 8 May 2014 17:20:20 +0200 Subject: NAT (PAT) log Message-ID: Hello, as we are running out of ipv4 addresses we started to think of dual stack deployment in our network and that means we will soon need to have some NAT in place (NAT44).However I am curios to find how do you manage NAT logs? Considering the fact that we will need to use overload for pools I don't see any good solution how to track ip address leases. Any ideas? From shopik at inblock.ru Thu May 8 15:29:08 2014 From: shopik at inblock.ru (Nikolay Shopik) Date: Thu, 08 May 2014 19:29:08 +0400 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: Message-ID: <536BA2C4.9040900@inblock.ru> I know most people have problems with 2 bgp feeds and 4GB RAM on ASR1002-F (as it max installable memory). So I doubt about 2M routes with 2GB RAM. On 08.05.2014 18:45, Irwin, Kevin wrote: > on an ASR-1K with 2GB of RAM you can then have > up to 2 million IPv4 routes From mwalter at 3z.net Thu May 8 15:38:45 2014 From: mwalter at 3z.net (Mike Walter) Date: Thu, 8 May 2014 15:38:45 +0000 Subject: NAT (PAT) log In-Reply-To: References: Message-ID: In the past, when we had a Cisco 7200 doing NATing, we had a script someone wrote that would telnet into the router and do a " sh ip nat trans". The file would be saved out and we could parse through it at a later time, we had the script run even 10 minutes or so I believe. If that is what you are looking for, I can try and dig up the script we had for this. -Mike -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Pavel Dimow Sent: Thursday, May 08, 2014 11:20 AM To: NANOG Subject: NAT (PAT) log Hello, as we are running out of ipv4 addresses we started to think of dual stack deployment in our network and that means we will soon need to have some NAT in place (NAT44).However I am curios to find how do you manage NAT logs? Considering the fact that we will need to use overload for pools I don't see any good solution how to track ip address leases. Any ideas? From nrollo at kw-corp.com Thu May 8 16:19:50 2014 From: nrollo at kw-corp.com (Nolan Rollo) Date: Thu, 8 May 2014 16:19:50 +0000 Subject: Residential CPE suggestions In-Reply-To: References: <20140506123107.4466177D@m0005297.ppops.net> Message-ID: <2a700f3fd03343be80c1bd4db30b3965@KWMAIL.local.kw-corp.com> We’ve had two of the ER3s in production. One of which has had no problems to date, the other one had several issues just staying online. It would randomly drop out from time to time (no ICMP, didn't pass traffic; basically a flashing brick). These were both single homed stub networks on older firmware so your results may vary. In my past experience the Ubiquiti release cycle is: Announce Product --> (1 year later) --> Reannounce Product /Start Shipping --> (4 months later) --> Claim it's still on the boat and will reach distributors soon --> (2 months later) --> Begin shipping from Distribution with defunct firmware --> (8 months later and a few firmware updates) --> Release a stable firmware version TL;DR: Ubiquiti has good, inexpensive equipment but it might not always be ready for production networks or very patient customers. For what you’re looking for though no one else can match that price point. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jimmy Hess Sent: Tuesday, May 6, 2014 9:13 PM To: surfer at mauigateway.com Cc: NANOG list Subject: Re: Residential CPE suggestions On Tue, May 6, 2014 at 2:31 PM, Scott Weeks wrote: I wouldn't worry. A fancy GUI without intelligent engineering and design leveraged is just more rope for everyone to hang themselves with, esp. when something in the GUI inevitably doesn't work quite like it's supposed to. Network vendor GUIs never work 100% like they are supposed to; there's always eventually some bug or another, or limitation requiring some workaround. And IPv6 is a game-changer. > It looks like everyone here should start looking for a new > career: "Next-generation user experience allows anyone to quickly > become a routing expert." > ;-) > scott -- -JH From jared at puck.nether.net Thu May 8 16:26:14 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 8 May 2014 12:26:14 -0400 Subject: Residential CPE suggestions In-Reply-To: <2a700f3fd03343be80c1bd4db30b3965@KWMAIL.local.kw-corp.com> References: <20140506123107.4466177D@m0005297.ppops.net> <2a700f3fd03343be80c1bd4db30b3965@KWMAIL.local.kw-corp.com> Message-ID: On May 8, 2014, at 12:19 PM, Nolan Rollo wrote: > TL;DR: Ubiquiti has good, inexpensive equipment but it might not always be ready for production networks or very patient customers. For what you’re looking for though no one else can match that price point. +1 If you have hardware in-hand and don't mind support via their 'free' forums. If you can reproduce any issues, they will promptly recreate it and fix it. You may end up waiting awhile for the software, but even $big_vendor has that issue. I'm using both the nanobridge/nanobeam hardware as well as edgerouter and unifi and they work quite well. - Jared From rcarpen at network1.net Thu May 8 16:30:01 2014 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 8 May 2014 12:30:01 -0400 (EDT) Subject: Residential CPE suggestions In-Reply-To: <2a700f3fd03343be80c1bd4db30b3965@KWMAIL.local.kw-corp.com> References: <20140506123107.4466177D@m0005297.ppops.net> <2a700f3fd03343be80c1bd4db30b3965@KWMAIL.local.kw-corp.com> Message-ID: <1286183966.176319.1399566601791.JavaMail.zimbra@network1.net> I would love to see the EdgeRouter Lite, or something similar with 2 SFP ports and 2 1000bT ports (Which would fit with the OP's question). Q-in-Q tunneling and basic routing required, but not much else for me. Bonus points points for something like that with redundant power supplies for <$1k There really does not seem to be anything in that space that is viable and inexpensive. thanks, -Randy ----- Original Message ----- > We’ve had two of the ER3s in production. One of which has had no problems to > date, the other one had several issues just staying online. It would > randomly drop out from time to time (no ICMP, didn't pass traffic; basically > a flashing brick). These were both single homed stub networks on older > firmware so your results may vary. In my past experience the Ubiquiti > release cycle is: > > Announce Product --> (1 year later) --> Reannounce Product /Start Shipping > --> (4 months later) --> Claim it's still on the boat and will reach > distributors soon --> (2 months later) --> Begin shipping from Distribution > with defunct firmware --> (8 months later and a few firmware updates) --> > Release a stable firmware version > > TL;DR: Ubiquiti has good, inexpensive equipment but it might not always be > ready for production networks or very patient customers. For what you’re > looking for though no one else can match that price point. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jimmy Hess > Sent: Tuesday, May 6, 2014 9:13 PM > To: surfer at mauigateway.com > Cc: NANOG list > Subject: Re: Residential CPE suggestions > > On Tue, May 6, 2014 at 2:31 PM, Scott Weeks wrote: > > I wouldn't worry. A fancy GUI without intelligent engineering and design > leveraged is just more rope for everyone to hang themselves with, esp. > when something in the GUI inevitably doesn't work quite like it's supposed > to. > > Network vendor GUIs never work 100% like they are supposed to; there's always > eventually some bug or another, or limitation requiring some workaround. > > And IPv6 is a game-changer. > > > It looks like everyone here should start looking for a new > > career: "Next-generation user experience allows anyone to quickly > > become a routing expert." > > > ;-) > > scott > -- > -JH > From morrowc.lists at gmail.com Thu May 8 16:34:14 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 8 May 2014 12:34:14 -0400 Subject: bgp convergence problem In-Reply-To: <201405081651.41649.mark.tinka@seacom.mu> References: <53685E02.7060309@gmail.com> <201405080751.13601.mark.tinka@seacom.mu> <201405081651.41649.mark.tinka@seacom.mu> Message-ID: On Thu, May 8, 2014 at 10:51 AM, Mark Tinka wrote: > On Thursday, May 08, 2014 04:41:21 PM Christopher Morrow > wrote: > >> if only there were some technology that could be used to >> thwart such things. > > It's gotten to a point where a repeat offender has me wound > up enough to prepend his AS into some of my paths. > > I wish there was a simpler way to "turn them off". :( that's bad news... config hackery is brittle. (but fun) From wbailey at satelliteintelligencegroup.com Thu May 8 16:39:01 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 8 May 2014 16:39:01 +0000 Subject: Residential CPE suggestions In-Reply-To: References: <20140506123107.4466177D@m0005297.ppops.net> <2a700f3fd03343be80c1bd4db30b3965@KWMAIL.local.kw-corp.com>, Message-ID: I still get email updates on the thread I created in mid 2013. In my experience their forum is a good excuse for not EVER answering the phone. And when I say ever.. I mean.. They don't even take sales calls. (the issue is still there.. By the way.) Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Jared Mauch Date: 05/08/2014 9:28 AM (GMT-08:00) To: Nolan Rollo Cc: NANOG list Subject: Re: Residential CPE suggestions On May 8, 2014, at 12:19 PM, Nolan Rollo wrote: > TL;DR: Ubiquiti has good, inexpensive equipment but it might not always be ready for production networks or very patient customers. For what you’re looking for though no one else can match that price point. +1 If you have hardware in-hand and don't mind support via their 'free' forums. If you can reproduce any issues, they will promptly recreate it and fix it. You may end up waiting awhile for the software, but even $big_vendor has that issue. I'm using both the nanobridge/nanobeam hardware as well as edgerouter and unifi and they work quite well. - Jared From shawnl at up.net Thu May 8 16:46:55 2014 From: shawnl at up.net (Shawn L) Date: Thu, 8 May 2014 12:46:55 -0400 Subject: Experience with Third-Party memory (Cisco)? Message-ID: With all the talk lately about the growth in routes, I got to thinking about upgrading the memory in a couple of my routers. Does anyone have experience using third-party "guaranteed compatible" memory. With Cisco's discount it looks like I can upgrade for $5k vs $700 with third party memory. I'm just wondering if others have used it, and how it's performed, or if it isn't worth the risk. thanks From Jeff.Hodges at KingsMountain.com Thu May 8 17:10:19 2014 From: Jeff.Hodges at KingsMountain.com (=JeffH) Date: Thu, 08 May 2014 10:10:19 -0700 Subject: Observations of an Internet Middleman (Level3) Message-ID: <536BBA7B.6030109@KingsMountain.com> > http://blog.level3.com/global-connectivity/observations-internet-middleman/ See also... Level 3 accuses five unnamed US ISPs of abusing their market power in peering http://gigaom.com/2014/05/05/level-3-accuses-five-unnamed-us-isps-of-abusing-their-market-power-in-peering/ "... I’d love to see Cogent, Google and other providers release their data next, so even if the FCC doesn’t want to pursue this, a growing cry of consumer outrage could push the agency to do something about a very real and difficult problem that’s crippling access to video content on 5 U.S. broadband networks. Level 3 didn’t name names, but based on the deals Netflix has signed and the complaints it has made about AT&T, I’m confident that AT&T, Verizon and Comcast are among the five. " From Jeff.Hodges at KingsMountain.com Thu May 8 17:18:26 2014 From: Jeff.Hodges at KingsMountain.com (=JeffH) Date: Thu, 08 May 2014 10:18:26 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... Message-ID: <536BBC62.4070805@KingsMountain.com> Observations of an Internet Middleman (Level3) http://blog.level3.com/global-connectivity/observations-internet-middleman/ See also... Level 3 accuses five unnamed US ISPs of abusing their market power in peering http://gigaom.com/2014/05/05/level-3-accuses-five-unnamed-us-isps-of-abusing-their-market-power-in-peering/ "... I’d love to see Cogent, Google and other providers release their data next, so even if the FCC doesn’t want to pursue this, a growing cry of consumer outrage could push the agency to do something about a very real and difficult problem that’s crippling access to video content on 5 U.S. broadband networks. Level 3 didn’t name names, but based on the deals Netflix has signed and the complaints it has made about AT&T, I’m confident that AT&T, Verizon and Comcast are among the five. " =JeffH From Jeff.Hodges at KingsMountain.com Thu May 8 17:22:08 2014 From: Jeff.Hodges at KingsMountain.com (=JeffH) Date: Thu, 08 May 2014 10:22:08 -0700 Subject: preemptive apology.. Message-ID: <536BBD40.4070409@KingsMountain.com> ..for inadvertent double-post. mea culpa. From fenner at gmail.com Thu May 8 18:41:01 2014 From: fenner at gmail.com (Bill Fenner) Date: Thu, 8 May 2014 14:41:01 -0400 Subject: US patent 5473599 In-Reply-To: <20140508074954.GK26826@quigon.bsws.de> References: <5AFC5024-1BAB-4A55-AD31-CBB1C333301A@virtualized.org> <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <536A9B46.1030400@earthlink.net> <6E38BC9A-9C95-46A1-8302-E6FB2AD4553E@virtualized.org> <20140507231953.GJ29444@hezmatt.org> <20140508074954.GK26826@quigon.bsws.de> Message-ID: On Thu, May 8, 2014 at 3:49 AM, Henning Brauer wrote: > * Owen DeLong [2014-05-08 04:36]: > > I don’t believe for one second that the IESG refused to deal with ‘em. > > you're free to believe whatever you want and ignore facts. > > > I do believe the IESG did not hand them everything they wanted on a > > silver platter in contravention of the established consensus process > > and that they failed to gain the consensus they wanted as easily as > > they hoped. > > lie. > I was the IESG member responsible for the VRRP working group when the OpenBSD developer (I'm sorry, Henning, I forget if it was you or someone else) came to a VRRP WG meeting and demanded that the IETF handle the patent issue with VRRP. We described the IETF's IPR process and that the policy is explicitly not to do what was being requested, and the response was more or less "well, then we'll have to fix the problem for you". At later meetings I heard buzz about how the developers intended CARP to interfere with VRRP, with the philosophical position that VRRP wasn't a protocol. When I first saw the claims that IANA told OpenBSD that you had to have deep pockets to get a protocol number, I asked the IANA to share the original request and any related correspondence with the IESG. They could not find any such correspondence in the raw archive of the iana at iana.orgmailbox. While the OpenBSD project has done an incredible amount of good on the Internet, the version of events described by the 3.5 release song does not match my personal experiences. Bill From hb-nanog at bsws.de Thu May 8 18:54:02 2014 From: hb-nanog at bsws.de (Henning Brauer) Date: Thu, 8 May 2014 20:54:02 +0200 Subject: US patent 5473599 In-Reply-To: References: <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <536A9B46.1030400@earthlink.net> <6E38BC9A-9C95-46A1-8302-E6FB2AD4553E@virtualized.org> <20140507231953.GJ29444@hezmatt.org> <20140508074954.GK26826@quigon.bsws.de> Message-ID: <20140508185402.GE15042@quigon.bsws.de> * Bill Fenner [2014-05-08 20:41]: > I was the IESG member responsible for the VRRP working group when the > OpenBSD developer (I'm sorry, Henning, I forget if it was you or someone > else) wasn't me, as stated repeatedly I wasn't the one talking to the standard bodies. > came to a VRRP WG meeting and demanded that the IETF handle the > patent issue with VRRP. We described the IETF's IPR process and that the > policy is explicitly not to do what was being requested, and the response > was more or less "well, then we'll have to fix the problem for you". At > later meetings I heard buzz about how the developers intended CARP to > interfere with VRRP, with the philosophical position that VRRP wasn't a > protocol. I think we have told what happened in enough detail in the 3.5 commentary already posted to this thread. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting From mark.tinka at seacom.mu Thu May 8 19:11:15 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 8 May 2014 21:11:15 +0200 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: <536BA2C4.9040900@inblock.ru> References: <536BA2C4.9040900@inblock.ru> Message-ID: <201405082111.19011.mark.tinka@seacom.mu> On Thursday, May 08, 2014 05:29:08 PM Nikolay Shopik wrote: > I know most people have problems with 2 bgp feeds and 4GB > RAM on ASR1002-F (as it max installable memory). So I > doubt about 2M routes with 2GB RAM. I've never ran the ASR1002-F, but I know some other ASR1000 platforms consume half the memory just for the IOS image upon boot. This makes running a second instance of IOSd on boxes that have a single RP a sure way to lead to a crash when the same box is running BGP (happened to me once, 2nd IOSd never again). 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 Thu May 8 19:13:19 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 8 May 2014 21:13:19 +0200 Subject: bgp convergence problem In-Reply-To: References: <53685E02.7060309@gmail.com> <201405081651.41649.mark.tinka@seacom.mu> Message-ID: <201405082113.19393.mark.tinka@seacom.mu> On Thursday, May 08, 2014 06:34:14 PM Christopher Morrow wrote: > :( that's bad news... config hackery is brittle. > (but fun) Don't I know :-)... *sigh* 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 nicotine at warningg.com Thu May 8 23:30:29 2014 From: nicotine at warningg.com (Brandon Ewing) Date: Thu, 8 May 2014 18:30:29 -0500 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: Message-ID: <20140508233029.GF31516@radiological.warningg.com> On Tue, May 06, 2014 at 03:39:13PM +0000, Drew Weaver wrote: > > I am wondering if maybe we should make some kind of concerted effort to remind folks about the IPv4 routing table inching closer and closer to the 512K route mark. > Closer to? Internap announces 507K prefixes to me today. Coupled with the prefixes I carry in iBGP internally, I've been sitting at 511K for quite some time, and at occasions, exceeded 512K in the last 2 weeks. L3 Forwarding Resources FIB TCAM usage: Total Used %Used 72 bits (IPv4, MPLS, EoM) 802816 511848 64% IP routing table maximum-paths is 32 Route Source Networks Subnets Overhead Memory (bytes) connected 0 31 3012 4464 static 1 78 17456 11376 ospf 1 1 310 22392 44784 Intra-area: 110 Inter-area: 160 External-1: 0 External-2: 41 NSSA External-1: 0 NSSA External-2: 0 bgp 23456 167707 343507 36808128 75466680 External: 507479 Internal: 3735 Local: 0 internal 6054 13246152 Total 173763 343926 36850988 88773456 -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tom at ninjabadger.net Thu May 8 23:45:51 2014 From: tom at ninjabadger.net (Tom Hill) Date: Fri, 09 May 2014 00:45:51 +0100 Subject: Experience with Third-Party memory (Cisco)? In-Reply-To: References: Message-ID: <536C172F.5070705@ninjabadger.net> On 08/05/14 17:46, Shawn L wrote: > Does anyone have experience using third-party "guaranteed compatible" > memory. > > With Cisco's discount it looks like I can upgrade for $5k vs $700 with > third party memory. I'm just wondering if others have used it, and how it's > performed, or if it isn't worth the risk. As far as I'm aware, there are up to four ISR 3825s still operating somewhere I've worked previously, with Crucial DIMMs in them. The stuff that came out looked pretty bog-standard OEM stuff, too. I suppose it could depend on what type of memory it is, but when it's just regular DDR SDRAM, I don't see any cause for concern for the few tens of pounds it cost (versus £hundreds for Cisco's own) to find out. Tom From mdikkema at gmail.com Thu May 8 14:55:22 2014 From: mdikkema at gmail.com (Michael Dikkema) Date: Thu, 8 May 2014 09:55:22 -0500 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: <1D80627D-AF5C-4E2D-B93D-1EEF624BAC0E@inblock.ru> References: <536969E5.6080608@cox.net> <1D80627D-AF5C-4E2D-B93D-1EEF624BAC0E@inblock.ru> Message-ID: I could never get an definitive answer out of TAC or my account team, but I believe the ASR1002 w/ESP5 is also affected. On Thu, May 8, 2014 at 1:15 AM, Nikolay Shopik wrote: > Asr1002-f may have problem as it limited to 512k iirc > > > On 08 мая 2014 г., at 2:45, Shawn L wrote: > > > > Do the ASR1k routers have this issue as well? I searched around but > > couldn't find any information. > > > > > > > > ---------- Forwarded message ---------- > > From: Irwin, Kevin > > Date: Wed, May 7, 2014 at 10:39 AM > > Subject: Re: Getting pretty close to default IPv4 route maximum for > > 6500/7600 routers. > > To: "nanog at nanog.org" > > > > > > I¹m really surprised that most people have not hit this limit already, > > especially on the 9K¹s, as it seems Cisco has some fuzzy math when it > > comes to the 512K limit. > > > > Also make sure you have spare cards when you reload after changing the > > scaling, those old cards don¹t always like to come back. > > > >> On 5/6/14, 7:01 PM, "Larry Sheldon" wrote: > >> > >>> On 5/6/2014 10:39 AM, Drew Weaver wrote: > >>> > >>> Just something to think about before it becomes a story the community > >>> talks about for the next decade. > >> > >> Like we have for the last two? > >> > >> > >> -- > >> Requiescas in pace o email Two identifying characteristics > >> of System Administrators: > >> Ex turpi causa non oritur actio Infallibility, and the ability to > >> learn from their mistakes. > >> (Adapted from Stephen Pinker) > > > > The information transmitted is intended only for the person or entity to > > which it is addressed and may contain confidential and/or privileged > > material. Any review, retransmission, dissemination or other use of, or > > taking of any action in reliance upon, this information by persons or > > entities other than the intended recipient is prohibited. If you receive > > this in error, please contact the sender and destroy any copies of this > > document. > From boutilpj at ednet.ns.ca Thu May 8 16:51:34 2014 From: boutilpj at ednet.ns.ca (Patrick Boutilier) Date: Thu, 08 May 2014 13:51:34 -0300 Subject: Experience with Third-Party memory (Cisco)? In-Reply-To: References: Message-ID: <536BB616.7050709@ednet.ns.ca> On 05/08/2014 01:46 PM, Shawn L wrote: > With all the talk lately about the growth in routes, I got to thinking > about upgrading the memory in a couple of my routers. > > Does anyone have experience using third-party "guaranteed compatible" > memory. > > With Cisco's discount it looks like I can upgrade for $5k vs $700 with > third party memory. I'm just wondering if others have used it, and how it's > performed, or if it isn't worth the risk. > > thanks > No direct experience with Cisco but we used to use Kingston memory in Dell servers without any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: boutilpj.vcf Type: text/x-vcard Size: 298 bytes Desc: not available URL: From Gary.Dunaway at teamhgs.com Thu May 8 17:02:07 2014 From: Gary.Dunaway at teamhgs.com (Gary Dunaway) Date: Thu, 8 May 2014 17:02:07 +0000 Subject: Experience with Third-Party memory (Cisco)? In-Reply-To: References: Message-ID: <1B2337429310304A8483E6ECE293371E02C68F@PHMNEXCHMBS-02.HTMT.SOFT.NET> A few years back, we had to do memory upgrades on our ASAs in order to move to 8.3 code. All was done with 3rd party memory kits. There have been no performance issues we've noticed with them. The one issue we had was that one of the memory sticks in the kit was bad. The vendor immediately sent out a replacement for it and all was well after that. -Gary -----Original Message----- From: NANOG [mailto:nanog-bounces+gary.dunaway=teamhgs.com at nanog.org] On Behalf Of Shawn L Sent: Thursday, May 08, 2014 11:47 AM To: nanog Subject: Experience with Third-Party memory (Cisco)? With all the talk lately about the growth in routes, I got to thinking about upgrading the memory in a couple of my routers. Does anyone have experience using third-party "guaranteed compatible" memory. With Cisco's discount it looks like I can upgrade for $5k vs $700 with third party memory. I'm just wondering if others have used it, and how it's performed, or if it isn't worth the risk. thanks _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ Please make note of our new e-mail domain name: TEAMHGS.COM. Request you to update your address book accordingly. Confidentiality Notice: The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Hinduja Global Solutions or postmaster at teamhgs.com immediately and destroy all copies of this message and any attachments. 9284f6a0-bf16-11e3-b1b6-0800200c9a66 From chiel at gmx.net Thu May 8 19:37:05 2014 From: chiel at gmx.net (chiel) Date: Thu, 08 May 2014 21:37:05 +0200 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: Message-ID: <536BDCE1.6010407@gmx.net> On 05/06/2014 05:39 PM, Drew Weaver wrote: > I am wondering if maybe we should make some kind of concerted effort to remind folks about the IPv4 routing table inching closer and closer to the 512K route mark. Thanks for this e-mail with clear subject ;) Did anyone yet calculated roughly when the ipv4 routing table will hit 512K ? From savage at savage.za.org Fri May 9 05:06:29 2014 From: savage at savage.za.org (Chris Knipe) Date: Fri, 9 May 2014 07:06:29 +0200 Subject: Experience with Third-Party memory (Cisco)? In-Reply-To: <1B2337429310304A8483E6ECE293371E02C68F@PHMNEXCHMBS-02.HTMT.SOFT.NET> References: <1B2337429310304A8483E6ECE293371E02C68F@PHMNEXCHMBS-02.HTMT.SOFT.NET> Message-ID: Running 6500's and 7200's with 3rd party memory... No issues. On Thu, May 8, 2014 at 7:02 PM, Gary Dunaway wrote: > A few years back, we had to do memory upgrades on our ASAs in order to move to 8.3 code. All was done with 3rd party memory kits. There have been no performance issues we've noticed with them. The one issue we had was that one of the memory sticks in the kit was bad. The vendor immediately sent out a replacement for it and all was well after that. > > -Gary > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+gary.dunaway=teamhgs.com at nanog.org] On Behalf Of Shawn L > Sent: Thursday, May 08, 2014 11:47 AM > To: nanog > Subject: Experience with Third-Party memory (Cisco)? > > With all the talk lately about the growth in routes, I got to thinking about upgrading the memory in a couple of my routers. > > Does anyone have experience using third-party "guaranteed compatible" > memory. > > With Cisco's discount it looks like I can upgrade for $5k vs $700 with third party memory. I'm just wondering if others have used it, and how it's performed, or if it isn't worth the risk. > > thanks > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ > > Please make note of our new e-mail domain name: TEAMHGS.COM. > Request you to update your address book accordingly. > > Confidentiality Notice: > The information contained in this electronic message and any attachments to this message are > intended for the exclusive use of the addressee(s) and may contain confidential or privileged > information. If you are not the intended recipient, please notify the sender at > Hinduja Global Solutions or postmaster at teamhgs.com immediately and destroy all copies of > this message and any attachments. > > 9284f6a0-bf16-11e3-b1b6-0800200c9a66 -- Regards, Chris Knipe From geraint at koding.com Fri May 9 05:08:42 2014 From: geraint at koding.com (Geraint Jones) Date: Fri, 09 May 2014 17:08:42 +1200 Subject: Experience with Third-Party memory (Cisco)? In-Reply-To: References: Message-ID: This is what your looking for : http://www.ebay.com/itm/IBM-PC2700U-512MB-DDR-CL2-5-333Mhz-ECC-Memory-38L52 31-/331191705115?pt=US_Memory_RAM_&hash=item4d1c905e1b 512MB DDR CL2.5 Unbuffered/Unregistered CL2.5 - buy 10 and have a huge stack of spares :) -- Geraint Jones Director of Systems & Infrastructure Koding (AS62805) https://koding.com geraint at koding.com Phone (415) 653-0083 On 9/05/14 4:46 am, "Shawn L" wrote: >With all the talk lately about the growth in routes, I got to thinking >about upgrading the memory in a couple of my routers. > >Does anyone have experience using third-party "guaranteed compatible" >memory. > >With Cisco's discount it looks like I can upgrade for $5k vs $700 with >third party memory. I'm just wondering if others have used it, and how >it's >performed, or if it isn't worth the risk. > >thanks From randy at psg.com Fri May 9 05:12:38 2014 From: randy at psg.com (Randy Bush) Date: Fri, 09 May 2014 07:12:38 +0200 Subject: US patent 5473599 In-Reply-To: <20140508185402.GE15042@quigon.bsws.de> References: <6B7FA690-F25D-462D-9521-50AC5323ECD4@virtualized.org> <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net> <536A9B46.1030400@earthlink.net> <6E38BC9A-9C95-46A1-8302-E6FB2AD4553E@virtualized.org> <20140507231953.GJ29444@hezmatt.org> <20140508074954.GK26826@quigon.bsws.de> <20140508185402.GE15042@quigon.bsws.de> Message-ID: > I think we have told what happened in enough detail in the 3.5 ^your version of > commentary already posted to this thread. randy, yet another of the hordes of vrrp users From wbailey at satelliteintelligencegroup.com Fri May 9 05:16:27 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 9 May 2014 05:16:27 +0000 Subject: Experience with Third-Party memory (Cisco)? In-Reply-To: References: Message-ID: I used some old laptop simms from ebay in my 2801.. Worked like a charm :) On 5/8/14, 10:08 PM, "Geraint Jones" wrote: >This is what your looking for : > >http://www.ebay.com/itm/IBM-PC2700U-512MB-DDR-CL2-5-333Mhz-ECC-Memory-38L5 >2 >31-/331191705115?pt=US_Memory_RAM_&hash=item4d1c905e1b > > >512MB DDR CL2.5 Unbuffered/Unregistered CL2.5 - buy 10 and have a huge >stack of spares :) > > >-- >Geraint Jones > >Director of Systems & Infrastructure >Koding (AS62805) >https://koding.com >geraint at koding.com >Phone (415) 653-0083 > > > > > >On 9/05/14 4:46 am, "Shawn L" wrote: > >>With all the talk lately about the growth in routes, I got to thinking >>about upgrading the memory in a couple of my routers. >> >>Does anyone have experience using third-party "guaranteed compatible" >>memory. >> >>With Cisco's discount it looks like I can upgrade for $5k vs $700 with >>third party memory. I'm just wondering if others have used it, and how >>it's >>performed, or if it isn't worth the risk. >> >>thanks > > From adam.vitkovsky at swan.sk Fri May 9 07:48:55 2014 From: adam.vitkovsky at swan.sk (=?iso-8859-1?Q?Vitkovsk=FD_Adam?=) Date: Fri, 9 May 2014 07:48:55 +0000 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: <536969E5.6080608@cox.net> Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B011EA88B@EX01.swan.local> > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Irwin, Kevin > Sent: Wednesday, May 07, 2014 4:39 PM > I¹m really surprised that most people have not hit this limit already, especially > on the 9K¹s, as it seems Cisco has some fuzzy math when it comes to the > 512K limit. I would actually be very surprised if someone would hit the 512K limit on ASRs. With 6500/7600 I can understand they've been around for ages and no one anticipated the 512k limit back then. But ASRs? When these where bough engineers must have known that 512k is not going to be enough. I guess one does some reading and tweaking before installing a box as a PE or Internet Edge. adam From rdobbins at arbor.net Fri May 9 08:14:20 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 9 May 2014 08:14:20 +0000 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B011EA88B@EX01.swan.local> References: <536969E5.6080608@cox.net> <61DC6BC4ABA10E4489D4A73EBABAC18B011EA88B@EX01.swan.local> Message-ID: On May 9, 2014, at 2:48 PM, Vitkovský Adam wrote: > With 6500/7600 I can understand they've been around for ages and no one anticipated the 512k limit back then. Actually, it *was* anticipated. It's just that those who designed the ASIC didn't necessarily envision that it would still be in service, having gone through successive additional minor variations, for quite so long. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From aledm at qix.co.uk Fri May 9 11:05:53 2014 From: aledm at qix.co.uk (Aled Morris) Date: Fri, 9 May 2014 12:05:53 +0100 Subject: Residential CPE suggestions In-Reply-To: <1286183966.176319.1399566601791.JavaMail.zimbra@network1.net> References: <20140506123107.4466177D@m0005297.ppops.net> <2a700f3fd03343be80c1bd4db30b3965@KWMAIL.local.kw-corp.com> <1286183966.176319.1399566601791.JavaMail.zimbra@network1.net> Message-ID: On 8 May 2014 17:30, Randy Carpenter wrote: > > I would love to see the EdgeRouter Lite, or something similar with 2 SFP > ports and 2 1000bT ports (Which would fit with the OP's question). Q-in-Q > tunneling and basic routing required, but not much else for me. Bonus > points points for something like that with redundant power supplies for <$1k > Indeed. Mikrotik are promising a CCR1009 with 2xSFP and 8xUTP GE ports (and dual PSU) for $425 but it isn't an access switch (so no Q-in-Q) though it does support MPLS/VPLS. Aled From Jason_Livingood at cable.comcast.com Fri May 9 12:27:58 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Fri, 9 May 2014 12:27:58 +0000 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: <536BBC62.4070805@KingsMountain.com> References: <536BBC62.4070805@KingsMountain.com> Message-ID: Hi Jeff – I noticed the question posed here so thought I’d respond, perhaps at risk of stirring up a hornet’s nest given how long the last thread was. ;-) Anyway… there’s no congestion between Comcast and Level 3 connections, and we’re working collaboratively with Level 3. Given these facts, we have no reason to believe that Comcast is on their list. - Jason Comcast On 5/8/14, 1:18 PM, "=JeffH" > wrote: Level 3 accuses five unnamed US ISPs of abusing their market power in peering http://gigaom.com/2014/05/05/level-3-accuses-five-unnamed-us-isps-of-abusing-their-market-power-in-peering/ "...I’d love to see Cogent, Google and other providers release their data next, so even if the FCC doesn’t want to pursue this, a growing cry of consumer outrage could push the agency to do something about a very real and difficult problem that’s crippling access to video content on 5 U.S. broadband networks. Level 3 didn’t name names, but based on the deals Netflix has signed and the complaints it has made about AT&T, I’m confident that AT&T, Verizon and Comcast are among the five. " From aledm at qix.co.uk Fri May 9 13:15:24 2014 From: aledm at qix.co.uk (Aled Morris) Date: Fri, 9 May 2014 14:15:24 +0100 Subject: Residential CPE suggestions In-Reply-To: References: <20140506123107.4466177D@m0005297.ppops.net> <2a700f3fd03343be80c1bd4db30b3965@KWMAIL.local.kw-corp.com> <1286183966.176319.1399566601791.JavaMail.zimbra@network1.net> Message-ID: On 9 May 2014 12:05, Aled Morris wrote: > Indeed. Mikrotik are promising a CCR1009 with 2xSFP and 8xUTP GE ports > (and dual PSU) for $425 but it isn't an access switch (so no Q-in-Q) though > it does support MPLS/VPLS. > Apologies for correcting myself, but I just checked and Q-in-Q is supported in Mikrotik RouterOS, so this might be the ideal box for you (if it were orderable.) I forgot to include the link too - http://routerboard.com/CCR1009-8G-1S Aled From cscora at apnic.net Fri May 9 18:11:16 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 10 May 2014 04:11:16 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201405091811.s49IBGbF010707@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 10 May, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 493796 Prefixes after maximum aggregation: 193891 Deaggregation factor: 2.55 Unique aggregates announced to Internet: 244717 Total ASes present in the Internet Routing Table: 46783 Prefixes per ASN: 10.56 Origin-only ASes present in the Internet Routing Table: 35788 Origin ASes announcing only one prefix: 16362 Transit ASes present in the Internet Routing Table: 6078 Transit-only ASes present in the Internet Routing Table: 173 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: 1828 Unregistered ASNs in the Routing Table: 460 Number of 32-bit ASNs allocated by the RIRs: 6563 Number of 32-bit ASNs visible in the Routing Table: 4917 Prefixes from 32-bit ASNs in the Routing Table: 16421 Number of bogon 32-bit ASNs visible in the Routing Table: 100 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 398 Number of addresses announced to Internet: 2682427140 Equivalent to 159 /8s, 226 /16s and 151 /24s Percentage of available address space announced: 72.5 Percentage of allocated address space announced: 72.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.3 Total number of prefixes smaller than registry allocations: 171140 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 117515 Total APNIC prefixes after maximum aggregation: 34991 APNIC Deaggregation factor: 3.36 Prefixes being announced from the APNIC address blocks: 120427 Unique aggregates announced from the APNIC address blocks: 50342 APNIC Region origin ASes present in the Internet Routing Table: 4927 APNIC Prefixes per ASN: 24.44 APNIC Region origin ASes announcing only one prefix: 1227 APNIC Region transit ASes present in the Internet Routing Table: 868 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 30 Number of APNIC region 32-bit ASNs visible in the Routing Table: 940 Number of APNIC addresses announced to Internet: 732451712 Equivalent to 43 /8s, 168 /16s and 83 /24s Percentage of available APNIC address space announced: 85.6 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: 167973 Total ARIN prefixes after maximum aggregation: 83567 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 169469 Unique aggregates announced from the ARIN address blocks: 79909 ARIN Region origin ASes present in the Internet Routing Table: 16255 ARIN Prefixes per ASN: 10.43 ARIN Region origin ASes announcing only one prefix: 6117 ARIN Region transit ASes present in the Internet Routing Table: 1665 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 99 Number of ARIN addresses announced to Internet: 1075858560 Equivalent to 64 /8s, 32 /16s and 76 /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: 123505 Total RIPE prefixes after maximum aggregation: 62580 RIPE Deaggregation factor: 1.97 Prefixes being announced from the RIPE address blocks: 128045 Unique aggregates announced from the RIPE address blocks: 80903 RIPE Region origin ASes present in the Internet Routing Table: 17675 RIPE Prefixes per ASN: 7.24 RIPE Region origin ASes announcing only one prefix: 8268 RIPE Region transit ASes present in the Internet Routing Table: 2874 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: 2693 Number of RIPE addresses announced to Internet: 657616260 Equivalent to 39 /8s, 50 /16s and 109 /24s Percentage of available RIPE address space announced: 95.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 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: 56356 Total LACNIC prefixes after maximum aggregation: 10059 LACNIC Deaggregation factor: 5.60 Prefixes being announced from the LACNIC address blocks: 62858 Unique aggregates announced from the LACNIC address blocks: 28900 LACNIC Region origin ASes present in the Internet Routing Table: 2095 LACNIC Prefixes per ASN: 30.00 LACNIC Region origin ASes announcing only one prefix: 547 LACNIC Region transit ASes present in the Internet Routing Table: 437 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 34 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1155 Number of LACNIC addresses announced to Internet: 160668288 Equivalent to 9 /8s, 147 /16s and 154 /24s Percentage of available LACNIC address space announced: 95.8 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: 11917 Total AfriNIC prefixes after maximum aggregation: 2656 AfriNIC Deaggregation factor: 4.49 Prefixes being announced from the AfriNIC address blocks: 12599 Unique aggregates announced from the AfriNIC address blocks: 4335 AfriNIC Region origin ASes present in the Internet Routing Table: 715 AfriNIC Prefixes per ASN: 17.62 AfriNIC Region origin ASes announcing only one prefix: 203 AfriNIC Region transit ASes present in the Internet Routing Table: 153 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 30 Number of AfriNIC addresses announced to Internet: 55520512 Equivalent to 3 /8s, 79 /16s and 45 /24s Percentage of available AfriNIC address space announced: 55.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 2947 11591 922 Korea Telecom 17974 2801 901 75 PT Telekomunikasi Indonesia 7545 2224 320 117 TPG Telecom Limited 4755 1855 396 199 TATA Communications formerly 9829 1629 1291 32 National Internet Backbone 9583 1328 103 545 Sify Limited 9498 1258 314 84 BHARTI Airtel Ltd. 7552 1225 1082 13 Viettel Corporation 4808 1208 2151 355 CNCGROUP IP network China169 24560 1130 388 175 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 2966 3688 53 BellSouth.net Inc. 22773 2425 2937 134 Cox Communications Inc. 1785 2204 700 135 PaeTec Communications, Inc. 18566 2047 379 178 MegaPath Corporation 20115 1705 1688 564 Charter Communications 4323 1628 1073 409 tw telecom holdings, inc. 701 1479 11159 750 MCI Communications Services, 30036 1406 305 549 Mediacom Communications Corp 6983 1328 800 307 ITC^Deltacom 22561 1306 402 232 CenturyTel Internet Holdings, 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 34984 1708 264 270 TELLCOM ILETISIM HIZMETLERI A 8402 1506 544 16 OJSC "Vimpelcom" 20940 1320 506 988 Akamai International B.V. 13188 1049 100 28 TOV "Bank-Inform" 31148 1018 45 19 Freenet Ltd. 8551 918 370 40 Bezeq International-Ltd 6849 822 357 27 JSC "Ukrtelecom" 6830 766 2333 427 Liberty Global Operations B.V 12479 721 797 56 France Telecom Espana SA 9198 564 344 25 JSC Kazakhtelecom 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 3777 1989 101 NET Servi�os de Comunica��o S 10620 2854 462 191 Telmex Colombia S.A. 18881 1970 972 21 Global Village Telecom 7303 1755 1174 230 Telecom Argentina S.A. 8151 1402 2931 406 Uninet S.A. de C.V. 6503 1108 434 60 Axtel, S.A.B. de C.V. 7738 913 1754 40 Telemar Norte Leste S.A. 27947 872 114 50 Telconet S.A 26615 842 2325 35 Tim Celular S.A. 11830 815 364 15 Instituto Costarricense de El 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 1114 240 6 Sudanese Mobile Telephone (ZA 24863 963 280 26 Link Egypt (Link.NET) 6713 614 722 28 Office National des Postes et 8452 573 958 13 TE-AS 24835 304 144 9 Vodafone Data 36992 301 783 24 ETISALAT MISR 3741 247 921 208 Internet Solutions 37054 229 19 6 Data Telecom Service 29571 228 22 16 Cote d'Ivoire Telecom 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 3777 1989 101 NET Servi�os de Comunica��o S 6389 2966 3688 53 BellSouth.net Inc. 4766 2947 11591 922 Korea Telecom 10620 2854 462 191 Telmex Colombia S.A. 17974 2801 901 75 PT Telekomunikasi Indonesia 22773 2425 2937 134 Cox Communications Inc. 7545 2224 320 117 TPG Telecom Limited 1785 2204 700 135 PaeTec Communications, Inc. 18566 2047 379 178 MegaPath Corporation 18881 1970 972 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 2966 2913 BellSouth.net Inc. 17974 2801 2726 PT Telekomunikasi Indonesia 10620 2854 2663 Telmex Colombia S.A. 22773 2425 2291 Cox Communications Inc. 7545 2224 2107 TPG Telecom Limited 1785 2204 2069 PaeTec Communications, Inc. 4766 2947 2025 Korea Telecom 18881 1970 1949 Global Village Telecom 18566 2047 1869 MegaPath Corporation 4755 1855 1656 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 5.109.32.0/19 23456 32bit Transition AS 65456 PRIVATE 5.109.96.0/19 23456 32bit Transition AS 30662 UNALLOCATED 8.2.129.0/24 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 22511 UNALLOCATED 8.28.225.0/24 2828 XO Communications 22511 UNALLOCATED 8.36.68.0/24 2828 XO Communications Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.14.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 41.73.16.0/24 37004 >>UNKNOWN<< 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:12 /10:30 /11:90 /12:258 /13:483 /14:966 /15:1703 /16:12943 /17:6841 /18:11674 /19:24314 /20:34252 /21:36653 /22:52933 /23:46217 /24:262262 /25:771 /26:927 /27:397 /28:13 /29:20 /30:8 /31:1 /32:12 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2002 2047 MegaPath Corporation 6389 1694 2966 BellSouth.net Inc. 22773 1671 2425 Cox Communications Inc. 30036 1244 1406 Mediacom Communications Corp 8402 1200 1506 OJSC "Vimpelcom" 11492 1173 1213 CABLE ONE, INC. 1785 1166 2204 PaeTec Communications, Inc. 36998 1080 1114 Sudanese Mobile Telephone (ZA 6983 1043 1328 ITC^Deltacom 34984 1038 1708 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1029 2:662 3:3 4:15 5:983 6:19 8:742 12:1842 13:4 14:991 15:13 16:2 17:31 18:21 20:36 23:790 24:1734 25:1 27:1759 31:1478 32:40 33:2 34:5 36:131 37:1881 38:957 39:7 40:198 41:3187 42:250 44:12 46:2180 47:19 49:702 50:916 52:12 54:47 55:7 57:28 58:1235 59:602 60:405 61:1544 62:1236 63:1963 64:4366 65:2294 66:4158 67:2072 68:1031 69:3310 70:857 71:447 72:2010 74:2654 75:315 76:419 77:1532 78:892 79:707 80:1295 81:1163 82:743 83:757 84:721 85:1263 86:470 87:1169 88:483 89:1797 90:140 91:5688 92:693 93:1713 94:2036 95:1477 96:511 97:349 98:1076 99:48 100:54 101:796 103:4787 105:536 106:173 107:600 108:577 109:2055 110:959 111:1292 112:659 113:842 114:901 115:1121 116:1061 117:933 118:1398 119:1339 120:382 121:809 122:2032 123:1323 124:1408 125:1401 128:627 129:318 130:346 131:659 132:398 133:162 134:322 135:74 136:252 137:291 138:349 139:171 140:210 141:371 142:574 143:445 144:506 145:103 146:605 147:458 148:909 149:346 150:169 151:786 152:425 153:218 154:277 155:484 156:336 157:336 158:240 159:899 160:329 161:538 162:1412 163:220 164:691 165:599 166:280 167:614 168:1031 169:123 170:1399 171:191 172:21 173:1626 174:701 175:596 176:1460 177:2878 178:1983 179:617 180:1723 181:1135 182:1559 183:513 184:706 185:1600 186:2762 187:1553 188:1914 189:1458 190:7542 191:284 192:7265 193:5499 194:4051 195:3496 196:1406 197:645 198:5036 199:5575 200:6245 201:2610 202:9006 203:8883 204:4637 205:2702 206:2932 207:2953 208:3990 209:3726 210:3098 211:1684 212:2298 213:2078 214:901 215:86 216:5521 217:1678 218:578 219:321 220:1283 221:604 222:354 223:582 End of report From cidr-report at potaroo.net Fri May 9 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 May 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201405092200.s49M00Bt045330@wattle.apnic.net> This report has been generated at Fri May 9 21:13:53 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 02-05-14 500388 283099 03-05-14 500674 281707 04-05-14 499055 282390 05-05-14 500188 281852 06-05-14 499505 282156 07-05-14 499946 281901 08-05-14 499340 282123 09-05-14 499630 282356 AS Summary 47026 Number of ASes in routing system 19165 Number of ASes announcing only one prefix 3777 Largest number of prefixes announced by an AS AS28573: NET Servi�os de Comunica��o S.A.,BR 120042496 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 09May14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 499702 282290 217412 43.5% All ASes AS28573 3777 297 3480 92.1% NET Servi�os de Comunica��o S.A.,BR AS6389 2965 58 2907 98.0% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2802 251 2551 91.0% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS4766 2947 931 2016 68.4% KIXS-AS-KR Korea Telecom,KR AS18881 1970 37 1933 98.1% Global Village Telecom,BR AS1785 2204 494 1710 77.6% AS-PAETEC-NET - PaeTec Communications, Inc.,US AS10620 2854 1358 1496 52.4% Telmex Colombia S.A.,CO AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation,US AS7303 1760 459 1301 73.9% Telecom Argentina S.A.,AR AS4755 1855 585 1270 68.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4323 1639 421 1218 74.3% TWTC - tw telecom holdings, inc.,US AS7545 2238 1076 1162 51.9% TPG-INTERNET-AP TPG Telecom Limited,AU AS7552 1252 146 1106 88.3% VIETEL-AS-AP Viettel Corporation,VN AS22561 1306 241 1065 81.5% AS22561 - CenturyTel Internet Holdings, Inc.,US AS6983 1326 306 1020 76.9% ITCDELTA - Earthlink, Inc.,US AS36998 1114 160 954 85.6% SDN-MOBITEL,SD AS4788 1045 148 897 85.8% TMNET-AS-AP TM Net, Internet Service Provider,MY AS9829 1629 735 894 54.9% BSNL-NIB National Internet Backbone,IN AS22773 2420 1556 864 35.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS24560 1130 295 835 73.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS4808 1212 394 818 67.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS18101 946 187 759 80.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS8151 1414 672 742 52.5% Uninet S.A. de C.V.,MX AS701 1481 751 730 49.3% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US AS7738 913 183 730 80.0% Telemar Norte Leste S.A.,BR AS26615 842 113 729 86.6% Tim Celular S.A.,BR AS855 750 57 693 92.4% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA AS9808 1002 327 675 67.4% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS6147 784 113 671 85.6% Telefonica del Peru S.A.A.,PE AS4780 1039 374 665 64.0% SEEDNET Digital United Inc.,TW Total 50663 13290 37373 73.8% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.236.0/24 AS37290 -Reserved AS-,ZZ 41.78.237.0/24 AS37290 -Reserved AS-,ZZ 41.78.238.0/24 AS37290 -Reserved AS-,ZZ 41.78.239.0/24 AS37290 -Reserved AS-,ZZ 41.190.72.0/24 AS37451 CongoTelecom,CG 41.190.73.0/24 AS37451 CongoTelecom,CG 41.190.74.0/24 AS37451 CongoTelecom,CG 41.190.75.0/24 AS37451 CongoTelecom,CG 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos,US 63.247.0.0/24 AS27609 -Reserved AS-,ZZ 63.247.1.0/24 AS27609 -Reserved AS-,ZZ 63.247.2.0/24 AS27609 -Reserved AS-,ZZ 63.247.3.0/24 AS27609 -Reserved AS-,ZZ 63.247.4.0/24 AS27609 -Reserved AS-,ZZ 63.247.5.0/24 AS27609 -Reserved AS-,ZZ 63.247.6.0/24 AS27609 -Reserved AS-,ZZ 63.247.7.0/24 AS27609 -Reserved AS-,ZZ 63.247.8.0/24 AS27609 -Reserved AS-,ZZ 63.247.9.0/24 AS27609 -Reserved AS-,ZZ 63.247.10.0/24 AS27609 -Reserved AS-,ZZ 63.247.11.0/24 AS27609 -Reserved AS-,ZZ 63.247.13.0/24 AS27609 -Reserved AS-,ZZ 63.247.14.0/24 AS27609 -Reserved AS-,ZZ 63.247.15.0/24 AS27609 -Reserved AS-,ZZ 63.247.16.0/24 AS27609 -Reserved AS-,ZZ 63.247.17.0/24 AS27609 -Reserved AS-,ZZ 63.247.18.0/24 AS27609 -Reserved AS-,ZZ 63.247.19.0/24 AS27609 -Reserved AS-,ZZ 63.247.20.0/24 AS27609 -Reserved AS-,ZZ 63.247.21.0/24 AS27609 -Reserved AS-,ZZ 63.247.22.0/24 AS27609 -Reserved AS-,ZZ 63.247.23.0/24 AS27609 -Reserved AS-,ZZ 63.247.24.0/24 AS27609 -Reserved AS-,ZZ 63.247.25.0/24 AS27609 -Reserved AS-,ZZ 63.247.26.0/24 AS27609 -Reserved AS-,ZZ 63.247.27.0/24 AS27609 -Reserved AS-,ZZ 63.247.28.0/24 AS27609 -Reserved AS-,ZZ 63.247.29.0/24 AS27609 -Reserved AS-,ZZ 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.111.160.0/20 AS40551 -Reserved AS-,ZZ 64.111.160.0/24 AS40551 -Reserved AS-,ZZ 64.111.161.0/24 AS40551 -Reserved AS-,ZZ 64.111.162.0/24 AS40551 -Reserved AS-,ZZ 64.111.167.0/24 AS40551 -Reserved AS-,ZZ 64.111.169.0/24 AS40551 -Reserved AS-,ZZ 64.111.170.0/24 AS40551 -Reserved AS-,ZZ 64.111.171.0/24 AS40551 -Reserved AS-,ZZ 64.111.172.0/24 AS40551 -Reserved AS-,ZZ 64.111.173.0/24 AS40551 -Reserved AS-,ZZ 64.111.174.0/24 AS40551 -Reserved AS-,ZZ 64.111.175.0/24 AS40551 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.254.188.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.115.124.0/23 AS46540 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD,RU 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT 91.229.182.0/24 AS56960 -Reserved AS-,ZZ 91.229.186.0/24 AS56967 -Reserved AS-,ZZ 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 95.215.140.0/22 AS48949 -Reserved AS-,ZZ 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP 103.23.48.0/24 AS56194 103.23.49.0/24 AS56194 103.23.50.0/24 AS56194 103.23.51.0/24 AS56194 103.31.236.0/22 AS17941 BIT-ISLE Bit-isle Co.,Ltd.,JP 103.244.236.0/22 AS58794 103.247.52.0/23 AS4725 ODN SOFTBANK TELECOM Corp.,JP 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 176.125.224.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 185.57.4.0/22 AS21250 TYFON Tyfon Svenska AB - Sweden,SE 185.57.8.0/22 AS19790 HOSTNET Hostnet B.V.,NL 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A.,EC 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc.,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.241.20.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.241.21.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.84.187.0/24 AS16276 OVH OVH SAS,FR 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.112.0/23 AS12964 DBMG-DE Dr. Buelow & Masiak GmbH,DE 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.243.166.0/24 AS44093 -Reserved AS-,ZZ 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.69.203.0/24 AS5089 NTL Virgin Media Limited,GB 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 194.213.8.0/24 AS42845 BRETAGNETELECOM BRETAGNE TELECOM SAS,FR 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.39.252.0/23 AS29004 -Reserved AS-,ZZ 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.90.98.0/23 AS57511 OVALTECH-AS OvalTech Internet Ltd,GB 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL,RO 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.2.224.0/22 AS24863 LINKdotNET-AS,EG 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.13.201.0/24 AS2018 TENET-1,ZA 196.13.202.0/24 AS2018 TENET-1,ZA 196.13.203.0/24 AS2018 TENET-1,ZA 196.13.204.0/24 AS2018 TENET-1,ZA 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.45.0.0/21 AS26625 -Reserved AS-,ZZ 196.45.10.0/24 AS26625 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.72.78.0/23 AS3967 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.30.138.0/24 AS23319 -Reserved AS-,ZZ 199.30.139.0/24 AS23319 -Reserved AS-,ZZ 199.30.143.0/24 AS8100 IPTELLIGENT - IPTelligent LLC,US 199.68.72.0/24 AS174 COGENT-174 - Cogent Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.9.40.0/24 AS56194 202.9.41.0/24 AS56194 202.9.42.0/24 AS56194 202.9.43.0/24 AS56194 202.9.44.0/24 AS56194 202.9.45.0/24 AS56194 202.9.46.0/24 AS56194 202.9.47.0/24 AS56194 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.10.94.0/23 AS30097 NUWAVE - NuWave,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp.,CA 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 212.119.32.0/19 AS12550 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US 216.24.176.0/20 AS19401 -Reserved AS-,ZZ 216.24.188.0/24 AS19401 -Reserved AS-,ZZ 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.203.80.0/20 AS27021 -Reserved AS-,ZZ 216.203.80.0/21 AS27021 -Reserved AS-,ZZ 216.203.87.0/24 AS27021 -Reserved AS-,ZZ 216.203.88.0/21 AS27021 -Reserved AS-,ZZ 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 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 May 9 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 May 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201405092200.s49M0106045346@wattle.apnic.net> BGP Update Report Interval: 01-May-14 -to- 08-May-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 79697 4.2% 87.4 -- BSNL-NIB National Internet Backbone,IN 2 - AS23752 49567 2.6% 454.7 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - AS58115 37173 2.0% 1956.5 -- DATALABS-AS DATALABS Ltd,RU 4 - AS8402 27267 1.4% 45.1 -- CORBINA-AS OJSC "Vimpelcom",RU 5 - AS4775 24537 1.3% 322.9 -- GLOBE-TELECOM-AS Globe Telecoms,PH 6 - AS4323 24357 1.3% 18.4 -- TWTC - tw telecom holdings, inc.,US 7 - AS41691 21541 1.1% 2154.1 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 8 - AS28573 17942 0.9% 16.2 -- NET Servi�os de Comunica��o S.A.,BR 9 - AS17557 17589 0.9% 586.3 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 10 - AS5800 16487 0.9% 109.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center,US 11 - AS14259 15034 0.8% 1503.4 -- Gtd Internet S.A.,CL 12 - AS25184 13721 0.7% 108.0 -- AFRANET AFRANET Co. Tehran, Iran,IR 13 - AS3816 12665 0.7% 23.9 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 14 - AS45899 12498 0.7% 46.8 -- VNPT-AS-VN VNPT Corp,VN 15 - AS4755 11950 0.6% 8.3 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 16 - AS18747 11417 0.6% 37.2 -- -Reserved AS-,ZZ 17 - AS3475 11371 0.6% 114.9 -- DNIC-AS-03475 - Navy Network Information Center (NNIC),US 18 - AS35567 11045 0.6% 298.5 -- DASTO-BOSNIA-AS DASTO semtel d.o.o.,BA 19 - AS48159 10221 0.5% 46.0 -- TIC-AS Telecommunication Infrastructure Company,IR 20 - AS7552 9711 0.5% 8.3 -- VIETEL-AS-AP Viettel Corporation,VN TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6459 7950 0.4% 7950.0 -- TRANSBEAM - I-2000, Inc.,US 2 - AS4 7740 0.4% 824.0 -- ISI-AS - University of Southern California,US 3 - AS45590 2771 0.1% 2771.0 -- HGCINTNET-AS-AP Hutch Connect,HK 4 - AS41691 21541 1.1% 2154.1 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 5 - AS54465 6230 0.3% 2076.7 -- QPM-AS-1 - QuickPlay Media Inc.,US 6 - AS58115 37173 2.0% 1956.5 -- DATALABS-AS DATALABS Ltd,RU 7 - AS14259 15034 0.8% 1503.4 -- Gtd Internet S.A.,CL 8 - AS3 1485 0.1% 1987.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 9 - AS24960 4413 0.2% 1471.0 -- GATCHINA-AS Severo-Zapad Ltd.,RU 10 - AS57992 1459 0.1% 1459.0 -- TRANSPROMSTROY-AS TransPromStroy Ltd,RU 11 - AS21840 3824 0.2% 1274.7 -- SAGONET-TPA - Sago Networks,US 12 - AS18135 8248 0.4% 1178.3 -- BTV BTV Cable television,JP 13 - AS60345 1160 0.1% 1160.0 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 14 - AS57201 1099 0.1% 1099.0 -- EDF-AS Estonian Defence Forces,EE 15 - AS33643 1035 0.1% 1035.0 -- JELLYBELLY - Jelly Belly Candy Company,US 16 - AS6629 9452 0.5% 945.2 -- NOAA-AS - NOAA,US 17 - AS59137 1505 0.1% 752.5 -- IDNIC-KEMHAN-AS-ID PUSDATIN KEMHAN RI,ID 18 - AS48068 741 0.0% 741.0 -- VISONIC Visonic Ltd,IL 19 - AS25488 712 0.0% 712.0 -- COMUNE-NOVARA-AS Comune di novara,IT 20 - AS4 1355 0.1% 630.0 -- ISI-AS - University of Southern California,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 89.221.206.0/24 21474 1.0% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 2 - 121.52.144.0/24 17831 0.9% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK AS45773 -- HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan,PK 3 - 87.250.97.0/24 10814 0.5% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o.,BA 4 - 192.58.232.0/24 9416 0.5% AS6629 -- NOAA-AS - NOAA,US 5 - 78.109.192.0/20 8476 0.4% AS25184 -- AFRANET AFRANET Co. Tehran, Iran,IR 6 - 42.83.48.0/20 8236 0.4% AS18135 -- BTV BTV Cable television,JP 7 - 205.247.12.0/24 7950 0.4% AS6459 -- TRANSBEAM - I-2000, Inc.,US 8 - 120.28.62.0/24 7927 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 9 - 186.237.56.0/22 7740 0.4% AS4 -- ISI-AS - University of Southern California,US 10 - 222.127.0.0/24 7177 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 11 - 115.170.128.0/17 7171 0.3% AS4847 -- CNIX-AP China Networks Inter-Exchange,CN 12 - 185.24.67.0/24 6521 0.3% AS12041 -- AS-AFILIAS1 - Afilias Canada, Corp.,CA 13 - 206.152.15.0/24 6228 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.,US 15 - 205.94.160.0/19 3098 0.1% AS3475 -- DNIC-AS-03475 - Navy Network Information Center (NNIC),US 16 - 202.70.88.0/21 2825 0.1% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 17 - 112.137.16.0/20 2771 0.1% AS45590 -- HGCINTNET-AS-AP Hutch Connect,HK 18 - 203.1.78.0/24 2740 0.1% AS4802 -- ASN-IINET iiNet Limited,AU 19 - 84.205.66.0/24 2586 0.1% AS12654 -- RIPE-NCC-RIS-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC),EU 20 - 163.121.103.0/24 2492 0.1% AS6127 -- IDSC,EG 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 patrick at ianai.net Fri May 9 22:11:53 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 9 May 2014 18:11:53 -0400 Subject: The Cidr Report In-Reply-To: <201405092200.s49M00Bt045330@wattle.apnic.net> References: <201405092200.s49M00Bt045330@wattle.apnic.net> Message-ID: <956DD505-E883-4468-B486-925B2954748F@ianai.net> w00 h00! We did it!! Is this excellent or what? We dipped below half a million again! I am impressed. Keep up the good work, everyone. Party in Bellevue if we can keep it below 500K until then! -- TTFN, patrick > On May 9, 2014, at 18:00, cidr-report at potaroo.net wrote: > > This report has been generated at Fri May 9 21:13:53 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 > 02-05-14 500388 283099 > 03-05-14 500674 281707 > 04-05-14 499055 282390 > 05-05-14 500188 281852 > 06-05-14 499505 282156 > 07-05-14 499946 281901 > 08-05-14 499340 282123 > 09-05-14 499630 282356 > > > AS Summary > 47026 Number of ASes in routing system > 19165 Number of ASes announcing only one prefix > 3777 Largest number of prefixes announced by an AS > AS28573: NET Serviços de Comunicação S.A.,BR > 120042496 Largest address span announced by an AS (/32s) > AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN > > > 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'). > > --- 09May14 --- > ASnum NetsNow NetsAggr NetGain % Gain Description > > Table 499702 282290 217412 43.5% All ASes > > AS28573 3777 297 3480 92.1% NET Serviços de Comunicação > S.A.,BR > AS6389 2965 58 2907 98.0% BELLSOUTH-NET-BLK - > BellSouth.net Inc.,US > AS17974 2802 251 2551 91.0% TELKOMNET-AS2-AP PT > Telekomunikasi Indonesia,ID > AS4766 2947 931 2016 68.4% KIXS-AS-KR Korea Telecom,KR > AS18881 1970 37 1933 98.1% Global Village Telecom,BR > AS1785 2204 494 1710 77.6% AS-PAETEC-NET - PaeTec > Communications, Inc.,US > AS10620 2854 1358 1496 52.4% Telmex Colombia S.A.,CO > AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath > Corporation,US > AS7303 1760 459 1301 73.9% Telecom Argentina S.A.,AR > AS4755 1855 585 1270 68.5% TATACOMM-AS TATA > Communications formerly VSNL > is Leading ISP,IN > AS4323 1639 421 1218 74.3% TWTC - tw telecom holdings, > inc.,US > AS7545 2238 1076 1162 51.9% TPG-INTERNET-AP TPG Telecom > Limited,AU > AS7552 1252 146 1106 88.3% VIETEL-AS-AP Viettel > Corporation,VN > AS22561 1306 241 1065 81.5% AS22561 - CenturyTel Internet > Holdings, Inc.,US > AS6983 1326 306 1020 76.9% ITCDELTA - Earthlink, Inc.,US > AS36998 1114 160 954 85.6% SDN-MOBITEL,SD > AS4788 1045 148 897 85.8% TMNET-AS-AP TM Net, Internet > Service Provider,MY > AS9829 1629 735 894 54.9% BSNL-NIB National Internet > Backbone,IN > AS22773 2420 1556 864 35.7% ASN-CXA-ALL-CCI-22773-RDC - > Cox Communications Inc.,US > AS24560 1130 295 835 73.9% AIRTELBROADBAND-AS-AP Bharti > Airtel Ltd., Telemedia > Services,IN > AS4808 1212 394 818 67.5% CHINA169-BJ CNCGROUP IP > network China169 Beijing > Province Network,CN > AS18101 946 187 759 80.2% RELIANCE-COMMUNICATIONS-IN > Reliance Communications > Ltd.DAKC MUMBAI,IN > AS8151 1414 672 742 52.5% Uninet S.A. de C.V.,MX > AS701 1481 751 730 49.3% UUNET - MCI Communications > Services, Inc. d/b/a Verizon > Business,US > AS7738 913 183 730 80.0% Telemar Norte Leste S.A.,BR > AS26615 842 113 729 86.6% Tim Celular S.A.,BR > AS855 750 57 693 92.4% CANET-ASN-4 - Bell Aliant > Regional Communications, > Inc.,CA > AS9808 1002 327 675 67.4% CMNET-GD Guangdong Mobile > Communication Co.Ltd.,CN > AS6147 784 113 671 85.6% Telefonica del Peru S.A.A.,PE > AS4780 1039 374 665 64.0% SEEDNET Digital United Inc.,TW > > Total 50663 13290 37373 73.8% Top 30 total > > > Possible Bogus Routes > > 27.100.7.0/24 AS56096 > 41.73.1.0/24 AS37004 -Reserved AS-,ZZ > 41.73.2.0/24 AS37004 -Reserved AS-,ZZ > 41.73.10.0/24 AS37004 -Reserved AS-,ZZ > 41.73.11.0/24 AS37004 -Reserved AS-,ZZ > 41.73.12.0/24 AS37004 -Reserved AS-,ZZ > 41.73.13.0/24 AS37004 -Reserved AS-,ZZ > 41.73.14.0/24 AS37004 -Reserved AS-,ZZ > 41.73.15.0/24 AS37004 -Reserved AS-,ZZ > 41.73.16.0/24 AS37004 -Reserved AS-,ZZ > 41.73.18.0/24 AS37004 -Reserved AS-,ZZ > 41.73.20.0/24 AS37004 -Reserved AS-,ZZ > 41.73.21.0/24 AS37004 -Reserved AS-,ZZ > 41.76.48.0/21 AS36969 MTL-AS,MW > 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US > 41.78.236.0/24 AS37290 -Reserved AS-,ZZ > 41.78.237.0/24 AS37290 -Reserved AS-,ZZ > 41.78.238.0/24 AS37290 -Reserved AS-,ZZ > 41.78.239.0/24 AS37290 -Reserved AS-,ZZ > 41.190.72.0/24 AS37451 CongoTelecom,CG > 41.190.73.0/24 AS37451 CongoTelecom,CG > 41.190.74.0/24 AS37451 CongoTelecom,CG > 41.190.75.0/24 AS37451 CongoTelecom,CG > 41.191.108.0/22 AS37004 -Reserved AS-,ZZ > 41.191.108.0/24 AS37004 -Reserved AS-,ZZ > 41.191.109.0/24 AS37004 -Reserved AS-,ZZ > 41.191.110.0/24 AS37004 -Reserved AS-,ZZ > 41.191.111.0/24 AS37004 -Reserved AS-,ZZ > 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL > 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL > 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos,US > 63.247.0.0/24 AS27609 -Reserved AS-,ZZ > 63.247.1.0/24 AS27609 -Reserved AS-,ZZ > 63.247.2.0/24 AS27609 -Reserved AS-,ZZ > 63.247.3.0/24 AS27609 -Reserved AS-,ZZ > 63.247.4.0/24 AS27609 -Reserved AS-,ZZ > 63.247.5.0/24 AS27609 -Reserved AS-,ZZ > 63.247.6.0/24 AS27609 -Reserved AS-,ZZ > 63.247.7.0/24 AS27609 -Reserved AS-,ZZ > 63.247.8.0/24 AS27609 -Reserved AS-,ZZ > 63.247.9.0/24 AS27609 -Reserved AS-,ZZ > 63.247.10.0/24 AS27609 -Reserved AS-,ZZ > 63.247.11.0/24 AS27609 -Reserved AS-,ZZ > 63.247.13.0/24 AS27609 -Reserved AS-,ZZ > 63.247.14.0/24 AS27609 -Reserved AS-,ZZ > 63.247.15.0/24 AS27609 -Reserved AS-,ZZ > 63.247.16.0/24 AS27609 -Reserved AS-,ZZ > 63.247.17.0/24 AS27609 -Reserved AS-,ZZ > 63.247.18.0/24 AS27609 -Reserved AS-,ZZ > 63.247.19.0/24 AS27609 -Reserved AS-,ZZ > 63.247.20.0/24 AS27609 -Reserved AS-,ZZ > 63.247.21.0/24 AS27609 -Reserved AS-,ZZ > 63.247.22.0/24 AS27609 -Reserved AS-,ZZ > 63.247.23.0/24 AS27609 -Reserved AS-,ZZ > 63.247.24.0/24 AS27609 -Reserved AS-,ZZ > 63.247.25.0/24 AS27609 -Reserved AS-,ZZ > 63.247.26.0/24 AS27609 -Reserved AS-,ZZ > 63.247.27.0/24 AS27609 -Reserved AS-,ZZ > 63.247.28.0/24 AS27609 -Reserved AS-,ZZ > 63.247.29.0/24 AS27609 -Reserved AS-,ZZ > 64.25.16.0/23 AS19535 -Reserved AS-,ZZ > 64.25.20.0/24 AS19535 -Reserved AS-,ZZ > 64.25.21.0/24 AS19535 -Reserved AS-,ZZ > 64.25.22.0/24 AS19535 -Reserved AS-,ZZ > 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US > 64.111.160.0/20 AS40551 -Reserved AS-,ZZ > 64.111.160.0/24 AS40551 -Reserved AS-,ZZ > 64.111.161.0/24 AS40551 -Reserved AS-,ZZ > 64.111.162.0/24 AS40551 -Reserved AS-,ZZ > 64.111.167.0/24 AS40551 -Reserved AS-,ZZ > 64.111.169.0/24 AS40551 -Reserved AS-,ZZ > 64.111.170.0/24 AS40551 -Reserved AS-,ZZ > 64.111.171.0/24 AS40551 -Reserved AS-,ZZ > 64.111.172.0/24 AS40551 -Reserved AS-,ZZ > 64.111.173.0/24 AS40551 -Reserved AS-,ZZ > 64.111.174.0/24 AS40551 -Reserved AS-,ZZ > 64.111.175.0/24 AS40551 -Reserved AS-,ZZ > 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US > 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US > 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US > 66.55.96.0/23 AS17203 -Reserved AS-,ZZ > 66.55.98.0/24 AS17203 -Reserved AS-,ZZ > 66.55.99.0/24 AS17203 -Reserved AS-,ZZ > 66.55.100.0/22 AS17203 -Reserved AS-,ZZ > 66.55.102.0/23 AS17203 -Reserved AS-,ZZ > 66.55.104.0/21 AS17203 -Reserved AS-,ZZ > 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA > 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US > 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US > 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.254.188.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT > 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US > 74.112.100.0/22 AS16764 -Reserved AS-,ZZ > 74.113.200.0/23 AS46939 -Reserved AS-,ZZ > 74.114.52.0/22 AS40818 -Reserved AS-,ZZ > 74.114.52.0/23 AS40818 -Reserved AS-,ZZ > 74.114.52.0/24 AS40818 -Reserved AS-,ZZ > 74.114.53.0/24 AS40818 -Reserved AS-,ZZ > 74.114.54.0/23 AS40818 -Reserved AS-,ZZ > 74.114.54.0/24 AS40818 -Reserved AS-,ZZ > 74.114.55.0/24 AS40818 -Reserved AS-,ZZ > 74.115.124.0/23 AS46540 -Reserved AS-,ZZ > 74.118.132.0/22 AS5117 -Reserved AS-,ZZ > 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US > 77.243.80.0/24 AS42597 -Reserved AS-,ZZ > 77.243.81.0/24 AS42597 -Reserved AS-,ZZ > 77.243.88.0/24 AS42597 -Reserved AS-,ZZ > 77.243.91.0/24 AS42597 -Reserved AS-,ZZ > 77.243.94.0/24 AS42597 -Reserved AS-,ZZ > 77.243.95.0/24 AS42597 -Reserved AS-,ZZ > 80.250.32.0/22 AS37106 ODUA-AS,NG > 85.202.160.0/20 AS44404 -Reserved AS-,ZZ > 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 91.197.36.0/22 AS43359 -Reserved AS-,ZZ > 91.199.90.0/24 AS44330 -Reserved AS-,ZZ > 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD,RU > 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE > 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT > 91.229.182.0/24 AS56960 -Reserved AS-,ZZ > 91.229.186.0/24 AS56967 -Reserved AS-,ZZ > 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB > 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > 93.190.10.0/24 AS47254 -Reserved AS-,ZZ > 95.215.140.0/22 AS48949 -Reserved AS-,ZZ > 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU > 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN > 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN > 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP > 103.23.48.0/24 AS56194 > 103.23.49.0/24 AS56194 > 103.23.50.0/24 AS56194 > 103.23.51.0/24 AS56194 > 103.31.236.0/22 AS17941 BIT-ISLE Bit-isle Co.,Ltd.,JP > 103.244.236.0/22 AS58794 > 103.247.52.0/23 AS4725 ODN SOFTBANK TELECOM Corp.,JP > 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU > 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK > 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US > 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US > 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US > 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN > 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN > 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP > 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US > 172.85.0.0/24 AS29571 CITelecom-AS,CI > 172.85.1.0/24 AS29571 CITelecom-AS,CI > 172.85.2.0/24 AS29571 CITelecom-AS,CI > 172.85.3.0/24 AS29571 CITelecom-AS,CI > 172.86.0.0/24 AS29571 CITelecom-AS,CI > 172.86.1.0/24 AS29571 CITelecom-AS,CI > 172.86.2.0/24 AS29571 CITelecom-AS,CI > 172.87.0.0/24 AS29571 CITelecom-AS,CI > 172.88.0.0/24 AS29571 CITelecom-AS,CI > 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN > 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US > 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO > 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ > 176.125.224.0/19 AS39906 COPROSYS CoProSys a.s.,CZ > 185.57.4.0/22 AS21250 TYFON Tyfon Svenska AB - Sweden,SE > 185.57.8.0/22 AS19790 HOSTNET Hostnet B.V.,NL > 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO > 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A.,EC > 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR > 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US > 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US > 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US > 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US > 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US > 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US > 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA > 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US > 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 192.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc.,US > 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE > 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US > 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US > 192.154.32.0/19 AS81 NCREN - MCNC,US > 192.154.64.0/19 AS81 NCREN - MCNC,US > 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 192.241.20.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US > 192.241.21.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US > 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US > 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US > 193.9.59.0/24 AS1257 TELE2,SE > 193.16.106.0/24 AS31539 -Reserved AS-,ZZ > 193.16.145.0/24 AS31392 -Reserved AS-,ZZ > 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI > 193.22.224.0/20 AS3322 -Reserved AS-,ZZ > 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE > 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB > 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE > 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB > 193.84.187.0/24 AS16276 OVH OVH SAS,FR > 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB > 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO > 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES > 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO > 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO > 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE > 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US > 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT > 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO > 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.201.112.0/23 AS12964 DBMG-DE Dr. Buelow & Masiak GmbH,DE > 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB > 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB > 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT > 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.243.166.0/24 AS44093 -Reserved AS-,ZZ > 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA > 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA > 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE > 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE > 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE > 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB > 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE > 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB > 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 194.69.203.0/24 AS5089 NTL Virgin Media Limited,GB > 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE > 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO > 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE > 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 194.126.219.0/24 AS34545 -Reserved AS-,ZZ > 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR > 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE > 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE > 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE > 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA > 194.213.8.0/24 AS42845 BRETAGNETELECOM BRETAGNE TELECOM SAS,FR > 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO > 195.39.252.0/23 AS29004 -Reserved AS-,ZZ > 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE > 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO > 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.90.98.0/23 AS57511 OVALTECH-AS OvalTech Internet Ltd,GB > 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL,RO > 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE > 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE > 195.234.156.0/24 AS25028 -Reserved AS-,ZZ > 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 196.2.224.0/22 AS24863 LINKdotNET-AS,EG > 196.3.182.0/24 AS37004 -Reserved AS-,ZZ > 196.3.183.0/24 AS37004 -Reserved AS-,ZZ > 196.13.201.0/24 AS2018 TENET-1,ZA > 196.13.202.0/24 AS2018 TENET-1,ZA > 196.13.203.0/24 AS2018 TENET-1,ZA > 196.13.204.0/24 AS2018 TENET-1,ZA > 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR > 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US > 196.45.0.0/21 AS26625 -Reserved AS-,ZZ > 196.45.10.0/24 AS26625 -Reserved AS-,ZZ > 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US > 198.72.78.0/23 AS3967 -Reserved AS-,ZZ > 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US > 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US > 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US > 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US > 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US > 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA > 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA > 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA > 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA > 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US > 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US > 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US > 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US > 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK > 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 199.30.138.0/24 AS23319 -Reserved AS-,ZZ > 199.30.139.0/24 AS23319 -Reserved AS-,ZZ > 199.30.143.0/24 AS8100 IPTELLIGENT - IPTelligent LLC,US > 199.68.72.0/24 AS174 COGENT-174 - Cogent Communications,US > 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA > 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US > 199.116.200.0/21 AS22830 -Reserved AS-,ZZ > 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US > 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US > 200.58.248.0/21 AS27849 > 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR > 202.9.40.0/24 AS56194 > 202.9.41.0/24 AS56194 > 202.9.42.0/24 AS56194 > 202.9.43.0/24 AS56194 > 202.9.44.0/24 AS56194 > 202.9.45.0/24 AS56194 > 202.9.46.0/24 AS56194 > 202.9.47.0/24 AS56194 > 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK > 202.58.113.0/24 AS19161 -Reserved AS-,ZZ > 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN > 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG > 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN > 203.142.219.0/24 AS45149 > 203.189.116.0/22 AS45606 > 203.189.116.0/24 AS45606 > 203.189.117.0/24 AS45606 > 203.189.118.0/24 AS45606 > 203.189.119.0/24 AS45606 > 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 204.10.94.0/23 AS30097 NUWAVE - NuWave,US > 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US > 204.16.96.0/24 AS19972 -Reserved AS-,ZZ > 204.16.97.0/24 AS19972 -Reserved AS-,ZZ > 204.16.98.0/24 AS19972 -Reserved AS-,ZZ > 204.16.99.0/24 AS19972 -Reserved AS-,ZZ > 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US > 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US > 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB > 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA > 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US > 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp.,CA > 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA > 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US > 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US > 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US > 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US > 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US > 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US > 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US > 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US > 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US > 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US > 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM > 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM > 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM > 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US > 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US > 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US > 208.75.152.0/21 AS32146 -Reserved AS-,ZZ > 208.76.20.0/24 AS31812 -Reserved AS-,ZZ > 208.76.21.0/24 AS31812 -Reserved AS-,ZZ > 208.77.164.0/24 AS22659 -Reserved AS-,ZZ > 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US > 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US > 208.84.232.0/24 AS33131 -Reserved AS-,ZZ > 208.84.234.0/24 AS33131 -Reserved AS-,ZZ > 208.84.237.0/24 AS33131 -Reserved AS-,ZZ > 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US > 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US > 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US > 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US > 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US > 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US > 209.234.112.0/23 AS32252 -Reserved AS-,ZZ > 209.234.114.0/23 AS32252 -Reserved AS-,ZZ > 209.234.116.0/24 AS32252 -Reserved AS-,ZZ > 209.234.117.0/24 AS32252 -Reserved AS-,ZZ > 209.234.118.0/24 AS32252 -Reserved AS-,ZZ > 209.234.119.0/24 AS32252 -Reserved AS-,ZZ > 209.234.120.0/24 AS32252 -Reserved AS-,ZZ > 209.234.121.0/24 AS32252 -Reserved AS-,ZZ > 209.234.122.0/24 AS32252 -Reserved AS-,ZZ > 212.119.32.0/19 AS12550 -Reserved AS-,ZZ > 213.184.64.0/24 AS13071 -Reserved AS-,ZZ > 213.184.65.0/24 AS13071 -Reserved AS-,ZZ > 213.184.66.0/24 AS13071 -Reserved AS-,ZZ > 213.184.67.0/24 AS13071 -Reserved AS-,ZZ > 213.184.68.0/24 AS13071 -Reserved AS-,ZZ > 213.184.69.0/24 AS13071 -Reserved AS-,ZZ > 213.184.70.0/24 AS13071 -Reserved AS-,ZZ > 213.184.71.0/24 AS13071 -Reserved AS-,ZZ > 213.184.72.0/24 AS13071 -Reserved AS-,ZZ > 213.184.73.0/24 AS13071 -Reserved AS-,ZZ > 213.184.74.0/24 AS13071 -Reserved AS-,ZZ > 213.184.75.0/24 AS13071 -Reserved AS-,ZZ > 213.184.76.0/24 AS13071 -Reserved AS-,ZZ > 213.184.77.0/24 AS13071 -Reserved AS-,ZZ > 213.184.78.0/24 AS13071 -Reserved AS-,ZZ > 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US > 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US > 216.24.176.0/20 AS19401 -Reserved AS-,ZZ > 216.24.188.0/24 AS19401 -Reserved AS-,ZZ > 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US > 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US > 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US > 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US > 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US > 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US > 216.203.80.0/20 AS27021 -Reserved AS-,ZZ > 216.203.80.0/21 AS27021 -Reserved AS-,ZZ > 216.203.87.0/24 AS27021 -Reserved AS-,ZZ > 216.203.88.0/21 AS27021 -Reserved AS-,ZZ > 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc.,US > 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US > > > 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 hugo at slabnet.com Fri May 9 19:10:04 2014 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 9 May 2014 12:10:04 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> Message-ID: <20140509191004.GA30776@slab-wks-04.slabnet.com> >Anyway… there’s no congestion between Comcast and Level 3 connections, and >we’re working collaboratively with Level 3. Given these facts, we have no >reason to believe that Comcast is on their list. Sure, because Level 3 is already paying Comcast to deliver traffic to your paying customers, right? -- Hugo >From: NANOG on behalf of Livingood, Jason > >Sent: Friday, May 9, 2014 5:27 AM >To: =JeffH; nanog at nanog.org >Subject: Re: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... > >Hi Jeff – I noticed the question posed here so thought I’d respond, perhaps at risk of stirring up a hornet’s nest given how long the last thread was. ;-) Anyway… there’s no congestion between Comcast and Level 3 connections, and we’re working collaboratively with Level 3. Given these facts, we have no reason to believe that Comcast is on their list. > >- Jason >Comcast > >On 5/8/14, 1:18 PM, "=JeffH" > wrote: > >Level 3 accuses five unnamed US ISPs of abusing their market power in peering >http://gigaom.com/2014/05/05/level-3-accuses-five-unnamed-us-isps-of-abusing-their-market-power-in-peering/ > >"...I’d love to see Cogent, Google and other providers release their data next, so even if the FCC doesn’t want to pursue this, a growing cry of consumer outrage could push the agency to do something about a very real and difficult problem that’s crippling access to video content on 5 U.S. broadband networks. Level 3 didn’t name names, but based on the deals Netflix has signed and the complaints it has made about AT&T, I’m confident that AT&T, Verizon and Comcast are among the five. " > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From owen at delong.com Sat May 10 00:51:56 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 9 May 2014 17:51:56 -0700 Subject: The Cidr Report In-Reply-To: <956DD505-E883-4468-B486-925B2954748F@ianai.net> References: <201405092200.s49M00Bt045330@wattle.apnic.net> <956DD505-E883-4468-B486-925B2954748F@ianai.net> Message-ID: ROFLMAO — Party in Bellevue is more than likely to push it back up over 500K again, isn’t it? Sounds like a Dish commercial… (James Earl Jones voice): When you put a bunch of network engineers in a party in Bellevue, you get a bunch of drunk network engineers. When you get drunk network engineers, you get interesting router configurations. When you get interesting router configurations you get disaggregation of the routing table for TE. When you get disaggregation for TE, the routing table grows. When the routing table grows, you hit half a million routes. When you hit half a million routes, the internet starts to break. Don’t break the internet. Don’t get half a million routes. Don’t let network engineers party in Bellevue. (No, I’m not actually opposed to the party, but I thought you might find the commercial amusing). Owen On May 9, 2014, at 3:11 PM, Patrick W. Gilmore wrote: > w00 h00! We did it!! > > Is this excellent or what? We dipped below half a million again! I am impressed. > > Keep up the good work, everyone. > > Party in Bellevue if we can keep it below 500K until then! > > -- > TTFN, > patrick > > >> On May 9, 2014, at 18:00, cidr-report at potaroo.net wrote: >> >> This report has been generated at Fri May 9 21:13:53 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 >> 02-05-14 500388 283099 >> 03-05-14 500674 281707 >> 04-05-14 499055 282390 >> 05-05-14 500188 281852 >> 06-05-14 499505 282156 >> 07-05-14 499946 281901 >> 08-05-14 499340 282123 >> 09-05-14 499630 282356 >> >> >> AS Summary >> 47026 Number of ASes in routing system >> 19165 Number of ASes announcing only one prefix >> 3777 Largest number of prefixes announced by an AS >> AS28573: NET Serviços de Comunicação S.A.,BR >> 120042496 Largest address span announced by an AS (/32s) >> AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN >> >> >> 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'). >> >> --- 09May14 --- >> ASnum NetsNow NetsAggr NetGain % Gain Description >> >> Table 499702 282290 217412 43.5% All ASes >> >> AS28573 3777 297 3480 92.1% NET Serviços de Comunicação >> S.A.,BR >> AS6389 2965 58 2907 98.0% BELLSOUTH-NET-BLK - >> BellSouth.net Inc.,US >> AS17974 2802 251 2551 91.0% TELKOMNET-AS2-AP PT >> Telekomunikasi Indonesia,ID >> AS4766 2947 931 2016 68.4% KIXS-AS-KR Korea Telecom,KR >> AS18881 1970 37 1933 98.1% Global Village Telecom,BR >> AS1785 2204 494 1710 77.6% AS-PAETEC-NET - PaeTec >> Communications, Inc.,US >> AS10620 2854 1358 1496 52.4% Telmex Colombia S.A.,CO >> AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath >> Corporation,US >> AS7303 1760 459 1301 73.9% Telecom Argentina S.A.,AR >> AS4755 1855 585 1270 68.5% TATACOMM-AS TATA >> Communications formerly VSNL >> is Leading ISP,IN >> AS4323 1639 421 1218 74.3% TWTC - tw telecom holdings, >> inc.,US >> AS7545 2238 1076 1162 51.9% TPG-INTERNET-AP TPG Telecom >> Limited,AU >> AS7552 1252 146 1106 88.3% VIETEL-AS-AP Viettel >> Corporation,VN >> AS22561 1306 241 1065 81.5% AS22561 - CenturyTel Internet >> Holdings, Inc.,US >> AS6983 1326 306 1020 76.9% ITCDELTA - Earthlink, Inc.,US >> AS36998 1114 160 954 85.6% SDN-MOBITEL,SD >> AS4788 1045 148 897 85.8% TMNET-AS-AP TM Net, Internet >> Service Provider,MY >> AS9829 1629 735 894 54.9% BSNL-NIB National Internet >> Backbone,IN >> AS22773 2420 1556 864 35.7% ASN-CXA-ALL-CCI-22773-RDC - >> Cox Communications Inc.,US >> AS24560 1130 295 835 73.9% AIRTELBROADBAND-AS-AP Bharti >> Airtel Ltd., Telemedia >> Services,IN >> AS4808 1212 394 818 67.5% CHINA169-BJ CNCGROUP IP >> network China169 Beijing >> Province Network,CN >> AS18101 946 187 759 80.2% RELIANCE-COMMUNICATIONS-IN >> Reliance Communications >> Ltd.DAKC MUMBAI,IN >> AS8151 1414 672 742 52.5% Uninet S.A. de C.V.,MX >> AS701 1481 751 730 49.3% UUNET - MCI Communications >> Services, Inc. d/b/a Verizon >> Business,US >> AS7738 913 183 730 80.0% Telemar Norte Leste S.A.,BR >> AS26615 842 113 729 86.6% Tim Celular S.A.,BR >> AS855 750 57 693 92.4% CANET-ASN-4 - Bell Aliant >> Regional Communications, >> Inc.,CA >> AS9808 1002 327 675 67.4% CMNET-GD Guangdong Mobile >> Communication Co.Ltd.,CN >> AS6147 784 113 671 85.6% Telefonica del Peru S.A.A.,PE >> AS4780 1039 374 665 64.0% SEEDNET Digital United Inc.,TW >> >> Total 50663 13290 37373 73.8% Top 30 total >> >> >> Possible Bogus Routes >> >> 27.100.7.0/24 AS56096 >> 41.73.1.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.2.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.10.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.11.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.12.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.13.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.14.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.15.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.16.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.18.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.20.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.21.0/24 AS37004 -Reserved AS-,ZZ >> 41.76.48.0/21 AS36969 MTL-AS,MW >> 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US >> 41.78.236.0/24 AS37290 -Reserved AS-,ZZ >> 41.78.237.0/24 AS37290 -Reserved AS-,ZZ >> 41.78.238.0/24 AS37290 -Reserved AS-,ZZ >> 41.78.239.0/24 AS37290 -Reserved AS-,ZZ >> 41.190.72.0/24 AS37451 CongoTelecom,CG >> 41.190.73.0/24 AS37451 CongoTelecom,CG >> 41.190.74.0/24 AS37451 CongoTelecom,CG >> 41.190.75.0/24 AS37451 CongoTelecom,CG >> 41.191.108.0/22 AS37004 -Reserved AS-,ZZ >> 41.191.108.0/24 AS37004 -Reserved AS-,ZZ >> 41.191.109.0/24 AS37004 -Reserved AS-,ZZ >> 41.191.110.0/24 AS37004 -Reserved AS-,ZZ >> 41.191.111.0/24 AS37004 -Reserved AS-,ZZ >> 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL >> 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL >> 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos,US >> 63.247.0.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.1.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.2.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.3.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.4.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.5.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.6.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.7.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.8.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.9.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.10.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.11.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.13.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.14.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.15.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.16.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.17.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.18.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.19.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.20.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.21.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.22.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.23.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.24.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.25.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.26.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.27.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.28.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.29.0/24 AS27609 -Reserved AS-,ZZ >> 64.25.16.0/23 AS19535 -Reserved AS-,ZZ >> 64.25.20.0/24 AS19535 -Reserved AS-,ZZ >> 64.25.21.0/24 AS19535 -Reserved AS-,ZZ >> 64.25.22.0/24 AS19535 -Reserved AS-,ZZ >> 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 64.111.160.0/20 AS40551 -Reserved AS-,ZZ >> 64.111.160.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.161.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.162.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.167.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.169.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.170.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.171.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.172.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.173.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.174.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.175.0/24 AS40551 -Reserved AS-,ZZ >> 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US >> 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US >> 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US >> 66.55.96.0/23 AS17203 -Reserved AS-,ZZ >> 66.55.98.0/24 AS17203 -Reserved AS-,ZZ >> 66.55.99.0/24 AS17203 -Reserved AS-,ZZ >> 66.55.100.0/22 AS17203 -Reserved AS-,ZZ >> 66.55.102.0/23 AS17203 -Reserved AS-,ZZ >> 66.55.104.0/21 AS17203 -Reserved AS-,ZZ >> 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA >> 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US >> 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US >> 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.254.188.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT >> 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US >> 74.112.100.0/22 AS16764 -Reserved AS-,ZZ >> 74.113.200.0/23 AS46939 -Reserved AS-,ZZ >> 74.114.52.0/22 AS40818 -Reserved AS-,ZZ >> 74.114.52.0/23 AS40818 -Reserved AS-,ZZ >> 74.114.52.0/24 AS40818 -Reserved AS-,ZZ >> 74.114.53.0/24 AS40818 -Reserved AS-,ZZ >> 74.114.54.0/23 AS40818 -Reserved AS-,ZZ >> 74.114.54.0/24 AS40818 -Reserved AS-,ZZ >> 74.114.55.0/24 AS40818 -Reserved AS-,ZZ >> 74.115.124.0/23 AS46540 -Reserved AS-,ZZ >> 74.118.132.0/22 AS5117 -Reserved AS-,ZZ >> 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US >> 77.243.80.0/24 AS42597 -Reserved AS-,ZZ >> 77.243.81.0/24 AS42597 -Reserved AS-,ZZ >> 77.243.88.0/24 AS42597 -Reserved AS-,ZZ >> 77.243.91.0/24 AS42597 -Reserved AS-,ZZ >> 77.243.94.0/24 AS42597 -Reserved AS-,ZZ >> 77.243.95.0/24 AS42597 -Reserved AS-,ZZ >> 80.250.32.0/22 AS37106 ODUA-AS,NG >> 85.202.160.0/20 AS44404 -Reserved AS-,ZZ >> 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 91.197.36.0/22 AS43359 -Reserved AS-,ZZ >> 91.199.90.0/24 AS44330 -Reserved AS-,ZZ >> 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD,RU >> 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE >> 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT >> 91.229.182.0/24 AS56960 -Reserved AS-,ZZ >> 91.229.186.0/24 AS56967 -Reserved AS-,ZZ >> 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB >> 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ >> 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ >> 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ >> 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ >> 93.190.10.0/24 AS47254 -Reserved AS-,ZZ >> 95.215.140.0/22 AS48949 -Reserved AS-,ZZ >> 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU >> 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN >> 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN >> 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP >> 103.23.48.0/24 AS56194 >> 103.23.49.0/24 AS56194 >> 103.23.50.0/24 AS56194 >> 103.23.51.0/24 AS56194 >> 103.31.236.0/22 AS17941 BIT-ISLE Bit-isle Co.,Ltd.,JP >> 103.244.236.0/22 AS58794 >> 103.247.52.0/23 AS4725 ODN SOFTBANK TELECOM Corp.,JP >> 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU >> 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK >> 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US >> 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US >> 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US >> 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN >> 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN >> 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP >> 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US >> 172.85.0.0/24 AS29571 CITelecom-AS,CI >> 172.85.1.0/24 AS29571 CITelecom-AS,CI >> 172.85.2.0/24 AS29571 CITelecom-AS,CI >> 172.85.3.0/24 AS29571 CITelecom-AS,CI >> 172.86.0.0/24 AS29571 CITelecom-AS,CI >> 172.86.1.0/24 AS29571 CITelecom-AS,CI >> 172.86.2.0/24 AS29571 CITelecom-AS,CI >> 172.87.0.0/24 AS29571 CITelecom-AS,CI >> 172.88.0.0/24 AS29571 CITelecom-AS,CI >> 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN >> 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US >> 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO >> 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ >> 176.125.224.0/19 AS39906 COPROSYS CoProSys a.s.,CZ >> 185.57.4.0/22 AS21250 TYFON Tyfon Svenska AB - Sweden,SE >> 185.57.8.0/22 AS19790 HOSTNET Hostnet B.V.,NL >> 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO >> 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A.,EC >> 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR >> 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US >> 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US >> 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US >> 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US >> 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US >> 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US >> 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA >> 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US >> 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 192.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc.,US >> 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE >> 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US >> 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US >> 192.154.32.0/19 AS81 NCREN - MCNC,US >> 192.154.64.0/19 AS81 NCREN - MCNC,US >> 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 192.241.20.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US >> 192.241.21.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US >> 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US >> 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US >> 193.9.59.0/24 AS1257 TELE2,SE >> 193.16.106.0/24 AS31539 -Reserved AS-,ZZ >> 193.16.145.0/24 AS31392 -Reserved AS-,ZZ >> 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI >> 193.22.224.0/20 AS3322 -Reserved AS-,ZZ >> 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE >> 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB >> 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE >> 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB >> 193.84.187.0/24 AS16276 OVH OVH SAS,FR >> 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB >> 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO >> 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES >> 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO >> 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO >> 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE >> 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US >> 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT >> 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO >> 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.201.112.0/23 AS12964 DBMG-DE Dr. Buelow & Masiak GmbH,DE >> 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB >> 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB >> 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT >> 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.243.166.0/24 AS44093 -Reserved AS-,ZZ >> 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA >> 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA >> 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE >> 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE >> 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE >> 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB >> 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE >> 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB >> 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 194.69.203.0/24 AS5089 NTL Virgin Media Limited,GB >> 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE >> 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO >> 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE >> 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 194.126.219.0/24 AS34545 -Reserved AS-,ZZ >> 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR >> 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE >> 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE >> 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE >> 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA >> 194.213.8.0/24 AS42845 BRETAGNETELECOM BRETAGNE TELECOM SAS,FR >> 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO >> 195.39.252.0/23 AS29004 -Reserved AS-,ZZ >> 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE >> 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO >> 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.90.98.0/23 AS57511 OVALTECH-AS OvalTech Internet Ltd,GB >> 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL,RO >> 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE >> 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE >> 195.234.156.0/24 AS25028 -Reserved AS-,ZZ >> 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 196.2.224.0/22 AS24863 LINKdotNET-AS,EG >> 196.3.182.0/24 AS37004 -Reserved AS-,ZZ >> 196.3.183.0/24 AS37004 -Reserved AS-,ZZ >> 196.13.201.0/24 AS2018 TENET-1,ZA >> 196.13.202.0/24 AS2018 TENET-1,ZA >> 196.13.203.0/24 AS2018 TENET-1,ZA >> 196.13.204.0/24 AS2018 TENET-1,ZA >> 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR >> 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US >> 196.45.0.0/21 AS26625 -Reserved AS-,ZZ >> 196.45.10.0/24 AS26625 -Reserved AS-,ZZ >> 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US >> 198.72.78.0/23 AS3967 -Reserved AS-,ZZ >> 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US >> 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US >> 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US >> 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US >> 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US >> 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA >> 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA >> 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA >> 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA >> 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US >> 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US >> 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US >> 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US >> 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK >> 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US >> 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US >> 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US >> 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US >> 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US >> 199.30.138.0/24 AS23319 -Reserved AS-,ZZ >> 199.30.139.0/24 AS23319 -Reserved AS-,ZZ >> 199.30.143.0/24 AS8100 IPTELLIGENT - IPTelligent LLC,US >> 199.68.72.0/24 AS174 COGENT-174 - Cogent Communications,US >> 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA >> 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US >> 199.116.200.0/21 AS22830 -Reserved AS-,ZZ >> 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US >> 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US >> 200.58.248.0/21 AS27849 >> 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR >> 202.9.40.0/24 AS56194 >> 202.9.41.0/24 AS56194 >> 202.9.42.0/24 AS56194 >> 202.9.43.0/24 AS56194 >> 202.9.44.0/24 AS56194 >> 202.9.45.0/24 AS56194 >> 202.9.46.0/24 AS56194 >> 202.9.47.0/24 AS56194 >> 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK >> 202.58.113.0/24 AS19161 -Reserved AS-,ZZ >> 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN >> 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG >> 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN >> 203.142.219.0/24 AS45149 >> 203.189.116.0/22 AS45606 >> 203.189.116.0/24 AS45606 >> 203.189.117.0/24 AS45606 >> 203.189.118.0/24 AS45606 >> 203.189.119.0/24 AS45606 >> 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 204.10.94.0/23 AS30097 NUWAVE - NuWave,US >> 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US >> 204.16.96.0/24 AS19972 -Reserved AS-,ZZ >> 204.16.97.0/24 AS19972 -Reserved AS-,ZZ >> 204.16.98.0/24 AS19972 -Reserved AS-,ZZ >> 204.16.99.0/24 AS19972 -Reserved AS-,ZZ >> 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US >> 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US >> 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB >> 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA >> 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US >> 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp.,CA >> 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA >> 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US >> 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US >> 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US >> 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US >> 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US >> 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US >> 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US >> 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US >> 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US >> 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US >> 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM >> 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM >> 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM >> 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US >> 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US >> 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US >> 208.75.152.0/21 AS32146 -Reserved AS-,ZZ >> 208.76.20.0/24 AS31812 -Reserved AS-,ZZ >> 208.76.21.0/24 AS31812 -Reserved AS-,ZZ >> 208.77.164.0/24 AS22659 -Reserved AS-,ZZ >> 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US >> 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US >> 208.84.232.0/24 AS33131 -Reserved AS-,ZZ >> 208.84.234.0/24 AS33131 -Reserved AS-,ZZ >> 208.84.237.0/24 AS33131 -Reserved AS-,ZZ >> 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US >> 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US >> 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US >> 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US >> 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US >> 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US >> 209.234.112.0/23 AS32252 -Reserved AS-,ZZ >> 209.234.114.0/23 AS32252 -Reserved AS-,ZZ >> 209.234.116.0/24 AS32252 -Reserved AS-,ZZ >> 209.234.117.0/24 AS32252 -Reserved AS-,ZZ >> 209.234.118.0/24 AS32252 -Reserved AS-,ZZ >> 209.234.119.0/24 AS32252 -Reserved AS-,ZZ >> 209.234.120.0/24 AS32252 -Reserved AS-,ZZ >> 209.234.121.0/24 AS32252 -Reserved AS-,ZZ >> 209.234.122.0/24 AS32252 -Reserved AS-,ZZ >> 212.119.32.0/19 AS12550 -Reserved AS-,ZZ >> 213.184.64.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.65.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.66.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.67.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.68.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.69.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.70.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.71.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.72.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.73.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.74.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.75.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.76.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.77.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.78.0/24 AS13071 -Reserved AS-,ZZ >> 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US >> 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US >> 216.24.176.0/20 AS19401 -Reserved AS-,ZZ >> 216.24.188.0/24 AS19401 -Reserved AS-,ZZ >> 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US >> 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US >> 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US >> 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US >> 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US >> 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US >> 216.203.80.0/20 AS27021 -Reserved AS-,ZZ >> 216.203.80.0/21 AS27021 -Reserved AS-,ZZ >> 216.203.87.0/24 AS27021 -Reserved AS-,ZZ >> 216.203.88.0/21 AS27021 -Reserved AS-,ZZ >> 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc.,US >> 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US >> >> >> 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 surfer at mauigateway.com Sat May 10 01:01:07 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 9 May 2014 18:01:07 -0700 Subject: The Cidr Report Message-ID: <20140509180107.4462FBA6@m0005312.ppops.net> --- owen at delong.com wrote: From: Owen DeLong Don’t let network engineers party in Bellevue. ------------------------------------------------- Yeah, let me know how that works out... :-) scott From trelane at trelane.net Sat May 10 01:28:51 2014 From: trelane at trelane.net (Andrew D Kirch) Date: Fri, 9 May 2014 21:28:51 -0400 Subject: The Cidr Report In-Reply-To: References: <201405092200.s49M00Bt045330@wattle.apnic.net> <956DD505-E883-4468-B486-925B2954748F@ianai.net> Message-ID: <6d79f01cf6bef$33ea1b90$9bbe52b0$@trelane.net> If the whole thing breaks, I'm taking a vacation. Andrew -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Owen DeLong Sent: Friday, May 9, 2014 8:52 PM To: Patrick W. Gilmore Cc: nanog at nanog.org Subject: Re: The Cidr Report ROFLMAO — Party in Bellevue is more than likely to push it back up over 500K again, isn’t it? Sounds like a Dish commercial (James Earl Jones voice): When you put a bunch of network engineers in a party in Bellevue, you get a bunch of drunk network engineers. When you get drunk network engineers, you get interesting router configurations. When you get interesting router configurations you get disaggregation of the routing table for TE. When you get disaggregation for TE, the routing table grows. When the routing table grows, you hit half a million routes. When you hit half a million routes, the internet starts to break. Don’t break the internet. Don’t get half a million routes. Don’t let network engineers party in Bellevue. (No, I’m not actually opposed to the party, but I thought you might find the commercial amusing). Owen On May 9, 2014, at 3:11 PM, Patrick W. Gilmore wrote: > w00 h00! We did it!! > > Is this excellent or what? We dipped below half a million again! I am impressed. > > Keep up the good work, everyone. > > Party in Bellevue if we can keep it below 500K until then! > > -- > TTFN, > patrick > > >> On May 9, 2014, at 18:00, cidr-report at potaroo.net wrote: >> >> This report has been generated at Fri May 9 21:13:53 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 >> 02-05-14 500388 283099 >> 03-05-14 500674 281707 >> 04-05-14 499055 282390 >> 05-05-14 500188 281852 >> 06-05-14 499505 282156 >> 07-05-14 499946 281901 >> 08-05-14 499340 282123 >> 09-05-14 499630 282356 >> >> >> AS Summary >> 47026 Number of ASes in routing system >> 19165 Number of ASes announcing only one prefix >> 3777 Largest number of prefixes announced by an AS >> AS28573: NET Serviços de Comunicação S.A.,BR >> 120042496 Largest address span announced by an AS (/32s) >> AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN >> >> >> 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'). >> >> --- 09May14 --- >> ASnum NetsNow NetsAggr NetGain % Gain Description >> >> Table 499702 282290 217412 43.5% All ASes >> >> AS28573 3777 297 3480 92.1% NET Serviços de Comunicação >> S.A.,BR >> AS6389 2965 58 2907 98.0% BELLSOUTH-NET-BLK - >> BellSouth.net Inc.,US >> AS17974 2802 251 2551 91.0% TELKOMNET-AS2-AP PT >> Telekomunikasi Indonesia,ID >> AS4766 2947 931 2016 68.4% KIXS-AS-KR Korea Telecom,KR >> AS18881 1970 37 1933 98.1% Global Village Telecom,BR >> AS1785 2204 494 1710 77.6% AS-PAETEC-NET - PaeTec >> Communications, Inc.,US >> AS10620 2854 1358 1496 52.4% Telmex Colombia S.A.,CO >> AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath >> Corporation,US >> AS7303 1760 459 1301 73.9% Telecom Argentina S.A.,AR >> AS4755 1855 585 1270 68.5% TATACOMM-AS TATA >> Communications formerly VSNL >> is Leading ISP,IN >> AS4323 1639 421 1218 74.3% TWTC - tw telecom holdings, >> inc.,US >> AS7545 2238 1076 1162 51.9% TPG-INTERNET-AP TPG Telecom >> Limited,AU >> AS7552 1252 146 1106 88.3% VIETEL-AS-AP Viettel >> Corporation,VN >> AS22561 1306 241 1065 81.5% AS22561 - CenturyTel Internet >> Holdings, Inc.,US >> AS6983 1326 306 1020 76.9% ITCDELTA - Earthlink, Inc.,US >> AS36998 1114 160 954 85.6% SDN-MOBITEL,SD >> AS4788 1045 148 897 85.8% TMNET-AS-AP TM Net, Internet >> Service Provider,MY >> AS9829 1629 735 894 54.9% BSNL-NIB National Internet >> Backbone,IN >> AS22773 2420 1556 864 35.7% ASN-CXA-ALL-CCI-22773-RDC - >> Cox Communications Inc.,US >> AS24560 1130 295 835 73.9% AIRTELBROADBAND-AS-AP Bharti >> Airtel Ltd., Telemedia >> Services,IN >> AS4808 1212 394 818 67.5% CHINA169-BJ CNCGROUP IP >> network China169 Beijing >> Province Network,CN >> AS18101 946 187 759 80.2% RELIANCE-COMMUNICATIONS-IN >> Reliance Communications >> Ltd.DAKC MUMBAI,IN >> AS8151 1414 672 742 52.5% Uninet S.A. de C.V.,MX >> AS701 1481 751 730 49.3% UUNET - MCI Communications >> Services, Inc. d/b/a Verizon >> Business,US >> AS7738 913 183 730 80.0% Telemar Norte Leste S.A.,BR >> AS26615 842 113 729 86.6% Tim Celular S.A.,BR >> AS855 750 57 693 92.4% CANET-ASN-4 - Bell Aliant >> Regional Communications, >> Inc.,CA >> AS9808 1002 327 675 67.4% CMNET-GD Guangdong Mobile >> Communication Co.Ltd.,CN >> AS6147 784 113 671 85.6% Telefonica del Peru S.A.A.,PE >> AS4780 1039 374 665 64.0% SEEDNET Digital United Inc.,TW >> >> Total 50663 13290 37373 73.8% Top 30 total >> >> >> Possible Bogus Routes >> >> 27.100.7.0/24 AS56096 >> 41.73.1.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.2.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.10.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.11.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.12.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.13.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.14.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.15.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.16.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.18.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.20.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.21.0/24 AS37004 -Reserved AS-,ZZ >> 41.76.48.0/21 AS36969 MTL-AS,MW >> 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US >> 41.78.236.0/24 AS37290 -Reserved AS-,ZZ >> 41.78.237.0/24 AS37290 -Reserved AS-,ZZ >> 41.78.238.0/24 AS37290 -Reserved AS-,ZZ >> 41.78.239.0/24 AS37290 -Reserved AS-,ZZ >> 41.190.72.0/24 AS37451 CongoTelecom,CG >> 41.190.73.0/24 AS37451 CongoTelecom,CG >> 41.190.74.0/24 AS37451 CongoTelecom,CG >> 41.190.75.0/24 AS37451 CongoTelecom,CG >> 41.191.108.0/22 AS37004 -Reserved AS-,ZZ >> 41.191.108.0/24 AS37004 -Reserved AS-,ZZ >> 41.191.109.0/24 AS37004 -Reserved AS-,ZZ >> 41.191.110.0/24 AS37004 -Reserved AS-,ZZ >> 41.191.111.0/24 AS37004 -Reserved AS-,ZZ >> 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL >> 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL >> 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos,US >> 63.247.0.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.1.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.2.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.3.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.4.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.5.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.6.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.7.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.8.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.9.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.10.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.11.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.13.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.14.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.15.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.16.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.17.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.18.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.19.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.20.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.21.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.22.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.23.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.24.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.25.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.26.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.27.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.28.0/24 AS27609 -Reserved AS-,ZZ >> 63.247.29.0/24 AS27609 -Reserved AS-,ZZ >> 64.25.16.0/23 AS19535 -Reserved AS-,ZZ >> 64.25.20.0/24 AS19535 -Reserved AS-,ZZ >> 64.25.21.0/24 AS19535 -Reserved AS-,ZZ >> 64.25.22.0/24 AS19535 -Reserved AS-,ZZ >> 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 64.111.160.0/20 AS40551 -Reserved AS-,ZZ >> 64.111.160.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.161.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.162.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.167.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.169.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.170.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.171.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.172.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.173.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.174.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.175.0/24 AS40551 -Reserved AS-,ZZ >> 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US >> 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US >> 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US >> 66.55.96.0/23 AS17203 -Reserved AS-,ZZ >> 66.55.98.0/24 AS17203 -Reserved AS-,ZZ >> 66.55.99.0/24 AS17203 -Reserved AS-,ZZ >> 66.55.100.0/22 AS17203 -Reserved AS-,ZZ >> 66.55.102.0/23 AS17203 -Reserved AS-,ZZ >> 66.55.104.0/21 AS17203 -Reserved AS-,ZZ >> 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA >> 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US >> 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US >> 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.254.188.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT >> 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US >> 74.112.100.0/22 AS16764 -Reserved AS-,ZZ >> 74.113.200.0/23 AS46939 -Reserved AS-,ZZ >> 74.114.52.0/22 AS40818 -Reserved AS-,ZZ >> 74.114.52.0/23 AS40818 -Reserved AS-,ZZ >> 74.114.52.0/24 AS40818 -Reserved AS-,ZZ >> 74.114.53.0/24 AS40818 -Reserved AS-,ZZ >> 74.114.54.0/23 AS40818 -Reserved AS-,ZZ >> 74.114.54.0/24 AS40818 -Reserved AS-,ZZ >> 74.114.55.0/24 AS40818 -Reserved AS-,ZZ >> 74.115.124.0/23 AS46540 -Reserved AS-,ZZ >> 74.118.132.0/22 AS5117 -Reserved AS-,ZZ >> 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US >> 77.243.80.0/24 AS42597 -Reserved AS-,ZZ >> 77.243.81.0/24 AS42597 -Reserved AS-,ZZ >> 77.243.88.0/24 AS42597 -Reserved AS-,ZZ >> 77.243.91.0/24 AS42597 -Reserved AS-,ZZ >> 77.243.94.0/24 AS42597 -Reserved AS-,ZZ >> 77.243.95.0/24 AS42597 -Reserved AS-,ZZ >> 80.250.32.0/22 AS37106 ODUA-AS,NG >> 85.202.160.0/20 AS44404 -Reserved AS-,ZZ >> 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 91.197.36.0/22 AS43359 -Reserved AS-,ZZ >> 91.199.90.0/24 AS44330 -Reserved AS-,ZZ >> 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD,RU >> 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE >> 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT >> 91.229.182.0/24 AS56960 -Reserved AS-,ZZ >> 91.229.186.0/24 AS56967 -Reserved AS-,ZZ >> 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB >> 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ >> 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ >> 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ >> 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ >> 93.190.10.0/24 AS47254 -Reserved AS-,ZZ >> 95.215.140.0/22 AS48949 -Reserved AS-,ZZ >> 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU >> 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN >> 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN >> 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP >> 103.23.48.0/24 AS56194 >> 103.23.49.0/24 AS56194 >> 103.23.50.0/24 AS56194 >> 103.23.51.0/24 AS56194 >> 103.31.236.0/22 AS17941 BIT-ISLE Bit-isle Co.,Ltd.,JP >> 103.244.236.0/22 AS58794 >> 103.247.52.0/23 AS4725 ODN SOFTBANK TELECOM Corp.,JP >> 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU >> 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK >> 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US >> 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US >> 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US >> 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN >> 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN >> 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP >> 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US >> 172.85.0.0/24 AS29571 CITelecom-AS,CI >> 172.85.1.0/24 AS29571 CITelecom-AS,CI >> 172.85.2.0/24 AS29571 CITelecom-AS,CI >> 172.85.3.0/24 AS29571 CITelecom-AS,CI >> 172.86.0.0/24 AS29571 CITelecom-AS,CI >> 172.86.1.0/24 AS29571 CITelecom-AS,CI >> 172.86.2.0/24 AS29571 CITelecom-AS,CI >> 172.87.0.0/24 AS29571 CITelecom-AS,CI >> 172.88.0.0/24 AS29571 CITelecom-AS,CI >> 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN >> 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US >> 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO >> 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ >> 176.125.224.0/19 AS39906 COPROSYS CoProSys a.s.,CZ >> 185.57.4.0/22 AS21250 TYFON Tyfon Svenska AB - Sweden,SE >> 185.57.8.0/22 AS19790 HOSTNET Hostnet B.V.,NL >> 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO >> 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A.,EC >> 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR >> 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US >> 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US >> 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US >> 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US >> 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US >> 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US >> 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA >> 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US >> 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 192.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc.,US >> 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE >> 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US >> 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US >> 192.154.32.0/19 AS81 NCREN - MCNC,US >> 192.154.64.0/19 AS81 NCREN - MCNC,US >> 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 192.241.20.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US >> 192.241.21.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US >> 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US >> 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US >> 193.9.59.0/24 AS1257 TELE2,SE >> 193.16.106.0/24 AS31539 -Reserved AS-,ZZ >> 193.16.145.0/24 AS31392 -Reserved AS-,ZZ >> 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI >> 193.22.224.0/20 AS3322 -Reserved AS-,ZZ >> 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE >> 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB >> 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE >> 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB >> 193.84.187.0/24 AS16276 OVH OVH SAS,FR >> 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB >> 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO >> 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES >> 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO >> 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO >> 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE >> 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US >> 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT >> 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO >> 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.201.112.0/23 AS12964 DBMG-DE Dr. Buelow & Masiak GmbH,DE >> 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB >> 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB >> 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT >> 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.243.166.0/24 AS44093 -Reserved AS-,ZZ >> 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA >> 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA >> 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE >> 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE >> 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE >> 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB >> 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE >> 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB >> 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 194.69.203.0/24 AS5089 NTL Virgin Media Limited,GB >> 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE >> 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO >> 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE >> 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 194.126.219.0/24 AS34545 -Reserved AS-,ZZ >> 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR >> 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE >> 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE >> 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE >> 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA >> 194.213.8.0/24 AS42845 BRETAGNETELECOM BRETAGNE TELECOM SAS,FR >> 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO >> 195.39.252.0/23 AS29004 -Reserved AS-,ZZ >> 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE >> 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO >> 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.90.98.0/23 AS57511 OVALTECH-AS OvalTech Internet Ltd,GB >> 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL,RO >> 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE >> 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE >> 195.234.156.0/24 AS25028 -Reserved AS-,ZZ >> 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 196.2.224.0/22 AS24863 LINKdotNET-AS,EG >> 196.3.182.0/24 AS37004 -Reserved AS-,ZZ >> 196.3.183.0/24 AS37004 -Reserved AS-,ZZ >> 196.13.201.0/24 AS2018 TENET-1,ZA >> 196.13.202.0/24 AS2018 TENET-1,ZA >> 196.13.203.0/24 AS2018 TENET-1,ZA >> 196.13.204.0/24 AS2018 TENET-1,ZA >> 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR >> 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US >> 196.45.0.0/21 AS26625 -Reserved AS-,ZZ >> 196.45.10.0/24 AS26625 -Reserved AS-,ZZ >> 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US >> 198.72.78.0/23 AS3967 -Reserved AS-,ZZ >> 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US >> 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US >> 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US >> 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US >> 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US >> 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA >> 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA >> 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA >> 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA >> 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US >> 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US >> 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US >> 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US >> 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK >> 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US >> 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US >> 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US >> 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US >> 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US >> 199.30.138.0/24 AS23319 -Reserved AS-,ZZ >> 199.30.139.0/24 AS23319 -Reserved AS-,ZZ >> 199.30.143.0/24 AS8100 IPTELLIGENT - IPTelligent LLC,US >> 199.68.72.0/24 AS174 COGENT-174 - Cogent Communications,US >> 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA >> 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US >> 199.116.200.0/21 AS22830 -Reserved AS-,ZZ >> 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US >> 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US >> 200.58.248.0/21 AS27849 >> 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR >> 202.9.40.0/24 AS56194 >> 202.9.41.0/24 AS56194 >> 202.9.42.0/24 AS56194 >> 202.9.43.0/24 AS56194 >> 202.9.44.0/24 AS56194 >> 202.9.45.0/24 AS56194 >> 202.9.46.0/24 AS56194 >> 202.9.47.0/24 AS56194 >> 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK >> 202.58.113.0/24 AS19161 -Reserved AS-,ZZ >> 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN >> 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG >> 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN >> 203.142.219.0/24 AS45149 >> 203.189.116.0/22 AS45606 >> 203.189.116.0/24 AS45606 >> 203.189.117.0/24 AS45606 >> 203.189.118.0/24 AS45606 >> 203.189.119.0/24 AS45606 >> 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 204.10.94.0/23 AS30097 NUWAVE - NuWave,US >> 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US >> 204.16.96.0/24 AS19972 -Reserved AS-,ZZ >> 204.16.97.0/24 AS19972 -Reserved AS-,ZZ >> 204.16.98.0/24 AS19972 -Reserved AS-,ZZ >> 204.16.99.0/24 AS19972 -Reserved AS-,ZZ >> 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US >> 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US >> 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB >> 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA >> 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US >> 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp.,CA >> 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA >> 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US >> 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US >> 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US >> 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US >> 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US >> 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US >> 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US >> 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US >> 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US >> 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US >> 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM >> 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM >> 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM >> 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US >> 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US >> 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US >> 208.75.152.0/21 AS32146 -Reserved AS-,ZZ >> 208.76.20.0/24 AS31812 -Reserved AS-,ZZ >> 208.76.21.0/24 AS31812 -Reserved AS-,ZZ >> 208.77.164.0/24 AS22659 -Reserved AS-,ZZ >> 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US >> 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US >> 208.84.232.0/24 AS33131 -Reserved AS-,ZZ >> 208.84.234.0/24 AS33131 -Reserved AS-,ZZ >> 208.84.237.0/24 AS33131 -Reserved AS-,ZZ >> 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US >> 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US >> 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US >> 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US >> 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US >> 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US >> 209.234.112.0/23 AS32252 -Reserved AS-,ZZ >> 209.234.114.0/23 AS32252 -Reserved AS-,ZZ >> 209.234.116.0/24 AS32252 -Reserved AS-,ZZ >> 209.234.117.0/24 AS32252 -Reserved AS-,ZZ >> 209.234.118.0/24 AS32252 -Reserved AS-,ZZ >> 209.234.119.0/24 AS32252 -Reserved AS-,ZZ >> 209.234.120.0/24 AS32252 -Reserved AS-,ZZ >> 209.234.121.0/24 AS32252 -Reserved AS-,ZZ >> 209.234.122.0/24 AS32252 -Reserved AS-,ZZ >> 212.119.32.0/19 AS12550 -Reserved AS-,ZZ >> 213.184.64.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.65.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.66.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.67.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.68.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.69.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.70.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.71.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.72.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.73.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.74.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.75.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.76.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.77.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.78.0/24 AS13071 -Reserved AS-,ZZ >> 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US >> 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US >> 216.24.176.0/20 AS19401 -Reserved AS-,ZZ >> 216.24.188.0/24 AS19401 -Reserved AS-,ZZ >> 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US >> 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US >> 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US >> 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US >> 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US >> 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US >> 216.203.80.0/20 AS27021 -Reserved AS-,ZZ >> 216.203.80.0/21 AS27021 -Reserved AS-,ZZ >> 216.203.87.0/24 AS27021 -Reserved AS-,ZZ >> 216.203.88.0/21 AS27021 -Reserved AS-,ZZ >> 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc.,US >> 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US >> >> >> 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 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4570 / Virus Database: 3931/7443 - Release Date: 05/05/14 From Valdis.Kletnieks at vt.edu Sat May 10 14:17:16 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 10 May 2014 10:17:16 -0400 Subject: The Cidr Report In-Reply-To: Your message of "Fri, 09 May 2014 17:51:56 -0700." References: <201405092200.s49M00Bt045330@wattle.apnic.net> <956DD505-E883-4468-B486-925B2954748F@ianai.net> Message-ID: <6561.1399731436@turing-police.cc.vt.edu> On Fri, 09 May 2014 17:51:56 -0700, Owen DeLong said: > Sounds like a Dish commercial (James Earl Jones voice): Now imagine it again, but with Jim Cummings instead... https://www.youtube.com/watch?v=eLXTDirrQ5w (Sorry, I couldn't resist... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From antoine.meillet at gmail.com Sat May 10 14:58:58 2014 From: antoine.meillet at gmail.com (Antoine Meillet) Date: Sat, 10 May 2014 16:58:58 +0200 Subject: About NetFlow/IPFIX and DPI In-Reply-To: <20140507164338.GA12304@moussaka.pmacct.net> References: <20140507154506.GA11696@moussaka.pmacct.net> <5A3E2A55-8BAF-4A9F-A2A1-F755DAF1A1ED@arbor.net> <20140507164338.GA12304@moussaka.pmacct.net> Message-ID: Thank you Matt (offlist), Dan, Roland and Paolo for your answers ! Antoine. On 7 mai 2014, at 18:43, Paolo Lucente wrote: > Please note NBAR/NetFlow integration wanted to be an example of > using NetFlow/ IPFIX as a transport for DPI classification info > (where classification could be performed with any other in-line > technology than NBAR). > > Whether NBAR works or does not as a classification technology is > out of scope for me here - and seems also out of the op request. > > Inline: > > On Wed, May 07, 2014 at 04:15:44PM +0000, Dobbins, Roland wrote: > >> So, perhaps now we can de-conflate flow telemetry and 'DPI', since the real-life export, collection, and analysis of anything other than layer-4 information via flow telemetry isn't at all commonplace (if it in fact exists at all) on production networks), at this juncture. > > I disagree if anybody conflates here. I don't. I see two disjoint > pieces: classification technology and transport of classification > info to a central location. IPFIX, for example, is general (and > standardized) enough to transport/encapsulate other info than just > flow info, this might include DPI classification or other stuff. > You can also read this as: if you have to travel some info, why re > invent the wheel and not leverage a general-enough, standardized > transport protocol (that btw you can contribute at any point to > enhance if not satisfactory enough)? > > And please it's nice to have different positions - no need to escalate. > > Cheers, > Paolo From jnanog at gmail.com Sat May 10 15:04:02 2014 From: jnanog at gmail.com (Rick Astley) Date: Sat, 10 May 2014 11:04:02 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: <536BBC62.4070805@KingsMountain.com> References: <536BBC62.4070805@KingsMountain.com> Message-ID: That was an interesting read but it's not the whole story. Skip to the TL;DR if you'd like but I'll attempt to explain what happened. What he isn't saying is the roles of the companies involved have changed over the last 10 years. Mostly gone are the days that content providers and access networks each just gave a middleman/transit provider money to reach each other. "Content provider" has expanded to become "content delivery network" and "access network" has expanded their role to offer transit as well. If these networks have a large amount of traffic between them and are able to reach each other in multiple locations nationally what is the technical reason a 3rd party transit network is required instead of a direct peering relationship? From a purely technical perspective content and access at that scale can peer directly cutting out the middle man. The reality is an increasingly directly peered Internet doesn't sit well if you are in the business of being the middle man. Now if you will, why do transit companies themselves charge content companies to deliver bits? How is it fair to be in the business of charging companies to receive their bits and hand them to a settlement free peer on the hook to deliver them, but not fair for content to just bypass the transit company and enter a paid peering agreement with the company delivering the bits? In this case paid peering is mutually beneficial to both companies involved and is typically cheaper for the content company than it would cost to send that traffic over transit. What we have is a major shift in the market over the last 10 or so years. So why are these large nationally connected "access" networks charging Level 3 for ports? That's the elephant in the room here and to understand that you have to go back to where (to my knowledge) this dispute first went public. The most comprehensive description I have seen to date is the following Youtube video: https://www.youtube.com/watch?v=tR1sLLOYxnY I recommend the video before continuing. "Level 3" is really both Level 3 transit and Level 3 CDN. Level 3 has already had a long standing precedent of justifying the right of an ISP to charge for content delivery. So what happens when Level 3 greatly expands their content delivery business and sends traffic to other ISP's over settlement free ports? The large access networks say "hey, content delivery is a billable service, you should know" and they ask Level 3 CDN for compensation. The middleman networks protest and say "Charging for content delivery is only OK if we do it, but not when you do it!" and their justification for this claim is made on the basis that unlike access networks they a) Have a large network and b) send a full table of prefixes. So lets look at the first claim. Are the transit networks large? Yes, but especially in the case of North American traffic destined for North America they are typically smaller overall than the largest access networks who arguably have the lions share of equipment tasked with delivering the bits beyond just the colo. The 2nd claim is mostly a strawman and this is why. Middlemen still carry traffic not destined to directly connected peers but how they bill for it is largely based on volume of traffic, not the number of prefixes exchanged. The big content providers and the big access networks make up a majority of the traffic on the Internet even if they don't make up a majority of the prefixes. TL;DR So the reason the ports are maxed out is the market has changed, access networks have attempted to change peering agreements to match the existing market conditions but the middleman networks are arguing they should be exempt from the long standing tradition of charging for content delivery they themselves helped to establish. Some middleman networks have responded by refusing payment to access networks for delivery and as a result, the paths have not been upgraded and remain congested. End of TL;DR The next part is (even) more opinion than fact so you are forgiven if you stop here. My opinion is this is a peering dispute more than something that should fall under net neutrality. If content companies sent letters to "middlmen" that said "In your statements to the public you made the case that content delivery to ISP's should be settlement free so we have decided to take your offer and refuse any further payment to you from here forward" how would they handle it? Likely those companies would not only find themselves congested but depeered. A bunch of people say charging at both ends is double dipping but really modern access networks are now at least partly filling the role of transit as well as last mile delivery. Where "content" "transit" and "access" all have a presence in the same colo, paying more money to send traffic through transit first instead of just directly to access because of some dated definition of what the roles of those companies are supposed to be doesn't make sense to me. Hijacking NN to attempt to bring litigation into the matter to protect an old business model from a changing market makes even less sense. Seeing Level 3 publish half truths in what looks like an attempt to mislead the public on the matter is disappointing. I would expect it from maybe Cogent but I have higher expectations of Level 3. Broadband providers obviously aren't without some blame in the matter either. One of them is allowing customer satisfaction to be so low that they are easy targets for misinformation as most the comments I have seen on the matter to date are more emotional than rational. They have other mistakes too but for the purpose of keeping this brief and because some of them have been heavily documented elsewhere I'll save them for another day. On Thu, May 8, 2014 at 1:18 PM, =JeffH wrote: > Observations of an Internet Middleman (Level3) > http://blog.level3.com/global-connectivity/observations- > internet-middleman/ > > See also... > > Level 3 accuses five unnamed US ISPs of abusing their market power in > peering > http://gigaom.com/2014/05/05/level-3-accuses-five-unnamed- > us-isps-of-abusing-their-market-power-in-peering/ > > "... > I’d love to see Cogent, Google and other providers release their data > next, so even if the FCC doesn’t want to pursue this, a growing cry of > consumer outrage could push the agency to do something about a very real > and difficult problem that’s crippling access to video content on 5 U.S. > broadband networks. Level 3 didn’t name names, but based on the deals > Netflix has signed and the complaints it has made about AT&T, I’m confident > that AT&T, Verizon and Comcast are among the five. " > > > =JeffH > > > > From mpetach at netflight.com Sat May 10 06:19:40 2014 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 9 May 2014 23:19:40 -0700 Subject: The Cidr Report In-Reply-To: <6d79f01cf6bef$33ea1b90$9bbe52b0$@trelane.net> References: <201405092200.s49M00Bt045330@wattle.apnic.net> <956DD505-E883-4468-B486-925B2954748F@ianai.net> <6d79f01cf6bef$33ea1b90$9bbe52b0$@trelane.net> Message-ID: On Fri, May 9, 2014 at 6:28 PM, Andrew D Kirch wrote: > If the whole thing breaks, I'm taking a vacation. > > Dammit, I'm *on* vacation--don't break the whole thing! Matt > Andrew > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Owen DeLong > Sent: Friday, May 9, 2014 8:52 PM > To: Patrick W. Gilmore > Cc: nanog at nanog.org > Subject: Re: The Cidr Report > > > ROFLMAO — Party in Bellevue is more than likely to push it back up over > 500K > again, isn’t it? > > Sounds like a Dish commercial… (James Earl Jones voice): > > When you put a bunch of network engineers in a party in Bellevue, you get a > bunch of drunk network engineers. > When you get drunk network engineers, you get interesting router > configurations. > When you get interesting router configurations you get disaggregation of > the > routing table for TE. > When you get disaggregation for TE, the routing table grows. > When the routing table grows, you hit half a million routes. > When you hit half a million routes, the internet starts to break. > > Don’t break the internet. Don’t get half a million routes. Don’t let > network > engineers party in Bellevue. > > (No, I’m not actually opposed to the party, but I thought you might find > the > commercial amusing). > > Owen > > On May 9, 2014, at 3:11 PM, Patrick W. Gilmore wrote: > > > w00 h00! We did it!! > > > > Is this excellent or what? We dipped below half a million again! I am > impressed. > > > > Keep up the good work, everyone. > > > > Party in Bellevue if we can keep it below 500K until then! > > > > -- > > TTFN, > > patrick > > > > > >> On May 9, 2014, at 18:00, cidr-report at potaroo.net wrote: > >> > >> This report has been generated at Fri May 9 21:13:53 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 > >> 02-05-14 500388 283099 > >> 03-05-14 500674 281707 > >> 04-05-14 499055 282390 > >> 05-05-14 500188 281852 > >> 06-05-14 499505 282156 > >> 07-05-14 499946 281901 > >> 08-05-14 499340 282123 > >> 09-05-14 499630 282356 > >> > >> > >> AS Summary > >> 47026 Number of ASes in routing system > >> 19165 Number of ASes announcing only one prefix > >> 3777 Largest number of prefixes announced by an AS > >> AS28573: NET Serviços de Comunicação S.A.,BR > >> 120042496 Largest address span announced by an AS (/32s) > >> AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN > >> > >> > >> 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'). > >> > >> --- 09May14 --- > >> ASnum NetsNow NetsAggr NetGain % Gain Description > >> > >> Table 499702 282290 217412 43.5% All ASes > >> > >> AS28573 3777 297 3480 92.1% NET Serviços de > Comunicação > >> S.A.,BR > >> AS6389 2965 58 2907 98.0% BELLSOUTH-NET-BLK - > >> BellSouth.net Inc.,US > >> AS17974 2802 251 2551 91.0% TELKOMNET-AS2-AP PT > >> Telekomunikasi Indonesia,ID > >> AS4766 2947 931 2016 68.4% KIXS-AS-KR Korea > Telecom,KR > >> AS18881 1970 37 1933 98.1% Global Village Telecom,BR > >> AS1785 2204 494 1710 77.6% AS-PAETEC-NET - PaeTec > >> Communications, Inc.,US > >> AS10620 2854 1358 1496 52.4% Telmex Colombia S.A.,CO > >> AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath > >> Corporation,US > >> AS7303 1760 459 1301 73.9% Telecom Argentina S.A.,AR > >> AS4755 1855 585 1270 68.5% TATACOMM-AS TATA > >> Communications formerly > VSNL > >> is Leading ISP,IN > >> AS4323 1639 421 1218 74.3% TWTC - tw telecom > holdings, > >> inc.,US > >> AS7545 2238 1076 1162 51.9% TPG-INTERNET-AP TPG > Telecom > >> Limited,AU > >> AS7552 1252 146 1106 88.3% VIETEL-AS-AP Viettel > >> Corporation,VN > >> AS22561 1306 241 1065 81.5% AS22561 - CenturyTel > Internet > >> Holdings, Inc.,US > >> AS6983 1326 306 1020 76.9% ITCDELTA - Earthlink, > Inc.,US > >> AS36998 1114 160 954 85.6% SDN-MOBITEL,SD > >> AS4788 1045 148 897 85.8% TMNET-AS-AP TM Net, > Internet > >> Service Provider,MY > >> AS9829 1629 735 894 54.9% BSNL-NIB National Internet > >> Backbone,IN > >> AS22773 2420 1556 864 35.7% ASN-CXA-ALL-CCI-22773-RDC > - > >> Cox Communications Inc.,US > >> AS24560 1130 295 835 73.9% AIRTELBROADBAND-AS-AP > Bharti > >> Airtel Ltd., Telemedia > >> Services,IN > >> AS4808 1212 394 818 67.5% CHINA169-BJ CNCGROUP IP > >> network China169 Beijing > >> Province Network,CN > >> AS18101 946 187 759 80.2% RELIANCE-COMMUNICATIONS-IN > >> Reliance Communications > >> Ltd.DAKC MUMBAI,IN > >> AS8151 1414 672 742 52.5% Uninet S.A. de C.V.,MX > >> AS701 1481 751 730 49.3% UUNET - MCI Communications > >> Services, Inc. d/b/a > Verizon > >> Business,US > >> AS7738 913 183 730 80.0% Telemar Norte Leste > S.A.,BR > >> AS26615 842 113 729 86.6% Tim Celular S.A.,BR > >> AS855 750 57 693 92.4% CANET-ASN-4 - Bell Aliant > >> Regional Communications, > >> Inc.,CA > >> AS9808 1002 327 675 67.4% CMNET-GD Guangdong Mobile > >> Communication Co.Ltd.,CN > >> AS6147 784 113 671 85.6% Telefonica del Peru > S.A.A.,PE > >> AS4780 1039 374 665 64.0% SEEDNET Digital United > Inc.,TW > >> > >> Total 50663 13290 37373 73.8% Top 30 total > >> > >> > >> Possible Bogus Routes > >> > >> 27.100.7.0/24 AS56096 > >> 41.73.1.0/24 AS37004 -Reserved AS-,ZZ > >> 41.73.2.0/24 AS37004 -Reserved AS-,ZZ > >> 41.73.10.0/24 AS37004 -Reserved AS-,ZZ > >> 41.73.11.0/24 AS37004 -Reserved AS-,ZZ > >> 41.73.12.0/24 AS37004 -Reserved AS-,ZZ > >> 41.73.13.0/24 AS37004 -Reserved AS-,ZZ > >> 41.73.14.0/24 AS37004 -Reserved AS-,ZZ > >> 41.73.15.0/24 AS37004 -Reserved AS-,ZZ > >> 41.73.16.0/24 AS37004 -Reserved AS-,ZZ > >> 41.73.18.0/24 AS37004 -Reserved AS-,ZZ > >> 41.73.20.0/24 AS37004 -Reserved AS-,ZZ > >> 41.73.21.0/24 AS37004 -Reserved AS-,ZZ > >> 41.76.48.0/21 AS36969 MTL-AS,MW > >> 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE > CORPORATION,US > >> 41.78.236.0/24 AS37290 -Reserved AS-,ZZ > >> 41.78.237.0/24 AS37290 -Reserved AS-,ZZ > >> 41.78.238.0/24 AS37290 -Reserved AS-,ZZ > >> 41.78.239.0/24 AS37290 -Reserved AS-,ZZ > >> 41.190.72.0/24 AS37451 CongoTelecom,CG > >> 41.190.73.0/24 AS37451 CongoTelecom,CG > >> 41.190.74.0/24 AS37451 CongoTelecom,CG > >> 41.190.75.0/24 AS37451 CongoTelecom,CG > >> 41.191.108.0/22 AS37004 -Reserved AS-,ZZ > >> 41.191.108.0/24 AS37004 -Reserved AS-,ZZ > >> 41.191.109.0/24 AS37004 -Reserved AS-,ZZ > >> 41.191.110.0/24 AS37004 -Reserved AS-,ZZ > >> 41.191.111.0/24 AS37004 -Reserved AS-,ZZ > >> 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL > >> 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL > >> 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos,US > >> 63.247.0.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.1.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.2.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.3.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.4.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.5.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.6.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.7.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.8.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.9.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.10.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.11.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.13.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.14.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.15.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.16.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.17.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.18.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.19.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.20.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.21.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.22.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.23.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.24.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.25.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.26.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.27.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.28.0/24 AS27609 -Reserved AS-,ZZ > >> 63.247.29.0/24 AS27609 -Reserved AS-,ZZ > >> 64.25.16.0/23 AS19535 -Reserved AS-,ZZ > >> 64.25.20.0/24 AS19535 -Reserved AS-,ZZ > >> 64.25.21.0/24 AS19535 -Reserved AS-,ZZ > >> 64.25.22.0/24 AS19535 -Reserved AS-,ZZ > >> 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI > Communications Services, Inc. d/b/a Verizon Business,US > >> 64.111.160.0/20 AS40551 -Reserved AS-,ZZ > >> 64.111.160.0/24 AS40551 -Reserved AS-,ZZ > >> 64.111.161.0/24 AS40551 -Reserved AS-,ZZ > >> 64.111.162.0/24 AS40551 -Reserved AS-,ZZ > >> 64.111.167.0/24 AS40551 -Reserved AS-,ZZ > >> 64.111.169.0/24 AS40551 -Reserved AS-,ZZ > >> 64.111.170.0/24 AS40551 -Reserved AS-,ZZ > >> 64.111.171.0/24 AS40551 -Reserved AS-,ZZ > >> 64.111.172.0/24 AS40551 -Reserved AS-,ZZ > >> 64.111.173.0/24 AS40551 -Reserved AS-,ZZ > >> 64.111.174.0/24 AS40551 -Reserved AS-,ZZ > >> 64.111.175.0/24 AS40551 -Reserved AS-,ZZ > >> 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US > >> 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US > >> 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US > >> 66.55.96.0/23 AS17203 -Reserved AS-,ZZ > >> 66.55.98.0/24 AS17203 -Reserved AS-,ZZ > >> 66.55.99.0/24 AS17203 -Reserved AS-,ZZ > >> 66.55.100.0/22 AS17203 -Reserved AS-,ZZ > >> 66.55.102.0/23 AS17203 -Reserved AS-,ZZ > >> 66.55.104.0/21 AS17203 -Reserved AS-,ZZ > >> 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development > Corporation,CA > >> 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated > Computer Services, Inc.,US > >> 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, > Inc.,US > >> 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge > Networks,US > >> 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge > Networks,US > >> 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge > Networks,US > >> 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge > Networks,US > >> 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge > Networks,US > >> 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge > Networks,US > >> 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge > Networks,US > >> 66.254.188.0/22 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT > >> 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, > Inc.,US > >> 74.112.100.0/22 AS16764 -Reserved AS-,ZZ > >> 74.113.200.0/23 AS46939 -Reserved AS-,ZZ > >> 74.114.52.0/22 AS40818 -Reserved AS-,ZZ > >> 74.114.52.0/23 AS40818 -Reserved AS-,ZZ > >> 74.114.52.0/24 AS40818 -Reserved AS-,ZZ > >> 74.114.53.0/24 AS40818 -Reserved AS-,ZZ > >> 74.114.54.0/23 AS40818 -Reserved AS-,ZZ > >> 74.114.54.0/24 AS40818 -Reserved AS-,ZZ > >> 74.114.55.0/24 AS40818 -Reserved AS-,ZZ > >> 74.115.124.0/23 AS46540 -Reserved AS-,ZZ > >> 74.118.132.0/22 AS5117 -Reserved AS-,ZZ > >> 74.121.24.0/22 AS36263 FORONA - Forona Technologies, > Inc.,US > >> 77.243.80.0/24 AS42597 -Reserved AS-,ZZ > >> 77.243.81.0/24 AS42597 -Reserved AS-,ZZ > >> 77.243.88.0/24 AS42597 -Reserved AS-,ZZ > >> 77.243.91.0/24 AS42597 -Reserved AS-,ZZ > >> 77.243.94.0/24 AS42597 -Reserved AS-,ZZ > >> 77.243.95.0/24 AS42597 -Reserved AS-,ZZ > >> 80.250.32.0/22 AS37106 ODUA-AS,NG > >> 85.202.160.0/20 AS44404 -Reserved AS-,ZZ > >> 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 91.197.36.0/22 AS43359 -Reserved AS-,ZZ > >> 91.199.90.0/24 AS44330 -Reserved AS-,ZZ > >> 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD,RU > >> 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE > >> 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise > Mageal,LT > >> 91.229.182.0/24 AS56960 -Reserved AS-,ZZ > >> 91.229.186.0/24 AS56967 -Reserved AS-,ZZ > >> 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting > Limited,GB > >> 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > >> 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > >> 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > >> 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > >> 93.190.10.0/24 AS47254 -Reserved AS-,ZZ > >> 95.215.140.0/22 AS48949 -Reserved AS-,ZZ > >> 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU > >> 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN > >> 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center > building,MN > >> 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP > >> 103.23.48.0/24 AS56194 > >> 103.23.49.0/24 AS56194 > >> 103.23.50.0/24 AS56194 > >> 103.23.51.0/24 AS56194 > >> 103.31.236.0/22 AS17941 BIT-ISLE Bit-isle Co.,Ltd.,JP > >> 103.244.236.0/22 AS58794 > >> 103.247.52.0/23 AS4725 ODN SOFTBANK TELECOM Corp.,JP > >> 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks > Pty Ltd,AU > >> 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan > Telecommunication Company Limited,PK > >> 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, > Inc,US > >> 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, > Inc,US > >> 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, > Inc,US > >> 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications > formerly VSNL is Leading ISP,IN > >> 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong > Street,CN > >> 163.47.23.0/24 AS2907 SINET-AS Research Organization of > Information and Systems, National Institute of Informatics,JP > >> 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US > >> 172.85.0.0/24 AS29571 CITelecom-AS,CI > >> 172.85.1.0/24 AS29571 CITelecom-AS,CI > >> 172.85.2.0/24 AS29571 CITelecom-AS,CI > >> 172.85.3.0/24 AS29571 CITelecom-AS,CI > >> 172.86.0.0/24 AS29571 CITelecom-AS,CI > >> 172.86.1.0/24 AS29571 CITelecom-AS,CI > >> 172.86.2.0/24 AS29571 CITelecom-AS,CI > >> 172.87.0.0/24 AS29571 CITelecom-AS,CI > >> 172.88.0.0/24 AS29571 CITelecom-AS,CI > >> 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom > (Group),CN > >> 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, > Inc.,US > >> 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO > >> 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ > >> 176.125.224.0/19 AS39906 COPROSYS CoProSys a.s.,CZ > >> 185.57.4.0/22 AS21250 TYFON Tyfon Svenska AB - Sweden,SE > >> 185.57.8.0/22 AS19790 HOSTNET Hostnet B.V.,NL > >> 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO > >> 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A.,EC > >> 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR > >> 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, > Inc,US > >> 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US > >> 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US > >> 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US > >> 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US > >> 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US > >> 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA > >> 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US > >> 192.101.70.0/24 AS701 UUNET - MCI Communications Services, > Inc. d/b/a Verizon Business,US > >> 192.101.71.0/24 AS701 UUNET - MCI Communications Services, > Inc. d/b/a Verizon Business,US > >> 192.101.72.0/24 AS702 UUNET - MCI Communications Services, > Inc. d/b/a Verizon Business,US > >> 192.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec > Communications, > Inc.,US > >> 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines > Deutschen Forschungsnetzes e.V.,DE > >> 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, > Inc.,US > >> 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter > eSecurity,US > >> 192.154.32.0/19 AS81 NCREN - MCNC,US > >> 192.154.64.0/19 AS81 NCREN - MCNC,US > >> 192.166.32.0/20 AS702 UUNET - MCI Communications Services, > Inc. d/b/a Verizon Business,US > >> 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network > Information Center,US > >> 192.241.20.0/24 AS7381 SUNGARDRS - SunGard Availability > Services LP,US > >> 192.241.21.0/24 AS7381 SUNGARDRS - SunGard Availability > Services LP,US > >> 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability > Services LP,US > >> 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, > Inc.,US > >> 193.9.59.0/24 AS1257 TELE2,SE > >> 193.16.106.0/24 AS31539 -Reserved AS-,ZZ > >> 193.16.145.0/24 AS31392 -Reserved AS-,ZZ > >> 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon > Ab,FI > >> 193.22.224.0/20 AS3322 -Reserved AS-,ZZ > >> 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services > VOF,BE > >> 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB > >> 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE > >> 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB > >> 193.84.187.0/24 AS16276 OVH OVH SAS,FR > >> 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks > Ltd,GB > >> 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO > >> 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en > Internet S.A.,ES > >> 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO > >> 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO > >> 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & > Connectivity GmbH,DE > >> 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, > Inc.,US > >> 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication > GmbH,AT > >> 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications > Company,JO > >> 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 193.201.112.0/23 AS12964 DBMG-DE Dr. Buelow & Masiak GmbH,DE > >> 193.201.244.0/24 AS702 UUNET - MCI Communications Services, > Inc. d/b/a Verizon Business,US > >> 193.201.245.0/24 AS702 UUNET - MCI Communications Services, > Inc. d/b/a Verizon Business,US > >> 193.201.246.0/24 AS702 UUNET - MCI Communications Services, > Inc. d/b/a Verizon Business,US > >> 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom > International Ltd,GB > >> 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom > International Ltd,GB > >> 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication > GmbH,AT > >> 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 193.243.166.0/24 AS44093 -Reserved AS-,ZZ > >> 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA > >> 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA > >> 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE > >> 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE > >> 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE > >> 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB > >> 194.39.78.0/23 AS702 UUNET - MCI Communications Services, > Inc. d/b/a Verizon Business,US > >> 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE > >> 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB > >> 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 194.69.203.0/24 AS5089 NTL Virgin Media Limited,GB > >> 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE > >> 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech Passport Ltd > SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO > >> 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 194.99.67.0/24 AS9083 CARPENET carpeNet Information > Technologies GmbH,DE > >> 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 194.126.219.0/24 AS34545 -Reserved AS-,ZZ > >> 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR > >> 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE > >> 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE > >> 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information > Technology GmbH,DE > >> 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA > >> 194.213.8.0/24 AS42845 BRETAGNETELECOM BRETAGNE TELECOM > SAS,FR > >> 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO > >> 195.39.252.0/23 AS29004 -Reserved AS-,ZZ > >> 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & > Connectivity GmbH,DE > >> 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO > >> 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 195.90.98.0/23 AS57511 OVALTECH-AS OvalTech Internet Ltd,GB > >> 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL,RO > >> 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE > >> 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE > >> 195.234.156.0/24 AS25028 -Reserved AS-,ZZ > >> 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 196.2.224.0/22 AS24863 LINKdotNET-AS,EG > >> 196.3.182.0/24 AS37004 -Reserved AS-,ZZ > >> 196.3.183.0/24 AS37004 -Reserved AS-,ZZ > >> 196.13.201.0/24 AS2018 TENET-1,ZA > >> 196.13.202.0/24 AS2018 TENET-1,ZA > >> 196.13.203.0/24 AS2018 TENET-1,ZA > >> 196.13.204.0/24 AS2018 TENET-1,ZA > >> 196.22.8.0/24 AS27822 Emerging Markets Communications de > Argentina S.R.L,AR > >> 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies > Satellites, Inc.,US > >> 196.45.0.0/21 AS26625 -Reserved AS-,ZZ > >> 196.45.10.0/24 AS26625 -Reserved AS-,ZZ > >> 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, > Inc.,US > >> 198.72.78.0/23 AS3967 -Reserved AS-,ZZ > >> 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan > Energy,US > >> 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan > Energy,US > >> 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet > Services,US > >> 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet > Services,US > >> 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet > Services,US > >> 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network > Information Center,US > >> 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network > Information Center,US > >> 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network > Information Center,US > >> 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network > Information Center,US > >> 198.161.239.0/24 AS852 ASN852 - TELUS Communications > Inc.,CA > >> 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications > Co-operative Limited,CA > >> 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA > >> 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA > >> 198.168.0.0/16 AS701 UUNET - MCI Communications Services, > Inc. d/b/a Verizon Business,US > >> 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & > Gold Inc.,US > >> 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & > Gold Inc.,US > >> 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & > Gold Inc.,US > >> 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & > Gold Inc.,US > >> 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange > Services,HK > >> 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter > Communications,US > >> 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter > Communications,US > >> 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter > Communications,US > >> 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter > Communications,US > >> 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter > Communications,US > >> 199.30.138.0/24 AS23319 -Reserved AS-,ZZ > >> 199.30.139.0/24 AS23319 -Reserved AS-,ZZ > >> 199.30.143.0/24 AS8100 IPTELLIGENT - IPTelligent LLC,US > >> 199.68.72.0/24 AS174 COGENT-174 - Cogent > Communications,US > >> 199.85.9.0/24 AS852 ASN852 - TELUS Communications > Inc.,CA > >> 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality > Investment > Properties Sacramento, LLC,US > >> 199.116.200.0/21 AS22830 -Reserved AS-,ZZ > >> 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - > Mediacom Communications Corp,US > >> 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network > Information Center,US > >> 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network > Information Center,US > >> 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US > >> 200.58.248.0/21 AS27849 > >> 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., > Ltd.,KR > >> 202.9.40.0/24 AS56194 > >> 202.9.41.0/24 AS56194 > >> 202.9.42.0/24 AS56194 > >> 202.9.43.0/24 AS56194 > >> 202.9.44.0/24 AS56194 > >> 202.9.45.0/24 AS56194 > >> 202.9.46.0/24 AS56194 > >> 202.9.47.0/24 AS56194 > >> 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom > International CPC Limited,HK > >> 202.58.113.0/24 AS19161 -Reserved AS-,ZZ > >> 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network > China169 Beijing Province Network,CN > >> 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG > >> 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN > >> 203.142.219.0/24 AS45149 > >> 203.189.116.0/22 AS45606 > >> 203.189.116.0/24 AS45606 > >> 203.189.117.0/24 AS45606 > >> 203.189.118.0/24 AS45606 > >> 203.189.119.0/24 AS45606 > >> 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, > Inc.,US > >> 204.10.94.0/23 AS30097 NUWAVE - NuWave,US > >> 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net > LLC,US > >> 204.16.96.0/24 AS19972 -Reserved AS-,ZZ > >> 204.16.97.0/24 AS19972 -Reserved AS-,ZZ > >> 204.16.98.0/24 AS19972 -Reserved AS-,ZZ > >> 204.16.99.0/24 AS19972 -Reserved AS-,ZZ > >> 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James > Financial, Inc.,US > >> 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US > >> 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB > >> 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus > Telecommunications Canada Inc.,CA > >> 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US > >> 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp.,CA > >> 205.211.160.0/24 AS30045 UHN-ASN - University Health > Network,CA > >> 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US > >> 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a > NetLabs LLC Company,US > >> 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US > >> 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US > >> 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US > >> 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US > >> 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US > >> 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US > >> 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US > >> 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US > >> 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM > >> 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM > >> 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM > >> 208.67.132.0/22 AS701 UUNET - MCI Communications Services, > Inc. d/b/a Verizon Business,US > >> 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US > >> 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, > Inc,US > >> 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, > Inc,US > >> 208.75.152.0/21 AS32146 -Reserved AS-,ZZ > >> 208.76.20.0/24 AS31812 -Reserved AS-,ZZ > >> 208.76.21.0/24 AS31812 -Reserved AS-,ZZ > >> 208.77.164.0/24 AS22659 -Reserved AS-,ZZ > >> 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US > >> 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US > >> 208.84.232.0/24 AS33131 -Reserved AS-,ZZ > >> 208.84.234.0/24 AS33131 -Reserved AS-,ZZ > >> 208.84.237.0/24 AS33131 -Reserved AS-,ZZ > >> 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, > L.L.C.,US > >> 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US > >> 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, > Inc,US > >> 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications > Company, LLC,US > >> 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS > CORP.,US > >> 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US > >> 209.234.112.0/23 AS32252 -Reserved AS-,ZZ > >> 209.234.114.0/23 AS32252 -Reserved AS-,ZZ > >> 209.234.116.0/24 AS32252 -Reserved AS-,ZZ > >> 209.234.117.0/24 AS32252 -Reserved AS-,ZZ > >> 209.234.118.0/24 AS32252 -Reserved AS-,ZZ > >> 209.234.119.0/24 AS32252 -Reserved AS-,ZZ > >> 209.234.120.0/24 AS32252 -Reserved AS-,ZZ > >> 209.234.121.0/24 AS32252 -Reserved AS-,ZZ > >> 209.234.122.0/24 AS32252 -Reserved AS-,ZZ > >> 212.119.32.0/19 AS12550 -Reserved AS-,ZZ > >> 213.184.64.0/24 AS13071 -Reserved AS-,ZZ > >> 213.184.65.0/24 AS13071 -Reserved AS-,ZZ > >> 213.184.66.0/24 AS13071 -Reserved AS-,ZZ > >> 213.184.67.0/24 AS13071 -Reserved AS-,ZZ > >> 213.184.68.0/24 AS13071 -Reserved AS-,ZZ > >> 213.184.69.0/24 AS13071 -Reserved AS-,ZZ > >> 213.184.70.0/24 AS13071 -Reserved AS-,ZZ > >> 213.184.71.0/24 AS13071 -Reserved AS-,ZZ > >> 213.184.72.0/24 AS13071 -Reserved AS-,ZZ > >> 213.184.73.0/24 AS13071 -Reserved AS-,ZZ > >> 213.184.74.0/24 AS13071 -Reserved AS-,ZZ > >> 213.184.75.0/24 AS13071 -Reserved AS-,ZZ > >> 213.184.76.0/24 AS13071 -Reserved AS-,ZZ > >> 213.184.77.0/24 AS13071 -Reserved AS-,ZZ > >> 213.184.78.0/24 AS13071 -Reserved AS-,ZZ > >> 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US > >> 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, > LLC,US > >> 216.24.176.0/20 AS19401 -Reserved AS-,ZZ > >> 216.24.188.0/24 AS19401 -Reserved AS-,ZZ > >> 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL > WEST > COMMUNICATIONS LLC,US > >> 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox > Communications Inc.,US > >> 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks > Inc.,US > >> 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks > Inc.,US > >> 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks > Inc.,US > >> 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks > Inc.,US > >> 216.203.80.0/20 AS27021 -Reserved AS-,ZZ > >> 216.203.80.0/21 AS27021 -Reserved AS-,ZZ > >> 216.203.87.0/24 AS27021 -Reserved AS-,ZZ > >> 216.203.88.0/21 AS27021 -Reserved AS-,ZZ > >> 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc.,US > >> 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN > DRIVING > RECORDS, INC.,US > >> > >> > >> 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 > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4570 / Virus Database: 3931/7443 - Release Date: 05/05/14 > > From webbax at webbax.se Sat May 10 09:24:30 2014 From: webbax at webbax.se (Peter Persson) Date: Sat, 10 May 2014 11:24:30 +0200 Subject: Odd syslog-ng problem Message-ID: Hey, I got a weird problem with my syslog-ng setup, im logging from alot of cisco machines and that works great. The problem is that when i "pass" this further to a shell program, some lines disapere. My destination looks like this destination hosts { file("/var/log/ciscorouters/$HOST.log" owner(root) group(root) perm(0600) dir_perm(0700) create_dirs(yes)); program("/scripts/irc/syslog_wrapper_new.sh" template(t_irctempl)); }; The "/var/log/ciscorouters/$HOST.log" writes correct, but the data thats putted trough to "/scripts/irc/syslog_wrapper_new.sh" only get the first line, if it gets flooded (like 5 rows per second). Do anyone of you have any idea of what might be the problem? Regards, Peter From ikiris at gmail.com Sat May 10 15:17:58 2014 From: ikiris at gmail.com (Blake Dunlap) Date: Sat, 10 May 2014 10:17:58 -0500 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> Message-ID: This is a lot of hand waving and self justification to attempt to validate the practice of [Access Network] trying to charge 3rd party entities to deliver the content that [Access Network]'s paying customers have requested over the service they already pay for, instead of [Access Network] having to themselves pay for the bandwidth because they know their customers can't leave them, and they know they have a big enough market presence that they can rent seek with impunity. Why pay for transit connectivity expansion, when it financially benefits you to instead let the links run over full, and charge the world individually for uncongested access to your captive customers? -Blake -Blake -Blake On Sat, May 10, 2014 at 10:04 AM, Rick Astley wrote: > That was an interesting read but it's not the whole story. Skip to the > TL;DR if you'd like but I'll attempt to explain what happened. What he > isn't saying is the roles of the companies involved have changed over the > last 10 years. Mostly gone are the days that content providers and access > networks each just gave a middleman/transit provider money to reach each > other. "Content provider" has expanded to become "content delivery network" > and "access network" has expanded their role to offer transit as well. If > these networks have a large amount of traffic between them and are able to > reach each other in multiple locations nationally what is the technical > reason a 3rd party transit network is required instead of a direct peering > relationship? From a purely technical perspective content and access at > that scale can peer directly cutting out the middle man. > > The reality is an increasingly directly peered Internet doesn't sit well if > you are in the business of being the middle man. Now if you will, why do > transit companies themselves charge content companies to deliver bits? How > is it fair to be in the business of charging companies to receive their > bits and hand them to a settlement free peer on the hook to deliver them, > but not fair for content to just bypass the transit company and enter a > paid peering agreement with the company delivering the bits? In this case > paid peering is mutually beneficial to both companies involved and is > typically cheaper for the content company than it would cost to send that > traffic over transit. > > What we have is a major shift in the market over the last 10 or so years. > So why are these large nationally connected "access" networks charging > Level 3 for ports? That's the elephant in the room here and to understand > that you have to go back to where (to my knowledge) this dispute first went > public. The most comprehensive description I have seen to date is the > following Youtube video: https://www.youtube.com/watch?v=tR1sLLOYxnY > > I recommend the video before continuing. "Level 3" is really both Level 3 > transit and Level 3 CDN. Level 3 has already had a long standing precedent > of justifying the right of an ISP to charge for content delivery. So what > happens when Level 3 greatly expands their content delivery business and > sends traffic to other ISP's over settlement free ports? The large access > networks say "hey, content delivery is a billable service, you should know" > and they ask Level 3 CDN for compensation. The middleman networks protest > and say "Charging for content delivery is only OK if we do it, but not when > you do it!" and their justification for this claim is made on the basis > that unlike access networks they a) Have a large network and b) send a full > table of prefixes. > > So lets look at the first claim. Are the transit networks large? Yes, but > especially in the case of North American traffic destined for North America > they are typically smaller overall than the largest access networks who > arguably have the lions share of equipment tasked with delivering the bits > beyond just the colo. > The 2nd claim is mostly a strawman and this is why. Middlemen still carry > traffic not destined to directly connected peers but how they bill for it > is largely based on volume of traffic, not the number of prefixes > exchanged. The big content providers and the big access networks make up a > majority of the traffic on the Internet even if they don't make up a > majority of the prefixes. > > TL;DR So the reason the ports are maxed out is the market has changed, > access networks have attempted to change peering agreements to match the > existing market conditions but the middleman networks are arguing they > should be exempt from the long standing tradition of charging for content > delivery they themselves helped to establish. Some middleman networks have > responded by refusing payment to access networks for delivery and as a > result, the paths have not been upgraded and remain congested. > > End of TL;DR > > The next part is (even) more opinion than fact so you are forgiven if you > stop here. My opinion is this is a peering dispute more than something > that should fall under net neutrality. If content companies sent letters to > "middlmen" that said "In your statements to the public you made the case > that content delivery to ISP's should be settlement free so we have decided > to take your offer and refuse any further payment to you from here forward" > how would they handle it? Likely those companies would not only find > themselves congested but depeered. > > A bunch of people say charging at both ends is double dipping but really > modern access networks are now at least partly filling the role of transit > as well as last mile delivery. Where "content" "transit" and "access" all > have a presence in the same colo, paying more money to send traffic through > transit first instead of just directly to access because of some dated > definition of what the roles of those companies are supposed to be doesn't > make sense to me. Hijacking NN to attempt to bring litigation into the > matter to protect an old business model from a changing market makes even > less sense. Seeing Level 3 publish half truths in what looks like an > attempt to mislead the public on the matter is disappointing. I would > expect it from maybe Cogent but I have higher expectations of Level 3. > > Broadband providers obviously aren't without some blame in the matter > either. One of them is allowing customer satisfaction to be so low that > they are easy targets for misinformation as most the comments I have seen > on the matter to date are more emotional than rational. They have other > mistakes too but for the purpose of keeping this brief and because some of > them have been heavily documented elsewhere I'll save them for another day. > > > On Thu, May 8, 2014 at 1:18 PM, =JeffH wrote: > >> Observations of an Internet Middleman (Level3) >> http://blog.level3.com/global-connectivity/observations- >> internet-middleman/ >> >> See also... >> >> Level 3 accuses five unnamed US ISPs of abusing their market power in >> peering >> http://gigaom.com/2014/05/05/level-3-accuses-five-unnamed- >> us-isps-of-abusing-their-market-power-in-peering/ >> >> "... >> I’d love to see Cogent, Google and other providers release their data >> next, so even if the FCC doesn’t want to pursue this, a growing cry of >> consumer outrage could push the agency to do something about a very real >> and difficult problem that’s crippling access to video content on 5 U.S. >> broadband networks. Level 3 didn’t name names, but based on the deals >> Netflix has signed and the complaints it has made about AT&T, I’m confident >> that AT&T, Verizon and Comcast are among the five. " >> >> >> =JeffH >> >> >> >> From patrick at ianai.net Sat May 10 18:42:53 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 10 May 2014 14:42:53 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> Message-ID: <05F6EA01-711E-4EE2-AC84-3F0A107ED849@ianai.net> Nice discussion about history & motivations. Not completely correct, but it's always fun to argue over history, and over motivations, since both are open to intepretation. Personally, I am interested in the future, and specifically in market-driven solutions to our problems. Call me a capitalist if you like, but I believe in a functioning market, we can get a very good approximation of "fair". If Company A and Company B have a mutual customer, and that customer needs both companies to perform a task, the market will find a way to make those two companies work together. Either that, or the customer will replace A or B, whichever the customer feels is underperforming, with Company C. We have that situation today. Streaming Company wants to send End User of Broadband Company some content. If Streaming Company sucks - not enough titles, lousy customer service, high price, poor performance, etc., etc. - End User is free to select Streaming Company 2. And contrary to popular belief, there are plenty of "Streaming Company 2s" available. Besides NF, there is Hulu, Amazon, iTunes, iPlayer, etc. They might have different models, but they all allow you to access streaming content, so choice is available. And here is where we get into the problem. Should End User believe Broadband Company sucks, they frequently cannot choose Broadband Company 2. I know I cannot, my choices are Comcast @ 100 Mbps or Verizon at 1.1 (yes, one-point-one) Mbps. So when Streaming Company sucks, but they suck because Broadband company is doing something I do not like, I cannot "vote with my wallet" and pick Broadband Company 2. I have no choice but to pick Streaming Company 2, even if I think the problem is Broadband Company's fault. (To be clear, I am not a NF subscriber - any more - and so this is not a NF/CC thing, I'm just talking generalities.) Put more succinctly, there is no functioning market. therefore there cannot be a market-based solution. Personally, I view that as about the most Un-American, Un-Capitalistic thing there is. Lots of people have suggested a simple, if very difficult, fix to this problem. Make the underlying physical infrastructure a regulated monopoly, i.e. a Utility. Then allow anyone to run services over that physical infrastructure. This is not pipe dream. The UK does it today. People there pick ISPs based on service, price, features, etc., not on "who paid off my local PUC". And before anyone brings up the whole "the UK is more dense than the US", I preemptively call BS. There is more choice, faster speeds, and lower prices in the middle of no-where UK than downtown manhattan. Please just leave that argument where it belongs, in the dung heap. Why can we not do something similar in the US? because the companies who own the lines have enough money to pay enough lobbyists to avoid even the promises they do make. (If anyone on this list is un-aware of things like the telcos promising ubiquitous high-speed BB years ago and never delivering, but never giving back their tax breaks or monopoly positions, you should be ashamed of yourselves.) But hey, a guy can dream, right? In the mean time, let's stop pretending that 'oh, L3 paid CC so they must be best friends'. L3 paid because They Had No Choice, and maybe because they see some long-term strategic benefit (e.g. they can charge others more later). This is not a functioning market. This is a few players with Market Power charging Rents, which any first year econ major will explain is a _very_very_very_ bad place for the market to be. -- TTFN, patrick From j at arpa.com Sat May 10 18:49:16 2014 From: j at arpa.com (jamie rishaw) Date: Sat, 10 May 2014 13:49:16 -0500 Subject: Odd syslog-ng problem In-Reply-To: References: Message-ID: Off topic. The issue is with the daemon, not your devices. https://lists.balabit.hu/mailman/listinfo/syslog-ng On Sat, May 10, 2014 at 4:24 AM, Peter Persson wrote: > Hey, > > I got a weird problem with my syslog-ng setup, im logging from alot of > cisco machines and that works great. > The problem is that when i "pass" this further to a shell program, some > lines disapere. > > My destination looks like this > destination hosts { > file("/var/log/ciscorouters/$HOST.log" > owner(root) group(root) perm(0600) dir_perm(0700) create_dirs(yes)); > program("/scripts/irc/syslog_wrapper_new.sh" template(t_irctempl)); > }; > The "/var/log/ciscorouters/$HOST.log" writes correct, but the data thats > putted trough to "/scripts/irc/syslog_wrapper_new.sh" only get the first > line, if it gets flooded (like 5 rows per second). > > Do anyone of you have any idea of what might be the problem? > > Regards, > Peter -- jamie rishaw // .com.arpa at j <- reverse it. ish. "...let's consider this world like a family and care about each other..." -Malala Yousafzai From me at anuragbhatia.com Sat May 10 19:15:24 2014 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sun, 11 May 2014 00:45:24 +0530 Subject: Odd syslog-ng problem In-Reply-To: References: Message-ID: <9EE03B3E-A103-4F98-89E8-67E87A2A9048@anuragbhatia.com> Another off topic (question) - what kind of fronted UI you use with syslog-ng? I see log analyser based on PHP is common. In my tests it worked fine but it’s major issue I saw was that I couldn’t sort all logs based on individual hosts/devices. What kind of open source web UI everyone is using, just wondering? Thanks. On 11-May-2014, at 12:19 am, jamie rishaw wrote: > Off topic. > The issue is with the daemon, not your devices. > > https://lists.balabit.hu/mailman/listinfo/syslog-ng > > > On Sat, May 10, 2014 at 4:24 AM, Peter Persson wrote: >> Hey, >> >> I got a weird problem with my syslog-ng setup, im logging from alot of >> cisco machines and that works great. >> The problem is that when i "pass" this further to a shell program, some >> lines disapere. >> >> My destination looks like this >> destination hosts { >> file("/var/log/ciscorouters/$HOST.log" >> owner(root) group(root) perm(0600) dir_perm(0700) create_dirs(yes)); >> program("/scripts/irc/syslog_wrapper_new.sh" template(t_irctempl)); >> }; >> The "/var/log/ciscorouters/$HOST.log" writes correct, but the data thats >> putted trough to "/scripts/irc/syslog_wrapper_new.sh" only get the first >> line, if it gets flooded (like 5 rows per second). >> >> Do anyone of you have any idea of what might be the problem? >> >> Regards, >> Peter > > > > -- > jamie rishaw // .com.arpa at j <- reverse it. ish. > > "...let's consider this world like a family and care about each other..." > -Malala Yousafzai -- Anurag Bhatia anuragbhatia.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 881 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bedard.phil at gmail.com Sat May 10 19:40:36 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Sat, 10 May 2014 15:40:36 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: <05F6EA01-711E-4EE2-AC84-3F0A107ED849@ianai.net> References: <536BBC62.4070805@KingsMountain.com> <05F6EA01-711E-4EE2-AC84-3F0A107ED849@ianai.net> Message-ID: The UK only does this with BT OpenReach since they were the telco monopoly that originated as a government entity. Virgin Media (well all the people who now form Virgin Media) built and operates their own fiber/HFC access networks, the same as MSOs in the US, and does not offer wholesale access and isn't treated as a utility. There are areas in the UK Virgin serves where the wholesale network does not, and areas where they offer much faster speeds, which is the same exact scenario as we have here. Just because Verizon isn't using VDSL/VDSL2 or hasn't brought FIOS to your area isn't Comcast's fault. The newer OpenReach wholesale fiber network is also partially subsidized by the government. I'm all for wholesale broadband access, but I wouldn't paint the situation in the UK as vastly different than here. We had the same thing the UK does now 10+ years ago with the CLECs and DSL providers like Covad, etc. but the regulations changed and dried up access. TWC did wholesale access during the same time; Earthlink Cable had quite a few customers back in the day through the arrangement, but it was complicated and ultimately your Internet pipe all still went through TWC. Phil On 5/10/14, 2:42 PM, "Patrick W. Gilmore" wrote: >Nice discussion about history & motivations. Not completely correct, but >it's always fun to argue over history, and over motivations, since both >are open to intepretation. > >Personally, I am interested in the future, and specifically in >market-driven solutions to our problems. Call me a capitalist if you >like, but I believe in a functioning market, we can get a very good >approximation of "fair". > >If Company A and Company B have a mutual customer, and that customer >needs both companies to perform a task, the market will find a way to >make those two companies work together. Either that, or the customer will >replace A or B, whichever the customer feels is underperforming, with >Company C. > >We have that situation today. Streaming Company wants to send End User of >Broadband Company some content. If Streaming Company sucks - not enough >titles, lousy customer service, high price, poor performance, etc., etc. >- End User is free to select Streaming Company 2. And contrary to popular >belief, there are plenty of "Streaming Company 2s" available. Besides NF, >there is Hulu, Amazon, iTunes, iPlayer, etc. They might have different >models, but they all allow you to access streaming content, so choice is >available. > >And here is where we get into the problem. Should End User believe >Broadband Company sucks, they frequently cannot choose Broadband Company >2. I know I cannot, my choices are Comcast @ 100 Mbps or Verizon at 1.1 >(yes, one-point-one) Mbps. So when Streaming Company sucks, but they suck >because Broadband company is doing something I do not like, I cannot >"vote with my wallet" and pick Broadband Company 2. I have no choice but >to pick Streaming Company 2, even if I think the problem is Broadband >Company's fault. (To be clear, I am not a NF subscriber - any more - and >so this is not a NF/CC thing, I'm just talking generalities.) > >Put more succinctly, there is no functioning market. therefore there >cannot be a market-based solution. > >Personally, I view that as about the most Un-American, Un-Capitalistic >thing there is. > >Lots of people have suggested a simple, if very difficult, fix to this >problem. Make the underlying physical infrastructure a regulated >monopoly, i.e. a Utility. Then allow anyone to run services over that >physical infrastructure. > >This is not pipe dream. The UK does it today. People there pick ISPs >based on service, price, features, etc., not on "who paid off my local >PUC". > >And before anyone brings up the whole "the UK is more dense than the US", >I preemptively call BS. There is more choice, faster speeds, and lower >prices in the middle of no-where UK than downtown manhattan. Please just >leave that argument where it belongs, in the dung heap. > >Why can we not do something similar in the US? because the companies who >own the lines have enough money to pay enough lobbyists to avoid even the >promises they do make. (If anyone on this list is un-aware of things like >the telcos promising ubiquitous high-speed BB years ago and never >delivering, but never giving back their tax breaks or monopoly positions, >you should be ashamed of yourselves.) > >But hey, a guy can dream, right? > >In the mean time, let's stop pretending that 'oh, L3 paid CC so they must >be best friends'. L3 paid because They Had No Choice, and maybe because >they see some long-term strategic benefit (e.g. they can charge others >more later). > >This is not a functioning market. This is a few players with Market Power >charging Rents, which any first year econ major will explain is a >_very_very_very_ bad place for the market to be. > >-- >TTFN, >patrick > From bzs at world.std.com Sat May 10 19:44:59 2014 From: bzs at world.std.com (Barry Shein) Date: Sat, 10 May 2014 15:44:59 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: <05F6EA01-711E-4EE2-AC84-3F0A107ED849@ianai.net> References: <536BBC62.4070805@KingsMountain.com> <05F6EA01-711E-4EE2-AC84-3F0A107ED849@ianai.net> Message-ID: <21358.33211.262136.642903@world.std.com> I agree with your summary. -- -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 randy at psg.com Sat May 10 20:34:11 2014 From: randy at psg.com (Randy Bush) Date: Sat, 10 May 2014 22:34:11 +0200 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> Message-ID: imiho think vi hart has it down simply and understandable by a lay person. . my friends in last mile providers disagree. i take that as a good sign. randy From pauldotwall at gmail.com Sat May 10 21:53:44 2014 From: pauldotwall at gmail.com (Paul WALL) Date: Sat, 10 May 2014 21:53:44 +0000 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> Message-ID: It is important to consider bias and factual accuracy of the material. George Ou was working for Comcast and AT&T as a lobbyist at the time he produced the Youtube video. Drive Slow, Paul Wall On Sat, May 10, 2014 at 3:04 PM, Rick Astley wrote: > That was an interesting read but it's not the whole story. Skip to the > TL;DR if you'd like but I'll attempt to explain what happened. What he > isn't saying is the roles of the companies involved have changed over the > last 10 years. Mostly gone are the days that content providers and access > networks each just gave a middleman/transit provider money to reach each > other. "Content provider" has expanded to become "content delivery network" > and "access network" has expanded their role to offer transit as well. If > these networks have a large amount of traffic between them and are able to > reach each other in multiple locations nationally what is the technical > reason a 3rd party transit network is required instead of a direct peering > relationship? From a purely technical perspective content and access at > that scale can peer directly cutting out the middle man. > > The reality is an increasingly directly peered Internet doesn't sit well if > you are in the business of being the middle man. Now if you will, why do > transit companies themselves charge content companies to deliver bits? How > is it fair to be in the business of charging companies to receive their > bits and hand them to a settlement free peer on the hook to deliver them, > but not fair for content to just bypass the transit company and enter a > paid peering agreement with the company delivering the bits? In this case > paid peering is mutually beneficial to both companies involved and is > typically cheaper for the content company than it would cost to send that > traffic over transit. > > What we have is a major shift in the market over the last 10 or so years. > So why are these large nationally connected "access" networks charging > Level 3 for ports? That's the elephant in the room here and to understand > that you have to go back to where (to my knowledge) this dispute first went > public. The most comprehensive description I have seen to date is the > following Youtube video: https://www.youtube.com/watch?v=tR1sLLOYxnY > > I recommend the video before continuing. "Level 3" is really both Level 3 > transit and Level 3 CDN. Level 3 has already had a long standing precedent > of justifying the right of an ISP to charge for content delivery. So what > happens when Level 3 greatly expands their content delivery business and > sends traffic to other ISP's over settlement free ports? The large access > networks say "hey, content delivery is a billable service, you should know" > and they ask Level 3 CDN for compensation. The middleman networks protest > and say "Charging for content delivery is only OK if we do it, but not when > you do it!" and their justification for this claim is made on the basis > that unlike access networks they a) Have a large network and b) send a full > table of prefixes. > > So lets look at the first claim. Are the transit networks large? Yes, but > especially in the case of North American traffic destined for North America > they are typically smaller overall than the largest access networks who > arguably have the lions share of equipment tasked with delivering the bits > beyond just the colo. > The 2nd claim is mostly a strawman and this is why. Middlemen still carry > traffic not destined to directly connected peers but how they bill for it > is largely based on volume of traffic, not the number of prefixes > exchanged. The big content providers and the big access networks make up a > majority of the traffic on the Internet even if they don't make up a > majority of the prefixes. > > TL;DR So the reason the ports are maxed out is the market has changed, > access networks have attempted to change peering agreements to match the > existing market conditions but the middleman networks are arguing they > should be exempt from the long standing tradition of charging for content > delivery they themselves helped to establish. Some middleman networks have > responded by refusing payment to access networks for delivery and as a > result, the paths have not been upgraded and remain congested. > > End of TL;DR > > The next part is (even) more opinion than fact so you are forgiven if you > stop here. My opinion is this is a peering dispute more than something > that should fall under net neutrality. If content companies sent letters to > "middlmen" that said "In your statements to the public you made the case > that content delivery to ISP's should be settlement free so we have decided > to take your offer and refuse any further payment to you from here forward" > how would they handle it? Likely those companies would not only find > themselves congested but depeered. > > A bunch of people say charging at both ends is double dipping but really > modern access networks are now at least partly filling the role of transit > as well as last mile delivery. Where "content" "transit" and "access" all > have a presence in the same colo, paying more money to send traffic through > transit first instead of just directly to access because of some dated > definition of what the roles of those companies are supposed to be doesn't > make sense to me. Hijacking NN to attempt to bring litigation into the > matter to protect an old business model from a changing market makes even > less sense. Seeing Level 3 publish half truths in what looks like an > attempt to mislead the public on the matter is disappointing. I would > expect it from maybe Cogent but I have higher expectations of Level 3. > > Broadband providers obviously aren't without some blame in the matter > either. One of them is allowing customer satisfaction to be so low that > they are easy targets for misinformation as most the comments I have seen > on the matter to date are more emotional than rational. They have other > mistakes too but for the purpose of keeping this brief and because some of > them have been heavily documented elsewhere I'll save them for another day. > > > On Thu, May 8, 2014 at 1:18 PM, =JeffH wrote: > >> Observations of an Internet Middleman (Level3) >> http://blog.level3.com/global-connectivity/observations- >> internet-middleman/ >> >> See also... >> >> Level 3 accuses five unnamed US ISPs of abusing their market power in >> peering >> http://gigaom.com/2014/05/05/level-3-accuses-five-unnamed- >> us-isps-of-abusing-their-market-power-in-peering/ >> >> "... >> I’d love to see Cogent, Google and other providers release their data >> next, so even if the FCC doesn’t want to pursue this, a growing cry of >> consumer outrage could push the agency to do something about a very real >> and difficult problem that’s crippling access to video content on 5 U.S. >> broadband networks. Level 3 didn’t name names, but based on the deals >> Netflix has signed and the complaints it has made about AT&T, I’m confident >> that AT&T, Verizon and Comcast are among the five. " >> >> >> =JeffH >> >> >> >> From pauldotwall at gmail.com Sat May 10 21:56:53 2014 From: pauldotwall at gmail.com (Paul WALL) Date: Sat, 10 May 2014 21:56:53 +0000 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> Message-ID: The pertinent question is what time period Level 3 was looking at / averaging when writing the blog post. Even if Comcast and Level 3 are not congested right at this moment, they were most definitely congested several years following their landmark agreement. A better question would be why that is/was. Drive Slow, Paul Wall On Fri, May 9, 2014 at 12:27 PM, Livingood, Jason wrote: > Hi Jeff – I noticed the question posed here so thought I’d respond, perhaps at risk of stirring up a hornet’s nest given how long the last thread was. ;-) Anyway… there’s no congestion between Comcast and Level 3 connections, and we’re working collaboratively with Level 3. Given these facts, we have no reason to believe that Comcast is on their list. > > - Jason > Comcast > > On 5/8/14, 1:18 PM, "=JeffH" > wrote: > > Level 3 accuses five unnamed US ISPs of abusing their market power in peering > http://gigaom.com/2014/05/05/level-3-accuses-five-unnamed-us-isps-of-abusing-their-market-power-in-peering/ > > "...I’d love to see Cogent, Google and other providers release their data next, so even if the FCC doesn’t want to pursue this, a growing cry of consumer outrage could push the agency to do something about a very real and difficult problem that’s crippling access to video content on 5 U.S. broadband networks. Level 3 didn’t name names, but based on the deals Netflix has signed and the complaints it has made about AT&T, I’m confident that AT&T, Verizon and Comcast are among the five. " > > From ikiris at gmail.com Sat May 10 22:00:24 2014 From: ikiris at gmail.com (Blake Dunlap) Date: Sat, 10 May 2014 17:00:24 -0500 Subject: Odd syslog-ng problem In-Reply-To: <9EE03B3E-A103-4F98-89E8-67E87A2A9048@anuragbhatia.com> References: <9EE03B3E-A103-4F98-89E8-67E87A2A9048@anuragbhatia.com> Message-ID: I use kibana / elasticsearch -Blake On Sat, May 10, 2014 at 2:15 PM, Anurag Bhatia wrote: > Another off topic (question) - what kind of fronted UI you use with syslog-ng? I see log analyser based on PHP is common. In my tests it worked fine but it’s major issue I saw was that I couldn’t sort all logs based on individual hosts/devices. > > > What kind of open source web UI everyone is using, just wondering? > > > > > Thanks. > > > > On 11-May-2014, at 12:19 am, jamie rishaw wrote: > >> Off topic. >> The issue is with the daemon, not your devices. >> >> https://lists.balabit.hu/mailman/listinfo/syslog-ng >> >> >> On Sat, May 10, 2014 at 4:24 AM, Peter Persson wrote: >>> Hey, >>> >>> I got a weird problem with my syslog-ng setup, im logging from alot of >>> cisco machines and that works great. >>> The problem is that when i "pass" this further to a shell program, some >>> lines disapere. >>> >>> My destination looks like this >>> destination hosts { >>> file("/var/log/ciscorouters/$HOST.log" >>> owner(root) group(root) perm(0600) dir_perm(0700) create_dirs(yes)); >>> program("/scripts/irc/syslog_wrapper_new.sh" template(t_irctempl)); >>> }; >>> The "/var/log/ciscorouters/$HOST.log" writes correct, but the data thats >>> putted trough to "/scripts/irc/syslog_wrapper_new.sh" only get the first >>> line, if it gets flooded (like 5 rows per second). >>> >>> Do anyone of you have any idea of what might be the problem? >>> >>> Regards, >>> Peter >> >> >> >> -- >> jamie rishaw // .com.arpa at j <- reverse it. ish. >> >> "...let's consider this world like a family and care about each other..." >> -Malala Yousafzai > > > > > -- > Anurag Bhatia > anuragbhatia.com > From mike at conlen.org Sat May 10 22:14:13 2014 From: mike at conlen.org (Michael Conlen) Date: Sat, 10 May 2014 18:14:13 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: <05F6EA01-711E-4EE2-AC84-3F0A107ED849@ianai.net> References: <536BBC62.4070805@KingsMountain.com> <05F6EA01-711E-4EE2-AC84-3F0A107ED849@ianai.net> Message-ID: <98FA78E1-E968-40D6-977C-E9B23367ECD0@conlen.org> If we ignore why and how the few high speed options exist for a moment and accept that it's "the way it is," then it seems reasonable that the place to put regulation is on them. At the same time cutting out middlemen is generally good for everyone but the middlemen. My current opinion then is to let ISPs cut out the middlemen but ensure that services which don't pay fees get reasonable access; regulate peering and transit agreements (not just for access providers but across the board). ISPs should be responsible to keep their links congestion free and have fair and reasonable terms to connect to their networks. They can sell direct access to their network to anyone as long as they aren't selling QoS. Comcast and Verizon can sell direct access to content providers but they cannot degrade service as leverage in negotiations. A side effect would be that if peering agreements must be public and there are stated terms for various types of peering many of the silky peering games that get played and the silky peering disagreements that cause problems would be more difficult. We could finally answer the age old question, "is company X a 'tier 1'. " -- Mike > On May 10, 2014, at 14:42, "Patrick W. Gilmore" wrote: > > Nice discussion about history & motivations. Not completely correct, but it's always fun to argue over history, and over motivations, since both are open to intepretation. > > Personally, I am interested in the future, and specifically in market-driven solutions to our problems. Call me a capitalist if you like, but I believe in a functioning market, we can get a very good approximation of "fair". > > If Company A and Company B have a mutual customer, and that customer needs both companies to perform a task, the market will find a way to make those two companies work together. Either that, or the customer will replace A or B, whichever the customer feels is underperforming, with Company C. > > We have that situation today. Streaming Company wants to send End User of Broadband Company some content. If Streaming Company sucks - not enough titles, lousy customer service, high price, poor performance, etc., etc. - End User is free to select Streaming Company 2. And contrary to popular belief, there are plenty of "Streaming Company 2s" available. Besides NF, there is Hulu, Amazon, iTunes, iPlayer, etc. They might have different models, but they all allow you to access streaming content, so choice is available. > > And here is where we get into the problem. Should End User believe Broadband Company sucks, they frequently cannot choose Broadband Company 2. I know I cannot, my choices are Comcast @ 100 Mbps or Verizon at 1.1 (yes, one-point-one) Mbps. So when Streaming Company sucks, but they suck because Broadband company is doing something I do not like, I cannot "vote with my wallet" and pick Broadband Company 2. I have no choice but to pick Streaming Company 2, even if I think the problem is Broadband Company's fault. (To be clear, I am not a NF subscriber - any more - and so this is not a NF/CC thing, I'm just talking generalities.) > > Put more succinctly, there is no functioning market. therefore there cannot be a market-based solution. > > Personally, I view that as about the most Un-American, Un-Capitalistic thing there is. > > Lots of people have suggested a simple, if very difficult, fix to this problem. Make the underlying physical infrastructure a regulated monopoly, i.e. a Utility. Then allow anyone to run services over that physical infrastructure. > > This is not pipe dream. The UK does it today. People there pick ISPs based on service, price, features, etc., not on "who paid off my local PUC". > > And before anyone brings up the whole "the UK is more dense than the US", I preemptively call BS. There is more choice, faster speeds, and lower prices in the middle of no-where UK than downtown manhattan. Please just leave that argument where it belongs, in the dung heap. > > Why can we not do something similar in the US? because the companies who own the lines have enough money to pay enough lobbyists to avoid even the promises they do make. (If anyone on this list is un-aware of things like the telcos promising ubiquitous high-speed BB years ago and never delivering, but never giving back their tax breaks or monopoly positions, you should be ashamed of yourselves.) > > But hey, a guy can dream, right? > > In the mean time, let's stop pretending that 'oh, L3 paid CC so they must be best friends'. L3 paid because They Had No Choice, and maybe because they see some long-term strategic benefit (e.g. they can charge others more later). > > This is not a functioning market. This is a few players with Market Power charging Rents, which any first year econ major will explain is a _very_very_very_ bad place for the market to be. > > -- > TTFN, > patrick > From andrew.fried at gmail.com Sat May 10 22:31:43 2014 From: andrew.fried at gmail.com (Andrew Fried) Date: Sat, 10 May 2014 18:31:43 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <05F6EA01-711E-4EE2-AC84-3F0A107ED849@ianai.net> References: <536BBC62.4070805@KingsMountain.com> <05F6EA01-711E-4EE2-AC84-3F0A107ED849@ianai.net> Message-ID: <536EA8CF.2080803@gmail.com> ++1 Andrew Fried andrew.fried at gmail.com On 5/10/14, 2:42 PM, Patrick W. Gilmore wrote: > Nice discussion about history & motivations. Not completely correct, but it's always fun to argue over history, and over motivations, since both are open to intepretation. > > Personally, I am interested in the future, and specifically in market-driven solutions to our problems. Call me a capitalist if you like, but I believe in a functioning market, we can get a very good approximation of "fair". > > If Company A and Company B have a mutual customer, and that customer needs both companies to perform a task, the market will find a way to make those two companies work together. Either that, or the customer will replace A or B, whichever the customer feels is underperforming, with Company C. > > We have that situation today. Streaming Company wants to send End User of Broadband Company some content. If Streaming Company sucks - not enough titles, lousy customer service, high price, poor performance, etc., etc. - End User is free to select Streaming Company 2. And contrary to popular belief, there are plenty of "Streaming Company 2s" available. Besides NF, there is Hulu, Amazon, iTunes, iPlayer, etc. They might have different models, but they all allow you to access streaming content, so choice is available. > > And here is where we get into the problem. Should End User believe Broadband Company sucks, they frequently cannot choose Broadband Company 2. I know I cannot, my choices are Comcast @ 100 Mbps or Verizon at 1.1 (yes, one-point-one) Mbps. So when Streaming Company sucks, but they suck because Broadband company is doing something I do not like, I cannot "vote with my wallet" and pick Broadband Company 2. I have no choice but to pick Streaming Company 2, even if I think the problem is Broadband Company's fault. (To be clear, I am not a NF subscriber - any more - and so this is not a NF/CC thing, I'm just talking generalities.) > > Put more succinctly, there is no functioning market. therefore there cannot be a market-based solution. > > Personally, I view that as about the most Un-American, Un-Capitalistic thing there is. > > Lots of people have suggested a simple, if very difficult, fix to this problem. Make the underlying physical infrastructure a regulated monopoly, i.e. a Utility. Then allow anyone to run services over that physical infrastructure. > > This is not pipe dream. The UK does it today. People there pick ISPs based on service, price, features, etc., not on "who paid off my local PUC". > > And before anyone brings up the whole "the UK is more dense than the US", I preemptively call BS. There is more choice, faster speeds, and lower prices in the middle of no-where UK than downtown manhattan. Please just leave that argument where it belongs, in the dung heap. > > Why can we not do something similar in the US? because the companies who own the lines have enough money to pay enough lobbyists to avoid even the promises they do make. (If anyone on this list is un-aware of things like the telcos promising ubiquitous high-speed BB years ago and never delivering, but never giving back their tax breaks or monopoly positions, you should be ashamed of yourselves.) > > But hey, a guy can dream, right? > > In the mean time, let's stop pretending that 'oh, L3 paid CC so they must be best friends'. L3 paid because They Had No Choice, and maybe because they see some long-term strategic benefit (e.g. they can charge others more later). > > This is not a functioning market. This is a few players with Market Power charging Rents, which any first year econ major will explain is a _very_very_very_ bad place for the market to be. > From jfmezei_nanog at vaxination.ca Sat May 10 23:32:27 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sat, 10 May 2014 19:32:27 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> Message-ID: <536EB70B.60506@vaxination.ca> In these situations, I find it helps to mentally implement structural separation. So you have level3-Transit and Level3-CDN as separate companies. Netflix pays Level3-CDN to make content available locally in many cities. It is up to the ISP to find the most efficient way to connect to the Level3-CDN node(s). As a CDN, does Level3 offer free peering with ISPs who only have to pay for ports in a big switch ? ? Similarly, if there were Comcast-Transit and Comcast-ISP, and I purchase transit from Comcast-Transit, does it offer good connectivity around the world, or is it just a shell company that serves the Comcast-ISP ? From bzs at world.std.com Sun May 11 01:58:31 2014 From: bzs at world.std.com (Barry Shein) Date: Sat, 10 May 2014 21:58:31 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> Message-ID: <21358.55623.277608.645527@world.std.com> On May 10, 2014 at 22:34 randy at psg.com (Randy Bush) wrote: > imiho think vi hart has it down simply and understandable by a lay > person. . my > friends in last mile providers disagree. i take that as a good sign. Yeah, well, for extra credit integrate Akamai into that story. -- -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 at byoteki.com Sat May 10 17:41:40 2014 From: gary at byoteki.com (Gary Josack) Date: Sat, 10 May 2014 10:41:40 -0700 Subject: Odd syslog-ng problem In-Reply-To: References: Message-ID: It's hard to say without seeing the actual script. Is your script running as a daemon or are you counting on syslog-ng to start your program per message. If the latter, that's probably not the best strategy. On Sat, May 10, 2014 at 2:24 AM, Peter Persson wrote: > Hey, > > I got a weird problem with my syslog-ng setup, im logging from alot of > cisco machines and that works great. > The problem is that when i "pass" this further to a shell program, some > lines disapere. > > My destination looks like this > destination hosts { > file("/var/log/ciscorouters/$HOST.log" > owner(root) group(root) perm(0600) dir_perm(0700) create_dirs(yes)); > program("/scripts/irc/syslog_wrapper_new.sh" template(t_irctempl)); > }; > The "/var/log/ciscorouters/$HOST.log" writes correct, but the data thats > putted trough to "/scripts/irc/syslog_wrapper_new.sh" only get the first > line, if it gets flooded (like 5 rows per second). > > Do anyone of you have any idea of what might be the problem? > > Regards, > Peter > From jof at thejof.com Sun May 11 07:36:06 2014 From: jof at thejof.com (Jonathan Lassoff) Date: Sun, 11 May 2014 00:36:06 -0700 Subject: Odd syslog-ng problem In-Reply-To: References: Message-ID: Peter, it's a bit difficult to tell what's going on without seeing the rest of the syslog-ng configuration and your script's source code. However, a couple possibilities come to mind: - Your script is only reading one line at a time. syslog-ng starts a program() output persistently and expects that it can send multiple messages into its pipe to your script's stdin. - Messages are being buffered inside of syslog-ng. Check out the flush_lines() and flush_timeout() flags to syslog-ng's program() output. Find the right page for your version, but here's v3.3.: http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.3-guides/en/syslog-ng-ose-v3.3-guide-admin-en/html/reference_destination_program.html - Messages are being buffered in your shell or script. Maybe try some non-blocking IO with a smallish buffer to see data as it comes in before a whole line or block fills and flushes in. To Anurag's question about open source log management with a WebUI, I agree with Blake: logstash ingesting syslog and inputting it into elasticsearch makes for a great backend for Kibana. The logstash grok filter is great for pulling apart and indexing weird vendor-specific logging formats: http://logstash.net/docs/1.4.1/filters/grok Cheers, jof On Sat, May 10, 2014 at 2:24 AM, Peter Persson wrote: > Hey, > > I got a weird problem with my syslog-ng setup, im logging from alot of > cisco machines and that works great. > The problem is that when i "pass" this further to a shell program, some > lines disapere. > > My destination looks like this > destination hosts { > file("/var/log/ciscorouters/$HOST.log" > owner(root) group(root) perm(0600) dir_perm(0700) create_dirs(yes)); > program("/scripts/irc/syslog_wrapper_new.sh" template(t_irctempl)); > }; > The "/var/log/ciscorouters/$HOST.log" writes correct, but the data thats > putted trough to "/scripts/irc/syslog_wrapper_new.sh" only get the first > line, if it gets flooded (like 5 rows per second). > > Do anyone of you have any idea of what might be the problem? > > Regards, > Peter From owen at delong.com Sun May 11 17:11:57 2014 From: owen at delong.com (Owen DeLong) Date: Sun, 11 May 2014 10:11:57 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: <98FA78E1-E968-40D6-977C-E9B23367ECD0@conlen.org> References: <536BBC62.4070805@KingsMountain.com> <05F6EA01-711E-4EE2-AC84-3F0A107ED849@ianai.net> <98FA78E1-E968-40D6-977C-E9B23367ECD0@conlen.org> Message-ID: <0ED02CA1-12CE-4D69-9F3E-E4E7EA0F5678@delong.com> On May 10, 2014, at 3:14 PM, Michael Conlen wrote: > If we ignore why and how the few high speed options exist for a moment and accept that it's "the way it is," then it seems reasonable that the place to put regulation is on them. At the same time cutting out middlemen is generally good for everyone but the middlemen. > > My current opinion then is to let ISPs cut out the middlemen but ensure that services which don't pay fees get reasonable access; regulate peering and transit agreements (not just for access providers but across the board). ISPs should be responsible to keep their links congestion free and have fair and reasonable terms to connect to their networks. They can sell direct access to their network to anyone as long as they aren't selling QoS. > > Comcast and Verizon can sell direct access to content providers but they cannot degrade service as leverage in negotiations. > That set of regulations would be utterly impossible to meaningfully enforce because so much of it depends on subjective evaluation. The various law firms involved (Comcast, AT&T, Verizon, et al.) would have a field day playing in the gray areas of any such set of rules, most likely creating a situation of exactly the opposite of what is intended. > A side effect would be that if peering agreements must be public and there are stated terms for various types of peering many of the silky peering games that get played and the silky peering disagreements that cause problems would be more difficult. More likely, costs would go up for everyone for everything and the game wouldn’t change by all that much. > We could finally answer the age old question, "is company X a 'tier 1'. “ Since nobody has a real definition for “tier 1”, it’s a fairly meaningless question to begin with. (Yes, I am familiar with the alleged “does not pay for transit” definition, but I’ll point out that a completely disconnected network doesn’t pay for transit, either, but I doubt anyone would think they are a tier 1.) Owen > > -- > Mike > > >> On May 10, 2014, at 14:42, "Patrick W. Gilmore" wrote: >> >> Nice discussion about history & motivations. Not completely correct, but it's always fun to argue over history, and over motivations, since both are open to intepretation. >> >> Personally, I am interested in the future, and specifically in market-driven solutions to our problems. Call me a capitalist if you like, but I believe in a functioning market, we can get a very good approximation of "fair". >> >> If Company A and Company B have a mutual customer, and that customer needs both companies to perform a task, the market will find a way to make those two companies work together. Either that, or the customer will replace A or B, whichever the customer feels is underperforming, with Company C. >> >> We have that situation today. Streaming Company wants to send End User of Broadband Company some content. If Streaming Company sucks - not enough titles, lousy customer service, high price, poor performance, etc., etc. - End User is free to select Streaming Company 2. And contrary to popular belief, there are plenty of "Streaming Company 2s" available. Besides NF, there is Hulu, Amazon, iTunes, iPlayer, etc. They might have different models, but they all allow you to access streaming content, so choice is available. >> >> And here is where we get into the problem. Should End User believe Broadband Company sucks, they frequently cannot choose Broadband Company 2. I know I cannot, my choices are Comcast @ 100 Mbps or Verizon at 1.1 (yes, one-point-one) Mbps. So when Streaming Company sucks, but they suck because Broadband company is doing something I do not like, I cannot "vote with my wallet" and pick Broadband Company 2. I have no choice but to pick Streaming Company 2, even if I think the problem is Broadband Company's fault. (To be clear, I am not a NF subscriber - any more - and so this is not a NF/CC thing, I'm just talking generalities.) >> >> Put more succinctly, there is no functioning market. therefore there cannot be a market-based solution. >> >> Personally, I view that as about the most Un-American, Un-Capitalistic thing there is. >> >> Lots of people have suggested a simple, if very difficult, fix to this problem. Make the underlying physical infrastructure a regulated monopoly, i.e. a Utility. Then allow anyone to run services over that physical infrastructure. >> >> This is not pipe dream. The UK does it today. People there pick ISPs based on service, price, features, etc., not on "who paid off my local PUC". >> >> And before anyone brings up the whole "the UK is more dense than the US", I preemptively call BS. There is more choice, faster speeds, and lower prices in the middle of no-where UK than downtown manhattan. Please just leave that argument where it belongs, in the dung heap. >> >> Why can we not do something similar in the US? because the companies who own the lines have enough money to pay enough lobbyists to avoid even the promises they do make. (If anyone on this list is un-aware of things like the telcos promising ubiquitous high-speed BB years ago and never delivering, but never giving back their tax breaks or monopoly positions, you should be ashamed of yourselves.) >> >> But hey, a guy can dream, right? >> >> In the mean time, let's stop pretending that 'oh, L3 paid CC so they must be best friends'. L3 paid because They Had No Choice, and maybe because they see some long-term strategic benefit (e.g. they can charge others more later). >> >> This is not a functioning market. This is a few players with Market Power charging Rents, which any first year econ major will explain is a _very_very_very_ bad place for the market to be. >> >> -- >> TTFN, >> patrick >> From owen at delong.com Sun May 11 17:26:41 2014 From: owen at delong.com (Owen DeLong) Date: Sun, 11 May 2014 10:26:41 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: <21358.55623.277608.645527@world.std.com> References: <536BBC62.4070805@KingsMountain.com> <21358.55623.277608.645527@world.std.com> Message-ID: <72D90FA8-F7AB-42F1-AEAC-D5A471EC2A75@delong.com> On May 10, 2014, at 6:58 PM, Barry Shein wrote: > > On May 10, 2014 at 22:34 randy at psg.com (Randy Bush) wrote: >> imiho think vi hart has it down simply and understandable by a lay >> person. . my >> friends in last mile providers disagree. i take that as a good sign. > > Yeah, well, for extra credit integrate Akamai into that story. They were already there. Owen From tom at ninjabadger.net Sun May 11 23:55:10 2014 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 12 May 2014 00:55:10 +0100 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <05F6EA01-711E-4EE2-AC84-3F0A107ED849@ianai.net> Message-ID: <53700DDE.5070503@ninjabadger.net> On 10/05/14 20:40, Phil Bedard wrote: > The UK only does this with BT OpenReach since they were the telco monopoly > that originated as a government entity. Virgin Media (well all the people > who now form Virgin Media) built and operates their own fiber/HFC access > networks, the same as MSOs in the US, and does not offer wholesale access > and isn't treated as a utility. There are areas in the UK Virgin serves > where the wholesale network does not, and areas where they offer much > faster speeds, which is the same exact scenario as we have here I think Patrick was more trying to highlight that there is nothing stopping Openreach and Virgin Media from building their last miles in the same markets, side by side. They do so in many cases, and compete fairly equally for that business. Or, for that matter, anyone else: Metronet[1] are busy building their own wireless infrastructure around the UK, and City Fibre[2] are running fibre up to everyone's door in a number of cities. Wholesale agreements are part and parcel of the business, as is the consumer choice to switch provider without penalty. (And, just to clarify, you *can* buy wholesale Ethernet leased lines from Virgin Media Business, just not the DOCSIS access services.) These examples are really only scratching the surface; the point is that you can switch providers to your heart's content. Or just build your own, should you have the means. There isn't a granted monopoly on end-user access in the UK (anything else is due to economics, and for that, see B4RN[3]). I won't claim to hold the magic recipe for ensuring fair choice for consumers, and the UK market is far from perfect, but so far it's sounding a hell of a lot saner than what's happening in the US. Tom [1] http://www.metronet-uk.com [2] http://www.cityfibre.com [3] http://b4rn.org.uk/ From bzs at world.std.com Mon May 12 02:57:07 2014 From: bzs at world.std.com (Barry Shein) Date: Sun, 11 May 2014 22:57:07 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: <0ED02CA1-12CE-4D69-9F3E-E4E7EA0F5678@delong.com> References: <536BBC62.4070805@KingsMountain.com> <05F6EA01-711E-4EE2-AC84-3F0A107ED849@ianai.net> <98FA78E1-E968-40D6-977C-E9B23367ECD0@conlen.org> <0ED02CA1-12CE-4D69-9F3E-E4E7EA0F5678@delong.com> Message-ID: <21360.14467.769766.531327@world.std.com> Possibly interesting: FCC chairman will reportedly revise broadband proposal http://www.cnet.com/news/fcc-chairman-will-reportedly-revise-broadband-proposal/ or http://tinyurl.com/kfwrogs -- -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 email at edylie.net Mon May 12 10:36:32 2014 From: email at edylie.net (Pui Edylie) Date: Mon, 12 May 2014 18:36:32 +0800 Subject: Local Loop Provider Boston Natick Message-ID: <5370A430.6060901@edylie.net> Dear Nanog, I am sorry for wide distribution. We are looking for a local loop provider in Boston Natick area to either 1. our POP in New Jersey OR 2. to Singapore Equinix SG1 We are looking for 100Mbps Layer 2 (MTU Size 2000 and above) and able to carry our SVLAN and CVLAN. Please kindly unicast the reply to me. Thanks much! Best Regards, Edy From alumbis at gmail.com Mon May 12 12:18:38 2014 From: alumbis at gmail.com (Pete Lumbis) Date: Mon, 12 May 2014 08:18:38 -0400 Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. In-Reply-To: References: <536969E5.6080608@cox.net> <1D80627D-AF5C-4E2D-B93D-1EEF624BAC0E@inblock.ru> Message-ID: The datasheet for the ESP-5 states support for 500,000 IPv4 Prefixes. The TCAM on the ASR1k is different from 6500 and can't be adjusted in the same fashion. You'd have to filter or upgrade the ESP. http://www.cisco.com/c/en/us/products/collateral/routers/asr-1000-series-aggregation-services-routers/data_sheet_c78-450070.html(ctrl+f "Table 3") On Thu, May 8, 2014 at 10:55 AM, Michael Dikkema wrote: > I could never get an definitive answer out of TAC or my account team, but I > believe the ASR1002 w/ESP5 is also affected. > > > On Thu, May 8, 2014 at 1:15 AM, Nikolay Shopik wrote: > > > Asr1002-f may have problem as it limited to 512k iirc > > > > > On 08 мая 2014 г., at 2:45, Shawn L wrote: > > > > > > Do the ASR1k routers have this issue as well? I searched around but > > > couldn't find any information. > > > > > > > > > > > > ---------- Forwarded message ---------- > > > From: Irwin, Kevin > > > Date: Wed, May 7, 2014 at 10:39 AM > > > Subject: Re: Getting pretty close to default IPv4 route maximum for > > > 6500/7600 routers. > > > To: "nanog at nanog.org" > > > > > > > > > I¹m really surprised that most people have not hit this limit already, > > > especially on the 9K¹s, as it seems Cisco has some fuzzy math when it > > > comes to the 512K limit. > > > > > > Also make sure you have spare cards when you reload after changing the > > > scaling, those old cards don¹t always like to come back. > > > > > >> On 5/6/14, 7:01 PM, "Larry Sheldon" wrote: > > >> > > >>> On 5/6/2014 10:39 AM, Drew Weaver wrote: > > >>> > > >>> Just something to think about before it becomes a story the community > > >>> talks about for the next decade. > > >> > > >> Like we have for the last two? > > >> > > >> > > >> -- > > >> Requiescas in pace o email Two identifying characteristics > > >> of System Administrators: > > >> Ex turpi causa non oritur actio Infallibility, and the ability to > > >> learn from their mistakes. > > >> (Adapted from Stephen Pinker) > > > > > > The information transmitted is intended only for the person or entity > to > > > which it is addressed and may contain confidential and/or privileged > > > material. Any review, retransmission, dissemination or other use of, or > > > taking of any action in reliance upon, this information by persons or > > > entities other than the intended recipient is prohibited. If you > receive > > > this in error, please contact the sender and destroy any copies of this > > > document. > > > From nick at foobar.org Mon May 12 13:02:28 2014 From: nick at foobar.org (Nick Hilliard) Date: Mon, 12 May 2014 15:02:28 +0200 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> Message-ID: <5370C664.5050405@foobar.org> On 10/05/2014 22:34, Randy Bush wrote: > imiho think vi hart has it down simply and understandable by a lay > person. . my > friends in last mile providers disagree. i take that as a good sign. Vi's analogy is wrong on a subtle but important point. In the analogy, the delivery company needs to get a bunch of new trucks to handle the delivery but as the customer is paying for each delivery instances, the delivery company's costs are covered by increased end-user charges. In the net neutrality debate, the last mile service providers are in a position where they need to upgrade their access networks, but the end-user pricing is not necessarily keeping pace. There are lot of ways to argue this point, depending on whether you're the user, the access provider or the content provider. >From a financial point of view, the content providers will say that access providers need to charge their end users in a way which reflects their usage requirements because let's face it, it's the users that are pulling the traffic - they're not sending traffic to arbitrary IP addresses just for the fun of it. The end users will say that they're only going to pay market rate for their services, and they won't care whether this covers their costs or not. The access providers will say that they're only upgrading to deal with the additional requirements of the larger content providers, particularly the CDNs and the video streaming services, and that the going market rate doesn't allow them to charge the end users more. Besides, it's a whole pile easier to chase a small number of companies for a large amount of money than it is to chase a large number of customer for a small amount of money. Even better, if you chase the the content sources for cash, you can do this without increasing customer prices which means you can stay more competitive in the sales market. So from a business perspective it makes lots of sense to deprioritise the large companies that don't pay in favour of the ones that do. Those who pay get better service for their customers; seems fair, right? >From the proverbial helicopter viewpoint, we are walking towards a situation where the short-term business actions of the individual companies involved in the industry is going to lead towards customers being hurt and this means that the likely long-term outcome is more regulation and legislative control imposed on the industry. It is another tragedy of the commons. Nick From clayton at MNSi.Net Mon May 12 13:27:37 2014 From: clayton at MNSi.Net (Clayton Zekelman) Date: Mon, 12 May 2014 09:27:37 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <5370C664.5050405@foobar.org> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> Message-ID: <1399901280_81418@surgemail.mnsi.net> At 09:02 AM 12/05/2014, Nick Hilliard wrote: >So from a business >perspective it makes lots of sense to deprioritise the large companies that >don't pay in favour of the ones that do. Those who pay get better service >for their customers; seems fair, right? I think that's where the biggest gulf exists. It doesn't seem fair. It seems like extortion. The last mile access guys are the gatekeepers to the end user, with little competition. The access providers are saying "Our customers are paying us to use our service, but we don't want to raise our retail prices to match their usage patterns, so we'll put the squeeze on the guys on the other side who are distributing the content. They can raise their prices, so we don't look like the bad guys. The benefit is, since their video services compete with our packaged television services, we may have fewer TV cord cutters." I have a mix of wholesale and facilities based last mile access in my network. I don't sell TV. I see Netflix as a reason people sign up for my service - not as a competitor trying to "ride my pipes for free". I would welcome peering with them, but sadly, they don't peer in Canada, so their traffic ends up on transit links. --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From nick at foobar.org Mon May 12 13:37:53 2014 From: nick at foobar.org (Nick Hilliard) Date: Mon, 12 May 2014 15:37:53 +0200 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <1399901280_81418@surgemail.mnsi.net> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <1399901280_81418@surgemail.mnsi.net> Message-ID: <5370CEB1.9050705@foobar.org> On 12/05/2014 15:27, Clayton Zekelman wrote: > I think that's where the biggest gulf exists. It doesn't seem fair. It > seems like extortion. The last mile access guys are the gatekeepers to the > end user, with little competition. that is the core problem: lack of competition. Net neutrality is a kludge to deal with a specific type of failure in the market. Nick From Valdis.Kletnieks at vt.edu Mon May 12 13:38:51 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 12 May 2014 09:38:51 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: Your message of "Mon, 12 May 2014 15:02:28 +0200." <5370C664.5050405@foobar.org> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> Message-ID: <53925.1399901931@turing-police.cc.vt.edu> On Mon, 12 May 2014 15:02:28 +0200, Nick Hilliard said: > a small amount of money. Even better, if you chase the the content sources > for cash, you can do this without increasing customer prices which means > you can stay more competitive in the sales market. Thank you, I needed my morning chuckle. :) We know which last-mile providers are doing this. Over what percentage of their territory is there any *realistic* competition? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From nick at pelagiris.org Mon May 12 13:44:33 2014 From: nick at pelagiris.org (Nick B) Date: Mon, 12 May 2014 09:44:33 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <5370C664.5050405@foobar.org> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> Message-ID: Google Fiber and various other FTTH services disprove the "omg it costs a lot" theory. This is purely a money grab by a monopoly, sanctioned by the FCC because.. the people doing the money grab own the FCC. It helps to keep in mind that several of the parties involved in this grab *HAVE ALREADY BEEN PAID TO EXPAND THEIR NETWORKS BY THE PUBLIC, AND HAVE FAILED TO DO SO*. I'm not really sure how anyone could view this whole thing as fair, honest or even legal. I also fully expect the FCC to sign off on it as the receipt says "Paid by Verizon." Nick On Mon, May 12, 2014 at 9:02 AM, Nick Hilliard wrote: > On 10/05/2014 22:34, Randy Bush wrote: > > imiho think vi hart has it down simply and understandable by a lay > > person. . my > > friends in last mile providers disagree. i take that as a good sign. > > Vi's analogy is wrong on a subtle but important point. In the analogy, the > delivery company needs to get a bunch of new trucks to handle the delivery > but as the customer is paying for each delivery instances, the delivery > company's costs are covered by increased end-user charges. > > In the net neutrality debate, the last mile service providers are in a > position where they need to upgrade their access networks, but the end-user > pricing is not necessarily keeping pace. > > There are lot of ways to argue this point, depending on whether you're the > user, the access provider or the content provider. > > From a financial point of view, the content providers will say that access > providers need to charge their end users in a way which reflects their > usage requirements because let's face it, it's the users that are pulling > the traffic - they're not sending traffic to arbitrary IP addresses just > for the fun of it. The end users will say that they're only going to pay > market rate for their services, and they won't care whether this covers > their costs or not. The access providers will say that they're only > upgrading to deal with the additional requirements of the larger content > providers, particularly the CDNs and the video streaming services, and that > the going market rate doesn't allow them to charge the end users more. > Besides, it's a whole pile easier to chase a small number of companies for > a large amount of money than it is to chase a large number of customer for > a small amount of money. Even better, if you chase the the content sources > for cash, you can do this without increasing customer prices which means > you can stay more competitive in the sales market. So from a business > perspective it makes lots of sense to deprioritise the large companies that > don't pay in favour of the ones that do. Those who pay get better service > for their customers; seems fair, right? > > From the proverbial helicopter viewpoint, we are walking towards a > situation where the short-term business actions of the individual companies > involved in the industry is going to lead towards customers being hurt and > this means that the likely long-term outcome is more regulation and > legislative control imposed on the industry. It is another tragedy of the > commons. > > Nick > > > From clayton at MNSi.Net Mon May 12 14:00:53 2014 From: clayton at MNSi.Net (Clayton Zekelman) Date: Mon, 12 May 2014 10:00:53 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> Message-ID: <1399903256_81852@surgemail.mnsi.net> Actually, I've done a bit of overbuild, and it does "omg cost a lot". We don't know how much Google Fiber has paid to build the network. They're Google, they can do it just because they feel like it. Of course I don't have any proof, but the rest of your points may not be far off the mark. At 09:44 AM 12/05/2014, Nick B wrote: >Google Fiber and various other FTTH services disprove the "omg it costs a >lot" theory. This is purely a money grab by a monopoly, sanctioned by the >FCC because.. the people doing the money grab own the FCC. It helps to >keep in mind that several of the parties involved in this grab *HAVE >ALREADY BEEN PAID TO EXPAND THEIR NETWORKS BY THE PUBLIC, AND HAVE FAILED >TO DO SO*. I'm not really sure how anyone could view this whole thing as >fair, honest or even legal. I also fully expect the FCC to sign off on it >as the receipt says "Paid by Verizon." >Nick --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From owen at delong.com Mon May 12 14:07:33 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 12 May 2014 07:07:33 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <5370C664.5050405@foobar.org> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> Message-ID: <5820C336-043E-4680-87BB-8CAE72ACA4DF@delong.com> On May 12, 2014, at 6:02 AM, Nick Hilliard wrote: > On 10/05/2014 22:34, Randy Bush wrote: >> imiho think vi hart has it down simply and understandable by a lay >> person. . my >> friends in last mile providers disagree. i take that as a good sign. > > Vi's analogy is wrong on a subtle but important point. In the analogy, the > delivery company needs to get a bunch of new trucks to handle the delivery > but as the customer is paying for each delivery instances, the delivery > company's costs are covered by increased end-user charges. Two words nuke your suggestion here: Amazon Prime Owen From joelja at bogus.com Mon May 12 14:30:07 2014 From: joelja at bogus.com (joel jaeggli) Date: Mon, 12 May 2014 07:30:07 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <5820C336-043E-4680-87BB-8CAE72ACA4DF@delong.com> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <5820C336-043E-4680-87BB-8CAE72ACA4DF@delong.com> Message-ID: <5370DAEF.5020102@bogus.com> On 5/12/14, 7:07 AM, Owen DeLong wrote: > > On May 12, 2014, at 6:02 AM, Nick Hilliard wrote: > >> On 10/05/2014 22:34, Randy Bush wrote: >>> imiho think vi hart has it down simply and understandable by a lay >>> person. . my >>> friends in last mile providers disagree. i take that as a good sign. >> >> Vi's analogy is wrong on a subtle but important point. In the analogy, the >> delivery company needs to get a bunch of new trucks to handle the delivery >> but as the customer is paying for each delivery instances, the delivery >> company's costs are covered by increased end-user charges. > > Two words nuke your suggestion here: Amazon Prime Once you build the capacity to reach every delivery point every-day it's maybe not enough to hope that people utilize that facility . decreasing the cost per package requires higher unit volume. The incremental cost of delivering the second package is much lower than the first. > Owen > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From wesley.george at twcable.com Mon May 12 14:41:44 2014 From: wesley.george at twcable.com (George, Wes) Date: Mon, 12 May 2014 10:41:44 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <5820C336-043E-4680-87BB-8CAE72ACA4DF@delong.com> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <5820C336-043E-4680-87BB-8CAE72ACA4DF@delong.com> Message-ID: On 5/12/14, 10:07 AM, "Owen DeLong" wrote: > >On May 12, 2014, at 6:02 AM, Nick Hilliard wrote: > >> On 10/05/2014 22:34, Randy Bush wrote: >>> imiho think vi hart has it down simply and understandable by a lay >>> person. . my >>> friends in last mile providers disagree. i take that as a good sign. >> >> Vi's analogy is wrong on a subtle but important point. In the analogy, >>the >> delivery company needs to get a bunch of new trucks to handle the >>delivery >> but as the customer is paying for each delivery instances, the delivery >> company's costs are covered by increased end-user charges. > >Two words nuke your suggestion here: Amazon Prime Amazon Prime isn’t a flat-rate delivery service for the delivery company, else it’d be called FedUPS Prime. It’s a flat rate shipping subscription for *Amazon*, and is likely a loss leader to ensure better stickiness of Amazon’s potential customers. They may have a great deal of negotiating leverage on their delivery partners to reduce their shipping costs, and the sheer volume of Amazon warehouses mean that they can take advantage of proximity to reduce costs further (like a CDN), but I haven’t seen anything implying that they’ve been successful in negotiating a contract that is insensitive to the *amount* of items being shipped. Wes George 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 clayton at MNSi.Net Mon May 12 14:44:13 2014 From: clayton at MNSi.Net (Clayton Zekelman) Date: Mon, 12 May 2014 10:44:13 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <5370DAEF.5020102@bogus.com> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <5820C336-043E-4680-87BB-8CAE72ACA4DF@delong.com> <5370DAEF.5020102@bogus.com> Message-ID: <1399905856_82475@surgemail.mnsi.net> That's true for any given network topology up to the limit of capacity. On cable plant, node splitting does incur significant costs. May cable companies who built their fiber optic network with 200-500 customers per RF node are now finding they have to reduce that density. They don't have enough feeder fiber in their network to accommodate. They have a few choices: 1) overlash more fiber, 2) use more WDM, 3) build more pop sites. The incremental cost of delivering that one package above what the truck will hold is a doozie. It requires the delivery company to buy bigger trucks, or buy more trucks and run smaller routes. At 10:30 AM 12/05/2014, joel jaeggli wrote: >Once you build the capacity to reach every delivery point every-day it's >maybe not enough to hope that people utilize that facility . decreasing >the cost per package requires higher unit volume. The incremental cost >of delivering the second package is much lower than the first. --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From owen at delong.com Mon May 12 14:51:50 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 12 May 2014 07:51:50 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <5370DAEF.5020102@bogus.com> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <5820C336-043E-4680-87BB-8CAE72ACA4DF@delong.com> <5370DAEF.5020102@bogus.com> Message-ID: <6F0C54A2-D107-4D3D-84AF-8AE82F1209C6@delong.com> On May 12, 2014, at 7:30 AM, joel jaeggli wrote: > On 5/12/14, 7:07 AM, Owen DeLong wrote: >> >> On May 12, 2014, at 6:02 AM, Nick Hilliard wrote: >> >>> On 10/05/2014 22:34, Randy Bush wrote: >>>> imiho think vi hart has it down simply and understandable by a lay >>>> person. . my >>>> friends in last mile providers disagree. i take that as a good sign. >>> >>> Vi's analogy is wrong on a subtle but important point. In the analogy, the >>> delivery company needs to get a bunch of new trucks to handle the delivery >>> but as the customer is paying for each delivery instances, the delivery >>> company's costs are covered by increased end-user charges. >> >> Two words nuke your suggestion here: Amazon Prime > > Once you build the capacity to reach every delivery point every-day it's > maybe not enough to hope that people utilize that facility . decreasing > the cost per package requires higher unit volume. The incremental cost > of delivering the second package is much lower than the first. My point is that above, he claims that shipping is per package and not flat-rate. Amazon Prime contradicts that claim. It is flat rate for two-day shipping for almost everything I purchase from Amazon. Owen From nick at pelagiris.org Mon May 12 14:53:45 2014 From: nick at pelagiris.org (Nick B) Date: Mon, 12 May 2014 10:53:45 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <1399903256_81852@surgemail.mnsi.net> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <1399903256_81852@surgemail.mnsi.net> Message-ID: Even if you are right, which I'm not sure you are about the cost as Google isn't the only FTTH provider, at least one of the major players *HAS ALREADY PEEN PAID TO DO THE WORK*. http://stopthecap.com/2014/03/17/new-jerseys-fiber-ripoff-verizon-walks-away-from-fiber-upgrades-customers-already-paid-for/ Nick On Mon, May 12, 2014 at 10:00 AM, Clayton Zekelman wrote: > > Actually, I've done a bit of overbuild, and it does "omg cost a lot". > > We don't know how much Google Fiber has paid to build the network. > They're Google, they can do it just because they feel like it. > > Of course I don't have any proof, but the rest of your points may not be > far off the mark. > > > > At 09:44 AM 12/05/2014, Nick B wrote: > >> Google Fiber and various other FTTH services disprove the "omg it costs a >> lot" theory. This is purely a money grab by a monopoly, sanctioned by the >> FCC because.. the people doing the money grab own the FCC. It helps to >> keep in mind that several of the parties involved in this grab *HAVE >> ALREADY BEEN PAID TO EXPAND THEIR NETWORKS BY THE PUBLIC, AND HAVE FAILED >> TO DO SO*. I'm not really sure how anyone could view this whole thing as >> fair, honest or even legal. I also fully expect the FCC to sign off on it >> as the receipt says "Paid by Verizon." >> Nick >> > > --- > > Clayton Zekelman > Managed Network Systems Inc. (MNSi) > 3363 Tecumseh Rd. E > Windsor, Ontario > N8W 1H4 > > tel. 519-985-8410 > fax. 519-985-8409 > From owen at delong.com Mon May 12 14:55:59 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 12 May 2014 07:55:59 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <5820C336-043E-4680-87BB-8CAE72ACA4DF@delong.com> Message-ID: <2E5842F9-D6E8-4C10-A76B-67CFBBF10FF0@delong.com> On May 12, 2014, at 7:41 AM, George, Wes wrote: > > On 5/12/14, 10:07 AM, "Owen DeLong" wrote: > >> >> On May 12, 2014, at 6:02 AM, Nick Hilliard wrote: >> >>> On 10/05/2014 22:34, Randy Bush wrote: >>>> imiho think vi hart has it down simply and understandable by a lay >>>> person. . my >>>> friends in last mile providers disagree. i take that as a good sign. >>> >>> Vi's analogy is wrong on a subtle but important point. In the analogy, >>> the >>> delivery company needs to get a bunch of new trucks to handle the >>> delivery >>> but as the customer is paying for each delivery instances, the delivery >>> company's costs are covered by increased end-user charges. >> >> Two words nuke your suggestion here: Amazon Prime > > Amazon Prime isn’t a flat-rate delivery service for the delivery company, > else it’d be called FedUPS Prime. It’s a flat rate shipping subscription > for *Amazon*, and is likely a loss leader to ensure better stickiness of > Amazon’s potential customers. They may have a great deal of negotiating > leverage on their delivery partners to reduce their shipping costs, and > the sheer volume of Amazon warehouses mean that they can take advantage of > proximity to reduce costs further (like a CDN), but I haven’t seen > anything implying that they’ve been successful in negotiating a contract > that is insensitive to the *amount* of items being shipped. > Who cares? It’s insensitive from the end-customer perspective. Same as what I pay to Comcast is insensitive to my usage. Amazon hasn’t negotiated insensitive pricing with their shipping companies, just as Comcast hasn’t negotiated insensitive pricing for infrastructure upgrades. Seems to me that the analogy holds. Owen From fergdawgster at mykolab.com Mon May 12 16:49:43 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Mon, 12 May 2014 09:49:43 -0700 Subject: How the NSA tampers with US-made Internet routers Message-ID: <5370FBA7.6030900@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Just an FYI: "For years, the US government loudly warned the world that Chinese routers and other internet devices pose a "threat" because they are built with backdoor surveillance functionality that gives the Chinese government the ability to spy on anyone using them. Yet what the NSA's documents show is that Americans have been engaged in precisely the activity that the US accused the Chinese of doing." Much more: http://www.theguardian.com/books/2014/may/12/glenn-greenwald-nsa-tampers-us-internet-routers-snowden Enjoy! - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNw+6cACgkQKJasdVTchbJvwAD9GySSpd3dpSMNkJM0y6GjWRzC +Ys/giaX2FcjtSu2qwgA/jzxiz5h69e8Vw/3MBgp3YcpjrauC1Olz3mFmxSseF33 =gc8p -----END PGP SIGNATURE----- From bzs at world.std.com Mon May 12 17:05:28 2014 From: bzs at world.std.com (Barry Shein) Date: Mon, 12 May 2014 13:05:28 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <5370C664.5050405@foobar.org> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> Message-ID: <21360.65368.453476.954590@world.std.com> On May 12, 2014 at 15:02 nick at foobar.org (Nick Hilliard) wrote: > > In the net neutrality debate, the last mile service providers are in a > position where they need to upgrade their access networks, but the end-user > pricing is not necessarily keeping pace. You make a common error: That we the people should be concerned with Comcast's (et al) business model over our own ability to obtain the best service at the best price. That we should be so concerned that we are willing to legislate and regulate against our own interests lest Comcast et all suffer an economic injustice. It's an interesting, albeit not uncommon, view of economic justice for corporate entities. We live in an economic advocacy society, not one driven primarily by economic justice. The latter is generally called "charity" and charity for huge corporations is, well, just that. Obviously one has every right to advocate for corporate welfare but let's call it what it is. -- -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 bzs at world.std.com Mon May 12 17:06:55 2014 From: bzs at world.std.com (Barry Shein) Date: Mon, 12 May 2014 13:06:55 -0400 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <5370CEB1.9050705@foobar.org> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <1399901280_81418@surgemail.mnsi.net> <5370CEB1.9050705@foobar.org> Message-ID: <21360.65455.544149.936534@world.std.com> On May 12, 2014 at 15:37 nick at foobar.org (Nick Hilliard) wrote: > On 12/05/2014 15:27, Clayton Zekelman wrote: > > I think that's where the biggest gulf exists. It doesn't seem fair. It > > seems like extortion. The last mile access guys are the gatekeepers to the > > end user, with little competition. > > that is the core problem: lack of competition. Net neutrality is a kludge > to deal with a specific type of failure in the market. HOWEVER, I do agree with this comment. -- -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 Jason_Livingood at cable.comcast.com Mon May 12 19:48:50 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Mon, 12 May 2014 19:48:50 +0000 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <2E5842F9-D6E8-4C10-A76B-67CFBBF10FF0@delong.com> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <5820C336-043E-4680-87BB-8CAE72ACA4DF@delong.com> <2E5842F9-D6E8-4C10-A76B-67CFBBF10FF0@delong.com> Message-ID: On 5/12/14, 10:55 AM, "Owen DeLong" > wrote: Who cares? It’s insensitive from the end-customer perspective. Same as what I pay to Comcast is insensitive to my usage. Amazon hasn’t negotiated insensitive pricing with their shipping companies, just as Comcast hasn’t negotiated insensitive pricing for infrastructure upgrades. Seems to me that the analogy holds. Interesting analogy. To digress a bit. UPS/FedEx/UPS generally serve as the package delivery network for Amazon Prime shipments, though sometimes they do so via smaller regional package delivery networks. Also Amazon seems to be experimenting with direct delivery in some areas in order to provide a level of delivery quality they don’t feel they can get via 3rd party (same day delivery). As you describe, the end users (consumers of Amazon Prime) are insensitive to the shipping cost due to the flat fee the consumer paid to Amazon. This dynamic appears to have contributed to a 2013 holiday shipping season that saw package delays (packages sent exceeded capacity to deliver on time), which appears to have played a role in FedEx’s recent announcement of a plan to charge shippers by size, rather than purely by weight. Some analysis I read was that this may prompt companies like Amazon to get more efficient in what they send to package delivery networks; packages will become smaller (think fewer of those inflatable plastic bags inside). Jason From randy at psg.com Mon May 12 20:11:55 2014 From: randy at psg.com (Randy Bush) Date: Mon, 12 May 2014 22:11:55 +0200 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <5820C336-043E-4680-87BB-8CAE72ACA4DF@delong.com> <2E5842F9-D6E8-4C10-A76B-67CFBBF10FF0@delong.com> Message-ID: jason, thanks for posting from your work address. really appreciated. i wish others employed on one side or t'other would make their affiliations clear, when the subject cuts so close to the pockets of large financial interests. randy From dougb at dougbarton.us Mon May 12 20:39:34 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 12 May 2014 13:39:34 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <5820C336-043E-4680-87BB-8CAE72ACA4DF@delong.com> <2E5842F9-D6E8-4C10-A76B-67CFBBF10FF0@delong.com> Message-ID: <53713186.6070603@dougbarton.us> On 05/12/2014 12:48 PM, Livingood, Jason wrote: > Also Amazon seems to be experimenting with direct delivery in some areas in order to provide a level of delivery quality they don’t feel they can get via 3rd party Someone wake me up when RFC 1149 gets updated to "IP Datagrams on Drone Carriers" From phiber at phiber.org Mon May 12 21:46:53 2014 From: phiber at phiber.org (Christopher Rogers) Date: Mon, 12 May 2014 14:46:53 -0700 Subject: level3 dia egress filtering? Message-ID: Does anyone have any experience dealing with level3 in trying to get egress filters applied to an internet dia link with them? I've been trying to get them to apply an egress filter to drop all of udp to a certain /25 on my network that's been getting hammered by a dns amplification attack, and I am being told that they can only 'drop an entire protocol, and not to a specific ip address or range.' Can anyone confirm if that's the case? cheers -chris From Petter.Bruland at allegiantair.com Mon May 12 21:58:20 2014 From: Petter.Bruland at allegiantair.com (Petter Bruland) Date: Mon, 12 May 2014 21:58:20 +0000 Subject: level3 dia egress filtering? In-Reply-To: References: Message-ID: We contacted Level3 a few weeks back, and were told that they do not provide any filtering service. I've not been able to confirm this from anyone else, besides the Level3 customer service rep we spoke with. Currently looking into a DDoS protection service from Akamai. Sounds awesome what they can do, but often "awesome" translates to "overkill" and/or "too expensive". -Petter -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher Rogers Sent: Monday, May 12, 2014 2:47 PM To: nanog at nanog.org Subject: level3 dia egress filtering? Does anyone have any experience dealing with level3 in trying to get egress filters applied to an internet dia link with them? I've been trying to get them to apply an egress filter to drop all of udp to a certain /25 on my network that's been getting hammered by a dns amplification attack, and I am being told that they can only 'drop an entire protocol, and not to a specific ip address or range.' Can anyone confirm if that's the case? cheers -chris From bob at FiberInternetCenter.com Mon May 12 22:20:05 2014 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 12 May 2014 15:20:05 -0700 Subject: level3 dia egress filtering? In-Reply-To: References: Message-ID: <2bb6070aa4c425c6bbaa68c2263e68c0.squirrel@66.201.44.180> Are you asking a transit network to filter specific ports as an end user or as an ISP who has Level 3 as a transit provider? I haven't seen a specific port could be dropped by any network....Only aware of BGP community string like, 3356:9999 - black hole (discard all traffic for specific IP range) traffic type abilities. We have and will filter specific ports for customers. But this port type ACL is completed by hand....I haven't seen anyone implement this using a BGP community string. Bob Evans CTO Fiber Internet CenterThank You Bob Evans CTO > We contacted Level3 a few weeks back, and were told that they do not > provide any filtering service. > I've not been able to confirm this from anyone else, besides the Level3 > customer service rep we spoke with. > > Currently looking into a DDoS protection service from Akamai. Sounds > awesome what they can do, but often "awesome" translates to "overkill" > and/or "too expensive". > > -Petter > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher > Rogers > Sent: Monday, May 12, 2014 2:47 PM > To: nanog at nanog.org > Subject: level3 dia egress filtering? > > Does anyone have any experience dealing with level3 in trying to get > egress filters applied to an internet dia link with them? > > I've been trying to get them to apply an egress filter to drop all of udp > to a certain /25 on my network that's been getting hammered by a dns > amplification attack, and I am being told that they can only 'drop an > entire protocol, and not to a specific ip address or range.' > > Can anyone confirm if that's the case? > > cheers > -chris > From phiber at phiber.org Mon May 12 22:27:26 2014 From: phiber at phiber.org (Christopher Rogers) Date: Mon, 12 May 2014 15:27:26 -0700 Subject: level3 dia egress filtering? In-Reply-To: <2bb6070aa4c425c6bbaa68c2263e68c0.squirrel@66.201.44.180> References: <2bb6070aa4c425c6bbaa68c2263e68c0.squirrel@66.201.44.180> Message-ID: Not specific ports, but something more like: 'deny udp any my.target.slash.25 0.0.255.255' BGP blackholing will obviously impact all traffic to a target. -chris 2014-05-12 15:20 GMT-07:00 Bob Evans : > Are you asking a transit network to filter specific ports as an end user > or as an ISP who has Level 3 as a transit provider? > > I haven't seen a specific port could be dropped by any network....Only > aware of BGP community string like, 3356:9999 - black hole (discard all > traffic for specific IP range) traffic type abilities. > > We have and will filter specific ports for customers. But this port type > ACL is completed by hand....I haven't seen anyone implement this using a > BGP community string. > > Bob Evans > CTO > Fiber Internet CenterThank You > Bob Evans > CTO > > > > We contacted Level3 a few weeks back, and were told that they do not > > provide any filtering service. > > I've not been able to confirm this from anyone else, besides the Level3 > > customer service rep we spoke with. > > > > Currently looking into a DDoS protection service from Akamai. Sounds > > awesome what they can do, but often "awesome" translates to "overkill" > > and/or "too expensive". > > > > -Petter > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher > > Rogers > > Sent: Monday, May 12, 2014 2:47 PM > > To: nanog at nanog.org > > Subject: level3 dia egress filtering? > > > > Does anyone have any experience dealing with level3 in trying to get > > egress filters applied to an internet dia link with them? > > > > I've been trying to get them to apply an egress filter to drop all of udp > > to a certain /25 on my network that's been getting hammered by a dns > > amplification attack, and I am being told that they can only 'drop an > > entire protocol, and not to a specific ip address or range.' > > > > Can anyone confirm if that's the case? > > > > cheers > > -chris > > > > > From bob at FiberInternetCenter.com Mon May 12 23:22:57 2014 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 12 May 2014 16:22:57 -0700 Subject: level3 dia egress filtering? In-Reply-To: References: <2bb6070aa4c425c6bbaa68c2263e68c0.squirrel@66.201.44.180> Message-ID: Ahh, Yep, same thing port and/or protocol for an address range. I haven't seen that accomplished via BGP. I know ATT will do it - they want about 2K more per month for that ability. All your traffic is redirected (extra hops ) through a firewall. So, it's a basic expensive firewall service. We have done both port based and protocol. But it gets installed by hand only on the connected port the customer. Bob Evans CTO Fiber Internet Center > Not specific ports, but something more like: > > 'deny udp any my.target.slash.25 0.0.255.255' > > BGP blackholing will obviously impact all traffic to a target. > > -chris > > 2014-05-12 15:20 GMT-07:00 Bob Evans : > >> Are you asking a transit network to filter specific ports as an end user >> or as an ISP who has Level 3 as a transit provider? >> >> I haven't seen a specific port could be dropped by any network....Only >> aware of BGP community string like, 3356:9999 - black hole (discard all >> traffic for specific IP range) traffic type abilities. >> >> We have and will filter specific ports for customers. But this port type >> ACL is completed by hand....I haven't seen anyone implement this using a >> BGP community string. >> >> Bob Evans >> CTO >> Fiber Internet CenterThank You >> Bob Evans >> CTO >> >> >> > We contacted Level3 a few weeks back, and were told that they do not >> > provide any filtering service. >> > I've not been able to confirm this from anyone else, besides the >> Level3 >> > customer service rep we spoke with. >> > >> > Currently looking into a DDoS protection service from Akamai. Sounds >> > awesome what they can do, but often "awesome" translates to "overkill" >> > and/or "too expensive". >> > >> > -Petter >> > >> > -----Original Message----- >> > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher >> > Rogers >> > Sent: Monday, May 12, 2014 2:47 PM >> > To: nanog at nanog.org >> > Subject: level3 dia egress filtering? >> > >> > Does anyone have any experience dealing with level3 in trying to get >> > egress filters applied to an internet dia link with them? >> > >> > I've been trying to get them to apply an egress filter to drop all of >> udp >> > to a certain /25 on my network that's been getting hammered by a dns >> > amplification attack, and I am being told that they can only 'drop an >> > entire protocol, and not to a specific ip address or range.' >> > >> > Can anyone confirm if that's the case? >> > >> > cheers >> > -chris >> > >> >> >> > From deepak at ai.net Tue May 13 00:29:49 2014 From: deepak at ai.net (Deepak Jain) Date: Tue, 13 May 2014 00:29:49 +0000 Subject: Residential CPE suggestions In-Reply-To: References: <20140506123107.4466177D@m0005297.ppops.net> <2a700f3fd03343be80c1bd4db30b3965@KWMAIL.local.kw-corp.com> <1286183966.176319.1399566601791.JavaMail.zimbra@network1.net> Message-ID: > On 9 May 2014 12:05, Aled Morris wrote: > > > Indeed. Mikrotik are promising a CCR1009 with 2xSFP and 8xUTP GE > > ports (and dual PSU) for $425 but it isn't an access switch (so no > > Q-in-Q) though it does support MPLS/VPLS. > > > > Apologies for correcting myself, but I just checked and Q-in-Q is supported in > Mikrotik RouterOS, so this might be the ideal box for you (if it were > orderable.) > > I forgot to include the link too - http://routerboard.com/CCR1009-8G-1S Thanks to everyone who responded. The picture/spec on this page shows a single SFP, not dual. Hopefully they will come out with something that supports dual SFP. I am looking for something suitable for an active Ethernet fiber-to-X deployment. The Ubiquiti routers don't support dual SFP until you get to the PRO (too bad no Wifi, emailed them. :) Thanks, Deepak From streiner at cluebyfour.org Mon May 12 22:59:07 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 12 May 2014 18:59:07 -0400 (EDT) Subject: level3 dia egress filtering? In-Reply-To: References: <2bb6070aa4c425c6bbaa68c2263e68c0.squirrel@66.201.44.180> Message-ID: On Mon, 12 May 2014, Bob Evans wrote: > Ahh, Yep, same thing port and/or protocol for an address range. I haven't > seen that accomplished via BGP. I know ATT will do it - they want about 2K > more per month for that ability. All your traffic is redirected (extra > hops ) through a firewall. So, it's a basic expensive firewall service. > > We have done both port based and protocol. But it gets installed by hand > only on the connected port the customer. >From what I've seen, most of the major carriers don't filter traffic outside of truly exceptional circumstances, or it's treated as a revenue source. If it's offered at all, it's often priced unattractively, because carriers often don't want to be in the firewall/port-filtering business. jms From cb.list6 at gmail.com Tue May 13 02:02:28 2014 From: cb.list6 at gmail.com (Ca By) Date: Mon, 12 May 2014 19:02:28 -0700 Subject: level3 dia egress filtering? In-Reply-To: References: <2bb6070aa4c425c6bbaa68c2263e68c0.squirrel@66.201.44.180> Message-ID: On May 12, 2014 6:53 PM, "Justin M. Streiner" wrote: > > On Mon, 12 May 2014, Bob Evans wrote: > >> Ahh, Yep, same thing port and/or protocol for an address range. I haven't >> seen that accomplished via BGP. I know ATT will do it - they want about 2K >> more per month for that ability. All your traffic is redirected (extra >> hops ) through a firewall. So, it's a basic expensive firewall service. >> >> We have done both port based and protocol. But it gets installed by hand >> only on the connected port the customer. > > > From what I've seen, most of the major carriers don't filter traffic outside of truly exceptional circumstances, or it's treated as a revenue source. If it's offered at all, it's often priced unattractively, because carriers often don't want to be in the firewall/port-filtering business. > > jms All my providers provide me incident response that includes rtbh as well as ACL and in some cases protocol rate limiting. ACL may take a while working the phone, but rtbh is immediate. I substanilly decreased business with at&t since they do not offer rtbh. Rtbh is really the floor on security features, and at&t is below the floor. CB From deepak at ai.net Tue May 13 07:08:03 2014 From: deepak at ai.net (Deepak Jain) Date: Tue, 13 May 2014 07:08:03 +0000 Subject: Residential CPE suggestions In-Reply-To: References: <20140506123107.4466177D@m0005297.ppops.net> <2a700f3fd03343be80c1bd4db30b3965@KWMAIL.local.kw-corp.com> <1286183966.176319.1399566601791.JavaMail.zimbra@network1.net> Message-ID: > Thanks to everyone who responded. The picture/spec on this page shows a > single SFP, not dual. Hopefully they will come out with something that > supports dual SFP. > > I am looking for something suitable for an active Ethernet fiber-to-X > deployment. The Ubiquiti routers don't support dual SFP until you get to the > PRO (too bad no Wifi, emailed them. :) Self-quoting here: CRS226-24G-2S from Mikrotik is using a new chipset, supposedly. I suspect that more vendors will be releasing configs like this if the silicon is becoming more prevalent. The thing has SFP+ ports (10G) which is cool, especially at the price point, but overkill. It has 24x gigabit ports which is definitely overkill, so ideally I can find a slimmer switch. :) List price under $300 looks like. This guy fits the bill (port config) more closely but also costs 3x more (faster cpu, more ram, etc). Neat stuff, either way. Deepak From mark.tinka at seacom.mu Tue May 13 09:02:13 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 13 May 2014 11:02:13 +0200 Subject: level3 dia egress filtering? In-Reply-To: References: Message-ID: <201405131102.16055.mark.tinka@seacom.mu> On Monday, May 12, 2014 11:58:20 PM Petter Bruland wrote: > We contacted Level3 a few weeks back, and were told that > they do not provide any filtering service. I've not been > able to confirm this from anyone else, besides the > Level3 customer service rep we spoke with. We've received such requests from customers as well, and our policy is we do not implement any kind of filtering, even though it is restricted to just one customer. If the customer is looking for DoS/DDoS Mitigation services, that is something else that can be offered. But as an ISP, filtering in the data plane that is not for the protection of our core's control plane is not our deal. It is not something I'd ask of my IP Transit provider, nor support that they do. 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 Joel.Snyder at Opus1.COM Tue May 13 12:08:26 2014 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Tue, 13 May 2014 14:08:26 +0200 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality) In-Reply-To: References: Message-ID: <53720B3A.7010103@Opus1.COM> Shouldn't there be a rule against using "RIP" in the subject line of a NANOG post? Every time I see that, a shudder goes down *my* spine. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From fergdawgster at mykolab.com Tue May 13 13:33:02 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Tue, 13 May 2014 06:33:02 -0700 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff Message-ID: <53721F0E.6090904@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I realize that New Zealand is *not* in North America (hence NANOG), but I figure that some global providers might be interested here. This sounds rather... dire (probably not the right word). "The new Telecommunications (Interception Capability and Security) Act of 2013 is in effect in New Zealand and brings in several drastic changes for ISPs, telcos and service providers. One of the country's spy agencies, the GCSB, gets to decide on network equipment procurement and design decisions (PDF), plus operators have to register with the police and obtain security clearance for some staff. Somewhat illogically, the NZ government pushed through the law combining mandated communications interception capabilities for law enforcement, with undefined network security requirements as decided by the GCSB. All network operators are subject to the new law, including local providers as well as the likes of Facebook, Google, Microsoft, who have opposed it, saying the new statutes clash with overseas privacy legislation." http://yro.slashdot.org/story/14/05/13/005259/new-zealand-spy-agency-to-vet-network-builds-provider-staff FYI, - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNyHw4ACgkQKJasdVTchbLwDgD/WVHo2iTapJ90l8MRcwUZ5OQ7 QfJ5cI1v4t2bUXZp1hQBAKHCP0hyxg6naGOzRLt/vHjgxXnl3+yiWoj0ENxQyIr9 =0yLu -----END PGP SIGNATURE----- From ggm at algebras.org Tue May 13 13:40:49 2014 From: ggm at algebras.org (George Michaelson) Date: Tue, 13 May 2014 15:40:49 +0200 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: <53721F0E.6090904@mykolab.com> References: <53721F0E.6090904@mykolab.com> Message-ID: It got a pretty firefight discussion at the NZNOG. None of the ISPs feel comfortable with it, but in avoiding a shoot-the-messenger syndrome they tried to give good feedback to the reps from GCSB who came to talk. Basically, a lot of post-act variations are expected to clarify what changes do and do not have to be notified. There was a lot of bitter humour about calling them at 3am to report BGP failures and ask permission to remediate. On Tue, May 13, 2014 at 3:33 PM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I realize that New Zealand is *not* in North America (hence NANOG), > but I figure that some global providers might be interested here. > > This sounds rather... dire (probably not the right word). > > "The new Telecommunications (Interception Capability and Security) Act > of 2013 is in effect in New Zealand and brings in several drastic > changes for ISPs, telcos and service providers. One of the country's > spy agencies, the GCSB, gets to decide on network equipment > procurement and design decisions (PDF), plus operators have to > register with the police and obtain security clearance for some staff. > Somewhat illogically, the NZ government pushed through the law > combining mandated communications interception capabilities for law > enforcement, with undefined network security requirements as decided > by the GCSB. All network operators are subject to the new law, > including local providers as well as the likes of Facebook, Google, > Microsoft, who have opposed it, saying the new statutes clash with > overseas privacy legislation." > > > http://yro.slashdot.org/story/14/05/13/005259/new-zealand-spy-agency-to-vet-network-builds-provider-staff > > FYI, > > - - ferg > > > > - -- > Paul Ferguson > VP Threat Intelligence, IID > PGP Public Key ID: 0x54DC85B2 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlNyHw4ACgkQKJasdVTchbLwDgD/WVHo2iTapJ90l8MRcwUZ5OQ7 > QfJ5cI1v4t2bUXZp1hQBAKHCP0hyxg6naGOzRLt/vHjgxXnl3+yiWoj0ENxQyIr9 > =0yLu > -----END PGP SIGNATURE----- > From fergdawgster at mykolab.com Tue May 13 13:49:09 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Tue, 13 May 2014 06:49:09 -0700 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: References: <53721F0E.6090904@mykolab.com> Message-ID: <537222D5.5050003@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 So is there just reluctant acceptance of this law, or is there push-back and plans to repeal, or...? I guess my question is something along the lines of "Are people just reluctantly accepting that government surveillance & micromanagement of private businesses/networks is a fact of life?" I am purposefully making a distinction here between the U.S. CALEA [1] and NSLs [2] and a NZ spy agency getting "...to decide on network equipment procurement and design decisions". The latter seems like a bit of an overreach? - - ferg [1] https://en.wikipedia.org/wiki/Communications_Assistance_for_Law_Enforcement_Act [2] https://en.wikipedia.org/wiki/National_security_letter On 5/13/2014 6:40 AM, George Michaelson wrote: > It got a pretty firefight discussion at the NZNOG. None of the ISPs > feel comfortable with it, but in avoiding a shoot-the-messenger > syndrome they tried to give good feedback to the reps from GCSB who > came to talk. Basically, a lot of post-act variations are expected > to clarify what changes do and do not have to be notified. > > There was a lot of bitter humour about calling them at 3am to > report BGP failures and ask permission to remediate. > > > On Tue, May 13, 2014 at 3:33 PM, Paul Ferguson > > > wrote: > > I realize that New Zealand is *not* in North America (hence > NANOG), but I figure that some global providers might be interested > here. > > This sounds rather... dire (probably not the right word). > > "The new Telecommunications (Interception Capability and Security) > Act of 2013 is in effect in New Zealand and brings in several > drastic changes for ISPs, telcos and service providers. One of the > country's spy agencies, the GCSB, gets to decide on network > equipment procurement and design decisions (PDF), plus operators > have to register with the police and obtain security clearance for > some staff. Somewhat illogically, the NZ government pushed through > the law combining mandated communications interception capabilities > for law enforcement, with undefined network security requirements > as decided by the GCSB. All network operators are subject to the > new law, including local providers as well as the likes of > Facebook, Google, Microsoft, who have opposed it, saying the new > statutes clash with overseas privacy legislation." > > http://yro.slashdot.org/story/14/05/13/005259/new-zealand-spy-agency-to-vet-network-builds-provider-staff > > FYI, > > - ferg > > > > > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNyItUACgkQKJasdVTchbL5GwEAxMtkr0W8oCtLTEdJDcdJHZTw hCGmG1ZTbWdb7NTEnwIA/j4YYMcN/gOQCQfABs1UIYFX30i/SewOkXYDOvfO6ReM =rAdv -----END PGP SIGNATURE----- From ikiris at gmail.com Tue May 13 13:51:56 2014 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 13 May 2014 08:51:56 -0500 Subject: level3 dia egress filtering? In-Reply-To: <201405131102.16055.mark.tinka@seacom.mu> References: <201405131102.16055.mark.tinka@seacom.mu> Message-ID: I would personally look at leaving Level 3 over that kind of response. I consider it basic service to throw a 1 line acl on an interface temporarily in exceptional circumstances. Transit guys can argue if they wish, but it won't change my expectations as a customer. Eventually I'll find a carrier that will offer reasonable service. I know it's why I kept UUnet back in the day, and dropped all my other providers at the time. Heck ATT even blackholed our traffic with a static null, so we were broken even after depeering for several hours until we could find someone who knew what a route was via their support. -Blake On Tue, May 13, 2014 at 4:02 AM, Mark Tinka wrote: > On Monday, May 12, 2014 11:58:20 PM Petter Bruland wrote: > >> We contacted Level3 a few weeks back, and were told that >> they do not provide any filtering service. I've not been >> able to confirm this from anyone else, besides the >> Level3 customer service rep we spoke with. > > We've received such requests from customers as well, and our > policy is we do not implement any kind of filtering, even > though it is restricted to just one customer. > > If the customer is looking for DoS/DDoS Mitigation services, > that is something else that can be offered. > > But as an ISP, filtering in the data plane that is not for > the protection of our core's control plane is not our deal. > It is not something I'd ask of my IP Transit provider, nor > support that they do. > > Mark. From contact at winterei.se Tue May 13 14:08:12 2014 From: contact at winterei.se (Paul S.) Date: Tue, 13 May 2014 23:08:12 +0900 Subject: level3 dia egress filtering? In-Reply-To: References: <201405131102.16055.mark.tinka@seacom.mu> Message-ID: <5372274C.9010305@winterei.se> You can't really have your cake, and eat it too. If this is a deal breaker for anyone, getting it in writing within the contract should be the most basic of steps to undertake. Asking beforehand will also actually let you know who will and won't do this, thus avoid surprises like these altogether. Otherwise, as Mark mentioned, they're entirely within the contractual agreement. On 5/13/2014 午後 10:51, Blake Dunlap wrote: > I would personally look at leaving Level 3 over that kind of response. > I consider it basic service to throw a 1 line acl on an interface > temporarily in exceptional circumstances. Transit guys can argue if > they wish, but it won't change my expectations as a customer. > Eventually I'll find a carrier that will offer reasonable service. > > I know it's why I kept UUnet back in the day, and dropped all my other > providers at the time. Heck ATT even blackholed our traffic with a > static null, so we were broken even after depeering for several hours > until we could find someone who knew what a route was via their > support. > > -Blake > > On Tue, May 13, 2014 at 4:02 AM, Mark Tinka wrote: >> On Monday, May 12, 2014 11:58:20 PM Petter Bruland wrote: >> >>> We contacted Level3 a few weeks back, and were told that >>> they do not provide any filtering service. I've not been >>> able to confirm this from anyone else, besides the >>> Level3 customer service rep we spoke with. >> We've received such requests from customers as well, and our >> policy is we do not implement any kind of filtering, even >> though it is restricted to just one customer. >> >> If the customer is looking for DoS/DDoS Mitigation services, >> that is something else that can be offered. >> >> But as an ISP, filtering in the data plane that is not for >> the protection of our core's control plane is not our deal. >> It is not something I'd ask of my IP Transit provider, nor >> support that they do. >> >> Mark. From ggm at algebras.org Tue May 13 14:09:35 2014 From: ggm at algebras.org (George Michaelson) Date: Tue, 13 May 2014 16:09:35 +0200 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: <537222D5.5050003@mykolab.com> References: <53721F0E.6090904@mykolab.com> <537222D5.5050003@mykolab.com> Message-ID: I can't speak to that Paul. I attended NZNOG as a guest, I'm from Australia. Others will have to say how the NZ industry is approaching this, I'd get it wrong if I tried! -G On Tue, May 13, 2014 at 3:49 PM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > So is there just reluctant acceptance of this law, or is there > push-back and plans to repeal, or...? > > I guess my question is something along the lines of "Are people just > reluctantly accepting that government surveillance & micromanagement > of private businesses/networks is a fact of life?" > > I am purposefully making a distinction here between the U.S. CALEA [1] > and NSLs [2] and a NZ spy agency getting "...to decide on network > equipment procurement and design decisions". > > The latter seems like a bit of an overreach? > > - - ferg > > > [1] > > https://en.wikipedia.org/wiki/Communications_Assistance_for_Law_Enforcement_Act > [2] https://en.wikipedia.org/wiki/National_security_letter > > > On 5/13/2014 6:40 AM, George Michaelson wrote: > > > It got a pretty firefight discussion at the NZNOG. None of the ISPs > > feel comfortable with it, but in avoiding a shoot-the-messenger > > syndrome they tried to give good feedback to the reps from GCSB who > > came to talk. Basically, a lot of post-act variations are expected > > to clarify what changes do and do not have to be notified. > > > > There was a lot of bitter humour about calling them at 3am to > > report BGP failures and ask permission to remediate. > > > > > > On Tue, May 13, 2014 at 3:33 PM, Paul Ferguson > > > > > wrote: > > > > I realize that New Zealand is *not* in North America (hence > > NANOG), but I figure that some global providers might be interested > > here. > > > > This sounds rather... dire (probably not the right word). > > > > "The new Telecommunications (Interception Capability and Security) > > Act of 2013 is in effect in New Zealand and brings in several > > drastic changes for ISPs, telcos and service providers. One of the > > country's spy agencies, the GCSB, gets to decide on network > > equipment procurement and design decisions (PDF), plus operators > > have to register with the police and obtain security clearance for > > some staff. Somewhat illogically, the NZ government pushed through > > the law combining mandated communications interception capabilities > > for law enforcement, with undefined network security requirements > > as decided by the GCSB. All network operators are subject to the > > new law, including local providers as well as the likes of > > Facebook, Google, Microsoft, who have opposed it, saying the new > > statutes clash with overseas privacy legislation." > > > > > http://yro.slashdot.org/story/14/05/13/005259/new-zealand-spy-agency-to-vet-network-builds-provider-staff > > > > FYI, > > > > - ferg > > > > > > > > > > > > - -- > Paul Ferguson > VP Threat Intelligence, IID > PGP Public Key ID: 0x54DC85B2 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlNyItUACgkQKJasdVTchbL5GwEAxMtkr0W8oCtLTEdJDcdJHZTw > hCGmG1ZTbWdb7NTEnwIA/j4YYMcN/gOQCQfABs1UIYFX30i/SewOkXYDOvfO6ReM > =rAdv > -----END PGP SIGNATURE----- > From mark.tinka at seacom.mu Tue May 13 14:10:13 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 13 May 2014 16:10:13 +0200 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: <537222D5.5050003@mykolab.com> References: <53721F0E.6090904@mykolab.com> <537222D5.5050003@mykolab.com> Message-ID: <201405131610.13762.mark.tinka@seacom.mu> On Tuesday, May 13, 2014 03:49:09 PM Paul Ferguson wrote: > I am purposefully making a distinction here between the > U.S. CALEA [1] and NSLs [2] and a NZ spy agency getting > "...to decide on network equipment procurement and > design decisions". > > The latter seems like a bit of an overreach? I have to agree. Telling me what to buy - that's another realm, even for me... 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 Tue May 13 14:21:38 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 13 May 2014 16:21:38 +0200 Subject: level3 dia egress filtering? In-Reply-To: References: <201405131102.16055.mark.tinka@seacom.mu> Message-ID: <201405131621.39212.mark.tinka@seacom.mu> On Tuesday, May 13, 2014 03:51:56 PM Blake Dunlap wrote: > I would personally look at leaving Level 3 over that kind > of response. I consider it basic service to throw a 1 > line acl on an interface temporarily in exceptional > circumstances. Transit guys can argue if they wish, but > it won't change my expectations as a customer. > Eventually I'll find a carrier that will offer > reasonable service. I suppose the question then becomes your and the ISP's interpretation of "exceptional circumstances". 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 jlewis at lewis.org Tue May 13 14:32:48 2014 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 13 May 2014 10:32:48 -0400 (EDT) Subject: NANOG 61 hotel Message-ID: The Hyatt appears to have filled up. :( Anyone have alternate hotel recommendations? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From hslabbert at stargate.ca Tue May 13 15:06:37 2014 From: hslabbert at stargate.ca (Hugo Slabbert) Date: Tue, 13 May 2014 08:06:37 -0700 Subject: NANOG 61 hotel In-Reply-To: References: Message-ID: <20140513150637.GD5268@stargate.ca> On Tue 2014-May-13 10:32:48 -0400, Jon Lewis wrote: >The Hyatt appears to have filled up. :( > >Anyone have alternate hotel recommendations? I put together a list when I was making my pitch to go down: ! --------------- ! Westin Bellevue http://www.starwoodhotels.com/westin/rates/rate.html?propertyID=1555 - $280/room/night ! ---------------- ! Marriot Bellevue (Courtyard Seattle Bellevue/Downtown) http://www.marriott.com/hotels/travel/bvudt-courtyard-seattle-bellevue-downtown/ - $269/room/night ! ---------------- ! Silver Cloud Inn http://www.silvercloud.com/bellevuedowntown/ - $229/room/night - 2 Queens/room ! ------------------------ ! La Residence Suite Hotel http://www.bellevuelodging.com/ - $169/room/night - 2x Queens - couple of blocks away These are all within 5-10 minutes walk of the Hyatt, IIRC and if Google Maps can be trusted. Rates at some of them seem a little different from when I looked before, e.g. the Westin now read as $303/night whereas e.g. Silver Cloud shows a single king room at $189/night. > >---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are >_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From owen at delong.com Tue May 13 16:12:44 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 13 May 2014 09:12:44 -0700 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: <53721F0E.6090904@mykolab.com> References: <53721F0E.6090904@mykolab.com> Message-ID: <22B7B879-F14D-464E-B937-A5B95227FC97@delong.com> Yep… If I had infrastructure in NZ, that would be enough to cause me to remove it. Owen On May 13, 2014, at 6:33 AM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I realize that New Zealand is *not* in North America (hence NANOG), > but I figure that some global providers might be interested here. > > This sounds rather... dire (probably not the right word). > > "The new Telecommunications (Interception Capability and Security) Act > of 2013 is in effect in New Zealand and brings in several drastic > changes for ISPs, telcos and service providers. One of the country's > spy agencies, the GCSB, gets to decide on network equipment > procurement and design decisions (PDF), plus operators have to > register with the police and obtain security clearance for some staff. > Somewhat illogically, the NZ government pushed through the law > combining mandated communications interception capabilities for law > enforcement, with undefined network security requirements as decided > by the GCSB. All network operators are subject to the new law, > including local providers as well as the likes of Facebook, Google, > Microsoft, who have opposed it, saying the new statutes clash with > overseas privacy legislation." > > http://yro.slashdot.org/story/14/05/13/005259/new-zealand-spy-agency-to-vet-network-builds-provider-staff > > FYI, > > - - ferg > > > > - -- > Paul Ferguson > VP Threat Intelligence, IID > PGP Public Key ID: 0x54DC85B2 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlNyHw4ACgkQKJasdVTchbLwDgD/WVHo2iTapJ90l8MRcwUZ5OQ7 > QfJ5cI1v4t2bUXZp1hQBAKHCP0hyxg6naGOzRLt/vHjgxXnl3+yiWoj0ENxQyIr9 > =0yLu > -----END PGP SIGNATURE----- From patrick at ianai.net Tue May 13 16:34:26 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 13 May 2014 12:34:26 -0400 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: <22B7B879-F14D-464E-B937-A5B95227FC97@delong.com> References: <53721F0E.6090904@mykolab.com> <22B7B879-F14D-464E-B937-A5B95227FC97@delong.com> Message-ID: <4BE296DF-8D1E-4688-BCDC-9EC2000DA3B9@ianai.net> Don't get me wrong, I'm not a fan of this. But at least they did it in the open, unlike the NSA (where you live). -- TTFN, patrick On May 13, 2014, at 12:12 , Owen DeLong wrote: > Yep… If I had infrastructure in NZ, that would be enough to cause me to remove it. > > Owen > > On May 13, 2014, at 6:33 AM, Paul Ferguson wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> I realize that New Zealand is *not* in North America (hence NANOG), >> but I figure that some global providers might be interested here. >> >> This sounds rather... dire (probably not the right word). >> >> "The new Telecommunications (Interception Capability and Security) Act >> of 2013 is in effect in New Zealand and brings in several drastic >> changes for ISPs, telcos and service providers. One of the country's >> spy agencies, the GCSB, gets to decide on network equipment >> procurement and design decisions (PDF), plus operators have to >> register with the police and obtain security clearance for some staff. >> Somewhat illogically, the NZ government pushed through the law >> combining mandated communications interception capabilities for law >> enforcement, with undefined network security requirements as decided >> by the GCSB. All network operators are subject to the new law, >> including local providers as well as the likes of Facebook, Google, >> Microsoft, who have opposed it, saying the new statutes clash with >> overseas privacy legislation." >> >> http://yro.slashdot.org/story/14/05/13/005259/new-zealand-spy-agency-to-vet-network-builds-provider-staff >> >> FYI, >> >> - - ferg >> >> >> >> - -- >> Paul Ferguson >> VP Threat Intelligence, IID >> PGP Public Key ID: 0x54DC85B2 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.22 (MingW32) >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iF4EAREIAAYFAlNyHw4ACgkQKJasdVTchbLwDgD/WVHo2iTapJ90l8MRcwUZ5OQ7 >> QfJ5cI1v4t2bUXZp1hQBAKHCP0hyxg6naGOzRLt/vHjgxXnl3+yiWoj0ENxQyIr9 >> =0yLu >> -----END PGP SIGNATURE----- From aaron at wholesaleinternet.net Tue May 13 16:40:18 2014 From: aaron at wholesaleinternet.net (Aaron) Date: Tue, 13 May 2014 11:40:18 -0500 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: <4BE296DF-8D1E-4688-BCDC-9EC2000DA3B9@ianai.net> References: <53721F0E.6090904@mykolab.com> <22B7B879-F14D-464E-B937-A5B95227FC97@delong.com> <4BE296DF-8D1E-4688-BCDC-9EC2000DA3B9@ianai.net> Message-ID: <53724AF2.9000705@wholesaleinternet.net> I live in the USA and have not been forced to register with the government as a network operator or have them vet my staff. On 5/13/2014 11:34 AM, Patrick W. Gilmore wrote: > Don't get me wrong, I'm not a fan of this. But at least they did it in the open, unlike the NSA (where you live). > -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================ From lists at mrqueue.com Tue May 13 00:25:15 2014 From: lists at mrqueue.com (Mr. Queue) Date: Mon, 12 May 2014 19:25:15 -0500 Subject: This is me venting.... OVH/lvl3 Message-ID: <5371666B.2030709@mrqueue.com> Almost a week of this now.. OVH/lvl3 at dal-1-6k. Thank you sir may I have another...... http://weathermap.ovh.net/usa From n-matsumoto at sakura.ad.jp Tue May 13 09:10:19 2014 From: n-matsumoto at sakura.ad.jp (Naoto MATSUMOTO) Date: Tue, 13 May 2014 18:10:19 +0900 Subject: FYI: Unbreakable VPN using Vyatta/VyOS -HOW TO- Message-ID: <20140513181019.B1C4.C42C3789@sakura.ad.jp> Hi all! We wrote TIPS memo about the Basic Idea for inter-cloud networking using Virtual Router (a.k.a Brocade Vyatta vRotuer and VyOS) with High Availability Concept. Please enjoy it if you interest in ;-) Unbreakable VPN using Vyatta/VyOS -HOW TO- http://slidesha.re/1lryGVU Best Regards, -- SAKURA Internet Inc. / Senior Researcher Naoto MATSUMOTO SAKURA Internet Research Center From snnijd at gmail.com Tue May 13 10:02:25 2014 From: snnijd at gmail.com (DjinnS C.) Date: Tue, 13 May 2014 12:02:25 +0200 Subject: CERT and ISO 27001 Message-ID: Hi, I'm searching a service/company doing continuos review of security alerts for various tools, software and hardware (Apache, PHP, Cisco IOS, Juniper JunOS, Netapp Ontap, etc ...). I think the right way is to use a CERT offering commercial services with daily notifications about a list of specifics choosen subjects. I found some companies with a commercial CERT offering this services: Lexsi, XMCO, Intrinsec. Do you know or use a service link this ? We need this for our implementation of ISO 27001 standard. Thank you in advance. Regards, -- Guillaume From coy.hile at coyhile.com Tue May 13 12:17:03 2014 From: coy.hile at coyhile.com (coy.hile at coyhile.com) Date: Tue, 13 May 2014 08:17:03 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality) In-Reply-To: <53720B3A.7010103@Opus1.COM> References: <53720B3A.7010103@Opus1.COM> Message-ID: <4E07565E-29D3-4BB2-B9BE-EE34310EF401@coyhile.com> It could be worse! Somebody might have thrown a 'v1' in there, too, Joel! Sent from my iPhone > On May 13, 2014, at 8:08, Joel M Snyder wrote: > > Shouldn't there be a rule against using "RIP" in the subject line of a > NANOG post? > > Every time I see that, a shudder goes down *my* spine. > > jms > > -- > Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 > Senior Partner, Opus One Phone: +1 520 324 0494 > jms at Opus1.COM http://www.opus1.com/jms From me at staticsafe.ca Tue May 13 17:33:30 2014 From: me at staticsafe.ca (staticsafe) Date: Tue, 13 May 2014 13:33:30 -0400 Subject: This is me venting.... OVH/lvl3 In-Reply-To: <5371666B.2030709@mrqueue.com> References: <5371666B.2030709@mrqueue.com> Message-ID: <5372576A.8080508@staticsafe.ca> On 5/12/2014 20:25, Mr. Queue wrote: > Almost a week of this now.. OVH/lvl3 at dal-1-6k. > > Thank you sir may I have another...... > > http://weathermap.ovh.net/usa > Looks fine. -- staticsafe https://asininetech.com From owen at delong.com Tue May 13 18:01:43 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 13 May 2014 11:01:43 -0700 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: <4BE296DF-8D1E-4688-BCDC-9EC2000DA3B9@ianai.net> References: <53721F0E.6090904@mykolab.com> <22B7B879-F14D-464E-B937-A5B95227FC97@delong.com> <4BE296DF-8D1E-4688-BCDC-9EC2000DA3B9@ianai.net> Message-ID: <8A9C15BC-F40A-4AE6-9D83-FDBD817F7528@delong.com> I didn’t see the NSA telling us what we had to buy are demanding advance approval rights on our maintenance procedures. Owen On May 13, 2014, at 9:34 AM, Patrick W. Gilmore wrote: > Don't get me wrong, I'm not a fan of this. But at least they did it in the open, unlike the NSA (where you live). > > -- > TTFN, > patrick > > On May 13, 2014, at 12:12 , Owen DeLong wrote: > >> Yep… If I had infrastructure in NZ, that would be enough to cause me to remove it. >> >> Owen >> >> On May 13, 2014, at 6:33 AM, Paul Ferguson wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> I realize that New Zealand is *not* in North America (hence NANOG), >>> but I figure that some global providers might be interested here. >>> >>> This sounds rather... dire (probably not the right word). >>> >>> "The new Telecommunications (Interception Capability and Security) Act >>> of 2013 is in effect in New Zealand and brings in several drastic >>> changes for ISPs, telcos and service providers. One of the country's >>> spy agencies, the GCSB, gets to decide on network equipment >>> procurement and design decisions (PDF), plus operators have to >>> register with the police and obtain security clearance for some staff. >>> Somewhat illogically, the NZ government pushed through the law >>> combining mandated communications interception capabilities for law >>> enforcement, with undefined network security requirements as decided >>> by the GCSB. All network operators are subject to the new law, >>> including local providers as well as the likes of Facebook, Google, >>> Microsoft, who have opposed it, saying the new statutes clash with >>> overseas privacy legislation." >>> >>> http://yro.slashdot.org/story/14/05/13/005259/new-zealand-spy-agency-to-vet-network-builds-provider-staff >>> >>> FYI, >>> >>> - - ferg >>> >>> >>> >>> - -- >>> Paul Ferguson >>> VP Threat Intelligence, IID >>> PGP Public Key ID: 0x54DC85B2 >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v2.0.22 (MingW32) >>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>> >>> iF4EAREIAAYFAlNyHw4ACgkQKJasdVTchbLwDgD/WVHo2iTapJ90l8MRcwUZ5OQ7 >>> QfJ5cI1v4t2bUXZp1hQBAKHCP0hyxg6naGOzRLt/vHjgxXnl3+yiWoj0ENxQyIr9 >>> =0yLu >>> -----END PGP SIGNATURE----- From lukasz at bromirski.net Tue May 13 20:15:32 2014 From: lukasz at bromirski.net (=?utf-8?Q?=C5=81ukasz_Bromirski?=) Date: Tue, 13 May 2014 22:15:32 +0200 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality) In-Reply-To: <4E07565E-29D3-4BB2-B9BE-EE34310EF401@coyhile.com> References: <53720B3A.7010103@Opus1.COM> <4E07565E-29D3-4BB2-B9BE-EE34310EF401@coyhile.com> Message-ID: <3D765DB6-8490-4FCD-BE89-3FD4A8FDC546@bromirski.net> On 13 May 2014, at 14:17, coy.hile at coyhile.com wrote: > It could be worse! Somebody might have thrown a 'v1' in there, too, Joel! Well - just imagine that network without mask. On public list. Horrible. Thankfully, we have civilization & stuff, so nothing like that couldn’t have had happened. -- "There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromirski at jabber.org about." John von Neumann | http://lukasz.bromirski.net -------------- 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 tom at ninjabadger.net Tue May 13 21:22:44 2014 From: tom at ninjabadger.net (Tom Hill) Date: Tue, 13 May 2014 22:22:44 +0100 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: <8A9C15BC-F40A-4AE6-9D83-FDBD817F7528@delong.com> References: <53721F0E.6090904@mykolab.com> <22B7B879-F14D-464E-B937-A5B95227FC97@delong.com> <4BE296DF-8D1E-4688-BCDC-9EC2000DA3B9@ianai.net> <8A9C15BC-F40A-4AE6-9D83-FDBD817F7528@delong.com> Message-ID: <53728D24.8060008@ninjabadger.net> On 13/05/14 19:01, Owen DeLong wrote: > I didn’t see the NSA telling us what we had to buy are demanding > advance approval rights on our maintenance procedures. Because they didn't (don't) need to...? Tom From patrick at ianai.net Tue May 13 21:25:06 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 13 May 2014 17:25:06 -0400 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: <8A9C15BC-F40A-4AE6-9D83-FDBD817F7528@delong.com> References: <53721F0E.6090904@mykolab.com> <22B7B879-F14D-464E-B937-A5B95227FC97@delong.com> <4BE296DF-8D1E-4688-BCDC-9EC2000DA3B9@ianai.net> <8A9C15BC-F40A-4AE6-9D83-FDBD817F7528@delong.com> Message-ID: <1D59F949-7A80-48E7-8586-9A1DF58D6260@ianai.net> Exactly. They just broke in and left a trail of open doors behind. Again, not saying either is good, just saying at least NZ is being "above board". -- TTFN, patrick On May 13, 2014, at 14:01 , Owen DeLong wrote: > I didn’t see the NSA telling us what we had to buy are demanding advance approval rights on our maintenance procedures. > > Owen > > On May 13, 2014, at 9:34 AM, Patrick W. Gilmore wrote: > >> Don't get me wrong, I'm not a fan of this. But at least they did it in the open, unlike the NSA (where you live). >> >> -- >> TTFN, >> patrick >> >> On May 13, 2014, at 12:12 , Owen DeLong wrote: >> >>> Yep… If I had infrastructure in NZ, that would be enough to cause me to remove it. >>> >>> Owen >>> >>> On May 13, 2014, at 6:33 AM, Paul Ferguson wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>> >>>> I realize that New Zealand is *not* in North America (hence NANOG), >>>> but I figure that some global providers might be interested here. >>>> >>>> This sounds rather... dire (probably not the right word). >>>> >>>> "The new Telecommunications (Interception Capability and Security) Act >>>> of 2013 is in effect in New Zealand and brings in several drastic >>>> changes for ISPs, telcos and service providers. One of the country's >>>> spy agencies, the GCSB, gets to decide on network equipment >>>> procurement and design decisions (PDF), plus operators have to >>>> register with the police and obtain security clearance for some staff. >>>> Somewhat illogically, the NZ government pushed through the law >>>> combining mandated communications interception capabilities for law >>>> enforcement, with undefined network security requirements as decided >>>> by the GCSB. All network operators are subject to the new law, >>>> including local providers as well as the likes of Facebook, Google, >>>> Microsoft, who have opposed it, saying the new statutes clash with >>>> overseas privacy legislation." >>>> >>>> http://yro.slashdot.org/story/14/05/13/005259/new-zealand-spy-agency-to-vet-network-builds-provider-staff >>>> >>>> FYI, >>>> >>>> - - ferg >>>> >>>> >>>> >>>> - -- >>>> Paul Ferguson >>>> VP Threat Intelligence, IID >>>> PGP Public Key ID: 0x54DC85B2 >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v2.0.22 (MingW32) >>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>> >>>> iF4EAREIAAYFAlNyHw4ACgkQKJasdVTchbLwDgD/WVHo2iTapJ90l8MRcwUZ5OQ7 >>>> QfJ5cI1v4t2bUXZp1hQBAKHCP0hyxg6naGOzRLt/vHjgxXnl3+yiWoj0ENxQyIr9 >>>> =0yLu >>>> -----END PGP SIGNATURE----- From tony at wicks.co.nz Tue May 13 21:44:08 2014 From: tony at wicks.co.nz (Tony Wicks) Date: Wed, 14 May 2014 09:44:08 +1200 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: References: <53721F0E.6090904@mykolab.com> <537222D5.5050003@mykolab.com> Message-ID: <004401cf6ef4$784b4c70$68e1e550$@wicks.co.nz> >To: Paul Ferguson >Cc: NANOG >Subject: Re: New Zealand Spy Agency To Vet Network Builds, Provider Staff > >I can't speak to that Paul. I attended NZNOG as a guest, I'm from Australia. Others will have to say how the NZ industry is approaching this, I'd get it wrong if I tried! The industry in New Zealand is responding with "Nobody listened to us and we have no damn choice but to do what the government orders us to do". The general public is completely unaware of what has just happened and as long as there is still beer in the fridge and the game on TV they don't seem to give much of a toss. From tony at wicks.co.nz Tue May 13 21:47:46 2014 From: tony at wicks.co.nz (Tony Wicks) Date: Wed, 14 May 2014 09:47:46 +1200 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: <8A9C15BC-F40A-4AE6-9D83-FDBD817F7528@delong.com> References: <53721F0E.6090904@mykolab.com> <22B7B879-F14D-464E-B937-A5B95227FC97@delong.com> <4BE296DF-8D1E-4688-BCDC-9EC2000DA3B9@ianai.net> <8A9C15BC-F40A-4AE6-9D83-FDBD817F7528@delong.com> Message-ID: <006a01cf6ef4$faade650$f009b2f0$@wicks.co.nz> >Cc: NANOG list >Subject: Re: New Zealand Spy Agency To Vet Network Builds, Provider Staff > >I didn't see the NSA telling us what we had to buy are demanding advance approval rights on our maintenance procedures. > >Owen Try to get approval to land a submarine cable onto US soil using Huawei DWDM kit and then come back to us. From patrick at ianai.net Tue May 13 21:52:58 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 13 May 2014 17:52:58 -0400 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: <006a01cf6ef4$faade650$f009b2f0$@wicks.co.nz> References: <53721F0E.6090904@mykolab.com> <22B7B879-F14D-464E-B937-A5B95227FC97@delong.com> <4BE296DF-8D1E-4688-BCDC-9EC2000DA3B9@ianai.net> <8A9C15BC-F40A-4AE6-9D83-FDBD817F7528@delong.com> <006a01cf6ef4$faade650$f009b2f0$@wicks.co.nz> Message-ID: <8BD160DC-0E18-4D1F-8244-17E79FE1E338@ianai.net> On May 13, 2014, at 17:47 , Tony Wicks wrote: >> Cc: NANOG list >> Subject: Re: New Zealand Spy Agency To Vet Network Builds, Provider Staff >> >> I didn't see the NSA telling us what we had to buy are demanding advance >> approval rights on our maintenance procedures. >> >> Owen > > Try to get approval to land a submarine cable onto US soil using Huawei DWDM > kit and then come back to us. Hey, now, that's not fair. The NSA is just doing what any large player who dominates their space does - try to block out the competition! Copy/pasting from a friend of mine (he can out himself if he likes): http://www.theguardian.com/books/2014/may/12/glenn-greenwald-nsa-tampers-us-internet-routers-snowden - But while American companies were being warned away from supposedly untrustworthy Chinese routers, foreign organisations would have been well advised to beware of American-made ones. A June 2010 report from the head of the NSA's Access and Target Development department is shockingly explicit. The NSA routinely receives or intercepts routers, servers, and other computer network devices being exported from the US before they are delivered to the international customers. - The agency then implants backdoor surveillance tools, repackages the devices with a factory seal, and sends them on. The NSA thus gains access to entire networks and all their users. The document gleefully observes that some "SIGINT tradecraft is very hands-on (literally!)". - Eventually, the implanted device connects back to the NSA. The report continues: "In one recent case, after several months a beacon implanted through supply-chain interdiction called back to the NSA covert infrastructure. This call back provided us access to further exploit the device and survey the network." - It is quite possible that Chinese firms are implanting surveillance mechanisms in their network devices. But the US is certainly doing the same. - Warning the world about Chinese surveillance could have been one of the motives behind the US government's claims that Chinese devices cannot be trusted. But an equally important motive seems to have been preventing Chinese devices from supplanting American-made ones, which would have limited the NSA's own reach. In other words, Chinese routers and servers represent not only economic competition but also surveillance competition. Makes you proud to be an UH-mer-e-kan, dunnit? -- TTFN, patrick From zaid at zaidali.com Tue May 13 22:24:06 2014 From: zaid at zaidali.com (Zaid Ali Kahn) Date: Tue, 13 May 2014 17:24:06 -0500 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: <8BD160DC-0E18-4D1F-8244-17E79FE1E338@ianai.net> References: <53721F0E.6090904@mykolab.com> <22B7B879-F14D-464E-B937-A5B95227FC97@delong.com> <4BE296DF-8D1E-4688-BCDC-9EC2000DA3B9@ianai.net> <8A9C15BC-F40A-4AE6-9D83-FDBD817F7528@delong.com> <006a01cf6ef4$faade650$f009b2f0$@wicks.co.nz> <8BD160DC-0E18-4D1F-8244-17E79FE1E338@ianai.net> Message-ID: On May 13, 2014, at 4:52 PM, Patrick W. Gilmore wrote: > > - Warning the world about Chinese surveillance could have been one of > the motives behind the US government's claims that Chinese devices > cannot be trusted. But an equally important motive seems to have been > preventing Chinese devices from supplanting American-made ones, which > would have limited the NSA's own reach. In other words, Chinese > routers and servers represent not only economic competition but also > surveillance competition. Case in point on Sprint/Softbank merger http://www.theverge.com/2013/3/28/4155714/us-wants-sprint-softbank-deal-to-avoid-chinese-network-equipment/in/3252625 Should we as a community look at Open Hardware when we start to lose trust in vendors and governments? Can we make boards/ASIC/FPGA commodity enough to scale? Zaid -------------- 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 jared at puck.nether.net Tue May 13 22:28:40 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 13 May 2014 18:28:40 -0400 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: References: <53721F0E.6090904@mykolab.com> <22B7B879-F14D-464E-B937-A5B95227FC97@delong.com> <4BE296DF-8D1E-4688-BCDC-9EC2000DA3B9@ianai.net> <8A9C15BC-F40A-4AE6-9D83-FDBD817F7528@delong.com> <006a01cf6ef4$faade650$f009b2f0$@wicks.co.nz> <8BD160DC-0E18-4D1F-8244-17E79FE1E338@ianai.net> Message-ID: <7B66F8EB-2288-4F5A-8562-6DB7B3B09B1C@puck.nether.net> On May 13, 2014, at 6:24 PM, Zaid Ali Kahn wrote: > Case in point on Sprint/Softbank merger http://www.theverge.com/2013/3/28/4155714/us-wants-sprint-softbank-deal-to-avoid-chinese-network-equipment/in/3252625 Any such deal would also be subject to CFIUS and mandatory 5-year reviews as well. If you think your PII isn’t shared with the Government as part of this, your blinders are on. - Jared From kyle at wirestar.net Tue May 13 21:37:00 2014 From: kyle at wirestar.net (Kyle Leissner) Date: Tue, 13 May 2014 21:37:00 +0000 Subject: IPAM DDI Software, Subscriber Management, CMDB and Per Customer VLANs Message-ID: <5bffbb5f2f0942e58c899fa3a0592bcf@BY2PR06MB092.namprd06.prod.outlook.com> I would like recommendations on the following software/hardware elements required to run an access network. Assume you are building a greenfield network using a combination of access technologies such as DSL, GPON, AE, and WiFi. IPAM / DDI Solution: Needs full support for IPv6, Customer VLANs, RFC 1918, VRF, Overlapping Address Space, integration with DNS, DNSSEC, Integration with DHCP, and integration with ARIN. Looks like there are both open source and commercial solutions available according to old NANOG posts. Which cater to service providers? Who are the leaders in this space? Does anyone have experience with dealing with multiple vendors? Subscriber Management/BRAS/BNG: Redback was the big player back in the day, but I believe they are no longer. Juniper has their Subscriber Management feature pack on their MX routers, and Cisco has their Broadband Network Gateway on their ASR routers. Besides these two vendors I am not sure what other solutions are out there. I believe both of these solutions communicate upstream to external radius servers and DHCP servers. Is anyone using Subscriber Management, or is there another way of doing it? CMDB: A centralized database to keep track of all assets within the network would be nice. I would assume this would need to tie in with the IPAM solution and billing systems. I would also like to hear thoughts on the per customer VLAN model. Most of the whitepapers recommend a per customer VLAN for greenfield networks, but that seems like a management and documentation nightmare. The systems described above must be able to manage and maintain per customer VLANs in an automated fashion for this approach to work and scale. If you had your choice starting from the ground up how would you deploy an access network today? From DStaal at usa.net Wed May 14 02:50:21 2014 From: DStaal at usa.net (Daniel Staal) Date: Tue, 13 May 2014 22:50:21 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <5370C664.5050405@foobar.org> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> Message-ID: <68E386555FFBD7352D8642B4@[192.168.1.50]> --As of May 12, 2014 3:02:28 PM +0200, Nick Hilliard is alleged to have said: > On 10/05/2014 22:34, Randy Bush wrote: >> imiho think vi hart has it down simply and understandable by a lay >> person. . my >> friends in last mile providers disagree. i take that as a good sign. > > Vi's analogy is wrong on a subtle but important point. In the analogy, > the delivery company needs to get a bunch of new trucks to handle the > delivery but as the customer is paying for each delivery instances, the > delivery company's costs are covered by increased end-user charges. > > In the net neutrality debate, the last mile service providers are in a > position where they need to upgrade their access networks, but the > end-user pricing is not necessarily keeping pace. --As for the rest, it is mine. So the fact that the USA has higher prices than many other countries, for slower service, and those prices are rising (mine went up three times in the past year, including them starting to charge rent for a cable modem I bought when I signed up, for the same service) doesn't mean anything? Or the fact that they are one of the most profitable market segments in the country? They have the money. They have the ability to get more money. *They see no reason to spend money making customers happy.* They can make more profit without it. Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --------------------------------------------------------------- From jfmezei_nanog at vaxination.ca Wed May 14 07:04:11 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 14 May 2014 03:04:11 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <68E386555FFBD7352D8642B4@[192.168.1.50]> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@[192.168.1.50]> Message-ID: <5373156B.8000005@vaxination.ca> On 14-05-13 22:50, Daniel Staal wrote: > They have the money. They have the ability to get more money. *They see > no reason to spend money making customers happy.* They can make more > profit without it. There is the issue of control over the market. But also the pressure from shareholders for continued growth. The problem with the internet is that while it had promises of wild growth in the 90s and 00s, once penetration reaches a certain level, growth stabilizes. When you combine this with threath to large incumbents's media and media distribution endeavours by the likes of Netflix (and cat videos on Youtube), large incumbents start thinking about how they will be able to continue to grow revenus/profits when customers will shift spending to vspecialty channels/cableTV to Netflix and customer growth will not compensate. So they seek new sources of revenues, and/or attempt to thwart competition any way they can. The current trend is to "if you can't fight them, jon them" where cablecos start to include the Netflix app into their proprietary set-top boxes. The idea is that you at least make the customer continue to use your box and your remote control which makes it easier for them to switch between netflix and legacy TV. Would be interesting to see if those cable companies that are agreeing to add the Netflix app onto their proprietary STBs also play peering capacity games to degrade the service or not. From lists at mrqueue.com Tue May 13 23:41:12 2014 From: lists at mrqueue.com (Mr. Queue) Date: Tue, 13 May 2014 18:41:12 -0500 Subject: This is me venting.... OVH/lvl3 In-Reply-To: <5371666B.2030709@mrqueue.com> References: <5371666B.2030709@mrqueue.com> Message-ID: <5372AD98.7000009@mrqueue.com> On 5/12/2014 7:25 PM, Mr. Queue wrote: > Almost a week of this now.. OVH/lvl3 at dal-1-6k. > > Thank you sir may I have another...... > > http://weathermap.ovh.net/usa > Sorry about that, it was my first mail to the list so it was held over a bit for moderation. However, it's back at it and I've grabbed a couple of screenshots. http://mrqueue.com/images/weathermap_usa.png http://mrqueue.com/images/weathermap_usa.-crop.png As like yesterday, right about the same time. Hopefully someone is actively working on a solution. Regards, From mark.tinka at seacom.mu Wed May 14 07:29:30 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 14 May 2014 09:29:30 +0200 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <5373156B.8000005@vaxination.ca> References: <536BBC62.4070805@KingsMountain.com> <68E386555FFBD7352D8642B4@[192.168.1.50]> <5373156B.8000005@vaxination.ca> Message-ID: <201405140929.30945.mark.tinka@seacom.mu> On Wednesday, May 14, 2014 09:04:11 AM Jean-Francois Mezei wrote: > The problem with the internet is that while it had > promises of wild growth in the 90s and 00s, once > penetration reaches a certain level, growth stabilizes. That depends on your point-of-view and/or interpretation of "growth". In the last several years, networks have been adding more capacity than they have customers. I suppose, for a number of operators now, growth is in bandwidth, which is non- linear to customer growth. 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 mpetach at netflight.com Wed May 14 08:11:30 2014 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 14 May 2014 01:11:30 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> Message-ID: On Sat, May 10, 2014 at 8:04 AM, Rick Astley wrote: > [...] > The reality is an increasingly directly peered Internet doesn't sit well if > you are in the business of being the middle man. Now if you will, why do > transit companies themselves charge content companies to deliver bits? How > is it fair to be in the business of charging companies to receive their > bits and hand them to a settlement free peer on the hook to deliver them, > but not fair for content to just bypass the transit company and enter a > paid peering agreement with the company delivering the bits? In this case > paid peering is mutually beneficial to both companies involved and is > typically cheaper for the content company than it would cost to send that > traffic over transit. > What you're missing is that the transit provider is selling full routes. The access network is selling paid peering, which is a tiny fraction of the routes. If I pay transit provider X $10/mb (i know, not realistic, but it makes my math work) to reach the entire internet, it might seem reasonable to pay access network C $5/mb to hand traffic to them, and bypass the transit provider, avoiding potentially congested links. But then access network A decides they want to cut out the middleman as well--so they do the same thing, run their ports to transit provider X hot; to avoid that, I can pay the cheap price of $4/mb to reach them. Now access networks F and D want to do the same thing; their prices for their routes are $4 and $5/mb, respectively. Finally, little access provider T wants in at $2/mb for their routes. So, at the end of the week, I *had* been paying $10/mb to send traffic through transit to reach the whole rest of the internet. Now, I'm paying $5+$4+$4+$5+$2, or $30, and I don't have a full set of routes, so I've still got to keep paying the transit provider as well at $10. Depending on port counts, locations, and commit volumes, your "typically cheaper for the content company than it would cost to send that traffic over transit" has flown completely out the window. It could even end up being many times more expensive to handle the traffic that way. In order for the costs to work out, you'd really need to apply a formula along the lines of C(n) <= T(n) * C(t) where T(n) =fraction of traffic volume destined for access network X C(t)=cost of transit (ie, full routes, reachability to the entire internet) C(n)=cost of paid peering to access network X So, if you're an access network and want to charge for paid peering, and you represent 1/20th of my traffic, there's no reason for me to pay more than 1/20th of my transit cost for your routes; otherwise, it's more cost effective for me as a business to continue to pay a transit provider. I'm constantly amazed at how access networks think they can charge 2/3 the price of full transit for just their routes when they represent less than 1/10th of the overall traffic volume. The math just doesn't work out. It's nothing about being tier 1, or bigger than someone else; it's just math, pure and simple. Matt (currently not being paid by anyone for my time or thoughts, so take what I'm saying as purely my own thoughts on the matter, nothing more) From rdobbins at arbor.net Wed May 14 09:27:57 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 14 May 2014 16:27:57 +0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> Message-ID: <566F1D41-74BD-41B4-AFE3-D988747D4911@arbor.net> On May 14, 2014, at 3:11 PM, Matthew Petach wrote: > I'm constantly amazed at how access networks think they can charge 2/3 the price of full transit for just their routes when they represent less than 1/10th of the overall traffic volume. My guess is that from the perspective of the access providers, they aren't selling traffic volume or routes, per se - their view is that they're selling privileged engagement with large numbers of potentially monetizable individual prospects. Note that I'm neither endorsing nor disputing this perspective, just mooting it as a possible explanation. Are there any real-world models out there for revenue-sharing between app/content providers and access networks which would eliminate or reduce 'paid peering' (an alternate way to think of it is as 'delimited transit', another oxymoron like 'paid peering', but with a slightly different emphasis) monetary exchanges? ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From mark.tinka at seacom.mu Wed May 14 09:28:55 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 14 May 2014 11:28:55 +0200 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> Message-ID: <201405141128.56037.mark.tinka@seacom.mu> On Wednesday, May 14, 2014 10:11:30 AM Matthew Petach wrote: > I'm constantly amazed at how access networks > think they can charge 2/3 the price of full transit > for just their routes when they represent less than > 1/10th of the overall traffic volume. The math just > doesn't work out. It's nothing about being tier 1, or > bigger than someone else; it's just math, pure and > simple. I suppose because (in the context of Access networks) the most interested folk that would be even willing to consider paying them for their routes are the content owners. As a fellow middleman with no content on the backbone, I'd have little interest in paying an Access network for their routes, if it's cheaper to get to them through an existing peer or 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 Thijs.Stuurman at is.nl Wed May 14 09:41:47 2014 From: Thijs.Stuurman at is.nl (Thijs Stuurman) Date: Wed, 14 May 2014 09:41:47 +0000 Subject: CERT and ISO 27001 In-Reply-To: References: Message-ID: Usually your system and network admins receive those themselves as part of either support contracts or simply by registering for the appropriate notification/mailing list. Perhaps these links will help you out as well: http://cve.mitre.org/about/index.html http://cve.mitre.org/compatible/compatible.html http://nvd.nist.gov/ Kind regards / Vriendelijke groet, IS Group Thijs Stuurman Powered by results. Wielingenstraat 8 | T +31 (0)299 476 185 1441 ZR Purmerend | F +31 (0)299 476 288 http://www.is.nl | KvK Hoorn 36049256 IS Group is ISO 9001:2008, ISO/IEC 27001:2005, ISO 20.000-1:2005, ISAE 3402 en PCI DSS certified. -----Oorspronkelijk bericht----- Van: NANOG [mailto:nanog-bounces at nanog.org] Namens DjinnS C. Verzonden: Tuesday, May 13, 2014 12:02 PM Aan: nanog at nanog.org Onderwerp: CERT and ISO 27001 Hi, I'm searching a service/company doing continuos review of security alerts for various tools, software and hardware (Apache, PHP, Cisco IOS, Juniper JunOS, Netapp Ontap, etc ...). I think the right way is to use a CERT offering commercial services with daily notifications about a list of specifics choosen subjects. I found some companies with a commercial CERT offering this services: Lexsi, XMCO, Intrinsec. Do you know or use a service link this ? We need this for our implementation of ISO 27001 standard. Thank you in advance. Regards, -- Guillaume From ahebert at pubnix.net Wed May 14 11:33:32 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 14 May 2014 07:33:32 -0400 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: <53724AF2.9000705@wholesaleinternet.net> References: <53721F0E.6090904@mykolab.com> <22B7B879-F14D-464E-B937-A5B95227FC97@delong.com> <4BE296DF-8D1E-4688-BCDC-9EC2000DA3B9@ianai.net> <53724AF2.9000705@wholesaleinternet.net> Message-ID: <5373548C.6000900@pubnix.net> They already have all the information and did it for you. You are just not aware of 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 05/13/14 12:40, Aaron wrote: > I live in the USA and have not been forced to register with the > government as a network operator or have them vet my staff. > > On 5/13/2014 11:34 AM, Patrick W. Gilmore wrote: >> Don't get me wrong, I'm not a fan of this. But at least they did it >> in the open, unlike the NSA (where you live). >> > From mark.tinka at seacom.mu Wed May 14 12:47:10 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 14 May 2014 14:47:10 +0200 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: <566F1D41-74BD-41B4-AFE3-D988747D4911@arbor.net> References: <536BBC62.4070805@KingsMountain.com> <566F1D41-74BD-41B4-AFE3-D988747D4911@arbor.net> Message-ID: <201405141447.11250.mark.tinka@seacom.mu> On Wednesday, May 14, 2014 11:27:57 AM Roland Dobbins wrote: > Are there any real-world models out there for > revenue-sharing between app/content providers and access > networks which would eliminate or reduce 'paid peering' > (an alternate way to think of it is as 'delimited > transit', another oxymoron like 'paid peering', but with > a slightly different emphasis) monetary exchanges? I think so, but none will cop to it publicly :-). 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 owen at delong.com Wed May 14 13:35:41 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 14 May 2014 06:35:41 -0700 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: <006a01cf6ef4$faade650$f009b2f0$@wicks.co.nz> References: <53721F0E.6090904@mykolab.com> <22B7B879-F14D-464E-B937-A5B95227FC97@delong.com> <4BE296DF-8D1E-4688-BCDC-9EC2000DA3B9@ianai.net> <8A9C15BC-F40A-4AE6-9D83-FDBD817F7528@delong.com> <006a01cf6ef4$faade650$f009b2f0$@wicks.co.nz> Message-ID: <504BEA38-64A4-43F6-A922-26294EA3DD02@delong.com> On May 13, 2014, at 2:47 PM, Tony Wicks wrote: >> Cc: NANOG list >> Subject: Re: New Zealand Spy Agency To Vet Network Builds, Provider Staff >> >> I didn't see the NSA telling us what we had to buy are demanding advance > approval rights on our maintenance procedures. >> >> Owen > > Try to get approval to land a submarine cable onto US soil using Huawei DWDM > kit and then come back to us. Last I looked, you were free to change out the kit on your submarine cable to anything you wanted once the cable was landed. Owen From owen at delong.com Wed May 14 13:34:51 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 14 May 2014 06:34:51 -0700 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: <1D59F949-7A80-48E7-8586-9A1DF58D6260@ianai.net> References: <53721F0E.6090904@mykolab.com> <22B7B879-F14D-464E-B937-A5B95227FC97@delong.com> <4BE296DF-8D1E-4688-BCDC-9EC2000DA3B9@ianai.net> <8A9C15BC-F40A-4AE6-9D83-FDBD817F7528@delong.com> <1D59F949-7A80-48E7-8586-9A1DF58D6260@ianai.net> Message-ID: <03AE478B-0133-4018-8665-DB7BAFE547DC@delong.com> While I applaud NZ being open and honest about it, I do think that they have gone quite a bit further than the NSA and that their proposal is far more damaging. Owen On May 13, 2014, at 2:25 PM, Patrick W. Gilmore wrote: > Exactly. They just broke in and left a trail of open doors behind. > > Again, not saying either is good, just saying at least NZ is being "above board". > > -- > TTFN, > patrick > > On May 13, 2014, at 14:01 , Owen DeLong wrote: > >> I didn’t see the NSA telling us what we had to buy are demanding advance approval rights on our maintenance procedures. >> >> Owen >> >> On May 13, 2014, at 9:34 AM, Patrick W. Gilmore wrote: >> >>> Don't get me wrong, I'm not a fan of this. But at least they did it in the open, unlike the NSA (where you live). >>> >>> -- >>> TTFN, >>> patrick >>> >>> On May 13, 2014, at 12:12 , Owen DeLong wrote: >>> >>>> Yep… If I had infrastructure in NZ, that would be enough to cause me to remove it. >>>> >>>> Owen >>>> >>>> On May 13, 2014, at 6:33 AM, Paul Ferguson wrote: >>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA256 >>>>> >>>>> I realize that New Zealand is *not* in North America (hence NANOG), >>>>> but I figure that some global providers might be interested here. >>>>> >>>>> This sounds rather... dire (probably not the right word). >>>>> >>>>> "The new Telecommunications (Interception Capability and Security) Act >>>>> of 2013 is in effect in New Zealand and brings in several drastic >>>>> changes for ISPs, telcos and service providers. One of the country's >>>>> spy agencies, the GCSB, gets to decide on network equipment >>>>> procurement and design decisions (PDF), plus operators have to >>>>> register with the police and obtain security clearance for some staff. >>>>> Somewhat illogically, the NZ government pushed through the law >>>>> combining mandated communications interception capabilities for law >>>>> enforcement, with undefined network security requirements as decided >>>>> by the GCSB. All network operators are subject to the new law, >>>>> including local providers as well as the likes of Facebook, Google, >>>>> Microsoft, who have opposed it, saying the new statutes clash with >>>>> overseas privacy legislation." >>>>> >>>>> http://yro.slashdot.org/story/14/05/13/005259/new-zealand-spy-agency-to-vet-network-builds-provider-staff >>>>> >>>>> FYI, >>>>> >>>>> - - ferg >>>>> >>>>> >>>>> >>>>> - -- >>>>> Paul Ferguson >>>>> VP Threat Intelligence, IID >>>>> PGP Public Key ID: 0x54DC85B2 >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG v2.0.22 (MingW32) >>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>>> >>>>> iF4EAREIAAYFAlNyHw4ACgkQKJasdVTchbLwDgD/WVHo2iTapJ90l8MRcwUZ5OQ7 >>>>> QfJ5cI1v4t2bUXZp1hQBAKHCP0hyxg6naGOzRLt/vHjgxXnl3+yiWoj0ENxQyIr9 >>>>> =0yLu >>>>> -----END PGP SIGNATURE----- From matthew at matthew.at Wed May 14 13:50:42 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 14 May 2014 06:50:42 -0700 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: <8A9C15BC-F40A-4AE6-9D83-FDBD817F7528@delong.com> References: <53721F0E.6090904@mykolab.com> <22B7B879-F14D-464E-B937-A5B95227FC97@delong.com> <4BE296DF-8D1E-4688-BCDC-9EC2000DA3B9@ianai.net> <8A9C15BC-F40A-4AE6-9D83-FDBD817F7528@delong.com> Message-ID: <2BCAFD91-9936-4AF4-8349-088708A2F60A@matthew.at> No, they just intercept whatever gear you do purchase before it gets to your loading dock and then seal it back up with their modifications. Matthew Kaufman (Sent from my iPhone) > On May 13, 2014, at 11:01 AM, Owen DeLong wrote: > > I didn’t see the NSA telling us what we had to buy are demanding advance approval rights on our maintenance procedures. > > Owen > >> On May 13, 2014, at 9:34 AM, Patrick W. Gilmore wrote: >> >> Don't get me wrong, I'm not a fan of this. But at least they did it in the open, unlike the NSA (where you live). >> >> -- >> TTFN, >> patrick >> >>> On May 13, 2014, at 12:12 , Owen DeLong wrote: >>> >>> Yep… If I had infrastructure in NZ, that would be enough to cause me to remove it. >>> >>> Owen >>> >>>> On May 13, 2014, at 6:33 AM, Paul Ferguson wrote: >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>> >>>> I realize that New Zealand is *not* in North America (hence NANOG), >>>> but I figure that some global providers might be interested here. >>>> >>>> This sounds rather... dire (probably not the right word). >>>> >>>> "The new Telecommunications (Interception Capability and Security) Act >>>> of 2013 is in effect in New Zealand and brings in several drastic >>>> changes for ISPs, telcos and service providers. One of the country's >>>> spy agencies, the GCSB, gets to decide on network equipment >>>> procurement and design decisions (PDF), plus operators have to >>>> register with the police and obtain security clearance for some staff. >>>> Somewhat illogically, the NZ government pushed through the law >>>> combining mandated communications interception capabilities for law >>>> enforcement, with undefined network security requirements as decided >>>> by the GCSB. All network operators are subject to the new law, >>>> including local providers as well as the likes of Facebook, Google, >>>> Microsoft, who have opposed it, saying the new statutes clash with >>>> overseas privacy legislation." >>>> >>>> http://yro.slashdot.org/story/14/05/13/005259/new-zealand-spy-agency-to-vet-network-builds-provider-staff >>>> >>>> FYI, >>>> >>>> - - ferg >>>> >>>> >>>> >>>> - -- >>>> Paul Ferguson >>>> VP Threat Intelligence, IID >>>> PGP Public Key ID: 0x54DC85B2 >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v2.0.22 (MingW32) >>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>> >>>> iF4EAREIAAYFAlNyHw4ACgkQKJasdVTchbLwDgD/WVHo2iTapJ90l8MRcwUZ5OQ7 >>>> QfJ5cI1v4t2bUXZp1hQBAKHCP0hyxg6naGOzRLt/vHjgxXnl3+yiWoj0ENxQyIr9 >>>> =0yLu >>>> -----END PGP SIGNATURE----- > From charles at thefnf.org Wed May 14 14:23:21 2014 From: charles at thefnf.org (charles at thefnf.org) Date: Wed, 14 May 2014 09:23:21 -0500 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <5373156B.8000005@vaxination.ca> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@[192.168.1.50]> <5373156B.8000005@vaxination.ca> Message-ID: On 2014-05-14 02:04, Jean-Francois Mezei wrote: > On 14-05-13 22:50, Daniel Staal wrote: > >> They have the money. They have the ability to get more money. *They >> see >> no reason to spend money making customers happy.* They can make more >> profit without it. > > There is the issue of control over the market. But also the pressure > from shareholders for continued growth. Yes. That is true. Except that it's not. How do service providers grow? Let's explore that: What is growth for a transit provider? More (new) access network(s) (connections). More bandwidth across backbone pipes. What is growth for access network? More subscribers. Except that the incumbent carriers have shown they have no interest in providing decent bandwidth to anywhere but the most profitable rate centers. I'd say about 2/3 of the USA is served with quite terrible access. > > The problem with the internet is that while it had promises of wild > growth in the 90s and 00s, once penetration reaches a certain level, > growth stabilizes. Penetration is ABYSMAL sir. Huge swaths of underserved americans exist. > > When you combine this with threath to large incumbents's media and > media > distribution endeavours by the likes of Netflix (and cat videos on > Youtube), large incumbents start thinking about how they will be able > to > continue to grow revenus/profits when customers will shift spending to > vspecialty channels/cableTV to Netflix and customer growth will not > compensate. Except they aren't. Even in the most profitable rate centers, they've declined to really invest in the networks. They aren't a real business. You have to remember that. They have regulatory capture, natural/defacto monopoly etc etc. They don't operate in the real world of risk/reward/profit/loss/uncertainty like any other real business has to. > > So they seek new sources of revenues, and/or attempt to thwart > competition any way they can. No to the first. Yes to the second. If they were seeking new sources of revenue, they'd be massively expanding into un/der served markets and aggressively growing over the top services (which are fat margin). They did a bit of an advertising campaign of "smart home" offerings, but that seems to have never grown beyond a pilot. > > The current trend is to "if you can't fight them, jon them" where > cablecos start to include the Netflix app into their proprietary > set-top > boxes. The idea is that you at least make the customer continue to use > your box and your remote control which makes it easier for them to > switch between netflix and legacy TV. > True. I don't know why one of the cablecos hasn't licensed roku, added cable card and made that available as a "hip/cool" set top box offering and charge another 10.00 a month on top of the standard dvr rental. > Would be interesting to see if those cable companies that are agreeing > to add the Netflix app onto their proprietary STBs also play peering > capacity games to degrade the service or not. So how is the content delivered? Is it over the internet? Or is it over the cable plant, from cable headends? From mark.tinka at seacom.mu Wed May 14 14:41:34 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 14 May 2014 16:41:34 +0200 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: <504BEA38-64A4-43F6-A922-26294EA3DD02@delong.com> References: <53721F0E.6090904@mykolab.com> <006a01cf6ef4$faade650$f009b2f0$@wicks.co.nz> <504BEA38-64A4-43F6-A922-26294EA3DD02@delong.com> Message-ID: <201405141641.35133.mark.tinka@seacom.mu> On Wednesday, May 14, 2014 03:35:41 PM Owen DeLong wrote: > Last I looked, you were free to change out the kit on > your submarine cable to anything you wanted once the > cable was landed. Things could have changed now, but if memory serves, you would be asked to reconfirm your kit during intervals and/or if you tried to get any additional services deployed within the U.S. It's been a while since I ran a cable into the U.S., so this could have changed. 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 tarko at lanparty.ee Wed May 14 14:50:56 2014 From: tarko at lanparty.ee (Tarko Tikan) Date: Wed, 14 May 2014 17:50:56 +0300 Subject: IPAM DDI Software, Subscriber Management, CMDB and Per Customer VLANs In-Reply-To: <5bffbb5f2f0942e58c899fa3a0592bcf@BY2PR06MB092.namprd06.prod.outlook.com> References: <5bffbb5f2f0942e58c899fa3a0592bcf@BY2PR06MB092.namprd06.prod.outlook.com> Message-ID: <537382D0.5040408@lanparty.ee> hey, > Subscriber Management/BRAS/BNG: Redback was the big player back in the day, but I believe they are no longer. Juniper has their Subscriber Management feature pack on their MX routers, and Cisco has their Broadband Network Gateway on their ASR routers. Besides these two vendors I am not sure what other solutions are out there. I believe both of these solutions communicate upstream to external radius servers and DHCP servers. Is anyone using Subscriber Management, or is there another way of doing it? ALU is the most known (and yet least known as subscriber management is mainly used by big telcos who are not sharing what they do internally) and has best subscriber management features both v4 and v6. Google "ALU 7750". -- tarko From mikea at mikea.ath.cx Wed May 14 15:06:09 2014 From: mikea at mikea.ath.cx (Mike A) Date: Wed, 14 May 2014 10:06:09 -0500 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: <8BD160DC-0E18-4D1F-8244-17E79FE1E338@ianai.net> References: <53721F0E.6090904@mykolab.com> <22B7B879-F14D-464E-B937-A5B95227FC97@delong.com> <4BE296DF-8D1E-4688-BCDC-9EC2000DA3B9@ianai.net> <8A9C15BC-F40A-4AE6-9D83-FDBD817F7528@delong.com> <006a01cf6ef4$faade650$f009b2f0$@wicks.co.nz> <8BD160DC-0E18-4D1F-8244-17E79FE1E338@ianai.net> Message-ID: <20140514150609.GB1924@mikea.ath.cx> On Tue, May 13, 2014 at 05:52:58PM -0400, Patrick W. Gilmore wrote: > On May 13, 2014, at 17:47 , Tony Wicks wrote: > > >> Cc: NANOG list > >> Subject: Re: New Zealand Spy Agency To Vet Network Builds, Provider Staff > >> > >> I didn't see the NSA telling us what we had to buy are demanding advance > >> approval rights on our maintenance procedures. > >> > >> Owen > > > > Try to get approval to land a submarine cable onto US soil using Huawei DWDM > > kit and then come back to us. > > Hey, now, that's not fair. The NSA is just doing what any large player who dominates their space does - try to block out the competition! > > Copy/pasting from a friend of mine (he can out himself if he likes): > http://www.theguardian.com/books/2014/may/12/glenn-greenwald-nsa-tampers-us-internet-routers-snowden > - But while American companies were being warned away from supposedly > untrustworthy Chinese routers, foreign organisations would have been > well advised to beware of American-made ones. A June 2010 report from > the head of the NSA's Access and Target Development department is > shockingly explicit. The NSA routinely receives or intercepts routers, > servers, and other computer network devices being exported from the US > before they are delivered to the international customers. > > - The agency then implants backdoor surveillance tools, repackages the > devices with a factory seal, and sends them on. The NSA thus gains > access to entire networks and all their users. The document gleefully > observes that some "SIGINT tradecraft is very hands-on (literally!)". > > - Eventually, the implanted device connects back to the NSA. The report > continues: "In one recent case, after several months a beacon > implanted through supply-chain interdiction called back to the NSA > covert infrastructure. This call back provided us access to further > exploit the device and survey the network." > > - It is quite possible that Chinese firms are implanting surveillance > mechanisms in their network devices. But the US is certainly doing the > same. > > - Warning the world about Chinese surveillance could have been one of > the motives behind the US government's claims that Chinese devices > cannot be trusted. But an equally important motive seems to have been > preventing Chinese devices from supplanting American-made ones, which > would have limited the NSA's own reach. In other words, Chinese > routers and servers represent not only economic competition but also > surveillance competition. This comes as absolutely no surprise to me. I heard rumbles and rumors as far back as Gulf War I that just before the "shock and awe" assault, the Iraqui milnet, and in particular their C3I net, went down hard, reducing them to radio and POTS. The outage was attributed to our penetration of that net through router/switch backdoors, and to magic packets to hard-kill the routers. While the sources were not, TTBOMK, inside the classification barrier, the assertions and claims seemed quite plausible then; in light of the Snowden disclosures to date, them seem not merely plausible, but eminently probable. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From charles at thefnf.org Wed May 14 15:14:25 2014 From: charles at thefnf.org (charles at thefnf.org) Date: Wed, 14 May 2014 10:14:25 -0500 Subject: IPAM DDI Software, Subscriber Management, CMDB and Per Customer VLANs In-Reply-To: <5bffbb5f2f0942e58c899fa3a0592bcf@BY2PR06MB092.namprd06.prod.outlook.com> References: <5bffbb5f2f0942e58c899fa3a0592bcf@BY2PR06MB092.namprd06.prod.outlook.com> Message-ID: On 2014-05-13 16:37, Kyle Leissner wrote: > I would like recommendations on the following software/hardware > elements required to run an access network. Assume you are building a > greenfield network using a combination of access technologies such as > DSL, GPON, AE, and WiFi. What a timely thread! With all the talk the past several days about incumbents and lack of alternatives, I'm glad to see someone starting a new network! If it's not ultra proprietary, what (major) geographical region are you looking to start in, how many homes/businesses do you intend to pass? Or is this all theoretical? I've recently helped a coalation of non profits start an access network in Kansans City Missiouri/Kansas. It passes about 1,000 homes. Uses wifi exclusively. Meraki / Ubiquiti gear in the access layer, Ubiquiti gear in the backbone. We've been ironing out things like grounding/access to facilities, user access policies, dealing with bandwidth hogs etc etc. Now we are getting to the support suite and asking some of the same questions you are. One thing I don't see you mention below is a network monitoring system. What are you using for that? > > IPAM / DDI Solution: Needs full support for IPv6, Of course. That's important. > Customer VLANs, QinQ? You looking at offering metro-e services? RFC > 1918, ewww. v6 sir! Greenfield network and everything. > VRF, Overlapping Address Space, ewww again. Those are horrible hacks, v6 all the things. > integration with DNS, DNSSEC, So what does that mean? Create forward/reverse zone entries? Do you want to be able to delegate zone editing to customers? You'll need strong ACLs and what not. What does integration with DNSSEC mean to you? > Integration with DHCP, v4? v6? SLACC? RADVD? > and integration with ARIN. You mean the ARIN API? So you can setup auto SWIP? Looks like there are > both open source and commercial solutions available according to old > NANOG posts. Indeed. I've been looking at http://nocproject.org/ which should cater to most of the above requirements. Which cater to service providers? Who are the leaders in > this space? Does anyone have experience with dealing with multiple > vendors? Multiple vendors in what regard? You mean integrating offerings from multiple vendors? Honestly I'd spend money on a couple good integration engineers. What you are looking for almost certainly will need a good amount of perl/python/bash glue to work. You could also throw money at proprietary solutions, which might get you what you want. > > Subscriber Management/BRAS/BNG: Redback was the big player back in the > day, but I believe they are no longer. Juniper has their Subscriber > Management feature pack on their MX routers, and Cisco has their > Broadband Network Gateway on their ASR routers. Besides these two > vendors I am not sure what other solutions are out there. I believe > both of these solutions communicate upstream to external radius > servers and DHCP servers. Is anyone using Subscriber Management, or is > there another way of doing it? What is subscriber management? You mean like provisioning and such? Ah here is a description: "Broadband Subscriber Management is a method of dynamically provisioning and managing subscriber access in a multiplay or triple play network environment. This method uses AAA configuration in conjunction with dynamic profiles to provide dynamic, per-subscriber authentication, addressing, access, and configuration for a host of broadband services including Internet access, gaming, IPTV, Video on Demand (VoD), and subscriber wholesaling." We (Free Network Foundation) are doing this with RADIUS. FreeRadius on the backend, hostapd on the access layer (fairly heavily modified, we'll be submitting patches upstream soon), pfsense (with pfblocker, but used in a reverse manner). This gives us full AAA capabilities. It's somewhat "hacked" together, but our testing has seen good results so far. We hope to deploy in limited production test this weekend. > > CMDB: A centralized database to keep track of all assets within the > network would be nice. I would assume this would need to tie in with > the IPAM solution and billing systems. > Yes. Agreed. I've not necessarily come up with a good system for this. I'm using a combination of Zenoss / Observium (will retire Observium once I have figured out the Zenoss API). > If you had your choice starting from the ground up how would you > deploy an access network today? Well since I'm in the process of doing that: v6 only (though to be honest, we are v4 right now, but heavily testing v6. Still lots of broken stuff, like gaming) All FLOSS. Pfsense for internet edge (OSPF/BGP) routing, full l7 firewalling/IDS/IPS, proxy/caching Zenoss (up/down, trending) Observium (used as a CMDB, will be retiring for Zenoss soon) Slack/Rundeck (configuration management, command dispatching). Since everything is *NIX with a shell, I can just treat the routers/access points like *NIX boxes and have access to a full suite of tools. OpenWRT (qmp.cat firmware build) + Quagga (to redistribute the bmx6 protocol routes (adhoc/dynamic wireless) into OSPF/BGP (static wireless/wired) hostapd (heavily patched) FreeRADIUS Users fund/own the equipment. They can buy as little or much as they like (we advise them on a recommended bill of materials and help with sizing etc). This keeps costs low. Multiple transit providers of course. That's it off the top of my head. From me at geordish.org Wed May 14 16:09:02 2014 From: me at geordish.org (Dave Bell) Date: Wed, 14 May 2014 17:09:02 +0100 Subject: IPAM DDI Software, Subscriber Management, CMDB and Per Customer VLANs In-Reply-To: References: <5bffbb5f2f0942e58c899fa3a0592bcf@BY2PR06MB092.namprd06.prod.outlook.com> Message-ID: On 14 May 2014 16:14, wrote: > On 2014-05-13 16:37, Kyle Leissner wrote: > RFC >> >> 1918, > > > ewww. v6 sir! Greenfield network and everything. > >> VRF, Overlapping Address Space, > > > ewww again. Those are horrible hacks, v6 all the things. People use VRF's to provide Layer3 VPNs to customers. Customers typically use overlapping address space in their networks. VRFs are not horrible hacks. Regards, Dave From Valdis.Kletnieks at vt.edu Wed May 14 16:16:14 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 14 May 2014 12:16:14 -0400 Subject: IPAM DDI Software, Subscriber Management, CMDB and Per Customer VLANs In-Reply-To: Your message of "Wed, 14 May 2014 17:09:02 +0100." References: <5bffbb5f2f0942e58c899fa3a0592bcf@BY2PR06MB092.namprd06.prod.outlook.com> Message-ID: <23751.1400084174@turing-police.cc.vt.edu> On Wed, 14 May 2014 17:09:02 +0100, Dave Bell said: > People use VRF's to provide Layer3 VPNs to customers. Customers > typically use overlapping address space in their networks. That's the customer's problem inside their networks. If you have overlapping address space in *your own greenfield* network, you're probably doing something wrong. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From me at geordish.org Wed May 14 16:23:05 2014 From: me at geordish.org (Dave Bell) Date: Wed, 14 May 2014 17:23:05 +0100 Subject: IPAM DDI Software, Subscriber Management, CMDB and Per Customer VLANs In-Reply-To: <23751.1400084174@turing-police.cc.vt.edu> References: <5bffbb5f2f0942e58c899fa3a0592bcf@BY2PR06MB092.namprd06.prod.outlook.com> <23751.1400084174@turing-police.cc.vt.edu> Message-ID: It depends on the service you are providing. If its fully managed up to the customer premises, I fail to see how you can get away without knowing what addressing the customer is using. On 14 May 2014 17:16, wrote: > On Wed, 14 May 2014 17:09:02 +0100, Dave Bell said: > > > People use VRF's to provide Layer3 VPNs to customers. Customers > > typically use overlapping address space in their networks. > > That's the customer's problem inside their networks. If you have > overlapping address space in *your own greenfield* network, you're > probably doing something wrong. > From owen at delong.com Wed May 14 17:07:32 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 14 May 2014 10:07:32 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: <201405141447.11250.mark.tinka@seacom.mu> References: <536BBC62.4070805@KingsMountain.com> <566F1D41-74BD-41B4-AFE3-D988747D4911@arbor.net> <201405141447.11250.mark.tinka@seacom.mu> Message-ID: <4F6EA49C-4CF3-445D-88CB-D8A52BAAE0EF@delong.com> On May 14, 2014, at 5:47 AM, Mark Tinka wrote: > On Wednesday, May 14, 2014 11:27:57 AM Roland Dobbins wrote: > >> Are there any real-world models out there for >> revenue-sharing between app/content providers and access >> networks which would eliminate or reduce 'paid peering' >> (an alternate way to think of it is as 'delimited >> transit', another oxymoron like 'paid peering', but with >> a slightly different emphasis) monetary exchanges? > > I think so, but none will cop to it publicly :-). > > Mark. 900- numbers and xxx-976 numbers come to mind. Owen From rps at maine.edu Wed May 14 17:13:09 2014 From: rps at maine.edu (Ray Soucy) Date: Wed, 14 May 2014 13:13:09 -0400 Subject: FYI: Unbreakable VPN using Vyatta/VyOS -HOW TO- In-Reply-To: <20140513181019.B1C4.C42C3789@sakura.ad.jp> References: <20140513181019.B1C4.C42C3789@sakura.ad.jp> Message-ID: Thanks for this, Have you posted this to the VyOS project forums? It would make a nice addition to the wiki (*cough* I've been trying to find some help to complete the VyOS user guide). On Tue, May 13, 2014 at 5:10 AM, Naoto MATSUMOTO wrote: > Hi all! > > > We wrote TIPS memo about the Basic Idea for inter-cloud networking using > Virtual Router (a.k.a Brocade Vyatta vRotuer and VyOS) with High > Availability > Concept. > > Please enjoy it if you interest in ;-) > > Unbreakable VPN using Vyatta/VyOS -HOW TO- > http://slidesha.re/1lryGVU > > Best Regards, > > -- > SAKURA Internet Inc. / Senior Researcher > Naoto MATSUMOTO > SAKURA Internet Research Center > > -- 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 jabley at hopcount.ca Wed May 14 18:31:56 2014 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 14 May 2014 20:31:56 +0200 Subject: New Zealand Spy Agency To Vet Network Builds, Provider Staff In-Reply-To: <537222D5.5050003@mykolab.com> References: <53721F0E.6090904@mykolab.com> <537222D5.5050003@mykolab.com> Message-ID: <5EABE42F-D3F4-47DC-B7C3-04231F9221EE@hopcount.ca> On 13 May 2014, at 15:49, Paul Ferguson wrote: > So is there just reluctant acceptance of this law, or is there > push-back and plans to repeal, or...? This was news to me when I heard about it the other day (because apparently I am a bad kiwi and do not keep myself informed), but it does sound like the conversation at NZNOG resulted in an exception list that makes the general idea at least a little more practical, if not palatable. See http://ncsc.govt.nz/assets/TICSA/NCSC-Guidance-for-Network-Operators.pdf http://ncsc.govt.nz/assets/TICSA/Notice-of-Exemptions.pdf The recent NZNOG discussion is hereabouts: http://list.waikato.ac.nz/pipermail/nznog/2014-May/020802.html Joe From DStaal at usa.net Wed May 14 18:41:59 2014 From: DStaal at usa.net (Daniel Staal) Date: Wed, 14 May 2014 14:41:59 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@[192.168.1.50]> <5373156B.8000005@vaxination.ca> Message-ID: <70A96FCC0350D38A6A64EE97@[192.168.1.50]> --As of May 14, 2014 9:23:21 AM -0500, charles at thefnf.org is alleged to have said: >> So they seek new sources of revenues, and/or attempt to thwart >> competition any way they can. > > No to the first. Yes to the second. If they were seeking new sources of > revenue, they'd be massively expanding into un/der served markets and > aggressively growing over the top services (which are fat margin). They > did a bit of an advertising campaign of "smart home" offerings, but that > seems to have never grown beyond a pilot. --As for the rest, it is mine. This whole argument is about them seeking new sources of revenue: The content providers who their current customers want to access. Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --------------------------------------------------------------- From hugo at slabnet.com Wed May 14 15:02:37 2014 From: hugo at slabnet.com (Hugo Slabbert) Date: Wed, 14 May 2014 08:02:37 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> Message-ID: > > So they seek new sources of revenues, and/or attempt to thwart >> competition any way they can. >> > No to the first. Yes to the second. If they were seeking new sources of > revenue, they'd be massively expanding into un/der served markets and > aggressively growing over the top services (which are fat margin). > Sure they are (seeking new sources of revenue). They're not necessarily creating new products or services, i.e. actually adding any value, but they are finding ways to extract additional revenue from the same pipes, e.g. through paid peering with content providers. I'm not endorsing this; just pointing out that you two are actually in agreement here. -- Hugo On Wed, May 14, 2014 at 7:23 AM, wrote: > On 2014-05-14 02:04, Jean-Francois Mezei wrote: > >> On 14-05-13 22:50, Daniel Staal wrote: >> >> They have the money. They have the ability to get more money. *They see >>> no reason to spend money making customers happy.* They can make more >>> profit without it. >>> >> >> There is the issue of control over the market. But also the pressure >> from shareholders for continued growth. >> > > > Yes. That is true. Except that it's not. > > How do service providers grow? Let's explore that: > > What is growth for a transit provider? > > More (new) access network(s) (connections). > More bandwidth across backbone pipes. > > > What is growth for access network? > More subscribers. > > Except that the incumbent carriers have shown they have no interest in > providing decent bandwidth to anywhere but the most profitable rate > centers. I'd say about 2/3 of the USA is served with quite terrible access. > > > > >> The problem with the internet is that while it had promises of wild >> growth in the 90s and 00s, once penetration reaches a certain level, >> growth stabilizes. >> > > Penetration is ABYSMAL sir. Huge swaths of underserved americans exist. > > > >> When you combine this with threath to large incumbents's media and media >> distribution endeavours by the likes of Netflix (and cat videos on >> Youtube), large incumbents start thinking about how they will be able to >> continue to grow revenus/profits when customers will shift spending to >> vspecialty channels/cableTV to Netflix and customer growth will not >> compensate. >> > > Except they aren't. Even in the most profitable rate centers, they've > declined to really invest in the networks. They aren't a real business. You > have to remember that. They have regulatory capture, natural/defacto > monopoly etc etc. They don't operate in the real world of > risk/reward/profit/loss/uncertainty like any other real business has to. > > > >> So they seek new sources of revenues, and/or attempt to thwart >> competition any way they can. >> > > No to the first. Yes to the second. If they were seeking new sources of > revenue, they'd be massively expanding into un/der served markets and > aggressively growing over the top services (which are fat margin). They did > a bit of an advertising campaign of "smart home" offerings, but that seems > to have never grown beyond a pilot. > > > >> The current trend is to "if you can't fight them, jon them" where >> cablecos start to include the Netflix app into their proprietary set-top >> boxes. The idea is that you at least make the customer continue to use >> your box and your remote control which makes it easier for them to >> switch between netflix and legacy TV. >> >> > True. I don't know why one of the cablecos hasn't licensed roku, added > cable card and made that available as a "hip/cool" set top box offering and > charge another 10.00 a month on top of the standard dvr rental. > > > > Would be interesting to see if those cable companies that are agreeing >> to add the Netflix app onto their proprietary STBs also play peering >> capacity games to degrade the service or not. >> > > So how is the content delivered? Is it over the internet? Or is it over > the cable plant, from cable headends? > From owen at delong.com Wed May 14 19:02:28 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 14 May 2014 12:02:28 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> Message-ID: Yes, the more accurate statement would be aggressively seeking new ways to monetize the existing infrastructure without investing in upgrades or additional buildout any more than absolutely necessary. Owen On May 14, 2014, at 8:02 AM, Hugo Slabbert wrote: >> >> So they seek new sources of revenues, and/or attempt to thwart >>> competition any way they can. >>> >> > No to the first. Yes to the second. If they were seeking new sources of >> revenue, they'd be massively expanding into un/der served markets and >> aggressively growing over the top services (which are fat margin). >> > > Sure they are (seeking new sources of revenue). They're not necessarily > creating new products or services, i.e. actually adding any value, but they > are finding ways to extract additional revenue from the same pipes, e.g. > through paid peering with content providers. > > I'm not endorsing this; just pointing out that you two are actually in > agreement here. > > -- > Hugo > > > On Wed, May 14, 2014 at 7:23 AM, wrote: > >> On 2014-05-14 02:04, Jean-Francois Mezei wrote: >> >>> On 14-05-13 22:50, Daniel Staal wrote: >>> >>> They have the money. They have the ability to get more money. *They see >>>> no reason to spend money making customers happy.* They can make more >>>> profit without it. >>>> >>> >>> There is the issue of control over the market. But also the pressure >>> from shareholders for continued growth. >>> >> >> >> Yes. That is true. Except that it's not. >> >> How do service providers grow? Let's explore that: >> >> What is growth for a transit provider? >> >> More (new) access network(s) (connections). >> More bandwidth across backbone pipes. >> >> >> What is growth for access network? >> More subscribers. >> >> Except that the incumbent carriers have shown they have no interest in >> providing decent bandwidth to anywhere but the most profitable rate >> centers. I'd say about 2/3 of the USA is served with quite terrible access. >> >> >> >> >>> The problem with the internet is that while it had promises of wild >>> growth in the 90s and 00s, once penetration reaches a certain level, >>> growth stabilizes. >>> >> >> Penetration is ABYSMAL sir. Huge swaths of underserved americans exist. >> >> >> >>> When you combine this with threath to large incumbents's media and media >>> distribution endeavours by the likes of Netflix (and cat videos on >>> Youtube), large incumbents start thinking about how they will be able to >>> continue to grow revenus/profits when customers will shift spending to >>> vspecialty channels/cableTV to Netflix and customer growth will not >>> compensate. >>> >> >> Except they aren't. Even in the most profitable rate centers, they've >> declined to really invest in the networks. They aren't a real business. You >> have to remember that. They have regulatory capture, natural/defacto >> monopoly etc etc. They don't operate in the real world of >> risk/reward/profit/loss/uncertainty like any other real business has to. >> >> >> >>> So they seek new sources of revenues, and/or attempt to thwart >>> competition any way they can. >>> >> >> No to the first. Yes to the second. If they were seeking new sources of >> revenue, they'd be massively expanding into un/der served markets and >> aggressively growing over the top services (which are fat margin). They did >> a bit of an advertising campaign of "smart home" offerings, but that seems >> to have never grown beyond a pilot. >> >> >> >>> The current trend is to "if you can't fight them, jon them" where >>> cablecos start to include the Netflix app into their proprietary set-top >>> boxes. The idea is that you at least make the customer continue to use >>> your box and your remote control which makes it easier for them to >>> switch between netflix and legacy TV. >>> >>> >> True. I don't know why one of the cablecos hasn't licensed roku, added >> cable card and made that available as a "hip/cool" set top box offering and >> charge another 10.00 a month on top of the standard dvr rental. >> >> >> >> Would be interesting to see if those cable companies that are agreeing >>> to add the Netflix app onto their proprietary STBs also play peering >>> capacity games to degrade the service or not. >>> >> >> So how is the content delivered? Is it over the internet? Or is it over >> the cable plant, from cable headends? >> From mpetach at netflight.com Wed May 14 19:06:26 2014 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 14 May 2014 12:06:26 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: <566F1D41-74BD-41B4-AFE3-D988747D4911@arbor.net> References: <536BBC62.4070805@KingsMountain.com> <566F1D41-74BD-41B4-AFE3-D988747D4911@arbor.net> Message-ID: On Wed, May 14, 2014 at 2:27 AM, Roland Dobbins wrote: > > On May 14, 2014, at 3:11 PM, Matthew Petach wrote: > > > I'm constantly amazed at how access networks think they can charge 2/3 > the price of full transit for just their routes when they represent less > than 1/10th of the overall traffic volume. > > My guess is that from the perspective of the access providers, they aren't > selling traffic volume or routes, per se - their view is that they're > selling privileged engagement with large numbers of potentially monetizable > individual prospects. > For an ad-supported enterprise, that becomes quite the challenge; if the access network has 40M users, but they're all endemic cheapskates that never click on ads, a) is it worth trying to improve connectivity to them? (will better connectivity increase likelihood of clicking, or are they simply cheap to the core, in which case it would be wasted money and effort), and b) would the access network be willing to divulge the demographic nature of their customer base ahead of time ("we have 40M skinflints who will never click on your ads--come pay for direct access to them!"). That "potentially" is quite a big "?" in the equation. ^_^; Are there any real-world models out there for revenue-sharing between > app/content providers and access networks which would eliminate or reduce > 'paid peering' (an alternate way to think of it is as 'delimited transit', > another oxymoron like 'paid peering', but with a slightly different > emphasis) monetary exchanges? > An interesting proposal, to be sure. "I'll pay you a portion of all ad revenue I generate from your users clicking on my ads. If you get users with more disposable income who are more likely to click on my ads, you get more revenue share from me. If you go after the bottom of the barrel cheap users who never click on ads, you end up with no revenue share income." Would be somewhat amusing to have broadband providers sending out notes to their customers "I'm sorry, we're not going to give you the option of renewing your service; you never click on ads, we don't get any revenue share out of you. Go find some other network to sponge off it, you're not worth it for us anymore." ;P Not going to happen, of course, but an interesting thought exercise to contemplate. ^_^;; Matt From Kevin_McElearney at cable.comcast.com Wed May 14 21:14:16 2014 From: Kevin_McElearney at cable.comcast.com (McElearney, Kevin) Date: Wed, 14 May 2014 21:14:16 +0000 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> , Message-ID: <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> Respectfully, this is a highly inaccurate "sound bite" - Kevin 215-313-1083 > On May 14, 2014, at 3:05 PM, "Owen DeLong" wrote: > > Yes, the more accurate statement would be aggressively seeking new > ways to monetize the existing infrastructure without investing in upgrades > or additional buildout any more than absolutely necessary. > > Owen > > On May 14, 2014, at 8:02 AM, Hugo Slabbert wrote: > >>> >>> So they seek new sources of revenues, and/or attempt to thwart >>>> competition any way they can. >> No to the first. Yes to the second. If they were seeking new sources of >>> revenue, they'd be massively expanding into un/der served markets and >>> aggressively growing over the top services (which are fat margin). >> >> Sure they are (seeking new sources of revenue). They're not necessarily >> creating new products or services, i.e. actually adding any value, but they >> are finding ways to extract additional revenue from the same pipes, e.g. >> through paid peering with content providers. >> >> I'm not endorsing this; just pointing out that you two are actually in >> agreement here. >> >> -- >> Hugo >> >> >>> On Wed, May 14, 2014 at 7:23 AM, wrote: >>> >>>> On 2014-05-14 02:04, Jean-Francois Mezei wrote: >>>> >>>> On 14-05-13 22:50, Daniel Staal wrote: >>>> >>>> They have the money. They have the ability to get more money. *They see >>>>> no reason to spend money making customers happy.* They can make more >>>>> profit without it. >>>> >>>> There is the issue of control over the market. But also the pressure >>>> from shareholders for continued growth. >>> >>> >>> Yes. That is true. Except that it's not. >>> >>> How do service providers grow? Let's explore that: >>> >>> What is growth for a transit provider? >>> >>> More (new) access network(s) (connections). >>> More bandwidth across backbone pipes. >>> >>> >>> What is growth for access network? >>> More subscribers. >>> >>> Except that the incumbent carriers have shown they have no interest in >>> providing decent bandwidth to anywhere but the most profitable rate >>> centers. I'd say about 2/3 of the USA is served with quite terrible access. >>> >>> >>> >>> >>>> The problem with the internet is that while it had promises of wild >>>> growth in the 90s and 00s, once penetration reaches a certain level, >>>> growth stabilizes. >>> >>> Penetration is ABYSMAL sir. Huge swaths of underserved americans exist. >>> >>> >>> >>>> When you combine this with threath to large incumbents's media and media >>>> distribution endeavours by the likes of Netflix (and cat videos on >>>> Youtube), large incumbents start thinking about how they will be able to >>>> continue to grow revenus/profits when customers will shift spending to >>>> vspecialty channels/cableTV to Netflix and customer growth will not >>>> compensate. >>> >>> Except they aren't. Even in the most profitable rate centers, they've >>> declined to really invest in the networks. They aren't a real business. You >>> have to remember that. They have regulatory capture, natural/defacto >>> monopoly etc etc. They don't operate in the real world of >>> risk/reward/profit/loss/uncertainty like any other real business has to. >>> >>> >>> >>>> So they seek new sources of revenues, and/or attempt to thwart >>>> competition any way they can. >>> >>> No to the first. Yes to the second. If they were seeking new sources of >>> revenue, they'd be massively expanding into un/der served markets and >>> aggressively growing over the top services (which are fat margin). They did >>> a bit of an advertising campaign of "smart home" offerings, but that seems >>> to have never grown beyond a pilot. >>> >>> >>> >>>> The current trend is to "if you can't fight them, jon them" where >>>> cablecos start to include the Netflix app into their proprietary set-top >>>> boxes. The idea is that you at least make the customer continue to use >>>> your box and your remote control which makes it easier for them to >>>> switch between netflix and legacy TV. >>> True. I don't know why one of the cablecos hasn't licensed roku, added >>> cable card and made that available as a "hip/cool" set top box offering and >>> charge another 10.00 a month on top of the standard dvr rental. >>> >>> >>> >>> Would be interesting to see if those cable companies that are agreeing >>>> to add the Netflix app onto their proprietary STBs also play peering >>>> capacity games to degrade the service or not. >>> >>> So how is the content delivered? Is it over the internet? Or is it over >>> the cable plant, from cable headends? > From Gus.Crichton at digicelgroup.com Wed May 14 22:14:01 2014 From: Gus.Crichton at digicelgroup.com (Gus Crichton) Date: Wed, 14 May 2014 22:14:01 +0000 Subject: BGP route flapping Message-ID: <6B06BC6CCB666849B576AE9A62A801175E4ACB1E@WSMBX001.digicelgroup.local> Hi there, Hope you networking experts can shed some light on a concern I have please. I am multihoming using 2 ISPs to the internet, due to reasons outside my control, my primary preferred link keeps dropping a number of times a day forcing traffic to my backup and vice-versa when the primary comes back up. The route calculations by the upstream tier 1s and 2s handle the route calculations but if I do this too many times consuming their resources, is there a penalty/blackmark on my AS? Is this monitored even by the tier1s and 2s? Thanks. Regards, Gus C. ________________________________ Notice of Confidentiality: The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. From LarrySheldon at cox.net Thu May 15 00:01:36 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 14 May 2014 19:01:36 -0500 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <1lUt1o01g1cZc5601lUvWZ> References: <536BBC62.4070805@KingsMountain.com> <1lUt1o01g1cZc5601lUvWZ> Message-ID: <537403E0.5050502@cox.net> On 5/14/2014 4:27 AM, Roland Dobbins wrote: > > On May 14, 2014, at 3:11 PM, Matthew Petach > wrote: > >> I'm constantly amazed at how access networks think they can charge >> 2/3 the price of full transit for just their routes when they >> represent less than 1/10th of the overall traffic volume. > > My guess is that from the perspective of the access providers, they > aren't selling traffic volume or routes, per se - their view is that > they're selling privileged engagement with large numbers of > potentially monetizable individual prospects. In a world ruled by by the dreaded principles of completion, that would be described as the price where buyer and seller agreed on the value of the product. > Note that I'm neither endorsing nor disputing this perspective, just > mooting it as a possible explanation.| I do endorse a free market as providing the best value to all. > Are there any real-world models out there for revenue-sharing between > app/content providers and access networks which would eliminate or > reduce 'paid peering' (an alternate way to think of it is as > 'delimited transit', another oxymoron like 'paid peering', but with a > slightly different emphasis) monetary exchanges? Maybe it is time to try a free market. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From jared at puck.nether.net Thu May 15 00:15:50 2014 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 14 May 2014 20:15:50 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> , <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> Message-ID: <37AFC907-CAB5-4721-B79D-EAE2687970BF@puck.nether.net> Owen, I've seen a vast difference between Comcast and others in the "marketplace". Right now, if I had the choice between Comcast and a "legacy" telco, I would pick Comcast hands-down for: a) performance b) IPv6 support c) willingness to work on issues - Jared On May 14, 2014, at 5:14 PM, McElearney, Kevin wrote: > Respectfully, this is a highly inaccurate "sound bite" > > - Kevin > > 215-313-1083 > >> On May 14, 2014, at 3:05 PM, "Owen DeLong" wrote: >> >> Yes, the more accurate statement would be aggressively seeking new >> ways to monetize the existing infrastructure without investing in upgrades >> or additional buildout any more than absolutely necessary. >> >> Owen >> >> On May 14, 2014, at 8:02 AM, Hugo Slabbert wrote: >> >>>> >>>> So they seek new sources of revenues, and/or attempt to thwart >>>>> competition any way they can. >>> No to the first. Yes to the second. If they were seeking new sources of >>>> revenue, they'd be massively expanding into un/der served markets and >>>> aggressively growing over the top services (which are fat margin). >>> >>> Sure they are (seeking new sources of revenue). They're not necessarily >>> creating new products or services, i.e. actually adding any value, but they >>> are finding ways to extract additional revenue from the same pipes, e.g. >>> through paid peering with content providers. >>> >>> I'm not endorsing this; just pointing out that you two are actually in >>> agreement here. >>> >>> -- >>> Hugo >>> >>> >>>> On Wed, May 14, 2014 at 7:23 AM, wrote: >>>> >>>>> On 2014-05-14 02:04, Jean-Francois Mezei wrote: >>>>> >>>>> On 14-05-13 22:50, Daniel Staal wrote: >>>>> >>>>> They have the money. They have the ability to get more money. *They see >>>>>> no reason to spend money making customers happy.* They can make more >>>>>> profit without it. >>>>> >>>>> There is the issue of control over the market. But also the pressure >>>>> from shareholders for continued growth. >>>> >>>> >>>> Yes. That is true. Except that it's not. >>>> >>>> How do service providers grow? Let's explore that: >>>> >>>> What is growth for a transit provider? >>>> >>>> More (new) access network(s) (connections). >>>> More bandwidth across backbone pipes. >>>> >>>> >>>> What is growth for access network? >>>> More subscribers. >>>> >>>> Except that the incumbent carriers have shown they have no interest in >>>> providing decent bandwidth to anywhere but the most profitable rate >>>> centers. I'd say about 2/3 of the USA is served with quite terrible access. >>>> >>>> >>>> >>>> >>>>> The problem with the internet is that while it had promises of wild >>>>> growth in the 90s and 00s, once penetration reaches a certain level, >>>>> growth stabilizes. >>>> >>>> Penetration is ABYSMAL sir. Huge swaths of underserved americans exist. >>>> >>>> >>>> >>>>> When you combine this with threath to large incumbents's media and media >>>>> distribution endeavours by the likes of Netflix (and cat videos on >>>>> Youtube), large incumbents start thinking about how they will be able to >>>>> continue to grow revenus/profits when customers will shift spending to >>>>> vspecialty channels/cableTV to Netflix and customer growth will not >>>>> compensate. >>>> >>>> Except they aren't. Even in the most profitable rate centers, they've >>>> declined to really invest in the networks. They aren't a real business. You >>>> have to remember that. They have regulatory capture, natural/defacto >>>> monopoly etc etc. They don't operate in the real world of >>>> risk/reward/profit/loss/uncertainty like any other real business has to. >>>> >>>> >>>> >>>>> So they seek new sources of revenues, and/or attempt to thwart >>>>> competition any way they can. >>>> >>>> No to the first. Yes to the second. If they were seeking new sources of >>>> revenue, they'd be massively expanding into un/der served markets and >>>> aggressively growing over the top services (which are fat margin). They did >>>> a bit of an advertising campaign of "smart home" offerings, but that seems >>>> to have never grown beyond a pilot. >>>> >>>> >>>> >>>>> The current trend is to "if you can't fight them, jon them" where >>>>> cablecos start to include the Netflix app into their proprietary set-top >>>>> boxes. The idea is that you at least make the customer continue to use >>>>> your box and your remote control which makes it easier for them to >>>>> switch between netflix and legacy TV. >>>> True. I don't know why one of the cablecos hasn't licensed roku, added >>>> cable card and made that available as a "hip/cool" set top box offering and >>>> charge another 10.00 a month on top of the standard dvr rental. >>>> >>>> >>>> >>>> Would be interesting to see if those cable companies that are agreeing >>>>> to add the Netflix app onto their proprietary STBs also play peering >>>>> capacity games to degrade the service or not. >>>> >>>> So how is the content delivered? Is it over the internet? Or is it over >>>> the cable plant, from cable headends? >> From jbates at paradoxnetworks.net Thu May 15 00:27:16 2014 From: jbates at paradoxnetworks.net (Jack Bates) Date: Wed, 14 May 2014 19:27:16 -0500 Subject: BGP route flapping In-Reply-To: <6B06BC6CCB666849B576AE9A62A801175E4ACB1E@WSMBX001.digicelgroup.local> References: <6B06BC6CCB666849B576AE9A62A801175E4ACB1E@WSMBX001.digicelgroup.local> Message-ID: <537409E4.5080807@paradoxnetworks.net> On 5/14/2014 5:14 PM, Gus Crichton wrote: > The route calculations by the upstream tier 1s and 2s handle the route calculations but if I do this too many times consuming their resources, is there a penalty/blackmark on my AS? Is this monitored even by the tier1s and 2s? > > Generally I don't like to see BGP flap more than 3 times in an hour or two. I've seen some people do some really fast flapping and find themselves isolated from quite a few networks for 30 minutes or so. It really just depends on who out there is doing route dampening and how they configured it. Remember, a single flap from your point of view is possibly multiple flaps from other router viewpoints. Generally it is not an ASN issue unless you're just horribly bad, but individual networks can have issues with automated mechanisms. Jack From streiner at cluebyfour.org Wed May 14 21:39:35 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 14 May 2014 17:39:35 -0400 (EDT) Subject: BGP route flapping In-Reply-To: <6B06BC6CCB666849B576AE9A62A801175E4ACB1E@WSMBX001.digicelgroup.local> References: <6B06BC6CCB666849B576AE9A62A801175E4ACB1E@WSMBX001.digicelgroup.local> Message-ID: On Wed, 14 May 2014, Gus Crichton wrote: > Hope you networking experts can shed some light on a concern I have > please. I am multihoming using 2 ISPs to the internet, due to reasons > outside my control, my primary preferred link keeps dropping a number of > times a day forcing traffic to my backup and vice-versa when the primary > comes back up. Is it feasible to make your backup ISP your primary ISP until your 'real' primary ISP gets the link flapping issues sorted out, or you and your real primary ISP work together to get the issue sorted out? > The route calculations by the upstream tier 1s and 2s handle the route > calculations but if I do this too many times consuming their resources, > is there a penalty/blackmark on my AS? Is this monitored even by the > tier1s and 2s? Networks can choose to implement some amount of BGP flap damping, however this is generally done at the closest point to the source of the flapping. This is typically a temporary measure - the damped routes will be restored after a period of stability. The bigger issue is finding the source of the flapping and getting it fixed. jms From mpalmer at hezmatt.org Thu May 15 01:05:12 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Thu, 15 May 2014 11:05:12 +1000 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <537403E0.5050502@cox.net> References: <536BBC62.4070805@KingsMountain.com> <1lUt1o01g1cZc5601lUvWZ> <537403E0.5050502@cox.net> Message-ID: <20140515010512.GB10673@hezmatt.org> On Wed, May 14, 2014 at 07:01:36PM -0500, Larry Sheldon wrote: > Maybe it is time to try a free market. Can't do that, it would be UnAmerican! - Matt -- I can only guess that the designer of the things had a major Toilet Duck habit and had managed to score a couple of industrial-sized bottles of the stuff the night before. -- Tanuki From hugo at slabnet.com Thu May 15 04:29:12 2014 From: hugo at slabnet.com (Hugo Slabbert) Date: Wed, 14 May 2014 21:29:12 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> Message-ID: <20140515042912.GC7991@slab-wks-04.slabnet.com> >So, at the end of the week, I *had* been paying $10/mb to >send traffic through transit to reach the whole rest of the >internet. Now, I'm paying $5+$4+$4+$5+$2, or $30, and >I don't have a full set of routes, so I've still got to keep >paying the transit provider as well at $10. I would like to agree with you as I'm not a fan (by any stretch) of this type of paid peering to enter access networks, but your formula's off. It supposes that the same bit is traversing multiple paid peering links. The formula (if we ignore commits for now) should be something more like: C(T) = R(t) * M(t) + R(1) * M(1) ... + R(n) * M(n) Where: C(T) = total cost R(t) = transit $/mbit rate M(t) = transit mbps R(1) = paid peering agreement #1 $/mbps rate M(1) = paid peering agreement #1 mbps R(n) = paid peering agreement #n $/mbps rate M(n) = paid peering agreement #n mbps For your $10/mb transit example, suppose we had 1 Gbps of traffic and so our transit cost would be $10,000/month. We take your mixed bag of paid peering and say we give each of those 5 paid peers 100 mbps: C(T) = 500 * 10 + 100 * 5 + 100 * 4 + 100 * 4 + 100 * 5 + 100 * 2 C(T) = $7,000/month So, yes, as long as R(n) is lower than R(t), your overall cost should be lower, since you're moving some number of mbps from your higher priced transit link to one or more (slightly) cheaper paid peering links. Now, as I mentioned, this ignores commits, so it's really more like: C(T) = ( c(t) + R(t) * M(t) ) + ( c(n) + R(n) * M(n) ) Where: c(t) = transit commit $ M(t) = transit mbps over commit c(n) = paid peering agreement #n commit $...I've not personally had to deal with paid peering so I don't know if commit rates are at all common on them, but you can sub or add in other fixed costs e.g. transport to reach the paid peering exchange point M(n) = paid peering agreement #n mbps over commit So, it starts to get murkier. E.g. if you're not over your transit commit and now you're shifting traffic off of your transit onto paid peering, you may want to lower your transit commits. This also does not account for other potential costs were this type of arrangement to become commonplace, e.g. the additional burden on content providers of maintaining direct business relationships with any access network that would require paid peering for preferential/decent quality. Again: I'm not a fan of some of the possible abuses or strong-arm tactics of this type of arrangement between eyeball networks and content providers (e.g. running transit or existing peering links hot to push content providers to paid peering to reach the eyeball customers), but the math is not quite so dire as it was made out to be. -- Hugo On Wed 2014-May-14 01:11:30 -0700, Matthew Petach wrote: >On Sat, May 10, 2014 at 8:04 AM, Rick Astley wrote: > >> [...] >> The reality is an increasingly directly peered Internet doesn't sit well if >> you are in the business of being the middle man. Now if you will, why do >> transit companies themselves charge content companies to deliver bits? How >> is it fair to be in the business of charging companies to receive their >> bits and hand them to a settlement free peer on the hook to deliver them, >> but not fair for content to just bypass the transit company and enter a >> paid peering agreement with the company delivering the bits? In this case >> paid peering is mutually beneficial to both companies involved and is >> typically cheaper for the content company than it would cost to send that >> traffic over transit. >> > >What you're missing is that the transit provider is >selling full routes. The access network is selling >paid peering, which is a tiny fraction of the routes. >If I pay transit provider X $10/mb (i know, not realistic, >but it makes my math work) to reach the entire internet, >it might seem reasonable to pay access network C $5/mb >to hand traffic to them, and bypass the transit provider, >avoiding potentially congested links. > >But then access network A decides they want to cut out >the middleman as well--so they do the same thing, run >their ports to transit provider X hot; to avoid that, I can >pay the cheap price of $4/mb to reach them. > >Now access networks F and D want to do the same thing; >their prices for their routes are $4 and $5/mb, respectively. > >Finally, little access provider T wants in at $2/mb for their >routes. > >So, at the end of the week, I *had* been paying $10/mb to >send traffic through transit to reach the whole rest of the >internet. Now, I'm paying $5+$4+$4+$5+$2, or $30, and >I don't have a full set of routes, so I've still got to keep >paying the transit provider as well at $10. Depending on >port counts, locations, and commit volumes, your "typically >cheaper for the content company than it would cost to send >that traffic over transit" has flown completely out the window. >It could even end up being many times more expensive to >handle the traffic that way. > >In order for the costs to work out, you'd really need >to apply a formula along the lines of >C(n) <= T(n) * C(t) >where >T(n) =fraction of traffic volume destined for access network X >C(t)=cost of transit (ie, full routes, reachability to the entire internet) >C(n)=cost of paid peering to access network X > >So, if you're an access network and want to charge >for paid peering, and you represent 1/20th of my >traffic, there's no reason for me to pay more than >1/20th of my transit cost for your routes; otherwise, >it's more cost effective for me as a business to >continue to pay a transit provider. > >I'm constantly amazed at how access networks >think they can charge 2/3 the price of full transit >for just their routes when they represent less than >1/10th of the overall traffic volume. The math just >doesn't work out. It's nothing about being tier 1, or >bigger than someone else; it's just math, pure and >simple. > >Matt >(currently not being paid by anyone for my time >or thoughts, so take what I'm saying as purely >my own thoughts on the matter, nothing more) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From mark.tinka at seacom.mu Thu May 15 09:43:32 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 15 May 2014 11:43:32 +0200 Subject: IPAM DDI Software, Subscriber Management, CMDB and Per Customer VLANs In-Reply-To: References: <5bffbb5f2f0942e58c899fa3a0592bcf@BY2PR06MB092.namprd06.prod.outlook.com> Message-ID: <201405151143.32626.mark.tinka@seacom.mu> On Wednesday, May 14, 2014 06:09:02 PM Dave Bell wrote: > VRFs are not horrible hacks. Except when operators stress them to the limit by running the full Internet table inside them. But this is one of those religious arguments. 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 owen at delong.com Thu May 15 14:13:20 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 15 May 2014 07:13:20 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> , <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> Message-ID: <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> Oh, please do explicate on how this is inaccurate… Owen On May 14, 2014, at 2:14 PM, McElearney, Kevin wrote: > Respectfully, this is a highly inaccurate "sound bite" > > - Kevin > > 215-313-1083 > >> On May 14, 2014, at 3:05 PM, "Owen DeLong" wrote: >> >> Yes, the more accurate statement would be aggressively seeking new >> ways to monetize the existing infrastructure without investing in upgrades >> or additional buildout any more than absolutely necessary. >> >> Owen >> >> On May 14, 2014, at 8:02 AM, Hugo Slabbert wrote: >> >>>> >>>> So they seek new sources of revenues, and/or attempt to thwart >>>>> competition any way they can. >>> No to the first. Yes to the second. If they were seeking new sources of >>>> revenue, they'd be massively expanding into un/der served markets and >>>> aggressively growing over the top services (which are fat margin). >>> >>> Sure they are (seeking new sources of revenue). They're not necessarily >>> creating new products or services, i.e. actually adding any value, but they >>> are finding ways to extract additional revenue from the same pipes, e.g. >>> through paid peering with content providers. >>> >>> I'm not endorsing this; just pointing out that you two are actually in >>> agreement here. >>> >>> -- >>> Hugo >>> >>> >>>> On Wed, May 14, 2014 at 7:23 AM, wrote: >>>> >>>>> On 2014-05-14 02:04, Jean-Francois Mezei wrote: >>>>> >>>>> On 14-05-13 22:50, Daniel Staal wrote: >>>>> >>>>> They have the money. They have the ability to get more money. *They see >>>>>> no reason to spend money making customers happy.* They can make more >>>>>> profit without it. >>>>> >>>>> There is the issue of control over the market. But also the pressure >>>>> from shareholders for continued growth. >>>> >>>> >>>> Yes. That is true. Except that it's not. >>>> >>>> How do service providers grow? Let's explore that: >>>> >>>> What is growth for a transit provider? >>>> >>>> More (new) access network(s) (connections). >>>> More bandwidth across backbone pipes. >>>> >>>> >>>> What is growth for access network? >>>> More subscribers. >>>> >>>> Except that the incumbent carriers have shown they have no interest in >>>> providing decent bandwidth to anywhere but the most profitable rate >>>> centers. I'd say about 2/3 of the USA is served with quite terrible access. >>>> >>>> >>>> >>>> >>>>> The problem with the internet is that while it had promises of wild >>>>> growth in the 90s and 00s, once penetration reaches a certain level, >>>>> growth stabilizes. >>>> >>>> Penetration is ABYSMAL sir. Huge swaths of underserved americans exist. >>>> >>>> >>>> >>>>> When you combine this with threath to large incumbents's media and media >>>>> distribution endeavours by the likes of Netflix (and cat videos on >>>>> Youtube), large incumbents start thinking about how they will be able to >>>>> continue to grow revenus/profits when customers will shift spending to >>>>> vspecialty channels/cableTV to Netflix and customer growth will not >>>>> compensate. >>>> >>>> Except they aren't. Even in the most profitable rate centers, they've >>>> declined to really invest in the networks. They aren't a real business. You >>>> have to remember that. They have regulatory capture, natural/defacto >>>> monopoly etc etc. They don't operate in the real world of >>>> risk/reward/profit/loss/uncertainty like any other real business has to. >>>> >>>> >>>> >>>>> So they seek new sources of revenues, and/or attempt to thwart >>>>> competition any way they can. >>>> >>>> No to the first. Yes to the second. If they were seeking new sources of >>>> revenue, they'd be massively expanding into un/der served markets and >>>> aggressively growing over the top services (which are fat margin). They did >>>> a bit of an advertising campaign of "smart home" offerings, but that seems >>>> to have never grown beyond a pilot. >>>> >>>> >>>> >>>>> The current trend is to "if you can't fight them, jon them" where >>>>> cablecos start to include the Netflix app into their proprietary set-top >>>>> boxes. The idea is that you at least make the customer continue to use >>>>> your box and your remote control which makes it easier for them to >>>>> switch between netflix and legacy TV. >>>> True. I don't know why one of the cablecos hasn't licensed roku, added >>>> cable card and made that available as a "hip/cool" set top box offering and >>>> charge another 10.00 a month on top of the standard dvr rental. >>>> >>>> >>>> >>>> Would be interesting to see if those cable companies that are agreeing >>>>> to add the Netflix app onto their proprietary STBs also play peering >>>>> capacity games to degrade the service or not. >>>> >>>> So how is the content delivered? Is it over the internet? Or is it over >>>> the cable plant, from cable headends? >> From n-matsumoto at sakura.ad.jp Thu May 15 01:51:25 2014 From: n-matsumoto at sakura.ad.jp (Naoto MATSUMOTO) Date: Thu, 15 May 2014 10:51:25 +0900 Subject: FYI: Unbreakable VPN using Vyatta/VyOS -HOW TO- In-Reply-To: References: <20140513181019.B1C4.C42C3789@sakura.ad.jp> Message-ID: <20140515105125.4CEC.C42C3789@sakura.ad.jp> Hi Ray Okey, I'll be soon. On Wed, 14 May 2014 13:13:09 -0400 Ray Soucy wrote: > Thanks for this, > > Have you posted this to the VyOS project forums? It would make a nice > addition to the wiki (*cough* I've been trying to find some help to > complete the VyOS user guide). > > > On Tue, May 13, 2014 at 5:10 AM, Naoto MATSUMOTO > wrote: > > > Hi all! > > > > > > We wrote TIPS memo about the Basic Idea for inter-cloud networking using > > Virtual Router (a.k.a Brocade Vyatta vRotuer and VyOS) with High > > Availability > > Concept. > > > > Please enjoy it if you interest in ;-) > > > > Unbreakable VPN using Vyatta/VyOS -HOW TO- > > http://slidesha.re/1lryGVU > > > > Best Regards, > > > > -- > > SAKURA Internet Inc. / Senior Researcher > > Naoto MATSUMOTO > > SAKURA Internet Research Center > > > > > > > -- > 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 -- SAKURA Internet Inc. / Senior Researcher Naoto MATSUMOTO SAKURA Internet Research Center From owen at delong.com Thu May 15 14:26:43 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 15 May 2014 07:26:43 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <37AFC907-CAB5-4721-B79D-EAE2687970BF@puck.nether.net> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> , <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <37AFC907-CAB5-4721-B79D-EAE2687970BF@puck.nether.net> Message-ID: <74642389-7742-406C-9FC4-C0B0B4940136@delong.com> I don’t disagree. However, given the choice between Comcast and broadband services in NL, Chatanooga, or Seoul, just to name a few, Comcast loses badly. Choosing between Comcast and a legacy Telco is like choosing between legionnaire’s disease and SARS. Owen On May 14, 2014, at 5:15 PM, Jared Mauch wrote: > Owen, > > I've seen a vast difference between Comcast and others in the "marketplace". Right now, if I had the choice between Comcast and a "legacy" telco, I would pick Comcast hands-down for: > > a) performance > b) IPv6 support > c) willingness to work on issues > > - Jared > > On May 14, 2014, at 5:14 PM, McElearney, Kevin wrote: > >> Respectfully, this is a highly inaccurate "sound bite" >> >> - Kevin >> >> 215-313-1083 >> >>> On May 14, 2014, at 3:05 PM, "Owen DeLong" wrote: >>> >>> Yes, the more accurate statement would be aggressively seeking new >>> ways to monetize the existing infrastructure without investing in upgrades >>> or additional buildout any more than absolutely necessary. >>> >>> Owen >>> >>> On May 14, 2014, at 8:02 AM, Hugo Slabbert wrote: >>> >>>>> >>>>> So they seek new sources of revenues, and/or attempt to thwart >>>>>> competition any way they can. >>>> No to the first. Yes to the second. If they were seeking new sources of >>>>> revenue, they'd be massively expanding into un/der served markets and >>>>> aggressively growing over the top services (which are fat margin). >>>> >>>> Sure they are (seeking new sources of revenue). They're not necessarily >>>> creating new products or services, i.e. actually adding any value, but they >>>> are finding ways to extract additional revenue from the same pipes, e.g. >>>> through paid peering with content providers. >>>> >>>> I'm not endorsing this; just pointing out that you two are actually in >>>> agreement here. >>>> >>>> -- >>>> Hugo >>>> >>>> >>>>> On Wed, May 14, 2014 at 7:23 AM, wrote: >>>>> >>>>>> On 2014-05-14 02:04, Jean-Francois Mezei wrote: >>>>>> >>>>>> On 14-05-13 22:50, Daniel Staal wrote: >>>>>> >>>>>> They have the money. They have the ability to get more money. *They see >>>>>>> no reason to spend money making customers happy.* They can make more >>>>>>> profit without it. >>>>>> >>>>>> There is the issue of control over the market. But also the pressure >>>>>> from shareholders for continued growth. >>>>> >>>>> >>>>> Yes. That is true. Except that it's not. >>>>> >>>>> How do service providers grow? Let's explore that: >>>>> >>>>> What is growth for a transit provider? >>>>> >>>>> More (new) access network(s) (connections). >>>>> More bandwidth across backbone pipes. >>>>> >>>>> >>>>> What is growth for access network? >>>>> More subscribers. >>>>> >>>>> Except that the incumbent carriers have shown they have no interest in >>>>> providing decent bandwidth to anywhere but the most profitable rate >>>>> centers. I'd say about 2/3 of the USA is served with quite terrible access. >>>>> >>>>> >>>>> >>>>> >>>>>> The problem with the internet is that while it had promises of wild >>>>>> growth in the 90s and 00s, once penetration reaches a certain level, >>>>>> growth stabilizes. >>>>> >>>>> Penetration is ABYSMAL sir. Huge swaths of underserved americans exist. >>>>> >>>>> >>>>> >>>>>> When you combine this with threath to large incumbents's media and media >>>>>> distribution endeavours by the likes of Netflix (and cat videos on >>>>>> Youtube), large incumbents start thinking about how they will be able to >>>>>> continue to grow revenus/profits when customers will shift spending to >>>>>> vspecialty channels/cableTV to Netflix and customer growth will not >>>>>> compensate. >>>>> >>>>> Except they aren't. Even in the most profitable rate centers, they've >>>>> declined to really invest in the networks. They aren't a real business. You >>>>> have to remember that. They have regulatory capture, natural/defacto >>>>> monopoly etc etc. They don't operate in the real world of >>>>> risk/reward/profit/loss/uncertainty like any other real business has to. >>>>> >>>>> >>>>> >>>>>> So they seek new sources of revenues, and/or attempt to thwart >>>>>> competition any way they can. >>>>> >>>>> No to the first. Yes to the second. If they were seeking new sources of >>>>> revenue, they'd be massively expanding into un/der served markets and >>>>> aggressively growing over the top services (which are fat margin). They did >>>>> a bit of an advertising campaign of "smart home" offerings, but that seems >>>>> to have never grown beyond a pilot. >>>>> >>>>> >>>>> >>>>>> The current trend is to "if you can't fight them, jon them" where >>>>>> cablecos start to include the Netflix app into their proprietary set-top >>>>>> boxes. The idea is that you at least make the customer continue to use >>>>>> your box and your remote control which makes it easier for them to >>>>>> switch between netflix and legacy TV. >>>>> True. I don't know why one of the cablecos hasn't licensed roku, added >>>>> cable card and made that available as a "hip/cool" set top box offering and >>>>> charge another 10.00 a month on top of the standard dvr rental. >>>>> >>>>> >>>>> >>>>> Would be interesting to see if those cable companies that are agreeing >>>>>> to add the Netflix app onto their proprietary STBs also play peering >>>>>> capacity games to degrade the service or not. >>>>> >>>>> So how is the content delivered? Is it over the internet? Or is it over >>>>> the cable plant, from cable headends? >>> From owen at delong.com Thu May 15 14:29:06 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 15 May 2014 07:29:06 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <20140515010512.GB10673@hezmatt.org> References: <536BBC62.4070805@KingsMountain.com> <1lUt1o01g1cZc5601lUvWZ> <537403E0.5050502@cox.net> <20140515010512.GB10673@hezmatt.org> Message-ID: <2EF85817-700B-46E7-A3E8-B73899C7A18F@delong.com> Having an actual free market would require having competition. So long as we have monopoly layer 1 providers being allowed to use that monopoly as leverage for higher layer service monopolies, (or oligopolies), an actual free market is virtually impossible. The result of deregulating the current environment would only be more pain and cost to the consumer than we currently have with no improvement in speeds or capabilities and no additional innovation. Owen On May 14, 2014, at 6:05 PM, Matt Palmer wrote: > On Wed, May 14, 2014 at 07:01:36PM -0500, Larry Sheldon wrote: >> Maybe it is time to try a free market. > > Can't do that, it would be UnAmerican! > > - Matt > > -- > I can only guess that the designer of the things had a major Toilet Duck > habit and had managed to score a couple of industrial-sized bottles of the > stuff the night before. > -- Tanuki From Kevin_McElearney at cable.comcast.com Thu May 15 14:57:22 2014 From: Kevin_McElearney at cable.comcast.com (McElearney, Kevin) Date: Thu, 15 May 2014 14:57:22 +0000 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> , <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com>, <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> Message-ID: <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> Upgrades/buildout are happening every day. They are continuous to keep ahead of demand and publicly measured by SamKnows (FCC measuring broadband), Akamai, Ookla, etc What is not well known is that Comcast has been an existing commercial transit business for 15+ years (with over 8000 commercial fiber customers). Comcast also has over 40 balanced peers with plenty of capacity, and some of the largest Internet companies as customers. - Kevin 215-313-1083 > On May 15, 2014, at 10:19 AM, "Owen DeLong" wrote: > > Oh, please do explicate on how this is inaccurate… > > Owen > >> On May 14, 2014, at 2:14 PM, McElearney, Kevin wrote: >> >> Respectfully, this is a highly inaccurate "sound bite" >> >> - Kevin >> >> 215-313-1083 >> >>> On May 14, 2014, at 3:05 PM, "Owen DeLong" wrote: >>> >>> Yes, the more accurate statement would be aggressively seeking new >>> ways to monetize the existing infrastructure without investing in upgrades >>> or additional buildout any more than absolutely necessary. >>> >>> Owen >>> >>> On May 14, 2014, at 8:02 AM, Hugo Slabbert wrote: >>> >>>>> >>>>> So they seek new sources of revenues, and/or attempt to thwart >>>>>> competition any way they can. >>>> No to the first. Yes to the second. If they were seeking new sources of >>>>> revenue, they'd be massively expanding into un/der served markets and >>>>> aggressively growing over the top services (which are fat margin). >>>> >>>> Sure they are (seeking new sources of revenue). They're not necessarily >>>> creating new products or services, i.e. actually adding any value, but they >>>> are finding ways to extract additional revenue from the same pipes, e.g. >>>> through paid peering with content providers. >>>> >>>> I'm not endorsing this; just pointing out that you two are actually in >>>> agreement here. >>>> >>>> -- >>>> Hugo >>>> >>>> >>>>>> On Wed, May 14, 2014 at 7:23 AM, wrote: >>>>>> >>>>>> On 2014-05-14 02:04, Jean-Francois Mezei wrote: >>>>>> >>>>>> On 14-05-13 22:50, Daniel Staal wrote: >>>>>> >>>>>> They have the money. They have the ability to get more money. *They see >>>>>>> no reason to spend money making customers happy.* They can make more >>>>>>> profit without it. >>>>>> >>>>>> There is the issue of control over the market. But also the pressure >>>>>> from shareholders for continued growth. >>>>> >>>>> >>>>> Yes. That is true. Except that it's not. >>>>> >>>>> How do service providers grow? Let's explore that: >>>>> >>>>> What is growth for a transit provider? >>>>> >>>>> More (new) access network(s) (connections). >>>>> More bandwidth across backbone pipes. >>>>> >>>>> >>>>> What is growth for access network? >>>>> More subscribers. >>>>> >>>>> Except that the incumbent carriers have shown they have no interest in >>>>> providing decent bandwidth to anywhere but the most profitable rate >>>>> centers. I'd say about 2/3 of the USA is served with quite terrible access. >>>>> >>>>> >>>>> >>>>> >>>>>> The problem with the internet is that while it had promises of wild >>>>>> growth in the 90s and 00s, once penetration reaches a certain level, >>>>>> growth stabilizes. >>>>> >>>>> Penetration is ABYSMAL sir. Huge swaths of underserved americans exist. >>>>> >>>>> >>>>> >>>>>> When you combine this with threath to large incumbents's media and media >>>>>> distribution endeavours by the likes of Netflix (and cat videos on >>>>>> Youtube), large incumbents start thinking about how they will be able to >>>>>> continue to grow revenus/profits when customers will shift spending to >>>>>> vspecialty channels/cableTV to Netflix and customer growth will not >>>>>> compensate. >>>>> >>>>> Except they aren't. Even in the most profitable rate centers, they've >>>>> declined to really invest in the networks. They aren't a real business. You >>>>> have to remember that. They have regulatory capture, natural/defacto >>>>> monopoly etc etc. They don't operate in the real world of >>>>> risk/reward/profit/loss/uncertainty like any other real business has to. >>>>> >>>>> >>>>> >>>>>> So they seek new sources of revenues, and/or attempt to thwart >>>>>> competition any way they can. >>>>> >>>>> No to the first. Yes to the second. If they were seeking new sources of >>>>> revenue, they'd be massively expanding into un/der served markets and >>>>> aggressively growing over the top services (which are fat margin). They did >>>>> a bit of an advertising campaign of "smart home" offerings, but that seems >>>>> to have never grown beyond a pilot. >>>>> >>>>> >>>>> >>>>>> The current trend is to "if you can't fight them, jon them" where >>>>>> cablecos start to include the Netflix app into their proprietary set-top >>>>>> boxes. The idea is that you at least make the customer continue to use >>>>>> your box and your remote control which makes it easier for them to >>>>>> switch between netflix and legacy TV. >>>>> True. I don't know why one of the cablecos hasn't licensed roku, added >>>>> cable card and made that available as a "hip/cool" set top box offering and >>>>> charge another 10.00 a month on top of the standard dvr rental. >>>>> >>>>> >>>>> >>>>> Would be interesting to see if those cable companies that are agreeing >>>>>> to add the Netflix app onto their proprietary STBs also play peering >>>>>> capacity games to degrade the service or not. >>>>> >>>>> So how is the content delivered? Is it over the internet? Or is it over >>>>> the cable plant, from cable headends? > From mi.netops at gmail.com Thu May 15 15:10:16 2014 From: mi.netops at gmail.com (Metro-Inet Netops) Date: Thu, 15 May 2014 10:10:16 -0500 Subject: Possible Comcast Load Balancing issues in Chicago? Message-ID: It’s possible I’m missing something, but it looks like traffic from Comcast business customers in the Minneapolis/St. Paul area is not all making it through Chicago to my VPN endpoints. Testing to some of my address space from one of the Comcast remote VPN sites, I can get to some numbers and not others (odds/evens switch roles depending on the block I trace) fall apart hopping though Chicago. Testing to the same addresses from the HE looking glass, everything seems fine. Any input or even knowledge that it’s being worked on would be appreciated. Traceroutes below: Fails: HUGO-CH-2921#trace 199.249.109.13 Type escape sequence to abort. Tracing the route to vpn.metro-inet.us (199.249.109.13) VRF info: (vrf in name/id, vrf out name/id) 1 75-149-158-38-minnesota.hfc.comcastbusiness.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 12 msec 12 msec 16 msec 3 te-4-2-ur02.whitebear.mn.minn.comcast.net (68.85.167.37) 16 msec 16 msec 16 msec 4 te-2-1-ur02.oakdale.mn.minn.comcast.net (68.87.174.138) 16 msec 16 msec 16 msec 5 te-8-3-ur01.oakdale.mn.minn.comcast.net (68.87.174.109) 20 msec 12 msec 16 msec 6 te-0-3-0-5-ar01.crosstown.mn.minn.comcast.net (69.139.176.61) 16 msec 16 msec 20 msec 7 pos-0-0-0-0-ar01.roseville.mn.minn.comcast.net (68.87.174.194) 16 msec 16 msec 12 msec 8 he-1-12-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.77) 24 msec 24 msec 28 msec 9 * * * 10 * Gets Through: HUGO-CH-2921#trace 199.249.109.14 Type escape sequence to abort. Tracing the route to 199.249.109.14 VRF info: (vrf in name/id, vrf out name/id) 1 75-149-158-38-minnesota.hfc.comcastbusiness.net (75.149.158.38) 4 msec 0 msec 0 msec 2 73.237.168.1 8 msec 12 msec 8 msec 3 te-4-2-ur01.whitebear.mn.minn.comcast.net (68.85.167.33) 12 msec 12 msec 12 msec 4 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 12 msec 12 msec 5 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 12 msec 8 msec 8 msec 6 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 12 msec 12 msec 12 msec 7 he-1-11-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.73) 28 msec 20 msec 24 msec 8 ix-7-0-3-0.tcore1.CT8-Chicago.as6453.net (64.86.137.33) 16 msec 16 msec 20 msec 9 206.82.141.90 20 msec 20 msec 20 msec 10 hurricane-ic-124397-chi-bb1.c.telia.net (213.248.104.214) 24 msec 24 msec 28 msec 11 100ge13-1.core1.msp1.he.net (184.105.223.178) 36 msec 24 msec 28 msec 12 city-of-roseville.gigabitethernet3-8.core1.msp1.he.net (184.105.249.218) 28 msec 28 msec 24 msec 13 199.249.109.227 28 msec 24 msec 28 msec Gets Through: HUGO-CH-2921#trace 67.88.181.25 Type escape sequence to abort. Tracing the route to ip67-88-181-25.z181-88-67.customer.algx.net(67.88.181.25) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 8 msec 8 msec 8 msec 3 te-4-2-ur01.whitebear.mn.minn.comcast.net (68.85.167.33) 12 msec 12 msec 8 msec 4 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 8 msec 12 msec 5 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 12 msec 12 msec 8 msec 6 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 8 msec 12 msec 12 msec 7 he-1-12-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.77) 24 msec 20 msec 16 msec 8 ix-2-3-0-0.tcore1.CT8-Chicago.as6453.net (64.86.137.41) 24 msec 16 msec 40 msec 9 p5-1.ir1.chicago2-il.us.xo.net (206.111.2.33) 68 msec 20 msec 80 msec 10 207.88.14.193.ptr.us.xo.net (207.88.14.193) 32 msec 32 msec 36 msec 11 ae0d0.mcr1.minneapolis-mn.us.xo.net (216.156.0.170) 28 msec 28 msec 28 msec Fails: HUGO-CH-2921#trace 67.88.181.26 Type escape sequence to abort. Tracing the route to webvpn.metro-inet.us (67.88.181.26) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 8 msec 8 msec 8 msec 3 te-4-2-ur02.whitebear.mn.minn.comcast.net (68.85.167.37) 8 msec 12 msec 8 msec 4 te-2-1-ur02.oakdale.mn.minn.comcast.net (68.87.174.138) 8 msec 12 msec 20 msec 5 te-8-3-ur01.oakdale.mn.minn.comcast.net (68.87.174.109) 8 msec 8 msec 12 msec 6 te-0-3-0-5-ar01.crosstown.mn.minn.comcast.net (69.139.176.61) 12 msec 12 msec 12 msec 7 pos-0-1-0-0-ar01.roseville.mn.minn.comcast.net (68.87.174.2) 8 msec 8 msec 12 msec 8 he-1-13-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.81) 24 msec 24 msec 20 msec 9 * * * 10 * * * 11 * * * 12 * * * Gets Through: HUGO-CH-2921#trace 67.88.181.27 Type escape sequence to abort. Tracing the route to ip67-88-181-27.z181-88-67.customer.algx.net(67.88.181.27) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 4 msec 0 msec 4 msec 2 73.237.168.1 8 msec 12 msec 8 msec 3 te-4-2-ur02.whitebear.mn.minn.comcast.net (68.85.167.37) 12 msec 12 msec 8 msec 4 te-8-3-ur01.whitebear.mn.minn.comcast.net (68.87.174.133) 12 msec 12 msec 4 msec 5 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 12 msec 8 msec 6 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 16 msec 8 msec 8 msec 7 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 12 msec 12 msec 16 msec 8 he-1-13-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.81) 20 msec 20 msec 20 msec 9 ix-2-2-1-0.tcore1.CT8-Chicago.as6453.net (64.86.137.37) 16 msec 16 msec 16 msec 10 p5-1.ir1.chicago2-il.us.xo.net (206.111.2.33) 32 msec 72 msec 96 msec 11 207.88.14.193.ptr.us.xo.net (207.88.14.193) 36 msec 32 msec 32 msec 12 ae0d0.mcr1.minneapolis-mn.us.xo.net (216.156.0.170) 28 msec 28 msec 32 msec 13 * * * Fails: HUGO-CH-2921#trace 67.88.181.28 Type escape sequence to abort. Tracing the route to ip67-88-181-28.z181-88-67.customer.algx.net(67.88.181.28) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 12 msec 8 msec 12 msec 3 te-4-2-ur01.whitebear.mn.minn.comcast.net (68.85.167.33) 8 msec 8 msec 8 msec 4 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 8 msec 12 msec 5 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 12 msec 8 msec 8 msec 6 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 12 msec 12 msec 12 msec 7 he-1-11-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.73) 20 msec 20 msec 20 msec 8 * * * 9 * * * 10 * Mark Mayfield City of Roseville – AS 54371 Network Systems Engineer 2660 Civic Center Drive Roseville, MN 55113 651-792-7098 Office From Courtney_Smith at Cable.Comcast.com Thu May 15 15:31:44 2014 From: Courtney_Smith at Cable.Comcast.com (Smith, Courtney) Date: Thu, 15 May 2014 15:31:44 +0000 Subject: Possible Comcast Load Balancing issues in Chicago? In-Reply-To: References: Message-ID: <8DD18D69FFC6DB46AE9CDB191CD8B981602B74EA@PACDCEXMB04.cable.comcast.com> Looking into. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Metro-Inet Netops Sent: Thursday, May 15, 2014 11:10 AM To: nanog at nanog.org Subject: Possible Comcast Load Balancing issues in Chicago? It’s possible I’m missing something, but it looks like traffic from Comcast business customers in the Minneapolis/St. Paul area is not all making it through Chicago to my VPN endpoints. Testing to some of my address space from one of the Comcast remote VPN sites, I can get to some numbers and not others (odds/evens switch roles depending on the block I trace) fall apart hopping though Chicago. Testing to the same addresses from the HE looking glass, everything seems fine. Any input or even knowledge that it’s being worked on would be appreciated. Traceroutes below: Fails: HUGO-CH-2921#trace 199.249.109.13 Type escape sequence to abort. Tracing the route to vpn.metro-inet.us (199.249.109.13) VRF info: (vrf in name/id, vrf out name/id) 1 75-149-158-38-minnesota.hfc.comcastbusiness.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 12 msec 12 msec 16 msec 3 te-4-2-ur02.whitebear.mn.minn.comcast.net (68.85.167.37) 16 msec 16 msec 16 msec 4 te-2-1-ur02.oakdale.mn.minn.comcast.net (68.87.174.138) 16 msec 16 msec 16 msec 5 te-8-3-ur01.oakdale.mn.minn.comcast.net (68.87.174.109) 20 msec 12 msec 16 msec 6 te-0-3-0-5-ar01.crosstown.mn.minn.comcast.net (69.139.176.61) 16 msec 16 msec 20 msec 7 pos-0-0-0-0-ar01.roseville.mn.minn.comcast.net (68.87.174.194) 16 msec 16 msec 12 msec 8 he-1-12-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.77) 24 msec 24 msec 28 msec 9 * * * 10 * Gets Through: HUGO-CH-2921#trace 199.249.109.14 Type escape sequence to abort. Tracing the route to 199.249.109.14 VRF info: (vrf in name/id, vrf out name/id) 1 75-149-158-38-minnesota.hfc.comcastbusiness.net (75.149.158.38) 4 msec 0 msec 0 msec 2 73.237.168.1 8 msec 12 msec 8 msec 3 te-4-2-ur01.whitebear.mn.minn.comcast.net (68.85.167.33) 12 msec 12 msec 12 msec 4 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 12 msec 12 msec 5 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 12 msec 8 msec 8 msec 6 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 12 msec 12 msec 12 msec 7 he-1-11-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.73) 28 msec 20 msec 24 msec 8 ix-7-0-3-0.tcore1.CT8-Chicago.as6453.net (64.86.137.33) 16 msec 16 msec 20 msec 9 206.82.141.90 20 msec 20 msec 20 msec 10 hurricane-ic-124397-chi-bb1.c.telia.net (213.248.104.214) 24 msec 24 msec 28 msec 11 100ge13-1.core1.msp1.he.net (184.105.223.178) 36 msec 24 msec 28 msec 12 city-of-roseville.gigabitethernet3-8.core1.msp1.he.net (184.105.249.218) 28 msec 28 msec 24 msec 13 199.249.109.227 28 msec 24 msec 28 msec Gets Through: HUGO-CH-2921#trace 67.88.181.25 Type escape sequence to abort. Tracing the route to ip67-88-181-25.z181-88-67.customer.algx.net(67.88.181.25) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 8 msec 8 msec 8 msec 3 te-4-2-ur01.whitebear.mn.minn.comcast.net (68.85.167.33) 12 msec 12 msec 8 msec 4 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 8 msec 12 msec 5 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 12 msec 12 msec 8 msec 6 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 8 msec 12 msec 12 msec 7 he-1-12-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.77) 24 msec 20 msec 16 msec 8 ix-2-3-0-0.tcore1.CT8-Chicago.as6453.net (64.86.137.41) 24 msec 16 msec 40 msec 9 p5-1.ir1.chicago2-il.us.xo.net (206.111.2.33) 68 msec 20 msec 80 msec 10 207.88.14.193.ptr.us.xo.net (207.88.14.193) 32 msec 32 msec 36 msec 11 ae0d0.mcr1.minneapolis-mn.us.xo.net (216.156.0.170) 28 msec 28 msec 28 msec Fails: HUGO-CH-2921#trace 67.88.181.26 Type escape sequence to abort. Tracing the route to webvpn.metro-inet.us (67.88.181.26) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 8 msec 8 msec 8 msec 3 te-4-2-ur02.whitebear.mn.minn.comcast.net (68.85.167.37) 8 msec 12 msec 8 msec 4 te-2-1-ur02.oakdale.mn.minn.comcast.net (68.87.174.138) 8 msec 12 msec 20 msec 5 te-8-3-ur01.oakdale.mn.minn.comcast.net (68.87.174.109) 8 msec 8 msec 12 msec 6 te-0-3-0-5-ar01.crosstown.mn.minn.comcast.net (69.139.176.61) 12 msec 12 msec 12 msec 7 pos-0-1-0-0-ar01.roseville.mn.minn.comcast.net (68.87.174.2) 8 msec 8 msec 12 msec 8 he-1-13-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.81) 24 msec 24 msec 20 msec 9 * * * 10 * * * 11 * * * 12 * * * Gets Through: HUGO-CH-2921#trace 67.88.181.27 Type escape sequence to abort. Tracing the route to ip67-88-181-27.z181-88-67.customer.algx.net(67.88.181.27) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 4 msec 0 msec 4 msec 2 73.237.168.1 8 msec 12 msec 8 msec 3 te-4-2-ur02.whitebear.mn.minn.comcast.net (68.85.167.37) 12 msec 12 msec 8 msec 4 te-8-3-ur01.whitebear.mn.minn.comcast.net (68.87.174.133) 12 msec 12 msec 4 msec 5 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 12 msec 8 msec 6 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 16 msec 8 msec 8 msec 7 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 12 msec 12 msec 16 msec 8 he-1-13-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.81) 20 msec 20 msec 20 msec 9 ix-2-2-1-0.tcore1.CT8-Chicago.as6453.net (64.86.137.37) 16 msec 16 msec 16 msec 10 p5-1.ir1.chicago2-il.us.xo.net (206.111.2.33) 32 msec 72 msec 96 msec 11 207.88.14.193.ptr.us.xo.net (207.88.14.193) 36 msec 32 msec 32 msec 12 ae0d0.mcr1.minneapolis-mn.us.xo.net (216.156.0.170) 28 msec 28 msec 32 msec 13 * * * Fails: HUGO-CH-2921#trace 67.88.181.28 Type escape sequence to abort. Tracing the route to ip67-88-181-28.z181-88-67.customer.algx.net(67.88.181.28) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 12 msec 8 msec 12 msec 3 te-4-2-ur01.whitebear.mn.minn.comcast.net (68.85.167.33) 8 msec 8 msec 8 msec 4 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 8 msec 12 msec 5 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 12 msec 8 msec 8 msec 6 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 12 msec 12 msec 12 msec 7 he-1-11-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.73) 20 msec 20 msec 20 msec 8 * * * 9 * * * 10 * Mark Mayfield City of Roseville – AS 54371 Network Systems Engineer 2660 Civic Center Drive Roseville, MN 55113 651-792-7098 Office From scott at sberkman.net Thu May 15 15:41:07 2014 From: scott at sberkman.net (Scott Berkman) Date: Thu, 15 May 2014 11:41:07 -0400 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> , <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com>, <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> Message-ID: <5374E013.1050708@sberkman.net> Unfortunately these build-outs are primarily in subscriber facing bandwidth and number of headend locations (to add more customers to the network). These peering point/transit connection issues have been going on for a long time, evidenced by Level 3 coming out with this post. Comcast is also suspiciously absent from public exchanges (TelX's TIE would be one example) while many of their competitors participate for the benefit of the Internet as a whole and their customers. Measured broadband is also a game, because its very easy for large providers to give priority to (or otherwise "help") known speed test and similar sites, giving customers a false impression of their available capacity or performance. We've all seen cases where customers have some amazing result on their favorite test site, and then real world performance can't even come close. That said, if Comcast does or is making efforts to finally resolve this, more power to them and congratulations to their customers. Unfortunately trying to brute-force the industry and external content providers tells a very different story. Where is Comcast's official blog post showing evidence as to where they do ensure their peering and or transit to the largest Tier 1 providers are not congested? Instead all we see are policy arguments about who should pay for what, while users continue to suffer. This is really similar to when TV providers have spats with content owners, and the result is the end users missing out on something they are paying for. It is good for related industries and the large players in each to keep working with each other in open ways to keep pricing reasonable (as opposed to working together in hiding to price fix), but it is not OK to do so by throwing tantrums and making everyone involved suffer. -Scott On 05/15/2014 10:57 AM, McElearney, Kevin wrote: > Upgrades/buildout are happening every day. They are continuous to keep ahead of demand and publicly measured by SamKnows (FCC measuring broadband), Akamai, Ookla, etc > > What is not well known is that Comcast has been an existing commercial transit business for 15+ years (with over 8000 commercial fiber customers). Comcast also has over 40 balanced peers with plenty of capacity, and some of the largest Internet companies as customers. > > - Kevin > > 215-313-1083 > >> On May 15, 2014, at 10:19 AM, "Owen DeLong" wrote: >> >> Oh, please do explicate on how this is inaccurate… >> >> Owen >> >>> On May 14, 2014, at 2:14 PM, McElearney, Kevin wrote: >>> >>> Respectfully, this is a highly inaccurate "sound bite" >>> >>> - Kevin >>> >>> 215-313-1083 >>> >>>> On May 14, 2014, at 3:05 PM, "Owen DeLong" wrote: >>>> >>>> Yes, the more accurate statement would be aggressively seeking new >>>> ways to monetize the existing infrastructure without investing in upgrades >>>> or additional buildout any more than absolutely necessary. >>>> >>>> Owen >>>> >>>> On May 14, 2014, at 8:02 AM, Hugo Slabbert wrote: >>>> >>>>>> So they seek new sources of revenues, and/or attempt to thwart >>>>>>> competition any way they can. >>>>> No to the first. Yes to the second. If they were seeking new sources of >>>>>> revenue, they'd be massively expanding into un/der served markets and >>>>>> aggressively growing over the top services (which are fat margin). >>>>> Sure they are (seeking new sources of revenue). They're not necessarily >>>>> creating new products or services, i.e. actually adding any value, but they >>>>> are finding ways to extract additional revenue from the same pipes, e.g. >>>>> through paid peering with content providers. >>>>> >>>>> I'm not endorsing this; just pointing out that you two are actually in >>>>> agreement here. >>>>> >>>>> -- >>>>> Hugo >>>>> >>>>> >>>>>>> On Wed, May 14, 2014 at 7:23 AM, wrote: >>>>>>> >>>>>>> On 2014-05-14 02:04, Jean-Francois Mezei wrote: >>>>>>> >>>>>>> On 14-05-13 22:50, Daniel Staal wrote: >>>>>>> >>>>>>> They have the money. They have the ability to get more money. *They see >>>>>>>> no reason to spend money making customers happy.* They can make more >>>>>>>> profit without it. >>>>>>> There is the issue of control over the market. But also the pressure >>>>>>> from shareholders for continued growth. >>>>>> >>>>>> Yes. That is true. Except that it's not. >>>>>> >>>>>> How do service providers grow? Let's explore that: >>>>>> >>>>>> What is growth for a transit provider? >>>>>> >>>>>> More (new) access network(s) (connections). >>>>>> More bandwidth across backbone pipes. >>>>>> >>>>>> >>>>>> What is growth for access network? >>>>>> More subscribers. >>>>>> >>>>>> Except that the incumbent carriers have shown they have no interest in >>>>>> providing decent bandwidth to anywhere but the most profitable rate >>>>>> centers. I'd say about 2/3 of the USA is served with quite terrible access. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> The problem with the internet is that while it had promises of wild >>>>>>> growth in the 90s and 00s, once penetration reaches a certain level, >>>>>>> growth stabilizes. >>>>>> Penetration is ABYSMAL sir. Huge swaths of underserved americans exist. >>>>>> >>>>>> >>>>>> >>>>>>> When you combine this with threath to large incumbents's media and media >>>>>>> distribution endeavours by the likes of Netflix (and cat videos on >>>>>>> Youtube), large incumbents start thinking about how they will be able to >>>>>>> continue to grow revenus/profits when customers will shift spending to >>>>>>> vspecialty channels/cableTV to Netflix and customer growth will not >>>>>>> compensate. >>>>>> Except they aren't. Even in the most profitable rate centers, they've >>>>>> declined to really invest in the networks. They aren't a real business. You >>>>>> have to remember that. They have regulatory capture, natural/defacto >>>>>> monopoly etc etc. They don't operate in the real world of >>>>>> risk/reward/profit/loss/uncertainty like any other real business has to. >>>>>> >>>>>> >>>>>> >>>>>>> So they seek new sources of revenues, and/or attempt to thwart >>>>>>> competition any way they can. >>>>>> No to the first. Yes to the second. If they were seeking new sources of >>>>>> revenue, they'd be massively expanding into un/der served markets and >>>>>> aggressively growing over the top services (which are fat margin). They did >>>>>> a bit of an advertising campaign of "smart home" offerings, but that seems >>>>>> to have never grown beyond a pilot. >>>>>> >>>>>> >>>>>> >>>>>>> The current trend is to "if you can't fight them, jon them" where >>>>>>> cablecos start to include the Netflix app into their proprietary set-top >>>>>>> boxes. The idea is that you at least make the customer continue to use >>>>>>> your box and your remote control which makes it easier for them to >>>>>>> switch between netflix and legacy TV. >>>>>> True. I don't know why one of the cablecos hasn't licensed roku, added >>>>>> cable card and made that available as a "hip/cool" set top box offering and >>>>>> charge another 10.00 a month on top of the standard dvr rental. >>>>>> >>>>>> >>>>>> >>>>>> Would be interesting to see if those cable companies that are agreeing >>>>>>> to add the Netflix app onto their proprietary STBs also play peering >>>>>>> capacity games to degrade the service or not. >>>>>> So how is the content delivered? Is it over the internet? Or is it over >>>>>> the cable plant, from cable headends? From Kevin_McElearney at cable.comcast.com Thu May 15 15:50:56 2014 From: Kevin_McElearney at cable.comcast.com (McElearney, Kevin) Date: Thu, 15 May 2014 15:50:56 +0000 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <5374E013.1050708@sberkman.net> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> , <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com>, <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com>, <5374E013.1050708@sberkman.net> Message-ID: <8AFC1EC8-5F2E-4645-B57C-A147FC56B390@cable.comcast.com> There is no gaming on measurements and disputes are isolated and temporary with issues not unique over the history of the internet. I think all the same rhetorical quotes continue to be reused - Kevin > On May 15, 2014, at 11:43 AM, "Scott Berkman" wrote: > > Unfortunately these build-outs are primarily in subscriber facing bandwidth and number of headend locations (to add more customers to the network). These peering point/transit connection issues have been going on for a long time, evidenced by Level 3 coming out with this post. Comcast is also suspiciously absent from public exchanges (TelX's TIE would be one example) while many of their competitors participate for the benefit of the Internet as a whole and their customers. > > Measured broadband is also a game, because its very easy for large providers to give priority to (or otherwise "help") known speed test and similar sites, giving customers a false impression of their available capacity or performance. We've all seen cases where customers have some amazing result on their favorite test site, and then real world performance can't even come close. > > That said, if Comcast does or is making efforts to finally resolve this, more power to them and congratulations to their customers. Unfortunately trying to brute-force the industry and external content providers tells a very different story. Where is Comcast's official blog post showing evidence as to where they do ensure their peering and or transit to the largest Tier 1 providers are not congested? Instead all we see are policy arguments about who should pay for what, while users continue to suffer. > > This is really similar to when TV providers have spats with content owners, and the result is the end users missing out on something they are paying for. It is good for related industries and the large players in each to keep working with each other in open ways to keep pricing reasonable (as opposed to working together in hiding to price fix), but it is not OK to do so by throwing tantrums and making everyone involved suffer. > > -Scott > > >> On 05/15/2014 10:57 AM, McElearney, Kevin wrote: >> Upgrades/buildout are happening every day. They are continuous to keep ahead of demand and publicly measured by SamKnows (FCC measuring broadband), Akamai, Ookla, etc >> >> What is not well known is that Comcast has been an existing commercial transit business for 15+ years (with over 8000 commercial fiber customers). Comcast also has over 40 balanced peers with plenty of capacity, and some of the largest Internet companies as customers. >> >> - Kevin >> >> 215-313-1083 >> >>> On May 15, 2014, at 10:19 AM, "Owen DeLong" wrote: >>> >>> Oh, please do explicate on how this is inaccurate… >>> >>> Owen >>> >>>> On May 14, 2014, at 2:14 PM, McElearney, Kevin wrote: >>>> >>>> Respectfully, this is a highly inaccurate "sound bite" >>>> >>>> - Kevin >>>> >>>> 215-313-1083 >>>> >>>>> On May 14, 2014, at 3:05 PM, "Owen DeLong" wrote: >>>>> >>>>> Yes, the more accurate statement would be aggressively seeking new >>>>> ways to monetize the existing infrastructure without investing in upgrades >>>>> or additional buildout any more than absolutely necessary. >>>>> >>>>> Owen >>>>> >>>>> On May 14, 2014, at 8:02 AM, Hugo Slabbert wrote: >>>>> >>>>>>> So they seek new sources of revenues, and/or attempt to thwart >>>>>>>> competition any way they can. >>>>>> No to the first. Yes to the second. If they were seeking new sources of >>>>>>> revenue, they'd be massively expanding into un/der served markets and >>>>>>> aggressively growing over the top services (which are fat margin). >>>>>> Sure they are (seeking new sources of revenue). They're not necessarily >>>>>> creating new products or services, i.e. actually adding any value, but they >>>>>> are finding ways to extract additional revenue from the same pipes, e.g. >>>>>> through paid peering with content providers. >>>>>> >>>>>> I'm not endorsing this; just pointing out that you two are actually in >>>>>> agreement here. >>>>>> >>>>>> -- >>>>>> Hugo >>>>>> >>>>>> >>>>>>>> On Wed, May 14, 2014 at 7:23 AM, wrote: >>>>>>>> >>>>>>>> On 2014-05-14 02:04, Jean-Francois Mezei wrote: >>>>>>>> >>>>>>>> On 14-05-13 22:50, Daniel Staal wrote: >>>>>>>> >>>>>>>> They have the money. They have the ability to get more money. *They see >>>>>>>>> no reason to spend money making customers happy.* They can make more >>>>>>>>> profit without it. >>>>>>>> There is the issue of control over the market. But also the pressure >>>>>>>> from shareholders for continued growth. >>>>>>> >>>>>>> Yes. That is true. Except that it's not. >>>>>>> >>>>>>> How do service providers grow? Let's explore that: >>>>>>> >>>>>>> What is growth for a transit provider? >>>>>>> >>>>>>> More (new) access network(s) (connections). >>>>>>> More bandwidth across backbone pipes. >>>>>>> >>>>>>> >>>>>>> What is growth for access network? >>>>>>> More subscribers. >>>>>>> >>>>>>> Except that the incumbent carriers have shown they have no interest in >>>>>>> providing decent bandwidth to anywhere but the most profitable rate >>>>>>> centers. I'd say about 2/3 of the USA is served with quite terrible access. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> The problem with the internet is that while it had promises of wild >>>>>>>> growth in the 90s and 00s, once penetration reaches a certain level, >>>>>>>> growth stabilizes. >>>>>>> Penetration is ABYSMAL sir. Huge swaths of underserved americans exist. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> When you combine this with threath to large incumbents's media and media >>>>>>>> distribution endeavours by the likes of Netflix (and cat videos on >>>>>>>> Youtube), large incumbents start thinking about how they will be able to >>>>>>>> continue to grow revenus/profits when customers will shift spending to >>>>>>>> vspecialty channels/cableTV to Netflix and customer growth will not >>>>>>>> compensate. >>>>>>> Except they aren't. Even in the most profitable rate centers, they've >>>>>>> declined to really invest in the networks. They aren't a real business. You >>>>>>> have to remember that. They have regulatory capture, natural/defacto >>>>>>> monopoly etc etc. They don't operate in the real world of >>>>>>> risk/reward/profit/loss/uncertainty like any other real business has to. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> So they seek new sources of revenues, and/or attempt to thwart >>>>>>>> competition any way they can. >>>>>>> No to the first. Yes to the second. If they were seeking new sources of >>>>>>> revenue, they'd be massively expanding into un/der served markets and >>>>>>> aggressively growing over the top services (which are fat margin). They did >>>>>>> a bit of an advertising campaign of "smart home" offerings, but that seems >>>>>>> to have never grown beyond a pilot. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> The current trend is to "if you can't fight them, jon them" where >>>>>>>> cablecos start to include the Netflix app into their proprietary set-top >>>>>>>> boxes. The idea is that you at least make the customer continue to use >>>>>>>> your box and your remote control which makes it easier for them to >>>>>>>> switch between netflix and legacy TV. >>>>>>> True. I don't know why one of the cablecos hasn't licensed roku, added >>>>>>> cable card and made that available as a "hip/cool" set top box offering and >>>>>>> charge another 10.00 a month on top of the standard dvr rental. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Would be interesting to see if those cable companies that are agreeing >>>>>>>> to add the Netflix app onto their proprietary STBs also play peering >>>>>>>> capacity games to degrade the service or not. >>>>>>> So how is the content delivered? Is it over the internet? Or is it over >>>>>>> the cable plant, from cable headends? > From jvanoppen at spectrumnet.us Thu May 15 15:57:57 2014 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Thu, 15 May 2014 15:57:57 +0000 Subject: NANOG 61 hotel In-Reply-To: <20140513150637.GD5268@stargate.ca> References: <20140513150637.GD5268@stargate.ca> Message-ID: The westin is for all affective purposes connected to the building where the conference is. It would be the closest, the others are a bit further, blocks are very long in Bellevue so keep that in mind when looking at the maps. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Hugo Slabbert Sent: Tuesday, May 13, 2014 8:07 AM To: nanog at nanog.org Subject: Re: NANOG 61 hotel On Tue 2014-May-13 10:32:48 -0400, Jon Lewis wrote: >The Hyatt appears to have filled up. :( > >Anyone have alternate hotel recommendations? I put together a list when I was making my pitch to go down: ! --------------- ! Westin Bellevue http://www.starwoodhotels.com/westin/rates/rate.html?propertyID=1555 - $280/room/night ! ---------------- ! Marriot Bellevue (Courtyard Seattle Bellevue/Downtown) http://www.marriott.com/hotels/travel/bvudt-courtyard-seattle-bellevue-downtown/ - $269/room/night ! ---------------- ! Silver Cloud Inn http://www.silvercloud.com/bellevuedowntown/ - $229/room/night - 2 Queens/room ! ------------------------ ! La Residence Suite Hotel http://www.bellevuelodging.com/ - $169/room/night - 2x Queens - couple of blocks away These are all within 5-10 minutes walk of the Hyatt, IIRC and if Google Maps can be trusted. Rates at some of them seem a little different from when I looked before, e.g. the Westin now read as $303/night whereas e.g. Silver Cloud shows a single king room at $189/night. > >---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are _________ >http://www.lewis.org/~jlewis/pgp for PGP public key_________ -- Hugo From jared at puck.nether.net Thu May 15 16:01:34 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 15 May 2014 12:01:34 -0400 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <8AFC1EC8-5F2E-4645-B57C-A147FC56B390@cable.comcast.com> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> , <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com>, <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com>, <5374E013.1050708@sberkman.net> <8AFC1EC8-5F2E-4645-B57C-A147FC56B390@cable.comcast.com> Message-ID: On May 15, 2014, at 11:50 AM, McElearney, Kevin wrote: > There is no gaming on measurements and disputes are isolated and temporary with issues not unique over the history of the internet. I think all the same rhetorical quotes continue to be reused > Kevin, in the past most issues were transient for a few months as both sides got complaints, but while at RIPE earlier this week someone commented to me: there's no one provider you can buy access from to get a packet-loss free connection to all their other business partners/customers. This hurts the entire marketplace when there is persistent congestion. Some of these issues are related to (as Craig called them) "Hypergiants" (OTT) but others are due to providers having poor capital models so they don't have "budget" for upgrading unless someone pays for that upgrade, vs seeing their existing customer base as that source for the capital. As an engineer, I'm hopeful that those responsible for budgeting will do the right thing. As a greedy capitalist, please pay me more $$$. It does feel a bit like tic-tac-toe with zero players in wargames though, the only way to win is to not play [games]. - Jared From Mark.Mayfield at metro-inet.us Thu May 15 16:04:00 2014 From: Mark.Mayfield at metro-inet.us (Mark Mayfield) Date: Thu, 15 May 2014 11:04:00 -0500 Subject: Possible Comcast Load Balancing issues in Chicago? In-Reply-To: <8DD18D69FFC6DB46AE9CDB191CD8B981602B74EA@PACDCEXMB04.cable.comcast.com> References: <8DD18D69FFC6DB46AE9CDB191CD8B981602B74EA@PACDCEXMB04.cable.comcast.com> Message-ID: <552495BF71B9D04D82A596A010E64CD29B3AF168C1@MIEX07MBXVM1.metro-inet.us> Seems to have cleared up about 30 minutes ago. Thanks, Mark Mayfield City of Roseville – AS 54371 Network Systems Engineer 2660 Civic Center Drive Roseville, MN 55113 651-792-7098      Office -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Smith, Courtney Sent: Thursday, May 15, 2014 10:32 AM To: Metro-Inet Netops Cc: nanog at nanog.org Subject: RE: Possible Comcast Load Balancing issues in Chicago? Looking into. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Metro-Inet Netops Sent: Thursday, May 15, 2014 11:10 AM To: nanog at nanog.org Subject: Possible Comcast Load Balancing issues in Chicago? It’s possible I’m missing something, but it looks like traffic from Comcast business customers in the Minneapolis/St. Paul area is not all making it through Chicago to my VPN endpoints. Testing to some of my address space from one of the Comcast remote VPN sites, I can get to some numbers and not others (odds/evens switch roles depending on the block I trace) fall apart hopping though Chicago. Testing to the same addresses from the HE looking glass, everything seems fine. Any input or even knowledge that it’s being worked on would be appreciated. Traceroutes below: Fails: HUGO-CH-2921#trace 199.249.109.13 Type escape sequence to abort. Tracing the route to vpn.metro-inet.us (199.249.109.13) VRF info: (vrf in name/id, vrf out name/id) 1 75-149-158-38-minnesota.hfc.comcastbusiness.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 12 msec 12 msec 16 msec 3 te-4-2-ur02.whitebear.mn.minn.comcast.net (68.85.167.37) 16 msec 16 msec 16 msec 4 te-2-1-ur02.oakdale.mn.minn.comcast.net (68.87.174.138) 16 msec 16 msec 16 msec 5 te-8-3-ur01.oakdale.mn.minn.comcast.net (68.87.174.109) 20 msec 12 msec 16 msec 6 te-0-3-0-5-ar01.crosstown.mn.minn.comcast.net (69.139.176.61) 16 msec 16 msec 20 msec 7 pos-0-0-0-0-ar01.roseville.mn.minn.comcast.net (68.87.174.194) 16 msec 16 msec 12 msec 8 he-1-12-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.77) 24 msec 24 msec 28 msec 9 * * * 10 * Gets Through: HUGO-CH-2921#trace 199.249.109.14 Type escape sequence to abort. Tracing the route to 199.249.109.14 VRF info: (vrf in name/id, vrf out name/id) 1 75-149-158-38-minnesota.hfc.comcastbusiness.net (75.149.158.38) 4 msec 0 msec 0 msec 2 73.237.168.1 8 msec 12 msec 8 msec 3 te-4-2-ur01.whitebear.mn.minn.comcast.net (68.85.167.33) 12 msec 12 msec 12 msec 4 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 12 msec 12 msec 5 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 12 msec 8 msec 8 msec 6 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 12 msec 12 msec 12 msec 7 he-1-11-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.73) 28 msec 20 msec 24 msec 8 ix-7-0-3-0.tcore1.CT8-Chicago.as6453.net (64.86.137.33) 16 msec 16 msec 20 msec 9 206.82.141.90 20 msec 20 msec 20 msec 10 hurricane-ic-124397-chi-bb1.c.telia.net (213.248.104.214) 24 msec 24 msec 28 msec 11 100ge13-1.core1.msp1.he.net (184.105.223.178) 36 msec 24 msec 28 msec 12 city-of-roseville.gigabitethernet3-8.core1.msp1.he.net (184.105.249.218) 28 msec 28 msec 24 msec 13 199.249.109.227 28 msec 24 msec 28 msec Gets Through: HUGO-CH-2921#trace 67.88.181.25 Type escape sequence to abort. Tracing the route to ip67-88-181-25.z181-88-67.customer.algx.net(67.88.181.25) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 8 msec 8 msec 8 msec 3 te-4-2-ur01.whitebear.mn.minn.comcast.net (68.85.167.33) 12 msec 12 msec 8 msec 4 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 8 msec 12 msec 5 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 12 msec 12 msec 8 msec 6 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 8 msec 12 msec 12 msec 7 he-1-12-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.77) 24 msec 20 msec 16 msec 8 ix-2-3-0-0.tcore1.CT8-Chicago.as6453.net (64.86.137.41) 24 msec 16 msec 40 msec 9 p5-1.ir1.chicago2-il.us.xo.net (206.111.2.33) 68 msec 20 msec 80 msec 10 207.88.14.193.ptr.us.xo.net (207.88.14.193) 32 msec 32 msec 36 msec 11 ae0d0.mcr1.minneapolis-mn.us.xo.net (216.156.0.170) 28 msec 28 msec 28 msec Fails: HUGO-CH-2921#trace 67.88.181.26 Type escape sequence to abort. Tracing the route to webvpn.metro-inet.us (67.88.181.26) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 8 msec 8 msec 8 msec 3 te-4-2-ur02.whitebear.mn.minn.comcast.net (68.85.167.37) 8 msec 12 msec 8 msec 4 te-2-1-ur02.oakdale.mn.minn.comcast.net (68.87.174.138) 8 msec 12 msec 20 msec 5 te-8-3-ur01.oakdale.mn.minn.comcast.net (68.87.174.109) 8 msec 8 msec 12 msec 6 te-0-3-0-5-ar01.crosstown.mn.minn.comcast.net (69.139.176.61) 12 msec 12 msec 12 msec 7 pos-0-1-0-0-ar01.roseville.mn.minn.comcast.net (68.87.174.2) 8 msec 8 msec 12 msec 8 he-1-13-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.81) 24 msec 24 msec 20 msec 9 * * * 10 * * * 11 * * * 12 * * * Gets Through: HUGO-CH-2921#trace 67.88.181.27 Type escape sequence to abort. Tracing the route to ip67-88-181-27.z181-88-67.customer.algx.net(67.88.181.27) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 4 msec 0 msec 4 msec 2 73.237.168.1 8 msec 12 msec 8 msec 3 te-4-2-ur02.whitebear.mn.minn.comcast.net (68.85.167.37) 12 msec 12 msec 8 msec 4 te-8-3-ur01.whitebear.mn.minn.comcast.net (68.87.174.133) 12 msec 12 msec 4 msec 5 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 12 msec 8 msec 6 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 16 msec 8 msec 8 msec 7 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 12 msec 12 msec 16 msec 8 he-1-13-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.81) 20 msec 20 msec 20 msec 9 ix-2-2-1-0.tcore1.CT8-Chicago.as6453.net (64.86.137.37) 16 msec 16 msec 16 msec 10 p5-1.ir1.chicago2-il.us.xo.net (206.111.2.33) 32 msec 72 msec 96 msec 11 207.88.14.193.ptr.us.xo.net (207.88.14.193) 36 msec 32 msec 32 msec 12 ae0d0.mcr1.minneapolis-mn.us.xo.net (216.156.0.170) 28 msec 28 msec 32 msec 13 * * * Fails: HUGO-CH-2921#trace 67.88.181.28 Type escape sequence to abort. Tracing the route to ip67-88-181-28.z181-88-67.customer.algx.net(67.88.181.28) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 12 msec 8 msec 12 msec 3 te-4-2-ur01.whitebear.mn.minn.comcast.net (68.85.167.33) 8 msec 8 msec 8 msec 4 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 8 msec 12 msec 5 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 12 msec 8 msec 8 msec 6 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 12 msec 12 msec 12 msec 7 he-1-11-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.73) 20 msec 20 msec 20 msec 8 * * * 9 * * * 10 * Mark Mayfield City of Roseville – AS 54371 Network Systems Engineer 2660 Civic Center Drive Roseville, MN 55113 651-792-7098 Office From Kevin_McElearney at cable.comcast.com Thu May 15 16:41:09 2014 From: Kevin_McElearney at cable.comcast.com (McElearney, Kevin) Date: Thu, 15 May 2014 16:41:09 +0000 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> , <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com>, <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com>, <5374E013.1050708@sberkman.net> <8AFC1EC8-5F2E-4645-B57C-A147FC56B390@cable.comcast.com>, Message-ID: <696D5986-AB28-4793-976D-FFE542AEB68D@cable.comcast.com> This is a smart group. If if that was true I think every internet site / service one visits from home would be a negatively impacted. That is not the case As I said before, Comcast also has over 40 balanced peers with plenty of capacity. Wholesale $$ are very small, highly competitive and only "skin in the game" to promote efficiencies - Kevin > On May 15, 2014, at 12:01 PM, "Jared Mauch" wrote: > > >> On May 15, 2014, at 11:50 AM, McElearney, Kevin wrote: >> >> There is no gaming on measurements and disputes are isolated and temporary with issues not unique over the history of the internet. I think all the same rhetorical quotes continue to be reused > > Kevin, > > in the past most issues were transient for a few months as both sides got complaints, but while at RIPE earlier this week someone commented to me: there's no one provider you can buy access from to get a packet-loss free connection to all their other business partners/customers. This hurts the entire marketplace when there is persistent congestion. > > Some of these issues are related to (as Craig called them) "Hypergiants" (OTT) but others are due to providers having poor capital models so they don't have "budget" for upgrading unless someone pays for that upgrade, vs seeing their existing customer base as that source for the capital. > > As an engineer, I'm hopeful that those responsible for budgeting will do the right thing. As a greedy capitalist, please pay me more $$$. It does feel a bit like tic-tac-toe with zero players in wargames though, the only way to win is to not play [games]. > > - Jared > From nick at pelagiris.org Thu May 15 16:43:02 2014 From: nick at pelagiris.org (Nick B) Date: Thu, 15 May 2014 12:43:02 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> Message-ID: Yes, you've got "some of the largest Internet companies as customers". Because you told them "if you don't pay us, we'll throttle you". Then you throttled them. I'm sorry, not a winning argument. Nick On Thu, May 15, 2014 at 10:57 AM, McElearney, Kevin < Kevin_McElearney at cable.comcast.com> wrote: > Upgrades/buildout are happening every day. They are continuous to keep > ahead of demand and publicly measured by SamKnows (FCC measuring > broadband), Akamai, Ookla, etc > > What is not well known is that Comcast has been an existing commercial > transit business for 15+ years (with over 8000 commercial fiber customers). > Comcast also has over 40 balanced peers with plenty of capacity, and some > of the largest Internet companies as customers. > > - Kevin > > 215-313-1083 > > > On May 15, 2014, at 10:19 AM, "Owen DeLong" wrote: > > > > Oh, please do explicate on how this is inaccurate… > > > > Owen > > > >> On May 14, 2014, at 2:14 PM, McElearney, Kevin < > Kevin_McElearney at cable.comcast.com> wrote: > >> > >> Respectfully, this is a highly inaccurate "sound bite" > >> > >> - Kevin > >> > >> 215-313-1083 > >> > >>> On May 14, 2014, at 3:05 PM, "Owen DeLong" wrote: > >>> > >>> Yes, the more accurate statement would be aggressively seeking new > >>> ways to monetize the existing infrastructure without investing in > upgrades > >>> or additional buildout any more than absolutely necessary. > >>> > >>> Owen > >>> > >>> On May 14, 2014, at 8:02 AM, Hugo Slabbert wrote: > >>> > >>>>> > >>>>> So they seek new sources of revenues, and/or attempt to thwart > >>>>>> competition any way they can. > >>>> No to the first. Yes to the second. If they were seeking new sources > of > >>>>> revenue, they'd be massively expanding into un/der served markets and > >>>>> aggressively growing over the top services (which are fat margin). > >>>> > >>>> Sure they are (seeking new sources of revenue). They're not > necessarily > >>>> creating new products or services, i.e. actually adding any value, > but they > >>>> are finding ways to extract additional revenue from the same pipes, > e.g. > >>>> through paid peering with content providers. > >>>> > >>>> I'm not endorsing this; just pointing out that you two are actually in > >>>> agreement here. > >>>> > >>>> -- > >>>> Hugo > >>>> > >>>> > >>>>>> On Wed, May 14, 2014 at 7:23 AM, wrote: > >>>>>> > >>>>>> On 2014-05-14 02:04, Jean-Francois Mezei wrote: > >>>>>> > >>>>>> On 14-05-13 22:50, Daniel Staal wrote: > >>>>>> > >>>>>> They have the money. They have the ability to get more money. > *They see > >>>>>>> no reason to spend money making customers happy.* They can make > more > >>>>>>> profit without it. > >>>>>> > >>>>>> There is the issue of control over the market. But also the pressure > >>>>>> from shareholders for continued growth. > >>>>> > >>>>> > >>>>> Yes. That is true. Except that it's not. > >>>>> > >>>>> How do service providers grow? Let's explore that: > >>>>> > >>>>> What is growth for a transit provider? > >>>>> > >>>>> More (new) access network(s) (connections). > >>>>> More bandwidth across backbone pipes. > >>>>> > >>>>> > >>>>> What is growth for access network? > >>>>> More subscribers. > >>>>> > >>>>> Except that the incumbent carriers have shown they have no interest > in > >>>>> providing decent bandwidth to anywhere but the most profitable rate > >>>>> centers. I'd say about 2/3 of the USA is served with quite terrible > access. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> The problem with the internet is that while it had promises of wild > >>>>>> growth in the 90s and 00s, once penetration reaches a certain level, > >>>>>> growth stabilizes. > >>>>> > >>>>> Penetration is ABYSMAL sir. Huge swaths of underserved americans > exist. > >>>>> > >>>>> > >>>>> > >>>>>> When you combine this with threath to large incumbents's media and > media > >>>>>> distribution endeavours by the likes of Netflix (and cat videos on > >>>>>> Youtube), large incumbents start thinking about how they will be > able to > >>>>>> continue to grow revenus/profits when customers will shift spending > to > >>>>>> vspecialty channels/cableTV to Netflix and customer growth will not > >>>>>> compensate. > >>>>> > >>>>> Except they aren't. Even in the most profitable rate centers, they've > >>>>> declined to really invest in the networks. They aren't a real > business. You > >>>>> have to remember that. They have regulatory capture, natural/defacto > >>>>> monopoly etc etc. They don't operate in the real world of > >>>>> risk/reward/profit/loss/uncertainty like any other real business has > to. > >>>>> > >>>>> > >>>>> > >>>>>> So they seek new sources of revenues, and/or attempt to thwart > >>>>>> competition any way they can. > >>>>> > >>>>> No to the first. Yes to the second. If they were seeking new sources > of > >>>>> revenue, they'd be massively expanding into un/der served markets and > >>>>> aggressively growing over the top services (which are fat margin). > They did > >>>>> a bit of an advertising campaign of "smart home" offerings, but that > seems > >>>>> to have never grown beyond a pilot. > >>>>> > >>>>> > >>>>> > >>>>>> The current trend is to "if you can't fight them, jon them" where > >>>>>> cablecos start to include the Netflix app into their proprietary > set-top > >>>>>> boxes. The idea is that you at least make the customer continue to > use > >>>>>> your box and your remote control which makes it easier for them to > >>>>>> switch between netflix and legacy TV. > >>>>> True. I don't know why one of the cablecos hasn't licensed roku, > added > >>>>> cable card and made that available as a "hip/cool" set top box > offering and > >>>>> charge another 10.00 a month on top of the standard dvr rental. > >>>>> > >>>>> > >>>>> > >>>>> Would be interesting to see if those cable companies that are > agreeing > >>>>>> to add the Netflix app onto their proprietary STBs also play > peering > >>>>>> capacity games to degrade the service or not. > >>>>> > >>>>> So how is the content delivered? Is it over the internet? Or is it > over > >>>>> the cable plant, from cable headends? > > > From Kevin_McElearney at cable.comcast.com Thu May 15 16:46:56 2014 From: Kevin_McElearney at cable.comcast.com (McElearney, Kevin) Date: Thu, 15 May 2014 16:46:56 +0000 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com>, Message-ID: Guys, I'm already pretty far off the reservation and will not respond to trolling. I think most ISPs are starting to avoid participation here for the same reason. I'm going to stop for a while. - Kevin On May 15, 2014, at 12:42 PM, "Nick B" > wrote: Yes, you've got "some of the largest Internet companies as customers". Because you told them "if you don't pay us, we'll throttle you". Then you throttled them. I'm sorry, not a winning argument. Nick On Thu, May 15, 2014 at 10:57 AM, McElearney, Kevin > wrote: Upgrades/buildout are happening every day. They are continuous to keep ahead of demand and publicly measured by SamKnows (FCC measuring broadband), Akamai, Ookla, etc What is not well known is that Comcast has been an existing commercial transit business for 15+ years (with over 8000 commercial fiber customers). Comcast also has over 40 balanced peers with plenty of capacity, and some of the largest Internet companies as customers. - Kevin 215-313-1083 > On May 15, 2014, at 10:19 AM, "Owen DeLong" > wrote: > > Oh, please do explicate on how this is inaccurate… > > Owen > >> On May 14, 2014, at 2:14 PM, McElearney, Kevin > wrote: >> >> Respectfully, this is a highly inaccurate "sound bite" >> >> - Kevin >> >> 215-313-1083 >> >>> On May 14, 2014, at 3:05 PM, "Owen DeLong" > wrote: >>> >>> Yes, the more accurate statement would be aggressively seeking new >>> ways to monetize the existing infrastructure without investing in upgrades >>> or additional buildout any more than absolutely necessary. >>> >>> Owen >>> >>> On May 14, 2014, at 8:02 AM, Hugo Slabbert > wrote: >>> >>>>> >>>>> So they seek new sources of revenues, and/or attempt to thwart >>>>>> competition any way they can. >>>> No to the first. Yes to the second. If they were seeking new sources of >>>>> revenue, they'd be massively expanding into un/der served markets and >>>>> aggressively growing over the top services (which are fat margin). >>>> >>>> Sure they are (seeking new sources of revenue). They're not necessarily >>>> creating new products or services, i.e. actually adding any value, but they >>>> are finding ways to extract additional revenue from the same pipes, e.g. >>>> through paid peering with content providers. >>>> >>>> I'm not endorsing this; just pointing out that you two are actually in >>>> agreement here. >>>> >>>> -- >>>> Hugo >>>> >>>> >>>>>> On Wed, May 14, 2014 at 7:23 AM, > wrote: >>>>>> >>>>>> On 2014-05-14 02:04, Jean-Francois Mezei wrote: >>>>>> >>>>>> On 14-05-13 22:50, Daniel Staal wrote: >>>>>> >>>>>> They have the money. They have the ability to get more money. *They see >>>>>>> no reason to spend money making customers happy.* They can make more >>>>>>> profit without it. >>>>>> >>>>>> There is the issue of control over the market. But also the pressure >>>>>> from shareholders for continued growth. >>>>> >>>>> >>>>> Yes. That is true. Except that it's not. >>>>> >>>>> How do service providers grow? Let's explore that: >>>>> >>>>> What is growth for a transit provider? >>>>> >>>>> More (new) access network(s) (connections). >>>>> More bandwidth across backbone pipes. >>>>> >>>>> >>>>> What is growth for access network? >>>>> More subscribers. >>>>> >>>>> Except that the incumbent carriers have shown they have no interest in >>>>> providing decent bandwidth to anywhere but the most profitable rate >>>>> centers. I'd say about 2/3 of the USA is served with quite terrible access. >>>>> >>>>> >>>>> >>>>> >>>>>> The problem with the internet is that while it had promises of wild >>>>>> growth in the 90s and 00s, once penetration reaches a certain level, >>>>>> growth stabilizes. >>>>> >>>>> Penetration is ABYSMAL sir. Huge swaths of underserved americans exist. >>>>> >>>>> >>>>> >>>>>> When you combine this with threath to large incumbents's media and media >>>>>> distribution endeavours by the likes of Netflix (and cat videos on >>>>>> Youtube), large incumbents start thinking about how they will be able to >>>>>> continue to grow revenus/profits when customers will shift spending to >>>>>> vspecialty channels/cableTV to Netflix and customer growth will not >>>>>> compensate. >>>>> >>>>> Except they aren't. Even in the most profitable rate centers, they've >>>>> declined to really invest in the networks. They aren't a real business. You >>>>> have to remember that. They have regulatory capture, natural/defacto >>>>> monopoly etc etc. They don't operate in the real world of >>>>> risk/reward/profit/loss/uncertainty like any other real business has to. >>>>> >>>>> >>>>> >>>>>> So they seek new sources of revenues, and/or attempt to thwart >>>>>> competition any way they can. >>>>> >>>>> No to the first. Yes to the second. If they were seeking new sources of >>>>> revenue, they'd be massively expanding into un/der served markets and >>>>> aggressively growing over the top services (which are fat margin). They did >>>>> a bit of an advertising campaign of "smart home" offerings, but that seems >>>>> to have never grown beyond a pilot. >>>>> >>>>> >>>>> >>>>>> The current trend is to "if you can't fight them, jon them" where >>>>>> cablecos start to include the Netflix app into their proprietary set-top >>>>>> boxes. The idea is that you at least make the customer continue to use >>>>>> your box and your remote control which makes it easier for them to >>>>>> switch between netflix and legacy TV. >>>>> True. I don't know why one of the cablecos hasn't licensed roku, added >>>>> cable card and made that available as a "hip/cool" set top box offering and >>>>> charge another 10.00 a month on top of the standard dvr rental. >>>>> >>>>> >>>>> >>>>> Would be interesting to see if those cable companies that are agreeing >>>>>> to add the Netflix app onto their proprietary STBs also play peering >>>>>> capacity games to degrade the service or not. >>>>> >>>>> So how is the content delivered? Is it over the internet? Or is it over >>>>> the cable plant, from cable headends? > From jgreco at ns.sol.net Thu May 15 16:58:29 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 15 May 2014 11:58:29 -0500 (CDT) Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <8AFC1EC8-5F2E-4645-B57C-A147FC56B390@cable.comcast.com> Message-ID: <201405151658.s4FGwTWt000124@aurora.sol.net> > There is no gaming on measurements and disputes are isolated and temporary = > with issues not unique over the history of the internet. I think all the s= > ame rhetorical quotes continue to be reused An awesome example of the fundamental spin inherent in all of this. For carefully selected values of "gaming," "measurements," and "disputes," your statement is true. And I'm even willing to believe that you believe it to be true. So let me step back and sketch the following out as a more general example of the actual problem here. Chairman Wheeler insists that any prioritization could not result in the customer getting shortchanged, as in: 1) Customer purchases 10Mbps Internet connection. 2) Netflix purchases 5Mbps "fast lane" 3) Customer gets 10Mbps to Netflix. 4) Customer gets 5Mbps (less than paid for) to others. Now that seems obvious that the customer's getting shafted. So here's a different possible mechanism for fast lanes: 1) Customer purchases 10Mbps Internet connection. 2) Netflix purchases 5Mbps "fast lane" 3) Customer gets 15Mbps to Netflix. 4) Customer gets 10Mbps (what was paid for) to others. This seems reasonable, at least at face value. Some people have already suggested that this is what the "fast lane" should be. One of the not-immediately-obvious issues with the second suggestion is that the choices offered to customer are picked by the provider. The second suggestion is actually a good way to opening to door to shortchanging the customer by simply defining the service offerings in a manner that favors the provider; if you simply don't OFFER a higher speed tier, then the customer can never say that they are being shortchanged, and the Netflixes (Netflii?) of the world can be told they have to pay more to get a fast connection to their customers. Carefully omitting, spinning, or even outright lying about the facts is a key aspect of this whole game. Consider this: http://www.theverge.com/2013/2/27/4036128/time-warner-cable-no-consumer-demand-for-fiber-gigabit-internet Wow. What a load! But it basically serves to highlight my point. I guess some of us are just tired of watching the Internet that we helped to build and helped to grow get taken over by interests who are simply looking to suck as much money out of as many pockets as possible. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From ryan at hack.net Thu May 15 17:06:22 2014 From: ryan at hack.net (Ryan Brooks) Date: Thu, 15 May 2014 12:06:22 -0500 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <201405151658.s4FGwTWt000124@aurora.sol.net> References: <201405151658.s4FGwTWt000124@aurora.sol.net> Message-ID: <5374F40E.8010603@hack.net> On 5/15/14, 11:58 AM, Joe Greco wrote: > 2) Netflix purchases 5Mbps "fast lane" > I appreciate Joe's use of quotation marks here. A lot of the dialog has included this 'fast lane' terminology, yet all of us know there's no 'fast lane' being constructed, rather just varying degrees of _slow_ applied to existing traffic. It's a shame the use of 'fast lane' is ubiquitous in this argument. If the local distribution networks would like to actually build something fast, then this would be a different story. -Ryan Brooks From nick at pelagiris.org Thu May 15 17:08:01 2014 From: nick at pelagiris.org (Nick B) Date: Thu, 15 May 2014 13:08:01 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <4979e2ebc9739fc8efb1fbad8d39ecf3.squirrel@mail2tor2zyjdctd.onion> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> <4979e2ebc9739fc8efb1fbad8d39ecf3.squirrel@mail2tor2zyjdctd.onion> Message-ID: To be fair, I have no evidence that Comcast demanded money in advance. As far as I can tell, Level 3, Cogent and Comcast all agree on the rest though, Comcast's peering filled up. Both Level 3 and Cogent offered/requested to upgrade. Then at least Cogent (IIRC?) offered to upgrade *and pay Comcast to upgrade*. All of these offers were ignored or rejected, and at this point I think all parties agree that ransom was demanded by Comcast. Then, just weeks after Verizon's successful litigation against Net Neutrality, Netflix agreed to pay Comcast directly. I'm not sure if the removal of Netflix is enough to resolve the congestion on the Level 3 and Cogent links, but I'm not sure how one could explain the above situation other than deliberate throttling in an attempt to extort money. Nick On Thu, May 15, 2014 at 12:51 PM, wrote: > Yes Kevin, this is understood - but valid observation from Nick. > > Can you pls answer my question first? Very curious. > > Arvinder > > > Guys, I'm already pretty far off the reservation and will not respond to > > trolling. I think most ISPs are starting to avoid participation here for > > the same reason. I'm going to stop for a while. > > > > - Kevin > > > > > > On May 15, 2014, at 12:42 PM, "Nick B" > > > wrote: > > > > Yes, you've got "some of the largest Internet companies as customers". > > Because you told them "if you don't pay us, we'll throttle you". Then > you > > throttled them. I'm sorry, not a winning argument. > > Nick > > > > > > On Thu, May 15, 2014 at 10:57 AM, McElearney, Kevin > > Kevin_McElearney at cable.comcast.com>> > > wrote: > > Upgrades/buildout are happening every day. They are continuous to keep > > ahead of demand and publicly measured by SamKnows (FCC measuring > > broadband), Akamai, Ookla, etc > > > > What is not well known is that Comcast has been an existing commercial > > transit business for 15+ years (with over 8000 commercial fiber > > customers). Comcast also has over 40 balanced peers with plenty of > > capacity, and some of the largest Internet companies as customers. > > > > - Kevin > > > > 215-313-1083 > > > >> On May 15, 2014, at 10:19 AM, "Owen DeLong" > >> > wrote: > >> > >> Oh, please do explicate on how this is inaccurate… > >> > >> Owen > >> > >>> On May 14, 2014, at 2:14 PM, McElearney, Kevin > >>> Kevin_McElearney at cable.comcast.com>> > >>> wrote: > >>> > >>> Respectfully, this is a highly inaccurate "sound bite" > >>> > >>> - Kevin > >>> > >>> 215-313-1083 > >>> > >>>> On May 14, 2014, at 3:05 PM, "Owen DeLong" > >>>> > wrote: > >>>> > >>>> Yes, the more accurate statement would be aggressively seeking new > >>>> ways to monetize the existing infrastructure without investing in > >>>> upgrades > >>>> or additional buildout any more than absolutely necessary. > >>>> > >>>> Owen > >>>> > >>>> On May 14, 2014, at 8:02 AM, Hugo Slabbert > >>>> > wrote: > >>>> > >>>>>> > >>>>>> So they seek new sources of revenues, and/or attempt to thwart > >>>>>>> competition any way they can. > >>>>> No to the first. Yes to the second. If they were seeking new sources > >>>>> of > >>>>>> revenue, they'd be massively expanding into un/der served markets > >>>>>> and > >>>>>> aggressively growing over the top services (which are fat margin). > >>>>> > >>>>> Sure they are (seeking new sources of revenue). They're not > >>>>> necessarily > >>>>> creating new products or services, i.e. actually adding any value, > >>>>> but they > >>>>> are finding ways to extract additional revenue from the same pipes, > >>>>> e.g. > >>>>> through paid peering with content providers. > >>>>> > >>>>> I'm not endorsing this; just pointing out that you two are actually > >>>>> in > >>>>> agreement here. > >>>>> > >>>>> -- > >>>>> Hugo > >>>>> > >>>>> > >>>>>>> On Wed, May 14, 2014 at 7:23 AM, > >>>>>>> > wrote: > >>>>>>> > >>>>>>> On 2014-05-14 02:04, Jean-Francois Mezei wrote: > >>>>>>> > >>>>>>> On 14-05-13 22:50, Daniel Staal wrote: > >>>>>>> > >>>>>>> They have the money. They have the ability to get more money. > >>>>>>> *They see > >>>>>>>> no reason to spend money making customers happy.* They can make > >>>>>>>> more > >>>>>>>> profit without it. > >>>>>>> > >>>>>>> There is the issue of control over the market. But also the > >>>>>>> pressure > >>>>>>> from shareholders for continued growth. > >>>>>> > >>>>>> > >>>>>> Yes. That is true. Except that it's not. > >>>>>> > >>>>>> How do service providers grow? Let's explore that: > >>>>>> > >>>>>> What is growth for a transit provider? > >>>>>> > >>>>>> More (new) access network(s) (connections). > >>>>>> More bandwidth across backbone pipes. > >>>>>> > >>>>>> > >>>>>> What is growth for access network? > >>>>>> More subscribers. > >>>>>> > >>>>>> Except that the incumbent carriers have shown they have no interest > >>>>>> in > >>>>>> providing decent bandwidth to anywhere but the most profitable rate > >>>>>> centers. I'd say about 2/3 of the USA is served with quite terrible > >>>>>> access. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> The problem with the internet is that while it had promises of wild > >>>>>>> growth in the 90s and 00s, once penetration reaches a certain > >>>>>>> level, > >>>>>>> growth stabilizes. > >>>>>> > >>>>>> Penetration is ABYSMAL sir. Huge swaths of underserved americans > >>>>>> exist. > >>>>>> > >>>>>> > >>>>>> > >>>>>>> When you combine this with threath to large incumbents's media and > >>>>>>> media > >>>>>>> distribution endeavours by the likes of Netflix (and cat videos on > >>>>>>> Youtube), large incumbents start thinking about how they will be > >>>>>>> able to > >>>>>>> continue to grow revenus/profits when customers will shift spending > >>>>>>> to > >>>>>>> vspecialty channels/cableTV to Netflix and customer growth will not > >>>>>>> compensate. > >>>>>> > >>>>>> Except they aren't. Even in the most profitable rate centers, > >>>>>> they've > >>>>>> declined to really invest in the networks. They aren't a real > >>>>>> business. You > >>>>>> have to remember that. They have regulatory capture, natural/defacto > >>>>>> monopoly etc etc. They don't operate in the real world of > >>>>>> risk/reward/profit/loss/uncertainty like any other real business has > >>>>>> to. > >>>>>> > >>>>>> > >>>>>> > >>>>>>> So they seek new sources of revenues, and/or attempt to thwart > >>>>>>> competition any way they can. > >>>>>> > >>>>>> No to the first. Yes to the second. If they were seeking new sources > >>>>>> of > >>>>>> revenue, they'd be massively expanding into un/der served markets > >>>>>> and > >>>>>> aggressively growing over the top services (which are fat margin). > >>>>>> They did > >>>>>> a bit of an advertising campaign of "smart home" offerings, but that > >>>>>> seems > >>>>>> to have never grown beyond a pilot. > >>>>>> > >>>>>> > >>>>>> > >>>>>>> The current trend is to "if you can't fight them, jon them" where > >>>>>>> cablecos start to include the Netflix app into their proprietary > >>>>>>> set-top > >>>>>>> boxes. The idea is that you at least make the customer continue to > >>>>>>> use > >>>>>>> your box and your remote control which makes it easier for them to > >>>>>>> switch between netflix and legacy TV. > >>>>>> True. I don't know why one of the cablecos hasn't licensed roku, > >>>>>> added > >>>>>> cable card and made that available as a "hip/cool" set top box > >>>>>> offering and > >>>>>> charge another 10.00 a month on top of the standard dvr rental. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Would be interesting to see if those cable companies that are > >>>>>> agreeing > >>>>>>> to add the Netflix app onto their proprietary STBs also play > >>>>>>> peering > >>>>>>> capacity games to degrade the service or not. > >>>>>> > >>>>>> So how is the content delivered? Is it over the internet? Or is it > >>>>>> over > >>>>>> the cable plant, from cable headends? > >> > > > > > > > From jfmezei_nanog at vaxination.ca Thu May 15 17:11:20 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 15 May 2014 13:11:20 -0400 Subject: FTTH ONTs and routers Message-ID: <5374F538.5010108@vaxination.ca> It had been my impression that ONTs, like most other consumer modems, came with built-in router capabilities (along with ATA for voice). The assertion that ONTs have built-in routing capabilities has been challenged. Can anyone confirm whether ONTs generally have routing (aka: home router that does the PPPoE or DHCP and then NAT for home) capabilities? Are there examples where a telco has deployed ONTs with the router built-in and enabled ? Or would almost all FTTH deployments be made with any routing disabled and the ONT acting as a pure ethernet bridge ? (I appreciate your help on this as I am time constrained to do research). From effinjdent at gmail.com Thu May 15 17:11:21 2014 From: effinjdent at gmail.com (Jerry Dent) Date: Thu, 15 May 2014 12:11:21 -0500 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> Message-ID: > What is not well known is that Comcast has been an existing commercial transit business for 15+ years (with over 8000 commercial fiber customers). Comcast also has over 40 balanced peers with plenty of capacity, and some of the largest Internet companies as customers. Peers that are balanced only due strong arm tactics used against smaller hosting and content providers. On Thu, May 15, 2014 at 11:46 AM, McElearney, Kevin < Kevin_McElearney at cable.comcast.com> wrote: > Guys, I'm already pretty far off the reservation and will not respond to > trolling. I think most ISPs are starting to avoid participation here for > the same reason. I'm going to stop for a while. > > - Kevin > > > On May 15, 2014, at 12:42 PM, "Nick B" nick at pelagiris.org>> wrote: > > Yes, you've got "some of the largest Internet companies as customers". > Because you told them "if you don't pay us, we'll throttle you". Then you > throttled them. I'm sorry, not a winning argument. > Nick > > > On Thu, May 15, 2014 at 10:57 AM, McElearney, Kevin < > Kevin_McElearney at cable.comcast.com Kevin_McElearney at cable.comcast.com>> wrote: > Upgrades/buildout are happening every day. They are continuous to keep > ahead of demand and publicly measured by SamKnows (FCC measuring > broadband), Akamai, Ookla, etc > > What is not well known is that Comcast has been an existing commercial > transit business for 15+ years (with over 8000 commercial fiber customers). > Comcast also has over 40 balanced peers with plenty of capacity, and some > of the largest Internet companies as customers. > > - Kevin > > 215-313-1083 > > > On May 15, 2014, at 10:19 AM, "Owen DeLong" owen at delong.com>> wrote: > > > > Oh, please do explicate on how this is inaccurate… > > > > Owen > > > >> On May 14, 2014, at 2:14 PM, McElearney, Kevin < > Kevin_McElearney at cable.comcast.com Kevin_McElearney at cable.comcast.com>> wrote: > >> > >> Respectfully, this is a highly inaccurate "sound bite" > >> > >> - Kevin > >> > >> 215-313-1083 > >> > >>> On May 14, 2014, at 3:05 PM, "Owen DeLong" owen at delong.com>> wrote: > >>> > >>> Yes, the more accurate statement would be aggressively seeking new > >>> ways to monetize the existing infrastructure without investing in > upgrades > >>> or additional buildout any more than absolutely necessary. > >>> > >>> Owen > >>> > >>> On May 14, 2014, at 8:02 AM, Hugo Slabbert hugo at slabnet.com>> wrote: > >>> > >>>>> > >>>>> So they seek new sources of revenues, and/or attempt to thwart > >>>>>> competition any way they can. > >>>> No to the first. Yes to the second. If they were seeking new sources > of > >>>>> revenue, they'd be massively expanding into un/der served markets and > >>>>> aggressively growing over the top services (which are fat margin). > >>>> > >>>> Sure they are (seeking new sources of revenue). They're not > necessarily > >>>> creating new products or services, i.e. actually adding any value, > but they > >>>> are finding ways to extract additional revenue from the same pipes, > e.g. > >>>> through paid peering with content providers. > >>>> > >>>> I'm not endorsing this; just pointing out that you two are actually in > >>>> agreement here. > >>>> > >>>> -- > >>>> Hugo > >>>> > >>>> > >>>>>> On Wed, May 14, 2014 at 7:23 AM, charles at thefnf.org>> wrote: > >>>>>> > >>>>>> On 2014-05-14 02:04, Jean-Francois Mezei wrote: > >>>>>> > >>>>>> On 14-05-13 22:50, Daniel Staal wrote: > >>>>>> > >>>>>> They have the money. They have the ability to get more money. > *They see > >>>>>>> no reason to spend money making customers happy.* They can make > more > >>>>>>> profit without it. > >>>>>> > >>>>>> There is the issue of control over the market. But also the pressure > >>>>>> from shareholders for continued growth. > >>>>> > >>>>> > >>>>> Yes. That is true. Except that it's not. > >>>>> > >>>>> How do service providers grow? Let's explore that: > >>>>> > >>>>> What is growth for a transit provider? > >>>>> > >>>>> More (new) access network(s) (connections). > >>>>> More bandwidth across backbone pipes. > >>>>> > >>>>> > >>>>> What is growth for access network? > >>>>> More subscribers. > >>>>> > >>>>> Except that the incumbent carriers have shown they have no interest > in > >>>>> providing decent bandwidth to anywhere but the most profitable rate > >>>>> centers. I'd say about 2/3 of the USA is served with quite terrible > access. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> The problem with the internet is that while it had promises of wild > >>>>>> growth in the 90s and 00s, once penetration reaches a certain level, > >>>>>> growth stabilizes. > >>>>> > >>>>> Penetration is ABYSMAL sir. Huge swaths of underserved americans > exist. > >>>>> > >>>>> > >>>>> > >>>>>> When you combine this with threath to large incumbents's media and > media > >>>>>> distribution endeavours by the likes of Netflix (and cat videos on > >>>>>> Youtube), large incumbents start thinking about how they will be > able to > >>>>>> continue to grow revenus/profits when customers will shift spending > to > >>>>>> vspecialty channels/cableTV to Netflix and customer growth will not > >>>>>> compensate. > >>>>> > >>>>> Except they aren't. Even in the most profitable rate centers, they've > >>>>> declined to really invest in the networks. They aren't a real > business. You > >>>>> have to remember that. They have regulatory capture, natural/defacto > >>>>> monopoly etc etc. They don't operate in the real world of > >>>>> risk/reward/profit/loss/uncertainty like any other real business has > to. > >>>>> > >>>>> > >>>>> > >>>>>> So they seek new sources of revenues, and/or attempt to thwart > >>>>>> competition any way they can. > >>>>> > >>>>> No to the first. Yes to the second. If they were seeking new sources > of > >>>>> revenue, they'd be massively expanding into un/der served markets and > >>>>> aggressively growing over the top services (which are fat margin). > They did > >>>>> a bit of an advertising campaign of "smart home" offerings, but that > seems > >>>>> to have never grown beyond a pilot. > >>>>> > >>>>> > >>>>> > >>>>>> The current trend is to "if you can't fight them, jon them" where > >>>>>> cablecos start to include the Netflix app into their proprietary > set-top > >>>>>> boxes. The idea is that you at least make the customer continue to > use > >>>>>> your box and your remote control which makes it easier for them to > >>>>>> switch between netflix and legacy TV. > >>>>> True. I don't know why one of the cablecos hasn't licensed roku, > added > >>>>> cable card and made that available as a "hip/cool" set top box > offering and > >>>>> charge another 10.00 a month on top of the standard dvr rental. > >>>>> > >>>>> > >>>>> > >>>>> Would be interesting to see if those cable companies that are > agreeing > >>>>>> to add the Netflix app onto their proprietary STBs also play > peering > >>>>>> capacity games to degrade the service or not. > >>>>> > >>>>> So how is the content delivered? Is it over the internet? Or is it > over > >>>>> the cable plant, from cable headends? > > > > From ikiris at gmail.com Thu May 15 17:12:19 2014 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 15 May 2014 12:12:19 -0500 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <696D5986-AB28-4793-976D-FFE542AEB68D@cable.comcast.com> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> <5374E013.1050708@sberkman.net> <8AFC1EC8-5F2E-4645-B57C-A147FC56B390@cable.comcast.com> <696D5986-AB28-4793-976D-FFE542AEB68D@cable.comcast.com> Message-ID: And the "unbalanced" peers / transit? -Blake On Thu, May 15, 2014 at 11:41 AM, McElearney, Kevin wrote: > This is a smart group. If if that was true I think every internet site / service one visits from home would be a negatively impacted. That is not the case > > As I said before, Comcast also has over 40 balanced peers with plenty of capacity. Wholesale $$ are very small, highly competitive and only "skin in the game" to promote efficiencies > > - Kevin > > >> On May 15, 2014, at 12:01 PM, "Jared Mauch" wrote: >> >> >>> On May 15, 2014, at 11:50 AM, McElearney, Kevin wrote: >>> >>> There is no gaming on measurements and disputes are isolated and temporary with issues not unique over the history of the internet. I think all the same rhetorical quotes continue to be reused >> >> Kevin, >> >> in the past most issues were transient for a few months as both sides got complaints, but while at RIPE earlier this week someone commented to me: there's no one provider you can buy access from to get a packet-loss free connection to all their other business partners/customers. This hurts the entire marketplace when there is persistent congestion. >> >> Some of these issues are related to (as Craig called them) "Hypergiants" (OTT) but others are due to providers having poor capital models so they don't have "budget" for upgrading unless someone pays for that upgrade, vs seeing their existing customer base as that source for the capital. >> >> As an engineer, I'm hopeful that those responsible for budgeting will do the right thing. As a greedy capitalist, please pay me more $$$. It does feel a bit like tic-tac-toe with zero players in wargames though, the only way to win is to not play [games]. >> >> - Jared >> From jfmezei_nanog at vaxination.ca Thu May 15 17:18:11 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 15 May 2014 13:18:11 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <74642389-7742-406C-9FC4-C0B0B4940136@delong.com> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> , <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <37AFC907-CAB5-4721-B79D-EAE2687970BF@puck.nether.net> <74642389-7742-406C-9FC4-C0B0B4940136@delong.com> Message-ID: <5374F6D3.9040408@vaxination.ca> On 14-05-15 10:26, Owen DeLong wrote: > Choosing between Comcast and a legacy Telco is like choosing between legionnaire’s disease and SARS. Twisted pair is certantly "legacy". Is there a feeling that coax cable/DOSCIS is also "legacy" in terms of current capacity/speeds ? Or is that technology still considered viable against FTTH ? I realise that business practices make north american incumbents undesirable compared to the rest of the world, especially Comcast's dirty tricks with Netflix as an example. But in terms of the last mile technology and wiring (for instance, homes per HFC node) sre north american cavlecos up to par with the rest of the world ? From jared at puck.nether.net Thu May 15 17:18:23 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 15 May 2014 13:18:23 -0400 Subject: FTTH ONTs and routers In-Reply-To: <5374F538.5010108@vaxination.ca> References: <5374F538.5010108@vaxination.ca> Message-ID: <3A6A1F3D-A944-4954-BA16-75D960D42B2D@puck.nether.net> On May 15, 2014, at 1:11 PM, Jean-Francois Mezei wrote: > > It had been my impression that ONTs, like most other consumer modems, > came with built-in router capabilities (along with ATA for voice). > > The assertion that ONTs have built-in routing capabilities has been > challenged. > > Can anyone confirm whether ONTs generally have routing (aka: home router > that does the PPPoE or DHCP and then NAT for home) capabilities? > > Are there examples where a telco has deployed ONTs with the router > built-in and enabled ? Or would almost all FTTH deployments be made with > any routing disabled and the ONT acting as a pure ethernet bridge ? Some are and some don't. For example the ZHONE active ethernet boxes are Linux on the inside and you can do a variety of different things with them, either making them do the NAT or be bridged back to the aggregation gear. - jared From fergdawgster at mykolab.com Thu May 15 17:17:46 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Thu, 15 May 2014 10:17:46 -0700 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <5374F40E.8010603@hack.net> References: <201405151658.s4FGwTWt000124@aurora.sol.net> <5374F40E.8010603@hack.net> Message-ID: <5374F6BA.4020108@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 5/15/2014 10:06 AM, Ryan Brooks wrote: > It's a shame the use of 'fast lane' is ubiquitous in this argument. > If the local distribution networks would like to actually build > something fast, then this would be a different story. Okay, then call it the "faster lane" or the "uncongested lane" or something that actually reflects bias and preferential treatment. It's a done deal now: http://www.washingtonpost.com/blogs/the-switch/wp/2014/05/15/fcc-approves-plan-to-allow-for-paid-priority-on-internet FYI, - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlN09roACgkQKJasdVTchbJPlgEAtBpp0TKNZcIdrDkVP75Tni7a O9PvcnKZdaPNuNUpOb0A/RQ5hvrqPAu/QLSp8dPbcDSO5Zad8Z3JG67UfI6yaeJH =DhnX -----END PGP SIGNATURE----- From khelms at zcorum.com Thu May 15 17:21:34 2014 From: khelms at zcorum.com (Scott Helms) Date: Thu, 15 May 2014 13:21:34 -0400 Subject: FTTH ONTs and routers In-Reply-To: <5374F538.5010108@vaxination.ca> References: <5374F538.5010108@vaxination.ca> Message-ID: Jean-Francois, I've seen it done both ways, and _usually_ newer ONTs will have the capacity even if its not used. Having said that there is no real standardization between vendors other than the physical layer (and even that's not great) so what's common for one vendor may well be unheard of for another. Making generalizations about G/EPON gear is very hard right now and its worse for the older standards like BPON. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, May 15, 2014 at 1:11 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > > It had been my impression that ONTs, like most other consumer modems, > came with built-in router capabilities (along with ATA for voice). > > The assertion that ONTs have built-in routing capabilities has been > challenged. > > Can anyone confirm whether ONTs generally have routing (aka: home router > that does the PPPoE or DHCP and then NAT for home) capabilities? > > Are there examples where a telco has deployed ONTs with the router > built-in and enabled ? Or would almost all FTTH deployments be made with > any routing disabled and the ONT acting as a pure ethernet bridge ? > > > (I appreciate your help on this as I am time constrained to do research). > > From morrowc.lists at gmail.com Thu May 15 17:22:00 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 15 May 2014 13:22:00 -0400 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <5374F40E.8010603@hack.net> References: <201405151658.s4FGwTWt000124@aurora.sol.net> <5374F40E.8010603@hack.net> Message-ID: On Thu, May 15, 2014 at 1:06 PM, Ryan Brooks wrote: > On 5/15/14, 11:58 AM, Joe Greco wrote: >> >> 2) Netflix purchases 5Mbps "fast lane" >> > > I appreciate Joe's use of quotation marks here. A lot of the dialog has > included this 'fast lane' terminology, yet all of us know there's no 'fast > lane' being constructed, rather just varying degrees of _slow_ applied to > existing traffic. > please correct me if I'm wrong, but 'fast lane' really is (in this example): 'cableco' port from 'moviecompany' has 'qos' marking configuration to set all 'moviecompany' traffic (from this port!) to some priority level. customer-port to 'cableco' has 'qos' handling/queuing that will ensure '5mbps' of 'moviecompany' is always going to get down the link to the customer, regardless of the other traffic the customer is requesting. right? (presume that in the rest of the 'cableco' network is protecting 'moviecompany' traffic as well, of course) So, when there are 1 'moviecompany' things to prioritize and deliver that's cool... but what about when there are 10? 100? 1000? doesn't the queuing get complicated? what if the 'cableco' customer with 10mbps link has 3 people in the location all streaming from 3 different 'moviecompany' organizations which have paid for 'fastlane' services? 3 x 5 == 15 ... not 10. How will 'cableco' manage this when their 100gbps inter-metro links are seeing +100gbps if 'fastlane' traffic and 'fastlane' traffic can't make it to the local metro from the remote one? This all seems much, much more complicated and expensive than just building out networking, which they will have to do in the end anyway, right? Only with 'fastlanes' there's extra capacity management and configuration and testing and ... all on top of: "Gosh, does the new umnptyfart card from routerco actually work in old routerco routers?" This looks, to me, like nuttiness... like mutually assured destruction that the cableco folk are driving both parties into intentionally. -chris BTW: I didn't use a particular 'cable company' name for 'cableco', nor did I use a particular streaming media company for 'moviecompany'... Also, 'cableco' is short-hand for 'lastmile-consumer-provider-network'. Less typing was better, for me, I thought. From aledm at qix.co.uk Thu May 15 17:24:33 2014 From: aledm at qix.co.uk (Aled Morris) Date: Thu, 15 May 2014 18:24:33 +0100 Subject: FTTH ONTs and routers In-Reply-To: <5374F538.5010108@vaxination.ca> References: <5374F538.5010108@vaxination.ca> Message-ID: I notice Cisco's new ME4600 ONT's come in two flavors, one (the "Residential GateWay") with all the bells and whistles that you'd expect in an all-in-one home router (voice ports, small ethernet switch, wifi access point) and another (the "Single Family Unit") that looks a lot more basic and is likely to be deployed as a bridge. http://www.cisco.com/c/en/us/products/collateral/switches/me-4600-series-multiservice-optical-access-platform/datasheet-c78-730446.html Aled On 15 May 2014 18:11, Jean-Francois Mezei wrote: > > It had been my impression that ONTs, like most other consumer modems, > came with built-in router capabilities (along with ATA for voice). > > The assertion that ONTs have built-in routing capabilities has been > challenged. > > Can anyone confirm whether ONTs generally have routing (aka: home router > that does the PPPoE or DHCP and then NAT for home) capabilities? > > Are there examples where a telco has deployed ONTs with the router > built-in and enabled ? Or would almost all FTTH deployments be made with > any routing disabled and the ONT acting as a pure ethernet bridge ? > > > (I appreciate your help on this as I am time constrained to do research). > > From owen at delong.com Thu May 15 17:06:41 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 15 May 2014 10:06:41 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> , <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com>, <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> Message-ID: On May 15, 2014, at 7:57 AM, McElearney, Kevin wrote: > Upgrades/buildout are happening every day. They are continuous to keep ahead of demand and publicly measured by SamKnows (FCC measuring broadband), Akamai, Ookla, etc I didn’t say they weren’t doing any upgrades/buildouts. I will say that the copper capabilities in my neighborhood are so far behind demand(s) that it is abysmal. There hasn’t been significant maintenance to the $TELCO copper plant in my neighborhood since it was installed in 1960. > What is not well known is that Comcast has been an existing commercial transit business for 15+ years (with over 8000 commercial fiber customers). Comcast also has over 40 balanced peers with plenty of capacity, and some of the largest Internet companies as customers. I’ve been asked by my employer to stop picking on specific large ISPs. However, my experiences with $CABLECO have been as described. The infrastructure in my neighborhood was horrible and did not improve at all until I ordered business class service from them. I’ve seen nothing to indicate that there is any significant effort to improve customer satisfaction, but lots of things to indicate that they are trying to leverage as much revenue out of as little investment as possible. Owen > > - Kevin > > 215-313-1083 > >> On May 15, 2014, at 10:19 AM, "Owen DeLong" wrote: >> >> Oh, please do explicate on how this is inaccurate… >> >> Owen >> >>> On May 14, 2014, at 2:14 PM, McElearney, Kevin wrote: >>> >>> Respectfully, this is a highly inaccurate "sound bite" >>> >>> - Kevin >>> >>> 215-313-1083 >>> >>>> On May 14, 2014, at 3:05 PM, "Owen DeLong" wrote: >>>> >>>> Yes, the more accurate statement would be aggressively seeking new >>>> ways to monetize the existing infrastructure without investing in upgrades >>>> or additional buildout any more than absolutely necessary. >>>> >>>> Owen >>>> >>>> On May 14, 2014, at 8:02 AM, Hugo Slabbert wrote: >>>> >>>>>> >>>>>> So they seek new sources of revenues, and/or attempt to thwart >>>>>>> competition any way they can. >>>>> No to the first. Yes to the second. If they were seeking new sources of >>>>>> revenue, they'd be massively expanding into un/der served markets and >>>>>> aggressively growing over the top services (which are fat margin). >>>>> >>>>> Sure they are (seeking new sources of revenue). They're not necessarily >>>>> creating new products or services, i.e. actually adding any value, but they >>>>> are finding ways to extract additional revenue from the same pipes, e.g. >>>>> through paid peering with content providers. >>>>> >>>>> I'm not endorsing this; just pointing out that you two are actually in >>>>> agreement here. >>>>> >>>>> -- >>>>> Hugo >>>>> >>>>> >>>>>>> On Wed, May 14, 2014 at 7:23 AM, wrote: >>>>>>> >>>>>>> On 2014-05-14 02:04, Jean-Francois Mezei wrote: >>>>>>> >>>>>>> On 14-05-13 22:50, Daniel Staal wrote: >>>>>>> >>>>>>> They have the money. They have the ability to get more money. *They see >>>>>>>> no reason to spend money making customers happy.* They can make more >>>>>>>> profit without it. >>>>>>> >>>>>>> There is the issue of control over the market. But also the pressure >>>>>>> from shareholders for continued growth. >>>>>> >>>>>> >>>>>> Yes. That is true. Except that it's not. >>>>>> >>>>>> How do service providers grow? Let's explore that: >>>>>> >>>>>> What is growth for a transit provider? >>>>>> >>>>>> More (new) access network(s) (connections). >>>>>> More bandwidth across backbone pipes. >>>>>> >>>>>> >>>>>> What is growth for access network? >>>>>> More subscribers. >>>>>> >>>>>> Except that the incumbent carriers have shown they have no interest in >>>>>> providing decent bandwidth to anywhere but the most profitable rate >>>>>> centers. I'd say about 2/3 of the USA is served with quite terrible access. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> The problem with the internet is that while it had promises of wild >>>>>>> growth in the 90s and 00s, once penetration reaches a certain level, >>>>>>> growth stabilizes. >>>>>> >>>>>> Penetration is ABYSMAL sir. Huge swaths of underserved americans exist. >>>>>> >>>>>> >>>>>> >>>>>>> When you combine this with threath to large incumbents's media and media >>>>>>> distribution endeavours by the likes of Netflix (and cat videos on >>>>>>> Youtube), large incumbents start thinking about how they will be able to >>>>>>> continue to grow revenus/profits when customers will shift spending to >>>>>>> vspecialty channels/cableTV to Netflix and customer growth will not >>>>>>> compensate. >>>>>> >>>>>> Except they aren't. Even in the most profitable rate centers, they've >>>>>> declined to really invest in the networks. They aren't a real business. You >>>>>> have to remember that. They have regulatory capture, natural/defacto >>>>>> monopoly etc etc. They don't operate in the real world of >>>>>> risk/reward/profit/loss/uncertainty like any other real business has to. >>>>>> >>>>>> >>>>>> >>>>>>> So they seek new sources of revenues, and/or attempt to thwart >>>>>>> competition any way they can. >>>>>> >>>>>> No to the first. Yes to the second. If they were seeking new sources of >>>>>> revenue, they'd be massively expanding into un/der served markets and >>>>>> aggressively growing over the top services (which are fat margin). They did >>>>>> a bit of an advertising campaign of "smart home" offerings, but that seems >>>>>> to have never grown beyond a pilot. >>>>>> >>>>>> >>>>>> >>>>>>> The current trend is to "if you can't fight them, jon them" where >>>>>>> cablecos start to include the Netflix app into their proprietary set-top >>>>>>> boxes. The idea is that you at least make the customer continue to use >>>>>>> your box and your remote control which makes it easier for them to >>>>>>> switch between netflix and legacy TV. >>>>>> True. I don't know why one of the cablecos hasn't licensed roku, added >>>>>> cable card and made that available as a "hip/cool" set top box offering and >>>>>> charge another 10.00 a month on top of the standard dvr rental. >>>>>> >>>>>> >>>>>> >>>>>> Would be interesting to see if those cable companies that are agreeing >>>>>>> to add the Netflix app onto their proprietary STBs also play peering >>>>>>> capacity games to degrade the service or not. >>>>>> >>>>>> So how is the content delivered? Is it over the internet? Or is it over >>>>>> the cable plant, from cable headends? >> From Jason_Livingood at cable.comcast.com Thu May 15 17:26:17 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 15 May 2014 17:26:17 +0000 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> Message-ID: On 5/15/14, 12:43 PM, "Nick B" wrote: >Yes, you've got "some of the largest Internet companies as customers². >Because you told them "if you don't pay us, we'll throttle you". Then >you throttled them. I'm sorry, not a winning argument. >Nick That is categorically untrue, however nice a soundbite it may be. If you or anyone else truly believes we are throttling someone then I encourage you to file a formal complaint with the FCC. According to their Open Internet rules that we are bound to through at least 2018 (IIRC) we may not discriminate on traffic in that way, so there is a clear rule and a clear process for complaints. Jason From Courtney_Smith at Cable.Comcast.com Thu May 15 17:28:25 2014 From: Courtney_Smith at Cable.Comcast.com (Smith, Courtney) Date: Thu, 15 May 2014 17:28:25 +0000 Subject: Possible Comcast Load Balancing issues in Chicago? In-Reply-To: <552495BF71B9D04D82A596A010E64CD29B3AF168C1@MIEX07MBXVM1.metro-inet.us> References: <8DD18D69FFC6DB46AE9CDB191CD8B981602B74EA@PACDCEXMB04.cable.comcast.com> <552495BF71B9D04D82A596A010E64CD29B3AF168C1@MIEX07MBXVM1.metro-inet.us> Message-ID: <8DD18D69FFC6DB46AE9CDB191CD8B981602B7A49@PACDCEXMB04.cable.comcast.com> Mark, Faulty circuit was removed from path. NOC is working with TATA(AS6453) to repair. Thanks. Courtney Smith Network Engineer Comcast http://www.comcastwholesale.com/ -----Original Message----- From: Mark Mayfield [mailto:Mark.Mayfield at metro-inet.us] Sent: Thursday, May 15, 2014 12:04 PM To: Smith, Courtney; Metro-Inet Netops Cc: nanog at nanog.org Subject: RE: Possible Comcast Load Balancing issues in Chicago? Seems to have cleared up about 30 minutes ago. Thanks, Mark Mayfield City of Roseville – AS 54371 Network Systems Engineer 2660 Civic Center Drive Roseville, MN 55113 651-792-7098      Office -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Smith, Courtney Sent: Thursday, May 15, 2014 10:32 AM To: Metro-Inet Netops Cc: nanog at nanog.org Subject: RE: Possible Comcast Load Balancing issues in Chicago? Looking into. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Metro-Inet Netops Sent: Thursday, May 15, 2014 11:10 AM To: nanog at nanog.org Subject: Possible Comcast Load Balancing issues in Chicago? It’s possible I’m missing something, but it looks like traffic from Comcast business customers in the Minneapolis/St. Paul area is not all making it through Chicago to my VPN endpoints. Testing to some of my address space from one of the Comcast remote VPN sites, I can get to some numbers and not others (odds/evens switch roles depending on the block I trace) fall apart hopping though Chicago. Testing to the same addresses from the HE looking glass, everything seems fine. Any input or even knowledge that it’s being worked on would be appreciated. Traceroutes below: Fails: HUGO-CH-2921#trace 199.249.109.13 Type escape sequence to abort. Tracing the route to vpn.metro-inet.us (199.249.109.13) VRF info: (vrf in name/id, vrf out name/id) 1 75-149-158-38-minnesota.hfc.comcastbusiness.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 12 msec 12 msec 16 msec 3 te-4-2-ur02.whitebear.mn.minn.comcast.net (68.85.167.37) 16 msec 16 msec 16 msec 4 te-2-1-ur02.oakdale.mn.minn.comcast.net (68.87.174.138) 16 msec 16 msec 16 msec 5 te-8-3-ur01.oakdale.mn.minn.comcast.net (68.87.174.109) 20 msec 12 msec 16 msec 6 te-0-3-0-5-ar01.crosstown.mn.minn.comcast.net (69.139.176.61) 16 msec 16 msec 20 msec 7 pos-0-0-0-0-ar01.roseville.mn.minn.comcast.net (68.87.174.194) 16 msec 16 msec 12 msec 8 he-1-12-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.77) 24 msec 24 msec 28 msec 9 * * * 10 * Gets Through: HUGO-CH-2921#trace 199.249.109.14 Type escape sequence to abort. Tracing the route to 199.249.109.14 VRF info: (vrf in name/id, vrf out name/id) 1 75-149-158-38-minnesota.hfc.comcastbusiness.net (75.149.158.38) 4 msec 0 msec 0 msec 2 73.237.168.1 8 msec 12 msec 8 msec 3 te-4-2-ur01.whitebear.mn.minn.comcast.net (68.85.167.33) 12 msec 12 msec 12 msec 4 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 12 msec 12 msec 5 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 12 msec 8 msec 8 msec 6 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 12 msec 12 msec 12 msec 7 he-1-11-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.73) 28 msec 20 msec 24 msec 8 ix-7-0-3-0.tcore1.CT8-Chicago.as6453.net (64.86.137.33) 16 msec 16 msec 20 msec 9 206.82.141.90 20 msec 20 msec 20 msec 10 hurricane-ic-124397-chi-bb1.c.telia.net (213.248.104.214) 24 msec 24 msec 28 msec 11 100ge13-1.core1.msp1.he.net (184.105.223.178) 36 msec 24 msec 28 msec 12 city-of-roseville.gigabitethernet3-8.core1.msp1.he.net (184.105.249.218) 28 msec 28 msec 24 msec 13 199.249.109.227 28 msec 24 msec 28 msec Gets Through: HUGO-CH-2921#trace 67.88.181.25 Type escape sequence to abort. Tracing the route to ip67-88-181-25.z181-88-67.customer.algx.net(67.88.181.25) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 8 msec 8 msec 8 msec 3 te-4-2-ur01.whitebear.mn.minn.comcast.net (68.85.167.33) 12 msec 12 msec 8 msec 4 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 8 msec 12 msec 5 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 12 msec 12 msec 8 msec 6 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 8 msec 12 msec 12 msec 7 he-1-12-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.77) 24 msec 20 msec 16 msec 8 ix-2-3-0-0.tcore1.CT8-Chicago.as6453.net (64.86.137.41) 24 msec 16 msec 40 msec 9 p5-1.ir1.chicago2-il.us.xo.net (206.111.2.33) 68 msec 20 msec 80 msec 10 207.88.14.193.ptr.us.xo.net (207.88.14.193) 32 msec 32 msec 36 msec 11 ae0d0.mcr1.minneapolis-mn.us.xo.net (216.156.0.170) 28 msec 28 msec 28 msec Fails: HUGO-CH-2921#trace 67.88.181.26 Type escape sequence to abort. Tracing the route to webvpn.metro-inet.us (67.88.181.26) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 8 msec 8 msec 8 msec 3 te-4-2-ur02.whitebear.mn.minn.comcast.net (68.85.167.37) 8 msec 12 msec 8 msec 4 te-2-1-ur02.oakdale.mn.minn.comcast.net (68.87.174.138) 8 msec 12 msec 20 msec 5 te-8-3-ur01.oakdale.mn.minn.comcast.net (68.87.174.109) 8 msec 8 msec 12 msec 6 te-0-3-0-5-ar01.crosstown.mn.minn.comcast.net (69.139.176.61) 12 msec 12 msec 12 msec 7 pos-0-1-0-0-ar01.roseville.mn.minn.comcast.net (68.87.174.2) 8 msec 8 msec 12 msec 8 he-1-13-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.81) 24 msec 24 msec 20 msec 9 * * * 10 * * * 11 * * * 12 * * * Gets Through: HUGO-CH-2921#trace 67.88.181.27 Type escape sequence to abort. Tracing the route to ip67-88-181-27.z181-88-67.customer.algx.net(67.88.181.27) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 4 msec 0 msec 4 msec 2 73.237.168.1 8 msec 12 msec 8 msec 3 te-4-2-ur02.whitebear.mn.minn.comcast.net (68.85.167.37) 12 msec 12 msec 8 msec 4 te-8-3-ur01.whitebear.mn.minn.comcast.net (68.87.174.133) 12 msec 12 msec 4 msec 5 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 12 msec 8 msec 6 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 16 msec 8 msec 8 msec 7 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 12 msec 12 msec 16 msec 8 he-1-13-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.81) 20 msec 20 msec 20 msec 9 ix-2-2-1-0.tcore1.CT8-Chicago.as6453.net (64.86.137.37) 16 msec 16 msec 16 msec 10 p5-1.ir1.chicago2-il.us.xo.net (206.111.2.33) 32 msec 72 msec 96 msec 11 207.88.14.193.ptr.us.xo.net (207.88.14.193) 36 msec 32 msec 32 msec 12 ae0d0.mcr1.minneapolis-mn.us.xo.net (216.156.0.170) 28 msec 28 msec 32 msec 13 * * * Fails: HUGO-CH-2921#trace 67.88.181.28 Type escape sequence to abort. Tracing the route to ip67-88-181-28.z181-88-67.customer.algx.net(67.88.181.28) VRF info: (vrf in name/id, vrf out name/id) 1 pubwp.comcast.net (75.149.158.38) 0 msec 0 msec 0 msec 2 73.237.168.1 12 msec 8 msec 12 msec 3 te-4-2-ur01.whitebear.mn.minn.comcast.net (68.85.167.33) 8 msec 8 msec 8 msec 4 te-2-1-ur02.shoreview.mn.minn.comcast.net (68.87.174.129) 8 msec 8 msec 12 msec 5 te-8-3-ur01.shoreview.mn.minn.comcast.net (68.87.174.125) 12 msec 8 msec 8 msec 6 te-0-3-0-6-ar01.roseville.mn.minn.comcast.net (68.87.174.178) 12 msec 12 msec 12 msec 7 he-1-11-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.73) 20 msec 20 msec 20 msec 8 * * * 9 * * * 10 * Mark Mayfield City of Roseville – AS 54371 Network Systems Engineer 2660 Civic Center Drive Roseville, MN 55113 651-792-7098 Office From nick at pelagiris.org Thu May 15 17:28:52 2014 From: nick at pelagiris.org (Nick B) Date: Thu, 15 May 2014 13:28:52 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> Message-ID: By "categorically untrue" do you mean "FCC's open internet rules allow us to refuse to upgrade full peers"? Nick On Thu, May 15, 2014 at 1:26 PM, Livingood, Jason < Jason_Livingood at cable.comcast.com> wrote: > On 5/15/14, 12:43 PM, "Nick B" wrote: > > > >Yes, you've got "some of the largest Internet companies as customers². > >Because you told them "if you don't pay us, we'll throttle you". Then > >you throttled them. I'm sorry, not a winning argument. > >Nick > > That is categorically untrue, however nice a soundbite it may be. If you > or anyone else truly believes we are throttling someone then I encourage > you to file a formal complaint with the FCC. According to their Open > Internet rules that we are bound to through at least 2018 (IIRC) we may > not discriminate on traffic in that way, so there is a clear rule and a > clear process for complaints. > > Jason > > From Jason_Livingood at cable.comcast.com Thu May 15 17:34:32 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 15 May 2014 17:34:32 +0000 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> Message-ID: On 5/15/14, 1:28 PM, "Nick B" > wrote: By "categorically untrue" do you mean "FCC's open internet rules allow us to refuse to upgrade full peers"? Throttling is taking, say, a link from 10G and applying policy to constrain it to 1G, for example. What if a peer wants to go from a balanced relationship to 10,000:1, well outside of the policy binding the relationship? Should we just unquestionably toss out our published policy – which is consistent with other networks – and ignore expectations for other peers? Jason From clayton at MNSi.Net Thu May 15 17:35:38 2014 From: clayton at MNSi.Net (Clayton Zekelman) Date: Thu, 15 May 2014 13:35:38 -0400 Subject: FTTH ONTs and routers In-Reply-To: <5374F538.5010108@vaxination.ca> References: <5374F538.5010108@vaxination.ca> Message-ID: <1400175340_128176@surgemail.mnsi.net> At 01:11 PM 15/05/2014, Jean-Francois Mezei wrote: >It had been my impression that ONTs, like most other consumer modems, >came with built-in router capabilities (along with ATA for voice). > >The assertion that ONTs have built-in routing capabilities has been >challenged. By who? >Can anyone confirm whether ONTs generally have routing (aka: home router >that does the PPPoE or DHCP and then NAT for home) capabilities? All the unit's I've seen have this capability. We don't use it though. >Are there examples where a telco has deployed ONTs with the router >built-in and enabled ? Or would almost all FTTH deployments be made with >any routing disabled and the ONT acting as a pure ethernet bridge ? No way to tell, since configuring routing capability in a router that has it built in is a relatively trivial task. It would be like asking how many people use the "bagel" button on their toaster, if it has this capability built in. --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From jfmezei_nanog at vaxination.ca Thu May 15 17:43:08 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 15 May 2014 13:43:08 -0400 Subject: FTTH ONTs and routers In-Reply-To: <1400175340_128176@surgemail.mnsi.net> References: <5374F538.5010108@vaxination.ca> <1400175340_128176@surgemail.mnsi.net> Message-ID: <5374FCAC.8010708@vaxination.ca> Many thanks for the answers so far. On 14-05-15 13:35, Clayton Zekelman wrote: >>The assertion that ONTs have built-in routing capabilities has been >>challenged. > > By who? A rather large company in Canada whose name contains the last name of the inventor of the Telephone :-) (actually from their Atlantic Canada arm). I know that Bell Canada's FTTH deployment includes a Sagemcom VDSL modem after the ONT. It uses it as plain router in FTTH because it supports twin VLANs (one for internet and other for IPTV) and I guess they figured it would be easier to standarize on a single router across its DSL and FTTH footprint. Not sure what Bell Aliant uses. My argument had been that in a wholesale context, the Sagemcom must not be included when wholesale service since it is not necessary. From nick at pelagiris.org Thu May 15 17:43:58 2014 From: nick at pelagiris.org (Nick B) Date: Thu, 15 May 2014 13:43:58 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> Message-ID: Yes, throttling an entire ISP by refusing to upgrade peering is clearly a way to avoid technically throttling. Interestingly enough only Comcast and Verizon are having this problem, though I'm sure now that you have set an example others will follow. Nick On Thu, May 15, 2014 at 1:34 PM, Livingood, Jason < Jason_Livingood at cable.comcast.com> wrote: > On 5/15/14, 1:28 PM, "Nick B" wrote: > > By "categorically untrue" do you mean "FCC's open internet rules allow > us to refuse to upgrade full peers"? > > > Throttling is taking, say, a link from 10G and applying policy to > constrain it to 1G, for example. What if a peer wants to go from a balanced > relationship to 10,000:1, well outside of the policy binding the > relationship? Should we just unquestionably toss out our published policy – > which is consistent with other networks – and ignore expectations for other > peers? > > Jason > From khelms at zcorum.com Thu May 15 17:48:10 2014 From: khelms at zcorum.com (Scott Helms) Date: Thu, 15 May 2014 13:48:10 -0400 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: References: <201405151658.s4FGwTWt000124@aurora.sol.net> <5374F40E.8010603@hack.net> Message-ID: Its not really that complex, if you think about it having 10000s of 'movieco' with the same priority is the status quo. At the end of the day the QoS mechanics in DOCSIS are pretty straightforward and rely on service flows, while service flows can have equal priority I doubt most operators will sell more than a few (perhaps just one) top priority in a given a category. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, May 15, 2014 at 1:22 PM, Christopher Morrow wrote: > On Thu, May 15, 2014 at 1:06 PM, Ryan Brooks wrote: > > On 5/15/14, 11:58 AM, Joe Greco wrote: > >> > >> 2) Netflix purchases 5Mbps "fast lane" > >> > > > > I appreciate Joe's use of quotation marks here. A lot of the dialog > has > > included this 'fast lane' terminology, yet all of us know there's no > 'fast > > lane' being constructed, rather just varying degrees of _slow_ applied to > > existing traffic. > > > > please correct me if I'm wrong, but 'fast lane' really is (in this > example): > 'cableco' port from 'moviecompany' has 'qos' marking configuration > to set all 'moviecompany' traffic (from this port!) to some priority > level. > > customer-port to 'cableco' has 'qos' handling/queuing that will > ensure '5mbps' of 'moviecompany' is always going to get down the link > to the customer, regardless of the other traffic the customer is > requesting. > > right? (presume that in the rest of the 'cableco' network is > protecting 'moviecompany' traffic as well, of course) > > So, when there are 1 'moviecompany' things to prioritize and deliver > that's cool... but what about when there are 10? 100? 1000? doesn't > the queuing get complicated? what if the 'cableco' customer with > 10mbps link has 3 people in the location all streaming from 3 > different 'moviecompany' organizations which have paid for 'fastlane' > services? > > 3 x 5 == 15 ... not 10. How will 'cableco' manage this when their > 100gbps inter-metro links are seeing +100gbps if 'fastlane' traffic > and 'fastlane' traffic can't make it to the local metro from the > remote one? > > This all seems much, much more complicated and expensive than just > building out networking, which they will have to do in the end anyway, > right? Only with 'fastlanes' there's extra capacity management and > configuration and testing and ... all on top of: "Gosh, does the new > umnptyfart card from routerco actually work in old routerco routers?" > > This looks, to me, like nuttiness... like mutually assured destruction > that the cableco folk are driving both parties into intentionally. > > -chris > > BTW: I didn't use a particular 'cable company' name for 'cableco', nor > did I use a particular streaming media company for 'moviecompany'... > Also, 'cableco' is short-hand for > 'lastmile-consumer-provider-network'. Less typing was better, for me, > I thought. > From jgreco at ns.sol.net Thu May 15 17:48:49 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 15 May 2014 12:48:49 -0500 (CDT) Subject: Observations of an Internet Middleman (Level3) In-Reply-To: Message-ID: <201405151748.s4FHmns9000874@aurora.sol.net> Blake Dunlap wrote: > And the "unbalanced" peers / transit? Surely it is too much to expect a service provider to actually provide service even if it is not entirely fair and balanced. It's not like, you know, anyone was paying them to provide a service ... [...rewind...] wrote: > This is a smart group. Well, smart enough to at least try to see it for what it actually is. Telling us we're smart and then expecting us to swallow a load doesn't quite seem to work, judging from the last few responses you've had. Some of us are actually businesspeople, so we understand the issues from multiple dimensions. Including historical ones, where there are both examples of Monopolies Gone Wild! (Spring Break Edition!) and also Government Regulation Gone Overboard. If you'd like to say that you're trying to leverage as much revenue as possible by taking advantage of new trends (i.e. cord cutting) in a customer base that's at least partially without other reasonable options, while keeping investment costs as low as possible, well, then, we have the potential for an honest conversation. But if you're going to tell us about how you've managed to acquire transit customers, that feels like the start of a dishonest discussion because basically most of us here wouldn't buy transit from a cable company unless it was the only available option, or there was some other distorting reason - such as congestion - that caused such an arrangement to be needed. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From morrowc.lists at gmail.com Thu May 15 18:01:03 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 15 May 2014 14:01:03 -0400 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: References: <201405151658.s4FGwTWt000124@aurora.sol.net> <5374F40E.8010603@hack.net> Message-ID: On Thu, May 15, 2014 at 1:48 PM, Scott Helms wrote: > Its not really that complex, if you think about it having 10000s of > 'movieco' with the same priority is the status quo. At the end of the day > the QoS mechanics in DOCSIS are pretty straightforward and rely on service > flows, while service flows can have equal priority I doubt most operators > will sell more than a few (perhaps just one) top priority in a given a > category. > yes, there will only ever be 5 computers. or you couldn't possibly need more than 640kb of ram..... or more than 4billion 'ip addresses'. I don't think you have to get to more than 10 or 20 of the stated examples before things get dicey ... Once a set of customers experience (and can measure) the effect, they'll back their complaints up to 'moviecompany' and some set of contract penalties will kick in, I suspect. Sure, if there is only one it's not a problem, but there are already not just one... > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > On Thu, May 15, 2014 at 1:22 PM, Christopher Morrow > wrote: >> >> On Thu, May 15, 2014 at 1:06 PM, Ryan Brooks wrote: >> > On 5/15/14, 11:58 AM, Joe Greco wrote: >> >> >> >> 2) Netflix purchases 5Mbps "fast lane" >> >> >> > >> > I appreciate Joe's use of quotation marks here. A lot of the dialog >> > has >> > included this 'fast lane' terminology, yet all of us know there's no >> > 'fast >> > lane' being constructed, rather just varying degrees of _slow_ applied >> > to >> > existing traffic. >> > >> >> please correct me if I'm wrong, but 'fast lane' really is (in this >> example): >> 'cableco' port from 'moviecompany' has 'qos' marking configuration >> to set all 'moviecompany' traffic (from this port!) to some priority >> level. >> >> customer-port to 'cableco' has 'qos' handling/queuing that will >> ensure '5mbps' of 'moviecompany' is always going to get down the link >> to the customer, regardless of the other traffic the customer is >> requesting. >> >> right? (presume that in the rest of the 'cableco' network is >> protecting 'moviecompany' traffic as well, of course) >> >> So, when there are 1 'moviecompany' things to prioritize and deliver >> that's cool... but what about when there are 10? 100? 1000? doesn't >> the queuing get complicated? what if the 'cableco' customer with >> 10mbps link has 3 people in the location all streaming from 3 >> different 'moviecompany' organizations which have paid for 'fastlane' >> services? >> >> 3 x 5 == 15 ... not 10. How will 'cableco' manage this when their >> 100gbps inter-metro links are seeing +100gbps if 'fastlane' traffic >> and 'fastlane' traffic can't make it to the local metro from the >> remote one? >> >> This all seems much, much more complicated and expensive than just >> building out networking, which they will have to do in the end anyway, >> right? Only with 'fastlanes' there's extra capacity management and >> configuration and testing and ... all on top of: "Gosh, does the new >> umnptyfart card from routerco actually work in old routerco routers?" >> >> This looks, to me, like nuttiness... like mutually assured destruction >> that the cableco folk are driving both parties into intentionally. >> >> -chris >> >> BTW: I didn't use a particular 'cable company' name for 'cableco', nor >> did I use a particular streaming media company for 'moviecompany'... >> Also, 'cableco' is short-hand for >> 'lastmile-consumer-provider-network'. Less typing was better, for me, >> I thought. > > From khelms at zcorum.com Thu May 15 18:06:24 2014 From: khelms at zcorum.com (Scott Helms) Date: Thu, 15 May 2014 14:06:24 -0400 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: References: <201405151658.s4FGwTWt000124@aurora.sol.net> <5374F40E.8010603@hack.net> Message-ID: Chris, You're not reading what I said, nor did I make a statement anything like one of the silly things you referenced (640k ram etc). Prioritization isn't that complex and today we handle the maximum amount of complexity already since everything is the same priority right now. You're trying to make the statement that giving multiple content providers priority somehow makes connectivity unworkable for consumers as if we don't have this problem already. Consumers can easily starve themselves of bandwidth with video or any other content and almost no connections in the US have any sort of intelligent fair usage buffering provided by the service provider. This is true for both cable, telco, and other operators. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, May 15, 2014 at 2:01 PM, Christopher Morrow wrote: > On Thu, May 15, 2014 at 1:48 PM, Scott Helms wrote: > > Its not really that complex, if you think about it having 10000s of > > 'movieco' with the same priority is the status quo. At the end of the > day > > the QoS mechanics in DOCSIS are pretty straightforward and rely on > service > > flows, while service flows can have equal priority I doubt most operators > > will sell more than a few (perhaps just one) top priority in a given a > > category. > > > > yes, there will only ever be 5 computers. or you couldn't possibly > need more than 640kb of ram..... or more than 4billion 'ip addresses'. > > I don't think you have to get to more than 10 or 20 of the stated > examples before things get dicey ... Once a set of customers > experience (and can measure) the effect, they'll back their complaints > up to 'moviecompany' and some set of contract penalties will kick in, > I suspect. > > Sure, if there is only one it's not a problem, but there are already > not just one... > > > > > Scott Helms > > Vice President of Technology > > ZCorum > > (678) 507-5000 > > -------------------------------- > > http://twitter.com/kscotthelms > > -------------------------------- > > > > > > On Thu, May 15, 2014 at 1:22 PM, Christopher Morrow > > wrote: > >> > >> On Thu, May 15, 2014 at 1:06 PM, Ryan Brooks wrote: > >> > On 5/15/14, 11:58 AM, Joe Greco wrote: > >> >> > >> >> 2) Netflix purchases 5Mbps "fast lane" > >> >> > >> > > >> > I appreciate Joe's use of quotation marks here. A lot of the dialog > >> > has > >> > included this 'fast lane' terminology, yet all of us know there's no > >> > 'fast > >> > lane' being constructed, rather just varying degrees of _slow_ applied > >> > to > >> > existing traffic. > >> > > >> > >> please correct me if I'm wrong, but 'fast lane' really is (in this > >> example): > >> 'cableco' port from 'moviecompany' has 'qos' marking configuration > >> to set all 'moviecompany' traffic (from this port!) to some priority > >> level. > >> > >> customer-port to 'cableco' has 'qos' handling/queuing that will > >> ensure '5mbps' of 'moviecompany' is always going to get down the link > >> to the customer, regardless of the other traffic the customer is > >> requesting. > >> > >> right? (presume that in the rest of the 'cableco' network is > >> protecting 'moviecompany' traffic as well, of course) > >> > >> So, when there are 1 'moviecompany' things to prioritize and deliver > >> that's cool... but what about when there are 10? 100? 1000? doesn't > >> the queuing get complicated? what if the 'cableco' customer with > >> 10mbps link has 3 people in the location all streaming from 3 > >> different 'moviecompany' organizations which have paid for 'fastlane' > >> services? > >> > >> 3 x 5 == 15 ... not 10. How will 'cableco' manage this when their > >> 100gbps inter-metro links are seeing +100gbps if 'fastlane' traffic > >> and 'fastlane' traffic can't make it to the local metro from the > >> remote one? > >> > >> This all seems much, much more complicated and expensive than just > >> building out networking, which they will have to do in the end anyway, > >> right? Only with 'fastlanes' there's extra capacity management and > >> configuration and testing and ... all on top of: "Gosh, does the new > >> umnptyfart card from routerco actually work in old routerco routers?" > >> > >> This looks, to me, like nuttiness... like mutually assured destruction > >> that the cableco folk are driving both parties into intentionally. > >> > >> -chris > >> > >> BTW: I didn't use a particular 'cable company' name for 'cableco', nor > >> did I use a particular streaming media company for 'moviecompany'... > >> Also, 'cableco' is short-hand for > >> 'lastmile-consumer-provider-network'. Less typing was better, for me, > >> I thought. > > > > > From shawnl at up.net Thu May 15 18:11:50 2014 From: shawnl at up.net (Shawn L) Date: Thu, 15 May 2014 14:11:50 -0400 Subject: FTTH ONTs and routers In-Reply-To: References: <5374F538.5010108@vaxination.ca> Message-ID: Calix makes a number of ONTs some with residential gateways, some that are just bridges On Thu, May 15, 2014 at 1:24 PM, Aled Morris wrote: > I notice Cisco's new ME4600 ONT's come in two flavors, one (the > "Residential GateWay") with all the bells and whistles that you'd expect in > an all-in-one home router (voice ports, small ethernet switch, wifi access > point) and another (the "Single Family Unit") that looks a lot more basic > and is likely to be deployed as a bridge. > > > http://www.cisco.com/c/en/us/products/collateral/switches/me-4600-series-multiservice-optical-access-platform/datasheet-c78-730446.html > > Aled > > > On 15 May 2014 18:11, Jean-Francois Mezei >wrote: > > > > > It had been my impression that ONTs, like most other consumer modems, > > came with built-in router capabilities (along with ATA for voice). > > > > The assertion that ONTs have built-in routing capabilities has been > > challenged. > > > > Can anyone confirm whether ONTs generally have routing (aka: home router > > that does the PPPoE or DHCP and then NAT for home) capabilities? > > > > Are there examples where a telco has deployed ONTs with the router > > built-in and enabled ? Or would almost all FTTH deployments be made with > > any routing disabled and the ONT acting as a pure ethernet bridge ? > > > > > > (I appreciate your help on this as I am time constrained to do research). > > > > > From Jason_Livingood at cable.comcast.com Thu May 15 18:11:30 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 15 May 2014 18:11:30 +0000 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> Message-ID: So by extension, if you enter an agreement and promise to remain balanced you can just willfully throw that out and abuse the heck out of it? Where does it end? Why even bother having peering policies at all then? To use an analogy, if you and I agree to buy a car together and agree to switch off who uses it every other day, can I just say "forget our agreement – I’m just going to drive the car myself every single day – its all mine”? And as you say, “interestingly enough only Comcast and Verizon are having this problem” someone else might say “interestingly enough one content distributor is at the center of all of these issues.” I’m frankly surprised that no one is stepping back to try to understand what was and is driving those changes. Jason On 5/15/14, 1:43 PM, "Nick B" > wrote: Yes, throttling an entire ISP by refusing to upgrade peering is clearly a way to avoid technically throttling. Interestingly enough only Comcast and Verizon are having this problem, though I'm sure now that you have set an example others will follow. Nick From Kevin_McElearney at cable.comcast.com Thu May 15 18:22:34 2014 From: Kevin_McElearney at cable.comcast.com (McElearney, Kevin) Date: Thu, 15 May 2014 18:22:34 +0000 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> , Message-ID: I said I would step away, but trying to keep some level of emotion out of this... We all need "rational actor" behavior in the ecosystem. We need our policies and agree to live up to those policies between players. Random and inconsistent behavior does not build a well functioning market and is the root of most disputes We can argue about what the policy should be, the impacts, etc and that is a fair discussion. - Kevin 215-313-1083 On May 15, 2014, at 2:11 PM, "Livingood, Jason" > wrote: So by extension, if you enter an agreement and promise to remain balanced you can just willfully throw that out and abuse the heck out of it? Where does it end? Why even bother having peering policies at all then? To use an analogy, if you and I agree to buy a car together and agree to switch off who uses it every other day, can I just say "forget our agreement – I’m just going to drive the car myself every single day – its all mine”? And as you say, “interestingly enough only Comcast and Verizon are having this problem” someone else might say “interestingly enough one content distributor is at the center of all of these issues.” I’m frankly surprised that no one is stepping back to try to understand what was and is driving those changes. Jason On 5/15/14, 1:43 PM, "Nick B" > wrote: Yes, throttling an entire ISP by refusing to upgrade peering is clearly a way to avoid technically throttling. Interestingly enough only Comcast and Verizon are having this problem, though I'm sure now that you have set an example others will follow. Nick From jgreco at ns.sol.net Thu May 15 18:25:14 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 15 May 2014 13:25:14 -0500 (CDT) Subject: Observations of an Internet Middleman (Level3) In-Reply-To: Message-ID: <201405151825.s4FIPEH4001292@aurora.sol.net> > On Thu, May 15, 2014 at 1:06 PM, Ryan Brooks wrote: > > On 5/15/14, 11:58 AM, Joe Greco wrote: > >> 2) Netflix purchases 5Mbps "fast lane" > > > > I appreciate Joe's use of quotation marks here. A lot of the dialog has > > included this 'fast lane' terminology, yet all of us know there's no 'fast > > lane' being constructed, rather just varying degrees of _slow_ applied to > > existing traffic. > > please correct me if I'm wrong, but 'fast lane' really is (in this example): > 'cableco' port from 'moviecompany' has 'qos' marking configuration > to set all 'moviecompany' traffic (from this port!) to some priority > level. I think that's a possibility, but that we're actually talking at a less-technical level. [...] > 3 x 5 == 15 ... not 10. How will 'cableco' manage this when their > 100gbps inter-metro links are seeing +100gbps if 'fastlane' traffic > and 'fastlane' traffic can't make it to the local metro from the > remote one? #whocares You've made a technical implementation issue out of a mostly non-tech issue. > This all seems much, much more complicated and expensive than just > building out networking, which they will have to do in the end anyway, > right? Only with 'fastlanes' there's extra capacity management and > configuration and testing and ... all on top of: "Gosh, does the new > umnptyfart card from routerco actually work in old routerco routers?" I certainly agree. This isn't a technical issue though. A majority of the people on this list should appreciate the costs associated with building and maintaining networks, and there are lots of them to be sure. This is about other aspects of the business. > This looks, to me, like nuttiness... like mutually assured destruction > that the cableco folk are driving both parties into intentionally. No. I don't actually believe that. Businesses are in the habit of making money. There's a reasonably strong desire to remain in business and hopefully make a profit. To that end, in the capitalist model, competition serves to lower prices and increase quality to levels that the average consumer finds acceptable. A monopoly or duopoly environment distorts that; in a market with a constrained number of providers, the conventional capitalistic model can perform poorly or even fail entirely - as an example, consider the LCD price fixing scandal last decade, where prices ended up artificially high. The current situation is worse; the telcos and cablecos have a bunch of incentives to prevent cannibalizing their existing profitable pay TV product lines... which are seeing competition from the likes of Netflix. And there's even some legitimacy there: if all of those customers suddenly dropped their pay TV service and went to Netflix, the whole economic underpinnings of a cable TV company could be thrown into disarray. Because those pay TV subscribers are in some way contributing to covering the opex and capex of the cable TV distribution network. That'd also be damaging to the last mile IP connectivity, heh. But it's hard to have an honest discussion about all of this when those involved are so busy trying to spin things in their favor, and to keep the status quo, etc. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From ikiris at gmail.com Thu May 15 18:28:57 2014 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 15 May 2014 13:28:57 -0500 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> Message-ID: I agree, and those peers should be then paid for the bits that your customers are requesting that they send through you if you cannot maintain a balanced peer relationship with them. It's shameful that access networks are attempting to not pay for their leeching of mass amounts of data in clear violation of standard expectations for balanced peering agreements. Oh... you meant something else? -Blake On Thu, May 15, 2014 at 12:34 PM, Livingood, Jason wrote: > On 5/15/14, 1:28 PM, "Nick B" > wrote: > > By "categorically untrue" do you mean "FCC's open internet rules allow us to refuse to upgrade full peers"? > > Throttling is taking, say, a link from 10G and applying policy to constrain it to 1G, for example. What if a peer wants to go from a balanced relationship to 10,000:1, well outside of the policy binding the relationship? Should we just unquestionably toss out our published policy – which is consistent with other networks – and ignore expectations for other peers? > > Jason From owen at delong.com Thu May 15 18:27:31 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 15 May 2014 11:27:31 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <5374F6D3.9040408@vaxination.ca> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> , <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <37AFC907-CAB5-4721-B79D-EAE2687970BF@puck.nether.net> <74642389-7742-406C-9FC4-C0B0B4940136@delong.com> <5374F6D3.9040408@vaxination.ca> Message-ID: On May 15, 2014, at 10:18 AM, Jean-Francois Mezei wrote: > On 14-05-15 10:26, Owen DeLong wrote: >> Choosing between Comcast and a legacy Telco is like choosing between legionnaire’s disease and SARS. > > Twisted pair is certantly "legacy". > > Is there a feeling that coax cable/DOSCIS is also "legacy" in terms of > current capacity/speeds ? Or is that technology still considered viable > against FTTH ? > > I realise that business practices make north american incumbents > undesirable compared to the rest of the world, especially Comcast's > dirty tricks with Netflix as an example. > > But in terms of the last mile technology and wiring (for instance, homes > per HFC node) sre north american cavlecos up to par with the rest of the > world ? I am not speaking specifically about any one company here. In North America, very few places have any level of FTTH. If you are in a rural area with USF subsidies, you are more likely to have FTTH than many urban areas. Co-ax, or if you’re somewhat lucky, HFC is about the best last mile technology available to most US subscribers. In states where some city invested in municipal FTTH on an open-access basis, the incumbent $CABLECOS and $TELCOS have fought hard to push legislation making it illegal for other cities in the state to do the same. The state of broadband networks in the US in general can best be described as pathetic and/or apathetic when it comes to the consumer’s interest. Lilly Tomlin summed this up very well in a number of her early comedy sketches where she pretended to be a telephone company operator. Her catch phrase was “We don’t care. We don’t have to. We’re the phone company!” Further, it appears that several of the $CABLECOS and $TELCOS will actually attempt to quash their more vocal opponents by discussing public comments they make on a personal basis with said opponents employer and using them as a “negotiating tactic”. Personally, I think this is one of the most underhanded and lowest forms of an act of desperation to try and squash public debate. To be very clear… This statement is absolutely not targeted at any one company. There were several. Owen From owen at delong.com Thu May 15 18:31:34 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 15 May 2014 11:31:34 -0700 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <5374F6BA.4020108@mykolab.com> References: <201405151658.s4FGwTWt000124@aurora.sol.net> <5374F40E.8010603@hack.net> <5374F6BA.4020108@mykolab.com> Message-ID: <0D8895B7-FE65-4A73-96C4-64C3D82D3627@delong.com> That link is broken and insists that I install a windows upgrade for Flash on my Mac. Owen On May 15, 2014, at 10:17 AM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 5/15/2014 10:06 AM, Ryan Brooks wrote: > >> It's a shame the use of 'fast lane' is ubiquitous in this argument. >> If the local distribution networks would like to actually build >> something fast, then this would be a different story. > > Okay, then call it the "faster lane" or the "uncongested lane" or > something that actually reflects bias and preferential treatment. It's > a done deal now: > > http://www.washingtonpost.com/blogs/the-switch/wp/2014/05/15/fcc-approves-plan-to-allow-for-paid-priority-on-internet > > FYI, > > - - ferg > > > - -- > Paul Ferguson > VP Threat Intelligence, IID > PGP Public Key ID: 0x54DC85B2 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlN09roACgkQKJasdVTchbJPlgEAtBpp0TKNZcIdrDkVP75Tni7a > O9PvcnKZdaPNuNUpOb0A/RQ5hvrqPAu/QLSp8dPbcDSO5Zad8Z3JG67UfI6yaeJH > =DhnX > -----END PGP SIGNATURE----- From fergdawgster at mykolab.com Thu May 15 18:36:52 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Thu, 15 May 2014 11:36:52 -0700 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <0D8895B7-FE65-4A73-96C4-64C3D82D3627@delong.com> References: <201405151658.s4FGwTWt000124@aurora.sol.net> <5374F40E.8010603@hack.net> <5374F6BA.4020108@mykolab.com> <0D8895B7-FE65-4A73-96C4-64C3D82D3627@delong.com> Message-ID: <53750944.7090602@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 No idea -- I use NoScript and block Flash (as well as other dangerous & annoying embedded content) and it works for me. - - ferg On 5/15/2014 11:31 AM, Owen DeLong wrote: > That link is broken and insists that I install a windows upgrade > for Flash on my Mac. > > Owen > > On May 15, 2014, at 10:17 AM, Paul Ferguson > wrote: > > On 5/15/2014 10:06 AM, Ryan Brooks wrote: > >>>> It's a shame the use of 'fast lane' is ubiquitous in this >>>> argument. If the local distribution networks would like to >>>> actually build something fast, then this would be a different >>>> story. > > Okay, then call it the "faster lane" or the "uncongested lane" or > something that actually reflects bias and preferential treatment. > It's a done deal now: > > http://www.washingtonpost.com/blogs/the-switch/wp/2014/05/15/fcc-approves-plan-to-allow-for-paid-priority-on-internet > > FYI, > > - ferg > > > > > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlN1CUMACgkQKJasdVTchbJ+qQEA1PVA2pd4UhdA8onBV/2v/XC/ /hVje/whDjYhLWXMZroA/RlUxhJqQgc5erlnLXz5S2blywH1+e0d6ZtQ96srChne =ychK -----END PGP SIGNATURE----- From owen at delong.com Thu May 15 18:41:59 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 15 May 2014 11:41:59 -0700 Subject: Observations of an Internet Middleman / RIP Network Neutrality Message-ID: > Yes, you've got "some of the largest Internet companies as customers². > Because you told them "if you don't pay us, we'll throttle you". Then > you throttled them. I'm sorry, not a winning argument. > Nick Claims by some large ISPs that this is “untrue” rest on the claim that they don’t do traffic discrimination. While they may not be (and, indeed, are not allowed to) do traffic discrimination, what is ignored is that refusing to add sufficient peering capacity is, to the consumer’s perspective (and to the content provider’s perspective as well) effectively the same thing as throttling. I will note that as yet, not one of these providers has claimed that they did not refuse to increase peering capacity in order to leverage payment, and, indeed, payment does appear to have been leveraged. Owen From swmike at swm.pp.se Thu May 15 18:45:34 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 15 May 2014 20:45:34 +0200 (CEST) Subject: FTTH ONTs and routers In-Reply-To: <5374F538.5010108@vaxination.ca> References: <5374F538.5010108@vaxination.ca> Message-ID: On Thu, 15 May 2014, Jean-Francois Mezei wrote: > Are there examples where a telco has deployed ONTs with the router > built-in and enabled ? Or would almost all FTTH deployments be made with > any routing disabled and the ONT acting as a pure ethernet bridge ? Can we please stop equating FTTH and PON? There are plenty FTTH deployments that are not PON. -- Mikael Abrahamsson email: swmike at swm.pp.se From jgreco at ns.sol.net Thu May 15 18:53:54 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 15 May 2014 13:53:54 -0500 (CDT) Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: Message-ID: <201405151853.s4FIrsed001682@aurora.sol.net> > Throttling is taking, say, a link from 10G and applying policy to constrain= > it to 1G, for example. Throttling is also trying to cram 20G of traffic through that same 10G link. > What if a peer wants to go from a balanced relation= > ship to 10,000:1, well outside of the policy binding the relationship? What if you're running a 10G port at saturation in both directions and you decide to stop accepting announcements from the peer on that port? Now you have a 10,000:0 ratio. Then what? > Should we just unquestionably toss out our published policy =96 which is consis= > tent with other networks =96 and ignore expectations for other peers? What's your goal at the end of the day? You have customers who are paying you for connectivity to "Teh Interwebz". Do you have an obligation to run a dedicated 100GbE to each and every host on the planet? No. Do you have an obligation to make a reasonable effort to move the traffic that your customer is paying you for? Yes. At the end of the day, if I'm your customer and I'm trying to pull 50Mbps of data on my 50Mbps connection that I am buying from you, then it seems like a reasonable thing to expect that you'll have the 50Mbps of capacity to actually fulfill the demand. That does not mean that I will actually GET 50Mbps - it just means that you should be making a reasonable effort and especially that you are not actively sabotaging it, by aggregating it through a congested 10Gbps port, or forcing the packets through a congested peer, or any of a number of other underhanded things. If you cannot figure out how to arrange your transit and peering affairs in a manner that allows you to deliver on what you've sold to customers in the current unregulated model, I think you'll find that the alternative of regulation is very much less palatable. So, to answer your question, yes, if you're unable to figure out that Netflix is always going to generate tons more traffic than it receives, and that your customers desperately want to get good connectivity to there, then that's dumb. Perhaps you should figure out how to arrange peering with sites where there's obviously going to be an unrectifiable traffic imbalance. You're a service provider. What should your goal be? I would have thought it obvious: Provide the service. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From surfer at mauigateway.com Thu May 15 18:58:44 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 15 May 2014 11:58:44 -0700 Subject: Observations of an Internet Middleman (Level3) Message-ID: <20140515115844.55D87403@m0005296.ppops.net> From: Paul Ferguson On 5/15/2014 10:06 AM, Ryan Brooks wrote: > It's a shame the use of 'fast lane' is ubiquitous in this argument. > If the local distribution networks would like to actually build > something fast, then this would be a different story. Okay, then call it the "faster lane" or the "uncongested lane" or something that actually reflects bias and preferential treatment. It's a done deal now: http://www.washingtonpost.com/blogs/the-switch/wp/2014/05/15/fcc-approves-plan-to-allow-for-paid-priority-on-internet -------------------------------------------- According to the doc it's not a done deal: "The proposal is not a final rule, but the vote on Thursday is a significant step forward" "Agencies almost always change their rules from the initial proposal" "The next phase will be four months of public comments, after which the commissioners will vote again on redrafted rules that are meant to take into account public opinion." But, yeah. I don't believe for a minute that all/any this is above board when it's coming from a lobbyist. scott From khelms at zcorum.com Thu May 15 19:00:31 2014 From: khelms at zcorum.com (Scott Helms) Date: Thu, 15 May 2014 15:00:31 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> Message-ID: AFAIK Comcast wasn't consuming, "mass amounts of data" from Level 3 (Netflix's transit to them). Are you implying that a retail customer has a similar expectation (or should) as a tier 1 ISP has for peering? I hope not, that would be hyperbole verging on the silly. Retail customer agreement spell out, in every example I've seen, realistic terms and expectations for service and those are very different from peering arrangements. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, May 15, 2014 at 2:28 PM, Blake Dunlap wrote: > I agree, and those peers should be then paid for the bits that your > customers are requesting that they send through you if you cannot > maintain a balanced peer relationship with them. It's shameful that > access networks are attempting to not pay for their leeching of mass > amounts of data in clear violation of standard expectations for > balanced peering agreements. > > Oh... you meant something else? > > -Blake > > On Thu, May 15, 2014 at 12:34 PM, Livingood, Jason > wrote: > > On 5/15/14, 1:28 PM, "Nick B" nick at pelagiris.org>> wrote: > > > > By "categorically untrue" do you mean "FCC's open internet rules allow > us to refuse to upgrade full peers"? > > > > Throttling is taking, say, a link from 10G and applying policy to > constrain it to 1G, for example. What if a peer wants to go from a balanced > relationship to 10,000:1, well outside of the policy binding the > relationship? Should we just unquestionably toss out our published policy – > which is consistent with other networks – and ignore expectations for other > peers? > > > > Jason > From effinjdent at gmail.com Thu May 15 19:02:19 2014 From: effinjdent at gmail.com (Jerry Dent) Date: Thu, 15 May 2014 14:02:19 -0500 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> Message-ID: If traffic is unbalanced, what determines who is the payer and who is the payee? Apparently whoever can hold on to their customers better while performance is shit. On Thu, May 15, 2014 at 1:28 PM, Blake Dunlap wrote: > I agree, and those peers should be then paid for the bits that your > customers are requesting that they send through you if you cannot > maintain a balanced peer relationship with them. It's shameful that > access networks are attempting to not pay for their leeching of mass > amounts of data in clear violation of standard expectations for > balanced peering agreements. > > Oh... you meant something else? > > -Blake > > On Thu, May 15, 2014 at 12:34 PM, Livingood, Jason > wrote: > > On 5/15/14, 1:28 PM, "Nick B" nick at pelagiris.org>> wrote: > > > > By "categorically untrue" do you mean "FCC's open internet rules allow > us to refuse to upgrade full peers"? > > > > Throttling is taking, say, a link from 10G and applying policy to > constrain it to 1G, for example. What if a peer wants to go from a balanced > relationship to 10,000:1, well outside of the policy binding the > relationship? Should we just unquestionably toss out our published policy – > which is consistent with other networks – and ignore expectations for other > peers? > > > > Jason > From morrowc.lists at gmail.com Thu May 15 19:05:32 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 15 May 2014 15:05:32 -0400 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: References: <201405151658.s4FGwTWt000124@aurora.sol.net> <5374F40E.8010603@hack.net> Message-ID: On Thu, May 15, 2014 at 2:06 PM, Scott Helms wrote: > Chris, > > You're not reading what I said, nor did I make a statement anything like > one of the silly things you referenced (640k ram etc). Prioritization isn't yes I made a joke. (*three of them actually) > that complex and today we handle the maximum amount of complexity already > since everything is the same priority right now. sure... simple networking, no priorities. > You're trying to make the statement that giving multiple content providers > priority somehow makes connectivity unworkable for consumers as if we don't > have this problem already. Consumers can easily starve themselves of not unworkable for the consumer, per say. it makes guaranteeing that 'fast-lane' for those folk that do pay for it harder. The cableco/etc will potentially have to provide the equivalent 'fast-lane' bandwidth for each consumer, or risk contract breach with some of their paying 'fast-lane' purchasers. or that's sort of what it looks like to me... of course statistical multiplexing and 'long tail' and other things probably mean this isn't a 'happens to all households' problem, but it could happen to a goodly portion if enough services become popular in an example household. > bandwidth with video or any other content and almost no connections in the > US have any sort of intelligent fair usage buffering provided by the service > provider. This is true for both cable, telco, and other operators. sure, but there's no contractual problem with lost bits/streams today... because 'moviecompany' didn't pay for a 'premium service' (or priority or...) from 'cableco'. -chris > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > On Thu, May 15, 2014 at 2:01 PM, Christopher Morrow > wrote: >> >> On Thu, May 15, 2014 at 1:48 PM, Scott Helms wrote: >> > Its not really that complex, if you think about it having 10000s of >> > 'movieco' with the same priority is the status quo. At the end of the >> > day >> > the QoS mechanics in DOCSIS are pretty straightforward and rely on >> > service >> > flows, while service flows can have equal priority I doubt most >> > operators >> > will sell more than a few (perhaps just one) top priority in a given a >> > category. >> > >> >> yes, there will only ever be 5 computers. or you couldn't possibly >> need more than 640kb of ram..... or more than 4billion 'ip addresses'. >> >> I don't think you have to get to more than 10 or 20 of the stated >> examples before things get dicey ... Once a set of customers >> experience (and can measure) the effect, they'll back their complaints >> up to 'moviecompany' and some set of contract penalties will kick in, >> I suspect. >> >> Sure, if there is only one it's not a problem, but there are already >> not just one... >> >> > >> > Scott Helms >> > Vice President of Technology >> > ZCorum >> > (678) 507-5000 >> > -------------------------------- >> > http://twitter.com/kscotthelms >> > -------------------------------- >> > >> > >> > On Thu, May 15, 2014 at 1:22 PM, Christopher Morrow >> > wrote: >> >> >> >> On Thu, May 15, 2014 at 1:06 PM, Ryan Brooks wrote: >> >> > On 5/15/14, 11:58 AM, Joe Greco wrote: >> >> >> >> >> >> 2) Netflix purchases 5Mbps "fast lane" >> >> >> >> >> > >> >> > I appreciate Joe's use of quotation marks here. A lot of the >> >> > dialog >> >> > has >> >> > included this 'fast lane' terminology, yet all of us know there's no >> >> > 'fast >> >> > lane' being constructed, rather just varying degrees of _slow_ >> >> > applied >> >> > to >> >> > existing traffic. >> >> > >> >> >> >> please correct me if I'm wrong, but 'fast lane' really is (in this >> >> example): >> >> 'cableco' port from 'moviecompany' has 'qos' marking configuration >> >> to set all 'moviecompany' traffic (from this port!) to some priority >> >> level. >> >> >> >> customer-port to 'cableco' has 'qos' handling/queuing that will >> >> ensure '5mbps' of 'moviecompany' is always going to get down the link >> >> to the customer, regardless of the other traffic the customer is >> >> requesting. >> >> >> >> right? (presume that in the rest of the 'cableco' network is >> >> protecting 'moviecompany' traffic as well, of course) >> >> >> >> So, when there are 1 'moviecompany' things to prioritize and deliver >> >> that's cool... but what about when there are 10? 100? 1000? doesn't >> >> the queuing get complicated? what if the 'cableco' customer with >> >> 10mbps link has 3 people in the location all streaming from 3 >> >> different 'moviecompany' organizations which have paid for 'fastlane' >> >> services? >> >> >> >> 3 x 5 == 15 ... not 10. How will 'cableco' manage this when their >> >> 100gbps inter-metro links are seeing +100gbps if 'fastlane' traffic >> >> and 'fastlane' traffic can't make it to the local metro from the >> >> remote one? >> >> >> >> This all seems much, much more complicated and expensive than just >> >> building out networking, which they will have to do in the end anyway, >> >> right? Only with 'fastlanes' there's extra capacity management and >> >> configuration and testing and ... all on top of: "Gosh, does the new >> >> umnptyfart card from routerco actually work in old routerco routers?" >> >> >> >> This looks, to me, like nuttiness... like mutually assured destruction >> >> that the cableco folk are driving both parties into intentionally. >> >> >> >> -chris >> >> >> >> BTW: I didn't use a particular 'cable company' name for 'cableco', nor >> >> did I use a particular streaming media company for 'moviecompany'... >> >> Also, 'cableco' is short-hand for >> >> 'lastmile-consumer-provider-network'. Less typing was better, for me, >> >> I thought. >> > >> > > > From jgreco at ns.sol.net Thu May 15 19:05:57 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 15 May 2014 14:05:57 -0500 (CDT) Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: Message-ID: <201405151905.s4FJ5w4s001864@aurora.sol.net> > So by extension, if you enter an agreement and promise to remain balanced y= > ou can just willfully throw that out and abuse the heck out of it? Where do= > es it end? Why even bother having peering policies at all then? It doesn't strike you as a ridiculous promise to extract from someone? "Hi I'm an Internet company. I don't actually know what the next big thing next year will be but I promise that I won't host it on my network and cause our traffic to become lopsided." Wow. Is that what you're saying? > To use an analogy, if you and I agree to buy a car together and agree to sw= > itch off who uses it every other day, can I just say "forget our agreement = > =96 I=92m just going to drive the car myself every single day =96 its all m= > ine=94? Seems like a poor analogy since I'm pretty sure both parties on a peering can use the port at the same time. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jgreco at ns.sol.net Thu May 15 19:07:05 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 15 May 2014 14:07:05 -0500 (CDT) Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <0D8895B7-FE65-4A73-96C4-64C3D82D3627@delong.com> Message-ID: <201405151907.s4FJ75RE001877@aurora.sol.net> > That link is broken and insists that I install a windows upgrade for = > Flash on my Mac. Try http://arstechnica.com/tech-policy/2014/05/fcc-votes-for-internet-fast-lanes-but-could-change-its-mind-later/ ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From Jason_Livingood at cable.comcast.com Thu May 15 19:48:03 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 15 May 2014 19:48:03 +0000 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <201405151905.s4FJ5w4s001864@aurora.sol.net> References: <201405151905.s4FJ5w4s001864@aurora.sol.net> Message-ID: On 5/15/14, 3:05 PM, "Joe Greco" wrote: >"Hi I'm an Internet company. I don't actually know what the next big >thing next year will be but I promise that I won't host it on my network >and cause our traffic to become lopsided." > >Wow. Is that what you're saying? Of course not. JL From khelms at zcorum.com Thu May 15 19:54:56 2014 From: khelms at zcorum.com (Scott Helms) Date: Thu, 15 May 2014 15:54:56 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <201405151905.s4FJ5w4s001864@aurora.sol.net> References: <201405151905.s4FJ5w4s001864@aurora.sol.net> Message-ID: On Thu, May 15, 2014 at 3:05 PM, Joe Greco wrote: > > So by extension, if you enter an agreement and promise to remain > balanced y= > > ou can just willfully throw that out and abuse the heck out of it? Where > do= > > es it end? Why even bother having peering policies at all then? > > It doesn't strike you as a ridiculous promise to extract from someone? > You could certainly say its ridiculous, but it is (and has been) the basis for almost all peering arrangements in North America for several decades in my personal experience. I believe that the practice came from the telco world when large telephone companies would exchange traffic without billing each other so long as the traffic was relatively balanced. You can imagine AT&T and Sprint exchange toll traffic and so long as things we're fairly close there wasn't a big imbalance of traffic to worry the financial folks over and thus having to do exact accounting on each minute, which was technically challenging 30 years ago. "Hi I'm an Internet company. I don't actually know what the next big > thing next year will be but I promise that I won't host it on my network > and cause our traffic to become lopsided." > > Wow. Is that what you're saying? > That's not what happened. What happened is that Netflix went to Level 3 who already had a peering arrangement with Comcast which was built around normal (roughly) balanced peering. It had been in place for years before Netflix signed with Level 3 and worked, and was contracted this way, around relatively balanced traffic. Once Netflix started sending most of their traffic destined to Comcast end user through Level 3 things got out of balance. Netflix still has a contract with Cogent (I believe that is the correct one) or other provider that had previously been handling the bulk of the Comcast directed traffic, but the Level 3 connection was cheaper for Netflix. If anyone actually acted in bad faith it was, IMO, Level 3. > > > To use an analogy, if you and I agree to buy a car together and agree to > sw= > > itch off who uses it every other day, can I just say "forget our > agreement = > > =96 I=92m just going to drive the car myself every single day =96 its > all m= > > ine=94? > > Seems like a poor analogy since I'm pretty sure both parties on a peering > can use the port at the same time. > His point was you can't simply change a contract without having both parties involved. Level 3 tried to do just that. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] > then I > won't contact you again." - Direct Marketing Ass'n position on e-mail > spam(CNN) > With 24 million small businesses in the US alone, that's way too many > apples. > From scott at sberkman.net Thu May 15 20:16:26 2014 From: scott at sberkman.net (Scott Berkman) Date: Thu, 15 May 2014 16:16:26 -0400 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <8AFC1EC8-5F2E-4645-B57C-A147FC56B390@cable.comcast.com> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> , <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com>, <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com>, <5374E013.1050708@sberkman.net> <8AFC1EC8-5F2E-4645-B57C-A147FC56B390@cable.comcast.com> Message-ID: <5375209A.20003@sberkman.net> I guess I should have said this another way. Everyone knows Comcast uses (or used) Sandvine for shaping (unless they've finished building a new probably internal solution, I'm sure this is another secret we'll only have rumors to work with, ). By shaping other traffic (IPSEC VPNs or P2P traffic for example) into BE or limited queues, and then not shaping or prioritizing traffic to test sites, the customer gets invalid data and expectations. I'm no longer in a position to test this for reporting to the FCC as suggested, but in a previous life we were able to prove it enough for the Comcast customer getting the short end of the stick to stop yelling at us and get a new provider, which of course made everyone involved happier. If Comcast has since actually completely torn down that infrastructure to openly comply with the FCC's rules that came out of the legal battle regarding P2P shaping, again congrats to the customers that hopefully get to see some benefit. I'd love to see a case study published by Comcast on how that project went and what the impacts to the network and bottom line were. -Scott On 05/15/2014 11:50 AM, McElearney, Kevin wrote: > There is no gaming on measurements and disputes are isolated and temporary with issues not unique over the history of the internet. I think all the same rhetorical quotes continue to be reused > > - Kevin > >> On May 15, 2014, at 11:43 AM, "Scott Berkman" wrote: >> >> Unfortunately these build-outs are primarily in subscriber facing bandwidth and number of headend locations (to add more customers to the network). These peering point/transit connection issues have been going on for a long time, evidenced by Level 3 coming out with this post. Comcast is also suspiciously absent from public exchanges (TelX's TIE would be one example) while many of their competitors participate for the benefit of the Internet as a whole and their customers. >> >> Measured broadband is also a game, because its very easy for large providers to give priority to (or otherwise "help") known speed test and similar sites, giving customers a false impression of their available capacity or performance. We've all seen cases where customers have some amazing result on their favorite test site, and then real world performance can't even come close. >> >> That said, if Comcast does or is making efforts to finally resolve this, more power to them and congratulations to their customers. Unfortunately trying to brute-force the industry and external content providers tells a very different story. Where is Comcast's official blog post showing evidence as to where they do ensure their peering and or transit to the largest Tier 1 providers are not congested? Instead all we see are policy arguments about who should pay for what, while users continue to suffer. >> >> This is really similar to when TV providers have spats with content owners, and the result is the end users missing out on something they are paying for. It is good for related industries and the large players in each to keep working with each other in open ways to keep pricing reasonable (as opposed to working together in hiding to price fix), but it is not OK to do so by throwing tantrums and making everyone involved suffer. >> >> -Scott >> >> >>> On 05/15/2014 10:57 AM, McElearney, Kevin wrote: >>> Upgrades/buildout are happening every day. They are continuous to keep ahead of demand and publicly measured by SamKnows (FCC measuring broadband), Akamai, Ookla, etc >>> >>> What is not well known is that Comcast has been an existing commercial transit business for 15+ years (with over 8000 commercial fiber customers). Comcast also has over 40 balanced peers with plenty of capacity, and some of the largest Internet companies as customers. >>> >>> - Kevin >>> >>> 215-313-1083 >>> >>>> On May 15, 2014, at 10:19 AM, "Owen DeLong" wrote: >>>> >>>> Oh, please do explicate on how this is inaccurate… >>>> >>>> Owen >>>> >>>>> On May 14, 2014, at 2:14 PM, McElearney, Kevin wrote: >>>>> >>>>> Respectfully, this is a highly inaccurate "sound bite" >>>>> >>>>> - Kevin >>>>> >>>>> 215-313-1083 >>>>> >>>>>> On May 14, 2014, at 3:05 PM, "Owen DeLong" wrote: >>>>>> >>>>>> Yes, the more accurate statement would be aggressively seeking new >>>>>> ways to monetize the existing infrastructure without investing in upgrades >>>>>> or additional buildout any more than absolutely necessary. >>>>>> >>>>>> Owen >>>>>> >>>>>> On May 14, 2014, at 8:02 AM, Hugo Slabbert wrote: >>>>>> >>>>>>>> So they seek new sources of revenues, and/or attempt to thwart >>>>>>>>> competition any way they can. >>>>>>> No to the first. Yes to the second. If they were seeking new sources of >>>>>>>> revenue, they'd be massively expanding into un/der served markets and >>>>>>>> aggressively growing over the top services (which are fat margin). >>>>>>> Sure they are (seeking new sources of revenue). They're not necessarily >>>>>>> creating new products or services, i.e. actually adding any value, but they >>>>>>> are finding ways to extract additional revenue from the same pipes, e.g. >>>>>>> through paid peering with content providers. >>>>>>> >>>>>>> I'm not endorsing this; just pointing out that you two are actually in >>>>>>> agreement here. >>>>>>> >>>>>>> -- >>>>>>> Hugo >>>>>>> >>>>>>> >>>>>>>>> On Wed, May 14, 2014 at 7:23 AM, wrote: >>>>>>>>> >>>>>>>>> On 2014-05-14 02:04, Jean-Francois Mezei wrote: >>>>>>>>> >>>>>>>>> On 14-05-13 22:50, Daniel Staal wrote: >>>>>>>>> >>>>>>>>> They have the money. They have the ability to get more money. *They see >>>>>>>>>> no reason to spend money making customers happy.* They can make more >>>>>>>>>> profit without it. >>>>>>>>> There is the issue of control over the market. But also the pressure >>>>>>>>> from shareholders for continued growth. >>>>>>>> Yes. That is true. Except that it's not. >>>>>>>> >>>>>>>> How do service providers grow? Let's explore that: >>>>>>>> >>>>>>>> What is growth for a transit provider? >>>>>>>> >>>>>>>> More (new) access network(s) (connections). >>>>>>>> More bandwidth across backbone pipes. >>>>>>>> >>>>>>>> >>>>>>>> What is growth for access network? >>>>>>>> More subscribers. >>>>>>>> >>>>>>>> Except that the incumbent carriers have shown they have no interest in >>>>>>>> providing decent bandwidth to anywhere but the most profitable rate >>>>>>>> centers. I'd say about 2/3 of the USA is served with quite terrible access. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> The problem with the internet is that while it had promises of wild >>>>>>>>> growth in the 90s and 00s, once penetration reaches a certain level, >>>>>>>>> growth stabilizes. >>>>>>>> Penetration is ABYSMAL sir. Huge swaths of underserved americans exist. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> When you combine this with threath to large incumbents's media and media >>>>>>>>> distribution endeavours by the likes of Netflix (and cat videos on >>>>>>>>> Youtube), large incumbents start thinking about how they will be able to >>>>>>>>> continue to grow revenus/profits when customers will shift spending to >>>>>>>>> vspecialty channels/cableTV to Netflix and customer growth will not >>>>>>>>> compensate. >>>>>>>> Except they aren't. Even in the most profitable rate centers, they've >>>>>>>> declined to really invest in the networks. They aren't a real business. You >>>>>>>> have to remember that. They have regulatory capture, natural/defacto >>>>>>>> monopoly etc etc. They don't operate in the real world of >>>>>>>> risk/reward/profit/loss/uncertainty like any other real business has to. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> So they seek new sources of revenues, and/or attempt to thwart >>>>>>>>> competition any way they can. >>>>>>>> No to the first. Yes to the second. If they were seeking new sources of >>>>>>>> revenue, they'd be massively expanding into un/der served markets and >>>>>>>> aggressively growing over the top services (which are fat margin). They did >>>>>>>> a bit of an advertising campaign of "smart home" offerings, but that seems >>>>>>>> to have never grown beyond a pilot. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> The current trend is to "if you can't fight them, jon them" where >>>>>>>>> cablecos start to include the Netflix app into their proprietary set-top >>>>>>>>> boxes. The idea is that you at least make the customer continue to use >>>>>>>>> your box and your remote control which makes it easier for them to >>>>>>>>> switch between netflix and legacy TV. >>>>>>>> True. I don't know why one of the cablecos hasn't licensed roku, added >>>>>>>> cable card and made that available as a "hip/cool" set top box offering and >>>>>>>> charge another 10.00 a month on top of the standard dvr rental. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Would be interesting to see if those cable companies that are agreeing >>>>>>>>> to add the Netflix app onto their proprietary STBs also play peering >>>>>>>>> capacity games to degrade the service or not. >>>>>>>> So how is the content delivered? Is it over the internet? Or is it over >>>>>>>> the cable plant, from cable headends? From mpalmer at hezmatt.org Thu May 15 20:18:52 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Fri, 16 May 2014 06:18:52 +1000 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: <2EF85817-700B-46E7-A3E8-B73899C7A18F@delong.com> References: <536BBC62.4070805@KingsMountain.com> <1lUt1o01g1cZc5601lUvWZ> <537403E0.5050502@cox.net> <20140515010512.GB10673@hezmatt.org> <2EF85817-700B-46E7-A3E8-B73899C7A18F@delong.com> Message-ID: <20140515201852.GB18835@hezmatt.org> On Thu, May 15, 2014 at 07:29:06AM -0700, Owen DeLong wrote: > The result of deregulating the current environment would only be more pain > and cost to the consumer than we currently have with no improvement in > speeds or capabilities and no additional innovation. Indeed. While I certainly understand (and sympathise with) the sentiments of those who say, "we don't want the government regulating the Internet!", unfortunately in *this* particular battle I can't see a way out of the morass without a certain amount of government intervention. Of course, it would greatly help the situation if the idiotic restrictions imposed by many states making it illegal to setup muni fibre and wifi (at the behest of the monopoly carriers, of course) were repealed (or overridden), and holding companies like Verizon to account for breaking their promises to build out fibre plant, but I think the situation is *such* a mess that removing all the barriers and hoping that things naturally take care of themselves is, well, optimistic at best. - Matt -- You have a 16-bit quantity, but 5 bits of it are here and 2 bits of it are there... and 2 bits of it are back here and 3 bits of it are up there. The C code to extract useful data had so many >> and << operators in it that it looked like the C++ version of "hello world". -- Matt Roberds, ASR From Jason_Livingood at cable.comcast.com Thu May 15 21:19:22 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 15 May 2014 21:19:22 +0000 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <5375209A.20003@sberkman.net> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> <5374E013.1050708@sberkman.net> <8AFC1EC8-5F2E-4645-B57C-A147FC56B390@cable.comcast.com> <5375209A.20003@sberkman.net> Message-ID: On 5/15/14, 4:16 PM, "Scott Berkman" > wrote: Everyone knows Comcast uses (or used) Sandvine for shaping (unless they've finished building a new probably internal solution, I'm sure this is another secret we'll only have rumors to work with, ). Comcast turned off Sandvine’s active traffic management system at the end of 2008; I know because it was my job to do it (and I had nothing to do with the decision to turn on the Sandvine system). ;-) FCC Chairman Kevin Martin required the turn down of that system by EOY 2008. Here is the letter to the FCC confirming that transition was completed on January 9, 2009: http://downloads.comcast.net/docs/comcast-nm-transition-notification.pdf. It was replaced with a protocol-agnosting congestion management system (active only in the DOCSIS network). That system was disclosed here: http://downloads.comcast.net/docs/Attachment_B_Future_Practices.pdf http://tools.ietf.org/html/rfc6057 http://downloads.comcast.net/docs/IETF%2072%20-%20TANA%20BoF%20-%20ISP%20Requirements%20-%20Comcast.pdf http://downloads.comcast.net/docs/Comcast-IETF-P2Pi-20080528.pdf http://downloads.comcast.net/docs/ietf-p2pi-comcast-20080509.pdf There is no other active traffic management system (other than what any ISP has for DDoS protection/mitigation), period. I'm no longer in a position to test this for reporting to the FCC as suggested, but in a previous life we were able to prove it enough for the Comcast customer getting the short end of the stick to stop yelling at us and get a new provider, which of course made everyone involved happier. We used to have a “positive” traffic shaping system called PowerBoost. That enabled customers to boost above their advertised or provisioned rates for brief periods. That system seemed to cause more customer confusion than it was worth and PowerBoost was eliminated across all of our tiers of service. Sometimes tools to notice traffic shaping noticed PowerBoost and it was sometimes hard to explain that we were shaping traffic *up* in capacity rather than down, but I digress. I'd love to see a case study published by Comcast on how that project went and what the impacts to the network and bottom line were. We documented every step of the way on our Network Management page at http://networkmanagement.comcast.net/. You may also be interested to read Alissa Cooper’s September 2013 PhD thesis, which touches on this system on some level at http://www.alissacooper.com/files/Thesis.pdf. There is also a good paper by the Broadband Internet Technical Advisory Group (BITAG) on this topic at http://www.bitag.org/documents/BITAG_-_Congestion_Management_Report.pdf. We at Comcast comply with all of the BITAG recommendations in that paper. Jason From arvindersingh at mail2tor.com Thu May 15 16:49:14 2014 From: arvindersingh at mail2tor.com (arvindersingh at mail2tor.com) Date: Thu, 15 May 2014 17:49:14 +0100 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <696D5986-AB28-4793-976D-FFE542AEB68D@cable.comcast.com> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> , <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com>, <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com>, <5374E013.1050708@sberkman.net> <8AFC1EC8-5F2E-4645-B57C-A147FC56B390@cable.comcast.com>, <696D5986-AB28-4793-976D-FFE542AEB68D@cable.comcast.com> Message-ID: <7d1719ae1b00cd964f2140e92ffb20e5.squirrel@mail2tor2zyjdctd.onion> Kevin first thank you for posting to NANOG to help with the issues...not every day we see Comcast executive on engineering mailing lists. *LOL* I have two issues with the comments: 1. You mention that congestion issues to Comcast peers are temporary. I notice AS6543 "Tata Communication" - major backbone provider to my home country - very very congested for over three years. Will your engineers kindly update the connection as priority? 2. You mention that all packets treated equally - no games. Why does AS7922 assign the speed test different DSCP from regular internet connection? Arvinder S. > This is a smart group. If if that was true I think every internet site / > service one visits from home would be a negatively impacted. That is not > the case > > As I said before, Comcast also has over 40 balanced peers with plenty of > capacity. Wholesale $$ are very small, highly competitive and only "skin > in the game" to promote efficiencies > > - Kevin > > >> On May 15, 2014, at 12:01 PM, "Jared Mauch" >> wrote: >> >> >>> On May 15, 2014, at 11:50 AM, McElearney, Kevin >>> wrote: >>> >>> There is no gaming on measurements and disputes are isolated and >>> temporary with issues not unique over the history of the internet. I >>> think all the same rhetorical quotes continue to be reused >> >> Kevin, >> >> in the past most issues were transient for a few months as both sides >> got complaints, but while at RIPE earlier this week someone commented to >> me: there's no one provider you can buy access from to get a packet-loss >> free connection to all their other business partners/customers. This >> hurts the entire marketplace when there is persistent congestion. >> >> Some of these issues are related to (as Craig called them) "Hypergiants" >> (OTT) but others are due to providers having poor capital models so they >> don't have "budget" for upgrading unless someone pays for that upgrade, >> vs seeing their existing customer base as that source for the capital. >> >> As an engineer, I'm hopeful that those responsible for budgeting will do >> the right thing. As a greedy capitalist, please pay me more $$$. It >> does feel a bit like tic-tac-toe with zero players in wargames though, >> the only way to win is to not play [games]. >> >> - Jared >> > From arvindersingh at mail2tor.com Thu May 15 16:51:47 2014 From: arvindersingh at mail2tor.com (arvindersingh at mail2tor.com) Date: Thu, 15 May 2014 17:51:47 +0100 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com>, Message-ID: <4979e2ebc9739fc8efb1fbad8d39ecf3.squirrel@mail2tor2zyjdctd.onion> Yes Kevin, this is understood - but valid observation from Nick. Can you pls answer my question first? Very curious. Arvinder > Guys, I'm already pretty far off the reservation and will not respond to > trolling. I think most ISPs are starting to avoid participation here for > the same reason. I'm going to stop for a while. > > - Kevin > > > On May 15, 2014, at 12:42 PM, "Nick B" > > wrote: > > Yes, you've got "some of the largest Internet companies as customers". > Because you told them "if you don't pay us, we'll throttle you". Then you > throttled them. I'm sorry, not a winning argument. > Nick > > > On Thu, May 15, 2014 at 10:57 AM, McElearney, Kevin > > > wrote: > Upgrades/buildout are happening every day. They are continuous to keep > ahead of demand and publicly measured by SamKnows (FCC measuring > broadband), Akamai, Ookla, etc > > What is not well known is that Comcast has been an existing commercial > transit business for 15+ years (with over 8000 commercial fiber > customers). Comcast also has over 40 balanced peers with plenty of > capacity, and some of the largest Internet companies as customers. > > - Kevin > > 215-313-1083 > >> On May 15, 2014, at 10:19 AM, "Owen DeLong" >> > wrote: >> >> Oh, please do explicate on how this is inaccurate >> >> Owen >> >>> On May 14, 2014, at 2:14 PM, McElearney, Kevin >>> > >>> wrote: >>> >>> Respectfully, this is a highly inaccurate "sound bite" >>> >>> - Kevin >>> >>> 215-313-1083 >>> >>>> On May 14, 2014, at 3:05 PM, "Owen DeLong" >>>> > wrote: >>>> >>>> Yes, the more accurate statement would be aggressively seeking new >>>> ways to monetize the existing infrastructure without investing in >>>> upgrades >>>> or additional buildout any more than absolutely necessary. >>>> >>>> Owen >>>> >>>> On May 14, 2014, at 8:02 AM, Hugo Slabbert >>>> > wrote: >>>> >>>>>> >>>>>> So they seek new sources of revenues, and/or attempt to thwart >>>>>>> competition any way they can. >>>>> No to the first. Yes to the second. If they were seeking new sources >>>>> of >>>>>> revenue, they'd be massively expanding into un/der served markets >>>>>> and >>>>>> aggressively growing over the top services (which are fat margin). >>>>> >>>>> Sure they are (seeking new sources of revenue). They're not >>>>> necessarily >>>>> creating new products or services, i.e. actually adding any value, >>>>> but they >>>>> are finding ways to extract additional revenue from the same pipes, >>>>> e.g. >>>>> through paid peering with content providers. >>>>> >>>>> I'm not endorsing this; just pointing out that you two are actually >>>>> in >>>>> agreement here. >>>>> >>>>> -- >>>>> Hugo >>>>> >>>>> >>>>>>> On Wed, May 14, 2014 at 7:23 AM, >>>>>>> > wrote: >>>>>>> >>>>>>> On 2014-05-14 02:04, Jean-Francois Mezei wrote: >>>>>>> >>>>>>> On 14-05-13 22:50, Daniel Staal wrote: >>>>>>> >>>>>>> They have the money. They have the ability to get more money. >>>>>>> *They see >>>>>>>> no reason to spend money making customers happy.* They can make >>>>>>>> more >>>>>>>> profit without it. >>>>>>> >>>>>>> There is the issue of control over the market. But also the >>>>>>> pressure >>>>>>> from shareholders for continued growth. >>>>>> >>>>>> >>>>>> Yes. That is true. Except that it's not. >>>>>> >>>>>> How do service providers grow? Let's explore that: >>>>>> >>>>>> What is growth for a transit provider? >>>>>> >>>>>> More (new) access network(s) (connections). >>>>>> More bandwidth across backbone pipes. >>>>>> >>>>>> >>>>>> What is growth for access network? >>>>>> More subscribers. >>>>>> >>>>>> Except that the incumbent carriers have shown they have no interest >>>>>> in >>>>>> providing decent bandwidth to anywhere but the most profitable rate >>>>>> centers. I'd say about 2/3 of the USA is served with quite terrible >>>>>> access. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> The problem with the internet is that while it had promises of wild >>>>>>> growth in the 90s and 00s, once penetration reaches a certain >>>>>>> level, >>>>>>> growth stabilizes. >>>>>> >>>>>> Penetration is ABYSMAL sir. Huge swaths of underserved americans >>>>>> exist. >>>>>> >>>>>> >>>>>> >>>>>>> When you combine this with threath to large incumbents's media and >>>>>>> media >>>>>>> distribution endeavours by the likes of Netflix (and cat videos on >>>>>>> Youtube), large incumbents start thinking about how they will be >>>>>>> able to >>>>>>> continue to grow revenus/profits when customers will shift spending >>>>>>> to >>>>>>> vspecialty channels/cableTV to Netflix and customer growth will not >>>>>>> compensate. >>>>>> >>>>>> Except they aren't. Even in the most profitable rate centers, >>>>>> they've >>>>>> declined to really invest in the networks. They aren't a real >>>>>> business. You >>>>>> have to remember that. They have regulatory capture, natural/defacto >>>>>> monopoly etc etc. They don't operate in the real world of >>>>>> risk/reward/profit/loss/uncertainty like any other real business has >>>>>> to. >>>>>> >>>>>> >>>>>> >>>>>>> So they seek new sources of revenues, and/or attempt to thwart >>>>>>> competition any way they can. >>>>>> >>>>>> No to the first. Yes to the second. If they were seeking new sources >>>>>> of >>>>>> revenue, they'd be massively expanding into un/der served markets >>>>>> and >>>>>> aggressively growing over the top services (which are fat margin). >>>>>> They did >>>>>> a bit of an advertising campaign of "smart home" offerings, but that >>>>>> seems >>>>>> to have never grown beyond a pilot. >>>>>> >>>>>> >>>>>> >>>>>>> The current trend is to "if you can't fight them, jon them" where >>>>>>> cablecos start to include the Netflix app into their proprietary >>>>>>> set-top >>>>>>> boxes. The idea is that you at least make the customer continue to >>>>>>> use >>>>>>> your box and your remote control which makes it easier for them to >>>>>>> switch between netflix and legacy TV. >>>>>> True. I don't know why one of the cablecos hasn't licensed roku, >>>>>> added >>>>>> cable card and made that available as a "hip/cool" set top box >>>>>> offering and >>>>>> charge another 10.00 a month on top of the standard dvr rental. >>>>>> >>>>>> >>>>>> >>>>>> Would be interesting to see if those cable companies that are >>>>>> agreeing >>>>>>> to add the Netflix app onto their proprietary STBs also play >>>>>>> peering >>>>>>> capacity games to degrade the service or not. >>>>>> >>>>>> So how is the content delivered? Is it over the internet? Or is it >>>>>> over >>>>>> the cable plant, from cable headends? >> > > From arvindersingh at mail2tor.com Thu May 15 19:03:34 2014 From: arvindersingh at mail2tor.com (arvindersingh at mail2tor.com) Date: Thu, 15 May 2014 20:03:34 +0100 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> Message-ID: Jason, like Kevin, thank you very much for opening up to us. It is not every day that someone so close to the issues posts with insight. >From what we see here in India, it is true only Comcast and Verizon are access networks with peering problems. We are able to reach Cox, RCN, Charter, Sonoma Interconnect, other without congestion from AS 6453 "Tata". Please can you explain what it is about your network design or management that causes the choke? Arvinder > So by extension, if you enter an agreement and promise to remain balanced > you can just willfully throw that out and abuse the heck out of it? Where > does it end? Why even bother having peering policies at all then? > > To use an analogy, if you and I agree to buy a car together and agree to > switch off who uses it every other day, can I just say "forget our > agreement – I’m just going to drive the car myself every single day – its > all mine”? > > And as you say, “interestingly enough only Comcast and Verizon are having > this problem” someone else might say “interestingly enough one content > distributor is at the center of all of these issues.” I’m frankly > surprised that no one is stepping back to try to understand what was and > is driving those changes. > > Jason > > On 5/15/14, 1:43 PM, "Nick B" > > wrote: > > Yes, throttling an entire ISP by refusing to upgrade peering is clearly a > way to avoid technically throttling. Interestingly enough only Comcast > and Verizon are having this problem, though I'm sure now that you have set > an example others will follow. > Nick > From arvindersingh at mail2tor.com Thu May 15 19:12:45 2014 From: arvindersingh at mail2tor.com (arvindersingh at mail2tor.com) Date: Thu, 15 May 2014 20:12:45 +0100 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> Message-ID: Jason I think it is important to consider that you are operating your AS 7922 to serve a global Internet. In US, there is not a lot of choke because all the big Internet property - Google, Facebook, Microsoft, Amazon - pay toll to reach Comcast Broadband customer. If they do not pay u, there is not a competitive provider to pay. The routes to Comcast from "peers" are very congested. If u don't pay Comcast, you get sent over throttled Tata link... how is that "open" internet? In my home country, the routes to Comcast are poor bc dominant provider, AS 6453 Tata, is vendor Comcast refuses to upgrade so it can play games. Thank u again for helping provide information, but pls try to keep it accurate. Regards- Arvinder Singh > On 5/15/14, 12:43 PM, "Nick B" wrote: > > >>Yes, you've got "some of the largest Internet companies as customers². >>Because you told them "if you don't pay us, we'll throttle you". Then >>you throttled them. I'm sorry, not a winning argument. >>Nick > > That is categorically untrue, however nice a soundbite it may be. If you > or anyone else truly believes we are throttling someone then I encourage > you to file a formal complaint with the FCC. According to their Open > Internet rules that we are bound to through at least 2018 (IIRC) we may > not discriminate on traffic in that way, so there is a clear rule and a > clear process for complaints. > > Jason > > From arvindersingh at mail2tor.com Thu May 15 19:17:40 2014 From: arvindersingh at mail2tor.com (arvindersingh at mail2tor.com) Date: Thu, 15 May 2014 20:17:40 +0100 Subject: Observations of an Internet Middleman / RIP Network Neutrality In-Reply-To: References: Message-ID: Owen this is interesting I think also...but how do u prove motive? Arvinder >> Yes, you've got "some of the largest Internet companies as customers². >> Because you told them "if you don't pay us, we'll throttle you". Then >> you throttled them. I'm sorry, not a winning argument. >> Nick > > Claims by some large ISPs that this is “untrue” rest on the claim that > they don’t do traffic discrimination. > > While they may not be (and, indeed, are not allowed to) do traffic > discrimination, what is ignored is that refusing to add sufficient peering > capacity is, to the consumer’s perspective (and to the content provider’s > perspective as well) effectively the same thing as throttling. > > I will note that as yet, not one of these providers has claimed that they > did not refuse to increase peering capacity in order to leverage payment, > and, indeed, payment does appear to have been leveraged. > > Owen > > From takashi.tome at gmail.com Thu May 15 19:45:06 2014 From: takashi.tome at gmail.com (takashi tome) Date: Thu, 15 May 2014 16:45:06 -0300 Subject: [nanog] GoDaddy Message-ID: Hi all. Does anyone know whether GoDaddy is alive/down? thanks Takashi From ktims at stargate.ca Thu May 15 20:17:22 2014 From: ktims at stargate.ca (Keenan Tims) Date: Thu, 15 May 2014 20:17:22 +0000 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: References: <201405151905.s4FJ5w4s001864@aurora.sol.net>, Message-ID: <344c9be20b124b9bbf35ea9e55476a52@STCOEX01.stargate.local> Their existing agreements notwithstanding, I believe the problem many have with Comcast's balanced ratio requirement is that they have 10s of millions of customers, all or almost all of whom are sold "unbalanced" services. In addition the majority of their customers are end users, who are also going to bias toward heavily inbound patterns (which is one of the reasons for the asymmetric connections in the first place). As primarily an eyeball network with a token (8000 quoted) number of transit customers it does not seem reasonable for them to expect balanced ratios on peering links. They are, effectively by their own choice of market, always going to have a heavily inbound traffic ratio. It seems to me that requiring anything else is basically a way to give the finger to a potential peer while claiming to be neutral. I find it hard to believe that Comcast would be running many balanced links (peering or transit) at all, except perhaps to other consumer ISPs. In today's environment there are inevitably going to be heavily inbound and heavily outbound networks. Content networks don't have any problem with SFI despite their ratio. Eyeball networks do. Both are in the position they are because of the line of business they have respectively chosen. But the eyeball network is the only one that is explicitly and exclusively paid *to carry traffic*. IMO if the content network is willing to bring their content, for free, to the eyeball network's edge, this is to the benefit of the eyeball network more than content, in the absence of other "factors". In this case that factor appears to me to be "ad-hoc oligopoly". If customers had options and an easy path to switch, they would not tolerate this behaviour when they can switch to a competitor who provides good service for the bits they request. Content would gain a lot of leverage in this situation as they could help "educate" customers on alternatives, automatically and without paying a support agent. Of course we should be careful not to let the opposite situation occur either... Keenan ________________________________________ From: NANOG on behalf of Scott Helms Sent: May 15, 2014 12:54 PM To: Joe Greco Cc: nanog at nanog.org Subject: Re: Observations of an Internet Middleman (Level3) (was: RIP On Thu, May 15, 2014 at 3:05 PM, Joe Greco wrote: > > So by extension, if you enter an agreement and promise to remain > balanced y= > > ou can just willfully throw that out and abuse the heck out of it? Where > do= > > es it end? Why even bother having peering policies at all then? > > It doesn't strike you as a ridiculous promise to extract from someone? > You could certainly say its ridiculous, but it is (and has been) the basis for almost all peering arrangements in North America for several decades in my personal experience. I believe that the practice came from the telco world when large telephone companies would exchange traffic without billing each other so long as the traffic was relatively balanced. You can imagine AT&T and Sprint exchange toll traffic and so long as things we're fairly close there wasn't a big imbalance of traffic to worry the financial folks over and thus having to do exact accounting on each minute, which was technically challenging 30 years ago. "Hi I'm an Internet company. I don't actually know what the next big > thing next year will be but I promise that I won't host it on my network > and cause our traffic to become lopsided." > > Wow. Is that what you're saying? > That's not what happened. What happened is that Netflix went to Level 3 who already had a peering arrangement with Comcast which was built around normal (roughly) balanced peering. It had been in place for years before Netflix signed with Level 3 and worked, and was contracted this way, around relatively balanced traffic. Once Netflix started sending most of their traffic destined to Comcast end user through Level 3 things got out of balance. Netflix still has a contract with Cogent (I believe that is the correct one) or other provider that had previously been handling the bulk of the Comcast directed traffic, but the Level 3 connection was cheaper for Netflix. If anyone actually acted in bad faith it was, IMO, Level 3. > > > To use an analogy, if you and I agree to buy a car together and agree to > sw= > > itch off who uses it every other day, can I just say "forget our > agreement = > > =96 I=92m just going to drive the car myself every single day =96 its > all m= > > ine=94? > > Seems like a poor analogy since I'm pretty sure both parties on a peering > can use the port at the same time. > His point was you can't simply change a contract without having both parties involved. Level 3 tried to do just that. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] > then I > won't contact you again." - Direct Marketing Ass'n position on e-mail > spam(CNN) > With 24 million small businesses in the US alone, that's way too many > apples. > From mpetach at netflight.com Fri May 16 02:24:18 2014 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 15 May 2014 19:24:18 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: <20140515042912.GC7991@slab-wks-04.slabnet.com> References: <536BBC62.4070805@KingsMountain.com> <20140515042912.GC7991@slab-wks-04.slabnet.com> Message-ID: On Wed, May 14, 2014 at 9:29 PM, Hugo Slabbert wrote: > So, at the end of the week, I *had* been paying $10/mb to >> send traffic through transit to reach the whole rest of the >> internet. Now, I'm paying $5+$4+$4+$5+$2, or $30, and >> I don't have a full set of routes, so I've still got to keep >> paying the transit provider as well at $10. >> > > I would like to agree with you as I'm not a fan (by any stretch) of this > type of paid peering to enter access networks, but your formula's off. It > supposes that the same bit is traversing multiple paid peering links. The > formula (if we ignore commits for now) should be something more like: > > C(T) = R(t) * M(t) + R(1) * M(1) ... + R(n) * M(n) > > Where: > C(T) = total cost > R(t) = transit $/mbit rate > M(t) = transit mbps > R(1) = paid peering agreement #1 $/mbps rate > M(1) = paid peering agreement #1 mbps > R(n) = paid peering agreement #n $/mbps rate > M(n) = paid peering agreement #n mbps > > For your $10/mb transit example, suppose we had 1 Gbps of traffic and so > our transit cost would be $10,000/month. We take your mixed bag of paid > peering and say we give each of those 5 paid peers 100 mbps: > > C(T) = 500 * 10 + 100 * 5 + 100 * 4 + 100 * 4 + 100 * 5 + 100 * 2 > C(T) = $7,000/month > > So, yes, as long as R(n) is lower than R(t), your overall cost should be > lower, since you're moving some number of mbps from your higher priced > transit link to one or more (slightly) cheaper paid peering links. > > Now, as I mentioned, this ignores commits, so it's really more like: > This is exactly where it gets ugly. Pretty much everyone that wants money, also wants minimum commitments in order to keep the link. > > C(T) = ( c(t) + R(t) * M(t) ) + ( c(n) + R(n) * M(n) ) > Where: > c(t) = transit commit $ > M(t) = transit mbps over commit > c(n) = paid peering agreement #n commit $...I've not personally had to > deal with paid peering so I don't know if commit rates are at all common on > them, but you can sub or add in other fixed costs e.g. transport to reach > the paid peering exchange point > M(n) = paid peering agreement #n mbps over commit > > So, it starts to get murkier. E.g. if you're not over your transit commit > and now you're shifting traffic off of your transit onto paid peering, you > may want to lower your transit commits. > You may *want* to lower your transit commits; doesn't mean the transit provider will go along happily with that; they may require turning off some ports, and raising the per-mbit price, throwing your calculations off, as now you're having to haul traffic to centralized hubs to hand off, because you had to shut down transit ports in smaller cities based on your reduced commit level, which can also cause performance issues for users. In the worst case, you get stuck still paying for your transit port (as your need to reach the rest of the internet hasn't gone away), as *well* as the commits for all the individual provider ports. > This also does not account for other potential costs were this type of > arrangement to become commonplace, e.g. the additional burden on content > providers of maintaining direct business relationships with any access > network that would require paid peering for preferential/decent quality. > > Again: I'm not a fan of some of the possible abuses or strong-arm tactics > of this type of arrangement between eyeball networks and content providers > (e.g. running transit or existing peering links hot to push content > providers to paid peering to reach the eyeball customers), but the math is > not quite so dire as it was made out to be. > > -- > Hugo > The math *may* not be as dire; but there's no guarantee it won't be, which is the big challenge; working through the scenarios takes multiple iterations, as reducing your transit volumes changes the commit size and pricing on those ports, and may change the count of ports you can maintain; and splitting your traffic up among separate individual links to every access network uses up limited port counts available on routers. There's a lot of factors involved that all working together help provide a strong incentive for transit providers to continue to exist in the ecosystem, which was the main point I was trying to make; while it might be easy at first blush to say "gosh, why doesn't everyone just pay the access networks, bypass the transit providers, and life will be rosy and happy", the reality is that model largely doesn't work out well, as both your math and mine highlight, to differing degrees. But yes, the actual calculations involved are far beyond the realm of a simple NANOG post to completely enumerate. :/ Thanks! Matt From eddie at aquino.se Fri May 16 03:00:10 2014 From: eddie at aquino.se (Eddie Aquino) Date: Thu, 15 May 2014 20:00:10 -0700 Subject: [nanog] GoDaddy In-Reply-To: References: Message-ID: What issues are you experiencing? I have a site that has been intermittently reachable since Monday. I don't have many details as I just took over but I'm almost certain it's GoDaddy hosted. It is not a secure site. However, sometimes https works. Eddie Network Engineer On May 15, 2014 7:44 PM, "takashi tome" wrote: > Hi all. Does anyone know whether GoDaddy is alive/down? > > thanks > > Takashi > From drc at virtualized.org Fri May 16 03:22:02 2014 From: drc at virtualized.org (David Conrad) Date: Thu, 15 May 2014 20:22:02 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> Message-ID: <77CE61AE-0588-4C1E-80BC-5144200A40B1@virtualized.org> Hi, On May 15, 2014, at 12:12 PM, arvindersingh at mail2tor.com wrote: > Jason I think it is important to consider that you are operating your AS > 7922 to serve a global Internet. Actually, I suspect Jason is operating 'his' AS to serve Comcast customers and/or shareholders... 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 frnkblk at iname.com Fri May 16 04:48:55 2014 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 15 May 2014 23:48:55 -0500 Subject: FTTH ONTs and routers In-Reply-To: References: <5374F538.5010108@vaxination.ca> Message-ID: <004c01cf70c2$24af5370$6e0dfa50$@iname.com> Calix's indoor ONT (836GE) come with RG functionality by default: http://www.calix.com/systems/p-series/calix_residential_services_gateways.html but they also have a software load for their 700GE-series ONTs: http://www.calix.com/news/press_releases/press_release_20130611.html Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Shawn L Sent: Thursday, May 15, 2014 1:12 PM To: nanog Subject: Re: FTTH ONTs and routers Calix makes a number of ONTs some with residential gateways, some that are just bridges On Thu, May 15, 2014 at 1:24 PM, Aled Morris wrote: > I notice Cisco's new ME4600 ONT's come in two flavors, one (the > "Residential GateWay") with all the bells and whistles that you'd expect in > an all-in-one home router (voice ports, small ethernet switch, wifi access > point) and another (the "Single Family Unit") that looks a lot more basic > and is likely to be deployed as a bridge. > > > http://www.cisco.com/c/en/us/products/collateral/switches/me-4600-series-multiservice-optical-access-platform/datasheet-c78-730446.html > > Aled > > > On 15 May 2014 18:11, Jean-Francois Mezei >wrote: > > > > > It had been my impression that ONTs, like most other consumer modems, > > came with built-in router capabilities (along with ATA for voice). > > > > The assertion that ONTs have built-in routing capabilities has been > > challenged. > > > > Can anyone confirm whether ONTs generally have routing (aka: home router > > that does the PPPoE or DHCP and then NAT for home) capabilities? > > > > Are there examples where a telco has deployed ONTs with the router > > built-in and enabled ? Or would almost all FTTH deployments be made with > > any routing disabled and the ONT acting as a pure ethernet bridge ? > > > > > > (I appreciate your help on this as I am time constrained to do research). > > > > > From mpetach at netflight.com Fri May 16 05:26:02 2014 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 15 May 2014 22:26:02 -0700 Subject: A simple proposal Message-ID: There's been a whole lot of chatter recently about whether or not it's sensible to require balanced peering ratios when selling heavily unbalanced services to customers. There's a very simple solution, it seems. Just have every website, every streaming service, every bit of consumable internet data have built-in reciprocity. You want to stream a movie? No problem; the video player opens up a second data port back to a server next to the streaming box; its only purpose is to accept a socket, and send all bits received on it to /dev/null. The video player sends back an equivalent stream of data to what is being received in. The server receiving the upstream data stream checks the bitrate coming into it from the player, and communicates back to the video streaming box every few minutes to lower the outbound bitrate going to the player to match what the inbound bitrate coming from the client is. That way, traffic volumes stay nicely balanced, and everyone is happy. For extra credit, and to deal with multiple layers of NAT in the v4 world, you could even piggyback on the same stream, though that would take just a bit more work. Mobile apps could be programmed the same way; you download a certain amount of data, an equivalent volume of data is sent back upstream to balance it out, and preserve the holy ratio. Even web pages could use javascript footers to send back upstream an equivalent amount of data to what was downloaded. Once and for all, we could put an end to the ceaseless bickering about ratios, as everyone, everywhere would be forced into glorious unity, a perfect 1:1 ratio wherever the eye should look. As far as I can tell, this should solve *everyone's* concerns from all sides, all in one simple effort. Matt From jfmezei_nanog at vaxination.ca Fri May 16 06:19:39 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 16 May 2014 02:19:39 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <344c9be20b124b9bbf35ea9e55476a52@STCOEX01.stargate.local> References: <201405151905.s4FJ5w4s001864@aurora.sol.net>, <344c9be20b124b9bbf35ea9e55476a52@STCOEX01.stargate.local> Message-ID: <5375ADFB.3000303@vaxination.ca> On 14-05-15 16:17, Keenan Tims wrote: > As primarily an eyeball network with a token (8000 quoted) number of transit customers it does not seem reasonable for them to expect balanced ratios on peering links. Pardon my ignorance here, but isn't there a massive difference between settlement-free peering between large transit providers at the core which happens with balanced traffic, and some free peering at local exchanges at the edge where there is no expectation of balanced traffic, just an oppportunity to exchange traffic without using transit capacity. (isn't that how CDN nodes in a exchange works ? Lets ISPs connect to it and bypass transit links to save money ? Seems to me like the word "peering" shouldn't have been used to denote relationships at the core between the big guys if it is also used at the edge for a fairly different purpose. From mark.tinka at seacom.mu Fri May 16 07:11:12 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 16 May 2014 09:11:12 +0200 Subject: FTTH ONTs and routers In-Reply-To: <5374F538.5010108@vaxination.ca> References: <5374F538.5010108@vaxination.ca> Message-ID: <201405160911.12591.mark.tinka@seacom.mu> On Thursday, May 15, 2014 07:11:20 PM Jean-Francois Mezei wrote: > Can anyone confirm whether ONTs generally have routing > (aka: home router that does the PPPoE or DHCP and then > NAT for home) capabilities? I know of a well-known vendor coming out with a new OLT that supports both typical GPON access, as well as Active-E access, and with IP routing capabilities. It hasn't yet hit the shelves, but for anyone with an ounce of interest in FTTH, you will hear about it soon. So yes, in the past it has been hit & miss, but I think there are some vendors who are now seriously pushing a box that is multi-lingual, i.e., supports GPON, Active-E, IP and MPLS. 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 Fri May 16 07:16:23 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 16 May 2014 09:16:23 +0200 Subject: FTTH ONTs and routers In-Reply-To: References: <5374F538.5010108@vaxination.ca> Message-ID: <201405160916.23417.mark.tinka@seacom.mu> On Thursday, May 15, 2014 07:24:33 PM Aled Morris wrote: > I notice Cisco's new ME4600 ONT's come in two flavors, > one (the "Residential GateWay") with all the bells and > whistles that you'd expect in an all-in-one home router > (voice ports, small ethernet switch, wifi access point) > and another (the "Single Family Unit") that looks a lot > more basic and is likely to be deployed as a bridge. Ah, so looks like it's been announced now - that is the breed I was referring to; the ME4600 OLT. 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 Fri May 16 07:53:11 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 16 May 2014 09:53:11 +0200 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <201405151905.s4FJ5w4s001864@aurora.sol.net> References: <201405151905.s4FJ5w4s001864@aurora.sol.net> Message-ID: <201405160953.14953.mark.tinka@seacom.mu> On Thursday, May 15, 2014 09:05:57 PM Joe Greco wrote: > "Hi I'm an Internet company. I don't actually know what > the next big thing next year will be but I promise that > I won't host it on my network and cause our traffic to > become lopsided." You mean like almost every other mobile carrier the world over, and their data-capped services? Want to guess how many mobile carrier executives converge around a table on a daily basis to discuss how to stem growth in demand for traffic by their customers? 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 jnanog at gmail.com Fri May 16 10:25:27 2014 From: jnanog at gmail.com (Rick Astley) Date: Fri, 16 May 2014 06:25:27 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> Message-ID: >What you're missing is that the transit provider is selling full routes. The access network is selling paid peering, which is a tiny fraction of the routes. Considering they charge on a $per/mb basis I don't think its just routes they are selling. It looks a lot like they are selling bits. From the perspective of a content provider it looks like they swivel chair most those bits to access networks for delivery. That "tiny fraction of routes" on the access networks make up most delivered content. In total network size the access networks are larger although less spread out globally. Being globally connected is useful but it doesn't make a legitimate case for having exclusive rights to charge for content being delivered in North America. If you are planning to serve large scale data over oceanic fiber it's a strong selling point but that's not the case here. If instead of $per/mb traffic delivery you want to get into arbitrary justifications access networks have more directly assigned IP addresses than transit networks. I'm not making the case that a middle man should never be used, I'm making the case that they shouldn't be used where there isn't a requirement for one. Bypassing the middleman is generally better for everyone but the middle man. >So, at the end of the week, I *had* been paying $10/mb to send traffic through transit to reach the whole rest of the internet. Now, I'm paying $5+$4+$4+$5+$2, or $30, and I don't have a full set of routes, so I've still got to keep paying the transit provider as well at $10. If this is the math you are using to justify your stance it's probably worth reconsidering. You ignore that each of those if sent through transit would have been $10 so the cost of $5, $4, and $2/Mb represent a savings of $5, $6,and $8. Why would you add them? Sure there are factors you have to evaluate like putting yourself under a minimum commit with $transit or if the amount of traffic is worth peering over but you would generally have to make those evaluations for peering anyway. The real difference is the volume of traffic needed before a $2/mb savings is worth peering directly for is higher than if the savings were the full $10 but that doesn't mean its never worth it. There is a difference between saying "I did the math and transit remains the cheaper option" and saying "Paid peering would save us both money and improve performance at the same time but we refuse to do it anyway on principal". The concept of fair gets brought up a lot when talking about the ability of a startup to come in to compete against bigger players in the content space but really what do you think the impact is if the largest established content providers peer freely and smaller newcomers only have paid options available for traffic? Some other things I also want to get to: >On Vi's analogy vs Amazon prime One major different I think people overlook is overusing Amazon prime would mean buying too many things from Amazon. Even when you purchase through companies selling through Amazon they get a cut of the sale and some of that I assume gets applied to covering any additional shipping costs not covered by Prime. If Internet traffic used the same model would ISP's receive a portion of proceeds for ad revenue on places like Youtube or a percentage of Netflix subscription fees? I'm not making the case that thats the model that should be used I'm only pointing out that analogies are best to break things down into simple terms for people but have diminishing returns in usefulness when getting into details. The other problem with Vi's analogy is the shipping company delivers to the driveway of the customer where a more real life scenario would be something closer to Amazon having a distribution center in that city, and both Comcast and FedEx are already both sitting idle in the parking lot. Amazon pays FedEx to give the package to Comcast in the next parking space, who then drives it to the customers house. Comcast says to Netflix, since I am the one driving this from the parking lot to the customers house, why not just pay me instead of paying FedEx more money to just put it on my truck? Amazon says, but FedEx will deliver the package to France if I tell them to. Comcast says, but you don't even serve france out of this distribution center, and I am not asking to be charged for all packages, only the ones I deliver instead of FedEx. Amazon says, you are right, we have technology to give your packages directly to you and stuff going to France to Fedex, and it would be best for both of us to do it, but unless you'll deliver my packages for free I'm going to keep paying FedEx to just keep loading them on your truck. Comcast says have at it, there are 5 trucks for FedEx to load freely now but if you need more you have to compromise with us on a deal that works better for both of us. Amazon says, when we are done with you in the media we won't need to compromise. >Government regulation of interconnects I agree with Owen Delong on this who said "That set of regulations would be utterly impossible to meaningfully enforce because so much of it depends on subjective evaluation." and gave some reasons why. I also think that in order for the government to meaningfully review all interconnect relationships between companies there would be more legal scrutiny within companies needing to justify the process, forms would need to be filed with government for review, some reviewing entity would need to perform a traffic study potentially needing access to netflow data, and "tier 1" if it would continue to exist would likely require expensive certification to come with the responsibility and there would need to be some process for new companies seeking "tier 1" status to apply for it. We would be left with a pile of costs, nothing beneficial gained from it, and an advantage to companies with more lawyers than engineers. >Broadband is too expensive in the US compared to other places I have seen this repeated so many times that I assume it's true but I have never seen anything objective as to why. I can tell you if you look at population density by country the US is 182nd in the world and the average broadband speed (based on OOKLA: http://www.netindex.com/download/allcountries/) is 30th in the world. South Korea that is well known for its fast broadband speeds has a density of 505/km vs the US at 32/km. We have about 1/15 of the population density and about 1/2 the average broadband speed. Hong Kong, Singapore, Netherlands, Japan, Macau etc. all have more than 10x the population density in the US so definitely not all countries with fast broadband make for a fair comparison and there are likely fewer that do. The UK is only beating the US by 2Mbps but has a population density of 262/km. So while its a fair assessment that broadband in the US is very bias to ignore some of the other factors involved. Another mistake I see people keep making is in comparing the cost of broadband in the US in $USD to other countries around the world. The cost of broadband in Estonia is only about $30/month. OMG, I can't believe broadband is cheaper in Estonia! What people ignore is everything is cheaper in Estonia, the average household income in Estonia is $14k vs $55k here. By that measure broadband is more expensive for families there than it is in the US. This is another point people repeat without bothering to qualify. This would be like my grandfather comparing the costs of a candy bar from back when he was a kid to today but ignoring inflation. >Broadband companies are making money hand over fist This may be true but I have honestly not attempted to index a bunch of major companies and compare their profit vs revenue so see if broadband companies are really on the top of the pile as people making this point imply. I have to confess to being skeptic that the people making the claim have done this either. >ad hominem attacks Inevitable but no, I don't have financial gain in any of this. My stance is essentially that if ISP's are forced to choose between higher prices, metered billing, or adopting paid peering then paid peering is the best solution of those 3 and pushing for legislation prohibiting it only serves to take what I think is the best solution off the table. Especially in cases where content providers are monetizing a service sold over the top I think resistance to this option is a bit stubborn and I'd like to see the industry solve the dispute without the government taking the opportunity to land grab for expanded power over the Internet. If they pick just ratcheting up pricing for unlimited plans in auto pilot as costs rise it will only harm the "Broadband is too expensive in the US compared to other places" numbers and I think people have been pretty clear in their objection to metered billing. Metered billing would also probably hurt content providers more than paid peering would so it's the worst option all around. I read complaints about the way things are handled all the time and complaining is easy but proposing better solutions is harder. On Wed, May 14, 2014 at 4:11 AM, Matthew Petach wrote: > > > > On Sat, May 10, 2014 at 8:04 AM, Rick Astley wrote: > >> [...] >> >> The reality is an increasingly directly peered Internet doesn't sit well >> if >> you are in the business of being the middle man. Now if you will, why do >> transit companies themselves charge content companies to deliver bits? How >> is it fair to be in the business of charging companies to receive their >> bits and hand them to a settlement free peer on the hook to deliver them, >> but not fair for content to just bypass the transit company and enter a >> paid peering agreement with the company delivering the bits? In this case >> paid peering is mutually beneficial to both companies involved and is >> typically cheaper for the content company than it would cost to send that >> traffic over transit. >> > > What you're missing is that the transit provider is > selling full routes. The access network is selling > paid peering, which is a tiny fraction of the routes. > If I pay transit provider X $10/mb (i know, not realistic, > but it makes my math work) to reach the entire internet, > it might seem reasonable to pay access network C $5/mb > to hand traffic to them, and bypass the transit provider, > avoiding potentially congested links. > > But then access network A decides they want to cut out > the middleman as well--so they do the same thing, run > their ports to transit provider X hot; to avoid that, I can > pay the cheap price of $4/mb to reach them. > > Now access networks F and D want to do the same thing; > their prices for their routes are $4 and $5/mb, respectively. > > Finally, little access provider T wants in at $2/mb for their > routes. > > So, at the end of the week, I *had* been paying $10/mb to > send traffic through transit to reach the whole rest of the > internet. Now, I'm paying $5+$4+$4+$5+$2, or $30, and > I don't have a full set of routes, so I've still got to keep > paying the transit provider as well at $10. Depending on > port counts, locations, and commit volumes, your "typically > cheaper for the content company than it would cost to send > that traffic over transit" has flown completely out the window. > It could even end up being many times more expensive to > handle the traffic that way. > > In order for the costs to work out, you'd really need > to apply a formula along the lines of > C(n) <= T(n) * C(t) > where > T(n) =fraction of traffic volume destined for access network X > C(t)=cost of transit (ie, full routes, reachability to the entire internet) > C(n)=cost of paid peering to access network X > > So, if you're an access network and want to charge > for paid peering, and you represent 1/20th of my > traffic, there's no reason for me to pay more than > 1/20th of my transit cost for your routes; otherwise, > it's more cost effective for me as a business to > continue to pay a transit provider. > > I'm constantly amazed at how access networks > think they can charge 2/3 the price of full transit > for just their routes when they represent less than > 1/10th of the overall traffic volume. The math just > doesn't work out. It's nothing about being tier 1, or > bigger than someone else; it's just math, pure and > simple. > > Matt > (currently not being paid by anyone for my time > or thoughts, so take what I'm saying as purely > my own thoughts on the matter, nothing more) > > > From takashi.tome at gmail.com Fri May 16 11:50:54 2014 From: takashi.tome at gmail.com (takashi tome) Date: Fri, 16 May 2014 08:50:54 -0300 Subject: [nanog] GoDaddy In-Reply-To: References: Message-ID: Thanks, Eddie. Yes, I also have been experiencing intermittency this week. But yesterday/today things went worse: I simply can not reach neither some sites hosted there, neither GD's admin area. Neither their call centre... :-( Takashi Tome network dummy 2014-05-16 0:00 GMT-03:00 Eddie Aquino : > What issues are you experiencing? I have a site that has been > intermittently reachable since Monday. I don't have many details as I just > took over but I'm almost certain it's GoDaddy hosted. It is not a secure > site. However, sometimes https works. > > Eddie > Network Engineer > On May 15, 2014 7:44 PM, "takashi tome" wrote: > >> Hi all. Does anyone know whether GoDaddy is alive/down? >> >> thanks >> >> Takashi >> > From Jason_Livingood at cable.comcast.com Fri May 16 12:08:38 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Fri, 16 May 2014 12:08:38 +0000 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <7d1719ae1b00cd964f2140e92ffb20e5.squirrel@mail2tor2zyjdctd.onion> References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> <5374E013.1050708@sberkman.net> <8AFC1EC8-5F2E-4645-B57C-A147FC56B390@cable.comcast.com> <696D5986-AB28-4793-976D-FFE542AEB68D@cable.comcast.com> <7d1719ae1b00cd964f2140e92ffb20e5.squirrel@mail2tor2zyjdctd.onion> Message-ID: On 5/15/14, 12:49 PM, "arvindersingh at mail2tor.com" wrote: >I have two issues with the comments: > >2. You mention that all packets treated equally - no games. Why does >AS7922 assign the speed test different DSCP from regular internet >connection? I have no idea what you are talking about. Our Internet traffic, including to speedtest web sites, is all best effort class data. Do you have more specific information? Jason From vinny at abellohome.net Fri May 16 11:56:25 2014 From: vinny at abellohome.net (Vinny Abello) Date: Fri, 16 May 2014 07:56:25 -0400 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> <5374E013.1050708@sberkman.net> <8AFC1EC8-5F2E-4645-B57C-A147FC56B390@cable.comcast.com> <696D5986-AB28-4793-976D-FFE542AEB68D@cable.comcast.com> <7d1719ae1b00cd964f2140e92ffb20e5.squirrel@mail2tor2zyjdctd.onion> Message-ID: On , Livingood, Jason wrote: > On 5/15/14, 12:49 PM, "arvindersingh at mail2tor.com" > wrote: > > >> I have two issues with the comments: >> >> 2. You mention that all packets treated equally - no games. Why does >> AS7922 assign the speed test different DSCP from regular internet >> connection? > > I have no idea what you are talking about. Our Internet traffic, > including > to speedtest web sites, is all best effort class data. Do you have more > specific information? > > Jason I think he's questioning why packets from speedtest.comcast.net have CS1 if everything is supposedly equal, and what that is used for. A quick Wireshark shows that to be true right now running to your Plainfield, NJ speedtest site, and my network peers directly with Comcast. I'm kind of curious too. What is the purpose of this? Is it the traditional purpose of CS1 to be less than best effort or something else? If this is the case it seems Comcast would be purposely putting themselves at a disadvantage in speed tests when congestion is involved... or is this possibly on purpose to make peering problems look even worse during congestion? -Vinny From owen at delong.com Fri May 16 13:54:33 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 16 May 2014 06:54:33 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <5375ADFB.3000303@vaxination.ca> References: <201405151905.s4FJ5w4s001864@aurora.sol.net>, <344c9be20b124b9bbf35ea9e55476a52@STCOEX01.stargate.local> <5375ADFB.3000303@vaxination.ca> Message-ID: <1ED86D5A-748F-4AD2-A40D-195B148797CE@delong.com> All the talk about ratios is a red herring… The real issue boils down to this: 1. The access (eyeball) networks don’t want to bear the cost of delivering what they promised to their customers. 2. This is because when they built their business models, they didn’t expect their customers to use nearly as much of their promised bandwidth as they are now using. Most of the models were constructed around the idea that a customer receiving, say 27mbps down/7mbps up would use all of that bandwidth in short bursts and mostly use less than a megabit. 3. New services have been developed (streaming video, et al.) which have created an increasing demand from customers for more of the bandwidth they were sold. 4. Instead of raising the prices to the access network customers or accepting that the lavish profits that they eyeball networks had been pocketing were no more, the access networks are trying to slough off the costs of delivering that higher fraction of what they sold onto someone else. 5. The content providers looked like an easy target with the advantage that: A. Some of them appear to have deep pockets. B. They are the competition for many of the access network’s other lines of business, so increasing their costs helps make them less competitive. C. Consumers are emotional about price increases. Content providers look at it as a business problem and perform a mathematical analysis. If their customer satisfaction impact costs more than paying the extortion from the access networks, they’ll pay it. In reality, if the $ACCESS_PROVIDERS wanted to satisfy their customers, they’d be aggressively seeking to peer with content providers in as many locations as possible. They might (reasonably) require content providers to build out to additional locations to keep their long-haul costs down (It’s reasonable, IMHO, for a content provider not to want to carry multiple gigabits of traffic from a content provider clear across the country for free. If $CONTENT_PROVIDER wants to access California customers of $ACCESS_PROVIDER, then it’s reasonable for $ACCESS_PROVIDER to insist that $CONTENT_PROVIDER peer in California for delivering those bits.) Neither side of this issue has completely clean hands. Both have been trying to take as much of the money on the table for themselves with limited regard for serving the consumer. The Access Networks have done a far worse job of serving the consumer than the content providers and that’s a big part of what is driving the current backlash. As a general rule, access customers don’t select the provider they love the most, they select the one they think sucks the least. I think the recent FCC NPRM is a bit optimistic in that it expects the $ACCESS_PROVIDERS to act in good faith. If they do, it will likely turn out to be a limited victory for the $ACCESS_PROVIDERS. However, I don’t expect the $ACCESS_PROVIDERS to live within that limited victory. Assuming the NRPM becomes rule and then withstands the likely legal challenges, I expect they will, as usual, play in the gray areas of the ruling as much as they think they legally can and push the edges as far as possible to try and extort every dollar they can from $CONTENT_PROVIDERS with this so-called fast-lane (which we all know is just preferential peering and/or QoS[1] tuning). I suspect they will likely push this far enough that over the next several years, things will get progressively worse until the FCC finally decides that they have to move from section 706 to Title II. OTOH, if I’m wrong and the $ACCESS_PROVIDERS suddenly start behaving like civilized companies, develop a sudden concern for their customers’ experiences, and start unimaginably acting in good faith, the proposed rule wouldn’t be so bad for $CONTENT_PROVIDERS, $CONSUMERS, or $ACCESS_PROVIDERS. Of course, you can already see the $ACCESS_PROVIDERS laying the groundwork to try and mount a legal challenge against the FCC’s authority to use rule 706. Sadly, some of this groundwork is being laid by FCC commissioners. Said commissioners clearly have no interest in representing the people’s interest and are strictly there as mouth-pieces for some of the big players in the industry. Owen [1] QoS — A deceptive name if ever there was one. QoS is not about Quality of Service, it’s about screwing over network users by choice rather than by chance when you haven’t built an adequate network. From morrowc.lists at gmail.com Fri May 16 14:17:43 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 16 May 2014 10:17:43 -0400 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> <5374E013.1050708@sberkman.net> <8AFC1EC8-5F2E-4645-B57C-A147FC56B390@cable.comcast.com> <696D5986-AB28-4793-976D-FFE542AEB68D@cable.comcast.com> <7d1719ae1b00cd964f2140e92ffb20e5.squirrel@mail2tor2zyjdctd.onion> Message-ID: On Fri, May 16, 2014 at 7:56 AM, Vinny Abello wrote: > I think he's questioning why packets from speedtest.comcast.net have CS1 if > everything is supposedly equal, and what that is used for. A quick Wireshark > shows that to be true right now running to your Plainfield, NJ speedtest > site, and my network peers directly with Comcast. are you measuring inside the (for this) comcast network or after your cable-modem? I recall that the cable-modem(s) often (by docsis config) impose some qos markings on the lan-side of the connection. I think they can do the same on the WAN side for traffic leaving your site to the tubes... but you probably can't measure that as easily as with wireshark on your pc. -chris (also, is there some other equipment between your wiresharker and the cable-modem? could that equipment be re-marking/marking as well?) From owen at delong.com Fri May 16 14:19:45 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 16 May 2014 07:19:45 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here... In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> Message-ID: <5CC19BCA-35D3-4AF4-94EC-418E935B5164@delong.com> On May 16, 2014, at 3:25 AM, Rick Astley wrote: >> Broadband is too expensive in the US compared to other places > > I have seen this repeated so many times that I assume it's true but I have > never seen anything objective as to why. I can tell you if you look at > population density by country the US is 182nd in the world and the average > broadband speed (based on OOKLA: > http://www.netindex.com/download/allcountries/) is 30th in the world. South > Korea that is well known for its fast broadband speeds has a density of > 505/km vs the US at 32/km. We have about 1/15 of the population density and > about 1/2 the average broadband speed. Hong Kong, Singapore, Netherlands, > Japan, Macau etc. all have more than 10x the population density in the US > so definitely not all countries with fast broadband make for a fair > comparison and there are likely fewer that do. The UK is only beating the > US by 2Mbps but has a population density of 262/km. > > So while its a fair assessment that broadband in the US is very bias to > ignore some of the other factors involved. Another mistake I see people > keep making is in comparing the cost of broadband in the US in $USD to > other countries around the world. The cost of broadband in Estonia is only > about $30/month. OMG, I can't believe broadband is cheaper in Estonia! What > people ignore is everything is cheaper in Estonia, the average household > income in Estonia is $14k vs $55k here. By that measure broadband is more > expensive for families there than it is in the US. This is another point > people repeat without bothering to qualify. This would be like my > grandfather comparing the costs of a candy bar from back when he was a kid > to today but ignoring inflation. I might be willing to accept this argument if it weren’t for the fact that rural locations in the US are far more likely to have FTTH than higher density areas because the whole USF thing has inverted the priorities. I live in the largest city in the bay area, yet there is only one facilities based provider in my area that can deliver 2mbps or more and that’s over HFC. Twisted pair is abysmal and there is no fiber. The situation is not significantly better in the densest city in the bay area, either. South Korea averages 4x US Speed for an average $28.50/month. US averages 1x US Speed for an average $45.50/month. (http://edition.cnn.com/2010/TECH/03/31/broadband.south.korea/) Korean average annual wage: $36,757 @ 21% tax = $29,038 take-home. US Average annual wage: $55,048 @ 29.6% tax = $38,753 take-home. (http://en.wikipedia.org/wiki/List_of_countries_by_average_wage) So that says KR take-home wage = ~75% of US wage. 75% of $45.50 is $34.125 So 4x speed is still approximately $5 cheaper per month in KR than in the US. Owen From Jason_Livingood at cable.comcast.com Fri May 16 14:58:57 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Fri, 16 May 2014 14:58:57 +0000 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> <5374E013.1050708@sberkman.net> <8AFC1EC8-5F2E-4645-B57C-A147FC56B390@cable.comcast.com> <696D5986-AB28-4793-976D-FFE542AEB68D@cable.comcast.com> <7d1719ae1b00cd964f2140e92ffb20e5.squirrel@mail2tor2zyjdctd.onion> Message-ID: On 5/16/14, 7:56 AM, "Vinny Abello" wrote: >I think he's questioning why packets from speedtest.comcast.net have CS1 >if everything is supposedly equal, and what that is used for. A quick >Wireshark shows that to be true right now running to your Plainfield, NJ >speedtest site, and my network peers directly with Comcast. > >I'm kind of curious too. What is the purpose of this? Is it the >traditional purpose of CS1 to be less than best effort or something >else? If this is the case it seems Comcast would be purposely putting >themselves at a disadvantage in speed tests when congestion is >involved... or is this possibly on purpose to make peering problems look >even worse during congestion? Ah! That makes sense now. CS1 is used internally to mark best effort Internet traffic. This has often caused confusion when folks see our markings. If folks want to send me any data off-list that you think merits further investigation, let me know (never know if something someplace is an honest config error). Jason From mark.tinka at seacom.mu Fri May 16 15:02:00 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 16 May 2014 17:02:00 +0200 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <1ED86D5A-748F-4AD2-A40D-195B148797CE@delong.com> References: <5375ADFB.3000303@vaxination.ca> <1ED86D5A-748F-4AD2-A40D-195B148797CE@delong.com> Message-ID: <201405161702.03926.mark.tinka@seacom.mu> On Friday, May 16, 2014 03:54:33 PM Owen DeLong wrote: > customers. 2. This is because when they built their > business models, they didn’t expect their customers to > use nearly as much of their promised bandwidth as they > are now using. Most of the models were constructed > around the idea that a customer receiving, say 27mbps > down/7mbps up would use all of that bandwidth in short > bursts and mostly use less than a megabit. And in general, models have assumed, for a long time, that customer demand patterns are largely asymmetric. While that is true a lot of the time (especially for eyeball networks), it is less so now due to social media. Social media forces the use of symmetric bandwidth (like FTTH), putting even more demand on the network, and making the gist of this thread an even bigger issue, if you discount the fact, of course, that Broadband in the U.S. currently sucks for a developed market. 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 khelms at zcorum.com Fri May 16 15:08:33 2014 From: khelms at zcorum.com (Scott Helms) Date: Fri, 16 May 2014 11:08:33 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <201405161702.03926.mark.tinka@seacom.mu> References: <5375ADFB.3000303@vaxination.ca> <1ED86D5A-748F-4AD2-A40D-195B148797CE@delong.com> <201405161702.03926.mark.tinka@seacom.mu> Message-ID: Social media is not a big driver of symmetrical traffic here in the US or internationally. Broadband suffers here for a number of reasons, mainly topological and population density, in comparison to places like Japan, parts (but certainly not all) of Europe, and South Korea. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, May 16, 2014 at 11:02 AM, Mark Tinka wrote: > On Friday, May 16, 2014 03:54:33 PM Owen DeLong wrote: > > > customers. 2. This is because when they built their > > business models, they didn’t expect their customers to > > use nearly as much of their promised bandwidth as they > > are now using. Most of the models were constructed > > around the idea that a customer receiving, say 27mbps > > down/7mbps up would use all of that bandwidth in short > > bursts and mostly use less than a megabit. > > And in general, models have assumed, for a long time, that > customer demand patterns are largely asymmetric. > > While that is true a lot of the time (especially for eyeball > networks), it is less so now due to social media. Social > media forces the use of symmetric bandwidth (like FTTH), > putting even more demand on the network, and making the gist > of this thread an even bigger issue, if you discount the > fact, of course, that Broadband in the U.S. currently sucks > for a developed market. > > Mark. > From jra at baylink.com Fri May 16 15:24:57 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 16 May 2014 11:24:57 -0400 (EDT) Subject: FTTH ONTs and routers In-Reply-To: <201405160916.23417.mark.tinka@seacom.mu> Message-ID: <10894860.1814.1400253897245.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Tinka" > On Thursday, May 15, 2014 07:24:33 PM Aled Morris wrote: > > I notice Cisco's new ME4600 ONT's come in two flavors, > > one (the "Residential GateWay") with all the bells and > > whistles that you'd expect in an all-in-one home router > > (voice ports, small ethernet switch, wifi access point) > > and another (the "Single Family Unit") that looks a lot > > more basic and is likely to be deployed as a bridge. > > Ah, so looks like it's been announced now - that is the > breed I was referring to; the ME4600 OLT. Having just gone through The Usual Crap getting a new Bright House/ Road Runner deploy into bridge mode for our own router (ask at order, ask installer, find out it isn't anyway, call tech support, 45 minute hold time, says twice they set it, still isn't set, magically reboots into bridge mode 45 minutes after they give up), I'm wondering: If you deploy edge gear in this class, optical, DOCSIS or DSL, what percentage of installs want bridge mode cause they're supplying their own router, and what percentage want you to supply the full training-wheels package? 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 mark.tinka at seacom.mu Fri May 16 15:26:14 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 16 May 2014 17:26:14 +0200 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: References: <201405161702.03926.mark.tinka@seacom.mu> Message-ID: <201405161726.18601.mark.tinka@seacom.mu> On Friday, May 16, 2014 05:08:33 PM Scott Helms wrote: > Social media is not a big driver of symmetrical traffic > here in the US or internationally. Broadband suffers > here for a number of reasons, mainly topological and > population density, in comparison to places like Japan, > parts (but certainly not all) of Europe, and South > Korea. It might not be (now), but if symmetrical bandwidth will go in on the back of teenagers wanting to upload videos about their lives, the meer fact that the bandwidth is there means someone will find bigger and better use for it, than social media. We saw this when we deployed FTTH in Malaysia, back in '09. 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 jra at baylink.com Fri May 16 15:27:01 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 16 May 2014 11:27:01 -0400 (EDT) Subject: A simple proposal In-Reply-To: Message-ID: <13389736.1816.1400254021459.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Matthew Petach" > You want to stream a movie? No problem; > the video player opens up a second data > port back to a server next to the streaming > box; its only purpose is to accept a socket, > and send all bits received on it to /dev/null. Congratulations, Matt, on coming up with a proposal that was *stylistically* in keeping with the one from which you stole the idea for the title. :-) 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 May 16 15:35:39 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 16 May 2014 11:35:39 -0400 (EDT) Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <201405161702.03926.mark.tinka@seacom.mu> Message-ID: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Tinka" > While that is true a lot of the time (especially for eyeball > networks), it is less so now due to social media. Social > media forces the use of symmetric bandwidth (like FTTH), > putting even more demand on the network, Oh yes; clearly, Twitter will be the end of L3. :-) Could you expand a bit, Mark on "Social media forces the use of symmetric bandwidth"? Which social media platform is it that you think has a) symmetrical flows that b) are big enough to figure into transit symmetry? 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 khelms at zcorum.com Fri May 16 15:45:06 2014 From: khelms at zcorum.com (Scott Helms) Date: Fri, 16 May 2014 11:45:06 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <201405161726.18601.mark.tinka@seacom.mu> References: <201405161702.03926.mark.tinka@seacom.mu> <201405161726.18601.mark.tinka@seacom.mu> Message-ID: Mark, Bandwidth use trends are actually increasingly asymmetical because of the popularity of OTT video. Social media, even with video uploading, simply doesn't generate that much traffic per session. "During peak period, Real-Time Entertainment traffic is by far the most dominant traffic category, accounting for almost half of the downstream bytes on the network. As observed in past reports, Social Networking applications continue to be very well represented on the mobile network. This speaks to their popularity with subscribers as these applications typically generate far less traffic than those that stream audio and video." https://www.sandvine.com/downloads/general/global-internet-phenomena/2013/sandvine-global-internet-phenomena-report-1h-2013.pdf Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, May 16, 2014 at 11:26 AM, Mark Tinka wrote: > On Friday, May 16, 2014 05:08:33 PM Scott Helms wrote: > > > Social media is not a big driver of symmetrical traffic > > here in the US or internationally. Broadband suffers > > here for a number of reasons, mainly topological and > > population density, in comparison to places like Japan, > > parts (but certainly not all) of Europe, and South > > Korea. > > It might not be (now), but if symmetrical bandwidth will go > in on the back of teenagers wanting to upload videos about > their lives, the meer fact that the bandwidth is there means > someone will find bigger and better use for it, than social > media. > > We saw this when we deployed FTTH in Malaysia, back in '09. > > Mark. > From blake at ispn.net Fri May 16 15:53:00 2014 From: blake at ispn.net (Blake Hudson) Date: Fri, 16 May 2014 10:53:00 -0500 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> Message-ID: <5376345C.8070300@ispn.net> Jay Ashworth wrote the following on 5/16/2014 10:35 AM: > ----- Original Message ----- >> From: "Mark Tinka" >> While that is true a lot of the time (especially for eyeball >> networks), it is less so now due to social media. Social >> media forces the use of symmetric bandwidth (like FTTH), >> putting even more demand on the network, > Oh yes; clearly, Twitter will be the end of L3. > > :-) > > Could you expand a bit, Mark on "Social media forces the use of symmetric > bandwidth"? Which social media platform is it that you think has a) > symmetrical flows that b) are big enough to figure into transit symmetry? > > Cheers, > -- jra Applications like Skype and Facetime (especially conference calls) would be one example where an application benefits from symmetric (or asymmetric in favor of higher upload speed) connectivity. Cloud office applications like storage of documents, email, and IVR telephony also benefit from symmetrical connectivity. Off-site backup software is another great example. Most residential connections are ill suited for this. I believe these applications (and derivatives) would be more popular today if the connectivity was available. --Blake From khelms at zcorum.com Fri May 16 16:02:03 2014 From: khelms at zcorum.com (Scott Helms) Date: Fri, 16 May 2014 12:02:03 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <5376345C.8070300@ispn.net> References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> Message-ID: Blake, None of those applications come close to causing symmetrical traffic patterns and for many/most networks the upstream connectivity has greatly improved. Anything related to voice is no more than 80 kbps per line, even if the SIP traffic isn't trunked (less if it is because the signaling data is shared). Document sharing is not being impinged, on my residential account right now I've uploaded about 30 documents this morning including large PDFs and Power Point presentations. Off site back up is one use that could drive traffic, but I don't believe that the limiting factor is bandwidth. We looked at getting into that business and from what we saw the limiting factor was that most residential and SOHO accounts didn't want to pay enough to cover your storage & management costs. In our analysis the impact of bandwidth on the consumer side adoption was basically zero. There is no expectation that back ups run instantly. Having said all of that, even if hosted back up became wildly popular would not change the balance of power because OTT video is both larger, especially for HD streams, and used much more frequently. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, May 16, 2014 at 11:53 AM, Blake Hudson wrote: > > Jay Ashworth wrote the following on 5/16/2014 10:35 AM: > >> ----- Original Message ----- >> >>> From: "Mark Tinka" >>> While that is true a lot of the time (especially for eyeball >>> networks), it is less so now due to social media. Social >>> media forces the use of symmetric bandwidth (like FTTH), >>> putting even more demand on the network, >>> >> Oh yes; clearly, Twitter will be the end of L3. >> >> :-) >> >> Could you expand a bit, Mark on "Social media forces the use of symmetric >> bandwidth"? Which social media platform is it that you think has a) >> symmetrical flows that b) are big enough to figure into transit symmetry? >> >> Cheers, >> -- jra >> > Applications like Skype and Facetime (especially conference calls) would > be one example where an application benefits from symmetric (or asymmetric > in favor of higher upload speed) connectivity. Cloud office applications > like storage of documents, email, and IVR telephony also benefit from > symmetrical connectivity. Off-site backup software is another great > example. Most residential connections are ill suited for this. I believe > these applications (and derivatives) would be more popular today if the > connectivity was available. > > --Blake > From nicotine at warningg.com Fri May 16 16:05:05 2014 From: nicotine at warningg.com (Brandon Ewing) Date: Fri, 16 May 2014 11:05:05 -0500 Subject: A simple proposal In-Reply-To: References: Message-ID: <20140516160505.GA14426@radiological.warningg.com> On Thu, May 15, 2014 at 10:26:02PM -0700, Matthew Petach wrote: > > You want to stream a movie? No problem; > the video player opens up a second data > port back to a server next to the streaming > box; its only purpose is to accept a socket, > and send all bits received on it to /dev/null. You can push the stream back to offloaded cloud now: http://devnull-as-a-service.com/ -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Kevin_McElearney at cable.comcast.com Fri May 16 16:28:19 2014 From: Kevin_McElearney at cable.comcast.com (McElearney, Kevin) Date: Fri, 16 May 2014 16:28:19 +0000 Subject: A simple proposal In-Reply-To: <20140516160505.GA14426@radiological.warningg.com> References: <20140516160505.GA14426@radiological.warningg.com> Message-ID: I agree symmetry alone is a bad metric and efforts to build a service, or artifically game traffic in order to create symmetry will likely have negative consequences all around. I can¹t speak for all situations, but I believe relative ³balance" was designed to be one of several criteria which outlines the definition of a ³Peer² in the Internet's current two sided market. It is one criteria which helps define some measure of economic trade of network investment to carry traffic between respective customer networks and helps avoid exploitation of the trade relationship. - Kevin On 5/16/14, 12:05 PM, "Brandon Ewing" wrote: >On Thu, May 15, 2014 at 10:26:02PM -0700, Matthew Petach wrote: >> >> You want to stream a movie? No problem; >> the video player opens up a second data >> port back to a server next to the streaming >> box; its only purpose is to accept a socket, >> and send all bits received on it to /dev/null. > >You can push the stream back to offloaded cloud now: >http://devnull-as-a-service.com/ > >-- >Brandon Ewing >(nicotine at warningg.com) From blake at ispn.net Fri May 16 16:38:27 2014 From: blake at ispn.net (Blake Hudson) Date: Fri, 16 May 2014 11:38:27 -0500 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> Message-ID: <53763F03.7040706@ispn.net> Certainly video is one of the most bandwidth intensive applications. I don't deny that a < 1 Mbps video call is both less common and consumes less bandwidth than an 8Mbps HD stream. However, if Americans had access to symmetric connections capable of reliably making HD video calls (they don't, in my experience), we might be seeing video calls as a common occurrence and not a novelty. I think the state of usage is a reflection on the technology available. If the capability was available at an affordable price to residential consumers, we might see those consumers stream movies or send videos from their home or mobile devices via their internet connection directly to the recipient rather than through a centralized source like Disney, NetFlix, Youtube, etc. Video sharing sites (like youtube, vimeo, etc) primary reason for existence is due to the inability of the site's users to distribute content themselves. One of the hurdles to overcome in video sharing is the lack of availability in affordable internet connectivity that is capable of sending video at reasonable (greater than real time) speeds. --Blake Scott Helms wrote the following on 5/16/2014 11:02 AM: > Blake, > > None of those applications come close to causing symmetrical traffic > patterns and for many/most networks the upstream connectivity has > greatly improved. Anything related to voice is no more than 80 kbps > per line, even if the SIP traffic isn't trunked (less if it is because > the signaling data is shared). Document sharing is not being > impinged, on my residential account right now I've uploaded about 30 > documents this morning including large PDFs and Power Point presentations. > > Off site back up is one use that could drive traffic, but I don't > believe that the limiting factor is bandwidth. We looked at getting > into that business and from what we saw the limiting factor was that > most residential and SOHO accounts didn't want to pay enough to cover > your storage & management costs. In our analysis the impact of > bandwidth on the consumer side adoption was basically zero. There is > no expectation that back ups run instantly. Having said all of that, > even if hosted back up became wildly popular would not change the > balance of power because OTT video is both larger, especially for HD > streams, and used much more frequently. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > On Fri, May 16, 2014 at 11:53 AM, Blake Hudson > wrote: > > > Jay Ashworth wrote the following on 5/16/2014 10:35 AM: > > ----- Original Message ----- > > From: "Mark Tinka" > > While that is true a lot of the time (especially for eyeball > networks), it is less so now due to social media. Social > media forces the use of symmetric bandwidth (like FTTH), > putting even more demand on the network, > > Oh yes; clearly, Twitter will be the end of L3. > > :-) > > Could you expand a bit, Mark on "Social media forces the use > of symmetric > bandwidth"? Which social media platform is it that you think > has a) > symmetrical flows that b) are big enough to figure into > transit symmetry? > > Cheers, > -- jra > > Applications like Skype and Facetime (especially conference calls) > would be one example where an application benefits from symmetric > (or asymmetric in favor of higher upload speed) connectivity. > Cloud office applications like storage of documents, email, and > IVR telephony also benefit from symmetrical connectivity. Off-site > backup software is another great example. Most residential > connections are ill suited for this. I believe these applications > (and derivatives) would be more popular today if the connectivity > was available. > > --Blake > > From betty at newnog.org Fri May 16 16:38:50 2014 From: betty at newnog.org (Betty Burke ) Date: Fri, 16 May 2014 12:38:50 -0400 Subject: [NANOG-announce] NANOG 61 Final Update Message-ID: NANOGers: We are aware of stress regarding the Hyatt Hotel Room Block, therefore, 2 alternate NANOG Room blocks at nearby hotels have been established. We are confident, all who wish to attend NANOG 61 should find a reasonable hotel rate and room. Contact nanog-support at nanog.orgshould you have any questions or concerns regarding the hotels. The NANOG 61 agenda is posted, and the Evening Social informationis also available. Registration for the Education class series is open. A few, sponsorship opportunitiesremain for NANOG 61. Send a note to marketing at nanog.org to let us know if you (or your company) maybe interested and we will be sure to get right back to you. Lastly, be aware the meeting registrationrate will increase on May 25, 2014. Safe travels to everyone, and we look forward to seeing many of you in Bellevue. 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 khelms at zcorum.com Fri May 16 17:06:17 2014 From: khelms at zcorum.com (Scott Helms) Date: Fri, 16 May 2014 13:06:17 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <53763F03.7040706@ispn.net> References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> Message-ID: Blake, I might agree with your premise if weren't for a couple of items. 1) Very few consumers are walking around with a HD or 4K camera today. 2) Most consumers who want to share video wouldn't know how to host it themselves, which isn't an insurmountable issue but is a big barrier to entry especially given the number of NAT'ed connections. I think this is much more of a problem than available bandwidth. 3) Most consumers who want to share videos seem to be satisfied with sharing via one of the cloud services whether that be YouTube (which was created originally for that use), Vimeo, or one of the other legions of services like DropBox. 4) Finally, upstream bandwidth has increased on many/most operators. I just ran the FCC's speedtest (mLab not Ookla) and got 22 mbps on my residential cable internet service. I subscribe to one of the major MSOs for a normal residential package. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, May 16, 2014 at 12:38 PM, Blake Hudson wrote: > Certainly video is one of the most bandwidth intensive applications. I > don't deny that a < 1 Mbps video call is both less common and consumes less > bandwidth than an 8Mbps HD stream. However, if Americans had access to > symmetric connections capable of reliably making HD video calls (they > don't, in my experience), we might be seeing video calls as a common > occurrence and not a novelty. I think the state of usage is a reflection on > the technology available. > > If the capability was available at an affordable price to residential > consumers, we might see those consumers stream movies or send videos from > their home or mobile devices via their internet connection directly to the > recipient rather than through a centralized source like Disney, NetFlix, > Youtube, etc. Video sharing sites (like youtube, vimeo, etc) primary reason > for existence is due to the inability of the site's users to distribute > content themselves. One of the hurdles to overcome in video sharing is the > lack of availability in affordable internet connectivity that is capable of > sending video at reasonable (greater than real time) speeds. > > --Blake > > Scott Helms wrote the following on 5/16/2014 11:02 AM: > >> Blake, >> >> None of those applications come close to causing symmetrical traffic >> patterns and for many/most networks the upstream connectivity has greatly >> improved. Anything related to voice is no more than 80 kbps per line, even >> if the SIP traffic isn't trunked (less if it is because the signaling data >> is shared). Document sharing is not being impinged, on my residential >> account right now I've uploaded about 30 documents this morning including >> large PDFs and Power Point presentations. >> >> Off site back up is one use that could drive traffic, but I don't believe >> that the limiting factor is bandwidth. We looked at getting into that >> business and from what we saw the limiting factor was that most residential >> and SOHO accounts didn't want to pay enough to cover your storage & >> management costs. In our analysis the impact of bandwidth on the consumer >> side adoption was basically zero. There is no expectation that back ups >> run instantly. Having said all of that, even if hosted back up became >> wildly popular would not change the balance of power because OTT video is >> both larger, especially for HD streams, and used much more frequently. >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> >> On Fri, May 16, 2014 at 11:53 AM, Blake Hudson > blake at ispn.net>> wrote: >> >> >> Jay Ashworth wrote the following on 5/16/2014 10:35 AM: >> >> ----- Original Message ----- >> >> From: "Mark Tinka" > > >> While that is true a lot of the time (especially for eyeball >> networks), it is less so now due to social media. Social >> media forces the use of symmetric bandwidth (like FTTH), >> putting even more demand on the network, >> >> Oh yes; clearly, Twitter will be the end of L3. >> >> :-) >> >> Could you expand a bit, Mark on "Social media forces the use >> of symmetric >> bandwidth"? Which social media platform is it that you think >> has a) >> symmetrical flows that b) are big enough to figure into >> transit symmetry? >> >> Cheers, >> -- jra >> >> Applications like Skype and Facetime (especially conference calls) >> would be one example where an application benefits from symmetric >> (or asymmetric in favor of higher upload speed) connectivity. >> Cloud office applications like storage of documents, email, and >> IVR telephony also benefit from symmetrical connectivity. Off-site >> backup software is another great example. Most residential >> connections are ill suited for this. I believe these applications >> (and derivatives) would be more popular today if the connectivity >> was available. >> >> --Blake >> >> >> > From mike at mtcc.com Fri May 16 17:18:09 2014 From: mike at mtcc.com (Michael Thomas) Date: Fri, 16 May 2014 17:18:09 -0000 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: References: <201405161702.03926.mark.tinka@seacom.mu> <201405161726.18601.mark.tinka@seacom.mu> Message-ID: <535D9F07.1000808@mtcc.com> Scott Helms wrote: > Mark, > > Bandwidth use trends are actually increasingly asymmetical because of the > popularity of OTT video. Until my other half decides to upload a video. Is it too much to ask for a bucket of bits that I can use in whichever direction happens to be needed at the moment? Mike From blake at ispn.net Fri May 16 17:20:22 2014 From: blake at ispn.net (Blake Hudson) Date: Fri, 16 May 2014 12:20:22 -0500 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> Message-ID: <537648D6.9070308@ispn.net> Thanks for the insight Scott. I appreciate the experience and point of view you're adding to this discussion (not just the responses to me). While I might be playing the devil's advocate here a bit, I think one could argue each of the points you've made below. I do feel that general usage patterns are a reflection of the technologies that have traditionally been available to consumers. New uses and applications would be available to overcome hurdles if the technologies had developed to be symmetrical. I'm not saying that the asymmetrical choice was a bad one, but it was not without consequences. If residential ISPs sell asymmetric connections for decades, how can the ISP expect that application developers would not take this into account when developing applications? I don't think my application would be very successful if it required X Mbps and half of my market did not meet this requirement. Of course content/service providers are going to tailor their services based around their market. --Blake Scott Helms wrote the following on 5/16/2014 12:06 PM: > Blake, > > I might agree with your premise if weren't for a couple of items. > > 1) Very few consumers are walking around with a HD or 4K camera today. > > 2) Most consumers who want to share video wouldn't know how to host > it themselves, which isn't an insurmountable issue but is a big > barrier to entry especially given the number of NAT'ed connections. I > think this is much more of a problem than available bandwidth. > > 3) Most consumers who want to share videos seem to be satisfied with > sharing via one of the cloud services whether that be YouTube (which > was created originally for that use), Vimeo, or one of the other > legions of services like DropBox. > > 4) Finally, upstream bandwidth has increased on many/most operators. > I just ran the FCC's speedtest (mLab not Ookla) and got 22 mbps on my > residential cable internet service. I subscribe to one of the major > MSOs for a normal residential package. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > On Fri, May 16, 2014 at 12:38 PM, Blake Hudson > wrote: > > Certainly video is one of the most bandwidth intensive > applications. I don't deny that a < 1 Mbps video call is both less > common and consumes less bandwidth than an 8Mbps HD stream. > However, if Americans had access to symmetric connections capable > of reliably making HD video calls (they don't, in my experience), > we might be seeing video calls as a common occurrence and not a > novelty. I think the state of usage is a reflection on the > technology available. > > If the capability was available at an affordable price to > residential consumers, we might see those consumers stream movies > or send videos from their home or mobile devices via their > internet connection directly to the recipient rather than through > a centralized source like Disney, NetFlix, Youtube, etc. Video > sharing sites (like youtube, vimeo, etc) primary reason for > existence is due to the inability of the site's users to > distribute content themselves. One of the hurdles to overcome in > video sharing is the lack of availability in affordable internet > connectivity that is capable of sending video at reasonable > (greater than real time) speeds. > > --Blake > > Scott Helms wrote the following on 5/16/2014 11:02 AM: > > Blake, > > None of those applications come close to causing symmetrical > traffic patterns and for many/most networks the upstream > connectivity has greatly improved. Anything related to voice > is no more than 80 kbps per line, even if the SIP traffic > isn't trunked (less if it is because the signaling data is > shared). Document sharing is not being impinged, on my > residential account right now I've uploaded about 30 documents > this morning including large PDFs and Power Point presentations. > > Off site back up is one use that could drive traffic, but I > don't believe that the limiting factor is bandwidth. We > looked at getting into that business and from what we saw the > limiting factor was that most residential and SOHO accounts > didn't want to pay enough to cover your storage & management > costs. In our analysis the impact of bandwidth on the > consumer side adoption was basically zero. There is no > expectation that back ups run instantly. Having said all of > that, even if hosted back up became wildly popular would not > change the balance of power because OTT video is both larger, > especially for HD streams, and used much more frequently. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > On Fri, May 16, 2014 at 11:53 AM, Blake Hudson >> wrote: > > > Jay Ashworth wrote the following on 5/16/2014 10:35 AM: > > ----- Original Message ----- > > From: "Mark Tinka" > >> > While that is true a lot of the time (especially > for eyeball > networks), it is less so now due to social media. > Social > media forces the use of symmetric bandwidth (like > FTTH), > putting even more demand on the network, > > Oh yes; clearly, Twitter will be the end of L3. > > :-) > > Could you expand a bit, Mark on "Social media forces > the use > of symmetric > bandwidth"? Which social media platform is it that > you think > has a) > symmetrical flows that b) are big enough to figure into > transit symmetry? > > Cheers, > -- jra > > Applications like Skype and Facetime (especially > conference calls) > would be one example where an application benefits from > symmetric > (or asymmetric in favor of higher upload speed) connectivity. > Cloud office applications like storage of documents, > email, and > IVR telephony also benefit from symmetrical connectivity. > Off-site > backup software is another great example. Most residential > connections are ill suited for this. I believe these > applications > (and derivatives) would be more popular today if the > connectivity > was available. > > --Blake > > > > From george.herbert at gmail.com Fri May 16 17:29:05 2014 From: george.herbert at gmail.com (George William Herbert) Date: Fri, 16 May 2014 10:29:05 -0700 Subject: A simple proposal In-Reply-To: References: <20140516160505.GA14426@radiological.warningg.com> Message-ID: On May 16, 2014, at 9:28 AM, "McElearney, Kevin" wrote: > will likely have > negative consequences all around. Actually, pretty focusedly more negative for the middlemen trying to charge for those packets' transit of their networks. -george william herbert george.herbert at gmail.com Sent from Kangphone From khelms at zcorum.com Fri May 16 17:34:35 2014 From: khelms at zcorum.com (Scott Helms) Date: Fri, 16 May 2014 13:34:35 -0400 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <535D9F07.1000808@mtcc.com> References: <201405161702.03926.mark.tinka@seacom.mu> <201405161726.18601.mark.tinka@seacom.mu> <535D9F07.1000808@mtcc.com> Message-ID: Michael, No, its not too much to ask and any end user who has that kind of requirement can order a business service to get symmetrical service but the reality is that symmetrical service costs more and the vast majority of customers don't use the upstream capacity they have today. I have personal insight into about half a million devices and the percentage of people who bump up against their upstream rate is less than 0.2%. I have the ability to get data on another 10 million and the last time I checked their rates were similar. This kind of question has been asked of operators since long before cable companies could offer internet service. What happens if everyone in an area use their telephone (cellular or land line) at the same time? A fast busy or recorded "All circuits are busy message." Over subscription is a fact of economics in virtually everything we do. By this logic restaurants should be massively over built so that there is never a waiting line, highways should always be a speed limit ride, and all of these things would cost much more money than they do today. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Sun, Apr 27, 2014 at 8:21 PM, Michael Thomas wrote: > Scott Helms wrote: > >> Mark, >> >> Bandwidth use trends are actually increasingly asymmetical because of the >> popularity of OTT video. >> > > Until my other half decides to upload a video. > > Is it too much to ask for a bucket of bits that I can use in whichever > direction happens > to be needed at the moment? > > Mike > From mpetach at netflight.com Fri May 16 17:37:20 2014 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 16 May 2014 10:37:20 -0700 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <535D9F07.1000808@mtcc.com> References: <201405161702.03926.mark.tinka@seacom.mu> <201405161726.18601.mark.tinka@seacom.mu> <535D9F07.1000808@mtcc.com> Message-ID: On Sun, Apr 27, 2014 at 5:21 PM, Michael Thomas wrote: > Scott Helms wrote: > >> Mark, >> >> Bandwidth use trends are actually increasingly asymmetical because of the >> popularity of OTT video. >> > > Until my other half decides to upload a video. > > Is it too much to ask for a bucket of bits that I can use in whichever > direction happens > to be needed at the moment? > > Mike > > Sure, I've got two of those; they're called T1 lines, and they work equally well in both directions, even when the other half wants to upload cat videos. Matt From khelms at zcorum.com Fri May 16 17:39:43 2014 From: khelms at zcorum.com (Scott Helms) Date: Fri, 16 May 2014 13:39:43 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <537648D6.9070308@ispn.net> References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> <537648D6.9070308@ispn.net> Message-ID: Blake, You're absolutely correct. The world adapts to the reality that we find ourselves in via normal market mechanics. The problem with proposing that connectivity for residential customers should be more symmetrical is that its expensive, which is why we as operators didn't roll it out that way to start. We also don't see consumer demand for symmetrical connections and with the decline in peer to peer file sharing we've actually seen a decrease the ratio of used upstream bandwidth (though not a decrease in absolute terms). I would like to deliver symmetrical bandwidth to all consumers just so those few customers who need it today would have lower bills but trying to justify that to our CFO without being able to point to an increase in revenue either because of more revenue per sub or more subs is a very tough task. I don't believe my situation is uncommon. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, May 16, 2014 at 1:20 PM, Blake Hudson wrote: > Thanks for the insight Scott. I appreciate the experience and point of > view you're adding to this discussion (not just the responses to me). While > I might be playing the devil's advocate here a bit, I think one could argue > each of the points you've made below. > > I do feel that general usage patterns are a reflection of the technologies > that have traditionally been available to consumers. New uses and > applications would be available to overcome hurdles if the technologies had > developed to be symmetrical. I'm not saying that the asymmetrical choice > was a bad one, but it was not without consequences. If residential ISPs > sell asymmetric connections for decades, how can the ISP expect that > application developers would not take this into account when developing > applications? I don't think my application would be very successful if it > required X Mbps and half of my market did not meet this requirement. Of > course content/service providers are going to tailor their services based > around their market. > > --Blake > > Scott Helms wrote the following on 5/16/2014 12:06 PM: > >> Blake, >> >> I might agree with your premise if weren't for a couple of items. >> >> 1) Very few consumers are walking around with a HD or 4K camera today. >> >> 2) Most consumers who want to share video wouldn't know how to host it >> themselves, which isn't an insurmountable issue but is a big barrier to >> entry especially given the number of NAT'ed connections. I think this is >> much more of a problem than available bandwidth. >> >> 3) Most consumers who want to share videos seem to be satisfied with >> sharing via one of the cloud services whether that be YouTube (which was >> created originally for that use), Vimeo, or one of the other legions of >> services like DropBox. >> >> 4) Finally, upstream bandwidth has increased on many/most operators. I >> just ran the FCC's speedtest (mLab not Ookla) and got 22 mbps on my >> residential cable internet service. I subscribe to one of the major MSOs >> for a normal residential package. >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> >> On Fri, May 16, 2014 at 12:38 PM, Blake Hudson > blake at ispn.net>> wrote: >> >> Certainly video is one of the most bandwidth intensive >> applications. I don't deny that a < 1 Mbps video call is both less >> common and consumes less bandwidth than an 8Mbps HD stream. >> However, if Americans had access to symmetric connections capable >> of reliably making HD video calls (they don't, in my experience), >> we might be seeing video calls as a common occurrence and not a >> novelty. I think the state of usage is a reflection on the >> technology available. >> >> If the capability was available at an affordable price to >> residential consumers, we might see those consumers stream movies >> or send videos from their home or mobile devices via their >> internet connection directly to the recipient rather than through >> a centralized source like Disney, NetFlix, Youtube, etc. Video >> sharing sites (like youtube, vimeo, etc) primary reason for >> existence is due to the inability of the site's users to >> distribute content themselves. One of the hurdles to overcome in >> video sharing is the lack of availability in affordable internet >> connectivity that is capable of sending video at reasonable >> (greater than real time) speeds. >> >> --Blake >> >> Scott Helms wrote the following on 5/16/2014 11:02 AM: >> >> Blake, >> >> None of those applications come close to causing symmetrical >> traffic patterns and for many/most networks the upstream >> connectivity has greatly improved. Anything related to voice >> is no more than 80 kbps per line, even if the SIP traffic >> isn't trunked (less if it is because the signaling data is >> shared). Document sharing is not being impinged, on my >> residential account right now I've uploaded about 30 documents >> this morning including large PDFs and Power Point presentations. >> >> Off site back up is one use that could drive traffic, but I >> don't believe that the limiting factor is bandwidth. We >> looked at getting into that business and from what we saw the >> limiting factor was that most residential and SOHO accounts >> didn't want to pay enough to cover your storage & management >> costs. In our analysis the impact of bandwidth on the >> consumer side adoption was basically zero. There is no >> expectation that back ups run instantly. Having said all of >> that, even if hosted back up became wildly popular would not >> change the balance of power because OTT video is both larger, >> especially for HD streams, and used much more frequently. >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> >> On Fri, May 16, 2014 at 11:53 AM, Blake Hudson > > >> wrote: >> >> >> Jay Ashworth wrote the following on 5/16/2014 10:35 AM: >> >> ----- Original Message ----- >> >> From: "Mark Tinka" > >> > >> >> While that is true a lot of the time (especially >> for eyeball >> networks), it is less so now due to social media. >> Social >> media forces the use of symmetric bandwidth (like >> FTTH), >> putting even more demand on the network, >> >> Oh yes; clearly, Twitter will be the end of L3. >> >> :-) >> >> Could you expand a bit, Mark on "Social media forces >> the use >> of symmetric >> bandwidth"? Which social media platform is it that >> you think >> has a) >> symmetrical flows that b) are big enough to figure into >> transit symmetry? >> >> Cheers, >> -- jra >> >> Applications like Skype and Facetime (especially >> conference calls) >> would be one example where an application benefits from >> symmetric >> (or asymmetric in favor of higher upload speed) connectivity. >> Cloud office applications like storage of documents, >> email, and >> IVR telephony also benefit from symmetrical connectivity. >> Off-site >> backup software is another great example. Most residential >> connections are ill suited for this. I believe these >> applications >> (and derivatives) would be more popular today if the >> connectivity >> was available. >> >> --Blake >> >> >> >> >> > From cscora at apnic.net Fri May 16 18:11:44 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 17 May 2014 04:11:44 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201405161811.s4GIBiib012079@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 17 May, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 494425 Prefixes after maximum aggregation: 194026 Deaggregation factor: 2.55 Unique aggregates announced to Internet: 244746 Total ASes present in the Internet Routing Table: 46876 Prefixes per ASN: 10.55 Origin-only ASes present in the Internet Routing Table: 35819 Origin ASes announcing only one prefix: 16376 Transit ASes present in the Internet Routing Table: 6100 Transit-only ASes present in the Internet Routing Table: 178 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1767 Unregistered ASNs in the Routing Table: 459 Number of 32-bit ASNs allocated by the RIRs: 6631 Number of 32-bit ASNs visible in the Routing Table: 4957 Prefixes from 32-bit ASNs in the Routing Table: 16579 Number of bogon 32-bit ASNs visible in the Routing Table: 123 Special use prefixes present in the Routing Table: 3 Prefixes being announced from unallocated address space: 455 Number of addresses announced to Internet: 2686157316 Equivalent to 160 /8s, 27 /16s and 130 /24s Percentage of available address space announced: 72.6 Percentage of allocated address space announced: 72.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.4 Total number of prefixes smaller than registry allocations: 170913 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 117997 Total APNIC prefixes after maximum aggregation: 35118 APNIC Deaggregation factor: 3.36 Prefixes being announced from the APNIC address blocks: 120997 Unique aggregates announced from the APNIC address blocks: 50556 APNIC Region origin ASes present in the Internet Routing Table: 4941 APNIC Prefixes per ASN: 24.49 APNIC Region origin ASes announcing only one prefix: 1231 APNIC Region transit ASes present in the Internet Routing Table: 871 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 21 Number of APNIC region 32-bit ASNs visible in the Routing Table: 947 Number of APNIC addresses announced to Internet: 732831104 Equivalent to 43 /8s, 174 /16s and 29 /24s Percentage of available APNIC address space announced: 85.6 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: 168161 Total ARIN prefixes after maximum aggregation: 83564 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 169653 Unique aggregates announced from the ARIN address blocks: 79930 ARIN Region origin ASes present in the Internet Routing Table: 16272 ARIN Prefixes per ASN: 10.43 ARIN Region origin ASes announcing only one prefix: 6124 ARIN Region transit ASes present in the Internet Routing Table: 1670 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 103 Number of ARIN addresses announced to Internet: 1075289472 Equivalent to 64 /8s, 23 /16s and 157 /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: 123140 Total RIPE prefixes after maximum aggregation: 62592 RIPE Deaggregation factor: 1.97 Prefixes being announced from the RIPE address blocks: 127720 Unique aggregates announced from the RIPE address blocks: 80508 RIPE Region origin ASes present in the Internet Routing Table: 17686 RIPE Prefixes per ASN: 7.22 RIPE Region origin ASes announcing only one prefix: 8272 RIPE Region transit ASes present in the Internet Routing Table: 2884 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: 2702 Number of RIPE addresses announced to Internet: 657675908 Equivalent to 39 /8s, 51 /16s and 86 /24s Percentage of available RIPE address space announced: 95.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 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: 56577 Total LACNIC prefixes after maximum aggregation: 10060 LACNIC Deaggregation factor: 5.62 Prefixes being announced from the LACNIC address blocks: 63064 Unique aggregates announced from the LACNIC address blocks: 29007 LACNIC Region origin ASes present in the Internet Routing Table: 2098 LACNIC Prefixes per ASN: 30.06 LACNIC Region origin ASes announcing only one prefix: 541 LACNIC Region transit ASes present in the Internet Routing Table: 437 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1174 Number of LACNIC addresses announced to Internet: 161174912 Equivalent to 9 /8s, 155 /16s and 85 /24s Percentage of available LACNIC address space announced: 96.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: 11859 Total AfriNIC prefixes after maximum aggregation: 2654 AfriNIC Deaggregation factor: 4.47 Prefixes being announced from the AfriNIC address blocks: 12536 Unique aggregates announced from the AfriNIC address blocks: 4364 AfriNIC Region origin ASes present in the Internet Routing Table: 718 AfriNIC Prefixes per ASN: 17.46 AfriNIC Region origin ASes announcing only one prefix: 208 AfriNIC Region transit ASes present in the Internet Routing Table: 152 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 31 Number of AfriNIC addresses announced to Internet: 55690496 Equivalent to 3 /8s, 81 /16s and 197 /24s Percentage of available AfriNIC address space announced: 55.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 2946 11591 922 Korea Telecom 17974 2793 899 72 PT Telekomunikasi Indonesia 7545 2228 320 117 TPG Telecom Limited 4755 1852 396 199 TATA Communications formerly 9829 1645 1306 37 National Internet Backbone 9583 1315 104 543 Sify Limited 9498 1260 314 86 BHARTI Airtel Ltd. 7552 1223 1082 13 Viettel Corporation 4808 1219 2153 363 CNCGROUP IP network China169 24560 1129 389 183 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 2960 3688 53 BellSouth.net Inc. 22773 2438 2937 133 Cox Communications Inc. 1785 2206 701 135 PaeTec Communications, Inc. 18566 2047 379 178 MegaPath Corporation 20115 1706 1689 567 Charter Communications 4323 1632 1073 412 tw telecom holdings, inc. 701 1473 11159 746 MCI Communications Services, 30036 1407 306 549 Mediacom Communications Corp 6983 1327 800 306 ITC^Deltacom 22561 1306 402 232 CenturyTel Internet Holdings, 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 34984 1708 264 270 TELLCOM ILETISIM HIZMETLERI A 8402 1497 544 16 OJSC "Vimpelcom" 20940 1328 509 991 Akamai International B.V. 13188 1049 100 28 TOV "Bank-Inform" 31148 1018 45 19 Freenet Ltd. 8551 918 370 40 Bezeq International-Ltd 6849 823 357 28 JSC "Ukrtelecom" 6830 765 2333 427 Liberty Global Operations B.V 12479 722 797 56 France Telecom Espana SA 9198 569 344 25 JSC Kazakhtelecom 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 3757 1990 99 NET Servi�os de Comunica��o S 10620 2853 461 202 Telmex Colombia S.A. 18881 1982 972 21 Global Village Telecom 7303 1753 1174 229 Telecom Argentina S.A. 8151 1403 2933 405 Uninet S.A. de C.V. 6503 1108 434 60 Axtel, S.A.B. de C.V. 7738 912 1754 39 Telemar Norte Leste S.A. 27947 876 114 50 Telconet S.A 26615 858 2325 35 Tim Celular S.A. 3816 817 334 136 COLOMBIA TELECOMUNICACIONES S 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 1114 240 6 Sudanese Mobile Telephone (ZA 24863 961 280 26 Link Egypt (Link.NET) 6713 615 727 32 Office National des Postes et 8452 577 958 13 TE-AS 24835 304 144 9 Vodafone Data 36992 301 783 24 ETISALAT MISR 3741 248 921 209 Internet Solutions 37054 241 19 6 Data Telecom Service 29571 229 22 16 Cote d'Ivoire Telecom 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 3757 1990 99 NET Servi�os de Comunica��o S 6389 2960 3688 53 BellSouth.net Inc. 4766 2946 11591 922 Korea Telecom 10620 2853 461 202 Telmex Colombia S.A. 17974 2793 899 72 PT Telekomunikasi Indonesia 22773 2438 2937 133 Cox Communications Inc. 7545 2228 320 117 TPG Telecom Limited 1785 2206 701 135 PaeTec Communications, Inc. 18566 2047 379 178 MegaPath Corporation 18881 1982 972 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 2960 2907 BellSouth.net Inc. 17974 2793 2721 PT Telekomunikasi Indonesia 10620 2853 2651 Telmex Colombia S.A. 22773 2438 2305 Cox Communications Inc. 7545 2228 2111 TPG Telecom Limited 1785 2206 2071 PaeTec Communications, Inc. 4766 2946 2024 Korea Telecom 18881 1982 1961 Global Village Telecom 18566 2047 1869 MegaPath Corporation 4755 1852 1653 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 5.109.32.0/19 23456 32bit Transition AS 65456 PRIVATE 5.109.96.0/19 23456 32bit Transition AS 30662 UNALLOCATED 8.2.129.0/24 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 22511 UNALLOCATED 8.28.225.0/24 2828 XO Communications 22511 UNALLOCATED 8.36.68.0/24 2828 XO Communications 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.64.0.0/11 7922 Comcast Cable Communications, 100.64.111.0/24 25019 Autonomus System Number for S 100.96.0.0/12 7922 Comcast Cable Communications, 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 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.14.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 41.73.16.0/24 37004 >>UNKNOWN<< 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:12 /10:30 /11:91 /12:259 /13:486 /14:966 /15:1700 /16:12964 /17:6885 /18:11699 /19:24346 /20:34354 /21:36772 /22:52838 /23:46336 /24:262524 /25:775 /26:929 /27:390 /28:13 /29:20 /30:7 /31:1 /32:12 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2002 2047 MegaPath Corporation 6389 1692 2960 BellSouth.net Inc. 22773 1683 2438 Cox Communications Inc. 30036 1245 1407 Mediacom Communications Corp 8402 1182 1497 OJSC "Vimpelcom" 11492 1175 1215 CABLE ONE, INC. 1785 1166 2206 PaeTec Communications, Inc. 36998 1080 1114 Sudanese Mobile Telephone (ZA 6983 1044 1327 ITC^Deltacom 34984 1038 1708 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1123 2:670 3:3 4:15 5:1000 6:19 8:745 12:1843 13:4 14:997 15:13 16:2 17:32 18:21 20:36 23:820 24:1733 25:1 27:1751 31:1481 32:43 33:2 34:5 36:132 37:1882 38:959 39:8 40:203 41:3165 42:249 44:12 46:2042 47:19 49:703 50:933 52:12 54:47 55:6 57:29 58:1227 59:602 60:408 61:1539 62:1219 63:1962 64:4302 65:2290 66:4192 67:2068 68:1034 69:3332 70:855 71:449 72:2016 74:2652 75:323 76:419 77:1517 78:874 79:706 80:1291 81:1165 82:746 83:752 84:684 85:1294 86:462 87:1157 88:482 89:1829 90:140 91:5684 92:694 93:1712 94:2024 95:1494 96:524 97:364 98:1075 99:48 100:55 101:804 103:4848 105:536 106:170 107:601 108:578 109:2052 110:968 111:1295 112:651 113:846 114:897 115:1124 116:1094 117:941 118:1369 119:1337 120:383 121:811 122:2035 123:1321 124:1407 125:1398 128:582 129:341 130:346 131:661 132:401 133:162 134:321 135:74 136:254 137:296 138:350 139:170 140:214 141:373 142:569 143:464 144:501 145:104 146:624 147:476 148:893 149:355 150:173 151:791 152:420 153:218 154:279 155:484 156:334 157:336 158:240 159:900 160:329 161:542 162:1438 163:221 164:691 165:605 166:281 167:614 168:1050 169:123 170:1405 171:187 172:21 173:1654 174:707 175:599 176:1409 177:2929 178:1979 179:626 180:1730 181:1121 182:1558 183:526 184:700 185:1638 186:2784 187:1539 188:1895 189:1466 190:7511 191:291 192:7263 193:5495 194:4051 195:3497 196:1411 197:646 198:5049 199:5549 200:6273 201:2614 202:9037 203:8893 204:4644 205:2675 206:2935 207:2965 208:3991 209:3722 210:3098 211:1685 212:2295 213:2085 214:879 215:86 216:5511 217:1676 218:581 219:321 220:1291 221:610 222:353 223:580 End of report From laszlo at heliacal.net Fri May 16 18:38:39 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Fri, 16 May 2014 18:38:39 +0000 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: References: <201405161702.03926.mark.tinka@seacom.mu> <201405161726.18601.mark.tinka@seacom.mu> <535D9F07.1000808@mtcc.com> Message-ID: <5D3ECC3F-8BB5-4F2E-9706-E0B8B9FFA07C@heliacal.net> I'd just like to point out that a lot of people are in fact using their upstream capability, and the operators always throw a fit and try to cut off specific applications to force it back into the idle state. For example P2P things like torrents and most recently the open NTP and DNS servers. How about SMTP? Not sure about you guys but my local broadband ISP has cut me off and told me that my 'unlimited internet' is in fact limited. The reality is that those people who are not using it (99.8%?) are just being ripped off - paying for something they were told they need, thinking that it's there when they want it, then getting cut off when they actually try to use it. It's not like whining about it here will change anything, but the prices are severely distorted. Triple play packages are designed to force people to pay for stuff they don't need or want - distorting the price of a service hoping to recover it elsewhere, then if the gamble doesn't pan out, the customer loses again. The whole model is based on people buying stuff that they won't actually come to collect, so then you can sell it an infinite number of times. The people who do try to collect what was sold to them literally end up getting called names and cut off - terms like "excessive bandwidth user" and "network abuser" are used to describe paying customers. With regard to the peering disputes, it's hardly surprising that their business partners are treated with the same attitude as their customers. Besides, if you cut off the customers and peers who are causing that saturation, then the existing peering links can support an infinite number of idle subscribers. The next phase is usage-based-billing which is kind of like having to pay a fine for using it, so they can artificially push the price point lower and hopefully get some more idle customers. That will help get the demand down and keep the infrastructure nice and idle. When you're paying for every cat video maybe you realize you can live without it instead. Everyone has been trained so well, they don't even flinch anymore when they hear about "over subscription", and they apologize for the people who are doing it to them. The restaurant analogy is incorrect - you can go to the restaurant next door if a place is busy, thus they have pressure to increase their capacity if they want to sell more meals. With broadband you can't go anywhere else, (for most people) there's only one restaurant, and there's a week long waiting list. If you don't like it, you're probably an abuser or excessive eater anyway. -Laszlo On May 16, 2014, at 5:34 PM, Scott Helms wrote: > Michael, > > No, its not too much to ask and any end user who has that kind of > requirement can order a business service to get symmetrical service but the > reality is that symmetrical service costs more and the vast majority of > customers don't use the upstream capacity they have today. I have personal > insight into about half a million devices and the percentage of people who > bump up against their upstream rate is less than 0.2%. I have the ability > to get data on another 10 million and the last time I checked their rates > were similar. > > This kind of question has been asked of operators since long before cable > companies could offer internet service. What happens if everyone in an > area use their telephone (cellular or land line) at the same time? A fast > busy or recorded "All circuits are busy message." Over subscription is a > fact of economics in virtually everything we do. By this logic restaurants > should be massively over built so that there is never a waiting line, > highways should always be a speed limit ride, and all of these things would > cost much more money than they do today. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > On Sun, Apr 27, 2014 at 8:21 PM, Michael Thomas wrote: > >> Scott Helms wrote: >> >>> Mark, >>> >>> Bandwidth use trends are actually increasingly asymmetical because of the >>> popularity of OTT video. >>> >> >> Until my other half decides to upload a video. >> >> Is it too much to ask for a bucket of bits that I can use in whichever >> direction happens >> to be needed at the moment? >> >> Mike >> From blake at ispn.net Fri May 16 18:47:53 2014 From: blake at ispn.net (Blake Hudson) Date: Fri, 16 May 2014 13:47:53 -0500 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> <537648D6.9070308@ispn.net> Message-ID: <53765D59.50406@ispn.net> Oh, I'm not proposing symmetrical connectivity at all. I'm just supporting the argument that in the context of this discussion I think it's silly for a residential ISP to purport themselves to be a neutral carrier of traffic and expect peering ratios to be symmetric when the overwhelming majority of what they're selling (and have been selling for over a decade) is asymmetric connectivity. Their traffic imbalance is, arguably, their own doing. How residential ISPs recoup costs (or simply increase revenue/profit) is another question entirely. I think the most insightful comment in this discussion was made by Mr. Rick Astley (I assume a pseudonym), when he states that ISPs have several options to increase revenue A) Increase price of their product, B) Implement usage restrictions, or C) Charge someone else/Make someone else your customer. I think he successfully argues that option C may be the best. As we've seen, the wireless market in the US went for option B. We've yet to see where the wireline market will go. Of course, the market would ideally keep ISPs' demands for revenue/profit in check and we'd all reach a satisfactory solution. One of the arguments, one I happen to support, in this thread is that there is not a free market for internet connectivity in many parts of the US. If there was, I believe Comcast would be focusing on how to provide a balance between the best product at the lowest cost and not on how they can monetize their paying customers in order to increase profits. I appreciate honesty; When a service provider advertises X Mbps Internet speeds, I expect they can deliver on their claims (to the whole Internet, and not just the portions of it they've decided). I understand congestion, overselling, etc. But choosing which portions of the internet work well and which don't is a lot more like censorship than service. --Blake Scott Helms wrote the following on 5/16/2014 12:39 PM: > Blake, > > You're absolutely correct. The world adapts to the reality that we > find ourselves in via normal market mechanics. The problem with > proposing that connectivity for residential customers should be more > symmetrical is that its expensive, which is why we as operators didn't > roll it out that way to start. We also don't see consumer demand for > symmetrical connections and with the decline in peer to peer file > sharing we've actually seen a decrease the ratio of used upstream > bandwidth (though not a decrease in absolute terms). > > I would like to deliver symmetrical bandwidth to all consumers just so > those few customers who need it today would have lower bills but > trying to justify that to our CFO without being able to point to an > increase in revenue either because of more revenue per sub or more > subs is a very tough task. I don't believe my situation is uncommon. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > On Fri, May 16, 2014 at 1:20 PM, Blake Hudson > wrote: > > Thanks for the insight Scott. I appreciate the experience and > point of view you're adding to this discussion (not just the > responses to me). While I might be playing the devil's advocate > here a bit, I think one could argue each of the points you've made > below. > > I do feel that general usage patterns are a reflection of the > technologies that have traditionally been available to consumers. > New uses and applications would be available to overcome hurdles > if the technologies had developed to be symmetrical. I'm not > saying that the asymmetrical choice was a bad one, but it was not > without consequences. If residential ISPs sell asymmetric > connections for decades, how can the ISP expect that application > developers would not take this into account when developing > applications? I don't think my application would be very > successful if it required X Mbps and half of my market did not > meet this requirement. Of course content/service providers are > going to tailor their services based around their market. > > --Blake > > Scott Helms wrote the following on 5/16/2014 12:06 PM: > > Blake, > > I might agree with your premise if weren't for a couple of items. > > 1) Very few consumers are walking around with a HD or 4K > camera today. > > 2) Most consumers who want to share video wouldn't know how > to host it themselves, which isn't an insurmountable issue but > is a big barrier to entry especially given the number of > NAT'ed connections. I think this is much more of a problem > than available bandwidth. > > 3) Most consumers who want to share videos seem to be > satisfied with sharing via one of the cloud services whether > that be YouTube (which was created originally for that use), > Vimeo, or one of the other legions of services like DropBox. > > 4) Finally, upstream bandwidth has increased on many/most > operators. I just ran the FCC's speedtest (mLab not Ookla) > and got 22 mbps on my residential cable internet service. I > subscribe to one of the major MSOs for a normal residential > package. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > On Fri, May 16, 2014 at 12:38 PM, Blake Hudson >> wrote: > > Certainly video is one of the most bandwidth intensive > applications. I don't deny that a < 1 Mbps video call is > both less > common and consumes less bandwidth than an 8Mbps HD stream. > However, if Americans had access to symmetric connections > capable > of reliably making HD video calls (they don't, in my > experience), > we might be seeing video calls as a common occurrence and > not a > novelty. I think the state of usage is a reflection on the > technology available. > > If the capability was available at an affordable price to > residential consumers, we might see those consumers stream > movies > or send videos from their home or mobile devices via their > internet connection directly to the recipient rather than > through > a centralized source like Disney, NetFlix, Youtube, etc. Video > sharing sites (like youtube, vimeo, etc) primary reason for > existence is due to the inability of the site's users to > distribute content themselves. One of the hurdles to > overcome in > video sharing is the lack of availability in affordable > internet > connectivity that is capable of sending video at reasonable > (greater than real time) speeds. > > --Blake > > Scott Helms wrote the following on 5/16/2014 11:02 AM: > > Blake, > > None of those applications come close to causing > symmetrical > traffic patterns and for many/most networks the upstream > connectivity has greatly improved. Anything related > to voice > is no more than 80 kbps per line, even if the SIP traffic > isn't trunked (less if it is because the signaling data is > shared). Document sharing is not being impinged, on my > residential account right now I've uploaded about 30 > documents > this morning including large PDFs and Power Point > presentations. > > Off site back up is one use that could drive traffic, > but I > don't believe that the limiting factor is bandwidth. We > looked at getting into that business and from what we > saw the > limiting factor was that most residential and SOHO > accounts > didn't want to pay enough to cover your storage & > management > costs. In our analysis the impact of bandwidth on the > consumer side adoption was basically zero. There is no > expectation that back ups run instantly. Having said > all of > that, even if hosted back up became wildly popular > would not > change the balance of power because OTT video is both > larger, > especially for HD streams, and used much more frequently. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > On Fri, May 16, 2014 at 11:53 AM, Blake Hudson > > > > > >>> wrote: > > > Jay Ashworth wrote the following on 5/16/2014 > 10:35 AM: > > ----- Original Message ----- > > From: "Mark Tinka" > > > > >>> > While that is true a lot of the time > (especially > for eyeball > networks), it is less so now due to social > media. > Social > media forces the use of symmetric > bandwidth (like > FTTH), > putting even more demand on the network, > > Oh yes; clearly, Twitter will be the end of L3. > > :-) > > Could you expand a bit, Mark on "Social media > forces > the use > of symmetric > bandwidth"? Which social media platform is it > that > you think > has a) > symmetrical flows that b) are big enough to > figure into > transit symmetry? > > Cheers, > -- jra > > Applications like Skype and Facetime (especially > conference calls) > would be one example where an application benefits > from > symmetric > (or asymmetric in favor of higher upload speed) > connectivity. > Cloud office applications like storage of documents, > email, and > IVR telephony also benefit from symmetrical > connectivity. > Off-site > backup software is another great example. Most > residential > connections are ill suited for this. I believe these > applications > (and derivatives) would be more popular today if the > connectivity > was available. > > --Blake > > > > > > From khelms at zcorum.com Fri May 16 18:51:55 2014 From: khelms at zcorum.com (Scott Helms) Date: Fri, 16 May 2014 14:51:55 -0400 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <5D3ECC3F-8BB5-4F2E-9706-E0B8B9FFA07C@heliacal.net> References: <201405161702.03926.mark.tinka@seacom.mu> <201405161726.18601.mark.tinka@seacom.mu> <535D9F07.1000808@mtcc.com> <5D3ECC3F-8BB5-4F2E-9706-E0B8B9FFA07C@heliacal.net> Message-ID: Lazlo, You're correct that some applications are being restricted, but AFAIK in North America they are all being restricted for quite valid network management reasons. While back in the day I ran Sendmail and sometimes qmail on my home connection I was also responsible with my mail server and more importantly the world was different. The threat from an open relay or mail server with a compromise is much higher, in part because the speeds are higher, but also because the attackers are more sophisticated and the hardware the mail server is running on is much more powerful. P2P is _not_ being blocked legally anywhere and if you believe that it is then you should complain to the FCC in the US or the CRTC in Canada. Running a DNS or NTP server that's open to the Internet on a home connection should NOT be allowed. I'm sorry if you're one of the few people who can run those services effectively and safely (just like SMTP) but the vast majority of customers can't and in most cases they aren't running them intentionally. I won't get into marketing, that's not what I do and I agree that unlimited seems to mean something other than the way I understand it but that's no different from unlimited telephone service, all you can eat buffets, or just about anywhere else you can see the word "unlimited" or all in marketing. I'd also like to see much more competition in the market and that's one the things I work to accomplish. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, May 16, 2014 at 2:38 PM, Laszlo Hanyecz wrote: > I'd just like to point out that a lot of people are in fact using their > upstream capability, and the operators always throw a fit and try to cut > off specific applications to force it back into the idle state. For > example P2P things like torrents and most recently the open NTP and DNS > servers. How about SMTP? Not sure about you guys but my local broadband > ISP has cut me off and told me that my 'unlimited internet' is in fact > limited. The reality is that those people who are not using it (99.8%?) > are just being ripped off - paying for something they were told they need, > thinking that it's there when they want it, then getting cut off when they > actually try to use it. > > It's not like whining about it here will change anything, but the prices > are severely distorted. Triple play packages are designed to force people > to pay for stuff they don't need or want - distorting the price of a > service hoping to recover it elsewhere, then if the gamble doesn't pan out, > the customer loses again. The whole model is based on people buying stuff > that they won't actually come to collect, so then you can sell it an > infinite number of times. The people who do try to collect what was sold > to them literally end up getting called names and cut off - terms like > "excessive bandwidth user" and "network abuser" are used to describe paying > customers. With regard to the peering disputes, it's hardly surprising > that their business partners are treated with the same attitude as their > customers. Besides, if you cut off the customers and peers who are causing > that saturation, then the existing peering links can support an infinite > number of idle subscribers. The next phase is usage-based-billing which is > kind of like having to pay a fine for using it, so they can artificially > push the price point lower and hopefully get some more idle customers. > That will help get the demand down and keep the infrastructure nice and > idle. When you're paying for every cat video maybe you realize you can > live without it instead. > > Everyone has been trained so well, they don't even flinch anymore when > they hear about "over subscription", and they apologize for the people who > are doing it to them. The restaurant analogy is incorrect - you can go to > the restaurant next door if a place is busy, thus they have pressure to > increase their capacity if they want to sell more meals. With broadband > you can't go anywhere else, (for most people) there's only one restaurant, > and there's a week long waiting list. If you don't like it, you're > probably an abuser or excessive eater anyway. > > -Laszlo > > > On May 16, 2014, at 5:34 PM, Scott Helms wrote: > > > Michael, > > > > No, its not too much to ask and any end user who has that kind of > > requirement can order a business service to get symmetrical service but > the > > reality is that symmetrical service costs more and the vast majority of > > customers don't use the upstream capacity they have today. I have > personal > > insight into about half a million devices and the percentage of people > who > > bump up against their upstream rate is less than 0.2%. I have the > ability > > to get data on another 10 million and the last time I checked their rates > > were similar. > > > > This kind of question has been asked of operators since long before cable > > companies could offer internet service. What happens if everyone in an > > area use their telephone (cellular or land line) at the same time? A > fast > > busy or recorded "All circuits are busy message." Over subscription is a > > fact of economics in virtually everything we do. By this logic > restaurants > > should be massively over built so that there is never a waiting line, > > highways should always be a speed limit ride, and all of these things > would > > cost much more money than they do today. > > > > > > Scott Helms > > Vice President of Technology > > ZCorum > > (678) 507-5000 > > -------------------------------- > > http://twitter.com/kscotthelms > > -------------------------------- > > > > > > On Sun, Apr 27, 2014 at 8:21 PM, Michael Thomas wrote: > > > >> Scott Helms wrote: > >> > >>> Mark, > >>> > >>> Bandwidth use trends are actually increasingly asymmetical because of > the > >>> popularity of OTT video. > >>> > >> > >> Until my other half decides to upload a video. > >> > >> Is it too much to ask for a bucket of bits that I can use in whichever > >> direction happens > >> to be needed at the moment? > >> > >> Mike > >> > > From morrowc.lists at gmail.com Fri May 16 18:52:31 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 16 May 2014 14:52:31 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <53765D59.50406@ispn.net> References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> <537648D6.9070308@ispn.net> <53765D59.50406@ispn.net> Message-ID: On Fri, May 16, 2014 at 2:47 PM, Blake Hudson wrote: > in the context of this discussion I think it's silly for a residential ISP > to purport themselves to be a neutral carrier of traffic and expect peering > ratios to be symmetric is 'symmetric traffic ratios' even relevant though? Peering is about offsetting costs, right? it might not be important that the ratio be 1:1 or 2:1... or even 10:1, if it's going to cost you 20x to get the traffic over longer/transit/etc paths... or if you have to build into some horrific location(s) to access the content in question. Harping on symmetric ratios seems very 1990... and not particularly germaine to the conversation at hand. From khelms at zcorum.com Fri May 16 18:57:39 2014 From: khelms at zcorum.com (Scott Helms) Date: Fri, 16 May 2014 14:57:39 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <53765D59.50406@ispn.net> References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> <537648D6.9070308@ispn.net> <53765D59.50406@ispn.net> Message-ID: Blake, I'm not sure what the relationship between what an access network sells has to do with how their peering is done. I realize that everyone's favorite target is Comcast right now, but would anyone bat an eye over AT&T making the same requirement since they have much more in the way of transit traffic? I don't think anyone forced Level 3 into their peering agreement with Comcast and it was (roughly) symmetrical for years before Level 3 was contracted by Netflix. Shouldn't Level 3 gone to Comcast and told them they needed to change their peering or get a different contract? Why was Cogent able to maintain (roughly) symmetrical traffic with Comcast when they were the primary path for Netflix to Comcast users? Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, May 16, 2014 at 2:47 PM, Blake Hudson wrote: > Oh, I'm not proposing symmetrical connectivity at all. I'm just supporting > the argument that in the context of this discussion I think it's silly for > a residential ISP to purport themselves to be a neutral carrier of traffic > and expect peering ratios to be symmetric when the overwhelming majority of > what they're selling (and have been selling for over a decade) is > asymmetric connectivity. Their traffic imbalance is, arguably, their own > doing. > > How residential ISPs recoup costs (or simply increase revenue/profit) is > another question entirely. I think the most insightful comment in this > discussion was made by Mr. Rick Astley (I assume a pseudonym), when he > states that ISPs have several options to increase revenue A) Increase price > of their product, B) Implement usage restrictions, or C) Charge someone > else/Make someone else your customer. I think he successfully argues that > option C may be the best. As we've seen, the wireless market in the US went > for option B. We've yet to see where the wireline market will go. > > Of course, the market would ideally keep ISPs' demands for revenue/profit > in check and we'd all reach a satisfactory solution. One of the arguments, > one I happen to support, in this thread is that there is not a free market > for internet connectivity in many parts of the US. If there was, I believe > Comcast would be focusing on how to provide a balance between the best > product at the lowest cost and not on how they can monetize their paying > customers in order to increase profits. I appreciate honesty; When a > service provider advertises X Mbps Internet speeds, I expect they can > deliver on their claims (to the whole Internet, and not just the portions > of it they've decided). I understand congestion, overselling, etc. But > choosing which portions of the internet work well and which don't is a lot > more like censorship than service. > > --Blake > From blake at ispn.net Fri May 16 19:11:56 2014 From: blake at ispn.net (Blake Hudson) Date: Fri, 16 May 2014 14:11:56 -0500 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> <537648D6.9070308@ispn.net> <53765D59.50406@ispn.net> Message-ID: <537662FC.20704@ispn.net> Christopher Morrow wrote the following on 5/16/2014 1:52 PM: > On Fri, May 16, 2014 at 2:47 PM, Blake Hudson wrote: >> in the context of this discussion I think it's silly for a residential ISP >> to purport themselves to be a neutral carrier of traffic and expect peering >> ratios to be symmetric > is 'symmetric traffic ratios' even relevant though? Peering is about > offsetting costs, right? it might not be important that the ratio be > 1:1 or 2:1... or even 10:1, if it's going to cost you 20x to get the > traffic over longer/transit/etc paths... or if you have to build into > some horrific location(s) to access the content in question. > > Harping on symmetric ratios seems very 1990... and not particularly > germaine to the conversation at hand. I agree about the term being passe ...and that it never applied to ISPs ...and that peering is about cost reduction, reliability, and performance. It seems to me that many CDNs or content providers want to setup peering relationships and are willing to do so at a cost to them in order to bypass "the internet middle men". But I mention traffic ratios because some folks in this discussion seem to be using it as justification for not peering. But hey, why peer at little or no cost if they can instead hold out and possibly peer at a negative cost? --Blake From james.cutler at consultant.com Fri May 16 19:14:00 2014 From: james.cutler at consultant.com (James R Cutler) Date: Fri, 16 May 2014 15:14:00 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> <537648D6.9070308@ispn.net> <53765D59.50406@ispn.net> Message-ID: All this talk about symmetry and asymmetry is interesting. Has anyone actually quantified how much congestion is due to buffer bloat which is, in turn, exacerbated by asymmetric connections? James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu -------------- 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 mpetach at netflight.com Fri May 16 19:15:15 2014 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 16 May 2014 12:15:15 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> <537648D6.9070308@ispn.net> <53765D59.50406@ispn.net> Message-ID: On Fri, May 16, 2014 at 11:52 AM, Christopher Morrow < morrowc.lists at gmail.com> wrote: > On Fri, May 16, 2014 at 2:47 PM, Blake Hudson wrote: > > in the context of this discussion I think it's silly for a residential > ISP > > to purport themselves to be a neutral carrier of traffic and expect > peering > > ratios to be symmetric > > is 'symmetric traffic ratios' even relevant though? Peering is about > offsetting costs, right? it might not be important that the ratio be > 1:1 or 2:1... or even 10:1, if it's going to cost you 20x to get the > traffic over longer/transit/etc paths... or if you have to build into > some horrific location(s) to access the content in question. > > Harping on symmetric ratios seems very 1990... and not particularly > germaine to the conversation at hand. > > Traffic asymmetry across peering connections was what lit the fuse on this whole powder keg, if I understand correctly; at the point the traffic went asymmetric, the refusals to augment capacity kicked in, and congestion became a problem. I've seen the same thing; pretty much every rejection is based on ratio issues, even when offering to cold-potato haul the traffic to the home market for the users. If the refusals hinged on any other clause of the peering requirements, you'd be right; but at the moment, that's the flag networks are waving around as their speedbump-du-jour. So, it may be very "1990", but unfortunately that seems to be the year many people in the industry are mentally stuck in. :( Matt From mpetach at netflight.com Fri May 16 19:21:57 2014 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 16 May 2014 12:21:57 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> <537648D6.9070308@ispn.net> <53765D59.50406@ispn.net> Message-ID: On Fri, May 16, 2014 at 12:14 PM, James R Cutler < james.cutler at consultant.com> wrote: > > All this talk about symmetry and asymmetry is interesting. > > Has anyone actually quantified how much congestion is due to buffer bloat > which is, in turn, exacerbated by asymmetric connections? > > > James R. Cutler > James.cutler at consultant.com > PGP keys at http://pgp.mit.edu > I think you might have the cart before the horse. If there's no congestion on a peering link, buffering doesn't come into play, at least not within the transport infrastructure. We're not talking congestion on the last mile side, we're looking at congestion on the interconnect links between networks, typically 10G or 100G ports. Unless you're running those links near or at capacity, buffering should be a complete non-issue. And if you're running those links at capacity, then the congestion is due to too much traffic, period, not to the size of buffers involved on either side of the link. ^_^; Thanks! Matt From khelms at zcorum.com Fri May 16 19:23:58 2014 From: khelms at zcorum.com (Scott Helms) Date: Fri, 16 May 2014 15:23:58 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> <537648D6.9070308@ispn.net> <53765D59.50406@ispn.net> Message-ID: Matthew, There is a difference between what should be philosophically and what happened with Level 3 which is a contractual issue. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, May 16, 2014 at 3:15 PM, Matthew Petach wrote: > On Fri, May 16, 2014 at 11:52 AM, Christopher Morrow < > morrowc.lists at gmail.com> wrote: > > > On Fri, May 16, 2014 at 2:47 PM, Blake Hudson wrote: > > > in the context of this discussion I think it's silly for a residential > > ISP > > > to purport themselves to be a neutral carrier of traffic and expect > > peering > > > ratios to be symmetric > > > > is 'symmetric traffic ratios' even relevant though? Peering is about > > offsetting costs, right? it might not be important that the ratio be > > 1:1 or 2:1... or even 10:1, if it's going to cost you 20x to get the > > traffic over longer/transit/etc paths... or if you have to build into > > some horrific location(s) to access the content in question. > > > > Harping on symmetric ratios seems very 1990... and not particularly > > germaine to the conversation at hand. > > > > > Traffic asymmetry across peering connections > was what lit the fuse on this whole powder keg, > if I understand correctly; at the point the traffic > went asymmetric, the refusals to augment > capacity kicked in, and congestion became > a problem. > > I've seen the same thing; pretty much every > rejection is based on ratio issues, even when > offering to cold-potato haul the traffic to the > home market for the users. > > If the refusals hinged on any other clause > of the peering requirements, you'd be right; > but at the moment, that's the flag networks > are waving around as their speedbump-du-jour. > So, it may be very "1990", but unfortunately > that seems to be the year many people in > the industry are mentally stuck in. :( > > Matt > From mark.tinka at seacom.mu Fri May 16 19:25:30 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 16 May 2014 21:25:30 +0200 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> Message-ID: <201405162125.33834.mark.tinka@seacom.mu> On Friday, May 16, 2014 05:35:39 PM Jay Ashworth wrote: > Could you expand a bit, Mark on "Social media forces the > use of symmetric bandwidth"? Which social media > platform is it that you think has a) symmetrical flows > that b) are big enough to figure into transit symmetry? What we saw with FTTH deployments is that customers uploaded more videos and photos to Youtube, Facebook, MySpace, e.t.c. They didn't do this on ADSL as much (it's too frustrating). When that caught on, customers started buying online backup services - synchronizing backups of their home or office computers to remote backup infrastructure. Again, they never did this with ADSL. What we learned: don't take it for granted that you will always know what your customers (or the content providers who serve them) will do with the bandwidth. If they have it, expect the worst, and plan for it as best you can. 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 morrowc.lists at gmail.com Fri May 16 19:30:21 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 16 May 2014 15:30:21 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> <537648D6.9070308@ispn.net> <53765D59.50406@ispn.net> Message-ID: On Fri, May 16, 2014 at 3:15 PM, Matthew Petach wrote: > > > > On Fri, May 16, 2014 at 11:52 AM, Christopher Morrow > wrote: >> >> On Fri, May 16, 2014 at 2:47 PM, Blake Hudson wrote: >> > in the context of this discussion I think it's silly for a residential >> > ISP >> > to purport themselves to be a neutral carrier of traffic and expect >> > peering >> > ratios to be symmetric >> >> is 'symmetric traffic ratios' even relevant though? Peering is about >> offsetting costs, right? it might not be important that the ratio be >> 1:1 or 2:1... or even 10:1, if it's going to cost you 20x to get the >> traffic over longer/transit/etc paths... or if you have to build into >> some horrific location(s) to access the content in question. >> >> Harping on symmetric ratios seems very 1990... and not particularly >> germaine to the conversation at hand. >> > > Traffic asymmetry across peering connections > was what lit the fuse on this whole powder keg, > if I understand correctly; at the point the traffic > went asymmetric, the refusals to augment > capacity kicked in, and congestion became > a problem. Is it that? or is it that planning at some ISP pair had a '6 months to upgrade' regularly penciled in, then 'all of a sudden' their links were filling up faster than every 6months and... now they are 1x or 2x upgrade cycles behind? I imagine that up to a point upgrading a router that does only 'peering' (SFP) is 'easy', but at some step function of upgrades on the edge ports you need to provision more backhaul and more core and probably upgrade the link types and the chassis and ... At some ISPs this process involves more than 1 dude/group. So coordination and budget issues and scheduling ... become a bit harder. Adjusting to the new reality of 'you need to plan for pipe filling more often, increase upgrade cycle crank speed!' seems like at least one problem, to me at least. It's really hard to tell what's upsetting people about this whole topic :( There's a mix of 'my access link blows' to 'isps should peer better and for freer' and a bunch of other stuff all mixed in the middle :( > I've seen the same thing; pretty much every > rejection is based on ratio issues, even when > offering to cold-potato haul the traffic to the > home market for the users. yes, welp... it's often rough to get folk who want to think in terms of apples to suddenly thing in terms of the new best fruit 'acai berry'. Especially at large and entrenched organizations. > If the refusals hinged on any other clause > of the peering requirements, you'd be right; > but at the moment, that's the flag networks > are waving around as their speedbump-du-jour. sure, it's also super easy for them to do this, see entrenched org comment above. it seems to me that the point of peering is not 'ratio or bust' but 'mutual benefit'. If a skewed ratio of 100:1 in a local market still is cheaper than 'backhaul that traffic from LHR to SFO' there's mutual benefit and a reason to peer. I understand that this is a bit of a rosy landscape I'm painting, but... > So, it may be very "1990", but unfortunately > that seems to be the year many people in > the industry are mentally stuck in. :( oh, entrenched. I see. thanks! -chris > From morrowc.lists at gmail.com Fri May 16 19:33:11 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 16 May 2014 15:33:11 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <537662FC.20704@ispn.net> References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> <537648D6.9070308@ispn.net> <53765D59.50406@ispn.net> <537662FC.20704@ispn.net> Message-ID: On Fri, May 16, 2014 at 3:11 PM, Blake Hudson wrote: > > Christopher Morrow wrote the following on 5/16/2014 1:52 PM: > >> On Fri, May 16, 2014 at 2:47 PM, Blake Hudson wrote: >>> >>> in the context of this discussion I think it's silly for a residential >>> ISP >>> to purport themselves to be a neutral carrier of traffic and expect >>> peering >>> ratios to be symmetric >> >> is 'symmetric traffic ratios' even relevant though? Peering is about >> offsetting costs, right? it might not be important that the ratio be >> 1:1 or 2:1... or even 10:1, if it's going to cost you 20x to get the >> traffic over longer/transit/etc paths... or if you have to build into >> some horrific location(s) to access the content in question. >> >> Harping on symmetric ratios seems very 1990... and not particularly >> germaine to the conversation at hand. > > I agree about the term being passe ...and that it never applied to ISPs > ...and that peering is about cost reduction, reliability, and performance. ok. > It seems to me that many CDNs or content providers want to setup peering > relationships and are willing to do so at a cost to them in order to bypass > "the internet middle men". But I mention traffic ratios because some folks 'the internet middle men' - is really, it seems to me, 'people I have no business relationship with'. There's also no way to control the capacity planning process with these middle-men, right? Some AS in the middle of my 3-AS-way conversation isn't someone I can capacity plan with :( -chris > in this discussion seem to be using it as justification for not peering. But > hey, why peer at little or no cost if they can instead hold out and possibly > peer at a negative cost? > > --Blake From mark.tinka at seacom.mu Fri May 16 19:40:32 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 16 May 2014 21:40:32 +0200 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: References: <201405161726.18601.mark.tinka@seacom.mu> Message-ID: <201405162140.35853.mark.tinka@seacom.mu> On Friday, May 16, 2014 05:45:06 PM Scott Helms wrote: > Bandwidth use trends are actually increasingly > asymmetical because of the popularity of OTT video. > > Social media, even with video uploading, simply doesn't > generate that much traffic per session. Our experience showed that there is a direct co-relation between the lack of traffic in the upstream direction and poor upload bandwidth (primarily, due to asymmetric tech. such as ADSL), e.g., because of the ADSL I have at home (512Kbps up, 4Mbps down), I generally do not send very large e-mails when working from home; nor do I use my laptop for remote router/switch updates as the software images are a nightmare to upload. And yes, there is a larger proportion of downstream traffic than there is upstream traffic pretty much most of the time (even with symmetric links). However, with symmetry, upstream traffic will increase significantly as customers realize it is now available. One of the use-cases we thought about when deploying an FTTH backbone was having remote PVR's. So rather than record and save linear Tv programming on the STB, record and save it in the network. This could only be done with symmetric bandwidth. 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 khelms at zcorum.com Fri May 16 19:44:55 2014 From: khelms at zcorum.com (Scott Helms) Date: Fri, 16 May 2014 15:44:55 -0400 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <201405162125.33834.mark.tinka@seacom.mu> References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <201405162125.33834.mark.tinka@seacom.mu> Message-ID: Mark, I don't think that anyone disputes that when you improve the upstream you do get an uptick in usage in that direction. What I take issue with is the notion that the upstream is anything like downstream even when the capacity is there. Upstream on ADSL is horribad, especially the first generations (g.lite and g.dmt). Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, May 16, 2014 at 3:25 PM, Mark Tinka wrote: > On Friday, May 16, 2014 05:35:39 PM Jay Ashworth wrote: > > > Could you expand a bit, Mark on "Social media forces the > > use of symmetric bandwidth"? Which social media > > platform is it that you think has a) symmetrical flows > > that b) are big enough to figure into transit symmetry? > > What we saw with FTTH deployments is that customers uploaded > more videos and photos to Youtube, Facebook, MySpace, e.t.c. > They didn't do this on ADSL as much (it's too frustrating). > > When that caught on, customers started buying online backup > services - synchronizing backups of their home or office > computers to remote backup infrastructure. Again, they never > did this with ADSL. > > What we learned: don't take it for granted that you will > always know what your customers (or the content providers > who serve them) will do with the bandwidth. If they have it, > expect the worst, and plan for it as best you can. > > Mark. > From mike at mtcc.com Fri May 16 19:46:29 2014 From: mike at mtcc.com (Michael Thomas) Date: Fri, 16 May 2014 12:46:29 -0700 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: References: <201405161702.03926.mark.tinka@seacom.mu> <201405161726.18601.mark.tinka@seacom.mu> <535D9F07.1000808@mtcc.com> Message-ID: <53766B15.8000504@mtcc.com> Scott Helms wrote: > Michael, > > No, its not too much to ask and any end user who has that kind of > requirement can order a business service to get symmetrical service but > the reality is that symmetrical service costs more and the vast majority > of customers don't use the upstream capacity they have today. I have > personal insight into about half a million devices and the percentage of > people who bump up against their upstream rate is less than 0.2%. I > have the ability to get data on another 10 million and the last time I > checked their rates were similar. I've just been on the losing end of yet another piece of why crappy upstream bandwidth sucks: Mavericks seems to have decided that my other half's imovie library really, really ought to be uploaded to iCloud (without asking, ftw). I can and should be pissed at Apple for doing such a wrongheaded thing, but the fact is that my upstream bandwidth was saturated for hours and days and it was extremely difficult to figure out why. I doubt I'm alone. Better upstream bandwidth would have at least made the pain period shorter. Mike From mike at mtcc.com Fri May 16 19:48:54 2014 From: mike at mtcc.com (Michael Thomas) Date: Fri, 16 May 2014 12:48:54 -0700 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <201405162140.35853.mark.tinka@seacom.mu> References: <201405161726.18601.mark.tinka@seacom.mu> <201405162140.35853.mark.tinka@seacom.mu> Message-ID: <53766BA6.9090808@mtcc.com> Mark Tinka wrote: > One of the use-cases we thought about when deploying an FTTH > backbone was having remote PVR's. So rather than record and > save linear Tv programming on the STB, record and save it in > the network. This could only be done with symmetric > bandwidth. > Isn't this already the case with Dishtv and their partnership with Sling? I'm pretty sure it's streaming it direct from my home dvr. Mike From khelms at zcorum.com Fri May 16 19:50:24 2014 From: khelms at zcorum.com (Scott Helms) Date: Fri, 16 May 2014 15:50:24 -0400 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <53766B15.8000504@mtcc.com> References: <201405161702.03926.mark.tinka@seacom.mu> <201405161726.18601.mark.tinka@seacom.mu> <535D9F07.1000808@mtcc.com> <53766B15.8000504@mtcc.com> Message-ID: Mike, In my experience you're not alone, just in a really tiny group. As I said I have direct eyeballs on ~500k devices and the ability to see another 10 million anytime I want and the percentage of people who cap their upstream in both of those sample groups for more than 15 minutes (over the last 3 years) is about 0.2%. Interestingly if a customer does it once they have about a 70% chance of doing it regularly. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, May 16, 2014 at 3:46 PM, Michael Thomas wrote: > Scott Helms wrote: > >> Michael, >> >> No, its not too much to ask and any end user who has that kind of >> requirement can order a business service to get symmetrical service but the >> reality is that symmetrical service costs more and the vast majority of >> customers don't use the upstream capacity they have today. I have personal >> insight into about half a million devices and the percentage of people who >> bump up against their upstream rate is less than 0.2%. I have the ability >> to get data on another 10 million and the last time I checked their rates >> were similar. >> > > I've just been on the losing end of yet another piece of why crappy > upstream > bandwidth sucks: Mavericks seems to have decided that my other half's > imovie > library really, really ought to be uploaded to iCloud (without asking, > ftw). > > I can and should be pissed at Apple for doing such a wrongheaded thing, but > the fact is that my upstream bandwidth was saturated for hours and days > and it > was extremely difficult to figure out why. I doubt I'm alone. > > Better upstream bandwidth would have at least made the pain period shorter. > > Mike > From mike at mtcc.com Fri May 16 20:06:58 2014 From: mike at mtcc.com (Michael Thomas) Date: Fri, 16 May 2014 13:06:58 -0700 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: References: <201405161702.03926.mark.tinka@seacom.mu> <201405161726.18601.mark.tinka@seacom.mu> <535D9F07.1000808@mtcc.com> <53766B15.8000504@mtcc.com> Message-ID: <53766FE2.1030209@mtcc.com> Scott Helms wrote: > Mike, > > In my experience you're not alone, just in a really tiny group. As I > said I have direct eyeballs on ~500k devices and the ability to see > another 10 million anytime I want and the percentage of people who cap > their upstream in both of those sample groups for more than 15 minutes > (over the last 3 years) is about 0.2%. Interestingly if a customer does > it once they have about a 70% chance of doing it regularly. Well, given Sling, Dropbox, iCloud, pervasive video calls (you have heard about webrtc, yes? 24/7 babycams!), youtube, etc, etc, I won't be a "tiny group" for long. Mike From khelms at zcorum.com Fri May 16 20:16:06 2014 From: khelms at zcorum.com (Scott Helms) Date: Fri, 16 May 2014 16:16:06 -0400 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <53766FE2.1030209@mtcc.com> References: <201405161702.03926.mark.tinka@seacom.mu> <201405161726.18601.mark.tinka@seacom.mu> <535D9F07.1000808@mtcc.com> <53766B15.8000504@mtcc.com> <53766FE2.1030209@mtcc.com> Message-ID: I think you will, all of those things have been around for a long time (well, except for pervasive video calls, which I think is vapor) and none generate the kind of traffic it takes to congest a decent link. Most of the DOCSIS systems I've worked with are running at least 6 mbps upstreams and many are well into the double digits. My current connection (tested this morning) is about 22 mbps. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, May 16, 2014 at 4:06 PM, Michael Thomas wrote: > Scott Helms wrote: > >> Mike, >> >> In my experience you're not alone, just in a really tiny group. As I >> said I have direct eyeballs on ~500k devices and the ability to see another >> 10 million anytime I want and the percentage of people who cap their >> upstream in both of those sample groups for more than 15 minutes (over the >> last 3 years) is about 0.2%. Interestingly if a customer does it once they >> have about a 70% chance of doing it regularly. >> > > Well, given Sling, Dropbox, iCloud, pervasive video calls (you have heard > about webrtc, yes? > 24/7 babycams!), youtube, etc, etc, I won't be a "tiny group" for long. > > Mike > From mike at mtcc.com Fri May 16 20:22:21 2014 From: mike at mtcc.com (Michael Thomas) Date: Fri, 16 May 2014 13:22:21 -0700 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: References: <201405161702.03926.mark.tinka@seacom.mu> <201405161726.18601.mark.tinka@seacom.mu> <535D9F07.1000808@mtcc.com> <53766B15.8000504@mtcc.com> <53766FE2.1030209@mtcc.com> Message-ID: <5376737D.6070908@mtcc.com> Scott Helms wrote: > I think you will, all of those things have been around for a long time > (well, except for pervasive video calls, which I think is vapor) and > none generate the kind of traffic it takes to congest a decent link. > Most of the DOCSIS systems I've worked with are running at least 6 mbps > upstreams and many are well into the double digits. My current > connection (tested this morning) is about 22 mbps. Um, no it's not vapor. Webrtc is quite real, and the barrier to implementation for any random web site is weeks, not years as was the case before. I just saw this that you wrote: > 1) Very few consumers are walking around with a HD or 4K camera today. In the US, we just surpassed 1/2 of the population who have that capability, iirc. They call them phones nowadays. Mike > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > On Fri, May 16, 2014 at 4:06 PM, Michael Thomas > wrote: > > Scott Helms wrote: > > Mike, > > In my experience you're not alone, just in a really tiny group. > As I said I have direct eyeballs on ~500k devices and the > ability to see another 10 million anytime I want and the > percentage of people who cap their upstream in both of those > sample groups for more than 15 minutes (over the last 3 years) > is about 0.2%. Interestingly if a customer does it once they > have about a 70% chance of doing it regularly. > > > Well, given Sling, Dropbox, iCloud, pervasive video calls (you have > heard about webrtc, yes? > 24/7 babycams!), youtube, etc, etc, I won't be a "tiny group" for long. > > Mike > > From khelms at zcorum.com Fri May 16 20:27:15 2014 From: khelms at zcorum.com (Scott Helms) Date: Fri, 16 May 2014 16:27:15 -0400 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <5376737D.6070908@mtcc.com> References: <201405161702.03926.mark.tinka@seacom.mu> <201405161726.18601.mark.tinka@seacom.mu> <535D9F07.1000808@mtcc.com> <53766B15.8000504@mtcc.com> <53766FE2.1030209@mtcc.com> <5376737D.6070908@mtcc.com> Message-ID: Michael, I didn't claim Webrtc is vapor, I claim that pervasive video calling is vapor. Further, even if that prediction is wrong pervasive video calling isn't enough even if 100% of users adopt it to swing the need for symmetrical bandwidth. An average Skype/Google Hangout/Apple is less than 400 kbps at peak and averages something like 150 kbps. http://www.digitalsociety.org/2010/08/iphone-facetime-bandwidth-gets-measured/ Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, May 16, 2014 at 4:22 PM, Michael Thomas wrote: > Scott Helms wrote: > >> I think you will, all of those things have been around for a long time >> (well, except for pervasive video calls, which I think is vapor) and none >> generate the kind of traffic it takes to congest a decent link. Most of >> the DOCSIS systems I've worked with are running at least 6 mbps upstreams >> and many are well into the double digits. My current connection (tested >> this morning) is about 22 mbps. >> > > Um, no it's not vapor. Webrtc is quite real, and the barrier to > implementation > for any random web site is weeks, not years as was the case before. > > I just saw this that you wrote: > > > 1) Very few consumers are walking around with a HD or 4K camera > today. > > In the US, we just surpassed 1/2 of the population who have that > capability, iirc. They > call them phones nowadays. > > Mike > > >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> On Fri, May 16, 2014 at 4:06 PM, Michael Thomas > mike at mtcc.com>> wrote: >> >> Scott Helms wrote: >> >> Mike, >> >> In my experience you're not alone, just in a really tiny group. >> As I said I have direct eyeballs on ~500k devices and the >> ability to see another 10 million anytime I want and the >> percentage of people who cap their upstream in both of those >> sample groups for more than 15 minutes (over the last 3 years) >> is about 0.2%. Interestingly if a customer does it once they >> have about a 70% chance of doing it regularly. >> >> >> Well, given Sling, Dropbox, iCloud, pervasive video calls (you have >> heard about webrtc, yes? >> 24/7 babycams!), youtube, etc, etc, I won't be a "tiny group" for >> long. >> >> Mike >> >> >> > From jared at puck.nether.net Fri May 16 20:30:10 2014 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 16 May 2014 16:30:10 -0400 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <5376737D.6070908@mtcc.com> References: <201405161702.03926.mark.tinka@seacom.mu> <201405161726.18601.mark.tinka@seacom.mu> <535D9F07.1000808@mtcc.com> <53766B15.8000504@mtcc.com> <53766FE2.1030209@mtcc.com> <5376737D.6070908@mtcc.com> Message-ID: <2B344C91-CC64-4F90-B8A3-98DBB7EA930E@puck.nether.net> On May 16, 2014, at 4:22 PM, Michael Thomas wrote: > In the US, we just surpassed 1/2 of the population who have that capability, iirc. They > call them phones nowadays. Many of them have native IPv6 as well, this also hasn't gotten significant number of legacy/incumbents to deploy yet either. It seems Facebook/LTE are the killer apps for v6. http://www.internetsociety.org/deploy360/wp-content/uploads/2014/04/WorldIPv6Congress-IPv6_LH-v2.pdf Like all things there are leaders and followers and the long-tail. - Jared From mpalmer at hezmatt.org Fri May 16 20:54:56 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sat, 17 May 2014 06:54:56 +1000 Subject: Rick Astley, Network Engineer [was: Observations of an Internet Middleman (Level3)] In-Reply-To: <53765D59.50406@ispn.net> References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> <537648D6.9070308@ispn.net> <53765D59.50406@ispn.net> Message-ID: <20140516205456.GC30271@hezmatt.org> On Fri, May 16, 2014 at 01:47:53PM -0500, Blake Hudson wrote: > Mr. Rick Astley (I assume a pseudonym) Why would you assume that? Mr. Astley has long been a champion of solid network engineering, and even net neutrality... he's long said that he's "Never gonna drop a route, never gonna fill a link, never gonna turn around and congest you." - Matt From wbailey at satelliteintelligencegroup.com Fri May 16 21:07:50 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 16 May 2014 21:07:50 +0000 Subject: Rick Astley, Network Engineer [was: Observations of an Internet Middleman (Level3)] In-Reply-To: <20140516205456.GC30271@hezmatt.org> References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> <537648D6.9070308@ispn.net> <53765D59.50406@ispn.net> <20140516205456.GC30271@hezmatt.org> Message-ID: Duh. On 5/16/14, 1:54 PM, "Matt Palmer" wrote: >On Fri, May 16, 2014 at 01:47:53PM -0500, Blake Hudson wrote: >> Mr. Rick Astley (I assume a pseudonym) > >Why would you assume that? Mr. Astley has long been a champion of solid >network engineering, and even net neutrality... he's long said that he's >"Never gonna drop a route, never gonna fill a link, never gonna turn >around >and congest you." > >- Matt > From blake at ispn.net Fri May 16 21:11:30 2014 From: blake at ispn.net (Blake Hudson) Date: Fri, 16 May 2014 16:11:30 -0500 Subject: Rick Astley, Network Engineer [was: Observations of an Internet Middleman (Level3)] In-Reply-To: <20140516205456.GC30271@hezmatt.org> References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> <537648D6.9070308@ispn.net> <53765D59.50406@ispn.net> <20140516205456.GC30271@hezmatt.org> Message-ID: <53767F02.4050207@ispn.net> Matt Palmer wrote the following on 5/16/2014 3:54 PM: > On Fri, May 16, 2014 at 01:47:53PM -0500, Blake Hudson wrote: >> Mr. Rick Astley (I assume a pseudonym) > Why would you assume that? Mr. Astley has long been a champion of solid > network engineering, and even net neutrality... he's long said that he's > "Never gonna drop a route, never gonna fill a link, never gonna turn around > and congest you." > > - Matt > Oh that made me laugh out loud. Thanks for that. From cidr-report at potaroo.net Fri May 16 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 May 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201405162200.s4GM00dY067273@wattle.apnic.net> This report has been generated at Fri May 16 21:13:53 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 09-05-14 499630 282328 10-05-14 499734 279956 11-05-14 499614 279852 12-05-14 499793 280018 13-05-14 500061 280153 14-05-14 500728 281450 15-05-14 500827 281280 16-05-14 500575 281635 AS Summary 47128 Number of ASes in routing system 19205 Number of ASes announcing only one prefix 3769 Largest number of prefixes announced by an AS AS28573: NET Servi�os de Comunica��o S.A.,BR 120058880 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 16May14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 500449 281787 218662 43.7% All ASes AS28573 3769 596 3173 84.2% NET Servi�os de Comunica��o S.A.,BR AS6389 2959 56 2903 98.1% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2794 251 2543 91.0% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS4766 2946 931 2015 68.4% KIXS-AS-KR Korea Telecom,KR AS18881 1982 37 1945 98.1% Global Village Telecom,BR AS1785 2206 496 1710 77.5% AS-PAETEC-NET - PaeTec Communications, Inc.,US AS10620 2853 1359 1494 52.4% Telmex Colombia S.A.,CO AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation,US AS7303 1760 455 1305 74.1% Telecom Argentina S.A.,AR AS4755 1852 585 1267 68.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4323 1643 424 1219 74.2% TWTC - tw telecom holdings, inc.,US AS7545 2243 1062 1181 52.7% TPG-INTERNET-AP TPG Telecom Limited,AU AS7552 1250 148 1102 88.2% VIETEL-AS-AP Viettel Corporation,VN AS36998 1114 37 1077 96.7% SDN-MOBITEL,SD AS22561 1306 241 1065 81.5% AS22561 - CenturyTel Internet Holdings, Inc.,US AS6983 1327 307 1020 76.9% ITCDELTA - Earthlink, Inc.,US AS9829 1645 714 931 56.6% BSNL-NIB National Internet Backbone,IN AS4788 1050 148 902 85.9% TMNET-AS-AP TM Net, Internet Service Provider,MY AS22773 2433 1534 899 37.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS4808 1223 404 819 67.0% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS24560 1129 361 768 68.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS18101 946 187 759 80.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS26615 858 106 752 87.6% Tim Celular S.A.,BR AS8151 1412 676 736 52.1% Uninet S.A. de C.V.,MX AS7738 912 182 730 80.0% Telemar Norte Leste S.A.,BR AS701 1474 747 727 49.3% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US AS855 755 58 697 92.3% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA AS4780 1041 372 669 64.3% SEEDNET Digital United Inc.,TW AS9808 1003 352 651 64.9% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS6147 781 135 646 82.7% Telefonica del Peru S.A.A.,PE Total 50713 13526 37187 73.3% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.236.0/24 AS37290 -Reserved AS-,ZZ 41.78.237.0/24 AS37290 -Reserved AS-,ZZ 41.78.238.0/24 AS37290 -Reserved AS-,ZZ 41.78.239.0/24 AS37290 -Reserved AS-,ZZ 41.189.96.0/19 AS37000 -Reserved AS-,ZZ 41.190.72.0/24 AS37451 CongoTelecom,CG 41.190.73.0/24 AS37451 CongoTelecom,CG 41.190.74.0/24 AS37451 CongoTelecom,CG 41.190.75.0/24 AS37451 CongoTelecom,CG 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos,US 63.247.0.0/24 AS27609 -Reserved AS-,ZZ 63.247.1.0/24 AS27609 -Reserved AS-,ZZ 63.247.2.0/24 AS27609 -Reserved AS-,ZZ 63.247.3.0/24 AS27609 -Reserved AS-,ZZ 63.247.4.0/24 AS27609 -Reserved AS-,ZZ 63.247.5.0/24 AS27609 -Reserved AS-,ZZ 63.247.6.0/24 AS27609 -Reserved AS-,ZZ 63.247.7.0/24 AS27609 -Reserved AS-,ZZ 63.247.8.0/24 AS27609 -Reserved AS-,ZZ 63.247.9.0/24 AS27609 -Reserved AS-,ZZ 63.247.10.0/24 AS27609 -Reserved AS-,ZZ 63.247.11.0/24 AS27609 -Reserved AS-,ZZ 63.247.13.0/24 AS27609 -Reserved AS-,ZZ 63.247.14.0/24 AS27609 -Reserved AS-,ZZ 63.247.15.0/24 AS27609 -Reserved AS-,ZZ 63.247.16.0/24 AS27609 -Reserved AS-,ZZ 63.247.17.0/24 AS27609 -Reserved AS-,ZZ 63.247.18.0/24 AS27609 -Reserved AS-,ZZ 63.247.19.0/24 AS27609 -Reserved AS-,ZZ 63.247.20.0/24 AS27609 -Reserved AS-,ZZ 63.247.21.0/24 AS27609 -Reserved AS-,ZZ 63.247.22.0/24 AS27609 -Reserved AS-,ZZ 63.247.23.0/24 AS27609 -Reserved AS-,ZZ 63.247.24.0/24 AS27609 -Reserved AS-,ZZ 63.247.25.0/24 AS27609 -Reserved AS-,ZZ 63.247.26.0/24 AS27609 -Reserved AS-,ZZ 63.247.27.0/24 AS27609 -Reserved AS-,ZZ 63.247.28.0/24 AS27609 -Reserved AS-,ZZ 63.247.29.0/24 AS27609 -Reserved AS-,ZZ 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.111.160.0/20 AS40551 -Reserved AS-,ZZ 64.111.160.0/24 AS40551 -Reserved AS-,ZZ 64.111.161.0/24 AS40551 -Reserved AS-,ZZ 64.111.162.0/24 AS40551 -Reserved AS-,ZZ 64.111.167.0/24 AS40551 -Reserved AS-,ZZ 64.111.169.0/24 AS40551 -Reserved AS-,ZZ 64.111.170.0/24 AS40551 -Reserved AS-,ZZ 64.111.171.0/24 AS40551 -Reserved AS-,ZZ 64.111.172.0/24 AS40551 -Reserved AS-,ZZ 64.111.173.0/24 AS40551 -Reserved AS-,ZZ 64.111.174.0/24 AS40551 -Reserved AS-,ZZ 64.111.175.0/24 AS40551 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.254.188.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.115.124.0/23 AS46540 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 -Reserved AS-,ZZ 74.120.214.0/23 AS32326 -Reserved AS-,ZZ 74.120.240.0/21 AS30063 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.122.224.0/21 AS30063 -Reserved AS-,ZZ 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD,RU 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT 91.229.182.0/24 AS56960 -Reserved AS-,ZZ 91.229.186.0/24 AS56967 -Reserved AS-,ZZ 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 95.215.140.0/22 AS48949 -Reserved AS-,ZZ 100.64.111.0/24 AS25019 SAUDINETSTC-AS Autonomus System Number for SaudiNet,SA 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN 103.18.76.0/22 AS18097 JPNIC-ASBLOCK-AP JPNIC,JP 103.18.80.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK 103.18.81.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK 103.23.48.0/24 AS56194 103.23.49.0/24 AS56194 103.23.50.0/24 AS56194 103.23.51.0/24 AS56194 103.31.236.0/22 AS17941 JPNIC-JP-ASN-BLOCK Japan Network Information Center,JP 103.244.236.0/22 AS58794 103.247.52.0/23 AS4725 ODN SOFTBANK TELECOM Corp.,JP 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 154.121.0.0/24 AS32771 ATM,DZ 154.121.1.0/24 AS32771 ATM,DZ 154.121.2.0/24 AS32771 ATM,DZ 154.121.3.0/24 AS32771 ATM,DZ 154.121.4.0/24 AS32771 ATM,DZ 154.121.5.0/24 AS32771 ATM,DZ 162.255.136.0/22 AS47869 NETROUTING-AS Netrouting,NL 162.255.152.0/24 AS18845 CASTLEGEM - Castlegem Inc.,US 162.255.153.0/24 AS18845 CASTLEGEM - Castlegem Inc.,US 162.255.154.0/24 AS18845 CASTLEGEM - Castlegem Inc.,US 162.255.155.0/24 AS18845 CASTLEGEM - Castlegem Inc.,US 162.255.180.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 163.47.23.0/24 AS2907 JPNIC-2BYTE-ASBLOCK-AP for assignment to JPNIC members,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 172.200.0.0/13 AS1668 AOL-ATDN - AOL Transit Data Network,US 172.200.0.0/16 AS1668 AOL-ATDN - AOL Transit Data Network,US 172.201.0.0/16 AS1668 AOL-ATDN - AOL Transit Data Network,US 172.202.0.0/16 AS1668 AOL-ATDN - AOL Transit Data Network,US 172.203.0.0/16 AS1668 AOL-ATDN - AOL Transit Data Network,US 172.204.0.0/16 AS1668 AOL-ATDN - AOL Transit Data Network,US 172.206.0.0/16 AS1668 AOL-ATDN - AOL Transit Data Network,US 172.207.0.0/16 AS1668 AOL-ATDN - AOL Transit Data Network,US 173.213.208.0/22 AS54040 -Reserved AS-,ZZ 173.213.212.0/24 AS54040 -Reserved AS-,ZZ 173.213.213.0/24 AS54040 -Reserved AS-,ZZ 173.213.214.0/23 AS54040 -Reserved AS-,ZZ 173.213.216.0/21 AS54040 -Reserved AS-,ZZ 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 176.125.224.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A.,EC 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc.,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.241.20.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.241.21.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.84.187.0/24 AS16276 OVH OVH SAS,FR 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.112.0/23 AS12964 DBMG-DE Dr. Buelow & Masiak GmbH,DE 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.243.166.0/24 AS44093 -Reserved AS-,ZZ 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.69.203.0/24 AS5089 NTL Virgin Media Limited,GB 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 194.213.8.0/24 AS42845 BRETAGNETELECOM BRETAGNE TELECOM SAS,FR 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.39.252.0/23 AS29004 -Reserved AS-,ZZ 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.90.98.0/23 AS57511 OVALTECH-AS OvalTech Internet Ltd,GB 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL,RO 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.2.224.0/22 AS24863 LINKdotNET-AS,EG 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.13.201.0/24 AS2018 TENET-1,ZA 196.13.202.0/24 AS2018 TENET-1,ZA 196.13.203.0/24 AS2018 TENET-1,ZA 196.13.204.0/24 AS2018 TENET-1,ZA 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.45.0.0/21 AS26625 -Reserved AS-,ZZ 196.45.10.0/24 AS26625 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.68.72.0/24 AS174 COGENT-174 - Cogent Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.9.40.0/24 AS56194 202.9.41.0/24 AS56194 202.9.42.0/24 AS56194 202.9.43.0/24 AS56194 202.9.44.0/24 AS56194 202.9.45.0/24 AS56194 202.9.46.0/24 AS56194 202.9.47.0/24 AS56194 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.10.94.0/23 AS30097 NUWAVE - NuWave,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp.,CA 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/22 AS16936 -Reserved AS-,ZZ 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.73.112.0/24 AS19231 -Reserved AS-,ZZ 208.73.113.0/24 AS19231 -Reserved AS-,ZZ 208.73.114.0/24 AS19231 -Reserved AS-,ZZ 208.73.115.0/24 AS19231 -Reserved AS-,ZZ 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US 209.17.224.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.225.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.226.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.227.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.228.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.229.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.230.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.231.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.232.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.233.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.234.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.235.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.236.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.237.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.238.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.239.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.240.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.241.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.242.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.243.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.244.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.245.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.246.0/24 AS14846 CGNOGE - NBC Internet,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 212.119.32.0/19 AS12550 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.178.96.0/21 AS17035 -Reserved AS-,ZZ 216.178.104.0/21 AS17035 -Reserved AS-,ZZ 216.203.80.0/20 AS27021 -Reserved AS-,ZZ 216.203.80.0/21 AS27021 -Reserved AS-,ZZ 216.203.87.0/24 AS27021 -Reserved AS-,ZZ 216.203.88.0/21 AS27021 -Reserved AS-,ZZ 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 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 May 16 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 May 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201405162200.s4GM01aU067288@wattle.apnic.net> BGP Update Report Interval: 08-May-14 -to- 15-May-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 108543 2.6% 65.8 -- BSNL-NIB National Internet Backbone,IN 2 - AS4775 65396 1.6% 531.7 -- GLOBE-TELECOM-AS Globe Telecoms,PH 3 - AS28573 47964 1.1% 12.1 -- NET Servi�os de Comunica��o S.A.,BR 4 - AS8402 42568 1.0% 24.6 -- CORBINA-AS OJSC "Vimpelcom",RU 5 - AS10620 25918 0.6% 9.1 -- Telmex Colombia S.A.,CO 6 - AS23752 23285 0.6% 165.1 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 7 - AS14259 20583 0.5% 76.8 -- Gtd Internet S.A.,CL 8 - AS4755 20546 0.5% 11.1 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 9 - AS41691 20385 0.5% 849.4 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 10 - AS24960 20357 0.5% 5089.2 -- GATCHINA-AS Severo-Zapad Ltd.,RU 11 - AS9808 18102 0.4% 9.7 -- CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN 12 - AS4766 17939 0.4% 6.1 -- KIXS-AS-KR Korea Telecom,KR 13 - AS6389 17842 0.4% 6.0 -- BELLSOUTH-NET-BLK - BellSouth.net Inc.,US 14 - AS25184 17074 0.4% 128.4 -- AFRANET AFRANET Co. Tehran, Iran,IR 15 - AS15003 16751 0.4% 19.4 -- NOBIS-TECH - Nobis Technology Group, LLC,US 16 - AS52879 15560 0.4% 1728.9 -- ABM INFORMATICA E TELECOM,BR 17 - AS17974 15438 0.4% 5.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID 18 - AS35567 15368 0.4% 102.5 -- DASTO-BOSNIA-AS DASTO semtel d.o.o.,BA 19 - AS45899 14566 0.3% 40.1 -- VNPT-AS-VN VNPT Corp,VN 20 - AS3475 14043 0.3% 141.8 -- DNIC-AS-03475 - Navy Network Information Center (NNIC),US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4 6657 0.2% 824.0 -- ISI-AS - University of Southern California,US 2 - AS24960 20357 0.5% 5089.2 -- GATCHINA-AS Severo-Zapad Ltd.,RU 3 - AS3 2178 0.1% 3260.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 4 - AS4 3804 0.1% 597.0 -- ISI-AS - University of Southern California,US 5 - AS52879 15560 0.4% 1728.9 -- ABM INFORMATICA E TELECOM,BR 6 - AS45590 1456 0.0% 1456.0 -- HGCINTNET-AS-AP Hutch Connect,HK 7 - AS40299 1446 0.0% 1446.0 -- TRIPP-LITE - Tripplite,US 8 - AS3 1413 0.0% 1987.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 9 - AS54465 6992 0.2% 1398.4 -- QPM-AS-1 - QuickPlay Media Inc.,US 10 - AS16321 3635 0.1% 1211.7 -- AICONET-AS Aiconet Ltd.,RU 11 - AS60345 2306 0.1% 1153.0 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 12 - AS37615 2132 0.1% 1066.0 -- Main-Street-AS,NG 13 - AS6629 9431 0.2% 857.4 -- NOAA-AS - NOAA,US 14 - AS41691 20385 0.5% 849.4 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 15 - AS5 5390 0.1% 1.0 -- SYMBOLICS - Symbolics, Inc.,US 16 - AS2 635 0.0% 2210.0 -- UDEL-DCN - University of Delaware,US 17 - AS3 630 0.0% 2319.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 18 - AS2 13976 0.3% 1127.0 -- UDEL-DCN - University of Delaware,US 19 - AS61985 582 0.0% 582.0 -- TECHNOLINK-NET Technolink Ltd.,CZ 20 - AS61229 534 0.0% 534.0 -- AIVA-AS Aiva Ltd.,RU TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 89.221.206.0/24 20269 0.5% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 2 - 121.52.144.0/24 12447 0.3% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK AS45773 -- HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan,PK 3 - 202.70.88.0/21 11946 0.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 192.58.232.0/24 9392 0.2% AS6629 -- NOAA-AS - NOAA,US 5 - 87.250.97.0/24 8888 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o.,BA 6 - 78.109.192.0/20 8472 0.2% AS25184 -- AFRANET AFRANET Co. Tehran, Iran,IR 7 - 202.70.64.0/21 8042 0.2% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 8 - 120.28.62.0/24 7784 0.2% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 9 - 205.247.12.0/24 7635 0.2% AS6459 -- TRANSBEAM - I-2000, Inc.,US 10 - 115.170.128.0/17 7265 0.2% AS4847 -- CNIX-AP China Networks Inter-Exchange,CN 11 - 222.127.0.0/24 7240 0.2% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 12 - 42.83.48.0/20 7237 0.2% AS18135 -- JPNIC-ASBLOCK-AP JPNIC,JP 13 - 206.152.15.0/24 6968 0.2% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.,US 14 - 91.227.46.0/24 6788 0.1% AS24960 -- GATCHINA-AS Severo-Zapad Ltd.,RU 15 - 193.111.252.0/22 6783 0.1% AS24960 -- GATCHINA-AS Severo-Zapad Ltd.,RU 16 - 91.227.44.0/23 6782 0.1% AS24960 -- GATCHINA-AS Severo-Zapad Ltd.,RU 17 - 186.237.56.0/22 6657 0.1% AS4 -- ISI-AS - University of Southern California,US 18 - 186.208.186.0/24 3792 0.1% AS4 -- ISI-AS - University of Southern California,US 19 - 166.149.142.0/24 3162 0.1% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 20 - 205.94.160.0/19 2944 0.1% AS3475 -- DNIC-AS-03475 - Navy Network Information Center (NNIC),US 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 hs.citizen at gmail.com Fri May 16 03:18:02 2014 From: hs.citizen at gmail.com (Chris) Date: Fri, 16 May 2014 13:18:02 +1000 Subject: Access hardware for small FTTP deployment Message-ID: Hi all, We are looking at doing a small FTTP deployment in a community of about 30 homes and I'm searching for options regarding access layer hardware. Initially we thought of a simple point-to-point ethernet setup with 1000Base-BX to each premises and a 48-port access switch. However, finding an appropriate piece of hardware has proven challenging because of our requirement of a 60+ degrees Celcius operating temperature (due to outdoor cabinet placement). The only one I found that meets the temperature requirement was Cisco's ME 2600X with 44 SFP ports, 4 SFP+ and 65degC max, but it's a bit pricey for our liking. Other offerings from HP (5800-24G-SFP), Juniper (EX4550), Brocade (CES-2048F) were nice, but all only had 40-45degC max operating temp. I'm interested to see what other people are doing for these types of small setups. Does anyone know of any other reasonably priced access switches, 32+ SFP ports, and able to withstand 60degC or higher operating temperature? We are also considering GPON, but given that we would only need one interface for such a small deployment, most of the hardware out there seems like overkill. Are there good small OLTs? Cheers, Chris From srahul.in at gmail.com Fri May 16 05:35:11 2014 From: srahul.in at gmail.com (Rahul Sawarkar) Date: Fri, 16 May 2014 11:05:11 +0530 Subject: A simple proposal In-Reply-To: References: Message-ID: You mean consume electricity in cpu cycles on the end devices and all the network middleboxes in between all over the world/Internet for dud data? For what? Just to stop a debate instead of resolving it thought intellectual brainstorming? For one thing it will slow down the TCP connections as ACKs incur a longer RTT. Then there is the whole question of managing and lowering power consumption as a green initiative, and capacity issues are yet another thing. ~Rahul On Fri, May 16, 2014 at 10:56 AM, Matthew Petach wrote: > There's been a whole lot of chatter recently > about whether or not it's sensible to require > balanced peering ratios when selling heavily > unbalanced services to customers. > > There's a very simple solution, it seems. > Just have every website, every streaming > service, every bit of consumable internet > data have built-in reciprocity. > > You want to stream a movie? No problem; > the video player opens up a second data > port back to a server next to the streaming > box; its only purpose is to accept a socket, > and send all bits received on it to /dev/null. > The video player sends back an equivalent > stream of data to what is being received in. > The server receiving the upstream data stream > checks the bitrate coming into it from the player, > and communicates back to the video streaming > box every few minutes to lower the outbound > bitrate going to the player to match what the > inbound bitrate coming from the client is. > That way, traffic volumes stay nicely balanced, > and everyone is happy. For extra credit, and > to deal with multiple layers of NAT in the v4 > world, you could even piggyback on the same > stream, though that would take just a bit more > work. > > Mobile apps could be programmed the same > way; you download a certain amount of data, > an equivalent volume of data is sent back > upstream to balance it out, and preserve > the holy ratio. Even web pages could use > javascript footers to send back upstream an > equivalent amount of data to what was > downloaded. > > Once and for all, we could put an end to > the ceaseless bickering about ratios, as > everyone, everywhere would be forced > into glorious unity, a perfect 1:1 ratio > wherever the eye should look. > > As far as I can tell, this should solve > *everyone's* concerns from all sides, > all in one simple effort. > > Matt > -- ~~~~~~ Regards Rahul From pete at tccmail.ca Fri May 16 16:14:46 2014 From: pete at tccmail.ca (Pete@TCC) Date: Fri, 16 May 2014 12:14:46 -0400 Subject: FTTH ONTs and routers In-Reply-To: <5374F538.5010108@vaxination.ca> References: <5374F538.5010108@vaxination.ca> Message-ID: <53763976.8020805@tccmail.ca> There are many ONTs out there with various abilities. I can only comment on what I deploy, and what various telcos deploy that I am familiar with. A few years ago, all of our AE and GPON ONTs were deployed as bridges. Port 1 was generally an Internet VLAN, and port 2,3,4 were IPTV VLANs. We have been using Occam (now Calix), but are considering other options at this point. Currently we bridge all services on GPON deployments, but rent routers for the Internet service if customers do not wish to provide their own. The 700-series ONTs are able to bounce between GPON and AE deployments with a firmware change, so they are very flexible. Calix has apparently released RG code (Residential Gateway, basic home router functionality) for for the 700s, but we don't use that code. We also deploy 836 ONTs, which had RG code built-in on release, and also WiFi. The 836s currently only do AE, but were originally supposed to do GPON/AE similar to the 700-series. Today, the standard AE deployment is an 836 with RG code enabled for WiFi and Port 1. WAN is DHCP, authorized with Option 82/RADIUS for bandwidth profiles. LAN does NAT, and hands out a 192.168.88.0/24 subnet to break as few consumer routers as possible. We have no problem enabling bridging for Port 1 if the customer requests it. We bridge Port 2,3,4 for IPTV because the RG functionality breaks certain features, namely call display on the TVs. The 836s can do Static, PPPoE, or DHCP on the WAN side. We use MGCP for voice. -- Pete Baldwin On 14-05-15 01:11 PM, Jean-Francois Mezei wrote: > It had been my impression that ONTs, like most other consumer modems, > came with built-in router capabilities (along with ATA for voice). > > The assertion that ONTs have built-in routing capabilities has been > challenged. > > Can anyone confirm whether ONTs generally have routing (aka: home router > that does the PPPoE or DHCP and then NAT for home) capabilities? > > Are there examples where a telco has deployed ONTs with the router > built-in and enabled ? Or would almost all FTTH deployments be made with > any routing disabled and the ONT acting as a pure ethernet bridge ? > > > (I appreciate your help on this as I am time constrained to do research). > From patrick at ianai.net Fri May 16 22:16:04 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 16 May 2014 18:16:04 -0400 Subject: The Cidr Report In-Reply-To: <201405162200.s4GM00dY067273@wattle.apnic.net> References: <201405162200.s4GM00dY067273@wattle.apnic.net> Message-ID: <494E1D77-08EA-480A-B892-4EA617B799C5@ianai.net> Dammit people. Get back to work. Pull us back down under 500K! -- TTFN, patrick On May 16, 2014, at 18:00 , cidr-report at potaroo.net wrote: > This report has been generated at Fri May 16 21:13:53 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 > 09-05-14 499630 282328 > 10-05-14 499734 279956 > 11-05-14 499614 279852 > 12-05-14 499793 280018 > 13-05-14 500061 280153 > 14-05-14 500728 281450 > 15-05-14 500827 281280 > 16-05-14 500575 281635 > > > AS Summary > 47128 Number of ASes in routing system > 19205 Number of ASes announcing only one prefix > 3769 Largest number of prefixes announced by an AS > AS28573: NET Serviços de Comunicação S.A.,BR > 120058880 Largest address span announced by an AS (/32s) > AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN > > > 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'). > > --- 16May14 --- > ASnum NetsNow NetsAggr NetGain % Gain Description > > Table 500449 281787 218662 43.7% All ASes > > AS28573 3769 596 3173 84.2% NET Serviços de Comunicação > S.A.,BR > AS6389 2959 56 2903 98.1% BELLSOUTH-NET-BLK - > BellSouth.net Inc.,US > AS17974 2794 251 2543 91.0% TELKOMNET-AS2-AP PT > Telekomunikasi Indonesia,ID > AS4766 2946 931 2015 68.4% KIXS-AS-KR Korea Telecom,KR > AS18881 1982 37 1945 98.1% Global Village Telecom,BR > AS1785 2206 496 1710 77.5% AS-PAETEC-NET - PaeTec > Communications, Inc.,US > AS10620 2853 1359 1494 52.4% Telmex Colombia S.A.,CO > AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath > Corporation,US > AS7303 1760 455 1305 74.1% Telecom Argentina S.A.,AR > AS4755 1852 585 1267 68.4% TATACOMM-AS TATA > Communications formerly VSNL > is Leading ISP,IN > AS4323 1643 424 1219 74.2% TWTC - tw telecom holdings, > inc.,US > AS7545 2243 1062 1181 52.7% TPG-INTERNET-AP TPG Telecom > Limited,AU > AS7552 1250 148 1102 88.2% VIETEL-AS-AP Viettel > Corporation,VN > AS36998 1114 37 1077 96.7% SDN-MOBITEL,SD > AS22561 1306 241 1065 81.5% AS22561 - CenturyTel Internet > Holdings, Inc.,US > AS6983 1327 307 1020 76.9% ITCDELTA - Earthlink, Inc.,US > AS9829 1645 714 931 56.6% BSNL-NIB National Internet > Backbone,IN > AS4788 1050 148 902 85.9% TMNET-AS-AP TM Net, Internet > Service Provider,MY > AS22773 2433 1534 899 37.0% ASN-CXA-ALL-CCI-22773-RDC - > Cox Communications Inc.,US > AS4808 1223 404 819 67.0% CHINA169-BJ CNCGROUP IP > network China169 Beijing > Province Network,CN > AS24560 1129 361 768 68.0% AIRTELBROADBAND-AS-AP Bharti > Airtel Ltd., Telemedia > Services,IN > AS18101 946 187 759 80.2% RELIANCE-COMMUNICATIONS-IN > Reliance Communications > Ltd.DAKC MUMBAI,IN > AS26615 858 106 752 87.6% Tim Celular S.A.,BR > AS8151 1412 676 736 52.1% Uninet S.A. de C.V.,MX > AS7738 912 182 730 80.0% Telemar Norte Leste S.A.,BR > AS701 1474 747 727 49.3% UUNET - MCI Communications > Services, Inc. d/b/a Verizon > Business,US > AS855 755 58 697 92.3% CANET-ASN-4 - Bell Aliant > Regional Communications, > Inc.,CA > AS4780 1041 372 669 64.3% SEEDNET Digital United Inc.,TW > AS9808 1003 352 651 64.9% CMNET-GD Guangdong Mobile > Communication Co.Ltd.,CN > AS6147 781 135 646 82.7% Telefonica del Peru S.A.A.,PE > > Total 50713 13526 37187 73.3% Top 30 total > > > Possible Bogus Routes > > 27.100.7.0/24 AS56096 > 41.73.1.0/24 AS37004 -Reserved AS-,ZZ > 41.73.2.0/24 AS37004 -Reserved AS-,ZZ > 41.73.10.0/24 AS37004 -Reserved AS-,ZZ > 41.73.11.0/24 AS37004 -Reserved AS-,ZZ > 41.73.12.0/24 AS37004 -Reserved AS-,ZZ > 41.73.13.0/24 AS37004 -Reserved AS-,ZZ > 41.73.14.0/24 AS37004 -Reserved AS-,ZZ > 41.73.15.0/24 AS37004 -Reserved AS-,ZZ > 41.73.16.0/24 AS37004 -Reserved AS-,ZZ > 41.73.18.0/24 AS37004 -Reserved AS-,ZZ > 41.73.20.0/24 AS37004 -Reserved AS-,ZZ > 41.73.21.0/24 AS37004 -Reserved AS-,ZZ > 41.76.48.0/21 AS36969 MTL-AS,MW > 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US > 41.78.236.0/24 AS37290 -Reserved AS-,ZZ > 41.78.237.0/24 AS37290 -Reserved AS-,ZZ > 41.78.238.0/24 AS37290 -Reserved AS-,ZZ > 41.78.239.0/24 AS37290 -Reserved AS-,ZZ > 41.189.96.0/19 AS37000 -Reserved AS-,ZZ > 41.190.72.0/24 AS37451 CongoTelecom,CG > 41.190.73.0/24 AS37451 CongoTelecom,CG > 41.190.74.0/24 AS37451 CongoTelecom,CG > 41.190.75.0/24 AS37451 CongoTelecom,CG > 41.191.108.0/22 AS37004 -Reserved AS-,ZZ > 41.191.108.0/24 AS37004 -Reserved AS-,ZZ > 41.191.109.0/24 AS37004 -Reserved AS-,ZZ > 41.191.110.0/24 AS37004 -Reserved AS-,ZZ > 41.191.111.0/24 AS37004 -Reserved AS-,ZZ > 41.223.208.0/22 AS37000 -Reserved AS-,ZZ > 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL > 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL > 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos,US > 63.247.0.0/24 AS27609 -Reserved AS-,ZZ > 63.247.1.0/24 AS27609 -Reserved AS-,ZZ > 63.247.2.0/24 AS27609 -Reserved AS-,ZZ > 63.247.3.0/24 AS27609 -Reserved AS-,ZZ > 63.247.4.0/24 AS27609 -Reserved AS-,ZZ > 63.247.5.0/24 AS27609 -Reserved AS-,ZZ > 63.247.6.0/24 AS27609 -Reserved AS-,ZZ > 63.247.7.0/24 AS27609 -Reserved AS-,ZZ > 63.247.8.0/24 AS27609 -Reserved AS-,ZZ > 63.247.9.0/24 AS27609 -Reserved AS-,ZZ > 63.247.10.0/24 AS27609 -Reserved AS-,ZZ > 63.247.11.0/24 AS27609 -Reserved AS-,ZZ > 63.247.13.0/24 AS27609 -Reserved AS-,ZZ > 63.247.14.0/24 AS27609 -Reserved AS-,ZZ > 63.247.15.0/24 AS27609 -Reserved AS-,ZZ > 63.247.16.0/24 AS27609 -Reserved AS-,ZZ > 63.247.17.0/24 AS27609 -Reserved AS-,ZZ > 63.247.18.0/24 AS27609 -Reserved AS-,ZZ > 63.247.19.0/24 AS27609 -Reserved AS-,ZZ > 63.247.20.0/24 AS27609 -Reserved AS-,ZZ > 63.247.21.0/24 AS27609 -Reserved AS-,ZZ > 63.247.22.0/24 AS27609 -Reserved AS-,ZZ > 63.247.23.0/24 AS27609 -Reserved AS-,ZZ > 63.247.24.0/24 AS27609 -Reserved AS-,ZZ > 63.247.25.0/24 AS27609 -Reserved AS-,ZZ > 63.247.26.0/24 AS27609 -Reserved AS-,ZZ > 63.247.27.0/24 AS27609 -Reserved AS-,ZZ > 63.247.28.0/24 AS27609 -Reserved AS-,ZZ > 63.247.29.0/24 AS27609 -Reserved AS-,ZZ > 64.25.16.0/23 AS19535 -Reserved AS-,ZZ > 64.25.20.0/24 AS19535 -Reserved AS-,ZZ > 64.25.21.0/24 AS19535 -Reserved AS-,ZZ > 64.25.22.0/24 AS19535 -Reserved AS-,ZZ > 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US > 64.111.160.0/20 AS40551 -Reserved AS-,ZZ > 64.111.160.0/24 AS40551 -Reserved AS-,ZZ > 64.111.161.0/24 AS40551 -Reserved AS-,ZZ > 64.111.162.0/24 AS40551 -Reserved AS-,ZZ > 64.111.167.0/24 AS40551 -Reserved AS-,ZZ > 64.111.169.0/24 AS40551 -Reserved AS-,ZZ > 64.111.170.0/24 AS40551 -Reserved AS-,ZZ > 64.111.171.0/24 AS40551 -Reserved AS-,ZZ > 64.111.172.0/24 AS40551 -Reserved AS-,ZZ > 64.111.173.0/24 AS40551 -Reserved AS-,ZZ > 64.111.174.0/24 AS40551 -Reserved AS-,ZZ > 64.111.175.0/24 AS40551 -Reserved AS-,ZZ > 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US > 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US > 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US > 66.55.96.0/23 AS17203 -Reserved AS-,ZZ > 66.55.98.0/24 AS17203 -Reserved AS-,ZZ > 66.55.99.0/24 AS17203 -Reserved AS-,ZZ > 66.55.100.0/22 AS17203 -Reserved AS-,ZZ > 66.55.102.0/23 AS17203 -Reserved AS-,ZZ > 66.55.104.0/21 AS17203 -Reserved AS-,ZZ > 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA > 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US > 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US > 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.254.188.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT > 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US > 74.112.100.0/22 AS16764 -Reserved AS-,ZZ > 74.113.200.0/23 AS46939 -Reserved AS-,ZZ > 74.114.52.0/22 AS40818 -Reserved AS-,ZZ > 74.114.52.0/23 AS40818 -Reserved AS-,ZZ > 74.114.52.0/24 AS40818 -Reserved AS-,ZZ > 74.114.53.0/24 AS40818 -Reserved AS-,ZZ > 74.114.54.0/23 AS40818 -Reserved AS-,ZZ > 74.114.54.0/24 AS40818 -Reserved AS-,ZZ > 74.114.55.0/24 AS40818 -Reserved AS-,ZZ > 74.115.124.0/23 AS46540 -Reserved AS-,ZZ > 74.118.132.0/22 AS5117 -Reserved AS-,ZZ > 74.120.212.0/23 AS32326 -Reserved AS-,ZZ > 74.120.214.0/23 AS32326 -Reserved AS-,ZZ > 74.120.240.0/21 AS30063 -Reserved AS-,ZZ > 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US > 74.122.224.0/21 AS30063 -Reserved AS-,ZZ > 77.243.80.0/24 AS42597 -Reserved AS-,ZZ > 77.243.81.0/24 AS42597 -Reserved AS-,ZZ > 77.243.88.0/24 AS42597 -Reserved AS-,ZZ > 77.243.91.0/24 AS42597 -Reserved AS-,ZZ > 77.243.94.0/24 AS42597 -Reserved AS-,ZZ > 77.243.95.0/24 AS42597 -Reserved AS-,ZZ > 80.250.32.0/22 AS37106 ODUA-AS,NG > 85.202.160.0/20 AS44404 -Reserved AS-,ZZ > 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 91.197.36.0/22 AS43359 -Reserved AS-,ZZ > 91.199.90.0/24 AS44330 -Reserved AS-,ZZ > 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD,RU > 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE > 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT > 91.229.182.0/24 AS56960 -Reserved AS-,ZZ > 91.229.186.0/24 AS56967 -Reserved AS-,ZZ > 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB > 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > 93.190.10.0/24 AS47254 -Reserved AS-,ZZ > 95.215.140.0/22 AS48949 -Reserved AS-,ZZ > 100.64.111.0/24 AS25019 SAUDINETSTC-AS Autonomus System Number for SaudiNet,SA > 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU > 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN > 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN > 103.18.76.0/22 AS18097 JPNIC-ASBLOCK-AP JPNIC,JP > 103.18.80.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK > 103.18.81.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK > 103.23.48.0/24 AS56194 > 103.23.49.0/24 AS56194 > 103.23.50.0/24 AS56194 > 103.23.51.0/24 AS56194 > 103.31.236.0/22 AS17941 JPNIC-JP-ASN-BLOCK Japan Network Information Center,JP > 103.244.236.0/22 AS58794 > 103.247.52.0/23 AS4725 ODN SOFTBANK TELECOM Corp.,JP > 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU > 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK > 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US > 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US > 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US > 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN > 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN > 154.121.0.0/24 AS32771 ATM,DZ > 154.121.1.0/24 AS32771 ATM,DZ > 154.121.2.0/24 AS32771 ATM,DZ > 154.121.3.0/24 AS32771 ATM,DZ > 154.121.4.0/24 AS32771 ATM,DZ > 154.121.5.0/24 AS32771 ATM,DZ > 162.255.136.0/22 AS47869 NETROUTING-AS Netrouting,NL > 162.255.152.0/24 AS18845 CASTLEGEM - Castlegem Inc.,US > 162.255.153.0/24 AS18845 CASTLEGEM - Castlegem Inc.,US > 162.255.154.0/24 AS18845 CASTLEGEM - Castlegem Inc.,US > 162.255.155.0/24 AS18845 CASTLEGEM - Castlegem Inc.,US > 162.255.180.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US > 163.47.23.0/24 AS2907 JPNIC-2BYTE-ASBLOCK-AP for assignment to JPNIC members,JP > 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US > 172.85.0.0/24 AS29571 CITelecom-AS,CI > 172.85.1.0/24 AS29571 CITelecom-AS,CI > 172.85.2.0/24 AS29571 CITelecom-AS,CI > 172.85.3.0/24 AS29571 CITelecom-AS,CI > 172.86.0.0/24 AS29571 CITelecom-AS,CI > 172.86.1.0/24 AS29571 CITelecom-AS,CI > 172.86.2.0/24 AS29571 CITelecom-AS,CI > 172.87.0.0/24 AS29571 CITelecom-AS,CI > 172.88.0.0/24 AS29571 CITelecom-AS,CI > 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN > 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US > 172.200.0.0/13 AS1668 AOL-ATDN - AOL Transit Data Network,US > 172.200.0.0/16 AS1668 AOL-ATDN - AOL Transit Data Network,US > 172.201.0.0/16 AS1668 AOL-ATDN - AOL Transit Data Network,US > 172.202.0.0/16 AS1668 AOL-ATDN - AOL Transit Data Network,US > 172.203.0.0/16 AS1668 AOL-ATDN - AOL Transit Data Network,US > 172.204.0.0/16 AS1668 AOL-ATDN - AOL Transit Data Network,US > 172.206.0.0/16 AS1668 AOL-ATDN - AOL Transit Data Network,US > 172.207.0.0/16 AS1668 AOL-ATDN - AOL Transit Data Network,US > 173.213.208.0/22 AS54040 -Reserved AS-,ZZ > 173.213.212.0/24 AS54040 -Reserved AS-,ZZ > 173.213.213.0/24 AS54040 -Reserved AS-,ZZ > 173.213.214.0/23 AS54040 -Reserved AS-,ZZ > 173.213.216.0/21 AS54040 -Reserved AS-,ZZ > 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO > 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ > 176.125.224.0/19 AS39906 COPROSYS CoProSys a.s.,CZ > 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO > 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A.,EC > 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR > 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US > 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US > 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US > 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US > 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US > 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US > 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA > 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US > 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 192.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc.,US > 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE > 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US > 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US > 192.154.32.0/19 AS81 NCREN - MCNC,US > 192.154.64.0/19 AS81 NCREN - MCNC,US > 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 192.241.20.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US > 192.241.21.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US > 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US > 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US > 193.9.59.0/24 AS1257 TELE2,SE > 193.16.106.0/24 AS31539 -Reserved AS-,ZZ > 193.16.145.0/24 AS31392 -Reserved AS-,ZZ > 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI > 193.22.224.0/20 AS3322 -Reserved AS-,ZZ > 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE > 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB > 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE > 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB > 193.84.187.0/24 AS16276 OVH OVH SAS,FR > 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB > 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO > 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES > 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO > 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO > 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE > 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US > 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT > 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO > 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.201.112.0/23 AS12964 DBMG-DE Dr. Buelow & Masiak GmbH,DE > 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB > 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB > 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT > 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.243.166.0/24 AS44093 -Reserved AS-,ZZ > 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA > 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA > 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE > 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE > 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE > 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB > 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE > 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB > 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 194.69.203.0/24 AS5089 NTL Virgin Media Limited,GB > 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE > 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO > 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE > 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 194.126.219.0/24 AS34545 -Reserved AS-,ZZ > 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR > 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE > 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE > 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE > 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA > 194.213.8.0/24 AS42845 BRETAGNETELECOM BRETAGNE TELECOM SAS,FR > 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO > 195.39.252.0/23 AS29004 -Reserved AS-,ZZ > 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE > 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO > 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.90.98.0/23 AS57511 OVALTECH-AS OvalTech Internet Ltd,GB > 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL,RO > 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE > 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE > 195.234.156.0/24 AS25028 -Reserved AS-,ZZ > 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 196.2.224.0/22 AS24863 LINKdotNET-AS,EG > 196.3.182.0/24 AS37004 -Reserved AS-,ZZ > 196.3.183.0/24 AS37004 -Reserved AS-,ZZ > 196.13.201.0/24 AS2018 TENET-1,ZA > 196.13.202.0/24 AS2018 TENET-1,ZA > 196.13.203.0/24 AS2018 TENET-1,ZA > 196.13.204.0/24 AS2018 TENET-1,ZA > 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR > 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US > 196.45.0.0/21 AS26625 -Reserved AS-,ZZ > 196.45.10.0/24 AS26625 -Reserved AS-,ZZ > 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US > 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US > 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US > 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US > 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US > 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US > 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA > 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA > 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA > 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA > 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US > 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US > 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US > 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US > 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK > 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 199.68.72.0/24 AS174 COGENT-174 - Cogent Communications,US > 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA > 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US > 199.116.200.0/21 AS22830 -Reserved AS-,ZZ > 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US > 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US > 200.58.248.0/21 AS27849 > 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR > 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR > 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR > 202.9.40.0/24 AS56194 > 202.9.41.0/24 AS56194 > 202.9.42.0/24 AS56194 > 202.9.43.0/24 AS56194 > 202.9.44.0/24 AS56194 > 202.9.45.0/24 AS56194 > 202.9.46.0/24 AS56194 > 202.9.47.0/24 AS56194 > 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK > 202.58.113.0/24 AS19161 -Reserved AS-,ZZ > 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN > 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG > 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN > 203.142.219.0/24 AS45149 > 203.189.116.0/22 AS45606 > 203.189.116.0/24 AS45606 > 203.189.117.0/24 AS45606 > 203.189.118.0/24 AS45606 > 203.189.119.0/24 AS45606 > 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 204.10.94.0/23 AS30097 NUWAVE - NuWave,US > 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US > 204.16.96.0/24 AS19972 -Reserved AS-,ZZ > 204.16.97.0/24 AS19972 -Reserved AS-,ZZ > 204.16.98.0/24 AS19972 -Reserved AS-,ZZ > 204.16.99.0/24 AS19972 -Reserved AS-,ZZ > 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US > 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US > 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB > 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA > 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US > 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US > 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp.,CA > 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA > 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US > 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US > 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US > 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US > 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US > 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US > 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US > 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US > 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US > 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US > 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM > 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM > 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM > 208.66.64.0/22 AS16936 -Reserved AS-,ZZ > 208.66.64.0/24 AS16936 -Reserved AS-,ZZ > 208.66.65.0/24 AS16936 -Reserved AS-,ZZ > 208.66.66.0/24 AS16936 -Reserved AS-,ZZ > 208.66.67.0/24 AS16936 -Reserved AS-,ZZ > 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US > 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US > 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US > 208.73.112.0/24 AS19231 -Reserved AS-,ZZ > 208.73.113.0/24 AS19231 -Reserved AS-,ZZ > 208.73.114.0/24 AS19231 -Reserved AS-,ZZ > 208.73.115.0/24 AS19231 -Reserved AS-,ZZ > 208.75.152.0/21 AS32146 -Reserved AS-,ZZ > 208.76.20.0/24 AS31812 -Reserved AS-,ZZ > 208.76.21.0/24 AS31812 -Reserved AS-,ZZ > 208.77.164.0/24 AS22659 -Reserved AS-,ZZ > 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US > 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US > 208.84.232.0/24 AS33131 -Reserved AS-,ZZ > 208.84.234.0/24 AS33131 -Reserved AS-,ZZ > 208.84.237.0/24 AS33131 -Reserved AS-,ZZ > 208.84.238.0/24 AS33131 -Reserved AS-,ZZ > 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US > 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US > 209.17.224.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.225.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.226.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.227.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.228.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.229.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.230.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.231.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.232.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.233.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.234.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.235.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.236.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.237.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.238.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.239.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.240.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.241.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.242.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.243.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.244.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.245.0/24 AS14846 CGNOGE - NBC Internet,US > 209.17.246.0/24 AS14846 CGNOGE - NBC Internet,US > 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US > 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US > 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US > 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US > 209.234.112.0/23 AS32252 -Reserved AS-,ZZ > 209.234.114.0/23 AS32252 -Reserved AS-,ZZ > 209.234.116.0/24 AS32252 -Reserved AS-,ZZ > 209.234.117.0/24 AS32252 -Reserved AS-,ZZ > 209.234.118.0/24 AS32252 -Reserved AS-,ZZ > 209.234.119.0/24 AS32252 -Reserved AS-,ZZ > 209.234.120.0/24 AS32252 -Reserved AS-,ZZ > 209.234.121.0/24 AS32252 -Reserved AS-,ZZ > 209.234.122.0/24 AS32252 -Reserved AS-,ZZ > 212.119.32.0/19 AS12550 -Reserved AS-,ZZ > 213.184.64.0/24 AS13071 -Reserved AS-,ZZ > 213.184.65.0/24 AS13071 -Reserved AS-,ZZ > 213.184.66.0/24 AS13071 -Reserved AS-,ZZ > 213.184.67.0/24 AS13071 -Reserved AS-,ZZ > 213.184.68.0/24 AS13071 -Reserved AS-,ZZ > 213.184.69.0/24 AS13071 -Reserved AS-,ZZ > 213.184.70.0/24 AS13071 -Reserved AS-,ZZ > 213.184.71.0/24 AS13071 -Reserved AS-,ZZ > 213.184.72.0/24 AS13071 -Reserved AS-,ZZ > 213.184.73.0/24 AS13071 -Reserved AS-,ZZ > 213.184.74.0/24 AS13071 -Reserved AS-,ZZ > 213.184.75.0/24 AS13071 -Reserved AS-,ZZ > 213.184.76.0/24 AS13071 -Reserved AS-,ZZ > 213.184.77.0/24 AS13071 -Reserved AS-,ZZ > 213.184.78.0/24 AS13071 -Reserved AS-,ZZ > 213.255.128.0/20 AS24863 LINKdotNET-AS,EG > 213.255.144.0/20 AS24863 LINKdotNET-AS,EG > 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US > 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US > 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US > 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US > 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US > 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US > 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US > 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US > 216.178.96.0/21 AS17035 -Reserved AS-,ZZ > 216.178.104.0/21 AS17035 -Reserved AS-,ZZ > 216.203.80.0/20 AS27021 -Reserved AS-,ZZ > 216.203.80.0/21 AS27021 -Reserved AS-,ZZ > 216.203.87.0/24 AS27021 -Reserved AS-,ZZ > 216.203.88.0/21 AS27021 -Reserved AS-,ZZ > 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc.,US > 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US > > > 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 geoffk at geoffk.org Fri May 16 23:41:46 2014 From: geoffk at geoffk.org (Geoffrey Keating) Date: 16 May 2014 16:41:46 -0700 Subject: Access hardware for small FTTP deployment In-Reply-To: References: Message-ID: Chris writes: > I'm interested to see what other people are doing for these types of small > setups. Does anyone know of any other reasonably priced access switches, > 32+ SFP ports, and able to withstand 60degC or higher operating temperature? An alternative you might consider is a small A/C unit, especially if high temperatures aren't common where you are. Around here it's rare to see a roadside cabinet without one. Depending on where you are you might also find you need heat, since it's even harder to find components specified for below-freezing than for high temperatures. (I was also reminded that heat is helpful if your equipment will occasionally be powered down or under a light load, because as it cools down there can be condensation.) From cb.list6 at gmail.com Sat May 17 00:34:43 2014 From: cb.list6 at gmail.com (Ca By) Date: Fri, 16 May 2014 17:34:43 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> <537648D6.9070308@ispn.net> <53765D59.50406@ispn.net> Message-ID: On May 16, 2014 12:21 PM, "Matthew Petach" wrote: > > On Fri, May 16, 2014 at 11:52 AM, Christopher Morrow < > morrowc.lists at gmail.com> wrote: > > > On Fri, May 16, 2014 at 2:47 PM, Blake Hudson wrote: > > > in the context of this discussion I think it's silly for a residential > > ISP > > > to purport themselves to be a neutral carrier of traffic and expect > > peering > > > ratios to be symmetric > > > > is 'symmetric traffic ratios' even relevant though? Peering is about > > offsetting costs, right? it might not be important that the ratio be > > 1:1 or 2:1... or even 10:1, if it's going to cost you 20x to get the > > traffic over longer/transit/etc paths... or if you have to build into > > some horrific location(s) to access the content in question. > > > > Harping on symmetric ratios seems very 1990... and not particularly > > germaine to the conversation at hand. > > > > > Traffic asymmetry across peering connections > was what lit the fuse on this whole powder keg, > if I understand correctly; at the point the traffic > went asymmetric, the refusals to augment > capacity kicked in, and congestion became > a problem. > What lit this powder keg?: Netflix bought transit from cogent and expected it to work. C'mon. This happens every month on this list and every month people tell others not to rely on cogent. Right? Netflix is smart, they know cogent is willing to burn down their network and blow up their customers for 15 minutes of fame $0.03 a meg. This makes me think the whole thing is a net neutrality strawman. They set the stage and all the players played their part. Now, what will be the result? I expect some concession from the comcast/twc deal. They made a big deal about net neutrality / netflix / strawman so they can trump up a "meaningful" concession to allow the merger. > I've seen the same thing; pretty much every > rejection is based on ratio issues, even when > offering to cold-potato haul the traffic to the > home market for the users. > > If the refusals hinged on any other clause > of the peering requirements, you'd be right; > but at the moment, that's the flag networks > are waving around as their speedbump-du-jour. > So, it may be very "1990", but unfortunately > that seems to be the year many people in > the industry are mentally stuck in. :( > > Matt From philfagan at gmail.com Sat May 17 02:18:03 2014 From: philfagan at gmail.com (Phil Fagan) Date: Fri, 16 May 2014 20:18:03 -0600 Subject: A simple proposal In-Reply-To: References: Message-ID: I agree with Rahul, seems like pointless cycles along the entire path. On Thu, May 15, 2014 at 11:35 PM, Rahul Sawarkar wrote: > You mean consume electricity in cpu cycles on the end devices and all the > network middleboxes in between all over the world/Internet for dud data? > For what? Just to stop a debate instead of resolving it thought > intellectual brainstorming? For one thing it will slow down the TCP > connections as ACKs incur a longer RTT. Then there is the whole question of > managing and lowering power consumption as a green initiative, and > capacity issues are yet another thing. > > ~Rahul > > > On Fri, May 16, 2014 at 10:56 AM, Matthew Petach >wrote: > > > There's been a whole lot of chatter recently > > about whether or not it's sensible to require > > balanced peering ratios when selling heavily > > unbalanced services to customers. > > > > There's a very simple solution, it seems. > > Just have every website, every streaming > > service, every bit of consumable internet > > data have built-in reciprocity. > > > > You want to stream a movie? No problem; > > the video player opens up a second data > > port back to a server next to the streaming > > box; its only purpose is to accept a socket, > > and send all bits received on it to /dev/null. > > The video player sends back an equivalent > > stream of data to what is being received in. > > The server receiving the upstream data stream > > checks the bitrate coming into it from the player, > > and communicates back to the video streaming > > box every few minutes to lower the outbound > > bitrate going to the player to match what the > > inbound bitrate coming from the client is. > > That way, traffic volumes stay nicely balanced, > > and everyone is happy. For extra credit, and > > to deal with multiple layers of NAT in the v4 > > world, you could even piggyback on the same > > stream, though that would take just a bit more > > work. > > > > Mobile apps could be programmed the same > > way; you download a certain amount of data, > > an equivalent volume of data is sent back > > upstream to balance it out, and preserve > > the holy ratio. Even web pages could use > > javascript footers to send back upstream an > > equivalent amount of data to what was > > downloaded. > > > > Once and for all, we could put an end to > > the ceaseless bickering about ratios, as > > everyone, everywhere would be forced > > into glorious unity, a perfect 1:1 ratio > > wherever the eye should look. > > > > As far as I can tell, this should solve > > *everyone's* concerns from all sides, > > all in one simple effort. > > > > Matt > > > > > > -- > ~~~~~~ > Regards > Rahul > -- Phil Fagan Denver, CO 970-480-7618 From ops.lists at gmail.com Sat May 17 02:24:09 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 17 May 2014 07:54:09 +0530 Subject: A simple proposal In-Reply-To: References: Message-ID: Wow nanog, dissecting the architecture of a sarcastic proposal. Maybe the joke would have been clearer if Matt had used the phrase "a modest proposal" .. On Saturday, May 17, 2014, Phil Fagan wrote: > I agree with Rahul, seems like pointless cycles along the entire path. > > > On Thu, May 15, 2014 at 11:35 PM, Rahul Sawarkar > >wrote: > > > You mean consume electricity in cpu cycles on the end devices and all > the > > network middleboxes in between all over the world/Internet for dud data? > > For what? Just to stop a debate instead of resolving it thought > > intellectual brainstorming? For one thing it will slow down the TCP > > connections as ACKs incur a longer RTT. Then there is the whole question > of > > managing and lowering power consumption as a green initiative, and > > capacity issues are yet another thing. > > > > ~Rahul > > > > > > On Fri, May 16, 2014 at 10:56 AM, Matthew Petach > > >wrote: > > > > > There's been a whole lot of chatter recently > > > about whether or not it's sensible to require > > > balanced peering ratios when selling heavily > > > unbalanced services to customers. > > > > > > There's a very simple solution, it seems. > > > Just have every website, every streaming > > > service, every bit of consumable internet > > > data have built-in reciprocity. > > > > > > You want to stream a movie? No problem; > > > the video player opens up a second data > > > port back to a server next to the streaming > > > box; its only purpose is to accept a socket, > > > and send all bits received on it to /dev/null. > > > The video player sends back an equivalent > > > stream of data to what is being received in. > > > The server receiving the upstream data stream > > > checks the bitrate coming into it from the player, > > > and communicates back to the video streaming > > > box every few minutes to lower the outbound > > > bitrate going to the player to match what the > > > inbound bitrate coming from the client is. > > > That way, traffic volumes stay nicely balanced, > > > and everyone is happy. For extra credit, and > > > to deal with multiple layers of NAT in the v4 > > > world, you could even piggyback on the same > > > stream, though that would take just a bit more > > > work. > > > > > > Mobile apps could be programmed the same > > > way; you download a certain amount of data, > > > an equivalent volume of data is sent back > > > upstream to balance it out, and preserve > > > the holy ratio. Even web pages could use > > > javascript footers to send back upstream an > > > equivalent amount of data to what was > > > downloaded. > > > > > > Once and for all, we could put an end to > > > the ceaseless bickering about ratios, as > > > everyone, everywhere would be forced > > > into glorious unity, a perfect 1:1 ratio > > > wherever the eye should look. > > > > > > As far as I can tell, this should solve > > > *everyone's* concerns from all sides, > > > all in one simple effort. > > > > > > Matt > > > > > > > > > > > -- > > ~~~~~~ > > Regards > > Rahul > > > > > > -- > Phil Fagan > Denver, CO > 970-480-7618 > -- --srs (iPad) From deleskie at gmail.com Sat May 17 02:41:18 2014 From: deleskie at gmail.com (deleskie at gmail.com) Date: Fri, 16 May 2014 23:41:18 -0300 Subject: A simple proposal In-Reply-To: References: Message-ID: <20140517024118.5849234.5697.22759@gmail.com> You shouldn't of stopped them I was eagerly ‎ waiting to find out how rtt was going to be increased :) -jim Sent from my BlackBerry 10 smartphone on the Rogers network.   Original Message   From: Suresh Ramasubramanian Sent: Friday, May 16, 2014 11:26 PM To: Phil Fagan Cc: nanog at nanog.org Subject: Re: A simple proposal Wow nanog, dissecting the architecture of a sarcastic proposal. Maybe the joke would have been clearer if Matt had used the phrase "a modest proposal" .. On Saturday, May 17, 2014, Phil Fagan wrote: > I agree with Rahul, seems like pointless cycles along the entire path. > > > On Thu, May 15, 2014 at 11:35 PM, Rahul Sawarkar > >wrote: > > > You mean consume electricity in cpu cycles on the end devices and all > the > > network middleboxes in between all over the world/Internet for dud data? > > For what? Just to stop a debate instead of resolving it thought > > intellectual brainstorming? For one thing it will slow down the TCP > > connections as ACKs incur a longer RTT. Then there is the whole question > of > > managing and lowering power consumption as a green initiative, and > > capacity issues are yet another thing. > > > > ~Rahul > > > > > > On Fri, May 16, 2014 at 10:56 AM, Matthew Petach > > >wrote: > > > > > There's been a whole lot of chatter recently > > > about whether or not it's sensible to require > > > balanced peering ratios when selling heavily > > > unbalanced services to customers. > > > > > > There's a very simple solution, it seems. > > > Just have every website, every streaming > > > service, every bit of consumable internet > > > data have built-in reciprocity. > > > > > > You want to stream a movie? No problem; > > > the video player opens up a second data > > > port back to a server next to the streaming > > > box; its only purpose is to accept a socket, > > > and send all bits received on it to /dev/null. > > > The video player sends back an equivalent > > > stream of data to what is being received in. > > > The server receiving the upstream data stream > > > checks the bitrate coming into it from the player, > > > and communicates back to the video streaming > > > box every few minutes to lower the outbound > > > bitrate going to the player to match what the > > > inbound bitrate coming from the client is. > > > That way, traffic volumes stay nicely balanced, > > > and everyone is happy. For extra credit, and > > > to deal with multiple layers of NAT in the v4 > > > world, you could even piggyback on the same > > > stream, though that would take just a bit more > > > work. > > > > > > Mobile apps could be programmed the same > > > way; you download a certain amount of data, > > > an equivalent volume of data is sent back > > > upstream to balance it out, and preserve > > > the holy ratio. Even web pages could use > > > javascript footers to send back upstream an > > > equivalent amount of data to what was > > > downloaded. > > > > > > Once and for all, we could put an end to > > > the ceaseless bickering about ratios, as > > > everyone, everywhere would be forced > > > into glorious unity, a perfect 1:1 ratio > > > wherever the eye should look. > > > > > > As far as I can tell, this should solve > > > *everyone's* concerns from all sides, > > > all in one simple effort. > > > > > > Matt > > > > > > > > > > > -- > > ~~~~~~ > > Regards > > Rahul > > > > > > -- > Phil Fagan > Denver, CO > 970-480-7618 > -- --srs (iPad) From mysidia at gmail.com Sat May 17 03:05:39 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 16 May 2014 22:05:39 -0500 Subject: A simple proposal In-Reply-To: References: Message-ID: On Fri, May 16, 2014 at 12:26 AM, Matthew Petach wrote: > You want to stream a movie? No problem; > the video player opens up a second data > port back to a server next to the streaming > box; its only purpose is to accept a socket, > and send all bits received on it to /dev/null. > The video player sends back an equivalent > stream of data to what is being received in. 1. Take the understanding that the media player will return the stream it received. For the sake of expediency and avoiding unnecessary waste (Enhanced efficiency), I suggest the introduction of a new frame format, the "Null reduced frame" and "Null reduced IP packet". This is an IP packet which logically contains N bytes of payload, that is to be transmitted without its payload, but is to be "understood" as having contained those N octets of payload data, for administrative and billing purposes; where N is some number between 1 octet and (2^32 - 1) octets. The media player can then emit these Null-reduced IP datagrams that contain no ordinary physically payload --- a flag will be set in the return packet and the frame when transmitted to indicate, that although the IP datagram physically contains no actual data, it MUST be counted on all device interface counters and Netflow reports as X octets, and treated as having contained N octets for the purposes of billing and peering negotiations. -- 2. Excellent. Especially if the video player receives streams over UDP and doesn't verify the source IP address before sending the stream back, what could possibly go wrong?. 3. On second thought.... why not send the return stream to another subscriber? Stream the thing only to buffer the content to a subset of the users' media players. The users' media players then shape the return stream in order to distribute the content ----- they could even SEND more data back to the content provider than they receive, if this benefits the content provider in peering negotiations. -- -JH From jfesler at gigo.com Sat May 17 04:51:36 2014 From: jfesler at gigo.com (Jason Fesler) Date: Fri, 16 May 2014 21:51:36 -0700 Subject: First ISP-hosted "transparent" test-IPv6.com mirror Message-ID: TL:DR? “Thanks, Comcast!” and “Who’s Next?” The test-ipv6.com site started out 4 years ago, at a table in Seattle, after an IPv6 round table meeting hosted by Internet Society. John Brzozowski and myself were each trying to come up with a way to help end users figure out that their IPv6 internet was good or bad. Ultimately I kept plugging away at it, as John was distracted with some kind of broadband IPv6 rollout for his employer (Comcast). And the test-ipv6.com site went live about a month later, with solicitation to a few operations lists for feedback. All in all, pretty successful. I’ve had two concerns since deploying test-ipv6.com: one, how to scale; and two, how to ensure the user’s connectivity back to the service is awesome (or at least, not bad). John was thinking the same thing - worried about sending too many of his customers to my site, and crushing it in the process. Not good for either of us. Both of those are relatively easy to solve. Simply deploy tons of mirrors around the world, problem solved - if you have the cash and/or smart business plan to back it. I don’t monetize the site with advertising; nor do I charge fees. Nor do I have a crack CFO who can help me IPO, and make me rich in the process. I don’t really have the time or energy to solicit for corporate handouts. As it turns out, it appears that I’m bad when it comes to making money on this project. So any solution has to be cheap. Asking folks to run regional mirrors (such as “test-ipv6.cz” or “test-ipv6.co.za”) is great; it offers a community local resources that are more immune to global connectivity issues. However, people must explicitly decide to visit these mirrors; to chose the location they want to test from. Those regional mirrors are mostly light duty as a result. They are still invaluable - they provide the back end that the global connectivity test uses, for any IPv6-validated customer visiting any of the mirrors. With this global test, we effectively crowd source getting IPv6 peering problems fixed. John and I decided to take things a step further; something I’m happy to see finally make it across the finish line after a fair bit of upfront dev work. Comcast is now running two mirrors and preparing a third - which directly act as “test-ipv6.com”. Nothing changes for the user. John has to worry less about transient (and transit!) connectivity back to test-ipv6.com. This is done with a poor-man’s GSLB (Global Server Load Balancer). We’re using an in-house built DNS server that looks at the internet routing table to see what ISP the DNS queries come from. Based on the source BGP ASN, we can decide which ISP mirror gets the traffic. (PS: thanks to routeviews.org and everyone who feeds data to it; that stuff is great!) In the end: we both get to worry less about Comcast traffic volume to test-ipv6.com; as well as ensure a good user experience for the customers visiting. What’s next? That’s where you come in :-). If you’re ... * working at a large ISP * doing real IPv6 deployment * or considering using “helpdesk.test-ipv6.com” with customers I’d love to help you set up a transparent mirror (acting as “test-ipv6.com”). For you, it means controlling the user experience using this site; as well as removing any capacity concerns. For me, it means the same thing. Win, win. More info at http://github.com/falling-sky/source/wiki/TransparentMirrors (http://tinyurl.com/m7nnhfn). If you want to help, or have questions, don’t hesitate to ask. -jason (link for sharing, if you're inclined: http://test-ipv6.com/comcast.html) From baldur.norddahl at gmail.com Sat May 17 07:00:10 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 17 May 2014 09:00:10 +0200 Subject: Access hardware for small FTTP deployment In-Reply-To: References: Message-ID: Hi I would use PON or WDM and move the active equipment to a more sane location. We use Zhone which have a one unit four port OLT (MXK-194). Or if you do not mind using GEPON instead of GPON then look at some Chinese suppliers. You can probably get a GEPON switch for about 1000 USD. Another option is DWDM using either bidirectional or fiber pairs. But I think you will find that the total cost of the required SFP modules will be higher than using PON. Regards, Baldur On 16 May 2014 05:18, Chris wrote: > Hi all, > > We are looking at doing a small FTTP deployment in a community of about 30 > homes and I'm searching for options regarding access layer hardware. > > Initially we thought of a simple point-to-point ethernet setup with > 1000Base-BX to each premises and a 48-port access switch. However, finding > an appropriate piece of hardware has proven challenging because of our > requirement of a 60+ degrees Celcius operating temperature (due to outdoor > cabinet placement). > > The only one I found that meets the temperature requirement was Cisco's ME > 2600X with 44 SFP ports, 4 SFP+ and 65degC max, but it's a bit pricey for > our liking. Other offerings from HP (5800-24G-SFP), Juniper (EX4550), > Brocade (CES-2048F) were nice, but all only had 40-45degC max operating > temp. > > I'm interested to see what other people are doing for these types of small > setups. Does anyone know of any other reasonably priced access switches, > 32+ SFP ports, and able to withstand 60degC or higher operating > temperature? > > We are also considering GPON, but given that we would only need one > interface for such a small deployment, most of the hardware out there seems > like overkill. Are there good small OLTs? > > Cheers, > Chris > From eugen at imacandi.net Sat May 17 07:14:12 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sat, 17 May 2014 10:14:12 +0300 Subject: Access hardware for small FTTP deployment In-Reply-To: References: Message-ID: On Fri, May 16, 2014 at 6:18 AM, Chris wrote: > Hi all, > > We are looking at doing a small FTTP deployment in a community of about 30 > homes and I'm searching for options regarding access layer hardware. > > Initially we thought of a simple point-to-point ethernet setup with > 1000Base-BX to each premises and a 48-port access switch. However, finding > an appropriate piece of hardware has proven challenging because of our > requirement of a 60+ degrees Celcius operating temperature (due to outdoor > cabinet placement). > > The only one I found that meets the temperature requirement was Cisco's ME > 2600X with 44 SFP ports, 4 SFP+ and 65degC max, but it's a bit pricey for > our liking. Other offerings from HP (5800-24G-SFP), Juniper (EX4550), > Brocade (CES-2048F) were nice, but all only had 40-45degC max operating > temp. > > I'm interested to see what other people are doing for these types of small > setups. Does anyone know of any other reasonably priced access switches, > 32+ SFP ports, and able to withstand 60degC or higher operating > temperature? > > We are also considering GPON, but given that we would only need one > interface for such a small deployment, most of the hardware out there seems > like overkill. Are there good small OLTs? > > For your particular case, you might want to look at industrial ethernet switches with IP67 enclosure specs. >From Cisco you can look at IE3000 series. They can do VLANs, routing, have SFP ports for uplinks. Another option would be the OCTOPUS series from Belden, they claim -40C to +70C degrees operating temperature. Regards, Eugeniu From srahul.in at gmail.com Sat May 17 10:11:04 2014 From: srahul.in at gmail.com (Rahul Sawarkar) Date: Sat, 17 May 2014 15:41:04 +0530 Subject: A simple proposal In-Reply-To: <20140517024118.5849234.5697.22759@gmail.com> References: <20140517024118.5849234.5697.22759@gmail.com> Message-ID: Ah! So somebody nudged me and pointed out that this is a reference to a satirical story and a standard part of the American curriculum. On Sat, May 17, 2014 at 8:11 AM, wrote: > You shouldn't of stopped them I was eagerly ‎ waiting to find out how rtt > was going to be increased :) > > -jim Heh. Well I was thinking along the lines of the effect of 100 streaming users all filling up the router queues in the path to the server, with full size packets (or replicas of the incoming) where in the normal case a smaller ACK packet would be sent for every other TCP segment transmitted by the sender. Now I get the joke. Rahul From frnkblk at iname.com Sat May 17 15:17:56 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 17 May 2014 10:17:56 -0500 Subject: FTTH ONTs and routers In-Reply-To: <53763976.8020805@tccmail.ca> References: <5374F538.5010108@vaxination.ca> <53763976.8020805@tccmail.ca> Message-ID: <005e01cf71e3$2ec2b1a0$8c4814e0$@iname.com> FYI, Calix has GPON support for the 836GE ONT on the E7 today, and it will be supported in GPON mode in Release 9.0 on the C7. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Pete at TCC Sent: Friday, May 16, 2014 11:15 AM To: Jean-Francois Mezei; nanog at nanog.org Subject: Re: FTTH ONTs and routers There are many ONTs out there with various abilities. I can only comment on what I deploy, and what various telcos deploy that I am familiar with. A few years ago, all of our AE and GPON ONTs were deployed as bridges. Port 1 was generally an Internet VLAN, and port 2,3,4 were IPTV VLANs. We have been using Occam (now Calix), but are considering other options at this point. Currently we bridge all services on GPON deployments, but rent routers for the Internet service if customers do not wish to provide their own. The 700-series ONTs are able to bounce between GPON and AE deployments with a firmware change, so they are very flexible. Calix has apparently released RG code (Residential Gateway, basic home router functionality) for for the 700s, but we don't use that code. We also deploy 836 ONTs, which had RG code built-in on release, and also WiFi. The 836s currently only do AE, but were originally supposed to do GPON/AE similar to the 700-series. Today, the standard AE deployment is an 836 with RG code enabled for WiFi and Port 1. WAN is DHCP, authorized with Option 82/RADIUS for bandwidth profiles. LAN does NAT, and hands out a 192.168.88.0/24 subnet to break as few consumer routers as possible. We have no problem enabling bridging for Port 1 if the customer requests it. We bridge Port 2,3,4 for IPTV because the RG functionality breaks certain features, namely call display on the TVs. The 836s can do Static, PPPoE, or DHCP on the WAN side. We use MGCP for voice. -- Pete Baldwin On 14-05-15 01:11 PM, Jean-Francois Mezei wrote: > It had been my impression that ONTs, like most other consumer modems, > came with built-in router capabilities (along with ATA for voice). > > The assertion that ONTs have built-in routing capabilities has been > challenged. > > Can anyone confirm whether ONTs generally have routing (aka: home router > that does the PPPoE or DHCP and then NAT for home) capabilities? > > Are there examples where a telco has deployed ONTs with the router > built-in and enabled ? Or would almost all FTTH deployments be made with > any routing disabled and the ONT acting as a pure ethernet bridge ? > > > (I appreciate your help on this as I am time constrained to do research). > From mark.tinka at seacom.mu Sun May 18 05:34:24 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 18 May 2014 07:34:24 +0200 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <53765D59.50406@ispn.net> References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <53765D59.50406@ispn.net> Message-ID: <201405180734.28128.mark.tinka@seacom.mu> On Friday, May 16, 2014 08:47:53 PM Blake Hudson wrote: > How residential ISPs recoup costs (or simply increase > revenue/profit) is another question entirely. I think > the most insightful comment in this discussion was made > by Mr. Rick Astley (I assume a pseudonym), when he > states that ISPs have several options to increase > revenue A) Increase price of their product, B) Implement > usage restrictions, or C) Charge someone else/Make > someone else your customer. I think he successfully > argues that option C may be the best. As we've seen, the > wireless market in the US went for option B. We've yet > to see where the wireline market will go. Some of the operators, here in Africa, who are venturing into FTTH, are continuing on with their data caps. I suppose if you're primarily a mobile carrier who uses data caps to charge for access (and makes lots of money in the process for, pretty much, selling nothing), the model becomes attractive regardless of the medium. New providers who are not encumbered by this type of thinking, obviously, have a more flexible and forward- thinking business model. 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 Sun May 18 05:39:13 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 18 May 2014 07:39:13 +0200 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <53765D59.50406@ispn.net> Message-ID: <201405180739.13730.mark.tinka@seacom.mu> On Friday, May 16, 2014 08:52:31 PM Christopher Morrow wrote: > is 'symmetric traffic ratios' even relevant though? > Peering is about offsetting costs, right? it might not > be important that the ratio be 1:1 or 2:1... or even > 10:1, if it's going to cost you 20x to get the traffic > over longer/transit/etc paths... or if you have to build > into some horrific location(s) to access the content in > question. > > Harping on symmetric ratios seems very 1990... and not > particularly germaine to the conversation at hand. Agree. We don't have a ratio requirement, for example. We have a "if it makes sense" requirement. I'm forced to peer with certain African providers in London and Amsterdam because they don't want to peer in Africa, where we are literally are an x-connect away from each other. And the reasons are not even because either of us is larger or smaller than the other... it's just legacy thinking and we're the new guy that has grown rapidly. Now we both have to pay for traffic to get sent to Europe and back. How nice... 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 Sun May 18 05:40:55 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 18 May 2014 07:40:55 +0200 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <537662FC.20704@ispn.net> References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <537662FC.20704@ispn.net> Message-ID: <201405180740.55795.mark.tinka@seacom.mu> On Friday, May 16, 2014 09:11:56 PM Blake Hudson wrote: > But hey, why peer at little or no cost if they > can instead hold out and possibly peer at a negative > cost? Because they hope that, one day, you'll cave and become a customer. Isn't that more prestigious :-)? 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 Sun May 18 05:45:31 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 18 May 2014 07:45:31 +0200 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <201405162125.33834.mark.tinka@seacom.mu> Message-ID: <201405180745.31602.mark.tinka@seacom.mu> On Friday, May 16, 2014 09:44:55 PM Scott Helms wrote: > I don't think that anyone disputes that when you improve > the upstream you do get an uptick in usage in that > direction. What I take issue with is the notion that > the upstream is anything like downstream even when the > capacity is there. Certainly not - what I'm saying is that there can be a lot more upstream utilization than we are typically seeing today, if that stopper is unblocked. We can, then, take it from there... 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 randy at psg.com Sun May 18 09:55:52 2014 From: randy at psg.com (Randy Bush) Date: Sun, 18 May 2014 12:55:52 +0300 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <201405180739.13730.mark.tinka@seacom.mu> References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <53765D59.50406@ispn.net> <201405180739.13730.mark.tinka@seacom.mu> Message-ID: > Harping on symmetric ratios seems very 1990. not so much. that kink came in later randy From randy at psg.com Sun May 18 09:57:51 2014 From: randy at psg.com (Randy Bush) Date: Sun, 18 May 2014 12:57:51 +0300 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <201405180739.13730.mark.tinka@seacom.mu> References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <53765D59.50406@ispn.net> <201405180739.13730.mark.tinka@seacom.mu> Message-ID: > I'm forced to peer with certain African providers in London > and Amsterdam because they don't want to peer in Africa, > where we are literally are an x-connect away from each > other. And the reasons are not even because either of us is > larger or smaller than the other... it's just legacy > thinking and we're the new guy that has grown rapidly. > > Now we both have to pay for traffic to get sent to Europe > and back. How nice... which is amusing given you have massive east coast to europe fiber capacity. randy From mark.tinka at seacom.mu Sun May 18 12:17:44 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 18 May 2014 14:17:44 +0200 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <201405180739.13730.mark.tinka@seacom.mu> Message-ID: <201405181417.44291.mark.tinka@seacom.mu> On Sunday, May 18, 2014 11:57:51 AM Randy Bush wrote: > which is amusing given you have massive east coast to > europe fiber capacity. My point exactly - as an operator, it costs me close to nothing given all the capacity we have (and can further light) on this path, but the other guys do not necessarily have that advantage. But that is beside the point - I'm willing to spend the money intra-Africa to avoid the silliness of switching in Europe. It's 2014... 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 Sun May 18 15:35:08 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 18 May 2014 10:35:08 -0500 Subject: A simple proposal In-Reply-To: References: Message-ID: <9B45901D-BC70-47D7-BE60-81BCAB783025@ufp.org> On May 16, 2014, at 12:26 AM, Matthew Petach wrote: > You want to stream a movie? No problem; > the video player opens up a second data > port back to a server next to the streaming > box; its only purpose is to accept a socket, > and send all bits received on it to /dev/null. I can improve on your proposal. Have the player return four copies of the data. Put the eyeball networks out of ratio in the other direction, then charge them using their same logic. Also, congest all their end user uplinks, which are slower of course, as that is congestion in their own network they will have to spend money to fix. -- 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 owen at delong.com Sun May 18 17:24:48 2014 From: owen at delong.com (Owen DeLong) Date: Sun, 18 May 2014 10:24:48 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> Message-ID: On May 16, 2014, at 10:06 AM, Scott Helms wrote: > Blake, > > I might agree with your premise if weren't for a couple of items. > > 1) Very few consumers are walking around with a HD or 4K camera today. Not true. Most cell phones have HD cameras. Most CCD video cameras sold in the last 5 years are HD capable. > 2) Most consumers who want to share video wouldn't know how to host it > themselves, which isn't an insurmountable issue but is a big barrier to > entry especially given the number of NAT'ed connections. I think this is > much more of a problem than available bandwidth. Yes, but NAT is a temporary problem that is already gone for ~40% of the subscribers on the largest CMTS networks in the US and is disappearing for everyone else fairly quickly. It’s disappearing even faster for anyone who buys an X-Box One or gets an IPv6 Tunnel. An application on an X-Box One could literally solve the video hosting problem overnight. This is an example of the limitations on innovation posed by NAT which is one of the reasons it’s becoming more and more important to move forward with IPv6. Since there are enough drivers and that transition is already in progress, treating it like it’s a bigger problem than available bandwidth really doesn’t make sense to me. Available bandwidth is the much more insurmountable barrier at this point. > 3) Most consumers who want to share videos seem to be satisfied with > sharing via one of the cloud services whether that be YouTube (which was > created originally for that use), Vimeo, or one of the other legions of > services like DropBox. Sure, but there are other more interactive services that are under greater and greater demand and realistically, people will come to expect multi-party HD video chat as a given over time. The reason they accept it not working so far is because they haven’t seen it actually working. As it becomes more ubiquitous in other parts of the world, demand will grow in the US. Shared gaming experiences will be another driver. While games are engineered today to deal with the limited bandwidth available, developers are seeking ways to deliver a richer, more immersive interactive experience and that’s going to require more bandwidth. Once NAT can no longer be blamed as the primary barrier, bandwidth will be their next target. > 4) Finally, upstream bandwidth has increased on many/most operators. I > just ran the FCC's speedtest (mLab not Ookla) and got 22 mbps on my > residential cable internet service. I subscribe to one of the major MSOs > for a normal residential package. Good for you. I’m paying for business service at the middle tier in my area and get 27Mbps down and only 7Mbps up, both in what my provider tells me they are selling me and in most of my mLab _AND_ Ookla tests. If I went with DSL, the most I could get would be 1.5Mbps down and only 384Kbps up. I’ve been getting those same levels of service for more than 5 years now. Upstream bandwidth is definitely a limitation and it definitely hasn’t improved for many customers. Owen From owen at delong.com Sun May 18 18:40:35 2014 From: owen at delong.com (Owen DeLong) Date: Sun, 18 May 2014 11:40:35 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> <537648D6.9070308@ispn.net> <53765D59.50406@ispn.net> Message-ID: <31F5944C-2FF8-4530-BD3F-EFC2792BD973@delong.com> Traffic Symmetry is a distraction that the $ACCESS_PROVIDERS would like us to focus on. The reality is that $ACCESS_PROVIDERS want us to focus on that so that we don’t see what is really going on which is a battle to deeper (or avoid increasing peering capacity with) networks they think they can force to pay them more money. This is an age old tactic and it isn’t unique to $ACCESS_PROVIDERS. The larger $BACKBONE_PROVIDERS did it in the past, too. The first one was a railroad company turned telecom. Then came the remnants of PSI. Today, it’s the largest $ACCESS_PROVIDERS. Usually, this just results in harm to both sides and eventually a loss of subscribers. The $ACCESS_PROVIDERS have an advantage in the latter as they mostly avoid loss of subscribers through the fact that the subscribers don’t have anywhere else that they can usefully go. Owen On May 16, 2014, at 12:15 PM, Matthew Petach wrote: > On Fri, May 16, 2014 at 11:52 AM, Christopher Morrow < > morrowc.lists at gmail.com> wrote: > >> On Fri, May 16, 2014 at 2:47 PM, Blake Hudson wrote: >>> in the context of this discussion I think it's silly for a residential >> ISP >>> to purport themselves to be a neutral carrier of traffic and expect >> peering >>> ratios to be symmetric >> >> is 'symmetric traffic ratios' even relevant though? Peering is about >> offsetting costs, right? it might not be important that the ratio be >> 1:1 or 2:1... or even 10:1, if it's going to cost you 20x to get the >> traffic over longer/transit/etc paths... or if you have to build into >> some horrific location(s) to access the content in question. >> >> Harping on symmetric ratios seems very 1990... and not particularly >> germaine to the conversation at hand. >> >> > Traffic asymmetry across peering connections > was what lit the fuse on this whole powder keg, > if I understand correctly; at the point the traffic > went asymmetric, the refusals to augment > capacity kicked in, and congestion became > a problem. > > I've seen the same thing; pretty much every > rejection is based on ratio issues, even when > offering to cold-potato haul the traffic to the > home market for the users. > > If the refusals hinged on any other clause > of the peering requirements, you'd be right; > but at the moment, that's the flag networks > are waving around as their speedbump-du-jour. > So, it may be very "1990", but unfortunately > that seems to be the year many people in > the industry are mentally stuck in. :( > > Matt From owen at delong.com Sun May 18 18:50:29 2014 From: owen at delong.com (Owen DeLong) Date: Sun, 18 May 2014 11:50:29 -0700 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: <53766FE2.1030209@mtcc.com> References: <201405161702.03926.mark.tinka@seacom.mu> <201405161726.18601.mark.tinka@seacom.mu> <535D9F07.1000808@mtcc.com> <53766B15.8000504@mtcc.com> <53766FE2.1030209@mtcc.com> Message-ID: On May 16, 2014, at 1:06 PM, Michael Thomas wrote: > Scott Helms wrote: >> Mike, >> In my experience you're not alone, just in a really tiny group. As I said I have direct eyeballs on ~500k devices and the ability to see another 10 million anytime I want and the percentage of people who cap their upstream in both of those sample groups for more than 15 minutes (over the last 3 years) is about 0.2%. Interestingly if a customer does it once they have about a 70% chance of doing it regularly. > > Well, given Sling, Dropbox, iCloud, pervasive video calls (you have heard about webrtc, yes? > 24/7 babycams!), youtube, etc, etc, I won't be a "tiny group" for long. > > Mike Yes… Scott is making what I consider a classic mistake. Attempting to define the future in terms of the limitations that users have adapted to from the past. Eventually, users do realize that the limitations are no longer necessary and then they won’t accept them. Unfortunately, this takes far longer than is desirable. Fortunately, this gives proactive and innovative service providers the opportunity to adapt the technology and remove those limitations before the users care. Unfortunately, it also gives other service providers the opportunity to try and hold users back even after they care. IIRC, there are awards in both categories. Owen From kilobit at gmail.com Sun May 18 22:55:01 2014 From: kilobit at gmail.com (bas) Date: Mon, 19 May 2014 00:55:01 +0200 Subject: Observations of an Internet Middleman (Level3) In-Reply-To: References: <536BBC62.4070805@KingsMountain.com> <5370C664.5050405@foobar.org> <68E386555FFBD7352D8642B4@192.168.1.50> <5373156B.8000005@vaxination.ca> <2B92D9D4-A4CA-4683-833F-9ADADA2EADF4@cable.comcast.com> <3E49C7D2-5738-4BBC-BF01-7124DA1123B1@delong.com> <4EAA99EC-6E3C-44DC-8BD7-932E4B99A945@cable.comcast.com> <5374E013.1050708@sberkman.net> <8AFC1EC8-5F2E-4645-B57C-A147FC56B390@cable.comcast.com> <696D5986-AB28-4793-976D-FFE542AEB68D@cable.comcast.com> <7d1719ae1b00cd964f2140e92ffb20e5.squirrel@mail2tor2zyjdctd.onion> Message-ID: Jason, In your first reply you mention a lot of "we're all good, we comply, we don't do x etc" However you seem to have forgotten to reply to question #1 that Arvinder asked. (#2 you were able to reply) http://comcrust.com/ is already four years old it would seem enough time to get an upgrade in place. Our tata upgrades are usually in place after a couple of weeks. Thanks, Bas On Fri, May 16, 2014 at 4:58 PM, Livingood, Jason < Jason_Livingood at cable.comcast.com> wrote: > On 5/16/14, 7:56 AM, "Vinny Abello" wrote: > > >I think he's questioning why packets from speedtest.comcast.net have CS1 > >if everything is supposedly equal, and what that is used for. A quick > >Wireshark shows that to be true right now running to your Plainfield, NJ > >speedtest site, and my network peers directly with Comcast. > > > >I'm kind of curious too. What is the purpose of this? Is it the > >traditional purpose of CS1 to be less than best effort or something > >else? If this is the case it seems Comcast would be purposely putting > >themselves at a disadvantage in speed tests when congestion is > >involved... or is this possibly on purpose to make peering problems look > >even worse during congestion? > > Ah! That makes sense now. CS1 is used internally to mark best effort > Internet traffic. This has often caused confusion when folks see our > markings. If folks want to send me any data off-list that you think merits > further investigation, let me know (never know if something someplace is > an honest config error). > > Jason > > From hs.citizen at gmail.com Mon May 19 02:50:01 2014 From: hs.citizen at gmail.com (Chris) Date: Mon, 19 May 2014 12:50:01 +1000 Subject: Access hardware for small FTTP deployment In-Reply-To: References: Message-ID: Thanks all. The Calix E7-2 and Zhone MXK-194 seem like good options for GPON, we will look further at these two. Cheers On Sat, May 17, 2014 at 5:14 PM, Eugeniu Patrascu wrote: > On Fri, May 16, 2014 at 6:18 AM, Chris wrote: > >> Hi all, >> >> We are looking at doing a small FTTP deployment in a community of about 30 >> homes and I'm searching for options regarding access layer hardware. >> >> Initially we thought of a simple point-to-point ethernet setup with >> 1000Base-BX to each premises and a 48-port access switch. However, finding >> an appropriate piece of hardware has proven challenging because of our >> requirement of a 60+ degrees Celcius operating temperature (due to outdoor >> cabinet placement). >> >> The only one I found that meets the temperature requirement was Cisco's ME >> 2600X with 44 SFP ports, 4 SFP+ and 65degC max, but it's a bit pricey for >> our liking. Other offerings from HP (5800-24G-SFP), Juniper (EX4550), >> Brocade (CES-2048F) were nice, but all only had 40-45degC max operating >> temp. >> >> I'm interested to see what other people are doing for these types of small >> setups. Does anyone know of any other reasonably priced access switches, >> 32+ SFP ports, and able to withstand 60degC or higher operating >> temperature? >> >> We are also considering GPON, but given that we would only need one >> interface for such a small deployment, most of the hardware out there >> seems >> like overkill. Are there good small OLTs? >> >> > For your particular case, you might want to look at industrial ethernet > switches with IP67 enclosure specs. > > From Cisco you can look at IE3000 series. They can do VLANs, routing, have > SFP ports for uplinks. > > Another option would be the OCTOPUS series from Belden, they claim -40C to > +70C degrees operating temperature. > > Regards, > Eugeniu > From mpetach at netflight.com Mon May 19 04:15:38 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 18 May 2014 21:15:38 -0700 Subject: Observations of an Internet Middleman (Level3) (was: RIP In-Reply-To: <31F5944C-2FF8-4530-BD3F-EFC2792BD973@delong.com> References: <12805358.1820.1400254539295.JavaMail.root@benjamin.baylink.com> <5376345C.8070300@ispn.net> <53763F03.7040706@ispn.net> <537648D6.9070308@ispn.net> <53765D59.50406@ispn.net> <31F5944C-2FF8-4530-BD3F-EFC2792BD973@delong.com> Message-ID: On Sun, May 18, 2014 at 11:40 AM, Owen DeLong wrote: > Traffic Symmetry is a distraction that the $ACCESS_PROVIDERS would like us > to > focus on. > > The reality is that $ACCESS_PROVIDERS want us to focus on that so that we > don’t > see what is really going on which is a battle to deeper (or avoid > increasing peering > capacity with) networks they think they can force to pay them more money. > > This is an age old tactic and it isn’t unique to $ACCESS_PROVIDERS. The > larger > $BACKBONE_PROVIDERS did it in the past, too. The first one was a railroad > company turned telecom. Then came the remnants of PSI. Today, it’s the > largest > $ACCESS_PROVIDERS. Usually, this just results in harm to both sides and > eventually a loss of subscribers. The $ACCESS_PROVIDERS have an advantage > in the latter as they mostly avoid loss of subscribers through the fact > that the > subscribers don’t have anywhere else that they can usefully go. > > Owen > > I agree it's a distraction from the primary reason behind it; today, networks using traffic ratios as the excuse why peering 'doesn't make sense'; even if the traffic ratios are balanced, though, I'm sure there would be another requirement, such as minimum number of prefixes announced (mass deaggregation should meet that one), minimum number of downstream ASNs announced (a 4-byte ASN for every rack switch cluster should handle that one), minimum backbone size (isn't everyone already doing 100G at this point?), present on multiple continents (isn't everyone?). When you get right down to it, though, it's all just hand waving around the age-old question of "how many entities can I push to pay, without going too far, and alienating the entire rest of the internet?" In years gone by, that line was relatively conservative; hosting spammers, for example, was thought to be a sure kiss of death that would lead all other networks to shun you, effectively cutting you off from the internet community. However, I think we've all seen that our notion of the power of the community was overstated; internet-wide shunning didn't materialize, we failed at being able to cut spammers off to a level that would make it unprofitable, and we still have thread after thread about BCP 38 compliance. Seeing that, it's really not surprising that networks would become bolder, no longer fearing widespread disapproval or community disaffection for actions that might have seemed more extreme in years past. I mean, at this point we can't even seem to effectively shame people into not leaking deaggregated prefixes, in spite of the weekly email to the list naming names, and in spite of Patrick's exhortations. Given all that, it really isn't all that suprising that a certain 3-digit ASN is trying to pull games like this, refusing to augment capacity in the hopes they can use their customer base as leverage. They've realized the internet has no teeth, so they can act with impunity. It's sad to see, but somehow, it's not all that surprising. So yes, Owen--I agree with you; it's not a new tactic, it's just being carried out more brazenly and with less and less fear of community opprobrium. Matt From linford at spamhaus.org Mon May 19 16:26:46 2014 From: linford at spamhaus.org (Steve Linford) Date: Mon, 19 May 2014 18:26:46 +0200 Subject: FYI: Spamhaus joe-job spam targeting ARIN & RIPE contacts database Message-ID: <19528-7.1400516786@spamhaus.org> FYI only: There's a joe-job spam going round targeting what looks like a dump of ARIN and RIPE contact records so quite a few of you probably got it (we got a lot of copies ourselves). It is being sent probably by a Slavic spammer (judging by the grammar) and points to another Spamhaus joe-job posted last week to defamation site Ripoff Report by same Slavic spammer(s). The copies we got all come from MailChimp IPs and the From line is "Steve Linford " (apparently spammer thinks I use Gmail ;-) Regards, Steve Linford Chief Executive The Spamhaus Project http://www.spamhaus.org From eric at ericheather.com Tue May 20 00:52:23 2014 From: eric at ericheather.com (Eric C. Miller) Date: Tue, 20 May 2014 00:52:23 +0000 Subject: First ISP-hosted "transparent" test-IPv6.com mirror In-Reply-To: References: Message-ID: Jason, Love the service that you guys have. I use it as part of training helpdesk agents as well as field techs. My ISP wants to set up a transparent mirror, and I encourage other to do so as well. Do you support us adding a hosted by logo, or a link to our IPv6 speedtest server? Eric Miller, CCNP Network Engineering Consultant (407) 257-5115 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jason Fesler Sent: Saturday, May 17, 2014 12:52 AM To: nanog at nanog.org Subject: First ISP-hosted "transparent" test-IPv6.com mirror TL:DR? “Thanks, Comcast!” and “Who’s Next?” The test-ipv6.com site started out 4 years ago, at a table in Seattle, after an IPv6 round table meeting hosted by Internet Society. John Brzozowski and myself were each trying to come up with a way to help end users figure out that their IPv6 internet was good or bad. Ultimately I kept plugging away at it, as John was distracted with some kind of broadband IPv6 rollout for his employer (Comcast). And the test-ipv6.com site went live about a month later, with solicitation to a few operations lists for feedback. All in all, pretty successful. I’ve had two concerns since deploying test-ipv6.com: one, how to scale; and two, how to ensure the user’s connectivity back to the service is awesome (or at least, not bad). John was thinking the same thing - worried about sending too many of his customers to my site, and crushing it in the process. Not good for either of us. Both of those are relatively easy to solve. Simply deploy tons of mirrors around the world, problem solved - if you have the cash and/or smart business plan to back it. I don’t monetize the site with advertising; nor do I charge fees. Nor do I have a crack CFO who can help me IPO, and make me rich in the process. I don’t really have the time or energy to solicit for corporate handouts. As it turns out, it appears that I’m bad when it comes to making money on this project. So any solution has to be cheap. Asking folks to run regional mirrors (such as “test-ipv6.cz” or “test-ipv6.co.za”) is great; it offers a community local resources that are more immune to global connectivity issues. However, people must explicitly decide to visit these mirrors; to chose the location they want to test from. Those regional mirrors are mostly light duty as a result. They are still invaluable - they provide the back end that the global connectivity test uses, for any IPv6-validated customer visiting any of the mirrors. With this global test, we effectively crowd source getting IPv6 peering problems fixed. John and I decided to take things a step further; something I’m happy to see finally make it across the finish line after a fair bit of upfront dev work. Comcast is now running two mirrors and preparing a third - which directly act as “test-ipv6.com”. Nothing changes for the user. John has to worry less about transient (and transit!) connectivity back to test-ipv6.com. This is done with a poor-man’s GSLB (Global Server Load Balancer). We’re using an in-house built DNS server that looks at the internet routing table to see what ISP the DNS queries come from. Based on the source BGP ASN, we can decide which ISP mirror gets the traffic. (PS: thanks to routeviews.org and everyone who feeds data to it; that stuff is great!) In the end: we both get to worry less about Comcast traffic volume to test-ipv6.com; as well as ensure a good user experience for the customers visiting. What’s next? That’s where you come in :-). If you’re ... * working at a large ISP * doing real IPv6 deployment * or considering using “helpdesk.test-ipv6.com” with customers I’d love to help you set up a transparent mirror (acting as “test-ipv6.com”). For you, it means controlling the user experience using this site; as well as removing any capacity concerns. For me, it means the same thing. Win, win. More info at http://github.com/falling-sky/source/wiki/TransparentMirrors (http://tinyurl.com/m7nnhfn). If you want to help, or have questions, don’t hesitate to ask. -jason (link for sharing, if you're inclined: http://test-ipv6.com/comcast.html) From jfesler at gigo.com Tue May 20 01:28:58 2014 From: jfesler at gigo.com (Jason Fesler) Date: Mon, 19 May 2014 18:28:58 -0700 Subject: First ISP-hosted "transparent" test-IPv6.com mirror In-Reply-To: References: Message-ID: > Love the service that you guys have. I use it as part of training helpdesk agents as well as field techs. My ISP wants to set up a transparent mirror, and I encourage other to do so as well. Awesome. If you're not familiar with it already, be sure to try "helpdesk.test-ipv6.com" or "test-ipv6.com/helpdesk". There's also a document floating around that we're encouraging people to contribute to, specifically to be used by help desks, if you're interested. https://git.steffann.nl/go6/ipv6-troubleshooting-for-helpdesks/blob/master/IPv6-troubleshooting-for-helpdesks.md for the document as it is today. > Do you support us adding a hosted by logo, or a link to our IPv6 speedtest server? Within limits, yes. Text only; keeping it classy. You can see what I've done with http://beta.test-ipv6.com/ ; you'll see what Comcast users see when they visit the site. I'm not hung up on the exact wording, but do want to keep things minimal/classy. Mirrors operating on other domains, are welcome to put in footers at the bottom, larger logos, etc. They get loaded and displayed one the test is done running. You can see an example of this at http://test-ipv6.co.za (thanks Graham!). From di at egihosting.com Mon May 19 17:14:12 2014 From: di at egihosting.com (Di Li) Date: Mon, 19 May 2014 10:14:12 -0700 Subject: ASN lookup tool Message-ID: Hey Guys, We just launch out our new ASN/IP/IPv6 lookup tool, let us know if there's any feedback, we know there's still some small bugs in the middle, we are still work on the bugs and new features, this is just a beta version, I hope you guys can find it useful. www.asnmap.com -- Thanks, Di From j at arpa.com Tue May 20 02:40:02 2014 From: j at arpa.com (jamie rishaw) Date: Mon, 19 May 2014 21:40:02 -0500 Subject: All of .mil tld is down Message-ID: At time of post.. .mil. is down. Apparently an Anonymous "Operation Payback". .mil nameservers are unresponsive. From cryptographrix at gmail.com Tue May 20 02:57:23 2014 From: cryptographrix at gmail.com (Cryptographrix) Date: Mon, 19 May 2014 22:57:23 -0400 Subject: All of .mil tld is down In-Reply-To: References: Message-ID: Well that's the most ludicrous thing I've heard all month. *grabs popcorn* On Mon, May 19, 2014 at 10:40 PM, jamie rishaw wrote: > At time of post.. > .mil. is down. > Apparently an Anonymous "Operation Payback". > > .mil nameservers are unresponsive. > From tony at wicks.co.nz Tue May 20 03:01:35 2014 From: tony at wicks.co.nz (Tony Wicks) Date: Tue, 20 May 2014 15:01:35 +1200 Subject: All of .mil tld is down In-Reply-To: References: Message-ID: <006401cf73d7$d00c1790$702446b0$@wicks.co.nz> All those Domain servers seem to be in the one /16 and my traces show them all taking the same network path... Well that is pretty poor planning... http://www.iana.org/domains/root/db/mil.html -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of jamie rishaw Sent: Tuesday, 20 May 2014 2:40 p.m. To: NANOG list Subject: All of .mil tld is down At time of post.. .mil. is down. Apparently an Anonymous "Operation Payback". .mil nameservers are unresponsive. From shishido at gmail.com Tue May 20 04:14:16 2014 From: shishido at gmail.com (Clark Shishido) Date: Tue, 20 May 2014 04:14:16 +0000 Subject: All of .mil tld is down In-Reply-To: <006401cf73d7$d00c1790$702446b0$@wicks.co.nz> References: <006401cf73d7$d00c1790$702446b0$@wicks.co.nz> Message-ID: OpenDNS still has A records for nipr.mil authoritative nameservers. ​ % dig -t ns nipr.mil @resolver1.opendns.com ; <<>> DiG 9.9.3-P2 <<>> -t ns nipr.mil @resolver1.opendns.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37645 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;nipr.mil. IN NS ;; ANSWER SECTION: nipr.mil. 20126 IN NS EUR2.nipr.mil. nipr.mil. 20126 IN NS EUR1.nipr.mil. nipr.mil. 20126 IN NS PAC2.nipr.mil. nipr.mil. 20126 IN NS CON1.nipr.mil. nipr.mil. 20126 IN NS PAC1.nipr.mil. nipr.mil. 20126 IN NS CON2.nipr.mil. ;; Query time: 58 msec ;; SERVER: 208.67.222.222#53(208.67.222.222) ;; WHEN: Tue May 20 04:09:11 UTC 2014 ;; MSG SIZE rcvd: 151 % dig eur2.nipr.mil @resolver1.opendns.com ; <<>> DiG 9.9.3-P2 <<>> eur2.nipr.mil @resolver1.opendns.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44901 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;eur2.nipr.mil. IN A ;; ANSWER SECTION: eur2.nipr.mil. 20103 IN A 199.252.143.234 ;; Query time: 56 msec ;; SERVER: 208.67.222.222#53(208.67.222.222) ;; WHEN: Tue May 20 04:09:34 UTC 2014 ;; MSG SIZE rcvd: 58 On 20 May 2014 03:01, Tony Wicks wrote: All those Domain servers seem to be in the one /16 and my traces show them all taking the same network path... Well that is pretty poor planning... http://www.iana.org/domains/root/db/mil.html -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of jamie rishaw Sent: Tuesday, 20 May 2014 2:40 p.m. To: NANOG list Subject: All of .mil tld is down At time of post.. .mil. is down. Apparently an Anonymous "Operation Payback". .mil nameservers are unresponsive. From me at anuragbhatia.com Tue May 20 04:30:34 2014 From: me at anuragbhatia.com (Anurag Bhatia) Date: Tue, 20 May 2014 10:00:34 +0530 Subject: All of .mil tld is down In-Reply-To: References: <006401cf73d7$d00c1790$702446b0$@wicks.co.nz> Message-ID: Hi Clark It's down when looked upon from our DNS recursors in India as well. I have seen in past with many domains (not TLDs though) that when they are down due to non-reachability of authoritative servers for the zone, OpenDNS and Google DNS still give answers. Likely they have some in-built resistivity to these issues by serving the stale data when auth is unreachable. On Tue, May 20, 2014 at 9:44 AM, Clark Shishido wrote: > OpenDNS still has A records for nipr.mil authoritative nameservers. > > > % dig -t ns nipr.mil @resolver1.opendns.com > > ; <<>> DiG 9.9.3-P2 <<>> -t ns nipr.mil @resolver1.opendns.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37645 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;nipr.mil. IN NS > > ;; ANSWER SECTION: > nipr.mil. 20126 IN NS EUR2.nipr.mil. > nipr.mil. 20126 IN NS EUR1.nipr.mil. > nipr.mil. 20126 IN NS PAC2.nipr.mil. > nipr.mil. 20126 IN NS CON1.nipr.mil. > nipr.mil. 20126 IN NS PAC1.nipr.mil. > nipr.mil. 20126 IN NS CON2.nipr.mil. > > ;; Query time: 58 msec > ;; SERVER: 208.67.222.222#53(208.67.222.222) > ;; WHEN: Tue May 20 04:09:11 UTC 2014 > ;; MSG SIZE rcvd: 151 > > % dig eur2.nipr.mil @resolver1.opendns.com > > ; <<>> DiG 9.9.3-P2 <<>> eur2.nipr.mil @resolver1.opendns.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44901 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;eur2.nipr.mil. IN A > > ;; ANSWER SECTION: > eur2.nipr.mil. 20103 IN A 199.252.143.234 > > ;; Query time: 56 msec > ;; SERVER: 208.67.222.222#53(208.67.222.222) > ;; WHEN: Tue May 20 04:09:34 UTC 2014 > ;; MSG SIZE rcvd: 58 > > > > On 20 May 2014 03:01, Tony Wicks wrote: > All those Domain servers seem to be in the one /16 and my traces show them > all taking the same network path... Well that is pretty poor planning... > > http://www.iana.org/domains/root/db/mil.html > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of jamie rishaw > Sent: Tuesday, 20 May 2014 2:40 p.m. > To: NANOG list > Subject: All of .mil tld is down > > At time of post.. > .mil. is down. > Apparently an Anonymous "Operation Payback". > > .mil nameservers are unresponsive. > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From rubensk at gmail.com Tue May 20 12:30:49 2014 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 20 May 2014 09:30:49 -0300 Subject: LACNIC becomes the first RIR to go below /9 of available IP space Message-ID: http://www.lacnic.net/en/web/lacnic/inicio Website is still showing phase 0 of address depletion, but the updated quantity means that the /9 trigger has been reached. Rubens From email at edylie.net Tue May 20 14:21:43 2014 From: email at edylie.net (Pui Edylie) Date: Tue, 20 May 2014 22:21:43 +0800 Subject: NAT IP and Google Message-ID: <537B64F7.5020504@edylie.net> Hi Everyone, May I know what is the best approach so that Google would not ban our Natted IP from time to time as it suspect it as a bot. Is there any official channel from Google which we could work with them for resolution? Thanks much! Best, Edy From ww at styx.org Tue May 20 14:27:21 2014 From: ww at styx.org (William Waites) Date: Tue, 20 May 2014 14:27:21 +0000 Subject: NAT IP and Google In-Reply-To: <537B64F7.5020504@edylie.net> References: <537B64F7.5020504@edylie.net> Message-ID: <20140520142721.GB2594@mavrino.styx.org> On Tue, May 20, 2014 at 10:21:43PM +0800, Pui Edylie wrote: > > May I know what is the best approach so that Google would not ban our > Natted IP from time to time as it suspect it as a bot. IPv6? From chk at pobox.com Tue May 20 14:35:56 2014 From: chk at pobox.com (Harald Koch) Date: Tue, 20 May 2014 10:35:56 -0400 Subject: NAT IP and Google In-Reply-To: <20140520142721.GB2594@mavrino.styx.org> References: <537B64F7.5020504@edylie.net> <20140520142721.GB2594@mavrino.styx.org> Message-ID: On 20 May 2014 10:27, William Waites wrote: > IPv6? > Might help if all your hosts have their own IPv6 addresses - doesn't help if you run an http proxy. Google blacklists my (personal) IPv6 proxy at least once a month. -- Harald From Derek.Andrew at usask.ca Tue May 20 15:10:56 2014 From: Derek.Andrew at usask.ca (Derek Andrew) Date: Tue, 20 May 2014 09:10:56 -0600 Subject: NAT IP and Google In-Reply-To: <4b0d18be0306409083ba2b44936c875d@CAMPUSCAS4.usask.ca> References: <4b0d18be0306409083ba2b44936c875d@CAMPUSCAS4.usask.ca> Message-ID: They take out our campus, both IPv4 and IPv6. All hailing attempts fail. Good luck. On Tue, May 20, 2014 at 8:21 AM, Pui Edylie wrote: > Hi Everyone, > > May I know what is the best approach so that Google would not ban our > Natted IP from time to time as it suspect it as a bot. > > Is there any official channel from Google which we could work with them > for resolution? > > Thanks much! > > Best, > Edy > > -- 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 chris at aperturefiber.com Tue May 20 16:55:38 2014 From: chris at aperturefiber.com (Chris Garrett) Date: Tue, 20 May 2014 11:55:38 -0500 Subject: NAT IP and Google In-Reply-To: References: <4b0d18be0306409083ba2b44936c875d@CAMPUSCAS4.usask.ca> Message-ID: Their determination is based on the type of search traffic more than the volume. I had some success using squid to proxy through to them and reduce the overall number of complex queries. On May 20, 2014, at 10:10 AM, Derek Andrew wrote: > They take out our campus, both IPv4 and IPv6. > > All hailing attempts fail. > > Good luck. > > > > > On Tue, May 20, 2014 at 8:21 AM, Pui Edylie wrote: > >> Hi Everyone, >> >> May I know what is the best approach so that Google would not ban our >> Natted IP from time to time as it suspect it as a bot. >> >> Is there any official channel from Google which we could work with them >> for resolution? >> >> Thanks much! >> >> Best, >> Edy >> >> > > > -- > 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 kkadow at gmail.com Tue May 20 17:27:44 2014 From: kkadow at gmail.com (Kevin Kadow) Date: Tue, 20 May 2014 13:27:44 -0400 Subject: NAT IP and Google In-Reply-To: References: <4b0d18be0306409083ba2b44936c875d@CAMPUSCAS4.usask.ca> Message-ID: If at all possible, consider using a NAT pool instead of translating all outbound web traffic to a single IP address. When I ran Tribune's network (with about 15K internal client IPs), we were blacklisted by Google several times due to high query volumes. In the end I built a pair of /24 NAT pools, so for example all internal 10.x.y.124 addresses are translated to "kevin.nat.trb.com". In my experience, Google does temporary blacklisting based both on rate and also for certain types of queries; you can reduce your chance of a ban by using a smart proxy to rate-limit or deny certain types of query, or to choose the source address based on the URL requested, basically have a "low risk" and a "high risk" source address. From marine64 at gmail.com Tue May 20 18:35:49 2014 From: marine64 at gmail.com (Brian Henson) Date: Tue, 20 May 2014 14:35:49 -0400 Subject: All of .mil tld is down In-Reply-To: References: <006401cf73d7$d00c1790$702446b0$@wicks.co.nz> Message-ID: Looks like it has been corrected now On Tue, May 20, 2014 at 12:30 AM, Anurag Bhatia wrote: > Hi Clark > > > It's down when looked upon from our DNS recursors in India as well. > > > I have seen in past with many domains (not TLDs though) that when they are > down due to non-reachability of authoritative servers for the zone, OpenDNS > and Google DNS still give answers. Likely they have some in-built > resistivity to these issues by serving the stale data when auth is > unreachable. > > > On Tue, May 20, 2014 at 9:44 AM, Clark Shishido > wrote: > > > OpenDNS still has A records for nipr.mil authoritative nameservers. > > > > > > % dig -t ns nipr.mil @resolver1.opendns.com > > > > ; <<>> DiG 9.9.3-P2 <<>> -t ns nipr.mil @resolver1.opendns.com > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37645 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 > > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags:; udp: 4096 > > ;; QUESTION SECTION: > > ;nipr.mil. IN NS > > > > ;; ANSWER SECTION: > > nipr.mil. 20126 IN NS EUR2.nipr.mil. > > nipr.mil. 20126 IN NS EUR1.nipr.mil. > > nipr.mil. 20126 IN NS PAC2.nipr.mil. > > nipr.mil. 20126 IN NS CON1.nipr.mil. > > nipr.mil. 20126 IN NS PAC1.nipr.mil. > > nipr.mil. 20126 IN NS CON2.nipr.mil. > > > > ;; Query time: 58 msec > > ;; SERVER: 208.67.222.222#53(208.67.222.222) > > ;; WHEN: Tue May 20 04:09:11 UTC 2014 > > ;; MSG SIZE rcvd: 151 > > > > % dig eur2.nipr.mil @resolver1.opendns.com > > > > ; <<>> DiG 9.9.3-P2 <<>> eur2.nipr.mil @resolver1.opendns.com > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44901 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags:; udp: 4096 > > ;; QUESTION SECTION: > > ;eur2.nipr.mil. IN A > > > > ;; ANSWER SECTION: > > eur2.nipr.mil. 20103 IN A 199.252.143.234 > > > > ;; Query time: 56 msec > > ;; SERVER: 208.67.222.222#53(208.67.222.222) > > ;; WHEN: Tue May 20 04:09:34 UTC 2014 > > ;; MSG SIZE rcvd: 58 > > > > > > > > On 20 May 2014 03:01, Tony Wicks wrote: > > All those Domain servers seem to be in the one /16 and my traces show > them > > all taking the same network path... Well that is pretty poor planning... > > > > http://www.iana.org/domains/root/db/mil.html > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of jamie rishaw > > Sent: Tuesday, 20 May 2014 2:40 p.m. > > To: NANOG list > > Subject: All of .mil tld is down > > > > At time of post.. > > .mil. is down. > > Apparently an Anonymous "Operation Payback". > > > > .mil nameservers are unresponsive. > > > > > > -- > > > Anurag Bhatia > anuragbhatia.com > > Linkedin | > Twitter > Skype: anuragbhatia.com > > PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 > From bortzmeyer at nic.fr Tue May 20 18:47:03 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 20 May 2014 20:47:03 +0200 Subject: All of .mil tld is down In-Reply-To: References: <006401cf73d7$d00c1790$702446b0$@wicks.co.nz> Message-ID: <20140520184703.GA356@nic.fr> On Tue, May 20, 2014 at 02:35:49PM -0400, Brian Henson wrote a message of 107 lines which said: > Looks like it has been corrected now Not from everywhere. From two different networks in France, I get: % check-soa -i nipr.mil CON1.nipr.mil. 199.252.157.234: ERROR: Timeout CON2.nipr.mil. 199.252.162.234: ERROR: Timeout EUR1.nipr.mil. 199.252.154.234: ERROR: Timeout EUR2.nipr.mil. 199.252.143.234: OK: 2014051904 (256 ms) PAC1.nipr.mil. 199.252.180.234: ERROR: Timeout PAC2.nipr.mil. 199.252.155.234: ERROR: Timeout % check-soa -i mil CON1.NIPR.mil. 199.252.157.234: ERROR: Timeout CON2.NIPR.mil. 199.252.162.234: ERROR: Timeout EUR1.NIPR.mil. 199.252.154.234: ERROR: Timeout EUR2.NIPR.mil. 199.252.143.234: OK: 2014051904 (265 ms) PAC1.NIPR.mil. 199.252.180.234: ERROR: Timeout PAC2.NIPR.mil. 199.252.155.234: ERROR: Timeout From ww at styx.org Tue May 20 18:45:44 2014 From: ww at styx.org (William Waites) Date: Tue, 20 May 2014 18:45:44 +0000 Subject: NAT IP and Google In-Reply-To: References: <537B64F7.5020504@edylie.net> <20140520142721.GB2594@mavrino.styx.org> Message-ID: <20140520184544.GB2348@mavrino.styx.org> On Tue, May 20, 2014 at 10:35:56AM -0400, Harald Koch wrote: > > Might help if all your hosts have their own IPv6 addresses That was meant to be implied... But... On Tue, May 20, 2014 at 09:10:56AM -0600, Derek Andrew wrote: > They take out our campus, both IPv4 and IPv6. That's interesting, I haven't seen this happen with IPv6. Some of the networks I work with do the "everything behind NAT" thing and get bitten by this. Using a pool of addresses helps but... This is only going to get more painful with more people doing "Carrier Grade" NAT... -w From tony at wicks.co.nz Tue May 20 20:58:32 2014 From: tony at wicks.co.nz (Tony Wicks) Date: Wed, 21 May 2014 08:58:32 +1200 Subject: NAT IP and Google In-Reply-To: <20140520184544.GB2348@mavrino.styx.org> References: <537B64F7.5020504@edylie.net> <20140520142721.GB2594@mavrino.styx.org> <20140520184544.GB2348@mavrino.styx.org> Message-ID: <003401cf746e$42bef870$c83ce950$@wicks.co.nz> >Some of the networks I work with do the "everything behind NAT" thing and get bitten by this. Using a pool of addresses helps but... This is only going to get more painful with more people doing >"Carrier Grade" >NAT... I Run CGN with tens of thousands of broadband users being translated behind /24 pools and experience no issues with Google whatsoever. (APNIC ran out of IP's some time ago) Occasionally there are issues with things like banks and universities firewall rules who get confused when hundreds of users are accessing them from one or two IP addresses, but this is not often. The biggest issue is the DDOS attacks have a much bigger effect if the upstream's block our destination IP before we can take the target out of the NAT pool. But that is an education thing primarily. Blocking ddestination IP's for DDOS mitigation is going to have to be phased out, its really just laziness and it rewards the attacker. From brandon at burn.net Tue May 20 21:21:08 2014 From: brandon at burn.net (Brandon Applegate) Date: Tue, 20 May 2014 17:21:08 -0400 Subject: rz.verisign-grs.com root zone ftp access Message-ID: <904CE971-B779-4C9E-AF8D-8DAFCCE01E67@burn.net> Is anyone using this and having failed login for a few days now ? I’ve been mirroring the root zone(s) for years and I just started getting failures in my logs. I emailed an address I found on the Verisign website but so far dead air. If anyone knows of a more pointed email POC that would actually have clue about this that would be awesome. -- 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." -------------- 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 nick at foobar.org Tue May 20 21:30:23 2014 From: nick at foobar.org (Nick Hilliard) Date: Tue, 20 May 2014 22:30:23 +0100 Subject: rz.verisign-grs.com root zone ftp access In-Reply-To: <904CE971-B779-4C9E-AF8D-8DAFCCE01E67@burn.net> References: <904CE971-B779-4C9E-AF8D-8DAFCCE01E67@burn.net> Message-ID: <537BC96F.4090109@foobar.org> On 20/05/2014 22:21, Brandon Applegate wrote: > Is anyone using this and having failed login for a few days now ? I’ve > been mirroring the root zone(s) for years and I just started getting > failures in my logs. ftp://rs.internic.net/domain/root.zone Nick From 2600hz at gmail.com Tue May 20 21:32:51 2014 From: 2600hz at gmail.com (jamie) Date: Tue, 20 May 2014 16:32:51 -0500 Subject: rz.verisign-grs.com root zone ftp access In-Reply-To: <904CE971-B779-4C9E-AF8D-8DAFCCE01E67@burn.net> References: <904CE971-B779-4C9E-AF8D-8DAFCCE01E67@burn.net> Message-ID: I have access; my last success was today at 12:27am est Wait; Do you have a userid or are you trying to log in anonymous? I'm pretty sure this is a closed system.. On Tue, May 20, 2014 at 4:21 PM, Brandon Applegate wrote: > Is anyone using this and having failed login for a few days now ? I’ve > been mirroring the root zone(s) for years and I just started getting > failures in my logs. I emailed an address I found on the Verisign website > but so far dead air. If anyone knows of a more pointed email POC that > would actually have clue about this that would be awesome. > > -- > 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 brandon at burn.net Tue May 20 21:42:18 2014 From: brandon at burn.net (Brandon Applegate) Date: Tue, 20 May 2014 17:42:18 -0400 Subject: rz.verisign-grs.com root zone ftp access In-Reply-To: References: <904CE971-B779-4C9E-AF8D-8DAFCCE01E67@burn.net> Message-ID: <7653698A-66D2-4EA3-AE34-B7387AE51FC8@burn.net> On May 20, 2014, at 5:32 PM, jamie <2600hz at gmail.com> wrote: > I have access; my last success was today at 12:27am est > > Wait; Do you have a userid or are you trying to log in anonymous? I'm pretty sure this is a closed system.. > I have a username/pass. Got it by signing the agreement years ago. I just started getting errors in the past few days: --2014-05-20 17:39:28-- ftp://user:*password*@rz.verisign-grs.com/ => `/tmp/verisign-root-zones/rz.verisign-grs.com/.listing' Resolving rz.verisign-grs.com (rz.verisign-grs.com)... 69.58.178.63 Connecting to rz.verisign-grs.com (rz.verisign-grs.com)|69.58.178.63|:21... connected. Logging in as user ... Login incorrect. -------------- 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 johnl at iecc.com Tue May 20 22:35:06 2014 From: johnl at iecc.com (John Levine) Date: 20 May 2014 22:35:06 -0000 Subject: rz.verisign-grs.com root zone ftp access In-Reply-To: <904CE971-B779-4C9E-AF8D-8DAFCCE01E67@burn.net> Message-ID: <20140520223506.12385.qmail@joyce.lan> In article <904CE971-B779-4C9E-AF8D-8DAFCCE01E67 at burn.net> you write: >-=-=-=-=-=- > >Is anyone using this and having failed login for a few days now ? I�ve been mirroring the root >zone(s) for years and I just started getting failures in my logs. I emailed an address I found on >the Verisign website but so far dead air. If anyone knows of a more pointed email POC that would >actually have clue about this that would be awesome. I have a password I've been using to FTP .com and .net from rz.verisign-grs.com, which still works fine as of five minutes ago. I can use it to get root.zone.gz as well but it's pretty much the same as the one at http://www.internic.net/zones give or take what time of day they dumped it. From marka at isc.org Tue May 20 23:18:24 2014 From: marka at isc.org (Mark Andrews) Date: Wed, 21 May 2014 09:18:24 +1000 Subject: NAT IP and Google In-Reply-To: Your message of "Tue, 20 May 2014 22:21:43 +0800." <537B64F7.5020504@edylie.net> References: <537B64F7.5020504@edylie.net> Message-ID: <20140520231824.B70C81623674@rock.dv.isc.org> Deploy IPv6. This is the solution to this problem. Google supports IPv6 on all their services AFAIK. Mark In message <537B64F7.5020504 at edylie.net>, Pui Edylie writes: > Hi Everyone, > > May I know what is the best approach so that Google would not ban our > Natted IP from time to time as it suspect it as a bot. > > Is there any official channel from Google which we could work with them > for resolution? > > Thanks much! > > Best, > Edy > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From j at arpa.com Wed May 21 02:49:50 2014 From: j at arpa.com (jamie rishaw) Date: Tue, 20 May 2014 21:49:50 -0500 Subject: rz.verisign-grs.com root zone ftp access In-Reply-To: <7653698A-66D2-4EA3-AE34-B7387AE51FC8@burn.net> References: <904CE971-B779-4C9E-AF8D-8DAFCCE01E67@burn.net> <7653698A-66D2-4EA3-AE34-B7387AE51FC8@burn.net> Message-ID: Some output deleted to save spamminess: }~/ ftp rz.verisign-grs.net Connected to rz.verisign-grs.net. 220-**** Welcome to the VeriSign Global Registry Services gTLD Zone FTP Server **** Name (rz.verisign-grs.net:jamie): [myusername] 331 Please specify the password. Password: 230 Login successful. ftp> ls 229 Entering Extended Passive Mode (|||31270|). 150 Here comes the directory listing. [ lots truncated ] -rw-r--r-- 1 ftp ftp 5167 May 20 16:21 arpa.zone.gz -rw-r--r-- 1 ftp ftp 2309652729 May 20 15:31 com.zone.gz -rw-r--r-- 1 ftp ftp 3107 Mar 28 14:46 named.root -rw-r--r-- 1 ftp ftp 317965345 May 20 15:23 net.zone.gz -rw-r--r-- 1 ftp ftp 550 Mar 27 15:49 root-servers.net.zone.gz -rw-r--r-- 1 ftp ftp 546199 May 20 15:42 root.zone -rw-r--r-- 1 ftp ftp 211133 May 20 15:42 root.zone.gz I will email the OP a couple of contacts in the AM after I verify it's alright to give out their info. -jamie From groups at digital-z.com Wed May 21 03:35:51 2014 From: groups at digital-z.com (Blaine Fleming) Date: Tue, 20 May 2014 22:35:51 -0500 Subject: rz.verisign-grs.com root zone ftp access In-Reply-To: <904CE971-B779-4C9E-AF8D-8DAFCCE01E67@burn.net> References: <904CE971-B779-4C9E-AF8D-8DAFCCE01E67@burn.net> Message-ID: <537C1F17.6070307@digital-z.com> On 5/20/14, 4:21 PM, Brandon Applegate wrote: > Is anyone using this and having failed login for a few days now ? I’ve been mirroring the root zone(s) for years and I just started getting failures in my logs. I emailed an address I found on the Verisign website but so far dead air. If anyone knows of a more pointed email POC that would actually have clue about this that would be awesome. I have been experiencing this problem as well but have not had a chance to look into it. It stopped working some time between May 15th and May 16th. If you find out anything, please let me know! --Blaine Fleming From johnl at iecc.com Wed May 21 04:53:46 2014 From: johnl at iecc.com (John Levine) Date: 21 May 2014 04:53:46 -0000 Subject: rz.verisign-grs.com root zone ftp access In-Reply-To: <537C1F17.6070307@digital-z.com> Message-ID: <20140521045346.13997.qmail@joyce.lan> In article <537C1F17.6070307 at digital-z.com> you write: >On 5/20/14, 4:21 PM, Brandon Applegate wrote: >> Is anyone using this and having failed login for a few days now ? I�ve been mirroring the root >zone(s) for years and I just started getting failures in my logs. I emailed an address I found on >the Verisign website but so far dead air. If anyone knows of a more pointed email POC that would >actually have clue about this that would be awesome. > >I have been experiencing this problem as well but have not had a chance >to look into it. It stopped working some time between May 15th and May >16th. If you find out anything, please let me know! When I had problems like this a while ago, I found their support people to be quite responsive. Try writing them at tldzone at verisign-grs.com or call the support number on the web site 703-925-6999. If you're not using your password to download the .COM or .NET zones, it is my impression that they will eventually turn off your password because they think you're not using it. R's, John From dougb at dougbarton.us Wed May 21 05:32:54 2014 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 20 May 2014 22:32:54 -0700 Subject: rz.verisign-grs.com root zone ftp access In-Reply-To: <904CE971-B779-4C9E-AF8D-8DAFCCE01E67@burn.net> References: <904CE971-B779-4C9E-AF8D-8DAFCCE01E67@burn.net> Message-ID: <537C3A86.50205@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/20/2014 02:21 PM, Brandon Applegate wrote: | Is anyone using this and having failed login for a few days now ? I?ve been mirroring the root zone(s) for years and I just started getting failures in my logs. I emailed an address I found on the Verisign website but so far dead air. If anyone knows of a more pointed email POC that would actually have clue about this that would be awesome. You can slave the root and more directly from ICANN: http://www.dns.icann.org/services/axfr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJTfDqGAAoJEFzGhvEaGryEavoH/A8ItF9Ddx2Lg+y7dZf8dLuN zyKMQIGpHZpbC9o1etS/ckK97LKGPFAaW83SfAAmtrXvqFxpziP70Gnnp68QPIS+ hZgBKGhRehy+eUZ/EDqrpDl0VaHns09PP5PVZHco3391aLM5LSVBzDHdygb4c3My NHukMb6dbMhBM4pyFymGXnL2ukFEUw8rGgKby3vWO96WIo0xPgGN/Z8Ev//OCipA dxGgLfHzS26F/qRi6lFg1oMgQZdfzcxG/lz9FI9gmGpC+6btIDUGozk4MgE9GcJW aZKbXq10xHnVl7b6Kncc6YL1kYbbZzXjXyryM3VwbRttS2Fr/PiC8OjJkBapcu4= =8u5u -----END PGP SIGNATURE----- From mehmet at akcin.net Wed May 21 05:42:20 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 20 May 2014 22:42:20 -0700 Subject: rz.verisign-grs.com root zone ftp access In-Reply-To: <537C3A86.50205@dougbarton.us> References: <904CE971-B779-4C9E-AF8D-8DAFCCE01E67@burn.net> <537C3A86.50205@dougbarton.us> Message-ID: F-root also allows you to axfr root-zone ( dig @f.root-servers.net . axfr ) On May 20, 2014, at 10:32 PM, Doug Barton wrote: > Signed PGP part > On 05/20/2014 02:21 PM, Brandon Applegate wrote: > | Is anyone using this and having failed login for a few days now ? > I?ve been mirroring the root zone(s) for years and I just started > getting failures in my logs. I emailed an address I found on the > Verisign website but so far dead air. If anyone knows of a more pointed > email POC that would actually have clue about this that would be awesome. > > You can slave the root and more directly from ICANN: > > http://www.dns.icann.org/services/axfr/ > > From dougb at dougbarton.us Wed May 21 05:50:40 2014 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 20 May 2014 22:50:40 -0700 Subject: rz.verisign-grs.com root zone ftp access In-Reply-To: References: <904CE971-B779-4C9E-AF8D-8DAFCCE01E67@burn.net> <537C3A86.50205@dougbarton.us> Message-ID: <537C3EB0.8000600@dougbarton.us> The last time I asked them, F-root had a "we allow it because it's the right thing to do but we don't like it" policy. Given that ICANN operates an infrastructure purposely built for doing zone transfers, and given that they offer more zones than are on the roots, that's the way I recommend people go. YMMV. Doug On 05/20/2014 10:42 PM, Mehmet Akcin wrote: > F-root also allows you to axfr root-zone ( dig @f.root-servers.net . axfr ) > > > On May 20, 2014, at 10:32 PM, Doug Barton wrote: > >> Signed PGP part >> On 05/20/2014 02:21 PM, Brandon Applegate wrote: >> | Is anyone using this and having failed login for a few days now ? >> I?ve been mirroring the root zone(s) for years and I just started >> getting failures in my logs. I emailed an address I found on the >> Verisign website but so far dead air. If anyone knows of a more pointed >> email POC that would actually have clue about this that would be awesome. >> >> You can slave the root and more directly from ICANN: >> >> http://www.dns.icann.org/services/axfr/ >> >> > From mehmet at akcin.net Wed May 21 05:51:47 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 20 May 2014 22:51:47 -0700 Subject: rz.verisign-grs.com root zone ftp access In-Reply-To: <537C3EB0.8000600@dougbarton.us> References: <904CE971-B779-4C9E-AF8D-8DAFCCE01E67@burn.net> <537C3A86.50205@dougbarton.us> <537C3EB0.8000600@dougbarton.us> Message-ID: Yeah, I was just suggesting alternatives just incase. I have setup ICANN's axfr servers :) mehmet On May 20, 2014, at 10:50 PM, Doug Barton wrote: > The last time I asked them, F-root had a "we allow it because it's the right thing to do but we don't like it" policy. Given that ICANN operates an infrastructure purposely built for doing zone transfers, and given that they offer more zones than are on the roots, that's the way I recommend people go. YMMV. > > Doug > > > On 05/20/2014 10:42 PM, Mehmet Akcin wrote: >> F-root also allows you to axfr root-zone ( dig @f.root-servers.net . axfr ) >> >> >> On May 20, 2014, at 10:32 PM, Doug Barton wrote: >> >>> Signed PGP part >>> On 05/20/2014 02:21 PM, Brandon Applegate wrote: >>> | Is anyone using this and having failed login for a few days now ? >>> I?ve been mirroring the root zone(s) for years and I just started >>> getting failures in my logs. I emailed an address I found on the >>> Verisign website but so far dead air. If anyone knows of a more pointed >>> email POC that would actually have clue about this that would be awesome. >>> >>> You can slave the root and more directly from ICANN: >>> >>> http://www.dns.icann.org/services/axfr/ >>> >>> >> > From leo.vegoda at icann.org Tue May 20 14:30:20 2014 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 20 May 2014 07:30:20 -0700 Subject: IANA IPv4 Recovered Address Space registry updated Message-ID: <5648A8908CCB564EBF46E2BC904A75B1A3BF67D529@EXVPMBX100-1.exc.icann.org> Hi, ICANN has updated the IANA IPv4 Recovered Address Space registry after LACNIC notified it that it has less than a total of a /9 in its inventory of IPv4 address space. This triggered the activation the Recovered IPv4 pool, which was created in the Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA. The address space selection is made using software that tries to allocate blocks based on the RIR managing the DNS for that /8. The software, along with a worked example, is published at: https://github.com/icann/ The list of allocations can be found at: https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovered -address-space.xhtml#ipv4-recovered-address-space-2 Kind regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5495 bytes Desc: not available URL: From druciaki at gmail.com Tue May 20 16:31:37 2014 From: druciaki at gmail.com (Thiago Druciaki Casagrande) Date: Tue, 20 May 2014 13:31:37 -0300 Subject: CFP: IFIP Latin America Networking Conference (LANC 2014) In-cooperation with ACM Message-ID: * IFIP LANC 2014* *The 8th Latin America Networking Conference 2014 (LANC 2014)* * In-cooperation with ACM* http://lanc2014.ufpa.br/ 18-19 September, 2014 Montevideo – Uruguay Collocated with CLEI 2014 The IFIP Latin America Networking Conference 2014 is in-cooperation with ACM and will provide an international technical forum for experts from industry and academia everywhere in the world, but especially from the Latin American countries, to exchange ideas and present results of ongoing research in networking. LANC 2014 is organized jointly with CLEI (Centro Latinoamericano de Estudio em Informatica) 2014 - http://clei.org/clei2014/ . Topics include, but are not limited to: NETWORKS and COMMUNICATION SYSTEMS - Cloud computing - Delay/Disruption-tolerant networks - Green and Energy-efficient communications - Internet based applications - Low cost access networks - Multimedia networking systems - National ICT infrastructures for education - Network and service management - Network performance evaluation - Network security - Optical communications - Peer-to-peer and overlay networks - Protocols - Quality of Service (QoS) and Quality of Experience (QoE) in communication systems - Routing and switching - Smart grid communications - Social Multimedia Networking - Software Defined Networks - Web infrastructure - Wireless, mobile, ad-hoc, and sensor networks - Cyber-physical systems and the Internet of things - Dynamic spectrum management - Implementation and experimental testbeds - Cognitive radio networking - Cross layer design and optimization Submission of papers that cover solutions of specific network problems of this region of the world is especially encouraged. *IMPORTANT DATES* - Full and Short Paper Submission deadline: June 10 - Notification of acceptance: August 01 - Camera-ready copy: August 20 *PAPER SUBMISSION* The submission is now open: Only original papers (written in English) not published or under review elsewhere can be submitted - full papers (up to 8 pages including references) and short papers (4 pages up to 1 additional page). Templates can be downloaded from the ACM website ( http://www.acm.org/sigs/publications/proceedings-templates / The LaTeX2e - Tighter Alternate style is preferable to the Strict one). Papers should be uploaded electronically, ONLY in PDF format, to the Easychair website: https://www.easychair.org/conferences/?conf=lanc2014 *REVIEW PROCESS* All submitted papers will have at least three reviews. Acceptance will be based on originality, quality, relevance and the practical value of the work. *PROCEEDINGS* All accepted papers will be published in the* ACM* Digital Library. There will be a special issue of the CLEI electronic journal ( http://www.clei.cl/cleiej) devoted to extended versions of a selection of the papers presented at LANC 2014. *Travel Support* IFIP TC6 Student Travel Grant Programme Under the IFIP TC6 Student Travel Grant Programme, students or young researchers from an IFIP member country may apply for partial funding to assist them towards paying their travel and accommodation costs when attending the 8th Latin America Networking Conference 2014. Young researchers are researchers who have not yet completed their studies up to, and including a doctoral degree. Such persons would normally not be older than 35 years on the 15th September 2014. An Awards Committee reviews the application and awards a grant where the applicant would not otherwise have the resources to attend a conference or workshop, with benefits to both the student and the symposium. Grants are for the applicants travel and lodging expenses only and will not exceed 500 U$ per grant. The maximum of the grant is fixed and any claims in excess of 500 U$ will not be considered. *VENUE* For more information about travel, hotels, etc. please visit CLEI 2014 web site (http://clei.org/clei2014/) *General Co-Chair* Eduardo Cerqueira, Federal University of Para, BR *Steering Committee* Ana Pont, U. Politécnica Valencia, ES David R. Oran, CISCO, US Ernst L. Leiss, U. of Houston, US Hector Cancela, U. de la República, UY Ramón Cáceres, AT&T Labs, US Rodrigo Santos, U. Nacional del Sur, AR *Technical Program Committee Co-Chairs* Aldri Santos, Federal University of Paraná, BR Eduardo Grampin, UDELAR, UY *Organizing Committee* Hector Cancela, UDELAR, UY *Technical Program Committee (TBD)* Aldri Santos, UFPR, BR Ariel Sabiguero, UDELAR, UY Artur Ziviani, LNCC, BR Augusto Neto, UFC, BR David Oran, CISCO, US Edjair Mota, UFAM, BR Edmundo Monteiro University of Coimbra, PT Eduardo Cerqueira, UFPA, BR Eduardo Grampin, UDELAR, UY Enrique Carrera, ESPE, EC Francisco Quiles, UCLM, ES Francisco Valera, UC3M, ES Harry Perros, NCSU, US Javier Baliosian, UDELAR, UY José Piquer, UCH, CL José Salinas, UPV, ES Jussara M. Almeida, UFMG, BR Lisandro Zambenedetti Granville, UFRGS, BR Marcelo Bagnulo Braun, UC3M, ES Maria Dolores Baños, UPCT, ES Maria Elena Villapol, UCV, VE Marília Curado, University of Coimbra, PT Marinho P. Barcellos, UFRGS, BR Michele Nogueira, UFPR, BR Mikolaj Leszczuk, AGH, PL Pablo Belzarena, UDELAR, UY Pablo Rodríguez-bocca, UDELAR, UY Ronaldo A. Ferreira UFMS, BR Sherali Zeadally, University of Kentucky, US Siraj A. Shaikh, Coventry University, UK Xavi Masip, UPC, ES Yutaka Takahashi, Kyoto University, JP From ajfrcc at rit.edu Tue May 20 03:32:55 2014 From: ajfrcc at rit.edu (Anthony Fontanez) Date: Tue, 20 May 2014 03:32:55 +0000 Subject: All of .mil tld is down In-Reply-To: References: Message-ID: <49E51FC2E6E2EA44B60CD5C7969C6CD730443EB8@ex03mail04.ad.rit.edu> Got this from a friend: http://pastebin.com/UkwHbY1V Greeting Internet. This is Operation PayBack We Are Anonymous Centre PayBack is a bitch All US MILITARY SERVERS ARE OFFLINE Operation PayBack - http://armypubs.army.mil Operation PayBack - http://army.mil Operation PayBack - www.public.navy.mil Operation PayBack - http://navy.mil Operation PayBack - http://usmc.mil Operation PayBack - http://US.Army.mil Operation PayBack - http://NKO.navy.mil Operation PayBack - http://www.uscg.mil Operation PayBack - http://www.af.mil Operation PayBack - http://www.marines.mil Operation PayBack - http://www.militaryonesource.mil Operation PayBack - http://www.dtic.mil Operation PayBack - http://www.dfas.mil Operation PayBack - http://www.dla.mil Operation PayBack - http://www.move.mil Operation PayBack - http://www.jcs.mil Operation PayBack - http://www.stratcom.mil Operation PayBack - http://www.dc3.mil Operation PayBack - US ARMY Operation PayBack - US NAVY Operation PayBack - US MARINES Operation PayBack - US AIR FORCE All US MILITARY SERVERS ARE OFFLINE @Anon_Centre #AnonCentre -----Original Message----- From: NANOG [mailto:nanog-bounces+ajfrcc=rit.edu at nanog.org] On Behalf Of Cryptographrix Sent: Monday, May 19, 2014 22:57 To: jamie rishaw Cc: NANOG list Subject: Re: All of .mil tld is down Well that's the most ludicrous thing I've heard all month. *grabs popcorn* On Mon, May 19, 2014 at 10:40 PM, jamie rishaw wrote: > At time of post.. > .mil. is down. > Apparently an Anonymous "Operation Payback". > > .mil nameservers are unresponsive. > From kburke at burlingtontelecom.com Tue May 20 19:05:10 2014 From: kburke at burlingtontelecom.com (Kevin Burke) Date: Tue, 20 May 2014 15:05:10 -0400 Subject: FTTH ONTs and routers In-Reply-To: <005e01cf71e3$2ec2b1a0$8c4814e0$@iname.com> References: <5374F538.5010108@vaxination.ca> <53763976.8020805@tccmail.ca> <005e01cf71e3$2ec2b1a0$8c4814e0$@iname.com> Message-ID: <707FECBBE7FEE241ABE4CAAF4025A0BE02997315@corpmail.burlingtontelecom.com> I have used a lot of Calix gear. It works good until they decide to EoL your platform. They grow through acquisition, then see which products they want to keep. Adtran seems to have the same features and the same pricepoint. The Calix E7 is a relatively new product...plenty of bugs compared to the much more mature TA5000. Oh and if you don't show these the other guys prices they will dine out on your tab. Funny how much lower people can go when they realize you are bidding something out. Kevin -----Original Message----- From: NANOG [mailto:nanog-bounces+kburke=burlingtontelecom.com at nanog.org] On Behalf Of Frank Bulk Sent: Saturday, May 17, 2014 11:18 AM To: 'Pete at TCC'; Jean-Francois Mezei; nanog at nanog.org Subject: RE: FTTH ONTs and routers FYI, Calix has GPON support for the 836GE ONT on the E7 today, and it will be supported in GPON mode in Release 9.0 on the C7. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Pete at TCC Sent: Friday, May 16, 2014 11:15 AM To: Jean-Francois Mezei; nanog at nanog.org Subject: Re: FTTH ONTs and routers There are many ONTs out there with various abilities. I can only comment on what I deploy, and what various telcos deploy that I am familiar with. A few years ago, all of our AE and GPON ONTs were deployed as bridges. Port 1 was generally an Internet VLAN, and port 2,3,4 were IPTV VLANs. We have been using Occam (now Calix), but are considering other options at this point. Currently we bridge all services on GPON deployments, but rent routers for the Internet service if customers do not wish to provide their own. The 700-series ONTs are able to bounce between GPON and AE deployments with a firmware change, so they are very flexible. Calix has apparently released RG code (Residential Gateway, basic home router functionality) for for the 700s, but we don't use that code. We also deploy 836 ONTs, which had RG code built-in on release, and also WiFi. The 836s currently only do AE, but were originally supposed to do GPON/AE similar to the 700-series. Today, the standard AE deployment is an 836 with RG code enabled for WiFi and Port 1. WAN is DHCP, authorized with Option 82/RADIUS for bandwidth profiles. LAN does NAT, and hands out a 192.168.88.0/24 subnet to break as few consumer routers as possible. We have no problem enabling bridging for Port 1 if the customer requests it. We bridge Port 2,3,4 for IPTV because the RG functionality breaks certain features, namely call display on the TVs. The 836s can do Static, PPPoE, or DHCP on the WAN side. We use MGCP for voice. -- Pete Baldwin On 14-05-15 01:11 PM, Jean-Francois Mezei wrote: > It had been my impression that ONTs, like most other consumer modems, > came with built-in router capabilities (along with ATA for voice). > > The assertion that ONTs have built-in routing capabilities has been > challenged. > > Can anyone confirm whether ONTs generally have routing (aka: home > router that does the PPPoE or DHCP and then NAT for home) capabilities? > > Are there examples where a telco has deployed ONTs with the router > built-in and enabled ? Or would almost all FTTH deployments be made > with any routing disabled and the ONT acting as a pure ethernet bridge ? > > > (I appreciate your help on this as I am time constrained to do research). > From di at egihosting.com Tue May 20 22:39:53 2014 From: di at egihosting.com (Di Li) Date: Tue, 20 May 2014 15:39:53 -0700 Subject: ASN lookup tool In-Reply-To: References: Message-ID: Get more than 700 unique user check out our new tool, and also get some feedbacks about API access and IRR record. For the API part, we may add it in the future if we have enough people want to access or use it, pretty much will be a restful with json format output, so far we don't plan to do anything with whois format output. For the IRR record, we just added IRR for the ASN, we are using RADB/LEVEL3/ARIN/RIPE/NTT/ALTDB right now, and we may add IRR for the IP blocks in the future, right now no plan to do that yet. Thanks, Di On Mon, May 19, 2014 at 10:14 AM, Di Li wrote: > Hey Guys, > > We just launch out our new ASN/IP/IPv6 lookup tool, let us know if there's > any feedback, we know there's still some small bugs in the middle, we are > still work on the bugs and new features, this is just a beta version, I > hope you guys can find it useful. > > www.asnmap.com > > -- > Thanks, > Di > -- Thanks, Di From fergdawgster at mykolab.com Wed May 21 14:00:09 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 21 May 2014 07:00:09 -0700 Subject: Dyn Acquires Internet Intelligence Service Renesys In-Reply-To: <537CA7CA.2050105@internetidentity.com> References: <537CA7CA.2050105@internetidentity.com> Message-ID: <537CB169.9010105@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Interesting development. http://techcrunch.com/2014/05/21/dyn-acquires-internet-intelligence-service-renesys/ FYI, - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlN8sWkACgkQKJasdVTchbJv3AD/brr/c4iEzhoNDIS4c7CCR8wY 6fkPd7DZbV8eEEeW4AsA/3ZZnapiMpvrDL00JF0BpTsNGn8nNEatmTNr2t+OZQwm =jA0r -----END PGP SIGNATURE----- From owen at delong.com Wed May 21 18:20:21 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 21 May 2014 11:20:21 -0700 Subject: NAT IP and Google In-Reply-To: <537B64F7.5020504@edylie.net> References: <537B64F7.5020504@edylie.net> Message-ID: <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> On May 20, 2014, at 7:21 AM, Pui Edylie wrote: > Hi Everyone, > > May I know what is the best approach so that Google would not ban our Natted IP from time to time as it suspect it as a bot. > > Is there any official channel from Google which we could work with them for resolution? > > Thanks much! > > Best, > Edy The absolute best solution is to deploy IPv6 and deprecate NAT. If you’re looking for an IPv4-only solution, I don’t have a good answer for you. Owen From owen at delong.com Wed May 21 18:26:50 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 21 May 2014 11:26:50 -0700 Subject: NAT IP and Google In-Reply-To: References: <4b0d18be0306409083ba2b44936c875d@CAMPUSCAS4.usask.ca> Message-ID: <5FAB50AF-9061-4CFB-A07F-FE75BE95093A@delong.com> This works out especially well if you are using VOIP behind said NAT. ;-) Owen On May 20, 2014, at 10:27 AM, Kevin Kadow wrote: > If at all possible, consider using a NAT pool instead of translating > all outbound web traffic to a single IP address. When I ran > Tribune's network (with about 15K internal client IPs), we were > blacklisted by Google several times due to high query volumes. In the > end I built a pair of /24 NAT pools, so for example all internal > 10.x.y.124 addresses are translated to "kevin.nat.trb.com". > > In my experience, Google does temporary blacklisting based both on > rate and also for certain types of queries; you can reduce your chance > of a ban by using a smart proxy to rate-limit or deny certain types of > query, or to choose the source address based on the URL requested, > basically have a "low risk" and a "high risk" source address. From LarrySheldon at cox.net Wed May 21 18:42:59 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 21 May 2014 13:42:59 -0500 Subject: IANA IPv4 Recovered Address Space registry updated In-Reply-To: <4caD1o0061cZc5601caGtr> References: <4caD1o0061cZc5601caGtr> Message-ID: <537CF3B3.6020302@cox.net> On 5/20/2014 9:30 AM, Leo Vegoda wrote: > https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovered > -address-space.xhtml#ipv4-recovered-address-space-2 Comes up 404 here. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From LarrySheldon at cox.net Wed May 21 18:59:43 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 21 May 2014 13:59:43 -0500 Subject: Correction to 404 report (was Re: IANA IPv4 Recovered Address Space registry updated) In-Reply-To: <4iqg1o01D0z497J01iqhC3> References: <4caD1o0061cZc5601caGtr> <537CF3B3.6020302@cox.net> <4iqg1o01D0z497J01iqhC3> Message-ID: <537CF79F.9000007@cox.net> On 5/21/2014 1:50 PM, Darryl Dunkin wrote: > Did you just click the link? It got wrapped. Yes as a matter if fact I did--and noticed the truncation and cut and pasted it--and it still failed. > http://bit.ly/1k5ROJW That works. As does a newly submitted cut-and-paste. Mystery. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From mianosm at gmail.com Wed May 21 19:08:04 2014 From: mianosm at gmail.com (Steven Miano) Date: Wed, 21 May 2014 15:08:04 -0400 Subject: IANA IPv4 Recovered Address Space registry updated In-Reply-To: <537CF3B3.6020302@cox.net> References: <537CF3B3.6020302@cox.net> Message-ID: If you're just clicking the link it won't work in some e-mail clients. Copy the entirety and it will display for you I'm sure. On Wed, May 21, 2014 at 2:42 PM, Larry Sheldon wrote: > On 5/20/2014 9:30 AM, Leo Vegoda wrote: > >> https://www.iana.org/assignments/ipv4-recovered- >> address-space/ipv4-recovered >> -address-space.xhtml#ipv4-recovered-address-space-2 >> > > Comes up 404 here. > > > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > From tony at wicks.co.nz Wed May 21 21:21:12 2014 From: tony at wicks.co.nz (Tony Wicks) Date: Thu, 22 May 2014 09:21:12 +1200 Subject: NAT IP and Google In-Reply-To: <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> Message-ID: <005701cf753a$97d6e670$c784b350$@wicks.co.nz> > >On May 20, 2014, at 7:21 AM, Pui Edylie wrote: > >The absolute best solution is to deploy IPv6 and deprecate NAT. If you're looking for an IPv4-only solution, I don't have a good answer for you. Deploy v6... yes its very easy to replace every CPE device that every home user has... really ? come on, back in the real world that is just not going to happen until by default every CPE device has the capability as default. Dual stack with CGNAT is the only real solution that works today. From LarrySheldon at cox.net Wed May 21 21:43:48 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 21 May 2014 16:43:48 -0500 Subject: NAT IP and Google In-Reply-To: <4lNd1o01v1cZc5601lNfhy> References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <4lNd1o01v1cZc5601lNfhy> Message-ID: <537D1E14.2030906@cox.net> On 5/21/2014 4:21 PM, Tony Wicks wrote: > Deploy v6... yes its very easy ....... The system is fully automated, and if you carefully follow instructions, life will be wonderful and nothing can possibly go wronand nothing can possibly go wronand nothing can possibly go wronand nothing can possibly go wronand nothing can possibly go wron..... Sorry. Having a bad day dealing with heinous telephone robots and unspeakably bad web pages. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From Valdis.Kletnieks at vt.edu Wed May 21 23:01:42 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 21 May 2014 19:01:42 -0400 Subject: NAT IP and Google In-Reply-To: Your message of "Thu, 22 May 2014 09:21:12 +1200." <005701cf753a$97d6e670$c784b350$@wicks.co.nz> References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> Message-ID: <110703.1400713302@turing-police.cc.vt.edu> On Thu, 22 May 2014 09:21:12 +1200, "Tony Wicks" said: > Deploy v6... yes its very easy to replace every CPE device that every home > user has... really ? come on, back in the real world that is just not going > to happen until by default every CPE device has the capability as default. > Dual stack with CGNAT is the only real solution that works today. And if 5 years ago you had *started* distributing CPE that did v6, and by now you had 40% of your customer with CPE that did it, you'd need a 40% smaller CGN to fix your Google problem.. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From cb.list6 at gmail.com Wed May 21 23:17:05 2014 From: cb.list6 at gmail.com (Ca By) Date: Wed, 21 May 2014 16:17:05 -0700 Subject: NAT IP and Google In-Reply-To: <110703.1400713302@turing-police.cc.vt.edu> References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> Message-ID: On May 21, 2014 4:04 PM, wrote: > > On Thu, 22 May 2014 09:21:12 +1200, "Tony Wicks" said: > > > Deploy v6... yes its very easy to replace every CPE device that every home > > user has... really ? come on, back in the real world that is just not going > > to happen until by default every CPE device has the capability as default. > > Dual stack with CGNAT is the only real solution that works today. > > And if 5 years ago you had *started* distributing CPE that did v6, and by now > you had 40% of your customer with CPE that did it, you'd need a 40% smaller CGN > to fix your Google problem.. > > > > Verizon Wireless is at 50% ipv6 penetration, T-Mobile US and Comcast are closing in on 30% It's a non-trivial number of eyeballs. And, FB, Google / Youtube , and Netflix are all native ipv6 ...its a lot of cotent too. CB From cb.list6 at gmail.com Wed May 21 23:17:57 2014 From: cb.list6 at gmail.com (Ca By) Date: Wed, 21 May 2014 16:17:57 -0700 Subject: NAT IP and Google In-Reply-To: References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> Message-ID: On May 21, 2014 4:17 PM, "Ca By" wrote: > > > On May 21, 2014 4:04 PM, wrote: > > > > On Thu, 22 May 2014 09:21:12 +1200, "Tony Wicks" said: > > > > > Deploy v6... yes its very easy to replace every CPE device that every home > > > user has... really ? come on, back in the real world that is just not going > > > to happen until by default every CPE device has the capability as default. > > > Dual stack with CGNAT is the only real solution that works today. > > > > And if 5 years ago you had *started* distributing CPE that did v6, and by now > > you had 40% of your customer with CPE that did it, you'd need a 40% smaller CGN > > to fix your Google problem.. > > > > > > > > > > Verizon Wireless is at 50% ipv6 penetration, T-Mobile US and Comcast are closing in on 30% > > It's a non-trivial number of eyeballs. And, FB, Google / Youtube , and Netflix are all native ipv6 ...its a lot of cotent too. > > CB Citation http://www.worldipv6launch.org/verizon-wireless-breaks-through-50-ipv6-and-still-climbing/ From marka at isc.org Wed May 21 23:45:24 2014 From: marka at isc.org (Mark Andrews) Date: Thu, 22 May 2014 09:45:24 +1000 Subject: NAT IP and Google In-Reply-To: Your message of "Thu, 22 May 2014 09:21:12 +1200." <005701cf753a$97d6e670$c784b350$@wicks.co.nz> References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> Message-ID: <20140521234524.7A72F163D3DF@rock.dv.isc.org> In message <005701cf753a$97d6e670$c784b350$@wicks.co.nz>, "Tony Wicks" writes: > > > >On May 20, 2014, at 7:21 AM, Pui Edylie wrote: > > > >The absolute best solution is to deploy IPv6 and deprecate NAT. If you're > >looking for an IPv4-only solution, I don't have a good answer for you. > > Deploy v6... yes its very easy to replace every CPE device that every home > user has... really ? come on, back in the real world that is just not going > to happen until by default every CPE device has the capability as default. > Dual stack with CGNAT is the only real solution that works today. It you have ONE IP, which was what was described by the OP, then upgrade is the solution. Even when you have customer CPE devices deploying IPv6 is still the solution. If you supply the CPE device stop purchasing IPv4 only devices. Only ship IPv6 capable devices. If the customers supply the CPE device tell them you are turning on IPv6 and that they need to purchase a IPv6 capable CPE device to use it with this minimum set of IPv6 features. Give them a list of CPE devices that you have tested. A little communication goes a long way. Every IPv6 CPE deployed reduces the probability that the NAT will be used for a connection. I wish I could get the CPE feature list need for IPv6 from my home ISP. It would save me money buying devices that I will just have to throw out before they die when they finally get around to deploying IPv6. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jared at puck.nether.net Thu May 22 01:38:03 2014 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 21 May 2014 21:38:03 -0400 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> Message-ID: On May 21, 2014, at 7:17 PM, Ca By wrote: > Verizon Wireless is at 50% ipv6 penetration I suspect this would go up significantly if Twitter and Instagram would IPv6 enable their services. Same for pintarest. Other folks like bit.ly have briefly toyed with IPv6, and with the helpdesk.test-ipv6.com site, I think things will continue to get better. IPv6 via LTE and handset are the way most of the worlds population will access the internet, not via a computer the way I have been getting "online" for the past few decades. - jared From damian at google.com Thu May 22 04:42:17 2014 From: damian at google.com (Damian Menscher) Date: Wed, 21 May 2014 21:42:17 -0700 Subject: NAT IP and Google In-Reply-To: <537B64F7.5020504@edylie.net> References: <537B64F7.5020504@edylie.net> Message-ID: On Tue, May 20, 2014 at 7:21 AM, Pui Edylie wrote: > > May I know what is the best approach so that Google would not ban our > Natted IP from time to time as it suspect it as a bot. > As others have said, Google's abuse systems are smart enough to understand NAT and proxies, and won't block on request volume alone. When we automatically apply a block, we'll generally offer a captcha to give innocent users a workaround and limit the annoyance until the abuse stops and the block can expire. While we do everything we can to limit the collateral damage, if your organization has an infected user spewing abuse, you need to take responsibility for your network. IPv6 is the best long-term solution, as this will allow Google's abuse systems to distinguish between your users and block only those violating the ToS. Please give each user a distinct /64 (this seems obvious, but I've seen someone put all their users in the same /96). If you can't deploy IPv6 yet, some other suggestions: - Put your users behind a proxy that adds the X-Forwarded-For header with the user's internal IP. Google's abuse systems use that header to limit blocking when possible. - Review your machines for signs of infection -- many blocks are triggered by botnets that are sending abuse. Another common cause is a browser extension that automatically sends requests. Finally, don't set up monitoring to test whether you're being blocked -- those automated monitoring requests are also a violation of the ToS and only increase the chance of being blocked. - If you have a proxy, test it to ensure it's not an "open" proxy. Open proxies are frequently abused, and will get blocked as a result. - Partitioning users across different IPs can help contain the collateral damage when one user's machine goes rogue. If you load-balance all users across all your IPs then it will likely just result in the entire pool being blocked. Is there any official channel from Google which we could work with them for > resolution? > There's no official channel for working to resolve a blocking issue. Years of experience proves the abuse systems are very accurate (and constantly being improved) -- false positives are extremely rare. Despite this certainty, due to privacy concerns no evidence can be shared back to the ISP to point to the source of abuse. Since nothing can be shared except for times abuse was seen (which is rarely helpful due to lack of logging by the ISP), the response is generally just the suggestions listed above. The blocks will expire on their own once the abuse has been stopped. Damian -- Damian Menscher :: Security Reliability Engineer :: Google From Jason_Livingood at cable.comcast.com Thu May 22 12:04:18 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 22 May 2014 12:04:18 +0000 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> Message-ID: On 5/21/14, 9:38 PM, "Jared Mauch" wrote: >On May 21, 2014, at 7:17 PM, Ca By wrote: > >> Verizon Wireless is at 50% ipv6 penetration > >I suspect this would go up significantly if Twitter and Instagram would >IPv6 enable their services. Same for pintarest. +1 We naturally focus a lot on network enablement here, but IMO it is a great time to focus on more web-based services embracing IPv6 with another June 6 just around the corner. :-) JL From jared at puck.nether.net Thu May 22 12:41:45 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 22 May 2014 08:41:45 -0400 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> Message-ID: <509325F4-F695-473C-B6FA-309EF7F23116@puck.nether.net> On May 22, 2014, at 8:04 AM, Livingood, Jason wrote: > On 5/21/14, 9:38 PM, "Jared Mauch" wrote: > >> On May 21, 2014, at 7:17 PM, Ca By wrote: >> >>> Verizon Wireless is at 50% ipv6 penetration >> >> I suspect this would go up significantly if Twitter and Instagram would >> IPv6 enable their services. Same for pintarest. > > +1 > We naturally focus a lot on network enablement here, but IMO it is a great > time to focus on more web-based services embracing IPv6 with another June > 6 just around the corner. :-) I'm waiting to see Akamai and Cachefly follow the lead of Cloudflare and make everything IPv6 by default. I remind vendors when I talk to them, "IPv6 first, then IP classic(tm)". From morrowc.lists at gmail.com Thu May 22 12:55:14 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 22 May 2014 08:55:14 -0400 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: <509325F4-F695-473C-B6FA-309EF7F23116@puck.nether.net> References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> <509325F4-F695-473C-B6FA-309EF7F23116@puck.nether.net> Message-ID: On Thu, May 22, 2014 at 8:41 AM, Jared Mauch wrote: > I remind vendors when I talk to them, "IPv6 first, then IP classic(tm)". Coke Classic managed to outlast NewCoke... pattern repeating? From Joshua_Sholes at cable.comcast.com Thu May 22 13:19:20 2014 From: Joshua_Sholes at cable.comcast.com (Sholes, Joshua) Date: Thu, 22 May 2014 13:19:20 +0000 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> <509325F4-F695-473C-B6FA-309EF7F23116@puck.nether.net> Message-ID: Don't even joke about that, I can't handle another decade of NAT. -- Josh On 5/22/14, 8:55 AM, "Christopher Morrow" wrote: >On Thu, May 22, 2014 at 8:41 AM, Jared Mauch >wrote: >> I remind vendors when I talk to them, "IPv6 first, then IP >>classic(tm)". > >Coke Classic managed to outlast NewCoke... pattern repeating? From bmanning at karoshi.com Thu May 22 13:44:26 2014 From: bmanning at karoshi.com (manning) Date: Thu, 22 May 2014 06:44:26 -0700 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> <509325F4-F695-473C-B6FA-309EF7F23116@puck.nether.net> Message-ID: <89671811-53FF-4C87-AB6B-A47B1F6AA2EE@karoshi.com> On 22May2014Thursday, at 5:55, Christopher Morrow wrote: > On Thu, May 22, 2014 at 8:41 AM, Jared Mauch wrote: >> I remind vendors when I talk to them, "IPv6 first, then IP classic(tm)". > > Coke Classic managed to outlast NewCoke... pattern repeating? its classic for a reason…. /bill From dealing.with.ddos at gmail.com Thu May 22 04:51:37 2014 From: dealing.with.ddos at gmail.com (Beleaguered Admin) Date: Wed, 21 May 2014 21:51:37 -0700 Subject: Large DDoS, small extortion Message-ID: Apologies for the non-personal email address, but I don't want to give our attacker any additional information than I need to. I'd be happy to send personal contact/ASN information to any nanog admins or regular members of nanog if it's useful. Over the past year or so, we (a decent sized tier 2 with a nationwide US backbone) have had several large DDoS attacks from what appear to be the same person who is (we presume) going down something like the alexa list of top sites, attacking them, and asking for small amounts of money to stop. This has been going on for a long time -- almost every detail is exactly the same as what is described here: http://it.slashdot.org/story/12/11/03/1846252/ask-slashdot-how-to-deal-with-a-ddos-attack and more recently: http://techcrunch.com/2014/03/03/meetup-suffering-significant-ddos-attack-taking-it-offline-for-days/ and: https://gist.github.com/dhh/9741477 And I believe attacks including vimeo, github, and others. The attacker is smarter than many random attackers, or at least has better tools. He watches when you mitigate the attack, and shifts his attack to something new. He (or his tools) also watch DNS for the thing he's attacking and the attack moves as DNS changes. We've seen UDP amplification (NTP and DNS mainly), syn flood, syn/ack flood, layer 7 cache busting (https://isc.sans.edu/forums/diary/Wordpress+Pingback+DDoS+Attacks/17801/), and others we haven't been able to fully mitigate/identify. The largest we've seen (which isn't the largest we've read about) attacks are over 50Gbit and 10s of millions of pps. He is in regular communication (via whois info and other collected contact data) asking for <$1000 USD sums to stop the attacks. While we are interested in technical means to mitigate the attacks (the syn and syn/acks are brutal, all cores pegged on multicore 10G nic servers just dealing with interrupts), what I'd really like to find out is how to help fix the problem. We've tried to engage upstream providers to help trace the attacks, but have gotten nowhere (they didn't seem to understand that the syn attacks were spoofed, and looking at source IPs didn't matter, we wanted to know the ingress points on their network.) What are the best practices for this? Are there secret code words (http://xkcd.com/806/) we can use to get to someone at our upstreams who might know what we're talking about? Is it worth the time? Is it worth talking to law enforcement? Some of these have been >500k costs to the customer, but we assume the person doing it isn't in any western country, so maybe it doesn't even matter? Thanks. From jared at puck.nether.net Thu May 22 14:03:56 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 22 May 2014 10:03:56 -0400 Subject: Large DDoS, small extortion In-Reply-To: References: Message-ID: On May 22, 2014, at 12:51 AM, Beleaguered Admin wrote: > Apologies for the non-personal email address, but I don't want to give > our attacker any additional information than I need to. > > I'd be happy to send personal contact/ASN information to any nanog > admins or regular members of nanog if it's useful. > > We've tried to engage upstream providers to help trace the attacks, > but have gotten nowhere (they didn't seem to understand that the syn > attacks were spoofed, and looking at source IPs didn't matter, we > wanted to know the ingress points on their network.) this sounds like a tooling issue on their part. they should be able to pick a specific set of items and trace them back and mitigate some set of spoofed packets. Some attackers are advanced and will detect when you block their spoofed packets immediately (they have telemetry/data like we all do) and move to another attack vector. > What are the best practices for this? Are there secret code words > (http://xkcd.com/806/) we can use to get to someone at our upstreams > who might know what we're talking about? Is it worth the time? You need to talk to the security team in their NOC. These are usually small and sometimes difficult to reach. I know our NOC can find them quickly and works with them on customer issues often. > Is it worth talking to law enforcement? Absolutely. Even if the "lost costs" have been just payroll which already exist, this may be related to other activity. I suggest calling your local FBI office (assuming you are in the US). They can be quite helpful. If you don't get somewhere quickly, let me know and I can try to hunt someone in a local field office for you. > Some of these have been >500k > costs to the customer, but we assume the person doing it isn't in any > western country, so maybe it doesn't even matter? I'll say it does matter, because even if they are in some "unreachable" location, these folks sometimes travel to locations where they can be picked up. It may not be immediate, but can help build the case. It is sad, but I can likely guess who your upstreams are, and some are more responsive than others. I'm aware of one that puts almost no effort into tracking spoofed packets to clamp down on them. - Jared From michael at supermathie.net Thu May 22 14:06:10 2014 From: michael at supermathie.net (Michael Brown) Date: Thu, 22 May 2014 10:06:10 -0400 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> <509325F4-F695-473C-B6FA-309EF7F23116@puck.nether.net> Message-ID: <537E0452.403@supermathie.net> On 14-05-22 08:55 AM, Christopher Morrow wrote: > Coke Classic managed to outlast NewCoke... pattern repeating? Coke Classic changed as well. NAT44: the high-fructose corn syrup of IPv4. M. -- Michael Brown | The true sysadmin does not adjust his behaviour Systems Administrator | to fit the machine. He adjusts the machine michael at supermathie.net | until it behaves properly. With a hammer, | if necessary. - Brian From rdobbins at arbor.net Thu May 22 14:57:39 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 22 May 2014 21:57:39 +0700 Subject: Large DDoS, small extortion In-Reply-To: References: Message-ID: On May 22, 2014, at 11:51 AM, Beleaguered Admin wrote: > While we are interested in technical means to mitigate the attacks (the syn and syn/acks are brutal, all cores pegged on multicore 10G nic servers just dealing with interrupts), Here's how to get started: Ensure you have flow telemetry enabled at all your edges; there are open-source tools like nfsen/nfdump that you can get started with quickly. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From Jason_Livingood at cable.comcast.com Thu May 22 15:23:40 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 22 May 2014 15:23:40 +0000 Subject: Large DDoS, small extortion In-Reply-To: References: Message-ID: On 5/22/14, 12:51 AM, "Beleaguered Admin" wrote: >This has been going on for a long time -- almost every detail is >exactly the same as what is described here: >http://techcrunch.com/2014/03/03/meetup-suffering-significant-ddos-attack- >taking-it-offline-for-days/ > >He is in regular communication (via whois info and other collected >contact data) asking for <$1000 USD sums to stop the attacks. That article said that the company didn¹t want to negotiate with criminals. As an aside I spent some time with a retired hostage negotiator on Tuesday (which was fascinating BTW). He actually said negotiation is always useful and sometimes paying a ransom demand can serve as a method to track where the money goes, to identify all the actors involved for later action (which may apply in this case). And sometimes financial demands are dropped as a result of negotiation. >Is it worth talking to law enforcement? Some of these have been >500k >costs to the customer, but we assume the person doing it isn't in any >western country, so maybe it doesn't even matter? You may find the law enforcement more interested in engaging within you than you might think. Jason From Derek.Andrew at usask.ca Thu May 22 15:26:31 2014 From: Derek.Andrew at usask.ca (Derek Andrew) Date: Thu, 22 May 2014 09:26:31 -0600 Subject: NAT IP and Google In-Reply-To: References: <537B64F7.5020504@edylie.net> Message-ID: As others have said, Google's abuse systems are smart enough to understand NAT and proxies, and won't block on request volume alone. When we automatically apply a block, we'll generally offer a captcha to give innocent users a workaround and limit the annoyance until the abuse stops and the block can expire This failed at our site. Our entire IPv4 and IPv6 addresse blocks received captcha after captcha after captcha, forever and ever. There was a link on the page to get more information, but all that got was another captcha. Normally I am 100% behind Google in everything, but sadly, this has now fallen to 99.8%. derek On Wed, May 21, 2014 at 10:42 PM, Damian Menscher wrote: > On Tue, May 20, 2014 at 7:21 AM, Pui Edylie wrote: > > > > May I know what is the best approach so that Google would not ban our > > Natted IP from time to time as it suspect it as a bot. > > > > As others have said, Google's abuse systems are smart enough to understand > NAT and proxies, and won't block on request volume alone. When we > automatically apply a block, we'll generally offer a captcha to give > innocent users a workaround and limit the annoyance until the abuse stops > and the block can expire. While we do everything we can to limit the > collateral damage, if your organization has an infected user spewing abuse, > you need to take responsibility for your network. > > IPv6 is the best long-term solution, as this will allow Google's abuse > systems to distinguish between your users and block only those violating > the ToS. Please give each user a distinct /64 (this seems obvious, but > I've seen someone put all their users in the same /96). > > If you can't deploy IPv6 yet, some other suggestions: > - Put your users behind a proxy that adds the X-Forwarded-For header with > the user's internal IP. Google's abuse systems use that header to limit > blocking when possible. > - Review your machines for signs of infection -- many blocks are > triggered by botnets that are sending abuse. Another common cause is a > browser extension that automatically sends requests. Finally, don't set up > monitoring to test whether you're being blocked -- those automated > monitoring requests are also a violation of the ToS and only increase the > chance of being blocked. > - If you have a proxy, test it to ensure it's not an "open" proxy. Open > proxies are frequently abused, and will get blocked as a result. > - Partitioning users across different IPs can help contain the collateral > damage when one user's machine goes rogue. If you load-balance all users > across all your IPs then it will likely just result in the entire pool > being blocked. > > Is there any official channel from Google which we could work with them for > > resolution? > > > > There's no official channel for working to resolve a blocking issue. Years > of experience proves the abuse systems are very accurate (and constantly > being improved) -- false positives are extremely rare. Despite this > certainty, due to privacy concerns no evidence can be shared back to the > ISP to point to the source of abuse. Since nothing can be shared except > for times abuse was seen (which is rarely helpful due to lack of logging by > the ISP), the response is generally just the suggestions listed above. The > blocks will expire on their own once the abuse has been stopped. > > Damian > -- > Damian Menscher :: Security Reliability Engineer :: Google > -- 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 Lee at asgard.org Thu May 22 15:49:14 2014 From: Lee at asgard.org (Lee Howard) Date: Thu, 22 May 2014 11:49:14 -0400 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> Message-ID: On 5/22/14 8:04 AM, "Livingood, Jason" wrote: >On 5/21/14, 9:38 PM, "Jared Mauch" wrote: > >>On May 21, 2014, at 7:17 PM, Ca By wrote: >> >>> Verizon Wireless is at 50% ipv6 penetration >> >>I suspect this would go up significantly if Twitter and Instagram would >>IPv6 enable their services. Same for pintarest. > >+1 >We naturally focus a lot on network enablement here, but IMO it is a great >time to focus on more web-based services embracing IPv6 with another June >6 just around the corner. :-) A side project I've been meaning to take on: In his really useful listing of content providers' IPv6 support, https://www.vyncke.org/ipv6status/ Eric Vyncke has added "CDN" to sites using an identifiable CDN. I've been meaning to write a script to pull those sites and CDNs, to identify "bang for the buck" in CDN enablement. I know Akamai is enormous, but if CloudFlare, Limelight, and a couple of hosting companies were to dual-stack all of their customers, would it matter that Akamai and Amazon weren't doing so yet? Or another way to look at it would be, who would be the key players for a major content enablement day? Lee From rdobbins at arbor.net Thu May 22 15:50:16 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 22 May 2014 22:50:16 +0700 Subject: Large DDoS, small extortion In-Reply-To: References: Message-ID: <66236A3D-8223-4C77-99B5-ECA28332EF8F@arbor.net> On May 22, 2014, at 10:23 PM, Livingood, Jason wrote: > He actually said negotiation is always useful and sometimes paying a ransom demand can serve as a method to track where the money goes, to identify all the actors involved for later action (which may apply in this case). Bad advice for online stuff, as a) it's very, very rare that the perpetrators are caught, and b) word will get around that you're an easy mark - so, more attacks, more (and more expensive) extortion. *Never* pay extortion money to a DDoSer. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From wbailey at satelliteintelligencegroup.com Thu May 22 15:59:42 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 22 May 2014 15:59:42 +0000 Subject: Large DDoS, small extortion In-Reply-To: <66236A3D-8223-4C77-99B5-ECA28332EF8F@arbor.net> References: <66236A3D-8223-4C77-99B5-ECA28332EF8F@arbor.net> Message-ID: Never pay extortion anyways. After you pay once, you¹ll pay again. If I were you, I¹d pay someone a few bucks to pull this kids dox and drop them on pastebin. Stainless Steel Testicles turn to itty bitty testicles when your name and phone number are sitting on the internet. Or just write back to him and tell him that if you don¹t stop being packeted, you¹re going to take his mother to a nice seafood dinner and NEVER call her again. What¹s he going to do, packet you? ;) On 5/22/14, 8:50 AM, "Roland Dobbins" wrote: > >On May 22, 2014, at 10:23 PM, Livingood, Jason > wrote: > >> He actually said negotiation is always useful and sometimes paying a >>ransom demand can serve as a method to track where the money goes, to >>identify all the actors involved for later action (which may apply in >>this case). > >Bad advice for online stuff, as a) it's very, very rare that the >perpetrators are caught, and b) word will get around that you're an easy >mark - so, more attacks, more (and more expensive) extortion. > >*Never* pay extortion money to a DDoSer. > >---------------------------------------------------------------------- >Roland Dobbins // > > Equo ne credite, Teucri. > > -- Laocoön > From royce at techsolvency.com Thu May 22 16:03:03 2014 From: royce at techsolvency.com (Royce Williams) Date: Thu, 22 May 2014 08:03:03 -0800 Subject: NAT IP and Google In-Reply-To: References: <537B64F7.5020504@edylie.net> Message-ID: On Thu, May 22, 2014 at 7:26 AM, Derek Andrew wrote: > As others have said, Google's abuse systems are smart enough to understand > NAT and proxies, and won't block on request volume alone. When we > automatically apply a block, we'll generally offer a captcha to give > innocent users a workaround and limit the annoyance until the abuse stops > and the block can expire > > This failed at our site. Our entire IPv4 and IPv6 addresse blocks received > captcha after captcha after captcha, forever and ever. > > There was a link on the page to get more information, but all that got was > another captcha. > > Normally I am 100% behind Google in everything, but sadly, this has now > fallen to 99.8%. I've triggered Google's CAPTCHA multiple times at home, just from rapidly adding and removing search terms, in a couple of different tabs, after driving down a hundred results or so. It's been a few months, but this used to happen to me pretty regularly if I had drive deep to find something. Royce From cma at cmadams.net Thu May 22 16:13:20 2014 From: cma at cmadams.net (Chris Adams) Date: Thu, 22 May 2014 11:13:20 -0500 Subject: NAT IP and Google In-Reply-To: References: <537B64F7.5020504@edylie.net> Message-ID: <20140522161320.GC15187@cmadams.net> Once upon a time, Royce Williams said: > I've triggered Google's CAPTCHA multiple times at home, just from > rapidly adding and removing search terms, in a couple of different > tabs, after driving down a hundred results or so. I tend to look up docs and such from a screen session on my VPS using Lynx (text-mode browser). My VPS provider (Linode) assigns a single IPv6 address out of a /64 to a VPS, and apparently Google periodically blocks the /64 I'm in. Lynx can't handle a CAPTCHA (of course), so I don't get Google anymore for a while when that happens. I tried logging in and allowing the cookie to see if that helped, but it doesn't appear it does. -- Chris Adams From lists at mrqueue.com Thu May 22 16:25:58 2014 From: lists at mrqueue.com (Mr. Queue) Date: Thu, 22 May 2014 11:25:58 -0500 Subject: Large DDoS, small extortion In-Reply-To: References: <66236A3D-8223-4C77-99B5-ECA28332EF8F@arbor.net> Message-ID: <537E2516.3040101@mrqueue.com> On 5/22/2014 10:59 AM, Warren Bailey wrote: > Never pay extortion anyways. After you pay once, you¹ll pay again. > > If I were you, I¹d pay someone a few bucks to pull this kids dox and drop > them on pastebin. Stainless Steel Testicles turn to itty bitty testicles > when your name and phone number are sitting on the internet. Or just write > back to him and tell him that if you don¹t stop being packeted, you¹re > going to take his mother to a nice seafood dinner and NEVER call her > again. What¹s he going to do, packet you? ;) World could use more opts like this. From bmanning at karoshi.com Thu May 22 17:22:24 2014 From: bmanning at karoshi.com (manning) Date: Thu, 22 May 2014 10:22:24 -0700 Subject: Large DDoS, small extortion In-Reply-To: References: Message-ID: negotiation is fine… a weakness is presuming to know what the perp wants (and many times they don;t know themselves) so engagement is good “The Cuckoo's Egg” is worth the read… /bill On 22May2014Thursday, at 8:23, Livingood, Jason wrote: > On 5/22/14, 12:51 AM, "Beleaguered Admin" > wrote: > >> This has been going on for a long time -- almost every detail is >> exactly the same as what is described here: >> http://techcrunch.com/2014/03/03/meetup-suffering-significant-ddos-attack- >> taking-it-offline-for-days/ >> >> He is in regular communication (via whois info and other collected >> contact data) asking for <$1000 USD sums to stop the attacks. > > That article said that the company didn¹t want to negotiate with > criminals. As an aside I spent some time with a retired hostage negotiator > on Tuesday (which was fascinating BTW). He actually said negotiation is > always useful and sometimes paying a ransom demand can serve as a method > to track where the money goes, to identify all the actors involved for > later action (which may apply in this case). And sometimes financial > demands are dropped as a result of negotiation. > >> Is it worth talking to law enforcement? Some of these have been >500k >> costs to the customer, but we assume the person doing it isn't in any >> western country, so maybe it doesn't even matter? > > You may find the law enforcement more interested in engaging within you > than you might think. > > Jason > From wbailey at satelliteintelligencegroup.com Thu May 22 17:26:48 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 22 May 2014 17:26:48 +0000 Subject: Large DDoS, small extortion In-Reply-To: References: Message-ID: I could attribute a fair number of misdeeds to that book. ;) On 5/22/14, 10:22 AM, "manning" wrote: >negotiation is fine… a weakness is presuming to know what the perp wants > (and many times they don;t know themselves) >so engagement is good “The Cuckoo's Egg” is worth the read… > >/bill > > >On 22May2014Thursday, at 8:23, Livingood, Jason > wrote: > >> On 5/22/14, 12:51 AM, "Beleaguered Admin" >> wrote: >> >>> This has been going on for a long time -- almost every detail is >>> exactly the same as what is described here: >>> >>>http://techcrunch.com/2014/03/03/meetup-suffering-significant-ddos-attac >>>k- >>> taking-it-offline-for-days/ >>> >>> He is in regular communication (via whois info and other collected >>> contact data) asking for <$1000 USD sums to stop the attacks. >> >> That article said that the company didn¹t want to negotiate with >> criminals. As an aside I spent some time with a retired hostage >>negotiator >> on Tuesday (which was fascinating BTW). He actually said negotiation is >> always useful and sometimes paying a ransom demand can serve as a method >> to track where the money goes, to identify all the actors involved for >> later action (which may apply in this case). And sometimes financial >> demands are dropped as a result of negotiation. >> >>> Is it worth talking to law enforcement? Some of these have been >500k >>> costs to the customer, but we assume the person doing it isn't in any >>> western country, so maybe it doesn't even matter? >> >> You may find the law enforcement more interested in engaging within you >> than you might think. >> >> Jason >> > From damian at google.com Thu May 22 17:44:40 2014 From: damian at google.com (Damian Menscher) Date: Thu, 22 May 2014 10:44:40 -0700 Subject: Large DDoS, small extortion In-Reply-To: References: Message-ID: Contact law enforcement -- they can combine intel from multiple cases to hopefully identify the attacker. Automate your analysis and reporting. If you send an email to the sources of abuse you can reduce the attacker's capabilities. (To set expectations: only about 10% will take action.) If you have specific customers that are being targeted, you may want to suggest they get behind a DDoS mitigation provider that can absorb large attacks (up to 500Gbps). Damian On Wed, May 21, 2014 at 9:51 PM, Beleaguered Admin < dealing.with.ddos at gmail.com> wrote: > Apologies for the non-personal email address, but I don't want to give > our attacker any additional information than I need to. > > I'd be happy to send personal contact/ASN information to any nanog > admins or regular members of nanog if it's useful. > > Over the past year or so, we (a decent sized tier 2 with a nationwide > US backbone) have had several large DDoS attacks from what appear to > be the same person who is (we presume) going down something like the > alexa list of top sites, attacking them, > and asking for small amounts of money to stop. > > This has been going on for a long time -- almost every detail is > exactly the same as what is described here: > > > http://it.slashdot.org/story/12/11/03/1846252/ask-slashdot-how-to-deal-with-a-ddos-attack > > and more recently: > > > http://techcrunch.com/2014/03/03/meetup-suffering-significant-ddos-attack-taking-it-offline-for-days/ > > and: > > https://gist.github.com/dhh/9741477 > > And I believe attacks including vimeo, github, and others. > > The attacker is smarter than many random attackers, or at least has > better tools. He watches when you mitigate the attack, and shifts his > attack to something new. He (or his tools) also watch DNS for the > thing he's attacking and the attack moves as DNS changes. > > We've seen UDP amplification (NTP and DNS mainly), syn flood, syn/ack > flood, layer 7 cache busting > (https://isc.sans.edu/forums/diary/Wordpress+Pingback+DDoS+Attacks/17801/ > ), > and others we haven't been able to fully mitigate/identify. > > The largest we've seen (which isn't the largest we've read about) > attacks are over 50Gbit and 10s of millions of pps. > > He is in regular communication (via whois info and other collected > contact data) asking for <$1000 USD sums to stop the attacks. > > While we are interested in technical means to mitigate the attacks > (the syn and syn/acks are brutal, all cores pegged on multicore 10G > nic servers just dealing with interrupts), what I'd really like to > find out is how to help fix the problem. > > We've tried to engage upstream providers to help trace the attacks, > but have gotten nowhere (they didn't seem to understand that the syn > attacks were spoofed, and looking at source IPs didn't matter, we > wanted to know the ingress points on their network.) > > What are the best practices for this? Are there secret code words > (http://xkcd.com/806/) we can use to get to someone at our upstreams > who might know what we're talking about? Is it worth the time? > > Is it worth talking to law enforcement? Some of these have been >500k > costs to the customer, but we assume the person doing it isn't in any > western country, so maybe it doesn't even matter? > > Thanks. > From bzs at world.std.com Thu May 22 20:38:41 2014 From: bzs at world.std.com (Barry Shein) Date: Thu, 22 May 2014 16:38:41 -0400 Subject: Large DDoS, small extortion In-Reply-To: References: Message-ID: <21374.24658.3602.618224@world.std.com> You know what would be nice? Some real life experience and results, case studies. I see the "common sense" and "logic" to a lot of these suggestions but that and $1.75 plus tax will get you a venti coffee of the day at Starbucks. Victim: I'd be very wary of these suggestions unless there's some good, solid reason to believe they're based on reality not just "I've simulated all of human psychology in my head and here's what I think you should do..." I think it's interesting that the guy asks for such small amounts, under US$1000. Maybe that's a lot of money for him. Maybe he thinks it won't be worth investigating such a small amount. Maybe he thinks it's not a very big crime so if he gets caught he's more likely to walk. Maybe he thinks he's poor/broke and this money is deservedly his to demand, it's such a modest demand. Note: He could be factually/legally wrong but that's why I prefaced with "maybe he thinks..." Maybe he's a sadist and gets a kick out of making you squirm and the money is just his way of keeping score, making you do something tangible, kind of like "kiss my boots!" Maybe he's insane which voids all of the above. Maybe it's some sort of penetration exercise by terrorists, a govt, etc. Maybe all I've said and $1.75 plus tax... -- -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 merike at doubleshotsecurity.com Thu May 22 22:17:40 2014 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Thu, 22 May 2014 15:17:40 -0700 Subject: Large DDoS, small extortion In-Reply-To: <21374.24658.3602.618224@world.std.com> References: <21374.24658.3602.618224@world.std.com> Message-ID: I will use this opportunity to solicit real world experience and use cases that could be discussed at the Security Track at NANOG 61. While I've been soliciting talks in operational security specific groups, this thread also peaked my interest. Nothing beats sharing the good, the bad, the ugly and how collectively we can improve on how we mitigate against varying attacks. Please respond to me in unicast and let me know if you'd be willing to share some experiences. The Security Track is not recorded nor streamed and you do not need a formal presentation. - merike On May 22, 2014, at 1:38 PM, Barry Shein wrote: > > You know what would be nice? Some real life experience and results, > case studies. > > I see the "common sense" and "logic" to a lot of these suggestions but > that and $1.75 plus tax will get you a venti coffee of the day at > Starbucks. > > Victim: I'd be very wary of these suggestions unless there's some > good, solid reason to believe they're based on reality not just "I've > simulated all of human psychology in my head and here's what I think > you should do..." > > I think it's interesting that the guy asks for such small amounts, > under US$1000. > > Maybe that's a lot of money for him. > > Maybe he thinks it won't be worth investigating such a small amount. > > Maybe he thinks it's not a very big crime so if he gets caught he's > more likely to walk. > > Maybe he thinks he's poor/broke and this money is deservedly his to > demand, it's such a modest demand. > > Note: He could be factually/legally wrong but that's why I prefaced > with "maybe he thinks..." > > Maybe he's a sadist and gets a kick out of making you squirm and the > money is just his way of keeping score, making you do something > tangible, kind of like "kiss my boots!" > > Maybe he's insane which voids all of the above. > > Maybe it's some sort of penetration exercise by terrorists, a govt, > etc. > > Maybe all I've said and $1.75 plus tax... > > > -- > -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* -------------- 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 mpetach at netflight.com Thu May 22 23:46:21 2014 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 22 May 2014 16:46:21 -0700 Subject: seeking nanog hotel room to crash in Message-ID: looks like i waited too long again to reserve a hotel room for nanog...anyone have a double room with an unused bed they'd be willing to split with a very quiet roommate? ^_^; thanks! Matt From jlewis at lewis.org Fri May 23 00:29:15 2014 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 22 May 2014 20:29:15 -0400 (EDT) Subject: seeking nanog hotel room to crash in In-Reply-To: References: Message-ID: On Thu, 22 May 2014, Matthew Petach wrote: > looks like i waited too long again to > reserve a hotel room for nanog...anyone Did you check the Silver Cloud Inn? It appears to be about a block away. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From hannigan at gmail.com Fri May 23 01:14:06 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 22 May 2014 21:14:06 -0400 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: <509325F4-F695-473C-B6FA-309EF7F23116@puck.nether.net> References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> <509325F4-F695-473C-B6FA-309EF7F23116@puck.nether.net> Message-ID: On Thursday, May 22, 2014, Jared Mauch wrote: > > On May 22, 2014, at 8:04 AM, Livingood, Jason < > Jason_Livingood at cable.comcast.com > wrote: > > > On 5/21/14, 9:38 PM, "Jared Mauch" > > wrote: > > > >> On May 21, 2014, at 7:17 PM, Ca By > > wrote: > >> > >>> Verizon Wireless is at 50% ipv6 penetration > >> > >> I suspect this would go up significantly if Twitter and Instagram would > >> IPv6 enable their services. Same for pintarest. > > > > +1 > > We naturally focus a lot on network enablement here, but IMO it is a > great > > time to focus on more web-based services embracing IPv6 with another June > > 6 just around the corner. :-) > > > I'm waiting to see Akamai and Cachefly follow the lead of Cloudflare and > make everything IPv6 by default. I remind vendors when I talk to them, > "IPv6 first, then IP classic(tm)". Jared, Akamai has been v6 enabled for years. Customers have choices and know best. Isn't your network still offering both as customer choices? :-) Best, -M< From jared at puck.nether.net Fri May 23 01:21:03 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 22 May 2014 21:21:03 -0400 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> <509325F4-F695-473C-B6FA-309EF7F23116@puck.nether.net> Message-ID: On May 22, 2014, at 9:14 PM, Martin Hannigan wrote: > > > On Thursday, May 22, 2014, Jared Mauch wrote: > > On May 22, 2014, at 8:04 AM, Livingood, Jason wrote: > > > On 5/21/14, 9:38 PM, "Jared Mauch" wrote: > > > >> On May 21, 2014, at 7:17 PM, Ca By wrote: > >> > >>> Verizon Wireless is at 50% ipv6 penetration > >> > >> I suspect this would go up significantly if Twitter and Instagram would > >> IPv6 enable their services. Same for pintarest. > > > > +1 > > We naturally focus a lot on network enablement here, but IMO it is a great > > time to focus on more web-based services embracing IPv6 with another June > > 6 just around the corner. :-) > > > I'm waiting to see Akamai and Cachefly follow the lead of Cloudflare and make everything IPv6 by default. I remind vendors when I talk to them, "IPv6 first, then IP classic(tm)". > > > Jared, > > Akamai has been v6 enabled for years. Customers have choices and know best. I respectfully disagree with the 'know best', I've seen many customers who don't know the right choice and it takes a bit of time to learn the right way. > Isn't your network still offering both as customer choices? :-) We still are, and I posted recently on ratio that we see, which is 286:1 https://twitter.com/jaredmauch/status/466150814663581696 With so many people already doing IPv6 on their main sites, I'm hard pressed to believe this won't break people who aren't already broken. You can't cater to everyones broken network. I can't reach 1.1.1.1 from here either, but sometimes when I travel I can, even with TTL=1. At some point folks have to fix what's broken. - Jared From rubensk at gmail.com Fri May 23 01:24:44 2014 From: rubensk at gmail.com (Rubens Kuhl) Date: Thu, 22 May 2014 22:24:44 -0300 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> <509325F4-F695-473C-B6FA-309EF7F23116@puck.nether.net> Message-ID: > > > Jared, > > Akamai has been v6 enabled for years. Customers have choices and know best. > > Isn't your network still offering both as customer choices? :-) > Making new customers dual-stack by default for the last two years would have gone far in increasing IPv6, unless Akamai is only losing customers to other CDNs instead of getting new ones... Rubens From hannigan at gmail.com Fri May 23 01:41:53 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 22 May 2014 21:41:53 -0400 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> <509325F4-F695-473C-B6FA-309EF7F23116@puck.nether.net> Message-ID: On Thursday, May 22, 2014, Rubens Kuhl wrote: > > > > > > Jared, > > > > Akamai has been v6 enabled for years. Customers have choices and know > best. > > > > Isn't your network still offering both as customer choices? :-) > > > > Making new customers dual-stack by default for the last two years would > have gone far in increasing IPv6, unless Akamai is only losing customers to > other CDNs instead of getting new ones... > > > Rubens > My job isn't to increase v6. It's to make sure we can serve traffic over protocols we are asked to. We are dual stacked which means our customers are. I ho Best, -M< From hannigan at gmail.com Fri May 23 01:46:06 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 22 May 2014 21:46:06 -0400 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> <509325F4-F695-473C-B6FA-309EF7F23116@puck.nether.net> Message-ID: On Thursday, May 22, 2014, Martin Hannigan wrote: > > > On Thursday, May 22, 2014, Rubens Kuhl > > wrote: > >> > >> > >> > Jared, >> > >> > Akamai has been v6 enabled for years. Customers have choices and know >> best. >> > >> > Isn't your network still offering both as customer choices? :-) >> > >> >> Making new customers dual-stack by default for the last two years would >> have gone far in increasing IPv6, unless Akamai is only losing customers >> to >> other CDNs instead of getting new ones... >> >> >> Rubens >> > > My job isn't to increase v6. It's to make sure we can serve traffic over > protocols we are asked to. We are dual stacked which means our customers > are. > > > And correcting typo. Apologies, slippery thumbs Best, -M< From mpetach at netflight.com Fri May 23 02:18:54 2014 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 22 May 2014 19:18:54 -0700 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> Message-ID: On Thu, May 22, 2014 at 8:49 AM, Lee Howard wrote: > > > On 5/22/14 8:04 AM, "Livingood, Jason" > wrote: > > >On 5/21/14, 9:38 PM, "Jared Mauch" wrote: > > > >>On May 21, 2014, at 7:17 PM, Ca By wrote: > >> > >>> Verizon Wireless is at 50% ipv6 penetration > >> > >>I suspect this would go up significantly if Twitter and Instagram would > >>IPv6 enable their services. Same for pintarest. > > > >+1 > >We naturally focus a lot on network enablement here, but IMO it is a great > >time to focus on more web-based services embracing IPv6 with another June > >6 just around the corner. :-) > > A side project I've been meaning to take on: > > In his really useful listing of content providers' IPv6 support, > https://www.vyncke.org/ipv6status/ Eric Vyncke has added "CDN" to sites > using an identifiable CDN. > I suspect there's a problem with the data collection on that site; looking at https://www.vyncke.org/ipv6status/detailed.php?country=us I really don't think the top 5 players don't support IPv6 DNS queries at all. I'd be curious to know more about how the data there is collected; I don't see any links to any description of the data collection methodology on the site. Matt From rdobbins at arbor.net Fri May 23 03:20:22 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 23 May 2014 10:20:22 +0700 Subject: Large DDoS, small extortion In-Reply-To: <21374.24658.3602.618224@world.std.com> References: <21374.24658.3602.618224@world.std.com> Message-ID: <0BD7B0BD-7F94-427A-9215-1AFC5828AED5@arbor.net> On May 23, 2014, at 3:38 AM, Barry Shein wrote: > Some real life experience and results, case studies. Some of us have quite a bit of real-life experience and results in these situations. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From ikiris at gmail.com Fri May 23 04:22:39 2014 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 22 May 2014 23:22:39 -0500 Subject: Large DDoS, small extortion In-Reply-To: <0BD7B0BD-7F94-427A-9215-1AFC5828AED5@arbor.net> References: <21374.24658.3602.618224@world.std.com> <0BD7B0BD-7F94-427A-9215-1AFC5828AED5@arbor.net> Message-ID: Most of us wish we didn't. There are so much more productive ways to spend the day than fighting a determined and adaptive attacker. -Blake On Thu, May 22, 2014 at 10:20 PM, Roland Dobbins wrote: > > On May 23, 2014, at 3:38 AM, Barry Shein wrote: > >> Some real life experience and results, case studies. > > Some of us have quite a bit of real-life experience and results in these situations. > > ---------------------------------------------------------------------- > Roland Dobbins // > > Equo ne credite, Teucri. > > -- Laocoön > From rdobbins at arbor.net Fri May 23 04:43:58 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 23 May 2014 11:43:58 +0700 Subject: Large DDoS, small extortion In-Reply-To: References: <21374.24658.3602.618224@world.std.com> <0BD7B0BD-7F94-427A-9215-1AFC5828AED5@arbor.net> Message-ID: <2DF6CD6D-3826-4584-B48E-0DA58D18134B@arbor.net> On May 23, 2014, at 11:22 AM, Blake Dunlap wrote: > Most of us wish we didn't. Concur 100%. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From nanog at studio442.com.au Fri May 23 05:24:08 2014 From: nanog at studio442.com.au (Julien Goodwin) Date: Fri, 23 May 2014 15:24:08 +1000 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> <509325F4-F695-473C-B6FA-309EF7F23116@puck.nether.net> Message-ID: <537EDB78.2000207@studio442.com.au> On 23/05/14 11:21, Jared Mauch wrote: > You can't cater to everyones broken network. I can't reach 1.1.1.1 from here either, but sometimes when I travel I can, even with TTL=1. At some point folks have to fix what's broken. 1.1.1.1 is not private IP space. BGP routing table entry for 1.1.1.0/24 Paths: (2 available, best #1) 15169 AS-path translation: { Google } edge5.Amsterdam1 (metric 20040) Origin IGP, metric 100000, localpref 86, valid, internal, best Community: Europe Lclprf_86 Netherlands Level3_Peer Amsterdam Originator: edge5.Amsterdam1 15169 AS-path translation: { Google } edge5.Amsterdam1 (metric 20040) Origin IGP, metric 100000, localpref 86, valid, internal Community: Europe Lclprf_86 Netherlands Level3_Peer Amsterdam Originator: edge5.Amsterdam1 (Yes ok, it doesn't respond to any packets last I checked) I just wish Cisco wouldn't document it as a great IP address to use for your captive portal From morrowc.lists at gmail.com Fri May 23 05:29:18 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 23 May 2014 01:29:18 -0400 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: <537EDB78.2000207@studio442.com.au> References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> <509325F4-F695-473C-B6FA-309EF7F23116@puck.nether.net> <537EDB78.2000207@studio442.com.au> Message-ID: On Fri, May 23, 2014 at 1:24 AM, Julien Goodwin wrote: > On 23/05/14 11:21, Jared Mauch wrote: >> You can't cater to everyones broken network. I can't reach 1.1.1.1 from here either, but sometimes when I travel I can, even with TTL=1. At some point folks have to fix what's broken. > > 1.1.1.1 is not private IP space. > > BGP routing table entry for 1.1.1.0/24 > Paths: (2 available, best #1) > 15169 > AS-path translation: { Google } > edge5.Amsterdam1 (metric 20040) > Origin IGP, metric 100000, localpref 86, valid, internal, best > Community: Europe Lclprf_86 Netherlands Level3_Peer Amsterdam > Originator: edge5.Amsterdam1 > 15169 > AS-path translation: { Google } > edge5.Amsterdam1 (metric 20040) > Origin IGP, metric 100000, localpref 86, valid, internal > Community: Europe Lclprf_86 Netherlands Level3_Peer Amsterdam > Originator: edge5.Amsterdam1 > > (Yes ok, it doesn't respond to any packets last I checked) some times it does (some portion of the space does/service replies to a sample of packets...) Geoff should have more info on the progress of his experiment though. > > I just wish Cisco wouldn't document it as a great IP address to use for > your captive portal yea.. 'document' ... I think 'hardcode' (or perhaps default-config) is more like it, right? From dealing.with.ddos at gmail.com Fri May 23 06:05:54 2014 From: dealing.with.ddos at gmail.com (Frank Doherty) Date: Thu, 22 May 2014 23:05:54 -0700 Subject: Large DDoS, small extortion In-Reply-To: References: Message-ID: Thanks everyone. There's been a lot of great on and off list responses, and we have a much better list of contacts for the next time this happens. We are in contact with the FBI now (very impressed, particularly compared to what I expected), and have access to resources that we didn't know existed. Hopefully I'll meet some of you in bellevue next week. On Wed, May 21, 2014 at 9:51 PM, Beleaguered Admin wrote: > Apologies for the non-personal email address, but I don't want to give > our attacker any additional information than I need to. > > I'd be happy to send personal contact/ASN information to any nanog > admins or regular members of nanog if it's useful. > > Over the past year or so, we (a decent sized tier 2 with a nationwide > US backbone) have had several large DDoS attacks from what appear to > be the same person who is (we presume) going down something like the > alexa list of top sites, attacking them, > and asking for small amounts of money to stop. > > This has been going on for a long time -- almost every detail is > exactly the same as what is described here: > > http://it.slashdot.org/story/12/11/03/1846252/ask-slashdot-how-to-deal-with-a-ddos-attack > > and more recently: > > http://techcrunch.com/2014/03/03/meetup-suffering-significant-ddos-attack-taking-it-offline-for-days/ > > and: > > https://gist.github.com/dhh/9741477 > > And I believe attacks including vimeo, github, and others. > > The attacker is smarter than many random attackers, or at least has > better tools. He watches when you mitigate the attack, and shifts his > attack to something new. He (or his tools) also watch DNS for the > thing he's attacking and the attack moves as DNS changes. > > We've seen UDP amplification (NTP and DNS mainly), syn flood, syn/ack > flood, layer 7 cache busting > (https://isc.sans.edu/forums/diary/Wordpress+Pingback+DDoS+Attacks/17801/), > and others we haven't been able to fully mitigate/identify. > > The largest we've seen (which isn't the largest we've read about) > attacks are over 50Gbit and 10s of millions of pps. > > He is in regular communication (via whois info and other collected > contact data) asking for <$1000 USD sums to stop the attacks. > > While we are interested in technical means to mitigate the attacks > (the syn and syn/acks are brutal, all cores pegged on multicore 10G > nic servers just dealing with interrupts), what I'd really like to > find out is how to help fix the problem. > > We've tried to engage upstream providers to help trace the attacks, > but have gotten nowhere (they didn't seem to understand that the syn > attacks were spoofed, and looking at source IPs didn't matter, we > wanted to know the ingress points on their network.) > > What are the best practices for this? Are there secret code words > (http://xkcd.com/806/) we can use to get to someone at our upstreams > who might know what we're talking about? Is it worth the time? > > Is it worth talking to law enforcement? Some of these have been >500k > costs to the customer, but we assume the person doing it isn't in any > western country, so maybe it doesn't even matter? > > Thanks. From randy at psg.com Fri May 23 08:24:39 2014 From: randy at psg.com (Randy Bush) Date: Fri, 23 May 2014 17:24:39 +0900 Subject: Large DDoS, small extortion In-Reply-To: References: Message-ID: > Thanks everyone. There's been a lot of great on and off list > responses, and we have a much better list of contacts for the next > time this happens. > > We are in contact with the FBI now (very impressed, particularly > compared to what I expected), and have access to resources that we > didn't know existed. > > Hopefully I'll meet some of you in bellevue next week. seeing as the web version of the security track is content free, it would be cool if you held a little open chat. randy From mpetach at netflight.com Fri May 23 10:01:57 2014 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 23 May 2014 03:01:57 -0700 Subject: seeking nanog hotel room to crash in In-Reply-To: References: Message-ID: I am truly humbled and amazed at the number of replies I received; I'm all set now, thank you to everyone who responded to help me out! I'll be more careful next time around to not leave the trip planning until the last minute like this. ^_^; Thanks again, everyone--this really is an amazing community we have! Matt On Thu, May 22, 2014 at 4:46 PM, Matthew Petach wrote: > > looks like i waited too long again to > reserve a hotel room for nanog...anyone > have a double room with an unused bed > they'd be willing to split with a very quiet > roommate? ^_^; > > thanks! > > Matt > > From mpetach at netflight.com Fri May 23 10:03:49 2014 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 23 May 2014 03:03:49 -0700 Subject: Large DDoS, small extortion In-Reply-To: References: Message-ID: On Fri, May 23, 2014 at 1:24 AM, Randy Bush wrote: > > Thanks everyone. There's been a lot of great on and off list > > responses, and we have a much better list of contacts for the next > > time this happens. > > > > We are in contact with the FBI now (very impressed, particularly > > compared to what I expected), and have access to resources that we > > didn't know existed. > > > > Hopefully I'll meet some of you in bellevue next week. > > seeing as the web version of the security track is content free, it > would be cool if you held a little open chat. > > randy > > I replied back privately, as the specific details I had to share weren't really best aired in an archived, public forum. I suspect others might be in a similar position, unfortunately. I can see why the decision to not webcast the security forum is a good one. Matt From gih at apnic.net Fri May 23 11:03:40 2014 From: gih at apnic.net (Geoff Huston) Date: Fri, 23 May 2014 21:03:40 +1000 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> <509325F4-F695-473C-B6FA-309EF7F23116@puck.nether.net> <537EDB78.2000207@studio442.com.au> Message-ID: <8D982768-C0C1-43A7-8F12-3A218C5B63EE@apnic.net> On 23 May 2014, at 3:29 pm, Christopher Morrow wrote: > On Fri, May 23, 2014 at 1:24 AM, Julien Goodwin wrote: >> On 23/05/14 11:21, Jared Mauch wrote: >>> You can't cater to everyones broken network. I can't reach 1.1.1.1 from here either, but sometimes when I travel I can, even with TTL=1. At some point folks have to fix what's broken. >> >> 1.1.1.1 is not private IP space. >> >> BGP routing table entry for 1.1.1.0/24 >> Paths: (2 available, best #1) >> 15169 >> AS-path translation: { Google } >> edge5.Amsterdam1 (metric 20040) >> Origin IGP, metric 100000, localpref 86, valid, internal, best >> Community: Europe Lclprf_86 Netherlands Level3_Peer Amsterdam >> Originator: edge5.Amsterdam1 >> 15169 >> AS-path translation: { Google } >> edge5.Amsterdam1 (metric 20040) >> Origin IGP, metric 100000, localpref 86, valid, internal >> Community: Europe Lclprf_86 Netherlands Level3_Peer Amsterdam >> Originator: edge5.Amsterdam1 >> >> (Yes ok, it doesn't respond to any packets last I checked) > > some times it does > (some portion of the space does/service replies to a sample of packets...) > > Geoff should have more info on the progress of his experiment though. Some time back I did try responding to TCP SYNs with SYN ACKs, to see where it went. But it massively increased load and I gave up. So if 1.1.1.1 responds to you.... its NOT me! Geoff From amitchell at isipp.com Fri May 23 16:02:22 2014 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Fri, 23 May 2014 10:02:22 -0600 Subject: Large DDoS, small extortion In-Reply-To: References: Message-ID: The FBI is all over this, I was coordinating between the agency and several of those first attacked, for a while, and am still in touch with the agency. There is also a private group of the C-level folks of those orgs that have been attacked, who are talking and sharing amongst themselves. For anybody here who has been targeted, contact me offlist (amitchell at isipp.com) if you would a) like to be put in touch with the agency contact who is dealing with this (which I highly recommend) and b) if you'd like an invitation to the private group. I'm on digest, so won't see replies to the list very quickly. Anne Anne P. Mitchell, Attorney at Law CEO/President Institute for Social Internet Public Policy Member, Cal. Bar Cyberspace Law Committee Author: Section 6 of the Federal CAN-SPAM Act of 2003 Ret. Professor of Law, Lincoln Law School of San Jose From gabe at teksavvy.ca Fri May 23 17:08:25 2014 From: gabe at teksavvy.ca (Gabriel Blanchard) Date: Fri, 23 May 2014 13:08:25 -0400 Subject: 60 Hudson Equinix Message-ID: <537F8089.7010202@teksavvy.ca> Apologies for asking on this list but we're looking for a very minimal amount of space in Equinix @ 60 Hudson. 2U worth of space tops with only 1A worth of power. Is there anyone here willing to sub-lease space that would be interested? Email me off-list. -Gabe From bzs at world.std.com Fri May 23 17:13:39 2014 From: bzs at world.std.com (Barry Shein) Date: Fri, 23 May 2014 13:13:39 -0400 Subject: Large DDoS, small extortion In-Reply-To: References: <21374.24658.3602.618224@world.std.com> <0BD7B0BD-7F94-427A-9215-1AFC5828AED5@arbor.net> Message-ID: <21375.33219.250649.91422@world.std.com> Sure, of course, many of us have. But how is $VICTIM supposed to distinguish the wheat from the chaff without reference to specific cases and results? Some reasonable-sounding suggestions could be counter-productive or even downright dangerous (depending on the nature of the attacker.) Or a waste of time. On May 22, 2014 at 23:22 ikiris at gmail.com (Blake Dunlap) wrote: > Most of us wish we didn't. There are so much more productive ways to > spend the day than fighting a determined and adaptive attacker. > > -Blake > > On Thu, May 22, 2014 at 10:20 PM, Roland Dobbins wrote: > > > > On May 23, 2014, at 3:38 AM, Barry Shein wrote: > > > >> Some real life experience and results, case studies. > > > > Some of us have quite a bit of real-life experience and results in these situations. > > > > ---------------------------------------------------------------------- > > Roland Dobbins // > > > > Equo ne credite, Teucri. > > > > -- Laocoön > > -- -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 rdobbins at arbor.net Fri May 23 17:38:49 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 24 May 2014 00:38:49 +0700 Subject: Large DDoS, small extortion In-Reply-To: <21375.33219.250649.91422@world.std.com> References: <21374.24658.3602.618224@world.std.com> <0BD7B0BD-7F94-427A-9215-1AFC5828AED5@arbor.net> <21375.33219.250649.91422@world.std.com> Message-ID: <52B00551-63F6-4E94-8DA6-CFBD871EE509@arbor.net> On May 24, 2014, at 12:13 AM, Barry Shein wrote: > Some reasonable-sounding suggestions could be counter-productive or even downright dangerous (depending on the nature of the attacker.) Or a waste of time. Sure. Every circumstance is different. But there is *one* universal rule Never pay. Never, under any circumstances, pay. Not even if you've persuaded the Men from U.N.C.L.E. to help you, and they suggest you pay because they think they can trace the money, do not pay. Why not? Because, irrespective of what happens with this one attacker, you will be swarmed by countless others. Attackers brag when they're paid; they'll exaggerate how much they received, and then you have a much bigger problem. So, yes - one's own experiences and what one did and how one did it and why one did it and how it turned out are very valuable to share. But never, under any circumstances, for any reason, no matter who advises you to do so, should you pay. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From bzs at world.std.com Fri May 23 18:09:18 2014 From: bzs at world.std.com (Barry Shein) Date: Fri, 23 May 2014 14:09:18 -0400 Subject: Large DDoS, small extortion In-Reply-To: <52B00551-63F6-4E94-8DA6-CFBD871EE509@arbor.net> References: <21374.24658.3602.618224@world.std.com> <0BD7B0BD-7F94-427A-9215-1AFC5828AED5@arbor.net> <21375.33219.250649.91422@world.std.com> <52B00551-63F6-4E94-8DA6-CFBD871EE509@arbor.net> Message-ID: <21375.36558.279277.239681@world.std.com> On May 24, 2014 at 00:38 rdobbins at arbor.net (Roland Dobbins) wrote: > Never, under any circumstances, pay. Not even if you've persuaded > the Men from U.N.C.L.E. to help you, and they suggest you pay > because they think they can trace the money, do not pay. Ok, you're recommending $VICTIM ignores or resists the advice of law enforcement authorities, right? What is this based on other than your subsequent "common sense" reasoning? (directly below) >Why not? > >Because, irrespective of what happens with this one attacker, you >will be swarmed by countless others. Attackers brag when they're >paid; they'll exaggerate how much they received, and then you have a >much bigger problem. By "irrespective of what happens" do you include your earlier suggestion that the attacker might be traced and arrested? Tracing the money in extortion schemes is a common tactic. Obviously the likelihood of success has to be evaluated. But a lot of criminals are dumb or perhaps put better naive. DDos'ing is one thing, successfully laundering money is a different skill set. I just don't know and would suggest reliance on case studies and experienced professionals. -- -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 cscora at apnic.net Fri May 23 18:12:26 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 24 May 2014 04:12:26 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201405231812.s4NICQAH004324@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 24 May, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 495622 Prefixes after maximum aggregation: 194181 Deaggregation factor: 2.55 Unique aggregates announced to Internet: 244818 Total ASes present in the Internet Routing Table: 46929 Prefixes per ASN: 10.56 Origin-only ASes present in the Internet Routing Table: 35829 Origin ASes announcing only one prefix: 16362 Transit ASes present in the Internet Routing Table: 6102 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: 1728 Unregistered ASNs in the Routing Table: 457 Number of 32-bit ASNs allocated by the RIRs: 6690 Number of 32-bit ASNs visible in the Routing Table: 4998 Prefixes from 32-bit ASNs in the Routing Table: 16799 Number of bogon 32-bit ASNs visible in the Routing Table: 144 Special use prefixes present in the Routing Table: 15 Prefixes being announced from unallocated address space: 434 Number of addresses announced to Internet: 2688488320 Equivalent to 160 /8s, 63 /16s and 19 /24s Percentage of available address space announced: 72.6 Percentage of allocated address space announced: 72.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.4 Total number of prefixes smaller than registry allocations: 171648 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 117984 Total APNIC prefixes after maximum aggregation: 35204 APNIC Deaggregation factor: 3.35 Prefixes being announced from the APNIC address blocks: 121068 Unique aggregates announced from the APNIC address blocks: 50794 APNIC Region origin ASes present in the Internet Routing Table: 4939 APNIC Prefixes per ASN: 24.51 APNIC Region origin ASes announcing only one prefix: 1229 APNIC Region transit ASes present in the Internet Routing Table: 868 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 24 Number of APNIC region 32-bit ASNs visible in the Routing Table: 961 Number of APNIC addresses announced to Internet: 733553792 Equivalent to 43 /8s, 185 /16s and 36 /24s Percentage of available APNIC address space announced: 85.7 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: 168311 Total ARIN prefixes after maximum aggregation: 83445 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 169868 Unique aggregates announced from the ARIN address blocks: 79415 ARIN Region origin ASes present in the Internet Routing Table: 16291 ARIN Prefixes per ASN: 10.43 ARIN Region origin ASes announcing only one prefix: 6133 ARIN Region transit ASes present in the Internet Routing Table: 1679 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 107 Number of ARIN addresses announced to Internet: 1075771136 Equivalent to 64 /8s, 30 /16s and 247 /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: 123686 Total RIPE prefixes after maximum aggregation: 62765 RIPE Deaggregation factor: 1.97 Prefixes being announced from the RIPE address blocks: 128237 Unique aggregates announced from the RIPE address blocks: 80797 RIPE Region origin ASes present in the Internet Routing Table: 17689 RIPE Prefixes per ASN: 7.25 RIPE Region origin ASes announcing only one prefix: 8260 RIPE Region transit ASes present in the Internet Routing Table: 2879 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: 2711 Number of RIPE addresses announced to Internet: 658457216 Equivalent to 39 /8s, 63 /16s and 66 /24s Percentage of available RIPE address space announced: 95.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 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: 56758 Total LACNIC prefixes after maximum aggregation: 10069 LACNIC Deaggregation factor: 5.64 Prefixes being announced from the LACNIC address blocks: 63361 Unique aggregates announced from the LACNIC address blocks: 29037 LACNIC Region origin ASes present in the Internet Routing Table: 2095 LACNIC Prefixes per ASN: 30.24 LACNIC Region origin ASes announcing only one prefix: 535 LACNIC Region transit ASes present in the Internet Routing Table: 439 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1187 Number of LACNIC addresses announced to Internet: 162006144 Equivalent to 9 /8s, 168 /16s and 4 /24s Percentage of available LACNIC address space announced: 96.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: 11965 Total AfriNIC prefixes after maximum aggregation: 2661 AfriNIC Deaggregation factor: 4.50 Prefixes being announced from the AfriNIC address blocks: 12654 Unique aggregates announced from the AfriNIC address blocks: 4385 AfriNIC Region origin ASes present in the Internet Routing Table: 721 AfriNIC Prefixes per ASN: 17.55 AfriNIC Region origin ASes announcing only one prefix: 205 AfriNIC Region transit ASes present in the Internet Routing Table: 154 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 32 Number of AfriNIC addresses announced to Internet: 55998976 Equivalent to 3 /8s, 86 /16s and 122 /24s Percentage of available AfriNIC address space announced: 55.6 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 11591 922 Korea Telecom 17974 2793 899 72 PT Telekomunikasi Indonesia 7545 2229 320 117 TPG Telecom Limited 4755 1854 396 199 TATA Communications formerly 9829 1642 1307 32 National Internet Backbone 9583 1302 101 534 Sify Limited 9498 1259 314 85 BHARTI Airtel Ltd. 7552 1226 1082 13 Viettel Corporation 4808 1204 2146 359 CNCGROUP IP network China169 24560 1131 393 184 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 2959 3688 53 BellSouth.net Inc. 22773 2428 2937 133 Cox Communications Inc. 1785 2063 690 151 PaeTec Communications, Inc. 18566 2047 379 178 MegaPath Corporation 20115 1706 1690 566 Charter Communications 4323 1629 1073 413 tw telecom holdings, inc. 701 1471 11190 742 MCI Communications Services, 30036 1417 310 546 Mediacom Communications Corp 6983 1325 800 306 ITC^Deltacom 22561 1307 402 232 CenturyTel Internet Holdings, 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 34984 1704 264 275 TELLCOM ILETISIM HIZMETLERI A 8402 1481 544 16 OJSC "Vimpelcom" 20940 1354 523 1016 Akamai International B.V. 13188 1049 100 28 TOV "Bank-Inform" 8551 1034 370 40 Bezeq International-Ltd 31148 1018 45 19 Freenet Ltd. 6849 822 357 27 JSC "Ukrtelecom" 6830 763 2333 424 Liberty Global Operations B.V 12479 711 795 57 France Telecom Espana SA 9198 574 344 28 JSC Kazakhtelecom 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 3787 1996 100 NET Servi�os de Comunica��o S 10620 2864 463 200 Telmex Colombia S.A. 18881 2007 972 21 Global Village Telecom 7303 1755 1174 229 Telecom Argentina S.A. 8151 1407 2945 409 Uninet S.A. de C.V. 6503 1097 434 60 Axtel, S.A.B. de C.V. 7738 978 1882 40 Telemar Norte Leste S.A. 27947 876 114 50 Telconet S.A 26615 859 2324 34 Tim Celular S.A. 3816 824 339 136 COLOMBIA TELECOMUNICACIONES S 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 1114 240 6 Sudanese Mobile Telephone (ZA 24863 961 280 26 Link Egypt (Link.NET) 6713 615 727 32 Office National des Postes et 8452 582 958 13 TE-AS 24835 304 144 9 Vodafone Data 36992 300 783 24 ETISALAT MISR 3741 248 921 209 Internet Solutions 37054 241 19 6 Data Telecom Service 29571 226 22 16 Cote d'Ivoire Telecom 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 3787 1996 100 NET Servi�os de Comunica��o S 6389 2959 3688 53 BellSouth.net Inc. 4766 2941 11591 922 Korea Telecom 10620 2864 463 200 Telmex Colombia S.A. 17974 2793 899 72 PT Telekomunikasi Indonesia 22773 2428 2937 133 Cox Communications Inc. 7545 2229 320 117 TPG Telecom Limited 1785 2063 690 151 PaeTec Communications, Inc. 18566 2047 379 178 MegaPath Corporation 18881 2007 972 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 2959 2906 BellSouth.net Inc. 17974 2793 2721 PT Telekomunikasi Indonesia 10620 2864 2664 Telmex Colombia S.A. 22773 2428 2295 Cox Communications Inc. 7545 2229 2112 TPG Telecom Limited 4766 2941 2019 Korea Telecom 18881 2007 1986 Global Village Telecom 1785 2063 1912 PaeTec Communications, Inc. 18566 2047 1869 MegaPath Corporation 4755 1854 1655 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 5.109.32.0/19 23456 32bit Transition AS 65456 PRIVATE 5.109.96.0/19 23456 32bit Transition AS 30662 UNALLOCATED 8.2.129.0/24 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 22511 UNALLOCATED 8.28.225.0/24 2828 XO Communications 22511 UNALLOCATED 8.36.68.0/24 2828 XO Communications 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.64.111.0/24 25019 Autonomus System Number for S 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.96.0.0/14 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 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.14.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 41.73.16.0/24 37004 >>UNKNOWN<< 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:12 /10:30 /11:91 /12:258 /13:488 /14:970 /15:1703 /16:12973 /17:6894 /18:11718 /19:24475 /20:34440 /21:36984 /22:52781 /23:46370 /24:263330 /25:768 /26:918 /27:384 /28:12 /29:5 /30:0 /31:0 /32:2 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2002 2047 MegaPath Corporation 6389 1692 2959 BellSouth.net Inc. 22773 1679 2428 Cox Communications Inc. 30036 1254 1417 Mediacom Communications Corp 11492 1175 1215 CABLE ONE, INC. 8402 1174 1481 OJSC "Vimpelcom" 1785 1129 2063 PaeTec Communications, Inc. 36998 1080 1114 Sudanese Mobile Telephone (ZA 6983 1042 1325 ITC^Deltacom 34984 1034 1704 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1129 2:669 3:3 4:15 5:1013 6:19 8:744 12:1849 13:3 14:998 15:13 16:2 17:32 18:21 20:36 23:892 24:1735 25:1 27:1753 31:1474 32:43 33:2 34:5 36:136 37:1890 38:960 39:7 40:202 41:3192 42:251 44:11 46:2085 47:19 49:704 50:937 52:12 54:47 55:4 57:29 58:1230 59:603 60:407 61:1545 62:1216 63:1960 64:4373 65:2289 66:4213 67:2071 68:1038 69:3339 70:856 71:442 72:2013 74:2652 75:324 76:421 77:1583 78:870 79:712 80:1291 81:1157 82:746 83:758 84:744 85:1299 86:463 87:1168 88:485 89:1826 90:140 91:5696 92:699 93:1751 94:2021 95:1512 96:535 97:364 98:1080 99:48 100:56 101:809 103:4936 105:538 106:170 107:602 108:574 109:2029 110:970 111:1298 112:654 113:844 114:862 115:1127 116:1090 117:943 118:1402 119:1350 120:387 121:818 122:2033 123:1317 124:1424 125:1399 128:578 129:340 130:346 131:662 132:400 133:162 134:317 135:74 136:254 137:296 138:357 139:166 140:213 141:373 142:571 143:439 144:505 145:104 146:609 147:475 148:904 149:357 150:167 151:796 152:424 153:218 154:295 155:484 156:340 157:335 158:242 159:900 160:328 161:553 162:1464 163:234 164:690 165:605 166:281 167:619 168:1050 169:124 170:1422 171:187 172:26 173:1691 174:709 175:603 176:1409 177:3010 178:1999 179:657 180:1730 181:1141 182:1565 183:522 184:705 185:1675 186:2795 187:1573 188:1929 189:1447 190:7439 191:318 192:7289 193:5495 194:4036 195:3496 196:1410 197:641 198:5058 199:5541 200:6241 201:2573 202:9014 203:8892 204:4598 205:2671 206:2932 207:2971 208:3978 209:3722 210:3100 211:1680 212:2296 213:2081 214:879 215:86 216:5522 217:1685 218:581 219:320 220:1289 221:599 222:353 223:589 End of report From rdobbins at arbor.net Fri May 23 18:18:01 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 24 May 2014 01:18:01 +0700 Subject: Large DDoS, small extortion In-Reply-To: <21375.36558.279277.239681@world.std.com> References: <21374.24658.3602.618224@world.std.com> <0BD7B0BD-7F94-427A-9215-1AFC5828AED5@arbor.net> <21375.33219.250649.91422@world.std.com> <52B00551-63F6-4E94-8DA6-CFBD871EE509@arbor.net> <21375.36558.279277.239681@world.std.com> Message-ID: <8EBAAAB0-4910-4961-9BC8-0EEC97590A51@arbor.net> On May 24, 2014, at 1:09 AM, Barry Shein wrote: > What is this based on other than your subsequent "common sense" reasoning? (directly below) I've been involved in helping people who've paid. It didn't turn out well (obviously, or they wouldn't need help, heh). > By "irrespective of what happens" do you include your earlier suggestion that the attacker might be traced and arrested? Yes - it doesn't matter even if attacker #1 is traced and arrested (which doesn't happen often, and takes lots and lots of time), if you're now busy dealing with attackers #2 - N. I've never, ever heard of an LEO recommending that someone pay in these particular circumstances - i.e., DDoS extortion. I doubt one ever would. But if one did, I personally wouldn't follow that particular recommendation, and would urge others to seriously think before doing it. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From merike at doubleshotsecurity.com Fri May 23 18:47:50 2014 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Fri, 23 May 2014 11:47:50 -0700 Subject: Large DDoS, small extortion In-Reply-To: References: Message-ID: On May 23, 2014, at 1:24 AM, Randy Bush wrote: >> Thanks everyone. There's been a lot of great on and off list >> responses, and we have a much better list of contacts for the next >> time this happens. >> >> We are in contact with the FBI now (very impressed, particularly >> compared to what I expected), and have access to resources that we >> didn't know existed. >> >> Hopefully I'll meet some of you in bellevue next week. > > seeing as the web version of the security track is content free, it > would be cool if you held a little open chat. Am in discussions with folks who replied to my solicitation yesterday (thanks to those who did) and as soon as topics locked the content free aspect will be modified. - merike (herder of cats for committed speakers for Security Track) -------------- 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 Lee at asgard.org Fri May 23 18:55:18 2014 From: Lee at asgard.org (Lee Howard) Date: Fri, 23 May 2014 14:55:18 -0400 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> <509325F4-F695-473C-B6FA-309EF7F23116@puck.nether.net> Message-ID: On 5/22/14 9:41 PM, "Martin Hannigan" wrote: > > >My job isn't to increase v6. It's to make sure we can serve traffic over >protocols we are asked to. We are dual stacked which means our customers >are. I'm not going to tell you what your job is. I'm curious, though, whether your customers specify the Internet Protocol, and if so, whether they specify a version number? As we say in rfc6540, you should be certain you know whether an implementation is inclusive or exclusive of IPv6. Lee From asullivan at dyn.com Fri May 23 19:19:49 2014 From: asullivan at dyn.com (Andrew Sullivan) Date: Fri, 23 May 2014 15:19:49 -0400 Subject: Large DDoS, small extortion In-Reply-To: <21375.36558.279277.239681@world.std.com> References: <21374.24658.3602.618224@world.std.com> <0BD7B0BD-7F94-427A-9215-1AFC5828AED5@arbor.net> <21375.33219.250649.91422@world.std.com> <52B00551-63F6-4E94-8DA6-CFBD871EE509@arbor.net> <21375.36558.279277.239681@world.std.com> Message-ID: <20140523191948.GI9406@dyn.com> On Fri, May 23, 2014 at 02:09:18PM -0400, Barry Shein wrote: > I just don't know and would suggest reliance on case studies and > experienced professionals. Well, yes, but I also observe that LE's interests and your own as the operator of the site diverge, because their risk isn't the same as yours. It's worth keeping that in one's calculus. A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From merike at doubleshotsecurity.com Fri May 23 19:55:52 2014 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Fri, 23 May 2014 12:55:52 -0700 Subject: Large DDoS, small extortion In-Reply-To: References: Message-ID: <59F32E9A-8B71-4E4A-9139-7983A50CF715@doubleshotsecurity.com> On May 23, 2014, at 3:03 AM, Matthew Petach wrote: > On Fri, May 23, 2014 at 1:24 AM, Randy Bush wrote: > >>> Thanks everyone. There's been a lot of great on and off list >>> responses, and we have a much better list of contacts for the next >>> time this happens. >>> >>> We are in contact with the FBI now (very impressed, particularly >>> compared to what I expected), and have access to resources that we >>> didn't know existed. >>> >>> Hopefully I'll meet some of you in bellevue next week. >> >> seeing as the web version of the security track is content free, it >> would be cool if you held a little open chat. >> >> randy >> >> > I replied back privately, as the specific details > I had to share weren't really best aired in an > archived, public forum. I suspect others might > be in a similar position, unfortunately. > I can see why the decision to not webcast > the security forum is a good one. Whoop I may have mis-read Randy's first comment to mean there's no definitive agenda listed yet. But yes, definitely not streamed or recorded since we do want to have some open discussion on items that people don't want attributed nor shared in a public way. I've already had at least one specific request where speaker wants to give some details that they don't want to be attributed. - merike -------------- 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 cidr-report at potaroo.net Fri May 23 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 May 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201405232200.s4NM00vi005330@wattle.apnic.net> This report has been generated at Fri May 23 21:13:54 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 16-05-14 500575 281800 17-05-14 500395 282083 18-05-14 500335 282247 19-05-14 500503 281866 20-05-14 500758 282267 21-05-14 501860 282920 22-05-14 501994 282240 23-05-14 501454 282453 AS Summary 47199 Number of ASes in routing system 19224 Number of ASes announcing only one prefix 3786 Largest number of prefixes announced by an AS AS28573: NET Servi�os de Comunica��o S.A.,BR 120042496 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 23May14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 501865 282546 219319 43.7% All ASes AS28573 3786 547 3239 85.6% NET Servi�os de Comunica��o S.A.,BR AS6389 2959 76 2883 97.4% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2794 248 2546 91.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS4766 2941 931 2010 68.3% KIXS-AS-KR Korea Telecom,KR AS18881 2007 37 1970 98.2% Global Village Telecom,BR AS1785 2106 401 1705 81.0% AS-PAETEC-NET - PaeTec Communications, Inc.,US AS10620 2864 1369 1495 52.2% Telmex Colombia S.A.,CO AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation,US AS7303 1760 442 1318 74.9% Telecom Argentina S.A.,AR AS4755 1854 586 1268 68.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4323 1640 425 1215 74.1% TWTC - tw telecom holdings, inc.,US AS7545 2248 1066 1182 52.6% TPG-INTERNET-AP TPG Telecom Limited,AU AS22773 2423 1294 1129 46.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS7552 1253 149 1104 88.1% VIETEL-AS-AP Viettel Corporation,VN AS36998 1114 37 1077 96.7% SDN-MOBITEL,SD AS22561 1307 241 1066 81.6% AS22561 - CenturyTel Internet Holdings, Inc.,US AS6983 1325 307 1018 76.8% ITCDELTA - Earthlink, Inc.,US AS9829 1651 733 918 55.6% BSNL-NIB National Internet Backbone,IN AS4788 1053 148 905 85.9% TMNET-AS-AP TM Net, Internet Service Provider,MY AS9808 1007 158 849 84.3% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS4808 1209 401 808 66.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS7738 978 185 793 81.1% Telemar Norte Leste S.A.,BR AS24560 1131 362 769 68.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS18101 942 186 756 80.3% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS26615 859 107 752 87.5% Tim Celular S.A.,BR AS8551 1037 286 751 72.4% BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbone,IL AS8151 1416 680 736 52.0% Uninet S.A. de C.V.,MX AS701 1470 741 729 49.6% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US AS855 756 58 698 92.3% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA AS6147 779 113 666 85.5% Telefonica del Peru S.A.A.,PE Total 50716 12879 37837 74.6% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.236.0/24 AS37290 -Reserved AS-,ZZ 41.78.237.0/24 AS37290 -Reserved AS-,ZZ 41.78.238.0/24 AS37290 -Reserved AS-,ZZ 41.78.239.0/24 AS37290 -Reserved AS-,ZZ 41.189.96.0/19 AS37000 -Reserved AS-,ZZ 41.190.72.0/24 AS37451 CongoTelecom,CG 41.190.73.0/24 AS37451 CongoTelecom,CG 41.190.74.0/24 AS37451 CongoTelecom,CG 41.190.75.0/24 AS37451 CongoTelecom,CG 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.111.160.0/20 AS40551 -Reserved AS-,ZZ 64.111.160.0/24 AS40551 -Reserved AS-,ZZ 64.111.161.0/24 AS40551 -Reserved AS-,ZZ 64.111.162.0/24 AS40551 -Reserved AS-,ZZ 64.111.167.0/24 AS40551 -Reserved AS-,ZZ 64.111.169.0/24 AS40551 -Reserved AS-,ZZ 64.111.170.0/24 AS40551 -Reserved AS-,ZZ 64.111.171.0/24 AS40551 -Reserved AS-,ZZ 64.111.172.0/24 AS40551 -Reserved AS-,ZZ 64.111.173.0/24 AS40551 -Reserved AS-,ZZ 64.111.174.0/24 AS40551 -Reserved AS-,ZZ 64.111.175.0/24 AS40551 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.115.124.0/23 AS46540 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 -Reserved AS-,ZZ 74.120.214.0/23 AS32326 -Reserved AS-,ZZ 74.120.240.0/21 AS30063 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.122.224.0/21 AS30063 -Reserved AS-,ZZ 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD,RU 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT 91.229.182.0/24 AS56960 -Reserved AS-,ZZ 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 95.215.140.0/22 AS48949 -Reserved AS-,ZZ 100.64.111.0/24 AS25019 SAUDINETSTC-AS SaudiNet, Saudi Telecom Company,SA 100.88.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.89.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.90.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.91.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.92.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.93.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.94.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.95.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.96.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.100.1.0/24 AS26219 Skycorp S.A.,AR 100.104.0.0/13 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.112.0.0/13 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.120.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.124.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN 103.18.76.0/22 AS18097 JPNIC-ASBLOCK-AP JPNIC,JP 103.18.80.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK 103.18.81.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK 103.23.48.0/24 AS56194 103.23.49.0/24 AS56194 103.23.50.0/24 AS56194 103.23.51.0/24 AS56194 103.244.236.0/22 AS58794 103.247.52.0/23 AS4725 ODN SOFTBANK TELECOM Corp.,JP 104.36.40.0/22 AS4474 TCT-AS - TCT West, Inc.,US 104.128.48.0/20 AS32748 STEADFAST - Steadfast Networks,US 104.128.48.0/22 AS32181 ASN-GIGENET - GigeNET,US 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.158.28.0/22 AS45857 154.121.0.0/24 AS32771 ATM,DZ 154.121.1.0/24 AS32771 ATM,DZ 154.121.2.0/24 AS32771 ATM,DZ 154.121.3.0/24 AS32771 ATM,DZ 154.121.4.0/24 AS32771 ATM,DZ 154.121.5.0/24 AS32771 ATM,DZ 163.47.23.0/24 AS2907 JPNIC-2BYTE-ASBLOCK-AP for assignment to JPNIC members,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.80.9.0/24 AS26219 Skycorp S.A.,AR 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.90.1.0/24 AS26219 Skycorp S.A.,AR 172.90.3.0/24 AS26219 Skycorp S.A.,AR 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 173.213.208.0/22 AS54040 -Reserved AS-,ZZ 173.213.212.0/24 AS54040 -Reserved AS-,ZZ 173.213.213.0/24 AS54040 -Reserved AS-,ZZ 173.213.214.0/23 AS54040 -Reserved AS-,ZZ 173.213.216.0/21 AS54040 -Reserved AS-,ZZ 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 176.125.224.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.58.176.0/22 AS28792 PUBLIC-INTERNET Public Internet Ltd,GB 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A.,EC 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc.,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.84.187.0/24 AS16276 OVH OVH SAS,FR 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.112.0/23 AS12964 DBMG-DE Dr. Buelow & Masiak GmbH,DE 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.243.166.0/24 AS44093 -Reserved AS-,ZZ 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.69.203.0/24 AS5089 NTL Virgin Media Limited,GB 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.39.252.0/23 AS29004 -Reserved AS-,ZZ 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL,RO 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.2.224.0/22 AS24863 LINKdotNET-AS,EG 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.13.201.0/24 AS2018 TENET-1,ZA 196.13.202.0/24 AS2018 TENET-1,ZA 196.13.203.0/24 AS2018 TENET-1,ZA 196.13.204.0/24 AS2018 TENET-1,ZA 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.45.0.0/21 AS26625 -Reserved AS-,ZZ 196.45.10.0/24 AS26625 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.9.40.0/24 AS56194 202.9.41.0/24 AS56194 202.9.42.0/24 AS56194 202.9.43.0/24 AS56194 202.9.44.0/24 AS56194 202.9.45.0/24 AS56194 202.9.46.0/24 AS56194 202.9.47.0/24 AS56194 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.10.94.0/23 AS30097 NUWAVE - NuWave,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/22 AS16936 -Reserved AS-,ZZ 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.73.112.0/24 AS19231 -Reserved AS-,ZZ 208.73.113.0/24 AS19231 -Reserved AS-,ZZ 208.73.114.0/24 AS19231 -Reserved AS-,ZZ 208.73.115.0/24 AS19231 -Reserved AS-,ZZ 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US 209.17.224.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.225.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.226.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.227.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.228.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.229.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.230.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.231.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.232.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.233.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.234.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.235.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.236.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.237.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.238.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.239.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.240.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.241.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.242.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.243.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.244.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.245.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.246.0/24 AS14846 CGNOGE - NBC Internet,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 212.119.32.0/19 AS12550 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.178.96.0/21 AS17035 -Reserved AS-,ZZ 216.178.104.0/21 AS17035 -Reserved AS-,ZZ 216.203.80.0/20 AS27021 -Reserved AS-,ZZ 216.203.80.0/21 AS27021 -Reserved AS-,ZZ 216.203.87.0/24 AS27021 -Reserved AS-,ZZ 216.203.88.0/21 AS27021 -Reserved AS-,ZZ 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 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 May 23 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 May 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201405232200.s4NM01Jo005348@wattle.apnic.net> BGP Update Report Interval: 15-May-14 -to- 22-May-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 116359 3.4% 70.5 -- BSNL-NIB National Internet Backbone,IN 2 - AS45514 90170 2.6% 332.7 -- TELEMEDIA-SMB-AS-AP Bharti Airtel Ltd., TELEMEDIA Services, for SMB customers,IN 3 - AS13238 75821 2.2% 257.0 -- YANDEX Yandex LLC,RU 4 - AS8402 46535 1.4% 26.9 -- CORBINA-AS OJSC "Vimpelcom",RU 5 - AS28573 44405 1.3% 11.5 -- NET Servi�os de Comunica��o S.A.,BR 6 - AS4775 35456 1.0% 285.9 -- GLOBE-TELECOM-AS Globe Telecoms,PH 7 - AS10620 25281 0.7% 8.8 -- Telmex Colombia S.A.,CO 8 - AS27738 24997 0.7% 43.3 -- Ecuadortelecom S.A.,EC 9 - AS23752 24978 0.7% 181.0 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 10 - AS41691 19795 0.6% 549.9 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 11 - AS3816 19145 0.6% 22.9 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 12 - AS16625 17281 0.5% 36.5 -- AKAMAI-AS - Akamai Technologies, Inc.,US 13 - AS14259 15757 0.5% 58.8 -- Gtd Internet S.A.,CL 14 - AS25184 14882 0.4% 118.1 -- AFRANET AFRANET Co. Tehran, Iran,IR 15 - AS9583 14774 0.4% 10.2 -- SIFY-AS-IN Sify Limited,IN 16 - AS35819 13516 0.4% 25.0 -- MOBILY-AS Etihad Etisalat Company (Mobily),SA 17 - AS17974 12798 0.4% 4.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID 18 - AS7552 12552 0.4% 10.1 -- VIETEL-AS-AP Viettel Corporation,VN 19 - AS31148 12438 0.4% 12.2 -- FREENET-AS Freenet Ltd.,UA 20 - AS4766 12243 0.3% 4.2 -- KIXS-AS-KR Korea Telecom,KR TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS60345 10049 0.3% 5024.5 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 2 - AS4 3939 0.1% 824.0 -- ISI-AS - University of Southern California,US 3 - AS45590 2901 0.1% 2901.0 -- HGCINTNET-AS-AP Hutch Connect,HK 4 - AS16321 6691 0.2% 2230.3 -- AICONET-AS Aiconet Ltd.,RU 5 - AS60134 1848 0.1% 1848.0 -- FRESHNET-AS FreshNet Ltd.,UA 6 - AS3 1453 0.0% 1987.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 7 - AS54465 7022 0.2% 1404.4 -- QPM-AS-1 - QuickPlay Media Inc.,US 8 - AS52879 7016 0.2% 779.6 -- ABM INFORMATICA E TELECOM,BR 9 - AS37626 1365 0.0% 682.5 -- OceanBrave-AS,NG 10 - AS55393 1320 0.0% 660.0 -- MIDOKURA Midokura Co., Ltd,JP 11 - AS3 640 0.0% 1550.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 12 - AS41691 19795 0.6% 549.9 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 13 - AS60135 488 0.0% 488.0 -- WEBSTAR-NET WebStar Ltd.,RU 14 - AS2 5673 0.2% 1131.0 -- UDEL-DCN - University of Delaware,US 15 - AS40173 463 0.0% 463.0 -- IRBS-ASN - IRBS Engineering, Inc.,US 16 - AS22416 441 0.0% 441.0 -- -Reserved AS-,ZZ 17 - AS35093 1251 0.0% 417.0 -- RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 18 - AS45688 1197 0.0% 399.0 -- UT-NSRG The University of Tokyo Interfaculty Initiative in Information Studies,JP 19 - AS11504 380 0.0% 380.0 -- WHITE-CASE-1155 - White & Case,US 20 - AS42561 749 0.0% 374.5 -- GRAD-AS OOO "NTS GRADIENT",RU TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 89.221.206.0/24 19588 0.5% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 2 - 202.70.88.0/21 11319 0.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 202.70.64.0/21 11209 0.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 192.58.232.0/24 10690 0.3% AS6629 -- NOAA-AS - NOAA,US 5 - 78.109.192.0/20 10233 0.3% AS25184 -- AFRANET AFRANET Co. Tehran, Iran,IR 6 - 120.28.62.0/24 7829 0.2% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 7 - 222.127.0.0/24 7639 0.2% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 8 - 205.247.12.0/24 7614 0.2% AS6459 -- TRANSBEAM - I-2000, Inc.,US 9 - 115.170.128.0/17 7155 0.2% AS4847 -- CNIX-AP China Networks Inter-Exchange,CN 10 - 206.152.15.0/24 7006 0.2% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.,US 11 - 42.83.48.0/20 5921 0.2% AS18135 -- JPNIC-ASBLOCK-AP JPNIC,JP 12 - 78.158.184.0/24 5026 0.1% AS60345 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 13 - 5.160.10.0/24 5023 0.1% AS60345 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 14 - 186.237.56.0/22 3939 0.1% AS4 -- ISI-AS - University of Southern California,US 15 - 112.137.16.0/20 2901 0.1% AS45590 -- HGCINTNET-AS-AP Hutch Connect,HK 16 - 84.205.66.0/24 2754 0.1% AS12654 -- RIPE-NCC-RIS-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC),EU 17 - 66.171.233.0/24 2542 0.1% AS4436 -- AS-GTT-4436 - nLayer Communications, Inc.,US 18 - 66.171.236.0/24 2542 0.1% AS4436 -- AS-GTT-4436 - nLayer Communications, Inc.,US 19 - 185.27.8.0/22 2531 0.1% AS42525 -- GlobalConnect a/s,DK 20 - 176.116.240.0/20 2233 0.1% AS16321 -- AICONET-AS Aiconet Ltd.,RU 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 LarrySheldon at cox.net Fri May 23 23:47:57 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 23 May 2014 18:47:57 -0500 Subject: Large DDoS, small extortion In-Reply-To: <5WAT1o0181cZc5601WAVRQ> References: <21374.24658.3602.618224@world.std.com> <0BD7B0BD-7F94-427A-9215-1AFC5828AED5@arbor.net> <21375.33219.250649.91422@world.std.com> <52B00551-63F6-4E94-8DA6-CFBD871EE509@arbor.net> <5WAT1o0181cZc5601WAVRQ> Message-ID: <537FDE2D.3060204@cox.net> On 5/23/2014 1:09 PM, Barry Shein wrote: > > On May 24, 2014 at 00:38 rdobbins at arbor.net (Roland Dobbins) wrote: > > Never, under any circumstances, pay. Not even if you've persuaded > > the Men from U.N.C.L.E. to help you, and they suggest you pay > > because they think they can trace the money, do not pay. > > Ok, you're recommending $VICTIM ignores or resists the advice of law > enforcement authorities, right? Given the the current status of reputation, ordinary, run-of-the-mill common sense, and a calm, reflective consideration of the obvious, I would say yes, follow the advice that makes sense, but pay NO money, not even as bait. If they want to put up taxpayer money from their budget, I would still worry for the reasons given. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From rbf+nanog at panix.com Sat May 24 00:39:31 2014 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Fri, 23 May 2014 19:39:31 -0500 Subject: Large DDoS, small extortion In-Reply-To: <21375.36558.279277.239681@world.std.com> References: <21374.24658.3602.618224@world.std.com> <0BD7B0BD-7F94-427A-9215-1AFC5828AED5@arbor.net> <21375.33219.250649.91422@world.std.com> <52B00551-63F6-4E94-8DA6-CFBD871EE509@arbor.net> <21375.36558.279277.239681@world.std.com> Message-ID: <20140524003931.GA25199@panix.com> On Fri, May 23, 2014 at 02:09:18PM -0400, Barry Shein wrote: > > On May 24, 2014 at 00:38 rdobbins at arbor.net (Roland Dobbins) wrote: > > Never, under any circumstances, pay. Not even if you've persuaded > > the Men from U.N.C.L.E. to help you, and they suggest you pay > > because they think they can trace the money, do not pay. > > Ok, you're recommending $VICTIM ignores or resists the advice of law > enforcement authorities, right? Law enforcement and victims have different objectives. Law enforcement wants to find the criminal, gather sufficient evidence to prove their guilt, then prosecute them. More attacks helps law enforcement. The victims, in general, want the attacks to stop. > I just don't know and would suggest reliance on case studies and > experienced professionals. Agreed. But make sure the experienced professionals you talk with have interests that are aligned with yours. (Not arguing pay or don't pay here. I don't know, either. My instincts say "don't pay" but I have no data.) -- Brett From LarrySheldon at cox.net Sat May 24 02:00:20 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 23 May 2014 21:00:20 -0500 Subject: Oddity Message-ID: <537FFD34.9020601@cox.net> Odd that "comics.com" is dead and "gocomics.com" is "down for Scheduled Maintenance" at 2000 Central USA time. No the Intertubes are not down--lots of stuff is working, but those and some others are not. (Cox customer out of Omaha). -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From LarrySheldon at cox.net Sat May 24 02:02:34 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 23 May 2014 21:02:34 -0500 Subject: Oddity In-Reply-To: <5e1G1o01v1cZc5601e1JLu> References: <5e1G1o01v1cZc5601e1JLu> Message-ID: <537FFDBA.5050405@cox.net> On 5/23/2014 9:00 PM, Larry Sheldon wrote: > Odd that "comics.com" is dead and "gocomics.com" is "down for Scheduled > Maintenance" at 2000 Central USA time. > > No the Intertubes are not down--lots of stuff is working, but those and > some others are not. (Cox customer out of Omaha). Yes, I considered that they might be the same place. No I have not checked it out. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From faisal at snappytelecom.net Sat May 24 14:30:58 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 24 May 2014 14:30:58 +0000 (GMT) Subject: Linkedin Peering Contact In-Reply-To: <128952026.485479.1400941729489.JavaMail.root@snappytelecom.net> Message-ID: <286636666.485489.1400941858099.JavaMail.root@snappytelecom.net> Hello, I am trying to contact the folks responsible for Linkedin Peering. Can you please send me you contact info off list. (emails to addresses listed in peeringdb are being bounced back by the mail server) Thanks 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 From amitchell at isipp.com Sat May 24 16:29:14 2014 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Sat, 24 May 2014 10:29:14 -0600 Subject: Large DDoS, small extortion In-Reply-To: References: Message-ID: <0964540F-333F-4784-8812-592C1FCFB293@isipp.com> > Law enforcement and victims have different objectives. Law enforcement > wants to find the criminal, gather sufficient evidence to prove their > guilt, then prosecute them. More attacks helps law enforcement. > > The victims, in general, want the attacks to stop. Actually, our experience in this particular case (it is the same person(s) hitting all of the targets, even using the same email addresses, etc.) is that the victims want to find the guy too. In fact, I can say with a fair degree of certainty that the coordinated efforts of a dedicated group of "victims", who have come together without regards to the fact that they are otherwise 'competitors' in business, and who have furnished the agencies with useable technical information about the attacks, have given the agencies a substantial leg up in the investigation. Anne Anne P. Mitchell, Attorney at Law CEO/President Institute for Social Internet Public Policy Member, Cal. Bar Cyberspace Law Committee Author: Section 6 of the Federal CAN-SPAM Act of 2003 Ret. Professor of Law, Lincoln Law School of San Jose From m.hotze at hotze.com Sat May 24 17:49:01 2014 From: m.hotze at hotze.com (Martin Hotze) Date: Sat, 24 May 2014 17:49:01 +0000 Subject: help with CF card on Catalyst 6500 with Sup720 Message-ID: Hi, can anyone provide a dd-image from a CF card from a Catalyst 6500 with Sup720, please. We have a refurbished 6500 w/ Sup720-3BXL with an old rommon which is not able to format a CF card. (various other methods with formatting FAT16 on Linux etc. did not work; google search only pointed to format within a running system, but we do not have such a system nearby) IOS image is already present. any help appreciated. thanks, martin From florian.hibler at kaiaglobal.com Sat May 24 18:42:38 2014 From: florian.hibler at kaiaglobal.com (Florian Hibler) Date: Sat, 24 May 2014 12:42:38 -0600 Subject: help with CF card on Catalyst 6500 with Sup720 In-Reply-To: References: Message-ID: <2483429588500727800@unknownmsgid> Hi Martin, Unfortunately I cannot provide you a dd-image, although I had the same issue a couple of times. What helped me was formatting the cf with fat16 and using the 2nd cf slot on the sup instead of the first one. Hope that works for you as well. Cheers, Florian > On 24 May 2014, at 11:50, Martin Hotze wrote: > > Hi, > > can anyone provide a dd-image from a CF card from a Catalyst 6500 with Sup720, please. > > We have a refurbished 6500 w/ Sup720-3BXL with an old rommon which is not able to format a CF card. > > (various other methods with formatting FAT16 on Linux etc. did not work; google search only pointed to format within a running system, but we do not have such a system nearby) > > IOS image is already present. > > any help appreciated. > > thanks, martin > > From bzs at world.std.com Sat May 24 20:13:38 2014 From: bzs at world.std.com (Barry Shein) Date: Sat, 24 May 2014 16:13:38 -0400 Subject: Large DDoS, small extortion In-Reply-To: <20140523191948.GI9406@dyn.com> References: <21374.24658.3602.618224@world.std.com> <0BD7B0BD-7F94-427A-9215-1AFC5828AED5@arbor.net> <21375.33219.250649.91422@world.std.com> <52B00551-63F6-4E94-8DA6-CFBD871EE509@arbor.net> <21375.36558.279277.239681@world.std.com> <20140523191948.GI9406@dyn.com> Message-ID: <21376.64882.131850.300731@world.std.com> On May 23, 2014 at 15:19 asullivan at dyn.com (Andrew Sullivan) wrote: > On Fri, May 23, 2014 at 02:09:18PM -0400, Barry Shein wrote: > > I just don't know and would suggest reliance on case studies and > > experienced professionals. > > Well, yes, but I also observe that LE's interests and your own as the > operator of the site diverge, because their risk isn't the same as > yours. It's worth keeping that in one's calculus. Good point. There is the danger of "the operation was a success but the patient died" (i.e., they caught the perp but destroyed your business in the process.) -- -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 faisal at snappytelecom.net Sat May 24 21:38:27 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 24 May 2014 21:38:27 +0000 (GMT) Subject: Linkedin Peering Contact In-Reply-To: <286636666.485489.1400941858099.JavaMail.root@snappytelecom.net> References: <286636666.485489.1400941858099.JavaMail.root@snappytelecom.net> Message-ID: <704469448.487970.1400967507297.JavaMail.root@snappytelecom.net> Thanks you for everyone who replied. I am in contact with Zaid. Wishing everyone a great weekend. 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: "Faisal Imtiaz" > To: "NANOG" > Sent: Saturday, May 24, 2014 10:30:58 AM > Subject: Linkedin Peering Contact > > Hello, > > I am trying to contact the folks responsible for Linkedin Peering. > > Can you please send me you contact info off list. > > (emails to addresses listed in peeringdb are being bounced back by the mail > server) > > Thanks > > > 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 > > From LarrySheldon at cox.net Sun May 25 00:09:06 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 24 May 2014 19:09:06 -0500 Subject: Large DDoS, small extortion In-Reply-To: <5sW71o02B1cZc5601sW9pk> References: <5sW71o02B1cZc5601sW9pk> Message-ID: <538134A2.6050001@cox.net> On 5/24/2014 11:29 AM, Anne P. Mitchell, Esq. wrote: > >> Law enforcement and victims have different objectives. Law >> enforcement wants to find the criminal, gather sufficient evidence >> to prove their guilt, then prosecute them. More attacks helps law >> enforcement. >> >> The victims, in general, want the attacks to stop. > > Actually, our experience in this particular case (it is the same > person(s) hitting all of the targets, even using the same email > addresses, etc.) is that the victims want to find the guy too. In > fact, I can say with a fair degree of certainty that the coordinated > efforts of a dedicated group of "victims", who have come together > without regards to the fact that they are otherwise 'competitors' in > business, and who have furnished the agencies with useable technical > information about the attacks, have given the agencies a substantial > leg up in the investigation. All that from a far greater authority than I. But lest my weak words be misunderstood, I have no objection what ever to providing technical information (and facilities, even)--it is ONLY the paying of ransom that I object to. And I think I would say that if I were the captive. I think over the long haul the odds are that if you DO pay the ransom, the victim will be dead anyway. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From faisal at snappytelecom.net Tue May 27 13:49:14 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Tue, 27 May 2014 13:49:14 +0000 (GMT) Subject: Contact for Road Runner In-Reply-To: <321062072.515651.1401198434541.JavaMail.root@snappytelecom.net> Message-ID: <475978951.515662.1401198554218.JavaMail.root@snappytelecom.net> Hello, I am looking to get in touch with anyone who is responsible for Routing Registry Objects at Road Runner Cable. Can you please reply back to me off list. (We need to have an older ASN RR Object Created by rr.com to be removed please). Thanks. 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 From nick at flhsi.com Tue May 27 14:30:28 2014 From: nick at flhsi.com (Nick Olsen) Date: Tue, 27 May 2014 10:30:28 -0400 Subject: Contact for Road Runner Message-ID: <7107f5bf$345ccb5f$2ee43f73$@flhsi.com> Hey Faisal, We use to have peering with Road Runner (Bright House Networks) ~6 years ago. At that time, They created a RR object (RADB) for our AS that specifically said ROAD RUNNER. Which caused all kinds of havoc as some databases would pull that over the "AS NAME" when listing our network. They even updated the registry a couple of times in the years following our termination of their service. Emails to their RADB email, As well as to their direct support went completely unanswered. The solution for me was asking Merit (RADB's Parent company..whatever they are). To forcibly remove the entry, They did so about two hours after my email to them and were extremely helpful. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Faisal Imtiaz" Sent: Tuesday, May 27, 2014 9:52 AM To: "NANOG" Subject: Contact for Road Runner Hello, I am looking to get in touch with anyone who is responsible for Routing Registry Objects at Road Runner Cable. Can you please reply back to me off list. (We need to have an older ASN RR Object Created by rr.com to be removed please). Thanks. 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 From mhuff at ox.com Tue May 27 18:24:33 2014 From: mhuff at ox.com (Matthew Huff) Date: Tue, 27 May 2014 18:24:33 +0000 Subject: Cogent / Internap issue ?? Message-ID: <4baaf84129e54ee38a5aaac92772186f@pur-vm-exch13n1.ox.com> We are having troubles reaching services on the other side of cogent/internap peering. Anyone else seeing issues? Basically 14607 -> 6128 -> 174 -> 14744. Type escape sequence to abort. Tracing the route to 72.5.52.199 VRF info: (vrf in name/id, vrf out name/id) 1 24.157.32.249 [AS 6128] 4 msec 4 msec 4 msec 2 24.38.117.6 [AS 6128] 4 msec 8 msec 4 msec 3 167.206.183.29 [AS 6128] 4 msec 4 msec 8 msec 4 * * * 5 * * * 6 154.54.47.17 [AS 174] 4 msec 154.54.47.29 [AS 174] 8 msec 154.54.44.69 [AS 174] 4 msec 7 66.28.4.202 [AS 174] 28 msec 28 msec 154.54.6.190 [AS 174] 28 msec 8 154.54.6.85 [AS 174] 40 msec 154.54.24.81 [AS 174] 36 msec 154.54.6.117 [AS 174] 40 msec 9 154.54.26.113 [AS 174] 52 msec 154.54.26.121 [AS 174] 52 msec 154.54.26.129 [AS 174] 48 msec 10 154.54.25.70 [AS 174] 64 msec 154.54.25.66 [AS 174] 60 msec 154.54.25.70 [AS 174] 60 msec 11 154.54.2.197 [AS 174] 92 msec 88 msec 84 msec 12 154.54.0.249 [AS 174] 80 msec 154.54.0.253 [AS 174] 80 msec 154.54.0.249 [AS 174] 84 msec 13 154.54.41.142 [AS 174] 152 msec 224 msec 92 msec 14 38.122.90.42 [AS 174] 84 msec 84 msec 38.104.124.82 [AS 174] 80 msec 15 63.251.160.18 [AS 14744] 76 msec 76 msec 72 msec 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * ---- Matthew Huff             | 1 Manhattanville Rd Director of Operations   | Purchase, NY 10577 OTA Management LLC       | Phone: 914-460-4039 From bmanning at isi.edu Tue May 27 18:28:00 2014 From: bmanning at isi.edu (manning bill) Date: Tue, 27 May 2014 11:28:00 -0700 Subject: crave your indulgence Message-ID: <110B4198-E9C2-490D-AF82-01C8AF4CEF31@isi.edu> If you wouldn’t mind a quick tracerooute - Can you confirm reachability to the following: 2001:500:84::b Thanks in advance. /bill Neca eos omnes. Deus suos agnoscet. From john-nanog at peachfamily.net Tue May 27 18:33:15 2014 From: john-nanog at peachfamily.net (John Peach) Date: Tue, 27 May 2014 14:33:15 -0400 Subject: crave your indulgence In-Reply-To: <110B4198-E9C2-490D-AF82-01C8AF4CEF31@isi.edu> References: <110B4198-E9C2-490D-AF82-01C8AF4CEF31@isi.edu> Message-ID: <20140527143315.61980f97@jpeach-desktop.anbg.mssm.edu> traceroute to 2001:500:84::b (2001:500:84::b) from 2a04:840:0:2::8baf:41a6, 30 hops max, 24 byte packets 1 2a04:840:0:2::1 (2a04:840:0:2::1) 0.299 ms 0.299 ms 1.03 ms 2 2a00:1c10:3:667::a (2a00:1c10:3:667::a) 1.172 ms 1.42 ms 1.355 ms 3 rtr-23-121-141-2914.thn.v6.custdc.net (2a00:1c10:ffff:1::2914:161) 3.375 ms 2.768 ms 3.684 ms 4 ae-4.r23.londen03.uk.bb.gin.ntt.net (2001:728:0:2000::29) 1.866 ms 1.899 ms 1.866 ms 5 ae-3.r22.amstnl02.nl.bb.gin.ntt.net (2001:728:0:2000::16) 9.383 ms 36.228 ms 9.444 ms 6 ae-0.r23.amstnl02.nl.bb.gin.ntt.net (2001:418:0:2000::1c6) 9.367 ms 19.211 ms 9.387 ms 7 ae-7.r21.asbnva02.us.bb.gin.ntt.net (2001:418:0:2000::1b1) 91.736 ms 91.679 ms 91.688 ms 8 ae-0.r20.asbnva02.us.bb.gin.ntt.net (2001:418:0:2000::d) 102.92 ms 91.509 ms 91.442 ms 9 ae-2.r21.lsanca03.us.bb.gin.ntt.net (2001:418:0:2000::1f6) 156.269 ms 156.27 ms 156.435 ms 10 ae-2.r05.lsanca03.us.bb.gin.ntt.net (2001:418:0:2000::14e) 154.111 ms 153.917 ms 153.976 ms 11 * 2001:418:1401:1a::2 (2001:418:1401:1a::2) 150.113 ms * 12 2001:1878::181:177 (2001:1878::181:177) 172.279 ms 168.706 ms 160.806 ms 13 2001:500:84::b (2001:500:84::b) 156.772 ms 156.17 ms 148.251 ms On Tue, 27 May 2014 11:28:00 -0700 manning bill wrote: > If you wouldn’t mind a quick tracerooute - Can you confirm > reachability to the following: > > 2001:500:84::b > > Thanks in advance. > > /bill > Neca eos omnes. Deus suos agnoscet. > From brak at gameservers.com Tue May 27 18:35:10 2014 From: brak at gameservers.com (Brian Rak) Date: Tue, 27 May 2014 14:35:10 -0400 Subject: crave your indulgence In-Reply-To: <110B4198-E9C2-490D-AF82-01C8AF4CEF31@isi.edu> References: <110B4198-E9C2-490D-AF82-01C8AF4CEF31@isi.edu> Message-ID: <5384DADE.6010004@gameservers.com> This seems like a perfect use for ATLAS: https://atlas.ripe.net/ On 5/27/2014 2:28 PM, manning bill wrote: > If you wouldn’t mind a quick tracerooute - Can you confirm reachability to the following: > > 2001:500:84::b > > Thanks in advance. > > /bill > Neca eos omnes. Deus suos agnoscet. > From mhuff at ox.com Tue May 27 18:39:55 2014 From: mhuff at ox.com (Matthew Huff) Date: Tue, 27 May 2014 18:39:55 +0000 Subject: Cogent / Internap issue ?? In-Reply-To: <4baaf84129e54ee38a5aaac92772186f@pur-vm-exch13n1.ox.com> References: <4baaf84129e54ee38a5aaac92772186f@pur-vm-exch13n1.ox.com> Message-ID: <2c33b32d44524d96b3ad98d71c531133@pur-vm-exch13n1.ox.com> Just to clarify, it's not just a traceroute issue. I can't ping nor connect to port 80/443 to the ip address 72.5.52.199 from our network, although I can do both from an external shell account. It's very possible that it's a routing issue on the other side, and I'm reaching out to them as well. ---- Matthew Huff             | 1 Manhattanville Rd Director of Operations   | Purchase, NY 10577 OTA Management LLC       | Phone: 914-460-4039 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew Huff Sent: Tuesday, May 27, 2014 2:25 PM To: nanog at nanog.org Subject: Cogent / Internap issue ?? We are having troubles reaching services on the other side of cogent/internap peering. Anyone else seeing issues? Basically 14607 -> 6128 -> 174 -> 14744. Type escape sequence to abort. Tracing the route to 72.5.52.199 VRF info: (vrf in name/id, vrf out name/id) 1 24.157.32.249 [AS 6128] 4 msec 4 msec 4 msec 2 24.38.117.6 [AS 6128] 4 msec 8 msec 4 msec 3 167.206.183.29 [AS 6128] 4 msec 4 msec 8 msec 4 * * * 5 * * * 6 154.54.47.17 [AS 174] 4 msec 154.54.47.29 [AS 174] 8 msec 154.54.44.69 [AS 174] 4 msec 7 66.28.4.202 [AS 174] 28 msec 28 msec 154.54.6.190 [AS 174] 28 msec 8 154.54.6.85 [AS 174] 40 msec 154.54.24.81 [AS 174] 36 msec 154.54.6.117 [AS 174] 40 msec 9 154.54.26.113 [AS 174] 52 msec 154.54.26.121 [AS 174] 52 msec 154.54.26.129 [AS 174] 48 msec 10 154.54.25.70 [AS 174] 64 msec 154.54.25.66 [AS 174] 60 msec 154.54.25.70 [AS 174] 60 msec 11 154.54.2.197 [AS 174] 92 msec 88 msec 84 msec 12 154.54.0.249 [AS 174] 80 msec 154.54.0.253 [AS 174] 80 msec 154.54.0.249 [AS 174] 84 msec 13 154.54.41.142 [AS 174] 152 msec 224 msec 92 msec 14 38.122.90.42 [AS 174] 84 msec 84 msec 38.104.124.82 [AS 174] 80 msec 15 63.251.160.18 [AS 14744] 76 msec 76 msec 72 msec 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * ---- Matthew Huff             | 1 Manhattanville Rd Director of Operations   | Purchase, NY 10577 OTA Management LLC       | Phone: 914-460-4039 From rwebb at ropeguru.com Tue May 27 18:44:01 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Tue, 27 May 2014 14:44:01 -0400 Subject: crave your indulgence In-Reply-To: <110B4198-E9C2-490D-AF82-01C8AF4CEF31@isi.edu> References: <110B4198-E9C2-490D-AF82-01C8AF4CEF31@isi.edu> Message-ID: Looks good from here: Tracing route to 2001:500:84::b over a maximum of 30 hops 1 <1 ms <1 ms <1 ms 2601:8:1400:880::1 2 * * * Request timed out. 3 10 ms 9 ms 8 ms te-9-3-ur01.shadygrove.va.richmond.comcast.net [2001:558:182:fb::1] 4 9 ms 9 ms 7 ms xe-12-0-1-0-ar02.staplesmllrd.va.richmond.comcast.net [2001:558:180:25::1] 5 24 ms 24 ms 26 ms pos-3-10-0-0-cr01.56marietta.ga.ibone.comcast.net [2001:558:0:f6e6::1] 6 * * * Request timed out. 7 23 ms 24 ms 23 ms 2001:559::1056 8 23 ms 23 ms 24 ms ae-6.r03.atlnga05.us.bb.gin.ntt.net [2001:418:0:2000::31] 9 42 ms 76 ms 90 ms ae-7.r21.dllstx09.us.bb.gin.ntt.net [2001:418:0:2000::37d] 10 43 ms 41 ms 41 ms ae-0.r20.dllstx09.us.bb.gin.ntt.net [2001:418:0:2000::a9] 11 71 ms 73 ms 90 ms ae-5.r20.lsanca03.us.bb.gin.ntt.net [2001:418:0:2000::295] 12 71 ms 72 ms 74 ms ae-1.r05.lsanca03.us.bb.gin.ntt.net [2001:418:0:2000::116] 13 73 ms 72 ms 74 ms 2001:418:1401:1a::2 14 72 ms 75 ms 72 ms 2001:1878::181:177 15 74 ms 71 ms 71 ms 2001:500:84::b On Tue, 27 May 2014 11:28:00 -0700 manning bill wrote: > If you wouldn’t mind a quick tracerooute - Can you confirm >reachability to the following: > > 2001:500:84::b > > Thanks in advance. > > /bill > Neca eos omnes. Deus suos agnoscet. > From robert at ripe.net Tue May 27 18:45:01 2014 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 27 May 2014 20:45:01 +0200 Subject: crave your indulgence In-Reply-To: <110B4198-E9C2-490D-AF82-01C8AF4CEF31@isi.edu> References: <110B4198-E9C2-490D-AF82-01C8AF4CEF31@isi.edu> Message-ID: <5384DD2D.1040305@ripe.net> On 2014.05.27. 20:28, manning bill wrote: > If you wouldn’t mind a quick tracerooute - Can you confirm reachability to the following: > > 2001:500:84::b > > Thanks in advance. > > /bill > Neca eos omnes. Deus suos agnoscet. There should be a tool for this kind of thing! :-) https://atlas.ripe.net/atlas/udm.html?msm_id=1666831 or just the data (~1MB): https://atlas.ripe.net/api/v1/measurement/1666831/result/ Cheers, Robert From morrowc.lists at gmail.com Tue May 27 18:47:35 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 27 May 2014 14:47:35 -0400 Subject: crave your indulgence In-Reply-To: <5384DADE.6010004@gameservers.com> References: <110B4198-E9C2-490D-AF82-01C8AF4CEF31@isi.edu> <5384DADE.6010004@gameservers.com> Message-ID: Measurement: 1666834 should be bill's measurement request... 50 icmptraceroutes from around the globez. On Tue, May 27, 2014 at 2:35 PM, Brian Rak wrote: > This seems like a perfect use for ATLAS: https://atlas.ripe.net/ > > > On 5/27/2014 2:28 PM, manning bill wrote: >> >> If you wouldn’t mind a quick tracerooute - Can you confirm reachability >> to the following: >> >> 2001:500:84::b >> >> Thanks in advance. >> >> /bill >> Neca eos omnes. Deus suos agnoscet. >> > From owen at delong.com Tue May 27 19:07:34 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 27 May 2014 12:07:34 -0700 Subject: crave your indulgence In-Reply-To: References: <110B4198-E9C2-490D-AF82-01C8AF4CEF31@isi.edu> Message-ID: <4DF6A63F-C5DC-4C2E-9F0B-52E0FF9B4672@delong.com> traceroute6 to 2001:500:84::b (2001:500:84::b) from 2620::930:0:28e6:7b60:e856:aad7, 64 hops max, 12 byte packets 1 2620:0:930::cafe:beef 82.620 ms 0.772 ms 1.622 ms 2 2620::930:0:2e6b:f5ff:fe03:a80 1.965 ms 3.523 ms 2.613 ms 3 owen-2.tunnel.tserv2.fmt.ipv6.he.net 16.909 ms 18.061 ms 17.007 ms 4 ge5-10.core1.fmt1.he.net 17.122 ms 22.394 ms 15.948 ms 5 10ge3-4.core3.fmt2.he.net 18.848 ms 16.894 ms 19.103 ms 6 10ge12-1.core1.lax1.he.net 26.129 ms 27.115 ms 25.247 ms 7 10ge1-3.core1.lax2.he.net 24.409 ms 24.877 ms 25.065 ms 8 * 2001:504:13::210:43 28.831 ms 28.393 ms 9 2001:1878::181:177 31.308 ms 29.668 ms 25.611 ms 10 2001:500:84::b 24.900 ms 220.098 ms 188.378 ms From mark.tinka at seacom.mu Tue May 27 19:18:24 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 27 May 2014 21:18:24 +0200 Subject: crave your indulgence In-Reply-To: <110B4198-E9C2-490D-AF82-01C8AF4CEF31@isi.edu> References: <110B4198-E9C2-490D-AF82-01C8AF4CEF31@isi.edu> Message-ID: <201405272118.24850.mark.tinka@seacom.mu> On Tuesday, May 27, 2014 08:28:00 PM manning bill wrote: > If you wouldn’t mind a quick tracerooute - Can you > confirm reachability to the following: > > 2001:500:84::b From Mombasa, Kenya (you're welcome to use http://lg.seacomnet.com/): lg-01-mba.ke>traceroute 2001:500:84::b Type escape sequence to abort. Tracing the route to 2001:500:84::B 1 ge-1-0-0-213.mba6-201-access-3.mpls.seacomnet.com (2C0F:FEB0:5:FFFF::1) [AS 37100] 0 msec 0 msec 0 msec 2 xe-3-0-0.lon6-201-access-3.mpls.seacomnet.com (2C0F:FEB0:0:20::1) [AS 37100] 452 msec 268 msec 632 msec 3 xe-0-0-0-0.pp6-01-lhr.uk.seacomnet.com (2C0F:FEB0:0:23::6) [AS 37100] 132 msec 132 msec 128 msec 4 40ge1-3.core1.lon2.he.net (2001:7F8:4::1B1B:1) [AS 5459] 220 msec 216 msec 192 msec 5 100ge1-1.core1.nyc4.he.net (2001:470:0:2CF::2) [AS 6939] 224 msec 232 msec 228 msec 6 10ge10-3.core1.lax1.he.net (2001:470:0:10E::1) [AS 6939] 292 msec 268 msec 272 msec 7 10ge1-3.core1.lax2.he.net (2001:470:0:72::2) [AS 6939] 260 msec 268 msec 272 msec 8 * usclos-nettos.gigabitethernet4-11.core1.lax2.he.net (2001:470:1:3E8::2) 256 msec * 9 2001:1878::181:177 [AS 226] 288 msec 284 msec 296 msec 10 2001:500:84::B [AS 226] 292 msec 264 msec 276 msec lg-01-mba.ke> Cheers, 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 hank at efes.iucc.ac.il Tue May 27 18:59:31 2014 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 27 May 2014 21:59:31 +0300 Subject: crave your indulgence In-Reply-To: References: <5384DADE.6010004@gameservers.com> <110B4198-E9C2-490D-AF82-01C8AF4CEF31@isi.edu> <5384DADE.6010004@gameservers.com> Message-ID: <5.1.1.6.2.20140527215859.0525aa28@efes.iucc.ac.il> At 14:47 27/05/2014 -0400, Christopher Morrow wrote: >Measurement: 1666834 should be bill's measurement request... 50 >icmptraceroutes from around the globez. Or ring-ping and ring-trace: https://ring.nlnog.net/toolbox/ -Hank >On Tue, May 27, 2014 at 2:35 PM, Brian Rak wrote: > > This seems like a perfect use for ATLAS: https://atlas.ripe.net/ > > > > > > On 5/27/2014 2:28 PM, manning bill wrote: > >> > >> If you wouldn't mind a quick tracerooute - Can you confirm reachability > >> to the following: > >> > >> 2001:500:84::b > >> > >> Thanks in advance. > >> > >> /bill > >> Neca eos omnes. Deus suos agnoscet. > >> > > From cb.list6 at gmail.com Tue May 27 19:28:30 2014 From: cb.list6 at gmail.com (Ca By) Date: Tue, 27 May 2014 12:28:30 -0700 Subject: RIPE Atlas data parsing Message-ID: Folks, Yes, RIPE Atlas is great. It generates output as JSON. Is there dummy tool for summarizing this JSON data and possibly visualizing it? I could write my own, but i imagine someone has already done this somewhere. No? CB From robert at ripe.net Tue May 27 19:36:10 2014 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 27 May 2014 21:36:10 +0200 Subject: RIPE Atlas data parsing In-Reply-To: References: Message-ID: <5384E92A.1040703@ripe.net> On 2014.05.27. 21:28, Ca By wrote: > Folks, > > Yes, RIPE Atlas is great. It generates output as JSON. > > Is there dummy tool for summarizing this JSON data and possibly > visualizing it? I could write my own, but i imagine someone has > already done this somewhere. No? > > CB > These may help: https://github.com/RIPE-NCC/ripe.atlas.sagan From bortzmeyer at nic.fr Tue May 27 19:41:27 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 27 May 2014 21:41:27 +0200 Subject: RIPE Atlas data parsing In-Reply-To: References: Message-ID: <20140527194127.GA3236@nic.fr> On Tue, May 27, 2014 at 12:28:30PM -0700, Ca By wrote a message of 9 lines which said: > Is there dummy tool for summarizing this JSON data and possibly > visualizing it? On Atlas Web site, there is the Seismograph (an interactive tool). I don't use it myself. There are many sample programs on: https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib See for instance reachability+retrieve.py There is now a new library to help parsing, called Sagan: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-latest-results-api-and-parsing-library (I used it only a little) You may also look at the tutorial: https://ripe67.ripe.net/presentations/153-ripe-atlas-udm-api-1.pdf From geraint at koding.com Tue May 27 19:52:55 2014 From: geraint at koding.com (Geraint Jones) Date: Tue, 27 May 2014 12:52:55 -0700 Subject: crave your indulgence In-Reply-To: <5.1.1.6.2.20140527215859.0525aa28@efes.iucc.ac.il> References: <110B4198-E9C2-490D-AF82-01C8AF4CEF31@isi.edu> <5384DADE.6010004@gameservers.com> <5.1.1.6.2.20140527215859.0525aa28@efes.iucc.ac.il> Message-ID: # ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS 1 2001:504:13::1a 0% 6 8.4ms 12.2 8.4 19.9 5.3 2 2001:470:1:3e8::2 0% 6 9.2ms 9.2 9.1 9.4 0.1 3 2001:1878::181:177 0% 6 8.8ms 9 8.8 10 0.4 4 2001:500:84::b 0% 6 9ms 8.7 8.6 9 0.1 On Tue, May 27, 2014 at 11:59 AM, Hank Nussbacher wrote: > At 14:47 27/05/2014 -0400, Christopher Morrow wrote: > > Measurement: 1666834 should be bill's measurement request... 50 >> icmptraceroutes from around the globez. >> > > Or ring-ping and ring-trace: > https://ring.nlnog.net/toolbox/ > > -Hank > > > On Tue, May 27, 2014 at 2:35 PM, Brian Rak wrote: >> > This seems like a perfect use for ATLAS: https://atlas.ripe.net/ >> > >> > >> > On 5/27/2014 2:28 PM, manning bill wrote: >> >> >> >> If you wouldn't mind a quick tracerooute - Can you confirm >> reachability >> >> to the following: >> >> >> >> 2001:500:84::b >> >> >> >> Thanks in advance. >> >> >> >> /bill >> >> Neca eos omnes. Deus suos agnoscet. >> >> >> > >> > > From md1clv at md1clv.com Tue May 27 20:00:50 2014 From: md1clv at md1clv.com (Daniel Ankers) Date: Tue, 27 May 2014 21:00:50 +0100 Subject: RIPE Atlas data parsing In-Reply-To: <20140527194127.GA3236@nic.fr> References: <20140527194127.GA3236@nic.fr> Message-ID: I'm using Graphite (http://graphite.readthedocs.org) - I plan on blogging how I'm doing it at some point, but it's not all that difficult. Dan On 27 May 2014 20:41, Stephane Bortzmeyer wrote: > On Tue, May 27, 2014 at 12:28:30PM -0700, > Ca By wrote > a message of 9 lines which said: > > > Is there dummy tool for summarizing this JSON data and possibly > > visualizing it? > > On Atlas Web site, there is the Seismograph (an interactive tool). I > don't use it myself. > > There are many sample programs on: > > https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib > > See for instance reachability+retrieve.py > > There is now a new library to help parsing, called Sagan: > > > https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-latest-results-api-and-parsing-library > > (I used it only a little) > > You may also look at the tutorial: > > https://ripe67.ripe.net/presentations/153-ripe-atlas-udm-api-1.pdf > > From jw at nuclearfallout.net Tue May 27 20:59:22 2014 From: jw at nuclearfallout.net (John Weekes) Date: Tue, 27 May 2014 13:59:22 -0700 Subject: Cogent / Internap issue ?? In-Reply-To: <4baaf84129e54ee38a5aaac92772186f@pur-vm-exch13n1.ox.com> References: <4baaf84129e54ee38a5aaac92772186f@pur-vm-exch13n1.ox.com> Message-ID: <5384FCAA.4050800@nuclearfallout.net> On 5/27/2014 11:24 AM, Matthew Huff wrote: > We are having troubles reaching services on the other side of cogent/internap peering. Anyone else seeing issues? We haven't seen Cogent-related issues at SEF today and that IP address is currently pingable through the Cogent looking glass. From your trace, Internap's equipment is reachable and responding (the two last hops are Internap-controlled), so the actual endpoint network (beyond Internap) seems to be either explicitly filtering your source or sending traffic back to it over a different and broken path. The Internap NOC is responsive when it comes to investigating routing problems, so they're a good place to turn for such concerns. If you're having problems reaching them or would like some external help in exploring the problem from inside and outside that PNAP, shoot me an email off-list. -John From groups at digital-z.com Tue May 27 23:21:10 2014 From: groups at digital-z.com (Blaine Fleming) Date: Tue, 27 May 2014 18:21:10 -0500 Subject: rz.verisign-grs.com root zone ftp access In-Reply-To: <20140521045346.13997.qmail@joyce.lan> References: <20140521045346.13997.qmail@joyce.lan> Message-ID: <53851DE6.9020808@digital-z.com> On 5/20/14, 11:53 PM, John Levine wrote: > In article <537C1F17.6070307 at digital-z.com> you write: >> On 5/20/14, 4:21 PM, Brandon Applegate wrote: >>> Is anyone using this and having failed login for a few days now ? I�ve been mirroring the root >> zone(s) for years and I just started getting failures in my logs. I emailed an address I found on >> the Verisign website but so far dead air. If anyone knows of a more pointed email POC that would >> actually have clue about this that would be awesome. >> >> I have been experiencing this problem as well but have not had a chance >> to look into it. It stopped working some time between May 15th and May >> 16th. If you find out anything, please let me know! > > When I had problems like this a while ago, I found their support > people to be quite responsive. Try writing them at > tldzone at verisign-grs.com or call the support number on the web site > 703-925-6999. > > If you're not using your password to download the .COM or .NET zones, > it is my impression that they will eventually turn off your password > because they think you're not using it. > > R's, > John > Just wanted to follow-up on this issue. I was actively using it every day to fetch the .COM and .NET TLD zone files. Sent multiple emails to tldzone at verisign-grs.com with no response. Finally reached out to them via chat and was informed that I needed to execute a new zone file access agreement because they needed updated information for me. New agreement has been submitted so we will see what they say this time. If anyone else is still having problems then you probably need to do the same. --Blaine From hannigan at gmail.com Wed May 28 00:21:53 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 27 May 2014 20:21:53 -0400 Subject: rz.verisign-grs.com root zone ftp access In-Reply-To: <537C3EB0.8000600@dougbarton.us> References: <904CE971-B779-4C9E-AF8D-8DAFCCE01E67@burn.net> <537C3A86.50205@dougbarton.us> <537C3EB0.8000600@dougbarton.us> Message-ID: Hi Doug, IIRC you can ftp to rs.internic.net (the IANA) and download zones to your hearts content. At least until "transition", I'd think this one is authoritative. I don't exactly remember where you can pull it from, but I believe they offer it in XML too. [ Paging Joe Abley ] Best, -M< On Wed, May 21, 2014 at 1:50 AM, Doug Barton wrote: > The last time I asked them, F-root had a "we allow it because it's the > right thing to do but we don't like it" policy. Given that ICANN operates > an infrastructure purposely built for doing zone transfers, and given that > they offer more zones than are on the roots, that's the way I recommend > people go. YMMV. > > Doug > > > > On 05/20/2014 10:42 PM, Mehmet Akcin wrote: > >> F-root also allows you to axfr root-zone ( dig @f.root-servers.net . >> axfr ) >> >> >> On May 20, 2014, at 10:32 PM, Doug Barton wrote: >> >> Signed PGP part >>> On 05/20/2014 02:21 PM, Brandon Applegate wrote: >>> | Is anyone using this and having failed login for a few days now ? >>> I?ve been mirroring the root zone(s) for years and I just started >>> getting failures in my logs. I emailed an address I found on the >>> Verisign website but so far dead air. If anyone knows of a more pointed >>> email POC that would actually have clue about this that would be awesome. >>> >>> You can slave the root and more directly from ICANN: >>> >>> http://www.dns.icann.org/services/axfr/ >>> >>> >>> >> > From j at arpa.com Wed May 28 01:48:19 2014 From: j at arpa.com (jamie rishaw) Date: Tue, 27 May 2014 20:48:19 -0500 Subject: rz.verisign-grs.com root zone ftp access In-Reply-To: <53851DE6.9020808@digital-z.com> References: <20140521045346.13997.qmail@joyce.lan> <53851DE6.9020808@digital-z.com> Message-ID: Pretty annoying (esp. to my databases) that com.zone.gz alone is >2.3 GB ... >.< On Tue, May 27, 2014 at 6:21 PM, Blaine Fleming wrote: > On 5/20/14, 11:53 PM, John Levine wrote: >> In article <537C1F17.6070307 at digital-z.com> you write: >>> On 5/20/14, 4:21 PM, Brandon Applegate wrote: >>>> Is anyone using this and having failed login for a few days now ? I�ve been mirroring the root >>> zone(s) for years and I just started getting failures in my logs. I emailed an address I found on >>> the Verisign website but so far dead air. If anyone knows of a more pointed email POC that would >>> actually have clue about this that would be awesome. >>> >>> I have been experiencing this problem as well but have not had a chance >>> to look into it. It stopped working some time between May 15th and May >>> 16th. If you find out anything, please let me know! >> >> When I had problems like this a while ago, I found their support >> people to be quite responsive. Try writing them at >> tldzone at verisign-grs.com or call the support number on the web site >> 703-925-6999. >> >> If you're not using your password to download the .COM or .NET zones, >> it is my impression that they will eventually turn off your password >> because they think you're not using it. >> >> R's, >> John >> > > Just wanted to follow-up on this issue. I was actively using it every > day to fetch the .COM and .NET TLD zone files. Sent multiple emails to > tldzone at verisign-grs.com with no response. Finally reached out to them > via chat and was informed that I needed to execute a new zone file > access agreement because they needed updated information for me. New > agreement has been submitted so we will see what they say this time. If > anyone else is still having problems then you probably need to do the same. > > --Blaine > -- jamie rishaw // .com.arpa at j <- reverse it. ish. "...let's consider this world like a family and care about each other..." -Malala Yousafzai From jaap at NLnetLabs.nl Wed May 28 04:50:21 2014 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 28 May 2014 06:50:21 +0200 Subject: [dns-wg] crave your indulgence In-Reply-To: <110B4198-E9C2-490D-AF82-01C8AF4CEF31@isi.edu> References: <110B4198-E9C2-490D-AF82-01C8AF4CEF31@isi.edu> Message-ID: <201405280450.s4S4oLa6099229@bela.nlnetlabs.nl> If you wouldn't mind a quick tracerooute - Can you confirm reachability to the following: 2001:500:84::b Thanks in advance. traceroute6 to 2001:500:84::b (2001:500:84::b) from 2a04:b900::1:0:0:15, 64 hops max, 12 byte packets 1 office.bijgepunt.nlnetlabs.nl 0.333 ms 0.314 ms 0.308 ms 2 2a02:d28:5580:e:1000::245 0.589 ms 0.611 ms 0.507 ms 3 eth1-1.core1.ams1.nl.as5580.net 0.554 ms 0.549 ms 0.536 ms 4 eth1-8.r1.ams2.nl.as5580.net 0.694 ms 13.099 ms 4.514 ms 5 30gigabitethernet1-3.core1.ams1.he.net 8.437 ms 1.450 ms 1.651 ms 6 100ge9-1.core1.lon2.he.net 17.578 ms 7.245 ms 17.896 ms 7 100ge1-1.core1.nyc4.he.net 86.636 ms 82.937 ms 103.756 ms 8 10ge10-3.core1.lax1.he.net 159.165 ms 164.547 ms 153.020 ms 9 10ge1-3.core1.lax2.he.net 158.396 ms 153.472 ms 152.610 ms 10 2001:504:13::210:43 153.222 ms 154.124 ms 153.499 ms 11 2001:1878::181:177 153.629 ms 153.891 ms 153.103 ms 12 2001:500:84::b 153.426 ms 153.167 ms 152.977 ms From daniel.karrenberg at ripe.net Wed May 28 08:02:19 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 28 May 2014 10:02:19 +0200 Subject: [dns-wg] crave your indulgence In-Reply-To: <53858865.60601@ripe.net> References: <110B4198-E9C2-490D-AF82-01C8AF4CEF31@isi.edu> <5384DD2D.1040305@ripe.net> <53858865.60601@ripe.net> Message-ID: <5385980B.90604@ripe.net> On 28.05.14 8:55 , Daniel Karrenberg wrote: > ... you discover that local connectivity is through HE and Los Nettos. .... Ouch! I just got hit by my own wrong default of excluding hops with no response. There is no direct link to HE evident from the traceroutes. I wish ICMP "TTL Exceeded" responses were more reliable ... Correct graph with * hops included. Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: bif-tr1-noresponse.png Type: image/png Size: 30744 bytes Desc: not available URL: From jabley at hopcount.ca Wed May 28 08:49:08 2014 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 28 May 2014 11:49:08 +0300 Subject: rz.verisign-grs.com root zone ftp access In-Reply-To: References: <904CE971-B779-4C9E-AF8D-8DAFCCE01E67@burn.net> <537C3A86.50205@dougbarton.us> <537C3EB0.8000600@dougbarton.us> Message-ID: On 28 May 2014, at 3:21, Martin Hannigan wrote: > IIRC you can ftp to rs.internic.net (the IANA) and download zones to your > hearts content. At least until "transition", I'd think this one is > authoritative. > > I don't exactly remember where you can pull it from, but I believe they > offer it in XML too. > > [ Paging Joe Abley ] *twitch* Half of this thread seems to be talking about the COM/NET zones, not the root zone, but since you asked... is a service provided by ICANN. is a service provided by Verisign. I think both services are provided under their respective agreements with NTIA (the IANA Functions Contract and the Cooperative Agreement) and hence those URLs can be expected to be somewhat stable. (We live in interesting times, but I don't sense a desire by anybody to change the IANA Functions as part of the management transition currently under discussion). I don't remember the details of how the two sites above are provisioned, but I have a feeling that one is mirrored from the other. Right now, from here, B-Root, C-Root, F-Root, G-Root, and K-Root respond positively to AXFR requests. Sending AXFR requests to instances of root servers is a bit unfriendly, in my opinion, since you're occupying TCP slots on nameservers that arguably would be better used for non-AXFR queries using TCP transport. As Mehmet mentioned, xfr.cjr.dns.icann.org and xfr.lax.dns.icann.org are both dedicated AXFR servers from which the root zone (and other zones served by ICANN's DNS Operations department) can be retrieved. I am not aware of any commitment or requirement to provide those services, but I can't imagine the good people currently in that ICANN department would make them unavailable gratuitously. Lastly, the root zone is signed with NSEC, which means you can walk the NSEC chain and recover the complete zone (see below, thanks Jelte). It occurs to me that this is actually a plausible way to prime your resolver with the full contents of the root zone, as an alternative to slaving the root zone, for people who think this kind of obsessive behaviour is useful. But maybe that's just the malarone talking. I am not aware of anybody providing the contents of the root zone in XML format (and I'm not sure what value that would have to anybody). You may have been remembering the root zone trust anchor distribution format, as seen at . Joe [walrus:~]% ldns-walk -f . | head -40 . 218447 IN NS i.root-servers.net. . 218447 IN NS h.root-servers.net. . 218447 IN NS m.root-servers.net. . 218447 IN NS l.root-servers.net. . 218447 IN NS j.root-servers.net. . 218447 IN NS e.root-servers.net. . 218447 IN NS d.root-servers.net. . 218447 IN NS b.root-servers.net. . 218447 IN NS f.root-servers.net. . 218447 IN NS k.root-servers.net. . 218447 IN NS g.root-servers.net. . 218447 IN NS c.root-servers.net. . 218447 IN NS a.root-servers.net. . 487056 IN RRSIG NS 8 0 518400 20140603000000 20140526230000 40926 . gsG1xrmc32HKMscG4pEQjgTNg2UOKgXTEZEGjg5lY9X14ADCwNleAwfNXkeAS2cEEJI+Sj8P4gWvKCpgCi7rKSMVPapfelN8huMZHiplWsl0JyaHxkU6WwAa2ciBIayGuY7vsPY2LGudosN4th+5eXnB0gfIJFCuQjhaK3dI5iM= . 86309 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2014052701 1800 900 604800 86400 . 86309 IN RRSIG SOA 8 0 86400 20140603000000 20140526230000 40926 . JZPdfvMZq/+k+ScgnPVp02j6PSYnA5ntR4TGiLHoeeLTWty7OY3ATas48mCxRZja8D/44VKV5COiXb3dNJNRnXtGqI1nuTWwGXmK/J52satKzLilkk/NtHjy1MxT1NQmgnPYFKNP4liE3vr0deTUYCPRkjDwveTCJ/NowB1OyWs= . 45819 IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ;{id = 19036 (ksk), size = 2048b} . 45819 IN DNSKEY 256 3 8 AwEAAZvJd8ORk+jmZ41QMYbQ1XCpf60l6YJuHtnxn0VSh5a5vqwEjTST3/PZ4xhUFu2YcTfRNWxs9WTiGZl3MY/UlBIvzpLhKgKnf9Vk8sEU3q0nmOGFgE6jTi/cU95ATU/2dTQovMDv9XyWvrmj8KIG2brj6mF4S8GTae6G2GwbMF5v ;{id = 40926 (zsk), size = 1024b} . 45819 IN RRSIG DNSKEY 8 0 172800 20140604235959 20140521000000 19036 . H6fUqoXYqDtYeDOZxBxBEXWsQ1APR6+MMboI74uSgdIkcm5B2zBQOwD+lYid1j3JJ1vhzONwk4PP31o1RG24P0iMqhwwaGXtoWLDeH3FSQxuVUdLA3DxIM0c8NdEzgCW36iH8zzcy/uzFwgPvw6/ksbd6Np+nu/bIw38XhGH61fkidahj1lTAUDIMXi4TM7igJ9bZgUtLViXN8sLeD4G+hrPZbydcksvZpVB8XFCvgKrHHMq3Ha7AO6cl2XDrn6/DodibcVBpMK07kL24NEVFre/jeqjiQWCms6GDuGkqRKaUf8Hdwl12rsmptIuDa70qNh3Pz+pbjNXXGuWlkyYdA== . 10709 IN NSEC ac. NS SOA RRSIG NSEC DNSKEY . 10709 IN RRSIG NSEC 8 0 86400 20140603000000 20140526230000 40926 . DfkP4WFtbeus1jPx7viKJ9GAPlRvgJfgJzvRTA8zoAbteZyOD3zDOs64YcBoDt/0kQxpfa5RYKbEHTzquV8FiPyAZ91a5Syh0ml5tOoWIgxArLKAYpdW5sTKSOwYsrvZ3zb8Bwt9DTjrv7z7fPy8byVKyAJcN1vGB7odFOagHro= ac. 172708 IN NS b.nic.ac. ac. 172708 IN NS b.ns13.net. ac. 172708 IN NS a.ns13.net. ac. 172708 IN NS ns1.communitydns.net. ac. 172708 IN NS a.nic.ac. ac. 172708 IN NS b.nic.io. ac. 172708 IN NS ns3.icb.co.uk. ac. 86400 IN RRSIG NS 8 1 86400 20140630163458 20140526153043 15896 ac. VZHivI5edUvEwYka2WNX7/A0ud5u+vGObZ54Aw/RpJuCMv3Q4VrLP3HFVmQCWdALxldamnYnUPiLnnhjWL/xaYrKHbvmIViws5nsDLMWy5jHzLxCBUtm4BudRq7sLcWNKwZi08eP9Gq2G4/aOhnGmhjQs6its+slrAhbXDc/n7I= ac. 8622 IN DS 23014 8 2 9f135b4b4c69c92383b997632e821e3c8ab9699658674cc96fde5405acb68b65 ac. 8622 IN RRSIG DS 8 1 86400 20140603000000 20140526230000 40926 . EsZz1A8kWMAzsg9+mrsLfdH78qOFd4HTKErJT7LuL20uOId6SvWT7br8hyK6XP7w3USSXsH4miYhH+oh8spxEH11KMgTOT0Lm2LE7W16asO0cHfN4SantZ8aeubDlDWbYj+DioqUuDUgqbMqeOxV3E42ROo0mINDOo+QxWj7GuU= ac. 10709 IN NSEC academy. NS DS RRSIG NSEC ac. 10709 IN RRSIG NSEC 8 1 86400 20140603000000 20140526230000 40926 . TtCsZLK3YtFXiRHi4ZGKreWbrf1+97tA973i64k7RTT2GujHPv3MhpDP+IWlqcwvH1XcX5CBkleDbIBVGzxgenzewl31wF+ufw9DCbPlbli38y2S7Z5QK50Q+Sa3cJvFm0CagkM5s0owZxyZKdAdZbohWAy74ohb5gf+rjWOrR8= academy. 172709 IN NS demand.beta.aridns.net.au. academy. 172709 IN NS demand.alpha.aridns.net.au. academy. 172709 IN NS demand.gamma.aridns.net.au. academy. 172709 IN NS demand.delta.aridns.net.au. academy. 86400 IN RRSIG NS 8 1 86400 20140609042557 20140510040258 9414 academy. dBGJK1r2Ay31FYTLFEfjXTdgQTQVOWlSsKWHu9hoC7fOwySFOhRtBh/Me/dpuHz2TqtCQ4pKBpu+CsAbWWrdrJz727CCRdmmhfClI+c70eO7oNoE5/zwchLOqmyLERaoInYi2Ra3PQYQpZc23PYy15jr8hblvKOx7cSW/RR4fZIaZFbVB3rGJtiDxSoTpCTA4evlUvcLVTIGfD4MJBLbXg== academy. 86309 IN DS 47032 8 2 e2a2dae3cc55e8ce27e9aea6217bda4a835bf2270c40749ad278e9a9b4aba132 academy. 86309 IN RRSIG DS 8 1 86400 20140603000000 20140526230000 40926 . AwaaZrLUSAiSaKw0NMkXRtvsUjH0rajpHGHwTaZ4ROf+4DYD3vpXqYIT7DQ6s/LMmZSPEhjzpH7OS8/gpomZZVyadfjQQ3/aLDej3vwImI5ZYHNr8Y6dJyFZ81ihyk+Xxu7l3cmt5mPlGIAQ87CYh8bz7tF6raor8hkqk0bNNls= [walrus:~]% From jra at baylink.com Wed May 28 14:00:59 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 28 May 2014 10:00:59 -0400 (EDT) Subject: CMTS/Public Wifi provisioning question Message-ID: <18008962.2628.1401285659813.JavaMail.root@benjamin.baylink.com> I expect Frank Bulk to have an opinion on this, all others welcome. Hat tip to Bright House -- I've noticed lately that I don't have to go through their captive portal when using their public wifi hotspots (they participate in the CableWifi consortium, using WAPs built into their 6580 and other cablemodems, and offer a carrier-specific connection SSID as well). This has led me to a point of curiosity: If I'm the subscriber, and I've paid for 15 mb/s down, then my wired connection and my private wireless (if provisioned, and they charge $10/mo, so I'll do that myself, thanks) are using one ... DOCSIS path? back to the CMTS. I assume that cableco provided voice is on a separate path, and I'm sure the TV service is -- if it's even IP at all. But the question is: is that public wifi service *also* on a separate bandwidth-limited channel out of the cablemodem? Offline replies fine, unless you think it's of sufficiently general interest; I expect it's implementation dependent. 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 bmanning at isi.edu Wed May 28 14:35:48 2014 From: bmanning at isi.edu (manning bill) Date: Wed, 28 May 2014 07:35:48 -0700 Subject: indulgence satiated Message-ID: Thanks All for taking the time to prod 2001:500:84::b Looks like it is reachable from many places… enough that we will proceed to augment the “B” root server with perhaps the last in a long line of IPv6 addresses that it has had over the last 15 years. Splay will increase over time. /bill /bill Neca eos omnes. Deus suos agnoscet. From ryan at u13.net Wed May 28 22:29:35 2014 From: ryan at u13.net (Ryan Rawdon) Date: Wed, 28 May 2014 17:29:35 -0500 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> Message-ID: On May 22, 2014, at 9:18 PM, Matthew Petach wrote: > On Thu, May 22, 2014 at 8:49 AM, Lee Howard wrote: > >> >> >> On 5/22/14 8:04 AM, "Livingood, Jason" >> wrote: >> [snip] >> In his really useful listing of content providers' IPv6 support, >> https://www.vyncke.org/ipv6status/ Eric Vyncke has added "CDN" to sites >> using an identifiable CDN. >> > > I suspect there's a problem with > the data collection on that site; > looking at > https://www.vyncke.org/ipv6status/detailed.php?country=us > I really don't think the top 5 players > don't support IPv6 DNS queries at all. > I'd be curious to know more about how the > data there is collected; I don't see any links > to any description of the data collection > methodology on the site. > > Matt The data is correct — The top 5 players on that page do not have AAAA records published for their authoritative name servers (despot all being v6-capable for most or all of their content): ryan at lion:~$ echo google.com facebook.com youtube.com yahoo.com wikipedia.org | xargs -n1 dig +short -t NS | xargs -n1 dig +short -t AAAA ryan at lion:~$ (no results for the authoritative servers of all 5 domains) ryan at lion:~$ echo google.com facebook.com youtube.com yahoo.com wikipedia.org | xargs -n1 dig +short -t NS | xargs -n1 dig +short -t A 216.239.34.10 216.239.32.10 216.239.38.10 216.239.36.10 69.171.239.12 69.171.255.12 216.239.38.10 216.239.34.10 216.239.36.10 216.239.32.10 68.180.131.16 119.160.247.124 203.84.221.53 68.142.255.16 121.101.144.139 98.138.11.157 91.198.174.239 208.80.152.214 208.80.154.238 ryan at lion:~$ (19 A record total results for the 5 domains in question) The same query done together with host(1), excluding various MX responses, which would show v6 answers alongside the v4: ryan at lion:~$ echo google.com facebook.com youtube.com yahoo.com wikipedia.org | xargs -n1 dig +short -t NS | xargs -n1 host | grep -v mail ns1.google.com has address 216.239.32.10 ns2.google.com has address 216.239.34.10 ns4.google.com has address 216.239.38.10 ns3.google.com has address 216.239.36.10 b.ns.facebook.com has address 69.171.255.12 a.ns.facebook.com has address 69.171.239.12 ns4.google.com has address 216.239.38.10 ns2.google.com has address 216.239.34.10 ns1.google.com has address 216.239.32.10 ns3.google.com has address 216.239.36.10 ns5.yahoo.com has address 119.160.247.124 ns2.yahoo.com has address 68.142.255.16 ns3.yahoo.com has address 203.84.221.53 ns1.yahoo.com has address 68.180.131.16 ns4.yahoo.com has address 98.138.11.157 ns6.yahoo.com has address 121.101.144.139 ns0.wikimedia.org has address 208.80.154.238 ns1.wikimedia.org has address 208.80.152.214 ns2.wikimedia.org has address 91.198.174.239 ryan at lion:~$ From bverd at verisign.com Thu May 29 02:17:46 2014 From: bverd at verisign.com (Verd, Brad) Date: Thu, 29 May 2014 02:17:46 +0000 Subject: rz.verisign-grs.com root zone ftp access In-Reply-To: <904CE971-B779-4C9E-AF8D-8DAFCCE01E67@burn.net> References: <904CE971-B779-4C9E-AF8D-8DAFCCE01E67@burn.net> Message-ID: <2C141BC9-8761-4074-B78C-E9DB1C9A0B70@verisign.com> All, Verisign performed routine account maintenance on the Verisign TLD Zone File Access Program (TLDZ) platform. This service gives participants FTP access to the TLD Zone Files for the .com, .net and .name top-level domains (TLDs). Each file contains the active domain names in that particular TLD and is updated daily. Any user without a current contract in place was removed. All reasonable efforts were taken to notify users prior to their access being revoked. If a customer has lost their access to rz.verisign-grs.com (TLDZ), they should call into Verisign Customer Service @+1-703-925-6999 and they will be instructed on how to submit the contract request. Once the request is processed a new user ID for the customer will be added to the platform. Additional information regarding TLDZ can be view at http://www.verisigninc.com/en_US/channel-resources/domain-registry-products/zone-file-information/index.xhtml Regards, Brad G. Bradford Verd Vice President Operations bverd at verisign.com 12061 Bluemont Way Reston, VA 20190 VerisignInc.com [cid:image003.gif at 01CE05D2.5D1F5A90] On May 20, 2014, at 5:21 PM, Brandon Applegate > wrote: Is anyone using this and having failed login for a few days now ? I’ve been mirroring the root zone(s) for years and I just started getting failures in my logs. I emailed an address I found on the Verisign website but so far dead air. If anyone knows of a more pointed email POC that would actually have clue about this that would be awesome. -- 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." -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.gif Type: image/gif Size: 3105 bytes Desc: image003.gif URL: From mpetach at netflight.com Thu May 29 03:37:07 2014 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 28 May 2014 20:37:07 -0700 Subject: IPv6 at 50% for VZW (Re: NAT IP and Google) In-Reply-To: References: <537B64F7.5020504@edylie.net> <459F5544-07F6-46CF-96AE-C501578FCE97@delong.com> <005701cf753a$97d6e670$c784b350$@wicks.co.nz> <110703.1400713302@turing-police.cc.vt.edu> Message-ID: On Wed, May 28, 2014 at 3:29 PM, Ryan Rawdon wrote: > On May 22, 2014, at 9:18 PM, Matthew Petach wrote: > > On Thu, May 22, 2014 at 8:49 AM, Lee Howard wrote: > > > > On 5/22/14 8:04 AM, "Livingood, Jason" > wrote: > [snip] > > In his really useful listing of content providers' IPv6 support, > https://www.vyncke.org/ipv6status/ Eric Vyncke has added "CDN" to sites > using an identifiable CDN. > > > I suspect there's a problem with > the data collection on that site; > looking at > https://www.vyncke.org/ipv6status/detailed.php?country=us > I really don't think the top 5 players > don't support IPv6 DNS queries at all. > I'd be curious to know more about how the > data there is collected; I don't see any links > to any description of the data collection > methodology on the site. > > Matt > > > > The data is correct — The top 5 players on that page do not have AAAA > records published for their authoritative name servers (despot all being > v6-capable for most or all of their content): > > > ryan at lion:~$ echo google.com facebook.com youtube.com yahoo.com > wikipedia.org | xargs -n1 dig +short -t NS | xargs -n1 dig +short -t AAAA > ryan at lion:~$ > > (no results for the authoritative servers of all 5 domains) > > ryan at lion:~$ echo google.com facebook.com youtube.com yahoo.com > wikipedia.org | xargs -n1 dig +short -t NS | xargs -n1 dig +short -t A > 216.239.34.10 > 216.239.32.10 > 216.239.38.10 > 216.239.36.10 > 69.171.239.12 > 69.171.255.12 > 216.239.38.10 > 216.239.34.10 > 216.239.36.10 > 216.239.32.10 > 68.180.131.16 > 119.160.247.124 > 203.84.221.53 > 68.142.255.16 > 121.101.144.139 > 98.138.11.157 > 91.198.174.239 > 208.80.152.214 > 208.80.154.238 > ryan at lion:~$ > > (19 A record total results for the 5 domains in question) > > > The same query done together with host(1), excluding various MX responses, > which would show v6 answers alongside the v4: > ryan at lion:~$ echo google.com facebook.com youtube.com yahoo.com > wikipedia.org | xargs -n1 dig +short -t NS | xargs -n1 host | grep -v mail > ns1.google.com has address 216.239.32.10 > ns2.google.com has address 216.239.34.10 > ns4.google.com has address 216.239.38.10 > ns3.google.com has address 216.239.36.10 > b.ns.facebook.com has address 69.171.255.12 > a.ns.facebook.com has address 69.171.239.12 > ns4.google.com has address 216.239.38.10 > ns2.google.com has address 216.239.34.10 > ns1.google.com has address 216.239.32.10 > ns3.google.com has address 216.239.36.10 > ns5.yahoo.com has address 119.160.247.124 > ns2.yahoo.com has address 68.142.255.16 > ns3.yahoo.com has address 203.84.221.53 > ns1.yahoo.com has address 68.180.131.16 > ns4.yahoo.com has address 98.138.11.157 > ns6.yahoo.com has address 121.101.144.139 > ns0.wikimedia.org has address 208.80.154.238 > ns1.wikimedia.org has address 208.80.152.214 > ns2.wikimedia.org has address 91.198.174.239 > ryan at lion:~$ > > Aha! Thank you for the clarification, Ryan; the page is somewhat confusing, as it seemed like it was saying there was no quad-A support from the DNS servers; but what it's actually saying is that the DNS servers support IPv6 queries, but only over IPv4 transport. Thank you for explaining the methodology behind the report. It would definitely be useful for the site to have a link explaining the nature of the tests being done, to avoid similar confusion on the part of others who see it. Thanks! Matt From andy at newslink.com Thu May 29 04:37:25 2014 From: andy at newslink.com (Andy Ringsmuth) Date: Wed, 28 May 2014 23:37:25 -0500 Subject: Roadrunner/TimeWarner contact Message-ID: <72D777B9-BDC3-4CE5-8EDB-C7E702D0EEFC@newslink.com> Any chance there's someone from Roadrunner out there who could contact me off-list? Been dealing with some erratic POP/SMTP/IMAP authentication problems that I've had zero luck remedying through normal channels. Much appreciated. ---- Andy Ringsmuth andy at newslink.com News Link – Manager Technology & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From frnkblk at iname.com Thu May 29 05:19:13 2014 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 29 May 2014 00:19:13 -0500 Subject: CMTS/Public Wifi provisioning question In-Reply-To: <18008962.2628.1401285659813.JavaMail.root@benjamin.baylink.com> References: <18008962.2628.1401285659813.JavaMail.root@benjamin.baylink.com> Message-ID: <001401cf7afd$879e3240$96da96c0$@iname.com> It's my understanding that the public Wi-Fi uses the same data flow as the subcriber's data flow. I've seen nothing in the release notes for ARRIS or Moto that suggest one can tie an SSID to a specific service flow. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay Ashworth Sent: Wednesday, May 28, 2014 9:01 AM To: NANOG Subject: CMTS/Public Wifi provisioning question I expect Frank Bulk to have an opinion on this, all others welcome. Hat tip to Bright House -- I've noticed lately that I don't have to go through their captive portal when using their public wifi hotspots (they participate in the CableWifi consortium, using WAPs built into their 6580 and other cablemodems, and offer a carrier-specific connection SSID as well). This has led me to a point of curiosity: If I'm the subscriber, and I've paid for 15 mb/s down, then my wired connection and my private wireless (if provisioned, and they charge $10/mo, so I'll do that myself, thanks) are using one ... DOCSIS path? back to the CMTS. I assume that cableco provided voice is on a separate path, and I'm sure the TV service is -- if it's even IP at all. But the question is: is that public wifi service *also* on a separate bandwidth-limited channel out of the cablemodem? Offline replies fine, unless you think it's of sufficiently general interest; I expect it's implementation dependent. 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 khelms at zcorum.com Thu May 29 12:58:08 2014 From: khelms at zcorum.com (Scott Helms) Date: Thu, 29 May 2014 08:58:08 -0400 Subject: CMTS/Public Wifi provisioning question In-Reply-To: <001401cf7afd$879e3240$96da96c0$@iname.com> References: <18008962.2628.1401285659813.JavaMail.root@benjamin.baylink.com> <001401cf7afd$879e3240$96da96c0$@iname.com> Message-ID: >From talking to folks involved with http://www.cablewifi.com/ and Comcast support there is a separate service flow for the public SSID. I have yet to configure that in the lab, but it sounds like a good project :) Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, May 29, 2014 at 1:19 AM, Frank Bulk wrote: > It's my understanding that the public Wi-Fi uses the same data flow as the > subcriber's data flow. I've seen nothing in the release notes for ARRIS or > Moto that suggest one can tie an SSID to a specific service flow. > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay Ashworth > Sent: Wednesday, May 28, 2014 9:01 AM > To: NANOG > Subject: CMTS/Public Wifi provisioning question > > I expect Frank Bulk to have an opinion on this, all others welcome. > > Hat tip to Bright House -- I've noticed lately that I don't have to go > through their captive portal when using their public wifi hotspots (they > participate in the CableWifi consortium, using WAPs built into their > 6580 and other cablemodems, and offer a carrier-specific connection SSID > as well). > > This has led me to a point of curiosity: > > If I'm the subscriber, and I've paid for 15 mb/s down, then my wired > connection and my private wireless (if provisioned, and they charge > $10/mo, so I'll do that myself, thanks) are using one ... DOCSIS path? > back to the CMTS. > > I assume that cableco provided voice is on a separate path, and I'm sure > the TV service is -- if it's even IP at all. > > But the question is: is that public wifi service *also* on a separate > bandwidth-limited channel out of the cablemodem? > > Offline replies fine, unless you think it's of sufficiently general > interest; I expect it's implementation dependent. > > 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 daniel.karrenberg at ripe.net Wed May 28 07:22:25 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 28 May 2014 09:22:25 +0200 Subject: [dns-wg] crave your indulgence In-Reply-To: <5384DD2D.1040305@ripe.net> References: <110B4198-E9C2-490D-AF82-01C8AF4CEF31@isi.edu> <5384DD2D.1040305@ripe.net> Message-ID: <53858EB1.4000209@ripe.net> On 27.05.14 20:45 , Robert Kisteleki wrote: > ... > There should be a tool for this kind of thing! :-) > > https://atlas.ripe.net/atlas/udm.html?msm_id=1666831 [shortened version for NANOG with only one attachment] When you analyse these results with using my experimental tool LARA http://labske.org/tools you discover that local connectivity is through HE and Los Nettos. Further you can see that about half the HE packets are sent via Los Nettos, so the amount ofredundancy that local traffic distribution among upstreams may suggest is not really there. If you like we can run this again with more probes. Of course you can also just get an account and run it yourself.... Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: bif-tr1-netnames.png Type: image/png Size: 81220 bytes Desc: not available URL: From fclements at corp.ptd.net Wed May 28 21:10:20 2014 From: fclements at corp.ptd.net (Clements, Frank) Date: Wed, 28 May 2014 21:10:20 +0000 Subject: CMTS/Public Wifi provisioning question In-Reply-To: <18008962.2628.1401285659813.JavaMail.root@benjamin.baylink.com> References: <18008962.2628.1401285659813.JavaMail.root@benjamin.baylink.com> Message-ID: <55B1C3EE-22F1-4EF1-9C24-30F26D2D2D71@corp.ptd.net> On list would be awesome, I'm also interested in this! -- Frank Clements > On May 28, 2014, at 10:02 AM, "Jay Ashworth" wrote: > > I expect Frank Bulk to have an opinion on this, all others welcome. > > Hat tip to Bright House -- I've noticed lately that I don't have to go > through their captive portal when using their public wifi hotspots (they > participate in the CableWifi consortium, using WAPs built into their > 6580 and other cablemodems, and offer a carrier-specific connection SSID > as well). > > This has led me to a point of curiosity: > > If I'm the subscriber, and I've paid for 15 mb/s down, then my wired > connection and my private wireless (if provisioned, and they charge > $10/mo, so I'll do that myself, thanks) are using one ... DOCSIS path? > back to the CMTS. > > I assume that cableco provided voice is on a separate path, and I'm sure > the TV service is -- if it's even IP at all. > > But the question is: is that public wifi service *also* on a separate > bandwidth-limited channel out of the cablemodem? > > Offline replies fine, unless you think it's of sufficiently general > interest; I expect it's implementation dependent. > > 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 jcurran at arin.net Thu May 29 15:04:48 2014 From: jcurran at arin.net (John Curran) Date: Thu, 29 May 2014 15:04:48 +0000 Subject: Regional IPv4 Free Pool Depletion versus "Possible Bogus Routes" section of The Cidr Report References: <201405232200.s4NM00vi005330@wattle.apnic.net> Message-ID: <8F55AF7C-096C-4D47-B4FA-F3AF89152285@arin.net> Folks - Several of the "Possible Bogus Routes" in the weekly Cidr report appear to be from address blocks which will be issued as we get closer to the end of the IPv4 free pool in each region. In the case of ARIN, this is expected to be in the second half of this year (2014). If you are currently sourcing routes of one of these address blocks, it may be prudent to start reviewing the basis for doing so, as any issuance would likely result in unexpected operational impacts once put into use by the recipient. If there is some confusion regarding the registration status of one of these blocks, then having the current party making use of the block raise the issue with the respective RIR would be a very wise proactive measure. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: cidr-report at potaroo.net Subject: The Cidr Report Date: May 23, 2014 at 6:00:00 PM EDT To: cidr-report at potaroo.net Cc: nanog at nanog.org, routing-wg at ripe.net, apops at apops.net, eof-list at ripe.net, afnog at afnog.org This report has been generated at Fri May 23 21:13:54 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. ... Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.236.0/24 AS37290 -Reserved AS-,ZZ 41.78.237.0/24 AS37290 -Reserved AS-,ZZ 41.78.238.0/24 AS37290 -Reserved AS-,ZZ 41.78.239.0/24 AS37290 -Reserved AS-,ZZ 41.189.96.0/19 AS37000 -Reserved AS-,ZZ 41.190.72.0/24 AS37451 CongoTelecom,CG 41.190.73.0/24 AS37451 CongoTelecom,CG 41.190.74.0/24 AS37451 CongoTelecom,CG 41.190.75.0/24 AS37451 CongoTelecom,CG 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.111.160.0/20 AS40551 -Reserved AS-,ZZ 64.111.160.0/24 AS40551 -Reserved AS-,ZZ 64.111.161.0/24 AS40551 -Reserved AS-,ZZ 64.111.162.0/24 AS40551 -Reserved AS-,ZZ 64.111.167.0/24 AS40551 -Reserved AS-,ZZ 64.111.169.0/24 AS40551 -Reserved AS-,ZZ 64.111.170.0/24 AS40551 -Reserved AS-,ZZ 64.111.171.0/24 AS40551 -Reserved AS-,ZZ 64.111.172.0/24 AS40551 -Reserved AS-,ZZ 64.111.173.0/24 AS40551 -Reserved AS-,ZZ 64.111.174.0/24 AS40551 -Reserved AS-,ZZ 64.111.175.0/24 AS40551 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.115.124.0/23 AS46540 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 -Reserved AS-,ZZ 74.120.214.0/23 AS32326 -Reserved AS-,ZZ 74.120.240.0/21 AS30063 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.122.224.0/21 AS30063 -Reserved AS-,ZZ 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD,RU 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT 91.229.182.0/24 AS56960 -Reserved AS-,ZZ 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 95.215.140.0/22 AS48949 -Reserved AS-,ZZ 100.64.111.0/24 AS25019 SAUDINETSTC-AS SaudiNet, Saudi Telecom Company,SA 100.88.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.89.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.90.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.91.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.92.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.93.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.94.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.95.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.96.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.100.1.0/24 AS26219 Skycorp S.A.,AR 100.104.0.0/13 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.112.0.0/13 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.120.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.124.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN 103.18.76.0/22 AS18097 JPNIC-ASBLOCK-AP JPNIC,JP 103.18.80.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK 103.18.81.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK 103.23.48.0/24 AS56194 103.23.49.0/24 AS56194 103.23.50.0/24 AS56194 103.23.51.0/24 AS56194 103.244.236.0/22 AS58794 103.247.52.0/23 AS4725 ODN SOFTBANK TELECOM Corp.,JP 104.36.40.0/22 AS4474 TCT-AS - TCT West, Inc.,US 104.128.48.0/20 AS32748 STEADFAST - Steadfast Networks,US 104.128.48.0/22 AS32181 ASN-GIGENET - GigeNET,US 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.158.28.0/22 AS45857 154.121.0.0/24 AS32771 ATM,DZ 154.121.1.0/24 AS32771 ATM,DZ 154.121.2.0/24 AS32771 ATM,DZ 154.121.3.0/24 AS32771 ATM,DZ 154.121.4.0/24 AS32771 ATM,DZ 154.121.5.0/24 AS32771 ATM,DZ 163.47.23.0/24 AS2907 JPNIC-2BYTE-ASBLOCK-AP for assignment to JPNIC members,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.80.9.0/24 AS26219 Skycorp S.A.,AR 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.90.1.0/24 AS26219 Skycorp S.A.,AR 172.90.3.0/24 AS26219 Skycorp S.A.,AR 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 173.213.208.0/22 AS54040 -Reserved AS-,ZZ 173.213.212.0/24 AS54040 -Reserved AS-,ZZ 173.213.213.0/24 AS54040 -Reserved AS-,ZZ 173.213.214.0/23 AS54040 -Reserved AS-,ZZ 173.213.216.0/21 AS54040 -Reserved AS-,ZZ 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 176.125.224.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.58.176.0/22 AS28792 PUBLIC-INTERNET Public Internet Ltd,GB 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A.,EC 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc.,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.84.187.0/24 AS16276 OVH OVH SAS,FR 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.112.0/23 AS12964 DBMG-DE Dr. Buelow & Masiak GmbH,DE 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.243.166.0/24 AS44093 -Reserved AS-,ZZ 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.69.203.0/24 AS5089 NTL Virgin Media Limited,GB 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.39.252.0/23 AS29004 -Reserved AS-,ZZ 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL,RO 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.2.224.0/22 AS24863 LINKdotNET-AS,EG 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.13.201.0/24 AS2018 TENET-1,ZA 196.13.202.0/24 AS2018 TENET-1,ZA 196.13.203.0/24 AS2018 TENET-1,ZA 196.13.204.0/24 AS2018 TENET-1,ZA 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.45.0.0/21 AS26625 -Reserved AS-,ZZ 196.45.10.0/24 AS26625 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.9.40.0/24 AS56194 202.9.41.0/24 AS56194 202.9.42.0/24 AS56194 202.9.43.0/24 AS56194 202.9.44.0/24 AS56194 202.9.45.0/24 AS56194 202.9.46.0/24 AS56194 202.9.47.0/24 AS56194 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.10.94.0/23 AS30097 NUWAVE - NuWave,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/22 AS16936 -Reserved AS-,ZZ 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.73.112.0/24 AS19231 -Reserved AS-,ZZ 208.73.113.0/24 AS19231 -Reserved AS-,ZZ 208.73.114.0/24 AS19231 -Reserved AS-,ZZ 208.73.115.0/24 AS19231 -Reserved AS-,ZZ 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US 209.17.224.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.225.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.226.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.227.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.228.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.229.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.230.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.231.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.232.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.233.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.234.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.235.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.236.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.237.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.238.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.239.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.240.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.241.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.242.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.243.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.244.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.245.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.246.0/24 AS14846 CGNOGE - NBC Internet,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 212.119.32.0/19 AS12550 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.178.96.0/21 AS17035 -Reserved AS-,ZZ 216.178.104.0/21 AS17035 -Reserved AS-,ZZ 216.203.80.0/20 AS27021 -Reserved AS-,ZZ 216.203.80.0/21 AS27021 -Reserved AS-,ZZ 216.203.87.0/24 AS27021 -Reserved AS-,ZZ 216.203.88.0/21 AS27021 -Reserved AS-,ZZ 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 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 frnkblk at iname.com Fri May 30 03:27:22 2014 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 29 May 2014 22:27:22 -0500 Subject: CMTS/Public Wifi provisioning question In-Reply-To: References: <18008962.2628.1401285659813.JavaMail.root@benjamin.baylink.com> <001401cf7afd$879e3240$96da96c0$@iname.com> Message-ID: <001a01cf7bb7$11cd90f0$3568b2d0$@iname.com> Interesting, I may need to open a ticket with Moto to ask how that’s done. Frank From: Scott Helms [mailto:khelms at zcorum.com] Sent: Thursday, May 29, 2014 7:58 AM To: Frank Bulk Cc: Jay Ashworth; NANOG Subject: Re: CMTS/Public Wifi provisioning question >From talking to folks involved with http://www.cablewifi.com/ and Comcast support there is a separate service flow for the public SSID. I have yet to configure that in the lab, but it sounds like a good project :) Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, May 29, 2014 at 1:19 AM, Frank Bulk > wrote: It's my understanding that the public Wi-Fi uses the same data flow as the subcriber's data flow. I've seen nothing in the release notes for ARRIS or Moto that suggest one can tie an SSID to a specific service flow. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org ] On Behalf Of Jay Ashworth Sent: Wednesday, May 28, 2014 9:01 AM To: NANOG Subject: CMTS/Public Wifi provisioning question I expect Frank Bulk to have an opinion on this, all others welcome. Hat tip to Bright House -- I've noticed lately that I don't have to go through their captive portal when using their public wifi hotspots (they participate in the CableWifi consortium, using WAPs built into their 6580 and other cablemodems, and offer a carrier-specific connection SSID as well). This has led me to a point of curiosity: If I'm the subscriber, and I've paid for 15 mb/s down, then my wired connection and my private wireless (if provisioned, and they charge $10/mo, so I'll do that myself, thanks) are using one ... DOCSIS path? back to the CMTS. I assume that cableco provided voice is on a separate path, and I'm sure the TV service is -- if it's even IP at all. But the question is: is that public wifi service *also* on a separate bandwidth-limited channel out of the cablemodem? Offline replies fine, unless you think it's of sufficiently general interest; I expect it's implementation dependent. 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 Jason_Livingood at cable.comcast.com Fri May 30 13:00:03 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Fri, 30 May 2014 13:00:03 +0000 Subject: CMTS/Public Wifi provisioning question In-Reply-To: <001a01cf7bb7$11cd90f0$3568b2d0$@iname.com> References: <18008962.2628.1401285659813.JavaMail.root@benjamin.baylink.com> <001401cf7afd$879e3240$96da96c0$@iname.com> <001a01cf7bb7$11cd90f0$3568b2d0$@iname.com> Message-ID: If folks have questions - happy to assist - my team manages the engineering of our WiFi network (in home & out of home). Just send me a note off-list. Jason Livingood Comcast On 5/29/14, 11:27 PM, "Frank Bulk" wrote: >Interesting, I may need to open a ticket with Moto to ask how that¹s done. > > > >Frank > > > >From: Scott Helms [mailto:khelms at zcorum.com] >Sent: Thursday, May 29, 2014 7:58 AM >To: Frank Bulk >Cc: Jay Ashworth; NANOG >Subject: Re: CMTS/Public Wifi provisioning question > > > >From talking to folks involved with http://www.cablewifi.com/ and Comcast >support there is a separate service flow for the public SSID. I have yet >to configure that in the lab, but it sounds like a good project :) > > > > > > >Scott Helms >Vice President of Technology >ZCorum >(678) 507-5000 >-------------------------------- >http://twitter.com/kscotthelms >-------------------------------- > > > >On Thu, May 29, 2014 at 1:19 AM, Frank Bulk > wrote: > >It's my understanding that the public Wi-Fi uses the same data flow as >the subcriber's data flow. I've seen nothing in the release notes for >ARRIS or Moto that suggest one can tie an SSID to a specific service flow. > >Frank > >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org > ] On Behalf Of Jay Ashworth >Sent: Wednesday, May 28, 2014 9:01 AM >To: NANOG >Subject: CMTS/Public Wifi provisioning question > >I expect Frank Bulk to have an opinion on this, all others welcome. > >Hat tip to Bright House -- I've noticed lately that I don't have to go >through their captive portal when using their public wifi hotspots (they >participate in the CableWifi consortium, using WAPs built into their >6580 and other cablemodems, and offer a carrier-specific connection SSID >as well). > >This has led me to a point of curiosity: > >If I'm the subscriber, and I've paid for 15 mb/s down, then my wired >connection and my private wireless (if provisioned, and they charge >$10/mo, so I'll do that myself, thanks) are using one ... DOCSIS path? >back to the CMTS. > >I assume that cableco provided voice is on a separate path, and I'm sure >the TV service is -- if it's even IP at all. > >But the question is: is that public wifi service *also* on a separate >bandwidth-limited channel out of the cablemodem? > >Offline replies fine, unless you think it's of sufficiently general >interest; I expect it's implementation dependent. > >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 blake at ispn.net Fri May 30 15:02:47 2014 From: blake at ispn.net (Blake Hudson) Date: Fri, 30 May 2014 10:02:47 -0500 Subject: CMTS/Public Wifi provisioning question In-Reply-To: <001a01cf7bb7$11cd90f0$3568b2d0$@iname.com> References: <18008962.2628.1401285659813.JavaMail.root@benjamin.baylink.com> <001401cf7afd$879e3240$96da96c0$@iname.com> <001a01cf7bb7$11cd90f0$3568b2d0$@iname.com> Message-ID: <53889D97.7000604@ispn.net> DOCSIS config files allow one to use service flow classifiers that match on a variety of criteria. I imagine either the IP range used for public access or the SSID/VLAN/Interface of the wifi hotspot could be used in this instance. http://www.cmtsinfo.net/?howto=cm_config provides a good general overview of what's available and how to apply (see section 6 on classifiers). Of course, even if a dedicated service flow is used, this could still compete with the bandwidth available to the modem or to other modems served on the same node. I could envision this making network bandwidth management more difficult as customers roam, especially if they densely congregate. --Blake Frank Bulk wrote the following on 5/29/2014 10:27 PM: > Interesting, I may need to open a ticket with Moto to ask how that’s done. > > > > Frank > > > > From: Scott Helms [mailto:khelms at zcorum.com] > Sent: Thursday, May 29, 2014 7:58 AM > To: Frank Bulk > Cc: Jay Ashworth; NANOG > Subject: Re: CMTS/Public Wifi provisioning question > > > > From talking to folks involved with http://www.cablewifi.com/ and Comcast support there is a separate service flow for the public SSID. I have yet to configure that in the lab, but it sounds like a good project :) > > > > > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > > On Thu, May 29, 2014 at 1:19 AM, Frank Bulk > wrote: > > It's my understanding that the public Wi-Fi uses the same data flow as the subcriber's data flow. I've seen nothing in the release notes for ARRIS or Moto that suggest one can tie an SSID to a specific service flow. > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org ] On Behalf Of Jay Ashworth > Sent: Wednesday, May 28, 2014 9:01 AM > To: NANOG > Subject: CMTS/Public Wifi provisioning question > > I expect Frank Bulk to have an opinion on this, all others welcome. > > Hat tip to Bright House -- I've noticed lately that I don't have to go > through their captive portal when using their public wifi hotspots (they > participate in the CableWifi consortium, using WAPs built into their > 6580 and other cablemodems, and offer a carrier-specific connection SSID > as well). > > This has led me to a point of curiosity: > > If I'm the subscriber, and I've paid for 15 mb/s down, then my wired > connection and my private wireless (if provisioned, and they charge > $10/mo, so I'll do that myself, thanks) are using one ... DOCSIS path? > back to the CMTS. > > I assume that cableco provided voice is on a separate path, and I'm sure > the TV service is -- if it's even IP at all. > > But the question is: is that public wifi service *also* on a separate > bandwidth-limited channel out of the cablemodem? > > Offline replies fine, unless you think it's of sufficiently general > interest; I expect it's implementation dependent. > > 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 shortdudey123 at gmail.com Fri May 30 15:14:20 2014 From: shortdudey123 at gmail.com (Grant Ridder) Date: Fri, 30 May 2014 08:14:20 -0700 Subject: Google voice contact Message-ID: Hi Everyone, Can someone with Google voice contact me offlist? My work has a google voice number that was setup long ago, and no one knows what email address it is attached to. -Grant From cscora at apnic.net Fri May 30 18:11:41 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 31 May 2014 04:11:41 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201405301811.s4UIBfqu015723@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 31 May, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 496757 Prefixes after maximum aggregation: 194283 Deaggregation factor: 2.56 Unique aggregates announced to Internet: 245269 Total ASes present in the Internet Routing Table: 46953 Prefixes per ASN: 10.58 Origin-only ASes present in the Internet Routing Table: 35820 Origin ASes announcing only one prefix: 16321 Transit ASes present in the Internet Routing Table: 6117 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: 1760 Unregistered ASNs in the Routing Table: 454 Number of 32-bit ASNs allocated by the RIRs: 6751 Number of 32-bit ASNs visible in the Routing Table: 5016 Prefixes from 32-bit ASNs in the Routing Table: 17046 Number of bogon 32-bit ASNs visible in the Routing Table: 182 Special use prefixes present in the Routing Table: 14 Prefixes being announced from unallocated address space: 426 Number of addresses announced to Internet: 2691437568 Equivalent to 160 /8s, 108 /16s and 20 /24s Percentage of available address space announced: 72.7 Percentage of allocated address space announced: 72.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.5 Total number of prefixes smaller than registry allocations: 172289 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 118346 Total APNIC prefixes after maximum aggregation: 35205 APNIC Deaggregation factor: 3.36 Prefixes being announced from the APNIC address blocks: 121399 Unique aggregates announced from the APNIC address blocks: 50818 APNIC Region origin ASes present in the Internet Routing Table: 4941 APNIC Prefixes per ASN: 24.57 APNIC Region origin ASes announcing only one prefix: 1229 APNIC Region transit ASes present in the Internet Routing Table: 868 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 24 Number of APNIC region 32-bit ASNs visible in the Routing Table: 960 Number of APNIC addresses announced to Internet: 733707136 Equivalent to 43 /8s, 187 /16s and 123 /24s Percentage of available APNIC address space announced: 85.7 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: 168392 Total ARIN prefixes after maximum aggregation: 83486 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 170004 Unique aggregates announced from the ARIN address blocks: 79409 ARIN Region origin ASes present in the Internet Routing Table: 16285 ARIN Prefixes per ASN: 10.44 ARIN Region origin ASes announcing only one prefix: 6114 ARIN Region transit ASes present in the Internet Routing Table: 1685 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 112 Number of ARIN addresses announced to Internet: 1076222976 Equivalent to 64 /8s, 37 /16s and 220 /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: 123795 Total RIPE prefixes after maximum aggregation: 62795 RIPE Deaggregation factor: 1.97 Prefixes being announced from the RIPE address blocks: 128358 Unique aggregates announced from the RIPE address blocks: 81051 RIPE Region origin ASes present in the Internet Routing Table: 17694 RIPE Prefixes per ASN: 7.25 RIPE Region origin ASes announcing only one prefix: 8248 RIPE Region transit ASes present in the Internet Routing Table: 2883 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: 2714 Number of RIPE addresses announced to Internet: 658556544 Equivalent to 39 /8s, 64 /16s and 198 /24s Percentage of available RIPE address space announced: 95.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 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: 57046 Total LACNIC prefixes after maximum aggregation: 10096 LACNIC Deaggregation factor: 5.65 Prefixes being announced from the LACNIC address blocks: 63836 Unique aggregates announced from the LACNIC address blocks: 29229 LACNIC Region origin ASes present in the Internet Routing Table: 2102 LACNIC Prefixes per ASN: 30.37 LACNIC Region origin ASes announcing only one prefix: 531 LACNIC Region transit ASes present in the Internet Routing Table: 438 Average LACNIC Region AS path length visible: 4.6 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1198 Number of LACNIC addresses announced to Internet: 164221696 Equivalent to 9 /8s, 201 /16s and 211 /24s Percentage of available LACNIC address space announced: 97.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: 12030 Total AfriNIC prefixes after maximum aggregation: 2664 AfriNIC Deaggregation factor: 4.52 Prefixes being announced from the AfriNIC address blocks: 12734 Unique aggregates announced from the AfriNIC address blocks: 4382 AfriNIC Region origin ASes present in the Internet Routing Table: 719 AfriNIC Prefixes per ASN: 17.71 AfriNIC Region origin ASes announcing only one prefix: 199 AfriNIC Region transit ASes present in the Internet Routing Table: 156 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 32 Number of AfriNIC addresses announced to Internet: 56025600 Equivalent to 3 /8s, 86 /16s and 226 /24s Percentage of available AfriNIC address space announced: 55.7 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 2940 11591 922 Korea Telecom 17974 2793 899 72 PT Telekomunikasi Indonesia 7545 2233 320 117 TPG Telecom Limited 4755 1855 396 199 TATA Communications formerly 9829 1652 1307 32 National Internet Backbone 9583 1302 101 535 Sify Limited 9498 1260 314 84 BHARTI Airtel Ltd. 7552 1234 1090 14 Viettel Corporation 4808 1216 2148 360 CNCGROUP IP network China169 24560 1144 393 188 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 2960 3688 53 BellSouth.net Inc. 22773 2438 2937 134 Cox Communications Inc. 1785 2146 684 138 PaeTec Communications, Inc. 18566 2047 379 178 MegaPath Corporation 20115 1703 1687 571 Charter Communications 4323 1631 1073 414 tw telecom holdings, inc. 701 1447 11189 733 MCI Communications Services, 30036 1417 310 546 Mediacom Communications Corp 6983 1325 800 306 ITC^Deltacom 22561 1307 402 232 CenturyTel Internet Holdings, 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 34984 1706 264 275 TELLCOM ILETISIM HIZMETLERI A 8402 1461 544 16 OJSC "Vimpelcom" 20940 1385 535 1030 Akamai International B.V. 13188 1031 100 28 TOV "Bank-Inform" 31148 1018 45 19 Freenet Ltd. 8551 956 370 40 Bezeq International-Ltd 6849 823 357 28 JSC "Ukrtelecom" 6830 759 2333 420 Liberty Global Operations B.V 12479 730 795 57 France Telecom Espana SA 9198 576 344 28 JSC Kazakhtelecom 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 3808 1996 100 NET Servi�os de Comunica��o S 10620 2874 464 191 Telmex Colombia S.A. 18881 2015 972 21 Global Village Telecom 7303 1760 1175 229 Telecom Argentina S.A. 8151 1408 2949 410 Uninet S.A. de C.V. 6503 1105 434 61 Axtel, S.A.B. de C.V. 7738 979 1882 41 Telemar Norte Leste S.A. 27947 885 114 50 Telconet S.A 26615 861 2325 35 Tim Celular S.A. 3816 827 339 137 COLOMBIA TELECOMUNICACIONES S 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 1114 240 6 Sudanese Mobile Telephone (ZA 24863 961 280 26 Link Egypt (Link.NET) 6713 615 727 32 Office National des Postes et 8452 587 958 13 TE-AS 24835 304 144 9 Vodafone Data 36992 300 783 24 ETISALAT MISR 37054 250 19 6 Data Telecom Service 3741 248 921 209 Internet Solutions 29571 225 22 16 Cote d'Ivoire Telecom 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 3808 1996 100 NET Servi�os de Comunica��o S 6389 2960 3688 53 BellSouth.net Inc. 4766 2940 11591 922 Korea Telecom 10620 2874 464 191 Telmex Colombia S.A. 17974 2793 899 72 PT Telekomunikasi Indonesia 22773 2438 2937 134 Cox Communications Inc. 7545 2233 320 117 TPG Telecom Limited 1785 2146 684 138 PaeTec Communications, Inc. 18566 2047 379 178 MegaPath Corporation 18881 2015 972 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 2960 2907 BellSouth.net Inc. 17974 2793 2721 PT Telekomunikasi Indonesia 10620 2874 2683 Telmex Colombia S.A. 22773 2438 2304 Cox Communications Inc. 7545 2233 2116 TPG Telecom Limited 4766 2940 2018 Korea Telecom 1785 2146 2008 PaeTec Communications, Inc. 18881 2015 1994 Global Village Telecom 18566 2047 1869 MegaPath Corporation 4755 1855 1656 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 5.109.32.0/19 23456 32bit Transition AS 65456 PRIVATE 5.109.96.0/19 23456 32bit Transition AS 30662 UNALLOCATED 8.2.129.0/24 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 22511 UNALLOCATED 8.28.225.0/24 2828 XO Communications 22511 UNALLOCATED 8.36.68.0/24 2828 XO Communications 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.64.111.0/24 25019 Autonomus System Number for S 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.96.0.0/14 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 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.14.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 41.73.16.0/24 37004 >>UNKNOWN<< 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:12 /10:30 /11:91 /12:258 /13:489 /14:979 /15:1704 /16:12976 /17:6888 /18:11729 /19:24495 /20:34503 /21:36968 /22:52961 /23:46528 /24:264033 /25:774 /26:919 /27:384 /28:13 /29:5 /30:0 /31:0 /32:2 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2002 2047 MegaPath Corporation 6389 1694 2960 BellSouth.net Inc. 22773 1690 2438 Cox Communications Inc. 30036 1254 1417 Mediacom Communications Corp 11492 1176 1216 CABLE ONE, INC. 1785 1167 2146 PaeTec Communications, Inc. 8402 1161 1461 OJSC "Vimpelcom" 36998 1080 1114 Sudanese Mobile Telephone (ZA 6983 1042 1325 ITC^Deltacom 34984 1036 1706 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1134 2:664 3:3 4:15 5:1020 6:19 8:745 12:1845 13:3 14:1001 15:13 16:2 17:34 18:21 20:38 23:885 24:1739 25:1 27:1767 31:1476 32:43 33:2 34:5 36:137 37:1900 38:950 39:7 40:202 41:3229 42:253 44:11 46:2097 47:21 49:704 50:936 52:12 54:48 55:10 57:29 58:1223 59:605 60:401 61:1547 62:1248 63:1961 64:4363 65:2290 66:4186 67:2073 68:1055 69:3333 70:857 71:438 72:2017 74:2653 75:324 76:421 77:1684 78:863 79:695 80:1289 81:1150 82:751 83:760 84:734 85:1314 86:461 87:1169 88:486 89:1826 90:141 91:5696 92:694 93:1750 94:2031 95:1511 96:526 97:363 98:1081 99:48 100:55 101:813 103:4982 105:539 106:168 107:616 108:586 109:2027 110:968 111:1302 112:655 113:845 114:864 115:1122 116:1074 117:943 118:1407 119:1387 120:390 121:824 122:2029 123:1311 124:1450 125:1400 128:571 129:341 130:347 131:662 132:404 133:163 134:319 135:74 136:259 137:296 138:357 139:165 140:211 141:375 142:572 143:453 144:507 145:104 146:621 147:472 148:909 149:361 150:168 151:739 152:440 153:219 154:298 155:487 156:343 157:336 158:244 159:896 160:329 161:558 162:1487 163:236 164:692 165:605 166:280 167:620 168:1056 169:124 170:1431 171:187 172:21 173:1648 174:708 175:603 176:1406 177:3083 178:2015 179:631 180:1741 181:1143 182:1570 183:526 184:710 185:1706 186:2888 187:1575 188:1935 189:1456 190:7552 191:370 192:7286 193:5508 194:4029 195:3502 196:1384 197:666 198:5076 199:5507 200:6232 201:2559 202:9017 203:8906 204:4583 205:2666 206:2930 207:2978 208:3992 209:3744 210:3093 211:1689 212:2293 213:2056 214:871 215:86 216:5539 217:1690 218:584 219:321 220:1284 221:613 222:352 223:596 End of report From ahebert at pubnix.net Fri May 30 21:09:52 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 30 May 2014 17:09:52 -0400 Subject: Off Topic Friday Message-ID: <5388F3A0.70000@pubnix.net> Well happy friday. We're planning to build a MPLS lab this summer. If anyone has suggestion for cheap hardware to simulate a implementation of all the RFC's from the Core to the CPE. it would be greatly appreciated. >From our research, It is pretty much all over the place, like the vendor did it on purpose to milk all the money they could from the spec :). As usual, off-list would be best. PS: I'll forward a summary of the information to the people interested by this subject. -- ----- 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 charles at thefnf.org Fri May 30 21:32:55 2014 From: charles at thefnf.org (charles at thefnf.org) Date: Fri, 30 May 2014 16:32:55 -0500 Subject: Off Topic Friday In-Reply-To: <5388F3A0.70000@pubnix.net> References: <5388F3A0.70000@pubnix.net> Message-ID: <56119eaa984396748236d6f67e8e7b6c@thefnf.org> On 2014-05-30 16:09, Alain Hebert wrote: > Well happy friday. > > We're planning to build a MPLS lab this summer. What's this? Operational related content on a Friday? *angrily hurls popcorn across the room*. LOL. MPLS lab sounds cool. For students? Already experienced engineers? Simulating a production environment? Tell us more details please! :) > > If anyone has suggestion for cheap hardware to simulate a > implementation of all the RFC's from the Core to the CPE. Hmmmm. Good question. Any particular vendors you want to emulate? C/J I presume (maybe interop between them)? They do have official VM versions freely available of representative sampling of their product lines now days. Start there? Run it on a digtial ocean cloud? (They are currently $MY_FAV_CLOUD_PROVIDER) Or if you've got some spare server class kit kicking around your nearest colo then just load up Ubuntu 12.04 and Virtualbox (or heck, even w2k12/w8 which is what I'm using for my network vm lab). I've got... HP (comware something something (v7? I dunno) . Oh and they have some cloud router deal to, I think I grabbed that. Arista (got this at SCALE this year). Not sure if you can grab it "officially offically" Cisco (asa, asr and that cloud router thing) Juniper (mx emulator something someting) Huewai (eNSP) GNS3 I'm not at home right now, I'll put the links to the above item downloads on my lab wiki and update the thread (I'm embarrassed I didn't do that already). Of course there is also OpenDaylight and other Linuxish stuff. But that's beyond MPLS. Linux/BSD MPLS seems to be not so great last I looked. > > it would be greatly appreciated. Same here. > > From our research, > > It is pretty much all over the place, like the vendor did it on > purpose to milk all the money they could from the spec :). Haha. > > As usual, off-list would be best. If it's cool with 10k of my closest friends, I'd say this would be a welcome on list topic? From cidr-report at potaroo.net Fri May 30 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 May 2014 22:00:01 GMT Subject: The Cidr Report Message-ID: <201405302200.s4UM01WP095119@wattle.apnic.net> This report has been generated at Fri May 30 21:13:56 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 23-05-14 501454 282069 24-05-14 501842 281925 25-05-14 501439 282209 26-05-14 501524 282359 27-05-14 501594 282236 28-05-14 502148 282677 29-05-14 501950 282549 30-05-14 502889 282922 AS Summary 47249 Number of ASes in routing system 19209 Number of ASes announcing only one prefix 3806 Largest number of prefixes announced by an AS AS28573: NET Servi�os de Comunica��o S.A.,BR 120042240 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 30May14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 503050 282945 220105 43.8% All ASes AS28573 3806 176 3630 95.4% NET Servi�os de Comunica��o S.A.,BR AS6389 2959 78 2881 97.4% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2794 248 2546 91.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS4766 2940 931 2009 68.3% KIXS-AS-KR Korea Telecom,KR AS18881 2018 37 1981 98.2% Global Village Telecom,BR AS1785 2192 470 1722 78.6% AS-PAETEC-NET - PaeTec Communications, Inc.,US AS10620 2874 1381 1493 51.9% Telmex Colombia S.A.,CO AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation,US AS7303 1765 442 1323 75.0% Telecom Argentina S.A.,AR AS4755 1855 583 1272 68.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4323 1642 426 1216 74.1% TWTC - tw telecom holdings, inc.,US AS7545 2249 1067 1182 52.6% TPG-INTERNET-AP TPG Telecom Limited,AU AS7552 1260 165 1095 86.9% VIETEL-AS-AP Viettel Corporation,VN AS22773 2433 1355 1078 44.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS36998 1114 37 1077 96.7% SDN-MOBITEL,SD AS22561 1307 241 1066 81.6% AS22561 - CenturyTel Internet Holdings, Inc.,US AS6983 1324 307 1017 76.8% ITCDELTA - Earthlink, Inc.,US AS4788 1055 147 908 86.1% TMNET-AS-AP TM Net, Internet Service Provider,MY AS9829 1571 696 875 55.7% BSNL-NIB National Internet Backbone,IN AS9808 1002 155 847 84.5% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS4808 1221 403 818 67.0% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS7738 979 189 790 80.7% Telemar Norte Leste S.A.,BR AS24560 1144 359 785 68.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS18101 943 187 756 80.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS26615 861 108 753 87.5% Tim Celular S.A.,BR AS8151 1418 682 736 51.9% Uninet S.A. de C.V.,MX AS701 1447 733 714 49.3% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US AS855 759 58 701 92.4% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA AS11492 1216 519 697 57.3% CABLEONE - CABLE ONE, INC.,US AS6147 819 125 694 84.7% Telefonica del Peru S.A.A.,PE Total 51014 12870 38144 74.8% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.236.0/24 AS37290 -Reserved AS-,ZZ 41.78.237.0/24 AS37290 -Reserved AS-,ZZ 41.78.238.0/24 AS37290 -Reserved AS-,ZZ 41.78.239.0/24 AS37290 -Reserved AS-,ZZ 41.189.96.0/19 AS37000 -Reserved AS-,ZZ 41.190.72.0/24 AS37451 CongoTelecom,CG 41.190.73.0/24 AS37451 CongoTelecom,CG 41.190.74.0/24 AS37451 CongoTelecom,CG 41.190.75.0/24 AS37451 CongoTelecom,CG 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.111.160.0/20 AS40551 -Reserved AS-,ZZ 64.111.160.0/24 AS40551 -Reserved AS-,ZZ 64.111.161.0/24 AS40551 -Reserved AS-,ZZ 64.111.162.0/24 AS40551 -Reserved AS-,ZZ 64.111.167.0/24 AS40551 -Reserved AS-,ZZ 64.111.169.0/24 AS40551 -Reserved AS-,ZZ 64.111.170.0/24 AS40551 -Reserved AS-,ZZ 64.111.171.0/24 AS40551 -Reserved AS-,ZZ 64.111.172.0/24 AS40551 -Reserved AS-,ZZ 64.111.173.0/24 AS40551 -Reserved AS-,ZZ 64.111.174.0/24 AS40551 -Reserved AS-,ZZ 64.111.175.0/24 AS40551 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.115.124.0/23 AS46540 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 -Reserved AS-,ZZ 74.120.214.0/23 AS32326 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 95.215.140.0/22 AS48949 -Reserved AS-,ZZ 100.88.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.89.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.90.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.91.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.92.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.93.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.94.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.95.0.0/16 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.96.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.104.0.0/13 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.112.0.0/13 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.120.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 100.124.0.0/14 AS6697 BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP 103.18.80.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK 103.18.81.0/24 AS13253 HKDNCL-AS Dot Gold Data Exchange Center,HK 103.23.48.0/24 AS56194 103.23.49.0/24 AS56194 103.23.50.0/24 AS56194 103.23.51.0/24 AS56194 103.232.156.0/23 AS58624 END2END-AS-AP End 2 End Limited,NZ 103.232.158.0/24 AS58624 END2END-AS-AP End 2 End Limited,NZ 104.36.116.0/22 AS14442 MEDIA-HOSTS - Media-Hosts Inc.,CA 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.158.28.0/22 AS45857 155.254.32.0/19 AS62599 VIVID - Vivid LLC,US 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 173.213.208.0/22 AS54040 -Reserved AS-,ZZ 173.213.212.0/24 AS54040 -Reserved AS-,ZZ 173.213.213.0/24 AS54040 -Reserved AS-,ZZ 173.213.214.0/23 AS54040 -Reserved AS-,ZZ 173.213.216.0/21 AS54040 -Reserved AS-,ZZ 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 176.125.224.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.59.120.0/22 AS20192 185.64.0.0/23 AS6870 H1ASN H1 LLC,RU 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A.,EC 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc.,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.84.187.0/24 AS16276 OVH OVH SAS,FR 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.112.0/23 AS12964 DBMG-DE Dr. Buelow & Masiak GmbH,DE 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.243.166.0/24 AS44093 -Reserved AS-,ZZ 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.69.203.0/24 AS5089 NTL Virgin Media Limited,GB 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.39.252.0/23 AS29004 -Reserved AS-,ZZ 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL,RO 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.2.224.0/22 AS24863 LINKdotNET-AS,EG 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.13.201.0/24 AS2018 TENET-1,ZA 196.13.202.0/24 AS2018 TENET-1,ZA 196.13.203.0/24 AS2018 TENET-1,ZA 196.13.204.0/24 AS2018 TENET-1,ZA 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.45.0.0/21 AS26625 -Reserved AS-,ZZ 196.45.10.0/24 AS26625 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.50.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.9.40.0/24 AS56194 202.9.41.0/24 AS56194 202.9.42.0/24 AS56194 202.9.43.0/24 AS56194 202.9.44.0/24 AS56194 202.9.45.0/24 AS56194 202.9.46.0/24 AS56194 202.9.47.0/24 AS56194 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.10.94.0/23 AS30097 NUWAVE - NuWave,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/22 AS16936 -Reserved AS-,ZZ 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.73.112.0/24 AS19231 -Reserved AS-,ZZ 208.73.113.0/24 AS19231 -Reserved AS-,ZZ 208.73.114.0/24 AS19231 -Reserved AS-,ZZ 208.73.115.0/24 AS19231 -Reserved AS-,ZZ 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US 209.17.224.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.225.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.226.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.227.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.228.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.229.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.230.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.231.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.232.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.233.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.234.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.235.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.236.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.237.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.238.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.239.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.240.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.241.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.242.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.243.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.244.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.245.0/24 AS14846 CGNOGE - NBC Internet,US 209.17.246.0/24 AS14846 CGNOGE - NBC Internet,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 212.119.32.0/19 AS12550 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.178.96.0/21 AS17035 -Reserved AS-,ZZ 216.178.104.0/21 AS17035 -Reserved AS-,ZZ 216.203.80.0/20 AS27021 -Reserved AS-,ZZ 216.203.80.0/21 AS27021 -Reserved AS-,ZZ 216.203.87.0/24 AS27021 -Reserved AS-,ZZ 216.203.88.0/21 AS27021 -Reserved AS-,ZZ 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 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 May 30 22:00:02 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 May 2014 22:00:02 GMT Subject: BGP Update Report Message-ID: <201405302200.s4UM02ot095133@wattle.apnic.net> BGP Update Report Interval: 22-May-14 -to- 29-May-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 110737 4.6% 107.2 -- BSNL-NIB National Internet Backbone,IN 2 - AS16625 72210 3.0% 451.3 -- AKAMAI-AS - Akamai Technologies, Inc.,US 3 - AS28885 47124 1.9% 306.0 -- OMANTEL-NAP-AS OmanTel NAP,OM 4 - AS8402 40557 1.7% 53.2 -- CORBINA-AS OJSC "Vimpelcom",RU 5 - AS28573 35149 1.4% 9.2 -- NET Servi�os de Comunica��o S.A.,BR 6 - AS48159 32851 1.4% 157.9 -- TIC-AS Telecommunication Infrastructure Company,IR 7 - AS23752 23801 1.0% 355.2 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 8 - AS10481 21890 0.9% 4.1 -- Prima S.A.,AR 9 - AS41691 20865 0.9% 907.2 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 10 - AS25184 17174 0.7% 134.2 -- AFRANET AFRANET Co. Tehran, Iran,IR 11 - AS14259 15809 0.7% 1317.4 -- Gtd Internet S.A.,CL 12 - AS4775 15800 0.7% 1128.6 -- GLOBE-TELECOM-AS Globe Telecoms,PH 13 - AS7552 14663 0.6% 12.1 -- VIETEL-AS-AP Viettel Corporation,VN 14 - AS27738 13362 0.6% 23.2 -- Ecuadortelecom S.A.,EC 15 - AS6629 12610 0.5% 12610.0 -- NOAA-AS - NOAA,US 16 - AS10620 11591 0.5% 4.8 -- Telmex Colombia S.A.,CO 17 - AS5800 11367 0.5% 77.3 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center,US 18 - AS6713 10934 0.5% 18.7 -- IAM-AS,MA 19 - AS35819 10655 0.4% 20.7 -- MOBILY-AS Etihad Etisalat Company (Mobily),SA 20 - AS647 10263 0.4% 77.2 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center,US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6629 12610 0.5% 12610.0 -- NOAA-AS - NOAA,US 2 - AS6459 7679 0.3% 7679.0 -- TRANSBEAM - I-2000, Inc.,US 3 - AS54465 7263 0.3% 7263.0 -- QPM-AS-1 - QuickPlay Media Inc.,US 4 - AS60345 10114 0.4% 5057.0 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 5 - AS45590 2803 0.1% 2803.0 -- HGCINTNET-AS-AP Hutch Connect,HK 6 - AS18135 9019 0.4% 1803.8 -- BTV BTV Cable television,JP 7 - AS3 1491 0.1% 1987.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 8 - AS60134 1351 0.1% 1351.0 -- FRESHNET-AS FreshNet Ltd.,UA 9 - AS14259 15809 0.7% 1317.4 -- Gtd Internet S.A.,CL 10 - AS4775 15800 0.7% 1128.6 -- GLOBE-TELECOM-AS Globe Telecoms,PH 11 - AS24683 1022 0.0% 1022.0 -- OSU-AS State Educational Institution of Higher Professional Education Orenburg State University,RU 12 - AS41691 20865 0.9% 907.2 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 13 - AS61976 694 0.0% 694.0 -- CODESPRING-AS Codespring SRL,RO 14 - AS4 645 0.0% 1417.0 -- ISI-AS - University of Southern California,US 15 - AS43095 571 0.0% 571.0 -- FUNDSERVICEBANK-NET OJSC FUNDSERVICEBANK,RU 16 - AS37447 2280 0.1% 570.0 -- OASIS-SPRL,CD 17 - AS44960 553 0.0% 553.0 -- CRYSTAL-SYSTEM-AS Crystal System SRL,RO 18 - AS37115 521 0.0% 521.0 -- TMP-UG,UG 19 - AS28236 2060 0.1% 515.0 -- PRTURBO INTERNET WIRELLESS EPP LTDA,BR 20 - AS53149 3563 0.1% 509.0 -- csc machado cia ltda,BR TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 89.221.206.0/24 20783 0.8% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 2 - 192.58.232.0/24 12610 0.5% AS6629 -- NOAA-AS - NOAA,US 3 - 202.70.64.0/21 11787 0.5% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 202.70.88.0/21 11489 0.5% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 5 - 78.109.192.0/20 10107 0.4% AS25184 -- AFRANET AFRANET Co. Tehran, Iran,IR 6 - 184.31.240.0/20 9337 0.4% AS16625 -- AKAMAI-AS - Akamai Technologies, Inc.,US 7 - 184.25.164.0/22 9240 0.4% AS16625 -- AKAMAI-AS - Akamai Technologies, Inc.,US 8 - 184.24.154.0/23 9238 0.4% AS16625 -- AKAMAI-AS - Akamai Technologies, Inc.,US 9 - 23.46.144.0/20 9055 0.3% AS16625 -- AKAMAI-AS - Akamai Technologies, Inc.,US 10 - 42.83.48.0/20 9012 0.3% AS18135 -- BTV BTV Cable television,JP 11 - 172.224.144.0/20 8793 0.3% AS16625 -- AKAMAI-AS - Akamai Technologies, Inc.,US 12 - 172.224.160.0/22 8733 0.3% AS16625 -- AKAMAI-AS - Akamai Technologies, Inc.,US 13 - 172.224.128.0/20 8691 0.3% AS16625 -- AKAMAI-AS - Akamai Technologies, Inc.,US 14 - 172.224.114.0/23 8642 0.3% AS16625 -- AKAMAI-AS - Akamai Technologies, Inc.,US 15 - 120.28.62.0/24 7957 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 16 - 205.247.12.0/24 7679 0.3% AS6459 -- TRANSBEAM - I-2000, Inc.,US 17 - 222.127.0.0/24 7559 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 18 - 206.152.15.0/24 7263 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.,US 19 - 78.158.184.0/24 5083 0.2% AS60345 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 20 - 5.160.10.0/24 5031 0.2% AS60345 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 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 Bill.Armstrong at charter.com Fri May 30 19:06:32 2014 From: Bill.Armstrong at charter.com (Armstrong, Bill R) Date: Fri, 30 May 2014 14:06:32 -0500 Subject: CMTS/Public Wifi provisioning question In-Reply-To: <53889D97.7000604@ispn.net> References: <18008962.2628.1401285659813.JavaMail.root@benjamin.baylink.com> <001401cf7afd$879e3240$96da96c0$@iname.com> <001a01cf7bb7$11cd90f0$3568b2d0$@iname.com> <53889D97.7000604@ispn.net> Message-ID: <1DB5A12D98EB024FA4A9D0355029655A01BA7AB240@KSTLMEXCP02MBX.CORP.CHARTERCOM.COM> That’s what I was thinking, I'm not sure about the specifics of the implementation in question but the SSID may have a unique tunnel address(back to a wireless controller) which *could* be used to tag the flows with a specific SCN. -Bill -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Blake Hudson Sent: Friday, May 30, 2014 10:03 AM To: nanog at nanog.org Subject: Re: CMTS/Public Wifi provisioning question DOCSIS config files allow one to use service flow classifiers that match on a variety of criteria. I imagine either the IP range used for public access or the SSID/VLAN/Interface of the wifi hotspot could be used in this instance. http://www.cmtsinfo.net/?howto=cm_config provides a good general overview of what's available and how to apply (see section 6 on classifiers). Of course, even if a dedicated service flow is used, this could still compete with the bandwidth available to the modem or to other modems served on the same node. I could envision this making network bandwidth management more difficult as customers roam, especially if they densely congregate. --Blake Frank Bulk wrote the following on 5/29/2014 10:27 PM: > Interesting, I may need to open a ticket with Moto to ask how that’s done. > > > > Frank > > > > From: Scott Helms [mailto:khelms at zcorum.com] > Sent: Thursday, May 29, 2014 7:58 AM > To: Frank Bulk > Cc: Jay Ashworth; NANOG > Subject: Re: CMTS/Public Wifi provisioning question > > > > From talking to folks involved with http://www.cablewifi.com/ and > Comcast support there is a separate service flow for the public SSID. > I have yet to configure that in the lab, but it sounds like a good > project :) > > > > > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > > On Thu, May 29, 2014 at 1:19 AM, Frank Bulk > wrote: > > It's my understanding that the public Wi-Fi uses the same data flow as the subcriber's data flow. I've seen nothing in the release notes for ARRIS or Moto that suggest one can tie an SSID to a specific service flow. > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org > ] On Behalf Of Jay Ashworth > Sent: Wednesday, May 28, 2014 9:01 AM > To: NANOG > Subject: CMTS/Public Wifi provisioning question > > I expect Frank Bulk to have an opinion on this, all others welcome. > > Hat tip to Bright House -- I've noticed lately that I don't have to go > through their captive portal when using their public wifi hotspots > (they participate in the CableWifi consortium, using WAPs built into > their > 6580 and other cablemodems, and offer a carrier-specific connection > SSID as well). > > This has led me to a point of curiosity: > > If I'm the subscriber, and I've paid for 15 mb/s down, then my wired > connection and my private wireless (if provisioned, and they charge > $10/mo, so I'll do that myself, thanks) are using one ... DOCSIS path? > back to the CMTS. > > I assume that cableco provided voice is on a separate path, and I'm > sure the TV service is -- if it's even IP at all. > > But the question is: is that public wifi service *also* on a separate > bandwidth-limited channel out of the cablemodem? > > Offline replies fine, unless you think it's of sufficiently general > interest; I expect it's implementation dependent. > > 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 > > > > >