| Author: | John.Marshall@riverwillow.com.au |
|---|---|
| Date: | 13-May-2005 |
| Revised: | 17-Jun-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 articles:
Yesterday morning I found many notices in my Inbox from my Cable link alert job. Our Cable connection had been "down" since 02:30. The lights on the cable modem were OK, but our router had let go of its Internet IP address lease and was not getting any response to DHCP discover requests. I concluded that BigPond had changed the world again, without telling anybody, so I proceeded to follow my method from last year to discover the new BigPond environment.
I started logging DHCP activity and dropped packets activity on our router. DHCP responses were now coming from a completely different Network 10 address (10.143.24.1). I permitted DHCP traffic from that address and obtained a lease. No longer was the address 144.136.n.n; we now had something completely different: 60.225.n.n. The DHCP-configured settings in the router confirmed that this was from BigPond. The DHCP server address was still 172.18.18.80 and the domain was still nsw.bigpond.net.au.
I thought that was all I needed to do until I discovered, today, that the intermittent losses of connectivity on the Cable link weren't due to BigPond outages but were due to the fact that our router couldn't talk to the DHCP server to renew its IP address lease. DHCP Lease Renewal attempts would result in no response, the lease would expire, the router would let go of its Internet IP address and then start the DHCP discover process again. So, we were able to acquire a lease but not renew it. Lease acquisition was courtesy of the DHCP relay in the Cable Router (in this case 10.143.24.1) but lease renewal requires direct communication with the DHCP server. This was really puzzling! I had a route configured to the DHCP server pointing at the router's Internet Ethernet interface. This had worked fine for the past 12 months. After a lot of experimenting, I discovered that I had to change our security model in order to get this to work.
This is the routing security strategy we employed in our perimeter Cisco 1710 router which faces the BigPond Cable network (via the Motorola SB5100 Cable Modem). It worked fine on the DOCSIS network for the past year, but broke after whatever changes BigPond made on 12th May 2005. Evidence documented on this page leads us to be fairly certain that BigPond replaced the local UBR hardware. Ethernet MAC addresses on HFC cards for both the previous and current UBR indicate that both are Cisco devices; so it would appear that we are either a victim of a newer version of Cisco IOS or a change in configuration of the UBR by BigPond.
Here are details of the configuration which no longer works:
Pointing routes at the interface no longer works. Perhaps the IP address and default route configured by DHCP are being configured differently? Since I don't have the luxury of being able to look at what it was like earlier in the week, I shall just have to wonder!
The only way I can configure static outbound routes successfully now is to point them at the Internet Gateway address for our current subnet on the UBR (e.g. 60.225.140.1). That is not an option because this gateway address is a moving target. If our Cable Modem lands on a different HFC channel, the subnet and gateway address change. I have concluded that our only option is to delete the null-routes for the relevant private address ranges, so that those ranges are included in the DHCP-assigned default route - and clog ingress and egress filters with lots of exceptions (sigh!).
We now have a working route to the DHCP Server and our leases renew happily. Wouldn't it be helpful if BigPond would tell its customers when their world was about to change?
The following table displays the cable-side addresses of our local UBR (61.9.207.174). The results were obtained by setting the Cable Modem to select different HFC Downstream channels. The cable modem was unable to acquire and HFC IP address on the 573MHz channel, so those cells have been left blank. It would be easy to extrapolate and "fill in the gaps" but I don't want to publish anything I haven't tested.
| Downstream Channel (MHz) |
IP Addresses | MAC Address | |
|---|---|---|---|
| Primary (DHCP Relay) |
Secondary (Gateway) |
||
| 561 | 10.143.56.1 | 60.225.156.1/22 | 00:0F:35:BE:84:54 |
| 567 | 10.143.48.1 | 60.225.152.1/22 | 00:0F:35:BE:84:55 |
| 573 | 10.143.40.1 | 60.225.148.1/22 | 00:0F:35:BE:84:70 |
| 579 | 10.143.32.1 | 60.225.144.1/22 | 00:0F:35:BE:84:71 |
| 585 | 10.143.24.1 | 60.225.140.1/22 | 00:0F:35:BE:84:8C |
| 591 | 10.143.16.1 | 60.225.136.1/22 | 00:0F:35:BE:84:8D |
| 597 | 10.143.8.1 | 60.225.132.1/22 | 00:0F:35:BE:84:A8 |
| 603 | 10.143.0.1 | 60.225.128.1/22 | 00:0F:35:BE:84:A9 |
The following traceroute output demonstrates the use of private addressing in the BigPond Cable infrastructure network. The first hop is BigPond's Cable Router (UBR).
| 1 | 10.143.24.1 | 12 msec | 8 msec | 12 msec |
| 2 | 192.168.8.1 | 12 msec | 12 msec | 16 msec |
| 3 | 172.18.22.53 | 28 msec | 16 msec | 12 msec |
| 4 | 172.18.22.36 | 16 msec | 32 msec | 24 msec |
| 5 | 172.18.22.33 | 24 msec | 48 msec | 36 msec |
| 6 | 172.18.18.8 | 20 msec | 16 msec | 12 msec |
| 7 | 172.18.18.80 | 12 msec | 32 msec | 16 msec |
| 26-May-2005 | Original Document |
|---|---|
| 10-Jun-2005 | Added more data to UBR Address Table
following additional measurements, edited its preceding paragraph accordingly, and
moved them both to the foot of the page. Added table showing route to DHCP server. |
| 17-Jun-2005 | Added address information to 573MHz channel in UBR Address Table. Following an outage in the early hours of this morning, this channel is now working. |