3.10. VLL Services Command Reference

This command administratively disables an entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics.

The operational state of the entity is disabled as well as the operational state of any entities contained within. Many objects must be shut down before they may be deleted.

Services are created in the administratively down (shutdown) state. When a no shutdown command is entered, the service becomes administratively up and then tries to enter the operationally up state.

The no form of this command places the entity into an administratively enabled state.

This command creates a text description stored in the configuration file for a configuration context. The description command associates a text string with a configuration context to identify the content in the configuration file.

The no form of this command removes the string from the configuration.

This command enables the context to configure ETH-CFM parameters.

This command configures the Maintenance Endpoint (MEP).

The no form of this command reverts to the default values.

For more information about ETH-CFM support for different services, see Table 9.

This command configures a point-to-point Epipe service instance. An Epipe connects two endpoints, defined as Service Access Points (SAPs). In a local service, the SAPs can be defined in one 7210 SAS node, and in a distributed service, the SAPs can be defined on two different 7210 SAS nodes.

Note: 7210 SAS platforms as described in this document support local SAP-to-SAP service. 7210 SAS platforms as described in this document support both local and distributed services.

MAC learning and filtering are not supported on an Epipe service.

When a service is created, the customer keyword and customer-id parameter must be specified to associate the service with a customer. The customer-id must already exist, having been created using the customer command in the service context. When a service has been created with a customer association, it is not possible to edit the customer association. The service must be deleted and recreated with a new customer association.

When a service is created, the use of the customer customer-id command is optional for navigating into the service configuration context. Edit a service with the incorrect customer-id value specified results in an error.

By default, no epipe services exist until they are explicitly created with this command.

The no form of this command deletes the Epipe service instance with the specified service-id. The service cannot be deleted until the service has been shut down and all instances of SAPs, mesh SDPs, or spoke SDPs have been deleted from the service.

This command configures a service endpoint.

This command specifies that the node delays sending the change in the T-LDP status bits for the VLL endpoint when the MC-LAG transitions the LAG subgroup that hosts the SAP for this VLL endpoint from active to standby or when any object in the endpoint. For example, SAP, ICB, or regular spoke-SDP, transitions from up to down operational state.

By default, when the MC-LAG transitioned the LAG subgroup that hosts the SAP for this VLL endpoint from active to standby, the node immediately sends new T-LDP status bits indicating the new value of "standby" over the spoke SDPs that are on the mate-endpoint of the VLL. The same applies when an object in the endpoint changes an operational state from up to down.

A value of zero means that when the MC-LAG transitioned the LAG subgroup which hosts the SAP for this VLL endpoint from active to standby, the node sends immediately new T-LDP status bits indicating the new value of standby over the spoke SDPs which are on the mate-endpoint of the VLL. The same applies when any object in the endpoint changes an operational state from up to down.

There is no delay applied to the VLL endpoint status bit advertisement when the MC-LAG transitions the LAG subgroup that hosts the SAP from "standby" to "active" or when an object in the endpoint transitions to an operationally up state.

This command configures the time to wait before reverting back to the primary spoke-SDP defined on this service endpoint, after having failed over to a backup spoke-SDP.

When this command is enabled, the pseudowire standby bit (value 0x00000020) is sent to T-LDP peer for each spoke SDP of the endpoint that is selected as a standby.

This command is mutually exclusive with a VLL mate SAP created on an MC-LAG or ICB. This command is also mutually exclusive with the vc-switching parameter.

This command configures the service payload (Maximum Transmission Unit – MTU), in bytes, for the service. This MTU value overrides the service-type default MTU. The service-mtu defines the payload capabilities of the service. It is used by the system to validate the SAP and the SDP binding operational state within the service.

The service MTU and a SAP service delineation encapsulation overhead (that is, 4 bytes for a dot1q tag) is used to derive the required MTU of the physical port or channel on which the SAP was created. If the required payload is larger than the port or channel MTU, the SAP is placed in an inoperative state. If the required MTU is equal to or less than the port or channel MTU, the SAP can transition to the operative state.

