Multiple IPs same Mac Address

[vincentbri]

We have an issue since a long time upgrading the software of a Catalyst 9300 Switch. We are currently running 17.03.04 and wanted back then to 17.09.05 and right now to 17.12.04. The Problem, there is a virtualization machine connected with multiple IPs and the same MAC-Address on one port. This Machine always makes so much trouble after upgrading that we roll back the software Version, to get it running again. 
Some Additional info we are running a Fabric in version 2.3.7.7.

Ive read about some known Bugs about this but it should not be affected on my Versions.

Thanks for helping me out.

[MHM Cisco World]

What kind of trouble can you more elaborate 

MHM

[vincentbri]

The machine is not receiving a network connection because it’s unable to obtain the IP addresses.
Unfortunately, I don’t have more details at the moment, as we stayed on the older software version and my colleagues weren’t able to provide further explanation on the error.
Right now, I wanna do the upgrade again, but since this is a production environment, I’d like to check in advance what I can prepare for to avoid this specific issue or tests i can do before.

[Richard Burts]

We do not know enough about the situation to be able to give good advice. You mention that a device has multiple IP addresses associated with a single MAC address. That should not be a problem. But clearly something was a problem. During the upgrade did you capture any log messages, and if so do they point to any issue?

How is the port where the device is connected configured? Is it an access port in a vlan? A routed port? A trunk port?

[vincentbri]

Yes I see, Im sry that i can not provide more information about it. When Im trying the Softwareupdate i will dig deeper and capture the logs aswell.
But its an access port in a vlan.

[Torbjørn]

Hello @vincentbri,

I found the following bug that matches your description pretty well: CSCwi60989 
The workaround listed is to change the security level for the given port to glean. That would look something like this:

Device(config)# device-tracking policy tmp_policy
Device(config-device-tracking)# security-level glean
Device(config-device-tracking)# exit
Device(config)# int {port number}
Device(config-if)# device-tracking attach-policy tmp_policy

 Please note that this reduces the level of security for the given port. To quote the bug:

"""
It is important to note that removing switch from "security-level guard" implies the interface(s) attached to the IPDT policy will no longer be protected against any duplication / theft / spoofing (MAC or IP) detection / prevention. Take this into consideration to evaluate if this workaround is acceptable in your environment.
"""

[vincentbri]

Thanks for your answer i think the Bug you mentioned actually matches my Symptoms and the exact Software versions. I will evaluate the workaround in my Team and give it a try when upgrading again. 

[Torbjørn]

Good luck with the upgrade! Please report back with the results

[andrew.baker@mlh.org]

Hey everyone.  I really appreciate this conversation cause this same issue was occurring with us on 3 different systems that have use a virtual IP address from one MAC.  Our standard device-tracking policy is:

device-tracking policy IPDT_POLICY
no protocol udp
tracking enable

This was causing an issue with an IBM storage system and a phone system.  We have a device-tracking policy that allows 10:

device-tracking policy IPDT_MAX_10
limit address-count 10
no protocol udp
tracking enable

By applying that device-tracking policy to the ports for the storage, the issue has been resolved.  Thanks for the suggestions here.  

[Richard Burts]

Thanks for posting this. Glad that what we discussed was helpful to you. Glad to know that your issue is resolved.