]> xenbits.xensource.com Git - libvirt.git/commit
network driver: don't send default route to clients on isolated networks
authorLaine Stump <laine@laine.org>
Sun, 13 Mar 2011 08:42:58 +0000 (04:42 -0400)
committerLaine Stump <laine@laine.org>
Mon, 14 Mar 2011 12:24:23 +0000 (08:24 -0400)
commit013427e6e733f7a662f4e8a9c11f7dad4cd65e3f
tree07dca8af7175eb4f27e2ac99c6a427b979a31ea9
parentc51f08272af7a1a890ccf10d421b8948777c3a33
network driver: don't send default route to clients on isolated networks

Normally dnsmasq will send a default route (the address of the host in
the network definition) to any client requesting an address via
DHCP. On an isolated network this makes no sense, as we have iptables
to prevent any traffic going out via that interface, so anything sent
that way would be dropped anyway.

This extra/unusable default route becomes problematic if you have
setup a guest with multiple network interfaces, with one connected to
an isolated network and another that provides connectivity to the
outside (example - one interface directly connecting to a physical
interface via macvtap, with a second connected to an isolated network
so that the host and guest can communicate (macvtap doesn't support
guest<->host communication without an external switch that supports
vepa, or reflecting all traffic back)). In this case, if the guest
chooses the default route of the isolated network, the guest will not
be able to get network traffic beyond the host.

To prevent dnsmasq from sending a default route, you can tell it to
send 0 bytes of data for the default route option (option number 3)
with --dhcp-option=3 (normally the data to send for the option would
follow the option number; no extra data means "don't send this option").

I have checked on RHEL5 (a good representative of the oldest supported
libvirt platforms) and its version of dnsmasq (2.45) does support
--dhcp-option, so this shouldn't create any compatibility problems.
src/network/bridge_driver.c