In the event that a service MTU, port or channel MTU, or path MTU is dynamically or administratively modified, all associated SAP and SDP binding operational states are automatically reevaluated.

To disable service MTU check, execute the command no service-mtu-check. Disabling service MTU check allows the packets to pass to the egress if the packet length is less than or equal to the MTU configured on the port.

The no form of this command reverts to the default value.

Disabling service MTU check allows the packets to pass to the egress if the packet length is less than or equal to the MTU configured on the port. The length of the packet sent from a SAP is limited only by the access port MTU. In case of a pseudowire, the length of a packet is limited by the network port MTU (including the MPLS encapsulation).

The no form of this command disables the service MTU check.

Note: If TLDP is used for signaling, the configured value for service-mtu is used during pseudowire set up.

This command creates a SAP within a service. A SAP is a combination of port and encapsulation parameters that identify the SAP on the interface and within the service. Each SAP must be unique.

All SAPs must be explicitly created. If no SAPs are created within a service or on an IP interface, a SAP does not exist on that object.

Enter an existing SAP without the create keyword to edit SAP parameters.

For ports in network mode, multiple SAPs on the same port can belong to the same service.

If a port is shut down, all SAPs on that port become operationally down. When a service is shut down, SAPs for the service are not displayed as operationally down, although all traffic traversing the service will be discarded.

The operational state of a SAP is relative to the operational state of the port on which the SAP is defined.

The following encapsulations are supported:

The no form of this command deletes the SAP with the specified port. When a SAP is deleted, all configuration parameters for the SAP are also deleted.

This command applies a time-based policy (filter or QoS policy) to the service SAP. The suite name must already exist in the config>cron context.

This command creates the accounting policy context that can be applied to a SAP or spoke-SDP.

An accounting policy must be defined before it can be associated with a SAP or spoke-SDP. If the policy-id does not exist, an error message is generated.

A maximum of one accounting policy can be associated with a SAP or spoke-SDP at one time. Accounting policies are configured in the config>log context.

The no form of this command removes the accounting policy association from the SAP or spoke-SDP, and the accounting policy reverts to the default.

This command enables accounting and statistical data collection for either the SAP, network port, or IP interface. When applying accounting policies, by default the data is collected in the appropriate records and written to the designated billing file.

When the no collect-stats command is issued, the statistics are still accumulated by the cards. However, the CPU does not obtain the results and write them to the billing file. If a subsequent collect-stats command is issued, the counters written to the billing file include all the traffic while the no collect-stats command was in effect.

This command configures Ethernet properties in this SAP.

This command enables Link Loss Forwarding (LLF) on an Ethernet port. It provides an end-to-end OAM fault notification for Ethernet VLL service.

LLF on an Ethernet port brings down the port when there is a local fault on the pseudowire or service, or a remote fault on the SAP or pseudowire, signaled with label withdrawal or TLDP status bits. LLF stops signaling when the fault disappears.

The Ethernet port must be configured for null encapsulation.

The no form of this command disables LLF.

This command enables the context to configure the optional command for a specific SAP to ignore the transition of the operational state to down when a SAP fails. Only a single SAP in an Epipe may use this option.

This command enables Maintenance Intermediate Points (MIPs) to be created if mhf-creation for the MA is configured using the default option.

The no form of this command deletes the MIP.

This command enables the context to configure egress SAP parameters.

This command defines a maximum total rate for all egress queues on a service SAP.

The SAP aggregate rate can be used only if SAP based-scheduling mode is configured at the port level. It is not supported in FC-based scheduling mode.

When configured in SAP-based scheduling mode, the egress port scheduler distributes the available bandwidth to all the SAPs configured on the port, up to the configured aggregate rate for the SAP.

The no form of this command removes the aggregate rate limit from the SAP.

This command associates a set of two counters to count total forwarded packets and octets and total dropped packets and octets. When enabled, the amount of resources required increases by twice the amount of resources taken up when counter is not used. If the enable-stats keyword is specified during the creation of the meter, the counter is allocated by the software, if available. To free up the counter and relinquish its use, use the no aggregate-meter-rate command, and then recreate the meter using the aggregate-meter-rate command.

