Brocade ICX 6650 Platform and Layer 2 Configuration Guide
Brocade ICX 6650 Platform and Layer 2 Configuration Guide
07.5.00
Part Number: 53-1002602-01
documentation@brocade.com


Metro Features : Metro Ring Protocol

Metro Ring Protocol
Metro Ring Protocol (MRP) is a Brocade proprietary protocol that prevents Layer 2 loops and provides fast reconvergence in Layer 2 ring topologies. It is an alternative to STP and is especially useful in Metropolitan Area Networks (MANs) where using STP has the following drawbacks:
Figure 1 shows an example of an MRP metro ring.
Figure 1 Metro ring – normal state
The ring in this example consists of four MRP nodes (Brocade switches). Each node has two interfaces with the ring. Each node also is connected to a separate customer network. The nodes forward Layer 2 traffic to and from the customer networks through the ring. The ring interfaces are all in one port-based VLAN. Each customer interface can be in the same VLAN as the ring or in a separate VLAN.
One node is configured as the master node of the MRP ring. One of the two interfaces on the master node is configured as the primary interface; the other is the secondary interface. The primary interface originates Ring Health Packets (RHPs), which are used to monitor the health of the ring. An RHP is forwarded on the ring to the next interface until it reaches the secondary interface of the master node. The secondary interface blocks the packet to prevent a Layer 2 loops.
Metro Ring Protocol configuration notes
MRP rings without shared interfaces (MRP Phase 1)
MRP Phase 1 allows you to configure multiple MRP rings, as shown in Figure 2, but the rings cannot share the same link. For example, you cannot configure ring 1 and ring 2 to each have interfaces 1/1/1 and 1/1/2.
Also, when you configure an MRP ring, any node on the ring can be designated as the master node for the ring. A master node can be the master node of more than one ring. (Refer to Figure 2.) Each ring is an independent ring and RHP packets are processed within each ring.
Figure 2 Metro ring – multiple rings
In this example, two nodes are each configured with two MRP rings. Any node in a ring can be the master for its ring. A node also can be the master for more than one ring.
MRP rings with shared interfaces (MRP Phase 2)
With MRP Phase 2, MRP rings can be configured to share the same interfaces as long as the interfaces belong to the same VLAN. Figure 3 shows examples of multiple MRP rings that share the same interface.
Figure 3 Examples of multiple rings sharing the same interface - MRP Phase 2
 
On each node that will participate in the ring, you specify the ring ID and the interfaces that will be used for ring traffic. In a multiple ring configuration, a ring ID determines its priority. The lower the ring ID, the higher priority of a ring.
A ring ID is also used to identify the interfaces that belong to a ring.
Figure 4 Interface IDs and types
 
