On 2013/05/10 16:53, Mike Belopuhov wrote: > On 10 May 2013 16:43, Chris Cappuccio <[email protected]> wrote: > > Stuart Henderson [[email protected]] wrote: > >> On 2013/02/22 12:30, Stuart Henderson wrote: > >> > I thought we already had something for this after the misc@ thread > >> > a few months ago, but clearly not. > >> > > >> > Adapted from FreeBSD if_lagg.c r171661 (which includes capability > >> > setting which we already do). > >> > http://svnweb.freebsd.org/base/head/sys/net/if_lagg.c?r1=171603&r2=171661 > >> > >> JJ tested this diff but I didn't hear much else. Any comments? > > > > if (tr->tr_ac.ac_if.if_mtu != ifp->if_mtu) seems wrong. what about people > > who want to use trunk between two totally different interfaces for failover?
I think that in this case, they should be doing failover at a different layer, or choose a lowest common denominator themselves - mixing different MTUs within a subnet doesn't work too well and there's no way to let other machines know that your MTU has now reduced and that they should follow suit. > > i think the trunk mtu should simply be the lowest common of the group. > > i agree with chris. doesn't mtu get propogated into the routing table? > what if you failover and your other trunk port can't handle packets that > big but ip_output thinks it should be fine? > That's exactly why the diff restricts things so a port can only be added to a trunk if the MTU is the same as existing ports. Otherwise we would be reducing an already-existing trunk's MTU to the lowest common MTU when a new trunkport is added which would quite possibly give problems in the routing table, and even problems pushed down to daemons (OSPF in particular), I think it's safer to force people to think ahead and make a decision when the trunk interface is created.
