Services overview

This chapter provides an overview of the 7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE subscriber services, service model, and service entities. Additional information about the individual subscriber services is described in subsequent chapters.

Introduction

A service is a globally unique entity that refers to a type of connectivity service for either Internet or VPN connectivity. Each service is uniquely identified by a service ID and an optional service within a service area. The 7210 SAS-series service model uses logical service entities to construct a service. In the service model, logical service entities provide a uniform, service-centric configuration, management, and billing model for service provisioning.

In 7210 SAS-series routers, services can provide Layer 2/bridged service between a service access point (SAP) on one router and another service access point (a SAP is where traffic enters and exits the service) on the same (local) router or another router (distributed). A distributed service spans more than one router.

Distributed services use service distribution points (SDPs) to direct traffic to another 7210 SAS or SR router or other router that supports MPLS, through a service tunnel. 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).

Note:

SDPs are supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode. Only local services can be configured on 7210 SAS platforms operating in access-uplink mode.

Service types

The 7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-Sx 1/10GE: standalone and standalone-VC, and 7210 SAS-Sx 10/100GE offer the following types of subscriber services, which are described in more detail in the following chapters:

  • Virtual Leased Line (VLL) services:

    • Ethernet pipe (Epipe)

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

  • Virtual Private LAN Service (VPLS)

    A Layer 2 multipoint-to-multipoint VPN. See Virtual Private LAN Service.

  • Internet Enhanced Service (IES)

    A routed connectivity service used to provide IP services.This service is supported in 7210 SAS platforms operated in access-uplink mode for only inband management of the node (that is, it cannot be used for configuring customer service in access-uplink mode). See Internet Enhanced Service.

  • Virtual Private Routed Network (VPRN)

    A Layer 3 IP multipoint-to-multipoint VPN service as defined in RFC 2547bis. See Virtual Private Routed Network service.

Service policies

Common to all 7210 SAS-series connectivity services are policies that are assigned to the service. Policies are defined at a global level, then applied to a service on the router. Policies are used to define 7210 SAS-series service enhancements. The types of policies that are common to all 7210 SAS-series connectivity services, and their functions, are the following:

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

  • QoS ingress and egress policies determine the QoS characteristics for a SAP. A QoS ingress policy applied to a SAP specifies the number of meters, meter characteristics (such as forwarding class, committed, and peak information rates, and so on) and the mapping of traffic to a forwarding class. A QoS egress policy defines the queue characteristics (such as CBS, CIR, PIR). A QoS policy must be created before it can be applied to a SAP. A single ingress and egress QoS policy can be associated with a SAP. 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 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.

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

Nokia service model

In the Nokia service model, the service edge routers are deployed at the provider edge. Services are provisioned on the service routers and transported across an IP or IP/MPLS provider core network in encapsulation tunnels created using MPLS label switched paths (LSPs).

The 7210 SAS devices configured in access-uplink mode support QinQ/dot1q Layer 2 uplinks to transport the services to the provider edge in a hierarchical configuration, whereas 7210 SAS devices configured in network mode support MPLS uplinks to transport the services.

The service model uses logical service entities to construct a service. The logical service entities are designed to provide a uniform, service-centric configuration, management, and billing model for service provisioning. Some benefits of this service-centric design include:

  • Many services can be bound to a single customer.

  • QoS policies, filter policies, and accounting policies are applied to each service instead of correlating parameters and statistics from ports to customers to services.

Service provisioning uses logical entities to provision a service where additional properties can be configured for bandwidth provisioning, QoS, security filtering, and accounting/billing to the appropriate entity.

Service entities

The following figure shows an example of the basic logical entities in the service model used to construct a service for a 7210 SAS device configured in network mode.

Figure 1. Service entities for 7210 SAS devices configured in network mode

Customers

The terms ‟customer” and ‟subscriber” are used synonymously. The most basic required entity is the customer ID value, which is assigned when the customer account is created. To provision a service, a customer ID must be associated with the service at the time of service creation.

SAPs

Each subscriber service type is configured with at least one SAP. A SAP identifies the customer interface point for a service on a 7210 SAS router (SAPs for 7210 SAS configured in network mode). The SAP configuration requires that slot, MDA, and port information be specified. The slot, MDA, and port parameters must be configured before provisioning a service (see the Cards, MDAs, and Ports sections of the 7210 SAS-Mxp, R6, R12, S, Sx, T Interface Configuration Guide).

A SAP is a local entity to the router and is uniquely identified by:

  • physical Ethernet port

  • encapsulation type

  • encapsulation identifier (ID)

Depending on the encapsulation, a physical port can have more than one SAP associated with it. SAPs can only be created on ports designated as ‟access” in the physical port configuration.

The following figure shows SAPs used for customer service delivery, with SDP used for service transport on 7210 SAS devices that support MPLS uplinks (also known as network mode platforms).

Figure 2. SAPs for 7210 SAS configured in network mode

The following figure shows multiple 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).

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

The following are the encapsulation service options on Ethernet ports:

  • null

    Supports a single service on the port. For example, where a single customer with a single service customer edge (CE) device is attached to the port. The encapsulation ID is always 0 (zero).

  • dot1q

    Supports multiple services for one customer or services for multiple customers (Multiple SAPs on a single port (7210 SAS configured in network mode)). The encapsulation ID used to distinguish an individual service is the VLAN ID in the IEEE 802.1Q header. For example, the port is connected to a Ethernet switch with multiple downstream customers.

  • QinQ

    The QinQ encapsulation type adds a IEEE 802.1Q tag to the 802.1Q tagged packets entering the network, to expand the VLAN space by tagging tagged packets, producing a double-tagged frame. The 7210 SAS supports QinQ encapsulation for access ports in network mode. In access-uplink mode, QinQ encapsulation is supported for both access ports and access-uplink ports.

The following are the 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.

The following figure shows multiple SAPs used for customer service delivery on the same port and belonging to the same service, along with SDP used for service transport on 7210 SAS devices that support MPLS uplinks (also known as network mode platforms). This is supported only in network mode.

Figure 4. Multiple SAPs on a single port (7210 SAS configured in network mode)

Services and SAP encapsulations

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

Table 1. Service and SAP encapsulation

Port type

Encapsulation

Ethernet

Null

Ethernet

Dot1q

Ethernet

QinQ

Default SAP 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. Dot1q default SAPs are not supported in VPRNs.

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

  • This type of SAP is mutually exclusive of a SAP defined by explicit null encapsulation (for example, 1/1/1:0). This avoids conflict as with which SAP untagged frames should be associated.

  • 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 (supported only on 7210 SAS devices configured in access-uplink mode)

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.

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.

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

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

The following features are available for default QinQ SAPs on either access ports or access-uplink ports:

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

  • Eth-CFM and Y.1731 is not available for use.

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

  • MVPLS with xSTP can be used for loop prevention. The default QinQ SAPs inherit the state from the associated MVPLS 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 must 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.

  • IP interface in a VPLS service is not supported in a service using this SAP.

The following features are available for default QinQ SAPs created on access-uplink port:

  • Ingress QoS policy 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).

The following features are available for default QinQ SAPs created on access ports:

  • SAP ingress QoS policy is available for use.

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

  • SAP ingress ACLs are available for use.

  • SAP egress ACLs are not available for use.

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

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

The following considerations apply to default QinQ SAPs for transit service in a ring deployment configurations:

  • 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 and loop-detection mechanisms can be implemented for VPLS service configured in the ring nodes, by using MVPLS 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 MVPLS/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 MVPLS with xSTP configured for protection, load-balancing of the traffic based on the VLAN IDs is not possible. If load-balancing is needed, it is better to use Epipe service with default QinQ SAPs as the transit service.

SAP configuration considerations for network mode and access-uplink mode

The following considerations apply to network mode and access-uplink mode SAP configurations:

  • A SAP is a local entity and only locally unique to a specific device. The same SAP ID value can be used on another 7210 SAS-series router.

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

  • At creation, the default administrative state for a SAP is set to administratively enabled.

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

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

  • On a port with a dot1q encapsulation type, traffic for the SAP is identified based on a specific IEEE 802.1Q VLAN ID value. The VLAN ID is stripped off at SAP ingress and the appropriate VLAN ID added at SAP egress. As a result, VLAN IDs only have local significance, and configuring identical VLAN IDs for each SAP on a service is not required.

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

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

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

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

    • Ingress filter policy

    • Egress filter policy

    • Ingress QoS policy

    • Accounting policy

SAP configuration notes when operating 7210 SAS devices in network mode only

When provisioned in network mode, the following SAP configuration guidelines are applicable.

The following table describes SAP and service (svc-sap-type) combinations for Layer 2 services (when in network mode).

Table 2. SAP and Service (svc-sap-type) combinations for Layer 2 services when in network mode

svc-sap-type (Layer 2 service)

Access SAPs

SDP bindings

Any (without any QinQ SAP in the same service)

Null SAP, dot1q SAP, dot1q default SAP, dot1q explicit null SAP, Q1.* SAP, 0.* SAP (accepts only untagged frames)

PW with vc-type set to vc-ether or vc-vlan

Any (with QinQ SAP in the same service)

