HSRP is one of the most know FHRP (Fisrt Hop Routing) protocols proposed by Cisco to help secure (in terms of redundancy) the gateway (for hosts or servers) in a LAN. The objective is simple: configure one gateway address and provision as many real routers (gateways) to serve it.
To understand how it works let’s first read the RFC and write down all information that may hint on how HSRP handle IP traffic. We’ll try next to check our understanding of the RFC by setting up a lab and test those features. This understanding is crucial if we want troubleshoot efficiently its normal operation.
A walk by the RFC 2281
What does RFC 2281 says about Cisco HSRP that may affect the IP traffic flow process?
- A single router elected from the group is responsible for forwarding the packets that hosts send to the virtual router. Thus no effective loadbalacing!
- In the event that the active router fails, the standby assumes the packet forwarding duties of the active router.
- Although an arbitrary number of routers may run HSRP, only the active router forwards the packets sent to the virtual router.
- For each standby group, a single well-known (for HSRP usage) MAC address is allocated to the group, as well as an IP address (not physical?).
- The following information MUST be known to each router in the standby group : Standby group number, Virtual MAC address, Priority, Authentication Data, Hellotime, Holdtime (The mechanisms used to determine this information are outside of the scope of this document (RFC)).
- Send Gratuitous APR Message: The router broadcasts an ARP response packet advertising the group’s virtual IP address and virtual MAC address. The packet is sent using the virtual MAC address as the source MAC address in the link layer header, as well as within the ARP packet.
- Routers which implement HSRP SHOULD use well-known HSRP MAC addresses as the group’s virtual MAC address whenever possible.
- The active router MUST accept and forward traffic that is destined for the group’s virtual MAC address.
- It MUST stop accepting or forwarding such traffic when the router leaves the Active state.
- If and only if the router is in the Active state, the router MUST use the group’s virtual MAC address as the source MAC address for its Hello messages.
- As noted, routers currently emulating a virtual router adopt their group’s MAC and IP addresses.
- MAC addresses are typically provided in an address filter or ‘list’ of MAC addresses in a router’s interface controller.
- It is desirable for routers to be able to add one or more virtual MAC addresses to their controllers’ MAC address filter while maintaining their primary MAC addresses.
- In these cases (address filtering for only on unicast MAC address), such routers can still implement HSRP, but the protocol must change the interface’s primary MAC address when assuming or relinquishing control as the active router.
- Thus, routers participating in HSRP on an interface MUST NOT send ICMP redirects on that interface.
Lab setup… to show the least accurate case!
Let us analyze the IP traffic forwarding process in our lab setup (physical topology):
The logical topology is presented in the next figure. You may notice that the logical topology shows two redundant (independent) paths whereas the physical, only one!
Our test is simple: PC-1 @ip:192.168.1.1 tries to reach PC-2 @ip:192.168.2.1. In our network design, PC-1 have three possibilities:
- Forward traffic to Rtr-1,
- Rtr-2,
- or virtual router (FHRP-HSRP implemented by Rtr-1 and 2 in the subnet facing Pc-1)
What would be the most accurate gateway configuration? in those cases?
| Configured gateway | Rtr-1 | Rtr-2 | Virtual Rtr |
|---|---|---|---|
| Rtr-1 fails | Ko, Rtr1 fails | Ko, because no alternate path | Ko, because no alternate path |
| Rtr-1 Link1 fails at L3 | Ko | Ok, via link1 and link 2 | Ok, Rtr-2 active |
| Rtr-1 Link1 fails at L2 | Ko | Ko, because no alternate path | Ko, because no alternate path |
| Rtr-1 or Rtr-2 Link2 fails at L2 | Ok, via link1 | Ko, because no alternate path | Ok, Rtr-1 active |
Even in such bad design (physical topology), the virtual router as a gateway, is the most accurate configuration.
The HSRP Active Router,
On the active router, what are the changes after the new HSRP configuration? New ip aliases (dynamic) are added to the ip aliases tables, new arp entries (not aging) are added to the arp table, but the structure of the svi interface has not changed! Or at least the change is invisible…
The new alias enables the router to respond to ARP requests destined for the virtual ip addresses.
An entry that matches the standby group virtual ip address to the virtual mac address and interface is installed in the arp table. This output shows also that both the primary and virtual mac addresses are attached to the vlan123 interface.
From which structure does the arp table gather this information? The interface controller as it was described in the RFC ? Another structure? We first check the output of sh inter controller and sh controller commands
The sh inter controller and sh controller, commands shows only the physical interfaces information: idb, hw and software addr filters, etc. it is hard to see any hint on where are stored and used the virtual mac address information.
By checking the internal hsrp information, the output hints on an “HSRP MAC Address Table”
In the “HSRP MAC Address Table” the virtual mac address, it tied to the SVI interface. Is this table, a part of the usual MAC Address Table? I suppose that the active router uses this table in the same way as the usual mac address table when looking up L2 destinations and forwarding but exclusively for the HSRP operation (to not poison the regular MAC address).
A step-by-step analysis together with the information from the RFC
Based on the RFC comments and show command let us describe a packet forwarding from the source host to the destination host, step-by-step:
- PC-1’s gateway is the @ip of the virtual router
- PC-1 sends a packet to PC-2 reachable via its gateway
- To complete L2 encapsulation information it sends an ARP for the @ip of the vr requesting its mac (or use the gratuitous ARP the router becoming the active router)
- ARP broadcast request reaches the active router : Rtr-1
- The active router check its ARP table and find the @mac of the vr (the ip aliasing populated the ARP table and enabled the router to respond to ARP requests)
- The active router Rtr-1 sends an ARP reply back to the PC-1
- PC-1 L2 encapsulate the packet and sends it to the active router Rtr-1
- Because Rtr-1, the active router, sends hellos using its virtual mac address as source, all switches on the path optimize the forwarding of PC-1 packet towards Rtr-1
- The packet reaches the active router
- The active router for the standby group checks the forwarding table that we suppose include the HSRP MAC Address table.
- In the HSRP MAC Address Table the allhsrp mac is tight to SVI 123 which is a local destination
- Because the router is the active router in the corresponding standby group, the packet has reached its final L2 destination and is L3 processed next.
- The active router finds an OSPF route to the destination and forwards the packet using its output interface L2 information (not the vlan213 virtual mac address) to the next hop.
Yet more details
The HSRP elected active router sends hello packets using its virtual mac to the ALL Routers multicast group:
The full hello packet sent by the active router shows the source mac address is the All-HSRP-routers mac address:
A comparison between HSRP internal status in both routers active and passive.
Both routers have the same HSRP MAC Address Table and group information. But only the passive router maintains a state for the active router (ACTIVE_TIMERS)
Upon handling the virtual router role, the active router sends a gratuitous arp with its virtual ip address
The hello packet that is sent by the backup has as source address its primary mac address.
The fact that the active router uses the virtual mac address as source address in its hello packet let’s suppose that this mac address is tight to the structure of the svi or that another process crafts the packet (not using the interface information) and just forwarded through the svi.
Let’s suppose that the virtual mac address information is tight to the svi interface structure, it means that this mac address is reserved and added to the controller’s address list if the router is active. If the router is not active, then passive, this address is not added to the controller interface.
Then what happens then if I try to change the svi mac address on the backup router? In my setup?
The router accepts this configuration!
The standby router starts dropping the hello packet from the active router seeing its own mac address in the frame source and at the same time, it handles the active state.
Now in my network I have two routers with the same ip and mac address!
If the virtual mac address is not tight to the structure of the interface controller the only possibility is that the incoming packets are matched against the hsrp mac address table and that the outgoing packets (other than control or management hsrp packets) uses the primary mac address.
I ping from PC-1 to the virtual @ip of the active router Rtr-1. The captured reply packet shows that the response is sourced from the primary mac address not the virtual mac address.
In conclusion,
HSRP is about accepting and forwarding packets that have the virtual router MAC address as the destination.
In our lab setup, only the active router adds an entry of the virtual IP address in its ARP table (IP and MAC) and its IP alias table, which enables it to respond to ARP requests.
Incoming packet forwarding (from PC-1) would rely on an “hsrp mac address” table that is a part of actual mac address table or equivalent.
It is hard to see how this implementation conforms to the RFC saying that: “MAC addresses are typically provided in an address filter or ‘list’ of MAC addresses in a router’s interface controller.”
Outgoing packet forwarding (towards PC-1) uses the interface primary address information and not the virtual mac-address.
This reinforces the point that the virtual mac address is not added to the interface controller’s address filter, in this implementation!
