cc/td/doc/product/ong/15400/r72docs
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table Of Contents

Configuring IEEE 802.17b Resilient Packet Ring

Understanding RPR-IEEE

RPR-IEEE Features on the ML-Series Card

Advantages of RPR-IEEE

Role of SONET/SDH Circuits

RPR-IEEE Framing Process

CTM and RPR-IEEE

Configuring RPR-IEEE Characteristics

Configuring the Attribute Discovery Timer

Configuring the Reporting of SONET Alarms

Configuring BER Threshold Values

Configuring RPR-IEEE Protection

Configuring the Hold-off Timer

Configuring Jumbo Frames

Configuring Forced or Manual Switching

Configuring Protection Timers

Configuring the Wait-to-Restore Timer

Configuring a Span Shutdown

Configuring Keepalive Events

Configuring Triggers for CRC Errors

Configuring QoS on RPR-IEEE

Class A

ClassB

ClassC

MQC -IEEE RPR CLI Characteristics

Configuring Traffic Rates for Transmission

Configuring Fairness Weights

Configuring RPR-IEEE Service Classes Using the Modular QoS CLI

Configuration Example for RPR-IEEE QoS

Configuration Example Using MQC to Configure Simple RPR-IEEE QoS

Configuration Example Using MQC to Configure Complex RPR-IEEE QoS

Verifying and Monitoring RPR-IEEE

Configuring RPR-IEEE End-to-End

Provisioning Card Mode

Connecting the ML-Series Cards with Point-to-Point STS/STM Circuits

Creating the RPR-IEEE Interface and Bridge Group

Configuration Examples for Cisco IOS CLI Portion of End-to-End RPR-IEEE

Verifying RPR-IEEE End-to-End Ethernet Connectivity

Understanding Redundant Interconnect

Characteristics of RI on the ML-Series Card

RI Configuration Example


Configuring IEEE 802.17b Resilient Packet Ring

Note The terms "Unidirectional Path Switched Ring" and "UPSR" may appear in Cisco literature. These terms do not refer to using Cisco ONS 15xxx products in a unidirectional path switched ring configuration. Rather, these terms, as well as "Path Protected Mesh Network" and "PPMN," refer generally to Cisco's path protection feature, which may be used in any topological network configuration. Cisco does not recommend using its path protection feature in any particular topological network configuration.

This chapter describes the IEEE 802.17b-based resilient packet ring (RPR-IEEE) and how to configure it on the ML-Series card.

This chapter contains the following major sections:

• Understanding RPR-IEEE

• Configuring RPR-IEEE Characteristics

• Configuring RPR-IEEE Protection

• Configuring QoS on RPR-IEEE

• Configuration Example for RPR-IEEE QoS

• Verifying and Monitoring RPR-IEEE

• Configuring RPR-IEEE End-to-End

• Verifying RPR-IEEE End-to-End Ethernet Connectivity

• Understanding Redundant Interconnect

Understanding RPR-IEEE

RPR, as described in IEEE 802.17, is a metropolitan area network (MAN) technology supporting data transfer among stations interconnected in a dual-ring configuration. The IEEE 802.17b spatially aware sublayer amendment is not yet ratified but is expected to add support for bridging to IEEE 802.17. Since the amendment is not yet ratified, no equipment is currently IEEE 802.17b compliant. The ML-Series card's RPR-IEEE is based on the expected IEEE 802.17b based standard.

The ML-Series card supports RPR-IEEE. RPR-IEEE is well suited for transporting Ethernet over a SONET/SDH ring topology and enables multiple ML-Series cards to become one functional network segment. When used in this role, RPR-IEEE overcomes the limitations of earlier schemes, such as IEEE 802.1D Spanning Tree Protocol (STP), IEEE 802.1W Rapid Spanning Tree Protocol (RSTP), and SONET/SDH.

Note Throughout this book, Cisco proprietary RPR is referred to as Cisco proprietary RPR, and IEEE 802.17b-based RPR is referred to as RPR-IEEE. This chapter covers RPR-IEEE. Chapter 17, "Configuring Cisco Proprietary Resilient Packet Ring" covers Cisco Proprietary RPR.

RPR-IEEE Features on the ML-Series Card

See the "ML-Series Feature List" section on page 1-2 for a list of the ML-Series card's supported and non-supported features based on the expected IEEE 802.17b.

Advantages of RPR-IEEE

In Software Release 7.2 and later, the ML-Series card supports RPR-IEEE in addition to Cisco proprietary RPR. Some of the advantages of RPR-IEEE include:

•Steering. Ring protection is accomplished through steering instead of wrapping. Steering is a more efficient way of routing around a failure.

•Dual-transit queues. Dual-transit queues offer more control in handling transit traffic.

•Best-effort traffic classifications. "Best Effort" and "EIR" traffic classifications improve distribution of traffic across a best-effort service class.

•Interoperability. Conformance to the expected IEEE 802.17b standard increases interoperability with third-party vendors.

•Built-in service provider support. RPR-IEEE provides built-in operations, administration, and maintenance (OAM) support for service provider environments.

•Fairness. Fairness allows all the stations on the ring to fairly share the RPR-IEEE's best-effort bandwidth.

Role of SONET/SDH Circuits

The ML-Series cards in an RPR-IEEE must connect directly or indirectly through point-to-point synchronous transport signal/synchronous transport module (STS/STM) circuits. The point-to-point STS/STM circuits are configured on the ONS node through Cisco Transport Controller (CTC) or Transaction Language One (TL1) and are transported over the ONS node's SONET/SDH topology on either protected or unprotected circuits.

On circuits unprotected by the SONET/SDH mechanism, RPR-IEEE provides resiliency without using the capacity of the redundant protection path that a SONET/SDH protected circuit would require. This frees this capacity for additional traffic. RPR-IEEE also utilizes the bandwidth of the entire ring and does not block segments like STP or RSTP.

An RPR-IEEE is made up of dual counter-rotating rings (ringlets), one for clockwise or west data traffic and one for counter-clockwise or east data traffic. The ringlets are identified as Ringlet 0 and Ringlet 1 in Figure 26-1. The west ringlet traffic is transmitted out the west interface and received by the east interface. The east ringlet traffic is transmitted out the east interface and received by the west interface. Only east-to-west or west-to-east transmission schemes are allowed.

Figure 26-1 Dual-Ring Structure

RPR-IEEE Framing Process

The ML-Series card transports data around the RPR-IEEE through packet-over-SONET/SDH (POS) circuits. With POS, the RPR-IEEE frame is encapsulated into the SONET/SDH payload for transport over the SONET/SDH topology. For more information about POS, see Chapter 20, "POS on ONS Ethernet Cards."

Figure 26-2 illustrates the IEEE 802.17 basic data frame for IP only networks and the expected IEEE 802.17b extended data frame used with bridging. The extended data frame adds an extended destination address and extended source address to the basic data frame.

Figure 26-2 RPR-IEEE Data Frames

Table 26-1 defines the most important fields in the RPR-IEEE data frame.

Table 26-1 Definitions of RPR-IEEE Frame Fields

Field
Definition
MAC Destination Address (MAC da)

A forty-eight-bit field specifying the destination as a multicast MAC address or the MAC address of a specific ML-Series card in the RPR-IEEE.

MAC Source Address (MAC sa)

A fourth-eight-bit field specifying the MAC address of a specific ML-Series card in the RPR-IEEE as the source.

Base Control

A field that includes the ring indicator (RI) bit, the fairness eligible (FE) bit, the frame type (FT) bit, and the service class (SC) bit.

TTL Base

A field that contains the time to live (TTL) setting. The sending station sets the TTL, which remains unchanged for the life of the packet.

Extended Control

A field that contains the flood indicator (FI) bit and the strict order (SO) bit.

Extended DA

A forty-eight-bit field specifying the MAC address of the ultimate destination.

Extended SA

A forty-eight-bit field specifying the MAC address of the ultimate source.


Figure 26-3 illustrates the RPR-IEEE topology and protection control frame. Topology and protection (TP) frames are usually sent to the broadcast address.

Figure 26-3 Topology and Protection Control Frame Formats

Figure 26-4 illustrates the RPR-IEEE fairness frame. Fairness frames are sent either to all stations or only the nearest neighbor depending on whether it is a single-choke fairness frame (SCFF) or multi-choke fairness frame (MCFF). Fairness frames are included in the total bandwidth of the QoS A0 service class. This eliminates the need for a destination address (DA). The MCFF type also includes an additional frequency division duplexing (FDD) frame to help smooth the fairness variation. The field SA Compact is the address of the station providing the fair rate.

Note The ML-Series card supports multi-choke fairness frames from other stations on the RPR-IEEE. The ML-Series card does not generate these frames.

Figure 26-4 Fairness Frame Format

For comparison of RPR-IEEE frames and Cisco proprietary RPR frames, see the "Cisco Proprietary RPR Framing Process" section on page 17-5 for Cisco proprietary RPR framing information.

