Skip to content
joemarkgraf's profile

New problem solver

 • 

10 Messages

Tuesday, September 17th, 2019 6:00 PM

Can not get internal IPv6 traffic to route with the CGA4131COM

Hello,

 

I am unable to get internal traffic to route to the internet with my new CGA4131COM. I have tried DHCPv6 and SLAAC and both are not working.

 

The Cisco gateway I had in the past worked find with DHCPv6 enabled. This new box isn’t working in the same manner.

Administrator

 • 

261 Messages

5 years ago

Thanks so much for reaching out. Can you let us know how you have things setup right now? Is the gateway in bridge mode, is there an additional router, is there a primary modem? 

 

-Gina

Administrator

 • 

261 Messages

5 years ago

Ah, okay! You can't do bridge mode with statics but you could do pass through mode. This is an older thread but the information is still pertinent: True Bridge Mode versus Pass Through Mode . With the specific issue about the IPv6 routing, I didn't see it above but is the LAN DHCP also disabled?

 

-Gina

New problem solver

 • 

10 Messages

5 years ago

Hi Gina,

 

I have static IPv4 IPs, so the CGA4131COM must *NOT* be set into bridge mode per support. 

 

The CGA4131COM runs into a pfsense router/firewall, then out to my network.

 

I have everything on the CGA4131COM disabled.

  • IPv4 & IPv6 - Disable entire firewall checked.
  • Managed Sites Disabled
  • Managed Services Disabled
  • Managed Devices Disabled
  • Port Forwarding/Triggering Disabled
  • Port Management - Disable all rules and allow all inbound traffic through is checked.
  • DMZ Disabled
  • NAT - Disable All is checked
  • Static Routing - No entries
  • Dynamic DNS disabled
  • UPnP and Zero Config are disabled.

As for my pfsense config- it's basic. I have a WAN port and a LAN port. I have tired DHCPv6 and SLAAC on the WAN port, with prefix delegation, and my internal network (LAN port) can not route back out to the internet. In the past, with my old Cisco gateway, DHCPv6 worked without issue. Routing and addressing came through without issue on both the WAN and LAN.

 

Regarding bridge mode- I would prefer that the device acts as a bridge however, I have been told that this is not possible with the CGA4131COM due to my requirement for static IPs.

 

New problem solver

 • 

10 Messages

5 years ago

Hi Gina,

 

Originally I had setup the CGA4131COM using this post.

 

LAN DHCP is not disabled for IPv4. I handle LAN DHCP with the pfsense box and use static IPs on my WAN so I did not change this setting.

 

IPv6 is set with the following options:

 

  • Stateless - checked
  • Stateful(Use Dhcp Server) - checked
  • DHCPv6 Lease Time - 1 Weeks
  • Assign DNS manually - not checked

Please let me know via PM if you want my addresses / address range.

Administrator

 • 

261 Messages

5 years ago


@joemarkgraf wrote:

Hi Gina,

 

Originally I had setup the CGA4131COM using this post.

 

LAN DHCP is not disabled for IPv4. I handle LAN DHCP with the pfsense box and use static IPs on my WAN so I did not change this setting.

 

IPv6 is set with the following options:

 

  • Stateless - checked
  • Stateful(Use Dhcp Server) - checked
  • DHCPv6 Lease Time - 1 Weeks
  • Assign DNS manually - not checked

Please let me know via PM if you want my addresses / address range.


Thanks for providing this info. We got your private message so I'll follow up with you there.

 

Ken

New problem solver

 • 

8 Messages

5 years ago

I have run into this same issue, although I am using a Cisco router. I bumped up my Internet speed from 150 to 300 on Friday (9-27-2019) and the technician removed the CG3000DCR and replaced it with a CGA4131COM (CBR-T). Everything was working fine with the old gateway. I checked all of the settings on the new gateway and everything is fine. I can perform a IPv6 traceroute (traceroute to 2001:4860:4860::8888) from the router and clients behind the router are getting autoconfigured IPv6 addresses but no IPv6 traffic will pass from the clients behind the router. And traceroute from the clients never go through the CGA4131COM to the outside (traceroute to 2001:4860:4860::8888).

 

I am at a loss why everthing was working with the old Netgear gateway but not with the new gateway. 

 

 

New problem solver

 • 

8 Messages

5 years ago

After extended testing, the only way a Technicolor gateway will pass IPv6 traffic from client computers when using IPv6 DHCP-PD on a firewall or router behind it is to place the Technicolor gateway in bridge mode. 

Visitor

 • 

4 Messages

5 years ago

