High-availability Seamless Redundancy
High-availability Seamless Redundancy (HSR) is defined in International Standard IEC 62439-3-2016 clause 5. HSR is similar to Parallel Redundancy Protocol (PRP) but is designed to work in a ring topology. Instead of two parallel independent networks of any topology (LAN-A and LAN-B), HSR defines a ring with traffic in opposite directions. Port-A sends traffic counter clockwise in the ring, and Port-B sends traffic clockwise in the ring.
The HSR packet format is also different from PRP. To allow the switch to determine and discard duplicate packets, additional protocol specific information is sent with the data frame. For PRP, this is sent as part of a trailer called the redundancy control trailer (RCT), whereas for HSR this is sent as part of the header called the HSR header. Both the RCT and HSR header contain a sequence number, which is the primary data used to determine if the received frame is the first instance or a duplicate instance.
 Note |
HSR is supported on certain SKUs of the Cisco Catalyst IE9300 Rugged Series Switches (see the Guidelines and Limitations section in this guide for supported SKUs). The term switch in this document refers to a Cisco Catalyst IE9300 Rugged Series Switch unless otherwise noted. |
In this release, the switch supports only HSR-singly attached node (SAN) and only one HSR instance. In addition, you can create only one HSR or one PRP instance. If you have created a PRP instance, no HSR instance can be created.
The non-switching nodes with two interfaces attached to the HSR ring are referred to as Doubly Attached Nodes implementing HSR (DANHs). Similar to PRP, Singly Attached Nodes (SANs) are attached to the HSR ring through a device called a RedBox (Redundancy Box). The RedBox acts as a DANH for all traffic for which it is the source or the destination. The switch implements RedBox functionality using Gigabit Ethernet port connections to the HSR ring.
The following figure shows an example of an HSR ring as described in IEC 62439-3. In this example, the RedBox is an Cisco Catalyst IE9300 Rugged Series Switch.
Devices that do not support HSR out of the box (for example, laptops and printers) cannot be attached to the HSR ring directly because all HSR capable devices must be able to process the HSR header on packets received from the ring and add the HSR header to all packets sent into the ring. These nodes are attached to the HSR ring through a RedBox. As shown in the figure above, the RedBox has two ports on the DANH side. Non-HSR SAN devices are attached to the upstream switch ports. The RedBox generates the supervision frames on behalf of these devices so that they are seen as DANH devices on the ring. Because the RedBox emulates these as DANH, they are called Virtual Doubly Attached Nodes (VDAN).
Loop Avoidance
Each node in the HSR ring forwards frames received from one port to the other port of the HSR pair. To avoid loops and use network bandwidth effectively, the RedBox does not transmit frames that are already transmitted in same direction. When a node injects a packet into the ring, the packet is handled as follows to avoid loops:
-
Unicast packet with destination inside the ring: When the unicast packet reaches the destination node, the packet is consumed by the respective node and is not forwarded.
-
Unicast packet with destination not inside the ring: Because this packet does not have a destination node in the ring, it is forwarded by every node in the ring until it reaches the originating node. Because every node has a record of the packet it sent, along with the direction in which it was sent, the originating node detects that packet has completed the loop and drops the packet.
-
Multicast packet: A multicast packet is forwarded by each node because there can be more than one consumer of this packet. For this reason a multicast packet always reaches the originating node. However, every node will check whether it has already forwarded the received packet through its outgoing interface. Once the packet reaches the originating node, the originating node determines that it already forwarded this packet and drops the packet instead of forwarding it again.
HSR RedBox Modes of Operation
The most basic mode of operation is HSR-SAN mode (single RedBox mode). In this mode, the RedBox is used to connect SAN devices to the HSR ring. The Redbox’s responsibility in this mode is to represent SAN devices as VDANs on the ring.
Note |
In this release, the switch supports HSR-SAN mode only. |
HSR SAN Mode
In HSR-SAN mode, the RedBox inserts the HSR tag on behalf of the host and forwards the ring traffic, except for frames sent by the node itself, duplicate frames, and frames for which the node is the unique destination. In this mode, packets are handled as follows:
-
A source DANH sends a frame passed from its upper layers (C frame), prefixes it with an HSR tag to identify frame duplicates, and sends the frame over each port (A frame and B frame).
-
A destination DANH receives two identical frames from each port within a certain interval. The destination DANH removes the HSR tag of the first frame before passing it to its upper layers and discards any duplicate.
-
Each node in the HSR ring forwards frames received from one port to the other port of the HSR pair. A node will not forward frames received on one port to the other under the following conditions:
-
The received frame returns to the originating node in the ring.
-
The frame is a unicast frame with a destination MAC address of a node upstream of the receiving node.
-
The node had already sent the same frame in the same direction. This rule prevents a frame from spinning in the ring in an infinite loop.
-
CDP and LLDP for HSR
HSR supports the Cisco Discovery Protocol (CDP) and Link Layer Discovery Protocol (LLDP). CDP and LLDP are Layer 2 neighbor discovery protocols. Both CDP and LLDP can provide information about nodes directly connected to the device. They also provide additional information such as the local and remote interface and device names.
When CDP or LLDP is enabled, you can use the CDP or LLDP information to find the adjacent nodes on an HSR ring and their status. You can then use the neighbor information from each node to determine the complete HSR network topology and debug and locate ring faults.
CDP and LLDP are configured on physical interfaces only.
For more information, see Configuring an HSR Ring and Verifying Configuration.
HSR Uplink Redundancy Enhancement
The HSR Uplink Redundancy Enhancement feature allows for flexible designs that enable two separate interfaces to connect upstream from the HSR ring through two separate HSR RedBoxes. This ensures there is no single point of failure exiting the HSR ring. Examples of protocols that can leverage this feature to improve high availability include HSRP, VRRP and REP. Prior to this enhancement, if these protocols were utilized on redundant uplinks, undesirable results could occur, such as next-hop split-brain conditions or slow REP failover times.
The following diagram shows an example network with HSR and HSRP that allows uplink next-hop gateway redundancy out of the HSR ring.
To implement HSR Uplink Redundancy, ensure that the fpgamode-DualUplinkEnhancement feature is not disabled. This feature is required to support the connectivity to a dual router (HSRP in this case) on the distribution layer:
Switch#show hsr ring 1 detail | include fpgamode
fpgamode-DualUplinkEnhancement: Enabled
If the output shows fpgamode-DualUplinkEnhancement,:Disabled issue the following command:
Switch# conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)# hsr-ring 1 fpgamode-DualUplinkEnhancement
Switch(config)# end
HSRP Configuration
The following example HSRP configuration applies to the two distribution switches Active & Standby in the above figure. In the following configuration, HSRP is configured in a Switch Virtual Interface (SVI).
Active# conf t
Enter configuration commands, one per line. End with CNTL/Z.
Active(config)# interface vlan 10
Active(config-if)# ip address 30.30.30.2 255.255.255.0
Active(config-if)# standby 1 ip 30.30.30.1
Active(config-if)# standby 1 priority 120
Active(config-if)# end
Standby# conf t
Enter configuration commands, one per line. End with CNTL/Z.
Standby(config)# interface Vlan10
Standby(config-if)# ip address 30.30.30.4 255.255.255.0
Standby(config-if)# standby 1 ip 30.30.30.1
Standby(config-if)# end
Active# show standby
Vlan10 - Group 1
State is Active
8 state changes, last state change 00:03:55
Track object 1 (unknown)
Virtual IP address is 30.30.30.1
Active virtual MAC address is 0000.0c07.ac01 (MAC In Use)
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 200 msec, hold time 750 msec
Next hello sent in 0.176 secs
Preemption enabled, delay min 5 secs, reload 5 secs, sync 5 secs
Active router is local
Standby router is 30.30.30.4, priority 100 (expires in 0.656 sec)
Priority 120 (configured 120)
Group name is "hsrp-Vl10-1" (default)
FLAGS: 0/1
Active# show standby brief
P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Vl10 1 120 P Active local 30.30.30.4 30.30.30.1
Standby# show standby
Vlan10 - Group 1
State is Standby
13 state changes, last state change 00:04:17
Track object 1 (unknown)
Virtual IP address is 30.30.30.1
Active virtual MAC address is 0000.0c07.ac01 (MAC Not In Use)
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 200 msec, hold time 750 msec
Next hello sent in 0.064 secs
Preemption enabled, delay min 5 secs, reload 5 secs, sync 5 secs
Active router is 30.30.30.2, priority 120 (expires in 0.816 sec)
Standby router is local
Priority 100 (default 100)
Group name is "hsrp-Vl10-1" (default)
FLAGS: 0/1
Standby# show standby brief
P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Vl10 1 100 P Standby 30.30.30.2 local 30.30.30.1
Feedback