pfSense fails to restore IPV6 after WAN side service interruption
-
@JKnott said in pfSense fails to restore IPV6 after WAN side service interruption:
This brings up the question, is the OPs modem in bridge o
Bridge, of course.
-
My setup:
ISP - Comcast
Modem - Netgear CM600
Bridge mode
Non-Puma chipset (Broadcom)
Does not do LAN DHCP when ISP drops AFAICT
pfSense is direct connect to the modem (but as a VM)
IPv4 comes back fine, have to bounce the IPv6.
(Just stirrin' the pot! :) -
@JKnott Ok, tried that, interesting result.
With the switch inline, pfSense never notices that the modem's gone away, other than apinger and NTP complaining of loss of connectivity. Reconnecting the coax lets the modem re-register, and connectivity is restored on the very same V4 and V6 addresses.
Without the inline switch I managed to reproduce the original problem. Pulling the coax immediately cause the IP address to switch to 192.168.100.10, so I guess there is a short Ethernet link interruption. However, V6 connectivity was not restored. Restarting the radvd service re-established V6 connectivity.
-
@jcyr interesting, I will be putting a dummy switch between the modem and router, that may indeed be the simplest work around.
It's rather odd that there is an interruption at the ethernet layer when the coax is pulled - you'd think that the switch ports at the back of the modem are exactly that, just a switch.
I don't think it has anything to do with the Puma chipsets (which are notoriously terrible at maintaining decent first hop latency), but it may have something to do with firmware. Given that @provels reproduced the issue with a Broadcom chipset, I'm going to assume there is a gremlin in Comcast's firmware that causes a momentary ethernet interruption. Again, Rogers exactly mirrors Comcast's technology - identical hardware, identical firmware.
At this point I believe we ruled out that the issue lies with pfSense, it is widely reproducible, and I doubt any of the cable providers will consider it an issue as any non-standard use of their garbage "residential gateways" are explicitly unsupported.
tl;dr
Mainstream DOCSIS residential gateways are never truly bridged even operating in bridge mode. This worked fine prior to dual-stack going mainstream, although I do have to praise Comcast (and Rogers) for their otherwise superb IPv6 support. (/56 per gateway is pretty cool) -
@ljr said in pfSense fails to restore IPV6 after WAN side service interruption:
I will be putting a dummy switch between the modem and router, that may indeed be the simplest work around.
That will only work if Comcast assigns the same V4 and V6 addresses to you upon re-registration. I know this to be mostly true for Comcast, but not guaranteed.
IPV6 Test: http://ipv6-test.com
-
@jcyr said in pfSense fails to restore IPV6 after WAN side service interruption:
That will only work if Comcast assigns the same V4 and V6 addresses to you upon re-registration. I know this to be mostly true for Comcast, but not guaranteed.
I don't recall my v4 address ever changing, unless I change the MAC address on my WAN interface... same for v6, as long as you'd have the same DUID you should receive the same prefix...
I suppose one could write a script to restart the interface periodically until the 192.168.100.0/24 address clears.
-
pfSense has a gateway monitoring function. Perhaps that might help. However, I haven't tried it, as I don't have a need to. What is the intended function of gateway monitoring?
-
@ljr said in pfSense fails to restore IPV6 after WAN side service interruption:
I suppose one could write a script to restart the interface periodically until the 192.168.100.0/24 address clears.
Or start with RTFM: https://docs.netgate.com/pfsense/en/latest/book/interfaces/ipv4-wan-types.html#dhcp and try to reject the lease.
-
@Grimson I'll certainly try that. But that's IPV4 stuff and never had a problem with V4.
-
@Grimson said in pfSense fails to restore IPV6 after WAN side service interruption:
Or start with RTFM: https://docs.netgate.com/pfsense/en/latest/book/interfaces/ipv4-wan-types.html#dhcp and try to reject the lease.
Well, in retrospect it was amateur to suggest hacking a script. But, shit, that does the trick.
Sorry.
-
@Grimson I have been rejecting leases from my cable modem, 192.168.100.1, for some time now. Doesn't appear to have an impact on this issue(s).
Rebooted pfsense late last night and the WAN did not get an ipv6 address. Waited a good long time. A second reboot set it right. I then disconnected the cable, waited a few minutes, and reconnected. It worked.
Too many variables, I need to set aside some time and work this through methodically.
-
@jwj said in pfSense fails to restore IPV6 after WAN side service interruption:
@Grimson I have been rejecting leases from my cable modem, 192.168.100.1, for some time now. Doesn't appear to have an impact on this issue(s).
Rebooted pfsense late last night and the WAN did not get an ipv6 address. Waited a good long time. A second reboot set it right. I then disconnected the cable, waited a few minutes, and reconnected. It worked.
Too many variables, I need to set aside some time and work this through methodically.
Indeed, there appears to be more than one path to failure.
-
@Grimson Well that didn't work! Had another service interruption today and ignoring leases from the modem's DHCP prevented even IPV4 from recovering when the modem registered upon resumption of service. Had to bounce the WAN link to restore LAN side connectivity.
-
I see this as well, IPv6 will not come up until apply button is pressed in the WAN interface or a second reboot (sometimes)
This is with Arris CM8200B and 2.4.5-RELEASE-p1
-
