[ovs-dev] [PATCH 7/7] ovn-northd: Logical flows for load balancers.
Guru Shetty
guru at ovn.org
Mon Jul 4 03:17:32 UTC 2016
On 3 July 2016 at 10:24, Ben Pfaff <blp at ovn.org> wrote:
> On Wed, Jun 29, 2016 at 01:17:11AM -0700, Gurucharan Shetty wrote:
> > This commit adds a 'pre_lb' table that sits before 'pre_stateful' table.
> > For packets that need to be load balanced, this table sets reg0[0]
> > to act as a hint for the pre-stateful table to send the packet to
> > the conntrack table for defragmentation.
> >
> > This commit also adds a 'lb' table that sits before 'stateful' table.
> > For packets from established connections, this table sets reg0[2] to
> > indicate to the 'stateful' table that the packet needs to be sent to
> > connection tracking table to just do NAT.
> >
> > In stateful table, packet for a new connection that needs to be load
> balanced
> > is given a ct_lb("$IP_LIST") action.
> >
> > Signed-off-by: Gurucharan Shetty <guru at ovn.org>
>
> This will require a change to the generated flow syntax if you accept my
> suggestion for patch 6.
>
I made that change and also had the schema change (that was reviewed
separately) squashed into this patch.
>
> Is there a way to test this?
>
The load balancing itself via group actions are tested here:
https://github.com/openvswitch/ovs/blob/master/tests/system-traffic.at#L2529
But OVN tests do not exist end to end as unit test framework does not
integrate with conntrack NAT.
One option is to wait for Daniele's userpace NAT work to get merged to add
the tests.
One way that we could test it is to look for specific group flows that get
generated with 'ovs-ofctl dump-groups' without any traffic sent. I can
create a unit test for that as a separate patch.
>
> Acked-by: Ben Pfaff <blp at ovn.org>
>
Thank you, I applied it with the following incremental around documentation
(which I had completely forgotten about, sorry about that. I am happy to
send any incremental documentation fixes if you have any comments. I
thought about sending another version, but I would likely again have
conflict with Numan's DHCP patches).
diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index b8ee106..6bc83ea 100644
--- a/ovn/northd/ovn-northd.8.xml
+++ b/ovn/northd/ovn-northd.8.xml
@@ -252,7 +252,23 @@
before eventually advancing to ingress table <code>ACLs</code>.
</p>
- <h3>Ingress Table 4: Pre-stateful</h3>
+ <h3>Ingress Table 4: Pre-LB</h3>
+
+ <p>
+ This table prepares flows for possible stateful load balancing
processing
+ in ingress table <code>LB</code> and <code>Stateful</code>. It
contains
+ a priority-0 flow that simply moves traffic to the next table. If
load
+ balancing rules with virtual IP addresses (and ports) are configured
in
+ <code>OVN_Northbound</code> database for a logical datapath, a
+ priority-100 flow is added for each configured virtual IP address
+ <var>VIP</var> with a match <code>ip && ip4.dst ==
<var>VIP</var>
+ </code> that sets an action <code>reg0[0] = 1; next;</code> to act
as a
+ hint for table <code>Pre-stateful</code> to send IP packets to the
+ connection tracker for packet de-fragmentation before eventually
+ advancing to ingress table <code>LB</code>.
+ </p>
+
+ <h3>Ingress Table 5: Pre-stateful</h3>
<p>
This table prepares flows for all possible stateful processing
@@ -263,7 +279,7 @@
<code>ct_next;</code> action.
</p>
- <h3>Ingress table 5: <code>from-lport</code> ACLs</h3>
+ <h3>Ingress table 6: <code>from-lport</code> ACLs</h3>
<p>
Logical flows in this table closely reproduce those in the
@@ -312,16 +328,57 @@
</li>
</ul>
- <h3>Ingress Table 6: Stateful</h3>
+ <h3>Ingress Table 7: LB</h3>
<p>
It contains a priority-0 flow that simply moves traffic to the next
- table. A priority-100 flow commits packets to connection tracker
using
- <code>ct_commit; next;</code> action based on a hint provided by
- the previous tables (with a match for <code>reg0[1] == 1</code>).
+ table. For established connections a priority 100 flow matches on
+ <code>ct.est && !ct.rel && !ct.new &&
+ !ct.inv</code> and sets an action <code>reg0[2] = 1; next;</code> to
act
+ as a hint for table <code>Stateful</code> to send packets through
+ connection tracker to NAT the packets. (The packet will
automatically
+ get DNATed to the same IP address as the first packet in that
+ connection.)
</p>
- <h3>Ingress Table 7: ARP responder</h3>
+ <h3>Ingress Table 8: Stateful</h3>
+
+ <ul>
+ <li>
+ For all the configured load balancing rules in
+ <code>OVN_Northbound</code> database that includes a L4 port
+ <var>PORT</var> of protocol <var>P</var> and IPv4 address
+ <var>VIP</var>, a priority-120 flow that matches on
+ <code>ct.new && ip && ip4.dst == <var>VIP
+ </var>&& <var>P</var> && <var>P</var>.dst ==
<var>PORT
+ </var></code> with an action of
<code>ct_lb(<var>args</var>)</code>,
+ where <var>args</var> contains comma separated IPv4 addresses (and
+ optional port numbers) to load balance to.
+ </li>
+ <li>
+ For all the configured load balancing rules in
+ <code>OVN_Northbound</code> database that includes just an IP
address
+ <var>VIP</var> to match on, a priority-110 flow that matches on
+ <code>ct.new && ip && ip4.dst ==
<var>VIP</var></code>
+ with an action of <code>ct_lb(<var>args</var>)</code>, where
+ <var>args</var> contains comma separated IPv4 addresses.
+ </li>
+ <li>
+ A priority-100 flow commits packets to connection tracker using
+ <code>ct_commit; next;</code> action based on a hint provided by
+ the previous tables (with a match for <code>reg0[1] == 1</code>).
+ </li>
+ <li>
+ A priority-100 flow sends the packets to connection tracker using
+ <code>ct_lb;</code> as the action based on a hint provided by the
+ previous tables (with a match for <code>reg0[2] == 1</code>).
+ </li>
+ <li>
+ A priority-0 flow that simply moves traffic to the next table.
+ </li>
+ </ul>
+
+ <h3>Ingress Table 9: ARP responder</h3>
<p>
This table implements ARP responder for known IPs. It contains these
@@ -366,7 +423,7 @@ output;
</li>
</ul>
- <h3>Ingress Table 8: Destination Lookup</h3>
+ <h3>Ingress Table 10: Destination Lookup</h3>
<p>
This table implements switching behavior. It contains these logical
@@ -397,33 +454,50 @@ output;
</li>
</ul>
- <h3>Egress Table 0: <code>to-lport</code> Pre-ACLs</h3>
+ <h3>Egress Table 0: Pre-LB</h3>
+
+ <p>
+ This table is similar to ingress table <code>Pre-LB</code>. It
+ contains a priority-0 flow that simply moves traffic to the next
table.
+ If any load balancing rules exist for the datapath, a priority-100
flow
+ is added with a match of <code>ip</code> and action of <code>reg0[0]
= 1;
+ next;</code> to act as a hint for table <code>Pre-stateful</code> to
+ send IP packets to the connection tracker for packet
de-fragmentation.
+ </p>
+
+ <h3>Egress Table 1: <code>to-lport</code> Pre-ACLs</h3>
<p>
This is similar to ingress table <code>Pre-ACLs</code> except for
<code>to-lport</code> traffic.
</p>
- <h3>Egress Table 1: Pre-stateful</h3>
+ <h3>Egress Table 2: Pre-stateful</h3>
<p>
This is similar to ingress table <code>Pre-stateful</code>.
</p>
- <h3>Egress Table 2: <code>to-lport</code> ACLs</h3>
+ <h3>Egress Table 3: LB</h3>
+ <p>
+ This is similar to ingress table <code>LB</code>.
+ </p>
+
+ <h3>Egress Table 4: <code>to-lport</code> ACLs</h3>
<p>
This is similar to ingress table <code>ACLs</code> except for
<code>to-lport</code> ACLs.
</p>
- <h3>Egress Table 3: Stateful</h3>
+ <h3>Egress Table 5: Stateful</h3>
<p>
- This is similar to ingress table <code>Stateful</code>.
+ This is similar to ingress table <code>Stateful</code> except that
+ there are no rules added for load balancing new connections.
</p>
- <h3>Egress Table 4: Egress Port Security - IP</h3>
+ <h3>Egress Table 6: Egress Port Security - IP</h3>
<p>
This is similar to the port security logic in table
@@ -433,7 +507,7 @@ output;
<code>ip4.src</code> and <code>ip6.src</code>
</p>
- <h3>Egress Table 5: Egress Port Security - L2</h3>
+ <h3>Egress Table 7: Egress Port Security - L2</h3>
>
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
More information about the dev
mailing list