To implement pseudowire redundancy, a VLL service accommodates more than a single object on the SAP side and on the spoke-SDP side. The following figure shows the model for a redundant VLL service based on the concept of endpoints.
A VLL service supports by default two implicit endpoints managed internally by the system. Each endpoint can only have one object, a SAP or a spoke-SDP.
To add more objects, up to two (2) explicitly named endpoints may be created per VLL service. The endpoint name is locally significant to the VLL service. They are referred to as endpoint 'X' and endpoint 'Y' as shown in the preceding figure.
The information in Figure: Redundant VLL endpoint objects is merely an example and that the ‟Y” endpoint can also have a SAP and an ICB spoke-SDP. The following details the four types of endpoint objects supported and the rules used when associating them with an endpoint of a VLL service:
SAP
There can only be a maximum of one SAP per VLL endpoint.
Primary spoke-SDP
The VLL service always uses this pseudowire and only switches to a secondary pseudowire when it is down the VLL service switches the path to the primary pseudowire when it is back up. The user can configure a timer to delay reverting back to primary or to never revert. There can only be a maximum of one primary spoke-SDP per VLL endpoint.
Secondary spoke-SDP
There can be a maximum of four secondary spoke-SDP per endpoint. The user can configure the precedence of a secondary pseudowire to indicate the order in which a secondary pseudowire is activated.
Inter-Chassis Backup (ICB) spoke-SDP
Special pseudowire used for MC-LAG and pseudowire redundancy application. Forwarding between ICBs is blocked on the same node. The user has to explicitly indicate the spoke-SDP is actually an ICB at creation time. There are however a few scenarios (as follows) where the user can configure the spoke-SDP as ICB or as a regular spoke-SDP on a specific node. The CLI for those cases indicate both options.
A VLL service endpoint can only use a single active object to transmit at any specific time but can receive from all endpoint objects
An explicitly named endpoint can have a maximum of one SAP and one ICB. When a SAP is added to the endpoint, only one more object of type ICB spoke-SDP is allowed. The ICB spoke-SDP cannot be added to the endpoint if the SAP is not part of a MC-LAG instance. Conversely, a SAP which is not part of a MC-LAG instance cannot be added to an endpoint which already has an ICB spoke-SDP.
An explicitly named endpoint, which does not have a SAP object, can have a maximum of four spoke SDPs and can include any of the following:
a single primary spoke-SDP
one or many secondary spoke SDPs with precedence
a single ICB spoke-SDP