Services overview
This chapter provides an overview of the 7210 SAS-R6 and 7210 SAS-R12-series subscriber services, service model, and service entities. Additional information about the individual subscriber services is in subsequent chapters.
Introduction
A service is a globally unique entity that refers to a type of connectivity service for either Internet or VPN connectivity. Each service is uniquely identified by a service ID and an optional service within a service area. The 7210 SAS-series service model uses logical service entities to construct a service. In the service model, logical service entities provide a uniform, service-centric configuration, management, and billing model for service provisioning.
In the 7210 SAS-series routers, services can provide Layer 2/bridged service between a service access point (SAP) and another service access point (a SAP is where traffic enters and exits the service) on the same (local) router or another router (distributed). A distributed service spans more than one router.
Distributed services use service distribution points (SDPs) to direct traffic through a service tunnel to another 7210 SAS router, SR router, or other router that supports MPLS. SDPs are created on each participating router, specifying the origination address (the router participating in the service communication) and the destination address of another router. SDPs are then bound to a specific customer service. Without the binding process, the far-end router is not able to participate in the service (there is no service without associating an SDP with the service).
Service types
The 7210 SAS-R6 and 7210 SAS-R12 provide the following types of subscriber services, which are described in more detail in the referenced chapters:
-
Virtual Leased Line (VLL) Ethernet pipe (Epipe) services - a Layer 2 point-to-point VLL service for Ethernet frames. See Ethernet pipe (Epipe) services for more information about Epipe
Virtual Private LAN Service (VPLS) - a Layer 2 multipoint-to-multipoint VPN. See Virtual Private LAN Service for more information about VPLS
Internet Enhanced Service (IES) - a routed connectivity service used to provide IP services. See Internet Enhanced Service
Virtual Private Routed Network (VPRN) - a Layer 3 IP multipoint-to-multipoint VPN service as defined in RFC 2547bis. See Virtual Private Routed Network service
Service policies
Common to all 7210 SAS-series connectivity services are policies that are assigned to the service. Policies are defined at a global level, then applied to a service on the router. Policies are used to define 7210 SAS-series service enhancements. The types of policies that are common to all 7210 SAS-series connectivity services, and their functions, are:
SAP Quality of Service (QoS) policies allow for different classes of traffic within a service at SAP ingress and SAP egress.
QoS ingress and egress policies determine the QoS characteristics for a SAP. A QoS ingress policy applied to a SAP specifies the number of meters, meter characteristics (such as forwarding class, committed, and peak information rates, and so on) and the mapping of traffic to a forwarding class. A QoS egress policy defines the queue characteristics (such as CBS, CIR, PIR). A QoS policy must be created before it can be applied to a SAP. A single ingress and egress QoS policy can be associated with a SAP.
Filter policies allow selective blocking of traffic matching criteria from ingressing or egressing a SAP.
Filter policies, also referred to as access control lists (ACLs), control the traffic allowed in or out of a SAP, based on MAC or IP match criteria. Associating a filter policy with a SAP is optional. Filter policies are identified by a unique filter policy ID. A filter policy must be created before it can be applied to a SAP. A single ingress and single egress filter policy can be associated with a SAP.
Accounting policies define how to count the traffic usage for a service, for billing purposes.
The routers provide a comprehensive set of service-related counters. Accounting data can be collected on a per-service, per-forwarding class basis, which enables network operators to accurately measure network usage and bill each customer for each individual service, using any of a number of different billing models.
Nokia service model
In the Nokia service model, the service edge routers are deployed at the provider edge. Services are provisioned on the service routers and transported across an IP or IP/MPLS provider core network in encapsulation tunnels created using MPLS label switched paths (LSPs).
The service model uses logical service entities to construct a service. The logical service entities are designed to provide a uniform, service-centric configuration, management, and billing model for service provisioning. Some benefits of this service-centric design include:
Many services can be bound to a single customer.
QoS policies, filter policies, and accounting policies are applied to each service instead of correlating parameters and statistics from ports to customers to services.
Service provisioning uses logical entities to provision a service where additional properties can be configured for bandwidth provisioning, QoS, security filtering, and accounting/billing to the appropriate entity.
Service entities
The following sections describe the basic logical entities in the service model used to construct a service.
The following figure shows service entities for 7210 SAS devices configured in network mode.
Customers
The terms ‟customer” and ‟subscriber” are used synonymously. The most basic required entity is the customer ID value, which is assigned when the customer account is created. To provision a service, a customer ID must be associated with the service at the time of service creation.
SAPs
Each subscriber service type is configured with at least one SAP. A SAP identifies the customer interface point for a service on a 7210 SAS router. The SAP configuration requires that slot, MDA, and port information be specified. The slot, MDA, and port parameters must be configured before provisioning a service (see the Cards, MDAs, and Ports sections of the 7210 SAS-Mxp, R6, R12, S, Sx, T Interface Configuration Guide).
A SAP is a local entity to the router and is uniquely identified by:
physical Ethernet port
encapsulation type
encapsulation identifier (ID)
Depending on the encapsulation, a physical port can have more than one SAP associated with it. SAPs can only be created on ports designated as ‟access” in the physical port configuration.
The following figure shows SAPs used for customer service delivery, with SDP used for service transport on 7210 SAS devices that support MPLS uplinks (also known as network mode platforms).
SAP encapsulation types and identifiers
The encapsulation type is an access property of a service Ethernet port. The appropriate encapsulation type for the port depends on the requirements to support multiple services on a single port on the associated SAP and the capabilities of the downstream equipment connected to the port. For example, a port can be tagged with IEEE 802.1Q (referred to as dot1q) encapsulation in which each individual tag can be identified with a service. A SAP is created on a specific port by identifying the service with a specific encapsulation ID.
Ethernet encapsulations
The following lists encapsulation service options on Ethernet ports:
null
Supports a single service on the port. For example, where a single customer with a single service customer edge (CE) device is attached to the port. The encapsulation ID is always 0 (zero).
dot1q
Supports multiple services for one customer or services for multiple customers (Multiple SAPs on a single port). The encapsulation ID used to distinguish an individual service is the VLAN ID in the IEEE 802.1Q header. For example, the port is connected to a Ethernet switch with multiple downstream customers.
QinQ
The QinQ encapsulation type adds a IEEE 802.1Q tag to the 802.1Q tagged packets entering the network, to expand the VLAN space by tagging tagged packets, producing a double-tagged frame. The 7210 SAS-R6, and 7210 SAS-R12 support QinQ encapsulation for access ports in network mode.
The preceding figure shows multiple SAPs used for customer service delivery on the same port and belonging to the same service, along with SDP used for service transport on 7210 SAS devices that support MPLS uplinks (also known as network mode platforms). This is supported only in network mode.
Services and SAP encapsulations
The following table lists the service and SAP encapsulation information for Ethernet ports.
Port type | Encapsulation |
---|---|
Ethernet |
null |
Ethernet |
Dot1q |
Ethernet |
QinQ |
When a VPLS service with default QinQ SAPs on the ring ports is used for transit traffic in a ring deployment, users can use either G.8032 or M-VPLS with xSTP for ring protection. When using G.8032, the state of the default QinQ SAPs in the VPLS service can be managed using a separate G.8032 control instance.
Note:A G.8032 control instance cannot use default QinQ SAPs.
MVPLS with xSTP can be used for loop prevention. The default QinQ SAPs inherit the state from the associated MVPLS instance.
SAP configuration considerations
The following considerations apply to SAP configurations:
A SAP is a local entity and only locally unique to a specific device. The same SAP ID value can be used on another 7210 SAS-series device.
By default, no SAPs are configured on the node. All SAPs in subscriber services must be created.
At creation, the default administrative state for a SAP is set to administratively enabled.
When a SAP is deleted, all configuration parameters for the SAP are also deleted.
A SAP is owned by and associated with the service in which it is created in each router.
On a port with a dot1q encapsulation type, traffic for the SAP is identified based on a specific IEEE 802.1Q VLAN ID value. The VLAN ID is stripped off at SAP ingress and the appropriate VLAN ID added at SAP egress. As a result, VLAN IDs only have local significance, and configuring identical VLAN IDs for each SAP on a service is not required.
If a port is administratively shutdown, all SAPs on that port are operationally out of service.
QinQ access SAPs of type Q1.0 are supported only for IES, VPRN, and R-VPLS services. They are not supported for Layer 2 services.
A SAP cannot be deleted until it has been administratively disabled (shutdown).
Each SAP can have one each of the following policies assigned:
ingress filter policy
egress filter policy
ingress QoS policy
accounting policy
QinQ SAP configuration restrictions for 7210 SAS in network mode only
The following are the QinQ access SAP configuration guidelines for 7210 SAS in network mode only:
Tagged packets received on SAPs configured in a service in which a QinQ SAP is also in use are processed (not applicable when a QinQ SAP is not provisioned in a service).
When a QinQ SAP is configured in a service, the number of VLAN tags in the packets received on null SAP, dot1q SAP, and QinQ SAP configured in the same service should match the number of VLAN tags implied by the port encapsulation mode. Packets that do not match are dropped by the hardware. That is, packets received with more than two VLAN tags on a QinQ SAP are dropped, packets received with more than one VLAN tag on a dot1q SAP are dropped, and packets received with tags (even packets with a priority tag) on a null SAP are dropped. In this document, such packets are referred to as extra-tag packets.
When a QinQ SAP is configured in a service, the number of VLAN tags in the packets received on the VC/pseudowire of type VC-VLAN should be exactly one and packets received on the VC/pseudowire of type VC-Ether-should contain no tags (not even priority tags). If either case, packets that contain more VLAN tags than the number specified previously are dropped. In this document, such packets are referred to as extra-tag packets.
The system provides a limited number of counters for the extra-tag packets dropped on SAP ingress. These counters are intended for diagnostic use.
The following table describes the SAP types allowed in a service when QinQ SAP is in use.
Table 2. SAP types in a service when QinQ SAP is in use (network mode operation) SAP configured in the service SAPs not allowed for configuration in same service QinQ
Q.* SAP, Dot1q default SAP
Q.*
Q1.Q2
Dotq1 default SAP
Q1.Q2
A 0.* QinQ SAP configured in the service only accepts untagged or priority-tagged packets, regardless of whether a QinQ SAP is configured in the service.
The 7210 SAS supports a mechanism to transport QinQ packets in an Epipe with two or more tags, with some restrictions. For more information, see Ethernet pipe (Epipe) services.
SDPs
An SDP provides a logical way to direct traffic from one router to another through a unidirectional (one-way) service tunnel. The SDP terminates at the far-end router, which directs packets to the correct service egress SAPs on that router. A distributed service consists of a configuration with at least one SAP on a local node, one SAP on a remote node, and an SDP that binds the service to the service tunnel.
An SDP has the following characteristics:
An SDP is locally unique to a participating router. The same SDP ID can appear on other 7210 SAS-series routers.
An SDP uses the system IP address to identify the far-end edge router.
An SDP is not specific to any one service or any type of service. When an SDP is created, services are bound to the SDP. An SDP can also have more than one service type associated with it.
All services mapped to an SDP use the same transport encapsulation type defined for the SDP.
An SDP is a management entity. Even though the SDP configuration and the services carried within are independent, they are related objects. Operations on the SDP affect all the services associated with the SDP. For example, the operational and administrative state of an SDP controls the state of services bound to the SDP.
An SDP from the local router to a far-end router requires a return path SDP from the far-end router back to the local router. Each device must have an SDP defined for every remote router to which it needs to provide service. SDPs must be created first, before a distributed service can be configured.
SDP binding
To configure a distributed service from ALA-A to ALA-B, the SDP ID (1) must be specified in the service creation process to bind the service to the tunnel (the SDP). Otherwise, service traffic is not directed to a far-end point and the far-end devices cannot participate in the service (there is no service). To configure a distributed service from ALA-B to ALA-A, the SDP ID (5) must be specified.
The following figure shows MPLS service distribution point pointing from ALA-A to ALA-B.
Spoke and mesh SDPs
When an SDP is bound to a service, it is bound as either a spoke-SDP or a mesh SDP. The type of SDP indicates how flooded traffic is transmitted.
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” and not transmitted on the port it was received.
All mesh SDPs bound to a service are logically treated like a single bridge ‟port” for flooded traffic where flooded traffic received on any mesh SDP on the service is replicated to other ‟ports” (spoke-SDPs and SAPs) and not transmitted on any mesh SDPs.
SDP using BGP route tunnel
SDPs are enhanced to use BGP route tunnel to extend inter-AS support for Layer 2 and Layer 3 VPN services. An SDP can be configured to use the MPLS transport method. MPLS SDP support is enhanced to allow a BGP route tunnel to reach the far-end PE. A single method of tunneling is allowed per SDP (for example, LDP, RSVP-TE LSP, or BGP route tunnel). The BGP route tunnel method is excluded if multi-mode transport is enabled for an SDP.
A single method of tunneling is allowed per SDP (for example, LDP, RSVP-TE LSP or BGP route tunnel). BGP route tunnel method is excluded if multimode transport is enabled for an SDP.
For inter-AS far-end PE, the next-hop for the BGP route tunnel must be one of the local ASBRs. The LSP type selected to reach the local ASBR (BGP labeled route next-hop) must be configured under the BGP global context. LDP must be supported to provide a transport LSP to reach the BGP route tunnel next-hop.
Only BGP route labels can be used to transition from an ASBR to the next-hop ASBR. The global BGP route tunnel transport configuration option must be entered to select an LSP to reach the PE node from the ASBR node. On the last BGP segment, both BGP+LDP and LDP routes may be available to reach the far-end PE from the ASBR node. An LDP LSP must be preferred because of higher protocol priority. This leads to just one label, besides other labels in the stack, to identify the VC/VPN at far-end PE nodes.
SDP keepalives
SDP keepalives actively monitor the SDP operational state using periodic SDP ping echo request and echo reply messages. Nokia SDP ping is a part of the suite of service diagnostics built on a Nokia service-level OA&M protocol. When SDP ping is used in the SDP keepalive application, the SDP echo request and echo reply messages are a mechanism for exchanging far-end SDP status.
Configuring SDP keepalives on a specific SDP is optional. SDP keepalives for a particular SDP have the following configurable parameters:
admin up/admin down state
hello time
message length
max drop count
hold down time
SDP keepalive echo request messages are only sent when the SDP is completely configured and administratively up and SDP keepalives are administratively up. If the SDP is administratively down, keepalives for the SDP are disabled.
SDP keepalive echo request messages are sent out periodically, based on the configured Hello Time. An optional message length for the echo request can be configured. If max drop count echo request messages do not receive an echo reply, the SDP is immediately brought operationally down.
If a keepalive response is received that indicates an error condition, the SDP 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 is eligible to be put into the operationally up state. If no other condition prevents the operational change, the SDP enters the operationally up state.
For information about configuring keepalive parameters, see Configuring an SDP.
SDP administrative groups
This feature provides the support of SDP administrative groups, referred to as SDP admin groups. SDP admin groups provide a way for services using a PW template to automatically include or exclude specific provisioned SDPs. SDPs sharing a specific characteristic or attribute can be made members of the same admin group.
The user first creates the admin groups that are to be used by SDPs on this node:
config>service>sdp-group>group-name group-name value group-value create
A maximum of 32 admin groups can be created. The no option is only allowed if the group name is not referenced in a PW template or SDP.
The group value ranges from zero (0) to 31. It is uniquely associated with the group name at creation time. If the user attempts to configure another group name for a group value that is already assigned to an existing group name, the SDP admin group creation is failed. The same happens if the user attempts to configure an SDP admin group with a new name but associates it to a group value already assigned to an existing group name.
Next, the user configures the SDP membership in admin groups:
config>service>sdp>sdp-group group-name
The user can enter a maximum of one (1) admin group name per command execution. The user can execute the command multiple times to add membership to more than one admin group. The admin group name must have been configured or the command fails. Admin groups are supported on an SDP of type MPLS (BGP/RSVP/LDP). They are also supported on an SDP with the mixed-lsp-mode option enabled.
The user then selects which admin groups to include or exclude in a specific PW template:
config>service>pw-template>sdp-include group-name
config>service>pw-template>sdp-exclude group-name
The admin group name must have been configured or the command is failed. The user can execute the command multiple times to include or exclude more than one admin group. The sdp-include and sdp-exclude commands can only be used with the use-provisioned-sdp option. If the same group name is included and excluded within the same PW template, only the exclude option is enforced.
Any changes made to the admin group sdp-include and sdp-exclude constraints are reflected only in existing spoke-SDPs after the following command has been executed:
tools>perform>service>eval-pw-template>allow-service-impact
When the service is bound to the PW template, the SDP selection rules enforce the admin group constraints specified in the sdp-include and sdp-excludecommands.
config>service>vpls>bgp>pw-template-binding policy-id
config>service>epipe>spoke-sdp-fec>pw-template-bind policy-id
The group value is used to uniquely identify an SDP admin group throughout the network in the 5620 SAM. The node sends both the group name and value to 5620 SAM, or other SNMP device, at the creation of the SDP admin group. In all other operations in the node, such as adding an SDP to an admin group or including/excluding an SDP admin group in a service context, only the group name is sent to the 5620 SAM or the SNMP device.
SDP admin groups can be enabled on all 7210 services that make use of the PW template (that is, BGP-AD VPLS service, BGP-VPLS service, BGP-VPWS and FEC129 VLL service).
Mixed-LSP mode of operation
The mixed-LSP mode of operation allows for a maximum of two LSP types to be configured within an SDP; a primary LSP type and a backup LSP type. An RSVP primary LSP type can be backed up by an LDP LSP type.
An LDP LSP can be configured as a primary LSP type, which can then be backed up by a BGP LSP type.
At any specific time, the service manager programs only one type of LSP in the line card, which activates it to forward service packets according to the following priority order:
RSVP LSP type
One RSVP LSP can be configured per SDP. This is the highest priority LSP type.
LDP LSP type
One LDP FEC is used per SDP. The 7210 SAS does not support LDP ECMP.
BGP LSP type
One RFC 3107-labeled BGP prefix programmed by the service manager.
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 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 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, then the SDP reverts to the highest priority LSP type only if the currently active LSP failed.
LDP uses a tunnel down damp timer which is set to three seconds by default. When the LDP LSP fails, the SDP will revert 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, see the 7210 SAS-Mxp, R6, R12, S, Sx, T MPLS Guide.
If the value of the revert-time timer is changed, it takes effect only at the next use of the timer. Any timer which 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.
The following are differences in behavior of 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.
The SDP revert-time cannot be used, because there is no situation where both LSP types are active for the same /32 prefix.
G.8032 Ethernet ring protection switching
Ethernet ring protection switching (Eth-ring) provides ITU-T G.8032 specification compliance to achieve resiliency for Ethernet Layer 2 networks. Similar to G.8031 linear protection (also called Automatic Protection Switching (APS)), G.8032 Eth-ring is implemented on Ethernet OAM and often referred to as Ring Automatic Protection Switching (R-APS).
Eth-rings are supported on VPLS SAPs. VPLS services supporting Rings SAPs can connect to other rings and Ethernet service using VPLS, and R-VPLS SAPs. The Eth-ring service enables rings for core network or access network resiliency. A single point of interconnection to other services is supported. The Eth-ring service is a VLAN service providing protection for ring topologies and the ability to interact with other protection mechanisms for overall service protection. This ensures failures detected by Eth-ring only result in R-APS switchover when the lower layer cannot recover, and that higher layers are isolated from the failure.
Rings are preferred in data networks where the native connectivity is laid out in a ring or there is a requirement for simple resilient LAN services. Because of the symmetry and the simple topology, rings are viewed a good solution for access and core networks where resilient LANS are required. The Nokia implementation of G.8032 Eth-ring can be used for interconnecting access rings and to provide traffic engineered backbone rings. The 7210 SAS implementation of G.8032 Eth-ring supports dual interconnected rings with sub-rings.
Eth-rings use one VID per control per ring instance and use one (typically) or multiple VIDs for data instances per control instance. A dedicated control VLAN (ERP VLAN) is used to run the protocol on the control VID. G.8032 controls the active state for the data VLANs (ring data instances) associated with a control instance. Multiple control instances allow logically separate rings on the same topology. The Nokia implementation supports dot1q, and QinQ encapsulation for data ring instances. The control channel supports dot1q and QinQ encapsulation.
SAP and service scaling with high SAP scale mode
In Layer 2 access networks that are used to backhaul service traffic from business services, mobile backhaul, and residential services, the 7210 SAS-R6 and 7210 SAS-R12 act as a Layer 2 carrier Ethernet switching platform with VLAN-based Layer 2 uplinks. To perform this role, the 7210 SAS-R6 and 7210 SAS-R12 must support a mode with higher SAP and service scaling. To do so, the 7210 SAS-R6 and 7210 SAS-R12 use the SAP scale mode and port-based access ingress policies.
The following figure shows the use of Layer 2 uplinks in a Layer 2 access network.
The SAP scale mode is configured using the configure>system>global-res-profile>sap-scale-mode {high | low} command. By default, the low option is configured for low SAP scale mode, which provides backward compatibility. The user can configure the high option to use high SAP scale mode, which allows the configuration of a higher number of services and SAPs. Before changing the sap-scale-mode value, the user must perform the following tasks:
Remove all service and SAP configurations.
Change the value of sap-scale-mode and enable per-port egress queuing using the configure>system>global-res-profile>qos>port-scheduler-mode command.
Reboot the node.
Reconfigure all SAPs and services as required.
In high SAP scale mode, the system supports higher SAP and service scaling for Epipe/VLL and VPLS services only. SAP and service scaling for IES, VPRN, and R-VPLS services remain unchanged.
QoS policies support port-based access ingress policies on access ports to facilitate the use of access ports as Layer 2 uplinks. With the use of ports as Layer 2 uplinks, the user can apply a single port-based access ingress policy at ingress of an access port, instead of using per-SAP ingress policies. This allows a single policy definition to be used to classify and rate-limit all traffic received over access ports used as Layer 2 uplinks (similar to a network port-based policy applied to network ports used as uplinks) instead of using per SAP ingress policies. Resources must be allocated using the configure>system>resource-profile command to use access ingress QoS policies on an access port.
In addition, only the following QoS policies can be used in the high SAP scale mode to achieve a higher scale:
access port-based egress queuing and shaping on all ports, including service delivery ports and uplinks
access port-based ingress classification and policing on uplinks
Epipe and VPLS SAPs using access port ingress QoS policies (instead of per-SAP ingress policies) on service delivery ports for higher SAP scale
IES and VPRN SAPs using table-based classification or CAM-based classification
R-VPLS SAPs using CAM-based classification and policing
The following SAP configuration restrictions apply to the high SAP scale mode; see SAPs for additional SAP configuration guidelines:
If an R-VPLS Q1.* SAP is configured, SAPs (Q1.Q2 SAP) with a matching Q1 tag cannot be configured in other VPLS, Epipe, IES, and VPRN services on the same port.
If a VPLS Q1.* SAP enabled with DHCP snooping is configured, SAPs (Q1.Q2 SAP) with a matching Q1 tag cannot be configured in other VPLS, Epipe, IES, and VPRN services on the same port. They can use other values for the Q1 tag. The reverse is also true.
The dot1p default SAP cannot be configured in R-VPLS services; it is only supported in Epipe, VPLS, IES, and VPRN services.
Guidelines for configuring high SAP scale mode
Perform the following steps to change the sap-scale-mode low to the sap-scale-mode high configuration:
Delete all SAPs.
Configure the config>system>global-res-profile>qos>port-scheduler-mode command.
Configure the sap-scale-mode command to use the high option.
Save the configuration and reboot the node.
Guidelines for configuring low SAP scale mode
Perform the following steps to change the sap-scale-mode high to the sap-scale-mode low configuration:
-
Delete all SAPs.
If the access ingress QoS policy has attachments, reset the policy.
If the access-ingress-qos-mode command is set to port-mode, configure the command to use the sap-mode option.
Configure the sap-scale-mode command to use the low option.
Save the configuration and reboot the node.
Overview of G.8032 operation
R-APS messages that carry the G.8032 protocol are sent on a dedicated protocol VLAN called ERP VLAN (or ring control instance). In a revertive case, G.8032 protocol ensures that one Ring Protection Link (RPL) owner blocks the RPL link. R-APS messages are periodically sent around in both directions to inform other nodes in the ring about the blocked port in the RPL owner node. In non-revertive mode, any link may be the RPL link.Y.1731 Ethernet OAM CC is the basis of the R-APS messages.
Y.1731 CC messages are typically used by nodes in the ring to monitor the health of each link in the ring in both directions. However, CC messages are not mandatory. Other link layer mechanisms could be considered; for example, LOS (Loss of Signal) when the nodes are directly connected.
Initially, each Ring Node blocks one of its links and notifies other nodes in the ring about the blocked link. When a ring node in the ring learns that another link is blocked, the node unblocks its blocked link, possibly causing FDB flush in all links of the ring for the affected service VLANs, controlled by the ring control instance. This procedure results in unblocking all links except the one link and the ring normal (or idle) state is reached.
In revertive mode, the RPL link is the link that is blocked when all links are operable after the revert time. In non-revertive mode, the RPL link is no different from other ring links. Revertive mode provides predictability, particularly when there are multiple ring instances, and the operator can control which links are blocked on the different instances. Each time that there is a topology change that affects Reachability, the nodes may flush the FDB and MAC learning takes place for the affected service VLANs, allowing forwarding of packets to continue. The following figure shows this initial operational state.
When a ring failure occurs, a node detecting the failure (enabled by Y.1731 OAM CC monitoring) sends R-APS message in both directions. This allows the nodes at both ends of the failed link to block forwarding to the failed link, preventing it from becoming active. In revertive mode, the RPL owner then unblocks the previously blocked RPL and triggers an FDB flush for all nodes for the affected service instances. The ring is now in protecting state and full ring connectivity is restored. MAC learning takes place to allow Layer 2 packet forwarding on a ring. The following figure shows the failed link scenario.
When the failed link recovers, the nodes that blocked the link again send the R-APS messages indicating no failure this time. This causes the RPL owner to block the RPL link and indicate the blocked RPL link to the ring in R-APS message, when received by the nodes at the recovered link, they unblock that link and restore connectivity (again all nodes in the ring perform an FDB flush and MAC learning takes place). The ring is back in the normal (or idle) state.
Within each path, Y.1731 Maintenance Entity Group (MEG) Endpoints (MEPs) are used to exchange R-APS specific information (specifically to coordinate switchovers) as well as optionally fast Continuity Check Messages (CCMs), providing an inherent failure detection mechanism as part of the protocol. Failure detection of a ring path by one of the mechanisms activates the protection links. Upon failure, reconvergence times are dependent on the failure detection mechanisms.
In the case of Y.1731, the CCM transmit interval determines the response time. The 7210 SAS device supports 100 ms message timers that allow for quicker restoration times. Alternatively, 802.3ah (Ethernet in the First Mile) or LOS can trigger a protection switch where appropriate. In the case of direct connectivity between the nodes, there is no need to use Ethernet CC messaging for liveliness detection.
Revertive and non-revertive behaviors are supported. The RPL is configured and Eth-rings can be configured to revert to the RPL upon recovery.
G.8032 supports multiple data channels (VIDs) or instances per ring control instance (R-APS tag). G.8032 also supports multiple control instances such that each instance can support RPLs on different links, providing for a load balancing capability. However, when services have been assigned to one instance, the rest of the services that need to be interconnected with those services must be on the same instance. That is, each data instance is a separate data VLAN on the same physical topology. When there is any one link failure or any one node failure in the ring, G.8032 protocols are capable of restoring traffic between all remaining nodes in these data instances.
There is no limit on the number of control channels on a port.
Ethernet R-APS can be configured on any port configured for access mode using dot1q, QinQ encapsulation, enabling support for Ethernet R-APS protected services on the service edge toward the customer site, or within the Ethernet backbone. ELINE and ELAN services can be provided Ethernet R-APS protection and, although the Ethernet ring providing the protection uses a ring for protection, the services are configured independent of the ring properties. The intent of this is to cause minimum disruption to the service during Ethernet R-APS failure detection and recovery.
In the 7210 SAS implementation, the Ethernet ring is built from a VPLS service on each node with VPLS SAPs that provides ring path with SAPs. As a result, most of the VPLS SAP features are available on Ethernet rings, if needed. This results in a fairly feature-rich ring service.
The control tag defined under each eth-ring is used for encapsulating and forwarding the CCMs and the G.8032 messages used for the protection function. If a failure of a link or node affects an active Ethernet ring segment, the services fail to receive the CC messages exchanged on that segment or receive a fault indication from the Link Layer OAM module.
For failure detection using CCMs, three CC messages plus a configurable hold-off timer must be missed for a fault to be declared on the associated path. The latter mechanism is required to accommodate the existence of an additional 50 ms resiliency mechanism in the optical layer. After it receives the fault indication, the protection module declares the associated ring link down and the G.8032 state machine sends the appropriate messages to open the RPL and flush the learned addresses.
Flushing is triggered by the G.8032 state machine and the 7210 SAS implementation allows flooding of traffic during the flushing interval to expedite traffic recovery.
Ethernet ring sub-rings
Ethernet sub-rings offer a dual redundant way to interconnect rings. The 7210 SAS supports sub-rings connected to major rings, and a sub-ring connected to a VPLS (LDP based) for access ring support in VPLS networks. Major ring and sub-ring scenario shows a major ring and sub-ring scenario, and 0 to 4 G.8032 sub-ring shows a G.8032 sub-ring. In this scenario, any link can fail in either ring (ERP1 or ERP2) and each ring is protected. Also, the sub-ring (ERP2) relies on the major ring (ERP1) as part of its protection for the traffic from C and D. The nodes C and D are configured as interconnection nodes.
Sub-rings and major rings run similar state machines for the ring logic; however, there are some differences. When sub-rings protect a link, the flush messages are propagated to the major ring. (A special configuration allows control of this option on the 7210 SAS.) When major rings change topology, the flush is propagated around the major ring and does not continue to any sub-rings. The reason for this is that major rings are completely connected but sub-rings are dependent on another ring or network for full connectivity. The topology changes need to be propagated to the other ring or network usually. Sub-rings offer the same capabilities as major rings in terms of control and data so that all link resources may be used.
Virtual and non-virtual channel
The following example shows a sub-ring using virtual-link configuration output on Node C, interconnecting node.
Sub-ring using virtual-link configuration output on Node C, interconnecting node
eth-ring 2
description "Ethernet Sub Ring on Ring 1"
interconnect ring-id 1 // Link to Major Ring 1
propagate-topology-change
exit
exit
path a 1/1/3 raps-tag 100 // Ring control uses VID 100
eth-cfm
mep 9 domain 1 association 4
ccm-enable
control-mep
no shutdown
exit
exit
no shutdown
exit
no shutdown
exit
sub-ring non-virtual-link // Not using a virtual link
# Control Channel for the Major Ring ERP1 illustrates that Major ring
# control is still separate from Sub-ring control
vpls 10 customer 1 create
description "Control VID 10 for Ring 1 Major Ring"
stp shutdown
sap 1/1/1:10 eth-ring 1 create
stp shutdown
exit
sap 1/1/4:10 eth-ring 1 create
stp shutdown
exit
no shutdown
exit
# Data configuration for the Sub-Ring
vpls 11 customer 1 create
description "Data on VID 11 for Ring 1"
stp shutdown
sap 1/1/1:11 eth-ring 1 create // VID 11 used for ring
stp shutdown
exit
sap 1/1/4:11 eth-ring 1 create
stp shutdown
exit
sap 1/1/3:11 eth-ring 2 create // Sub-ring data
stp shutdown
exit
sap 3/2/1:1 create
description "Local Data SAP"
stp shutdown
no shutdown
exit
# Control Channel for the Sub-Ring using a virtual link. This is
# a data channel as far as Ring 1 configuration. Other Ring 1
# nodes also need this VID to be configured.
vpls 100 customer 1 create
description "Control VID 100 for Ring 2 Interconnection"
split-horizon-group "s1" create //Ring Split horizon Group
exit
stp shutdown
sap 1/1/1:100 split-horizon-group "s1" eth-ring 1 create
stp shutdown
exit
sap 1/1/4:100 split-horizon-group "s1" eth-ring 1 create
stp shutdown
exit
sap 1/1/3:100 eth-ring 2 create
stp shutdown
exit
no shutdown
exit
Ethernet ring sub-ring using non-virtual link
The following figure shows 0 to 6 homed to VPLS.
Sub-ring using non-virtual link configuration output on PE1, interconnecting node
eth-ring 1
description "Ethernet Ring 1"
guard-time 20
no revert-time
rpl-node nbr
sub-ring non-virtual-link
interconnect vpls // VPLS is interconnection type
propagate-topology-change
exit
exit
path a 1/1/3 raps-tag 1.1
description "Ethernet Ring : 1 Path on LAG"
eth-cfm
mep 8 domain 1 association 8
ccm-enable
control-mep
no shutdown
exit
exit
no shutdown
exit
no shutdown
exit
Sub-ring nodes configured with sub-ring non-virtual link option within non-virtual link sub-ring
All the sub ring nodes part of a sub-ring with non-virtual link should be configured with the ‟sub-ring non-virtual-link” option.
eth-ring 1
sub-ring non-virtual-link
exit
path a 1/1/1 raps-tag 1.1
eth-cfm
mep 5 domain 1 association 4
ccm-enable
control-mep
no shutdown
exit
exit
no shutdown
exit
path b 1/1/2 raps-tag 1.1
eth-cfm
mep 6 domain 1 association 3
ccm-enable
control-mep
no shutdown
exit
exit
no shutdown
exit
no shutdown
exit
# Control Channel for Sub-Ring using non-virtual-link on interconnecting node:
vpls 1 customer 1 create
description "Ring 1 Control termination"
stp shutdown
sap 1/1/3:1.1 eth-ring 1 create //path a control
stp shutdown
exit
no shutdown
exit
# Configuration for the ring data into the VPLS Service
vpls 5 customer 1 create
description "VPLS Service at PE1"
stp
no shutdown
exit
sap 1/1/3:2.2 eth-ring 1 create
stp shutdown
exit
sap 1/1/5:1 create
exit
mesh-sdp 5001:5 create //sample LDP MPLS LSPs
exit
mesh-sdp 5005:5 create
exit
mesh-sdp 5006:5 create
exit
no shutdown
exit
# Control Channel for Sub-Ring using non-virtual-link on sub-Ring nodes:
vpls 1 customer 1 create
stp
shutdown
exit
sap 1/1/1:1.1 eth-ring 1 create
stp
shutdown
exit
exit
sap 1/1/2:1.1 eth-ring 1 create
stp
shutdown
exit
exit
no shutdown
exit
Sample sub-ring using non-virtual link configuration output homed to a major ring
eth-ring 1
description "Ethernet Ring 1"
guard-time 20
no revert-time
rpl-node nbr
sub-ring non-virtual-link
interconnect ring-id <major ring index>
propagate-topology-change
exit
exit
path a 1/1/3 raps-tag 1.1
description "Ethernet Ring : 1 Path on LAG"
eth-cfm
mep 8 domain 1 association 8
ccm-enable
control-mep
no shutdown
exit
exit
no shutdown
exit
no shutdown
exit
Support for hardware-based 100ms CCM timers for G.8032 MEPs
On the 7210 SAS-R6 and 7210 SAS-R12, the user must reserve a VLAN-ID for use with only G.8032 MEPs which uses the hardware for CCM processing. No data services or control SAPs can use this VLAN-ID. The CLI command description used to reserve the VLAN-ID is available in the 7210 SAS-Mxp, R6, R12, S, Sx, T Interface Configuration Guide.
When using hardware CCMs, a limited amount of control instances is supported per port. Multiple data services/instances can be associated with each of these control instances.
Configuration output with control-sap-tag command
The following example shows configuration output with the control-sap-tag command.
Configure eth-ring 1
description "Ethernet Ring 1"
guard-time 20
revert-time 60
rpl-node owner
path a 1/1/8 raps-tag 1
description "Ethernet Ring : 1 Path : pathA"
rpl-end
eth-cfm
mep 1 domain 1 association 1
ccm-enable
control-mep
control-sap-tag 513
no shutdown
exit
exit
no shutdown
exit
path b 1/1/7 raps-tag 1
description "Ethernet Ring : 1 Path : pathB"
eth-cfm
mep 2 domain 1 association 2
ccm-enable
control-mep
control-sap-tag 513
no shutdown
exit
exit
no shutdown
exit
no shutdown
exit
Configuration guidelines for 7210 SAS-R6 and 7210 SAS-R12
The user needs to reserve VLANs using the system resource-profile g8032-control-sap-tags command. A maximum of up to 4 VLANs need to be reserved per line card. These VLANs are used to internally identify G.8032 CCM messages and R-APS messages. These VLANs cannot be used on any of the ports of the IMM, that is, SAPs cannot be configured with VLAN tag value matching any of the configured VLAN tags using this command.
LAG support
The 7210 SAS does not support G.8032 Ethernet rings on LAGs.
OAM considerations
Ethernet CFM can be enabled on each individual path under an Ethernet ring. Only Down MEPs can be configured on each of them and CCM sessions can be enabled to monitor the liveliness of the path using an interval of 100 ms. Different CCM intervals can be supported on path A and path B in an Ethernet ring. CFM is optional if hardware supports LOS, for example.
Service Down MEPs cannot be configured on the same port as the G.8032 ring ports.
QoS considerations
When Ethernet ring is configured on two ports located on different IOMs, the SAP queues and virtual schedulers are created with the actual parameters on each IOM.
Ethernet ring CC messages transmitted over the SAP queues using the default egress QoS policy use NC (network class) as a forwarding class. If user traffic is assigned to the NC forwarding class, it competes for the same bandwidth resources with the Ethernet CCMs. Because CCM loss could lead to unnecessary switching of the Ethernet ring, congestion of the queues associated with the NC traffic should be avoided. The operator must configure different QoS policies to avoid congestion for the CCM forwarding class by controlling the amount of traffic assigned into the corresponding queue.
More information about the Ethernet ring applicability in the services solution, see the respective Layer 2 sections of the 7210 SAS-R6, R12 Services Guide.
Support service and solution combinations
Ethernet rings are a supported Layer 2 service. The following considerations apply:
Only ports in access mode can be configured as eth-ring paths.
Dot1q and QinQ ports are supported as eth-ring path members.
A mix of regular and multiple eth-ring SAPs and PWs can be configured in the same services.
Configuration guidelines for G.8032
The following are the configuration guidelines for G.8032:
Service level MEPs are not available on all SAPs tied to an Eth-ring instance on a port.
On 7210 SAS-R6 and 7210 SAS-R12 with IMMv2 (that is, IMM-sas-r-b), to improve the service failover time because of failures in the ring path, fast flood is enabled by default only for VPLS services (and not for R-VPLS services). On a failure detection in one of the paths of the eth-ring, along with MAC flush the system starts to flood the traffic onto the available path. No explicit user configuration is needed for this and it does not need resources to be allocated from the ingress internal TCAM pool. When G8032 is enabled for R-VPLS services to enable fast-flood, user needs to explicitly assign resources from the ‛sf-ingress-internal-tcam’ pool using the global system resource profile commands.
G.8032 instances cannot be configured over a LAG.
On 7210 SAS-R6 and 7210 SAS-R12, user can enable G.8032 fast-flood by allocating resources to this feature using the command configure>system>global-system-profile>sf-ingress-internal-tcam>g8032-fast-flood.
Service creation process overview
The following figure shows the overall process to provision core and subscriber services.
Deploying and provisioning services
The service model provides a logical and uniform way of constructing connectivity services. The basic steps for deploying and provisioning services can be broken down into three phases:
core network construction
service administration
service provisioning
Phase 1: core network construction
Before the services are provisioned, the following tasks should be completed:
Build the IP or IP/MPLS core network.
Configure routing protocols.
Configure MPLS LSPs (if MPLS is used).
Phase 2: service administration
Perform preliminary policy configurations to control traffic flow, operator access, and to manage fault conditions and alarm messages. The following tasks should be completed:
Configure group and user access privileges.
Build templates for QoS, filter, and accounting policies needed to support the core services.
Phase 3: service provisioning
For service provisioning, the following tasks should be completed:
Provision customer account information.
If necessary, build any customer-specific QoS, filter, or accounting policies.
Provision the customer services on the service edge routers by defining SAPs, and binding policies to the SAPs.
Configuration notes
This section describes service configuration restrictions.
General
Service provisioning tasks can be logically separated into two main functional areas, core tasks and subscriber tasks, and are typically performed before provisioning a subscriber service.
Core tasks include the following:
Create customer accounts.
Create template QoS, filter, scheduler, and accounting policies.
Subscriber services tasks include the following:
Create Epipe and VPLS services.
Create a VPRN service (supported only when operating in network mode).
Bind SDPs.
Configure interfaces (where required) and SAPs.
Create exclusive QoS and filter policies.
Configuring global service entities with CLI
This section provides information to create subscriber (customer) accounts using the command line interface.
Service model entities
The Nokia service model uses logical entities to construct a service. The service model contains four main entities to configure a service.
Basic configuration
The most basic service configuration must have the following:
customer ID
service type
service ID
SAP identifying a port and encapsulation value
associated SDP for distributed services in the network mode
Epipe service configuration output showing SDP and Epipe service entities
The following is a sample Epipe service configuration output showing the SDP and Epipe service entities. SDP ID 1 was created with the far-end node 10.20.1.2. Epipe ID 101 was created for customer ID 1, which uses the SDP ID 1.
A:ALA-7210>config>service#
------------------------------------------
...
sdp 1 mpls create
description "Default sdp description"
far-end 10.20.1.2
lsp "lsp_1_to_B"
signaling tldp
no vlan-vc-etype
path-mtu 9194
no adv-mtu-override
keep-alive
shutdown
hello-time 10
hold-down-time 10
max-drop-count 3
timeout 5
no message-length
exit
no collect-stats
no accounting-policy
no shutdown
exit
...
epipe 101 customer 1 vpn 101 create
description "Default epipe description for service id 101"
service-mtu 9194
sap lag-2:101 create
description "Default sap description for service id 101"
no tod-suite
dot1ag
exit
ingress
qos 1
no filter
exit
spoke-sdp 101:101 vc-type ether create
no vlan-vc-tag
ingress
no vc-label
exit
egress
no vc-label
exit
no control-word
no
dot1ag
mep 1 domain 5 association 101 direction down
ccm-enable
no ccm-ltm-priority
low-priority-defect remErrXcon
no mac-address
no shutdown
exit
mep 1 domain 6 association 101 direction down
ccm-enable
no ccm-ltm-priority
low-priority-defect remErrXcon
no mac-address
no shutdown
exit
exit
no collect-stats
no accounting-policy
no precedence
no shutdown
exit
no shutdown
...
------------------------------------------
A:ALA-7210>config>service#
Common configuration tasks
This section provides a brief overview of the tasks that must be performed to configure a customer account.
Configuring customer accounts
The most basic customer account must have a customer ID. Optional parameters include:
description
contact name
telephone number
Customer information
Use the following syntax to create and input customer information.
config>service# customer customer-id create
contact contact-information
description description-string
phone phone-number
Basic customer account configuration output
A:ALA-12>config>service# info
-------------------------------------------
...
customer 5 create
description "Nokia Customer"
contact "Technical Support"
phone "650 555-5100"
exit
...
-------------------------------------------
A:A:ALA-12>config>service#
Configuring an SDP
The most basic SDP must have the following:
locally unique SDP identification (ID) number
system IP address of the far-end routers
SDP encapsulation type, MPLS
SDP configuration tasks
This section provides a brief overview of the tasks that must be performed to configure SDPs, and provides the CLI commands.
Consider the following SDP characteristics:
-
SDPs can be created as MPLS.
-
Each distributed service must have an SDP defined for every remote router to provide VLL, VPLS, and VPRN services.
-
A distributed service must be bound to an SDP. By default, no SDP is associated with a service. When an SDP is created, services can be associated with that SDP.
-
An SDP is not specific or exclusive to any one service or any type of service. An SDP can have more than one service bound to it.
-
The SDP IP address must be a 7210 SAS-series system IP address.
-
To configure an MPLS SDP, LSPs must be configured first, then the LSP-to-SDP association must be explicitly created.
-
In the SDP configuration, automatic ingress and egress labeling (targeted LDP) is enabled by default. Ingress and egress VC labels are signaled over a TLDP connection between two 7210 SAS-series routers.
If signaling is disabled for an SDP, services using that SDP must configure ingress and egress VC labels manually.
To configure a basic SDP, perform the following steps:
-
Specify an originating node.
-
Create an SDP ID.
-
Specify an encapsulation type.
-
Specify a far-end node.
Configuring an SDP
Use the following syntax to create an SDP and select an encapsulation type. Only MPLS encapsulation is supported.
When you specify the far-end IP address, you are creating the tunnel; you are creating the path from point A to point B. When you configure a distributed service, you must identify an SDP ID. Use the show service sdp command to display the qualifying SDPs.
When specifying MPLS SDP parameters, you must specify an LSP. If an LSP name is specified, RSVP is used for dynamic signaling within the LSP.
LSPs are configured in the config>router>mpls context. See the 7210 SAS-Mxp, R6, R12, S, Sx, T MPLS Guide for configuration and command information.
Use the following syntax to create an MPLS SDP.
config>service>sdp sdp-id [mpls] create
adv-mtu-override
description description-string
far-end ip-address
keep-alive
hello-time seconds
hold-down-time seconds
max-drop-count count
message-length octets
timeout timeout
no shutdown
lsp lsp-name [lsp-name] (only for MPLS SDPs)
path-mtu octets
signaling {off | tldp}
no shutdown
LSP-signaled MPLS SDP configuration output
The following example shows LSP-signaled MPLS SDP configuration output.
A:ALA-12>config>service# info
-------------------------------------------
...
sdp 8 mpls create
description "MPLS-10.10.10.104"
far-end 10.10.10.104
lsp "to-104"
keep-alive
mixed-lsp-mode
revert-time 1
shutdown
exit
no shutdown
exit
...
-----------------------------------------
A:ALA-12>config>service#
Configuring a mixed-LSP SDP
Use the following command to configure an SDP with mixed LSP mode of operation:
config>service>sdp mpls>mixed-lsp-mode
The primary is backed up by the secondary. Two combinations are possible: the primary of RSVP is backed up by LDP and the primary of LDP is backed up by 3107 BGP.
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.
The user can also configure how long the service manager must wait before it reverts the SDP to a higher priority LSP type, when it becomes available, by using the following command:
config>service>sdp mpls>mixed-lsp-mode>revert-time revert-time
An infinite value for the timer dictates that the SDP must never revert to another higher priority LSP type unless the currently active LSP type is down:
config>service>sdp mpls>mixed-lsp-mode>revert-time infinite
The BGP LSP type is allowed. The bgp-tunnel command can be configured under the SDP with the lsp or ldp commands.
Ethernet Connectivity Fault Management
Ethernet Connectivity Fault Management (ETH-CFM) is defined in two similar standards: IEEE 802.1ag and ITU-T Y.1731. Both standards specify protocols, procedures, and managed objects to support transport fault management, including discovery and verification of the path, detection and isolation of a connectivity fault for each Ethernet service instance.
The configuration is split into multiple CLI contexts. The base ETH-CFM configuration defines the different management constructs and administrative elements. This configuration is performed in the eth-cfm context. The individual management points are configured within the specific service contexts in which they are applied (port, SAP, and so on).
See the 7210 SAS-R6, R12 Services Guide for detailed information about the basic service-applicable material to build the service-specific management points, MEPs, and MIPs. The different service types support a subset of the features from the complete ETH-CFM suite.
ETH-CC used for continuity is available to all MEPs configured within a service. The 7210 SAS devices support Down MEPs and Up MEPs, though the support is not available on all platforms. See the 7210 SAS-Mxp, R6, R12, S, Sx, T OAM and Diagnostics Guide for more information about platform support.
The troubleshooting tools ETH-LBM, ETH-LBR, LTM ETH-TST, and LTR ETH-TST, defined by the IEEE 802.1ag specification and the ITU-T Y.1731 recommendation, are applicable to all MEPs (and MIPs where appropriate). The advanced notification function, Alarm Indication Signal (AIS), defined by the ITU-T Y.1731, is supported on Epipe services.
The advanced performance functions, 1DM, DMM/DMR, and SLM/SLR, are supported on all service MEPs.
See the 7210 SAS-Mxp, R6, R12, S, Sx, T OAM and Diagnostics Guide for more information about the individual features and functions that are supported and configuration guidelines applicable to CFM entities on the 7210 SAS.
The following table lists ETH-CFM acronym expansions.
Acronym | Expansion |
---|---|
1DM |
One-way Delay Measurement (Y.1731) |
AIS |
Alarm Indication Signal |
BNM |
Bandwidth Notification Message (Y.1731 sub OpCode of GMN) |
CCM |
Continuity Check Message |
CFM |
Connectivity Fault Management |
DMM |
Delay Measurement Message (Y.1731) |
DMR |
Delay Measurement Reply (Y.1731) |
GMN |
Generic Message Notification |
LBM |
Loopback Message |
LBR |
Loopback Reply |
LTM |
Linktrace Message |
LTR |
Linktrace Reply |
ME |
Maintenance Entity |
MA |
Maintenance Association |
MA-ID |
Maintenance Association Identifier |
MD |
Maintenance Domain |
MEP |
Maintenance Association Endpoint |
MEP-ID |
Maintenance Association Endpoint Identifier |
MHF |
MIP Half Function |
MIP |
Maintenance Domain Intermediate Point |
OpCode |
Operational Code |
RDI |
Remote Defect Indication |
TST |
Ethernet Test (Y.1731) |
SLM |
Synthetic Loss Message (Y.1731) |
SLR |
Synthetic Loss Reply (Y.1731) |
ETH-CFM capabilities may be deployed in many different Ethernet service architectures. The Ethernet-based SAPs and SDP bindings provide the endpoint on which the management points may be created. The basic functions can be used in different services, VPLS and Epipe. The following figures show two possible example scenarios for ETH-CFM deployment in Ethernet access and aggregation networks.
The following functions are supported:
CFM can be enabled or disabled on a SAP or SDP bindings basis.
The eight ETH-CFM levels are suggested to be broken up numerically between customer 7 to 5, service provider 4 to 3 and operator 2 to 1. Level 0 typically is meant to monitor direct connections without any MIPs and should be reserved for port-based G8032 MEPs. These can be configured, deleted or modified.
Down MEP and Up MEP with an MEP-ID on a SAP/SDP binding for each MD level can be configured, modified, or deleted. Each MEP is uniquely identified by the MA-ID, MEP-ID tuple.
MEP creation on a SAP is only allowed for Ethernet ports (with null, q-tags, QinQ encapsulations).
MEP support in different services and the endpoints configured in the services (SAPs, SDPs, IP interfaces, and so on) varies across services and 7210 platforms. See the 7210 SAS-Mxp, R6, R12, S, Sx, T OAM and Diagnostics Guide for more information about MEP support on 7210 SAS platforms.
MIP creation on a SAP for each MD level can be enabled and disabled. MIP creation is automatic or manual when it is enabled. When MIP creation is disabled for an MD level, the existing MIP is removed. The 7210 SAS platforms have the notion of ingress and egress MIPs. Ingress MIP responds to OAM messages that are received. Egress MIP responds to OAM messages that are sent. Ingress and egress MIP support for SAP, SDP bindings and services varies and is listed in the following table. See the 7210 SAS-Mxp, R6, R12, S, Sx, T OAM and Diagnostics Guide for more information about MEP support on 7210 SAS platforms.
Common actionable failures
AIS operates independently from the low-priority-defect setting. The low-priority-defect setting configuration parameter affects only the ETH-CFM fault propagation and alarming outside the scope of AIS. Any fault in the MEP state machine generates AIS when it is configured. The following table describes the ETH-CC defect condition groups, configured low-priority-defect setting, priority, and defect as it applies to fault propagation.
Defect | Low priority defect | Description | Causes | Priority |
---|---|---|---|---|
DefNone |
N/A |
No faults in the association |
Normal operations |
N/A |
DefRDICCM |
allDef |
Remote Defect Indication |
Feedback mechanism to inform that unidirectional faults exist. It provides the feedback loop to the node with the unidirectional failure conditions. |
1 |
DefMACStatus (default) |
macRemErrXcon |
MAC Layer |
Remote MEP is indicating that a remote port or interface is not operational. |
2 |
DefRemoteCCM |
remErrXon |
No communication from remote peer |
MEP is not receiving CCM from a configured peer. The timeout of CCM occurs at 3.5 times the local CC interval. As per the specification, this value is not configurable. |
3 |
DefErrorCCM |
errXcon |
Remote and local configurations do not match required parameters |
Caused by different interval timer, domain-level issues (lower value arriving at a MEP configured with a higher value), MEP receiving CCM with its MEPID |
4 |
DefXconn |
Xcon |
Cross Connected Service |
The service is receiving CCM packets from a different association. This could indicate that two services have merged or there is a configuration error on one of the SAPs or bindings of the service, incorrect association identification. |
5 |
MEP and MIP support
See the 7210 SAS-Mxp, R6, R12, S, Sx, T OAM and Diagnostics Guide for more information about ETH-CFM support for different services and endpoints.
Configuring ETH-CFM parameters
See the 7210 SAS-Mxp, R6, R12, S, Sx, T OAM and Diagnostics Guide for more information about ETH-CFM configuration guidelines for 7210 SAS platforms.
Configuring ETH-CFM requires commands at two different hierarchy levels of the CLI.
This section provides a sample of the global ETH-CFM configuration, which defines the domains, associations, linkage of the service ID or function, and the globally applicable CCM parameters, including the interval and building of the remote MEPs database.
ETH-CFM configuration output
The following example shows ETH-CFM configuration output.
*A:ALU-7_A>config>eth-cfm# info
----------------------------------------------
domain 1 name "1" level 1
association 2 name "1345"
bridge-identifier 100
exit
ccm-interval 60
remote-mepid 2
remote-mepid 3
exit
exit
----------------------------------------------
*A:ALU-7_A>config>eth-cfm#
MEP and service-specific ETH-CFM parameters configured on a SAP
Defining the MEP and configuring service-specific ETH-CFM parameters is performed within the service on the specific SAP or SDP binding. The following example shows service VPLS 100 showing this configuration output on the SAP.
#*A:ALU-7_A>config>service# info
----------------------------------------------
vpls 100 customer 1 create
description "VPLS service 100 - Used for MEP configuration example"
sap 2/2/1:20 create
description "2/2/1:20"
eth-cfm
mep 1 domain 1 association 1 direction down
no shutdown
exit
exit
exit
exit
no shutdown
exit
customer 1 create
description "Default customer"
exit
exit
----------------------------------------------
*A:ALU-7_A>config>service#
All of the preceding examples were based on IEEE 802.1ag. They are not capable of running Y.1731 functions. To build a Y.1731 context, the domain format must be none.
Global ETH-CFM configuration outputs and advanced Y.1731 functions
The following example shows global ETH-CFM configuration outputs and the advanced Y.1731 functions that can be configured. The configuration rejects the configuration of Y.1731 functions within an IEEE 802.1ag context.
*A:7210-2# config>eth-cfm# info
----------------------------------------------
domain 1 format none level 1
association 1 format icc-based name "1234567890123"
bridge-identifier 100
exit
ccm-interval 1
exit
exit
*A:7210-2# config>service# info
----------------------------------------------
vpls 100 customer 1 create
stp
shutdown
exit
sap 2/2/1:40 create
eth-cfm
mep 1 domain 1 association 1 direction up
ais-enable
priority 2
interval 60
exit
eth-test-enable
test-pattern all-ones crc-enable
exit
no shutdown
exit
exit
exit
no shutdown
exit
----------------------------------------------
-
To be able to transmit and also receive AIS PDUs, a Y.1731 MEP must have ais-enable set.
-
To be able to transmit and also receive ETH-Test PDUs, a Y.1731 MEP must have eth-test-enable set.
Applying ETH-CFM parameters
Use the following syntax to apply ETH-CFM parameters to the following entities.
config>service>epipe>sap
eth-cfm
mep mep-id domain md-index association ma-index [direction
{up | down}]
ais-enable
client-meg-level [[level [level ...]]
interval {1 | 60}
priority priority-value
ccm-enable
ccm-ltm-priority priority
eth-test-enable
test-pattern {all-zeros | all-ones} [crc-enable]
low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
[no] shutdown
config>service>epipe>spoke-sdp
eth-cfm
mep mep-id domain md-index association ma-index [direction
{up | down}]
ccm-enable
ccm-ltm-priority priority
eth-test-enable
test-pattern {all-zeros | all-ones} [crc-enable]
low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
[no] shutdown
config>service>vpls>sap
eth-cfm
mip
mep mep-id domain md-index association ma-index [direction {up | down}]
no mep mep-id domain md-index association ma-index
ccm-enable
ccm-ltm-priority priority
eth-test-enable
test-pattern {all-zeros | all-ones} [crc-enable]
low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
mac-address mac-address
[no] shutdown
config>service>vpls>mesh-sdp sdp-id[:vc-id] [vc-type {ether | vlan}]
eth-cfm
mep mep-id domain md-index association ma-index [direction
{up | down}]
ccm-enable
ccm-ltm-priority priority
eth-test-enable
test-pattern {all-zeros | all-ones} [crc-enable]
low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
mac-address mac-address
[no] shutdown
config>service>vpls
spoke-sdp sdp-id:vc-id [vc-type {ether | vlan}] [split-horizon-group group-name] [no-endpoint]
spoke-sdp sdp-id:vc-id [vc-type {ether | vlan}] [split-horizon-group group-name] endpoint endpoint
eth-cfm
map mep-id domain md-index association ma-index [direction
{up | down}]
ccm-enable
ccm-ltm-priority priority
eth-test-enable
test-pattern {all-zeros | all-ones} [crc-enable]
low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
mac-address mac-address
[no] shutdown
oam
eth-cfm linktrace mac-address mep mep-id domain md-index association ma-index [ttl ttl-value]
eth-cfm loopback mac-address mep mep-id domain md-index association ma-index [send-count send-count] [size data-size] [priority priority]
eth-cfm eth-test mac-address mep mep-id domain md-index association ma-index [priority priority] [data-length data-length]
eth-cfm one-way-delay-test mac-address mep mep-id domain md-index association ma-index [priority priority]
eth-cfm two-way-delay-test mac-address mep mep-id domain md-index association ma-index [priority priority]
eth-cfm two-way-slm-test mac-address mep mep-id domain md-index association ma-index [priority priority]
Service management tasks
This section describes the service management tasks.
Modifying customer accounts
To access a specific customer account, you must specify the customer ID. To display a list of customer IDs, use the show service customer command. Enter the parameter (description, contact, phone), then enter the new information.
config>service# customer customer-id create
[no] contact contact-information
[no] description description-string
[no] phone phone-number
Modifying customer accounts
config>service# customer 27 create
config>service>customer$ description ‟Western Division”
config>service>customer# contact ‟John Dough”
config>service>customer# no phone ‟(650) 237-5102”
Deleting customers
The no form of the customer command removes a customer ID and all associated information. All service references to the customer must be shut down and deleted before a customer account can be deleted.
config>service# no customer customer-id
Deleting customers
config>service# epipe 5 customer 27 shutdown
config>service# epipe 9 customer 27 shutdown
config>service# no epipe 5
config>service# no epipe 9
config>service# no customer 27
Modifying SDPs
To access a specific SDP, you must specify the SDP ID. To display a list of SDPs, use the show service sdp command. Enter the parameter, such as description, far-end, and lsp, then enter the new information.
You cannot modify the SDP encapsulation type after the SDP is created.
config>service# sdp sdp-id
Modifying SDPs
config>service# sdp 79
config>service>sdp# description ‟Path-to-107”
config>service>sdp# shutdown
config>service>sdp# far-end ‟10.10.10.107”
config>service>sdp# path-mtu 1503
config>service>sdp# no shutdown
Deleting SDPs
The no sdp command removes an SDP ID and all associated information. Before an SDP can be deleted, the SDP must be shutdown and removed (unbound) from all customer services where it is applied.
config>service# no sdp 79
Deleting SDPs
config>service# epipe 5 spoke-sdp 79:5
config>service>epipe>sdp# shutdown
config>service>epipe>sdp# exit
config>service>epipe# exit
config>service# no sdp 79
Layer 2 Control Processing
Operators providing Epipe service need to be able to transparently forward Layer 2 Control Processing (L2CP) control frames received from the customers. This allows their customers to run these control protocols between the different locations that are part of the Layer 2 VPN service. The 7210 SAS platforms provide the user with the following capability:
An option to tunnel, discard, or peer for EFM OAM, LLDP, Dot1x, and LACP.
BPDU translation and Layer 2 protocol tunneling support for xSTP and Cisco control protocols. This is supported only in a VPLS service. For more information, see L2PT and BPDU translation.
The CDP, VTP, DTP, PAgP, and UDLD management protocols are forwarded transparently in an Epipe service.
By default, LACP, LLDP, EFM OAM, and Dot1x L2CP untagged packets are discarded if the protocol is not enabled on the port where these frames are received. The user has an option to enable peering by enabling the protocol on the port and configuring the appropriate parameters for the protocol. The user also has an option to tunnel these packets using an Epipe or VPLS service.
In a VPLS service, the Layer 2 control frames are sent out of all the SAPs configured in the VPLS service. Nokia recommends using this feature carefully and only when a VPLS is used to emulate an end-to-end Epipe service (that is, an Epipe configured using a three-point VPLS service, with one access SAP and two access-uplink SAP/SDPs for redundant connectivity). That is, if the VPLS service is used for multipoint connectivity, Nokia does not recommend using this feature. When a Layer 2 control frame is forwarded out of a dot1q SAP or a QinQ SAP, the SAP tags of the egress SAP are added to the packet.
The following SAPs can be configured for tunneling the untagged L2CP frames (corresponding protocol tunneling needs to be enabled on the port):
If the port encapsulation is null, the user has an option to tunnel these packets by configuring a null SAP on a port.
If the port encapsulation is dot1q, the user has an option to use dot1q explicit null SAP (for example, 1/1/10:0) or a dot1q default SAP (for example, 1/1/11:*) to tunnel these packets.
If the port encapsulation is QinQ, the user has an option to use 0.* SAP (for example, 1/1/10:0.*) to tunnel these packets.
In addition to the preceding list of protocols, protocols that are not supported on 7210 SAS (for example, GARP, GVRP, ELMI, and others) are transparently forwarded in case of a VPLS service. These protocols are transparently forwarded if a null SAP, dot1q default SAP, dot1q explicit null SAP, or 0.* SAP is configured on the port and the received packet is untagged. If the received packet is tagged and matches the tag of any of the SAPs configured on the port, it is forwarded in the context of the SAP and the service. Otherwise, if the received packet is untagged and none of the null or dot1q default or dot1q explicit null or 0.* SAP is configured, it is discarded.
If a 7210 SAS receives a tagged L2CP packet on any SAP (including null, dot1q, dot1q range, QinQ, QinQ default), it is forwarded transparently in the service similar to normal service traffic (xSTP processing behavior is different in VPLS service and is listed as follows).
The xSTP processing behavior in a VPLS service is as follows:
If xSTP is enabled in the service, and if the tag in the STP BPDU matches the tag of the configured SAP, the received xSTP BPDU is processed by the local xSTP instance on the node for that service when xSTP is enabled on the SAP, and discarded when xSTP is disabled on the SAP.
If the tags do not match, xSTP BPDU packets are transparently forwarded in the service similar to normal service traffic.
If xSTP is disabled in the service, STP BPDU packets are transparently forwarded in the service similar to normal service traffic.
The following table describes L2CP support for the 7210 SAS-R6 and 7210 SAS-R12.
Packet type | 7210 SAS-R6 and 7210 SAS-R12 |
---|---|
LACP |
Option to tunnel or discard or peer |
Dot1x |
Option to tunnel or discard or peer |
LLDP |
Option to tunnel or discard or peer1 |
EFM |
Option to tunnel or discard or peer |
L2TP |
Supported 2 |
BPDU Tunneling |
Supported |
xSTP |
Option to peer or tunnel |
Global services command reference
Command hierarchies
Customer commands
config
- service
- [no] customer customer-id
- contact contact-information
- no contact
- description description-string
- no description
- [no] phone phone-number
Pseudowire (PW) commands (applicable only for 7210 SAS devices configured in network mode)
config
- service
- pw-routing
- boot-timer secs
- no boot-timer
- local-prefix local-prefix [create]
- no local-prefix local-prefix
- advertise-bgp route-distinguisher rd [community community]
- no advertise-bgp route-distinguisher rd
- path name [create]
- no path name
- hop hop-index ip-address
- no hop hop-index
- [no] shutdown
- retry-count [10..10000]
- no retry-count
- retry-timer secs
- no retry-timer
- spe-address global-id:prefix
- no spe-address
- [no] static-route route-name
config
- service
- [no] pw-template policy-id [use-provisioned-sdp] [create]
- accounting-policy acct-policy-id
- no accounting-policy
- [no] collect-stats
- [no] control-word
- [no] disable-learning
- [no] disable-aging
- hash-label [signal-capability]
- no hash-label
- igmp-snooping
- import policy-name
- no import
- last-member-query-interval 1/10 seconds
- no last-member-query-interval
- max-num-groups max-num-groups
- no max-num-groups
- query-interval seconds
- no query-interval
- query-response-interval seconds
- no query-response-interval
- robust-count robust-count
- no robust-count
- [no] send-queries
- version version
- no version
- vc-type {blockable | non-blockable}
- no vc-type
- [no] mac-pinning
- max-nbr-mac-addr table-size
- no max-nbr-mac-addr
- split-horizon-group group-name
- no split-horizon-group
- description description-string
- no description
- vc-type {ether | vlan}
- vlan-vc-tag 0..4094
- no vlan-vc-tag
config
- service
- sdp sdp-id [mpls] [create]
- no sdp sdp-id
- accounting-policy acct-policy-id
- no accounting-policy
- collect-stats acct-policy-id
- no collect-stats
- [no] adv-mtu-override
- [no] bgp-tunnel
- [no] collect-stats
- description description-string
- no description
- far-end ip-address node-id node-id [global-id global-id]
- no far-end
- keep-alive
- hello-time seconds
- no hello-time
- hold-down-time seconds
- no hold-down-time
- max-drop-count count
- no max-drop-count
- message-length octets
- no message-length
- [no] shutdown
- timeout timeout
- no timeout
- [no] ldp
- metric metric
- no metric
- no mixed-lsp-mode
- mixed-lsp-mode
- no revert-time
- revert-time {revert-time | infinite}
- [no] lsp lsp-name
- path-mtu octets
- no path-mtu
- [no] shutdown
- signaling [off | tldp]
- [no] sr-isis
- [no] sr-ospf
SAP commands for 7210 SAS devices configured in access or network mode
config
- service
- epipe
- sap sap-id [create] [no-endpoint] with-aggregate-meter
- no sap sap-id [create] endpoint endpoint-name
- no sap sap-id
- vpls
- sap sap-id [split-horizon-group group-name] [eth-ring ring-index] [create]
- no sap sap-id
- vprn
- interface ip-int-name [create]
- no interface ip-int-name
- sap sap-id [create]
- no sap sap-id
ETH-CFM configuration commands
For command descriptions, see the 7210 SAS-Mxp, R6, R12, S, Sx, T OAM and Diagnostics Guide.
config
- eth-cfm
- domain md-index [format md-name-format] [name md-name] level level
- domain md-index
- no domain md-index
- association ma-index [format ma-name-format] name ma-name
- association ma-index
- no association ma-index
- [no] bridge-identifier bridge-id
- mhf-creation {none | explicit | default | static}
- no mhf-creation
- mip-ltr-priority priority
- vlan vlan-id
- no vlan
- ccm-interval {10ms | 100ms | 1 | 10 | 60 | 600}
- no ccm-interval
- [no] remote-mep-id mep-id
- slm
- inactivity-timer timer
- no inactivity-timer
Show commands
show
- service
- customer [customer-id] [site customer-site-name]
- fdb-mac [ieee-address] [expiry]
- id service vpls-group
- id service vpls-group vpls-group-id non-template-saps
- sdp sdp-id keep-alive-history
- sdp far-end ip-address keep-alive-history
- sdp [sdp-id] [detail]
- sdp far-end ip-address [detail]
- sdp-using [sdp-id[:vc-id] | far-end ip-address]
- service-using [epipe] [mirror] [customer customer-id]
- eth-ring [status]
- eth-ring ring-index hierarchy
- eth-ring ring-index [path {a | b}]
- eth-cfm
- association [ma-index] [detail]
- cfm-stack-table [port [port-id [vlan vlan-id]] [level 0..7] [direction down]
- cfm-stack-table
- cfm-stack-table port [{all-ports] [level 0..7] [direction down]
- cfm-stack-table port-id [vlan qtag[.qtag]] [level 0..7] [direction down]
- mep mep-id domain md-index association ma-index [loopback] [linktrace]
- mep mep-id domain md-index association ma-index remote-mepid mep-id | all-remote-mepids
- mep mep-id domain md-index association ma-index eth-test-results [remote-peer mac-address]
- mep mep-id domain md-index association ma-index one-way-delay-test [remote-peer mac-address]
- mep mep-id domain md-index association ma-index two-way-delay-test [remote-peer mac-address]
- mip
- pw-routing {local-prefix | static-route | paths | all}
- pw-routing route-table [all-routes]
- pw-routing route-table summary
- pw-template
Tools perform commands
tools
- perform
- service
- eval-pw-template policy-id [allow-service-impact]
- id service-id
- endpoint endpoint-name
- force-switchover sdp-id:vc-id
- no force-switchover
- force-switchover spoke-sdp-fec [1..4294967295]
- eval-pw-template policy-id [allow-service-impact]
- eval-expired-fec
- eval-expired-fec spoke-sdp-fec-id
- eval-expired-fec all
- spoke-sdp-fec-release global-id[:prefix[:ac-id]]
Command descriptions
Configuration commands
Generic commands
shutdown
Syntax
[no] shutdown
Context
config>dot1ag>mep
config>service>sdp
config>service>sdp>keep-alive
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Special Cases
- Service Admin State
Bindings to an SDP within the service are put into the out-of-service state when the service is shut down. While the service is shut down, all customer packets are dropped and counted as discards for billing and debugging purposes.
- SDP (global)
When an SDP is shut down at the global service level, all bindings to that SDP are put into the out-of-service state, and the SDP is put into the administratively and operationally down states. Packets that would usually be transmitted using this SDP binding are discarded and counted as dropped packets.
- SDP (service level)
Shutting down an SDP within a service affects traffic only on that service from entering or being received from the SDP. The SDP may still be operationally up for other services.
- SDP Keepalives
Enables SDP connectivity monitoring keepalive messages for the SDP ID. The default state is disabled (shutdown) in which case the operational state of the SDP-ID is not affected by the keepalive message state.
description
Syntax
description description-string
no description
Context
config>service>customer
config>service>sdp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Parameters
- string
Specifies the description character string. Allowed values are any string up to 80 characters composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
Customer management commands
customer
Syntax
customer customer-id [create]
no customer customer-id
Context
config>service
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Parameters
- customer-id
Specifies the ID number to be associated with the customer, expressed as an integer.
contact
Syntax
contact contact-information
no contact contact-information
Context
config>service>customer
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Parameters
- contact-information
Specifies the customer contact information entered as an ASCII character string up to 80 characters. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes. Any printable, seven bit ASCII characters may be used within the string.
phone
Syntax
[no] phone string
Context
config>service>customer
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Parameters
- string
Specifies the customer phone number entered as an ASCII string, up to 80 characters. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes. Any printable, seven-bit ASCII characters may be used within the string.
Pseudowire commands
pw-routing
Syntax
pw-routing
Context
config>service
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
Commands in this context 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.
Default
disabled
boot-timer
Syntax
boot-timer timer-value
no boot-timer
Context
config>service>pw-routing
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
boot-timer 10
Parameters
- timer-value
Specifies the value of the boot timer in seconds.
local-prefix
Syntax
local-prefix local-prefix [create]
no local-prefix local-prefix
Context
config>service>pw-routing
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
no local-prefix
Parameters
- local-prefix
Specifies a 32-bit prefix for the AII. One or more prefix values, up to a maximum of 16, may be assigned to the node. The global ID can contain the 2-octet or 4-octet value of the provider Autonomous System Number (ASN). The presence of a global ID based on the provider ASN ensures that the AII for spoke-SDPs configured on the node are globally unique.
- raw-prefix 1
4294967295
- global-id 1
4294967295
advertise-bgp
Syntax
advertise-bgp route-distinguisher rd [community community]
no advertise-bgp route-distinguisher rd
Context
config>service>pw-routing>local-prefix
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
no advertise-bgp
Parameters
- rd
Specifies a 32-bit prefix for the AII. One or more prefix values, up to a maximum of 16, may be assigned to the node. The global ID can contain the 2-octet or 4-octet value of the provider Autonomous System Number (ASN). The presence of a global ID based on the provider ASN ensures that the AII for spoke-SDPs configured on the node is globally unique.
- community community
Specifies an optional BGP community attribute associated with the advertisement. To delete a previously advertised community, advertise-bgp route-distinguisher must be run again with the same value for the RD but excluding the community attribute.
path
Syntax
path name [create]
no path name
Context
config>service>pw-routing
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
no path
Parameters
- name
Specifies a locally unique, case-sensitive alphanumeric name label for the MS-PW path of up to 32 characters.
hop
Syntax
hop hop-index ip-address
no hop hop-index
Context
config>service>pw-routing>path
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
no hop
Parameters
- hop-index
Specifies a locally significant numeric identifier for the hop. The hop index is used to order the hops specified. The LSP always traverses from the lowest hop index to the highest. The hop index does not need to be sequential.
- ip-address
Specifies the system IP address or terminating IP address for the T-LDP session to the S-PE corresponding to this hop. For a specific IP address on a hop, the system chooses the SDP.
retry-count
Syntax
retry-count [10..10000]
no retry-count
Context
config>service>pw-routing
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
30
Parameters
- retry-count
Specifies the maximum number of retries before putting the spoke-SDP into the shutdown state.
retry-timer
Syntax
retry-timer secs
no retry-timer
Context
config>service>pw-routing
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
retry-timer 30
Parameters
- secs
Specifies the initial retry timer value in seconds.
10 to 480
spe-address
Syntax
spe-address global-id:prefix
no spe-address
Context
config>service>pw-routing
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
no spe-address
Parameters
- global-id
Specifies a 4-octet value that is unique to the service provider. For example, the global ID can contain the 2-octet or 4-octet value of the provider Autonomous System Number (ASN).
Syntax: <global-id:prefix>: <global-id>:{<prefix>|<ipaddress>} global-id 1 to 4294967295 prefix 1 to 4294967295 ipaddress a.b.c.d
static-route
Syntax
[no] static-route route-name
Context
config>service>pw-routing
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
no static-route
Parameters
- route-name
Specifies the static pseudowire route.
- <global-id>:0
4294967295 prefix a.b.c.d | 0— 4294967295 ip_addr a.b.c.d
pw-template
Syntax
[no] pw-template policy-id [use-provisioned-sdp] [create]
Context
config>service
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configures an SDP template.
Parameters
- use-provisioned-sdp
Specifies whether to use an already provisioned SDP. When specified, the tunnel manager is consulted for an existing active SDP. Otherwise, the default SDP template is used for instantiation of the SDP.
- create
This keyword is required when creating the configuration context. When the context is created, it is possible to navigate to the context without the create keyword.
control-word
Syntax
[no] control-word
Context
config>service>pw-template
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
no control-word
SDP commands
sdp
Syntax
sdp sdp-id [mpls] [create]
no sdp sdp-id
Context
config>service
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Parameters
- sdp-id
Specifies the SDP identifier.
accounting-policy
Syntax
accounting-policy acct-policy-id
no accounting-policy
Context
config>service>sdp
config>service>pw-template
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Parameters
- acct-policy-id
Specifies the accounting policy-id, as configured in the config>log>accounting-policy context.
collect-stats
Syntax
[no] collect-stats
Context
config>service>sdp
config>service>pw-template
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
no collect-stats
hash-label
Syntax
hash-label [signal-capability]
no hash-label
Context
config>service>pw-template
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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 datapath is modified such that the result of the hash on the packet header is communicated to the egress datapath for use as the value of the label field of the hash label. The egress datapath appends the hash label at the bottom of the stack (BoS) and sets the S-bit to one (1).
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.
The 7210 SAS local PE inserts the Flow Label Interface Parameters sub-TLV with T=1 and R=1 in the PW ID FEC element in the label mapping message for the specific spoke-SDP or mesh-SDP.
If a remote PE does not send the Flow Label sub-TLV in the PW ID FEC element, or sends a Flow Label sub-TLV in the PW ID FEC element with T=FALSE and R=FALSE, the local node disables the hash label capability. Consequently, the local PE node does not insert a hash label in the user and control plane packets that it forwards on the spoke-SDP or mesh-SDP. The local PE node also drops user and control plane packets received from remote PE if they include a hash label. The dropped packets may be caused by any of the following:
a remote 7210 SAS PE that does not support the hash-label command
a remote 7210 SAS PE that has the hash-label command enabled but does not support the signal-capability option
a remote 7210 SAS PE that supports the hash-label command and the signal-capability option, but the user did not enable them due to a misconfiguration
If the remote PE sends Flow Label sub-TLV in the PW ID FEC element with T=TRUE and R=TRUE, the local PE enables the hash label capability. Consequently, the local PE node inserts a hash label in the user and control plane packets that it forwards on the spoke-SDP or mesh-SDP. The local PE node also accepts user and control plane packets from the remote PE with or without the hash label.
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.
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.
Default
no hash-label
Parameters
- signal-capability
Keyword that enables the signaling and negotiation of hash label use between the local and remote PE nodes.
vc-type
Syntax
vc-type {ether | vlan}
Context
config>service>pw-template
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
The VC type value for Ethernet is 0x0005.
The VC type value for an Ethernet VLAN is 0x0004.
Parameters
- ether
Defines the VC type as Ethernet. The ether and vlan keywords are mutually exclusive. When the VC type is not defined then the default is Ethernet for spoke-SDP bindings. Defining Ethernet is the same as executing no vc-type and restores the default VC type for the spoke-SDP binding. (hex 5)
- vlan
Defines the VC type as VLAN. The ether and vlan keywords are mutually exclusive. When the VC type is not defined, the default is Ethernet for spoke-SDP bindings.
vlan-vc-tag
Syntax
vlan-vc-tag vlan-id
no vlan-vc-tag
Context
config>service>pw-template
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
no vlan-vc-tag
Parameters
- vlan-id
Specifies a valid VLAN identifier to bind an 802.1Q VLAN tag ID.
adv-mtu-override
Syntax
[no] adv-mtu-override
Context
config>service>sdp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
no adv-mtu-override
bgp-tunnel
Syntax
[no] bgp-tunnel
Context
config>service>sdp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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).
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-Mxp, R6, R12, S, Sx, T Routing Protocols Guide.
The no form of this command disables resolving BGP route tunnel LSP for SDP far-end.
Default
no bgp-tunnel
far-end
Syntax
far-end ip-address node-id node-id [global-id global-id]
no far-end
Context
config>service>sdp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Parameters
- ip-address
Specifies the system address of the far-end 7210 SAS devices for the SDP in dotted-decimal notation.
- node-id node-id
Specifies the MPLS-TP Node ID of the far-end system for the SDP, either in dotted-decimal notation (a.b.c.d) or an unsigned 32-bit integer (1 – 4294967295). This parameter is mandatory for an SDP using an MPLS-TP LSP.
- global-id global-id
Specifies the MPLS-TP Global ID of the far-end system for the SDP, in an unsigned 32-bit integer. This parameter is optional for an SDP using an MPLS-TP LSP. If not entered, a default value for the Global ID of ‟0” is used, which indicates that the far-end node is in the same domain as the local node. The user must explicitly configure a Global ID if its value is non-zero.
metric
Syntax
metric metric
no metric
Context
config>service>sdp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Parameters
- metric
Specifies the SDP metric.
mixed-lsp-mode
Syntax
[no] mixed-lsp-mode
Context
config>service>sdp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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 can activate it to forward service packets according to the following priority order:
RSVP LSP type. One RSVP LSP can be configured per SDP. This is the highest priority LSP type.
LDP LSP type. One LDP FEC is used per SDP. 7210 SAS does not support LDP ECMP.
BGP LSP type. One RFC 3107-labeled BGP prefix programmed by the service manager.
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.
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, see the 7210 SAS-Mxp, R6, R12, S, Sx, T 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.
Default
no mixed-lsp-mode
revert-time
Syntax
revert-time {revert-time | infinite}
no revert-time
Context
config>service>sdp>mixed-lsp-mode
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
0
Parameters
- revert-time
Specifies the delay period, in seconds, that the SDP must wait before it reverts to a higher priority LSP type when one becomes available. A value of zero means the SDP reverts immediately to a higher priority LSP type when one becomes available.
- infinite
This keyword forces the SDP to never revert to another higher priority LSP type unless the currently active LSP type is down.
ldp
Syntax
[no] ldp
Context
config>service>sdp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
no ldp
lsp
Syntax
lsp lsp-name
no lsp lsp-name
Context
config>service>sdp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Parameters
- lsp-name
Specifies the name of the LSP to associate with the SDP. An LSP name is case-sensitive and is limited to 32 ASCII 7-bit printable characters with no spaces.
signaling
Syntax
signaling {off | tldp}
Context
config>service>sdp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
tldp
Parameters
- off
Specifies that ingress and egress signal auto-labeling is not enabled. If this keyword is selected, each service using the specified SDP must manually configure VPN labels. This configuration is independent of the SDP transport type, MPLS (RSVP or LDP).
- tldp
Specifies that ingress and egress pseudowire signaling using T-LDP is enabled.
path-mtu
Syntax
path-mtu bytes
no path-mtu
Context
config>service>sdp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
sr-isis
Syntax
[no] sr-isis
Context
config>service>sdp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
no sr-isis
sr-ospf
Syntax
[no] sr-ospf
Context
config>service>sdp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
no sr-ospf
SDP keepalive commands
keep-alive
Syntax
keepalive
Context
config>service>sdp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
Commands in this context 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.
The following table describes the keepalive interpretation of SDP echo reply response conditions and the effect on the SDP ID operational status.
Result of request | Stored response state | Operational state |
---|---|---|
keepalive request timeout without reply |
Request Timeout |
Down |
keepalive request not sent because of non-existent orig-sdp-id3 |
Orig-SDP Non-Existent |
Down |
keepalive request not sent because of administratively down orig-sdp-id |
Orig-SDP Admin-Down |
Down |
keepalive reply received, invalid origination-id |
Far End: Originator-ID Invalid |
Down |
keepalive reply received, invalid responder-id |
Far End: Responder-ID Error |
Down |
keepalive reply received, No Error |
Success |
Up (If no other condition prevents) |
hello-time
Syntax
hello-time seconds
no hello-time
Context
config>service>sdp>keep-alive
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
hello-time 10
Parameters
- seconds
Specifies the time in seconds between SDP keepalive messages, expressed as a decimal integer.
hold-down-time
Syntax
hold-down-time seconds
no hold-down-time
Context
config>service>sdp>keep-alive
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
hold-down-time 10
Parameters
- seconds
Specifies the time in seconds, expressed as a decimal integer, the sdp-id remains in the operationally down state before it is eligible to enter the operationally up state. A value of 0 indicates that no hold-down-time is enforced for sdp-id.
max-drop-count
Syntax
max-drop-count count
no max-drop-count
Context
config>service>sdp>keep-alive
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
max-drop-count 3
Parameters
- count
Specifies he number of consecutive SDP keepalive requests that are failed to be sent or replies missed, expressed as a decimal integer.
message-length
Syntax
message-length octets
no message-length
Context
config>service>sdp>keep-alive
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
message-length 0
Parameters
- octets
Specifies the size of the keepalive request messages in octets, expressed as a decimal integer. The size keyword overrides the default keepalive message size.
timeout
Syntax
timeout timeout
no timeout
Context
config>service>sdp>keep-alive
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configures the time interval that the SDP waits before tearing down the session.
Default
timeout 5
Parameters
- timeout
Specifies the timeout time, in seconds.
Show commands
Service show commands
customer
Syntax
customer [customer-id] [site customer-site-name]]
Context
show>service
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays service customer information.
Parameters
- customer-id
Displays only information for the specified customer ID.
- site customer-site-name
Specifies the customer site, which is an anchor point for an ingress and egress virtual scheduler hierarchy.
Output
The following output is an example of service customer information, and Output fields: customer describes the output fields.
Sample output*A:ALA-12# show service customer
==========================================================
Customers
==========================================================
Customer-ID : 1
Contact : Manager
Description : Default customer
Phone : (123) 555-1212
Customer-ID : 2
Contact : Tech Support
Description : TiMetra Networks
Phone : (234) 555-1212
Customer-ID : 3
Contact : Test
Description : TiMetra Networks
Phone : (345) 555-1212
Customer-ID : 6
Contact : Test1
Description : Epipe Customer
Phone : (456) 555-1212
Customer-ID : 7
Contact : Test2
Description : VPLS Customer
Phone : (567) 555-1212
Customer-ID : 274
Contact : TestA
Description : ABC Company
Phone : 650 123-4567
Customer-ID : 94043
Contact : Test Engineer on Duty
Description : TEST Customer
Phone : (789) 555-1212
------------------------------------------------------
Total Customers : 8
-----------------------------------------------------------
*A:ALA-12#
*A:ALA-12# show service customer 274
==============================================================================
Customer 274
==============================================================================
Customer-ID : 274
Contact : Mssrs. Beaucoup
Description : ABC Company
Phone : 650 123-4567
------------------------------------------------------------------------------
Multi Service Site
------------------------------------------------------------------------------
Site : west
Description : (Not Specified)
==============================================================================
*A:ALA-12#
Label | Description |
---|---|
Customer-ID |
The ID that uniquely identifies a customer. |
Contact |
The name of the primary contact person. |
Description |
Generic information about the customer. |
Phone |
The phone or pager number to reach the primary contact person. |
Total Customers |
The total number of customers configured. |
Site |
Multi-service site name. A multi-service customer site is a group of SAPs with common origination and termination points. |
Description |
Displays information about the multi-service site of a specific customer. |
Assignment |
The port ID, MDA, or card number, where the SA's that are members of this multi- service site are defined. |
I. Sched Pol |
The ingress QoS scheduler policy assigned to this multi-service site. |
E. Sched Pol |
The egress QoS scheduler policy assigned to this multi-service site. |
Service-ID |
The ID that uniquely identifies a service. |
SAP |
Specifies the SAP assigned to the service. |
fdb-mac
Syntax
fdb-mac [ieee-address] [expiry]
Context
show>service
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays the FDB entry for a specific MAC address.
Parameters
- ieee-address
Specifies the 48-bit MAC address in the form aa:bb:cc:dd:ee:ff or aa-bb-cc-dd-ee-ff where aa, bb, cc, dd, ee, and ff are hexadecimal numbers.
- expiry
Keyword to display the amount of time until MAC is aged out.
Output
The following output is an example of FDB MAC information, and Output fields: FDB MAC describes the output fields.
Sample output*A:ALA-48# show service fdb-mac
===============================================================================
Service Forwarding Database
===============================================================================
ServId MAC Source-Identifier Type/Age Last Change
-------------------------------------------------------------------------------
103 12:34:56:78:90:0f sap:1/1/7:0 Static 02/02/2009 09:27:57
700 90:30:ff:ff:ff:8f cpm Host 02/02/2009 09:27:57
-------------------------------------------------------------------------------
No. of Entries: 2
===============================================================================
*A:ALA-48#
*A:ALA-48# show service fdb-mac expiry
===============================================================================
Service Forwarding Database
===============================================================================
ServId MAC Source-Identifier Type/ Last Change
Expiry
-------------------------------------------------------------------------------
103 12:34:56:78:90:0f sap:1/1/7:0 Static 02/02/2009 09:27:57
700 90:30:ff:ff:ff:8f cpm Host 02/02/2009 09:27:57
-------------------------------------------------------------------------------
No. of Entries: 2
===============================================================================
*A:ALA-48#
Label | Description |
---|---|
ServId |
Displays the configured service ID |
MAC |
Displays the MAC address |
Source-Identifier |
Displays the location where the MAC is defined |
Type/Age |
Static — FDB entries created by management Learned — Dynamic entries created by the learning process OAM — Entries created by the OAM process H — Host, the entry added by the system for a static configured subscriber host D or DHCP — DHCP-installed MAC. Learned addresses can be temporarily frozen by the DHCP snooping application for the duration of a DHCP lease. P — Indicates the MAC is protected by the MAC protection feature |
Last Change |
Displays the time when the specific row entry was last changed |
sdp
Syntax
sdp sdp-id keep-alive-history
sdp far-end ip-address keep-alive-history
sdp [sdp-id] [detail]
sdp far-end ip-address [detail]
Context
show>service
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays SDP information.
If no optional parameters are specified, a summary SDP output for all SDPs is displayed.
Parameters
- sdp-id
Specifies the SDP ID for which to display information.
- far-end ip-address
Displays only SDPs matching with the specified far-end IP address.
- detail
Displays detailed SDP information.
- keep-alive-history
Displays the last fifty SDP keepalive events for the SDP.
Output
The following output is an example of SDP information, and Output fields: service SDP describes the output fields.
Sample output*A:ALA-7210# show service sdp
==============================================================================
Services: Service Destination Points
==============================================================================
SdpId Adm MTU Opr MTU IP address Adm Opr Del LSP Signal
------------------------------------------------------------------------------
10 4462 4462 10.20.1.3 Up Dn NotReady MPLS B TLDP
40 4462 1534 10.20.1.20 Up Up MPLS B TLDP
60 4462 1514 10.20.1.21 Up Up MPLS B TLDP
100 4462 4462 10.0.0.2 Down Down MPLS B TLDP
500 4462 4462 10.20.1.50 Up Dn NotReady MPLS B TLDP
------------------------------------------------------------------------------
Number of SDPs : 5
==============================================================================
*A:ALA-7210#
*7210SAS>show>service# sdp 1 detail
===============================================================================
Service Destination Point (Sdp Id : 1) Details
===============================================================================
-------------------------------------------------------------------------------
Sdp Id 1 -0.0.0.0
-------------------------------------------------------------------------------
Description : (Not Specified)
SDP Id : 1 SDP Source : manual
Admin Path MTU : 0 Oper Path MTU : 0
Far End : 0.0.0.0 Delivery : MPLS
Tunnel Far End : n/a LSP Types : None
Admin State : Down Oper State : Down
Signaling : TLDP Metric : 0
Acct. Pol : None Collect Stats : Disabled
Last Status Change : 11/04/2099 22:56:41 Adv. MTU Over. : No
Last Mgmt Change : 11/10/2099 15:56:44 VLAN VC Etype : 0x8100
Bw BookingFactor : 100 PBB Etype : 0x88e7
Oper Max BW(Kbps) : 0 Avail BW(Kbps) : 0
Net-Domain : default Egr Interfaces : n/a
Flags : SdpAdminDown NoSysIPAddr
TranspTunnDown
Mixed LSP Mode Information :
Mixed LSP Mode : Enabled Active LSP Type : RSVP....also be
LDP, BGP
Revert Time : 200 Revert Count Down : n/a
KeepAlive Information :
Admin State : Disabled Oper State : Disabled
Hello Time : 10 Hello Msg Len : 0
Hello Timeout : 5 Unmatched Replies : 0
Max Drop Count : 3 Hold Down Time : 10
Tx Hello Msgs : 0 Rx Hello Msgs : 0
-------------------------------------------------------------------------------
RSVP/Static LSPs
-------------------------------------------------------------------------------
Associated LSP List :
No LSPs Associated
===============================================================================
*7210SAS>show>service#
Label | Description |
---|---|
SDP Id |
Displays the SDP identifier |
Description |
Displays a text string describing the SDP |
Admin Path MTU |
Displays the required largest service frame size (in octets) that can be transmitted through this SDP to the far-end ESR, without requiring the packet to be fragmented. The default value of zero indicates that the path MTU should be computed dynamically from the corresponding MTU of the tunnel. |
Opr Path MTU |
Displays the actual largest service frame size (in octets) that can be transmitted through this SDP to the far-end ESR, without requiring the packet to be fragmented. To be able to bind this SDP to a specific service, the value of this object minus the control word size (if applicable) must be equal to or larger than the MTU of the service, as defined by its service MTU. |
Far End |
Displays the far end IP address |
Delivery |
The type of delivery used by the SDP: MPLS |
IP address |
Specifies the IP address of the remote end of the MPLS tunnel defined by this SDP |
Adm Admin State |
The administrative state of the SDP |
Opr Oper State |
The operating state of the SDP |
Flags |
Specifies all the conditions that affect the operating status of this SDP |
Signal Signaling |
The signaling protocol used to obtain the ingress and egress labels used in frames transmitted and received on the SDP |
Last Status Change |
The time of the most recent operating status change to this SDP |
Adv. NTU Over |
Specifies whether the advertised MTU of a VLL spoke-SDP bind includes the 14-byte Layer 2 header, so that it is backward compatible with pre-2.0 software. |
Last Mgmt Change |
The time of the most recent management-initiated change to this SDP. |
KeepAlive Information |
This section displays Keepalive information. |
Hello Time |
Specifies how often the SDP echo request messages are transmitted on this SDP. |
Hello Msg Len |
The length of the SDP echo request messages transmitted on this SDP. |
Hello Timeout |
The number of seconds to wait for an SDP echo response message before declaring a timeout. |
Unmatched Replies |
The number of SDP unmatched message replies timer expired. |
Max Drop Count |
The maximum number of consecutive SDP echo request messages that can be unacknowledged before the keepalive protocol reports a fault. |
Hold Down Time |
The amount of time to wait before the keepalive operating status is eligible to enter the alive state. |
TX Hello Msgs |
The number of SDP echo request messages transmitted after the keepalive was administratively enabled or the counter was cleared. |
Rx Hello Msgs |
The number of SDP echo request messages received after the keepalive was administratively enabled or the counter was cleared. |
Associated LSP List |
When the SDP type is MPLS, a list of LSPs used to reach the far-end router displays. All the LSPs in the list must terminate at the IP address specified in the far end field. |
Lsp Name |
Displays the LSP name. |
Time Since Last Transaction |
Displays the time of the last transaction. |
Signaling |
Specifies the signaling type. |
Metric |
Displays the metric to be 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 like MP-BGP to select route with lower value. |
Acct. Pol |
Displays the policy to use to collect accounting statistics on this SDP. The value zero indicates that the agent should use the default accounting policy, if one exists. |
Collect Stats |
Specifies whether the agent collects accounting statistics for this SDP. When the value is true the agent collects accounting statistics on this SDP. |
VLAN VC Etype |
Displays the VLAN VC type. |
BW Booking Factor |
Specifies the value used to calculate the max SDP available bandwidth. The value specifies the percentage of the SDP max available bandwidth for VLL call admission. When the value of is set to zero (0), no new VLL spoke-SDP bindings with non-zero bandwidth are permitted with this SDP. Overbooking >100% is allowed. |
PBB Etype |
Displays the Ethertype used in frames sent out on this SDP when specified as vlan for Provider Backbone Bridging frames. |
Oper Max BW (Kbps) |
Indicates the operational bandwidth in kilo-bits per seconds (Kbps) available for this SDP. The value is determined by the sum of the bandwidth of all the RSVP LSPs used by the SDP. |
Avail BW (Kbps) |
Indicates the bandwidth that is still free for booking by the SDP bindings on the SDP. |
Net-Domain |
Specifies the network-domain name configured on this SDP. The default value of this object is the default'network-domain. |
Egr Interface |
Indicates whether all the egress network interfaces that can carry traffic on this SDP are associated with the network-domain configured on this SDP. Not applicable — Indicates that there is no egress network interface that can carry traffic on this SDP. Consistent — Indicates that the network-domains for all the egress network interfaces that can carry traffic on this SDP are consistent. Inconsistent — Indicates that the network-domain for one or more egress network interfaces that can carry traffic on this SDP are inconsistent. |
Mixed LSP Mode |
Indicates whether the SDP is enabled to use mixed-mode-lsp. |
Active LSP Type |
Displays the LSP type that is currently active and in use to transport service packets. When multiple LSPs are configured under the SDP and enabled with the command mixed-mode-lsp, the active LSP could be one of the configured ones. It displays RSVP, if the LSP in use is of type RSVP LSP, LDP if the LSP in use is of type LDP LSP and BGP 3107, if LSP if of type RFC 3107 BGP Labeled route LSP. |
Revert Time |
Specifies the time to wait before reverting back from LDP to the configured LSPs, after having failed over to LDP. |
Revert Count Down |
Indicates the timer countdown before reverting back from LDP on this SDP. The timer countdown begins after the first configured LSP becomes active. |
Flags |
Displays all the conditions that affect the operating status of this SDP. |
Class Forwarding |
Indicates the admin state of class-based forwarding on this SDP. When the value is true, class-based forwarding is enabled. |
EnforceDSTELspFc |
Specifies whether service manager must validate with RSVP the support of the FC by the LSP. |
Default LSP |
Specifies the LSP ID that is used as a default when class-based forwarding is enabled on this SDP. This object must be set when enabling class-based forwarding. |
Multicast LSP |
Displays the LSP ID that all multicast traffic is forwarded on when class-based forwarding is enabled on this SDP. When this object has its default value, multicast traffic is forwarded on an LSP according to its forwarding class mapping. |
Number of SDPs |
The total number of SDPs displayed according to the criteria specified. |
sdp-using
Syntax
sdp-using [sdp-id[:vc-id] | far-end ip-address]
Context
show>service
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays services using SDP or far-end address options.
Parameters
- sdp-id
Displays only services bound to the specified SDP ID.
- vc-id
Specifies the virtual circuit identifier.
- far-end ip-address
Displays only services matching the specified far-end IP address.
Output
The following output is an example of service SDP information, and Output fields: SDP using describes the output fields.
Sample output*A:ALA-7210# show service sdp-using 300
===============================================================================
Service Destination Point (Sdp Id : 300)
===============================================================================
SvcId SdpId Type Far End Opr State I.Label E.Label
-------------------------------------------------------------------------------
1 300:1 Spok 10.0.0.13 Up 131071 131071
2 300:2 Spok 10.0.0.13 Up 131070 131070
100 300:100 Spok 10.0.0.13 Up 131069 131069
101 300:101 Spok 10.0.0.13 Up 131068 131068
-------------------------------------------------------------------------------
Number of SDPs : 4
===============================================================================
*A:ALA-7210#
Label | Description |
---|---|
Svc ID |
The service identifier. |
Sdp ID |
The SDP identifier. |
Type |
Type of SDP: spoke |
Far End |
The far end address of the SDP. |
Oper State |
The operational state of the service. |
Ingress Label |
The label used by the far-end device to send packets to this device in this service by this SDP. |
Egress Label |
The label used by this device to send packets to the far-end device in this service by this SDP. |
service-using
Syntax
service-using [sdp sdp-id] [b-vpls] [m-vpls] [sdp sdp-id] [customer customer-id]
Context
show>service
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays the services matching specified usage properties. If no optional parameters are specified, all services defined on the system are displayed.
Parameters
- epipe
Displays matching Epipe services.
- vpls
Displays matching VPLS instances.
- sdp sdp-id
Displays only services bound to the specified SDP ID.
- customer customer-id
Displays services only associated with the specified customer ID.
Output
The following output is an example of service information, and Output fields: service using describes the output fields.
Sample output*7210SAS>show>service# service-using customer 1
===============================================================================
Services Customer 1
===============================================================================
ServiceId Type Adm Opr CustomerId Service Name
-------------------------------------------------------------------------------
1 VPLS Up Up 1
2 VPLS Up Up 1
3 VPLS Up Up 1
4 VPLS Up Up 1
2147483648 IES Up Down 1 _tmnx_InternalIesService
2147483649 intVpls Up Down 1 _tmnx_InternalVplsService
-------------------------------------------------------------------------------
Matching Services : 6
-------------------------------------------------------------------------------
===============================================================================
*7210SAS>show>service#
Label | Description |
---|---|
Service Id |
The service identifier. |
Type |
Specifies the service type configured for the service ID. |
Adm |
The administrative state of the service. |
Opr |
The operating state of the service. |
CustomerID |
The ID of the customer who owns this service. |
Service name |
The name of the service. |
eth-ring
Syntax
eth-ring [status]
eth-ring [ring-index] hierarchy
eth-ring ring-index [path {a | b}]
Context
show
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays the Ethernet rings information.
Parameters
- status
Displays the status information of the Ethernet rings configured on the system.
- hierarchy
Displays Eth-ring hierarchical relationships.
- path {a | b}
Displays information related to the configured Ethernet rings.
- ring-index
Specifies the ring index of the Ethernet ring.
Output
The following outputs are examples of Ethernet ring information, and the associated tables describe the output fields.
Sample output, Sample for 7210 SAS-R6 and 7210 SAS-R12, Output fields: show Ethernet ring
Sample output for Ethernet ring status, Output fields: Ethernet ring status
*A:NS1015C0821>show# eth-ring 10
===============================================================================
Ethernet Ring 10 Information
===============================================================================
Description : (Not Specified)
Admin State : Down Oper State : Down
Node ID : 00:25:ba:03:48:04
Guard Time : 5 deciseconds RPL Node : rplNone
Max Revert Time : 300 seconds Time to Revert : N/A
CCM Hold Down Time : 0 centiseconds CCM Hold Up Time : 20 deciseconds
Compatible Version : 2
APS Tx PDU : N/A
Defect Status :
Sub-Ring Type : virtualLink Interconnect-ID : N/A
-------------------------------------------------------------------------------
Ethernet Ring Path Summary
-------------------------------------------------------------------------------
Path Port Raps-Tag Admin/Oper Type Fwd State
-------------------------------------------------------------------------------
a - - -/- - -
b - - -/- - -
===============================================================================
*A:NS1015C0821>show#
Sample for 7210 SAS-R6 and 7210 SAS-R12
*A:7210SAS>show# eth-ring
===============================================================================
Ethernet Rings (summary)
===============================================================================
Ring Int Admin Oper Paths Summary Path States
ID ID State State a b
-------------------------------------------------------------------------------
1 - Up Up a - 1/1/3 1 b - 1/1/1 1 B U
10 - Up Up a - 1/1/3 10 b - 1/1/1 10 B U
30 - Up Up a - 1/1/3 30 b - 1/1/1 30 B U
===============================================================================
Ethernet Ring Summary Legend: B - Blocked U - Unblocked
*A:7210SAS>show#
Label | Description |
---|---|
Description |
The ring description. |
Admin State |
Displays the administrative state. |
Oper State |
Displays the operational state. |
Node ID |
Displays the node identifier. |
Guard Time |
Displays the configured guard time. |
Max Revert time |
Displays the configured maximum revert time. |
CCM Hold down time |
Displays the configured CCM Hold down time. |
APS TX PDU |
Displays the APS TX PDU information. |
Defect Status |
Displays the defect status. |
RPL Node |
Displays the RPL node information. |
Time to revert |
Displays the configured time to revert. |
CCM Hold Up Time |
Displays the configured CCM Hold up time. |
Sub-Ring Type |
Displays the sub-ring type information, the sub-ring type can be virtual link or on-virtual link. |
Interconnect-ID |
Displays the interconnect ID. The ID can be a ring-index ID or VPLS service ID. |
Compatible Version |
Displays the Ethernet ring version information. |
*A:NS1015C0821>show# eth-ring status
===============================================================================
Ethernet Ring (Status information)
===============================================================================
Ring Admin Oper Path Information MEP Information
ID State State Path Tag State Ctrl-MEP CC-Intvl Defects
-------------------------------------------------------------------------------
1 Up Up a - 1/1/1 100 Up Yes 100ms -----
b - 1/1/2 100 Up Yes 100ms -----
10 Down Down a - N/A - - - -----
b - N/A - - - -----
===============================================================================
Ethernet Tunnel MEP Defect Legend:
R = Rdi, M = MacStatus, C = RemoteCCM, E = ErrorCCM, X = XconCCM
*A:NS1015C0821>show#
Label | Description |
---|---|
Ring Id |
The ring identifier |
Admin State |
Displays the administrative state |
Oper State |
Displays the operational state |
Path Information |
|
Path |
Displays the path information |
Tag |
Displays the tag information |
State |
Displays the state of the path |
MEP Information |
|
Ctrl-MEP |
Displays the Ctrl-MEP information |
CC-Intvl |
Displays the Ctrl-Interval information |
Defects |
Displays the defects |
pw-routing
Syntax
pw-routing {local-prefix | static-route | paths | all}
pw-routing route-table [all-routes]
pw-routing route-table summary
Context
show>service
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays PW routing information at this 7210 node.
Parameters
- local-prefix | static-route | paths | all
Shows details of the T-PE prefixes configured on this node, static routes from this node, explicit PW paths configured on this node, or all of these.
- route-table [all-routes]
Displays the PW routing table on this node. If all-routes is specified, the full routing table is displayed.
- route-table summary
Displays a summary of the PW routing table for this node.
Output
The following output is an example of PW routing information.
Sample output*A:Dut-C# show service pw-routing local-prefix
===============================================================================
Service PW Routing Information
===============================================================================
===============================================================================
Service PW Routing Local-Prefix RD Information
===============================================================================
Local-Prefix Route-Dist Community Adv-Bgp
-------------------------------------------------------------------------------
3:10.20.1.3 100:3 100:3 enabled
100:4 100:4 enabled
-------------------------------------------------------------------------------
Local-Prefix Entries found: 1
===============================================================================
===============================================================================
*A:Dut-C# show service pw-routing static-route
===============================================================================
Service PW Routing Information
===============================================================================
=========================================================
Service PW Routing Static-Route Information
=========================================================
Prefix Next-Hop
---------------------------------------------------------
6:10.20.1.6/64 10.20.1.5
---------------------------------------------------------
Static Route Entries found: 1
=========================================================
===============================================================================
*A:Dut-C# show service pw-routing paths
===============================================================================
Service PW Routing Information
===============================================================================
=============================================================
Service PW Routing Path Information
=============================================================
Path Adm Hop IP Address
-------------------------------------------------------------
path1_to_F up 1 10.20.1.5
2 10.20.1.2
path1_to_F2 up 1 10.20.1.2
2 10.20.1.5
-------------------------------------------------------------
Path Entries found: 2
=============================================================
===============================================================================
*A:Dut-C# show service pw-routing all
===============================================================================
Service PW Routing Information
===============================================================================
SPE-Address : 3:10.20.1.3
Boot Timer : 10 secs
Boot Timer Remain : 0 secs
Retry Timer : 30 secs
Retry Count : 30
===============================================================================
Service PW Routing Local-Prefix RD Information
===============================================================================
Local-Prefix Route-Dist Community Adv-Bgp
-------------------------------------------------------------------------------
3:10.20.1.3 100:3 100:3 enabled
100:4 100:4 enabled
-------------------------------------------------------------------------------
Local-Prefix Entries found: 1
===============================================================================
=========================================================
Service PW Routing Static-Route Information
=========================================================
Prefix Next-Hop
---------------------------------------------------------
6:10.20.1.6/64 10.20.1.5
---------------------------------------------------------
Static Route Entries found: 1
=========================================================
=============================================================
Service PW Routing Path Information
=============================================================
Path Adm Hop IP Address
-------------------------------------------------------------
path1_to_F up 1 10.20.1.5
2 10.20.1.2
path1_to_F2 up 1 10.20.1.2
2 10.20.1.5
-------------------------------------------------------------
Path Entries found: 2
=============================================================
===============================================================================
*A:Dut-C# show service pw-routing route-table all-routes
===============================================================================
Service PW L2 Routing Information
===============================================================================
AII-Type2/Prefix-Len Next-Hop Owner Age
Route-Distinguisher Community Best
-------------------------------------------------------------------------------
3:10.20.1.3:0/64 10.20.1.3 local 00h32m08s
0:0 0:0 yes
3:10.20.1.3:1/96 10.20.1.3 host 00h32m08s
0:0 0:0 yes
3:10.20.1.3:2/96 10.20.1.3 host 00h32m08s
0:0 0:0 yes
3:10.20.1.3:3/96 10.20.1.3 host 00h32m08s
0:0 0:0 yes
3:10.20.1.3:4/96 10.20.1.3 host 00h32m08s
0:0 0:0 yes
3:10.20.1.3:5/96 10.20.1.3 host 00h32m08s
0:0 0:0 yes
3:10.20.1.3:6/96 10.20.1.3 host 00h32m08s
0:0 0:0 yes
3:10.20.1.3:7/96 10.20.1.3 host 00h32m08s
0:0 0:0 yes
3:10.20.1.3:8/96 10.20.1.3 host 00h32m08s
0:0 0:0 yes
3:10.20.1.3:9/96 10.20.1.3 host 00h32m08s
0:0 0:0 yes
3:10.20.1.3:10/96 10.20.1.3 host 00h32m07s
0:0 0:0 yes
6:10.20.1.6:0/64 10.20.1.5 static 00h07m33s
0:0 0:0 yes
6:10.20.1.6:0/64 10.20.1.5 bgp 00h31m34s
100:6 100:6 no
-------------------------------------------------------------------------------
Entries found: 13
===============================================================================
*A:Dut-C# show service pw-routing route-table summary
========================================
Service PW L2 Routing Summary
========================================
Source Active
----------------------------------------
BGP 1
Static 1
Host 10
Local 3
----------------------------------------
Total 15
========================================
pw-template
Syntax
pw-template
Context
show>service
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays information about PW templates.
Output
The following output is an example of PW template information.
Sample output*A:Dut-B# show service pw-template 1
=======================================================================
PW Template Information
=======================================================================
PW Tmpl Id : 1
Use Provisioned Sdp : enabled VcType : vlan
Acctg Policy : default Collect Stats : disabled
Mac-Learning : enabled Mac-Ageing : enabled
Discard Unkn Src : disabled Limit MacMove : blockable
Mac-Pinning : disabled Vlan VcTag : 4095
MAC Address Limit : no limit Rest Prot Src Mac: disabled
Auto Learn Mac Prot : disabled RestProtSrcMacAct: disable
Block On Peer Fault : disabled
SHG
Name :
Description : (Not Specified)
Rest Prot Src Mac : disabled Rest Unprot Dst : disabled
Auto Learn Mac Prot : disabled RestProtSrcMacAct: disable
Egress
Mac FilterId : none Ip FilterId : none
Ipv6 FilterId : none QoS NetPlcyId : none
Port RedirectQGrp : none Instance Id : none
Ingress
Mac FilterId : none Ip FilterId : none
Ipv6 FilterId : none QoS NetPlcyId : none
Fp RedirectQGrp : none Instance Id : none
IGMP
Fast Leave : disabled Import Plcy : none
Last Memb Intvl : 10 deci-secs Max Nbr Grps : 0
Send Queries : disabled
Version : 3
Force VlanVc Fwd : disabled Control Word : disabled
Hash Label : disabled Hash Lbl Sig Cap : disabled
Last Changed : 02/12/2013 22:11:49
-----------------------------------------------------------------------
Included SDP-Groups
-----------------------------------------------------------------------
red
-----------------------------------------------------------------------
saii-type2-using
Syntax
saii-type2-using global-id[:prefix[:ac-id]]
Context
show>service
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays the SDP used by a spoke-SDP FEC with a specified FEC129 Type 2 SAII.
Parameters
- global-id[:prefix[:ac-id]]
Specifies the switch-point information using SAII-Type2.
Output
The following output is an example of information for a spoke-SDP FEC using FEC129 Type 2 SAII.
Sample output*A:Dut-E# show service saii-type2-using 3:10.20.1.3:1
===================================================================
Service Switch-Point Information
===================================================================
SvcId Oper-SdpBind SAII-Type2
-------------------------------------------------------------------
2147483598 17407:4294967195 3:10.20.1.3:1
-------------------------------------------------------------------
Entries found: 1
===================================================================
spoke-sdp-fec-using
Syntax
spoke-sdp-fec-using [spoke-sdp-fec-id <spoke-sdp-fec-id>] [saii-type2 <global-id:prefix:ac-id>] [taii-type2 <global-id:prefix:ac-id>] [path <name>] [expired] taii-type2-using global-id[:prefix[:ac-id]]
Context
show>service
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays the SDPs used by spoke-SDP FECs at this node.
Output
The following output is an example of information for spoke-SDP FECs using SDPs.
Sample output*A:Dut-C# show service spoke-sdp-fec-using
===============================================================================
Service Spoke-SDP-Fec Information
===============================================================================
SvcId SpokeSdpFec Oper-SdpBind SAII-Type2
Path TAII-Type2
-------------------------------------------------------------------------------
1 1 17407:4294967245 3:10.20.1.3:1
n/a 6:10.20.1.6:1
2 2 17407:4294967247 3:10.20.1.3:2
n/a 6:10.20.1.6:2
3 3 17407:4294967248 3:10.20.1.3:3
n/a 6:10.20.1.6:3
4 4 17407:4294967249 3:10.20.1.3:4
n/a 6:10.20.1.6:4
5 5 17407:4294967250 3:10.20.1.3:5
n/a 6:10.20.1.6:5
6 6 17407:4294967251 3:10.20.1.3:6
n/a 6:10.20.1.6:6
7 7 17407:4294967252 3:10.20.1.3:7
n/a 6:10.20.1.6:7
8 8 17407:4294967253 3:10.20.1.3:8
n/a 6:10.20.1.6:8
9 9 17407:4294967254 3:10.20.1.3:9
n/a 6:10.20.1.6:9
10 10 17407:4294967255 3:10.20.1.3:10
n/a 6:10.20.1.6:10
-------------------------------------------------------------------------------
Entries found: 10
===============================================================================
taii-type2-using
Syntax
taii-type2-using global-id[:prefix[:ac-id]]
Context
show>service
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays switch-point information using TAII.
Parameters
- global-id[:prefix[:ac-id]]
Specifies the switch-point information using SAII-Type2.
Output
The following output is an example of information for switch-point using TAII.
Sample output*A:Dut-E# show service taii-type2-using 6:10.20.1.6:1
===================================================================
Service Switch-Point Information
===================================================================
SvcId Oper-SdpBind TAII-Type2
-------------------------------------------------------------------
2147483598 17407:4294967195 6:10.20.1.6:1
-------------------------------------------------------------------
Entries found: 1
=====================================================
ETH-CFM show commands
eth-cfm
Syntax
eth-cfm
Context
show
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays ETH-CFM information.
eth-tunnel
Syntax
eth-tunnel
Context
show
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
association
Syntax
association [ma-index] [detail]
Context
show>eth-cfm
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays eth-cfm association information.
Parameters
- ma-index
Specifies the maintenance association (MA) index.
- detail
Displays more information for the ETH-CFM association.
Output
The following output is an example of Ethernet CFM association information, and Output fields: ETH CFM association describes the output fields.
Sample outputA:dut-b# show eth-cfm association
======================================================================
CFM Association Table
======================================================================
Md-index Ma-index Name CCM-interval Bridge-id
----------------------------------------------------------------------
1 1 a1 1 1
1 2 a2 1 2
2 1 a1 1 2
2 2 a2 1 1
======================================================================
A:dut-b#
Label | Description |
---|---|
Md-index |
Displays the maintenance domain (MD) index. |
Ma-index |
Displays the maintenance association (MA) index. |
Name |
Displays the part of the maintenance association identifier which is unique within the maintenance domain name. |
CCM-interval |
Displays the CCM transmission interval for all MEPs in the association. |
Bridge-id |
Displays the bridge-identifier value for the domain association. |
MHF Creation |
Displays the MIP half function (MHF) for the association. |
Primary VLAN |
Displays the primary bridge-identifier VLAN ID. |
Num Vids |
Displays the number of VIDs associated with the VLAN. |
Remote Mep Id |
Displays the remote maintenance association endpoint (MEP) identifier. |
cfm-stack-table
Syntax
cfm-stack-table [{all-ports}] [level <0..7>] [direction <down>]
cfm-stack-table port <port-id> [vlan <qtag[.qtag]>] [level <0..7>] [direction <down>]
cfm-stack-table facility [{all-ports | all-lags | all-lag-ports | all-tunnel-meps | all-router-interfaces}] [level <0..7>] [direction <down>]
cfm-stack-table facility lag <id> [tunnel <1..4094>] [level <0..7>] [direction <down>]
cfm-stack-table facility port <id> [level <0..7>] [direction <down>]
cfm-stack-table facility router-interface <ip-int-name> [level <0..7>] [direction <down>]
Context
show>eth-cfm
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Parameters
- port port-id
Displays the bridge port or aggregated port on which MEPs or MHFs are configured.
- vlan vlan-id
Displays the associated VLAN ID.
- level
Displays the MD level of the maintenance point.
- direction down
Displays the direction in which the MP faces on the bridge port.
Output
The following output is an example of Ethernet CFM stack table information, and Output fields: ETH-CFM CFM stack table describes the output fields.
Sample output
*A:7210SAS>show>eth-cfm# cfm-stack-table
========================================================================
CFM SAP Stack Table
========================================================================
Sap Level Dir Md-index Ma-index Mep-id Mac-address
------------------------------------------------------------------------
1/1/18:100 7 Up 7 100 1 00:25:ba:0d:21:13
========================================================================
========================================================================
CFM Ethernet Tunnel Stack Table
========================================================================
Eth-tunnel Level Dir Md-index Ma-index Mep-id Mac-address
------------------------------------------------------------------------
No Matching Entries
========================================================================
========================================================================
CFM SDP Stack Table
========================================================================
Sdp Level Dir Md-index Ma-index Mep-id Mac-address
------------------------------------------------------------------------
No Matching Entries
========================================================================
========================================================================
CFM Virtual Stack Table
========================================================================
Service Level Dir Md-index Ma-index Mep-id Mac-address
------------------------------------------------------------------------
No Matching Entries
========================================================================
*A:7210SAS>show>eth-cfm#
Sample for 7210 SAS-R6 and 7210 SAS-R12 IMMv2:
*A:7210SAS>show>eth-cfm# cfm-stack-table
===============================================================================
CFM SAP Primary VLAN Stack Table
===============================================================================
Sap
Primary VlanId Lvl Dir Md-index Ma-index MepId Mac-address Defect
-------------------------------------------------------------------------------
lag-2:1
200 7 Both 10 1 MIP 00:11:11:11:11:11 ------
lag-2:2
200 7 Both 10 2 MIP 00:11:11:11:11:12 ------
lag-2:3
*A:7210SAS>show>
Label | Description |
---|---|
Sap |
Displays associated SAP IDs |
Sdp |
Displays the SDP binding for the bridge |
Level Dir |
Displays the MD level of the maintenance point |
Md-index |
Displays the maintenance domain (MD) index |
Ma-index |
Displays the maintenance association (MA) index |
Mep-id |
Displays the integer that is unique among all the MEPs in the same MA |
Mac-address |
Displays the MAC address of the MP |
domain
Syntax
domain [md-index] [association ma-index | all-associations] [detail]
Context
show>eth-cfm
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays domain information.
Parameters
- md-index
Displays the index of the MD to which the MP is associated, or 0, if none.
- association ma-index
Displays the index to which the MP is associated, or 0, if none.
- all-associations
Displays all associations to the MD.
- detail
Displays detailed domain information.
Output
The following output is an example of Ethernet CFM domain information, and Output fields: ETH-CFM domain describes the output fields.
Sample outputA:dut-b# show eth-cfm domain
==============================================================================
CFM Domain Table
==============================================================================
Md-index Level Name Format
------------------------------------------------------------------------------
1 6 d1 charString
2 7 d2 charString
==============================================================================
A:dut-b#
Label | Description |
---|---|
Md-index |
Displays the Maintenance Domain (MD) index value |
Level |
Displays an integer identifying the Maintenance Domain Level (MD Level). Higher numbers correspond to higher Maintenance Domains, those with the greatest physical reach, with the highest values for customers' CFM PDUs. Lower numbers correspond to lower Maintenance Domains, those with more limited physical reach, with the lowest values for CFM PDUs protecting single bridges or physical links. |
Name |
Displays a generic Maintenance Domain (MD) name |
Format |
Displays the type of the Maintenance Domain (MD) name. Values include dns, mac, and string. |
mep
Syntax
mep mep-id domain md-index association ma-index [loopback] [linktrace]
mep mep-id domain md-index association ma-index remote-mepid mep-id | all-remote-mepids
mep mep-id domain md-index association ma-index eth-test-results [remote-peer mac-address]
mep mep-id domain md-index association ma-index one-way-delay-test [remote-peer mac-address]
mepmep-id domain md-index association ma-index two-way-delay-test [remote-peer mac-address]
mep mep-id domain md-index association ma-index two-way-slm-test [remote-peer macaddress]
Context
show>eth-cfm
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays Maintenance Endpoint (MEP) information.
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.
Parameters
- mep-id
Displays the integer that is unique among all the MEPs in the same MA.
- domain md-index
Displays the index of the MD to which the MP is associated, or 0, if none.
- association ma-index
Displays the index to which the MP is associated, or 0, if none.
- loopback
Displays loopback information for the specified MEP.
- linktrace
Displays linktrace information for the specified MEP.
- remote-mepid mep-id
Includes specified remote mep-id information for specified the MEP.
- all-remote-mepids
Includes all remote mep-id information for the specified MEP.
- eth-test-results
Includes eth-test-result information for the specified MEP.
- one-way-delay-test
Includes one-way-delay-test information for the specified MEP.
- two-way-delay-test
Includes two-way-delay-test information for the specified MEP.
- two-way-slm-test
Includes two-way-slm-test information for the specified MEP.
- remote-peer mac-address
Includes specified remote mep-id information for the specified MEP.
Output
The following outputs are examples of MEP information, and Output fields: MEP describes the output fields.
Sample outputA:dut-b# show eth-cfm mep 1 domain 1 association 1 linktrace
-------------------------------------------------------------------------------
Mep Information
-------------------------------------------------------------------------------
Md-index : 1 Direction : Down
Ma-index : 1 Admin : Enabled
MepId : 1 CCM-Enable : Enabled
IfIndex : 35946496 PrimaryVid : 1
FngState : fngReset ControlMep : False
LowestDefectPri : macRemErrXcon HighestDefect : none
Defect Flags : None
Mac Address : 00:25:ba:01:c3:6a CcmLtmPriority : 7
CcmTx : 0 CcmSequenceErr : 0
Eth-1Dm Threshold : 3(sec)
Eth-Ais: : Disabled
Eth-Tst: : Disabled
CcmLastFailure Frame:
None
XconCcmFailure Frame:
None
-------------------------------------------------------------------------------
Mep Linktrace Message Information
-------------------------------------------------------------------------------
LtRxUnexplained : 0 LtNextSequence : 2
LtStatus : False LtResult : False
TargIsMepId : False TargMepId : 0
TargMac : 00:00:00:00:00:00 TTL : 64
EgressId : 00:00:00:25:ba:01:c3:6a SequenceNum : 1
LtFlags : useFDBonly
-------------------------------------------------------------------------------
Mep Linktrace Replies
-------------------------------------------------------------------------------
SequenceNum : 1 ReceiveOrder : 1
Ttl : 63 Forwarded : False
LastEgressId : 00:00:00:25:ba:01:c3:6a TerminalMep : True
NextEgressId : 00:00:00:25:ba:00:5e:bf Relay : rlyHit
ChassisIdSubType : unknown value (0)
ChassisId:
None
ManAddressDomain:
None
ManAddress:
None
IngressMac : 00:25:ba:00:5e:bf Ingress Action : ingOk
IngrPortIdSubType : unknown value (0)
IngressPortId:
None
EgressMac : 00:00:00:00:00:00 Egress Action : egrNoTlv
EgrPortIdSubType : unknown value (0)
EgressPortId:
None
Org Specific TLV:
None
A:dut-b#
A:dut-b#
A:dut-b# show eth-cfm mep 1 domain 1 association 1 loopback
-------------------------------------------------------------------------------
Mep Information
-------------------------------------------------------------------------------
Md-index : 1 Direction : Down
Ma-index : 1 Admin : Enabled
MepId : 1 CCM-Enable : Enabled
IfIndex : 35946496 PrimaryVid : 1
FngState : fngReset ControlMep : False
LowestDefectPri : macRemErrXcon HighestDefect : none
Defect Flags : None
Mac Address : 00:25:ba:01:c3:6a CcmLtmPriority : 7
CcmTx : 0 CcmSequenceErr : 0
Eth-1Dm Threshold : 3(sec)
Eth-Ais: : Disabled
Eth-Tst: : Disabled
CcmLastFailure Frame:
None
XconCcmFailure Frame:
None
-------------------------------------------------------------------------------
Mep Loopback Information
-------------------------------------------------------------------------------
LbRxReply : 1 LbRxBadOrder : 0
LbRxBadMsdu : 0 LbTxReply : 0
LbSequence : 2 LbNextSequence : 2
LbStatus : False LbResultOk : True
DestIsMepId : False DestMepId : 0
DestMac : 00:00:00:00:00:00 SendCount : 0
VlanDropEnable : True VlanPriority : 7
Data TLV:
None
A:dut-b#
*A:dut-b# show eth-cfm mep 1 domain 4 association 4 two-way-delay-test remote-
peer 00:25:ba:00:5e:bf
==================================================================
Eth CFM Two-way Delay Test Result Table
==================================================================
Peer Mac Addr Delay (us) Delay Variation (us)
------------------------------------------------------------------
00:25:ba:00:5e:bf 507 507
==================================================================
*A:dut-b#
*A:dut-b# show eth-cfm mep 1 domain 4 association 4 two-way-delay-test
==================================================================
Eth CFM Two-way Delay Test Result Table
==================================================================
Peer Mac Addr Delay (us) Delay Variation (us)
------------------------------------------------------------------
00:25:ba:00:5e:bf 507 507
==================================================================
*A:dut-b#
*A:dut-a# show eth-cfm mep 2 domain 4 association 4 eth-test-results remote-
peer 00:25:ba:01:c3:6a
==============================================================
Eth CFM ETH-Test Result Table
==============================================================
Current Accumulate
FrameCount ErrBits ErrBits
Peer Mac Addr ByteCount CrcErrs CrcErrs
--------------------------------------------------------------
00:25:ba:01:c3:6a 6 0 0
384 0 0
==============================================================
*A:dut-a#
*A:dut-a# show eth-cfm mep 2 domain 4 association 4 eth-test-results
==============================================================
Eth CFM ETH-Test Result Table
==============================================================
Current Accumulate
FrameCount ErrBits ErrBits
Peer Mac Addr ByteCount CrcErrs CrcErrs
--------------------------------------------------------------
00:25:ba:01:c3:6a 6 0 0
384 0 0
==============================================================
*A:dut-a# show eth-cfm mep 2 domain 4 association 4 one-way-delay-test remote-
peer 00:25:ba:01:c3:6a
==================================================================
Eth CFM One-way Delay Test Result Table
==================================================================
Peer Mac Addr Delay (us) Delay Variation (us)
------------------------------------------------------------------
00:25:ba:01:c3:6a 402 402
==================================================================
*A:dut-a#
*A:dut-a# show eth-cfm mep 2 domain 4 association 4 one-way-delay-test
==================================================================
Eth CFM One-way Delay Test Result Table
==================================================================
Peer Mac Addr Delay (us) Delay Variation (us)
------------------------------------------------------------------
00:25:ba:01:c3:6a 402 402
==================================================================
*A:dut-a#
Sample output for two-way-slm-test
*A:7210SAS# show eth-cfm mep 1 domain 7 association 100 two-way-slm-test
===============================================================================
Eth CFM Two-way SLM Test Result Table (Test-id: 1)
===============================================================================
Peer Mac Addr Remote MEP Count In Loss Out Loss Unack
-------------------------------------------------------------------------------
00:25:ba:0d:1e:12 2 1 0 0 0
===============================================================================
*A:7210SAS#
Label | Description |
---|---|
Mep Information |
|
Md-index |
Displays the MD index of the domain. |
Direction |
Displays the direction of OAMPDU transmission. |
Ma-index |
Displays the MA index of the association. |
Admin |
Displays the administrative status of the MEP. |
MepId |
Displays the MEP identifier. |
CCM-Enable |
Displays the status of the CCM (enabled or disabled). |
IfIndex |
Displays the index of the interface. |
PrimaryVid |
Displays the identifier of the primary VLAN. |
FngState |
Indicates the different states of the Fault Notification Generator. |
LowestDefectPri |
Displays the lowest priority defect (a configured value) that is allowed to generate a fault alarm. |
HighestDefect |
Identifies the highest defect that is present (for example, if defRDICCM and defXconCCM are present, the highest defect is defXconCCM). |
Defect Flags |
Displays the number of defect flags. |
Mac Address |
Displays the MAC address of the MEP. |
CcmLtmPriority |
Displays the priority value transmitted in the linktrace messages (LTM)s and CCMs for this MEP. The MEP must be configured on a VLAN. |
CcmTx |
Displays the number of Continuity Check Messages (CCM) sent. The count is taken from the last polling interval (every 10 s). |
CcmSequenceErr |
Displays the number of CCM errors. |
Eth-1DM Threshold |
Displays the one-way-delay threshold value. |
Eth-Ais |
Displays the state of the ETH-AIS test (enabled or disabled). |
Eth-Test |
Displays the state of the ETH-Test (enabled or disabled). |
CcmLastFailure Frame |
Displays the frame that caused the last CCM failure. |
XconCcmFailure Frame |
Displays the frame that caused the XconCCMFailure. |
Mep Loopback Information |
|
LbRxReply |
Displays the number of received loopback (LB) replies. |
LbRxBadOrder |
Displays the number of received loopback messages that are in a bad order. |
LbRxBadMsdu |
Displays the number of loopback replies that have been received with the wrong destination MAC address (MSDU = MAC Service Data Unit). |
LbTxReply |
Displays the number of loopback replies transmitted out this MEP. |
LbTxReply (Total) |
Displays the total number of LBRs (loopback replies) transmitted from this MEP. |
LbTxReplyNoTLV |
Displays the number of LBRs (loopback replies) transmitted from this MEP with no TLV. Because only LBMs with no TLVs are used for throughput testing, the LbTxReply (Total), LbTxReplyNoTLV, and LbTxReplyWithTLV counters can help debug problems if throughput testing is not working. |
LbTxReplyWithTLV |
Displays the number of LBRs (loopback replies) transmitted from this MEP with TLV. |
LbSequence |
Displays the sequence number in the loopback message. |
LbNextSequence |
Displays the next loopback sequence. |
LbStatus |
Displays the loopback status as True or False: True — loopback is in progress False — no loopback is in progress |
LbResultOk |
Displays the result of the loopback test. |
DestIsMepId |
Identifies whether the destination interface has a MEP-ID (true or false). |
DestMepId |
Displays the MEP-ID of the destination interface. |
DestMac |
Displays the MAC address of the destination interface. |
SendCount |
Indicates the number of loopback messages sent. |
VlanDropEnable |
Identifies whether the VLAN drop is enabled (true or false). |
VlanPriority |
Displays the VLAN priority. |
Data TLV |
Displays the data TLV information. |
Mep Linktrace Message Information |
|
LtRxUnexplained |
Displays the number of unexplained linktrace messages (LTM) that have been received. |
LtNextSequence |
Displays the sequence number of the next linktrace message. |
LtStatus |
Displays the status of the linktrace. |
LtResult |
Displays the result of the linktrace. |
TargIsMepId |
Identifies whether the target interface has a MEP-ID (true or false). |
TargMepId |
Displays the MEP-ID of the target interface. |
TargMac |
Displays the MAC address of the target interface. |
TTL |
Displays the TTL value. |
EgressId |
Displays the egress ID of the linktrace message. |
SequenceNum |
Displays the sequence number of the linktrace message. |
LtFlags |
Displays the linktrace flags. |
Mep Linktrace Replies |
|
SequenceNum |
Displays the sequence number returned by a previous transmit linktrace message, indicating which linktrace message response will be returned. |
ReceiveOrder |
Displays the order in which the linktrace initiator received the linktrace replies. |
Ttl |
Displays the TTL field value for a returned linktrace reply. |
Forwarded |
Indicates whether the linktrace message was forwarded by the responding MEP. |
LastEgressId |
Displays the last egress identifier returned in the linktrace reply egress identifier TLV of the linktrace reply. The last egress identifier identifies the MEP linktrace initiator that initiated, or the linktrace responder that forwarded, the linktrace message for which this linktrace reply is the response. This is the same value as the egress identifier TLV of that linktrace message. |
TerminalMep |
Indicates whether the forwarded linktrace message reached a MEP enclosing its MA. |
NextEgressId |
Displays the next egress identifier returned in the linktrace reply egress identifier TLV of the linktrace reply. The next egress identifier identifies the linktrace responder that transmitted this linktrace reply and can forward the linktrace message to the next hop. This is the same value as the egress identifier TLV of the forwarded linktrace message, if any. |
Relay |
Displays the value returned in the Relay Action field. |
ChassisIdSubType |
Displays the format of the chassis ID returned in the Sender ID TLV of the linktrace reply, if any. This value is meaningless if the chassis ID has a length of 0. |
ChassisId |
Displays the chassis ID returned in the Sender ID TLV of the linktrace reply, if any. The format is determined by the value of the ChassisIdSubType. |
ManAddressDomain |
Displays the TDomain that identifies the type and format of the related ManAddress, used to access the SNMP agent of the system transmitting the linktrace reply. Received in the linktrace reply Sender ID TLV from that system. |
ManAddress |
Displays the TAddress that can be used to access the SNMP agent of the system transmitting the CCM. Received in the CCM Sender ID TLV from that system. |
IngressMac |
Displays the MAC address returned in the ingress MAC address field. |
Ingress Action |
Displays the value returned in the Ingress Action field of the linktrace message. |
IngressPortIdSubType |
Displays the format of the ingress port ID. |
IngressPortId |
Displays the ingress port ID; the format is determined by the value of the IngressPortIdSubType. |
EgressMac |
Displays the MAC address returned in the egress MAC address field. |
Egress Action |
Displays the value returned in the Egress Action field of the linktrace message. |
EgressPortIdSubType |
Displays the format of the egress port ID. |
EgressPortId |
Displays the egress port ID; the format is determined by the value of the EgressPortIDSubType. |
Org Specific TLV |
Displays all organization-specific TLVs returned in the linktrace reply, if any. Includes all octets including and following the TLV length field of each TLV, concatenated. |
Eth-Test |
|
Peer Mac Addr |
Displays the MAC address of the peer (remote) entity. |
FrameCount |
Displays the number of test frames sent between the MEP and the peer entity. |
ByteCount |
Displays the number of bytes sent between the MEP and the peer entity. |
Current ErrBits |
Displays the number of bit errors in the current test. |
Current CrcErrs |
Displays the number of CRC errors in the current test. |
Accumulate ErrBits |
Displays the accumulated number of bit errors in the current test. |
Accumulate CrcErrs |
Displays the accumulated number of CRC errors in the current test. |
Delay Measurement Test |
|
Peer Mac Addr |
Displays the MAC address of the peer (remote) entity. |
Delay (us) |
Displays the measured delay (in microseconds) for the DM test. |
Delay Variation (us) |
Displays the measured delay variation (in microseconds) for the DV test. |
mip
Syntax
mip
Context
show>eth-cfm>mip
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays Maintenance Intermediate Point (MIP) information.
Output
The following output is an example of MIP information, and Output fields: MIP describes the output fields.
Sample output*A:7210SAS# show eth-cfm mip
==========================================================================
CFM SAP MIP Table
==========================================================================
Sap Mip-Enabled Mip Mac Address
--------------------------------------------------------------------------
1/1/16 yes 00:a1:b1:c1:d1:e1
==========================================================================
==========================================================================
CFM SDP MIP Table
==========================================================================
Sdp Mip-Enabled Mip Mac Address
--------------------------------------------------------------------------
456:123 yes 00:a2:b2:c2:d2:e2
==========================================================================
*A:7210SAS#
Label | Description |
---|---|
Mip-Enabled |
Displays the state of the MIP service |
Mip Mac Address |
Displays the MAC address of the MIP |
connection-profile
Syntax
connection-profile [conn-prof-id] [associations]
Context
show
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays connection profile information.
Parameters
- conn-prof-id
Specifies the connection profile ID.
- associations
Displays the SAP and the service ID that use this connection profile.
Output
The following outputs are examples of connection profile information, and Output fields: connection profile describes the output fields.
Sample output*7210SAS>show# connection-profile
===============================================================================
Connection Profile Summary Information
===============================================================================
CP Index Number of HasRange
Members
-------------------------------------------------------------------------------
1 0 Yes
2 0 Yes
3 0 Yes
5 0 Yes
6 0 Yes
100 0 Yes
200 0 Yes
300 0 Yes
400 0 Yes
500 0 Yes
600 0 Yes
700 0 Yes
800 0 Yes
900 0 Yes
===============================================================================
*7210SAS>show#
Sample output for connection-profile associations
*A:7210SAS>show# connection-profile associations
===============================================================================
Connection Profile Summary Information
===============================================================================
CP Index Number of HasRange
Members
-------------------------------------------------------------------------------
1 0 No
===============================================================================
*A:7210SAS>show#
Label | Description |
---|---|
CP Index |
Identifies the connection-profile. |
Number of Members |
Indicates the number of ATM connection profile members not applicable for 7210 SAS. |
HasRange |
Indicates whether VLAN range is configured. |
Tools perform commands
tools
Syntax
tools
Context
root
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
Commands in this context enable tools for debugging purposes.
Parameters
- dump
Enables dump tools for the various protocols.
- perform
Enables tools to perform specific tasks.
perform
Syntax
perform
Context
tools
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
Commands in this context enable tools to perform specific tasks.
service
Syntax
service
Context
tools>perform
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
Commands in this context configure tools for services.
id
Syntax
id service-id
Context
tools>perform>service
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configured tools for a specific service.
Parameters
- service-id
Specifies an existing service ID.
endpoint
Syntax
endpoint endpoint-name
Context
tools>perform>service>id
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configures tools for a specific VLL service endpoint.
Parameters
- endpoint-name
Specifies an existing VLL service endpoint name.
force-switchover
Syntax
force-switchover sdp-id:vc-id
no force-switchover
force-switchover spoke-sdp-fec [1..4294967295]
Context
tools>perform>service>id>endpoint
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command forces a switch of the active spoke-SDP for the specified service.
Parameters
- sdp-id:vc-id
Specifies an existing spoke-SDP for the service.
- spoke-sdp-fec spoke-sdp-fec-id
The spoke-sdp-fec-id for a FEC129 AII Type 2 spoke-sdp. This parameter and sdp:vc-id used for a FEC 128 spoke-sdp are mutually exclusive.
Sample output
*A:Dut-B# show service id 1 endpoint =============================================================================== Service 1 endpoints =============================================================================== Endpoint name : mcep-t1 Description : (Not Specified) Revert time : 0 Act Hold Delay : 0 Ignore Standby Signaling : false Suppress Standby Signaling : false Block On Mesh Fail : true Multi-Chassis Endpoint : 1 MC Endpoint Peer Addr : 10.1.1.3 Psv Mode Active : No Tx Active : 221:1(forced) Tx Active Up Time : 0d 00:00:17 Revert Time Count Down : N/A Tx Active Change Count : 6 Last Tx Active Change : 02/14/2009 00:17:32 ------------------------------------------------------------------------------- Members ------------------------------------------------------------------------------- Spoke-sdp: 221:1 Prec:1 Oper Status: Up Spoke-sdp: 231:1 Prec:2 Oper Status: Up ================================================================================ *A:Dut-B#
eval-pw-template
Syntax
eval-pw-template
Context
tools>perform>service
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command reevaluates the pseudowire template policy.
Parameters
- policy-id
Specifies the pseudowire template policy.
eval-expired-fec
Syntax
eval-expired-fec spoke-sdp-fec-id
eval-expired-fec all
Context
tools>perform>service>pw-routing
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command resets the retry counter and retry timer for the specified spoke-SDP and attempts to reestablish the spoke-SDP.
spoke-sdp-fec-release
Syntax
spoke-sdp-fec-release global-id[:prefix[:ac-id]]
Context
tools>perform>service
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command clears the MS-PW bindings associated with particular SAII or TAII on an S-PE.