Who rated this post

Hi

Bond MAC Address:

As all bond slaves have to share the same MAC, one of the slaves has to be chosen as the MAC address for the bond.

in Scalable Platforms we choose the first added slave (as you already stated).

This decision is persistent (survives reboot) and the same for all members (to assure symmetry).

The only time it can change is when the first slave is removed.

The first index can be found in /config/active (1 is the bond id here):

[Expert@Maestro-ch01-01:0]# egrep "bonding:group:1:.*index" /config/active
bonding:group:1:port:eth1-11:index 1
bonding:group:1:port:eth1-12:index 2
bonding:group:1:port:eth1-10:index 3

As you can see in my case, eth1-11 is the first index, hence it's MAC address was chosen (0x0b = 11 decimal)

[Global] Maestro-ch01-01:0 > show interface bond1 mac-addr
1_01:
mac-addr 00:1c:7f:81:0b:df

2_01:

mac-addr 00:1c:7f:81:0b:df

MAC Addresses conflicts

The last 2 digits are based on the magic mac value:

[Global] DC_MXL_VSX-ch01-01:0 > fw ctl get int fwha_mac_magic
-*- 2 blades: 1_01 2_01 -*-
fwha_mac_magic = 223

Which by default, is derived from the last Mgmt port IP address:

[Global] DC_MXL_VSX-ch01-01:0 > show interface eth1-Mgmt1 ipv4-address
1_01:
ipv4-address 172.23.103.223/24

Which eventually results with the MAC address last 2 digits as df (0xDF = 223):

mac-addr 00:1c:7f:81:0b:df

Conclusions

Probably in your case the same broadcast domain was used for multiple subnets, so the last octet was overlapped (e.g a setup with IP address of 100.1.1.100/24, another one with 200.1.1.100/24, etc.).

You can modify the magic mac in order to overcome the collisions and have more MAC address uniqueness.

In Scalable Platforms, it has to be done by modifying the /etc/smodb.json file. Please refer to sk25977 - "Connecting multiple clusters to the same network segment (same VLAN, same switch)", refer to section "Change Source MAC Addresses - Gateway & VSX Mode - Gaia Scalable Platform R80.20SP, R80.30SP - Procedure".

Cheers