I'm seeing an odd problem on a Cisco UBR10012 K regarding my EMTA based modems.
I assign the following, 10.10.0.0's to CM only's. 10.20.0.0's to CM portion of EMTA and 10.30.0.0's to MTA portion of EMTA.
ARP timeout is set to 43200 on CMTS (12 hours), DHCP set to 12 hours on EMTA subnet, ARP entry is being expired on the MTA portion, fix is to set DHCP timeout to less than ARP timeout, however I want to actually push these out to weeks, like my CM expiry.
I've noticed on the CMTS
Internet 10.10.2.91 14460 14c0.3ec3.1493 ARPA Bundle1
Internet 10.20.2.143 30370 e889.2c9f.90b7 ARPA Bundle1
Internet 10.30.3.40 529 acb3.13e0.beca ARPA Bundle1
10.10 and 10.20 seem to have infinite arp, while 10.30 and other ip's respect the arp timeout specified on the BUNDLE interface.
arp timeout 43200
What tells the CMTSS to exempt the 10.10/10.20 subnets from it's ARP expiry, I would like to exempt 10.30, I don't see anything on the CMTS to cause this behavior, or in the Docsis configs, any hints would be great.
You shouldn't need to adjust default ARP timeout.
If you are fiddling ARP to fix a problem, it's the other problem that actually needs to be fixed.
Please show your bundle1 running configuration.
I removed the Public Secondary blocks from the bundle1 interface below.
interface Bundle1
ip dhcp relay information trusted
ip dhcp relay information option-insert
ip address 10.20.1.1 255.255.0.0 secondary
ip address 10.10.1.1 255.255.0.0 secondary
ip address 10.30.1.1 255.255.0.0 secondary
ip address 10.40.0.1 255.255.255.0 secondary
ip address 10.50.0.1 255.255.255.0 secondary
ip helper-address 172.25.0.34
cable arp filter request-send 20 2
cable arp filter reply-accept 20 2
no cable arp
cable source-verify
cable dhcp-insert service-class
cable dhcp-giaddr policy
arp timeout 43200
end
I also just logged into one of the modems where the MTA portion has lost connectivity, ARP entry gone in CMTS, I dropped the DHCP timout to 6 hours, when it hit the 3 hour mark it requested and received a new lease, however no new ARP entry was placed in the arp table on the CMTS. Had to reboot modem to get it to get back in to the ARP table. Somehow the ARP entry is getting lost on the MTA, not sure why. I think I'm missing something like a keepalive, to keep it in the ARP table, DHCP traffic alone doesn't seem to put it in the ARP table after it times out.
no cable arp is most likely your culprit, without that on the CMTS ignores any arp requests from Cable interface. The command reference is a little unclear, but I also believe it applies to cable modem integrated components like eMTA, eSTB, eRouter etc. the CM and CPE devices can get arp entries with persistent polling/use from subnets that request ARP via the NSI (network side interface) but MTAs (depending on your mode of operation) don't usually get traffic from outside unless there is a call. And since you do not have cable arp turned on when the MTA DHCPs it is not added to arp table.
https://www.cisco.com/c/en/us/td/docs/cable/cmts/cmd_ref/b_cmts_cable_cm...
Thanks for the reply, yes I believe that is the issue also, however it really brings the CPU down with the "no cable arp" specified on the bundle. I think it is related to the difference between "cable source-verify" and "cable sourc-verify dhcp". Cable source-verify keeps the entry in the arp table until arp expires and doesn't get put back into arp table until new DHCP request, so there is a time when arp entry doesn't exist and new packetcable doesn't trigger putting it back in arp table when "no cable arp" is active with cable source-verify. I think cable source-verify dhcp would keep them in the arp table, but my DHCP server doesn't support that on static ip entries, so I can't use that.
I wish I could activate cable source-verify dhcp on some IP blocks but not others, since I have subnets allocated for static assignment. I wonder if this something I could do with multiple bundles. Use leasequery on everything but my static block assignments.
I wonder if the SAV will work, if I specify the prefix for the MTA assignments. If this will work in conjunction with cable source-verify in the bundle1.
In Global
cable source-verify enable-sav-static
cable source-verify group
prefix 10.30.0.0/16
In Bundle1
cable source-verify
Yea, I think the problem here is using the combination of "cable source-verify" and "no cable arp", cable source-verify does not "refresh" the arp entry for the mta host, so the arp entry expires until a new dhcp renew is sent from the MTA, so this doesn't work. I believe "cable source-verify dhcp leasequery" works differently, if it receives a packet then it does a LQ and adds it to the ARP table if it does not exist, whereas "cable source-verify" has to wait until the next actual DHCP request, resulting in the potential of a time period between DHCP request where the IP could have expired from the ARP cache, making the MTA lose dialtone.
So I need to figure out how to make this work, without enabling arp, and without being able to use leasequery at this time, without exending arp timeout to infinity.