Manually Configuring an SRP Ring on the ONS 15190 and Modifying Existing SRP Configurations
Available Languages
Contents
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
| CTRL 1 | LINE 1 | LINE 2 | LINE 3 | LINE 4 | SW 1 | SW 2 | SW 3 | SW 4 | SW 5 | LINE 5 | LINE 6 | LINE 7 | LINE 8 | CTRL 2 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| OPER i960 | OPER OC12 | OPER OC12 | OPER OC12 | OPER | OPER | OPER | OPER | OPER | OPER OC12 | OPER i960 | ||||
| L1.1 OPER LINK L1.2 OPER LINK | L2.1 OPER LINK L2.2 OPER LINK | L3.1 OPER LINK L3.2 OPER LINK | L8.1 OPER LINK UNEQ L8.2 LINK UNEQ | ACT THIS CTRL |
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
| CTRL 1 | LINE 1 | LINE 2 | LINE 3 | LINE 4 | SW 1 | SW 2 | SW 3 | SW 4 | SW 5 | LINE 5 | LINE 6 | LINE 7 | LINE 8 | CTRL 2 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| OPER i960 | OPER OC12 | OPER OC12 | OPER OC12 | OPER | OPER | OPER | OPER | OPER | OPER OC12 | OPER i960 | ||||
| L1.1 OPER LINK L1.2 OPER LINK | L2.1 OPER LINK L2.2 OPER LINK | L3.1 OPER LINK L3.2 OPER LINK | L8.1 OPER LINK L8.2 OPER LINK | ACT THIS CTRL |
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.
Related Information
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)