Configuring 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 how to configure resilient packet ring (RPR) and Dual RPR Interconnect (DRPRI) for the ML-Series card.

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 Link Fault Propagation

Understanding Dual RPR Interconnect

Configuring DRPRI

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/SDH in packet-based networks. RPR operates at the Layer 2 level and is compatible with Ethernet and SONET/SDH.

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/SDH 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/SDH 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 supports operation over protected and unprotected SONET/SDH circuits. On unprotected SONET/SDH circuits, RPR provides SONET/SDH-like protection without the redundant SONET/SDH protection path. Eliminating the need for a redundant SONET/SDH 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 17-1 illustrates these operations. Bridging connects and passes packets between the Ethernet ports on the ML-Series and the packet-over-SONET/SDH (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 17-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/SDH 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/SDH 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 initiates ring wraps immediately (default) or delays the wrap with a configured carrier delay time. When configured to wrap traffic after the carrier delay, a POS trigger delay time should be added to the carrier delay time to estimate approximate convergence times. The default and minimum POS trigger delay time for the ML-Series card is 200 ms. A carrier delay time of 200 ms (default) and a POS trigger delay time of 200 ms (default and minimum) combine for a total convergence time of approximately 400 ms. If the carrier delay is set to 0, then the convergence time would be approximately 200 ms. Figure 17-2 illustrates ring wrapping.

Figure 17-2 RPR Ring Wrapping


Note ML-Series card RPR convergence times might exceed 50 ms in the case of multiple failures in the same ring, if traffic passes through an ML-Series card configured with DRPRI (in active mode) during the reloading of the ML-Series card, or in the case of mismatched microcode images on ML-Series cards.



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 Gigabit Ethernet or 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 an STP and RSTP, a new VLAN must configured on all POS interfaces on 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 a 255 architectural maximum limit of 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, a greater number of connected devices are allowed on an RPR network basis.

Configuring Point-to-Point Circuits on CTC for RPR

RPR on the Cisco ONS 15454 or Cisco ONS 15454 SDH enables two or more ML-Series cards to become one functional network segment or SPR. The bridged ML-Series cards are connected to each other through point-to-point STS/STM 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 ONS 15454 SONET/SDH network. Provision the point-to-point circuits using Cisco Transport Controller (CTC) or Transaction Language One (TL1) in the same manner as an ONS 15454 OC-N card STS/STM circuits. The Cisco ONS 15454 Procedure Guide or the Cisco ONS 15454 SDH 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 on the Circuit Routing Preferences dialog box. Fully Protected Path provides SONET/SDH protection and should be unchecked. RPR normally provides the 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/STM 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/STM 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, SCNP, or path protection 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/SDH 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/SDH 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 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/STM 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 RPR.


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/SDH protection time to register the defect and declare the link down. Use immediate if RPR is running over unprotected SONET/SDH circuits. Use delayed for BLSR, path protection, 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 or Gigabit 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/SDH 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 Gigabit Ethernet or 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.


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 the POS ports that are part of the SPR interface.

Each of the ML-Series card's two POS ports must be assigned to 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 number

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-if)# interface pos 
number

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 milliseconds, which is optimum for SONET/SDH protected circuits.

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 17-3 shows an example of an RPR Cisco IOS configuration. The associated code is provided in Examples 17-1, 17-2, and 17-3. The configuration assumes that ML-Series card POS ports are already linked by point-to-point SONET/SDH circuits configured through CTC.

Figure 17-3 RPR Configuration Example

Example 17-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 Gigabit Ethernet0
 no ip address
 no ip route-cache
bridge-group 1

interface Gigabit Ethernet1
 no ip address
 no ip route-cache
bridge-group 1

Example 17-2 SPR Station-ID 2 Configuration

bridge irb
!
interface SPR1 
no ip address
no keepalive
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 Gigabit Ethernet0
 no ip address
 no ip route-cache
bridge-group 1

interface Gigabit Ethernet1
 no ip address
 no ip route-cache
bridge-group 1

Example 17-3 SPR Station-ID 3 Configuration

bridge irb
!
interface SPR1 
no ip address
no keepalive
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 Gigabit Ethernet0
 no ip address
 no ip route-cache
