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>


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


VRRP Worked Abnormally Because of the Conflict of MAC Addresses on the Ports of the NE20

Publication Date:  2012-07-27 Views:  79 Downloads:  0
Issue Description
The networking diagram is as follows:
|                         |
|                         |
A board with two GE ports is on the two NE20 routers respectively, one as the master and the other as the slave. Enable VRRP on the two GE ports. In the case of correct configuration, the ports of the two NE20 routers should be in the master state. However, the real addresses of VRRP on the two ports cannot be pinged. 
Alarm Information
Handling Process
1. The test found that Layer 2 links worked normally.
2. The same VRRP configuration on another pair of ports of the NE20 could work normally.
3. Checking the equipment, the engineer found that no policy filtered VRRP packets.
4. Viewing ARP, the engineer found that ARP entries of the peer port could not be learned. Running the debugging arp command, the engineer found abnormal ARP interactive packets. Finally, he found that the MAC addresses of the two ports enabled with VRRP were the same (the MAC address of GigabitEthernet1/0/0 was 00e0-fcaa-0001). Thus, the engineer thought the problem may be caused by the MAC address conflict.
5. Through view of the sequence numbers of the boards, the engineer found the true MAC addresses of two boards. The MAC addresses were modified as follows:
Now you enter a hidden command view for developer’s testing, some commands may affect operation by wrong use, please carefully use it with HUAWEI engineer’s direction.
input password (1-12 characters) : huaweihuawei
This mode is for Huawei engineers to test. Running these commands could result in exceptions. Please do not run these commands without directions of huawei engineers.
[SNXA-PS-WAP-RT02-diagnose]tset mac ethernet eeprom 1 0 0 00E0-FC55-40B5
[SNXA-PS-WAP-RT02-diagnose]tset mac ethernet eeprom 1 0 1 00E0-FC55-40B6
After the modification, the ports were in the Down state. Accessing the corresponding port, the engineer shut down the port and then ran the undo shutdown command. Thus, the VRRP status became normal and the problem was solved. 
Root Cause
1. Layer 2 links may not be interconnected.
2. The VRRP modules of the NE20 routers were abnormal.
3. VRRP packets were filtered out in the intermediate links.