Your forum won't let me .. it tries to convert my response to HTML, then errors out stating I've sent too many private message, which are zero total, as you can likely see in my 'Sent'-folder. 

Please let me know when the limitation is removed.

Thanks.

Visitor

 • 

4 Messages

5 years ago

ComcastBiz_Support / Comcast_Gina -

 

This statement is completely unrelated to the post/request made by ITGrouch56 as well as multiple other posters/threads in your own forums (bordering on the same level of tone-deafness I’ve encountered).

 

The statements made by ITGrouch56 are 100% accurate. The CGA4131COM is broken at the firmware level. This escaped both your quality assurance testing as well as any limited scope testing performed before they were released to general availability.

 

I’ve spent the better part of the last month trying to resolve the exact same issue experienced by the individual who started this thread.

 

Back at the end of August, my CG3000DCR, which worked for 6+ years in a dual-stack (IPv4/IPv6) configuration behind two different Ubiquiti EdgeRouter firewalls, ceased to function and was slated for replacement.

 

I was provided a DPC3941B as an initial replacement, after a few days of testing/acclimation, I asked for a different device as latency/packet loss/skew is inconsistent/out-of-spec for even the internal address/static gateway assigned to the provided equipment, much less the outside world. (Google: Puma 6 chipset)

 

Made several emphatic requests with Tier-2/ECR to simply give me a new CG3000DCR. They were denied by local dispatch/maintenance no fewer than ~5 times, stating the device is EoL and will only cause more issues.

 

After nearly ~30 days of back and forth, daily emails and calls, local finally ‘caved’ and provided me a used CG3000DCR that was not only covered in white paint spatter, but scratched/gouged on all facets.

 

Not willing to stand in the way of progress, I accepted the obviously damaged device as the local representative stated it was the only device left, I wouldn’t be receiving another.

 

We brought it online and provisioned, immediately IPv6/dual-stack connectivity was restored without a single change to my equipment aside from deleting DUID, releasing/renewing the interface.

 

I was thrilled, sent emails to Executive Customer Relations stating that everything was once again functional, thanking them for the time/effort put into resolving this request.

 

Not more than literally ~15 minutes after the technician pulled away from the curb, the device hard-locked and refused to even accept ICMP to the inside interface/assigned IPv4-static gateway.

 

Notified ECR of the failure and was told that they’d have someone onsite the following day.

 

Less than ~24 hours later I had multiple technicians, including a local VP, respond to my premise (likely trying to find fault with my installation/implementation). I was informed that I wouldn’t be receiving another CG3000DCR, only the CGA4131COM.

 

To be frank, the CGA4131COM is a very capable device, one that I have zero issue keeping, if it were not for the the fact that it was shipped with broken firmware.

 

This isn’t conjecture, my opinion, a crazy person rattling nonsense, nor is it my configuration. A nearly ~100 billion dollar company, shipped a broken device. That’s it. It happens. This is a fact.

 

It took me the better part of a month to not only convince not only ECR/T2 of this fact, but local resources. I’m still not sure how much of them finally seeing the light was simply placation to get me to stop contacting them.

 

Here’s where we left off:

 

My last email to ECR and subsequent site-visit was on Sept 25/26th. I was informed that it was now a ‘known issue’ and a new firmware was in the pipeline, slated for testing/deployment within ~2 weeks. However, this wouldn’t apply to me because I’m a static customer that routes their block over RIPv2, which requires a different firmware. This firmware for static customers would be available ‘middle of November’

 

Needing to move on with life, I accepted this, adding additional cost to my monthly totals with Amazon Web Services to spin up a bastion/testing host for only IPv6. Not only is this inconvenient, but it doesn’t work for the majority of test-cases I’d generally leverage IPv6 for.

 

As a provider myself who works in the telecommunications space, my needs are significantly different than the average Xfinity/Comcast Business customer. But it cannot be overstated how much this has impacted my workflow.

 

I just wanted to type this up so that anyone else encountering this issue can rest assured, it’s not you. It’s the modem. I don’t care what response I receive to this, if any, your CGA4131COM has broken firmware. It needs to be escalated to the appropriate parties.

 

I’m not hopeful this is going to be resolved soon as even the NOC staff looked at this as a ‘dude, fix your configuration’-issue. But I can remain hopeful that this isn’t falling of deaf ears.

 

I await my boiler-plate/copy-pasta response about how Comcast supports IPv6 and I should real support/KB-document ‘XYZ’ as to how to configure my equipment.

 

Likely going to shamelessly necro-post any related threads I see with the term ‘CGA4131COM’ because I’ve seen a trend where you prefer to take these threads offline, which negates the entire purpose of a community forum like this.

 

