2.13. Global Services Command Reference

This command administratively disables an entity. When disabled, an entity does not change, reset, or remove 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.

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

This command creates a customer ID and customer context that associates information with a specific 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 enables the context to configure 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 is 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 reverts it to the default value.

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 explicitly withdraws 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 multisegment pseudowires. Paths are used by a 7210 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 first to delete the hop from the hop list. The no hop hop-index command does not result in an action, except for a warning message on the console indicating that the path is administratively up.

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

When the specified number is reached, no more attempts are made, and the spoke-SDP is put into the shutdown state. Use the no shutdown command to bring up the path after the retry limit is exceeded.

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

This command specifies a retry timer for the spoke-SDP. This is a configurable exponential back-off timer that determines the interval between retries to reestablish a spoke-SDP if it fails 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 a single S-PE address for the node, which is 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. Configuring this parameter 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 localprefixes cannot be configured on a T-PE. Also, 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 also 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 reboot of 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 the 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 behavior of not using the control word.

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 device to a particular service without having to specifically define far-end SAPs. Each SDP represents a method to reach a far-end 7210 SAS router.

The 7210 SAS supports only MPLS encapsulation as the method to reach the far-end router It does not support GRE or other encapsulation methods. A 7210 SAS router supports both signaled and non-signaled 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 the sdp-id parameter 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 run when all relevant parameters are defined and before the SDP can be used.

If the sdp-id parameter 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 enables the accounting policy context that can be applied to an SDP. An accounting policy must be defined before it can be associated with a 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 configures the hash label on VLL or VPLS services that are bound to an LDP or RSVP 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 egress data path appends the hash label at the bottom of the stack (BoS) and sets the S-bit to one (1).

Note: On 7210 SAS 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 a value of 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 the signal-capability options are enabled on the local PE.

If the hash-label command is enabled on the local PE with 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 node. These packets must be dropped. To resolve this situation, disable the signaling-capability option on the local node, which results in the insertion of the hash label by both the local and remote 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. 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 SAS for service traffic (for MPLS OAM traffic the MSB bit is set). That is, 7210 SAS devices do not set the MSB bit in the hash label value for service traffic; therefore, the user must ensure that both the ends are correctly configured to either process hash labels or disable them.

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

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 which 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 vctype 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 specifying no 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 which 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 the one signaled by the far-end PE router, 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 behavior.

This command enables BGP route tunnels available in the tunnel table to reach SDP far-end nodes. Use of BGP route tunnels are available only with MPLS-SDPs. 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 that are in use by services. For more information about this option, refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Routing Protocols Guide.

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

This command configures the system IP address of the far-end destination 7210 SAS-R6 and 7210 SAS-R12 router for the Service Distribution Point (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 7210 SAS device 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 specifies 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 enables 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. The user can configure one or two types of LSPs under the same SDP. Without this command, these commands are mutually exclusive.

The user can configure an RSVP LSP as a primary LSP type with an LDP LSP as a backup type. The user 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 linecard 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 linecard with the LDP LSP, if available. If not, 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 linecard 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 tunnel-down-damp-time command. For more information about the configure router ldp tunnel-down-damp-time command, refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S MPLS Guide.

If the user changes the value of the sdp-revert-time timer, 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 linecard with the BGP LSP if available, otherwise it brings down the SDP operationally.

Also, the following difference in behavior exists for the LDP/BGP SDP compared to that of an RSVP/LDP SDP. For a specific /32 prefix, only a single route exists in the routing table: the IGP route or the BGP route; therefore, either the LDP FEC or the BGP label route is active at any specific time. The impact of this is that the tunnel table needs to be reprogrammed each time a route is deactivated and the other is activated. Also, the SDP revert-time cannot be used because there is no situation where both LSP types are active for the same /32 prefix.

The no form of this command disables the mixed-LSP mode of operation. The user first has to 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 using 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 Multi-Protocol Label Switching (MPLS) Service Distribution Point (SDP). This command is implemented only on MPLS-type encapsulated SDPs.

In MPLS SDP configurations either one LSP can be specified.

The LSP must have already been created in the config>router>mpls context using 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 shutdown, causing the association with the SDP to be operationally down (the LSP is not used by the SDP).

If an exact match of lsp-name does not already exist as a defined LSP, an error message is generated. If the lsp-name exists and the LSP to IP address matches the SDP far-end IP address, the association is created.

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 association 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 only be changed while the administrative status of the SDP is down.

To modify the signaling configuration, the SDP must be administratively shut down, then the signaling parameter can be modified and reenabled.

This command configures the Maximum Transmission Unit (MTU) in bytes that the Service Distribution Point (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 like 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 default 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 uses the system default for the SDP type.

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

The no form of this command disables the use of the IS-IS segment routing LSP type for an MPLS SDP.

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

The no form of this command disables the use of the OSPF segment routing LSP type for an MPLS SDP.

This command enables the context to configure 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.

Table 11 describes the keepalive interpretation of SDP echo reply response conditions and the effect on the SDP ID operational status.

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 the hello-time seconds value to the default.

This command 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 is 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 to the default value.

This command configures the number of consecutive SDP keepalive failed request attempts or remote replies that can be missed after which the SDP is take operationally down. If the max-drop-count consecutive keepalive request messages cannot be sent or no replies are received, the SDP-ID is taken operationally down by the keepalive SDP monitoring.

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

This command configures the SDP monitoring keepalive request message length that is transmitted.

The message length should be equal to the SDP operating path MTU, as configured in the path-mtu command. If the default size is overridden, the actual size used is the smaller of the operational SDP-ID Path MTU and the size specified.

The no form of this command reverts the default value.

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

This command displays service customer information.

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

This command displays SDP information.

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

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 the Ethernet rings information.

This command displays PW routing information at this 7210 node.

This command displays information about PW templates.

This command displays the SDP used by a spoke-SDP FEC with a specified FEC129 Type 2 SAII.

This command displays the SDPs used by spoke-SDP FECs at this node.

This command displays switch-point information using TAII.

This command displays ETH-CFM information.

This command displays Ethernet tunnel information. Any data SAP missing a tag for a defined path has the EthTunTagMismatch flag generated. In the following example, SAP eth-tunnel-1:1 does not have the tag for path 2 configured. Therefore, it is operationally down with the reason indicated by the EthTunTagMismatch flag.

This command displays eth-cfm association information.

This command displays stack-table information. This stack-table is used to display the various management points MEPs and MIPs that are configured on the system. This can be service based. The options allow the user to display specific information. 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 Maintenance Intermediate Point (MIP) information.

This command displays connection profile information.