| Author: | John.Marshall@riverwillow.com.au |
|---|---|
| Date: | 10-Jun-2004 |
| Revised: | 26-May-2005 |
This page describes what I have observed in the context of our own BigPond Broadband Cable connection. My observations are offered for the interest of others and are confined to the following context:
This article assumes a basic knowledge of the cable network as outlined in our previous article, DOCSIS, DHCP and Firewalls.
Solutions documented on this page worked for us until 12-May-2005 when BigPond changed our world by replacing our local UBR. See our subsequent article on DHCP Lease Renewal Problems for further details.
Yesterday morning I noticed that the cable modem's Online light was flashing: Power, Receive and Send lights were all on solid. A quick check confirmed a lack of Internet connectivity. After about 10 minutes the Receive, Send and Online lights extinguished, the Recieve light blinked a few times and then changed to On, the Send light blinked a few times and then changed to On, and the Online also light blinked a few times and settled back to On. "Ah good!" I thought, "We're back on the air!" Not so!
I checked the cable modem's status pages and noticed that it had selected a new pair of downstream and upstream cable channels. I checked the router - the WAN port was still configured with its public IP address, and the DHCP lease still had another half hour or so to run. BPALogin was retrying login every minute without success. It is not an uncommon thing for the heartbeat server to disappear from time to time, but even then it is still possible to talk to the BigPond DNS and FTP servers. This time, there was no DNS and no FTP either - we had absolutely no IP connectivity...
The short answer is that you land on a different subnet:
A DHCP timer on our router's WAN interface fired and it started trying to talk to the DHCP server. No joy - it didn't have a route. Then, I started seeing BOOTP replies coming from 10.128.132.1 - my firewall rules only permitted DHCP traffic from 10.128.136.1 and I wasn't seeing anything from it. I decided to permit that traffic and watched the router's WAN interface come up in a different subnet (144.136.100/22 instead of 144.136.104/22). After that, I could once again talk to the BigPond DNS and FTP servers, and BPALogin found the authentication server and logged me in. We were back on the air.
Noticing that the previous and current private and public IP subnets were adjacent to each other, I conducted some experiments in which I forced the cable modem to change downstream and upstream channels. I concluded that:
I discovered 4 adjacent Downstream Cable Channels on our local UBR, across which 20-bit IP network allocations had been distributed in consecutive 22-bit subnets. There may well be more channels involved. The following table shows my findings.
| Downstream Channel (MHz) |
IP Addresses | MAC Address | |
|---|---|---|---|
| Primary (DHCP Relay) |
Secondary (Gateway) |
||
| 561 | 10.128.140.1/22 | 144.136.108.1/22 | 00:05:5F:EC:38:54 |
| 567 | 10.128.136.1/22 | 144.136.104.1/22 | 00:05:5F:EC:38:70 |
| 573 | 10.128.132.1/22 | 144.136.100.1/22 | 00:05:5F:EC:38:8C |
| 579 | 10.128.128.1/22 | 144.136.96.1/22 | 00:05:5F:EC:38:A8 |
More firewall rules! We need to permit BOOTP broadcast replies from the Primary (private) IP address on each of the UBR's HFC interfaces. It is also helpful to permit ICMP traffic from those addresses. I noticed that if I log out BPALogin, I start seeing ICMP 3/13 packets returned from the current channel's primary UBR address (10.128.n.1) - that's the UBR telling me "Destination Unreachable: Communication Administratively Prohibited", which provides instant indication of heartbeat/dce-server problems.
The SB5100 cable modem runs its own HTTP server on TCP Port 80 on its default LAN address (192.168.100.1). This server provides access to a handful of status and configuration pages which are very useful for diagnostic purposes. Even during normal operation (when the modem is in bridging mode) it listens for, and intercepts, HTTP traffic addressed to itself. If your router/firewall swallows outbound traffic addressed to private addresses, then you will want to define a host route to this address and a rule to permit http browser access to it. This link should show the status pages on your cable modem.
An ICMP Type 3 packet denotes, "Destination Unreachable". An ICMP Type 3 packet with a Code of 13 denotes, "Communication Administratively Prohibited" as described in RFC1812. A router returns an ICMP 3/13 packet if it drops a packet as a result of administrative filtering.
ICMP Parameters is an IANA "Assigned Numbers" document which lists the ICMP packet Type numbers and their associated Codes.
| 10-Jun-2004 | Original Document |
|---|---|
| 26-May-2005 | Modify Notice at top to include reference to article on UBR replacement |