Ok here's a strange problem.
We're unable to ping modems directly from the CMTS to the modem private IPs. As a result we're seeing a number of modems unable to get past init(d) during initialization because the CMTS cant communicate with them.
Also DHCP does not see the DHCP request.
What makes this issue more complicated is that we're able to ping to these modems private IPs from other locations within the network.
Tracing to the non-routable modem IP shows the CMTS as the hop just before the modem as one would expect.
There's plenty of IPs available in DHCP, some modems are online until they're power cycled or reset.
We see CPE traffic to and from the Internet.
Also, I'm able to communicate with the modems at the docsis layer (ping docsis )
Update: After reloading the CMTS, we regain the ability to ping modems and they are able to communicate to DHCP once more.
This has happened on / off for the last few weeks. Things work great for a while then everything goes down hill.
Cisco Internetwork Operating System Software
IOS (tm) 7200 Software (UBR7200-K8PU2-M), Version 12.3(21a)BC1, RELEASE SOFTWARE (fc1)
Any suggestions?
We have experienced the problem you are describing, but ours has not been intermittent and it always has been a subnet/routing issue.
I would also check and make sure that DHCP is handing the right gateway/subnet to the modems, maybe a partictular policy is misconfigured? If the modems are getting the wrong gateway/subnet they will send the initial dhcp request (broadcast), but be unable to communicate further.
Other than that, not much I can think of, does your cmts have multiple blades? does the problem occur on a specific blade or specific port? We have had bad blades sometimes cause weird problems like this.
Do you have dhcp source-verify on? if so does your dhcp server support it?
Any chance you could post your bundle/blade configuration specifically dhcp related items?
What dhcp server are you using?
Thanks for your response.
I'm thinking routing/subnet issue also but so far we haven't found any misconfiguration in that regard.
DHCP policy's look good although we sort of ruled this out only because we're thinking we should see the problem right away rather than after a few days of uptime if DHCP policy's are at fault.
We're running CNR for DHCP (Network Registrar 6.0.5.4 nightly build #341938)
Unfortunately it happens across all cable interfaces and both private IP blocks.
We're thinking of swapping the entire CMTS chassis if nothing else resolves the problem.
ubr1#show running-config interface bundle 1
Building configuration...
Current configuration : 815 bytes
!
interface Bundle1
ip address x.x.x.x 255.255.255.0 secondary
ip address x.x.x.x 255.255.254.0 secondary
ip address x.x.x.x 255.255.255.0 secondary
ip address x.x.x.x 255.255.255.0 secondary
ip address x.x.x.x 255.255.254.0 secondary
ip address x.x.x.x 255.255.254.0 secondary
ip address 10.50.10.1 255.255.255.0 secondary
ip address 10.18.20.1 255.255.248.0
ip route-cache flow
cable arp filter request-send 3 2
cable arp filter reply-accept 3 2
cable dhcp-giaddr primary
cable helper-address x.x.x.x (Valid DHCP IP )
end
You have a debug modem in your network ? maybe this can show why the modems cant communicate with the DHCPserver.
Also, cable IOS supports the command : cable monitor
what way you can span traffic from a modem out to a server using Wireshark, decoding DOCSIS pack.
http://wiki.wireshark.org/CaptureSetup/DOCSIS
Have you, just for fun, tryed another DHCPserver ? maybe an ISC dhcpserver, just to see if the modems come online ?
Once, ive experinced similar problem, random modems came online but some count'nt get an IPaddress, this was do to
an option missing in ISC DHCPserver, option wasnt default in the upgraded version of DHCPservice :/
Martin
DK