Cisco ONS 15310-CL Ethernet Card Software Feature and Configuration Guide, Release 6.0 - Chapter 15, Configuring Resilient Packet Ring on the ML-Series Card [Cisco ONS 15300 Series]

Table Of Contents

Configuring Resilient Packet Ring on the ML-Series Card

Understanding RPR

Packet Handling Operations

Ring Wrapping

MAC Address and VLAN Support

Configuring Point-to-Point Circuits on CTC for RPR

Configuring RPR on Cisco IOS

RPR Cisco IOS Configuration Example

Monitoring and Verifying RPR

Configuring Resilient Packet Ring on the ML-Series Card

Note 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 how to configure resilient packet ring (RPR) for ML-Series cards.

This chapter contains the following major sections:

•Understanding RPR

•Configuring Point-to-Point Circuits on CTC for RPR

•Configuring RPR on Cisco IOS

•Monitoring and Verifying RPR

Understanding RPR

RPR is an emerging network architecture designed for metro fiber ring networks. This new MAC protocol is designed to overcome the limitations of IEEE 802.1D Spanning Tree Protocol (STP), IEEE 802.1W Rapid Spanning Tree Protocol (RSTP), and SONET in packet-based networks. RPR operates at the Layer 2 level and is compatible with Ethernet and SONET.

The ML-Series card's RPR relies on the quality of service (QoS) features of the ML-Series card for efficient bandwidth utilization with service level agreement (SLA) support. ML-Series card QoS mechanisms apply to all SONET traffic on the ML-Series card, whether passed-through, bridged, or stripped.

When an ML-Series card is configured with RPR and made part of a shared packet ring (SPR), the ML-Series card assumes it is part of a ring. If a packet is not destined for devices attached to the specific ML-Series, the ML-Series card simply continues to forward this transit traffic along the SONET circuit, relying on the circular path of the ring architecture to guarantee that the packet will eventually arrive at the destination. This eliminates the need to queue and forward the packet flowing through the nondestination ML-Series card. From a Layer 2 or Layer 3 perspective, the entire RPR looks like one shared network segment.

RPR operates over either protected or unprotected SONET circuits. On unprotected SONET circuits, RPR provides SONET-like protection without the redundant SONET protection path. Eliminating the need for a redundant SONET path frees bandwidth for additional traffic. RPR also incorporates spatial reuse of bandwidth through a hash algorithm for east/west packet transmission. RPR utilizes the entire ring bandwidth and does not need to block ring segments like STP or RSTP.

Packet Handling Operations

The RPR protocol, using the transmitted packet's header information, allows the interfaces to quickly determine the operation that needs to be applied to the packet. An ML-Series card configured with RPR is part of the ring and has three basic packet-handling operations: bridge, pass-through, and strip. Figure 15-1 illustrates these operations. Bridging connects and passes packets between the Ethernet ports on the ML-Series and the packet-over-SONET (POS) circuit circling the ring. Pass-through lets the packets continue through the ML-Series card and along the ring, and stripping takes the packet off the ring and discards it. Because STP or RSTP is not in effect between nodes when RPR is configured, the transmitting RPR port strips its own packets after they return from circling the ring. A hash algorithm is used to determine the direction of the packet around the RPR.

Figure 15-1 RPR Packet Handling Operations

Ring Wrapping

RPR initiates ring wraps in the event of a fiber cut, node failure, node restoration, new node insertion, or other traffic problems. This protection mechanism redirects traffic to the original destination by sending it in the opposite direction around the ring after a link state change or after receiving SONET path level alarms. Ring wrapping on the ML-Series card allows convergence times of less than 50 ms. RPR convergence times are comparable to SONET and much faster than STP or RSTP.

RPR on the ML-Series card survives both unidirectional and bidirectional transmission failures within the ring. Unlike STP or RSTP, RPR restoration is scalable. Increasing the number of ML-Series cards in a ring does not increase the convergence time.

RPR wraps occur within 50 msec after the failure condition with the default spr wrap immediate configured. If spr wrap delay is configured, the wrap is delayed until the POS interface goes link-down. The link goes down after the time specified with the CLI pos trigger delay <msec>. If the circuits are VCAT then the Cico IOS CLI command pos vcat defect delayed also needs to be configured. The delay helps ensure that when RPR is configured with SONET bandwidth protection, this Layer 1 protection has a chance to take effect before the Layer 2 RPR protection. If the interface goes down without a SONET error, then the carrier delay also take effect. Figure 15-2 illustrates ring wrapping.