bridge-group 1

interface Gigabit 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 spr or show run interface spr command (Example 17-4).

Example 17-4 Monitor and Verify RPR

Router# show interfaces spr 1
SPR1 is up, line protocol is up 
Hardware is POS-SPR, address is 0005.9a39.714a (bia 0000.0000.0000)
MTU 1500 bytes, BW 1244160 Kbit, DLY 100 usec, 
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ONS15454-G1000, loopback not set
Keepalive not set
DTR is pulsed for 33391 seconds on reset
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/150/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/80 (size/max)
5 minute input rate 1000 bits/sec, 2 packets/sec
5 minute output rate 2000 bits/sec, 4 packets/sec
1014 packets input, 96950 bytes
Received 0 broadcasts (0 IP multicast)
0 runts, 0 giants, 0 throttles
0 parity
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
1640 packets output, 158832 bytes, 0 underruns
0 output errors, 0 applique, 9 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

Understanding RPR Link Fault Propagation

Link fault propagation (LFP), also known as link pass through, decreases convergence times in networks where routers interconnect through ML-Series card RPR. It quickly relays link faults from a master Gigabit Ethernet link to a remote slave link, either Gigabit Ethernet or FastEthernet. LFP greatly improves the time it takes for a router connected to the slave link to fail over to an alternate path. Under normal protection schemes, convergence might take as long as forty seconds. Using LFP, the slave interface reflects the state of the master interface in well under a second. This feature is often used to enable a link failure at a far-end hub site to trigger a link down state at a near-end access site. Figure 17-4 illustrates LFP.

Figure 17-4 RPR Link Fault Propagation Example

LFP updates are done through a CDP packet extension. The update is sent periodically and immediately after the master interface goes into link-down. LFP updates are sent separately from normal CDP packets, and the two types do not interact. Configuring or disabling CDP on the interface has no effect on LFP updates.

When the master interface goes down, including an administrative shutdown, the slave interface is forced down. When the master interface goes up, the slave interface will go back up. Administrative shutdown on a slave interface will suspend the LFP function on that interface, and removing the shutdown will reactivate LFP.

A link-down fault is also forced onto the slave link if the connection from the master to the slave fails. Any of the following can cause a loss of conecction:

Removing or resetting the master ML-Series card.

Shutdown or failure on both of the RPR paths between master and slave.

Disabling LFP on the master interface.

Link faults only propagate from master to slave. Normal slave link faults are not propagated. RPR wrapping and unwrapping has no effect on LFP.

Propagation Delays

Propagation delay includes the carrier-delay time on the slave interface. The carrier-delay time is configureable and has a default of 200 ms. See the "Configuring RPR on Cisco IOS" section for more information on configuring carrier-delay time.

Different propagation delays apply to different LFP scenarios:

Propagation delay between master link-down and slave link-down is 50 ms plus the carrier-delay time on the slave interface.

Propagation delay between master link-up and slave-link up has an additional built-in delay at the master interface to prevent interface flapping. Link-up propagation takes approximately 50-200 ms plus the carrier-delay time on the slave interface.

Propagation delay from when the master to slave link fails until slave link-down is approximately 600 ms plus the carrier-delay time on the slave interface.

Configuring LFP

Figure 17-4 illustrates an example of RPR configured with LFP. The process of configuring LFP consists of the following tasks:

1. Configure one ML-Series card Gigabit Ethernet interface as a master link.

2. Configure other ML-Series cards' Gigabit Ethernet or FastEthernet interfaces as slave links.

To enable and configure the LFP master link, perform the following procedure, beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router# interface gigabit ethernet number

Activates interface configuration mode to configure the Gigabit Ethernet interface.

Step 2 

Router(config-if)# link-fault rpr-master

Enables link-fault master status on the interface.

The no form of this command disables link-fault master status.

Step 3 

Router(config-if)# no shutdown

Enables the interface by preventing it from shutting down.

Step 4 

Router(config)# end

Returns to privileged EXEC mode.

Step 5 

Router# copy running-config startup-config

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

To enable and configure the LFP slave link, perform the following procedure on an ML-Series card in the RPR other than the ML-Series card configured for the master link. Begin in global configuration mode:

 
Command
Purpose

