[Bug 648620] New: "Missing" option for bridge interfaces
https://bugzilla.novell.com/show_bug.cgi?id=648620 https://bugzilla.novell.com/show_bug.cgi?id=648620#c0 Summary: "Missing" option for bridge interfaces Classification: openSUSE Product: openSUSE 11.3 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: joop.boonen@boonen.org QAContact: jsrain@novell.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.10) Gecko/20100914 SUSE/3.6.10-0.3.1 Firefox/3.6.10 When i look at the option for physical network interfaces i have: <quote> Network Card Setup ┌General──Address──Hardware────────────────────────────────────────────────┐ │ Device Type Configuration Name │ │ Ethernet▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒↓ eth0▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ │( ) No IP Address (for Bonding Devices) [ ] Use iBFT values │ │(x) Dynamic Address DHCP▒▒▒▒▒▒▒▒▒▒↓ DHCP both version 4 and 6▒↓ │ │( ) Statically assigned IP Address </quote> When I look at the options for a bridge interface I see: <quote> Network Card Setup ┌General──Address──Bridged Devices─────────────────────────────────────────┐ │ Device Type Configuration Name │ │ Bridge▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒↓ br0▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ │( ) Dynamic Address DHCP▒▒▒▒▒▒▒▒▒▒↓ DHCP both version 4 and 6▒↓ │ │(x) Statically assigned IP Address │ </quote> I'm missing the option "( ) No IP Address (for Bonding Devices) [ ] Use iBFT values" for the bridge interface. As this is very useful for Xen based firewall virtual system. Reproducible: Always Steps to Reproduce: 1. 2. 3. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=648620
https://bugzilla.novell.com/show_bug.cgi?id=648620#c2
Michal Zugec
https://bugzilla.novell.com/show_bug.cgi?id=648620
https://bugzilla.novell.com/show_bug.cgi?id=648620#c3
--- Comment #3 from Michal Zugec
https://bugzilla.novell.com/show_bug.cgi?id=648620
https://bugzilla.novell.com/show_bug.cgi?id=648620#c4
--- Comment #4 from Joop Boonen
https://bugzilla.novell.com/show_bug.cgi?id=648620
https://bugzilla.novell.com/show_bug.cgi?id=648620#c
Joop Boonen
https://bugzilla.novell.com/show_bug.cgi?id=648620
https://bugzilla.novell.com/show_bug.cgi?id=648620#c5
Michal Zugec
https://bugzilla.novell.com/show_bug.cgi?id=648620
https://bugzilla.novell.com/show_bug.cgi?id=648620#c6
--- Comment #6 from Joop Boonen
https://bugzilla.novell.com/show_bug.cgi?id=648620
https://bugzilla.novell.com/show_bug.cgi?id=648620#c7
Michal Zugec
https://bugzilla.novell.com/show_bug.cgi?id=648620
https://bugzilla.novell.com/show_bug.cgi?id=648620#c8
Marius Tomaschewski
Marius, could you please write your opinion here?
The "do not assign any IP to an interface" [including, but not limited to a bridge] case is essential for many setups. This scenario inclusive. And in case of a bridge it is essential for many virtualized setups. _But_ see bellow please -- it is a basically usability / label problem. YaST2 is forcing to enter the 0.0.0.0/32 IP -- as I requested already, please stop confusing the users and do not use it any more, just allow the user to keep the address settings empty to avoid this sort of bug reports in the future. (In reply to comment #6)
May be I'm a bit to paranoia. But I think security wise 0.0.0.0/32 is less secure then "No IP" as DOM0 has an IP address on the interface even tough it's 0.0.0.0/32. A smart hacker might be able to make use of this, to exploit DOM0, as DOM0 listens to this interface via 0.0.0.0/32.
No. YaST2 is using a trick derived from the "ifconfig $ifname 0.0.0.0" behavior I think (what where a request to _remove_ all IPv4 IPs) to make the address input field checks easier I think. I don't like it too and asked already (and now again) to not use it, but it is harmless: The request to set 0.0.0.0/32 to an interface is ignored by the kernel; the 0.0.0.0/32 address is not set on the interface.
What is the disadvantage of using "No IP" in any other case the a "bounding slave"?
Well, yast2 is using the "No IP" label to describe the BOOTPROTO=none config setting. Maybe BOOTPROTO=slave would be better name in case of bonding slaves, but in some another scenarios / interfaces it is not the best choice. How it works: The BOOTPROTO=none is to avoid especially the "ip link set up dev ethX" and also any another link + ip (ip addr) configuration step completely. On the another side, a "ifdown ethX" causes to remove all IPs, set it "down" and stop dhcp clients, so the interface is in a clean state after [so it is different behavior to just STARTMODE=off] and a configuration change from IP on ethX to IP on bondY using ethX + restart works as expected without any need for special hacks. That the interface is not set "up", is is important in case of bonding interfaces, because it has to be in the "down" state while it is added to the bonding [or it would fail] because the bonding controls the rest; it calls "ip link set up" itself. When the interface is "up", the bonding script has to call "down" before it adds it to the bond and in the time it were up, e.g. ipv6 address may be configured by the kernel and cause trouble later [duplicate address detection, ...]. The configuration "(X) static" + "0.0.0.0/32" causes following config: BOOTPROTO=static IPADDR=0.0.0.0/32 In this case, the "ip link set up ethX && ip addr add 0.0.0.0/32 dev ethX" are called, so the interface is in "up" state after, but has no IP address, because 0.0.0.0/32 is ignored. For physical interfaces (eth0), the static variant is what the user expects; the interface is up and there is no IP assigned by ifup [but maybe ipv6 via autoconfig]. A BOOTPROTO=none, would not bring the interface "up" and the interface would be down after "ifup eth0" call. In case of a bridge interface, BOOTPROTO=none works fine, because ifup-bridge script calls "ip link set up dev brZ" itself -- otherwise the bridge would not start working (doing STP or forwarding packets). What does not happen in BOOTPROTO=none, is the link configuration: the MTU or MAC address are _not_ applied here. Joop, there is another issue that you should consider in your setup, except you've disabled ipv6 at all: IPv6 autoconfiguration. Independently of the BOOTPROTO, all your interfaces may get link local ipv6 addresses like "fe80::<the MAC address with few changes>/64". These addresses are "link local", that is usable from directly attached hosts... You may disable ipv6 either globally or also per interface by adding a configuration file: /etc/sysconfig/network/ifsysctl: net.ipv6.conf.eth0.disable_ipv6 = 1 net.ipv6.conf.eth1.disable_ipv6 = 1 .. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=648620
https://bugzilla.novell.com/show_bug.cgi?id=648620#c9
Michal Zugec
participants (1)
-
bugzilla_noreply@novell.com