CTM and RPR-IEEE

Cisco Transport Manager (CTM) is an element management system (EMS) designed to integrate into an overall network management system (NMS) and interface with other higher level management tools. CTM supports RPR-IEEE provisioning on ML-Series cards. For more information, refer to the Cisco Transport Manager User Guide at:

http://www.cisco.com/en/US/products/sw/opticsw/ps2204/products_user_guide_list.html

Configuring RPR-IEEE Characteristics

Configuration tasks for RPR-IEEE characteristics are presented in the following sections:

•General characteristics:

– Configuring the Attribute Discovery Timer

– Configuring the Reporting of SONET Alarms

– Configuring BER Threshold Values

•Protection characteristics:

– Configuring the Hold-off Timer

– Configuring Jumbo Frames

– Configuring Forced or Manual Switching

– Configuring Protection Timers

– Configuring the Wait-to-Restore Timer

– Configuring a Span Shutdown

– Configuring Keepalive Events

•QoS characteristics:

– Configuring Traffic Rates for Transmission

– Configuring Fairness Weights

– Configuring RPR-IEEE Service Classes Using the Modular QoS CLI

Configuring the Attribute Discovery Timer

Because station attributes are communicated separately from topology and protection packets, there is a separate timer to control the frequency at which these packets are sent. Attribute propagation is therefore determined by the attribute discovery (ATD) timer. The default rate is one packet per second for each ringlet.

Note Configure both ringlets with the same value.

To enable and configure the ATD, perform the following procedure, beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# interface rpr-ieee 0


Activates interface configuration mode to configure the RPR-IEEE interface.

Step 2 

Router(config-if)# rpr-ieee atd-timer seconds


Specifies the time, in seconds, within which one station attributes packet is sent for each ringlet. The default is one packet for each ringlet per second.

Step 3 

Router(config)# no shut

Enables the RPR-IEEE interface and changes the mode from the default passthrough.

Step 4 

Router(config)# end

Returns to privileged EXEC mode.

Step 5 

Router# copy running-config startup-config

(Optional) Saves configuration changes to the TCC2/TCC2P flash database.

Configuring the Reporting of SONET Alarms

The ML-Series card reports SONET/SDH alarms through the CTC alarm panel in the same manner as other ONS cards. The ML-Series card can also report SONET/SDH alarms through the Cisco IOS command-line interface (CLI). Configuring CTC reporting does not affect Cisco IOS CLI reporting or vice-versa.

To configure the reporting of SONET/SDH alarms on the Cisco IOS CLI, perform the following procedure, beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# interface rpr-ieee 0


Activates interface configuration mode to configure the RPR-IEEE interface.

Step 2 

Router(config-if)# rpr-ieee report {all | encap | pais | plop | ppdi | pplm | prdi ptim | puneq | sd-ber-b3 | sf-ber-b3} [east | west]

Enables reporting of specific SONET/SDH alarms on the Cisco IOS CLI. The default is to report all alarms on both the east and west ringlet.

(Optional) You can also specify the east or west ringlet.

Step 3 

Router(config)# no shut

Enables the RPR-IEEE interface and changes the mode from the default passthrough.

Step 4 

Router(config)# end

Returns to privileged EXEC mode.

Step 5 

Router# copy running-config startup-config

(Optional) Saves configuration changes to the TCC2/TCC2P flash database.

Configuring BER Threshold Values

To configure BER threshold values for various alarms on an RPR-IEEE interface, refer to the "DLP-A533 Create Ethernet RMON Alarm Thresholds" task in the Cisco ONS 15454 Procedure Guide or to the "DLP-D441 Create Ethernet RMON Alarm Thresholds" task in the Cisco ONS 15454 SDH Procedure Guide.

Configuring RPR-IEEE Protection

RPR-IEEE has three protection states:

•Closed—This is the normal steady state. Data traffic is traveling around the RPR-IEEE on both Ringlet 0 and Ringlet 1. Figure 26-1 illustrates this state.

•Open—This is the state after a protection event. A protection event, such as a fiber cut or node failure, triggers a change in the ring topology. Each node responds to the new topology by steering. Steering forwards data traffic so that it avoids the failure. Based on the type of failure, it will avoid either a specific span or a node and its two adjoining spans. Figure 26-5 illustrates this state.

•Passthrough—This is the initial state of the RPR-IEEE node. It does not participate in the topology and blindly forwards frames.

Figure 26-5 Each RPR-IEEE Node Responding to a Protection Event by Steering

You can modify many of the RPR-IEEE protection characteristics with the procedures in the following sections.

Configuring the Hold-off Timer

You can delay the protection response to a failure event, such as a signal failure or signal degradation, with the hold-off timer. When spans fail, the RPR protection switch may be triggered either by the SONET/SDH error, or by RPR keepalive failure, whichever is detected first. The RPR protection switch can be delayed by changing the Hold-off timer and the RPR keepalive-timer. These should be configured according to the type of circuit

•If the TDM circuit is unprotected, then both these timers should be left at their default values. No extra configuration is required in this case.

•When the TDM circuit is protected (e.g., path protection or BLSR), the RPR protection switch should be delayed till the protection-switch at the TDM level has finished.

–For example : If it takes 60ms for the TDM protection switch to complete. Then both the hold off timer and the RPR keepalive timer must be configured higher than 60 milliseconds. If either of these timers is left at its default value, then it will trigger the RPR protection before TDM protection is over.

Caution It TDM protection is configured along with RPR, and if the RPR protection switch kicks in before the TDM protection switch over is complete, the system behavior is unpredictable/unstable.

To enable and configure the hold-off timer, perform the following procedure, beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# interface rpr-ieee 0

Activates interface configuration mode to configure the RPR-IEEE interface.

Step 2 

Router(config-if)# rpr-ieee protection sonet holdoff-timer time [east | west]

Specifies the delay before a protection response is sent. Values range from 0 to 20, in units of 10 milliseconds. The default is 0.

(Optional) You can also specify the east or west ringlet.

Caution When using SW-LCAS on the RPR-IEEE, the addition or deletion of a SW-LCAS member circuit causes a traffic hit with a maximum of 50 msec. The holdoff timer requires a value greater than 5 (50 msec) or the SW-LCAS addition or deletion triggers a protection response

Step 3 

Router(config)# no shut

Enables the RPR-IEEE interface and changes the mode from the default passthrough.

Step 4 

Router(config)# end

Returns to privileged EXEC mode.

Step 5 

Router# copy running-config startup-config

(Optional) Saves configuration changes to the TCC2/TCC2P flash database.

Configuring Jumbo Frames

You can configure the interface to support jumbo frames. The jumbo setting specifies that the station support a maximum transfer unit (MTU) of up to 9100 bytes.

Caution For jumbo frame support, you must configure all the stations on the ring to support jumbo frames.

To enable and configure Jumbo frames, perform the following procedure, beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# interface rpr-ieee 0


Activates interface configuration mode to configure the RPR-IEEE interface.

Step 2 

Router(config-if)# rpr-ieee protection pref jumbo

Enables jumbo frame capability on the RPR-IEEE interface:

jumbo—Enables handling of frames in excess of the standard size, up to a maximum size of 9100 bytes. A jumbo-enabled station changes the interface MTU to 9100 bytes if all stations in the ring are jumbo enabled. A message is generated to indicate that the ring supports jumbo frames when all stations are configured for this preference.

The default is to not support jumbo frames.

Step 3 

Router(config)# no shut

Enables the RPR-IEEE interface and changes the mode from the default passthrough.

Step 4 

Router(config)# end

Returns to privileged EXEC mode.

Step 5 

Router# copy running-config startup-config

(Optional) Saves configuration changes to the TCC2/TCC2P flash database.

Configuring Forced or Manual Switching

You can request certain protection states to take effect manually on either span of the interface to avoid link usage or in anticipation of failures.

To enable and configure forced or manual switching, perform the following procedure, beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# interface rpr-ieee 0


Activates interface configuration mode to configure the RPR-IEEE interface.

Step 2 

Router(config-if)# rpr-ieee protection request {forced-switch | manual-switch} {east | west}


Specifies that a switch take place on the interface:

forced-switch—Precedes all other failure events on a ring for the span on which it is configured. The operation protects the span indicated by the command. In the case of steering, forwarding uses only the topology list for the opposite span. A forced switch is saved in the configuration.

manual-switch—Behaves similarly to a forced switch, in that it coerces a reaction from the protection system. The difference is that this configuration can be usurped by higher-level requests detected on the configured or the opposite span. A manual switch is not saved in the configuration. Configuring a manual Swich on a span that has a forced switch configured wiil clear the forced switch.

Note When a manual switch is configured, it will neither display in the running configuration nor save to the startup configuration.

You must specify whether the switch is to take place on the east or west ringlet.

Step 3 

Router(config)# no shut

