Troubleshooting VRRP

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:

Forum Replies

javeedz says:

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
andrew says:

Hi Shayan,
Believe 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
... Continue reading in our forum
javeedz says:

Hello Andrew,

Thanks a lot for your detailed explanation on the vrrp authentication.

Regards!
Shayan
Networkteam says:

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?
lagapidis says:

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

Ask a question or join the discussion by visiting our Community Forum

We're Sorry, Full Content Access is for Members Only...

Forum Replies