RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:
when admin defines bridged interface without any HWADDR defined and slaves plugged in, the bridge mac address often changes during the runtime without admin being involved. One of possible explanations is that initscripts don't persist the mac address of the device, so when physical device is plugged into the bridge, the bridge changes its address to physical address one.

Version-Release number of selected component (if applicable):
initscripts-9.03.38-1.el6.x86_64

How reproducible:
not sure about exact reproducer but this should do based on my research:

Steps to Reproduce:
0. service network stop
1. define ifcfg-br0 file and make sure that no ifcfg-IFACE file refers to it. ifcfg-br0 example:
DEVICE=br0
TYPE=Bridge
BOOTPROTO=none
ONBOOT=yes
DELAY=0
STP=off

2. service network start; note br0 mac address
3. plug physical interface to the bridge
4. note br0 mac address again
  
Actual results:
addresses should differ based on my understanding

Expected results:
addresses are the same

Additional info:
The reproducer and root cause may be different, this is a best-effort guess of what can be wrong.

Hi,

This is expected behaviour of bridges. They always use the lowest MAC address of all enslaved interfaces. There are few ways how to force the bridge not to change the MAC address. You can find them in these articles:

http://backreference.org/2010/07/28/linux-bridge-mac-addresses-and-dynamic-ports/
http://blog.tinola.com/?e=4

The problem is that bridge is identified by HWADDR= if present so if bridge mac address is changed during runtime, network-scripts may get confused. This may be somehow connected to behaviour I observed in bug 902900 that you can't reproduce with stripped-down "reproducer".

Sure, it may eventually in specific case lead in some problems. But it is the expected behaviour of the bridge. Initscripts do not set the MAC addr, they just call brctl for bridge creation and device enslavement. There is nothing to fix about this in initscripts.