2.20. Global 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. 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 creates a text description stored in the configuration file for a configuration context.

This 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 configures a customer ID and customer context used to associate information with a particular customer. Services can later be associated with this customer at the service level.

Each customer-id must be unique. The create keyword must follow each new customer customer-id entry.

Enter an existing customer customer-id (without the create keyword) to edit the customer parameters.

Default customer 1 always exists on the system and cannot be deleted.

The no form of this command removes a customer-id and all associated information. Before removing a customer-id, all references to that customer in all services must be deleted or changed to a different customer ID.

This command configures contact information for a customer.

Include any customer-related contact information, such as a technician name or account contract name.

The no form of this command removes the contact information from the customer ID.

This command adds telephone number information for a customer ID.

The no form of this command removes the phone number value from the customer ID.

This command enables the context to configure dynamic multi-segment pseudowire (MS-PW) routing. Pseudowire routing must be configured on each node that will be a T-PE or an S-PE.

This command configures a hold-off timer for MS-PW routing advertisements and signaling and is used at boot time.

The no form of this command removes a previously configured timer and restores it to the default.

This command configures one or more node prefix values to be used for MS-PW routing. At least one prefix must be configured on each node that is an S-PE or a T-PE.

The no form of this command removes a previously configured prefix, and causes the corresponding route to be withdrawn if it has been advertised in BGP.

This command enables a specific prefix to be advertised in MP-BGP for dynamic MS-PW routing.

The no form of this command will explicitly withdraw a route if it has been previously advertised.

This command configures an explicit path between this 7210 SAS T-PE and a remote 7210 SAS T-PE. For each path, one or more intermediate S-PE hops must be configured. A path can be used by multiple multi-segment pseudowires. Paths are used by a T-PE to populate the list of explicit route TLVs included in the signaling of a dynamic MS-PW.

A path may specify all or only some of the hops along the route to reach a T-PE.

The no form of this command removes a specified explicit path from the configuration.

This command configures each hop on an explicit path that can be used by one or more dynamic MSPWs. It specifies the IP addresses of the hops that the MS-PE should traverse. These IP addresses can correspond to the system IP address of each S-PE, or the IP address on which the T-LDP session to a specific S-PE terminates.

The no form of this command deletes hop list entries for the path. All the MS-PWs currently using this path are unaffected. Additionally, all services actively using these MS-PWs are unaffected. The path must be shut down before deleting the hop from the hop list. The no hop hop-index command does not result in any action, except for a warning message on the console indicating that the path is administratively up.

This optional command specifies the number of attempts that are 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 to the default value.

Note: The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C can only be configured as T-PE nodes and not as S-PE nodes. This command allows the 7210 SAS-K 2F6C4T or 7210 SAS-K 3SFP+ 8C to be configured as a T-PE node to determine the S-PE node to use for multi-segment PWs.

This command configures a single S-PE address for the node to be used for dynamic MS-PWs. This value is used for the PW switching point TLV used in LDP signaling, and is the value used by PW status signaling to indicate the PE that originates a PW status message. Configuration of this command is mandatory to enable dynamic MS-PW support on a node.

If the S-PE address is not configured, spoke-SDPs that use dynamic MS-PWs and pw-routing local prefixes cannot be configured on a T-PE. A 7210 SAS node sends a label release for any label mappings received for FEC129 AII type 2.

The S-PE address cannot be changed unless the dynamic ms-pw configuration is removed.

Changing the S-PE address results in all dynamic MS-PWs for which this node is an S-PE being released. Nokia recommends that the S-PE address be configured for the life of an MS-PW configuration after rebooting the 7210 SAS.

The no form of this command removes the configured S-PE address.

This command configures a static route to a next-hop S-PE or T-PE. Static routes may be configured on either S-PEs or T-PEs.

A default static route is entered as follows:

static-route 0:0:next_hop_ip_addresss

or

static-route 0:0.0.0.0:next_hop_ip_address

The no form of this command removes a previously configured static route.

This command configures an SDP template.

This command enables the use of the control word on pseudowire packets in VPLS and enables the use of the control word individually on each mesh-SDP or spoke-SDP.

By default, the control word is disabled. When the control word is enabled, all VPLS packets, including the BPDU frames, are encapsulated with the control word when sent over the pseudowire. The T-LDP control plane behavior is the same as in the implementation of control word for VLL services. The configuration for the two directions of the Ethernet pseudowire should match.

