# Connectivity issues between Security Group members in a Maestro Dual-Site configuration with a non-direct site-sync connection **Product**: Maestro HyperScale Firewall **Version**: R81.20, R82, R82.10 **OS**: Gaia **Platform**: Maestro Orchestrator **Last Modified**: 2026-07-23 ## Symptoms - In a Maestro Dual-Site configuration with a non-directly connected site-sync connection, a link within the site-sync path fails. - Security Group Members (SGMs) in different sites experience intermittent connectivity loss. ## Cause > Consider a Maestro Dual-Site deployment where the Site-Sync connection between the two sites through intermediate Layer-2 switches (see [sk168092](https://support.checkpoint.com/results/sk/sk168092)). > SGM 1 > > MHO 1\_1 > > MHO 2\_1 > > MHO 1\_2 > > MHO 2\_2 > > Sync-ext > > Sync-int > > Sync-ext > > Sync-int > > Sync-ext > > Sync-ext > > Sync-int > > Sync-int > > Switch 3 > > Switch 4 > > SGM 2 > > Switch 1 > > Switch 2 > > If the connection between the switches goes down, then the Sync-ext interfaces continue to report that the link is up, but the actual path between remote peers is broken. For example, if the link between Switch 3 and Switch 4 fails, MHOs 1\_2, 2\_2 do not detect it. > > SGM 1 > > MHO 1\_1 > > MHO 2\_1 > > MHO 1\_2 > > MHO 2\_2 > > Sync-ext > > Sync-int > > Sync-ext > > Sync-int > > Sync-ext > > Sync-ext > > Sync-int > > Sync-int > > Switch 3 > > Switch 4 > > SGM 2 > > Switch 1 > > Switch 2 > > Would this link fail: > > Sync-ext on 1\_2, 2\_2 will be seen as _up_ > > In the scenario above, the entire deployment is not able to use the faulty link but continues to try to use it as if it were valid. ## Solution > This problem was fixed. The fix is included in: > > - [Jumbo Hotfix Accumulator for R82.10](https://sc1.checkpoint.com/documents/Jumbo_HFA/R82.10/Default.htm) starting from Take 36 > > 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, please collect [CPinfo files](http://supportcontent.checkpoint.com/solutions?id=sk92739) from the Security Management Server and Security Gateways involved in the case. > **Hotfix installation instructions:** > Refer to [sk168597 - How to install a Hotfix](https://support.checkpoint.com/results/sk/sk168597). > > ### **How Site-Sync Monitoring mitigates the issue** > > Each MHO runs the `SSM_PMD` daemon, which performs two checks: > > - **Physical Link Monitoring** > > Detects Link Aggregation Group (LAG) or interface link-down events on the Site-Sync interface > - **Connectivity Verification (Ping Test)** > > When Site-Sync Monitoring is enabled, the daemon periodically sends Internet Control Message Protocol (ICMP) pings to the remote Maestro Hyperscale Orchestrator (MHO) through the Site-Sync interface. > > If the ping test fails to meet the configured success threshold: > > - The link is treated as down, even if the physical interface reports link-up. > - This prevents the system from using a broken site-sync path. > > ### **Enable Site-Sync Monitoring** > > Enable Site-Sync Monitoring on (MHOs that do not have a direct Site-Sync connection (typically the “parallel” MHOs): > `set maestro configuration security-appliances inter-site monitor state enabled` > Note - Enabling this on one MHO automatically enables it on the corresponding parallel MHO in the other site. For example, enabling it on MHO 1\_2 also enables it on MHO 2\_2, ensuring symmetrical monitoring. > > ### **Clish Parameters** > > In the Clish configuration, aside from `state`, you can change the following ping settings. The system uses these parameters to determine link health. If the number of successful pings falls below the configured threshold, the link is marked as unreachable. > > | | | | > | --- | --- | --- | > | **Parameter** | **Description** | **Default** | > | `ping-timeout` | Timeout (in seconds) to wait for each ping reply | 1 | > | `ping-count` | Number of ping packets sent over the Sync-ext interface during each check | 2 | > | `successful-pings-required` | Minimum number of successful pings (from `ping-count`) required for the link to be considered active | 1 | > > ### Logger Settings > > | | | | > | --- | --- | --- | > | **Parameter** | **Description** | **Default** | > | `interval-length-for-flapping` | Time (in minutes) during which link state changes are counted. | 2 | > | `max-flaps` | Maximum number of link state changes allowed in the interval before the link is considered to be flapping | 3 | > | `log-timeout-if-flapping` | Time (in minutes) to suppress repetitive log messages after flapping is detected | 30 | > > To prevent excessive logging: when the system detects excessive state changes, and considers the link as flapping (exceeds the value of `max_flaps`) in the specified interval, then the system: > > 1. Logs a single warning in `/var/log/messages` > 2. Suppresses further logs for the duration defined in `log_timeout_if_flapping_min`. > > ### FAQs > > - How do I check if the link between the MHOs went down due to Site-Sync Monitoring? > > > Examine the `/var/log/maestro.log` for ping-failure entries (example below): > > `Nov 30 11:47:33 2025 MHO_1_2 ssm_pmd: site_sync_monitoring_ping_check:254: Site-Sync ping to 2_2 via Sync-ext interface failed (0/2 successful pings; 1/3 flaps)` > - How do I check if the link is flapping? > > > A flapping condition generates a warning in `/var/log/messages` (example below): > > `Nov 30 13:33:17 2025 MHO_1_2 ssm_pmd: site_sync_monitoring_ping_check:261: Site-Sync link is flapping: 3 flaps exceed threshold (3) within 2 minutes. Suppressing further flap logs for 30 minutes.` > - What is the current state of the Site-sync interface? > > > Check the current link status: > > `cat /etc/ports_link.json | grep sync -A 1` > > If the interface appears down, either the physical link is down or the connectivity check (ping test) failed. #### 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.