
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-25-2018 07:22 AM
-Traceback= 17AF700 17AD5D4 17ADC5C 17ADCCC 18769A8 186D420
Oct 25 14:19:07.645: %IP-4-DUPADDR: Duplicate address XX.XX.XX.XX on VlanXX, sourced by 00f8.2cca.30c5
Oct 25 14:19:09.512: %STM-2-REGIONERROR: TCAM region 24 error: move failed, source index 4954 target index 4955.
-Traceback= 17AF700 17AD560 17ADC5C 17ADCCC 18769A8 186D420
Oct 25 14:19:14.524: %STM-2-REGIONERROR: TCAM region 24 error: move failed, source index 4955 target index 4954.
-Traceback= 17AF700 17AD5D4 17ADC5C 17ADCCC 18769A8 186D420
is there any advise?
Solved! Go to Solution.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-25-2018 01:54 PM
what is this device in that vlan, where do you see this logs ( i mean what device is this ?)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-25-2018 02:27 PM
You've got two problems:
1. Duplicate IP address; and
2. Traceback
You've got the MAC address of the offender, I recommend you trace the machine and then make the necessary decision.
For tracebacks, you'll need to provide us the complete output to the following commands:
1. sh version; and
2. sh log
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-26-2018 09:16 AM
If the duplicate devices are on an industrial segment, ie, plc's or something like that - AND you have a 3850 installed check your IPDT - see
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-25-2018 01:54 PM
what is this device in that vlan, where do you see this logs ( i mean what device is this ?)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-25-2018 02:27 PM
You've got two problems:
1. Duplicate IP address; and
2. Traceback
You've got the MAC address of the offender, I recommend you trace the machine and then make the necessary decision.
For tracebacks, you'll need to provide us the complete output to the following commands:
1. sh version; and
2. sh log
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-26-2018 09:16 AM
If the duplicate devices are on an industrial segment, ie, plc's or something like that - AND you have a 3850 installed check your IPDT - see
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-26-2018 09:17 AM
568750 False Duplicate IP detection on Ethernet modules when used with Cisco switches
Problem
When Rockwell Automation EtherNet/IP modules are connected to a subnet containing Cisco switches with "IP device tracking" (IPDT) enabled, the modules may go into a
duplicate IP address state after a restart/reset.
Environment
Any layer two networks that contain both Rockwell Automation EtherNet/IP modules and Cisco switches running IPDT.
IPDT is much more likely to be implemented on Cisco switches as of August, 2013 because of a behavior change which enables this command if any feature which
requires it is enabled.
This behavior change also removes the ability to turn off IPDT without first turning off any features which require IPDT.
The Stratix line of switches will not have “IP device tracking” enabled by default until a permanent solution is in place.
Cause
The IPDT feature sends probe ARP packets with a source IP address of 0.0.0.0., the source MAC ID of the switch, and the target IP and MAC ID for the device being probed
to check that it is still connected and responsive.
When a device becomes disconnected, and then is reconnected within the configurable IPDT timeout period, probe ARP packets may be received by a Logix Ethernet
module at the same time as it is in its Address Conflict Detection mechanism. If this happens, the EtherNet/IP module will immediately go into a duplicate IP state, and
stop communicating.
IPDT when activated on a Cisco switch will try to probe for every IP connected on the subnet, regardless of whether it is connected to that switch or not.
Testing has shown that this affects the majority of Ethernet modules sold by Rockwell Automation.
Solution
Cisco is continually updating the latest workarounds.
Here is a link to Cisco’s technote:
http://www.cisco.com/c/en/us/support/docs/ip/addressresolutionprotocolarp/
118630technoteipdt00.
html
Workaround
Several workarounds to this issue exist. They all make suggestions using Cisco IOS commandline
interface commands.
Workaround 1
Architect manufacturing zone subnets such that:
1. IPDT is explicitly disabled on every trunk port with the following command:
Hostname (configif)#
ip device tracking maximum 0
2. IPDT probe delay is manually configured on any access port connected to a Rockwell Automation Ethernet module with the following command:
Hostname (config)# ip device tracking probe delay 10
Workaround 2
If the switch in question has an administration IP (SVI) configured on the subnet/VLAN in question the Cisco CLI command:
Hostname (config)# ip device tracking probe usesvi
will insert the administration IP into the source IP in the IPDT packet. This packet will not impact Address Conflict Detection operation.
Workaround 3
Disable IPDT on any Cisco switch ports with IPDT enabled that subsequently connect to a Rockwell Automation Ethernet module with the following command:
Hostname (configif)#
ip device tracking maximum 0
