Date: Mon, 05 Oct 2015 09:32:49 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 156226] [lagg]: failover does not announce the failover to switch Message-ID: <bug-156226-2472-KhS5pZdZ7l@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-156226-2472@https.bugs.freebsd.org/bugzilla/> References: <bug-156226-2472@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156226 --- Comment #14 from pvz@itassistans.se --- The patch could probably be simplified. I suggested when I created the case four years ago that the solution might be to send out a gratuitous ARP. However, that would not seem to be a correct generic solution, in that you're adding coupling to IPv4 and IPv6, where the problem actually occurs further down the network stack. It would be entirely appropriate to send out *any* type of broadcast Ethernet frame. For example, VMware ESXi uses RARP in this scenario: http://rickardnobel.se/vswitch-notify-switches-setting/ This would be a valid approach no matter if the switches in question are connected to an IPv4 network, an IPv6-only network, or even, God forbid, IPX or PPPoE or anything else that might run over Ethernet (not IP neccessarilly) ... The only goal is to update the MAC forwarding tables in the switches, what the actual payload in Ethernet is doesn't matter. You might even be able to send out a completely empty broadcast frame. This is of course then also complicated by the hypothetical but plausible scenario where you might have VLANs configured on top of the lagg, where these "notify packets" would have to be sent for each VLAN, because switches typically have per-VLAN forwarding tables. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-156226-2472-KhS5pZdZ7l>