3.10. VLL Services Command Reference

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 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. Default administrative states for services and service entities is described as follows in Special Cases.

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

This command configures a Circuit Emulation Services instance. When a service is created, the customer keyword and customer-id must be specified and associates 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.

The no form of this command deletes the service instance with the specified service-id. The service cannot be deleted until the service has been shutdown.

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.

On 7210 SAS, platforms operating in network mode, both local and distributed services are supported.

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 value 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. Editing a service with the incorrect customer-id value specified results in an error.

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, or spokes have been deleted from the service.

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 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: Distributed services are only supported on 7210 SAS platforms operating in the network mode. 7210 SAS platforms operating in access-uplink mode only support local SAP-to-SAP service.

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 parameter 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. Editing a service with the incorrect customer-id value specified results in an error.

The no form of this command deletes the Epipe service instance with the specified service-id value. The service cannot be deleted until it has been shut down and all instances of SAPs 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 which 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 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 which 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.

The no form of this command resets the timer to the default value of 0.

This command enables the pseudowire standby bit (value 0x00000020) to be sent to T-LDP peer for each spoke SPD 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. It is also mutually exclusive with vc-switching.

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 (i.e., 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, then all associated SAP and SDP binding operational states are automatically re-evaluated.

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

Note: 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 lesser than or equal to the MTU configured on the port.

This command configures an optional service name, up to 64 characters, which 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/administrator to identify and manage services within the 7210 SAS platforms.

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 o identify and reference a specific service when it is initially created.

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

Disabling service MTU check allows the packets to pass to the egress if the packet length is lesser 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).

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

This command creates a SAP within a service. A SAP is a combination of port and encapsulation parameters which identifies 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.

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 service. This is true only for access-uplink mode. That is, for network mode, multiple SAPs on the same port can belong to the same service.

A SAP can only be associated with 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 be defined also on 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 f the port on which theo 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 is also deleted.

This command creates 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 either the SAP, network port, or IP interface. When applying accounting policies the data, by default, 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 defines an ASCII string associated with egress-multicast-group-name.

The no form of this command removes an existing description string from egress-multicast-group.

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

This command provisions the maintenance endpoint (MEP).

See the following tables for more information about ETH-CFM support:

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

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 in seconds.

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.

For ETH-test to work, operators need to configure ETH-test parameters on both sender and receiver nodes. The ETH-test then can be done 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 done 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 specifies the threshold value of bit errors.

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

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

This command configures the fault propagation for the MEP.

This command specifies the lowest priority defect that is allowed to generate a fault alarm.

This command specifies the MAC address of the MEP.

The no form of this command reverts the MAC address of the MEP back to that of the port (if the MEP is on a SAP) or the bridge (if the MEP is on a spoke).

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 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 enables/disables eth-test functionality on MEP.

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

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. It ceases 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 user 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 the context to configure egress SAP parameters.

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

The no version of this command sets default behavior.

This command enables the use of 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 the hash-label command 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. Only the hash-2 parameters are used to compute hash-label, even if sdp is over a lag (with load-balancing set as hash-1 or hash-2) or a port. The egress data path adds 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 which 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 interface, a VPLS spoke-SDP interface, or a VPLS 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 procedures apply when the hash-label option and the signal-capability option are enabled on the local PE:

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. 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. This is not supported on 7210 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. Therefore, user must ensure that both the ends are correctly configured to either process hash labels or disable it.

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