The no form of this command reverts the mesh-SDP or spoke-SDP to the default value.

This command creates or edits a Service Distribution Point (SDP). SDPs must be explicitly configured.

An SDP is a logical mechanism that ties a far-end 7210 SAS to a service without having to specifically define far-end SAPs. Each SDP represents a method to reach a 7210 SAS router.

The 7210 SAS supports only Multi-Protocol Label Switching (MPLS) encapsulation as the method to reach the far-end router. It does not support GRE or other encapsulation methods. A 7210 SAS supports both signaled and non-signaled Label-Switched Paths (LSPs) through the network. Non-signaled paths are defined at each hop through the network. Signaled paths are communicated by protocol from end-to-end using Resource Reservation Protocol (RSVP). Paths may be manually defined or a constraint-based routing protocol (such as OSPF-TE or CSPF) can be used to determine the best path with specific constraints. An LDP LSP can also be used for an SDP when the encapsulation is MPLS. The use of an LDP LSP type or an RSVP/static LSP type are mutually exclusive, except when the mixed LSP option is enabled on the SDP.

SDPs are created, then bound to services. Many services may be bound to a single SDP. The operational and administrative state of the SDP controls the state of the SDP binding to the service.

If sdp-id does not exist, a new SDP is created. When creating an SDP, the mpls keyword must be specified. SDPs are created in the admin down state (shutdown) and the no shutdown command must be executed when all relevant parameters are defined and before the SDP can be used.

If sdp-id exists, the current CLI context is changed to that SDP for editing and modification. For editing an existing SDP, the mpls keyword is specified. If a keyword is specified for an existing sdp-id, an error is generated and the context of the CLI is not changed to the specified sdp-id.

The no form of this command deletes the specified SDP. Before an SDP can be deleted, it must be administratively down (shutdown) and not bound to any services. If the specified SDP is bound to a service, the no sdp command fails, generating an error message specifying the first bound service found during the deletion process. If the specified sdp-id does not exist, an error is generated.

This command creates the accounting policy context that can be applied to an SDP. An accounting policy must be defined before it can be associated with an SDP. If the policy-id does not exist, an error message is generated.

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

This command enables accounting and statistical data collection for the SDP. 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 IOM 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 enables learning of new MAC addresses.

This parameter is mainly used in conjunction with the discard-unknown command.

The no form of this command enables learning of MAC addresses.

This command configures that packets received with an unknown source MAC address are dropped only if the maximum number of MAC addresses has been reached. When disabled, the packets are forwarded based on the destination MAC addresses.

The no form of this command causes packets with an unknown source MAC address to be forwarded by destination MAC addresses.

This command enables the context to configure spoke-SDP binding egress filter parameters.

This command enables the context to configure spoke-SDP binding ingress filter parameters.

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 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 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, 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 forces vc-vlan-type forwarding in the data path for spoke and mesh SDPs that have either vc-type. This command is not allowed on vlan-vc-type SDPs.

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

This command is used to create a new split horizon group for the VPLS instance. Traffic arriving on a SAP or spoke-SDP within this split horizon group is not copied to other SAPs or spoke-SDPs in the same split horizon group.

A split horizon group must be created before SAPs and spoke-SDPs can be assigned to the group. The split horizon group is defined within the context of a single VPLS instance. The same group-name can be reused in different VPLS instances.

The no form of this command removes the group name from the configuration.

This command configures the ingress VC label.

This command indicates whether the mac-move agent will limit the MAC relearn (move) rate.

This command overrides the default VC type signaled for the binding to the far end SDP. The VC type is a 15-bit quantity containing a value that represents the type of VC. The actual signaling of the VC type depends on the signaling parameter defined for the SDP. If signaling is disabled, the vc-type command can still be used to define the dot1q value expected by the far-end provider equipment.

A change of the bindings VC type causes the binding to signal the new VC type to the far end when signaling is enabled.

VC types are derived according to IETF draft-martini-l2circuit-trans-mpls.

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 overrides the advertised VC-type MTU of all spoke-SDPs of Layer 2 services using this SDP ID. When enabled, the router signals a VC MTU equal to the service MTU, which includes the Layer 2 header. It also allows this router to accept an MTU advertised by the far-end PE whose value matches either its advertised MTU or its advertised MTU minus the Layer 2 headers.

