Bug 1086897
| Summary: | bridging_opts fail to apply due to race with creating the bridge | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Antoni Segura Puimedon <asegurap> | ||||
| Component: | initscripts | Assignee: | Lukáš Nykrýn <lnykryn> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Jan Ščotka <jscotka> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.5 | CC: | asegurap, bazulay, cra, danken, kernel-mgr, lnykryn, lpeer, lvernia, psklenar, twoerner | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | initscripts-9.03.41-1.el6 | Doc Type: | Bug Fix | ||||
| Doc Text: |
In BRIDGING_OPTS options "multicast_router" and "hash_max" can be applied after the bridge is up. So lets apply them after the bridge is up.
|
Story Points: | --- | ||||
| Clone Of: | |||||||
| : | 1129624 1138719 (view as bug list) | Environment: | |||||
| Last Closed: | 2014-10-14 06:28:20 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1129624, 1138719 | ||||||
| Attachments: |
|
||||||
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. 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". |
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##*=};