Page 460 7750 SR OS Services Guide
→ Only one of the pseudowires is activated based on the primary/secondary, preference
configuration and pseudowire status. In case of a tie the pseudowire located on the
master chassis will be chosen.
→ The rest of the pseudowires are blocked locally on the MC-EP pair and on the remote
PEs as long as they implement the pseudowire active/standby status.
Fast Detection of Peer Failure using BFD
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 as other protocols, MC-EP will register with BFD if the “bfd-enable” command is active
under “config>redundancy>multi-chassis>peer>mc-ep” object. 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 will use it for fast detection of MC-EP peer
failure. If BFD registration or BFD initialization fails, the MC-EP will keep using its own keep-
alive mechanism and it will send a trap to the NMS signaling the failure to register with/open BFD
session.
In order 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 certain
BFD session:
• Only the centralized BFD sessions using system or loopback IP interfaces (see 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 certain interface (system/
loopback) then the following actions are not allowed under the interface: IP address
change, “shutdown”, “no bfd” commands. If one of these action is required under the
interface, the operator needs to disable BFD using the following procedures:
→ “no bfd-enable” command under “config>redundancy>multi-chassis>peer>mc-ep”
object – this is the recommended procedure.
→ shutdown from under “config>redundancy>multi-chassis>peer>mc-ep” or from
under “config>redundancy>multi-chassis>peer” objects
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
will use its own keep-alives for failure detection.
• To ensure the database is cleared if the remote MC-EP peer is shutdown or miss-
configured (each x seconds – one second suggested as default).
To Next Page
Loading...