If egress Frame-based accounting is used, the SAP egress aggregate meter rate accounts for the Ethernet frame overhead. The system accounts for 12 bytes of IFG and 8 bytes of start delimiter. Frame-based counting does not affect the count of octets maintained by the counter, if in use.

Note: Before enabling this command for a SAP, resources must be allocated to this feature from the egress internal TCAM resource pool using the configure system resource-profile egress-internal-tcam egress-sap-aggregate-meter command. Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Basic System Configuration Guide for more information. The egress aggregate meter is not FC aware. The forward and drop decisions are made based on the order the packets are sent out of the SAP by the egress port scheduler.

The no form of this command removes the egress aggregate policer from use.

This command associates an IP filter policy with an ingress or egress SAP or IP interface.

Filter policies control the forwarding and dropping of packets based on IP matching criteria. Only one filter can be applied to a SAP at a time.

The filter command is used to associate a filter policy with a specified filter-id with an ingress or egress SAP. The filter-id must already be defined before the filter command is executed. If the filter policy does not exist, the operation fails and an error message is returned.

IP filters apply only to RFC 2427-routed IP packets. Frames that do not contain IP packets are not subject to the filter and are always passed, even if the default action of the filter is to drop.

Note: For filter support available on different 7210 SAS platforms, refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Router Configuration Guide.

The no form of this command removes any configured filter ID association with the SAP or IP interface. The filter ID is not removed from the system.

This command associates a Quality of Service (QoS) policy with an ingress SAP.

QoS ingress policies are important for the enforcement of SLA agreements. The policy ID must be defined before associating the policy with a SAP or IP interface. If the policy-id does not exist, an error is returned.

The qos command is used to associate both ingress and egress QoS policies. The qos command allows ingress policies to be associated only on SAP or IP interface ingress, and allows egress policies only on SAP or IP interface egress. Attempts to associate a QoS policy of the wrong type returns an error.

Only one ingress QoS policy can be associated with a SAP or IP interface at one time. Attempts to associate a second policy of same or different type replaces the earlier one with the new policy.

On the 7210 SAS-R6 and 7210 SAS-R12 (ingress), using the enable-table-classification keyword enables the use of IP DSCP tables to assign FC and profile on a per-SAP ingress basis. The match-criteria configured from the service ingress policy, which require CAM resources, are ignored. Only meters from the service ingress policy are used (and the meters still require CAM resources). The IP DSCP classification policy configured in the SAP ingress policy is used to assign FC and profile. The default FC is assigned from the SAP ingress policy.

By default, if no specific QoS policy is associated with the SAP for ingress or egress, the default QoS policy is used.

The no form of this command removes the QoS policy association from the SAP, and the QoS policy reverts to the default.

This command enables the context to configure ingress SAP QoS policies.

If no SAP ingress QoS policy is defined, the system default SAP ingress QoS policy is used for ingress processing.

This command configures the SAP ingress aggregate policer. The rate of the SAP ingress aggregate policer must be specified by the user. The user can optionally specify the burst size for the SAP aggregate policer. The aggregate policer monitors the ingress traffic on different FCs and determines the final disposition of the packet. The packet is either forwarded to an identified profile or dropped.

Note: The sum of CIR of the individual FCs configured under the SAP cannot exceed the PIR rate configured for the SAP. The 7210 SAS software does not block this configuration, however it is not recommended.

When the SAP aggregate policer is configured, per FC policer can be configured only in “trtcm2” mode (RFC 4115).

Note: The meter modes “srtcm” and “trtcm1” are used in the absence of an aggregate meter.

The SAP ingress meter counters increment the packet or octet counts based on the final disposition of the packet.

If ingress Frame-based accounting is used, the SAP aggregate meter rate accounts for the Ethernet frame overhead. The system accounts for 12 bytes of IFG and 8 bytes of start delimiter.

The no form of this command removes the aggregate policer from use.

This command configures specific overrides to one or more meters created on the SAP through the sap-ingress QoS policies.

