3.8. 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, 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 help 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 provisions 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 the following links:

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

Note: 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T platforms only support local SAP to SAP service. 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C platforms support both local and distributed service.

No MAC learning or filtering is provided on an Epipe.

When a service is created, the customer keyword and customer-id must be specified and 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 is optional for navigating into the service configuration context. Attempting to edit a service with the incorrect customer-id specified results in an error.

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

The tables in the following links list the allowed SAPs for a particular value of svc-sap-type on different 7210 platforms:

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.

This command configures a service endpoint.

This command specifies that the node will delay 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.

A value of zero (default) means that when the MC-LAG transitions 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 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 any 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 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 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 is able to 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.

The no form of this command reverts to the default service-mtu value for the indicated service type.

This command configures an optional service name that adds a name identifier to a specific service to then use that service name in configuration references as well as display and use service names in show commands throughout the system. This helps the service provider or administrator to identify and manage services.

All services are required to assign a service ID to initially create a service. However, either the service ID or the service name can be used to identify and reference a specific service when it is initially created.

This command creates a Service Access Point (SAP) within a service. A SAP is a combination of port and encapsulation parameters that identify the service access point on the interface and within the 7210 device. 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. The SAP is owned by the service in which it was created.

On the 7210 SAS-D and 7210 SAS-Dxp, in a single physical port only one SAP can belong to one service. Multiple SAPs can be defined over a physical port but each of these SAPs should belong to different services. This restriction does not apply to the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, or 7210 SAS-K 3SFP+ 8C.

A SAP can be associated with only a single service. A SAP can only be defined on a port that has been configured as an access port. Additionally, in access-uplink mode, SAPs can also be defined on an access-uplink port. Access-uplink SAPs are network-facing SAPs representing dot1q or QinQ tunnels used to transport traffic toward the service nodes.

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 is 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 be deleted. For IES, the IP interface must be shut down before the SAP on that interface may be removed.

This command enables the accounting policy context that can be applied to a SAP.

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

A maximum of one accounting policy can be associated with a SAP 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, and the accounting policy reverts to the default.

This command enables accounting and statistical data collection for 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 will 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 the generation and the reception of AIS messages.

This command configures the client maintenance entity group (MEG) levels to use for AIS message generation. Up to 7 levels can be provisioned, with the restriction that the client MEG level must be higher than the local MEG level.

This command specifies the transmission interval of AIS messages.

This command specifies the priority of AIS messages originated by the node.

This command enables the generation of CCM messages.

The no form of this command disables the generation of CCM messages.

This command specifies the priority value for CCMs and LTMs transmitted by the MEP.

The no form of this command removes the priority value from the configuration.

This command enables Link Loss Forwarding (LLF) on an Ethernet port or an ATM port. This command provides an end-to-end OAM fault notification for Ethernet VLL service. It brings down the Ethernet port (Ethernet LLF) toward the attached CE 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 T-LDP status bits. It ceases when the fault disappears.

The Ethernet port must be configured for null encapsulation.

This command configures 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 specifies that ETH-AIS should be generated for client MEPs immediately when port down event is detected on the port where the server MEP (and the associated SAP) resides. By default, the system generates an ETH-AIS message, if enabled, when CCM messages are not received within the configured time period. On a subsequent port up event, the AIS messages continue to be sent until valid CCMs are received. If there are no remote MEPs configured for the MEP, on a subsequent port up event, the AIS messages are not sent.

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

This command enables the Ethernet test functionality on MEP. For ETH-test to work, users must configure ETH-test parameters on both sender and receiver nodes. The ETH-test can then be performed using the following OAM commands:

oam eth-cfm eth-test mac-address mep mep-id domain md-index association ma-index [priority priority] [data-length data-length]

A check is performed for both the provisioning and test to ensure that the MEP is an Y.1731 MEP (MEP provisioned with domain format none, association format icc-based.) If not, the operation fails. An error message in the CLI and SNMP indicates the problem.

This command configures the test pattern for eth-test frames.

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

This command is used to specify the threshold value of bit errors.

This command enables eth-test functionality on MEP.

This command configures that the source and destination MAC address for all the packets to be sent out of the SAP is swapped, then the packets are looped back to ingress of the SAP. SAP loopback is typically used with Y.1564 testhead functionality to loop back packets received on the end that is acting as a reflector, looping back packets received from the testhead generator.

This command is available for testing VLL services and VPLS services only. When enabled, no packets egress the service SAP, and packets received on ingress are not processed.

Note: Before enabling this command, turn off all Layer 2 and IP control protocols (such as LACP, EFM, 802.1x and so on) on the device and its peer to prevent errors such as protocol flaps because of timeout and so on. When SAP loopback with MAC-swap is enabled for broadcast and multicast packets (that is, packets received with multicast or broadcast destination address), the source MAC address is used as the destination MAC address and the system MAC address is the source MAC address. The user can enable MAC swap on multiple SAPs in the same service. The user can also configure static MAC on SAPs and traffic to prevent running into the MAC move, relearning issues and unpredictable device behavior.

