Re: [libvirt] [PATCH 06/10] network: Bridge - Add support for a DHCP Relay Agent
On 28/02/13 19:56, Laine Stump wrote:
On 02/27/2013 09:57 PM, TJ wrote:
> From: TJ <linux(a)iam.tj>
>
> A DHCP relay daemon will be started that will forward all DHCP/BOOTP
> requests on the bridge network via the first declared forward
> interface.
Okay, I think we've got our first candidate for something we might want
to configure. Picking the forward interface would probably be correct
95% of the time, but it seems reasonable someone might want to forward
it somewhere else. Also there's the fact that most people don't define
any forward interface for their networks, just leaving it up to the
host's IP routing to determine the appropriate egress for every packet.
(I don't really like what's done with the forward interface anyway - it
doesn't do anything about routing to force traffic egress via that
particular interface, just rejects any traffic that would have gone out
a different interface).
Are you thinking in terms of <dhcp relay='yes' forward='ethX'/> ?
Should it be always explicit or use the current 'pick a sensible default' but
allow this property to over-ride it?
> The relay is broadcast rather than routed so no IP address
> is needed on the bridge.
>
> The XML <relay> element's "relay" property of the active DHCP
stanza
> defaults to 'no'. Set it to 'yes' to enable the relay:
>
> <ip ...>
> <dhcp relay='yes'/>
> </ip>
>
> The relay will not be started if the "enable" property is 'no':
>
> <ip ...>
> <dhcp enable='no' relay='yes'/>
I don't see the utility of that - it's the same as simply omitting the
<dhcp> element altogether.
The utility of the "enabled='(yes|no)'" properties is one of
convenience for the sysadmin, and was something I felt in need of whilst testing many
scenarios of dnsmaq *before* I embarked on this DHCP
relay functionality, and again when I was testing dhcp-helper.
Without needing to delete important sub-elements of <dhcp> (and lose through
forgetting them) from an active network XML definition I could selectively switch a
<dhcp> block on/off simply by adding
the "enabled" property to the element.
The alternative was continually having to switch amongst several network XML files all of
which were permutations of the same settings in order that disabling a stanza in the
primary XML didn't
require needing to delete, for example, all the <host> and <range>
sub-elements of <dhcp>.