Services overview

This chapter provides an overview of the 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C subscriber services, service model, and service entities. Additional information about the individual subscriber services supported on different 7210 SAS platforms and their configuration options 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.

On the 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T platforms, 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. It cannot support distributed services using MPLS uplinks.

On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C platforms, services can provide Layer 2/bridged service or Layer 3/IP routed connectivity between a service access point (SAP) on one router and another SAP (which is where traffic enters and exits the service) on the same (local) router or another router (distributed). The use of either MPLS uplinks or Ethernet uplinks is supported.

The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C support both local and distributed service. A distributed service spans more than one router. Distributed services use service distribution points (SDPs) to direct traffic through a service tunnel to another Nokia router. 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 on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

The 7210 SAS-D,7210 SAS-Dxp, and 7210 SAS-K 2F1C2T offer the following types of subscriber services, described in more detail in the referenced chapters:

  • Virtual Leased Line (VLL) services

    • Ethernet pipe (Epipe)

      A Layer 2 point-to-point VLL service for Ethernet frames. See Epipe for more information about Epipe.

  • Virtual Private LAN Service (VPLS)

    A Layer 2 multipoint-to-multipoint VPN bridging service or VPN (using QinQ uplinks). See Virtual Private LAN Service for more information about VPLS.

Service types on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C offer the following types of subscriber services, described in more detail in the referenced chapters:

  • Virtual Leased Line (VLL) services

    • Ethernet pipe (Epipe)

      A Layer 2 point-to-point VLL service for Ethernet frames. See Epipe for more information.

  • Virtual Private LAN Service (VPLS)

    VPLS is a Layer 2 multipoint-to-multipoint VPN bridging service or VPN (using QinQ uplinks). See Virtual Private LAN Service for more information.

  • Routed VPLS Service (R-VPLS)

    An R-VPLS integrates routing and bridging into a single service. It provides the capability to provide Layer 2 multipoint-to-multipoint services locally on the node, typically using an IP interface for uplink connectivity. See Virtual Private LAN Service for more information.

  • Internet Enhanced Services (IES)

    IES is a direct Internet access service where the customer is assigned an IP interface for Internet connectivity. See the Internet Enhanced Service on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T for more information about IES.

  • Virtual Private Routed Network (VPRN)

    VPRN is a Layer 3 IP multipoint-to-multipoint VPN service as defined in RFC 2547bis. See Virtual Private Network service on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C for more information.

Service policies on 7210 SAS-D and 7210 SAS-Dxp

Common to connectivity services on 7210 SAS-D and 7210 SAS-Dxp platforms are policies 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 following types of policies are common to all 7210 SAS-series connectivity services:

  • SAP Quality of Service (QoS) policies allow different classes of traffic within a service at SAP ingress. Access egress QoS policies allow differential treatment of various traffic classes within a service (SAPs) which exists in an egress port.

    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 QoS policy can be associated with a SAP. A single access egress QoS policy can be associated with a port.

  • 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 on 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.

  • Scheduler policies define the operating parameters (such as scheduling algorithm, weights per priority). Depending on the platform, these are either associated with SAPs or physical ports.

  • 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 that enables network operators to accurately measure network usage and bill each customer for each individual service using any of several billing models.

Service policies on 77210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

Common to connectivity services on the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4Tand 7210 SAS-K 3SFP+ 8C, are policies 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 service enhancements. The following types of policies and their functions are common to all 7210 SAS connectivity services:

  • SAP Quality of Service (QoS) policies allow different classes of traffic within a service at SAP ingress and at SAP egress.

    QoS ingress and egress policies determine the QoS characteristics for a SAP. A QoS ingress and egress policies applied to a SAP specifies the number of queue, queue characteristics (such as forwarding class, committed, and peak information rates, and so on) and the mapping of traffic to a forwarding class. 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 and 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 that enables network operators to accurately measure network usage and bill each customer for each individual service, using any of several billing models.

Nokia service model on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

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 and IP/MPLS provider core network in encapsulation tunnels created using generic router encapsulation MPLS label-switched paths (LSPs). The 7210 SAS-D, 7210 SAS-Dxp, and 77210 SAS-K 2F1C2T support only QinQ and dot1q Layer 2 uplinks, which are used to transport the services to the provider edge in a hierarchal configuration. The platforms do not support transport tunnels that use MPLS 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 the following:

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

Nokia service model on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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 and IP/MPLS provider core network in encapsulation tunnels created using generic router encapsulation MPLS label-switched paths (LSPs). The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C support transport tunnels that use MPLS LSPs or QinQ/dot1q Layer 2 uplinks. These tunnels are used to transport the services to the provider edge in a hierarchical configuration.

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 the following:

  • Many services can be bound to a single customer.

  • Many services can be bound to a single tunnel.

  • Tunnel configurations are independent of the services they carry.

  • Changes are made to a single logical entity instead of multiple ports on multiple devices. It is easier to change one tunnel instead of several services.

  • The operational integrity of a logical entity (such as a service tunnel and service endpoints) can be verified instead of dozens of individual services improving management scaling and performance.

  • On 7210 SAS platforms, a failure in the network core can be correlated to specific subscribers and services.

  • 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, accounting/billing to the appropriate entity.

Service entities on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The basic logical entities in the service model used to construct a service are:

Customers

The terms ‟customer” and ‟subscriber” are used synonymously. The most basic required entity is the customer ID value, 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 on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

Each subscriber service type is configured with at least one SAP. Multiple SAPs in a service using QinQ uplinks in 7210 SAS configured in access-uplink mode shows how 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-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C 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” or ‟access uplink” in the physical port configuration. SAPs can be created on ports designated as core facing ‟access uplink” ports. These ports have a different set of features enabled in software.

Figure 1. Multiple SAPs in a service using QinQ uplinks in 7210 SAS configured in access-uplink mode

The preceding figure shows SAPs used for customer service delivery, with access-uplink SAPs (also known as QinQ SAPs) used for service transport on 7210 SAS devices that support only Layer 2 uplinks (also known as access-uplink mode platforms).

SAPs on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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 (Multiple SAPs for 7210 SAS configured with MPLS uplinks). 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-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C 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.

Figure 2. Multiple SAPs for 7210 SAS configured with MPLS uplinks

The preceding figure shows SAPs used for customer service delivery, with SDP used for service transport on 7210 SAS devices that support MPLS uplinks.

SAPs can be created on ports designated as core facing ‟access uplink” ports when using QinQ uplinks. Access-uplink ports have a different set of features enabled in software.

The following figure shows SAPs used for customer service delivery with access-uplink SAPs (also known as QinQ SAPs) used for service transport on 7210 SAS devices when using Layer 2 uplinks.

Figure 3. Multiple SAPs in a service using QinQ uplinks in 7210 SAS configured in access-uplink mode

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 supported on 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

The following lists encapsulation service options on Ethernet access 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). For example, the port is connected to a customer who needs multiple services. The encapsulation ID used to distinguish an individual service is the VLAN ID in the IEEE 802.1Q header.

  • 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 following lists encapsulation service options on Ethernet access-uplink ports:

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

    Figure 4. Multiple SAPs on a single port

Services and SAP encapsulations

The following table lists the service and SAP encapsulation information for Ethernet ports.

Table 1. Service and SAP encapsulation for access ports

Port type

Encapsulation

7210 SAS platforms support

Ethernet

null

All

Ethernet

Dot1q

All

Ethernet

QinQ

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

The following table lists the service and SAP encapsulation information for Ethernet access-uplink ports.

Table 2. Port type and encapsulation for access-uplink ports

Port type

Encapsulation

7210 platforms

Ethernet access-uplink

QinQ

All

Default SAPs on a dot1q port

This feature provides default SAP functionality on dot1q-encapsulated ports. On a dot1q-encapsulated port where a default SAP is configured, all packets with q-tags not matching any explicitly defined SAPs will be assigned to this SAP. SAPs with default dot1q encapsulation are supported in VPLS and Epipe services.

In this context, the character ‟*” indicates default, which means allow through. The default SAP also accepts untagged or priority-tagged packets. A default SAP must be configured explicitly. When a default SAP is not configured explicitly, packets not matching any explicitly defined SAPs will be dropped.

One of the applications where this feature can be applicable is an access connection of a customer who uses the whole port to access Layer 2 services. The internal VLAN tags are transparent to the service provider. This can be provided by a null-encapsulated port.

In this type of environment, logically two SAPs exist: a management SAP and a service SAP. The management SAP can be created by specifying a VLAN tag that is reserved to manage the CPE. The service SAP covers all other VLANs and behaves as a SAP on a null-encapsulated port.

There are a few constraints related to the use of a default SAP on a dot1q-encapsulated port:

  • This type of SAP is supported only on VPLS and Epipe services, and cannot be created in IES services because it cannot preserve VLAN tag markings.

  • For VPLS SAPs with STP enabled, STP listens to untagged and null-tagged BPDUs only. All other tagged BPDUs are forwarded like other customer packets. This is the same behavior as null-encapsulated ports.

  • IGMP snooping is not supported on a default SAP. This would require remembering VLAN tags per hosts. By not allowing IGMP snooping on this SAP, all IGMP packets will be transparently forwarded.

Default SAPs on a QinQ port

Default QinQ SAPs (notation *.*) are used in ring ports to avoid the need to configure services on all the intermediate nodes in the ring that are transiting the service. Default QinQ SAPs match all VLAN-tagged traffic that is not classified into any other SAP configured on the same port. Only one Epipe service with default QinQ SAPs is needed for transit service traffic on access-uplink ports.

Default QinQ SAPs are only allowed on access-uplink ports and access ports. A default QinQ SAP can coexist with a 0.* SAP on an access-uplink or access port. A default QinQ SAP accepts only tagged packets. Untagged packets or priority-tagged packets are not accepted on default QinQ SAPs. 7210 SAS-K, accepts untagged and tagged packets on a default QinQ SAP.

When an Epipe service with default QinQ SAPs on the ring ports is used for transit traffic in a ring deployment, no protection mechanism (for example, STP or G.8032) is supported for default QinQ SAPs. The upstream or head-end node on which the service originates must ensure that the correct path on the ring is selected using either G.8032 or STP.

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.

The following features are available for use with default QinQ SAPs configured in Epipe and VPLS service (unless explicitly specified, the following features are applicable for both Epipe and VPLS service).

For default QinQ SAPs on either access ports or access-uplink ports the following is true:

  • On the 7210 SAS-D and 7210 SAS-Dxp, a default QinQ SAP accepts only tagged packets. Untagged packets or priority-tagged packets are not accepted on default QinQ SAPs.

  • On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, a default QinQ SAP accepts both untagged and tagged packets.

  • On the 7210 SAS-D and 7210 SAS-Dxp, default QinQ SAP is available for use only in an Epipe and a VPLS service created with svc-sap-type parameter set to ‟null-star”. Default QinQ SAP can be configured along with other SAPs allowed in the same service (that is, service with svc-sap-type parameter set to ‟null-star”).

  • On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, default QinQ SAP is available for use only in an Epipe and a VPLS service created with svc-sap-type parameter set to ‟any”. Default QinQ SAP can be configured along with other SAPs allowed in the same service (that is, service with svc-sap-type parameter set to ‟any”).

  • MAC learning and aging is available for use in a VPLS service.

  • Per-SAP MAC limit is available for use in a VPLS service.

  • Mac-move detection and Mac-pinning is available for use in a VPLS service.

  • Discard-unknown and discard-unknown-source is available for use in a VPLS service.

  • Ethernet Connectivity Fault Management (ETH-CFM) and Y.1731 are not available for use.

  • STP (and all its different flavors) cannot be enabled in the service with default QinQ SAPs.

  • M-VPLS with xSTP can be used for loop prevention. The default QinQ SAPs inherit the state from the associated M-VPLS instance.

  • A G.8032 control instance cannot be configured in a service with a default QinQ SAP.

  • G.8032 can be used for loop prevention in ring deployments, where the default QinQ SAPs are configured on the ring ports in a VPLS service. A separate G.8032 control instance needs to be configured for use on the ring ports, and the service with default QinQ ports needs to be associated with this G.8032 control instance.

  • IGMP snooping is not available for use.

  • L2PT and BPDU translation is not available for use.

  • On the 7210 SAS-D and 7210 SAS-Dxp, IP interface in a VPLS service is not supported in a service priority-tagged using this SAP. On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, IP interface in a VPLS service is not supported (irrespective of SAP encapsulations).

For default QinQ SAPs created on an access-uplink port, the following is true:

  • Ingress QoS policies applied on an access-uplink port is available for classification and policing on ingress.

  • Egress QoS policy applied on an access-uplink port is available for egress queue shaping, scheduling, and marking.

  • SAP ingress ACLs are available for use.

  • SAP egress ACLs are not available for use.

  • SAP ingress received count and SAP egress forwarded count are available for use (appropriate accounting records can be used).

For default QinQ SAPs created on access ports, the following is true:

  • A SAP ingress QoS policy is available for use.

  • On the 7210 SAS-D and 7210 SAS-Dxp, an egress QoS policy applied on an access port is available for egress shaping, scheduling, and marking.

  • On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, an egress QoS policy applied on an access SAP is available for egress shaping, scheduling and marking.

  • SAP ingress ACLs are available for use.

  • SAP egress ACLs are not available for use.

  • On the 7210 SAS-D and 7210 SAS-Dxp, SAP ingress meter counters, SAP ingress received count, and SAP egress forwarded counter are available for use (appropriate accounting records can be used).

  • On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, SAP ingress queue counters, SAP ingress received count, and SAP egress forwarded counter are available for use (appropriate accounting records can be used).

Configuration notes for default QinQ SAPs for transit service in a ring deployment

  • If an Epipe service is used with default QinQ SAPs on the ring ports for transit service in a ring deployment, no protection mechanism is available for the transit service (that is, Epipe service with the default QinQ SAPs on ring ports). Both Epipe and VPLS services that are originating on different nodes in the ring can use the transit service.

    Protection/loop-detection mechanisms can be implemented for VPLS service configured in the ring nodes, by using M-VPLS with xSTP on the nodes where the VPLS service is configured. No protection mechanisms are available for use with Epipe services on the node that originates the service.

  • If a VPLS service is used with default QinQ SAPs on the ring ports for transit service in a ring deployment, either M-VPLS/xSTP or G.8032 can be used to protect the transit service (that is, VPLS service with the default QinQ SAPs on ring ports). In this case, VPLS services that are originating on different nodes in the ring and use the transit VPLS service are also protected. Epipe services that are originating on different nodes in the ring cannot use the transit VPLS service.

  • When using VPLS service with default QinQ SAPs for transit service with either G.8032 or M-VPLS with xSTP configured for protection, load-balancing of the traffic based on the VLAN IDs is not possible. If load-balancing is needed, then it is better to use Epipe service with default QinQ SAPs as the transit service.

