In a previous lesson I demonstrated how to troubleshoot a HSRP issue. This time we’ll troubleshoot VRRP. These two protocols have many similarities, if you can troubleshoot one then the other shouldn’t be a problem.
Let’s take a look, I will use the following topology:
The router on the left is our “client” device, R2 and R3 are configured for VRRP. The goal is to reach 4.4.4.4 from the client. Unfortunately, this is not working:
Client#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
U.!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 8/13/20 ms
Some of the IP packets are not arriving at 4.4.4.4. Let’s check what default gateway our client is using:
Client#show ip route
Default gateway is 192.168.123.254
Host Gateway Last Use Total Uses Interface
ICMP redirect cache is empty
IP routing has been disabled and the client is using gateway IP address 192.168.123.254. Let’s check if we can reach this address:
Client#ping 192.168.123.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.123.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/20 ms
Pinging the gateway address is no problem. Are our two VRRP routers able to reach 4.4.4.4 ? Let’s try that:
R2#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R3#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/20 ms
R2 is unable to reach 4.4.4.4 but R3 has no issues. Before we continue checking why R2 is unable to reach 4.4.4.4 we’ll take a look at the VRRP configuration to see which router is the master:
R2#show vrrp
FastEthernet0/0 - Group 1
State is Master
Virtual IP address is 192.168.123.254
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 100
Authentication MD5, key-string "WRONGPASS"
Master Router is 192.168.123.2 (local), priority is 100
Master Advertisement interval is 1.000 sec
Master Down interval is 3.609 sec
R3#show vrrp
FastEthernet0/0 - Group 1
State is Master
Virtual IP address is 192.168.123.254
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 100
Authentication MD5, key-string "SECRET"
Master Router is 192.168.123.3 (local), priority is 100
Master Advertisement interval is 1.000 sec
Master Down interval is 3.609 sec
The output of show vrrp is interesting. Both routers think they are active and if you look closely you can see why. Authentication has been enabled and there is a mismatch in the key-string. Since both routers are active half of the packets will end up at R2 and the rest at R3. This is why our client sees some packets arriving and others not. Let’s fix our authentication:
R2(config)#interface FastEthernet 0/0
R2(config-if)#vrrp 1 authentication md5 key-string SECRET
We’ll make sure the key-string is the same. Now you’ll see something on the console:
R2# %VRRP-6-STATECHANGE: Fa0/0 Grp 1 state Master -> Backup
This message on the console of R2 is promising. R3 has become the master:
R2#show vrrp | include Master
Master Router is 192.168.123.3, priority is 100
R3#show vrrp | include Master
State is Master
Master Router is 192.168.123.3 (local), priority is 100
R3 has been elected as the master router. Now let’s find out why R2 was unable to reach 4.4.4.4:
Hello Rene,
One quick Question if there is any mismatch in the authentication … in first place it should not forward packets at all ? we could see some packets are being forwarded … could you please explain.
Thanks
Shayan
Hi Shayan,
... Continue reading in our forumBelieve it or not, what you are seeing is expected behavior from VRRP! If the authentication is not correct from a VRRP neighbor, then its packets get ignored. Each side will claim the other has incorrect authentication, so each VRRP router believes itself to be the master, and each will claim to own the IP address! The only upside to this is that assuming each side is using the same VRRP instance number, the MAC address will agree between them, so other computers on the network would have no idea this is going on. Additionally, should one of the
Hello Andrew,
Thanks a lot for your detailed explanation on the vrrp authentication.
Regards!
Shayan
Let us assume authentication is proper & timers also. Suppose the VRRP keepalive messages are not able to reach each other due to any random reason, in that case both should be active & active.
So will they forward packets or not?
Hello Tejas
Yes, if that is the case, both devices will become active, and any packets arriving at a device will be forwarded. But, if for whatever reason the redundant gateways can’t reach each other, that means that hosts will also have trouble reaching one of the gateways for the same reason. Remember that redundant gateways and hosts are all on the same subnet. If communication between gateways somehow fails, then communication will also fail between hosts and one or more of the redundant gateways.
So in most cases, even if both gateways become active, t
... Continue reading in our forum