O Canada! > Canadian > TekSavvy > Constant Ottawa Disconnects, DHCP Issues Not Resolved.

Constant Ottawa Disconnects, DHCP Issues Not Resolved.

You may want to remove your IP from there.

And if you wouldn't mind posting in the »TekSavvy Direct forum so we can look at this.

We have notice lot's of maintenance in Ottawa as of late. It could very well be you are being affected by this.

Martin
--
TSI Martin (Escalations / Social Media) - TekSavvy Solutions Inc.
Authorized TSI employee ( »»TekSavvy FAQ »Official support in the forum )
Follow me on Twitter : @TSIMartin

for what it's worth, my area in Ottawa near the market hasn't had any of these disconnects.

I reside in Gloucester on the St. Laurent2 POI and haven't had any issues here in weeks, myself.

Funny enough, though... On a hunch I checked the Event Log in my firewall and found numerous DHCP renewals on its WAN interface on November 2nd. 31 of them, to be exact. Bunch more on November 1st, too.

My partner and I never noticed any problems, though, and the same IP kept getting re-assigned for each renewal, strangely enough.

I'm on the Richmond Road POI. So there is a pattern developing. What good would taking this to the direct forums do other than letting Teksavvy hide the problem? We have been putting up with this crap for a long time. In August the internet was unusable. Not only was it annoying the outages would often crash my old router so I had to upgrade.

Here would be a great place to explain what is wrong with the DHCP server. The problem has been hidden away for months. Time for a little more openness.

reply to jmck
We've seen the recent stories and all the stories from long ago. Conclusion without a doubt Ottawa is the number one city in southern Ontario for internet problems of all types per capita.

reply to Nemo888
There is NOTHING wrong with the DHCP server.

This is all to do with the way Rogers has chosen to implement TPIA addressing services.

When a modem is powered up on the cable it sends its MAC address to the CMTS to validate it. For Rogers customers, this is easy peasy ... they have their own central database of Rogers customers and Rogers modems can connect anywhere across Rogers footprint. BUT For TPIA customers, there's another database held with the CMTS (so that TPIA's devices are unique to the CMTS they are provisioned on - there's other reasons for that including the lack of access across Rogers network).

Now after being acknowledged the modem then is permitted to ask for its OWN IP address based on its MAC by a commn DHCP server. This is a Rogers internal IP so they can operate the modem and send the provisioning data.

Now the modem will come online for TCP/IP communications and the ISP DHCP will assign an IP (Rogers or TPIA) based on the modem MAC, and system MAC. From here, the system will have access to the internet connection ...

Rogers IPs traffic has open access to Rogers network. TPIA IPs traffic are filtered off at the CMTS router to a POI router.

Providing the TPIA's IP addresses are correctly programmed in the CMTS router, all will be good and everybody gets to the internet by Rogers or TekSavvy.

Now all this is good except ...

When Rogers does a nodesplit, users may be moved to another CMTS. If you're a Rogers user, no biggie, but for TPIA clients, the new CMTS must have its allowed MAC database updated. Fall down number 1 ... Rogers forgets to do this. The modem isn't recognized so config and IP address are dropped.

Assuming that gets done properly, the next stumbling block is with the assignment of the internal IP address ... This requires that the central database of MACs is updated correctly ... Sometimes Rogers messes this up.

Assuming that's done properly the DHCP server database must be updated correctly with the new IPs for TPIA customers.

Then the CMTS router must have its routing tables set up correctly to route TPIA traffic tot he POI router. Rogers seems to forget to do that.

All these steps if not done or done properly cause all kinds of problems like this one.

It looks like in this case it looks like a node split, new IPs not updated by Rogers for the DHCP server. It looks like it's at the system IP level (for the router) that it's failed and not the prior levels.

Apart from beating Rogers over the head with a bat to get them to ensure the DHCP servers are correct, there's not a lot TSI can do. The reality is just continuing to hit them with tickets.

It's the risk of using TPIAs.

So much depends on the specific implementations in the POIs. Wouldn't surprise me at all if each head end is configured differently as they learned, which is why some places don't seem to suffer and others do. In all the things going on, I've not had a single problem out where I am on Fallowfield related to these issues even though I'm now 4 streams up too. Although I know I'm on a comparatively low population node which could have a lot to do with it. They tried combining this area with another into a virtual node several years back and I had 2 weeks of performance hell. They split us back out and it was back to normal.

For a short while I was the only customer on this node and then one of 2 for several months! Back in the days of 1500 kbps down was express and I could only get 1200 flat out!

reply to Nemo888
I am experiencing the same thing. I've had 3 disconnects in the last few hours. Has been happening since mid-last week. Barrhaven area (whichever POI that is).

Is this specifically a Rogers/Teksavvy issue, or does it relate to modem firmware at all?

What is your Internet IP lease times?

reply to Nemo888
This is what it currently shows:

Lease Obtained. . . . . . . . . . : Monday, November 05, 2012 11:47:33 AM

Lease Expires . . . . . . . . . . : Tuesday, November 06, 2012 11:47:33 AM

reply to Nemo888
It probably does NOT relate to modem firmware and is a Rogers signal issue.

reply to josh7878

reply to Nemo888
It's still happening. Not really seeing any pattern yet except it is often a double disconnect. Do other people get the disconnects at the same time? We need a few people's logs here.

Latest disconnects,
Nov 4 20:28:21 WAN Connection: WAN was restored.
Nov 5 05:06:17 WAN Connection: WAN was restored.
Nov 5 05:07:38 WAN Connection: WAN was restored.
Nov 5 13:32:33 WAN Connection: WAN was restored.
Nov 5 22:00:01 WAN Connection: WAN was restored.
Nov 5 22:02:21 WAN Connection: WAN was restored.
Nov 6 06:38:38 WAN Connection: WAN was restored.

Those logs appear to all be from a router. Best to look for logs in the modem itself here.

Wed Nov 07 03:20:58 2012 Critical (3) SYNC Timing Synchronization failure - Failed to acquire FEC f...
Time Not Established Critical (3) DHCP FAILED - Requested Info not supported.;CM-MAC=00:26:24:b...
Wed Nov 07 04:39:47 2012 Critical (3) Started Unicast Maintenance Ranging - No Response received - ...
Fri Oct 19 07:06:13 2012 Critical (3) SYNC Timing Synchronization failure - Failed to receive MAC S...
Wed Nov 07 03:21:03 2012 Critical (3) SYNC Timing Synchronization failure - Failed to acquire QAM/Q...
Wed Nov 07 21:40:30 2012 Critical (3) Received Response to Broadcast Maintenance Request, But no Un...
Fri Oct 19 07:03:40 2012 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=00:26:24:b6...

The logs on the modem aren't great. New router logs are very easy to read.
Nov 6 15:05:04 WAN Connection: WAN was restored.
Nov 6 23:38:24 WAN Connection: WAN was restored.
Nov 7 08:13:40 WAN Connection: WAN was restored.
Nov 7 08:14:41 WAN Connection: WAN was restored.
Nov 7 16:38:42 WAN Connection: WAN was restored.

Are you sure it's not just a router bug?
The modem logs you posted look "normal".

reply to Nemo888
The modem log looks as if it lost RF signal momentarily and no amount of looking at modem logs or signal strengths unless you look at the right moment, is going to reveal that to be the case.