The no form of this command is used to remove existing meter overrides.

This command enables the context for specific overrides to a specific meter created on the SAP through a SAP ingress QoS policies.

The no form of this command is used to remove existing overrides for the specified meter-id.

This command configures the override of specific attributes of the specified meter adaptation rule parameters. The adaptation rule controls the method used by the system to derive the operational CIR and PIR settings when the meter is provisioned in hardware. For the CIR and PIR parameters individually, the system attempts to find the best operational rate, depending on the defined constraint.

The no form of this command removes explicitly defined constraints used to derive the operational CIR and PIR created by the application of the policy. When a specific adaptation-rule is removed, the default constraints for rate and cir apply.

This command configures the override of the default CBS for the meter. The committed burst size parameter specifies the maximum burst size that can be transmitted by the source while still complying with the CIR. If the transmitted burst is lower than the CBS value, the packets are marked as in-profile by the meter to indicate that the traffic is complying with meter configured parameters.

The no form of this command reverts to the default value.

This command configures a mechanism to override the default MBS for the meter. The maximum burst size parameter specifies the maximum burst size that can be transmitted by the source while still complying with the CIR. If the transmitted burst is lower than the MBS value then the packets are marked as in-profile by the meter to indicate that the traffic is complying with meter configured parameters.

The no form of this command reverts to the default value.

This command overrides the SAP ingress QoS policy configured mode parameters for the specified meter-id.

The no form of this command restores the policy defined metering and profiling mode to a meter.

This command overrides the SAP ingress QoS policy configured rate parameters for the specified meter-id.

The max default specifies the amount of bandwidth in kilobits per second (thousand bits per second). The max value is mutually exclusive to the pir-rate value.

The no form of this command reverts the policy defined metering and profiling rate to a meter.

This command enables the context to configure the counters associated with SAP ingress and egress.

This command enables the context to configure the ingress SAP statistics counter.

This command sets the counter mode for the counters associated with SAP ingress meters (also known as policers). A pair of counters is available with each meter. These counters count different events based on the counter mode value.

Note: The counter mode can be changed if an accounting policy is associated with a SAP. If the counter mode is changed, the counters associated with the meter are reset and the counts are cleared. If an accounting policy is in use when the counter mode is changed, a new record will be written into the current accounting file. The configuration information is not saved across a reboot.

Perform the following sequence of commands on the specified SAP to ensure the correct statistics are collected when the counter-mode is changed.

The no form of this command reverts to the default value.

This command associates a counter, which enables the counting of extra VLAN-tag dropped packets for the SAP or spoke-SDP. A limited number of such counters are available for use.

The no form of this command removes the associated counter.

This command binds a service to an existing Service Distribution Point (SDP).

The SDP has an operational state, which determines the operational state of the SDP within the service; for example, if the SDP is administratively or operationally down, the SDP for the service will be down.

The SDP must already exist in the config>service>sdp context before it can be associated with an Epipe or VPL service. If the sdp sdp-id is not already configured, an error message is generated. If the sdp-id exists, a binding between the specific sdp-id and the service is created.

SDPs must be explicitly associated and bound to a service to allow far-end 7210 SAS-R6 and 7210 SAS-R12 devices to participate in the service.

The no form of this command removes the SDP binding from the service; the SDP configuration is not affected. When the SDP binding is removed, no packets are forwarded to the far-end router.

This command adds a control word as part of the packet encapsulation for pseudowire types for which the control word is optional. These are Ethernet pseudowires (Epipe).

The configuration for the two directions of the pseudowire must match because the control word negotiation procedures described in Section 6.2 of RFC 4447 are not supported. The C-bit in the pseudowire FEC sent in the label mapping message is set to 1 when the control word is enabled. Otherwise, it is set to 0.

The service will only come up if the same C-bit value is signaled in both directions. If a spoke-sdp is configured to use the control word but the node receives a label mapping message with a C-bit clear, the node releases the label with the an “Illegal C-bit” status code, in accordance with Section 6.1 of RFC 4447. When the user also enables the control on the remote peer, the remote peer withdraws its original label and sends a label mapping with the C-bit set to 1; the VLL service will then be up in both nodes.

