2960x Switchport itself ARPing the very device connected to it

[stratton22]

I have a  WS-C2960X-48FPS-L 15.2(2)E9  that is ARPing for the very device connected to it. The ARP request originates from the very port the device is connected to.  This is not the port just passing on an ARP request from something else. this is the port itself generating the ARP request.  Couple of odd things

Why would a switchport ever ARP for anything.  The ARP request is a unicast vs a broadcast. The source IP is 0.0.0.0. This behavior apparently is present only on ports that the device is off but the NIC has done DHCP for Wake-on-LAN purposes.

For example: Let me show the interface to see the MAC, the mac table for that interface and the ARP request and reply.  This shows that the ARP request originated at the switchport.

Q: Is this a bug or a config I don't understand?

---------

Sh int g2/0/27

  GigabitEthernet2/0/27 is up, line protocol is up (connected)

  Hardware is Gigabit Ethernet, address is 3c0e.23ea.139b (bia 3c0e.23ea.139b)

------------

sh mac addr | i 2/0/27
400 40a8.f044.0ab5 DYNAMIC Gi2/0/27

--------------

Frame 41: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface \Device\NPF_{D07B84DF-9EB1-4A85-A853-DC9272598409}, id 0
Ethernet II, Src: Cisco_ea:13:9b (3c:0e:23:ea:13:9b), Dst: HewlettP_44:0a:b5 (40:a8:f0:44:0a:b5)
Address Resolution Protocol (request)
Hardware type: Ethernet (1)
Protocol type: IPv4 (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: request (1)
Sender MAC address: Cisco_ea:13:9b (3c:0e:23:ea:13:9b)
Sender IP address: 0.0.0.0
Target MAC address: HewlettP_44:0a:b5 (40:a8:f0:44:0a:b5)
Target IP address: 10.69.188.151

-------

Frame 42: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface \Device\NPF_{D07B84DF-9EB1-4A85-A853-DC9272598409}, id 0
Ethernet II, Src: HewlettP_44:0a:b5 (40:a8:f0:44:0a:b5), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (reply)
Hardware type: Ethernet (1)
Protocol type: IPv4 (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: reply (2)
Sender MAC address: HewlettP_44:0a:b5 (40:a8:f0:44:0a:b5)
Sender IP address: 10.69.188.151
Target MAC address: Cisco_ea:13:9b (3c:0e:23:ea:13:9b)
Target IP address: 0.0.0.0

[balaji.bandi]

As per the device, device has its own MAC Address.

sh mac addr | i 2/0/27
400 40a8.f044.0ab5 DYNAMIC Gi2/0/27

this is the device connected and it will resolve the same when you do show ip arp | in 40a8.f044.0ab5

[stratton22]

Thx for the reply but my question is why is it sending the ARP request at all? and it is doing so every 30-60 seconds.

The issue it generates is the ARP Reply by the client.  As the source IP was 0.0.0.0 the client is unable to unicast the reply but has to broadcast it.   This reply hits our Nexus 7K who sees the destination address of 0.0.0.0 and adds an error entry to the logfile. Our logfiles are filling up with the entries.

[Reza Sharifi · Accepted solution]

Do you have IP device tracking enabled on the switch? This document is for the 7k series but may apply to the 2960x depending on the IOS version.

https://www.cisco.com/c/en/us/support/docs/switches/nexus-7000-series-switches/200397-Nexus-7000-Understanding-and-Remediatin.html

HTH

[stratton22]

We do. It was added by DNA.

[stratton22]

The document you referenced mention another doc that described how to raise the logging level for "erroneous ARPs" to keep them from flooding the logs.

[stratton22]

Allow me a little speculation 

We are seeing these ARP requests it seems for just those devices that are "off" but are still doing DHCP for Wake-on-LAN purpose. I'll guess these "discovery ARPs" are not needed for active devices as the switch can see whom/what they.   These "off" devices get ARPed periodically because they are too quiet?

[Giuseppe Larosa]

Hello @stratton22 ,

yes it looks like that with IP device tracking on the switch will attempt to verify quiet clients .

Doing it every 60 seconds I agree is too much.

Have you been able to mask/filter  the log messages ?

Hope to help

Giuseppe

[stratton22]

Yes more retrictive ARP logging has been successful.

  Thx for your time.