> Source: [sk182488](https://support.checkpoint.com/results/sk/sk182488) # sk182488 - Traffic issues because of inconsistent MAC addresses on Maestro Security Group Members | Property | Value | |----------|-------| | Solution ID | sk182488 | | Date Created | 2024-07-10 | | Last Modified | 2025-06-23 | | Technical Level | General | | Products | Scalable Platforms | | Versions | R81.20, R81.10 (EOS) | | OS | Gaia | ## Symptoms - * The output of the "`asg diag`" command on the Security Group shows that the "`MAC Setting`" test fails with "`Inconsistent MAC Addresses between SGMs`". Example: ``` -------------------------------------------------------------------------------- | Networking | -------------------------------------------------------------------------------- | 19 | MAC Setting | Failed (!) | (1)Inconsistent MAC Addresses between | | | | | SGMs | ``` * The output of the "`mac_verifier`" command on the Security Group shows "`MAC address inconsistency found on interface (difference between SGMs)`". Example for bond14 created on eth1-14 and eth2-14: ``` Verifying MAC address on local chassis (Chassis 1)... ... ... MAC address inconsistency found on interface bond14 (difference between SGMs) -*- 4 blades: 1_01 1_02 1_03 1_05 -*- bond14 00:XX:XX:81:XX:XX -*- 1 blade: 1_06 -*- bond14 00:XX:XX:82:XX:XX ... ... MAC address inconsistency found on interface eth1-14 (difference between SGMs) -*- 4 blades: 1_01 1_02 1_03 1_05 -*- eth1-14 00:XX:XX:81:XX:XX -*- 1 blade: 1_06 -*- eth1-14 00:XX:XX:82:XX:XX MAC address inconsistency found on interface eth2-14 (difference between SGMs) -*- 4 blades: 1_01 1_02 1_03 1_05 -*- eth2-14 00:XX:XX:81:XX:XX -*- 1 blade: 1_06 -*- eth2-14 00:XX:XX:82:XX:XX ... ... Failed ``` * Running the command "`cpha_blade_config pull_config all `" does not solve the problem. * Rebooting the Security Group Members does not solve the problem. ## Cause The MAC Address of the Bond interface is determined by the MAC address of the first subordinate interface that was added to this Bond interface. When you change the Bond interface mode (for example, from LACP to Active-Backup), then the Linux kernel rebuilds the Bond configuration, which may change the order of subordinate interfaces, but in the Gaia OS database, the order of subordinate interfaces does not change. Example: Show / Hide this section 1. The original configuration of the Bond interface "bond14" was: * 8023AD (LACP) mode * eth2-14 was the first added subordinate interface with the MAC address 00:XX:XX:82:XX:XX * eth1-14 was the second added subordinate interface with the MAC address 00:XX:XX:81:XX:XX * The output of the "`grep 'bonding:group:14' /config/active`" command in the Expert mode showed that the first subordinate interface is eth2-14: > ``` > bonding:group:14 t > bonding:group:14:primary eth1-14 > bonding:group:14:port:eth2-14 t > bonding:group:14:port:eth2-14:index 1 > bonding:group:14:port:eth1-14 t > bonding:group:14:port:eth1-14:index 2 > ``` * The output of the "`cat /proc/net/bonding/bond14`" command in the Expert mode showed that the first subordinate interface is eth2-14: > ``` > [Expert@MyGaia:0]# cat /proc/net/bonding/bond14 > Ethernet Channel Bonding Driver: v3.2.4 (January 28, 2008) > > Bonding Mode: IEEE 802.3ad Dynamic link aggregation > Transmit Hash Policy: layer2 (0) > MII Status: up > MII Polling Interval (ms): 100 > Up Delay (ms): 200 > Down Delay (ms): 200 > > 802.3ad info > LACP rate: slow > > Slave Interface: eth2-14 > MII Status: up > Link Failure Count: 0 > Permanent HW addr: 00:XX:XX:82:XX:XX > Aggregator ID: 1 > > Slave Interface: eth1-14 > MII Status: up > Link Failure Count: 0 > Permanent HW addr: 00:XX:XX:81:XX:XX > Aggregator ID: 1 > [Expert@MyGaia:0]# > ``` 2. The bond mode was changed to "active-backup" in Gaia gClish: `set bonding group 14 mode active-backup` 3. The output of the "`cat /proc/net/bonding/bond14`" command in the Expert mode showed that the first subordinate interface is now eth1-14: > ``` > [Expert@MyGaia:0]# cat /proc/net/bonding/bond14 > Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) > > Bonding Mode: fault-tolerance (active-backup) > Primary Slave: eth1-14 (primary_reselect always) > Currently Active Slave: eth1-14 > MII Status: up > MII Polling Interval (ms): 100 > Up Delay (ms): 200 > Down Delay (ms): 200 > > Slave Interface: eth1-14 > MII Status: up > Speed: 10000 Mbps > Duplex: Full > Link Failure Count: 0 > Permanent HW addr: 00:XX:XX:81:XX:XX > Slave queue ID: 0 > > Slave Interface: eth2-14 > MII Status: up > Speed: 10000 Mbps > Duplex: Full > Link Failure Count: 0 > Permanent HW addr: 00:XX:XX:82:XX:XX > Slave queue ID: 0 > [Expert@MyGaia:0]# > ``` 4. The output of the "`grep 'bonding:group:14' /config/active`" command in the Expert mode showed that the first subordinate interface is still eth2-14 - the Gaia database was **not** updated: > ``` > bonding:group:14 t > bonding:group:14:primary eth1-14 > bonding:group:14:port:eth2-14 t > bonding:group:14:port:eth2-14:index 1 > bonding:group:14:port:eth1-14 t > bonding:group:14:port:eth1-14:index 2 > bonding:group:14:mode active_backup > bonding:group:14:lacp_rate slow > bonding:group:14:xmit_hash_policy layer2 > bonding:group:14:mii_interval 100 > bonding:group:14:up_delay 200 > bonding:group:14:down_delay 200 > ``` ## Solution This problem was fixed. The fix is included in: * [Jumbo Hotfix Accumulator for R82](https://sc1.checkpoint.com/documents/Jumbo_HFA/R82/Default.htm) starting from Take 25 * [Jumbo Hotfix Accumulator for R81.20](https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.20/Default.htm) starting from Take 99 * [Jumbo Hotfix Accumulator for R81.10](https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.10/Default.htm) starting from Take 177 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://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk168597). As an immediate **workaround** , follow these instructions: 1. Connect to the command line on the Security Group. 2. Collect the Gaia snapshot. 3. In the problematic Bond interface, remove the subordinate interface with Index 1: `delete bonding group interface ` This forces the second subordinate interface to change its Index from Index 2 to Index 1 in the Gaia database. In our example - remove "eth2-14" from the bonding group 14: `delete bonding group 14 interface eth2-14` 4. In the problematic Bond interface, add the subordinate interface you removed in the previous step: `delete bonding group interface ` This adds the second subordinate interface with Index 2 in the Gaia database. In our example - add "eth2-14" to the bonding group 14: `add bonding group 14 interface eth2-14` 5. Make sure the index numbers of subordinate interfaces in the Gaia database match the index numbers of subordinate interfaces in Linux database: 1. Go to the Expert mode. 2. Get the configuration in the Gaia database: `grep 'bonding:group:' /config/active` In our example: `grep 'bonding:group:14' /config/active` 3. Get the configuration in the Linux database: `cat /proc/net/bonding/bond` In our example: `cat /proc/net/bonding/bond14` In our example, the subordinate interface **eth1-14** must have **Index 1** in both outputs. 6. Reboot the problematic Security Group Members: `reboot -b ` --- # Agent Instructions This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products. ## Navigating This Knowledge Base - **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt) - **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml) - **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}` - **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content