This post refers to the false duplicate IP alarm - CISCO Arp probe. Let's see more details below.
Issue description
Device: S2750-28TP-EI-AC
Version: V200R010C00SPC600 SPH006
Diagnostic: After upgrading from V2R8 to V2R10, the logs were full of information on the alarm:
Oct 31 2017 14:26:47+01:00 Gy2750-5 %ARP/4/ARP_DUPLICATE_IPADDR(l)[4]:Received an ARP packet with a duplicate IP address from the interface. (IpAddress=X.X.X.X, InterfaceName=Vlanif111, MacAddress=cc46-d645-wxyz)
Oct 31 2017 14:26:47+01:00 Gy2750-5 ARP/4/ARP_IPCONFLICT_TRAP:OID 1.3.6.1.4.1.2011.5.25.123.2.6 ARP detects IP conflict. (IP address=X.X.X.X, Local interface=Vlanif111, Local MAC=c0bf-c022-c026, Local vlan=0, Local CE vlan=0, Receive interface=GigabitEthernet0/0/3, Receive MAC=cc46-d645-wxyz, Receive vlan=111, Receive CE vlan=0, IP conflict type=Local IP conflict).
We are sure there is no IP conflict in the system. The mentioned the MAC: cc46-d645-c97f was a Cisco Cat4500 L3 switch at the core of the L2 hierarchy.
The IP address: X.X.X.X is the interface VLAN111 on this switch.
We have 5pcs S2750 access switches causing the same issue on the V2R10 version, so we downgraded them to V2R8.
Alarm information
Oct 31 2017 14:26:47+01:00 Gy2750-5 %ARP/4/ARP_DUPLICATE_IPADDR(l)[4]:Received an ARP packet with a duplicate IP address from the interface. (IpAddress=X.X.X.X, InterfaceName=Vlanif111, MacAddress=cc46-d645-wxyz)
Handling process
1. We confirmed the matching between the IP address of the Cisco Cat4500 L3 switch and the MAC address cc46-d645-wxyz.
L4500-x-2#
Cisco IOS Software, IOS-XE Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSALK9-M), Version 03.05.01.E RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2013 by Cisco Systems, Inc.
Compiled Sat 23-Nov-13 00:13 by prod_rel_team
.
.
.
ROM: 15.0(1r)SG11
L4500-x-2 uptime is 1 year, 41 weeks, 6 days, 1 hour, 57 minutes
System returned to ROM by power-on
System restarted at 14:03:50 MET Thu Jan 21 2016
Running default software
Jawa Revision 2, Winter Revision 0x0.0x40
Last reload reason: power-on
L4500-x-2#sh int vlan 111
Vlan111 is up, line protocol is up
Hardware is Ethernet SVI, address is cc46.d645.wxyz (bia cc46.d645.wxyz)
Description: MGMT
Internet address is x.x.x.x/27
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not supported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes
L3 out Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes
IPv6 L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes
IPv6 L3 out Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes
33 packets input, 4820 bytes, 0 no buffer
Received 44012601 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
757605 packets output, 37589849 bytes, 0 underruns
0 output errors, 1 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
interface Vlan111
description MGMT
ip address x.x.x.x 255.255.255.224
end
2. Since we already confirmed that there was no ARP IP conflict, it may be caused by the CISCO device sending the probe ARP packet. In V2R10 version, when the device receives a probe ARP packet will print this alarm. We can see details above.
If we want to confirm whether the issue is caused by CISCO probe packet, we can capture the packet by running the commands below, and check whether the device receive probe ARP packet:
<HUAWEI>terminal debugging
<HUAWEI>terminal monitor
<HUAWEI>debugging timeout 0
<HUAWEI>debugging arp packet interface Vlanif 10 ------wait for at least 30 minutes
<HUAWEI>undo terminal debugging
<HUAWEI>undo terminal monitor
<HUAWEI>undo debugging all
3. We checked the Cisco documentation. It suggests several workarounds, so no other action is needed from the Huawei side.
Interface IP Address/Mask Physical Protocol
NULL0 unassigned up up(s)
Vlanif1 unassigned *down down
Vlanif111 x.x.x.x/27 up up
<Gy2750-1>
Nov 17 2017 09:40:14.40.1+01:00 Gy2750-1 ARP/7/arp_rcv:Receive an ARP Packet, operation : 1, sender_eth_addr : cc46-d645-wxyz, sender_ip_addr : 0.0.0.0, target_eth_addr : c0bf-c022-c03a, target_ip_addr : x.x.x.x
Nov 17 2017 09:40:14+01:00 Gy2750-1 %ARP/4/ARP_DUPLICATE_IPADDR(l)[1]:Received an ARP packet with a duplicate IP address from the interface. (IpAddress=x.x.x.x, InterfaceName=Vlanif111, MacAddress=cc46-d645-wxyz)
Nov 17 2017 09:40:14.70.1+01:00 Gy2750-1 ARP/7/arp_send:Send an ARP Packet, operation : 2, sender_eth_addr : c0bf-c022-c03a,sender_ip_addr : x.x.x.x, target_eth_addr : ffff-ffff-ffff, target_ip_addr : x.x.x.x
<Gy2750-1>
Nov 17 2017 09:40:52.910.1+01:00 Gy2750-1 ARP/7/arp_rcv:Receive an ARP Packet, operation : 1, sender_eth_addr : cc46-d645-c3ff, sender_ip_addr : 0.0.0.0, target_eth_addr : c0bf-c022-c03a, target_ip_addr : x.x.x.x
Nov 17 2017 09:40:52+01:00 Gy2750-1 %ARP/4/ARP_DUPLICATE_IPADDR(l)[2]:Received an ARP packet with a duplicate IP address from the interface. (IpAddress=x.x.x.x, InterfaceName=Vlanif111, MacAddress=cc46-d645-wxyz)
Nov 17 2017 09:40:52.940.1+01:00 Gy2750-1 ARP/7/arp_rcv:Receive an ARP Packet, operation : 1, sender_eth_addr : cc46-d645-wxyz,sender_ip_addr : 0.0.0.0, target_eth_addr : c0bf-c022-c03a, target_ip_addr : x.x.x.x
Root cause
Cisco IOS® uses the Address Resolution Protocol (ARP) Probe that is sourced from an address of 0.0.0.0 in order to maintain the IP device-tracking cache during IP device tracking, and a feature that uses it is enabled (such as 802.1x) on a Cisco IOS switch. The purpose of IP device tracking is for the switch to obtain and maintain a list of devices that are connected to the switch via an IP address.
The probe does not populate the tracking entry. It is used in order to activate and maintain the entry in the table after it is learned. This IP address is then used when an Access Control List (ACL) is applied to the interface in order to substitute the source address in the ACL with the client IP address. This function is critical whenever access lists are used with 802.1x or any other Flex-Auth function on Cisco switches.
Solution
Use the Cisco workarounds, no action is required from the Huawei switch side:
https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/8021x/116529-problemsolution-product-00.html.
