In networking, I have a lot of respect for having to make “less-than-ideal” design decisions due to external requirements. This usually is because of budget or regulatory constraints, preventing the best technical solution from being implemented.
However, there is one design decision that I have a very hard time respecting: using FHRP in transit networks.
FHRP protocols such as HSRP, VRRP and GLBP are great and useful pieces of technology that, when correctly implemented, can provide great redundancy for host networks. A host network is a network segment, usually Ethernet, connecting one or more hosts to the network. In situations where redundancy is required, you will usually want these host networks (hostnets) to have redundant gateways, so that in the event of a failure, the network can recover and use the secondary gateway. In these situations, a FHRP protocol can be very useful, allowing the hosts to failover to the secondary gateway without needing to update the default route on all hosts in the hostnet.
This, is what the FHRP protocols were designed for - redundancy in hostnets.
I do see however, many environments using a FHRP protocol for failover between ’transit nodes’ (by this I am referring to network devices that packets are traversing on their path from source to destination). Using FHRP for transit networks is not what the technology was intended for.
Let me show an example:
In stead of using FHRP in you transit networks you should use a dynamic routing protocol, like OSPF, BGP, IS-IS, or EIGRP. These allow for more ‘accurate’ failover, and if setup properly, extremely fast failover. The example diagram above shows how a L3 link failure (linkstate is still up/up on R1) can cause asymmetric routing where the transit link between R1 and the other routers is down. I have seen this cause issues multiple times in production networks.
There are a few situations where you may want to consider using this method anyway. Firewalls is one of those situations, especially if it is a customer firewall. Since firewalls usually mark the ’edge’ of a network and therefore perform various NAT/PAT operations, the public facing interface of a firewall can be seen as a host in a hostnet. This would then allow us, as the internet service provider in this scenario, to use FHRP on the gateway side of the public firewall network. In order to setup FHRP with as few problems as possible, we should ensure that we implement the following steps:
- Setup IP SLA and priority decrementing on the FHRP peering.
- Setup route-withdrawl based on IP SLA monitoring downstream reachability.
- Configure FHRP authentication.
- Consider setting up BFD for sub second failover.
This is one of the first steps. This prevent the active gateway from remaining active is upstream reachability is lost. Here is how you can implement it on a Cisco router:
! Setup the IP SLA and tracking
ip sla 10
icmp-echo 1.1.1.1 source-interface gi0/1
frequency 5
ip sla schedule 10 start now life forever
track 10 ip sla 10
! Configure the interface for FHRP through HSRP.
interface GigabitEthernet0/0
ip addr 77.80.129.12 255.255.255.0
standby 10 authentication md5 key-string yeet
standby 10 ip 77.80.129.11
standby 10 priority 250
standby 10 preempt
standby 10 track 10 decrement 50
standby bfd
bfd interval 50 min_rx 50 multiplier 5
interface GigabitEthernet0/1
ip address 10.99.19.1 255.255.255.0
! Create prefix list and route-map used for route-withdrawl filtering
ip prefix-list HSRP_ROUTE_WITHDRAWL_PREFIX permit 77.80.129.0/24
route-map HSRP_ROUTE_WITHDRAWL permit 10
match track 10
match ip address prefix-list HSRP_ROUTE_WITHDRAWL_PREFIX
route-map HSRP_ROUTE_WITHDRAWL deny 20
match ip address prefix-list HSRP_ROUTE_WITHDRAWL_PREFIX
route-map HSRP_ROUTE_WITHDRAWL permit 10000
! Upstream internet peering.
router bgp 1
bgp log-neighbor-changes
network 77.80.129.0 mask 255.255.255.0
neighbor 10.99.19.99 remote-as 99
neighbor 10.99.19.99 route-map HSRP_ROUTE_WITHDRAWL out
The above configuration is an example of the primary router configuration. I assume you are familiar with the configuration and so I will not provide a complete example.
I hope that I can at least plant some extra guard rails and warning in your brain using this article, for when you are considering deploying FHRP on transit networks.
Just make sure that you understand all the implications of FHRP on transit networks before you choose to pull the trigger.
Sincerely, a FHRP-transit hater