For example, in Figure 4, the ID of all interfaces on all nodes on Ring 1 is 1 and all interfaces on all nodes on Ring 2 is 2. Port 1/1/1 on node S1 and Port 1/2/2 on S2 have the IDs of 1 and 2 since the interfaces are shared by Rings 1 and 2.
The ring ID is also used to determine an interface priority. Generally, a ring ID is also the ring priority and the priority of all interfaces on that ring. However, if the interface is shared by two or more rings, then the highest priority (lowest ID) becomes the priority of the interface. For example, in Figure 4, all interfaces on Ring 1, except for Port 1/1/1 on node S1 and Port 1/2/2 on node S2 have a priority of 1. Likewise, all interfaces on Ring 2, except for Port1/ 1/1 on node S1 and Port 1/2/2 on node S2 have a priority of 2. Port 1/1/1 on S1 and Port 1/2/2 on S2 have a priority of 1 since 1 is the highest priority (lowest ID) of the rings that share the interface.
If a node has interfaces that have different IDs, the interfaces that belong to the ring with the highest priority become regular ports. Those interfaces that do not belong to the ring with the highest priority become tunnel ports. In Figure 4, nodes S1 and S2 have interfaces that belong to Rings 1 and 2. Those interfaces with a priority of 1 are regular ports. The interfaces with a priority of 2 are the tunnel ports since they belong to Ring 2, which has a lower priority than Ring 1.
Selection of master node
Allowing MRP rings to share interfaces limits the nodes that can be designated as the master node. Any node on an MRP ring that does not have a shared interface can be designated as the ring master node. However, if all nodes on the ring have shared interfaces, nodes that do not have tunnel ports can be designated as the master node of that ring. If none of the nodes meet these criteria, you must change the rings’ priorities by reconfiguring the rings’ ID.
In Figure 4, any of the nodes on Ring 1, even S1 or S2, can be a master node since none of its interfaces are tunnel ports. However in Ring 2, neither S1 nor S2 can be a master node since these nodes contain tunnel ports.
Ring initialization
The ring shown in Figure 1 shows the port states in a fully initialized ring without any broken links. Figure 5 shows the initial state of the ring, when MRP is first enabled on the ring switches. All ring interfaces on the master node and member nodes begin in the Preforwarding state (PF).
Figure 5 Metro ring – initial state
MRP uses Ring Health Packets (RHPs) to monitor the health of the ring. An RHP is an MRP protocol packet. The source address is the MAC address of the master node and the destination MAC address is a protocol address for MRP. The Master node generates RHPs and sends them on the ring. The state of a ring port depends on the RHPs.
RHP processing in MRP Phase 1
A ring interface can have one of the following MRP states:
Preforwarding (PF) – The interface can forward RHPS but cannot forward data. All ring ports begin in this state when you enable MRP.
Forwarding (F) – The interface can forward data as well as RHPs. An interface changes from Preforwarding to Forwarding when the port preforwarding time expires. This occurs if the port does not receive an RHP from the Master, or if the forwarding bit in the RHPs received by the port is off. This indicates a break in the ring. The port heals the ring by changing its state to Forwarding. The preforwarding time is the number of milliseconds the port will remain in the Preforwarding state before changing to the Forwarding state, even without receiving an RHP.
Blocking (B) – The interface cannot forward data. Only the secondary interface on the Master node can be Blocking.
When MRP is enabled, all ports begin in the Preforwarding state. The primary interface on the Master node, although it is in the Preforwarding state like the other ports, immediately sends an RHP onto the ring. The secondary port on the Master node listens for the RHP.
Figure 6 shows an example.
Figure 6 Metro ring – from preforwarding to forwarding
Each RHP also has a sequence number. MRP can use the sequence number to determine the round-trip time for RHPs in the ring. Refer to “Metro Ring Protocol diagnostics”.
RHP processing in MRP Phase 2
Figure 7 shows an example of how RHP packets are processed normally in MRP rings with shared interfaces.
Figure 7 Flow of RHP packets on MRP rings with shared interfaces
 
