To implement pseudowire redundancy, a VLL service accommodates more than a single object on the SAP side and on the spoke-SDP side. Figure 1 shows the model for a redundant VLL service based on the concept of endpoints.
By default, a VLL service supports 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 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 example in Figure 1.
In Figure 1, the Y endpoint can also have a SAP and, or an ICB spoke-SDP. The following is a list of supported endpoint objects and the applicable rules to associate the object with an endpoint of a VLL service:
SAP — A maximum of one SAP per VLL endpoint is supported.
Primary spoke-SDP — The VLL service always uses this pseudowire and only switches to a secondary pseudowire when this primary pseudowire 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. A maximum of one primary spoke-SDP per VLL endpoint is supported.
Secondary spoke-SDP — There can be a maximum of four secondary spoke-SDPs 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 — This special pseudowire is used for MC-LAG and pseudowire redundancy applications. Forwarding between ICBs is blocked on the same node. The user has to explicitly indicate that the spoke-SDP is an ICB, at creation time. However, following are a few scenarios where the user can configure the spoke-SDP as ICB or as a regular spoke-SDP on a specified node. The CLI for those cases indicates both options.
A VLL service endpoint can only use a single active object to transmit at a specific time, but it 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 an MC-LAG instance. Conversely, a SAP that is not part of an MC-LAG instance cannot be added to an endpoint that already has an ICB spoke-SDP.
An explicitly named endpoint that does not have a SAP object can have a maximum of four spoke-SDPs and includes any of the following:
a single primary spoke-SDP
one or many secondary spoke-SDPs with precedence
a single ICB spoke-SDP