Red Hat Bugzilla – Bug 803752
ifup-eth and ifdown-eth incorrectly handle bridged devices and unreliably build and tear down tunnels for TAP devices
Last modified: 2014-03-16 23:30:14 EDT
Created attachment 570318 [details]
sample ifcfg-ethx and ifcfg-tapx files and patch files to correct the problem
Description of problem:
ifup-eth builds a bridge device but does not assign addresses or other interface specific properties. Sometimes a second 'service network restart' will get an address assigned. Ifup-eth uses tunctl to build a TAP device tunnel I/F but the way tunctl is used creates tunx or tapx devices other than the intended number when invoked more than once because ifdown-eth does not correctly tear down the tunnel using tunctl. I was also not able to use tunnels created by tunctl with openvpn. Also noted that the bridge and member interfaces were not explicitly set to promiscuous mode. Openvpn reliably creates tap and tun device interfaces, so is preferred over tunctl when available.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. introduce BRIDGE=br0 into ifcfg-eth files
2. reboot or execute 'service network restart'
bridge will be created, but no IP address will be assigned to the br0 device nor the eth devices. Example ifcfg files attached.
bridge should be created with an IP address specified in one of the ifcfg-ethx files.
Additional info: provided are some ifcfg files used to reproduce the issue. Also provided are patch files to fix the problem: correctly apply interface parameters to the bridge device, apply promiscuous mode to the bridge device and member interfaces, create tun and tap interfaces preferentially using openvpn (if available), then tunctl, correctly tear down tun and tap interfaces, reliably remove members from the bridge and tear down the bridge on last member removal.
The f16.pat files are for Fedora 16 and the cos.pat are for CentOS 6.2. I have filed a separate bug report for CentOS 6.2.
The config files look wrong - IP addresses go in the bridge configuration file, not in the underlying device file.
Can you provide a set of sample config files or point me to the documentation on how this is supposed to be done - I haven't found anything that really covers this in enough detail to make it work as you seem to indicate.
All the IP configuration would go in a ifcfg-br0 file with TYPE=Bridge.
I.e., something like this ifcfg-br0:
The IP configuration would then be removed from ifcfg-eth0, so it just looks like:
Created attachment 574565 [details]
Some examples of common net config files
Add aditional documentation to initscripts to provide some samples of common network configurations including use of bridged interfaces and tunnels.
Created attachment 574570 [details]
revised patch file to replace ifup-eth.f16.pat
Reverted to account for correct handling of bridge address configuration with correctly formatted ifcfg-br0 file.
That still doesn't look right (note: diff -u format preferred) - the bridge settings should not need frobbed from the device config file.
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '16'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 16's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 16 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" and open it against that version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.