Hide Forgot
Description of problem: When a bridge does not exist and the ifcfg file contains bridging_opts, ifup-eth first creates the bridge doing: brctl addbr <bridge_name> Just after that it iterates through the bridging_opts echoing the values to /sys/class/net/<bridge_name>/bridge/<key_name> The problem is that when echoing the value to the bridge sysfs entries, those entries will not yet exist, as some, like multicast_router are created after the link is put up. Version-Release number of selected component (if applicable): initscripts-9.03.40-2.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. Create a bridge named 'tar' with the following ifcfg-tar: DEVICE=tar ONBOOT=yes TYPE=Bridge DELAY=0 DEFROUTE=no NM_CONTROLLED=no BRIDGING_OPTS='multicast_router=0 multicast_snooping=0' 2. Do 'ifup tar' 3. cat /sys/class/net/tar/bridge/multicast_router Actual results: 1 Expected results: 0 Additional info: Adding an 'ip link set dev ${DEVICE} up' solves it for me. *************** *** 62,67 **** --- 62,68 ---- [ -n "${DELAY}" ] && /usr/sbin/brctl setfd ${DEVICE} ${DELAY} [ -n "${STP}" ] && /usr/sbin/brctl stp ${DEVICE} ${STP} # add the bits to setup driver parameters here + ip link set dev ${DEVICE} up for arg in $BRIDGING_OPTS ; do key=${arg%%=*}; value=${arg##*=};
The code looks the same in fedora, so it happens the same.
Is it completely safe to take the bridge up (with its default options set) and only later tweak them? (I have flawed STP values in mind) I'm not sure about the consequence, but please consider re-applying the options after the bridge is up, so that both pre-up and post-up options take effect.
We can't set this option because of this check in kernel https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/bridge/br_multicast.c?id=refs/tags/v3.15-rc1#n1860 I am not sure why kernel is doing that. They allow to set other parameters when the bridge is down. Reassigning to kernel to get an opinion if this inconsistency could be fixed in kernel of if we should workaround it in user-space. Similar issue is with hash_max.
By the way bridge-utils have the same problem [root@localhost ~]# brctl setmcrouter tar 0; echo $? 0 [root@localhost ~]# cat /sys/class/net/tar/bridge/multicast_router 1
It is because certain opts you can only set when the bridge is up, isn't it?
But it looks that your reproducer *works* on rhel7.
Created attachment 886219 [details] Completely untested patch which could solve this from initscripts side.
Since there is no response from kernel, lets fix it in initscripts.
https://git.fedorahosted.org/cgit/initscripts.git/commit/?h=rhel6-branch&id=32a67116ad1b2f058d9724b5205a859f01dca7a3
Please provide a 6.5.z backport of the fix, as this bug blocks a requested RHEV feature bz 1044042 (to set bridge options).
Since the fixup patch is tiny, and the bug's resolution is anticipated by a RHEV-3.5 customer, can supporting multicast_snooping be granted exception+?
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1448.html
(In reply to Lukáš Nykrýn from comment #10) > https://git.fedorahosted.org/cgit/initscripts.git/commit/?h=rhel6- > branch&id=32a67116ad1b2f058d9724b5205a859f01dca7a3 This problem still happens for me, even with the initscripts patch included. Upon initial bootup BRIDGING_OPTS="multicast_snooping=0" doesn't get applied. Doing another "ifup br0" manually afterwards works. The patch should be modified to also apply "multicast_snooping", not just "multicast_router" and "hash_max".