Enables the RPR-IEEE interface and changes the mode from the default passthrough.

Step 4 

Router(config)# end

Returns to privileged EXEC mode.

Step 5 

Router# copy running-config startup-config

(Optional) Saves configuration changes to the TCC2/TCC2P flash database.

Configuring Protection Timers

Protection messages are sent based on the intervals of two timers. These timers apply under different circumstances:

•Fast timer—Immediately after a protection event occurs, a fast protection timer is used. This timer is configured between 1 and 20 milliseconds to cause a rapid acknowledgement of the protected state on the ring. A finite number of packets are sent at this frequency after the event. The default for this timer is 10 milliseconds.

•Slow timer—Between protection events, the slow timer communicates the current protection state of the ring. This timer is configured from 1 to 10 in units of 100 milliseconds. The default is 10, which represents 100 milliseconds.

The protection timers are configured the same on both spans of an interface.

To enable and configure the protection timers, perform the following procedure, beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# interface rpr-ieee 0


Activates interface configuration mode to configure the RPR-IEEE interface.

Step 2 

Router(config-if)# rpr-ieee protection timer {fast time | slow time}

Specifies the value of the fast or slow protection timer:

fast—Ranges from 1 to 20 milliseconds. The default is 10.

slow—Ranges from 1 to 10 in units of 100 milliseconds. The default is 1 (100 milliseconds).

Step 3 

Router(config)# no shut

Enables the RPR-IEEE interface and changes the mode from the default passthrough.

Step 4 

Router(config)# end

Returns to privileged EXEC mode.

Step 5 

Router# copy running-config startup-config

(Optional) Saves configuration changes to the TCC2/TCC2P flash database.

Configuring the Wait-to-Restore Timer

When the failure is fixed, a wait-to-restore timer defines how long before the span reverts to its original state. This timer protects against false negatives in the detection of the failure status, which can avoid protection-flapping through the use of larger values. Smaller values result in faster recovery times, however. This timer can be configured between 0 and 1440 seconds, or configured to not recover automatically. The default for the timer is 10 seconds.

To enable and configure the wait-to-restore timer, perform the following procedure, beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# interface rpr-ieee 0


Activates interface configuration mode to configure the RPR-IEEE interface.

Step 2 

Router(config-if)# rpr-ieee protection wtr-timer {time | never}

Specifies the value of the wait-to-restore timer:

time—Ranges from 0 to 1440 seconds. The default is 10.

never—Specifies that protection is never restored (no revert mode).

Step 3 

Router(config)# no shut

Enables the RPR-IEEE interface and changes the mode from the default passthrough.

Step 4 

Router(config)# end

Returns to privileged EXEC mode.

Step 5 

Router# copy running-config startup-config

(Optional) Saves configuration changes to the TCC2/TCC2P flash database.

Configuring a Span Shutdown

The rpr-ieee shutdown command performs the same task as the rpr-ieee protection request forced-switch command.

To cause a forced switch on the span of the interface, perform the following procedure, beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# interface rpr-ieee 0


Activates interface configuration mode to configure the RPR-IEEE interface.

Step 2 

Router(config-if)# rpr-ieee shutdown {east | west}

Causes a forced switch on a specified span of the interface.

Step 3 

Router(config)# end

Returns to privileged EXEC mode.

Step 4 

Router# copy running-config startup-config

(Optional) Saves configuration changes to the TCC2/TCC2P flash database.

Configuring Keepalive Events

A station receives fairness messages from a link to determine its status. When the number of milliseconds that pass without receiving a fairness message from the neighboring stations exceeds a specified timer, a keepalive event is triggered. The keepalive event generates a protection event.

The timer can have a different value on each span and must be greater than or equal to the hold-off timer. This feature is independent of the fairness algorithm itself, but is still a function performed by the fairness machine.

The RPR protection switch can be delayed by changing the Hold-off timer and the RPR keepalive-timer. These should be configured according to the type of circuit

•If the TDM circuit is unprotected, then both these timers should be left at their default values. No extra configuration is required in this case.

•When the TDM circuit is protected (e.g., path protection or BLSR), the RPR protection switch should be delayed till the protection-switch at the TDM level has finished.

–For example : If it takes 60ms for the TDM protection switch to complete. Then both the hold off timer and the RPR keepalive timer must be configured higher than 60 milliseconds. If either of these timers is left at its default value, then it will trigger the RPR protection before TDM protection is over.

Caution If TDM protection is configured along with RPR, and if the RPR protection switch kicks in before the TDM protection switch over is complete, the system behavior is unpredictable/unstable.

To enable and configure the keepalives, perform the following procedure, beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# interface rpr-ieee 0


Activates interface configuration mode to configure the RPR-IEEE interface.

Step 2 

Router(config-if)# rpr-ieee keepalive-timer milliseconds [east | west]


Specifies the amount of time that can pass before a keepalive event is triggered after not receiving a fairness message from a neighboring station. Values range from 2 to 200 milliseconds. The default is 3 milliseconds.

(Optional) You can also specify the east or west ringlet.

Step 3 

Router(config)# no shut

Enables the RPR-IEEE interface and changes the mode from the default passthrough.

Step 4 

Router(config)# end

Returns to privileged EXEC mode.

Step 5 

Router# copy running-config startup-config

(Optional) Saves configuration changes to the TCC2/TCC2P flash database.

Configuring Triggers for CRC Errors

You can configure a span shutdown when the ML-Series card receives CRC errors at a rate that exceeds the configured threshold and configured soak time.

To enable and configure the triggers for CRC errors, perform the following procedure, beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# interface rpr-ieee 0

Activates interface configuration mode to configure the RPR-IEEE interface.

Step 2 

Router(config-if)# trigger crc-error threshold crc-error-rate {east | west | <cr>}

Configures the threshold for the CRC errors on the RPR-IEEE span. The threshold is the percentage of received, continously CRC-errored frames required during the delay period (soak time). When the threshold is crossed, the excessive crc alarm is declared. This also triggers the CRC error action, if one is configured.

For crc-error-rate, specify the CRC packet error rate variable in the range from 2 to 4. The error rate variable corresponds to the CRC error rate as a percentage of traffic.

•2 is 10e-2 or 1% of traffic (1 CRC error in100 frames).

•3 is 10e-3 or 0.1% of traffic. (1 CRC error in1000 frames).

•4 is 10e-4 or 0.01% of traffic (1 CRC error in10000 frames).

The default threshold is 3.

(Optional) You can also specify the east or west ringlet.

Step 3 

Router(config-if)# trigger crc-error action {east | west | <cr>}

Specifies whether excessive CRC errors shut down the span. The default is for excessive CRC errors not to shut down the span.

(Optional) You can also specify the east or west ringlet.

Caution The user must configure both spans to shut down on receiving excessive CRC errors. With the default behavior of both spans not shutting down, network problems can occur if the ML-Series card receives signal degrade (SD) while in passthrough mode.

Step 4 

Router(config-if)# trigger crc-error delay soak-minutes {east | west | <cr>}

(Optional) Sets the number of minutes that CRC errors must exceed the threshold (soak) before an action is taken. For soak-minutes, the range is from 3 minutes to 10 minutes. The default is 10 minutes.

(Optional) You can also specify the east or west ringlet.

Step 5 

Router(config)# no shut

Enables the RPR-IEEE interface and changes the mode from the default passthrough.

Step 6 

Router(config)# end

Returns to privileged EXEC mode.

Step 7 

Router# copy running-config startup-config

(Optional) Saves configuration changes to the TCC2/TCC2P flash database.

Configuring QoS on RPR-IEEE

The different priorities of traffic can be configured with rate limiters and prescribed specific bandwidths. This configuration on each span might be identical (default) or might vary from the other span.

The highest-priority traffic, known as service class A0, can reserve a portion of total ringlet bandwidth using the reserved keyword. This reservation is propagated throughout the ringlet, and all stations recognize the bandwidth allocation cumulatively. Reserved A0 ba802.17 RPR defines 3 service classes, each with unique QOS characteristics.

1. Class A

2. Class B

3. Class C

With this different priorities of traffic can be configured with rate limiters and prescribed specific bandwidths. This configuration on each span might be identical (default) or might vary from the other span.

Class A

Class A is highest priority, lowest latency, and lowest jitter class . A has two types - A0 and A1. Can reserve a portion of the ringlet bandwidth using "reserve" keyword. This bandwidth is known as A0 bandwidth. The A0 bandwidth can only be used for classA traffic. Any Reserved bandwidth that is unused will remain unused on the ring, Reserved bandwidth is therefore expensive because it reduces the bandwidth available for best effort. This reservation is propagated throughout the ringlet, and all RPR stations recognize the bandwidth allocation cumulatively. Reserved A0 bandwidth can be used only by the station that reserves it. The default allocation is 0 Mbps. The unreserved classA bandwidth is called the A1 bandwidth. Service class A1 is configured as high-priority traffic in excess of the A0 bandwidth reservation, and can be rate-limited using the high tx-traffic rate limiter. The default allocation for A1 is 5 Mbps.

