This feature is used in VPLS to enhance the existing BGP MH solution by providing a block-on-group failure function similar to the block-on-mesh failure feature implemented for LDP VPLS. On the PE selected as the Designated Forwarder (DF), if the rest of the VPLS endpoints fail (pseudowire spokes/pseudowire mesh and, or SAPs), there is no path forward for the frames sent to the MH site selected as DF. The status of the VPLS endpoints, other than the MH site, is reflected by bringing down/up the objects associated with the MH site.
Support for the feature is provided initially in VPLS and B-VPLS instance types for LDP VPLS, with or without BGP-AD and for BGP VPLS. The following objects may be placed as components of an operational group: BGP VPLS pseudowires, SAPs, spoke-pseudowire, BGP-AD pseudowires. The following objects are supported as monitoring objects: BGP MH site, individual SAP, spoke-pseudowire.
The following rules apply:
An object can only belong to one group at a time.
An object that is part of a group cannot monitor the status of any group.
An object that monitors the status of a group cannot be part of any group.
An operational group may contain any combination of member types: SAP, spoke-pseudowire, BGP-AD or BGP VPLS pseudowires.
An operational group may contain members from different VPLS service instances.
Objects from different services may monitor the operational group.
The operational group feature may coexist in parallel with the block-on-mesh failure feature as long as they are running in different VPLS instances.
There are two steps involved in enabling the block-on-mesh failure feature in a VPLS scenario:
Identify a set of objects whose forwarding state should be considered as a whole group, then group them under an operational group using the oper-group CLI command.
Associate other existing objects (clients) with the oper-group command using the monitor-group CLI command; its forwarding state is derived from the related operational group state.
The status of the operational group (oper-group) is dictated by the status of one or more members according to the following rule:
The oper-group goes down if all the objects in the oper-group go down; the oper-group comes up if at least one of the components is up.
An object in the oper-group is considered down if it is not forwarding traffic in at least one direction. That could be because the operational state is down or the direction is blocked through some resiliency mechanisms.
If an oper-group is configured but no members are specified yet, its status is considered up. As soon as the first object is configured, the status of the oper-group is dictated by the status of the provisioned members.
For BGP-AD or BGP VPLS pseudowires associated with the oper-group (under the config>service-vpls>bgp>pw-template-binding context), the status of the oper-group is down as long as the pseudowire members are not instantiated (auto-discovered and signaled).
A simple configuration example is described for the case of a BGP VPLS mesh used to interconnect different customer locations. If we assume a customer edge (CE) device is dual-homed to two PEs using BGP MH, the following configuration steps apply:
The oper-group bgp-vpls-mesh is created.
The BGP VPLS mesh is added to the bgp-vpls-mesh group through the pseudowire template used to create the BGP VPLS mesh.
The BGP MH site defined for the access endpoint is associated with the bgp-vpls-mesh group; its status from now on is influenced by the status of the BGP VPLS mesh.
Below is a simple configuration example:
service>oper-group bgp-vpls-mesh-1 create
service>vpls>bgp>pw-template-binding> oper-group bgp-vpls-mesh-1
service>vpls>site> monitor-group bgp-vpls-mesh-1