# 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](https://support.checkpoint.com/results/sk/sk183506)  
- [Jumbo Hotfix Accumulator for R81.20](https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.20/Default.htm) starting from Take 120

If you choose not to upgrade, Check Point can supply a **Hotfix**. [Contact Check Point Support](https://www.checkpoint.com/support-services/.contact-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](https://support.checkpoint.com/results/sk/sk92739) file from the Management Server involved in the case.
2. [CPinfo](https://support.checkpoint.com/results/sk/sk92739) file from each Maestro Orchestrator involved in the case.
3. [CPinfo](https://support.checkpoint.com/results/sk/sk92739) 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](https://support.checkpoint.com/results/sk/sk168597).

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