Failure of Terminal Service in M-LAG+VRRP Network after Enabling ARP Proxy

Devices and Versions: S9850 R6616P01

Networking: Two S9850 switches are used as DRNI devices, and VRRP is configured as the Layer 3 gateway for downstream terminals.

M-LAG has gradually replaced IRF. DRNI is renamed as M-LAG

l  Original DR port>>M-LAG interface

l  Original DR group>>M-LAG group

l  Original IPL link>>peer-link link

l  Original IPP port>>peer-link interface

The command line in this article will not be modified

In an on-site DRNI+VRRP network, after enabling ARP proxy on the VRRP gateway VLAN virtual interface of the primary and backup devices, it was found that the terminals could not access the external network through the gateway. Further investigation of the forwarding table revealed that the terminals did not learn the ARP entries for the Layer 3 gateway, resulting in the inability to access the external network.

Why can't the terminals learn the ARP entries of the gateway after enabling ARP proxy on the VRRP gateway?

When local ARP proxy is not enabled, the process of learning the ARP entries for terminals in a DRNI+VRRP network should be as follows:

1)      The terminal sends an ARP request packet. If it hashes to the backup device, the backup device learns the MAC entry on the DR interface.

2)      The ARP request packet is a broadcast packet and is normally flooded to the IPL link and reaches the VRRP primary device.

3)      Because there is a Vlan virtual interface on the backup device, the ARP packet will be copied to the CPU. Since it is an ARP packet received by the DR interface, it will be encapsulated into an Rlink Packet packet and sent to the primary device;

4)      The primary device receives the ARP request for the virtual IP sent by flooding and replies with an ARP response packet to the terminal, allowing the terminal to learn the gateway ARP;

5)      The primary device receives two ARP packets and learns the ARP table entry on the DR interface based on the received Rlink Packet.

However, if both the VRRP primary and backup devices have ARP proxy enabled on the vlan virtual interface, when the terminal's ARP request packet reaches the backup device, the packet will no longer be flooded from the IPP interface, but redirected to the CPU. Since the VRRP backup device does not have a VRRP virtual IP, it will not respond with an ARP reply packet to the terminal. The ARP packet received on the DR interface of the backup device will be encapsulated into an Rlink Packet packet and sent to the primary device. The VRRP primary device can learn the terminal's ARP normally, but it will not respond to the RLINK packet, resulting in the terminal unable to learn the gateway ARP. If the ARP request packet is directly hashed to the VRRP primary device, the primary device can directly respond with a reply packet, and the terminal can learn the gateway ARP normally. The situation on site is that the terminal's ARP request packet is hashed to the backup device.

1. It is recommended to disable ARP proxy configuration on the VRRP backup device. In this way, when the terminal sends an ARP packet and it is hashed to the VRRP backup device, the ARP packet will still be flooded to the primary device, and an RLINK packet will also be encapsulated and sent to the primary device. The VRRP primary device can respond normally to the ARP request flooded from the backup device, and the terminal can learn ARP normally.

2. In the current network, there is a requirement for the VRRP backup device to enable ARP proxy. For this purpose, a patch named R6616P01H09 has been developed for S9850. This patch modifies the processing of ARP requests by the DRNI+VRRP backup device, so that it can still flood ARP request packets for the virtual IP from the terminal after enabling ARP proxy. If needed, this patch can be loaded.