By default, the router advertises a VC-MTU equal to the Layer 2 service MTU minus the Layer 2 header and always matches its advertised MTU to that signaled by the far-end PE rotuer, otherwise the spoke-SDP goes operationally down.

When this command is enabled on the SDP, it has no effect on a spoke-SDP of an IES/VPRN spoke interface using this SDP ID. The router continues to signal a VC MTU equal to the net IP interface MTU, which is min (ip-mtu, sdp operational path mtu - Layer 2 headers). The router also continues to ensure that the advertised MTU values of both PE routers match or the spoke-SDP goes operationally down.

The no form of this command disables the VC-type MTU override and reverts to the default value.

This command allows the use of BGP route tunnels available in the tunnel table to reach SDP far-end nodes. Use of BGP route tunnels are only available with MPLS-SDP. Only one of the transport methods is allowed per SDP - LDP, RSVP-LSP, or BGP-Tunnel (BGP-Tunnel is not supported on multimode LSP).

Note: The 7210 SAS provides an option to install labels for only those BGP 3107 labeled routes which are in use by services. For more information about this option, refer to the 7210 SAS-K 2F6C4T, K 3SFP+ 8C Routing Protocols Guide.

The no form of this command disables resolving BGP route tunnel LSPs for the SDP far end.

This command configures the system IP address of the far-end destination router for the SDP that is the termination point for a service.

The far-end IP address must be explicitly configured. The destination IP address must be a system IP address.

If the SDP uses MPLS encapsulation, the far-end IP address is used to check LSP names when added to the SDP. If the “to IP address” defined within the LSP configuration does not exactly match the SDP far-end IP address, the LSP is not added to the SDP and an error is generated.

If the SDP uses MPLS encapsulation, the far-end IP address is used to check LSP names when added to the SDP. If the “to IP address” defined within the LSP configuration does not exactly match the SDP far-end IP address, the LSP is not added to the SDP and an error is generated.

Alternatively, an SDP that uses MPLS can have an MPLS-TP node with an MPLS-TP node-id and (optionally) global-id. In this case, the SDP must use an MPLS-TP LSP and the SDP signaling parameter must be set to off.

An SDP cannot be administratively enabled until a far-end IP address or MPLS-TP node-id is defined. The SDP is operational when it is administratively enabled (no shutdown) and the far-end IP address is contained in the IGP routing table as a host route. OSPF ABRs should not summarize host routes between areas. This can cause SDPs to become operationally down. Static host routes (direct and indirect) can be defined in the local device to alleviate this issue.

The no form of this command removes the currently configured destination IP address for the SDP.

The ip-address parameter is not specified and will generate an error if used in the no far-end command. The SDP must be administratively disabled using the config service sdp shutdown command before the no far-end command can be executed. Removing the far end IP address causes all lsp-name associations with the SDP to be removed.

This command configures the metric used within the tunnel table manager for decision-making purposes. When multiple SDPs going to the same destination exist, this value is used as a tie-breaker by tunnel table manager users, such as MP-BGP, to select the route with the lower value.

This command configures the use by an SDP of the mixed-LSP mode of operation. This command indicates to the service manager that it must allow a primary LSP type and a backup LSP type in the same SDP configuration; for example, the lsp and ldp commands are allowed concurrently in the SDP configuration. Users can configure one or two types of LSPs under the same SDP. Without this command, these commands are mutually exclusive.

Users can configure an RSVP LSP as a primary LSP type with an LDP LSP as a backup type. Users can also configure a BGP RFC 3107 BGP LSP as a backup LSP type.

If the user configures an LDP LSP as a primary LSP type, the backup LSP type must be an RFC 3107 BGP labeled route.

At any time, the service manager programs only one type of LSP in the line card that will activate it to forward service packets according to the following priority order:

In the case of the RSVP/LDP SDP, the service manager programs the NHLFEs for the active LSP type, preferring the RSVP LSP type over the LDP LSP type. If no RSVP LSP is configured or all configured RSVP LSPs go down, the service manager reprograms the line card with the LDP LSP, if available. If the LDP LSP is not available, the SDP goes operationally down.

When a higher priority LSP type becomes available, the service manager reverts back to this LSP at the expiry of the sdp-revert-time timer or the failure of the currently active LSP, whichever comes first. The service manager then reprograms the line card accordingly. If the infinite value is configured, the SDP reverts to the highest priority LSP type only if the currently active LSP failed.