This command enables the context to configure static pseudowire status signaling on a spoke-SDP for which signaling for its SDP is set to OFF.

A control-channel-status no shutdown is allowed only if all of the following is true:

The no form of this command removes control channel status signaling form a spoke-sdp. It can only be removed if control channel status is shutdown.

This command configures the acknowledgment of control channel status messages. By default, no acknowledgment packets are sent.

This command configures the refresh timer for control channel status signaling packets. By default, no refresh packets are sent.

This command configures the control channel status request mechanism. When it is configured, control channel status request procedures are used. These augment the procedures for control channel status messaging, in accordance with RFC 6478. This command is mutually exclusive with a non-zero refresh-timer value.

This command forces vc-vlan-type forwarding in the data path for spokes that have either vc-type. This command is not allowed on vlan-vc-type SDPs.

The no version of this command reverts to the default value.

This command configures the use of the hash label on a VLL or VPLS service bound to LDP or RSVP SDP using the autobind mode with the ldp, rsvp-te, or mpls options. When this feature is enabled, the ingress data path is modified such that the result of the hash on the packet header is communicated to the egress data path for use as the value of the label field of the hash label. The egress data path appends the hash label at the bottom of the stack (BoS) and sets the S-bit to one (1).

Note: On 7210 SAS, the hash label is not used on the local node for purpose of ECMP hashing and LAG hashing. It is available for use by LSR nodes through which the traffic flows and that are capable of using the labels for hashing.

Packets generated in CPM and that are forwarded labeled within the context of a service (for example, OAM packets) must also include a hash label at the BoS and set the S-bit accordingly.

The TTL of the hash label is set to a value of 0.

The user enables the signaling of the hash-label capability under a VLL spoke-sdp, a VPLS spoke-sdp, or mesh-sdp interface by adding the signal-capability option. In this case, the decision whether to insert the hash label on the user and control plane packets by the local PE is solely determined by the outcome of the signaling process and can override the local PE configuration. The following rules apply when the hash-label option and the signal-capability option are enabled on the local PE.

If the hash-label option was enabled on the local configuration of the spoke-sdp or mesh-sdp at the remote PE, the pseudowire packets received by the local PE will have the hash label included. These packets must be dropped. The only way to solve this is to disable the signaling capability option on the local node, which results in the insertion of the hash label by both PE nodes.

If the hash-label option is not supported or was not enabled on the local configuration of the spoke-SDP or mesh SDP at the remote PE, the pseudowire received by the local PE does not have the hash label included.

The user can enable or disable the signal-capability option in CLI as needed. When doing so, the router must withdraw the label it sent to its peer and send a new label mapping message with the new value of the F bit in the flow label interface parameters sub-TLV of the PW ID FEC element.

Note: This feature is supported only for VLL and VPLS services. It not supported for VPRN services. It is also not supported on multicast packets forwarded using RSVP P2MP LPS or mLDP LSP in both the base router instance and in the multicast VPN (mVPN) instance. In 7x50 and possibly other vendor implementations, to allow applications where the egress LER infers the presence of the hash label implicitly from the value of the label, the Most Significant Bit (MSB) of the result of the hash is set before copying into the Hash Label. Therefore, the value of the hash label is always in the range [524,288 to 1,048,575] and does not overlap with the signaled/static LSP and signaled/static service label ranges. This also guarantees the hash label does not match a value in the reserved label range. This is not supported on 7210 SAS for service traffic (for MPLS OAM traffic the MSB bit is set). That is, 7210 SAS devices do not set the MSB bit in the hash label value for service traffic. If enabled, the user must ensure that both the ends are correctly configured to process hash labels.

The no form of this command disables the use of the hash label.

This command specifies the precedence of the SDP binding when there are multiple SDP bindings attached to one service endpoint. The value of zero can only be assigned to one SDP bind making it the primary SDP bind. When an SDP binding goes down, the next highest precedence SDP binding begins to forward traffic.

