Spatial Reuse Protocol/Dynamic Packet Transport (SRP/DPT)

Document ID: 13548

Contents

Introduction
Prerequisites
      Requirements
      Components Used
      Conventions
The Platform Used
Use the Autoconnect Function
      Exceptions
Verify the Physical Connectivity
Define Nodes on the ONS 15190
Create a Logical Ring and Assign Nodes
Modify the Node Order of an Existing Ring
Recommendations and Comments
Cisco Support Community - Featured Conversations
Related Information

Introduction

This document provides instructions to manually configure a spatial reuse protocol (SRP) ring on the ONS 15190. This document also describes how to modify existing SRP configurations.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

The Platform Used

All information contained in this document refers to the ONS 15190. In order to determine which version you run, use the system show info command:

Jupiter#system show info
	System uptime: 9d, 23:26:13.517 
	System time: 9d, 23:26:13.520    
	Name: Jupiter 
	Description: 
	Location: 
	Contact: 
Running image: 
	Release: 2.0 
	Created on: Thu Jun 01 17:42:44 2000 
	Created by: PentaCom Ltd. 
	Length: 3054362 
	Signature: 0x7A784DA1 
	Software version: 2.0.213    
	Software created on: May 24 2000, 16:13:11 
	Bootstrap version: 3.0 
Jupiter# 

Use the Autoconnect Function

One of the assets of the ONS 15190 is that you can plug the fibers from the SRP line card or Port Adapter (PA) into any port, and the software configures the individual nodes. If there are enough SRP cards in the ONS 15190 to directly connect all nodes, you can use the autoconnect command to add all the SRP nodes it finds to the same default ring.

Exceptions

In most cases, you can use the autoconnect command and perform some manual adjustments if necessary. Here are some exceptions:

• If you choose to interconnect some nodes, and thus have partial connectivity to the ONS 15190, you must manually define a span that comprises side A of one node and side B of another node.

• If you choose to define multiple rings, or your SRP line cards do not support synchronous optical network (SONET) path trace messages, the autoconnect command will not work.

The sample configuration in this document represents a totally manual configuration.

Verify the Physical Connectivity

This sample configuration uses these names for the ONS 15190 and SRP nodes:

• ONS 15190 = Jupiter

• SRP nodes (Cisco 12000 Series routers) = Maxi, Mini, Cloud and Thunder

The easiest way to find out the node to port connections is to use the port all show trace command on the ONS 15190:

Jupiter#port all show trace 
Port     Hostname     IP         Interface     Side
L1.1     Maxi         1.1.1.1    SRP 0/0       A
L1.2     Cloud        1.1.1.5    SRP 1/0       B
L2.1     Mini         1.1.1.2    SRP 0/0       A
L2.2     Maxi         1.1.1.1    SRP 0/0       B
L3.1     Thunder      1.1.1.4    SRP 0/0       A
L3.2     Mini         1.1.1.2    SRP 0/0       B

This output indicates that:

• Maxi SRP line card, side A is connected to port L1.1.

• Maxi SRP line card, side B is connected to port L2.2.

• Mini SRP line card, side A is connected to port L2.1.

• Mini SRP line card, side B is connected to port L3.2.

• Cloud and Thunder are interconnected (Cloud, side A is connected to Thunder, side B) and:

  • Cloud SRP line card, side B is connected to port L1.2.

  • Thunder SRP line card, side A is connected to port L3.1.

Now use the system show box command to get more information:

Jupiter#system show box 

You can verify the connection on the nodes through the show controller srp command:

Thunder#show controller srp 0/0 
SRP0/0 - Side A (Outer RX, Inner TX) 
SECTION 
	LOF = 0 	LOS = 0 			BIP(B1) = 15 
LINE 
	AIS = 0 	RDI = 0 	FEBE = 307 	BIP(B2) = 203 
PATH 
	AIS = 0 	RDI = 0 	FEBE = 219 	BIP(B3) = 30 
	LOP = 0 	NEWPTR = 0 	PSE = 0 	NSE = 0 

