False duplicate IP alarm - CISCO Arp probe

737 0 0 0
 Issue Description

Device: S2750-28TP-EI-AC

Version: V200R010C00SPC600 SPH006

 

Symptom: After upgrading from V2R8 to V2R10 the logs full of 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 MAC: cc46-d645-c97f is 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 producing the same on V2R10 version, so we downgraded them to V2R8.


transparent.gif 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)


transparent.gif Handling Process

 

1.      We confirmed the matching between IP address of 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 is 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 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


transparent.gif 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.


transparent.gif Solution

Use Cisco workarounds, no action is required from Huawei switch side:

https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/8021x/116529-problemsolution-product-00.html

  • x
  • convention:

Reply

Reply
You need to log in to reply to the post Login | Register

Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."
If the attachment button is not available, update the Adobe Flash Player to the latest version!

Login and enjoy all the member benefits

Login
Fast reply Scroll to top