The following rules describe how the block-on-mesh-failure operates with the MC-EP solution (see Figure 1):
If PE3 does not have any forwarding path toward Domain1 mesh, it should block both PW1 and PW2 and inform PE3 so one of its pseudowires can be activated.
To allow the use of block-on-mesh-failure for MC-EP, a block-on-mesh-failure parameter can be specified in the config>service>vpls>endpoint context with the following rules:
The default is no block-on-mesh-failure to allow for easy migration.
For a spoke-SDP to be added under an endpoint, the setting for its block-on-mesh-failure parameter must be in synchronization with the endpoint parameter.
After the spoke-SDP is added to an endpoint, the configuration of its block-on-mesh-failure parameter is disabled. A change in endpoint configuration for the block-on-mesh-failure parameter is propagated to the individual spoke-SDP configuration.
When a spoke-SDP is removed from the endpoint group, it inherits the last configuration from the endpoint parameter.
Adding an MC-EP under the related endpoint configuration does not affect the above behavior.
Before Release 7.0, the block-on-mesh-failure command could not be enabled under config>service>vpls>endpoint context. For a spoke-SDP to be added to an (single-chassis) endpoint, its block-on-mesh-failure had to be disabled (config>service>vpls>spoke-sdp>no block-on-mesh-failure). Then, the configuration of block-on-mesh-failure under a spoke-SDP is blocked.
If block-on-mesh-failure is enabled on PE1 and PE2, these PEs signal pseudowire standby status toward the MC-EP PE pair. PE3 and PE3 should consider the pseudowire status signaling from remote PE1 and PE2 when making the selection of the active pseudowire.