Clearing Arp-Cache brings ping but after 5 minutes it stops again

[simoesmarco8626982]

Hi all,

hope to find everyone well

I'm currently having a really, weird, weird issue with a Cisco 3650 with the SVI 10.5.40.254 and some equipment. 

Basically, I have some radios connected to this switch where the radio is 10.5.40.39 and this radio islinking to two other radios, and this is bringing some CCTV cameras. The issue is, I do pings from the network 10.1.40.0 where a computer is located and precisely after 5 minutes the remote computer stops timing out the pings to the radio 10.5.40.39, but if I do a ping from the core 10.5.40.254 the pings are constant. If I pint this radio from another part of the network I get replies and timeouts. And for things to become even weirder, despite having constant timeouts to the radio 10.5.40.39 from the computer, I can still browse to the webpage of the radio and do changes.

To "solve" the issue, found that clearing the arp-cache on the core 10.5.40.254 for the IP 10.5.40.39 puts the pings from the computers to 10.5.40.39 and the connection to the cameras that are in this link stabilize. After 5 minutes tough, everything starts again, timeout to the radio 10.5.40.39 and packet being lost to the cameras that use this radio to return. If I clear the cache again the system stays ok again for 5 minutes and then it starts again.

All this are symptoms of a double IP address somewhere but changed the IP of the radio from 10.5.40.39 to 10.5.40.80, and the same things happens....

Any ideas please?

Thank you

P.S: Found now that clearing the arp-cache for a camera that comes via this link brings the pings back up for everything in that link.

Basically it seems clearing the arp-cache for any device in this link brings the pings back for 5 minutes until it stops again an I clear the arp cache again. This is really weird...

[Flavio Miranda]

Hi

 Try disable Proxy ARP:

Globally:

ip arp proxy disable

On SVI:

no proxy ip proxy-arp 

[simoesmarco8626982]

Hi Flavio,

thank you for the reply! Unfortunately it didn't worked and I still have the same issue

[Flavio Miranda]

I'd recommend another action. Try to add a static arp entry on core for the ratio IP address.

arp 10.5.40.39 ' aabb.cc03.8200' alias interface gigabitethernetxxx

[David Ruess]

Hello,

As @Flavio Miranda starts to suggest it points to maybe an ARP issue since I believe the default time is 5 minutes to keep an ARP entry. 

Not sure how the radios Interact with the 3650 you have and why the pings are weird in what you describe.

Try setting a statically configured aro entry for the IP/MAC that keeps failing after 5 min on the device you clear the ARP entry for.

arp {ip-address | vrf vrf-name} hardware-address encap-type [interface-type]

Example:

Device(config)# arp 10.0.0.0 aabb.cc03.820

-David

[Elliot Dierksen]

I think you need to determine if this is a transport issue (no way to reach the MAC address in question at layer 2) or if it is a duplicate IP address. When the pings are failing, do a "show ip arp X.X.X.X" for the IP address in question. Is it the MAC address you expect? If not then you likely have a duplicate IP address. This will tell you the MAC address of the offending device which you should be able to track down. If it is unknown/incomplete then you likely have some kind of L2 transport issue.

[MHM Cisco World]

are there any L2 security config? 

[simoesmarco8626982]

hi, 

thank you all for the replies!

I tried executing and adding the arp entries manually to the switch but even still it wasn't working. Pointed them to the interface where the macs were entering but still the same was happening and after 5 minutes it would go. 

Tried adding the macs to the specific vlan but it would give me an error stating the IP needed to be bridged or something. There's also no L2 security configured in this port.

Disabled proxy-arp and still nothing, the same issue would happen.

Checked the arp entries several times and every single time the entry was always the same. Changed IP addresses but still the same was happening. 

So as a last resort decided to apply a workaround to the switch... it's not the correct way of doing this since I still don't know what is causing the problem but everything is working correctly now.

Basically created an IP SLA with a track pinging the equipment one in one minute and created an applet executing a clear of the arp-cache 4 in 4 minutes to that specific IP address and voila everything is running like clockwork. 

It's not the correct way but after hours of battling it was the quickest way of putting the system working in order for the customer to have the CCTV back on. 

What a weird issue...