@zed wrote:
I am at my wit's end.
For over 5 weeks since we installed Ignite , we have had unreliable service. Outages at least once a day, often more.
Technicians have come out over 5 times. They have: replaced the wire from the pole, the wire into the house. multitude of monitoring, checked the installation of devices, cleaned up the old amplifiers and splitters. All but replace the modem.
To no avail.
Phones calls are mounting into the 10s of hours with these people who do not care enough. They keep to their textbook care and escalation protocol.
When the internet drops we are disconnected from our offices, VPN and VOIP phones. Reset always has been to re power the modem. Funny the modem light stays WHITE.
This is seriously affect my business, is professionally embarrassing and raises the frustration factor worse in this COVID time.
WHAT IS A POOR CUSOTMER TO DO?????????
(I didn't pick this post for any specific reason, and this is also a very general reply.)
Some of you have said that this must be a "widespread infrastructure issue", but I can assure you that the "Internet keeps dropping" problem does not affect everybody everywhere.
I'm generally not a huge fan of all-in-one gateways from a technical perspective, primarily because their performance tends to be "average" in most respects. I also use Ignite TV over my own network infrastructure, with the XB6 in Bridge Mode. However, if I ever run into a problem, I disable bridge mode, and ensure that the problem replicates before calling into Rogers for support. I completely eliminate any of my own equipment from the troubleshooting process.
If you are experiencing connectivity drops, it could be WiFi-related, it could be the coax Internet link, an upstream problem, or it could be a problem with the modem itself. If you see connectivity drop out on WiFi, and can also confirm that on an Ethernet-connected computer and using the modem's internal troubleshooting tools, that puts the problem squarely in Rogers's court, regardless of whether they can see any evidence of the problem using their testing tools.
If you are seeing connections drop on WiFi but do not see a connectivity drop on Ethernet or with the modem's troubleshooting tools, that puts the problem in your court, and there may not be much that Rogers can do on their own to help.
Your modem will also report connection drops (that it sees) in its Events log. If you are seeing critical DOCSIS event errors getting logged, it is (most likely) caused by a problem on Rogers' side.
VPN and VoIP-related issues can also be very tricky to troubleshoot, and those network applications/protocols can be unstable when the network is under extreme load. VPN sessions can drop due to problems anywhere on the network path.
If you are using Ignite WiFi Pods, understand that your WiFi connectivity will become even more unstable and unreliable if the Pods are not installed in the correct location.
I have also isolated problems on Rogers end that they could not initially see, and documented them so that could be escalated and eventually fixed.
Even if the problem is on your side, Rogers can still assist you in troubleshooting and resolving your connectivity issues. However, unless the root cause of your particular problem can be isolated or the scope can at least be narrowed, your connectivity issues will never get resolved.
@88dalejrfan In January/February, 2020, like many other people at the time, I was seeing extreme latency spikes and packet loss that got bad enough that it affected Ignite TV. There were no problems with my modem's signal levels, no problems with noise in my neighbourhood, and no errors of any kind in my modem's log. No uncorrectable codeword errors were getting logged either. The signal to my modem was totally clean and there were no issues in my house. The problem was that Rogers could not see any issues at there end either.
It got to the point where the latency spikes on a few occasions exceeded 12,000 ms. Yes, for 12 seconds, packets were just getting stuck in the network somewhere.
Here's what I did:
On my Linux system, I set up continuous, concurrent, simultaneous pings, in separate windows to my router, to 8.8.8.8, and to my local CMTS router. (On Linux, I can measure a 12000ms ping response; it does not get reported as a lost ping. The ping response to the CMTS router took longer than the corresponding ping to 8.8.8.8, also indicating signs that the processor card on my CMTS router was under extreme load.) When there was a latency spike, I could see EXACTLY where is was (and was not) occurring, and it was only visible on the simultaneous pings to 8.8.8.8 and to the CMTS router. It was not a problem with my WiFi or anything in my home.
I then set up a traceroute on my XB6 to 8.8.8.8 and I waited for the next latency spike to occur. When I did not see an immediate ping response from 8.8.8.8, I clicked "Start Traceroute" on the XB6. That caught a response of 4500 ms from the CMTS router, but every other successive hop following took < 15 ms.
I caught an intermittent problem where my local node stopped forwarding packets, from time-to-time, for several seconds at a time. I used tools that would take my WiFi and an-home network out of the picture, and used the tools on the XB6 to confirm the problem and pinpoint exactly where it was occurring.
You also need to understand how your own troubleshooting tools work, know their strengths and limitations, and bring tools into the mix that Rogers trusts. Only then can they submit an escalation ticket that can be acted on by Engineering. I'm not bashing tools such as PingPlotter. However, sometimes the simplest of tools, when used correctly, are the most effective.
@88dalejrfan wrote:
Could you tell me how to determine the address of the local CMTS router? Is this the next hop in the network from my router's address?
If your modem is in bridge mode, yes. Otherwise it would your modem's default gateway address.
@MisterPinst wrote:
I have a ticket now that starts with "CT" and is followed by 8 digits. Is that an engineering ticket? I've honestly been as patient and as scientific, data-oriented as I can with this but I'm starting to get frustrated.
I think that this is the only kind of ticket that can get created on our behalf. What matters is that it gets escalated internally to the right team, and that it ultimately has information that can be acted on by whatever team is responsible for resolving it. And, yeah... sometimes issues, such as these, can take a while to get fixed but they eventually will.
When you folks called into Rogers and were told that everything tested fine, did your support agent ever consult with (or transfer you to) a 2nd-level tech, who has access to additional stats and tools?
If not, send a Private Message to @CommunityHelps and get them engaged. They can also check to see whether your local node is overloaded or if there are any other issues in your area that could be impacting your service.
@88dalejrfan I sent my findings and test results to @CommunityHelps and asked if they required any additional information. They asked a few more questions, I passed on more information, and they created a ticket on my behalf so that the issue could be investigated. And then I waited.
I don't know what could be causing the problems affecting your service but I like working with the CommunityHelps team because I can type up my findings, attach screenshots, etc. and they can then copy this information verbatim into the ticket. Having spent my career in this field, I know what information the engineering teams need to know and I try to pass on whatever helpful information that I can. I also use Telephone Support for simpler issues but for more complex things, you run the risk that an inexperienced tech won't fully understand the problem or that critical information will be omitted when they rush to create a ticket in the time that they have allotted to them.
You can log into your modem to check error logs and verify that your signal levels are within range:
This article has other great tips but keep in mind that if your problem is intermittent, the traceroute command likely will not be helpful in pinpointing latency on the network path, and may even provide misleading information. You should also run your ping test for one hour (3600 seconds) to get a more accurate and more useful statistics.
-
231270 views
-
200 Likes
-
-
