M-LAG Networking Keepalive Link Protocol Down Case

Devices and Versions: S6900-F F2712

Networking: In the new setup at the site, two S6900-F devices, TOR-1 and TOR-2, are used to form an M-LAG. The partial network is as shown in the figure below:

TOR-1 and TOR-2 successfully form an M-LAG, establish a keepalive link using IPv6 addresses, but the keepalive connection cannot be established, and the link is always in the protocol down state.

Checking the M-LAG configuration shows no problems. Both the primary and secondary devices have ND entries for the keepalive source address of the peer, and they can ping each other:

By using the "debugging drni keepalive" command on the two devices to view the interaction of keepalive packets, it was found that TOR-1 device received and sent packets, but TOR-2 device only sent packets and did not receive them. At the same time, we confirmed through flow statistics that the incoming direction of the keepalive link on TOR-2 device did receive packets:

From the above investigation, we can conclude that TOR-2 received the keepalive packet sent by TOR-1 but did not process it. Therefore, we suspected that the port number used by keepalive on TOR-2 was occupied or there was a problem with the keepalive packet received by TOR-2. Therefore, we first checked the UDP port usage on TOR-2 and found that the default UDP port 6400 used by keepalive was occupied by another application:

The default UDP port 6400 used by keepalive was occupied, causing TOR-2 to be unable to receive and process the keepalive packets sent by TOR-1 normally.

Temporary workaround: Use the command when configuring keepalive udp-port udp-number Manually specify an unused port number; If the device restarts, there is a risk of the configured UDP port number being taken over by other applications.

Solution: Patch evaluation and release will be conducted in subsequent versions after F2712 to reserve UDP port 6400 for M-LAG keepalive usage and prevent other applications from taking over.