Step 1 

Router# interface [gigabit ethernet | 
fastethernet] number

Activates interface configuration mode to configure the Gigabit Ethernet or FastEthernet interface.

Step 2 

Router(config-if)# link-fault rpr-slave

Enables link-fault slave status on the interface.

The no form of this command disables link-fault slave status.

Step 3 

Router(config-if)# no shutdown

Enables the interface by preventing it from shutting down.

Step 4 

Router(config)# end

Returns to privileged EXEC mode.

Step 5 

Router# copy running-config startup-config

(Optional) Saves configuration changes to TCC2 flash database.

LFP Configuration Requirements

LFP has these configuration requirement:

A link-fault master and slave should not be configured on the same card.

The ML-Series card must be running the Enhanced microcode image.

All ML-Series cards in the RPR must be running software release 5.0 and later.

ML-Series card configured for DRPRI should not be configured for LFP, and LFP on DRPRI is unsupported.

Only ML-Series card Gigabit Ethernet interfaces are eligible to become link-fault masters.

Only one link-fault master is allowed per RPR.

Gigabit Ethernet and FastEthernet interfaces are both eligible to become link-fault slaves.

There is no configuration limit on link-fault slaves on an RPR.

Monitoring and Verifying LFP

A slave interface in link-down state raises a CARLOSS alarm on CTC. CTC does not distinguish between a local loss on the slave link and loss due to LFP. For more information on CARLOSS, refer to refer to the "Alarm Troubleshooting" chapter of the Cisco ONS 15454 Troubleshooting Guide or the "Alarm Troubleshooting" chapter of the Cisco ONS 15454 SDH Troubleshooting Guide.

The Cisco IOS status of link-down interface is shown as protocol down/link down. Neither the show controller or show interface command reveals the difference between a local loss on the link and an LFP loss.

After LFP is configured, you can monitor the LFP status of each master or slave link using the show link-fault command. Use this command to determine whether LFP caused the link down on a slave interface. Example 17-5 illustrates the output from this command on a slave interface.

Example 17-5 Monitor and Verify LFP

Router# show link-fault
Link Fault Propagation Configuration:
-------------------------------------
    LFP Config Mode  : LFP_SLAVE
    LFP Master State : LFP_STATUS_DOWN
    Interfaces configured for LFP:
        FastEthernet0 (down)

Understanding Dual RPR Interconnect

Cisco ML-Series RPR includes a mechanism to interconnect rings for protection from node failure. The bridge-group protocol, DRPRI, provides two parallel connections of the rings linked by a special instance of RSTP. One connection is the active node and the other is the standby node. During a failure of the active node, link, or card, a proprietary algorithm detects the failure and causes a switchover to the standby node. DRPRI provides a recovery time of less than 200 ms for Layer 2 bridged traffic, when the ML-Series employs the enhanced microcode image. When the ML-Series employs the base or Multiprotocol Label Switching (MPLS) microcode images, the recovery time for Layer 2 bridged traffic is up to 12 seconds. With any microcode image the recovery time for Layer 3 unicast and multicast traffic also depends on the convergence time of the routing protocol implemented.

The paired ML1000-2 cards share the same station ID and are viewed by other members of the RPR as a single card. In Figure 17-5, paired cards A and B have the same SPR station ID, and paired cards C and D have the same station ID. The interconnected nodes do not need to be adjacent on the RPR. Bridging, IP routing, policing and bandwidth allocations can still be provisioned on DRPRI ML1000-2 cards.

Figure 17-5 Dual RPR Interconnect Network and Paired Cards

DRPRI has these characteristics:

Four ML1000-2 cards are required.

All four ML1000-2 cards must be part of the same bridge-group (VLAN).

Each paired set of ML1000-2 cards must have the same SPR station ID.

The bridge-group must be configured on SPR subinterfaces.

The DRPRI bridge-group is limited to one protocol, so a bridge-group with DRPRI implemented cannot also implement RSTP or STP.

On each of the four ML1000-2 cards, both Gigabit Ethernet ports must be joined in Gigabit EtherChannel (GEC) and the GEC interface included in the DRPRI bridge-group, or one Gigabit Ethernet port must be shut down and the other one included in the DRPRI bridge-group. We recommend the GEC method.