ClassB

This is the medium traffic priority. Lower priority than classA, but higher priority than classC. The medium transmit traffic rate limiter allows a certain amount of traffic to be added to the ringlet that is not subject to fairness eligibility, but must compete for the unreserved bandwidth with other traffic of the same service class. This traffic is committed information rate (B-CIR) traffic. The default allocation is 10 Mbps.

ClassC

This is the lowest traffic priority. Class C cannot allocate any ring bandwidth guarantees

MQC -IEEE RPR CLI Characteristics

•IEEE-RPR classes are applicable to both front end and RPR-IEEE interfaces.

•A MQC class in a policy map can be mapped to one of the RPR classes using "set rpr-ieee service class". By default the MQC class maps to IEEE-RPR class C.

•RPR classes B and C support Weighted Round Robin scheduling for multiple MQC classes mapping to RPR class A and B. MQC classes mapped to RPR class A gets mapped to one stream, while each MQC class mapped to RPR class B or C gets mapped to a seperate stream.

•The "Bandwidth percent" action is supported for MQC classes mapping to RPR class B and C. The bandwidth percent for these MQC classes defines the proportion of b/w these class B and C stream will get, out of total b/w available to class B and C (whatever remains after class A traffic) . Both these RPR classes allow 100% each. Trying to assign more than 100% will be rejected with an error .

•The MQC class mapped to IEEE RPR class B or C with no explicit "bandwidth percent" configured gets a default 7% bandwidth.

•Bandwidth absolute/ percent action is not supported on rpr-ieee interfaces but only on Gig/Fast Ethernet interfaces.

Configuring Traffic Rates for Transmission

To enable and configure the traffic rates, perform the following procedure, beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# interface rpr-ieee 0


Activates interface configuration mode to configure the RPR-IEEE interface.

Step 2 

Router(config-if)# rpr-ieee tx-traffic rate-limit {reserved | high | medium} rate [east | west]

Specifies a rate limit on a traffic queue. The allowable rate depends on the speed of the interface.

reserved—Reserves bandwidth for the highest priority traffic, known as service class A0. The default allocation is 0 Mbps.

high—Limits the rate of service class A1. The default allocation is 10 Mbps.

medium—Limits the rate of service class B-CIR. The default allocation is 10 Mbps.

(Optional) Specify the east or west ringlet.

Step 3 

Router(config)# no shut

Enables the RPR-IEEE interface and changes the mode from the default passthrough.

Step 4 

Router(config)# end

Returns to privileged EXEC mode.

Step 5 

Router# copy running-config startup-config

(Optional) Saves configuration changes to the TCC2/TCC2P flash database.

Configuring Fairness Weights

RPR-IEEE has a configurable fairness system, used to control congestion on each ringlet. This feature moderates bandwidth utilization of the ringlet to minimize and potentially eliminate starvation of any station. Each station has two instances of the fairness machine, to control traffic that is being transmitted and transited out of each span of the interface. Each fairness machine is devoted to a particular ringlet, and controls the traffic that is destined to that ringlet.

Each ringlet in an unwrapped ring is independent, and the fairness configuration can differ for each direction. The default is to configure both directions, but you can optionally specify east or west in the configuration.

The local station weight impacts how congested the station appears relative to other stations in the ringlet. It also affects how much more bandwidth a station can use. A higher weight gives the local station a greater share of the ringlet bandwidth. A lower weight decreases the bandwidth share of the local station. The default value is 0 configured as an exponent of 2, which yields an effective weight of 1.

To enable and configure the fairness weight, perform the following procedure, beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# interface rpr-ieee 0


Activates interface configuration mode to configure the RPR-IEEE interface.

Step 2 

Router(config-if)# rpr-ieee fairness weight weight [east | west]

Specifies the weight for a station on the ringlet. Values can range from 0 to 7 and are configured as an exponent of 2, which results in weights ranging from 1 to 128. The default value is zero.

(Optional

Step 3 

Router(config)# no shut

Enables the RPR-IEEE interface and changes the mode from the default passthrough.

Step 4 

Router(config)# end

Returns to privileged EXEC mode.

Step 5 

Router# copy running-config startup-config

(Optional) Saves configuration changes to the TCC2/TCC2P flash database.

Configuring RPR-IEEE Service Classes Using the Modular QoS CLI

Traffic is directed to the three service classes supported by RPR-IEEE by using the standard Cisco Modular QoS CLI (MQC). MQC is a CLI structure that allows you to create traffic policies and attach these policies to interfaces. A traffic policy contains a traffic class and one or more QoS features. A traffic class classifies traffic, while the QoS features in the traffic policy determine how to treat the classified traffic.

For more information on general MQC configuration, refer to the following Cisco IOS documents:

•Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2 at this URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122mindx/l22index.htm

•Cisco IOS Quality of Service Solutions Command Reference, Release 12.2 at this URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_r/index.htm

Caution The cos priority-mcast command is not supported under RPR-IEEE on the ML-Series card or accepted. The command incorrectly shows as an option under the Cisco IOS CLI.
Caution In IEEE-RPR mode if additional class maps are added to a policy map and associated the policy map with a output interface even if no bandwidth is reserved explicitly, by default 7% bw is allocated and once the bandwidth reaches more thant 100% further class-map configuration on that policy-map is rejected.

To enable and configure the RPR-IEEE service classes with the MQC, perform the following procedure, beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# class-map match-any class-name


Specifies the user-defined name of the traffic class and the logical OR operator for all matching statements under this traffic class.

Step 2 

Router(config)# match ip precedence {ip-precedence-value | ip-precedence-traffic-label}

Specifies an IP precedence value (0 to 7) used as match criteria or specifies an IP precedence traffic label.

Each value variable is mapped to a specific label variable. Entering the command with a ? in place of the ip-precedence-value | ip-precedence-traffic-label variable reveals the labels and their corresponding values.

Step 3 

Router(config)# exit

Exits class mode.

Step 4 

Router(config)# policy-map policy-name

Specifies the name of the service policy to configure. Service policies link the configured class maps to Layer 2 traffic priorities, or in this case, the three service classes of RPR-IEEE.

Note An assignment has to be constructed for each class map.

Step 5 

Router(config)# class class-name

Specifies the name of a predefined class, which was defined with the class-map command, to be included in the service policy.

Note Each of the three RPR-IEEE classes must be configured as described in this procedure.

Step 6 

Router(config)# set rpr-ieee service-class {a | b | c}

Specifies the appropriate RPR-IEEE service class for the class. The three classes correspond to each of the three RPR-IEEE service classes. Only one service class can be configured for each MQC class.

Step 7 

Router(config)# exit

Exits class mode.

Step 8 

Router(config)# no shut

Enables the RPR-IEEE interface and changes the mode from the default passthrough.

Step 9 

Router(config)# end

Returns to privileged EXEC mode.

Step 10 

Router# copy running-config startup-config

(Optional) Saves configuration changes to the TCC2/TCC2P flash database.

Configuration Example for RPR-IEEE QoS

The following sample configurations are for RPR-IEEE QoS. Example 26-1 details a simple QoS configuration. Example 26-7 details a more complex configuration. The configuration on your network will differ based on your network design.

Configuration Example Using MQC to Configure Simple RPR-IEEE QoS

The following is an example of the configuration process for the three RPR-IEEE service classes:

Example 26-1 Configuration Example for a Simple RPR-IEEE QoS Configuration

class-map match-any DataHi
match cos 2 3 4
class-map match-any Control
match cos 5 6 7
policy-map EgrNNI
class Control

set rpr-ieee service-class a
class DataHi
set rpr-ieee service-class b
class class-default
set rpr-ieee service-class c
!
interface RPR-IEEE0
no ip address
rpr-ieee protection pref jumbo
rpr-ieee tx-traffic rate-limit high 100 east
rpr-ieee tx-traffic rate-limit high 100 west
rpr-ieee tx-traffic rate-limit medium 200 east
rpr-ieee tx-traffic rate-limit medium 200 west
service-policy output EgrNNI

Configuration Example Using MQC to Configure Complex RPR-IEEE QoS

The following is an example of a more complex RPR-IEEE QoS configuration:

Example 26-2 Configuration Example for a Complex RPR-IEEE

class-map match-all classA
match bridge-group 22
!
!
policy-map EgrNNI
class classA
set rpr-ieee service-class a
class class-default
set rpr-ieee service-class c
!
bridge irb
!
!
interface GigabitEthernet0
no ip address
mode dot1q-tunnel
l2protocol-tunnel cdp
l2protocol-tunnel stp
l2protocol-tunnel vtp
no cdp enable
bridge-group 20
bridge-group 20 spanning-disabled
!
interface GigabitEthernet1
no ip address
mode dot1q-tunnel
l2protocol-tunnel cdp
l2protocol-tunnel stp
l2protocol-tunnel vtp
no cdp enable
bridge-group 22
bridge-group 22 spanning-disabled
!
interface RPR-IEEE0
ip address 1.1.1.3 255.255.255.0
rpr-ieee fairness mode aggressive
service-policy output EgrNNI
!
interface RPR-IEEE0.20
encapsulation dot1Q 20
no snmp trap link-status
bridge-group 20
bridge-group 20 spanning-disabled
!
interface RPR-IEEE0.22
encapsulation dot1Q 22
no snmp trap link-status
bridge-group 22
bridge-group 22 spanning-disabled
!
interface RPR-IEEE0.30
encapsulation dot1Q 30
no snmp trap link-status
bridge-group 30
bridge-group 30 spanning-disabled
!
ip classless

Verifying and Monitoring RPR-IEEE

After RPR-IEEE is configured, you can use the following commands to verify setup and monitor its status:

•The show interface rpr-ieee interface-number command ( Example 26-3) displays the following for an interface:

–Primary or secondary status (if RI is activated)

–Active or standby mode (if RI is activated)

–Up or down (pass-through mode) status

–Monitoring status and by extension, general protection status

•The show interface rpr-ieee fairness detail command ( Example 26-4) displays the following for an interface:

–Total bandwidth

–Traffic class configured transmission rates

–Fairness weight settings for the interface

–Instances of congestion

•The show rpr-ieee protection command ( Example 26-5) displays the following for an interface:

–Station and neighbor interface MAC addresses

–Protection timer settings

–Ring protection status

–Span failures

•The show rpr-ieee topology detail command ( Example 26-6) displays the following for the ring:

–Station names and neighbor MAC addresses of all stations on the ring

–Traffic class configured transmission rates for all stations on the ring

–Fairness weight settings for all stations on the ring

–Jumbo frame status (on or off) for all stations on the ring

–ATD information for all stations on the ring

–Protection mode for all nodes on the ring

–Secondary MAC addresses for all stations on the ring

Example 26-3 show interface rpr-ieee 0 Output

router# show interface rpr-ieee 0
RPR-IEEE0 is up, line protocol is up
Hardware is RPR-IEEE Channelized SONET, address is 000e.8312.bcf0 (bia 000e.8312.bcf0)
MTU 1500 bytes, BW 145152 Kbit, DLY 100 usec,
reliability 255/255, txload 105/255, rxload 99/255

Encapsulation: RPR-IEEE,
West Span: loopback not set
East Span: loopback not set
MAC passthrough not set
RI: primary,active peer mac 000e.8312.b870
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)

