ā05-06-2022 02:32 AM
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
Solved! Go to Solution.
ā05-06-2022 03:35 AM - edited ā05-06-2022 03:35 AM
ARP request and ARP reply from SW it seem to me you enable
ip tracking in SW, IP tracking make SW send/receive ARP.
ā05-09-2022 03:45 AM
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)
Thank you Sergiu for pointing me in a useful direction
--sk
ā05-06-2022 03:35 AM - edited ā05-06-2022 03:35 AM
ARP request and ARP reply from SW it seem to me you enable
ip tracking in SW, IP tracking make SW send/receive ARP.
ā05-06-2022 04:22 AM - edited ā05-06-2022 04:25 AM
ā05-08-2022 07:11 AM - edited ā05-09-2022 04:52 AM
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
ā05-09-2022 03:45 AM
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)
Thank you Sergiu for pointing me in a useful direction
--sk
ā05-09-2022 04:34 AM
""Catalyst switches running the 'IP Device Tracking' feature""
So this issue from IP tracking.
at least thanks to me LOL
good job friend.
ā05-09-2022 06:27 AM
Yes -- I was just looking on the wrong device!
--sk
ā05-09-2022 06:29 AM
You Are So So welcome friend.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide