Troubleshooting Tip: Challenges with Setting vrip (VRRP) in the Same Subnet as Secondary IP

[riteshpv]

Description	This article addresses issues that arise when a Virtual IP (vrip) configured under VRRP shares the same subnet as the secondary IP.
Scope	FortiSwitch v7.2, v7.4.
Solution	Below is an example of the VRRP configuration on an SVI: config system interface     edit "test1"         set ip 10.201.133.253 255.255.254.0         set allowaccess ping         set vrrp-virtual-mac enable             config vrrp                 edit 12                     set priority 110                     set vrip 10.201.128.30                 next             end                 set secondary-IP enable                 set vlanid 10                 set interface "internal"                     config secondaryip                         edit 1                             set ip 10.201.128.29 255.255.255.224                             set allowaccess ping                         next                     end                 next             end In this configuration, the primary IP is 10.201.133.253/23. The VRRP virtual IP (vrip) 10.201.128.30 shares the same subnet as the secondary IP 10.201.128.29/27. Example Output for the above Configuration: TEST-FGT # diagnose ip address list | grep 10.201.128 IP=10.201.128.29->10.201.128.29/255.255.255.224 index=73 devname=test1 Flags: 0x80 IP=10.201.128.30->10.201.128.30/255.255.254.0 index=73 devname=test1 Flags: 0x80 TEST-FGT # diagnose ip route list | grep 10.201.128 tab=254 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.201.128.0/27 pref=10.201.128.29 gwy=0.0.0.0 dev=73(test1) tab=254 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.201.128.0/23 pref=10.201.128.30 gwy=0.0.0.0 dev=73(test1) <<<<<<<<<< tab=255 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.201.128.0/32 pref=10.201.128.29 gwy=0.0.0.0 dev=73(test1) tab=255 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.201.128.0/32 pref=10.201.128.30 gwy=0.0.0.0 dev=73(test1) tab=255 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.201.128.29/32 pref=10.201.128.29 gwy=0.0.0.0 dev=73(test1) tab=255 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.201.128.30/32 pref=10.201.128.30 gwy=0.0.0.0 dev=73(test1) tab=255 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.201.128.31/32 pref=10.201.128.29 gwy=0.0.0.0 dev=73(test1) tab=255 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.201.129.255/32 pref=10.201.128.30 gwy=0.0.0.0 dev=73(test1) The output shows a /27 subnet mask for 10.201.128.x. VRRP defaults to using the primary IP's subnet mask (/23), which can prevent a large range of IPs from being reused. When enabling VRRP on an SVI, it is recommended to set the primary IP as static and ensure the vrip shares the same subnet as the primary IP, rather than with the secondary IP. Solution 1: Swap Primary and Secondary IPs: If the vrip must share a subnet with the IP set on the secondary IP, swap the primary and secondary IPs, as shown in the following example: config system interface     edit "test1"         set ip 10.201.128.29 255.255.255.224         set allowaccess ping         set vrrp-virtual-mac enable             config vrrp                 edit 12                     set priority 110                     set vrip 10.201.128.30                 next             end                 set secondary-IP enable                 set vlanid 10                 set interface "internal"                     config secondaryip                         edit 1                             set ip 10.201.133.253 255.255.254.0                             set allowaccess ping                         next                     end                 next             end The modified output confirms the swap. i.e now the 10.201.128.x. use only /27. TEST-FGT # diagnose ip address list | grep 10.201.128 IP=10.201.128.29->10.201.128.29/255.255.255.224 index=74 devname=test1 Flags: 0x80 IP=10.201.128.30->10.201.128.30/255.255.255.224 index=74 devname=test1 Flags: 0x81 TEST-FGT # diagnose ip route list | grep 10.201.128 tab=254 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.201.128.0/27 pref=10.201.128.29 gwy=0.0.0.0 dev=74(test1) tab=255 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.201.128.0/32 pref=10.201.128.29 gwy=0.0.0.0 dev=74(test1) tab=255 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.201.128.29/32 pref=10.201.128.29 gwy=0.0.0.0 dev=74(test1) tab=255 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.201.128.30/32 pref=10.201.128.29 gwy=0.0.0.0 dev=74(test1) tab=255 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.201.128.31/32 pref=10.201.128.29 gwy=0.0.0.0 dev=74(test1) Solution 2: Change VRRP IP (vrip) to Match the Primary IP Subnet: If there is no requirement for vrip to share a subnet with the secondary IP, adjust vrip to match the primary IP’s subnet. config system interface     edit "test1"         set ip 10.201.133.253 255.255.254.0         set allowaccess ping         set vrrp-virtual-mac enable             config vrrp                 edit 12                     set priority 110                     set vrip 10.201.133.10                 next             end                 set secondary-IP enable                 set vlanid 10                 set interface "internal"                     config secondaryip                         edit 1                             set ip 10.201.128.29 255.255.255.224                             set allowaccess ping                         next                     end                 next             end Using either solution, configuring VRRP within a shared subnet is managed correctly, avoiding potential issues with IP ranges.