[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH v2 2/2] bridge driver: don't masquerade local subnet broadcast/multicast packets



On 13-09-23 10:05 AM, Laszlo Ersek wrote:
Packets sent by guests on virbrN, *or* by dnsmasq on the same, to
- 255.255.255.255/32 (netmask-independent local network broadcast
   address), or to
- 224.0.0.0/24 (local subnetwork multicast range)

All multicast, not just the local subnet multicast needs to be exempt from masquerading.

I would tend to guess that anyone trying to do "global Internet" multicast behind NAT is signing up for a world of trouble anyway. It's not like you could put a multicast source behind a NAT so it could really only apply to sinks.

Since sinks operate by "subscribing" to a multicast source by way of their multicast router (which should be local and not through a NAT) I would think a NAT device that supports multicast to it's NAT clients should support it as if it were a multicast router and not so much a NAT and so there never really should be NATting of traffic from a sink.

So AFACT there never really is a use-case for actually NATting multicast traffic, so just don't NAT the whole range, 224.0.0.0/4.

are never forwarded, hence it is not necessary to masquerade them.

In fact we must not masquerade them: translating their source addresses or
source ports (where applicable) may confuse receivers on virbrN.

One example is the DHCP client in OVMF (= UEFI firmware for virtual
machines):

An example use-case if you want for multicast is creating a corosync cluster. When that works, you have this patch right. :-)

diff --git a/src/network/bridge_driver_linux.c b/src/network/bridge_driver_linux.c
index 80430a8..95add0e 100644
--- a/src/network/bridge_driver_linux.c
+++ b/src/network/bridge_driver_linux.c
@@ -127,6 +127,9 @@ out:
      return ret;
  }

+static const char networkLocalMulticast[] = "224.0.0.0/24";

NACK. 224.0.0.0/4 is the entire multicast space. 224.0.0.0/24 is just one tiny reserved "control block" of addresses for routing protocols, etc. There's a lot more to multicast than just routing protocols.

Cheers,
b.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]