Null SAP (accepts only untagged frames), Dot1q SAP (accepts only a single tag frame, Dot1q explicit null SAP (accepts only untagged frame), Q1.Q2 SAP (accepts frames with only two tags), 0.* SAP (accepts only untagged frames)

PW with vc-type set to vc-ether or vc-vlan (accepts only untagged frames on vc-ether PW and only tagged frames on vc-vlan PW)

Any (with dot1q-range SAP)

Dot1q range SAP, Q1.* SAP

PW with vc-type set to vc-ether or vc-vlan (no checks on VLAN ID for packets received on PW)

Qinq-inner-tag-preserve

Q1.Q2 SAP (inner tag Q1 is not stripped), dot1q SAP (no tags are stripped)

PW with vc-vlan (vc-vlan is not stripped)

QinQ SAP Configuration Restrictions for 7210 SAS platforms in network operating mode

The following are the QinQ access SAP configuration guidelines for 7210 SAS in network mode only.

These guidelines are not applicable when 7210 SAS devices are operating in access-uplink mode and access-uplink SAPs are in use:

  • Tagged packets received on SAPs configured in a service in which a QinQ SAP is also in use are processed (not applicable when a QinQ SAP is not provisioned in a service).

  • When a QinQ SAP is configured in a service, the number of VLAN tags in the packets received on null SAP, dot1q SAP, and QinQ SAP configured in the same service should match the number of VLAN tags implied by the port encapsulation mode. Packets that do not match are dropped by the hardware. That is, packets received with more than two VLAN tags on a QinQ SAP are dropped, packets received with more than one VLAN tag on a Dot1q SAP are dropped, and packets received with tags (even packets with a priority tag) on a null SAP are dropped. In this document, such packets are referred to as extra-tag packets.

  • When a QinQ SAP is configured in a service, the number of VLAN tags in the packets received on the VC/pseudowire of type vc-vlan should be exactly one and packets received on the VC/pseudowire of type vc-ether should contain no tags (not even priority tags). If either case, packets that contain more VLAN tags than the number specified previously are dropped. In this document, such packets are referred to as extra-tag packets.

  • The system will provide a limited number of counters for the extra-tag packets dropped on SAP ingress. These counters are intended for diagnostic use.

    The following table shows the SAP types allowed in a service when QinQ SAP is in use.

    Table 3. SAP types in a service when QinQ SAP is in use (network mode operation)

    SAP configured in the service

    SAPs not allowed for configuration in the same service

    QinQ

    Q.* SAP, dot1q default SAP

    Q.*

    Q1.Q2

    Dotq1 default SAP

    Q1.Q2

A 0.* QinQ SAP configured in the service will only accept untagged or priority-tagged packets, regardless of whether a QinQ SAP is configured in the service.

Note:

The 7210 SAS platforms support a mechanism to transport QinQ packets in an Epipe with two or more tags, with some restrictions. For more information, see Epipe services.

SAP configuration notes for 7210 SAS platforms in access-uplink operating mode

When provisioned in access-uplink mode, the following SAP configuration guidelines are applicable.

The following table describes SAP and service combinations allowed in access-uplink mode.

Table 4. SAP and service combinations for 7210 SAS-T in access-uplink mode

svc-sap-type

Access SAPs

Access uplink SAPs

null-star

Null SAP, dot1q default SAP, default QinQ SAP (*.* SAP)

Q.* SAP, default QinQ SAP (*.* SAP)

dot1q-preserve

Dot1q SAP (dot1q VLAN tag is not stripped on ingress), Q1.Q2 SAP (Q2 tag VLAN ID 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

The following guidelines apply to SAPs:

  • The svc-sap-type parameter value determines the type of SAPs that are allowed to be provisioned in a service.

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

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

  • A dot1q default SAP cannot be configured when 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 svc-sap-type set to null-star, to process and forward packets with one or more tags (including priority tag) on a null SAP.

  • An ingress QoS policy and accounting policy is assigned per access-uplink port and cannot be assigned per access-uplink 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 un-tagged packets, even if 0.* SAP is not configured for use on that port.

  • The default QinQ SAP is 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 svc-sap-type parameter set to null-star.

  • SAPs using connection-profile (to specify dot1q VLAN ranges or individual VLAN IDs) can be configured in a service only when 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 services for more information about the processing behavior for this type of service.

SDPs

Note:

SDPs are supported by all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.

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 device which directs packets to the correct service egress SAPs on that device. 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 device to a far-end router requires a return path SDP from the far-end 7210 SAS-series 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

The following figure shows an example SDP binding. To configure a distributed service from ALA-A to ALA-B, the SDP ID must be specified in the service creation process to bind the service to the tunnel (the SDP). Otherwise, service traffic is not directed to a far-end point and the far-end devices cannot participate in the service (there is no service). To configure a distributed service from ALA-B to ALA-A, the SDP ID must be specified.

Figure 5. MPLS SDP pointing from ALA-A to ALA-B

Spoke and mesh SDPs

Note:

SDPs are supported by all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.

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 tunnels 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 because of higher protocol priority. This leads to just one label, besides other labels in the stack to identify the VC/VPN at far-end PE nodes.

SDP keepalives

SDP keepalives actively monitor the SDP operational state using periodic SDP ping echo request and echo reply messages. SDP ping is a part of the suite of service diagnostics built on a Nokia service-level OA&M protocol. When SDP ping is used in the SDP keepalive application, the SDP echo request and echo reply messages are a mechanism for exchanging far-end SDP status.

Configuring SDP keepalives on a specific SDP is optional. SDP keepalives for a particular SDP have the following configurable parameters:

  • admin up/admin down state

  • hello time

  • message length

  • max drop count

  • hold down time

SDP keepalive echo request messages are only sent when the SDP is completely configured and administratively up and SDP keepalives are administratively up. If the SDP is administratively down, keepalives for the SDP are disabled.

SDP keepalive echo request messages are sent out periodically, based on the configured hello time. An optional message length for the echo request can be configured. If max drop count echo request messages do not receive an echo reply, the SDP 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.

See Configuring an SDP for information about configuring keepalive parameters.

Mixed-LSP mode of operation

The mixed-LSP mode of operation allows for a maximum of two LSP types to be configured within an SDP: 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 will be used per SDP. The 7210 SAS does not support LDP ECMP.

  3. BGP LSP type

    One RFC 3107-labeled BGP prefix programmed by the service manager.

In the case of the RSVP/LDP SDP, the service manager 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 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, 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. If the LDP LSP fails, the SDP reverts to the RSVP LSP type after the timer expires. For an immediate switchover, the timer should be set to zero using the configure>router>ldp>tunnel-down-damp-time command. See the 7210 SAS-Mxp, R6, R12, S, Sx, T MPLS Guide for more information.

If the value of the revert-time timer is changed, it comes into 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, the SDP is placed in the operationally down state.

Note:

An LDP/BGP SDP has differences in behavior compared to 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. As a result, the tunnel table needs to be reprogrammed each time a route is deactivated and another is activated. Also, the SDP revert-time cannot be used, because there is no situation where both LSP types are active for the same /32 prefix.

SAP and service scaling with high SAP scale mode

Note:

This feature is supported only on the 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE (standalone), and 7210 SAS-Sx 10/100GE (standalone).

In Layer 2 access networks used to backhaul service traffic from business services, mobile backhaul, and residential services, the 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE platforms act as Layer 2 carrier Ethernet switching platforms with VLAN-based Layer 2 uplinks. To perform this role, these platforms must support higher SAP and service scaling. To do so, these platforms use the SAP scale mode and port-based access ingress policies.

Note:

On the 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE, sap-scale-mode can be configured in standalone mode and does not require a BOF configuration.

The following figure shows the use of Layer 2 uplinks in a Layer 2 access network with a 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, or 7210 SAS-Sx 10/100GE.

Figure 6. 7210 SAS using Layer 2 uplinks in an Layer 2 network

The SAP scale mode is configured using the configure>system>resource-profile>sap-scale-mode {high | low} command. By default, the low option is configured for low SAP scale mode, which provides backward compatibility. The user can configure the high option to use high SAP scale mode, which allows the configuration of a higher number of services and SAPs. Before changing the sap-scale-mode value, the user must perform the following:

  • Remove all service and SAP configurations.

  • Change the value of sap-scale-mode and enable per-port egress queuing using the configure>system>resource-profile>qos>port-scheduler-mode command.

  • Reboot the node.

  • Reconfigure all SAPs and services as required.

In high SAP scale mode, the system supports higher SAP and service scaling for Epipe/VLL and VPLS services only. SAP and service scaling for IES, VPRN, and RVPLS services remain unchanged.

QoS policies support port-based access ingress policies on access ports to facilitate the use of access ports as Layer 2 uplinks. With the use of ports as Layer 2 uplinks, the user can apply a single port-based access ingress policy at ingress of an access port, instead of using per-SAP ingress policies. This allows a single policy definition to be used to classify and rate-limit all traffic received over access ports used as Layer 2 uplinks (similar to a network port-based policy applied to network ports used as uplinks) instead of using per SAP ingress policies. Resources must be allocated using the configure>system>resource-profile command to use access ingress QoS policies on an access port.

In addition, only the following QoS policies can be used in the high SAP scale mode to achieve a higher scale:

  • access port-based egress queuing and shaping on all ports, including service delivery ports and uplinks

  • access port-based ingress classification and policing on uplinks

  • Epipe and VPLS SAPs using ingress table-based classification and policing on service delivery ports for higher SAP scale

  • IES and VPRN SAPs using table-based classification or CAM-based classification

  • RVPLS SAPs using CAM-based classification and policing

  • default SAP ingress QoS policy of 65536 for the 7210 SAS-Mxp and 1 for the 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE.

The following SAP configuration restrictions apply to the high SAP scale mode; see SAPs for additional SAP configuration guidelines:

  • If an RVPLS Q1.* SAP is configured, SAPs (Q1.Q2 SAP) with a matching Q1 tag cannot be configured in other VPLS, Epipe, IES, and VPRN services on the same port.

  • If a VPLS Q1.* SAP enabled with DHCP snooping is configured, SAPs (Q1.Q2 SAP) with a matching Q1 tag cannot be configured in other VPLS, Epipe, IES, and VPRN services on the same port. They can use other values for the Q1 tag. The reverse is also true.

  • The dot1p default SAP cannot be configured in RVPLS services; it is only supported in Epipe, VPLS, IES, and VPRN services.

  • If the following criteria are met on the 7210 SAS-Sx 10/100GE, IES and VPRN SAPs for IES or VPRN services are not supported:

    • the SAP has a QinQ encapsulation

    • access-ingress-qos-mode is set to port-mode

    • sap-scale-mode is set to high

Guidelines for configuring high SAP scale mode

Perform the following procedure to change the sap-scale-mode low to the sap-scale-mode high configuration:


  1. Delete all SAPs.


  2. Configure the config>system>resource-profile>qos>port-scheduler-mode command.


  3. Configure the sap-scale-mode command to use the high option.


  4. Save the configuration and reboot the node.

Guidelines for configuring low SAP scale mode

Perform the following procedure to change the sap-scale-mode high to the sap-scale-mode low configuration:


  1. Delete all SAPs.


  2. If the access ingress QoS policy has attachments, reset the policy.


  3. If the access-ingress-qos-mode command is set to port-mode, configure the command to use the sap-mode option.


  4. Configure the sap-scale-mode command to use the low option.


  5. Save the configuration and reboot the node.

G.8032 Ethernet ring protection switching

Ethernet ring (Eth-ring) protection switching provides ITU-T G.8032 specification compliance to achieve resiliency for Ethernet Layer 2 networks. Similar to G.8031 linear protection (also called Automatic Protection Switching (APS)), G.8032 Eth-ring is implemented on Ethernet OAM and often referred to as Ring Automatic Protection Switching (R-APS).

Eth-rings are supported on VPLS SAPs. VPLS services supporting Eth-ring SAPs can connect to other rings and Ethernet service using VPLS and R-VPLS SAPs. The Eth-ring service enables rings for core network or access network resiliency. A single point of interconnection to other services is supported. The Eth-ring service is a VLAN service providing protection for ring topologies and the ability to interact with other protection mechanisms for overall service protection. This ensures failures detected by Eth-ring only result in R-APS switchover when the lower layer cannot recover, and that higher layers are isolated from the failure.

Rings are preferred in data networks where the native connectivity is laid out in a ring or there is a requirement for simple resilient LAN services. Because of the symmetry and the simple topology, rings are viewed a good solution for access and core networks where resilient LANS are required. The Nokia implementation of G.8032 Eth-rings can be used for interconnecting access rings and to provide traffic engineered backbone rings. The 7210 SAS implementation of G.8032 Eth-rings supports dual interconnected rings with sub-rings.

Eth-rings use one VID per control per ring instance and use one (typically) or multiple VIDs for data instances per control instance. A dedicated control VLAN (ERP VLAN) is used to run the protocol on the control VID. G.8032 controls the active state for the data VLANs (ring data instances) associated with a control instance. Multiple control instances allow logically separate rings on the same topology. The Nokia implementation supports dot1q and QinQ encapsulation for data ring instances. The control channel supports dot1q and QinQ encapsulation.

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, the 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, loss of signal (LoS) 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 an 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 detecting the failure (enabled by Y.1731 OAM CC monitoring) sends an 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. 0 to 1 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 an R-APS message. When the message is received by the nodes at the recovered link, they unblock that link and restore connectivity (again all nodes in the ring perform an FDB flush and MAC learning takes place). The ring is back in the normal (or idle) state.

Within each path, Y.1731 Maintenance Entity Group (MEG) Endpoints (MEPs) are used to exchange R-APS specific information (specifically to coordinate switchovers). As well, MEPs optionally exchange 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, after 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.

R-APS can be configured on any port configured for access mode using dot1q or QinQ encapsulation, enabling support for R-APS protected services on the service edge toward the customer site, or within the Ethernet backbone. ELINE and ELAN services can be provided R-APS protection and, although the Eth-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 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 figure shows a resilient ring service example, in which a PBB ring (solid line) using VID 500 carries two service VLANs on I-SID 1000 and 1001 for service VIDs (dot1q 100 and QinQ 400.1, respectively). The RPL for the PBB ring is between A and B, where B is the RPL owner. The following figure also shows 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 allows a form of load balancing. The example demonstrates that service and ring encapsulation can be mixed in various combinations. Also, note that 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 the 50ms transfer time (signaling time after detection).

Figure 9. 0 to 3 resilient ring service example
Ethernet ring configuration

The following is a sample configuration that shows an Ethernet ring configuration.

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
               exit
          exit
          no shutdown  // would allow protect switching
                       // in absence of the "force" command
     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
               exit
          exit
          no shutdown
     exit
no shutdown
exit

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
service
     vpls 40 customer 1 b-vpls 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

service
     epipe 100 pbb-epipe   // CPE traffic
          description "PBB epipe service for CPE"
                 pbb-tunnel 40 backbone-dest-mac 00:bb:bb:bb:bb:bb isid 100
                 sap 3/1/1:100 create
                     description "Default sap description for service id 100"
                 exit
                 no shutdown
     exit

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.

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 10. 0 to 4 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.

Virtual and non-virtual channel

The following is a sample sub-ring using virtual-link configuration output on Node C, interconnecting node.

eth-ring 2
        description "Ethernet Sub Ring on Ring 1"
            interconnect ring-id 1 // Link to Major Ring 1
                propagate-topology-change 
            exit
        exit
        path a 1/1/3 raps-tag 100 // Ring control uses VID 100
            eth-cfm
                mep 9 domain 1 association 4
                    ccm-enable
                    control-mep
                    no shutdown
                exit
            exit
            no shutdown
        exit
        no shutdown
    exit
sub-ring non-virtual-link // Not using a virtual link

# Control Channel for the Major Ring ERP1 illustrates that Major ring 
# control is still separate from Sub-ring control
  vpls 10 customer 1 create
      description "Control VID 10 for Ring 1 Major Ring"
      stp shutdown
      sap 1/1/1:10 eth-ring 1 create
          stp shutdown
          exit
      sap 1/1/4:10 eth-ring 1 create
          stp shutdown 
          exit
      no shutdown
  exit 

# Data configuration for the Sub-Ring

  vpls 11 customer 1 create
      description "Data on VID 11 for Ring 1"
      stp shutdown 
      sap 1/1/1:11 eth-ring 1 create // VID 11 used for ring
          stp shutdown 
      exit
      sap 1/1/4:11 eth-ring 1 create
          stp shutdown 
      exit
      sap 1/1/3:11 eth-ring 2 create // Sub-ring data
          stp shutdown 
      exit
      sap 3/2/1:1 create 
      description "Local Data SAP"
          stp shutdown 
      no shutdown
  exit

# Control Channel for the Sub-Ring using a virtual link. This is 
# a data channel as far as Ring 1 configuration. Other Ring 1 
# nodes also need this VID to be configured. 

  vpls 100 customer 1 create
      description "Control VID 100 for Ring 2 Interconnection"
      split-horizon-group "s1" create //Ring Split horizon Group
      exit
      stp shutdown 
      sap 1/1/1:100 split-horizon-group "s1" eth-ring 1 create
          stp shutdown 
      exit
      sap 1/1/4:100 split-horizon-group "s1" eth-ring 1 create
          stp shutdown 
      exit
      sap 1/1/3:100 eth-ring 2 create
          stp shutdown 
      exit
      no shutdown
  exit 
Ethernet ring sub-ring using non-virtual link

The following figure shows an Ethernet sub-ring that uses a non-virtual link.

Figure 11. 0 to 6 sub-ring homed to VPLS

The following is a sample sub-ring using non-virtual link configuration output on PE1, the 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 that are part of a sub-ring with non-virtual link should be configured with the sub-ring non-virtual-link option, as shown in the following sample configuration.

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 output homed to a major ring.

eth-ring 1
      description "Ethernet Ring 1"
      guard-time 20
      no revert-time
      rpl-node nbr
      sub-ring non-virtual-link
          interconnect ring-id <major ring index>
              propagate-topology-change 
          exit
      exit
      path a 1/1/3 raps-tag 1.1
          description "Ethernet Ring : 1 Path on LAG"
          eth-cfm
          mep 8 domain 1 association 8
               ccm-enable
               control-mep
               no shutdown
            exit
        exit
        no shutdown
    exit
    no shutdown
exit
Lag support

The 7210 SAS does not support G.8032 Ethernet rings on LAGs.

OAM considerations

Ethernet CFM can be enabled on each individual path under an Ethernet ring. Only Down MEPs can be configured on each path 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.

QoS considerations

When Ethernet ring is configured on two ports located on different IOMs, the SAP queues and virtual schedulers will be created with the actual parameters on each IOM.

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.

See the 7210 SAS-Mxp, S, Sx, T Services Guide for more information about Ethernet ring applicability in the services solution.

Support service and solution combinations

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

  • Only ports in access mode can be configured as Ethernet-ring paths.

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

  • A mix of regular and multiple Ethernet-ring SAPs and PWs can be configured in the same services.

Configuration guidelines for G.8032

The configuration guidelines for G.8032 are the following:

  • For 7210 SAS-T devices in network mode, users must enable the fast-flood feature and allocate the resources from the ingress-internal-tcam pool using the config system resource-profile g8032-fast-flood-enable command.

  • For 7210 SAS-T devices in access-uplink mode, users do not need to enable the fast-flood feature or allocate the resources from the ingress-internal-tcam pool using the config system resource-profile g8032-fast-flood-enable command, because the resources are automatically allocated by the software.

  • For 7210 SAS-Mxp devices in network mode, the fast-flood feature is enabled by default to improve the service fail-over time caused by failures in the ring path. If a failure is detected in one of the paths of the Ethernet ring, along with MAC flush, the system also floods the traffic to the available path. No explicit user configuration is required to facilitate this, and resource allocation from the ingress-internal-tcam pool is not needed.

  • For 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE, no explicit user configuration is needed to enable G.8032 fast-flood, and resources do not need to be allocated from the ingress-internal-tcam pool.

  • Service-level MEPs are not available on SAPs tied to an Ethernet-ring instance on a port.

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

  • G.8032 version 2 is the supported version, by default. Use the config eth-ring compatible-version command to change the G.8032 version to 1, if required. See the 7210 SAS-Mxp, R6, R12, S, Sx, T Interface Configuration Guide for more information.

Service creation process overview

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

Figure 12. 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:

  • core network construction

  • service administration

  • service provisioning

Phase 1: core network construction

Before the services are provisioned, perform the following tasks:

  • Build the IP or IP/MPLS core network.

  • Configure routing protocols.

  • Configure MPLS LSPs (if MPLS is used).

Phase 2: service administration

Perform the following tasks to complete preliminary policy configurations to control traffic flow, operator access, and to manage fault conditions and alarm messages. Perform the following tasks:

  • Configure group and user access privileges.

  • Build templates for QoS, filter and accounting policies needed to support the core services.

Phase 3: service provisioning

Perform the following tasks to complete 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, and binding policies to the SAPs.

Configuration notes

This section describes service configuration restrictions.

General

Service provisioning tasks can be logically separated into two main functional areas, core tasks and subscriber services 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 (not applicable for devices configured in access-uplink mode).

Subscriber services tasks include the following:

  • Create Epipe and VPLS services.

  • Create a VPRN service (supported only when operating in network mode).

  • Bind SDPs (not applicable for 7210 SAS devices configured in access-uplink mode).

  • Configure interfaces (where required) and SAPs.

  • Create exclusive QoS and filter policies.

To send and receive inband management traffic (for 7210 SAS configured in access-uplink mode), create an IES service.

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:

  • a customer ID

  • a service type

  • a service ID

  • a SAP identifying a port and encapsulation value

  • an associated SDP for distributed services in the network mode

    The SDPs are not supported in the access-uplink mode.

The following is a sample Epipe service configuration output showing the SDP and Epipe service entities. SDP ID 1 was created with the far-end node 10.20.1.2. Epipe ID 101 was created for customer ID 1, which uses the SDP ID 1.

A:ALA-7210M>config>service#
------------------------------------------
...
        sdp 1 mpls create
            description "Default sdp description"
            far-end 10.20.1.2
            lsp "lsp_1_to_B"
            signaling tldp
            no vlan-vc-etype
            path-mtu 9194
            no adv-mtu-override
            keep-alive
                shutdown
                hello-time 10
                hold-down-time 10
                max-drop-count 3
                timeout 5
                no message-length
            exit 
            no collect-stats          
            no accounting-policy      
            no shutdown               
        exit 
...
    epipe 101 customer 1 vpn 101 create
            description "Default epipe description for service id 101"
            service-mtu 9194
            sap lag-2:101 create
                description "Default sap description for service id 101"
                no tod-suite
                dot1ag
                exit
                ingress
                    qos 1 
                    no filter
                exit
            spoke-sdp 101:101 vc-type ether create
                no vlan-vc-tag
                ingress
                    no vc-label
                exit
                egress
                    no vc-label
                exit
                no control-word
                no 
                dot1ag
                    mep 1 domain 5 association 101 direction down
                        ccm-enable
                        no ccm-ltm-priority
                        low-priority-defect remErrXcon
                        no mac-address
                        no shutdown
                    exit
                    mep 1 domain 6 association 101 direction down
                        ccm-enable    
                        no ccm-ltm-priority
                        low-priority-defect remErrXcon
                        no mac-address
                        no shutdown
                    exit
                exit
                no collect-stats
                no accounting-policy
                no precedence 
                no shutdown
            exit
            no shutdown
...
------------------------------------------
A:ALA-7210M>config>service#

Common configuration tasks

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

Configuring customers 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:ALA-12>config>service# info
-------------------------------------------
...
       customer 5 create
           description "Nokia Customer"
           contact "Technical Support"
           phone "650 555-5100"
       exit
...
-------------------------------------------
A:A:ALA-12>config>service#

Configuring an SDP

Note:

SDPs are supported by all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.

The most basic SDP must have the following:

  • a locally unique SDP identification (ID) number

  • the system IP address of the far-end routers

  • an SDP encapsulation type, MPLS

SDP configuration tasks

This section provides a brief overview of the tasks that must be performed to configure SDPs, and provides the CLI commands.

Consider the following SDP characteristics:

  • SDPs can be created as MPLS.

  • Each distributed service must have an SDP defined for every remote router to provide VLL, VPLS, and VPRN services.

  • A distributed service must be bound to an SDP. By default, no SDP is associated with a service. When an SDP is created, services can be associated with that SDP.

  • An SDP is not specific or exclusive to any one service or any type of service. An SDP can have more than one service bound to it.

  • The SDP IP address must be a 7210 SAS-series system IP address.

  • To configure an MPLS SDP, LSPs must be configured first, then the LSP-to-SDP association must be explicitly created.

  • In the SDP configuration, automatic ingress and egress labeling (targeted LDP) is enabled by default. Ingress and egress VC labels are signaled over a TLDP connection between two 7210 SAS-series routers.

    If signaling is disabled for an SDP, services using that SDP must configure ingress and egress VC labels manually.

To configure a basic SDP, perform the following steps:


  1. Specify an originating node.


  2. Create an SDP ID.


  3. Specify an encapsulation type.


  4. Specify a far-end node.

Configuring an SDP

Use the following syntax to create an SDP and select an encapsulation type. Only MPLS encapsulation is supported.

Note:

When you specify the far-end IP address, you are creating the tunnel; in essence, you are creating the path from point A to point B. When you configure a distributed service, you must identify an SDP ID. Use the show service sdp command to display the qualifying SDPs.

When specifying MPLS SDP parameters, you must specify an LSP. If an LSP name is specified, RSVP is used for dynamic signaling within the LSP.

LSPs are configured in the config>router>mpls context. See the 7210 SAS-Mxp, R6, R12, S, Sx, T MPLS Guide for configuration and command information.

Use the following syntax to create an MPLS SDP.

config>service>sdp sdp-id [mpls] create
    adv-mtu-override
    description description-string
    far-end ip-address
    keep-alive 
    hello-time seconds
    hold-down-time seconds
    max-drop-count count
    message-length octets
    timeout timeout
    no shutdown 
            lsp lsp-name [lsp-name](only for MPLS SDPs)
    path-mtu octets
    signaling {off | tldp}
    no shutdown 

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

A:ALA-12>config>service# info
-------------------------------------------
...
        sdp 8 mpls create
            description "MPLS-10.10.10.104"
            far-end 10.10.10.104
            lsp "to-104"
            keep-alive
            mixed-lsp-mode
                revert-time 1
                shutdown
            exit
            no shutdown
        exit
...
-----------------------------------------
A:ALA-12>config>service#

Configuring a mixed-LSP SDP

The following is 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.

Ethernet connectivity fault management

Ethernet Connectivity Fault Management (ETH-CFM) is defined in two similar standards: IEEE 802.1ag and ITU-T Y.1731. Both standards specify protocols, procedures, and managed objects to support transport fault management, including discovery and verification of the path, detection and isolation of a connectivity fault for each Ethernet service instance.

ETH-CFM configuration is split into multiple CLI contexts. The ETH-CFM configuration, which 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-Mxp, S, Sx, T Services Guide for detailed information about the basic service-applicable material to build the service-specific management points, MEPs, and MIPs. The different service types support a subset of the features from the complete ETH-CFM suite.

Ethernet continuity check (ETH-CC) used for continuity is available to all MEPs configured within a service. 7210 SAS devices support Down MEPs and UP MEPs, though the support is not available on all platforms. See the 7210 SAS-Mxp, R6, R12, S, Sx, T OAM and Diagnostics Guide for more information.

The troubleshooting tools ETH-LBM, ETH-LBR, LTM ETH-TST, and LTR ETH-TST, defined by the IEEE 802.1ag specification and the ITU-T Y.1731 recommendation, are applicable to all MEPs (and MIPs where appropriate).The advanced notification function, Alarm Indication Signal (AIS), defined by the ITU-T Y.1731, is supported on Epipe services.

The advanced performance functions, 1DM, DMM/DMR, and SLM/SLR are supported on all service MEPs.

See the 7210 SAS-Mxp, R6, R12, S, Sx, T OAM and Diagnostics Guide for 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 5. ETH-CFM acronym expansions

Acronym

Expansions

1DM

One-way Delay Measurement (Y.1731)

AIS

Alarm Indication Signal

BNM

Bandwidth Notification Message (Y.1731 sub OpCode of GMN)

CCM

Continuity Check Message

CFM

Connectivity Fault Management

DMM

Delay Measurement Message (Y.1731)

DMR

Delay Measurement Reply (Y.1731)

GMN

Generic Message Notification

LBM

Loopback Message

LBR

Loopback Reply

LTM

Linktrace Message

LTR

Linktrace Reply

ME

Maintenance Entity

MA

Maintenance Association

MA-ID

Maintenance Association Identifier

MD

Maintenance Domain

MEP

Maintenance Association Endpoint

MEP-ID

Maintenance Association Endpoint Identifier

MHF

MIP Half Function

MIP

Maintenance Domain Intermediate Point

OpCode

Operational Code

RDI

Remote Defect Indication

TST

Ethernet Test (Y.1731)

SLM

Synthetic Loss Message (Y.1731)

SLR

Synthetic Loss Reply (Y.1731)

MA, MEP, MIP, and MD levels

ETH-CFM capabilities may be deployed in many different Ethernet service architectures. The Ethernet-based SAPs and SDP bindings provide the endpoint on which the management points may be created. The basic functions can be used in different services, VPLS and Epipe. The following figures show two possible example scenarios for ETH-CFM deployment in Ethernet access and aggregation networks.

Figure 13. Ethernet OAM model for Ethernet access – business
Figure 14. Ethernet OAM model for Ethernet access – wholesale

The following functions are supported:

  • CFM can be enabled or disabled on a SAP or SDP bindings basis.

  • The eight ETH-CFM levels are suggested to be broken up numerically between customer 7-5, service provider 4-3 and operator 2-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, MEP-ID tuple:

    • MEP creation on a SAP is allowed only 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 SAS platforms.

  • MIP creation on a SAP for each MD level can be enabled and disabled. MIP creation is automatic or manual when it is enabled. When MIP creation is disabled for an MD level, the existing MIP is removed. 7210 SAS platforms have the notion of ingress and egress MIPs. Ingress MIP responds to OAM messages that are received. Egress MIP responds to OAM messages that are sent. Ingress and egress MIP support for SAP, SDP bindings, and services varies and is listed in Defect conditions and priority settings. See MEP and MIP support for more information about MEP and MIP support.

Common actionable failures

It is important to note that 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 6. Defect conditions and priority settings

Defect

Low priority defect

Description

Causes

Priority

DefNone

N/A

No faults in the association

Normal operations

N/A

DefRDICCM

allDef

Remote Defect Indication

Feedback mechanism to inform that unidirectional faults exist. It provides the feedback loop to the node with the unidirectional failure conditions.

1

DefMACStatus (default)

macRemErrXcon

MAC Layer

Remote MEP is indicating that a remote port or interface is not operational.

2

DefRemoteCCM

remErrXon

No communication from remote peer

MEP is not receiving CCM from a configured peer. The timeout of CCM occurs at 3.5 times the local CC interval. As per the specification, this value is not configurable.

3

DefErrorCCM

errXcon

Remote and local configurations do not match required parameters

Caused by different interval timer, domain-level issues (lower value arriving at a MEP configured with a higher value), MEP receiving CCM with its MEPID

4

DefXconn

Xcon

Cross connected service

The service is receiving CCM packets from a different association. This could indicate that two services have merged or there is a configuration error on one of the SAPs or bindings of the service, incorrect association identification.

5

MEP and MIP support

See the 7210 SAS-Mxp, R6, R12, S, Sx, T OAM and Diagnostics Guide for more information about ETH-CFM support for different services and endpoints.

Configuring ETH-CFM parameters

Note:

See the 7210 SAS-Mxp, R6, R12, S, Sx, T OAM and Diagnostics Guide for more information about ETH-CFM configuration guidelines for 7210 SAS platforms.

Configuring ETH-CFM requires commands at two different hierarchy levels of the CLI.

This section provides a sample of the global ETH-CFM configuration, which defines the domains, associations, linkage of the service ID or function, and the globally applicable CCM parameters, including the interval and building of the remote MEPs database.

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 following is sample output using the service VPLS 100 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 sample global ETH-CFM configuration outputs 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 transmit and receive AIS PDUs, Y.1731 MEPs must have ais-enable configured.

  • To transmit and receive ETH-Test PDUs, Y.1731 MEPs must have eth-test-enable configured.

Applying ETH-CFM parameters

Use the following syntax to apply ETH-CFM parameters to the following entities.

config>service>epipe>sap
    eth-cfm
    mep mep-id domain md-index association ma-index [direction
    {up | down}]
            ais-enable
                client-meg-level [level [level ...]
                interval {1 | 60}
                priority priority-value
            ccm-enable
            ccm-ltm-priority priority
            eth-test-enable
                test-pattern {all-zeros | all-ones} [crc-enable]
            low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
            [no] shutdown
config>service>epipe>spoke-sdp
    eth-cfm
    mep mep-id domain md-index association ma-index [direction
    {up | down}]
        ccm-enable
        ccm-ltm-priority priority
        eth-test-enable
            test-pattern {all-zeros | all-ones} [crc-enable]
        low-priority-defect {allDef|macRemErrXcon|remErrXcon|
            errXcon|xcon|noXcon}
        [no] shutdown
config>service>vpls>sap
    eth-cfm
    mip
    mep mep-id domain md-index association ma-index [direction {up | down}]
    no mep mep-id domain md-index association ma-index
        ccm-enable
        ccm-ltm-priority priority
        eth-test-enable
            test-pattern {all-zeros | all-ones} [crc-enable]
        low-priority-defect {allDef|macRemErrXcon|remErrXcon|errXcon|xcon|noXcon}
        mac-address mac-address
        [no] shutdown
config>service>vpls>mesh-sdp sdp-id[:vc-id] [vc-type {ether|vlan}]
    eth-cfm
    mep mep-id domain md-index association ma-index [direction
    {up | down}]
        ccm-enable
        ccm-ltm-priority priority
        eth-test-enable
            test-pattern {all-zeros | all-ones} [crc-enable]
        low-priority-defect {allDef|macRemErrXcon|remErrXcon|
        errXcon|xcon|noXcon}
        mac-address mac-address
        no] shutdown
config>service>vpls
    spoke-sdp sdp-id:vc-id [vc-type {ether | vlan}] [split-horizon-group group-name] [no-endpoint]
    spoke-sdp sdp-id:vc-id [vc-type {ether | vlan}] [split-horizon-group group-name] endpoint endpoint
    eth-cfm
    map mep-id domain md-index association ma-index [direction
    {up | down}]
        ccm-enable
        ccm-ltm-priority priority
        eth-test-enable
            test-pattern {all-zeros | all-ones} [crc-enable]
        low-priority-defect {allDef | macRemErrXcon|remErrXcon|errXcon|xcon|noXcon}
        mac-address mac-address
        no] shutdown
oam
    eth-cfm linktrace mac-address mep mep-id domain md-index association ma-index [ttl ttl-value]
    eth-cfm loopback mac-address mep mep-id domain md-index association ma-index [send-count send-count] [size data-size] [priority priority]
    eth-cfm eth-test mac-address mep mep-id domain md-index association ma-index [priority priority] [data-length data-length]
    eth-cfm one-way-delay-test mac-address mep mep-id domain md-index association ma-index [priority priority]
    eth-cfm two-way-delay-test mac-address mep mep-id domain md-index association ma-index [priority priority]
    eth-cfm two-way-slm-test mac-address mep mep-id domain md-index association ma-index [priority priority]

Layer 2 control processing

Operators providing the Epipe service must be able to transparently forward Layer 2 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.

    See L2PT and BPDU translation for more information.

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 Layer 2 control protocol 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 SAPs or SDPs for redundant connectivity). That is, if the VPLS service is used for multipoint connectivity, it is not recommended to use 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 protocols listed previously, protocols that are not supported on the 7210 SAS (for example, GARP, GVRP, ELMI, and others) are transparently forwarded in case of a VPLS service. These protocols are transparently forwarded if a null SAP, dot1q default SAP, dot1q explicit null SAP or 0.* SAP is configured on the port and the received packet is untagged. If the received packet is tagged and matches the tag of any of the SAPs configured on the port, it is forwarded in the context of the SAP and the service. Otherwise, if the received packet is untagged and none of the null or dot1q default or dot1q explicit null or 0.* SAP is configured, it is discarded.