A manual shutdown on subinterfaces or the GEC interface included in the DRPRI bridge-group must be issued on the interfaces at both ends of the GEC or Ethernet connection between the rings.

The DRPRI bridge-group cannot also be used to carry data traffic.

A DRPRI node can only be used for interconnecting two RPRs. The front ports of the cards should not be used to carry other traffic.

Non-DRPRI bridge-groups carrying traffic between rings should not have STP or RSTP configured.

Non-DRPRI bridge-groups carrying traffic between rings must be configured on each of the four ML-Series cards.

QinQ and protocol tunnels cannot be started on DRPRI nodes, but DRPRI nodes can bridge QinQ and protocol tunnels across the connected rings.

Users should not change the pathcost of members of the DRPRI bridge-group. The pathcost is assigned by the ML-Series card to ensure proper operation of DRPRI. A user configured pathcost are overwritten by the assigned default DRPRI pathcost.

Configuring DRPRI

DRPRI requires two pairs of ML-Series cards with one pair configured as RPR and belonging to the first of two adjacent RPRs, and the second pair configured as RPR and belonging to the second RPR (Figure 17-5). DRPRI is configured on each of the four ML1000-2 cards that connect the two adjacent RPRs. The process of configuring DRPRI consists of the following tasks:

1. Configure a bridge-group with the DRPRI protocol.

2. Configure the SPR interface.

a. Assign a station ID number.

b. Assign a DRPRI ID of 0 or 1.

3. Create an SPR subinterface and assign the bridge-group to the subinterface.

4. Create a GEC interface.

5. Create a GEC subinterface and assign the bridge-group to the subinterface.

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

 
Command
Purpose

Step 1 

Router(config)# bridge crb

Concurrent routing and bridging is enabled. When concurrent routing and bridging has been enabled, the default behavior is to bridge all protocols that are not explicitly routed in a bridge group.

Step 2 

Router(config)# bridge bridge-group-number 
protocol drpri-rstp

Creates the bridge-group number shared by the four ML1000-2 cards and assigns the protocol for DRPRI to the bridge-group. The same command using the same bridge group number must be given on each of the four cards.

Step 3 

Router(config)# interface spr 1

Creates the SPR interface for RPR or enters the SPR interface configuration mode on a previously created SPR interface. The only valid SPR number is 1.

Step 4 

Router(config-if)# spr station-ID 
station-ID-number

Configures a station identification number. The user must configure the same station ID on both the paired cards. Valid station ID numbers range from 1 to 254.

Step 5 

Router(config-if)# spr drpri-ID {0 | 1}

Creates a DRPRI identification number of 0 or 1 to differentiate between the ML1000-2 cards paired for DRPRI.

Step 6 

Router(config-if)# interface spr 
shared-packet-ring-subinterface-number

Creates the SPR subinterface.

Step 7 

Router(config-subif)# encapsulation dot1q 
vlan-ID

Sets the SPR subinterface encapsulation to IEEE 802.1Q.

Step 8 

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

Assigns the SPR subinterface to a bridge-group.

Step 9 

Router(config)# interface port-channel 
channel-number

Creates the GEC interface or channel-group.

Step 10 

Router(config-if)# interface Gigabit 
Ethernet number

Enters interface configuration mode for the first Gigabit Ethernet interface that you want to assign to the GEC subinterface.

Step 11 

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

Assigns the Gigabit Ethernet interfaces to the GEC. The channel number must be the same channel number that you assigned to the EtherChannel interface.

Step 12 

Router(config-if)# interface Gigabit 
Ethernet number

Enters interface configuration mode for the second Gigabit Ethernet interface that you want to assign to the GEC subinterface.

Step 13 

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

Assigns the Gigabit Ethernet interfaces to the GEC. The channel number must be the same channel number that you assigned to the EtherChannel interface.

Step 14 

Router(config-subif)# interface 
port-channel channel-sub-interface-number

Creates the GEC subinterface.

Step 15 

Router(config-subif)# encapsulation dot1q 
vlan-ID

Sets subinterface encapsulation to IEEE 802.1Q. The VLAN ID used should be the same VLAN ID used in Step 7.