Active Defects:	None 
Active Alarms:	None 
Alarm reporting enabled for: SLOS SLOF PLOP

Framing:                           SONET
Rx SONET/SDH bytes:                (K1/K2) = 0/0   S1S0 = 0    C2 = 0x16 J0 = 0xCC 
Tx SONET/SDH bytes:                (K1/K2) = 0/0   S1S0 = 0    C2 = 0x16 
Clock source:                      Internal
Framer loopback:                   None
Path tace buffer:                  Stable
Remote hostname:                   RingStar8000
Remote interface:                  SRPL3.1
Remote IP addr:                    10.200.28.100
Remote side id:                    B
BER thresholds:                    SF = 10e-3      SD = 10e-6
IPS BER thresholds(B3):            SF = 10e-3      SD = 10e-6
TCA thresholds:                    B1 = 10e-6      B2 = 10e-6   B3 = 10e-6 

SRP0/0 - Side B (Inner RX, Outer TX) 
SECTION    
	LOF = 0 	LOS = 0                 	BIP(B1) = 15 
LINE 
	AIS = 0 	RDI = 0 	FEBE = 155 	BIP(B2) = 188 
PATH    
	AIS = 0 	RDI = 0 	FEBE = 34 	BIP(B3) = 35 
	LOP = 0 	NEWPTR = 0 	PSE = 0 	NSE = 0 


Active Defects: None 
Active Alarms: None 
Alarm reporting enabled for: SLOS SLOF PLOP    


Framing            : SONET 
Rx SONET/SDH bytes	: (K1/K2) = 0/0  S1S0 = 0  C2 = 0x16 
Tx SONET/SDH bytes	: (K1/K2) = 0/0  S1S0 = 0  C2 = 0x16  J0 = 0xCC 
Clock source 		: Internal 
Framer    loopback 	: None 
Path trace buffer 	: Stable
Remote hostname 	: Cloud 
Remote interface	: SRP1/0 
Remote IP addr 		: 1.1.1.5 
Remote side id 		: A 

BER thresholds:         SF = 10e-3  SD = 10e-6 
IPS BER thresholds(B3): SF = 10e-3  SD = 10e-6 
TCA thresholds:         B1 = 10e-6  B2 = 10e-6  B3 = 10e-6

Here you can see that Thunder is connected to the ONS 15190 on side A and on port L3.1. You can also see that side B is connected to Cloud.

The ONS 15190 is a SONET Path Terminator that issues path trace messages if configured in normal mode. Optionally, you can configure ONS 15190 as transparent, in which case it mirrors the path trace messages that the adjacent nodes in the ring send to each other.

When you have gathered this information, you can start to define the nodes on the ONS 15190.

Define Nodes on the ONS 15190

Use the rconf command to modify the nodes and rings on the ONS 15190. Before you do this, check both the applied configuration and the current configuration:

Jupiter#rconf show ?
applied Show applied configuration 
current Show current shadow (editable) configuration 


Jupiter#rconf show current
Current shadow (editable) connection configuration: 

Sniff configuration: 
Sniffer             Port   Sniffed node   Port
----------------------------------------------
No sniffer nodes.


POS connections: 
Node                IP Address    Ports   Type   Other
------------------------------------------------------
No POS connections.


Ring configuration (nodes in order of outer ring): 
Ring             Name   Nodes   IP Address   A-Port   B-Port   Type   Other
---------------------------------------------------------------------------
No rings defined.

Jupiter#rconf show applied
Applied connection configuration: 

Sniff configuration: 
Sniffer             Port   Sniffed node   Port
----------------------------------------------
No sniffer nodes.


POS connections: 
Node                IP Address    Ports   Type   Other
------------------------------------------------------
No POS connections.


Ring configuration (nodes in order of outer ring): 
Ring             Name   Nodes   IP Address   A-Port   B-Port   Type   Other
---------------------------------------------------------------------------
No rings defined.

You can see from this output that nothing is configured yet. Start to manually configure the nodes, on the basis of the output that the port all show trace command generates.