West Span: 5 minutes output rate 57872638 bits/sec, 25307 packets/sec
5 minutes input rate 57786924 bits/sec, 25268 packets/sec
East Span: 5 minutes output rate 2765315 bits/sec, 1197 packets/sec
5 minutes input rate 0 bits/sec, 0 packets/sec
26310890 packets input, 3230040117 bytes
Received 0 broadcasts (0 IP multicast)
0 runts, 0 giants, 0 throttles
3 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast
0 input packets with dribble condition detected
32138811 packets output, 601868274 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

Example 26-4 show rpr-ieee fairness detail Output

router# show rpr-ieee fairness detail
IEEE 802.17 Fairness on RPR-IEEE0:
Bandwidth: 96768 kilobits per second
Station using aggressive rate adjustment.
Westbound Tx (Ringlet 1)
Weighted Fairness:
Local Weight: 0 (1)
Single-Choke Fairness Status:
Local Congestion:
Congested? No
Head? No
Local Fair Rate:
Approximate Bandwidth: 64892 Kbps
25957 normalized bytes per aging interval
51914 bytes per ageCoef aging interval
Downstream Congestion:
Congested? No
Tail? No
Received Source Address: 0000.0000.0000
Received Fair Rate:
Approximate Bandwidth: FULL RATE
65535 normalized bytes per aging interval

Reserved Rate:
0 Kbps
0 bytes per aging interval
Unreserved Rate:
96768 Kbps
4838 bytes per aging interval
Allowed Rate:
Approximate Bandwidth: 96000 Kbps
4800 bytes per aging interval
Allowed Rate Congested:
Approximate Bandwidth: 96000 Kbps
4800 bytes per aging interval
TTL to Congestion: 255
Total Hops Tx: 4
Advertised Fair Rate:
Approximate Bandwidth: FULL RATE
65535 normalized bytes per aging interval
8191 bytes per aging interval
Eastbound Tx (Ringlet 0)
Weighted Fairness:
Local Weight: 0 (1)
Single-Choke Fairness Status:
Local Congestion:
Congested? No
Head? No
Local Fair Rate:
Approximate Bandwidth: 0 Kbps
0 normalized bytes per aging interval
0 bytes per ageCoef aging interval
Downstream Congestion:
Congested? No
Tail? No
Received Source Address: 0000.0000.0000
Received Fair Rate:
Approximate Bandwidth: FULL RATE
65535 normalized bytes per aging interval

Reserved Rate:
0 Kbps
0 bytes per aging interval
Unreserved Rate:
96768 Kbps
4838 bytes per aging interval
Allowed Rate:
Approximate Bandwidth: 96000 Kbps
4800 bytes per aging interval
Allowed Rate Congested:
Approximate Bandwidth: 96000 Kbps
4800 bytes per aging interval
TTL to Congestion: 255
Total Hops Tx: 4
Advertised Fair Rate:
Approximate Bandwidth: FULL RATE
65535 normalized bytes per aging interval
8191 bytes per aging interval

Example 26-5 show rpr-ieee protection Output

router# show rpr-ieee protection
Protection Information for Interface RPR-IEEE0
MAC Addresses
West Span (Ringlet 0 RX) neighbor 000b.fcff.9d34
East Span (Ringlet 1 RX) neighbor 0013.1991.1fc0
Station MAC address 0005.9a3c.59c0
TP frame sending timers:
fast timer: 10 msec
slow timer: 1x100 msec (100 msec)
Protection holdoff timers:
L1 Holdoff Keepalive Detection
West Span 0x10 msec ( 0 msec) West Span 5 msec
East Span 0x10 msec ( 0 msec) East Span 5 msec
Configured protection mode: STEERING
Protection Status
Ring is IDLE
Protection WTR period is 10 sec. (timer is inactive)
Self Detected Requests Remote Requests
West Span IDLE West Span IDLE
East Span IDLE East Span IDLE
Distant Requests
East Span IDLE West Span IDLE
West Span Failures: none
East Span Failures: none

Example 26-6 show rpr-ieee topology detail Output

Note The ip address field in the output of show rpr-ieee topology detail is populated only by the IP address that is applied to the rpr 0 main interface. It is not populated by the IP address of any of the sub-interfaces.