Note: LDP uses a tunnel down damp timer that is set to three seconds by default. When the LDP LSP fails, the SDP reverts to the RSVP LSP type after the expiry of this timer. For an immediate switchover, this timer must be set to zero. Use the configure router ldp tunneldown-damp-time command. Refer to the 7210 SAS-K 2F6C4T, K 3SFP+ 8C MPLS Guide for more information about this timer.

If the value of the sdp-revert-time timer is changes, it takes effect only at the next use of the timer. Any timer that is outstanding at the time of the change is restarted with the new value. In the case of the LDP/BGP SDP, the service manager prefers the LDP LSP type over the BGP LSP type. The service manager reprograms the line card with the BGP LSP, if available, otherwise it brings down the SDP operationally.

LDP/BGP SDPs behave differently compared to RSVP/ LDP SDPs. For a /32 prefix, only a single route exists in the routing table: the IGP route or the BGP route. Either the LDP FEC or the BGP label route is active at any time. The tunnel table must be reprogrammed each time a route is deactivated and the other is activated. The SDP revert-time cannot be used because both LSP types cannot be active for the same /32 prefix.

The no form of this command disables the mixed-LSP mode of operation. The user must remove one of the LSP types from the SDP configuration or the command fails.

This command configures the delay period the SDP must wait before it reverts to a higher priority LSP type when one becomes available.

The no form of this command resets the timer to the default value of 0. This means the SDP reverts immediately to a higher priority LSP type when one becomes available.

This command enables LDP-signaled LSPs on MPLS-encapsulated SDPs.

In MPLS SDP configurations either one LSP can be specified or LDP can be enabled. The SDP ldp and lsp commands are mutually exclusive. If an LSP is specified on an MPLS SDP, LDP cannot be enabled on the SDP. To enable LDP on the SDP when an LSP is already specified, the LSP must be removed from the configuration using the no lsp lsp-name command.

Alternatively, if LDP is already enabled on an MPLS SDP, an LSP cannot be specified on the SDP. To specify an LSP on the SDP, the LDP must be disabled. The LSP must have already been created in the config>router>mpls context with a valid far-end IP address. The preceding rules are relaxed when the mixed-lsp option is enabled on the SDP.

This command creates associations between one LSP and an MPLS SDP. This command is implemented only on MPLS-type encapsulated SDPs

In MPLS SDP configurations one LSP can be specified.

The LSP must have already been created in the config>router>mpls context with a valid far-end IP address. RSVP must be enabled.

If no LSP is associated with an MPLS SDP, the SDP cannot enter the operationally up state. The SDP can be administratively enabled (no shutdown) with no LSP associations. The lsp-name may be shut down, causing the association with the SDP to be operationally down (the LSP is not used by the SDP).

The no form of this command deletes one LSP association from an SDP. If the lsp-name does not exist as an association or as a configured LSP, no error is returned. An lsp-name must be removed from all SDP associations before the lsp-name can be deleted from the system. The SDP must be administratively disabled (shutdown) before the last lsp-name associated with the SDP is deleted.

This command specifies the signaling protocol used to obtain the ingress and egress pseudowire labels in frames transmitted and received on the SDP. When signaling is off, labels are manually configured when the SDP is bound to a service. The signaling value can be changed only while the administrative status of the SDP is down.

The SDP must be administratively shut down before the signaling command can be modified and re-enabled.

This command configures the IS-IS segment routing LSP type for an MPLS SDP. The SDP of LSP type sr-isis can be used with the far-end command. The signaling protocol for the service labels for an SDP using an SR tunnel can be configured to static (off), T-LDP (tldp), or BGP (bgp).

This command configures an OSPF segment routing LSP type for an MPLS SDP. The SDP of LSP type sr-ospf can be used with the far-end command. The signaling protocol for the service labels for an SDP using an SR tunnel can be configured to static (off), T-LDP (tldp), or BGP (bgp).

This command configures the Maximum Transmission Unit (MTU) in bytes that the SDP can transmit to the far-end device router without packet dropping or IP fragmentation overriding the SDP-type default path MTU.

The default SDP-type path MTU can be overridden on a per-SDP basis. Dynamic maintenance protocols on the SDP, such as RSVP, may override this setting.

