No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

MAC address learning is incorrect lead to the FW switchover failure

Publication Date:  2012-10-19 Views:  45 Downloads:  0
Issue Description
A. Networking

 
version:FW version is EU200 V200R001C03B02

B. Symptom
1、 Active and standby FW make switchover test, after switch over all services stopped, in the FW ping impassably to upper layer device direct-connection interface.
2、 at this time switchover back, service become normal, but slave FW0 can not PING passably to the direct-connection interface.
Alarm Information
none
Handling Process
Through check C company SW configuration, C manufacturer switch ports open ARP agency functions by default. The root cause:
1), upstream ARP agent
2),VRRP multiple switchover
3), firewall itself ARP learning and refresh mechanism.

The solution:
1)close ARP agency function directly connect with firewall interface, can avoid this problem. Specific order as:
ip arp proxy disable
or
no ip proxy-arp
after configure Can check the corresponding buildrun information, check whether have closed correctly.
2)try to avoid the master and slave frequent switchover and at the same time consider to refine firewall ARP learning and refresh mechanism.

Root Cause
1)first check firewall ARP entry, when the master access 10.192.254.125 address, the ARP entry learned to is 10.192.254.129, as below:
HRP_S[Eudemon_0_Slave]dis arp
IP ADDRESS      MAC ADDRESS  EXPIRE(M) TYPE INTERFACE      VPN-INSTANCE
                                       VLAN PVC
------------------------------------------------------------------------------
10.192.254.129  0017-59dc-7b69  19     D    Eth0/0/1
10.192.254.125  0017-59dc-7b69  15     D    Eth0/0/1
------------------------------------------------------------------------------
Total:26        Dynamic:20      Static:0    Interface:6
The probably reason is that the upper device enable the ARP agency functions.
2)As the ARP entry item is real-time backup, so backup the entry to the slave, slave access 10.192.254.125, directly use the MAC address entry as destination MAC address, lead to message destination MAC incorrect and discarded when message in C company SW, this is the main reason caused by the direct-connection impassable.
3)、at present the firewall ARP learning mechanism: when the ARP entry is aging, will send an ARP request again, if the peer end have a response, will learning the entry again, and at the same time, the master make real-time backup to the slave.
4)After clear the slave ARP entry, can ping passably:
HRP_S[Eudemon_0_Slave]ping 10.192.254.125
  PING 10.192.254.125: 56  data bytes, press CTRL+C to break
    Reply from 10.192.254.125: bytes=56 Sequence=1 ttl=255 time=1 ms
    Reply from 10.192.254.125: bytes=56 Sequence=2 ttl=255 time=1 ms
    Reply from 10.192.254.125: bytes=56 Sequence=3 ttl=255 time=1 ms
    Reply from 10.192.254.125: bytes=56 Sequence=4 ttl=255 time=1 ms
    Reply from 10.192.254.125: bytes=56 Sequence=5 ttl=255 time=1 ms

  --- 10.192.254.125 ping statistics ---
    5 packet(s) transmitted
    5 packet(s) received
    0.00% packet loss
    round-trip min/avg/max = 1/1/1 ms
Suggestions
Connect with other company devices must deeply understand other manufacturers processing mechanism information, avoid the problem.

END