cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1635
Views
0
Helpful
7
Replies

Every-30-second-refresh of ARP cache

stuartkendrick
Level 1
Level 1

I am examining a Nexus 93180YC-EX running NX-OS 9.3.8 functioning at Layer 3.  Or, more precisely, I am examining pcaps which I am capturing at hosts

 

The N9K appears to be refreshing its active ARP entries (mostly) consistently every 30s, despite the following:

ip arp timeout 14400

In other words, in the pcaps, I see the N9K emit an ARP Request (and receive an ARP Reply) from hosts every 30s.  Every now and then, it misses a refresh cycle, but mostly, it sticks to this cadence.

 

The N9K is part of a vPC pair:

vpc domain 1
  peer-switch
  role priority 10
  peer-keepalive destination 1.1.1.2 source 1.1.1.1 vrf VPCKeepAlive
  peer-gateway
  auto-recovery
  ip arp synchronize

 

Every-30-seconds seems a bit energetic to me.  Has anyone else seen this behavior?  Have a model to offer for why?

 

--sk

 

Stuart Kendrick

2 Accepted Solutions

Accepted Solutions

ARP request and ARP reply from SW it seem to me you enable 
ip tracking in SW, IP tracking make SW send/receive ARP.

View solution in original post

stuartkendrick
Level 1
Level 1

OK, you lead me to the answer ... the ethanalyzer output did *not* show the every-30s ARP Requests ... in fact, the periodic ARP Requests are coming from Layer 2 Catalyst switches running the 'IP Device Tracking' feature, which interacts badly with Windows duplicate IP address detection (I was mistakenly attributing them to the N9K)

 

https://www.cisco.com/c/en/us/support/docs/ip/address-resolution-protocol-arp/118630-technote-ipdt-00.html

https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/8021x/116529-problemsolution-product-00.html

 

Thank you Sergiu for pointing me in a useful direction

 

--sk

View solution in original post

7 Replies 7

ARP request and ARP reply from SW it seem to me you enable 
ip tracking in SW, IP tracking make SW send/receive ARP.

I do not see any sign of tracking

 

mdf-a-rtr# sh run | include track
mdf-a-rtr#

 

 

Hi @stuartkendrick 

 

Did you confirmed that the source MAC address or ARP requests is the one belonging to N9K?

Is the ARP resolved on the N9K for the problematic endpoint?

Check what type of traffic is being sent to CPU - maybe you have lots of glean traffic - in case ARP is not resolved for that EP. You can use ethanalyzer to verify the traffic at cpu level:

ethanalyzer local interface inband limit-capture 0

ctrl+c to break the capture

There is no impact on the switch to use this command.

 

Cheers,

Sergiu

 

 

stuartkendrick
Level 1
Level 1

OK, you lead me to the answer ... the ethanalyzer output did *not* show the every-30s ARP Requests ... in fact, the periodic ARP Requests are coming from Layer 2 Catalyst switches running the 'IP Device Tracking' feature, which interacts badly with Windows duplicate IP address detection (I was mistakenly attributing them to the N9K)

 

https://www.cisco.com/c/en/us/support/docs/ip/address-resolution-protocol-arp/118630-technote-ipdt-00.html

https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/8021x/116529-problemsolution-product-00.html

 

Thank you Sergiu for pointing me in a useful direction

 

--sk

""Catalyst switches running the 'IP Device Tracking' feature""

So this issue from IP tracking.

at least thanks to me LOL 

good job 
friend.

Yes -- I was just looking on the wrong device!

 

--sk

You Are So So welcome friend.