[ovs-dev] [PATCH RFC] OVN: Openstack floating ip support

Ryan Moats rmoats at us.ibm.com
Fri Mar 25 17:15:22 UTC 2016


"dev" <dev-bounces at openvswitch.org> wrote on 03/22/2016 04:19:07 PM:

> From: Chandra Sekhar Vejendla/San Jose/IBM at IBMUS
> To: dev at openvswitch.org
> Date: 03/22/2016 04:19 PM
> Subject: [ovs-dev] [PATCH RFC] OVN: Openstack floating ip support
> Sent by: "dev" <dev-bounces at openvswitch.org>
>
> This patch adds distributed floating ip support for ovn. The assumption
made
> here is that the external network is a single L2 broadcast domain and all
the
> chassis have connectivity to the external network.
>
> 2 new tables are added in the LROUTER pipeline IN_IP_DNAT & IP_IN_SNAT.
> IN_IP_DNAT will modify the dst ip of the packet from floating ip to vm
ip.
> IN_IP_SNAT will modify the src ip of the packet from vm ip to floating
ip.
>
> Rules in IN_IP_DNAT:
> - Priority 100 rule to set the reg2 to 0x1 if dst & src networks are
>   connectected via a router and both the networks are private.
> - Priority 90 rule to modify the dst ip from floating ip to vm ip.
> - Priority 0 rule to go to next table.
>
> Rules in IN_IP_SNAT:
> - Priority 100 rule to skip modifying the src ip when reg2 is set to 0x1
> - Priority 90 rule to modify the src ip from vm ip to floating ip and dst
mac
>   to floating ip port mac if the packet is egressing via the gateway port
> - Priority 50 rule to modify the src ip from vm ip to floating ip
> - Priority 0 rule to go to next table.
>
> Priority 100 rules in IN_IP_DNAT and IN_IP_SNAT serves 2 purposes.
> - Avoid NAT when vms in different LSWITCHES connected via a LROUTER talk
to
>   each other using private ips.
> - When 2 VMs connected to the same LSWITCH or different LSWITCHES
connected
>   via a router try to talk to each other, the dst ip of the packet should
>   first be DNATed and then the src ip should be SNATed.
>
> The initial design was to stage DNAT in the ingress pipeline and the SNAT
in
> the egress pipeline, but now both the stages are in the ingress pipeline.
This
> was done to solve the cases highlighted above [Priority 100 rules]. There
is a
> need to use information from DNAT stage when SNAT is being processed.
This
> would require an explicit register to be burnt to store the information.
>
> Flows modified in the LSWITCH pipeline
>
> Rules in IN_PORT_SEC:
> - Priority 50 rule to allow packets ingressing the LSWITCH router port
>   with a src mac of floating ip port
>
> Rules in ARP_RSP:
> - Priority 150 rule to respond to arp request for floating ip. To prevent
arp
>   responses for floating ip's from all the chassis, "lport" option is set
in
>   the external_id's column of the lflow table. lport will point to
> the vif-id of
>   the vm that is associated with the floating ip. When ovn-controller is
>   processing the flows, if it sees an lport option set in the
external_ids
>   column, it will install this lflow only if the lport is a local port on
the
>   chassis.
>
> Rules in L2_LKUP:
> - Priority 50 rule to set the outport to the lrouter port when the dst
mac
>   matches the floating ip mac
>
> Rules in OUT_PORT_SEC:
> - Priority 50 rule to allow packet egressing the lrouter port with a mac
of a
>   floating ip port.
>
> Had to increase MAX_RESUBMIT_RECURSION from 64 to 96. When 2 VMs
connected
> via vm1->LS->LR->LS->LR->LS->vm2 are trying to talk to each other, the
> resubmits are exceeding the existing 64 limit.
>
> When a floating ip is associated with a VM ip, NB will set the options of
the
> floating ip lport to "fixed-ip-port=<lport of vif>, router-port=<lport of
the
> logical router port".
>
> If you want to try out this patch with openstack, add the following patch
[1]
> to networking-ovn.
>
> [1] https://review.openstack.org/#/c/295547/

I know this is an RFC patch, but I'd really like to see two improvements
w.r.t the documentation:

1. include the needed changes to ovn-northd.8.xml.
2. It looks like the DNAT code is also clearing the inport value and I
didn't find the reason why anywhere - I'm pretty sure I know why, but
confirmation would be good.

Ryan Moats (regXboi)



More information about the dev mailing list