Jupiter#port all show trace
Port     Hostname     IP         Interface     Side
L1.1     Maxi         1.1.1.1    SRP 0/0       A
L1.2     Cloud        1.1.1.5    SRP 1/0       B
L2.1     Mini         1.1.1.2    SRP 0/0       A
L2.2     Maxi         1.1.1.1    SRP 0/0       B
L3.1     Thunder      1.1.1.4    SRP 0/0       A
L3.2     Mini         1.1.1.2    SRP 0/0       B

For this, use the rconf node new command to inform the ONS 15190 which two ports form a node. Here is the format of this command:

rconf node new [srp/pos/sniff/aps/fiber] [oc12/oc48]

The nodes emit SONET path trace messages, and are currently connected. Therefore, you do not need to specify the node type (such as SRP or Packet-over-SONET), or state whether it is an optical carrier (OC) 12 or 48, because the ONS 15190 reads this information from the path trace message.

Jupiter#rconf node new Maxi l1.1 l2.2
OC12 SRP node Maxi created. 

Jupiter#rconf node new Mini l2.1 l3.2 
OC12 SRP node Mini created.

Jupiter#rconf node new span1 l3.1 l1.2 
OC12 SRP node span1 created. 

Jupiter#rconf show current 
Current shadow (editable) connection configuration:  

Sniff configuration: 
Sniffer             Port   Sniffed node   Port
----------------------------------------------
No sniffer nodes.


POS connections: 
Node                IP Address    Ports   Type   Other
------------------------------------------------------
No POS connections.


Ring configuration (nodes in order of outer ring): 
Ring             Name   Nodes   IP Address   A-Port   B-Port   Type   Other
---------------------------------------------------------------------------
No rings defined.

Free nodes: 
	Maxi		L1.1 L2.2 OC12 
	Mini		L2.1 L3.2 OC12 
	span1		L3.1 L1.2 OC12

Current configuration not yet applied.

Create a Logical Ring and Assign Nodes

After you define the nodes (all spanned parts are defined as one node), you need to create a logical ring, and assign nodes to the ring. Use the rconf ring new command:

Jupiter#rconf ring new ring1 
SRP ring ring1 created.

The rconf ring nodes command provides a quick way to add the free nodes to the ring. At the same time, this command lets you decide on the order of the ring.

Jupiter#rconf ring ring1 nodes Maxi Mini span1 
Ring ring1 node list set. 

Note: When you add a new node to an existing ring, the node is inserted at the end of the ring. You may therefore have to reorder the ring. See the Modify the Node Order of an Existing Ring section for instructions.

In order to check that all nodes are defined, check the current configuration again:

Jupiter#rconf show current
Current shadow (editable) connection configuration: 

Sniff configuration: 
Sniffer             Port   Sniffed node   Port
----------------------------------------------
No sniffer nodes.


POS connections: 
Node                IP Address    Ports   Type   Other
------------------------------------------------------
No POS connections.


Ring configuration (nodes in order of outer ring): 

Ring Name  Nodes   IP Address    A-Port   B-Port  Type   Other
--------------------------------------------------------------
ring1      Maxi                  L1.1     L2.2    OC12
           Mini                  L2.1     L3.2    OC12
           span1                 L3.1     L1.2    OC12 

Current configuration not yet applied. 

Now that the configuration is set, you need to apply the configuration:

Jupiter#rconf apply 
Configuration applied.
 
Jupiter#
9d, 22:33:33.202 Port L1.1 - Stop transmitting UNEQ. 
9d, 22:33:33.397 Port L1.2 - Stop transmitting UNEQ.    
9d, 22:33:33.590 Port L2.1 - Stop transmitting UNEQ. 
9d, 22:33:33.820 Port L2.2 - Stop transmitting UNEQ. 
9d, 22:33:34.004 Port L3.1 - Stop transmitting UNEQ.    
9d, 22:33:34.250 Port L3.2 - Stop transmitting UNEQ. 

