[ovs-discuss] Controlling / Constraining / Directing DHCP

John Galgay john at galgay.net
Fri Nov 13 21:39:07 UTC 2009


I am thinking about the DHCP broadcast issue across the multi-tenant cloud
switching fabric.  This includes intra-host openvswitch, the multi-host
openvswitch, and openvswitch+real switch scenarios.  The objective is
obviously to constrain the ability of any entity besides the desired server
to answer the DHCP request and assign IP addresses.

The best solution is always a dual wall solution - 1 wall to prevent an
event, the other in case it does anyways.  In this case, the first wall is a
receiver wall and common practice is to use firewall/ip tables to prevent
DHCP requests from entering / DHCP offers from leaving a host that could
receive the Request broadcast and act as an unauthorized DHCP server.  This
solution however assumes administrative control off all receivers or the
infrastructure connecting all receivers (such is a best practice with cable
modems).  

The second wall is a sender wall.  The objective would be to send  DHCP
requests directly to the  DHCP server and have the answers send directly
back to the requesting host.  We are all aware of DHCP forwarding services
that can be provided by a router  (also called IP Helper by some vendors) to
an off-LAN DHCP server --- whereby the router picks up the DHCP request,
stamps itself as the Gateway, and unicast forwards the request to a
configured DHCP server(s) anywhere.  The unicast Offer responses are
received by the router and sent directly to requesting MAC address. 

I see this as a useful feature of the openvswitch residing in a VM Host,
whereby the ovs will intercept the DHCP Requests on selected ports, stamp
its internal (bridge) IP address as the gateway, unicast forward the request
to  the configured DHCP server(s) - [could be a host on the same network or
a host on a different network].  The Offer will be unicast returned to the
internal IP address of the ovs switch, and forwarded to the requesting VM
out the originally received port.

This service will  effectively keep DHCP broadcast Request / Offer traffic
off of the entire multi-tenant cloud switching fabric all together.  The
only entity that will see the DHCP request is the ovs switch instance . and
the only answer can come from the authorized DHCP servers . and all traffic
between these entities will be unicast and may optionally be secured /
encrypted.

Any thoughts on this capability for openvswitch ??

Thanks.

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20091113/5bae743a/attachment-0002.html>


More information about the discuss mailing list