If anyone within the organization is curious enough to follow up, I’d be happy to provide private details via DM, as long as we agree to continue the brunt of the discussion in an open forum as to benefit others like myself who have met the same brick wall.

 

For the .00001% of people who made it this far, thanks!

-fwp

Problem solver

 • 

144 Messages

5 years ago

Hi there. I can definitely assist you with any concern you have. Please provide me with your full name, and account number and I'll work on this immediately. -Rob K.

New Contributor

 • 

4 Messages

5 years ago

fwpowell:  Hear, hear!  You hit the nail on the head.  So, I have called Comcast four or five times in the past 36 hours since I have had this roaring dumpster fire of a unit installed in my home office.  I've had every problem you've had, among others...the CGA4131COM is an absolute piece of well-crafted garbage.

 

So, I renewed my contract, and pleaded to not be burdened with the DPC3941 either, since it too was an albatross.  "Sure, no problem, you won't have the problems you've been having," says the account representative.  Baloney.  And since I have static IPv4 and IPv6 allocations, this thing arrived with a technician as a must-have.  Can't bring my own modem, can't use anything else.  Comcast says they'll come out and fix it for $99, but also tell me they can't help because of a "demarcation policy".  We had a circular argument on the phone over this disaster.  So, I am forced to take the device, and because it won't work, I'm forced to pay $99 and still have it not work.  No way...Comcast can sweep up the many little pieces they'll find it in this week.

 

The CGA4131COM has several problems:

* It doesn't keep time properly.  Whether it's supposed to come from NTP or the head-end, it won't sync up.  The fact that it's December 31, 1969 is of no concern to anyone Comcast...and no wonder, apparently they're all stuck in that year.  Tier I Support does not possibly see this as a problem and tells me it shouldn't impact performance.  Meanwhile, lease times for DHCP show up on the order of 49710 days.  Gee, how could that be a problem?

* Static DHCP leases can't be applied; they revert back to previously assigned DHCP address.

* LAN subnets can't be changed; it screws up the DHCP scopes and won't allow IPs to be reserved for static DHCP.

* You can't logon as "cusadmin"; the modem forces logout or warns that re-attempts of logging in will cause a five minute lockout.  Tier I Support told me not to change the password from "highspeed" because of the problems I've been having, but when I logon, the modem wants me to use anything but "highspeed".  Really!?

* Removing a device from the DHCP list blocks it...it doesn't remove anything.  Retaining a limitless table of MACs for devices long unplugged is nonsense.  Even worse, if the offline device is holding an IPs you need for Static DHCP, forget it.

* You can't bridge the device; Comcast admits to this, but through snaky double-talk, they say their way of bridging is different...it's "pass through mode", and that their way is a better way, even if it violates about every RFC standard known to man and makes every network engineer cry.

 

I'm still busy doing Comcast's QA work, so I am sure there are a mountain of other bugs I have yet to find.  Fortunately, I think I will be rid of Comcast within the next few days.  I think 56k dial-up modem service will probably be less aggravating, and I might consider that instead or going back to sending snail mail.

New Contributor

 • 

4 Messages

5 years ago

Oh yeah, found another bug!  1:1 NAT doesn't work...hey, just like the DPC3941...amazing.  Dear Comcast: If you can't do 1:1 NAT, or you don't want anyone doing 1:1 NAT, why do you bother to put it in as a feature?

Administrator

 • 

261 Messages

5 years ago

Hey there! Thank you so much for your time and patience. I am sorry to learn that you have had this experience with our CGA4131COM and DPC3941 equipment. I definitely understand the importance of paying for service and receiving quality service in return. We will surely miss your business. I will make sure to pass along your feedback so we can make the corrections necessary to prevent this kind of unfavorable experiences from happening in the future. As far as doing 1:1 NAT goes, the modems are capable of this feature, however, we do not recommend it because it can cause a dual NAT issue with modem and routers.  -Gabriel

Visitor

 • 

2 Messages

5 years ago

Has there been a firmware update/hotfix to address these issues? IPv6 is utterly broken for our configuration.

Gold Problem solver

 • 

421 Messages

5 years ago

Hi TheIC! I hate to hear you're having issues 😞 If you use one of our CGA4131COM gateways, you can enable IPv6 routing and make sure that you have LAN IPv6 Address Assignment set as Stateful. If you continue to have have issues, please click on my handle (Comcast_Gina) and send a private message with your name, the business name, the complete service address (including city, state, ZIP, suite number, etc), and the phone or account number, and any pertinent details so we can help out.

Image