User manual
Table Of Contents
- Cisco ONS 15310-CL and Cisco ONS 15310-MA Ethernet Card Software Feature and Configuration Guide
- Contents
- Preface
- Overview of the ML-Series Card
- CTC Operations on the ML-Series Card
- Initial Configuration of the ML-Series Card
- Configuring Interfaces on the ML-Series Card
- Configuring POS on the ML-Series Card
- Configuring STP and RSTP on the ML-Series Card
- STP Features
- STP Overview
- Supported STP Instances
- Bridge Protocol Data Units
- Election of the Root Switch
- Bridge ID, Switch Priority, and Extended System ID
- Spanning-Tree Timers
- Creating the Spanning-Tree Topology
- Spanning-Tree Interface States
- Spanning-Tree Address Management
- STP and IEEE 802.1Q Trunks
- Spanning Tree and Redundant Connectivity
- Accelerated Aging to Retain Connectivity
- RSTP Features
- Interoperability with IEEE 802.1D STP
- Configuring STP and RSTP Features
- Default STP and RSTP Configuration
- Disabling STP and RSTP
- Configuring the Root Switch
- Configuring the Port Priority
- Configuring the Path Cost
- Configuring the Switch Priority of a Bridge Group
- Configuring the Hello Time
- Configuring the Forwarding-Delay Time for a Bridge Group
- Configuring the Maximum-Aging Time for a Bridge Group
- Verifying and Monitoring STP and RSTP Status
- STP Features
- Configuring VLANs on the ML-Series Card
- Configuring IEEE 802.1Q Tunneling and Layer 2 Protocol Tunneling on the ML-Series Card
- Configuring Link Aggregation on the ML-Series Card
- Configuring IRB on the ML-Series Card
- Configuring Quality of Service on the ML-Series Card
- Understanding QoS
- ML-Series QoS
- QoS on RPR
- Configuring QoS
- Monitoring and Verifying QoS Configuration
- QoS Configuration Examples
- Understanding Multicast QoS and Multicast Priority Queuing
- Configuring Multicast Priority Queuing QoS
- QoS not Configured on Egress
- ML-Series Egress Bandwidth Example
- Understanding CoS-Based Packet Statistics
- Configuring CoS-Based Packet Statistics
- Understanding IP SLA
- Configuring the Switching Database Manager on the ML-Series Card
- Configuring Access Control Lists on the ML-Series Card
- Configuring Resilient Packet Ring on the ML-Series Card
- Understanding RPR
- Configuring RPR
- Connecting the ML-Series Cards with Point-to-Point STS Circuits
- Configuring CTC Circuits for RPR
- Configuring RPR Characteristics and the SPR Interface on the ML-Series Card
- Assigning the ML-Series Card POS Ports to the SPR Interface
- Creating the Bridge Group and Assigning the Ethernet and SPR Interfaces
- RPR Cisco IOS Configuration Example
- Verifying Ethernet Connectivity Between RPR Ethernet Access Ports
- CRC Threshold Configuration and Detection
- Monitoring and Verifying RPR
- Add an ML-Series Card into an RPR
- Delete an ML-Series Card from an RPR
- Cisco Proprietary RPR KeepAlive
- Cisco Proprietary RPR Shortest Path
- Redundant Interconnect
- Configuring Security for the ML-Series Card
- Understanding Security
- Disabling the Console Port on the ML-Series Card
- Secure Login on the ML-Series Card
- Secure Shell on the ML-Series Card
- RADIUS on the ML-Series Card
- RADIUS Relay Mode
- RADIUS Stand Alone Mode
- Understanding RADIUS
- Configuring RADIUS
- Default RADIUS Configuration
- Identifying the RADIUS Server Host
- Configuring AAA Login Authentication
- Defining AAA Server Groups
- Configuring RADIUS Authorization for User Privileged Access and Network Services
- Starting RADIUS Accounting
- Configuring a nas-ip-address in the RADIUS Packet
- Configuring Settings for All RADIUS Servers
- Configuring the ML-Series Card to Use Vendor-Specific RADIUS Attributes
- Configuring the ML-Series Card for Vendor-Proprietary RADIUS Server Communication
- Displaying the RADIUS Configuration
- Configuring Bridging on the ML-Series Card
- CE-100T-8 Ethernet Operation
- Command Reference for the ML-Series Card
- [no] bridge bridge-group-number protocol {drpri-rstp | ieee | rstp}
- clear counters
- [no] clock auto
- interface spr 1
- [no] pos mode gfp [fcs-disabled]
- [no] pos pdi holdoff time
- [no] pos report alarm
- [non] pos trigger defects condition
- [no] pos trigger delay time
- [no] pos vcat defect {immediate | delayed}
- show controller pos interface-number [details]
- show interface pos interface-number
- show ons alarm
- show ons alarm defect {[eqpt | port [port-number] | sts [sts-number] | vcg [vcg-number] | vt]}
- show ons alarm failure {[eqpt | port [port-number] | sts [sts-number] | vcg [vcg-number] | vt]}
- spr-intf-id shared-packet-ring-number
- [no] spr load-balance { auto | port-based }
- spr station-id station-id-number
- spr wrap { immediate | delayed }
- Unsupported CLI Commands for the ML-Series Card
- Using Technical Support
- Index

