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

17-4
Cisco ONS 15310-CL and Cisco ONS 15310-MA Ethernet Card Software Feature and Configuration Guide R8.5
78-18133-01
Chapter 17 CE-100T-8 Ethernet Operation
CE-100T-8 Ethernet Features
Enhanced State Model for Ethernet and SONET Ports
The CE-100T-8 supports the Enhanced State Model (ESM) for the Ethernet ports, as well as for the
SONET circuit. For more information about the ESM, refer to the “Administrative and Service States”
appendix in the Cisco ONS 15454 Reference Manual.
The Ethernet ports can be set to the ESM service states including the In-Service, Automatic In-Service
(IS,AINS) administrative state. IS,AINS initially puts the port in the Out-of-Service and Autonomous,
Automatic In-Service (OOS-AU,AINS) state. In this service state, alarm reporting is suppressed, but
traffic is carried and loopbacks are allowed. After the soak period passes, the port changes to In-Service
and Normal (IS-NR). Raised fault conditions, whether their alarms are reported or not, can be retrieved
on the CTC Conditions tab or by using the TL1 RTRV-COND command.
Two Ethernet port alarms/conditions, CARLOSS and TPTFAIL, can prevent the port from going into
service. This occurs even though alarms are suppressed when a CE-100T-8 circuit is provisioned with
the Ethernet ports set to the IS,AINS state, because the CE-100T-8 link integrity function is active and
ensures that the links at both ends are not enabled until all SONET and Ethernet errors along the path
are cleared. As long as the link integrity function keeps the end-to-end path down, both ports will have
at least one of the two conditions needed to suppress the AINS-to-IS transition. Therefore, the ports will
remain in the AINS state with alarms suppressed.
ESM also applies to the SONET circuits of the CE-100T-8 card. If the SONET circuit is set up in
IS,AINS state and the Ethernet error occurs before the circuit transitions to IS, then link integrity will
also prevent the circuit transition to the IS state until the Ethernet port errors are cleared at both ends.
The service state will be OOS-AU,AINS as long as the administrative state is IS,AINS. When there are
no Ethernet or SONET errors, link integrity enables the Ethernet port at each end. Simultaneously, the
AINS countdown begins as normal. If no additional conditions occur during the time period, each port
transitions to the IS-NR state. During the AINS countdown, the soak time remaining is available in CTC
and TL1. The AINS soaking logic restarts from the beginning if a condition appears again during the
soak period.
A SONET circuit provisioned in the IS,AINS state remains in the initial Out-of-Service (OOS) state until
the Ethernet ports on each end of the circuit transition to the IS-NR state. The SONET circuit transports
Ethernet traffic and counts statistics when link integrity turns on the Ethernet port, regardless of whether
this AINS-to-IS transition is complete.
IEEE 802.1Q CoS and IP ToS Queuing
The CE-100T-8 references IEEE 802.1Q class of service (CoS) thresholds and IP type of service (ToS)
(IP Differentiated Services Code Point [DSCP]) thresholds for priority queueing. CoS and ToS thresholds
for the CE-100T-8 are provisioned on a per port level. This allows the user to provide priority treatment
based on open standard quality of service (QoS) schemes already existing in the data network attached
to the CE-100T-8. The QoS treatment is applied to both Ethernet and POS ports.
Any packet or frame with a priority greater than the set threshold is treated as priority traffic. This
priority traffic is sent to the priority queue instead of the normal queue. When buffering occurs, packets
on the priority queue preempt packets on the normal queue. This results in lower latency for the priority
traffic, which is often latency-sensitive traffic, such as VoIP.
Because these priorities are placed on separate queues, the priority queuing feature should not be used
to separate rate-based CIR/EIR marked traffic (sometimes done at a Metro Ethernet service provider
edge). This could result in out-of-order packet delivery for packets of the same application, which would
cause performance issues with some applications.