Although the MC-EP protocol has its own keep-alive mechanisms, sharing a common mechanism for failure detection with other protocols (for example, BGP, RSVP-TE) scales better. MC-EP can be configured to use the centralized BFD mechanism.
Similar to other protocols, MC-EP registers with BFD if the bfd-enable command is active under the config>redundancy>multi-chassis>peer>mc-ep context. As soon as the MC-EP application is activated using no shutdown, it tries to open a new BFD session or register automatically with an existing one. The source-ip configuration under redundancy multi-chassis peer-ip is used to determine the local interface while the peer-ip is used as the destination IP for the BFD session. After MC-EP registers with an active BFD session, it uses it for fast detection of MC-EP peer failure. If BFD registration or BFD initialization fails, the MC-EP keeps using its own keep-alive mechanism and it sends a trap to the NMS signaling the failure to register with/open a BFD session.
To minimize operational mistakes and wrong peer interpretation for the loss of BFD session, the following additional rules are enforced when the MC-EP is registering with a BFD session:
Only the centralized BFD sessions using system or loopback IP interfaces (source-ip parameter) are accepted in order for MC-EP to minimize the false indication of peer loss.
If the BFD session associated with MC-EP protocol is using a system/loopback interface, the following actions are not allowed under the interface: IP address change, ‟shutdown”, ‟no bfd” commands. If one of these actions is required under the interface, the operator needs to disable BFD using the following procedures:
The no bfd-enable command in the config>redundancy>multi-chassis>peer>mc-ep context — this is the recommended procedure.
The shutdown command in the config>redundancy>multi-chassis>peer>mc-ep or from under config>redundancy>multi-chassis>peer contexts.
MC-EP keep-alives are still exchanged for the following reasons:
As a backup; if the BFD session does not come up or is disabled, the MC-EP protocol uses its own keep-alives for failure detection.
To ensure the database is cleared if the remote MC-EP peer is shut down or misconfigured (each x seconds; one second suggested as default).
If MC-EP de-registers with BFD using the no bfd-enable command, the following processing steps occur:
The local peer indicates to the MC-EP peer that the local BFD is being disabled using the MC-EP peer-config-TLV fields ([BFD local: BFD remote]). This is done to avoid the wrong interpretation of the BFD session loss.
The remote peer acknowledges reception indicating through the same peer-config-TLV fields that it is de-registering with the BFD session.
Both MC-EP peers de-register and use only keep-alives for failure detection.
There should be no pseudowire status change during this process.
Traps are sent when the status of the monitoring of the MC-EP session through BFD changes in the following instances:
When red/mc/peer is no shutdown and BFD is not enabled, a notification is sent indicating BFD is not monitoring the MC-EP peering session.
When BFD changes to open, a notification is sent indicating BFD is monitoring the MC-EP peering session.
When BFD changes to down/close, a notification is sent indicating BFD is not monitoring the MC-EP peering session.