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. 

[Diego Cabanas]

Hello Vincentbri,

Hope it is not too late and this can help others, what you are describing is an expected behavior for security in SDA networks. starting 17.4+ version there was and enhancement in the security described in the "CSCvu28035  ENH - LISP IPv4 detection through SISF and EID-watch support" we use IPDT(device-tracking/SISF) to communicate with LISP process and register the endpoints.

If you validate in your Edge, you are going to see the vlan is associated with the IPDT policy DT-PROGRAMMATIC. 

Edge-1# show device-tracking policies vlan 10
Target Type Policy Feature Target range
vlan 10 VLAN DT-PROGRAMMATIC Device-tracking vlan all <------
vlan 10 VLAN LISP-DT-GUARD-VLAN Device-tracking vlan all
vlan 10 VLAN LISP-AR-RELAY-VLAN Address Resolution Relay vlan all

If we verify this policy in more detail this policy, you can see it is explicitly restricted  one ip per mac.

Edge-1#show device-tracking policy DT-PROGRAMMATIC
Device-tracking policy DT-PROGRAMMATIC configuration:
security-level glean
device-role node
gleaning from Neighbor Discovery
gleaning from DHCP6
gleaning from ARP
gleaning from DHCP4
NOT gleaning from protocol unkn
limit address-count for IPv4 per mac 1 <------- we can see per security reason, only one ip is allow per mac
tracking (downlink only) enable
Policy DT-PROGRAMMATIC is applied on the following targets:
Target Type Policy Feature Target range
vlan 5 VLAN DT-PROGRAMMATIC Device-tracking vlan all
vlan 6 VLAN DT-PROGRAMMATIC Device-tracking vlan all
vlan 10 VLAN DT-PROGRAMMATIC Device-tracking vlan all

As there are scenarios like your case, there is a feature called Multiple IP-to-MAC Addresses that you can enable in the Anycast Gateway config or the L2VN config in case it is a L2 only vlan in your Cisco Catalyst Center 2.3.7.7 is already available.

This will override this  security restriction and allow 1000 ipv4 per mac as a new IPDT policy will be added for that particular vlan. Let me show you the vlan 18 that has this feature enable:

The configuration added is over hte L2 lisp instance id 82200 for my vlan 18.

Edge-1#show run | s 8200
interface L2LISP0.8200
instance-id 8200
remote-rloc-probe on-route-change
service ethernet
eid-table vlan 18
database-mapping mac locator-set rloc_711367e5-e8ae-4692-aef2-34a7b3aa3e48
dynamic-eid detection multiple-addr bridged-vm <---- add this configuration in the switch
exit-service-ethernet
!
exit-instance-id

Also, it is added the ip dhcp snooping vlan 18 proxy-bridge
Edge-1#show run | inc ip dhcp snooping vlan
ip dhcp snooping vlan 5-6,10-11,13-18,20,88
ip dhcp snooping vlan 18 proxy-bridge <----

And with this change there is added a new IPDT policy LISP-DT-GUARD-VLAN-MULTI-IP to this vlan 18.

Edge-1# show device-tracking policies vlan 18
Target Type Policy Feature Target range
vlan 18 VLAN DT-PROGRAMMATIC Device-tracking vlan all
vlan 18 VLAN LISP-DT-GUARD-VLAN-MULTI-IP Device-tracking vlan all <---------
vlan 18 VLAN LISP-AR-RELAY-VLAN Address Resolution Relay vlan all

If we validate this particular policy, we can see the limit of 1 ip per mac is overrides because we have the preference high, so now it is allowed 1000 ip per mac.

Edge-1#show device-tracking policy LISP-DT-GUARD-VLAN-MULTI-IP
Device-tracking policy LISP-DT-GUARD-VLAN-MULTI-IP configuration:
security-level guard
device-role node
gleaning from Neighbor Discovery
gleaning from DHCP6
gleaning from ARP
gleaning from DHCP4
NOT gleaning from protocol unkn
limit address-count for IPv4 per mac 1000 preference high <---------
limit address-count for IPv6 per mac 1000
origin fabric
tracking enable reachable-lifetime 240
Policy LISP-DT-GUARD-VLAN-MULTI-IP is applied on the following targets:
Target Type Policy Feature Target range
vlan 18 VLAN LISP-DT-GUARD-VLAN-MULTI-IP Device-tracking vlan all

Hope this help you to clarify the behavior observed.

Best regard,

Diego Cabanas