Figure 15-2 RPR Ring Wrapping

Note If the carrier delay time is changed from the default, the new carrier delay time must be configured on all the ML-Series card interfaces, including the SPR, POS, and Fast Ethernet interfaces.

Note ML-Series card POS interfaces normally send PDI-P to the far-end when the POS link goes down or RPR wraps. ML-Series card POS interfaces do not send PDI-P to the far-end when PDI-P is detected, when RDI-P is being sent to the far-end or when the only defects detected are GFP LFD, GFP CSF, VCAT LOM or VCAT SQM.

MAC Address and VLAN Support

RPR improves MAC address support, because an ML-Series card does not need to learn the MAC address of pass-through packets. The ML-Series card's MAC address table only holds the MAC IDs of packets that have been bridged or stripped by that card. This allows the collective tables of the ML-Series cards in the ring to hold a greater number of MAC addresses.

RPR also enhances VLAN support relative to STP and RSTP. In STP and RSTP, a new VLAN must configured on all POS interfaces in the ring. In RPR, the VLAN must only be added to the configuration of those interfaces that bridge or strip packets for that VLAN. The ML-Series card still has an architectural maximum limit of 255 VLAN/bridge-group per ML-Series card. But because the ML-Series card only needs to maintain the MAC address of directly connected devices per card, this allows for a greater number of connected devices per RPR network.

Configuring Point-to-Point Circuits on CTC for RPR

RPR on the Cisco ONS 15310-CL enables two or more ML-Series cards to become one functional network segment or shared packet ring (SPR). The bridged ML-Series cards are connected to each other through point-to-point STS circuits, which use one of the first ML-Series card's POS ports as a source and one of the second ML-Series card's POS ports as a destination. All ML-Series cards in an SPR must be connected directly or indirectly by point-to-point circuits.

The point-to-point circuits use the SONET network. Provision the point-to-point circuits using Cisco Transport Controller (CTC) or Transaction Language One (TL1) in the same manner as ONS 15310-CL STS circuits. The Cisco ONS 15310-CL Procedure Guide provides specific instructions about how to create an automatically routed optical circuit.

When configuring a point-to-point circuit on the ML-Series:

•Leave all CTC Circuit Creation Wizard options at default except Fully Protected Path in the Circuit Routing Preferences dialog box, which provides SONET protection and should be unchecked. RPR provides Layer 2 protection for SPR circuits.

•Check Using Required Nodes and Spans to route automatically in the Circuit Routing Preferences dialog box. If the source and destination nodes are adjacent on the ring, exclude all nodes except the source and destination in the Circuit Routing Preferences dialog box. This forces the circuit to be routed directly between source and destination and preserves STS circuits, which would be consumed if the circuit routed through other nodes in the ring. If there is a node or nodes that do not contain an ML-Series card between the two nodes containing ML-Series card, include this node or nodes in the included nodes area in the Circuit Routing Preference dialog box, along with the source and destination nodes.

•Keep in mind that ML-Series card STS circuits do not support unrelated circuit creation options, such as unidirectional traffic, creating cross-connects only (TL1-like), interdomain (unified control plane [UCP]), protected drops, subnetwork connection protection (SNCP), or path protection path selectors.

After the CTC circuit process is complete, begin a Cisco IOS session to configure RPR/SPR on the ML-Series card and interfaces.

Note A best practice is to configure SONET circuits in an east-to-west or west-to-east configuration, from Port 0 (east) to Port 1 (west) or Port 1 (east) to Port 0 (west), around the SONET ring. Do not configure Port 0 to Port 0 or Port 1 to Port 1. The east-to-west or west-to-east setup is required for the Cisco Transport Manager (CTM) network management software to recognize the ML-Series configuration as an SPR.

Configuring RPR on Cisco IOS

You configure RPR on the ML-Series cards by creating an SPR interface from the Cisco IOS command-line interface (CLI). The SPR is a virtual interface, similar to an EtherChannel interface. The POS interfaces are the physical interfaces associated with the RPR SPR interface. An ML-Series card supports a single SPR interface. The SPR interface has a single MAC address and provides all the normal attributes of a Cisco IOS interface, such as support for default routes. An SPR interface is considered a trunk port, and like all trunk ports, subinterfaces must be configured for the SPR interface to become part of a bridge group.

