gurfin / ENCOR #11 - NTP, FHRP and tracking

Created Sun, 23 Mar 2025 11:14:00 +0100 Modified Sun, 23 Mar 2025 13:31:26 +0000
1269 Words
ENCOR

This post will be covering some useful, but less heavy technologies, namely NTP and FHRP. These are essential to building a resilient and well functioning network.

It’s funny, every time I work with NTP I am reminded of when I took a certain exam. During one of the labs there was a need for configuring NTP on a router - simple enough, I though. I spent about 40% of the entire allotted exam time on trying to get NTP to synchronize - turns out, that everything was correctly configured and NTP was just slow… 🤦‍♂️

NTP

Network Time Protocol (NTP) aims to solve the issue with synchronizing clock times between networked devices. It uses the concept of stratum to signify how many hops a NTP server has to its “root NTP server”, which is usually outfitted with an atomic clock.

Configure NTP

On Cisco IOS XE 16.9.5 you would configure NTP as follows:

ntp source <mgmt-interface>
ntp server (vrf <vrf-source-definition>) <ntp-server-address>

Also, keep in mind that you may need to set the timezone correctly. You can read more about how to do that in this post.

To verify the NTP status use the following command. Also, note that synchronization can take around 15 minutes, so go grab a coffee.

cisco-router#show ntp status
Clock is synchronized, stratum 2, reference is 194.58.204.20
nominal freq is 250.0000 Hz, actual freq is 250.0050 Hz, precision is 2**10
ntp uptime is 1865830200 (1/100 of seconds), resolution is 4000
reference time is EB8A536E.E18939B8 (10:31:26.881 SWEDEN Sun Mar 23 2025)
clock offset is 0.1123 msec, root delay is 5.99 msec
root dispersion is 63.86 msec, peer dispersion is 1.11 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000020101 s/s
system poll interval is 1024, last update was 3577 sec ago.

It can be a good idea to configure multiple different NTP servers. This is to prevent a single point of failure, even though NTP pools are usually highly redundant. The Cisco device will select the device that has the lowest stratum, but you can also manually set the preferred server using the following configuration:

ntp server (vrf <vrf-definition>) <ntp-server-address> prefer

Peers in NTP

It is possible to configure NTP peers between two Cisco devices. This causes them to act as both servers and clients, allowing for redundancy in time synchronization should the external stratum servers fail.

FHRP

First Hop Redundancy Protocol (FHRP) allows for redundant hostnet gateways while still only configuring a single default gateway on the host devices. There are different implementations of the FHRP technology but the most common are:

  • Hot Standby Router Protocol (HSRP)
  • Virtual Router Redundancy Protocol (VRRP)
  • Gateway Load Balancing Protocol (GLBP)

Now, these are all quite similar to implement, but offer slightly different capabilities. HSRP and GLBP are both Cisco proprietary protocols, while VRRP is an open standard.

HSRP

HSRP is an Active/Standby protocol where you are able to have “share” an IP between two routers on the same network. This shared IP, commonly referred to as the Virtual IP (VIP) has a Virtual MAC-address assigned to it. This Virtual MAC-address is shared between both of the routers, however, it is only the active router which responds to ARP requests for the VIP.
HSRP does support both IPv4 and IPv6 VIPs.

HSRP diagram

This allows for the primary router to be the default gateway for that broadcast domain, while still allowing the secondary router to “take ownership” of the Virtual MAC and Virtual IP.

HSRP sends hello messages between the two routers to ensure that the neighbor is alive and well. The default interval, known as hello time, is 3 seconds.
Then, if the router does not receive a hello message within the set hold time, for which the default is 10 seconds, HSRP will consider the neighbor to be in a down state. The hold time must be at least 3 times the hello time.

By default, HSRP does not actively switch over to a neighbor with higher priority. However, you can induce this behavior by adding the preempt configuration to the standby group.

Here is an example configuration on IOS XE 16.9.5:

interface Vlan20
 ip address 10.100.20.2 255.255.255.0
 standby 1 ip 10.100.20.1
 standby 1 timers msec 250 msec 750
 standby 1 priority 150
 standby 1 preempt

VRRP

Now for the open standard we can use VRRP. VRRP is very similar to HSRP, however, there are some key differences.
VRRP comes in two versions: v2 and v3. Version 2 is now considered legacy and does not support IPv6, while version 3 does. To enable version 3 you have to enable version 3 on the router globally. This is done through the following command on IOS XE 16.9.5:

fhrp version vrrp v3

This is an example of how you configure VRRPv3:

fhrp version vrrp v3
interface Vlan30
 ip address 10.100.20.2 255.255.255.0
 vrrp 1 address-family ipv4
  timers advertise 250
  priority 150
  address 10.100.20.1
  exit-vrrp

GLBP

This protocol is very cool!
GLBP, unlike HSRP and VRRP, allows for load-balancing which router is the default gateway for hosts on a network, without setting different default gateways on each host. In GLBP, we work with two roles: Active Virtual Gateway (AVG) and Active Virtual Forwarder (AVF).

GLBP diagram

There can exist a single AVG in a GLBP group. This router will be responsible for responding to all ARP requests from the hosts. However, the AVG modifies the ARP requests based on which host sends out the request in order to point that given host to a specific AVF. The AVG also acts as an AVF.

There can exist up to 4 AVFs in a GLBP group. The task of the AVF is to simply forward traffic that is receives from the host network. AVFs are also ready to take over the AVG role, should the current AVG go down.

Tracking

Now, using a FHRP alone is great in case of failure between the LAN and the router, or if the router itself goes down. However, if the primary WAN connection is affected, then the FHRP would not properly switch over.

To solve this we can use tracking. This allows us to define something we want to monitor. There are quite a lot you can monitor using tracks, especially if you utilize IP SLAs, but we will only cover the basics how.

Using this tracking method allows us to monitor the weather or not the WAN interface has carrier. If the WAN interface goes down, we can then perform some sort of action. In the case for FHRP the action would be to decrement the priority. This would, in turn, cause the FHRP to failover, given that we have configured preempt.

track 10 interface gigabitEthernet 0/0/0 line-protocol
interface Vlan20
 ip address 10.100.20.2 255.255.255.0
 standby 1 ip 10.100.20.1
 standby 1 timers msec 250 msec 750
 standby 1 priority 150
 standby 1 preempt
 standby 1 track 10 decrement 100

Tracking route presence in the RIB

Another common simple method used for tracking, is to look for the presence of a specific route in the RIB. This allows you to verify, not only link state of the WAN interface, but that the routing going across the WAN interface is functional.
Of course, this is not bulletproof and there are ways in which we can improve this tracking. However, this, I would say, is the minimum required to setup a FHRP protocol correctly.

track 10 ip route 10.22.22.0/24 reachability
interface Vlan20
 ip address 10.100.20.2 255.255.255.0
 standby 1 ip 10.100.20.1
 standby 1 timers msec 250 msec 750
 standby 1 priority 150
 standby 1 preempt
 standby 1 track 10 decrement 100

That is all for now folks! :)