Re: [ovs-dev] [PATCH v4 ovn 0/2] Forwarding group to load balance l2 traffic with liveness detection
Thank you Numan!
On 1/23/20, 11:02 AM, "Numan Siddique" wrote:
On Thu, Jan 23, 2020 at 3:01 AM Manoj Sharma
wrote:
>
> *** BLURB HERE ***
>
> Manoj Sharma (2):
> Re-apply the v3 to resolve the failure reported by 0-day robot.
> A forwarding group is an aggregation of logical switch ports of a
> logical switch to load balance traffic across the ports. It also
> detects the liveness if the logical switch ports are realized as
> OVN tunnel ports on the physical topology.
>
> NEWS | 1 +
> controller/lflow.c| 20
> controller/physical.c | 13 +++
> controller/physical.h | 4 +
> include/ovn/actions.h | 19 +++-
> lib/actions.c | 142 ++
> northd/ovn-northd.8.xml | 49 +
> northd/ovn-northd.c | 64
> ovn-nb.ovsschema | 18 +++-
> ovn-nb.xml| 35 +++
> ovn-sb.xml| 19
> tests/ovn-nbctl.at| 37 +++
> tests/ovn.at | 124 +++
> utilities/ovn-nbctl.8.xml | 38 +++
> utilities/ovn-nbctl.c | 253
++
> utilities/ovn-trace.c | 3 +
> 16 files changed, 836 insertions(+), 3 deletions(-)
Hi Manoj,
Thanks for the patches.. I applied this series to master with the below
changes.
Patch 1 had code which belonged to patch 2. So I moved that to patch 2.
Without this the tests were failing after applying the first patch.
Test cases for fwd_group action were missing in the "action parsing".
I added few cases for that.
Patch 1 changes
diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
index bcb320be9..3628d352b 100644
--- a/northd/ovn-northd.8.xml
+++ b/northd/ovn-northd.8.xml
@@ -766,45 +766,6 @@ output;
-
-
- For each VIP configured in the table
-
- a priority-50 logical flow is added with the match
- arp.tpa == vip && && arp.op == 1
- and applies the action
-
-
-
-eth.dst = eth.src;
-eth.src = E;
-arp.op = 2; /* ARP reply. */
-arp.tha = arp.sha;
-arp.sha = E;
-arp.tpa = arp.spa;
-arp.spa = A;
-outport = inport;
-flags.loopback = 1;
-output;
-
-
-
- where E is the forwarding group's mac defined in
- the .
-
-
-
- A is used as either the destination ip for load
balancing
- traffic to child ports or as nexthop to hosts behind the child
ports.
-
-
-
- These flows are required to respond to an ARP request if an ARP
- request is sent for the IP vip.
-
-
-
One priority-0 fallback flow that matches all packets and advances
to
the next table.
@@ -1192,16 +1153,6 @@ output;
address is only programmed on the
redirect-chassis.
-
-
- For each forwarding group configured on the logical switch
datapath,
- a priority-50 flow that matches on eth.dst ==
VIP
- with an action of fwd_group(childports=args
- ), where args contains comma separated
- logical switch child ports to load balance to.
- If liveness is enabled, then action also includes
- liveness=true.
-
diff --git a/ovn-nb.ovsschema b/ovn-nb.ovsschema
index 99b62859f..7d969fb58 100644
--- a/ovn-nb.ovsschema
+++ b/ovn-nb.ovsschema
@@ -1,7 +1,7 @@
{
"name": "OVN_Northbound",
-"version": "5.18.0",
-"cksum": "63300136 24879",
+"version": "5.19.0",
+"cksum": "4258826789 24879",
"tables": {
"NB_Global": {
"columns": {
diff --git a/ovn-sb.xml b/ovn-sb.xml
index 93bbb8618..9635dcc1d 100644
--- a/ovn-sb.xml
+++ b/ovn-sb.xml
@@ -1957,25 +1957,6 @@
-
-fwd_group(P);
-
-
-Parameters: liveness, list of child ports P.
-
-
-
-It load balances traffic to one or more child ports in a
-logical switch. ovn-controller translates the
-
[ovs-dev] [PATCH v4 ovn 1/2] Forwarding group to load balance l2 traffic with liveness detection
Add a forwarding group table and a reference to the logical switch it is
configured on. The forwarding group is configured with a virtual IP, virtual
MAC and a number of logical switch ports from a logical switch.
Unit tests for the forwarding group.
Signed-off-by: Manoj Sharma
---
NEWS | 1 +
northd/ovn-northd.8.xml | 49 +
ovn-nb.ovsschema | 18 +++-
ovn-nb.xml| 35 +++
ovn-sb.xml| 19
tests/ovn-nbctl.at| 37 +++
tests/ovn.at | 124 +++
utilities/ovn-nbctl.8.xml | 38 +++
utilities/ovn-nbctl.c | 253 ++
9 files changed, 572 insertions(+), 2 deletions(-)
diff --git a/NEWS b/NEWS
index 0ad9677..9e7d601 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,7 @@ Post-OVS-v2.12.0
independently.
- Added IPv6 NAT support for OVN routers.
- Added Stateless Floating IP support in OVN.
+ - Added Forwarding Group support in OVN.
v2.12.0 - 03 Sep 2019
-
diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
index 3628d35..bcb320b 100644
--- a/northd/ovn-northd.8.xml
+++ b/northd/ovn-northd.8.xml
@@ -767,6 +767,45 @@ output;
+
+ For each VIP configured in the table
+
+ a priority-50 logical flow is added with the match
+ arp.tpa == vip && && arp.op == 1
+ and applies the action
+
+
+
+eth.dst = eth.src;
+eth.src = E;
+arp.op = 2; /* ARP reply. */
+arp.tha = arp.sha;
+arp.sha = E;
+arp.tpa = arp.spa;
+arp.spa = A;
+outport = inport;
+flags.loopback = 1;
+output;
+
+
+
+ where E is the forwarding group's mac defined in
+ the .
+
+
+
+ A is used as either the destination ip for load balancing
+ traffic to child ports or as nexthop to hosts behind the child ports.
+
+
+
+ These flows are required to respond to an ARP request if an ARP
+ request is sent for the IP vip.
+
+
+
+
One priority-0 fallback flow that matches all packets and advances to
the next table.
@@ -1153,6 +1192,16 @@ output;
address is only programmed on the redirect-chassis.
+
+
+ For each forwarding group configured on the logical switch datapath,
+ a priority-50 flow that matches on eth.dst == VIP
+ with an action of fwd_group(childports=args
+ ), where args contains comma separated
+ logical switch child ports to load balance to.
+ If liveness is enabled, then action also includes
+ liveness=true.
+
diff --git a/ovn-nb.ovsschema b/ovn-nb.ovsschema
index 12999a4..99b6285 100644
--- a/ovn-nb.ovsschema
+++ b/ovn-nb.ovsschema
@@ -1,7 +1,7 @@
{
"name": "OVN_Northbound",
"version": "5.18.0",
-"cksum": "2806349485 24196",
+"cksum": "63300136 24879",
"tables": {
"NB_Global": {
"columns": {
@@ -59,7 +59,12 @@
"min": 0, "max": "unlimited"}},
"external_ids": {
"type": {"key": "string", "value": "string",
- "min": 0, "max": "unlimited"}}},
+ "min": 0, "max": "unlimited"}},
+ "forwarding_groups": {
+"type": {"key": {"type": "uuid",
+ "refTable": "Forwarding_Group",
+ "refType": "strong"},
+ "min": 0, "max": "unlimited"}}},
"isRoot": true},
"Logical_Switch_Port": {
"columns": {
@@ -113,6 +118,15 @@
"min": 0, "max": "unlimited"}}},
"indexes": [["name"]],
"isRoot": false},
+"Forwarding_Group": {
+"columns": {
+"name": {"type": "string"},
+"vip": {"type": "string"},
+"vmac": {"type": "string"},
+"liveness": {"type": "boolean"},
+"child_port": {"type": {"key": "string",
+"min": 1, &q
[ovs-dev] [PATCH v4 ovn 2/2] Forwarding group to load balance l2 traffic with liveness detection
A forwarding group is an aggregation of logical switch ports of a logical switch to load balance traffic across the ports. It also detects the liveness if the logical switch ports are realized as OVN tunnel ports on the physical topology. In the below logical topology diagram, the logical switch has two ports connected to chassis / external routers R1 and R2. The logical router needs to send traffic to an external network that is connected through R1 and R2. ++ +--+ R1 |* / ++ ** ** +--++--+ / lsp1 * * | Logical || Logical|/ * External * | Router ++ switch X* Network * | || |\ * * +--++--+ \ lsp2 * * ^ \ ++ ** ** | +--+ R2 |* | ++ fwd_group -> (lsp1, lsp2) In the absence of forwarding group, the logical router will have unicast route to point to either R1 or R2. In case of R1 or R2 going down, it will require control plane's intervention to update the route to point to proper nexthop. With forwarding group, a virtual IP (VIP) and virtual MAC (VMAC) address are configured on the forwarding group. The logical router points to the forwarding group's VIP as the nexthop for hosts behind R1 and R2. [root@fwd-group]# ovn-nbctl fwd-group-add fwd ls1 VIP_1 VMAC_1 lsp1 lsp2 [root@fwd-group]# ovn-nbctl fwd-group-list FWD_GROUP LSVIP VMAC CHILD_PORTS fwd ls1 VIP_1 VMAC_1 lsp1 lsp2 [root@fwd-group]# ovn-nbctl lr-route-list lr1 IPv4 Routes external_host_prefix/prefix_lenVIP_1 dst-ip The logical switch will install an ARP responder rule to reply with VMAC as the MAC address for ARP requests for VIP. It will also install a MAC lookup rule for VMAC with action to load balance across the logical switch ports of the forwarding group. Datapath: "ls1" Pipeline: ingress table=10(ls_in_arp_rsp ), priority=50 , match=(arp.tpa == VIP_1 && arp.op == 1), action=(eth.dst = eth.src; eth.src = VMAC_1; arp.op = 2; /* ARP reply */ arp.tha = arp.sha; arp.sha = VMAC_1; arp.tpa = arp.spa; arp.spa = VIP; outport = inport; flags.loopback = 1; output;) table=13(ls_in_l2_lkup ), priority=50 , match=(eth.dst == VMAC_1), action=(fwd_group(childports="lsp1","lsp2");) In the physical topology, OVN managed hypervisors are connected to R1 and R2 through overlay tunnels. The logical flow's "fwd_group" action mentioned above, gets translated to openflow group type "select" with one bucket for each logical switch port. cookie=0x0, duration=16.869s, table=29, n_packets=4, n_bytes=392, idle_age=0, priority=111,metadata=0x9,dl_dst=VMAC_1 actions=group:1 group_id=1,type=select,selection_method=dp_hash, bucket=actions=load:0x2->NXM_NX_REG15[0..15], resubmit(,32), bucket=actions=load:0x3->NXM_NX_REG15[0..15],resubmit(,32) where 0x2 and 0x3 are port tunnel keys of lsp1 and lsp2. The openflow group type "select" with selection method "dp_hash" load balances traffic based on source and destination Ethernet address, VLAN ID, Ethernet type, IPv4/v6 source and destination address and protocol, and for TCP and SCTP only, the source and destination ports. To detect path failure between OVN managed hypervisors and (R1, R2), BFD is enabled on the tunnel interfaces. The openflow group is modified to include watch_port for liveness detection of a port. The forwarding group must be configured with --liveness to enable it. With liveness enabled, the logical flow changes to: table=13(ls_in_l2_lkup ), priority=50 , match=(eth.dst == VMAC_1), action=(fwd_group(liveness="true",childports="lsp1","lsp2");) While the openflow group is: group_id=1,type=select,selection_method=dp_hash, bucket=watch_port:31,actions=load:0x2->NXM_NX_REG15[0..15],resubmit(,32), bucket=watch_port:32,actions=load:0x3->NXM_NX_REG15[0..15],resubmit(,32) Where 31 and 32 are ovs port numbers for the tunnel interfaces connecting to R1 and R2. If the BFD forwarding status is down for any of the tunnels, the corresponding bucket will not be selected for packet forwarding. Signed-off-by: Manoj Sharma --- controller/lflow.c| 20 +++ controller/physical.c | 13 + controller/physical.h | 4 ++ include/ovn/actions.h | 19 ++- lib/actions.c | 142 ++ northd/o
[ovs-dev] [PATCH v4 ovn 0/2] Forwarding group to load balance l2 traffic with liveness detection
*** BLURB HERE *** Manoj Sharma (2): Re-apply the v3 to resolve the failure reported by 0-day robot. A forwarding group is an aggregation of logical switch ports of a logical switch to load balance traffic across the ports. It also detects the liveness if the logical switch ports are realized as OVN tunnel ports on the physical topology. NEWS | 1 + controller/lflow.c| 20 controller/physical.c | 13 +++ controller/physical.h | 4 + include/ovn/actions.h | 19 +++- lib/actions.c | 142 ++ northd/ovn-northd.8.xml | 49 + northd/ovn-northd.c | 64 ovn-nb.ovsschema | 18 +++- ovn-nb.xml| 35 +++ ovn-sb.xml| 19 tests/ovn-nbctl.at| 37 +++ tests/ovn.at | 124 +++ utilities/ovn-nbctl.8.xml | 38 +++ utilities/ovn-nbctl.c | 253 ++ utilities/ovn-trace.c | 3 + 16 files changed, 836 insertions(+), 3 deletions(-) -- 1.8.3.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 ovn 1/3] Forwarding group to load balance l2 traffic with liveness detection
Hi Numan,
I sent v3 just now. Please take a look.
Some of the issues reported by checkpatch can not be avoided. I fixed whatever
could be broken into two lines.
The warnings below are for ‘-‘ in fwd-group-add/del.
Thanks,
Manoj
From: Numan Siddique
Date: Thursday, January 16, 2020 at 7:36 AM
To: Manoj Sharma
Cc: "ovs-dev@openvswitch.org"
Subject: Re: [ovs-dev] [PATCH v2 ovn 1/3] Forwarding group to load balance l2
traffic with liveness detection
On Sat, Jan 11, 2020 at 6:11 AM Manoj Sharma
mailto:manoj.sha...@nutanix.com>> wrote:
Add a forwarding group table and a reference to the logical switch it is
configured on. The forwarding group is configured with a virtual IP, virtual
MAC and a number of logical switch ports from a logical switch.
Signed-off-by: Manoj Sharma
mailto:manoj.sha...@nutanix.com>>
This patch has below checkpatch issues. Can you please fix them.
== Checking 198cdb9bab38 ("Forwarding group to load balance l2 traffic with
liveness detection") ==
WARNING: Line is 149 characters long (recommended limit is 79)
#125 FILE: utilities/ovn-nbctl.8.xml:489:
[--liveness]fwd-group-add group
switch vip vmac ports
WARNING: Line is 85 characters long (recommended limit is 79)
#146 FILE: utilities/ovn-nbctl.8.xml:510:
[--if-exists] fwd-group-del
group
WARNING: Line lacks whitespace around operator
#172 FILE: utilities/ovn-nbctl.c:653:
fwd-group-add GROUP SWITCH VIP VMAC PORTS...\n\
WARNING: Line lacks whitespace around operator
#174 FILE: utilities/ovn-nbctl.c:655:
fwd-group-del GROUP delete a forwarding group\n\
WARNING: Line lacks whitespace around operator
#175 FILE: utilities/ovn-nbctl.c:656:
fwd-group-list [SWITCH] print forwarding groups\n\
ERROR: Improper whitespace around control block
#196 FILE: utilities/ovn-nbctl.c:4742:
NBREC_FORWARDING_GROUP_FOR_EACH(fwd_group, ctx->idl) {
ERROR: Improper whitespace around control block
#392 FILE: utilities/ovn-nbctl.c:4938:
NBREC_FORWARDING_GROUP_FOR_EACH(fwd_group, ctx->idl) {
**
I think you can ignore the warnings in ovn-nbctl.c.
You can run these checks your self - "utilities/checkpatch.py -1"
You need to bump up the version in ovn-nb.ovsschema to 5.19.0
Also please move the relevant test cases from patch 3 to this one.
Thanks
Numan
---
ovn-nb.ovsschema | 18 +++-
ovn-nb.xml| 35 +++
utilities/ovn-nbctl.8.xml | 37 +++
utilities/ovn-nbctl.c | 253 ++
4 files changed, 341 insertions(+), 2 deletions(-)
diff --git a/ovn-nb.ovsschema b/ovn-nb.ovsschema
index 12999a4..99b6285 100644
--- a/ovn-nb.ovsschema
+++ b/ovn-nb.ovsschema
@@ -1,7 +1,7 @@
{
"name": "OVN_Northbound",
"version": "5.18.0",
-"cksum": "2806349485 24196",
+"cksum": "63300136 24879",
"tables": {
"NB_Global": {
"columns": {
@@ -59,7 +59,12 @@
"min": 0, "max": "unlimited"}},
"external_ids": {
"type": {"key": "string", "value": "string",
- "min": 0, "max": "unlimited"}}},
+ "min": 0, "max": "unlimited"}},
+ "forwarding_groups": {
+"type": {"key": {"type": "uuid",
+ "refTable": "Forwarding_Group",
+ "refType": "strong"},
+ "min": 0, "max": "unlimited"}}},
"isRoot": true},
"Logical_Switch_Port": {
"columns": {
@@ -113,6 +118,15 @@
"min": 0, "max": "unlimited"}}},
"indexes": [["name"]],
"isRoot": false},
+"Forwarding_Group": {
+"columns": {
+"name": {"type": "string"},
+"vip": {"type": "string"},
+"vmac": {"type": "string"},
+"liveness": {"type": "boolean"},
+"child_port": {"type": {"key": "string",
+"min": 1, "max": "unlimited"}}},
+"isRoot": false},
"Address_Set": {
"columns": {
"name": {"t
[ovs-dev] [PATCH v3 ovn 2/2] Forwarding group to load balance l2 traffic with liveness detection
A forwarding group is an aggregation of logical switch ports of a logical switch to load balance traffic across the ports. It also detects the liveness if the logical switch ports are realized as OVN tunnel ports on the physical topology. In the below logical topology diagram, the logical switch has two ports connected to chassis / external routers R1 and R2. The logical router needs to send traffic to an external network that is connected through R1 and R2. ++ +--+ R1 |* / ++ ** ** +--++--+ / lsp1 * * | Logical || Logical|/ * External * | Router ++ switch X* Network * | || |\ * * +--++--+ \ lsp2 * * ^ \ ++ ** ** | +--+ R2 |* | ++ fwd_group -> (lsp1, lsp2) In the absence of forwarding group, the logical router will have unicast route to point to either R1 or R2. In case of R1 or R2 going down, it will require control plane's intervention to update the route to point to proper nexthop. With forwarding group, a virtual IP (VIP) and virtual MAC (VMAC) address are configured on the forwarding group. The logical router points to the forwarding group's VIP as the nexthop for hosts behind R1 and R2. [root@fwd-group]# ovn-nbctl fwd-group-add fwd ls1 VIP_1 VMAC_1 lsp1 lsp2 [root@fwd-group]# ovn-nbctl fwd-group-list FWD_GROUP LSVIP VMAC CHILD_PORTS fwd ls1 VIP_1 VMAC_1 lsp1 lsp2 [root@fwd-group]# ovn-nbctl lr-route-list lr1 IPv4 Routes external_host_prefix/prefix_lenVIP_1 dst-ip The logical switch will install an ARP responder rule to reply with VMAC as the MAC address for ARP requests for VIP. It will also install a MAC lookup rule for VMAC with action to load balance across the logical switch ports of the forwarding group. Datapath: "ls1" Pipeline: ingress table=10(ls_in_arp_rsp ), priority=50 , match=(arp.tpa == VIP_1 && arp.op == 1), action=(eth.dst = eth.src; eth.src = VMAC_1; arp.op = 2; /* ARP reply */ arp.tha = arp.sha; arp.sha = VMAC_1; arp.tpa = arp.spa; arp.spa = VIP; outport = inport; flags.loopback = 1; output;) table=13(ls_in_l2_lkup ), priority=50 , match=(eth.dst == VMAC_1), action=(fwd_group(childports="lsp1","lsp2");) In the physical topology, OVN managed hypervisors are connected to R1 and R2 through overlay tunnels. The logical flow's "fwd_group" action mentioned above, gets translated to openflow group type "select" with one bucket for each logical switch port. cookie=0x0, duration=16.869s, table=29, n_packets=4, n_bytes=392, idle_age=0, priority=111,metadata=0x9,dl_dst=VMAC_1 actions=group:1 group_id=1,type=select,selection_method=dp_hash, bucket=actions=load:0x2->NXM_NX_REG15[0..15], resubmit(,32), bucket=actions=load:0x3->NXM_NX_REG15[0..15],resubmit(,32) where 0x2 and 0x3 are port tunnel keys of lsp1 and lsp2. The openflow group type "select" with selection method "dp_hash" load balances traffic based on source and destination Ethernet address, VLAN ID, Ethernet type, IPv4/v6 source and destination address and protocol, and for TCP and SCTP only, the source and destination ports. To detect path failure between OVN managed hypervisors and (R1, R2), BFD is enabled on the tunnel interfaces. The openflow group is modified to include watch_port for liveness detection of a port. The forwarding group must be configured with --liveness to enable it. With liveness enabled, the logical flow changes to: table=13(ls_in_l2_lkup ), priority=50 , match=(eth.dst == VMAC_1), action=(fwd_group(liveness="true",childports="lsp1","lsp2");) While the openflow group is: group_id=1,type=select,selection_method=dp_hash, bucket=watch_port:31,actions=load:0x2->NXM_NX_REG15[0..15],resubmit(,32), bucket=watch_port:32,actions=load:0x3->NXM_NX_REG15[0..15],resubmit(,32) Where 31 and 32 are ovs port numbers for the tunnel interfaces connecting to R1 and R2. If the BFD forwarding status is down for any of the tunnels, the corresponding bucket will not be selected for packet forwarding. Signed-off-by: Manoj Sharma --- controller/lflow.c| 20 +++ controller/physical.c | 13 + controller/physical.h | 4 ++ include/ovn/actions.h | 19 ++- lib/actions.c | 142 ++ northd/o
[ovs-dev] [PATCH v3 ovn 1/2] Forwarding group to load balance l2 traffic with liveness detection
Add a forwarding group table and a reference to the logical switch
it is configured on. The forwarding group is configured with a virtual
IP, virtual MAC and a number of logical switch ports from a logical
switch. Unit tests for the forwarding group.
Signed-off-by: Manoj Sharma
---
NEWS | 1 +
northd/ovn-northd.8.xml | 49 +
ovn-nb.ovsschema | 18 +++-
ovn-nb.xml| 35 +++
ovn-sb.xml| 19
tests/ovn-nbctl.at| 37 +++
tests/ovn.at | 124 +++
utilities/ovn-nbctl.8.xml | 38 +++
utilities/ovn-nbctl.c | 253 ++
9 files changed, 572 insertions(+), 2 deletions(-)
diff --git a/NEWS b/NEWS
index 0ad9677..9e7d601 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,7 @@ Post-OVS-v2.12.0
independently.
- Added IPv6 NAT support for OVN routers.
- Added Stateless Floating IP support in OVN.
+ - Added Forwarding Group support in OVN.
v2.12.0 - 03 Sep 2019
-
diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
index 4b227ca..47ec328 100644
--- a/northd/ovn-northd.8.xml
+++ b/northd/ovn-northd.8.xml
@@ -767,6 +767,45 @@ output;
+
+ For each VIP configured in the table
+
+ a priority-50 logical flow is added with the match
+ arp.tpa == vip && && arp.op == 1
+ and applies the action
+
+
+
+eth.dst = eth.src;
+eth.src = E;
+arp.op = 2; /* ARP reply. */
+arp.tha = arp.sha;
+arp.sha = E;
+arp.tpa = arp.spa;
+arp.spa = A;
+outport = inport;
+flags.loopback = 1;
+output;
+
+
+
+ where E is the forwarding group's mac defined in
+ the .
+
+
+
+ A is used as either the destination ip for load balancing
+ traffic to child ports or as nexthop to hosts behind the child ports.
+
+
+
+ These flows are required to respond to an ARP request if an ARP
+ request is sent for the IP vip.
+
+
+
+
One priority-0 fallback flow that matches all packets and advances to
the next table.
@@ -1153,6 +1192,16 @@ output;
address is only programmed on the redirect-chassis.
+
+
+ For each forwarding group configured on the logical switch datapath,
+ a priority-50 flow that matches on eth.dst == VIP
+ with an action of fwd_group(childports=args
+ ), where args contains comma separated
+ logical switch child ports to load balance to.
+ If liveness is enabled, then action also includes
+ liveness=true.
+
diff --git a/ovn-nb.ovsschema b/ovn-nb.ovsschema
index 12999a4..99b6285 100644
--- a/ovn-nb.ovsschema
+++ b/ovn-nb.ovsschema
@@ -1,7 +1,7 @@
{
"name": "OVN_Northbound",
"version": "5.18.0",
-"cksum": "2806349485 24196",
+"cksum": "63300136 24879",
"tables": {
"NB_Global": {
"columns": {
@@ -59,7 +59,12 @@
"min": 0, "max": "unlimited"}},
"external_ids": {
"type": {"key": "string", "value": "string",
- "min": 0, "max": "unlimited"}}},
+ "min": 0, "max": "unlimited"}},
+ "forwarding_groups": {
+"type": {"key": {"type": "uuid",
+ "refTable": "Forwarding_Group",
+ "refType": "strong"},
+ "min": 0, "max": "unlimited"}}},
"isRoot": true},
"Logical_Switch_Port": {
"columns": {
@@ -113,6 +118,15 @@
"min": 0, "max": "unlimited"}}},
"indexes": [["name"]],
"isRoot": false},
+"Forwarding_Group": {
+"columns": {
+"name": {"type": "string"},
+"vip": {"type": "string"},
+"vmac": {"type": "string"},
+"liveness": {"type": "boolean"},
+"child_port": {"type": {"key": "string",
+"min": 1, &q
[ovs-dev] [PATCH v3 ovn 0/2] Forwarding group to load balance l2 traffic with liveness detection
*** BLURB HERE *** Manoj Sharma (2): Add a forwarding group table and a reference to the logical switch it is configured on. The forwarding group is configured with a virtual IP, virtual MAC and a number of logical switch ports from a logical switch. Unit tests for the forwarding group. A forwarding group is an aggregation of logical switch ports of a logical switch to load balance traffic across the ports. It also detects the liveness if the logical switch ports are realized as OVN tunnel ports on the physical topology. NEWS | 1 + controller/lflow.c| 20 controller/physical.c | 13 +++ controller/physical.h | 4 + include/ovn/actions.h | 19 +++- lib/actions.c | 142 ++ northd/ovn-northd.8.xml | 49 + northd/ovn-northd.c | 64 ovn-nb.ovsschema | 18 +++- ovn-nb.xml| 35 +++ ovn-sb.xml| 19 tests/ovn-nbctl.at| 37 +++ tests/ovn.at | 124 +++ utilities/ovn-nbctl.8.xml | 38 +++ utilities/ovn-nbctl.c | 253 ++ utilities/ovn-trace.c | 3 + 16 files changed, 836 insertions(+), 3 deletions(-) -- 1.8.3.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 ovn 2/3] Forwarding group to load balance l2 traffic with liveness detection
Hi Numan,
Please see my answers inline.
From: Numan Siddique
Date: Thursday, January 16, 2020 at 7:53 AM
To: Manoj Sharma
Cc: "ovs-dev@openvswitch.org"
Subject: Re: [ovs-dev] [PATCH v2 ovn 2/3] Forwarding group to load balance l2
traffic with liveness detection
On Sat, Jan 11, 2020 at 6:11 AM Manoj Sharma
mailto:manoj.sha...@nutanix.com>> wrote:
Add forwarding group support for a logical switch. It will add a new OVN
action "fwd_group" with a virtual IP and virtual MAC. Any number of logical
switch ports of this switch can be added to this forwarding group.
If traffic has to be load balanced across these logical switch ports then
traffic should be sent to forwarding group's virtual IP.
If the logical switch ports correspond to tunnel interfaces and BFD
can be enabled on these tunnel interfaces, then liveness can be enabled
for the forwarding group so that if any of the tunnel is down then
the corresponding logical switch port will not be selected during
load balancing.
Signed-off-by: Manoj Sharma
mailto:manoj.sha...@nutanix.com>>
Hi Manoj,
As I mentioned in the earlier email, please add the detailed description in
patch 0 to this patch.
How about defining the action - fwd_group as - fwd_group(liveliness=true,
childports=p1,p2,...) ?
Normally in the OVN action, we use ";" for inner OpenFlow actions, but these
are more like arguments
to the action - fwd_group.
Thank you for the suggestion. I am sending the new changes in v3.
In your setup, you would manually set the child port's chassis yourself ?
i.e ovn-sbctl lsp-bindright ?
Yes, if the chassis is not running ovn-controller.
You need to add the relevant documentation in ovn-northd.8.xml for the logical
flows added
You need to add documentation for the action - fwd_group in ovn-sb.xml.
Also please update the NEWS file about this feature.
Done
Please see below for few comments.
---
controller/lflow.c| 20 +
controller/physical.c | 13 ++
controller/physical.h | 4 ++
include/ovn/actions.h | 19 +++-
lib/actions.c | 122 ++
northd/ovn-northd.c | 63 ++
utilities/ovn-trace.c | 3 ++
7 files changed, 243 insertions(+), 1 deletion(-)
diff --git a/controller/lflow.c b/controller/lflow.c
index a689320..49dfa06 100644
--- a/controller/lflow.c
+++ b/controller/lflow.c
@@ -103,6 +103,25 @@ lookup_port_cb(const void *aux_, const char *port_name,
unsigned int *portp)
return false;
}
+/* Given the OVN port name, get its openflow port */
+static bool
+tunnel_ofport_cb(const void *aux_, const char *port_name, ofp_port_t *ofport)
+{
+const struct lookup_port_aux *aux = aux_;
+
+const struct sbrec_port_binding *pb
+= lport_lookup_by_name(aux->sbrec_port_binding_by_name, port_name);
+if (!pb || (pb->datapath != aux->dp) || !pb->chassis) {
+return false;
+}
+
+if (!get_tunnel_ofport(pb->chassis->name, NULL, ofport)) {
+return false;
+}
+
+return true;
+}
+
static bool
is_chassis_resident_cb(const void *c_aux_, const char *port_name)
{
@@ -681,6 +700,7 @@ consider_logical_flow(
struct ofpbuf ofpacts = OFPBUF_STUB_INITIALIZER(ofpacts_stub);
struct ovnact_encode_params ep = {
.lookup_port = lookup_port_cb,
+.tunnel_ofport = tunnel_ofport_cb,
.aux = &aux,
.is_switch = is_switch(ldp),
.group_table = group_table,
diff --git a/controller/physical.c b/controller/physical.c
index 500d419..af1d10f 100644
--- a/controller/physical.c
+++ b/controller/physical.c
@@ -1794,3 +1794,16 @@ physical_run(struct ovsdb_idl_index
*sbrec_port_binding_by_name,
simap_destroy(&new_tunnel_to_ofport);
}
+
+bool
+get_tunnel_ofport(const char *chassis_name, char *encap_ip, ofp_port_t *ofport)
+{
+struct chassis_tunnel *tun = NULL;
+tun = chassis_tunnel_find(chassis_name, encap_ip);
+if (!tun) {
+return false;
+}
+
+*ofport = tun->ofport;
+return true;
+}
diff --git a/controller/physical.h b/controller/physical.h
index c93f6b1..c0e17cd 100644
--- a/controller/physical.h
+++ b/controller/physical.h
@@ -72,4 +72,8 @@ void physical_handle_mc_group_changes(
const struct simap *ct_zones,
const struct hmap *local_datapaths,
struct ovn_desired_flow_table *);
+bool get_tunnel_ofport(
+const char *chassis_name,
+char *encap_ip,
+ofp_port_t *ofport);
#endif /* controller/physical.h */
diff --git a/include/ovn/actions.h b/include/ovn/actions.h
index 047a8d7..2d39239 100644
--- a/include/ovn/actions.h
+++ b/include/ovn/actions.h
@@ -89,7 +89,8 @@ struct ovn_extend_table;
OVNACT(CHECK_PKT_LARGER, ovnact_check_pkt_larger) \
OVNACT(TRIGGER_EVENT, ovnact_controller_event) \
OVNACT(BIND_VPORT,ovnact_bind_vport) \
-OVNACT(HANDLE_SVC_CHECK, ovnact_handle
Re: [ovs-dev] [PATCH v1 ovn 0/1] Forwarding group to load balance l2 traffic with liveness detection
Hi Numan, Please see my answers inline: On 1/13/20, 11:37 PM, "Numan Siddique" wrote: On Sat, Jan 11, 2020 at 6:31 AM Manoj Sharma wrote: > > Thank you for the review Numan. > > On 1/8/20, 11:14 PM, "Numan Siddique" wrote: > > Hi Manoj, > > Thanks for the patch. I didn't look into the complete patch. I have > initial few comments. > > The patch fails to compile when --enable-Werror and --enable-sparse > are enabled during configuration. > > I sent the v2 that has the fix for the compilation issue. Thanks for v2. I will take a look at it. I have few follow up questions. > > Can you please include the description in Patch 0 in the actual patch > commit message ? > The commit message in the patch doesn't have much details. > > Done > > In your above description, does the logical switch (with logical ports > lsp1 and lsp2) has a localnet port ? > > It does not matter if the switch has localnet port or not. You are only putting > the logical switch ports in an openflow group so that traffic can be load balanced > across them. > > I am confused how the packet goes out of the logical switch to the > external network ? > Does lsp1 and lsp2 bound to any VM/VIF ? > > From the test case you have written I see that lsp21 and lsp22 are > part of forward group and they > have VIF ports as well. So the packet destined to the VIP will be > delivered to one of the VIF ? > And the VIF/VM takes care of sending the traffic to external routers ? > > We can model an external router as an OVN chassis. For HA, you will need more than one external router > and bind the lsp1 and lsp2 to these chassis (lsp1 <> chassis1, lsp2 <> chassis2). If we want > to load balance across these external routers then just send the traffic to the VIP. Does ovn-controller run on these external router hosts ? I presume so, otherwise there will be no chassis entry in the SB Chassis table. I am curious on how the packet will go out of br-int ? It's not necessary to run ovn-controller on these external appliances. It can be any device, outside OVN also. Yes, you need an entry in the chassis table for it. I will give an example of how it can be used. Let's assume that there are two external hosts "ext_rtr1", and "ext_rtr2". We add these hosts in the chassis table by : "ovn-sbctl chassis-add ext_rtr1 ENCAP-TYPE ENCAP-IP" and "ovn-sbctl chassis-add ext_rtr2 ENCAP-TYPE ENCAP-IP". I have a logical switch "ext-ls" with one port for connecting to each of these chassis : "ovn-sbctl lsp-bind ext-lsp1 ext_rtr1" and "ovn-sbctl lsp-bind ext-lsp2 ext_rtr2". You can configure a fwd group on "ext_ls" with "ext_lsp1" and "ext_lsp2" as child ports and load balance traffic to these two external hosts. With liveness enabled, if any of the hosts goes down, traffic will stop getting forwarded to it automatically. You must be aware that we already have native load balancer feature in OVN which does almost exactly the same thing. The forward groups you proposed here and the OVN load balancer uses the same mechanism. But probably load balancer don't use BFD mechanism to check the liveliness. Can the native load balancer be used instead ? It does have health check feature now. If it's possible, then definitely I would avoid adding forward groups. The native load balancer can not be used with non-ovn appliance where BFD is the most common mechanism to detect liveness. Also I see forwarding group more of a LAG/bond interface at the logical switch. Thanks, Manoj ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v1 ovn 0/1] Forwarding group to load balance l2 traffic with liveness detection
Thank you for the review Numan. On 1/8/20, 11:14 PM, "Numan Siddique" wrote: Hi Manoj, Thanks for the patch. I didn't look into the complete patch. I have initial few comments. The patch fails to compile when --enable-Werror and --enable-sparse are enabled during configuration. I sent the v2 that has the fix for the compilation issue. Can you please include the description in Patch 0 in the actual patch commit message ? The commit message in the patch doesn't have much details. Done In your above description, does the logical switch (with logical ports lsp1 and lsp2) has a localnet port ? It does not matter if the switch has localnet port or not. You are only putting the logical switch ports in an openflow group so that traffic can be load balanced across them. I am confused how the packet goes out of the logical switch to the external network ? Does lsp1 and lsp2 bound to any VM/VIF ? From the test case you have written I see that lsp21 and lsp22 are part of forward group and they have VIF ports as well. So the packet destined to the VIP will be delivered to one of the VIF ? And the VIF/VM takes care of sending the traffic to external routers ? We can model an external router as an OVN chassis. For HA, you will need more than one external router and bind the lsp1 and lsp2 to these chassis (lsp1 <> chassis1, lsp2 <> chassis2). If we want to load balance across these external routers then just send the traffic to the VIP. Since I also wanted to include --liveness in the unit tests, I put the VIFs, bound to lsp1 and lsp2, on different hypervisors so that there is a tunnel interface from the source hypervisor to these two VIFs. For liveness, you need BFD running on the tunnel interface. Thanks, Manoj ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2 ovn 3/3] Forwarding group to load balance l2 traffic with liveness detection
Unit tests for forwarding group Signed-off-by: Manoj Sharma --- tests/ovn-nbctl.at | 37 tests/ovn.at | 124 + 2 files changed, 161 insertions(+) diff --git a/tests/ovn-nbctl.at b/tests/ovn-nbctl.at index 2679f1f..077c41e 100644 --- a/tests/ovn-nbctl.at +++ b/tests/ovn-nbctl.at @@ -1735,6 +1735,43 @@ $SW1P2 AT_CHECK([ovn-nbctl pg-del pg1], [0], [ignore]) AT_CHECK([ovn-nbctl list port_group], [0], []) ]) +dnl - + +OVN_NBCTL_TEST([ovn_nbctl_fwd_groups], [fwd groups], [ + +dnl Add fwd-group to a non-existent logical switch +AT_CHECK([ovn-nbctl fwd-group-add fwd_grp1 ls0 10.1.1.11 00:11:22:33:44:55 lsp1 lsp2], [1], [], + [ovn-nbctl: ls0: switch name not found +]) + +AT_CHECK([ovn-nbctl ls-add ls0]) + +dnl Add fwd-group with non-existent logical switch ports +AT_CHECK([ovn-nbctl fwd-group-add fwd_grp1 ls0 10.1.1.11 00:11:22:33:44:55 lsp1 lsp2], [1], [], + [ovn-nbctl: lsp1: logical switch port does not exist +]) + +AT_CHECK([ovn-nbctl lsp-add ls0 lsp1]) +AT_CHECK([ovn-nbctl lsp-add ls0 lsp2]) +AT_CHECK([ovn-nbctl fwd-group-add fwd_grp1 ls0 10.1.1.11 00:11:22:33:44:55 lsp1 lsp2]) +AT_CHECK([ovn-nbctl fwd-group-list ls0], [0], [dnl +FWD_GROUP LSVIP VMAC CHILD_PORTS +fwd_grp1ls0 10.1.1.11 00:11:22:33:44:55 lsp1 lsp2 +]) +AT_CHECK([ovn-nbctl --bare --columns=name list forwarding_group], [0], +[fwd_grp1 +]) + +dnl Add duplicate fwd-group +AT_CHECK([ovn-nbctl fwd-group-add fwd_grp1 ls0 10.1.1.11 00:11:22:33:44:55 lsp1 lsp2], [1], [], + [ovn-nbctl: fwd_grp1: a forwarding group by this name already exists +]) + +dnl Delete fwd-group +AT_CHECK([ovn-nbctl fwd-group-del fwd_grp1], [0], [ignore]) +AT_CHECK([ovn-nbctl list forwarding_group], [0], []) + +]) AT_SETUP([ovn-nbctl - daemon retry connection]) OVN_NBCTL_TEST_START daemon diff --git a/tests/ovn.at b/tests/ovn.at index 411b768..b8e8eba 100644 --- a/tests/ovn.at +++ b/tests/ovn.at @@ -17338,3 +17338,127 @@ OVS_WAIT_UNTIL([ OVN_CLEANUP([hv1]) AT_CLEANUP + +AT_SETUP([ovn -- forwarding group: 3 HVs, 1 LR, 2 LS]) +AT_KEYWORDS([forwarding-group]) +ovn_start + +# Logical network: +# One LR - R1 has a logical switch ls1 and ls2 connected to it. +# Logical switch ls1 has one port while ls2 has two logical switch ports as +# child ports. +ovn-nbctl lr-add R1 +ovn-nbctl ls-add ls1 +ovn-nbctl ls-add ls2 + +# Logical switch ls1 to R1 connectivity +ovn-nbctl lrp-add R1 R1-ls1 00:00:00:01:02:f1 192.168.1.1/24 +ovn-nbctl lsp-add ls1 ls1-R1 -- set Logical_Switch_Port ls1-R1 \ +type=router options:router-port=R1-ls1 -- lsp-set-addresses ls1-R1 router +ovn-nbctl lsp-add ls1 lsp11 \ +-- lsp-set-addresses lsp11 "00:00:00:01:02:01 192.168.1.2" + +# Logical switch ls2 to R1 connectivity +ovn-nbctl lrp-add R1 R1-ls2 00:00:00:01:02:f2 172.16.1.1/24 +ovn-nbctl lsp-add ls2 ls2-R1 -- set Logical_Switch_Port ls2-R1 \ +type=router options:router-port=R1-ls2 -- lsp-set-addresses ls2-R1 router +ovn-nbctl lsp-add ls2 lsp21 \ +-- lsp-set-addresses lsp21 "00:00:00:01:02:01 172.16.1.2" +ovn-nbctl lsp-add ls2 lsp22 \ +-- lsp-set-addresses lsp22 "00:00:00:01:02:02 172.16.1.3" + +# Create a network +net_add n1 + +# Create hypervisor hv1 connected to n1 +sim_add hv1 +as hv1 +ovs-vsctl add-br br-phys +ovn_attach n1 br-phys 192.168.0.1 +ovs-vsctl add-port br-int vif1 -- set Interface vif1 external-ids:iface-id=lsp11 options:tx_pcap=hv1/vif1-tx.pcap options:rxq_pcap=hv1/vif1-rx.pcap ofport-request=1 + +# Create hypervisor hv2 connected to n1 +sim_add hv2 +as hv2 +ovs-vsctl add-br br-phys +ovn_attach n1 br-phys 192.168.0.2 +ovs-vsctl add-port br-int vif2 -- set Interface vif2 external-ids:iface-id=lsp21 options:tx_pcap=hv2/vif2-tx.pcap options:rxq_pcap=hv2/vif2-rx.pcap ofport-request=1 + +# Create hypervisor hv3 connected to n1 +sim_add hv3 +as hv3 +ovs-vsctl add-br br-phys +ovn_attach n1 br-phys 192.168.0.3 +ovs-vsctl add-port br-int vif3 -- set Interface vif3 external-ids:iface-id=lsp22 options:tx_pcap=hv3/vif3-tx.pcap options:rxq_pcap=hv3/vif3-rx.pcap ofport-request=1 + +# Add a forwarding group on ls2 with lsp21 and lsp22 as child ports +# virtual IP - 172.16.1.11, virtual MAC - 00:11:de:ad:be:ef +ovn-nbctl fwd-group-add fwd_grp1 ls2 172.16.1.11 00:11:de:ad:be:ef lsp21 lsp22 + +# Allow some time for ovn-northd and ovn-controller to catch up. +sleep 1 + +# Check logical flow +AT_CHECK([ovn-sbctl dump-flows | grep ls_in_l2_lkup | grep fwd_group | wc -l], [0], [dnl +1 +]) + +# Check openflow rule with "group" on hypervisor +AT_CHECK([as hv1 ovs-ofctl dump-flows br-int | \ +grep "dl_dst=00:11:de:ad:be:ef actions=group" | wc -l], [0], [dnl +1 +]) + +# Verify openflow group members +for child_port in lsp21 lsp22; do +tunnel_key=`ovn-sbctl --bare --column tunnel_key find port_binding logical
[ovs-dev] [PATCH v2 ovn 1/3] Forwarding group to load balance l2 traffic with liveness detection
Add a forwarding group table and a reference to the logical switch it is
configured on. The forwarding group is configured with a virtual IP, virtual
MAC and a number of logical switch ports from a logical switch.
Signed-off-by: Manoj Sharma
---
ovn-nb.ovsschema | 18 +++-
ovn-nb.xml| 35 +++
utilities/ovn-nbctl.8.xml | 37 +++
utilities/ovn-nbctl.c | 253 ++
4 files changed, 341 insertions(+), 2 deletions(-)
diff --git a/ovn-nb.ovsschema b/ovn-nb.ovsschema
index 12999a4..99b6285 100644
--- a/ovn-nb.ovsschema
+++ b/ovn-nb.ovsschema
@@ -1,7 +1,7 @@
{
"name": "OVN_Northbound",
"version": "5.18.0",
-"cksum": "2806349485 24196",
+"cksum": "63300136 24879",
"tables": {
"NB_Global": {
"columns": {
@@ -59,7 +59,12 @@
"min": 0, "max": "unlimited"}},
"external_ids": {
"type": {"key": "string", "value": "string",
- "min": 0, "max": "unlimited"}}},
+ "min": 0, "max": "unlimited"}},
+ "forwarding_groups": {
+"type": {"key": {"type": "uuid",
+ "refTable": "Forwarding_Group",
+ "refType": "strong"},
+ "min": 0, "max": "unlimited"}}},
"isRoot": true},
"Logical_Switch_Port": {
"columns": {
@@ -113,6 +118,15 @@
"min": 0, "max": "unlimited"}}},
"indexes": [["name"]],
"isRoot": false},
+"Forwarding_Group": {
+"columns": {
+"name": {"type": "string"},
+"vip": {"type": "string"},
+"vmac": {"type": "string"},
+"liveness": {"type": "boolean"},
+"child_port": {"type": {"key": "string",
+"min": 1, "max": "unlimited"}}},
+"isRoot": false},
"Address_Set": {
"columns": {
"name": {"type": "string"},
diff --git a/ovn-nb.xml b/ovn-nb.xml
index 5ae52bb..decb4ae 100644
--- a/ovn-nb.xml
+++ b/ovn-nb.xml
@@ -197,6 +197,11 @@
Please see the table.
+
+ Groups a set of logical port endpoints for traffic going out of the
+ logical switch.
+
+
These columns provide names for the logical switch. From OVN's
@@ -1152,6 +1157,36 @@
+
+
+ Each row represents one forwarding group.
+
+
+
+ A name for the forwarding group. This name has no special meaning or
+ purpose other than to provide convenience for human interaction with
+ the ovn-nb database.
+
+
+
+ The virtual IP address assigned to the forwarding group. It will respond
+ with vmac when an ARP request is sent for vip.
+
+
+
+ The virtual MAC address assigned to the forwarding group.
+
+
+
+ If set to true, liveness is enabled for child ports
+ otherwise it is disabled.
+
+
+
+ List of child ports in the forwarding group.
+
+
+
Each row in this table represents a named set of addresses.
diff --git a/utilities/ovn-nbctl.8.xml b/utilities/ovn-nbctl.8.xml
index 88ebd13..2f3badd 100644
--- a/utilities/ovn-nbctl.8.xml
+++ b/utilities/ovn-nbctl.8.xml
@@ -483,6 +483,43 @@
+Forwarding Group Commands
+
+
+ [--liveness]fwd-group-add group
switch vip vmac ports
+
+
+ Creates a new forwarding group named group as the name
+ with the provided vip and vmac. vip
+ should be a virtual IP address and vmac should be a
+ virtual MAC address to access the forwarding group. ports
+ are the logical switch port names that are put in the forwarding
+ group. Example for ports is lsp1 lsp2 ...
+ Traffic destined to virtual IP of the forwarding group will be load
+ balanced to all the child ports.
+
+
+ When --liveness is specified then child ports are
+ expected to be bound to extern
[ovs-dev] [PATCH v2 ovn 2/3] Forwarding group to load balance l2 traffic with liveness detection
Add forwarding group support for a logical switch. It will add a new OVN
action "fwd_group" with a virtual IP and virtual MAC. Any number of logical
switch ports of this switch can be added to this forwarding group.
If traffic has to be load balanced across these logical switch ports then
traffic should be sent to forwarding group's virtual IP.
If the logical switch ports correspond to tunnel interfaces and BFD
can be enabled on these tunnel interfaces, then liveness can be enabled
for the forwarding group so that if any of the tunnel is down then
the corresponding logical switch port will not be selected during
load balancing.
Signed-off-by: Manoj Sharma
---
controller/lflow.c| 20 +
controller/physical.c | 13 ++
controller/physical.h | 4 ++
include/ovn/actions.h | 19 +++-
lib/actions.c | 122 ++
northd/ovn-northd.c | 63 ++
utilities/ovn-trace.c | 3 ++
7 files changed, 243 insertions(+), 1 deletion(-)
diff --git a/controller/lflow.c b/controller/lflow.c
index a689320..49dfa06 100644
--- a/controller/lflow.c
+++ b/controller/lflow.c
@@ -103,6 +103,25 @@ lookup_port_cb(const void *aux_, const char *port_name,
unsigned int *portp)
return false;
}
+/* Given the OVN port name, get its openflow port */
+static bool
+tunnel_ofport_cb(const void *aux_, const char *port_name, ofp_port_t *ofport)
+{
+const struct lookup_port_aux *aux = aux_;
+
+const struct sbrec_port_binding *pb
+= lport_lookup_by_name(aux->sbrec_port_binding_by_name, port_name);
+if (!pb || (pb->datapath != aux->dp) || !pb->chassis) {
+return false;
+}
+
+if (!get_tunnel_ofport(pb->chassis->name, NULL, ofport)) {
+return false;
+}
+
+return true;
+}
+
static bool
is_chassis_resident_cb(const void *c_aux_, const char *port_name)
{
@@ -681,6 +700,7 @@ consider_logical_flow(
struct ofpbuf ofpacts = OFPBUF_STUB_INITIALIZER(ofpacts_stub);
struct ovnact_encode_params ep = {
.lookup_port = lookup_port_cb,
+.tunnel_ofport = tunnel_ofport_cb,
.aux = &aux,
.is_switch = is_switch(ldp),
.group_table = group_table,
diff --git a/controller/physical.c b/controller/physical.c
index 500d419..af1d10f 100644
--- a/controller/physical.c
+++ b/controller/physical.c
@@ -1794,3 +1794,16 @@ physical_run(struct ovsdb_idl_index
*sbrec_port_binding_by_name,
simap_destroy(&new_tunnel_to_ofport);
}
+
+bool
+get_tunnel_ofport(const char *chassis_name, char *encap_ip, ofp_port_t *ofport)
+{
+struct chassis_tunnel *tun = NULL;
+tun = chassis_tunnel_find(chassis_name, encap_ip);
+if (!tun) {
+return false;
+}
+
+*ofport = tun->ofport;
+return true;
+}
diff --git a/controller/physical.h b/controller/physical.h
index c93f6b1..c0e17cd 100644
--- a/controller/physical.h
+++ b/controller/physical.h
@@ -72,4 +72,8 @@ void physical_handle_mc_group_changes(
const struct simap *ct_zones,
const struct hmap *local_datapaths,
struct ovn_desired_flow_table *);
+bool get_tunnel_ofport(
+const char *chassis_name,
+char *encap_ip,
+ofp_port_t *ofport);
#endif /* controller/physical.h */
diff --git a/include/ovn/actions.h b/include/ovn/actions.h
index 047a8d7..2d39239 100644
--- a/include/ovn/actions.h
+++ b/include/ovn/actions.h
@@ -89,7 +89,8 @@ struct ovn_extend_table;
OVNACT(CHECK_PKT_LARGER, ovnact_check_pkt_larger) \
OVNACT(TRIGGER_EVENT, ovnact_controller_event) \
OVNACT(BIND_VPORT,ovnact_bind_vport) \
-OVNACT(HANDLE_SVC_CHECK, ovnact_handle_svc_check)
+OVNACT(HANDLE_SVC_CHECK, ovnact_handle_svc_check) \
+OVNACT(FWD_GROUP, ovnact_fwd_group)
/* enum ovnact_type, with a member OVNACT_ for each action. */
enum OVS_PACKED_ENUM ovnact_type {
@@ -359,6 +360,15 @@ struct ovnact_handle_svc_check {
struct expr_field port; /* Logical port name. */
};
+/* OVNACT_FWD_GROUP. */
+struct ovnact_fwd_group {
+struct ovnact ovnact;
+bool liveness;
+char **child_ports; /* Logical ports */
+size_t n_child_ports;
+uint8_t ltable; /* Logical table ID of next table. */
+};
+
/* Internal use by the helpers below. */
void ovnact_init(struct ovnact *, enum ovnact_type, size_t len);
void *ovnact_put(struct ofpbuf *, enum ovnact_type, size_t len);
@@ -620,6 +630,13 @@ struct ovnact_encode_params {
* '*portp' and returns true; otherwise, returns false. */
bool (*lookup_port)(const void *aux, const char *port_name,
unsigned int *portp);
+
+/* Looks up tunnel port to a chassis by its port name. If found, stores
+ * its openflow port number in '*ofport' and returns true;
+ * otherwise, returns false. */
+bool (*tunnel_ofport)(const void *aux, const char *port_name,
+
[ovs-dev] [PATCH v2 ovn 0/3] Forwarding group to load balance l2 traffic with liveness detection
A forwarding group is an aggregation of logical switch ports of a
logical switch to load balance traffic across the ports. It also detects
the liveness if the logical switch ports are realized as OVN tunnel ports
on the physical topology.
In the below logical topology diagram, the logical switch has two ports
connected to chassis / external routers R1 and R2. The logical router needs
to send traffic to an external network that is connected through R1 and R2.
++
+--+ R1 |*
/ ++ ** **
+--++--+ / lsp1 * *
| Logical || Logical|/ * External *
| Router ++ switch X* Network *
| || |\ * *
+--++--+ \ lsp2 * *
^ \ ++ ** **
| +--+ R2 |*
| ++
fwd_group -> (lsp1, lsp2)
In the absence of forwarding group, the logical router will have unicast
route to point to either R1 or R2. In case of R1 or R2 going down, it will
require control plane's intervention to update the route to point to proper
nexthop.
With forwarding group, a virtual IP (VIP) and virtual MAC (VMAC) address
are configured on the forwarding group. The logical router points to the
forwarding group's VIP as the nexthop for hosts behind R1 and R2.
[root@fwd-group]# ovn-nbctl fwd-group-add fwd ls1 VIP_1 VMAC_1 lsp1 lsp2
[root@fwd-group]# ovn-nbctl fwd-group-list
UUIDFWD_GROUP VIPVMAC CHILD_PORTS
UUID_1fwd VIP_1 VMAC_1 lsp1 lsp2
[root@fwd-group]# ovn-nbctl lr-route-list lr1
IPv4 Routes
external_host_prefix/prefix_lenVIP_1 dst-ip
The logical switch will install an ARP responder rule to reply with VMAC
as the MAC address for ARP requests for VIP. It will also install a MAC
lookup rule for VMAC with action to load balance across the logical switch
ports of the forwarding group.
Datapath: "ls1" Pipeline: ingress
table=10(ls_in_arp_rsp ), priority=50 , match=(arp.tpa == VIP_1 &&
arp.op == 1), action=(eth.dst = eth.src; eth.src = VMAC_1; arp.op = 2;
/* ARP reply */ arp.tha = arp.sha; arp.sha = VMAC_1; arp.tpa = arp.spa;
arp.spa = VIP; outport = inport; flags.loopback = 1; output;)
table=13(ls_in_l2_lkup ), priority=50 , match=(eth.dst == VMAC_1),
action=(fwd_group("lsp1","lsp2");)
In the physical topology, OVN managed hypervisors are connected to R1 and
R2 through overlay tunnels. The logical flow's "fwd_group" action mentioned
above, gets translated to openflow group type "select" with one bucket for
each logical switch port.
cookie=0x0, duration=16.869s, table=29, n_packets=4, n_bytes=392, idle_age=0,
priority=111,metadata=0x9,dl_dst=VMAC_1 actions=group:1
group_id=1,type=select,selection_method=dp_hash,
bucket=actions=load:0x2->NXM_NX_REG15[0..15], resubmit(,32),
bucket=actions=load:0x3->NXM_NX_REG15[0..15],resubmit(,32)
where 0x2 and 0x3 are port tunnel keys of lsp1 and lsp2.
The openflow group type "select" with selection method "dp_hash" load
balances traffic based on source and destination Ethernet address, VLAN ID,
Ethernet type, IPv4/v6 source and destination address and protocol, and for
TCP and SCTP only, the source and destination ports.
To detect path failure between OVN managed hypervisors and (R1, R2), BFD is
enabled on the tunnel interfaces. The openflow group is modified to include
watch_port for liveness detection of a port.
group_id=1,type=select,selection_method=dp_hash,
bucket=watch_port:31,actions=load:0x2->NXM_NX_REG15[0..15],resubmit(,32),
bucket=watch_port:32,actions=load:0x3->NXM_NX_REG15[0..15],resubmit(,32)
Where 31 and 32 are ovs port numbers for the tunnel interfaces connecting
to R1 and R2.
If the BFD forwarding status is down for any of the tunnels, the
corresponding bucket will not be selected for packet forwarding.
Manoj Sharma (3):
Schema changes for adding forwarding_group table and new ovn-nbctl commands
Changes to add flow in the logical switch as well as in the ovn controller
Unit tests for forwarding group
controller/lflow.c| 20
controller/physical.c | 13 +++
controller/physical.h | 4 +
include/ovn/actions.h | 19 +++-
lib/actions.c | 122 ++
northd/ovn-northd.c | 63
ovn-nb.ovsschema | 18 +++-
ovn-nb.xml| 35 +++
tests/ovn-nbctl.at| 37 +++
tests/ovn.at
[ovs-dev] [PATCH v1 ovn 0/1] Forwarding group to load balance l2 traffic with liveness detection
A forwarding group is an aggregation of logical switch ports of a
logical switch to load balance traffic across the ports. It also
detects the liveness if the logical switch ports are realized as
OVN tunnel ports on the physical topology.
In the below logical topology diagram, the logical switch has two ports
connected to chassis / external routers R1 and R2. The logical router needs
to send traffic to an external network that is connected through R1 and R2.
++
+--+ R1 |*
/ ++ ** **
+--++--+ / lsp1 * *
| Logical || Logical|/ * External *
| Router ++ switch X* Network *
| || |\ * *
+--++--+ \ lsp2 * *
^ \ ++ ** **
| +--+ R2 |*
| ++
fwd_group -> (lsp1, lsp2)
In the absence of forwarding group, the logical router will have unicast
route to point to either R1 or R2. In case of R1 or R2 going down, it will
require control plane's intervention to update the route to point to proper
nexthop.
With forwarding group, a virtual IP (VIP) and virtual MAC (VMAC) address
are configured on the forwarding group. The logical router points to the
forwarding group's VIP as the nexthop for hosts behind R1 and R2.
[root@fwd-group]# ovn-nbctl fwd-group-add fwd ls1 VIP_1 VMAC_1 lsp1 lsp2
[root@fwd-group]# ovn-nbctl fwd-group-list
UUIDFWD_GROUP VIPVMAC CHILD_PORTS
UUID_1fwd VIP_1 VMAC_1 lsp1 lsp2
[root@fwd-group]# ovn-nbctl lr-route-list lr1
IPv4 Routes
external_host_prefix/prefix_lenVIP_1 dst-ip
The logical switch will install an ARP responder rule to reply with VMAC
as the MAC address for ARP requests for VIP. It will also install a MAC
lookup rule for VMAC with action to load balance across the logical switch
ports of the forwarding group.
Datapath: "ls1" Pipeline: ingress
table=10(ls_in_arp_rsp ), priority=50 , match=(arp.tpa == VIP_1 &&
arp.op == 1), action=(eth.dst = eth.src; eth.src = VMAC_1; arp.op = 2;
/* ARP reply */ arp.tha = arp.sha; arp.sha = VMAC_1; arp.tpa = arp.spa;
arp.spa = VIP; outport = inport; flags.loopback = 1; output;)
table=13(ls_in_l2_lkup ), priority=50 , match=(eth.dst == VMAC_1),
action=(fwd_group("lsp1","lsp2");)
In the physical topology, OVN managed hypervisors are connected to R1 and
R2 through overlay tunnels. The logical flow's "fwd_group" action mentioned
above, gets translated to openflow group type "select" with one bucket for
each logical switch port.
cookie=0x0, duration=16.869s, table=29, n_packets=4, n_bytes=392, idle_age=0,
priority=111,metadata=0x9,dl_dst=VMAC_1 actions=group:1
group_id=1,type=select,selection_method=dp_hash,
bucket=actions=load:0x2->NXM_NX_REG15[0..15], resubmit(,32),
bucket=actions=load:0x3->NXM_NX_REG15[0..15],resubmit(,32)
where 0x2 and 0x3 are port tunnel keys of lsp1 and lsp2.
The openflow group type "select" with selection method "dp_hash" load
balances traffic based on source and destination Ethernet address, VLAN ID,
Ethernet type, IPv4/v6 source and destination address and protocol, and for
TCP and SCTP only, the source and destination ports.
To detect path failure between OVN managed hypervisors and (R1, R2), BFD is
enabled on the tunnel interfaces. The openflow group is modified to include
watch_port for liveness detection of a port. To enable liveness, --liveness
option must be specified while configuring the forwarding group.
group_id=1,type=select,selection_method=dp_hash,
bucket=watch_port:31,actions=load:0x2->NXM_NX_REG15[0..15],resubmit(,32),
bucket=watch_port:32,actions=load:0x3->NXM_NX_REG15[0..15],resubmit(,32)
Where 31 and 32 are ovs port numbers for the tunnel interfaces connecting
to R1 and R2.
If the BFD forwarding status is down for any of the tunnels, the
corresponding bucket will not be selected for packet forwarding.
Signed-off-by: Manoj Sharma
controller/lflow.c| 20
controller/physical.c | 13 +++
controller/physical.h | 4 +
include/ovn/actions.h | 19 +++-
lib/actions.c | 122
northd/ovn-northd.c | 63 +
ovn-nb.ovsschema | 18 +++-
ovn-nb.xml| 35 +++
tests/ovn-nbctl.at| 37
tests/ovn.at | 124
utilities/ovn-nbctl.c | 254 +++
[ovs-dev] [PATCH v1 ovn 1/1] Forwarding group to load balance l2 traffic with liveness detection
A forwarding group is an aggregation of logical switch ports of a
logical switch to load balance traffic across the ports. It also
detects the liveness if the logical switch ports are realized as
OVN tunnel ports on the physical topology.
Signed-off-by: Manoj Sharma
---
controller/lflow.c| 20
controller/physical.c | 13 +++
controller/physical.h | 4 +
include/ovn/actions.h | 19 +++-
lib/actions.c | 122
northd/ovn-northd.c | 63 +
ovn-nb.ovsschema | 18 +++-
ovn-nb.xml| 35 +++
tests/ovn-nbctl.at| 37
tests/ovn.at | 124
utilities/ovn-nbctl.c | 254 ++
utilities/ovn-trace.c | 3 +
12 files changed, 709 insertions(+), 3 deletions(-)
diff --git a/controller/lflow.c b/controller/lflow.c
index a689320..49dfa06 100644
--- a/controller/lflow.c
+++ b/controller/lflow.c
@@ -103,6 +103,25 @@ lookup_port_cb(const void *aux_, const char *port_name,
unsigned int *portp)
return false;
}
+/* Given the OVN port name, get its openflow port */
+static bool
+tunnel_ofport_cb(const void *aux_, const char *port_name, ofp_port_t *ofport)
+{
+const struct lookup_port_aux *aux = aux_;
+
+const struct sbrec_port_binding *pb
+= lport_lookup_by_name(aux->sbrec_port_binding_by_name, port_name);
+if (!pb || (pb->datapath != aux->dp) || !pb->chassis) {
+return false;
+}
+
+if (!get_tunnel_ofport(pb->chassis->name, NULL, ofport)) {
+return false;
+}
+
+return true;
+}
+
static bool
is_chassis_resident_cb(const void *c_aux_, const char *port_name)
{
@@ -681,6 +700,7 @@ consider_logical_flow(
struct ofpbuf ofpacts = OFPBUF_STUB_INITIALIZER(ofpacts_stub);
struct ovnact_encode_params ep = {
.lookup_port = lookup_port_cb,
+.tunnel_ofport = tunnel_ofport_cb,
.aux = &aux,
.is_switch = is_switch(ldp),
.group_table = group_table,
diff --git a/controller/physical.c b/controller/physical.c
index 500d419..af1d10f 100644
--- a/controller/physical.c
+++ b/controller/physical.c
@@ -1794,3 +1794,16 @@ physical_run(struct ovsdb_idl_index
*sbrec_port_binding_by_name,
simap_destroy(&new_tunnel_to_ofport);
}
+
+bool
+get_tunnel_ofport(const char *chassis_name, char *encap_ip, ofp_port_t *ofport)
+{
+struct chassis_tunnel *tun = NULL;
+tun = chassis_tunnel_find(chassis_name, encap_ip);
+if (!tun) {
+return false;
+}
+
+*ofport = tun->ofport;
+return true;
+}
diff --git a/controller/physical.h b/controller/physical.h
index c93f6b1..c0e17cd 100644
--- a/controller/physical.h
+++ b/controller/physical.h
@@ -72,4 +72,8 @@ void physical_handle_mc_group_changes(
const struct simap *ct_zones,
const struct hmap *local_datapaths,
struct ovn_desired_flow_table *);
+bool get_tunnel_ofport(
+const char *chassis_name,
+char *encap_ip,
+ofp_port_t *ofport);
#endif /* controller/physical.h */
diff --git a/include/ovn/actions.h b/include/ovn/actions.h
index 047a8d7..2d39239 100644
--- a/include/ovn/actions.h
+++ b/include/ovn/actions.h
@@ -89,7 +89,8 @@ struct ovn_extend_table;
OVNACT(CHECK_PKT_LARGER, ovnact_check_pkt_larger) \
OVNACT(TRIGGER_EVENT, ovnact_controller_event) \
OVNACT(BIND_VPORT,ovnact_bind_vport) \
-OVNACT(HANDLE_SVC_CHECK, ovnact_handle_svc_check)
+OVNACT(HANDLE_SVC_CHECK, ovnact_handle_svc_check) \
+OVNACT(FWD_GROUP, ovnact_fwd_group)
/* enum ovnact_type, with a member OVNACT_ for each action. */
enum OVS_PACKED_ENUM ovnact_type {
@@ -359,6 +360,15 @@ struct ovnact_handle_svc_check {
struct expr_field port; /* Logical port name. */
};
+/* OVNACT_FWD_GROUP. */
+struct ovnact_fwd_group {
+struct ovnact ovnact;
+bool liveness;
+char **child_ports; /* Logical ports */
+size_t n_child_ports;
+uint8_t ltable; /* Logical table ID of next table. */
+};
+
/* Internal use by the helpers below. */
void ovnact_init(struct ovnact *, enum ovnact_type, size_t len);
void *ovnact_put(struct ofpbuf *, enum ovnact_type, size_t len);
@@ -620,6 +630,13 @@ struct ovnact_encode_params {
* '*portp' and returns true; otherwise, returns false. */
bool (*lookup_port)(const void *aux, const char *port_name,
unsigned int *portp);
+
+/* Looks up tunnel port to a chassis by its port name. If found, stores
+ * its openflow port number in '*ofport' and returns true;
+ * otherwise, returns false. */
+bool (*tunnel_ofport)(const void *aux, const char *port_name,
+ ofp_port_t *ofport);
+
const void *aux;
/* 'true' if the flow is for a switch. */
diff --git a/lib/actions.c b/lib/actions.c
index 051e6c8..73dade9 100644
-
Re: [ovs-dev] Openflow group/load balancing support in OVN
Thanks Numan, Yes, I had seen the native load balance support. I was looking for support at the egress switch with option to enable BFD on the VIF. That will automatically provide health check also. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Openflow group/load balancing support in OVN
Folks, Is there any way to configure open flow group or anything similar from OVN to load balance traffic to more than one port? I have a logical switch with two ports connected to two different chassis. I would like to load balance traffic to these two chassis. ovn-nbctl ls-add foo ovn-nbctl lsp-add foo foo-lsp1 ovn-nbctl lsp-add foo foo-lsp2 ovn-sbctl chassis-add ch0 vxlan 1.2.3.5 ovn-sbctl chassis-add ch1 vxlan 1.2.3.6 ovn-sbctl lsp-bind foo-lsp1 ch0 ovn-sbctl lsp-bind foo-lsp2 ch1 Is there any way to put foo-lsp1 and foo-lsp2 in a group or some similar construct and load balance across these two? Thanks Manoj ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Port based SNAT support
Guru, we tried with a single client and did not see the source port translation
happening. As you suggested, we will try it with parallel connections and let
you know what we observe.
Thanks
On 11/6/17, 7:19 PM, "ovs-dev-boun...@openvswitch.org on behalf of Guru Shetty"
wrote:
I guess, I did not read the original question carefully. I would imagine
that we do port based SNATting, otherwise there would be conflicts. Have
you tried doing parallel connections with the same src port but different
source IP address?
On 6 November 2017 at 19:12, Guru Shetty wrote:
> We don't have that feature.
>
> On 6 November 2017 at 18:53, Ritesh Rekhi
> wrote:
>
>> Hi Guru,
>>
>> Thx for the reply , load balancer can change the dest port if directed to
>> a single ip.
>>
>> The use case we are looking for is PAT where a whole subnet can go to
>> internet using same IP .
>>
>> Thx
>> Ritesh
>>
>> Sent from my iPhone
>>
>> On Nov 6, 2017, at 5:56 PM, Guru Shetty
mailto:g...@ovn.org>>
>> wrote:
>>
>> You can use load-balancer with a single destination to achieve port
>> NAtting.
>>
>> On 6 November 2017 at 16:39, Manoj Sharma > to:manoj.sha...@nutanix.com>> wrote:
>> Hi Guru, Mickey,
>>
>> Does OVN currently support PORT based SNAT? By looking at the code in
>> ovn/lib/actions.c, it seems to be doing only IP based NAT.
>> Can you please confirm?
>>
>> This is the NAT table entry:
>>
>> ovn-nbctl lr-nat-list R1
>>
>> TYPE EXTERNAL_IPLOGICAL_IPEXTERNAL_MAC
>> LOGICAL_PORT
>> snat public_ip
192.168.1.0/24<https://urldefense.proofpoint.com/v2/url?u=https-3A__urldefe&d=DwIGaQ&c=s883GpUCOChKOHiocYtGcg&r=9SN4tlEcxQzh-CvuC81YSi9I6ERNBOWQbg-05pnXlNw&m=1h3810lD3pTH_ZsKxW6X0ojF5Ml3hg3Rs98quXdqd9I&s=ObcM8PNKhIOLpRiDQfI2TGHkxfYOfAtZgU0iSadaZls&e=
>> nse.proofpoint.com/v2/url?u=http-3A__192.168.1.0_24&d=
>> DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=tS71hH9ZpgeYuaCp3UYeWhphNU
>> WUM294zNruMiZ86oA&m=MhrEKKl6awcvFeJUEtRr9oLd3f74WvM1H-
>> 28zF00BCM&s=j2p_B4NvYyNR4YDDV-vQSn997P7OtyALvQoKeBpjfoM&e=>
>>
>> When a VM in subnet
192.168.1.0/24<https://urldefense.proofpoint.com/v2/url?u=https-3A__urldefe&d=DwIGaQ&c=s883GpUCOChKOHiocYtGcg&r=9SN4tlEcxQzh-CvuC81YSi9I6ERNBOWQbg-05pnXlNw&m=1h3810lD3pTH_ZsKxW6X0ojF5Ml3hg3Rs98quXdqd9I&s=ObcM8PNKhIOLpRiDQfI2TGHkxfYOfAtZgU0iSadaZls&e=
>> nse.proofpoint.com/v2/url?u=http-3A__192.168.1.0_24&d=
>> DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=tS71hH9ZpgeYuaCp3UYeWhphNU
>> WUM294zNruMiZ86oA&m=MhrEKKl6awcvFeJUEtRr9oLd3f74WvM1H-
>> 28zF00BCM&s=j2p_B4NvYyNR4YDDV-vQSn997P7OtyALvQoKeBpjfoM&e=> sends
>> traffic to physical network, the source IP is getting translated to the
>> “public_ip” but source port is left unchanged.
>>
>> Thanks
>> Manoj
>>
>> ___
>> dev mailing list
>> d...@openvswitch.org
>>
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwIGaQ&c=s883GpUCOChKOHiocYtGcg&r=9SN4tlEcxQzh-CvuC81YSi9I6ERNBOWQbg-05pnXlNw&m=1h3810lD3pTH_ZsKxW6X0ojF5Ml3hg3Rs98quXdqd9I&s=j707BMgxWnEQq52pyTGGi6tbxqiILliFfeX6BERVxdg&e=
>>
>
>
___
dev mailing list
d...@openvswitch.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwIGaQ&c=s883GpUCOChKOHiocYtGcg&r=9SN4tlEcxQzh-CvuC81YSi9I6ERNBOWQbg-05pnXlNw&m=1h3810lD3pTH_ZsKxW6X0ojF5Ml3hg3Rs98quXdqd9I&s=j707BMgxWnEQq52pyTGGi6tbxqiILliFfeX6BERVxdg&e=
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Port based SNAT support
Hi Guru, Mickey, Does OVN currently support PORT based SNAT? By looking at the code in ovn/lib/actions.c, it seems to be doing only IP based NAT. Can you please confirm? This is the NAT table entry: ovn-nbctl lr-nat-list R1 TYPE EXTERNAL_IPLOGICAL_IPEXTERNAL_MAC LOGICAL_PORT snat public_ip 192.168.1.0/24 When a VM in subnet 192.168.1.0/24 sends traffic to physical network, the source IP is getting translated to the “public_ip” but source port is left unchanged. Thanks Manoj ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 2/3] ovn: Ability to skip some IP addresses for SNAT.
On 20 June 2017 at 14:52, Manoj Sharma
mailto:manoj.sha...@nutanix.com>> wrote:
Hi Guru,
Please see my answer below:
On 19 June 2017 at 23:17, Manoj Sharma
mailto:manoj.sha...@nutanix.com>> wrote:
The use case is if someone wants to access a VM from on-prem then it is an
l3vpn and we should not do SNAT for it.
> Please expand on the above. What does "on-prem" mean in the context of OVN?
> And is the VM a OVN logical port?
I have two OVN networks at two different locations and they are connected
through a gateway. I want the SNAT to happen for internet traffic but not for
the inter-office traffic because it is a single private network stretched
across two locations.
> Okay. Your physical infrastructure knows how to route OVN's logical IP
> addresses?
Yes, the physical infrastructure can route the logical IP addresses.
> Does this use gateway routers or does it use distributed router ports?
The gateway router port is after distributed router port for south->north
traffic. The snat/nosnat will happen as part of the distributed router port and
then it will be sent out using the gateway router port.
Both sides should be using their logical IPs.
> This confuses me. If both sides use logical IP, it reads to me that both
> sides are OVN logical ports. In that case, why do we even needs SNATs? Why is
> the packet even >going to a gateway?
Its a single layer 3 private network spanning across two OVN domains. They
should use their logical IP while talking to each other.
However the match for “nosnat” should be on destination IP.
I will rebase it to current master and run the tests.
Regards
- Manoj
From: Guru Shetty mailto:g...@ovn.org>>
Date: Monday, June 19, 2017 at 1:04 PM
To: Manoj Sharma mailto:manoj.sha...@nutanix.com>>
Cc: "d...@openvswitch.org<mailto:d...@openvswitch.org>"
mailto:d...@openvswitch.org>>
Subject: Re: [ovs-dev] [PATCH 2/3] ovn: Ability to skip some IP addresses for
SNAT.
On 19 June 2017 at 12:16, Manoj Sharma
mailto:manoj.sha...@nutanix.com>> wrote:
Hi Guru,
It looked very useful patch. Do you plan to commit it into main?
Was there any reason to not merge it so far?
Is there a use case for which you want to use it? What is the use case? This is
an old patch and if you think it is useful, please consider spending some time
rebasing it to the current master and running all the system tests to make sure
that it does not introduce any regression.
Regards
- Manoj
On 11/3/16, 3:46 AM, "dev on behalf of Gurucharan Shetty"
mailto:dev-boun...@openvswitch.org> on behalf of
g...@ovn.org<mailto:g...@ovn.org>> wrote:
>We currently have the ability to add a large network to
>match on the source IP address of a packet and then SNAT
>it to a external_ip. For e.g. one could add a SNAT rule
>that SNATs all packets with source IP address of
>"0.0.0.0/0<http://0.0.0.0/0>" to 10.1.1.10.
>
>It is useful to make a small subnet to pass-through without
>any SNAT done on it. For e.g a subnet that is routable in
>the external network. This commit adds a "nosnat" option
>to the NAT table.
>
>Signed-off-by: Gurucharan Shetty mailto:g...@ovn.org>>
>---
> ovn/northd/ovn-northd.8.xml | 8
> ovn/northd/ovn-northd.c | 38 --
> ovn/ovn-nb.ovsschema| 5 +++--
> ovn/ovn-nb.xml | 7 +++
> tests/system-ovn.at<http://system-ovn.at> | 17 +
> 5 files changed, 63 insertions(+), 12 deletions(-)
>
>diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
>index df53d4c..b406db6 100644
>--- a/ovn/northd/ovn-northd.8.xml
>+++ b/ovn/northd/ovn-northd.8.xml
>@@ -1434,6 +1434,14 @@ arp {
>
>
> For each configuration in the OVN Northbound database, that asks
>+ NOT to change the source IP address of a packet with address
>+ A or NOT to change the source IP address of a packet that
>+ belongs to network A, a priority-100 flow with a match of
>+ ip && ip4.src == A and an action of
>+ next;.
>+
>+
>+ For each configuration in the OVN Northbound database, that asks
> to change the source IP address of a packet from an IP address of
> A or to change the source IP address of a packet that
> belongs to network A to B, a flow matches
>diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
>index 07c7b2d..86504aa 100644
>--- a/ovn/northd/ovn-northd.c
>+++ b/ovn/northd/ovn-northd.c
>@@ -3680,6 +3680,10 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap
>*ports,
>
> nat = op->od->nbr->nat[i];
>
>+if (!strcmp(n
Re: [ovs-dev] [PATCH 2/3] ovn: Ability to skip some IP addresses for SNAT.
Hi Guru,
Please see my answer below:
On 19 June 2017 at 23:17, Manoj Sharma
mailto:manoj.sha...@nutanix.com>> wrote:
The use case is if someone wants to access a VM from on-prem then it is an
l3vpn and we should not do SNAT for it.
> Please expand on the above. What does "on-prem" mean in the context of OVN?
> And is the VM a OVN logical port?
I have two OVN networks at two different locations and they are connected
through a gateway. I want the SNAT to happen for internet traffic but not for
the inter-office traffic because it is a single private network stretched
across two locations.
Both sides should be using their logical IPs.
> This confuses me. If both sides use logical IP, it reads to me that both
> sides are OVN logical ports. In that case, why do we even needs SNATs? Why is
> the packet even >going to a gateway?
Its a single layer 3 private network spanning across two OVN domains. They
should use their logical IP while talking to each other.
However the match for “nosnat” should be on destination IP.
I will rebase it to current master and run the tests.
Regards
- Manoj
From: Guru Shetty mailto:g...@ovn.org>>
Date: Monday, June 19, 2017 at 1:04 PM
To: Manoj Sharma mailto:manoj.sha...@nutanix.com>>
Cc: "d...@openvswitch.org<mailto:d...@openvswitch.org>"
mailto:d...@openvswitch.org>>
Subject: Re: [ovs-dev] [PATCH 2/3] ovn: Ability to skip some IP addresses for
SNAT.
On 19 June 2017 at 12:16, Manoj Sharma
mailto:manoj.sha...@nutanix.com>> wrote:
Hi Guru,
It looked very useful patch. Do you plan to commit it into main?
Was there any reason to not merge it so far?
Is there a use case for which you want to use it? What is the use case? This is
an old patch and if you think it is useful, please consider spending some time
rebasing it to the current master and running all the system tests to make sure
that it does not introduce any regression.
Regards
- Manoj
On 11/3/16, 3:46 AM, "dev on behalf of Gurucharan Shetty"
mailto:dev-boun...@openvswitch.org> on behalf of
g...@ovn.org<mailto:g...@ovn.org>> wrote:
>We currently have the ability to add a large network to
>match on the source IP address of a packet and then SNAT
>it to a external_ip. For e.g. one could add a SNAT rule
>that SNATs all packets with source IP address of
>"0.0.0.0/0<http://0.0.0.0/0>" to 10.1.1.10.
>
>It is useful to make a small subnet to pass-through without
>any SNAT done on it. For e.g a subnet that is routable in
>the external network. This commit adds a "nosnat" option
>to the NAT table.
>
>Signed-off-by: Gurucharan Shetty mailto:g...@ovn.org>>
>---
> ovn/northd/ovn-northd.8.xml | 8
> ovn/northd/ovn-northd.c | 38 --
> ovn/ovn-nb.ovsschema| 5 +++--
> ovn/ovn-nb.xml | 7 +++
> tests/system-ovn.at<http://system-ovn.at> | 17 +
> 5 files changed, 63 insertions(+), 12 deletions(-)
>
>diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
>index df53d4c..b406db6 100644
>--- a/ovn/northd/ovn-northd.8.xml
>+++ b/ovn/northd/ovn-northd.8.xml
>@@ -1434,6 +1434,14 @@ arp {
>
>
> For each configuration in the OVN Northbound database, that asks
>+ NOT to change the source IP address of a packet with address
>+ A or NOT to change the source IP address of a packet that
>+ belongs to network A, a priority-100 flow with a match of
>+ ip && ip4.src == A and an action of
>+ next;.
>+
>+
>+ For each configuration in the OVN Northbound database, that asks
> to change the source IP address of a packet from an IP address of
> A or to change the source IP address of a packet that
> belongs to network A to B, a flow matches
>diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
>index 07c7b2d..86504aa 100644
>--- a/ovn/northd/ovn-northd.c
>+++ b/ovn/northd/ovn-northd.c
>@@ -3680,6 +3680,10 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap
>*ports,
>
> nat = op->od->nbr->nat[i];
>
>+if (!strcmp(nat->type, "nosnat")) {
>+continue;
>+}
>+
> ovs_be32 ip;
> if (!ip_parse(nat->external_ip, &ip) || !ip) {
> static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
>@@ -3920,19 +3924,24 @@ build_lrouter_flows(struct hmap *datapaths, struct
>hmap *ports,
>
> ovs_be32 ip, mask;
>
>-char *error = ip_parse_masked(nat->external_ip, &ip, &mask);
>-if (error || mask != OV
Re: [ovs-dev] [PATCH 2/3] ovn: Ability to skip some IP addresses for SNAT.
The use case is if someone wants to access a VM from on-prem then it is an
l3vpn and we should not do SNAT for it. Both sides should be using their
logical IPs.
However the match for “nosnat” should be on destination IP.
I will rebase it to current master and run the tests.
Regards
- Manoj
From: Guru Shetty mailto:g...@ovn.org>>
Date: Monday, June 19, 2017 at 1:04 PM
To: Manoj Sharma mailto:manoj.sha...@nutanix.com>>
Cc: "d...@openvswitch.org<mailto:d...@openvswitch.org>"
mailto:d...@openvswitch.org>>
Subject: Re: [ovs-dev] [PATCH 2/3] ovn: Ability to skip some IP addresses for
SNAT.
On 19 June 2017 at 12:16, Manoj Sharma
mailto:manoj.sha...@nutanix.com>> wrote:
Hi Guru,
It looked very useful patch. Do you plan to commit it into main?
Was there any reason to not merge it so far?
Is there a use case for which you want to use it? What is the use case? This is
an old patch and if you think it is useful, please consider spending some time
rebasing it to the current master and running all the system tests to make sure
that it does not introduce any regression.
Regards
- Manoj
On 11/3/16, 3:46 AM, "dev on behalf of Gurucharan Shetty"
mailto:dev-boun...@openvswitch.org> on behalf of
g...@ovn.org<mailto:g...@ovn.org>> wrote:
>We currently have the ability to add a large network to
>match on the source IP address of a packet and then SNAT
>it to a external_ip. For e.g. one could add a SNAT rule
>that SNATs all packets with source IP address of
>"0.0.0.0/0<http://0.0.0.0/0>" to 10.1.1.10.
>
>It is useful to make a small subnet to pass-through without
>any SNAT done on it. For e.g a subnet that is routable in
>the external network. This commit adds a "nosnat" option
>to the NAT table.
>
>Signed-off-by: Gurucharan Shetty mailto:g...@ovn.org>>
>---
> ovn/northd/ovn-northd.8.xml | 8
> ovn/northd/ovn-northd.c | 38 --
> ovn/ovn-nb.ovsschema| 5 +++--
> ovn/ovn-nb.xml | 7 +++
> tests/system-ovn.at<http://system-ovn.at> | 17 +
> 5 files changed, 63 insertions(+), 12 deletions(-)
>
>diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
>index df53d4c..b406db6 100644
>--- a/ovn/northd/ovn-northd.8.xml
>+++ b/ovn/northd/ovn-northd.8.xml
>@@ -1434,6 +1434,14 @@ arp {
>
>
> For each configuration in the OVN Northbound database, that asks
>+ NOT to change the source IP address of a packet with address
>+ A or NOT to change the source IP address of a packet that
>+ belongs to network A, a priority-100 flow with a match of
>+ ip && ip4.src == A and an action of
>+ next;.
>+
>+
>+ For each configuration in the OVN Northbound database, that asks
> to change the source IP address of a packet from an IP address of
> A or to change the source IP address of a packet that
> belongs to network A to B, a flow matches
>diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
>index 07c7b2d..86504aa 100644
>--- a/ovn/northd/ovn-northd.c
>+++ b/ovn/northd/ovn-northd.c
>@@ -3680,6 +3680,10 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap
>*ports,
>
> nat = op->od->nbr->nat[i];
>
>+if (!strcmp(nat->type, "nosnat")) {
>+continue;
>+}
>+
> ovs_be32 ip;
> if (!ip_parse(nat->external_ip, &ip) || !ip) {
> static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
>@@ -3920,19 +3924,24 @@ build_lrouter_flows(struct hmap *datapaths, struct
>hmap *ports,
>
> ovs_be32 ip, mask;
>
>-char *error = ip_parse_masked(nat->external_ip, &ip, &mask);
>-if (error || mask != OVS_BE32_MAX) {
>-static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
>-VLOG_WARN_RL(&rl, "bad external ip %s for nat",
>- nat->external_ip);
>-free(error);
>-continue;
>+if (strcmp(nat->type, "nosnat")) {
>+/* "nosnat" cases do not have a 'external_ip'. Every other
>+ * case should have a valid 'external_ip'. */
>+char *error = ip_parse_masked(nat->external_ip, &ip, &mask);
>+if (error || mask != OVS_BE32_MAX) {
>+static struct vlog_rate_limit rl
>+= VLOG_RATE_LIMIT_INIT(5, 1);
>+VLO
Re: [ovs-dev] [PATCH 2/3] ovn: Ability to skip some IP addresses for SNAT.
Hi Guru,
It looked very useful patch. Do you plan to commit it into main?
Was there any reason to not merge it so far?
Regards
- Manoj
On 11/3/16, 3:46 AM, "dev on behalf of Gurucharan Shetty"
wrote:
>We currently have the ability to add a large network to
>match on the source IP address of a packet and then SNAT
>it to a external_ip. For e.g. one could add a SNAT rule
>that SNATs all packets with source IP address of
>"0.0.0.0/0" to 10.1.1.10.
>
>It is useful to make a small subnet to pass-through without
>any SNAT done on it. For e.g a subnet that is routable in
>the external network. This commit adds a "nosnat" option
>to the NAT table.
>
>Signed-off-by: Gurucharan Shetty
>---
> ovn/northd/ovn-northd.8.xml | 8
> ovn/northd/ovn-northd.c | 38 --
> ovn/ovn-nb.ovsschema| 5 +++--
> ovn/ovn-nb.xml | 7 +++
> tests/system-ovn.at | 17 +
> 5 files changed, 63 insertions(+), 12 deletions(-)
>
>diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
>index df53d4c..b406db6 100644
>--- a/ovn/northd/ovn-northd.8.xml
>+++ b/ovn/northd/ovn-northd.8.xml
>@@ -1434,6 +1434,14 @@ arp {
>
>
> For each configuration in the OVN Northbound database, that asks
>+ NOT to change the source IP address of a packet with address
>+ A or NOT to change the source IP address of a packet that
>+ belongs to network A, a priority-100 flow with a match of
>+ ip && ip4.src == A and an action of
>+ next;.
>+
>+
>+ For each configuration in the OVN Northbound database, that asks
> to change the source IP address of a packet from an IP address of
> A or to change the source IP address of a packet that
> belongs to network A to B, a flow matches
>diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
>index 07c7b2d..86504aa 100644
>--- a/ovn/northd/ovn-northd.c
>+++ b/ovn/northd/ovn-northd.c
>@@ -3680,6 +3680,10 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap
>*ports,
>
> nat = op->od->nbr->nat[i];
>
>+if (!strcmp(nat->type, "nosnat")) {
>+continue;
>+}
>+
> ovs_be32 ip;
> if (!ip_parse(nat->external_ip, &ip) || !ip) {
> static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
>@@ -3920,19 +3924,24 @@ build_lrouter_flows(struct hmap *datapaths, struct
>hmap *ports,
>
> ovs_be32 ip, mask;
>
>-char *error = ip_parse_masked(nat->external_ip, &ip, &mask);
>-if (error || mask != OVS_BE32_MAX) {
>-static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
>-VLOG_WARN_RL(&rl, "bad external ip %s for nat",
>- nat->external_ip);
>-free(error);
>-continue;
>+if (strcmp(nat->type, "nosnat")) {
>+/* "nosnat" cases do not have a 'external_ip'. Every other
>+ * case should have a valid 'external_ip'. */
>+char *error = ip_parse_masked(nat->external_ip, &ip, &mask);
>+if (error || mask != OVS_BE32_MAX) {
>+static struct vlog_rate_limit rl
>+= VLOG_RATE_LIMIT_INIT(5, 1);
>+VLOG_WARN_RL(&rl, "bad external ip %s for nat",
>+ nat->external_ip);
>+free(error);
>+continue;
>+}
> }
>
> /* Check the validity of nat->logical_ip. 'logical_ip' can
>- * be a subnet when the type is "snat". */
>-error = ip_parse_masked(nat->logical_ip, &ip, &mask);
>-if (!strcmp(nat->type, "snat")) {
>+ * be a subnet when the type is "snat" or "nosnat". */
>+char *error = ip_parse_masked(nat->logical_ip, &ip, &mask);
>+if (!strcmp(nat->type, "snat") || !strcmp(nat->type, "nosnat")) {
> if (error) {
> static struct vlog_rate_limit rl =
> VLOG_RATE_LIMIT_INIT(5, 1);
>@@ -3987,6 +3996,15 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap
>*ports,
> ds_cstr(&match), ds_cstr(&actions));
> }
>
>+/* Egress SNAT table: Skip packets that have a specific 'nosnat'
>+ * rule. */
>+if (!strcmp(nat->type, "nosnat")) {
>+ds_clear(&match);
>+ds_put_format(&match, "ip && ip4.src == %s", nat->logical_ip);
>+ovn_lflow_add(lflows, od, S_ROUTER_OUT_SNAT, 100,
>+ ds_cstr(&match), "next;");
>+}
>+
> /* Egress SNAT table: Packets enter the egress pipeline with
> * source ip address that needs to be SNATted to a external ip
>
