Qrux wrote: > 1) Why is ifup bringing up the virtual interface? That is clearly a > service-level responsibility. In fact, in the case of a bridge, that > interface doesn't even exist until you create it with brctl. What > purpose does it serve in ifup?
Sine it it placed after the creation/configuration, it brings up the interface specified and any component interfaces. > 2) Why does ifup manage any routing at all (including gw)? That's a > service-level issue. Sort of the same thing. It prevents needing the code in multiple locations. > 3) Why does bridge handle setting IP_FORWARD? Why isn't that in > ipv4-static? Bridging shouldn't care about IP issues like routing, > and that's the wrong place to set it. It's needed for passing packets from the outside to a bridged device. It's there for convenience. If IP_FORWARD isn't specified, then nothing happens. > 4) Why pay any attention to the MTU value? Report an error from ip > if a bad MTU value is set; I don't think anyone needs to rely on the > ifup-&-co. scripts to check for valid values. ip will report those > values. AFAIC--and I was the one who put a numeric check in the > first place--it doesn't even need to check if it's a number. Yes, you suggested a numeric check, but you allowed an illegal value. I just added the check for a number at least as large as the minimum value allowed. > (Another minor point...Why specify BROADCAST? Isn't it unusual to > have an address/prefix that didn't produce the right broadcast > address.) An old habit. It used to be always required. Leaving it doesn't hurt anything. > 5) What does this mean? "What these scripts to *not* do is process > multiple IP addresses if there is more than 1 ethx interface." I don't handle more than one value of $IP or $PREFIX. > Are you talking about a bridge with multiple slaves (e.g., eth0 -- > br0 -- eth1)? Or virtual NIC definitions (e.g., eth1:3)? Seems to > me a big part of the issue was making sure the scripts support > virtual NICs. Supporting multiple slaves for a bridge in trivial. > Again; it's not a multi-homed IP setup. A bridge, regardless of the > number of enslaved ports, has only a single logical interface (e.g., > br0). Virtual nics like eth1:3 are handled with a separate ifconfig script. For example $ cat ifconfig.eth0:2 ONBOOT=no IFACE=eth0:2 SERVICE=dhcpcd DHCP_START="--waitip" DHCP_STOP="-k" # Set PRINTIP="yes" to have the script print # the DHCP assigned IP address PRINTIP="yes" # Set PRINTALL="yes" to print the DHCP assigned values for # IP, SM, DG, and 1st NS. This requires PRINTIP="yes". PRINTALL="no" -------- > 6) Also, do we just dislike PHYS as a variable name? That seems > preferable to two variables with similar and somewhat confusing names > (IFACE vs INTERFACES). It's a personal preference. The only place INTERFACES makes any sense is on a bridge. Most users will never use that. > 7) As for cleanly separating logic...The general guideline should be > that ifup should not use IFACE. In fact, only ifdown does, and > that's just a reference-counting shortcut. The other guideline is > that the service scripts should refer to IFACE, and only use PHYS > (what you call INTERFACES) as necessary (for example, in the case of > a bridge enslaving ports). > > Stuff like ifup handling gateways, bridge handling IP-related > sysctls, and ifup bringing up bridge interfaces all seem misplaced. The alternative is to replicate some functionality in multiple service scripts. I could put the IP_FORWARD in the bridge script, but a user might well want to bring up eth0 and eth2 and enable IP_FORWARD. Of course, that could be also done in either syscyl.conf or in the iptables configuration script. > It's good to take time to look at this, but can you reframe this in > terms of the problems you're solving? AFAIK, there was only one > remaining issue to look at, which is how to properly support virtual > NICS. I thought I had resolved the issues with MTU, multiple PHYS > per bridge, and cleanly separating the service/physical logic issues. > It just seems like a lot of changes here are pushing the wrong logic > into the wrong scripts. I'd like to keep the scripts as simple as possible. What are the circumstances where more than one physical interface is needed for a bridge? How many of our users need such a capability? I'm trying to provide an alternate solution to the ticket you created. I was uncomfortable with your solution. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