The no form of this command reverts the value to the default.

This command enables the context to configure an MPLS-TP Pseudowire Path Identifier for a spoke-SDP. All elements of the PW path ID must be configured to enable a spoke-SDP with a PW path ID.

For an IES or VPRN spoke-SDP, the PW path ID is only valid for Ethernet spoke SDPs.

This command is configurable only if all the following conditions are true:

The no form of this command deletes the PW path ID.

This command configures the attachment group identifier for an MPLS-TP PW.

This command configures the source individual attachment identifier (SAII) for an MPLS-TP spoke-sdp. If this is configured on a spoke-sdp for which vc-switching is also configured, that is, if it is at an S-PE, the values must match those of the taii-type2 of the mate spoke-sdp.

This command configures the source individual attachment identifier (SAII) for an MPLS-TP spoke-sdp. If this is configured on a spoke-sdp for which vc-switching is also configured, that is, it is at an S-PE, the values must match those of the taii-type2 of the mate spoke-sdp.

This command enables pseudowire status signaling for this spoke-SDP binding.

The no form of this command disables the status signaling.

This command configures the egress VC label.

This command configures the ingress VC label.

This command specifies an explicit dot1q value used when encapsulating to the SDP far end. When signaling is enabled between the near and far end, the configured dot1q tag can be overridden by a received TLV specifying the dot1q value expected by the far end. This signaled value must be stored as the remote signaled dot1q value for the binding. The provisioned local dot1q tag must be stored as the administrative dot1q value for the binding.

When the dot1q tag is not defined, the default value of zero is stored as the administrative dot1q value. Setting the value to zero is equivalent to not specifying the value.

The no form of this command disables the command.

This command binds a service to an existing Service Distribution Point (SDP), using a dynamic MS-PW.

A spoke-SDP is treated like the equivalent of a traditional bridge “port” where flooded traffic received on the spoke-SDP is replicated on all other “ports” (other spoke and mesh SDPs or SAPs) and not transmitted on the port it was received.

The SDP has an operational state which determines the operational state of the SDP within the service. For example, if the SDP is administratively or operationally down, the SDP for the service will be down.

When using dynamic MS-PWs, the particular SDP to bind-to is automatically selected based on the Target Attachment Individual Identifier (TAII) and the path to use, specified under spoke-SDP FEC. The selected SDP will terminate on the first hop S-PE of the MS-PW. Therefore, an SDP must already be defined in the config>service>sdp context that reaches the first hop 7210 SAS of the MS-PW. The 7210 SAS will to associate an SDP with a service. If an SDP is not already configured, an error message is generated. If the sdp-id does exist, a binding between that sdp-id and the service is created.

This command differs from the spoke-sdp command in that the spoke-sdp command creates a spoke-SDP binding that uses a PW with the PW ID FEC. However, the spoke-sdp-fec command enables PWs with other FEC types to be used. In Release 9.0, only the Generalised ID FEC (FEC129) may be specified using this command.

The no form of this command removes the SDP binding from the service. The SDP configuration is not affected; only the binding of the SDP to a service. When removed, no packets are forwarded to the far-end router.

This command enables single-sided automatic endpoint configuration of the spoke-SDP. The 7210 SAS acts as the passive T-PE for signaling this MS-PW.

Automatic Endpoint Configuration allows the configuration of a spoke-SDP endpoint without specifying the TAII associated with that spoke-SDP. It allows a single-sided provisioning model where an incoming label mapping message with a TAII that matches the SAII of that spoke-SDP to be automatically bound to that endpoint. In this mode, the far end T-PE actively initiates MS-PW signaling and will send the initial label mapping message using T-LDP, while the 7210 SAS T-PE for which auto-config is specified will act as the passive T-PE.

The auto-config command is blocked in CLI if signaling active has been enabled for this spoke-SDP. It it is only applicable to spoke SDPs configured under the Epipe, IES and VPRN interface context.