SAP configuration considerations applicable for SAPs configured on access-uplink ports

Note:

On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, the simultaneous configuration of access-uplink and network operating modes, without explicit BOF configuration, is supported. A mix of access-uplink and network ports can be simultaneously configured on these platforms.

When configuring a SAP, consider the following:

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

  • On the 7210 SAS-D and 7210 SAS-Dxp, a physical port can only have one SAP to be part of one service. Multiple SAPS can be defined over a physical port but each of these SAPs must belong to a different service.

  • On the 77210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, multiple SAPs configured on the same port can be part of the same service.

  • The 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C support the use of a Q1.0 SAP. This SAP matches packets received on a port with the outermost tag being Q1 and the inner tag being absent (that is, no tag) or the inner tag is a priority tag. It does not accept packets with any other VLAN tag value as the inner tag.

  • There are no default SAPs configured on the node. All SAPs in subscriber services must be created.

  • The default administrative state for a SAP at creation time is administratively enabled.

  • When a SAP is deleted, all configuration parameters for the SAP will also be deleted.

  • An access SAP is owned by and associated with the service in which it is created in each router.

  • A port with a dot1q encapsulation type means the 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 placed on at SAP egress. As a result, VLAN IDs only have local significance, so the VLAN IDs for the SAPs for a service need not be the same at each SAP.

    Note:

    Some exceptions to this are dot1q range SAPs and dot1q preserve SAPs configured on a port with dot1q encapsulation.

  • If a port is administratively shut down, all SAPs on that port are operationally out of service.

  • A SAP cannot be deleted until it has been administratively disabled (shut down).

  • Each SAP can have one each of the following policies assigned:

    • ingress filter policy

    • egress filter policy

    • ingress QoS policy

    • accounting policy

    • egress QoS policy on the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

  • An ingress QoS policy and accounting policy is assigned per access-uplink port and cannot be assigned per access-uplink SAP. That is, all access-uplink SAPs on a specific port share the QoS policy.

  • Ingress filter policy and egress filter policy is available per access-uplink SAP.

  • The svc-sap-type parameter value determines the type of SAPs provisioned in a service:

    • provides details of SAP and service combinations allowed in 7210 SAS-D and 7210 SAS-Dxp devices

    • provides details of SAP and service combinations allowed in 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C devices

  • If a service sap-type is specified as dot1q-preserve, all the SAPs configured in the service must have the same VLAN ID. The outermost VLAN tag of the packets received on the access port is not stripped, when svc-sap-type is set to dot1q-preserve.

  • For dot1q range SAP, the outermost VLAN tag is compared against the range of VLAN IDs configured and mapped to the SAP if there is a match. The outermost tag is not stripped on SAP ingress and is forwarded through the other service endpoint.

  • L2PT cannot be configured for use on all the configured SAPs simultaneously. The number of SAPs that can use this simultaneously is less than the maximum number of SAPs supported by the node.

Configuration guidelines for 7210 SAS-D and 7210 SAS-Dxp

The following considerations apply to SAP configurations:

  • Ensure that egress SAP counters are enabled before associating accounting records that count egress forwarded packets.

  • Before modifying the counter, disable the account log generation and run the no collect-stats command.

  • Egress SAP statistics are not available on any of the SAPs of a port, on which a dot1q SAP and dot1q default SAP configuration are present at the same time. This limitation also applies for egress ACLs. That is, egress ACLs are not supported on either dot1q SAPs or dot1q default SAPs when both these SAPs are configured on a port simultaneously.

  • Egress SAP statistics cannot be configured for use simultaneously on all the configured SAPs. The number of SAPs that can use this feature simultaneously is less than the maximum number of SAPs supported by the node.

  • Service MTU is not supported on the 7210 SAS-D.

  • QinQ access SAPs of type Q1.0 are supported only for IES and R-VPLS services. They are not supported for Layer 2 services.

The following table lists the SAPs allowed with different values for the svc-sap-type on 7210 SAS-D and 7210 SAS-Dxp.

Table 3. SAP and service combinations for 7210 SAS-D and 7210 SAS-Dxp

svc-sap-type

Access SAPs

Access-uplink SAPs

null-star

null SAP,

Dot1q default SAP

Q.* SAP,

0.* SAP

default QinQ SAP (*.* SAP)

Q.* SAP,

0.* SAP

default QinQ SAP (*.* SAP)

dot1q-preserve

Dot1q SAP (Dot1q VLAN tag not stripped on ingress),

Q1.Q2 SAP (Q2 tag VLAN must match the Dot1q SAP VLAN ID)

Q1.Q2 SAP (Q2 tag VLAN ID must match the Dot1q SAP VLAN ID)

any

null SAP,

Dot1q SAP,

Dot1q explicit null SAP

Q1.Q2 SAP,

Q.* SAP,

0.* SAP

Q1.Q2 SAP,

Q.* SAP,

0.* SAP

dot1q-range

Dot1q SAP (Dot1q VLAN tag not stripped on ingress),

Q1.* SAP

Q1.* SAP

  • A dot1q default SAP cannot be configured when the svc-sap-type is set to any.

  • When svc-sap-type is set to any for a null SAP, the system processes and forwards only packets with no VLAN tag (that is, untagged). All other packets with one or more VLAN tags (even those with priority tag only) are not processed and are dropped. Users can use the service with the svc-sap-type set to null-star, to process and forward packets with one or more tags (including priority tag) on a null SAP.

  • The default QinQ SAP processes only tagged packets received on a QinQ port. All tagged packets that do not match the specific SAP tags configured on the same port are processed by this SAP. The default QinQ SAP cannot process untagged packets, even if 0.* SAP is not configured for use on that port.

  • The default QinQ SAPs are available for use with 0.* SAPs configured on the same port or in the same service. It is available for use with another default QinQ SAP configured in the same service (on a different port).

  • In a VPLS service, the default QinQ SAP is available for use with any other SAP type configured in a service configured with the svc-sap-type parameter set to null-star.

  • SAPs using connection profiles (to specify dot1q VLAN ranges) can be configured in a service only when the svc-sap-type is set to dot1q-range.

  • When a service is configured to use svc-sap-type dot1q-range, the outermost V-LAN tag of the packets is not stripped when the packet is received on access port ingress. See Epipe for information about processing behavior for this type of service.

  • Service MTU is not supported on 7210 SAS-D.

  • The following counters are available on 7210 SAS-D and 7210 SAS-Dxp devices:

    • ingress and egress counters per SAP

    • ingress policer counters per SAP

    • egress queue counters per access port

    • ingress and egress counters per access-uplink port

  • The number of counters available to count total received packets or octets on an access-uplink SAP (in a VPLS, VLL or IES service) ingress is limited; therefore a count of received packets or octets cannot be obtained for all the SAPs simultaneously. By default, these counts are not available.

  • The config>service>epipe>sap>statistics>ingress command is available to associate a counter with the SAP and obtain the counts.

  • The number of counters available to count total forwarded packets or octets on an access SAP egress and access-uplink SAP egress is limited and therefore a count of received packets or octets cannot be obtained for all the SAPs simultaneously. By default, these counts are not available.

  • The config>service>epipe>sap>statistics> ingress>forwarded-count command is available to associate a counter with the SAP and obtain the counts.

Configuration guidelines for 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

The following guidelines apply to SAP configurations:

  • The 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C support the following types of SAPs:

    • access SAPs

      null, dot1q (dot1q, dot1q default, dot1q range, dot1q explicit null), QinQ SAPs (Q1.Q2, Q1. *, Q1.0 QinQ default SAP (that is, *.* SAP), 0.*) are supported.

    • access-uplink SAPs

      QinQ SAPs (various SAP types, such as Q1.Q2, QinQ default SAP (*.* SAP), 0.*, Q1.*, Q1.0) are supported.

  • The 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C support Q1.0 SAP. This SAP accepts a packet with the outermost tag as Q1 or a packet with outermost tag as Q1 and the following inner tag is a priority tag. Unlike 7x50, it does not accept packets with two tags with the outermost tag being Q1 and the inner tag being any tag other than priority tag.

  • The 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C allow any port to be configured in either access-uplink mode or access mode. Additionally the ports can be in access-uplink mode or access mode or they can be mix of the ports using either modes. There is no limit to the number of access ports allowed to be configured. That is, all ports can be configured as access ports. The number of access-uplink ports depends on the number of QoS resources allocated per port. That is, not all the ports can be configured as access-uplink ports at a specific time.

  • The 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C support service MTU:

    • A received frame/packet length is checked against the configured service MTU after subtracting the length of the SAP encapsulation (including the Layer 2 header) from the received frame length. The packet is further processed in the context of the service, if the computed length is less than equal to the configured service MTU or the packet is dropped.

    • The user must configure the correct service MTU across all the nodes, if support is available, through which the service is transported.

  • The 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C support only the following svc-sap type parameters:

    • ‛any’

      A service configured with this value for svc-sap-type allows for configuration of all combination of access SAPs and access-uplink SAPs in the same service, except for dot1q range SAPs. A packet that is received with tags more than the number of SAP tags to which it is mapped to, is forwarded transparently in the service (the processing behavior is similar to any other packet mapped to the SAP).

    • ‛dot1q-range’

      A service configured with this value for svc-sap-type allows for configuration of dot1q range SAPs and Q1.* access-uplink SAP in the same service.

The following table lists the SAPs allowed on the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C with different values of svc-sap-type.

Table 4. SAP and service combinations for 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

svc-sap-type

Access SAPs

Access-uplink SAPs

any

null SAP,

Dot1q SAP,

Dot1q explicit null SAP

Dot1q default SAP

Q1.Q2 SAP,

Q.* SAP,

Q1.0 SAP,

0.* SAP

QinQ default SAP (*.* SAP)

Q1.Q2 SAP,

Q.* SAP,

Q1.0 SAP,

0.* SAP,

QinQ default SAP (*.* SAP)

dot1q-range

Dot1q SAP (Dot1q VLAN tag not stripped on ingress), Q1.* SAP

Q1.* SAP

VLAN range for SAPs (or dot1q range SAPs) in an Epipe or VPLS service

The 7210 SAS VLAN ranges (or dot1q range SAPs) provide a mechanism to group a range of VLAN IDs as a single service entity. This allows the operator to provide the service treatment (forwarding, ACL, QoS, accounting, and others) to the group of VLAN IDs as a whole.

Note:

  • Dot1q range SAPs are supported on all 7210 SAS platforms as described in this document.

  • Grouping a range of VLAN IDs to a SAP is supported only for Epipe and VPLS Ethernet services.

Epipe processing behavior for dot1q range SAPs in access-uplink mode on the 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

The access SAPs that specify VLAN range values using the connection profile (also known as dot1q range SAPs) are allowed in the Epipe and VPLS service. For more information about the supported functionality, see Epipe VLAN range SAPs feature support and restrictions. The system allows only one range SAP in an Epipe service; attempts to configure more than one range SAP fail. Range SAPs can only be configured on access ports. The other endpoint in the Epipe service must be a Q.* SAP in access-uplink mode. The processing and forwarding behavior for packets received on range SAPs is as follows:

  • No VLAN tags are stripped on ingress of an access dot1q SAP configured to use VLAN ranges. A single tag (Q1) is added to the frame when it is forwarded out of the Q1.* access-uplink SAP.

  • When a packet is received on the access-uplink Q1.* SAP, the outermost tag is removed and the packet is forwarded out of the access dot1q range SAP. The system does not check if the inner VLAN tag matches the VLANs IDs (both range and individual values specified in the connection profile) of the dot1q access SAPs configured in the service.

  • The dot1q range SAP can be supported in a service with svc-sap-type set to dot1q-range.

Epipe VLAN range SAPs feature support and restrictions

The feature support and restrictions of VLAN range SAPs in an Epipe service are the following:

  • The access SAPs that specify VLAN range values (using the connection profile) are only allowed in an Epipe service. The system allows only one range SAP in an Epipe service, and fails any attempt to configure more than one. Range SAPs can only be configured on access ports.

  • On 7210 SAS-D and 7210 SAS-Dxp, the dot1q range SAP can only be configured in a service with svc-sap-type set to dot1q-range.

  • On 7210 SAS-K 2F1C2T, the dot1q range SAP can only be configured in a service with svc-sap-type set to dot1q-range.

  • The access SAPs using VLAN range values are only allowed for ports or a LAGs configured for dot1q encapsulation.

  • A connection profile is used to specify either range of VLAN IDs or individual VLANs to be grouped together in a single SAP.

  • On 7210 SAS-D and 7210 SAS-Dxp, dot1q default SAP and dot1q range SAP is not allowed to be configured on the same access port. That is, they are mutually exclusive. This restriction does not apply to 7210 SAS-K 2F1C2T.

  • Multiple connection-profiles can be used per port or LAG if the VLAN value specified by each of them does not overlap. The number of VLAN ranges available per port/LAG is limited. The available number must be shared among all the SAPs on the port/LAG.

  • The connection profile associated with a SAP cannot be modified. To modify a connection profile, it must be removed from all SAPs using it.

  • ACL support – Filter policies are supported on SAP ingress. IP criteria and MAC criteria-based filter policy is available for use with access SAPs. For more information about ACL on range SAPs, see the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Router Configuration Guide.

  • On 7210 SAS-K 2F1C2T, the outermost VLAN tag and Inner VLAN tag matches are supported for both ingress/egress ACL and ingress QoS classification.

  • On 7210 SAS-D and 7210 SAS-Dxp, access SAP egress filters are not supported for SAPs configured in a dot1q-range service.This restriction does not apply to 7210 SAS-K 2F1C2T.

  • On 7210 SAS-D and 7210 SAS-Dxp, access-uplink SAP egress filters are not supported for SAPs configured in a dot1q-range service. This restriction does not apply to 7210 SAS-K 2F1C2T.

  • QoS on 7210 SAS-D and 7210 SAS-Dxp, Ingress classification, metering with hierarchical metering support for SAP ingress is available:

    • SAP ingress classification criteria that is available for use with VLAN range SAPs is similar to that available for other SAPs supported in an Epipe service. Dot1p-based ingress classification uses the dot1p bits in the outermost VLAN tag for matching.

  • QoS on 7210 SAS-K 2F1C2T- Ingress classification, queuing with hierarchical shaping support for SAP ingress is available:

    • SAP ingress classification criteria that is available for use with VLAN range SAPs is similar to that available for other SAPs supported in an Epipe service. Dot1p-based ingress classification uses the dot1p bits in the outermost VLAN tag for matching.

  • The amount of hardware resources (such as CAM entries used for matching in QoS classification and ACL matching, meters used in SAP ingress policy, and others), consumed by a single range SAP, are equivalent to the amount of resources consumed by a single SAP that specifies a single VLAN ID for service identification. That is, the hardware can match a range of VLAN values, and therefore uses X resources for a SAP using a VLAN range, instead of X * n, where n is the number of VLANs specified in the range and X is the amount of QoS or ACL resources needed.

  • Ingress accounting support is like the support available for other SAPs in an Epipe service. The count of packets or octets received from individual VLANs configured in the connection profile is not available. No support for Egress SAP statistics and accounting is available.

  • Mirroring is supported.

