From pfsinoz at gmail.com Sun Nov 1 08:06:48 2015 From: pfsinoz at gmail.com (Philip Smith) Date: Sun, 1 Nov 2015 18:06:48 +1000 Subject: APRICOT 2016 Message-ID: <5635C818.7040606@gmail.com> Hi everyone, Many of the NANOG community have over the years participated in the annual APRICOT conference. This is to let you know about the opening of the Call for Papers for APRICOT 2016, being held in Auckland, New Zealand. If you are considering attending APRICOT, why not do so as a presenter too. I've forwarded the CfP on behalf of the PC Chairs. Many thanks! philip -- Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) 15th - 26th February 2016, Auckland, New Zealand https://2016.apricot.net CALL FOR PAPERS =============== The APRICOT 2016 Programme Committee is now seeking contributions for Presentations and Tutorials for APRICOT 2016. We are looking for presenters who would: - Offer a technical tutorial on an appropriate topic; - Participate in the technical conference sessions as a speaker; - Convene and chair panel sessions of relevant topics. Please submit on-line at: http://papers.apricot.net/user/login.php?event=34 CONFERENCE MILESTONES --------------------- Call for Papers Opens: 2 November 2015 Draft Program Published: As Papers Confirmed Final Deadline for Submissions: 25 January 2016 Final Program Published: 1 February 2016 Final Slides Received: 8 February 2016 **NOTE THAT REGARDLESS OF DEADLINES SLOTS ARE FILLED ON A FIRST COME, FIRST SERVED BASIS*** PROGRAMME MATERIAL ------------------ The APRICOT Programme is organised in three parts, including workshops, tutorials and the conference. Topics for tutorials and the conference must be relevant to Internet Operations and Technologies: - IPv4 / IPv6 Routing and operations - IPv6 deployment and transition technologies - Internet backbone operations - ISP and Carrier services - IXPs and Peering - Research on Internet Operations and Deployment - Pacific/Oceania Internet - Software Defined Networking / Network Function Virtualisaton - Network security issues (NSP-SEC, DDoS, Anti-Spam, Anti-Malware) - DNS / DNSSEC - Internet policy (Security, Regulation, Content Management, Addressing, etc) - Access and Transport Technologies, including Cable/DSL, 3G/LTE, wireless, metro ethernet, fibre, MPLS - Content & Service Delivery (Multicast, Voice, Video, "telepresence", Gaming) and Cloud Computing CfP SUBMISSION -------------- Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions otherwise the Programme Committee will be unable to review the submission. For avoidance of doubt this means that submissions which do not include slides will be rejected immediately. For work in progress, the most current information available at time of submission is acceptable. All draft and complete slides must be submitted in PDF format only. Final slides are to be provided by the specified deadline for publication on the APRICOT website. Prospective presenters should note that the majority of speaking slots will be filled well before the final submission deadline. The PC may, at their discretion, retain a limited number of slots up to the final submission deadline for presentations that are exceptionally timely, important, or of critical operational importance. Every year we turn away submissions, due to filling up all available program slots before the deadline. Presenters should endeavour to get material into the PC sooner rather than later Please submit on-line at: http://papers.apricot.net/user/login.php?event=34 Any questions or concerns should be addressed to the Programme Committee by e-mail at: pc-chairs at apricot.net We look forward to receiving your presentation proposals. Mike Jager & Dean Pemberton Co-Chairs, APRICOT 2016 Programme Committee From inetjunkmail at gmail.com Mon Nov 2 13:11:42 2015 From: inetjunkmail at gmail.com (inetjunkmail) Date: Mon, 2 Nov 2015 08:11:42 -0500 Subject: CIDR Utilization In-Reply-To: References: Message-ID: Learned that attachments do make it to the list. Here's a link: http://pastebin.com/tMdcfvji On Sat, Oct 31, 2015 at 10:29 AM, inetjunkmail wrote: > Attached is a perl script I wrote for a coworker that you can tweak as > you'd like. It's designed to log into a router and dump the route table(s) > and find used/unused subnets in a given supernet. Available routes are > green and used routes are red. Yellow routes are routes where we have > route and a more specific route so the first route is probably an aggregate > and there _may_ be open space available. > > On Fri, Oct 30, 2015 at 8:51 PM, John Steve Nash < > john.steve.nash at gmail.com> wrote: > >> Hi, >> >> I'm looking for any tool or a way I could specify a CIDR and the prefixes >> that are being used within this CIDR and the tool show me all free >> supernets. >> >> Example: >> >> 192.168.0.0/24 - CIDR >> >> Used subnet's: >> >> 192.168.0.1/32 >> 192.168.0.8/27 >> 192.168.0.64/26 >> 192.168.0.68/32 >> 192.168.0.96/29 >> >> Tool Result => Free Subnet's: >> >> 192.168.0.2/31 >> 192.168.0.4/30 >> 192.168.0.32/27 >> 192.168.0.128/25 >> >> Regards, >> >> John >> > > From jmaimon at ttec.com Mon Nov 2 16:23:18 2015 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 02 Nov 2015 11:23:18 -0500 Subject: Traceroute troubleshooting Message-ID: <56378DF6.3090509@ttec.com> So we all know that its much more difficult to diagnose using that tool than just reading its output more often than not. Whats usually more important is correlation, over time and at any specific time. While tools such as mtr provide over time viewpoints, what can be run, user style, that will show packet loss/jitter over successive hops or in some sort of diagnosable pattern, as snapshots of data, when running the tool for some period of time where the long term averages/cumulative numbers will render such events mere statistical noise? Thanks! Joe From jsklein at gmail.com Mon Nov 2 17:14:39 2015 From: jsklein at gmail.com (Joe Klein) Date: Mon, 2 Nov 2015 12:14:39 -0500 Subject: Routing between TATA COMMUNICATIONS and Level 3 Communications, Inc. Message-ID: Found a routing problem between TATA COMMUNICATIONS and Level 3 Communications, Inc. Attempted traceroute from Digital Ocean to FrontRange Internet : traceroute to www.asx.com (2607:fa88:1000:5::a744:a050) from 2604:a880:800:10::1ba:5001, 30 hops max, 24 byte packets 1 2604:a880:800:10:ffff:ffff:ffff:fff2 (2604:a880:800:10:ffff:ffff:ffff:fff2) 2.638 ms 1.354 ms 1.101 ms 2 2604:a880:800::701 (2604:a880:800::701) 0.418 ms 0.338 ms 0.289 ms 3 decix-nyc.he.net (2001:504:36::1b1b:0:1) 11.43 ms 9.492 ms 1.132 ms 4 10ge16-1.core1.nyc4.he.net (2001:470:0:259::1) 10.062 ms 9.559 ms 1.177 ms 5 level3.gige-g3-5.core1.nyc4.he.net (2001:470:0:202::2) 2.989 ms 2.773 ms 1.515 ms 6 2001:1900:19:5::8 (2001:1900:19:5::8) 1.427 ms 1.402 ms 1.344 ms 7 vl-4060.car2.NewYork2.Level3.net (2001:1900:4:1::fe) 1.349 ms 1.332 ms 1.967 ms 8 vl-4061.car1.Chicago1.Level3.net (2001:1900:4:1::21) 22.435 ms 71.92 ms 57.907 ms 9 vl-4040.edge1.Chicago2.Level3.net (2001:1900:4:1::1e) 23.516 ms 23.427 ms 23.414 ms 10 vl-4042.edge6.Denver1.Level3.net (2001:1900:4:1::35) 46.468 ms 46.58 ms 46.779 ms 11 vl-51.ear1.Denver1.Level3.net (2001:1900:13:1::8) 47.678 ms 47.647 ms 47.861 ms 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * Traceroute from the FrontRange Internet to Digital Ocean: traceroute6 2604:a880:800:10::1ba:5001 traceroute to 2604:a880:800:10::1ba:5001 (2604:a880:800:10::1ba:5001), 30 hops max, 80 byte packets 1 2607:fa88:1000:5::fffd (2607:fa88:1000:5::fffd) 0.554 ms 0.471 ms 0.375 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 2001:5a0:3900::3e (2001:5a0:3900::3e) 75.679 ms 78.276 ms 77.441 ms 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Please contact off-line. Joe Klein "Inveniam viam aut faciam" From owen at delong.com Mon Nov 2 18:47:41 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Nov 2015 13:47:41 -0500 Subject: CIDR Utilization In-Reply-To: References: Message-ID: <893BFE22-D252-4032-A44D-92BC7F3F1104@delong.com> The results appear to be missing 192.168.0.0/32. Is this intended behavior? 192.168.0.8/27 is not a valid CIDR ? It actually represents an address within 192.168.0.0/27, so actually, rather than missing 192.168.0.0/32, one could argue that there are erroneous reports for 192.168.0.2/31, 192.168.0.4/30 being available. 192.168.0.64/26 encompasses 192.168.0.68/32 and 192.168.0.96/29, so there?s also an allocation conflict potential there. I thought I understood what you were looking for from your question, but your example creates significant confusion. Owen > On Oct 30, 2015, at 8:51 PM, John Steve Nash wrote: > > Hi, > > I'm looking for any tool or a way I could specify a CIDR and the prefixes > that are being used within this CIDR and the tool show me all free > supernets. > > Example: > > 192.168.0.0/24 - CIDR > > Used subnet's: > > 192.168.0.1/32 > 192.168.0.8/27 > 192.168.0.64/26 > 192.168.0.68/32 > 192.168.0.96/29 > > Tool Result => Free Subnet's: > > 192.168.0.2/31 > 192.168.0.4/30 > 192.168.0.32/27 > 192.168.0.128/25 > > Regards, > > John From nanog-isp at mail.com Mon Nov 2 11:53:02 2015 From: nanog-isp at mail.com (nanog-isp at mail.com) Date: Mon, 2 Nov 2015 12:53:02 +0100 Subject: New ISPs getting of the ground without IPv4? Message-ID: Surprisingly enough demand for Internet services did not end when we ran out of IPv4. I'd like to hear from the guys and gals starting new ISPs how they are facing this brave new world. Is it NATs all the way down? Is IPv6 the knight in shining armor? Are you getting enough IPs? If not, how are you coping? Buying/renting some, tunneling to somebody who has some, what? It's all good and well hearing about how you should dual stack and reading about how established players handle IPv6 and IPv4 exhaustion, but what do you do when dual stacking isn't an option and IPv6 only takes you so far? Now is your chance to shine and bring us some tales from the trenches :) Jared From ythomas at castle-it.fr Mon Nov 2 07:53:56 2015 From: ythomas at castle-it.fr (Yoann THOMAS) Date: Mon, 2 Nov 2015 08:53:56 +0100 Subject: [TECH] Pica8 & Cumulus Networks Message-ID: <56371694.4080904@castle-it.fr> Hello everyone, Under a Cloud project I ask myself to use equipment based on the Pica8 or Cumulus Networks. All in order to mount a Spine & Leaf architecture - Spine 40Gbps - Leaf in 10Gbps Someone of you there a feedback on this equipment. Regards, Yoann THOMAS CTO - Castle-IT From dcorbe at hammerfiber.com Mon Nov 2 19:32:19 2015 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Mon, 02 Nov 2015 14:32:19 -0500 Subject: New ISPs getting of the ground without IPv4? In-Reply-To: (nanog-isp@mail.com's message of "Mon, 2 Nov 2015 12:53:02 +0100") References: Message-ID: <87si4oi4e4.fsf@corbe.net> nanog-isp at mail.com writes: > Surprisingly enough demand for Internet services did not end when we > ran out of IPv4. I'd like to hear from the guys and gals starting new > ISPs how they are facing this brave new world. I can help. We're a cable company operating in Atlantic City who hope to have 800 beta customers launched between November 30 and February 1. > > Is it NATs all the way down? We've got two large NAT pools and a /24 set aside for customers who must absolutely be globally routable for IPv4. We're trying to qualify as few customers for this need as possible. > > Is IPv6 the knight in shining armor? We're going to try to deploy as many people as we can as native IPv6-only customers but we also expect there to be a considerable amount of protest to this idea. In which case, we'd simply turn IPv4 on for them and NAT them. It's disgusting how much stuff out there still doesn't support IPv6. We're all ready for that with NAT64 on the edge for sites like twitter and 464XLAT for devices that support it. But just off the top of my head, we know we're going to run into problems with people's XBox 360s and anyone who uses PSN (that's all PS3 and PS4 users as of this writing), Skype, Android on wifi, etc. > > Are you getting enough IPs? If not, how are you coping? Buying/renting > some, tunneling to somebody who has some, what? We wish we had enough address space to give everyone a globally routable IPv4 address; alas, we don't. We're on ARIN's waiting list. We're also trolling the transfer market and keeping our eyes open for anyone who might like to put their company up for sale for its resources and revenue. > > It's all good and well hearing about how you should dual stack and > reading about how established players handle IPv6 and IPv4 exhaustion, > but what do you do when dual stacking isn't an option and IPv6 only > takes you so far? We're just going to limp along as best we can until the rest of the world wises up. BTW, hardware NAT costs $$$. So the barrier for entry is pretty high right now. From egon at egon.cc Mon Nov 2 20:19:04 2015 From: egon at egon.cc (James Downs) Date: Mon, 2 Nov 2015 12:19:04 -0800 Subject: [TECH] Pica8 & Cumulus Networks In-Reply-To: <56371694.4080904@castle-it.fr> References: <56371694.4080904@castle-it.fr> Message-ID: > On Nov 1, 2015, at 23:53, Yoann THOMAS wrote: > Under a Cloud project I ask myself to use equipment based on the Pica8 or Cumulus Networks. We?ve had some great conversations with Cumulus, but more generally, I think you need to look at the cloud project?s goals. Those should help inform your decision making process. Specifically, what are your SDN and generally, networking needs and use cases. > All in order to mount a Spine & Leaf architecture > > - Spine 40Gbps > - Leaf in 10Gbps In a new cloud deployment of any size, you probably want more than 10G to the compute servers, especially if you?re carrying storage traffic. > > Someone of you there a feedback on this equipment. > > Regards, > > Yoann THOMAS > CTO - Castle-IT Cheers, -j From tom at ninjabadger.net Mon Nov 2 21:07:35 2015 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 2 Nov 2015 21:07:35 +0000 Subject: Routing between TATA COMMUNICATIONS and Level 3 Communications, Inc. In-Reply-To: References: Message-ID: <5637D097.3080803@ninjabadger.net> On 02/11/15 17:14, Joe Klein wrote: > Found a routing problem between TATA COMMUNICATIONS LOUD NOISES -- Tom From simon.leinen at switch.ch Mon Nov 2 21:52:49 2015 From: simon.leinen at switch.ch (Simon Leinen) Date: Mon, 02 Nov 2015 22:52:49 +0100 Subject: [TECH] Pica8 & Cumulus Networks In-Reply-To: <56371694.4080904@castle-it.fr> (Yoann THOMAS's message of "Mon, 2 Nov 2015 08:53:56 +0100") References: <56371694.4080904@castle-it.fr> Message-ID: Yoann THOMAS writes: > Under a Cloud project I ask myself to use equipment based on the Pica8 > or Cumulus Networks. Ah, quite different beasts. Cumulus Networks tries to really make the switch look like a Linux system with hardware-accelerated forwarding, so you can use stock programs that manipulate routing, e.g. Quagga, and all forwarding between the high-speed ports is done "in hardware". Most other systems including Pica8 treat the high-speed interfaces as different; you need special software to manipulate the configuration of the forwarding ASIC. I think in the case of Pica8 it's OpenFlow/Open vSwitch, for other systems it will be some sort of a ASIC-specific SDK. A colleague has built a proof-of-concept L3 leaf/spine network (using OSPFv2/OSPFv3 according to local tradition) with six 32x40GE Quanta switches running Cumulus Linux. So far it has been quite pleasant. There have been a few glitches, but those usually get fixed pretty quickly. We configure the switches very much like GNU/Linux servers, in our case using Puppet (Ansible or Chef would work just as well). > All in order to mount a Spine & Leaf architecture > - Spine 40Gbps > - Leaf in 10Gbps One interesting option is to get (e.g. 1RU 32x) 40G switches for both spine and leaf, and connect the servers using 1:4 break-out cables. Fewer SKUs, better port density at the cost of funny cabling. Also gives you a bit more flexibility with respect to uplinks (can have more than 6*40GE per leaf if needed) and downlinks (easy to connect some servers at 40GE). The new 32*100GE switches also look interesting, but they might still be prohibitively expensive (although you can save on spine count and cabling) unless you NEED the bandwidth or want to build something future-proof. They are even more flexible in that you can drive the ports as 4*10GE, 4*25GE (could be an attractive high-speed option once 25GE server adapters become common), 40GE, 2*50GE, 100GE. We have looked at Edge-Core and Quanta and they both look pretty solid. I think they are also both used by some of the Web "hypergiants". Others may be just as good - basically it's always the same Broadcom switching silicon (Trident II/II+ in the 40GE, Tomahawk in the 100GE switches) with a bit of glue; there may be subtle differences between vendors in quality, box design, airflow etc. It's a bit unhealthy that Broadcom is so dominant in this market - but probably not undeserved. There are a few alternative switching chipsets, e.g. Mellanox, Cavium XPliant that look competitive (at least on paper) and that may be more "open" than Broadcom's. I think both the software vendors (e.g. Cumulus Networks) and the ODMs (Edge-Core, Quanta etc.) are interested in these. -- Simon. From baldur.norddahl at gmail.com Mon Nov 2 21:57:22 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 2 Nov 2015 22:57:22 +0100 Subject: New ISPs getting of the ground without IPv4? In-Reply-To: References: Message-ID: On 2 November 2015 at 12:53, wrote: > Surprisingly enough demand for Internet services did not end when we ran > out of IPv4. I'd like to hear from the guys and gals starting new ISPs how > they are facing this brave new world. > > Is it NATs all the way down? > No NAT. > > Is IPv6 the knight in shining armor? > We have IPv6 (dual stack) but mostly because it is the right thing to do and a few tech savvy customers appreciate it. > > Are you getting enough IPs? If not, how are you coping? Buying/renting > some, tunneling to somebody who has some, what? > We buy them at approx $10 each. This is of course a burden. However we have many costs in establishing a new customer. Our GPON ONU is much more than the cost to get the IP-address. > It's all good and well hearing about how you should dual stack and reading > about how established players handle IPv6 and IPv4 exhaustion, but what do > you do when dual stacking isn't an option and IPv6 only takes you so far? > I do not know how to answer that given that dual stack _is_ an option. We have two basic options. One is to buy address space. The other is NAT. Neither is free. We came to the conclusion that buying address space is the best option for us. We believe that NAT would cause some customers to choose a different ISP and that NAT can be almost as expensive per customer if you factor in all costs. I am still not too worried about the price of IPv4 address space. Many companies have huge amounts of space that can be reclaimed and sold off. This is especially true in the ARIN region. IPv4 space will always be available, it is just a matter of how expensive it will be. I hope that IPv6 becomes more widespread in the coming years. That should lead to less customers that care about a global routable IPv4 address . As a larger fraction of the traffic moves to IPv6 the carrier NAT solution will scale better. Regards, Baldur From lists at mtin.net Mon Nov 2 22:36:27 2015 From: lists at mtin.net (Justin Wilson - MTIN) Date: Mon, 2 Nov 2015 17:36:27 -0500 Subject: New ISPs getting of the ground without IPv4? In-Reply-To: References: Message-ID: <0FC12642-39F4-431B-B93C-F6CF1AFB4B65@mtin.net> The two I am working with are factoring buying IP space as part of the business model. Folks like Cogent are now charging a $50 BGP fee so it is a new world. I am seeing more and more folks go to MPLS to try and squeeze as many IPs out as they can. They are flattening their customer pools and saving a few IPs here and there. A couple others are paying for circuits they no longer use just to hold onto IP space. Justin Wilson j2sw at mtin.net --- http://www.mtin.net Owner/CEO xISP Solutions- Consulting ? Data Centers - Bandwidth http://www.midwest-ix.com COO/Chairman Internet Exchange - Peering - Distributed Fabric > On Nov 2, 2015, at 6:53 AM, nanog-isp at mail.com wrote: > > Surprisingly enough demand for Internet services did not end when we ran out of IPv4. I'd like to hear from the guys and gals starting new ISPs how they are facing this brave new world. > > Is it NATs all the way down? > > Is IPv6 the knight in shining armor? > > Are you getting enough IPs? If not, how are you coping? Buying/renting some, tunneling to somebody who has some, what? > > It's all good and well hearing about how you should dual stack and reading about how established players handle IPv6 and IPv4 exhaustion, but what do you do when dual stacking isn't an option and IPv6 only takes you so far? > > Now is your chance to shine and bring us some tales from the trenches :) > > Jared > From ian.clark at dreamhost.com Tue Nov 3 00:35:02 2015 From: ian.clark at dreamhost.com (Ian Clark) Date: Mon, 2 Nov 2015 16:35:02 -0800 Subject: [TECH] Pica8 & Cumulus Networks In-Reply-To: <56371694.4080904@castle-it.fr> References: <56371694.4080904@castle-it.fr> Message-ID: On Sun, Nov 1, 2015 at 11:53 PM, Yoann THOMAS wrote: > Hello everyone, > > Under a Cloud project I ask myself to use equipment based on the Pica8 or > Cumulus Networks. > > All in order to mount a Spine & Leaf architecture > > - Spine 40Gbps > - Leaf in 10Gbps > > Someone of you there a feedback on this equipment. > We've had a lot of success running Cumulus gear in cloudy production environments. They're easy to manage with infrastructure automation tools and perform as well as any other switch with the same hardware. There are a few features missing from the current general availability code (VRF is the main one for us), but the guys and gals at Cumulus are pretty responsive to requests for new features and I know that VRF is on its way. The main advantage IMO is the huge price break for 10g and 40g ports when compared with the other major players. -- Ian Clark Lead Network Engineer DreamHost From tony at wicks.co.nz Tue Nov 3 01:20:43 2015 From: tony at wicks.co.nz (Tony Wicks) Date: Tue, 3 Nov 2015 14:20:43 +1300 Subject: New ISPs getting of the ground without IPv4? In-Reply-To: References: Message-ID: <4a1a01d115d5$dd764cb0$9862e610$@wicks.co.nz> >-----Original Message----- > >Surprisingly enough demand for Internet services did not end when we ran out of IPv4. I'd like to hear from the guys and gals starting new ISPs how they are facing this brave new world. > Well, APNIC ran out years ago, so as someone with experience running a residential ISP with very limited IPv4 I can tell you that the overwhelming majority of customers don't know or care that they are running behind CGNAT as long as you are upfront about it (in the FAQ's, no you can't run a server on this service). One /24 is good for about 16k broadband users without major issues (apart from dealing with random blocks by our "friends" at "playstation"). Overall it just works and nobody notices. You will want a good DDOS scrubbing solution though as you can't just block a destination IP that happens to be in one of your IP pools. From jason.iannone at gmail.com Tue Nov 3 01:35:24 2015 From: jason.iannone at gmail.com (Jason Iannone) Date: Mon, 2 Nov 2015 17:35:24 -0800 Subject: Traceroute troubleshooting In-Reply-To: <56378DF6.3090509@ttec.com> References: <56378DF6.3090509@ttec.com> Message-ID: If your vendors support it, doing stuff in-box is nice: ITU-T Y.1731. If you're looking for an off box solution, PerfSONAR is actively developed. You need some kind of ownership of all test points for configuration and reporting for both solutions. On Mon, Nov 2, 2015 at 8:23 AM, Joe Maimon wrote: > So we all know that its much more difficult to diagnose using that tool than > just reading its output more often than not. > > Whats usually more important is correlation, over time and at any specific > time. > > While tools such as mtr provide over time viewpoints, what can be run, user > style, that will show packet loss/jitter over successive hops or in some > sort of diagnosable pattern, as snapshots of data, when running the tool for > some period of time where the long term averages/cumulative numbers will > render such events mere statistical noise? > > Thanks! > > Joe From frnkblk at iname.com Tue Nov 3 04:35:19 2015 From: frnkblk at iname.com (frnkblk at iname.com) Date: Mon, 2 Nov 2015 22:35:19 -0600 Subject: Two IPv6 websites down In-Reply-To: <002501d113ec$88b332f0$9a1998d0$@iname.com> References: <002501d113ec$88b332f0$9a1998d0$@iname.com> Message-ID: <000f01d115f1$1e743950$5b5cabf0$@iname.com> Without disclosing too much, I learned from a person within BT's broader organization that the removal of AAAA for www.bt.com was intentional for troubleshooting purposes. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of frnkblk at iname.com Sent: Saturday, October 31, 2015 9:58 AM To: nanog at nanog.org Subject: Two IPv6 websites down My regular BT and CTL link contacts have not responded, but perhaps there's another engineer on the list that can investigate. www.bt.com hasn't had an AAAA since Friday, October 30 at 4:36 am (U.S. Central). OpenDNS carried it for a while longer yesterday, but when I checked this morning it was gone. www.centurylink.com (and www.qwest.com) have had HTTPv6 access down since Friday, October 30 at 1:21 am (U.S. Central). I suspect that after maintenance something wasn't fixed up or restored. In addition, the following sites, which had working HTTPv6 at one time, remain down: enterprise.ca cs.co mydeviceinfo.comcast.net www.dnssec.comcast.net wireless.att.com www.att.net (Akamai hosted) www.charter.com www.twtelecom.com Regards, Frank root at nagios:/home/fbulk# wget -6 www.centurylink.com --2015-10-31 09:53:13-- http://www.centurylink.com/ Resolving www.centurylink.com... 2001:428:b21:1::20 Connecting to www.centurylink.com|2001:428:b21:1::20|:80... failed: Connection timed out. Retrying. --2015-10-31 09:53:35-- (try: 2) http://www.centurylink.com/ Connecting to www.centurylink.com|2001:428:b21:1::20|:80... failed: Connection timed out. Retrying. --2015-10-31 09:53:58-- (try: 3) http://www.centurylink.com/ Connecting to www.centurylink.com|2001:428:b21:1::20|:80... failed: Connection timed out. Retrying. --2015-10-31 09:54:22-- (try: 4) http://www.centurylink.com/ Connecting to www.centurylink.com|2001:428:b21:1::20|:80... failed: Connection timed out. Retrying. --2015-10-31 09:54:47-- (try: 5) http://www.centurylink.com/ Connecting to www.centurylink.com|2001:428:b21:1::20|:80... failed: Connection timed out. Retrying. --2015-10-31 09:55:13-- (try: 6) http://www.centurylink.com/ Connecting to www.centurylink.com|2001:428:b21:1::20|:80... ^C root at nagios:/home/fbulk# From meirea at charterschoolit.com Wed Nov 4 17:33:21 2015 From: meirea at charterschoolit.com (Mario Eirea) Date: Wed, 4 Nov 2015 17:33:21 +0000 Subject: DDoS Mitigation Message-ID: Hello everyone, Looking to find out how the pricing model works for DDoS mitigation and what to expect as far as ballpark pricing from my ISP. Some background, we are getting hit with a chargen attack that comes and goes and is saturating our 500mb connection. Tried hitting up the ISP for UDP block on 19 but they want us to go through our rep, in the process making this go on longer that is necessary. Any feedback would be appreciated. Thanks, -ME From paras at protrafsolutions.com Wed Nov 4 18:10:52 2015 From: paras at protrafsolutions.com (Paras) Date: Wed, 4 Nov 2015 13:10:52 -0500 Subject: DDoS Mitigation In-Reply-To: References: Message-ID: <563A4A2C.8040700@protrafsolutions.com> Hey, Just blocking port 19 won't cut it, as we often see Chargen attacks that run on nonstandard ports as well Thanks, Paras On 11/4/2015 12:33 PM, Mario Eirea wrote: > Hello everyone, > > Looking to find out how the pricing model works for DDoS mitigation and what to expect as far as ballpark pricing from my ISP. Some background, we are getting hit with a chargen attack that comes and goes and is saturating our 500mb connection. Tried hitting up the ISP for UDP block on 19 but they want us to go through our rep, in the process making this go on longer that is necessary. Any feedback would be appreciated. > > Thanks, > > -ME From Sam at SanDiegoBroadband.com Wed Nov 4 17:53:09 2015 From: Sam at SanDiegoBroadband.com (Sam Norris) Date: Wed, 4 Nov 2015 09:53:09 -0800 Subject: AT&T Wholesale Message-ID: <151701d11729$acafdec0$060f9c40$@SanDiegoBroadband.com> Hey everyone, Can someone send me privately the contact info for an AT&T Wholesale rep for Metro E / VPLS / Layer 2 stuff here in the SouthWest region? Their website is not very informative on how to make any contact with the wholesale group. Thx, Sam From joe at breathe-underwater.com Wed Nov 4 22:54:16 2015 From: joe at breathe-underwater.com (Joseph Jenkins) Date: Wed, 4 Nov 2015 14:54:16 -0800 Subject: DDoS Mitigation In-Reply-To: References: Message-ID: <68E76335-2406-4154-B2C3-B35D3052E4AB@breathe-underwater.com> Depends on the service, you might have better luck with versign or prolexic and they can get the services up and running quickly. Joe Jenkins 909.636.2097 > On Nov 4, 2015, at 9:33 AM, Mario Eirea wrote: > > Hello everyone, > > Looking to find out how the pricing model works for DDoS mitigation and what to expect as far as ballpark pricing from my ISP. Some background, we are getting hit with a chargen attack that comes and goes and is saturating our 500mb connection. Tried hitting up the ISP for UDP block on 19 but they want us to go through our rep, in the process making this go on longer that is necessary. Any feedback would be appreciated. > > Thanks, > > -ME From jtin at akamai.com Wed Nov 4 22:12:43 2015 From: jtin at akamai.com (Tin, James) Date: Wed, 4 Nov 2015 22:12:43 +0000 Subject: DDoS Mitigation In-Reply-To: <563A4A2C.8040700@protrafsolutions.com> References: , <563A4A2C.8040700@protrafsolutions.com> Message-ID: <152DBDF5-199A-478F-B329-0D0F6F2FD3E8@akamai.com> This is my first post to Nanog. So please don't flame me down ;) Hi Mario. Typically the cost of Ddos mitigation is charged on the amount of clean traffic inbound to your network, the number of protected /24 ranges you need protected and the number of datacentres you want to protect. Ideally the Ddos mitigation solution should block attacks as close as possible to the source of the attack. One good way of doing this is by leveraging anycast from multiple scrubbing centres and ensure there is enough backbone bandwidth between each scrubbing centre to deliver clean traffic. Blocking it at your upstream transit provider may be too late for significant attacks as any service provider between you and the source could black hole the traffic before it gets to your peers. This results in legitimate traffic not being able to reach your network. Paras is correct, attacks could be on any port and often multivector and change within an attack campaign if attackers see one vector is not effective. So each attack really needs to be dealt with dynamically to ensure there are no false positives (something is blocked when it shouldn't be) Unfortunately it is very simple to intimate a Ddos attack, but the cost of mitigation is very high. So the solution you choose really depends on the monetary cost of the outages, clients you have and whether the cost can be amortised over your client base. I have seen service providers offer premium hosting services which have Ddos mitigation, using separate infrastructure and links to their normal customers. This reduces the cost of mitigation while also containing the risks and the collateral damage. There are also different Ddos mitigation solutions depending on the service protocols your are offering. Ie web traffic could be mitigated with cdn vs all protocols and ports with BGP via a scrubbing centre. Sent from my iPhone James Tin Enterprise Security Architect APJ Join the Conversation. Log on to Akamai Community. [http://www.akamai.com/images/img/community-icon-large.png] [http://www.akamai.com/images/img/bg/akamai-logo.png] Office: +61 9008 4906 Cell: +61 466 961 555 Akamai Technologies Level 7, 76 Berry St North Sydney, NSW 2071 Connect with Us: [http://www.akamai.com/images/img/akamai-community-icon.jpg] [http://www.akamai.com/graphics/misc/rs_icon_small.png] [http://www.akamai.com/graphics/misc/tw_icon_small.png] [http://www.akamai.com/graphics/misc/fb_icon_small.png] [http://www.akamai.com/graphics/misc/in_icon_small.png] [http://www.akamai.com/graphics/misc/yt_icon_small.png] On 5 Nov 2015, at 05:13, Paras > wrote: Hey, Just blocking port 19 won't cut it, as we often see Chargen attacks that run on nonstandard ports as well Thanks, Paras On 11/4/2015 12:33 PM, Mario Eirea wrote: Hello everyone, Looking to find out how the pricing model works for DDoS mitigation and what to expect as far as ballpark pricing from my ISP. Some background, we are getting hit with a chargen attack that comes and goes and is saturating our 500mb connection. Tried hitting up the ISP for UDP block on 19 but they want us to go through our rep, in the process making this go on longer that is necessary. Any feedback would be appreciated. Thanks, -ME From morrowc.lists at gmail.com Thu Nov 5 00:27:04 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 5 Nov 2015 11:27:04 +1100 Subject: DDoS Mitigation In-Reply-To: <152DBDF5-199A-478F-B329-0D0F6F2FD3E8@akamai.com> References: <563A4A2C.8040700@protrafsolutions.com> <152DBDF5-199A-478F-B329-0D0F6F2FD3E8@akamai.com> Message-ID: a short answer for the OP is: "Find an ISP that will actually support you" there are quite a few in the US that will filter traffic like this for you (vzb will) on demand, provided the traffic is service impacting and NOT 'victoria secret runway show' traffic. alternately you could find an ISP that has a mitigation service (vzb, att, ntt, sprint i think still does) and move your links there. All of those are cheaper when under attack than the off-netork solutions (generally). On Thu, Nov 5, 2015 at 9:12 AM, Tin, James wrote: > This is my first post to Nanog. So please don't flame me down ;) > > Hi Mario. > > Typically the cost of Ddos mitigation is charged on the amount of clean traffic inbound to your network, the number of protected /24 ranges you need protected and the number of datacentres you want to protect. > > Ideally the Ddos mitigation solution should block attacks as close as possible to the source of the attack. One good way of doing this is by leveraging anycast from multiple scrubbing centres and ensure there is enough backbone bandwidth between each scrubbing centre to deliver clean traffic. > > Blocking it at your upstream transit provider may be too late for significant attacks as any service provider between you and the source could black hole the traffic before it gets to your peers. This results in legitimate traffic not being able to reach your network. > > Paras is correct, attacks could be on any port and often multivector and change within an attack campaign if attackers see one vector is not effective. So each attack really needs to be dealt with dynamically to ensure there are no false positives (something is blocked when it shouldn't be) > > Unfortunately it is very simple to intimate a Ddos attack, but the cost of mitigation is very high. So the solution you choose really depends on the monetary cost of the outages, clients you have and whether the cost can be amortised over your client base. > > I have seen service providers offer premium hosting services which have Ddos mitigation, using separate infrastructure and links to their normal customers. This reduces the cost of mitigation while also containing the risks and the collateral damage. > > There are also different Ddos mitigation solutions depending on the service protocols your are offering. Ie web traffic could be mitigated with cdn vs all protocols and ports with BGP via a scrubbing centre. > > Sent from my iPhone > James Tin > Enterprise Security Architect APJ > Join the Conversation. > Log on to Akamai Community. [http://www.akamai.com/images/img/community-icon-large.png] > > [http://www.akamai.com/images/img/bg/akamai-logo.png] > > Office: +61 9008 4906 > Cell: +61 466 961 555 > Akamai Technologies > Level 7, 76 Berry St > North Sydney, NSW 2071 > > Connect with Us: [http://www.akamai.com/images/img/akamai-community-icon.jpg] [http://www.akamai.com/graphics/misc/rs_icon_small.png] [http://www.akamai.com/graphics/misc/tw_icon_small.png] [http://www.akamai.com/graphics/misc/fb_icon_small.png] [http://www.akamai.com/graphics/misc/in_icon_small.png] [http://www.akamai.com/graphics/misc/yt_icon_small.png] > > > > > On 5 Nov 2015, at 05:13, Paras > wrote: > > Hey, > > Just blocking port 19 won't cut it, as we often see Chargen attacks that run on nonstandard ports as well > > Thanks, > Paras > > On 11/4/2015 12:33 PM, Mario Eirea wrote: > Hello everyone, > > Looking to find out how the pricing model works for DDoS mitigation and what to expect as far as ballpark pricing from my ISP. Some background, we are getting hit with a chargen attack that comes and goes and is saturating our 500mb connection. Tried hitting up the ISP for UDP block on 19 but they want us to go through our rep, in the process making this go on longer that is necessary. Any feedback would be appreciated. > > Thanks, > > -ME > > From paras at protrafsolutions.com Thu Nov 5 08:03:41 2015 From: paras at protrafsolutions.com (Paras) Date: Thu, 5 Nov 2015 03:03:41 -0500 Subject: Internap route optimization Message-ID: <563B0D5D.5000705@protrafsolutions.com> Does anyone know or have any experience with Internap's route optimization? Is it any good? I've heard of competing solutions as well, such as the one provided by Noction. Thanks for your input, Paras From pavel.odintsov at gmail.com Thu Nov 5 08:50:56 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Thu, 5 Nov 2015 11:50:56 +0300 Subject: DDoS Mitigation In-Reply-To: References: <563A4A2C.8040700@protrafsolutions.com> <152DBDF5-199A-478F-B329-0D0F6F2FD3E8@akamai.com> Message-ID: Hello, Christopher! Could you share "there are quite a few in the US that will filter traffic like this for you" off-list? On Thu, Nov 5, 2015 at 3:27 AM, Christopher Morrow wrote: > a short answer for the OP is: "Find an ISP that will actually support you" > > there are quite a few in the US that will filter traffic like this for > you (vzb will) on demand, provided the traffic is service impacting > and NOT 'victoria secret runway show' traffic. > > alternately you could find an ISP that has a mitigation service (vzb, > att, ntt, sprint i think still does) and move your links there. > > All of those are cheaper when under attack than the off-netork > solutions (generally). > > On Thu, Nov 5, 2015 at 9:12 AM, Tin, James wrote: >> This is my first post to Nanog. So please don't flame me down ;) >> >> Hi Mario. >> >> Typically the cost of Ddos mitigation is charged on the amount of clean traffic inbound to your network, the number of protected /24 ranges you need protected and the number of datacentres you want to protect. >> >> Ideally the Ddos mitigation solution should block attacks as close as possible to the source of the attack. One good way of doing this is by leveraging anycast from multiple scrubbing centres and ensure there is enough backbone bandwidth between each scrubbing centre to deliver clean traffic. >> >> Blocking it at your upstream transit provider may be too late for significant attacks as any service provider between you and the source could black hole the traffic before it gets to your peers. This results in legitimate traffic not being able to reach your network. >> >> Paras is correct, attacks could be on any port and often multivector and change within an attack campaign if attackers see one vector is not effective. So each attack really needs to be dealt with dynamically to ensure there are no false positives (something is blocked when it shouldn't be) >> >> Unfortunately it is very simple to intimate a Ddos attack, but the cost of mitigation is very high. So the solution you choose really depends on the monetary cost of the outages, clients you have and whether the cost can be amortised over your client base. >> >> I have seen service providers offer premium hosting services which have Ddos mitigation, using separate infrastructure and links to their normal customers. This reduces the cost of mitigation while also containing the risks and the collateral damage. >> >> There are also different Ddos mitigation solutions depending on the service protocols your are offering. Ie web traffic could be mitigated with cdn vs all protocols and ports with BGP via a scrubbing centre. >> >> Sent from my iPhone >> James Tin >> Enterprise Security Architect APJ >> Join the Conversation. >> Log on to Akamai Community. [http://www.akamai.com/images/img/community-icon-large.png] >> >> [http://www.akamai.com/images/img/bg/akamai-logo.png] >> >> Office: +61 9008 4906 >> Cell: +61 466 961 555 >> Akamai Technologies >> Level 7, 76 Berry St >> North Sydney, NSW 2071 >> >> Connect with Us: [http://www.akamai.com/images/img/akamai-community-icon.jpg] [http://www.akamai.com/graphics/misc/rs_icon_small.png] [http://www.akamai.com/graphics/misc/tw_icon_small.png] [http://www.akamai.com/graphics/misc/fb_icon_small.png] [http://www.akamai.com/graphics/misc/in_icon_small.png] [http://www.akamai.com/graphics/misc/yt_icon_small.png] >> >> >> >> >> On 5 Nov 2015, at 05:13, Paras > wrote: >> >> Hey, >> >> Just blocking port 19 won't cut it, as we often see Chargen attacks that run on nonstandard ports as well >> >> Thanks, >> Paras >> >> On 11/4/2015 12:33 PM, Mario Eirea wrote: >> Hello everyone, >> >> Looking to find out how the pricing model works for DDoS mitigation and what to expect as far as ballpark pricing from my ISP. Some background, we are getting hit with a chargen attack that comes and goes and is saturating our 500mb connection. Tried hitting up the ISP for UDP block on 19 but they want us to go through our rep, in the process making this go on longer that is necessary. Any feedback would be appreciated. >> >> Thanks, >> >> -ME >> >> -- Sincerely yours, Pavel Odintsov From fred at web2objects.com Thu Nov 5 09:53:51 2015 From: fred at web2objects.com (Fred Hollis) Date: Thu, 5 Nov 2015 10:53:51 +0100 Subject: Internap route optimization In-Reply-To: <563B0D5D.5000705@protrafsolutions.com> References: <563B0D5D.5000705@protrafsolutions.com> Message-ID: <563B272F.4090705@web2objects.com> Hi, No particular experience with Internaps optimization...however I wouldn't be that sure if I would use it within our networks, because you always have the conflict of this not being their core business as they want to sell their optimized IP transit. However, some time ago we tried Border6 in an evaluation and then finally put it into production. Not only the optimization is nice, but the reporting is so extremely detailed making it very transparent where the transit has congestion issues and which prefix is routed (in and out) through which upstream. For sure traffic engineering/optimization is not a trivial task but requires deep thinking and understanding of the whole BGP and routing picture. On 05.11.2015 at 09:03 Paras wrote: > Does anyone know or have any experience with Internap's route > optimization? Is it any good? > > I've heard of competing solutions as well, such as the one provided by > Noction. > > Thanks for your input, > Paras > From morrowc.lists at gmail.com Thu Nov 5 10:01:35 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 5 Nov 2015 21:01:35 +1100 Subject: Internap route optimization In-Reply-To: <563B272F.4090705@web2objects.com> References: <563B0D5D.5000705@protrafsolutions.com> <563B272F.4090705@web2objects.com> Message-ID: Also, please, if you use one of this sort of device filter your prefixes toward your customers/peers/transits... Do not be the next person to leak their internap-box-routes to the world, m'kay? :) On Thu, Nov 5, 2015 at 8:53 PM, Fred Hollis wrote: > Hi, > > No particular experience with Internaps optimization...however I wouldn't be > that sure if I would use it within our networks, because you always have the > conflict of this not being their core business as they want to sell their > optimized IP transit. > > However, some time ago we tried Border6 in an evaluation and then finally > put it into production. Not only the optimization is nice, but the reporting > is so extremely detailed making it very transparent where the transit has > congestion issues and which prefix is routed (in and out) through which > upstream. > > For sure traffic engineering/optimization is not a trivial task but requires > deep thinking and understanding of the whole BGP and routing picture. > > > On 05.11.2015 at 09:03 Paras wrote: >> >> Does anyone know or have any experience with Internap's route >> optimization? Is it any good? >> >> I've heard of competing solutions as well, such as the one provided by >> Noction. >> >> Thanks for your input, >> Paras >> > From fred at web2objects.com Thu Nov 5 10:05:00 2015 From: fred at web2objects.com (Fred Hollis) Date: Thu, 5 Nov 2015 11:05:00 +0100 Subject: Internap route optimization In-Reply-To: References: <563B0D5D.5000705@protrafsolutions.com> <563B272F.4090705@web2objects.com> Message-ID: <563B29CC.9060300@web2objects.com> Totally right! That's why I wrote >> For sure traffic engineering/optimization is not a trivial task but requires >> deep thinking and understanding of the whole BGP and routing picture. ;) On 05.11.2015 at 11:01 Christopher Morrow wrote: > Also, please, if you use one of this sort of device filter your > prefixes toward your customers/peers/transits... Do not be the next > person to leak their internap-box-routes to the world, m'kay? :) > > On Thu, Nov 5, 2015 at 8:53 PM, Fred Hollis wrote: >> Hi, >> >> No particular experience with Internaps optimization...however I wouldn't be >> that sure if I would use it within our networks, because you always have the >> conflict of this not being their core business as they want to sell their >> optimized IP transit. >> >> However, some time ago we tried Border6 in an evaluation and then finally >> put it into production. Not only the optimization is nice, but the reporting >> is so extremely detailed making it very transparent where the transit has >> congestion issues and which prefix is routed (in and out) through which >> upstream. >> >> For sure traffic engineering/optimization is not a trivial task but requires >> deep thinking and understanding of the whole BGP and routing picture. >> >> >> On 05.11.2015 at 09:03 Paras wrote: >>> >>> Does anyone know or have any experience with Internap's route >>> optimization? Is it any good? >>> >>> I've heard of competing solutions as well, such as the one provided by >>> Noction. >>> >>> Thanks for your input, >>> Paras >>> >> From chip.gwyn at gmail.com Thu Nov 5 12:18:08 2015 From: chip.gwyn at gmail.com (chip) Date: Thu, 5 Nov 2015 07:18:08 -0500 Subject: Internap route optimization In-Reply-To: References: <563B0D5D.5000705@protrafsolutions.com> <563B272F.4090705@web2objects.com> Message-ID: Just to be clear, Internap's solution doesn't use "more specifics" to steer traffic. The mechanisms in place to protect yourself from normal route leaking should apply just the same. --chip On Thu, Nov 5, 2015 at 5:01 AM, Christopher Morrow wrote: > Also, please, if you use one of this sort of device filter your > prefixes toward your customers/peers/transits... Do not be the next > person to leak their internap-box-routes to the world, m'kay? :) > > On Thu, Nov 5, 2015 at 8:53 PM, Fred Hollis wrote: > > Hi, > > > > No particular experience with Internaps optimization...however I > wouldn't be > > that sure if I would use it within our networks, because you always have > the > > conflict of this not being their core business as they want to sell their > > optimized IP transit. > > > > However, some time ago we tried Border6 in an evaluation and then finally > > put it into production. Not only the optimization is nice, but the > reporting > > is so extremely detailed making it very transparent where the transit has > > congestion issues and which prefix is routed (in and out) through which > > upstream. > > > > For sure traffic engineering/optimization is not a trivial task but > requires > > deep thinking and understanding of the whole BGP and routing picture. > > > > > > On 05.11.2015 at 09:03 Paras wrote: > >> > >> Does anyone know or have any experience with Internap's route > >> optimization? Is it any good? > >> > >> I've heard of competing solutions as well, such as the one provided by > >> Noction. > >> > >> Thanks for your input, > >> Paras > >> > > > -- Just my $.02, your mileage may vary, batteries not included, etc.... From nanog at ics-il.net Thu Nov 5 13:21:05 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 5 Nov 2015 07:21:05 -0600 (CST) Subject: Internap route optimization In-Reply-To: <563B0D5D.5000705@protrafsolutions.com> Message-ID: <962573932.10921.1446729692705.JavaMail.mhammett@ThunderFuck> Keep in mind that most do not optimize inbound traffic, only outbound. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Paras" To: nanog at nanog.org Sent: Thursday, November 5, 2015 2:03:41 AM Subject: Internap route optimization Does anyone know or have any experience with Internap's route optimization? Is it any good? I've heard of competing solutions as well, such as the one provided by Noction. Thanks for your input, Paras From eric.sieg at gmail.com Thu Nov 5 13:23:03 2015 From: eric.sieg at gmail.com (Eric Sieg) Date: Thu, 5 Nov 2015 08:23:03 -0500 Subject: Looking for a comcast NOC and/or peering contact Message-ID: If you could contact me off-list, it would be greatly appreciated! -Eric From s+Mailinglisten.nanog at sloc.de Thu Nov 5 13:56:10 2015 From: s+Mailinglisten.nanog at sloc.de (Sebastian Spies) Date: Thu, 5 Nov 2015 14:56:10 +0100 Subject: Internap route optimization In-Reply-To: <962573932.10921.1446729692705.JavaMail.mhammett@ThunderFuck> References: <962573932.10921.1446729692705.JavaMail.mhammett@ThunderFuck> Message-ID: <563B5FFA.8020409@sloc.de> Hey Mike, do you know route optimizers that actually do optimize inbound traffic? We, at datapath.io, are currently working on this and could not find another one that does it. Best, Sebastian Am 05.11.2015 um 14:21 schrieb Mike Hammett: > Keep in mind that most do not optimize inbound traffic, only outbound. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Paras" > To: nanog at nanog.org > Sent: Thursday, November 5, 2015 2:03:41 AM > Subject: Internap route optimization > > Does anyone know or have any experience with Internap's route > optimization? Is it any good? > > I've heard of competing solutions as well, such as the one provided by > Noction. > > Thanks for your input, > Paras > > From fred at web2objects.com Thu Nov 5 14:00:53 2015 From: fred at web2objects.com (Fred Hollis) Date: Thu, 5 Nov 2015 15:00:53 +0100 Subject: Internap route optimization In-Reply-To: <563B5FFA.8020409@sloc.de> References: <962573932.10921.1446729692705.JavaMail.mhammett@ThunderFuck> <563B5FFA.8020409@sloc.de> Message-ID: <563B6115.808@web2objects.com> Border6 offers such an option based on prependings and bgp communities. But honestly, I didn't test that feature yet. And I'm not that sure how much sense it makes since it probably requires quite a lot global BGP updates... makes routers even more busy than they are currently. On 05.11.2015 at 14:56 Sebastian Spies wrote: > Hey Mike, > > do you know route optimizers that actually do optimize inbound traffic? > We, at datapath.io, are currently working on this and could not find > another one that does it. > > Best, > Sebastian > > Am 05.11.2015 um 14:21 schrieb Mike Hammett: >> Keep in mind that most do not optimize inbound traffic, only outbound. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> ----- Original Message ----- >> >> From: "Paras" >> To: nanog at nanog.org >> Sent: Thursday, November 5, 2015 2:03:41 AM >> Subject: Internap route optimization >> >> Does anyone know or have any experience with Internap's route >> optimization? Is it any good? >> >> I've heard of competing solutions as well, such as the one provided by >> Noction. >> >> Thanks for your input, >> Paras >> >> From eric at atlantech.net Thu Nov 5 11:17:33 2015 From: eric at atlantech.net (Eric Van Tol) Date: Thu, 5 Nov 2015 06:17:33 -0500 Subject: Internap route optimization In-Reply-To: <563B0D5D.5000705@protrafsolutions.com> References: <563B0D5D.5000705@protrafsolutions.com> Message-ID: <2C05E949E19A9146AF7BDF9D44085B86720A812942@exchange.aoihq.local> TL;DR: Not worth it unless you have only a few transit providers and are a content-heavy network with little inbound traffic. We used the Internap FCP for a long time (10 or so years). In general, we were satisfied with it, but honestly, after not having it in our network for the past year and a half, we really don't notice a difference. We primarily purchased it to keep transit costs down, but as we kept boosting our minimums with providers, it became less and less about transit costs and more about performance. Boxes like these really work best if your network is a content-heavy network (more outbound than inbound). Sure, it will route around poorly performing paths, but IMO it's not worth the money and yearly maintenance fees just for this. I always said that it must be doing a good job since we never got complaints about packet loss in an upstream network, but now that the device is gone, we still don't get complaints about packet loss in an upstream's network. :-/ The biggest problem that we found was that it just was not actively developed (at the time, not sure about now). New software features were non-existent for years. Bugs were not fixed in a timely manner. Given what we were paying in yearly maintenance fees, it just wasn't worth it to keep around. It also wasn't scalable as we kept adding more transit interfaces, given that there were a fixed amount of capture ports. Adding non-transit peering into the mix was also complicated and messed with the route decision algorithms. Maybe things have changed. As far as technicals, it seemed to work fine. One of the really only annoying things about it were remote users who think that a UDP packet hitting their firewall from its automatic traceroute mechanism were 'DDoS' and threats of lawyers/the wrath of god almighty would come down upon us for sending unauthorized packets to their precious and delicate network. You would definitely also want to make sure that you filter announcements so you don't accidentally start sending longer paths to your upstreams or customer peers, but if you run BGP, you already do that, amirite?! -evt > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Paras > Sent: Thursday, November 05, 2015 3:04 AM > To: nanog at nanog.org > Subject: Internap route optimization > > Does anyone know or have any experience with Internap's route > optimization? Is it any good? > > I've heard of competing solutions as well, such as the one provided by > Noction. > > Thanks for your input, > Paras From alex at alexforster.com Thu Nov 5 02:38:44 2015 From: alex at alexforster.com (Alex Forster) Date: Thu, 5 Nov 2015 02:38:44 +0000 Subject: AT&T Wholesale In-Reply-To: <151701d11729$acafdec0$060f9c40$@SanDiegoBroadband.com> References: <151701d11729$acafdec0$060f9c40$@SanDiegoBroadband.com> Message-ID: Actually, I'd appreciate pointers to a good rep with AT&T or Verizon for Layer 2 services as well ? no preference for which region of the country. Thanks to anyone who can help! Alex Forster On 11/4/15, 12:53 PM, "NANOG on behalf of Sam Norris" wrote: >Hey everyone, > >Can someone send me privately the contact info for an AT&T Wholesale rep >for >Metro E / VPLS / Layer 2 stuff here in the SouthWest region? Their >website is >not very informative on how to make any contact with the wholesale group. > >Thx, >Sam > From edugas at unknowndevice.ca Thu Nov 5 21:48:51 2015 From: edugas at unknowndevice.ca (Eric Dugas) Date: Thu, 5 Nov 2015 16:48:51 -0500 Subject: Long-haul 100Mbps EPL circuit throughput issue Message-ID: Hello NANOG, We've been dealing with an interesting throughput issue with one of our carrier. Specs and topology: 100Mbps EPL, fiber from a national carrier. We do MPLS to the CPE providing a VRF circuit to our customer back to our data center through our MPLS network. Circuit has 75 ms of latency since it's around 5000km. Linux test machine in customer's VRF <-> SRX100 <-> Carrier CPE (Cisco 2960G) <-> Carrier's MPLS network <-> NNI - MX80 <-> Our MPLS network <-> Terminating edge - MX80 <-> Distribution switch - EX3300 <-> Linux test machine in customer's VRF We can full the link in UDP traffic with iperf but with TCP, we can reach 80-90% and then the traffic drops to 50% and slowly increase up to 90%. Any one have dealt with this kind of problem in the past? We've tested by forcing ports to 100-FD at both ends, policing the circuit on our side, called the carrier and escalated to L2/L3 support. They tried to also police the circuit but as far as I know, they didn't modify anything else. I've told our support to make them look for underrun errors on their Cisco switch and they can see some. They're pretty much in the same boat as us and they're not sure where to look at. Thanks Eric From nanogml at Mail.DDoS-Mitigator.net Thu Nov 5 23:19:12 2015 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Thu, 5 Nov 2015 15:19:12 -0800 Subject: Long-haul 100Mbps EPL circuit throughput issue In-Reply-To: References: Message-ID: <20151105231912.GA17090@Mail.DDoS-Mitigator.net> hi eric On 11/05/15 at 04:48pm, Eric Dugas wrote: ... > Linux test machine in customer's VRF <-> SRX100 <-> Carrier CPE (Cisco > 2960G) <-> Carrier's MPLS network <-> NNI - MX80 <-> Our MPLS network <-> > Terminating edge - MX80 <-> Distribution switch - EX3300 <-> Linux test > machine in customer's VRF > > We can full the link in UDP traffic with iperf but with TCP, we can reach > 80-90% and then the traffic drops to 50% and slowly increase up to 90%. if i was involved with these tests, i'd start looking for "not enough tcp send and tcp receive buffers" for flooding at 100Mbit/s, you'd need about 12MB buffers ... udp does NOT care too much about dropped data due to the buffers, but tcp cares about "not enough buffers" .. somebody resend packet# 1357902456 :-) at least double or triple the buffers needed to compensate for all kinds of network whackyness: data in transit, misconfigured hardware-in-the-path, misconfigured iperfs, misconfigured kernels, interrupt handing, etc, etc - how many "iperf flows" are you also running ?? - running dozen's or 100's of them does affect thruput too - does the same thing happen with socat ?? - if iperf and socat agree with network thruput, it's the hw somewhere - slowly increasing thruput doesn't make sense to me ... it sounds like something is cacheing some of the data magic pixie dust alvin > Any one have dealt with this kind of problem in the past? We've tested by > forcing ports to 100-FD at both ends, policing the circuit on our side, > called the carrier and escalated to L2/L3 support. They tried to also > police the circuit but as far as I know, they didn't modify anything else. > I've told our support to make them look for underrun errors on their Cisco > switch and they can see some. They're pretty much in the same boat as us > and they're not sure where to look at. > From bob at FiberInternetCenter.com Thu Nov 5 23:31:39 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Thu, 5 Nov 2015 15:31:39 -0800 Subject: Long-haul 100Mbps EPL circuit throughput issue In-Reply-To: References: Message-ID: <2af1f897aece8062f5744396fed1559a.squirrel@66.201.44.180> Eric, I have seen that happen. 1st double check that the gear is truly full duplex....seems like it may claim it is and you just discovered it is not. That's always been an issue with manufactures claiming they are full duplex and on short distances it's not so noticeable. Try to perf in both directions at the same time and it become obvious. Thank You Bob Evans CTO > Hello NANOG, > > We've been dealing with an interesting throughput issue with one of our > carrier. Specs and topology: > > 100Mbps EPL, fiber from a national carrier. We do MPLS to the CPE > providing > a VRF circuit to our customer back to our data center through our MPLS > network. Circuit has 75 ms of latency since it's around 5000km. > > Linux test machine in customer's VRF <-> SRX100 <-> Carrier CPE (Cisco > 2960G) <-> Carrier's MPLS network <-> NNI - MX80 <-> Our MPLS network <-> > Terminating edge - MX80 <-> Distribution switch - EX3300 <-> Linux test > machine in customer's VRF > > We can full the link in UDP traffic with iperf but with TCP, we can reach > 80-90% and then the traffic drops to 50% and slowly increase up to 90%. > > Any one have dealt with this kind of problem in the past? We've tested by > forcing ports to 100-FD at both ends, policing the circuit on our side, > called the carrier and escalated to L2/L3 support. They tried to also > police the circuit but as far as I know, they didn't modify anything else. > I've told our support to make them look for underrun errors on their Cisco > switch and they can see some. They're pretty much in the same boat as us > and they're not sure where to look at. > > Thanks > Eric > From plucena at coopergeneral.com Fri Nov 6 02:17:01 2015 From: plucena at coopergeneral.com (Pablo Lucena) Date: Thu, 5 Nov 2015 21:17:01 -0500 Subject: Long-haul 100Mbps EPL circuit throughput issue In-Reply-To: <2af1f897aece8062f5744396fed1559a.squirrel@66.201.44.180> References: <2af1f897aece8062f5744396fed1559a.squirrel@66.201.44.180> Message-ID: With default window size of 64KB, and a delay of 75 msec, you should only get around 7Mbps of throughput with TCP. You would need a window size of about 1MB in order to fill up the 100 Mbps link. 1/0.75 = 13.333 (how many RTTs in a second) 13.333 * 65535 * 8 = 6,990,225.24 (about 7Mbps) You would need to increase the window to 1,048,560 KB, in order to get around 100Mbps. 13.333 * 1,048,560 * 8 = 111,843,603.84 (about 100 Mbps) *Pablo Lucena* *Cooper General Global Services* *Network Administrator* *Office: 305-418-4440 ext. 130* *plucena at coopergeneral.com * On Thu, Nov 5, 2015 at 6:31 PM, Bob Evans wrote: > Eric, > > I have seen that happen. > > 1st double check that the gear is truly full duplex....seems like it may > claim it is and you just discovered it is not. That's always been an issue > with manufactures claiming they are full duplex and on short distances > it's not so noticeable. > > Try to perf in both directions at the same time and it become obvious. > > Thank You > Bob Evans > CTO > > > > > > Hello NANOG, > > > > We've been dealing with an interesting throughput issue with one of our > > carrier. Specs and topology: > > > > 100Mbps EPL, fiber from a national carrier. We do MPLS to the CPE > > providing > > a VRF circuit to our customer back to our data center through our MPLS > > network. Circuit has 75 ms of latency since it's around 5000km. > > > > Linux test machine in customer's VRF <-> SRX100 <-> Carrier CPE (Cisco > > 2960G) <-> Carrier's MPLS network <-> NNI - MX80 <-> Our MPLS network <-> > > Terminating edge - MX80 <-> Distribution switch - EX3300 <-> Linux test > > machine in customer's VRF > > > > We can full the link in UDP traffic with iperf but with TCP, we can reach > > 80-90% and then the traffic drops to 50% and slowly increase up to 90%. > > > > Any one have dealt with this kind of problem in the past? We've tested by > > forcing ports to 100-FD at both ends, policing the circuit on our side, > > called the carrier and escalated to L2/L3 support. They tried to also > > police the circuit but as far as I know, they didn't modify anything > else. > > I've told our support to make them look for underrun errors on their > Cisco > > switch and they can see some. They're pretty much in the same boat as us > > and they're not sure where to look at. > > > > Thanks > > Eric > > > > > From plucena at coopergeneral.com Fri Nov 6 02:18:38 2015 From: plucena at coopergeneral.com (Pablo Lucena) Date: Thu, 5 Nov 2015 21:18:38 -0500 Subject: Long-haul 100Mbps EPL circuit throughput issue In-Reply-To: References: <2af1f897aece8062f5744396fed1559a.squirrel@66.201.44.180> Message-ID: > With default window size of 64KB, and a delay of 75 msec, you should only > get around 7Mbps of throughput with TCP. > > You would need a window size of about 1MB in order to fill up the 100 Mbps > link. > > 1/0.75 = 13.333 (how many RTTs in a second) > 13.333 * 65535 * 8 = 6,990,225.24 (about 7Mbps) > > You would need to increase the window to 1,048,560 KB, in order to get > around 100Mbps. > > 13.333 * 1,048,560 * 8 = 111,843,603.84 (about 100 Mbps) > >> >> >> > ?I realized I made a typo: 1/*0.075* = 13.333 not 1/0.75 = 13.333 ? From theodore at ciscodude.net Fri Nov 6 02:27:27 2015 From: theodore at ciscodude.net (Theodore Baschak) Date: Thu, 5 Nov 2015 20:27:27 -0600 Subject: Long-haul 100Mbps EPL circuit throughput issue In-Reply-To: References: <2af1f897aece8062f5744396fed1559a.squirrel@66.201.44.180> Message-ID: <4A6A5425-ADA1-49D6-89D5-DE189A53D8FD@ciscodude.net> > On Nov 5, 2015, at 8:18 PM, Pablo Lucena wrote: > > ?I realized I made a typo: switch.ch has a nice bandwidth delay product calculator. https://www.switch.ch/network/tools/tcp_throughput/ Punching in the link spec from the original post, gives pretty much exactly what you said Pablo, including that it'd get ~6.999 megabits with a default 64k window. BDP (100 Mbit/sec, 75.0 ms) = 0.94 MByte required tcp buffer to reach 100 Mbps with RTT of 75.0 ms >= 915.5 KByte Theo From greg at foletta.org Thu Nov 5 23:35:13 2015 From: greg at foletta.org (Greg Foletta) Date: Fri, 6 Nov 2015 10:35:13 +1100 Subject: Long-haul 100Mbps EPL circuit throughput issue In-Reply-To: <20151105231912.GA17090@Mail.DDoS-Mitigator.net> References: <20151105231912.GA17090@Mail.DDoS-Mitigator.net> Message-ID: Along with recv window/buffer which is needed for your particular bandwidth/delay product, it appears you're also seeing TCP moving from slow-start to a congestion avoidance mechanism (Reno, Tahoe, CUBIC etc). Greg Foletta greg at foletta.org On 6 November 2015 at 10:19, alvin nanog wrote: > > hi eric > > On 11/05/15 at 04:48pm, Eric Dugas wrote: > ... > > Linux test machine in customer's VRF <-> SRX100 <-> Carrier CPE (Cisco > > 2960G) <-> Carrier's MPLS network <-> NNI - MX80 <-> Our MPLS network <-> > > Terminating edge - MX80 <-> Distribution switch - EX3300 <-> Linux test > > machine in customer's VRF > > > > We can full the link in UDP traffic with iperf but with TCP, we can reach > > 80-90% and then the traffic drops to 50% and slowly increase up to 90%. > > if i was involved with these tests, i'd start looking for "not enough tcp > send > and tcp receive buffers" > > for flooding at 100Mbit/s, you'd need about 12MB buffers ... > > udp does NOT care too much about dropped data due to the buffers, > but tcp cares about "not enough buffers" .. somebody resend packet# > 1357902456 :-) > > at least double or triple the buffers needed to compensate for all kinds of > network whackyness: > data in transit, misconfigured hardware-in-the-path, misconfigured iperfs, > misconfigured kernels, interrupt handing, etc, etc > > - how many "iperf flows" are you also running ?? > - running dozen's or 100's of them does affect thruput too > > - does the same thing happen with socat ?? > > - if iperf and socat agree with network thruput, it's the hw somewhere > > - slowly increasing thruput doesn't make sense to me ... it sounds like > something is cacheing some of the data > > magic pixie dust > alvin > > > Any one have dealt with this kind of problem in the past? We've tested by > > forcing ports to 100-FD at both ends, policing the circuit on our side, > > called the carrier and escalated to L2/L3 support. They tried to also > > police the circuit but as far as I know, they didn't modify anything > else. > > I've told our support to make them look for underrun errors on their > Cisco > > switch and they can see some. They're pretty much in the same boat as us > > and they're not sure where to look at. > > > From bill at herrin.us Fri Nov 6 04:40:22 2015 From: bill at herrin.us (William Herrin) Date: Thu, 5 Nov 2015 23:40:22 -0500 Subject: Long-haul 100Mbps EPL circuit throughput issue In-Reply-To: References: <2af1f897aece8062f5744396fed1559a.squirrel@66.201.44.180> Message-ID: On Thu, Nov 5, 2015 at 9:17 PM, Pablo Lucena wrote: > With default window size of 64KB, and a delay of 75 msec, you should only > get around 7Mbps of throughput with TCP. Hi Pablo, Modern TCPs support and typically use window scaling (RFC 1323). You may not notice it in packet dumps because the window scaling option is negotiated once for the connection, not repeated in every packet. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From plucena at coopergeneral.com Fri Nov 6 05:17:26 2015 From: plucena at coopergeneral.com (Pablo Lucena) Date: Fri, 6 Nov 2015 00:17:26 -0500 Subject: Long-haul 100Mbps EPL circuit throughput issue In-Reply-To: References: <2af1f897aece8062f5744396fed1559a.squirrel@66.201.44.180> Message-ID: > > > Modern TCPs support and typically use window scaling (RFC 1323). You > may not notice it in packet dumps because the window scaling option is > negotiated once for the connection, not repeated in every packet. > > Absolutely. Most host OS should support this by now. Some test utilities however, like iperf (at least the versions I've used) default to a 16 bit window size though. The goal of my response was to allude to the fact that TCP relies on windowing unlike UDP, thus explaining the discrepancies. This is a good article outlining these details: https://www.edge-cloud.net/2013/06/measuring-network-throughput/ From brandonwade at yahoo.com Fri Nov 6 05:12:29 2015 From: brandonwade at yahoo.com (Brandon Wade) Date: Fri, 6 Nov 2015 05:12:29 +0000 (UTC) Subject: Internap route optimization References: <671102648.693176.1446786749702.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <671102648.693176.1446786749702.JavaMail.yahoo@mail.yahoo.com> > Does anyone know or have any experience with Internap's route > optimization? Is it any good? > > I've heard of competing solutions as well, such as the one > provided by Noction. > > Thanks for your input, > Paras We currently utilize the Border6 solution on our network and are very happy with it. It optimizes our outbound traffic by injecting more specifics into our border router to influence the outbound traffic. To assure we don't re-advertise these more specifics to our downstream/peers we tag those routes with a community. The Border6 solution optimizes traffic based upon performance and also allows us to keep our traffic levels within our commits. It has saved us on bursting costs, as well as technical support costs since it has virtually eliminated packet loss complaints. As far as price, the Border6 solution is by far way more cost effective verses the quotes we have received from Internap and Noction. The technical support staff have always gone above and beyond to tweak the solution as needed as well. Overall we are very impressed and would recommend the Border6 solution. It more than pays for itself with customer satisfaction and not needing to staff someone around the clock to manually route around packet loss, blackholed traffic, etc. In fact a few weeks ago our appliance died (for reasons not related to the Border6 solution) and it took a few days for us to provide a replacement box and we did notice complaints come in for packet loss, etc. A pretty good indication that it is doing it's job as expected. Feel free to contact me off list if you have any questions about the Border6 solution. Brandon Wade - AS53767 http://as53767.net From seth.mos at dds.nl Fri Nov 6 07:59:33 2015 From: seth.mos at dds.nl (Seth Mos) Date: Fri, 6 Nov 2015 08:59:33 +0100 Subject: Youtube CDN unreachable over IPv6 Message-ID: <563C5DE5.60505@dds.nl> Dear Google, It appears that one of the Youtube CDN's (in Europe, NL) is not reachable over IPv6 from AS 20844. Can someone get back to us on this, the company can't access any of the videos currently, although the mainpage loads fine (over IPv6). Kind regards, Seth telnet r6---sn-5hne6n76.googlevideo.com 443 Trying 2a00:1450:401c:4::b... telnet: connect to address 2a00:1450:401c:4::b: Connection timed out Trying 74.125.100.203... Connected to r6.sn-5hne6n76.googlevideo.com (74.125.100.203). Escape character is '^]'. Connection closed by foreign host. telnet www.youtube.com 443 Trying 2a00:1450:4013:c01::5d... Connected to youtube-ui.l.google.com (2a00:1450:4013:c01::5d). Escape character is '^]'. Connection closed by foreign host. From niels=nanog at bakker.net Fri Nov 6 14:14:04 2015 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 6 Nov 2015 15:14:04 +0100 Subject: Youtube CDN unreachable over IPv6 In-Reply-To: <563C5DE5.60505@dds.nl> References: <563C5DE5.60505@dds.nl> Message-ID: <20151106141403.GG3097@excession.tpb.net> It's not just you, I'm seeing the same thing from my home connection in AS3265. I think this started happening not long ago when Google had an issue with one of their AMS-IX connections. % telnet -6 r7---sn-5hne6n7y.googlevideo.com 443 Trying 2a00:1450:401c:8::c... I'm certain it's not AS3265 who is to blame here, an ISP I've had pretty much zero issues with over, IPv6 or otherwise, the many years I've been a customer. -- Niels. * seth.mos at dds.nl (Seth Mos) [Fri 06 Nov 2015, 09:00 CET]: >Dear Google, > >It appears that one of the Youtube CDN's (in Europe, NL) is not >reachable over IPv6 from AS 20844. Can someone get back to us on this, >the company can't access any of the videos currently, although the >mainpage loads fine (over IPv6). > >Kind regards, > >Seth > >telnet r6---sn-5hne6n76.googlevideo.com 443 >Trying 2a00:1450:401c:4::b... >telnet: connect to address 2a00:1450:401c:4::b: Connection timed out >Trying 74.125.100.203... >Connected to r6.sn-5hne6n76.googlevideo.com (74.125.100.203). >Escape character is '^]'. >Connection closed by foreign host. > >telnet www.youtube.com 443 >Trying 2a00:1450:4013:c01::5d... >Connected to youtube-ui.l.google.com (2a00:1450:4013:c01::5d). >Escape character is '^]'. >Connection closed by foreign host. From Thijs.Stuurman at is.nl Fri Nov 6 14:35:44 2015 From: Thijs.Stuurman at is.nl (Thijs Stuurman) Date: Fri, 6 Nov 2015 14:35:44 +0000 Subject: Youtube CDN unreachable over IPv6 In-Reply-To: <20151106141403.GG3097@excession.tpb.net> References: <563C5DE5.60505@dds.nl> <20151106141403.GG3097@excession.tpb.net> Message-ID: The problem is on Google's side. From AS15879: """ [~]# telnet r7---sn-5hne6n7y.googlevideo.com 443 Trying 2a00:1450:401c:8::c... telnet: connect to address 2a00:1450:401c:8::c: Connection timed out Trying 173.194.153.76... Connected to r7---sn-5hne6n7y.googlevideo.com. Escape character is '^]'. Connection closed by foreign host. [~]# telnet r1---sn-5hne6n7z.googlevideo.com 443 Trying 2a00:1450:401c:3::7... telnet: connect to address 2a00:1450:401c:3::7: Connection timed out Trying 74.125.8.55... Connected to r1---sn-5hne6n7z.googlevideo.com. Escape character is '^]'. Connection closed by foreign host. [~]# telnet rijksoverheid.nl 443 Trying 2a00:d00:3:2::116... Connected to rijksoverheid.nl. Escape character is '^]'. ^] telnet> quit Connection closed. """ Thijs Stuurman Infrastructure & Solutions IS (internedservices) Group Wielingenstraat 8 | 1441 ZR Purmerend | The Netherlands T: +31(0)299476185 | M: +31(0)624366778 W: https://www.is.nl | L: http://nl.linkedin.com/in/thijsstuurman -----Oorspronkelijk bericht----- Van: NANOG [mailto:nanog-bounces at nanog.org] Namens Niels Bakker Verzonden: Friday, November 6, 2015 3:14 PM Aan: nanog at nanog.org Onderwerp: Re: Youtube CDN unreachable over IPv6 It's not just you, I'm seeing the same thing from my home connection in AS3265. I think this started happening not long ago when Google had an issue with one of their AMS-IX connections. % telnet -6 r7---sn-5hne6n7y.googlevideo.com 443 Trying 2a00:1450:401c:8::c... I'm certain it's not AS3265 who is to blame here, an ISP I've had pretty much zero issues with over, IPv6 or otherwise, the many years I've been a customer. -- Niels. * seth.mos at dds.nl (Seth Mos) [Fri 06 Nov 2015, 09:00 CET]: >Dear Google, > >It appears that one of the Youtube CDN's (in Europe, NL) is not >reachable over IPv6 from AS 20844. Can someone get back to us on this, >the company can't access any of the videos currently, although the >mainpage loads fine (over IPv6). > >Kind regards, > >Seth > >telnet r6---sn-5hne6n76.googlevideo.com 443 >Trying 2a00:1450:401c:4::b... >telnet: connect to address 2a00:1450:401c:4::b: Connection timed out >Trying 74.125.100.203... >Connected to r6.sn-5hne6n76.googlevideo.com (74.125.100.203). >Escape character is '^]'. >Connection closed by foreign host. > >telnet www.youtube.com 443 >Trying 2a00:1450:4013:c01::5d... >Connected to youtube-ui.l.google.com (2a00:1450:4013:c01::5d). >Escape character is '^]'. >Connection closed by foreign host. From andrew.duey at widerangebroadband.net Fri Nov 6 15:38:52 2015 From: andrew.duey at widerangebroadband.net (Andrew Duey) Date: Fri, 6 Nov 2015 09:38:52 -0600 Subject: Route leaks from AS9498 (BHARTI Airtel)? Message-ID: Is anyone else seeing their routes leaked from AS9498 (BHARTI Airtel) in India? According to bgpmon.net they started leaking our Level 3 provided IP space at 2015-11-06 05:52 UTC. Oddly, they're not leaking our ARIN assigned IP blocks but our prefixes inside the 8.0.0.0/8 range they are (8.34.96.0/21 and 8.33.2.0/24). BGPmon shows less of their probes are now showing the announcement and we haven't seen a noticeable hit in overall traffic levels. Has anyone else seen this route leak? Is it somehow specific to just the big Level 3 blocks? (4.0.0.0/8 and 8.0.0.0/8)? I figured NANOG would have a thread on it already but haven't heard a whisper (unless all the new guys like me are being modded thanks to the spam incident). Thanks, --Andrew Duey From job at instituut.net Fri Nov 6 15:43:42 2015 From: job at instituut.net (Job Snijders) Date: Fri, 6 Nov 2015 16:43:42 +0100 Subject: Route leaks from AS9498 (BHARTI Airtel)? In-Reply-To: References: Message-ID: <20151106154342.GS21786@Vurt.local> On Fri, Nov 06, 2015 at 09:38:52AM -0600, Andrew Duey wrote: > Is anyone else seeing their routes leaked from AS9498 (BHARTI Airtel) in > India? > > According to bgpmon.net they started leaking our Level 3 provided IP space > at 2015-11-06 05:52 UTC. Oddly, they're not leaking our ARIN assigned IP > blocks but our prefixes inside the 8.0.0.0/8 range they are (8.34.96.0/21 > and 8.33.2.0/24). > > BGPmon shows less of their probes are now showing the announcement and we > haven't seen a noticeable hit in overall traffic levels. > > Has anyone else seen this route leak? Is it somehow specific to just the > big Level 3 blocks? (4.0.0.0/8 and 8.0.0.0/8)? I figured NANOG would have > a thread on it already but haven't heard a whisper (unless all the new guys > like me are being modded thanks to the spam incident). Andree already did a good write-up: http://www.bgpmon.net/large-scale-bgp-hijack-out-of-india/ Kind regards, Job From arthurliew80 at gmail.com Fri Nov 6 12:57:16 2015 From: arthurliew80 at gmail.com (Arthur Liew) Date: Fri, 6 Nov 2015 20:57:16 +0800 Subject: NANOG Digest, Vol 94, Issue 4 In-Reply-To: References: Message-ID: Hi Brandon, Does Border6 works for inbound traffic engineering too? We were exploring inbound traffic engineering a while ago, and had attended Huawei RR+ demo. The idea is great, but they only support their own router netflow currently We are still looking for options.It'll be great if you can share more if it supports. Rgds Arthur Liew (CCIE#38181) On Fri, Nov 6, 2015 at 8:00 PM, wrote: > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: Internap route optimization (chip) > 2. Re: Internap route optimization (Mike Hammett) > 3. Looking for a comcast NOC and/or peering contact (Eric Sieg) > 4. Re: Internap route optimization (Sebastian Spies) > 5. Re: Internap route optimization (Fred Hollis) > 6. RE: Internap route optimization (Eric Van Tol) > 7. Re: AT&T Wholesale (Alex Forster) > 8. Long-haul 100Mbps EPL circuit throughput issue (Eric Dugas) > 9. Re: Long-haul 100Mbps EPL circuit throughput issue (alvin nanog) > 10. Re: Long-haul 100Mbps EPL circuit throughput issue (Bob Evans) > 11. Re: Long-haul 100Mbps EPL circuit throughput issue (Pablo Lucena) > 12. Re: Long-haul 100Mbps EPL circuit throughput issue (Pablo Lucena) > 13. Re: Long-haul 100Mbps EPL circuit throughput issue > (Theodore Baschak) > 14. Re: Long-haul 100Mbps EPL circuit throughput issue (Greg Foletta) > 15. Re: Long-haul 100Mbps EPL circuit throughput issue > (William Herrin) > 16. Re: Long-haul 100Mbps EPL circuit throughput issue (Pablo Lucena) > 17. Re: Internap route optimization (Brandon Wade) > 18. Youtube CDN unreachable over IPv6 (Seth Mos) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 5 Nov 2015 07:18:08 -0500 > From: chip > To: Christopher Morrow > Cc: Fred Hollis , nanog list > Subject: Re: Internap route optimization > Message-ID: > < > CABGzhdu8t8HW8RC4Tk+XWtrEtJZZuia_DcN-A2E_7TUv-PBGiQ at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Just to be clear, Internap's solution doesn't use "more specifics" to steer > traffic. The mechanisms in place to protect yourself from normal route > leaking should apply just the same. > > --chip > > > On Thu, Nov 5, 2015 at 5:01 AM, Christopher Morrow < > morrowc.lists at gmail.com> > wrote: > > > Also, please, if you use one of this sort of device filter your > > prefixes toward your customers/peers/transits... Do not be the next > > person to leak their internap-box-routes to the world, m'kay? :) > > > > On Thu, Nov 5, 2015 at 8:53 PM, Fred Hollis > wrote: > > > Hi, > > > > > > No particular experience with Internaps optimization...however I > > wouldn't be > > > that sure if I would use it within our networks, because you always > have > > the > > > conflict of this not being their core business as they want to sell > their > > > optimized IP transit. > > > > > > However, some time ago we tried Border6 in an evaluation and then > finally > > > put it into production. Not only the optimization is nice, but the > > reporting > > > is so extremely detailed making it very transparent where the transit > has > > > congestion issues and which prefix is routed (in and out) through which > > > upstream. > > > > > > For sure traffic engineering/optimization is not a trivial task but > > requires > > > deep thinking and understanding of the whole BGP and routing picture. > > > > > > > > > On 05.11.2015 at 09:03 Paras wrote: > > >> > > >> Does anyone know or have any experience with Internap's route > > >> optimization? Is it any good? > > >> > > >> I've heard of competing solutions as well, such as the one provided by > > >> Noction. > > >> > > >> Thanks for your input, > > >> Paras > > >> > > > > > > > > > -- > Just my $.02, your mileage may vary, batteries not included, etc.... > > > ------------------------------ > > Message: 2 > Date: Thu, 5 Nov 2015 07:21:05 -0600 (CST) > From: Mike Hammett > Cc: nanog at nanog.org > Subject: Re: Internap route optimization > Message-ID: > <962573932.10921.1446729692705.JavaMail.mhammett at ThunderFuck> > Content-Type: text/plain; charset=utf-8 > > Keep in mind that most do not optimize inbound traffic, only outbound. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Paras" > To: nanog at nanog.org > Sent: Thursday, November 5, 2015 2:03:41 AM > Subject: Internap route optimization > > Does anyone know or have any experience with Internap's route > optimization? Is it any good? > > I've heard of competing solutions as well, such as the one provided by > Noction. > > Thanks for your input, > Paras > > > > > ------------------------------ > > Message: 3 > Date: Thu, 5 Nov 2015 08:23:03 -0500 > From: Eric Sieg > To: nanog at nanog.org > Subject: Looking for a comcast NOC and/or peering contact > Message-ID: > < > CAEcHXr6EXg2M2uc-JkuSG3EjTPU4nra-sRiUhAR0fDyKHLUKdg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > If you could contact me off-list, it would be greatly appreciated! > > -Eric > > > ------------------------------ > > Message: 4 > Date: Thu, 5 Nov 2015 14:56:10 +0100 > From: Sebastian Spies > To: nanog at nanog.org > Subject: Re: Internap route optimization > Message-ID: <563B5FFA.8020409 at sloc.de> > Content-Type: text/plain; charset=utf-8 > > Hey Mike, > > do you know route optimizers that actually do optimize inbound traffic? > We, at datapath.io, are currently working on this and could not find > another one that does it. > > Best, > Sebastian > > Am 05.11.2015 um 14:21 schrieb Mike Hammett: > > Keep in mind that most do not optimize inbound traffic, only outbound. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > ----- Original Message ----- > > > > From: "Paras" > > To: nanog at nanog.org > > Sent: Thursday, November 5, 2015 2:03:41 AM > > Subject: Internap route optimization > > > > Does anyone know or have any experience with Internap's route > > optimization? Is it any good? > > > > I've heard of competing solutions as well, such as the one provided by > > Noction. > > > > Thanks for your input, > > Paras > > > > > > > ------------------------------ > > Message: 5 > Date: Thu, 5 Nov 2015 15:00:53 +0100 > From: Fred Hollis > To: nanog at nanog.org > Subject: Re: Internap route optimization > Message-ID: <563B6115.808 at web2objects.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Border6 offers such an option based on prependings and bgp communities. > But honestly, I didn't test that feature yet. And I'm not that sure how > much sense it makes since it probably requires quite a lot global BGP > updates... makes routers even more busy than they are currently. > > On 05.11.2015 at 14:56 Sebastian Spies wrote: > > Hey Mike, > > > > do you know route optimizers that actually do optimize inbound traffic? > > We, at datapath.io, are currently working on this and could not find > > another one that does it. > > > > Best, > > Sebastian > > > > Am 05.11.2015 um 14:21 schrieb Mike Hammett: > >> Keep in mind that most do not optimize inbound traffic, only outbound. > >> > >> > >> > >> > >> ----- > >> Mike Hammett > >> Intelligent Computing Solutions > >> http://www.ics-il.com > >> > >> ----- Original Message ----- > >> > >> From: "Paras" > >> To: nanog at nanog.org > >> Sent: Thursday, November 5, 2015 2:03:41 AM > >> Subject: Internap route optimization > >> > >> Does anyone know or have any experience with Internap's route > >> optimization? Is it any good? > >> > >> I've heard of competing solutions as well, such as the one provided by > >> Noction. > >> > >> Thanks for your input, > >> Paras > >> > >> > > > ------------------------------ > > Message: 6 > Date: Thu, 5 Nov 2015 06:17:33 -0500 > From: Eric Van Tol > To: NANOG > Subject: RE: Internap route optimization > Message-ID: > <2C05E949E19A9146AF7BDF9D44085B86720A812942 at exchange.aoihq.local> > Content-Type: text/plain; charset="utf-8" > > TL;DR: Not worth it unless you have only a few transit providers and are a > content-heavy network with little inbound traffic. > > We used the Internap FCP for a long time (10 or so years). In general, we > were satisfied with it, but honestly, after not having it in our network > for the past year and a half, we really don't notice a difference. We > primarily purchased it to keep transit costs down, but as we kept boosting > our minimums with providers, it became less and less about transit costs > and more about performance. > > Boxes like these really work best if your network is a content-heavy > network (more outbound than inbound). Sure, it will route around poorly > performing paths, but IMO it's not worth the money and yearly maintenance > fees just for this. I always said that it must be doing a good job since we > never got complaints about packet loss in an upstream network, but now that > the device is gone, we still don't get complaints about packet loss in an > upstream's network. :-/ > > The biggest problem that we found was that it just was not actively > developed (at the time, not sure about now). New software features were > non-existent for years. Bugs were not fixed in a timely manner. Given what > we were paying in yearly maintenance fees, it just wasn't worth it to keep > around. It also wasn't scalable as we kept adding more transit interfaces, > given that there were a fixed amount of capture ports. Adding non-transit > peering into the mix was also complicated and messed with the route > decision algorithms. Maybe things have changed. > > As far as technicals, it seemed to work fine. One of the really only > annoying things about it were remote users who think that a UDP packet > hitting their firewall from its automatic traceroute mechanism were 'DDoS' > and threats of lawyers/the wrath of god almighty would come down upon us > for sending unauthorized packets to their precious and delicate network. > You would definitely also want to make sure that you filter announcements > so you don't accidentally start sending longer paths to your upstreams or > customer peers, but if you run BGP, you already do that, amirite?! > > -evt > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Paras > > Sent: Thursday, November 05, 2015 3:04 AM > > To: nanog at nanog.org > > Subject: Internap route optimization > > > > Does anyone know or have any experience with Internap's route > > optimization? Is it any good? > > > > I've heard of competing solutions as well, such as the one provided by > > Noction. > > > > Thanks for your input, > > Paras > > > ------------------------------ > > Message: 7 > Date: Thu, 5 Nov 2015 02:38:44 +0000 > From: Alex Forster > To: "nanog at nanog.org" > Subject: Re: AT&T Wholesale > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > Actually, I'd appreciate pointers to a good rep with AT&T or Verizon for > Layer 2 services as well ? no preference for which region of the country. > Thanks to anyone who can help! > > Alex Forster > > > > On 11/4/15, 12:53 PM, "NANOG on behalf of Sam Norris" > wrote: > > >Hey everyone, > > > >Can someone send me privately the contact info for an AT&T Wholesale rep > >for > >Metro E / VPLS / Layer 2 stuff here in the SouthWest region? Their > >website is > >not very informative on how to make any contact with the wholesale group. > > > >Thx, > >Sam > > > > > > ------------------------------ > > Message: 8 > Date: Thu, 5 Nov 2015 16:48:51 -0500 > From: Eric Dugas > To: nanog at nanog.org > Subject: Long-haul 100Mbps EPL circuit throughput issue > Message-ID: > vf4EgPetoXJxaHTxfGt8HXYr6CE+xPk1Vy4g at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hello NANOG, > > We've been dealing with an interesting throughput issue with one of our > carrier. Specs and topology: > > 100Mbps EPL, fiber from a national carrier. We do MPLS to the CPE providing > a VRF circuit to our customer back to our data center through our MPLS > network. Circuit has 75 ms of latency since it's around 5000km. > > Linux test machine in customer's VRF <-> SRX100 <-> Carrier CPE (Cisco > 2960G) <-> Carrier's MPLS network <-> NNI - MX80 <-> Our MPLS network <-> > Terminating edge - MX80 <-> Distribution switch - EX3300 <-> Linux test > machine in customer's VRF > > We can full the link in UDP traffic with iperf but with TCP, we can reach > 80-90% and then the traffic drops to 50% and slowly increase up to 90%. > > Any one have dealt with this kind of problem in the past? We've tested by > forcing ports to 100-FD at both ends, policing the circuit on our side, > called the carrier and escalated to L2/L3 support. They tried to also > police the circuit but as far as I know, they didn't modify anything else. > I've told our support to make them look for underrun errors on their Cisco > switch and they can see some. They're pretty much in the same boat as us > and they're not sure where to look at. > > Thanks > Eric > > > ------------------------------ > > Message: 9 > Date: Thu, 5 Nov 2015 15:19:12 -0800 > From: alvin nanog > To: Eric Dugas > Cc: nanog at nanog.org > Subject: Re: Long-haul 100Mbps EPL circuit throughput issue > Message-ID: <20151105231912.GA17090 at Mail.DDoS-Mitigator.net> > Content-Type: text/plain; charset=us-ascii > > > hi eric > > On 11/05/15 at 04:48pm, Eric Dugas wrote: > ... > > Linux test machine in customer's VRF <-> SRX100 <-> Carrier CPE (Cisco > > 2960G) <-> Carrier's MPLS network <-> NNI - MX80 <-> Our MPLS network <-> > > Terminating edge - MX80 <-> Distribution switch - EX3300 <-> Linux test > > machine in customer's VRF > > > > We can full the link in UDP traffic with iperf but with TCP, we can reach > > 80-90% and then the traffic drops to 50% and slowly increase up to 90%. > > if i was involved with these tests, i'd start looking for "not enough tcp > send > and tcp receive buffers" > > for flooding at 100Mbit/s, you'd need about 12MB buffers ... > > udp does NOT care too much about dropped data due to the buffers, > but tcp cares about "not enough buffers" .. somebody resend packet# > 1357902456 :-) > > at least double or triple the buffers needed to compensate for all kinds of > network whackyness: > data in transit, misconfigured hardware-in-the-path, misconfigured iperfs, > misconfigured kernels, interrupt handing, etc, etc > > - how many "iperf flows" are you also running ?? > - running dozen's or 100's of them does affect thruput too > > - does the same thing happen with socat ?? > > - if iperf and socat agree with network thruput, it's the hw somewhere > > - slowly increasing thruput doesn't make sense to me ... it sounds like > something is cacheing some of the data > > magic pixie dust > alvin > > > Any one have dealt with this kind of problem in the past? We've tested by > > forcing ports to 100-FD at both ends, policing the circuit on our side, > > called the carrier and escalated to L2/L3 support. They tried to also > > police the circuit but as far as I know, they didn't modify anything > else. > > I've told our support to make them look for underrun errors on their > Cisco > > switch and they can see some. They're pretty much in the same boat as us > > and they're not sure where to look at. > > > > > ------------------------------ > > Message: 10 > Date: Thu, 5 Nov 2015 15:31:39 -0800 > From: "Bob Evans" > To: "Eric Dugas" > Cc: nanog at nanog.org > Subject: Re: Long-haul 100Mbps EPL circuit throughput issue > Message-ID: <2af1f897aece8062f5744396fed1559a.squirrel at 66.201.44.180> > Content-Type: text/plain;charset=iso-8859-1 > > Eric, > > I have seen that happen. > > 1st double check that the gear is truly full duplex....seems like it may > claim it is and you just discovered it is not. That's always been an issue > with manufactures claiming they are full duplex and on short distances > it's not so noticeable. > > Try to perf in both directions at the same time and it become obvious. > > Thank You > Bob Evans > CTO > > > > > > Hello NANOG, > > > > We've been dealing with an interesting throughput issue with one of our > > carrier. Specs and topology: > > > > 100Mbps EPL, fiber from a national carrier. We do MPLS to the CPE > > providing > > a VRF circuit to our customer back to our data center through our MPLS > > network. Circuit has 75 ms of latency since it's around 5000km. > > > > Linux test machine in customer's VRF <-> SRX100 <-> Carrier CPE (Cisco > > 2960G) <-> Carrier's MPLS network <-> NNI - MX80 <-> Our MPLS network <-> > > Terminating edge - MX80 <-> Distribution switch - EX3300 <-> Linux test > > machine in customer's VRF > > > > We can full the link in UDP traffic with iperf but with TCP, we can reach > > 80-90% and then the traffic drops to 50% and slowly increase up to 90%. > > > > Any one have dealt with this kind of problem in the past? We've tested by > > forcing ports to 100-FD at both ends, policing the circuit on our side, > > called the carrier and escalated to L2/L3 support. They tried to also > > police the circuit but as far as I know, they didn't modify anything > else. > > I've told our support to make them look for underrun errors on their > Cisco > > switch and they can see some. They're pretty much in the same boat as us > > and they're not sure where to look at. > > > > Thanks > > Eric > > > > > > > ------------------------------ > > Message: 11 > Date: Thu, 5 Nov 2015 21:17:01 -0500 > From: Pablo Lucena > To: bob at fiberinternetcenter.com > Cc: Eric Dugas , "NANOG Operators' Group" > > Subject: Re: Long-haul 100Mbps EPL circuit throughput issue > Message-ID: > 2fiNFMQoC5aw at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > With default window size of 64KB, and a delay of 75 msec, you should only > get around 7Mbps of throughput with TCP. > > You would need a window size of about 1MB in order to fill up the 100 Mbps > link. > > 1/0.75 = 13.333 (how many RTTs in a second) > 13.333 * 65535 * 8 = 6,990,225.24 (about 7Mbps) > > You would need to increase the window to 1,048,560 KB, in order to get > around 100Mbps. > > 13.333 * 1,048,560 * 8 = 111,843,603.84 (about 100 Mbps) > > > *Pablo Lucena* > > *Cooper General Global Services* > > *Network Administrator* > > *Office: 305-418-4440 ext. 130* > > *plucena at coopergeneral.com * > > On Thu, Nov 5, 2015 at 6:31 PM, Bob Evans > wrote: > > > Eric, > > > > I have seen that happen. > > > > 1st double check that the gear is truly full duplex....seems like it may > > claim it is and you just discovered it is not. That's always been an > issue > > with manufactures claiming they are full duplex and on short distances > > it's not so noticeable. > > > > Try to perf in both directions at the same time and it become obvious. > > > > Thank You > > Bob Evans > > CTO > > > > > > > > > > > Hello NANOG, > > > > > > We've been dealing with an interesting throughput issue with one of our > > > carrier. Specs and topology: > > > > > > 100Mbps EPL, fiber from a national carrier. We do MPLS to the CPE > > > providing > > > a VRF circuit to our customer back to our data center through our MPLS > > > network. Circuit has 75 ms of latency since it's around 5000km. > > > > > > Linux test machine in customer's VRF <-> SRX100 <-> Carrier CPE (Cisco > > > 2960G) <-> Carrier's MPLS network <-> NNI - MX80 <-> Our MPLS network > <-> > > > Terminating edge - MX80 <-> Distribution switch - EX3300 <-> Linux test > > > machine in customer's VRF > > > > > > We can full the link in UDP traffic with iperf but with TCP, we can > reach > > > 80-90% and then the traffic drops to 50% and slowly increase up to 90%. > > > > > > Any one have dealt with this kind of problem in the past? We've tested > by > > > forcing ports to 100-FD at both ends, policing the circuit on our side, > > > called the carrier and escalated to L2/L3 support. They tried to also > > > police the circuit but as far as I know, they didn't modify anything > > else. > > > I've told our support to make them look for underrun errors on their > > Cisco > > > switch and they can see some. They're pretty much in the same boat as > us > > > and they're not sure where to look at. > > > > > > Thanks > > > Eric > > > > > > > > > > > > ------------------------------ > > Message: 12 > Date: Thu, 5 Nov 2015 21:18:38 -0500 > From: Pablo Lucena > To: bob > Cc: Eric Dugas , "NANOG Operators' Group" > > Subject: Re: Long-haul 100Mbps EPL circuit throughput issue > Message-ID: > < > CAH+2GV+8kO1LEiCWri2NYyB5GsUbsc02uSTmVjK5+_AQgcVQqQ at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > > With default window size of 64KB, and a delay of 75 msec, you should only > > get around 7Mbps of throughput with TCP. > > > > You would need a window size of about 1MB in order to fill up the 100 > Mbps > > link. > > > > 1/0.75 = 13.333 (how many RTTs in a second) > > 13.333 * 65535 * 8 = 6,990,225.24 (about 7Mbps) > > > > You would need to increase the window to 1,048,560 KB, in order to get > > around 100Mbps. > > > > 13.333 * 1,048,560 * 8 = 111,843,603.84 (about 100 Mbps) > > > >> > >> > >> > > > ?I realized I made a typo: > > 1/*0.075* = 13.333 > > not > > 1/0.75 = 13.333 > > > ? > > > ------------------------------ > > Message: 13 > Date: Thu, 5 Nov 2015 20:27:27 -0600 > From: Theodore Baschak > To: NANOG Operators' Group > Subject: Re: Long-haul 100Mbps EPL circuit throughput issue > Message-ID: <4A6A5425-ADA1-49D6-89D5-DE189A53D8FD at ciscodude.net> > Content-Type: text/plain; charset=utf-8 > > > On Nov 5, 2015, at 8:18 PM, Pablo Lucena > wrote: > > > > ?I realized I made a typo: > > > switch.ch has a nice bandwidth delay product calculator. > https://www.switch.ch/network/tools/tcp_throughput/ < > https://www.switch.ch/network/tools/tcp_throughput/> > > Punching in the link spec from the original post, gives pretty much > exactly what you said Pablo, including that it'd get ~6.999 megabits with a > default 64k window. > > BDP (100 Mbit/sec, 75.0 ms) = 0.94 MByte > required tcp buffer to reach 100 Mbps with RTT of 75.0 ms >= 915.5 KByte > > Theo > > > > > ------------------------------ > > Message: 14 > Date: Fri, 6 Nov 2015 10:35:13 +1100 > From: Greg Foletta > To: alvin nanog > Cc: Eric Dugas , nanog at nanog.org > Subject: Re: Long-haul 100Mbps EPL circuit throughput issue > Message-ID: > 40S2yjzZg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Along with recv window/buffer which is needed for your particular > bandwidth/delay product, it appears you're also seeing TCP moving from > slow-start to a congestion avoidance mechanism (Reno, Tahoe, CUBIC etc). > > Greg Foletta > greg at foletta.org > > > On 6 November 2015 at 10:19, alvin nanog > wrote: > > > > > hi eric > > > > On 11/05/15 at 04:48pm, Eric Dugas wrote: > > ... > > > Linux test machine in customer's VRF <-> SRX100 <-> Carrier CPE (Cisco > > > 2960G) <-> Carrier's MPLS network <-> NNI - MX80 <-> Our MPLS network > <-> > > > Terminating edge - MX80 <-> Distribution switch - EX3300 <-> Linux test > > > machine in customer's VRF > > > > > > We can full the link in UDP traffic with iperf but with TCP, we can > reach > > > 80-90% and then the traffic drops to 50% and slowly increase up to 90%. > > > > if i was involved with these tests, i'd start looking for "not enough tcp > > send > > and tcp receive buffers" > > > > for flooding at 100Mbit/s, you'd need about 12MB buffers ... > > > > udp does NOT care too much about dropped data due to the buffers, > > but tcp cares about "not enough buffers" .. somebody resend packet# > > 1357902456 :-) > > > > at least double or triple the buffers needed to compensate for all kinds > of > > network whackyness: > > data in transit, misconfigured hardware-in-the-path, misconfigured > iperfs, > > misconfigured kernels, interrupt handing, etc, etc > > > > - how many "iperf flows" are you also running ?? > > - running dozen's or 100's of them does affect thruput too > > > > - does the same thing happen with socat ?? > > > > - if iperf and socat agree with network thruput, it's the hw somewhere > > > > - slowly increasing thruput doesn't make sense to me ... it sounds like > > something is cacheing some of the data > > > > magic pixie dust > > alvin > > > > > Any one have dealt with this kind of problem in the past? We've tested > by > > > forcing ports to 100-FD at both ends, policing the circuit on our side, > > > called the carrier and escalated to L2/L3 support. They tried to also > > > police the circuit but as far as I know, they didn't modify anything > > else. > > > I've told our support to make them look for underrun errors on their > > Cisco > > > switch and they can see some. They're pretty much in the same boat as > us > > > and they're not sure where to look at. > > > > > > > > ------------------------------ > > Message: 15 > Date: Thu, 5 Nov 2015 23:40:22 -0500 > From: William Herrin > To: Pablo Lucena > Cc: "NANOG Operators' Group" > Subject: Re: Long-haul 100Mbps EPL circuit throughput issue > Message-ID: > < > CAP-guGUycg9mcVKYxB_fXXVCLhNpA6unkCmoiODrFmn5i7aDOw at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Thu, Nov 5, 2015 at 9:17 PM, Pablo Lucena > wrote: > > With default window size of 64KB, and a delay of 75 msec, you should only > > get around 7Mbps of throughput with TCP. > > Hi Pablo, > > Modern TCPs support and typically use window scaling (RFC 1323). You > may not notice it in packet dumps because the window scaling option is > negotiated once for the connection, not repeated in every packet. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > > > ------------------------------ > > Message: 16 > Date: Fri, 6 Nov 2015 00:17:26 -0500 > From: Pablo Lucena > To: William Herrin > Cc: "NANOG Operators' Group" > Subject: Re: Long-haul 100Mbps EPL circuit throughput issue > Message-ID: > cP6NBesD90Z3EstQ at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > > > > > > Modern TCPs support and typically use window scaling (RFC 1323). You > > may not notice it in packet dumps because the window scaling option is > > negotiated once for the connection, not repeated in every packet. > > > > > Absolutely. Most host OS should support this by now. Some test utilities > however, like iperf (at least the versions I've used) default to a 16 bit > window size though. > > The goal of my response was to allude to the fact that TCP relies on > windowing unlike UDP, thus explaining the discrepancies. > > This is a good article outlining these details: > > https://www.edge-cloud.net/2013/06/measuring-network-throughput/ > > > ------------------------------ > > Message: 17 > Date: Fri, 6 Nov 2015 05:12:29 +0000 (UTC) > From: Brandon Wade > To: "nanog at nanog.org" > Subject: Re: Internap route optimization > Message-ID: > <671102648.693176.1446786749702.JavaMail.yahoo at mail.yahoo.com> > Content-Type: text/plain; charset=UTF-8 > > > Does anyone know or have any experience with Internap's route > > optimization? Is it any good? > > > > I've heard of competing solutions as well, such as the one > > provided by Noction. > > > > Thanks for your input, > > Paras > > We currently utilize the Border6 solution on our network and are very > happy with it. It optimizes our outbound traffic by injecting more > specifics into our border router to influence the outbound traffic. To > assure we don't re-advertise these more specifics to our downstream/peers > we tag those routes with a community. > > The Border6 solution optimizes traffic based upon performance and also > allows us to keep our traffic levels within our commits. It has saved us on > bursting costs, as well as technical support costs since it has virtually > eliminated packet loss complaints. > > As far as price, the Border6 solution is by far way more cost effective > verses the quotes we have received from Internap and Noction. The technical > support staff have always gone above and beyond to tweak the solution as > needed as well. Overall we are very impressed and would recommend the > Border6 solution. It more than pays for itself with customer satisfaction > and not needing to staff someone around the clock to manually route around > packet loss, blackholed traffic, etc. > > In fact a few weeks ago our appliance died (for reasons not related to the > Border6 solution) and it took a few days for us to provide a replacement > box and we did notice complaints come in for packet loss, etc. A pretty > good indication that it is doing it's job as expected. > > Feel free to contact me off list if you have any questions about the > Border6 solution. > > Brandon Wade - AS53767 > http://as53767.net > > > > > ------------------------------ > > Message: 18 > Date: Fri, 6 Nov 2015 08:59:33 +0100 > From: Seth Mos > To: NANOG list > Subject: Youtube CDN unreachable over IPv6 > Message-ID: <563C5DE5.60505 at dds.nl> > Content-Type: text/plain; charset=utf-8 > > Dear Google, > > It appears that one of the Youtube CDN's (in Europe, NL) is not > reachable over IPv6 from AS 20844. Can someone get back to us on this, > the company can't access any of the videos currently, although the > mainpage loads fine (over IPv6). > > Kind regards, > > Seth > > telnet r6---sn-5hne6n76.googlevideo.com 443 > Trying 2a00:1450:401c:4::b... > telnet: connect to address 2a00:1450:401c:4::b: Connection timed out > Trying 74.125.100.203... > Connected to r6.sn-5hne6n76.googlevideo.com (74.125.100.203). > Escape character is '^]'. > Connection closed by foreign host. > > telnet www.youtube.com 443 > Trying 2a00:1450:4013:c01::5d... > Connected to youtube-ui.l.google.com (2a00:1450:4013:c01::5d). > Escape character is '^]'. > Connection closed by foreign host. > > > End of NANOG Digest, Vol 94, Issue 4 > ************************************ > From rafaelpossa at gmail.com Fri Nov 6 15:12:09 2015 From: rafaelpossa at gmail.com (Rafael Possamai) Date: Fri, 6 Nov 2015 09:12:09 -0600 Subject: Internap route optimization In-Reply-To: <563B0D5D.5000705@protrafsolutions.com> References: <563B0D5D.5000705@protrafsolutions.com> Message-ID: A few years ago I had a couple boxes in a datacenter in Chicago that had its traffic optimized by Internap. Latency wise, it was always the lowest to my other applications, compared to other locations I had on-line. I am not sure what other benefits it brought aside from lower latency. One thing to remember is that they had several uplinks, so if you only have a couple I can't imagine the impact to be great. Just my 2cents. On Thu, Nov 5, 2015 at 2:03 AM, Paras wrote: > Does anyone know or have any experience with Internap's route > optimization? Is it any good? > > I've heard of competing solutions as well, such as the one provided by > Noction. > > Thanks for your input, > Paras > > From blair.trosper at gmail.com Fri Nov 6 17:48:46 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Fri, 6 Nov 2015 11:48:46 -0600 Subject: Youtube CDN unreachable over IPv6 In-Reply-To: References: <563C5DE5.60505@dds.nl> <20151106141403.GG3097@excession.tpb.net> Message-ID: This was happening two weeks ago in the Bay Area as well. It happens quite a lot, actually...search for my old threads. I gave up trying to get it noticed. On Fri, Nov 6, 2015 at 8:35 AM, Thijs Stuurman wrote: > The problem is on Google's side. From AS15879: > > """ > [~]# telnet r7---sn-5hne6n7y.googlevideo.com 443 > Trying 2a00:1450:401c:8::c... > telnet: connect to address 2a00:1450:401c:8::c: Connection timed out > Trying 173.194.153.76... > Connected to r7---sn-5hne6n7y.googlevideo.com. > Escape character is '^]'. > Connection closed by foreign host. > > [~]# telnet r1---sn-5hne6n7z.googlevideo.com 443 > Trying 2a00:1450:401c:3::7... > telnet: connect to address 2a00:1450:401c:3::7: Connection timed out > Trying 74.125.8.55... > Connected to r1---sn-5hne6n7z.googlevideo.com. > Escape character is '^]'. > Connection closed by foreign host. > > [~]# telnet rijksoverheid.nl 443 > Trying 2a00:d00:3:2::116... > Connected to rijksoverheid.nl. > Escape character is '^]'. > ^] > telnet> quit > Connection closed. > """ > > Thijs Stuurman > Infrastructure & Solutions > > IS (internedservices) Group > Wielingenstraat 8 | 1441 ZR Purmerend | The Netherlands > T: +31(0)299476185 | M: +31(0)624366778 > W: https://www.is.nl | L: http://nl.linkedin.com/in/thijsstuurman > > > -----Oorspronkelijk bericht----- > Van: NANOG [mailto:nanog-bounces at nanog.org] Namens Niels Bakker > Verzonden: Friday, November 6, 2015 3:14 PM > Aan: nanog at nanog.org > Onderwerp: Re: Youtube CDN unreachable over IPv6 > > It's not just you, I'm seeing the same thing from my home connection > in AS3265. I think this started happening not long ago when Google > had an issue with one of their AMS-IX connections. > > % telnet -6 r7---sn-5hne6n7y.googlevideo.com 443 > Trying 2a00:1450:401c:8::c... > > I'm certain it's not AS3265 who is to blame here, an ISP I've had > pretty much zero issues with over, IPv6 or otherwise, the many years > I've been a customer. > > > -- Niels. > > * seth.mos at dds.nl (Seth Mos) [Fri 06 Nov 2015, 09:00 CET]: > >Dear Google, > > > >It appears that one of the Youtube CDN's (in Europe, NL) is not > >reachable over IPv6 from AS 20844. Can someone get back to us on this, > >the company can't access any of the videos currently, although the > >mainpage loads fine (over IPv6). > > > >Kind regards, > > > >Seth > > > >telnet r6---sn-5hne6n76.googlevideo.com 443 > >Trying 2a00:1450:401c:4::b... > >telnet: connect to address 2a00:1450:401c:4::b: Connection timed out > >Trying 74.125.100.203... > >Connected to r6.sn-5hne6n76.googlevideo.com (74.125.100.203). > >Escape character is '^]'. > >Connection closed by foreign host. > > > >telnet www.youtube.com 443 > >Trying 2a00:1450:4013:c01::5d... > >Connected to youtube-ui.l.google.com (2a00:1450:4013:c01::5d). > >Escape character is '^]'. > >Connection closed by foreign host. > From yang.yu.list at gmail.com Fri Nov 6 18:19:29 2015 From: yang.yu.list at gmail.com (Yang Yu) Date: Fri, 6 Nov 2015 12:19:29 -0600 Subject: Route leaks from AS9498 (BHARTI Airtel)? In-Reply-To: References: Message-ID: On Fri, Nov 6, 2015 at 9:38 AM, Andrew Duey wrote: > Is anyone else seeing their routes leaked from AS9498 (BHARTI Airtel) in > India? > > According to bgpmon.net they started leaking our Level 3 provided IP space > at 2015-11-06 05:52 UTC. Oddly, they're not leaking our ARIN assigned IP > blocks but our prefixes inside the 8.0.0.0/8 range they are (8.34.96.0/21 > and 8.33.2.0/24). > Yes I saw the same thing. Level 3 customer space inside 8.0.0.0/8 got leaked by AS9498 through 174, 4323, 5580 and 12989. I did got alerts from bgpmon but the event is not shown on bgpstream.com. What are the criteria for listing on bgpstream.com? Yang From me at anuragbhatia.com Fri Nov 6 18:21:39 2015 From: me at anuragbhatia.com (Anurag Bhatia) Date: Fri, 6 Nov 2015 23:51:39 +0530 Subject: Route leaks from AS9498 (BHARTI Airtel)? In-Reply-To: <20151106154342.GS21786@Vurt.local> References: <20151106154342.GS21786@Vurt.local> Message-ID: Yes seems like the case. Right now quite a few Akamai prefixes are visible (too many makes it seems like a leak case) + 5.83.40.0/24 On Fri, Nov 6, 2015 at 9:13 PM, Job Snijders wrote: > On Fri, Nov 06, 2015 at 09:38:52AM -0600, Andrew Duey wrote: > > Is anyone else seeing their routes leaked from AS9498 (BHARTI Airtel) in > > India? > > > > According to bgpmon.net they started leaking our Level 3 provided IP > space > > at 2015-11-06 05:52 UTC. Oddly, they're not leaking our ARIN assigned IP > > blocks but our prefixes inside the 8.0.0.0/8 range they are ( > 8.34.96.0/21 > > and 8.33.2.0/24). > > > > BGPmon shows less of their probes are now showing the announcement and we > > haven't seen a noticeable hit in overall traffic levels. > > > > Has anyone else seen this route leak? Is it somehow specific to just the > > big Level 3 blocks? (4.0.0.0/8 and 8.0.0.0/8)? I figured NANOG would > have > > a thread on it already but haven't heard a whisper (unless all the new > guys > > like me are being modded thanks to the spam incident). > > Andree already did a good write-up: > > http://www.bgpmon.net/large-scale-bgp-hijack-out-of-india/ > > Kind regards, > > Job > -- Anurag Bhatia anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From crschmidt at google.com Fri Nov 6 18:17:48 2015 From: crschmidt at google.com (Christopher Schmidt) Date: Fri, 6 Nov 2015 13:17:48 -0500 Subject: Youtube CDN unreachable over IPv6 In-Reply-To: References: <563C5DE5.60505@dds.nl> <20151106141403.GG3097@excession.tpb.net> Message-ID: Hi all, Thanks for the reports. To the best of our knowledge, this issue has been resolved at this time. If you are still having problems connecting to YouTube CDN nodes, please feel free to let me know, and I will investigate further. On Fri, Nov 6, 2015 at 12:48 PM, Blair Trosper wrote: > This was happening two weeks ago in the Bay Area as well. It happens quite > a lot, actually...search for my old threads. I gave up trying to get it > noticed. Blair, I'm not aware of a similar issue with IPv6 being unavailable while IPv4 is available recently. I did not see any threads with information in them with the name "Blair" attached in either the October archive (http://mailman.nanog.org/pipermail/nanog/2015-October/thread.html) or the September archive (http://mailman.nanog.org/pipermail/nanog/2015-September/thread.html) . If this issue is ongoing, I would be happy to look into this; otherwise, I don't believe there is any action I can take to assist at this time. All the best. >> * seth.mos at dds.nl (Seth Mos) [Fri 06 Nov 2015, 09:00 CET]: >> >Dear Google, >> > >> >It appears that one of the Youtube CDN's (in Europe, NL) is not >> >reachable over IPv6 from AS 20844. Can someone get back to us on this, >> >the company can't access any of the videos currently, although the >> >mainpage loads fine (over IPv6). >> > >> >Kind regards, >> > >> >Seth >> > >> >telnet r6---sn-5hne6n76.googlevideo.com 443 >> >Trying 2a00:1450:401c:4::b... >> >telnet: connect to address 2a00:1450:401c:4::b: Connection timed out >> >Trying 74.125.100.203... >> >Connected to r6.sn-5hne6n76.googlevideo.com (74.125.100.203). >> >Escape character is '^]'. >> >Connection closed by foreign host. >> > >> >telnet www.youtube.com 443 >> >Trying 2a00:1450:4013:c01::5d... >> >Connected to youtube-ui.l.google.com (2a00:1450:4013:c01::5d). >> >Escape character is '^]'. >> >Connection closed by foreign host. >> -- Christopher Schmidt YouTube Quality of Experience From andree+nanog at toonk.nl Fri Nov 6 19:31:47 2015 From: andree+nanog at toonk.nl (Andree Toonk) Date: Fri, 06 Nov 2015 11:31:47 -0800 Subject: Route leaks from AS9498 (BHARTI Airtel)? In-Reply-To: References: Message-ID: <563D0023.2080003@toonk.nl> Hi Yang, My secret spy satellite informs me that Yang Yu wrote On 2015-11-06, 10:19 AM: > Yes I saw the same thing. Level 3 customer space inside 8.0.0.0/8 got > leaked by AS9498 through 174, 4323, 5580 and 12989. > > I did got alerts from bgpmon but the event is not shown on > bgpstream.com. What are the criteria for listing on bgpstream.com? Great question! We set out to build a tool that would provide a 'clean' feed of BGP events. The goal of bgpstream.com is to give folks an idea of what's going on in the world of BGP and in large scale cases like this, to show that you're not alone, instead many other networks were affected as well. So you'd go there to see if others see the same. We're still tuning the system, the hardest part is to figure out what is a 'suspicious' origin AS change and what is 'probably' ok. We have several checks and balances in place, for example GEO based info (expected ASn in US, new ASn in India). Historical info (did the AS ever announce other prefixes for the expected AS). Peering relations (customer - upstream relationship?). Obvious we check the several RIR/IRR databases, check for overlapping names / email addresses in those records. And a bunch more. All those heuristic combined determine if this is a 'suspicious' origin AS change (hijack) or not. With this we have a fairly good list of events that are worth looking into as a human. It's very easy to create a list of hundreds of events a day, but many will be perfectly fine and the goal was to have a handful of actionable events. As a result we do throttle the number of events that are published on bgpstream.com in cases of large scale incidents. That's what happened to the events this morning. We have 130 AS9498 events in BGPstream today, that's all that's the admin max today for a given AS. Just to be clear: we did detect many more events, alerted all our users, but only publish 130 per AS per day on bgpstream.com to prevent cluttering. At least for now :) Cheers, Andree (BGPmon.net) From jwbensley at gmail.com Fri Nov 6 19:34:14 2015 From: jwbensley at gmail.com (James Bensley) Date: Fri, 6 Nov 2015 19:34:14 +0000 Subject: Long-haul 100Mbps EPL circuit throughput issue In-Reply-To: References: Message-ID: On 5 Nov 2015 21:50, "Eric Dugas" wrote: > > Hello NANOG, > > We've been dealing with an interesting throughput issue with one of our > carrier. Specs and topology: > > 100Mbps EPL, fiber from a national carrier. We do MPLS to the CPE providing > a VRF circuit to our customer back to our data center through our MPLS > network. Circuit has 75 ms of latency since it's around 5000km. > > Linux test machine in customer's VRF <-> SRX100 <-> Carrier CPE (Cisco > 2960G) <-> Carrier's MPLS network <-> NNI - MX80 <-> Our MPLS network <-> > Terminating edge - MX80 <-> Distribution switch - EX3300 <-> Linux test > machine in customer's VRF > > We can full the link in UDP traffic with iperf but with TCP, we can reach > 80-90% and then the traffic drops to 50% and slowly increase up to 90%. > > Any one have dealt with this kind of problem in the past? We've tested by > forcing ports to 100-FD at both ends, policing the circuit on our side, > called the carrier and escalated to L2/L3 support. They tried to also > police the circuit but as far as I know, they didn't modify anything else. > I've told our support to make them look for underrun errors on their Cisco > switch and they can see some. They're pretty much in the same boat as us > and they're not sure where to look at. > > Thanks > Eric Hi Eric, Sounds like a TCP problem off the top of my head, however just throwing it out there, we use a mix of wholesale access circuit providers and carriers for locations we haven't PoP'ed and we are an LLU provider (CLEC in US terms). For such issues I have been developing an app to test below TCP/UDP and for pseudowires testing etc: https://github.com/jwbensley/Etherate It may or may not shed some light when you have an underlying problem (although yours sounds TCP related). Cheers, James. From amekkaoui at mektel.ca Sat Nov 7 07:18:47 2015 From: amekkaoui at mektel.ca (A MEKKAOUI) Date: Sat, 7 Nov 2015 02:18:47 -0500 Subject: IP Addresses Message-ID: <003701d1192c$8bcfc580$a36f5080$@ca> Hi Anyone can help on how to get IP addresses, purchase or lease or any broker who can help. Your help will be appreciated. Thank you KARIM From starwars1070 at gmail.com Sat Nov 7 09:33:18 2015 From: starwars1070 at gmail.com (samaul carman) Date: Sat, 7 Nov 2015 01:33:18 -0800 Subject: century link ipv6 Message-ID: <271801d1193f$5667eae0$0337c0a0$@gmail.com> Hello I am writing to y'all in regards to based on my understanding that does not happen on a ipv6 dsl network however I may be wrong about that I am still learning about ipv6 in my college courses however I have been noticing that these only occur on cable network based on my google searches however like I said I may be wrong I have century link service and I am using an asus rt68p ac1900 router the modem is in transpartent bridging and I use ppoe for my connection protocol please excuse me if I made any errors on the post to this list you may contact me off list if you like Nov 6 kernel: net_ratelimit: 979 callbacks suppressed Nov 6 19:50:55 kernel: net_ratelimit: 307 callbacks suppressed Nov 6 19:51:01 kernel: net_ratelimit: 320 callbacks suppressed Nov 6 19:56:29 kernel: net_ratelimit: 93 callbacks suppressed Nov 6 19:56:34 kernel: net_ratelimit: 418 callbacks suppressed Nov 6 19:56:39 kernel: net_ratelimit: 169 callbacks suppressed Nov 6 19:56:44 kernel: net_ratelimit: 391 callbacks suppressed Nov 6 19:56:49 kernel: net_ratelimit: 389 callbacks suppressed Nov 6 19:56:58 kernel: net_ratelimit: 97 callbacks suppressed Nov 6 19:57:03 kernel: net_ratelimit: 439 callbacks suppressed Nov 6 19:57:17 kernel: net_ratelimit: 231 callbacks suppressed Nov 6 19:57:48 kernel: net_ratelimit: 261 callbacks suppressed Nov 6 20:02:19 kernel: net_ratelimit: 157 callbacks suppressed Nov 6 20:02:24 kernel: net_ratelimit: 75 callbacks suppressed Nov 6 20:02:29 kernel: net_ratelimit: 412 callbacks suppressed Nov 6 20:02:34 kernel: net_ratelimit: 439 callbacks suppressed Nov 6 20:02:39 kernel: net_ratelimit: 360 callbacks suppressed Nov 6 20:02:51 kernel: net_ratelimit: 219 callbacks suppressed Nov 6 20:02:56 kernel: net_ratelimit: 345 callbacks suppressed Nov 6 20:03:06 kernel: net_ratelimit: 89 callbacks suppressed Nov 6 20:03:11 kernel: net_ratelimit: 420 callbacks suppressed Nov 6 20:04:33 kernel: net_ratelimit: 180 callbacks suppressed Nov 6 20:04:46 kernel: net_ratelimit: 166 callbacks suppressed Nov 6 20:04:57 kernel: net_ratelimit: 140 callbacks suppressed Nov 6 20:05:02 kernel: net_ratelimit: 142 callbacks suppressed Nov 6 20:05:19 kernel: net_ratelimit: 159 callbacks suppressed Nov 6 20:05:49 kernel: net_ratelimit: 73 callbacks suppressed Nov 6 20:05:58 kernel: net_ratelimit: 76 callbacks suppressed Nov 6 20:06:13 kernel: net_ratelimit: 278 callbacks suppressed Nov 6 20:06:18 kernel: net_ratelimit: 50 callbacks suppressed Nov 6 20:06:32 kernel: net_ratelimit: 173 callbacks suppressed Nov 6 20:07:01 kernel: net_ratelimit: 173 callbacks suppressed Nov 6 20:08:14 kernel: net_ratelimit: 353 callbacks suppressed Nov 6 20:08:19 kernel: net_ratelimit: 149 callbacks suppressed Nov 6 20:08:29 kernel: net_ratelimit: 53 callbacks suppressed Nov 6 20:08:35 kernel: net_ratelimit: 228 callbacks suppressed Nov 6 20:09:32 kernel: net_ratelimit: 398 callbacks suppressed Nov 6 20:10:20 kernel: net_ratelimit: 258 callbacks suppressed Nov 6 20:10:31 kernel: net_ratelimit: 25 callbacks suppressed Nov 6 20:16:45 kernel: net_ratelimit: 301 callbacks suppressed Nov 6 20:16:50 kernel: net_ratelimit: 423 callbacks suppressed Nov 6 20:16:57 kernel: net_ratelimit: 64 callbacks suppressed Nov 6 20:17:02 kernel: net_ratelimit: 440 callbacks suppressed Nov 6 20:17:09 kernel: net_ratelimit: 298 callbacks suppressed Nov 6 20:17:14 kernel: net_ratelimit: 439 callbacks suppressed Nov 6 20:17:19 kernel: net_ratelimit: 112 callbacks suppressed Nov 6 20:17:24 kernel: net_ratelimit: 146 callbacks suppressed Nov 6 20:17:29 kernel: net_ratelimit: 427 callbacks suppressed Nov 6 20:17:34 kernel: net_ratelimit: 405 callbacks suppressed Nov 6 20:17:46 kernel: net_ratelimit: 93 callbacks suppressed From joelja at bogus.com Sat Nov 7 21:03:24 2015 From: joelja at bogus.com (joel jaeggli) Date: Sun, 8 Nov 2015 06:03:24 +0900 Subject: century link ipv6 In-Reply-To: <271801d1193f$5667eae0$0337c0a0$@gmail.com> References: <271801d1193f$5667eae0$0337c0a0$@gmail.com> Message-ID: <563E671C.8060500@bogus.com> On 11/7/15 6:33 PM, samaul carman wrote: > Hello I am writing to y'all in regards to based on my understanding that > does not happen on a ipv6 dsl network however I may be wrong about that I am > still learning about ipv6 in my college courses however I have been noticing > that these only occur on cable network based on my google searches however > like I said I may be wrong I have century link service and I am using an > asus rt68p ac1900 router the modem is in transpartent bridging and I use > ppoe for my connection protocol please excuse me if I made any errors on the > post to this list you may contact me off list if you like The kernel is suppressing boatload of syslog messages from being emitted due to rate limiting... Somewhere in the logging is the actual message followed by it being suppressed. http://fxr.watson.org/fxr/source/lib/ratelimit.c?v=linux-2.6 > > Nov 6 kernel: net_ratelimit: 979 callbacks suppressed > Nov 6 19:50:55 kernel: net_ratelimit: 307 callbacks suppressed > > Nov 6 19:51:01 kernel: net_ratelimit: 320 callbacks suppressed > > Nov 6 19:56:29 kernel: net_ratelimit: 93 callbacks suppressed > > Nov 6 19:56:34 kernel: net_ratelimit: 418 callbacks suppressed > > Nov 6 19:56:39 kernel: net_ratelimit: 169 callbacks suppressed > > Nov 6 19:56:44 kernel: net_ratelimit: 391 callbacks suppressed > > Nov 6 19:56:49 kernel: net_ratelimit: 389 callbacks suppressed > > Nov 6 19:56:58 kernel: net_ratelimit: 97 callbacks suppressed > > Nov 6 19:57:03 kernel: net_ratelimit: 439 callbacks suppressed > > Nov 6 19:57:17 kernel: net_ratelimit: 231 callbacks suppressed > > Nov 6 19:57:48 kernel: net_ratelimit: 261 callbacks suppressed > > Nov 6 20:02:19 kernel: net_ratelimit: 157 callbacks suppressed > > Nov 6 20:02:24 kernel: net_ratelimit: 75 callbacks suppressed > > Nov 6 20:02:29 kernel: net_ratelimit: 412 callbacks suppressed > > Nov 6 20:02:34 kernel: net_ratelimit: 439 callbacks suppressed > > Nov 6 20:02:39 kernel: net_ratelimit: 360 callbacks suppressed > > Nov 6 20:02:51 kernel: net_ratelimit: 219 callbacks suppressed > > Nov 6 20:02:56 kernel: net_ratelimit: 345 callbacks suppressed > > Nov 6 20:03:06 kernel: net_ratelimit: 89 callbacks suppressed > > Nov 6 20:03:11 kernel: net_ratelimit: 420 callbacks suppressed > > Nov 6 20:04:33 kernel: net_ratelimit: 180 callbacks suppressed > > Nov 6 20:04:46 kernel: net_ratelimit: 166 callbacks suppressed > > Nov 6 20:04:57 kernel: net_ratelimit: 140 callbacks suppressed > > Nov 6 20:05:02 kernel: net_ratelimit: 142 callbacks suppressed > > Nov 6 20:05:19 kernel: net_ratelimit: 159 callbacks suppressed > > Nov 6 20:05:49 kernel: net_ratelimit: 73 callbacks suppressed > > Nov 6 20:05:58 kernel: net_ratelimit: 76 callbacks suppressed > > Nov 6 20:06:13 kernel: net_ratelimit: 278 callbacks suppressed > > Nov 6 20:06:18 kernel: net_ratelimit: 50 callbacks suppressed > > Nov 6 20:06:32 kernel: net_ratelimit: 173 callbacks suppressed > > Nov 6 20:07:01 kernel: net_ratelimit: 173 callbacks suppressed > > Nov 6 20:08:14 kernel: net_ratelimit: 353 callbacks suppressed > > Nov 6 20:08:19 kernel: net_ratelimit: 149 callbacks suppressed > > Nov 6 20:08:29 kernel: net_ratelimit: 53 callbacks suppressed > > Nov 6 20:08:35 kernel: net_ratelimit: 228 callbacks suppressed > > Nov 6 20:09:32 kernel: net_ratelimit: 398 callbacks suppressed > > Nov 6 20:10:20 kernel: net_ratelimit: 258 callbacks suppressed > > Nov 6 20:10:31 kernel: net_ratelimit: 25 callbacks suppressed > > Nov 6 20:16:45 kernel: net_ratelimit: 301 callbacks suppressed > > Nov 6 20:16:50 kernel: net_ratelimit: 423 callbacks suppressed > > Nov 6 20:16:57 kernel: net_ratelimit: 64 callbacks suppressed > > Nov 6 20:17:02 kernel: net_ratelimit: 440 callbacks suppressed > > Nov 6 20:17:09 kernel: net_ratelimit: 298 callbacks suppressed > > Nov 6 20:17:14 kernel: net_ratelimit: 439 callbacks suppressed > > Nov 6 20:17:19 kernel: net_ratelimit: 112 callbacks suppressed > > Nov 6 20:17:24 kernel: net_ratelimit: 146 callbacks suppressed > > Nov 6 20:17:29 kernel: net_ratelimit: 427 callbacks suppressed > > Nov 6 20:17:34 kernel: net_ratelimit: 405 callbacks suppressed > > Nov 6 20:17:46 kernel: net_ratelimit: 93 callbacks suppressed > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From blair.trosper at gmail.com Sun Nov 8 18:47:11 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Sun, 8 Nov 2015 12:47:11 -0600 Subject: Youtube CDN unreachable over IPv6 In-Reply-To: References: <563C5DE5.60505@dds.nl> <20151106141403.GG3097@excession.tpb.net> Message-ID: It was 2014-05-17 on this list, and went on to be handled at GGC, where it's come up now and then. On Fri, Nov 6, 2015 at 12:17 PM, Christopher Schmidt wrote: > Hi all, > > Thanks for the reports. > > To the best of our knowledge, this issue has been resolved at this > time. If you are still having problems connecting to YouTube CDN > nodes, please feel free to let me know, and I will investigate > further. > > On Fri, Nov 6, 2015 at 12:48 PM, Blair Trosper > wrote: > > This was happening two weeks ago in the Bay Area as well. It happens > quite > > a lot, actually...search for my old threads. I gave up trying to get it > > noticed. > > Blair, > > I'm not aware of a similar issue with IPv6 being unavailable while > IPv4 is available recently. > > I did not see any threads with information in them with the name > "Blair" attached in either the October archive > (http://mailman.nanog.org/pipermail/nanog/2015-October/thread.html) or > the September archive > (http://mailman.nanog.org/pipermail/nanog/2015-September/thread.html) > . > > If this issue is ongoing, I would be happy to look into this; > otherwise, I don't believe there is any action I can take to assist at > this time. > > All the best. > > > >> * seth.mos at dds.nl (Seth Mos) [Fri 06 Nov 2015, 09:00 CET]: > >> >Dear Google, > >> > > >> >It appears that one of the Youtube CDN's (in Europe, NL) is not > >> >reachable over IPv6 from AS 20844. Can someone get back to us on this, > >> >the company can't access any of the videos currently, although the > >> >mainpage loads fine (over IPv6). > >> > > >> >Kind regards, > >> > > >> >Seth > >> > > >> >telnet r6---sn-5hne6n76.googlevideo.com 443 > >> >Trying 2a00:1450:401c:4::b... > >> >telnet: connect to address 2a00:1450:401c:4::b: Connection timed out > >> >Trying 74.125.100.203... > >> >Connected to r6.sn-5hne6n76.googlevideo.com (74.125.100.203). > >> >Escape character is '^]'. > >> >Connection closed by foreign host. > >> > > >> >telnet www.youtube.com 443 > >> >Trying 2a00:1450:4013:c01::5d... > >> >Connected to youtube-ui.l.google.com (2a00:1450:4013:c01::5d). > >> >Escape character is '^]'. > >> >Connection closed by foreign host. > >> > > -- > Christopher Schmidt > YouTube Quality of Experience > From ybabenko3 at gmail.com Mon Nov 9 13:47:26 2015 From: ybabenko3 at gmail.com (Yuriy Babenko) Date: Mon, 9 Nov 2015 14:47:26 +0100 Subject: [TECH] Pica8 & Cumulus Networks In-Reply-To: References: <56371694.4080904@castle-it.fr> Message-ID: An easy start with Cumulus can be their VirtualBox image which can be found here https://cumulusnetworks.com/cumulus-vx/ This allows an easy start for a small evaluation PoC. On 3 November 2015 at 01:35, Ian Clark wrote: > On Sun, Nov 1, 2015 at 11:53 PM, Yoann THOMAS > wrote: > > > Hello everyone, > > > > Under a Cloud project I ask myself to use equipment based on the Pica8 or > > Cumulus Networks. > > > > All in order to mount a Spine & Leaf architecture > > > > - Spine 40Gbps > > - Leaf in 10Gbps > > > > Someone of you there a feedback on this equipment. > > > > We've had a lot of success running Cumulus gear in cloudy production > environments. They're easy to manage with infrastructure automation tools > and perform as well as any other switch with the same hardware. There are > a few features missing from the current general availability code (VRF is > the main one for us), but the guys and gals at Cumulus are pretty > responsive to requests for new features and I know that VRF is on its way. > The main advantage IMO is the huge price break for 10g and 40g ports when > compared with the other major players. > > -- > Ian Clark > Lead Network Engineer > DreamHost > From clecny at gmail.com Mon Nov 9 14:49:42 2015 From: clecny at gmail.com (Jay Patel) Date: Mon, 9 Nov 2015 09:49:42 -0500 Subject: Favorite GPON Vendor? Message-ID: Who is your favorite GPON OLT/ONU Vendor? Why? I am looking for recommendations I apologize in advance , if you feel my question is inappropriate for this mailing list ( feel free to point me to right forum/mailing list). Regards, Jay. From ecrogers at precisionds.com Mon Nov 9 18:09:55 2015 From: ecrogers at precisionds.com (Eric Rogers) Date: Mon, 9 Nov 2015 13:09:55 -0500 Subject: Favorite GPON Vendor? References: Message-ID: I Personally would like to know as well. We are just getting into GPON and the equipment we have been evaluating is clunky at best... It came highly recommended and supposed to be stable. Eric Rogers PDS Connect www.pdsconnect.me (317) 831-3000 x200 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay Patel Sent: Monday, November 9, 2015 9:50 AM To: nanog at nanog.org Subject: Favorite GPON Vendor? Who is your favorite GPON OLT/ONU Vendor? Why? I am looking for recommendations I apologize in advance , if you feel my question is inappropriate for this mailing list ( feel free to point me to right forum/mailing list). Regards, Jay. From briansupport at hotmail.com Mon Nov 9 19:25:44 2015 From: briansupport at hotmail.com (Brian R) Date: Mon, 9 Nov 2015 19:25:44 +0000 Subject: Favorite GPON Vendor? In-Reply-To: References: , Message-ID: We use the Adtran ONT solutions. We are using AE (Active Ethernet) not GPON but the solutions are similar for Adtran. We are providing IP and Analog this way. If used in the specified scope only there have been very little problems. Adtran is constantly updating their firmware, this can be a positive and negative at times. LoL The configuration is Adtran TA5000 with an Active Ethernet 24-Port Module (1187562F1) feeding an ONT TA324E (1287737G2) at the customer premise. For power we are using the Cyber Power CSN27U12v-NA3 units. The clam shell we are using to put the ONT in is TA350 ONT NID HSG SPLICE (1187770G1) All of these part numbers should be available on Adtrans website to look up. We are also testing some iPhotonix ONTs but have not gotten to the point we are sure we want to deploy them. Brian PS I will post this in voiceops as well (it may be more relevant there) ________________________________________ From: NANOG on behalf of Eric Rogers Sent: Monday, November 9, 2015 10:09 AM To: Jay Patel; nanog at nanog.org Subject: RE: Favorite GPON Vendor? I Personally would like to know as well. We are just getting into GPON and the equipment we have been evaluating is clunky at best... It came highly recommended and supposed to be stable. Eric Rogers PDS Connect www.pdsconnect.me (317) 831-3000 x200 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay Patel Sent: Monday, November 9, 2015 9:50 AM To: nanog at nanog.org Subject: Favorite GPON Vendor? Who is your favorite GPON OLT/ONU Vendor? Why? I am looking for recommendations I apologize in advance , if you feel my question is inappropriate for this mailing list ( feel free to point me to right forum/mailing list). Regards, Jay. From lorell at hathcock.org Mon Nov 9 21:27:20 2015 From: lorell at hathcock.org (Lorell Hathcock) Date: Mon, 9 Nov 2015 15:27:20 -0600 Subject: Updated Ookla Speedtest Server Requirements Message-ID: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> Esteemed Legions of NANOG: Does anyone have better and more modern recommendations for the hardware of an Ookla speedtest server? Here is the link to their recommendations. http://www.ookla.com/support/a26461638/ I want a server that is capable of handlilng a speedtest up to 10Gbps. I plan to do this with an SFP+ port when my network comes along. (As soon as MikroTik comes out with a decent 10G CCR router that is compatible with more SFPs.) In the mean time I will just test 1 Gbps speeds off a copper GE port, but want the SFP+ capability so I don't have to repurchase hardware in the next year. Thanks! Sincerely, Lorell Hathcock Chief Technology Officer SolStar Network, LLC Communications FIBER - VOIP - SECURITY - TV FTTH - Commercial - Residential Burglar - Access Control 956-478-5955 (cell) - 956-316-4090 (main) lorell at SolStarNetwork.com www.SolStarNetwork.com TX License #B19998 From dave.taht at gmail.com Mon Nov 9 21:38:06 2015 From: dave.taht at gmail.com (Dave Taht) Date: Mon, 9 Nov 2015 16:38:06 -0500 Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> References: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> Message-ID: I dearly would like them to update the software to include a similar bufferbloat related test to what dslreports is doing. http://www.dslreports.com/speedtest/results/bufferbloat?up=1 If you'd like a dslreports server instead... I know who to contact. :) Dave T?ht Let's go make home routers and wifi faster! With better software! https://www.gofundme.com/savewifi On Mon, Nov 9, 2015 at 4:27 PM, Lorell Hathcock wrote: > Esteemed Legions of NANOG: > > > > Does anyone have better and more modern recommendations for the hardware of > an Ookla speedtest server? > > > > Here is the link to their recommendations. > > > > http://www.ookla.com/support/a26461638/ > > > > I want a server that is capable of handlilng a speedtest up to 10Gbps. I > plan to do this with an SFP+ port when my network comes along. (As soon as > MikroTik comes out with a decent 10G CCR router that is compatible with more > SFPs.) > > > > In the mean time I will just test 1 Gbps speeds off a copper GE port, but > want the SFP+ capability so I don't have to repurchase hardware in the next > year. > > > > Thanks! > > > > Sincerely, > > > > Lorell Hathcock > > Chief Technology Officer > > > > > > > SolStar Network, LLC > > Communications > > FIBER - VOIP - SECURITY - TV > > FTTH - Commercial - Residential > > Burglar - Access Control > > 956-478-5955 (cell) - 956-316-4090 (main) > > lorell at SolStarNetwork.com > > www.SolStarNetwork.com > > TX License #B19998 > > > > > > > > > > > > > From gary.buhrmaster at gmail.com Mon Nov 9 22:02:12 2015 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Mon, 9 Nov 2015 22:02:12 +0000 Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: References: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> Message-ID: On Mon, Nov 9, 2015 at 9:38 PM, Dave Taht wrote: > I dearly would like them to update the software to .... not require flash. Last I knew ookla still required flash, and one should just say no to flash. Dslreports (and other speed tests) work with modern browser technologies without flash or java. From dhc2 at dcrocker.net Mon Nov 9 22:12:28 2015 From: dhc2 at dcrocker.net (Dave Crocker) Date: Mon, 9 Nov 2015 14:12:28 -0800 Subject: RDAP adoption? Message-ID: <56411A4C.5050202@dcrocker.net> Not sure whether this is a permitted query for the list... I'm trying to discover the field maturity of RDAP. How much deployment of servers supporting it is there, but also how much querying from clients is happening? Any sense of the adoption/use trends? Thanks (and maybe apologies.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nanogml at Mail.DDoS-Mitigator.net Mon Nov 9 22:26:21 2015 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Mon, 9 Nov 2015 14:26:21 -0800 Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> References: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> Message-ID: <20151109222621.GA10453@Mail.DDoS-Mitigator.net> hi lorell On 11/09/15 at 03:27pm, Lorell Hathcock wrote: > Esteemed Legions of NANOG: > ... > Here is the link to their recommendations. > http://www.ookla.com/support/a26461638/ ... > In the mean time I will just test 1 Gbps speeds off a copper GE port, but > want the SFP+ capability so I don't have to repurchase hardware in the next > year. also in the meantime, while waiting for the fiber stuff to be built out, you could use a $400 copper-based 10gigE pci card too magix pixie dust alvin http://DDoS-Mitigator.net From tom at ninjabadger.net Mon Nov 9 22:32:20 2015 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 9 Nov 2015 22:32:20 +0000 Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: <20151109222621.GA10453@Mail.DDoS-Mitigator.net> References: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> <20151109222621.GA10453@Mail.DDoS-Mitigator.net> Message-ID: <56411EF4.9070700@ninjabadger.net> On 09/11/15 22:26, alvin nanog wrote: > also in the meantime, while waiting for the fiber stuff to be built out, > you could use a $400 copper-based 10gigE pci card too PCI's a bit too slow for 10Gbit/sec - I'd definitely opt for PCI-E. -- Tom From josh at imaginenetworksllc.com Mon Nov 9 22:35:55 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 9 Nov 2015 17:35:55 -0500 Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: <56411EF4.9070700@ninjabadger.net> References: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> <20151109222621.GA10453@Mail.DDoS-Mitigator.net> <56411EF4.9070700@ninjabadger.net> Message-ID: You can't get SFP+ PCI cards anyways. I don't think you can very easily get boards with PCI on them, either. I expect he was just typing it out and left the "E" =) Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mon, Nov 9, 2015 at 5:32 PM, Tom Hill wrote: > On 09/11/15 22:26, alvin nanog wrote: > > also in the meantime, while waiting for the fiber stuff to be built out, > > you could use a $400 copper-based 10gigE pci card too > > PCI's a bit too slow for 10Gbit/sec - I'd definitely opt for PCI-E. > > -- > Tom > From tom at ninjabadger.net Mon Nov 9 22:51:51 2015 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 9 Nov 2015 22:51:51 +0000 Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: References: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> <20151109222621.GA10453@Mail.DDoS-Mitigator.net> <56411EF4.9070700@ninjabadger.net> Message-ID: <56412387.5000505@ninjabadger.net> On 09/11/15 22:35, Josh Luthman wrote: > I expect he was just typing it out and left the "E" =) ;) I can't see Mikrotik taking stock in 10GBASE-T on their CCRs any time soon, either. -- Tom From nanogml at Mail.DDoS-Mitigator.net Mon Nov 9 23:44:02 2015 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Mon, 9 Nov 2015 15:44:02 -0800 Subject: Updated Ookla Speedtest Server Requirements Message-ID: <20151109234402.GA29338@Mail.DDoS-Mitigator.net> On 11/09/15 at 05:35pm, Josh Luthman wrote: > You can't get SFP+ PCI cards anyways. I don't think you can very easily > get boards with PCI on them, either. lots of vendors w/ PCIe 10gigE cards w/ copper or SFP+ interface .. very few ( almost none ) for explicitly PCI w/ 10gigE and more importantly i usually get intel chipset based SFP+ PCI-e x8 based dual-10gigE cards similarly, for dual 10gigE copper for testing on gigE infrastructcure not many "tyan/supermicro" motherboards with dual-gigE SFP+ connectors ( our primary requirement is dual-nic 10gigE ports squeezed into 1U chassis ) yes, it could be slow ... and most likely not even run at "bit speeds" quoted by marketing, but not everybody goes around measuring bandwidth speeds similarly, not much marketing anymore for 3.xGhz or 4.xGhz or 6.xGhz Ghz "cpu speeds" and lately, past decade, how many cores can you squeeze into 1sq inch which is trivially easy to count and measure cores and it's performance :-) PCIe-3.x spec'd at 8Gbit/s # x8 would easily give you 40Gbit/s PCIe-2.x spec'd at 4Gbit/s PCIe-1.x spec'd at 2Gbit/s PCIe x1 == 2Gbit/s ( per lane ) PCIe x4 == "combined" 8Gbit/s PCIe x8 == "combined" 16Gbit/s ( common PCIe cards ) PCIe x16 == "combined" 32Gbit/s PCIe x32 == "combined" 64Gbit/s > I expect he was just typing it out and left the "E" =) just being brain-dead lazy w/ assumptions and PCI vs PCIe does make a big difference with network thruput magic pixie dust alvin # Custom 1U chassis w/ zero drives and up to 8 drives ----- End forwarded message ----- From jschiel at flowtools.net Mon Nov 9 23:52:46 2015 From: jschiel at flowtools.net (John Schiel) Date: Mon, 9 Nov 2015 16:52:46 -0700 Subject: century link ipv6 In-Reply-To: <271801d1193f$5667eae0$0337c0a0$@gmail.com> References: <271801d1193f$5667eae0$0337c0a0$@gmail.com> Message-ID: <564131CE.1060000@flowtools.net> I don't think it's your provider, check your hardware. http://zszsit.blogspot.com.br/2012/10/ratelimit-callbacks-suppressed.html (link provided by an associate) --John On 11/07/2015 02:33 AM, samaul carman wrote: > Hello I am writing to y'all in regards to based on my understanding that > does not happen on a ipv6 dsl network however I may be wrong about that I am > still learning about ipv6 in my college courses however I have been noticing > that these only occur on cable network based on my google searches however > like I said I may be wrong I have century link service and I am using an > asus rt68p ac1900 router the modem is in transpartent bridging and I use > ppoe for my connection protocol please excuse me if I made any errors on the > post to this list you may contact me off list if you like > > Nov 6 kernel: net_ratelimit: 979 callbacks suppressed > Nov 6 19:50:55 kernel: net_ratelimit: 307 callbacks suppressed > > Nov 6 19:51:01 kernel: net_ratelimit: 320 callbacks suppressed > > Nov 6 19:56:29 kernel: net_ratelimit: 93 callbacks suppressed > > Nov 6 19:56:34 kernel: net_ratelimit: 418 callbacks suppressed > > Nov 6 19:56:39 kernel: net_ratelimit: 169 callbacks suppressed > > Nov 6 19:56:44 kernel: net_ratelimit: 391 callbacks suppressed > > Nov 6 19:56:49 kernel: net_ratelimit: 389 callbacks suppressed > > Nov 6 19:56:58 kernel: net_ratelimit: 97 callbacks suppressed > > Nov 6 19:57:03 kernel: net_ratelimit: 439 callbacks suppressed > > Nov 6 19:57:17 kernel: net_ratelimit: 231 callbacks suppressed > > Nov 6 19:57:48 kernel: net_ratelimit: 261 callbacks suppressed > > Nov 6 20:02:19 kernel: net_ratelimit: 157 callbacks suppressed > > Nov 6 20:02:24 kernel: net_ratelimit: 75 callbacks suppressed > > Nov 6 20:02:29 kernel: net_ratelimit: 412 callbacks suppressed > > Nov 6 20:02:34 kernel: net_ratelimit: 439 callbacks suppressed > > Nov 6 20:02:39 kernel: net_ratelimit: 360 callbacks suppressed > > Nov 6 20:02:51 kernel: net_ratelimit: 219 callbacks suppressed > > Nov 6 20:02:56 kernel: net_ratelimit: 345 callbacks suppressed > > Nov 6 20:03:06 kernel: net_ratelimit: 89 callbacks suppressed > > Nov 6 20:03:11 kernel: net_ratelimit: 420 callbacks suppressed > > Nov 6 20:04:33 kernel: net_ratelimit: 180 callbacks suppressed > > Nov 6 20:04:46 kernel: net_ratelimit: 166 callbacks suppressed > > Nov 6 20:04:57 kernel: net_ratelimit: 140 callbacks suppressed > > Nov 6 20:05:02 kernel: net_ratelimit: 142 callbacks suppressed > > Nov 6 20:05:19 kernel: net_ratelimit: 159 callbacks suppressed > > Nov 6 20:05:49 kernel: net_ratelimit: 73 callbacks suppressed > > Nov 6 20:05:58 kernel: net_ratelimit: 76 callbacks suppressed > > Nov 6 20:06:13 kernel: net_ratelimit: 278 callbacks suppressed > > Nov 6 20:06:18 kernel: net_ratelimit: 50 callbacks suppressed > > Nov 6 20:06:32 kernel: net_ratelimit: 173 callbacks suppressed > > Nov 6 20:07:01 kernel: net_ratelimit: 173 callbacks suppressed > > Nov 6 20:08:14 kernel: net_ratelimit: 353 callbacks suppressed > > Nov 6 20:08:19 kernel: net_ratelimit: 149 callbacks suppressed > > Nov 6 20:08:29 kernel: net_ratelimit: 53 callbacks suppressed > > Nov 6 20:08:35 kernel: net_ratelimit: 228 callbacks suppressed > > Nov 6 20:09:32 kernel: net_ratelimit: 398 callbacks suppressed > > Nov 6 20:10:20 kernel: net_ratelimit: 258 callbacks suppressed > > Nov 6 20:10:31 kernel: net_ratelimit: 25 callbacks suppressed > > Nov 6 20:16:45 kernel: net_ratelimit: 301 callbacks suppressed > > Nov 6 20:16:50 kernel: net_ratelimit: 423 callbacks suppressed > > Nov 6 20:16:57 kernel: net_ratelimit: 64 callbacks suppressed > > Nov 6 20:17:02 kernel: net_ratelimit: 440 callbacks suppressed > > Nov 6 20:17:09 kernel: net_ratelimit: 298 callbacks suppressed > > Nov 6 20:17:14 kernel: net_ratelimit: 439 callbacks suppressed > > Nov 6 20:17:19 kernel: net_ratelimit: 112 callbacks suppressed > > Nov 6 20:17:24 kernel: net_ratelimit: 146 callbacks suppressed > > Nov 6 20:17:29 kernel: net_ratelimit: 427 callbacks suppressed > > Nov 6 20:17:34 kernel: net_ratelimit: 405 callbacks suppressed > > Nov 6 20:17:46 kernel: net_ratelimit: 93 callbacks suppressed > > > From aplato at coldwater.org Mon Nov 9 19:38:38 2015 From: aplato at coldwater.org (Art Plato) Date: Mon, 9 Nov 2015 14:38:38 -0500 (EST) Subject: Favorite GPON Vendor? In-Reply-To: References: Message-ID: <22699042.434.1447097920305.JavaMail.art@DQT6ZQ1> Brian, How complex is the troubleshooting side of the Adtran? We Use the Enablence Wave7 and getting any useful information from the CPE via the CLI is like pulling hens teeth. I have yet to see a way to view the actual throughput on the ethernet interfaces, only total bits passed, or the light levels at the CPE fiber interface. A bit annoying actually. It means a truck roll to get light levels at the CPE. Art. ----- Original Message ----- From: "Brian R" To: "Eric Rogers" , "Jay Patel" Cc: nanog at nanog.org Sent: Monday, November 9, 2015 2:25:44 PM Subject: Re: Favorite GPON Vendor? We use the Adtran ONT solutions. We are using AE (Active Ethernet) not GPON but the solutions are similar for Adtran. We are providing IP and Analog this way. If used in the specified scope only there have been very little problems. Adtran is constantly updating their firmware, this can be a positive and negative at times. LoL The configuration is Adtran TA5000 with an Active Ethernet 24-Port Module (1187562F1) feeding an ONT TA324E (1287737G2) at the customer premise. For power we are using the Cyber Power CSN27U12v-NA3 units. The clam shell we are using to put the ONT in is TA350 ONT NID HSG SPLICE (1187770G1) All of these part numbers should be available on Adtrans website to look up. We are also testing some iPhotonix ONTs but have not gotten to the point we are sure we want to deploy them. Brian PS I will post this in voiceops as well (it may be more relevant there) ________________________________________ From: NANOG on behalf of Eric Rogers Sent: Monday, November 9, 2015 10:09 AM To: Jay Patel; nanog at nanog.org Subject: RE: Favorite GPON Vendor? I Personally would like to know as well. We are just getting into GPON and the equipment we have been evaluating is clunky at best... It came highly recommended and supposed to be stable. Eric Rogers PDS Connect www.pdsconnect.me (317) 831-3000 x200 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay Patel Sent: Monday, November 9, 2015 9:50 AM To: nanog at nanog.org Subject: Favorite GPON Vendor? Who is your favorite GPON OLT/ONU Vendor? Why? I am looking for recommendations I apologize in advance , if you feel my question is inappropriate for this mailing list ( feel free to point me to right forum/mailing list). Regards, Jay. From tritran at cox.net Mon Nov 9 23:13:24 2015 From: tritran at cox.net (Tri Tran) Date: Mon, 9 Nov 2015 15:13:24 -0800 Subject: ISPs for US BANK TOWER in LA Message-ID: <56412894.5050004@cox.net> Hello everyone, Need to quickly turn up circuit. I've only been able to confirm these are in the bldg: TWC, ATT, Level3, and Cogent. CaInternet is the only who can turn up quickly but now sure how good their ClearFiber is. If anyone know of others, please share or PM me. Thank you --Tri From baldur.norddahl at gmail.com Tue Nov 10 01:11:36 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 10 Nov 2015 02:11:36 +0100 Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> References: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> Message-ID: The speedtest.net is flash based. Many computers struggle to measure 1g speed and not because the network is slow. I think you will find it very hard to get a 10g measure. If you like us just want to be sure your 1g users get 1g even when other users are running parallel tests, you do not need to worry too much about the server. It needs a 10g NIC but it does not need to perform more than 2g if even that. You will simply not have that many parallel tests running at any given time. Regards Baldur Den 9. nov. 2015 22.27 skrev "Lorell Hathcock" : > Esteemed Legions of NANOG: > > > > Does anyone have better and more modern recommendations for the hardware of > an Ookla speedtest server? > > > > Here is the link to their recommendations. > > > > http://www.ookla.com/support/a26461638/ > > > > I want a server that is capable of handlilng a speedtest up to 10Gbps. I > plan to do this with an SFP+ port when my network comes along. (As soon as > MikroTik comes out with a decent 10G CCR router that is compatible with > more > SFPs.) > > > > In the mean time I will just test 1 Gbps speeds off a copper GE port, but > want the SFP+ capability so I don't have to repurchase hardware in the next > year. > > > > Thanks! > > > > Sincerely, > > > > Lorell Hathcock > > Chief Technology Officer > > > > > > > SolStar Network, LLC > > Communications > > FIBER - VOIP - SECURITY - TV > > FTTH - Commercial - Residential > > Burglar - Access Control > > 956-478-5955 (cell) - 956-316-4090 (main) > > lorell at SolStarNetwork.com > > www.SolStarNetwork.com > > TX License #B19998 > > > > > > > > > > > > > > From lorell at hathcock.org Tue Nov 10 01:19:09 2015 From: lorell at hathcock.org (Lorell Hathcock) Date: Mon, 9 Nov 2015 19:19:09 -0600 Subject: Fwd: Updated Ookla Speedtest Server Requirements References: <3A171327-34E4-4E49-BC34-B6906A06CEB7@hathcock.org> Message-ID: <05BF09C5-F623-4AB0-AF92-CF5D162C1747@hathcock.org> Sent from my iPhone Begin forwarded message: > From: Lorell Hathcock > Date: November 9, 2015 at 7:18:31 PM CST > To: Jose Gerardo Perales Soto > Subject: Re: Updated Ookla Speedtest Server Requirements > > Jose: > > This is what I was looking for. I assume you have a PCI-E SFP+ cage line card in that bad boy? > > Lorell > > Sent from my iPhone > >> On Nov 9, 2015, at 7:13 PM, Jose Gerardo Perales Soto wrote: >> >> Currently using IBM/LENOVO x3550 / 12 GB RAM / 2 x Xeon E5620 >> >> 10GbE uplink currently handling ~2gbps peak traffic. >> >> - Gerardo >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lorell Hathcock >> Sent: Monday, November 09, 2015 3:27 PM >> To: 'NANOG list' >> Subject: Updated Ookla Speedtest Server Requirements >> >> Esteemed Legions of NANOG: >> >> >> >> Does anyone have better and more modern recommendations for the hardware of an Ookla speedtest server? >> >> >> >> Here is the link to their recommendations. >> >> >> >> http://www.ookla.com/support/a26461638/ >> >> >> >> I want a server that is capable of handlilng a speedtest up to 10Gbps. I plan to do this with an SFP+ port when my network comes along. (As soon as MikroTik comes out with a decent 10G CCR router that is compatible with more >> SFPs.) >> >> >> >> In the mean time I will just test 1 Gbps speeds off a copper GE port, but want the SFP+ capability so I don't have to repurchase hardware in the next year. >> >> >> >> Thanks! >> >> >> >> Sincerely, >> >> >> >> Lorell Hathcock >> >> Chief Technology Officer >> >> >> >> >> >> >> SolStar Network, LLC >> >> Communications >> >> FIBER - VOIP - SECURITY - TV >> >> FTTH - Commercial - Residential >> >> Burglar - Access Control >> >> 956-478-5955 (cell) - 956-316-4090 (main) >> >> lorell at SolStarNetwork.com >> >> www.SolStarNetwork.com >> >> TX License #B19998 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ________________________________ >> >> El contenido del presente correo electr?nico es de car?cter confidencial, privado y propiedad de AXTEL, S.A.B. de C.V., por lo que en caso de haber recibido el presente por error, o de no ser el destinatario del mismo, por favor h?galo saber al remitente, e igualmente elimine y no almacene en forma alguna la informaci?n aqu? contenida. As? mismo, el contenido del presente correo no genera obligaci?n alguna a cargo de AXTEL, S.A.B. de C.V., de cualquiera de sus subsidiarias o del remitente. From nanog at ics-il.net Tue Nov 10 04:13:18 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 9 Nov 2015 22:13:18 -0600 (CST) Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> Message-ID: <834127038.635.1447128821005.JavaMail.mhammett@ThunderFuck> I haven't heard much as far as CCR 10G incompatibility issues. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Lorell Hathcock" To: "NANOG list" Sent: Monday, November 9, 2015 3:27:20 PM Subject: Updated Ookla Speedtest Server Requirements Esteemed Legions of NANOG: Does anyone have better and more modern recommendations for the hardware of an Ookla speedtest server? Here is the link to their recommendations. http://www.ookla.com/support/a26461638/ I want a server that is capable of handlilng a speedtest up to 10Gbps. I plan to do this with an SFP+ port when my network comes along. (As soon as MikroTik comes out with a decent 10G CCR router that is compatible with more SFPs.) In the mean time I will just test 1 Gbps speeds off a copper GE port, but want the SFP+ capability so I don't have to repurchase hardware in the next year. Thanks! Sincerely, Lorell Hathcock Chief Technology Officer SolStar Network, LLC Communications FIBER - VOIP - SECURITY - TV FTTH - Commercial - Residential Burglar - Access Control 956-478-5955 (cell) - 956-316-4090 (main) lorell at SolStarNetwork.com www.SolStarNetwork.com TX License #B19998 From Valdis.Kletnieks at vt.edu Tue Nov 10 05:00:06 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 10 Nov 2015 00:00:06 -0500 Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> References: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> Message-ID: <18706.1447131606@turing-police.cc.vt.edu> On Mon, 09 Nov 2015 15:27:20 -0600, "Lorell Hathcock" said: > I want a server that is capable of handlilng a speedtest up to 10Gbps. Do you have (or are planning to have) a clear 10G path to enough systems that want to use speedtest specifically to make it worthwhile? We have a lot of gear reachable at high speeds, but the admins of those servers usually care more about iperf and similar than speedtest..... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From morrowc.lists at gmail.com Tue Nov 10 05:25:50 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 10 Nov 2015 16:25:50 +1100 Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: <18706.1447131606@turing-police.cc.vt.edu> References: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> <18706.1447131606@turing-police.cc.vt.edu> Message-ID: imagine lorell has a userbase on his ISP service of lots of 100mbps or 1gbps customers. Imagine some percentage of them want to test their network speeds. Imagine enough of them are trying at peak times that 1gbps to the 'speed test server' is not enough bandwidth. Perhaps he could instead run 10 servers or a 10g loadbalancer and 10 1g boxes behind that loadbalancer? On Tue, Nov 10, 2015 at 4:00 PM, wrote: > On Mon, 09 Nov 2015 15:27:20 -0600, "Lorell Hathcock" said: > >> I want a server that is capable of handlilng a speedtest up to 10Gbps. > > Do you have (or are planning to have) a clear 10G path to enough systems that > want to use speedtest specifically to make it worthwhile? We have a lot of > gear reachable at high speeds, but the admins of those servers usually care > more about iperf and similar than speedtest..... > From hank at efes.iucc.ac.il Tue Nov 10 06:15:39 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 10 Nov 2015 08:15:39 +0200 Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> Message-ID: <5.1.1.6.2.20151110080401.002caff8@efes.iucc.ac.il> At 15:27 09/11/2015 -0600, Lorell Hathcock wrote: >Esteemed Legions of NANOG: > >Does anyone have better and more modern recommendations for the hardware of >an Ookla speedtest server? > >Here is the link to their recommendations. > >http://www.ookla.com/support/a26461638/ After 5 happy years of using Speedtest, we had to drop them this year for a 2 reasons. a) they tripled their price b) their site which used to provide an excellent comparison between ISPs - at www.netindex.com was discontinued for some stripped down 4 country comparison site - http://www.speedtest.net/awards when it used have over 120 countries. The value of Ookla dropped significantly so we just let our license lapse and did what everyone else was doing and pointed our speedtest to: http://uk2.testmy.net/SmarTest/combinedAuto and manage with this free service just fine. -Hank From johnl at iecc.com Tue Nov 10 08:29:53 2015 From: johnl at iecc.com (John Levine) Date: 10 Nov 2015 08:29:53 -0000 Subject: RDAP adoption? In-Reply-To: <56411A4C.5050202@dcrocker.net> Message-ID: <20151110082953.64486.qmail@ary.lan> >How much deployment of servers supporting it is there, but also how much >querying from clients is happening? Any sense of the adoption/use trends? All of the RIRs have RDAP servers, all nominally for testing but in fact working pretty well give or take nits. In Yokahama we went through a list of comments on ICANN's rules for RDAP servers so I expect we'll be seeing gTLD servers pretty soon. R's, John From shawnl at up.net Tue Nov 10 13:27:46 2015 From: shawnl at up.net (Shawn L) Date: Tue, 10 Nov 2015 08:27:46 -0500 (EST) Subject: =?utf-8?Q?Re=3A_Favorite_GPON_Vendor=3F?= In-Reply-To: <22699042.434.1447097920305.JavaMail.art@DQT6ZQ1> References: <22699042.434.1447097920305.JavaMail.art@DQT6ZQ1> Message-ID: <1447162066.647710320@upnet.mymailsrvr.com> We like Calix's gpon gear, especially the E7 series. Though it's on the higher side price-wise than others. Manageable through their CMS software, the web, or command line. We tend to use their CMS software for most things, but the CLI is decent, and gives you access to anything you'd want. -----Original Message----- From: "Art Plato" Sent: Monday, November 9, 2015 2:38pm To: Cc: nanog at nanog.org Subject: Re: Favorite GPON Vendor? Brian, How complex is the troubleshooting side of the Adtran? We Use the Enablence Wave7 and getting any useful information from the CPE via the CLI is like pulling hens teeth. I have yet to see a way to view the actual throughput on the ethernet interfaces, only total bits passed, or the light levels at the CPE fiber interface. A bit annoying actually. It means a truck roll to get light levels at the CPE. Art. ----- Original Message ----- From: "Brian R" To: "Eric Rogers" , "Jay Patel" Cc: nanog at nanog.org Sent: Monday, November 9, 2015 2:25:44 PM Subject: Re: Favorite GPON Vendor? We use the Adtran ONT solutions. We are using AE (Active Ethernet) not GPON but the solutions are similar for Adtran. We are providing IP and Analog this way. If used in the specified scope only there have been very little problems. Adtran is constantly updating their firmware, this can be a positive and negative at times. LoL The configuration is Adtran TA5000 with an Active Ethernet 24-Port Module (1187562F1) feeding an ONT TA324E (1287737G2) at the customer premise. For power we are using the Cyber Power CSN27U12v-NA3 units. The clam shell we are using to put the ONT in is TA350 ONT NID HSG SPLICE (1187770G1) All of these part numbers should be available on Adtrans website to look up. We are also testing some iPhotonix ONTs but have not gotten to the point we are sure we want to deploy them. Brian PS I will post this in voiceops as well (it may be more relevant there) ________________________________________ From: NANOG on behalf of Eric Rogers Sent: Monday, November 9, 2015 10:09 AM To: Jay Patel; nanog at nanog.org Subject: RE: Favorite GPON Vendor? I Personally would like to know as well. We are just getting into GPON and the equipment we have been evaluating is clunky at best... It came highly recommended and supposed to be stable. Eric Rogers PDS Connect www.pdsconnect.me (317) 831-3000 x200 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay Patel Sent: Monday, November 9, 2015 9:50 AM To: nanog at nanog.org Subject: Favorite GPON Vendor? Who is your favorite GPON OLT/ONU Vendor? Why? I am looking for recommendations I apologize in advance , if you feel my question is inappropriate for this mailing list ( feel free to point me to right forum/mailing list). Regards, Jay. From aplato at coldwater.org Tue Nov 10 13:32:53 2015 From: aplato at coldwater.org (Art Plato) Date: Tue, 10 Nov 2015 08:32:53 -0500 (EST) Subject: Favorite GPON Vendor? In-Reply-To: <1447162066.647710320@upnet.mymailsrvr.com> References: <22699042.434.1447097920305.JavaMail.art@DQT6ZQ1> <1447162066.647710320@upnet.mymailsrvr.com> Message-ID: <341782.18.1447162373976.JavaMail.art@DQT6ZQ1> Awesome. Thanks for the feedback Brian. Price is important, but not the be all of the consideration process. Troubleshooting ease matters just as much. ----- Original Message ----- From: "Shawn L" To: "nanog" Sent: Tuesday, November 10, 2015 8:27:46 AM Subject: Re: Favorite GPON Vendor? We like Calix's gpon gear, especially the E7 series. Though it's on the higher side price-wise than others. Manageable through their CMS software, the web, or command line. We tend to use their CMS software for most things, but the CLI is decent, and gives you access to anything you'd want. -----Original Message----- From: "Art Plato" Sent: Monday, November 9, 2015 2:38pm To: Cc: nanog at nanog.org Subject: Re: Favorite GPON Vendor? Brian, How complex is the troubleshooting side of the Adtran? We Use the Enablence Wave7 and getting any useful information from the CPE via the CLI is like pulling hens teeth. I have yet to see a way to view the actual throughput on the ethernet interfaces, only total bits passed, or the light levels at the CPE fiber interface. A bit annoying actually. It means a truck roll to get light levels at the CPE. Art. ----- Original Message ----- From: "Brian R" To: "Eric Rogers" , "Jay Patel" Cc: nanog at nanog.org Sent: Monday, November 9, 2015 2:25:44 PM Subject: Re: Favorite GPON Vendor? We use the Adtran ONT solutions. We are using AE (Active Ethernet) not GPON but the solutions are similar for Adtran. We are providing IP and Analog this way. If used in the specified scope only there have been very little problems. Adtran is constantly updating their firmware, this can be a positive and negative at times. LoL The configuration is Adtran TA5000 with an Active Ethernet 24-Port Module (1187562F1) feeding an ONT TA324E (1287737G2) at the customer premise. For power we are using the Cyber Power CSN27U12v-NA3 units. The clam shell we are using to put the ONT in is TA350 ONT NID HSG SPLICE (1187770G1) All of these part numbers should be available on Adtrans website to look up. We are also testing some iPhotonix ONTs but have not gotten to the point we are sure we want to deploy them. Brian PS I will post this in voiceops as well (it may be more relevant there) ________________________________________ From: NANOG on behalf of Eric Rogers Sent: Monday, November 9, 2015 10:09 AM To: Jay Patel; nanog at nanog.org Subject: RE: Favorite GPON Vendor? I Personally would like to know as well. We are just getting into GPON and the equipment we have been evaluating is clunky at best... It came highly recommended and supposed to be stable. Eric Rogers PDS Connect www.pdsconnect.me (317) 831-3000 x200 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay Patel Sent: Monday, November 9, 2015 9:50 AM To: nanog at nanog.org Subject: Favorite GPON Vendor? Who is your favorite GPON OLT/ONU Vendor? Why? I am looking for recommendations I apologize in advance , if you feel my question is inappropriate for this mailing list ( feel free to point me to right forum/mailing list). Regards, Jay. From lorell at hathcock.org Tue Nov 10 13:34:56 2015 From: lorell at hathcock.org (Lorell Hathcock) Date: Tue, 10 Nov 2015 07:34:56 -0600 Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: <18706.1447131606@turing-police.cc.vt.edu> References: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> <18706.1447131606@turing-police.cc.vt.edu> Message-ID: <10b601d11bbc$96e24d70$c4a6e850$@hathcock.org> Good point. There will be no one customer that can get a 10G speedtest from us. But there will be hundreds that should be able to get a 1G test. Should any of them try simultaneously, I want to be ready. Plus I don't know what miscellaneous speedtests from the net to expect, so I want to affordably overbuild. -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Monday, November 9, 2015 11:00 PM To: Lorell Hathcock Cc: 'NANOG list' Subject: Re: Updated Ookla Speedtest Server Requirements On Mon, 09 Nov 2015 15:27:20 -0600, "Lorell Hathcock" said: > I want a server that is capable of handlilng a speedtest up to 10Gbps. Do you have (or are planning to have) a clear 10G path to enough systems that want to use speedtest specifically to make it worthwhile? We have a lot of gear reachable at high speeds, but the admins of those servers usually care more about iperf and similar than speedtest..... From lorell at hathcock.org Tue Nov 10 13:35:36 2015 From: lorell at hathcock.org (Lorell Hathcock) Date: Tue, 10 Nov 2015 07:35:36 -0600 Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: References: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> <18706.1447131606@turing-police.cc.vt.edu> Message-ID: <10b701d11bbc$ae830a00$0b891e00$@hathcock.org> Good question. -----Original Message----- From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: Monday, November 9, 2015 11:26 PM To: Valdis Kletnieks Cc: Lorell Hathcock ; NANOG list Subject: Re: Updated Ookla Speedtest Server Requirements imagine lorell has a userbase on his ISP service of lots of 100mbps or 1gbps customers. Imagine some percentage of them want to test their network speeds. Imagine enough of them are trying at peak times that 1gbps to the 'speed test server' is not enough bandwidth. Perhaps he could instead run 10 servers or a 10g loadbalancer and 10 1g boxes behind that loadbalancer? On Tue, Nov 10, 2015 at 4:00 PM, wrote: > On Mon, 09 Nov 2015 15:27:20 -0600, "Lorell Hathcock" said: > >> I want a server that is capable of handlilng a speedtest up to 10Gbps. > > Do you have (or are planning to have) a clear 10G path to enough > systems that want to use speedtest specifically to make it worthwhile? > We have a lot of gear reachable at high speeds, but the admins of > those servers usually care more about iperf and similar than speedtest..... > From morrowc.lists at gmail.com Tue Nov 10 15:13:05 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 11 Nov 2015 02:13:05 +1100 Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: <10b601d11bbc$96e24d70$c4a6e850$@hathcock.org> References: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> <18706.1447131606@turing-police.cc.vt.edu> <10b601d11bbc$96e24d70$c4a6e850$@hathcock.org> Message-ID: it sounds like horizontal scaling with redundancy and potentially geographic distriubution on your network would be your big friend here. On Wed, Nov 11, 2015 at 12:34 AM, Lorell Hathcock wrote: > Good point. There will be no one customer that can get a 10G speedtest from > us. But there will be hundreds that should be able to get a 1G test. > Should any of them try simultaneously, I want to be ready. Plus I don't > know what miscellaneous speedtests from the net to expect, so I want to > affordably overbuild. > > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Monday, November 9, 2015 11:00 PM > To: Lorell Hathcock > Cc: 'NANOG list' > Subject: Re: Updated Ookla Speedtest Server Requirements > > On Mon, 09 Nov 2015 15:27:20 -0600, "Lorell Hathcock" said: > >> I want a server that is capable of handlilng a speedtest up to 10Gbps. > > Do you have (or are planning to have) a clear 10G path to enough systems > that want to use speedtest specifically to make it worthwhile? We have a > lot of gear reachable at high speeds, but the admins of those servers > usually care more about iperf and similar than speedtest..... > > From richb.hanover at gmail.com Tue Nov 10 15:54:22 2015 From: richb.hanover at gmail.com (Rich Brown) Date: Tue, 10 Nov 2015 10:54:22 -0500 Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: References: Message-ID: <94E02753-2481-4340-8B20-B9F434BFDCA5@gmail.com> > On Nov 10, 2015, at 7:00 AM, Hank Nussbacher wrote: > > The value of Ookla dropped significantly so we just let our license lapse > and did what everyone else was doing and pointed our speedtest to: > http://uk2.testmy.net/SmarTest/combinedAuto > and manage with this free service just fine. You might consider pointing people to the DSLReports Speed Test (www.dslreports.com/speedtest) - It is also free (no cost), and HTML-based. - It's graphically far more attractive than testmy.net - It's easier for people to use. Click one button: it automatically selects the nearest test server and runs all the tests. - It retains test history, so your customers can compare today's tests with earlier runs. - It measures latency *under load*, which really affects a lot of people's perception of "network speed". - I find DSLReports to be more accurate than testmy.net. In several runs today, testmy.net results average 90% of the up/download speeds seen by DSLReports, Ookla, and netperf measurements on my 7mbps/768kbps DSL connection. -Rich From baldur.norddahl at gmail.com Tue Nov 10 16:30:25 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 10 Nov 2015 17:30:25 +0100 Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: <10b601d11bbc$96e24d70$c4a6e850$@hathcock.org> References: <0dcd01d11b35$6ad844f0$4088ced0$@hathcock.org> <18706.1447131606@turing-police.cc.vt.edu> <10b601d11bbc$96e24d70$c4a6e850$@hathcock.org> Message-ID: On 10 November 2015 at 14:34, Lorell Hathcock wrote: > Good point. There will be no one customer that can get a 10G speedtest > from > us. But there will be hundreds that should be able to get a 1G test. > Should any of them try simultaneously, I want to be ready. Plus I don't > know what miscellaneous speedtests from the net to expect, so I want to > affordably overbuild. > Here is a MRTG from the server that serves gigabit.speedtest.net: http://ballerup1.gigabit.dk/ballerup-core1-xgei3.png This is a 10G interface. The server is used by our users that include many 1G users. You are unable to see that because the speed test is much less than 1 minute in duration (1 minute is the sampling period for the graph) . Also you see the speed tests done by everyone else that uses our server. As you can see you do not need to worry too much about the traffic levels. You would be very unlucky to have two 1G users doing a test at exact the same time. It would be extremely unlikely that you have MORE than two 1G users doing a test in parallel. The tests are simply not that long and people do not run test all day long. They try it a few times, and then again a few times to show off for their friends or during troubleshooting. Based on this experience I will say that you do need a server with 10G interface (like ours) but you would not need to worry much about the performance of that server. Just about any server with a PCIe interface will be able to serve static files with the required speed on a 10G interface. Use something modern like nginx and you are set. The required performance is 1G for one of your own 1G users doing a test plus the background noise from the external tests, which means that you would get a good test with just 1.1G of performance :-). Regards, Baldur From joe at breathe-underwater.com Tue Nov 10 17:28:09 2015 From: joe at breathe-underwater.com (Joseph Jenkins) Date: Tue, 10 Nov 2015 09:28:09 -0800 Subject: Google Captcha on web searches Message-ID: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> We started getting a Google Captcha for our web searches this morning. Does anyone have contact info for Google so that I can contact them and figure out where the traffic is coming from on my side or what service it is going to so that I can track down the users? Thanks, Joe Jenkins 909.636.2097 From hugo at slabnet.com Tue Nov 10 17:47:41 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 10 Nov 2015 09:47:41 -0800 Subject: Google Captcha on web searches In-Reply-To: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> References: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> Message-ID: <20151110174741.GC20793@bamboo.slabnet.com> On Tue 2015-Nov-10 09:28:09 -0800, Joseph Jenkins wrote: >We started getting a Google Captcha for our web searches this morning. Does anyone have contact info for Google so that I can contact them and figure out where the traffic is coming from on my side or what service it is going to so that I can track down the users? Out of curiosity: Is this happening with IPv6-capable hosts? We've had instances where Google flags our dual stack hosts and pops up Captcha's like you're reporting when connecting via v6, but where we've never had problems accessing their services from the same host(s) over v4. Flipping the affected host's browser over to using v4 using a browser extension let's them access Google services again. https://support.google.com/websearch/answer/86640?hl=en is too generic/vague to give any specifics of why Google decided the user's v6 IP is put on the nasty list (or even whether it's their IP specifically or something larger like a /64). > >Thanks, > >Joe Jenkins >909.636.2097 > -- Hugo hugo at slabnet.com: email, xmpp/jabber PGP fingerprint (B178313E): CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E (also on Signal) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From josh at imaginenetworksllc.com Tue Nov 10 17:48:26 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Tue, 10 Nov 2015 12:48:26 -0500 Subject: Google Captcha on web searches In-Reply-To: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> References: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> Message-ID: It's done per /32 I believe. Do you have a lot of NATed users? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Nov 10, 2015 12:29 PM, "Joseph Jenkins" wrote: > We started getting a Google Captcha for our web searches this morning. > Does anyone have contact info for Google so that I can contact them and > figure out where the traffic is coming from on my side or what service it > is going to so that I can track down the users? > > Thanks, > > Joe Jenkins > 909.636.2097 > > From joe at breathe-underwater.com Tue Nov 10 17:51:49 2015 From: joe at breathe-underwater.com (Joseph Jenkins) Date: Tue, 10 Nov 2015 09:51:49 -0800 Subject: Google Captcha on web searches In-Reply-To: References: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> Message-ID: I have about a 600 users. We aren?t dual stick only ipv4 at this point. Someone contacted me off list and gave me some insight as to what to key on. Joe > On Nov 10, 2015, at 9:48 AM, Josh Luthman wrote: > > It's done per /32 I believe. Do you have a lot of NATed users? > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Nov 10, 2015 12:29 PM, "Joseph Jenkins" > wrote: > We started getting a Google Captcha for our web searches this morning. Does anyone have contact info for Google so that I can contact them and figure out where the traffic is coming from on my side or what service it is going to so that I can track down the users? > > Thanks, > > Joe From shopik at inblock.ru Tue Nov 10 18:09:02 2015 From: shopik at inblock.ru (Nikolay Shopik) Date: Tue, 10 Nov 2015 21:09:02 +0300 Subject: Google Captcha on web searches In-Reply-To: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> References: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> Message-ID: <564232BE.3040408@inblock.ru> You may get captcha if you are using popular open dns services. At least this is what I've seen. On 10/11/2015 20:28, Joseph Jenkins wrote: > We started getting a Google Captcha for our web searches this morning. Does anyone have contact info for Google so that I can contact them and figure out where the traffic is coming from on my side or what service it is going to so that I can track down the users? > > Thanks, > > Joe Jenkins > 909.636.2097 > From network at cwo.com Tue Nov 10 17:24:14 2015 From: network at cwo.com (CWO Network Operations) Date: Tue, 10 Nov 2015 09:24:14 -0800 Subject: Global Crossing / Level 3 Contact Message-ID: <7385E1C9-2B13-4C69-A274-B5CB1EA8C08B@cwo.com> Greetings, Some of my BGP announcements are suppressed at Global Crossing/Level 3. I have no idea why they would be suppressed, since my announcements (routes) are fine everywhere else and I?m not aware of any issues. Since I?m not peering with Level 3, it?s hard to get to anyone useful at Level 3. Feel free to contact me off list Thanks JB From nwarren at barryelectric.com Tue Nov 10 17:33:18 2015 From: nwarren at barryelectric.com (Nicholas Warren) Date: Tue, 10 Nov 2015 17:33:18 +0000 Subject: Google Captcha on web searches In-Reply-To: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> References: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> Message-ID: We had that problem too, it was only happening to computers with a NATed v4 address. Connecting to Google over IPv6 made the problems go away. Thank you, - Nich > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joseph Jenkins > Sent: Tuesday, November 10, 2015 11:28 AM > To: nanog at nanog.org > Subject: Google Captcha on web searches > > We started getting a Google Captcha for our web searches this morning. > Does anyone have contact info for Google so that I can contact them and > figure out where the traffic is coming from on my side or what service it > is going to so that I can track down the users? > > Thanks, > > Joe Jenkins > 909.636.2097 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4845 bytes Desc: not available URL: From r.engehausen at gmail.com Tue Nov 10 18:49:11 2015 From: r.engehausen at gmail.com (Roy) Date: Tue, 10 Nov 2015 11:49:11 -0700 Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: <94E02753-2481-4340-8B20-B9F434BFDCA5@gmail.com> References: <94E02753-2481-4340-8B20-B9F434BFDCA5@gmail.com> Message-ID: <56423C27.3040200@gmail.com> On 11/10/2015 8:54 AM, Rich Brown wrote: >> On Nov 10, 2015, at 7:00 AM, Hank Nussbacher wrote: >> >> The value of Ookla dropped significantly so we just let our license lapse >> and did what everyone else was doing and pointed our speedtest to: >> http://uk2.testmy.net/SmarTest/combinedAuto >> and manage with this free service just fine. > You might consider pointing people to the DSLReports Speed Test (www.dslreports.com/speedtest) > > ... My home cable connection testmynet 12/2.4 speedtest.net 94/3.3 dslreports 94/3.4 testmynet is not very accurate From jerome at ceriz.fr Tue Nov 10 19:22:24 2015 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Tue, 10 Nov 2015 20:22:24 +0100 Subject: Favorite GPON Vendor? In-Reply-To: References: Message-ID: <564243F0.5070603@ceriz.fr> Hello Jay, Le 09/11/2015 15:49, Jay Patel a ?crit : > Who is your favorite GPON OLT/ONU Vendor? Why? I am looking for > recommendations I've had great operationnal feedback with Alcatel's gear. Not the old 7302 series, rather the 7360s which support up to 16 ports/slot. The best part is their provisionning system, because it's a "service template" driven logic. It scales well, as long as you don't try to produce L3 services right on the OLT chassis (better trunk to a 7750 SR or any other L3 router). The 7360FX line also has a P2P linecard, which is usefull when you want to serve both residential and business accesses from the same device. Higlights : - Up to 32k GPON subscribers per chassis - Up to 1152 gigabit ports per chassis in PtP setup (ideal for B2B) - Unlimited customers from the same mamangement server (5620SAM, optionnal but worth it past 5+ chassis) On the financial aspects, well, it's surprisingly cheap as soon as you have to scale past the chinese pizabox OLTs. Over 9 trees out of a single PoP, you're definitely more effective with such devices. Best regards, -- J?r?me Nicolle +33 6 19 31 27 14 From briansupport at hotmail.com Tue Nov 10 19:32:48 2015 From: briansupport at hotmail.com (Brian R) Date: Tue, 10 Nov 2015 19:32:48 +0000 Subject: Favorite GPON Vendor? In-Reply-To: <341782.18.1447162373976.JavaMail.art@DQT6ZQ1> References: <22699042.434.1447097920305.JavaMail.art@DQT6ZQ1> <1447162066.647710320@upnet.mymailsrvr.com>, <341782.18.1447162373976.JavaMail.art@DQT6ZQ1> Message-ID: Art, I can't say we have a lot of experience with the Adtran GPON units. On the Active Ethernet side if we assign an IP to the ONT we can view all the stats going back to the TA5K. From the TA5K we can also view the individual Ethernet ports. I will send you directly some examples. I don't think NANOG wants to see a bunch of Adtran "show ..." commands : ] As far as Shawns Calix experiences the last time we tried Calix GPON was 5-6 years ago. The CPE seemed solid but the POP side was in constant need of rebooting and we gave it up after about 8-12 months of customer frustrations. At that time we did not get much help on the problems. Brian ________________________________________ From: NANOG on behalf of Art Plato Sent: Tuesday, November 10, 2015 5:32 AM To: Shawn L Cc: nanog Subject: Re: Favorite GPON Vendor? Awesome. Thanks for the feedback Brian. Price is important, but not the be all of the consideration process. Troubleshooting ease matters just as much. ----- Original Message ----- From: "Shawn L" To: "nanog" Sent: Tuesday, November 10, 2015 8:27:46 AM Subject: Re: Favorite GPON Vendor? We like Calix's gpon gear, especially the E7 series. Though it's on the higher side price-wise than others. Manageable through their CMS software, the web, or command line. We tend to use their CMS software for most things, but the CLI is decent, and gives you access to anything you'd want. -----Original Message----- From: "Art Plato" Sent: Monday, November 9, 2015 2:38pm To: Cc: nanog at nanog.org Subject: Re: Favorite GPON Vendor? Brian, How complex is the troubleshooting side of the Adtran? We Use the Enablence Wave7 and getting any useful information from the CPE via the CLI is like pulling hens teeth. I have yet to see a way to view the actual throughput on the ethernet interfaces, only total bits passed, or the light levels at the CPE fiber interface. A bit annoying actually. It means a truck roll to get light levels at the CPE. Art. ----- Original Message ----- From: "Brian R" To: "Eric Rogers" , "Jay Patel" Cc: nanog at nanog.org Sent: Monday, November 9, 2015 2:25:44 PM Subject: Re: Favorite GPON Vendor? We use the Adtran ONT solutions. We are using AE (Active Ethernet) not GPON but the solutions are similar for Adtran. We are providing IP and Analog this way. If used in the specified scope only there have been very little problems. Adtran is constantly updating their firmware, this can be a positive and negative at times. LoL The configuration is Adtran TA5000 with an Active Ethernet 24-Port Module (1187562F1) feeding an ONT TA324E (1287737G2) at the customer premise. For power we are using the Cyber Power CSN27U12v-NA3 units. The clam shell we are using to put the ONT in is TA350 ONT NID HSG SPLICE (1187770G1) All of these part numbers should be available on Adtrans website to look up. We are also testing some iPhotonix ONTs but have not gotten to the point we are sure we want to deploy them. Brian PS I will post this in voiceops as well (it may be more relevant there) ________________________________________ From: NANOG on behalf of Eric Rogers Sent: Monday, November 9, 2015 10:09 AM To: Jay Patel; nanog at nanog.org Subject: RE: Favorite GPON Vendor? I Personally would like to know as well. We are just getting into GPON and the equipment we have been evaluating is clunky at best... It came highly recommended and supposed to be stable. Eric Rogers PDS Connect www.pdsconnect.me (317) 831-3000 x200 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay Patel Sent: Monday, November 9, 2015 9:50 AM To: nanog at nanog.org Subject: Favorite GPON Vendor? Who is your favorite GPON OLT/ONU Vendor? Why? I am looking for recommendations I apologize in advance , if you feel my question is inappropriate for this mailing list ( feel free to point me to right forum/mailing list). Regards, Jay. From morrowc.lists at gmail.com Tue Nov 10 20:00:37 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 10 Nov 2015 15:00:37 -0500 Subject: Google Captcha on web searches In-Reply-To: <564232BE.3040408@inblock.ru> References: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> <564232BE.3040408@inblock.ru> Message-ID: On Tue, Nov 10, 2015 at 1:09 PM, Nikolay Shopik wrote: > You may get captcha if you are using popular open dns services. At least > this is what I've seen. > pardon, what? > On 10/11/2015 20:28, Joseph Jenkins wrote: >> We started getting a Google Captcha for our web searches this morning. Does anyone have contact info for Google so that I can contact them and figure out where the traffic is coming from on my side or what service it is going to so that I can track down the users? >> >> Thanks, >> >> Joe Jenkins >> 909.636.2097 >> From shopik at inblock.ru Tue Nov 10 20:29:11 2015 From: shopik at inblock.ru (Nikolay Shopik) Date: Tue, 10 Nov 2015 23:29:11 +0300 Subject: Google Captcha on web searches In-Reply-To: References: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> <564232BE.3040408@inblock.ru> Message-ID: <56425397.3040400@inblock.ru> When I've started using DNS from unotelly service, captcha starts appears from time to time. If I change DNS to something else, catcha gone immediately. Its probably related to DNS geo-locating to decide what records serve to client On 10/11/2015 23:00, Christopher Morrow wrote: > On Tue, Nov 10, 2015 at 1:09 PM, Nikolay Shopik wrote: >> You may get captcha if you are using popular open dns services. At least >> this is what I've seen. >> > > pardon, what? > >> On 10/11/2015 20:28, Joseph Jenkins wrote: >>> We started getting a Google Captcha for our web searches this morning. Does anyone have contact info for Google so that I can contact them and figure out where the traffic is coming from on my side or what service it is going to so that I can track down the users? >>> >>> Thanks, >>> >>> Joe Jenkins >>> 909.636.2097 >>> From chris at ipstuff.ca Tue Nov 10 22:43:04 2015 From: chris at ipstuff.ca (Chris Murray) Date: Tue, 10 Nov 2015 14:43:04 -0800 Subject: Google Captcha on web searches In-Reply-To: <56425397.3040400@inblock.ru> References: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> <564232BE.3040408@inblock.ru> <56425397.3040400@inblock.ru> Message-ID: Hi Nikolay, The "popular open dns services" you refer to appear to be Proxy/VPN services that also provide DNS to get around region blocking. These services proxy and/or NAT users behind a single IP address to make it look like you are coming from a different country. I may be biased, but when I think of popular open DNS services I think of OpenDNS or Google DNS, and you should *never* see a captcha as a result of using OpenDNS. Disclaimer: I work for OpenDNS, and while I can't speak to Google DNS, I have never heard of this behaviour with their service either. Just wanted to clarify. - Chris On Tue, Nov 10, 2015 at 12:29 PM, Nikolay Shopik wrote: > When I've started using DNS from unotelly service, captcha starts > appears from time to time. If I change DNS to something else, catcha > gone immediately. > > Its probably related to DNS geo-locating to decide what records serve to > client > > On 10/11/2015 23:00, Christopher Morrow wrote: >> On Tue, Nov 10, 2015 at 1:09 PM, Nikolay Shopik wrote: >>> You may get captcha if you are using popular open dns services. At least >>> this is what I've seen. >>> >> >> pardon, what? >> >>> On 10/11/2015 20:28, Joseph Jenkins wrote: >>>> We started getting a Google Captcha for our web searches this morning. Does anyone have contact info for Google so that I can contact them and figure out where the traffic is coming from on my side or what service it is going to so that I can track down the users? >>>> >>>> Thanks, >>>> >>>> Joe Jenkins >>>> 909.636.2097 >>>> From lorell at hathcock.org Tue Nov 10 22:48:04 2015 From: lorell at hathcock.org (Lorell Hathcock) Date: Tue, 10 Nov 2015 16:48:04 -0600 Subject: Environmental Graph Interpretation Message-ID: <02e901d11c09$dc77d7e0$956787a0$@hathcock.org> NANOG: Are there any one the list that would care to take a look at some graphs of temperature, relative humidity and dew point that I have for two locations. In one of the two locations, I'm having a problem with the floor getting wet (condensation?). At the other everything is just fine. I need to understand what these graphs are telling me about the problem and if a simple dehumidifier would solve my moisture problem. Any takers? Oh, the environmental monitor I installed in each location is the IT Watchdog from Geist Global. I bought the POE version. Installed like a charm and was $229 plus shipping. I do wonder if this question is off topic, but then I can hear myself saying "Hey, I'm Operating a Network, here! In North America!" And then I think, "Yep, on topic!" Thanks, Sincerely, Lorell Hathcock SolStar Network, LLC Communications FIBER - VOIP - SECURITY - TV FTTH - Commercial - Residential Burglar - Access Control 956-478-5955 (cell) - 956-316-4090 (main) lorell at SolStarNetwork.com www.SolStarNetwork.com TX License #B19998 From shopik at inblock.ru Tue Nov 10 23:09:24 2015 From: shopik at inblock.ru (Nikolay Shopik) Date: Wed, 11 Nov 2015 02:09:24 +0300 Subject: Google Captcha on web searches In-Reply-To: References: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> <564232BE.3040408@inblock.ru> <56425397.3040400@inblock.ru> Message-ID: <56427924.7020700@inblock.ru> Hi Chris, Yeah I probably should worded that differently not 'open dns services', sorry about that. In my case there is no proxy/vpn service (i know they can do that), just DNS changes. For some reason that cause false-positive detection in google from time to time. On 11/11/2015 01:43, Chris Murray wrote: > Hi Nikolay, > > The "popular open dns services" you refer to appear to be Proxy/VPN > services that also provide DNS to get around region blocking. These > services proxy and/or NAT users behind a single IP address to make it > look like you are coming from a different country. > > I may be biased, but when I think of popular open DNS services I think > of OpenDNS or Google DNS, and you should *never* see a captcha as a > result of using OpenDNS. Disclaimer: I work for OpenDNS, and while I > can't speak to Google DNS, I have never heard of this behaviour with > their service either. > > Just wanted to clarify. > - Chris > > On Tue, Nov 10, 2015 at 12:29 PM, Nikolay Shopik wrote: >> When I've started using DNS from unotelly service, captcha starts >> appears from time to time. If I change DNS to something else, catcha >> gone immediately. >> >> Its probably related to DNS geo-locating to decide what records serve to >> client >> >> On 10/11/2015 23:00, Christopher Morrow wrote: >>> On Tue, Nov 10, 2015 at 1:09 PM, Nikolay Shopik wrote: >>>> You may get captcha if you are using popular open dns services. At least >>>> this is what I've seen. >>>> >>> >>> pardon, what? >>> >>>> On 10/11/2015 20:28, Joseph Jenkins wrote: >>>>> We started getting a Google Captcha for our web searches this morning. Does anyone have contact info for Google so that I can contact them and figure out where the traffic is coming from on my side or what service it is going to so that I can track down the users? >>>>> >>>>> Thanks, >>>>> >>>>> Joe Jenkins >>>>> 909.636.2097 >>>>> From Valdis.Kletnieks at vt.edu Tue Nov 10 23:13:06 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 10 Nov 2015 18:13:06 -0500 Subject: Environmental Graph Interpretation In-Reply-To: <02e901d11c09$dc77d7e0$956787a0$@hathcock.org> References: <02e901d11c09$dc77d7e0$956787a0$@hathcock.org> Message-ID: <37182.1447197186@turing-police.cc.vt.edu> On Tue, 10 Nov 2015 16:48:04 -0600, "Lorell Hathcock" said: > Are there any one the list that would care to take a look at some graphs of > temperature, relative humidity and dew point that I have for two locations. > In one of the two locations, I'm having a problem with the floor getting wet > (condensation?). At the other everything is just fine. Is your moisture problem on a ground floor? Note that even well-cured concrete is like 30% water, and can allow moisture to slowly migrate through and weep. Usual cure is application of a proper sealant over the concrete. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From lorell at hathcock.org Tue Nov 10 23:25:04 2015 From: lorell at hathcock.org (Lorell Hathcock) Date: Tue, 10 Nov 2015 17:25:04 -0600 Subject: Environmental Graph Interpretation In-Reply-To: <37182.1447197186@turing-police.cc.vt.edu> References: <02e901d11c09$dc77d7e0$956787a0$@hathcock.org> <37182.1447197186@turing-police.cc.vt.edu> Message-ID: <030c01d11c0f$076c72d0$16455870$@hathcock.org> It is on the ground floor, but it is in a hut that has a wood floor that is raised off the ground. There is a gap between the bottom of the floor and the ground. -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Tuesday, November 10, 2015 5:13 PM To: Lorell Hathcock Cc: 'NANOG list' Subject: Re: Environmental Graph Interpretation On Tue, 10 Nov 2015 16:48:04 -0600, "Lorell Hathcock" said: > Are there any one the list that would care to take a look at some > graphs of temperature, relative humidity and dew point that I have for two locations. > In one of the two locations, I'm having a problem with the floor > getting wet (condensation?). At the other everything is just fine. Is your moisture problem on a ground floor? Note that even well-cured concrete is like 30% water, and can allow moisture to slowly migrate through and weep. Usual cure is application of a proper sealant over the concrete. From pete at fiberphone.co.nz Wed Nov 11 04:19:01 2015 From: pete at fiberphone.co.nz (Pete Mundy) Date: Wed, 11 Nov 2015 17:19:01 +1300 Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: <94E02753-2481-4340-8B20-B9F434BFDCA5@gmail.com> References: <94E02753-2481-4340-8B20-B9F434BFDCA5@gmail.com> Message-ID: I see they support speed-test via IPv6 testing! Good job & kudos to them! :) I just wish their Australian server was part of the IPv6 selection pool. 150+ms to the nearest one from down here. Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From pete at fiberphone.co.nz Wed Nov 11 05:26:53 2015 From: pete at fiberphone.co.nz (Pete Mundy) Date: Wed, 11 Nov 2015 18:26:53 +1300 Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: References: <94E02753-2481-4340-8B20-B9F434BFDCA5@gmail.com> Message-ID: Sorry list, I just realised I didn't quote the prior message I was referring to! Thanks Matt for the off-list reply that made me realise. To be clear for others, it was dslreports that I noticed has IPv6 support and them who I was pointing the kudos towards, not the other speedtest service which was in the subject header. Apologies for any confusion & full creds to dslreports! Pete On 11/11/2015, at 5:19 PM, Pete Mundy wrote: > > I see they support speed-test via IPv6 testing! Good job & kudos to them! :) > > I just wish their Australian server was part of the IPv6 selection pool. > > 150+ms to the nearest one from down here. > > Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From mark.tinka at seacom.mu Wed Nov 11 05:58:23 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 11 Nov 2015 07:58:23 +0200 Subject: Google Captcha on web searches In-Reply-To: <56427924.7020700@inblock.ru> References: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> <564232BE.3040408@inblock.ru> <56425397.3040400@inblock.ru> <56427924.7020700@inblock.ru> Message-ID: <5642D8FF.5030200@seacom.mu> On 11/Nov/15 01:09, Nikolay Shopik wrote: > Hi Chris, > > Yeah I probably should worded that differently not 'open dns services', > sorry about that. I think those types of DNS services are so-called "Smart DNS". Mark. From frnkblk at iname.com Wed Nov 11 06:14:30 2015 From: frnkblk at iname.com (frnkblk at iname.com) Date: Wed, 11 Nov 2015 00:14:30 -0600 Subject: Updated Ookla Speedtest Server Requirements In-Reply-To: References: <94E02753-2481-4340-8B20-B9F434BFDCA5@gmail.com> Message-ID: <004601d11c48$3ac58020$b0508060$@iname.com> Note that Ookla's speedtest server runs fine over IPv6 -- we have ours dual-stacked and also with a specific FQDN. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Pete Mundy Sent: Tuesday, November 10, 2015 11:27 PM To: nanog at nanog.org Subject: Re: Updated Ookla Speedtest Server Requirements Sorry list, I just realised I didn't quote the prior message I was referring to! Thanks Matt for the off-list reply that made me realise. To be clear for others, it was dslreports that I noticed has IPv6 support and them who I was pointing the kudos towards, not the other speedtest service which was in the subject header. Apologies for any confusion & full creds to dslreports! Pete On 11/11/2015, at 5:19 PM, Pete Mundy wrote: > > I see they support speed-test via IPv6 testing! Good job & kudos to them! :) > > I just wish their Australian server was part of the IPv6 selection pool. > > 150+ms to the nearest one from down here. > > Pete From marco at paesani.it Wed Nov 11 10:51:08 2015 From: marco at paesani.it (Marco Paesani) Date: Wed, 11 Nov 2015 11:51:08 +0100 Subject: Amazon AS16509 Message-ID: Hi, I have some issue on our backbone with AS16509 Feel free to contact me off list Thanks !! -- Marco Paesani MPAE Srl Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it From mhoppes at indigowireless.com Wed Nov 11 14:25:32 2015 From: mhoppes at indigowireless.com (Matt Hoppes) Date: Wed, 11 Nov 2015 09:25:32 -0500 Subject: Level3 Customer Center Down? Message-ID: <56434FDC.2030808@indigowireless.com> Has anyone else experienced the Level3 Customer Center down for the past 2 days? All I get when I try to go there is: http://www.level3.com/en/customer-center/ An HTTP error occurred while getting: http://www.level3.com/en/customer-center/ Tried in multiple browsers from multiple ISPs. From manager at monmouth.com Wed Nov 11 14:32:21 2015 From: manager at monmouth.com (Mark Stevens) Date: Wed, 11 Nov 2015 09:32:21 -0500 Subject: Level3 Customer Center Down? In-Reply-To: <56434FDC.2030808@indigowireless.com> References: <56434FDC.2030808@indigowireless.com> Message-ID: <56435175.7080709@monmouth.com> Works for me but takes time to load. Running Chrome and Firefox. On 11/11/2015 9:25 AM, Matt Hoppes wrote: > Has anyone else experienced the Level3 Customer Center down for the > past 2 days? All I get when I try to go there is: > > http://www.level3.com/en/customer-center/ > > An HTTP error occurred while getting: > > http://www.level3.com/en/customer-center/ > > > Tried in multiple browsers from multiple ISPs. > From mel at beckman.org Wed Nov 11 14:35:23 2015 From: mel at beckman.org (Mel Beckman) Date: Wed, 11 Nov 2015 14:35:23 +0000 Subject: Level3 Customer Center Down? In-Reply-To: <56434FDC.2030808@indigowireless.com> References: <56434FDC.2030808@indigowireless.com> Message-ID: <1F6D936A-A671-4EAB-9AB4-026A135C3C02@beckman.org> When L3 had a major outage last night at 9PM PST during scheduled maintenance (thousands of prefixes, including ours, stopped advertising across their border) we discovered the portal was down. I phoned in to open the BGP outage ticket, and let them know about the portal too. The portal was then up and down during the outage, which resolved about three hours later. But the portal kept bouncing, with DNS problems, and 404 messages. -mel beckman > On Nov 11, 2015, at 6:27 AM, Matt Hoppes wrote: > > Has anyone else experienced the Level3 Customer Center down for the past 2 days? All I get when I try to go there is: > > http://www.level3.com/en/customer-center/ > > An HTTP error occurred while getting: > > http://www.level3.com/en/customer-center/ > > > Tried in multiple browsers from multiple ISPs. From mel at beckman.org Wed Nov 11 14:37:13 2015 From: mel at beckman.org (Mel Beckman) Date: Wed, 11 Nov 2015 14:37:13 +0000 Subject: Level3 Customer Center Down? In-Reply-To: <56435175.7080709@monmouth.com> References: <56434FDC.2030808@indigowireless.com>, <56435175.7080709@monmouth.com> Message-ID: Also,mi think the new URL is http://my.level3.com. -mel beckman > On Nov 11, 2015, at 6:33 AM, Mark Stevens wrote: > > > Works for me but takes time to load. Running Chrome and Firefox. > >> On 11/11/2015 9:25 AM, Matt Hoppes wrote: >> Has anyone else experienced the Level3 Customer Center down for the past 2 days? All I get when I try to go there is: >> >> http://www.level3.com/en/customer-center/ >> >> An HTTP error occurred while getting: >> >> http://www.level3.com/en/customer-center/ >> >> >> Tried in multiple browsers from multiple ISPs. >> > From alejandroacostaalamo at gmail.com Wed Nov 11 14:37:30 2015 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Wed, 11 Nov 2015 10:07:30 -0430 Subject: Level3 Customer Center Down? In-Reply-To: <56435175.7080709@monmouth.com> References: <56434FDC.2030808@indigowireless.com> <56435175.7080709@monmouth.com> Message-ID: <564352AA.7070409@gmail.com> http://www.level3.com/en/customer-center/ also loaded for me. El 11/11/2015 a las 10:02 AM, Mark Stevens escribi?: > > Works for me but takes time to load. Running Chrome and Firefox. > > On 11/11/2015 9:25 AM, Matt Hoppes wrote: >> Has anyone else experienced the Level3 Customer Center down for the >> past 2 days? All I get when I try to go there is: >> >> http://www.level3.com/en/customer-center/ >> >> An HTTP error occurred while getting: >> >> http://www.level3.com/en/customer-center/ >> >> >> Tried in multiple browsers from multiple ISPs. >> > From morrowc.lists at gmail.com Wed Nov 11 15:09:50 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 11 Nov 2015 10:09:50 -0500 Subject: Google Captcha on web searches In-Reply-To: <5642D8FF.5030200@seacom.mu> References: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> <564232BE.3040408@inblock.ru> <56425397.3040400@inblock.ru> <56427924.7020700@inblock.ru> <5642D8FF.5030200@seacom.mu> Message-ID: On Wed, Nov 11, 2015 at 12:58 AM, Mark Tinka wrote: > > > On 11/Nov/15 01:09, Nikolay Shopik wrote: > >> Hi Chris, >> >> Yeah I probably should worded that differently not 'open dns services', >> sorry about that. > > I think those types of DNS services are so-called "Smart DNS". 'smart' ... I can't imagine that the DNS server you use would matter to Google, from a 'send to captcha' perspective. I CAN imagine that the DNS server you use could lie to you about the right RR to send back, and then push you through some proxy for all manner of good/bad reasons. Don't use DNS servers that lie. From damian at google.com Wed Nov 11 15:17:22 2015 From: damian at google.com (Damian Menscher) Date: Wed, 11 Nov 2015 07:17:22 -0800 Subject: Google Captcha on web searches In-Reply-To: References: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> <564232BE.3040408@inblock.ru> <56425397.3040400@inblock.ru> Message-ID: On Tue, Nov 10, 2015 at 2:43 PM, Chris Murray wrote: > The "popular open dns services" you refer to appear to be Proxy/VPN > services that also provide DNS to get around region blocking. These > services proxy and/or NAT users behind a single IP address to make it > look like you are coming from a different country. > > I may be biased, but when I think of popular open DNS services I think > of OpenDNS or Google DNS, and you should *never* see a captcha as a > result of using OpenDNS. Disclaimer: I work for OpenDNS, and while I > can't speak to Google DNS, I have never heard of this behaviour with > their service either. > Chris: as you correctly note, this can only happen if the DNS provider returns falsified records to hijack traffic and MITM it through their own proxies. But it sounds like you're unaware of the dark past of OpenDNS where they did exactly that, and their users got Google captchas as a result (they don't do this anymore). To answer the other questions/comments on the list: - You're responsible for all the traffic that comes from your IP. Joe, if you put 600 users behind an IPv4/32 you'd better make sure you have controls in place to keep malware (and shady browser extensions) off their machines. - The obvious way to avoid needing to share a NAT address is to switch to IPv6 if possible, as Nich said. - Google looks at an IPv4/32 or IPv6/64 by default (may be /56 or /48 for some hosting providers). If you have significant numbers of users sharing a /64, please explain why? Is it because you hate your users? ;) Damian From mark.tinka at seacom.mu Wed Nov 11 15:57:13 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 11 Nov 2015 17:57:13 +0200 Subject: Google Captcha on web searches In-Reply-To: References: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> <564232BE.3040408@inblock.ru> <56425397.3040400@inblock.ru> <56427924.7020700@inblock.ru> <5642D8FF.5030200@seacom.mu> Message-ID: <56436559.9010409@seacom.mu> On 11/Nov/15 17:09, Christopher Morrow wrote: > 'smart' ... I can't imagine that the DNS server you use would matter > to Google, from a 'send to captcha' perspective. I CAN imagine that > the DNS server you use could lie to you about the right RR to send > back, and then push you through some proxy for all manner of good/bad > reasons. > > Don't use DNS servers that lie. https://en.wikipedia.org/wiki/Smart_DNS_proxy_server I don't make this sh** up. Mark. From morrowc.lists at gmail.com Wed Nov 11 16:03:21 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 11 Nov 2015 11:03:21 -0500 Subject: Google Captcha on web searches In-Reply-To: <56436559.9010409@seacom.mu> References: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> <564232BE.3040408@inblock.ru> <56425397.3040400@inblock.ru> <56427924.7020700@inblock.ru> <5642D8FF.5030200@seacom.mu> <56436559.9010409@seacom.mu> Message-ID: On Wed, Nov 11, 2015 at 10:57 AM, Mark Tinka wrote: > > > On 11/Nov/15 17:09, Christopher Morrow wrote: > >> 'smart' ... I can't imagine that the DNS server you use would matter >> to Google, from a 'send to captcha' perspective. I CAN imagine that >> the DNS server you use could lie to you about the right RR to send >> back, and then push you through some proxy for all manner of good/bad >> reasons. >> >> Don't use DNS servers that lie. > > https://en.wikipedia.org/wiki/Smart_DNS_proxy_server > > I don't make this sh** up. it's in wikipedia, so ... someone did :) But yea, don't use dns servers that lie to you UNLESS you understand very well what that lie is going to be and under what conditions you'll get the lie. From mark.tinka at seacom.mu Wed Nov 11 16:09:58 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 11 Nov 2015 18:09:58 +0200 Subject: Google Captcha on web searches In-Reply-To: References: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> <564232BE.3040408@inblock.ru> <56425397.3040400@inblock.ru> <56427924.7020700@inblock.ru> <5642D8FF.5030200@seacom.mu> <56436559.9010409@seacom.mu> Message-ID: <56436856.2000605@seacom.mu> On 11/Nov/15 18:03, Christopher Morrow wrote: > it's in wikipedia, so ... someone did :) But yea, don't use dns > servers that lie to you UNLESS you understand very well what that lie > is going to be and under what conditions you'll get the lie. Well, there is a ton of them offering pay-for services online that seem to work for millions of people globally. I suppose those folk are okay with the "lies" those resolvers tell - but there is a specific use-case for those, as you may know... Mark. From morrowc.lists at gmail.com Wed Nov 11 16:15:54 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 11 Nov 2015 11:15:54 -0500 Subject: Google Captcha on web searches In-Reply-To: <56436856.2000605@seacom.mu> References: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> <564232BE.3040408@inblock.ru> <56425397.3040400@inblock.ru> <56427924.7020700@inblock.ru> <5642D8FF.5030200@seacom.mu> <56436559.9010409@seacom.mu> <56436856.2000605@seacom.mu> Message-ID: On Wed, Nov 11, 2015 at 11:09 AM, Mark Tinka wrote: > > > On 11/Nov/15 18:03, Christopher Morrow wrote: > >> it's in wikipedia, so ... someone did :) But yea, don't use dns >> servers that lie to you UNLESS you understand very well what that lie >> is going to be and under what conditions you'll get the lie. > > Well, there is a ton of them offering pay-for services online that seem > to work for millions of people globally. > > I suppose those folk are okay with the "lies" those resolvers tell - but > there is a specific use-case for those, as you may know... Yes, people also jump out of perfectly good airplanes... we can't fix all the things :( my point really is you assume some risk when you do odd things with basic plumbing on the internet, if you don't actually know what you are doing you're going to get burned. Quoted from Wikipedia: "Dangers of Use[edit] The dangers of using an unknown IP as a Smart DNS are similar to any other rogue DNS server preforming DNS hijacking in that the user is not aware which parts of his traffic are redirect and intercepted." -chris From mark.tinka at seacom.mu Wed Nov 11 16:23:50 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 11 Nov 2015 18:23:50 +0200 Subject: Google Captcha on web searches In-Reply-To: References: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> <564232BE.3040408@inblock.ru> <56425397.3040400@inblock.ru> <56427924.7020700@inblock.ru> <5642D8FF.5030200@seacom.mu> <56436559.9010409@seacom.mu> <56436856.2000605@seacom.mu> Message-ID: <56436B96.9070609@seacom.mu> On 11/Nov/15 18:15, Christopher Morrow wrote: > Yes, people also jump out of perfectly good airplanes... we can't fix > all the things :( > my point really is you assume some risk when you do odd things with > basic plumbing on the internet, if you don't actually know what you > are doing you're going to get burned. > > Quoted from Wikipedia: > "Dangers of Use[edit] > The dangers of using an unknown IP as a Smart DNS are similar to any > other rogue DNS server preforming DNS hijacking in that the user is > not aware which parts of his traffic are redirect and intercepted." No arguments from me there... Mark. From network at cwo.com Wed Nov 11 15:48:21 2015 From: network at cwo.com (CWO Network Operations) Date: Wed, 11 Nov 2015 07:48:21 -0800 Subject: Level3 Customer Center Down? In-Reply-To: <564352AA.7070409@gmail.com> References: <56434FDC.2030808@indigowireless.com> <56435175.7080709@monmouth.com> <564352AA.7070409@gmail.com> Message-ID: <2CF38B99-090C-4818-AB55-FE4A12A029BB@cwo.com> We have had problems with our traffic passing through Level 3?s network since Friday afternoon. All our prefix announcements are ?suppressed? on their routers, for no apparent reason. We have no routing problems anywhere else, nor are we flapping routes.. If you still can?t access their site (resources), I would go to their looking glass, http://lookingglass.level3.net, (from your cell or some other network) to check your routes. JB > On Nov 11, 2015, at 6:37 AM, Alejandro Acosta wrote: > > http://www.level3.com/en/customer-center/ also loaded for me. > > > El 11/11/2015 a las 10:02 AM, Mark Stevens escribi?: >> >> Works for me but takes time to load. Running Chrome and Firefox. >> >> On 11/11/2015 9:25 AM, Matt Hoppes wrote: >>> Has anyone else experienced the Level3 Customer Center down for the >>> past 2 days? All I get when I try to go there is: >>> >>> http://www.level3.com/en/customer-center/ >>> >>> An HTTP error occurred while getting: >>> >>> http://www.level3.com/en/customer-center/ >>> >>> >>> Tried in multiple browsers from multiple ISPs. >>> >> > From ianm at fairwaymc.com Wed Nov 11 16:39:45 2015 From: ianm at fairwaymc.com (Ian Mock) Date: Wed, 11 Nov 2015 16:39:45 +0000 Subject: Google Captcha on web searches In-Reply-To: <56436B96.9070609@seacom.mu> References: <777D03E8-6030-41A9-A59B-BF03FE33F780@breathe-underwater.com> <564232BE.3040408@inblock.ru> <56425397.3040400@inblock.ru> <56427924.7020700@inblock.ru> <5642D8FF.5030200@seacom.mu> <56436559.9010409@seacom.mu> <56436856.2000605@seacom.mu> , <56436B96.9070609@seacom.mu> Message-ID: <783C627CF58B9948866C2A5DD8C7A907925E0CA4@COLOMBX01.fairwaymc.com> We had an IP flagged where a new hire in our Marketing dept was doing some kind of SEO and was hammering Google's servers with API requests in the hundreds per minute. Google flagged it as malicious, got the captcha for all users behind that IP. After we found and stopped him, it returned to normal after a few hours. Ian Mock ________________________________________ From: NANOG [nanog-bounces at nanog.org] on behalf of Mark Tinka [mark.tinka at seacom.mu] Sent: Wednesday, November 11, 2015 10:23 AM To: Christopher Morrow Cc: nanog list Subject: Re: Google Captcha on web searches On 11/Nov/15 18:15, Christopher Morrow wrote: > Yes, people also jump out of perfectly good airplanes... we can't fix > all the things :( > my point really is you assume some risk when you do odd things with > basic plumbing on the internet, if you don't actually know what you > are doing you're going to get burned. > > Quoted from Wikipedia: > "Dangers of Use[edit] > The dangers of using an unknown IP as a Smart DNS are similar to any > other rogue DNS server preforming DNS hijacking in that the user is > not aware which parts of his traffic are redirect and intercepted." No arguments from me there... Mark. From briansupport at hotmail.com Wed Nov 11 19:58:14 2015 From: briansupport at hotmail.com (Brian R) Date: Wed, 11 Nov 2015 19:58:14 +0000 Subject: Favorite GPON Vendor? In-Reply-To: References: <22699042.434.1447097920305.JavaMail.art@DQT6ZQ1> <1447162066.647710320@upnet.mymailsrvr.com>, <341782.18.1447162373976.JavaMail.art@DQT6ZQ1>, Message-ID: Previously I had stated we tested Calix equipment. That was wrong, we had deployed Tellabs GPON equipment. That was what we had had problems with and had not received much support on. Apologies for the error. I believe the reason we chose not to go with Calix was the requirement to have a constant connection between the configuration server/hardware and the ONTs. If there was a problem with the configuration server or if the ONT reloaded and was not able to reach the configuration server the ONT would not configure. We like the fact that the Adtrans were configured directly off their uplink hardware and that they were capable of storing the configuration on the ONT. We did not have any problems with Calix support that I can recall. Brian ________________________________________ From: NANOG on behalf of Brian R Sent: Tuesday, November 10, 2015 11:32 AM To: Art Plato Cc: nanog Subject: Re: Favorite GPON Vendor? Art, I can't say we have a lot of experience with the Adtran GPON units. On the Active Ethernet side if we assign an IP to the ONT we can view all the stats going back to the TA5K. From the TA5K we can also view the individual Ethernet ports. I will send you directly some examples. I don't think NANOG wants to see a bunch of Adtran "show ..." commands : ] As far as Shawns Calix experiences the last time we tried Calix GPON was 5-6 years ago. The CPE seemed solid but the POP side was in constant need of rebooting and we gave it up after about 8-12 months of customer frustrations. At that time we did not get much help on the problems. Brian ________________________________________ From: NANOG on behalf of Art Plato Sent: Tuesday, November 10, 2015 5:32 AM To: Shawn L Cc: nanog Subject: Re: Favorite GPON Vendor? Awesome. Thanks for the feedback Brian. Price is important, but not the be all of the consideration process. Troubleshooting ease matters just as much. ----- Original Message ----- From: "Shawn L" To: "nanog" Sent: Tuesday, November 10, 2015 8:27:46 AM Subject: Re: Favorite GPON Vendor? We like Calix's gpon gear, especially the E7 series. Though it's on the higher side price-wise than others. Manageable through their CMS software, the web, or command line. We tend to use their CMS software for most things, but the CLI is decent, and gives you access to anything you'd want. -----Original Message----- From: "Art Plato" Sent: Monday, November 9, 2015 2:38pm To: Cc: nanog at nanog.org Subject: Re: Favorite GPON Vendor? Brian, How complex is the troubleshooting side of the Adtran? We Use the Enablence Wave7 and getting any useful information from the CPE via the CLI is like pulling hens teeth. I have yet to see a way to view the actual throughput on the ethernet interfaces, only total bits passed, or the light levels at the CPE fiber interface. A bit annoying actually. It means a truck roll to get light levels at the CPE. Art. ----- Original Message ----- From: "Brian R" To: "Eric Rogers" , "Jay Patel" Cc: nanog at nanog.org Sent: Monday, November 9, 2015 2:25:44 PM Subject: Re: Favorite GPON Vendor? We use the Adtran ONT solutions. We are using AE (Active Ethernet) not GPON but the solutions are similar for Adtran. We are providing IP and Analog this way. If used in the specified scope only there have been very little problems. Adtran is constantly updating their firmware, this can be a positive and negative at times. LoL The configuration is Adtran TA5000 with an Active Ethernet 24-Port Module (1187562F1) feeding an ONT TA324E (1287737G2) at the customer premise. For power we are using the Cyber Power CSN27U12v-NA3 units. The clam shell we are using to put the ONT in is TA350 ONT NID HSG SPLICE (1187770G1) All of these part numbers should be available on Adtrans website to look up. We are also testing some iPhotonix ONTs but have not gotten to the point we are sure we want to deploy them. Brian PS I will post this in voiceops as well (it may be more relevant there) ________________________________________ From: NANOG on behalf of Eric Rogers Sent: Monday, November 9, 2015 10:09 AM To: Jay Patel; nanog at nanog.org Subject: RE: Favorite GPON Vendor? I Personally would like to know as well. We are just getting into GPON and the equipment we have been evaluating is clunky at best... It came highly recommended and supposed to be stable. Eric Rogers PDS Connect www.pdsconnect.me (317) 831-3000 x200 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay Patel Sent: Monday, November 9, 2015 9:50 AM To: nanog at nanog.org Subject: Favorite GPON Vendor? Who is your favorite GPON OLT/ONU Vendor? Why? I am looking for recommendations I apologize in advance , if you feel my question is inappropriate for this mailing list ( feel free to point me to right forum/mailing list). Regards, Jay. From julianeble at yahoo.com.br Wed Nov 11 21:52:02 2015 From: julianeble at yahoo.com.br (Julian Eble) Date: Wed, 11 Nov 2015 19:52:02 -0200 Subject: RES: Favorite GPON Vendor? In-Reply-To: References: <22699042.434.1447097920305.JavaMail.art@DQT6ZQ1> <1447162066.647710320@upnet.mymailsrvr.com>, <341782.18.1447162373976.JavaMail.art@DQT6ZQ1>, Message-ID: <00c601d11ccb$342fed30$9c8fc790$@yahoo.com.br> We're evaluating the ZTE OLT/ONT and the results are being good so far. The OMCI has the basic commands to apply a PPPoE conection and a SIP phone, after the TR069 do the job. Julian -----Mensagem original----- De: NANOG [mailto:nanog-bounces at nanog.org] Em nome de Brian R Enviada em: quarta-feira, 11 de novembro de 2015 17:58 Para: nanog Assunto: Re: Favorite GPON Vendor? Previously I had stated we tested Calix equipment. That was wrong, we had deployed Tellabs GPON equipment. That was what we had had problems with and had not received much support on. Apologies for the error. I believe the reason we chose not to go with Calix was the requirement to have a constant connection between the configuration server/hardware and the ONTs. If there was a problem with the configuration server or if the ONT reloaded and was not able to reach the configuration server the ONT would not configure. We like the fact that the Adtrans were configured directly off their uplink hardware and that they were capable of storing the configuration on the ONT. We did not have any problems with Calix support that I can recall. Brian ________________________________________ From: NANOG on behalf of Brian R Sent: Tuesday, November 10, 2015 11:32 AM To: Art Plato Cc: nanog Subject: Re: Favorite GPON Vendor? Art, I can't say we have a lot of experience with the Adtran GPON units. On the Active Ethernet side if we assign an IP to the ONT we can view all the stats going back to the TA5K. From the TA5K we can also view the individual Ethernet ports. I will send you directly some examples. I don't think NANOG wants to see a bunch of Adtran "show ..." commands : ] As far as Shawns Calix experiences the last time we tried Calix GPON was 5-6 years ago. The CPE seemed solid but the POP side was in constant need of rebooting and we gave it up after about 8-12 months of customer frustrations. At that time we did not get much help on the problems. Brian ________________________________________ From: NANOG on behalf of Art Plato Sent: Tuesday, November 10, 2015 5:32 AM To: Shawn L Cc: nanog Subject: Re: Favorite GPON Vendor? Awesome. Thanks for the feedback Brian. Price is important, but not the be all of the consideration process. Troubleshooting ease matters just as much. ----- Original Message ----- From: "Shawn L" To: "nanog" Sent: Tuesday, November 10, 2015 8:27:46 AM Subject: Re: Favorite GPON Vendor? We like Calix's gpon gear, especially the E7 series. Though it's on the higher side price-wise than others. Manageable through their CMS software, the web, or command line. We tend to use their CMS software for most things, but the CLI is decent, and gives you access to anything you'd want. -----Original Message----- From: "Art Plato" Sent: Monday, November 9, 2015 2:38pm To: Cc: nanog at nanog.org Subject: Re: Favorite GPON Vendor? Brian, How complex is the troubleshooting side of the Adtran? We Use the Enablence Wave7 and getting any useful information from the CPE via the CLI is like pulling hens teeth. I have yet to see a way to view the actual throughput on the ethernet interfaces, only total bits passed, or the light levels at the CPE fiber interface. A bit annoying actually. It means a truck roll to get light levels at the CPE. Art. ----- Original Message ----- From: "Brian R" To: "Eric Rogers" , "Jay Patel" Cc: nanog at nanog.org Sent: Monday, November 9, 2015 2:25:44 PM Subject: Re: Favorite GPON Vendor? We use the Adtran ONT solutions. We are using AE (Active Ethernet) not GPON but the solutions are similar for Adtran. We are providing IP and Analog this way. If used in the specified scope only there have been very little problems. Adtran is constantly updating their firmware, this can be a positive and negative at times. LoL The configuration is Adtran TA5000 with an Active Ethernet 24-Port Module (1187562F1) feeding an ONT TA324E (1287737G2) at the customer premise. For power we are using the Cyber Power CSN27U12v-NA3 units. The clam shell we are using to put the ONT in is TA350 ONT NID HSG SPLICE (1187770G1) All of these part numbers should be available on Adtrans website to look up. We are also testing some iPhotonix ONTs but have not gotten to the point we are sure we want to deploy them. Brian PS I will post this in voiceops as well (it may be more relevant there) ________________________________________ From: NANOG on behalf of Eric Rogers Sent: Monday, November 9, 2015 10:09 AM To: Jay Patel; nanog at nanog.org Subject: RE: Favorite GPON Vendor? I Personally would like to know as well. We are just getting into GPON and the equipment we have been evaluating is clunky at best... It came highly recommended and supposed to be stable. Eric Rogers PDS Connect www.pdsconnect.me (317) 831-3000 x200 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay Patel Sent: Monday, November 9, 2015 9:50 AM To: nanog at nanog.org Subject: Favorite GPON Vendor? Who is your favorite GPON OLT/ONU Vendor? Why? I am looking for recommendations I apologize in advance , if you feel my question is inappropriate for this mailing list ( feel free to point me to right forum/mailing list). Regards, Jay. From jason at thebaughers.com Thu Nov 12 01:01:34 2015 From: jason at thebaughers.com (Jason Baugher) Date: Wed, 11 Nov 2015 19:01:34 -0600 Subject: Favorite GPON Vendor? In-Reply-To: References: <22699042.434.1447097920305.JavaMail.art@DQT6ZQ1> <1447162066.647710320@upnet.mymailsrvr.com> <341782.18.1447162373976.JavaMail.art@DQT6ZQ1> Message-ID: That is the case with Calix Active Ethernet ONT's, but not with GPON. AE ONT's need a tftp server on boot to get a configuration. On Nov 11, 2015 2:00 PM, "Brian R" wrote: > Previously I had stated we tested Calix equipment. That was wrong, we had > deployed Tellabs GPON equipment. That was what we had had problems with > and had not received much support on. > Apologies for the error. > > I believe the reason we chose not to go with Calix was the requirement to > have a constant connection between the configuration server/hardware and > the ONTs. If there was a problem with the configuration server or if the > ONT reloaded and was not able to reach the configuration server the ONT > would not configure. We like the fact that the Adtrans were configured > directly off their uplink hardware and that they were capable of storing > the configuration on the ONT. > We did not have any problems with Calix support that I can recall. > > Brian > ________________________________________ > From: NANOG on behalf of Brian R < > briansupport at hotmail.com> > Sent: Tuesday, November 10, 2015 11:32 AM > To: Art Plato > Cc: nanog > Subject: Re: Favorite GPON Vendor? > > Art, > > I can't say we have a lot of experience with the Adtran GPON units. On > the Active Ethernet side if we assign an IP to the ONT we can view all the > stats going back to the TA5K. From the TA5K we can also view the > individual Ethernet ports. I will send you directly some examples. I > don't think NANOG wants to see a bunch of Adtran "show ..." commands : ] > > As far as Shawns Calix experiences the last time we tried Calix GPON was > 5-6 years ago. The CPE seemed solid but the POP side was in constant need > of rebooting and we gave it up after about 8-12 months of customer > frustrations. At that time we did not get much help on the problems. > > Brian > > ________________________________________ > From: NANOG on behalf of Art Plato < > aplato at coldwater.org> > Sent: Tuesday, November 10, 2015 5:32 AM > To: Shawn L > Cc: nanog > Subject: Re: Favorite GPON Vendor? > > Awesome. Thanks for the feedback Brian. Price is important, but not the be > all of the consideration process. Troubleshooting ease matters just as much. > > ----- Original Message ----- > From: "Shawn L" > To: "nanog" > Sent: Tuesday, November 10, 2015 8:27:46 AM > Subject: Re: Favorite GPON Vendor? > > > We like Calix's gpon gear, especially the E7 series. Though it's on the > higher side price-wise than others. Manageable through their CMS software, > the web, or command line. We tend to use their CMS software for most > things, but the CLI is decent, and gives you access to anything you'd want. > > > -----Original Message----- > From: "Art Plato" > Sent: Monday, November 9, 2015 2:38pm > To: > Cc: nanog at nanog.org > Subject: Re: Favorite GPON Vendor? > > > > Brian, > How complex is the troubleshooting side of the Adtran? We Use the > Enablence Wave7 and getting any useful information from the CPE via the CLI > is like pulling hens teeth. I have yet to see a way to view the actual > throughput on the ethernet interfaces, only total bits passed, or the light > levels at the CPE fiber interface. A bit annoying actually. It means a > truck roll to get light levels at the CPE. > > Art. > > ----- Original Message ----- > From: "Brian R" > To: "Eric Rogers" , "Jay Patel" < > clecny at gmail.com> > Cc: nanog at nanog.org > Sent: Monday, November 9, 2015 2:25:44 PM > Subject: Re: Favorite GPON Vendor? > > We use the Adtran ONT solutions. We are using AE (Active Ethernet) not > GPON but the solutions are similar for Adtran. We are providing IP and > Analog this way. If used in the specified scope only there have been very > little problems. Adtran is constantly updating their firmware, this can be > a positive and negative at times. LoL > > The configuration is Adtran TA5000 with an Active Ethernet 24-Port Module > (1187562F1) feeding an ONT TA324E (1287737G2) at the customer premise. > For power we are using the Cyber Power CSN27U12v-NA3 units. > The clam shell we are using to put the ONT in is TA350 ONT NID HSG SPLICE > (1187770G1) > All of these part numbers should be available on Adtrans website to look > up. > > We are also testing some iPhotonix ONTs but have not gotten to the point > we are sure we want to deploy them. > > Brian > > PS I will post this in voiceops as well (it may be more relevant there) > > ________________________________________ > From: NANOG on behalf of Eric Rogers < > ecrogers at precisionds.com> > Sent: Monday, November 9, 2015 10:09 AM > To: Jay Patel; nanog at nanog.org > Subject: RE: Favorite GPON Vendor? > > I Personally would like to know as well. We are just getting into GPON and > the equipment we have been evaluating is clunky at best... It came highly > recommended and supposed to be stable. > > Eric Rogers > PDS Connect > www.pdsconnect.me > (317) 831-3000 x200 > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay Patel > Sent: Monday, November 9, 2015 9:50 AM > To: nanog at nanog.org > Subject: Favorite GPON Vendor? > > Who is your favorite GPON OLT/ONU Vendor? Why? I am looking for > recommendations > > I apologize in advance , if you feel my question is inappropriate for this > mailing list ( feel free to point me to right forum/mailing list). > > Regards, > Jay. > From jheitz at cisco.com Wed Nov 11 17:57:12 2015 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Wed, 11 Nov 2015 17:57:12 +0000 Subject: Environmental Graph Interpretation Message-ID: <231e2cda6aa14677ad24b62062cd50ab@XCH-ALN-014.cisco.com> If the temperature of the floor is below the dew point, then it will sweat. Maybe there's a cold wind blowing underneath the gap? --Jakob > -----Original Message----- > Date: Tue, 10 Nov 2015 17:25:04 -0600 > From: "Lorell Hathcock" > > It is on the ground floor, but it is in a hut that has a wood floor that is > raised off the ground. There is a gap between the bottom of the floor and > the ground. > > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Tuesday, November 10, 2015 5:13 PM > To: Lorell Hathcock > Cc: 'NANOG list' > Subject: Re: Environmental Graph Interpretation > > On Tue, 10 Nov 2015 16:48:04 -0600, "Lorell Hathcock" said: > > Are there any one the list that would care to take a look at some > > graphs of temperature, relative humidity and dew point that I have for two > locations. > > In one of the two locations, I'm having a problem with the floor > > getting wet (condensation?). At the other everything is just fine. > > Is your moisture problem on a ground floor? Note that even well-cured > concrete is like 30% water, and can allow moisture to slowly migrate through > and weep. Usual cure is application of a proper sealant over the concrete. From james at jamesstewartsmith.com Wed Nov 11 18:19:09 2015 From: james at jamesstewartsmith.com (James Smith) Date: Wed, 11 Nov 2015 13:19:09 -0500 Subject: CenturyLink and Bell Message-ID: It seems like there's a large outage going on with CenturyLink and Bell Canada. The CenturyLink outage seems to be US wide and seems to have been going on for a half day. Anyone know what's going on? From josh at kyneticwifi.com Thu Nov 12 02:48:35 2015 From: josh at kyneticwifi.com (Josh Reynolds) Date: Wed, 11 Nov 2015 20:48:35 -0600 Subject: Favorite GPON Vendor? In-Reply-To: References: Message-ID: We are about do deploy Calix, but after hearing about $company deploying Adtran and liking their chassis features and NG-PON2 upgrade path, we are now open to other vendors. Price IS a concern for us, but not THE concern. This may sound "wacky" to some, but if anybody on here is using Huawei GPON gear, could you contact me off list? Thanks (josh AT kyneticwifi.com) On Mon, Nov 9, 2015 at 8:49 AM, Jay Patel wrote: > Who is your favorite GPON OLT/ONU Vendor? Why? I am looking for > recommendations > > I apologize in advance , if you feel my question is inappropriate for this > mailing list ( feel free to point me to right forum/mailing list). > > Regards, > Jay. From mark.tinka at seacom.mu Thu Nov 12 05:41:52 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 12 Nov 2015 07:41:52 +0200 Subject: Favorite GPON Vendor? In-Reply-To: References: Message-ID: <564426A0.7030905@seacom.mu> On 12/Nov/15 04:48, Josh Reynolds wrote: > > This may sound "wacky" to some, but if anybody on here is using Huawei > GPON gear, could you contact me off list? I used Huawei GPON gear at previous job. I won't lie, it worked great. A few bugs with the IGMP implementation, but nothing a plane full of Huawei engineers from China with a local translator couldn't fix. That network probably still uses Huawei today. I'm more into Active-E myself, these days. Mark. From josh at kyneticwifi.com Thu Nov 12 18:42:58 2015 From: josh at kyneticwifi.com (Josh Reynolds) Date: Thu, 12 Nov 2015 12:42:58 -0600 Subject: Favorite GPON Vendor? In-Reply-To: <564426A0.7030905@seacom.mu> References: <564426A0.7030905@seacom.mu> Message-ID: Did you guys use them for core and distribution switching/routing as well, or just on the GPON access side? On Wed, Nov 11, 2015 at 11:41 PM, Mark Tinka wrote: > > > On 12/Nov/15 04:48, Josh Reynolds wrote: > >> >> This may sound "wacky" to some, but if anybody on here is using Huawei >> GPON gear, could you contact me off list? > > I used Huawei GPON gear at previous job. > > I won't lie, it worked great. A few bugs with the IGMP implementation, > but nothing a plane full of Huawei engineers from China with a local > translator couldn't fix. > > That network probably still uses Huawei today. I'm more into Active-E > myself, these days. > > Mark. From mail.network.bits at gmail.com Thu Nov 12 10:26:03 2015 From: mail.network.bits at gmail.com (Marcin Wojcik) Date: Thu, 12 Nov 2015 10:26:03 +0000 Subject: Environmental Graph Interpretation In-Reply-To: <02e901d11c09$dc77d7e0$956787a0$@hathcock.org> References: <02e901d11c09$dc77d7e0$956787a0$@hathcock.org> Message-ID: My guess is that your floor is not insulated. The air temperature in the room is higher than a temperature of the floor, hence, the floor starts sweating. Where are your temperature sensors installed? Do you have one of them measuring the air temperature in the room and the other located on the floor? What readings they show? I'd use a temp. gun to measure the floor temp (if you have only one sensor installed). and see if you have a considerable temp. difference between those two readings. I'd say you won't have this problem if you insulate the floor (if possible). Another option is A/C - it will help to control the temp and decrease humidity. A dehumidifier should help too but it wouldn't be my choice... On Tue, Nov 10, 2015 at 10:48 PM, Lorell Hathcock wrote: > NANOG: > > > > Are there any one the list that would care to take a look at some graphs of > temperature, relative humidity and dew point that I have for two locations. > In one of the two locations, I'm having a problem with the floor getting wet > (condensation?). At the other everything is just fine. > > > > I need to understand what these graphs are telling me about the problem and > if a simple dehumidifier would solve my moisture problem. > > > > Any takers? > > > > Oh, the environmental monitor I installed in each location is the IT > Watchdog from Geist Global. I bought the POE version. Installed like a > charm and was $229 plus shipping. > > > > I do wonder if this question is off topic, but then I can hear myself saying > "Hey, I'm Operating a Network, here! In North America!" And then I think, > "Yep, on topic!" > > > > Thanks, > > > > Sincerely, > > > > Lorell Hathcock > > > > > > > SolStar Network, LLC > > Communications > > FIBER - VOIP - SECURITY - TV > > FTTH - Commercial - Residential > > Burglar - Access Control > > 956-478-5955 (cell) - 956-316-4090 (main) > > lorell at SolStarNetwork.com > > www.SolStarNetwork.com > > TX License #B19998 > > > > > > > > > > > From mark.tinka at seacom.mu Thu Nov 12 19:36:18 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 12 Nov 2015 21:36:18 +0200 Subject: Favorite GPON Vendor? In-Reply-To: References: <564426A0.7030905@seacom.mu> Message-ID: <5644EA32.8070202@seacom.mu> On 12/Nov/15 20:42, Josh Reynolds wrote: > Did you guys use them for core and distribution switching/routing as > well, or just on the GPON access side? Just GPON. All IP/MPLS/Ethernet kit was Cisco and Juniper. Mark. From tarko at lanparty.ee Thu Nov 12 21:40:51 2015 From: tarko at lanparty.ee (Tarko Tikan) Date: Thu, 12 Nov 2015 23:40:51 +0200 Subject: Favorite GPON Vendor? In-Reply-To: <564426A0.7030905@seacom.mu> References: <564426A0.7030905@seacom.mu> Message-ID: <56450763.60804@lanparty.ee> hey, > I used Huawei GPON gear at previous job. +1 for the MA5600 series. They are decent boxes compared to most of the other vendors that tend to be hardcore telco with (undocumented) TL1 management plane. -- tarko From frnkblk at iname.com Fri Nov 13 00:01:45 2015 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 12 Nov 2015 18:01:45 -0600 Subject: Favorite GPON Vendor? In-Reply-To: References: Message-ID: <001a01d11da6$7c234d40$7469e7c0$@iname.com> What does ADTRAN's NG-PON2 upgrade path have over Calix's? Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Josh Reynolds Sent: Wednesday, November 11, 2015 8:49 PM To: NANOG Subject: Re: Favorite GPON Vendor? We are about do deploy Calix, but after hearing about $company deploying Adtran and liking their chassis features and NG-PON2 upgrade path, we are now open to other vendors. Price IS a concern for us, but not THE concern. This may sound "wacky" to some, but if anybody on here is using Huawei GPON gear, could you contact me off list? Thanks (josh AT kyneticwifi.com) On Mon, Nov 9, 2015 at 8:49 AM, Jay Patel wrote: > Who is your favorite GPON OLT/ONU Vendor? Why? I am looking for > recommendations > > I apologize in advance , if you feel my question is inappropriate for this > mailing list ( feel free to point me to right forum/mailing list). > > Regards, > Jay. From khelms at zcorum.com Fri Nov 13 00:24:15 2015 From: khelms at zcorum.com (Scott Helms) Date: Thu, 12 Nov 2015 19:24:15 -0500 Subject: Favorite GPON Vendor? In-Reply-To: <001a01d11da6$7c234d40$7469e7c0$@iname.com> References: <001a01d11da6$7c234d40$7469e7c0$@iname.com> Message-ID: Frank, Take a look at this webinar. https://www.webcaster4.com/Webcast/Page?companyId=116&webcastId=10264 On Nov 12, 2015 7:03 PM, "Frank Bulk" wrote: > What does ADTRAN's NG-PON2 upgrade path have over Calix's? > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Josh Reynolds > Sent: Wednesday, November 11, 2015 8:49 PM > To: NANOG > Subject: Re: Favorite GPON Vendor? > > We are about do deploy Calix, but after hearing about $company > deploying Adtran and liking their chassis features and NG-PON2 upgrade > path, we are now open to other vendors. Price IS a concern for us, but > not THE concern. > > This may sound "wacky" to some, but if anybody on here is using Huawei > GPON gear, could you contact me off list? Thanks > (josh AT kyneticwifi.com) > > On Mon, Nov 9, 2015 at 8:49 AM, Jay Patel wrote: > > Who is your favorite GPON OLT/ONU Vendor? Why? I am looking for > > recommendations > > > > I apologize in advance , if you feel my question is inappropriate for > this > > mailing list ( feel free to point me to right forum/mailing list). > > > > Regards, > > Jay. > > > From pelzi at pelzi.net Fri Nov 13 00:34:35 2015 From: pelzi at pelzi.net (Jussi Peltola) Date: Fri, 13 Nov 2015 02:34:35 +0200 Subject: Environmental Graph Interpretation In-Reply-To: <02e901d11c09$dc77d7e0$956787a0$@hathcock.org> References: <02e901d11c09$dc77d7e0$956787a0$@hathcock.org> Message-ID: <20151113003435.GP25044@pokute.pelzi.net> If there are heat producing devices in the room, it sounds implausible for condensation to occur in significant amounts unless the climate is very, very humid. RH sensors are often very inaccurate, but you can get the indoor dew point from the RH and the temperature[1], and if the floor is warmer than the dew point there can be no condensation. If it is below the dew point, there will be condensation - but the outside air cannot be colder than its own dewpoint, so in this case something must be adding water vapor to increase the absolute humidity in the room, or the floor must be cooled by something other than outside air. (Or the temperature [and dew point] of the outside air must be constantly falling while the indoor air is lagging behind. This can only be a transient situation, and the reverse should happen at some point, drying the floor again) 1: http://andrew.rsmas.miami.edu/bmcnoldy/Humidity.html From carlos at race.com Fri Nov 13 01:11:13 2015 From: carlos at race.com (Carlos Alcantar) Date: Fri, 13 Nov 2015 01:11:13 +0000 Subject: Favorite GPON Vendor? In-Reply-To: References: <001a01d11da6$7c234d40$7469e7c0$@iname.com>, Message-ID: I believe with any of these arms dealers (gpon vendors) they all have there goods and bads, it really comes down to what poison you feel you can deal with. The one place I can speak on with calix is there consumer connect with there 800 series ont's has pushed it to a totally different level, it's not perfect but it's getting there. ? 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 ________________________________________ From: NANOG on behalf of Scott Helms Sent: Thursday, November 12, 2015 4:24 PM To: Frank Bulk (iname.com) Cc: NANOG Subject: RE: Favorite GPON Vendor? Frank, Take a look at this webinar. https://www.webcaster4.com/Webcast/Page?companyId=116&webcastId=10264 On Nov 12, 2015 7:03 PM, "Frank Bulk" wrote: > What does ADTRAN's NG-PON2 upgrade path have over Calix's? > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Josh Reynolds > Sent: Wednesday, November 11, 2015 8:49 PM > To: NANOG > Subject: Re: Favorite GPON Vendor? > > We are about do deploy Calix, but after hearing about $company > deploying Adtran and liking their chassis features and NG-PON2 upgrade > path, we are now open to other vendors. Price IS a concern for us, but > not THE concern. > > This may sound "wacky" to some, but if anybody on here is using Huawei > GPON gear, could you contact me off list? Thanks > (josh AT kyneticwifi.com) > > On Mon, Nov 9, 2015 at 8:49 AM, Jay Patel wrote: > > Who is your favorite GPON OLT/ONU Vendor? Why? I am looking for > > recommendations > > > > I apologize in advance , if you feel my question is inappropriate for > this > > mailing list ( feel free to point me to right forum/mailing list). > > > > Regards, > > Jay. > > > From jason at thebaughers.com Fri Nov 13 01:18:47 2015 From: jason at thebaughers.com (Jason Baugher) Date: Thu, 12 Nov 2015 19:18:47 -0600 Subject: Favorite GPON Vendor? In-Reply-To: References: <001a01d11da6$7c234d40$7469e7c0$@iname.com> Message-ID: Too bad they require registration, don't need yet another sales person calling me. The abstract reads more or less like what Calix is promoting with their product development. On Nov 12, 2015 6:25 PM, "Scott Helms" wrote: > Frank, > > Take a look at this webinar. > > https://www.webcaster4.com/Webcast/Page?companyId=116&webcastId=10264 > On Nov 12, 2015 7:03 PM, "Frank Bulk" wrote: > > > What does ADTRAN's NG-PON2 upgrade path have over Calix's? > > > > Frank > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Josh Reynolds > > Sent: Wednesday, November 11, 2015 8:49 PM > > To: NANOG > > Subject: Re: Favorite GPON Vendor? > > > > We are about do deploy Calix, but after hearing about $company > > deploying Adtran and liking their chassis features and NG-PON2 upgrade > > path, we are now open to other vendors. Price IS a concern for us, but > > not THE concern. > > > > This may sound "wacky" to some, but if anybody on here is using Huawei > > GPON gear, could you contact me off list? Thanks > > (josh AT kyneticwifi.com) > > > > On Mon, Nov 9, 2015 at 8:49 AM, Jay Patel wrote: > > > Who is your favorite GPON OLT/ONU Vendor? Why? I am looking for > > > recommendations > > > > > > I apologize in advance , if you feel my question is inappropriate for > > this > > > mailing list ( feel free to point me to right forum/mailing list). > > > > > > Regards, > > > Jay. > > > > > > > From eliezer at ngtech.co.il Fri Nov 13 01:44:51 2015 From: eliezer at ngtech.co.il (Eliezer Croitoru) Date: Fri, 13 Nov 2015 03:44:51 +0200 Subject: Fwd: Updated Ookla Speedtest Server Requirements In-Reply-To: <05BF09C5-F623-4AB0-AF92-CF5D162C1747@hathcock.org> References: <3A171327-34E4-4E49-BC34-B6906A06CEB7@hathcock.org> <05BF09C5-F623-4AB0-AF92-CF5D162C1747@hathcock.org> Message-ID: <56454093.8000404@ngtech.co.il> On 10/11/2015 03:19, Lorell Hathcock wrote: > Currently using IBM/LENOVO x3550 / 12 GB RAM / 2 x Xeon E5620 What???? This is an overkill for this tiny task. >>> >>>10GbE uplink currently handling ~2gbps peak traffic. These services are not meant to sustain 10Gbe for a very long time. The specs from: http://www.ookla.com/support/a26461638/ Are pretty good and accurate. As long you won't use ATOM CPUs you will probably max the 10Gbe. Eliezer From nanog at ics-il.net Fri Nov 13 02:32:51 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 12 Nov 2015 20:32:51 -0600 (CST) Subject: Colo space at Cermak Message-ID: <58257764.1089.1447381997161.JavaMail.mhammett@ThunderFuck> Has something happened the past couple months to cause a quick shortage of space at Cermak? I had an offer sent a few months ago (when I didn't need it) where a cab and five cross connects were cheaper than what five cross connects normally are, much less the cabinet value as well. Around that time I think cabinets were going for $700 or so for basic primary\redundant 20A. Now the cabinet is going for $1,800. It went from being the cheapest I've seen at Cermak to the most I've seen at Cermak in a matter of a few months. Two people with space in that building are citing an uptick in demand. Really? That much of a demand increase with hundreds of thousands of square feet coming online in the Chicago metro? Can anyone corroborate that story or are they just making stuff up hoping I agree to inflated cabinet prices? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com From aftab.siddiqui at gmail.com Fri Nov 13 03:02:29 2015 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Fri, 13 Nov 2015 03:02:29 +0000 Subject: Favorite GPON Vendor? In-Reply-To: <56450763.60804@lanparty.ee> References: <564426A0.7030905@seacom.mu> <56450763.60804@lanparty.ee> Message-ID: On Fri, 13 Nov 2015 at 08:43 Tarko Tikan wrote: > hey, > > > I used Huawei GPON gear at previous job. > > +1 for the MA5600 series. > +1 for MA5600. Very stable and inter-op is also possible. -- Best Wishes, Aftab A. Siddiqui From jfmezei_nanog at vaxination.ca Fri Nov 13 03:27:01 2015 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 12 Nov 2015 22:27:01 -0500 Subject: DNSSEC and ISPs faking DNS responses Message-ID: <56455885.8090409@vaxination.ca> The Qu?bec government is wanting to pass a law that will force ISPs to block and/or redirect certain sites it doesn't like. (namely sites that offer on-line gambling that compete against its own Loto Qu?bec). In order to make a good submission to government, once has to boil it donw to simple enough arguments that clueless politicians can understand. And for me to do that, I want to make sure I understand this correctly. I have tried to research DNSSEC and while I understand how a proper DNS server can validate the chain from the - root server - TLD server - authoritative DNS server for that domain I remain in dark with regartds to clients, namely clients who cannot trust the DNS server supplied as part of DHCP/IPCP/PPPoE responses. Say a consumer wants to connect to lottery.com, which, from the world outside the ISP, would result in a signed, verifiable response. Can't the ISP's DNS server just pretend it is authoritative for lottery.com and return to client a non-DNSSEC response that points to a fake IP address ? If the client gets an unsigned response for lottery.com from its ISP's DNS server, how can it know it is a fake response, how can it know that lottery.com should have generated a signed DNSSEC response ? It seems to me that unless each client goes to the tld servers (they already have root signatures), get signature of the tld server and signed response of where "lotery.com" can be found, they have no way to know whether lottery.com should be signed or not, and whether the answer they got from their ISP is good or not. Is that a proper understanding ? So far, I have seen good explanations of what happens between DNS servers and the servers that are authoritative for domain, TLD and root. But I have seen nothing about clients who only have a resolver that talks to a DNS server. And while I am at it: when a client gets a legit response from ISP's DNS server with RRSIG records, how does the client obtain the public key against which to run the record to ensure its calculated signature matches that provided in RRSIG ? or do DNS servers return the full chain of records so that a request for lottery.com returns not only record for lottery.com but also .com,s reply on where lottery.com is and root's reply of where .com is ? Hopefully, I am only missing a small bit that would explain everything that happens at the client side. But as long as I am told that the client only talks to the ISP's DNS server, I am at a loss. Any help appreciated. (I just watched an hour long youtube on subject which didn't deal with client much). From bob at FiberInternetCenter.com Fri Nov 13 03:36:08 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Thu, 12 Nov 2015 19:36:08 -0800 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <56455885.8090409@vaxination.ca> References: <56455885.8090409@vaxination.ca> Message-ID: This will only create an new private (non-public) DNS service in China or Romania for Canadians to use. Imagine that someone in China starts a business to help people get around censorship in countries other than China. You nailed it - "clueless politicians". Bob Evans CTO > > The Qu??bec government is wanting to pass a law that will force ISPs to > block and/or redirect certain sites it doesn't like. (namely sites that > offer on-line gambling that compete against its own Loto Qu??bec). > > In order to make a good submission to government, once has to boil it > donw to simple enough arguments that clueless politicians can > understand. And for me to do that, I want to make sure I understand this > correctly. > > > I have tried to research DNSSEC and while I understand how a proper DNS > server can validate the chain from the > - root server > - TLD server > - authoritative DNS server for that domain > > I remain in dark with regartds to clients, namely clients who cannot > trust the DNS server supplied as part of DHCP/IPCP/PPPoE responses. > > > Say a consumer wants to connect to lottery.com, which, from the world > outside the ISP, would result in a signed, verifiable response. > > Can't the ISP's DNS server just pretend it is authoritative for > lottery.com and return to client a non-DNSSEC response that points to a > fake IP address ? > > If the client gets an unsigned response for lottery.com from its ISP's > DNS server, how can it know it is a fake response, how can it know that > lottery.com should have generated a signed DNSSEC response ? > > > It seems to me that unless each client goes to the tld servers (they > already have root signatures), get signature of the tld server and > signed response of where "lotery.com" can be found, they have no way to > know whether lottery.com should be signed or not, and whether the answer > they got from their ISP is good or not. > > Is that a proper understanding ? > > > > So far, I have seen good explanations of what happens between DNS > servers and the servers that are authoritative for domain, TLD and root. > But I have seen nothing about clients who only have a resolver that > talks to a DNS server. > > > And while I am at it: when a client gets a legit response from ISP's DNS > server with RRSIG records, how does the client obtain the public key > against which to run the record to ensure its calculated signature > matches that provided in RRSIG ? > > or do DNS servers return the full chain of records so that a request for > lottery.com returns not only record for lottery.com but also .com,s > reply on where lottery.com is and root's reply of where .com is ? > > > Hopefully, I am only missing a small bit that would explain everything > that happens at the client side. But as long as I am told that the > client only talks to the ISP's DNS server, I am at a loss. > > Any help appreciated. (I just watched an hour long youtube on subject > which didn't deal with client much). > From marka at isc.org Fri Nov 13 04:07:29 2015 From: marka at isc.org (Mark Andrews) Date: Fri, 13 Nov 2015 15:07:29 +1100 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: Your message of "Thu, 12 Nov 2015 22:27:01 -0500." <56455885.8090409@vaxination.ca> References: <56455885.8090409@vaxination.ca> Message-ID: <20151113040729.59FA93C9BC9A@rock.dv.isc.org> In message <56455885.8090409 at vaxination.ca>, Jean-Francois Mezei writes: > > The Qu??bec government is wanting to pass a law that will force ISPs to > block and/or redirect certain sites it doesn't like. (namely sites that > offer on-line gambling that compete against its own Loto Qu??bec). > > In order to make a good submission to government, once has to boil it > donw to simple enough arguments that clueless politicians can > understand. And for me to do that, I want to make sure I understand this > correctly. > > > I have tried to research DNSSEC and while I understand how a proper DNS > server can validate the chain from the > - root server > - TLD server > - authoritative DNS server for that domain > > I remain in dark with regartds to clients, namely clients who cannot > trust the DNS server supplied as part of DHCP/IPCP/PPPoE responses. > > > Say a consumer wants to connect to lottery.com, which, from the world > outside the ISP, would result in a signed, verifiable response. > > Can't the ISP's DNS server just pretend it is authoritative for > lottery.com and return to client a non-DNSSEC response that points to a > fake IP address ? No. If the client is validating the response it will fail validation. > If the client gets an unsigned response for lottery.com from its ISP's > DNS server, how can it know it is a fake response, how can it know that > lottery.com should have generated a signed DNSSEC response ? Because it asks the ISP for DS lottery.com and that response tells the client if it should be getting a signed response or not and which DNSKEYs to trust. > It seems to me that unless each client goes to the tld servers (they > already have root signatures), get signature of the tld server and > signed response of where "lotery.com" can be found, they have no way to > know whether lottery.com should be signed or not, and whether the answer > they got from their ISP is good or not. > > Is that a proper understanding ? DNSSEC was designed to allow a client to get answers from a recursive server it does not trust and verify that the answer has not been tampered with. There are not many clients that do this yet but that was the design goal and yes it was achieved. > So far, I have seen good explanations of what happens between DNS > servers and the servers that are authoritative for domain, TLD and root. > But I have seen nothing about clients who only have a resolver that > talks to a DNS server. They make the same queries and verify the answers the same way. For lottery.com they would ask for the DNSKEY records for lottery.com, the DS records for lottery.com, the DNSKEY records for com, the DS records for com and the DNSKEY records for the root. It doesn't matter if these come from a cache or directly from the authoritative servers. The crypto to verify the answers is the same. > And while I am at it: when a client gets a legit response from ISP's DNS > server with RRSIG records, how does the client obtain the public key > against which to run the record to ensure its calculated signature > matches that provided in RRSIG ? It asks for the DNSKEY records and RRSIGs. Verifies them against the DS records whick it asks for. Repeat all the way to the root. > or do DNS servers return the full chain of records so that a request for > lottery.com returns not only record for lottery.com but also .com,s > reply on where lottery.com is and root's reply of where .com is ? > > > Hopefully, I am only missing a small bit that would explain everything > that happens at the client side. But as long as I am told that the > client only talks to the ISP's DNS server, I am at a loss. > > Any help appreciated. (I just watched an hour long youtube on subject > which didn't deal with client much). -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From johnl at iecc.com Fri Nov 13 04:50:27 2015 From: johnl at iecc.com (John Levine) Date: 13 Nov 2015 04:50:27 -0000 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <56455885.8090409@vaxination.ca> Message-ID: <20151113045027.6997.qmail@ary.lan> In article <56455885.8090409 at vaxination.ca> you write: >The Qu?bec government is wanting to pass a law that will force ISPs to >block and/or redirect certain sites it doesn't like. (namely sites that >offer on-line gambling that compete against its own Loto Qu?bec). Blocking is prettty easy, just don't return the result, or fake an NXDOMAIN. For a signed domain, a DNSSEC client will see a SERVERFAIL instead, but they still won't get a result. Redirecting is much harder -- as others have explained there is a chain of signatures from the root to the desired record, and if the chain isn't intact, it's SERVERFAIL again. Inserting a replacement record with a fake signature into the original chain is intended to be impossible. (If you figure out how, CSIS would really like to talk to you.) It is possible to configure an ISP's DNS caches to trust specific signatures for specific parts of the tree, but that is kludgy and fragile and is likely to break DNS for everyone. And anyway, it's pointless. What they're saying is to take the gambling sites out of the phone book, but this is the Internet and there are a million other phone books available, outside of Quebec, such as Google's 8.8.8.8 located in the US, that people can configure their computers to use with a few mouse clicks. Or you can run your own cache on your home network like I do, just run NSD or BIND on a linux laptop. They could insist that ISPs block the actual web traffic to the sites, by blocking IP ranges, but that is also a losing battle since it's trivial to circumvent with widely available free VPN software. If they want to outlaw VPNs, they're outlawing telework, since VPNs is how remote workers connect to their employers' systems, and the software is identical. R's, John From alejandroacostaalamo at gmail.com Fri Nov 13 05:03:10 2015 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Fri, 13 Nov 2015 00:33:10 -0430 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <20151113045027.6997.qmail@ary.lan> References: <20151113045027.6997.qmail@ary.lan> Message-ID: <56456F0E.8040701@gmail.com> Hello, El 11/13/2015 a las 12:20 AM, John Levine escribi?: > In article <56455885.8090409 at vaxination.ca> you write: >> The Qu?bec government is wanting to pass a law that will force ISPs to >> block and/or redirect certain sites it doesn't like. (namely sites that >> offer on-line gambling that compete against its own Loto Qu?bec). > Blocking is prettty easy, just don't return the result, or fake an > NXDOMAIN. For a signed domain, a DNSSEC client will see a SERVERFAIL > instead, but they still won't get a result. > > Redirecting is much harder -- as others have explained there is a > chain of signatures from the root to the desired record, and if the > chain isn't intact, it's SERVERFAIL again. Inserting a replacement > record with a fake signature into the original chain is intended to be > impossible. (If you figure out how, CSIS would really like to talk to > you.) It is possible to configure an ISP's DNS caches to trust > specific signatures for specific parts of the tree, but that is kludgy > and fragile and is likely to break DNS for everyone. I'm not a DNSSEC expert but I wonder what would be the behavior if the ISP adds a specific trust anchor for the domain they wish to block? > > And anyway, it's pointless. What they're saying is to take the > gambling sites out of the phone book, but this is the Internet and > there are a million other phone books available, outside of Quebec, > such as Google's 8.8.8.8 located in the US, that people can configure > their computers to use with a few mouse clicks. Or you can run your > own cache on your home network like I do, just run NSD or BIND on a > linux laptop. > > They could insist that ISPs block the actual web traffic to the sites, > by blocking IP ranges, but that is also a losing battle since it's > trivial to circumvent with widely available free VPN software. If > they want to outlaw VPNs, they're outlawing telework, since VPNs is > how remote workers connect to their employers' systems, and the > software is identical. > > R's, > John Thanks, Alejandro, From owen at delong.com Fri Nov 13 05:05:49 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 12 Nov 2015 21:05:49 -0800 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <20151113045027.6997.qmail@ary.lan> References: <20151113045027.6997.qmail@ary.lan> Message-ID: <5CA68A46-2F63-466A-B418-30DA71B2BAC5@delong.com> > On Nov 12, 2015, at 20:50 , John Levine wrote: > > In article <56455885.8090409 at vaxination.ca> you write: >> The Qu?bec government is wanting to pass a law that will force ISPs to >> block and/or redirect certain sites it doesn't like. (namely sites that >> offer on-line gambling that compete against its own Loto Qu?bec). > > Blocking is prettty easy, just don't return the result, or fake an > NXDOMAIN. For a signed domain, a DNSSEC client will see a SERVERFAIL > instead, but they still won't get a result. > > Redirecting is much harder -- as others have explained there is a > chain of signatures from the root to the desired record, and if the > chain isn't intact, it's SERVERFAIL again. Inserting a replacement > record with a fake signature into the original chain is intended to be > impossible. (If you figure out how, CSIS would really like to talk to > you.) It is possible to configure an ISP's DNS caches to trust > specific signatures for specific parts of the tree, but that is kludgy > and fragile and is likely to break DNS for everyone. If you know that the client is using ONLY your resolver(s), couldn?t you simply fake the entire chain and sign everything yourself? Or, alternatively, couldn?t you just fake the answers to all the ?is this signed?? requests and say ?Nope!? regardless of the state of the authoritative zone in question? Sure, if the client has any sort of independent visibility it can verify that you?re lying, but if it can only talk to your resolvers, doesn?t that pretty much mean it can?t tell that you?re lying to it? > > And anyway, it's pointless. What they're saying is to take the > gambling sites out of the phone book, but this is the Internet and > there are a million other phone books available, outside of Quebec, > such as Google's 8.8.8.8 located in the US, that people can configure > their computers to use with a few mouse clicks. Or you can run your > own cache on your home network like I do, just run NSD or BIND on a > linux laptop. I believe the traditional statement is ?This type of regulation is considered damage and will be routed around.? > > They could insist that ISPs block the actual web traffic to the sites, > by blocking IP ranges, but that is also a losing battle since it's > trivial to circumvent with widely available free VPN software. If > they want to outlaw VPNs, they're outlawing telework, since VPNs is > how remote workers connect to their employers' systems, and the > software is identical. It?s also fairly easy for the gambling sites to become somewhat IP Agile creating a game of Whack-a-mole for the regulators and the ISPs they are inflicting this pain on. Owen From johnl at iecc.com Fri Nov 13 05:29:46 2015 From: johnl at iecc.com (John Levine) Date: 13 Nov 2015 05:29:46 -0000 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <5CA68A46-2F63-466A-B418-30DA71B2BAC5@delong.com> Message-ID: <20151113052946.7102.qmail@ary.lan> >> Redirecting is much harder -- ... >If you know that the client is using ONLY your resolver(s), couldn?t you >simply fake the entire chain and sign everything yourself? I suppose, although doing that at scale in a large provider like Videotron (1.5M subscribers) would be quite a challenge. >Or, alternatively, couldn?t you just fake the answers to all the ?is this >signed?? requests and say ?Nope!? regardless of the state of the authoritative >zone in question? No, those responses are signed too. >Sure, if the client has any sort of independent visibility it can verify that >you?re lying, but if it can only talk to your resolvers, doesn?t that pretty >much mean it can?t tell that you?re lying to it? At this point very few client resolvers check DNSSEC, so something that stripped off all the DNSSEC stuff and inserted lies where required would "work" for most clients. At least until they realized they couldn't get to PokerStars and switched their DNS to 8.8.8.8. R's, John From marka at isc.org Fri Nov 13 05:30:29 2015 From: marka at isc.org (Mark Andrews) Date: Fri, 13 Nov 2015 16:30:29 +1100 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: Your message of "Thu, 12 Nov 2015 21:05:49 -0800." <5CA68A46-2F63-466A-B418-30DA71B2BAC5@delong.com> References: <20151113045027.6997.qmail@ary.lan> <5CA68A46-2F63-466A-B418-30DA71B2BAC5@delong.com> Message-ID: <20151113053029.282AA3C9C320@rock.dv.isc.org> In message <5CA68A46-2F63-466A-B418-30DA71B2BAC5 at delong.com>, Owen DeLong write s: > > > On Nov 12, 2015, at 20:50 , John Levine wrote: > > > > In article <56455885.8090409 at vaxination.ca> you write: > >> The Qu??bec government is wanting to pass a law that will force ISPs to > >> block and/or redirect certain sites it doesn't like. (namely sites > >> that offer on-line gambling that compete against its own Loto Qu??bec). > > > > Blocking is prettty easy, just don't return the result, or fake an > > NXDOMAIN. For a signed domain, a DNSSEC client will see a SERVERFAIL > > instead, but they still won't get a result. > > > > Redirecting is much harder -- as others have explained there is a > > chain of signatures from the root to the desired record, and if the > > chain isn't intact, it's SERVERFAIL again. Inserting a replacement > > record with a fake signature into the original chain is intended to be > > impossible. (If you figure out how, CSIS would really like to talk to > > you.) It is possible to configure an ISP's DNS caches to trust > > specific signatures for specific parts of the tree, but that is kludgy > > and fragile and is likely to break DNS for everyone. > > If you know that the client is using ONLY your resolver(s), couldn???t you > simply fake the entire chain and sign everything yourself? Which is exactly how we test validation in nameservers. If you tell the validator to use a bogus trust anchor you get bogus trust. > Or, alternatively, couldn???t you just fake the answers to all the ???is this > signed???? requests and say ???Nope!??? regardless of the state of the > authoritative zone in question? No. You can detect that. > Sure, if the client has any sort of independent visibility it can verify > that > you???re lying, but if it can only talk to your resolvers, doesn???t that > pretty > much mean it can???t tell that you???re lying to it? No. The root's trust anchor are published independently of whatever your ISP does. This isn't something you learn via DHCP. > > And anyway, it's pointless. What they're saying is to take the > > gambling sites out of the phone book, but this is the Internet and > > there are a million other phone books available, outside of Quebec, > > such as Google's 8.8.8.8 located in the US, that people can configure > > their computers to use with a few mouse clicks. Or you can run your > > own cache on your home network like I do, just run NSD or BIND on a > > linux laptop. > > I believe the traditional statement is ???This type of regulation is > considered > damage and will be routed around.??? > > > > > They could insist that ISPs block the actual web traffic to the sites, > > by blocking IP ranges, but that is also a losing battle since it's > > trivial to circumvent with widely available free VPN software. If > > they want to outlaw VPNs, they're outlawing telework, since VPNs is > > how remote workers connect to their employers' systems, and the > > software is identical. > > It???s also fairly easy for the gambling sites to become somewhat IP Agile > creating a game of Whack-a-mole for the regulators and the ISPs they > are inflicting this pain on. > > Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From tiago at radaction.com.br Fri Nov 13 00:53:45 2015 From: tiago at radaction.com.br (Tiago Arnold) Date: Fri, 13 Nov 2015 13:53:45 +1300 Subject: Favorite GPON Vendor? In-Reply-To: References: <001a01d11da6$7c234d40$7469e7c0$@iname.com> Message-ID: To me the best solution in GPON is http://www.parks.com.br/ from Brazil. Good support and innovation. From jocthbr at gmail.com Fri Nov 13 04:04:18 2015 From: jocthbr at gmail.com (=?UTF-8?Q?Jonathan_Falc=C3=A3o?=) Date: Fri, 13 Nov 2015 04:04:18 +0000 Subject: Favorite GPON Vendor? In-Reply-To: References: <564426A0.7030905@seacom.mu> <56450763.60804@lanparty.ee> Message-ID: I thought I would see something about fiberhome here Em sex, 13 de nov de 2015 00:04, Aftab Siddiqui escreveu: > On Fri, 13 Nov 2015 at 08:43 Tarko Tikan wrote: > > > hey, > > > > > I used Huawei GPON gear at previous job. > > > > +1 for the MA5600 series. > > > > +1 for MA5600. Very stable and inter-op is also possible. > -- > Best Wishes, > > Aftab A. Siddiqui > From cjc+nanog at pumpky.net Fri Nov 13 05:33:30 2015 From: cjc+nanog at pumpky.net (Crist Clark) Date: Thu, 12 Nov 2015 21:33:30 -0800 Subject: Another puck.nether.net Outage? Message-ID: There hasn't been a any traffic on the puck.nether.net list to which I am subscribed since the 10th. I sent something to cisco-nsp yesterday and retried today, and nothing has come through. Is it me or puck? I apologize for using NANOG for this, but jared's email is puck.nether.net too; something OOB is needed. I know there are many, many people here who also follow puck.nether.net lists and some may have another way to reach him. From nanog-isp at mail.com Fri Nov 13 06:42:28 2015 From: nanog-isp at mail.com (nanog-isp at mail.com) Date: Fri, 13 Nov 2015 07:42:28 +0100 Subject: Favorite GPON Vendor? Message-ID: > Too bad they require registration.... Direct download link: http://www.webcaster4.com/Player/Material?uid=2305846&materialGuid=5f4478fb-d75f-4ef6-93f3-e25b67862c7a Or login with doe at sharklasers.com. Jared From jfmezei_nanog at vaxination.ca Fri Nov 13 09:27:36 2015 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 13 Nov 2015 04:27:36 -0500 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <20151113040729.59FA93C9BC9A@rock.dv.isc.org> References: <56455885.8090409@vaxination.ca> <20151113040729.59FA93C9BC9A@rock.dv.isc.org> Message-ID: <5645AD08.8070104@vaxination.ca> On 2015-11-12 23:07, Mark Andrews wrote: > They make the same queries and verify the answers the same way. > It asks for the DNSKEY records and RRSIGs. Verifies them against the DS > records whick it asks for. Repeat all the way to the root. Is it correct to state that clients, instead of issuing a single request to the ISP's DNS server and let it do the recursion, will request (if not cached already) records from the root, the tld and the domain's authoritative server to get the DNSSEC records for each in order to be able to "walk" the path and verify each signature ? So this would result in significant increase in number of transactions between clients and ISP DNS servers, correct ? If the above is correct, then it provides me with the missing link to my understanbding. BTW, the proposed law, being done by lawyers, will have the list of sites to be banned distributed to ISPs via REGISTERED MAIL. (there are two means to have "legal" documents served, registered mail and by bailiffs in Qu?bec). (there are to be financial penalties to ISPs who do not comply, so govt needs proof of delivery). I'll have to research how other countries tried to implement similar schemes (I believe the UK has with some of the popular torrent sites. I know the Australian attempt to filter porn failed miserably. From bjorn at mork.no Fri Nov 13 09:51:52 2015 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 13 Nov 2015 10:51:52 +0100 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <56455885.8090409@vaxination.ca> (Jean-Francois Mezei's message of "Thu, 12 Nov 2015 22:27:01 -0500") References: <56455885.8090409@vaxination.ca> Message-ID: <87y4e2mdl3.fsf@nemi.mork.no> Jean-Francois Mezei writes: > The Qu?bec government is wanting to pass a law that will force ISPs to > block and/or redirect certain sites it doesn't like. BTDT. See https://torrentfreak.com/pirate-sites-must-pay-legal-costs-of-own-blockade-court-rules-150902/ (yes, we could discuss the point of all this - but that is a political discussion, and there are better fora for those. Let's keep this techical here, please) Now, we mostly don't do DNSSEC validation yet, and luckily none of the blocked domains have any DS records either. So DNSSEC is not yet a real problem in this regard. But there is no reason to think this luck will last forever. Given the "success", we can only assume there will be more court orders. And we do want to enable DNSSEC validation everywhere at some point. So what do we do? We currently point the blocked domains to addresses of a web server with a short explanation. But what if the domains were signed? We could let validating servers return SERVFAIL. But I'd really prefer avoiding that for the simple reason that there is no way to distinguish that SERVFAIL from one caused by e.g. a domain owner configuration error. So I'm wondering if DLV might help us here? I imagine it will allow us to return a signed response to the client, with the AD flag, even if we have taken control of the domain. Or won't that work at all if the parent has a DS record? If the DLV strategy works, then the main advantage would be that a validating client could distiguish between a domain owner error and a deliberate "error" added by us as a resolver operator. The DLV signed response will still fail client calidation. And we would of course publish the DLV key, so that anyone wishing to verify the source of the failing signatures could do that (assuming that some clients may accept us as a MITM, but still want to prevent others from the same attack). What do you all think? Is this feasible? Any better solutions? OK, I should probably lab this instead of discussing it... Bj?rn (working for Telenor, but definitely not having any role in PR or legal matters) From A.L.M.Buxey at lboro.ac.uk Fri Nov 13 09:54:28 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Fri, 13 Nov 2015 09:54:28 +0000 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <5645AD08.8070104@vaxination.ca> References: <56455885.8090409@vaxination.ca> <20151113040729.59FA93C9BC9A@rock.dv.isc.org> <5645AD08.8070104@vaxination.ca> Message-ID: <20151113095428.GB29094@lboro.ac.uk> Hi, > BTW, the proposed law, being done by lawyers, will have the list of you say law.... but this idea of blocking all competitors to the states lotto sounds very unlawful and anti-competitive - yes, I can understand states or countries blocking ALL gambling , thats a simple 'we dont allow it here' , but to say 'yes, you can access just ours' well, in EU I dont think that would ever fly. > I know the Australian attempt to filter porn failed miserably. well, one could say people might be more determined to access porn than gambling sites so this gambling block might be more successful. either way, what you'll get are a host of DNS services based in other countries - some using VPN technology etc so blocking port 53 to other servers isnt going to work on that score either. it wont work. alan From alarig at swordarmor.fr Fri Nov 13 10:21:27 2015 From: alarig at swordarmor.fr (Alarig Le Lay) Date: Fri, 13 Nov 2015 11:21:27 +0100 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <5645AD08.8070104@vaxination.ca> References: <56455885.8090409@vaxination.ca> <20151113040729.59FA93C9BC9A@rock.dv.isc.org> <5645AD08.8070104@vaxination.ca> Message-ID: <20151113102127.GJ28689@drscott.swordarmor.fr> On Fri Nov 13 04:27:36 2015, Jean-Francois Mezei wrote: > I'll have to research how other countries tried to implement similar > schemes (I believe the UK has with some of the popular torrent sites. > > I know the Australian attempt to filter porn failed miserably. We also have some torrent sites blocked in France, for exemple: alarig at HP-Z210:~$ dig +noall +comments +answer t411.me @193.252.19.3 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38309 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1460 ;; ANSWER SECTION: t411.me. 16418 IN A 127.0.0.1 alarig at HP-Z210:~$ dig +noall +comments +answer t411.me ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41652 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; ANSWER SECTION: t411.me. 70 IN A 104.18.37.180 t411.me. 70 IN A 104.18.36.180 But, if you look at the flags, there?s no ad, so no DNSSEC (my resolver has DNSSEC enabled) -- alarig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From morrowc.lists at gmail.com Fri Nov 13 14:46:17 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 13 Nov 2015 09:46:17 -0500 Subject: Another puck.nether.net Outage? In-Reply-To: References: Message-ID: Received: from puck.nether.net (localhost [IPv6:::1]) by puck.nether.net (Postfix) with ESMTP id 25969540762; Fri, 13 Nov 2015 07:05:01 -0500 (EST) puck seems to be processing mail... $ w 09:45:28 up 2 days, 11:30, 2 users, $ mailq | grep cisco-nsp | wc -l 174 $ mailq | grep pumpk | wc -l 0 On Fri, Nov 13, 2015 at 12:33 AM, Crist Clark wrote: > There hasn't been a any traffic on the puck.nether.net list to which I am > subscribed since the 10th. I sent something to cisco-nsp yesterday and > retried today, and nothing has come through. > > Is it me or puck? > > I apologize for using NANOG for this, but jared's email is puck.nether.net > too; something OOB is needed. I know there are many, many people here who > also follow puck.nether.net lists and some may have another way to reach > him. From Andrew.White2 at charter.com Fri Nov 13 14:52:34 2015 From: Andrew.White2 at charter.com (White, Andrew) Date: Fri, 13 Nov 2015 08:52:34 -0600 Subject: Contact for Open Resolver Project? Message-ID: <678FDBA32DA0DD4A8EFB6D1C2FDC268A0202BB708A@KSTLMEXCP02MBX.CORP.CHARTERCOM.COM> Hi there, If anyone from the Open Resolver Project is on-list, would love to get in touch re. getting a feed of open resolver data for our ASN. I have not been receiving response to the email address listed on the project's web site. Andrew White Desk: 314.394-9594 | Cell: 314.308-7730 NetOps Consultant, DAS DNS group Charter Communications 12405 Powerscourt Drive, St. Louis, MO 63131 From hugo at slabnet.com Fri Nov 13 15:25:42 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 13 Nov 2015 07:25:42 -0800 (PST) Subject: Another puck.nether.net Outage? In-Reply-To: References: Message-ID: <3d72da88.kqhkiG.1510173c4cd@slabnet.com> The problem seems to have been with mailman. I pinged Jared OOB and he responded this that it's fixed. I'd sent something to outages-request prior to test, and that came through this morning. -- Hugo hugo at slabnet.com: email, xmpp/jabber also on Signal ---- From: Christopher Morrow -- Sent: 2015-11-13 - 06:46 ---- > Received: from puck.nether.net (localhost [IPv6:::1]) > by puck.nether.net (Postfix) with ESMTP id 25969540762; > Fri, 13 Nov 2015 07:05:01 -0500 (EST) > > puck seems to be processing mail... > > $ w > 09:45:28 up 2 days, 11:30, 2 users, > > $ mailq | grep cisco-nsp | wc -l > 174 > > $ mailq | grep pumpk | wc -l > 0 > > On Fri, Nov 13, 2015 at 12:33 AM, Crist Clark wrote: >> There hasn't been a any traffic on the puck.nether.net list to which I am >> subscribed since the 10th. I sent something to cisco-nsp yesterday and >> retried today, and nothing has come through. >> >> Is it me or puck? >> >> I apologize for using NANOG for this, but jared's email is puck.nether.net >> too; something OOB is needed. I know there are many, many people here who >> also follow puck.nether.net lists and some may have another way to reach >> him. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 870 bytes Desc: PGP/MIME digital signature URL: From johnl at iecc.com Fri Nov 13 17:15:45 2015 From: johnl at iecc.com (John Levine) Date: 13 Nov 2015 17:15:45 -0000 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <20151113095428.GB29094@lboro.ac.uk> Message-ID: <20151113171545.4522.qmail@ary.lan> >> BTW, the proposed law, being done by lawyers, will have the list of > >you say law.... but this idea of blocking all competitors to the states >lotto sounds very unlawful and anti-competitive This is Qu?bec, where the rules are not the same as in the UK. The provincial lottery is the only legal gambling in the province, give or take the large amount of online gambling hosted on the Mohawk reservation that's partly in Qu?bec and partly in New York. >either way, what you'll get are a host of DNS services based in other >countries - some using VPN technology etc so blocking port 53 to >other servers isnt going to work on that score either. it wont work. Of course not. R's, John From owen at delong.com Fri Nov 13 17:25:18 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 13 Nov 2015 09:25:18 -0800 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <20151113052946.7102.qmail@ary.lan> References: <20151113052946.7102.qmail@ary.lan> Message-ID: <9A14E989-8633-4937-BE46-7D27F5747235@delong.com> > On Nov 12, 2015, at 21:29 , John Levine wrote: > >>> Redirecting is much harder -- ... > >> If you know that the client is using ONLY your resolver(s), couldn?t you >> simply fake the entire chain and sign everything yourself? > > I suppose, although doing that at scale in a large provider like Videotron > (1.5M subscribers) would be quite a challenge. > >> Or, alternatively, couldn?t you just fake the answers to all the ?is this >> signed?? requests and say ?Nope!? regardless of the state of the authoritative >> zone in question? > > No, those responses are signed too. Only if you pass through the claim that the parent domain is signed. Again, if you?re the only resolver the clients are using, you can claim that nothing from the root down is signed without ever providing any cryptographic anything. Seems to me that wouldn?t be significantly harder than running a resolver at the same scale. > >> Sure, if the client has any sort of independent visibility it can verify that >> you?re lying, but if it can only talk to your resolvers, doesn?t that pretty >> much mean it can?t tell that you?re lying to it? > > At this point very few client resolvers check DNSSEC, so something > that stripped off all the DNSSEC stuff and inserted lies where > required would "work" for most clients. At least until they realized > they couldn't get to PokerStars and switched their DNS to 8.8.8.8. If the ISPs don?t start blocking well known public resolvers or even just blocking port 53 in general (which has been known to happen). Owen From johnl at iecc.com Fri Nov 13 17:33:12 2015 From: johnl at iecc.com (John R. Levine) Date: 13 Nov 2015 12:33:12 -0500 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <9A14E989-8633-4937-BE46-7D27F5747235@delong.com> References: <20151113052946.7102.qmail@ary.lan> <9A14E989-8633-4937-BE46-7D27F5747235@delong.com> Message-ID: >> At this point very few client resolvers check DNSSEC, so something >> that stripped off all the DNSSEC stuff and inserted lies where >> required would "work" for most clients. At least until they realized >> they couldn't get to PokerStars and switched their DNS to 8.8.8.8. > > If the ISPs don?t start blocking well known public resolvers or even just > blocking port 53 in general (which has been known to happen). I doubt the ISPs in Qu?bec would have much sympathy for this proposed law. It makes their life harder and provides them no benefit. Should it pass (remember, it's just proposed), I expect they'd just adjust their DNS caches to block responses for the list of domains that the government mails them and claim they're in full compliance. R's, John From eric-list at truenet.com Fri Nov 13 18:12:24 2015 From: eric-list at truenet.com (eric-list at truenet.com) Date: Fri, 13 Nov 2015 13:12:24 -0500 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: References: <20151113052946.7102.qmail@ary.lan> <9A14E989-8633-4937-BE46-7D27F5747235@delong.com> Message-ID: <002801d11e3e$d8973990$89c5acb0$@truenet.com> Actually, how are other places implementing these lists? I would have thought to use RPZ, but as far as I know if the blocked DNS domain is using DNSSEC it wouldn't work. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of John R. Levine Sent: Friday, November 13, 2015 12:33 PM To: Owen DeLong Cc: nanog at nanog.org Subject: Re: DNSSEC and ISPs faking DNS responses I doubt the ISPs in Qu?bec would have much sympathy for this proposed law. It makes their life harder and provides them no benefit. Should it pass (remember, it's just proposed), I expect they'd just adjust their DNS caches to block responses for the list of domains that the government mails them and claim they're in full compliance. R's, John From mlm at pixelgate.net Fri Nov 13 18:24:27 2015 From: mlm at pixelgate.net (Mark Milhollan) Date: Fri, 13 Nov 2015 10:24:27 -0800 (PST) Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <20151113052946.7102.qmail@ary.lan> References: <20151113052946.7102.qmail@ary.lan> Message-ID: On Thu, 13 Nov 2015, John Levine wrote: >At this point very few client resolvers check DNSSEC, so something >that stripped off all the DNSSEC stuff and inserted lies where >required would "work" for most clients. At least until they realized >they couldn't get to PokerStars and switched their DNS to 8.8.8.8. Except that the ISP can intercept those queries and respond as it likes. Such is already done at all scales. Not that a government generally cares what kind of burden is required once the law is passed, cf CALEA. True, some users would be able to detect such tampering and many of those could work around it. But most will have no way to do either. Would the masses ever replace their stub with a full resolver? Doubtful, unless their OS vendor does it for them. Would that be the right thing to do for a few billion users of Windows and another couple billion using Android most of whose ISPs are providing unfaked answers? Would the various authoritiative operators be happy / agree? How does one fit local zones into the picture? Would the masses setup a VPN to a service provider in a jurisdiction not subject to such foolishness so their resolver, whether stub or full, would have a chance at unfaked answers? Again, I'm thinking most would be entirely ignorant of the issue, and in any case would be hard pressed to set anything up unless it was trivial, e.g., not just part of their OS but also Wizard-like with most answers pre-supplied. /mark From greg at gregsowell.com Fri Nov 13 14:53:24 2015 From: greg at gregsowell.com (Greg Sowell) Date: Fri, 13 Nov 2015 08:53:24 -0600 Subject: Colo space at Cermak In-Reply-To: <58257764.1089.1447381997161.JavaMail.mhammett@ThunderFuck> References: <58257764.1089.1447381997161.JavaMail.mhammett@ThunderFuck> Message-ID: I would guess it has to do with competing with your landlord now. I know it's starting to happen more and more. On Thu, Nov 12, 2015 at 8:32 PM, Mike Hammett wrote: > Has something happened the past couple months to cause a quick shortage of > space at Cermak? I had an offer sent a few months ago (when I didn't need > it) where a cab and five cross connects were cheaper than what five cross > connects normally are, much less the cabinet value as well. Around that > time I think cabinets were going for $700 or so for basic primary\redundant > 20A. Now the cabinet is going for $1,800. It went from being the cheapest > I've seen at Cermak to the most I've seen at Cermak in a matter of a few > months. Two people with space in that building are citing an uptick in > demand. Really? That much of a demand increase with hundreds of thousands > of square feet coming online in the Chicago metro? > > Can anyone corroborate that story or are they just making stuff up hoping > I agree to inflated cabinet prices? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > > -- GregSowell.com TheBrothersWISP.com From virendra.rode at gmail.com Fri Nov 13 16:56:03 2015 From: virendra.rode at gmail.com (virendra rode) Date: Fri, 13 Nov 2015 08:56:03 -0800 Subject: Another puck.nether.net Outage? In-Reply-To: <3d72da88.kqhkiG.1510173c4cd@slabnet.com> References: <3d72da88.kqhkiG.1510173c4cd@slabnet.com> Message-ID: <2562FED7-646C-4477-9392-675A16C80F26@gmail.com> Thank you for reaching out. Will update outages wiki so people can reach admins directly for future reference. Sorry for any inconvenience this may have caused. regards, outages team > On Nov 13, 2015, at 7:25 AM, Hugo Slabbert wrote: > > The problem seems to have been with mailman. I pinged Jared OOB and he responded this that it's fixed. I'd sent something to outages-request prior to test, and that came through this morning. > -- > Hugo > hugo at slabnet.com: email, xmpp/jabber > also on Signal > > ---- From: Christopher Morrow -- Sent: 2015-11-13 - 06:46 ---- > >> Received: from puck.nether.net (localhost [IPv6:::1]) >> by puck.nether.net (Postfix) with ESMTP id 25969540762; >> Fri, 13 Nov 2015 07:05:01 -0500 (EST) >> >> puck seems to be processing mail... >> >> $ w >> 09:45:28 up 2 days, 11:30, 2 users, >> >> $ mailq | grep cisco-nsp | wc -l >> 174 >> >> $ mailq | grep pumpk | wc -l >> 0 >> >>> On Fri, Nov 13, 2015 at 12:33 AM, Crist Clark wrote: >>> There hasn't been a any traffic on the puck.nether.net list to which I am >>> subscribed since the 10th. I sent something to cisco-nsp yesterday and >>> retried today, and nothing has come through. >>> >>> Is it me or puck? >>> >>> I apologize for using NANOG for this, but jared's email is puck.nether.net >>> too; something OOB is needed. I know there are many, many people here who >>> also follow puck.nether.net lists and some may have another way to reach >>> him. > > From johnl at iecc.com Fri Nov 13 20:01:23 2015 From: johnl at iecc.com (John Levine) Date: 13 Nov 2015 20:01:23 -0000 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: Message-ID: <20151113200123.4931.qmail@ary.lan> >Would the masses setup a VPN to a service provider in a jurisdiction not >subject to such foolishness so their resolver, whether stub or full, >would have a chance at unfaked answers? Again, I'm thinking most would >be entirely ignorant of the issue, and in any case would be hard pressed >to set anything up unless it was trivial, e.g., not just part of their >OS but also Wizard-like with most answers pre-supplied. I was at a most interesting session in New Zealand a few months ago, about video streaming in NZ. People want to watch Netflix and Hulu, and are willing to pay for it, but NZ is such a small market that the big providers can't be bothered to license the content for NZ, and by the time local providers make arrangements it's a month later. So everyone buys a Netflix subsription and uses VPNs to pretend to be in the US. Take a look at Vyprvpn, which is pretty much point and install, or even Tunnelblick which is about four clicks to set up with VPN info from any provider. Civilians definitely use these. R's, John From bortzmeyer at nic.fr Fri Nov 13 21:59:38 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 13 Nov 2015 22:59:38 +0100 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <5645AD08.8070104@vaxination.ca> References: <56455885.8090409@vaxination.ca> <20151113040729.59FA93C9BC9A@rock.dv.isc.org> <5645AD08.8070104@vaxination.ca> Message-ID: <20151113215937.GA18454@sources.org> On Fri, Nov 13, 2015 at 04:27:36AM -0500, Jean-Francois Mezei wrote a message of 34 lines which said: > I'll have to research how other countries tried to implement similar > schemes https://www.afnic.fr/en/about-afnic/news/general-news/6584/show/the-afnic-scientific-council-shares-its-report-on-dns-based-internet-filtering.html From bortzmeyer at nic.fr Fri Nov 13 22:01:09 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 13 Nov 2015 23:01:09 +0100 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <20151113095428.GB29094@lboro.ac.uk> References: <56455885.8090409@vaxination.ca> <20151113040729.59FA93C9BC9A@rock.dv.isc.org> <5645AD08.8070104@vaxination.ca> <20151113095428.GB29094@lboro.ac.uk> Message-ID: <20151113220109.GB18454@sources.org> On Fri, Nov 13, 2015 at 09:54:28AM +0000, A.L.M.Buxey at lboro.ac.uk wrote a message of 20 lines which said: > well, in EU I dont think that would ever fly. It is done in France, for a long time . From bortzmeyer at nic.fr Fri Nov 13 22:02:42 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 13 Nov 2015 23:02:42 +0100 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: References: <20151113052946.7102.qmail@ary.lan> Message-ID: <20151113220242.GC18454@sources.org> On Fri, Nov 13, 2015 at 10:24:27AM -0800, Mark Milhollan wrote a message of 30 lines which said: > Would the masses ever replace their stub with a full resolver? > Doubtful, unless their OS vendor does it for them. Fedora already does it, apparently, with the excellent dnssec-trigger. > Would the various authoritiative operators be happy / agree? Wearing my TLD operator hat: yes, we agree and we're ready for that. From mdavids at forfun.net Fri Nov 13 22:10:09 2015 From: mdavids at forfun.net (Marco Davids) Date: Fri, 13 Nov 2015 23:10:09 +0100 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <20151113220109.GB18454@sources.org> References: <56455885.8090409@vaxination.ca> <20151113040729.59FA93C9BC9A@rock.dv.isc.org> <5645AD08.8070104@vaxination.ca> <20151113095428.GB29094@lboro.ac.uk> <20151113220109.GB18454@sources.org> Message-ID: <56465FC1.6060602@forfun.net> On 13/11/15 23:01, Stephane Bortzmeyer wrote: > On Fri, Nov 13, 2015 at 09:54:28AM +0000, > A.L.M.Buxey at lboro.ac.uk wrote > >> well, in EU I dont think that would ever fly. > > It is done in France, for a long time And it is common practice in Belgium as well. http://networkmsg.telenet.be/blocked/fccu/ http://networkmsg.telenet.be/blocked/ksc/ -- Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4239 bytes Desc: S/MIME Cryptographic Signature URL: From nick at foobar.org Fri Nov 13 22:20:19 2015 From: nick at foobar.org (Nick Hilliard) Date: Fri, 13 Nov 2015 22:20:19 +0000 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <56465FC1.6060602@forfun.net> References: <56455885.8090409@vaxination.ca> <20151113040729.59FA93C9BC9A@rock.dv.isc.org> <5645AD08.8070104@vaxination.ca> <20151113095428.GB29094@lboro.ac.uk> <20151113220109.GB18454@sources.org> <56465FC1.6060602@forfun.net> Message-ID: <56466223.8090108@foobar.org> On 13/11/2015 22:10, Marco Davids wrote: > On 13/11/15 23:01, Stephane Bortzmeyer wrote: >> On Fri, Nov 13, 2015 at 09:54:28AM +0000, >> A.L.M.Buxey at lboro.ac.uk wrote >> >>> well, in EU I dont think that would ever fly. >> >> It is done in France, for a long time > > And it is common practice in Belgium as well. > > http://networkmsg.telenet.be/blocked/fccu/ > http://networkmsg.telenet.be/blocked/ksc/ A similar law was tacked to the bottom of a finance bill regulating gambling in Ireland a couple of months ago. The first anyone knew of it was when the government department responsible for gambling came knocking on the ISP association's door wanting to talk about implementation details. Nick From drc at virtualized.org Fri Nov 13 22:22:15 2015 From: drc at virtualized.org (David Conrad) Date: Fri, 13 Nov 2015 14:22:15 -0800 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: References: <20151113052946.7102.qmail@ary.lan> Message-ID: <9692ECC6-34AD-49C0-B310-10B8EF8C112C@virtualized.org> On Nov 13, 2015, at 10:24 AM, Mark Milhollan wrote: > On Thu, 13 Nov 2015, John Levine wrote: > >> At this point very few client resolvers check DNSSEC, so something >> that stripped off all the DNSSEC stuff and inserted lies where >> required would "work" for most clients. At least until they realized >> they couldn't get to PokerStars and switched their DNS to 8.8.8.8. > > Except that the ISP can intercept those queries and respond as it likes. Thank you. I was wondering if anyone would mention this. DNSSEC only protects the validator's cache. My assumption (which may be wrong) is that for the vast majority of folks, that means the cache that is run by the ISP. How many of the ISPs in Quebec enable DNSSEC? Even if they do, I doubt the government would care: I would presume it would be up to the ISP to implement the law and respond back as the law dictates. How many of the ISPs would continue to enable DNSSEC if the cops show up at their door and turning off DNSSEC is the only way the ISP has to implement the law's requirements? How many applications request DNSSEC related information and validate? The only way DNSSEC matters in this context is if you validate locally. My guess is that the number of folk who do this is so low as to not be of interest to the Quebec government. This may be an argument for folks to run their own validating resolvers, but I'm not sure how you'd do that on your iPhone, iPad, or SmartTV. Regards, -drc -------------- 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 Valdis.Kletnieks at vt.edu Fri Nov 13 22:35:58 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 13 Nov 2015 17:35:58 -0500 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <9692ECC6-34AD-49C0-B310-10B8EF8C112C@virtualized.org> References: <20151113052946.7102.qmail@ary.lan> <9692ECC6-34AD-49C0-B310-10B8EF8C112C@virtualized.org> Message-ID: <10781.1447454158@turing-police.cc.vt.edu> On Fri, 13 Nov 2015 14:22:15 -0800, David Conrad said: > This may be an argument for folks to run their own validating resolvers, but > I'm not sure how you'd do that on your iPhone, iPad, or SmartTV. "There's an app for that". :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From marka at isc.org Sat Nov 14 00:18:52 2015 From: marka at isc.org (Mark Andrews) Date: Sat, 14 Nov 2015 11:18:52 +1100 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: Your message of "Fri, 13 Nov 2015 14:22:15 -0800." <9692ECC6-34AD-49C0-B310-10B8EF8C112C@virtualized.org> References: <20151113052946.7102.qmail@ary.lan> <9692ECC6-34AD-49C0-B310-10B8EF8C112C@virtualized.org> Message-ID: <20151114001852.EB8423CA23EA@rock.dv.isc.org> In message <9692ECC6-34AD-49C0-B310-10B8EF8C112C at virtualized.org>, David Conrad writes: > > On Nov 13, 2015, at 10:24 AM, Mark Milhollan wrote: > > On Thu, 13 Nov 2015, John Levine wrote: > > > >> At this point very few client resolvers check DNSSEC, so something > >> that stripped off all the DNSSEC stuff and inserted lies where > >> required would "work" for most clients. At least until they realized > >> they couldn't get to PokerStars and switched their DNS to 8.8.8.8. > > > > Except that the ISP can intercept those queries and respond as it likes. > > Thank you. I was wondering if anyone would mention this. > > DNSSEC only protects the validator's cache. My assumption (which may be > wrong) is that for the vast majority of folks, that means the cache that > is run by the ISP. > > How many of the ISPs in Quebec enable DNSSEC? > > Even if they do, I doubt the government would care: I would presume it > would be up to the ISP to implement the law and respond back as the law > dictates. How many of the ISPs would continue to enable DNSSEC if the > cops show up at their door and turning off DNSSEC is the only way the ISP > has to implement the law's requirements? Why would the ISP's turn off DNSSEC? It doesn't prevent them sending back NXDOMAIN. The clients will validate or not. If they validate they will get a validation failure. If they don't them the NXDOMAIN will be accepted. > How many applications request DNSSEC related information and validate? > > The only way DNSSEC matters in this context is if you validate locally. > My guess is that the number of folk who do this is so low as to not be of > interest to the Quebec government. This may be an argument for folks to > run their own validating resolvers, but I'm not sure how you'd do that on > your iPhone, iPad, or SmartTV. Apple just adds a validator to their stub resolver and installs a root trust anchor. This really isn't conceptually different to how they manage CA's. > Regards, > -drc -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From drc at virtualized.org Sat Nov 14 00:49:44 2015 From: drc at virtualized.org (David Conrad) Date: Fri, 13 Nov 2015 16:49:44 -0800 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <20151114001852.EB8423CA23EA@rock.dv.isc.org> References: <20151113052946.7102.qmail@ary.lan> <9692ECC6-34AD-49C0-B310-10B8EF8C112C@virtualized.org> <20151114001852.EB8423CA23EA@rock.dv.isc.org> Message-ID: <5C1BE1BF-6EEB-4C70-B115-D1B13D7F4B0D@virtualized.org> Mark, > On Nov 13, 2015, at 4:18 PM, Mark Andrews wrote: >> How many of the ISPs would continue to enable DNSSEC if the >> cops show up at their door and turning off DNSSEC is the only way the ISP >> has to implement the law's requirements? > > Why would the ISP's turn off DNSSEC? It doesn't prevent them sending back > NXDOMAIN. The clients will validate or not. If they validate they will > get a validation failure. If they don't them the NXDOMAIN will be accepted. My point was that folks at ISPs tend to prefer not to be thrown in jail. > Apple just adds a validator to their stub resolver and installs a root > trust anchor. Love that plan. Let me know when you've convinced Apple to "just" add a validator to IOS (I'm assuming IOS doesn't currently have that capability). > This really isn't conceptually different to how they manage > CA's. My point was that the vast majority of those affected by this would likely not be in a position to install a validating resolver on their device. Regards, -drc -------------- 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 rdobbins at arbor.net Sat Nov 14 01:44:09 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 14 Nov 2015 08:44:09 +0700 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <20151113200123.4931.qmail@ary.lan> References: <20151113200123.4931.qmail@ary.lan> Message-ID: <16420E98-94C5-4BC1-A9D9-440022B21657@arbor.net> On 14 Nov 2015, at 3:01, John Levine wrote: > Civilians definitely use these. A very tiny percentage. The power of the default reigns supreme. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Sat Nov 14 01:45:53 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 14 Nov 2015 08:45:53 +0700 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <9692ECC6-34AD-49C0-B310-10B8EF8C112C@virtualized.org> References: <20151113052946.7102.qmail@ary.lan> <9692ECC6-34AD-49C0-B310-10B8EF8C112C@virtualized.org> Message-ID: <3F8A5390-C02D-43EA-BD88-E2A854BDDACD@arbor.net> On 14 Nov 2015, at 5:22, David Conrad wrote: > Thank you. I was wondering if anyone would mention this. +1. This is done in some countries which are heavy-handed with Internet censorship. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Sat Nov 14 01:47:01 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 14 Nov 2015 08:47:01 +0700 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <5C1BE1BF-6EEB-4C70-B115-D1B13D7F4B0D@virtualized.org> References: <20151113052946.7102.qmail@ary.lan> <9692ECC6-34AD-49C0-B310-10B8EF8C112C@virtualized.org> <20151114001852.EB8423CA23EA@rock.dv.isc.org> <5C1BE1BF-6EEB-4C70-B115-D1B13D7F4B0D@virtualized.org> Message-ID: On 14 Nov 2015, at 7:49, David Conrad wrote: > My point was that the vast majority of those affected by this would > likely not be in a position to install a validating resolver on their > device. Correct. Most folks on this list can and will do it if they deem it necessary; but most folks on this list are not representative of the global user base. ----------------------------------- Roland Dobbins From johnl at iecc.com Sat Nov 14 03:02:02 2015 From: johnl at iecc.com (John Levine) Date: 14 Nov 2015 03:02:02 -0000 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <16420E98-94C5-4BC1-A9D9-440022B21657@arbor.net> Message-ID: <20151114030202.5877.qmail@ary.lan> >> Civilians definitely use these. > >A very tiny percentage. The power of the default reigns supreme. People in New Zealand said differently. It's a small country, but I was impressed how everyone in the session (it was NetHui, not a bunch of geeks) took for granted that you'd use a VPN to get your video fix. Online gamblers can be a very dedicated group. See, for example, these blog posts and online ads about VPNs that circumvent blocks to get to online poker sites: http://securethoughts.com/3-best-vpns-online-poker/ https://www.reddit.com/r/poker/comments/1xu89o/using_a_vpn_to_play_real_money_poker/ http://www.onlinebettingsites.com/vpns-for-online-betting/ https://www.vpnaccounts.com/blog/internet-gambling-using-vpn/ http://calvinayre.com/2014/08/18/poker/using-a-vpn-to-play-online-poker-could-be-working-against-you/ https://www.cardschat.com/f10/new-york-players-a-vpn-220913/ http://www.billrini.com/2011/04/23/thinking-vpning-poker/ https://www.le-vpn.com/vpn-for-online-poker-and-gambling/ https://vpnuk.net/gambling.html R's, John From rdobbins at arbor.net Sat Nov 14 03:09:35 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 14 Nov 2015 10:09:35 +0700 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <20151114030202.5877.qmail@ary.lan> References: <20151114030202.5877.qmail@ary.lan> Message-ID: <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> On 14 Nov 2015, at 10:02, John Levine wrote: > People in New Zealand said differently. This is a corner-case, however. ----------------------------------- Roland Dobbins From owen at delong.com Sat Nov 14 03:22:39 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 13 Nov 2015 19:22:39 -0800 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> Message-ID: <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> > On Nov 13, 2015, at 19:09 , Roland Dobbins wrote: > > On 14 Nov 2015, at 10:02, John Levine wrote: > >> People in New Zealand said differently. > > This is a corner-case, however. Is it really a corner-case, or, is it the first representation of a group of ordinary netizens sufficiently frustrated by policy that they found a workaround? If it?s a corner-case, it?s unlikely to get replicated by a similar level of frustration among a different group of netizens. OTOH, if, as I suspect, it?s merely the first (or first known to us) example of such behavior, then it may be more of a predictive result than a corner case. Every trend starts somewhere. Today, gamblers in Quebec don?t need to work around government stupidity, they can just go gamble. If the government truly manages to implement the proposed stupidity, that might serve as enough motivation to duplicate the ?New Zealand Netflix Effect? in Quebec. Surely time will tell, but I would not be so quick to dismiss this as a potential workaround after watching how quickly TOR was adopted to move video around during the Arab Spring. Owen From rdobbins at arbor.net Sat Nov 14 03:27:07 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 14 Nov 2015 10:27:07 +0700 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> Message-ID: On 14 Nov 2015, at 10:22, Owen DeLong wrote: > Surely time will tell, but I would not be so quick to dismiss this as > a potential workaround after watching how quickly TOR was adopted to > move video around during the Arab Spring. By a tiny minority of people. Selection bias. Most people do not know what a 'VPN' is, or how to install one and get it working. The number of people who do may increase somewhat over time due to various restrictions they seek to overcome, but it will never become anything close to the norm unless it is a default. Go out onto the street and ask a selection of random passers-by if they know what a VPN is, if they know how to install one, if they've installed one. ----------------------------------- Roland Dobbins From owen at delong.com Sat Nov 14 04:32:10 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 13 Nov 2015 20:32:10 -0800 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> Message-ID: > On Nov 13, 2015, at 19:27 , Roland Dobbins wrote: > > On 14 Nov 2015, at 10:22, Owen DeLong wrote: > >> Surely time will tell, but I would not be so quick to dismiss this as a potential workaround after watching how quickly TOR was adopted to move video around during the Arab Spring. > > By a tiny minority of people. > > Selection bias. > > Most people do not know what a 'VPN' is, or how to install one and get it working. The number of people who do may increase somewhat over time due to various restrictions they seek to overcome, but it will never become anything close to the norm unless it is a default. 20 years ago, most people didn?t know what a URL or a Domain name was. 18 years ago, they were on every billboard. People learn stuff as they need to. Today, the vast majority of people don?t need to know what a VPN is. New Zealand has become a notable exception to this situation as a result of their desire to watch US Netflix programming. I see no reason to believe it would be > Go out onto the street and ask a selection of random passers-by if they know what a VPN is, if they know how to install one, if they've installed one. Not a valid test? Go out onto the street and ask a random number of people over 30 if they know what a URL is and how to enter one into a browser. Now, ask if they learned that more or less than 20 years ago. In 1930, nobody knew what a television was, let alone a television remote control. Today, the average 6 year old can operate a DirectTV satellite system with a relatively high degree of facility. What the average person knows changes over time. Assuming that it does not strikes me as either (1) ignoring history or (2) underestimating the general public even more than I do, which is saying something. Owen From mpalmer at hezmatt.org Sat Nov 14 04:39:11 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sat, 14 Nov 2015 15:39:11 +1100 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <20151113095428.GB29094@lboro.ac.uk> References: <56455885.8090409@vaxination.ca> <20151113040729.59FA93C9BC9A@rock.dv.isc.org> <5645AD08.8070104@vaxination.ca> <20151113095428.GB29094@lboro.ac.uk> Message-ID: <20151114043911.GZ4973@hezmatt.org> On Fri, Nov 13, 2015 at 09:54:28AM +0000, A.L.M.Buxey at lboro.ac.uk wrote: > > BTW, the proposed law, being done by lawyers, will have the list of > > you say law.... but this idea of blocking all competitors to the states > lotto sounds very unlawful and anti-competitive - yes, I can > understand states or countries blocking ALL gambling , thats a simple > 'we dont allow it here' , but to say 'yes, you can access just ours' > well, in EU I dont think that would ever fly. Sweden's still part of the EU, isn't it? ("Systembolaget", if you need a search term). - Matt From mpalmer at hezmatt.org Sat Nov 14 04:46:14 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sat, 14 Nov 2015 15:46:14 +1100 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <87y4e2mdl3.fsf@nemi.mork.no> References: <56455885.8090409@vaxination.ca> <87y4e2mdl3.fsf@nemi.mork.no> Message-ID: <20151114044614.GA4973@hezmatt.org> On Fri, Nov 13, 2015 at 10:51:52AM +0100, Bj?rn Mork wrote: > So what do we do? We currently point the blocked domains to addresses of > a web server with a short explanation. But what if the domains were > signed? We could let validating servers return SERVFAIL. But I'd > really prefer avoiding that for the simple reason that there is no way > to distinguish that SERVFAIL from one caused by e.g. a domain owner > configuration error. Perhaps we need to expand RCODE to be the full octet, and indicate "blocked for legal reasons" with RCODE value 25. - Matt From rdobbins at arbor.net Sat Nov 14 05:28:23 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 14 Nov 2015 12:28:23 +0700 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> Message-ID: <5507E655-B415-483B-AAAE-C14648E4C387@arbor.net> On 14 Nov 2015, at 11:32, Owen DeLong wrote: > Go out onto the street and ask a random number of people over 30 if > they know what a URL is and how to enter one into a browser. They don't know what URIs are, nor do they enter them into browsers. They type words into a search engine and then click on the resulting links. [I was shocked when I realized this is how non-specialists access Web sites, about 15 years or so ago.] > Today, the average 6 year old can operate a DirectTV satellite system > with a relatively high degree of facility. And has no idea how it actually works, and can't do anything with it beyond the obvious. > What the average person knows changes over time. Yes, but not in the way you're thinking. If anything, specialized technical knowledge tends to decrease over time, as technology goes from being used by a relatively few self-selected enthusiasts to becoming more mainstream and accessible to the masses. Auto mechanics is one example from the physical world. Cooking is another. Handwriting is yet another. > Assuming that it does not strikes me as either (1) ignoring history See above. > or (2) underestimating the general public even more than I do, which > is saying something. Among the population of Internet users, the knowledge of how the Internet actually works has decreased tremendously in the last 20 years, as that population has expanded to include non-specialists - e.g., the majority. Most computer users have no idea how computers actually work. They certainly don't know what a VPN is, or how (or why) to set one up. This state of affairs will continue until VPN technology becomes subsumed into applications and is enabled as a default, if it ever does. ----------------------------------- Roland Dobbins From marka at isc.org Sat Nov 14 06:32:41 2015 From: marka at isc.org (Mark Andrews) Date: Sat, 14 Nov 2015 17:32:41 +1100 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: Your message of "Sat, 14 Nov 2015 15:46:14 +1100." <20151114044614.GA4973@hezmatt.org> References: <56455885.8090409@vaxination.ca> <87y4e2mdl3.fsf@nemi.mork.no> <20151114044614.GA4973@hezmatt.org> Message-ID: <20151114063241.E547F3CA405A@rock.dv.isc.org> In message <20151114044614.GA4973 at hezmatt.org>, Matt Palmer writes: > On Fri, Nov 13, 2015 at 10:51:52AM +0100, Bj?rn Mork wrote: > > So what do we do? We currently point the blocked domains to addresses of > > a web server with a short explanation. But what if the domains were > > signed? We could let validating servers return SERVFAIL. But I'd > > really prefer avoiding that for the simple reason that there is no way > > to distinguish that SERVFAIL from one caused by e.g. a domain owner > > configuration error. > > Perhaps we need to expand RCODE to be the full octet, and indicate "blocked > for legal reasons" with RCODE value 25. Rcode's were expanded to 12 bits back in 1999. See RFC 2671. > - Matt > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jfmezei_nanog at vaxination.ca Sat Nov 14 06:36:06 2015 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sat, 14 Nov 2015 01:36:06 -0500 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <20151113215937.GA18454@sources.org> References: <56455885.8090409@vaxination.ca> <20151113040729.59FA93C9BC9A@rock.dv.isc.org> <5645AD08.8070104@vaxination.ca> <20151113215937.GA18454@sources.org> Message-ID: <5646D656.2020905@vaxination.ca> On 2015-11-13 16:59, Stephane Bortzmeyer wrote: > On Fri, Nov 13, 2015 at 04:27:36AM -0500, > Jean-Francois Mezei wrote > a message of 34 lines which said: > >> I'll have to research how other countries tried to implement similar >> schemes > > https://www.afnic.fr/en/about-afnic/news/general-news/6584/show/the-afnic-scientific-council-shares-its-report-on-dns-based-internet-filtering.html > Thanks to Stephane and all the others. The afnic report will be especially usefull because it is in french and thus better understood by Qu?bec politicians. And thank to all those who filled in the gaps for DNSSEC for me. Unfortunately, an ISP can still pretend to be authoritative for the blocked domains and respond with fake unsigned response. The end client that doesn't validate will be gullible and access the redirect side. Those who validate will get SERVFAIL or NXDOMAIN and the end result is that the blocked web site remains blocked. With regards to VPNs: while they may not be very well known in the USA, they are outside the USA where many people need VPNs to access foreign content that is geoblocked in their home country. New Zealand is not alone, the practice is also common in Canada (as well as using pretend DNS servers in USA There are a number of commercial services that provide DNS "faking" that make your canadian requests appear to come from a USA location, so Netflix assumes you are in USA location when resolving whether content is available or not. (ex: https://www.unblock-us.com ) In the case of gambling, anyone with such an addiction will likely feel deprived after a couple of days being blocked and will call on their best friend Mr Google who will quickly provide ways to get around it such as ignoring your own ISP's DNS server and using one outside of Qu?bec. Or using a VPN. This may have interesting implications for Google's 8.8.8.8 which, if I am not mistaken, peers at QIX, the Montr?al exchange. Would they be bound by the law (they are not an ISP). Google could simply widthdraw from the QIX echange at which point the Qu?bec government would have 0 jurisdiction. ISPs that serve both Ontario and Qu?bec thorugh Bell's DSL infrastructure will have fun. PPPoE connections arrive to a common connection point via L2TP tunnels, so the ISP would have to determine the person's province based PPPoE login credentials and assign different DNS servers (blocked for QC, unblocked for ON). Loto Qu?bec is supposed to be testing for compliance, and I am not sure how they will do that short of having a subscription to every ISP that sells services in Qu?bec. (Maybe they think they only have to test 3 ISPs, (telcos and cablecos) and don't realise they have over 100 ISPs to test for compliance). And when an ISP in Val D'Or has its DNS set to recurse only for requests that come from its intranet, Loto Qu?bec won't be able to test from its cushy Montr?al offices with a simple "set server" command. Ahh... the trouble clueless politicians can cause. From royce at techsolvency.com Sat Nov 14 06:38:39 2015 From: royce at techsolvency.com (Royce Williams) Date: Fri, 13 Nov 2015 21:38:39 -0900 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <5507E655-B415-483B-AAAE-C14648E4C387@arbor.net> References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> <5507E655-B415-483B-AAAE-C14648E4C387@arbor.net> Message-ID: On Fri, Nov 13, 2015 at 8:28 PM, Roland Dobbins wrote: > On 14 Nov 2015, at 11:32, Owen DeLong wrote: > > Go out onto the street and ask a random number of people over 30 if they >> know what a URL is and how to enter one into a browser. >> > > They don't know what URIs are, nor do they enter them into browsers. They > type words into a search engine and then click on the resulting links. > The don't know what a VPN is ... but when they can't watch the Olympics on the Internet from their own country, a buddy tells them about an "app" that "makes you look like you're coming from a different country." Now they can watch the Olympics. I saw this "one weird trick" spread like wildfire through my non-technical acquaintances. They don't have to know what a VPN is in order to to use it -- and to pass it on to their friends. Royce From sakamura at gmail.com Sat Nov 14 07:43:54 2015 From: sakamura at gmail.com (Ishmael Rufus) Date: Sat, 14 Nov 2015 07:43:54 +0000 Subject: Colo space at Cermak In-Reply-To: References: <58257764.1089.1447381997161.JavaMail.mhammett@ThunderFuck> Message-ID: The company who has the worlds most played online multiplayer game moved their servers to Chicago back in late August. Maybe that affected prices? On Fri, Nov 13, 2015, 12:45 PM Greg Sowell wrote: > I would guess it has to do with competing with your landlord now. I know > it's starting to happen more and more. > > On Thu, Nov 12, 2015 at 8:32 PM, Mike Hammett wrote: > > > Has something happened the past couple months to cause a quick shortage > of > > space at Cermak? I had an offer sent a few months ago (when I didn't need > > it) where a cab and five cross connects were cheaper than what five cross > > connects normally are, much less the cabinet value as well. Around that > > time I think cabinets were going for $700 or so for basic > primary\redundant > > 20A. Now the cabinet is going for $1,800. It went from being the cheapest > > I've seen at Cermak to the most I've seen at Cermak in a matter of a few > > months. Two people with space in that building are citing an uptick in > > demand. Really? That much of a demand increase with hundreds of thousands > > of square feet coming online in the Chicago metro? > > > > Can anyone corroborate that story or are they just making stuff up hoping > > I agree to inflated cabinet prices? > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > > > > > Midwest Internet Exchange > > http://www.midwest-ix.com > > > > > > > > > > > -- > > GregSowell.com > TheBrothersWISP.com > From rdobbins at arbor.net Sat Nov 14 08:19:09 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 14 Nov 2015 15:19:09 +0700 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> <5507E655-B415-483B-AAAE-C14648E4C387@arbor.net> Message-ID: <930905C5-059D-4465-A89E-0C84779DBC33@arbor.net> On 14 Nov 2015, at 13:38, Royce Williams wrote: > They don't have to know what a VPN is in order to to use it -- and to pass > it on to their friends. That's still a very small proportion of the user base. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Sat Nov 14 08:21:58 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 14 Nov 2015 15:21:58 +0700 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <5646D656.2020905@vaxination.ca> References: <56455885.8090409@vaxination.ca> <20151113040729.59FA93C9BC9A@rock.dv.isc.org> <5645AD08.8070104@vaxination.ca> <20151113215937.GA18454@sources.org> <5646D656.2020905@vaxination.ca> Message-ID: On 14 Nov 2015, at 13:36, Jean-Francois Mezei wrote: > With regards to VPNs: while they may not be very well known in the > USA, they are outside the USA where many people need VPNs to access > foreign content that is geoblocked in their home country. I do not live in the United States; I live outside the United States, where many expats and others want to access content from their home countries that is 'geoblocked'. The percentage of the Internet user population who use VPNs is tiny. It is growing a bit, but it isn't even a sizable minority. ----------------------------------- Roland Dobbins From owen at delong.com Sat Nov 14 09:05:23 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 14 Nov 2015 01:05:23 -0800 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <5507E655-B415-483B-AAAE-C14648E4C387@arbor.net> References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> <5507E655-B415-483B-AAAE-C14648E4C387@arbor.net> Message-ID: <26D0C2D4-99B2-4462-8E79-B195EEEE8171@delong.com> > On Nov 13, 2015, at 21:28 , Roland Dobbins wrote: > > On 14 Nov 2015, at 11:32, Owen DeLong wrote: > >> Go out onto the street and ask a random number of people over 30 if they know what a URL is and how to enter one into a browser. > > They don't know what URIs are, nor do they enter them into browsers. They type words into a search engine and then click on the resulting links. If that were true, billboards wouldn?t look like this: http://worthwhileadvertising.com/wp-content/uploads/2010/11/Sandstone-billboard.jpg (Note randomly chosen billboard image from google image search, not at all tech related and not in silicon valley.) > > [I was shocked when I realized this is how non-specialists access Web sites, about 15 years or so ago.] I?m not surprised? It?s how I access about 30% of the websites I visit. Another 50% or so come from bookmarks/browser history completion. The remaining 20% are URLs I type. > >> Today, the average 6 year old can operate a DirectTV satellite system with a relatively high degree of facility. > > And has no idea how it actually works, and can't do anything with it beyond the obvious. Sure, but that?s also true of lots of VPNs that people use every day too. The marketing people at Akamai use VPNs routinely. IT has it boiled down to Clicking an ICON in the menu bar and selecting ?Akamai->Connect?. Lots of VPN services out there like the ones mentioned earlier in the thread have made it nearly as simple to install and operate a VPN. > >> What the average person knows changes over time. > > Yes, but not in the way you're thinking. If anything, specialized technical knowledge tends to decrease over time, as technology goes from being used by a relatively few self-selected enthusiasts to becoming more mainstream and accessible to the masses. > > Auto mechanics is one example from the physical world. Cooking is another. Handwriting is yet another. Sure, but it used to be that setting up an internet connection on the average computer was a complex technical process that only a few could handle. Today, we take having an internet connection on a system for granted. Why couldn?t things get to a point where we take using VPNs for granted? It?s just a combination of software development and user acceptance. I?m not saying everyone is going to learn how to configure an IPSEC SA set with tunnels on a Juniper. I?m saying that people will learn to use point-click-VPN software which already exists for the most part. > >> Assuming that it does not strikes me as either (1) ignoring history > > See above. Most people know how to operate a microwave while few are gourmet chefs. I would argue that VPN technology is evolving (has evolved) to a point where it can be more like a microwave. > >> or (2) underestimating the general public even more than I do, which is saying something. > > Among the population of Internet users, the knowledge of how the Internet actually works has decreased tremendously in the last 20 years, as that population has expanded to include non-specialists - e.g., the majority. Sure? Not particularly relevant to the discussion at hand, however. > Most computer users have no idea how computers actually work. They certainly don't know what a VPN is, or how (or why) to set one up. This state of affairs will continue until VPN technology becomes subsumed into applications and is enabled as a default, if it ever does. Or until users discover that they can achieve something they want by installing a VPN application and using that, such as happened in New Zealand. Will the understand how said VPN application works or why it makes what they want possible? No. Nor will they care. But they will care that it solves the problem of reaching their gambling sites despite the government interference or that they can use it to get to the Netflix version they want rather than no service in their locality or? Many ways to skin a cat. Owen From owen at delong.com Sat Nov 14 09:27:39 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 14 Nov 2015 01:27:39 -0800 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: References: <56455885.8090409@vaxination.ca> <20151113040729.59FA93C9BC9A@rock.dv.isc.org> <5645AD08.8070104@vaxination.ca> <20151113215937.GA18454@sources.org> <5646D656.2020905@vaxination.ca> Message-ID: <0D020E81-7F3A-4BE6-8A1F-9D477B79EA32@delong.com> > On Nov 14, 2015, at 00:21 , Roland Dobbins wrote: > > On 14 Nov 2015, at 13:36, Jean-Francois Mezei wrote: > >> With regards to VPNs: while they may not be very well known in the USA, they are outside the USA where many people need VPNs to access foreign content that is geoblocked in their home country. > > I do not live in the United States; I live outside the United States, where many expats and others want to access content from their home countries that is 'geoblocked'. > > The percentage of the Internet user population who use VPNs is tiny. It is growing a bit, but it isn't even a sizable minority. Today. Why on earth do you assume that this will not continue to expand and/or accelerate its rate of expansion as word spreads that it is possible? There was a time when on-line download or streaming was dwarfed by DVDs and Blu-Ray sales. There was a time when DVD/Blu-Ray/other digital formats didn?t represent even 1% of the market vs. VHS. This is a typical adoption rate issue. If people want a functionality that is not currently available to them, they will adopt and adapt technology to meet that desire over time. The adapt part is already mostly done with VPNs as has been pointed out. There are now GeoBlock Bypass services readily available and easily installable. The next step will be growth in adoption. We?ve already seen this occur in NZ. Likely it will spread fairly quickly to other geographies subject to geoblocking. It is unlikely to spread rapidly in the US because the US suffers from very little geoblocking or censorship in general. Likely the first major market where it will see very rapid adoption will be someplace like China where it can be used to circumvent a wide variety of government network restrictions. However, if Quebec and/or NY manage to block gambling as they are currently attempting to do, it?s very likely that such services will also catch on quickly in those localities. Owen From rdobbins at arbor.net Sat Nov 14 11:11:37 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 14 Nov 2015 18:11:37 +0700 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <26D0C2D4-99B2-4462-8E79-B195EEEE8171@delong.com> References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> <5507E655-B415-483B-AAAE-C14648E4C387@arbor.net> <26D0C2D4-99B2-4462-8E79-B195EEEE8171@delong.com> Message-ID: On 14 Nov 2015, at 16:05, Owen DeLong wrote: > Lots of VPN services out there like the ones mentioned earlier in the > thread have made it nearly as simple to install and operate a VPN. Until the setup and functionality are automagic, we're not going to see broad use of VPNs by non-specialists. VPN functionality is built into pretty much every mainstream (and many non-mainstream) OS out there, including mobile devices. But it isn't something that's simple; users have to at a minimum install and accept a VPN profile, which means they have to go looking for a service in the first place. I'm wondering if perhaps major OS vendors/developers may start offering/OEMing VPN services, or at least distributing profiles in the same way as browser vendors/developers distribute CA certs? ----------------------------------- Roland Dobbins From owen at delong.com Sat Nov 14 12:07:51 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 14 Nov 2015 04:07:51 -0800 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> <5507E655-B415-483B-AAAE-C14648E4C387@arbor.net> <26D0C2D4-99B2-4462-8E79-B195EEEE8171@delong.com> Message-ID: <6796CDAC-7C5E-4A79-A99E-8E503D033BA2@delong.com> > On Nov 14, 2015, at 03:11 , Roland Dobbins wrote: > > On 14 Nov 2015, at 16:05, Owen DeLong wrote: > >> Lots of VPN services out there like the ones mentioned earlier in the thread have made it nearly as simple to install and operate a VPN. > > Until the setup and functionality are automagic, we're not going to see broad use of VPNs by non-specialists. The point you seem to be missing is that your ?until?? is already met. I know of at least one ISP that is providing CPE with VPN pre-configured and built in. I know of several other software/service solutions that are literally download-launch-subscribe. (download client software, launch installer, supply payment information for subscription). > VPN functionality is built into pretty much every mainstream (and many non-mainstream) OS out there, including mobile devices. But it isn't something that's simple; users have to at a minimum install and accept a VPN profile, which means they have to go looking for a service in the first place. You?re not looking at the right VPN software. The built-in stuff is crap that is years behind the current state of the art. > I'm wondering if perhaps major OS vendors/developers may start offering/OEMing VPN services, or at least distributing profiles in the same way as browser vendors/developers distribute CA certs? More likely this is going to be iterations of what is already being more widely accepted. Downloadable pre-configured client software that works with a particular VPN service. Point-click-subscribe model seems to receive fairly wide adoption among people sufficiently interested in bypassing {insert network damage here} to pay a monthly fee for a service that will do it. I think the going rate is something like $5/month for US VPNs last time I looked. Owen From rdobbins at arbor.net Sat Nov 14 12:29:10 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 14 Nov 2015 19:29:10 +0700 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <0D020E81-7F3A-4BE6-8A1F-9D477B79EA32@delong.com> References: <56455885.8090409@vaxination.ca> <20151113040729.59FA93C9BC9A@rock.dv.isc.org> <5645AD08.8070104@vaxination.ca> <20151113215937.GA18454@sources.org> <5646D656.2020905@vaxination.ca> <0D020E81-7F3A-4BE6-8A1F-9D477B79EA32@delong.com> Message-ID: On 14 Nov 2015, at 16:27, Owen DeLong wrote: > Today. Yes, today, and tomorrow, and next week, and next month, and next year, etc. > Why on earth do you assume that this will not continue to expand > and/or accelerate its rate of expansion as word spreads that it is > possible? Because it isn't a simple default. If it ever becomes a simple default, we'll start to see greater adoption. And probably not in the form of 'tunneling-everything' VPNs, but 'application VPNs' which automagically utilize SSL/TLS ----------------------------------- Roland Dobbins From rdobbins at arbor.net Sat Nov 14 12:34:20 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 14 Nov 2015 19:34:20 +0700 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <6796CDAC-7C5E-4A79-A99E-8E503D033BA2@delong.com> References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> <5507E655-B415-483B-AAAE-C14648E4C387@arbor.net> <26D0C2D4-99B2-4462-8E79-B195EEEE8171@delong.com> <6796CDAC-7C5E-4A79-A99E-8E503D033BA2@delong.com> Message-ID: On 14 Nov 2015, at 19:07, Owen DeLong wrote: > The point you seem to be missing is that your ?until?? is > already met. Not AFAICT. It isn't a default in the OS and on the window manager/home screen. > I know of at least one ISP that is providing CPE with VPN > pre-configured and built in. That makes one. > I know of several other software/service solutions that are literally > download-launch-subscribe. (download client software, launch > installer, supply payment information for subscription). The 'download' part is the main barrier to entry. > You?re not looking at the right VPN software. I look at VPN software all the time, from many providers. > The built-in stuff is crap that is years behind the current state of > the art. My point is that it's in the OS. > More likely this is going to be iterations of what is already being > more widely accepted. Downloadable pre-configured client software that > works with a particular VPN service. Again, downloading is a barrier to entry. Don't you remember the browser wars and the Microsoft anti-trust case? > Point-click-subscribe model seems to receive fairly wide adoption > among people sufficiently interested in bypassing {insert network > damage here} to pay a monthly fee for a service that will do it. 'Sufficiently interested' is a limiting factor. 'Sufficiently interested' to learn that such a thing is possible, and to figure out how to go about doing it. Of course, the other concern is that governments which don't already interfere with VPNs will outlaw VPNs in the name of 'national security'. Answering my own question, the OS/device vendors won't get into the VPN business due to this issue. ----------------------------------- Roland Dobbins From mr.jonas.bjork at me.com Sat Nov 14 12:48:14 2015 From: mr.jonas.bjork at me.com (Jonas Bjork) Date: Sat, 14 Nov 2015 13:48:14 +0100 Subject: EoMPLS vlan rewrite between brands; possibly new bug in Cisco IOS 15 Message-ID: Hi, I am using a couple of AToM/EoMPLS tunnels in order to carry customer voice and data traffic across our IP/MPLS core, and it is currently working just fine. The first side consists of a Cisco 7600 router (rsp) and the other one is an HP A5500-HI routing switch with full LER/E-LSR capability. At the HP site, the tunnels are facing the access ports towards our premium end-customers; and on the Cisco PE I terminate the tunnels on one of the 2x10GE portchannel backbone links. There is vlan X on the HP side and vlan Y on the Cisco side - vlan rewrite is working perfectly - as long as I use IOS 12. After upgrading the Cisco router software to IOS 15 the tunnels won't come up. sh mpls l2 vc Y d says: ... Last error: Imposition VLAN rewrite capability mismatch with peer ... I use almost exactly the same Cisco configuration before and after the upgrade (only minor changes and nothing related to this) and I havn't touched the HP. Apparently they don't talk the same L2PW language. I wonder though, why now? We use service instances on the HP switchport as endpoint, we initiate the targetted LDP session in addition to the pseudowire handshake from a sub interface MPLS crossconnect. There is no MTU mismatch; not here - not anywhere. Anyone heard of this issue or experienced it? Best regards, Jonas Bj?rk SNE, Europe/Sweden (hope you guys will help me anyway:) From mike-nanog at tiedyenetworks.com Sat Nov 14 15:56:44 2015 From: mike-nanog at tiedyenetworks.com (Mike) Date: Sat, 14 Nov 2015 07:56:44 -0800 Subject: comcast metro-e questions Message-ID: <564759BC.1060708@tiedyenetworks.com> Hi, Anyone here using comcast metro-e? I'd like to hear the good, bad and the ugly. I have a call in to sales but it being the weekend I won't be expecting a response, but I'm also wondering off the top of my head on general ballpark pricing for gigE? Thanks. Mike- From royce at techsolvency.com Sat Nov 14 16:39:35 2015 From: royce at techsolvency.com (Royce Williams) Date: Sat, 14 Nov 2015 07:39:35 -0900 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> <5507E655-B415-483B-AAAE-C14648E4C387@arbor.net> <26D0C2D4-99B2-4462-8E79-B195EEEE8171@delong.com> <6796CDAC-7C5E-4A79-A99E-8E503D033BA2@delong.com> Message-ID: On Sat, Nov 14, 2015 at 3:34 AM, Roland Dobbins wrote: >> >> More likely this is going to be iterations of what is already being more widely accepted. Downloadable pre-configured client software that works with a particular VPN service. > > > Again, downloading is a barrier to entry. Don't you remember the browser wars and the Microsoft anti-trust case? That was before the rise of the app. Downloading is now much more common than during the age of the browser wars. As of October 2014, 64% of American adults owned a smartphone [1]. Phones don't usually come with Candy Crush, but somehow, 93 *million* people played it daily at one point. They many not understand that when they installed the app, they were "downloading" it. But the end result is the same. Downloading is now a way of life -- and there are easily downloaded VPN apps. You don't have to know what a VPN is in order to use one. Anecdote != data, but during the 2014 Olympics, Googling for "how to watch the Olympics on the Internet" led many people I know to install one, without asking me for advice like they usually do. :) It sounds like we're arguing about the definition of the word "most". Your thesis appears to be that most people won't use a VPN -- and you're probably right. But what everyone else is saying is that the value of "most" is likely to shrink rapidly. And it may only take a secondary use case to reach critical mass. People I know who use WhatsApp seem to have started using it to avoid per-text charges, not to get end-to-end encrypted messaging. But now, even if Facebook's estimate [2] of 450 million WhatsApp users is 90% inflated, there are 45 million people using encrypted texting, which I would not have predicted. Most of those users probably don't know what "encryption" is. But they're using it. Royce 1. http://www.pewinternet.org/fact-sheets/mobile-technology-fact-sheet/ 2. http://www.forbes.com/sites/georgeanders/2014/02/19/facebook-justifies-19-billion-by-awe-at-whatsapp-growth/ From josh at kyneticwifi.com Sat Nov 14 16:58:29 2015 From: josh at kyneticwifi.com (Josh Reynolds) Date: Sat, 14 Nov 2015 10:58:29 -0600 Subject: Colo space at Cermak In-Reply-To: References: <58257764.1089.1447381997161.JavaMail.mhammett@ThunderFuck> Message-ID: That's interesting news, how did you hear about that? On Nov 14, 2015 1:46 AM, "Ishmael Rufus" wrote: > The company who has the worlds most played online multiplayer game moved > their servers to Chicago back in late August. Maybe that affected prices? > > On Fri, Nov 13, 2015, 12:45 PM Greg Sowell wrote: > > > I would guess it has to do with competing with your landlord now. I know > > it's starting to happen more and more. > > > > On Thu, Nov 12, 2015 at 8:32 PM, Mike Hammett wrote: > > > > > Has something happened the past couple months to cause a quick shortage > > of > > > space at Cermak? I had an offer sent a few months ago (when I didn't > need > > > it) where a cab and five cross connects were cheaper than what five > cross > > > connects normally are, much less the cabinet value as well. Around that > > > time I think cabinets were going for $700 or so for basic > > primary\redundant > > > 20A. Now the cabinet is going for $1,800. It went from being the > cheapest > > > I've seen at Cermak to the most I've seen at Cermak in a matter of a > few > > > months. Two people with space in that building are citing an uptick in > > > demand. Really? That much of a demand increase with hundreds of > thousands > > > of square feet coming online in the Chicago metro? > > > > > > Can anyone corroborate that story or are they just making stuff up > hoping > > > I agree to inflated cabinet prices? > > > > > > > > > > > > > > > ----- > > > Mike Hammett > > > Intelligent Computing Solutions > > > http://www.ics-il.com > > > > > > > > > > > > Midwest Internet Exchange > > > http://www.midwest-ix.com > > > > > > > > > > > > > > > > > > -- > > > > GregSowell.com > > TheBrothersWISP.com > > > From bortzmeyer at nic.fr Sat Nov 14 17:26:40 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sat, 14 Nov 2015 18:26:40 +0100 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <5646D656.2020905@vaxination.ca> References: <56455885.8090409@vaxination.ca> <20151113040729.59FA93C9BC9A@rock.dv.isc.org> <5645AD08.8070104@vaxination.ca> <20151113215937.GA18454@sources.org> <5646D656.2020905@vaxination.ca> Message-ID: <20151114172640.GA20668@sources.org> On Sat, Nov 14, 2015 at 01:36:06AM -0500, Jean-Francois Mezei wrote a message of 71 lines which said: > Loto Qu?bec is supposed to be testing for compliance, and I am not > sure how they will do that short of having a subscription to every > ISP that sells services in Qu?bec. They will simply use RIPE Atlas probes, as we all do to test our networks from the outside. Here, Bulgaria, where the mandatory blocking of gambling Web sites is far from perfect (the right IP address is 5.226.176.16): % python resolve-name.py --requested=500 --country=BG www.bet365.com Measurement #2930308 for www.bet365.com/A uses 94 probes [] : 1 occurrences [193.24.240.122] : 1 occurrences [84.54.148.18] : 1 occurrences [212.73.128.166] : 1 occurrences [212.39.93.34] : 3 occurrences [ERROR: SERVFAIL] : 1 occurrences [5.226.176.16] : 75 occurrences [127.0.0.1] : 4 occurrences Test done at 2015-11-14T17:14:20Z A few lying DNS resolvers but not much. > (Maybe they think they only have to test 3 ISPs, (telcos and > cablecos) and don't realise they have over 100 ISPs to test for > compliance). My experience with these sort of organisations is that they don't care about 100?% compliance. They're only interested in "good enough" (the three largest ISPs...) From baldur.norddahl at gmail.com Sat Nov 14 18:32:32 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 14 Nov 2015 19:32:32 +0100 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <20151114172640.GA20668@sources.org> References: <56455885.8090409@vaxination.ca> <20151113040729.59FA93C9BC9A@rock.dv.isc.org> <5645AD08.8070104@vaxination.ca> <20151113215937.GA18454@sources.org> <5646D656.2020905@vaxination.ca> <20151114172640.GA20668@sources.org> Message-ID: So when will we see CPE routers with built-in secure resolver and VPN client? Log in to 192.168.1.1 and select your country of the day from a drop down. Regards Baldur From nsuan at nonexiste.net Sat Nov 14 18:44:18 2015 From: nsuan at nonexiste.net (Nicholas Suan) Date: Sat, 14 Nov 2015 13:44:18 -0500 Subject: Colo space at Cermak In-Reply-To: References: <58257764.1089.1447381997161.JavaMail.mhammett@ThunderFuck> Message-ID: They made an announcement about it a while back: http://boards.na.leagueoflegends.com/en/c/help-support/2uTrAyy8-na-server-roadmap-update-chicago-server-move-complete On Sat, Nov 14, 2015 at 11:58 AM, Josh Reynolds wrote: > That's interesting news, how did you hear about that? > On Nov 14, 2015 1:46 AM, "Ishmael Rufus" wrote: > >> The company who has the worlds most played online multiplayer game moved >> their servers to Chicago back in late August. Maybe that affected prices? >> >> On Fri, Nov 13, 2015, 12:45 PM Greg Sowell wrote: >> >> > I would guess it has to do with competing with your landlord now. I know >> > it's starting to happen more and more. >> > >> > On Thu, Nov 12, 2015 at 8:32 PM, Mike Hammett wrote: >> > >> > > Has something happened the past couple months to cause a quick shortage >> > of >> > > space at Cermak? I had an offer sent a few months ago (when I didn't >> need >> > > it) where a cab and five cross connects were cheaper than what five >> cross >> > > connects normally are, much less the cabinet value as well. Around that >> > > time I think cabinets were going for $700 or so for basic >> > primary\redundant >> > > 20A. Now the cabinet is going for $1,800. It went from being the >> cheapest >> > > I've seen at Cermak to the most I've seen at Cermak in a matter of a >> few >> > > months. Two people with space in that building are citing an uptick in >> > > demand. Really? That much of a demand increase with hundreds of >> thousands >> > > of square feet coming online in the Chicago metro? >> > > >> > > Can anyone corroborate that story or are they just making stuff up >> hoping >> > > I agree to inflated cabinet prices? >> > > >> > > >> > > >> > > >> > > ----- >> > > Mike Hammett >> > > Intelligent Computing Solutions >> > > http://www.ics-il.com >> > > >> > > >> > > >> > > Midwest Internet Exchange >> > > http://www.midwest-ix.com >> > > >> > > >> > > >> > > >> > >> > >> > -- >> > >> > GregSowell.com >> > TheBrothersWISP.com >> > >> From niels=nanog at bakker.net Sat Nov 14 19:08:45 2015 From: niels=nanog at bakker.net (Niels Bakker) Date: Sat, 14 Nov 2015 20:08:45 +0100 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> Message-ID: <20151114190845.GH3097@excession.tpb.net> * rdobbins at arbor.net (Roland Dobbins) [Sat 14 Nov 2015, 04:13 CET]: >On 14 Nov 2015, at 10:02, John Levine wrote: > >> People in New Zealand said differently. > >This is a corner-case, however. We can continue citing corner cases, like the % of people in Turkey who use Google DNS since their government started censoring web services like Twitter. When will there be enough 'corner cases' to convince you it's business as usual? -- Niels. From johnl at iecc.com Sat Nov 14 19:25:37 2015 From: johnl at iecc.com (John Levine) Date: 14 Nov 2015 19:25:37 -0000 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: Message-ID: <20151114192537.9440.qmail@ary.lan> >Until the setup and functionality are automagic, we're not going to see >broad use of VPNs by non-specialists. I'm getting the impression you haven't yet gotten around to looking at VPN applications intended for non-specialists. Here's a good one to start with: https://www.goldenfrog.com/vyprvpn They have point'n'click apps for all the usual platforms. The free level of service provides 500MB/mo, plenty for gambling. If you haven't heard of Golden Frog, it is better known as Giganews. R's, John From johnl at iecc.com Sat Nov 14 19:27:52 2015 From: johnl at iecc.com (John Levine) Date: 14 Nov 2015 19:27:52 -0000 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: Message-ID: <20151114192752.9461.qmail@ary.lan> In article you write: >So when will we see CPE routers with built-in secure resolver and VPN >client? Log in to 192.168.1.1 and select your country of the day from a >drop down. VyprVPN has a plug in for Tomato. R's, John From mpalmer at hezmatt.org Sat Nov 14 22:17:26 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sun, 15 Nov 2015 09:17:26 +1100 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <20151114063241.E547F3CA405A@rock.dv.isc.org> References: <56455885.8090409@vaxination.ca> <87y4e2mdl3.fsf@nemi.mork.no> <20151114044614.GA4973@hezmatt.org> <20151114063241.E547F3CA405A@rock.dv.isc.org> Message-ID: <20151114221726.GN4973@hezmatt.org> On Sat, Nov 14, 2015 at 05:32:41PM +1100, Mark Andrews wrote: > In message <20151114044614.GA4973 at hezmatt.org>, Matt Palmer writes: > > On Fri, Nov 13, 2015 at 10:51:52AM +0100, Bj?rn Mork wrote: > > > So what do we do? We currently point the blocked domains to addresses of > > > a web server with a short explanation. But what if the domains were > > > signed? We could let validating servers return SERVFAIL. But I'd > > > really prefer avoiding that for the simple reason that there is no way > > > to distinguish that SERVFAIL from one caused by e.g. a domain owner > > > configuration error. > > > > Perhaps we need to expand RCODE to be the full octet, and indicate "blocked > > for legal reasons" with RCODE value 25. > > Rcode's were expanded to 12 bits back in 1999. See RFC 2671. I didn't feel it was worth looking beyond RFC1035 for an off-the-cuff joke. - Matt From rdobbins at arbor.net Sat Nov 14 22:48:08 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 15 Nov 2015 05:48:08 +0700 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <20151114192537.9440.qmail@ary.lan> References: <20151114192537.9440.qmail@ary.lan> Message-ID: <339DE9D9-F459-48E3-8D27-94EB76C9044C@arbor.net> On 15 Nov 2015, at 2:25, John Levine wrote: > They have point'n'click apps for all the usual platforms. They are not defaults. I think that many people on this list don't understand that the vast majority of users around the world do not know what a VPN is, do not know why they might need one, and aren't especially adept at installing applications, even from 'apps stores'. ----------------------------------- Roland Dobbins From larrysheldon at cox.net Sat Nov 14 22:56:54 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Sat, 14 Nov 2015 16:56:54 -0600 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <339DE9D9-F459-48E3-8D27-94EB76C9044C@arbor.net> References: <20151114192537.9440.qmail@ary.lan> <339DE9D9-F459-48E3-8D27-94EB76C9044C@arbor.net> Message-ID: <5647BC36.5090105@cox.net> On 11/14/2015 16:48, Roland Dobbins wrote: > On 15 Nov 2015, at 2:25, John Levine wrote: > >> They have point'n'click apps for all the usual platforms. > > They are not defaults. > > I think that many people on this list don't understand that the vast > majority of users around the world do not know what a VPN is, do not > know why they might need one, and aren't especially adept at installing > applications, even from 'apps stores'. It would be interesting to see a credible, referred study of this. _I_ think the IT world continues to minimize and denigrate the abilities and interests of its customers at its own, great peril. -- sed quis custodiet ipsos custodes? (Juvenal) From larrysheldon at cox.net Sat Nov 14 23:01:45 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Sat, 14 Nov 2015 17:01:45 -0600 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <5647BC36.5090105@cox.net> References: <20151114192537.9440.qmail@ary.lan> <339DE9D9-F459-48E3-8D27-94EB76C9044C@arbor.net> <5647BC36.5090105@cox.net> Message-ID: <5647BD59.60804@cox.net> On 11/14/2015 16:56, Larry Sheldon wrote: > On 11/14/2015 16:48, Roland Dobbins wrote: >> On 15 Nov 2015, at 2:25, John Levine wrote: >> >>> They have point'n'click apps for all the usual platforms. >> >> They are not defaults. >> >> I think that many people on this list don't understand that the vast >> majority of users around the world do not know what a VPN is, do not >> know why they might need one, and aren't especially adept at installing >> applications, even from 'apps stores'. > > It would be interesting to see a credible, referred study of this. > > _I_ think the IT world continues to minimize and denigrate the abilities > and interests of its customers at its own, great peril. Even if the mythical "where is the 'any' key" calls happen at a rate, globally, of one a minute, there are still tens of thousands of customers unheard-from who are devising ways to get their work done in spite of your best attempts to prevent it. -- sed quis custodiet ipsos custodes? (Juvenal) From rdobbins at arbor.net Sat Nov 14 23:25:09 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 15 Nov 2015 06:25:09 +0700 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <20151114190845.GH3097@excession.tpb.net> References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> <20151114190845.GH3097@excession.tpb.net> Message-ID: <9FB739E4-2753-45C5-B465-53C28F0C5D29@arbor.net> On 15 Nov 2015, at 2:08, Niels Bakker wrote: > When will there be enough 'corner cases' to convince you it's business > as usual? The majority of people who use the Internet in Turkey do not in fact use Google DNS. It is an informed and motivated minority. The most recent statistics I can find on estimation of global VPN use put the number at ~25% of Internet users. That number seems high to me, and I've no confidence that the study in question was in fact conducted in a rigorous and scientific manner, so I won't link to it here. But let's assume for the sake of discussion that it's reasonably accurate. Do you believe that percentage is going to significantly increase over time? ----------------------------------- Roland Dobbins From johnl at iecc.com Sat Nov 14 23:34:18 2015 From: johnl at iecc.com (John Levine) Date: 14 Nov 2015 23:34:18 -0000 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <339DE9D9-F459-48E3-8D27-94EB76C9044C@arbor.net> Message-ID: <20151114233418.10108.qmail@ary.lan> In article <339DE9D9-F459-48E3-8D27-94EB76C9044C at arbor.net> you write: >On 15 Nov 2015, at 2:25, John Levine wrote: > >> They have point'n'click apps for all the usual platforms. > >They are not defaults. The question at hand is whether gamblers faced with government blocking would use VPNS to cirvumvent it. Given that we have ample evidence that gamblers elsewhere do exactly that, it's hard to imagine why anyone would care that it's not the default. R's, John From johnl at iecc.com Sat Nov 14 23:35:07 2015 From: johnl at iecc.com (John Levine) Date: 14 Nov 2015 23:35:07 -0000 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <9FB739E4-2753-45C5-B465-53C28F0C5D29@arbor.net> Message-ID: <20151114233507.10131.qmail@ary.lan> >Do you believe that percentage is going to significantly increase over >time? What relevance does that have to gamblers using VPNs to circumvent blocks? R's, John From rdobbins at arbor.net Sat Nov 14 23:36:25 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 15 Nov 2015 06:36:25 +0700 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> <5507E655-B415-483B-AAAE-C14648E4C387@arbor.net> <26D0C2D4-99B2-4462-8E79-B195EEEE8171@delong.com> <6796CDAC-7C5E-4A79-A99E-8E503D033BA2@delong.com> Message-ID: <2A54A5E1-F695-4031-B6B9-F156E25DBD28@arbor.net> On 14 Nov 2015, at 23:39, Royce Williams wrote: > Downloading is now much more common 2than during the age of the > browser wars. Sure, I understand that. > > As of October 2014, 64% of American adults owned a smartphone [1]. > Phones > don't usually come with Candy Crush, but somehow, 93 *million* people > played it daily at one point. They many not understand that when they > installed the app, they were "downloading" it. But the end result is > the > same. Yes, because that leads to them doing something they want to be able to do, that is very tangible. The same motivations spur VPN use (e.g., watching Netflix out-of-region, your example of the Olympics, and so forth). To put that 93 million in context, the most recent estimates I can find of Internet users put their number at about 3.2 billion: > It sounds like we're arguing about the definition of the word "most". > Your > thesis appears to be that most people won't use a VPN -- and you're > probably right. Yes, we're in agreement. > But what everyone else is saying is that the value of > "most" is likely to shrink rapidly. I don't know about that. It seems to me that most people who're inclined to use a VPN are already using one. Unless one believes that a relatively high percentage of people who don't yet have Internet access will become VPN users once they gain Internet access. > But now, even if Facebook's estimate [2] of 450 million WhatsApp users > is 90% inflated, > there are 45 million people using encrypted texting, which I would not > have > predicted. Sure, and Apple iMessage is somewhat similar in that regard, though it's more susceptible to MITM. Again, as compared to 3.2 billion. > Most of those users probably don't know what "encryption" is. But > they're > using it. Sure, via http/s. But VPNs used in the sense of this discussion tend to imply topological masking, as well. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Sat Nov 14 23:41:00 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 15 Nov 2015 06:41:00 +0700 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <5647BD59.60804@cox.net> References: <20151114192537.9440.qmail@ary.lan> <339DE9D9-F459-48E3-8D27-94EB76C9044C@arbor.net> <5647BC36.5090105@cox.net> <5647BD59.60804@cox.net> Message-ID: On 15 Nov 2015, at 6:01, Larry Sheldon wrote: > in spite of your best attempts to prevent it. My 'best attempts to prevent it'? You're obviously addressing someone else. I'm not trying to prevent anyone accessing anything. On the contrary, I'm very much in favor of making applications and data and services available to people, and keeping them that way. ----------------------------------- Roland Dobbins From haegar at sdinet.de Sun Nov 15 00:16:44 2015 From: haegar at sdinet.de (Sven-Haegar Koch) Date: Sun, 15 Nov 2015 01:16:44 +0100 (CET) Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <339DE9D9-F459-48E3-8D27-94EB76C9044C@arbor.net> References: <20151114192537.9440.qmail@ary.lan> <339DE9D9-F459-48E3-8D27-94EB76C9044C@arbor.net> Message-ID: On Sun, 15 Nov 2015, Roland Dobbins wrote: > On 15 Nov 2015, at 2:25, John Levine wrote: > > > They have point'n'click apps for all the usual platforms. > > They are not defaults. > > I think that many people on this list don't understand that the vast majority > of users around the world do not know what a VPN is, do not know why they > might need one, and aren't especially adept at installing applications, even > from 'apps stores'. Will everyone use VPN? For sure not. But everyone that really wants to access something that he "should not" by local definition. Like the kids in the neighbourhood - the firsts parents gets an invoice ("Abmahnung" in German) for an illegal download of something done by the kid, and watch how fast it goes around all of them that you can avoid such costs (and more important the trouble with the parents) by just installing this "app". Technical details do not matter, a big enough incentive to do something about it matters. c'ya sven-haegar -- Three may keep a secret, if two of them are dead. - Ben F. From jeff.tantsura at ericsson.com Sun Nov 15 00:26:49 2015 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Sun, 15 Nov 2015 00:26:49 +0000 Subject: EoMPLS vlan rewrite between brands; possibly new bug in Cisco IOS 15 In-Reply-To: References: Message-ID: Been forever since i looked at cisco, however sounds like vc type mismatch. They used to have it as a platform capability, perhaps SW upgrade changed the default. to my memory "show mpls l2 transport" should provide enough details. Hope this helps Regards, Jeff > On Nov 14, 2015, at 4:50 AM, Jonas Bjork wrote: > > Hi, I am using a couple of AToM/EoMPLS tunnels in order to carry customer voice and data traffic across our IP/MPLS core, and it is currently working just fine. The first side consists of a Cisco 7600 router (rsp) and the other one is an HP A5500-HI routing switch with full LER/E-LSR capability. At the HP site, the tunnels are facing the access ports towards our premium end-customers; and on the Cisco PE I terminate the tunnels on one of the 2x10GE portchannel backbone links. There is vlan X on the HP side and vlan Y on the Cisco side - vlan rewrite is working perfectly - as long as I use IOS 12. > > After upgrading the Cisco router software to IOS 15 the tunnels won't come up. sh mpls l2 vc Y d says: > ... > Last error: Imposition VLAN rewrite capability mismatch with peer > ... > > I use almost exactly the same Cisco configuration before and after the upgrade (only minor changes and nothing related to this) and I havn't touched the HP. Apparently they don't talk the same L2PW language. I wonder though, why now? We use service instances on the HP switchport as endpoint, we initiate the targetted LDP session in addition to the pseudowire handshake from a sub interface MPLS crossconnect. There is no MTU mismatch; not here - not anywhere. > > Anyone heard of this issue or experienced it? > > Best regards, > > Jonas Bj?rk > SNE, Europe/Sweden (hope you guys will help me anyway:) From owen at delong.com Sun Nov 15 00:46:04 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 14 Nov 2015 16:46:04 -0800 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> <5507E655-B415-483B-AAAE-C14648E4C387@arbor.net> <26D0C2D4-99B2-4462-8E79-B195EEEE8171@delong.com> <6796CDAC-7C5E-4A79-A99E-8E503D033BA2@delong.com> Message-ID: > On Nov 14, 2015, at 04:34 , Roland Dobbins wrote: > > On 14 Nov 2015, at 19:07, Owen DeLong wrote: > >> The point you seem to be missing is that your ?until?? is already met. > > Not AFAICT. It isn't a default in the OS and on the window manager/home screen. > >> I know of at least one ISP that is providing CPE with VPN pre-configured and built in. > > That makes one. > >> I know of several other software/service solutions that are literally download-launch-subscribe. (download client software, launch installer, supply payment information for subscription). > > The 'download' part is the main barrier to entry. Trust me, this is not a significant barrier to entry. If it were, Chrome would be virtually unused except on Droid. > >> You?re not looking at the right VPN software. > > I look at VPN software all the time, from many providers. > >> The built-in stuff is crap that is years behind the current state of the art. > > My point is that it's in the OS. Who cares? That?s like saying that Nobody uses a different preference of web browser, they almost all stick to the one that comes with the OS. If that were true, Firefox would only run on Linux and Chrome would only run on Chromebooks and Droids. > >> More likely this is going to be iterations of what is already being more widely accepted. Downloadable pre-configured client software that works with a particular VPN service. > > Again, downloading is a barrier to entry. Don't you remember the browser wars and the Microsoft anti-trust case? I do. I also note that the issue there wasn?t merely that IE shipped with the OS, but the fact that you could _NOT_ extricate it from the OS and beyond just downloading another browser, it took significant knowledge to make that other browser the preferred browser on the system with any meaningful persistence. >> Point-click-subscribe model seems to receive fairly wide adoption among people sufficiently interested in bypassing {insert network damage here} to pay a monthly fee for a service that will do it. > > 'Sufficiently interested' is a limiting factor. 'Sufficiently interested' to learn that such a thing is possible, and to figure out how to go about doing it. Among a given community it seems to only take a couple of individuals who figure it out once and if it is sufficiently easy to ?show a friend? such that that friend finds it sufficientlly easy to teach others, adoption spreads quite rapidly through said community. > Of course, the other concern is that governments which don't already interfere with VPNs will outlaw VPNs in the name of 'national security'. Answering my own question, the OS/device vendors won't get into the VPN business due to this issue. Sure, which is why FLOSS or off-shore subscription services will be the likely successful models here and so far, they are succeeding though not to the extent you might consider main stream as yet. Owen From owen at delong.com Sun Nov 15 00:49:51 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 14 Nov 2015 16:49:51 -0800 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> <5507E655-B415-483B-AAAE-C14648E4C387@arbor.net> <26D0C2D4-99B2-4462-8E79-B195EEEE8171@delong.com> <6796CDAC-7C5E-4A79-A99E-8E503D033BA2@delong.com> Message-ID: <0BCD0A16-DC60-4F74-B95F-78A7E9181968@delong.com> > > And it may only take a secondary use case to reach critical mass. People I > know who use WhatsApp seem to have started using it to avoid per-text > charges, not to get end-to-end encrypted messaging. But now, even if > Facebook's estimate [2] of 450 million WhatsApp users is 90% inflated, > there are 45 million people using encrypted texting, which I would not have > predicted. I think the number is much higher than that due to Messsages+iCloud usage by iPhone and other Apple products also constituting end-to-end encrypted text. Yep? Just a few years ago, nobody cared about end-to-end encrypted text, today, still most people don?t know or care what it is, but I bet there are enough people using it without even realizing to constitute ?most? or something very close to it. (Between Skype, WhatsApp, Messages/iMessage, and others). Owen From mr.jonas.bjork at me.com Sun Nov 15 01:31:58 2015 From: mr.jonas.bjork at me.com (Jonas Bjork) Date: Sun, 15 Nov 2015 02:31:58 +0100 Subject: EoMPLS vlan rewrite between brands; possibly new bug in Cisco IOS 15 In-Reply-To: References: Message-ID: Dear Mr. Jeff, Thank you for your reply. Below is the complete output in question (l2 is short for l2transport). You are mentioning platform capabilities and that the default might have changed. How do I alter this? pe#sh mpls l2 vc 42 d Local interface: Po190.42 up, line protocol up, Eth VLAN 42 up Destination address: X.X.1.89, VC ID: 42, VC status: down Last error: Imposition VLAN rewrite capability mismatch with peer Output interface: none, imposed label stack {} Preferred path: not configured Default path: no route No adjacency Create time: 00:00:59, last status change time: 00:31:40 Last label FSM state change time: 00:00:18 Last peer autosense occurred at: 00:00:18 Signaling protocol: LDP, peer X.X.1.89:0 up Targeted Hello: X.X.0.2(LDP Id) -> X.X.1.89, LDP is UP Graceful restart: not configured and not enabled Non stop routing: not configured and not enabled Status TLV support (local/remote) : enabled/not supported LDP route watch : enabled Label/status state machine : remote invalid, LruRnd Last local dataplane status rcvd: No fault Last BFD dataplane status rcvd: Not sent Last BFD peer monitor status rcvd: No fault Last local AC circuit status rcvd: No fault Last local AC circuit status sent: DOWN PW(rx/tx faults) Last local PW i/f circ status rcvd: No fault Last local LDP TLV status sent: No fault Last remote LDP TLV status rcvd: Not sent Last remote LDP ADJ status rcvd: No fault MPLS VC labels: local 242, remote 1199 Group ID: local 0, remote 0 MTU: local 9216, remote 9216 Remote interface description: Remote VLAN id: 42 Sequencing: receive disabled, send disabled Control Word: Off (configured: autosense) SSO Descriptor: X.X.1.89/42, local label: 242 Dataplane: SSM segment/switch IDs: 0/0 (used), PWID: 142 VC statistics: transit packet totals: receive 0, send 0 transit byte totals: receive 0, send 0 transit packet drops: receive 0, seq error 0, send 0 pe# Anyone else: feel free to join in. Maybe we have any L2VC/PW ninjas watching. Best regards, Jonas Bjork > On 15 Nov 2015, at 1:26, Jeff Tantsura wrote: > > Been forever since i looked at cisco, however sounds like vc type mismatch. They used to have it as a platform capability, perhaps SW upgrade changed the default. > > to my memory "show mpls l2 transport" should provide enough details. > > Hope this helps > > Regards, > Jeff > >> On Nov 14, 2015, at 4:50 AM, Jonas Bjork wrote: >> >> Hi, I am using a couple of AToM/EoMPLS tunnels in order to carry customer voice and data traffic across our IP/MPLS core, and it is currently working just fine. The first side consists of a Cisco 7600 router (rsp) and the other one is an HP A5500-HI routing switch with full LER/E-LSR capability. At the HP site, the tunnels are facing the access ports towards our premium end-customers; and on the Cisco PE I terminate the tunnels on one of the 2x10GE portchannel backbone links. There is vlan X on the HP side and vlan Y on the Cisco side - vlan rewrite is working perfectly - as long as I use IOS 12. >> >> After upgrading the Cisco router software to IOS 15 the tunnels won't come up. sh mpls l2 vc Y d says: >> ... >> Last error: Imposition VLAN rewrite capability mismatch with peer >> ... >> >> I use almost exactly the same Cisco configuration before and after the upgrade (only minor changes and nothing related to this) and I havn't touched the HP. Apparently they don't talk the same L2PW language. I wonder though, why now? We use service instances on the HP switchport as endpoint, we initiate the targetted LDP session in addition to the pseudowire handshake from a sub interface MPLS crossconnect. There is no MTU mismatch; not here - not anywhere. >> >> Anyone heard of this issue or experienced it? >> >> Best regards, >> >> Jonas Bj?rk >> SNE, Europe/Sweden (hope you guys will help me anyway:) From jeff.tantsura at ericsson.com Sun Nov 15 01:54:51 2015 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Sun, 15 Nov 2015 01:54:51 +0000 Subject: EoMPLS vlan rewrite between brands; possibly new bug in Cisco IOS 15 In-Reply-To: References: Message-ID: <2D19A5EF-87DB-4B83-97BB-F54A4F3DF1AC@ericsson.com> Jonas, As expected - the problem is related to vc type negotiation. You have hit CSCuq28998 :) talk to your cisco rep Workaround: - configure VC type 5 between the routers (configured on HP side) - configuring no-control-word The bug has been reported in 15.2(4)S4a, perhaps there?s an image with the problem fixed. Cheers, Jeff On 11/14/15, 17:31, "Jonas Bjork" wrote: >Dear Mr. Jeff, > >Thank you for your reply. Below is the complete output in question (l2 is short for l2transport). >You are mentioning platform capabilities and that the default might have changed. How do I alter this? > >pe#sh mpls l2 vc 42 d >Local interface: Po190.42 up, line protocol up, Eth VLAN 42 up > Destination address: X.X.1.89, VC ID: 42, VC status: down > Last error: Imposition VLAN rewrite capability mismatch with peer > Output interface: none, imposed label stack {} > Preferred path: not configured > Default path: no route > No adjacency > Create time: 00:00:59, last status change time: 00:31:40 > Last label FSM state change time: 00:00:18 > Last peer autosense occurred at: 00:00:18 > Signaling protocol: LDP, peer X.X.1.89:0 up > Targeted Hello: X.X.0.2(LDP Id) -> X.X.1.89, LDP is UP > Graceful restart: not configured and not enabled > Non stop routing: not configured and not enabled > Status TLV support (local/remote) : enabled/not supported > LDP route watch : enabled > Label/status state machine : remote invalid, LruRnd > Last local dataplane status rcvd: No fault > Last BFD dataplane status rcvd: Not sent > Last BFD peer monitor status rcvd: No fault > Last local AC circuit status rcvd: No fault > Last local AC circuit status sent: DOWN PW(rx/tx faults) > Last local PW i/f circ status rcvd: No fault > Last local LDP TLV status sent: No fault > Last remote LDP TLV status rcvd: Not sent > Last remote LDP ADJ status rcvd: No fault > MPLS VC labels: local 242, remote 1199 > Group ID: local 0, remote 0 > MTU: local 9216, remote 9216 > Remote interface description: > Remote VLAN id: 42 > Sequencing: receive disabled, send disabled > Control Word: Off (configured: autosense) > SSO Descriptor: X.X.1.89/42, local label: 242 > Dataplane: > SSM segment/switch IDs: 0/0 (used), PWID: 142 > VC statistics: > transit packet totals: receive 0, send 0 > transit byte totals: receive 0, send 0 > transit packet drops: receive 0, seq error 0, send 0 >pe# > >Anyone else: feel free to join in. Maybe we have any L2VC/PW ninjas watching. > >Best regards, >Jonas Bjork > > >> On 15 Nov 2015, at 1:26, Jeff Tantsura wrote: >> >> Been forever since i looked at cisco, however sounds like vc type mismatch. They used to have it as a platform capability, perhaps SW upgrade changed the default. >> >> to my memory "show mpls l2 transport" should provide enough details. >> >> Hope this helps >> >> Regards, >> Jeff >> >>> On Nov 14, 2015, at 4:50 AM, Jonas Bjork wrote: >>> >>> Hi, I am using a couple of AToM/EoMPLS tunnels in order to carry customer voice and data traffic across our IP/MPLS core, and it is currently working just fine. The first side consists of a Cisco 7600 router (rsp) and the other one is an HP A5500-HI routing switch with full LER/E-LSR capability. At the HP site, the tunnels are facing the access ports towards our premium end-customers; and on the Cisco PE I terminate the tunnels on one of the 2x10GE portchannel backbone links. There is vlan X on the HP side and vlan Y on the Cisco side - vlan rewrite is working perfectly - as long as I use IOS 12. >>> >>> After upgrading the Cisco router software to IOS 15 the tunnels won't come up. sh mpls l2 vc Y d says: >>> ... >>> Last error: Imposition VLAN rewrite capability mismatch with peer >>> ... >>> >>> I use almost exactly the same Cisco configuration before and after the upgrade (only minor changes and nothing related to this) and I havn't touched the HP. Apparently they don't talk the same L2PW language. I wonder though, why now? We use service instances on the HP switchport as endpoint, we initiate the targetted LDP session in addition to the pseudowire handshake from a sub interface MPLS crossconnect. There is no MTU mismatch; not here - not anywhere. >>> >>> Anyone heard of this issue or experienced it? >>> >>> Best regards, >>> >>> Jonas Bj?rk >>> SNE, Europe/Sweden (hope you guys will help me anyway:) > From jamesb2147 at gmail.com Sun Nov 15 02:00:57 2015 From: jamesb2147 at gmail.com (Sean Hunter) Date: Sun, 15 Nov 2015 10:00:57 +0800 Subject: Project Fi and the Great Firewall Message-ID: Hello everyone, I come to you to humbly request your assistance, on or off list. This not an urgent technical matter, but something I'm rather fascinated by at the moment. While in China recently, I noticed that my Project Fi phone was accessing Google. Not only Google, but Facebook, YouTube, Gmail, Twitter, and many other normally perma-blocked websites. It's taken me a few days of sleep deprived thinking to realize this, but I'm seeing the same or similar 26.x.x.x addresses across countries I've visited, including China, Spain, Malaysia, and Hong Kong. I'm not a cellular guy and I know even less about MVNO's, but I'm curious if I'm inferring the technical operations of the network correctly. It sounds like the local cellular companies are provisioning access upon arrival, then packing up the packets and shipping them off at layer 2 or below to Google, who's then handling the IP stack and up internet access. I'm also assuming the Great Firewall then acts above these layers since it's not blocking access on my phone. If my inference is correct, I'd be curious to see if those responsible for the Great Firewall are aware of this deal Google has with a Chinese cellular provider and the technical specifics of how it works. Might we be seeing a softening of Great Firewall policies for foreigners, or just another soon to be inspected or blocked flow of traffic? Anyway, I'd just love to hear from a knowledgeable engineer about how this works. If you've read this far, thanks for your time and have a great day! From mr.jonas.bjork at me.com Sun Nov 15 02:02:00 2015 From: mr.jonas.bjork at me.com (Jonas Bjork) Date: Sun, 15 Nov 2015 03:02:00 +0100 Subject: EoMPLS vlan rewrite between brands; possibly new bug in Cisco IOS 15 In-Reply-To: <2D19A5EF-87DB-4B83-97BB-F54A4F3DF1AC@ericsson.com> References: <2D19A5EF-87DB-4B83-97BB-F54A4F3DF1AC@ericsson.com> Message-ID: Thank you Jeff, I'll check it out on the HP side since Cisco seems to not care: Known Fixed Releases: (0) No release planned to fix this bug Best regards, Jonas Bjork > On 15 Nov 2015, at 2:54, Jeff Tantsura wrote: > > Jonas, > > As expected - the problem is related to vc type negotiation. > > You have hit CSCuq28998 :) > talk to your cisco rep > > Workaround: > - configure VC type 5 between the routers (configured on HP side) > - configuring no-control-word > > > The bug has been reported in 15.2(4)S4a, perhaps there?s an image with the problem fixed. > > Cheers, > Jeff > > > > > On 11/14/15, 17:31, "Jonas Bjork" wrote: > >> Dear Mr. Jeff, >> >> Thank you for your reply. Below is the complete output in question (l2 is short for l2transport). >> You are mentioning platform capabilities and that the default might have changed. How do I alter this? >> >> pe#sh mpls l2 vc 42 d >> Local interface: Po190.42 up, line protocol up, Eth VLAN 42 up >> Destination address: X.X.1.89, VC ID: 42, VC status: down >> Last error: Imposition VLAN rewrite capability mismatch with peer >> Output interface: none, imposed label stack {} >> Preferred path: not configured >> Default path: no route >> No adjacency >> Create time: 00:00:59, last status change time: 00:31:40 >> Last label FSM state change time: 00:00:18 >> Last peer autosense occurred at: 00:00:18 >> Signaling protocol: LDP, peer X.X.1.89:0 up >> Targeted Hello: X.X.0.2(LDP Id) -> X.X.1.89, LDP is UP >> Graceful restart: not configured and not enabled >> Non stop routing: not configured and not enabled >> Status TLV support (local/remote) : enabled/not supported >> LDP route watch : enabled >> Label/status state machine : remote invalid, LruRnd >> Last local dataplane status rcvd: No fault >> Last BFD dataplane status rcvd: Not sent >> Last BFD peer monitor status rcvd: No fault >> Last local AC circuit status rcvd: No fault >> Last local AC circuit status sent: DOWN PW(rx/tx faults) >> Last local PW i/f circ status rcvd: No fault >> Last local LDP TLV status sent: No fault >> Last remote LDP TLV status rcvd: Not sent >> Last remote LDP ADJ status rcvd: No fault >> MPLS VC labels: local 242, remote 1199 >> Group ID: local 0, remote 0 >> MTU: local 9216, remote 9216 >> Remote interface description: >> Remote VLAN id: 42 >> Sequencing: receive disabled, send disabled >> Control Word: Off (configured: autosense) >> SSO Descriptor: X.X.1.89/42, local label: 242 >> Dataplane: >> SSM segment/switch IDs: 0/0 (used), PWID: 142 >> VC statistics: >> transit packet totals: receive 0, send 0 >> transit byte totals: receive 0, send 0 >> transit packet drops: receive 0, seq error 0, send 0 >> pe# >> >> Anyone else: feel free to join in. Maybe we have any L2VC/PW ninjas watching. >> >> Best regards, >> Jonas Bjork >> >> >>> On 15 Nov 2015, at 1:26, Jeff Tantsura wrote: >>> >>> Been forever since i looked at cisco, however sounds like vc type mismatch. They used to have it as a platform capability, perhaps SW upgrade changed the default. >>> >>> to my memory "show mpls l2 transport" should provide enough details. >>> >>> Hope this helps >>> >>> Regards, >>> Jeff >>> >>>> On Nov 14, 2015, at 4:50 AM, Jonas Bjork wrote: >>>> >>>> Hi, I am using a couple of AToM/EoMPLS tunnels in order to carry customer voice and data traffic across our IP/MPLS core, and it is currently working just fine. The first side consists of a Cisco 7600 router (rsp) and the other one is an HP A5500-HI routing switch with full LER/E-LSR capability. At the HP site, the tunnels are facing the access ports towards our premium end-customers; and on the Cisco PE I terminate the tunnels on one of the 2x10GE portchannel backbone links. There is vlan X on the HP side and vlan Y on the Cisco side - vlan rewrite is working perfectly - as long as I use IOS 12. >>>> >>>> After upgrading the Cisco router software to IOS 15 the tunnels won't come up. sh mpls l2 vc Y d says: >>>> ... >>>> Last error: Imposition VLAN rewrite capability mismatch with peer >>>> ... >>>> >>>> I use almost exactly the same Cisco configuration before and after the upgrade (only minor changes and nothing related to this) and I havn't touched the HP. Apparently they don't talk the same L2PW language. I wonder though, why now? We use service instances on the HP switchport as endpoint, we initiate the targetted LDP session in addition to the pseudowire handshake from a sub interface MPLS crossconnect. There is no MTU mismatch; not here - not anywhere. >>>> >>>> Anyone heard of this issue or experienced it? >>>> >>>> Best regards, >>>> >>>> Jonas Bj?rk >>>> SNE, Europe/Sweden (hope you guys will help me anyway:) >> From rdobbins at arbor.net Sun Nov 15 02:16:51 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 15 Nov 2015 09:16:51 +0700 Subject: Project Fi and the Great Firewall In-Reply-To: References: Message-ID: <208D7CF9-D840-4A09-8768-602778A762F1@arbor.net> On 15 Nov 2015, at 9:00, Sean Hunter wrote: > While in China recently, I noticed that my Project Fi phone was > accessing Google. Accessing, or attempting to access? Were you using a local SIM card, or roaming w/data? What about WiFi? ----------------------------------- Roland Dobbins From joelja at bogus.com Sun Nov 15 02:18:50 2015 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 14 Nov 2015 18:18:50 -0800 Subject: Project Fi and the Great Firewall In-Reply-To: References: Message-ID: Sent from my iPhone > On Nov 14, 2015, at 18:00, Sean Hunter wrote: > > Hello everyone, > > I come to you to humbly request your assistance, on or off list. This not > an urgent technical matter, but something I'm rather fascinated by at the > moment. > > While in China recently, I noticed that my Project Fi phone was accessing > Google. Not only Google, but Facebook, YouTube, Gmail, Twitter, and many > other normally perma-blocked websites. It's taken me a few days of sleep > deprived thinking to realize this, but I'm seeing the same or similar > 26.x.x.x addresses across countries I've visited, including China, Spain, > Malaysia, and Hong Kong. 26/8 is T-Mobile using DOD space for their internal addressing. Irrespective of where you are your connected to the Same APN and traffic from your UE is indeed tunneled through the PGW https://en.m.wikipedia.org/wiki/System_Architecture_Evolution# > > I'm not a cellular guy and I know even less about MVNO's, but I'm curious > if I'm inferring the technical operations of the network correctly. It > sounds like the local cellular companies are provisioning access upon > arrival, then packing up the packets and shipping them off at layer 2 or > below to Google, who's then handling the IP stack and up internet access. > I'm also assuming the Great Firewall then acts above these layers since > it's not blocking access on my phone. > > If my inference is correct, I'd be curious to see if those responsible for > the Great Firewall are aware of this deal Google has with a Chinese > cellular provider and the technical specifics of how it works. Might we be > seeing a softening of Great Firewall policies for foreigners, or just > another soon to be inspected or blocked flow of traffic? > > Anyway, I'd just love to hear from a knowledgeable engineer about how this > works. > > If you've read this far, thanks for your time and have a great day! > From jake.mertel at ubiquityhosting.com Sun Nov 15 02:27:47 2015 From: jake.mertel at ubiquityhosting.com (Jake Mertel) Date: Sat, 14 Nov 2015 19:27:47 -0700 Subject: Project Fi and the Great Firewall In-Reply-To: <208D7CF9-D840-4A09-8768-602778A762F1@arbor.net> References: <208D7CF9-D840-4A09-8768-602778A762F1@arbor.net> Message-ID: I know the service/device uses VPN if you are using "wifi assist" to connect to an open WAP -- it automatically tunnels the traffic so it can't be read by nearby snoopers. Perhaps they employ a similar technology or are using something like PPP to take all of the traffic back to one (or many) "access servers" before sending it off to the Internet. I have no experience whatsoever in cellular network operations, but I know many providers employ similar methodologies to assist in meeting their CALEA requirements. On Saturday, November 14, 2015, Roland Dobbins wrote: > On 15 Nov 2015, at 9:00, Sean Hunter wrote: > > While in China recently, I noticed that my Project Fi phone was accessing >> Google. >> > > Accessing, or attempting to access? > > Were you using a local SIM card, or roaming w/data? What about WiFi? > > ----------------------------------- > Roland Dobbins > -- -- Regards, Jake Mertel Ubiquity Hosting *Web: *https://www.ubiquityhosting.com *Phone (direct): *1-480-478-1510 *Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054 From shefys at gmail.com Sun Nov 15 04:02:53 2015 From: shefys at gmail.com (Yury Shefer) Date: Sat, 14 Nov 2015 20:02:53 -0800 Subject: Project Fi and the Great Firewall In-Reply-To: References: Message-ID: My team mate was traveling to China with his Nexus 6 (with Project Fi SIM-card) and was able to access Google services. The phone uses roaming data to access Google and your phone gets IP assigned by your home mobile network packet gateway (P-GW). There is no local data break-out. On Sat, Nov 14, 2015 at 6:00 PM, Sean Hunter wrote: > Hello everyone, > > I come to you to humbly request your assistance, on or off list. This not > an urgent technical matter, but something I'm rather fascinated by at the > moment. > > While in China recently, I noticed that my Project Fi phone was accessing > Google. Not only Google, but Facebook, YouTube, Gmail, Twitter, and many > other normally perma-blocked websites. It's taken me a few days of sleep > deprived thinking to realize this, but I'm seeing the same or similar > 26.x.x.x addresses across countries I've visited, including China, Spain, > Malaysia, and Hong Kong. > > I'm not a cellular guy and I know even less about MVNO's, but I'm curious > if I'm inferring the technical operations of the network correctly. It > sounds like the local cellular companies are provisioning access upon > arrival, then packing up the packets and shipping them off at layer 2 or > below to Google, who's then handling the IP stack and up internet access. > I'm also assuming the Great Firewall then acts above these layers since > it's not blocking access on my phone. > > If my inference is correct, I'd be curious to see if those responsible for > the Great Firewall are aware of this deal Google has with a Chinese > cellular provider and the technical specifics of how it works. Might we be > seeing a softening of Great Firewall policies for foreigners, or just > another soon to be inspected or blocked flow of traffic? > > Anyway, I'd just love to hear from a knowledgeable engineer about how this > works. > > If you've read this far, thanks for your time and have a great day! > -- Best regards, Yury. From rdobbins at arbor.net Sun Nov 15 04:57:48 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 15 Nov 2015 11:57:48 +0700 Subject: Project Fi and the Great Firewall In-Reply-To: References: Message-ID: On 15 Nov 2015, at 11:02, Yury Shefer wrote: > The phone uses roaming data to access Google and your phone gets IP > assigned by your home mobile > network packet gateway (P-GW). This is what I thought, as well - thanks for confirming! ----------------------------------- Roland Dobbins From sunyucong at gmail.com Sun Nov 15 04:59:49 2015 From: sunyucong at gmail.com (Yucong Sun) Date: Sun, 15 Nov 2015 12:59:49 +0800 Subject: Project Fi and the Great Firewall In-Reply-To: References: Message-ID: This is what roaming data means, Your data packet is simply trunked to your original operator to process. So you will be having a US ip on the web. On Sun, Nov 15, 2015 at 12:02 PM, Yury Shefer wrote: > My team mate was traveling to China with his Nexus 6 (with Project Fi > SIM-card) and was able to access Google services. The phone uses roaming > data to access Google and your phone gets IP assigned by your home mobile > network packet gateway (P-GW). There is no local data break-out. > > On Sat, Nov 14, 2015 at 6:00 PM, Sean Hunter wrote: > >> Hello everyone, >> >> I come to you to humbly request your assistance, on or off list. This not >> an urgent technical matter, but something I'm rather fascinated by at the >> moment. >> >> While in China recently, I noticed that my Project Fi phone was accessing >> Google. Not only Google, but Facebook, YouTube, Gmail, Twitter, and many >> other normally perma-blocked websites. It's taken me a few days of sleep >> deprived thinking to realize this, but I'm seeing the same or similar >> 26.x.x.x addresses across countries I've visited, including China, Spain, >> Malaysia, and Hong Kong. >> >> I'm not a cellular guy and I know even less about MVNO's, but I'm curious >> if I'm inferring the technical operations of the network correctly. It >> sounds like the local cellular companies are provisioning access upon >> arrival, then packing up the packets and shipping them off at layer 2 or >> below to Google, who's then handling the IP stack and up internet access. >> I'm also assuming the Great Firewall then acts above these layers since >> it's not blocking access on my phone. >> >> If my inference is correct, I'd be curious to see if those responsible for >> the Great Firewall are aware of this deal Google has with a Chinese >> cellular provider and the technical specifics of how it works. Might we be >> seeing a softening of Great Firewall policies for foreigners, or just >> another soon to be inspected or blocked flow of traffic? >> >> Anyway, I'd just love to hear from a knowledgeable engineer about how this >> works. >> >> If you've read this far, thanks for your time and have a great day! >> > > > > -- > Best regards, > Yury. From brandon at rd.bbc.co.uk Sun Nov 15 14:01:26 2015 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sun, 15 Nov 2015 14:01:26 GMT Subject: Project Fi and the Great Firewall Message-ID: <201511151401.OAA06558@sunf10.rd.bbc.co.uk> > This is what roaming data means, Your data packet is simply trunked to > your original operator to process. So you will be having a US ip on > the web. And continuity of US tracking of your use rather than temporary Chinese tracking brandon From toddunder at gmail.com Sun Nov 15 14:21:53 2015 From: toddunder at gmail.com (Todd Underwood) Date: Sun, 15 Nov 2015 14:21:53 +0000 Subject: Project Fi and the Great Firewall In-Reply-To: <201511151401.OAA06558@sunf10.rd.bbc.co.uk> References: <201511151401.OAA06558@sunf10.rd.bbc.co.uk> Message-ID: Why not both? So sad when you have to choose a single oppressive regime to track your internet use. T On Sun, Nov 15, 2015, 09:04 Brandon Butterworth wrote: > > This is what roaming data means, Your data packet is simply trunked to > > your original operator to process. So you will be having a US ip on > > the web. > > And continuity of US tracking of your use rather than temporary Chinese > tracking > > brandon > From morrowc.lists at gmail.com Sun Nov 15 17:21:46 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 15 Nov 2015 12:21:46 -0500 Subject: Project Fi and the Great Firewall In-Reply-To: References: <201511151401.OAA06558@sunf10.rd.bbc.co.uk> Message-ID: On Sun, Nov 15, 2015 at 9:21 AM, Todd Underwood wrote: > Why not both? So sad when you have to choose a single oppressive regime to > track your internet use. to be fair, probably: o china sees the local mobile and can easily unwrap the probably not encrypted outer packet headers to get your 'metadata' o five-eyes sees the over-water transimission(s) and does the same as above o US folk see at the GPRx in the US So really there's 6 regimes all repressive, in their own right, involved. > T > > On Sun, Nov 15, 2015, 09:04 Brandon Butterworth > wrote: > >> > This is what roaming data means, Your data packet is simply trunked to >> > your original operator to process. So you will be having a US ip on >> > the web. >> >> And continuity of US tracking of your use rather than temporary Chinese >> tracking >> >> brandon >> From jfmezei_nanog at vaxination.ca Sun Nov 15 20:20:07 2015 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sun, 15 Nov 2015 15:20:07 -0500 Subject: Project Fi and the Great Firewall In-Reply-To: References: Message-ID: <5648E8F7.3080008@vaxination.ca> On 2015-11-14 23:59, Yucong Sun wrote: > This is what roaming data means, Your data packet is simply trunked to > your original operator to process. So you will be having a US ip on > the web. Based on my understanding, the phone establishes a local IP aconnection with equipment associated with an antenna and gets an IP a from it. It then establishes a tunnel to the APN operated by your carrier and the tunnel gets the IP address that your apps see/use. The IP address your apps see/use is given by your home carrier and all packlets flow through your home carrier's APN before going to the internet and you use your home carrier's DNS. Where I am unclear is what happens when you move from tower to tower. Whether your local IP changes and the tunnel is transparently moved to the new local IP, of whether the local IP address moves with you and routing tables are changed. Some phones have "debug" modes that will show both the local (local antenna) and the public IP address (from APN) in use. As your traffic flows out of China, it passes through the "great wall of routers" as traffic between you and your carrier's APN, not between you and some banned site you are trying to access. They'd have to do DPI and possibly decrypt tunnel traffic to catch where you are trying to connect and block those. From jaap at NLnetLabs.nl Sat Nov 14 07:32:51 2015 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Sat, 14 Nov 2015 08:32:51 +0100 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> Message-ID: <201511140732.tAE7Wpa2070273@bela.nlnetlabs.nl> "Roland Dobbins" writes: > On 14 Nov 2015, at 10:22, Owen DeLong wrote: > > By a tiny minority of people. > > Selection bias. > > Most people do not know what a 'VPN' is, or how to install one and get > it working. Most people don't need to know. They just buy a cheap (EUR 50 or so seems to be the starting price) application (rasberry Pi or similar stuff based) which gives them what they want. There is now a push to forbid the sales of these thingies. jaap From janusz at speedchecker.xyz Sat Nov 14 13:11:10 2015 From: janusz at speedchecker.xyz (Janusz Jezowicz) Date: Sat, 14 Nov 2015 14:11:10 +0100 Subject: Updated Ookla Speedtest Server Requirements Message-ID: We have done lots of 1Gbit testing in last months while improving our own speed tester for 1Gbit. We found Speedtest.net very inaccurate on 1Gbit (especially in IE) If anyone is interested in our test results feel free to have a look here> https://dl.dropboxusercontent.com/u/6260259/BSC%20HTML5%20Speedtest%20vs%20NetGauge%20-%201Gbps%20testing%20-%20evaluation.xlsx Our test setup was - We spawned 2x 1Gbit network instances on Amazon EC2 and measured throughput between them. We found DSLReports being much more accurate, on top of being HTML5 based. Of course we are very biased because we offer speed test as well, but I hope it prompts someone to verify if results from Ookla on 1Gbit connections are what they expect. Janusz http://www.speedchecker.xyz > The speedtest.net is flash based. Many computers struggle to measure 1g> speed and not because the network is slow. I think you will find it very> hard to get a 10g measure. > If you like us just want to be sure your 1g users get 1g even when other> users are running parallel tests, you do not need to worry too much about> the server. It needs a 10g NIC but it does not need to perform more than 2g>if even that. You will simply not have that many parallel tests running at> any given time. > > Regards > > Baldur Den 9. nov. 2015 22.27 skrev "Lorell Hathcock" : Esteemed Legions of NANOG: Does anyone have better and more modern recommendations for the hardware of an Ookla speedtest server? Here is the link to their recommendations. http://www.ookla.com/support/a26461638/ I want a server that is capable of handlilng a speedtest up to 10Gbps. I plan to do this with an SFP+ port when my network comes along. (As soon as MikroTik comes out with a decent 10G CCR router that is compatible with more SFPs.) In the mean time I will just test 1 Gbps speeds off a copper GE port, but want the SFP+ capability so I don't have to repurchase hardware in the next year. Thanks! Sincerely, Lorell Hathcock Chief Technology Officer SolStar Network, LLC Communications FIBER - VOIP - SECURITY - TV FTTH - Commercial - Residential Burglar - Access Control 956-478-5955 (cell) - 956-316-4090 (main) () SolStarNetwork com> lorell () SolStarNetwork com www.SolStarNetwork.com TX License #B19998 From jared at compuwizz.net Sun Nov 15 03:08:49 2015 From: jared at compuwizz.net (Jared Geiger) Date: Sat, 14 Nov 2015 19:08:49 -0800 Subject: Project Fi and the Great Firewall In-Reply-To: References: <208D7CF9-D840-4A09-8768-602778A762F1@arbor.net> Message-ID: When you roam onto another cellular network other than your home network, your data is encapsulated and sent back to your home network before going out to the internet. This is to provide a seamless experience for the customer. The network it rides on is the GRX/IPX which is a a worldwide MPLS network that the GSMA specified to make the data roaming experience work. The GRX/IPX also can carry voice and text back to the home network. Since it is a separate network from the Internet, the Great Firewall was bypassed. There are several GRX/IPX providers and they all peer with each other in key locations which usually end up being in the same major Internet peering locations. TATA, Syniverse, SAP, Telia, and many others run an IPX/GRX network and Equinix has IPX/GRX peering exchanges. The wikipedia articles will start you in the right direction for more information: https://en.wikipedia.org/wiki/GPRS_roaming_exchange https://en.wikipedia.org/wiki/IP_exchange ~Jared On Sat, Nov 14, 2015 at 6:27 PM, Jake Mertel < jake.mertel at ubiquityhosting.com> wrote: > I know the service/device uses VPN if you are using "wifi assist" to > connect to an open WAP -- it automatically tunnels the traffic so it can't > be read by nearby snoopers. Perhaps they employ a similar technology or are > using something like PPP to take all of the traffic back to one (or many) > "access servers" before sending it off to the Internet. I have no > experience whatsoever in cellular network operations, but I know many > providers employ similar methodologies to assist in meeting their CALEA > requirements. > > On Saturday, November 14, 2015, Roland Dobbins wrote: > > > On 15 Nov 2015, at 9:00, Sean Hunter wrote: > > > > While in China recently, I noticed that my Project Fi phone was accessing > >> Google. > >> > > > > Accessing, or attempting to access? > > > > Were you using a local SIM card, or roaming w/data? What about WiFi? > > > > ----------------------------------- > > Roland Dobbins > > > > > -- > > > -- > Regards, > > Jake Mertel > Ubiquity Hosting > > > > *Web: *https://www.ubiquityhosting.com > *Phone (direct): *1-480-478-1510 > *Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054 > From carlos at race.com Mon Nov 16 05:33:25 2015 From: carlos at race.com (Carlos Alcantar) Date: Mon, 16 Nov 2015 05:33:25 +0000 Subject: Project Fi and the Great Firewall In-Reply-To: References: <208D7CF9-D840-4A09-8768-602778A762F1@arbor.net> , Message-ID: Similar to the SS7 phone network where call signaling data is done on a totally different path then the actual rtp path. ? 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 ________________________________________ From: NANOG on behalf of Jared Geiger Sent: Saturday, November 14, 2015 7:08 PM To: NANOG Subject: Re: Project Fi and the Great Firewall When you roam onto another cellular network other than your home network, your data is encapsulated and sent back to your home network before going out to the internet. This is to provide a seamless experience for the customer. The network it rides on is the GRX/IPX which is a a worldwide MPLS network that the GSMA specified to make the data roaming experience work. The GRX/IPX also can carry voice and text back to the home network. Since it is a separate network from the Internet, the Great Firewall was bypassed. There are several GRX/IPX providers and they all peer with each other in key locations which usually end up being in the same major Internet peering locations. TATA, Syniverse, SAP, Telia, and many others run an IPX/GRX network and Equinix has IPX/GRX peering exchanges. The wikipedia articles will start you in the right direction for more information: https://en.wikipedia.org/wiki/GPRS_roaming_exchange https://en.wikipedia.org/wiki/IP_exchange ~Jared On Sat, Nov 14, 2015 at 6:27 PM, Jake Mertel < jake.mertel at ubiquityhosting.com> wrote: > I know the service/device uses VPN if you are using "wifi assist" to > connect to an open WAP -- it automatically tunnels the traffic so it can't > be read by nearby snoopers. Perhaps they employ a similar technology or are > using something like PPP to take all of the traffic back to one (or many) > "access servers" before sending it off to the Internet. I have no > experience whatsoever in cellular network operations, but I know many > providers employ similar methodologies to assist in meeting their CALEA > requirements. > > On Saturday, November 14, 2015, Roland Dobbins wrote: > > > On 15 Nov 2015, at 9:00, Sean Hunter wrote: > > > > While in China recently, I noticed that my Project Fi phone was accessing > >> Google. > >> > > > > Accessing, or attempting to access? > > > > Were you using a local SIM card, or roaming w/data? What about WiFi? > > > > ----------------------------------- > > Roland Dobbins > > > > > -- > > > -- > Regards, > > Jake Mertel > Ubiquity Hosting > > > > *Web: *https://www.ubiquityhosting.com > *Phone (direct): *1-480-478-1510 > *Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054 > From jwbensley at gmail.com Mon Nov 16 09:21:26 2015 From: jwbensley at gmail.com (James Bensley) Date: Mon, 16 Nov 2015 09:21:26 +0000 Subject: EoMPLS vlan rewrite between brands; possibly new bug in Cisco IOS 15 In-Reply-To: References: Message-ID: On 15 November 2015 at 01:31, Jonas Bjork wrote: > Dear Mr. Jeff, > > Thank you for your reply. Below is the complete output in question (l2 is short for l2transport). > You are mentioning platform capabilities and that the default might have changed. How do I alter this? > > pe#sh mpls l2 vc 42 d > Local interface: Po190.42 up, line protocol up, Eth VLAN 42 up > Destination address: X.X.1.89, VC ID: 42, VC status: down > Last error: Imposition VLAN rewrite capability mismatch with peer > Output interface: none, imposed label stack {} > Preferred path: not configured > Default path: no route > No adjacency > Create time: 00:00:59, last status change time: 00:31:40 > Last label FSM state change time: 00:00:18 > Last peer autosense occurred at: 00:00:18 > Signaling protocol: LDP, peer X.X.1.89:0 up > Targeted Hello: X.X.0.2(LDP Id) -> X.X.1.89, LDP is UP > Graceful restart: not configured and not enabled > Non stop routing: not configured and not enabled > Status TLV support (local/remote) : enabled/not supported > LDP route watch : enabled > Label/status state machine : remote invalid, LruRnd > Last local dataplane status rcvd: No fault > Last BFD dataplane status rcvd: Not sent > Last BFD peer monitor status rcvd: No fault > Last local AC circuit status rcvd: No fault > Last local AC circuit status sent: DOWN PW(rx/tx faults) > Last local PW i/f circ status rcvd: No fault > Last local LDP TLV status sent: No fault > Last remote LDP TLV status rcvd: Not sent > Last remote LDP ADJ status rcvd: No fault > MPLS VC labels: local 242, remote 1199 > Group ID: local 0, remote 0 > MTU: local 9216, remote 9216 > Remote interface description: > Remote VLAN id: 42 > Sequencing: receive disabled, send disabled > Control Word: Off (configured: autosense) > SSO Descriptor: X.X.1.89/42, local label: 242 > Dataplane: > SSM segment/switch IDs: 0/0 (used), PWID: 142 > VC statistics: > transit packet totals: receive 0, send 0 > transit byte totals: receive 0, send 0 > transit packet drops: receive 0, seq error 0, send 0 > pe# > > Anyone else: feel free to join in. Maybe we have any L2VC/PW ninjas watching. > > Best regards, > Jonas Bjork Hi Jonas, In that output you have "Remote VLAN id: 42" -What is the local VLAN ID on your Cisco PE? Do you need to VLAN rewrite here? Since you using different VLANs at each end, can you build the pseudowire at a point in the network stack where the VLAN tag has been popped off already and transport the frames untagged, so they will be pushed on again at the other end? (Is this is a VC type 4 pseudowire, check with "show mpls l2transport binding 42", if so, a dummy VLAN should be pushed on and popped off transparently if all hardware in use supports it). I don't know HP but with the Cisco 7600 for example, if it's VLAN 50 then you could add "interface vlan 50; xconnecy X.X.1.89 42 encaps mpls", if your hardware supports that. Or use mux-uni; "int gix/x.y; encaps dot1q y; xconnecy X.X.1.89 42 encaps mpls". Then add vice versa on the HP kit. What IOS have you tried to upgrade to, 15.2(4)S4a? If this is a VC type 4 pseudowire and either the HP or Cisco isn't supporting inserting a dummy VLAN tag, why is this a VC type 4 pseudowire? The VLAN re-write I guess. Certainly in IOS 15.3 (so probably also in 15.2 but I'm not 100% certain of that) Cisco IOS should be defaulting to VC type 5 unless the other end negotiates down to VC type 4. VC type 5 in IOS supports transporting of untagged, tagged and double tagged frames, I don't think there is any functionality in VC type 5 that wasn't in older type 4's so I'd try and work out why your devices are negotiating type 4 and maybe try to fix that, or as above, transport untagged. Cheers, James. From yang.yu.list at gmail.com Mon Nov 16 09:37:19 2015 From: yang.yu.list at gmail.com (Yang Yu) Date: Mon, 16 Nov 2015 03:37:19 -0600 Subject: Time Waner Cable IPv6 help needed Message-ID: Last month after a service upgrade/reprovisioning I am no longer getting an IPv6 prefix. Now all I see are RAs and never a response to DHCPv6 solicit. I have tried different support channels but no luck getting an answer. >From what I gathered IPv6 is available in my market and no known outages. Can someone please ping me offline? Very much appreciated Yang From dot at dotat.at Mon Nov 16 11:11:33 2015 From: dot at dotat.at (Tony Finch) Date: Mon, 16 Nov 2015 11:11:33 +0000 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <9A14E989-8633-4937-BE46-7D27F5747235@delong.com> References: <20151113052946.7102.qmail@ary.lan> <9A14E989-8633-4937-BE46-7D27F5747235@delong.com> Message-ID: Owen DeLong wrote: > Again, if you?re the only resolver the clients are using, you can claim that > nothing from the root down is signed without ever providing any cryptographic > anything. If the client is validating it will know the root is signed and the ISP resolver will not be able to strip signature without breaking validation. Tony. -- f.anthony.n.finch http://dotat.at/ Thames, Dover, Wight, Portland: Southwest 6 to gale 8, decreasing 5 for a time, perhaps severe gale 9 later. Moderate or rough, occasionally very rough later. Rain at times. Moderate or good, occasionally poor. From dot at dotat.at Mon Nov 16 11:14:42 2015 From: dot at dotat.at (Tony Finch) Date: Mon, 16 Nov 2015 11:14:42 +0000 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <002801d11e3e$d8973990$89c5acb0$@truenet.com> References: <20151113052946.7102.qmail@ary.lan> <9A14E989-8633-4937-BE46-7D27F5747235@delong.com> <002801d11e3e$d8973990$89c5acb0$@truenet.com> Message-ID: eric-list at truenet.com wrote: > Actually, how are other places implementing these lists? I would have > thought to use RPZ, but as far as I know if the blocked DNS domain is > using DNSSEC it wouldn't work. You can configure RPZ with the "break-dnssec" option which means validating clients will fail to resolve the blocked domains. DNSSEC only protects you from getting bad answers. If someone wants you to get no answers at all then DNSSEC cannot help. Tony. -- f.anthony.n.finch http://dotat.at/ Tyne, Dogger, Fisher: Southwest 6 to gale 8, occasionally severe gale 9 at first. Rough or very rough, becoming mainly moderate in Tyne. Rain or showers. Good, occasionally poor. From howard.m.kash.civ at mail.mil Mon Nov 16 12:30:50 2015 From: howard.m.kash.civ at mail.mil (Kash, Howard M CIV USARMY RDECOM ARL (US)) Date: Mon, 16 Nov 2015 12:30:50 +0000 Subject: Advance notice - H-root address change on December 1, 2015 In-Reply-To: <8B01299690A8A94AB8629283FAFED8F1ACBA048A@umechpanz.easf.csd.disa.mil> References: <8B01299690A8A94AB8629283FAFED8F1ACBA048A@umechpanz.easf.csd.disa.mil> Message-ID: <8B01299690A8A94AB8629283FAFED8F1C8BC596F@umechpanz.easf.csd.disa.mil> Friendly reminder... > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kash, Howard M CIV USARMY RDECOM > ARL (US) > Sent: Monday, August 31, 2015 12:39 PM > To: nanog at nanog.org > Subject: Advance notice - H-root address change on December 1, 2015 > > > This is advance notice that there is a scheduled change to the IP addresses > for one of the authorities listed for the DNS root zone and the .ARPA TLD. > The change is to H.ROOT-SERVERS.NET, which is administered by the U.S. Army > Research Laboratory. > > The new IPv4 address for this authority is 198.97.190.53. > > The new IPv6 address for the authority is 2001:500:1::53. > > This change is anticipated to be implemented in the root zone on 1 December > 2015, however the new addresses are operational now. They will replace the > previous IP addresses of 128.63.2.53 and 2001:500:1::803f:235 (also > previously known as AOS.BRL.MIL and AOS.ARL.ARMY.MIL). > > We encourage operators of DNS infrastructure to update any references to the > old IP addresses and replace them with the new addresses. In particular, > many DNS resolvers have a DNS root "hints" file. This should be updated with > the new IP addresses. > > New hints files will be available at the following URLs once the change has > been formally executed on December 1: > > http://www.internic.net/domain/named.root > http://www.internic.net/domain/named.cache > > The old IPv4 address will continue to work for six months after the > transition (until 1 June 2016), at which point it will be retired from > service. The address will remain under the control of the Army Research > Laboratory, never to be used again for DNS service. The old IPv6 address > will continue to work indefinitely, but may ultimately be retired from > service. > > Simultaneous to the retirement of the old address on June 1, 2016, the > ASN for H-root will change from 13 to 1508. > > You can monitor the transition of queries to the new addresses at the > following URL: > > http://h.root-servers.org/old_vs_new.html > > > -- > Howard Kash > U.S. Army Research Laboratory -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5583 bytes Desc: not available URL: From josh at imaginenetworksllc.com Mon Nov 16 15:35:02 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 16 Nov 2015 10:35:02 -0500 Subject: Advance notice - H-root address change on December 1, 2015 In-Reply-To: <8B01299690A8A94AB8629283FAFED8F1C8BC596F@umechpanz.easf.csd.disa.mil> References: <8B01299690A8A94AB8629283FAFED8F1ACBA048A@umechpanz.easf.csd.disa.mil> <8B01299690A8A94AB8629283FAFED8F1C8BC596F@umechpanz.easf.csd.disa.mil> Message-ID: Just a heads up, even the latest CentOS 7 package has the wrong IPv4 and v6 address. Version : 9.9.4 Release : 18.el7_1.1 Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mon, Nov 16, 2015 at 7:30 AM, Kash, Howard M CIV USARMY RDECOM ARL (US) < howard.m.kash.civ at mail.mil> wrote: > > Friendly reminder... > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kash, Howard M > CIV USARMY RDECOM > > ARL (US) > > Sent: Monday, August 31, 2015 12:39 PM > > To: nanog at nanog.org > > Subject: Advance notice - H-root address change on December 1, 2015 > > > > > > This is advance notice that there is a scheduled change to the IP > addresses > > for one of the authorities listed for the DNS root zone and the .ARPA > TLD. > > The change is to H.ROOT-SERVERS.NET, which is administered by the U.S. > Army > > Research Laboratory. > > > > The new IPv4 address for this authority is 198.97.190.53. > > > > The new IPv6 address for the authority is 2001:500:1::53. > > > > This change is anticipated to be implemented in the root zone on 1 > December > > 2015, however the new addresses are operational now. They will replace > the > > previous IP addresses of 128.63.2.53 and 2001:500:1::803f:235 (also > > previously known as AOS.BRL.MIL and AOS.ARL.ARMY.MIL). > > > > We encourage operators of DNS infrastructure to update any references to > the > > old IP addresses and replace them with the new addresses. In particular, > > many DNS resolvers have a DNS root "hints" file. This should be updated > with > > the new IP addresses. > > > > New hints files will be available at the following URLs once the change > has > > been formally executed on December 1: > > > > http://www.internic.net/domain/named.root > > http://www.internic.net/domain/named.cache > > > > The old IPv4 address will continue to work for six months after the > > transition (until 1 June 2016), at which point it will be retired from > > service. The address will remain under the control of the Army Research > > Laboratory, never to be used again for DNS service. The old IPv6 address > > will continue to work indefinitely, but may ultimately be retired from > > service. > > > > Simultaneous to the retirement of the old address on June 1, 2016, the > > ASN for H-root will change from 13 to 1508. > > > > You can monitor the transition of queries to the new addresses at the > > following URL: > > > > http://h.root-servers.org/old_vs_new.html > > > > > > -- > > Howard Kash > > U.S. Army Research Laboratory > From A.L.M.Buxey at lboro.ac.uk Mon Nov 16 16:19:39 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Mon, 16 Nov 2015 16:19:39 +0000 Subject: Advance notice - H-root address change on December 1, 2015 In-Reply-To: References: <8B01299690A8A94AB8629283FAFED8F1ACBA048A@umechpanz.easf.csd.disa.mil> <8B01299690A8A94AB8629283FAFED8F1C8BC596F@umechpanz.easf.csd.disa.mil> Message-ID: <20151116161939.GA3129@lboro.ac.uk> Hi, > Just a heads up, even the latest CentOS 7 package has the wrong IPv4 and v6 > address. whilst the new H-ROOT is alive now, the official switch-over date is 1st December 2015 and the old address will be available for 6 months after that....so if any BIND package comes out AFTER 1st December with old addresses in it, THEN complain/warn ;-) alan From shefys at gmail.com Mon Nov 16 17:43:03 2015 From: shefys at gmail.com (Yury Shefer) Date: Mon, 16 Nov 2015 09:43:03 -0800 Subject: Project Fi and the Great Firewall In-Reply-To: References: <208D7CF9-D840-4A09-8768-602778A762F1@arbor.net> Message-ID: With Wi-Fi calling it gets a bit more simplified (no "transit" operators in user plane) and may provide better privacy (only your home country will monitor your calls, lol). The UE establishes IPsec tunnel over the Internet to the home operator and uses it for native VoIP/messaging applications. On Sun, Nov 15, 2015 at 9:33 PM, Carlos Alcantar wrote: > > Similar to the SS7 phone network where call signaling data is done on a > totally different path then the actual rtp path. > > ? > 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 > > > ________________________________________ > From: NANOG on behalf of Jared Geiger < > jared at compuwizz.net> > Sent: Saturday, November 14, 2015 7:08 PM > To: NANOG > Subject: Re: Project Fi and the Great Firewall > > When you roam onto another cellular network other than your home network, > your data is encapsulated and sent back to your home network before going > out to the internet. This is to provide a seamless experience for the > customer. > > The network it rides on is the GRX/IPX which is a a worldwide MPLS network > that the GSMA specified to make the data roaming experience work. The > GRX/IPX also can carry voice and text back to the home network. Since it is > a separate network from the Internet, the Great Firewall was bypassed. > > There are several GRX/IPX providers and they all peer with each other in > key locations which usually end up being in the same major Internet peering > locations. TATA, Syniverse, SAP, Telia, and many others run an IPX/GRX > network and Equinix has IPX/GRX peering exchanges. > > The wikipedia articles will start you in the right direction for more > information: > https://en.wikipedia.org/wiki/GPRS_roaming_exchange > https://en.wikipedia.org/wiki/IP_exchange > > ~Jared > > On Sat, Nov 14, 2015 at 6:27 PM, Jake Mertel < > jake.mertel at ubiquityhosting.com> wrote: > > > I know the service/device uses VPN if you are using "wifi assist" to > > connect to an open WAP -- it automatically tunnels the traffic so it > can't > > be read by nearby snoopers. Perhaps they employ a similar technology or > are > > using something like PPP to take all of the traffic back to one (or many) > > "access servers" before sending it off to the Internet. I have no > > experience whatsoever in cellular network operations, but I know many > > providers employ similar methodologies to assist in meeting their CALEA > > requirements. > > > > On Saturday, November 14, 2015, Roland Dobbins > wrote: > > > > > On 15 Nov 2015, at 9:00, Sean Hunter wrote: > > > > > > While in China recently, I noticed that my Project Fi phone was > accessing > > >> Google. > > >> > > > > > > Accessing, or attempting to access? > > > > > > Were you using a local SIM card, or roaming w/data? What about WiFi? > > > > -- Best regards, Yury. From marka at isc.org Mon Nov 16 23:27:53 2015 From: marka at isc.org (Mark Andrews) Date: Tue, 17 Nov 2015 10:27:53 +1100 Subject: Advance notice - H-root address change on December 1, 2015 In-Reply-To: Your message of "Mon, 16 Nov 2015 16:19:39 -0000." <20151116161939.GA3129@lboro.ac.uk> References: <8B01299690A8A94AB8629283FAFED8F1ACBA048A@umechpanz.easf.csd.disa.mil> <8B01299690A8A94AB8629283FAFED8F1C8BC596F@umechpanz.easf.csd.disa.mil> <20151116161939.GA3129@lboro.ac.uk> Message-ID: <20151116232753.E54F63CC49E6@rock.dv.isc.org> In message <20151116161939.GA3129 at lboro.ac.uk>, A.L.M.Buxey at lboro.ac.uk writes: > Hi, > > > Just a heads up, even the latest CentOS 7 package has the wrong IPv4 and v6 > > address. > > whilst the new H-ROOT is alive now, the official switch-over date is 1st December 2015 > and the old address will be available for 6 months after that....so if any BIND package > comes out AFTER 1st December with old addresses in it, THEN complain/warn ;-) > > alan And given that built in values can be overridden there isn't even a need to do that. Josh, If you want to complain about something useful. Complain that CentOS is still at BIND 9.9.4 rather than BIND 9.9.8. You are missing bug fixes. We ship maintainence releases for a reason. This is like saying. We know there are 360 fixes between 9.9.4 and 9.9.8 and we don't think you are going to need any of them despite other people discovering these bugs. [rock:~/git/bind9] marka% git diff v9_9_4 v9_9_8 CHANGES | grep '^+[34]' | wc 360 3385 22807 [rock:~/git/bind9] marka% Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From A.L.M.Buxey at lboro.ac.uk Mon Nov 16 23:47:43 2015 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Mon, 16 Nov 2015 23:47:43 +0000 Subject: Advance notice - H-root address change on December 1, 2015 In-Reply-To: <20151116232753.E54F63CC49E6@rock.dv.isc.org> References: <8B01299690A8A94AB8629283FAFED8F1ACBA048A@umechpanz.easf.csd.disa.mil> <8B01299690A8A94AB8629283FAFED8F1C8BC596F@umechpanz.easf.csd.disa.mil> <20151116161939.GA3129@lboro.ac.uk> <20151116232753.E54F63CC49E6@rock.dv.isc.org> Message-ID: No. CentOS follows RedHat. They backport fixes to older versions rather than put the new version out. It appears that have aversion to new feature and just want to put the fixes onto the older versions. So that 9.9.4 probably has 60% of the changes that the diff of 9.9.4 has to 9.9.8 . This action confuses most. alan From marka at isc.org Tue Nov 17 00:16:26 2015 From: marka at isc.org (Mark Andrews) Date: Tue, 17 Nov 2015 11:16:26 +1100 Subject: Advance notice - H-root address change on December 1, 2015 In-Reply-To: Your message of "Mon, 16 Nov 2015 23:47:43 -0000." References: <8B01299690A8A94AB8629283FAFED8F1ACBA048A@umechpanz.easf.csd.disa.mil> <8B01299690A8A94AB8629283FAFED8F1C8BC596F@umechpanz.easf.csd.disa.mil> <20151116161939.GA3129@lboro.ac.uk> <20151116232753.E54F63CC49E6@rock.dv.isc.org> Message-ID: <20151117001626.7C9633CC5570@rock.dv.isc.org> In message , Alan Buxey writes: > > > No. CentOS follows RedHat. They backport fixes to older versions rather > than put the new version out. It appears that have aversion to new > feature and just want to put the fixes onto the older versions. So that > 9.9.4 probably has 60% of the changes that the diff of 9.9.4 has to 9.9.8 > . This action confuses most. > > alan The point of putting out maintainence releases is to fix bugs in the existing code not to introduce features. We leave features to the .0 releases. The [func] below are bug fixes / security fixes. Even with 60% of the changes one is missing a huge number of bug fixes. Mark diff --git a/CHANGES b/CHANGES index e3c5595..5929d64 100644 --- a/CHANGES +++ b/CHANGES @@ -1,8 +1,1220 @@ + --- 9.9.8 released --- + + --- 9.9.8rc1 released --- + +4193. [bug] Handle broken servers that return BADVERS incorrectly. + [RT #40427] + +4192. [bug] The default rrset-order of random was not always being + applied. [RT #40456] + +4191. [protocol] Accept DNS-SD non LDH PTR records in reverse zones + as per RFC 6763. [RT #37889] + +4190. [protocol] Accept Active Diretory gc._msdcs. name as + valid with check-names. still needs to be + LDH. [RT #40399] + +4189. [cleanup] Don't exit on overly long tokens in named.conf. + [RT #40418] + +4188. [bug] Support HTTP/1.0 client properly on the statistics + channel. [RT #40261] + +4187. [func] When any RR type implementation doesn't + implement totext() for the RDATA's wire + representation and returns ISC_R_NOTIMPLEMENTED, + such RDATA is now printed in unknown + presentation format (RFC 3597). RR types affected + include LOC(29) and APL(42). [RT #40317]. + +4183. [cleanup] Use timing-safe memory comparisons in cryptographic + code. Also, the timing-safe comparison functions have + been renamed to avoid possible confusion with + memcmp(). Thanks to Loganaden Velvindron of + AFRINIC. [RT #40148] + +4182. [cleanup] Use mnemonics for RR class and type comparisons. + [RT #40297] + +4181. [bug] Queued notify messages could be dequeued from the + wrong rate limiter queue. [RT #40350] + +4179. [bug] Fix double frees in getaddrinfo() in libirs. + [RT #40209] + +4178. [bug] Fix assertion failure in parsing UNSPEC(103) RR from + text. [RT #40274] + +4177. [bug] Fix assertion failure in parsing NSAP records from + text. [RT #40285] + +4176. [bug] Address race issues with lwresd. [RT #40284] + +4175. [bug] TKEY with GSS-API keys needed bigger buffers. + [RT #40333] + +4174. [bug] "dnssec-coverage -r" didn't handle time unit + suffixes correctly. [RT #38444] + +4173. [bug] dig +sigchase was not properly matching the trusted + key. [RT #40188] + +4172. [bug] Named / named-checkconf didn't handle a view of CLASS0. + [RT #40265] + +4171. [bug] Fixed incorrect class checks in TSIG RR + implementation. [RT #40287] + +4170. [security] An incorrect boundary check in the OPENPGPKEY + rdatatype could trigger an assertion failure. + (CVE-2015-5986) [RT #40286] + +4169. [test] Added a 'wire_test -d' option to read input as + raw binary data, for use as a fuzzing harness. + [RT #40312] + +4168. [security] A buffer accounting error could trigger an + assertion failure when parsing certain malformed + DNSSEC keys. (CVE-2015-5722) [RT #40212] + + --- 9.9.8b1 released --- + +4165. [security] A failure to reset a value to NULL in tkey.c could + result in an assertion failure. (CVE-2015-5477) + [RT #40046] + +4164. [bug] Don't rename slave files and journals on out of memory. + [RT #40033] + +4163. [bug] Address compiler warnings. [RT #40024] + +4162. [bug] httpdmgr->flags was not being initialized. [RT #40017] + +4159. [cleanup] Alphabetize dig's help output. [RT #39966] + +4158. [protocol] Support the printing of EDNS COOKIE and EXPIRE options. + [RT #39928] + +4154. [bug] A OPT record should be included with the FORMERR + response when there is a malformed EDNS option. + [RT #39647] + +4153. [bug] Check that non significant ECS bits are zero on + receipt. [RT #39647] + +4151. [bug] 'rndc flush' could cause a deadlock. [RT #39835] + +4150. [bug] win32: listen-on-v6 { any; }; was not working. Apply + minimal fix. [RT #39667] + +4149. [bug] Fixed a race condition in the getaddrinfo() + implementation in libirs. [RT #39899] + +4148. [bug] Fix a bug when printing zone names with '/' character + in XML and JSON statistics output. [RT #39873] + +4147. [bug] Filter-aaaa / filter-aaaa-on-v4 / filter-aaaa-on-v6 + was returning referrals rather than nodata responses + when the AAAA records were filtered. [RT #39843] + +4146. [bug] Address reference leak that could prevent a clean + shutdown. [RT #37125] + +4145. [bug] Not all unassociated adb entries where being printed. + [RT #37125] + +4143. [bug] serial-query-rate was not effective for notify. + [RT #39858] + +4142. [bug] rndc addzone with view specified saved NZF config + that could not be read back by named. This has now + been fixed. [RT #39845] + +4138. [security] An uninitialized value in validator.c could result + in an assertion failure. (CVE-2015-4620) [RT #39795] + +4137. [bug] Make rndc reconfig report configuration errors the + same way rndc reload does. [RT #39635] + +4132. [cleanup] dig: added +rd as a synonym for +recurse, + added +class as an unabbreviated alternative + to +cl. [RT #39686] + +4130. [bug] The compatibility shim for *printf() misprinted some + large numbers. [RT #39586] + +4129. [port] Address API changes in OpenSSL 1.1.0. [RT #39532] + +4128. [bug] Address issues raised by Coverity 7.6. [RT #39537] + +4127. [protocol] CDS and CDNSKEY need to be signed by the key signing + key as per RFC 7344, Section 4.1. [RT #37215] + +4123. [port] Added %z (size_t) format options to the portable + internal printf/sprintf implementation. [RT #39586] + +4118. [bug] Teach isc-config.sh about irs. [RT #39213] + +4117. [protocol] Add EMPTY.AS112.ARPA as per RFC 7534. + +4113. [test] Check for Net::DNS is some system test + prerequisites. [RT #39369] + +4112. [bug] Named failed to load when "root-delegation-only" + was used without a list of domains to exclude. + [RT #39380] + +4111. [doc] Alphabetize rndc man page. [RT #39360] + +4110. [bug] Address memory leaks / null pointer dereferences + on out of memory. [RT #39310] + +4109. [port] linux: support reading the local port range from + net.ipv4.ip_local_port_range. [RT # 39379] + +4107. [bug] Address potential deadlock when updating zone content. + [RT #39269] + +4106. [port] Improve readline support. [RT #38938] + +4105. [port] Misc fixes for Microsoft Visual Studio + 2015 CTP6 in 64 bit mode. [RT #39308] + +4104. [bug] Address uninitialized elements. [RT #39252] + +4102. [bug] Fix a use after free bug introduced in change + #4094. [RT #39281] + +4101. [bug] dig: the +split option didn't work with +short. + [RT #39291] + +4100. [bug] Inherited owernames on the line immediately following + a $INCLUDE were not working. [RT #39268] + +4099. [port] clang: make unknown commandline options hard errors + when determining what options are supported. + [RT #39273] + +4098. [bug] Address use-after-free issue when using a + predecessor key with dnssec-settime. [RT #39272] + +4097. [func] Add additional logging about xfrin transfer status. + [RT #39170] + +4096. [bug] Fix a use after free of query->sendevent. + [RT #39132] + +4094. [bug] A race during shutdown or reconfiguration could + cause an assertion in mem.c. [RT #38979] + +4091. [cleanup] Some cleanups in isc mem code. [RT #38896] + +4090. [bug] Fix a crash while parsing malformed CAA RRs in + presentation format, i.e., from text such as + from master files. Thanks to John Van de + Meulebrouck Brendgard for discovering and + reporting this problem. [RT #39003] + +4089. [bug] Send notifies immediately for slave zones during + startup. [RT #38843] + +4088. [port] Fixed errors when building with libressl. [RT #38899] + +4087. [bug] Fix a crash due to use-after-free due to sequencing + of tasks actions. [RT #38495] + +4085. [bug] ISC_PLATFORM_HAVEXADDQ could be inconsistently set. + [RT #38828] + +4084. [bug] Fix a possible race in updating stats counters. + [RT #38826] + +4082. [bug] Incrementally sign large inline zone deltas. + [RT #37927] + +4081. [cleanup] Use dns_rdatalist_init consistently. [RT #38759] + +4077. [test] Add static-stub regression test for DS NXDOMAIN + return making the static stub disappear. [RT #38564] + +4076. [bug] Named could crash on shutdown with outstanding + reload / reconfig events. [RT #38622] + +4075. [bug] Increase nsupdate's input buffer to accomodate + very large RRs. [RT #38689] + +4074. [cleanup] Cleaned up more warnings from gcc -Wshadow. [RT #38708] + +4073. [cleanup] Add libjson-c version number reporting to + "named -V"; normalize version number formatting. + [RT #38056] + +4072. [func] Add a --enable-querytrace configure switch for + very verbose query trace logging. (This option + has a negative performance impact and should be + used only for debugging.) [RT #37520] + +4070. [bug] Fix a segfault in nslookup in a query such as + "nslookup isc.org AMS.SNS-PB.ISC.ORG -all". + [RT #38548] + +4069. [doc] Reorganize options in the nsupdate man page. + [RT #38515] + +4067. [cleanup] Reduce noise from RRL when query logging is + disabled. [RT #38648] + +4066. [doc] Reorganize options in the dig man page. [RT #38516] + +4064. [contrib] dnssec-keyset.sh: Generates a specified number + of DNSSEC keys with timing set to implement a + pre-publication key rollover strategy. Thanks + to Jeffry A. Spain. [RT #38459] + +4063. [bug] Asynchronous zone loads were not handled + correctly when the zone load was already in + progress; this could trigger a crash in zt.c. + [RT #37573] + +4062. [bug] Fix an out-of-bounds read in RPZ code. If the + read succeeded, it doesn't result in a bug + during operation. If the read failed, named + could segfault. [RT #38559] + +3938. [func] Added quotas to be used in recursive resolvers + that are under high query load for names in zones + whose authoritative servers are nonresponsive or + are experiencing a denial of service attack. + + - "fetches-per-server" limits the number of + simultaneous queries that can be sent to any + single authoritative server. The configured + value is a starting point; it is automatically + adjusted downward if the server is partially or + completely non-responsive. The algorithm used to + adjust the quota can be configured via the + "fetch-quota-params" option. + - "fetches-per-zone" limits the number of + simultaneous queries that can be sent for names + within a single domain. (Note: Unlike + "fetches-per-server", this value is not + self-tuning.) + - New stats counters have been added to count + queries spilled due to these quotas. + + These options are not available by default; + use "configure --enable-fetchlimit" (or + --enable-developer) to include them in the build. + + See the ARM for details of these options. [RT #37125] + +3937. [func] Added some debug logging to better indicate the + conditions causing SERVFAILs when resolving. + [RT #35538] + + --- 9.9.7 released --- + + --- 9.9.7rc2 released --- + +4061. [bug] Handle timeout in legacy system test. [RT #38573] + +4060. [bug] dns_rdata_freestruct could be called on a + uninitialized structure when handling a error. + [RT #38568] + +4059. [bug] Addressed valgrind warnings. [RT #38549] + +4058. [bug] UDP dispatches could use the wrong pseudorandom + number generator context. [RT #38578] + +4056. [bug] Fixed several small bugs in automatic trust anchor + management, including a memory leak and a possible + loss of key state information. [RT #38458] + +4057. [bug] 'dnssec-dsfromkey -T 0' failed to add ttl field. + [RT #38565] + +4053. [security] Revoking a managed trust anchor and supplying + an untrusted replacement could cause named + to crash with an assertion failure. + (CVE-2015-1349) [RT #38344] + +4052. [bug] Fix a leak of query fetchlock. [RT #38454] + +4050. [bug] RPZ could send spurious SERVFAILs in response + to duplicate queries. [RT #38510] + +4049. [bug] CDS and CDNSKEY had the wrong attributes. [RT #38491] + +4048. [bug] adb hash table was not being grown. [RT #38470] + + --- 9.9.7rc1 released --- + +4047. [cleanup] "named -V" now reports the current running versions + of OpenSSL and the libxml2 libraries, in addition to + the versions that were in use at build time. + +4046. [bug] Accounting of "total use" in memory context + statistics was not correct. [RT #38370] + +4045. [bug] Skip to next master on dns_request_createvia4 failure. + [RT #25185] + +4044. [bug] Change 3955 was not complete, resulting in an assertion + failure if the timing was just right. [RT #38352] + +4039. [cleanup] Cleaned up warnings from gcc -Wshadow. [RT #37381] + +4038. [bug] Add 'rpz' flag to node and use it to determine whether + to call dns_rpz_delete. This should prevent unbalanced + add / delete calls. [RT #36888] + +4037. [bug] also-notify was ignoring the tsig key when checking + for duplicates resulting in some expected notify + messages not being sent. [RT #38369] + +4035. [bug] Close temporary and NZF FILE pointers before moving + the former into the latter's place, as required on + Windows. [RT #38332] + +4032. [bug] Built-in "empty" zones did not correctly inherit the + "allow-transfer" ACL from the options or view. + [RT #38310] + +4031. [bug] named-checkconf -z failed to report a missing file + with a hint zone. [RT #38294] + +4028. [bug] $GENERATE with a zero step was not being caught as a + error. A $GENERATE with a / but no step was not being + caught as a error. [RT #38262] + +3973. [test] Added hooks for Google Performance Tools CPU profiler, + including real-time/wall-clock profiling. Use + "configure --with-gperftools-profiler" to enable. + [RT #37339] + + --- 9.9.7b1 released --- + +4027. [port] Net::DNS 0.81 compatibility. [RT #38165] + +4026. [bug] Fix RFC 3658 reference in dig +sigchase. [RT #38173] + +4025. [port] bsdi: failed to build. [RT #38047] + +4024. [bug] dns_rdata_opt_first, dns_rdata_opt_next, + dns_rdata_opt_current, dns_rdata_txt_first, + dns_rdata_txt_next and dns_rdata_txt_current were + documented but not implemented. These have now been + implemented. + + dns_rdata_spf_first, dns_rdata_spf_next and + dns_rdata_spf_current were documented but not + implemented. The prototypes for these + functions have been removed. [RT #38068] + +4023. [bug] win32: socket handling with explicit ports and + invoking named with -4 was broken for some + configurations. [RT #38068] + +4021. [bug] Adjust max-recursion-queries to accommodate + the need for more queries when the cache is + empty. [RT #38104] + +4020. [bug] Change 3736 broke nsupdate's SOA MNAME discovery + resulting in updates being sent to the wrong server. + [RT #37925] + +4019. [func] If named is not configured to validate the answer + then allow fallback to plain DNS on timeout even + when we know the server supports EDNS. [RT #37978] + +4018. [bug] Fall back to plain DNS when EDNS queries are being + dropped was failing. [RT #37965] + +4017. [test] Add system test to check lookups to legacy servers + with broken DNS behavior. [RT #37965] + +4016. [bug] Fix a dig segfault due to bad linked list usage. + [RT #37591] + +4015. [bug] Nameservers that are skipped due to them being + CNAMEs were not being logged. They are now logged + to category 'cname' as per BIND 8. [RT #37935] + +4014. [bug] When including a master file origin_changed was + not being properly set leading to a potentially + spurious 'inherited owner' warning. [RT #37919] + +4012. [bug] Check returned status of OpenSSL digest and HMAC + functions when they return one. Note this applies + only to FIPS capable OpenSSL libraries put in + FIPS mode and MD5. [RT #37944] + +4011. [bug] master's list port inheritance was not properly + implemented. [RT #37792] + +4007. [doc] Remove acl forward reference restriction. [RT #37772] + +4006. [security] A flaw in delegation handling could be exploited + to put named into an infinite loop. This has + been addressed by placing limits on the number + of levels of recursion named will allow (default 7), + and the number of iterative queries that it will + send (default 50) before terminating a recursive + query (CVE-2014-8500). + + The recursion depth limit is configured via the + "max-recursion-depth" option, and the query limit + via the "max-recursion-queries" option. [RT #37580] + +4004. [bug] When delegations had AAAA glue but not A, a + reference could be leaked causing an assertion + failure on shutdown. [RT #37796] + +4000. [bug] NXDOMAIN redirection incorrectly handled NXRRSET + from the redirect zone. [RT #37722] + +3998. [bug] isc_radix_search was returning matches that were + too precise. [RT #37680] + +3997. [protocol] Add OPENGPGKEY record. [RT# 37671] + +3996. [bug] Address use after free on out of memory error in + keyring_add. [RT #37639] + +3995. [bug] receive_secure_serial holds the zone lock for too + long. [RT #37626] + +3990. [testing] Add tests for unknown DNSSEC algorithm handling. + [RT #37541] + +3989. [cleanup] Remove redundant dns_db_resigned calls. [RT #35748] + +3987. [func] Handle future Visual Studio 14 incompatible changes. + [RT #37380] + +3986. [doc] Add the BIND version number to page footers + in the ARM. [RT #37398] + +3985. [doc] Describe how +ndots and +search interact in dig. + [RT #37529] + +3982. [doc] Include release notes in product documentation. + [RT #37272] + +3981. [bug] Cache DS/NXDOMAIN independently of other query types. + [RT #37467] + +3978. [test] Added a unit test for Diffie-Hellman key + computation, completing change #3974. [RT #37477] + +3976. [bug] When refreshing managed-key trust anchors, clear + any cached trust so that they will always be + revalidated with the current set of secure + roots. [RT #37506] + +3974. [bug] Handle DH_compute_key() failure correctly in + openssldh_link.c. [RT #37477] + +3972. [bug] Fix host's usage statement. [RT #37397] + +3971. [bug] Reduce the cascading failures due to a bad $TTL line + in named-checkconf / named-checkzone. [RT #37138] + +3970. [contrib] Fixed a use after free bug in the SDB LDAP driver. + [RT #37237] + +3968. [bug] Silence spurious log messages when using 'named -[46]'. + [RT #37308] + +3967. [test] Add test for inlined signed zone in multiple views + with different DNSKEY sets. [RT #35759] + +3966. [bug] Missing dns_db_closeversion call in receive_secure_db. + [RT #35746] + +3962. [bug] 'dig +topdown +trace +sigchase' address unhandled error + conditions. [RT #34663] + +3961. [bug] Forwarding of SIG(0) signed UPDATE messages failed with + BADSIG. [RT #37216] + +3960. [bug] 'dig +sigchase' could loop forever. [RT #37220] + +3959. [bug] Updates could be lost if they arrived immediately + after a rndc thaw. [RT #37233] + +3958. [bug] Detect when writeable files have multiple references + in named.conf. [RT #37172] + +3957. [bug] "dnssec-keygen -S" failed for ECCGOST, ECDSAP256SHA256 + and ECDSAP384SHA384. [RT #37183] + +3955. [bug] Notify messages due to changes are no longer queued + behind startup notify messages. [RT #24454] + +3954. [bug] Unchecked mutex init in dlz_dlopen_driver.c [RT #37112] + +3953. [bug] Don't escape semi-colon in TXT fields. [RT #37159] + +3952. [bug] dns_name_fullcompare failed to set *nlabelsp when the + two name pointers were the same. [RT #37176] + + --- 9.9.6 released --- + +3950. [port] Changed the bin/python Makefile to work around a + bmake bug in FreeBSD 10 and NetBSD 6. [RT #36993] + + --- 9.9.6rc2 released --- + +3947. [cleanup] Set the executable bit on libraries when using + libtool. [RT #36786] + +3946. [cleanup] Improved "configure" search for a python interpreter. + [RT #36992] + +3945. [bug] Invalid wildcard expansions could be incorrectly + accepted by the validator. [RT #37093] + +3944. [test] Added a regression test for "server-id". [RT #37057] + +3942. [bug] Wildcard responses from a optout range should be + marked as insecure. [RT #37072] + +3941. [doc] Include the BIND version number in the ARM. [RT #37067] + + --- 9.9.6rc1 released --- + +3933. [bug] Corrected the implementation of dns_rdata_casecompare() + for the HIP rdata type. [RT #36911] + +3932. [test] Improved named-checkconf tests. [RT #36911] + +3931. [cleanup] Cleanup how dlz grammar is defined. [RT #36879] + +3929. [bug] 'host -a' needed to clear idnoptions. [RT #36963] + +3928. [test] Improve rndc system test. [RT #36898] + +3925. [bug] DS lookup of RFC 1918 empty zones failed. [RT #36917] + +3924. [bug] Improve 'rndc addzone' error reporting. [RT #35187] + +3923. [bug] Sanity check the xml2-config output. [RT #22246] + +3922. [bug] When resigning, dnssec-signzone was removing + all signatures from delegation nodes. It now + retains DS and (if applicable) NSEC signatures. + [RT #36946] + +3921. [bug] AD was inappropriately set on RPZ responses. [RT #36833] + +3919. [bug] dig: continue to next line if a address lookup fails + in batch mode. [RT #36755] + +3918. [doc] Update check-spf documentation. [RT #36910] + +3917. [bug] dig, nslookup and host now continue on names that are + too long after applying a search list elements. + [RT #36892] + +3916. [contrib] zone2sqlite checked wrong result code. Address + compiler warnings. [RT #36931] + + --- 9.9.6b2 released --- + +3914. [bug] Allow the URI target and CAA value fields to + be zero length. [RT #36737] + +3913. [bug] Address race issue in dispatch. [RT #36731] + +3910. [bug] Fix races to free event during shutdown. [RT #36720] + +3909. [bug] When computing the number of elements required for a + acl count_acl_elements could have a short count leading + to a assertion failure. Also zero out new acl elements + in dns_acl_merge. [RT #36675] + +3908. [bug] rndc now differentiates between a zone in multiple + views and a zone that doesn't exist at all. [RT #36691] + +3907. [cleanup] Alphabetize rndc help. [RT #36683] + +3906. [protocol] Update URI record format to comply with + draft-faltstrom-uri-08. [RT #36642] + +3905. [bug] Address deadlock between view.c and adb.c. [RT #36341] + +3904. [func] Add the RPZ SOA to the additional section. [RT36507] + +3903. [bug] Improve the accuracy of DiG's reported round trip + time. [RT 36611] + +3902. [bug] liblwres wasn't handling link-local addresses in + nameserver clauses in resolv.conf. [RT #36039] + +3901. [protocol] Added support for CAA record type (RFC 6844). + [RT #36625] + +3900. [bug] Fix a crash in PostgreSQL DLZ driver. [RT #36637] + +3899. [bug] "request-ixfr" is only applicable to slave and redirect + zones. [RT #36608] + +3898. [bug] Too small a buffer in tohexstr() calls in test code. + [RT #36598] + +3894. [bug] Buffers in isc_print_vsnprintf were not properly + initialized leading to potential overflows when + printing out quad values. [RT #36505] + +3892. [bug] Setting '-t aaaa' in .digrc had unintended side + effects. [RT #36452] + +3891. [bug] Use ${INSTALL_SCRIPT} rather than ${INSTALL_PROGRAM} + to install python programs. + +3890. [bug] RRSIG sets that were not loaded in a single transaction + at start up where not being correctly added to + re-signing heaps. [RT #36302] + +3889. [port] hurd: configure fixes as per: + https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746540 + +3887. [cleanup] Make all static symbols in rbtdb64 end in "64" so + they are easier to use in a debugger. [RT #36373] + + --- 9.9.6b1 released --- + +3885. [port] Use 'open()' rather than 'file()' to open files in + python. + +3884. [protocol] Add CDS and CDNSKEY record types. [RT #36333] + +3881. [bug] Address memory leak with UPDATE error handling. + [RT #36303] + +3880. [test] Update ans.pl to work with new TSIG support in + Net::DNS; add additional Net::DNS version prerequisite + checks. [RT #36327] + +3879. [func] Add version printing option to various BIND utilities. + [RT #10686] + +3878. [bug] Using the incorrect filename for a DLZ module + caused a segmentation fault on startup. [RT #36286] + +3874. [test] Check that only "check-names master" is needed for + updates to be accepted. + +3873. [protocol] Only warn for SPF without TXT spf record. [RT #36210] + +3872. [bug] Address issues found by static analysis. [RT #36209] + +3871. [bug] Don't publish an activated key automatically before + its publish time. [RT #35063] + +3868. [bug] isc_mem_setwater incorrectly cleared hi_called + potentially leaving over memory cleaner running. + [RT #35270] + +3866. [bug] Named could die on disk full in generate_session_key. + [RT #36119] + +3864. [bug] RPZ didn't work well when being used as forwarder. + [RT #36060] + +3862. [cleanup] Return immediately if we are not going to log the + message in ns_client_dumpmessage. + +3861. [bug] Benign missing isc_buffer_availablelength check in + dns_message_pseudosectiontotext. [RT #36078] + +3860. [bug] ioctl(DP_POLL) array size needs to be determined + at run time as it is limited to {OPEN_MAX}. + [RT #35878] + +3858. [bug] Disable GCC 4.9 "delete null pointer check". + [RT #35968] + +3857. [bug] Make it harder for a incorrect NOEDNS classification + to be made. [RT #36020] + +3855. [bug] Limit smoothed round trip time aging to no more than + once a second. [RT #32909] + +3854. [cleanup] Report unrecognized options, if any, in the final + configure summary. [RT #36014] + +3853. [cleanup] Refactor dns_rdataslab_fromrdataset to separate out + the handling of a rdataset with no records. [RT #35968] + +3849. [doc] Alphabetized dig's +options. [RT #35992] + +3847. [bug] 'configure --with-dlz-postgres' failed to fail when + there is not support available. + +3846. [bug] "dig +notcp ixfr=" should result in a UDP + ixfr query. [RT #35980] + +3844. [bug] Use the x64 version of the Microsoft Visual C++ + Redistributable when built for 64 bit Windows. + [RT #35973] + +3843. [protocol] Check EDNS EXPIRE option in dns_rdata_fromwire. + [RT #35969] + +3842. [bug] Adjust RRL log-only logging category. [RT #35945] + +3841. [cleanup] Refactor zone.c:add_opt to use dns_message_buildopt. + [RT #35924] + +3840. [port] Check for arc4random_addrandom() before using it; + it's been removed from OpenBSD 5.5. [RT #35907] + +3839. [test] Use only posix-compatible shell in system tests. + [RT #35625] + +3838. [protocol] EDNS EXPIRE as been assigned a code point of 9. + +3836. [bug] Address C++ keyword usage in header file. + +3834. [bug] The re-signing heaps were not being updated soon enough + leading to multiple re-generations of the same RRSIG + when a zone transfer was in progress. [RT #35273] + +3833. [bug] Cross compiling was broken due to calling genrandom at + build time. [RT #35869] + +3827. [contrib] The example DLZ driver (a version of which is + also used in the dlzexternal system test) could + use absolute names as relative. [RT #35802] + +3826. [bug] Corrected bad INSIST logic in isc_radix_remove(). + [RT #35870] + +3825. [bug] Address sign extension bug in isc_regex_validate. + [RT #35758] + +3824. [bug] A collision between two flag values could cause + problems with cache cleaning. [RT #35858] + +3822. [bug] Log the correct type of static-stub zones when + removing them. [RT #35842] + +3819. [bug] NSEC3 hashes need to be able to be entered and + displayed without padding. This is not a issue for + currently defined algorithms but may be for future + hash algorithms. [RT #27925] + +3818. [bug] Stop lying to the optimizer that 'void *arg' is a + constant in isc_event_allocate. + +3815. [doc] Clarify "nsupdate -y" usage in man page. [RT #35808] + +3809. [doc] Fix NSID documentation. + +3807. [bug] Fix sign extension bug in dns_name_fromtext when + lowercase is set. [RT #35743] + +3806. [test] Improved system test portability. [RT #35625] + +3805. [contrib] Added contrib/perftcpdns, a performance testing tool + for DNS over TCP. [RT #35710] + +3804. [bug] Corrected a race condition in dispatch.c in which + portentry could be reset leading to an assertion + failure in socket_search(). (Change #3708 + addressed the same issue but was incomplete.) + [RT #35128] + +3803. [bug] "named-checkconf -z" incorrectly rejected zones + using alternate data sources for not having a "file" + option. [RT #35685] + +3802. [bug] Various header files were not being installed. + +3801. [port] Fix probing for gssapi support on FreeBSD. [RT #35615] + +3799. [bug] Improve named's command line error reporting. + [RT #35603] + +3796. [bug] Register dns error codes. [RT #35629] + +3795. [bug] Make named-checkconf detect raw masterfiles for + hint zones and reject them. [RT #35268] + +3794. [maint] Added AAAA for C.ROOT-SERVERS.NET. + +3793. [bug] zone.c:save_nsec3param() could assert when out of + memory. [RT #35621] + +3792. [func] Provide links to the alternate statistics views when + displaying in a browser. [RT #35605] + +3791. [bug] solaris: remove extraneous return. [RT #35589] + +3787. [bug] The code that checks whether "auto-dnssec" is + allowed was ignoring "allow-update" ACLs set at + the options or view level. [RT #29536] + +3780. [bug] $GENERATE handled negative numbers incorrectly. + [RT #25528] + +3779. [cleanup] Clarify the error message when using an option + that was not enabled at compile time. [RT #35504] + +3778. [bug] Log a warning when the wrong address family is + used in "listen-on" or "listen-on-v6". [RT #17848] + +3775. [bug] dlz_dlopen driver could return the wrong error + code on API version mismatch, leading to a segfault. + [RT #35495] + +3773. [func] "host", "nslookup" and "nsupdate" now have + options to print the version number and exit. + [RT #26057] + +3770. [bug] "dig +trace" could fail with an assertion when it + needed to fall back to TCP due to a truncated + response. [RT #24660] + +3769. [doc] Improved documentation of "rndc signing -list". + [RT #30652] + +3768. [bug] "dnssec-checkds" was missing the SHA-384 digest + algorithm. [RT #34000] + +3767. [func] Log explicitly when using rndc.key to configure + command channel. [RT #35316] + +3765. [bug] Fixed a bug in "rndc secroots" that could crash + named when dumping an empty keynode. [RT #35469] + +3764. [bug] The dnssec-keygen/settime -S and -i options + (to set up a successor key and set the prepublication + interval) were missing from dnssec-keyfromlabel. + [RT #35394] + +3761. [bug] Address dangling reference bug in dns_keytable_add. + [RT #35471] + +3757. [port] Enable Python tools (dnssec-coverage, + dnssec-checkds) to run on Windows. [RT #34355] + +3756. [bug] GSSAPI Kerberos realm checking was broken in + check_config leading to spurious messages being + logged. [RT #35443] + +3754. [cleanup] win32: Installer now places files in the + Program Files area rather than system services. + [RT #35361] + +3753. [bug] allow-notify was ignoring keys. [RT #35425] + +3751. [tuning] The default setting for the -U option (setting + the number of UDP listeners per interface) has + been adjusted to improve performance. [RT #35417] + +3747. [bug] A race condition could lead to a core dump when + destroying a resolver fetch object. [RT #35385] + +3743. [bug] delegation-only flag wasn't working in forward zone + declarations despite being documented. This is + needed to support turning off forwarding and turning + on delegation only at the same name. [RT #35392] + +3742. [port] linux: libcap support: declare curval at start of + block. [RT #35387] + +3740. [contrib] Minor fixes to configure --with-dlz-bdb, + --with-dlz-postgres and --with-dlz-odbc. [RT #35340] + +3737. [bug] 'rndc retransfer' could trigger a assertion failure + with inline zones. [RT #35353] + +3736. [bug] nsupdate: When specifying a server by name, + fall back to alternate addresses if the first + address for that name is not reachable. [RT #25784] + +3734. [bug] Improve building with libtool. [RT #35314] + +3732. [contrib] Fixed a type mismatch causing the ODBC DLZ + driver to dump core on 64-bit systems. [RT #35324] + +3731. [func] Added a "no-case-compress" ACL, which causes + named to use case-insensitive compression + (disabling change #3645) for specified + clients. (This is useful when dealing + with broken client implementations that + use case-sensitive name comparisons, + rejecting responses that fail to match the + capitalization of the query that was sent.) + [RT #35300] + +3730. [cleanup] Added "never" as a synonym for "none" when + configuring key event dates in the dnssec tools. + [RT #35277] + +3729. [bug] dnssec-keygen could set the publication date + incorrectly when only the activation date was + specified on the command line. [RT #35278] + +3724. [bug] win32: Fixed a bug that prevented dig and + host from exiting properly after completing + a UDP query. [RT #35288] + +3720. [bug] Address compiler warnings. [RT #35261] + +3719. [bug] Address memory leak in in peer.c. [RT #35255] + +3718. [bug] A missing ISC_LINK_INIT in log.c. [RT #35260] + +3714. [test] System tests that need to test for cryptography + support before running can now use a common + "testcrypto.sh" script to do so. [RT #35213] + +3713. [bug] Save memory by not storing "also-notify" addresses + in zone objects that are configured not to send + notify requests. [RT #35195] + + --- 9.9.5 released --- + + --- 9.9.5rc2 released --- + +3710. [bug] Address double dns_zone_detach when switching to + using automatic empty zones from regular zones. + [RT #35177] + +3709. [port] Use built-in versions of strptime() and timegm() + on all platforms to avoid portability issues. + [RT #35183] + +3708. [bug] Address a portentry locking issue in dispatch.c. + [RT #35128] + +3707. [bug] irs_resconf_load now returns ISC_R_FILENOTFOUND + on a missing resolv.conf file and initializes the + structure as if it had been configured with: + + nameserver ::1 + nameserver 127.0.0.1 + + Note: Callers will need to be updated to treat + ISC_R_FILENOTFOUND as a qualified success or else + they will leak memory. The following code fragment + will work with both old and new versions without + changing the behaviour of the existing code. + + resconf = NULL; + result = irs_resconf_load(mctx, "/etc/resolv.conf", + &resconf); + if (result != ISC_SUCCESS) { + if (resconf != NULL) + irs_resconf_destroy(&resconf); + .... + } + + [RT #35194] + +3706. [contrib] queryperf: Fixed a possible integer overflow when + printing results. [RT #35182] + +3704. [protocol] Accept integer timestamps in RRSIG records. [RT #35185] + + --- 9.9.5rc1 released --- + +3701. [func] named-checkconf can now obscure shared secrets + when printing by specifying '-x'. [RT #34465] + +3699. [bug] Improvements to statistics channel XSL stylesheet: + the stylesheet can now be cached by the browser; + section headers are omitted from the stats display + when there is no data in those sections to be + displayed; counters are now right-justified for + easier readability. (Only available with + configure --enable-newstats.) [RT #35117] + +3698. [cleanup] Replaced all uses of memcpy() with memmove(). + [RT #35120] + +3697. [bug] Handle "." as a search list element when IDN support + is enabled. [RT #35133] + +3696. [bug] dig failed to handle AXFR style IXFR responses which + span multiple messages. [RT #35137] + +3695. [bug] Address a possible race in dispatch.c. [RT #35107] + +3694. [bug] Warn when a key-directory is configured for a zone, + but does not exist or is not a directory. [RT #35108] + +3693. [security] memcpy was incorrectly called with overlapping + ranges resulting in malformed names being generated + on some platforms. This could cause INSIST failures + when serving NSEC3 signed zones (CVE-2014-0591). + [RT #35120] + +3692. [bug] Two calls to dns_db_getoriginnode were fatal if there + was no data at the node. [RT #35080] + +3690. [bug] Iterative responses could be missed when the source + port for an upstream query was the same as the + listener port (53). [RT #34925] + +3689. [bug] Fixed a bug causing an insecure delegation from one + static-stub zone to another to fail with a broken + trust chain. [RT #35081] + + --- 9.9.5b1 released --- + +3688. [bug] loadnode could return a freed node on out of memory. + [RT #35106] + +3687. [bug] Address null pointer dereference in zone_xfrdone. + [RT #35042] + +3686. [func] "dnssec-signzone -Q" drops signatures from keys + that are still published but no longer active. + [RT #34990] + +3685. [bug] "rndc refresh" didn't work correctly with slave + zones using inline-signing. [RT #35105] + +3683. [cleanup] Add a more detailed "not found" message to rndc + commands which specify a zone name. [RT #35059] + +3682. [bug] Correct the behavior of rndc retransfer to allow + inline-signing slave zones to retain NSEC3 parameters + instead of reverting to NSEC. [RT #34745] + +3681. [port] Update the Windows build system to support feature + selection and WIN64 builds. This is a work in + progress. [RT #34160] + +3679. [bug] dig could fail to clean up TCP sockets still + waiting on connect(). [RT #35074] + +3678. [port] Update config.guess and config.sub. [RT #35060] + +3677. [bug] 'nsupdate' leaked memory if 'realm' was used multiple + times. [RT #35073] + +3676. [bug] "named-checkconf -z" now checks zones of type + hint and redirect as well as master. [RT #35046] + +3675. [misc] Provide a place for third parties to add version + information for their extensions in the version + file by setting the EXTENSIONS variable. + +3674. [bug] RPZ zeroed ttls if the query type was '*'. [RT #35026] + +3672. [func] Local address can now be specified when using + dns_client API. [RT #34811] + +3671. [bug] Don't allow dnssec-importkey overwrite a existing + non-imported private key. + +3670. [bug] Address read after free in server side of + lwres_getrrsetbyname. [RT #29075] + +3669. [port] freebsd: --with-gssapi needs -lhx509. [RT #35001] + +3668. [bug] Fix cast in lex.c which could see 0xff treated as eof. + [RT #34993] + +3667. [test] dig: add support to keep the TCP socket open between + successive queries (+[no]keepopen). [RT #34918] + +3665. [bug] Failure to release lock on error in receive_secure_db. + [RT #34944] + +3664. [bug] Updated OpenSSL PKCS#11 patches to fix active list + locking and other bugs. [RT #34855] + +3663. [bug] Address bugs in dns_rdata_fromstruct and + dns_rdata_tostruct for WKS and ISDN types. [RT #34910] + +3662. [bug] 'host' could die if a UDP query timed out. [RT #34870] + +3661. [bug] Address lock order reversal deadlock with inline zones. + [RT #34856] + +3660. [cleanup] Changed the name of "isc-config.sh" to "bind9-config". + [RT #23825] + +3659. [port] solaris: don't add explicit dependencies/rules for + python programs as make won't use the implicit rules. + [RT #34835] + +3658. [port] linux: Address platform specific compilation issue + when libcap-devel is installed. [RT #34838] + +3657. [port] Some readline clones don't accept NULL pointers when + calling add_history. [RT #34842] + +3656. [security] Treat an all zero netmask as invalid when generating + the localnets acl. (The prior behavior could + allow unexpected matches when using some versions + of Winsock: CVE-2013-6320.) [RT #34687] + +3655. [cleanup] Simplify TCP message processing when requesting a + zone transfer. [RT #34825] + +3654. [bug] Address race condition with manual notify requests. + [RT #34806] + +3653. [func] Create delegations for all "children" of empty zones + except "forward first". [RT #34826] + +3651. [tuning] Adjust when a master server is deemed unreachable. + [RT #27075] + +3650. [tuning] Use separate rate limiting queues for refresh and + notify requests. [RT #30589] + +3649. [cleanup] Include a comment in .nzf files, giving the name of + the associated view. [RT #34765] + +3648. [test] Updated the ATF test framework to version 0.17. + [RT #25627] + +3647. [bug] Address a race condition when shutting down a zone. + [RT #34750] + +3646. [bug] Journal filename string could be set incorrectly, + causing garbage in log messages. [RT #34738] + +3645. [protocol] Use case sensitive compression when responding to + queries. [RT #34737] + +3644. [protocol] Check that EDNS subnet client options are well formed. + [RT #34718] + +3642. [func] Allow externally generated DNSKEY to be imported + into the DNSKEY management framework. A new tool + dnssec-importkey is used to do this. [RT #34698] + +3641. [bug] Handle changes to sig-validity-interval settings + better. [RT #34625] + +3640. [bug] ndots was not being checked when searching. Only + continue searching on NXDOMAIN responses. Add the + ability to specify ndots to nslookup. [RT #34711] + +3639. [bug] Treat type 65533 (KEYDATA) as opaque except when used + in a key zone. [RT #34238] + --- 9.9.4 released --- -- 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 Tue Nov 17 00:55:31 2015 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 16 Nov 2015 19:55:31 -0500 Subject: Advance notice - H-root address change on December 1, 2015 In-Reply-To: <20151117001626.7C9633CC5570@rock.dv.isc.org> References: <8B01299690A8A94AB8629283FAFED8F1ACBA048A@umechpanz.easf.csd.disa.mil> <8B01299690A8A94AB8629283FAFED8F1C8BC596F@umechpanz.easf.csd.disa.mil> <20151116161939.GA3129@lboro.ac.uk> <20151116232753.E54F63CC49E6@rock.dv.isc.org> <20151117001626.7C9633CC5570@rock.dv.isc.org> Message-ID: <31326625-8723-4097-890E-153BB2F512E8@puck.nether.net> This action by red hat is nice from a stability perspective but infuriates many standards derived folks like ISC/BIND and NTP amongst others as a version number means something to them. This dialogue is typically broken from both sides as expectations are different and bug reports get lost between the OS packaging and the supplier packaging. Sometimes this is good other times it can be quite bad. I would prefer to see fewer variants and better bug fixes across the board but the enterprise side often want a specific version number and expect fixes that the upstream maintainers don't want to keep the same version numbering for "that fix" or add a stealth feature and red hat may not want to pick it up... Not saying who is right or wrong but these views sometimes drive the intractable situation where 4.2.6 is shipped for NTP from red hat (as example) but it is EOL from the NTP.org folks. The good news is most people don't need all 13 hints, or more when you consider them dual stacked like all new DNS servers are :-) Either way it's confusing to everyone involved and why I generally track fedora myself. Jared Mauch > On Nov 16, 2015, at 7:16 PM, Mark Andrews wrote: > > > In message , Alan Buxey writes: >> No. CentOS follows RedHat. They backport fixes to older versions rather >> than put the new version out. It appears that have aversion to new >> feature and just want to put the fixes onto the older versions. So that >> 9.9.4 probably has 60% of the changes that the diff of 9.9.4 has to 9.9.8 >> . This action confuses most. >> >> alan > > The point of putting out maintainence releases is to fix bugs in > the existing code not to introduce features. We leave features to > the .0 releases. The [func] below are bug fixes / security fixes. > > Even with 60% of the changes one is missing a huge number of bug > fixes. From stenn at nwtime.org Tue Nov 17 02:20:36 2015 From: stenn at nwtime.org (Harlan Stenn) Date: Mon, 16 Nov 2015 18:20:36 -0800 Subject: Advance notice - H-root address change on December 1, 2015 In-Reply-To: <31326625-8723-4097-890E-153BB2F512E8@puck.nether.net> References: <8B01299690A8A94AB8629283FAFED8F1ACBA048A@umechpanz.easf.csd.disa.mil> <8B01299690A8A94AB8629283FAFED8F1C8BC596F@umechpanz.easf.csd.disa.mil> <20151116161939.GA3129@lboro.ac.uk> <20151116232753.E54F63CC49E6@rock.dv.isc.org> <20151117001626.7C9633CC5570@rock.dv.isc.org> <31326625-8723-4097-890E-153BB2F512E8@puck.nether.net> Message-ID: <564A8EF4.5090605@nwtime.org> On 11/16/15 4:55 PM, Jared Mauch wrote: > This action by red hat is nice from a stability perspective but > infuriates many standards derived folks like ISC/BIND and NTP amongst > others as a version number means something to them. > > This dialogue is typically broken from both sides as expectations are > different and bug reports get lost between the OS packaging and the > supplier packaging. Sometimes this is good other times it can be > quite bad. > > I would prefer to see fewer variants and better bug fixes across the > board but the enterprise side often want a specific version number > and expect fixes that the upstream maintainers don't want to keep the > same version numbering for "that fix" or add a stealth feature and > red hat may not want to pick it up... > > Not saying who is right or wrong but these views sometimes drive the > intractable situation where 4.2.6 is shipped for NTP from red hat (as > example) but it is EOL from the NTP.org folks. Red Hat has known for YEARS that we only have the resources to support one stable code branch, and that if they want support for older versions we can offer that at cost. Nobody has ever approached us about support for older releases of NTP. The folks who scream the loudest about our not supporting older releases are the folks who charge their customers money for support. These same companies do nothing to support us. Anybody can see the list of companies that support NTP at: http://nwtime.org/current-members-donors/ The free software companies listed there do not give us any money. >> On Nov 16, 2015, at 7:16 PM, Mark Andrews wrote: >> >> The point of putting out maintainence releases is to fix bugs in >> the existing code not to introduce features. We leave features to >> the .0 releases. The [func] below are bug fixes / security fixes. >> >> Even with 60% of the changes one is missing a huge number of bug >> fixes. In NTP's case, we fixed over 1100 things between 4.2.6 and 4.2.8. Skippy (Harlan'e evil twin brother) From bjorn at mork.no Tue Nov 17 09:28:40 2015 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 17 Nov 2015 10:28:40 +0100 Subject: Advance notice - H-root address change on December 1, 2015 In-Reply-To: <20151117001626.7C9633CC5570@rock.dv.isc.org> (Mark Andrews's message of "Tue, 17 Nov 2015 11:16:26 +1100") References: <8B01299690A8A94AB8629283FAFED8F1ACBA048A@umechpanz.easf.csd.disa.mil> <8B01299690A8A94AB8629283FAFED8F1C8BC596F@umechpanz.easf.csd.disa.mil> <20151116161939.GA3129@lboro.ac.uk> <20151116232753.E54F63CC49E6@rock.dv.isc.org> <20151117001626.7C9633CC5570@rock.dv.isc.org> Message-ID: <871tbpvut3.fsf@nemi.mork.no> Mark Andrews writes: > The [func] below are bug fixes / security fixes. Umh, using a very relaxed definition maybe... I was very happy to see this feature added in 9.9.8, and I can certainly agree that it is security related. But I hardly think it is suitable for the strict "no new features" policy that many stable distros enforce: > +3938. [func] Added quotas to be used in recursive resolvers > + that are under high query load for names in zones > + whose authoritative servers are nonresponsive or > + are experiencing a denial of service attack. > + > + - "fetches-per-server" limits the number of > + simultaneous queries that can be sent to any > + single authoritative server. The configured > + value is a starting point; it is automatically > + adjusted downward if the server is partially or > + completely non-responsive. The algorithm used to > + adjust the quota can be configured via the > + "fetch-quota-params" option. > + - "fetches-per-zone" limits the number of > + simultaneous queries that can be sent for names > + within a single domain. (Note: Unlike > + "fetches-per-server", this value is not > + self-tuning.) > + - New stats counters have been added to count > + queries spilled due to these quotas. > + > + These options are not available by default; > + use "configure --enable-fetchlimit" (or > + --enable-developer) to include them in the build. > + > + See the ARM for details of these options. [RT #37125] Yes, I know they could still upgrade to 9.9.8 without this particular feature, by simply not enabling it in the build. But the restricted feature set policy tends to be applied on a source level. Playing the devil's advocate here... As I said, I was really happy to see this feature in 9.9.8 myself. Bj?rn From gadit.arqam at gmail.com Tue Nov 17 09:42:37 2015 From: gadit.arqam at gmail.com (Arqam Gadit) Date: Tue, 17 Nov 2015 14:42:37 +0500 Subject: Dyn Internet Intelligence (Formerly, Renesys) vs Telegeography's Global Bandwidth Research Service Message-ID: Hello guys, Does anyone here have any experience with Dyn's Internet Intelligence or Telegeography's Global Bandwidth Research Service? I am looking to use them to answer two questions: 1. Which is best possible path available, given the current internet infrastructure, from point A to B in terms of latency and jitter? 2. Which careers should I talk to get those paths? Just wanted to know if anyone here has any experience with them or if there are some other tools that I should be looking into before making the purchase. Regards, Arqam From josh at kyneticwifi.com Tue Nov 17 21:43:40 2015 From: josh at kyneticwifi.com (Josh Reynolds) Date: Tue, 17 Nov 2015 15:43:40 -0600 Subject: Issues via HE into Chicago? Message-ID: Anyone else seeing massive issues? From hugo at slabnet.com Tue Nov 17 21:52:17 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 17 Nov 2015 13:52:17 -0800 Subject: Issues via HE into Chicago? In-Reply-To: References: Message-ID: <20151117215217.GL31680@bamboo.slabnet.com> On Tue 2015-Nov-17 15:43:40 -0600, Josh Reynolds wrote: >Anyone else seeing massive issues? To what destination? [outages] had some info re: a comcast issue in that area that has been reported as now resolved. -- Hugo hugo at slabnet.com: email, xmpp/jabber PGP fingerprint (B178313E): CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E (also on Signal) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From Valdis.Kletnieks at vt.edu Tue Nov 17 22:18:33 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 17 Nov 2015 17:18:33 -0500 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <201511140732.tAE7Wpa2070273@bela.nlnetlabs.nl> References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> <201511140732.tAE7Wpa2070273@bela.nlnetlabs.nl> Message-ID: <120259.1447798713@turing-police.cc.vt.edu> On Sat, 14 Nov 2015 08:32:51 +0100, Jaap Akkerhuis said: > Most people don't need to know. They just buy a cheap (EUR 50 or > so seems to be the starting price) application (rasberry Pi or > similar stuff based) which gives them what they want. > > There is now a push to forbid the sales of these thingies. Which won't work as long as a vendor in another country is willing to accept your credit card. But actual reality rarely matters to those who feel They Must Be Seen Doing Something About It. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From rdobbins at arbor.net Wed Nov 18 00:21:27 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 18 Nov 2015 07:21:27 +0700 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <201511140732.tAE7Wpa2070273@bela.nlnetlabs.nl> References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> <201511140732.tAE7Wpa2070273@bela.nlnetlabs.nl> Message-ID: <778DAFDF-E36C-4E1B-BB9E-D46260A8F486@arbor.net> On 14 Nov 2015, at 14:32, Jaap Akkerhuis wrote: > There is now a push to forbid the sales of these thingies. A push to forbid the sale of Raspberry Pis, of VPNs, or of both? Where? Thanks! ----------------------------------- Roland Dobbins From morrowc.lists at gmail.com Wed Nov 18 01:23:31 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 17 Nov 2015 20:23:31 -0500 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <778DAFDF-E36C-4E1B-BB9E-D46260A8F486@arbor.net> References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> <201511140732.tAE7Wpa2070273@bela.nlnetlabs.nl> <778DAFDF-E36C-4E1B-BB9E-D46260A8F486@arbor.net> Message-ID: On Tue, Nov 17, 2015 at 7:21 PM, Roland Dobbins wrote: > On 14 Nov 2015, at 14:32, Jaap Akkerhuis wrote: > >> There is now a push to forbid the sales of these thingies. > > A push to forbid the sale of Raspberry Pis, of VPNs, or of both? > * > Where? elbonia. > Thanks! > > ----------------------------------- > Roland Dobbins From ryan at finnesey.com Wed Nov 18 04:56:50 2015 From: ryan at finnesey.com (Ryan Finnesey) Date: Wed, 18 Nov 2015 04:56:50 +0000 Subject: Veeam Cloud Connect? Message-ID: I was wondering if anyone has deployed Veeam Cloud Connect. How has Veeam been to work with? Sent from my Windows Phone From mike.lyon at gmail.com Wed Nov 18 05:09:08 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Tue, 17 Nov 2015 21:09:08 -0800 Subject: Veeam Cloud Connect? In-Reply-To: References: Message-ID: I haven't used Veeam Cloud Connect but I have used Veeam. I was pretty happy with it. Easy and fast to configure. -Mike On Tue, Nov 17, 2015 at 8:56 PM, Ryan Finnesey wrote: > I was wondering if anyone has deployed Veeam Cloud Connect. How has Veeam > been to work with? > > > Sent from my Windows Phone > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From jaap at NLnetLabs.nl Wed Nov 18 07:50:24 2015 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 18 Nov 2015 08:50:24 +0100 Subject: DNSSEC and ISPs faking DNS responses In-Reply-To: <778DAFDF-E36C-4E1B-BB9E-D46260A8F486@arbor.net> References: <20151114030202.5877.qmail@ary.lan> <11431935-09A2-4EAA-A294-1EA5B230375C@arbor.net> <7226EE0E-8069-4177-8738-DD4AC9A1D732@delong.com> <201511140732.tAE7Wpa2070273@bela.nlnetlabs.nl> <778DAFDF-E36C-4E1B-BB9E-D46260A8F486@arbor.net> Message-ID: <201511180750.tAI7oO3q099598@bela.nlnetlabs.nl> "Roland Dobbins" writes: > On 14 Nov 2015, at 14:32, Jaap Akkerhuis wrote: > > > There is now a push to forbid the sales of these thingies. > > A push to forbid the sale of Raspberry Pis, of VPNs, or of both? > No, a push on devices which allow access to "illegal" material. The devives might have raspberry pies or similar stuff under the hood wjicj where very likely implementing VPNs. > Where? Last time I saw this was in the Dutch media; the c9omplains came from the Dutch versions of the copyright lobby. jaap From randy at psg.com Wed Nov 18 10:06:33 2015 From: randy at psg.com (Randy Bush) Date: Wed, 18 Nov 2015 12:06:33 +0200 Subject: bad announcement taxonomy Message-ID: some friends and i were talking about recent routing cfs, and found we needed a clearer taxonomy. i throw this out. leak - i receive P and send it on to folk to whom i should not send it for business reasons (transit, peer, ...) mis-origination - i originate P when i do not own it hijack - an intentional mis-origination 7007 - i receive P (or some sub/superset), process it in some way (likely through my igp), and re-originate it, or part of it, as my own we need a name for 7007 other then vinnie randy From rdobbins at arbor.net Wed Nov 18 10:12:13 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 18 Nov 2015 17:12:13 +0700 Subject: bad announcement taxonomy In-Reply-To: References: Message-ID: On 18 Nov 2015, at 17:06, Randy Bush wrote: > we need a name for 7007 other then vinnie Mis-distribution? ----------------------------------- Roland Dobbins From dot at dotat.at Wed Nov 18 10:40:53 2015 From: dot at dotat.at (Tony Finch) Date: Wed, 18 Nov 2015 10:40:53 +0000 Subject: bad announcement taxonomy In-Reply-To: References: Message-ID: Randy Bush wrote: > > leak - i receive P and send it on to folk to whom i should not send > it for business reasons (transit, peer, ...) > > 7007 - i receive P (or some sub/superset), process it in some way > (likely through my igp), and re-originate it, or part of it, > as my own > > we need a name for 7007 other then vinnie Laundered leak? Tony. -- f.anthony.n.finch http://dotat.at/ German Bight, Humber, Thames, Dover: West or northwest, backing southwest for a time, 6 to gale 8, increasing severe gale 9 at times, perhaps storm 10 later in German Bight and Humber. Rough or very rough, occasionally high later in German Bight and Humber. Rain at times. Good, occasionally poor. From randy at psg.com Wed Nov 18 11:27:48 2015 From: randy at psg.com (Randy Bush) Date: Wed, 18 Nov 2015 13:27:48 +0200 Subject: bad announcement taxonomy In-Reply-To: References: Message-ID: >> 7007 - i receive P (or some sub/superset), process it in some way >> (likely through my igp), and re-originate it, or part of it, >> as my own >> >> we need a name for 7007 other then vinnie > > Laundered leak? how about re-origination? From aftab.siddiqui at gmail.com Wed Nov 18 11:44:59 2015 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Wed, 18 Nov 2015 11:44:59 +0000 Subject: bad announcement taxonomy In-Reply-To: References: Message-ID: On Wed, 18 Nov 2015 at 22:29 Randy Bush wrote: > >> 7007 - i receive P (or some sub/superset), process it in some way > >> (likely through my igp), and re-originate it, or part of it, > >> as my own > >> > >> we need a name for 7007 other then vinnie > > > > Laundered leak? > > how about re-origination? > +1 Mis-distribution. or may be Mis-redistribution Leak, Mis-origination, Hijack.. they all have something in common i.e. #culprit but re-origination sounds pretty legitimate. -- Best Wishes, Aftab A. Siddiqui From randy at psg.com Wed Nov 18 11:46:57 2015 From: randy at psg.com (Randy Bush) Date: Wed, 18 Nov 2015 13:46:57 +0200 Subject: bad announcement taxonomy In-Reply-To: References: Message-ID: >> how about re-origination? > > +1 Mis-distribution. or may be Mis-redistribution you lost the part of the language which made clear that the *origin* has been changed. randy From randy at psg.com Wed Nov 18 11:47:39 2015 From: randy at psg.com (Randy Bush) Date: Wed, 18 Nov 2015 13:47:39 +0200 Subject: bad announcement taxonomy In-Reply-To: References: Message-ID: > What about "origin scrubbing". so now it has no origin? From bill at herrin.us Wed Nov 18 11:51:20 2015 From: bill at herrin.us (William Herrin) Date: Wed, 18 Nov 2015 06:51:20 -0500 Subject: bad announcement taxonomy In-Reply-To: References: Message-ID: On Wed, Nov 18, 2015 at 5:06 AM, Randy Bush wrote: > some friends and i were talking about recent routing cfs, and found we > needed a clearer taxonomy. i throw this out. > > leak - i receive P and send it on to folk to whom i should not send > it for business reasons (transit, peer, ...) > > mis-origination - i originate P when i do not own it > > hijack - an intentional mis-origination > > 7007 - i receive P (or some sub/superset), process it in some way > (likely through my igp), and re-originate it, or part of it, > as my own > > we need a name for 7007 other then vinnie mis-origination. When you non-maliciously announce P as if you own it (even though you do not) the exact details of how you screwed the pooch are not externally important. And we have enough obscure names for things as it is. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From toddunder at gmail.com Wed Nov 18 11:55:37 2015 From: toddunder at gmail.com (Todd Underwood) Date: Wed, 18 Nov 2015 06:55:37 -0500 Subject: bad announcement taxonomy In-Reply-To: References: Message-ID: Reorigination? Mis-re-origination? On Nov 18, 2015 22:53, "Randy Bush" wrote: > > What about "origin scrubbing". > > so now it has no origin? > From randy at psg.com Wed Nov 18 11:56:54 2015 From: randy at psg.com (Randy Bush) Date: Wed, 18 Nov 2015 13:56:54 +0200 Subject: bad announcement taxonomy In-Reply-To: References: Message-ID: > Reorigination? tried that and folk have been pushing back > Mis-re-origination? remiss-origination? :) From bill at herrin.us Wed Nov 18 12:08:22 2015 From: bill at herrin.us (William Herrin) Date: Wed, 18 Nov 2015 07:08:22 -0500 Subject: bad announcement taxonomy In-Reply-To: References: Message-ID: On Wed, Nov 18, 2015 at 6:51 AM, William Herrin wrote: > On Wed, Nov 18, 2015 at 5:06 AM, Randy Bush wrote: >> some friends and i were talking about recent routing cfs, and found we >> needed a clearer taxonomy. i throw this out. >> >> leak - i receive P and send it on to folk to whom i should not send >> it for business reasons (transit, peer, ...) >> >> mis-origination - i originate P when i do not own it >> >> hijack - an intentional mis-origination >> >> 7007 - i receive P (or some sub/superset), process it in some way >> (likely through my igp), and re-originate it, or part of it, >> as my own >> >> we need a name for 7007 other then vinnie > > mis-origination. When you non-maliciously announce P as if you own it > (even though you do not) the exact details of how you screwed the > pooch are not externally important. And we have enough obscure names > for things as it is. For that matter, just call it a hijack like it is. Don't legitimize originating a prefix you don't own by giving it an innocuous name. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From alejandroacostaalamo at gmail.com Wed Nov 18 12:21:20 2015 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Wed, 18 Nov 2015 07:51:20 -0430 Subject: bad announcement taxonomy In-Reply-To: References: Message-ID: <564C6D40.90801@gmail.com> El 11/18/2015 a las 7:16 AM, Randy Bush escribi?: >>> how about re-origination? >> +1 Mis-distribution. or may be Mis-redistribution > you lost the part of the language which made clear that the *origin* has > been changed. mutant? > > randy From mianosm at gmail.com Wed Nov 18 12:35:21 2015 From: mianosm at gmail.com (Steven Miano) Date: Wed, 18 Nov 2015 07:35:21 -0500 Subject: Veeam Cloud Connect? In-Reply-To: References: Message-ID: Using Veeam for backup at the moment, pretty unhappy with backup copy functions on multiple deduplication devices. Would also be very interested in hearing cloud connect experiences. On Wed, Nov 18, 2015 at 12:09 AM, Mike Lyon wrote: > I haven't used Veeam Cloud Connect but I have used Veeam. I was pretty > happy with it. Easy and fast to configure. > > -Mike > > > On Tue, Nov 17, 2015 at 8:56 PM, Ryan Finnesey wrote: > > > I was wondering if anyone has deployed Veeam Cloud Connect. How has > Veeam > > been to work with? > > > > > > Sent from my Windows Phone > > > > > > -- > Mike Lyon > 408-621-4826 > mike.lyon at gmail.com > > http://www.linkedin.com/in/mlyon > -- Miano, Steven M. http://stevenmiano.com From bill at herrin.us Wed Nov 18 14:40:27 2015 From: bill at herrin.us (William Herrin) Date: Wed, 18 Nov 2015 09:40:27 -0500 Subject: bad announcement taxonomy In-Reply-To: <564C8216.7010303@gmail.com> References: <564C8216.7010303@gmail.com> Message-ID: On Wed, Nov 18, 2015 at 8:50 AM, Mattia Rossi wrote: > So probably it should be structured like this: > > _________ leak > / > hijack ----------------- mis-origination (which should be better described > as: I originate P when I don't have the right to) > \__________ origin scrubbing (I like that) > > It's a hijack (the result) in any case. If you want to differentiate > between malice and stupidity/ignorance just call it "malicious hijack" > opposed to "accidental hijack". And then list the cause (leak, > mis-origination, origin scrubbing) Hi Mat, I object to jargon on general principle. Excessive jargon makes technical disciplines needlessly inaccessible to folks who aren't steeped in the lore. Now and then there's a concept of such routine utility within the discipline that it's worth abbreviating into a word or short phrase. In that case, words that imply the concept are a good choice. Route Hijack is a good example of this. Creating jargon down in the weeds, though, that's a bad thing. Unwise. Something to be deliberately avoided. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From rdobbins at arbor.net Wed Nov 18 14:45:56 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 18 Nov 2015 21:45:56 +0700 Subject: bad announcement taxonomy In-Reply-To: References: <564C8216.7010303@gmail.com> Message-ID: On 18 Nov 2015, at 21:40, William Herrin wrote: > Creating jargon down in the weeds, though, that's a bad thing. 'AS 7007' is jargon to those unaware of the history and context. ----------------------------------- Roland Dobbins From m.waehlisch at fu-berlin.de Wed Nov 18 11:43:00 2015 From: m.waehlisch at fu-berlin.de (Matthias Waehlisch) Date: Wed, 18 Nov 2015 06:43:00 -0500 (Eastern Normalzeit) Subject: bad announcement taxonomy In-Reply-To: References: Message-ID: On Wed, 18 Nov 2015, Randy Bush wrote: > >> 7007 - i receive P (or some sub/superset), process it in some way > >> (likely through my igp), and re-originate it, or part of it, > >> as my own > >> > >> we need a name for 7007 other then vinnie > > > > Laundered leak? > > how about re-origination? > might be misleading in case you don't re-originate P exactly but only "part of it". What about "origin scrubbing". Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch at ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From nigel at titley.com Wed Nov 18 12:12:14 2015 From: nigel at titley.com (Nigel Titley) Date: Wed, 18 Nov 2015 14:12:14 +0200 Subject: bad announcement taxonomy In-Reply-To: References: Message-ID: <564C6B1E.10806@titley.com> On 18/11/2015 13:46, Randy Bush wrote: >>> how about re-origination? >> +1 Mis-distribution. or may be Mis-redistribution > you lost the part of the language which made clear that the *origin* has > been changed. Fenced From mattia.rossi.mailinglists at gmail.com Wed Nov 18 13:50:14 2015 From: mattia.rossi.mailinglists at gmail.com (Mattia Rossi) Date: Wed, 18 Nov 2015 14:50:14 +0100 Subject: bad announcement taxonomy In-Reply-To: References: Message-ID: <564C8216.7010303@gmail.com> Am 18.11.2015 um 13:08 schrieb William Herrin: > On Wed, Nov 18, 2015 at 6:51 AM, William Herrin wrote: >> On Wed, Nov 18, 2015 at 5:06 AM, Randy Bush wrote: >>> some friends and i were talking about recent routing cfs, and found we >>> needed a clearer taxonomy. i throw this out. >>> >>> leak - i receive P and send it on to folk to whom i should not send >>> it for business reasons (transit, peer, ...) >>> >>> mis-origination - i originate P when i do not own it >>> >>> hijack - an intentional mis-origination >>> >>> 7007 - i receive P (or some sub/superset), process it in some way >>> (likely through my igp), and re-originate it, or part of it, >>> as my own >>> >>> we need a name for 7007 other then vinnie >> mis-origination. When you non-maliciously announce P as if you own it >> (even though you do not) the exact details of how you screwed the >> pooch are not externally important. And we have enough obscure names >> for things as it is. > For that matter, just call it a hijack like it is. Don't legitimize > originating a prefix you don't own by giving it an innocuous name. So probably it should be structured like this: _________ leak / hijack ----------------- mis-origination (which should be better described as: I originate P when I don't have the right to) \__________ origin scrubbing (I like that) It's a hijack (the result) in any case. If you want to differentiate between malice and stupidity/ignorance just call it "malicious hijack" opposed to "accidental hijack". And then list the cause (leak, mis-origination, origin scrubbing) Cheers, Mat From noc at PBRC.EDU Wed Nov 18 04:50:41 2015 From: noc at PBRC.EDU (noc) Date: Wed, 18 Nov 2015 04:50:41 +0000 Subject: Time Warner contact? Message-ID: We're seeing 90% packet loss between Time Warner in socal, starting at 24.30.169.141 (tge0-9-0-23.lsapcawv02h.socal.rr.com), and anything in 74.125 (google space). Has been in ticket hell for the last week. Could you please contact me off list for the ticket number and additional information? This is a major impairment, at least for those TW customers it's affecting. Thanks, Spencer PBRC NOC From nellermann at broadaspect.com Wed Nov 18 15:08:23 2015 From: nellermann at broadaspect.com (Nick Ellermann) Date: Wed, 18 Nov 2015 15:08:23 +0000 Subject: Veeam Cloud Connect? In-Reply-To: References: Message-ID: <8b60c55deb1048b394eb785113628df0@exchange.broadaspect.local> Yes. We have the Veeam Cloud Connect platform deployed in multiple data centers for our customers. It's only useful for offsite backup copies at the moment, but with version 9 there will be VM replication options added to the platform. Veeam has been a great software partner of ours for several years and we enjoy the service provider program. Message me offline if you would like to know more. Sincerely, Nick Ellermann - CTO & VP Cloud Services BroadAspect ? E: nellermann at broadaspect.com P: 703-297-4639 F: 703-996-4443 ? THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. -----Original Message----- From: NANOG [mailto:nanog-bounces+nellermann=broadaspect.com at nanog.org] On Behalf Of Ryan Finnesey Sent: Tuesday, November 17, 2015 11:57 PM To: NANOG Subject: Veeam Cloud Connect? I was wondering if anyone has deployed Veeam Cloud Connect. How has Veeam been to work with? Sent from my Windows Phone From sfouant at shortestpathfirst.net Wed Nov 18 14:52:16 2015 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Wed, 18 Nov 2015 09:52:16 -0500 Subject: bad announcement taxonomy In-Reply-To: References: <564C8216.7010303@gmail.com> Message-ID: <7C1EA093-E164-4C3E-BCBD-0A1887494315@shortestpathfirst.net> > On Nov 18, 2015, at 9:45 AM, Roland Dobbins wrote: > >> On 18 Nov 2015, at 21:40, William Herrin wrote: >> >> Creating jargon down in the weeds, though, that's a bad thing. > > 'AS 7007' is jargon to those unaware of the history and context. https://en.m.wikipedia.org/wiki/AS_7007_incident He can thank me later ? Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI m (703) 625-6243 From listas at kurtkraut.net Wed Nov 18 16:28:20 2015 From: listas at kurtkraut.net (Kurt Kraut) Date: Wed, 18 Nov 2015 14:28:20 -0200 Subject: Is there a DNS lookup, traceroute, ping and HTTP GET as a service? Message-ID: Hi, I'm evaluating different datacenters and vendors accross the globe and it isn't worthy to perform tests like DNS, traceroute, ping and HTTP GET from my office. I need to be able to perform this tests remotely, from multiple endpoints. The only company I know allow such thing is ThousandEyes, but it is brutally and inexplicably expensive and doesn't fit perfectly to what I'm looking for. It has a paradigm I'm willing to monitor 24x7 specific targets from multiple points of view. I need to make tests on demand, on different targets and URLs. Does anyone know such service, DNS lookup, traceroute, ping and HTTP GET as a service from multiple nodes geographically spread? Thanks in advance, Kurt Kraut From morrowc.lists at gmail.com Wed Nov 18 16:31:27 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 18 Nov 2015 11:31:27 -0500 Subject: Is there a DNS lookup, traceroute, ping and HTTP GET as a service? In-Reply-To: References: Message-ID: ripe atlas? On Wed, Nov 18, 2015 at 11:28 AM, Kurt Kraut via NANOG wrote: > Hi, > > > I'm evaluating different datacenters and vendors accross the globe and it > isn't worthy to perform tests like DNS, traceroute, ping and HTTP GET from > my office. I need to be able to perform this tests remotely, from multiple > endpoints. > > The only company I know allow such thing is ThousandEyes, but it is > brutally and inexplicably expensive and doesn't fit perfectly to what I'm > looking for. It has a paradigm I'm willing to monitor 24x7 specific targets > from multiple points of view. I need to make tests on demand, on different > targets and URLs. > > Does anyone know such service, DNS lookup, traceroute, ping and HTTP GET as > a service from multiple nodes geographically spread? > > > Thanks in advance, > > > Kurt Kraut From bill at herrin.us Wed Nov 18 16:32:41 2015 From: bill at herrin.us (William Herrin) Date: Wed, 18 Nov 2015 11:32:41 -0500 Subject: Is there a DNS lookup, traceroute, ping and HTTP GET as a service? In-Reply-To: References: Message-ID: On Wed, Nov 18, 2015 at 11:28 AM, Kurt Kraut via NANOG wrote: > I'm evaluating different datacenters and vendors accross the globe and it > isn't worthy to perform tests like DNS, traceroute, ping and HTTP GET from > my office. I need to be able to perform this tests remotely, from multiple > endpoints. For common tests like ping and traceroute, google "ip looking glass". There are a lot of them in a lot of locations, all free to use. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From listas at kurtkraut.net Wed Nov 18 16:38:28 2015 From: listas at kurtkraut.net (Kurt Kraut) Date: Wed, 18 Nov 2015 14:38:28 -0200 Subject: Is there a DNS lookup, traceroute, ping and HTTP GET as a service? In-Reply-To: References: Message-ID: Hi, Thank you for the quick replies. Sorry for not being clear enough: I need it to have an API so I can integrate it with my own solution, generate my own metrics. So looking glasses are pretty much useless: they don't support HTTP GET and DNS lookup (usually) and the parsing for so many different HTML or telnet sources would be very time consuming. Also I've seen many looking glasses with captchas to halt these intents. So I need a SaaS with an API for these tests. About RIPE ATLAS, I already have one of their boxes and it never worked. Simply doesn't appear as online. Their support just barely gave me some tips but with no meaningful result. I need something reliable and I'm willing to pay for this service. RIPE Atlas falls in the category of 'best effort'. Best regards, Kurt Kraut 2015-11-18 14:32 GMT-02:00 William Herrin : > On Wed, Nov 18, 2015 at 11:28 AM, Kurt Kraut via NANOG > wrote: > > I'm evaluating different datacenters and vendors accross the globe and it > > isn't worthy to perform tests like DNS, traceroute, ping and HTTP GET > from > > my office. I need to be able to perform this tests remotely, from > multiple > > endpoints. > > For common tests like ping and traceroute, google "ip looking glass". > There are a lot of them in a lot of locations, all free to use. > > -Bill > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > From hank at efes.iucc.ac.il Wed Nov 18 16:50:19 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 18 Nov 2015 18:50:19 +0200 Subject: Is there a DNS lookup, traceroute, ping and HTTP GET as a service? In-Reply-To: References: Message-ID: <5.1.1.6.2.20151118184926.002ce1e8@efes.iucc.ac.il> At 14:38 18/11/2015 -0200, Kurt Kraut via NANOG wrote: Try: https://asm.ca.com/en/ -Hank >Hi, > > >Thank you for the quick replies. Sorry for not being clear enough: I need >it to have an API so I can integrate it with my own solution, generate my >own metrics. So looking glasses are pretty much useless: they don't support >HTTP GET and DNS lookup (usually) and the parsing for so many different >HTML or telnet sources would be very time consuming. > >Also I've seen many looking glasses with captchas to halt these intents. So >I need a SaaS with an API for these tests. > >About RIPE ATLAS, I already have one of their boxes and it never worked. >Simply doesn't appear as online. Their support just barely gave me some >tips but with no meaningful result. I need something reliable and I'm >willing to pay for this service. RIPE Atlas falls in the category of 'best >effort'. > > >Best regards, > > >Kurt Kraut > >2015-11-18 14:32 GMT-02:00 William Herrin : > > > On Wed, Nov 18, 2015 at 11:28 AM, Kurt Kraut via NANOG > > wrote: > > > I'm evaluating different datacenters and vendors accross the globe and it > > > isn't worthy to perform tests like DNS, traceroute, ping and HTTP GET > > from > > > my office. I need to be able to perform this tests remotely, from > > multiple > > > endpoints. > > > > For common tests like ping and traceroute, google "ip looking glass". > > There are a lot of them in a lot of locations, all free to use. > > > > -Bill > > > > > > -- > > William Herrin ................ herrin at dirtside.com bill at herrin.us > > Owner, Dirtside Systems ......... Web: > > From modonovan at btireland.net Wed Nov 18 16:50:50 2015 From: modonovan at btireland.net (Mick O Donovan) Date: Wed, 18 Nov 2015 16:50:50 +0000 Subject: Is there a DNS lookup, traceroute, ping and HTTP GET as a service? In-Reply-To: References: Message-ID: <20151118165050.GB27813@carra.btireland.net> Hi there, On Wed, Nov 18, 2015 at 02:38:28PM -0200, Kurt Kraut via NANOG wrote: > About RIPE ATLAS, I already have one of their boxes and it never worked. > Simply doesn't appear as online. Their support just barely gave me some > tips but with no meaningful result. I need something reliable and I'm > willing to pay for this service. RIPE Atlas falls in the category of 'best > effort'. > > > Best regards, > I find this surprising. Like many hundreds/thousands of people around the globe I find RIPE ATLAS an excellent and reliable way to get the measurements you require. You may not have had the best experience with your probe setup but I'm sure that if someone can assist you with setup you'll be pleasantly surprised at the ability the network of probes has to fulfill your needs - after all it is the biggest measurement network on the internet today! (at least that's what my t-shirt says) Regards, Mick -- Mick O'Donovan | Network Engineer | BT Ireland | Website: http://www.btireland.net Looking Glass: http://lg.as2110.net Peering Record: http://as2110.peeringdb.com AS-SET Macro: AS-BTIRE | ASN: 2110 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: Digital signature URL: From A.L.M.Buxey at lboro.ac.uk Wed Nov 18 17:24:33 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Wed, 18 Nov 2015 17:24:33 +0000 Subject: Is there a DNS lookup, traceroute, ping and HTTP GET as a service? In-Reply-To: References: Message-ID: <20151118172433.GA7718@lboro.ac.uk> Hi, > About RIPE ATLAS, I already have one of their boxes and it never worked. > Simply doesn't appear as online. Their support just barely gave me some > tips but with no meaningful result. I need something reliable and I'm > willing to pay for this service. RIPE Atlas falls in the category of 'best > effort'. RIPE Atlas probes? you just plug them intoa working network with DHCP and away they go - I'd investigate why it doesnt work - RIPE expect probe users to be technically proficient and that the networks that the probes are on arent RIPEs to debug/troubleshoot. once you have a working one iy can do tests but you then also have access to the testing system that they offer allowing you to do on-demand tests for various things from probes around the world whever you want - depending on how many points you have. I have a few million or so points :-) alan From A.L.M.Buxey at lboro.ac.uk Wed Nov 18 17:25:20 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Wed, 18 Nov 2015 17:25:20 +0000 Subject: Is there a DNS lookup, traceroute, ping and HTTP GET as a service? In-Reply-To: References: Message-ID: <20151118172520.GB7718@lboro.ac.uk> hi, ...and SamKnows? alan From crussell at kanren.net Wed Nov 18 16:12:02 2015 From: crussell at kanren.net (Casey Russell) Date: Wed, 18 Nov 2015 10:12:02 -0600 Subject: bad announcement taxonomy In-Reply-To: References: Message-ID: I think Tony's on the right track here. I vote we call this "Route Laundering", the people who do it "Route Launderers", and the routes themselves "Laundered Routes". I actually had a little trouble spelling the different forms of laundering. So I looked them up.. ----"I can't believe what a bunch of nerds we are. We're looking up "money laundering" in a dictionary." Casey Russell Network Engineer Kansas Research and Education Network 2029 Becker Drive, Suite 282 Lawrence, KS 66047 (785)856-9820 ext 9809 crussell at kanren.net On Wed, Nov 18, 2015 at 4:40 AM, Tony Finch wrote: > Randy Bush wrote: > > > > leak - i receive P and send it on to folk to whom i should not send > > it for business reasons (transit, peer, ...) > > > > 7007 - i receive P (or some sub/superset), process it in some way > > (likely through my igp), and re-originate it, or part of it, > > as my own > > > > we need a name for 7007 other then vinnie > > Laundered leak? > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > German Bight, Humber, Thames, Dover: West or northwest, backing southwest > for > a time, 6 to gale 8, increasing severe gale 9 at times, perhaps storm 10 > later > in German Bight and Humber. Rough or very rough, occasionally high later in > German Bight and Humber. Rain at times. Good, occasionally poor. > From bortzmeyer at nic.fr Wed Nov 18 17:42:50 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 18 Nov 2015 18:42:50 +0100 Subject: Is there a DNS lookup, traceroute, ping and HTTP GET as a service? In-Reply-To: References: Message-ID: <20151118174249.GA23713@sources.org> On Wed, Nov 18, 2015 at 02:38:28PM -0200, Kurt Kraut via NANOG wrote a message of 45 lines which said: > About RIPE ATLAS, I already have one of their boxes and it never > worked. Simply doesn't appear as online. Their support just barely > gave me some tips but with no meaningful result. Like most people, I have a very good experience with RIPE Atlas probes. If they fail (it never happened to me), there is a very comprehensive FAQ and the nice people on the user mailing list (remember it is a community service, the RIPE-NCC is not a commercial support team) are very responsive. From arturo.servin at gmail.com Wed Nov 18 20:55:22 2015 From: arturo.servin at gmail.com (Arturo Servin) Date: Wed, 18 Nov 2015 20:55:22 +0000 Subject: bad announcement taxonomy In-Reply-To: References: Message-ID: Laundered route I like it. Or re-originated laundered route (it has more meaning but a bit too long) .as On Wed, 18 Nov 2015 at 09:33 Casey Russell wrote: > I think Tony's on the right track here. I vote we call this "Route > Laundering", the people who do it "Route Launderers", and the routes > themselves "Laundered Routes". > > I actually had a little trouble spelling the different forms of > laundering. So I looked them up.. > > > ----"I can't believe what a bunch of nerds we are. We're looking up "money > laundering" in a dictionary." > > Casey Russell > Network Engineer > Kansas Research and Education Network > > 2029 Becker Drive, Suite 282 > > Lawrence, KS 66047 > (785)856-9820 ext 9809 > crussell at kanren.net > > On Wed, Nov 18, 2015 at 4:40 AM, Tony Finch wrote: > > > Randy Bush wrote: > > > > > > leak - i receive P and send it on to folk to whom i should not send > > > it for business reasons (transit, peer, ...) > > > > > > 7007 - i receive P (or some sub/superset), process it in some way > > > (likely through my igp), and re-originate it, or part of it, > > > as my own > > > > > > we need a name for 7007 other then vinnie > > > > Laundered leak? > > > > Tony. > > -- > > f.anthony.n.finch http://dotat.at/ > > German Bight, Humber, Thames, Dover: West or northwest, backing southwest > > for > > a time, 6 to gale 8, increasing severe gale 9 at times, perhaps storm 10 > > later > > in German Bight and Humber. Rough or very rough, occasionally high later > in > > German Bight and Humber. Rain at times. Good, occasionally poor. > > > From jabley at hopcount.ca Wed Nov 18 22:51:30 2015 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 18 Nov 2015 17:51:30 -0500 Subject: bad announcement taxonomy In-Reply-To: References: Message-ID: <8EF67853-078A-429C-946D-A6AEA6A0F5D6@hopcount.ca> On 18 Nov 2015, at 15:55, Arturo Servin wrote: > Laundered route The routes in question are not just being laundered, they're being bleached. Joe From surfer at mauigateway.com Wed Nov 18 23:22:04 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 18 Nov 2015 15:22:04 -0800 Subject: OT: BdNOG announces website blocks Message-ID: <20151118152204.4768365@m0087793.ppops.net> --------------------------------------------- Md. abdullah Al naser mail.naserbd at yahoo.com Wed Nov 18 12:56:15 BDT 2015 The service of Facebook, Viber and Whatsapp are blocked from now till further notice. It has been ordered by Begum Tarana Halim, State Minister, Post and Telecommunications. ---------------------------------------------- I just saw this on BdNOG and thought it might be interesting to others here and where some of the internet is headed... Wow, all of these govt's just can't seem to deal with not being able to completely control *everything* about the populace. So, in Bangladesh, no communicating with your social peers, no free calls, text or picture sharing and no mobile messaging. The new State Minister for Post and Telecommunications in Bangladesh wants her money. It'd be interesting to hear how they're attempting to make it happen. scott From shortdudey123 at gmail.com Wed Nov 18 23:34:13 2015 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 18 Nov 2015 15:34:13 -0800 Subject: OT: BdNOG announces website blocks In-Reply-To: <20151118152204.4768365@m0087793.ppops.net> References: <20151118152204.4768365@m0087793.ppops.net> Message-ID: Any idea if this includes Instagram as well since it is a Facebook asset? -Grant On Wed, Nov 18, 2015 at 3:22 PM, Scott Weeks wrote: > > --------------------------------------------- > Md. abdullah Al naser mail.naserbd at yahoo.com > Wed Nov 18 12:56:15 BDT 2015 > > The service of Facebook, Viber and Whatsapp are > blocked from now till further notice. It has been > ordered by Begum Tarana Halim, State Minister, Post > and Telecommunications. > ---------------------------------------------- > > > > I just saw this on BdNOG and thought it might be > interesting to others here and where some of the > internet is headed... > > Wow, all of these govt's just can't seem to deal > with not being able to completely control *everything* > about the populace. > > So, in Bangladesh, no communicating with your social > peers, no free calls, text or picture sharing and no > mobile messaging. The new State Minister for Post > and Telecommunications in Bangladesh wants her money. > > It'd be interesting to hear how they're attempting > to make it happen. > > scott > From drinking.coffee at gmail.com Wed Nov 18 21:45:16 2015 From: drinking.coffee at gmail.com (Matthew McGehrin) Date: Wed, 18 Nov 2015 15:45:16 -0600 Subject: Is there a DNS lookup, traceroute, ping and HTTP GET as a service? In-Reply-To: References: Message-ID: <564CF16C.6060202@gmail.com> Hello. Have you checked out some of the website monitoring sites? I know Hyperspin has a free test for most of their locations: http://www.hyperspin.com/en/quicktest.php UptimeRobot, has free monitoring for up to 50 sites: http://uptimerobot.com/ If you want to check DNS propagation, I use: https://www.whatsmydns.net/ -- Matthew Kurt Kraut via NANOG wrote: > Hi, > > I'm evaluating different datacenters and vendors accross the globe and it > isn't worthy to perform tests like DNS, traceroute, ping and HTTP GET from > my office. I need to be able to perform this tests remotely, from multiple > endpoints. > > From rsk at gsp.org Wed Nov 18 23:55:02 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 18 Nov 2015 18:55:02 -0500 Subject: OT: BdNOG announces website blocks In-Reply-To: References: <20151118152204.4768365@m0087793.ppops.net> Message-ID: <20151118235502.GA25163@gsp.org> On Wed, Nov 18, 2015 at 03:34:13PM -0800, Grant Ridder wrote: > Any idea if this includes Instagram as well since it is a Facebook asset? This news story: Social networking sites closed for security reasons, says Minister Tarana Halim http://bdnews24.com/bangladesh/2015/11/18/social-networking-sites-closed-for-security-reasons-says-minister-tarana-halim suggests that other sites are certainly on their radar: She [Halim] said the government was keeping an eye on Twitter, Tango, imo and several other social networking and messaging applications. ---rsk From surfer at mauigateway.com Thu Nov 19 00:13:30 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 18 Nov 2015 16:13:30 -0800 Subject: OT: BdNOG announces website blocks Message-ID: <20151118161330.47687A7@m0087793.ppops.net> On Wed, Nov 18, 2015 at 3:22 PM, Scott Weeks wrote: > --------------------------------------------- > Md. abdullah Al naser mail.naserbd at yahoo.com > Wed Nov 18 12:56:15 BDT 2015 > > The service of Facebook, Viber and Whatsapp are > blocked from now till further notice. It has been > ordered by Begum Tarana Halim, State Minister, Post > and Telecommunications. > ---------------------------------------------- > > I just saw this on BdNOG and thought it might be > interesting to others here and where some of the > internet is headed... > > Wow, all of these govt's just can't seem to deal > with not being able to completely control *everything* > about the populace. > > So, in Bangladesh, no communicating with your social > peers, no free calls, text or picture sharing and no > mobile messaging. The new State Minister for Post > and Telecommunications in Bangladesh wants her money. > > It'd be interesting to hear how they're attempting > to make it happen. --------------------------------------------- --- shortdudey123 at gmail.com wrote: From: Grant Ridder Any idea if this includes Instagram as well since it is a Facebook asset? ---------------------------------------------- No idea. I am seeing this want of govt's everywhere. Australia, China, US, BD, etc, etc. It makes me want to get hosed off with disinfectant. scott From marka at isc.org Thu Nov 19 00:27:17 2015 From: marka at isc.org (Mark Andrews) Date: Thu, 19 Nov 2015 11:27:17 +1100 Subject: OT: BdNOG announces website blocks In-Reply-To: Your message of "Wed, 18 Nov 2015 16:13:30 -0800." <20151118161330.47687A7@m0087793.ppops.net> References: <20151118161330.47687A7@m0087793.ppops.net> Message-ID: <20151119002717.AE2D03D098D5@rock.dv.isc.org> In message <20151118161330.47687A7 at m0087793.ppops.net>, "Scott Weeks" writes: > > On Wed, Nov 18, 2015 at 3:22 PM, Scott Weeks wrote: > > > --------------------------------------------- > > Md. abdullah Al naser mail.naserbd at yahoo.com > > Wed Nov 18 12:56:15 BDT 2015 > > > > The service of Facebook, Viber and Whatsapp are > > blocked from now till further notice. It has been > > ordered by Begum Tarana Halim, State Minister, Post > > and Telecommunications. > > ---------------------------------------------- > > > > I just saw this on BdNOG and thought it might be > > interesting to others here and where some of the > > internet is headed... > > > > Wow, all of these govt's just can't seem to deal > > with not being able to completely control *everything* > > about the populace. > > > > So, in Bangladesh, no communicating with your social > > peers, no free calls, text or picture sharing and no > > mobile messaging. The new State Minister for Post > > and Telecommunications in Bangladesh wants her money. > > > > It'd be interesting to hear how they're attempting > > to make it happen. > --------------------------------------------- > > > --- shortdudey123 at gmail.com wrote: > From: Grant Ridder > > Any idea if this includes Instagram as well since it is > a Facebook asset? > ---------------------------------------------- > > > No idea. I am seeing this want of govt's everywhere. > Australia, China, US, BD, etc, etc. It makes me want > to get hosed off with disinfectant. And the Australian PM boasted about using apps which encrypted traffic to avoid surveillance before he became PM. Perhaps he should be locked up as a terrorist. Mark > scott -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From alex-nanog at gt.net Wed Nov 18 23:48:35 2015 From: alex-nanog at gt.net (Alex Krohn) Date: Wed, 18 Nov 2015 15:48:35 -0800 Subject: Is there a DNS lookup, traceroute, ping and HTTP GET as a service? In-Reply-To: <564CF16C.6060202@gmail.com> References: <564CF16C.6060202@gmail.com> Message-ID: <20151118154835.5136.291F73A1@gt.net> Hi, > Kurt Kraut via NANOG wrote: > > Hi, > > > > I'm evaluating different datacenters and vendors accross the globe and it > > isn't worthy to perform tests like DNS, traceroute, ping and HTTP GET from > > my office. I need to be able to perform this tests remotely, from multiple > > endpoints. > > > > > Have you checked out some of the website monitoring sites? > Can also look at GTmetrix: https://gtmetrix.com/ which has rest api to launch real browser from a bunch of different locations and then can access the HAR file to see time to first byte, dns resolution, and a bunch of other metrics. https://gtmetrix.com/reports/www.nanog.org/INgQIGE6#waterfall Full disclosure, GT owns it (but you can do everything you want with free api). Cheers, Alex From dedelman at iname.com Thu Nov 19 00:21:32 2015 From: dedelman at iname.com (David Edelman) Date: Wed, 18 Nov 2015 18:21:32 -0600 Subject: bad announcement taxonomy In-Reply-To: <8EF67853-078A-429C-946D-A6AEA6A0F5D6@hopcount.ca> References: <8EF67853-078A-429C-946D-A6AEA6A0F5D6@hopcount.ca> Message-ID: <0ED16430-76A1-43D5-BB28-97A3E8DCCDF1@iname.com> How about Origin Obfuscation --Dave Dave Edelman > On Nov 18, 2015, at 16:51, Joe Abley wrote: > > > >> On 18 Nov 2015, at 15:55, Arturo Servin wrote: >> >> Laundered route > > The routes in question are not just being laundered, they're being bleached. > > > Joe From Valdis.Kletnieks at vt.edu Thu Nov 19 06:15:29 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 19 Nov 2015 01:15:29 -0500 Subject: bad announcement taxonomy In-Reply-To: <0ED16430-76A1-43D5-BB28-97A3E8DCCDF1@iname.com> References: <8EF67853-078A-429C-946D-A6AEA6A0F5D6@hopcount.ca> <0ED16430-76A1-43D5-BB28-97A3E8DCCDF1@iname.com> Message-ID: <18414.1447913729@turing-police.cc.vt.edu> On Wed, 18 Nov 2015 18:21:32 -0600, David Edelman said: > How about Origin Obfuscation Obfuscation implies intent. Most leaks and mis-announcements don't have intent because they're whoopsies. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From john-nanog at peachfamily.net Thu Nov 19 14:08:31 2015 From: john-nanog at peachfamily.net (John Peach) Date: Thu, 19 Nov 2015 09:08:31 -0500 Subject: AOL postmaster rejections. Message-ID: <20151119090831.2cae03ca@jpeach-desktop.anbg.mssm.edu> Has anyone else with relatively large volumes of email seen a huge spike in rejections from AOL recently? There is no obvious reason why they are being rejected as it is a generic message: Nov 18 12:10:39 pp-serve02 sendmail[1391]: tAIHAcPT001383: mailin-04.mx.aol.com.: SMTP DATA-2 protocol error: 521 5.2.1 : AOL will not accept delivery of this message. Looking back through my logs, I can see we've always had a few, but we are now receiving a lot of complaints from users (physicians who cannot email their patients) and I see this, starting on Monday: syslog-2015-11-16 588 syslog-2015-11-17 1668 syslog-2015-11-18 1937 and I already have 55 for today. We have a whitelist / feedback loop set up with AOL, our IPs show clean with them and our DNS / reverse DNS has not changed and resolves properly. We did raise a ticket with them, but it seems to have gone to the usual /dev/null. To reply off-list, please remove the VERP -nanog from my email address, -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From effulgence at gmail.com Thu Nov 19 10:36:55 2015 From: effulgence at gmail.com (Aris Lambrianidis) Date: Thu, 19 Nov 2015 12:36:55 +0200 Subject: bad announcement taxonomy In-Reply-To: References: Message-ID: <564DA647.1090305@gmail.com> Randy Bush wrote: > some friends and i were talking about recent routing cfs, and found we > needed a clearer taxonomy. i throw this out. > > leak - i receive P and send it on to folk to whom i should not send > it for business reasons (transit, peer, ...) > > mis-origination - i originate P when i do not own it > > hijack - an intentional mis-origination > > 7007 - i receive P (or some sub/superset), process it in some way > (likely through my igp), and re-originate it, or part of it, > as my own > > we need a name for 7007 other then vinnie So 7007 (laundering) might be (or not) a subset of a hijack which is a subset of mis-origination. What's the tree for a leak? I think a more structured approach is necessary if we are to delve on both technical definitions and intent. --Aris From janusz at speedchecker.xyz Thu Nov 19 10:52:44 2015 From: janusz at speedchecker.xyz (Janusz Jezowicz) Date: Thu, 19 Nov 2015 12:52:44 +0200 Subject: Is there a DNS lookup, traceroute, ping and HTTP GET as a service? In-Reply-To: References: Message-ID: Hello Kurt, Like others have commented RIPE Atlas works very well and many people use it with much success. The only limiting factor for you will be HTTP GET tests but for other tests you mentioned it will run fine. I would definitely recommend to give it one more try. I would like to mention our service - ProbeAPI (http://www.probeapi.com) We are a new service launched this year. I believe we tick all the boxes for your requirements. For non-commercial purposes API access is free. Otherwise feel free to get in touch. To anyone else - yes this is self-promotion I am new to the group (more involved in RIPE community than NANOG). I think this is very relevant to Kurt's question but if you don't think its appropriate please do let me know. Regards, Janusz On 18 November 2015 at 18:28, Kurt Kraut via NANOG wrote: > Hi, > > > I'm evaluating different datacenters and vendors accross the globe and it > isn't worthy to perform tests like DNS, traceroute, ping and HTTP GET from > my office. I need to be able to perform this tests remotely, from multiple > endpoints. > > The only company I know allow such thing is ThousandEyes, but it is > brutally and inexplicably expensive and doesn't fit perfectly to what I'm > looking for. It has a paradigm I'm willing to monitor 24x7 specific targets > from multiple points of view. I need to make tests on demand, on different > targets and URLs. > > Does anyone know such service, DNS lookup, traceroute, ping and HTTP GET as > a service from multiple nodes geographically spread? > > > Thanks in advance, > > > Kurt Kraut > From kc at caida.org Thu Nov 19 14:07:11 2015 From: kc at caida.org (k claffy) Date: Thu, 19 Nov 2015 06:07:11 -0800 Subject: looking for hosting sites for CAIDA Ark measurement infrastructure Message-ID: <20151119140710.GB49866@caida.org> folks, we are seeking additional Ark vantage points ( http://www.caida.org/projects/ark/ ) to support a variety of projects but especially motivated by our NSF-funded project to map and measure interconnection in the Internet: http://www.caida.org/funding/nets-congestion/ (recent paper describing the current method: http://www.caida.org/publications/papers/2015/measuring_interdomain_congestion/ ) we are looking to build as complete a map as we can of the interconnections between U.S. residential broadband access providers and their neighbors. so our priority is vantage points in the homes of U.S. access providers (especially high b/w access providers). but if you are interested in hosting an Ark node anywhere, please let me or monitor-info at caida.org know where/when. we will send a raspberry pi monitor out to you stat. some faq info on hosting a monitor: http://www.caida.org/projects/ark/siteinfo.xml and the infrastructure project itself: http://www.caida.org/projects/ark/ thanks very much, k From randy at psg.com Thu Nov 19 18:47:40 2015 From: randy at psg.com (Randy Bush) Date: Thu, 19 Nov 2015 20:47:40 +0200 Subject: bad announcement taxonomy In-Reply-To: <564DA647.1090305@gmail.com> References: <564DA647.1090305@gmail.com> Message-ID: > So 7007 (laundering) might be (or not) a subset of a hijack which is a > subset of mis-origination. > What's the tree for a leak? I think a more structured approach is > necessary if we are to delve on > both technical definitions and intent. you can make it as complex as you want. and you're not even the worst i have been sent. but i won't play. i believe those terms are sufficient and can be combined. randy From blake at ispn.net Thu Nov 19 19:30:17 2015 From: blake at ispn.net (Blake Hudson) Date: Thu, 19 Nov 2015 13:30:17 -0600 Subject: AOL postmaster rejections. In-Reply-To: <20151119090831.2cae03ca@jpeach-desktop.anbg.mssm.edu> References: <20151119090831.2cae03ca@jpeach-desktop.anbg.mssm.edu> Message-ID: <564E2349.5060901@ispn.net> John Peach wrote on 11/19/2015 8:08 AM: > Has anyone else with relatively large volumes of email seen a huge > spike in rejections from AOL recently? Yes. > There is no obvious reason why they are being rejected as it is a > generic message: > > Nov 18 12:10:39 pp-serve02 sendmail[1391]: tAIHAcPT001383: > mailin-04.mx.aol.com.: SMTP DATA-2 protocol error: 521 5.2.1 : AOL > will not accept delivery of this message. > > Looking back through my logs, I can see we've always had a few, but we > are now receiving a lot of complaints from users (physicians who cannot > email their patients) and I see this, starting on Monday: > > syslog-2015-11-16 > 588 > syslog-2015-11-17 > 1668 > syslog-2015-11-18 > 1937 > > and I already have 55 for today. Same; started this week. Only appears to affect one of our servers. Rejected messages by date: 2015-11-15 9 2015-11-15 4 2015-11-16 400 2015-11-17 710 2015-11-18 683 > > We have a whitelist / feedback loop set up with AOL, our IPs show clean > with them and our DNS / reverse DNS has not changed and resolves > properly. Same here > > We did raise a ticket with them, but it seems to have gone to the > usual /dev/null. Same here. I'm recommending AOL customers contact AOL for support. > > To reply off-list, please remove the VERP -nanog from my email address, From john-nanog at peachfamily.net Thu Nov 19 19:52:50 2015 From: john-nanog at peachfamily.net (John Peach) Date: Thu, 19 Nov 2015 14:52:50 -0500 Subject: AOL postmaster rejections. In-Reply-To: <564E2349.5060901@ispn.net> References: <20151119090831.2cae03ca@jpeach-desktop.anbg.mssm.edu> <564E2349.5060901@ispn.net> Message-ID: <20151119145250.73ba6a90@jpeach-desktop.anbg.mssm.edu> On Thu, 19 Nov 2015 13:30:17 -0600 Blake Hudson wrote: > > > John Peach wrote on 11/19/2015 8:08 AM: > > Has anyone else with relatively large volumes of email seen a huge > > spike in rejections from AOL recently? > Yes. > > > There is no obvious reason why they are being rejected as it is a > > generic message: > > > > Nov 18 12:10:39 pp-serve02 sendmail[1391]: tAIHAcPT001383: > > mailin-04.mx.aol.com.: SMTP DATA-2 protocol error: 521 5.2.1 : AOL > > will not accept delivery of this message. > > > > Looking back through my logs, I can see we've always had a few, but > > we are now receiving a lot of complaints from users (physicians who > > cannot email their patients) and I see this, starting on Monday: > > > > syslog-2015-11-16 > > 588 > > syslog-2015-11-17 > > 1668 > > syslog-2015-11-18 > > 1937 > > > > and I already have 55 for today. > Same; started this week. Only appears to affect one of our servers. Now that is interesting; I hadn't though to check that, but it is affecting 3 out of our 4 and they are all in the same subnet. > > Rejected messages by date: > 2015-11-15 > 9 > 2015-11-15 > 4 > 2015-11-16 > 400 > 2015-11-17 > 710 > 2015-11-18 > 683 > > > > > We have a whitelist / feedback loop set up with AOL, our IPs show > > clean with them and our DNS / reverse DNS has not changed and > > resolves properly. > Same here > > > > > We did raise a ticket with them, but it seems to have gone to the > > usual /dev/null. > Same here. I'm recommending AOL customers contact AOL for support. > > > > > To reply off-list, please remove the VERP -nanog from my email > > address, > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From nanog at email.todmue.de Thu Nov 19 15:34:34 2015 From: nanog at email.todmue.de (=?UTF-8?B?TWFyY28gR3J1w58=?=) Date: Thu, 19 Nov 2015 16:34:34 +0100 Subject: Is there a DNS lookup, traceroute, ping and HTTP GET as a service? In-Reply-To: References: Message-ID: <564DEC0A.3040900@email.todmue.de> Hi, On 11/18/2015 05:28 PM, Kurt Kraut via NANOG wrote: > I'm evaluating different datacenters and vendors accross the globe and it > isn't worthy to perform tests like DNS, traceroute, ping and HTTP GET from > my office. I need to be able to perform this tests remotely, from multiple > endpoints. As just suggested off-list, https://ring.nlnog.net/ might be worth a look. It requires sponsorship of a box on your own network to join though. Best, Marco From lists at tigertech.com Thu Nov 19 18:23:23 2015 From: lists at tigertech.com (Robert L Mathews) Date: Thu, 19 Nov 2015 10:23:23 -0800 Subject: AOL postmaster rejections. In-Reply-To: <20151119090831.2cae03ca@jpeach-desktop.anbg.mssm.edu> References: <20151119090831.2cae03ca@jpeach-desktop.anbg.mssm.edu> Message-ID: <564E139B.6060809@tigertech.com> On 11/19/15 6:08 AM, John Peach wrote: > Has anyone else with relatively large volumes of email seen a huge > spike in rejections from AOL recently? We also saw a large increase in this "AOL will not accept delivery of this message" problem earlier this week, despite also having "good reputation" on the affected IP addresses, no changes in what we send, no DNS changes, etc. It happened on about half our outbound mail server IP addresses, but not on the others. We temporarily switched to using only the "good" IP addresses to send to AOL, and they happily accept the same messages. -- Robert L Mathews, Tiger Technologies, http://www.tigertech.net/ From matlockken at gmail.com Thu Nov 19 18:43:36 2015 From: matlockken at gmail.com (Ken Matlock) Date: Thu, 19 Nov 2015 11:43:36 -0700 Subject: bad announcement taxonomy In-Reply-To: <18414.1447913729@turing-police.cc.vt.edu> References: <8EF67853-078A-429C-946D-A6AEA6A0F5D6@hopcount.ca> <0ED16430-76A1-43D5-BB28-97A3E8DCCDF1@iname.com> <18414.1447913729@turing-police.cc.vt.edu> Message-ID: Origin NAT? ;) Ken > On Nov 18, 2015, at 11:15 PM, Valdis.Kletnieks at vt.edu wrote: > > On Wed, 18 Nov 2015 18:21:32 -0600, David Edelman said: >> How about Origin Obfuscation > > Obfuscation implies intent. Most leaks and mis-announcements don't > have intent because they're whoopsies. From arturo.servin at gmail.com Thu Nov 19 23:24:09 2015 From: arturo.servin at gmail.com (Arturo Servin) Date: Thu, 19 Nov 2015 15:24:09 -0800 Subject: bad announcement taxonomy In-Reply-To: <18414.1447913729@turing-police.cc.vt.edu> References: <8EF67853-078A-429C-946D-A6AEA6A0F5D6@hopcount.ca> <0ED16430-76A1-43D5-BB28-97A3E8DCCDF1@iname.com> <18414.1447913729@turing-police.cc.vt.edu> Message-ID: On Wed, Nov 18, 2015 at 10:15 PM, wrote: > > How about Origin Obfuscation > > Obfuscation implies intent. Most leaks and mis-announcements don't > have intent because they're whoopsies. > Well, if you take a route, change its origin as your own (or any other) and re-announce it (perhaps just a smaller prefix of it) I would assume some intent. Or they are super whoopsies. .as From aaron at heyaaron.com Fri Nov 20 00:39:21 2015 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Thu, 19 Nov 2015 16:39:21 -0800 Subject: Comcast eastern Washington storm update? Message-ID: I know the east side of my state was nailed with a big storm. The Gov declared a state of emergency. Comcast service for several of my clients has understandably been down since Tuesday. I called in a few times over the last two days and the automated message keeps saying "service should be restored by 12:01 PM today", after that time passes the message gets changed to 7:01 PM, then to 8:01 AM, then 12:01 PM. (Always '01'--what's with that?) One time I let the call get through to a rep and they couldn't give any information on the extent of the damage or an ETA. Can anyone at Comcast shed some light on the disaster over there or give a rough idea on service restoration? As always, I appreciate the hard work from the guys in the trenches and the engineers that miraculously seem to keep my clients up 24/7. (Just for fun, attached are stats about the router for 365 days before the storm hit--and most of that 'unreachable' time was probably issues with the monitoring server.) Thanks again for all your hard work. -A From Valdis.Kletnieks at vt.edu Fri Nov 20 01:51:44 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 19 Nov 2015 20:51:44 -0500 Subject: bad announcement taxonomy In-Reply-To: References: <8EF67853-078A-429C-946D-A6AEA6A0F5D6@hopcount.ca> <0ED16430-76A1-43D5-BB28-97A3E8DCCDF1@iname.com> <18414.1447913729@turing-police.cc.vt.edu> Message-ID: <50533.1447984304@turing-police.cc.vt.edu> On Thu, 19 Nov 2015 15:24:09 -0800, Arturo Servin said: > Well, if you take a route, change its origin as your own (or any other) and > re-announce it (perhaps just a smaller prefix of it) I would assume some > intent. > > Or they are super whoopsies. AS7007 was a whoopsie. And in fact, I'll go out on a limb and say that most, if not all, EGP->IGP->EGP re-injections are whoopsies. Because let's face it, if you had *intent*, you'd just start announcing it. From aaron at heyaaron.com Fri Nov 20 02:10:27 2015 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Thu, 19 Nov 2015 18:10:27 -0800 Subject: Comcast eastern Washington storm update? In-Reply-To: References: Message-ID: Er, I should have mentioned 'Spokane, WA'. On Nov 19, 2015 4:39 PM, "Aaron C. de Bruyn" wrote: > I know the east side of my state was nailed with a big storm. The Gov > declared a state of emergency. > > Comcast service for several of my clients has understandably been down > since Tuesday. > > I called in a few times over the last two days and the automated message > keeps saying "service should be restored by 12:01 PM today", after that > time passes the message gets changed to 7:01 PM, then to 8:01 AM, then > 12:01 PM. (Always '01'--what's with that?) > > One time I let the call get through to a rep and they couldn't give any > information on the extent of the damage or an ETA. > > Can anyone at Comcast shed some light on the disaster over there or give a > rough idea on service restoration? > > As always, I appreciate the hard work from the guys in the trenches and > the engineers that miraculously seem to keep my clients up 24/7. (Just for > fun, attached are stats about the router for 365 days before the storm > hit--and most of that 'unreachable' time was probably issues with the > monitoring server.) > > Thanks again for all your hard work. > > -A > > > From randy at psg.com Fri Nov 20 07:22:55 2015 From: randy at psg.com (Randy Bush) Date: Fri, 20 Nov 2015 08:22:55 +0100 Subject: bad announcement taxonomy In-Reply-To: References: <8EF67853-078A-429C-946D-A6AEA6A0F5D6@hopcount.ca> <0ED16430-76A1-43D5-BB28-97A3E8DCCDF1@iname.com> <18414.1447913729@turing-police.cc.vt.edu> Message-ID: > Well, if you take a route, change its origin as your own (or any > other) and re-announce it (perhaps just a smaller prefix of it) I > would assume some intent. > > Or they are super whoopsies. the original 7007, telkom malasia, ... were super whoopsies. the classic of redistributing bgp into igp and then igp back to bgp (unfiltered, no sugar or cream). the kind of stuff we warn about in class. randy From mark.tinka at seacom.mu Fri Nov 20 08:29:17 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 20 Nov 2015 10:29:17 +0200 Subject: Project Fi and the Great Firewall In-Reply-To: References: <208D7CF9-D840-4A09-8768-602778A762F1@arbor.net> Message-ID: <564ED9DD.8050606@seacom.mu> On 15/Nov/15 05:08, Jared Geiger wrote: > When you roam onto another cellular network other than your home network, > your data is encapsulated and sent back to your home network before going > out to the internet. This is to provide a seamless experience for the > customer. I always felt it was just to ease billing headaches. Local hand-off has the potential to make billing more difficult. Not doing that is at the expense of a better experience for the customer. Mark. From mark.tinka at seacom.mu Fri Nov 20 08:31:48 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 20 Nov 2015 10:31:48 +0200 Subject: Project Fi and the Great Firewall In-Reply-To: References: Message-ID: <564EDA74.4090107@seacom.mu> On 15/Nov/15 06:02, Yury Shefer wrote: > My team mate was traveling to China with his Nexus 6 (with Project Fi > SIM-card) and was able to access Google services. The phone uses roaming > data to access Google and your phone gets IP assigned by your home mobile > network packet gateway (P-GW). There is no local data break-out. Part of the IPX spiel has been about encouraging local break-out to improve the practical experience of the roamer. However, the excuse this does not happen is the difficulty that brings to billing, despite all the talk about Diametre signaling in IPX infrastructure... You can imagine what my experience is like roaming in Honolulu when I live in South Africa... Mark. From Byrn.Baker at charter.com Thu Nov 19 21:03:27 2015 From: Byrn.Baker at charter.com (Baker, Byrn) Date: Thu, 19 Nov 2015 15:03:27 -0600 Subject: bad announcement taxonomy In-Reply-To: References: <8EF67853-078A-429C-946D-A6AEA6A0F5D6@hopcount.ca> <0ED16430-76A1-43D5-BB28-97A3E8DCCDF1@iname.com> <18414.1447913729@turing-police.cc.vt.edu> Message-ID: Don't get on Kens bad side. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ken Matlock Sent: Thursday, November 19, 2015 12:44 PM To: Valdis.Kletnieks at vt.edu Cc: North American Network Operators' Group Subject: Re: bad announcement taxonomy Origin NAT? ;) Ken > On Nov 18, 2015, at 11:15 PM, Valdis.Kletnieks at vt.edu wrote: > > On Wed, 18 Nov 2015 18:21:32 -0600, David Edelman said: >> How about Origin Obfuscation > > Obfuscation implies intent. Most leaks and mis-announcements don't > have intent because they're whoopsies. From jared at puck.nether.net Fri Nov 20 14:05:42 2015 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 20 Nov 2015 09:05:42 -0500 Subject: bad announcement taxonomy In-Reply-To: References: <8EF67853-078A-429C-946D-A6AEA6A0F5D6@hopcount.ca> <0ED16430-76A1-43D5-BB28-97A3E8DCCDF1@iname.com> <18414.1447913729@turing-police.cc.vt.edu> Message-ID: Did someone say NAT? https://www.youtube.com/watch?v=v26BAlfWBm8 - Jared > On Nov 19, 2015, at 4:03 PM, Baker, Byrn wrote: > > Don't get on Kens bad side. > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ken Matlock > Sent: Thursday, November 19, 2015 12:44 PM > To: Valdis.Kletnieks at vt.edu > Cc: North American Network Operators' Group > Subject: Re: bad announcement taxonomy > > Origin NAT? ;) > > Ken > >> On Nov 18, 2015, at 11:15 PM, Valdis.Kletnieks at vt.edu wrote: >> >> On Wed, 18 Nov 2015 18:21:32 -0600, David Edelman said: >>> How about Origin Obfuscation >> >> Obfuscation implies intent. Most leaks and mis-announcements don't >> have intent because they're whoopsies. From tim at pelican.org Fri Nov 20 15:07:30 2015 From: tim at pelican.org (tim at pelican.org) Date: Fri, 20 Nov 2015 15:07:30 -0000 (GMT) Subject: bad announcement taxonomy In-Reply-To: References: <8EF67853-078A-429C-946D-A6AEA6A0F5D6@hopcount.ca> <0ED16430-76A1-43D5-BB28-97A3E8DCCDF1@iname.com> <18414.1447913729@turing-police.cc.vt.edu> Message-ID: <1448032050.871111483@apps.rackspace.com> On Friday, 20 November, 2015 14:05, "Jared Mauch" said: > Did someone say NAT? > > https://www.youtube.com/watch?v=v26BAlfWBm8 Now *that's* how to make my Friday afternoon! You, sir, win the Internet for today. Regards, Tim. From jra at baylink.com Fri Nov 20 15:45:43 2015 From: jra at baylink.com (Jay Ashworth) Date: Fri, 20 Nov 2015 10:45:43 -0500 (EST) Subject: Binge On! - And So This is Net Neutrality? Message-ID: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> According to: http://www.engadget.com/2015/11/20/fcc-chairman-gives-t-mobiles-binge-on-the-thumbs-up/ Chairman Wheeler thinks that T-mob's new "customers can get uncapped media stream data, but only from the people we like" service called Binge On is pro-competition. My take on this is that the service is *precisely* what Net Neutrality was supposed to prevent -- carriers offering paid fast-lanes to content providers -- and that this is anti-competitive to the sort of "upstart YouTube" entities that NN was supposed to protect... and that *that* is the competition that NN was supposed to protect. And I just said the same thing two different ways. Cause does anyone here think that T-mob is giving those *carriers* pride of place *for free*? Corporations don't - in my experience - give away lots of money out of the goodness of their hearts. Cheers, -- jr 'whacky weekend' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From scott.brim at gmail.com Fri Nov 20 16:16:41 2015 From: scott.brim at gmail.com (Scott Brim) Date: Fri, 20 Nov 2015 11:16:41 -0500 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> Message-ID: On Fri, Nov 20, 2015 at 10:45 AM, Jay Ashworth wrote: > According to: > > http://www.engadget.com/2015/11/20/fcc-chairman-gives-t-mobiles-binge-on-the-thumbs-up/ > > Chairman Wheeler thinks that T-mob's new "customers can get uncapped media > stream data, but only from the people we like" service called Binge On > is pro-competition. > > My take on this is that the service is *precisely* what Net Neutrality > was supposed to prevent -- carriers offering paid fast-lanes to content > providers -- and that this is anti-competitive to the sort of "upstart > YouTube" entities that NN was supposed to protect... > > and that *that* is the competition that NN was supposed to protect. What I read was that as long as a video offerer marks its traffic and is certified in a few other ways, anyone can send video content cap-free. No I don't know what the criteria are. Does anyone here? I also think I remember that there is no significant cost to certification, i.e. this is not a paid fast lane. If this is all true, this doesn't bother me, and could do everyone a favor by getting definitions clearer and getting traffic marked. From shane at ronan-online.com Fri Nov 20 16:24:41 2015 From: shane at ronan-online.com (Shane Ronan) Date: Fri, 20 Nov 2015 11:24:41 -0500 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> Message-ID: <564F4949.2060508@ronan-online.com> T-Mobile claims they are not accepting any payment from these content providers for inclusion in Binge On. "Onstage today, Legere said any company can apply to join the Binge On program. "Anyone who can meet our technical requirement, we?ll include," he said. "This is not a net neutrality problem." Legere pointed to the fact that Binge On doesn't charge providers for inclusion and customers don't pay to access it." http://www.theverge.com/2015/11/10/9704482/t-mobile-uncarrier-binge-on-netflix-hbo-streaming On 11/20/15 10:45 AM, Jay Ashworth wrote: > According to: > > http://www.engadget.com/2015/11/20/fcc-chairman-gives-t-mobiles-binge-on-the-thumbs-up/ > > Chairman Wheeler thinks that T-mob's new "customers can get uncapped media > stream data, but only from the people we like" service called Binge On > is pro-competition. > > My take on this is that the service is *precisely* what Net Neutrality > was supposed to prevent -- carriers offering paid fast-lanes to content > providers -- and that this is anti-competitive to the sort of "upstart > YouTube" entities that NN was supposed to protect... > > and that *that* is the competition that NN was supposed to protect. > > And I just said the same thing two different ways. > > Cause does anyone here think that T-mob is giving those *carriers* pride > of place *for free*? > > Corporations don't - in my experience - give away lots of money out of > the goodness of their hearts. > > Cheers, > -- jr 'whacky weekend' a From mike at mtcc.com Fri Nov 20 16:32:08 2015 From: mike at mtcc.com (Michael Thomas) Date: Fri, 20 Nov 2015 08:32:08 -0800 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> Message-ID: <564F4B08.3020402@mtcc.com> On 11/20/2015 08:16 AM, Scott Brim wrote: > On Fri, Nov 20, 2015 at 10:45 AM, Jay Ashworth wrote: >> According to: >> >> http://www.engadget.com/2015/11/20/fcc-chairman-gives-t-mobiles-binge-on-the-thumbs-up/ >> >> Chairman Wheeler thinks that T-mob's new "customers can get uncapped media >> stream data, but only from the people we like" service called Binge On >> is pro-competition. >> >> My take on this is that the service is *precisely* what Net Neutrality >> was supposed to prevent -- carriers offering paid fast-lanes to content >> providers -- and that this is anti-competitive to the sort of "upstart >> YouTube" entities that NN was supposed to protect... >> >> and that *that* is the competition that NN was supposed to protect. > What I read was that as long as a video offerer marks its traffic and > is certified in a few other ways, anyone can send video content > cap-free. No I don't know what the criteria are. Does anyone here? I > also think I remember that there is no significant cost to > certification, i.e. this is not a paid fast lane. If this is all > true, this doesn't bother me, and could do everyone a favor by getting > definitions clearer and getting traffic marked. Why do you need certification? I doubt many people have a problem with qos marking, but "certification" sort of gives me the creeps. Mike From josh at kyneticwifi.com Fri Nov 20 16:32:41 2015 From: josh at kyneticwifi.com (Josh Reynolds) Date: Fri, 20 Nov 2015 10:32:41 -0600 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: <564F4949.2060508@ronan-online.com> References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <564F4949.2060508@ronan-online.com> Message-ID: I believe there may be a catch though: I don't think they can pick and choose which streaming providers they allow their customers to stream for free. As long as their streaming program is a "catch-all" for streaming video, they can claim they are doing what they can (within reason) to exempt streaming video from their data caps and are probably fine with the FCC. For instance, using the "streaming video" filter in Procera or a similar DPI product. If it is found they are picking and choosing which content is free (intentionally) they might be in trouble for that part. They are not paying for this feature with the content providers (no paid prioritization) and it's good for consumers. It probably sucks for WISPs until those cell sectors start getting filled up though ;) On Fri, Nov 20, 2015 at 10:24 AM, Shane Ronan wrote: > T-Mobile claims they are not accepting any payment from these content > providers for inclusion in Binge On. > > "Onstage today, Legere said any company can apply to join the Binge On > program. "Anyone who can meet our technical requirement, we?ll include," he > said. "This is not a net neutrality problem." Legere pointed to the fact > that Binge On doesn't charge providers for inclusion and customers don't pay > to access it." > http://www.theverge.com/2015/11/10/9704482/t-mobile-uncarrier-binge-on-netflix-hbo-streaming > > > > On 11/20/15 10:45 AM, Jay Ashworth wrote: >> >> According to: >> >> >> http://www.engadget.com/2015/11/20/fcc-chairman-gives-t-mobiles-binge-on-the-thumbs-up/ >> >> Chairman Wheeler thinks that T-mob's new "customers can get uncapped media >> stream data, but only from the people we like" service called Binge On >> is pro-competition. >> >> My take on this is that the service is *precisely* what Net Neutrality >> was supposed to prevent -- carriers offering paid fast-lanes to content >> providers -- and that this is anti-competitive to the sort of "upstart >> YouTube" entities that NN was supposed to protect... >> >> and that *that* is the competition that NN was supposed to protect. >> >> And I just said the same thing two different ways. >> >> Cause does anyone here think that T-mob is giving those *carriers* pride >> of place *for free*? >> >> Corporations don't - in my experience - give away lots of money out of >> the goodness of their hearts. >> >> Cheers, >> -- jr 'whacky weekend' a > > From morrowc.lists at gmail.com Fri Nov 20 16:33:46 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 20 Nov 2015 11:33:46 -0500 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: <564F4949.2060508@ronan-online.com> References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <564F4949.2060508@ronan-online.com> Message-ID: (CAUTION CAUTION CAUTION - just a swag) isn't this just moving content to v6 and/or behind the great-nat-of-tmo? 'reduce our need for NAT infra and incent customers to stop using NAT requiring services' ? On Fri, Nov 20, 2015 at 11:24 AM, Shane Ronan wrote: > T-Mobile claims they are not accepting any payment from these content > providers for inclusion in Binge On. > > "Onstage today, Legere said any company can apply to join the Binge On > program. "Anyone who can meet our technical requirement, we?ll include," he > said. "This is not a net neutrality problem." Legere pointed to the fact > that Binge On doesn't charge providers for inclusion and customers don't pay > to access it." > http://www.theverge.com/2015/11/10/9704482/t-mobile-uncarrier-binge-on-netflix-hbo-streaming > > > > On 11/20/15 10:45 AM, Jay Ashworth wrote: >> >> According to: >> >> >> http://www.engadget.com/2015/11/20/fcc-chairman-gives-t-mobiles-binge-on-the-thumbs-up/ >> >> Chairman Wheeler thinks that T-mob's new "customers can get uncapped media >> stream data, but only from the people we like" service called Binge On >> is pro-competition. >> >> My take on this is that the service is *precisely* what Net Neutrality >> was supposed to prevent -- carriers offering paid fast-lanes to content >> providers -- and that this is anti-competitive to the sort of "upstart >> YouTube" entities that NN was supposed to protect... >> >> and that *that* is the competition that NN was supposed to protect. >> >> And I just said the same thing two different ways. >> >> Cause does anyone here think that T-mob is giving those *carriers* pride >> of place *for free*? >> >> Corporations don't - in my experience - give away lots of money out of >> the goodness of their hearts. >> >> Cheers, >> -- jr 'whacky weekend' a > > From Steve.Mikulasik at civeo.com Fri Nov 20 16:37:20 2015 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Fri, 20 Nov 2015 16:37:20 +0000 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: <564F4949.2060508@ronan-online.com> References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <564F4949.2060508@ronan-online.com> Message-ID: What are these technical requirements? I feel like these would punish small upstarts well helping protect large incumbent services from competition. Even if you don't demand payment, you can still hurt the fairness of the internet this way. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Shane Ronan Sent: Friday, November 20, 2015 9:25 AM To: nanog at nanog.org Subject: Re: Binge On! - And So This is Net Neutrality? T-Mobile claims they are not accepting any payment from these content providers for inclusion in Binge On. "Onstage today, Legere said any company can apply to join the Binge On program. "Anyone who can meet our technical requirement, we?ll include," he said. "This is not a net neutrality problem." Legere pointed to the fact that Binge On doesn't charge providers for inclusion and customers don't pay to access it." http://www.theverge.com/2015/11/10/9704482/t-mobile-uncarrier-binge-on-netflix-hbo-streaming On 11/20/15 10:45 AM, Jay Ashworth wrote: > According to: > > http://www.engadget.com/2015/11/20/fcc-chairman-gives-t-mobiles-binge-on-the-thumbs-up/ > > Chairman Wheeler thinks that T-mob's new "customers can get uncapped > media stream data, but only from the people we like" service called > Binge On is pro-competition. > > My take on this is that the service is *precisely* what Net Neutrality > was supposed to prevent -- carriers offering paid fast-lanes to > content providers -- and that this is anti-competitive to the sort of > "upstart YouTube" entities that NN was supposed to protect... > > and that *that* is the competition that NN was supposed to protect. > > And I just said the same thing two different ways. > > Cause does anyone here think that T-mob is giving those *carriers* > pride of place *for free*? > > Corporations don't - in my experience - give away lots of money out of > the goodness of their hearts. > > Cheers, > -- jr 'whacky weekend' a From Steve.Mikulasik at civeo.com Fri Nov 20 17:03:24 2015 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Fri, 20 Nov 2015 17:03:24 +0000 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: <54d6d31bb38d432f89a2966f8af532ed@SEAEXCHMBX04.olympus.F5Net.com> References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <564F4949.2060508@ronan-online.com> <54d6d31bb38d432f89a2966f8af532ed@SEAEXCHMBX04.olympus.F5Net.com> Message-ID: That is much better than I thought. Although, I don't think the person who wrote this understands what UDP is. "Use of technology protocols that are demonstrated to prevent video stream detection, such as User Datagram Protocol ?UDP? on any platform will exclude video streams from that content provider" -----Original Message----- From: Ian Smith [mailto:I.Smith at F5.com] Sent: Friday, November 20, 2015 9:52 AM To: Steve Mikulasik ; Shane Ronan ; nanog at nanog.org Subject: RE: Binge On! - And So This is Net Neutrality? http://www.t-mobile.com/content/dam/tmo/en-g/pdf/BingeOn-Video-Technical-Criteria-November-2015.pdf -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Steve Mikulasik Sent: Friday, November 20, 2015 11:37 AM To: Shane Ronan ; nanog at nanog.org Subject: RE: Binge On! - And So This is Net Neutrality? What are these technical requirements? I feel like these would punish small upstarts well helping protect large incumbent services from competition. Even if you don't demand payment, you can still hurt the fairness of the internet this way. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Shane Ronan Sent: Friday, November 20, 2015 9:25 AM To: nanog at nanog.org Subject: Re: Binge On! - And So This is Net Neutrality? T-Mobile claims they are not accepting any payment from these content providers for inclusion in Binge On. "Onstage today, Legere said any company can apply to join the Binge On program. "Anyone who can meet our technical requirement, we?ll include," he said. "This is not a net neutrality problem." Legere pointed to the fact that Binge On doesn't charge providers for inclusion and customers don't pay to access it." http://www.theverge.com/2015/11/10/9704482/t-mobile-uncarrier-binge-on-netflix-hbo-streaming On 11/20/15 10:45 AM, Jay Ashworth wrote: > According to: > > > http://www.engadget.com/2015/11/20/fcc-chairman-gives-t-mobiles-binge- > on-the-thumbs-up/ > > Chairman Wheeler thinks that T-mob's new "customers can get uncapped > media stream data, but only from the people we like" service called > Binge On is pro-competition. > > My take on this is that the service is *precisely* what Net Neutrality > was supposed to prevent -- carriers offering paid fast-lanes to > content providers -- and that this is anti-competitive to the sort of > "upstart YouTube" entities that NN was supposed to protect... > > and that *that* is the competition that NN was supposed to protect. > > And I just said the same thing two different ways. > > Cause does anyone here think that T-mob is giving those *carriers* > pride of place *for free*? > > Corporations don't - in my experience - give away lots of money out of > the goodness of their hearts. > > Cheers, > -- jr 'whacky weekend' a From blake at ispn.net Fri Nov 20 17:24:00 2015 From: blake at ispn.net (Blake Hudson) Date: Fri, 20 Nov 2015 11:24:00 -0600 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> Message-ID: <564F5730.3050707@ispn.net> Considering T-Mobile's proposal is intended to favor streaming music and video services, I think it clearly violates net neutrality which is intended to not only promote competition in existing applications, but also in new (possibly undeveloped) applications. This proposal simply entrenches streaming video/music by artificially reducing the cost to operators in these fields while leaving costs the same for operators in other fields - medical imaging, video conferencing, online backup, etc. I believe the sum affect is a reduction in competition and growth of the internet as a whole, the antithesis to the spirit of net neutrality. From jra at baylink.com Fri Nov 20 17:29:35 2015 From: jra at baylink.com (Jay Ashworth) Date: Fri, 20 Nov 2015 12:29:35 -0500 (EST) Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: Message-ID: <6102871.32.1448040575700.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Brim" > What I read was that as long as a video offerer marks its traffic and > is certified in a few other ways, anyone can send video content > cap-free. No I don't know what the criteria are. Does anyone here? I > also think I remember that there is no significant cost to > certification, i.e. this is not a paid fast lane. If this is all > true, this doesn't bother me, and could do everyone a favor by getting > definitions clearer and getting traffic marked. Izzat so. If that's true, then more power to them. I hadn't seen that deep a dive in any of the coverage I'd read. 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 Nov 20 17:46:01 2015 From: blake at ispn.net (Blake Hudson) Date: Fri, 20 Nov 2015 11:46:01 -0600 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <564F5730.3050707@ispn.net> Message-ID: <564F5C59.6000901@ispn.net> It's not. And that's the point. This proposal, and ones similar, stifle growth of applications. If there are additional (artificial) burdens for operating in a field it becomes harder to get into. Because it's harder to get into, fewer operators compete. [Note, we just reduced open competition, one tenet of Net Neutrality] Because there are fewer operators there will be less competition. Less competition increases prices and fewer customers take the service. Because few people use the application, the network operator has no incentive to support the application well. [Note, we just reduced the freedom to run applications] Because the network doesn't support the application well, few people use the application. It's circular and it slows growth. Just because there may be inherent challenges to offering an application (bandwidth, for example), doesn't mean that adding another one (per application bandwidth caps) is desirable. Josh Reynolds wrote on 11/20/2015 11:29 AM: > How much medical imaging and video conference and online backup is > done over cell networks? Those are very high bandwidth tasks that > would quickly suck up a data cap. Until LTE came along, doing that was > often hit/miss as far as the reliability of the connection and the > speed. > > In an area with LTE, there are often better connectivity options. In > an area without LTE, well, how much medical imaging and data backup is > done over those 3G and satellite connections? > > On Fri, Nov 20, 2015 at 11:24 AM, Blake Hudson wrote: >> Considering T-Mobile's proposal is intended to favor streaming music and >> video services, I think it clearly violates net neutrality which is intended >> to not only promote competition in existing applications, but also in new >> (possibly undeveloped) applications. This proposal simply entrenches >> streaming video/music by artificially reducing the cost to operators in >> these fields while leaving costs the same for operators in other fields - >> medical imaging, video conferencing, online backup, etc. I believe the sum >> affect is a reduction in competition and growth of the internet as a whole, >> the antithesis to the spirit of net neutrality. From clay584 at gmail.com Fri Nov 20 18:00:58 2015 From: clay584 at gmail.com (Clay Curtis) Date: Fri, 20 Nov 2015 13:00:58 -0500 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: <564F5C59.6000901@ispn.net> References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <564F5730.3050707@ispn.net> <564F5C59.6000901@ispn.net> Message-ID: This is just the start. Providers will push the limits slowly and will eventually get to where they want to be. t-mob is doing this in such a way that consumer's will not object. When the general public doesn't object (because they are getting "free" data) that makes it a lot easier for the FCC to look past the fact that this is a violation of basic net neutrality. Reminds me of the boiling frog analogy ( https://en.wikipedia.org/wiki/Boiling_frog). Clay On Fri, Nov 20, 2015 at 12:46 PM, Blake Hudson wrote: > It's not. And that's the point. > > This proposal, and ones similar, stifle growth of applications. If there > are additional (artificial) burdens for operating in a field it becomes > harder to get into. Because it's harder to get into, fewer operators > compete. [Note, we just reduced open competition, one tenet of Net > Neutrality] Because there are fewer operators there will be less > competition. Less competition increases prices and fewer customers take the > service. Because few people use the application, the network operator has > no incentive to support the application well. [Note, we just reduced the > freedom to run applications] Because the network doesn't support the > application well, few people use the application. It's circular and it > slows growth. > > Just because there may be inherent challenges to offering an application > (bandwidth, for example), doesn't mean that adding another one (per > application bandwidth caps) is desirable. > > Josh Reynolds wrote on 11/20/2015 11:29 AM: > >> How much medical imaging and video conference and online backup is >> done over cell networks? Those are very high bandwidth tasks that >> would quickly suck up a data cap. Until LTE came along, doing that was >> often hit/miss as far as the reliability of the connection and the >> speed. >> >> In an area with LTE, there are often better connectivity options. In >> an area without LTE, well, how much medical imaging and data backup is >> done over those 3G and satellite connections? >> >> >> On Fri, Nov 20, 2015 at 11:24 AM, Blake Hudson wrote: >> >>> Considering T-Mobile's proposal is intended to favor streaming music and >>> video services, I think it clearly violates net neutrality which is >>> intended >>> to not only promote competition in existing applications, but also in new >>> (possibly undeveloped) applications. This proposal simply entrenches >>> streaming video/music by artificially reducing the cost to operators in >>> these fields while leaving costs the same for operators in other fields - >>> medical imaging, video conferencing, online backup, etc. I believe the >>> sum >>> affect is a reduction in competition and growth of the internet as a >>> whole, >>> the antithesis to the spirit of net neutrality. >>> >> > From cscora at apnic.net Fri Nov 20 18:11:30 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 21 Nov 2015 04:11:30 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201511201811.tAKIBU1X024821@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, SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. 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 21 Nov, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 571013 Prefixes after maximum aggregation (per Origin AS): 212430 Deaggregation factor: 2.69 Unique aggregates announced (without unneeded subnets): 279150 Total ASes present in the Internet Routing Table: 52060 Prefixes per ASN: 10.97 Origin-only ASes present in the Internet Routing Table: 36697 Origin ASes announcing only one prefix: 15985 Transit ASes present in the Internet Routing Table: 6347 Transit-only ASes present in the Internet Routing Table: 166 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 50 Max AS path prepend of ASN ( 55644) 41 Prefixes from unregistered ASNs in the Routing Table: 1045 Unregistered ASNs in the Routing Table: 377 Number of 32-bit ASNs allocated by the RIRs: 11786 Number of 32-bit ASNs visible in the Routing Table: 9016 Prefixes from 32-bit ASNs in the Routing Table: 34268 Number of bogon 32-bit ASNs visible in the Routing Table: 14 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 431 Number of addresses announced to Internet: 2798739168 Equivalent to 166 /8s, 209 /16s and 94 /24s Percentage of available address space announced: 75.6 Percentage of allocated address space announced: 75.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.8 Total number of prefixes smaller than registry allocations: 187607 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 145397 Total APNIC prefixes after maximum aggregation: 40151 APNIC Deaggregation factor: 3.62 Prefixes being announced from the APNIC address blocks: 153613 Unique aggregates announced from the APNIC address blocks: 61752 APNIC Region origin ASes present in the Internet Routing Table: 5117 APNIC Prefixes per ASN: 30.02 APNIC Region origin ASes announcing only one prefix: 1200 APNIC Region transit ASes present in the Internet Routing Table: 884 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 50 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1718 Number of APNIC addresses announced to Internet: 755568544 Equivalent to 45 /8s, 9 /16s and 15 /24s Percentage of available APNIC address space announced: 88.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 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: 180528 Total ARIN prefixes after maximum aggregation: 88974 ARIN Deaggregation factor: 2.03 Prefixes being announced from the ARIN address blocks: 183890 Unique aggregates announced from the ARIN address blocks: 87194 ARIN Region origin ASes present in the Internet Routing Table: 16512 ARIN Prefixes per ASN: 11.14 ARIN Region origin ASes announcing only one prefix: 5990 ARIN Region transit ASes present in the Internet Routing Table: 1712 Average ARIN Region AS path length visible: 3.7 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 832 Number of ARIN addresses announced to Internet: 1100853184 Equivalent to 65 /8s, 157 /16s and 175 /24s Percentage of available ARIN address space announced: 58.2 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, 64198-64296, 393216-395164 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: 137198 Total RIPE prefixes after maximum aggregation: 68452 RIPE Deaggregation factor: 2.00 Prefixes being announced from the RIPE address blocks: 144762 Unique aggregates announced from the RIPE address blocks: 89761 RIPE Region origin ASes present in the Internet Routing Table: 18018 RIPE Prefixes per ASN: 8.03 RIPE Region origin ASes announcing only one prefix: 7996 RIPE Region transit ASes present in the Internet Routing Table: 2968 Average RIPE Region AS path length visible: 4.8 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 4212 Number of RIPE addresses announced to Internet: 701424000 Equivalent to 41 /8s, 206 /16s and 225 /24s Percentage of available RIPE address space announced: 102.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 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: 60392 Total LACNIC prefixes after maximum aggregation: 11717 LACNIC Deaggregation factor: 5.15 Prefixes being announced from the LACNIC address blocks: 72900 Unique aggregates announced from the LACNIC address blocks: 33932 LACNIC Region origin ASes present in the Internet Routing Table: 2468 LACNIC Prefixes per ASN: 29.54 LACNIC Region origin ASes announcing only one prefix: 606 LACNIC Region transit ASes present in the Internet Routing Table: 537 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: 2084 Number of LACNIC addresses announced to Internet: 169848832 Equivalent to 10 /8s, 31 /16s and 176 /24s Percentage of available LACNIC address space announced: 101.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + 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: 13143 Total AfriNIC prefixes after maximum aggregation: 3095 AfriNIC Deaggregation factor: 4.25 Prefixes being announced from the AfriNIC address blocks: 15417 Unique aggregates announced from the AfriNIC address blocks: 6152 AfriNIC Region origin ASes present in the Internet Routing Table: 736 AfriNIC Prefixes per ASN: 20.95 AfriNIC Region origin ASes announcing only one prefix: 193 AfriNIC Region transit ASes present in the Internet Routing Table: 168 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 19 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 170 Number of AfriNIC addresses announced to Internet: 70674944 Equivalent to 4 /8s, 54 /16s and 106 /24s Percentage of available AfriNIC address space announced: 70.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 4538 5600 4192 76 China Education and Research 4766 2993 11135 989 Korea Telecom 7545 2954 340 143 TPG Telecom Limited 17974 2731 914 96 PT Telekomunikasi Indonesia 4755 2065 431 230 TATA Communications formerly 9829 2022 1407 304 National Internet Backbone 9808 1659 8639 18 Guangdong Mobile Communicatio 4812 1609 2099 114 China Telecom (Group) 4808 1550 2265 488 CNCGROUP IP network China169 9583 1495 119 560 Sify Limited 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 22773 3245 2964 143 Cox Communications Inc. 3356 2553 10689 511 Level 3 Communications, Inc. 6389 2510 3687 42 BellSouth.net Inc. 18566 2216 394 277 MegaPath Corporation 20115 1887 1897 400 Charter Communications 6983 1699 849 239 EarthLink, Inc. 30036 1647 329 361 Mediacom Communications Corp 4323 1578 1020 398 tw telecom holdings, inc. 209 1479 4325 1232 Qwest Communications Company, 701 1392 11415 666 MCI Communications Services, 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 39891 2473 129 7 SaudiNet, Saudi Telecom Compa 20940 2219 876 1598 Akamai International B.V. 34984 1920 320 403 TELLCOM ILETISIM HIZMETLERI A 8402 1197 544 15 OJSC "Vimpelcom" 8551 1088 376 53 Bezeq International-Ltd 13188 1074 97 79 TOV "Bank-Inform" 12479 1042 982 84 France Telecom Espana SA 31148 1041 47 41 Freenet Ltd. 9198 971 350 29 JSC Kazakhtelecom 6830 892 2706 466 Liberty Global Operations B.V 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 10620 3400 541 160 Telmex Colombia S.A. 8151 2108 3334 496 Uninet S.A. de C.V. 7303 1578 943 237 Telecom Argentina S.A. 6503 1379 437 57 Axtel, S.A.B. de C.V. 28573 1313 2166 117 NET Servi?os de Comunica??o S 11830 1094 364 24 Instituto Costarricense de El 6147 1040 376 34 Telefonica del Peru S.A.A. 26615 1002 2325 34 Tim Celular S.A. 7738 995 1882 41 Telemar Norte Leste S.A. 3816 967 451 178 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 8452 1112 1470 14 TE-AS 24863 1070 409 38 Link Egypt (Link.NET) 37611 571 38 42 Afrihost-Brevis Computer Serv 36903 522 263 102 Office National des Postes et 36992 437 1229 32 ETISALAT MISR 37492 326 192 74 Orange Tunisie 29571 243 21 11 Cote d'Ivoire Telecom 24835 234 146 12 Vodafone Data 3741 221 837 183 Internet Solutions 15706 171 32 6 Sudatel (Sudan Telecom Co. Lt 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 4538 5600 4192 76 China Education and Research 10620 3400 541 160 Telmex Colombia S.A. 22773 3245 2964 143 Cox Communications Inc. 4766 2993 11135 989 Korea Telecom 7545 2954 340 143 TPG Telecom Limited 17974 2731 914 96 PT Telekomunikasi Indonesia 3356 2553 10689 511 Level 3 Communications, Inc. 6389 2510 3687 42 BellSouth.net Inc. 39891 2473 129 7 SaudiNet, Saudi Telecom Compa 20940 2219 876 1598 Akamai International B.V. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 3400 3240 Telmex Colombia S.A. 22773 3245 3102 Cox Communications Inc. 7545 2954 2811 TPG Telecom Limited 17974 2731 2635 PT Telekomunikasi Indonesia 6389 2510 2468 BellSouth.net Inc. 39891 2473 2466 SaudiNet, Saudi Telecom Compa 3356 2553 2042 Level 3 Communications, Inc. 4766 2993 2004 Korea Telecom 18566 2216 1939 MegaPath Corporation 4755 2065 1835 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 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.124.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 3356 Level 3 Communicatio 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. 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.254.0/24 9583 Sify Limited Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 23.249.144.0/21 40430 colo4jax, LLC 23.249.152.0/21 40430 colo4jax, LLC 27.100.7.0/24 56096 >>UNKNOWN<< 31.170.96.0/23 23456 32bit Transition AS 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.46.8.0/23 13768 Peer 1 Network (USA) Inc. 37.46.10.0/23 36351 SoftLayer Technologies Inc. 37.46.14.0/24 36351 SoftLayer Technologies Inc. Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:11 /10:36 /11:97 /12:263 /13:507 /14:1008 /15:1761 /16:12925 /17:7435 /18:12585 /19:26080 /20:37662 /21:39749 /22:62786 /23:54562 /24:311970 /25:545 /26:566 /27:385 /28:19 /29:15 /30:9 /31:0 /32:21 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2437 3245 Cox Communications Inc. 39891 2432 2473 SaudiNet, Saudi Telecom Compa 18566 2118 2216 MegaPath Corporation 6389 1554 2510 BellSouth.net Inc. 30036 1464 1647 Mediacom Communications Corp 6983 1345 1699 EarthLink, Inc. 10620 1276 3400 Telmex Colombia S.A. 34984 1204 1920 TELLCOM ILETISIM HIZMETLERI A 11492 1127 1211 CABLE ONE, INC. 31148 960 1041 Freenet Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1640 2:701 4:100 5:1949 6:25 8:1412 12:1801 13:27 14:1528 15:22 16:2 17:57 18:19 20:47 23:1291 24:1736 27:2118 31:1667 32:54 33:2 34:4 35:5 36:172 37:2259 38:1112 39:20 40:73 41:2924 42:366 43:1619 44:36 45:1509 46:2316 47:64 49:1034 50:817 52:29 54:92 55:7 56:8 57:44 58:1419 59:832 60:508 61:1795 62:1398 63:1905 64:4371 65:2192 66:4022 67:2125 68:1085 69:3273 70:1017 71:463 72:1985 74:2549 75:356 76:416 77:1397 78:1254 79:802 80:1344 81:1347 82:835 83:651 84:794 85:1482 86:455 87:1036 88:536 89:1909 90:164 91:5990 92:863 93:2277 94:2184 95:2238 96:475 97:352 98:943 99:47 100:79 101:844 103:8871 104:2163 105:72 106:358 107:1097 108:634 109:2115 110:1218 111:1444 112:865 113:1103 114:878 115:1484 116:1474 117:1182 118:1971 119:1502 120:498 121:1154 122:2247 123:1860 124:1581 125:1738 128:704 129:369 130:388 131:1281 132:587 133:165 134:442 135:119 136:337 137:305 138:1478 139:190 140:244 141:454 142:655 143:692 144:572 145:142 146:794 147:612 148:1279 149:440 150:624 151:809 152:566 153:264 154:466 155:904 156:435 157:444 158:352 159:1062 160:407 161:665 162:2183 163:519 164:707 165:1082 166:312 167:883 168:1302 169:540 170:1430 171:261 172:351 173:1545 174:721 175:742 176:1509 177:3977 178:2293 179:1028 180:2031 181:1633 182:1859 183:668 184:766 185:4880 186:2996 187:1887 188:2074 189:1698 190:7493 191:1231 192:8688 193:5669 194:4291 195:3661 196:2260 197:1167 198:5528 199:5564 200:6697 201:3501 202:9875 203:9274 204:4572 205:2746 206:3029 207:3009 208:4005 209:3970 210:3756 211:2012 212:2613 213:2163 214:835 215:72 216:5753 217:1870 218:788 219:541 220:1601 221:805 222:725 223:856 End of report From joly at punkcast.com Fri Nov 20 18:30:34 2015 From: joly at punkcast.com (Joly MacFie) Date: Fri, 20 Nov 2015 13:30:34 -0500 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: <564F5C59.6000901@ispn.net> References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <564F5730.3050707@ispn.net> <564F5C59.6000901@ispn.net> Message-ID: ?Logic tells me that, if the major incumbents content doesn't count against the cap, this leaves more bandwidth for other applications?. What am I missing? On Fri, Nov 20, 2015 at 12:46 PM, Blake Hudson wrote: > It's not. And that's the point. > > This proposal, and ones similar, stifle growth of applications. If there > are additional (artificial) burdens for operating in a field it becomes > harder to get into. Because it's harder to get into, fewer operators > compete. [Note, we just reduced open competition, one tenet of Net > Neutrality] Because there are fewer operators there will be less > competition. Less competition increases prices and fewer customers take the > service. Because few people use the application, the network operator has > no incentive to support the application well. [Note, we just reduced the > freedom to run applications] Because the network doesn't support the > application well, few people use the application. It's circular and it > slows growth. > > Just because there may be inherent challenges to offering an application > (bandwidth, for example), doesn't mean that adding another one (per > application bandwidth caps) is desirable. -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- - From lyle at lcrcomputer.net Fri Nov 20 19:22:46 2015 From: lyle at lcrcomputer.net (Lyle Giese) Date: Fri, 20 Nov 2015 13:22:46 -0600 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <564F5730.3050707@ispn.net> <564F5C59.6000901@ispn.net> Message-ID: <564F7306.9030602@lcrcomputer.net> It leaves more data available to use within your data plan, but may reduce bandwidth available to you to actually use. In other words, you may find your billed usage unusable due to lack of usable bandwidth. 'Oh it's free, I will set my phone to stream all Monty Python movies continuously.' But I think this answer is more in line with the intent of your question, why would someone want to try to startup a new service that doesn't fit within the guidelines of these 'free' services. Lyle Giese LCR Computer Services, Inc. On 11/20/2015 12:30 PM, Joly MacFie wrote: > ?Logic tells me that, if the major incumbents content doesn't count against > the cap, this leaves more bandwidth for other applications?. What am I > missing? > > On Fri, Nov 20, 2015 at 12:46 PM, Blake Hudson wrote: > >> It's not. And that's the point. >> >> This proposal, and ones similar, stifle growth of applications. If there >> are additional (artificial) burdens for operating in a field it becomes >> harder to get into. Because it's harder to get into, fewer operators >> compete. [Note, we just reduced open competition, one tenet of Net >> Neutrality] Because there are fewer operators there will be less >> competition. Less competition increases prices and fewer customers take the >> service. Because few people use the application, the network operator has >> no incentive to support the application well. [Note, we just reduced the >> freedom to run applications] Because the network doesn't support the >> application well, few people use the application. It's circular and it >> slows growth. >> >> Just because there may be inherent challenges to offering an application >> (bandwidth, for example), doesn't mean that adding another one (per >> application bandwidth caps) is desirable. From bill at herrin.us Fri Nov 20 21:21:10 2015 From: bill at herrin.us (William Herrin) Date: Fri, 20 Nov 2015 16:21:10 -0500 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <564F5730.3050707@ispn.net> <564F5C59.6000901@ispn.net> Message-ID: On Fri, Nov 20, 2015 at 1:30 PM, Joly MacFie wrote: > Logic tells me that, if the major incumbents content doesn't count against > the cap, this leaves more bandwidth for other applications. What am I > missing? Cross-subsidy. It's a standard tool of monopoly abuse. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From owen at delong.com Fri Nov 20 21:27:17 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 20 Nov 2015 13:27:17 -0800 Subject: bad announcement taxonomy In-Reply-To: <1448032050.871111483@apps.rackspace.com> References: <8EF67853-078A-429C-946D-A6AEA6A0F5D6@hopcount.ca> <0ED16430-76A1-43D5-BB28-97A3E8DCCDF1@iname.com> <18414.1447913729@turing-police.cc.vt.edu> <1448032050.871111483@apps.rackspace.com> Message-ID: > On Nov 20, 2015, at 07:07 , tim at pelican.org wrote: > > On Friday, 20 November, 2015 14:05, "Jared Mauch" said: > >> Did someone say NAT? >> >> https://www.youtube.com/watch?v=v26BAlfWBm8 > > Now *that's* how to make my Friday afternoon! You, sir, win the Internet for today. > > Regards, > Tim. > > You?re awarding him this? https://www.youtube.com/watch?v=iDbyYGrswtg Owen From owen at delong.com Fri Nov 20 21:50:16 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 20 Nov 2015 13:50:16 -0800 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <564F4949.2060508@ronan-online.com> <54d6d31bb38d432f89a2966f8af532ed@SEAEXCHMBX04.olympus.F5Net.com> Message-ID: It?s a full page of standards in a relatively large font with decent spacing. Given that bluetooth is several hundred pages, I?d say this is pretty reasonable. Having read through the page, I don?t see anything onerous in the requirements. In fact, it looks to me like the bare minimum of reasonable and an expression by T-Mo of a willingness to expend a fair amount of effort to integrate content providers. I don?t see anything here that hurts net neutrality and I applaud this as actually being a potential boon to consumers and a potentially good model of how to implement ZRB in a net-neutral way going forward. Owen > On Nov 20, 2015, at 09:03 , Steve Mikulasik wrote: > > That is much better than I thought. Although, I don't think the person who wrote this understands what UDP is. > > "Use of technology protocols that are demonstrated to prevent video stream detection, such as User Datagram Protocol ?UDP? on any platform will exclude video streams from that content provider" > > > -----Original Message----- > From: Ian Smith [mailto:I.Smith at F5.com] > Sent: Friday, November 20, 2015 9:52 AM > To: Steve Mikulasik ; Shane Ronan ; nanog at nanog.org > Subject: RE: Binge On! - And So This is Net Neutrality? > > http://www.t-mobile.com/content/dam/tmo/en-g/pdf/BingeOn-Video-Technical-Criteria-November-2015.pdf > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Steve Mikulasik > Sent: Friday, November 20, 2015 11:37 AM > To: Shane Ronan ; nanog at nanog.org > Subject: RE: Binge On! - And So This is Net Neutrality? > > What are these technical requirements? I feel like these would punish small upstarts well helping protect large incumbent services from competition. > > Even if you don't demand payment, you can still hurt the fairness of the internet this way. > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Shane Ronan > Sent: Friday, November 20, 2015 9:25 AM > To: nanog at nanog.org > Subject: Re: Binge On! - And So This is Net Neutrality? > > T-Mobile claims they are not accepting any payment from these content providers for inclusion in Binge On. > > "Onstage today, Legere said any company can apply to join the Binge On program. "Anyone who can meet our technical requirement, we?ll include," > he said. "This is not a net neutrality problem." Legere pointed to the fact that Binge On doesn't charge providers for inclusion and customers don't pay to access it." > http://www.theverge.com/2015/11/10/9704482/t-mobile-uncarrier-binge-on-netflix-hbo-streaming > > > On 11/20/15 10:45 AM, Jay Ashworth wrote: >> According to: >> >> >> http://www.engadget.com/2015/11/20/fcc-chairman-gives-t-mobiles-binge- >> on-the-thumbs-up/ >> >> Chairman Wheeler thinks that T-mob's new "customers can get uncapped >> media stream data, but only from the people we like" service called >> Binge On is pro-competition. >> >> My take on this is that the service is *precisely* what Net Neutrality >> was supposed to prevent -- carriers offering paid fast-lanes to >> content providers -- and that this is anti-competitive to the sort of >> "upstart YouTube" entities that NN was supposed to protect... >> >> and that *that* is the competition that NN was supposed to protect. >> >> And I just said the same thing two different ways. >> >> Cause does anyone here think that T-mob is giving those *carriers* >> pride of place *for free*? >> >> Corporations don't - in my experience - give away lots of money out of >> the goodness of their hearts. >> >> Cheers, >> -- jr 'whacky weekend' a > From blake at ispn.net Fri Nov 20 22:04:34 2015 From: blake at ispn.net (Blake Hudson) Date: Fri, 20 Nov 2015 16:04:34 -0600 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <564F4949.2060508@ronan-online.com> <54d6d31bb38d432f89a2966f8af532ed@SEAEXCHMBX04.olympus.F5Net.com> Message-ID: <564F98F2.9010704@ispn.net> Not that I mind getting significantly more service at little additional cost - as proposed by T-Mobile. But I would have preferred to simply get unlimited data usage (or a much larger monthly allotment) and had the freedom to use that data how I see fit. Comparing the two options, I think one is more neutral than the other. Owen DeLong wrote on 11/20/2015 3:50 PM: > It?s a full page of standards in a relatively large font with decent spacing. > > Given that bluetooth is several hundred pages, I?d say this is pretty reasonable. > > Having read through the page, I don?t see anything onerous in the requirements. In fact, it looks to me > like the bare minimum of reasonable and an expression by T-Mo of a willingness to expend a fair amount > of effort to integrate content providers. > > I don?t see anything here that hurts net neutrality and I applaud this as actually being a potential boon > to consumers and a potentially good model of how to implement ZRB in a net-neutral way going > forward. > > Owen > >> On Nov 20, 2015, at 09:03 , Steve Mikulasik wrote: >> >> That is much better than I thought. Although, I don't think the person who wrote this understands what UDP is. >> >> "Use of technology protocols that are demonstrated to prevent video stream detection, such as User Datagram Protocol ?UDP? on any platform will exclude video streams from that content provider" >> >> >> -----Original Message----- >> From: Ian Smith [mailto:I.Smith at F5.com] >> Sent: Friday, November 20, 2015 9:52 AM >> To: Steve Mikulasik ; Shane Ronan ; nanog at nanog.org >> Subject: RE: Binge On! - And So This is Net Neutrality? >> >> http://www.t-mobile.com/content/dam/tmo/en-g/pdf/BingeOn-Video-Technical-Criteria-November-2015.pdf >> >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Steve Mikulasik >> Sent: Friday, November 20, 2015 11:37 AM >> To: Shane Ronan ; nanog at nanog.org >> Subject: RE: Binge On! - And So This is Net Neutrality? >> >> What are these technical requirements? I feel like these would punish small upstarts well helping protect large incumbent services from competition. >> >> Even if you don't demand payment, you can still hurt the fairness of the internet this way. >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Shane Ronan >> Sent: Friday, November 20, 2015 9:25 AM >> To: nanog at nanog.org >> Subject: Re: Binge On! - And So This is Net Neutrality? >> >> T-Mobile claims they are not accepting any payment from these content providers for inclusion in Binge On. >> >> "Onstage today, Legere said any company can apply to join the Binge On program. "Anyone who can meet our technical requirement, we?ll include," >> he said. "This is not a net neutrality problem." Legere pointed to the fact that Binge On doesn't charge providers for inclusion and customers don't pay to access it." >> http://www.theverge.com/2015/11/10/9704482/t-mobile-uncarrier-binge-on-netflix-hbo-streaming >> >> >> On 11/20/15 10:45 AM, Jay Ashworth wrote: >>> According to: >>> >>> >>> http://www.engadget.com/2015/11/20/fcc-chairman-gives-t-mobiles-binge- >>> on-the-thumbs-up/ >>> >>> Chairman Wheeler thinks that T-mob's new "customers can get uncapped >>> media stream data, but only from the people we like" service called >>> Binge On is pro-competition. >>> >>> My take on this is that the service is *precisely* what Net Neutrality >>> was supposed to prevent -- carriers offering paid fast-lanes to >>> content providers -- and that this is anti-competitive to the sort of >>> "upstart YouTube" entities that NN was supposed to protect... >>> >>> and that *that* is the competition that NN was supposed to protect. >>> >>> And I just said the same thing two different ways. >>> >>> Cause does anyone here think that T-mob is giving those *carriers* >>> pride of place *for free*? >>> >>> Corporations don't - in my experience - give away lots of money out of >>> the goodness of their hearts. >>> >>> Cheers, >>> -- jr 'whacky weekend' a From cma at cmadams.net Fri Nov 20 22:09:23 2015 From: cma at cmadams.net (Chris Adams) Date: Fri, 20 Nov 2015 16:09:23 -0600 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: <564F98F2.9010704@ispn.net> References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <564F4949.2060508@ronan-online.com> <54d6d31bb38d432f89a2966f8af532ed@SEAEXCHMBX04.olympus.F5Net.com> <564F98F2.9010704@ispn.net> Message-ID: <20151120220923.GE30565@cmadams.net> Once upon a time, Blake Hudson said: > Not that I mind getting significantly more service at little > additional cost - as proposed by T-Mobile. But I would have > preferred to simply get unlimited data usage (or a much larger > monthly allotment) and had the freedom to use that data how I see > fit. Comparing the two options, I think one is more neutral than the > other. So, lucky you: most T-Mobile data plans are doubling in size as well (same announcement). They do also offer an unlimited data plan (don't know the caveats, probably some apply). -- Chris Adams From owen at delong.com Fri Nov 20 22:21:09 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 20 Nov 2015 14:21:09 -0800 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: <20151120220923.GE30565@cmadams.net> References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <564F4949.2060508@ronan-online.com> <54d6d31bb38d432f89a2966f8af532ed@SEAEXCHMBX04.olympus.F5Net.com> <564F98F2.9010704@ispn.net> <20151120220923.GE30565@cmadams.net> Message-ID: <294FF08F-4381-4968-860A-9676EB747E59@delong.com> Unlimited data plan is $30/mo. Other than the usual cellular caveats of coverage sucks in lots of places and data rates can be slow when you?re in a densely populated area, congestion, oversubscription, etc? Doesn?t seem to have any problems. I?ve been on that plan for most of a year now. The biggest problem I have (other than occasionally terrible call quality) is that due to religious stupidity, they refuse to support IPv6 over LTE for iOS. Owen > On Nov 20, 2015, at 14:09 , Chris Adams wrote: > > Once upon a time, Blake Hudson said: >> Not that I mind getting significantly more service at little >> additional cost - as proposed by T-Mobile. But I would have >> preferred to simply get unlimited data usage (or a much larger >> monthly allotment) and had the freedom to use that data how I see >> fit. Comparing the two options, I think one is more neutral than the >> other. > > So, lucky you: most T-Mobile data plans are doubling in size as well > (same announcement). They do also offer an unlimited data plan (don't > know the caveats, probably some apply). > > -- > Chris Adams From joshuawark at hotmail.com Fri Nov 20 15:00:06 2015 From: joshuawark at hotmail.com (Joshua) Date: Fri, 20 Nov 2015 09:00:06 -0600 Subject: Comcast eastern Washington storm update? In-Reply-To: References: , Message-ID: We had hundreds of users in WA with Comcast having many issues yesterday. Comcast never would acknowledge it was an issue. It finally just cleared up. Their VOIP phones were not working, all website were really slow and generating PCBD errors. Not sure if this helps but thought I would mention it. We had no other users reporting issues from the rest of the USA. > Date: Thu, 19 Nov 2015 18:10:27 -0800 > Subject: Re: Comcast eastern Washington storm update? > From: aaron at heyaaron.com > To: nanog at nanog.org > > Er, I should have mentioned 'Spokane, WA'. > On Nov 19, 2015 4:39 PM, "Aaron C. de Bruyn" wrote: > > > I know the east side of my state was nailed with a big storm. The Gov > > declared a state of emergency. > > > > Comcast service for several of my clients has understandably been down > > since Tuesday. > > > > I called in a few times over the last two days and the automated message > > keeps saying "service should be restored by 12:01 PM today", after that > > time passes the message gets changed to 7:01 PM, then to 8:01 AM, then > > 12:01 PM. (Always '01'--what's with that?) > > > > One time I let the call get through to a rep and they couldn't give any > > information on the extent of the damage or an ETA. > > > > Can anyone at Comcast shed some light on the disaster over there or give a > > rough idea on service restoration? > > > > As always, I appreciate the hard work from the guys in the trenches and > > the engineers that miraculously seem to keep my clients up 24/7. (Just for > > fun, attached are stats about the router for 365 days before the storm > > hit--and most of that 'unreachable' time was probably issues with the > > monitoring server.) > > > > Thanks again for all your hard work. > > > > -A > > > > > > From I.Smith at F5.com Fri Nov 20 16:51:40 2015 From: I.Smith at F5.com (Ian Smith) Date: Fri, 20 Nov 2015 16:51:40 +0000 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <564F4949.2060508@ronan-online.com> Message-ID: <54d6d31bb38d432f89a2966f8af532ed@SEAEXCHMBX04.olympus.F5Net.com> http://www.t-mobile.com/content/dam/tmo/en-g/pdf/BingeOn-Video-Technical-Criteria-November-2015.pdf -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Steve Mikulasik Sent: Friday, November 20, 2015 11:37 AM To: Shane Ronan ; nanog at nanog.org Subject: RE: Binge On! - And So This is Net Neutrality? What are these technical requirements? I feel like these would punish small upstarts well helping protect large incumbent services from competition. Even if you don't demand payment, you can still hurt the fairness of the internet this way. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Shane Ronan Sent: Friday, November 20, 2015 9:25 AM To: nanog at nanog.org Subject: Re: Binge On! - And So This is Net Neutrality? T-Mobile claims they are not accepting any payment from these content providers for inclusion in Binge On. "Onstage today, Legere said any company can apply to join the Binge On program. "Anyone who can meet our technical requirement, we?ll include," he said. "This is not a net neutrality problem." Legere pointed to the fact that Binge On doesn't charge providers for inclusion and customers don't pay to access it." http://www.theverge.com/2015/11/10/9704482/t-mobile-uncarrier-binge-on-netflix-hbo-streaming On 11/20/15 10:45 AM, Jay Ashworth wrote: > According to: > > > http://www.engadget.com/2015/11/20/fcc-chairman-gives-t-mobiles-binge- > on-the-thumbs-up/ > > Chairman Wheeler thinks that T-mob's new "customers can get uncapped > media stream data, but only from the people we like" service called > Binge On is pro-competition. > > My take on this is that the service is *precisely* what Net Neutrality > was supposed to prevent -- carriers offering paid fast-lanes to > content providers -- and that this is anti-competitive to the sort of > "upstart YouTube" entities that NN was supposed to protect... > > and that *that* is the competition that NN was supposed to protect. > > And I just said the same thing two different ways. > > Cause does anyone here think that T-mob is giving those *carriers* > pride of place *for free*? > > Corporations don't - in my experience - give away lots of money out of > the goodness of their hearts. > > Cheers, > -- jr 'whacky weekend' a From kburke at burlingtontelecom.com Fri Nov 20 20:37:21 2015 From: kburke at burlingtontelecom.com (Kevin Burke) Date: Fri, 20 Nov 2015 15:37:21 -0500 Subject: Rack Locks Message-ID: <707FECBBE7FEE241ABE4CAAF4025A0BE03984B46@corpmail.burlingtontelecom.com> What kind of experience do people have with rack access control systems (electronic locks)? Anything I should pay attention to with the products? Hope this questions hasn't already been answered. Not to picky about what/who. The APC solution seems to start getting pricy with multiple racks. I see arduino has an RFID reader but haven't found the door opener. The racks in question are standard APC (SX?) racks. Background We have half a dozen racks, mostly ours. Mostly I want something to log who opened what door when. Cooling overhaul is next on the list but one at a time. Even with cameras those janky make nobody happy. If someone knows a better place to ask this that would be nice too. Thanks for your time! Kevin Burke 802-540-0979 Burlington Telecom - City of Burlington 200 Church St, Burlington, VT 05401 From jimb at jsbc.cc Fri Nov 20 21:35:55 2015 From: jimb at jsbc.cc (Jim Burwell) Date: Fri, 20 Nov 2015 13:35:55 -0800 Subject: DHCPv6 PD & Routing Questions Message-ID: <564F923B.9080200@jsbc.cc> Hi, Have a simple couple of questions here. In my admittedly cursory glances over the DHCPv6 RFCs, I don't see any reference to the protocol having any role in managing the routing of prefixes it delegates. Perhaps I missed it, but I somewhat expected the omission of this responsibility would be the case. My questions are: 1) Does the DHCPv6 protocol include any standards/mechanisms/methods for managing routes to prefixes it delegates, or does it consider this outside of its function? (I suspect the latter) 2) What are the most common ways of managing the routing of delegated prefixes in the ISPs routing domain? Has a standard method/best practice emerged yet? Routing protocols? IPv6 RAs? One obvious answer would be routing protocols. In my brief googling, I've seen a forum post that seems to indicate that Comcast makes use of RIPng on their CPE to propagate routing information for prefixes delegated to it. Can someone confirm this? This would seem as good a method as any to do this, albeit with obvious security concerns. What's the best way to implement a DHCPV6 PD client on a Linux router? Dibbler seems to do everything except route propagation (asks for PD, puts PD address on local NIC if asked). Anything better out there? TIA, - Jim From owen at delong.com Fri Nov 20 23:31:53 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 20 Nov 2015 15:31:53 -0800 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <564F4949.2060508@ronan-online.com> <54d6d31bb38d432f89a2966f8af532ed@SEAEXCHMBX04.olympus.F5Net.com> Message-ID: I think they actually might? It?s very hard to identify streams in UDP since UDP is stateless. Owen > On Nov 20, 2015, at 09:03 , Steve Mikulasik wrote: > > That is much better than I thought. Although, I don't think the person who wrote this understands what UDP is. > > "Use of technology protocols that are demonstrated to prevent video stream detection, such as User Datagram Protocol ?UDP? on any platform will exclude video streams from that content provider" > > > -----Original Message----- > From: Ian Smith [mailto:I.Smith at F5.com] > Sent: Friday, November 20, 2015 9:52 AM > To: Steve Mikulasik ; Shane Ronan ; nanog at nanog.org > Subject: RE: Binge On! - And So This is Net Neutrality? > > http://www.t-mobile.com/content/dam/tmo/en-g/pdf/BingeOn-Video-Technical-Criteria-November-2015.pdf > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Steve Mikulasik > Sent: Friday, November 20, 2015 11:37 AM > To: Shane Ronan ; nanog at nanog.org > Subject: RE: Binge On! - And So This is Net Neutrality? > > What are these technical requirements? I feel like these would punish small upstarts well helping protect large incumbent services from competition. > > Even if you don't demand payment, you can still hurt the fairness of the internet this way. > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Shane Ronan > Sent: Friday, November 20, 2015 9:25 AM > To: nanog at nanog.org > Subject: Re: Binge On! - And So This is Net Neutrality? > > T-Mobile claims they are not accepting any payment from these content providers for inclusion in Binge On. > > "Onstage today, Legere said any company can apply to join the Binge On program. "Anyone who can meet our technical requirement, we?ll include," > he said. "This is not a net neutrality problem." Legere pointed to the fact that Binge On doesn't charge providers for inclusion and customers don't pay to access it." > http://www.theverge.com/2015/11/10/9704482/t-mobile-uncarrier-binge-on-netflix-hbo-streaming > > > On 11/20/15 10:45 AM, Jay Ashworth wrote: >> According to: >> >> >> http://www.engadget.com/2015/11/20/fcc-chairman-gives-t-mobiles-binge- >> on-the-thumbs-up/ >> >> Chairman Wheeler thinks that T-mob's new "customers can get uncapped >> media stream data, but only from the people we like" service called >> Binge On is pro-competition. >> >> My take on this is that the service is *precisely* what Net Neutrality >> was supposed to prevent -- carriers offering paid fast-lanes to >> content providers -- and that this is anti-competitive to the sort of >> "upstart YouTube" entities that NN was supposed to protect... >> >> and that *that* is the competition that NN was supposed to protect. >> >> And I just said the same thing two different ways. >> >> Cause does anyone here think that T-mob is giving those *carriers* >> pride of place *for free*? >> >> Corporations don't - in my experience - give away lots of money out of >> the goodness of their hearts. >> >> Cheers, >> -- jr 'whacky weekend' a > From Steve.Mikulasik at civeo.com Fri Nov 20 23:35:49 2015 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Fri, 20 Nov 2015 23:35:49 +0000 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <564F4949.2060508@ronan-online.com> <54d6d31bb38d432f89a2966f8af532ed@SEAEXCHMBX04.olympus.F5Net.com> , Message-ID: Requiring streaming companies not to use UDP is pretty absurd. Surely they must be able to identify streaming traffic without needing TCP. Sent from my Windows Phone ________________________________ From: Owen DeLong Sent: ?11/?20/?2015 4:32 PM To: Steve Mikulasik Cc: Ian Smith; nanog at nanog.org Subject: Re: Binge On! - And So This is Net Neutrality? I think they actually might? It?s very hard to identify streams in UDP since UDP is stateless. Owen > On Nov 20, 2015, at 09:03 , Steve Mikulasik wrote: > > That is much better than I thought. Although, I don't think the person who wrote this understands what UDP is. > > "Use of technology protocols that are demonstrated to prevent video stream detection, such as User Datagram Protocol ?UDP? on any platform will exclude video streams from that content provider" > > > -----Original Message----- > From: Ian Smith [mailto:I.Smith at F5.com] > Sent: Friday, November 20, 2015 9:52 AM > To: Steve Mikulasik ; Shane Ronan ; nanog at nanog.org > Subject: RE: Binge On! - And So This is Net Neutrality? > > http://www.t-mobile.com/content/dam/tmo/en-g/pdf/BingeOn-Video-Technical-Criteria-November-2015.pdf > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Steve Mikulasik > Sent: Friday, November 20, 2015 11:37 AM > To: Shane Ronan ; nanog at nanog.org > Subject: RE: Binge On! - And So This is Net Neutrality? > > What are these technical requirements? I feel like these would punish small upstarts well helping protect large incumbent services from competition. > > Even if you don't demand payment, you can still hurt the fairness of the internet this way. > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Shane Ronan > Sent: Friday, November 20, 2015 9:25 AM > To: nanog at nanog.org > Subject: Re: Binge On! - And So This is Net Neutrality? > > T-Mobile claims they are not accepting any payment from these content providers for inclusion in Binge On. > > "Onstage today, Legere said any company can apply to join the Binge On program. "Anyone who can meet our technical requirement, we?ll include," > he said. "This is not a net neutrality problem." Legere pointed to the fact that Binge On doesn't charge providers for inclusion and customers don't pay to access it." > http://www.theverge.com/2015/11/10/9704482/t-mobile-uncarrier-binge-on-netflix-hbo-streaming > > > On 11/20/15 10:45 AM, Jay Ashworth wrote: >> According to: >> >> >> http://www.engadget.com/2015/11/20/fcc-chairman-gives-t-mobiles-binge- >> on-the-thumbs-up/ >> >> Chairman Wheeler thinks that T-mob's new "customers can get uncapped >> media stream data, but only from the people we like" service called >> Binge On is pro-competition. >> >> My take on this is that the service is *precisely* what Net Neutrality >> was supposed to prevent -- carriers offering paid fast-lanes to >> content providers -- and that this is anti-competitive to the sort of >> "upstart YouTube" entities that NN was supposed to protect... >> >> and that *that* is the competition that NN was supposed to protect. >> >> And I just said the same thing two different ways. >> >> Cause does anyone here think that T-mob is giving those *carriers* >> pride of place *for free*? >> >> Corporations don't - in my experience - give away lots of money out of >> the goodness of their hearts. >> >> Cheers, >> -- jr 'whacky weekend' a > From owen at delong.com Fri Nov 20 23:36:46 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 20 Nov 2015 15:36:46 -0800 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <564F923B.9080200@jsbc.cc> References: <564F923B.9080200@jsbc.cc> Message-ID: <85AC9398-125E-4078-86DA-63962DF76662@delong.com> > On Nov 20, 2015, at 13:35 , Jim Burwell wrote: > > Hi, > > Have a simple couple of questions here. > > In my admittedly cursory glances over the DHCPv6 RFCs, I don't see any > reference to the protocol having any role in managing the routing of > prefixes it delegates. Perhaps I missed it, but I somewhat expected the > omission of this responsibility would be the case. > > My questions are: > > 1) Does the DHCPv6 protocol include any standards/mechanisms/methods for > managing routes to prefixes it delegates, or does it consider this > outside of its function? (I suspect the latter) Yes and no? DHCPv6 doesn?t include anything specifically per se, but it does require that the local router sees the DHCPv6 PD answer in the process of passing it along to the target, and there?s a pretty obvious expectation that said router will have to arrange to do the needful in that respect. > 2) What are the most common ways of managing the routing of delegated > prefixes in the ISPs routing domain? Has a standard method/best > practice emerged yet? Routing protocols? IPv6 RAs? RAs really only apply to subnet local advertisement of routers and the on-net prefixes in most implementations. I don?t think any of the various methods of using routing protocols, static pre-routed blocks from which PDs are delegated, etc. could necessarily be called ?standardized?, but there are probably a few that are more popular than most of the others. Unfortunately, PD is really still in its infancy in terms of development and real running code for complete implementations throughout any sort of site hierarchy. Owen From jimb at jsbc.cc Sat Nov 21 00:20:20 2015 From: jimb at jsbc.cc (Jim Burwell) Date: Fri, 20 Nov 2015 16:20:20 -0800 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <85AC9398-125E-4078-86DA-63962DF76662@delong.com> References: <564F923B.9080200@jsbc.cc> <85AC9398-125E-4078-86DA-63962DF76662@delong.com> Message-ID: <564FB8C4.1070202@jsbc.cc> On 2015-11-20 15:36, Owen DeLong wrote: >> On Nov 20, 2015, at 13:35 , Jim Burwell wrote: >> >> Hi, >> >> Have a simple couple of questions here. >> >> In my admittedly cursory glances over the DHCPv6 RFCs, I don't see any >> reference to the protocol having any role in managing the routing of >> prefixes it delegates. Perhaps I missed it, but I somewhat expected the >> omission of this responsibility would be the case. >> >> My questions are: >> >> 1) Does the DHCPv6 protocol include any standards/mechanisms/methods for >> managing routes to prefixes it delegates, or does it consider this >> outside of its function? (I suspect the latter) > Yes and no? > > DHCPv6 doesn?t include anything specifically per se, but it does require that > the local router sees the DHCPv6 PD answer in the process of passing it > along to the target, and there?s a pretty obvious expectation that said router > will have to arrange to do the needful in that respect. > >> 2) What are the most common ways of managing the routing of delegated >> prefixes in the ISPs routing domain? Has a standard method/best >> practice emerged yet? Routing protocols? IPv6 RAs? > RAs really only apply to subnet local advertisement of routers and > the on-net prefixes in most implementations. > > I don?t think any of the various methods of using routing protocols, > static pre-routed blocks from which PDs are delegated, etc. could > necessarily be called ?standardized?, but there are probably a few > that are more popular than most of the others. > > Unfortunately, PD is really still in its infancy in terms of development > and real running code for complete implementations throughout any > sort of site hierarchy. > > Owen > > On 2015-11-20 15:36, Owen DeLong wrote: >> On Nov 20, 2015, at 13:35 , Jim Burwell wrote: >> >> Hi, >> >> Have a simple couple of questions here. >> >> In my admittedly cursory glances over the DHCPv6 RFCs, I don't see any >> reference to the protocol having any role in managing the routing of >> prefixes it delegates. Perhaps I missed it, but I somewhat expected the >> omission of this responsibility would be the case. >> >> My questions are: >> >> 1) Does the DHCPv6 protocol include any standards/mechanisms/methods for >> managing routes to prefixes it delegates, or does it consider this >> outside of its function? (I suspect the latter) > Yes and no? > > DHCPv6 doesn?t include anything specifically per se, but it does require that > the local router sees the DHCPv6 PD answer in the process of passing it > along to the target, and there?s a pretty obvious expectation that said router > will have to arrange to do the needful in that respect. > >> 2) What are the most common ways of managing the routing of delegated >> prefixes in the ISPs routing domain? Has a standard method/best >> practice emerged yet? Routing protocols? IPv6 RAs? > RAs really only apply to subnet local advertisement of routers and > the on-net prefixes in most implementations. > > I don?t think any of the various methods of using routing protocols, > static pre-routed blocks from which PDs are delegated, etc. could > necessarily be called ?standardized?, but there are probably a few > that are more popular than most of the others. > > Unfortunately, PD is really still in its infancy in terms of development > and real running code for complete implementations throughout any > sort of site hierarchy. > > Owen > > Thanks for the answer Owen! So it sounds like things are still in flux. But it least it answers my main question of "have I missed something here"? Could you elaborate on the "local router seeing the PD answer" a bit? I presume by "local router" you mean router acting as DHCPv6 relay? Or do you mean the router which made the original request? Would it be fair to say that the RFCs only really talk about delegating the prefixes, and leave what to do with the prefixes themselves up to the implementer? I'm asking these questions because I'm doing a little class for some folks on IPv6 and this is one area where I couldn't find answers. - Jim From owen at delong.com Sat Nov 21 01:27:43 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 20 Nov 2015 17:27:43 -0800 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <564FB8C4.1070202@jsbc.cc> References: <564F923B.9080200@jsbc.cc> <85AC9398-125E-4078-86DA-63962DF76662@delong.com> <564FB8C4.1070202@jsbc.cc> Message-ID: > On 2015-11-20 15:36, Owen DeLong wrote: >>> On Nov 20, 2015, at 13:35 , Jim Burwell wrote: >>> >>> Hi, >>> >>> Have a simple couple of questions here. >>> >>> In my admittedly cursory glances over the DHCPv6 RFCs, I don't see any >>> reference to the protocol having any role in managing the routing of >>> prefixes it delegates. Perhaps I missed it, but I somewhat expected the >>> omission of this responsibility would be the case. >>> >>> My questions are: >>> >>> 1) Does the DHCPv6 protocol include any standards/mechanisms/methods for >>> managing routes to prefixes it delegates, or does it consider this >>> outside of its function? (I suspect the latter) >> Yes and no? >> >> DHCPv6 doesn?t include anything specifically per se, but it does require that >> the local router sees the DHCPv6 PD answer in the process of passing it >> along to the target, and there?s a pretty obvious expectation that said router >> will have to arrange to do the needful in that respect. >> >>> 2) What are the most common ways of managing the routing of delegated >>> prefixes in the ISPs routing domain? Has a standard method/best >>> practice emerged yet? Routing protocols? IPv6 RAs? >> RAs really only apply to subnet local advertisement of routers and >> the on-net prefixes in most implementations. >> >> I don?t think any of the various methods of using routing protocols, >> static pre-routed blocks from which PDs are delegated, etc. could >> necessarily be called ?standardized?, but there are probably a few >> that are more popular than most of the others. >> >> Unfortunately, PD is really still in its infancy in terms of development >> and real running code for complete implementations throughout any >> sort of site hierarchy. >> >> Owen >> >> > Thanks for the answer Owen! > > So it sounds like things are still in flux. But it least it answers my > main question of "have I missed something here"? > > Could you elaborate on the "local router seeing the PD answer" a bit? I > presume by "local router" you mean router acting as DHCPv6 relay? Or do > you mean the router which made the original request? I mean the router that will deliver the PD to the requesting DHCPv6 client. If the DHCPv6 server is on-net, then this will be the requesting client. Otherwise, it will be the last relay router. > Would it be fair to say that the RFCs only really talk about delegating > the prefixes, and leave what to do with the prefixes themselves up to > the implementer? Yes? At least at this time. Some of the work in homenet might include some suggestions for some implementations. > I'm asking these questions because I'm doing a little class for some > folks on IPv6 and this is one area where I couldn't find answers. Depending on your audience, I?d suggest that unless this is an advanced IPv6 class, it?s probably one of those topics left for extra-curicular research. Owen From mysidia at gmail.com Sat Nov 21 01:55:14 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 20 Nov 2015 19:55:14 -0600 Subject: Rack Locks In-Reply-To: <707FECBBE7FEE241ABE4CAAF4025A0BE03984B46@corpmail.burlingtontelecom.com> References: <707FECBBE7FEE241ABE4CAAF4025A0BE03984B46@corpmail.burlingtontelecom.com> Message-ID: On Fri, Nov 20, 2015 at 2:37 PM, Kevin Burke wrote: > What kind of experience do people have with rack access control systems > (electronic locks)? Anything I should pay attention to with the Overpriced, overkill for most real-world uses? High-Tech technology for technology's sake? Avoid them if you can. Within six months or so, at least once, there will probably be some glitch delaying or denying required prompt access. [snip] > Background > We have half a dozen racks, mostly ours. Mostly I want something to log > who opened what door when. Cooling overhaul is next on the list but one It probably makes sense if there are more than a handful of people with unobserved physical access, and high frequency of access, or there's a trust issue, high-risk consideration. Or you have to satisfy a "Checkbox Auditor". You're not going to be able to look at a log and see Joe opened it at 2:45AM 12 months ago, and ever since then, the servers are not quite right. Consider manual procedures Example: Electronic access control to the actual rooms. A Robo-Key system (RKS), Keyvault, or Realtor lockboxes on each server rack ^_^ Physical locks on cabinets. Key vault that supports multiple combinations. Then you don't need exotic hardware, just a good lock, and sound key control procedures. I am imaging if you need to automate control of individual keys; that there will be more competing solutions for this than specialty rack locks. Logging procedures for key access... Send an e-mail when someone opens the vault. Simple magnetic reed switches on all cabinet doors. Send an e-mail when a cabinet door is opened. Quite a few standard alarm panels can do those types of things. Assign someone to periodically check handwritten logs and check for discrepancies. ^_^ > at a time. Even with cameras those janky make nobody happy. -- -JH From jabley at hopcount.ca Sat Nov 21 02:06:58 2015 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 20 Nov 2015 21:06:58 -0500 Subject: Rack Locks In-Reply-To: References: <707FECBBE7FEE241ABE4CAAF4025A0BE03984B46@corpmail.burlingtontelecom.com> Message-ID: <7413288204807398677@unknownmsgid> On Nov 20, 2015, at 20:55, Jimmy Hess wrote: > You're not going to be able to look at a log and see Joe opened it at 2:45AM > 12 months ago, and ever since then, the servers are not quite right. And I would have got away with it to, if it wasn't for you kids and your pesky logs. Joe From nanog at ics-il.net Sat Nov 21 02:24:30 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 20 Nov 2015 20:24:30 -0600 (CST) Subject: Xeex & 350 E. Cermak Message-ID: <1894269036.11586.1448072716215.JavaMail.mhammett@ThunderFuck> Has anyone else that had services from Xeex Communications have a disruption recently? Our stuff went down shortly after 5:00 this afternoon. I get to Equinix and our cross connects through them are gone. I had suspected some trouble over there and it appears that I unfortunately was correct. P.S. Looking for anyone with 1/4 cab, 10A of power and is good with cross connects in Equinix 350 E. Cermak to hit me up ASAP. ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com From mpalmer at hezmatt.org Sat Nov 21 02:43:46 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sat, 21 Nov 2015 13:43:46 +1100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <564F923B.9080200@jsbc.cc> References: <564F923B.9080200@jsbc.cc> Message-ID: <20151121024346.GO4973@hezmatt.org> On Fri, Nov 20, 2015 at 01:35:55PM -0800, Jim Burwell wrote: > My questions are: > > 1) Does the DHCPv6 protocol include any standards/mechanisms/methods for > managing routes to prefixes it delegates, or does it consider this > outside of its function? (I suspect the latter) It's considered outside of function. It makes a lot of sense, from the *protocol's* viewpoint, not to go constraining itself in any way. *Implementations*, on the other hand, appear to have kinda dropped the ball, insofar as none of the OSS DHCPv6 servers that can do PD appear to have put any thought into what to do with the prefixes delegated. > 2) What are the most common ways of managing the routing of delegated > prefixes in the ISPs routing domain? Has a standard method/best > practice emerged yet? Routing protocols? IPv6 RAs? I hacked some code into ISCP DHCPD to give called scripts sufficient knowledge to add routes to the local machine's routing table: http://www.hezmatt.org/~mpalmer/blog/2014/11/20/multi-level-prefix-delegation-is-not-a-myth-ive-seen-it.html (Holy crap, I published that post almost exactly a year ago today...) More recently, I'm doing some work with a production containerised environment, and I decided to use RAs to propagate /64 routes amongst the container hosts and immediate upstream router (the upstream router has the whole /48 routed to it, and the router then gets the RAs to know which machine to send the /64 to). It seems to work rather well. If I had any more complicated a setup, I'd definitely have broken out the OSPF or something. > One obvious answer would be routing protocols. In my brief googling, > I've seen a forum post that seems to indicate that Comcast makes use of > RIPng on their CPE to propagate routing information for prefixes > delegated to it. Can someone confirm this? This would seem as good a > method as any to do this, albeit with obvious security concerns. I can't confirm Comcast's use of anything in particular, but I'd certainly consider it a possibility. In an ISP environment, I think I'd prefer for my routing to *not* be under the control of anything that the customer can get their fingers into, but I'm sure there's suitable filters in place to stop a customer trying to announce all of 2000::/3... > What's the best way to implement a DHCPV6 PD client on a Linux router? > Dibbler seems to do everything except route propagation (asks for PD, > puts PD address on local NIC if asked). Anything better out there? Well, I'm quite partial to the solution I hacked up for ISC DHCPD, but it's hard to argue that I'm an unbiased observer. - Matt From nanog at ics-il.net Sat Nov 21 02:44:36 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 20 Nov 2015 20:44:36 -0600 (CST) Subject: Xeex & 350 E. Cermak In-Reply-To: <1894269036.11586.1448072716215.JavaMail.mhammett@ThunderFuck> Message-ID: <640814599.11793.1448073924146.JavaMail.mhammett@ThunderFuck> Last time I was in their cage, I saw an R&E network and a cable company in their cage, so I bet there are quite a few hot people right about now. :-\ ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" To: "NANOG list" Sent: Friday, November 20, 2015 8:24:30 PM Subject: Xeex & 350 E. Cermak Has anyone else that had services from Xeex Communications have a disruption recently? Our stuff went down shortly after 5:00 this afternoon. I get to Equinix and our cross connects through them are gone. I had suspected some trouble over there and it appears that I unfortunately was correct. P.S. Looking for anyone with 1/4 cab, 10A of power and is good with cross connects in Equinix 350 E. Cermak to hit me up ASAP. ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com From nanog at ics-il.net Sat Nov 21 05:24:46 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 20 Nov 2015 23:24:46 -0600 (CST) Subject: Xeex & 350 E. Cermak In-Reply-To: Message-ID: <496968921.216.1448083519100.JavaMail.mhammett@ThunderFuck> Your searching is apparently much better than mine. I checked when at NANOG last month and didn't see anything, but there it is... So then I wonder... when I've had bankrupt clients before, I wasn't allowed to disconnect service until the court was all said and done. I doubt it's done this quickly. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Aaron Ryan" To: "Mike Hammett" Cc: "NANOG list" Sent: Friday, November 20, 2015 11:20:51 PM Subject: Re: Xeex & 350 E. Cermak We have some servers hosted at Xeex that were down for 2 hours on Tuesday, Nov 17 2015 from 12:59:02 to 15:02:49 PST I did some research and it looks like they are in Chapter 7 Bankruptcy. http://chapter11cases.com/2015/09/03/bankruptcy-case-filing-alert-nr-software-systems-inc-dba-xeex-communications-in-california-central-district/ On Wednesday, July 15, 2015, NR SOFTWARE SYSTEMS, INC. d/b/a XEEX COMMUNICATIONS filed for protection under Chapter 7 of the United States Bankruptcy Code or had an involuntary petition filed against it. The bankruptcy petition was filed in the United States Bankruptcy Court located in Los Angeles (California ? Central District) and was assigned Case Number 2:15-bk-21180-ER. Judge Robles is presiding over the bankruptcy case. Contact information for the debtor and its counsel are listed as: NR SOFTWARE SYSTEMS, INC. d/b/a XEEX COMMUNICATIONS 615 S. Grand Ave. Los Angeles, CA 90017 Alan Broidy 1925 Century Park E 17th Fl Los Angeles, CA 90067 On Fri, Nov 20, 2015 at 6:44 PM, Mike Hammett < nanog at ics-il.net > wrote:
Last time I was in their cage, I saw an R&E network and a cable company in their cage, so I bet there are quite a few hot people right about now. :-\ ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" < nanog at ics-il.net > To: "NANOG list" < nanog at nanog.org > Sent: Friday, November 20, 2015 8:24:30 PM Subject: Xeex & 350 E. Cermak Has anyone else that had services from Xeex Communications have a disruption recently? Our stuff went down shortly after 5:00 this afternoon. I get to Equinix and our cross connects through them are gone. I had suspected some trouble over there and it appears that I unfortunately was correct. P.S. Looking for anyone with 1/4 cab, 10A of power and is good with cross connects in Equinix 350 E. Cermak to hit me up ASAP. ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com
From bevan at slattery.net.au Sat Nov 21 06:43:07 2015 From: bevan at slattery.net.au (Bevan Slattery) Date: Sat, 21 Nov 2015 16:43:07 +1000 Subject: Rack Locks In-Reply-To: References: <707FECBBE7FEE241ABE4CAAF4025A0BE03984B46@corpmail.burlingtontelecom.com> Message-ID: Hi Kevin, Well I?m happy to provide my experience. When I decided to build a new data centre business back in 2010, I started with a simple premise. That the core data centre experience must be controlled by browser and phone. That system was (and still is called) ONEDC. A key component of this is for the ability for our customers to: * Remotely lock and unlock racks from their phone (great for remote hands) * Use Facility Prox swipe cards to lock/unlock racks in facility at swipe points at end of aisle (did that back in 2008) * Needed to provide users/customers the ability to add/remove their staff (and their customers) access to racks including time of day, time of week access as well as a per rack access granular level (handy if you have 10 racks in a row with 5 different customers so you can limit their access, or a contractor with time of day access such as a tape swap out service) * Full data output allowing me to provide real time audit logs (yes audit logs for security). We did some pretty cool stuff with power management/measurement etc. and made a little video 3 years ago (my kids are playing soccer in the background ;)) https://www.youtube.com/watch?v=58vvIJOfBcE The product has come on a lot since it launched (I left the company 2 years ago now). So what did we do. I used to use a relay type system in 2007-10 in my previous data centre life. It?s pretty good but a bit ?industrial?. It?s also so 2007 (even 1990) and doesn?t scale well when you are trying to do 3,000 racks and 6,000 doors per facility. I looked at the APC electronic locking system, but the big issue is that some fool in product decided to remove radius authentication, allowing a decent independent command/control capability. The product I went with was TZ rack locking because: * Solid product with background in remote post office/delivery locking systems * Use ?Shape Memory Alloy? system in which the lock mechanism is a fluid type alloy that changes shape with voltage, rather than old school mechanical locking * They look really cool, fit most racks and have some great features (like delayed lock for 5 seconds in case you realise you left your screw driver in the rack :)) * Provided API Access so I can integrate it into our rack management system (ONEDC) * Full log interface They will try to ship you the entire product suite, but if you can commit to decent scale they are flexible (API access, support etc.) and let you integrate into the locks. I think NEXTDC has probably deployed about 10,000 doors and one of the old team at NEXTDC is now working for TZ and he eats this stuff for breakfast. I can pass on his details if you wish. Anyway I can definitely recommend TZ http://ixp.tz.net . In looking at their website their product set and locking systems have expanded in the last 2 years or so. Hope this helps. Cheers [b] On 21/11/2015 11:55 am, "NANOG on behalf of Jimmy Hess" wrote: >On Fri, Nov 20, 2015 at 2:37 PM, Kevin Burke > wrote: >> What kind of experience do people have with rack access control systems >> (electronic locks)? Anything I should pay attention to with the > >Overpriced, overkill for most real-world uses? >High-Tech technology for technology's sake? > >Avoid them if you can. Within six months or so, at least once, there >will >probably be some glitch delaying or denying required prompt access. >[snip] > >> Background >> We have half a dozen racks, mostly ours. Mostly I want something to log >> who opened what door when. Cooling overhaul is next on the list but one > >It probably makes sense if there are more than a handful of people with >unobserved physical access, and high frequency of access, or there's a >trust issue, high-risk consideration. Or you have to satisfy a >"Checkbox Auditor". > >You're not going to be able to look at a log and see Joe opened it at >2:45AM >12 months ago, and ever since then, the servers are not quite right. > >Consider manual procedures > >Example: Electronic access control to the actual rooms. >A Robo-Key system (RKS), Keyvault, or Realtor lockboxes on >each server rack ^_^ > >Physical locks on cabinets. Key vault that supports multiple >combinations. >Then you don't need exotic hardware, just a good lock, and sound key >control >procedures. > >I am imaging if you need to automate control of individual keys; >that there will be more competing solutions for this than specialty rack >locks. > >Logging procedures for key access... >Send an e-mail when someone opens the vault. > >Simple magnetic reed switches on all cabinet doors. >Send an e-mail when a cabinet door is opened. >Quite a few standard alarm panels can do those types of things. > >Assign someone to periodically check handwritten logs and check for >discrepancies. ^_^ > >> at a time. Even with cameras those janky make nobody happy. >-- >-JH From baldur.norddahl at gmail.com Sat Nov 21 08:10:29 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 21 Nov 2015 09:10:29 +0100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: References: <564F923B.9080200@jsbc.cc> <85AC9398-125E-4078-86DA-63962DF76662@delong.com> <564FB8C4.1070202@jsbc.cc> Message-ID: On 21 November 2015 at 02:27, Owen DeLong wrote: > I mean the router that will deliver the PD to the requesting DHCPv6 client. > > If the DHCPv6 server is on-net, then this will be the requesting client. > Otherwise, it will be the last relay router. > > There is no actual requirement that the relay function runs on a router. There might be more than one router that needs to know how to route the prefix. You might be using VRRP and you would need a synchronization protocol so the backup router also learns the prefix. I hold that as long nobody cared to write down the obvious implementation in a RFC, you are in error to assume said implementation. Unfortunately there are a few CPEs that do exactly that. Fortunately most work correctly. Also it might be obvious but not all router vendors actually implemented DHCPv6-PD snooping on the DHCPv6 relay function. Ours did not (yet - they probably will sometime before unix time wrapover). They can claim no RFC requires this and be right. I came around that limitation by implementing predictable assignments. Each requesting router/CPE will be assigned a fixed WAN address that is tied to the prefix also assigned. I then inject the routes using Exabgp. Example exabgp config: group g1 { static { route 2a00:7660:202::/48 next-hop 2a00:7660:0:2::2; route 2a00:7660:203::/48 next-hop 2a00:7660:0:2::3; route 2a00:7660:204::/48 next-hop 2a00:7660:0:2::4; route 2a00:7660:205::/48 next-hop 2a00:7660:0:2::5; route 2a00:7660:206::/48 next-hop 2a00:7660:0:2::6; route 2a00:7660:207::/48 next-hop 2a00:7660:0:2::7; route 2a00:7660:208::/48 next-hop 2a00:7660:0:2::8; ... and so on Our DHCPv6 server is then programmed to assign 2a00:7660:0:2::2 to the same CPE that will get 2a00:7660:202::/48. We also use static assignments based on the DHCPv6 interface ID option, but this is not a requirement for using the method. Injecting the routes using BGP is not strictly necessary. You could use static routes as well. Our routers have a limitation on how many static routes are allowed, the routes fill up the config and it is error prone to keep multiple routers in sync. For this reason I implemented route injection using Exabgp instead and it works great. We are not using a trigger on the DHCPv6 server. Instead the routes are computed and injected well before the client connects to the network for the first time. The method would also work well with a dynamically trigger based approach. Regards, Baldur From frederik at kriewitz.eu Sat Nov 21 10:13:54 2015 From: frederik at kriewitz.eu (Frederik Kriewitz) Date: Sat, 21 Nov 2015 11:13:54 +0100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <564F923B.9080200@jsbc.cc> References: <564F923B.9080200@jsbc.cc> Message-ID: On Fri, Nov 20, 2015 at 10:35 PM, Jim Burwell wrote: > 2) What are the most common ways of managing the routing of delegated > prefixes in the ISPs routing domain? Has a standard method/best > practice emerged yet? Routing protocols? IPv6 RAs? > > One obvious answer would be routing protocols. In my brief googling, > I've seen a forum post that seems to indicate that Comcast makes use of > RIPng on their CPE to propagate routing information for prefixes > delegated to it. Can someone confirm this? This would seem as good a > method as any to do this, albeit with obvious security concerns. We've build a small tool which watches the dhcpd6 lease file for changes and injects the PD routes using exabgp (iBGP session with corresponding IA_NA address as next-hop for the IA_PD prefix). Best Regards, Frederik Kriewitz From joelja at bogus.com Sat Nov 21 10:41:11 2015 From: joelja at bogus.com (joel jaeggli) Date: Sat, 21 Nov 2015 02:41:11 -0800 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <564F4949.2060508@ronan-online.com> <54d6d31bb38d432f89a2966f8af532ed@SEAEXCHMBX04.olympus.F5Net.com> Message-ID: <56504A47.3080407@bogus.com> On 11/20/15 3:35 PM, Steve Mikulasik wrote: > Requiring streaming companies not to use UDP is pretty absurd. Surely > they must be able to identify streaming traffic without needing TCP. One presumes that they've gotten rather good at looking at HLS or MPEG-DASH and triggering rate adaption where necessary. > Sent from my Windows Phone ________________________________ From: > Owen DeLong Sent: ?11/?20/?2015 4:32 PM To: > Steve Mikulasik Cc: Ian > Smith; > nanog at nanog.org Subject: Re: Binge On! - And > So This is Net Neutrality? > > I think they actually might? It?s very hard to identify streams in > UDP since UDP is stateless. > > Owen > >> On Nov 20, 2015, at 09:03 , Steve Mikulasik >> wrote: >> >> That is much better than I thought. Although, I don't think the >> person who wrote this understands what UDP is. >> >> "Use of technology protocols that are demonstrated to prevent video >> stream detection, such as User Datagram Protocol ?UDP? on any >> platform will exclude video streams from that content provider" >> >> >> -----Original Message----- From: Ian Smith [mailto:I.Smith at F5.com] >> Sent: Friday, November 20, 2015 9:52 AM To: Steve Mikulasik >> ; Shane Ronan ; >> nanog at nanog.org Subject: RE: Binge On! - And So This is Net >> Neutrality? >> >> http://www.t-mobile.com/content/dam/tmo/en-g/pdf/BingeOn-Video-Technical-Criteria-November-2015.pdf >> >> >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Steve >> Mikulasik Sent: Friday, November 20, 2015 11:37 AM To: Shane Ronan >> ; nanog at nanog.org Subject: RE: Binge On! - >> And So This is Net Neutrality? >> >> What are these technical requirements? I feel like these would >> punish small upstarts well helping protect large incumbent services >> from competition. >> >> Even if you don't demand payment, you can still hurt the fairness >> of the internet this way. >> >> >> -----Original Message----- From: NANOG >> [mailto:nanog-bounces at nanog.org] On Behalf Of Shane Ronan Sent: >> Friday, November 20, 2015 9:25 AM To: nanog at nanog.org Subject: Re: >> Binge On! - And So This is Net Neutrality? >> >> T-Mobile claims they are not accepting any payment from these >> content providers for inclusion in Binge On. >> >> "Onstage today, Legere said any company can apply to join the Binge >> On program. "Anyone who can meet our technical requirement, we?ll >> include," he said. "This is not a net neutrality problem." Legere >> pointed to the fact that Binge On doesn't charge providers for >> inclusion and customers don't pay to access it." >> http://www.theverge.com/2015/11/10/9704482/t-mobile-uncarrier-binge-on-netflix-hbo-streaming >> >> >> >> On 11/20/15 10:45 AM, Jay Ashworth wrote: >>> According to: >>> >>> >>> http://www.engadget.com/2015/11/20/fcc-chairman-gives-t-mobiles-binge- >>> >>> on-the-thumbs-up/ >>> >>> Chairman Wheeler thinks that T-mob's new "customers can get >>> uncapped media stream data, but only from the people we like" >>> service called Binge On is pro-competition. >>> >>> My take on this is that the service is *precisely* what Net >>> Neutrality was supposed to prevent -- carriers offering paid >>> fast-lanes to content providers -- and that this is >>> anti-competitive to the sort of "upstart YouTube" entities that >>> NN was supposed to protect... >>> >>> and that *that* is the competition that NN was supposed to >>> protect. >>> >>> And I just said the same thing two different ways. >>> >>> Cause does anyone here think that T-mob is giving those >>> *carriers* pride of place *for free*? >>> >>> Corporations don't - in my experience - give away lots of money >>> out of the goodness of their hearts. >>> >>> Cheers, -- jr 'whacky weekend' a >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: OpenPGP digital signature URL: From dave.taht at gmail.com Sat Nov 21 13:08:15 2015 From: dave.taht at gmail.com (Dave Taht) Date: Sat, 21 Nov 2015 14:08:15 +0100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: References: <564F923B.9080200@jsbc.cc> Message-ID: y'all might want to look over the work of the ietf homenet working group for some insight into plans for dhcp-pd, and routing interactions, in the home and small business, at least. https://tools.ietf.org/wg/homenet/ some dhcpv6 specific info is spread around using the new hncp protocol. blatant plug - https://github.com/sbyx/odhcp6c is now the best open source dhcpv6 (and pd) client "out there" right now IMHO. Dave T?ht Let's go make home routers and wifi faster! With better software! https://www.gofundme.com/savewifi On Sat, Nov 21, 2015 at 11:13 AM, Frederik Kriewitz wrote: > On Fri, Nov 20, 2015 at 10:35 PM, Jim Burwell wrote: >> 2) What are the most common ways of managing the routing of delegated >> prefixes in the ISPs routing domain? Has a standard method/best >> practice emerged yet? Routing protocols? IPv6 RAs? >> >> One obvious answer would be routing protocols. In my brief googling, >> I've seen a forum post that seems to indicate that Comcast makes use of >> RIPng on their CPE to propagate routing information for prefixes >> delegated to it. Can someone confirm this? This would seem as good a >> method as any to do this, albeit with obvious security concerns. > > We've build a small tool which watches the dhcpd6 lease file for > changes and injects the PD routes using exabgp (iBGP session with > corresponding IA_NA address as next-hop for the IA_PD prefix). > > Best Regards, > Frederik Kriewitz From baldur.norddahl at gmail.com Sat Nov 21 13:44:35 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 21 Nov 2015 14:44:35 +0100 Subject: route converge time Message-ID: Hi I got a network with two routers and two IP transit providers, each with the full BGP table. Router A is connected to provider A and router B to provider B. We use MPLS with a L3VPN with a VRF called "internet". Everything happens inside that VRF. Now if I interrupt one of the IP transit circuits, the routers will take several minutes to remove the now bad routes and move everything to the remaining transit provider. This is very noticeable to the customers. I am looking into ways to improve that. I added a default static route 0.0.0.0 to provider A on router A and did the same to provider B on router B. This is supposed to be a trick that allows the network to move packets before everything is fully converged. Traffic might not leave the most optimal link, but it will be delivered. Say I take down the provider A link on router A. As I understand it, the hardware will notice this right away and stop using the routes to provider A. Router A might know about the default route on router B and send the traffic to router B. However this is not much help, because on router B there is no link that is down, so the hardware is unaware until the BGP process is done updating the hardware tables. Which apparently can take several minutes. My routers also have multipath support, but I am unsure if that is going to be of any help. Anyone got any tricks or pointers to what can be done to optimize the downtime in case of a IP transit link failure? Or the related case of one my routers going down or the link between them going down (the traffic would go a non-direct way instead if the direct link is down). Thanks, Baldur From dcorbe at hammerfiber.com Sat Nov 21 15:17:22 2015 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Sat, 21 Nov 2015 10:17:22 -0500 Subject: route converge time In-Reply-To: (Baldur Norddahl's message of "Sat, 21 Nov 2015 14:44:35 +0100") References: Message-ID: <8737vzbcvx.fsf@corbe.net> Baldur Norddahl writes: > Hi > > I added a default static route 0.0.0.0 to provider A on router A and did > the same to provider B on router B. This is supposed to be a trick that > allows the network to move packets before everything is fully converged. > Traffic might not leave the most optimal link, but it will be > delivered. The other thing here is the one of the main advantages of taking a full routing table is so that you can be free of default routes. > > Anyone got any tricks or pointers to what can be done to optimize the > downtime in case of a IP transit link failure? Or the related case of one > my routers going down or the link between them going down (the traffic > would go a non-direct way instead if the direct link is down). > With only two providers, route convergence is always going to be a painful process. Especially if you're still using old equipment on your edge. But you shouldn't be losing transit links often enough for it to be a major problem for your users. If you are, I'd start looking at other options for transit. You could also take smaller tables from a wider variety of providers. Most folks in the wholesale transit business offer default routing and customer specifics. This won't give you best path selection in the truest sense but if you're connected to enough upstream providers it can get you pretty close. And if you're a content consumer rather than a content provider, go and peer with anyone that has an open peering policy. Most important content providers will peer with anyone that services customer and have relatively flexible traffic minimums. Off the top of my head that's facebook, google, netflix, yahoo, microsoft and several others. From jneiberger at gmail.com Sat Nov 21 19:37:05 2015 From: jneiberger at gmail.com (John Neiberger) Date: Sat, 21 Nov 2015 12:37:05 -0700 Subject: Comcast eastern Washington storm update? In-Reply-To: References: Message-ID: Lots of update information on the WA Comcast website. Looks like they've had daily updates. http://wacomcast.com/2015/11/21/washington-storm-update-nov-21-2015/ John On Fri, Nov 20, 2015 at 8:00 AM, Joshua wrote: > We had hundreds of users in WA with Comcast having many issues yesterday. Comcast never would acknowledge it was an issue. It finally just cleared up. Their VOIP phones were not working, all website were really slow and generating PCBD errors. Not sure if this helps but thought I would mention it. We had no other users reporting issues from the rest of the USA. > >> Date: Thu, 19 Nov 2015 18:10:27 -0800 >> Subject: Re: Comcast eastern Washington storm update? >> From: aaron at heyaaron.com >> To: nanog at nanog.org >> >> Er, I should have mentioned 'Spokane, WA'. >> On Nov 19, 2015 4:39 PM, "Aaron C. de Bruyn" wrote: >> >> > I know the east side of my state was nailed with a big storm. The Gov >> > declared a state of emergency. >> > >> > Comcast service for several of my clients has understandably been down >> > since Tuesday. >> > >> > I called in a few times over the last two days and the automated message >> > keeps saying "service should be restored by 12:01 PM today", after that >> > time passes the message gets changed to 7:01 PM, then to 8:01 AM, then >> > 12:01 PM. (Always '01'--what's with that?) >> > >> > One time I let the call get through to a rep and they couldn't give any >> > information on the extent of the damage or an ETA. >> > >> > Can anyone at Comcast shed some light on the disaster over there or give a >> > rough idea on service restoration? >> > >> > As always, I appreciate the hard work from the guys in the trenches and >> > the engineers that miraculously seem to keep my clients up 24/7. (Just for >> > fun, attached are stats about the router for 365 days before the storm >> > hit--and most of that 'unreachable' time was probably issues with the >> > monitoring server.) >> > >> > Thanks again for all your hard work. >> > >> > -A >> > >> > >> > > From bill at herrin.us Sat Nov 21 23:09:47 2015 From: bill at herrin.us (William Herrin) Date: Sat, 21 Nov 2015 18:09:47 -0500 Subject: route converge time In-Reply-To: References: Message-ID: On Sat, Nov 21, 2015 at 8:44 AM, Baldur Norddahl wrote: > I got a network with two routers and two IP transit providers, each with > the full BGP table. Router A is connected to provider A and router B to > provider B. We use MPLS with a L3VPN with a VRF called "internet". > Everything happens inside that VRF. > > Now if I interrupt one of the IP transit circuits, the routers will take > several minutes to remove the now bad routes and move everything to the > remaining transit provider. This is very noticeable to the customers. I am > looking into ways to improve that. Hi Baldur, Buy a router with a beefier CPU. It takes a lot of operations to remove the hundreds of thousands of stale routes from the RIB and completely recalculate FIB. > I added a default static route 0.0.0.0 to provider A on router A and did > the same to provider B on router B. This is supposed to be a trick that > allows the network to move packets before everything is fully converged. > Traffic might not leave the most optimal link, but it will be delivered. No. The router already has the alternate route in its RIB, just as soon as the CPU can find time to remove the dead one and recalculate the FIB. It won't get around to it any faster just because you also have a default route in the RIB. You -could- elect not to receive a full routing table -at all- and then tie default routes to something in the partial table you accept. Fewer routes = less recalculation. The trade off is that when the problem is upstream from your particular link to a service provider, it's less likely that you will recover from the error -at all- since your router knows fewer of the individual routes. This will also damage your ability to balance the load between the service providers. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jimb at jsbc.cc Sat Nov 21 23:27:41 2015 From: jimb at jsbc.cc (Jim Burwell) Date: Sat, 21 Nov 2015 15:27:41 -0800 Subject: DHCPv6 PD & Routing Questions In-Reply-To: References: <564F923B.9080200@jsbc.cc> Message-ID: <5650FDED.70300@jsbc.cc> On 2015-11-21 05:08, Dave Taht wrote: > y'all might want to look over the work of the ietf homenet working > group for some insight into plans for dhcp-pd, and routing > interactions, in the home and small business, at least. > > https://tools.ietf.org/wg/homenet/ > > some dhcpv6 specific info is spread around using the new hncp protocol. > > blatant plug - https://github.com/sbyx/odhcp6c is now the best open > source dhcpv6 (and pd) client "out there" right now IMHO. > Dave T?ht > Let's go make home routers and wifi faster! With better software! > https://www.gofundme.com/savewifi > > > On Sat, Nov 21, 2015 at 11:13 AM, Frederik Kriewitz > wrote: >> On Fri, Nov 20, 2015 at 10:35 PM, Jim Burwell wrote: >>> 2) What are the most common ways of managing the routing of delegated >>> prefixes in the ISPs routing domain? Has a standard method/best >>> practice emerged yet? Routing protocols? IPv6 RAs? >>> >>> One obvious answer would be routing protocols. In my brief googling, >>> I've seen a forum post that seems to indicate that Comcast makes use of >>> RIPng on their CPE to propagate routing information for prefixes >>> delegated to it. Can someone confirm this? This would seem as good a >>> method as any to do this, albeit with obvious security concerns. >> We've build a small tool which watches the dhcpd6 lease file for >> changes and injects the PD routes using exabgp (iBGP session with >> corresponding IA_NA address as next-hop for the IA_PD prefix). >> >> Best Regards, >> Frederik Kriewitz Thanks for all the replies. The gist I get is that no real SOP/BCP has emerged yet for doing this, and everyone is home-brewing their own methods. One of the other reasons I ask is because I was experimenting with Comcast Business IPv6. I was sent a cable modem that could do dual-stack and did PD. But it seemed really broken. It would only assign a /64, and never routed anything it assigned back to the head end as far as I could see through the customer interface. I was told that the firmware was broken. - Jim From joe at nethead.com Sat Nov 21 03:16:04 2015 From: joe at nethead.com (Joe Hamelin) Date: Fri, 20 Nov 2015 19:16:04 -0800 Subject: Rack Locks In-Reply-To: <7413288204807398677@unknownmsgid> References: <707FECBBE7FEE241ABE4CAAF4025A0BE03984B46@corpmail.burlingtontelecom.com> <7413288204807398677@unknownmsgid> Message-ID: http://www.netbotz.ca/rackbotz.htm Just make sure you put one on both the front and back. Otherwise one could just open the back and unplug the Ethernet cable. -- Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 On Fri, Nov 20, 2015 at 6:06 PM, Joe Abley wrote: > On Nov 20, 2015, at 20:55, Jimmy Hess wrote: > > > You're not going to be able to look at a log and see Joe opened it at > 2:45AM > > 12 months ago, and ever since then, the servers are not quite right. > > And I would have got away with it to, if it wasn't for you kids and > your pesky logs. > > > Joe > From s.kakaroukas at connecticore.com Sat Nov 21 15:14:25 2015 From: s.kakaroukas at connecticore.com (Spyros Kakaroukas) Date: Sat, 21 Nov 2015 15:14:25 +0000 Subject: route converge time In-Reply-To: References: Message-ID: <2bd19e1ea692497585edd8c2a48bd300@FGRIDEXMBX01.fusiongrid.local> Hey, This is a complex problems and there are quite a few parts to consider. Let's assume you want to optimize how fast you choose the right best exit after a failure. The opposite ( how fast the internet chooses the best entry point into your network after a failure ) is usually not that easy to influence. The first component of our total convergence time is how fast you can actually detect the failure. If your bgp speaker is directly connected to the transit's bgp speaker with no boxes inbetween, then you can detect the failure about as fast as it takes your end to detect that the link is down, which is usually pretty fast ( you could tune the carrier-delay if you want to ). If there are any other boxes in-between , you can't rely on that. The best solution in that case, imho, would be to use bfd. If you can't do that, you may want try and tune bgp keepalive/holddown timers. Keep in mind that running aggressive timers will consume cpu resources on both your and the provider's end. The second component would be how much time it takes bgp to find the alternate routes. As you're using l3vpn , there's an easy trick to apply here. You can just set up a different rd on each router and both routers will end up with routes from both providers in their bgp table. That will obviously consume hardware resources ( usually ram, as not every route will make it to the fib just yet ) so make sure your routers can handle it. The third component would be how much time it takes you to update the fib itself. This is usually fast for a single route, but not as fast as you might think for ~550k routes. What you can do to speed this up depends somewhat on your hardware. Most big vendors do support some flavor of a hierarchical fib ( cisco calls theirs pic core ). Keep in mind that this will also eat up hardware resources depending on the implementation itself. Make sure you read up before you try anything as it could end up doubling your fib requirements, which aren't light to begin with for full tables. Last but not least, keep scalabity in mind when reading the last 2 paragraphs. On newer boxes, tuning for fast convergence may be more than fine for 2 providers but practically impossible for, say, 6 or 8 of them. As for the scenarios of local failure, first of all, really try to make sure that the ibgp session between them ( or towards their RRs/etc ) is as robust as it gets. Assuming that's taken care of, convergence should be about as much time as it takes your igp to figure it out. Bfd and usual igp timer/feature adjustments do apply. Next-hop tracking and fast peering detection ( assuming cisco ) are also nice, though if you have defaults in your network, you might want to exclude them from being used for either. My thoughts and words are my own. Kind Regards, Spyros -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Baldur Norddahl Sent: Saturday, November 21, 2015 3:45 PM To: nanog at nanog.org Subject: route converge time Hi I got a network with two routers and two IP transit providers, each with the full BGP table. Router A is connected to provider A and router B to provider B. We use MPLS with a L3VPN with a VRF called "internet". Everything happens inside that VRF. Now if I interrupt one of the IP transit circuits, the routers will take several minutes to remove the now bad routes and move everything to the remaining transit provider. This is very noticeable to the customers. I am looking into ways to improve that. I added a default static route 0.0.0.0 to provider A on router A and did the same to provider B on router B. This is supposed to be a trick that allows the network to move packets before everything is fully converged. Traffic might not leave the most optimal link, but it will be delivered. Say I take down the provider A link on router A. As I understand it, the hardware will notice this right away and stop using the routes to provider A. Router A might know about the default route on router B and send the traffic to router B. However this is not much help, because on router B there is no link that is down, so the hardware is unaware until the BGP process is done updating the hardware tables. Which apparently can take several minutes. My routers also have multipath support, but I am unsure if that is going to be of any help. Anyone got any tricks or pointers to what can be done to optimize the downtime in case of a IP transit link failure? Or the related case of one my routers going down or the link between them going down (the traffic would go a non-direct way instead if the direct link is down). Thanks, Baldur -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4829 bytes Desc: not available URL: From bzs at theworld.com Sat Nov 21 21:33:33 2015 From: bzs at theworld.com (bzs at theworld.com) Date: Sat, 21 Nov 2015 16:33:33 -0500 Subject: Rack Locks In-Reply-To: <7413288204807398677@unknownmsgid> References: <707FECBBE7FEE241ABE4CAAF4025A0BE03984B46@corpmail.burlingtontelecom.com> <7413288204807398677@unknownmsgid> Message-ID: <22096.58157.8218.745601@pcls8.std.com> On November 20, 2015 at 21:06 jabley at hopcount.ca (Joe Abley) wrote: > On Nov 20, 2015, at 20:55, Jimmy Hess wrote: > > > You're not going to be able to look at a log and see Joe opened it at 2:45AM > > 12 months ago, and ever since then, the servers are not quite right. > > And I would have got away with it to, if it wasn't for you kids and > your pesky logs. Possibly NSFW-language depending on your W but just an image no audio: http://www.soveryfunny.com/wp-content/uploads/2014/09/too_many_fucking_security_cameras.jpeg or http://tinyurl.com/ngnvs4s -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD The World | Public Access Internet | Since 1989 *oo* From jra at baylink.com Sun Nov 22 17:03:15 2015 From: jra at baylink.com (Jay Ashworth) Date: Sun, 22 Nov 2015 12:03:15 -0500 (EST) Subject: Gmail spam filtering In-Reply-To: <6615793.38.1448211639795.JavaMail.root@benjamin.baylink.com> Message-ID: <7597897.40.1448211795254.JavaMail.root@benjamin.baylink.com> Bout a month ago, I had someone crack a POP password on my private mail server, and got a couple days of spam out through it before I caught it on Sunday afternoon. I locked it down, and am this weekend replacing that mail server with one of current vintage, serving the same domain from a linode instance on a different IP and, obviously, transport network. I'm finding, though, that gmail is spam-filing the emails I send out, presumably because they're on the same domain name in the envelope. Anyone got a pointer to where I go to assure Google I'm on top of it now? The mail delivers to their inbound MX ok, it just ends up in the spam folder, even on my business GoogleApps account. Delivers to Yahoomail just fine. I checked the new IP in the MXtoolbox RBL checker, and no hits, but does gmail know what ranges are assigned to VPS providers, like with the cable swamp, and bias its spamchecking accordingly? 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 colton.conor at gmail.com Sun Nov 22 18:12:50 2015 From: colton.conor at gmail.com (Colton Conor) Date: Sun, 22 Nov 2015 12:12:50 -0600 Subject: route converge time In-Reply-To: References: Message-ID: What types of routers are you currently using? On Sat, Nov 21, 2015 at 7:44 AM, Baldur Norddahl wrote: > Hi > > I got a network with two routers and two IP transit providers, each with > the full BGP table. Router A is connected to provider A and router B to > provider B. We use MPLS with a L3VPN with a VRF called "internet". > Everything happens inside that VRF. > > Now if I interrupt one of the IP transit circuits, the routers will take > several minutes to remove the now bad routes and move everything to the > remaining transit provider. This is very noticeable to the customers. I am > looking into ways to improve that. > > I added a default static route 0.0.0.0 to provider A on router A and did > the same to provider B on router B. This is supposed to be a trick that > allows the network to move packets before everything is fully converged. > Traffic might not leave the most optimal link, but it will be delivered. > > Say I take down the provider A link on router A. As I understand it, the > hardware will notice this right away and stop using the routes to provider > A. Router A might know about the default route on router B and send the > traffic to router B. However this is not much help, because on router B > there is no link that is down, so the hardware is unaware until the BGP > process is done updating the hardware tables. Which apparently can take > several minutes. > > My routers also have multipath support, but I am unsure if that is going to > be of any help. > > Anyone got any tricks or pointers to what can be done to optimize the > downtime in case of a IP transit link failure? Or the related case of one > my routers going down or the link between them going down (the traffic > would go a non-direct way instead if the direct link is down). > > Thanks, > > Baldur > From colinj at gt86car.org.uk Sun Nov 22 18:23:10 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Sun, 22 Nov 2015 18:23:10 +0000 Subject: Gmail spam filtering In-Reply-To: <7597897.40.1448211795254.JavaMail.root@benjamin.baylink.com> References: <7597897.40.1448211795254.JavaMail.root@benjamin.baylink.com> Message-ID: You can override the spam filter to inbox for specific domains/address's via googleapps gmail filter settings config Colin > On 22 Nov 2015, at 17:03, Jay Ashworth wrote: > > Bout a month ago, I had someone crack a POP password on my private mail server, > and got a couple days of spam out through it before I caught it on Sunday > afternoon. > > I locked it down, and am this weekend replacing that mail server with one > of current vintage, serving the same domain from a linode instance on a > different IP and, obviously, transport network. > > I'm finding, though, that gmail is spam-filing the emails I send out, > presumably because they're on the same domain name in the envelope. > > Anyone got a pointer to where I go to assure Google I'm on top of it now? > > The mail delivers to their inbound MX ok, it just ends up in the spam folder, > even on my business GoogleApps account. Delivers to Yahoomail just fine. > > I checked the new IP in the MXtoolbox RBL checker, and no hits, but does > gmail know what ranges are assigned to VPS providers, like with the cable > swamp, and bias its spamchecking accordingly? > > 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 fhr at fhrnet.eu Sun Nov 22 17:33:29 2015 From: fhr at fhrnet.eu (Filip Hruska) Date: Sun, 22 Nov 2015 18:33:29 +0100 Subject: Gmail spam filtering In-Reply-To: <7597897.40.1448211795254.JavaMail.root@benjamin.baylink.com> References: <7597897.40.1448211795254.JavaMail.root@benjamin.baylink.com> Message-ID: <5651FC69.3050007@fhrnet.eu> You might need to setup/change a SPF record for that domain. I always had Google marking my email as spam when I tried to send emails with no SPF record. On 11/22/2015 06:03 PM, Jay Ashworth wrote: > Bout a month ago, I had someone crack a POP password on my private mail server, > and got a couple days of spam out through it before I caught it on Sunday > afternoon. > > I locked it down, and am this weekend replacing that mail server with one > of current vintage, serving the same domain from a linode instance on a > different IP and, obviously, transport network. > > I'm finding, though, that gmail is spam-filing the emails I send out, > presumably because they're on the same domain name in the envelope. > > Anyone got a pointer to where I go to assure Google I'm on top of it now? > > The mail delivers to their inbound MX ok, it just ends up in the spam folder, > even on my business GoogleApps account. Delivers to Yahoomail just fine. > > I checked the new IP in the MXtoolbox RBL checker, and no hits, but does > gmail know what ranges are assigned to VPS providers, like with the cable > swamp, and bias its spamchecking accordingly? > > Cheers, > -- jra > From jra at baylink.com Sun Nov 22 19:36:50 2015 From: jra at baylink.com (Jay R. Ashworth) Date: Sun, 22 Nov 2015 19:36:50 +0000 (UTC) Subject: Gmail spam filtering In-Reply-To: <5651FC69.3050007@fhrnet.eu> References: <7597897.40.1448211795254.JavaMail.root@benjamin.baylink.com> <5651FC69.3050007@fhrnet.eu> Message-ID: <1487841473.171.1448221010149.JavaMail.zimbra@baylink.com> That wasn't a problem prior to my departure, but apparently it is now. I've just added an SPF for the domain. -- j ----- Original Message ----- > From: "Filip Hruska" > To: nanog at nanog.org > Sent: Sunday, November 22, 2015 12:33:29 PM > Subject: Re: Gmail spam filtering > You might need to setup/change a SPF record for that domain. I always > had Google marking my email as spam when I tried to send emails with no > SPF record. > > On 11/22/2015 06:03 PM, Jay Ashworth wrote: >> Bout a month ago, I had someone crack a POP password on my private mail server, >> and got a couple days of spam out through it before I caught it on Sunday >> afternoon. >> >> I locked it down, and am this weekend replacing that mail server with one >> of current vintage, serving the same domain from a linode instance on a >> different IP and, obviously, transport network. >> >> I'm finding, though, that gmail is spam-filing the emails I send out, >> presumably because they're on the same domain name in the envelope. >> >> Anyone got a pointer to where I go to assure Google I'm on top of it now? >> >> The mail delivers to their inbound MX ok, it just ends up in the spam folder, >> even on my business GoogleApps account. Delivers to Yahoomail just fine. >> >> I checked the new IP in the MXtoolbox RBL checker, and no hits, but does >> gmail know what ranges are assigned to VPS providers, like with the cable >> swamp, and bias its spamchecking accordingly? >> >> Cheers, >> -- jra From gtaylor at tnetconsulting.net Sun Nov 22 20:34:38 2015 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sun, 22 Nov 2015 13:34:38 -0700 Subject: Gmail spam filtering In-Reply-To: <1487841473.171.1448221010149.JavaMail.zimbra@baylink.com> References: <7597897.40.1448211795254.JavaMail.root@benjamin.baylink.com> <5651FC69.3050007@fhrnet.eu> <1487841473.171.1448221010149.JavaMail.zimbra@baylink.com> Message-ID: <565226DE.3000209@tnetconsulting.net> On 11/22/2015 12:36 PM, Jay R. Ashworth wrote: > I've just added an SPF for the domain. While you are at it, consider adding DKIM too. You might as well publish DMARC records if you have SPF and DKIM. -- Grant. . . . unix || die From saper at saper.info Sun Nov 22 20:43:32 2015 From: saper at saper.info (Marcin Cieslak) Date: Sun, 22 Nov 2015 20:43:32 +0000 Subject: Gmail spam filtering In-Reply-To: <565226DE.3000209@tnetconsulting.net> References: <7597897.40.1448211795254.JavaMail.root@benjamin.baylink.com> <5651FC69.3050007@fhrnet.eu> <1487841473.171.1448221010149.JavaMail.zimbra@baylink.com> <565226DE.3000209@tnetconsulting.net> Message-ID: On Sun, 22 Nov 2015, Grant Taylor via NANOG wrote: > On 11/22/2015 12:36 PM, Jay R. Ashworth wrote: > > I've just added an SPF for the domain. > > While you are at it, consider adding DKIM too. > > You might as well publish DMARC records if you have SPF and DKIM. I do only DKIM and no SPF for my domain names and it mostly works with Gmail. Marcin From nanog-isp at mail.com Sun Nov 22 23:30:02 2015 From: nanog-isp at mail.com (nanog-isp at mail.com) Date: Mon, 23 Nov 2015 00:30:02 +0100 Subject: Binge On! - And So This is Net Neutrality? Message-ID: So, which porn sites are zero rated? Uh, asking for a friend. (Would love to be a fly on the wall when those and other uncomfortable requests to join come in.) Jared From greg at foletta.org Mon Nov 23 00:00:16 2015 From: greg at foletta.org (Greg Foletta) Date: Mon, 23 Nov 2015 11:00:16 +1100 Subject: route converge time In-Reply-To: References: Message-ID: Would be helpful if you let us know what platform you're running on. Assuming a Cisco, make sure next-hop-tracking not disabled (enabled by default on modern IOS), then at "BGP Prefix Independent Convergence", so your BGP process isn't walking the entire RIB to see which next-hops it needs to change. Greg Foletta greg at foletta.org +61 408 199 630 On 23 November 2015 at 05:12, Colton Conor wrote: > What types of routers are you currently using? > > On Sat, Nov 21, 2015 at 7:44 AM, Baldur Norddahl < > baldur.norddahl at gmail.com> > wrote: > > > Hi > > > > I got a network with two routers and two IP transit providers, each with > > the full BGP table. Router A is connected to provider A and router B to > > provider B. We use MPLS with a L3VPN with a VRF called "internet". > > Everything happens inside that VRF. > > > > Now if I interrupt one of the IP transit circuits, the routers will take > > several minutes to remove the now bad routes and move everything to the > > remaining transit provider. This is very noticeable to the customers. I > am > > looking into ways to improve that. > > > > I added a default static route 0.0.0.0 to provider A on router A and did > > the same to provider B on router B. This is supposed to be a trick that > > allows the network to move packets before everything is fully converged. > > Traffic might not leave the most optimal link, but it will be delivered. > > > > Say I take down the provider A link on router A. As I understand it, the > > hardware will notice this right away and stop using the routes to > provider > > A. Router A might know about the default route on router B and send the > > traffic to router B. However this is not much help, because on router B > > there is no link that is down, so the hardware is unaware until the BGP > > process is done updating the hardware tables. Which apparently can take > > several minutes. > > > > My routers also have multipath support, but I am unsure if that is going > to > > be of any help. > > > > Anyone got any tricks or pointers to what can be done to optimize the > > downtime in case of a IP transit link failure? Or the related case of one > > my routers going down or the link between them going down (the traffic > > would go a non-direct way instead if the direct link is down). > > > > Thanks, > > > > Baldur > > > From swmike at swm.pp.se Mon Nov 23 06:24:21 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 23 Nov 2015 07:24:21 +0100 (CET) Subject: DHCPv6 PD & Routing Questions In-Reply-To: <5650FDED.70300@jsbc.cc> References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> Message-ID: On Sat, 21 Nov 2015, Jim Burwell wrote: > The gist I get is that no real SOP/BCP has emerged yet for doing this, > and everyone is home-brewing their own methods. Quite a few years back I did the following experiment: I had a Cisco 7200 router running some kind of not-too-old-code, which had a /48 routed to it. I then created a DHCPv6 PD pool of /56:es. I had 2 D-Link home gateways (DIR-655 I think) with some beta code I received from D-Link. I then hooked them up like this: C7200-DIR1-DIR2-Computer The C7200 would delegate a /56 to DIR1, who would then subdelegate a /64 out of that one to DIR2 who would assign that to its LAN interface so Computer could use SLAAC itself an address out of it. This worked fine. I also tested C7200-WIN7PC-Computer (WIN7PC running Windows7) and turned on ICS (Internet connection sharing), and WIN7PC would get a /56, allocate a /64 to its "LAN" interface, and Computer worked just fine. I never tried hooking up another router behind it. I am not 100% sure it was running Windows7, it might even have been running Windows Vista. So I'd say there is equipment out there that works, as expected, but as seen in this thread, plenty of equipment that doesn't. -- Mikael Abrahamsson email: swmike at swm.pp.se From tarko at lanparty.ee Mon Nov 23 08:53:13 2015 From: tarko at lanparty.ee (Tarko Tikan) Date: Mon, 23 Nov 2015 10:53:13 +0200 Subject: DHCPv6 PD & Routing Questions In-Reply-To: References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> Message-ID: <5652D3F9.6030009@lanparty.ee> hey, > So I'd say there is equipment out there that works, as expected, but as > seen in this thread, plenty of equipment that doesn't. Latest OpenWrt releases include https://github.com/sbyx/odhcpd as DHCPv4/6 server. This enables hierarchical PD on these platforms, ie. subdelegate /64s from the /56 PD prefix you received from SP. It's not the most configurable thing at this point but it does the job. -- tarko From baldur.norddahl at gmail.com Mon Nov 23 11:21:23 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 23 Nov 2015 12:21:23 +0100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <5650FDED.70300@jsbc.cc> References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> Message-ID: On 22 November 2015 at 00:27, Jim Burwell wrote: > One of the other reasons I ask is because I was experimenting with > Comcast Business IPv6. I was sent a cable modem that could do > dual-stack and did PD. But it seemed really broken. It would only > assign a /64, and never routed anything it assigned back to the head end > as far as I could see through the customer interface. I was told that > the firmware was broken. > > I would say how to handle it on the ISP network and how to do it in the home/SOHO is two different problems and set of requirements. The enterprise network might be a third case but is probably more like the ISP network. Regards, Baldur From owen at delong.com Mon Nov 23 18:37:08 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 23 Nov 2015 10:37:08 -0800 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <5652D3F9.6030009@lanparty.ee> References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> <5652D3F9.6030009@lanparty.ee> Message-ID: <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> > On Nov 23, 2015, at 00:53 , Tarko Tikan wrote: > > hey, > >> So I'd say there is equipment out there that works, as expected, but as >> seen in this thread, plenty of equipment that doesn't. > > Latest OpenWrt releases include https://github.com/sbyx/odhcpd as DHCPv4/6 server. This enables hierarchical PD on these platforms, ie. subdelegate /64s from the /56 PD prefix you received from SP. > > It's not the most configurable thing at this point but it does the job. If your SP is giving you a /56, you should complain and ask for a proper /48. Especially if you?re doing any real hierarchical PD. Owen From chkuhtz at microsoft.com Mon Nov 23 18:42:06 2015 From: chkuhtz at microsoft.com (Christian Kuhtz) Date: Mon, 23 Nov 2015 18:42:06 +0000 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> Message-ID: <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com> I don't know if this is NN or not, but the concept is ancient. Even back in the dark ages of mobile, zero rating and associated rev share were very common. Whether this is relevant to NN or not is for lawyers. Christian > On Nov 20, 2015, at 7:47 AM, Jay Ashworth wrote: > > According to: > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.engadget.com%2f2015%2f11%2f20%2ffcc-chairman-gives-t-mobiles-binge-on-the-thumbs-up%2f&data=01%7c01%7cchkuhtz%40microsoft.com%7c7c7a1c832d1a4d7d615008d2f1c1ebb0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=XFz213dwbX7LmC2FwUAeJn5HP%2bAV9rU6b4dCatA%2b6FM%3d > > Chairman Wheeler thinks that T-mob's new "customers can get uncapped media > stream data, but only from the people we like" service called Binge On > is pro-competition. > > My take on this is that the service is *precisely* what Net Neutrality > was supposed to prevent -- carriers offering paid fast-lanes to content > providers -- and that this is anti-competitive to the sort of "upstart > YouTube" entities that NN was supposed to protect... > > and that *that* is the competition that NN was supposed to protect. > > And I just said the same thing two different ways. > > Cause does anyone here think that T-mob is giving those *carriers* pride > of place *for free*? > > Corporations don't - in my experience - give away lots of money out of > the goodness of their hearts. > > Cheers, > -- jr 'whacky weekend' a > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.bcp38.info&data=01%7c01%7cchkuhtz%40microsoft.com%7c7c7a1c832d1a4d7d615008d2f1c1ebb0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=pqF%2fnrW6m6K0%2fdcNZO7pAm9xfEPpoYXHfaoS%2fpGZcsc%3d 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From marka at isc.org Mon Nov 23 20:27:06 2015 From: marka at isc.org (Mark Andrews) Date: Tue, 24 Nov 2015 07:27:06 +1100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: Your message of "Mon, 23 Nov 2015 10:37:08 -0800." <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> <5652D3F9.6030009@lanparty.ee> <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> Message-ID: <20151123202706.6A0A83D76305@rock.dv.isc.org> In message <29055E3F-B923-4E21-8513-60CC8C14A6C9 at delong.com>, Owen DeLong writes: > > > On Nov 23, 2015, at 00:53 , Tarko Tikan wrote: > > > > hey, > > > >> So I'd say there is equipment out there that works, as expected, but as > >> seen in this thread, plenty of equipment that doesn't. > > > > Latest OpenWrt releases include https://github.com/sbyx/odhcpd as > DHCPv4/6 server. This enables hierarchical PD on these platforms, ie. > subdelegate /64s from the /56 PD prefix you received from SP. > > > > It's not the most configurable thing at this point but it does the job. > > If your SP is giving you a /56, you should complain and ask for a proper > /48. > > Especially if you???re doing any real hierarchical PD. > > Owen Or you just don't do heirarchial routing / PD inside the site. It isn't needed. 65000 intra site routes isn't that hard handle nor is 65000 PD's for the border routers. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mpoublon at secantnet.net Mon Nov 23 16:37:33 2015 From: mpoublon at secantnet.net (Mike Poublon) Date: Mon, 23 Nov 2015 11:37:33 -0500 Subject: Rack Locks In-Reply-To: <707FECBBE7FEE241ABE4CAAF4025A0BE03984B46@corpmail.burlingtontelecom.com> References: <707FECBBE7FEE241ABE4CAAF4025A0BE03984B46@corpmail.burlingtontelecom.com> Message-ID: <565340CD.2030905@secantnet.net> Our datacenter build used RCI rack locks/handles and over the last year of production since going live haven't had any issues. http://www.rutherfordcontrols.com/en/products/electric-locks/3525/ We used the non-RFID model and put a standard card reader at the end of every row. Our Access control system handles the locking and unlocking as well as log generation (HIPAA compliant facility). These handles would work just as well with some form of relay controller. Locking the rack level also removed the need to allow building cages ( which would be a waste of space in our facility). Mike Poublon Senior Datacenter Network Engineer 269-375-8996 Main Secant Technologies 6395 Technology Ave. Suite A Kalamazoo, MI 49009 On 11/20/2015 3:37 PM, Kevin Burke wrote: > What kind of experience do people have with rack access control systems > (electronic locks)? Anything I should pay attention to with the > products? > > Hope this questions hasn't already been answered. Not to picky about > what/who. The APC solution seems to start getting pricy with multiple > racks. I see arduino has an RFID reader but haven't found the door > opener. > > The racks in question are standard APC (SX?) racks. > > Background > We have half a dozen racks, mostly ours. Mostly I want something to log > who opened what door when. Cooling overhaul is next on the list but one > at a time. Even with cameras those janky make nobody happy. > > If someone knows a better place to ask this that would be nice too. > > Thanks for your time! > > Kevin Burke > 802-540-0979 > Burlington Telecom - City of Burlington > 200 Church St, Burlington, VT 05401 > From owen at delong.com Mon Nov 23 22:12:01 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 23 Nov 2015 14:12:01 -0800 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com> References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com> Message-ID: Except there?s no revenue share here. According to T-Mobile, the streaming partners aren?t paying anything to T-Mo and T-Mo isn?t paying them. It?s kind of like zero-rating in that the customers don?t pay bandwidth charges, but it?s different in that the service provider isn?t being asked to subsidize the network provider (usual implementation of zero-rating). Owen > On Nov 23, 2015, at 10:42 , Christian Kuhtz wrote: > > I don't know if this is NN or not, but the concept is ancient. Even back in the dark ages of mobile, zero rating and associated rev share were very common. > > Whether this is relevant to NN or not is for lawyers. > > Christian > >> On Nov 20, 2015, at 7:47 AM, Jay Ashworth wrote: >> >> According to: >> >> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.engadget.com%2f2015%2f11%2f20%2ffcc-chairman-gives-t-mobiles-binge-on-the-thumbs-up%2f&data=01%7c01%7cchkuhtz%40microsoft.com%7c7c7a1c832d1a4d7d615008d2f1c1ebb0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=XFz213dwbX7LmC2FwUAeJn5HP%2bAV9rU6b4dCatA%2b6FM%3d >> >> Chairman Wheeler thinks that T-mob's new "customers can get uncapped media >> stream data, but only from the people we like" service called Binge On >> is pro-competition. >> >> My take on this is that the service is *precisely* what Net Neutrality >> was supposed to prevent -- carriers offering paid fast-lanes to content >> providers -- and that this is anti-competitive to the sort of "upstart >> YouTube" entities that NN was supposed to protect... >> >> and that *that* is the competition that NN was supposed to protect. >> >> And I just said the same thing two different ways. >> >> Cause does anyone here think that T-mob is giving those *carriers* pride >> of place *for free*? >> >> Corporations don't - in my experience - give away lots of money out of >> the goodness of their hearts. >> >> Cheers, >> -- jr 'whacky weekend' a >> -- >> Jay R. Ashworth Baylink jra at baylink.com >> Designer The Things I Think RFC 2100 >> Ashworth & Associates https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.bcp38.info&data=01%7c01%7cchkuhtz%40microsoft.com%7c7c7a1c832d1a4d7d615008d2f1c1ebb0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=pqF%2fnrW6m6K0%2fdcNZO7pAm9xfEPpoYXHfaoS%2fpGZcsc%3d 2000 Land Rover DII >> St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From morrowc.lists at gmail.com Mon Nov 23 22:16:03 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 23 Nov 2015 17:16:03 -0500 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com> Message-ID: On Mon, Nov 23, 2015 at 5:12 PM, Owen DeLong wrote: > Except there?s no revenue share here. According to T-Mobile, the streaming partners > aren?t paying anything to T-Mo and T-Mo isn?t paying them. It?s kind of like zero-rating > in that the customers don?t pay bandwidth charges, but it?s different in that the service > provider isn?t being asked to subsidize the network provider (usual implementation of > zero-rating). equal exchange of value doesn't have to be dollars/pesos/euros changing hands right? -chris From owen at delong.com Mon Nov 23 22:19:40 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 23 Nov 2015 14:19:40 -0800 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <20151123202706.6A0A83D76305@rock.dv.isc.org> References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> <5652D3F9.6030009@lanparty.ee> <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> <20151123202706.6A0A83D76305@rock.dv.isc.org> Message-ID: <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com> > On Nov 23, 2015, at 12:27 , Mark Andrews wrote: > > > In message <29055E3F-B923-4E21-8513-60CC8C14A6C9 at delong.com>, Owen DeLong writes: >> >>> On Nov 23, 2015, at 00:53 , Tarko Tikan wrote: >>> >>> hey, >>> >>>> So I'd say there is equipment out there that works, as expected, but as >>>> seen in this thread, plenty of equipment that doesn't. >>> >>> Latest OpenWrt releases include https://github.com/sbyx/odhcpd as >> DHCPv4/6 server. This enables hierarchical PD on these platforms, ie. >> subdelegate /64s from the /56 PD prefix you received from SP. >>> >>> It's not the most configurable thing at this point but it does the job. >> >> If your SP is giving you a /56, you should complain and ask for a proper >> /48. >> >> Especially if you?re doing any real hierarchical PD. >> >> Owen > > Or you just don't do heirarchial routing / PD inside the site. It isn't needed. > 65000 intra site routes isn't that hard handle nor is 65000 PD's for the border > routers. Yes, but to get to 65000 intrasite routes, you?ve got to already have that /48 I was suggesting you ask for. Owen From owen at delong.com Mon Nov 23 22:26:28 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 23 Nov 2015 14:26:28 -0800 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com> Message-ID: > On Nov 23, 2015, at 14:16 , Christopher Morrow wrote: > > On Mon, Nov 23, 2015 at 5:12 PM, Owen DeLong wrote: >> Except there?s no revenue share here. According to T-Mobile, the streaming partners >> aren?t paying anything to T-Mo and T-Mo isn?t paying them. It?s kind of like zero-rating >> in that the customers don?t pay bandwidth charges, but it?s different in that the service >> provider isn?t being asked to subsidize the network provider (usual implementation of >> zero-rating). > > equal exchange of value doesn't have to be dollars/pesos/euros > changing hands right? > -chris Sure, but I really don?t think there?s an exchange per se in this case, given that T-Mo is (at least apparently) willing to accommodate any streaming provider that wants to participate so long as they are willing to conform to a fairly basic set of technical criteria. Owen From marka at isc.org Mon Nov 23 22:39:54 2015 From: marka at isc.org (Mark Andrews) Date: Tue, 24 Nov 2015 09:39:54 +1100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: Your message of "Mon, 23 Nov 2015 14:19:40 -0800." <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com> References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> <5652D3F9.6030009@lanparty.ee> <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> <20151123202706.6A0A83D76305@rock.dv.isc.org> <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com> Message-ID: <20151123223954.A3DA13D775D5@rock.dv.isc.org> In message <6B49EE17-6DE1-4493-91C1-478F3BA44F12 at delong.com>, Owen DeLong write s: > > > On Nov 23, 2015, at 12:27 , Mark Andrews wrote: > > > > > > In message <29055E3F-B923-4E21-8513-60CC8C14A6C9 at delong.com>, Owen > DeLong writes: > >> > >>> On Nov 23, 2015, at 00:53 , Tarko Tikan wrote: > >>> > >>> hey, > >>> > >>>> So I'd say there is equipment out there that works, as expected, but > as > >>>> seen in this thread, plenty of equipment that doesn't. > >>> > >>> Latest OpenWrt releases include https://github.com/sbyx/odhcpd as > >> DHCPv4/6 server. This enables hierarchical PD on these platforms, ie. > >> subdelegate /64s from the /56 PD prefix you received from SP. > >>> > >>> It's not the most configurable thing at this point but it does the > job. > >> > >> If your SP is giving you a /56, you should complain and ask for a > proper > >> /48. > >> > >> Especially if you???re doing any real hierarchical PD. > >> > >> Owen > > > > Or you just don't do heirarchial routing / PD inside the site. It > isn't needed. > > 65000 intra site routes isn't that hard handle nor is 65000 PD's for > the border > > routers. > > Yes, but to get to 65000 intrasite routes, you???ve got to already have > that /48 I was > suggesting you ask for. > > Owen And a /56 gives you 256 subnets. When you remove unnecessary heirachical delegation / routing that still supports a reasonable sized home network. A /48 would be better but getting the allocation working is the first step. It's easy enough to make a /48 not work if you insist on heirachical delegation. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From niels=nanog at bakker.net Mon Nov 23 22:42:41 2015 From: niels=nanog at bakker.net (Niels Bakker) Date: Mon, 23 Nov 2015 23:42:41 +0100 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com> References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com> Message-ID: <20151123224241.GI3097@excession.tpb.net> * chkuhtz at microsoft.com (Christian Kuhtz) [Mon 23 Nov 2015, 19:43 CET]: >I don't know if this is NN or not, but the concept is ancient. Even >back in the dark ages of mobile, zero rating and associated rev >share were very common. > >Whether this is relevant to NN or not is for lawyers. This is backwards. It's definitely a net neutrality issue since it concerns inequal access for customers to content on the Internet. Whether it's subject to current laws or regulation is a matter for the lawyers, but current laws and regulations at least in the US are a far cry from actual net neutrality. (If you want a good example of that, look to the Netherlands.) -- Niels. From marka at isc.org Mon Nov 23 22:58:17 2015 From: marka at isc.org (Mark Andrews) Date: Tue, 24 Nov 2015 09:58:17 +1100 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: Your message of "Mon, 23 Nov 2015 14:26:28 -0800." References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com> Message-ID: <20151123225817.314A03D77872@rock.dv.isc.org> In message , Owen DeLong write s: > > > On Nov 23, 2015, at 14:16 , Christopher Morrow > wrote: > > > > On Mon, Nov 23, 2015 at 5:12 PM, Owen DeLong wrote: > >> Except there???s no revenue share here. According to T-Mobile, the > streaming partners > >> aren???t paying anything to T-Mo and T-Mo isn???t paying them. It???s kind > of like zero-rating > >> in that the customers don???t pay bandwidth charges, but it???s different > in that the service > >> provider isn???t being asked to subsidize the network provider (usual > implementation of > >> zero-rating). > > > > equal exchange of value doesn't have to be dollars/pesos/euros > > changing hands right? > > -chris > > Sure, but I really don???t think there???s an exchange per se in this case, > given that T-Mo > is (at least apparently) willing to accommodate any streaming provider > that wants to > participate so long as they are willing to conform to a fairly basic set > of technical criteria. No. This is T-Mo saying they are neutral but not actually being so. This is like writing a job add for one particular person. Its just as easy to identify a UDP stream as it is a TCP stream. You can ratelimit a UDP stream as easily as a TCP stream. You can have congestion control over UDP as well as over TCP. Just because the base transport doesn't give you some of these and you have to implement them higher up the stack is no reason to throw out a transport. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Mon Nov 23 23:22:45 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 23 Nov 2015 15:22:45 -0800 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: <20151123225817.314A03D77872@rock.dv.isc.org> References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com> <20151123225817.314A03D77872@rock.dv.isc.org> Message-ID: <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com> > On Nov 23, 2015, at 14:58 , Mark Andrews wrote: > > > In message >, Owen DeLong write > s: >> >>> On Nov 23, 2015, at 14:16 , Christopher Morrow >> wrote: >>> >>> On Mon, Nov 23, 2015 at 5:12 PM, Owen DeLong wrote: >>>> Except there?s no revenue share here. According to T-Mobile, the >> streaming partners >>>> aren?t paying anything to T-Mo and T-Mo isn?t paying them. It?s kind >> of like zero-rating >>>> in that the customers don?t pay bandwidth charges, but it?s different >> in that the service >>>> provider isn?t being asked to subsidize the network provider (usual >> implementation of >>>> zero-rating). >>> >>> equal exchange of value doesn't have to be dollars/pesos/euros >>> changing hands right? >>> -chris >> >> Sure, but I really don?t think there?s an exchange per se in this case, >> given that T-Mo >> is (at least apparently) willing to accommodate any streaming provider >> that wants to >> participate so long as they are willing to conform to a fairly basic set >> of technical criteria. > > No. This is T-Mo saying they are neutral but not actually being so. > This is like writing a job add for one particular person. > > Its just as easy to identify a UDP stream as it is a TCP stream. > You can ratelimit a UDP stream as easily as a TCP stream. You can > have congestion control over UDP as well as over TCP. Just because > the base transport doesn't give you some of these and you have to > implement them higher up the stack is no reason to throw out a > transport. Are there a significant number (ANY?) streaming video providers using UDP to deliver their streams? I admit I?m mostly ignorant here, but at least the ones I?m familiar with all use TCP. Further, it depends on how you define a stream? If a stream is a conversation between two particular endpoints using consistent port numbers, then sure, it?s (somewhat) easy to identify, except? OTOH, if a stream is considered all of the packets involved in a particular user watching a particular video, then depending on implementation, this could be much harder to identify over UDP than TCP. For example, if the stream is delivered via a torrent-like delivery system over UDP, it could be very hard to identify that all the various seemingly random UDP packets are part of that particular video delivery. If the requirements were specific enough that they matched a particularly small subset of video delivery services, then I might agree with you. In this case, they seem to have been written more from the technical limitations of T-Mobiles current ability to identify the traffic than targeted at a specific service. For example, I seriously doubt that video delivered from http://us-st.xhcdn.com/swf/ ? is likely to be among their ?target candidates?. Nonetheless, it does appear that if xhcdn chooses to apply under the program, they wouldn?t have any trouble meeting the requirements. (if you want to review the kind of videos hosted on xhcdn, visit their client www.xhamster.com . Warning? NSFW) You can make all the claims you want about how they should have or could have implemented this, but unless you have evidence that the issue is actually an attempt to circumvent the intent of net neutrality and not merely a technical limitation of their particular implementation, then I really don?t think you have a basis for your claim above. Owen From baldur.norddahl at gmail.com Tue Nov 24 01:28:22 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 24 Nov 2015 02:28:22 +0100 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com> References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com> <20151123225817.314A03D77872@rock.dv.isc.org> <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com> Message-ID: On 24 November 2015 at 00:22, Owen DeLong wrote: > Are there a significant number (ANY?) streaming video providers using UDP > to deliver their streams? > What else could we have that is UDP based? Ah voice calls. Video calls. Stuff that requires low latency and where TCP retransmit of stale data is bad. Media without buffering because it is real time. And why would a telco want to zero rate all the bandwidth heavy media with certain exceptions? Like not zero rating media that happens to compete with some of their own services, such as voice calls and video calls. Yes sounds like net neutrality to me too (or not!). Regards, Baldur From owen at delong.com Tue Nov 24 02:05:44 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 23 Nov 2015 18:05:44 -0800 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com> <20151123225817.314A03D77872@rock.dv.isc.org> <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com> Message-ID: > On Nov 23, 2015, at 17:28 , Baldur Norddahl wrote: > > On 24 November 2015 at 00:22, Owen DeLong wrote: > >> Are there a significant number (ANY?) streaming video providers using UDP >> to deliver their streams? >> > > What else could we have that is UDP based? Ah voice calls. Video calls. > Stuff that requires low latency and where TCP retransmit of stale data is > bad. Media without buffering because it is real time. > > And why would a telco want to zero rate all the bandwidth heavy media with > certain exceptions? Like not zero rating media that happens to compete with > some of their own services, such as voice calls and video calls. > > Yes sounds like net neutrality to me too (or not!). > > Regards, > > Baldur All T-Mobile plans include unlimited 128kbps data, so a voice call is effectively already zero-rated for all practical purposes. I guess the question is: Is it better for the consumer to pay for everything equally, or, is it reasonable for carriers to be able to give away some free data without opening it up to everything? To me, net neutrality isn?t as much about what you charge the customer for the data, it?s about whether you prioritize certain classes of traffic to the detriment of others in terms of service delivery. If T-Mobile were taking money from the video streaming services or only accepting certain video streaming services, I?d likely agree with you that this is a neutrality issue. However, in this case, it appears to me that they aren?t trying to give an advantage to any particular competing streaming video service over the other, they aren?t taking money from participants in the program, and consumers stand to benefit from it. If you see an actual way in which it?s better for everyone if T-Mobile weren?t doing this, then please explain it. If not, then this strikes me as harmless and overall benefits consumers. Owen From marka at isc.org Tue Nov 24 02:45:21 2015 From: marka at isc.org (Mark Andrews) Date: Tue, 24 Nov 2015 13:45:21 +1100 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: Your message of "Mon, 23 Nov 2015 18:05:44 -0800." References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com> <20151123225817.314A03D77872@rock.dv.isc.org> <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com> Message-ID: <20151124024521.AE6543D7BCAB@rock.dv.isc.org> In message , Owen DeLong write s: > > > On Nov 23, 2015, at 17:28 , Baldur Norddahl > wrote: > > > > On 24 November 2015 at 00:22, Owen DeLong wrote: > > > >> Are there a significant number (ANY?) streaming video providers using > >> UDP to deliver their streams? > >> > > > > What else could we have that is UDP based? Ah voice calls. Video calls. > > Stuff that requires low latency and where TCP retransmit of stale data > > is bad. Media without buffering because it is real time. > > > > And why would a telco want to zero rate all the bandwidth heavy media > > with certain exceptions? Like not zero rating media that happens to > > compete with some of their own services, such as voice calls and video > > calls. > > > > Yes sounds like net neutrality to me too (or not!). > > > > Regards, > > > > Baldur > > All T-Mobile plans include unlimited 128kbps data, so a voice call is > effectively already zero-rated for all practical purposes. > > I guess the question is: Is it better for the consumer to pay for > everything equally, or, is it reasonable for carriers to be able to > give away some free data without opening it up to everything? > > To me, net neutrality isn???t as much about what you charge the customer > for the data, it???s about whether you prioritize certain classes of > traffic to the detriment of others in terms of service delivery. > > If T-Mobile were taking money from the video streaming services or only > accepting certain video streaming services, I???d likely agree with you > that this is a neutrality issue. > > However, in this case, it appears to me that they aren???t trying to give > an advantage to any particular competing streaming video service over > the other, they aren???t taking money from participants in the program, > and consumers stand to benefit from it. It not being neutral over the content. If content != "video stream we like" then you will be penalised when the customer goes over their data limit. > If you see an actual way in which it???s better for everyone if T-Mobile > weren???t doing this, then please explain it. If not, then this strikes > me as harmless and overall benefits consumers. Actually this is as harmful as NAT for the same reasons as NAT. It a opportunity cost at a minimum. T-Mo could have just increased the data limits by the data usage of 7x24 standard definition video stream and achieved the same thing in a totally network neutral way. Instead they choose to play favourites with a type of technology. We are giving X Gigs of additional data. This is enough to allow you to stream your favourite video channels at standard definition all day long and not run out of data. > Owen Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From ktims at stargate.ca Tue Nov 24 03:00:11 2015 From: ktims at stargate.ca (Keenan Tims) Date: Mon, 23 Nov 2015 19:00:11 -0800 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com> <20151123225817.314A03D77872@rock.dv.isc.org> <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com> Message-ID: <5653D2BB.8030704@stargate.ca> I'm surprised you're supporting T-Mob here Owen. To me it's pretty clear: they are charging more for bits that are not streaming video. That's not neutral treatment from a policy perspective, and has no basis in the cost of operating the network. Granted, the network itself is neutral, but the purported purpose of NN in my eyes is twofold: take away the influence of the network on user and operator behaviour, and encourage an open market in network services (both content and access). Allowing zero-rating based on *any* criteria gives them a strong influence over what the end users are going to do with their network connection, and distorts the market for network services. What makes streaming video special to merit zero-rating? I like Clay's connection to the boiling frog. Yes, it's "nice" for most consumers now, but it's still distorting the market. I'm also not seeing why they have to make this so complicated. If they can afford to zero-rate high-bandwidth services like video and audio streaming, clearly there is network capacity to spare. The user behaviour they're encouraging with free video streaming is *precisely* what the incumbents claimed was causing congestion to merit throttling a few years ago, and still to this day whine about constantly. I don't have data, but I would expect usage of this to align quite nicely with their current peaks. Why not just raise the caps to something reasonable or make it unlimited across the board? I could even get behind zero-rating all 'off-peak-hours' use like we used to have for mobile voice; at least that makes sense for the network. What they're doing though is product differentiation where none exists; in fact the zero-rating is likely to cause more load on the system than just doubling or tripling the users' caps. That there seems to be little obvious justification for it from a network perspective makes me vary wary. Keenan On 2015-11-23 18:05, Owen DeLong wrote: > >> On Nov 23, 2015, at 17:28 , Baldur Norddahl wrote: >> >> On 24 November 2015 at 00:22, Owen DeLong wrote: >> >>> Are there a significant number (ANY?) streaming video providers using UDP >>> to deliver their streams? >>> >> >> What else could we have that is UDP based? Ah voice calls. Video calls. >> Stuff that requires low latency and where TCP retransmit of stale data is >> bad. Media without buffering because it is real time. >> >> And why would a telco want to zero rate all the bandwidth heavy media with >> certain exceptions? Like not zero rating media that happens to compete with >> some of their own services, such as voice calls and video calls. >> >> Yes sounds like net neutrality to me too (or not!). >> >> Regards, >> >> Baldur > > All T-Mobile plans include unlimited 128kbps data, so a voice call is effectively > already zero-rated for all practical purposes. > > I guess the question is: Is it better for the consumer to pay for everything equally, > or, is it reasonable for carriers to be able to give away some free data without opening > it up to everything? > > To me, net neutrality isn?t as much about what you charge the customer for the data, it?s about > whether you prioritize certain classes of traffic to the detriment of others in terms of > service delivery. > > If T-Mobile were taking money from the video streaming services or only accepting > certain video streaming services, I?d likely agree with you that this is a neutrality > issue. > > However, in this case, it appears to me that they aren?t trying to give an advantage to > any particular competing streaming video service over the other, they aren?t taking > money from participants in the program, and consumers stand to benefit from it. > > If you see an actual way in which it?s better for everyone if T-Mobile weren?t doing this, > then please explain it. If not, then this strikes me as harmless and overall benefits > consumers. > > Owen > From nanog at ics-il.net Tue Nov 24 12:46:54 2015 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 24 Nov 2015 06:46:54 -0600 (CST) Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: <5653D2BB.8030704@stargate.ca> Message-ID: <1513574724.3169.1448369243926.JavaMail.mhammett@ThunderFuck> Not so much to Keenan, but the thread as a whole. It continually amazes me the lack comprehension of the entire network world so many on this list have. They've confined to their little bubble of 100GigE pipes everywhere and everyone should just have balls to the walls everything all of the time. Maybe NANOG needs to have some sessions on putting people into the real world or maybe teach practicality in all circumstances. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Keenan Tims" To: nanog at nanog.org Sent: Monday, November 23, 2015 9:00:11 PM Subject: Re: Binge On! - And So This is Net Neutrality? I'm surprised you're supporting T-Mob here Owen. To me it's pretty clear: they are charging more for bits that are not streaming video. That's not neutral treatment from a policy perspective, and has no basis in the cost of operating the network. Granted, the network itself is neutral, but the purported purpose of NN in my eyes is twofold: take away the influence of the network on user and operator behaviour, and encourage an open market in network services (both content and access). Allowing zero-rating based on *any* criteria gives them a strong influence over what the end users are going to do with their network connection, and distorts the market for network services. What makes streaming video special to merit zero-rating? I like Clay's connection to the boiling frog. Yes, it's "nice" for most consumers now, but it's still distorting the market. I'm also not seeing why they have to make this so complicated. If they can afford to zero-rate high-bandwidth services like video and audio streaming, clearly there is network capacity to spare. The user behaviour they're encouraging with free video streaming is *precisely* what the incumbents claimed was causing congestion to merit throttling a few years ago, and still to this day whine about constantly. I don't have data, but I would expect usage of this to align quite nicely with their current peaks. Why not just raise the caps to something reasonable or make it unlimited across the board? I could even get behind zero-rating all 'off-peak-hours' use like we used to have for mobile voice; at least that makes sense for the network. What they're doing though is product differentiation where none exists; in fact the zero-rating is likely to cause more load on the system than just doubling or tripling the users' caps. That there seems to be little obvious justification for it from a network perspective makes me vary wary. Keenan On 2015-11-23 18:05, Owen DeLong wrote: > >> On Nov 23, 2015, at 17:28 , Baldur Norddahl wrote: >> >> On 24 November 2015 at 00:22, Owen DeLong wrote: >> >>> Are there a significant number (ANY?) streaming video providers using UDP >>> to deliver their streams? >>> >> >> What else could we have that is UDP based? Ah voice calls. Video calls. >> Stuff that requires low latency and where TCP retransmit of stale data is >> bad. Media without buffering because it is real time. >> >> And why would a telco want to zero rate all the bandwidth heavy media with >> certain exceptions? Like not zero rating media that happens to compete with >> some of their own services, such as voice calls and video calls. >> >> Yes sounds like net neutrality to me too (or not!). >> >> Regards, >> >> Baldur > > All T-Mobile plans include unlimited 128kbps data, so a voice call is effectively > already zero-rated for all practical purposes. > > I guess the question is: Is it better for the consumer to pay for everything equally, > or, is it reasonable for carriers to be able to give away some free data without opening > it up to everything? > > To me, net neutrality isn?t as much about what you charge the customer for the data, it?s about > whether you prioritize certain classes of traffic to the detriment of others in terms of > service delivery. > > If T-Mobile were taking money from the video streaming services or only accepting > certain video streaming services, I?d likely agree with you that this is a neutrality > issue. > > However, in this case, it appears to me that they aren?t trying to give an advantage to > any particular competing streaming video service over the other, they aren?t taking > money from participants in the program, and consumers stand to benefit from it. > > If you see an actual way in which it?s better for everyone if T-Mobile weren?t doing this, > then please explain it. If not, then this strikes me as harmless and overall benefits > consumers. > > Owen > From sander at steffann.nl Tue Nov 24 14:43:33 2015 From: sander at steffann.nl (Sander Steffann) Date: Tue, 24 Nov 2015 15:43:33 +0100 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com> <20151123225817.314A03D77872@rock.dv.isc.org> <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com> Message-ID: <9A7AF784-10DC-4E0D-B47D-80B94C293D99@steffann.nl> Hi Owen, > To me, net neutrality isn?t as much about what you charge the customer for the data, it?s about > whether you prioritize certain classes of traffic to the detriment of others in terms of > service delivery. > > If T-Mobile were taking money from the video streaming services or only accepting > certain video streaming services, I?d likely agree with you that this is a neutrality > issue. You are right in that it could have been much worse. However: giving a big advantage to a certain technology does get in the way of innovation in e.g. new video delivery technologies. And in the long run less innovation will not be to the benefit of the internet's users. We are already too locked in to tcp-port-80-and-443 as it is :( Cheers, Sander From Valdis.Kletnieks at vt.edu Tue Nov 24 16:47:06 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 24 Nov 2015 11:47:06 -0500 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <20151123223954.A3DA13D775D5@rock.dv.isc.org> References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> <5652D3F9.6030009@lanparty.ee> <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> <20151123202706.6A0A83D76305@rock.dv.isc.org> <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com> <20151123223954.A3DA13D775D5@rock.dv.isc.org> Message-ID: <42270.1448383626@turing-police.cc.vt.edu> On Tue, 24 Nov 2015 09:39:54 +1100, Mark Andrews said: > And a /56 gives you 256 subnets. When you remove unnecessary > heirachical delegation / routing that still supports a reasonable > sized home network. If you have a *workable* solution for the case where you're handed a /56 and are running a second CeroWRT or OpenWRT to improve coverage at the other end of the house that doesn't include hierarchical routing, we'd love to hear it. Note that "workable" includes "Joe Sixpack must have a reasonable chance of it working with minimum user configuration". Aternatively, if you have a algorithm for hierarchical deployment that doesn't burn through bits as fast, we'd love to hear it.. -------------- 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 Nov 24 17:10:38 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 24 Nov 2015 12:10:38 -0500 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <42270.1448383626@turing-police.cc.vt.edu> References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> <5652D3F9.6030009@lanparty.ee> <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> <20151123202706.6A0A83D76305@rock.dv.isc.org> <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com> <20151123223954.A3DA13D775D5@rock.dv.isc.org> <42270.1448383626@turing-police.cc.vt.edu> Message-ID: <44145.1448385038@turing-police.cc.vt.edu> On Tue, 24 Nov 2015 11:47:06 -0500, Valdis.Kletnieks at vt.edu said: > Aternatively, if you have a algorithm for hierarchical deployment that > doesn't burn through bits as fast, we'd love to hear it.. That will teach me to reply to stuff before reading *all* my e-mail (actually, probably not). Hot off the press today (now we just need to wait for code to ship): Subject: RFC 7695 on Distributed Prefix Assignment Algorithm From: rfc-editor at rfc-editor.org Date: Tue, 24 Nov 2015 08:17:58 -0800 (PST) (11:17 EST) To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org Cc: homenet at ietf.org, rfc-editor at rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7695 Title: Distributed Prefix Assignment Algorithm Author: P. Pfister, B. Paterson, J. Arkko Status: Standards Track Stream: IETF Date: November 2015 Mailbox: pierre.pfister at darou.fr, paterson.b at gmail.com, jari.arkko at piuha.net Pages: 20 Characters: 46244 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-homenet-prefix-assignment-08.txt URL: https://www.rfc-editor.org/info/rfc7695 DOI: http://dx.doi.org/10.17487/RFC7695 This document specifies a distributed algorithm for dividing a set of prefixes in a manner that allows for automatic assignment of sub-prefixes that are unique and non-overlapping. Used in conjunction with a protocol that provides flooding of information among a set of participating nodes, prefix configuration within a network may be automated. This document is a product of the Home Networking Working Group of the IETF. This is now a Proposed Standard. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From dhubbard at dino.hostasaurus.com Tue Nov 24 18:02:34 2015 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 24 Nov 2015 13:02:34 -0500 Subject: Opinions on Arista 7280? Message-ID: Curious if anyone's used the 7280 and wants to share their experience? I'm looking at it primarily for three reasons, MLAG (i.e. multi-chassis LACP), large ARP/MAC table (256k entries) and large IPv6 neighbor table (256k entries). For the table sizes we would like out of one pair of switches, we'd be into the Cisco 7000 series, but that's dramatically more expensive and we don't need much of anything else that it offers. Looked at Brocade too, but they don't have devices that can do the multi chassis LACP, has the huge table sizes and has a reasonable number of 10gig ports. It was possible to construct a workable solution using VDX's for switching and CER's for routing, but that's more complex than Arista's option if it's a usable option. Thanks, David From chuckchurch at gmail.com Tue Nov 24 18:11:17 2015 From: chuckchurch at gmail.com (Chuck Church) Date: Tue, 24 Nov 2015 13:11:17 -0500 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <42270.1448383626@turing-police.cc.vt.edu> References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> <5652D3F9.6030009@lanparty.ee> <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> <20151123202706.6A0A83D76305@rock.dv.isc.org> <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com> <20151123223954.A3DA13D775D5@rock.dv.isc.org> <42270.1448383626@turing-police.cc.vt.edu> Message-ID: <036101d126e3$994ac1a0$cbe044e0$@gmail.com> -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Valdis.Kletnieks at vt.edu Sent: Tuesday, November 24, 2015 11:47 AM To: Mark Andrews Cc: nanog at nanog.org Subject: Re: DHCPv6 PD & Routing Questions >If you have a *workable* solution for the case where you're handed a /56 and are running a second CeroWRT or OpenWRT to improve coverage at the other end of the house that >doesn't include hierarchical routing, we'd love to hear it. Note that "workable" includes "Joe Sixpack must have a reasonable chance of it working with minimum user configuration". Why wouldn't you just attach the second device via a LAN (versus the WAN) port, and disabling it's DHCP/SLAAC? Or use a proper L2-only wireless device like a range extender or an AP? If Joe Sixpack can't handle that, he probably is going to fail at getting OpenWRT to work, or configuring static IPv6 routes, or modifying windows firewall to allow his other subnets access. Chuck From josh at kyneticwifi.com Tue Nov 24 18:39:30 2015 From: josh at kyneticwifi.com (Josh Reynolds) Date: Tue, 24 Nov 2015 12:39:30 -0600 Subject: Opinions on Arista 7280? In-Reply-To: References: Message-ID: Have you looked at the brocade MLXe line? On Nov 24, 2015 12:05 PM, "David Hubbard" wrote: > Curious if anyone's used the 7280 and wants to share their experience? > I'm looking at it primarily for three reasons, MLAG (i.e. multi-chassis > LACP), large ARP/MAC table (256k entries) and large IPv6 neighbor table > (256k entries). For the table sizes we would like out of one pair of > switches, we'd be into the Cisco 7000 series, but that's dramatically > more expensive and we don't need much of anything else that it offers. > > Looked at Brocade too, but they don't have devices that can do the multi > chassis LACP, has the huge table sizes and has a reasonable number of > 10gig ports. It was possible to construct a workable solution using > VDX's for switching and CER's for routing, but that's more complex than > Arista's option if it's a usable option. > > Thanks, > > David > From mikevs at xs4all.net Tue Nov 24 19:27:09 2015 From: mikevs at xs4all.net (Miquel van Smoorenburg) Date: Tue, 24 Nov 2015 20:27:09 +0100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <85AC9398-125E-4078-86DA-63962DF76662@delong.com> References: <564F923B.9080200@jsbc.cc> Message-ID: <201511241927.tAOJR92k002867@xs9.xs4all.nl> In article you write: >Unfortunately, PD is really still in its infancy in terms of development >and real running code for complete implementations throughout any >sort of site hierarchy. Well, it works for us. Connect a second router (Fritz!box) behind the primary one and it works. We can't see how many customers actually do that but potentially it could be hunderds of thousands, so in practice it's still thousands or tens of thousands. I'm always amused by people saying IPv6 is difficult or impossible for various reasons and that real implementations of X and Y do not exist while we've been doing it for years. Probably because we didn't really know what we were getting into and simply started. The only way progress is ever made, it seems :) Mike. From dcorbe at hammerfiber.com Tue Nov 24 21:16:44 2015 From: dcorbe at hammerfiber.com (dcorbe at hammerfiber.com) Date: Tue, 24 Nov 2015 21:16:44 +0000 Subject: Opinions on Arista 7280? In-Reply-To: References: Message-ID: <20151124211644.Horde.lD99Cr_55xe-kQAREaXd1Q1@box1044.bluehost.com> I love the MLXe as a platform. Especially for a campus style switch. Also Cisco really isn't expensive. Not for this type of application. A 7606-S can be purchased refurbished for like 90% off list price. The market is seriously glutted with them. Quoting Josh Reynolds : > Have you looked at the brocade MLXe line? > On Nov 24, 2015 12:05 PM, "David Hubbard" > wrote: > >> Curious if anyone's used the 7280 and wants to share their experience? >> I'm looking at it primarily for three reasons, MLAG (i.e. multi-chassis >> LACP), large ARP/MAC table (256k entries) and large IPv6 neighbor table >> (256k entries). For the table sizes we would like out of one pair of >> switches, we'd be into the Cisco 7000 series, but that's dramatically >> more expensive and we don't need much of anything else that it offers. >> >> Looked at Brocade too, but they don't have devices that can do the multi >> chassis LACP, has the huge table sizes and has a reasonable number of >> 10gig ports. It was possible to construct a workable solution using >> VDX's for switching and CER's for routing, but that's more complex than >> Arista's option if it's a usable option. >> >> Thanks, >> >> David >> From owen at delong.com Tue Nov 24 21:47:45 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 24 Nov 2015 13:47:45 -0800 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <201511241927.tAOJR92k002867@xs9.xs4all.nl> References: <564F923B.9080200@jsbc.cc> <201511241927.tAOJR92k002867@xs9.xs4all.nl> Message-ID: <7CE50705-6D2F-4BF8-B043-6A242EA6E745@delong.com> > On Nov 24, 2015, at 11:27 , Miquel van Smoorenburg wrote: > > In article you write: >> Unfortunately, PD is really still in its infancy in terms of development >> and real running code for complete implementations throughout any >> sort of site hierarchy. > > Well, it works for us. Connect a second router (Fritz!box) behind > the primary one and it works. We can't see how many customers > actually do that but potentially it could be hunderds of thousands, > so in practice it's still thousands or tens of thousands. > > I'm always amused by people saying IPv6 is difficult or impossible > for various reasons and that real implementations of X and Y > do not exist while we've been doing it for years. Probably because > we didn't really know what we were getting into and simply started. > The only way progress is ever made, it seems :) > > Mike. What size prefix are you delegating to those end users? Owen From mikevs at xs4all.net Tue Nov 24 21:51:28 2015 From: mikevs at xs4all.net (Miquel van Smoorenburg) Date: Tue, 24 Nov 2015 22:51:28 +0100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <7CE50705-6D2F-4BF8-B043-6A242EA6E745@delong.com> References: <564F923B.9080200@jsbc.cc> <201511241927.tAOJR92k002867@xs9.xs4all.nl> <7CE50705-6D2F-4BF8-B043-6A242EA6E745@delong.com> Message-ID: <5654DBE0.1020506@xs4all.net> On 24/11/15 22:47, Owen DeLong wrote: >> On Nov 24, 2015, at 11:27 , Miquel van Smoorenburg wrote: >> In article you write: >>> Unfortunately, PD is really still in its infancy in terms of development >>> and real running code for complete implementations throughout any >>> sort of site hierarchy. >> >> Well, it works for us. > > What size prefix are you delegating to those end users? A /48. Mike. From owen at delong.com Tue Nov 24 21:58:42 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 24 Nov 2015 13:58:42 -0800 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <5654DBE0.1020506@xs4all.net> References: <564F923B.9080200@jsbc.cc> <201511241927.tAOJR92k002867@xs9.xs4all.nl> <7CE50705-6D2F-4BF8-B043-6A242EA6E745@delong.com> <5654DBE0.1020506@xs4all.net> Message-ID: <3070F629-9190-4317-ACF0-40FA0F6DB142@delong.com> > On Nov 24, 2015, at 13:51 , Miquel van Smoorenburg wrote: > > On 24/11/15 22:47, Owen DeLong wrote: >>> On Nov 24, 2015, at 11:27 , Miquel van Smoorenburg wrote: >>> In article you write: >>>> Unfortunately, PD is really still in its infancy in terms of development >>>> and real running code for complete implementations throughout any >>>> sort of site hierarchy. >>> >>> Well, it works for us. >> >> What size prefix are you delegating to those end users? > > A /48. > > Mike. Exactly? This discussion wasn?t about can or can?t IPv6. The topic of hierarchy came up when someone mentioned getting a /56 from their provider and I pointed out that anyone receiving a /56 should contact their provider and request a proper /48. Owen From tom at ninjabadger.net Tue Nov 24 22:29:37 2015 From: tom at ninjabadger.net (Tom Hill) Date: Tue, 24 Nov 2015 22:29:37 +0000 Subject: Opinions on Arista 7280? In-Reply-To: <20151124211644.Horde.lD99Cr_55xe-kQAREaXd1Q1@box1044.bluehost.com> References: <20151124211644.Horde.lD99Cr_55xe-kQAREaXd1Q1@box1044.bluehost.com> Message-ID: <5654E4D1.9000902@ninjabadger.net> On 24/11/15 21:16, dcorbe at hammerfiber.com wrote: > A 7606-S can be purchased refurbished for like 90% off list price. The > market is seriously glutted with them. Not sure the OP was talking about 7600s. They're mostly End-of-Life, and not in any way suited to the OP's requirements (MLAG missing, low density, nothing like Arista 7280) If the Cisco refurb route is available, N7K is probably obtainable through those channels. You'd be surprised what companies lease and then throw back for whatever reason. And in relation to Brocade: I'd feel very uncomfortable throwing any *new* money at MLXe, CER or CES. Strategy for those families seems to have fallen off of a cliff. -- Tom From marka at isc.org Tue Nov 24 23:36:47 2015 From: marka at isc.org (Mark Andrews) Date: Wed, 25 Nov 2015 10:36:47 +1100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: Your message of "Tue, 24 Nov 2015 11:47:06 -0500." <42270.1448383626@turing-police.cc.vt.edu> References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> <5652D3F9.6030009@lanparty.ee> <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> <20151123202706.6A0A83D76305@rock.dv.isc.org> <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com> <20151123223954.A3DA13D775D5@rock.dv.isc.org> <42270.1448383626@turing-police.cc.vt.edu> Message-ID: <20151124233647.E3D5B3D855A4@rock.dv.isc.org> In message <42270.1448383626 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu writes: > --==_Exmh_1448383626_2779P > Content-Type: text/plain; charset=us-ascii > > On Tue, 24 Nov 2015 09:39:54 +1100, Mark Andrews said: > > And a /56 gives you 256 subnets. When you remove unnecessary > > heirachical delegation / routing that still supports a reasonable > > sized home network. > > If you have a *workable* solution for the case where you're handed a /56 > and are running a second CeroWRT or OpenWRT to improve coverage at the > other end of the house that doesn't include hierarchical routing, > we'd love to hear it. Note that "workable" includes "Joe Sixpack must > have a reasonable chance of it working with minimum user configuration". Give PD is designed to allow you to have multiple delegation requests from one router to the dhcp server (router) and manage them independently. Just request prefixes as you need them. If the dhcp server (router) doesn't have any available it just make a up stream request. Ultimately this will get to the border router and be fullfilled there flowing back through all the itermediate servers and depending upon how they are configured setting up routes. Alternatively the original requesting route injects a route for the delegated prefix into the IRP. This isn't rocket science. Just use your @#!Q$# brains when you build CPE routers. This isn't new. DHCP servers have got answers from upsteam DHCP servers for various IPv4 DHCP options (e.g. DNS servers). PD isn't conceptually different other than it is done on demand rather than in advance. Mark > Aternatively, if you have a algorithm for hierarchical deployment that > doesn't burn through bits as fast, we'd love to hear it.. > > --==_Exmh_1448383626_2779P > Content-Type: application/pgp-signature > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: Exmh version 2.5 07/13/2001 > > iQIVAwUBVlSUigdmEQWDXROgAQLFHg/9EMTa5V0bocoBLFkA/JEZpkngRmU3wp3t > xtTyCCi9f5HT2TkCfPB3ai4C+QTINgPP0aVKjw10toQ2uEaBFPe900z0DL2YDUYS > ehN5ZHJzr2VdZoxbm1L5PMoib2UaLio8/WsGQgk2Jz6TCFoPe7hvGoV2qYnDmN0/ > wOK8cxVZqa1DXlMssXW3cJmIH0m4r5u2onV1sdj34uveVi8kp7PcRyLeVdZ0Wcr7 > Fji58QTJ4Iy/AqioWIpkQOB6coA3/UcHDT1clWIf9UP+vMv0Bc2OxUrTG0v6BDCl > Si3Vg22yvyTkirjQWTlxMGhWoYO7Sz1QXQTan0ZT8QZEtOfbFNBg2GXux4iNTvXq > g5ADYJD5WMb7y7Wk1hMjTCpoKwBUa04xh0RelfKF+gzhRAyRaEstC3O8hCOcbxEM > yP1K4Cf/2+iNQVeeY5x2DoJwa5wlVfV81LtcKAVxBAUayLwFScepb0RbLIKB7Rlw > aKqT2btXbR9cMyuNh0EmhaVVijNhwIHYwZw1PB6XVSivA8xaLpQf5T4H3Tyf9FGJ > LGgF3/em92qaqu9UzwiBiFHLNM1KT+tdyhvg2gkvvGQxxPA/26cVkOhW5rP4f4LS > 9Ov1gVeMQz6NMNC+2RkT4TUbyYj1HqH3zVIkiAsHVFfQ1wCmw9dx1B33x3pfGLhY > 3eCaVb6CKY8= > =pcXt > -----END PGP SIGNATURE----- > > --==_Exmh_1448383626_2779P-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From contact at winterei.se Wed Nov 25 00:06:48 2015 From: contact at winterei.se (Paul S.) Date: Wed, 25 Nov 2015 09:06:48 +0900 Subject: Opinions on Arista 7280? In-Reply-To: <5654E4D1.9000902@ninjabadger.net> References: <20151124211644.Horde.lD99Cr_55xe-kQAREaXd1Q1@box1044.bluehost.com> <5654E4D1.9000902@ninjabadger.net> Message-ID: <5654FB98.20500@winterei.se> Tom, Could you expand further on this? On 11/25/2015 07:29 AM, Tom Hill wrote: > And in relation to Brocade: I'd feel very uncomfortable throwing any > *new* money at MLXe, CER or CES. Strategy for those families seems to > have fallen off of a cliff. From baldur.norddahl at gmail.com Wed Nov 25 00:34:28 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 25 Nov 2015 01:34:28 +0100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <20151124233647.E3D5B3D855A4@rock.dv.isc.org> References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> <5652D3F9.6030009@lanparty.ee> <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> <20151123202706.6A0A83D76305@rock.dv.isc.org> <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com> <20151123223954.A3DA13D775D5@rock.dv.isc.org> <42270.1448383626@turing-police.cc.vt.edu> <20151124233647.E3D5B3D855A4@rock.dv.isc.org> Message-ID: On 25 November 2015 at 00:36, Mark Andrews wrote: > Give PD is designed to allow you to have multiple delegation requests > from one router to the dhcp server (router) and manage them > independently. Just request prefixes as you need them. If the > dhcp server (router) doesn't have any available it just make a up > stream request. Ultimately this will get to the border router and > be fullfilled there flowing back through all the itermediate servers > and depending upon how they are configured setting up routes. > Alternatively the original requesting route injects a route for the > delegated prefix into the IRP. > > This isn't rocket science. Just use your @#!Q$# brains when you build > CPE routers. > > This isn't new. DHCP servers have got answers from upsteam DHCP > servers for various IPv4 DHCP options (e.g. DNS servers). PD isn't > conceptually different other than it is done on demand rather than > in advance. > > Mark > Too many details were left out. Without a RFC to guide implementations, you can have no expectations that a mix of CPE routers on your home network will behave in any particular way. DHCPv6-PD allows multiple PD requests. But did anyone actually implement that? I am not aware of any device that will hand out sub delegations on one interface, notice that it is out of address space and then go request more space from the upstream router (*). DHCPv6-PD allows size hints, but it is often ignored. Also there is no guidance for what prefix sizes you should ask for. Many CPEs will ask for /48. If you got a /48 you will give out that /48 and then not honor any further requests, because only one /48 per site is allowed. If you are an ISP that gives out /48 and your customers CPE asks for a /56 you will still ignore his size hint and give him /48. If a CPE device gets a size hint of /48 from a downstream CPE router, it will be forced to ignore that hint and give out - what? A /49 because that is the closest to a /48 that is possible, if you only got a /48 yourself? A /56 because that is half the available bits for prefixes? A /60 because who needs more? A /52 because why would you connect more than 16 directly connected downstream routers? Nothing because it asked for a /48 and you couldn't give it that, so the request should be ignored (the last option works really poorly because the DHCPv6 spec has no way to signal "please ask again for less space"). If we go back to the point I marked with (*) above, then think about when should you take a size hint seriously enough to go and request more space from the upstream server? Usually you wouldn't. You would just ignore his size hint and give him less space than asked for. Really it is a mess. We have too many options and therefore you will not see a good working system from multiple vendors in this space as is. I am aware of the homenet working group, which seems to have taken a different approach to solve the issues. Regards, Baldur From marka at isc.org Wed Nov 25 01:32:36 2015 From: marka at isc.org (Mark Andrews) Date: Wed, 25 Nov 2015 12:32:36 +1100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: Your message of "Wed, 25 Nov 2015 01:34:28 +0100." References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> <5652D3F9.6030009@lanparty.ee> <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> <20151123202706.6A0A83D76305@rock.dv.isc.org> <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com> <20151123223954.A3DA13D775D5@rock.dv.isc.org> <42270.1448383626@turing-police.cc.vt.edu> <20151124233647.E3D5B3D855A4@rock.dv.isc.org> Message-ID: <20151125013236.EC97A3D8710B@rock.dv.isc.org> In message , Baldur Norddahl writes: > On 25 November 2015 at 00:36, Mark Andrews wrote: > > > Give PD is designed to allow you to have multiple delegation requests > > from one router to the dhcp server (router) and manage them > > independently. Just request prefixes as you need them. If the > > dhcp server (router) doesn't have any available it just make a up > > stream request. Ultimately this will get to the border router and > > be fullfilled there flowing back through all the itermediate servers > > and depending upon how they are configured setting up routes. > > Alternatively the original requesting route injects a route for the > > delegated prefix into the IRP. > > > > This isn't rocket science. Just use your @#!Q$# brains when you build > > CPE routers. > > > > This isn't new. DHCP servers have got answers from upsteam DHCP > > servers for various IPv4 DHCP options (e.g. DNS servers). PD isn't > > conceptually different other than it is done on demand rather than > > in advance. > > > > Mark > > > > Too many details were left out. Without a RFC to guide implementations, you > can have no expectations that a mix of CPE routers on your home network > will behave in any particular way. Does any RFC state copy "DNS servers from upstream DHCP response"? (the answer is NO by the way). Not everything should require a RFC. > DHCPv6-PD allows multiple PD requests. But did anyone actually implement > that? I am not aware of any device that will hand out sub delegations on > one interface, notice that it is out of address space and then go request > more space from the upstream router (*). Then none of the CPE vendors are worth their salt as product suppliers. > DHCPv6-PD allows size hints, but it is often ignored. Also there is no > guidance for what prefix sizes you should ask for. Many CPEs will ask for > /48. If you got a /48 you will give out that /48 and then not honor any > further requests, because only one /48 per site is allowed. If you are an > ISP that gives out /48 and your customers CPE asks for a /56 you will still > ignore his size hint and give him /48. It's a hint for the amount of space you need. What else would you put in there other than that value. If you get more than you need then there is no problem. If you get less than you need then you have a problem. I've got a CPE with 3 internal interfaces. I would expect it would ask for a /62 (which wastes 1 /64) or /63 and a /64 or 3 x /64 if the /62 or /63 could not be met. It's not that hard to request what you need. If you even think about the issue for a couple of seconds which you did to compose this reply you would realise that asking for a /48 by default is stupid and doesn't meet the definition of the hint which is the amount of space you need. > If a CPE device gets a size hint of /48 from a downstream CPE router, it > will be forced to ignore that hint and give out - what? A /49 because that > is the closest to a /48 that is possible, if you only got a /48 yourself? A > /56 because that is half the available bits for prefixes? A /60 because who > needs more? A /52 because why would you connect more than 16 directly > connected downstream routers? Nothing because it asked for a /48 and you > couldn't give it that, so the request should be ignored (the last option > works really poorly because the DHCPv6 spec has no way to signal "please > ask again for less space"). Which demonstrates that with a little bit of thought *you* could work though the issue of making the hint be a /48. > If we go back to the point I marked with (*) above, then think about when > should you take a size hint seriously enough to go and request more space > from the upstream server? Usually you wouldn't. You would just ignore his > size hint and give him less space than asked for. No. You go and make a request from the upsteam. The worst they can do is deny it. > Really it is a mess. We have too many options and therefore you will not > see a good working system from multiple vendors in this space as is. > > I am aware of the homenet working group, which seems to have taken a > different approach to solve the issues. > > Regards, > > Baldur -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From baldur.norddahl at gmail.com Wed Nov 25 02:35:19 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 25 Nov 2015 03:35:19 +0100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <20151125013236.EC97A3D8710B@rock.dv.isc.org> References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> <5652D3F9.6030009@lanparty.ee> <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> <20151123202706.6A0A83D76305@rock.dv.isc.org> <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com> <20151123223954.A3DA13D775D5@rock.dv.isc.org> <42270.1448383626@turing-police.cc.vt.edu> <20151124233647.E3D5B3D855A4@rock.dv.isc.org> <20151125013236.EC97A3D8710B@rock.dv.isc.org> Message-ID: On 25 November 2015 at 02:32, Mark Andrews wrote: > It's a hint for the amount of space you need. What else would you > put in there other than that value. If you get more than you need > then there is no problem. If you get less than you need then you > have a problem. > > I've got a CPE with 3 internal interfaces. I would expect it would > ask for a /62 (which wastes 1 /64) or /63 and a /64 or 3 x /64 if > the /62 or /63 could not be met. It's not that hard to request > what you need. You might think that would be obvious, but exactly zero (0) commercial available CPEs has implemented it like that. THAT means that if you expect the community to do it like this, you do in fact need to write it in a RFC. > > If you even think about the issue for a couple of seconds which you > did to compose this reply you would realise that asking for a /48 > by default is stupid and doesn't meet the definition of the hint > which is the amount of space you need. > Where did you find a "definition of the hint"? The RFC only has two short sections about the size hint: "In a message sent by a requesting router to a delegating router, the values in the fields can be used to indicate the requesting router's preference for those values. The requesting router may send a value of zero to indicate no preference. A requesting router may set the IPv6 prefix field to zero and a given value in the prefix-length field to indicate a preference for the size of the prefix to be delegated." and "If the requesting router includes an IA_PD Prefix option in the IA_PD option in its Solicit message, the delegating router MAY choose to use the information in that option to select the prefix(es) or prefix size to be delegated to the requesting router." It might be stupid, but the majority of the implementers read the RFC without your insight. It is poorly worded, because there is no guidance. You can not expect everyone to figure it out by themselves, especially not if you want them to come to the same conclusion. In this case people did come to a conclusion, it was just not the one you wanted. That conclusion was something like this: Hmm what is my preference for prefix size? I read NANOG and the cool guys says a /48 is better than /56, so I think my preference should be /48. I will put in /48 in this field. The only other option anyone really considered was putting in zero. > If we go back to the point I marked with (*) above, then think about when > > should you take a size hint seriously enough to go and request more space > > from the upstream server? Usually you wouldn't. You would just ignore his > > size hint and give him less space than asked for. > > No. You go and make a request from the upsteam. The worst they > can do is deny it. > > That is overly complex and with nothing in a RFC, few to none would implement it. We do not like to spend time and money on features nobody else implements. a) receive a request (as a server), see that we have too little space to fulfill the size hint b) go to the upstream server (as a client) and ask for more space c) if we still have too little space, ignore the size hint and do some other unspecified other action d) step a-c are asynchronous (have to wait unspecified time from upstream server, before we can make our own reply). This could be a problem because a DHCP server would usually not be programmed in this way. Fact is just that the DHCPv6 client and the DHCPv6 server are usually two pieces of a CPE that do not work together. Might even be two pieces of software from different projects. Then it becomes very complex to get that kind of coordination between client and server. I am not saying that it is impossible to implement a sane system using the framework provided by DHCPv6-PD. But too much was left out. Companies are not going to fill in the blanks. It will not be done until there is consensus this is the right way to implement hierarchical CPEs in the home. Regards, Baldur From bobp at purdon.id.au Wed Nov 25 02:21:49 2015 From: bobp at purdon.id.au (Bob Purdon) Date: Wed, 25 Nov 2015 13:21:49 +1100 Subject: Rack Locks In-Reply-To: References: <707FECBBE7FEE241ABE4CAAF4025A0BE03984B46@corpmail.burlingtontelecom.com> Message-ID: <4f7e42bc-7846-4e6d-a26b-5592ebaae65b@getmailbird.com> So what did we do. I used to use a relay type system in 2007-10 in my previous data centre life. It?s pretty good but a bit ?industrial?. It?s also so 2007 (even 1990) and doesn?t scale well when you are trying to do 3,000 racks and 6,000 doors per facility. Part of the scaling issue was the door locks on that system were conventional solenoids, which from memory needed about 1A @ 12VDC to fire. ?If a customer had 30-40 racks (and a couple did in that facility), you'd need to potentially fire 60-80 doors, or need 60-80 amps available (I have a recollection we used a 12V SLA battery to ride out those peaks). ?Additionally, monitoring lock status would have needed separate wiring and separate inputs. ?Cabling was a star topology (each rack directly back to the controller). The TZ locks use a fraction of that power - from memory, only a few amps to do a pod of 30 or so racks. ?Firing a lock is measured in milliamps, not amps. ?The locks are controlled over RS485, so you get lock control and monitoring over a single cat-5. ?From memory the cable topology is technically hierarchical, but you could loosely consider it to be a bus. ?Overall, vastly superior to the 'industrial' style system. I looked at the APC electronic locking system, but the big issue is that some fool in product decided to remove radius authentication, allowing a decent independent command/control capability. At the time the available version of the product didn't deal with too many racks, which also meant a lot of under-floor power outlets to feed the controllers). ?I think they were coming up with a denser version, but I didn't see it. From marka at isc.org Wed Nov 25 05:23:33 2015 From: marka at isc.org (Mark Andrews) Date: Wed, 25 Nov 2015 16:23:33 +1100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: Your message of "Wed, 25 Nov 2015 03:35:19 +0100." References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> <5652D3F9.6030009@lanparty.ee> <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> <20151123202706.6A0A83D76305@rock.dv.isc.org> <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com> <20151123223954.A3DA13D775D5@rock.dv.isc.org> <42270.1448383626@turing-police.cc.vt.edu> <20151124233647.E3D5B3D855A4@rock.dv.isc.org> <20151125013236.EC97A3D8710B@rock.dv.isc.org> Message-ID: <20151125052333.621523D8CD49@rock.dv.isc.org> In message , Baldur Norddahl writes: > On 25 November 2015 at 02:32, Mark Andrews wrote: > > > It's a hint for the amount of space you need. What else would you > > put in there other than that value. If you get more than you need > > then there is no problem. If you get less than you need then you > > have a problem. > > > > I've got a CPE with 3 internal interfaces. I would expect it would > > ask for a /62 (which wastes 1 /64) or /63 and a /64 or 3 x /64 if > > the /62 or /63 could not be met. It's not that hard to request > > what you need. > > You might think that would be obvious, but exactly zero (0) commercial > available CPEs has implemented it like that. > > THAT means that if you expect the community to do it like this, you do in > fact need to write it in a RFC. Or you could write it as you think it is needed. > > If you even think about the issue for a couple of seconds which you > > did to compose this reply you would realise that asking for a /48 > > by default is stupid and doesn't meet the definition of the hint > > which is the amount of space you need. > > > > Where did you find a "definition of the hint"? > > The RFC only has two short sections about the size hint: > > "In a message sent by a requesting router to a delegating router, the > values in the fields can be used to indicate the requesting router's > preference for those values. The requesting router may send a value > of zero to indicate no preference. A requesting router may set the > IPv6 prefix field to zero and a given value in the prefix-length > field to indicate a preference for the size of the prefix to be > delegated." > > and > > "If the requesting router includes an IA_PD Prefix option in the IA_PD > option in its Solicit message, the delegating router MAY choose to > use the information in that option to select the prefix(es) or prefix > size to be delegated to the requesting router." > > It might be stupid, but the majority of the implementers read the RFC > without your insight. It is poorly worded, because there is no guidance. > You can not expect everyone to figure it out by themselves, especially not > if you want them to come to the same conclusion. In this case people did > come to a conclusion, it was just not the one you wanted. > That conclusion was something like this: Hmm what is my preference for > prefix size? I read NANOG and the cool guys says a /48 is better than /56, > so I think my preference should be /48. I will put in /48 in this field. > The only other option anyone really considered was putting in zero. The cool guys tell the ISP's to hand out /48s. They don't say request a /48. There is a difference. > > If we go back to the point I marked with (*) above, then think about when > > > > should you take a size hint seriously enough to go and request more space > > > from the upstream server? Usually you wouldn't. You would just ignore his > > > size hint and give him less space than asked for. > > > > No. You go and make a request from the upsteam. The worst they > > can do is deny it. > > > > > That is overly complex and with nothing in a RFC, few to none would > implement it. We do not like to spend time and money on features nobody > else implements. Well write a RFC and implement it. Thats what I do when I find a I find something is missing or a problem and should be common to multiple implementations. Its not hard to do. If you leave to someone else it doesn't get addressed. Negative caching is a example of this. (RFC 2308) The DLV record is a example of this. (RFC 5074) The default local zones is a example of this. (RFC 6303) The EDNS EXPIRE option is a example of this. (RFC 7314) The EDNS COOKIE option is a example of this. (in last call) draft-ietf-dnsop-rfc6598-rfc6303-02 is yet another example (in last call) draft-andrews-dns-no-response-issue-12 (dnsop call for adoption at the moment) + others Most of my developement work is with nameservers but I occasionally fiddle on the DHCP side. > a) receive a request (as a server), see that we have too little space to > fulfill the size hint > b) go to the upstream server (as a client) and ask for more space > c) if we still have too little space, ignore the size hint and do some > other unspecified other action > d) step a-c are asynchronous (have to wait unspecified time from upstream > server, before we can make our own reply). This could be a problem because > a DHCP server would usually not be programmed in this way. > > Fact is just that the DHCPv6 client and the DHCPv6 server are usually two > pieces of a CPE that do not work together. Might even be two pieces of > software from different projects. Then it becomes very complex to get that > kind of coordination between client and server. They are usually seperate for in some classes of devices and integrated in others. If you are designing a DHCP server for a ISP you want it to be seperate. If you designing a DHCP client for a PC it or tablet it is seperate. If you are designing for a router you do a integated server/client (which by the what is what lots of CPE routers have). > I am not saying that it is impossible to implement a sane system using the > framework provided by DHCPv6-PD. But too much was left out. Companies are > not going to fill in the blanks. It will not be done until there is > consensus this is the right way to implement hierarchical CPEs in the home. DHCPv6-PD described the client/server iteraction necessary to get a prefix delegated. There are lots of reasons to requests a delegation. You are a border router. You are a interior router. You are running VM's and need addresses for them. You want multiple addresses and DHCP IA only gives you one. I'm sure someone else will figure out some other use for DHCPv6-PD soon enough. Homenet is looking at plugging together routers in ad-hoc networks without administators. > Regards, > > Baldur -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From paul at paulstewart.org Wed Nov 25 08:54:30 2015 From: paul at paulstewart.org (Paul Stewart) Date: Wed, 25 Nov 2015 03:54:30 -0500 Subject: SevOne Monitoring Message-ID: <00be01d1275e$e6400760$b2c01620$@paulstewart.org> Hey folks. Looking for feedback from actual customers on SevOne for network monitoring . anyone using them and willing to share thoughts online/offline? They have an appealing system for network monitoring and considering it as a replacement to Solarwinds. Cheers, Paul From jfmezei_nanog at vaxination.ca Wed Nov 25 09:40:00 2015 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 25 Nov 2015 04:40:00 -0500 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com> Message-ID: <565581F0.4080505@vaxination.ca> On 2015-11-23 17:12, Owen DeLong wrote: > Except there?s no revenue share here. According to T-Mobile, the streaming partners > aren?t paying anything to T-Mo and T-Mo isn?t paying them. In Canada, Vid?otron has begun a similar scheme for streaming music. It is currently at the CRTC. They also claimed that the setting up of the scheme with a music streaming partner involved no money exchange. They provided a contract. This contract was 1 page. yes, large incumbent wireless/cable carrier with large legal departments signs a 1 page contract.... This page dealth with which IP addresses from the music streaming service would be zero rated by the carrier. Yet, their advertising uses logos from the handful of music services they have accepted. Permission to use such logos was not included in that 1 page contract which means that there would be a separate contract, not related to zero rating which would deal with co-marketing and whatever else. From jfmezei_nanog at vaxination.ca Wed Nov 25 09:45:53 2015 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 25 Nov 2015 04:45:53 -0500 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com> Message-ID: <56558351.4050704@vaxination.ca> On 2015-11-23 17:26, Owen DeLong wrote: > Sure, but I really don?t think there?s an exchange per se in this case, given that T-Mo > is (at least apparently) willing to accommodate any streaming provider that wants to > participate so long as they are willing to conform to a fairly basic set of technical criteria. Vid?otron also stated on day of annoucement that they were opened to any/all music streaming services and not selective. But fine print is important here because they do "vet" music streaming services and the carrier wants to ensure they are "legal" in canada (music rights), are not a radio station (aka: onwer by competitor telco who owns most radio statiosn in markets where Vid?otron operates) and a whole buch other conditions. There is PR to make "zero rating" look good, and then there is fine print thats hows the true intentions. In the case of Vid?otron, the zero-rated music is available only on their highest priced services and is a marketing scheme to increase AREPU by inciting customers to upgrade to more expensive service. From baldur.norddahl at gmail.com Wed Nov 25 10:17:41 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 25 Nov 2015 11:17:41 +0100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <20151125052333.621523D8CD49@rock.dv.isc.org> References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> <5652D3F9.6030009@lanparty.ee> <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> <20151123202706.6A0A83D76305@rock.dv.isc.org> <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com> <20151123223954.A3DA13D775D5@rock.dv.isc.org> <42270.1448383626@turing-police.cc.vt.edu> <20151124233647.E3D5B3D855A4@rock.dv.isc.org> <20151125013236.EC97A3D8710B@rock.dv.isc.org> <20151125052333.621523D8CD49@rock.dv.isc.org> Message-ID: On 25 November 2015 at 06:23, Mark Andrews wrote: > > You might think that would be obvious, but exactly zero (0) commercial > > available CPEs has implemented it like that. > > > > THAT means that if you expect the community to do it like this, you do in > > fact need to write it in a RFC. > > Or you could write it as you think it is needed. > > The homenet working group just published a RFC with a different solution. The size hint is garbage today because every client will put garbage in it and most servers will ignore it (including isc-dhcp IIRC). And likely it will stay that way forever. The homenet solution is different, but it reduces the need for a size hint. Regards, Baldur From joesox at gmail.com Wed Nov 25 16:41:55 2015 From: joesox at gmail.com (JoeSox) Date: Wed, 25 Nov 2015 08:41:55 -0800 Subject: Bluehost.com Message-ID: Anyone have the scope on the outage for Bluehost? https://twitter.com/search?q=%23bluehostdown&src=tyah Cannot even move my DNS until its restored. :( I suggest moving the status page to outside your network as well. https://www.bluehost.com/hosting/serverstatus -- Later, Joe From bjorn at mork.no Wed Nov 25 16:57:11 2015 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Wed, 25 Nov 2015 17:57:11 +0100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <20151124233647.E3D5B3D855A4@rock.dv.isc.org> (Mark Andrews's message of "Wed, 25 Nov 2015 10:36:47 +1100") References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> <5652D3F9.6030009@lanparty.ee> <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> <20151123202706.6A0A83D76305@rock.dv.isc.org> <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com> <20151123223954.A3DA13D775D5@rock.dv.isc.org> <42270.1448383626@turing-police.cc.vt.edu> <20151124233647.E3D5B3D855A4@rock.dv.isc.org> Message-ID: <87io4qvwyg.fsf@nemi.mork.no> Mark Andrews writes: > This isn't rocket science. Just use your @#!Q$# brains when you build > CPE routers. Right... Still waiting for the first CPE built like that :) Bj?rn From SNaslund at medline.com Wed Nov 25 17:04:53 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 25 Nov 2015 17:04:53 +0000 Subject: SevOne Monitoring In-Reply-To: <00be01d1275e$e6400760$b2c01620$@paulstewart.org> References: <00be01d1275e$e6400760$b2c01620$@paulstewart.org> Message-ID: <9578293AE169674F9A048B2BC9A081B401C7B2FE1D@MUNPRDMBXA1.medline.com> I looked at SevOne and liked the product a lot. One thing we found was that the pricing model escalates pretty rapidly because they count every OBJECT you monitor, not every device. So if I am looking at Bytes In, Bytes Out, Errors In, etc on a single interface those are all counted as a separate OBJECT against your license count. You really have to be more selective about what you want to see which to me is really inconvenient because often you don't know what SNMP object you want to look at until a problem surfaces. One of the strengths I really liked was the trending capability that helps you predict capacity issues before you hit them. Summary: Good product, real expensive in wide deployment. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Paul Stewart Sent: Wednesday, November 25, 2015 2:55 AM To: 'NANOG' Subject: SevOne Monitoring Hey folks. Looking for feedback from actual customers on SevOne for network monitoring . anyone using them and willing to share thoughts online/offline? They have an appealing system for network monitoring and considering it as a replacement to Solarwinds. Cheers, Paul From bruns at 2mbit.com Wed Nov 25 17:28:01 2015 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 25 Nov 2015 10:28:01 -0700 Subject: Bluehost.com In-Reply-To: References: Message-ID: <5655EFA1.4000004@2mbit.com> On 11/25/15 9:41 AM, JoeSox wrote: > Anyone have the scope on the outage for Bluehost? > https://twitter.com/search?q=%23bluehostdown&src=tyah > > Cannot even move my DNS until its restored. :( > I suggest moving the status page to outside your network as well. > https://www.bluehost.com/hosting/serverstatus > I am in the last stages of getting rid of BlueHost for one of my clients. Go figure this would happen _today_ at the exact same time I'm getting the last bit of data off so I can cancel the account. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From shortdudey123 at gmail.com Wed Nov 25 17:48:40 2015 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 25 Nov 2015 09:48:40 -0800 Subject: Bluehost.com In-Reply-To: <5655EFA1.4000004@2mbit.com> References: <5655EFA1.4000004@2mbit.com> Message-ID: Their site and my site work US west coast -Grant On Wed, Nov 25, 2015 at 9:28 AM, Brielle Bruns wrote: > On 11/25/15 9:41 AM, JoeSox wrote: > >> Anyone have the scope on the outage for Bluehost? >> https://twitter.com/search?q=%23bluehostdown&src=tyah >> >> Cannot even move my DNS until its restored. :( >> I suggest moving the status page to outside your network as well. >> https://www.bluehost.com/hosting/serverstatus >> >> > I am in the last stages of getting rid of BlueHost for one of my clients. > Go figure this would happen _today_ at the exact same time I'm getting the > last bit of data off so I can cancel the account. > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > From bortzmeyer at nic.fr Wed Nov 25 18:04:40 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 25 Nov 2015 19:04:40 +0100 Subject: Bluehost.com In-Reply-To: References: Message-ID: <20151125180440.GA20559@nic.fr> On Wed, Nov 25, 2015 at 08:41:55AM -0800, JoeSox wrote a message of 9 lines which said: > Anyone have the scope on the outage for Bluehost? > https://twitter.com/search?q=%23bluehostdown&src=tyah The two name servers ns1.bluehost.com and ns2.bluehost.com are awfully slow to respond: % check-soa -i picturemotion.com ns1.bluehost.com. 74.220.195.31: OK: 2012092007 (1382 ms) ns2.bluehost.com. 69.89.16.4: OK: 2012092007 (1388 ms) As a result, most clients timeout. May be a DoS against the name servers? bluehost.com itself is DNS-hosted on a completely different architecture. So it works fine. But the nginx Web site replies 502 Gateway timeout, probably overloaded by all the clients trying to get informed. The Twitter accounts of Bluehost do not distribute any useful information. From joesox at gmail.com Wed Nov 25 19:21:52 2015 From: joesox at gmail.com (JoeSox) Date: Wed, 25 Nov 2015 11:21:52 -0800 Subject: Bluehost.com In-Reply-To: <20151125180440.GA20559@nic.fr> References: <20151125180440.GA20559@nic.fr> Message-ID: I just waited 160 minutes for a tech call and the Bluehost tech told me he was able to confirm that it wasn't malicious activity that took down the datacenter but rather it was caused by a "datacenter issue". So my first thought is someone didn't design the topology correctly or something. Some of our emails are coming thru but Google DNS still lost all of our DNS zones which are hosted by Bluehost. At least the #bluehostdown is fun to read :/ -- Later, Joe On Wed, Nov 25, 2015 at 10:04 AM, Stephane Bortzmeyer wrote: > On Wed, Nov 25, 2015 at 08:41:55AM -0800, > JoeSox wrote > a message of 9 lines which said: > > > Anyone have the scope on the outage for Bluehost? > > https://twitter.com/search?q=%23bluehostdown&src=tyah > > The two name servers ns1.bluehost.com and ns2.bluehost.com are awfully > slow to respond: > > % check-soa -i picturemotion.com > ns1.bluehost.com. > 74.220.195.31: OK: 2012092007 (1382 ms) > ns2.bluehost.com. > 69.89.16.4: OK: 2012092007 (1388 ms) > > As a result, most clients timeout. > > May be a DoS against the name servers? > > bluehost.com itself is DNS-hosted on a completely different > architecture. So it works fine. But the nginx Web site replies 502 > Gateway timeout, probably overloaded by all the clients trying to get > informed. > > The Twitter accounts of Bluehost do not distribute any useful > information. > From joesox at gmail.com Wed Nov 25 19:22:44 2015 From: joesox at gmail.com (JoeSox) Date: Wed, 25 Nov 2015 11:22:44 -0800 Subject: Bluehost.com In-Reply-To: References: <20151125180440.GA20559@nic.fr> Message-ID: Forgot to mention that their ETA was by end of today. :facepalm: -- Later, Joe On Wed, Nov 25, 2015 at 11:21 AM, JoeSox wrote: > I just waited 160 minutes for a tech call and the Bluehost tech told me he > was able to confirm that it wasn't malicious activity that took down the > datacenter but rather it was caused by a "datacenter issue". > So my first thought is someone didn't design the topology correctly or > something. > Some of our emails are coming thru but Google DNS still lost all of our > DNS zones which are hosted by Bluehost. > At least the #bluehostdown is fun to read :/ > -- > Later, Joe > > On Wed, Nov 25, 2015 at 10:04 AM, Stephane Bortzmeyer > wrote: > >> On Wed, Nov 25, 2015 at 08:41:55AM -0800, >> JoeSox wrote >> a message of 9 lines which said: >> >> > Anyone have the scope on the outage for Bluehost? >> > https://twitter.com/search?q=%23bluehostdown&src=tyah >> >> The two name servers ns1.bluehost.com and ns2.bluehost.com are awfully >> slow to respond: >> >> % check-soa -i picturemotion.com >> ns1.bluehost.com. >> 74.220.195.31: OK: 2012092007 (1382 ms) >> ns2.bluehost.com. >> 69.89.16.4: OK: 2012092007 (1388 ms) >> >> As a result, most clients timeout. >> >> May be a DoS against the name servers? >> >> bluehost.com itself is DNS-hosted on a completely different >> architecture. So it works fine. But the nginx Web site replies 502 >> Gateway timeout, probably overloaded by all the clients trying to get >> informed. >> >> The Twitter accounts of Bluehost do not distribute any useful >> information. >> > > From trelane at trelane.net Wed Nov 25 19:24:05 2015 From: trelane at trelane.net (Andrew Kirch) Date: Wed, 25 Nov 2015 14:24:05 -0500 Subject: Bluehost.com In-Reply-To: References: <20151125180440.GA20559@nic.fr> Message-ID: remember folks, redundancy is the savior of all f***ups. :) On Wed, Nov 25, 2015 at 2:21 PM, JoeSox wrote: > I just waited 160 minutes for a tech call and the Bluehost tech told me he > was able to confirm that it wasn't malicious activity that took down the > datacenter but rather it was caused by a "datacenter issue". > So my first thought is someone didn't design the topology correctly or > something. > Some of our emails are coming thru but Google DNS still lost all of our DNS > zones which are hosted by Bluehost. > At least the #bluehostdown is fun to read :/ > -- > Later, Joe > > On Wed, Nov 25, 2015 at 10:04 AM, Stephane Bortzmeyer > wrote: > > > On Wed, Nov 25, 2015 at 08:41:55AM -0800, > > JoeSox wrote > > a message of 9 lines which said: > > > > > Anyone have the scope on the outage for Bluehost? > > > https://twitter.com/search?q=%23bluehostdown&src=tyah > > > > The two name servers ns1.bluehost.com and ns2.bluehost.com are awfully > > slow to respond: > > > > % check-soa -i picturemotion.com > > ns1.bluehost.com. > > 74.220.195.31: OK: 2012092007 (1382 ms) > > ns2.bluehost.com. > > 69.89.16.4: OK: 2012092007 (1388 ms) > > > > As a result, most clients timeout. > > > > May be a DoS against the name servers? > > > > bluehost.com itself is DNS-hosted on a completely different > > architecture. So it works fine. But the nginx Web site replies 502 > > Gateway timeout, probably overloaded by all the clients trying to get > > informed. > > > > The Twitter accounts of Bluehost do not distribute any useful > > information. > > > From bob at FiberInternetCenter.com Wed Nov 25 20:27:28 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Wed, 25 Nov 2015 12:27:28 -0800 Subject: Bluehost.com In-Reply-To: References: <20151125180440.GA20559@nic.fr> Message-ID: <6f661213d9ce49dbee4721ab2423140a.squirrel@66.201.44.180> Gee, for $3.49 for a website hosting per month , it's a real bargain. While the network person inside me says, Wow that's a long outage. The other part of me is really wondering what one thinks they can really expect from a company that hosts a website for just $3.49 ? Such a bargain at less than 1/2 the price of a single hot dog at a baseball stadium per month. That price point alone tells you about the setup and what you are agreeing too and who it's built for. Goes along with the ol' saying, "you get what you pay for." If they are down for 10 hours a month out of the average 720 hours in a month - thats a tiny percentage 1-2 of the time it's unavailable - in service terms of dollars it's roughly a nickel they credit each customer. Do I need more coffee or is my math wrong about a nickel for 10 hours of website hosing ? However, maybe that is all many companies /sites really need. In which case, it should be easy enough to build in backup yourself using two cheap hosing providers and flip between them when the need arises. Or pick a provider that manages their routing well and works with you quickly, but, you'll have to pay more for that. Yep, the math spells it out - "you get what you pay for." Thank You Bob Evans CTO > remember folks, redundancy is the savior of all f***ups. > > :) > > On Wed, Nov 25, 2015 at 2:21 PM, JoeSox wrote: > >> I just waited 160 minutes for a tech call and the Bluehost tech told me >> he >> was able to confirm that it wasn't malicious activity that took down the >> datacenter but rather it was caused by a "datacenter issue". >> So my first thought is someone didn't design the topology correctly or >> something. >> Some of our emails are coming thru but Google DNS still lost all of our >> DNS >> zones which are hosted by Bluehost. >> At least the #bluehostdown is fun to read :/ >> -- >> Later, Joe >> >> On Wed, Nov 25, 2015 at 10:04 AM, Stephane Bortzmeyer >> >> wrote: >> >> > On Wed, Nov 25, 2015 at 08:41:55AM -0800, >> > JoeSox wrote >> > a message of 9 lines which said: >> > >> > > Anyone have the scope on the outage for Bluehost? >> > > https://twitter.com/search?q=%23bluehostdown&src=tyah >> > >> > The two name servers ns1.bluehost.com and ns2.bluehost.com are awfully >> > slow to respond: >> > >> > % check-soa -i picturemotion.com >> > ns1.bluehost.com. >> > 74.220.195.31: OK: 2012092007 (1382 ms) >> > ns2.bluehost.com. >> > 69.89.16.4: OK: 2012092007 (1388 ms) >> > >> > As a result, most clients timeout. >> > >> > May be a DoS against the name servers? >> > >> > bluehost.com itself is DNS-hosted on a completely different >> > architecture. So it works fine. But the nginx Web site replies 502 >> > Gateway timeout, probably overloaded by all the clients trying to get >> > informed. >> > >> > The Twitter accounts of Bluehost do not distribute any useful >> > information. >> > >> > From dcorbe at hammerfiber.com Wed Nov 25 21:27:49 2015 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Wed, 25 Nov 2015 16:27:49 -0500 Subject: Third Party NOC services Message-ID: Can anyone recommend some good third parties for NOC services? I don?t necessarily need something on the scope of companies like iNOC where they charge 20 bucks a device because I?ve got my own monitoring system. What I need are bodies to watch my monitors and react to problems. I also need a place to forward a toll free phone number for first level incident response. From dovid at telecurve.com Wed Nov 25 21:37:10 2015 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 25 Nov 2015 16:37:10 -0500 Subject: Third Party NOC services In-Reply-To: References: Message-ID: I am very happy with amoebanetworks.com On Wed, Nov 25, 2015 at 4:27 PM, Daniel Corbe wrote: > Can anyone recommend some good third parties for NOC services? > > I don?t necessarily need something on the scope of companies like iNOC > where they charge 20 bucks a device because I?ve got my own monitoring > system. What I need are bodies to watch my monitors and react to > problems. I also need a place to forward a toll free phone number for > first level incident response. > > > From mpalmer at hezmatt.org Wed Nov 25 23:06:30 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Thu, 26 Nov 2015 10:06:30 +1100 Subject: Bluehost.com In-Reply-To: References: <20151125180440.GA20559@nic.fr> Message-ID: <20151125230630.GJ4973@hezmatt.org> On Wed, Nov 25, 2015 at 02:24:05PM -0500, Andrew Kirch wrote: > remember folks, redundancy is the savior of all f***ups. Except for the fuckups that the redundancy *caused*... - Matt From joesox at gmail.com Wed Nov 25 23:23:17 2015 From: joesox at gmail.com (JoeSox) Date: Wed, 25 Nov 2015 15:23:17 -0800 Subject: Bluehost.com In-Reply-To: <6f661213d9ce49dbee4721ab2423140a.squirrel@66.201.44.180> References: <20151125180440.GA20559@nic.fr> <6f661213d9ce49dbee4721ab2423140a.squirrel@66.201.44.180> Message-ID: Walmart has cheap prices so "you get what you pay for."?? Hasty generalization but I can't disagree 100% with your opinion on this one. I am learning about the non-profit world of IT and the challenges are all around me. :) -- Later, Joe On Wed, Nov 25, 2015 at 12:27 PM, Bob Evans wrote: > > Gee, for $3.49 for a website hosting per month , it's a real bargain. > While the network person inside me says, Wow that's a long outage. The > other part of me is really wondering what one thinks they can really > expect from a company that hosts a website for just $3.49 ? Such a > bargain at less than 1/2 the price of a single hot dog at a baseball > stadium per month. That price point alone tells you about the setup and > what you are agreeing too and who it's built for. Goes along with the ol' > saying, "you get what you pay for." > > If they are down for 10 hours a month out of the average 720 hours in a > month - thats a tiny percentage 1-2 of the time it's unavailable - in > service terms of dollars it's roughly a nickel they credit each customer. > Do I need more coffee or is my math wrong about a nickel for 10 hours of > website hosing ? > > However, maybe that is all many companies /sites really need. In which > case, it should be easy enough to build in backup yourself using two cheap > hosing providers and flip between them when the need arises. Or pick a > provider that manages their routing well and works with you quickly, but, > you'll have to pay more for that. > > Yep, the math spells it out - "you get what you pay for." > > Thank You > Bob Evans > CTO > > > > > > remember folks, redundancy is the savior of all f***ups. > > > > :) > > > > On Wed, Nov 25, 2015 at 2:21 PM, JoeSox wrote: > > > >> I just waited 160 minutes for a tech call and the Bluehost tech told me > >> he > >> was able to confirm that it wasn't malicious activity that took down the > >> datacenter but rather it was caused by a "datacenter issue". > >> So my first thought is someone didn't design the topology correctly or > >> something. > >> Some of our emails are coming thru but Google DNS still lost all of our > >> DNS > >> zones which are hosted by Bluehost. > >> At least the #bluehostdown is fun to read :/ > >> -- > >> Later, Joe > >> > >> On Wed, Nov 25, 2015 at 10:04 AM, Stephane Bortzmeyer > >> > >> wrote: > >> > >> > On Wed, Nov 25, 2015 at 08:41:55AM -0800, > >> > JoeSox wrote > >> > a message of 9 lines which said: > >> > > >> > > Anyone have the scope on the outage for Bluehost? > >> > > https://twitter.com/search?q=%23bluehostdown&src=tyah > >> > > >> > The two name servers ns1.bluehost.com and ns2.bluehost.com are > awfully > >> > slow to respond: > >> > > >> > % check-soa -i picturemotion.com > >> > ns1.bluehost.com. > >> > 74.220.195.31: OK: 2012092007 (1382 ms) > >> > ns2.bluehost.com. > >> > 69.89.16.4: OK: 2012092007 (1388 ms) > >> > > >> > As a result, most clients timeout. > >> > > >> > May be a DoS against the name servers? > >> > > >> > bluehost.com itself is DNS-hosted on a completely different > >> > architecture. So it works fine. But the nginx Web site replies 502 > >> > Gateway timeout, probably overloaded by all the clients trying to get > >> > informed. > >> > > >> > The Twitter accounts of Bluehost do not distribute any useful > >> > information. > >> > > >> > > > > > From Valdis.Kletnieks at vt.edu Wed Nov 25 23:24:58 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 25 Nov 2015 18:24:58 -0500 Subject: Bluehost.com In-Reply-To: <20151125230630.GJ4973@hezmatt.org> References: <20151125180440.GA20559@nic.fr> <20151125230630.GJ4973@hezmatt.org> Message-ID: <86778.1448493898@turing-police.cc.vt.edu> On Thu, 26 Nov 2015 10:06:30 +1100, Matt Palmer said: > Except for the fuckups that the redundancy *caused*... You can't have split-brain failures if there isn't enough brain to split? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From James at mor-pah.net Wed Nov 25 20:59:36 2015 From: James at mor-pah.net (James Greig) Date: Wed, 25 Nov 2015 20:59:36 +0000 Subject: SevOne Monitoring In-Reply-To: <00be01d1275e$e6400760$b2c01620$@paulstewart.org> References: <00be01d1275e$e6400760$b2c01620$@paulstewart.org> Message-ID: <4C69C9B1-B80F-44D0-B30F-FAF49757579A@mor-pah.net> Depending on what you're after observium might be worth looking into. I run solarwinds, paessler and observium but neither are as clear and as useful for monitoring network as observium ( My opinion only of course ) Kind regards James Greig > On 25 Nov 2015, at 08:54, Paul Stewart wrote: > > Hey folks. > > > > Looking for feedback from actual customers on SevOne for network monitoring > . anyone using them and willing to share thoughts online/offline? > > > > They have an appealing system for network monitoring and considering it as a > replacement to Solarwinds. > > > > Cheers, > > Paul > > > > > From ml at knight-networks.com Wed Nov 25 21:30:12 2015 From: ml at knight-networks.com (Brian Knight) Date: Wed, 25 Nov 2015 15:30:12 -0600 Subject: DHCPv6 PD & Routing Questions In-Reply-To: References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> <5652D3F9.6030009@lanparty.ee> <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> <20151123202706.6A0A83D76305@rock.dv.isc.org> <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com> <20151123223954.A3DA13D775D5@rock.dv.isc.org> <42270.1448383626@turing-police.cc.vt.edu> <20151124233647.E3D5B3D855A4@rock.dv.isc.org> Message-ID: On Tue, Nov 24, 2015 at 6:34 PM, Baldur Norddahl wrote: > > DHCPv6-PD allows multiple PD requests. But did anyone actually implement > that? I am not aware of any device that will hand out sub delegations on > one interface, notice that it is out of address space and then go request > more space from the upstream router (*). > > DHCPv6-PD allows size hints, but it is often ignored. Also there is no > guidance for what prefix sizes you should ask for. Many CPEs will ask for > /48. If you got a /48 you will give out that /48 and then not honor any > further requests, because only one /48 per site is allowed. If you are an > ISP that gives out /48 and your customers CPE asks for a /56 you will still > ignore his size hint and give him /48. Or, worse, the ISP's DHCPv6 server honors the new request and issues the larger prefix, but refuses to route it. Ran into that myself when I replaced my home CPE router, and changed the prefix hint to ask for a /60 block (expanded from /64) at the same time. That made for a frustrating few days without IPv6 service, waiting for my original delegation to expire. (Tech support, of course, had no clue and blamed my router.) In retrospect I should have perhaps had my original CPE generate a DHCP release message for that prefix before disconnecting it. But I won't be the last person to fail to generate that. -Brian From keith at kouzmanoff.com Wed Nov 25 22:00:16 2015 From: keith at kouzmanoff.com (Keith Kouzmanoff) Date: Wed, 25 Nov 2015 16:00:16 -0600 Subject: Bluehost.com In-Reply-To: <6f661213d9ce49dbee4721ab2423140a.squirrel@66.201.44.180> References: <20151125180440.GA20559@nic.fr> <6f661213d9ce49dbee4721ab2423140a.squirrel@66.201.44.180> Message-ID: <56562F70.2080907@kouzmanoff.com> From mike.lyon at gmail.com Wed Nov 25 23:49:42 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 25 Nov 2015 15:49:42 -0800 Subject: SevOne Monitoring In-Reply-To: <4C69C9B1-B80F-44D0-B30F-FAF49757579A@mor-pah.net> References: <00be01d1275e$e6400760$b2c01620$@paulstewart.org> <4C69C9B1-B80F-44D0-B30F-FAF49757579A@mor-pah.net> Message-ID: Can Observium alert on SNMP traps? I seem to remember that it couldn't do that... On Wed, Nov 25, 2015 at 12:59 PM, James Greig wrote: > Depending on what you're after observium might be worth looking into. I > run solarwinds, paessler and observium but neither are as clear and as > useful for monitoring network as observium ( My opinion only of course ) > > Kind regards > > James Greig > > > On 25 Nov 2015, at 08:54, Paul Stewart wrote: > > > > Hey folks. > > > > > > > > Looking for feedback from actual customers on SevOne for network > monitoring > > . anyone using them and willing to share thoughts online/offline? > > > > > > > > They have an appealing system for network monitoring and considering it > as a > > replacement to Solarwinds. > > > > > > > > Cheers, > > > > Paul > > > > > > > > > > > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From marka at isc.org Wed Nov 25 23:59:50 2015 From: marka at isc.org (Mark Andrews) Date: Thu, 26 Nov 2015 10:59:50 +1100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: Your message of "Wed, 25 Nov 2015 15:30:12 -0600." References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> <5652D3F9.6030009@lanparty.ee> <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> <20151123202706.6A0A83D76305@rock.dv.isc.org> <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com> <20151123223954.A3DA13D775D5@rock.dv.isc.org> <42270.1448383626@turing-police.cc.vt.edu> <20151124233647.E3D5B3D855A4@rock.dv.isc.org> Message-ID: <20151125235950.6E5293D93209@rock.dv.isc.org> In message , Brian Knight writes: > On Tue, Nov 24, 2015 at 6:34 PM, Baldur Norddahl > wrote: > > > > DHCPv6-PD allows multiple PD requests. But did anyone actually implement > > that? I am not aware of any device that will hand out sub delegations on > > one interface, notice that it is out of address space and then go request > > more space from the upstream router (*). > > > > DHCPv6-PD allows size hints, but it is often ignored. Also there is no > > guidance for what prefix sizes you should ask for. Many CPEs will ask for > > /48. If you got a /48 you will give out that /48 and then not honor any > > further requests, because only one /48 per site is allowed. If you are an > > ISP that gives out /48 and your customers CPE asks for a /56 you will still > > ignore his size hint and give him /48. > > Or, worse, the ISP's DHCPv6 server honors the new request and issues > the larger prefix, but refuses to route it. Ran into that myself when > I replaced my home CPE router, and changed the prefix hint to ask for > a /60 block (expanded from /64) at the same time. That made for a > frustrating few days without IPv6 service, waiting for my original > delegation to expire. (Tech support, of course, had no clue and > blamed my router.) > > In retrospect I should have perhaps had my original CPE generate a > DHCP release message for that prefix before disconnecting it. But I > won't be the last person to fail to generate that. > > -Brian Well the requesting router could announce the route. ISC's client has hooks that allow this to be done. That is, after all, how routing is designed to work. The DHCP server usually is sitting in a data center on the other side of the country with zero ability to inject approptiate routes. The DHCP relay could also have injected routes but that is a second class solution. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bob at FiberInternetCenter.com Thu Nov 26 00:00:37 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Wed, 25 Nov 2015 16:00:37 -0800 Subject: Bluehost.com In-Reply-To: References: <20151125180440.GA20559@nic.fr> <6f661213d9ce49dbee4721ab2423140a.squirrel@66.201.44.180> Message-ID: <62b3e90c9574776b8a43974eb72f3cd8.squirrel@66.201.44.180> Yes, I agree with you Joe - a hasty generalization, as "you get what you pay for" doesn't really apply to as many goods in the same way it does to almost all services. However, a $3.49 web site service should have be a good first clue. Thank You Bob Evans CTO > Walmart has cheap prices so "you get what you pay for."?? > Hasty generalization but I can't disagree 100% with your opinion on this > one. > I am learning about the non-profit world of IT and the challenges are all > around me. :) > > -- > Later, Joe > > On Wed, Nov 25, 2015 at 12:27 PM, Bob Evans > wrote: > >> >> Gee, for $3.49 for a website hosting per month , it's a real bargain. >> While the network person inside me says, Wow that's a long outage. The >> other part of me is really wondering what one thinks they can really >> expect from a company that hosts a website for just $3.49 ? Such a >> bargain at less than 1/2 the price of a single hot dog at a baseball >> stadium per month. That price point alone tells you about the setup and >> what you are agreeing too and who it's built for. Goes along with the >> ol' >> saying, "you get what you pay for." >> >> If they are down for 10 hours a month out of the average 720 hours in a >> month - thats a tiny percentage 1-2 of the time it's unavailable - in >> service terms of dollars it's roughly a nickel they credit each >> customer. >> Do I need more coffee or is my math wrong about a nickel for 10 hours of >> website hosing ? >> >> However, maybe that is all many companies /sites really need. In which >> case, it should be easy enough to build in backup yourself using two >> cheap >> hosing providers and flip between them when the need arises. Or pick a >> provider that manages their routing well and works with you quickly, >> but, >> you'll have to pay more for that. >> >> Yep, the math spells it out - "you get what you pay for." >> >> Thank You >> Bob Evans >> CTO >> >> >> >> >> > remember folks, redundancy is the savior of all f***ups. >> > >> > :) >> > >> > On Wed, Nov 25, 2015 at 2:21 PM, JoeSox wrote: >> > >> >> I just waited 160 minutes for a tech call and the Bluehost tech told >> me >> >> he >> >> was able to confirm that it wasn't malicious activity that took down >> the >> >> datacenter but rather it was caused by a "datacenter issue". >> >> So my first thought is someone didn't design the topology correctly >> or >> >> something. >> >> Some of our emails are coming thru but Google DNS still lost all of >> our >> >> DNS >> >> zones which are hosted by Bluehost. >> >> At least the #bluehostdown is fun to read :/ >> >> -- >> >> Later, Joe >> >> >> >> On Wed, Nov 25, 2015 at 10:04 AM, Stephane Bortzmeyer >> >> >> >> wrote: >> >> >> >> > On Wed, Nov 25, 2015 at 08:41:55AM -0800, >> >> > JoeSox wrote >> >> > a message of 9 lines which said: >> >> > >> >> > > Anyone have the scope on the outage for Bluehost? >> >> > > https://twitter.com/search?q=%23bluehostdown&src=tyah >> >> > >> >> > The two name servers ns1.bluehost.com and ns2.bluehost.com are >> awfully >> >> > slow to respond: >> >> > >> >> > % check-soa -i picturemotion.com >> >> > ns1.bluehost.com. >> >> > 74.220.195.31: OK: 2012092007 (1382 ms) >> >> > ns2.bluehost.com. >> >> > 69.89.16.4: OK: 2012092007 (1388 ms) >> >> > >> >> > As a result, most clients timeout. >> >> > >> >> > May be a DoS against the name servers? >> >> > >> >> > bluehost.com itself is DNS-hosted on a completely different >> >> > architecture. So it works fine. But the nginx Web site replies 502 >> >> > Gateway timeout, probably overloaded by all the clients trying to >> get >> >> > informed. >> >> > >> >> > The Twitter accounts of Bluehost do not distribute any useful >> >> > information. >> >> > >> >> >> > >> >> >> > From James at mor-pah.net Thu Nov 26 00:03:21 2015 From: James at mor-pah.net (James Greig) Date: Thu, 26 Nov 2015 00:03:21 +0000 Subject: SevOne Monitoring In-Reply-To: References: <00be01d1275e$e6400760$b2c01620$@paulstewart.org> <4C69C9B1-B80F-44D0-B30F-FAF49757579A@mor-pah.net> Message-ID: <6CC1E8BF-3C27-4EAF-A589-98CC89DE2620@mor-pah.net> No, as far as I know that's work in progress at the moment. The alert system works well for anything polled though but depends how often you're polling James Greig > On 25 Nov 2015, at 23:49, Mike Lyon wrote: > > Can Observium alert on SNMP traps? I seem to remember that it couldn't do that... > >> On Wed, Nov 25, 2015 at 12:59 PM, James Greig wrote: >> Depending on what you're after observium might be worth looking into. I run solarwinds, paessler and observium but neither are as clear and as useful for monitoring network as observium ( My opinion only of course ) >> >> Kind regards >> >> James Greig >> >> > On 25 Nov 2015, at 08:54, Paul Stewart wrote: >> > >> > Hey folks. >> > >> > >> > >> > Looking for feedback from actual customers on SevOne for network monitoring >> > . anyone using them and willing to share thoughts online/offline? >> > >> > >> > >> > They have an appealing system for network monitoring and considering it as a >> > replacement to Solarwinds. >> > >> > >> > >> > Cheers, >> > >> > Paul >> > >> > >> > >> > >> > > > > > -- > Mike Lyon > 408-621-4826 > mike.lyon at gmail.com > > http://www.linkedin.com/in/mlyon > > > From mike.lyon at gmail.com Thu Nov 26 00:38:31 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 25 Nov 2015 16:38:31 -0800 Subject: SevOne Monitoring In-Reply-To: <6CC1E8BF-3C27-4EAF-A589-98CC89DE2620@mor-pah.net> References: <00be01d1275e$e6400760$b2c01620$@paulstewart.org> <4C69C9B1-B80F-44D0-B30F-FAF49757579A@mor-pah.net> <6CC1E8BF-3C27-4EAF-A589-98CC89DE2620@mor-pah.net> Message-ID: Shucks. On Wed, Nov 25, 2015 at 4:03 PM, James Greig wrote: > No, as far as I know that's work in progress at the moment. The alert > system works well for anything polled though but depends how often you're > polling > > James Greig > > On 25 Nov 2015, at 23:49, Mike Lyon wrote: > > Can Observium alert on SNMP traps? I seem to remember that it couldn't do > that... > > On Wed, Nov 25, 2015 at 12:59 PM, James Greig wrote: > >> Depending on what you're after observium might be worth looking into. I >> run solarwinds, paessler and observium but neither are as clear and as >> useful for monitoring network as observium ( My opinion only of course ) >> >> Kind regards >> >> James Greig >> >> > On 25 Nov 2015, at 08:54, Paul Stewart wrote: >> > >> > Hey folks. >> > >> > >> > >> > Looking for feedback from actual customers on SevOne for network >> monitoring >> > . anyone using them and willing to share thoughts online/offline? >> > >> > >> > >> > They have an appealing system for network monitoring and considering it >> as a >> > replacement to Solarwinds. >> > >> > >> > >> > Cheers, >> > >> > Paul >> > >> > >> > >> > >> > >> > > > > -- > Mike Lyon > 408-621-4826 > mike.lyon at gmail.com > > http://www.linkedin.com/in/mlyon > > > > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From rwebb at ropeguru.com Thu Nov 26 00:42:22 2015 From: rwebb at ropeguru.com (Robert Webb) Date: Wed, 25 Nov 2015 19:42:22 -0500 Subject: Bluehost.com In-Reply-To: <62b3e90c9574776b8a43974eb72f3cd8.squirrel@66.201.44.180> References: <20151125180440.GA20559@nic.fr><6f661213d9ce49dbee4721ab2423140a.squirrel@66.201.44.180><62b3e90c9574776b8a43974eb72f3cd8.squirrel@66.201.44.180> Message-ID: However, with thousands more users at that price point, you would think the income would be plenty for better services. Who makes more, the store with smaller quantities at higher prices or the store that sells more bulk at lower prices? Perception of value, I believe, wins. Robert On Wed, 25 Nov 2015 16:00:37 -0800 "Bob Evans" wrote: > Yes, I agree with you Joe - a hasty generalization, as "you get >what you > pay for" doesn't really apply to as many goods in the same way it >does to > almost all services. However, a $3.49 web site service should have >be a > good first clue. > > Thank You > Bob Evans > CTO > > >> Walmart has cheap prices so "you get what you pay for."?? >> Hasty generalization but I can't disagree 100% with your opinion on >>this >> one. >> I am learning about the non-profit world of IT and the challenges >>are all >> around me. :) >> >> -- >> Later, Joe >> >> On Wed, Nov 25, 2015 at 12:27 PM, Bob Evans >> >> wrote: >> >>> >>> Gee, for $3.49 for a website hosting per month , it's a real >>>bargain. >>> While the network person inside me says, Wow that's a long outage. >>>The >>> other part of me is really wondering what one thinks they can really >>> expect from a company that hosts a website for just $3.49 ? Such a >>> bargain at less than 1/2 the price of a single hot dog at a baseball >>> stadium per month. That price point alone tells you about the setup >>>and >>> what you are agreeing too and who it's built for. Goes along with >>>the >>> ol' >>> saying, "you get what you pay for." >>> >>> If they are down for 10 hours a month out of the average 720 hours >>>in a >>> month - thats a tiny percentage 1-2 of the time it's unavailable - >>>in >>> service terms of dollars it's roughly a nickel they credit each >>> customer. >>> Do I need more coffee or is my math wrong about a nickel for 10 >>>hours of >>> website hosing ? >>> >>> However, maybe that is all many companies /sites really need. In >>>which >>> case, it should be easy enough to build in backup yourself using two >>> cheap >>> hosing providers and flip between them when the need arises. Or pick >>>a >>> provider that manages their routing well and works with you quickly, >>> but, >>> you'll have to pay more for that. >>> >>> Yep, the math spells it out - "you get what you pay for." >>> >>> Thank You >>> Bob Evans >>> CTO >>> >>> >>> > remember folks, redundancy is the savior of all f***ups. >>> > >>> > :) >>> > >>> > On Wed, Nov 25, 2015 at 2:21 PM, JoeSox wrote: >>> > >>> >> I just waited 160 minutes for a tech call and the Bluehost tech >>>told >>> me >>> >> he >>> >> was able to confirm that it wasn't malicious activity that took >>>down >>> the >>> >> datacenter but rather it was caused by a "datacenter issue". >>> >> So my first thought is someone didn't design the topology >>>correctly >>> or >>> >> something. >>> >> Some of our emails are coming thru but Google DNS still lost all >>>of >>> our >>> >> DNS >>> >> zones which are hosted by Bluehost. >>> >> At least the #bluehostdown is fun to read :/ >>> >> -- >>> >> Later, Joe >>> >> >>> >> On Wed, Nov 25, 2015 at 10:04 AM, Stephane Bortzmeyer >>> >> >>> >> wrote: >>> >> >>> >> > On Wed, Nov 25, 2015 at 08:41:55AM -0800, >>> >> > JoeSox wrote >>> >> > a message of 9 lines which said: >>> >> > >>> >> > > Anyone have the scope on the outage for Bluehost? >>> >> > > https://twitter.com/search?q=%23bluehostdown&src=tyah >>> >> > >>> >> > The two name servers ns1.bluehost.com and ns2.bluehost.com are >>> awfully >>> >> > slow to respond: >>> >> > >>> >> > % check-soa -i picturemotion.com >>> >> > ns1.bluehost.com. >>> >> > 74.220.195.31: OK: 2012092007 (1382 ms) >>> >> > ns2.bluehost.com. >>> >> > 69.89.16.4: OK: 2012092007 (1388 ms) >>> >> > >>> >> > As a result, most clients timeout. >>> >> > >>> >> > May be a DoS against the name servers? >>> >> > >>> >> > bluehost.com itself is DNS-hosted on a completely different >>> >> > architecture. So it works fine. But the nginx Web site replies >>>502 >>> >> > Gateway timeout, probably overloaded by all the clients trying >>>to >>> get >>> >> > informed. >>> >> > >>> >> > The Twitter accounts of Bluehost do not distribute any useful >>> >> > information. >>> >> > >>> >> >>> > >>> >>> From bob at FiberInternetCenter.com Thu Nov 26 01:19:54 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Wed, 25 Nov 2015 17:19:54 -0800 Subject: Bluehost.com In-Reply-To: References: <20151125180440.GA20559@nic.fr><6f661213d9ce49dbee4721ab2423140a.squirrel@66.201.44.180><62b3e90c9574776b8a43974eb72f3cd8.squirrel@66.201.44.180> Message-ID: <7b66dbeb53965d5e9a48887196e9ed42.squirrel@66.201.44.180> For an ISP type service - it's almost impossible the make it up in volume - all you need is one phone call to cost you $10 in support on a $3.50 service. With that many customers you can imagine how many call to just ask what happened or vent after the event is over. I founded a cable modem business prior to docsis standard. Call center with 150 people in it. People would call for help with their printer just because we answered the phone. So support for a $3.49 web service must make compromises somewhere in an attempt to reach profitability. I know of 3 very big ISPs - all barely making money for years. Providing crummy service , priced cheaply and expecting to make it up in volume. Their solution was to merge and lose money together. Still providing a lowball price for service , they then took the profitable parts of the business and sold those to others so they can re-org and improve cash momentarily. The re-org produced the same low prices and crummy service. So it's a cycle some people play just to win money from hedge funds, investors and finally the public. What do they call it when one keeps doing the same thing over and over again expecting a different result ? Low priced services are difficult to make profitable - if you drove your car the way most low priced business services operate you would have a car that top speeds at the minimal freeway speed, wouldnt carry a a spare tire, drive around until the empty light turns on and carry as little insurance as possible. - Gee, come to think of it, I've been in an airport shuttle van like that in new york. Thank You Bob Evans CTO > However, with thousands more users at that price point, you would think > the > income would be plenty for better services. > > Who makes more, the store with smaller quantities at higher prices or the > store that sells more bulk at lower prices? Perception of value, I > believe, > wins. > > Robert > > On Wed, 25 Nov 2015 16:00:37 -0800 > "Bob Evans" wrote: >> Yes, I agree with you Joe - a hasty generalization, as "you get >>what you >> pay for" doesn't really apply to as many goods in the same way it >>does to >> almost all services. However, a $3.49 web site service should have >>be a >> good first clue. >> >> Thank You >> Bob Evans >> CTO >> >> >>> Walmart has cheap prices so "you get what you pay for."?? >>> Hasty generalization but I can't disagree 100% with your opinion on >>>this >>> one. >>> I am learning about the non-profit world of IT and the challenges >>>are all >>> around me. :) >>> >>> -- >>> Later, Joe >>> >>> On Wed, Nov 25, 2015 at 12:27 PM, Bob Evans >>> >>> wrote: >>> >>>> >>>> Gee, for $3.49 for a website hosting per month , it's a real >>>>bargain. >>>> While the network person inside me says, Wow that's a long outage. >>>>The >>>> other part of me is really wondering what one thinks they can really >>>> expect from a company that hosts a website for just $3.49 ? Such a >>>> bargain at less than 1/2 the price of a single hot dog at a baseball >>>> stadium per month. That price point alone tells you about the setup >>>>and >>>> what you are agreeing too and who it's built for. Goes along with >>>>the >>>> ol' >>>> saying, "you get what you pay for." >>>> >>>> If they are down for 10 hours a month out of the average 720 hours >>>>in a >>>> month - thats a tiny percentage 1-2 of the time it's unavailable - >>>>in >>>> service terms of dollars it's roughly a nickel they credit each >>>> customer. >>>> Do I need more coffee or is my math wrong about a nickel for 10 >>>>hours of >>>> website hosing ? >>>> >>>> However, maybe that is all many companies /sites really need. In >>>>which >>>> case, it should be easy enough to build in backup yourself using two >>>> cheap >>>> hosing providers and flip between them when the need arises. Or pick >>>>a >>>> provider that manages their routing well and works with you quickly, >>>> but, >>>> you'll have to pay more for that. >>>> >>>> Yep, the math spells it out - "you get what you pay for." >>>> >>>> Thank You >>>> Bob Evans >>>> CTO >>>> >>>> >>>> > remember folks, redundancy is the savior of all f***ups. >>>> > >>>> > :) >>>> > >>>> > On Wed, Nov 25, 2015 at 2:21 PM, JoeSox wrote: >>>> > >>>> >> I just waited 160 minutes for a tech call and the Bluehost tech >>>>told >>>> me >>>> >> he >>>> >> was able to confirm that it wasn't malicious activity that took >>>>down >>>> the >>>> >> datacenter but rather it was caused by a "datacenter issue". >>>> >> So my first thought is someone didn't design the topology >>>>correctly >>>> or >>>> >> something. >>>> >> Some of our emails are coming thru but Google DNS still lost all >>>>of >>>> our >>>> >> DNS >>>> >> zones which are hosted by Bluehost. >>>> >> At least the #bluehostdown is fun to read :/ >>>> >> -- >>>> >> Later, Joe >>>> >> >>>> >> On Wed, Nov 25, 2015 at 10:04 AM, Stephane Bortzmeyer >>>> >> >>>> >> wrote: >>>> >> >>>> >> > On Wed, Nov 25, 2015 at 08:41:55AM -0800, >>>> >> > JoeSox wrote >>>> >> > a message of 9 lines which said: >>>> >> > >>>> >> > > Anyone have the scope on the outage for Bluehost? >>>> >> > > https://twitter.com/search?q=%23bluehostdown&src=tyah >>>> >> > >>>> >> > The two name servers ns1.bluehost.com and ns2.bluehost.com are >>>> awfully >>>> >> > slow to respond: >>>> >> > >>>> >> > % check-soa -i picturemotion.com >>>> >> > ns1.bluehost.com. >>>> >> > 74.220.195.31: OK: 2012092007 (1382 ms) >>>> >> > ns2.bluehost.com. >>>> >> > 69.89.16.4: OK: 2012092007 (1388 ms) >>>> >> > >>>> >> > As a result, most clients timeout. >>>> >> > >>>> >> > May be a DoS against the name servers? >>>> >> > >>>> >> > bluehost.com itself is DNS-hosted on a completely different >>>> >> > architecture. So it works fine. But the nginx Web site replies >>>>502 >>>> >> > Gateway timeout, probably overloaded by all the clients trying >>>>to >>>> get >>>> >> > informed. >>>> >> > >>>> >> > The Twitter accounts of Bluehost do not distribute any useful >>>> >> > information. >>>> >> > >>>> >> >>>> > >>>> >>>> > > From nanogml at Mail.DDoS-Mitigator.net Thu Nov 26 02:15:22 2015 From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog) Date: Wed, 25 Nov 2015 18:15:22 -0800 Subject: Bluehost.com In-Reply-To: <7b66dbeb53965d5e9a48887196e9ed42.squirrel@66.201.44.180> References: <20151125180440.GA20559@nic.fr> <6f661213d9ce49dbee4721ab2423140a.squirrel@66.201.44.180> <62b3e90c9574776b8a43974eb72f3cd8.squirrel@66.201.44.180> <7b66dbeb53965d5e9a48887196e9ed42.squirrel@66.201.44.180> Message-ID: <20151126021522.GA18194@Mail.DDoS-Mitigator.net> hi On 11/25/15 at 05:19pm, Bob Evans wrote: > For an ISP type service - it's almost impossible the make it up in volume > - all you need is one phone call to cost you $10 in support on a $3.50 > service. With that many customers you can imagine how many call to just > ask what happened or vent after the event is over. a painful reality ... support costs are NOT cheap if one is trying to keep customers happy more customers usually requires more support expenses too and hopeully, support expenses would start to go down after some critical levels > I founded a cable modem business prior to docsis standard. congrats.. > What do they call it when one keeps > doing the same thing over and over again expecting a different result ? "the internet" "there's NO sheriff in town" "there's a (new) sucker born every second" "dumb money" "tax deductions - tax write offs" "i wanna get involved, me too syndrome" ... > Low priced services are difficult to make profitable - pricing strategy vs customer volume is always a tradeoff - one can always give well behaved customers their discounts from "normal pricing" - one cannot give "good service" when starting from "lowest possible pricing" magic pixie dust on dah turkey alvin From bob at FiberInternetCenter.com Thu Nov 26 02:49:55 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Wed, 25 Nov 2015 18:49:55 -0800 Subject: Bluehost.com In-Reply-To: <0bd301d127ed$737e3b40$5a7ab1c0$@com> References: <20151125180440.GA20559@nic.fr><6f661213d9ce49dbee4721ab2423140a.squirrel@66.201.44.180><62b3e90c9574776b8a43974eb72f3cd8.squirrel@66.201.44.180> <7b66dbeb53965d5e9a48887196e9ed42.squirrel@66.201.44.180> <0bd301d127ed$737e3b40$5a7ab1c0$@com> Message-ID: Kiriki, you nailed it. Explained this perfectly. Thank You Bob Evans CTO > The bottom line is the value/price ratio. We should all be working to add > value. By any means necessary. > > The pitfall of low priced "services", is that it's hard to balance the > support level and lower price for services. > > If Bluehost and lower end web hosters can completely do away with the > support aspect, certainly SAAS can scale. But if a significant part of > your > value proposition is support, it's real hard to get down this low if any > human is ever involved, and if you pay a living wage to your workers. I > really expect at the ultra low end you have to be willing to do away with > live support, and just provide a product that works....with no support. > > Would people want to buy a web host for $3.95 but if they engage support > pay > $15/hour for it? Perhaps that would work... but I think the value > proposition gets skewed in this sense. Those customers paying this little > likely needs support in a variety of ways. The challenge is to do it all > right, so they don't... > > I agree with Bob, more likely they are subsidizing costs with investment > and > hoping to provide a profitable model in the future with enough market > share. > > Bottom line, is the industry needs to be increasing value, because the > flip > side.... working for no profit, surviving off investment only... there's > no > end-game. You see this cycle time and time again as market share is > grabbed, > then underperforming companies are rolled up. In this process value is > destroyed. > > Ultimately this is also why it's extremely damaging for investors to > constantly invest in companies that don't make a profit, and don't provide > a > successful economical model for the services/products provided. These > companies largely live on investor money, lose money, and in their wake > destroy value for the entire industry. Of course the end-game for the > investors is to make money... I'm always surprised how strong > investment/gambles are for non-profitable companies. I guess there is no > end > to those with too much money that have to place that money somewhere. As > the > rich get richer, there will only be more dumb money cheapening the value > proposition. After all, who needs value when you have willing investors. > > Bottom line is that if it's not worth doing... then maybe it should not be > done. Maybe the race to the bottom is not worth it. Maybe investments that > lose value for an industry should be limited. > > The giant pool of money is now weaponized. > > -Kiriki > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bob Evans > Sent: Wednesday, November 25, 2015 5:20 PM > To: Robert Webb > Cc: NANOG > Subject: Re: Bluehost.com > > For an ISP type service - it's almost impossible the make it up in volume > - all you need is one phone call to cost you $10 in support on a $3.50 > service. With that many customers you can imagine how many call to just > ask > what happened or vent after the event is over. > > I founded a cable modem business prior to docsis standard. Call center > with > 150 people in it. People would call for help with their printer just > because > we answered the phone. So support for a $3.49 web service must make > compromises somewhere in an attempt to reach profitability. > > I know of 3 very big ISPs - all barely making money for years. Providing > crummy service , priced cheaply and expecting to make it up in volume. > Their solution was to merge and lose money together. Still providing a > lowball price for service , they then took the profitable parts of the > business and sold those to others so they can re-org and improve cash > momentarily. The re-org produced the same low prices and crummy service. > So it's a cycle some people play just to win money from hedge funds, > investors and finally the public. What do they call it when one keeps > doing > the same thing over and over again expecting a different result ? > > Low priced services are difficult to make profitable - if you drove your > car > the way most low priced business services operate you would have a car > that > top speeds at the minimal freeway speed, wouldnt carry a a spare tire, > drive > around until the empty light turns on and carry as little insurance as > possible. - Gee, come to think of it, I've been in an airport shuttle van > like that in new york. > > Thank You > Bob Evans > CTO > > > > >> However, with thousands more users at that price point, you would >> think the income would be plenty for better services. >> >> Who makes more, the store with smaller quantities at higher prices or >> the store that sells more bulk at lower prices? Perception of value, I >> believe, wins. >> >> Robert >> >> On Wed, 25 Nov 2015 16:00:37 -0800 >> "Bob Evans" wrote: >>> Yes, I agree with you Joe - a hasty generalization, as "you get what >>>you pay for" doesn't really apply to as many goods in the same way it >>>does to almost all services. However, a $3.49 web site service should >>>have be a good first clue. >>> >>> Thank You >>> Bob Evans >>> CTO >>> >>> >>>> Walmart has cheap prices so "you get what you pay for."?? >>>> Hasty generalization but I can't disagree 100% with your opinion on >>>>this one. >>>> I am learning about the non-profit world of IT and the challenges >>>>are all around me. :) >>>> >>>> -- >>>> Later, Joe >>>> >>>> On Wed, Nov 25, 2015 at 12:27 PM, Bob Evans >>>> >>>> wrote: >>>> >>>>> >>>>> Gee, for $3.49 for a website hosting per month , it's a real >>>>>bargain. >>>>> While the network person inside me says, Wow that's a long outage. >>>>>The >>>>> other part of me is really wondering what one thinks they can >>>>>really expect from a company that hosts a website for just $3.49 ? >>>>>Such a bargain at less than 1/2 the price of a single hot dog at a >>>>>baseball stadium per month. That price point alone tells you about >>>>>the setup and what you are agreeing too and who it's built for. >>>>>Goes along with the ol' >>>>> saying, "you get what you pay for." >>>>> >>>>> If they are down for 10 hours a month out of the average 720 hours >>>>>in a month - thats a tiny percentage 1-2 of the time it's >>>>>unavailable - in service terms of dollars it's roughly a nickel >>>>>they credit each customer. >>>>> Do I need more coffee or is my math wrong about a nickel for 10 >>>>>hours of website hosing ? >>>>> >>>>> However, maybe that is all many companies /sites really need. In >>>>>which case, it should be easy enough to build in backup yourself >>>>>using two cheap hosing providers and flip between them when the >>>>>need arises. Or pick a provider that manages their routing well and >>>>>works with you quickly, but, you'll have to pay more for that. >>>>> >>>>> Yep, the math spells it out - "you get what you pay for." >>>>> >>>>> Thank You >>>>> Bob Evans >>>>> CTO >>>>> >>>>> >>>>> > remember folks, redundancy is the savior of all f***ups. >>>>> > >>>>> > :) >>>>> > >>>>> > On Wed, Nov 25, 2015 at 2:21 PM, JoeSox wrote: >>>>> > >>>>> >> I just waited 160 minutes for a tech call and the Bluehost tech >>>>>told >>>>> me >>>>> >> he >>>>> >> was able to confirm that it wasn't malicious activity that took >>>>>down >>>>> the >>>>> >> datacenter but rather it was caused by a "datacenter issue". >>>>> >> So my first thought is someone didn't design the topology >>>>>correctly >>>>> or >>>>> >> something. >>>>> >> Some of our emails are coming thru but Google DNS still lost all >>>>>of >>>>> our >>>>> >> DNS >>>>> >> zones which are hosted by Bluehost. >>>>> >> At least the #bluehostdown is fun to read :/ >>>>> >> -- >>>>> >> Later, Joe >>>>> >> >>>>> >> On Wed, Nov 25, 2015 at 10:04 AM, Stephane Bortzmeyer >>>>> >> >>>>> >> wrote: >>>>> >> >>>>> >> > On Wed, Nov 25, 2015 at 08:41:55AM -0800, JoeSox >>>>> >> > wrote a message of 9 lines which said: >>>>> >> > >>>>> >> > > Anyone have the scope on the outage for Bluehost? >>>>> >> > > https://twitter.com/search?q=%23bluehostdown&src=tyah >>>>> >> > >>>>> >> > The two name servers ns1.bluehost.com and ns2.bluehost.com are >>>>> awfully >>>>> >> > slow to respond: >>>>> >> > >>>>> >> > % check-soa -i picturemotion.com ns1.bluehost.com. >>>>> >> > 74.220.195.31: OK: 2012092007 (1382 ms) >>>>> >> > ns2.bluehost.com. >>>>> >> > 69.89.16.4: OK: 2012092007 (1388 ms) >>>>> >> > >>>>> >> > As a result, most clients timeout. >>>>> >> > >>>>> >> > May be a DoS against the name servers? >>>>> >> > >>>>> >> > bluehost.com itself is DNS-hosted on a completely different >>>>> >> > architecture. So it works fine. But the nginx Web site replies >>>>>502 >>>>> >> > Gateway timeout, probably overloaded by all the clients trying >>>>>to >>>>> get >>>>> >> > informed. >>>>> >> > >>>>> >> > The Twitter accounts of Bluehost do not distribute any useful >>>>> >> > information. >>>>> >> > >>>>> >> >>>>> > >>>>> >>>>> >> >> > > > > From morrowc.lists at gmail.com Thu Nov 26 04:35:36 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 25 Nov 2015 23:35:36 -0500 Subject: Oh Hai! Telstra/reach.... HOWDY! Message-ID: THIS IS A WARNING MESSAGE ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. Delivery to the following recipient has been delayed: dbadmin at net.reach.com Message will be retried for 1 more day(s) COULD YOU MAKE YOUR EMAIL WORK! (for f's sake.. srsly, this is your POC for your IRR and it's broken... ) From mtaylor at mty.net.au Thu Nov 26 04:49:26 2015 From: mtaylor at mty.net.au (Matt Taylor) Date: Thu, 26 Nov 2015 15:49:26 +1100 Subject: Oh Hai! Telstra/reach.... HOWDY! In-Reply-To: References: Message-ID: <56568F56.8020103@mty.net.au> Hi Christopher, A better place to reach out to Telstra employees is AusNOG (with a nicely written email, might I add). I've BCC'd a fairly active (awesome) Telstra staff member from AusNOG into this response, so it's up to him if he wishes to respond directly to you; or even escalate the issue internally. Thanks, Matt. On 26/11/2015 15:35, Christopher Morrow wrote: > THIS IS A WARNING MESSAGE ONLY. > > YOU DO NOT NEED TO RESEND YOUR MESSAGE. > > Delivery to the following recipient has been delayed: > > dbadmin at net.reach.com > > Message will be retried for 1 more day(s) > > COULD YOU MAKE YOUR EMAIL WORK! > (for f's sake.. srsly, this is your POC for your IRR and it's broken... ) From marka at isc.org Thu Nov 26 06:04:12 2015 From: marka at isc.org (Mark Andrews) Date: Thu, 26 Nov 2015 17:04:12 +1100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: Your message of "Thu, 26 Nov 2015 06:34:49 +0100." <20151126053449.GA22347@eik.bme.hu> References: <5652D3F9.6030009@lanparty.ee> <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> <20151123202706.6A0A83D76305@rock.dv.isc.org> <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com> <20151123223954.A3DA13D775D5@rock.dv.isc.org> <42270.1448383626@turing-police.cc.vt.edu> <20151124233647.E3D5B3D855A4@rock.dv.isc.org> <20151125235950.6E5293D93209@rock.dv.isc.org> <20151126053449.GA22347@eik.bme.hu> Message-ID: <20151126060412.C63F03D961A9@rock.dv.isc.org> In message <20151126053449.GA22347 at eik.bme.hu>, =?utf-8?B?SsOBS8OTIEFuZHLDoXM=?= writes: > > Well the requesting router could announce the route. ISC's client > > has hooks that allow this to be done. That is, after all, how > > routing is designed to work. The DHCP server usually is sitting > > in a data center on the other side of the country with zero ability > > to inject approptiate routes. > > > > The DHCP relay could also have injected routes but that is a second > > class solution. > > A CPE announcing the route is fine as long as the ISP controls the CPE. > > If the CPE is controled by the customer, then the ISP's problems are > similar. They need to find a way to filter the CPE's announcement so > that it can announce only the prefixes delegated to it. > > Andr??s Which is why I mentioned the DHCP relay. Somewhere back towards the beginnings of this thread there was a reference to a blog post that complained that they couldn't workout how to send a git pull request to us. I've forwarded that to our dhcp team. For future reference dhcp-bugs at isc.org or dhcp-suggest at isc.org would have been fine places to send the request. So to the bug reporting form on isc.org which lets you select if it is bug, suggestion or a security issue. There also the general contact form which would get to the dhcp team after being forwarded a couple of times. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bjorn at mork.no Thu Nov 26 10:07:35 2015 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 26 Nov 2015 11:07:35 +0100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <20151125235950.6E5293D93209@rock.dv.isc.org> (Mark Andrews's message of "Thu, 26 Nov 2015 10:59:50 +1100") References: <564F923B.9080200@jsbc.cc> <5650FDED.70300@jsbc.cc> <5652D3F9.6030009@lanparty.ee> <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> <20151123202706.6A0A83D76305@rock.dv.isc.org> <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com> <20151123223954.A3DA13D775D5@rock.dv.isc.org> <42270.1448383626@turing-police.cc.vt.edu> <20151124233647.E3D5B3D855A4@rock.dv.isc.org> <20151125235950.6E5293D93209@rock.dv.isc.org> Message-ID: <87lh9lul94.fsf@nemi.mork.no> Mark Andrews writes: > The DHCP server usually is sitting > in a data center on the other side of the country with zero ability > to inject approptiate routes. Not too sure about that. At least, that's not what we do. We run the DHCPv6 and DHCP servers on our BNGs (or BRAS or whatever the current buzzword for "access router" is). So the "servers" have full control of both DHCP/DHCPv6 and routing. The DHCP backend database may need to be centralised, but tunneling the DHCP protocol all they way through your network just to achieve that seems unnecessarily risky and error-prone. Moving the DHCP frontends as close as possible to the clients is a very simple way to make DHCP scalable and robust. If you feel you should have a DHCP server in more than one site for robustness, then you might as well do a fully distributed design. Going half-way, centralising everything and then dividing it on multiple datasenters is just ten times the trouble.. If you only do pool-based arbitrary address allocations, then you might not need a centralised database at all. Distribute your prefixes to the BNGs and let them manage the pools independently of each other. > The DHCP relay could also have injected routes but that is a second > class solution. DHCP relays *are* second class solutions :) Unfortunately they cannot always be avoided in the semi-L2-environments like ISP access networks often are. Bj?rn From sthaug at nethelp.no Thu Nov 26 10:23:55 2015 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 26 Nov 2015 11:23:55 +0100 (CET) Subject: DHCPv6 PD & Routing Questions In-Reply-To: <87lh9lul94.fsf@nemi.mork.no> References: <20151125235950.6E5293D93209@rock.dv.isc.org> <87lh9lul94.fsf@nemi.mork.no> Message-ID: <20151126.112355.74685951.sthaug@nethelp.no> > > The DHCP relay could also have injected routes but that is a second > > class solution. > > DHCP relays *are* second class solutions :) Unfortunately they cannot > always be avoided in the semi-L2-environments like ISP access networks > often are. Each to his own, I guess. Some of us are using DHCP relay agents with no problems, and don't necessarily agree on the "second class solution" characterization. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From alh-ietf at tndh.net Thu Nov 26 20:44:28 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 26 Nov 2015 12:44:28 -0800 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: <5653D2BB.8030704@stargate.ca> References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com> <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com> <20151123225817.314A03D77872@rock.dv.isc.org> <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com> <5653D2BB.8030704@stargate.ca> Message-ID: <012401d1288b$3f7d3370$be779a50$@tndh.net> Keenan Tims wrote: > To: nanog at nanog.org > Subject: Re: Binge On! - And So This is Net Neutrality? > > I'm surprised you're supporting T-Mob here Owen. To me it's pretty > clear: they are charging more for bits that are not streaming video. > That's not neutral treatment from a policy perspective, and has no basis in > the cost of operating the network. I have no visibility into what the line "T?Mobile will work with content providers to ensure that our networks work together to properly" actually means, but they could/should be using this as a tool to drive content sources to IPv6. Trying to explain to consumers why an unlimited data plan only works for a tiny subset of content is a waste of energy. Picking a category and "encouraging" that content to move, then after the time limit, pick the next category, rinse/repeat, is a way to move traffic away from the 6/4 nat infrastructure without having to make a big deal about the IP version to the consumer, and at the same time remove "it costs too much" complaints from the sources. If I were implementing such a plan, I would walk the list of traffic sources based on volume to move traffic as quickly as possible, so it makes perfect sense to me that they would start with video. Tony > > Granted, the network itself is neutral, but the purported purpose of NN in > my eyes is twofold: take away the influence of the network on user and > operator behaviour, and encourage an open market in network services > (both content and access). Allowing zero-rating based on *any* criteria > gives them a strong influence over what the end users are going to do with > their network connection, and distorts the market for network services. > What makes streaming video special to merit zero-rating? > > I like Clay's connection to the boiling frog. Yes, it's "nice" for most > consumers now, but it's still distorting the market. > > I'm also not seeing why they have to make this so complicated. If they can > afford to zero-rate high-bandwidth services like video and audio streaming, > clearly there is network capacity to spare. The user behaviour they're > encouraging with free video streaming is *precisely* what the incumbents > claimed was causing congestion to merit throttling a few years ago, and still > to this day whine about constantly. I don't have data, but I would expect > usage of this to align quite nicely with their current peaks. > > Why not just raise the caps to something reasonable or make it unlimited > across the board? I could even get behind zero-rating all 'off-peak-hours' > use like we used to have for mobile voice; at least that makes sense for the > network. What they're doing though is product differentiation where none > exists; in fact the zero-rating is likely to cause more load on the system than > just doubling or tripling the users' > caps. That there seems to be little obvious justification for it from a network > perspective makes me vary wary. > > Keenan > > On 2015-11-23 18:05, Owen DeLong wrote: > > > >> On Nov 23, 2015, at 17:28 , Baldur Norddahl > wrote: > >> > >> On 24 November 2015 at 00:22, Owen DeLong > wrote: > >> > >>> Are there a significant number (ANY?) streaming video providers > >>> using UDP to deliver their streams? > >>> > >> > >> What else could we have that is UDP based? Ah voice calls. Video calls. > >> Stuff that requires low latency and where TCP retransmit of stale > >> data is bad. Media without buffering because it is real time. > >> > >> And why would a telco want to zero rate all the bandwidth heavy media > >> with certain exceptions? Like not zero rating media that happens to > >> compete with some of their own services, such as voice calls and video > calls. > >> > >> Yes sounds like net neutrality to me too (or not!). > >> > >> Regards, > >> > >> Baldur > > > > All T-Mobile plans include unlimited 128kbps data, so a voice call is > > effectively already zero-rated for all practical purposes. > > > > I guess the question is: Is it better for the consumer to pay for > > everything equally, or, is it reasonable for carriers to be able to > > give away some free data without opening it up to everything? > > > > To me, net neutrality isn?t as much about what you charge the customer > > for the data, it?s about whether you prioritize certain classes of > > traffic to the detriment of others in terms of service delivery. > > > > If T-Mobile were taking money from the video streaming services or > > only accepting certain video streaming services, I?d likely agree with > > you that this is a neutrality issue. > > > > However, in this case, it appears to me that they aren?t trying to > > give an advantage to any particular competing streaming video service > > over the other, they aren?t taking money from participants in the program, > and consumers stand to benefit from it. > > > > If you see an actual way in which it?s better for everyone if T-Mobile > > weren?t doing this, then please explain it. If not, then this strikes > > me as harmless and overall benefits consumers. > > > > Owen > > From kiriki at streamguys.com Thu Nov 26 01:54:55 2015 From: kiriki at streamguys.com (Kiriki Delany) Date: Wed, 25 Nov 2015 17:54:55 -0800 Subject: Bluehost.com In-Reply-To: <7b66dbeb53965d5e9a48887196e9ed42.squirrel@66.201.44.180> References: <20151125180440.GA20559@nic.fr><6f661213d9ce49dbee4721ab2423140a.squirrel@66.201.44.180><62b3e90c9574776b8a43974eb72f3cd8.squirrel@66.201.44.180> <7b66dbeb53965d5e9a48887196e9ed42.squirrel@66.201.44.180> Message-ID: <0bd301d127ed$737e3b40$5a7ab1c0$@com> The bottom line is the value/price ratio. We should all be working to add value. By any means necessary. The pitfall of low priced "services", is that it's hard to balance the support level and lower price for services. If Bluehost and lower end web hosters can completely do away with the support aspect, certainly SAAS can scale. But if a significant part of your value proposition is support, it's real hard to get down this low if any human is ever involved, and if you pay a living wage to your workers. I really expect at the ultra low end you have to be willing to do away with live support, and just provide a product that works....with no support. Would people want to buy a web host for $3.95 but if they engage support pay $15/hour for it? Perhaps that would work... but I think the value proposition gets skewed in this sense. Those customers paying this little likely needs support in a variety of ways. The challenge is to do it all right, so they don't... I agree with Bob, more likely they are subsidizing costs with investment and hoping to provide a profitable model in the future with enough market share. Bottom line, is the industry needs to be increasing value, because the flip side.... working for no profit, surviving off investment only... there's no end-game. You see this cycle time and time again as market share is grabbed, then underperforming companies are rolled up. In this process value is destroyed. Ultimately this is also why it's extremely damaging for investors to constantly invest in companies that don't make a profit, and don't provide a successful economical model for the services/products provided. These companies largely live on investor money, lose money, and in their wake destroy value for the entire industry. Of course the end-game for the investors is to make money... I'm always surprised how strong investment/gambles are for non-profitable companies. I guess there is no end to those with too much money that have to place that money somewhere. As the rich get richer, there will only be more dumb money cheapening the value proposition. After all, who needs value when you have willing investors. Bottom line is that if it's not worth doing... then maybe it should not be done. Maybe the race to the bottom is not worth it. Maybe investments that lose value for an industry should be limited. The giant pool of money is now weaponized. -Kiriki -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bob Evans Sent: Wednesday, November 25, 2015 5:20 PM To: Robert Webb Cc: NANOG Subject: Re: Bluehost.com For an ISP type service - it's almost impossible the make it up in volume - all you need is one phone call to cost you $10 in support on a $3.50 service. With that many customers you can imagine how many call to just ask what happened or vent after the event is over. I founded a cable modem business prior to docsis standard. Call center with 150 people in it. People would call for help with their printer just because we answered the phone. So support for a $3.49 web service must make compromises somewhere in an attempt to reach profitability. I know of 3 very big ISPs - all barely making money for years. Providing crummy service , priced cheaply and expecting to make it up in volume. Their solution was to merge and lose money together. Still providing a lowball price for service , they then took the profitable parts of the business and sold those to others so they can re-org and improve cash momentarily. The re-org produced the same low prices and crummy service. So it's a cycle some people play just to win money from hedge funds, investors and finally the public. What do they call it when one keeps doing the same thing over and over again expecting a different result ? Low priced services are difficult to make profitable - if you drove your car the way most low priced business services operate you would have a car that top speeds at the minimal freeway speed, wouldnt carry a a spare tire, drive around until the empty light turns on and carry as little insurance as possible. - Gee, come to think of it, I've been in an airport shuttle van like that in new york. Thank You Bob Evans CTO > However, with thousands more users at that price point, you would > think the income would be plenty for better services. > > Who makes more, the store with smaller quantities at higher prices or > the store that sells more bulk at lower prices? Perception of value, I > believe, wins. > > Robert > > On Wed, 25 Nov 2015 16:00:37 -0800 > "Bob Evans" wrote: >> Yes, I agree with you Joe - a hasty generalization, as "you get what >>you pay for" doesn't really apply to as many goods in the same way it >>does to almost all services. However, a $3.49 web site service should >>have be a good first clue. >> >> Thank You >> Bob Evans >> CTO >> >> >>> Walmart has cheap prices so "you get what you pay for."?? >>> Hasty generalization but I can't disagree 100% with your opinion on >>>this one. >>> I am learning about the non-profit world of IT and the challenges >>>are all around me. :) >>> >>> -- >>> Later, Joe >>> >>> On Wed, Nov 25, 2015 at 12:27 PM, Bob Evans >>> >>> wrote: >>> >>>> >>>> Gee, for $3.49 for a website hosting per month , it's a real >>>>bargain. >>>> While the network person inside me says, Wow that's a long outage. >>>>The >>>> other part of me is really wondering what one thinks they can >>>>really expect from a company that hosts a website for just $3.49 ? >>>>Such a bargain at less than 1/2 the price of a single hot dog at a >>>>baseball stadium per month. That price point alone tells you about >>>>the setup and what you are agreeing too and who it's built for. >>>>Goes along with the ol' >>>> saying, "you get what you pay for." >>>> >>>> If they are down for 10 hours a month out of the average 720 hours >>>>in a month - thats a tiny percentage 1-2 of the time it's >>>>unavailable - in service terms of dollars it's roughly a nickel >>>>they credit each customer. >>>> Do I need more coffee or is my math wrong about a nickel for 10 >>>>hours of website hosing ? >>>> >>>> However, maybe that is all many companies /sites really need. In >>>>which case, it should be easy enough to build in backup yourself >>>>using two cheap hosing providers and flip between them when the >>>>need arises. Or pick a provider that manages their routing well and >>>>works with you quickly, but, you'll have to pay more for that. >>>> >>>> Yep, the math spells it out - "you get what you pay for." >>>> >>>> Thank You >>>> Bob Evans >>>> CTO >>>> >>>> >>>> > remember folks, redundancy is the savior of all f***ups. >>>> > >>>> > :) >>>> > >>>> > On Wed, Nov 25, 2015 at 2:21 PM, JoeSox wrote: >>>> > >>>> >> I just waited 160 minutes for a tech call and the Bluehost tech >>>>told >>>> me >>>> >> he >>>> >> was able to confirm that it wasn't malicious activity that took >>>>down >>>> the >>>> >> datacenter but rather it was caused by a "datacenter issue". >>>> >> So my first thought is someone didn't design the topology >>>>correctly >>>> or >>>> >> something. >>>> >> Some of our emails are coming thru but Google DNS still lost all >>>>of >>>> our >>>> >> DNS >>>> >> zones which are hosted by Bluehost. >>>> >> At least the #bluehostdown is fun to read :/ >>>> >> -- >>>> >> Later, Joe >>>> >> >>>> >> On Wed, Nov 25, 2015 at 10:04 AM, Stephane Bortzmeyer >>>> >> >>>> >> wrote: >>>> >> >>>> >> > On Wed, Nov 25, 2015 at 08:41:55AM -0800, JoeSox >>>> >> > wrote a message of 9 lines which said: >>>> >> > >>>> >> > > Anyone have the scope on the outage for Bluehost? >>>> >> > > https://twitter.com/search?q=%23bluehostdown&src=tyah >>>> >> > >>>> >> > The two name servers ns1.bluehost.com and ns2.bluehost.com are >>>> awfully >>>> >> > slow to respond: >>>> >> > >>>> >> > % check-soa -i picturemotion.com ns1.bluehost.com. >>>> >> > 74.220.195.31: OK: 2012092007 (1382 ms) >>>> >> > ns2.bluehost.com. >>>> >> > 69.89.16.4: OK: 2012092007 (1388 ms) >>>> >> > >>>> >> > As a result, most clients timeout. >>>> >> > >>>> >> > May be a DoS against the name servers? >>>> >> > >>>> >> > bluehost.com itself is DNS-hosted on a completely different >>>> >> > architecture. So it works fine. But the nginx Web site replies >>>>502 >>>> >> > Gateway timeout, probably overloaded by all the clients trying >>>>to >>>> get >>>> >> > informed. >>>> >> > >>>> >> > The Twitter accounts of Bluehost do not distribute any useful >>>> >> > information. >>>> >> > >>>> >> >>>> > >>>> >>>> > > From jako.andras at eik.bme.hu Thu Nov 26 05:34:49 2015 From: jako.andras at eik.bme.hu (=?utf-8?B?SsOBS8OTIEFuZHLDoXM=?=) Date: Thu, 26 Nov 2015 06:34:49 +0100 Subject: DHCPv6 PD & Routing Questions In-Reply-To: <20151125235950.6E5293D93209@rock.dv.isc.org> References: <5652D3F9.6030009@lanparty.ee> <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com> <20151123202706.6A0A83D76305@rock.dv.isc.org> <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com> <20151123223954.A3DA13D775D5@rock.dv.isc.org> <42270.1448383626@turing-police.cc.vt.edu> <20151124233647.E3D5B3D855A4@rock.dv.isc.org> <20151125235950.6E5293D93209@rock.dv.isc.org> Message-ID: <20151126053449.GA22347@eik.bme.hu> > Well the requesting router could announce the route. ISC's client > has hooks that allow this to be done. That is, after all, how > routing is designed to work. The DHCP server usually is sitting > in a data center on the other side of the country with zero ability > to inject approptiate routes. > > The DHCP relay could also have injected routes but that is a second > class solution. A CPE announcing the route is fine as long as the ISP controls the CPE. If the CPE is controled by the customer, then the ISP's problems are similar. They need to find a way to filter the CPE's announcement so that it can announce only the prefixes delegated to it. Andr?s From nellermann at broadaspect.com Fri Nov 27 14:03:17 2015 From: nellermann at broadaspect.com (Nick Ellermann) Date: Fri, 27 Nov 2015 14:03:17 +0000 Subject: Anyone having issues with Equinix IX out of Ashburn? Message-ID: <7711a4914ac641c9b3d4357bee8e5468@exchange.broadaspect.local> At about 4:15 am eastern we lost our bgp peers on the Ashburn IX at Equinix. Equinix is not responding to our support requests, either they are overloaded with support requests or all on holiday. Curious if others know if there are known issues at this site or is it just us. Sincerely, Nick Ellermann - CTO & VP Cloud Services BroadAspect E: nellermann at broadaspect.com P: 703-297-4639 F: 703-996-4443 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. From jeroen.wunnink at hibernianetworks.com Fri Nov 27 14:13:23 2015 From: jeroen.wunnink at hibernianetworks.com (Jeroen Wunnink) Date: Fri, 27 Nov 2015 15:13:23 +0100 Subject: Anyone having issues with Equinix IX out of Ashburn? In-Reply-To: <7711a4914ac641c9b3d4357bee8e5468@exchange.broadaspect.local> References: <7711a4914ac641c9b3d4357bee8e5468@exchange.broadaspect.local> Message-ID: <56586503.7090108@hibernianetworks.com> We've seen issues as well. We've just started to turn the exchange up again and check if it's fixed. On 27/11/15 15:03, Nick Ellermann wrote: > At about 4:15 am eastern we lost our bgp peers on the Ashburn IX at Equinix. Equinix is not responding to our support requests, either they are overloaded with support requests or all on holiday. Curious if others know if there are known issues at this site or is it just us. > > > Sincerely, > Nick Ellermann - CTO & VP Cloud Services > BroadAspect > > E: nellermann at broadaspect.com > P: 703-297-4639 > F: 703-996-4443 > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. > -- Jeroen Wunnink IP Engineering Manager - Hibernia Networks Main numbers (Ext: 1011): USA +1.908.516.4200 | UK +44.1704.322.300 Netherlands +31.208.200.622 | 24/7 IP NOC Phone: +31.20.82.00.623 jeroen.wunnink at hibernianetworks.com www.hibernianetworks.com This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From eric at atlantech.net Fri Nov 27 15:24:42 2015 From: eric at atlantech.net (Eric Van Tol) Date: Fri, 27 Nov 2015 10:24:42 -0500 Subject: Anyone having issues with Equinix IX out of Ashburn? In-Reply-To: <56586503.7090108@hibernianetworks.com> References: <7711a4914ac641c9b3d4357bee8e5468@exchange.broadaspect.local> <56586503.7090108@hibernianetworks.com> Message-ID: <2C05E949E19A9146AF7BDF9D44085B86720A8130CF@exchange.aoihq.local> Received a notification shortly after reporting the problem at 6am this morning about "issues" on the Exchange. We saw packet input on our routers in upwards of 350K pps, with all peers disabled. Looked to be a broadcast/multicast storm. Seems to be good now, but no explanation of what was found. -evt > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jeroen Wunnink > Sent: Friday, November 27, 2015 9:13 AM > To: nanog at nanog.org > Subject: Re: Anyone having issues with Equinix IX out of Ashburn? > > We've seen issues as well. We've just started to turn the exchange up > again and check if it's fixed. > > > On 27/11/15 15:03, Nick Ellermann wrote: > > At about 4:15 am eastern we lost our bgp peers on the Ashburn IX at > Equinix. Equinix is not responding to our support requests, either they are > overloaded with support requests or all on holiday. Curious if others know > if there are known issues at this site or is it just us. > > > > > > Sincerely, > > Nick Ellermann - CTO & VP Cloud Services > > BroadAspect > > > > E: nellermann at broadaspect.com > > P: 703-297-4639 > > F: 703-996-4443 > > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > > > > > -- > > Jeroen Wunnink > IP Engineering Manager - Hibernia Networks > Main numbers (Ext: 1011): USA +1.908.516.4200 | UK +44.1704.322.300 > Netherlands +31.208.200.622 | 24/7 IP NOC Phone: +31.20.82.00.623 > jeroen.wunnink at hibernianetworks.com > www.hibernianetworks.com > > This e-mail and any attachments thereto is intended only for use by the > addressee(s) named herein and may be proprietary and/or legally privileged. > If you are not the intended recipient of this e-mail, you are hereby > notified that any dissemination, distribution or copying of this email, and > any attachments thereto, without the prior written permission of the sender > is strictly prohibited. If you receive this e-mail in error, please > immediately telephone or e-mail the sender and permanently delete the > original copy and any copy of this e-mail, and any printout thereof. All > documents, contracts or agreements referred or attached to this e-mail are > SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may > contain software viruses that could damage your own computer system. While > Hibernia Networks has taken every reasonable precaution to minimize this > risk, we cannot accept liability for any damage that you sustain as a result > of software viruses. You should carry out your own virus checks before > opening any attachment. From hibaysal at gmail.com Fri Nov 27 09:39:18 2015 From: hibaysal at gmail.com (H I Baysal) Date: Fri, 27 Nov 2015 10:39:18 +0100 Subject: Opinions on Arista 7280? In-Reply-To: References: Message-ID: Hi, Hardware is really nice. Backplane, buffers, just basically ?pumping? bandwidth. It?s really good. However, mlag can show some bugs when having only 1 interface in an MLAG (only 1 side) they had issues with the ifindex numbering in software. There were OSPF configuration options missing, etc. In short, hardware is really nice, software needs more maturing. Nice for distribution but not for core. > On 24 Nov 2015, at 19:02, David Hubbard wrote: > > Curious if anyone's used the 7280 and wants to share their experience? > I'm looking at it primarily for three reasons, MLAG (i.e. multi-chassis > LACP), large ARP/MAC table (256k entries) and large IPv6 neighbor table > (256k entries). For the table sizes we would like out of one pair of > switches, we'd be into the Cisco 7000 series, but that's dramatically > more expensive and we don't need much of anything else that it offers. > > Looked at Brocade too, but they don't have devices that can do the multi > chassis LACP, has the huge table sizes and has a reasonable number of > 10gig ports. It was possible to construct a workable solution using > VDX's for switching and CER's for routing, but that's more complex than > Arista's option if it's a usable option. > > Thanks, > > David From kiwi at oav.net Fri Nov 27 14:22:13 2015 From: kiwi at oav.net (Xavier Beaudouin) Date: Fri, 27 Nov 2015 15:22:13 +0100 (CET) Subject: Anyone having issues with Equinix IX out of Ashburn? In-Reply-To: <56586503.7090108@hibernianetworks.com> References: <7711a4914ac641c9b3d4357bee8e5468@exchange.broadaspect.local> <56586503.7090108@hibernianetworks.com> Message-ID: <2105635461.22689.1448634133183.JavaMail.zimbra@oav.net> Hi, Seems it was some icmpv6 neighbor solicitation multicast storm. Got about > 800kpps this morning for about 4hours... Strange there is no rate limits somewhere... Regards From Byrn.Baker at charter.com Fri Nov 27 14:31:36 2015 From: Byrn.Baker at charter.com (Baker, Byrn) Date: Fri, 27 Nov 2015 08:31:36 -0600 Subject: Anyone having issues with Equinix IX out of Ashburn? In-Reply-To: <56586503.7090108@hibernianetworks.com> References: <7711a4914ac641c9b3d4357bee8e5468@exchange.broadaspect.local> <56586503.7090108@hibernianetworks.com> Message-ID: All of our IX peers dropped around 11 UTC. All recovered about 30 mins later. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jeroen Wunnink Sent: Friday, November 27, 2015 8:13 AM To: nanog at nanog.org Subject: Re: Anyone having issues with Equinix IX out of Ashburn? We've seen issues as well. We've just started to turn the exchange up again and check if it's fixed. On 27/11/15 15:03, Nick Ellermann wrote: > At about 4:15 am eastern we lost our bgp peers on the Ashburn IX at Equinix. Equinix is not responding to our support requests, either they are overloaded with support requests or all on holiday. Curious if others know if there are known issues at this site or is it just us. > > > Sincerely, > Nick Ellermann - CTO & VP Cloud Services BroadAspect > > E: nellermann at broadaspect.com > P: 703-297-4639 > F: 703-996-4443 > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. > -- Jeroen Wunnink IP Engineering Manager - Hibernia Networks Main numbers (Ext: 1011): USA +1.908.516.4200 | UK +44.1704.322.300 Netherlands +31.208.200.622 | 24/7 IP NOC Phone: +31.20.82.00.623 jeroen.wunnink at hibernianetworks.com www.hibernianetworks.com This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From johnstong at westmancom.com Fri Nov 27 16:09:15 2015 From: johnstong at westmancom.com (Graham Johnston) Date: Fri, 27 Nov 2015 16:09:15 +0000 Subject: Anyone having issues with Equinix IX out of Ashburn? In-Reply-To: References: <7711a4914ac641c9b3d4357bee8e5468@exchange.broadaspect.local> <56586503.7090108@hibernianetworks.com> Message-ID: <49EE1A35457387418410F97564A3752B01369393EE@MSG6.westman.int> I think we saw an issue like this a few weeks back in Chicago. It took them longer than I would have expected to fix it, later they ultimately ended up upgrading software I think. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com ??think green; don't print this email. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Baker, Byrn Sent: Friday, November 27, 2015 8:32 AM To: nanog at nanog.org Subject: RE: Anyone having issues with Equinix IX out of Ashburn? All of our IX peers dropped around 11 UTC. All recovered about 30 mins later. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jeroen Wunnink Sent: Friday, November 27, 2015 8:13 AM To: nanog at nanog.org Subject: Re: Anyone having issues with Equinix IX out of Ashburn? We've seen issues as well. We've just started to turn the exchange up again and check if it's fixed. On 27/11/15 15:03, Nick Ellermann wrote: > At about 4:15 am eastern we lost our bgp peers on the Ashburn IX at Equinix. Equinix is not responding to our support requests, either they are overloaded with support requests or all on holiday. Curious if others know if there are known issues at this site or is it just us. > > > Sincerely, > Nick Ellermann - CTO & VP Cloud Services BroadAspect > > E: nellermann at broadaspect.com > P: 703-297-4639 > F: 703-996-4443 > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. > -- Jeroen Wunnink IP Engineering Manager - Hibernia Networks Main numbers (Ext: 1011): USA +1.908.516.4200 | UK +44.1704.322.300 Netherlands +31.208.200.622 | 24/7 IP NOC Phone: +31.20.82.00.623 jeroen.wunnink at hibernianetworks.com www.hibernianetworks.com This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From cscora at apnic.net Fri Nov 27 18:11:16 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 Nov 2015 04:11:16 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201511271811.tARIBGsc000309@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, SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. 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 28 Nov, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 571471 Prefixes after maximum aggregation (per Origin AS): 212838 Deaggregation factor: 2.69 Unique aggregates announced (without unneeded subnets): 279928 Total ASes present in the Internet Routing Table: 52120 Prefixes per ASN: 10.96 Origin-only ASes present in the Internet Routing Table: 36663 Origin ASes announcing only one prefix: 15952 Transit ASes present in the Internet Routing Table: 6370 Transit-only ASes present in the Internet Routing Table: 165 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 35 Max AS path prepend of ASN ( 55644) 31 Prefixes from unregistered ASNs in the Routing Table: 1036 Unregistered ASNs in the Routing Table: 371 Number of 32-bit ASNs allocated by the RIRs: 11884 Number of 32-bit ASNs visible in the Routing Table: 9087 Prefixes from 32-bit ASNs in the Routing Table: 34497 Number of bogon 32-bit ASNs visible in the Routing Table: 15 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 415 Number of addresses announced to Internet: 2802174912 Equivalent to 167 /8s, 5 /16s and 203 /24s Percentage of available address space announced: 75.7 Percentage of allocated address space announced: 75.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.8 Total number of prefixes smaller than registry allocations: 188217 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 144685 Total APNIC prefixes after maximum aggregation: 40283 APNIC Deaggregation factor: 3.59 Prefixes being announced from the APNIC address blocks: 152898 Unique aggregates announced from the APNIC address blocks: 61972 APNIC Region origin ASes present in the Internet Routing Table: 5115 APNIC Prefixes per ASN: 29.89 APNIC Region origin ASes announcing only one prefix: 1194 APNIC Region transit ASes present in the Internet Routing Table: 888 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 34 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1726 Number of APNIC addresses announced to Internet: 756128128 Equivalent to 45 /8s, 17 /16s and 153 /24s Percentage of available APNIC address space announced: 88.4 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 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: 180739 Total ARIN prefixes after maximum aggregation: 89055 ARIN Deaggregation factor: 2.03 Prefixes being announced from the ARIN address blocks: 184168 Unique aggregates announced from the ARIN address blocks: 87343 ARIN Region origin ASes present in the Internet Routing Table: 16513 ARIN Prefixes per ASN: 11.15 ARIN Region origin ASes announcing only one prefix: 5978 ARIN Region transit ASes present in the Internet Routing Table: 1718 Average ARIN Region AS path length visible: 3.7 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 845 Number of ARIN addresses announced to Internet: 1102537920 Equivalent to 65 /8s, 183 /16s and 100 /24s Percentage of available ARIN address space announced: 58.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-395164 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: 137548 Total RIPE prefixes after maximum aggregation: 68566 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 145239 Unique aggregates announced from the RIPE address blocks: 90032 RIPE Region origin ASes present in the Internet Routing Table: 18019 RIPE Prefixes per ASN: 8.06 RIPE Region origin ASes announcing only one prefix: 7988 RIPE Region transit ASes present in the Internet Routing Table: 2978 Average RIPE Region AS path length visible: 4.8 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 4243 Number of RIPE addresses announced to Internet: 701837696 Equivalent to 41 /8s, 213 /16s and 49 /24s Percentage of available RIPE address space announced: 102.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 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: 60552 Total LACNIC prefixes after maximum aggregation: 11790 LACNIC Deaggregation factor: 5.14 Prefixes being announced from the LACNIC address blocks: 73085 Unique aggregates announced from the LACNIC address blocks: 34042 LACNIC Region origin ASes present in the Internet Routing Table: 2463 LACNIC Prefixes per ASN: 29.67 LACNIC Region origin ASes announcing only one prefix: 600 LACNIC Region transit ASes present in the Internet Routing Table: 540 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 22 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2100 Number of LACNIC addresses announced to Internet: 170322432 Equivalent to 10 /8s, 38 /16s and 234 /24s Percentage of available LACNIC address space announced: 101.5 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + 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: 13364 Total AfriNIC prefixes after maximum aggregation: 3103 AfriNIC Deaggregation factor: 4.31 Prefixes being announced from the AfriNIC address blocks: 15666 Unique aggregates announced from the AfriNIC address blocks: 6188 AfriNIC Region origin ASes present in the Internet Routing Table: 731 AfriNIC Prefixes per ASN: 21.43 AfriNIC Region origin ASes announcing only one prefix: 192 AfriNIC Region transit ASes present in the Internet Routing Table: 169 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 19 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 173 Number of AfriNIC addresses announced to Internet: 70993920 Equivalent to 4 /8s, 59 /16s and 72 /24s Percentage of available AfriNIC address space announced: 70.5 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 4538 5599 4192 76 China Education and Research 7545 3025 343 151 TPG Telecom Limited 4766 2996 11134 987 Korea Telecom 17974 2721 914 96 PT Telekomunikasi Indonesia 4755 2066 431 231 TATA Communications formerly 9829 2034 1408 299 National Internet Backbone 9808 1671 8639 18 Guangdong Mobile Communicatio 4808 1560 2269 497 CNCGROUP IP network China169 9583 1499 120 560 Sify Limited 9498 1403 335 112 BHARTI Airtel Ltd. 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 22773 3245 2964 143 Cox Communications Inc. 3356 2583 10693 531 Level 3 Communications, Inc. 6389 2509 3687 42 BellSouth.net Inc. 18566 2213 394 277 MegaPath Corporation 20115 1887 1897 400 Charter Communications 6983 1699 849 238 EarthLink, Inc. 30036 1648 329 361 Mediacom Communications Corp 4323 1578 1013 395 tw telecom holdings, inc. 209 1482 4326 1233 Qwest Communications Company, 701 1392 11415 665 MCI Communications Services, 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 39891 2473 129 7 SaudiNet, Saudi Telecom Compa 20940 2232 886 1607 Akamai International B.V. 34984 1918 320 406 TELLCOM ILETISIM HIZMETLERI A 8402 1199 544 15 OJSC "Vimpelcom" 8551 1086 376 53 Bezeq International-Ltd 13188 1074 97 79 TOV "Bank-Inform" 12479 1044 966 82 France Telecom Espana SA 31148 1035 47 41 Freenet Ltd. 9198 963 349 25 JSC Kazakhtelecom 6830 892 2706 466 Liberty Global Operations B.V 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 10620 3400 540 156 Telmex Colombia S.A. 8151 2107 3342 498 Uninet S.A. de C.V. 7303 1573 940 235 Telecom Argentina S.A. 6503 1381 437 57 Axtel, S.A.B. de C.V. 28573 1332 2175 119 NET Servi?os de Comunica??o S 11830 1094 364 24 Instituto Costarricense de El 6147 1042 376 34 Telefonica del Peru S.A.A. 26615 1004 2325 34 Tim Celular S.A. 7738 993 1882 41 Telemar Norte Leste S.A. 3816 962 450 185 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 8452 1144 1470 14 TE-AS 24863 1087 409 38 Link Egypt (Link.NET) 37611 575 39 41 Afrihost-Brevis Computer Serv 36903 522 263 102 Office National des Postes et 36992 438 1229 32 ETISALAT MISR 37492 324 192 74 Orange Tunisie 29571 244 21 11 Cote d'Ivoire Telecom 24835 234 146 12 Vodafone Data 3741 221 837 183 Internet Solutions 15706 171 32 6 Sudatel (Sudan Telecom Co. Lt 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 4538 5599 4192 76 China Education and Research 10620 3400 540 156 Telmex Colombia S.A. 22773 3245 2964 143 Cox Communications Inc. 7545 3025 343 151 TPG Telecom Limited 4766 2996 11134 987 Korea Telecom 17974 2721 914 96 PT Telekomunikasi Indonesia 3356 2583 10693 531 Level 3 Communications, Inc. 6389 2509 3687 42 BellSouth.net Inc. 39891 2473 129 7 SaudiNet, Saudi Telecom Compa 20940 2232 886 1607 Akamai International B.V. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 3400 3244 Telmex Colombia S.A. 22773 3245 3102 Cox Communications Inc. 7545 3025 2874 TPG Telecom Limited 17974 2721 2625 PT Telekomunikasi Indonesia 6389 2509 2467 BellSouth.net Inc. 39891 2473 2466 SaudiNet, Saudi Telecom Compa 3356 2583 2052 Level 3 Communications, Inc. 4766 2996 2009 Korea Telecom 18566 2213 1936 MegaPath Corporation 4755 2066 1835 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 8655 UNALLOCATED 1.3.3.0/24 4134 No.31,Jin-rong Stree 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 47092 UNALLOCATED 8.8.204.0/24 16410 The Reynolds and Rey 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.124.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 3356 Level 3 Communicatio 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 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.254.0/24 9583 Sify Limited Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 23.249.144.0/21 40430 colo4jax, LLC 23.249.152.0/21 40430 colo4jax, LLC 27.100.7.0/24 56096 >>UNKNOWN<< 31.170.96.0/23 23456 32bit Transition AS 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.46.8.0/23 13768 Peer 1 Network (USA) Inc. 37.46.10.0/23 36351 SoftLayer Technologies Inc. 37.46.14.0/24 36351 SoftLayer Technologies Inc. Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:11 /10:36 /11:98 /12:263 /13:506 /14:1009 /15:1763 /16:12924 /17:7365 /18:12572 /19:25693 /20:37644 /21:39814 /22:62856 /23:54554 /24:312786 /25:549 /26:566 /27:384 /28:16 /29:16 /30:9 /31:0 /32:21 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2437 3245 Cox Communications Inc. 39891 2432 2473 SaudiNet, Saudi Telecom Compa 18566 2115 2213 MegaPath Corporation 6389 1553 2509 BellSouth.net Inc. 30036 1465 1648 Mediacom Communications Corp 6983 1346 1699 EarthLink, Inc. 10620 1279 3400 Telmex Colombia S.A. 34984 1206 1918 TELLCOM ILETISIM HIZMETLERI A 11492 1132 1217 CABLE ONE, INC. 31148 954 1035 Freenet Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1649 2:701 4:100 5:1991 6:25 8:1414 12:1805 13:27 14:1560 15:23 16:2 17:57 18:19 20:48 23:1317 24:1736 27:2142 31:1685 32:54 33:2 34:4 35:5 36:185 37:2274 38:1115 39:20 40:74 41:2926 42:364 43:1616 44:36 45:1526 46:2325 47:63 49:1038 50:815 52:33 54:93 55:8 56:8 57:44 58:1406 59:826 60:509 61:1765 62:1404 63:1906 64:4402 65:2200 66:4040 67:2126 68:1085 69:3269 70:1018 71:463 72:1991 74:2561 75:357 76:416 77:1393 78:1253 79:801 80:1344 81:1348 82:838 83:648 84:790 85:1482 86:459 87:1044 88:538 89:1930 90:168 91:5992 92:860 93:2286 94:2184 95:2249 96:474 97:352 98:910 99:47 100:80 101:849 103:8938 104:2185 105:73 106:363 107:1104 108:632 109:2105 110:1225 111:1533 112:866 113:1107 114:874 115:1496 116:1482 117:1185 118:1974 119:1495 120:502 121:1161 122:2253 123:1870 124:1562 125:1734 128:701 129:368 130:387 131:1260 132:593 133:165 134:439 135:119 136:345 137:312 138:1484 139:191 140:246 141:455 142:637 143:699 144:571 145:148 146:787 147:608 148:1286 149:440 150:621 151:810 152:568 153:266 154:471 155:909 156:434 157:444 158:342 159:1055 160:409 161:680 162:2213 163:494 164:705 165:1084 166:312 167:885 168:1311 169:548 170:1505 171:261 172:356 173:1551 174:720 175:752 176:1499 177:4008 178:2332 179:1050 180:2033 181:1622 182:1865 183:666 184:771 185:4976 186:3037 187:1876 188:2065 189:1694 190:7522 191:1212 192:8685 193:5711 194:4304 195:3690 196:2251 197:1214 198:5496 199:5551 200:6677 201:3508 202:9879 203:9287 204:4566 205:2744 206:3024 207:3009 208:4000 209:3971 210:3746 211:2008 212:2627 213:2178 214:830 215:72 216:5775 217:1881 218:741 219:544 220:1624 221:807 222:640 223:860 End of report From frnkblk at iname.com Fri Nov 27 18:27:54 2015 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 27 Nov 2015 12:27:54 -0600 Subject: Anyone having issues with Equinix IX out of Ashburn? In-Reply-To: <2105635461.22689.1448634133183.JavaMail.zimbra@oav.net> References: <7711a4914ac641c9b3d4357bee8e5468@exchange.broadaspect.local> <56586503.7090108@hibernianetworks.com> <2105635461.22689.1448634133183.JavaMail.zimbra@oav.net> Message-ID: <002b01d12941$54da70f0$fe8f52d0$@iname.com> Storm caused by an L2 loop, malicious attack, bug in router code, or something else? Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Xavier Beaudouin Sent: Friday, November 27, 2015 8:22 AM To: nanog at nanog.org Subject: Re: Anyone having issues with Equinix IX out of Ashburn? Hi, Seems it was some icmpv6 neighbor solicitation multicast storm. Got about > 800kpps this morning for about 4hours... Strange there is no rate limits somewhere... Regards From mr.jonas.bjork at me.com Sat Nov 28 04:55:01 2015 From: mr.jonas.bjork at me.com (Jonas Bjork) Date: Sat, 28 Nov 2015 05:55:01 +0100 Subject: EoMPLS vlan rewrite between brands; possibly new bug in Cisco IOS 15 In-Reply-To: References: Message-ID: Dear Mr. Bensley, The platform is Cisco 7600 on side A and HP A5500-HI on side B. I am currently running IOS v12.2-33.SRE5 and I'm trying to upgrade to v15.3-3.S6. In the current version the VC type is Eth VLAN and I have tried all different options on the HP side with no success. On the Cisco side I don't know if there is anything I can do - the negotiation seems to take place without any possible user interference. It's true that I can terminate the tunnel elsewhere and switch the traffic using layer 2 but I don't want to have any "ugly" solutions in the network. Everything works fine even though I rewrite the vlan id (and that is essential for my solution) at the moment and it bothers me that an IOS upgrade triggers this bug. The bug is submitted (against Juniper) as previously mentioned in this thread but Cisco won't do anything about it. Best regards, Jonas Bjork Network Nerd > On 16 Nov 2015, at 10:21, James Bensley wrote: > > On 15 November 2015 at 01:31, Jonas Bjork > wrote: >> Dear Mr. Jeff, >> >> Thank you for your reply. Below is the complete output in question (l2 is short for l2transport). >> You are mentioning platform capabilities and that the default might have changed. How do I alter this? >> >> pe#sh mpls l2 vc 42 d >> Local interface: Po190.42 up, line protocol up, Eth VLAN 42 up >> Destination address: X.X.1.89, VC ID: 42, VC status: down >> Last error: Imposition VLAN rewrite capability mismatch with peer >> Output interface: none, imposed label stack {} >> Preferred path: not configured >> Default path: no route >> No adjacency >> Create time: 00:00:59, last status change time: 00:31:40 >> Last label FSM state change time: 00:00:18 >> Last peer autosense occurred at: 00:00:18 >> Signaling protocol: LDP, peer X.X.1.89:0 up >> Targeted Hello: X.X.0.2(LDP Id) -> X.X.1.89, LDP is UP >> Graceful restart: not configured and not enabled >> Non stop routing: not configured and not enabled >> Status TLV support (local/remote) : enabled/not supported >> LDP route watch : enabled >> Label/status state machine : remote invalid, LruRnd >> Last local dataplane status rcvd: No fault >> Last BFD dataplane status rcvd: Not sent >> Last BFD peer monitor status rcvd: No fault >> Last local AC circuit status rcvd: No fault >> Last local AC circuit status sent: DOWN PW(rx/tx faults) >> Last local PW i/f circ status rcvd: No fault >> Last local LDP TLV status sent: No fault >> Last remote LDP TLV status rcvd: Not sent >> Last remote LDP ADJ status rcvd: No fault >> MPLS VC labels: local 242, remote 1199 >> Group ID: local 0, remote 0 >> MTU: local 9216, remote 9216 >> Remote interface description: >> Remote VLAN id: 42 >> Sequencing: receive disabled, send disabled >> Control Word: Off (configured: autosense) >> SSO Descriptor: X.X.1.89/42, local label: 242 >> Dataplane: >> SSM segment/switch IDs: 0/0 (used), PWID: 142 >> VC statistics: >> transit packet totals: receive 0, send 0 >> transit byte totals: receive 0, send 0 >> transit packet drops: receive 0, seq error 0, send 0 >> pe# >> >> Anyone else: feel free to join in. Maybe we have any L2VC/PW ninjas watching. >> >> Best regards, >> Jonas Bjork > > Hi Jonas, > > In that output you have "Remote VLAN id: 42" -What is the local VLAN > ID on your Cisco PE? Do you need to VLAN rewrite here? > > Since you using different VLANs at each end, can you build the > pseudowire at a point in the network stack where the VLAN tag has been > popped off already and transport the frames untagged, so they will be > pushed on again at the other end? (Is this is a VC type 4 pseudowire, > check with "show mpls l2transport binding 42", if so, a dummy VLAN > should be pushed on and popped off transparently if all hardware in > use supports it). > > I don't know HP but with the Cisco 7600 for example, if it's VLAN 50 > then you could add "interface vlan 50; xconnecy X.X.1.89 42 encaps > mpls", if your hardware supports that. Or use mux-uni; "int gix/x.y; > encaps dot1q y; xconnecy X.X.1.89 42 encaps mpls". Then add vice versa > on the HP kit. > > What IOS have you tried to upgrade to, 15.2(4)S4a? If this is a VC > type 4 pseudowire and either the HP or Cisco isn't supporting > inserting a dummy VLAN tag, why is this a VC type 4 pseudowire? The > VLAN re-write I guess. Certainly in IOS 15.3 (so probably also in 15.2 > but I'm not 100% certain of that) Cisco IOS should be defaulting to VC > type 5 unless the other end negotiates down to VC type 4. VC type 5 in > IOS supports transporting of untagged, tagged and double tagged > frames, I don't think there is any functionality in VC type 5 that > wasn't in older type 4's so I'd try and work out why your devices are > negotiating type 4 and maybe try to fix that, or as above, transport > untagged. > > Cheers, > James. From mkamal at noor.net Sat Nov 28 12:52:39 2015 From: mkamal at noor.net (Mohamed Kamal) Date: Sat, 28 Nov 2015 14:52:39 +0200 Subject: EoMPLS vlan rewrite between brands; possibly new bug in Cisco IOS 15 In-Reply-To: References: Message-ID: <5659A397.8090909@noor.net> Jonas, If the problem is in VC type 4 signalling, then switch to Ethernet interworking or VC type 5. It will work in your case, and VLAN rewrite operation will be done at the AC points. I don't know if you already has this configured or not, but you have to use psudowire-class templates with the "interworking ethernet" underneath. Mohamed Kamal On 11/28/2015 6:55 AM, Jonas Bjork wrote: > Dear Mr. Bensley, > > The platform is Cisco 7600 on side A and HP A5500-HI on side B. I am currently running IOS v12.2-33.SRE5 and I'm trying to upgrade to v15.3-3.S6. > In the current version the VC type is Eth VLAN and I have tried all different options on the HP side with no success. On the Cisco side I don't know if there is anything I can do - the negotiation seems to take place without any possible user interference. > > It's true that I can terminate the tunnel elsewhere and switch the traffic using layer 2 but I don't want to have any "ugly" solutions in the network. Everything works fine even though I rewrite the vlan id (and that is essential for my solution) at the moment and it bothers me that an IOS upgrade triggers this bug. The bug is submitted (against Juniper) as previously mentioned in this thread but Cisco won't do anything about it. > > Best regards, > > Jonas Bjork > Network Nerd > >> On 16 Nov 2015, at 10:21, James Bensley wrote: >> >> On 15 November 2015 at 01:31, Jonas Bjork > wrote: >>> Dear Mr. Jeff, >>> >>> Thank you for your reply. Below is the complete output in question (l2 is short for l2transport). >>> You are mentioning platform capabilities and that the default might have changed. How do I alter this? >>> >>> pe#sh mpls l2 vc 42 d >>> Local interface: Po190.42 up, line protocol up, Eth VLAN 42 up >>> Destination address: X.X.1.89, VC ID: 42, VC status: down >>> Last error: Imposition VLAN rewrite capability mismatch with peer >>> Output interface: none, imposed label stack {} >>> Preferred path: not configured >>> Default path: no route >>> No adjacency >>> Create time: 00:00:59, last status change time: 00:31:40 >>> Last label FSM state change time: 00:00:18 >>> Last peer autosense occurred at: 00:00:18 >>> Signaling protocol: LDP, peer X.X.1.89:0 up >>> Targeted Hello: X.X.0.2(LDP Id) -> X.X.1.89, LDP is UP >>> Graceful restart: not configured and not enabled >>> Non stop routing: not configured and not enabled >>> Status TLV support (local/remote) : enabled/not supported >>> LDP route watch : enabled >>> Label/status state machine : remote invalid, LruRnd >>> Last local dataplane status rcvd: No fault >>> Last BFD dataplane status rcvd: Not sent >>> Last BFD peer monitor status rcvd: No fault >>> Last local AC circuit status rcvd: No fault >>> Last local AC circuit status sent: DOWN PW(rx/tx faults) >>> Last local PW i/f circ status rcvd: No fault >>> Last local LDP TLV status sent: No fault >>> Last remote LDP TLV status rcvd: Not sent >>> Last remote LDP ADJ status rcvd: No fault >>> MPLS VC labels: local 242, remote 1199 >>> Group ID: local 0, remote 0 >>> MTU: local 9216, remote 9216 >>> Remote interface description: >>> Remote VLAN id: 42 >>> Sequencing: receive disabled, send disabled >>> Control Word: Off (configured: autosense) >>> SSO Descriptor: X.X.1.89/42, local label: 242 >>> Dataplane: >>> SSM segment/switch IDs: 0/0 (used), PWID: 142 >>> VC statistics: >>> transit packet totals: receive 0, send 0 >>> transit byte totals: receive 0, send 0 >>> transit packet drops: receive 0, seq error 0, send 0 >>> pe# >>> >>> Anyone else: feel free to join in. Maybe we have any L2VC/PW ninjas watching. >>> >>> Best regards, >>> Jonas Bjork >> Hi Jonas, >> >> In that output you have "Remote VLAN id: 42" -What is the local VLAN >> ID on your Cisco PE? Do you need to VLAN rewrite here? >> >> Since you using different VLANs at each end, can you build the >> pseudowire at a point in the network stack where the VLAN tag has been >> popped off already and transport the frames untagged, so they will be >> pushed on again at the other end? (Is this is a VC type 4 pseudowire, >> check with "show mpls l2transport binding 42", if so, a dummy VLAN >> should be pushed on and popped off transparently if all hardware in >> use supports it). >> >> I don't know HP but with the Cisco 7600 for example, if it's VLAN 50 >> then you could add "interface vlan 50; xconnecy X.X.1.89 42 encaps >> mpls", if your hardware supports that. Or use mux-uni; "int gix/x.y; >> encaps dot1q y; xconnecy X.X.1.89 42 encaps mpls". Then add vice versa >> on the HP kit. >> >> What IOS have you tried to upgrade to, 15.2(4)S4a? If this is a VC >> type 4 pseudowire and either the HP or Cisco isn't supporting >> inserting a dummy VLAN tag, why is this a VC type 4 pseudowire? The >> VLAN re-write I guess. Certainly in IOS 15.3 (so probably also in 15.2 >> but I'm not 100% certain of that) Cisco IOS should be defaulting to VC >> type 5 unless the other end negotiates down to VC type 4. VC type 5 in >> IOS supports transporting of untagged, tagged and double tagged >> frames, I don't think there is any functionality in VC type 5 that >> wasn't in older type 4's so I'd try and work out why your devices are >> negotiating type 4 and maybe try to fix that, or as above, transport >> untagged. >> >> Cheers, >> James. > From mpetach at netflight.com Sat Nov 28 15:56:43 2015 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 28 Nov 2015 07:56:43 -0800 Subject: Bluehost.com In-Reply-To: <0bd301d127ed$737e3b40$5a7ab1c0$@com> References: <20151125180440.GA20559@nic.fr> <6f661213d9ce49dbee4721ab2423140a.squirrel@66.201.44.180> <62b3e90c9574776b8a43974eb72f3cd8.squirrel@66.201.44.180> <7b66dbeb53965d5e9a48887196e9ed42.squirrel@66.201.44.180> <0bd301d127ed$737e3b40$5a7ab1c0$@com> Message-ID: On Wed, Nov 25, 2015 at 5:54 PM, Kiriki Delany wrote: > [...] > > Bottom line, is the industry needs to be increasing value, because the flip > side.... working for no profit, surviving off investment only... there's no > end-game. You see this cycle time and time again as market share is grabbed, > then underperforming companies are rolled up. In this process value is > destroyed. > > Ultimately this is also why it's extremely damaging for investors to > constantly invest in companies that don't make a profit, and don't provide a > successful economical model for the services/products provided. These > companies largely live on investor money, lose money, and in their wake > destroy value for the entire industry. Of course the end-game for the > investors is to make money... I'm always surprised how strong > investment/gambles are for non-profitable companies. I guess there is no end > to those with too much money that have to place that money somewhere. As the > rich get richer, there will only be more dumb money cheapening the value > proposition. After all, who needs value when you have willing investors. I'm confused. If these companies largely live on investor money, lose money, and destroy value...how is it that a scant two sentences later, the rich are getting richer, and there is _more_ dumb money? I would posit the rich get richer because they *do* see value in the investments they make. That is, value is being created in these deals...just not for everyone. Matt From bob at FiberInternetCenter.com Sat Nov 28 16:13:00 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Sat, 28 Nov 2015 08:13:00 -0800 Subject: Bluehost.com In-Reply-To: References: <20151125180440.GA20559@nic.fr> <6f661213d9ce49dbee4721ab2423140a.squirrel@66.201.44.180> <62b3e90c9574776b8a43974eb72f3cd8.squirrel@66.201.44.180> <7b66dbeb53965d5e9a48887196e9ed42.squirrel@66.201.44.180> <0bd301d127ed$737e3b40$5a7ab1c0$@com> Message-ID: <2c1bbf2ce7573cc9d1e6867b630126d3.squirrel@66.201.44.180> I think he means to say the rich get richer on the other side of the investment by playing the shorting and the buying of stock in the gambling marketplace. As the stock itself can create a new currency.... so they make more money playing with that than the actually investment. They are on the inside hence the saying the rich get richer. Thank You Bob Evans CTO > On Wed, Nov 25, 2015 at 5:54 PM, Kiriki Delany > wrote: >> [...] >> >> Bottom line, is the industry needs to be increasing value, because the >> flip >> side.... working for no profit, surviving off investment only... there's >> no >> end-game. You see this cycle time and time again as market share is >> grabbed, >> then underperforming companies are rolled up. In this process value is >> destroyed. >> >> Ultimately this is also why it's extremely damaging for investors to >> constantly invest in companies that don't make a profit, and don't >> provide a >> successful economical model for the services/products provided. These >> companies largely live on investor money, lose money, and in their wake >> destroy value for the entire industry. Of course the end-game for the >> investors is to make money... I'm always surprised how strong >> investment/gambles are for non-profitable companies. I guess there is no >> end >> to those with too much money that have to place that money somewhere. As >> the >> rich get richer, there will only be more dumb money cheapening the value >> proposition. After all, who needs value when you have willing investors. > > > I'm confused. If these companies largely live on investor money, > lose money, and destroy value...how is it that a scant two sentences > later, the rich are getting richer, and there is _more_ dumb money? > > I would posit the rich get richer because they *do* > see value in the investments they make. That is, > value is being created in these deals...just not for > everyone. > > Matt > From kmedcalf at dessus.com Sat Nov 28 16:42:04 2015 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 28 Nov 2015 09:42:04 -0700 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: Message-ID: <648baa7ff7bbe74a846d12c5cb4c950e@mail.dessus.com> Obviously this is designed so that the carrier knows what traffic to "disregard" in their feed to the NSA ... That is the sole purpose of it. > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Owen DeLong > Sent: Friday, 20 November, 2015 14:50 > To: Steve Mikulasik > Cc: nanog at nanog.org > Subject: Re: Binge On! - And So This is Net Neutrality? > > It?s a full page of standards in a relatively large font with decent > spacing. > > Given that bluetooth is several hundred pages, I?d say this is pretty > reasonable. > > Having read through the page, I don?t see anything onerous in the > requirements. In fact, it looks to me > like the bare minimum of reasonable and an expression by T-Mo of a > willingness to expend a fair amount > of effort to integrate content providers. > > I don?t see anything here that hurts net neutrality and I applaud this as > actually being a potential boon > to consumers and a potentially good model of how to implement ZRB in a > net-neutral way going > forward. > > Owen > > > On Nov 20, 2015, at 09:03 , Steve Mikulasik > wrote: > > > > That is much better than I thought. Although, I don't think the person > who wrote this understands what UDP is. > > > > "Use of technology protocols that are demonstrated to prevent video > stream detection, such as User Datagram Protocol ?UDP? on any platform > will exclude video streams from that content provider" > > > > > > -----Original Message----- > > From: Ian Smith [mailto:I.Smith at F5.com] > > Sent: Friday, November 20, 2015 9:52 AM > > To: Steve Mikulasik ; Shane Ronan > ; nanog at nanog.org > > Subject: RE: Binge On! - And So This is Net Neutrality? > > > > http://www.t-mobile.com/content/dam/tmo/en-g/pdf/BingeOn-Video- > Technical-Criteria-November-2015.pdf > > > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Steve > Mikulasik > > Sent: Friday, November 20, 2015 11:37 AM > > To: Shane Ronan ; nanog at nanog.org > > Subject: RE: Binge On! - And So This is Net Neutrality? > > > > What are these technical requirements? I feel like these would punish > small upstarts well helping protect large incumbent services from > competition. > > > > Even if you don't demand payment, you can still hurt the fairness of the > internet this way. > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Shane Ronan > > Sent: Friday, November 20, 2015 9:25 AM > > To: nanog at nanog.org > > Subject: Re: Binge On! - And So This is Net Neutrality? > > > > T-Mobile claims they are not accepting any payment from these content > providers for inclusion in Binge On. > > > > "Onstage today, Legere said any company can apply to join the Binge On > program. "Anyone who can meet our technical requirement, we?ll include," > > he said. "This is not a net neutrality problem." Legere pointed to the > fact that Binge On doesn't charge providers for inclusion and customers > don't pay to access it." > > http://www.theverge.com/2015/11/10/9704482/t-mobile-uncarrier-binge-on- > netflix-hbo-streaming > > > > > > On 11/20/15 10:45 AM, Jay Ashworth wrote: > >> According to: > >> > >> > >> http://www.engadget.com/2015/11/20/fcc-chairman-gives-t-mobiles-binge- > >> on-the-thumbs-up/ > >> > >> Chairman Wheeler thinks that T-mob's new "customers can get uncapped > >> media stream data, but only from the people we like" service called > >> Binge On is pro-competition. > >> > >> My take on this is that the service is *precisely* what Net Neutrality > >> was supposed to prevent -- carriers offering paid fast-lanes to > >> content providers -- and that this is anti-competitive to the sort of > >> "upstart YouTube" entities that NN was supposed to protect... > >> > >> and that *that* is the competition that NN was supposed to protect. > >> > >> And I just said the same thing two different ways. > >> > >> Cause does anyone here think that T-mob is giving those *carriers* > >> pride of place *for free*? > >> > >> Corporations don't - in my experience - give away lots of money out of > >> the goodness of their hearts. > >> > >> Cheers, > >> -- jr 'whacky weekend' a > > From kmedcalf at dessus.com Sat Nov 28 16:50:13 2015 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 28 Nov 2015 09:50:13 -0700 Subject: Binge On! - And So This is Net Neutrality? In-Reply-To: Message-ID: <4753e6ae87f46349a094fde68b6f42d9@mail.dessus.com> Why uncomfortable? How do you know this is not how the company executive that came up with the idea did so? (So that he or she could watch unlimited bestiality videos). > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of nanog- > isp at mail.com > Sent: Sunday, 22 November, 2015 16:30 > To: nanog at nanog.org > Subject: Re: Binge On! - And So This is Net Neutrality? > > So, which porn sites are zero rated? Uh, asking for a friend. > > (Would love to be a fly on the wall when those and other uncomfortable > requests to join come in.) > > Jared From mpetach at netflight.com Sat Nov 28 19:34:35 2015 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 28 Nov 2015 11:34:35 -0800 Subject: route converge time In-Reply-To: References: Message-ID: One thing I notice you don't mention is whether your BGP sessions to your upstream providers are direct or multi-hop eBGP. I know for a while some of the more bargain-basement providers were doing eBGP multi-hop feeds for full tables, which will definitely slow down convergence if the routers have to wait for hold timers to expire to flush routes, rather than being able to direct detect link state transitions. Matt On Sat, Nov 21, 2015 at 5:44 AM, Baldur Norddahl wrote: > Hi > > I got a network with two routers and two IP transit providers, each with > the full BGP table. Router A is connected to provider A and router B to > provider B. We use MPLS with a L3VPN with a VRF called "internet". > Everything happens inside that VRF. > > Now if I interrupt one of the IP transit circuits, the routers will take > several minutes to remove the now bad routes and move everything to the > remaining transit provider. This is very noticeable to the customers. I am > looking into ways to improve that. > > I added a default static route 0.0.0.0 to provider A on router A and did > the same to provider B on router B. This is supposed to be a trick that > allows the network to move packets before everything is fully converged. > Traffic might not leave the most optimal link, but it will be delivered. > > Say I take down the provider A link on router A. As I understand it, the > hardware will notice this right away and stop using the routes to provider > A. Router A might know about the default route on router B and send the > traffic to router B. However this is not much help, because on router B > there is no link that is down, so the hardware is unaware until the BGP > process is done updating the hardware tables. Which apparently can take > several minutes. > > My routers also have multipath support, but I am unsure if that is going to > be of any help. > > Anyone got any tricks or pointers to what can be done to optimize the > downtime in case of a IP transit link failure? Or the related case of one > my routers going down or the link between them going down (the traffic > would go a non-direct way instead if the direct link is down). > > Thanks, > > Baldur > From jeff.tantsura at ericsson.com Sat Nov 28 21:59:49 2015 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Sat, 28 Nov 2015 21:59:49 +0000 Subject: route converge time In-Reply-To: References: , Message-ID: <73E92557-9C53-409A-80D7-867192314850@ericsson.com> In that case multihop BFD (if supported on both sides) would really help. Regards, Jeff > On Nov 28, 2015, at 11:37 AM, Matthew Petach wrote: > > One thing I notice you don't mention is whether your > BGP sessions to your upstream providers are direct > or multi-hop eBGP. I know for a while some of the > more bargain-basement providers were doing eBGP > multi-hop feeds for full tables, which will definitely > slow down convergence if the routers have to wait > for hold timers to expire to flush routes, rather than > being able to direct detect link state transitions. > > Matt > > > On Sat, Nov 21, 2015 at 5:44 AM, Baldur Norddahl > wrote: >> Hi >> >> I got a network with two routers and two IP transit providers, each with >> the full BGP table. Router A is connected to provider A and router B to >> provider B. We use MPLS with a L3VPN with a VRF called "internet". >> Everything happens inside that VRF. >> >> Now if I interrupt one of the IP transit circuits, the routers will take >> several minutes to remove the now bad routes and move everything to the >> remaining transit provider. This is very noticeable to the customers. I am >> looking into ways to improve that. >> >> I added a default static route 0.0.0.0 to provider A on router A and did >> the same to provider B on router B. This is supposed to be a trick that >> allows the network to move packets before everything is fully converged. >> Traffic might not leave the most optimal link, but it will be delivered. >> >> Say I take down the provider A link on router A. As I understand it, the >> hardware will notice this right away and stop using the routes to provider >> A. Router A might know about the default route on router B and send the >> traffic to router B. However this is not much help, because on router B >> there is no link that is down, so the hardware is unaware until the BGP >> process is done updating the hardware tables. Which apparently can take >> several minutes. >> >> My routers also have multipath support, but I am unsure if that is going to >> be of any help. >> >> Anyone got any tricks or pointers to what can be done to optimize the >> downtime in case of a IP transit link failure? Or the related case of one >> my routers going down or the link between them going down (the traffic >> would go a non-direct way instead if the direct link is down). >> >> Thanks, >> >> Baldur >> From baldur.norddahl at gmail.com Sat Nov 28 23:36:11 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 29 Nov 2015 00:36:11 +0100 Subject: route converge time In-Reply-To: <73E92557-9C53-409A-80D7-867192314850@ericsson.com> References: <73E92557-9C53-409A-80D7-867192314850@ericsson.com> Message-ID: Hi The IP transit links are direct links (not multihop). It is my impression that a link down event is handled with no significant delay by the router that has the link. The problem is the other router, the one that has to go through the first router to access the link the went down. The transit links are not unstable and in fact they have never been down due to a fault. But we are a young network and still frequently have to change things while we build it out. There have been cases where I have had to take down the link for various reasons. There seems to be no way to do this without causing significant disruption to the network. Our routers are 2015 hardware. The spec has 2M IPv4 + 1M IPv6 routes in FIB and 10M routes in RIB. Route convergence time is specified as 15k routes/second. 8 GB ram on the route engines. Say transit T1 is connected to router R1 and transit T2 is connected to router R2. I believe the underlying problem is that due to MPLS L3VPN the next hop on R2 for routes out through T1 is not the transit provider router as usual. Instead it is the loopback IP of R1. This means that when T1 goes down, the next hop is still valid and R2 is unable to deactivate the invalid routes as a group operation due to invalid next hop. I am considering adding a loopback2 interface that has a trigger on the transit interface, such that a shutdown on loopback2 is triggered if the transit interface goes down. And then force next hop to be loopback2. That way our IGP will signal that the next hop is gone and that should invalidate all the routes as a group operation. Regards, Baldur From jj at anexia.at Sat Nov 28 23:46:01 2015 From: jj at anexia.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Sat, 28 Nov 2015 23:46:01 +0000 Subject: route converge time In-Reply-To: References: <73E92557-9C53-409A-80D7-867192314850@ericsson.com>, Message-ID: <3d66e387ba6145d395e6e6029605d0fd@anx-i-dag02.anx.local> Hi, Why you not simply shut down the session upfront (before you turn down the link)? Best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Original Message----- From: Baldur Norddahl [baldur.norddahl at gmail.com] Received: Sonntag, 29 Nov. 2015, 0:39 To: nanog at nanog.org [nanog at nanog.org] Subject: Re: route converge time Hi The IP transit links are direct links (not multihop). It is my impression that a link down event is handled with no significant delay by the router that has the link. The problem is the other router, the one that has to go through the first router to access the link the went down. The transit links are not unstable and in fact they have never been down due to a fault. But we are a young network and still frequently have to change things while we build it out. There have been cases where I have had to take down the link for various reasons. There seems to be no way to do this without causing significant disruption to the network. Our routers are 2015 hardware. The spec has 2M IPv4 + 1M IPv6 routes in FIB and 10M routes in RIB. Route convergence time is specified as 15k routes/second. 8 GB ram on the route engines. Say transit T1 is connected to router R1 and transit T2 is connected to router R2. I believe the underlying problem is that due to MPLS L3VPN the next hop on R2 for routes out through T1 is not the transit provider router as usual. Instead it is the loopback IP of R1. This means that when T1 goes down, the next hop is still valid and R2 is unable to deactivate the invalid routes as a group operation due to invalid next hop. I am considering adding a loopback2 interface that has a trigger on the transit interface, such that a shutdown on loopback2 is triggered if the transit interface goes down. And then force next hop to be loopback2. That way our IGP will signal that the next hop is gone and that should invalidate all the routes as a group operation. Regards, Baldur From mpetach at netflight.com Sun Nov 29 01:20:20 2015 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 28 Nov 2015 17:20:20 -0800 Subject: route converge time In-Reply-To: <3d66e387ba6145d395e6e6029605d0fd@anx-i-dag02.anx.local> References: <73E92557-9C53-409A-80D7-867192314850@ericsson.com> <3d66e387ba6145d395e6e6029605d0fd@anx-i-dag02.anx.local> Message-ID: Or, better yet, apply a REJECT-ALL type policy on the neighbor to deny all inbound/outbound prefixes; that way, you can keep the session up as long as possible, but gracefully bleed traffic off ahead of your work. Matt On Sat, Nov 28, 2015 at 3:46 PM, J?rgen Jaritsch wrote: > Hi, > > Why you not simply shut down the session upfront (before you turn down the link)? > > Best regards > > > J?rgen Jaritsch > Head of Network & Infrastructure > > ANEXIA Internetdienstleistungs GmbH > > Telefon: +43-5-0556-300 > Telefax: +43-5-0556-500 > > E-Mail: jj at anexia.at > Web: http://www.anexia.at > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > Gesch?ftsf?hrer: Alexander Windbichler > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > > > -----Original Message----- > From: Baldur Norddahl [baldur.norddahl at gmail.com] > Received: Sonntag, 29 Nov. 2015, 0:39 > To: nanog at nanog.org [nanog at nanog.org] > Subject: Re: route converge time > > Hi > > The IP transit links are direct links (not multihop). It is my impression > that a link down event is handled with no significant delay by the router > that has the link. The problem is the other router, the one that has to go > through the first router to access the link the went down. > > The transit links are not unstable and in fact they have never been down > due to a fault. But we are a young network and still frequently have to > change things while we build it out. There have been cases where I have had > to take down the link for various reasons. There seems to be no way to do > this without causing significant disruption to the network. > > Our routers are 2015 hardware. The spec has 2M IPv4 + 1M IPv6 routes in FIB > and 10M routes in RIB. Route convergence time is specified as 15k > routes/second. 8 GB ram on the route engines. > > Say transit T1 is connected to router R1 and transit T2 is connected to > router R2. > > I believe the underlying problem is that due to MPLS L3VPN the next hop on > R2 for routes out through T1 is not the transit provider router as usual. > Instead it is the loopback IP of R1. This means that when T1 goes down, the > next hop is still valid and R2 is unable to deactivate the invalid routes > as a group operation due to invalid next hop. > > I am considering adding a loopback2 interface that has a trigger on the > transit interface, such that a shutdown on loopback2 is triggered if the > transit interface goes down. And then force next hop to be loopback2. That > way our IGP will signal that the next hop is gone and that should > invalidate all the routes as a group operation. > > Regards, > > Baldur > From jj at anexia.at Sun Nov 29 03:45:28 2015 From: jj at anexia.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Sun, 29 Nov 2015 03:45:28 +0000 Subject: route converge time In-Reply-To: References: <73E92557-9C53-409A-80D7-867192314850@ericsson.com> <3d66e387ba6145d395e6e6029605d0fd@anx-i-dag02.anx.local>, Message-ID: Route update via new policy could be more cpu intensive than dropping prefixes caused by session shutdown. Best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Original Message----- From: Matthew Petach [mpetach at netflight.com] Received: Sonntag, 29 Nov. 2015, 2:21 CC: nanog at nanog.org [nanog at nanog.org] Subject: Re: route converge time Or, better yet, apply a REJECT-ALL type policy on the neighbor to deny all inbound/outbound prefixes; that way, you can keep the session up as long as possible, but gracefully bleed traffic off ahead of your work. Matt On Sat, Nov 28, 2015 at 3:46 PM, J?rgen Jaritsch wrote: > Hi, > > Why you not simply shut down the session upfront (before you turn down the link)? > > Best regards > > > J?rgen Jaritsch > Head of Network & Infrastructure > > ANEXIA Internetdienstleistungs GmbH > > Telefon: +43-5-0556-300 > Telefax: +43-5-0556-500 > > E-Mail: jj at anexia.at > Web: http://www.anexia.at > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > Gesch?ftsf?hrer: Alexander Windbichler > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > > > -----Original Message----- > From: Baldur Norddahl [baldur.norddahl at gmail.com] > Received: Sonntag, 29 Nov. 2015, 0:39 > To: nanog at nanog.org [nanog at nanog.org] > Subject: Re: route converge time > > Hi > > The IP transit links are direct links (not multihop). It is my impression > that a link down event is handled with no significant delay by the router > that has the link. The problem is the other router, the one that has to go > through the first router to access the link the went down. > > The transit links are not unstable and in fact they have never been down > due to a fault. But we are a young network and still frequently have to > change things while we build it out. There have been cases where I have had > to take down the link for various reasons. There seems to be no way to do > this without causing significant disruption to the network. > > Our routers are 2015 hardware. The spec has 2M IPv4 + 1M IPv6 routes in FIB > and 10M routes in RIB. Route convergence time is specified as 15k > routes/second. 8 GB ram on the route engines. > > Say transit T1 is connected to router R1 and transit T2 is connected to > router R2. > > I believe the underlying problem is that due to MPLS L3VPN the next hop on > R2 for routes out through T1 is not the transit provider router as usual. > Instead it is the loopback IP of R1. This means that when T1 goes down, the > next hop is still valid and R2 is unable to deactivate the invalid routes > as a group operation due to invalid next hop. > > I am considering adding a loopback2 interface that has a trigger on the > transit interface, such that a shutdown on loopback2 is triggered if the > transit interface goes down. And then force next hop to be loopback2. That > way our IGP will signal that the next hop is gone and that should > invalidate all the routes as a group operation. > > Regards, > > Baldur > From bill at herrin.us Sun Nov 29 04:01:24 2015 From: bill at herrin.us (William Herrin) Date: Sat, 28 Nov 2015 23:01:24 -0500 Subject: route converge time In-Reply-To: References: <73E92557-9C53-409A-80D7-867192314850@ericsson.com> <3d66e387ba6145d395e6e6029605d0fd@anx-i-dag02.anx.local> Message-ID: On Sat, Nov 28, 2015 at 10:45 PM, J?rgen Jaritsch wrote: >> From: Matthew Petach [mpetach at netflight.com] >> >> Or, better yet, apply a REJECT-ALL type policy >> on the neighbor to deny all inbound/outbound >> prefixes; that way, you can keep the session >> up as long as possible, but gracefully bleed >> traffic off ahead of your work. > Route update via new policy could be more cpu intensive than dropping prefixes caused by session shutdown. Of course. But operable routes remain throughout. However, you don't want to reject the routes you want to depreference them, both received and sent. And depreference them on the router whose link will stay up first, so that it starts sending traffic via its link before the router you're taking down changes its routes. Once the preference change moves all routes to the other router, then you want to drop the BGP session to deal with the residual routes. Then once traffic drops to zero on the link, you take down the link. If your customers are really that sensitive to downtime during a reasonable off-hours maintenance window. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From rs+nanog at seastrom.com Sun Nov 29 02:06:06 2015 From: rs+nanog at seastrom.com (Rob Seastrom) Date: Sat, 28 Nov 2015 21:06:06 -0500 Subject: Multi-core clamp on ammeter Message-ID: <86r3j9ef01.fsf@valhalla.seastrom.com> Hi folks, I own a Megger MMC850 which will read amps in a multi-core cable, such as the 10 gauge SEOOW cable one often finds feeding rack PDUs. Datasheet here: http://www.mouser.com/ds/2/263/MMC850_DS_en_V02-15853.pdf Apparently they've been discontinued. Pity. Anyone know of a suitable replacement? I need more. -r From mpetach at netflight.com Sun Nov 29 17:15:28 2015 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 29 Nov 2015 09:15:28 -0800 Subject: OT: BdNOG announces website blocks In-Reply-To: <20151118152204.4768365@m0087793.ppops.net> References: <20151118152204.4768365@m0087793.ppops.net> Message-ID: On Wed, Nov 18, 2015 at 3:22 PM, Scott Weeks wrote: > > --------------------------------------------- > Md. abdullah Al naser mail.naserbd at yahoo.com > Wed Nov 18 12:56:15 BDT 2015 > > The service of Facebook, Viber and Whatsapp are > blocked from now till further notice. It has been > ordered by Begum Tarana Halim, State Minister, Post > and Telecommunications. > ---------------------------------------------- It occurs to me this is a very pro-competition on the part of the government. By blocking the major incumbent messaging apps, it opens up the marketplace for newer, younger startups to gain marketshare. Kudos to the State Minister for such a forward-thinking and pro-competitive-market strategy! Matt (not sure if my tongue should be in my cheek or not, actually...) From joly at punkcast.com Sun Nov 29 18:12:33 2015 From: joly at punkcast.com (Joly MacFie) Date: Sun, 29 Nov 2015 13:12:33 -0500 Subject: OT: BdNOG announces website blocks In-Reply-To: References: <20151118152204.4768365@m0087793.ppops.net> Message-ID: Seems like there's some hardball going on http://www.thedailystar.net/country/cyber-crimes-govt-write-facebook-deal-179314 On Wed, Nov 18, 2015 at 3:22 PM, Scott Weeks wrote: > > > > --------------------------------------------- > > Md. abdullah Al naser mail.naserbd at yahoo.com > > Wed Nov 18 12:56:15 BDT 2015 > > > > The service of Facebook, Viber and Whatsapp are > > blocked from now till further notice. It has been > > ordered by Begum Tarana Halim, State Minister, Post > > and Telecommunications. > > ---------------------------------------------- > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- - From mpetach at netflight.com Sun Nov 29 21:13:09 2015 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 29 Nov 2015 13:13:09 -0800 Subject: Bluehost.com In-Reply-To: <2c1bbf2ce7573cc9d1e6867b630126d3.squirrel@66.201.44.180> References: <20151125180440.GA20559@nic.fr> <6f661213d9ce49dbee4721ab2423140a.squirrel@66.201.44.180> <62b3e90c9574776b8a43974eb72f3cd8.squirrel@66.201.44.180> <7b66dbeb53965d5e9a48887196e9ed42.squirrel@66.201.44.180> <0bd301d127ed$737e3b40$5a7ab1c0$@com> <2c1bbf2ce7573cc9d1e6867b630126d3.squirrel@66.201.44.180> Message-ID: On Sat, Nov 28, 2015 at 8:13 AM, Bob Evans wrote: > I think he means to say the rich get richer on the other side of the > investment by playing the shorting and the buying of stock in the gambling > marketplace. As the stock itself can create a new currency.... so they > make more money playing with that than the actually investment. They are > on the inside hence the saying the rich get richer. > Thank You > Bob Evans > CTO Ah! So there's two types of value being discussed; network value, vs dollar value. While dollar value is being made, and the rich are getting richer, the value of the network resources may indeed be destroyed. Unfortunately, it's very hard to steer behaviour when the incentives are not aligned with the desired outcome, and in these cases, the incentive (get richer) is often at odds with what the technical community might desire. As much as we might wish it to be otherwise, the primary job of public companies is to make money, not create network value--at least, as long as the majority of your voting shares are held by investors rather than technologists. I look at companies like Google, Alibaba, and Facebook as interesting anomalies because they've structured their corporate ownership in a way that doesn't cede control over to the institutional investors the way the vast majority of public companies have. It remains to be seen if that separation allows them to prioritize creating network value above making money. (I suspect Google sidestepped the question when picking their motto--"Don't be evil" doesn't define the nature of evil; for investors, not doing everything possible to make a profit might be seen as 'evil'. ) Thanks! Matt > > > > >> On Wed, Nov 25, 2015 at 5:54 PM, Kiriki Delany >> wrote: >>> [...] >>> >>> Bottom line, is the industry needs to be increasing value, because the >>> flip >>> side.... working for no profit, surviving off investment only... there's >>> no >>> end-game. You see this cycle time and time again as market share is >>> grabbed, >>> then underperforming companies are rolled up. In this process value is >>> destroyed. >>> >>> Ultimately this is also why it's extremely damaging for investors to >>> constantly invest in companies that don't make a profit, and don't >>> provide a >>> successful economical model for the services/products provided. These >>> companies largely live on investor money, lose money, and in their wake >>> destroy value for the entire industry. Of course the end-game for the >>> investors is to make money... I'm always surprised how strong >>> investment/gambles are for non-profitable companies. I guess there is no >>> end >>> to those with too much money that have to place that money somewhere. As >>> the >>> rich get richer, there will only be more dumb money cheapening the value >>> proposition. After all, who needs value when you have willing investors. >> >> >> I'm confused. If these companies largely live on investor money, >> lose money, and destroy value...how is it that a scant two sentences >> later, the rich are getting richer, and there is _more_ dumb money? >> >> I would posit the rich get richer because they *do* >> see value in the investments they make. That is, >> value is being created in these deals...just not for >> everyone. >> >> Matt >> > > From davidbass570 at gmail.com Mon Nov 30 16:33:43 2015 From: davidbass570 at gmail.com (David Bass) Date: Mon, 30 Nov 2015 11:33:43 -0500 Subject: Opinions on Arista 7280? In-Reply-To: References: Message-ID: These are being implemented in production on many a bank network...so yes, they are plenty good enough. You will obviously need to test them in a lab to make sure the features you need to implement don't have any bugs that need to be addressed first. Overall I've had good experiences with them though in a spine/leaf topology in major data centers. I've also been implementing Arista switches as core devices outside of the data center with some pretty great results, but you need to be careful to make sure the features you need are available on the platform you want to buy. As with Cisco (and any other vendor) there are some hardware limitations where some features will exist on one platform, but not another. On Fri, Nov 27, 2015 at 4:39 AM, H I Baysal wrote: > Hi, > > Hardware is really nice. > Backplane, buffers, just basically ?pumping? bandwidth. It?s really good. > > However, mlag can show some bugs when having only 1 interface in an MLAG > (only 1 side) they had issues with the ifindex numbering in software. > There were OSPF configuration options missing, etc. > > In short, hardware is really nice, software needs more maturing. > Nice for distribution but not for core. > > > > > On 24 Nov 2015, at 19:02, David Hubbard > wrote: > > > > Curious if anyone's used the 7280 and wants to share their experience? > > I'm looking at it primarily for three reasons, MLAG (i.e. multi-chassis > > LACP), large ARP/MAC table (256k entries) and large IPv6 neighbor table > > (256k entries). For the table sizes we would like out of one pair of > > switches, we'd be into the Cisco 7000 series, but that's dramatically > > more expensive and we don't need much of anything else that it offers. > > > > Looked at Brocade too, but they don't have devices that can do the multi > > chassis LACP, has the huge table sizes and has a reasonable number of > > 10gig ports. It was possible to construct a workable solution using > > VDX's for switching and CER's for routing, but that's more complex than > > Arista's option if it's a usable option. > > > > Thanks, > > > > David > > From ttauber at 1-4-5.net Mon Nov 30 19:39:44 2015 From: ttauber at 1-4-5.net (Tony Tauber) Date: Mon, 30 Nov 2015 14:39:44 -0500 Subject: [NANOG-announce] Fwd: NANOG 66 - San Diego - Call for Presentations is Open! In-Reply-To: References: Message-ID: Hi folks, A reminder of today being the due date for Abstracts for NANOG66 in San Diego. We'd like to see things submitted the PC Tool . Don't sweat it if the idea isn't all the way fleshed out. The PC meets bi-weekly to review submissions and assign a "Shepherd" w/in the PC to help develop and refine the content. If you did happen to have materials such as a draft slide deck ready, please upload it to the PC Tool as well as it helps give the PC a sense of the scope and level of detail of the proposal. Thanks, Tony Chair, NANOG Program Committee ---------- Forwarded message ---------- From: Tony Tauber Date: Tue, Oct 27, 2015 at 5:07 PM Subject: NANOG 66 - San Diego - Call for Presentations is Open! To: nanog-announce at nanog.org Greetings NANOG Folks, The last two NANOG meetings (San Francisco and Montreal) set records for attendance and we hope and expect the trend of strong attendance numbers to continue for the NANOG 66 meeting February 8-10, 2016 in San Diego, CA which will be hosted by IIX, Inc. The detailed NANOG66 Call For Presentations has more info but below is some information that might be useful for quick digestion. Cheers, Tony Tauber Chair, NANOG Program Committee === Timeline for submission and proposal review 1. Submitter enters Abstract (and draft slides if possible) in Program Committee Site . 1. Any time following Call for Presentations and before deadline for Abstracts 2. PC performs initial review and assigns a ?Shepherd? to help develop the submission. 1. Within about 2-3 weeks 3. Submitter develops draft slides (minimally showing proposed outline and level of detail). 1. Please submit initial draft slides before published deadline for slides 2. Panels and Track submissions should provide topic list and intended/confirmed participants 4. PC reviews slides and iteratively works with Submitter to help develop topic. 5. PC accepts or declines submission 6. Agenda assembled and posted 7. Submitters notified If you think you have an interesting topic but want some feedback or assistance working it into a presentation, please email the Program Committee , and a representative on the Program Committee will give you the feedback needed to work it into a presentation. Otherwise, don't delay in submitting your talk, keynote, track, or panel proposal to the Program Committee Site . We look forward to reviewing your submission. Key Dates For NANOG 66 Event/Deadline Date Registration for NANOG 66 Opens Monday, 10/26/2015 CFP Opens for NANOG 66 Monday, 10/26/2015 CFP Deadline #1: Presentation Abstracts Due Monday, 11/30/2015 CFP Topic List and NANOG Highlights Page Posted Friday, 12/18/2015 CFP Deadline #2: Presentation Slides Due Monday, 1/4/2016 Meeting Agenda Published Monday, 1/11/2016 Speaker FINAL presentations to Program Committee Site Wednesday, 2/3/2016 On-site Registration Sunday, 2/7/2016 Lightning Talk Submissions Open (Abstracts Only) Sunday, 2/7/2016 Further Presentation Guidelines can be found under "Present at a NANOG" and some general advice is available in Tips on Giving a Talk . -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From kiriki at streamguys.com Mon Nov 30 21:13:25 2015 From: kiriki at streamguys.com (Kiriki Delany) Date: Mon, 30 Nov 2015 13:13:25 -0800 Subject: Bluehost.com In-Reply-To: References: <20151125180440.GA20559@nic.fr> <6f661213d9ce49dbee4721ab2423140a.squirrel@66.201.44.180> <62b3e90c9574776b8a43974eb72f3cd8.squirrel@66.201.44.180> <7b66dbeb53965d5e9a48887196e9ed42.squirrel@66.201.44.180> <0bd301d127ed$737e3b40$5a7ab1c0$@com> <2c1bbf2ce7573cc9d1e6867b630126d3.squirrel@66.201.44.180> Message-ID: <0eff01d12bb3$f46b0610$dd411230$@com> I was more stating the macro economics, and specifically commenting on the effects of the losing investments if the product/service itself is being sold at a loss. Slim margins on the long-tail of high-volume low end is to be expected. The rich are getting richer, was a generally observation that there is a trend of more money coming down from the top. I *think* there is more losers than winners in general, but the point is about how businesses survive. They either have to be profitable, and typically providing value in the "free market" or are being subsidized in some way (by investment). The constant subsidy of investment, before there is an actual value-add to the service/product, damages the rest of the value proposition for the industry. I don?t claim to have the answers, just observations from our perspective as a privately held, profitable service company. These issue are at the heart of conversations about the value of services like YouTube (Paid for by Google but a successful business model?) and Streaming radio services like Pandora, Spotify, Tidal, etc... Typically those conversations are about the value of the content, vs the revenue paid to the content creators, and who is doing more "work" i.e is Google getting the content out there? Or is it destroying the value of the content by providing access. These are content examples, but I think it?s the same conversation for the web hosting and networks. I'm also saying more energy needs to be put into increasing value and being able to raise the prices of a service. After-all if you are supplying a higher value, it's worth more to the customer, and they are actually saving money in the long run paying for a more valuable service. As networks and web-hosting becomes more of a commodity, I wonder how the service side is being addressed. It's certainly a struggle for most large operators, just look at Telco's and Cable operators, some of the most hated support provided. Even the airlines are horrible. No one's solving the problem of how to massively scale and keep up the quality of your support services too. -Kiriki -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew Petach Sent: Sunday, November 29, 2015 1:13 PM Cc: NANOG Subject: Re: Bluehost.com On Sat, Nov 28, 2015 at 8:13 AM, Bob Evans wrote: > I think he means to say the rich get richer on the other side of the > investment by playing the shorting and the buying of stock in the > gambling marketplace. As the stock itself can create a new > currency.... so they make more money playing with that than the > actually investment. They are on the inside hence the saying the rich get richer. > Thank You > Bob Evans > CTO Ah! So there's two types of value being discussed; network value, vs dollar value. While dollar value is being made, and the rich are getting richer, the value of the network resources may indeed be destroyed. Unfortunately, it's very hard to steer behaviour when the incentives are not aligned with the desired outcome, and in these cases, the incentive (get richer) is often at odds with what the technical community might desire. As much as we might wish it to be otherwise, the primary job of public companies is to make money, not create network value--at least, as long as the majority of your voting shares are held by investors rather than technologists. I look at companies like Google, Alibaba, and Facebook as interesting anomalies because they've structured their corporate ownership in a way that doesn't cede control over to the institutional investors the way the vast majority of public companies have. It remains to be seen if that separation allows them to prioritize creating network value above making money. (I suspect Google sidestepped the question when picking their motto--"Don't be evil" doesn't define the nature of evil; for investors, not doing everything possible to make a profit might be seen as 'evil'. ) Thanks! Matt > > > > >> On Wed, Nov 25, 2015 at 5:54 PM, Kiriki Delany >> >> wrote: >>> [...] >>> >>> Bottom line, is the industry needs to be increasing value, because >>> the flip side.... working for no profit, surviving off investment >>> only... there's no end-game. You see this cycle time and time again >>> as market share is grabbed, then underperforming companies are >>> rolled up. In this process value is destroyed. >>> >>> Ultimately this is also why it's extremely damaging for investors to >>> constantly invest in companies that don't make a profit, and don't >>> provide a successful economical model for the services/products >>> provided. These companies largely live on investor money, lose >>> money, and in their wake destroy value for the entire industry. Of >>> course the end-game for the investors is to make money... I'm always >>> surprised how strong investment/gambles are for non-profitable >>> companies. I guess there is no end to those with too much money that >>> have to place that money somewhere. As the rich get richer, there >>> will only be more dumb money cheapening the value proposition. After >>> all, who needs value when you have willing investors. >> >> >> I'm confused. If these companies largely live on investor money, >> lose money, and destroy value...how is it that a scant two sentences >> later, the rich are getting richer, and there is _more_ dumb money? >> >> I would posit the rich get richer because they *do* see value in the >> investments they make. That is, value is being created in these >> deals...just not for everyone. >> >> Matt >> > >