Troubleshooting VRRP

This section shows known issues with VRRP configurations and fixes. Read this section before contacting Check Point Support.

Traces for VRRP

You can log information about errors and events for troubleshooting VRRP. Enable traces (debug) for VRRP.

To enable traces for VRRP:

Step	Description
1	In the navigation tree, click Routing > Routing Options.
2	In the Trace Options section, in the Filter Visible Tables Below drop down list, select VRRP.
3	In the VRRP table, select the applicable options. We recommend you select All. To select several specific options: Press and hold the Ctrl key on the keyboard. Left-click on the applicable options. The selected options become highlighted. To select several consecutive options: Left-click on the first consecutive applicable option. Press and hold the Shift key on the keyboard. Left-click on the last consecutive applicable option. The selected options become highlighted.
4	Click Add. The selected options show Enabled.
5	Scroll to the top of this page.
6	In the Routing Options section, click Apply. The Gaia restarts the routing subsystem and signals it to reread its configuration. The debug information is saved in /var/log/routed.log* files and /var/log/routed_messages* files. Note - As an example, see sk84520 - How to debug OSPF and RouteD daemon on Gaia.

To disable traces for VRRP:

Step	Description
1	In the navigation tree, click Routing > Routing Options.
2	In the Trace Options section, in the Filter Visible Tables Below drop down list, select VRRP. In the VRRP table, select All.
3	Click Remove. The options do not show Enabled anymore.
4	Scroll to the top of this page.
5	In the Routing Options section, click Apply. The Gaia restarts the routing subsystem and signals it to reread its configuration.

General Configuration Considerations

If VRRP failover does not occur as expected, make sure that the configuration of these items.

All Security Gateways in a Virtual Router must have the same system times. The simplest method to synchronize times is to enable NTP on all Security Gateways of the Virtual Router. You can also manually change the time and time zone on each Security Gateway to match the other Security Gateways. It must be no more than seconds apart.
All routers of a Virtual Router must have the same VRRP Hello Interval.
The Priority Delta must be sufficiently large for the Effective Priority to be lower than the VRRP Master router. Otherwise, when you pull an interface for a Monitored-Circuit VRRP test, other interfaces do not release IP addresses.
Each unique Virtual Router ID must be configured with the same Backup Address on each Security Gateway.
The VRRP monitor in the Gaia Portal might show one of the interfaces in initialize state. This might suggest that the IP address used as the Backup Address on that interface is invalid or reserved.
An SNMP "Get" request on interfaces may list the incorrect IP addresses. This results in incorrect policy. An SNMP "Get" request fetches the lowest IP address for each interface. If interfaces are created when the Security Gateway is the VRRP Master, the incorrect IP address might be included. Repair this problem. Edit the interfaces by hand, if necessary.

Firewall Policies

Configure the Access policy to accept VRRP packets to and from the Gaia platform. The multicast destination assigned by the IANA for VRRP is 224.0.0.18. If the Access policy does not accept packets sent to 224.0.0.18, Security Gateways in one Virtual Router take on VRRP Master state.

Monitored-Circuit VRRP in Switched Environments

With Monitored-Circuit VRRP, some Ethernet switches might not recognize the VRRP MAC address after a change from VRRP Master to VRRP Backup. This is because many switches cache the MAC address related to the Ethernet device attached to a port. When failover to a VRRP Backup router occurs, the Virtual Router MAC address becomes associated with a different switch port. Switches that cache the MAC address might not change the associated cached MAC address to the new port during a VRRP change.

To repair this problem, you can take one of these actions:

Replace the switch with a hub.
Disable MAC address caching on the switch, or switch ports, to which the VRRP cluster members are connected.
It might be not possible to disable the MAC address caching. If so, set the address aging value sufficiently low that the MAC addresses age out after a one second or two seconds. This causes more overhead on the switch. Therefore, find out if this is a viable option for your switch model.

The Spanning Tree Protocol (STP) prevents Layer 2 loops across multiple bridges. Spanning-Tree can be enabled on the ports connected to the two sides of a VRRP cluster. It can also "see" multicast VRRP Hello packets coming for the same MAC address on two different ports. When the two occur, it can suggest a loop, and the switch blocks traffic on one port. If a port is blocked, the VRRP cluster members cannot get VRRP Hello packets from each other. As a result, both VRRP cluster members enter the VRRP Master state.

If possible, turn off Spanning-Tree on the switch to resolve this issue. However, this can have harmful effects, if the switch is involved in a bridging loop. If you cannot disable Spanning-Tree, enable PortFast on the ports connected to the VRRP cluster members. PortFast causes a port to enter the Spanning-Tree forwarding state immediately, by passing the listening and learning states.