Good morning @mozerd.
Voicing your needs and suggestions for changes to our service here is one of the better ways to be heard. We understand better than anyone that our super users have needs and wants for their home network that go beyond that of the average user.
I would not suggest escalating to the Office of the President for this. It is not something that they have the power to change immediately and they are a group that is intended to handle customer escalations for issues that our front line support has been unable to resolve. They are not technical support experts (or well versed in this type of expertise) and would not be able to help troubleshoot a custom made router setup using PfSense.
Please also understand that customizing your own third party networking equipment is not something that we directly support. Our primary intention is for customers to connect using our gateway, removing the gateway entirely might "work" if you have an ONT but once you remove the gateway, you're no longer using an officially supported setup. The kinds of setups being discussed in this thread are considered unsupported and thus our Office of the President would not be well suited to provide support.
Regards,
RogersCorey
I agree. From an IP point of view, it should make no difference on how you connect.
BTW, I was surprised to see me listed as a reference on the dslreports thread. While I have done some work for Rogers, I have never been an Rogers employee. The closest I've come to that was when I worked for Unitel and Rogers was part owner.
That said, Roger can be difficult to work with at times. A little over 5 years ago, I had a problem where IPv6 stopped working properly. I was running pfSense for my router/firewall. Through my own testing, I knew the problem was not in my equipment. For example, I could try to ping something like Google and I'd see the ping go out, but no response. I also tried pinging my own network from a different connection. I could ping my WAN interface, but nothing on the LAN, as those packets weren't even reaching my router. This indicated a routing problem with my prefix. I then called 2nd level support (I rarely waste my time with 1st level, as I know more than they do) and demonstrated the issue to them. They agreed it was a Rogers problem, but those responsible refused to do anything as I had my own router. This despite the fact that the same issue affected my next door neighbour and he only had a single computer connected to the cable modem, which was in gateway mode. I complained to the office of the president and a senior tech came to my home. He brought his own modem and computer and experienced the same problem. He then went back to the Wolfedale office and tried with 4 different CMTS and it worked OK with 3, but not the one I was connected to, the exact same one that I had identified by host name, with my own testing, before he showed up. I had even provided him with a packet capture, showing the error message. With him now being able to show that my CMTS was failing, he was finally able to get those responsible to get off their butts and fix the problem. It's been fine ever since.
Incidentally, last year I was doing some work in the Wolfedale office, including around my CMTS.
@mozerd wrote:
this is really a very minor configuration issue but it requires a knowledgeable person to make the appropriate configuration regardless of the access method and only the NOC can get the resource working on that.
Maybe; maybe not.
On the DOCSIS side, Rogers originally only offered a /64 prefix:
At the moment, the delegated prefix length is limited to a /64. We understand that some of you are eager to get a larger prefix in order to take advantage of some of the advanced functionalities IPv6 has to offer. Now that we have completed the rollout, our engineering teams are currently assessing the effort required to enable this functionality.
Obviously, they were able to get this resolved and enable us to request a larger prefix.
I don't know what routing infrastructure Rogers is using for their XGS-PON FTTH customers. If someone who is using their own router/firewall would be so kind as to display their ARP table and post the OUI portion of their default gateway's MAC address, that would reveal the manufacturer of the next-hop router. If Rogers happens to be using the same routing infrastructure for XGS-PON as their mobile networks, that may be what is limiting them to issuing a /64 PD.
@-G- wrote:
If someone who is using their own router/firewall would be so kind as to display their ARP table and post the OUI portion of their default gateway's MAC address, that would reveal the manufacturer of the next-hop router.
Given Rogers moving to IPv6, that might not work as ARP might not be used. With IPv6, you can list neighbours or their MAC addresses. If possible, do a packet capture, so you can see what's happening.
@JKnott wrote:
@-G- wrote:
If someone who is using their own router/firewall would be so kind as to display their ARP table and post the OUI portion of their default gateway's MAC address, that would reveal the manufacturer of the next-hop router.Given Rogers moving to IPv6, that might not work as ARP might not be used. With IPv6, you can list neighbours or their MAC addresses. If possible, do a packet capture, so you can see what's happening.
I was referring to the ARP table for IPv4. I'm not picky about how we ID the router at the next hop. 🙂
@-G- wrote:
I was referring to the ARP table for IPv4.
Problem is there might not be any native IPv4. The trend is to do everything with IPv6, including encapsulating IPv4 in IPv6. Some other ISPs are doing this. I don't know about Rogers cable, but it's certainly the case with their cell network. My cell connection is IPv6 only, with 464XLAT used for IPv4, which converts IPv4 to IPv6, when needed for IPv4 only sites. That's why I suggested a packet capture, if they can manage it, to see what's actually going over the wire (fibre). Packet capture is easy enough to do with pfSense or OPNSense. Then use Wireshark to examine the packet.
@JKnott XGS-PON could still be a dual-stack IPv4/IPv6 service. Yes, IPv6 + 464XLAT for IPv4 is a possibility but I have not seen any FTTH customers reporting any limitations that would be associated with that implementation.
Right now, I'm just looking to see if we can get any hints as to why Rogers might currently be limited to issuing a /64 PD to FTTH customers.
@JKnott wrote:
@-G- wrote:
I was referring to the ARP table for IPv4.Problem is there might not be any native IPv4. The trend is to do everything with IPv6, including encapsulating IPv4 in IPv6. Some other ISPs are doing this. I don't know about Rogers cable, but it's certainly the case with their cell network.
On the cable side, even with the move to Casa DAA / R-PHY nodes and virtualized (vBNG) routing, it is still native dual-stack IPv4/IPv6.
-
14345 views
-
36 Likes
-
-
