ā05-05-2025 02:57 AM
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.
ā05-05-2025 03:16 AM
What kind of trouble can you more elaborate
MHM
ā05-05-2025 03:52 AM
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.
ā05-05-2025 03:17 PM
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?
ā05-05-2025 11:29 PM
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.
ā05-06-2025 12:40 AM
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.
"""
ā05-06-2025 01:10 AM
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.
ā05-06-2025 01:27 AM
Good luck with the upgrade! Please report back with the results
ā07-03-2025 09:56 AM
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.
ā07-04-2025 08:36 AM
Thanks for posting this. Glad that what we discussed was helpful to you. Glad to know that your issue is resolved.
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