In order to check if the ring creation is successful, look at one of the nodes. Use the show srp top command for this:

Thunder# 
*Jun 30 04:01:04.295: %SRP-4-WRAP_STATE_CHANGE: SRP0/0 unwrapped on side B 
*Jun 30 04:01:04.295: %SRP-4-ALARM: SRP0/0 Side A Keepalive OK 
*Jun 30 04:01:04.295: %SRP-4-WRAP_STATE_CHANGE: SRP0/0 wrapped on side B 
*Jun 30 04:01:04.299: %SRP-4-WRAP_STATE_CHANGE: SRP0/0 unwrapped on side B 
*Jun 30 04:01:04.299: %SRP-4-WRAP_STATE_CHANGE: SRP0/0 wrapped on side B 
*Jun 30 04:01:04.299: %SRP-4-WRAP_STATE_CHANGE: SRP0/0 unwrapped on side B 


Thunder#show srp top
Topology Map for Interface SRP0/0 
Topology pkt. sent every 5 sec. (next pkt. after 4 sec.) 
Last received topology pkt. 00:00:00 
Nodes on the ring: 4 

Hops(outer ring)   MAC               IP Address       Wrapped      Name
0                  0010.f608.ec00    1.1.1.4          No           Thunder
1                  0010.f60c.8c20    Unknown          No           Cloud
2                  0030.71f1.6c00    Unknown          No           Maxi
3                  0030.71f3.7c00    Unknown          No           Mini

Thunder# 

As soon as you type the rconf apply command, the ONS 15190 unwraps the individual isolated nodes, and creates the topology map through the SRP topology packets.

Modify the Node Order of an Existing Ring

In certain cases, you may want to reorder nodes on the ring. For example, if there is heavy traffic between two pairs of nodes, and these traffic flows currently overlap, and lead to poor bandwidth usage. In this example, assume that Thunder and Maxi have a constant high bandwidth exchange of data, as do Cloud and Mini. You can reorder these nodes so that the data flow from Thunder to Maxi does not interfere with the flow from Cloud to Mini:

Jupiter#rconf ring ring1 nodes Maxi span1 Mini 
Ring ring1 node list set. 

Jupiter#rconf apply  
Configuration applied. 

Jupiter#rconf show applied
Applied connection configuration:

Sniff configuration: 
Sniffer             Port   Sniffed node   Port
----------------------------------------------
No sniffer nodes.


POS connections: 
Node                IP Address    Ports   Type   Other
------------------------------------------------------
No POS connections.


Ring configuration (nodes in order of outer ring): 

Ring Name  Nodes   IP Address    A-Port   B-Port  Type   Other
--------------------------------------------------------------
ring1      Maxi                  L1.1     L2.2    OC12
           Mini                  L3.1     L1.2    OC12
           span1                 L2.1     L3.2    OC12 
Jupiter#

Now return to Thunder to verify the new order, and check the Address Resolution Protocol (ARP) table to see if everything went as expected:

Thunder#show srp top 
Topology Map for Interface SRP0/0 
Topology pkt. sent every 5 sec. (next pkt. after 2 sec.) 
Last received topology pkt. 00:00:02 
Nodes on the ring: 4 

Hops(outer ring)  MAC             IP Address            Wrapped      Name
0                 0010.f608.ec00  1.1.1.4               No           Thunder
1                 0010.f60c.8c20  1.1.1.5               No           Cloud
2                 0030.71f3.7c00  1.1.1.2               No           Mini
3                 0030.71f1.6c00  1.1.1.1               No           Maxi

Thunder#show arp | i SRP 
Internet 1.1.1.1 5 0030.71f1.6c00 SRP-A SRP0/0 
Internet 1.1.1.2 5 0030.71f3.7c00 SRP-B SRP0/0 
Internet 1.1.1.5 0 0010.f60c.8c20 SRP-B SRP0/0 
Internet 1.1.1.4 - 0010.f608.ec00 SRP SRP0/0 