If the physical MTU on an egress interface indicates the next hop on an SDP path cannot support the current path-mtu, the operational path-mtu on that SDP is modified to a value that can be transmitted without fragmentation.

By default, the path-mtu defined on the system for the type of SDP is used.

The no form of this command removes any path-mtu defined on the SDP and the SDP will use the system default for the SDP type.

This command enables the context for configuring SDP connectivity monitoring keepalive messages for the SDP ID.

SDP-ID keepalive messages use SDP Echo Request and Reply messages to monitor SDP connectivity. The operating state of the SDP is affected by the keepalive state on the SDP-ID. SDP Echo Request messages are sent only when the SDP-ID is completely configured and administratively up. If the SDP-ID is administratively down, keepalives for that SDP-ID are disabled. SDP Echo Requests (when sent for keepalive messages) are always sent with the originator-sdp-id.

All SDP-ID keepalive SDP Echo Replies are sent using generic IP OAM encapsulation. When a keepalive response is received that indicates an error condition, the SDP ID is immediately brought operationally down. When a response is received that indicates the error has cleared and the hold-down-time interval has expired, the SDP ID is eligible to be put into the operationally up state. If no other condition prevents the operational change, the SDP ID enters the operational state.

A set of event counters track the number of keepalive requests sent, the size of the message sent, non-error replies received, and error replies received. A keepalive state value is kept indicating the last response event. A keepalive state timestamp value is kept indicating the time of the last event. With each keepalive event change, a log message is generated indicating the event type and the timestamp value.

This command configures the time period between SDP keepalive messages on the SDP-ID for the SDP connectivity monitoring messages.

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

Configures the minimum time period the SDP remains in the operationally down state in response to SDP keepalive monitoring.

This parameter can be used to prevent the SDP operational state from “flapping” by rapidly transitioning between the operationally up and operationally down states based on keepalive messages.

When an SDP keepalive response is received that indicates an error condition or the max-drop-count keepalive messages receive no reply, the sdp-id is immediately brought operationally down. If a keepalive response is received that indicates the error has cleared, the sdp-id becomes eligible to be put into the operationally up state only after the hold-down-time interval has expired.

The no form of this command reverts the hold-down-time value to the default.

This command configures the number of consecutive SDP keepalive failed request attempts or remote replies that can be missed after which the SDP is operationally downed.

If the max-drop-count consecutive keepalive request messages cannot be sent or no replies are received, the SDP ID will be brought operationally down by the keepalive SDP monitoring.

The no form of this command reverts the max-drop-count value to the default.

This command configures the size of the SDP monitoring keepalive request messages transmitted on the SDP.

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

This command configures the time interval that the SDP waits before tearing down the session.

This command enables the context to enable useful tools for debugging purposes.

This command enables the context to enable tools to perform specific tasks.

This command enables the context to configure tools for services.

This command enables the context to configure tools for a specific service.

This command enables the context to configure tools for a specific VLL service endpoint.

This command forces a switch of the active spoke-SDP for the specified service.

This command reevaluates the pseudowire template policy.

This command resets the retry counter and retry timer for the specified spoke-SDP and attempts to reestablish the spoke-SDP.

This command clears the MS-PW bindings associated with a particular SAII or TAII on an SPE.

This command displays service customer information.

This command displays the FDB entry for a specific MAC address.

This command displays services using SDP or far-end address options.

This command displays the services matching certain usage properties. If no optional parameters are specified, all services defined on the system are displayed.

This command displays information about a specified service ID.

This command displays the Ethernet ring information.

This command displays PW routing information at this 7210 node.

This command displays information about PW templates.

This command displays information about services that are using a PW template.

This command displays SDP information.

If no optional parameters are specified, a summary SDP output for all SDPs is displayed.

This command enables the context to display eth-cfm information.

This command displays Ethernet SFM association information.

This command displays stack-table information. This stack-table is used to display the various management points MEPs and MIPs configured on the system. This can be Service based. The various options allow users to be specific. If no parameters are included, the entire stack-table is displayed.

This command displays domain information.

This command displays Maintenance Endpoint (MEP) information.

Note: The show eth-cfm mep mep-id domain md-id association ma-id command does not display CCM ERROR, CCM XCON frames in the output. The show eth-cfm mep mep-id domain md-id association ma-id remote-mep rmep-id command does not display some TLVs details.

This command displays connection profile information.