dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
1
share rss forum feed


sbrook
Premium,Mod
join:2001-12-14
Ottawa
kudos:13
Reviews:
·WIND Mobile
·TekSavvy Cable
reply to Nemo888

Re: Constant Ottawa Disconnects, DHCP Issues Not Resolved.

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.


mlord

join:2006-11-05
Nepean, ON
kudos:13
Reviews:
·Start Communicat..
·TekSavvy Cable

said by sbrook:

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).

There must be something more to it than just that last sentence -- I can take my TSI Modem to a different CMTS and it still works just fine, thanks. So it's not locked to the CMTS, but perhaps it is locked to the POI instead?

There's another surprising point in there: with aggregated POI for TPIA, one might expect a lot of those fail points to vanish. But according to both TSI (non aggregated) and Start.ca (aggregated POI), the need for CMTS-specific IP addresses and CMTS-specific DHCP still remains. Weird. I'd have thought the aggregated POI would result in everything going to, say, a central MAC database for TPIA just as it does for Rogers clients.

Cheers

mlord

join:2006-11-05
Nepean, ON
kudos:13
Reviews:
·Start Communicat..
·TekSavvy Cable

said by mlord:

There must be something more to it than just that last sentence -- I can take my TSI Modem to a different CMTS and it still works just fine, thanks. So it's not locked to the CMTS, but perhaps it is locked to the POI instead?

Actually, on reflection, I bet the answer is "both."
The modems probably are locked (or "local") to specific CMTSs, but not just a single CMTS -- the teksavvy modem database likely gets replicated in part/whole across many CMTSs in the region.

I say this because when I had an 11-day outage here this past summer, my modem did work on other CMTSs off the same POI, just not on my own local CMTS for some reason. So that does support the "local to a CMTS" theory, though likely several CMTSs, not just a single CMTS.

Cheers


sbrook
Premium,Mod
join:2001-12-14
Ottawa
kudos:13
Reviews:
·WIND Mobile
·TekSavvy Cable

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!