11-8
Cisco ONS 15310-CL and Cisco ONS 15310-MA Ethernet Card Software Feature and Configuration Guide R8.5
78-18133-01
Chapter 11 Configuring Quality of Service on the ML-Series Card
ML-Series QoS
Egress Priority Marking
Egress priority marking allows the operator to assign the IEEE 802.1p CoS bits of packets that exit the
card. This marking allows the operator to use the CoS bits as a mechanism for signaling to downstream
nodes the QoS treatment that the packet should be given. This feature operates on the outer-most
IEEE 802.1p CoS field. When used with the QinQ feature, priority marking allows the user traffic (inner
Q-tag) to traverse the network transparently, while providing a means for the network to internally signal
QoS treatment at Layer 2.
Priority marking follows the classification process, and therefore any of the classification criteria
identified earlier can be used as the basis to set the outgoing IEEE 802.1p CoS field. For example, a
specific CoS value can be mapped to a specific bridge group.
Priority marking is configured using the MQC set-cos command. If packets would otherwise leave the
card without an IEEE 802.1Q tag, then the set-cos command has no effect on that packet. If an
IEEE 802.1Q tag is inserted in the packet (either a normal tag or a QinQ tag), the inserted tag has the
set-cos priority. If an IEEE 802.1Q tag is present on packet ingress and retained on packet egress, the
priority of that tag is modified. If the ingress interface is an QinQ access port and the set-cos policy-map
classifies based on ingress tag priority, this classifies based on the user priority. This is a way to allow
the user-tag priority to determine the SP tag priority. When a packet does not match any set-cos
policy-map, the priority of any preserved tag is unchanged and the priority of any inserted IEEE 802.1Q
tag is set to 0.
The set-cos command on the output service policy is only applied to unicast traffic. Priority marking for
multicast/broadcast traffic can only be achieved by the set-cos action of the policing process on the input
service policy.
Ingress Priority Marking
Ingress priority marking can be done for all input packets of a port, for all input packets matching a
classification, or based on a measured rate. Marking of all packets of an input class can also be done with
a policing command of the form police 96000 conform-action set-cos-transmit exceed-action
set-cos-transmit. Using this command with a policy map that contains only the “class-default” will
mark all ingress packets to the value. Rate based priority marking is discussed in the “Marking and
Discarding with a Policer” section on page 11-5.
QinQ Implementation
The hierarchical VLAN or IEEE 802.1Q tunneling feature enables the service provider to transparently
carry the customer VLANs coming from any specific port (UNI) and transport them over the service
provider network. This feature is also known as QinQ, which is performed by adding an additional
IEEE 802.1Q tag on every customer frame.
Using the QinQ feature, service providers can use a single VLAN to support customers with multiple
VLANs. QinQ preserves customer VLAN IDs and segregates traffic from different customers within the
service-provider infrastructure, even when traffic from different customers originally shared the same
VLAN ID. The QinQ also expands VLAN space by using a VLAN-in-VLAN hierarchy and tagging the
tagged packets. When the service provider (SP) tag is added, the QinQ network typically loses any
visibility to the IP header or the customer Ethernet IEEE 802.1Q tag on the QinQ encapsulated frames.
On the ML-Series cards, the QinQ access ports (IEEE 802.1Q tunnel ports or QinQ UNI ports) have
visibility to the customer CoS and the IP precedence or IP DSCP values; therefore, the SP tag can be
assigned with proper CoS bit, which would reflect the customer IP precedence, IP DSCP, or CoS bits. In