Skip to content

Commit

Permalink
ovn: Add support for Load balancers.
Browse files Browse the repository at this point in the history 
This commit adds schema changes to the OVN_Northbound database to support
Load balancers.

In ovn-northd, it adds two logical tables to program logical flows.
It 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.

It 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@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
  • Loading branch information
@shettyg
shettyg committed Jul 4, 2016
1 parent 467085f commit 7a15be6
Show file tree
Hide file tree
Showing 5 changed files with 351 additions and 28 deletions.
104 changes: 89 additions & 15 deletions ovn/northd/ovn-northd.8.xml
View file
Expand Up @@ -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 &amp;&amp; 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
Expand All @@ -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
Expand Down Expand Up @@ -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 &amp;&amp; !ct.rel &amp;&amp; !ct.new &amp;&amp;
!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 &amp;&amp; ip &amp;&amp; ip4.dst == <var>VIP
</var>&amp;&amp; <var>P</var> &amp;&amp; <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 &amp;&amp; ip &amp;&amp; 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
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand All @@ -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>

<p>
This is similar to the ingress port security logic in ingress table
Expand Down

0 comments on commit 7a15be6

Please sign in to comment.