dragonflow/doc/source/distributed_dhcp.rst

58 lines
1.8 KiB
ReStructuredText

================
Distributed DHCP
================
Current Neutron Reference Implementation
========================================
The DHCP server is implemented using the Dnsmasq server
running in a namespace on the network-node per tenant subnet
that is configured with DHCP enabled.
Currently High availability is achieved by running multiple Dnsmasq
servers on multiple Network nodes.
There is a namespace with Dnsmasq server per tenant subnet
Problems with current DHCP implementation:
1) Management and Scalability
- Need to configure and mange multiple Dnsmasq instances
2) Centralize solution depended on the network node
DHCP agent
----------
Same Concept as L3 agent and namespaces for virtual router.
Using black boxes that implement functionality and using them as the IaaS
backbone implementation
Distributed DHCP In Dragonflow
==============================
Dragonflow distribute DHCP policy/configuration using the pluggable DB.
Each local controller installs DHCP redirection Openflow rules, to be
handle by the local controller.
Those rules are installed only for local ports that are
attached to a virtual network with DHCP enabled.
The controller set the flow metadata in the redirection rules
to the local port unique key as a hint to allow fast port info lookup
for the reactive DHCP packets handle by the DHCP application.
The local DHCP application handle the redirected DHCP packets and answer as a
DHCP server. DHCP traffic is handled directly at the compute node and never
goes on the network.
The following diagrams demonstrate this process:
.. image:: ../images/dhcp1.jpg
:alt: Distributed DHCP 1
:width: 600
:height: 525
:align: center
.. image:: ../images/dhcp2.jpg
:alt: Distributed DHCP 1
:width: 600
:height: 525
:align: center