If a 7210 receives a tagged L2CP packet on any SAP (including null, dot1q, dot1q range, QinQ, QinQ default), it is forwarded transparently in the service similar to normal service traffic (xSTP processing behavior is different in VPLS service and is listed as follows).

The xSTP processing behavior in a VPLS service is as follows:

  • If xSTP is enabled in the service, and if the tag in the STP BPDU matches the tag of the configured SAP, the received xSTP BPDU is processed by the local xSTP instance on the node for that service when xSTP is enabled on the SAP, and discarded when xSTP is disabled on the SAP.

  • If the tags do not match, xSTP BPDU packets are transparently forwarded in the service similar to normal service traffic.

  • If xSTP is disabled in the service, STP BPDU packets are transparently forwarded in the service similar to normal service traffic.

    The following table describes L2CP support for 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Mxp access-uplink and network media platforms.

    Table 7. L2CP support for 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE, and 7210 SAS-Mxp access-uplink and network mode platforms

    Packet type

    7210 SAS-T

    7210 SAS-Mxp

    7210 SAS-Sx/S 1/10GE

    7210 SAS-Sx 10/100GE

    LACP

    Option to tunnel or discard or peer

    Option to tunnel or discard or peer

    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

    Option to tunnel or discard or peer

    Option to tunnel or discard or peer

    LLDP

    Option to tunnel or discard or peer1

    Option to tunnel or discard or peer1

    Option to tunnel or discard or peer1

    Option to tunnel or discard or peer1

    EFM

    Option to tunnel or discard or peer

    Option to tunnel or discard or peer

    Option to tunnel or discard or peer

    Option to tunnel or discard or peer

    L2PT

    Supported2

    Supported2

    Supported2

    Supported2

    BPDU Tunneling

    Supported

    Supported

    Supported

    Supported

    xSTP

    Option to peer or tunnel

    Option to peer or tunnel

    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

    Option to tunnel or discard or peer3

    Option to tunnel or discard or peer

    1 See the 7210 SAS-Mxp, R6, R12, S, Sx, T Interface Configuration Guide for more information about options available for LLDP tunneling.
    2 L2TP support on 7210 SAS platforms varies among the platforms. Not all platforms support tunneling of all CISCO protocols. See L2PT and BPDU translation for more information.
    3 ESMC tunneling is not supported in the standalone-VC mode of operation.

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-Sx/S 1/10GE (standalone).

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 15. 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-Mxp, R6, R12, S, Sx, T 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 16. 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-Mxp, R6, R12, S, Sx, T 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 management tasks

