Hi John,
Could you explain your use-case from the perspective of the result you
would like to achieve instead of a suggested implementation? I could
guess at what that result is from the suggested implementation but I
think it would be better to get your perspective directly.
--- Keith
On Fri, 2009-11-13 at 15:39 -0600, John Galgay wrote:
> 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
>
>
> _______________________________________________
> discuss mailing list
> [email protected]
> http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
