Comcast business IPv6 vs rbldnsd & PSBL
First of all, kudos to Comcast for trying to roll out IPv6 across their entire network. Static IPv6 netblocks seem to be available for Comcast business users, and IPv6 is enabled unconditionally in the CPE routers used by Comcast business class internet. Unfortunately, the software in the two available CPE routers (SMC & Cisco) is horribly broken when it comes to IPv6. The TL;DR summary: even when IPv6 firewalling is disabled in the configuration, the router still tracks every IPv6 "connection", which causes every single DNS lookup to fill up a slot in its connection tracking table. The router's logs say it blocks tens of thousands of IPv6 connections every day, despite firewalling being "disabled" on the router. Once the connection tracking table fills up, both IPv6 and IPv4 start having trouble, with packet loss on ICMP, high ping times to the local router (and the internet), and new connections not establishing. The router randomly crashes and reboots too, sometimes multiple times a day. This ends up breaking both IPv6 and IPv4. It only takes about 300kbit/s of DNS traffic to trigger the bug, in both the SMC and the Cisco routers. Are there any Comcast NOC or other technical people present who could help? I am interested both in helping resolve the firmware issues in the routers (there will no doubt be other customers who hit this in the future, as IPv6 becomes ore common) or, if that is not an option, finding some way to avoid the issue. http://forums.businesshelp.comcast.com/t5/Equipment-Modems-Gateways/Cis co-DPC3941B-slows-to-a-crawl-and-crashes-several-times-a-day/td-p/30807 -- All Rights Reversed. signature.asc Description: This is a digitally signed message part
Re: Comcast business IPv6 vs rbldnsd & PSBL
On Tue, 2016-11-29 at 13:34 -0500, Jared Mauch wrote: > Folks at Comcast have told me to ask for the SMC gateway to be > replaced with either the netgear or Cisco to solve that issue. Over the past year and a bit, I have had all three of the Comcast business routers in my network. The Netgear only stayed for one day - after about 10-15 minutes of "heavy" (~300kbit/s) DNS lookups coming in from the outside, it was almost impossible to make new TCP connections across the router, either IPv4 or IPv6. The SMC D3G-CCR mostly worked, except at some point during the year, the fraction of traffic going over IPv6 went high enough to wreck the D3G, causing it to crash and reboot several times a day, without having enough diagnostics for me to figure out what was going on. The Cisco DPC3941B seems to fail in pretty much the same way as the SMC D3G-CCR, but it has enough diagnostics that I could finally figure out what was happening. With "Gateway Smart Packet Detection" disabled, and the "Firewall completely disabled", the logs are still showing tens of thousands of dropped IPv6 connections every day. In other words, the config options that supposedly disable the firewall completely, do not in fact disable the firewall code, and I am still hitting connection tracking limits. DNS lookups coming from randomized port numbers (to avoid spoofing issues) mean every DNS query takes up another slot in the connection tracking table. Once the table is full, the router will search for a re-usable slot before routing a packet. This can cause ping times to 10.1.10.1 (the router) to go as high as 800ms. This is from a system sitting 5ft from the router. If the router does not find any re-usable slot in the connection tracking table, packets can get lost. This leads to the "fun" scenario where pinging the router from a system directly connected to it shows 30% packet loss, while streaming video over an already established TCP stream continues at full speed! Not a symptom I ever expected to see... -- All rights reversed signature.asc Description: This is a digitally signed message part
Re: Geographic map of IPv6 availability
On Thu, 4 Oct 2007 00:18:34 +0100 <[EMAIL PROTECTED]> wrote: > It's one way to debunk the myth that IPv6 is really hard to find. I just realized that IPv6 web sites are not being indexed by Google. That would make IPv6 content really hard to find. What can we do about that? Any Google people on NANOG? -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