Port 1/2/1 on Ring 1 master node is the primary interface of the master node. The primary interface forwards an RHP packet on the ring. Since all the interfaces on Ring 1 are regular ports, the RHP packet is forwarded to all the interfaces until it reaches Port 1/2/2, the secondary interface of the master node. Port 1/2/2 then blocks the packet to complete the process.
On Ring 2, Port 1/3/1, is the primary interface of the master node. It sends an RHP packet on the ring. Since all ports on S4 are regular ports, the RHP packet is forwarded on those interfaces. When the packet reaches S2, the receiving interface is a tunnel port. The port compares the packet priority to its priority. Since the packet priority is the same as the tunnel port priority, the packet is forwarded up the link shared by Rings 1 and 2.
When the RHP packet reaches the interface on node S2 shared by Rings 1 and 2, the packet is forwarded since its priority is less than the interface priority. The packet continues to be forwarded to node S1 until it reaches the tunnel port on S1. That tunnel port determines that the RHP packet priority is equal to the port priority and forwards the packet. The RHP packet is forwarded to the remaining interfaces on Ring 2 until it reaches port 1/3/2, the secondary interface of the master node. Port1/ 3/2 then blocks the packet to prevent a loop.
When the RHP packet from Ring 2 reached S2, it was also forwarded from S2 to S3 on Ring 1 since the port on S2 has a higher priority than the RHP packet. The packets is forwarded around Ring 1 until it reaches port 1/2/2, Ring 1 the secondary port. The RHP packet is then blocked by that port.
How ring breaks are detected and healed
Figure 8 shows ring interface states following a link break. MRP quickly heals the ring and preserves connectivity among the customer networks.
Figure 8 Metro ring – ring break
If a break in the ring occurs, MRP heals the ring by changing the states of some of the ring interfaces:
Blocking interface – The Blocking interface on the Master node has a dead timer. If the dead time expires before the interface receives one of its ring RHPs, the interface changes state to Preforwarding. Once the secondary interface changes state to Preforwarding:
-
-
Forwarding interfaces – Each member interface remains in the Forwarding state.
When the broken link is repaired, the link interfaces come up in the Preforwarding state, which allows RHPs to travel through the restored interfaces and reach the secondary interface on the Master node:
-
-
If the link between shared interfaces breaks (Figure 9), the secondary interface on Ring 1 master node changes to a preforwarding state. The RHP packet sent by port 1/3/1 on Ring 2 is forwarded through the interfaces on S4, then to S2. The packet is then forwarded through S2 to S3, but not from S2 to S1 since the link between the two nodes is not available. When the packet reaches Ring 1 master node, the packet is forwarded through the secondary interface since it is currently in a preforwarding state. A secondary interface in preforwarding mode ignores any RHP packet that is not from its ring. The secondary interface changes to blocking mode only when the RHP packet forwarded by its primary interface is returned.
The packet then continues around Ring 1, through the interfaces on S1 to Ring 2 until it reaches Ring 2 master node. Port 1/3/2, the secondary interface on Ring 2 changes to blocking mode since it received its own packet, then blocks the packet to prevent a loop.
Figure 9 Flow of RHP packets when a link for shared interfaces breaks
 
RHP packets follow this flow until the link is restored; then the RHP packet returns to it normal flow as shown in Figure 7.
Master VLANs and customer VLANs
All the ring ports must be in the same VLAN. Placing the ring ports in the same VLAN provides Layer 2 connectivity for a given customer across the ring. Figure 10 shows an example.
Figure 10 Metro ring – ring VLAN and customer VLANs
 
Notice that each customer has their own VLAN. Customer A has VLAN 30 and Customer B has VLAN 40. Customer A host attached to Switch D can reach the Customer A host attached to Switch B at Layer 2 through the ring. Since Customer A and Customer B are on different VLANs, they will not receive each other traffic.
You can configure MRP separately on each customer VLAN. However, this is impractical if you have many customers. To simplify configuration when you have a lot of customers (and therefore a lot of VLANs), you can use a topology group.
A topology group enables you to control forwarding in multiple VLANs using a single instance of a Layer 2 protocol such as MRP. A topology group contains a master VLAN and member VLANs. The master VLAN contains all the configuration parameters for the Layer 2 protocol (STP, MRP, or VSRP). The member VLANs use the Layer 2 configuration of the master VLAN.
In Figure 10, VLAN 2 is the master VLAN and contains the MRP configuration parameters for ring 1. VLAN 30 and VLAN 40, the customer VLANs, are member VLANs in the topology group. Since a topology group is used, a single instance of MRP provides redundancy and loop prevention for both the customer VLANs.
If you use a topology group:
For more information about topology groups, refer to “Topology groups”.
Refer to “MRP CLI example” for the configuration commands required to implement the MRP configuration shown in Figure 10.
Metro Ring Protocol configuration
To configure Metro Ring Protocol (MRP), perform the following tasks. You need to perform the first task on only one of the nodes. Perform the remaining tasks on all the nodes.
NOTE: There are no new commands or parameters to configure MRP with shared interfaces (MRP Phase 2).
-
-
-
-
-
When configuring MRP-1 or MRP-2 rings on a VLAN, using the metro-rings command in addition to the metro-ring command is highly recommended. Since these devices do not support mac-range filtering, the metro-rings command greatly reduces the number of FDB entries.
Adding an MRP ring to a VLAN
To add an MRP ring to a VLAN, enter commands such as the following.
NOTE: If you plan to use a topology group to add VLANs to the ring, make sure you configure MRP on the topology group master VLAN.
Brocade(config)# vlan 2
Brocade(config-vlan-2)# metro-ring 1
Brocade(config-vlan-2-mrp-1)# name CustomerA
Brocade(config-vlan-2-mrp-1)# master
Brocade(config-vlan-2-mrp-1)# ring-interface ethernet 1/1/1 ethernet 1/1/2
Brocade(config-vlan-2-mrp-1)# enable
 