An SPR interface is configured similarly to a EtherChannel (port-channel) interface. The members of the SPR interface must be POS interfaces. Instead of using the channel-group command to define the members, you use the spr-intf-id command. And like port-channel, you configure the SPR interfaces instead of the POS interface.

Caution In configuring an SPR, if one ML-Series card is not configured with an SPR interface, but valid STS circuits connect this ML-Series card to the other ML-Series cards in the SPR, no traffic will flood between the properly configured ML-Series cards in the SPR, and no alarms will indicate this condition. Cisco recommends that you configure all of the ML-Series cards in an SPR before sending traffic.

Caution Do not use native VLANs for carrying traffic with RPRs.

Note RPR is only supported with LEX encapsulation. LEX is the default encapsulation for the ML-Series card.

To provision RPR, 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 spr 1
Creates the SPR interface on the ML-Series card or enters the SPR interface configuration mode. The only valid SPR number is 1.
Step 3
Router(config-if)# spr station-id 
station-ID-number
Configures a station ID. The user must configure a different number for each SPR interface that attaches to the RPR. Valid station ID numbers range from 1 to 254.
Step 4
Router(config-if)# spr wrap 
{immediate | delayed}
(Optional) Sets the RPR ring wrap mode to either wrap traffic the instant it detects a link state change or to wrap traffic after the carrier delay, which gives the SONET protection time to register the defect and declare the link down. Use immediate if RPR is running over unprotected SONET circuits. Use delayed for bidirectional line switched ring (BLSR), path protection, multiplex section-shared protection ring (MS-SPRing), or SNCP protected circuits.

The default setting is immediate.
Step 5
Router(config-if)# bridge-group 
bridge-group-number
(Optional) Assigns the SPR interface to a bridge-group. The bridge-group-number bridges the SPR and Fast Ethernet interface.
Step 6
Router(config-if)# carrier-delay msec 
milliseconds
(Optional) Sets the carrier delay time. The default setting is 200 milliseconds, which is optimum for SONET protected circuits.

Note If the carrier delay time is changed from the default, the new carrier delay time must be configured on all the ML-Series card interfaces, including the SPR, POS, and Fast Ethernet interfaces.
Step 7
Router(config-if)# [no] spr 
load-balance { auto | port-based } 
(Optional) Specifies the RPR load-balancing scheme for Unicast packets. The port-based load balancing option maps even ports to the POS 0 interface and odd ports to the POS 1 interface. The default auto option balances the load based on the MAC addresses or source and destination addresses of the IP packet.
Step 8
Router(config-if)# end
Exits to privileged EXEC mode.
Step 9
Router# copy running-config 
startup-config
(Optional) Saves configuration changes to NVRAM.
Each of the ML-Series card's two POS ports must be assigned to the SPR interface.

Caution The SPR interface is the routed interface. Do not enable Layer 3 addresses or assign bridge groups on the POS interfaces assigned to the SPR interface.

Caution When traffic coming in on an SPR interface needs to be policed, the same input service policy needs to be applied to both of the POS ports that are part of the SPR interface.

To assign the POS interfaces on the ML-Series to the SPR, perform the following procedure, beginning in global configuration mode:
Command

Purpose
Step 1
Router(config)# interface pos 1
Enters the interface configuration mode to configure the first POS interface that you want to assign to the SPR.
Step 2
Router(config-if)# spr-intf-id 
shared-packet-ring-number
Assigns the POS interface to the SPR interface. The shared packet ring number must be the same shared packet ring number that you assigned to the SPR interface.
Step 3
Router(config-if)# carrier-delay msec 
milliseconds 
(Optional) Sets the carrier delay time. The default setting is 200 msec, which is optimum for SONET/SDH protected circuits.

Note The default unit of time for setting the carrier delay is seconds. The msec command resets the time unit to milliseconds.
Step 4
Router(config-if)# pos trigger defect 
ber_sd-b3
(Optional) Configures a trigger to bring down the POS interface when the SONET/SDH bit error rate exceeds the threshold set for the signal degrade alarm. Bringing the POS interface down initiates the RPR wrap.