This section describes the service management tasks.

Modifying customer accounts

To access a specific customer account, you must specify the customer ID.

Use the following syntax to display a list of customer IDs.

Enter the parameter (description, contact, phone) and then enter the new information.

config>service# customer customer-id create
    [no] contact contact-information
    [no] description description-string
    [no] phone phone-number
Example:
config>service# customer 27 create
    config>service>customer$ description ‟Western Division”
    config>service>customer# contact ‟John Dough”
    config>service>customer# no phone ‟(650) 237-5102”

Deleting customers

The no form of the customer command removes a customer ID and all associated information. All service references to the customer must be shut down and deleted before a customer account can be deleted.

config>service# no customer customer-id
Example:
config>service# epipe 5 customer 27 shutdown
    config>service# epipe 9 customer 27 shutdown
    config>service# no epipe 5
    config>service# no epipe 9
    config>service# no customer 27

Modifying SDPs

Note:

SDPs are supported by all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.

To access a specific SDP, you must specify the SDP ID. To display a list of SDPs, use the show service sdp command. Enter the parameter, such as description, far-end, and lsp, and then enter the new information.

Note:

When an SDP is created, the SDP encapsulation type cannot be modified.

config>service# sdp sdp-id 
Example:
config>service# sdp 79 
    config>service>sdp# description ‟Path-to-107”
    config>service>sdp# shutdown
    config>service>sdp# far-end ‟10.10.10.107”
    config>service>sdp# path-mtu 1503
    config>service>sdp# no shutdown

Deleting SDPs

The no form of the sdp command removes an SDP ID and all associated information. Before an SDP can be deleted, the SDP must be shutdown and removed (unbound) from all customer services where it is applied.

config>service# no sdp 79
Example:
config>service# epipe 5 spoke-sdp 79:5
    config>service>epipe>sdp# shutdown
    config>service>epipe>sdp# exit
    config>service>epipe# exit
    config>service# no sdp 79

Global services command reference

Command hierarchies

Global service configuration commands

Pseudowire (PW) commands
Note:

PW commands are supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.