This command allows 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 configures the fault propagation for the MEP.

This command creates a profile to configure the list of VLAN values to be assigned to a dot1q SAP in an Epipe service.

A connection profile can only be applied to a dot1q SAP that is part of an Epipe service.

The no form of this command deletes the profile from the configuration.

Provides the context to configure the VLAN ranges values.

Specifies the list of VLAN ranges or individual VLAN IDs used for mapping the specific VLANs to the Epipe SAP.

The system validates that the values specified are valid VLAN IDs in the range 0 to 4094 (VLAN ID 4095 is reserved). Ranges are specified in the format “a-b”, the expression (a < b) should be true. Up to 32 individual VLAN values or VLAN ranges can be specified. A maximum of 8 VLAN ranges are allowed per connection profile.

This command enables the context to configure egress SAP parameters.

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

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

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 aggregate rate for the access SAP shaper. The aggregate SAP shaper is available to limit only the unicast traffic and the BUM traffic across all the FCs of the SAP configured to use ingress queues.

The no form of this command disables the use of the SAP aggregate rate shaper. That is, the SAP can use up the maximum bandwidth available.

This command configures the aggregate rate for the access SAP shaper. The aggregate SAP shaper is available to limit only the unicast traffic and the BUM traffic across all the FCs of the SAP configured to use egress queues.

The no form of this command disables the use of the SAP aggregate rate shaper. That is, the SAP can use up the maximum bandwidth available.

This command configures the access SAP egress aggregate policer. The rate (PIR) of the SAP egress aggregate policer must be specified. The user can optionally specify the burst size for the SAP aggregate policer. The aggregate policer monitors the traffic sent out of the SAP and determines the final disposition of the packet, which is either forwarded or dropped.

The user can optionally associate a set of two counters to count total forwarded packets and octets and total dropped packets and octets. When use of this counter is enabled, the amount of resources required increases by twice the amount of resources taken up when the 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, 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 accounting 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 config system resource-profile egress-internal-tcam egress-sap-aggregate-meter command. Refer to the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C 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 in which 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 allows the user to configure the access 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 using policers to rate-limit the flow and determines the final disposition of the packet. The packet is either forwarded to an identified profile or dropped.

Note: The sum of the CIR of the individual FCs configured under the SAP cannot exceed the PIR rate configured for the SAP. Although the 7210 SAS software does not block this configuration, Nokia does not recommend this configuration. The queued traffic flows are not limited by the aggregate meter. That is, only metered flows can use the aggregate meter. Queue flows can use only the aggregate shaper.

Table 31 lists the final disposition of the packet based on the operating rate of the per FC policer and the per SAP aggregate policer.

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

The no form of this command removes the 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 will fail and an error message 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 filter default action is to drop.

Note: For filter support available on different 7210 SAS platforms, refer to the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C 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 defines the dot1p marking values used per SAP on egress for the inner tag when the SAP encapsulation is QinQ (that is, Q1.Q2 SAP).

This command takes effect only if remarking is enabled in the remark policy associated with this SAP (under the egress context). It overrides the marking values defined in the remark policy associated with this SAP, if any.

Table 32 describes the dot1p values extracted from the packet on SAP (ingress) when dot1p-inner and dot1p-outer CLI commands are configured.

Table 33 describes the dot1p values marked in the packet on SAP egress when dot1p inner and dot1p-outer CLI commands are configured.

Note: The NA entry in the preceding table means egress encapsulation is not done, and neither the remark policy nor the use-rcvd command will be applicable at that level.

When the no form of this command is executed, the values defined in the remark policy associated with this SAP are used, if any. If no remark policy is associated with SAP egress, the default values are used.

This command defines the dot1p marking values to be used per SAP on egress for the outer tag when the SAP encapsulation is QinQ or dot1q. The command takes effect only if remarking is enabled in the remark policy associated with this SAP (under the egress context). It overrides the marking values defined in the remark policy associated with this SAP, if any. For more information, see Table 32 and Table 33.

When the no form of this command is executed, the values defined in the remark policy associated with this SAP are used, if any. If no remark policy is associated with SAP egress, the default values are used.

Note: The config>service>vprn>if>sap>ingress context is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

This command, within the SAP ingress contexts, creates a CLI node for specific overrides to one or more meters created on the SAP through the SAP-ingress QoS policies.

The no form of this command removes any existing meter overrides.

Note: The config>service>vprn>if>sap>ingress>meter-override context is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