The no form of this command means that the 7210 SAS T-PE either acts as the active T-PE (if signaling active is configured) or automatically determines which 7210 SAS initiates MS-PW signaling based on the prefix values configured in the SAII and TAII of the spoke-SDP. If the SAII has the greater prefix value, the 7210 SAS initiates MS-PW signaling without waiting for a label mapping message from the far end. However, if the TAII has the greater value prefix, the 7210 SAS assumes that the far end T-PE will initiate MS-PW signaling and will wait for that label mapping message before responding with a T-LDP label mapping message for the MS-PW in the reverse direction.

This command specifies the explicit path, containing a list of S-PE hops, that should be used for this spoke-SDP. The path-name should correspond to the name of an explicit path configured using the config>service>pw-routing context.

If no path is configured, each next-hop of the MS-PW used by the spoke-SDP will be chosen locally at each T-PE and S-PE.

This command specifies the precedence of the SDP binding when there are multiple SDP bindings attached to one service endpoint. The value of zero can be assigned to only one SDP bind making it the primary SDP bind. When an SDP binding goes down, the next highest precedence SDP binding begins to forward traffic.

The no form of this command reverts to the default value.

This command binds the parameters included in a specific PW Template to a spoke-SDP.

The no form of this command removes the values from the configuration.

This optional command specifies the number of attempts software should make to reestablish the spoke-SDP after it has failed. After each successful attempt, the counter is reset to zero.

When the specified number is reached, no more attempts are made, and the spoke-sdp is put into the shutdown state.

Use the no shutdown command to bring up the path after the retry limit is exceeded.

The no form of this command reverts to the default value.

This command specifies a retry-timer for the spoke-SDP. This is a configurable exponential back-off timer that determines the interval between retries to reestablish a spoke-SDP if it fails, a label withdraw message is received with the status code “AII unreachable”.

The no form of this command reverts to the default value.

This command configures the source attachment individual identifier for the spoke-sdp. This is only applicable to FEC129 AII type 2.

This command enables the context to configure this 7210 SAS as the active or passive T-PE for signaling this MS-PW, or to automatically select whether this T-PE is active or passive based on the prefix.

In an active role, this endpoint initiates MS-PW signaling without waiting for a T-LDP label mapping message to arrive from the far end T-PE. In a passive role, it waits for the initial label mapping message from the far end before sending a label mapping for this end of the PW. In auto mode, if the SAII has the greater prefix value, the 7210 SAS initiates MS-PW signaling without waiting for a label mapping message from the far end. However, if the TAII has the greater value prefix, the 7210 SAS assumes that the far end T-PE will initiate MS-PW signaling and will wait for that label mapping message before responding with a T-LDP label mapping message for the MS-PW in the reverse direction.

The no form of this command means that the 7210 SAS T-PE automatically selects the 7210 SAS that will initiate MS-PW signaling based on the prefix values configured in the SAII and TAII of the spoke-SDP, as described previously.

When this command is enabled, the node blocks the transmit forwarding direction of a spoke-SDP based on the setting of the standby bit received from a T-LDP peer.

This command is present at the endpoint level and spoke-SDP level. If the spoke-sdp is part of an explicit-endpoint, it is not possible to change this setting at the spoke-sdp level. An existing spoke-sdp can be made part of the explicit endpoint only if the settings do not conflict. A newly created spoke-sdp, which is part of a specific explicit-endpoint, inherits this setting from the endpoint configuration. An existing spoke-sdp cannot be moved to an endpoint if the setting of standby-signaling-slave is not the same as at the endpoint level. If the standby-signaling-slave setting is changed at the endpoint level, that change is automatically populated to the member spoke-sdps.This command is mutually exclusive with an endpoint that is part of an MC-LAG, ICB, and MC endpoint, or for which standby-signaling-master has been enabled.

If this command is disabled, the node assumes the existing Release 5.0 mode of behavior for forwarding on the spoke-SDP.

This command configures the target attachment individual identifier for the spoke-sdp. This is only applicable to FEC129 AII type 2.

This command is blocked in CLI if this end of the spoke-SDP is configured for single-sided auto configuration (using the auto-config command).