These commands configure an MRP ring on VLAN 2. The ring ID is 1, the ring name is Customer A, and this node (this Brocade device) is the master for the ring. The ring interfaces are 1/1/1 and 1/1/2. Interface 1/1/1 is the primary interface and 1/1/2 is the secondary interface. The primary interface will initiate RHPs by default. The ring takes effect in VLAN 2.
Brocade(config)# vlan 2
Brocade(config-vlan-2)# metro-ring 1
Brocade(config-vlan-2-mrp-1)# name CustomerA
Brocade(config-vlan-2-mrp-1)# ring-interface ethernet 1/1/1 ethernet 1/1/2
Brocade(config-vlan-2-mrp-1)# enable
Brocade(config-vlan-2-mrp-1)# metro-ring 2
Brocade(config-vlan-2-mrp-2)# name CustomerB
Brocade(config-vlan-2-mrp-2)# ring-interface ethernet 1/1/1 ethernet 1/1/2
Brocade(config-vlan-2-mrp-2)# enable
Syntax:
[no] metro-ring ring id
The ring-id parameter specifies the ring ID. The ring-id can be from 1–1023; ID 256 is reserved for VSRP.
Enter the metro-rings in addition to the metro-ring command as shown below.
Brocade(config)#vlan 2
Brocade(config-vlan-2)#metro-rings 1 2
Brocade(config-vlan-2)#metro-ring 1
Brocade(config-vlan-2-mrp-1)#name CustomerA
Brocade(config-vlan-2-mrp-1)#ring-interface ethernet 1/1/1 ethernet 1/1/2
Brocade(config-vlan-2-mrp-1)#enable
Brocade(config-vlan-2-mrp-1)#metro-ring 2
Brocade(config-vlan-2-mrp-2)#name CustomerB
Brocade(config-vlan-2-mrp-2)#ring-interface ethernet 1/1/1 ethernet 1/1/2
Brocade(config-vlan-2-mrp-2)#enable
Syntax:
[no] metro-rings ring-id ring -d...
The ring-id variables identify the metro rings you want to configure on the VLAN.
Syntax:
[no] name string
The string parameter specifies a name for the ring. The name is optional, but it can be up to 20 characters long and can include blank spaces. If you use a name that has blank spaces, enclose the name in double quotation marks (for example: “Customer A”).
Syntax:
[no] master
Configures this node as the master node for the ring. Enter this command only on one node in the ring. The node is a member (non-master) node by default.
Syntax:
[no] ring-interface ethernet primary-if ethernet secondary-if
The ethernet primary-if parameter specifies the primary interface. On the master node, the primary interface is the one that originates RHPs. Ring control traffic and Layer 2 data traffic will flow in the outward direction from this interface by default. On member nodes, the direction of traffic flow depends on the traffic direction selected by the master node. Therefore, on a member node, the order in which you enter the interfaces does not matter.
The ethernet secondary-if parameter specifies the secondary interface.
NOTE: To take advantage of every interface in a Metro network, you can configure another MRP ring and either configure a different Master node for the ring or reverse the configuration of the primary and secondary interfaces on the Master node. Configuring multiple rings enables you to use all the ports in the ring. The same port can forward traffic one ring while blocking traffic for another ring.
Syntax:
[no] enable
The enable command enables the ring.
Changing the hello and preforwarding times
You also can change the RHP hello time and preforwarding time. To do so, enter commands such as the following.
Brocade(config-vlan-2-mrp-1)# hello-time 200
Brocade(config-vlan-2-mrp-1)# preforwarding-time 400
 
