Correct. The DHCP client sends a DHCP DISCOVER packet with IP SRC set to 0.0.0.0, IP DEST set to 255.255.255.255 and UDP source and destination port set to 68/67 respectively. <div><br></div><div>The DHCP server responds with a DHCP OFFER with IP SRC of the server and IP DEST of 255.255.255.255 but the DEST MAC is set to the client VM. </div>
<div><br></div><div>Vinay</div><div><div><br><div class="gmail_quote">On Mon, Nov 26, 2012 at 3:13 PM, Dan Wendlandt <span dir="ltr"><<a href="mailto:dan@nicira.com" target="_blank">dan@nicira.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br><div class="gmail_quote"><div class="im">On Mon, Nov 26, 2012 at 12:38 PM, Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@redhat.com" target="_blank">gkotton@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div>
On 11/26/2012 09:20 PM, Mark McClain wrote:
<blockquote type="cite">
Sorry I realized that my reply did not go back to the list.
<div><br>
</div>
<div>The DHCP protocol is designed for active/active setups, so we
don't need to front it with a load balancer. The protocol
specifies how clients should handle when servers go offline and
lease renewals cannot be completed. You can get HA right now by
starting more than one DHCP agent instance on other hosts.<br>
</div>
</blockquote>
<br></div>
If I understand correctly the IP address of the DHCP server is
passed by Nova to the VM. Which IP address will this be? If a load
balancer is used the address can be the same - that is a virtual IP.</div></blockquote><div><br></div></div><div>DHCP server addresses are not passed to the VM, the VM sends a request to broadcast when it boots, and the DHCP server receives this message and responds. Nova traditionally grabs the DHCP address in order to poke a hole in the VMs inbound security group filters to allow the DHCP server reply to reach the VM. </div>
<div><br></div><div>Dan</div><div><div class="h5"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
<div><br>
<br>
<br>
<blockquote type="cite">
<div>
<div><br>
</div>
<div>mark<br>
<div><br>
</div>
<div>
<div>
<div>On Nov 26, 2012, at 2:21 AM, Gary Kotton <<a href="mailto:gkotton@redhat.com" target="_blank">gkotton@redhat.com</a>>
wrote:</div>
<br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> On 11/26/2012
06:45 AM, Vinay Bannai wrote:
<blockquote type="cite">I would agree that having a
active/standby for DHCP agent makes a lot of sense.
We might want to leverage the VRRP infastructure for
that.
<div>I am not sure I understand clearly the need to
have the DHCP agents sit behind the load
balancers. What are we trying to load balance
here? The amount of DHCP intermittent and
transient to say the least with a heavy bias
towards more traffic at the time of a VM booting
up. <br>
</div>
</blockquote>
<br>
At the moment there are a number of problems with the
DHCP agents:<br>
- single point of failure<br>
- it does not scale<br>
<br>
A simple solution to addressing the above is making
use of a standard load balancer (as depicted in the
diagram below). This enables us to scale and to have
HA for the DHCP agents. I really like the solution and
it addresses a number of problems and concerns about
the DHCP agents.<br>
<br>
<blockquote type="cite">
<div><br>
</div>
<div>If we were to truly load balance we would need
to keep the state of the DHCP servers in sync
(dynamically) as they would be allocating from a
common pool of resources. That might not be a
problem that we would want to inherit. <br>
</div>
</blockquote>
<br>
Yes, a load balcner maintaining a persistent entry
will ensure that the leasing works correctly. In the
event that a DHCP agent terminates (maintenance,
network issues, excpetion etc.) the the load balcner
will select another active DHCP agent. The advantage
here is that the current implementation has the DHCP
agents all having the relevant host information - i.e.
the routes, ip address and mac address.<br>
<br>
<blockquote type="cite">
<div><br>
</div>
<div>On the other hand, your suggestion to use VRRP
would be a great idea for those use cases where
the L3 agent and the DHCP agent would be
co-located. The problem of keeping the state in
sync would still have to be dealt with but is not
as severe as the load balancing case. <br>
</div>
</blockquote>
<br>
VRRP is a way of providing the high availability. All
off the shelf load balancers today support this. Some
may have their own proprietary ways of performance HA.
This will ensure that the load balancer is not a
single point of failure. Originally I was in favor of
implementing VRRP on the L3 agents but now that the
LBaaS is starting to crystallize this is a far better
solution for the infrastructure and Openstack as a
whole.<br>
<br>
<blockquote type="cite">
<div><br>
</div>
<div>Just my thoughts. </div>
<div>Vinay<br>
<div><br>
<div class="gmail_quote">On Sun, Nov 25, 2012 at
5:56 AM, Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@redhat.com" target="_blank">gkotton@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Hi,<br>
There were two ideas discussed at the
summit the first is the LBaaS and the
second was improvements for the DHCP agent
(multinode). I think that we can leverage
the LBaaS to support a highly available
and robust Quantum DHCP service.<br>
<br>
This can be achieved as follows:<br>
<br>
1. For each network that supports a DHCP
service there will be a VIP for the DHCP
address (this will also have the relevant
health checks etc.)<br>
2. Each DHCP running agent will be
registered as a member (I hope that I have
the terminology correct here). Basically
vip = {dhcps1, dhcps2, ...}<br>
3. All of the DHCP requests and lease
updates will be sent via the VIP for the
DHCP. The load balcner will select a DHCP
server if this is the first time a request
from the client has been made or it will
forward to a existing server entry.<br>
<br>
Please see the diagram below. This will
enable a cluster of hosts on the same
network tenant to get a highly available
DHCP service - the DHCP server IP is the
virtual IP (it is ideal to have an active
backup load balancing pair to ensure HA -
this could either be by VRRP or some
propriatery method that any of the vendors
support). My thinking is that if we can
use this for the first LBaaS integration
example then we are certainly moving in
the right direction and we have killed two
birds with one stone. <br>
<br>
In the example below there will be 2 DHCP
agents. The traffic will be load balanced
by the active load balancer (in an active
back configuration the persistent sessions
will be maintained :)). <br>
<br>
A few minor changes may be required when
Nova receives the DHCP address - we should
return the VIP address. <br>
<br>
<span><Mail Attachment.png></span><br>
<br>
Ideas, comments or thoughts? <br>
<br>
Thanks<span><font color="#888888"><br>
Gary<br>
<br>
</font></span></div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Vinay Bannai<br>
Email: <a href="mailto:vbannai@gmail.com" target="_blank">vbannai@gmail.com</a><br>
Google Voice: <a href="tel:415%20938%207576" value="+14159387576" target="_blank">415 938 7576</a><br>
<br>
</div>
</div>
</blockquote>
<br>
</div>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>
<div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div><br>
</font></span><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Vinay Bannai<br>Email: <a href="mailto:vbannai@gmail.com">vbannai@gmail.com</a><br>Google Voice: 415 938 7576<br><br>
</div></div>