Epipe processing behavior for dot1q range SAPs on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The access SAPs that specify VLAN range values (using the connection profile) are only allowed in an Epipe service. The system allows only one range SAP in an Epipe service; attempts to configure more than one range SAP fail. Range SAPs can only be configured on access ports. The other endpoint in the Epipe service has to be a Q.* access SAP or a Q.* access-uplink SAP or a spoke-SDP (PW) in network mode.

The spoke-SDP processing and forwarding behavior for packets received on range SAPs are as follows:

  • No VLAN tags are stripped on ingress of the access dot1q SAPs using VLAN range connection profile.

  • When the other endpoint in the service is configured to be an Q1.* access SAP or a Q1.* access-uplink SAP, the 7210 adds another tag to the packet and forwards it out of that SAP. If the other endpoint in the service is configured to be a spoke-SDP whose VC type is set to vc-ether, the 7210 SAS adds the appropriate MPLS PW and LSP encapsulations and forwards it out of the SDP.

  • In the reverse direction, when the other endpoint is a Q1.* access SAP or a Q1.* access-uplink SAP and a packet is received on it, the 7210 SAS removes the outermost VLAN tag and forwards the packet out of the access dot1q range SAP. When the other endpoint is a spoke-SDP (whose VC type is set to vc-ether), the 7210 SAS removes the MPLS PW and LSP encapsulation and forwards the packet out of the access dot1q SAP using VLAN ranges. The system does not check if the VLAN in the packet matches the VLAN IDs of the dot1q access SAPs configured in the service. That is, when forwarding the traffic out of the range SAPs, the outermost VLAN tag value is not matched against the range configuration.

Epipe VLAN range SAPs feature support and restrictions on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The following information describes feature support and restrictions for VLAN range SAPs configured in an Epipe service:

  • The access SAPs that specifies VLAN range values (using connection profile) is only allowed in Epipe service. The system allows only one range SAP in an Epipe service. It will fail any attempt to configure more than one range SAP in an Epipe service. Range SAP can be configured only on access ports.

  • The dot1q range sap can be configured only in a service with svc-sap-type set to dot1q-range.

  • The access SAPs using VLAN range values are only allowed for dot1q encapsulation port.

  • A connection profile is used to specify either range of VLAN IDs or individual VLANs to be grouped together in a single SAP.

  • The dot1q default SAP and dot1q range SAP can co-exist on the same access port.

  • Multiple connection profiles can be used per port or LAG as long as the VLAN value specified by each of them does not overlap. The number of VLAN ranges match resources available per port/LAG is limited. The available number must be shared among all the dot1q range SAPs configured on the port/LAG.

  • The connection profile associated with a SAP cannot be modified. To modify a connection profile, it must be removed from all SAPs using it.

  • ACL support – Filter policies are supported on SAP ingress and SAP egress. Only MAC criteria-based filter policy is available for use with access SAPs. For more information about ACL on range SAPs, see the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Router Configuration Guide.

  • The outermost VLAN tag and Inner VLAN tag matches are supported for both ingress/egress ACL and ingress QoS classification.

  • SDP egress and ingress filter are not supported.

  • QoS – ingress classification, queuing with hierarchical shaping support for SAP ingress:

    • SAP ingress classification criteria that is available for use with VLAN range SAPs is like that available for other SAPs supported in an Epipe service. Dot1p-based ingress classification uses the dot1p bits in the outermost VLAN tag for matching. On access egress, dot1p received from the SDP (on a network port) from another access port is preserved.

  • The amount of hardware resources (such as CAM entries used for matching in QoS classification and ACL matching, meters used in SAP ingress policy, and others), consumed by a single range SAP, are equivalent to the amount of resources consumed by a single SAP that specifies a single VLAN ID for service identification. That is, the hardware can match a range of VLAN values, and therefore uses X resources for a SAP using a VLAN range, instead of X * n, where n is the number of VLANs specified in the range and X is the amount of QoS or ACL resources needed.

  • Ingress accounting support is like the support available for other SAPs in an Epipe service. The count of packets or octets received from individual VLANs configured in the connection profile is not available. No support for Egress SAP statistics and accounting is available.

  • Mirroring is supported.

  • Service resiliency mechanisms, such as Epipe PW redundancy, are supported.

VLAN range SAPs in a VPLS service on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

VLAN ranges on the 7210 SAS provide a mechanism to group a range of VLAN IDs as a single service entity. This allows the operator to provide the service treatment (forwarding, ACL, QoS, Accounting, and so on) to the group of VLAN IDs as a whole.

VPLS processing behavior for dot1q range SAPs on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The access SAPs that specify VLAN range values (using the connection profile) are allowed in VPLS services. The system allows support for one or more dot1q range access SAPs in a VPLS service, with the other endpoint being only a spoke-SDP, mesh-SDP, or access-uplink SAP. No other SAP encapsulations are allowed when the access SAP is a dot1q range SAP (other than access uplink SAP as specified above).

The processing and forwarding behavior for packets received on range SAPs are as follows:

  • No VLAN tags are stripped on the ingress of the access dot1q SAPs using the VLAN range connection profile.

  • When the other endpoint in the service is configured to be a Q1.* access SAP or a Q1.* access-uplink SAP, the 7210 SAS adds another tag to the packet and forwards it out of that SAP. If the other endpoint in the service is configured to be a spoke-SDP and mesh-SDP, the 7210 SAS adds the appropriate MPLS PW and LSP encapsulations and forwards it out of the SDP.

  • In the reverse direction, when the other endpoint is a Q1.* access SAP or a Q1.* access-uplink SAP and a packet is received on it, the 7210 SAS removes the outermost VLAN tag and forwards the packet out of the access dot1q range SAP. When the other endpoint is a spoke-SDP and mesh-SDP, the 7210 SAS removes the MPLS PW and LSP encapsulation and forwards the packet out of the access dot1q range SAP.

  • The system does not check if the outermost VLAN tag in the packet matches the VLAN IDs of the dot1q range SAP configured in the service. That is, when forwarding the traffic out of the dot1q range SAPs, the outermost VLAN tag value is not matched against the range configuration.

VPLS VLAN range SAP feature support and restrictions

The following information describes dot1q range SAPs feature support and restrictions:

  • Dot1q range SAPs are only allowed to be configured in a service with the svc-sap-type set to dot1q-range.

  • The access SAPs using VLAN range values are only allowed for a dot1q encapsulation port or LAG.

  • A connection profile is used to specify either the range of VLAN IDs or individual VLANs to be grouped together in a single SAP.

  • The system allows support for one or more dot1q range access SAPs in an VPLS service, with the other endpoint being only a spoke-SDP, mesh-SDP, or access-uplink SAP. No other SAP encapsulations are allowed when the access SAP is a dot1q range SAP (other than access uplink SAP as specified above).

  • Dot1q default SAPs are not allowed on the same access port as the one on which a SAP with a range is configured.

  • Multiple connection profiles can be used per port or LAG as long as the VLAN value specified by each of them does not overlap. The number of VLAN ranges available per port or LAG is limited. The available number must be shared among all the SAPs on the port or LAG.

  • The connection profile associated with a SAP cannot be modified. To modify a connection profile, it must be removed from all SAPs that are using it.

  • L2 processing (Learning, Unicast forwarding, BUM flooding, and replication) completed for traffic received on a dot1q range SAP is similar to the processing for a NULL/dot1q default SAP in a VPLS service. In other words, no special handling is required for dot1q range SAPs, other than the requirement to not add and or remove the outermost VLAN tag for a dot1q range SAP.

  • For BUM traffic flooding (including L2 multicast if any), a packet is replicated to all dot1q range SAPs in the VPLS service with no modification or addition of VLAN tags. In other words, a single copy of BUM traffic is sent out of the SAP and the dataplane does not replicate a copy per VLAN ID configured in the dot1q range SAP for BUM traffic. It is assumed that the downstream device can do the required replication for L2 multicast/BUM traffic if needed.

  • No egress checks are implemented for all traffic (unicast and BUM) to check if outermost VLAN tag in the packet matches the VLAN IDs of the range of the egress SAP that the packet is sent out of.

  • L2 forwarding accounts for service-based SHG or port-based SHG while forwarding.

  • Learning is enabled on the service by default. The user has an option to disable learning per-service. Learning enable and disable per-SAP is not supported.

  • MAC limiting is available per-service. MAC limiting per-SAP is not supported.

  • ACL support:

    • Filter policies are supported on SAP ingress. IP criteria and MAC criteria-based filter policies are available for use with access SAPs.

    • Egress filters are supported for access SAPs and access-uplink SAPs configured in a dot1q range service.

    • The outermost VLAN tag and inner VLAN tag matches are supported for both ingress/egress ACL and ingress QoS classification.

      For more information about ACL on range SAPs, see the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Router Configuration Guide.

  • QoS on the 7210 SAS-K 2F6C4T: ingress classification and queuing with hierarchical shaping support for SAP ingress is available:

    • SAP ingress classification criteria that is available for use with dot1q range SAPs is similar to that available for other SAPs supported in a VPLS service. Dot1p-based ingress classification uses the dot1p bits in the outermost VLAN tag for matching.

    • SAP egress queueing and shaping is supported for dot1q range SAPs.

  • The amount of hardware resources (such as CAM entries used for matching in QoS classification and ACL matching, meters used in SAP ingress policy, and so on) consumed by a single range SAP are equivalent to the amount of resources consumed by a single SAP that specifies a single VLAN ID for service identification. That is, the hardware can match a range of VLAN values, and therefore uses X resources for a SAP using a VLAN range, instead of X * n, where n is the number of VLANs specified in the range, and X is the amount of QoS or ACL resources needed.

  • Ingress accounting support is like the support available for other SAPs in a VPLS service. The packets or octets count received from individual VLANs configured in the connection profile is not available.

  • Egress SAP statistics and accounting are not supported.

  • Mirroring is supported.

  • IGMP snoopoing and MVR are not supported.

  • DHCP snooping is not supported.

  • xSTP is not supported.

  • G8032 is not supported.

  • CFM OAM is not supported.

  • A/S PW redundancy is not supported.

Epipe emulation using dot1q VLAN range SAP in VPLS with G.8032

Note:

This feature is only supported on the 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C operating in access-uplink mode.

On the node where the service originates, in addition to the access dot1q range SAP, the service needs to be configured with access-uplink SAPs on the two G.8032 ring ports. G.8032 mechanism is used to for breaking the loop in the ring and VPLS service protection. The intermediate nodes on the ring needs to use VPLS service with access-uplink SAPs on the ring ports and use the same G.8032 instance for protection, as one is used for service protection on the originating node.

The following figure shows how two business offices, served by an operator are connected in a ring network deployment using dot1q range SAPs and a VPLS service with G.8032 for protection.

Figure 5. Epipe emulation in a ring using VPLS with G.8032

The following are the requirements to provide for an Epipe service connectivity between two business sites:

  • Transport all the VLANs used by the internal enterprise network of the businesses.

  • Support high availability for the service between the business sites by protecting against failure of the links or nodes in the ring.

To achieve connectivity between two business sites in access-uplink/L2 mode is to configure SAPs for each of the individual VLANs used in the enterprise network in a VPLS service and use G.8032 for protection. The number of VLANs that was supported is limited by the number of SAPs supported on the platform.

The 7210 SAS platforms, currently support the use of Dot1q range SAPs with only Epipe services in either network/MPLS mode or access-uplink/L2 mode. Dot1q range SAPs allows operators to transport a range of VLANs by providing similar service treatment (service treatment refers to forwarding decision along with encapsulation used, QoS and ACL processing, accounting, and so on) to all the VLANs configured in the range. It simplifies service configuration and allows operators to scale the number of VLANs that can be handled by the node. This took care of the need to support hundreds of VLANs using a single SAP or a small number of SAPs. When MPLS the mode is deployed in ring topology, operators have the option of using different redundancy mechanisms such as FRR, primary/secondary LSPs, Active/Standby PWs, to improve Epipe service availability. No such option is available to protect Epipe service in L2 mode when deployed in a ring topology. Additionally many operators prefer G.8032 based ring protection mechanism, because a single control instance on the ring can potentially protect all the VPLS services on the ring.

This feature allows operators to deploy Epipe services in a ring topology when using L2 mode, by emulating an Epipe service using a VPLS service with G.8032 protection and at the same time provides the benefits of using dot1q range SAPs. The user should ensure that the VPLS service is a point-to-point service. This is achieved by configuring a VPLS service with an access dot1q range SAP used at the customer hand-off on one node in the ring and an access dot1q range SAP in a customer hand-off of a VPLS service on another node (that is, at the other end of the Epipe), such that there are only two endpoints for the service in the network.

On the node where the service originates, in addition to the access dot1q range SAP, the service needs to be configured with access-uplink SAPs on the two G.8032 ring ports. G.8032 mechanism is used to for breaking the loop in the ring and VPLS service protection. The intermediate nodes on the ring needs to use VPLS service with access-uplink SAPs on the ring ports and use the same G.8032 instance for protection, as one is used for service protection on the originating node.

Epipe emulation using dot1q VLAN range SAP in VPLS with G.8032 — configuration guidelines and restrictions

