Saturday, June 4, 2011

Comware RRPP usage in layer 2 bridging - notes and configuration

Most switching vendors nowaday have an implementation of a ring protocol with fast convergence to replace slower STP and all its associated pitfalls.

Comware has RRPP (Rapid Ring Protection Protocol - based on Extreme EAPS or IETF RFC 3619 ), Cisco has REP (Resilient Ethernet Protocol), Brocade has MRP (Metro Ring Protocol), Juniper has ERP (Ethernet Ring Protocol) and other vendors likely all have their own approach to ring type topologies.

Most of these protocols tend to define more or less a similar technique in which one device along the ring is defined as the master and blocks an interface from transmitting trafic unless a failure is detected in the ring. Most of the ring protocols offer support for intersecting / overlapping rings. Cisco's REP offers support for the ring to have one of its segment shared with STP.

This post centers around implementing a single Comware RRPP ring on HP A-series switches. While ring protocols allow for extremely fast convergence, another very useful function is their capability to isolate STP domains. This is due to ring protocols replacing STP on the links over which they run (with the notable exception of REP's capability to share a single segment with STP). Isolating STP fault domains is a worthwhile feature which I tend to recommend in datacenter bridging topologies in which a remote datacenter uses a pair of layer 2 links for connectivity and redundancy (a necessary evil in today's "vmotion" world). Running a ring protocol over such redundant links not only means fast convergence, but also isolation of the 2 site's STP domains, a clear security improvement over having the whole thing converge as one.

The following schema presents a typical topology associated with implementing RRPP for bridging two sites at layer 2 redundantly and the biggest pitfall associated with ring protocols:


This topology makes use of redundant switches in each site to terminate both links, resulting in 4 devices participating in the ring. As the ring devices are themselves connected to an existing STP domain, one can likely foresee the two network loops that will result from this topology being implemented. The fact that RRPP would only block the backup link and that BPDUs would not be exchanged over the ring would result in a loop being created between all 4 of each site's switches. Cisco's REP's ability to share a single link with STP in an open ring topology would only solve one of the above loops, and the second site would remain with a loop condition.

There are two solutions that can alleviate this issue:
  1. Virtualize the STP switches and use a technology like HP Smart Links or Cisco Flex Links to ensure that link down due to a defective ring switch results in an alternate link to the second ring switch is brought up. Cisco users would have to resort to using Stackwise-equipped switches or a VSS pair, limiting product selection to 3750s and 6500s and ME-series switches for the ring (Cisco does not support REP on anything else than SP gear). HP users could pick just about any device that supports IRF and Smart Links, which is comprised of 90% of the A-series product line, and RRPP-supporting switches, which would be comprised of the 5120 and above.
  2. Virtualize the ring switches, and talk STP with the site's existing STP domain. A clearly simpler approach which greatly simplifies configuration of both the ring and each site's implementation. While at this point Cisco users are limited to using ME3750s to achieve this (only Metro Ethernet products support REP), HP users can once again pick any A-series device that supports IRF and RRPP, which means the 5120, 5500, 5800 and above.
  3. Virtulize the ring switches and the site's STP domain switches: STP-free, link-aggregation all-links-active network utopia! The HP solution will involve doing it all within the same IRFed 5500s, using IRFed 5120s for the ring and IRFed 5500s for your layer 3 site's core or any chassis solution. Cisco users will find themselves implementing that with stackwised ME3750s at the ring and stackwised 3750s or VSSed 6500s with at the core, all of which will carry a high price tag.

RRPP is implemented on A-series through the definition of an MST instance (it only uses MST's instance constructs - it does not rely on MST any other way) and association of a ring to protect the created instance. Take heed that any misconfiguration of the MST instance, including forgetting to activate the region config, can result in a loop being created. Make sure you adjust your region configuration before allowing any new VLANs on your ring-enabled port's trunking configs. Additionally, each RRPP domain uses 2 control VLANs to exchange ring state over - the number provided in the configuration will actually end up also reserving the next vlan (4092 being configured below also uses 4093).


stp region-configuration
 region-name TEST
 instance 1 vlan 1 to 4000
 active region-configuration
#
interface GigabitEthernet1/0/24
 port link-mode bridge
 port link-type trunk
 port trunk permit vlan 1
 stp disable
#
rrpp domain 1
 control-vlan 4092
 protected-vlan reference-instance 1
 timer hello-timer 2 fail-timer 7
 timer fast-hello-timer 100
 ring 1 node-mode master primary-port GigabitEthernet1/0/21 secondary-port GigabitEthernet1/0/22 level 0
 ring 1 enable

1 comment:


  1. Excellent blogs!!!!you have for sharing them effect information..we developer very learning to easy

    123 HP oj3830

    ReplyDelete