Recently I had a chance to conduct VRRP verification with YAMAHA's RTX830, and I thought I would share it with the world as a memorandum.
What is VRRP?
※ For those who are already familiar, feel free to skip this.
Let me explain!
VRRP (Virtual Router Redundancy Protocol) is a technology that makes routers redundant and makes two routers appear as if they are one from the local side.
VRRP does not use TCP or UDP, but protocol number 112. This allows for continuous communication even if one of the routers goes down due to a failure or other reasons. This is quite convenient.
Verification Environment
Two YAMAHA RTX830 routers were used for the setup.
â– Simplified Configuration Diagram
On the local PC (the girl’s PC in the above figure), only the VIP (virtual IP address) "192.168.100.1" is visible as the default gateway (In reality, the physical IPs "Master: 192.168.100.2" and "Backup: 192.168.100.3" can also be directly connected to.)
â– Note
The IP assigned to the WAN-side interface must be static.
L2 switches or equivalents are required both above and below.
Config
Here are all the basic settings regarding VRRP! ⇩
â– Main Side (RTX1)
ip lan1 vrrp 1 192.168.100.1 priority=200 #setup virtual IP; higher priority value takes precedence
ip lan1 vrrp shutdown trigger 1 lan2 #Interface designation for failure detection (lan2 is WAN)
ip lan1 address 192.168.100.2/24 #Actual addressÂ
â– Backup Side
ip lan1 vrrp 1 192.168.100.1 priority=100
ip lan1 vrrp shutdown trigger 1 lan2
ip lan1 address 192.168.100.3/24
â– For WAN-side alive monitoring
ip keepalive 10 icmp-echo 1 3 1.1.1.1    #IP placeholder Â
Verification Records
Here I did a simple test by sending a ping from the local PC to the Internet destination (192.168.10.1).
Verification 1 : Continuously Ping to VIP: 192.168.100.1 and Internet IP: 192.168.10.1 (Power off the master side during transmission)
Reply from 192.168.10.1: bytes=32 time=1ms TTL=63
Reply from 192.168.10.1: bytes=32 time=1ms TTL=63
Reply from 192.168.10.1: bytes=32 time=1ms TTL=63
Reply from 192.168.10.1: bytes=32 time=1ms TTL=63
Reply from 192.168.10.1: bytes=32 time=1ms TTL=63
Reply from 192.168.10.1: bytes=32 time=1ms TTL=63
Request timed out.
Reply from 192.168.10.1: bytes=32 time=1ms TTL=63
Reply from 192.168.10.1: bytes=32 time=1ms TTL=63
Reply from 192.168.10.1: bytes=32 time=1ms TTL=63
Â
Ping statistics for 192.168.10.1:
    Packets: Sent = 42, Received = 41, Lost = 1 (2% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 4ms, Average = 1ms
Â
Reply from 192.168.100.1: bytes=32 time=1ms TTL=255
Reply from 192.168.100.1: bytes=32 time=1ms TTL=255
Reply from 192.168.100.1: bytes=32 time=1ms TTL=255
Request timed out.
Reply from 192.168.100.1: bytes=32 time=1ms TTL=255
Reply from 192.168.100.1: bytes=32 time=1ms TTL=255
Â
Ping statistics for 192.168.10.1:
    Packets: Sent = 78, Received = 77, Lost = 1 (1% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 3ms, Average = 0ms
At line 7 ⇧, there was a timeout in the ping. Approximately 7 seconds later, communication to 192.168.10.1 was restored.
At the same time, at line 20, the virtual IP "192.168.100.1,"Â which is the default gateway, switched to the backup device, and ping responses were restored.
The loss was also significantly minimized.
Verification 2 : Internet Outage (physically disconnect WAN on the master side)
Reply from 192.168.10.1: bytes=32 time=1ms TTL=63
Request timed out.
Reply from 192.168.10.1: bytes=32 time=1ms TTL=63
→ It was confirmed that recovery was almost instantaneous.
→ The switch from master to backup was also performed immediately.Â
It looks good.
And it seems like it would come through even in case of an emergency.
Status Checking
During the verification, I used these commands to check the status of the switchover.
â– VRRP
show status vrrp
#Output example
show status vrrp
 LAN1 ID:1 Virtual IP address: 192.168.100.1
  Current master: 192.168.100.2 Priority: 200
     My state: Master / Priority: 200 Preempt Authentication: NONE Timer: 1
⇧The main side is operating as the master.
â– Interface and keepalive confirmation
show status lan2
show status ip keepalive
This blog post is translated from a blog post written by Kawai on our Japanese website Beyond Co..