This command, within the SAP ingress contexts, creates a CLI node for specific overrides to a specific meter created on the SAP through a SAP-ingress QoS policies.

The no form of this command removes any existing overrides for the specified meter ID.

Note: The config>service>vprn>if>sap>ingress>meter-override>meter context is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

This command overrides 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 any 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.

Note: The config>service>vprn>if>sap>ingress>meter-override>meter context is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

This command overrides 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 the CBS size to the default value.

Note: The config>service>vprn>if>sap>ingress>meter-override>meter context is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

This command overrides 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 PIR. If the transmitted burst is lower than the MBS 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 the MBS size to the default value.

Note: The config>service>vprn>if>sap>ingress>meter-override>meter context is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

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

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

Note: The config>service>vprn>if>sap>ingress>meter-override>meter context is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

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

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

This command associates a 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 ingress policies. The qos command only allows ingress policies to be associated on SAP ingress. 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 QoS policy of a specific type returns an error.

By default, if no specific QoS policy is associated with the SAP for ingress, 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 the counters associated with SAP ingress and egress.

This command enables the context to configure the egress SAP statistics counter and set the mode of the counter.

This counter counts the number of packets forwarded through the SAP.

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

The ingress counters are not enabled by default for access-uplink SAPs. For access SAPs, if the ingress counter is enabled by default, it can be disabled.

The types of ingress SAP counters are the following:

This command associates a counter with the SAP. The counter counts the number of packets forwarded through the SAP.

A limited number of such counters are available for use with access SAPs and access-uplink SAPs.

Use this command before enabling applicable accounting record collection on the SAP to associate a counter with the SAP.

The no form of this command disables the packet count.

This command sets the counter mode for the counters associated with SAP ingress meters or 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.

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

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

This command associates a counter with the SAP. It counts the number of packets and octets received on the SAP (ingress).

A limited number of such counters are available for use with access-uplink SAPs.

Use this command before enabling applicable accounting record collection on the SAP.

The no form of this command disables counter.

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

The SDP has an operational state that 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 is 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 command 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 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 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, as 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 comes up only 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, according to Section 6.1 of RFC 4447. When the user also enables the control 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 is then up in both nodes.

This command configures the hash label on VLL or VPLS services that are bound to RSVP SDP, 3107 BGP SDP, segment routing, or LDP SDP, using the auto-bind mode with the ldp, rsvp-te, or mpls options. When this command is enabled, the ingress data path is modified so 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 ingress 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 devices, the hash label is not used on the local node for ECMP and LAG hashing. It is available for use by LSR nodes, through which the traffic flows, that are capable of using the labels for hashing.

Packets generated in the CPM that are forwarded with a label 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 0.

Signaling of the hash label capability is enabled by adding the signal-capability option under the VLL spoke-SDP, VPLS spoke-SDP or mesh SDP interface, or PW template instance. In this case, the decision of the local PE to insert the hash label on the user and control plane packets is determined by the outcome of the signaling process and can override the local PE configuration. The following process flow applies when the hash-label and signal-capability options are enabled on the local PE.

If the hash-label command is enabled on the local PE with the signal-capability option configured and on the remote PE without the signal-capability option configured on the spoke-SDP or mesh-SDP, the hash label is included in the pseudowire packets received by the local PE. These packets must be dropped. To resolve this situation, you must disable the signal-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 is not enabled on the local configuration of the spoke-SDP or mesh-SDP at the remote PE, the hash label is not included in the pseudowire received by the local PE.

If the signal-capability option is enabled or disabled in the CLI, 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 is 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 7750 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. This means that 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 that the hash label does not match a value in the reserved label range. 7210 SAS devices do not set the MSB in the hash label value for service traffic. Therefore, the user must ensure that both ends are correctly configured to either process hash labels or disable them. The MSB bit is set for MPLS/OAM traffic on 7210 SAS devices. The cpe-ping, mac-ping, and svc-ping commands are not supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C when the hash-label command is enabled.

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 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 the precedence to the default value.

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 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 that 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 is 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 terminates 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 of the MS-PW. The 7210 associates an SDP with a service. If an SDP to that service is not already configured, an error message is generated. If the SDP ID exists, a binding between that SDP ID and the service is created.

This command differs from the spoke-sdp command because 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 Generalized 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 sends the initial label mapping message using T-LDP, while the 7210 T-PE for which auto-config is specified acts 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 contexts.

The no form of this command means that the 7210 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 initiates MS-PW signaling and waits 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 value should correspond to the name of an explicit path configured in the config>service>pw-routing context.

If no path is configured, each next hop of the MS-PW used by the spoke-SDP is 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 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 precedence to the default value.

This command binds 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 that should be made 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 and a label withdraw message is received with the status code “AII unreachable”.

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

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

This command configures 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, the endpoing 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 initiates 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 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.

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).