Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces
Extracted elements (23)
BFD is preferred over LACP for LAG member link failure detection because it provides (1) faster detection, (2) detection in the absence of LACP, and (3) the ability to verify L3 bidirectional forwarding capability per member link.
L3 protocols such as OSPF treat the LAG as a single interface and have no insight into individual member links. The signaling from micro-BFD sessions to L3 protocols is done indirectly through the impact on the load-balancing table and any decision by the LAG/interface manager to shut down the LAG.
Running a single BFD session over the aggregation without internal knowledge of the member links would make it impossible for BFD to guarantee detection of physical member link failures. Per-member-link micro-BFD sessions are required to ensure link continuity verification for every member link.
UDP port 6784 was assigned specifically to remove the ambiguity between BFD-over-LAG packets and BFD-over-single-hop-IP (RFC 5881) packets. A misconfiguration where one side uses per-member micro-BFD and the other uses a single RFC 5881 session would otherwise be indistinguishable.
If BFD-over-LAG is provisioned on a member link that is already active within a LAG, BFD session state should not influence the load-balancing algorithm until the session transitions to Up, ensuring that the ordering of enabling LAG and enabling BFD has no impact on the forwarding service.
If one device is not operating a micro-BFD session on a link while the other device is and perceives the session as Down, the two devices will have different views of link status, likely leading to traffic loss across the LAG. Bootstrapping protocols can detect such mismatched configurations.
When local or remote state of a micro-BFD session is AdminDown, the system should not indicate a connectivity failure to any client and should not remove the member link from forwarding. This behavior is independent of LACP usage.
Even when LACP considers a member link ready to forward traffic, the member link MUST NOT be used by the load balancer until all micro-BFD sessions of that member link are in Up state. BFD controls whether the load-balancing algorithm can select a particular LAG member link.
Implementations compliant with this standard MUST be able to receive both untagged and 802.1p priority tagged (VLAN tag of zero) micro-BFD packets when the LAG operates in the context of IEEE 802.1q or IEEE 802.qinq.
Micro-BFD session negotiation MUST follow the same procedures defined in RFC 5880 and RFC 5881. At least one system MUST take the Active role (possibly both).
Micro-BFD sessions for a particular LAG member link MUST be requested when the member link state is either Distributing or Standby, and MUST be deleted when the member link is in neither of those states.
On Ethernet-based LAG member links, the source MAC SHOULD be the MAC address of the member link transmitting the packet. Micro-BFD packets SHOULD always be sent untagged.
The dedicated multicast MAC 01-00-5E-90-00-01 MUST be used for initial BFD packets in Down/AdminDown and Init states, and for the first bfd.DetectMult packets when a session transitions to Up state. All implementations MUST be able to send and receive BFD packets in Up state using this dedicated MAC.
The procedures defined in this document MUST be used for BFD messages addressed to UDP port 6784 and MUST NOT be used for other ports assigned in RFCs describing other BFD modes.
When a micro-BFD session goes down, the corresponding member link MUST be taken out of the LAG load-balancing table(s). Implementations with separate IPv4 and IPv6 tables MAY remove the link only from the table matching the failing session's address family.
When an address family (IPv4 or IPv6) is used for micro-BFD sessions on one member link of a LAG, it MUST be used on all member links of that particular LAG. Two micro-BFD sessions MAY exist per member link: one IPv4 and one IPv6.
When the Your Discriminator field is nonzero and a micro-BFD over a LAG session is found, the interface on which the micro-BFD control packet arrived MUST correspond to the interface associated with that session. This amends the reception procedure in RFC 5880 Section 6.8.6.
A 'micro-BFD session' is an independent Asynchronous mode BFD session run on each individual LAG member link. Each session uses its own unique local discriminator values, maintains its own set of state variables, and has its own independent state machine.
BFD control packets for each micro-BFD session are IP/UDP encapsulated per RFC 5881 but use a new UDP destination port 6784 instead of the standard BFD port. This port distinguishes BFD-over-LAG packets from BFD-over-single-hop-IP packets.
On Ethernet-based LAG member links, the dedicated multicast destination MAC address 01-00-5E-90-00-01 is used as the immediate next hop for micro-BFD packets. This reduces additional MAC address usage and required resources on receiving hardware.
IANA assigned the dedicated multicast MAC address 01-00-5E-90-00-01 for BFD on Link Aggregation Group (LAG) Interfaces, per the IANA MAC address registry defined in RFC 7042.
IANA assigned UDP port 6784 for BFD on Link Aggregation Group (LAG) Interfaces. The registry shows Assignee as [IESG] and Contact as [BFD_Chairs] ([email protected]), with reference updated to RFC 7130.
RFC 7130 does not introduce any additional security issues beyond those already present in BFD. The security mechanisms defined in RFC 5880 (BFD base specification) apply to the micro-BFD sessions defined in this document.