The VPLS service with dot1-range SAPs use svc-sap-type of dot1q-range and supports limited functionality in comparison to a normal VPLS service, The following paragraph provide more details of the feature functionality, configuration guidelines and restrictions:

  • The user can define access dot1q range SAPs, which specifies a group of VLANs which receive similar service treatment, that is, forwarding behavior, SAP ingress QoS treatment and SAP (behavior like that available in Epipe service) and allows it to be configured in a VPLS service:

    • On the node, where the service originates, in addition to the access dot1q range SAP, the service should be configured with Q1.* SAPs on the two G.8032 ring ports. The access or access-uplink Q1.*SAPs can be used, but the access-uplink SAPs are recommended for use.The user cannot configure any other SAPs in the same VPLS service.

    • There is no special configuration required on intermediate nodes, that is, the ring nodes which do not terminate or originate the service. The nodes should be configured for providing transit VPLS service and the VPLS service must use the same G.8032 instance for protection as is used by the service on originating and terminating node.

    • The Epipe service on 7210, currently does not check if the inner tag received on a Q1.* SAP is within the range of the configured VLANs. VPLS service too has the same behavior.

  • Support for SAP Ingress QoS, Ingress and Egress ACLs, accounting, and other services, for dot1q range SAP configured in a VPLS service matches the support available in Epipe service.

  • G.8032 mechanism is used for loop detection in ring network and service protection. A separate VPLS service representing the G.8032 control instance must be configured and the state should be associated with this service:

    • Use of dot1q range SAPs to provide service on the interconnection node, in a G.8032 major-ring/sub-ring deployment, when using the virtual channel, is not supported. This restriction is not applicable when the interconnection node in a G.8032 major-ring/sub-ring is configured without a virtual channel.

  • mVPLS/xSTP support is available for use with Q1.* SAP on the ring ports to break the loop. This is a add-on to the G.8032 support.

  • Broadcast, Unknown Unicast and Multicast (BUM) traffic is flooded in the service.

  • Learning is enabled on the service by default, to avoid the need to flood the service traffic out of one of the ring ports, after network MAC addresses are learnt. The user has an option to disable learning per service. Learning enable/disable per SAP is not supported.

  • MAC limiting is available per service. MAC limiting per SAP is not supported.

  • CFM OAM is supported. The support for UP MEPs on the dot1q range SAP in the service to be used for fault management and performance management using the CFM/Y.1731 OAM tools is available:

    • On 7210 SAS-D and 7210 SAS-Dxp, only UP MEP is allowed to be configured only on the dot1q VLAN range SAPs. CFM/Y.1731 tools can be used for trouble shooting and performance measurements. User must pick a VLAN value from the range of VLANs configured for the dot1-range SAP using the config>eth-cfm>domain>association>bridge-identifier VLAN command and enable the use of using the CLI command primary-vlan-enable under the MEP CLI context. It is used as the VLAN tag in the packet header for all the CFM/Y.1731 messages sent out in the context of the UP MEP. This is not supported on 7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T.

    • Down MEPs and MIPs are not allowed to be configured.

    • Fault propagation is not supported with UP MEPs for dot1q range SAP in access-uplink mode.

  • CFM support is not available for SAPs on the ring ports.

  • IGMP snooping and MVR is not supported.

SDPs on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Note:

SDPs are only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

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 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 pointing from ALA-A to ALA-B.

Figure 6. MPLS SDP 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. The 7210 SAS network mode devices support both spoke and mesh SDPs.

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 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 due to 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. SDP ping is a part of the suite of service diagnostics built on a Nokia service-level OAM 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 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 will immediately be brought operationally down.

If a keepalive response is received that indicates an error condition, the SDP will immediately be brought operationally down.

When a response is received that indicates the error has cleared and the hold down time interval has expired, the SDP will be eligible to be put into the operationally up state. If no other condition prevents the operational change, the SDP will enter 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 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. 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 is failed. Admin groups are supported on an SDP and 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 will be enforced.

Any changes made to the admin group sdp-include and sdp-exclude constraints will only be reflected 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 will enforce the admin group constraints specified in the sdp-include and sdp-exclude commands.

config>service>vpls>bgp>pw-template-binding policy-id

config>service>epipe>spoke-sdp-fec>pw-template-bind policy-id

The group value is what is used to uniquely identify an SDP admin group throughout the network in the NSP NFM-P. The node will send both the group name and value to the NSM NFM-P 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 NSP NFM-P or the SNMP device.

SDP admin groups can be enabled on all 7210 SAS services that make use of the PW template (that is, BGP-AD VPLS service).

Mixed-LSP mode of operation

The mixed-LSP 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 time, the service manager programs only one type of LSP in the line-card, which will activate it to forward service packets according to the following priority order:

  1. RSVP LSP type

    One RSVP LSP can be configured per SDP. This is the highest priority LSP type.

  2. LDP LSP type

    One LDP FEC can be used per SDP. The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C support LDP ECMP.

  3. BGP LSP type

    One RFC 3107-labeled BGP prefix, which is programmed by the service manager, is used.

In the case of the RSVP/LDP SDP, the service manager will program 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 will reprogram 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.

Note:

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-K 2F6C4T, K 3SFP+ 8C MPLS Guide.

If the value of the revert-time timer is changed, it will take effect only at the next use of the timer. Any timer which is outstanding at the time of the change will be restarted with the new value.

In the case of the LDP/BGP SDP, the service manager will prefer the LDP LSP type over the BGP LSP type. The service manager will reprogram the line card with the BGP LSP, if available; otherwise, it brings down the SDP operationally.

Note:

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 will exist 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 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

Note:

On the 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, CCMs used for G.8032 Ethernet ring protection service are implemented in hardware.

Ethernet ring protection switching (Eth-ring) provides ITU-T G.8032 specification compliance to achieve resiliency for Ethernet Layer 2 networks.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, 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. Due to 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.

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.

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 will be 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:

Figure 7. G.8032 ring in the initial state

When a ring failure occurs, a node or nodes 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.

Figure 8. G.8032 ring in the protecting state

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 cause them to 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.

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 will fail to receive the CC messages exchanged on that segment or will 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 will declare the associated ring link down and the G.8032 state machine will send 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.

The following diagram shows an example G.8032 ring. The following 0 to 3 ring example shows a resilient ring service. In the ring example, a QinQ ring (solid line) using VID 500 carries two customer VLANs dot1q 100 and QinQ 400.1, respectively). The RPL for the G.8032 ring is between A and B, where B is the RPL owner. 0 to 3 ring example is also a QinQ service on the (dotted line) ring that uses dot1q VID 600 for the ring to connect service VLAN 100.50.

The two rings have RPLs on different nodes which allow a form of load balancing. The example serves to illustrate that service encapsulations and ring encapsulation can be mixed in various combinations.

Note:

Neither of the rings is a closed loop. A ring can restore connectivity when any one node or link fails to all remaining nodes within a small amount of transfer time (signaling time after detection).

Figure 9. 0 to 3 ring example

The following are sample configuration outputs for G.8032 ring for the preceding figure.

  1. Configure G.8032 ring Paths and Control MEPs used for failure detection on ring ports.
    configure eth-ring 1
     description "Ring PBB BLUE on Node B"
     revert-time 100
     guard-time 5
     ccm-hold-time down 100 up 200
     rpl-node owner
     path a 1/1/1 raps-tag 100 // CC Tag 100
          description "To A ring link"
          rpl-end
          eth-cfm
               mep 1 domain 1 association 1 direction down  // Control MEP
                    no shutdown
               ccm-enable
               control-mep
               exit
          exit
          no shutdown  // would allow protect switching
                // in absence of the "force" cmd
     exit
     path b 6/6/2 raps-tag 100 //Tag 100
          description "to D Ring Link"
          eth-cfm
               mep 1 domain 1 association 1 direction down
                    no shutdown
                         ccm-enable
                         control-mep
               exit
          exit
          no shutdown
     exit
no shutdown
exit
  2. Configure VPLS service used for G.8032 control instances (identified with VID tag 100 and 500) used to exchange R-APS messages for the two control instances created on the ring. 
    configure> service
     vpls 10 customer 1 create // Ring APS SAPs
          description "Ring Control VID 100"
          sap 1/1/1:100 eth-ring 1 create  // TAG for the Control Path a
          exit
          sap 6/6/2:100 eth-ring 1 create  // TAG for the Control Path b
          exit
          no shutdown
     exit
configure> service
     vpls 40 customer 1 create //Data Channel on Ring
          description "Ethernet Ring 1 VID 500"
          sap 1/1/1:500 eth-ring 1 create   // TAG for the Data Channel Path a
          exit
          sap 6/6/2:500 eth-ring 1 create   // TAG for the Data Channel Path b
          exit
     exit
  3. Configure VPLS data services that will use G.8032 for protection. 
    configure> service vpls 1001 // CPE traffic
          sap 3/1/2:400.1 create 
          // CPE SAP
          exit

          sap 6/6/1:2000 create
          // uplink SAP
          exit

          no shutdown
     exit

configure> service vpls 1001 // CPE traffic
          sap 2/2/1:100.50 create 
          // CPE SAP
          exit

          sap 6/6/1:600 create
          // uplink SAP
          exit

          no shutdown
     exit

G.8032 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, as shown in the following figure.

Note:

Only the 7210 SAS-Dxp can be used as an interconnection node. Other 7210 SAS platforms described in this document can only be used as ring nodes in the sub-ring.

Figure 10. Major ring and sub-ring scenario

The following figure shows a major ring and sub ring scenario. 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.

Figure 11. G.8032 sub-ring

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.

G.8032 virtual and non-virtual channel

The following is a sample sub-ring using virtual-link configuration 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

G.8032 Ethernet ring sub-ring using non-virtual link

The following figure shows 0 to 6 sub-ring homed to VPLS.

Note:

This solution is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, and these nodes can only be the ring nodes. They cannot be used as the interconnection PE nodes.

Figure 12. 0 to 6 sub-ring homed to VPLS
Configuration Outputs for sub-rings using non-virtual link configurations

The following is a sample sub-ring using non-virtual link configuration 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

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

The following is a sample sub-ring using non-virtual link configuration 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

G.8032 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.

Up MEPs on service SAPs that multicast into the service and monitor the active path may be used to monitor services.

G.8032 QoS considerations

Ethernet ring CC messages transmitted over the SAP queues using the default egress QoS policy will use NC (network class) as a forwarding class. If user traffic is assigned to the NC forwarding class, it will compete 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.

Note:

The operator must configure appropriate ingress QoS policies to ensure that R-APS messages get appropriate QoS treatment and is processed and/or transmitted without delays to enable better failover time.

G.8032 service and solution combinations

Ethernet rings are a supported Layer 2 service. The following considerations apply:

  • Only ports in access mode and access-uplink mode can be configured as eth-ring paths.

  • Dot1q and QinQ ports are supported as eth-ring path members.

G.8032 configuration guidelines

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.

  • G.8032 instances cannot be configured over a LAG.

  • For 7210 SAS-D and 7210 SAS-Dxp devices, to improve the service fail-over time due to failures in the ring path, fast flood is enabled by default. 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 affect scaling for filters/ACLs.

  • For 7210 SAS-D and 7210 SAS-Dxp devices, Down MEPs used with services and G.8032 share common hardware resources.

  • All 7210 SAS-K platforms support fast-flood by default to improve service fail-over time. It does not require explicit user configuration and does not share resources with either Filters/ACLS or Service Down MEPs.

Layer 2 control processing

Operators providing Epipe and VPLS services 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 the L2PT and BPDU translation.

