VRRP - Best practise

[Carl_Wallmark]

Hi, I have a customer that have 3 FortiGates, each fortigate have 3 VLANs on Port1. (same on all three) They want to use VRRP on all VLANs, each fortigate should be Master of one VLAN, and the other should be backups. They also want to use the vrdst function and link-monitor to detehttp://ct failure on the Internet beyond their network. What prioritys, adv-interval and start-timer should I use ? Should we use " fail-detect" with " detectserver" on the WAN port ? They need to detect if the WAN port is down or if the ping probe is down with Link-Monitor, if it occurs it should fail over to the backup which has the highest priority.

[Toshi_Esumi]

I came across your old post when I was looking for a similar answer that you were looking for 18 months ago. Then I tested some and figured out the behavior with 'vrdst' option. Apparently it's looking for the specific route in the routing table to decide VRRP master or backup.

So if you want to monitor WAN1 interface and trigger master->backup change in VRRP status, you just need to configure a vrdst with, let's say 8.8.8.8 that is a part of a route toward WAN1. The route can be a static default route, or a more specific route as long as it includes 8.8.8.8. Then when WAN1 goes down, the route disappears and VRRP status changes to BACKUP.

One gotcha is you can't use a monitoring IP in the subnet on the interface. That's at least we confirmed it didn't work. The bottom line is 'vrdst' doesn't ping the destination, it just monitors the route if it exist or not.

[Carl_Wallmark]

Hi,

Yes, this became a two stage rocket, and we eventually solved it, and we also found a nasty bug in VRRP.

Setup the VLANs and VRRP as you want them to be, then use monitoring IP and ping an IP address outside of your network, when the ping dies the it would set the interface to down and the route will disappear and the VRDST function would kick in, and the failover would occur.

The bug we found was that it wouldn´t go back when the ping started to work again, it was later solved by fortinet when we told support about it.