On 12-03-01 06:41 AM, Santiago Garcia Mantinan wrote: >> If the if-pre-up.d script is changed to use "ifup" I think the following >> configuration in /etc/network/interfaces would make sense : > > Well, first I seem to remember that using ifup used to cause problems, but > besides that, it would mean that you have to define all the interfaces > explicity and as inet manual and that doesn't make sense at all to me.
Agreed, that can be cumbersome with many interfaces. > Besides, I've seen people doing things like the one you propose (adding > configs for the bridge ports) and that was causing problems, not solving > anything. >From what I saw, all the bridged ports configs are simply ignored. >> The proposed configuration is opened to suggestions as maybe that would >> make more sense to support a mtu directive in the bridge configuration >> stanza (which would tentatively set the mtu of all devices part of the >> bridge). > > Well. you've opened some interesting discussion here, let's see if we can > get this to a point we all agree on. I'm sure we can come to an agreement on how to deal with this best. > There is a long standing bug we have and that still exists because I don't > know how we should deal with all these MTU things... the bug is #292088 > http://bugs.debian.org/292088 and is asking for more doc on MTU stuff, I'm > CCing the old bug to let possible followers find about this discussion but > I'd rather have all discussion on the new bug as the old one was calling for > doc and doc will result of the implementation we need to agree on here, > regarding the kernel problems commented on #292088 they seem to be fixed on > current kernels, at least for the tests I run on my systems. I won't be > merging both bugs as the old is about doc and this one is about implementing > new functionality. > > I believe that what is coherent here is that both the bridge interface and > the underlaying interfaces (bridge ports) have the same MTU. The bridge itself will have a MTU matching the smallest MTU of the bridged ports. > So one could write something that checks to see if there is a MTU set for > the bridge interface and sets this for all the bridge ports, no problem here > as it is the user who is requesting this and he should know what MTU the > interfaces support (we are not doing this yet, but I think we should add > this for the next version if we agree on this). That's the simplest solution IMO. Adding the "mtu XXXX" to the bridge stanza is consistent with how other interfaces are managed. This directive should also be accepted when the bridge is in "inet manual" though. Setting the MTU at the bridge level and trying to set the same MTU on the bridged ports is good as that "degrades" well. Asking ifconfig to set a MTU higher than the bridged port supports trows an error and the MTU isn't changed for that device. Example, a user bridges a 1G port (MTU 9000) and a PPPoE (MTU 1492) interface and ask the bridge to have a MTU of 9000. The bridge will try to propagate the MTU of 9000, that will work for the 1G port but will fail on the PPPoE one. The bridge will then use the smallest MTU of the bridged port, that is 1492. Does that sound like a desirable way to "degrade" if the user was mistaken ? > There is only one thing I'm not sure about this case, and it is what to do > if you have a 1500 port and a 9000 port, should we check if the MTU of the > port is higher than the one we are setting for the bridge and in that case > leave the port with the big MTU? I'd leave the bridged port to its MTU setting. The bridge itself will adapt to the smallest MTU and that should be OK, right ? > I believe that in most cases this will be because the MTU of the port that > has a big MTU is set to the default one, not because the user had set it, so > I think that setting it to the bridge one is the wanted thing on this case, > and the user could still set a higher MTU for this port if he wants with a > post-up ifconfig command (Note: document this as an example if we agree to > set this). I am not opposed to this but that sounds like more work to implement. > Thus I'd say, set the MTU of all the ports to the bridge one on this case > (user specifies the MTU for the bridge). Yes. > Ok, the next thing to solve would be the case where the user doesn't specify > a MTU, we could be tempted to do several things here: > > We could explore all the ports and choose the bigger MTU among them to set > it to all the ports, but this could force higher than supported MTUs on some > interfaces, thus this option seems like trouble. > > We could set them all (including the bridge) to the smaller supported MTU. I > see no problems with this one. > > If I had to go with one of these two I'd choose the later, I believe it is > the safest option. Please note that we would have the option of setting a > big MTU on the bridge and this would propagate down to all the ports, so if > you want a bigger MTU that would be the way to go. > > However there is another option, if you are not specifying a MTU it could be > because you want the kernel to decide here, and I've been doing some tests > on this, the bridge will dynamically adapt to set its MTU to be equal to > that of the smaller of it's ports, so if you have a giga with a 9000 MTU and > attach a typical DSL interface with a 1492 MTU the bridge is going to set to > a MTU of 1492, farthermore, it won't allow manually setting an MTU higher > than what it's ports allow, so it is playing safe here, of course. But if > you only have giga interfaces that are all set to 9000 the resulting bridge > will go with a MTU of 9000. > > So... what should we do if the user doesn't specify a MTU? > I'd say... don't do a thing, the less you mess with things the less trouble > you'll get (less interactions with user scripts, bridge kernel driver and > NICs kernel drivers). Agreed, let's keep it simple. If the user didn't ask for a specific MTU, don't try to be smarter. > I still haven't taken a look at how to implement this, I want to agree on > the good solution and then take a look at the implementation, but I don't > think there should be any problem in implementing what I have exposed as my > sugestions on how to do this, which is to set the MTU of the ports to that > of the bridge when the user specifies this value. I'm glad to hear that you see no major problem for the implementation part. > One last thing for the future... if we implement the hotplug addition of > interfaces like we want per #626152, still waiting on #568479 of ifupdown, > we'll net to try to set the MTU of the hotpluged interfaces we try to > attach, to what? the current bridge MTU? or the MTU specified on the > interfaces file? :-???? I haven't looked at those 2 bugs, but for a new device, I'd try to set the bridge MTU to the one of the hotplug device *if* higher than the current bridge MTU. Otherwise, if the hotplug device supports a smaller MTU, the bridges will adapt to it by itself. If the hotplug device supports a larger MTU (say 9000 while the bridge is at 4000), then that should be treated as a "mtu 9000" directive in the bridge stanza. The code would then attempt to propagate that new MTU (9000) and might fail or succeed. At any rates that should set the bridge MTU to the smallest MTU of all devices bridged. Another, simpler alternative would be to simply ignore the MTU directive of the hotplug interface an use the one in the bridge config stanza. If the user want a higher MTU to match the one of the hotplug device, he should set the bridge MTU to that value. Interesting discussion indeed. I appreciate your input on this. Regards, Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
