Date: Tue, 07 May 2019 18:26:58 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 234472] CARP using wrong multicast MAC destination (was: Missing outgoing CARP traffic on interface) Message-ID: <bug-234472-7501-EyTiXEwkf3@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-234472-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-234472-7501@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=3D234472 --- Comment #10 from Andreas Pflug <pgadmin@pse-consulting.de> --- AFAICS the rule actually does as advised, since naively speaking 224.0.0.18 isn't in the ix4 network and so anything should be routed to the stdgw. But it's IP multicast, and so route-to shouldn't be applied in any case on 224.0.0.0/4, according to RFC1112. I added "pass out quick from {ix4} to 224.0.0.0/4" before that route-to rul= e, preventing the misshaped multicast packet. So actually pf does as advised to straight forward, but this will break multicast specifications. IMHO pf should implement the special behaviour on multicast packets implicitely, i.e. excepting them from routing, because th= is issue has been around for years without being diagnosed correctly (probably blaming some innocent switch IGMP implementations), and users probably don't expect a standard default gateway routing command breaking local multicast traffic. --=20 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-234472-7501-EyTiXEwkf3>