| Attachment | Size |
|---|---|
 cpu_ubr10k.JPG | 81.19 KB |
Dear I am experiencing high usage of cpu in a cts cisco ubr10k with pre-4. It seems that the problem is in traffic and not in processes. Someone has an idea of what causes it. In the attached command the traffic was around 700mbps.
Thank you, Flávio.
adj resolve proc is your culprit
here is a description of what it does:
https://supportforums.cisco.com/discussion/11800886/need-information-abo...
and here is a bug for it, even though this lists 15.x IOS it also applies to 12.2.33 IOS too.
https://quickview.cloudapps.cisco.com/quickview/bug/CSCty72704
Basically your mac broadcast domain is too large and/or someone is scanning your network causing your CMTS to spend too much time doing arp requests.
you can:
split up your traffic into multiple Bundles (effectively splitting your broadcast mac domain)
turn on dhcp lease query AND no cable arp
no cable arp and dhcp lease query solved the problem for us, but your mileage may vary.
Thanks,
Jason
With no cable arp and dhcp lease query, do you worry that your CMTS dataflow is now dependent on the uptime of your DHCP software?
Do you run a single DHCP server, or have a cluster?
First off should have been cable source-verify dhcp, rather than dhcp lease query, though dhcp lease query is part of cable source-verify dhcp.
Do you run a single DHCP server, or have a cluster?
We run two dhcp servers in a small cluster that can failover.
do you worry that your CMTS dataflow is now dependent on the uptime of your DHCP software?
Yes and No, the dhcp server is vital to the network, but in the cable source-verify dhcp scenario, is less vital. with cable source-verify dhcp and ip dhcp relay information option on, when the CMTS sees a dhcp transaction it updates the ARP tables with the information, for the duration of the lease. So the only time lease query is involved is when traffic that did not dhcp on you network tries to traverse your network. i.e. customers who have statically assigned themselves an IP. This could also include your static customers as well, in which case you would need to add a cable trust for each one. If the DHCP server were to go down only customers whose leases have expired or customers who are trying to get on are affected, exactly the same as with cable arp on.
see this doc on the logic behind cable source-verify http://www.cisco.com/c/en/us/support/docs/broadband-cable/cable-security...
The ultimate problem is that the mac broadcast domain is too large for the PRE 4s or rather there is too many unused ips in your mac broadcast domain, if your like me, you created a /16 for your modems to use and everything went smoothly, till some knucklehead customer got a virus and started trying to connect to all of the unused ips in your /16 causing an Arp storm. Resubnetting your modem subnet to be closer in size to your modem customer base will go a long way to solving the problem. It is also possible that an upgrade to a PRE 5 could help as well. The other thing that Cisco recommends is to add a second ip bundle and move some ips there which may or may not be possible in your scenario, it wasn't in ours.
After switching to no cable arp, we had about 2-3 days of increased call volume and then notta.