This command is recommended for all RPR POS interfaces since excessive SONET/SDH bit errors can cause packet loss on RPR traffic.
Step 5
Router(config)# interface pos 2
Enters the interface configuration mode to configure the second POS interface that you want to assign to the SPR.
Step 6
Router(config-if)# spr-intf-id 
shared-packet-ring-number
Assigns the POS interface to the SPR interface. The shared packet ring number must be the same shared packet ring number that you assigned to the SPR interface.
Step 7
Router(config-if)# carrier-delay msec 
milliseconds 
(Optional) Sets the carrier delay time. The default setting is 200 msec, which is optimum for SONET/SDH protected circuits.

Note The default unit of time for setting the carrier delay is seconds. The msec command resets the time unit to milliseconds.
Step 8
Router(config-if)# pos trigger defect 
ber_sd-b3
(Optional) Configures a trigger to bring down the POS interface when the SONET/SDH bit error rate exceeds the threshold set for the signal degrade alarm. Bringing the POS interface down initiates the RPR wrap.

This command is recommended for all RPR POS interfaces since excessive SONET/SDH bit errors can cause packet loss on RPR traffic.
Step 9
Router(config-if)# end
Exits to privileged EXEC mode.
Step 10
Router# copy running-config 
startup-config
(Optional) Saves the configuration changes to NVRAM.
RPR Cisco IOS Configuration Example

Figure 15-3 shows an example of an RPR Cisco IOS configuration. The associated code is provided in Examples 15-1, 15-2, and 15-3. The configuration assumes that ML-Series card POS ports are already linked by point-to-point SONET circuits configured through CTC.

Figure 15-3 RPR Configuration Example

Example 15-1 SPR Station-ID 1 Configuration
bridge irb
!
interface SPR1 
no ip address
no keepalive
spr station-ID 1
hold-queue 150 in
bridge-group 1
!
interface POS0 
no ip address
spr-intf-id 1
!
interface POS1
no ip address
spr-intf-id 1
interface Fast Ethernet0
 no ip address
 no ip route-cache
bridge-group 1
interface Fast Ethernet1
 no ip address
 no ip route-cache
bridge-group 1
Example 15-2 SPR Station-ID 2 Configuration
bridge irb
!
interface SPR1 
no ip address
spr station-ID 2
hold-queue 150 in
bridge-group 1
!
interface POS0 
no ip address
spr-intf-id 1
!
interface POS1
no ip address
spr-intf-id 1
interface Fast Ethernet0
 no ip address
 no ip route-cache
bridge-group 1
interface Fast Ethernet1
 no ip address
 no ip route-cache
bridge-group 1
Example 15-3 SPR Station-ID 3 Configuration
bridge irb
!
interface SPR1 
no ip address
spr station-ID 3
hold-queue 150 in
bridge-group 1
!
interface POS0 
no ip address
spr-intf-id 1
!
interface POS1
no ip address
spr-intf-id 1
interface Fast Ethernet0
 no ip address
 no ip route-cache
bridge-group 1
interface Fast Ethernet1
 no ip address
 no ip route-cache
bridge-group 1
Monitoring and Verifying RPR

After RPR is configured, you can monitor its status using the show interface spr1 or show run interface spr command (Example 15-4).

Example 15-4 Monitor and Verify RPR
ML_Series# show interfaces spr1
SPR1 is up, line protocol is up 
  Hardware is POS-SPR, address is 000c.9a9a.9a9a (bia 0000.0000.0000)
  MTU 1500 bytes, BW 96768 Kbit, DLY 100 usec, 
     reliability 152/255, txload 72/255, rxload 79/255
 Encapsulation: Cisco-EoS-LEX, loopback not set
  Keepalive not set
  Restart-Delay is 33289 secs
  ARP type: ARPA, ARP Timeout 04:00:00
    No. of active members in this SPR interface: 2 
        Member 0 : POS0 
		Member 1 : POS1
  Last input never, 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)
  5 minute input rate 30227000 bits/sec, 13005 packets/sec
  5 minute output rate 27437000 bits/sec, 3854 packets/sec
     149420778 packets input, 3246063555 bytes
     Received 0 broadcasts (0 IP multicast)
     0 runts, 0 giants, 0 throttles
              0 parity
     4307057 input errors, 177 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     144306681 packets output, 2688996761 bytes, 0 underruns
     0 output errors, 0 applique, 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
     0 carrier transitions