Cisco REP (Resilient Ethernet Protocol)

REP is a Cisco proprietary protocol used to manage loops in Ethernet ring topologies. In a perfect ring, one link must always be blocked in order to prevent a loop. But in the event of another link failing, the blocked linked should forward again to restore reachability on the ring.

Take the following topology below:

In this ring, all devices can either be routers or switches but the links must all be layer 2. If all ports were forwarding and the topology was not running STP, you would have a forwarding loop, because BUM traffic would loop around the ring endlessly.

The problem with using STP in a carrier ethernet ring topology is that it is much too slow to converge. RSTP can converge from a link failure very quickly, but from a “soft failure” in which the link is still up but not passing traffic, RSTP will have to miss 3x BPDUs which are by default sent at 2 second intervals. A service provider needs failure detection and recovery that happens within tens of miliseconds.

A ring topology is actually a fairly simply layer 2 topology when it comes to loop prevention. In a ring you must always have one single port in blocking mode. If any other link in the ring fails, you must bring that “predetermined” blocking port back into forwarding. If more than one link fails, the ring will be broken no matter what. So a ring can only handle a single link failure.

For example, we can block Gi1 on R5:

The downside is that R5 now needs to forward traffic towards R1 all the way around the ring (R5-R4-R3-R2-R1) instead of directly to R1. However, we have N + 1 link redundancy, because if any link in the ring fails, R5 can bring Gi1 up again.

Essentially, loop free management of a ring turns it into a flat line:

REP Terms

Segment

In REP, the entire ring is called a segment. This can be a little confusing because your inclination is to think of each individual link as a segment. Instead the ring itself is a single segment, which REP will manage and block a single port on that segment. A segment ID uniquely defines the segment, and it is present in REP messages when the segment is built. All devices on the segment must be configured with the same segment ID, otherwise two devices will not form a REP adjacency.

Edge Ports

Every segment is terminated by two edge ports. These ports define the beginning and end of a segment. In a perfect ring, any two ports on a single node can be an edge port.

For example, we can make Gi1 and Gi2 on R1 edge ports:

REP now sees the segment as this:

Edge ports send End Port Advertisement messages, by default every four seconds. These are sent end-to-end through the segment to disocver the topology.

Open Port

An open port is comparable to an STP forwarding port. It operates normally and forwards traffic. In a closed ring under normal conditions, all ports will be Open except for one Alternate port.

Alternate Port

The port which is pre-selected to be blocked is called the alternate port. If any other link in the ring fails, this port will transition to Open.

Failed Port

This is a port which was previously Open, but the link has gone down (failed). If a Failed port exists in a ring topology, there should no longer be an Alternate port in the topology.

These are link-local messages used to detect a REP neighbor on the link and determine the helath of a link. REP uses local link failure detection. LSL PDUs can be sent at a very fast interval, which probably varies based on platform. When you lower the interval to say, 200ms, it uses up some CPU but allows for faster failover detection. A source says that by deafult a port will take five seconds to detect a fault that does not directly bring the interface down, but I cannot confirm this. When a link fails, each node at the edge of that failed link sends a notification up the segment.

Configuration

Unfortunately REP is not supported on any virtual platforms. If you wanted to test this yourself you would need ME switches or 3650s. However the configuration is quite basic, so I will explain it here so you get a sense of how REP is configured.

  1. Configure a REP admin VLAN on each switch/device.

    rep admin vlan vlan-id

    You will be able to see the REP admin vlan using show interface:

    show int Gi0/0/0 rep detail
    
    GigabitEthernet0/0 REP enabled
    Segment-id: 1 (Edge)
    <---snip--->

  2. Configure each interface as a REP segment and specify the segment ID. For edge ports, add the edge keyword.

    int Gi0/0/0
     rep segment 1 [edge]

This is the bare minimum needed to have a function REP topology. Of course there are more options but they are not detailed here because we can not test and verify them.

REP Advanced Features

Per-VLAN load balancing

REP can load balance per VLAN somewhat like per-vlan STP. You configure the alternate port to only block some VLANs, and all remaining VLANs are blocked on the primary edge port. In this way you have two separate forwarding paths for each group of VLANs.

Open Segments

In an open segment, the two edge ports do not connect to the same router. This is used when you have a partial ring that connects to another layer 2 network.

For example, let’s say we add more layer 2 devices to our existing ring. Below I’ve added R10 through R13 and connected the partial ring to R4 to form a second ring:

Segment 1 is represented by the black line and is a closed ring. Segment 2 is represented by the blue line and is an open ring. This allows us a more simple configuration, because R4 does not need to participate in two separate segments. Or in other cases, the operator of Segment 2 might not have administrative control of R4 and cannot configure it to even participate in REP.

The open ring works, because as long as any one port within Segment 2 is an alternate port, there will be no layer 2 loops. An open ring relies on connectivity to some other layer 2 network to provide connectivity between each “open” end of the ring.

Further Reading

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/lanswitch/configuration/xe-3s/lanswitch-xe-3s-book/lsw-cfg-rep.html

https://reaper81.wordpress.com/2013/11/11/resilient-ethernet-protocol-rep/

https://ipfiles.wordpress.com/2015/01/30/carrier-ethernet-design-with-resilient-ethernet-protocol-rep/

https://www.reddit.com/r/networking/comments/8nnrb4/cisco_resilient_ethernet_protocol_an_alternative/

Last updated