Note:

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 multi-point 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 protocols, protocols not supported on 7210 (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 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 lists the L2CP support on 7210 SAS platforms.

Table 5. L2CP support on the 7210 SAS

Packet Type

7210 SAS-D, 7210 SAS-Dxp

7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

LACP

Option to tunnel or discard or peer

Option to tunnel or discard or peer

Dot1x

Option to tunnel or discard or peer

Option to tunnel or discard or peer

LLDP

Option to tunnel or discard or Peer 1

Option to tunnel or discard or peer 1

EFM

Option to tunnel or discard or peer

Option to tunnel or discard or peer

L2PT

Supported

Supported

BPDU Tunneling

Supported

Supported

xSTP

Option to peer or tunnel

Option to peer or tunnel

ESMC protocol

Option to tunnel or discard or peer

Option to tunnel or discard or peer
1 See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Interface Configuration Guide for more information about the options available for LLDP tunneling.

Dynamic VLAN assignment using dot1x RADIUS authentication with EHS

Note:

Dynamic VLAN assignment using dot1x RADIUS authentication with EHS is only supported on the 7210 SAS-Dxp.

On the 7210 SAS, users can assign a VLAN using the RADIUS tunnel attribute. Only the VLAN is returned by RADIUS, while other policies (such QoS, ACLs, accounting) are not. The locally configured policies can be applied when the VLAN ID is used to configure the SAP after a successful authentication of the host using dot1x (including MAC authentication).

Assignment of a VLAN after a host is authenticated using dot1x

The 7210 SAS provides support for RADIUS-based dot1x or MAC authentication to authenticate network access in enterprise networks. If RADIUS authentication is successful on the port on which the dot1x frames are received or the packet that triggered MAC authentication, access is unblocked and the user is granted access to the network. In addition, the RADIUS message contains the VLAN ID that is assigned to the traffic received on the port. The SAP for the user along with the QoS policy, ACLs, or accounting policy can be configured using EHS only after the VLAN tag information is received upon a successful authentication.

During an unsuccessful authentication, the port is blocked, preventing network access.

It is expected that the service is preconfigured with uplinks and service parameters (if any), including preconfiguration of the access port (for example, port mode and encap, MTU, and so on) to which the device is connected. During a successful authentication, only the access SAP with the appropriate VLAN along with any policies associated with SAP can be configured using EHS scripts.

To achieve this functionality, the event handling system (EHS) script must be configured so that the script is invoked with the appropriate parameters received from the RADIUS server to allow the script to configure the SAP and the policies associated with the SAP for the user.

The following figure shows how devices are mapped to a VLAN (service and SAP in the SR OS context) in an enterprise network. The devices can send tagged or untagged traffic, and use port, MAC, or VLAN authentication.

Note:

When using VLAN authentication, dynamic VLAN assignment procedures are trigerred. The device must know the VLAN to use for dot1x authentication which can be assigned using LLDP-MED. It is expected that the device continues to use the same VLAN for service traffic after authentication is completed successfully, though there are no checks enforced by the node to ensure the same VLAN is used.

Figure 13. Dynamic VLAN assignment using dot1x in enterprise

In the preceding figure, the user has connected a camera that sends untagged traffic using MAC authentication, a Wi-Fi AP that sends tagged traffic using port authentication, and a laptop that sends untagged traffic using MAC authentication. Based on the VLAN returned by the RADIUS server, the traffic from each of these devices is mapped to a different VPLS with the appropriate SAP configured to accept tagged and untagged traffic from the devices connected to the 7210 SAS.

Note:

VPLS with SAPs to accept tagged and untagged traffic is used in SR OS to implement a VLAN bridge service.

Assigning a VLAN to a device based on dot1x authentication

Perform this procedure to achieve the scenario described in Assignment of a VLAN after a host is authenticated using dot1x.
  1. Configure dot1x, MAC, or VLAN authentication on the required ports.
  2. If an EAPOL request is received on the port, use the EAPOL message to authenticate the connected device; or if the device connected to the port is not capable of dot1x, then use the source MAC address from the first packet received on the port to authenticate the device by sending the dot1x request to the RADIUS server for authentication.
  3. If the RADIUS server has returned an authentication "SUCCESS", it is expected to also send the VLAN to be configured for the port. The software triggers the EHS scripts associated with the dot1x "tmnxPortDot1xAuthSuccess" event and it is expected that the EHS script performs the following:
    1. Configure the access SAP using the VLAN and authenticated port, and associate it with the appropriate service.
      Note:

      The VPLS service is preconfigured with only the uplinks (access SAPs are added dynamically). In addition, the access port is preconfigured with appropriate port mode and encap type.

    2. Configure the other SAP policies (QoS, ACL, accounting, and so on) and other parameters.
      Note:

      See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C System Management Guide for more information about EHS and script configuration examples.

Guest and restricted VLAN service support

The 7210 SAS allows a host or device configured with a corporate VLAN to connect to the company network (for example, devices used by employees), and a guest or restricted VLAN for devices used by visitors to allow internet access. To access the corporate VLAN, the employee device must successfully authenticate using 802.1x through a RADIUS server that acts as the AAA server.

The following figure shows a simplified architecture in which a host connected to the switch needs to connect to the network. There are three possibilities:

  • VPLS 1 – corporate VLAN access if 802.1x authentication is successful

  • VPLS 2 – restricted VLAN access if 802.1x authentication fails

  • VPLS 3 – guest VLAN if the device does not send EAPOL packets or if there is no response from the RADIUS server

Figure 14. Corporate or guest VPLS assignment based on 802.1x authentication outcome

When the RADIUS server returns an authentication failure and there is no response from the RADIUS server, or if dot1x authentication is enabled on a port but no EAPOL packets are received from the connected device, the connected user or device must assign a guest or restricted VLAN.

Assign a guest VLAN when there is no response from the RADIUS server or when dot1x authentication is enabled on a port but no EAPOL packets are received from the connected device.

Assign a restricted VLAN when the RADIUS server returns authentication failure.

Use the following commands to configure a guest or restricted VLAN:

  • config>port>ethernet>dot1x>guest-service service-id [vlan-id vlan-id]

  • config>port>ethernet>dot1x>restricted-service service-id [vlan-id vlan-id]

Use the EHS script to configure a service-id or svc-name to specify the service under which the SAP must be configured. The EHS script must use the NULL (“:0”) tag to configure a NULL SAP if the optional vlan-id is not configured. If the vlan-id is configured, it is used as the SAP tag.
Note: The configured vlan-id cannot be modified if the config>port>ethernet>dot1x>port-control command is set to auto. To modify the service and VLAN ID information, users must set the config>port>ethernet>dot1x>port-control command to either force-auth or force-unauth.

Similar to the successful authentication scenario in which the VLAN provided by the RADIUS server is passed to the EHS script, information about the configured guest VLAN and restricted VLAN is passed to the EHS script for configuration of the SAP in the appropriate service. Specifically, the software passes the service-id or svc-name and the configured vlan-id to EHS script. The configured service-id can reference an Epipe or VPLS service (or a Layer 3 service).

The following log events have been added to allow the user to create and delete the guest and restricted VLAN service:

  • tmnxPortDot1xAuthLostGRvC

    This log event invokes the EHS script that must be used to configure the SAP in the service used for guest and restricted VLAN services.

  • tmnxPortDot1xAuthLostGRvD

    This log event invokes the EHS script that must be used to delete the SAP in the service used for guest and restricted VLAN services.

Configuration guidelines

The following configuration guidelines apply to dynamic VLAN assignment using dot1x RADIUS authentication with EHS:

  • To assign the SAP and a service based on the VLAN ID obtained from the RADIUS server, an EHS script must be provided. The EHS script is expected to use the parameters passed to the script and the appropriate CLI commands supported by the node to create the SAP in the required service. For an example see the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C System Management Guide.

  • The SAPs created through EHS scripts are treated as dynamic SAPs. Dynamic SAPs are not saved in the configuration file and do not survive reboots. Upon a reboot, the device or user is authenticated afresh, and as a result, the EHS script is executed again to create the SAP and associate it with a service.

  • Dynamic SAPs are identified as “Dynamic SAPs” in the show command output.

  • It is mandatory to use the VLAN ID returned by the RADIUS server as the service-delimiting VLAN tag of the SAP created through the EHS script. The software uses the VLAN ID to identify dynamic SAPs created through EHS scripts.

  • An EHS script must be provided for the dot1x authentication lost event (for example, tmnxPortDot1xAuthLost). The script is expected to remove the SAP configuration.

  • For the RADIUS server, the "Tunnel-Type" value is set to 13, the "Tunnel-Medium-Type" value is 6, and the "Tunnel-Private-Group-Id" value refers to the VLAN ID.

  • The value configured with the config>port>ethernet>dot1x>server>timeout command must be greater than the timeout value configured with the config>system>security>radius>timeout and config>system>security>radius>retry commands. This allows for sufficient time before the software can timeout the authentication attempt with the RADIUS server before attempting dot1x authentication again.

Service creation process overview

This section provides an overview of the service creation process with access-uplink ports.

The following figure shows the overall process to provision core and subscriber services.

Figure 15. Service creation and implementation flow

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:

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.

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/or 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 caveats.

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:

  • 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

Common configuration tasks

This section provides a brief overview of the tasks that must be performed to configure a customer account

Configuring customer accounts

Subscribers

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

The following is a sample basic customer account configuration output.

A:ALA-12>config>service# info
-------------------------------------------
...
       customer 5 create
           description "Alcatel Customer"
           contact "Technical Support"
           phone "650 555-5100"
       exit
...
-------------------------------------------
A:A:ALA-12>config>service#

Service creation process overview on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The following figure shows the overall process to provision core and subscriber services.

Note:

Service creation with MPLS uplinks using SDPs for interconnecting routers is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

Figure 16. Service creation and implementation flow

Deploying and provisioning services on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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.

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

  • Configure access-uplink SAPs (if only Layer 2 uplinks are needed).

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/or accounting policies needed to support the core services.

Phase 3: service provisioning

  • 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, binding policies to the SAPs.

Configuration notes

This section describes service configuration caveats.

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

  • Create SDPs (if using MPLS uplinks)

Subscriber services tasks include the following:

  • Create Epipe and VPLS services.

  • Create a VPRN service

  • Bind SDPs (if using MPLS uplinks)

  • 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 using MPLS uplinks.

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:Dut-B>config>service# info 
----------------------------------------------
        sdp 1 mpls create
            far-end 10.20.1.2
            ldp
            keep-alive
                shutdown
            exit
            no shutdown
        exit
        customer 1 create
            description "Default customer"
        exit
        epipe 101 customer 1 svc-sap-type any create
            spoke-sdp 1:1 create
                no shutdown
            exit
            no shutdown
        exit
----------------------------------------------

Common configuration tasks

This section provides a brief overview of the tasks performed to configure a customer account and an SDP. SDP configuration is not needed when 7210 SAS devices are configured to use only access-uplink ports.

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

The following is a sample basic customer account configuration output.

*A:K-SASK12>config>service>cust# info detail
----------------------------------------------
description "default Customer"
contact "Technical Support"
phone "650 555-5100"
----------------------------------------------
*A:K-SASK12>config>service>cust#

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 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, IES 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.

Note:

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 CLI syntax to create an SDP and select an encapsulation type. Only MPLS encapsulation is supported.

Note:

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-K 2F6C4T, K 3SFP+ 8C MPLS Guide for configuration and command information.

Use the following syntax to create an MPLS SDP.

config>service>sdp sdp-id [mpls] create

The following is a sample LSP-signaled MPLS SDP configuration output.

*A:K-SASK12>config>service>sdp$ info detail
----------------------------------------------
exit
        sdp 1 mpls create
            shutdown
            no description
            signaling tldp
            no ldp
            no bgp-tunnel
            no path-mtu
            no adv-mtu-override
            keep-alive
                shutdown
                hello-time 10
                hold-down-time 10
                max-drop-count 3
                timeout 5
                no message-length
            exit
----------------------------------------------
*A:K-SASK12>config>service>sdp$

Configuring a mixed-LSP SDP

The following shows the command usage 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 will fail.

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.

ETH-CFM

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.

ETH-CFM configuration is split into multiple CLI contexts. The base ETH-CFM configuration, that defines the different management constructs and administrative elements, 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-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Services Guide for more 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.

The supported features vary across services and depending on different 7210 SAS platforms.

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-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C OAM and Diagnostics Guide for a description of 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.

Table 6. Service endpoint and MEP/MIP acronyms

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)

GNM

Generic Notification Message

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 scenarios for ETH-CFM deployment in Ethernet access and aggregation networks.

Figure 17. Ethernet OAM model for Ethernet access - business
Figure 18. Ethernet OAM model for Ethernet access - wholesale

The following functions are supported:

  • On the 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T, CFM can be enabled or disabled on a per-SAP basis.

  • On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, CFM can be enabled or disabled on a per-SAP and per-SDP binding 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.

  • 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 and 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. The following table lists the support available for MEP on different 7210 platforms.

    • On the 7210 SAS-D and 7210 SAS-Dxp, Up MEPs cannot be created by default on system bootup. See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C OAM and Diagnostics Guide for more information about ETH-CFM configuration guidelines.

  • 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-D and 7210 SAS-Dxp have the notion of ingress and egress MIPs. That is, on these platforms, MIPs are not bidirectional by default. 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 ETH-CC defect condition groups. See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C OAM and Diagnostics Guide for more information.

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.

Table 7. ETH-CC defect condition groups

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-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C OAM and Diagnostics Guide for more information about ETH-CFM support for the different services and endpoints.

Configuring ETH-CFM parameters

Note:

See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C 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.

The following is a sample 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#

Defining the MEP and configuring service-specific ETH-CFM parameters is performed within the service on the specific SAP or SDP binding.

The example using the service VPLS 100 shows this configuration 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#

The preceding samples 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.