The traffic from Thunder to Maxi now takes side A. Now go to Cloud, and check the same thing:

Cloud#show srp top
Topology Map for Interface SRP1/0 
Topology pkt. sent every 5 sec. (next pkt. after 0 sec.) 
Last received topology pkt. 00:00:04 
Nodes on the ring: 4 
Hops (outer ring) MAC IP Address Wrapped Name 
0 0010.f60c.8c20 1.1.1.5 No Cloud 
1 0030.71f3.7c00 1.1.1.2 No Mini 
2 0030.71f1.6c00 1.1.1.1 No Maxi 
3 0010.f608.ec00 1.1.1.4 No Thunder 

Cloud#show arp | i SRP 
Internet 1.1.1.1 0 0030.71f1.6c00 SRP-A SRP1/0 
Internet 1.1.1.2 0 0030.71f3.7c00 SRP-B SRP1/0 
Internet 1.1.1.5 - 0010.f60c.8c20 SRP SRP1/0 
Internet 1.1.1.4 2 0010.f608.ec00 SRP-A SRP1/0 
Cloud#

Traffic from Cloud to Mini takes side B, which means that the modification was successful as these two flows do not interfere with each other.

Note: Cisco recommends that you let the ONS 15190 automatically set the order of the ring for you in order to get maximum redundancy. Use the autoorder command for this:

Jupiter#rconf ring ring1 autoorder 
Ring ring1 reordered. 

Jupiter#rconf apply   
Configuration applied. 

Jupiter#rconf show applied
Applied connection configuration:  

Sniff configuration: 
Sniffer             Port   Sniffed node   Port
----------------------------------------------
No sniffer nodes.


POS connections: 
Node                IP Address    Ports   Type   Other
------------------------------------------------------
No POS connections.


Ring configuration (nodes in order of outer ring): 
Ring Name  Nodes   IP Address    A-Port   B-Port  Type   Other
--------------------------------------------------------------
ring1      Maxi                  L1.1     L2.2    OC12
           Mini                  L2.1     L3.2    OC12
           span1                 L3.1     L1.2    OC12 
Jupiter#

Now you are back to the initial configuration. You can now add or remove nodes, or reorder the ring and still not lose any packets on the ring.

Note: You may occasionally lose packets that are stuck in transit buffers of individual nodes when you remove or reorder the nodes. This can happen if, due to the new order, the source stripping removes the packets from the ring before the destination sees them.

Note: The system does not carry out any wrapping when you reorder nodes, even when you add an isolated node. This is because the ONS 15190 creates a one-node ring with the isolated node (so that it is on a ring of its own). This prevents unwrapping time loss when you add nodes to a ring.

Recommendations and Comments

When you set up the physical connectivity from the SRP nodes to the ONS 15190, Cisco recommends that you:

• Never put either two A-sides or two B-sides on the same card on the ONS 15190. If you connect two A-sides or B-sides to the same card and that card fails, you end up with lost two logical cross-connections (since side A must always be connected to side B), and the ring splits in two.

• Always connect one SRP node to two different cards on the ONS 15190. If you have one SRP node connected to only one card, and that card fails, the node is isolated from the ring.

Note: Cisco recommends that you do this to prevent redundancy, but everything still works if you do not.

Jupiter#system show box 

Assume that L1.1 and L1.2 are connected to the A-sides of two SRP nodes, and L2.1 and L2.2 are connected to the B-sides of those nodes. The logical connections need to go from L1 to L2 with:

• L1.1 connected to L2.1.

• L1.2 connected to L2.2.

This means that, if you lose L1, the entire ring disappears because you have lost both logical connections.

When you configure an SRP ring, try to follow these guidelines:

• For physical connectivity, connect a node to two different cards in order to achieve redundancy in case one card fails.

• Be careful not to end up with either two A-sides or two B-sides on the same card.

• Always try to maximize the number of vertical logical connections.

Cisco Support Community - Featured Conversations

Related Information

• SRP/DPT Technical Support
• Technical Support & Documentation - Cisco Systems