router# show rpr-ieee topology detail
802.17 Topology Display
RX ringlet0->West span RX ringlet1->East span
Number of nodes on
ringlet0: 5 ringlet1: 5
=======================================================================
Local Station Topology Info
=======================================================================
Topology entry:
Station MAC address: 0005.9a3c.59c0
West Span (Outer ringlet RX) neighbor 000b.fcff.9d34
East Span (Inner ringlet RX) neighbor 0013.1991.1fc0
Ring Topology: CLOSED (STABLE)
Containment Active: NO
A0 class reserved rate:
ringlet0: 0 (mbps) ringlet1: 0 (mbps)
Ringlet reserved rate:
ringlet0: 0 (mbps) ringlet1: 0 (mbps)
Ringlet unreserved rate:
ringlet0: 96 (mbps) ringlet1: 96 (mbps)
Ringlet effective unreserved rate:
ringlet0: 95.9 (mbps) ringlet1: 95.9 (mbps)
Advertised Protection requests:
ringlet0: IDLE ringlet1: IDLE
Active Edges:
ringlet0: NO ringlet1: NO
Configured protection mode: STEERING
Jumbo preference: NOT SET (ring doesn't support JUMBOS)
Is revertive: YES
Measured LRTT: 0
Sequence Number: 3
ATD INFO:
ATD timer: 1 sec
Station Name: ML100T-481
A0 reserved Bandwidth:
ringlet0: 0 mbps ringlet1: 0 mbps
SAS enabled: YES
Weight:
ringlet0: 1 ringlet1: 1
Secondary Mac Addresses:
MAC 1: 0000.0000.0000 (UNUSED)
MAC 2: 0000.0000.0000 (UNUSED)

=======================================================================
Topology Map for Outer ringlet
=======================================================================

=======================================================================
Topology entry at Index 1 on ringlet 0:
Station MAC address: 000b.fcff.9d34
Valid on ringlet0: YES
Entry reachable: YES
Advertised Protection requests:
ringlet0: IDLE ringlet1: IDLE
Active Edges:
ringlet0: NO ringlet1: NO
Preferred protection mode: STEERING
Jumbo preference: NOT SET (ring doesn't supports JUMBOS)
Measured LRTT: 0
Sequence Number: 3
ATD INFO:
Station Name: ML100X-491
A0 reserved Bandwidth:
ringlet0: 0 mbps ringlet1: 0 mbps
SAS enabled: YES
Weight:
ringlet0: 1 ringlet1: 1
Secondary Mac Addresses:
MAC 1: 0000.0000.0000 (UNUSED)
MAC 2: 0000.0000.0000 (UNUSED)
=======================================================================

Topology entry at Index 2 on ringlet 0:
Station MAC address: 0011.2130.b568
Valid on ringlet0: YES
Entry reachable: YES
Advertised Protection requests:
ringlet0: IDLE ringlet1: IDLE
Active Edges:
ringlet0: NO ringlet1: NO
Preferred protection mode: STEERING
Jumbo preference: NOT SET (ring doesn't supports JUMBOS)
Measured LRTT: 0
Sequence Number: 3
ATD INFO:
Station Name: ML1000-491
A0 reserved Bandwidth:
ringlet0: 0 mbps ringlet1: 0 mbps
SAS enabled: YES
Weight:
ringlet0: 1 ringlet1: 1
Secondary Mac Addresses:
MAC 1: 0000.0000.0000 (UNUSED)
MAC 2: 0000.0000.0000 (UNUSED)
=======================================================================

Topology entry at Index 3 on ringlet 0:
Station MAC address: 0005.9a39.7630
Valid on ringlet0: YES
Entry reachable: YES
Advertised Protection requests:
ringlet0: IDLE ringlet1: IDLE
Active Edges:
ringlet0: NO ringlet1: NO
Preferred protection mode: STEERING
Jumbo preference: NOT SET (ring doesn't supports JUMBOS)
Measured LRTT: 0
Sequence Number: 3
ATD INFO:
Station Name: ML1000-492
A0 reserved Bandwidth:
ringlet0: 0 mbps ringlet1: 0 mbps
SAS enabled: YES
Weight:
ringlet0: 1 ringlet1: 1
Secondary Mac Addresses:
MAC 1: 0000.0000.0000 (UNUSED)
MAC 2: 0000.0000.0000 (UNUSED)
=======================================================================

Topology entry at Index 4 on ringlet 0:
Station MAC address: 0013.1991.1fc0
Valid on ringlet0: YES
Entry reachable: YES
Advertised Protection requests:
ringlet0: IDLE ringlet1: IDLE
Active Edges:
ringlet0: NO ringlet1: NO
Preferred protection mode: STEERING
Jumbo preference: NOT SET (ring doesn't supports JUMBOS)
Measured LRTT: 0
Sequence Number: 3
ATD INFO:
Station Name: ML100T-482
A0 reserved Bandwidth:
ringlet0: 0 mbps ringlet1: 0 mbps
SAS enabled: YES
Weight:
ringlet0: 1 ringlet1: 1
Secondary Mac Addresses:
MAC 1: 0000.0000.0000 (UNUSED)
MAC 2: 0000.0000.0000 (UNUSED)
=======================================================================

Topology entry at Index 5 on ringlet 0:
Station MAC address: 0005.9a3c.59c0
Valid on ringlet0: YES
Entry reachable: YES
Advertised Protection requests:
ringlet0: IDLE ringlet1: IDLE
Active Edges:
ringlet0: NO ringlet1: NO
Preferred protection mode: STEERING
Jumbo preference: NOT SET (ring doesn't supports JUMBOS)
Measured LRTT: 0
Sequence Number: 3
ATD INFO:
Station Name: ML100T-481
A0 reserved Bandwidth:
ringlet0: 0 mbps ringlet1: 0 mbps
SAS enabled: YES
Weight:
ringlet0: 1 ringlet1: 1
Secondary Mac Addresses:
MAC 1: 0000.0000.0000 (UNUSED)
MAC 2: 0000.0000.0000 (UNUSED)
=======================================================================
Topology Map for Inner ringlet
=======================================================================

=======================================================================
Topology entry at Index 1 on ringlet 1:
Station MAC address: 0013.1991.1fc0
Valid on ringlet1: YES
Entry reachable: YES
Advertised Protection requests:
ringlet0: IDLE ringlet1: IDLE
Active Edges:
ringlet0: NO ringlet1: NO
Preferred protection mode: STEERING
Jumbo preference: NOT SET (ring doesn't supports JUMBOS)
Measured LRTT: 0
Sequence Number: 3
ATD INFO:
Station Name: ML100T-482
A0 reserved Bandwidth:
ringlet0: 0 mbps ringlet1: 0 mbps
SAS enabled: YES
Weight:
ringlet0: 1 ringlet1: 1
Secondary Mac Addresses:
MAC 1: 0000.0000.0000 (UNUSED)
MAC 2: 0000.0000.0000 (UNUSED)
=======================================================================

Topology entry at Index 2 on ringlet 1:
Station MAC address: 0005.9a39.7630
Valid on ringlet1: YES
Entry reachable: YES
Advertised Protection requests:
ringlet0: IDLE ringlet1: IDLE
Active Edges:
ringlet0: NO ringlet1: NO
Preferred protection mode: STEERING
Jumbo preference: NOT SET (ring doesn't supports JUMBOS)
Measured LRTT: 0
Sequence Number: 3
ATD INFO:
Station Name: ML1000-492
A0 reserved Bandwidth:
ringlet0: 0 mbps ringlet1: 0 mbps
SAS enabled: YES
Weight:
ringlet0: 1 ringlet1: 1
Secondary Mac Addresses:
MAC 1: 0000.0000.0000 (UNUSED)
MAC 2: 0000.0000.0000 (UNUSED)
=======================================================================

Topology entry at Index 3 on ringlet 1:
Station MAC address: 0011.2130.b568
Valid on ringlet1: YES
Entry reachable: YES
Advertised Protection requests:
ringlet0: IDLE ringlet1: IDLE
Active Edges:
ringlet0: NO ringlet1: NO
Preferred protection mode: STEERING
Jumbo preference: NOT SET (ring doesn't supports JUMBOS)
Measured LRTT: 0
Sequence Number: 3
ATD INFO:
Station Name: ML1000-491
A0 reserved Bandwidth:
ringlet0: 0 mbps ringlet1: 0 mbps
SAS enabled: YES
Weight:
ringlet0: 1 ringlet1: 1
Secondary Mac Addresses:
MAC 1: 0000.0000.0000 (UNUSED)
MAC 2: 0000.0000.0000 (UNUSED)
=======================================================================

Topology entry at Index 4 on ringlet 1:
Station MAC address: 000b.fcff.9d34
Valid on ringlet1: YES
Entry reachable: YES
Advertised Protection requests:
ringlet0: IDLE ringlet1: IDLE
Active Edges:
ringlet0: NO ringlet1: NO
Preferred protection mode: STEERING
Jumbo preference: NOT SET (ring doesn't supports JUMBOS)
Measured LRTT: 0
Sequence Number: 3
ATD INFO:
Station Name: ML100X-491
A0 reserved Bandwidth:
ringlet0: 0 mbps ringlet1: 0 mbps
SAS enabled: YES
Weight:
ringlet0: 1 ringlet1: 1
Secondary Mac Addresses:
MAC 1: 0000.0000.0000 (UNUSED)
MAC 2: 0000.0000.0000 (UNUSED)
=======================================================================

Topology entry at Index 5 on ringlet 1:
Station MAC address: 0005.9a3c.59c0
Valid on ringlet1: YES
Entry reachable: YES
Advertised Protection requests:
ringlet0: IDLE ringlet1: IDLE
Active Edges:
ringlet0: NO ringlet1: NO
Preferred protection mode: STEERING
Jumbo preference: NOT SET (ring doesn't supports JUMBOS)
Measured LRTT: 0
Sequence Number: 3
ATD INFO:
Station Name: ML100T-481
A0 reserved Bandwidth:
ringlet0: 0 mbps ringlet1: 0 mbps
SAS enabled: YES
Weight:
ringlet0: 1 ringlet1: 1
Secondary Mac Addresses:
MAC 1: 0000.0000.0000 (UNUSED)
MAC 2: 0000.0000.0000 (UNUSED)

Configuring RPR-IEEE End-to-End

You need to use both CTC and Cisco IOS to configure RPR-IEEE for the ML-Series card. CTC is the graphical user interface (GUI) that serves as the enhanced craft tool for specific ONS node operations, including the provisioning of the point-to-point SONET/SDH circuits required for RPR-IEEE. Cisco IOS is used to configure RPR-IEEE on the ML-Series card and its interfaces.

Successfully creating an RPR-IEEE requires these procedures:

• Provisioning Card Mode, page 2-4 (CTC)

• Connecting the ML-Series Cards with Point-to-Point STS/STM Circuits (CTC or TL1)

• Creating the RPR-IEEE Interface and Bridge Group (Cisco IOS)

• Verifying RPR-IEEE End-to-End Ethernet Connectivity (Cisco IOS)

Caution High-level data link control (HDLC) framing is not supported.

Note You can use TL-1 to provision the required SONET/SDH point-to-point circuits instead of CTC.

Provisioning Card Mode

The first task in creating an end-to-end RPR-IEEE is to set the CTC card mode to 802.17. For more information on this task, see the "Provisioning Card Mode" section on page 2-4.

Connecting the ML-Series Cards with Point-to-Point STS/STM Circuits

You connect the ML-Series cards in an RPR-IEEE through point-to-point STS/STM circuits. These circuits use the ONS 15454 SONET/SDH network and are provisioned using CTC in the same general manner as provisioning ONS 15454 SONET/SDH optical circuits. After putting the ML-Series card in RPR-IEEE mode and creating the circuits through CTC, further provisioning of the ML-Series card is done through the Cisco IOS CLI. It is assumed that the SONET/SDH node and its network are already active.

Guidelines for Connecting the ML-Series Cards with Point-to-Point STS/STM Circuits

These are some general guidelines for configuring the circuits required by RPR-IEEE:

•Verify the CTC card mode for the ML-Series card is set to 802.17. For more information about card mode, see the "Provisioning Card Mode" section on page 2-4.

•You must configure SONET/SDH circuits in an east-to-west configuration, from Port 0 (east) to Port 1 (west) around the SONET/SDH ring. The ports are labeled East and West in the CTC card-level view of the ML-Series card being provisioned and in the CTC Circuit Creation Wizard. The east-to-west provisioning is enforced by the network control program (NCP). The east-to-west setup is also required in order for the CTM network management software to recognize the ML-Series configuration as an RPR-IEEE.

Detailed CTC circuit procedures are available in the NTP-A343, "Create an Automatically Routed OC-N Circuit," and the NTP-A344, "Create a Manually Routed OC-N Circuit," procedures in the "Create Circuits and VT Tunnels" chapter of the Cisco ONS 15454 Procedure Guide and in the NTP-D323, "Create an Automatically Routed High-Order Circuit," and NTP-D 324, "Create a Manually Routed High-Order Circuit," procedures in the "Create Circuits and Tunnels" chapter of the Cisco ONS 15454 SDH Procedure Guide.

Example of Connecting the ML-Series Cards with Point-to-Point STS/STM Circuits

The three-node RPR-IEEE in Figure 26-6 shows an example of the point-to-point circuits needed.

Figure 26-6 Three Node RPR-IEEE Example

To configure the circuits for the example, you would need to perform these tasks in CTC:

1. Create a circuit from Node 1, East Span to Node 2, West Span.

2. Create a circuit from Node 2, East Span to Node 3, West Span.

3. Create a circuit from Node 3, East Span to Node 1, West Span.

Creating the RPR-IEEE Interface and Bridge Group

The plug-n-play feature of RPR-IEEE automatically discovers topology and advertises station capabilities. This allows ML-Series cards to become operational without manual intervention when the ML-Series card is in 802.17 mode and the SONET/SDH circuits are configured. Unlike Cisco proprietary RPR, RPR-IEEE does not require the user to configure POS interfaces.

The additional Cisco IOS CLI provisioning needed to set up basic, functional RPR is straightforward. The user needs to complete these tasks:

1. Configure the ML-Series card for integrated routing and bridging (IRB).

2. Create the bridge group.

3. Set the encapsulation on the Ethernet interface.

4. Assign Ethernet interfaces to the bridge group.

5. Enable the Ethernet ports.

6. Enable the rpr-ieee interface.

7. Set the encapsulation on the Ethernet interface.

8. Create rpr-ieee subinterfaces and assign them to the bridge group.

Caution A duplicate MAC address on the RPR-IEEE can cause network problems.

Understanding the RPR-IEEE Interface

When the card mode is changed to IEEE 802.17, the physical rpr-ieee interface is automatically created. It provides all the normal attributes of a Cisco IOS virtual interface, such as support for default routes.

An rpr-ieee interface is considered a trunk port, and like all trunk ports, subinterfaces must be configured for the rpr-ieee interface to join a bridge group.

The POS interfaces are not visible or configurable in 802.17 card mode.

Understanding the RPR-IEEE Bridge Group

The default behavior of the ML-Series card is that no traffic is bridged over the RPR-IEEE even with the interfaces enabled. This is in contrast to many Layer 2 switches, including the Cisco Catalyst 6500 series and the Cisco Catalyst 7600 series, which forward VLAN 1 by default. The ML-Series card will not forward any traffic by default, including untagged or VLAN 1 tagged packets.

For any RPR-IEEE traffic to be bridged on an ML-Series card, a bridge group needs to be created for that traffic. Bridge groups maintain the bridging and forwarding between the interfaces on the ML-Series card and are locally significant. Interfaces not participating in a bridge group cannot forward bridged traffic. The bridge group enables data transport across the RPR-IEEE infrastructure.

Figure 26-7 illustrates a bridge group spanning the ML-Series card interfaces, including the rpr-ieee virtual interface.

Figure 26-7 RPR-IEEE Bridge Group

Caution All Layer 2 network redundant links (loops) in the connecting network, except the RPR-IEEE topology, must be removed for correct RPR-IEEE operation. Or if loops exist, you must configure STP/RSTP.
Caution RPR-IEEE requires GFP-F framing. High-level data link control (HDLC) framing is not supported.

To enable the rpr-ieee interface and create the bridge group, perform the following procedure, beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# bridge irb

Enables the Cisco IOS software to both route and bridge a given protocol on separate interfaces within a single ML-Series card.

Step 2 

Router(config)# interface {fastethernet | gigabitethernet} interface-number

Enters interface configuration mode to configure the Ethernet interface that you want to include in the bridge group.

Step 3 

Router(config-if)# bridge-group bridge-group-number

Assigns the network interface to a bridge group.

Note You can safely ignore the baby giant frames warning that may appear.

Step 4 

Router(config-if)# no shutdown

Changes the shutdown state to up and enables the interface.

Step 5 

Router(config)# interface rpr-ieee 0

Creates the rpr-ieee interface on the ML-Series card or enters the rpr-ieee interface configuration mode. The only valid rpr-ieee number is 0.

Step 6 

Router(config-if)# rpr-ieee protection pref jumbo

Enables jumbo frame capability on the RPR-IEEE interface:

jumbo—Enables handling of frames in excess of the standard size, up to a maximum size of 9100 bytes. A jumbo-enabled station changes the interface MTU to 9100 bytes if all stations in the ring are jumbo enabled. A message is generated to indicate that the ring supports jumbo frames when all stations are configured for this preference.

The default is no jumbo frame support.

Step 7 

Router(config-if)# no shutdown

Changes the shutdown state to up and enables the interface.

Step 8 

Router(config-if)# interface rpr-ieee 0.subinterface-number

Enters subinterface configuration mode to configure the rpr-ieee subinterface.

Step 9 

Router(config-subif)# encap dot1q bridge-group-number

Sets the encapsulation on the bridge-group to IEEE 802.1Q.

Step 10 

Router(config-subif)# bridge-group bridge-group-number

Associates the rpr-ieee subinterface to the created bridge group.

Step 11 

Router(config)# no shut

Enables the RPR-IEEE interface and changes the mode from the default passthrough.

Step 12 

Router(config-if)# end

Exits to privileged EXEC mode.

Step 13 

Router# copy running-config startup-config

(Optional) Saves the configuration changes to NVRAM.

Configuration Examples for Cisco IOS CLI Portion of End-to-End RPR-IEEE

The following examples show RPR-IEEE configurations. Example 26-7 is a simple configuration. It does the minimum needed to bridge the ML-Series card's Ethernet ports and the ML-Series card's RPR-IEEE and leaves the RPR-IEEE characteristics at default. Example 26-8 is a complex example of RPR-IEEE with multiple bridge groups, configured characteristics, and QoS.

Example 26-7 Configuration Example for Simple RPR-IEEE

version 12.2
no service pad
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
no service password-encryption
service internal
!
hostname ml
!
boot-start-marker
boot-end-marker
!
enable password x
!
clock timezone PST -8
clock summer-time PDT date Apr 2 2006 2:00 Oct 29 2006 2:00
ip subnet-zero
no ip routing
no ip domain-lookup
!
no mpls traffic-eng auto-bw timers frequency 0
!
bridge irb
!
!
interface GigabitEthernet0
no ip address
no ip route-cache
no ip mroute-cache
bridge-group 10
bridge-group 10 spanning-disabled
!
interface GigabitEthernet1
no ip address
no ip route-cache
no ip mroute-cache
shutdown
!
interface RPR-IEEE0
no ip address
no ip route-cache
rpr-ieee fairness mode aggressive
!
interface RPR-IEEE0.10
encapsulation dot1Q 10
no ip route-cache
no snmp trap link-status
bridge-group 10
bridge-group 10 spanning-disabled
!
ip classless
no ip http server

Example 26-8 Configuration Example for a Complex RPR-IEEE

version 12.2
no service pad
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
no service password-encryption
service internal
!
hostname ml
!
boot-start-marker
boot-end-marker
!
enable password x
!
clock timezone PST -8
clock summer-time PDT date Apr 2 2006 2:00 Oct 29 2006 2:00
ip subnet-zero
no ip domain-lookup
!
vlan dot1q tag
no mpls traffic-eng auto-bw timers frequency 0
!
bridge irb
!
!
interface GigabitEthernet0
no ip address
bridge-group 12
bridge-group 12 spanning-disabled
!
interface GigabitEthernet1
no ip address
mode dot1q-tunnel
bridge-group 22
bridge-group 22 spanning-disabled
!
interface RPR-IEEE0
ip address 11.1.1.1 255.255.255.0
trigger crc-error threshold 4 east
trigger crc-error threshold 4 west
trigger crc-error action east
trigger crc-error action west
trigger crc-error delay 3 east
trigger crc-error delay 3 w
rpr-ieee atd-timer 10
rpr-ieee protection wtr-timer 60
!
interface RPR-IEEE0.1
encapsulation dot1Q 1 native
ip address 10.1.1.4 255.255.255.0
no snmp trap link-status
!
interface RPR-IEEE0.10
encapsulation dot1Q 10
no snmp trap link-status
bridge-group 10
bridge-group 10 spanning-disabled
!
interface RPR-IEEE0.12
encapsulation dot1Q 12
ip address 1.1.1.12 255.255.255.0
no snmp trap link-status
bridge-group 12
bridge-group 12 spanning-disabled
!
interface RPR-IEEE0.22
encapsulation dot1Q 22
no snmp trap
bridge-group 22
bridge-group 22 spanning-disabled
!
interface RPR-IEEE0.800
encapsulation dot1Q 800
ip address 8.1.1.1 255.255.255.224
no snmp trap link-status
!
ip classless
no ip http server
!
!
snmp-server community public RW
snmp-server ifindex persist
snmp-server trap link ietf
snmp-server host 64.101.18.178 version 2c public
snmp-server host 64.101.18.193 version 2c public
!
!
control-plane
!
line con 0
exec-timeout 0 0
line vty 0 4
exec-timeout 0 0
no login
end

Verifying RPR-IEEE End-to-End Ethernet Connectivity

After successfully completing the procedures to provision an RPR-IEEE, you can test Ethernet connectivity between the Ethernet access ports on the separate ML-Series cards. To do this, use your standard Ethernet connectivity testing.

Understanding Redundant Interconnect

Ring interconnect (RI) is a mechanism to interconnect RPRs, both RPR-IEEE and Cisco proprietary RPR, for protection from failure. It does this through redundant pairs of back-to-back Gigabit Ethernet connections that bridge RPR networks. One connection is the active node and the other is the standby node. During a failure of the active node, link, or card, the detection of the failure triggers a switchover to the standby node. Figure 26-8 illustrates an example of RPR RI.

Figure 26-8 RPR RI

Characteristics of RI on the ML-Series Card

RI on the ML-Series card has these characteristics:

•Supported only on Gigabit Ethernet

•Provisioned by identifying peer RPR MACs as either primary or standby

•Uses an OAM frame to flush the spatially aware sublayer (SAS) table and MAC table at the add stations

•Provides protection between individual RPRs, including:

–Two RPRs

–Two Cisco proprietary RPRs

–A Cisco proprietary ring and an IEEE 802.17 ring

•Provides card-level redundancy when connected to a switch running EtherChannel

Caution When connecting to a switch running EtherChannel, you must configure rpr-ieee ri foreign on the primary and secondary ML-Series cards.
Caution RPR-IEEE RI requires communication over the topology between the ML-Series cards. Traffic loss can occur if there is not enough communication and more than one span is down on a ring, for any reason.
Caution If the primary ML-Series card goes to standby because the interconnect interface goes down, then the ring interface is placed admininistratively down (admin down). This action signals the secondary ML-Series card to go to active. At this time, if the user configures a no shutdown on the primary ML-Series card ring interface, the ring interface comes up. This will signal the secondary ML-Series card to go to standby, which causes traffic loss. This occurs with all ML-Series card microcodes and with both RPR-IEEE and Cisco proprietary RPR.
Caution With Cisco proprietary RPR, a shutdown of the SPR interface puts ML1000-2 cards in passthrough mode. This allows the card to participate in RI. ML1000-2 cards are the only ML-Series cards eligible for RI. Other ML-Series cards fail to enter passthrough mode, when the SPR interface is shutdown.

RI Configuration Example

Excerpts of sample Cisco IOS code for an RPR RI for ML-Series-card-only connections are provided in Example 26-9 and Example 26-10. Excerpts of sample Cisco IOS code for an RPR RI where the primary and secondary ML-Series cards are connected to any switch that is not an ML-Series card (foreign switch), are provided in Example 26-9 and Example 26-10. Status of RI can be found using Example 26-13

Example 26-9 Primary ML-Series Card Configuration

interface rpr-ieee0
no ip address
rpr-ieee ri mode
no shutdown

In the above example, after rpr-ieee ri mode you need to insert the MAC address of the primary peer. To fetch this address, log in to the primary peer ML-Series card and enter the command show interface rpr-ieee as follows:

Router#show interface rpr-ieee 0
RPR-IEEE0 is up, line protocol is up
Hardware is RPR-IEEE Channelized SONET, address is 0019.076c.7f71 (bia 0019.076c.7f71)

The MAC address of the primary peer is 0019.076c.7f71. The configuration would now appear as rpr-ieee ri mode 0019.076c.7f71.

Example 26-10 Secondary ML-Series Card Configuration

interface rpr-ieee0
no ip address
rpr-ieee ri mode
no shutdown

In the above example, after rpr-ieee ri mode you need to insert the MAC address of the secondary peer. To fetch this address, log in to the secondary peer ML-Series card and enter the command show interface rpr-ieee as follows:


Router#show interface rpr-ieee 0
RPR-IEEE0 is up, line protocol is up
Hardware is RPR-IEEE Channelized SONET, address is 0019.076c.7f72 (bia 0019.076c.7f72)

The MAC address of the secondary peer is 0019.076c.7f72. The configuration would now appear as rpr-ieee ri mode 0019.076c.7f72.

Example 26-11 Primary ML-Series Card Configuration with Connection to Switch

interface rpr-ieee0
no ip address
rpr-ieee ri mode
rpr-ieee ri foreign
no shutdown

In the above example, after rpr-ieee ri mode you need to insert the MAC address of the primary peer. To fetch this address, log in to the primary peer ML-Series card and enter the command show interface rpr-ieee as follows:

Router#show interface rpr-ieee 0
RPR-IEEE0 is up, line protocol is up
Hardware is RPR-IEEE Channelized SONET, address is 0019.076c.7f73 (bia 0019.076c.7f73)

The MAC address of the primary peer is 0019.076c.7f73. The configuration would now appear as rpr-ieee ri mode 0019.076c.7f73.

Example 26-12 Secondary ML-Series Card Configuration with Connection to Switch

interface rpr-ieee0
no ip address
rpr-ieee ri mode
rpr-ieee ri foreign
no shutdown

In the above example, after rpr-ieee ri mode you need to insert the MAC address of the secondary peer. To fetch this address, log in to the secondary peer ML-Series card and enter the command show interface rpr-ieee as follows:

Router#show interface rpr-ieee 0
RPR-IEEE0 is up, line protocol is up
Hardware is RPR-IEEE Channelized SONET, address is 0019.076c.7f74 (bia 0019.076c.7f74)

The MAC address of the secondary peer is 0019.076c.7f74. The configuration would now appear as rpr-ieee ri mode 0019.076c.7f74.

Note In Figure 26-8 Cards A and C are primary cards, and B and D are secondary cards. Cards B and D are peers. Therefore, to configure Card A's MAC address, you need to configure Card B's RPR MAC address. Similarly, to configure Card C's MAC address, you need to configure Card D's RPR MAC address.

Example 26-13 Status of Redundant Interconnect can be found using

Router#sh ons dot17 ri
Redundant Interconnect Data
Mode: primary
State: standby
Peer: 0000.1111.2222
Peer Active: false
Spans Provisioned : true
Topology: stable
Ring if: up
Interconnect if: down
Secondary IC mode: link-up, WTR-timer:60 Adjusted:65
Ucode mode: Standby
Interconnect interface 0:
name: GigabitEthernet0
state: not up
member port channel: false
Interconnect interface 1:
name: GigabitEthernet1
state: not up
member port channel: false
Monitored if: interconnect

hometocprevnextglossaryfeedbacksearchhelp

Posted: Mon Oct 22 08:42:16 PDT 2007
All contents are Copyright © 1992--2007 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.