Qrux wrote: > On Apr 6, 2012, at 3:24 PM, Bruce Dubbs wrote: > >> 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. > But why is it in ifup? ifup should not be aware of the bridge > interface. It's not aware of the bridge explicitly. It's just sets whatever interface and any potential components up. >>> 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. > It should only be in one location: ipv4-static. It's an IP > configuration parameter. Not a physical link parameter. For now, it could be in either place, but I think it gives more flexibility for future services. >>> 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. > I'm not exactly sure how your bridge configurations look like. Even > without my virtualization setup, when I have a bridge on br0 that > enslaves eth0, I don't need forwarding to see "output" packets. Is > there something strange that the KVM stuff does to the default > bridging configuration? It was suggested in the documentation I read. > Secondly, (again with the why), IP_FORWARD is a system-wide setting. > Why is bridge handling that? Bridges should not be aware of > IP_FORWARD. I would stand behind your idea that IP forwarding should > go in sysctl.conf. Again, it was there for convenience. If needed by the bridge, then all the network configuration items are in one location. > The point is, this running theme of parameters being applied in > inappropriate places is the main motivation behind my scripts. > Frankly, they are not that different. The existing ones--including > this round of changes--do not, and seem to proliferate the surprising > behavior of settings parameters in unexpected places. There are only ifup/ifdown and the services they call. You can't really understand ifup without the services and vice versa. They are not long scripts. Surprise is not an issue. ifup is only doing four things beyond simple error checking: Create/configure the intrerface Set the interface up If requested, set the interface MTU If requested, set the interface as the route default All this is done in about 25 lines of code, including comments. > I'm not > aware of any physical or kernel limitations on MTU, so if you are, > then your info may be more current than mine. http://tools.ietf.org/html/rfc791 September 1981 Page 25. >>> (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. > > It's completely superfluous. Yes, it *can* hurt. A wrongly > configured broadcast address can bork your IP configuration. If it's > entirely unneeded, don't you think it's better to leave it out? If > the logic to look for it is not there, it can't be misconfigured. > It's entirely determined by the IP address and the PREFIX. If the > scripts look at PREFIX instead of a classic netmask, then it should > also avoid BROADCAST. > > Look at it another way. Taking the BROADCAST-handling logic out does > not hurt ifconfig scripts that still have it in; it's just completely > ignored. People can get around to removing that extraneous parameter > when they need it. BROADCAST has been in the script since the script was first put in svn in 2004. Perhaps is should be removed. I'd like some other opinions. I do disagree that that something should be removed because it might be misconfigured. You might want to make that argument to the maintainers of Inetutils and have them remove the option from the ip command. >>> 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. > Even if it's rarely used--which I don't necessarily agree > with--should it be confusing? If it's your scenario (that it's > rarely used), then we have lots of flexibility to choose a meaningful > and less ambiguous variable name. If it's often used, then it should > *definitely* be less ambiguous. OK. I do want to keep IFACE, but I'm willing to change INTERFACES. What do you suggest. PHYS doesn't seem right to me. How about COMPONENT_INTERFACES? ATTACHED_INTERFACES? >>> 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. > Where is this replication? In fact, I'm trying to remove replication > as well as surprising parameter setting in unexpected scripts. There is potential replication if a new service script is developed. >> 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. > I would agree if you're saying that IP_FORWARD is a system parameter, > and should be set in a system-wide fashion, and not in a way that > implies a relationship to a per-logical-interface. Enabling IP > forwarding in ifconfig wrongly implies it's a per-logical-interface > setting. It's very much a system-wide parameter, and doesn't really > make sense in ifconfig files. Consider how it would interact with > iptables if setting the sysctl happens only if a certain ifconfig > scripts gets reached. The iptables script could set it also, but since the network boot script comes after iptables, the last one takes priority. There's nothing to prevent a user from creating a S99local bootscript and setting it there either. > In fact, if we stick by your "KISS" suggestion, IP forwarding > shouldn't even get treatment here. It's another "advanced" feature > that people can enable on their own. IP forwarding is orthogonal to > bridging. It's providing an easy option. We also have PEER in ipv4-static, but I've never used it. I think it is needed for KVM, so I set it in the bridge service. >>> 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. > I don't have any issue with your discomfort, but I'd like to > understand the technical objection(s). In ifup you only set the MTU if you do a CHECK_LINK. The interface does not need to be up to set the MTU. The CHECK_LINK operation controls whether to set the interface up or not. This is only useful for a bridge where the bridge device has not yet been created. If the procedure for setting the interface up is delayed to after bridge creation, CHECK_LINK is not required at all. Setting the GATEWAY in ipv4-static doesn't make more sense than setting it in ifup. The only real need for ipv4-static is to set the ip address for the interface. bridge created the bridge device and adds interface devices to it. Setting the bridge up there and setting the ethx interfaces up in ifup didn't make sense to me. > In the ticket, I already mentioned that I don't mind coalescing > BRIDGE_IF and IPV4_IF into IFACE. If I were to guess, that's what > I'd say you're objecting to. Once I get around to that, the > ifconfigs look exactly as they did before. The only difference would > be where I'm using PHYS for INTERFACES, but I figure that's easy to > do a mental s/PHYS/INTERFACES/g to understand. We do have different preferences for variable names, but that wasn't the problem. > This variable coalescing doesn't change the scripts I provided > materially, except to rename those two variables. What it *does* do > is keep IP stuff in ipv4-static as much as possible, bridge stuff in > bridge, and physical stuff in ifup/ifdown. What IP stuff? Your version of bridge creates the bridge, sets it up, adds ethx interfaces, and sets ip_forward. I just moved the 'set up' to ifup so the bridge and ethx devices can all be brought up together. In ipv4-static, I just moved the GATEWAY code to be after the 'set up' because the GATEWAY code failed if the device was down. > It seems that in trying to keep things simple, you're spreading logic > into strange places: ifup handles some IP parameters which ones? > , physical link parameters, Yes, mtu and also brings up bridges interfaces. The name of the program is ifup, as in interface up. > Then, bridge handles some IP issues, which? ip_forward? Your version did that too. The ip_forward code could easily be brought up to ifup. > but ipv4-static/dhcp also handles IP issues. When I look at this, we really only have a couple of differences. There are only a few lines of code in different sections of what is logically all one function (ifup/ifdown) and some minor naming issues. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
