sk182488 - Traffic issues because of inconsistent MAC addresses on Maestro Security Group Members

Traffic issues because of inconsistent MAC addresses on Maestro Security Group Members

Product

Maestro HyperScale Firewall

Version

R80.20SP (EOS), R80.30SP (EOS), R81 (EOS), R81.10 (EOS), R81.20

OS

Gaia

Last Modified

2025-06-23

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 <Name of Bond 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 <Sync IP Address>" 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.

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]#

The bond mode was changed to "active-backup" in Gaia gClish:

set bonding group 14 mode active-backup

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]#

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 starting from Take 25
Jumbo Hotfix Accumulator for R81.20 starting from Take 99
Jumbo Hotfix Accumulator for R81.10 starting from Take 177

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, please collect CPinfo files from the Security Management Server and Security Gateways involved in the case.

Hotfix installation instructions:

Refer to sk168597 - How to install a Hotfix.

As an immediate workaround, follow these instructions:

Connect to the command line on the Security Group.
Collect the Gaia snapshot.
In the problematic Bond interface, remove the subordinate interface with Index 1:

delete bonding group <Number of Bond Interface> interface <Name of First Subordinate 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

In the problematic Bond interface, add the subordinate interface you removed in the previous step:

delete bonding group <Number of Bond Interface> interface <Name of Second Subordinate 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

Make sure the index numbers of subordinate interfaces in the Gaia database match the index numbers of subordinate interfaces in Linux database:
Go to the Expert mode.
Get the configuration in the Gaia database:

grep 'bonding:group:<Number of Bond Interface>' /config/active

In our example:

grep 'bonding:group:14' /config/active

Get the configuration in the Linux database:

cat /proc/net/bonding/bond<Number of Bond Interface>

In our example:

cat /proc/net/bonding/bond14

In our example, the subordinate interface eth1-14 must have Index 1 in both outputs.

Reboot the problematic Security Group Members:

reboot -b <SGM_ID>

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.