Services Overview
This chapter provides an overview of the 7705 SAR subscriber services, service model, and service entities. Additional details on the individual subscriber services are found in subsequent chapters.
Topics in this chapter include:
Introduction to Services on the 7705 SAR
Topics in this section include:
Overview
A service is a type of telecommunications connection from one place to another. These telecommunications connections have the particular attributes and characteristics that are needed to provide a specific communications link through which an information flow or exchange can occur. The 7705 Service Access Router (7705 SAR) offers VLL services, Layer 2 multipoint VPN services (VPLS), Layer 3 MPLS VPN services (VPRN), and Layer 3 routed/IP services.
The 7705 SAR service model uses (logical) service entities to construct a service. These logical entities provide a uniform, service-centric configuration, management, and billing model for service provisioning (see Nokia Service Model for more information). Many services can be created on the same 7705 SAR at the same time, and each service is uniquely identified by a service ID.
The 7705 SAR offers Virtual Leased Line (VLL) services (also referred to as pseudowire (PW) services or pipes), which emulate a Layer 1/2 entity, such as a wire or a leased line. These emulated services provide connectivity between a service access point (SAP) on one 7705 SAR and on another SAP on the same router, or on a remote 7705 SAR or 7750 SR. VLL services offer SAP logical entities—such as a VLAN or a virtual connection—Layer 2 visibility or processing (IMA termination). A SAP is the point where customer traffic enters and exits the service.
A connection between two SAPs on the same router is known as a local service. A connection between SAPs on a local and a remote router is known as a distributed service. SAP-to-SAP connections are supported for ATM, Ethernet, FR, HDLC, and TDM VLLs.
The 7705 SAR also supports the aggregation of multiple ATM VCC SAPs into a single aggregation group within a service. Aggregation groups enable service providers to make more efficient use of the ATM VCC VLL services that are deployed in a network.
Distributed services use service destination points (SDPs) to direct traffic from a local router to a remote router through a service tunnel. An SDP is created on the local router and identifies the endpoint of a logical unidirectional service tunnel. Traffic enters the tunnel at the SDP on the local router and exits the tunnel at the remote router. Hence a service tunnel provides a path from a 7705 SAR to another service router, such as another 7705 SAR or a 7750 SR. Because an SDP is unidirectional, two service tunnels are needed for bidirectional communication between two service routers (one SDP on each router).
SDPs are configured on each participating 7705 SAR or service router (for example, a 7750 SR), specifying the address of the destination router, such as another 7705 SAR or service router. After SDPs are created, they are bound to a specific service. The binding process is needed to associate the far-end devices to the service; otherwise, far-end devices are not able to participate in the service.
The 7705 SAR also offers IES, VPLS, and VPRN services.
IES provides IP connectivity between customer access points. From the customer’s perspective, IES provides direct IP connectivity. The customer is assigned an IP interface and a SAP designates the customer access point where the customer IP device is connected—one SAP binding per IP interface. Supported SAP encapsulations are MC-MLPPP, PPP/MLPPP and null/dot1q/qinq Ethernet. SDP binding is not required because traffic is routed rather than being encapsulated in a tunnel.
A Virtual Private Routed Network (VPRN) consists of a set of customer sites connected to one or more PE routers. VPRNs are based on RFC 2547bis, which details a method of distributing routing information and forwarding data to provide a Layer 3 Virtual Private Network (VPN) service to end customers. VPRN traffic is transported over LDP and RSVP-TE tunnels, as well as static LSPs.
A Virtual Private LAN Service (VPLS) enables Layer 2 multipoint connections within an enterprise infrastructure. Supported SAP encapsulations are null/dot1q/qinq Ethernet (on the 6-port Ethernet 10Gbps Adapter card, 7705 SAR-X, 8-port Gigabit Ethernet Adapter card, and the 10-port 1GigE/1-port 10GigE X-Adapter card) and ATM (on the 4-port OC3/STM1 Clear Channel Adapter card).
VPLS traffic can also be transported over existing tunnel types like GRE tunnels, LDP tunnels, RSVP-TE tunnels, and static LSPs using SDPs. For the ATM SAPs, the Layer 2 Ethernet frames are encapsulated in llc-snap bridged PDUs, as per RFC 2684, widely referred to with the obsoleted RFC 1483.
Service Types
Services are commonly called customer or subscriber services. The 7705 SAR offers the following types of services, which are described in more detail in the referenced chapters:
Virtual Leased Line (VLL) services
ATM VLL (Apipe)—a pseudowire emulation edge-to-edge (PWE3) ATM service over MPLS, GRE, or IP tunnels on 7705 SAR nodes. See ATM VLL (Apipe) Services.
Circuit emulation VLL (Cpipe)—a PWE3 circuit emulation service over MPLS or GRE tunnels on 7705 SAR nodes. See Circuit Emulation VLL (Cpipe) Services.
Ethernet VLL (Epipe)—a PWE3 Ethernet service over MPLS or GRE tunnels for Ethernet frames on 7705 SAR nodes. See Ethernet VLL (Epipe) Services.
FR VLL (Fpipe)—a PWE3 FR service over MPLS or GRE tunnels for FR frames on 7705 SAR nodes. See Frame Relay VLL (Fpipe) Services.
HDLC VLL (Hpipe)—a PWE3 HDLC service over MPLS or GRE tunnels for HDLC frames on 7705 SAR nodes. See HDLC VLL (Hpipe) Services.
IP interworking VLL (Ipipe)—a PWE3 IP service between two hosts connected by any combination of point-to-point access circuits. IP interworking VLLs can operate over MPLS or GRE networks. Some typical examples are Ethernet SAP to Ethernet SAP, Ethernet SAP to MLPPP SAP, Ethernet SAP to LAG SAP, FR SAP to Ethernet SAP, or cHDLC SAP to Ethernet SAP. See IP Interworking VLL (Ipipe) Services.
Internet Enhanced Service (IES)
IES is used both as a direct Internet access service where the customer is assigned an IP interface for routed connectivity and for in-band management of the 7705 SAR. See Internet Enhanced Service.
Virtual Private LAN Service (VPLS)
VPLS provides a Layer 2 multipoint VPN service to end customers. VPLS includes Hierarchical VPLS (H-VPLS), which is an enhancement of VPLS that extends pseudowire-style signaled or static virtual circuit labeling outside the fully meshed VPLS core. The 7705 SAR can participate in hierarchical VPLS. In addition, the 7705 SAR supports management VPLS (mVPLS) via Rapid Spanning Tree Protocol (RSTP). See VPLS.
Virtual Private Routed Network Service (VPRN)
VPRN provides a Layer 3 VPN service to end customers. VPRN services provide MP-BGP peering with other PEs, configurable QoS policy and filtering, VRF import and export policies, and SGT-QoS marking. See VPRN Services.
Pseudowire Service Types lists the supported pseudowire (PW) service types. The values are as defined in RFC 4446.
PW Service Type (Ethertype) |
Value |
|---|---|
IP Layer 2 transport |
0x000B |
Ethernet tagged mode |
0x0004 |
Ethernet raw |
0x0005 |
HDLC |
0x0006 |
ATM N-to-one VCC cell mode1 |
0x0009 |
ATM N-to-one VPC cell mode1 |
0x000A |
ATM transparent cell transport mode |
0x0003 |
SAToP E1 |
0x0011 |
SAToP T1 |
0x0012 |
CESoPSN basic mode |
0x0015 |
CESoPSN TDM with CAS |
0x0017 |
FR DLCI |
0x0019 |
Note:
‟N-to-one” is expressed as ‟N-to-1” throughout this guide.
Service Policies
Common to all 7705 SAR connectivity services are policies that are assigned to the service. Policies are defined at the global level, then applied to a service on the router. Policies are used to define 7705 SAR service enhancements.
The types of policies that are common to all 7705 SAR connectivity services are SAP Quality of Service (QoS) policies and accounting policies. Filter policies are supported on network interfaces, Epipe and Ipipe SAPs, VPLS SAPs and SDPs (mesh and spoke), VPRN SAPs and spoke SDPs, IES SAPs and spoke SDPs, and IES in-band management SAPs.
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 policy applied to a SAP specifies the number of queues, queue characteristics (such as forwarding class, committed information rates, and peak information rates) and the mapping of traffic to a forwarding class. A QoS policy must be created before it can be applied to a SAP. A single ingress and a single egress QoS policy can be associated with a SAP.
QoS ingress and egress policies also apply to SAP aggregation groups.
Accounting policies define how to count the traffic usage for a service for billing purposes.
The 7705 SAR 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.
Filter policies, also referred to as access control lists (ACLs), allow selective blocking or forwarding of traffic that matches criteria that is set in the policy. The resulting action (block or forward) is applied to that traffic.
Filter policies control the traffic allowed into a SAP or SDP, and are based on IP or MAC match criteria. The ability to configure and apply a filter depends on the combination of service, traffic type and direction, and entity type (SAP or SDP). Assigning a filter policy to a SAP or SDP is optional. Filter policies are identified by a unique filter policy ID. A filter policy must be created before it can be applied. A single ingress and a single egress filter policy can be assigned to a SAP (if supported), and a single ingress filter policy can be assigned to an SDP (if supported).
For more information about provisioning QoS policies, including queuing behaviors, see the 7705 SAR Quality of Service Guide. For information about configuring IP and MAC filter policies, see the 7705 SAR Router Configuration Guide.
Nokia Service Model
The 7705 SAR routers are deployed at the provider edge (PE). Services are provisioned on the 7705 SAR and other network equipment in order to facilitate the transport of telecommunications data across an IP/MPLS provider’s core network. The data is formatted so that it can be transported in encapsulation tunnels created using generic routing encapsulation (GRE), IP encapsulation, or MPLS label switched paths (LSPs).
The service model has four main logical components, referred to as (logical) service entities. The entities are: customers, service types, service access points (SAPs), and service destination points (SDPs) (see Service Entities). In accordance with the service model, the operator uses the (logical) service entities to construct an end-to-end service. The service entities are designed to provide a uniform, service-centric model for service provisioning. This service-centric design implies the following characteristics.
Many services can be bound to a single customer.
Many services can be bound to a single tunnel.
Tunnel configurations are independent of the services they carry.
Changes are made to a single service entity rather than to multiple ports on multiple devices. It is easier to change one tunnel rather than several services.
The operational integrity of a service entity (such as a service tunnel or service endpoint) can be verified by one operation rather than through the verification of dozens of parameters, thereby simplifying management operations, network scalability, and performance.
A failure in the network core can be correlated to specific subscribers and services.
The following policies are applied to various services:
QoS policies
accounting policies
filter policies (IP and MAC)
Additional properties can be configured for bandwidth assignments, class of service, and accounting and billing on the appropriate entity.
Service Entities
The basic (logical) service entities in the service model used to construct an end-to-end service are:
Service Entities and the Service Model shows an example of how the service entities relate to the service model. A subscriber (or customer) attachment circuit connects to a SAP. SDPs define the entrance and exit points of unidirectional service tunnels, which carry one-way traffic between the two routers (ALU-A and ALU-B). After SDPs have been configured, they are bound to a service, which is the final step in making the end-to-end service connection. In Service Entities and the Service Model, the entrance point is labeled SDP and the exit point is labeled Exit.
Traffic encapsulation occurs at the SAP and SDP. The SAP encapsulation types are SONET/SDH, Ethernet, and TDM. The SDP encapsulation types are MPLS, GRE, and IP. For information about SAP encapsulation types, see SAP Encapsulation Types and Identifiers. For information about SDP encapsulation types, see SDP Encapsulation Types.
Customers
The terms customers and subscribers are used synonymously. Every customer account must have a customer ID, 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.
Service Types
Service types provide the traffic adaptation needed by customer attachment circuits (ACs). This (logical) service entity adapts customer traffic to service tunnel requirements. The 7705 SAR provides six types of VLL service (that is, point-to-point MPLS-based emulation service, also called Virtual Private Wire Service (VPWS)):
ATM VLL (Apipe)
circuit emulation VLL (Cpipe)
Ethernet VLL (Epipe)
Frame relay VLL (Fpipe)
HDLC VLL (Hpipe)
IP interworking VLL (Ipipe)
The 7705 SAR also provides Ethernet layer (MAC-based) VPLS service (including management VPLS), as well as IP layer VPRN and IES services, that offer any-to-any connectivity within a Virtual Routing Domain or Generic Routing Domain, respectively.
Service Names
A service ID number must be associated with a service at the time of service creation. After the service is created, an optional service name can be assigned to the service for use by commands that reference the service.
Service Access Points (SAPs)
A service access point (SAP) is the point at which a service begins (ingress) or ends (egress) and represents the access point associated with a service. A SAP may be a physical port or a logical entity within a physical port. For example, a SAP may be a channel group within a DS1 or E1 frame, an ATM endpoint, an Ethernet port, or a VLAN that is identified by an Ethernet port and a VLAN tag. Each subscriber service connection on the 7705 SAR is configured to use only one SAP.
A SAP identifies the customer interface point for a service on a 7705 SAR router. Service Access Point (SAP) shows one customer connected to two services via two SAPs. The SAP identifiers are 1/1/5 and 1/1/6, which represent the physical ports associated with these SAPs. The physical port information should be configured prior to provisioning a service. See the 7705 SAR Interface Configuration Guide for more information about configuring a port. See Port and SAP CLI Identifiers for more information about identifiers.
The 7705 SAR supports the following services types: ATM pseudowires (Apipe), TDM pseudowires (Cpipe), IP pseudowires (Ipipe), Ethernet pseudowires (Epipe), FR pseudowires (Fpipe), HDLC pseudowires (Hpipe), IES, VPLS, and VPRN services. Customer access to these services is provided via SAPs. For each service type, the SAP has slightly different parameters.
In general, SAPs are logical endpoints that are local to the 7705 SAR and are uniquely identified by:
the physical Ethernet port, SONET/SDH port, or TDM channel group
the encapsulation type for the service (for example, ATM)
the encapsulation identifier (ID), which is, for example, the optional VLAN ID for Epipes, or the channel group ID for Cpipes
Depending on the encapsulation, a physical port or channel can have more than one SAP associated with it (for example, a port may have several circuit groups, where each group has an associated SAP). SAPs can only be created on ports or channels designated as ‟access” in the physical port configuration.
SAPs cannot be created on ports designated as core-facing ‟network” ports because these ports have a different set of features enabled in software.
SAP Encapsulation Types and Identifiers
The SAP encapsulation type is an access property of the Ethernet port, SONET/SDH port, or TDM channel group used for the service. It identifies the protocol that is used to provide the service.
The 7705 SAR supports three SAP encapsulation types:
Encapsulation types may have more than one option to choose from. For example, the options for TDM encapsulation type include ‟cem” (for circuit emulation service) and ‟atm” (for ATM service), among others.
For SAPs configured on the 16-port T1/E1 ASAP Adapter card, 32-port T1/E1 ASAP Adapter card, or 4-port DS3/E3 Adapter card, the cards must be configured to support the appropriate encapsulation methods before the encapsulation type can be configured. This is done using the mda-mode command. See the 7705 SAR Interface Configuration Guide for more information.
The encapsulation ID is an optional suffix that is appended to a port-id to specify a logical sub-element for a SAP. For example, port-id:qtag1 represents a port that can be tagged to use IEEE 802.1Q encapsulation (referred to as dot1q), where each individual tag can identify with an individual service. Similarly, port-id.channel-group:vpi/vci represents the encapsulation ID for an ATM SAP, which is a special case because it requires that a channel group identifier (which always uses the value 1) precede the VPI/VCI value.
Throughout this guide, the term ‟channel group” is often simplified to ‟channel”.
Do not confuse the term ‟encapsulation ID” (described here) with the term ‟Encapsulation ID”, which is used with the SNMP and MIBs for the 7705 SAR.
Ethernet Encapsulations
The following encapsulation service options are available 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.
dot1q—supports multiple services for one customer or services for multiple customers (see Multiple SAPs on a Single Port/Channel). An example of dot1q use may be the case where the Ethernet port is connected to a multi-tenant unit device with multiple downstream customers. The encapsulation ID used to distinguish an individual service is the VLAN ID in the IEEE 802.1Q header.
qinq— supports multiple services for one customer or services for multiple customers. The encapsulation IDs used to distinguish an individual service are the QinQ VLAN IDs in the IEEE 802.1ad header, producing a double-tagged frame. For more information about QinQ, see QinQ Support.
Default SAP on a Dot1q and QinQ Port
The 7705 SAR supports default SAP functionality on dot1q- and qinq-encapsulated ports. On dot1q- and qinq-encapsulated ports where a default SAP is configured, all packets with Q-tags not matching any other explicitly defined SAPs are assigned to the default SAP for transport.
A default SAP is identified in the CLI by the use of the character ‟*” as a Q-tag, where the ‟*” means ‟all”. For example, port-id:vlan-x.* and port-id:*.* are default SAPs. The former case (vlan-x.*) is a specific example of the latter case (*.*), where the outer tag (vlan-x) matches an existing SAP VLAN ID. See Special QinQ SAP Identifiers for more information.
One of the applications where the default SAP feature can be used is for 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 (the use of a whole port) can be provided by a null-encapsulated port. A dedicated VLAN (not used by the user) can be used to provide CPE management.
In this type of environment, two SAPs logically 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 functions as a SAP on a null-encapsulated port.
There are a few constraints related to the use of a default SAP on a dot1q- or a qinq-encapsulated port:
-
The default SAP is supported only on VPLS and Epipe services and cannot be created in IES and VPRN services because IES and VPRN services cannot preserve VLAN tag markings.
-
For VPLS SAPs with STP enabled, STP listens to untagged and null-tagged BPDUs only. All other tagged BPDUs are forwarded like other customer packets. This is the same behavior as null-encapsulated ports.
-
IGMP snooping is not supported on a default SAP. By not allowing IGMP snooping of a default SAP, all IGMP packets will be transparently forwarded.
-
The default SAP and the SAP defined by explicit null encapsulation are mutually exclusive (for example, 1/1/1:* and 1/1/1:0 are mutually exclusive, and 1/1/2:1.* and 1/1/2:1.0 are mutually exclusive). This avoids conflict as to which SAP untagged frames should be associated with.
SONET/SDH Encapsulations
The following service encapsulation option is available on SONET/SDH ports:
atm—supports multiple service instances for one customer, as well as bridged llc-snap encapsulated ATM SAP termination to VPLS
TDM and Serial (TDM) Encapsulations
The following service encapsulation options are available on TDM and SDI ports:
atm—supports multiple services for one customer (TDM ports only)
cem—supports multiple services for one customer. Structured CEM service (circuit emulation service over packet switched network (CESoPSN (n ✕ DS0)) and unstructured CEM service (structure-agnostic TDM over packet (SAToP)) are supported. (TDM and SDI ports)
ipcp—supports a single IP service per TDM channel group on channelized DS1/E1 interfaces or on unstructured (unframed) E1 interfaces. Unframed E1 can be used for Ipipe support. Channelized interfaces are typically used for router interconnection using the point-to-point protocol (PPP). (TDM ports, and SDI V.35 and X.21 ports at super-rate speeds)
frame-relay (TDM ports, and SDI V.35 and X.21 ports at super-rate speeds)
cisco-hdlc (TDM on DS1/E1 ports, and SDI V.35 and X.21 ports at super-rate speeds)
hdlc (TDM on DS1/E1 ports, and SDI V.35 and X.21 ports at super-rate speeds)
Service Types and SAP Encapsulations—Summary
Service Types and SAP Encapsulations lists the SAP encapsulations available to 7705 SAR service types. These encapsulations apply to access-facing ports. The service (port) type and encapsulations are configured at the port level. See the 7705 SAR Interface Configuration Guide for more information about the cards and ports that support each of the service types.
Service (Port) Type |
Encapsulation Option |
|---|---|
Ethernet |
null |
Ethernet |
dot1q |
Ethernet |
qinq |
SONET/SDH |
atm |
TDM |
cem |
TDM |
atm |
TDM |
ipcp |
TDM |
frame-relay |
TDM |
cisco-hdlc |
TDM |
hdlc |
SAP Configuration Considerations
In addition to being an entry or exit point for service traffic, a SAP has to be configured for a service and, therefore, has properties. When configuring a SAP, consider the following.
A SAP is a local entity and is only locally unique to a specific device. The same SAP ID value can be used on another 7705 SAR.
There are no default SAPs. All subscriber service SAPs must be created.
The default administrative state for a SAP at creation time is administratively enabled.
When a SAP is deleted, all configuration parameters for the SAP are also deleted.
A SAP is owned by and associated with the service in which it is created.
An Ethernet port or channel with a dot1q encapsulation type means that the traffic for the SAP is identified based on a specific IEEE 802.1Q VLAN ID value. The VLAN ID is stripped off at SAP ingress and the appropriate VLAN ID is placed on at SAP egress. As a result, VLAN IDs only have local significance, so the VLAN IDs for the SAPs for a service need not be the same at each SAP. QinQ encapsulation means that the SAP is identified based on specific IEEE 802.1ad VLAN ID values.
A TDM circuit emulation service (for example, CESoPSN) requires a channel group. The channel group must be created before it can be assigned to a SAP.
An ATM service (for example, ATM N-to-1 VCC cell transport) on a 16-port T1/E1 ASAP Adapter card, 2-port OC3/STM1 Channelized Adapter card, or 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card requires a channel group. For this case, the channel group requires the assignment of all 24 timeslots (T1) or 30 timeslots (E1). The timeslot assignments are made automatically after a channel group is configured for ATM encapsulation.
If a port or channel is administratively shut down, all SAPs on that port or channel will be operationally out of service.
A SAP cannot be deleted until it has been administratively disabled (shut down).
Each SAP can have one of the following policies assigned to it:
Ingress QoS policy
Egress QoS policy
Accounting policy
Ingress filter policy (for Epipe SAPs, Ipipe SAPs, VPLS SAPs, VPRN SAPs, IES SAPs, and IES in-band management SAPs)
Egress filter policy (for VPRN and IES SAPs, and for VPLS SAPs (Ethernet SAPs only))
Service Destination Points (SDPs)
An SDP identifies the endpoint of a logical unidirectional service tunnel. The service tunnel provides a path from one 7705 SAR to another network device, such as another 7705 SAR or a 7750 SR.
In more general terms, SDP refers to the service tunnel itself. The SDP terminates at the far-end router, which is responsible for directing the flow of packets to the correct service egress SAPs on that device.
-
Service Destination Point
-
Service Distribution Point
-
Service Destination Path
-
Service Distribution Path
-
Service Delivery Path
When an SDP is bound to a service, the service is referred to as a distributed service. 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 binding that binds the service to the service tunnel.
An SDP has the following characteristics.
An SDP is locally unique to a participating 7705 SAR. The same SDP ID can appear on other 7705 SAR routers.
An SDP uses the system IP address of the far-end edge router to locate its destination.
An SDP is not specific to any one service or to any type of service. After 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 bound to an SDP use the same SDP (transport) encapsulation type defined for the SDP (GRE, IP, or MPLS).
An SDP is a service entity used for service management. Even though the SDP configuration and the services carried within it 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 tunnel from the local device (typically, a 7705 SAR) to the far-end device (router) requires a return SDP tunnel from the far end back to the local device. Each device must have an SDP defined for every remote router to which it wants to provide service. The SDP must be created before a distributed service can be configured.
An SDP can be used to provide PW redundancy, where up to four spoke SDPs can be assigned to a service endpoint that acts as the managing entity to ensure service connection. See Pseudowire Redundancy.
SDP Binding
To configure a distributed service pointing from ALU-A to ALU-B, the SDP ID on the ALU-A side (see SDP Tunnel Pointing from ALU-A to ALU-B) must be specified during service creation in order to bind the service to the tunnel (the SDP). Otherwise, service traffic is not directed to a far-end point and the far-end 7705 SAR devices cannot participate in the service (there is no service). To configure a distributed service pointing from ALU-B to ALU-A, the SDP ID on the ALU-B side must be specified.
Spoke and Mesh SDPs
There are two types of SDPs: spoke and mesh. The type of SDP defines how flooded traffic (or broadcast traffic, such as an ARP request) is propagated. For point-to-point PW/VLL services, spoke SDPs are the only way to bind services to the far-end router. For VPLS, mesh and spoke SDP bindings are allowed.
A spoke SDP that is bound to a service operates like a traditional bridge port. Flooded traffic that is received on the spoke SDP is transmitted to all the spoke SDPs, mesh SDPs, and SAPs to which it is connected. Flooded traffic is not transmitted back toward the port from which it was received.
In contrast, a mesh SDP that is bound to a service operates like a single bridge port. Flooded traffic received on a mesh SDP is transmitted to all spoke SDPs and SAPs to which it is connected. Flooded traffic is not transmitted to any other mesh SDPs or back toward the port from which it was received. This property of mesh SDPs is important for multi-node networks; mesh SDPs are used to prevent the creation of routing loops.
SDPs and BGP Route Tunnels
SDP can use BGP route tunnels to extend inter-AS support for Layer 2 and Layer 3 VPN services as defined in RFC 3107. An SDP can be configured based on service transport method (for example, GRE or MPLS tunnel). 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 LSP, RSVP-TE LSP or BGP route tunnel). This restriction is relaxed for some combinations of the transport methods when the mixed-LSP mode option is enabled on the SDP. See Mixed-LSP SDPs for more information.
For an 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/RSVP 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 configured to select an LSP to reach the PE node from the ASBR.
For more information about BGP route tunnels, see the 7705 SAR Routing Protocols Guide, ‟BGP Route Tunnels”.
SDP Encapsulation Types
The Nokia service model uses encapsulation tunnels (also referred to as service tunnels) through the core to interconnect 7705 SAR and SR routers. An SDP is a logical way of referencing the entrance to an encapsulation tunnel.
The following encapsulation types are supported:
Layer 2 within multiprotocol label switching (MPLS Encapsulation)
Layer 2 or Layer 3 within generic routing encapsulation (GRE Encapsulation)
Layer 2 within IP (IP Encapsulation)
Each SDP service tunnel has an entrance and an exit point for the pseudowires contained within it.
MPLS Encapsulation
Multiprotocol label switching (MPLS) encapsulation has the following characteristics.
-
An MPLS 7705 SAR router supports both signaled and non-signaled LSPs through the network.
-
Non-signaled paths are defined at each hop through the network.
An SDP has an implicit Maximum Transmission Unit (MTU) value because services are carried in encapsulation tunnels and an SDP is an entrance to the tunnel. The MTU is configurable (in octets), where the transmitted frame can be no larger than the MTU.
With MPLS, the MTU for the network port allows the addition of labels for transmission across the MPLS network. Ethernet frames that are sent out of a network port toward the MPLS core network (or a P router) are allowed to be oversized in order to include the MPLS labels without the need to fragment large frames. See MTU Settings for more information.
The following ways of configuring an MPLS tunnel are supported:
-
LDP signaled
-
RSVP-TE signaled
-
user-configured (static LSP)
GRE Encapsulation
Generic routing encapsulation (GRE) is one of the most common tunneling techniques in the industry. GRE tunnels are used to transport various network layer packets and are especially useful for facilitating pseudowires over IP networks. Since MPLS is a Layer 2.5 protocol, MPLS packets cannot be natively transported over a Layer 3 (IP) network. Therefore, GRE is the ideal alternative for applications where traffic must travel over a Layer 3 network; for example, in DSL applications.
For the HSDPA offload application (see HSDPA Offload), ATM pseudowires are transported over IP using GRE tunneling. For other applications, Ethernet and TDM pseudowires over GRE are also supported.
GRE SDPs are supported on all network interfaces.
GRE Format
In accordance with RFC 2784, a GRE encapsulated packet has the following format:
-
delivery header
-
GRE header
-
payload packet
Delivery Header
The delivery header is always an IP header.
GRE Header
The GRE header format is shown in GRE Header and described in GRE Header Descriptions.
|
Field |
Description |
|---|---|
|
C |
Specifies whether there is a checksum in the header If set to 1, both the checksum and reserved1 fields must be present On the 7705 SAR, in the network egress (transmit) direction, the C bit is always set to 0; therefore, the checksum and reserved1 fields are omitted from the header. The GRE header is therefore always 4 bytes (32 bits) in the network egress direction. In the network ingress direction, the C bit validity is checked. If it is set to a non-zero value, the GRE packet is discarded and the IP discards counter is increased. |
|
Reserved0 |
Indicates whether the header contains optional fields Not applicable to the 7705 SAR—first 5 bits of the field are always set to 0 and bits 6 to 12 are reserved for future use and also set to 0 by the 7705 SAR |
|
Ver |
Always set to 000 for GRE At network ingress, if a GRE packet is received with the version field set to any value other than 000, the packet is discarded and the IP discards counter is increased |
|
Protocol Type |
Specifies the protocol type of the original payload packet—identical to Ethertype with the only supported option being MPLS unicast (0x8847) |
|
Checksum (optional) |
Not applicable |
|
Reserved1 (optional) |
Not applicable |
Payload Packet
The payload encapsulation format for pseudowires over GRE is shown in GRE Pseudowire Payload Packet over Ethernet and described in GRE Pseudowire Payload Packet Descriptions.
|
Field |
Description |
|---|---|
|
Eth |
The Layer 2 transport header The only Layer 2 protocol supported is Ethernet MTU size depends on the encapsulation type (14 bytes for null encapsulation, 18 bytes for dot1q encapsulation, and 22 bytes for qinq encapsulation) |
|
IP |
Indicates the transport protocol The Ethertype is always set to IP (0x800), and in case of a mismatch, the unexpected or illegal Ethertype counters are increased 1 |
|
GRE |
Indicates the encapsulation protocol |
|
PW header |
The pseudowire header identifies a service within the GRE tunnel |
|
CW (optional) |
The pseudowire control word (CW) is a 32-bit (4-byte) field that is inserted between the VC label and the Layer 2 frame For more information about the control word, see Pseudowire Control Word |
|
PW payload |
The PW payload is the payload of the service being encapsulated (Ethernet, ATM, or TDM) |
Note:
-
The only exception to the Ethertype is if the packets are address resolution protocol (ARP) packets. For information about ARP, see the 7705 SAR Router Configuration Guide.
At the network egress of the 7705 SAR, the source address of the IP header is always set to the system IP address. The destination IP address is set to the system IP address of the service router on which the GRE SDP is configured, the far-end interface address, or the loopback address. Using the system IP addresses to bring up the GRE session ensures that any IP link between the two routers can be used to transport GRE/IP packets. It may therefore be necessary to use static IP address configuration over DSL networks to ensure connectivity between the routers (especially if the DSL modem is in bridge mode).
GRE Fragmentation
IP fragmentation can be enabled for GRE tunnels. Services for which fragmentation is typically not available can make use of IP fragmentation performed at the IP layer of the GRE tunnel. The IP fragmentation feature can be enabled at the GRE tunnel ingress by enabling the allow-fragmentation command on the SDP. The IP fragmentation size limits are derived from the MTU of the network port used by the GRE tunnel.
At the GRE tunnel egress, IP reassembly can be performed as specified by a reassembly profile assigned to the network interfaces on which the GRE packets are expected to arrive. The IP reassembly function is performed on the IP fragments received at the GRE tunnel egress before any underlying service label is processed. A reassembly profile is used to specify the amount of buffer space allocated for the IP reassembly function and to configure a reassembly timeout. These parameters are configured for each forwarding class to isolate different types of GRE traffic.
When allow-fragmentation is enabled on an SDP, the current MTU algorithm is overwritten with the configured path MTU. The administrative MTU and operational MTU both show the specified MTU value. If the path MTU is not configured or available, the operational MTU is set to 2000 bytes, and the administrative MTU displays a value of 0. When allow-fragmentation is disabled, the operational MTU reverts to the previous value.
Fragmentation is supported on the following types of GRE SDPs:
VPLS
Layer 3 spoke SDP
Epipe
The GRE SDPs can be NGE-encrypted; however, the NGE interface must be Ethernet. Fragmentation is not supported on NGE PPP/MLPPP interfaces. See GRE Fragmentation for NGE Packets for more information.
IP packets that are transported over a Layer 3 spoke SDP using a fragmentation-enabled GRE tunnel are handled differently depending on the DF bit setting and the size of the packet.
If the packet DF bit setting is 0 (Fragment), the GRE fragment size is determined by the network port MTU value.
If the packet DF bit setting is 1 (Do not fragment), and the packet size is smaller or equal to the smaller value of either the operational MTU of the spoke SDP or the Layer 3 spoke SDP interface MTU (if configured), the packet is sent through the GRE tunnel.
If the packet DF bit setting is 1 (Do not fragment), and the packet size is larger than the smaller value of either the operational MTU of the spoke SDP or the Layer 3 spoke SDP interface MTU (if configured), the packet is discarded and an ICMP message ‟Fragmentation Needed and Don’t Fragment was Set” is sent back to the source IP address.
IP reassembly profiles are required to ensure that all packet fragments are received within an expected time frame for each forwarding class. When the reassembly profile timers expire, all fragments of the corresponding incomplete frame are dropped and a ‟Fragment Reassembly Time Exceeded” ICMP error message is sent to the source node.
Traffic ingressing a GRE tunnel can use different forwarding classes and different queues. If multiple queues are transmitting fragments, a higher-priority queue could interrupt the transmission of fragments of a frame in a lower-priority queue by interleaving fragments of another frame. If the fragments from the different frames have similar IP identifiers, they could be reassembled incorrectly into one frame at the tunnel egress. To prevent this incorrect reassembly of frames, the 7705 SAR that is performing the IP fragmentation uses 4 bits of the 16-bit IP identifier to indicate the transmitting queue at the tunnel ingress. The IP identifier is part of the IP reassembly tuple, which also contains the protocol, source address, and destination address. Using the IP reassembly tuple, fragments of frames from different queues are always differentiated. However, reserving 4 bits in the IP identifier field leaves only 12 bits to act as a sequence number, which causes a shorter identifier wraparound. The time required for the IP identifier to wrap around is a function of the traffic rate on a specific queue at the GRE tunnel ingress.
If fragments are dropped along the GRE tunnel due to congestion or bit errors, the 7705 SAR that is performing the IP reassembly at the tunnel egress normally drops partially reassembled packets due to expiration of the reassembly timeout interval. If fragment loss occurs in the network along with an IP identifier wraparound due to a high packet rate, the IP reassembly block may incorrectly insert fragments of a new frame into a frame of older fragments that are waiting for timeout. When configuring the timeout interval, it is therefore important to factor in the pre-fragmentation frame rate for forwarding classes on a GRE tunnel. As a guideline, higher-priority packets should have shorter timeout intervals than other packets because their queue interruption at the ingress GRE tunnel is minimal, and the timeout intervals should be shorter than the transmission time of 4096 packets for that forwarding class.
The 7705 SAR does not support double fragmentation.
IP Encapsulation
IP encapsulation is added to the 7705 SAR in response to a growing demand for more pseudowire-based solutions in mobile backhaul. IP encapsulation is similar to GRE encapsulation but allows pseudowires to be transported natively over IP packets. Only static pseudowires are supported for IP SDPs because there is no label path to define except for the endpoints. The path is an IP routed path.
The 7705 SAR supports the transport of pseudowires over IP tunnels. IP Example of Pseudowire Payload Packet over Ethernet shows an example of an application using Apipes over IP over Ethernet.
Payload Packet
A typical payload encapsulation format for pseudowires over IP is shown in IP Example of Pseudowire Payload Packet over Ethernet and described in IP Pseudowire Payload Packet Descriptions.
Field |
Description |
|---|---|
Eth |
The Layer 2 transport header The only Layer 2 protocol supported is Ethernet MTU size depends on the encapsulation type (14 bytes for null encapsulation, 18 bytes for dot1q encapsulation, and 22 bytes for qinq encapsulation) |
IP |
Indicates the transport protocol The only supported option is MPLS in IP (0x89) The Ethertype is always set to IP (0x0800), and in case of a mismatch, the unexpected or illegal Ethertype counters are increased1 |
PW header |
The pseudowire header identifies a service within the IP tunnel. The pseudowire header is like an MPLS header that has context only to the encapsulating and decapsulating LERs. This means that the IP transport network has no knowledge about the pseudowires that it carries. Only the edge LERs are aware of the pseudowire because the IPv4 Protocol Number field is set to 137 (0x89), indicating an MPLS unicast packet. |
CW (optional) |
The pseudowire control word (CW) is a 32-bit (4-byte) field that is inserted between the VC label and the Layer 2 frame For more information about control word, see Pseudowire Control Word |
ATM Cell #1 to ATM Cell #N |
Indicates the payload of the service being encapsulated (ATM) |
Note:
The only exception to the Ethertype is if the packets are address resolution protocol (ARP) packets. For information about ARP, see the 7705 SAR Router Configuration Guide.
Spoke SDP Terminations
The 7705 SAR supports spoke SDP as termination points for IES and VPRN services. Spoke SDP Termination Support shows which service interfaces and spoke SDPs can be connected to each other. For example, an Epipe spoke SDP can connect to an IES or VPRN interface. See Spoke SDP Termination to IES and Spoke SDP Termination to VPRN for more information.
Epipe Spoke SDP |
Epipe Spoke SDP Redundancy (standby-signal-master enabled) |
IES Interface |
VPRN Interface |
VPLS Spoke SDP |
VPLS Spoke SDP Redundancy (suppress-standby- signaling disabled) |
|
|---|---|---|---|---|---|---|
Epipe Spoke SDP |
✓ |
✓ |
✓ |
✓ |
✓ |
✓ |
Epipe Spoke SDP Redundancy (standby-signal-master enabled) |
✓ |
✓ |
✓ |
✓ |
✓ |
✓ |
IES Interface |
✓ |
✓ |
✓ |
✓ |
✓ |
✓ |
VPRN Interface |
✓ |
✓ |
✓ |
✓ |
✓ |
✓ |
VPLS Spoke SDP |
✓ |
✓ |
✓ |
✓ |
✓ |
✓ |
VPLS Spoke SDP Redundancy (suppress-standby- signaling disabled) |
✓ |
✓ |
✓ |
✓ |
✓ |
✓ |
SDP Ping
Ping is an application that allows a user to test whether a particular host is reachable. SDP Ping is an application that allows a user to test whether a particular SDP endpoint is reachable.
SDP ping uses the SDP identifier that is stored in the 7705 SAR that originates the ping request. SDP ping responses can be configured to return through the corresponding return tunnel as a round-trip ping, or out-of band when unidirectional pings are requested. See the 7705 SAR OAM and Diagnostics Guide, ‟SDP Ping”, for more information.
SDP Keepalives
The SDP keepalive application allows a system operator to actively monitor the SDP operational state using periodic Nokia SDP Echo Request and Echo Reply messages. Automatic SDP keepalives work in a manner that is similar to a manual SDP ping command. The SDP Echo Request and Echo Reply messages provide a mechanism for exchanging far-end SDP statuses.
SDP keepalive Echo Request messages are only sent after the SDP has been completely configured and is administratively up and the 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.
The SDP is immediately brought operationally down when:
the Max Drop Count Echo Request messages do not receive an Echo Reply
a keepalive response is received that indicates an error condition
After a response is received that indicates the error has cleared and the Hold Down Time interval has expired, the SDP is eligible to be put into the operationally up state. If no other condition prevents the operational change, the SDP enters the operational state.
Configuring SDP keepalives on a specific SDP is optional. SDP keepalives have the following configurable keepalive parameters:
Hello Time
Message Length
Max Drop Count
Hold Down Time
Timeout
For information about configuring keepalive parameters, see Configuring SDPs.
Mixed-LSP SDPs
If mixed-LSP SDP mode is enabled on an SDP, a maximum of two LSP types can be configured on the SDP: a primary LSP and a secondary (backup) LSP. Two combinations are possible:
an RSVP-TE primary LSP backed up by an LDP LSP
an LDP primary LSP backed up by a BGP LSP
The config>service>sdp mpls>mixed-lsp-mode command is used to configure a mixed-LSP SDP.
Mixed-LSP Mode of Operation
The service manager programs only one type of LSP in the line card, which activates it to forward service packets. The LSPs are programmed in the following priority order:
RSVP-TE LSP type
This is the highest-priority LSP type. Up to eight RSVP-TE LSPs can be entered by the user and programmed by the service manager in the ingress line card to load-balance service packets.
LDP LSP type
One LDP FEC is programmed by the service manager, but the ingress line card can use up to eight LDP ECMP paths for the FEC to load-balance service packets when ECMP is enabled on the node.
BGP LSP type
One RFC 3107-labeled BGP prefix is programmed by the service manager. The ingress line card can use more than one next hop for the prefix.
For an RSVP-TE/LDP SDP, the service manager programs the NHLFEs for the active LSP type, preferring the RSVP-TE LSP type over the LDP LSP type. If no RSVP-TE LSP is configured, or if all of the configured RSVP-TE LSPs go down, the service manager reprograms the line card with the LDP LSP, if available. If no LDP LSP is available, the SDP goes operationally down.
For LDP/BGP SDPs, the service manager prefers the LDP LSP type over the BGP LSP type. If no LDP LSP is configured or all configured LDP LSPs go down, the service manager reprograms the line card with the BGP LSP if it is available; otherwise, the SDP goes operationally down.
An LDP/BGP SDP differs from an RSVP/LDP SDP in the number of routes available. For any given /32 prefix, only a single route exists in the routing table: the IGP route or the BGP route. Therefore, only the LDP FEC or the BGP label route is active at any given time. The impact of this is that the tunnel table must be reprogrammed each time a route is deactivated and the other route is activated. In this scenario, the SDP revert-time command cannot be used because there is no situation where both LSP types are active for the same /32 prefix.
When a higher-priority LSP type becomes available, the service manager resets the SDP configuration to this LSP type when the revert timer expires or when the current active LSP fails, whichever occurs first. The length of time that the service manager must wait can be configured with the config>service>sdp mpls>mixed-lsp-mode>revert-time command. After the SDP has reverted to the higher-priority LSP, the service manager reprograms the line card accordingly. If the revert timer is configured with the infinite parameter, the service manager never resets the SDP to the highest-priority LSP type unless the current active LSP fails.
If the value of the revert time timer is changed, it takes effect when the timer is next activated. Any timer that is currently active when the value is changed is restarted with the new value.
Multiple Load-balancing LSPs Under a Single SDP
Configuring multiple LSPs under a single SDP allows load distribution among multiple LSPs to the same destination. This load distribution is handled by the node without the need for any operator intervention. LSP additions or deletions result in automatic rehashing of services onto remaining LSPs, making it transparent to the operator. No new hashing algorithms are required; existing hashing algorithms are extended to select an LSP from multiple LSPs under an SDP.
Up to eight RSVP-TE or SR-TE LSPs can be configured under a single SDP. However, a mix of RSVP-TE and SR-TE LSPs is not supported. When the first LSP is configured under the SDP, all other LSPs configured under that SDP must be of the same type.
Multiple LSPs are only supported for SDPs configured for MPLS encapsulation.
High-Speed Download Packet Access Offload
The Mobile Radio Access Network (RAN) is rapidly growing to meet the increased demand in mobile services. This in turn increases demands on carriers to provide high-bandwidth, mobile broadband services. Today, at a typical cell site, 2G and 3G base stations are connected to high-cost, T1/E1 leased lines that are used to backhaul both voice and data traffic to the MTSO. For mission-critical, delay-sensitive, and low-bandwidth traffic such as voice, signaling, and synchronization traffic, it is vital that the high availability of these leased lines is ensured. SLA agreements also promise a high level of availability for customers.
Currently, however, best-effort traffic such as high-speed downlink packet access (HSDPA) is also switched over these SLA-enabled leased lines. HSDPA is a 3G mobile telephony communications service that allows UMTS networks to have higher data transfer speeds and capacity, allowing the mobile customer (end user) to browse the Internet or to use the mobile device. The increasing use of HSDPA is having a dramatic impact on the ability of the T1/E1 leased lines to scale with the traffic growth as well as on the operating costs of these lines.
Similar issues confront CDMA EVDO networks today.
Nokia provides a solution that enables mobile operators to keep their existing infrastructure (circuit-based leased lines), while gradually migrating to a packet-based infrastructure that will allow scalability, decrease costs, and ease the transition to the next-generation, all-IP network solutions.
HSDPA Offload
The Nokia solution is to make use of widely available DSL networks and split the traffic being backhauled. Mission-critical traffic (voice, signaling, synchronization) remains on the T1/E1 leased line circuits, while the best-effort, bandwidth-hungry HSDPA traffic is off-loaded to DSL networks.
The 7705 SAR-A is an ideal candidate for this scenario. The 7705 SAR-A is a small-scale version of the 7705 SAR product family, optimized for use in standalone small or midsized sites where traffic aggregation from multiple cell sites is not needed. For more information about the 7705 SAR-A, see the 7705 SAR-A Chassis Installation Guide.
7705 SAR-A HSDPA Offload Example shows an example of HSDPA offload with the 7705 SAR-A.
A 3G Node B is connected to a 7705 SAR-A over an ATM/IMA access port (SAP endpoint). An ATM SAP-to-SAP connection is set up in the 7705 SAR-A and a pseudowire is configured between the two endpoints to emulate local ATM switching. Traffic from the Node B enters an ATM/IMA port, the VCs transporting mission-critical traffic are locally switched (SAP-to-SAP) to another ATM/IMA port (SAP endpoint), and then switched over the leased lines to the MTSO.
For non-mission-critical traffic, for example, HSDPA traffic, an Ethernet interface on the 7705 SAR is connected to an external DSL modem. HSDPA traffic is interworked to ATM pseudowires and transported over the DSL network to the BRAS, then forwarded to the service router at the MTSO.
Failure Detection
Failure of the GRE SDP or the IP network it rides over can be detected by OAM tools as well as by BFD. With SAA, OAM tools can be configured to run periodically in order to facilitate faster failure detection. If a failure occurs, the ATM SAPs must be rerouted by the NSP NFM-P to the ATM ports used for backhauling the traffic. The mission-critical traffic is still serviced before the best-effort HSDPA traffic.
For information about OAM and SAA tools, see the 7705 SAR OAM and Diagnostics Guide. For information about BFD, see the 7705 SAR Router Configuration Guide.
ETH-CFM (802.1ag and Y.1731)
Topics in this section include:
Ethernet Connectivity Fault Management (ETH-CFM) is defined in two complementary standards: IEEE 802.1ag (dot1ag) and ITU-T Y.1731. Both standards specify protocols, procedures, and managed objects in support of transport fault management, including discovery and verification of the path, and detection and isolation of a connectivity fault for each Ethernet service instance.
Dot1ag and Y.1731 provide fault management (FM) functions for loopback, linktrace, and connectivity checks, as well as Up and Down MEP support for Ethernet SAPs (Epipe and VPLS), Ethernet spoke SDPs, and VPLS spoke/mesh SDPs, and facility MEP support for network interfaces.
Y.1731 fault management (Y.1731 FM) extends dot1ag CFM by providing functions for alarm indication signal (AIS) and ETH-Test testing. Furthermore, Y.1731 provides performance monitoring (Y.1731 PM) functions for delay and loss measurements. For more information on Y.1731 PM, see the ‟ITU-T Y.1731 Performance Monitoring (PM)” section in the 7705 SAR OAM and Diagnostics Guide.
For information about running Ethernet OAM tests, see the ‟ETH-CFM (802.1ag and Y.1731)” section in the 7705 SAR OAM and Diagnostics Guide.
The information in this section is specific to Ethernet SAPs and spoke and mesh SDPs, although most of it also applies to Ethernet network interfaces. For information about ETH-CFM support specific to network interfaces, see the 7705 SAR Router Configuration Guide, ‟ETH-CFM Support”.
CFM uses Ethernet frames that are distinguished by their Ethertype value and special Ethernet multicast address. For more information about the Ethernet frame, and the Ethertype and Ethernet multicast address values, see ETH-CFM Frame Format.
Using CFM, interoperability can be achieved between different vendor equipment in the service provider network, up to and including customer premises bridges.
-
global (config>eth-cfm)
-
Epipe SAPs (config>service>epipe>sap>eth-cfm)
-
Epipe spoke SDPs (config>service>epipe>spoke-sdp>eth-cfm)
-
VPLS SAPs (config>service>vpls>sap>eth-cfm)
-
VPLS spoke SDPs (config>service>vpls>spoke-sdp>eth-cfm)
-
VPLS mesh SDPs (config>service>vpls>mesh-sdp>eth-cfm)
-
network interface (config>router>if>eth-cfm)
-
show (show>eth-cfm)
-
oam (oam>eth-cfm)
802.1ag and Y.1731 Terminology
802.1ag Terminology defines 802.1ag terms. Y.1731 Terminology illustrates the similarities and differences between Y.1731 and 802.1ag terms.
Term |
Expansion |
Definition |
|---|---|---|
MA |
Maintenance Association |
A grouping of maintenance entities (MEs) that need to be managed as part of a service |
MA-ID |
Maintenance Association Identifier |
A unique combination of MD index (md-index), MD level (level), and MA index (ma-index), where md-index, level, and ma-index are user-configured values An MA is identified by its MA-ID |
MD |
Maintenance Domain |
A set of Ethernet network elements or ports that are controlled by an operator, where boundaries are set by MEPs |
MD level |
Maintenance Domain level |
A user-configured value of 0 to 7 representing a level of hierarchy within a CFM architecture. The value 7 is the highest MD level and 0 is the lowest. The MD level is transmitted as part of the Ethernet CFM frame. A CFM message is said to have a higher MD level when its MD level value is higher than the MD value configured on the receiving MEP 7705 SAR. Higher-level CFM messages are relayed as data frames by MEPs and ignored by the MEP entity. |
ME |
Maintenance Entity |
An Ethernet port or endpoint that is managed as part of dot1ag OAM An endpoint can be a SAP, spoke SDP, or mesh SDP (VPLS only) |
MEP |
Maintenance Association End Point |
An (edge) endpoint that can terminate, respond to, or initiate the OAM messages for a configured MD-MA combination |
MEP-ID |
Maintenance Association End Point Identifier |
A MEP is identified by its MEP-ID, which is a unique combination of MD index (md-index) and MA index (ma-index), where md-index and ma-index are user-configured values |
MIP |
Maintenance Association Intermediate Point |
An intermediate point that can respond to OAM messages initiated by MEPs in the same MD. Connectivity fault management (CFM) messages destined for other MIPs or the destination MEP are transparent to MIPs. MIPs are not supported on the 7705 SAR |
Term |
Expansion |
Definition |
|---|---|---|
MEG |
Maintenance Entity Group |
Same as MA but applies to Y.1731 |
MEG-ID |
Maintenance Entity Group Identifier |
Same as MA-ID but applies to Y.1731 |
MEG level |
Maintenance Entity Group Level |
Same as MD level but applies to Y.1731 Although MEG level and MD level are equivalent terms, there is no Y.1731 equivalent to an MD |
MEP |
Maintenance Association End Point |
Same as MEP for 802.1ag |
MDs, MD Levels, MAs, and MEPs (802.1ag)
Maintenance domains (MDs) and maintenance associations (MAs) are configured at the global level. Maintenance association endpoints (MEPs) are configured at the service level.
An MD is a set of network elements that have a common CFM OAM purpose. MDs are identified by their MD index and can be given an MD name. An MD is assigned a maintenance domain level (MD level). There are eight MD levels. MD levels are used to set up a messaging hierarchy for the CFM architecture.
An MA consists of up to eight MEPs (one local and up to seven remote) for Up MEPs on Epipe and VPLS services and two MEPs (one local and one remote) for Down MEPs on Epipe and VPLS services. The MA and the service are associated by configuring the MA bridge identifier parameter to have the same value as the service ID of the service that supports the MEPs. MAs are identified by their MA index and can be given an MA name. The MA is used to verify the integrity of a single service instance.
A MEP is configured as part of an Ethernet SAP, spoke SDP, or mesh SDP (VPLS only). MEPs can generate or terminate CFM OAM messages. MEPs only communicate within the same MD level, where the value of the MD level (0 to 7) is carried in a CFM OAMPDU. MEPs are identified by their MEP identifier and MA-ID. The MA-ID is configured at the global level.
MEPs and MAs shows a high-level view of MEPs in a CFM-enabled network. Two MAs are shown. The endpoints of MA 1 are MEPs 1 and 2, while MEPs 3 and 4 are the endpoints for MA 2.
For more information about MEP support, see Ethernet OAM.
MEG Levels, MEGs, and MEPs (Y.1731)
On the 7705 SAR, the implementation of Y.1731 Fault Management (FM) is similar to that of dot1ag CFM, except that Y.1731 does not have a maintenance domain (MD). For Y.1731 and 802.1ag, the following terms are equivalent:
MEG level is equivalent to MD level
MEG is equivalent to MA
a Y.1731 MEP is equivalent to a dot1ag MEP
To access Y.1731 functions, including Y.1731 Performance Monitoring (PM) functions, configure a MEP to have the domain format set to none and the association format set to icc-based or string (the string keyword enables the Y.1731 MEP to interoperate with a dot1ag MEP).
ETH-CFM Frame Format
ETH-CFM OAMPDU messages for 802.1ag and Y.1731 use a standard Ethernet frame (see ETH-CFM Frame Format). The parts of the frame are described below.
Destination and Source Addresses
The destination and source MAC addresses of the CFM message must match at the send and the receive routers. For example, a 7705 SAR-initiated ETH-CFM message would use the spoke SDP MAC address of the 7705 SAR as the source MAC address and the spoke SDP MAC address of the far-end router as the destination MAC address. At the far end, the source and destination MAC addresses would be the reverse of the near end.
An exception to the matching source-destination MAC address requirement occurs for linktrace and continuity messages, where the destination MAC address is set to a multicast group address. The designated multicast group address for linktrace and CCM is 01-80-C2-00-00-3x; where x represents the maintenance domain (MD) level (for 802.1ag) or the MEG level (for Y.1731). For example, a dot1ag CCM message destined for 01-80-C2-00-00-31 corresponds to MD level 1.
CCM packets using source-destination multicast MAC addresses are for user-initiated messages only (loopbacks).
Ethertype (T)
If dot1q or qinq encapsulation is not configured, the Ethertype value is 0x8902 and there are no VLAN tags. If dot1q or qinq encapsulation is configured, the VLAN tag (Ethertype value 0x8100) is present and is followed by the Ethertype value of 0x8902, which indicates ETH-CFM messages. The Ethertype is not hard-coded to 0x8100 and can be changed via the port configuration command.
VLAN/dot1p
The Vlan/Dot1p tag is the VLAN/dot1p identifier. If null encapsulation is configured (for Ethernet SAPs or spoke or mesh SDP bindings to a VC-type, ether or vlan), the frame is tagged with NULL.
ETH-CFM OAMPDU
The contents of the Ethernet OAMPDU depend on whether dot1ag or Y.1731 standards are being used. For information about the dot1ag or Y.1731 OAMPDU, see ETH-CFM OAMPDU.
FCS
The FCS is the frame check sequence field.
ETH-CFM OAMPDU
As shown in ETH-CFM OAMPDU Message, each ETH-CFM OAMPDU message contains the following fields:
MD level or MEG level: user-configured value, 0 to 7
version: current version is 0
opcodes: as defined in IEEE 802.1ag and Y.1731 standards, for messages such as:
Continuity Check Message (CCM)
Loopback Message (LBM)
Loopback Reply (LBR)
Linktrace Message (LTM)
Linktrace Reply (LTR)
flags: as defined in IEEE 802.1ag and Y.1731 standards
one or more TLVs, which include:
End TLV
Data TLV
Reply Ingress TLV
Reply Egress TLV
LTM egress identifier TLV
LTR egress identifier TLV
Test TLV
CFM Frame Processing
CFM Frame Processing shows whether a CFM frame received by various MEP types is processed. Frames that are processed are extracted from the datapath for CFM processing; unprocessed frames are treated as user traffic and follow the user traffic rules.
MEP Details |
Received CFM Frame Treatment |
||||
|---|---|---|---|---|---|
MEP Type |
Direction |
VC-Type |
Port |
Untagged |
Tagged 1 |
Spoke SDP |
Down |
Raw |
Any |
Processed |
Not processed |
VLAN |
Any |
Not processed |
Processed |
||
Up |
Raw |
Any |
Processed |
Not processed |
|
VLAN |
Any |
Not processed |
Processed |
||
Mesh SDP |
Down |
Raw |
Any |
Processed |
Not processed |
VLAN |
Any |
Not processed |
Processed |
||
Up |
Raw |
Any |
Processed |
Not processed |
|
VLAN |
Any |
Not processed |
Processed |
||
SAP |
Down |
Any |
Dot1q or QinQ |
Not processed 2 |
Processed |
Any |
Null |
Processed |
Not processed |
||
Up |
Any |
Dot1q or QinQ |
Not processed |
Processed |
|
Any |
Null |
Processed |
Not processed |
||
Notes:
Tagged frames are single-tagged frames (dot1q) or double-tagged frames (qinq).
Untagged frames received on a dot1q-encapsulated port are processed by the Epipe or VPLS pseudowire configured to handle untagged frames. The SAP identifier uses VLAN ID 0, also referred to as SAP 0 (for example, 1/1/2:0). Untagged frames are also processed on the *.* QinQ SAP, and on a vlan-x.0 QinQ SAP only if the outer tag matches.
Processing SAP 0 and SAP 0.* OAM Packets
The following points describe the processing of OAM packets on SAP 0 (dot1q) and SAP 0.* (qinq). SAP 0.0 is not supported on OAM packets.
the 7705 SAR transmits untagged OAM frames on SAP 0 and SAP 0.*
the 7705 SAR does not process OAM frames tagged with VLAN ID 0 or VLAN ID 0.* on a port configured with null encapsulation
the 7705 SAR processes double-tagged or triple-tagged OAM frames under the following configuration scenario: there is a SAP Up MEP on a dot1q- or qinq-encapsulated port, using SAP 0 or 0.*, and having VC-type VLAN
In this case, the top VLAN tag is removed and the bottom VLAN tag is assumed to be SAP 0 or 0.*. If the bottom VLAN tag is not SAP 0 or 0.*, the VLAN ID is changed to 0. If the frame is an OAM frame, double-tagged (or triple-tagged), the frame is extracted from the SAP Up MEP and the reply is with a single-tagged frame with its VLAN ID set to 0.
on a SAP Down MEP (dot1q or qinq), untagged frames are processed on SAP 0 or 0.*
MEG-ID and ICC-Based Format
Similar to an 802.1ag MA-ID, a Y.1731 MEG-ID uniquely identifies a group of MEs that are associated at the same MEG level in one administrative domain. The features of MEG-IDs are:
each MEG-ID must be globally unique
if the MEG may be required for path setup across interoperator boundaries, then the MEG-ID must be available to other network operators
the MEG-ID should not change while the MEG remains in existence
the MEG-ID should be able to identify the network operator that is responsible for the MEG
The 7705 SAR supports the ITU Carrier Code (ICC-based) MEG-ID format (TLV value 32). The generic and ICC-based MEG-ID formats are defined in the ITU-T Y.1731 standard. ICC-based MEG-ID Format shows the ICC-based MEG-ID format.
The MEG-ID value has exactly 13 characters and consists of two subfields, the ITU Carrier Code (ICC) followed by a Unique MEG-ID Code (UMC). The ITU Carrier Code consists of between 1 and 6 left-justified characters (alphabetic or leading alphabetic with trailing numeric). The UMC code immediately follows the ICC and consists of between 7 and 12 characters, with trailing NULLs (if necessary to complete the 13 characters).
The UMC is the responsibility of the organization to which the ICC has been assigned, provided that uniqueness is guaranteed.
ETH-CFM Functions and Tests
The following list of ETH-CFM functions applies to both dot1ag and Y.1731 Ethernet OAM:
ETH-CFM—ETH-CFM can be enabled or disabled on a SAP, spoke SDP, or mesh SDP (VPLS only)
MD levels—eight MD levels can be assigned
MD name—the following MD name formats are supported:
none (no MD name; used for specifying a Y.1731 functionality)
DNS name
MAC address and 2-octet integer
character string
MAs—MAs for each MD level can be configured, modified, or deleted
each MA is defined by a unique combination of MD index, MD level, and MA index. This unique combination of values is called the MA identifier (MA-ID).
the following MA name formats are supported:
primary VLAN ID (VID)
character string (when used with MD name format none, specifies Y.1731 interoperability with 802.1ag)
2-octet integer
RFC 2685, Virtual Private Networks Identifier
ICC-based (used for specifying a Y.1731 functionality)
when a VID is used as the MA name, CFM will not support VLAN translation because the unique MA-ID must match all the MEPs
the default format for an MA name is a 2-octet integer; integer value 0 means that the MA is not attached to a VID.
MEPs—Up and Down MEPs on a SAP, spoke SDP, or mesh SDP
MEPs can be configured, modified, or deleted for each MD level (both associations for the Up or Down MEP are with the same bridge port as described in Section 19.2.1 of IEEE Standard 802.1ag-2007)
each MEP is uniquely identified by its MEP identifier and MA-ID combination
MEP creation—MEP creation on a SAP is allowed only for Ethernet ports (with null, dot1q, or qinq encapsulations)
ETH-CFM Ethernet OAM Tests
This section describes Ethernet OAM tests for ETH-CFM on the 7705 SAR, including:
loopbacks
linktrace
throughput measurement
continuity check
remote defect indication
alarm indication signal
Ethernet (signal) test
Loopback
The loopback (LB) function is supported by 802.1ag and Y.1731 on the 7705 SAR. A Loopback Message (LBM) is generated by a MEP to its peer MEP. Both dot1ag and dot3ah loopbacks are supported. The loopback function is similar to IP or MPLS ping in that it verifies Ethernet connectivity between the nodes on a per-request basis. That is, it is non-periodic and is only initiated by a user request.
In Dot1ag Loopback Test, the line labeled LB represents the dot1ag loopback message between the 7750 SR (source) and 7705 SAR (target). The 7750 SR-generated LBM is switched to the 7705 SAR, where the LBM is processed. After the 7705 SAR generates the Loopback Reply message (LBR), the LBR is switched over the PW to the 7750 SR.
The following loopback-related functions are supported:
loopback message functionality on a MEP can be enabled or disabled
MEP—supports generating loopback messages and responding to loopback messages with loopback reply messages
displays the loopback test results on the originating MEP
Linktrace
The linktrace (LT) function is supported by 802.1ag and Y.1731 on the 7705 SAR. A Linktrace Message (LTM) is originated by a MEP and targeted to a peer MEP in the same MA and within the same MD level. Its function is similar to IP traceroute. The peer MEP responds with a Linktrace Reply (LTR) message after successful inspection of the LTM.
The following linktrace related functions are supported:
enables/disables LT functions on a MEP
MEP—supports generating LTMs and responding with LTR messages
displays linktrace test results on the originating MEP
Throughput Measurement
Throughput measurement is performed by sending frames to the far end at an increasing rate (up to wire speed) and measuring the percentage of frames received back. In general, the rate is dependent on frame size; the larger the frame size, the lower the rate.
The Y.1731 specification recommends the use of unicast ETH-LB and ETH-Test frames to measure throughput.
On the 7705 SAR, LBM processing and LBR generation are enhanced and occur on the datapath, allowing the 7705 SAR to respond to loopback messages at wire speed and making in-service throughput tests possible. Therefore, if the 7705 SAR receives LBMs at up to wire speed, it can generate up to an equal number of LBRs.
In order to process LBMs at wire speed, there must be either no TLVs or a single TLV (which is a data TLV) in the LBM frame. The End TLV field (0) must be present and the frame can be padded with data after the End TLV field in order to increase the size of the frame. The MAC address cannot be a multicast MAC address; it must be the MEP MAC destination address (DA).
Datapath processing of LBMs is supported with dot1ag and Y.1731 for the following MEPs:
SAP Up and Down MEPs
spoke SDP Up and Down MEPs
mesh SDP Up and Down MEPs (VPLS only)
For spoke or mesh SDP Up and Down MEPs, fastpath (datapath) LBM processing requires that both interfaces—the LBM receiver and the LBR transmitter—reside on the same adapter card. For example, if the 7705 SAR must perform a reroute operation and needs to move the next-hop interface to another adapter card (that is, LBMs are received on one card and LBRs are transmitted on another), the fastpath processing of LBMs is terminated and LBM processing continues via the CSM.
Continuity Check
The continuity check (CC) function is supported by 802.1ag and Y.1731 on the 7705 SAR. A Continuity Check Message (CCM) is a multicast frame that is generated by a MEP and sent to its remote MEPs in the same MA. The CCM does not require a reply message. To identify faults, the receiving MEP maintains a MEP database with the MAC addresses of the remote MEPs with which it expects to maintain connectivity checking. The MEP database can be provisioned manually. If there is no CCM from a monitored remote MEP in a preconfigured period, the local MEP raises an alarm.
The following CC capabilities are supported:
enable and disable CC for a MEP
automatically put local MEPs into the database when they are created
manually configure and delete the MEP entries in the CC MEP monitoring database. The only local provisioning required to identify a remote MEP is the remote MEP identifier (using the remote-mepid mep-id command).
CCM transmit interval: 10ms, 100ms, 1s, 10s, 1m, 10m (default: 10s)
transmit interval: 10ms, 100ms, 1s, 10s, 1m, 10m (default: 10s)
CCM declares a fault when it:
stops hearing from one of the remote MEPs for a period of 3.5 times the CC interval
hears from a MEP with a lower MD level
hears from a MEP that is not in the same MA
hears from a MEP that is in the same MA but is not in the configured MEP list
hears from a MEP that is in the same MA with the same MEP ID as the receiving MEP
recognizes that the CC interval of the remote MEP does not match the local configured CC interval
recognizes that the remote MEP declares a fault
An alarm is raised and a trap is sent if the defect is greater than or equal to the configured low-priority-defect value.
CC must be enabled in order for RDI information to be carried in the CCM OAMPDU
Remote Defect Indication
The Ethernet Remote Defect Indication (ETH-RDI) function is used by a MEP to communicate to its peer MEPs that a defect condition has been encountered. Defect conditions such as signal failure and AIS may result in the transmission of frames with ETH-RDI information. ETH-RDI is used only when ETH-CC transmission is enabled and it is enabled automatically.
ETH-RDI has the following two applications:
single-ended fault management—the receiving MEP detects an RDI defect condition, which gets correlated with other defect conditions in this MEP and may become a fault cause. The absence of received ETH-RDI information in a single MEP indicates the absence of defects in the entire MEG.
contribution to far-end performance monitoring—the transmitting MEP reflects that there was a defect at the far end, which is used as an input to the performance monitoring process
A MEP that is in a defect condition transmits frames with ETH-RDI information. A MEP, upon receiving frames with ETH-RDI information, determines that its peer MEP has encountered a defect condition.
The specific configuration information required by a MEP to support the ETH-RDI function is as follows:
MEG level—the MEG level at which the MEP exists
ETH-RDI transmission period—application-dependent and is the same value as the ETH-CC transmission period
priority—the priority of frames containing ETH-RDI information and is the same value as the ETH-CC priority
The PDU used to carry ETH-RDI information is the CCM.
Alarm Indication Signal
The Ethernet Alarm Indication Signal (ETH-AIS) function is a Y.1731 CFM enhancement used to suppress alarms at the client (sub) layer following detection of defect conditions at the server (sub) layer.
Transmission of frames with ETH-AIS information can be enabled or disabled on a Y.1731 SAP MEP.
Frames with ETH-AIS information can be issued at the client MEG level by a MEP, including a server MEP, upon detecting the following conditions:
signal failure conditions in the case where ETH-CC is enabled
AIS condition in the case where ETH-CC is disabled
For a point-to-point Ethernet connection at the client (sub) layer, a client layer MEP can determine that the server (sub) layer entity providing connectivity to its peer MEP has encountered a defect condition upon receiving a frame with ETH-AIS information. Alarm suppression is simplified by the fact that a MEP is expected to suppress only those defect conditions associated with its peer MEP.
Only a MEP, including a server MEP, is configured to issue frames with ETH-AIS information. Upon detecting a defect condition, the MEP can immediately start transmitting periodic frames with ETH-AIS information at a configured client MEG level. A MEP continues to transmit periodic frames with ETH-AIS information until the defect condition is removed. Upon receiving a frame with ETH-AIS information from its server (sub) layer, a client (sub) layer MEP detects the AIS condition and suppresses alarms associated with all its peer MEPs. After the AIS condition is cleared, a MEP resumes alarm generation upon detecting defect conditions.
The following specific configuration information is required by a SAP MEP to support ETH-AIS:
client MEG level—the MEG level at which the most immediate client layer MEPs exist
ETH-AIS transmission period—the transmission period of frames with ETH-AIS information
priority—the priority of frames with ETH-AIS information
Ethernet Test
The Ethernet Test (ETH-Test) signal function is a Y.1731 CFM enhancement used to perform one-way, on-demand, in-service diagnostics tests, which include verifying frame loss and bit errors. ETH-Test is supported on Y.1731 SAP MEPs and facility MEPs on network interfaces.
When configured to perform such tests, a MEP inserts frames with ETH-Test information such as frame size and transmission patterns.
When an in-service ETH-Test function is performed, data traffic is not disrupted and the frames with ETH-Test information are transmitted.
To support ETH-Test, a Y.1731 SAP or facility MEP requires the following configuration information:
MEG level—the MEG level at which the MEP exists
unicast MAC address—the unicast MAC address of the peer MEP for which ETH-Test is intended
data—an optional element with which to configure data length and contents for the MEP. The contents can be a test pattern and an optional checksum.
Examples of test patterns include all 0s or all 1s. At the transmitting MEP, this configuration information is required for a test signal generator that is associated with the MEP. At the receiving MEP, this configuration is required for a test signal detector that is associated with the MEP.
priority—the priority of frames with ETH-Test information
A MEP inserts frames with ETH-Test information toward a targeted peer MEP. The receiving MEP detects the frames with ETH-Test information and performs the requested measurements.
MEP Support (802.1ag and Y.1731)
The 7705 SAR supports the following MEPs for 802.1ag and Y.1731:
Up and Down MEPs on Ethernet (Epipe and VPLS) SAPs
Up and Down MEPs on Ethernet (Epipe and VPLS) spoke SDPs
Up and Down MEPs on mesh SDPs (VPLS only)
facility MEPs on network interfaces
802.1ag MEP Support on Ethernet SAPs
The 7705 SAR supports Up and Down MEPs on Ethernet SAPs. MEP on Ethernet Access shows that the 7705 SAR can terminate and respond to CFM messages received from connected devices, such as base stations, when port B is a Down MEP on a SAP. A CFM message coming from port A would be terminated on port B of the 7705 SAR. As well, port B on the 7705 SAR can generate and send a CFM message toward port A.
Down MEP at Ethernet SAP shows how a Down MEP on an Ethernet SAP may be used. In this example, an Ethernet network connects to an access Ethernet port on the 7705 SAR and there are multiple SAPs on that port (that is, multiple endpoints). Since CFM offers OAM capabilities on a per-service basis, which in this case means per SAP (or endpoint), each service can run CFM. If BSC end devices were directly connected to the 7705 SAR (and a VLAN was not used to separate services from each other), EFM would offer capabilities similar to CFM for Ethernet OAM.
In the example shown in Down MEP at Ethernet SAP, separate dot1ag instances initiated on the Wavence nodes can be used to ensure Ethernet layer connectivity on a per-base-station basis. All the traffic from these base stations is aggregated and switched to a single port on the 7705 SAR. Each base station is recognized through a different VLAN, where the VLANs are bound to different services. CFM with traffic in the Down MEP OAMPDU direction at the Ethernet SAP offers the flexibility to run OAM tests on a per-base-station basis.
802.1ag and Y.1731 MEP Support on Ethernet Spoke SDPs and Mesh SDPs
The 7705 SAR supports Up and Down MEPs with 802.1ag and Y.1731 on Ethernet spoke SDP endpoints (Epipe and VPLS) and mesh SDP endpoints (VPLS only). Dot1ag Down MEPs on Spoke SDPs illustrates a dot1ag Down MEP on an Ethernet spoke SDP.
CFM messages can be generated and switched across an Ethernet PW. CFM messages that are received and have an MD that matches the value configured on the 7705 SAR are extracted and processed. Any received CFM messages with an MD level that does not match the configured value are not terminated and are switched transparently to the Ethernet SAP.
Up and Down MEPs on Ethernet spoke and mesh SDPs on the 7705 SAR support the following:
termination of the CFM messages destined for the MEP-ID of the 7705 SAR
termination of CFM messages at the user-configured domain only
discarding of OAMPDUs at a lower MD level than the configured one (an alarm message is raised)
transparent pass-through of upper-layer CFM messages
MD of the CFM messages that are higher than the one configured on the 7705 SAR
MIP functionality (that is, forwarding of CFM messages with the same MD level) is not supported.
In Dot1ag Down MEPs on Spoke SDPs, assuming that the MEP is enabled both on the 7750 SR and the 7705 SAR spoke SDP endpoints, the 7705 SAR can generate CFM messages and can terminate any received CFM messages that are destined for the 7705 SAR MEP-ID and have a matching configured domain. Any 7705 SAR-generated CFM packets would traverse the Ethernet PW and would be processed first by the 7750 SR node. The Ethernet PW running between the 7705 SAR and the 7750 SR generates a pipe-like connectivity; therefore, no intermediate Ethernet node can process the CFM messages. All the CFM messages are transported over Ethernet PWs, and PW termination only takes place on 7750 SR and 7705 SAR endpoints.
Y.1731 MEP Support on Ethernet SAPs
As shown in Y.1731 MEP Support on the 7705 SAR, the 7705 SAR supports Y.1731 Up and Down MEPs on Ethernet SAPs that are bound to an Ethernet PW service.
Y.1731 MEP Support on the 7705 SAR also shows an 802.1ag Down MEP on an Ethernet spoke SDP in order to illustrate that when performing CFM tests on the 7705 SAR, a Y.1731 Up MEP on an Ethernet SAP should be used instead of an 802.1ag Down MEP on an Ethernet spoke or mesh SDP. Using a Y.1731 SAP Up MEP means that CFM packets verify the switching fabric and SAP status before the packet is processed, because the SAP is on the access side of the 7705 SAR whereas a spoke or mesh SDP is on the network side. If a spoke or mesh SDP Down MEP is used, packets are terminated and extracted on the network side without being switched through the switching fabric.
Priority Mapping (802.1ag and Y.1731)
Operators often run OAM tests over a single, specific forwarding class (FC). For example, an operator may be mapping OAM traffic to FC2 (AF – Assured Forwarding) and, in order to examine the delay, jitter, or loss qualities of the OAM traffic, would need to run OAM tests using FC2. To provide operators with the ability to control which FC the OAM packets will follow, the priority priority command is included in several OAM test commands.
When the 7705 SAR generates an Ethernet OAM frame, it uses the priority as per the user’s configuration of the priority keyword and then sends the frame through the datapath. Therefore, the OAM frame follows the entire datapath and receives the same treatment as any other user frame before it is switched over the port.
For example, a CCM frame generated by a SAP Up MEP with a priority value of 7 will receive the following treatment.
First, the CCM frame is classified as per the access ingress and QoS policy settings. For example, the CCM frame can be mapped to the BE forwarding class if the assigned QoS policy has its priority 7 mapped to BE.
Then, the OAM packet is mapped to the associated queue (the queue hosting the BE forwarding class) and follows ingress scheduling like any other datapath frame.
Next, the CCM frame is switched through the fabric and reclassified to the network egress queues, as per the assigned QoS policy classifiers.
Finally, the CCM frame is scheduled again, as per the queue type and profile state of the queue.
This implementation replicates the user experience since the OAM packet follows the same path as the data packets.
Priority Mapping for SAP Up MEPs
For Up MEPs on a SAP, priority mapping operates as described in the following list, which indicates how the messages or replies generated on ingress have their FC and VLAN tag priority set.
The resulting frames (CCM, LMM, DMM, 1DM, LBM, LMR, DMR, or LBR) are inserted in the access ingress datapath and are processed in the same way as any other frame. That is, they are classified based on the SAP ingress policy.
Continuity Check Messages (CCMs) generated on ingress are based on the setting of the ccm-ltm-prio command for the MEP (that is, the VLAN tag priority is set according to the ccm-ltm-prio command for the MEP).
Loss Measurement Messages (LMMs), two-way Delay Measurement Messages (DMMs), one-way Delay Measurement Messages (1DMs), and Loopback Messages (LBMs) generated on ingress are based on the priority specified during the LMM, DMM, 1DM, or LBM test (that is, the VLAN tag priority is set according to the priority specified during the test).
Loss Measurement Replies (LMRs), two-way Delay Measurement Replies (DMRs), and Loopback Replies (LBRs) generated on ingress keep the VLAN tag priority of their corresponding LMM or DMM frame.
FC and VLAN Priority Mappings for Up and Down MEPs as per Frame Type summarizes the 7705 SAR FC and VLAN priority mappings for SAP Up and Down MEPs based on the frame type.
MEP Type |
Frame Type (Tx) |
FC |
VLAN priority |
|---|---|---|---|
SAP Up MEP |
CCM |
derived from vlan-prio after classification |
ccm-ltm-prio |
LMM, DMM, 1DM, LBM |
derived from vlan-prio after classification |
user-specified |
|
LMR, DMR, LBR |
derived from vlan-prio after classification |
preserve incoming query priority |
|
SAP Down MEP |
CCM |
ccm-ltm-prio |
ccm-ltm-prio |
LMM, DMM, 1DM, LBM |
user-specified |
user-specified |
|
LMR, DMR, LBR |
ccm-ltm-prio |
incoming tag priority |
Priority Mapping for SAP Down MEPs
For SAP Down MEPs, priority mapping operates as described in the following list, which indicates how the messages or replies generated on egress have their FC and VLAN tag priority set.
CCMs generated on egress are based on ccm-ltm-prio of the MEP (that is, FC and VLAN tag priority are set according to the ccm-ltm-prio of the MEP).
LMM, DMM and 1DM generated on egress are based on the priority specified during the test (that is, FC and VLAN tag priority are set according to the priority specified during the test).
LMR, DMR, and LBR generated on egress use the ccm-ltm-prio of the MEP as FC. The VLAN tag priority is not replaced (that is, the VLAN tag priority of LMM and DMM are kept).
G.8032 Ethernet Ring Protection Switching
This section contains the following topics:
The 7705 SAR supports Ethernet ring protection switching in accordance with ITU-T G.8032 to achieve resiliency for Ethernet Layer 2 networks. A G.8032 Ethernet ring is built on Ethernet OAM and is also referred to as Ring Automatic Protection Switching (RAPS).
Ethernet rings are supported on VPLS SAPs. VPLS services supporting Ethernet rings can connect to other rings and Ethernet services using VPLS and r-VPLS SAPs. Ethernet rings provide rings for core network or access network resiliency. A single point of interconnection to other services is supported. The Ethernet-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 combined service protection ensures that higher layers are isolated from failures because there will only be a RAPS switchover when the lower layer cannot recover.
Rings are preferred in data networks where the native connectivity is laid out in a ring or where there is a requirement for simple resilient LAN services. Due to the symmetry and the simple topology, rings are considered a good solution for access and core networks where resilient LANS are required. The 7705 SAR implementation can be used for interconnecting access rings and to provide traffic engineered backbone rings.
Even though 7705 SAR nodes are often connected via IP/MPLS links to each other or to higher hierarchies, the first level of connected aggregation nodes can significantly benefit from G.8032 protection switching. Ethernet Protection Switching shows a common example where standalone microwave nodes are deployed in a ring that are connected to a 7705 SAR node acting as the head-end of the ring. Providing G.8032 Ethernet ring protection switching would provide significantly better reconvergence times in the ring and ensure minimal service disruption in case of failure.
Ethernet rings use one VLAN ID per control per ring instance and use one or more VIDs for data instances per control instance. A dedicated control VLAN (ERP VLAN) is used to run the protocol on the control VLAN ID. 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 7705 SAR supports dot1q and qinq encapsulation for data ring instances. The control channel supports dot1q and qinq encapsulation. The control channel can support dot1q while the data channels use qinq if the global new-qinq-untagged- sap command is enabled.
Overview of G.8032 Operation
RAPS messages that carry the G.8032 protocol are sent on a dedicated protocol VLAN called the Ethernet Ring Protection (ERP) instance. Revertive and non-revertive behaviors are supported. In revertive mode, the G.8032 protocol ensures that one Ring Protection Link (RPL) owner blocks the RPL. RAPS messages are periodically sent around the ring 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.
Y.1731 Ethernet OAM CC is the basis of the RAPS messages. Nodes in the ring typically us Y.1731 CC messages to monitor the health of each link in the ring in both directions. CC messages are not mandatory. Other link layer mechanisms could be used, for example, Loss of Signal (LOS) for instances 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. After a ring node in the ring learns that another link is blocked, the node unblocks its blocked link possibly causing an FDB flush of all links in the ring for the affected service VLANs controlled by the ring control instance. This results in unblocking all links except one so that the ring is in the normal, or idle, state. In revertive mode, the link that is blocked when all other links are operable after the revert time has expired becomes the RPL. In non-revertive mode the RPL is no different than other ring links. Revertive mode offers predictability, especially when there are multiple ring instances and the operator can control which links are blocked on each instance. When there is a topology change that affects reachability, the nodes may flush the FDB and MAC learning occurs for the affected service VLANs, which allows packet forwarding to continue. G.8032 Ring in the Idle State depicts this operational state.
When a ring failure occurs, any node that detects the failure (by using Y.1731 OAM CC monitoring) sends RAPS message in both directions. After receiving a failure notification, the nodes at both ends of the failed link block forwarding to the failed link to prevent it from becoming active.
When a ring failure occurs in revertive mode, the RPL owner unblocks the previously blocked RPL and triggers an FDB flush for all nodes for the affected service instances. The ring is now in the protecting state and full ring connectivity is restored. MAC learning occurs, which allows Layer 2 packet forwarding on the ring. G.8032 Ring in the Protecting State depicts a G.8032 ring in the protecting state.
After the failed link recovers, the nodes that blocked the link send RAPS messages indicating no failure. This triggers the RPL owner to block the RPL link and indicate the blocked link in its own RAPS message. When the nodes at the recovered link receive the RPL RAPS message, they unblock the specified link, restore connectivity, and all nodes in the ring perform an FBD flush. MAC learning takes place and the ring returns to the normal, or idle, state.
Each path uses Y.1731 Maintenance Entity Groups (MEGs) and Maintenance Endpoints (MEPs) to exchange RAPS-specific information to co-ordinate switchovers. As well Y.1731 MEGs and MEPs optionally use fast Continuity Check Messages (CCM), which provide an inherent fault detection mechanism as part of the protocol. When a ring path failure is detected, the protection links are activated. During a failure, reconvergence times depend on the failure detection mechanisms being used. For Y.1731, the CCM transmit interval determines the response time. The router supports message timers as low as 10 ms, providing restoration times comparable to SONET/SDH. Alternatively, 802.3ah (Ethernet in the First Mile) or simple LOS can act as a trigger for a protection switch where appropriate. Where nodes are directly connected there is no need to use Ethernet CC messaging for liveness detection.
G.8032 supports multiple data channels (VLAN IDs) or instances per ring control instance (RAPS tag). G.8032 also supports multiple control instances such that each instance can support RPLs on different links, providing load balancing capability. However, once services have been assigned to one instance the rest of the services that need to be interconnected to them must be on the same instance. In other words, each data instance is a separate data VLAN on the same physical topology. If there is a single link or node failure in the ring, G.8032 protocols are capable of restoring traffic between all remaining nodes in these data instances.
Ethernet RAPS can be configured on any port configured for access mode by using dot1q or qinq encapsulation, enabling support for Ethernet RAPS protected services on the service edge toward the customer site or within the Ethernet backbone.
The Ethernet ring is built from a VPLS service on each node with VPLS SAPs that provide ring paths with SAPs. As a result, most of the VPLS SAP features are also available on Ethernet rings resulting in a feature-rich ring service.
The control tag defined under each Ethernet 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 CCMs exchanged on that segment or will receive a fault indication from the link layer OAM module. CCMs are optional but MEPs are always configured to provide G.8032 control. The forwarding of CCMs and G.8032 RAPS messages continues in the control VPLS even if the service or its SAPs are administratively shut down. The Ethernet ring instance can be shut down to stop the operation of the ring on a node.
For fault detection using CCMs, three CC messages and a configurable hold-off timer must be missed for a fault to be declared on the associated path. The hold-off timer is required in order to support an additional 50 ms resiliency mechanism in the optical layer. After receiving the fault indication, the protection module declares the associated ring link down and the G.8032 state machine sends the appropriate messages to open the RPL and flush the learned addresses.
Flushing is triggered by the G.8032 state machine and the router implementation allows flooding of traffic during the flushing interval to expedite traffic recovery.
Ring Example illustrates a resilient Ring Service. In the example, a ring (solid line) with that usage dot1q VLAN ID 100 carries service VID 500. The RPL for the ring is between A and B, where B is the RPL owner. Also illustrated is a QinQ service on the (dotted line) ring that uses dot1q VLAN ID 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.
Ring Example illustrates that service encapsulations and ring encapsulation can be mixed in various combinations. Neither of the rings is a closed loop. When any one node or link fails, a ring can restore connectivity to all remaining nodes within the 50 ms transfer time (the signaling time after detection).
- Example:
configureeth-ring 1description "Ethernet Ring on Node B"revert-time 100guard-time 5ccm-hold-time down 100 up 200rpl-node ownerpath a 1/6/1 raps-tag 100# Control Channel Tag 100description "To A ring link"rpl-endeth-cfmmep 1 domain 1 association 1control-mepno shutdownexitexitno shutdownexitpath b 1/6/2 raps-tag 100 # Control Channel Tag 100description "to D Ring Link"eth-cfmmep 1 domain 1 association 1control-mepno shutdownexitexitno shutdownexitno shutdownexitservicevpls 10 customer 1 create # Ring APS SAPsdescription "Ring Control VLAN ID 100"sap 1/6/1:100 eth-ring 1 create# TAG for the Control Path ano shutdownexitsap 1/6/2:100 eth-ring 1 create# TAG for the Control Path bno shutdownexitno shutdownvpls 40 customer 1 createdescription "Data service over Ethernet Ring 1 VLAN ID 500"sap 1/1/1:100 create# Traffic from uW nodeno shutdownexitsap 1/6/1:500 eth-ring 1 create# TAG for the Data Channel Path ano shutdownexitsap 1/6/2:500 eth-ring 1 create# TAG for the Data Channel Path bno shutdownexitno shutdownexit
Ethernet Ring Sub-Rings
Ethernet sub-rings offer a dual redundancy with interconnected rings. The router supports sub-rings connected to major rings and a sub-ring connected to an LDP-based VPLS for access ring support in VPLS networks. G.8032 Sub-Ring and Sub-Ring Configuration Example illustrates 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. The sub-ring (ERP2) relies on the major ring (ERP1) as part of its protection for traffic from nodes C and D, which are configured as interconnection nodes.
Sub-rings and major rings run similar state machines for the ring logic, however there are some differences. When sub-rings protect a link, the flush messages are propagated to the major ring. A special configuration allows control of this option on the router. When major rings change topology, the flush is propagated around the major ring but 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 usually need to be propagated to the other ring or network. 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 7705 SAR supports sub-ring control communication using either a virtual channel or non-virtual channel. In virtual channel mode, a dedicated VLAN ID, other than the major ring RAPS control channel, is configured as a data instance on the major ring. This allows the sub-ring control messages and state machine logic to function similar to a major ring. In non-virtual channel mode, the sub-ring is only connected by the RAPS control channels on the sub-ring itself. This mode offers slightly less redundancy in the RAPS messaging than the virtual channel mode because sub-ring RAPS messages are not propagated across the major ring. When a non-virtual link is configured, the protocol allows RPL messages over the sub-ring blocked link. Sub-Ring Configuration Example shows a sub-ring configuration using virtual and non-virtual channels.
Sub-ring configuration is similar to major ring configuration and consists of three parts:
Ethernet ring instance configuration
control VPLS configuration
data VPLS configuration (data instance or data channel)
The Ethernet ring configuration of a sub-ring is tied to a major ring and only one path is allowed. A split horizon group is mandatory to ensure that sub-ring control messages from the major ring are only passed to the sub-ring control.
As with a major ring, CCMs and RAPS messages continue to be forwarded in the control VPLS even if the service or its SAPs are administratively shut down. The Ethernet ring instance can be shut down to stop the operation of the ring on a node.
The data VPLS can be configured on the major ring and shares the same VLAN ID (SAP encapsulation) on both the major ring and the sub-ring to keep data on the same VLAN ID everywhere. See the configuration example shown below. Like other services in the router, the encapsulation VLAN ID is controlled by SAP configuration and the association to the controlling ring is by the Ethernet ring ID.
The following CLI output is an example of a sub-ring configuration on Node C shown in Sub-Ring Configuration Example:
eth-ring 2
description "Ethernet Sub Ring on Ring 1"
sub-ring virtual-link // Using a virtual link
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 VLAN ID 100
eth-cfm
mep 9 domain 1 association 4
ccm-enable
control-mep
no shutdown
exit
exit
no shutdown
exit
no shutdown
exit
If the sub-ring had been configured as a non-virtual-link, the sub-ring configuration above and on all the other sub-ring nodes for this sub-ring would instead be:
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 VLAN ID 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 VLAN ID 11 for Ring 1"
stp shutdown
sap 1/1/1:11 eth-ring 1 create // VLAN ID 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 VLAN ID to be configured.
vpls 100 customer 1 create
description "Control VLAN ID 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
The 7705 SAR supports a special configuration of the non-virtual link sub-ring that can be homed to a VPLS service as illustrated in Sub-Ring Homed to VPLS. This is an economical way to have a redundant ring connection to a VPLS service. This is currently supported only for dot1q and qinq sub-rings and only on LDP-based VPLS. The primary application for this is access rings that require resiliency. This example in Sub-Ring Homed to VPLS shows a sub-ring at an interconnection node without a virtual channel and interconnected to a VPLS. A VPLS service 1 is used to terminate the ring control. The Ethernet ring data SAP appears in the associated LDP-based VPLS service 5.
The following CLI output is an example of a sub-ring configuration for VPLS PE1 of Multi-Ring Hierarchy:
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
# Configuration for the ring control interconnection termination:
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 LDP based 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
Ethernet rings and sub-rings offer a way to build a scalable and resilient Ethernet transport network. Multi-Ring Hierarchy illustrates a hierarchical ring network where dual-homed services are connected to an Ethernet ring network.
Major rings are connected by sub-rings to the top level major ring. These sub-rings require a virtual channel and will not work with non-virtual channels. Ring flushing is contained to major rings or in the case of a sub-ring link failure or node failure, to the sub-ring and any directly attached major rings.
LAG Support
Ethernet rings support LAG on Ethernet ring SAPS. However, using LAG impacts the resiliency response time. In many cases, operators may achieve better resiliency response time and QoS by using multiple ring instances, each on a single link, instead of LAG on Ethernet rings. If a response time of less than 100 ms is not required, LAG is an acceptable option for Ethernet rings.
OAM Considerations
Ethernet CFM is enabled by configuring MEPs on each individual path under an Ethernet ring. Only down MEPs can be configured on each path. CCM sessions can also be enabled to monitor the liveness of the path using an interval of 10 ms or 100 ms. Different CCM intervals can be supported on path A and path B in an Ethernet ring. CFM is optional if the node supports LOS, which is controlled by configuring no-ccm-enable.
Up MEPs on service SAPs that multicast into the service and monitor the active path may be used to monitor services.
When an Ethernet ring is configured on two ports located on different cards, the SAP queues and virtual schedulers are created with the actual parameters on each card.
Ethernet ring CC messages that are transmitted over the SAP queues using the default egress QoS policy use network class (NC) as a forwarding class. If user traffic is assigned to the NC forwarding class, it will compete for bandwidth resources with the Ethernet CCMs and cause congested queues. This congestion can result in CCM loss that could lead to unnecessary switching of the Ethernet ring. To avoid potential congestion, configure different QoS policies that will control the amount of traffic assigned into the corresponding queue.
Support Service and Solution Combinations
Ethernet rings are supported on VPLS and r-VPLS instances. The following considerations apply.
Only ports in access or hybrid mode can be configured as Ethernet ring paths. The ring ports can be located on the same or different media adapter cards.
Dot1q and qinq ports are supported as Ethernet ring path members.
A mix of regular and multiple Ethernet ring SAPs and pseudowires can be configured in the same services.
QinQ Support
This section contains the following topics:
Overview of QinQ
On the 7705 SAR, QinQ (also referred to as VLAN stacking) is based on the IEEE 802.1ad specification. QinQ allows a service provider to use a single VLAN for customers needing multiple VLANs by adding a second VLAN tag to an Ethernet frame, as shown in QinQ Frame. QinQ encapsulation can be thought of as a dot1q within a dot1q encapsulation.
QinQ operates from end-to-end by receiving customer frames on an ingress SAP, transporting the frames over a service tunnel, and receiving them at the far-end router, where they are unpacked and sent through the egress SAP to the customer.
On the 7705 SAR, QinQ ports and QinQ SAPs offer the same feature set as dot1q ports and dot1q SAPs for the following features:
OAM
redundancy
synchronization
QoS
card and node limits
QinQ is supported on the following service SAPs (including SAP-to-SAP configurations):
VLL services (Epipe and Ipipe)
VPLS
VPRN
IES
QinQ is supported on the following adapter cards, modules, and nodes:
6-port Ethernet 10Gbps Adapter card
8-port Gigabit Ethernet Adapter card
10-port 1GigE/1-port 10GigE X-Adapter card (10-port 1GigE mode)
Packet Microwave Adapter card
4-port SAR-H Fast Ethernet module
6-port SAR-M Ethernet module
7705 SAR-M
7705 SAR-A
7705 SAR-Ax
7705 SAR-Wx (Ethernet ports)
7705 SAR-H
7705 SAR-Hc
7705 SAR-X
QinQ Tagging Example shows an example of QinQ tagging, where three customer sites each use the same service provider PE router to transport multiple VLANs across an MPLS network. Customer 1 sends an Ethernet frame without a VLAN tag (null encapsulation) and the provider uses MPLS label 25. Customer 2 sends dot1q frames (VLAN ID 20) and the provider uses MPLS label 35. Lastly, customer 3 sends a qinq frame (VLAN ID 10:300) and the provider uses MPLS label 45.
For details on VLAN translation in an Ethernet frame from ingress SAP to egress SAP, see Raw and Tagged Modes.
QinQ Support with Forced C-Tag Forwarding (VPLS only)
For VPLS, force-c-vlan-forwarding can be user-configured as enabled or disabled. When force-c-vlan-forwarding is enabled at the ingress and egress SAPs, the VLAN tag transmitted at the far-end egress SAP is the same as the VLAN tag received at the near-end ingress SAP.
The following examples illustrate the QinQ implementation. Example 1 is a general example. Examples 2 and 3 are examples where the 7705 SAR parses a single frame that has three VLAN tags. For examples 2 and 3, the innermost VLAN Ethertype is always set to 0x8100.
Example 1: General QinQ Implementation
When a service has multiple SAPs configured that can match an incoming frame, the SAP with the most explicit match transmits the frame. For this example, assume that the following SAPs are configured on a port and that the port is in QinQ mode:
SAP_1 identifier is port-id:vlan-x.vlan-y
SAP_2 identifier is port-id:vlan-x.*
SAP_3 identifier is port-id:*.*
For an incoming frame with VLAN tags vlan-x.vlan-y, SAP_1 processes the frame because it is the most explicit match. Although SAP_2 and SAP_3 also match the frame, the most explicit SAP prevails.
Example 2: QinQ using VPLS with Ethernet SAPs
In this example, assume that the 7705 SAR parses a single frame that has three VLAN tags (innermost VLAN Ethertype is always set to 0x8100). This may occur in the scenario shown in QinQ Using VPLS Ethernet SAPs, where VPLS QinQ SAPs with force-c-vlan-forwarding enabled connect Customer 1 and Customer 2 and preserve the ingress VLAN tag.
In QinQ Using VPLS Ethernet SAPs, the following events occur.
At Node_1, an ingress QinQ SAP with force-c-vlan-forwarding enabled receives a frame and ensures that the bottom (inner) tag is preserved. The frame is then sent to an egress qinq-encapsulated SAP, where the top (outer) tag is swapped and an additional (third) tag is pushed on top.
At Node_2, the frame with three tags is received on a qinq-encapsulated SAP. The frame is then sent to an egress QinQ SAP with force-c-vlan-forwarding enabled, where the egress qinq-encapsulation SAP:
removes the first (top) tag
replaces the second (middle) tag
replaces only the Ethertype of the third (bottom/innermost) tag (that is, the VLAN ID is not replaced)
Example 3: QinQ Using VPLS with ATM SAPs
A second example of triple-tag behavior is shown in QinQ Using VPLS ATM SAPs, where customers are connected using ATM SAPs with subscriber-vlan enabled.
In this example, the ATM SAP with subscriber-vlan enabled pushes a tag on the frame at ingress. The frame is then sent toward a qinq-encapsulated SAP on egress, which pushes two more tags onto the frame. At the far end, the frame (with three tags) is received on a qinq-encapsulated SAP and sent toward the egress ATM SAP with subscriber-vlan enabled. In this case, the egress ATM-encapsulated SAP must be able to remove the three tags.
QinQ Support on Ethernet Ports
This section contains the following topics:
QinQ requires that the encap-type for the associated port be set for qinq, and that the sap-id include two Q-tags (VLAN IDs). An ingress QinQ SAP can be configured so that dot1p bits for packet QoS classification can come from the top or the bottom Q-tag. At egress, if dot1p re-marking is configured, both Q-tags are re-marked. However, you can use qinq-mark-top-only to re-mark only the top Q-tag.
Special QinQ SAP Identifiers
Special QinQ SAP Identifiers describes the special SAP identifiers used on the 7705 SAR. In Special QinQ SAP Identifiers, a qtag value represents a VLAN ID. The * (asterisk) represents a reserved VLAN that is used to carry traffic from any unused VLAN on the port. An unused VLAN is a VLAN that is not explicitly defined on the port.
QinQ SAP Type |
SAP Identifier |
Example |
Notes |
|---|---|---|---|
Explicit (specified) |
port-id:qtag1.qtag2 1 |
1/1/1:20.2000 |
qtag1 and qtag2 range: 0 to 4094, and * |
Null |
port-id port-id:0 port-id:0.* port-id:qtag1.0 2 |
1/1/1 1/1/1:0 1/1/1:0.* |
No suffix means no VLANs 0 suffix means SAP 0 0.* suffix means SAP 0 and any unused VLAN on the port |
Default |
port-id:* port-id:*.* port-id:qtag1.* |
1/1/1:* 1/1/1:*.* 1/1/1:40.* |
*.* means any unused VLAN on the port 3 |
Notes:
qtag1 is the top (outer) tag; qtag2 is the bottom (inner) tag.
This configuration becomes available when the new-qinq-untagged-sap command is enabled.
-
The behavior of the *.* SAP on the 7705 SAR is different from the *.* SAP behavior on the 7750 SR. On the 7750 SR, *.* represents a capture SAP.
-
port-id:*.0
-
port-id:*.vlan-y
The following list describes how the SAP types in Special QinQ SAP Identifiers process frames. Packet breakdowns are described in Raw and Tagged Modes.
default SAP (port-id:qtag1.*)
receives all frames with an explicit outer tag value of qtag1, regardless of the inner tag
the outer tag is stripped and the inner tag is passed transparently
example: SAP 1/1/1:10.* only matches a top Q tag of VLAN 10. The SAP may have any bottom tag or no bottom tag at all.
null SAP (port-id:0.*)
receives all untagged frames and/or any frames with a VLAN tag of 0
example: SAP 1/1/1:0.* allows any untagged frames and/or frames with an outer tag of ‟0” only
If the outer tag is 10, then the frame is dropped. If the outer tag is 0 and the inner tag is any valid VLAN ID, then the frame is not dropped.
null inner SAP (port-id:qtag1.0)
receives all frames with explicit outer tag value qtag1, and may have an inner tag of 0 or no inner tag at all
example: SAP 1/1/1:10.0 or SAP 1/1/1:10 will only match ‟10” as the outer tag, and may have a bottom tag of 0 or no bottom tag at all. The SAP 1/1/1:1/10 will be dropped because its outer tag is not ‟10”.
invalid SAPs (not supported) (port-id:*.qtag2 and port-id:*.0)
QinQ Dot1p Match Behavior
Since a qinq-encapsulated packet has top and bottom Q-tags, you can specify which qtag position provides the dot1p bits (P-bits) when QoS evaluates the P-bits in an ingress packet for a classification match. This is done with the sap>ingress>match-qinq-dot1p command. The default setting is to use the P-bits from the inner (bottom) Q-tag, or if the ingress packet has no Q-tags or has null encapsulation, then no match filtering is done.
QinQ Top-Only Mark Option
By default, if dot1p re-marking is configured at SAP egress on a QinQ SAP, the dot1p bits for both the top and bottom tags are re-marked. However, re-marking can be configured such that only the top Q-tag P-bits get remarked by enabling the sap>egress>qinq-mark-top-only command. The DEI bit is ignored.
Maximum Number of VLAN Tags
The maximum number of VLAN tags allowed in a packet depends on whether the service requires Layer 3 packet parsing (for example, to access to the IP header), as follows.
For services that do not require access to the Layer 3 IP header, such as Ethernet PWs and VPLS, there is no limit on the number of VLAN tags in the packet. Any packet with any number of VLAN tags is accepted.
For services that require access to the Layer 3 IP header, such as IP PWs, IES, and VPRN, there is a limit of three or fewer VLAN tags. When a packet is received that has four VLAN tags, the data following the third VLAN tag is considered as an IP packet. As a result, packets with four VLAN tags will be dropped by these services due to the inability to decode the IP header.
QinQ Configuration Overview
The basic steps to configure QinQ are as follows.
Configure the port encap-type for qinq and (optionally) set the Ethertype (qinq-etype).
Create one or more SAPs for the service.
Configure the SAP ingress dot1p re-marking behavior (match the top or bottom tag).
Enable the SAP egress qinq-mark-top-only command.
Configure the spoke SDP vc-type (ether or vlan).
Raw Socket IP Transport Service
Serial data transport using raw sockets over IP transport services is a method of transporting serial data, in character form, over an IP network using Layer 3-based services. This feature can help transport Supervisory Control and Data Acquisition (SCADA) data from Remote Terminal Units (RTUs) to Front-End Processors (FEPs), or SCADA masters.
The functionality provided by the IP transport service feature for serial raw sockets is summarized as follows:
IP transport local host (server) function, to listen to and open raw socket sessions from remote hosts
IP transport remote host (client) function, to initiate and open new raw socket sessions to remote hosts
both local host and remote host functions support for either TCP or UDP IP transport services
IP transport over an IES or VPRN service
enhanced QoS and queuing of sessions to ensure that collisions between sessions do not cause serial data to impact RTUs and end-user equipment
IP Transport Service illustrates a detailed view of the local host (server) and remote host (client) functionality that enables multiple communication streams to and from a serial port using raw socket IP transport.
The figure shows a three-node network: a 7705 SAR-H or 7705 SAR-Hc (left), a 7705 SAR-8 Shelf V2 or 7705 SAR-18 (top right) and a 7705 SAR-H/7705 SAR-Hc node, 7705 SAR-8 Shelf V2/7705 SAR-18 node, or 7750 SR/VSR node (bottom right). There are two devices, RTU (1) and RTU (2) connected to the serial ports on the 7705 SAR-H/7705 SAR-Hc. FEP server [A] can reach the RTUs via the socket sessions that originate from the 12-port Serial Data Interface card on the 7705 SAR-8 Shelf V2/7705 SAR-18 node. The bottom-right 7705 SAR or 7750 SR/VSR node is connected to FEP server [B] directly using Ethernet. This FEP server reaches the RTUs via a Layer 3 IP/MPLS service where raw socket sessions are processed directly on the FEP servers.
Through local host and remote host configurations on the 7705 SAR-H/7705 SAR-Hc or 7705 SAR-8 Shelf V2/7705 SAR-18, serial raw socket IP transport sessions are established to carry serial data over a wireless IP/MPLS network. The source and destination IP addresses and port numbers for these sessions are derived directly from the local/remote host configurations associated with each serial port or master head-end server.
The 7705 SAR-H/7705 SAR-Hc supports the ability to configure a raw socket IP transport interface for each serial port. This allows the raw socket IP transport to receive TCP or UDP session packets from multiple remote hosts when operating as a local host (server), or to create new multiple sessions to remote hosts to send and receive serial data when operating as a client.
There are two main configurations required for a serial raw socket IP transport service to be operational and to support the sending and receiving of serial data:
port-level configuration
This includes configuring rudimentary serial link parameters such as baud rate, start/stop values, and bits. Socket-level configuration is also required, such as configuring end-of-packet checking parameters (idle-time, length, special character) and the inter-sessions delay for transmitting sessions data out the serial link. For information about the required port-level configuration, see the 7705 SAR Interface Configuration Guide, Configuration Command Reference chapter, ‟Serial Commands”.
IP transport service-level configuration
This includes creating an IP transport subservice to associate the serial port within a Layer 3 IES/VPRN service, so that TCP/UDP encapsulated serial data can be routed within the corresponding Layer 3 service. The IP transport subservice ID is modeled and created in the same way that the SAP IDs are created under the same service types. IP transport configuration includes configuring IP transport local host items and remote host items, such as setting TCP timers and sessions controls. See IES Command Reference and VPRN Services Command Reference for the required commands.
The 7705 SAR-H/7705 SAR-Hc supports the configuration of a raw socket IP transport service for each serial port. This allows each serial port’s local host to listen to and open raw socket sessions from remote hosts that need to communicate over the serial port, and for each serial port’s local host to initiate and open raw socket sessions to remote hosts when serial data needs to be sent to those remote hosts. The local and remote host functions support TCP or UDP sessions (but not both concurrently) over the IES/VPRN service.
The serial data is received as characters that represent bytes in a packet. These bytes are packetized into Layer 3 TCP/UDP packets that are then transported or forwarded across the IP/MPLS network using the node’s Layer 3 IES/VPRN service constructs for routing. TCP/UDP Packet Transport Over IP/MPLS illustrates how serial data is encapsulated into TCP/UDP packets and transported over IP/MPLS.
For raw socket packets to be routed within an IES/VPRN service, an IP transport subservice must be configured within an IES/VPRN context. The IP transport subservice context is where users configure local host and remote host information, such as IP addresses and ports for establishing TCP/UDP sessions, and other per-session parameters. TCP/UDP encapsulated serial data is routed within the corresponding Layer 3 IES/VPRN service. IES/VPRN IP Transport Service illustrates this concept.
To create an IP transport subservice, the ip-transport command is used with the corresponding serial port as the ipt-id to bind the serial port SAP to the IP transport subservice. After the IP transport service is created, local host and remote host configurations can proceed. A local host must be configured before remote hosts can be configured.
Each local host uses a local address (from a loopback or local interface configured under the IES/VPRN service context) as the local host IP address of the IP transport subservice associated with the serial port. The local host IP address is the source IP address in the raw socket packets leaving the node within the IES/VPRN service. The local host is used to terminate TCP/UDP sessions from remote hosts. The local host can select either the TCP or UDP protocol for raw socket sessions but not both concurrently.
Multiple remote hosts can be configured under the IP transport subservice associated with the serial port so that each remote host receives the serial data that is received on the serial port. Each remote host has its own remote destination IP address and port value for establishing sessions. The configured remote hosts use the TCP or UDP protocol configured for the IP transport subservice.
IP transport processing of TCP/UDP packets occurs on the CSM of the 7705 SAR-H/7705 SAR-Hc. Filters configured for protecting the CSM must take into account the raw socket IP transport packets and ensure that the filter is not blocking associated IP transport sessions. For example, operators must ensure that interface IP addresses and ports configured on the node are not blocked and that remote host IP/port combinations are not blocked.
For IES/VPRN IP transport services, all tunnel types supported by the IES/VPRN service are also supported for the IP transport service. This includes all types of MPLS tunnels (such as RSVP-TE, LDP, auto-bind, static LSP) and GRE tunnels.
The 7705 SAR supports the concurrent operation of raw sockets and Cpipes on the 12-port Serial Data Interface card, version 2 and version 3. See Raw Socket and Cpipe Support on the 7705 SAR.
Remote Host Manual TCP Connection Check
A manual TCP connection check can be performed for each remote host configured for a raw socket IP transport subservice. When executed by an operator, the TCP connection check attempts to establish a TCP session toward the configured remote host. Only one TCP connection check attempt is made, with a fixed timeout of 5 s. If the attempt is successful, the session is torn down immediately without data being sent.
The TCP connection check is initiated in the CLI using the tools>perform>service>id>ip-transport>remote-host>check-tcp command. The result is displayed in the CLI using the tools>dump>service>id>ip-transport>remote-host>check-tcp command. Equivalent management is available via SNMP.
If a TCP connection to a remote host already exists due to serial traffic being transmitted, the check returns ‟successful” without impacting the existing TCP connection.
QoS Requirements for IP Transport
Serial raw socket data that is transported using an IP transport service can be DSCP marked and FC classified at the source node. This allows the source node (local host) of the traffic to mark packets correctly so that downstream nodes prioritize them as needed, and to queue local traffic in the right egress queue based on the classification assigned to the IP transport service.
Additionally, the DSCP setting is assigned per IP transport subservice for all traffic from the local host and all traffic destined for each remote host. The DCSP setting is not set per remote host.
See the dscp and fc commands under IES Raw Socket IP Transport Configuration Commands and VPRN Raw Socket IP Transport Configuration Commands for more information about configuring the QoS settings for an IES or VPRN IP transport subservice.
Service Creation Overview
Service Creation and Implementation Flowchart shows a flowchart that provides an overview of the process to create a service. Service creation can be separated into two main functional areas—core services tasks and subscriber services tasks. Core services tasks are performed prior to subscriber services tasks.
Before starting the process shown in Service Creation and Implementation Flowchart, ensure that the 7705 SAR system has been configured with an IP address and (for the 7705 SAR-8 Shelf V2 or 7705 SAR-18) has the appropriate adapter cards installed and activated.
Core services tasks include the following items:
create customer accounts
create template QoS and accounting policies
create LSPs
create SDPs
Subscriber services tasks include the following items:
create VLL (Apipe, Cpipe, Epipe, Fpipe, Hpipe, or Ipipe), IES, VPLS, or VPRN services
configure SAPs
bind SDPs
create exclusive QoS policies
(optionally) assign IP filter policies to Epipe SAPs, Ipipe SAPs, VPLS SAPs, VPRN interface SAPs, IES interface SAPs, and IES Management interface SAPs. IP filter policies can also be applied to VPLS SDPs (ingress mesh and spoke), and VPRN and IES interface ingress spoke SDPs.
(optionally) assign MAC ingress filter policies to VPLS SAPs and VPLS SDPs (mesh and spoke)
Port and SAP CLI Identifiers
When typing text in the command line interface (CLI), port-id is often displayed to indicate that a port identifier may need to be typed in the command line. Similarly, to identify a SAP, the port-id is used, but additional information may need to be appended to indicate a logical sub-element of the port.
On the CLI, a port-id is defined using the format slot/mda/port, where slot identifies the IOM card slot (always 1), mda identifies the physical slot in the chassis for the adapter card, and port identifies the physical port on the adapter card.
The value that can be appended to a SAP has the format [:ID], [.ID], [:ID/ID], or [:ID.ID]. The colon or dot and following ID identify a sub-element of the port (if applicable), such as a TDM channel group for a Cpipe, a VPI/VCI value for an Apipe, or a dot1q or qinq VLAN ID for an Epipe.
For example, a SAP associated with a TDM channel group on port 12 of a 16-port T1/E1 ASAP Adapter card in MDA slot 3 is identified as <1/3/12.3>, where ‟.3” is the appended value and identifies that for this SAP the channel group begins in timeslot 3.
Configuring Global Service Entities with CLI
This section provides information to create subscriber (customer) accounts and to configure service destination points (SDPs) using the command line interface.
Topics in this section include:
Service Model Entities
The Nokia service model uses (logical) service entities to construct a service. Each entity within the model has properties that describe it and influence its behavior. The service model has four main entities to configure a service. The entities are:
Customers
Service Destination Points (SDPs)
Service Types
Service Access Points (SAPs)
Basic Configuration
Before configuring a subscriber service, the QoS, logs, and MPLS LSPs (if applicable) must be configured. See to the following guides for more information:
7705 SAR Quality of Service Guide
7705 SAR Router Configuration Guide
7705 SAR System Management Guide
7705 SAR MPLS Guide
A basic service configuration must have the following items configured:
a customer ID
a service type
a service ID (a service-id number is mandatory and a service-name is optional)
a SAP identifying a port and encapsulation value
an interface (where required) identifying an IP address, IP subnet, and broadcast address
an associated SDP (for distributed services)
The following example shows an Epipe service configuration displaying the SDP and Epipe service entities. SDP ID 2 was created with the far-end node 10.10.10.104. Epipe ID 6000 was created for customer ID 6, which uses the SDP ID 2.
A:ALU-B>config>service# info detail
#------------------------------------------
...
sdp 2 mpls create
description "MPLS-10.10.10.104"
far-end 10.10.10.104
ldp
signaling tldp
no vlan-vc-etype
no path-mtu
keep-alive
shutdown
hello-time 10
hold-down-time 10
max-drop-count 3
timeout 5
no message-length
exit
no shutdown
exit
...
...
epipe 6000 customer 6 vpn 6000 create
service-mtu 1514
service-name ‟Epipe_6000”
sap 1/1/2:0 create
ingress
filter ip 1
qos 1
exit
egress
qos 1
exit
no shutdown
exit
spoke-sdp 2:6111 create
ingress
no vc-label
exit
egress
no vc-label
exit
no shutdown
exit
no shutdown
exit
...
#------------------------------------------
A:ALU-B>config>service#
Common Configuration Tasks
This section provides a brief overview of the following common configuration tasks that must be performed to configure a customer account and an SDP:
Configuring Customer Accounts
Use the customer command to configure customer information. Every customer account must have a customer ID. Optional parameters include:
description
contact name
telephone number
If special characters are included in the customer description string, such as spaces, #, or ?, the entire string must be enclosed in double quotes.
Use the following CLI syntax to create and input customer information.
- CLI Syntax:
config>service# customer customer-id createcontact contact-informationdescription description-stringphone phone-number
- Example:
config>service# customer 5 createconfig>service>cust# contact "Technical Support"config>service>cust$ description "Nokia Customer"config>service>cust# phone "650 555-5100"config>service>cust# exit
The following example displays the customer account configuration output.
A:ALU-12>config>service# info
-------------------------------------------
customer 5 create
contact "Technical Support"
description "Nokia Customer"
phone "650 555-5100"
exit
Configuring SDPs
When configuring an SDP, consider the following points.
SDPs can be configured for MPLS, GRE, or IP encapsulation.
If you do not specify an encapsulation type, the default is MPLS.
An SDP can have more than one service bound to it. That is, an SDP is not specific or exclusive to any one service or any type of service.
By default, SDPs are not associated with services. After an SDP is created, services can be associated with that SDP.
A distributed service must be bound to an SDP.
When configuring a distributed service, you must identify an SDP ID and the far-end IP address. Use the show>service>sdp command to display a list of qualifying SDPs.
If an SDP configuration does not include the IP address of the associated far-end router, VLL and VPLS services to the far-end router cannot be provided.
Up to eight RSVP-TE or SR-TE LSPs can be configured under a single MPLS-encapsulated SDP. However, a mix of RSVP-TE and SR-TE LSPs is not supported. RSVP-TE LSPs are configured using the config>service>sdp>lsp command and SR-TE LSPs are configured using the config>service>sdp> sr-te-lsp command.
For MPLS-encapsulated SDPs, LSPs must be configured before the LSP-to-SDP associations can be assigned. The LSP-to-SDP associations must be created explicitly.
LSPs are configured in the config>router>mpls context. See the 7705 SAR MPLS Guide for configuration and command information.
The destination address of the LSPs must match the far-end IP address of the SDP.
The far-end SDP IP address can be the system IP address of a 7705 SAR or an SR-series router, or loopback or network interface of the far-end router
When configuring MPLS SDP parameters, you can either specify up to eight RSVP-TE LSPs using the config>service>sdp>lsp command or enable LDP using the config>service>sdp>ldp command. There cannot be two methods of transport in a single SDP unless the mixed-lsp-mode option is selected (the lsp and ldp commands are mutually exclusive).
If mixed-lsp-mode is enabled and an LSP is specified, RSVP-TE is used for dynamic signaling in the LSP.
Automatic ingress and egress labeling (targeted LDP) is enabled by default. Ingress and egress VC labels are signaled over a targeted LDP connection between two 7705 SAR routers.
Note: If signaling is disabled for an SDP, ingress and egress vc-labels for the services using that SDP must be configured manually.
For a basic SDP configuration, perform the following steps:
Create an SDP ID.
Specify an encapsulation type.
Specify a far-end node.
The following examples show the CLI syntax for a basic MPLS SDP configuration. The first two show the syntax for configuring the SDP without mixed-lsp-mode enabled; one shows an RSVP-TE LSP configuration and the other shows an LDP configuration. The third example shows the syntax for configuring the SDP with mixed-lsp-mode enabled, with both an RSVP-TE LSP and LDP configured.
- CLI Syntax:
config>service>sdp sdp-id mpls createfar-end ip-addrlsp lsp-namekeep-aliveshutdownno shutdown
- Example:
config>service# sdp 100 mpls createconfig>service>sdp# far-end 10.10.10.10config>service>sdp# lsp "LSP1"config>service>sdp# no shutdownconfig>service>sdp# exit
The following example displays a basic SDP LSP configuration output.
*A:Sar18 Dut-B>config>service# info
----------------------------------------------
.....
sdp 100 create
no shutdown
far-end 10.10.10.10
lsp "LSP1"
keep-alive
shutdown
exit
exit
.....
-------------------------------------------
- CLI Syntax:
config>service>sdp sdp-id mpls createfar-end ip-addrldpkeep-aliveshutdownno shutdown
- Example:
config>service# sdp 300 mpls createconfig>service>sdp# far-end 10.10.10.10config>service>sdp# ldpconfig>service>sdp# no shutdownconfig>service>sdp# exit
The following example displays a basic SDP LDP configuration output.
*A:Sar18 Dut-B>config>service# info
----------------------------------------------
.....
sdp 300 create
far-end 10.10.10.10
ldp
keep-alive
shutdown
exit
no shutdown
exit
.....
-------------------------------------------
- CLI Syntax:
config>service>sdp sdp-id mpls createdescription description-stringfar-end ip-addrmixed-lsp-modeexitldplsp lsp-namekeep-aliveshutdownno shutdown
- Example:
config>service# sdp 1 mpls createconfig>service>sdp# description ‟SDI4”config>service>sdp# far-end 10.10.10.10config>service>sdp# mixed-lsp-modeconfig>service>sdp# exitconfig>service>sdp# ldpconfig>service>sdp# lsp "LSP1"config>service>sdp# no shutdownconfig>service>sdp# exit
The following example displays a basic SDP mixed-lsp-mode configuration output.
A:Sar18 Dut-B>config>service# info
----------------------------------------------
.....
sdp 1 create
description "SDI4"
far-end 10.10.10.10
mixed-lsp-mode
exit
ldp
lsp "LSP1"
keep-alive
shutdown
exit
no shutdown
exit
.....
----------------------------------------------
The following examples show the CLI syntax for a basic GRE SDP configuration.
- CLI Syntax:
config>service>sdp sdp-id gre createdescription description-stringfar-end ip-addrkeep-aliveshutdownno shutdown
- Example:
config>service# sdp 2 gre createconfig>service>sdp# description ‟GRE-10.10.10.10”config>service>sdp# far-end 10.10.10.10config>service>sdp# no shutdownconfig>service>sdp# exit
The following example displays a basic GRE SDP configuration output.
A:ALU-12>config>service# info
-------------------------------------------
.....
sdp 2 create
description "GRE-10.10.10.104"
far-end 10.10.10.104
keep-alive
shutdown
exit
no shutdown
.....
-----------------------------------------
A:ALU-12>config>service#
Enabling IP Fragmentation for GRE SDPs
Use the following CLI syntax to enable fragmentation of IP packets for GRE SDPs.
- CLI Syntax:
config>service>sdp sdp-id gre [create]allow-fragmentation
- Example:
config>service# sdp 2 gre createconfig>service>sdp# allow-fragmentation
Configuring Service Names
After a service has been created, it can be assigned a service name.
Use the following CLI syntax to assign a service name to a service. The syntax example is for an Epipe.
- CLI Syntax:
config>service>epipe# service-name service-name
- Example:
config>service# epipe 1 customer 1 createconfig>service>epipe# service-name ‟Epipe_1”
The following example displays the service name configuration output.
A:ALU-12>config>service>epipe# info
-------------------------------------------
...
shutdown
service-name "Epipe_1"
sdp 2 create
description "GRE-10.10.10.104"
far-end 10.10.10.104
keep-alive
shutdown
exit
no shutdown
exit
...
-----------------------------------------
A:ALU-12>config>service#
ETH-CFM (802.1ag and Y.1731) Tasks
This section provides a brief overview of the following ETH-CFM tasks:
Configuring ETH-CFM Parameters (802.1ag and Y.1731)
Configuration commands for both the 802.1ag and the Y.1731 functions are entered in an eth-cfm context (global or Epipe or VPLS service). For information about Ethernet OAM commands for 802.1ag and Y.1731 OAM, see the ‟Ethernet OAM Capabilities” section in the 7705 SAR OAM and Diagnostics Guide.
An 802.1ag MEP and a Y.1731 MEP are similar in function. Configure a MEP to be a Y.1731 MEP by choosing the format none keywords in the global domain command, and the format icc-based keywords in the global association command. Configure a MEP to be a Y.1731 MEP that can interoperate with a 802.1ag MEP by choosing the format none keywords in the global domain command, and the format string keywords in the global association command.
802.1ag Configuration
The first set of commands occurs at the global level. The second set occurs at the Epipe or VPLS service level.
*A:ALU-1>config>eth-cfm# info
----------------------------------------------
domain 1 name "kanata_MD" level 5
association 1 format string name "kanata_MA"
bridge-identifier 2
exit
ccm-interval 60
remote-mepid 125
exit
exit
----------------------------------------------
*A:ALU-1>config>service>epipe 2 customer 1 create
*A:ALU-1>config>service>epipe# info
----------------------------------------------
shutdown
sap 1/5/1 create
eth-cfm
mep 1 domain 1 association 1 direction down
shutdown
exit
exit
exit
spoke-sdp 1:11 create
eth-cfm
mep 2 domain 1 association 1 direction down
shutdown
exit
exit
exit
----------------------------------------------
*A:ALU-1>config>service>vpls 2 customer 1 create
*A:ALU-1>config>service>vpls# info
----------------------------------------------
shutdown
sap 1/2/1:0 create
eth-cfm
mep 1 domain 1 association 1 direction down
shutdown
exit
exit
exit
mesh-sdp 7:2 create
eth-cfm
mep 2 domain 1 association 1 direction down
shutdown
exit
exit
exit
----------------------------------------------
Y.1731 Configuration
The following example displays a Y.1731 configuration. The first set of commands occurs at the global level. The second set occurs at the Epipe or VPLS service level.
*A:ALU-1>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:ALU-1>config>service>epipe# info
----------------------------------------------
shutdown
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
...
----------------------------------------------
*A:ALU-1>config>service>vpls# info
----------------------------------------------
shutdown
sap 1/2/1:0 create
eth-cfm
mep 1 domain 1 association 1 direction up
ais-enable
interval 60
priority 2
exit
eth-test-enable
test-pattern all-ones crc-enable
exit
no shutdown
exit
exit
exit
no shutdown
...
----------------------------------------------
Applying ETH-CFM Parameters
Apply ETH-CFM parameters to the following entities, as shown in the CLI syntax examples below:
Epipe SAP
Epipe spoke SDP
VPLS SAP
VPLS spoke or mesh SDP
OAM tests (loopback, linktrace, Ethernet test, delay measurement, loss measurement, synthetic loss measurement)
The MAC address for a MEP on an Epipe SAP or on an Epipe or VPLS SDP cannot be changed. For a MEP on an Epipe SAP, the MAC address is the port MAC address. For a MEP on an Epipe or VPLS SDP, the MAC address is the system MAC address. The MAC address for a MEP on a VPLS SAP can be changed; the default is the port MAC address.
The 7705 SAR supports the following MEPs for both 802.1ag and Y.1731:
SAP Up and Down MEPs
spoke SDP Up and Down MEPs
mesh SDP Up and Down MEPs (VPLS only)
The following two syntax examples are for an Epipe service. Configuration for VPLS is the same except that the hold-mep-up-on-failure and dual-ended-loss-test-enable parameters are not supported on VPLS SAPs.
The third syntax shows the OAM tests that can be applied to MEPs.
- CLI Syntax:
config>service>epipe>sapeth-cfmhold-mep-up-on-failuremep mep-id domain md-index association ma-index [direction {up | down}]ais-enableccm-enableccm-ltm-priority prioritydual-ended-loss-test-enableeth-test-enablelow-priority-defect {allDef|macRemErrXcon| remErrXcon|errXcon|xcon|noXcon}one-way-delay-threshold seconds[no] shutdownconfig>service>epipe>spoke-sdpeth-cfmmep mep-id domain md-index association ma-index [direction {up | down}]ccm-enableccm-ltm-priority prioritylow-priority-defect {allDef|macRemErrXcon| remErrXcon|errXcon|xcon|noXcon}[no] shutdownoameth-cfm eth-test mac-address mep mep-id domain md-index association ma-index [priority priority] [data-length data-length]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 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 single-ended-loss-test mac-address mep mep-id domain md-index association ma-index [priority priority] [interval interval] [send-count send-count]eth-cfm two-way-slm-test mac-address mep mep-id domain md-index association ma-index [priority priority] [send-count send-count] [size data-size] [timeout timeout] [interval interval]
Service Management Tasks
This section provides a brief overview of the following service management tasks:
Modifying Customer Accounts
Use the show>service>customer command to display a list of customer IDs.
To modify a customer account:
Access the specific account by specifying the customer ID.
Enter the parameter to modify (description, contact, phone) and then enter the new information.
- CLI Syntax:
config>service# customer customer-id create[no] contact contact-information[no] description description-string[no] phone phone-number
- Example:
config>service# customer 27 createconfig>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 typically removes a customer ID and all associated information; however, all service references to the customer must be shut down and deleted before a customer account can be deleted.
- CLI Syntax:
config>service# no customer customer-id
- Example:
config>service# epipe 5 customer 27 shutdownconfig>service# epipe 9 customer 27 shutdownconfig>service# no epipe 5config>service# no epipe 9config>service# no customer 27
Modifying SDPs
Use the show>service>sdp command to display a list of SDP IDs.
To modify an SDP:
Access the specific SDP by specifying the SDP ID.
Enter the parameter to modify, such as description, far-end, or lsp, and then enter the new information.
- CLI Syntax:
config>service# sdp sdp-id
- Example:
config>service# sdp 79config>service>sdp# description ‟Path-to-107”config>service>sdp# shutdownconfig>service>sdp# far-end ‟10.10.10.107”config>service>sdp# path-mtu 1503config>service>sdp# no shutdown
Deleting SDPs
The no form of the sdp command typically removes an SDP ID and all associated information; however, before an SDP can be deleted, the SDP must be shut down and removed (unbound) from all customer services where it is applied.
- CLI Syntax:
config>service# no sdp 79
- Example:
config>service# epipe 5 spoke-sdp 79:5config>service>epipe>spoke-sdp# shutdownconfig>service>epipe>spoke-sdp# exitconfig>service>epipe 5 no spoke-sdp 79:5config>service>epipe# exitconfig>service# no sdp 79
Deleting LSP Associations
The no form of the lsp command removes an LSP ID and all associated information; however, before an LSP can be deleted, it must be removed from all SDP associations.
- CLI Syntax:
config>service# sdp sdp-id[no] lsp lsp-name
- Example:
config>service# sdp 79config>service>sdp# no lsp 123config>service>sdp# exit all
Global Service Command Reference
Command Hierarchies
Global Service Configuration Commands
Customer Commands
config
- service
- customer customer-id [create]
- no customer customer-id
- customer contact-information
- no customer
- description description-string
- no description
- customer phone-number
- [no] customer
SDP Commands
config
- service
- sdp sdp-id [gre | mpls | ip] [create]
- no sdp sdp-id
- [no] adv-mtu-override
- [no] allow-fragmentation
- [no] bgp-tunnel
- description description-string
- no description
- encryption-keygroup keygroup-id direction {inbound | outbound}
- no encryption-keygroup direction {inbound | outbound}
- far-end [ip-address | ipv6-address]
- no far-end
- keep-alive
- hello-time seconds
- no hello-time
- hold-down-time seconds
- no hold-down-time
- max-drop-count count
- no max-drop-count
- message-length octets
- no message-length
- [no] shutdown
- timeout timeout
- no timeout
- [no] ldp
- [no] lsp lsp-name
- metric metric
- no metric
- [no] mixed-lsp-mode
- revert-time {revert-time | infinite}
- no revert-time
- path-mtu bytes
- no path-mtu
- [no] shutdown
- signaling {off | tldp}
- [no] sr-isis
- [no] sr-ospf
- [no] sr-te-lsp lsp-name
- vlan-vc-etype 0x0600..0xffff
- no vlan-vc-etype [x0600.0xffff]
- [no] weighted-ecmp
SAP Commands
config
- service
- apipe
- sap sap-id [create]
- no sap sap-id
- cpipe
- sap sap-id [create]
- no sap sap-id
- epipe
- sap sap-id [create]
- no sap sap-id
- fpipe
- sap sap-id [create]
- no sap sap-id
- hpipe
- sap sap-id [create]
- no sap sap-id
- ipipe
- sap sap-id [create]
- no sap sap-id
- ies
- interface ip-int-name [create]
- sap sap-id [create]
- no sap sap-id
- vprn
- interface ip-int-name [create]
- sap sap-id [create]
- no sap sap-id
- vpls
- sap sap-id [create]
- no sap sap-id
- system
- ethernet
- [no] new-qinq-untagged-sap
Ethernet Ring Commands
config
- [no] eth-ring ring-index
- ccm-hold-time [down down-timeout] [up up-timeout]
- no ccm-hold-time
- compatible-version version
- no compatible-version
- description description-string
- no description
- guard-time time
- no guard-time
- node-id xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx
- no node-id
- path {a | b} [{port-id| lag-id | mw-link-id} raps-tag qtag1[.qtag2]]
- no path {a | b}
- description description-string
- no description
- eth-cfm
- [no] mep mep-id domain md-index association ma-index
- [no] ccm-enable
- ccm-ltm-priority priority
- no ccm-ltm-priority
- [no] control-mep
- description description-string
- no description
- no eth-test-enable
- bit-error-threshold bit-errors
- test-pattern {all-zeros | all-ones} [crc-enable]
- no test-pattern
- low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
- one-way-delay-threshold seconds
- [no] shutdown
- [no] rpl-end
- [no] shutdown
- revert-time time
- no revert-time
- rpl-node {owner | nbr}
- no rpl-node
- [no] shutdown
- [no] sub-ring {virtual-link | non-virtual-link}
- interconnect ring-id ring-index
- interconnect vpls
- [no] interconnect
- [no] propagate-topology-change
ETH-CFM Commands
config
- eth-cfm
- domain md-index [format {dns | mac | none | string}] name md-name level level
- domain md-index
- no domain md-index
- association ma-index [format {icc-based | integer | string | vid | vpn-id}] name ma-name
- association ma-index
- no association ma-index
- [no] bridge-identifier bridge-id
- vlan vlan-id
- no vlan
- ccm-interval {10ms | 100ms | 1 | 10 | 60 | 600}
- no ccm-interval
- [no] remote-mepid mep-id
- slm
- inactivity-timer timeout
- no inactivity-timer
Show Commands
show
- eth-ring [status]
- eth-ring [ring-index] hierarchy
- eth-ring ring-index [path {a | b}]
- service
- customer customer-id
- sdp sdp-id keep-alive-history
- sdp [sdp-id] [detail]
- sdp far-end ip-addr keep-alive-history
- sdp far-end ip-addr [detail]
- sdp-using sdp-id[:vc-id] | far-end ip-address]
- service-using [epipe] [fpipe] [hpipe] [ies] [vprn] [mirror] [vpls] [apipe] [cpipe] [sdp sdp-id] [customer customer-id]
Monitor Commands
monitor
- service
- id service-id
- sap sap-id [interval seconds] [repeat repeat] [absolute | rate]
- sap-aggregation-group group-id [interval seconds] [repeat repeat] [absolute | rate]
Command Descriptions
Global Service Configuration Commands
Generic Commands
description
Syntax
description description-string
no description
Context
config>service>customer
config>service>sdp
config>eth-ring
config>eth-ring>path
config>eth-ring>path>eth-cfm>mep
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 context.
Default
No description is associated with the configuration context.
Parameters
- description-string
the description character string. Allowed values are any string up to 80 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (such as #, $, or spaces), the entire string must be enclosed within double quotes.
shutdown
Syntax
[no] shutdown
Context
config>service>sdp
config>service>sdp>keep-alive
Description
The shutdown command administratively disables an entity. The operational state of the entity is disabled as well as the operational state of any entities contained within. When disabled, an entity does not change, reset, or remove any configuration settings or statistics. Many objects must be shut down before they may be deleted. Many entities must be explicitly enabled using the no shutdown command.
The no form of this command places the entity into an administratively enabled state.
Services are created in the administratively down state (shutdown). When a no shutdown command is entered, the service becomes administratively up and then tries to enter the operationally up state. Default administrative states for services and service entities are described in the following Special Cases.
Special Cases
- Service Admin State
bindings to an SDP within the service will be put into the out-of-service state when the service is shut down. While the service is shut down, all customer packets are dropped and counted as discards for billing and debugging purposes.
- SDP (global)
when an SDP is shut down at the global service level, all bindings to that SDP are put into the out-of-service state and the SDP itself is put into the administratively and operationally down states. Packets that would normally be transmitted using this SDP binding will be 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.
new-qinq-untagged-sap
Syntax
[no] new-qinq-untagged-sap
Context
config>system>ethernet
Description
This command controls the behavior of qinq SAP y.0 (for example, 1/1/1:3000.0). If this command is enabled, the y.0 SAP maps all ingress frames tagged with outer tag VLAN ID of y (qinq Ethertype) and no inner tag, or with an inner tag VLAN ID of zero (0). This behavior applies to all existing and future y.0 SAPs.
The no form of this command disables qinq untagged SAP, and the y.0 SAP will work like a y.* SAP (for example, 1/1/1:3000.*); all frames tagged with outer VLAN y and no inner VLANs, or inner VLAN x, where inner VLAN x is not specified in a SAP y.x configured on the same port (for example, 1/1/1:3000.10).
Default
no new-qinq-untagged-sap. This setting ensures that there will be no disruption for existing usage of this SAP type.
Customer Commands
customer
Syntax
customer customer-id [create]
no customer customer-id
Context
config>service
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 and the create keyword must follow each new customer customer-id entry.
To edit a customer’s parameters, enter the existing customer customer-id without the create keyword.
Default customer 1 always exists on the system and cannot be deleted.
The no form of this command removes a customer-id and all associated information. Before removing a customer-id, all references to that customer in all services must be deleted or changed to a different customer ID.
Parameters
- customer-id
specifies the ID number to be associated with the customer, expressed as an integer
contact
Syntax
contact contact-information
no contact
Context
config>service>customer
Description
This command allows you to configure contact information for a customer. Include any customer-related contact information such as a technician’s name or account contract name.
The no form of this command removes the contact information from the customer ID.
Default
No contact information is associated with the customer-id.
Parameters
- contact-information
the customer contact information entered as an ASCII character string. Allowed values are any string up to 80 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (such as #, $, or spaces), the entire string must be enclosed within double quotes.
phone
Syntax
[no] phone phone-number
Context
config>service>customer
Description
This command adds telephone number information for a customer ID.
The no form of this command removes the phone number value from the customer ID.
Default
No telephone number information is associated with a customer.
Parameters
- phone-number
the customer phone number entered as an ASCII string. Allowed values are any string up to 80 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (such as #, $, or spaces), the entire string must be enclosed within double quotes.
SDP Commands
sdp
Syntax
sdp sdp-id [gre | mpls | ip] [create]
no sdp sdp-id
Context
config>service
Description
This command creates or edits an SDP. SDPs must be explicitly configured.
An SDP is a (logical) service entity that is created on the local router. An SDP identifies the endpoint of a logical, unidirectional service tunnel. Traffic enters the tunnel at the SDP on the local router and exits the tunnel at the remote router. Thus, it is not necessary to specifically define far-end SAPs.
The 7705 SAR supports generic routing encapsulation (GRE) tunnels, multiprotocol label switching (MPLS) tunnels, and IP tunnels.
For MPLS, the 7705 SAR 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 LSPs are established in LDP-DU (downstream unsolicited) mode. Segment routing (SR) is another MPLS tunnel type and is used to allow service binding to an SR tunnel programmed in the tunnel table manager (TTM) by OSPF or IS-IS. An SDP of type sr-isis or sr-ospf can be used with the far-end option.
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. SDPs are created in the admin down state (shutdown). After all relevant parameters are defined, the no shutdown command must be executed before the SDP can be used.
If sdp-id exists, the current CLI context is changed to that SDP for editing and modification. If editing an existing SDP, the gre, mpls, or ip keyword is not specified. If a keyword is specified for an existing sdp-id, an error is generated and the context of the CLI is not changed to the specified sdp-id.
The no form of this command deletes the specified SDP. Before an SDP can be deleted, it must be administratively down (shutdown) and not bound to any services. If the specified SDP is bound to a service, the no sdp command fails, generating an error message specifying the first bound service found during the deletion process. If the specified sdp-id does not exist, an error is generated.
Default
n/a
Parameters
- sdp-id
the SDP identifier
- gre
specifies that the SDP will use GRE encapsulation tunnels. Only one GRE SDP is supported to a given destination 7705 SAR or 7750 SR.
- mpls
specifies that the SDP will use MPLS encapsulation and one or more LSP tunnels to reach the far-end 7705 SAR or 7750 SR. Multiple MPLS SDPs are supported to a given destination service router. Multiple MPLS SDPs to a single destination service router are helpful when they use divergent paths.
- ip
specifies that the SDP will use IP encapsulation tunnels. Only one IP SDP is supported to a given destination 7705 SAR because the SDP is tied to the system address of the destination LER.
adv-mtu-override
Syntax
[no] adv-mtu-override
Context
config>service>sdp
Description
This command overrides the advertised VC-type MTU. When enabled, the 7705 SAR signals a VC MTU equal to the service MTU that includes the Layer 2 header. Under normal operations it will advertise the service MTU minus the Layer 2 header. In the receive direction, it will accept either one.
The no form of this command disables the VC-type MTU override.
Default
no adv-mtu-override
allow-fragmentation
Syntax
[no] allow-fragmentation
Context
config>service>sdp
Description
This command enables GRE-encapsulated packets transmitted from the SDP to be fragmented if their size exceeds the configured network port MTU.
When allow-fragmentation is enabled, GRE-encapsulated packets that are larger than the network port MTU are fragmented and the DF bit is set to 0 by the router. Packets that are smaller than the port MTU are left unfragmented, the DF bit is set to 1 by the router, and the identification number of the packet is set to 0.
Fragmentation is supported on an SDP that has NGE (encryption-keygroup) enabled. To determine if an encrypted packet needs to be fragmented, the system compares the total packet size after NGE encryption to the network port MTU. If the encrypted packet size is larger than the MTU, the packet is fragmented. NGE decryption is performed after the packet is fully reassembled.
The no form of the command disables fragmentation of oversize GRE-encapsulated packets transmitted from the SDP.
Default
no allow-fragmentation
bgp-tunnel
Syntax
[no] bgp-tunnel
Context
config>service>sdp
Description
This command allows the use of BGP route tunnels available in the tunnel table to reach SDP far-end nodes. BGP route tunnels are only available with MPLS SDPs. Only one transport method is allowed per SDP: LDP, RSVP-LSP, BGP-tunnel, SR-ISIS, SR-OSPF, or SR-TE-LSP. This restriction is relaxed for some combinations of the transport methods when the mixed-LSP mode option is enabled on the SDP.
The no form of the command disables the use of BGP route tunnels for the SDP far end.
Default
no bgp-tunnel
encryption-keygroup
Syntax
encryption-keygroup keygroup-id direction {inbound | outbound}
no encryption-keygroup direction {inbound | outbound}
Context
config>service>sdp
Description
This command is used to bind a key group to an SDP for inbound or outbound packet processing. When configured in the outbound direction, packets egressing the node use the active-outbound-sa associated with the key group configured. When configured in the inbound direction, received packets must be encrypted using one of the valid security associations configured for the key group. Services using the SDP will be encrypted.
Encryption is enabled once the outbound direction is configured.
The no form of the command removes the key group from the SDP in the specified direction (inbound or outbound).
Default
n/a
Parameters
- keygroup-id
the number of the key group being configured
- direction {inbound | outbound}
mandatory keywords when binding a key group to a service for a particular direction
far-end
Syntax
far-end [ip-address|ipv6-address]
no far-end
Context
config>service>sdp
Description
This command configures the system IP address of the far-end destination 7705 SAR, 7750 SR, or other router ID platform for the SDP that is the termination point for a service.
The far-end IP address must be explicitly configured. The destination IP address must be a 7705 SAR, 7750 SR, or other router ID platform system IP address.
If the SDP uses GRE or IP for the destination encapsulation, the local 7705 SAR may not know that the ip-address is actually a system IP interface address on the far-end service router.
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 will not be added to the SDP and an error message will be generated.
An SDP cannot be administratively enabled until a far-end ip-address is defined. The SDP is operational when it is administratively enabled (no shutdown).
The no form of this command removes the currently configured destination IP address for the SDP. The ip-address and ipv6-address parameters are not specified and will generate an error message 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 will cause all lsp-name associations with the SDP to be removed.
Default
n/a
Parameters
- ip-address
the IPv4 address of the far-end destination router for the SDP
- ipv6-address
the IPv6 address of the far-end destination router for the SDP
ldp
Syntax
[no] ldp
Context
config>service>sdp
Description
This command enables LDP-signaled LSPs on MPLS-encapsulated SDPs.
In MPLS SDP configurations, up to eight RSVP-TE LSPs can be specified or LDP can be enabled. The SDP ldp and lsp commands are mutually exclusive unless mixed-LSP SDP is enabled with the mixed-lsp-mode command.
If mixed-LSP SDP is not enabled and 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.
Default
no ldp (disabled)
lsp
Syntax
[no] lsp lsp-name
Context
config>service>sdp
Description
This command creates an association between an LSP and an MPLS SDP. This command is implemented only on MPLS-encapsulated SDPs. Up to eight RSVP-TE LSPs can be associated with a single SDP. The LSPs must have already been created in the config>router>mpls context with a valid far-end IP address. See the 7705 SAR MPLS Guide for CLI syntax and command usage.
In MPLS SDP configurations, LSPs can be specified or LDP can be enabled. The SDP ldp and lsp commands are mutually exclusive unless mixed-LSP SDP is enabled with the mixed-lsp-mode command.
If mixed-LSP SDP is not enabled and LDP is already enabled on an MPLS SDP, an LSP cannot be specified on the SDP. To specify an LSP on the SDP, LDP must be disabled.
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 can be shut down, causing the association with the SDP to be operationally down (the LSP will not be used by the SDP).
LSP SDPs also require that the T-LDP signaling be specified and that the SDP keepalive parameter be enabled and not timed out.
The no form of this command deletes an LSP association from an SDP. If the lsp-name does not exist as an association or as a configured LSP, no error is returned. An lsp-name must be removed from all SDP associations before the lsp-name can be deleted from the system. The SDP must be administratively disabled (shutdown) before the last lsp-name association with the SDP is deleted.
Default
No LSP names are defined.
Parameters
- lsp-name
the name of the LSP to associate with the SDP
metric
Syntax
metric metric
no metric
Context
config>service>sdp
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 tiebreaker by tunnel table manager users to select the route with the lower value.
Parameters
- metric
specifies the SDP metric
mixed-lsp-mode
Syntax
[no] mixed-lsp-mode
Context
config>service>sdp
Description
This command enables the mixed-LSP mode of operation on an SDP, which allows a primary LSP type and a backup LSP type in the same SDP configuration. For example, RSVP-TE LSPs and LDP LSPs can be configured on an SDP with the lsp and ldp commands. If mixed-LSP mode is not enabled, these commands are mutually exclusive.
Two combinations of mixed LSPs are possible:
an RSVP-TE primary LSP backed up by an LDP LSP
an LDP primary LSP backed up by a BGP LSP
The no form of this command disables mixed-LSP; however you must remove one of the LSP types from the SDP configuration first or the command will fail.
revert-time
Syntax
revert-time {revert-time | infinite}
no revert-time
Context
config>service>sdp>mixed-lsp-mode
Description
This command configures the length of time that the service manager must wait before it resets the SDP configuration 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 that the service manager resets the SDP configuration immediately to a higher-priority LSP type when one becomes available.
Default
0
Parameters
- seconds
the time, in seconds, to wait before reverting to a higher-priority LSP type when one becomes available.
- infinite
the service manager never resets the SDP configuration to the highest-priority LSP type unless the currently active LSP fails
path-mtu
Syntax
path-mtu bytes
no path-mtu
Context
config>service>sdp
Description
This command configures the Maximum Transmission Unit (MTU) in bytes that the SDP can transmit to the far-end router without packet dropping or IP fragmentation overriding the default SDP-type path MTU.
The default SDP-type path-mtu can be overridden on a per-SDP basis.
Dynamic maintenance protocols on the SDP may override this setting.
If the physical mtu on an egress interface indicates that the next hop on an SDP path cannot support the current path-mtu, the operational path-mtu on that SDP will be 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 will use the system default for the SDP type.
Default
The default path-mtu defined on the system for the type of SDP is used.
Parameters
- bytes
specifies the number of bytes in the path MTU
signaling
Syntax
signaling {off | tldp}
Context
config>service>sdp
Description
This command specifies the signaling protocol used to obtain the ingress and egress labels in frames transmitted and received on the SDP. When signaling is off, then labels are manually configured when the SDP is bound to a service. The signaling value can only be changed while the administrative status of the SDP is down.
The no form of this command is not applicable. To modify the signaling configuration, the SDP must be administratively shut down and then the signaling parameter can be modified and re-enabled.
Default
tldp
Parameters
- off
ingress and egress signal auto-labeling is not enabled. If this parameter is selected, then each service using the specified SDP must manually configure VPN labels. This configuration is independent of the SDP transport type, MPLS (LDP).
- tldp
ingress and egress signaling auto-labeling is enabled
sr-isis
Syntax
[no] sr-isis
Context
config>service>sdp
Description
This command configures an MPLS SDP of LSP type IS-IS segment routing. The SDP of LSP type sr-isis can be used with the far-end option. The signaling protocol for the service labels for an SDP using an SR tunnel can be configured to static (off) or T-LDP (tldp).
Default
no sr-isis
sr-ospf
Syntax
[no] sr-ospf
Context
config>service>sdp
Description
This command configures an MPLS SDP of LSP type OSPF segment routing. The SDP of LSP type sr-ospf can be used with the far-end option. The signaling protocol for the service labels for an SDP using an SR tunnel can be configured to static (off) or T-LDP (tldp).
Default
no sr-ospf
sr-te-lsp
Syntax
[no] sr-te-lsp lsp-name
Context
config>service>sdp
Description
This command configures an MPLS SDP of LSP type SR-TE. Up to eight SR-TE LSPs can be configured under an SDP.
The mixed-lsp-mode option does not support the sr-te tunnel type.
The signaling protocol for the service labels for an SDP using an SR-TE LSP can be configured to static (off) or T-LDP (tldp).
Default
none
Parameters
- lsp-name
the name of an LSP that has already been created
vlan-vc-etype
Syntax
vlan-vc-etype 0x0600..0xffff
no vlan-vc-etype [0x0600..0xffff]
Context
config>service>sdp
Description
This command configures the VLAN VC Ethertype. The no form of this command returns the value to the default. The etype value populates the Ethertype field in the Ethernet frame. It is used to indicate which protocol is being transported in the Ethernet frame. The default value indicates that the payload is an IEEE 802.1q-tagged frame.
Default
no vlan-vc-etype (0x8100)
Parameters
- 0x0600..0xffff
specifies a valid VLAN etype identifier
weighted-ecmp
Syntax
[no] weighted-ecmp
Context
config>service>sdp
Description
This command enables weighted ECMP for IES or VPRN Layer 3 spoke SDP interfaces. This command is applicable when the SDP has RSVP-TE LSPs configured using the config>service>sdp>lsp command or SR-TE LSPs configured using the config>service>sdp>sr-te-lsp command.
When weighted ECMP is enabled on an SDP, a path is selected based on the configured hash. Paths are then load-balanced across the LSPs used by the SDP according to the normalized LSP load-balancing weight configured using the load-balancing-weight command described in the 7705 SAR MPLS Guide, ‟MPLS Commands”. This means that consecutive packets of a particular service use the same LSP, but the overall load handled by LSPs to the SDP far end is balanced according to the load-balancing weight if all services using the SDP send the same bandwidth and there are more services using the SDP than there are LSPs for the SDP.
If an LSP in the ECMP set has no load-balancing weight configured, then ECMP is applied to packets based on the output of the hash for the service ID.
The no form of the command disables weighted ECMP for the SDP.
Default
no weighted-ecmp
SDP Keepalive Commands
keep-alive
Syntax
keep-alive
Context
config>service>sdp
Description
This command is 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 will immediately be brought operationally down. After a response is received that indicates the error has cleared and the hold-down-time interval has expired, the SDP ID will be eligible to be put into the operationally up state. If no other condition prevents the operational change, the SDP ID will enter 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.
SDP Echo Reply Response Conditions describes keepalive interpretation of SDP Echo Reply response conditions and the effect on the SDP ID operational status.
Result of Request |
Stored Response State |
Operational State |
|---|---|---|
keepalive request timeout without reply |
Request Timeout |
Down |
keepalive request not sent due to non-existent orig-sdp-id 1 |
Orig-SDP Non-Existent |
Down |
keepalive request not sent due to 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) |
Note:
This condition should not occur.
hello-time
Syntax
hello-time seconds
no hello-time
Context
config>service>sdp>keep-alive
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 resets the hello-time seconds value to the default setting.
Parameters
- seconds
the time period in seconds between SDP keepalive messages, expressed as a decimal integer
hold-down-time
Syntax
hold-down-time seconds
no hold-down-time
Context
config>service>sdp>keep-alive
Description
This command configures the minimum time period the SDP will remain in the operationally down state in response to SDP keepalive monitoring.
This parameter can be used to prevent the SDP operational state from ‟flapping” by rapidly transitioning between the operationally up and operationally down states based on keepalive messages.
When an SDP keepalive response is received that indicates an error condition or the max-drop-count keepalive messages receive no reply, the sdp-id will immediately be brought operationally down. If a keepalive response is received that indicates the error has cleared, the sdp-id will be eligible to be put into the operationally up state only after the hold-down-time interval has expired.
The no form of this command resets the hold-down-time seconds value to the default setting.
Parameters
- seconds
the time in seconds, expressed as a decimal integer, the sdp-id will remain in the operationally down state after an SDP keepalive error before it is eligible to enter the operationally up state. A value of 0 indicates that no hold-down-time will be enforced for sdp-id.
max-drop-count
Syntax
max-drop-count count
no max-drop-count
Context
config>service>sdp>keep-alive
Description
This command configures the number of consecutive SDP keepalive failed request attempts or remote replies that can be missed after which the SDP is operationally downed.
If the max-drop-count consecutive keepalive request messages cannot be sent or no replies are received, the SDP-ID will be brought operationally down by the keepalive SDP monitoring.
The no form of this command resets the max-drop-count count value to the default settings.
Parameters
- count
the number of consecutive SDP keepalive requests that can fail to be sent or replies missed before the SDP is brought down, expressed as a decimal integer
message-length
Syntax
message-length octets
no message-length
Context
config>service>sdp>keep-alive
Description
This command configures the size of SDP monitoring keepalive request messages transmitted on the SDP.
The no form of this command resets the message-length octets value to the default setting.
Parameters
- octets
the size of keepalive request messages in octets, expressed as a decimal integer. The size keyword overrides the default keepalive message size.
The message length should be equal to the SDP operating path MTU as configured in the path-mtu command.
If the default size is overridden, the actual size used will be the smaller of the operational SDP-ID path MTU and the size specified.
timeout
Syntax
timeout timeout
no timeout
Context
config>service>sdp>keep-alive
Description
This command configures the time interval that the SDP waits before tearing down the session.
Parameters
- timeout
the timeout in seconds, expressed as a decimal integer
Ethernet Ring Commands
eth-ring
Syntax
[no] eth-ring ring-index
Context
config
Description
This command configures a G.8032 Ethernet ring. Ethernet rings may be configured as major rings with two paths (A and B), as sub-rings with two paths, or in the case of an interconnection node, a single path.
The no form of this command deletes the specified Ethernet ring.
Default
no eth-ring
Parameters
- ring-index
specifies the Ethernet ring ID
ccm-hold-time
Syntax
ccm-hold-time [down down-timeout] [up up-timeout]
no ccm-hold-time
Context
config>eth-ring
Description
This command configures Ethernet ring dampening timers.
The no form of the command sets the up and down timers to the default values.
Default
down 0
up 20
Parameters
- down-timeout
specifies the down timeout, in centiseconds
- up-timeout
specifies the hold-time for reporting the recovery, in deciseconds
compatible-version
Syntax
compatible-version version
no compatible-version
Context
config>eth-ring
Description
This command configures Ethernet ring compatibility version for the G.8032 state machine and messages. The default is version 2 and all router switches use version 2. The version can be changed if there is a need to interwork with third party devices that only support version 1.
The no form of this command sets the compatibility version to 2.
Default
2
Parameters
- version
specifies the version of the G.8032 state machine
guard-time
Syntax
guard-time time
no guard-time
Context
config>eth-ring
Description
This command configures the guard time for an Ethernet ring.
The no form of this command restores the default guard time.
Default
5
Parameters
- value
specifies the guard time, in deciseconds
node-id
Syntax
node-id xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx
no node-id
Context
config>eth-ring
Description
This optional command configures the MAC address of the RPL link. The default is to use the chassis MAC address for the ring control. This command allows the chassis MAC address to be overridden with another MAC address.
The no form of the command removes the RPL link.
Default
no node-id
Parameters
- xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx
specifies the MAC address
path
Syntax
path {a | b} [{port-id | lag-id| mw-link-id} raps-tag qtag1[.qtag2]]
no path {a | b}
Context
config>eth-ring
Description
This command assigns the Ethernet ring (major or sub-ring) path to a port and defines the Ethernet ring APS tag. Rings typically have two paths, A or B.
The no form of this command removes the configured path.
Default
no path
Parameters
- port-id
the port ID
- lag-id
the LAG ID
- mw-link-id
specifies the microwave link ID number, using the form mw-link-num
- raps-tag
the Ethernet ring member’s encapsulation
- qtag1
specifies the top or outer VLAN ID
- qtag2
specifies the bottom or inner VLAN ID
eth-cfm
Syntax
eth-cfm
Context
config>eth-ring>path
Description
This command enables the context to configure Ethernet CFM parameters.
mep
Syntax
[no] mep mep-id domain md-index association ma-index
Context
config>eth-ring>path>eth-cfm
Description
This command provisions an 802.1ag maintenance endpoint (MEP).
The no form of the command deletes the MEP.
Parameters
- mep-id
specifies the MEP identifier
- md-index
specifies the MD index value
- ma-index
specifies the MA index value
ccm-enable
Syntax
[no] ccm-enable
Context
config>eth-ring>path>eth-cfm>mep
Description
This command enables the generation of CCM messages.
The no form of the command disables the generation of CCM messages.
Default
no ccm-enable
ccm-ltm-priority
Syntax
ccm-ltm-priority priority
no ccm-ltm-priority
Context
config>eth-ring>path>eth-cfm>mep
Description
This command specifies the priority value for CCMs and LTMs transmitted by the MEP.
The no form of the command removes the priority value from the configuration.
Default
The highest priority on the bridge port.
Parameters
- priority
specifies the priority of CCM and LTM messages
control-mep
Syntax
[no] control-mep
Context
config>eth-ring>path>eth-cfm>mep
Description
This command enables Ethernet ring control on the MEP. Configuration of this command is mandatory for a ring. MEP detection of failure using CCM can be enabled or disabled independently of the control MEP.
The no form of this command disables Ethernet ring control.
Default
no control-mep
eth-test-enable
Syntax
[no] eth-test-enable
Context
config>eth-ring>path>eth-cfm>mep
Description
This command enables Ethernet test functionality on the MEP. For the test to work, operators need to configure Ethernet test parameters on both the sender and receiver nodes. The Ethernet test can be performed using the oam>eth-cfm>eth-test command.
A check is done for both the provisioning and the test to ensure the MEP is a Y.1731 MEP, provisioned with domain format none and associated with format icc-based. If they are not, the command fails and an error message is generated in the CLI and SNMP indicating the problem.
Default
no eth-test-enable
bit-error-threshold
Syntax
bit-error-threshold bit-errors
Context
config>eth-ring>path>eth-cfm>mep>eth-test-enable
Description
This command specifies the lowest priority defect that is allowed to generate a fault alarm.
Default
1
Parameters
- bit-errors
specifies the lowest priority defect
test-pattern
Syntax
test-pattern {all-zeros | all-ones} [crc-enable]
no test-pattern
Context
config>eth-ring>path>eth-cfm>mep>eth-test-enable
Description
This command configures the test pattern for Ethernet test frames.
The no form of the command removes the test pattern from the Ethernet test configuration.
Default
all-zeros
Parameters
- all-zeros
configures the test pattern with all zeros
- all-ones
configures the test pattern with all ones
- crc-enable
generates a CRC checksum
low-priority-defect
Syntax
low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
Context
config>eth-ring>path>eth-cfm>mep
Description
This command specifies the lowest priority defect that will generate a fault alarm.
Default
remErrXcon
Parameters
- allDef
all defects (DefRDICCM, DefMACstatus, DefRemoteCCM, DefErrorCCM, and DefXconCCM) generate a fault alarm
- macRemErrXcon
DefMACstatus, DefRemoteCCM, DefErrorCCM, and DefXconCCM generate a fault alarm
- remErrXcon
DefRemoteCCM, DefErrorCCM, and DefXconCCM generate a fault alarm
- errXcon
DefErrorCCM and DefXconCCM generate a fault alarm
- xcon
DefXconCCM generates a fault alarm
- noXcon
no defects DefXcon or lower generate a fault alarm
one-way-delay-threshold
Syntax
one-way-delay-threshold seconds
Context
config>eth-ring>path>eth-cfm>mep
Description
This command configures a one-way delay threshold time limit.
Default
3
Parameters
- seconds
the threshold value, in seconds
rpl-end
Syntax
[no] rpl-end
Context
config>eth-ring>path
Description
This command configures the G.8032 path as a ring protection link (RPL) end. The ring must be declared as either an RPL owner or an RPL neighbor in order for this command to be valid. Only a path configured as A or B can be configured as an RPL end.
The no form of this command reverts to the default.
Default
no rpl-end
revert-time
Syntax
revert-time time
no revert-time
Context
config>eth-ring
Description
This command configures the revert time for an Ethernet ring. It ranges from 60 s to 720 s.
The no form of this command means that the Ethernet ring is in non-revertive mode and the revert time is essentially 0. The revert timers are not set.
Default
300
Parameters
- time
specifies the revert time, in seconds
rpl-node
Syntax
rpl-node {owner | nbr}
no rpl-node
Context
config>eth-ring
Description
This command configures the G.8032 ring protection link type as either owner or neighbor. The no form of the command means this node is not connected to an RPL link. When an RPL owner or neighbor is specified, either the A or B path must be configured with the rpl-end command. An owner is responsible for operation of the RPL link. The link can be left with no RPL type configured, but if this command is used the nbr parameter is mandatory.
On a sub-ring without a virtual channel, it is mandatory to configure a sub-ring non-virtual-link on all nodes on the sub-ring to propagate the RAPS messages around the sub-ring.
The no form of this command removes the RPL link.
Default
no rpl-node
sub-ring
Syntax
[no] sub-ring {virtual-link | non-virtual-link}
Context
config>eth-ring
Description
This command defines an Ethernet ring as a sub-ring as defined in G.8032. A sub-ring can have only one valid path connecting it to a major ring or to a VPLS instance. The virtual-link parameter indicates that a sub-ring is connected to another ring and that control messages can be sent over the attached ring to the other side of the sub-ring. The non-virtual-link channel parameter indicates that a sub-ring may be connected to a another ring or to a VPLS instance but that control messages from the sub-ring can not use the attached ring or VPLS instance. The non-virtual channel behavior is standard G.8032 capability.
The no form of this command deletes the sub-ring and its virtual channel associations.
Default
no sub-ring
Parameters
- virtual-link
specifies that the interconnection is to a ring and a virtual link will be used
- non-virtual-link
specifies that the interconnection is to a ring or a VPLS instance and a virtual link will not be used
interconnect
Syntax
interconnect ring-id ring-index
interconnect vpls
no interconnect
Context
config>eth-ring>sub-ring
Description
This command links the G.8032 sub-ring to a ring instance or to a VPLS instance. The ring instance must be a complete ring with two paths but may itself be a sub-ring or a major ring, as declared by its configuration on another node. When the interconnection is to another node, the sub-ring may have a virtual link or a non-virtual-link. When the sub-ring has been configured with a non-virtual link, the sub-ring may be alternatively be connected to a VPLS service. This command is only valid on the interconnection node where a single sub-ring port connects to a major ring or terminates on a VPLS service.
The no form of this command removes the interconnect node.
Default
no interconnect
Parameters
- ring-index
specifies the identifier for the ring instance of the connection ring for this sub-ring on this node
- vpls
specifies that the sub-ring is connected to the VPLS instance that contains the sub-ring SAP
propagate-topology-change
Syntax
[no] propagate-topology-change
Context
config>eth-ring>sub-ring>interconnect
Description
This command configures the G.8032 sub-ring to propagate topology changes from the sub-ring to the major ring as specified in the G.8032 interconnection flush logic. This command is only valid on a sub-ring and the interconnection node. A virtual link or non-virtual link must be specified for this command to be valid. The command is blocked on major rings (when both path A and B are specified on a ring).
The no form of this command disables topology propagation.
Default
no propagate-topology-change
Show Commands
eth-ring
Syntax
eth-ring [status]
eth-ring [ring-index] hierarchy
eth-ring ring-index [path {a | b}]
Context
show
Description
This command displays Ethernet ring information.
Parameters
- status
displays an Ethernet ring status summary
- ring-index
specifies an Ethernet ring index
- hierarchy
displays Ethernet ring hierarchical relationships
- path
displays information for a specific path
Output
The following output is an example of Ethernet ring information and Ethernet Ring Command Field Descriptions describes the fields.
Output Example*A:7705:Dut-A# 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 - lag-32 1 Up Yes 100ms -----
b - 1/1/1 1 Up Yes 100ms -----
2 Up Up a - lag-32 3.3 Up Yes 100ms -----
b - 1/1/1 3.3 Up Yes 100ms -----
3 Up Up a - 1/1/3 5.5 Up Yes 100ms -----
b - N/A - - - -----
===============================================================================
Ethernet Tunnel MEP Defect Legend:
R = Rdi, M = MacStatus, C = RemoteCCM, E = ErrorCCM, X = XconCCM
*A:7705:Dut-A# show eth-ring 1 hierarchy
===============================================================================
Ethernet Ring 1 (hierarchy)
===============================================================================
Ring Int Admin Oper Paths Summary Path States
ID ID State State a b
-------------------------------------------------------------------------------
1 - Up Up a - lag-32 1 b - 1/1/1 1 U U
3 1 Up Up a - 1/1/3 5.5 b - Not configured B -
===============================================================================
Ethernet Ring Summary Legend: B - Blocked U - Unblocked
*A:7705:Dut-A# show eth-ring 1 path a
===============================================================================
Ethernet Ring 1 Path Information
===============================================================================
Description : Ethernet Ring : 1 Path : pathA
Port : lag-32 Raps-Tag : 1.0
Admin State : Up Oper State : Up
Path Type : normal Fwd State : unblocked
Fwd State Change : 03/19/2019 18:51:35
Last Switch Command: noCmd
APS Rx PDU : Request State: 0x0
Sub-Code : 0x0
Status : 0xE0 ( RB DNF BPR )
Node ID : 94:e9:8c:0c:db:d9
===============================================================================
*A:7705:Dut-A# show eth-ring 1 path b
===============================================================================
Ethernet Ring 1 Path Information
===============================================================================
Description : Ethernet Ring : 1 Path : pathB
Port : 1/1/1 Raps-Tag : 1.0
Admin State : Up Oper State : Up
Path Type : normal Fwd State : unblocked
Fwd State Change : 03/19/2019 18:51:39
Last Switch Command: noCmd
APS Rx PDU : Request State: 0x0
Sub-Code : 0x0
Status : 0xE0 ( RB DNF BPR )
Node ID : 94:e9:8c:0c:db:d9
===============================================================================
*A:7705:Dut-A#
|
Label |
Description |
|---|---|
|
Ring ID |
Displays the Ethernet ring ID number |
|
Admin State |
Up – the Ethernet ring or path is administratively enabled Down – the Ethernet ring or path is administratively disabled |
|
Oper State |
Up – the Ethernet ring or path is operationally enabled Down – the Ethernet ring or path is operationally disabled |
|
Path |
Displays the configured Ethernet ring path |
|
Tag |
Displays the APS tag |
|
Ctrl-MEP |
Indicates whether the MEP is configured as a control MEP |
|
CC-Intvl |
Displays the configured CCM interval value |
|
Defects |
Displays any Ethernet tunnel MEP defects |
|
Int ID |
Displays the interface ID |
|
Path States |
Displays the state of Ethernet ring paths B – Blocked U – Unblocked |
|
Description |
Displays the Ethernet ring path description |
|
Fwd State |
Displays the forwarding state of the path |
|
Fwd State Change |
Displays the date and time of the last change to the path’s forwarding state |
customer
Syntax
customer customer-id
Context
show>service
Description
This command displays service customer information.
Parameters
- customer-id
displays only information for the specified customer ID
Output
The following output is an example of customer information, and Customer Command Field Descriptions describes the fields.
Output Example*A:ALU-12# show service customer
==========================================================
Customers
==========================================================
Customer-ID : 1
Contact : Manager
Description : Default customer
Phone : (123) 555-1212
Customer-ID : 2
Contact : Tech Support
Description : ABC Networks
Phone : (234) 555-1212
Customer-ID : 3
Contact : Fred
Description : ABC Networks
Phone : (345) 555-1212
Customer-ID : 6
Contact : Ethel
Description : Epipe Customer
Phone : (456) 555-1212
Customer-ID : 7
Contact : Lucy
Description : VPLS Customer
Phone : (567) 555-1212
Customer-ID : 8
Contact : Customer Service
Description : IES Customer
Phone : (678) 555-1212
Customer-ID : 274
Contact : Mssrs. Beaucoup
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:ALU-12#
*A:ALU-12# show service customer 274
==============================================================================
Customer 274
==============================================================================
Customer-ID : 274
Contact : Mssrs. Beaucoup
Description : ABC Company
Phone : 650 123-4567
------------------------------------------------------------------------------
Total Customers : 1
------------------------------------------------------------------------------
*A:ALU-12#
Label |
Description |
|---|---|
Customer-ID |
Displays the unique customer identification number |
Contact |
Displays the name of the primary contact person |
Description |
Displays generic information about the customer |
Phone |
Displays the telephone or pager number used to reach the primary contact person |
Total Customers |
Displays the total number of customers configured |
sdp
Syntax
sdp sdp-id keep-alive-history
sdp [sdp-id] [detail]
sdp far-end ip-addr keep-alive-history
sdp far-end ip-addr [detail]
Context
show>service
Description
This command displays SDP information.
If no optional parameters are specified, a summary SDP output for all SDPs is displayed.
Parameters
- sdp-id
the SDP ID for which to display information
- ip-address
displays only SDPs matching with the specified far-end IP address
- detail
displays detailed SDP information
- keep-alive-history
displays the last fifty SDP keepalive events for the SDP
Output
The following output is an example of service SDP information, and Service SDP Field Descriptions describes the fields.
Output Example*A:Sar18 Dut-B>show>service# sdp
============================================================================
Services: Service Destination Points
============================================================================
SdpId AdmMTU OprMTU Far End Adm Opr Del LSP Sig
----------------------------------------------------------------------------
8 0 0 10.10.10.10 Down Down MPLS TLDP
11 0 0 Down Down MPLS TLDP
30 0 0 Down Down MPLS TLDP
900 0 0 10.10.10.10 Down Down MPLS TLDP
1000 0 1546 1.1.1.1 Up Up MPLS L TLDP
----------------------------------------------------------------------------
Number of SDPs : 5
----------------------------------------------------------------------------
Legend: R = RSVP, L = LDP, B = BGP, M = MPLS-TP, n/a = Not Applicable
I = SR-ISIS, O = SR-OSPF, T = SR-TE, F = FPE
============================================================================
*A:Sar18 Dut-B>show>service#
*A:Sar18 Dut-B>show>service# sdp 8
============================================================================
Service Destination Point (Sdp Id : 8)
============================================================================
SdpId AdmMTU OprMTU Far End Adm Opr Del LSP Sig
----------------------------------------------------------------------------
8 0 0 10.10.10.10 Down Down MPLS TLDP
============================================================================
*A:Sar18 Dut-B>show>service#
*A:Sar18 Dut-B>show>service# sdp 1000 detail
===============================================================================
Service Destination Point (Sdp Id : 1000) Details
===============================================================================
-------------------------------------------------------------------------------
Sdp Id 1000 -1.1.1.1
-------------------------------------------------------------------------------
Description : (Not Specified)
SDP Id : 1000 SDP Source : manual
Admin Path MTU : 0 Oper Path MTU : 1546
Delivery : MPLS
Far End : 1.1.1.1
Tunnel Far End : 1.1.1.1 LSP Types : LDP
Admin State : Up Oper State : Up
Signaling : TLDP Metric : 0
Last Status Change : 05/23/2018 18:41:32 Adv. MTU Over. : No
Last Mgmt Change : 05/23/2018 18:41:05 VLAN VC Etype : 0x8100
Flags : None
Mixed LSP Mode Information :
Mixed LSP Mode : Enabled Active LSP Type : LDP
Revert Time : 0 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
-------------------------------------------------------------------------------
BGP Tunnel Information :
-------------------------------------------------------------------------------
BGP LSP Id : 0
-------------------------------------------------------------------------------
LDP Information :
-------------------------------------------------------------------------------
LDP LSP Id : 65537
-------------------------------------------------------------------------------
RSVP/Static LSPs
-------------------------------------------------------------------------------
Associated LSP List :
No LSPs Associated
-------------------------------------------------------------------------------
Segment Routing
-------------------------------------------------------------------------------
ISIS : disabled
OSPF : disabled
TE-LSP : disabled
-------------------------------------------------------------------------------
Group Encryption
-------------------------------------------------------------------------------
Inbound Keygroup Id : N/A
Outbound Keygroup Id : N/A
===============================================================================
*A:Sar18 Dut-B>show>service# *
*A:ALU-12>show>service# sdp 11 keep-alive-history
===============================================================================
Service Destination Point (Sdp Id : 5001)
===============================================================================
Time of Probe Report RTT(ms) Size Status
-------------------------------------------------------------------------------
2010/11/30 11:27:32 1011 72 Response Received
2010/11/30 11:27:22 1001 72 Response Received
2010/11/30 11:27:12 1001 72 Response Received
2010/11/30 11:27:02 1001 72 Response Received
2010/11/30 11:26:58 1002 72 Response Received
===============================================================================
*A:ALU-12>show>service#
Label |
Description |
|---|---|
SDP Id |
Identifies the SDP |
Description |
Identifies the SDP by the text description stored in its configuration file |
SDP Source |
Specifies the SDP source type |
Adm MTU (Adm Path MTU) |
Specifies the desired largest service frame size (in octets) that can be transmitted through this SDP to the far-end router |
Opr MTU (Opr Path MTU) |
Specifies the actual largest service frame size (in octets) that can be transmitted through this SDP to the far-end router |
Delivery |
Specifies the delivery routing protocol |
Far End |
Specifies the IP address of the remote end of the GRE or MPLS tunnel defined by this SDP |
Tunnel Far End |
On the 7705 SAR, tunnel far end is the same as the SDP far end and is not configurable |
LSP Types |
Specifies the supported LSP types: R = RSVP, L = LDP, B = BGP, I = SR-ISIS, O = SR-OSPF, T = SR-TE, and n/a = Not Applicable |
Adm (Admin State) |
Specifies the desired state of the SDP |
Opr (Oper State) |
Specifies the operating state of the SDP |
Del (Delivery) |
Specifies the type of delivery used by the SDP: MPLS, GRE, or IP |
Sig (Signaling) |
Specifies the signaling protocol used to obtain the ingress and egress labels used in frames transmitted and received on the SDP |
Metric |
Specifies the value used as a tiebreaker by the tunnel table manager to select a route |
Last Status Change |
Specifies the time of the most recent operating status change to this SDP |
Last Mgmt Change |
Specifies the time of the most recent management-initiated change to this SDP |
Adv. MTU Over |
Specifies the state of the advertised VC-type MTU override command |
VLAN VC Etype |
Specifies the VLAN VC Ethertype for the SDP |
Flags |
Specifies all the conditions that affect the operating status of this SDP |
Number of SDPs |
Specifies the total number of SDPs displayed according to the criteria specified |
Mixed LSP Mode Information: |
|
Mixed LSP Mode |
Indicates whether mixed-LSP mode is configured on the SDP |
Active LSP Type |
Indicates the active LSP type on the mixed-LSP SDP: RSVP or LDP |
Revert Time |
The number of seconds the service manager must wait before it resets the SDP configuration to a higher priority LSP type when one becomes available |
Keepalive Information: |
|
Admin State |
Specifies the desired keepalive state |
Oper State |
Specifies the operating keepalive state |
Hello Time |
Specifies how often the SDP Echo Request messages are transmitted on this SDP |
Hello Msg Len |
Specifies the length of the SDP Echo Request messages transmitted on this SDP |
Hello Timeout |
Specifies the number of seconds to wait for an SDP echo response message before declaring a timeout |
Unmatched Replies |
Specifies the number of SDP unmatched message replies timer expired |
Max Drop Count |
Specifies the maximum number of consecutive SDP Echo Request messages that can be unacknowledged before the keepalive protocol reports a fault |
Hold Down Time |
Specifies the amount of time to wait before the keepalive operating status is eligible to enter the alive state |
TX Hello Msgs |
Specifies the number of SDP echo request messages transmitted since the keepalive was administratively enabled or the counter was cleared |
Rx Hello Msgs |
Specifies the number of SDP echo request messages received since the keepalive was administratively enabled or the counter was cleared |
Collect Stats. |
Specifies that the collection of accounting and statistical data for the SDP is enabled or disabled |
Keepalive History: |
|
Time of Probe Report |
Indicates the date and time of the report |
RTT (ms) |
Indicates round-trip time (RTT), in milliseconds. |
Size |
Indicates the size of the packet, in bytes |
Status |
Indicates the status of the response |
LDP Information: |
|
LDP LSP Id |
Indicates the LDP LSP identifier |
RSVP/Static LSPs: |
|
Associated LSP List |
Lists the associated LSPs If 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 If the SDP type is GRE, the following message displays: SDP Delivery Mechanism is not MPLS |
Lsp Name |
For MPLS: identifies the name of the static LSP |
Time since Last Trans* |
For MPLS: specifies the time that the associated static LSP has been in service |
Segment Routing |
|
ISIS |
Indicates the state of IS-IS segment routing: enabled or disabled |
OSPF |
Indicates the state of OSPF segment routing: enabled or disabled |
TE-LSP |
Indicates the state of TE-LSP segment routing: enabled or disabled |
Group Encryption |
|
Inbound Keygroup Id |
Indicates the key group used to decrypt inbound traffic for the service |
Outbound Keygroup Id |
Indicates the key group used to encrypt outbound traffic for the service |
sdp-using
Syntax
sdp-using [sdp-id[:vc-id] | far-end ip-address]
Context
show>service
Description
This command displays services using SDP or far-end address options.
Parameters
- sdp-id
displays only services bound to the specified SDP ID
- vc-id
the virtual circuit identifier
- ip-address
displays only services matching with the specified far-end IP address
Output
The following output is an example of service SDP-using information, and Service SDP-Using Field Descriptions describes the fields.
Output Example*A:ALU-1# 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
102 300:102 Spok 10.0.0.13 Up 131067 131067
-------------------------------------------------------------------------------
Number of SDPs : 7
-------------------------------------------------------------------------------
===============================================================================
Label |
Description |
|---|---|
SvcId |
Identifies the service |
SdpId |
Identifies the SDP |
Type |
Indicates the type of SDP (mesh or spoke) |
Far End |
Displays the far-end address of the SDP |
Opr State |
Displays the operational state of the service |
I. Label |
Displays the ingress label used by the far-end device to send packets to this device in this service by this SDP |
E. Label |
Displays the egress 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] [fpipe] [hpipe] [ies] [vpls] [vprn] [mirror] [apipe] [ipipe] [cpipe] [sdp sdp-id] [customer customer-id]
Context
show>service
Description
This command displays the services matching specific usage properties.
If no optional parameters are specified, all services defined on the system are displayed.
Parameters
- epipe
displays matching Epipe services
- ies
displays matching IES services
- vpls
displays matching VPLS services
- vprn
displays matching VPRN services
- mirror
displays matching mirror services
- apipe
displays matching Apipe services
- cpipe
displays matching Cpipe services
- fpipe
displays matching Fpipe services
- hpipe
displays matching Hpipe services
- sdp-id
displays only services bound to the specified SDP ID
- customer-id
displays services only associated with the specified customer ID
Output
The following outputs are examples of service-using information, and Service Service-Using Field Descriptions describes the fields.
Output Example – all services used in system*A:ALU-12# show service service-using
===============================================================================
Services
===============================================================================
ServiceId Type Adm Opr CustomerId Service Name
-------------------------------------------------------------------------------
1 Cpipe Down Down 1 cpipe_1_global
2 Apipe Down Down 1 apipe_2
103 Epipe Up Up 104 epipe_103_sales
104 Epipe Up Up 104 epipe_104_marketing
105 Epipe Up Up 104 epipe_105_finance
303 Cpipe Up Up 104
304 Cpipe Up Up 104
305 Cpipe Up Up 104
701 Apipe Up Down 1
702 Apipe Up Down 1
703 Apipe Up Down 1
704 Apipe Up Down 1
807 Apipe Up Down 1
808 Apipe Up Down 1
903 Cpipe Up Up 1
904 Cpipe Up Up 1
5000 VPLS Down Down 1 vpls_5000_sales
5001 VPLS Down Down 1
-------------------------------------------------------------------------------
Matching Services : 19
*A:7705:Dut-A# show service service-using
===============================================================================
Services
===============================================================================
ServiceId Type Adm Opr CustomerId Service Name
-------------------------------------------------------------------------------
100 Mirror Up Up 1 XYZ Mirror 100
1000 Epipe Up Up 1 XYZ Epipe 1000
2000 VPLS Up Up 1
2100 VPLS Up Up 1 rVpls2100
2200 Ipipe Up Up 1
3000 IES Up Up 1 XYZ Ies 3000
3500 VPRN Up Up 1 XYZ Vprn 3500
4050 IES Up Up 1 XYZ Ies 4050
-------------------------------------------------------------------------------
Matching Services : 8
*A:ALU-12# show service service-using customer 1
===============================================================================
Services Customer 1
===============================================================================
ServiceId Type Adm Opr CustomerId Service Name
-------------------------------------------------------------------------------
1 Cpipe Down Down 1 cpipe_1_global
2 Apipe Down Down 1 apipe_2
701 Apipe Up Down 1
702 Apipe Up Down 1
703 Apipe Up Down 1
704 Apipe Up Down 1
807 Apipe Up Down 1
808 Apipe Up Down 1
903 Cpipe Up Up 1
904 Cpipe Up Up 1
5000 VPLS Down Down 1 vpls_5000_sales
5001 VPLS Down Down 1
-------------------------------------------------------------------------------
Matching Services : 13
*A:ALU-12#
*A:ALU-12# show service service-using epipe
===============================================================================
Services [epipe]
===============================================================================
ServiceId Type Adm Opr CustomerId Service Name
-------------------------------------------------------------------------------
103 Epipe Up Up 104 epipe_103_sales
104 Epipe Up Up 104 epipe_104_marketing
105 Epipe Up Up 104 epipe_105_finance
-------------------------------------------------------------------------------
Matching Services : 3
*A:ALU-12#
Label |
Description |
|---|---|
Service Id |
Identifies the service |
Type |
Specifies the service type configured for the service ID |
Adm |
Displays the desired state of the service |
Opr |
Displays the operating state of the service |
CustomerID |
Displays the ID of the customer who owns this service |
Service Name |
The service name |
Monitor Commands
service
Syntax
service
Context
monitor
Description
This command enables the context to configure criteria to monitor specific service SAP criteria.
id
Syntax
id service-id
Context
monitor>service
Description
This command displays statistics for a specific service, specified by the service-id, at the configured interval until the configured count is reached.
The first screen displays the current statistics related to the service-id. The subsequent statistical information listed for each interval is displayed as a delta to the previous screen output.
When the keyword rate is specified, the rate per second for each statistic is displayed instead of the delta.
Monitor commands are similar to show commands, but only statistical information is displayed. Monitor commands display the selected statistics according to the configured number of times at the interval specified.
Parameters
- service-id
identifies the service in the service domain
sap
Syntax
sap sap-id [interval seconds] [repeat repeat] [absolute | rate]
Context
monitor>service>id
Description
This command displays statistics for a SAP associated with this service.
This command displays statistics for a specific SAP, identified by the port ID and encapsulation value, at the configured interval until the configured count is reached.
The first screen displays the current statistics related to the SAP. The subsequent statistical information listed for each interval is displayed as a delta to the previous screen output.
When the keyword rate is specified, the rate per second for each statistic is displayed instead of the delta.
Monitor commands are similar to show commands, but only statistical information is displayed. Monitor commands display the selected statistics according to the configured number of times at the interval specified.
Parameters
- sap-id
identifies the SAP for the service
The sap-id can be configured in one of the formats described in SAP ID Configurations . The range of values for the parameters follow the table.
Table 18. SAP ID Configurations Type
Syntax
Example
port-id
slot/mda/port[.channel]
1/1/5
bridge
slot/mda/<bridge-id.branch-id>
1/5/16.10
null
[port-id | bundle-id | lag-id | aps-id | mw-link-id]
port-id: 1/1/3
bundle-id: bundle-ppp-1/1.1
lag-id: lag-1
aps-id: aps-1
mw-link-id: mw-link-1
dot1q
[port-id | lag-id | aps-id | mw-link-id]:qtag1
port-id:qtag1: 1/1/3:100
lag-id: lag-1:10
aps-id: aps-1
mw-link-id: mw-link-1
qinq
[port-id | lag-id]:qtag1.qtag2
port-id:qtag1.qtag2: 1/1/3:100.30
lag-id: lag-1:10.10
atm
[port-id | aps-id][:vpi/vci | vpi | vpi1.vpi2]1
port-id: 1/1/1 or 1/1/1.1 (for T1/E1 channelized ports)
aps-id: aps-1
vpi/vci: 16/26
vpi: 16
vpi1.vpi2: 16.22
lag
lag-id
lag-2
frame
[port-id| aps-id]:dlci
1/1/1
aps-id: aps-1
dlci: 16
frame relay
[port-id]:dlci
1/1/1
dlci: 16
cisco-hdlc
slot/mda/port.channel
1/1/1.3
cem
slot/mda/port.channel
1/1/1.3
ima-grp
bundle-id[:vpi/vci | vpi | vpi1.vpi2]
1/1/3.1
ipcp
slot/mda/port.channel
1/2/2.4
hdlc
slot/mda/port.channel
1/1/3.1
lag-id
lag-id
lag-1
mw-link-id
mw-link-id
mw-link-1
aps-id
aps-group-id[.channel]
aps-1
bundle-id
bundle-[ima | ppp]-slot/mda.bundle-num
bundle-ima-1/1.1
tunnel-id
tunnel-<id>.[private | public]:<tag>
tunnel-1.private:1
Note:
For Apipes in virtual trunking mode, vpi/vci, vpi, and vpi1.vpi2 are omitted.
- port-id
specifies the physical port ID in the slot/mda/port format
If the card in the slot has an adapter card installed, the port-id must be in the slot_number/MDA_number/port_number format. For example, 1/2/3 specifies port 3 on MDA 2 in slot 1.
The port-id must reference a valid port type. When the port-id parameter represents TDM channels, the port ID must include the channel ID. A period ‟.” separates the physical port from the channel-id. The port must be configured as an access port.
- bridge-id
specifies an existing bridge that has been configured on an Integrated Services card in the slot/mda/<bridge-id.branch-id> format
bridge-id value range: 1 to 16
- branch-id
specifies an existing branch that has been configured on an Integrated Services card in the slot/mda/<bridge-id.branch-id> format
branch-id value range: 1 to 32
- bundle-id
specifies the multilink (PPP or IMA) bundle identifier. The bundle keyword must be entered at the beginning of the parameter. The command syntax must be configured as follows:
bundle-id: bundle-type-slot/mda.bundle-num
type: ima, ppp
bundle-num: 1 to 32
For example:
*A:ALU-12>config# port bundle-ppp-xz5/1.1 *A:ALU-12>config>port# multilink-bundle
- qtag1, qtag2
specifies the encapsulation value used to identify the SAP on the port or subport. For dot1q encapsulation, only qtag1 is used; for qinq encapsulation, both qtag1 and qtag2 are used. If qtag1 or qtag2 is not specifically defined, the value 0 is used. The ‟*” value represents all qtag values between 0 and 4094 that are not specifically defined within another SAP context under the same port. In addition, the following qtag1.qtag2 values are invalid options:
*.qtag2
*.0
0.qtag2
- seconds
configures the interval for each display in seconds
- repeat
configures how many times the command is repeated
- absolute
displays the absolute rate-per-second value for each statistic
- rate
displays the rate per second for each statistic instead of the delta
sap-aggregation-group
Syntax
sap-aggregation-group group-id [interval seconds] [repeat repeat] [absolute | rate]
Context
monitor>service>id
Description
This command displays the statistics for the specified SAP aggregation group that is associated with the service.
Parameters
- group-id
specifies the identifier for the SAP aggregation group
- seconds
configures the interval for each display in seconds
- repeat
configures how many times the command is repeated
- absolute
displays the absolute rate-per-second value for each statistic
- rate
displays the rate per second for each statistic instead of the delta
Output
The following output is an example of statistics for a SAP aggregation group.
Output Example*A:SYS28# monitor service id 1570 sap-aggregation-group SAG repeat 2
===============================================================================
Monitor statistics for Service 1570 SAP Aggregation Group SAG
===============================================================================
-------------------------------------------------------------------------------
At time t = 0 sec (Base Statistics)
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Sap Aggregation Group Statistics
-------------------------------------------------------------------------------
Last Cleared Time : N/A
Dropped Egress Cells (unconfigured vpi/vci): 14
Packets Octets
Forwarding Engine Stats (Ingress)
Dropped : 0 n/a
Off. HiPrio : 205557 n/a
Off. LowPrio : n/a n/a
Queueing Stats(Ingress QoS Policy 1)
Dro. HiPrio : 0 n/a
Dro. LowPrio : n/a n/a
For. InProf : 0 0
For. OutProf : 205557 68605598
Forwarding Engine Stats (Egress)
Dropped : 0 n/a
Queueing Stats(Egress QoS Policy 1)
Dro. InProf : 0 n/a
Dro. OutProf : n/a n/a
For. InProf : 202446 63083956
For. OutProf : n/a n/a
-------------------------------------------------------------------------------
Sap Aggregation Group per Queue Stats
-------------------------------------------------------------------------------
Packets Octets
Ingress Queue 1 (Priority)
Off. HiPrio : 205557 n/a
Off. LoPrio : n/a n/a
Dro. HiPrio : 0 n/a
Dro. LoPrio : n/a n/a
For. InProf : 0 0
For. OutProf : 205557 68605598
Egress Queue 1
For. InProf : 202446 63083956
For. OutProf : n/a n/a
Dro. InProf : 0 n/a
Dro. OutProf : n/a n/a
-------------------------------------------------------------------------------
At time t = 11 sec (Mode: Delta)
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Sap Aggregation Group Statistics
-------------------------------------------------------------------------------
Last Cleared Time : N/A
Dropped Egress Cells (unconfigured vpi/vci): 14
Packets Octets
Forwarding Engine Stats (Ingress)
Dropped : 0 n/a
Off. HiPrio : 233 n/a
Off. LowPrio : n/a n/a
Queueing Stats(Ingress QoS Policy 1)
Dro. HiPrio : 0 n/a
Dro. LowPrio : n/a n/a
For. InProf : 0 0
For. OutProf : 233 77822
Forwarding Engine Stats (Egress)
Dropped : 0 n/a
Queueing Stats(Egress QoS Policy 1)
Dro. InProf : 0 n/a
Dro. OutProf : n/a n/a
For. InProf : 232 72384
For. OutProf : n/a n/a
-------------------------------------------------------------------------------
Sap Aggregation Group per Queue Stats
-------------------------------------------------------------------------------
Packets Octets
Ingress Queue 1 (Priority)
Off. HiPrio : 233 n/a
Off. LoPrio : n/a n/a
Dro. HiPrio : 0 n/a
Dro. LoPrio : n/a n/a
For. InProf : 0 0
For. OutProf : 233 77822
Egress Queue 1
For. InProf : 232 72384
For. OutProf : n/a n/a
Dro. InProf : 0 n/a
Dro. OutProf : n/a n/a
-------------------------------------------------------------------------------
At time t = 22 sec (Mode: Delta)
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Sap Aggregation Group Statistics
-------------------------------------------------------------------------------
Last Cleared Time : N/A
Dropped Egress Cells (unconfigured vpi/vci): 14
Packets Octets
Forwarding Engine Stats (Ingress)
Dropped : 0 n/a
Off. HiPrio : 232 n/a
Off. LowPrio : n/a n/a
Queueing Stats(Ingress QoS Policy 1)
Dro. HiPrio : 0 n/a
Dro. LowPrio : n/a n/a
For. InProf : 0 0
For. OutProf : 232 77488
Forwarding Engine Stats (Egress)
Dropped : 0 n/a
Queueing Stats(Egress QoS Policy 1)
Dro. InProf : 0 n/a
Dro. OutProf : n/a n/a
For. InProf : 233 72696
For. OutProf : n/a n/a
-------------------------------------------------------------------------------
Sap Aggregation Group per Queue Stats
-------------------------------------------------------------------------------
Packets Octets
Ingress Queue 1 (Priority)
Off. HiPrio : 232 n/a
Off. LoPrio : n/a n/a
Dro. HiPrio : 0 n/a
Dro. LoPrio : n/a n/a
For. InProf : 0 0
For. OutProf : 232 77488
Egress Queue 1
For. InProf : 233 72696
For. OutProf : n/a n/a
Dro. InProf : 0 n/a
Dro. OutProf : n/a n/a