Connectivity issues may occur between Maestro Sites that are connected through Cisco OTV switches

Product: Maestro HyperScale Firewall
Version: R81.10 (EOS), R81.20, R82, R82.10
OS: Gaia
Last Modified: 2026-01-15

Symptoms

• Connectivity issues may occur between Maestro Sites that are connected through Cisco OTV (Overlay Transport Virtualization) switches.

Cause

Unlike regular Layer 2 networks, Cisco OTV drops unknown unicast packets instead of flooding them.

Maestro environment uses two separate Layer 2 networks (one network is for sync). Therefore, Cisco OTV endpoints may learn MAC addresses on only one of these Maestro networks. As a result, Cisco OTV endpoints drop the packets on the other Maestro network.

Solution

This problem was fixed. The fix is included in:

• Check Point Quantum R82.10
• Jumbo Hotfix Accumulator for R81.20 starting from Take 120

If you choose not to upgrade, Check Point can supply a Hotfix. Contact Check Point Support to get a Hotfix for this issue.

A Support Engineer will make sure the Hotfix is compatible with your environment before providing the Hotfix.

For faster resolution and verification, collect these files:

1. CPinfo file from the Management Server involved in the case.
2. CPinfo file from each Maestro Orchestrator involved in the case.
3. CPinfo file from each Security Group involved in the case.

Hotfix installation and configuration instructions for each Security Group:

1. Install the hotfix on the Security Group and reboot.

Refer to sk168597 - How to install a Hotfix.

2. Connect to the command line on the Security Group.

3. Log in.

4. If the default shell is Gaia gClish, then go to the Expert mode:

   expert

5. Add the required parameters to the Gaia OS database:

   1. gexec -b all -c 'dbset process:sync_keep_alive t'
   2. gexec -b all -c 'dbset process:sync_keep_alive:path /usr/bin'
   3. gexec -b all -c 'dbset process:sync_keep_alive:runlevel 4'
   4. gexec -b all -c 'dbset save'

6. Make sure the "process:sync_keep_alive" parameters were added to the Gaia OS database on all Security Group Members:

   gexec -b all -c 'cat /config/active | grep sync_keep_alive' | sort

7. Restart the "sync_keep_alive" process:

   1. tellpm process:sync_keep_alive
   2. tellpm process:sync_keep_alive t

8. Make sure the "/usr/bin/sync_keep_alive" process is running:

   ps aux | grep sync_keep_alive | grep -v grep

9. Make sure the Security Group Members are sending ARP requests for the Sync IP addresses 192.0.2.101 from each subordinate interface of the Sync interface (one ARP Request every 30 seconds):

   g_tcpdump -ennni eth1-Sync -Q out arp and '(host 192.0.2.101)'
g_tcpdump -ennni eth2-Sync -Q out arp and '(host 192.0.2.101)'

Note - To get the names of the Sync Subordinate Interfaces, run: grep "Slave Interface:" /proc/net/bonding/Sync | awk '{print $3}

NOTE

This solution has been verified for the specific scenario, described by the combination of Product, Version and Symptoms. It may not work in other scenarios.

Article Properties

Access Level: General
Status: Approved by TAC
Date Created: 2025-08-07
Last Modified: 2026-01-15