The following are samples of the global ETH-CFM configuration output and the advanced Y.1731 functions that can be configured. The configuration will reject 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
----------------------------------------------
Note:

  • To be able to transmit and receive AIS PDUs, a Y.1731 MEP must have ais-enable set.

  • To be able to transmit and receive ETH-Test PDUs, a Y.1731 MEP must have eth-test-enable set.

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 parameters (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

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

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

Global services command reference

Command hierarchies

Pseudowire (PW) commands for 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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
            - [no] discard-unknown-source
            - hash-label [signal-capability]
            - no hash-label
            - [no] force-vlan-vc-forwarding
            - igmp-snooping
                - [no] disable-router-alert-check
                - 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
            - limit-mac-move {blockable | non-blockable}
            - no limit-mac-move
            - [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

Pseudowire (PW) routing commands for 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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 [community community]
            - 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

SDP commands for 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

config
    - service
        - sdp sdp-id [mpls] [create]
        - no sdp sdp-id
            - accounting-policy acct-policy-id
            - no accounting-policy
            - booking-factor percentage
            - no booking-factor
            - 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 
            - 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 | bgp]
            - [no] sr-isis 
            - [no] sr-ospf

SAP commands for 7210 SAS-D and 7210 SAS-Dxp

config
    - service
        - epipe service-id [customer customer-id] [create] [svc-sap-type {null-star | dot1q-preserve | any | dot1q-range}] [customer-vid vlan-id]
        - no epipe service-id
            - sap sap-id [create]
            - no sap sap-id
        - ies service-id [customer customer-id] [create]
        - no ies service-id
            - interface address {ip-address/mask | ip-address netmask} [broadcast {all-ones | host-ones}] 
                - sap sap-id [create] 
                - no sap sap-id
        - vpls service-id [customer customer-id] [create] [vpn vpn-id] [m-vpls] [svc-sap-type {null-star | any | dot1q-preserve}] [customer-vid vlan-id]
        - no vpls service-id
            - sap sap-id [create] [eth-ring ring-index]
            - no sap sap-id

SAP commands for 7210 SAS-K 2F1C2T

config
    - service
        - epipe service-id [customer customer-id] [create] [svc-sap-type {any | dot1q-range}]
        - no epipe service-id
            - sap sap-id [create]
            - no sap sap-id
        - ies service-id [customer customer-id] [create] [vpn vpn-id]
        - no ies service-id
        - vpls service-id [customer customer-id] [create] [m-vpls] [svc-sap-type {any | dot1q-range}] [r-vpls]
        - no vpls service-id
            - sap sap-id [create] [split-horizon-group group-name]
            - no sap sap-id

SAP commands for 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

config
    - service
        - epipe service-id [customer customer-id] [create] [svc-sap-type {any | dot1q-range}]
        - no epipe service-id
            - sap sap-id [create]
            - no sap sap-id
        - ies service-id [customer customer-id] [create] [vpn vpn-id]
        - no ies service-id
        - vpls service-id [customer customer-id] [create] [m-vpls] [svc-sap-type {any | dot1q-range}] [r-vpls]
        - no vpls service-id
            - sap sap-id [create] [split-horizon-group group-name]
            - no sap sap-id
        - vprn service-id [customer customer-id] [create] 
        - no vprn service-id

ETH-CFM configuration commands

Note:

For command descriptions, see the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C 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-id-identifier bridge-id
                    - id-permission {chassis}
                    - no id-permission
                    - mhf-creation {default | none | explicit| 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-mepid mep-id
        - slm
            - inactivity-timer timer
            - no inactivity-timer
        - system 
            - enable-dmm-version-interop
            - no enable-dmm-version-interop
            - sender-id local local-name
            - sender-id system
            - no sender-id

Show commands

show
    - service
        - customer [customer-id] [site customer-site-name]
        - id service-id
        - sdp sdp-id keep-alive-history
        - sdp far-end ip-address keep-alive-history
        - sdp [sdp-id] [detail]
        - sdp far-end ip-address [detail]
        - pw-template-using sdp-id pw-port [pw-port-id]
        - pw-template-using [consistent | inconsistent | na] egressifs
        - pw-template-using sdp-id keep-alive-history
        - pw-template-using far-end ip-address keep-alive-history
        - pw-template-using [sdp-id] [detail]
        - pw-template-using far-end ip-address [detail]
        - sdp-using [sdp-id[:vc-id] | far-end ip-address]
        - service-using [epipe] [ies] [vpls] [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]
        - 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]
        - pw-routing {local-prefix | static-route | paths | all}
        - pw-routing route-table [all-routes]
        - pw-routing route-table summary

Command descriptions

Global service configuration commands

Generic commands
shutdown
Syntax

[no] shutdown

Context

config>eth-cfm>mep

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 any configuration settings or statistics.

The operational state of the entity is disabled, as well as the operational state of any entities contained within. Many objects must be shut down before they may be deleted.

Services are created in the administratively down (shutdown) state. When a no shutdown command is entered, the service becomes administratively up, then tries to enter the operationally up state. Default administrative states for services and service entities is described as follows in Special Cases.

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

Special Cases
Service Admin State

While the service is shut down, all customer packets are dropped and counted as discards for billing and debugging purposes.

description
Syntax

description description-string

no description

Context

config>service>customer

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.

This command associates a text string with a configuration context to help identify the content in the configuration file.

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

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

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

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

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

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

Parameters
customer-id

Specifies the ID number to be associated with the customer, expressed as an integer.

Values

1 to 2147483647

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 for 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
pw-routing
Syntax

pw-routing

Context

config>service

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure dynamic multi-segment pseudowire (MS-PW) routing. Pseudowire routing must be configured on each node that will be a T-PE or an S-PE.

boot-timer
Syntax

boot-timer secs

no boot-timer

Context

config>service>pw-routing

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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 restores it to the default.

Default

10

Parameters
secs

Specifies the value of the boot timer in seconds.

Values

0 to 600

local-prefix
Syntax

local-prefix local-prefix [create]

no local-prefix local-prefix

Context

config>service>pw-routing

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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 7210 SAS node. The global ID can contain the 2-octet or 4-octet value of the provider Autonomous System (AS) number. The presence of a global ID based on the provider AS number ensures that the AII for spoke-SDPs configured on the node is globally unique.

Values

global-id:ip-addr | raw-prefix

ip-addr: a.b.c.d

global-id: 1 to 4294967295

raw-prefix: 1 to 4294967295

advertise-bgp
Syntax

advertise-bgp route-distinguisher rd [community community]

no advertise-bgp route-distinguisher rd

Context

config>service>pw-routing

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

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

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 7210 node. The global ID can contain the 2-octet or 4-octet value of the provider AS number. The presence of a global ID based on the provider AS number ensures that the AII for spoke-SDPs configured on the node are globally unique.

Values

(6 bytes, other 2 bytes of type are automatically generated) asn:number1 (RD Type 0): 2bytes ASN and 4 bytes locally administered number ip-address:number2 (RD Type 1): 4bytes IPv4 and 2 bytes locally administered number

community community

Specifies an optional BGP communities attribute associated with the advertisement. To delete a previously advertised community, the advertise-bgp route-distinguisher command must be run again with the same value for the RD but excluding the community attribute.

Values

community:

{2-byte-as-number:comm-va1}

2-byte-asnumber:

1 to 65535

comm-va1:

0 to 65535
path
Syntax

path name [create]

no path name

Context

config>service>pw-routing

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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 multi-segment pseudowires. Paths are used by a T-PE to populate the list of explicit route TLVs included in the signaling of a dynamic MS-PW.

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

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

Default

no path

Parameters
path-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>hop

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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 before deleting the hop from the hop list. The no hop hop-index command does not result in any action, except for a warning message on the console indicating that the path is administratively up.

Default

no hop

Parameters
hop-index

Specifies a locally significant numeric identifier for the hop. The hop index is used to order the specified hops. The LSP always traverses from the lowest hop index to the highest. The hop index does not need to be sequential.

Values

1 to 16

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 appropriate SDP to use.

retry-count
Syntax

retry-count [count]

no retry-count

Context

config>service>pw-routing

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

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

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

Default

30

Parameters
count

Specifies the maximum number of retries before putting the spoke-SDP into the shutdown state.

Values

10 to 10000

retry-timer
Syntax

retry-timer secs

no retry-timer

Context

config>service>pw-routing

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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

Default

30

Parameters
secs

Specifies the initial retry-timer value in seconds.

Values

10 to 480

spe-address
Syntax

spe-address global-id:prefix

no spe-address

Context

config>service>pw-routing

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description
Note:

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

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

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

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

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

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

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 AS number.

Syntax: global-id:prefix: global-id:{prefix|ipaddress}

Values

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

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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.

Values

route-name:

global-id:prefix:next-hop-ip_addr

global-id:

0 to 4294967295

prefix:

a.b.c.d. | 0to 4294967295

next-hop-ip_addr:

a.b.c.d
pw-template
Syntax

[no] pw-template policy-id [use-provisioned-sdp] [create]

Context

config>service

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures an SDP template.

Parameters
policy-id

Specifies a number that uniquely identifies a template for the creation of an SDP.

Values

1 to 2147483647

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 the instantiation of the SDP.

create

Keyword required when first creating the configuration context. When the context is created, it is possible to navigate into the context without the create keyword.

control-word
Syntax

[no] control-word

Context

config>service>pw-template

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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 control word for VLL services. The configuration for the two directions of the Ethernet pseudowire should match.

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

Default

no control-word

SDP commands
sdp
Syntax

sdp sdp-id [mpls] [create]

no sdp sdp-id

Context

config>service

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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

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

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

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

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

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

Parameters
sdp-id

Specifies the SDP identifier.

Values

1 to 17407

mpls

Keyword to specify that the SDP uses MPLS encapsulation.

accounting-policy
Syntax

accounting-policy acct-policy-id

no accounting-policy

Context

config>service>sdp

config>service>pw-template

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

A maximum of one accounting policy can be associated with a SDP at one time. Accounting policies are configured in the config>log context.

The no form of this command removes the accounting policy association from the SDP, and the accounting policy reverts to the default.

Default

Default accounting policy.

Parameters
acct-policy-id

Specifies the accounting policy-id as configured in the config>log>accounting-policy context.

Values

1 to 99

booking-factor
Syntax

booking-factor percentage

no booking-factor

Context

config>service>sdp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the booking factor applied against the maximum SDP available bandwidth for the VLL CAC feature.

The service manager tracks the available bandwidth for each SDP. The maximum value is the sum of the bandwidths of all constituent LSPs in the SDP. The SDP available bandwidth is adjusted by the user-configured booking factor. A value of 0 means no VLL can be admitted into the SDP.

Note:

On 7210 SAS platforms, only a single LSP can be configured in the SDP.

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

Default

booking-factor 100

Parameters
percentage

Specifies the percentage of the SDP maximum available bandwidth for VLL call admission. When the value of this parameter is set to zero, no new VLL spoke SDP bindings with non-zero bandwidth are permitted with this SDP. Overbooking of more than 100% is allowed.

Values

0 to 1000

collect-stats
Syntax

[no] collect-stats

Context

config>service>sdp

config>service>pw-template

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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

disable-learning
Syntax

[no] disable-learning

Context

config>service>pw-template

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command enables learning of new MAC addresses.

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

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

Default

no disable-learning (normal MAC learning is enabled)

discard-unknown-source
Syntax

[no] discard-unknown-source

Context

config>service>pw-template

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

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

Default

no discard-unknown

egress
Syntax

egress

Context

config>service>pw-template

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure spoke-SDP binding egress filter parameters.

ingress
Syntax

ingress

Context

config>service>pw-template

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure spoke-SDP binding ingress filter parameters.

hash-label
Syntax

hash-label [signal-capability]

no hash-label

Context

config>service>pw-template

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the hash label on VLL or VPLS services that are bound to RSVP SDP, 3107 BGP SDP, segment routing, or LDP SDP, using the auto-bind mode with the ldp, rsvp-te, or mpls options. When this command is enabled, the ingress 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 ingress datapath appends the hash label at the bottom of the stack (BoS) and sets the S-bit to one (1).

Note:

On 7210 SAS devices, hash label is not used on the local node for ECMP and LAG hashing. It is available for use by LSR nodes, through which the traffic flows, that are capable of using the labels for hashing.

Packets generated in the CPM that are forwarded with a label within the context of a service (for example, OAM packets) must also include a hash label at the BoS and set the S-bit accordingly.

The TTL of the hash label is set to 0.

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

  • 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 also drops user and control plane packets received from a 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 a 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 a hash label. The local PE node drops user and control plane packets from the remote PE without a hash label.

If the hash-label command is enabled on the local PE with the signal-capability option configured and on the remote PE without the signal-capability option configured on the spoke-SDP or mesh-SDP, the hash label is included in the pseudowire packets received by the local PE. These packets must be dropped. To resolve this situation, you must disable the signal-capability option on the local node, which results in the insertion of the hash label by both PE nodes.

If the hash-label option is not supported or is not enabled on the local configuration of the spoke-SDP or mesh-SDP at the remote PE, the hash label is not included in the pseudowire received by the local PE.

If the signal-capability option is enabled or disabled in the CLI, the router must withdraw the label it sent to its peer and send a new label mapping message with the new value of the F bit in the flow label interface parameters sub-TLV of the PW ID FEC element.

Note:

  • This feature is supported only for VLL and VPLS services. It is not supported for VPRN services. It is also not supported on multicast packets forwarded using RSVP P2MP LPS or mLDP LSP in both the base router instance and in the multicast VPN (mVPN) instance.

  • In 7750 and possibly other vendor implementations, to allow applications where the egress LER infers the presence of the hash label implicitly from the value of the label, the Most Significant Bit (MSB) of the result of the hash is set before copying into the hash label. This means that the value of the hash label is always in the range [524,288 to 1,048,575] and does not overlap with the signaled/static LSP and signaled/static service label ranges. This also guarantees that the hash label does not match a value in the reserved label range. 7210 SAS devices do not set the MSB in the hash label value for service traffic. Therefore, the user must ensure that both ends are correctly configured to either process hash labels or disable them. The MSB bit is set for MPLS/OAM traffic on 7210 SAS devices.

  • The cpe-ping, mac-ping, and svc-ping commands are not supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C when the hash-label command is enabled.

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

Default

no hash-label

Parameters
signal-capability

Keyword that specifies to enable the signaling and negotiation of the use of the hash label between the local and remote PE nodes.

force-vlan-vc-forwarding
Syntax

[no] force-vlan-vc-forwarding

Context

config>service>pw-template

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command forces vc-vlan-type forwarding in the datapath for spoke and mesh SDPs that have either vc-type. This command is not allowed on vlan-vc-type SDPs.

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

Default

no force-vlan-vc-forwarding

split-horizon-group
Syntax

split-horizon-group group-name [create]

Context

config>service>vpls

config>service>pw-template

Platforms

7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

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

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

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

Parameters
group-name

Specifies the name of the split horizon group to which the SAP or spoke-SDP belongs.

create

Mandatory keyword to create a split-horizon group.

vc-label
Syntax

[no] vc-label vc-label

Context

config>service>pw-template>ingress

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the ingress VC label.

Parameters
vc-label

Specifies a VC ingress value that indicates a specific connection.

Values

2048 to 18431

limit-mac-move
Syntax

limit-mac-move [blockable | non-blockable]

no limit-mac-move

Context

config>service>pw-template

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

Default

blockable

Parameters
blockable

Keyword to specify the agent will monitor the MAC relearn rate and will block it when the relearn rate is exceeded.

non-blockable

Keyword to specify that a SAP will not be blocked, and another blockable SAP will be blocked instead.

vc-type
Syntax

vc-type {ether | vlan}

Context

config>service>pw-template

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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 that represents the type of VC. The actual signaling of the VC type depends on the signaling parameter defined for the SDP. If signaling is disabled, the vc-type command can still be used to define the dot1q value expected by the far-end provider equipment.

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

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

  • The VC type value for Ethernet is 0x0005.

  • The VC type value for an Ethernet VLAN is 0x0004.

Parameters
ether

Keyword that defines the VC type as Ethernet. The ethernet 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

Keyword that defines the VC type as VLAN. The ethernet and vlan keywords are mutually exclusive. When the VC type is not defined then 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

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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 not specifying the 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.

Values

0 to 4094

adv-mtu-override
Syntax

[no] adv-mtu-override

Context

config>service>sdp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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 whose value matches either its advertised MTU or its advertised MTU minus the Layer 2 headers.

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

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

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

Default

no adv-mtu-override

bgp-tunnel
Syntax

[no] bgp-tunnel

Context

config>service>sdp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

Note:

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

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

Default

no bgp-tunnel

far-end
Syntax

far-end ip-address node-id node-id

no far-end

Context

config>service>sdp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

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

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

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

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

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

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

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

Parameters
ip-address

Specifies the system address of the far-end device 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 or an unsigned 32-bit integer.

Values

a.b.c.d

1 to 4294967295

metric
Syntax

metric metric

no metric

Context

config>service>sdp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

Parameters
metric

Specifies the SDP metric.

Values

0 to 65535

mixed-lsp-mode
Syntax

[no] mixed-lsp-mode

Context

config>service>sdp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

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

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

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

  • RSVP LSP type — one RSVP LSP can be configured per SDP.

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

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

Note:

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

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

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

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

Default

no mixed-lsp-mode

revert-time
Syntax

revert-time {revert-time | infinite}

no revert-time

Context

config>service>sdp>mixed-lsp-mode

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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.

Values

0 to 600

infinite

Keyword that 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

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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 with 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

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

In MPLS SDP configurations one LSP can be specified.

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

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

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

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

signaling
Syntax

signaling {off | tldp | bgp}

Context

config>service>sdp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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

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

Default

tldp

Parameters
off

Keyword to specify that ingress and egress signal auto-labeling is not enabled. If this parameter 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

Keyword to specify that ingress and egress pseudowire signaling using T-LDP is enabled.

bgp

Keyword to specify that ingress and egress pseudowire signaling using BGP is enabled. This keyword is the default value used when BGP VPLS automatically instantiates the SDP.

sr-isis
Syntax

[no] sr-isis

Context

config>service>sdp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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

Default

no sr-isis

sr-ospf
Syntax

[no] sr-ospf

Context

config>service>sdp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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

Default

no sr-ospf

path-mtu
Syntax

path-mtu bytes

no path-mtu

Context

config>service>sdp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

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

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

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

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

Parameters
bytes

Specifies the number of bytes in the path MTU.

Values

576 to 9194

SDP keepalive commands
keep-alive
Syntax

keepalive

Context

config>service>sdp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

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

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

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

hello-time
Syntax

hello-time seconds

no hello-time

Context

config>service>sdp>keep-alive

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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

Default

hello-time 10

Parameters
seconds

Specifies the time period, in seconds, between SDP keepalive messages, expressed as a decimal integer.

Values

1 to 3600

hold-down-time
Syntax

hold-down-time seconds

no hold-down-time

Context

config>service>sdp>keep-alive

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

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

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

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

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 will be enforced for the SDP ID.

Values

0 to 3600

Default

10

max-drop-count
Syntax

max-drop-count count

no max-drop-count

Context

config>service>sdp>keep-alive

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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 operationally downed.

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

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

Parameters
count

Specifies the number of consecutive SDP keepalive requests that are failed to be sent or replies missed, expressed as a decimal integer.

Values

1 to 5

Default

3

message-length
Syntax

message-length octets

no message-length

Context

config>service>sdp>keep-alive

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

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

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.

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.

Values

40 to 9198

Default

0

timeout
Syntax

timeout timeout

no timeout

Context

config>service>sdp>keep-alive

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

Parameters
timeout

Specifies the timeout in seconds.

Values

1 to 10

Default

5

Tools perform commands for 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
tools
Syntax

tools

Context

root

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context enable useful tools for debugging purposes.

perform
Syntax

perform

Context

tools

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context enable tools to perform specific tasks.

service
Syntax

services

Context

tools>perform

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure tools for services.

id
Syntax

id service-id

Context

tools>perform>service

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command specifies a service for which to configure tools.

Parameters
service-id

Specifies an existing service ID.

Values

1 to 2147483647

endpoint
Syntax

endpoint endpoint-name

Context

tools>perform>service>id

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

Parameters
sdp-id

Specifies an existing spoke-SDP ID for the service.

Values

1 to 17407

vc-id

Specifies a virtual circuit ID.

Values

1 to 4294967295

spoke-sdp-fec spoke-sdp-fec-id

Specifies the spoke-SDP FEC ID for a FEC129 AII Type 2 spoke-SDP. This parameter is mutually exclusive with the sdp:vc-id used for a FEC 128 spoke-SDP4.

Output

The following output is an example of service endpoint information.

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 policy-id [allow-service-impact]

Context

tools>perform>service

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command reevaluates the pseudowire template policy.

Parameters
policy-id

Specifies the pseudowire template policy.

Values

1 to 2147483647

allow-service-impact

Keyword to reevaluate the pseudowire template even if the service is impacted.

eval-expired-fec
Syntax

eval-expired-fec spoke-sdp-fec-id

eval-expired-fec all

Context

tools>perform>service>pw-routing

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

Show, clear, debug commands

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

Values

1 to 2147483647

Default

All customer IDs display.

site customer-site-name

Specifies the customer site that 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 : 8
Contact     : Customer Service
Description : IES Customer
Phone       : (678) 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#
Table 8. Output fields: customer

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 a specific customer multi-service site.

Assignment

The port ID, MDA, or card number, where the SAPs 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 that shows the amount of time until the MAC address is aged out.

Output

The following output is an example of MAC address FDB entry 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#
Table 9. Output fields: FDB MAC

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

The time when the specific row entry was last changed.
sdp-using
Syntax

sdp-using [sdp-id[:vc-id] | far-end ip-address]

Context

show>service

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

Parameters
sdp-id

Displays only services bound to the specified SDP ID.

Values

1 to 17407

vc-id

Specifies the virtual circuit identifier.

Values

1 to 4294967295

far-end ip-address

Displays only services matching with the specified far-end IP address.

Default

services with any far-end IP address

Output

The following output is an example of information for services using SDP address options, 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#
Table 10. Output fields: SDP-using

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 [epipe][ies] [vpls] [mirror] [i-vpls] [m-vpls] [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 specific usage properties. If no optional parameters are specified, all services defined on the system are displayed.

Parameters
epipe

Displays matching Epipe services.

ies

Displays matching IES instances.

vpls

Displays matching VPLS instances.

mirror

Displays matching mirror services.

customer customer-id

Displays services only associated with the specified customer ID.

Values

1 to 2147483647

Default

services associated with a customer

Output

The following output is an example of information for services matching specific usage properties, 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#
Table 11. Output fields: service-using

Label

Description

Service Id

The service identifier.

Type

Specifies the service type configured for the service ID.

Adm

The desired 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.
id
Syntax

id service-id

Context

show>service

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command displays information about a specified service ID.

Parameters
service-id

Specifies the unique service ID number that identifies the service in the service domain.

Values

service-id: 1 to 2147483647

svc-name: a string up to 64 characters

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 ring information.

Parameters
ring-index

Specifies the ring index.

Values

1 to 128

status

Displays the status information of the Ethernet rings configured on the system.

hierarchy

Displays Ethernet ring hierarchical relationships.

path {a | b}

Displays information related to the configured Ethernet rings.

Output

The following outputs are examples of Ethernet ring information, and the associated tables describe the output fields.

Sample output 
*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#
Table 12. Output fields: eth-ring status

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.
Sample output 
*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

APS Tx PDU         : N/A
Defect Status      :


-------------------------------------------------------------------------------
Ethernet Ring Path Summary
-------------------------------------------------------------------------------
Path Port     Raps-Tag     Admin/Oper      Type            Fwd State
-------------------------------------------------------------------------------
  a  -        -                 -/-         -               -
  b  -        -                 -/-         -               -
===============================================================================
*A:NS1015C0821>show#
Table 13. Output fields: eth-ring

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

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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.

all-routes

Displays the PW routing table on this node. If all-routes is specified, the full routing table is displayed.

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

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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
-----------------------------------------------------------------------
pw-template-using
Syntax

pw-template-using

Context

show>service

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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

Output

The following output is an example of information about services that are using a PW template, and Output fields: PW template using describes the output fields.

Sample output 

*A:dut-a>show>service# pw-template-using 

============================================
Services using PW Template 
============================================
PW Template Id        SvcId
--------------------------------------------
5                     5
============================================
*A:dut-a>show>service#
Table 14. Output fields: PW template using

Label

Description

PW Template Id

The PW template identifier.

Svc ID

The service identifier.
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

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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.

Values

1 to 17407

Default

all SDPs

far-end ip-address

Displays only SDPs matching the specified far-end IP address.

Default

SDPs with any far-end IP address

detail

Displays detailed SDP information.

Default

SDP summary output

keep-alive-history

Displays the last fifty SDP keepalive events for the SDP.

Default

SDP summary output

Output

The following output is an example of SDP information for the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, and Output fields: service SDP describes the output fields.

Sample output 
*A:Dut-D# show service id 1 sdp 17407:4294967294 detail
=======================================================================
Service Destination Point (Sdp Id : 17407:4294967294) Details
=======================================================================
-------------------------------------------------------------------------------
 Sdp Id 17407:4294967294  -(not applicable)
-----------------------------------------------------------------------
Description     : (Not Specified)
SDP Id             : 17407:4294967294         Type              : VplsPmsi
Split Horiz Grp    : (Not Specified)
VC Type            : Ether                    VC Tag            : n/a
Admin Path MTU     : 9194                     Oper Path MTU     : 9194
Delivery           : MPLS
Far End            : not applicable
Tunnel Far End     : n/a                      LSP Types         : None
Hash Label         : Disabled                 Hash Lbl Sig Cap  : Disabled
Oper Hash Label    : Disabled
 
Admin State        : Up                       Oper State        : Up
Acct. Pol          : None                     Collect Stats     : Disabled
Ingress Label      : 0                        Egress Label      : 3
Ingr Mac Fltr-Id   : n/a                      Egr Mac Fltr-Id   : n/a
Ingr IP Fltr-Id    : n/a                      Egr IP Fltr-Id    : n/a
Ingr IPv6 Fltr-Id  : n/a                      Egr IPv6 Fltr-Id  : n/a
Admin ControlWord  : Not Preferred            Oper ControlWord  : False
Last Status Change : 12/14/2012 12:42:22      Signaling         : None
Last Mgmt Change   : 12/14/2012 12:42:19      Force Vlan-Vc     : Disabled
Endpoint           : N/A                      Precedence        : 4
PW Status Sig      : Enabled
Class Fwding State : Down
Flags              : None
Time to RetryReset : never                    Retries Left      : 3
Mac Move           : Blockable                Blockable Level   : Tertiary
Local Pw Bits      : None
Peer Pw Bits       : None
Peer Fault Ip      : None
Peer Vccv CV Bits  : None
Peer Vccv CC Bits  : None
Application Profile: None
Max Nbr of MAC Addr: No Limit                 Total MAC Addr    : 0
Learned MAC Addr   : 0                        Static MAC Addr   : 0
 
MAC Learning       : Enabled                  Discard Unkwn Srce: Disabled
MAC Aging          : Enabled
BPDU Translation   : Disabled
L2PT Termination   : Disabled
MAC Pinning        : Disabled
Ignore Standby Sig : False                    Block On Mesh Fail: False
Oper Group         : (none)                   Monitor Oper Grp  : (none)
Rest Prot Src Mac  : Disabled
Auto Learn Mac Prot: Disabled                 RestProtSrcMacAct : Disable
 
Ingress Qos Policy : (none)                   Egress Qos Policy : (none)
Ingress FP QGrp    : (none)                   Egress Port QGrp  : (none)
Ing FP QGrp Inst   : (none)                   Egr Port QGrp Inst: (none)
 
-----------------------------------------------------------------------
ETH-CFM SDP-Bind specifics
-----------------------------------------------------------------------
V-MEP Filtering    : Disabled
 
KeepAlive Information :
Admin State        : Disabled                 Oper State        : Disabled
Hello Time         : 10                       Hello Msg Len     : 0
Max Drop Count     : 3                        Hold Down Time    : 10
 
Statistics            :
I. Fwd. Pkts.      : 0                        I. Dro. Pkts.     : 0
I. Fwd. Octs.      : 0                        I. Dro. Octs.     : 0
E. Fwd. Pkts.      : 2979761                  E. Fwd. Octets    : 476761760
 
-----------------------------------------------------------------------
Control Channel Status
-----------------------------------------------------------------------
PW Status          : disabled                 Refresh Timer     : <none>
Peer Status Expire : false                    Clear On Timeout  : true
 
MCAC Policy Name   :
MCAC Max Unconst BW: no limit                 MCAC Max Mand BW  : no limit
MCAC In use Mand BW: 0                        MCAC Avail Mand BW: unlimited
MCAC In use Opnl BW: 0                        MCAC Avail Opnl BW: unlimited
 
-----------------------------------------------------------------------
RSVP/Static LSPs
-----------------------------------------------------------------------
Associated LSP List :
No LSPs Associated
 
-----------------------------------------------------------------------
Class-based forwarding :
-----------------------------------------------------------------------
Class forwarding   : Disabled                 EnforceDSTELspFc  : Disabled
Default LSP        : Uknwn                    Multicast LSP     : None
 
=======================================================================
FC Mapping Table
=======================================================================
FC Name             LSP Name
-----------------------------------------------------------------------
No FC Mappings
 

-----------------------------------------------------------------------
Stp Service Destination Point specifics
-----------------------------------------------------------------------
Stp Admin State    : Down                     Stp Oper State    : Down
Core Connectivity  : Down
Port Role          : N/A                      Port State        : Forwarding
Port Number        : 0                        Port Priority     : 128
Port Path Cost     : 10                       Auto Edge         : Enabled
Admin Edge         : Disabled                 Oper Edge         : N/A
Link Type          : Pt-pt                    BPDU Encap        : Dot1d
Root Guard         : Disabled                 Active Protocol   : N/A
Last BPDU from     : N/A
Designated Bridge  : N/A                      Designated Port Id: N/A
 
Fwd Transitions    : 0                        Bad BPDUs rcvd    : 0
Cfg BPDUs rcvd     : 0                        Cfg BPDUs tx      : 0
TCN BPDUs rcvd     : 0                        TCN BPDUs tx      : 0
TC bit BPDUs rcvd  : 0                        TC bit BPDUs tx   : 0
RST BPDUs rcvd     : 0                        RST BPDUs tx      : 0
-----------------------------------------------------------------------
Number of SDPs : 1
-----------------------------------------------------------------------
=======================================================================




*A:Dut-B#  show service sdp 204 detail 

=======================================================================
Service Destination Point (Sdp Id : 204) Details
=======================================================================
-----------------------------------------------------------------------
 Sdp Id 204  -10.20.1.4
-----------------------------------------------------------------------
Description           : (Not Specified)
SDP Id               : 204                   SDP Source         : manual
Admin Path MTU       : 0                     Oper Path MTU      : 1492
Delivery             : MPLS                  
Far End              : 10.20.1.4
Tunnel Far End       : n/a                   LSP Types          : RSVP
 
Admin State          : Up                    Oper State         : Up
Signaling            : TLDP                  Metric             : 0
Acct. Pol            : None                  Collect Stats      : Disabled
Last Status Change   : 02/12/2013 22:10:43   Adv. MTU Over.     : No
Last Mgmt Change     : 02/12/2013 22:09:55   VLAN VC Etype      : 0x8100
Bw BookingFactor     : 100                   PBB Etype          : 0x88e7
Oper Max BW(Kbps)    : 0                     Avail BW(Kbps)     : 0
Net-Domain           : default               Egr Interfaces     : Consistent
Flags                : None           
 
Mixed LSP Mode Information :
Mixed LSP Mode       : Disabled              Active LSP Type    : RSVP
 
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
-----------------------------------------------------------------------
SDP-Groups
-----------------------------------------------------------------------
red
-----------------------------------------------------------------------
 
-----------------------------------------------------------------------
RSVP/Static LSPs
-----------------------------------------------------------------------
Associated LSP List :
Lsp Name             : lsp-b2d               
Admin State          : Up                    Oper State         : Up
Time Since Last Tran*: 00h17m33s             
 
-----------------------------------------------------------------------
Class-based forwarding :
-----------------------------------------------------------------------
Class forwarding     : Disabled              EnforceDSTELspFc   : Disabled
Default LSP          : Uknwn                 Multicast LSP      : None

=======================================================================
FC Mapping Table
=======================================================================
FC Name             LSP Name
-----------------------------------------------------------------------
No FC Mappings
 
=======================================================================
* indicates that the corresponding row element may have been truncated.
*A:Dut-B# 


*A:ALA-12# show service sdp
==============================================================================
Services: Service Destination Points                                           
==============================================================================
SdpId    Adm MTU   Opr MTU   IP address       Adm  Opr         Deliver Signal  
------------------------------------------------------------------------------
10       4462      4462      10.20.1.3        Up   Dn NotReady MPLS    TLDP    
40       4462      1534      10.20.1.20       Up   Up          MPLS    TLDP    
60       4462      1514      10.20.1.21       Up   Up          MPLS    TLDP    
100      4462      4462      10.0.0.2         Down Down        MPLS    TLDP    
500      4462      4462      10.20.1.50       Up   Dn NotReady MPLS    TLDP    
------------------------------------------------------------------------------
Number of SDPs : 5                                                            
==============================================================================
*A:ALA-12# 

*A:Dut-A# show service sdp 1 detail 
==============================================================================
Service Destination Point (Sdp Id : 1) Details 
------------------------------------------------------------------------------
 Sdp Id 1  -(10.20.1.3)  
------------------------------------------------------------------------------
Description           : epipe sdp 1 for lspId 00:00:00:01:00:00:00:00
SDP Id               : 1                     SDP Source         : manual       
Admin Path MTU       : 0                     Oper Path MTU      : 1492         
Far End              : 10.20.1.3             Delivery           : MPLS         
Admin State          : Up                    Oper State         : Up           
Signaling            : TLDP                  Metric             : 0            
Acct. Pol            : None                  Collect Stats      : Disabled     
Last Status Change   : 12/08/2008 22:54:30   Adv. MTU Over.     : No           
Last Mgmt Change     : 12/08/2008 22:54:01   VLAN VC Etype      : 0x8100       
Bw BookingFactor     : 100                   PBB Etype          : 0x88e7       
Oper Max BW(Kbps)    : 1000                  Avail BW(Kbps)     : 1000         
Flags                : None
 
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            
 
Associated LSP LIST :
Lsp Name             : tof1                                                    
Admin State          : Up                    Oper State         : Up           
Time Since Last Tran*: 00h04m01s 
------------------------------------------------------------------------------
Class-based forwarding :
------------------------------------------------------------------------------
Class forwarding     : disabled              EnforceDSTELspFc   : disabled     
Default LSP          : Uknwn                 Multicast LSP      : None
==============================================================================
FC Mapping Table                      
==============================================================================
FC Name             LSP Name                                                   
------------------------------------------------------------------------------
No FC Mappings
==============================================================================
* indicates that the corresponding row element may have been truncated.
*A:Dut-A>config>service#


*A:ALA-12# show service sdp 8
==============================================================================
Service Destination Point (Sdp Id : 8)
==============================================================================
SdpId    Adm MTU   Opr MTU   IP address       Adm  Opr         Deliver Signal
------------------------------------------------------------------------------
8        4462      4462      10.10.10.104     Up   Dn NotReady MPLS    TLDP
==============================================================================
*A:ALA-12# 

*A:ALA-12# 
===============================================================================
Service Destination Point (Sdp Id : 8) Details
===============================================================================
Sdp Id 8  -(10.10.10.104)
-------------------------------------------------------------------------------
Description           : MPLS-10.10.10.104
SDP Id               : 8
Admin Path MTU       : 0                     Oper Path MTU      : 0
Far End              : 10.10.10.104          Delivery           : MPLS
Admin State          : Up                    Oper State         : Down
Flags                : SignalingSessDown TransportTunnDown
Signaling            : TLDP                  VLAN VC Etype      : 0x8100
Last Status Change   : 02/01/2007 09:11:39   Adv. MTU Over.     : No
Last Mgmt Change     : 02/01/2007 09:11:46
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
Associated LSP LIST :
Lsp Name             : to-104
Admin State          : Up                    Oper State         : Down
Time Since Last Tran*: 01d07h36m
===============================================================================
* indicates that the corresponding row element may have been truncated.
*A:ALA-12#

*A:MV-SR12>config>service>vprn# show service sdp 10 detail
===============================================================================
Service Destination Point (Sdp Id : 10) Details
===============================================================================
Sdp Id 10  -(200.20.1.201)
-------------------------------------------------------------------------------
Description           : (Not Specified)
SDP Id               : 10                    SDP Source         : manual
Admin Path MTU       : 0                     Oper Path MTU      : 9182
Far End              : 200.20.1.201          Delivery           : MPLS/LDP
Admin State          : Up                    Oper State         : Up
Signaling            : TLDP                  Metric             : 0
Acct. Pol            : None                  Collect Stats      : Disabled
Last Status Change   : 02/12/2010 22:37:08   Adv. MTU Over.     : No
Last Mgmt Change     : 02/12/2010 22:37:03   VLAN VC Etype      : 0x8100
Bw BookingFactor     : 100                   PBB Etype          : 0x88e7
Oper Max BW(Kbps)    : 0                     Avail BW(Kbps)     : 0
Net-Domain           : default               Egr Interfaces     : Consistent
Mixed LSP Mode       : Enabled
Revert Time          : 0                     Revert Count Down  : n/a
Flags                : None

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
-------------------------------------------------------------------------------
LDP Information :
-------------------------------------------------------------------------------
LDP LSP Id           : 65539                 LDP Active         : No
-------------------------------------------------------------------------------
RSVP/Static LSPs
-------------------------------------------------------------------------------
Associated LSP LIST :
Lsp Name             : To_7710
Admin State          : Up                    Oper State         : Up
Time Since Last Tran*: 01h20m56s
-------------------------------------------------------------------------------
Class-based forwarding :
-------------------------------------------------------------------------------
Class forwarding     : Disabled              EnforceDSTELspFc   : Disabled
Default LSP          : Uknwn                 Multicast LSP      : None
===============================================================================
FC Mapping Table
===============================================================================
FC Name             LSP Name
-------------------------------------------------------------------------------
No FC Mappings
===============================================================================
* indicates that the corresponding row element may have been truncated.
*A:MV-SR12>config>service>vprn#


*A:Dut-A# show service sdp 5 detail

===============================================================================
Service Destination Point (Sdp Id : 5) Details
===============================================================================
-------------------------------------------------------------------------------
 Sdp Id 5  -10.0.1.6
-------------------------------------------------------------------------------
Description           : Default sdp description
SDP Id               : 5                     SDP Source         : manual
Admin Path MTU       : 1600                  Oper Path MTU      : 1600
Delivery             : MPLS
Far End              : 10.0.1.6
Tunnel Far End       : n/a                   LSP Types          : RSVP

Admin State          : Up                    Oper State         : Up
Signaling            : TLDP                  Metric             : 0
Acct. Pol            : None                  Collect Stats      : Disabled
Last Status Change   : 09/07/2024 12:49:23   Adv. MTU Over.     : No
Last Mgmt Change     : 09/07/2024 12:48:56   VLAN VC Etype      : 0x8100
Bw BookingFactor     : 100                   PBB Etype          : 0x88e7
Oper Max BW(Kbps)    : 10000                 Avail BW(Kbps)     : 10000
Net-Domain           : default               Egr Interfaces     : Consistent
Flags                : None

Mixed LSP Mode Information :
Mixed LSP Mode       : Disabled              Active LSP Type    : RSVP

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

Src B-MAC LSB        : <none>                Ctrl PW VC ID      : <none>
Ctrl PW Active       : n/a

-------------------------------------------------------------------------------
RSVP/Static LSPs
-------------------------------------------------------------------------------
Associated LSP List :
Lsp Name             : C2F_1
Admin State          : Up                    Oper State         : Up
Time Since Last Tran*: 00h00m11s

===============================================================================
* indicates that the corresponding row element may have been truncated.
*A:Dut-A#
Table 15. Output fields: service SDP

Label

Description

SDP Id

The SDP identifier.

Description

Displays a text string describing the SDP.

Admin Path MTU

Displays the desired 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 desired 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 since the keepalive was administratively enabled or the counter was cleared.

Rx Hello Msgs

The number of SDP echo request messages received since 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.

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

Displays 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 of over 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)

Displays the operational bandwidth in kilobits per seconds (kb/s) 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)

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

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 will be forwarded on when class-based forwarding is enabled on this SDP. When this object has its default value, multicast traffic will be forwarded on an LSP according to its forwarding class mapping.