config
    - service
        - pw-routing
            - boot-timer secs
            - no boot-timer
            - local-prefix local-prefix [create]
            - no local-prefix local-prefix
                - advertise-bgp route-distinguisher rd [community community]
                -  no advertise-bgp route-distinguisher rd [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
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
            - [no] force-vlan-vc-forwarding
            - hash-label [signal-capability]
            - no hash-label
            - 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
SDP commands
Note:

SDP commands are supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.

config
    - service
        - sdp sdp-id [mpls] [create]
        - no sdp sdp-id
            - accounting-policy acct-policy-id
            - no accounting-policy
            - collect-stats acct-policy-id
            - no collect-stats
            - [no] adv-mtu-override
            - [no] bgp-tunnel
            - [no] collect-stats
            - description description-string
            - no description
            - far-end ip-address | ipv6-address
            - no far-end[ip-address | ipv6-address]
            - 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 platforms operating in network mode
config
    - service
        - epipe
            - sap sap-id [create]
            - no sap sap-id
        - ies
            - sap sap-id [create] 
            - no sap sap-id
        - vpls
            - sap sap-id [split-horizon-group group-name] [eth-ring ring-index] [create] 
            - no sap sap-id
        - vprn
            - interface ip-int-name  [create]
            - no interface ip-int-name 
                - sap sap-id [create] 
                - no sap sap-id
SAP commands for 7210 SAS platforms operating in access-uplink mode
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
            - sap sap-id [create]
            - no sap sap-id
        - vpls service-id [customer customer-id] [create] [vpn vpn-id] [m-vpls] [svc-sap-type {nullstar | any | dot1q-preserve}] [customer-vid vlan-id]
        - no vpls service-id
            - sap sap-id [create]
            - no sap sap-id
ETH-CFM configuration commands
Note:

For command descriptions, refer to the 7210 SAS-Mxp, R6, R12, S, Sx, T OAM and Diagnostics Guide.

config
    - eth-cfm
        - domain md-index [format md-name-format] [name md-name] level level
        - domain md-index
        - no domain md-index
            - association ma-index [format ma-name-format] name ma-name
            - association ma-index
            - no association ma-index
                - [no] bridge-identifier bridge-id
                    - id-permission {chassis}
                    - no id-permission
                    - mhf-creation {none | explicit | default | static} 
                    - no mhf-creation
                    - mip-ltr-priority priority
                    - vlan vlan-id
                    - no vlan
                - ccm-interval {10ms | 100ms | 1 | 10 | 60 | 600}
                - no ccm-interval
                - [no] remote-mepid mep-id
        - slm
            - inactivity-timer timer
            - no inactivity-timer
        - system
            - sender-id local local-name
            - sender-id system
            - no sender-id

Show commands

show
    - service
        - customer [customer-id] [site customer-site-name]
        - sdp sdp-id keep-alive-history
        - sdp far-end ip-address keep-alive-history
        - sdp [sdp-id] [detail] 
        - sdp far-end ip-address [detail]
        - sdp-using [sdp-id[:vc-id] | far-end ip-address]
        - service-using [epipe] [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]
        - cfm-stack-table
        - cfm-stack-table port port-id [all-ports] [level 0..7] [direction down]
        - cfm-stack-table port port-id [vlan qtag[.qtag]] [level 0..7] [direction down]
        - mep mep-id domain md-index association ma-index [loopback] [linktrace]
        - mep mep-id domain md-index association ma-index  remote-mepid mep-id | all-remote-mepids
        - mep mep-id domain md-index association ma-index eth-test-results [remote-peer mac-address]
        - mep mep-id domain md-index association ma-index one-way-delay-test [remote-peer mac-address]
        - mep mep-id domain md-index association ma-index two-way-delay-test [remote-peer mac-address]
        - mep mep-id domain md-index association ma-index two-way-slm-test [remote-peer macaddress]
        - pw-routing {local-prefix | static-route | paths | all}
        - pw-routing route-table [all-routes]
        - pw-routing route-table summary
        - pw-template

Command descriptions

Global service configuration commands

Generic commands
description
Syntax

description description-string

no description

Context

config>service>customer

config>service>sdp (not supported in access-uplink mode)

Platforms

Supported on all 7210 SAS platforms as described in this document, including those operating in access-uplink mode.

Description

This command creates a text description stored in the configuration file for a configuration context.

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

Default

No description associated with the configuration context.

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.

shutdown
Syntax

[no] shutdown

Context

config>dot1ag>mep

config>service>sdp (not supported in access-uplink mode)

config>service>sdp>keep-alive (not supported in access-uplink mode)

Platforms

Supported on all 7210 SAS platforms as described in this document, including those operating in access-uplink mode.

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. 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 and then tries to enter the operationally up state.

Special Cases
Service Admin State

Bindings to an SDP within the service are put into the out-of-service state when the service is shutdown. While the service is shutdown, all customer packets are dropped and counted as discards for billing and debugging purposes.

SDP (global)

When an SDP is shutdown at the global service level, all bindings to that SDP are put into the out-of-service state and the SDP itself is put into the administratively and operationally down states. Packets that would be transmitted using this SDP binding are discarded and counted as dropped packets.

SDP (service level)

Shutting down an SDP within a service only affects traffic on that service from entering or being received from the SDP. The SDP itself may still be operationally up for other services.

SDP Keepalives

Enables SDP connectivity monitoring keepalive messages for the SDP ID. Default state is disabled (shutdown) in which case the operational state of the SDP-ID is not affected by the keepalive message state.

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, including those operating in access-uplink mode

Description

This command creates 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.

Default

customer 1

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, including those operating in access-uplink mode

Description

This command specifies contact information for a customer, such as a technician name or account contract name.

Default

no contact

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, including those operating in access-uplink mode

Description

This command specifies telephone number information for a customer ID.

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

Parameters
string

Specifies the customer phone number entered as an ASCII string, up to 80 characters. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes. Any printable, seven bit ASCII characters may be used within the string.

Pseudowire Commands
pw-routing
Syntax

pw-routing

Context

config>service

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

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.

Default

disabled

boot-timer
Syntax

boot-timer secs

no boot-timer

Context

config>service>pw-routing

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

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

Default

10

Parameters
timer-value

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

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

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

Values

global-id:ip-addr | raw-prefix

ip-addr: a.b.c.d

raw-prefix: 1 to 4294967295

global-id: 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

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

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

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

Default

no advertise-bgp.

Parameters
rd

Specifies a 32 bit prefix for the AII. One or more prefix values, up to a maximum of 16 may be assigned to the 7210 node. The global ID can contain the 2-octet or 4-octet value of the provider's Autonomous System Number (ASN). The presence of a global ID based on the provider's ASN ensures that the AII for spoke-SDPs configured on the node are globally unique.

Values

(6 bytes, other 2 Bytes 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

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

Values

community: {2-byte-as-number:comm-val}

2-byte-asnumber: 1 to 65535

comm.-val: 0 to 65535

path
Syntax

path name [create]

no path name

Context

config>service>pw-routing

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

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

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

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

Default

no path

Parameters
name

Specifies a locally-unique case-sensitive alphanumeric name label for the MS-PW path of up to 32 characters.

hop
Syntax

hop hop-index ip-address

no hop hop-index

Context

config>service>pw-routing>hop

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

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 shutdown first to delete the hop from the hop list. The ‛no hop hop-index’ command does 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 hops specified. 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 [10..10000]

no retry-count

Context

config>service>pw-routing

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

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

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

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

Default

30

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

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

This command specifies a retry-timer for the spoke-SDP. This is a configurable exponential back-off timer that determines the interval between retries to reestablish a spoke-SDP if it fails and a label withdraw message is received with the status code ‟AII unreachable”.

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

Default

30

Parameters
retry-count

Specifies the initial retry-timer value in seconds.

10 – 480

spe-address
Syntax

spe-address global-id:prefix

no spe-address

Context

config>service>pw-routing

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

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 parameter is mandatory to enable dynamic MS-PW support on a node.

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

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

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

Also, changing the S-PE Address results in all dynamic MS-PWs for which this node is an S-PE being released. It is recommended that the S-PE Address should be configured for the life of an MS-PW configuration after reboot of the 7210.

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's Autonomous System Number (ASN).

Values:

<global-id:prefix>: <global-id>:{<prefix>|<ipaddress>}

global-id 1 to 4294967295

prefix 1 to 4294967295

ipaddress a.b.c.d

static-route
Syntax

[no] static-route route-name

Context

config>service>pw-routing

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

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 | 0 to 4294967295

ip_addr a.b.c.d

pw-template
Syntax

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

Context

config>service

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

This command configures an SDP template.

Parameters
use-provisioned-sdp

Specifies whether to use an already provisioned SDP. When specified, the tunnel manager is consulted for an existing active SDP. Otherwise, the default SDP template is used to use for instantiation of the SDP.

create

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

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

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 behavior of not using the control word.

Default

no control-word

SDP commands
Note:

SDP commands are supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.

sdp
Syntax

sdp sdp-id [mpls] [create]

no sdp sdp-id

Context

config>service

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

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

The 7210 SAS supported only 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 and 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 and generates 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

accounting-policy
Syntax

accounting-policy acct-policy-id

no accounting-policy

Context

config>service>sdp

config>service>pw-template

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

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 a SDP. If the policy-id does not exist, an error message is generated.

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

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

Default

Default accounting policy.

Parameters
acct-policy-id

Specifies the accounting policy-id, which must be entered as configured in the config> log> accounting-policy context.

Values

1 to 99

collect-stats
Syntax

[no] collect-stats

Context

config>service>sdp

config>service>pw-template

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

This command enables accounting and statistical data collection for an SDP. When applying accounting policies, the data, by default, is collected in the appropriate records and written to the designated billing file.

The no form of this command allows the IOM cards to continue to accumulate statistics. However, the CPU does not obtain the results and write them to the billing file. When 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

discard-unknown-source
Syntax

[no] discard-unknown-source

Context

config>service>pw-template

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

This command enables packets received with an unknown source MAC address to be dropped only if the maximum number of MAC addresses have 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 addresses to be forwarded by destination MAC addresses.

Default

no discard-unknown

hash-label
Syntax

hash-label [signal-capability]

no hash-label

Context

config>service>pw-template

Platforms

7210 SAS-Mxp

Description

This command enables the use of hash label on a VLL or VPLS service bound to LDP or RSVP SDP, using the autobind mode with the ldp, rsvp-te, or mpls options. When the hash-label command is enabled, the ingress 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. Only the hash-2 parameters are used to compute hash-label, even if sdp is over a lag (with load-balancing set as hash-1 or hash-2) or a port. The egress datapath adds the hash label at the bottom of the stack (BoS) and sets the S-bit to one (1).

Note:

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

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

The TTL of the hash label is set to a value of 0.

The user enables the signaling of the hash-label capability under a VLL spoke-SDP, a VPLS spoke-SDP or mesh SDP interface by adding the signal-capability option. In this case, the decision whether to insert the hash label on the user and control plane packets by the local PE is solely determined by the outcome of the signaling process and can override the local PE configuration. The following procedures apply when the hash-label option and the signal-capability option are enabled on the local PE:

  • The 7210 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 that spoke-SDP or mesh SDP.

  • If 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, then the local node disables the hash label capability. Therefore the local PE node does not insert a hash label in user and control plane packets it forwards on the spoke-SDP or mesh SDP. It also drops user and control plane packets received from remote PE if they include a hash label. Note that the latter may be caused by a remote 7210 PE which does not support the hash-label option, or which has the hash-label option enabled but does not support the signal-capability option, or does support both options but the user did not enable them because of a mis-configuration.

  • If remote PE sends Flow Label sub-TLV in the PW ID FEC element with T=TRUE and R=TRUE, then the local PE enables the hash label capability. Therefore local PE inserts a hash label in user and control plane packets it forwards on the spoke-SDP or mesh SDP. It also accepts user and control plane packets remote PE, with or without hash label

    • If the hash-label option was enabled on the local configuration of the spoke-SDP or mesh SDP at the remote PE, the pseudowire packets received by the local PE have the hash label included. These packets must be dropped. The only way to solve this is to disable the signaling 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 was not enabled on the local configuration of the spoke-SDP or mesh SDP at the remote PE, the pseudowire received by the local PE does not have the hash label included.

The user can enable or disable the signal-capability option in CLI as needed. When doing so, the router must withdraw the label it sent to its peer and send a new label mapping message with the new value of the F bit in the flow label interface parameters sub-TLV of the PW ID FEC element.

Note:

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

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

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

Default

no hash-label

Parameters
signal-capability

Enables the signaling and negotiation of the use of the hash label between the local and remote PE nodes.

limit-mac-move
Syntax

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

no limit-mac-move

Context

config>service>pw-template

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

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

Default

blockable

Parameters
blockable

Specifies that the agent monitors the MAC relearn rate, and block it when the relearn rate is exceeded.

non-blockable

When specified, a SAP is not blocked, and another blockable SAP is blocked instead.

vc-type
Syntax

vc-type {ether | vlan}

Context

config>service>pw-template

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

This command overrides the default VC type signaled for the binding to the far end SDP. The VC type is a 15 bit-quantity containing a value which represents the type of VC. The actual signaling of the VC type depends on the signaling parameter defined for the SDP. If signaling is disabled, the 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

Specifies the VC type as Ethernet. The ether and vlan keywords are mutually exclusive. When the VC type is not defined then the default is Ethernet for spoke-SDP bindings. Defining Ethernet is the same as executing no vc-type and restores the default VC type for the spoke-SDP binding. (hex 5)

vlan

Specifies the VC type as VLAN. The ether 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 0..4094

no vlan-vc-tag [0..4094]

Context

config>service>pw-template

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

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

Specifies a valid VLAN identifier to bind an 802.1Q VLAN tag ID.

adv-mtu-override
Syntax

[no] adv-mtu-override

Context

config>service>sdp

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

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

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

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

The no form of the 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

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

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-Mxp, R6, R12, S, Sx, T Routing Protocols Guide.

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

Default

no bgp-tunnel (BGP tunnel route to SDP far-end is disabled)

far-end
Syntax

far-end ip-address | ipv6-address node-id node-id [global-id global-id]

no far-end

Context

config>service>sdp

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

This command configures the system IP address of the far-end destination 7210 SAS router for the Service Distribution Point (SDP) that is the termination point for a service.

The far-end IP address must be explicitly configured. The destination IP address must be a 7210 SAS 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 generates an error if used in the no far-end command. The SDP must be administratively disabled using the config service sdp shutdown command before the no far-end command can be executed. Removing the far end IP address causes all lsp-name associations with the SDP to be removed.

Parameters
ip-address

Specifies the system address of the far-end 7210 SAS devices for the SDP in dotted-decimal notation.

ipv6-address

Specifies the system address of the far-end 7210 SAS devices for the SDP in dotted-decimal notation.

node-id node-id

Specifies the MPLS-TP Node ID of the far-end system for the SDP, either in dotted-decimal notation (a.b.c.d) or an unsigned 32-bit integer (1 – 4294967295). This parameter is mandatory for an SDP using an MPLS-TP LSP.

global-id global-id

Specifies the MPLS-TP Global ID of the far-end system for the SDP, in an unsigned 32-bit integer (0 – 4294967295). This parameter is optional for an SDP using an MPLS-TP LSP. If note entered, a default value for the Global ID of ‛0’ is used. A global ID of ‛0’ indicates that the far end node is in the same domain as the local node. The user must explicitly configure a Global ID if its value is non-zero.

metric
Syntax

metric metric

no metric

Context

config>service>sdp

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

This command specifies 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.

Parameters
metric

Specifies the SDP metric.

Values

0 to 65535

mixed-lsp-mode
Syntax

[no] mixed-lsp-mode

Context

config>service>sdp

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

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

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

If the user configures an LDP LSP as a primary LSP type, then 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 activates 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 is used per SDP. 7210 SAS does not support LDP ECMP.

  3. BGP LSP type. One RFC 3107-labeled BGP prefix programmed by the service manager.

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

When a higher priority LSP type becomes available, the service manager reverts back to this LSP at the expiry of the 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, then the SDP reverts to the highest priority type LSP only if the currently active LSP failed.

Note however, that LDP uses a tunnel down damp timer which is set to three seconds by default. When the LDP LSP fails, the SDP reverts to the RSVP LSP type after the expiry of this timer. For an immediate switchover this timer must be set to zero. Use the configure>router>ldp>tunnel-down-damp-time command.

Note:

For more information about the configure>router>ldp>tunnel-down-damp-time command, see the 7210 SAS-Mxp, R6, R12, S, Sx, T MPLS Guide.

If the user changes the value of the sdp-revert-time timer, it takes effect only at the next use of the timer. Any timer that is outstanding at the time of the change is restarted with the new value.

In the case of the LDP/BGP SDP, the service manager giver preference to 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.

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

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

Default

no mixed-lsp-mode

revert-time
Syntax

revert-time {revert-time | infinite}

no revert-time

Context

config>service>sdp>mixed-lsp-mode

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

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

Sets the SDP to never revert to another higher priority LSP type unless the currently active LSP type is down.

ldp
Syntax

[no] ldp

Context

config>service>sdp

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

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 (disabled)

lsp
Syntax

lsp lsp-name

no lsp lsp-name

Context

config>service>sdp

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

This command creates associations between one label switched paths (LSPs) and an Multi-Protocol Label Switching (MPLS) Service Distribution Point (SDP). This command is implemented only on MPLS-type encapsulated SDPs.

In MPLS SDP configurations either one LSP can be specified.

The LSP must have already been created in the config>router>mpls context. 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 shutdown, 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 associations from an SDP. If the lsp-name does not exist as an association or as a configured LSP, no error is returned. An lsp-name must be removed from all SDP associations before the lsp-name can be deleted from the system. The SDP must be administratively disabled (shutdown) before the last lsp-name association with the SDP is deleted.

Parameters
lsp-name

Specifies the name of the LSP to associate with the SDP. An LSP name is case sensitive and is limited to 32 ASCII 7-bit printable characters with no spaces. If an exact match of lsp-name does not already exist as a defined LSP, an error message is generated. If the lsp-name does exist 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

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

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

To modify the signaling configuration, the SDP must be administratively shut down so the signaling parameter can be modified and re-enabled.

Default

tldp

Parameters
off

Specifies 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

Specifies that ingress and egress pseudowire signaling using T-LDP is enabled.

bgp

Specifies that ingress and egress pseudowire signaling using BGP is enabled. This option 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-Mxp, 7210 SAS-Sx/S 1/10GE (standalone mode), and 7210 SAS-Sx 10/100GE (standalone mode)

Description

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

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

Default

no sr-isis

sr-ospf
Syntax

[no] sr-ospf

Context

config>service>sdp

Platforms

7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE (standalone mode), and 7210 SAS-Sx 10/100GE (standalone mode)

Description

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

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

Default

no sr-ospf

path-mtu
Syntax

path-mtu bytes

no path-mtu

Context

config>service>sdp

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

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

The default SDP-type path-mtu can be overridden on a per SDP basis. Dynamic maintenance protocols on the SDP like RSVP may override this setting.

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

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

Default

path-mtu defined on the system for the type of SDP is used

SDP keepalive commands
keep-alive
Syntax

keepalive

Context

config>service>sdp

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

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 only sent when the SDP-ID is completely configured and administratively up. If the SDP-ID is administratively down, keepalives for that SDP-ID are disabled. SDP Echo Requests (when sent for keepalive messages) are always sent with the originator-sdp-id. All SDP-ID keepalive SDP Echo Replies are sent using generic IP OAM encapsulation.

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

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

The following table describes keepalive interpretation of SDP echo reply response conditions and the effect on the SDP ID operational status.

Table 8. Keepalive request results

Result of request

Stored response state

Operational state

keepalive request timeout without reply

Request Timeout

Down

keepalive request not sent because of non-existent orig-sdp-id1

Orig-SDP Non-Existent

Down

keepalive request not sent because of administratively down orig-sdp-id

Orig-SDP Admin-Down

Down

keepalive reply received, invalid origination-id

Far End: Originator-ID Invalid

Down

keepalive reply received, invalid responder-id

Far End: Responder-ID Error

Down

keepalive reply received, No Error

Success

Up

(If no other condition prevents)

1 This condition should not occur.
hello-time
Syntax

hello-time seconds

no hello-time

Context

config>service>sdp>keep-alive

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

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

The no form of this command reverts the hello-time seconds value to the default setting.

Default

hello-time 10 — 10 seconds between keepalive messages

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

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

This command configures the minimum time period the SDP remains in the operationally down state in response to SDP keepalive monitoring. It can be used to prevent the SDP operational state from ‟flapping” by rapidly transitioning between the operationally up and operationally down states based on keepalive messages.

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

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

Default

hold-down-time 10 — The SDP is operationally down for 10 seconds after an SDP keepalive error.

Parameters
seconds

Specifies the time in seconds, expressed as a decimal integer, the sdp-id remains in the operationally down state before it is eligible to enter the operationally up state. A value of 0 indicates that no hold-down-time is enforced for sdp-id.

Values

0 to 3600

max-drop-count
Syntax

max-drop-count count

no max-drop-count

Context

config>service>sdp>keep-alive

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

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 is brought operationally down by the keepalive SDP monitoring.

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

Default

max-drop-count 3

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

message-length
Syntax

message-length octets

no message-length

Context

config>service>sdp>keep-alive

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

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

The no form of this command reverts the message-length octets value to the default setting.

Default

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

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.

Values

40 to 9198

timeout
Syntax

timeout timeout

no timeout

Context

config>service>sdp>keep-alive

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

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

Default

5

Parameters
timeout

Specifies the timeout time, in seconds.

Values

1 to 10

Show commands

Show service 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, including those operating in access-uplink mode

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 which is an anchor point for an ingress and egress virtual scheduler hierarchy.

Output

The following output is an example of service customer information, and Output fields: customer describes the output fields.

Sample output
*A:ALA-12# show service customer
==========================================================
Customers
==========================================================
Customer-ID : 1
Contact     : Manager
Description : Default customer
Phone       : (123) 555-1212

Customer-ID : 2
Contact     : Tech Support
Description : TiMetra Networks
Phone       : (234) 555-1212

Customer-ID : 3
Contact     : Test
Description : TiMetra Networks
Phone       : (345) 555-1212

Customer-ID : 6
Contact     : Test1
Description : Epipe Customer
Phone       : (456) 555-1212

Customer-ID : 7
Contact     : Test2
Description : VPLS Customer
Phone       : (567) 555-1212

Customer-ID : 274
Contact     : TestA
Description : ABC Company
Phone       : 650 123-4567

Customer-ID : 94043
Contact     : Test Engineer on Duty
Description : TEST Customer
Phone       : (789) 555-1212
------------------------------------------------------
Total Customers : 8
-----------------------------------------------------------
*A:ALA-12#
*A:ALA-12# show service customer 274
==============================================================================
Customer  274
==============================================================================
Customer-ID : 274
Contact     : Mssrs. Beaucoup
Description : ABC Company
Phone       : 650 123-4567
------------------------------------------------------------------------------
Multi Service Site
------------------------------------------------------------------------------
Site        : west
Description : (Not Specified)
==============================================================================
*A:ALA-12#
Table 9. 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/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's multi-service site.

Assignment

The port ID, MDA, or card number, where the SAP's that are members of this multi- service site are defined.

I. Sched Pol

The ingress QoS scheduler policy assigned to this multi-service site.

E. Sched Pol

The egress QoS scheduler policy assigned to this multi-service site.

Service-ID

The ID that uniquely identifies a service.

SAP

Specifies the SAP assigned to the service.

fdb-mac
Syntax

fdb-mac [ieee-address] [expiry]

Context

show>service

Platforms

Supported on all 7210 SAS platforms as described in this document, including those operating in access-uplink mode

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

Shows amount of time until MAC is aged out.

Output

The following output is an example of FDB entry information for a specific MAC address, 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 10. Output fields: FDB MAC

Label

Description

ServId

Displays the configured service ID.

MAC

Displays the MAC address.

Source-Identifier

Displays the ocation where the MAC is defined.

Type/Expiry

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

sdp
Syntax

sdp sdp-id keep-alive-history

sdp far-end ip-address keep-alive-history

sdp [sdp-id] [detail]

sdp far-end ip-address [detail]

Context

show>service

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

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 with 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 service SDP information, and Output fields: SDP describes the output fields.

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


*7210SAS>show>service# sdp 1 detail

===============================================================================
Service Destination Point (Sdp Id : 1) Details
===============================================================================
-------------------------------------------------------------------------------
 Sdp Id 1  -0.0.0.0
-------------------------------------------------------------------------------
Description           : (Not Specified)
SDP Id               : 1                     SDP Source         : manual
Admin Path MTU       : 0                     Oper Path MTU      : 0
Far End              : 0.0.0.0               Delivery           : MPLS
Tunnel Far End       : n/a                   LSP Types          : None

Admin State          : Down                  Oper State         : Down
Signaling            : TLDP                  Metric             : 0
Acct. Pol            : None                  Collect Stats      : Disabled
Last Status Change   : 11/04/2099 22:56:41   Adv. MTU Over.     : No
Last Mgmt Change     : 11/10/2099 15:56:44   VLAN VC Etype      : 0x8100
Bw BookingFactor     : 100                   PBB Etype          : 0x88e7
Oper Max BW(Kbps)    : 0                     Avail BW(Kbps)     : 0
Net-Domain           : default               Egr Interfaces     : n/a
Flags                : SdpAdminDown NoSysIPAddr
                       TranspTunnDown

Mixed LSP Mode Information :
Mixed LSP Mode       : Enabled               Active LSP Type    : RSVP....also be LD
P, BGP
Revert Time          : 200                   Revert Count Down  : n/a

KeepAlive Information :
Admin State          : Disabled              Oper State         : Disabled
Hello Time           : 10                    Hello Msg Len      : 0
Hello Timeout        : 5                     Unmatched Replies  : 0
Max Drop Count       : 3                     Hold Down Time     : 10
Tx Hello Msgs        : 0                     Rx Hello Msgs      : 0

-------------------------------------------------------------------------------
RSVP/Static LSPs
-------------------------------------------------------------------------------
Associated LSP List :
No LSPs Associated

===============================================================================
*7210SAS>show>service#

Table 11. Output fields: 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 because the keepalive was administratively enabled or the counter was cleared.

Rx Hello Msgs

The number of SDP echo request messages received because the keepalive was administratively enabled or the counter was cleared.

Associated LSP List

When the SDP type is MPLS, a list of LSPs used to reach the far-end router displays. All the LSPs in the list must terminate at the IP address specified in the far end field.

Lsp Name

Displays the LSP name.

Time Since Last Transaction

Displays the time of the last transaction.

Signaling

Specifies the signaling type.

Metric

Displays the metric to be used within the Tunnel Table Manager for decision making purposes. When multiple SDPs going to the same destination exist, this value is used as a tie-breaker by Tunnel Table Manager users like MP-BGP to select route with lower value.

Acct. Pol

Displays the policy to use to collect accounting statistics on this SDP. The value zero indicates that the agent should use the default accounting policy, if one exists.

Collect Stats

Specifies whether the agent collects accounting statistics for this SDP. When the value is true the agent collects accounting statistics on this SDP.

VLAN VC Etype

Displays the VLAN VC type.

BW Booking Factor

Specifies the value used to calculate the max SDP available bandwidth. The value specifies the percentage of the SDP max available bandwidth for VLL call admission. When the value of is set to zero (0), no new VLL spoke-SDP bindings with non-zero bandwidth are permitted with this SDP. Overbooking, >100% is allowed.

PBB Etype

Displays the Ethertype used in frames sent out on this SDP when specified as vlan for Provider Backbone Bridging frames.

Oper Max BW (Kbps)

Indicates the operational bandwidth in kilo-bits per seconds (Kbps) available for this SDP. The value is determined by the sum of the bandwidth of all the RSVP LSPs used by the SDP.

Avail BW (Kbps)

Indicates the bandwidth that is still free for booking by the SDP bindings on the SDP.

Net-Domain

Specifies the network-domain name configured on this SDP. The default value of this object is the default network-domain.

Egr Interface

Indicates whether all the egress network interfaces that can carry traffic on this SDP are associated with the network-domain configured on this SDP.

Not applicable: Indicates that there is no egress network interface that can carry traffic on this SDP.

Consistent: Indicates that the network-domains for all the egress network interfaces that can carry traffic on this SDP are consistent.

Inconsistent: Indicates that the network-domain for one or more egress network interfaces that can carry traffic on this SDP are inconsistent.

Mixed LSP Mode

Indicates if the SDP is enabled to use mixed-mode-lsp.

Active LSP Type

Displays the LSP type that is currently active and in use to transport service packets. When multiple LSPs are configured under the SDP and enabled with the command 'mixed-mode-lsp', the active LSP could be one of the configured ones. It displays RSVP, if the LSP in use is of type RSVP LSP, LDP if the LSP in use is of type LDP LSP and BGP 3107, if LSP if of type RFC 3107 BGP Labeled route LSP.

Revert Time

Specifies the time to wait before reverting back from LDP to the configured LSPs, after having failed over to LDP.

Revert Count Down

Indicates the timer countdown before reverting back from LDP on this SDP. The timer countdown begins after the first configured LSP becomes active.

Flags

Displays all the conditions that affect the operating status of this SDP.

Class Forwarding

Indicates the admin state of class-based forwarding on this SDP. When the value is true, class-based forwarding is enabled.

EnforceDSTELspFc

Specifies whether service manager must validate with RSVP the support of the FC by the LSP.

Default LSP

Specifies the LSP ID that is used as a default when class-based forwarding is enabled on this SDP. This object must be set when enabling class-based forwarding.

Multicast LSP

Displays the LSP ID that all multicast traffic is forwarded on when class-based forwarding is enabled on this SDP. When this object has its default value, multicast traffic is forwarded on an LSP according to its forwarding class mapping.

Number of SDPs

The total number of SDPs displayed according to the criteria specified.

sdp-using
Syntax

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

Context

show>service

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

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 about services using SDP, and Output fields: SDP-using describes the output fields.

Sample output
*A:ALA-7210M# 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-7210M#
Table 12. 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] [vpls] [b-vpls] [m-vpls] [sdp sdp-id] [customer customer-id]

Context

show>service

Platforms

Supported on all 7210 SAS platforms as described in this document, including those operating in access-uplink mode

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.

vpls

Displays matching VPLS instances.

b-vpls

Displays matching B-VPLS instances. This parameter is not supported on 7210 SAS platforms operating in access-uplink mode.

sdp sdp-id

Displays only services bound to the specified SDP ID. This parameter is not supported on 7210 SAS platforms operating in access-uplink mode.

Values

1 to 17407

Default

Services bound to any SDP ID.

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 service information, and Output fields: service-using describes the output fields.

Sample output
*7210SAS>show>service# service-using customer 1

===============================================================================
Services  Customer 1
===============================================================================
ServiceId    Type      Adm  Opr  CustomerId Service Name
-------------------------------------------------------------------------------
1            VPLS      Up   Up   1
2            VPLS      Up   Up   1
3            VPLS      Up   Up   1
4            VPLS      Up   Up   1
2147483648   IES       Up   Down 1          _tmnx_InternalIesService
2147483649   intVpls   Up   Down 1          _tmnx_InternalVplsService
-------------------------------------------------------------------------------
Matching Services : 6
-------------------------------------------------------------------------------
===============================================================================
*7210SAS>show>service#

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

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, including those operating in access-uplink mode

Description

This command displays the Ethernet rings information.

Parameters
status

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

hierarchy

Displays eth-ring hierarical relationships.

path {a|b}

Displays information related to the configured Ethernet rings.

ring-index

Specifies the ring index of the Ethernet ring.

Values

1to128

Output

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

Sample output — Standard
*A:NS1015C0821>show# eth-ring 10

===============================================================================
Ethernet Ring 10 Information
===============================================================================
Description        : (Not Specified)
Admin State        : Down               Oper State       : Down
Node ID            : 00:25:ba:03:48:04
Guard Time         :    5 deciseconds   RPL Node         : rplNone
Max Revert Time    :  300 seconds       Time to Revert   : N/A
CCM Hold Down Time :    0 centiseconds  CCM Hold Up Time :   20 deciseconds
Compatible Version : 2
APS Tx PDU         : N/A
Defect Status      :
Sub-Ring Type      : virtualLink        Interconnect-ID  : N/A

-------------------------------------------------------------------------------
Ethernet Ring Path Summary
-------------------------------------------------------------------------------
Path Port     Raps-Tag     Admin/Oper      Type            Fwd State
-------------------------------------------------------------------------------
  a  -        -                 -/-         -               -
  b  -        -                 -/-         -               -
===============================================================================
*A:NS1015C0821>show#

Table 14. Output fields: Ethernet 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.

Sample output — Ethernet ring status
*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 15. Output fields: Ethernet 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

pw-routing
Syntax

pw-routing {local-prefix | static-route | paths | all}

pw-routing route-table [all-routes]

pw-routing route-table summary

Context

show>service

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

This command displays PW routing information at this 7210 node.

Parameters
local-prefix | static-route | paths | all

Displays details of the T-PE prefixes configured on this node, static routes from this node, explicit PW paths configured on this node, or all of these.

route-table [all-routes]

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

route-table summary

Displays a summary of the PW routing table for this node.

Output

The following output is an example of PW routing information.

Sample output
*A:Dut-C# show service pw-routing local-prefix 
===============================================================================
Service PW Routing Information
===============================================================================
===============================================================================
Service PW Routing Local-Prefix RD Information
===============================================================================
Local-Prefix               Route-Dist                 Community       Adv-Bgp
-------------------------------------------------------------------------------
3:10.20.1.3                100:3                      100:3           enabled
                           100:4                      100:4           enabled
-------------------------------------------------------------------------------
Local-Prefix Entries found: 1
===============================================================================
===============================================================================
*A:Dut-C# show service pw-routing static-route 
===============================================================================
Service PW Routing Information
===============================================================================
=========================================================
Service PW Routing Static-Route Information
=========================================================
Prefix                        Next-Hop
---------------------------------------------------------
6:10.20.1.6/64                10.20.1.5
---------------------------------------------------------
Static Route Entries found: 1
=========================================================
===============================================================================


*A:Dut-C# show service pw-routing paths        
===============================================================================
Service PW Routing Information
===============================================================================
=============================================================
Service PW Routing Path Information
=============================================================
Path                             Adm     Hop IP Address
-------------------------------------------------------------
path1_to_F                       up      1   10.20.1.5
                                         2   10.20.1.2
path1_to_F2                      up      1   10.20.1.2
                                         2   10.20.1.5
-------------------------------------------------------------
Path Entries found: 2
=============================================================
===============================================================================


*A:Dut-C# show service pw-routing all        
===============================================================================
Service PW Routing Information
===============================================================================
SPE-Address       : 3:10.20.1.3
Boot Timer        : 10 secs
Boot Timer Remain : 0 secs
Retry Timer       : 30 secs
Retry Count       : 30

===============================================================================
Service PW Routing Local-Prefix RD Information
===============================================================================
Local-Prefix               Route-Dist                 Community       Adv-Bgp
-------------------------------------------------------------------------------
3:10.20.1.3                100:3                      100:3           enabled
                           100:4                      100:4           enabled
-------------------------------------------------------------------------------
Local-Prefix Entries found: 1
===============================================================================
=========================================================
Service PW Routing Static-Route Information
=========================================================
Prefix                        Next-Hop
---------------------------------------------------------
6:10.20.1.6/64                10.20.1.5
---------------------------------------------------------
Static Route Entries found: 1
=========================================================
=============================================================
Service PW Routing Path Information
=============================================================
Path                             Adm     Hop IP Address
-------------------------------------------------------------
path1_to_F                       up      1   10.20.1.5
                                         2   10.20.1.2
path1_to_F2                      up      1   10.20.1.2
                                         2   10.20.1.5
-------------------------------------------------------------
Path Entries found: 2
=============================================================
===============================================================================


*A:Dut-C# show service pw-routing route-table all-routes 
===============================================================================
Service PW L2 Routing Information
===============================================================================
AII-Type2/Prefix-Len                           Next-Hop       Owner  Age
 Route-Distinguisher                            Community      Best  
-------------------------------------------------------------------------------
3:10.20.1.3:0/64                               10.20.1.3      local  00h32m08s
 0:0                                            0:0            yes    
3:10.20.1.3:1/96                               10.20.1.3      host   00h32m08s
 0:0                                            0:0            yes    
3:10.20.1.3:2/96                               10.20.1.3      host   00h32m08s
 0:0                                            0:0            yes    
3:10.20.1.3:3/96                               10.20.1.3      host   00h32m08s
 0:0                                            0:0            yes    
3:10.20.1.3:4/96                               10.20.1.3      host   00h32m08s
 0:0                                            0:0            yes    
3:10.20.1.3:5/96                               10.20.1.3      host   00h32m08s
 0:0                                            0:0            yes    
3:10.20.1.3:6/96                               10.20.1.3      host   00h32m08s
 0:0                                            0:0            yes    
3:10.20.1.3:7/96                               10.20.1.3      host   00h32m08s
 0:0                                            0:0            yes    
3:10.20.1.3:8/96                               10.20.1.3      host   00h32m08s
 0:0                                            0:0            yes    
3:10.20.1.3:9/96                               10.20.1.3      host   00h32m08s
 0:0                                            0:0            yes    
3:10.20.1.3:10/96                              10.20.1.3      host   00h32m07s
 0:0                                            0:0            yes    
6:10.20.1.6:0/64                               10.20.1.5      static 00h07m33s
 0:0                                            0:0            yes    
6:10.20.1.6:0/64                               10.20.1.5      bgp    00h31m34s
 100:6                                          100:6          no     
-------------------------------------------------------------------------------
Entries found: 13
===============================================================================


*A:Dut-C# show service pw-routing route-table summary 
========================================
Service PW L2 Routing Summary
========================================
Source              Active
----------------------------------------
BGP                 1
Static              1
Host                10
Local               3
----------------------------------------
Total               15
========================================
pw-template
Syntax

pw-template

Context

show>service

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

This command displays pseudowire template information.

Output

The following output is an example of PW template information.

Sample output
*A:Dut-B#    show service  pw-template 1         
=======================================================================
PW Template Information
=======================================================================
PW Tmpl Id           : 1                    
Use Provisioned Sdp  : enabled              VcType           : vlan
Acctg Policy         : default              Collect Stats    : disabled
Mac-Learning         : enabled              Mac-Ageing       : enabled
Discard Unkn Src     : disabled             Limit MacMove    : blockable
Mac-Pinning          : disabled             Vlan VcTag       : 4095
MAC Address Limit    : no limit             Rest Prot Src Mac: disabled
Auto Learn Mac Prot  : disabled             RestProtSrcMacAct: disable
Block On Peer Fault  : disabled             

SHG
Name                 :                      
Description          : (Not Specified)
Rest Prot Src Mac    : disabled             Rest Unprot Dst  : disabled
Auto Learn Mac Prot  : disabled             RestProtSrcMacAct: disable

Egress
Mac FilterId         : none                 Ip FilterId      : none
Ipv6 FilterId        : none                 QoS NetPlcyId    : none
Port RedirectQGrp    : none                 Instance Id      : none

Ingress
Mac FilterId         : none                 Ip FilterId      : none
Ipv6 FilterId        : none                 QoS NetPlcyId    : none
Fp RedirectQGrp      : none                 Instance Id      : none

IGMP
Fast Leave           : disabled             Import Plcy      : none
Last Memb Intvl      : 10 deci-secs         Max Nbr Grps     : 0
Send Queries         : disabled             
Version              : 3                    

Force VlanVc Fwd     : disabled             Control Word     : disabled
Hash Label           : disabled             Hash Lbl Sig Cap : disabled
Last Changed         : 02/12/2013 22:11:49  
-----------------------------------------------------------------------
Included SDP-Groups
-----------------------------------------------------------------------
red
-----------------------------------------------------------------------
saii-type2-using
Syntax

saii-type2-using global-id[:prefix[:ac-id]]

Context

show>service

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

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

Parameters
global-id[:prefix[:ac-id]]

Specifies the switch-point information using SAII-Type2.

Values

<global-id[:prefix*> : <global-id>[:<prefix>[:<ac-id>]]

global-id

1..4294967295

prefix

a.b.c.d | 1..4294967295

ac-id

1..4294967295

Output

The following output is an example of information about an SDP used by a spoke-SDP FEC with a specified FEC129 type 2 SAII, and Output fields: SDP describes the output fields.

Sample output
*A:Dut-E# show service saii-type2-using 3:10.20.1.3:1 
===================================================================
Service Switch-Point Information
===================================================================
SvcId      Oper-SdpBind      SAII-Type2
-------------------------------------------------------------------
2147483598 17407:4294967195  3:10.20.1.3:1
-------------------------------------------------------------------
Entries found: 1
===================================================================
Table 16. Output fields: SDP

Label

Description

SvcId

Displays the service ID.

spoke-sdp-fec-using
Syntax

spoke-sdp-fec-using [spoke-sdp-fec-id spoke-sdp-fec-id] [saii-type2 global-id:prefix:ac-id] [taii-type2 global-id:prefix:ac-id] [path name] [expired] taii-type2-using global-id[:prefix[:ac-id]]

Context

show>service

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

This commmand displays the SDPs used by spoke-sdp-fecs at this node.

Output

The following output is an example of information about SDPs being used by spoke-SDP FECs.

Sample output
*A:Dut-C# show service spoke-sdp-fec-using
===============================================================================
Service Spoke-SDP-Fec Information
===============================================================================
SvcId SpokeSdpFec Oper-SdpBind SAII-Type2
Path TAII-Type2
-------------------------------------------------------------------------------
1 1 17407:4294967245 3:10.20.1.3:1
n/a 6:10.20.1.6:1
2 2 17407:4294967247 3:10.20.1.3:2
n/a 6:10.20.1.6:2
3 3 17407:4294967248 3:10.20.1.3:3
n/a 6:10.20.1.6:3
4 4 17407:4294967249 3:10.20.1.3:4
n/a 6:10.20.1.6:4
5 5 17407:4294967250 3:10.20.1.3:5
n/a 6:10.20.1.6:5
6 6 17407:4294967251 3:10.20.1.3:6
n/a 6:10.20.1.6:6
7 7 17407:4294967252 3:10.20.1.3:7
n/a 6:10.20.1.6:7
8 8 17407:4294967253 3:10.20.1.3:8
n/a 6:10.20.1.6:8
9 9 17407:4294967254 3:10.20.1.3:9
n/a 6:10.20.1.6:9
10 10 17407:4294967255 3:10.20.1.3:10
n/a 6:10.20.1.6:10
-------------------------------------------------------------------------------
Entries found: 10
===============================================================================
taii-type2-using
Syntax

taii-type2-using global-id[:prefix[:ac-id]]

Context

show>service

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

This command displays switch-point information using TAII.

Parameters
global-id[:prefix[:ac-id]]

Specifies the switch-point information using SAII-Type2.

Values

<global-id[:prefix*> : <global-id>[:<prefix>[:<ac-id>]]

global-id

1..4294967295

prefix

a.b.c.d | 1 to 4294967295

ac-id

1 to 4294967295

Output

The following output is an example of information about a switch-point using TAII Type 2.

Sample output
*A:Dut-E# show service taii-type2-using 6:10.20.1.6:1 
===================================================================
Service Switch-Point Information
===================================================================
SvcId      Oper-SdpBind      TAII-Type2
-------------------------------------------------------------------
2147483598 17407:4294967195  6:10.20.1.6:1
-------------------------------------------------------------------
Entries found: 1
=====================================================

Show ETH-CFM commands
eth-cfm
Syntax

eth-cfm

Context

show

Platforms

Supported on all 7210 SAS platforms as described in this document, including those operating in access-uplink mode

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, including those operating in access-uplink mode

Description

This command displays eth-cfm association information.

Parameters
ma-index

Specifies the maintenance association (MA) index.

Values

1 to 4294967295

detail

Displays more information for the eth-cfm association.

Output

Show eth-cfm association command output

The following output is an example of eth-cfm association information, and Output fields: ETH-CFM association describes output fields.

Sample output
A:dut-b# show eth-cfm association 

======================================================================
CFM Association Table
======================================================================
Md-index   Ma-index   Name                     CCM-interval Bridge-id          
----------------------------------------------------------------------
1          1          a1                       1            1         
1          2          a2                       1            2         
2          1          a1                       1            2         
2          2          a2                       1            1         
======================================================================
A:dut-b#
Table 17. Output fields: ETH-CFM 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 which is unique within the maintenance domain name.

CCM-interval

Displays the CCM transmission interval for all MEPs in the association.

Bridge-id

Displays the bridge-identifier value for the domain association.

MHF Creation

Displays the MIP half function (MHF) for the association.

Primary VLAN

Displays the primary bridge-identifier VLAN ID.

Num Vids

Displays the number of VIDs associated with the VLAN.

Remote Mep Id

Displays the remote maintenance association end point (MEP) identifier

cfm-stack-table
Syntax

cfm-stack-table [{all-ports}] [level 0..7] [direction <down>]

Context

show>eth-cfm

Platforms

Supported on all 7210 SAS platforms as described in this document, including those operating in access-uplink mode

Description

This command displays stack-table information. This stack-table is used to display the various management points MEPs and MIPs that are configured on the system. This can be Service based. The various options allow the operator to be specific. If no parameters are include then 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 down

Displays the direction in which the MP faces on the bridge port.

Output

Show eth-cfm CFM stack table command output

The following output is an example of eth-cfm CFM stack table information, and Output fields: CFM stack table describes the fields.

Sample output
*A:7210SAS>show>eth-cfm# cfm-stack-table

========================================================================
CFM SAP Stack Table
========================================================================
Sap            Level Dir  Md-index   Ma-index   Mep-id Mac-address
------------------------------------------------------------------------
1/1/18:100     7     Up   7          100        1      00:25:ba:0d:21:13
========================================================================

========================================================================
CFM Ethernet Tunnel Stack Table
========================================================================
Eth-tunnel     Level Dir  Md-index   Ma-index   Mep-id Mac-address
------------------------------------------------------------------------
No Matching Entries
========================================================================

========================================================================
CFM SDP Stack Table
========================================================================
Sdp            Level Dir  Md-index   Ma-index   Mep-id Mac-address
------------------------------------------------------------------------
No Matching Entries
========================================================================

========================================================================
CFM Virtual Stack Table
========================================================================
Service        Level Dir  Md-index   Ma-index   Mep-id Mac-address
------------------------------------------------------------------------
No Matching Entries
========================================================================
*A:7210SAS>show>eth-cfm#
Table 18. Output fields: CFM stack table

Label

Description

Sap

Displays associated SAP IDs.

Sdp

Displays the SDP binding for the bridge.

Level Dir

Displays the MD level of the maintenance point.

Md-index

Displays the maintenance domain (MD) index.

Ma-index

Displays the maintenance association (MA) index.

Mep-id

Displays the integer that is unique among all the MEPs in the same MA.

Mac-address

Displays the MAC address of the MP.

domain
Syntax

domain [md-index] [association ma-index | all-associations] [detail]

Context

show>eth-cfm

Platforms

Supported on all 7210 SAS platforms as described in this document, including those operating in access-uplink mode

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

Show eth-cfm Domain Command Output

The following output is an example of eth-cfm domain information, and Output Fields: ETH-CFM domain describes the output fields.

Sample output
A:dut-b# show eth-cfm domain 

==============================================================================
CFM Domain Table
==============================================================================
Md-index   Level Name                                       Format             
------------------------------------------------------------------------------
1          6     d1                                         charString        
2          7     d2                                         charString        
==============================================================================
A:dut-b# 
Table 19. Output Fields: ETH-CFM domain

Label

Description

Md-index

Displays the Maintenance Domain (MD) index value.

Level

Displays an integer identifying the Maintenance Domain Level (MD Level). Higher numbers correspond to higher Maintenance Domains, those with the greatest physical reach, with the highest values for customers' CFM PDUs. Lower numbers correspond to lower Maintenance Domains, those with more limited physical reach, with the lowest values for CFM PDUs protecting single bridges or physical links.

Name

Displays a generic Maintenance Domain (MD) name.

Format

Displays the type of the Maintenance Domain (MD) name. Values include dns, mac, and string.

mep
Syntax

mep mep-id domain md-index association ma-index [loopback] [linktrace]

mep mep-id domain md-index association ma-index remote-mepid mep-id | all-remote-mepids

mep mep-id domain md-index association ma-index eth-test-results [remote-peer mac-address]

mep mep-id domain md-index association ma-index one-way-delay-test [remote-peer mac-address]

mep mep-id domain md-index association ma-index two-way-delay-test [remote-peer mac-address]

mep mep-id domain md-index association ma-index two-way-slm-test [remote-peer macaddress]

Context

show>eth-cfm

Platforms

Supported on all 7210 SAS platforms as described in this document, including those operating in access-uplink mode

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

Sample output
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# 
Show 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

Supported on all 7210 SAS platforms as described in this document, including those operating in access-uplink mode

Description

This command displays connection profile information.

Parameters
conn-prof-id

Specifies the connection profile ID.

Values

1 to 8000

associations

Displays the SAP and the service ID that use this connection profile.

Output

The following output is an example of connection-profile information, and Output fields: connection profile describes output fields.

Sample output — Connection profile

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

Show output for connection-profile associations

*A:7210SAS>show# connection-profile associations

===============================================================================
Connection Profile Summary Information
===============================================================================
CP Index  Number of HasRange
          Members
-------------------------------------------------------------------------------
1         0         No
===============================================================================
*A:7210SAS>show#
Table 20. Output fields: 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.

HasRange

Indicates whether VLAN range is configured.

Tools commands

Tools perform commands
tools
Syntax

tools

Context

root

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

Commands in this context enable useful tools for debugging purposes.

Parameters
dump

Enables dump tools for the various protocols.

perform

Enables tools to perform specific tasks.

perform
Syntax

perform

Context

tools

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

Commands in this context enable tools to perform specific tasks.

service
Syntax

services

Context

tools>perform

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

Commands in this context configure tools for services.

id
Syntax

id service-id

Context

tools>perform>service

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

Commands in this context configure tools for a specific service.

Parameters
service-id

Specify an existing service ID.

Values

1 to 2147483647

endpoint
Syntax

endpoint endpoint-name

Context

tools>perform>service>id

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

This command configures tools for a specific VLL service endpoint.

Parameters
endpoint-name

Specify an existing VLL service endpoint name.

force-switchover
Syntax

force-switchover sdp-id:vc-id

no force-switchover

force-switchover spoke-sdp-fec [1..4294967295]

Context

tools>perform>service>id>endpoint

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

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

Parameters
sdp-id:vc-id

Specify an existing spoke-SDP for the service.

spoke-sdp-fec

The spoke-sdp-fec for a FEC129 AII Type 2 spoke-sdp. This parameter is mutually exclusive with sdp:vc-id used for a FEC 128 spoke-sdp.

Values

1 to 4294967295

Output

The following output is an example of force switchover 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

Context

tools>perform>service

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

This command reevaluates the pseudowire template policy.

Parameters
policy-id

Specifies the pseudowire template policy.

eval-expired-fec
Syntax

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

eval-expired-fec all

Context

tools>perform>service>pw-routing

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

This command resets the retry counter and retry timer for the specified spoke-SDP and attempt to establish the spoke-SDP again.

spoke-sdp-fec-release
Syntax

spoke-sdp-fec-release global-id[:prefix[:ac-id]]

Context

tools>perform>service

Platforms

Supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode

Description

This command is used to clear the MS-PW bindings associated with particular SAII or TAII on an S-PE.