These commands change the hello time to 200 ms and change the preforwarding time to 400 ms.
Syntax:
[no] hello-time ms
Syntax:
[no] preforwarding-time ms
The ms specifies the number of milliseconds. For the hello time, you can specify from 100-1000 (one second). The default hello time is 100 ms. The preforwarding time can be from 200–5000 ms, but must be at least twice the value of the hello time and must be a multiple of the hello time. The default preforwarding time is 300 ms. A change to the hello time or preforwarding time takes effect as soon as you enter the command.
Configuration notes for changing the hello and preforwarding times
Metro Ring Protocol diagnostics
The Metro Ring Protocol (MRP) diagnostics feature calculates how long it takes for RHP packets to travel through the ring. When you enable MRP diagnostics, the software tracks RHP packets according to their sequence numbers and calculates how long it takes an RHP packet to travel one time through the entire ring. When you display the diagnostics, the CLI shows the average round-trip time for the RHP packets sent since you enabled diagnostics. The calculated results have a granularity of 1 microsecond.
Enabling MRP diagnostics
To enable MRP diagnostics for a ring, enter the following command on the Master node, at the configuration level for the ring.
Brocade(config-vlan-2-mrp-1)# diagnostics
 
Syntax:
[no] diagnostics
NOTE: This command is valid only on the master node.
Displaying MRP diagnostics
To display MRP diagnostics results, enter the following command on the Master node.
Syntax:
show metro ring-id diag
This display shows the following information.
 
If the recommended hello time and preforwarding time are different from the actual settings and you want to change them, refer to “Metro Ring Protocol configuration”.
Displaying MRP information
You can display the following MRP information:
Displaying topology group information
To display topology group information, enter the following command.
Syntax:
Refer to “Displaying topology group information” for more information.
Displaying ring information
To display ring information, enter the following command.
Syntax:
show metro [ring-id]
This display shows the following information.
 
enabled – MRP is enabled
disabled – MRP is disabled
secondary – The interface does not generate RHPs.
blocking – The interface is blocking Layer 2 data traffic and RHPs
disabled – The interface is down
forwarding – The interface is forwarding Layer 2 data traffic and RHPs
preforwarding – The interface is listening for RHPs but is blocking Layer 2 data traffic
MRP CLI example
The following examples show the CLI commands required to implement the MRP configuration shown in Figure 10.
NOTE: For simplicity, the figure shows the VLANs on only two switches. The CLI examples implement the ring on all four switches.
MRP commands on Switch A (master node)
The following commands configure a VLAN for the ring. The ring VLAN must contain both of the node interfaces with the ring. Add these interfaces as tagged interfaces, since the interfaces also must be in each of the customer VLANs configured on the node.
Brocade(config)# vlan 2
Brocade(config-vlan-2)# tag ethernet 1/1/1 to 1/1/2
Brocade(config-vlan-2)# metro-ring 1
Brocade(config-vlan-2-mrp-1)# name “Metro A”
Brocade(config-vlan-2-mrp-1)# master
Brocade(config-vlan-2-mrp-1)# ring-interface ethernet 1/1/1 ethernet 1/1/2
Brocade(config-vlan-2-mrp-1)# enable
Brocade(config-vlan-2-mrp-1)# exit
Brocade(config-vlan-2)# exit
 
The following commands configure the customer VLANs. The customer VLANs must contain both the ring interfaces as well as the customer interfaces.
Brocade(config)# vlan 30
Brocade(config-vlan-30)# tag ethernet 1/1/1 to 1/1/2
Brocade(config-vlan-30)# tag ethernet 1/2/1
Brocade(config-vlan-30)# exit
Brocade(config)# vlan 40
Brocade(config-vlan-40)# tag ethernet 1/1/1 to 1/1/2
Brocade(config-vlan-40)# tag ethernet 1/2/2
Brocade(config-vlan-40)# exit
 
