On 22/09/2016 03:58, Gleb Smirnoff wrote:
On Wed, Sep 21, 2016 at 09:12:11PM -0400, Ryan Stone wrote:
R> > IMHO, the original patch was absolutely evil hack touching multiple
R> > layers, for the sake of a very special problem.
R> >
R> > I think, that in order to kick forwarding table on switches, lagg
R> > should:
R> >
R> > - allocate an mbuf itself
R> > - set its source hardware address to its own
R> > - set destination hardware to broadcast
R> > - put some payload in there, to make packet of valid size. Why should it be
R> > gratuitous ARP? A machine can be running IPv6 only, or may even use
R> > whatever
R> > higher level protocol, e.g. PPPoE. We shouldn't involve IP into this
R> > Layer 2
R> > problem at all.
R> > - Finally, send the prepared mbuf down the lagg member(s).
R> >
R> > And please don't hack half of the network stack to achieve that :)
R>
R> The original report in this thread is about a system where it takes almost
R> 15 minutes for the network to start working again after a failover. That
R> does not sound to me like a switch problem. That sounds to me like the ARP
R> cache on the remote system. To fix such a case we have to touch L3.
Does lagg(4) hardware address change when it failovers?
It moves the address between interfaces which typically moves it between
switches too.
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
