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

NE40 Routers of Earlier Versions Cannot Transmit VRRP Heartbeat Messages Transparently in Some Circumstances

Publication Date:  2012-07-27 Views:  29 Downloads:  0
Issue Description
The topology is as follows:
NE40-A-----NE40-B
|                         |
|                         |
SBC-A------SBC-B
Two NE40 routers and two SBCs are interconnected with each other, taking the shape of a square. Enable VRRP on the SBC so that the heartbeat messages can be transmitted through the two NE40 routers transparently. At the same time, enable VRRP on the NE40 routers with VLAN so that the heartbeat messages can be transmitted transparently between the two routers. After the configuration, it was found that the VRRP heartbeat messages from SBCs could not be transmitted transparently through NE40 routers. The version of the NE40 was VRP3.10-2321. 
 
Alarm Information
Null
Handling Process
1. The engineer checked the equipment and found that multicast messages were received through the interface of NE40-A to SBC-A, but no multicast message was sent through the interface to NE40-B.
2. The engineer tested the two NE40 routers with two PCs and found no problem with the Layer 2 interconnection. In normal circumstances, VRRP heartbeat messages can be transmitted transparently.
3. The engineer deleted VRRP data and the IP addresses of the Layer 3 virtual interfaces on the two NE40 routers. Then he found that VRRP worked normally on SBCs, electing one as the master device and the other as the slave device.
4. The engineer configured the Layer 3 virtual interface on NE40-A, finding that VRRP worked abnormally on SBCs. Multicast messages were received through the interface of NE40-A to SBC-A, but no multicast message was sent through the interface to NE40-B. Multicast messages were received through the interface of NE40-B to SBC-B and these message were sent through the interface to NE40-A. This indicated that NE40-B forwarded the VRRP heartbeat messages normally. Thus, the problem may be caused by the Layer 3 virtual interface configured on NE40-A, which sent the VRRP heartbeat messages to the CPU instead of advertising the messages.
5. The engineer viewed the alerts, finding that the NE40/S8016 of the VRP3.10-2xxx versions earlier than VRP3.10-2352 sent the VRRP messages to the CPU instead of advertising the messages in the VLAN upon receipt of them after VRRP was enabled on them. VRP3.10-2xxx, by default, supports sending of VRRP messages to the CPU to avoid the impact of VRRP message advertising upon Layer 2 network. Thus, it is only applicable to the networking with one master and one slave routers enabled with VRRP. In the case of one master and several slave routers, VRP3.10-2xxx does not support the transparent transmission of VRRP messages through other slave VRRP routers. Therefore, the R&D personnel made it possible for the routers enabled with VRRP to transmit transparently VRRP messages by configuring the vrrp broadcast enable command in the VLAN. After this command is configured in the VLAN, the VLAN sends the VRRP messages to the CPU and advertises them.
6. According to the alerts, if VRRP or only a Layer 3 virtual interface is configured on the NE40, the VRRP messages from SBCs are only sent to the CPU instead of being advertised. The problem can be solved if the vrrp broadcast enable command is configured in the VLAN. 
 
Root Cause
1. SBC did not send the heartbeat messages to NE40 routers.
2. NE40 routers discarded the messages after receiving the messages. 
 
Suggestions
1. Earlier versions, by default, only support sending of VRRP messages to the CPU to avoid the impact of the VRRP message advertising upon the Layer 2 network.
2. In the routine check, the engineers should pay more attention to the released alerts to improve the problem solving efficiency. 
 

END