The following commands configure topology group 1 on VLAN 2. The master VLAN is the one that contains the MRP configuration. The member VLANs use the MRP parameters of the master VLAN. The control interfaces (the ones shared by the master VLAN and member VLAN) also share MRP state.
Brocade(config)# topology-group 1
Brocade(config-topo-group-1)# master-vlan 2
Brocade(config-topo-group-1)# member-vlan 30
Brocade(config-topo-group-1)# member-vlan 40
MRP commands on Switch B
The commands for configuring Switches B, C, and D are similar to the commands for configuring Switch A, with two differences: the nodes are not configured to be the ring master. Omitting the master command is required for non-master nodes.
Brocade(config)# vlan 2
Brocade(config-vlan-2)# tag ethernet 1/1/1 to 1/1/2
Brocade(config-vlan-2)# metro-ring 1
Brocade(config-vlan-2-mrp-1)# name “Metro A”
Brocade(config-vlan-2-mrp-1)# ring-interface ethernet 1/1/1 ethernet 1/1/2
Brocade(config-vlan-2-mrp-1)# enable
Brocade(config-vlan-2)# exit
Brocade(config)# vlan 30
Brocade(config-vlan-30)# tag ethernet 1/1/1 to 1/1/2
Brocade(config-vlan-30)# tag ethernet 1/2/1
Brocade(config-vlan-30)# exit
Brocade(config)# vlan 40
Brocade(config-vlan-40)# tag ethernet 1/1/1 to 1/1/2
Brocade(config-vlan-40)# tag ethernet 1/3/1
Brocade(config-vlan-40)# exit
Brocade(config)# topology-group 1
Brocade(config-topo-group-1)# master-vlan 2
Brocade(config-topo-group-1)# member-vlan 30
Brocade(config-topo-group-1)# member-vlan 40
MRP commands on Switch C
Brocade(config)# vlan 2
Brocade(config-vlan-2)# tag ethernet 1/1/1 to 1/1/2
Brocade(config-vlan-2)# metro-ring 1
Brocade(config-vlan-2-mrp-1)# name “Metro A”
Brocade(config-vlan-2-mrp-1)# ring-interface ethernet 1/1/1 ethernet 1/1/2
Brocade(config-vlan-2-mrp-1)# enable
Brocade(config-vlan-2)# exit
Brocade(config)# vlan 30
Brocade(config-vlan-30)# tag ethernet 1/1/1 to 1/1/2
Brocade(config-vlan-30)# tag ethernet 1/2/1
Brocade(config-vlan-30)# exit
Brocade(config)# vlan 40
Brocade(config-vlan-40)# tag ethernet 1/1/1 to 1/1/2
Brocade(config-vlan-40)# tag ethernet 1/3/1
Brocade(config-vlan-40)# exit
Brocade(config)# topology-group 1
Brocade(config-topo-group-1)# master-vlan 2
Brocade(config-topo-group-1)# member-vlan 30
Brocade(config-topo-group-1)# member-vlan 40
MRP commands on Switch D
Brocade(config)# vlan 2
Brocade(config-vlan-2)# tag ethernet 1/1/1 to 1/1/2
Brocade(config-vlan-2)# metro-ring 1
Brocade(config-vlan-2-mrp-1)# name “Metro A”
Brocade(config-vlan-2-mrp-1)# ring-interface ethernet 1/1/1 ethernet 1/1/2
Brocade(config-vlan-2-mrp-1)# enable
Brocade(config-vlan-2)# exit
Brocade(config)# vlan 30
Brocade(config-vlan-30)# tag ethernet 1/1/1 to 1/1/2
Brocade(config-vlan-30)# tag ethernet 1/2/1
Brocade(config-vlan-30)# exit
Brocade(config)# vlan 40
Brocade(config-vlan-40)# tag ethernet 1/1/1 to 1/1/2
Brocade(config-vlan-40)# tag ethernet 1/3/1
Brocade(config-vlan-40)# exit
Brocade(config)# topology-group 1
Brocade(config-topo-group-1)# master-vlan 2
Brocade(config-topo-group-1)# member-vlan 30
Brocade(config-topo-group-1)# member-vlan 40

Metro Features : Metro Ring Protocol