Number of SDPs

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, such as MP-BGP, to select the route with the lower value.
ETH-CFM show commands
eth-cfm
Syntax

eth-cfm

Context

show

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

Commands in this context display eth-cfm information.

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 Ethernet SFM association information.

Parameters
ma-index

Specifies the maintenance association (MA) index.

Values

1to 4294967295

detail

Displays detailed information for the eth-cfm association.

Output

The following output is an example of Ethernet CFM association information, and Output fields: association describes the output fields.

Sample output 
*A:ALU-IPD#  show eth-cfm association 
======================================================================
CFM Association Table
======================================================================
Md-index   Ma-index   Name                     CCM-interval Bridge-id          
----------------------------------------------------------------------
1          1          abcabcabcabc1            1            1         
1          2          abcabcabcabc2            1            2         
1          3          abcabcabcabc3            1            3         
1          4          abcabcabcabc4            1            4             
======================================================================
*A:ALU-IPD#
Table 16. Output fields: association

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 that 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 up | 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 configured on the system. This can be Service based. The various options allow users to be specific. If no parameters are included, the entire stack-table is displayed.

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

Display the MD level of the maintenance point.

Values

0 to 7

direction

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: CFM stack-table describes the output fields.

Sample output 
*A:ALU-IPD#   show eth-cfm cfm-stack-table 
========================================================================
CFM SAP Stack Table
========================================================================
Sap            Level Dir  Md-index   Ma-index   Mep-id Mac-address             
------------------------------------------------------------------------
lag-1:1.1      0     Down 2          1          10     00:f3:f0:98:97:1b
lag-1:1.1      6     Down 1          1          1      00:f3:f0:98:97:1b
lag-1:2.2      0     Down 2          2          20     00:f3:f0:98:97:1b
lag-1:2.2      6     Down 1          2          2      00:f3:f0:98:97:1b
========================================================================
========================================================================
CFM Ethernet Tunnel Stack Table
========================================================================
Eth-tunnel     Level Dir  Md-index   Ma-index   Mep-id Mac-address             
------------------------------------------------------------------------
========================================================================
========================================================================
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:ALU-IPD#
Table 17. Output fields: CFM stack-table

