This article describes steps to troubleshoot VRRP split brain, where both master node and slave node shows as 'Master'. Given the VRRP configuration on both sides of the FortiGates are legitimate.
|Scope||FortiGate, all firmware|
In normal working condition the slave receives keep alive messages from the master and it takes the master role when it stops receiving keep alive messages from the previous master.
VRRP split brain scenario, where both master node and slave node shows as up 'Master' happens when there’s a communication problem happens between the two peers.
Following is an example case scenario of this problem:
JSY-ESP-VG-FG01(Master) 172.28.10.252---------VRRP------ 172.28.10.253 (Slave)VG-LFO-FG01
Slave node will stay as master unless it receives announcement from master node with a higher priority.
So, to see if proper communication is established on both sides, user must see if the multicast IP address of the other is seen by running the following sniffer on both FortiGates.
# diag sniffer packet any 'proto 112' 4 0 l
In both outputs, Master and Slave is communicating with Multicast address In the first packet.
In such case first check the configuration part on both sides as per the following document.
In this case both the capture and configuration look’s fine.
But still, Slave FortiGate (172.28.10.253) shows up as ‘Master’
In such exceptional case, there are high chances that 'Local in' policy is in place set to 'deny' action as in this case shown below.
# Config firewall local-in-policy
set uuid c20af8ea-fd36-51ec-d21e-65dc42ed530d
set intf "any"
set srcaddr "all" -----> set to deny all access
set dstaddr "all"
set service "ALL"
set schedule "always"
'all' also includes multicast address.
If this Local in policy is a requirement for remote management, etc
Create a service for VRRP as shown below,
Once it is created the issue will be resolved and the secondary will show as Slave moving forward.
Local in policy needs a check only when VRRP on both sides of FortiGates are configured properly.