Step 16 

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

Assigns the GEC subinterface to the bridge-group.

Step 17 

Router(config-if)# end

Exits to privileged EXEC mode.

Step 18 

Router# copy running-config startup-config

(Optional) Saves configuration changes to NVRAM.

DRPRI IOS Configuration Example

Figure 17-5 shows an example of RPR configuration. The associated code is provided in Examples 17-6, 17-7, 17-8, and 17-9.

Example 17-6 ML-Series Card A Configuration

hostname ML-Series A
bridge crb
bridge 100 protocol drpri-rstp

interface Port-channel1
no ip address
no ip route-cache
 hold-queue 300 in

interface Port-channel1.1
 encapsulation dot1Q 10
 no ip route-cache
 bridge-group 100

interface SPR1
 no ip address
 no keepalive
 spr station-ID 1
hold-queue 150 in

interface SPR1.1
 encapsulation dot1Q 10
 bridge-group 100

interface Gigabit Ethernet0
 no ip address
 no ip route-cache
channel-group 1

interface Gigabit Ethernet1
 no ip address
 no ip route-cache
channel-group 1

interface POS0
 no ip address
 spr-intf-id 1
 crc 32

interface POS1
 no ip address
 spr-intf-id 1
 crc 32

ip classless
no ip http server

Example 17-7 ML-Series Card B Configuration

hostname ML-Series B
bridge crb
bridge 100 protocol drpri-rstp

interface Port-channel1
no ip address
no ip route-cache
 hold-queue 300 in

interface Port-channel1.1
 encapsulation dot1Q 10
 no ip route-cache
 bridge-group 100

interface SPR1
 no ip address
 no keepalive
 spr station-ID 1
spr drpr-ID 1
 hold-queue 150 in

interface SPR1.1
 encapsulation dot1Q 10
 bridge-group 100

interface Gigabit Ethernet0
 no ip address
 no ip route-cache
channel-group 1

interface Gigabit Ethernet1
 no ip address
 no ip route-cache
channel-group 1

interface POS0
 no ip address
 spr-intf-id 1
 crc 32

interface POS1
 no ip address
 spr-intf-id 1
 crc 32

ip classless
no ip http server

Example 17-8 ML-Series Card C Configuration

hostname ML-Series C
bridge crb
bridge 100 protocol drpri-rstp

interface Port-channel1
no ip address
no ip route-cache
 hold-queue 300 in

interface Port-channel1.1
 encapsulation dot1Q 10
 no ip route-cache
 bridge-group 100

interface SPR1
 no ip address
 no keepalive
 spr station-ID 2
hold-queue 150 in

interface SPR1.1
 encapsulation dot1Q 10
 bridge-group 100

interface Gigabit Ethernet0
 no ip address
 no ip route-cache
channel-group 1

interface Gigabit Ethernet1
 no ip address
 no ip route-cache
channel-group 1

interface POS0
 no ip address
 spr-intf-id 1
 crc 32

interface POS1
 no ip address
 spr-intf-id 1
 crc 32

ip classless
no ip http server

Example 17-9 ML-Series Card D Configuration

hostname ML-Series D
bridge crb
bridge 100 protocol drpri-rstp

interface Port-channel1
no ip address
no ip route-cache
 hold-queue 300 in

interface Port-channel1.1
 encapsulation dot1Q 10
 no ip route-cache
 bridge-group 100

interface SPR1
 no ip address
 no keepalive
 spr station-ID 2
spr drpr-ID 1
 hold-queue 150 in

interface SPR1.1
 encapsulation dot1Q 10
 bridge-group 100

interface Gigabit Ethernet0
 no ip address
 no ip route-cache
channel-group 1

interface Gigabit Ethernet1
 no ip address
 no ip route-cache
channel-group 1

interface POS0
 no ip address
 spr-intf-id 1
 crc 32

interface POS1
 no ip address
 spr-intf-id 1
 crc 32

ip classless
no ip http server

Monitoring and Verifying DRPRI

After DRPRI is configured, you can monitor its status using the show bridge verbose command (Example 17-10).

Example 17-10 show bridge verbose Command

Router# show bridge bridge-group-number verbose