01-07-2022 05:27 PM - last edited on 01-07-2022 05:46 PM by RogersMoin
Hello everyone,
I am currently using a Ubiquiti's UNIF gear (APs, router/fw & switch).
I've reviewed some of the previous threads and some threads with Unifi. I think I have things configured correctly (more or less matching the PFsense setup previously described)
Unfortunately I can't seem to get anything ....... It's like there's a missing "on switch" somewhere. Before flipping to bridge mode a v6 addy was there, so I know it works ... and it's not like it's rocket science to flip to dhcpv6, prefix length 64, delegation on the lan side and id 0.
I'm gonna try power cycling everything just to make sure. I just changed over from a commercial setup (term ended) to a residential setup. On the commercial side I was static. Residential side I am all dhcp. I just swapped out the modems today.
*Added Labels*
03-01-2022 09:54 AM
@JKnott With this new FTTH service, the CPE demarc is a Nokia XGS-PON ONT. You basically access the Rogers network through a 10Gig Ethernet port and if you only require Internet service, you should be able to plug whatever equipment that you want into it.
However, the XB7 Ignite Gateway is still required to support certain Ignite services, such as Home Phone... and for Ignite TV to work in a plug-and-play manner, to support Ignite Pods, and to act as the hub for Rogers' Connected Home offerings. Since there is no coax cable for the Ignite gateway to connect to, you have the option to enable an Ethernet WAN interface, and this cannot be enabled in Bridge Mode.
As for @gadgetgeek 's issues, if I understand correctly, things worked fine for several weeks.
03-01-2022 10:39 AM
03-01-2022 11:46 AM
That is correct @-G- . It did work perfectly for several weeks. I didn't change anything on the configuration on my USG or other hardware devices. At some point, IPv6 disconnected from Rogers.
03-01-2022 12:00 PM
@JKnott gadgetgeek does not have a traditional/legacy cable Internet service. That next-generation FTTH deployment does not use RFoG and the Rogers Internet service there does not use DOCSIS. The cable modem portion of the XB7 is not even used. If the XB7 is required for Ignite services, it needs to connect to the ONT via Ethernet, and for that to work, Bridge Mode on the XB7 needs to be disabled.
03-01-2022 02:27 PM
My point was the home phone should not depend on gateway mode. My modem is in bridge mode and that has no effect at all on my home phone.
03-01-2022 03:04 PM
@JKnott wrote:
My point was the home phone should not depend on gateway mode. My modem is in bridge mode and that has no effect at all on my home phone.
I never said that Home Phone required gateway mode. I was responding to the point that you made in the following post:
I understand that my hardware is completely different, but one thing remains, you must put whatever device Rogers provides into bridge mode. No exceptions. I have a cable modem, which I have put into bridge mode and then follow it with my own router. I connect to my TVs via Ethernet, but WiFi should also work, since it's connected to the same LAN.
In an FTTH installation, you cannot use the XB7 in bridge mode. If you require an XB7 for any of your Ignite services, it can only be used in gateway mode. Bridge Mode can only be enabled when the Ignite gateway is being used as a cable modem.
03-02-2022 06:20 AM
I'm going to reach 2nd level support at Rogers and ask if its possible to get the ONT to connect via its 2 LAN ports.
I will let you folks know how I make out.
07-03-2022 10:56 PM - last edited on 07-05-2022 08:58 AM by RogersMaude
Hi,
I'm having periodic outages of a few minutes every hour or so. Other than that, things are working perfectly (although the outage is killing me, as it brings down both IPv4 and IPv6 networking and makes things useless).
The problems do not occur if I run the gateway in non-bridge mode and just use IPv4. But they star when the Gateway goes into Bridge Mode, and I allocate IPv6 to my clients. Router Model is CGM4331COM and firmware is CGM4331COM_5.2p7s1_PROD_sey.
The set up is pretty straight-forward:
- Gateway connected to PC running Arch Linux over Ethernet (a direct Cat6
- Arch Linux running as an IPv4 NAT and an IPv6 router, with dhclient to get the prefix and radvd to advertise it
The dhclient to obtain the prefix works well, and obtains the prefix without any trouble, i.e.:
dhclient -P [INTERFACE]
Jul 04 02:18:30 archlinux dhclient[9547]: Internet Systems Consortium DHCP Client 4.4.3
Jul 04 02:18:30 archlinux dhclient[9547]: Internet Systems Consortium DHCP Client 4.4.3
Jul 04 02:18:30 archlinux dhclient[9547]: Copyright 2004-2022 Internet Systems Consortium.
Jul 04 02:18:30 archlinux dhclient[9547]: All rights reserved.
Jul 04 02:18:30 archlinux dhclient[9547]: For info, please visit https://www.isc.org/software/dhcp/
Jul 04 02:18:30 archlinux dhclient[9547]: Copyright 2004-2022 Internet Systems Consortium.
Jul 04 02:18:30 archlinux dhclient[9547]: All rights reserved.
Jul 04 02:18:30 archlinux dhclient[9547]: For info, please visit https://www.isc.org/software/dhcp/
Jul 04 02:18:30 archlinux dhclient[9547]:
Jul 04 02:18:30 archlinux dhclient[9547]: Listening on Socket/enp0s31f6
Jul 04 02:18:30 archlinux dhclient[9547]: Listening on Socket/enp0s31f6
Jul 04 02:18:30 archlinux dhclient[9547]: Sending on Socket/enp0s31f6
Jul 04 02:18:30 archlinux dhclient[9547]: PRC: Confirming active lease (INIT-REBOOT).
Jul 04 02:18:30 archlinux dhclient[9547]: Sending on Socket/enp0s31f6
Jul 04 02:18:30 archlinux dhclient[9547]: XMT: Forming Rebind, 0 ms elapsed.
Jul 04 02:18:30 archlinux dhclient[9547]: XMT: X-- IA_PD d3:05:44:6a
Jul 04 02:18:30 archlinux dhclient[9547]: XMT: | X-- Requested renew +3600
Jul 04 02:18:30 archlinux dhclient[9547]: XMT: | X-- Requested rebind +5400
Jul 04 02:18:30 archlinux dhclient[9547]: XMT: | | X-- IAPREFIX [REDACTED]
Jul 04 02:18:30 archlinux dhclient[9547]: XMT: | | | X-- Preferred lifetime +7200
Jul 04 02:18:30 archlinux dhclient[9547]: XMT: | | | X-- Max lifetime +7500
Jul 04 02:18:30 archlinux dhclient[9547]: XMT: V IA_PD appended.
Jul 04 02:18:30 archlinux dhclient[9547]: XMT: Rebind on enp0s31f6, interval 940ms.
Jul 04 02:18:30 archlinux dhclient[9547]: XMT: Rebind on enp0s31f6, interval 940ms.
Jul 04 02:18:30 archlinux dhclient[9547]: RCV: Reply message on enp0s31f6 from fe80::217:10ff:fe93:6cac.
Jul 04 02:18:30 archlinux dhclient[9547]: RCV: Reply message on enp0s31f6 from fe80::217:10ff:fe93:6cac.
Jul 04 02:18:30 archlinux dhclient[9547]: RCV: X-- IA_PD d3:05:44:6a
Jul 04 02:18:30 archlinux dhclient[9547]: RCV: | X-- starts 1656901110
Jul 04 02:18:30 archlinux dhclient[9547]: RCV: | X-- t1 - renew +74463
Jul 04 02:18:30 archlinux dhclient[9547]: RCV: | X-- t2 - rebind +119141
Jul 04 02:18:30 archlinux dhclient[9547]: RCV: | X-- [Options]
Jul 04 02:18:30 archlinux dhclient[9547]: RCV: | | X-- IAPREFIX [REDACTED]
Jul 04 02:18:30 archlinux dhclient[9547]: RCV: | | | X-- Preferred lifetime 148927.
Jul 04 02:18:30 archlinux dhclient[9547]: RCV: | | | X-- Max lifetime 580927.
Jul 04 02:18:30 archlinux dhclient[9547]: RCV: X-- Server ID: [REDACTED]
Jul 04 02:18:30 archlinux dhclient[9547]: PRC: Bound to lease [REDACTED]
Jul 04 02:18:30 archlinux dhclient[9547]: PRC: Renewal event scheduled in 74463 seconds, to run for 44678 seconds.
Jul 04 02:18:30 archlinux dhclient[9547]: PRC: Depreference scheduled in 148927 seconds.
Jul 04 02:18:30 archlinux dhclient[9547]: PRC: Expiration scheduled in 580927 seconds.
The router advertisement also works well, i.e., running radvd with the following configuration:
interface enp2s0f0
{
AdvSendAdvert on;
prefix ::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
};
As I said, everything works really well and https://ipv6-test.com repotrs a happy result for clients behind the Arch Linux router.
The problem is that after an hour or so (could be one hour, could be a few hours), the router seems to drop of the network completely for a few minutes. It's not just an IPv6 thing either - trying to ping the router on either 10.0.0.1 or its 99.246 address results in a timeout for about a minute, after which IPv4 comes back without any problems. I then need to restart the dhclient to request the IPv6 IA_PD again, and then IPv6 starts working again as well.
There is no indication of any error in the router logs. Indeed, the router does not show a reboot or anything like that - it's not reachable for a few minutes, and then spontaneously comes back to life.
Nor is there anything in the arch linux logs (just a flurry of "timed out" messages when the router stops responding to requests).
I have also tried a hardware reset of the router, taking it in-and-out of bridge mode, and reseating the coaxial connection. None of those things had any impact. And, I note that the Gateway works reliably in normal Gateway mode with NATs, but I figured those things would be worth a go.
I read in another thread that someone had success changing it from ::/56 to ::/64 prefixes, but that had no impact here (I'm using ://64 since that's what the IA_PD client requested).
Any ideas? This one is killing me, and I'm out of things to try.
07-05-2022 08:44 AM
07-05-2022 08:46 AM
07-06-2022 01:24 PM
I've done more testing - swapping out the NIC in the server, swapping out the DHCP agent software, swapping out the rest of the server and even resetting the modem a few times - and I'm pretty sure now that it's failing modem.
What seals the deal for me is that it's now dropping out for a few minutes every few hours even when reset into standard gateway mode. I'll reach out to Rogers for a replacement - hopefully not too painful.
07-06-2022 02:49 PM
@darrynlowe It might not be a defective modem. Call into Rogers tech support and ask the agent to check your signal levels, the status of your local Node, check for noise in your area, etc. You might have some "neighbourhood issues" that are causing channels to drop, and under certain circumstances, that could cause your modem to reboot. You might need to get your call escalated to a 2nd-level tech. You can also send a Private Message to @CommunityHelps and ask them for assistance as well.
07-06-2022 02:57 PM
Thank you for your suggestion @-G-. That makes sense. I just spoke with the call center, and the agent said he checked the WAN conditions and didn't see anything that would give him pause (with the caveat that it's an intermittent problem with outages that are quite short, so it's hard to be definitive). There also didn't seem to be any alarms from the modem itself.
They've scheduled a tech to come out tomorrow have a look in person -- hopefully it is as simple as a defective box that they can swap over, since if it is not that, then I worry that I'm going to be a vortex of intermittent outages for a long time... fingers crossed.
Any suggestions on anything I should mention to the tech?
07-06-2022 03:19 PM
@darrynlowe From what I have heard, the level-1 techs don't have access to all the tools that are required to fully troubleshoot neighbourhood issues. Rogers also isn't always forthcoming when it comes to acknowledging stability issues with their network. Furthermore, if your support tech dispatched a contractor to troubleshoot your problems, then that tech can swap equipment... but they may not be even remotely qualified to troubleshoot or fix the actual underlying problem, so you may need to wait for an actual Rogers tech to troubleshoot and possibly yet another Rogers senior/maintenance tech to actually fix the problem.
I would send a PM to @CommunityHelps and ask them for a second opinion. They can also ensure that the appropriate tech gets dispatched to investigate (and hopefully resolve) your connectivity issues.