Label

Description

Sap

Displays associated SAP IDs.

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: domain describes the output fields.

Sample output 
*A:7210-2#  show eth-cfm domain 
==============================================================================
CFM Domain Table
==============================================================================
Md-index   Level Name                                       Format             
------------------------------------------------------------------------------
1          6                                                none              
2          0                                                none              
==============================================================================
*A:7210-2#
Table 18. Output fields: domain

Label

Description

Md-index

Displays the Maintenance Domain (MD) index value.

Level

Displays an integer identifying the MD level. Higher numbers correspond to higher MDs, those with the greatest physical reach, with the highest values for customers CFM PDUs. Lower numbers correspond to lower MDs, those with more limited physical reach, with the lowest values for CFM PDUs protecting single bridges or physical links.

Name

Displays a generic MD name.

Format

Displays the type of the 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 mac-address]

Context

show>eth-cfm

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command displays Maintenance Endpoint (MEP) information.

Note:

  • The show eth-cfm mep mep-id domain md-id association ma-id command does not display CCM ERROR, CCM XCON frames in the output.

  • The show eth-cfm mep mep-id domain md-id association ma-id remote-mep rmep-id command does not display some TLVs details.

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 Ethernet CFM MEP information, and Output fields: MEP describes the output fields.

Sample output 
*A:7210-2#  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            : 1342177281               PrimaryVid        : 65537
FngState           : fngReset                 ControlMep        : False
LowestDefectPri    : macRemErrXcon            HighestDefect     : none
Defect Flags       : None
Mac Address        : 00:f3:f0:98:97:1b        CcmLtmPriority    : 7
CcmTx              : 531                      CcmSequenceErr    : 0
Eth-1Dm Threshold  : 3(sec)                   
Eth-Ais:           : Disabled                 
Eth-Tst:           : Enabled                  Eth-Tst Pattern:  : allZerosNoCrc
Eth-Tst dataLength : 64                       Eth-Tst Priority: : 7
Eth-Tst Threshold  : 1(bitError)              
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:f3:f0:98:97:1b  SequenceNum       : 1
LtFlags            : useFDBonly
-------------------------------------------------------------------------------
Mep Linktrace Replies
-------------------------------------------------------------------------------
SequenceNum        : 1                        ReceiveOrder      : 1
Ttl                : 63                       Forwarded         : False
LastEgressId       : 00:00:00:f3:f0:98:97:1b  TerminalMep       : True
NextEgressId       : 00:00:00:e0:b1:99:cb:46  Relay             : n/a
ChassisIdSubType   : unknown value (0)        
ChassisId:
    None
ManAddressDomain:
    None
ManAddress:
    None
IngressMac         : 00:e0:b1:99:cb:46        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:7210-2# 


*A:7210-2#  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            : 1342177281               PrimaryVid        : 65537
FngState           : fngReset                 ControlMep        : False
LowestDefectPri    : macRemErrXcon            HighestDefect     : none
Defect Flags       : None
Mac Address        : 00:f3:f0:98:97:1b        CcmLtmPriority    : 7
CcmTx              : 566                      CcmSequenceErr    : 0
Eth-1Dm Threshold  : 3(sec)                   
Eth-Ais:           : Disabled                 
Eth-Tst:           : Enabled                  Eth-Tst Pattern:  : allZerosNoCrc
Eth-Tst dataLength : 64                       Eth-Tst Priority: : 7
Eth-Tst Threshold  : 1(bitError)              
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:7210-2#  


*A:7210-2#  show eth-cfm mep 1 domain 1 association 1 remote-mepid 10 
===========================================================================
Eth-CFM Remote-Mep Table
===========================================================================
R-mepId Rx CC  Rx Rdi Port-Tlv If-Tlv Peer Mac Addr     CCM status since       
---------------------------------------------------------------------------
10      True   False  Absent   Absent 00:e0:b1:99:cb:46 05/20/2010 12:59:55
===========================================================================
*A:7210-2#   


*A:7210-2#  show eth-cfm mep 1 domain 1 association 1 eth-test-results 
==============================================================
Eth CFM ETH-Test Result Table
==============================================================
                                 Current        Accumulate                     
                  FrameCount     ErrBits        ErrBits                        
Peer Mac Addr     ByteCount      CrcErrs        CrcErrs                        
--------------------------------------------------------------
00:e0:b1:99:cb:46 1              0              0             
                  64             0              0             
==============================================================


*A:7210-2#  show eth-cfm mep 1 domain 1 association 1 eth-test-results remote-
peer 00:e0:b1:99:cb:46 
==============================================================
Eth CFM ETH-Test Result Table
==============================================================
                                 Current        Accumulate                     
                  FrameCount     ErrBits        ErrBits                        
Peer Mac Addr     ByteCount      CrcErrs        CrcErrs                        
--------------------------------------------------------------
00:e0:b1:99:cb:46 1              0              0             
                  64             0              0             
==============================================================
*A:7210-2# 


*A:7210-2#  show eth-cfm mep 1 domain 1 association 1 one-way-delay-test 
==================================================================
Eth CFM One-way Delay Test Result Table
==================================================================
Peer Mac Addr         Delay (us)          Delay Variation (us)                 
------------------------------------------------------------------
00:e0:b1:99:cb:46     10000               10000              
==================================================================


*A:7210-2#  show eth-cfm mep 1 domain 1 association 1 one-way-delay-test remote-
peer 00:e0:b1:99:cb:46
==================================================================
Eth CFM One-way Delay Test Result Table
==================================================================
Peer Mac Addr         Delay (us)          Delay Variation (us)                 
------------------------------------------------------------------
00:e0:b1:99:cb:46     10000               10000              
==================================================================
*A:7210-2# 


*A:7210-2#  show eth-cfm mep 1 domain 1 association 1 two-way-delay-test 
==================================================================
Eth CFM Two-way Delay Test Result Table
==================================================================
Peer Mac Addr         Delay (us)          Delay Variation (us)                 
------------------------------------------------------------------
00:e0:b1:99:cb:46     10000               10000                   
==================================================================
*A:7210-2# 


*A:7210-2# # show eth-cfm mep 1 domain 1 association 1 two-way-delay-test remote-
peer 00:e0:b1:99:cb:46
==================================================================
Eth CFM Two-way Delay Test Result Table
==================================================================
Peer Mac Addr         Delay (us)          Delay Variation (us)                 
------------------------------------------------------------------
00:e0:b1:99:cb:46     10000               10000                   
==================================================================
*A:7210-2# 
A: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#
Table 19. Output fields: MEP

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 (LTMs) 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-Tst

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

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.

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.

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.
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#
connection-profile
Syntax

connection-profile [conn-prof-id] [associations]

Context

show

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command displays connection profile information.

Parameters
conn-prof-id

Specifies the connection profile ID.

Values

1 to 1000

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: show connection profile describes the output fields.

Sample output — standard 
*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 — 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#
Table 20. Output fields: show connection profile

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.