Hello!
I've a strange problem with DHCP Requests with some CPEs and
hope that someone here knows a solution.
There is a uBr7223 with two cable interfaces Cable2/0 and Cable3/0 in a bundle.
Then I've configured an "cable helper-address" to forward DHCP-Requests to a Linux-Host running ISC dhcpd.
Everything works perfectly, but sometimes some hosts could not receive a IP address anymore.
I changed IP-Adresses from my logs to:
xx.xx.xx.xx => offered client-address
yy.yy.yy.yy => dhcp-server address
zz.zz.zz.zz => other IP-addresses
The DHCP-Log is full of:
[code]Sep 19 12:48:58 p3 dhcpd: DHCPOFFER on xx.xx.xx.xx to 00:0e:08:e8:36:05 via yy.yy.yy.yy
Sep 19 12:49:14 p3 dhcpd: DHCPDISCOVER from 00:0e:08:e8:36:05 via 62.249.73.1
Sep 19 12:49:14 p3 dhcpd: DHCPOFFER on xx.xx.xx.xx to 00:0e:08:e8:36:05 via yy.yy.yy.yy
Sep 19 12:49:17 p3 dhcpd: DHCPDISCOVER from 00:0e:08:e8:36:05 via 62.249.73.1
Sep 19 12:49:17 p3 dhcpd: DHCPOFFER on xx.xx.xx.xx to 00:0e:08:e8:36:05 via yy.yy.yy.yy
Sep 19 12:49:22 p3 dhcpd: DHCPDISCOVER from 00:0e:08:e8:36:05 via 62.249.73.1
Sep 19 12:49:22 p3 dhcpd: DHCPOFFER on xx.xx.xx.xx to 00:0e:08:e8:36:05 via yy.yy.yy.yy
Sep 19 12:49:29 p3 dhcpd: DHCPDISCOVER from 00:0e:08:e8:36:05 via 62.249.73.1
Sep 19 12:49:29 p3 dhcpd: DHCPOFFER on xx.xx.xx.xx to 00:0e:08:e8:36:05 via yy.yy.yy.yy
[/code]
On the uBr7223 I switched on
# debug ip dhcp server packet
and got the following messages:
[code]Sep 19 11:21:13.892 CDT: %UBR7200-5-MAXHOST: Interface Cable2/0, New host with IP address 0.0.0.0 and MAC 000e.08e8.3605 on SID 4638 (CM 0000.0000.0000) is ignored.
Sep 19 11:21:13.892 CDT: DHCPD: setting giaddr to yy.yy.yy.yy.
Sep 19 11:21:13.892 CDT: DHCPD: adding relay information option.
Sep 19 11:21:13.892 CDT: DHCPD: BOOTREQUEST from 0100.0e08.e836.05 forwarded to yy.yy.yy.yy.
Sep 19 11:21:13.892 CDT: DHCPD: forwarding BOOTREPLY to client 000e.08e8.3605.
Sep 19 11:21:13.892 CDT: DHCPD: creating ARP entry (xx.xx.xx.xx, 000e.08e8.3605).
Sep 19 11:21:13.892 CDT: DHCPD: unicasting BOOTREPLY to client 000e.08e8.3605 (xx.xx.xx.xx).
[/code]
In the MAXHOST-Error the Interface is Cable2/0, but the CPE is on Cable3/0.
When I do a
[code]#show arp | i 000e.08e8.3605
Internet 62.249.73.160 182 000e.08e8.3605 ARPA Cable2/0
[/code]
looks OK (all CPEs in this list are on Cable2/0)
#clear arp
does not help
When I do a
[code]
#show interfaces cable3/0 modem 4638
SID Priv bits Type State IP address method MAC address
4638 00 host unknown zz.zz.zz.zz static 001d.7ee3.9d44
4638 00 modem up zz.zz.zz.zz dhcp 0090.64c7.deda
[/code]
the cable-modem and another CPE which works fine are here.
In the output of
#show cable tech-support
there is no sign from the CPE MAC 000e.08e8.3605
Now the funny thing:
When I reboot the uBr7223 everything works fine again - I really hate to reboot the CMTS.
A solution would be a "clear something"
I tried allready a lot of clears
#clear cable host 000e.08e8.3605
Clear host command failed. No such host
#clear arp
...
Does anyone know somthing about that problem?
Any tip to watch further is welcome.
maybe CM logs in on a different cable interface and the some cache keeps info that its connected to different interface? seen sth like this on a arris 1000/1500
bind CM to a specific DS frequency and recheck.
but the cable modem is on the right interface and the cable modem has no problems when I switch DS frequency.
It's only CPEs which are not able to fetch an IP-adress from DHCP.
Yes, I believe it's a cache problem, because a reboot of the CMTS solves the problem (which I really hate to do).
I just could not find out which table, which cache or whatever I have to clear.
I cleared allready all the normal things like ARP ...
those logs seem to show the system working. If I'm reading the debug trace right, the first line is just the CMTS setting the modem's SID. Then it is setting up the relay and forwarding the requests over (and back). Are you getting errors or failures in the logs?
The rf side of the cmts should be transparent to the CPE's. The CPE shouldn't care what channel the CM is on, unless there is something funky with the relay where different channels are relayed to different servers or there is enough noise on one channel to cause excessive packet loss.
Are you limiting CPE's per modem and how are you managing it?
I had an issue with a Coresma CMTS, where occasionally a customer would change CPE's behind a modem and the CMTS would deny a new lease to the new CPE even after power-cycling the modem. I was setting the CPE limit in the modem config file. For some reason, some Motorola modems with a particular (outdated) firmware version would not clear their MAC cache even after power cycling. The only solution is to manually delete the modem from within the CMTS and let it timeout and reboot. My CMTS has a 'delete CM' option that completely deletes the modem from the CMTS, including any cached CPE mappings.
If you are limiting CPE's, try removing the limit (or making it really high) and see if things change. I wound up just setting the limit at 2 CPE's and the issue went away.
other thoughts:
Do you have any sort of provisioning in place on the DHCP server and is it currently active?
What is your network topology like?
On the DHCP-server the log does not show any errors - from the CMTS I postet all "strange" lines from debug.
There are no configurations like relay/channels, noise is OK. In general all the modems register normally.
I also checked the CPE limits - had none configured and also tried to configure limit to eg. 10. No change.
There is no pattern. That does not happen only with special modems - we use a couple of different models (motorola, samsung, thomson, SCA). On the ubr7223 there is also a "clear cable modem xxx reset" which kills the modem. I tried everything. ;)
The provisioning-system itself is a web-driven self-programmed system, not bad, btw. ;).
It generates docsis-config files and the dhcp config for the ISC dhcpd.
Network is IMHO a simple setup.
Linux-Gateway with all the services like tftp, dhcp, etc. with a well working connection (2 switches and a 8km fiber-connection) to the ubr7223 headend-router. On the cable-side of the router are 3 networks 1 for the cable modems, 1 with official customer-IPs, 1 with NATed customer-IPs. The IP setup is the same since years. I *think* the problems started when we plugged in the second MC11 card and made the bundle - but I'm not sure.
Anybody?
So i've got the same problem with a CMTS, but this one is working itself as a DHCP-Server. Although are we thinking of "outsourcing" our DHCP to a Linux-box. Maybe this might solve the problem.
No problems with attached cable modems, all working well, but several CPE/hosts are coming in via log with:
Feb 25 08:55:32: %UBR7200-3-OVERLAPIP: Interface Cable3/0, IP address xx.xxx.xxx.xxx from MAC yyyy.yyyy.yyyy is already in use on Cable3/0. SID = 341
Feb 25 08:55:43: %UBR7200-3-OVERLAPIP: Interface Cable3/0, IP address xx.xxx.xxx.xxx from MAC yyyy.yyyy.yyyy is already in use on Cable3/0. SID = 341
Feb 25 08:55:45: %UBR7200-3-OVERLAPIP: Interface Cable3/0, IP address xx.xxx.xxx.xxx from MAC yyyy.yyyy.yyyy is already in use on Cable3/0. SID = 341
What looks like spoofing-attack on the first sight, is a ATA from Linksys, behind a cable modem and trying to get the same IP every second (seems to be like this?!). It's not only one device that acts like this, there are many more trying the same for hours. And - of course - the customers are not very amused...
I'm not sure who produces this shit, i tried some wiresharking but didn't get a response. Maybe the CMTS likes to kill some DHCPDISCOVER-messages (because there are no and if we get one from another clientm, which acts normal, it also gets an IP-address)...
I'm thinking of writing a little letter to Cisco, because both boxes are manufactured by them (or Taiwan)... just to let my feelings (pain) about this theme out to someone who gets paid for it...
regards from norway
daniela
Not so long ago I was debuggin alike problem.
After rebooting cisco uBR7114e it tool ages for cable modems to get their IPs. What I found out is that there was a grand (4-5 secs) delay between the time when a cable modem sent a DISCOVER and the time when it received an OFFER. The delay was being produced on cisco when it had to forward the OFFER to cable modem. It looked like cable modems were not eager to wait 4-5 seconds for an OFFER and were sending another DISCOVER before cisco could do anything.
The solution I've found was to stop the dhcp for a couple of seconds, and start it again, so that the first cable modems who sent a DISCOVER after restart would get its OFFER after and ACK without a significant delay... So, I was resetting a dhcp over and over until everything was getting back to normal.
that's what i also thought of, that the problem may be some misunderstandings (timing, message delay and so on) between CPE/host and CMTS. But it seems as if some CM have assigned their own static IP's (with or without help) and others also try to use the same.
It's one idea to take a further look on those devices (whether these are always the same) and to check, how in gods name they have the right to reserve addresses (so they're actually not assigned via DHCP or configured static via CMTS).
*sigh*
btw, our "born-from-hell"-devices don't send a friendly "discover", they send a DHCPREQUEST...
sh inter cable 3/0 modem 0 | i static
2 11 host unknown IP xx.xx.xx.xx static MAC xxxx.xxxx.xxxx
14 11 host unknown xx.xx.xx.xx static xxxx.xxxx.xxxx
18 11 host unknown xx.xx.xx.xx static xxxx.xxxx.xxxx
19 11 host unknown xx.xx.xx.xx static xxxx.xxxx.xxxx
32 10 host unknown xx.xx.xx.xx static xxxx.xxxx.xxxx
49 11 host unknown xx.xx.xx.xx static xxxx.xxxx.xxxx
99 11 host unknown xx.xx.xx.xx static xxxx.xxxx.xxxx
123 00 host unknown xx.xx.xx.xx static xxxx.xxxx.xxxx
125 11 host unknown xx.xx.xx.xx static xxxx.xxxx.xxxx
141 11 host unknown xx.xx.xx.xx static xxxx.xxxx.xxxx
143 11 host unknown xx.xx.xx.xx static xxxx.xxxx.xxxx
441 11 host unknown xx.xx.xx.xx static xxxx.xxxx.xxxx
455 00 host unknown xx.xx.xx.xx static xxxx.xxxx.xxxx
blablabla...
that was interesting to read regarding DHCP and ARP:
http://www.cisco.com/en/US/tech/tk86/tk89/technologies_tech_note09186a00...
Hello,
Can it be because of ISC DHCP leasequery ?
We tested almost the same yesterday, asked a cm to change DS (wanted to test some DS LB), it rebooted and came online again but the clients couldnt come online. Do a dhcp release / renew and it worked again. We havent had the time to debug further into the problem yet.
Try to do a dhcp release / renew, see if it works. If thats the case, look into the leasequery setup.
Martin
DK
Do you have any link regarding this Arris problem?
Perhaps I missed it, but but does the CPE receive the DHCP offer? A wireshark capture between the CM and the CPE would show that or not.
Frank
I made a wireshark capture between CM and CPE.
DHCPOFFER reaches the CPE and CPE sends a DHCPREQUEST which does not reach the DHCP-server.
I'm sure that the DHCPREQUEST is killed by the Cisco ubr7223.
Wireshark capture on the FastEthernet-side of the ubr7223 brings no DHCPREQUEST.
I'm allready sure that this problem comes, when I change the DS-frequency of the modem.
The modems themself have no problems with the frequency change, but the CPEs behind sometimes have those DHCP problems.
I did not do enough tests to reproduce that - it's also hard to reproduce because it happens seldom. But when it happens this CPE does not come online until I reboot the ubr7223. Another solution is to change the MAC address of the CPE.
I know sounds strange ;)
I'm not a Cisco guy, but have a quick question to the person who opened the post.
the dhcp request is a braodcast, the cpe would have a public address ( the norm unless you do NAT).
from the dhcp server, can you ping the cpe gateway?
did the wireshark show a reply to cpe going to the right interface/network?
my thought is the dhcp server knows one cpe network behind the cmts, but not the other?
is the dhcp offer for that network right ( possible config error with subnet mask or gateway)?
~Carl
We had a similar problem. The error message on the CMTS is quite confusing, though. The reason for this happening was not reaching the max-cpe for a CM, but that our DHCP incorrectly duplicated IPs and gave the same one to two different clients. The second one wasn't able to access the internet, and the CMTS (incorrectly) reported the UBR7200-5-MAXHOST error. Another reason for this is duplicate CPE MACs.
Rebooting the UBR solved the problem because the duplicate leases were cleaned by the DHCP.
-----------------------------------
http://www.net1.cc