This command enables the context to configure ingress SAP Quality of Service (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 egress aggregate policer. The rate (PIR) of the SAP egress 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 traffic sent out of the SAP and determines if the packet is either forwarded or dropped.

An option is provided to associate a set of two counters to calculate total forwarded packets and octets, and total dropped packets and octets. When the counter is enabled, the resources required increases to twice the resources required when the counter is not used. If enable-stats keyword is specified during the creation of the meter, the counter is allocated by software (if available). To free up the counter and relinquish its use, the user can use the no aggregate-meter-rate command, and then recreate the meter again 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 command configure>system>resource-profile>egress-internal-tcam>egress-sap-aggregate-meter. See 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 taken 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 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: When operating the 7210 SAS in access-uplink mode, this command is available only for access SAPs; it is not supported for access-uplink SAPs. The sum of CIR of the individual FCs configured under the SAP cannot exceed the PIR rate configured for the SAP. Though the 7210 SAS software does not block this configuration, it is not recommended for use.

Table 38 provides information about the final disposition of the packet based on the operating rate of the per FC policer and the per SAP aggregate policer.

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

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 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 IP packets. Frames that do not contain IP packets are not subject to the filter and are always be passed, even if the filter's default action 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, within the SAP ingress contexts, is used to create 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 is used to remove any existing meter overrides.

This command, within the SAP ingress contexts, is used to create 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 is used to remove any existing overrides for the specified meter-id.

This command can be used to override 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.

This command provides a mechanism to override 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 then the packets are marked as in-profile by the meter to indicate that the traffic is complying meter configured parameters.

The no form of this command returns the CBS size to the default value.

This command provides 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, the packets are marked as in-profile by the meter to indicate that the traffic is complying meter configured parameters.

The no form of this command returns the MBS size to the default value.

This command within the SAP ingress meter-overrides contexts is used to override the sap-ingress QoS policy configured mode parameters for the specified meter-id.

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

This command within the SAP ingress meter-overrides contexts is used to override the sap-ingress QoS policy configured rate parameters for the specified meter-id.

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

This command associates a Quality of Service (QoS) policy with an ingress or egress 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. If the policy-id does not exist, an error is returned.

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

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

Note: SAP egress QoS policies are only supported on the 7210 SAS-Mxp.

On the 7210 SAS-Mxp (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 the counters associated with SAP ingress and egress.

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

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 is written into the current accounting file. The configuration information is not saved across a reboot.

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

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 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 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 to associate an SDP with an Epipe or VPL service. If the sdp-id is not already configured, an error message is generated. If the sdp-id does exist, 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 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 provides the option to add 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 only comes 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 as per Section 6.1 of RFC 4447. As soon as the user also enabled the control the remote peer, the remote peer withdraws its original label and sends a label mapping with the C-bit set to 1 and the VLL service is up in both nodes.

This command enables the configuration of 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 enables 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 from RFC 6478. This command is mutually exclusive with a non-zero refresh-timer value.

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 returns the precedence 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.

The pw-path-id is only configurable if all of the following is 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 (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 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 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 is not already configured, an error message is generated. If the sdp-id does exists, a binding between that sdp-id and the service is created.

It 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 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 context.

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 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 initiates MS-PW signaling without waiting for a label mapping message from the far end. However, if the TAII has the greater value prefix, then the 7210 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 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 returns the precedence value to the default.

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 the parameter 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 only applicable to FEC129 AII type 2.

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

This command configures the service payload 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 (i.e., 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.

When binding an SDP to a service, the service MTU is compared to the path MTU associated with the SDP. The path MTU can be administratively defined in the context of the SDP. The default or administrative path MTU can be dynamically reduced due to the MTU capabilities discovered by the tunneling mechanism of the SDP or the egress interface MTU capabilities based on the next hop in the tunnel path.

If the service MTU is larger than the path MTU minus the control word length (if applicable), the SDP binding for the service is placed in an inoperative state with sdp-bind oper flag PathMTUTooSmall.

If the CEM SAP packet size is larger than the service MTU, the service is placed in an inoperative state with service oper flag ServiceMTUTooSmall. The CEM SAP packet size is defined as CEM SAP payload-size plus rtp-header size (if applicable).

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 returns the default service-mtu for the indicated service type to the default value.

This command creates a Service Access Point (SAP) within a service. A SAP is a combination of port and encapsulation parameters which identifies the service access point on the interface and within the service router. 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.

A SAP can only be associated with a single service. A SAP can only be defined on a port that has been configured as an access port using the config router interface port-type port-id mode access command. Channelized TDM ports are always access ports.

If a port is shutdown, all SAPs on that port become operationally down. When a service is shutdown, 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 no form of this command deletes the SAP with the specified port. When a SAP is deleted, all configuration parameters for the SAP is also deleted.

This command enables the context to specify circuit emulation (CEM) properties.

This command specifies the jitter buffer size, in milliseconds, and payload size, in bytes.

This command indicates the type of CEM SAP alarm.

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

This command specifies whether an RTP header is used when packets are transmitted to the packet service network (PSN) by the CEM SAP.

This command creates a list of VLAN values to be assigned to a Dot1q SAP in an Epipe service.

A connection profile can only be assigned to a Dot1q SAP which is part of an Epipe service.

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

This command provides the context to configure the VLAN ranges values.

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

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