On Fri, Jun 24, 2016 at 4:13 AM, Ben Pfaff <b...@ovn.org> wrote:
> On Wed, Jun 15, 2016 at 02:48:27PM +0530, Numan Siddique wrote:
> > OVN implements a native DHCP support which caters to the common
> > use case of providing an IP address to a booting instance by
> > providing stateless replies to DHCP requests based on statically
> > configured address mappings. To do this it allows a short list of
> > DHCP options to be configured and applied at each compute host
> > running ovn-controller.
> >
> > A new table 'Subnet' is added in OVN NB DB to store the DHCP options.
> >
> > For each logical port following flows are added if the CMS has defined
> > DHCP options in the 'Subnet' column
> >
> > - A logical flow which copies the DHCP options to the DHCP
> > request packets using the 'put_dhcp_opts' action and advances the
> > packet to the next stage.
> >
> > - A logical flow which implements the DHCP reponder by sending
> > the DHCP reply back to the inport once the 'put_dhcp_opts' action
> > is applied.
> >
> > Signed-off-by: Numan Siddique <nusid...@redhat.com>
> > Co-authored-by: Ben Pfaff <b...@ovn.org>
> > Signed-off-by: Ben Pfaff <b...@ovn.org>
>
> I would have expected that whether to enable DHCP and what DHCP options
> to use would be primarily a property of a logical switch port. Thus, I
> would have expected to add DHCP option information to
> Logical_Switch_Port or (since it turns out there's quite a lot of it and
> it's likely to be mostly the same from one port to another) a reference
> from Logical_Switch_Port to a row in some new DHCP_Options table.
>
> I don't know whether I actually object to your design though, because I
> haven't spent much time studying it yet, so I'd like to hear your (and
> others') opinion on the pluses and minuses of each possibility. Can you
> say a little about it?
>
>
Thanks Ben for the review and your comments.
I thought of having a Subnet table and storing DHCP options because
- most of the DHCP options are common to all the logical ports with the
same subnet cidr.
- Open
S
tack neutron has a subnet table and it spawns the "dnsmasq" process to
handle the DHCP requests when the subnet is created. So
thought of following the similar approach.
- and I never thought of the approach you mentioned.
The biggest minus i see with my approach is
- In cases where a logical port wants to override or add new DHCP options,
it has to define it in
the Logical_Switch_Port.options column with the prefix "dhcp_opt_".
Also if the admin wants to disable DHCP on a particular logical port
she has to define "dhcp_disabled" in the options column. This doesn't look
very clean when
compared to the approach you mentioned.
I think the approach you mentioned is more cleaner. All the logical ports
can refer to the same row of
the new DHCP options table. In cases where logical port wants to override,
the logical port can refer to a new row.
With your approach, the CMS has to do a bit more work compared to the first
approach, but I think that
'
s fine.
The couple of comments I could think of with your new approach, not really
sure if they are minus's.
*
When a logical port has more than one IPv4 address with different subnets,
then the new DHCP
option table should
also have a CIDR column, so that ovn-northd can add DHCP logical flow for
only the IPv4 address with matching CIDR column.
I
n which case the table will look very similar to Subnet table but instead
of the Logical_Switch refer
r
ing
to this table, Logical_Ports will refer to it.
Eg, if the logical port has [10.0.0.4, 20.0.0.4] then the new DHCP
options table should have a row
"CIDR": "10.0.0.0/24", "options": {"router=10.0.0.1",
"netmask=255.255.255.0"}
DHCP logical flow with offer_ip=10.0.0.4 will be added
Other approach is for the ovn-northd to look into "router" DHCP option
to figure out what the offer_ip should be.
Eg, if the logical port has [10.0.0.4, 20.0.0.4] and the new DHCP
options table has the row with the below options
"options": { "router=20.0.0.1", "netmask=255.255.255.0"}
DHCP logical flow with offer_ip=20.0.0.4 will be added
*
ovn-northd adds a new logical flow for each subnet of the Logical switch in
the egress pipeline "S_SWITCH_OUT_ACL" to allow the DHCP reply
Eg.
table=1( ls_out_acl), priority=34000, match=(eth.src ==
00:00:00:10:00:01 && ip4.src == 10.0.0.1 && udp && udp.src == 67 && udp.dst
== 68), action=(ct_commit; next;)
With the new approach, a new logical flow per logical port needs to be
added if DHCP is enabled on this port
. W
e can still add only one logical flow per logical switch, but we may have
to iterate over all the logical ports of the logical switch.
I personally feel having one logical flow per subnet is better than having
per logical port.
I am fine taking either approach. Let me know your comments. I can start
working on the new
approach.
Thanks
Numan
> Thanks,
>
> Ben.
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
