Error about sticky arp

I got this error on my switch.

5y15w: %IP-3-STCKYARPOVR: Attempt to overwrite Sticky ARP entry: 172.x.x.x, hw:  xxxx.xxxx.xxxx  by hw:  xxxx.xxxx.xxxx

Should I worry about it?
Dragon0x40Asked:
Who is Participating?
 
OzNetNerdCommented:
Not a problem Dragon.

I have done a bit more research and am I correct in saying that you are getting these issues with a dual NIC'd server/PC? It appears that this issue occurs if port channeling is set up incorrectly.

Can you please show us the running config of the device that is receiving these log messages?

Also, take a look at this PDF: http://tinyurl.com/ybknxmq

"When multiple network adapters are teamed using fault tolerance mode, PVLANs can be configured
without issues. When adapters are teamed using Load Balancing mode, the configuration of PVLANs
creates problems with sticky ARP entries for Layer 3 interfaces. When multiple network adapters are
teamed using Link Aggregation mode, PVLANs cannot be used. While a port is part of a PVLAN
configuration, any EtherChannel configurations for the port become inactive.
With load balancing mode, a single IP address is represented by multiple network adapters with multiple
MAC addresses. Traffic is shared across all network adapters according to the configured load balancing method. With PVLANs, the ARP entries learned on the Layer 3 interfaces (particularly on the server default gateway on the Aggregation Switch MSFC) are sticky ARP entries and do not age out.
Because the ARP entries cannot be automatically updated, traffic is only sent to the single sticky ARP
address and load balancing only occurs for outbound server traffic. In the event of a network failure, the network adapter whose MAC address is maintained as the sticky ARP entry could become unreachable.
This would create a situation where incoming traffic would be blackholed or forwarded as if the
destination were available, then ultimately dropped. The following system message is generated in
response to the attempts to overwrite the sticky ARP entry:

*%IP-3-STCKYARPOVR: Attempt to overwrite Sticky ARP entry: 10.2.31.14, hw: 0007.e910.ce0e
by hw: 0007.e910.ce0f

If a MAC address change is necessary, PVLAN ARP entries must be manually removed and reconfigured.
To avoid having interoperability issues between private VLANs and NIC teaming configuration make
sure to assign a MAC address to the virtual adapter. By doing this there is no need for the ARP table on
the router to change when a new NIC card takes over the primary role."
0
 
millsclCommented:
Is something breaking as a result?

adding "ip sticky-arp ignore" to the layer 3 interface would clear it.

Something is trying to overwrite the ARP entry.  You could have an IP being spoofed so use the aforementioned command wisely.  You might want to trace down each mac and see which device legitimately owns that address.
0
 
Dragon0x40Author Commented:
thanks millsci,

I am tracking down the macs.
0
Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
OzNetNerdCommented:
To trace the MACs, issue the "show ip arp | inc  xxxx.xxxx.xxxx " and show ip arp | inc  xxxx.xxxx.xxxx "

The "show ip arp | inc xxx" will show you the IP address of the device that the MAC address is connected to.

Also, if you issue the "show mac xxx" (where xxx is the MAC address) it will tell you which port the client is connected to, so you can trace it directly to the computer.
0
 
Dragon0x40Author Commented:
thanks bbd00,

I did that but the mac  xxxx.xxxx.xxxx  does not show up in the mac table.  xxxx.xxxx.xxxx  does show up in the mac table on port x/x.

I cleared arp and mac on port x/x but I am still getting the error.

The server hooked up to port x/x does not appear to have this mac.
0
 
Dragon0x40Author Commented:
Will work on it Monday.
0
 
Dragon0x40Author Commented:
thanks bbd00,

The server is using nic teaming and we have private vlans in use on the router getting this error message so I believe that you are on to something.

I don't know the nic teaming setup options well enough to formulate a test plan or a fix but I will get with the server admin and work that up.

I can post the config but it will take a few days.
0
 
OzNetNerdCommented:
Excellent, well at least we are on the right track.

Yes, please paste the config here when you have the chance and also see if the server admin can find out what is going on on his end. Hopefully the information above is enough for him to solve the problem.

Cheers
0
 
millsclCommented:
I've run into this problem using PVLANS and machines doing nic teaming or virtualization.

Had to definitely do the ip sticky-arp ignore on the layer 3 interface.  The server admins I was saddled with don't know how to do anything except blame the network and throw it over the fence so that was my network workaround.
0
 
Dragon0x40Author Commented:
Changed the teaming from load balance to NFT mode and cleared the arp-cache.

The arp-cache now has the correct mac and is no longer giving the overwrite error.

I wonder if just clearing the arp-cache would have cleared the error?

Protocol  Address          Age (min)  Hardware addr   Type   Interface

old entry
Internet  nnn.nn.nn.nnn         58  xxxx.xxxx.xxxx ARPA   Vlan901


new entry
Internet   nnn.nn.n.nnn             0    xxxx.xxxx.xxxx   ARPA   Vlan901

The server  nnn.nn.n.nnn   is on a promiscuous port. So I guess that is why vlan901 pv 801 does not show up as the interface


R#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet   nnn.nn.nn.nnn             7    xxxx.xxxx.xxxx   ARPA   Vlan901 pv 801
Internet   nnn.nn.nn.nnn            7     xxxx.xxxx.xxxx   ARPA   Vlan901 pv 801
Internet   nnn.nn.nn.nnn            7    xxxx.xxxx.xxxx  ARPA   Vlan901 pv 801
deleted to save space...


r#sh run int gi7/2
interface GigabitEthernet7/2
 description xxxx
 switchport private-vlan mapping 901 801
 switchport mode private-vlan promiscuous
 duplex full
0
 
OzNetNerdCommented:
"I wonder if just clearing the arp-cache would have cleared the error?"

It may have, but as per the document linked in my above post:

"If a MAC address change is necessary, PVLAN ARP entries must be manually removed and reconfigured.
To avoid having interoperability issues between private VLANs and NIC teaming configuration make
sure to assign a MAC address to the virtual adapter. By doing this there is no need for the ARP table on
the router to change when a new NIC card takes over the primary role."

So it is for the best that you use the virtual NIC's MAC as opposed to a physical NIC's MAC.

Anyway, I am glad your issue has been resolved :)
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.