[ovs-dev] [RFC ovn 207/207] [WIP] optimize port groups and address sets

[vkommadi]

From: venkata anil 

ovn-controller recalculates flows for all the members of a PG or AS
when a new member is added or deleted. Instead, this patch identifies
the changed members and only process their related flows.

Also this patch maintains constant sets for only local ports of a port
group (instead of all ports) to facilitate lesser lexer parsing and
symbols in expr.

This patch is unable to use conjuction flows (as conjuction ids are not
stored) and generate below flows
priority=2002,ct_state=-trk,ip,reg15=0x2,metadata=0x2,nw_src=10.0.0.239 
actions=resubmit(,45)

When conjuction ids used by a logical flow are maintained as part of
flow data structures instead of dynamically regenerated during flow
processing, we can update the patch to use the related conjuction ids
for the above flows.

Will test performance impact once the patch is updated with conjuction
flows.

Signed-off-by: Venkata Anil 
---
 controller/binding.c|   4 +-
 controller/binding.h|   2 +
 controller/lflow.c  | 405 +++-
 controller/lflow.h  |  16 +-
 controller/ofctrl.c |  35 +++
 controller/ofctrl.h |   4 +
 controller/ovn-controller.c | 604 ++--
 7 files changed, 960 insertions(+), 110 deletions(-)

diff --git a/controller/binding.c b/controller/binding.c
index 880fbb13b..d4a47572f 100644
--- a/controller/binding.c
+++ b/controller/binding.c
@@ -72,8 +72,6 @@ binding_register_ovs_idl(struct ovsdb_idl *ovs_idl)
 static struct tracked_binding_datapath *tracked_binding_datapath_create(
 const struct sbrec_datapath_binding *,
 bool is_new, struct hmap *tracked_dps);
-static struct tracked_binding_datapath *tracked_binding_datapath_find(
-struct hmap *, const struct sbrec_datapath_binding *);
 static void tracked_binding_datapath_lport_add(
 const struct sbrec_port_binding *, struct hmap *tracked_datapaths);
 static void update_lport_tracking(const struct sbrec_port_binding *pb,
@@ -722,7 +720,7 @@ tracked_binding_datapath_create(const struct 
sbrec_datapath_binding *dp,
 return t_dp;
 }
 
-static struct tracked_binding_datapath *
+struct tracked_binding_datapath *
 tracked_binding_datapath_find(struct hmap *tracked_datapaths,
   const struct sbrec_datapath_binding *dp)
 {
diff --git a/controller/binding.h b/controller/binding.h
index c9740560f..c96eb53ab 100644
--- a/controller/binding.h
+++ b/controller/binding.h
@@ -134,4 +134,6 @@ bool binding_handle_ovs_interface_changes(struct 
binding_ctx_in *,
 bool binding_handle_port_binding_changes(struct binding_ctx_in *,
  struct binding_ctx_out *);
 void binding_tracked_dp_destroy(struct hmap *tracked_datapaths);
+struct tracked_binding_datapath *tracked_binding_datapath_find(
+struct hmap *, const struct sbrec_datapath_binding *);
 #endif /* controller/binding.h */
diff --git a/controller/lflow.c b/controller/lflow.c
index b2f585727..78a23f790 100644
--- a/controller/lflow.c
+++ b/controller/lflow.c
@@ -15,6 +15,7 @@
 
 #include 
 #include "lflow.h"
+#include "binding.h"
 #include "coverage.h"
 #include "ha-chassis.h"
 #include "lport.h"
@@ -50,9 +51,16 @@ lflow_init(void)
 }
 
 struct lookup_port_aux {
+struct ovsdb_idl_index *sbrec_multicast_group_by_name_datapath;
+struct ovsdb_idl_index *sbrec_port_binding_by_name;
+const struct sbrec_datapath_binding *dp;
+};
+
+struct lookup_tracked_port_aux {
 struct ovsdb_idl_index *sbrec_multicast_group_by_name_datapath;
 struct ovsdb_idl_index *sbrec_port_binding_by_name;
 const struct sbrec_datapath_binding *dp;
+struct hmap *tracked_dp_bindings;
 };
 
 struct condition_aux {
@@ -63,6 +71,7 @@ struct condition_aux {
 /* Resource reference to store the port name referenced
  * in is_chassis_resident() to the logical flow. */
 struct lflow_resource_ref *lfrr;
+bool lflow_ref_portgroup_addrset;
 };
 
 static bool
@@ -74,6 +83,9 @@ consider_logical_flow(const struct sbrec_logical_flow *lflow,
   struct lflow_ctx_out *l_ctx_out);
 static void lflow_resource_add(struct lflow_resource_ref *, enum ref_type,
const char *ref_name, const struct uuid *);
+static bool consider_logical_flow_for_pg_as_member_updates(const struct 
sbrec_logical_flow *,
+  struct lflow_ctx_in *, struct lflow_ctx_out *,
+  enum ref_type, bool added, const struct shash *);
 
 static bool
 lookup_port_cb(const void *aux_, const char *port_name, unsigned int *portp)
@@ -128,11 +140,13 @@ is_chassis_resident_cb(const void *c_aux_, const char 
*port_name)
 }
 
 /* Store the port_name to lflow reference. */
-int64_t dp_id = pb->datapath->tunnel_key;
-char buf[16];
-get_unique_lport_key(dp_id, pb->tunnel_key, buf, sizeof(buf));
-lflow_resource_add(c_aux->lfrr, REF_TYPE_PORTBINDING, buf,
-   

[ovs-dev] [PATCH v7 3/4] Document the flows for redirecting VLAN packets

[vkommadi]

From: venkata anil 

We have added new flows for using vlans instead of tunnels for
redirecting VLAN packets to a gateway chassis. This patch documents
these flows in ovn-northd.8.xml and ovn-architecture.7.xml.

Signed-off-by: Venkata Anil 
---

v6->v7:
* Rebased

v5->v6:
* Rebased

v4->v5:
* This patch is added to document the logical and physical flows

 ovn/northd/ovn-northd.8.xml | 46 +
 ovn/ovn-architecture.7.xml  | 26 -
 2 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index f1771c6..8fa5272 100644
--- a/ovn/northd/ovn-northd.8.xml
+++ b/ovn/northd/ovn-northd.8.xml
@@ -995,6 +995,23 @@ output;
 
   
 
+  For each enabled router port P which is connected to
+  a VLAN network, a priority-100 flow that matches inport ==
+  P  flags.rcv_from_vlan == 1,
+  with action next;.
+
+
+
+  For the gateway port on a distributed logical router (where
+  one of the logical router ports specifies a
+  redirect-chassis), the above flow is only
+  programmed on the gateway port instance on the
+  redirect-chassis.
+
+  
+
+  
+
   For each enabled router port P with Ethernet address
   E, a priority-50 flow that matches inport ==
   P  (eth.mcast || eth.dst ==
@@ -1146,6 +1163,18 @@ output;
 
   For the gateway port on a distributed logical router (where
   one of the logical router ports specifies a
+  redirect-chassis), when the ARP request is
+  from router internal ports connected to vlan network (i.e
+  flags.rcv_from_vlan == 1), a priority-90 flow matches
+   flags.rcv_from_vlan == 1  arp.op == 1
+   arp.tpa == A will have the
+  above action but outport set to all router internal ports
+  which are connected to vlan network.
+
+
+
+  For the gateway port on a distributed logical router (where
+  one of the logical router ports specifies a
   redirect-chassis), the above flows are only
   programmed on the gateway port instance on the
   redirect-chassis.  This behavior avoids generation
@@ -1839,6 +1868,23 @@ next;
   If the address A is in the link-local scope, the
   route will be limited to sending on the ingress port.
 
+
+
+  If the route's outport is a gateway port on a
+  distributed logical router (where one of the logical router ports
+  specifies a redirect-chassis), for the packets matching
+  MLF_RCV_FROM_VLAN flag along with ip4.dst ==
+  N/M, or ip6.dst ==
+  N/M, add a flow with priority we get
+  by adding 1 to number of 1-bits in M, with an action
+  REGBIT_NAT_REDIRECT  =  1;  next;.
+  By setting the REGBIT_NAT_REDIRECT flag, in the ingress
+  table Gateway Redirect this will trigger a redirect to
+  the instance of the gateway port on the redict-chassis.
+  This flow is programmed on the gateway port instance other than the
+  redirect-chassis. This flow is also added if the route
+  is from a configured static route.
+
   
 
 
diff --git a/ovn/ovn-architecture.7.xml b/ovn/ovn-architecture.7.xml
index ae5ca8e..ad2101c 100644
--- a/ovn/ovn-architecture.7.xml
+++ b/ovn/ovn-architecture.7.xml
@@ -874,6 +874,19 @@
 Encapsulations for encoding details).  Then the actions resubmit
 to table 33 to enter the logical egress pipeline.
   
+
+  
+For VLAN packets coming through localnet port from remote chassis,
+table 0 sets logical datapath and logical ingress port based on
+localnet port. If these VLAN packets have distributed gateway port MAC
+(gateway port on a distributed logical router where one of the logical
+router ports specifies a redirect-chassis) as destination MAC address,
+a new flow with priority 200 is added which sets logical datapath to
+router metadata and logical ingress port to the patch port connecting
+router and vlan network, resubmit into the logical router ingress
+pipeline i.e table 8. This flow is only programmed  on the gateway
+port instance on the redirect-chassis.
+  
 
 
 
@@ -1020,6 +1033,16 @@
   determine the output port.
 
 
+  A higher-priority rule to match packets received from router ports
+  which are connected to vlan networks, based on flag
+  MLF_RCV_FROM_VLAN, where logical output port is a gateway port, on
+  a distributed logical router (where one of the logical router ports
+  specifies a redirect-chassis), but on remote hypervisor, the actions
+  tag the packet with input network VLAN id and 

[ovs-dev] [PATCH v7 4/4] Replace router internal MAC with gateway MAC for reply packets

[vkommadi]

From: venkata anil 

Previous patches in the series doesn't address issue 1 explained in [1]
i.e
1) removal of router gateway port MAC address on external switches
   after expiring of aging time.
2) then external switches unable to learn the gateway MAC as
   reply packets carry router internal port MAC address as source

To fix this, router on gateway node will use router gateway MAC address
instead of router internal port MAC address as source for reply packets,
so that external switches can learn gateway MAC address.
This is done only for reply packets from router gateway to tenant VLAN
switch ports.
Later before delivering the packet to the port, ovn-controller will
replace the gateway MAC with router internal port MAC in table 33.

[1] //mail.openvswitch.org/pipermail/ovs-dev/2018-July/349803.html

Reported-by: Miguel Angel Ajo 
Reported-at: 
https://mail.openvswitch.org/pipermail/ovs-dev/2018-July/349803.html
Signed-off-by: Venkata Anil 
---

v6->v7:
* Added this patch


 ovn/controller/physical.c   | 60 ++---
 ovn/northd/ovn-northd.8.xml | 10 
 ovn/northd/ovn-northd.c | 29 ++
 ovn/ovn-architecture.7.xml  |  4 ++-
 4 files changed, 99 insertions(+), 4 deletions(-)

diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index f269a1d..1f41f59 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -190,7 +190,9 @@ get_zone_ids(const struct sbrec_port_binding *binding,
 static void
 put_local_common_flows(uint32_t dp_key, uint32_t port_key,
bool nested_container, const struct zone_ids *zone_ids,
-   struct ofpbuf *ofpacts_p, struct hmap *flow_table)
+   struct ofpbuf *ofpacts_p, struct hmap *flow_table,
+   struct local_datapath *ld,
+   const struct hmap *local_datapaths)
 {
 struct match match;
 
@@ -221,11 +223,63 @@ put_local_common_flows(uint32_t dp_key, uint32_t port_key,
 }
 }
 
+struct ofpbuf *clone = NULL;
+clone = ofpbuf_clone(ofpacts_p);
+
 /* Resubmit to table 34. */
 put_resubmit(OFTABLE_CHECK_LOOPBACK, ofpacts_p);
 ofctrl_add_flow(flow_table, OFTABLE_LOCAL_OUTPUT, 100, 0,
 , ofpacts_p);
 
+/* For a reply packet from gateway with VLAN switch port as destination
+ * (excluding localnet_port and external VLAN networks), gateway router
+ * will use gateway MAC address as source MAC instead of router internal
+ * port MAC, so that external switches can learn gateway MAC address.
+ * Here (before packet is given to the port) we replace router gateway
+ * MAC address with router internal port MAC. */
+if (ld->localnet_port && (port_key != ld->localnet_port->tunnel_key)) {
+for (int i = 0; i < ld->n_peer_dps; i++) {
+struct local_datapath *peer_ldp = get_local_datapath(
+local_datapaths, ld->peer_dps[i]->peer_dp->tunnel_key);
+const struct sbrec_port_binding *crp;
+crp = peer_ldp->chassisredirect_port;
+if (!crp) {
+continue;
+}
+
+if (strcmp(smap_get(>options, "distributed-port"),
+   ld->peer_dps[i]->peer->logical_port) &&
+(port_key != ld->peer_dps[i]->patch->tunnel_key)) {
+for (int j = 0; j < crp->n_mac; j++) {
+struct lport_addresses laddrs;
+if (!extract_lsp_addresses(crp->mac[j], )) {
+continue;
+}
+match_set_dl_src(, laddrs.ea);
+destroy_lport_addresses();
+break;
+}
+for (int j = 0; j < ld->peer_dps[i]->peer->n_mac; j++) {
+struct lport_addresses laddrs;
+uint64_t mac64;
+if (!extract_lsp_addresses(
+ld->peer_dps[i]->peer->mac[j], )) {
+continue;
+}
+mac64 = eth_addr_to_uint64(laddrs.ea);
+put_load(mac64,
+ MFF_ETH_SRC, 0, 48, clone);
+destroy_lport_addresses();
+break;
+}
+put_resubmit(OFTABLE_CHECK_LOOPBACK, clone);
+ofctrl_add_flow(flow_table, OFTABLE_LOCAL_OUTPUT, 150, 0,
+, clone);
+}
+}
+}
+ofpbuf_delete(clone);
+
 /* Table 34, Priority 100.
  * ===
  *
@@ -330,7 +384,7 @@ consider_port_binding(struct ovsdb_idl_index 
*sbrec_chassis_by_name,
 
 struct zone_ids binding_zones = get_zone_ids(binding, ct_zones);
 put_local_common_flows(dp_key, port_key, false, _zones,
-   ofpacts_p, flow_table);
+   ofpacts_p, flow_table, ld, 

[ovs-dev] [PATCH v7 2/4] Send gateway port ARP through router internal ports

[vkommadi]

From: venkata anil 

External switches should learn the distributed gateway port MAC address
as they have to forward the packet tagged with tenant vlan network but
with this MAC as destination MAC address. So router has to send ARP
reply and gARP for this MAC address through router internal patch ports
connecting tenant vlan networks.

Signed-off-by: Venkata Anil 
---

v6->v7:
* Rebased
* Addressed review comments

v5->v6:
* Rebased

v4->v5:
* No changes in this patch


 ovn/controller/pinctrl.c | 57 +++-
 ovn/northd/ovn-northd.c  | 57 
 tests/ovn.at |  6 +
 3 files changed, 114 insertions(+), 6 deletions(-)

diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index a0bf602..d01e57f 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -2185,8 +2185,47 @@ get_nat_addresses_and_keys(struct ovsdb_idl_index 
*sbrec_chassis_by_name,
struct sset *local_l3gw_ports,
const struct sbrec_chassis *chassis,
const struct sset *active_tunnels,
-   struct shash *nat_addresses)
+   struct shash *nat_addresses,
+   const struct hmap *local_datapaths)
 {
+/* When a router has tenant vlan networks, gARP for distributed gateway
+ * router port has to be sent through internal tenant vlan network's
+ * localnet port, so that external switches can learn this MAC and forward
+ * tenant vlan network traffic with distributed gateway router port MAC
+ * as destination MAC address */
+
+struct local_datapath *ldp;
+struct shash router_vlan_ports;
+
+shash_init(_vlan_ports);
+HMAP_FOR_EACH (ldp, hmap_node, local_datapaths) {
+const struct sbrec_port_binding *crp;
+crp = ldp->chassisredirect_port;
+/* check if it a router with chassis redirect port,
+ * get corresponding distributed port */
+if (crp && crp->chassis &&
+!strcmp(crp->chassis->name, chassis->name)) {
+const struct sbrec_port_binding *dp = NULL;
+for (int i = 0; i < ldp->n_peer_dps; i++) {
+if (!strcmp(ldp->peer_dps[i]->patch->logical_port,
+smap_get(>options, "distributed-port"))) {
+dp = ldp->peer_dps[i]->peer;
+break;
+}
+}
+
+/* Save router internal port (patch port on tenant vlan network)
+ * along with distributed port. */
+for (int i = 0; i < ldp->n_peer_dps; i++) {
+if (strcmp(ldp->peer_dps[i]->patch->logical_port,
+   smap_get(>options, "distributed-port"))) {
+shash_add(_vlan_ports,
+  ldp->peer_dps[i]->peer->logical_port, dp);
+}
+}
+}
+}
+
 const char *gw_port;
 SSET_FOR_EACH(gw_port, local_l3gw_ports) {
 const struct sbrec_port_binding *pb;
@@ -2196,11 +2235,16 @@ get_nat_addresses_and_keys(struct ovsdb_idl_index 
*sbrec_chassis_by_name,
 continue;
 }
 
-if (pb->n_nat_addresses) {
-for (int i = 0; i < pb->n_nat_addresses; i++) {
+/* Router internal ports should send gARP for distributed port
+ * NAT addresses */
+const struct sbrec_port_binding *dp;
+dp = shash_find_data(_vlan_ports, pb->logical_port);
+const struct sbrec_port_binding *nat_port = dp ? dp : pb;
+if (nat_port->n_nat_addresses) {
+for (int i = 0; i < nat_port->n_nat_addresses; i++) {
 consider_nat_address(sbrec_chassis_by_name,
  sbrec_port_binding_by_name,
- pb->nat_addresses[i], pb,
+ nat_port->nat_addresses[i], pb,
  nat_address_keys, chassis,
  active_tunnels,
  nat_addresses);
@@ -2208,7 +2252,7 @@ get_nat_addresses_and_keys(struct ovsdb_idl_index 
*sbrec_chassis_by_name,
 } else {
 /* Continue to support options:nat-addresses for version
  * upgrade. */
-const char *nat_addresses_options = smap_get(>options,
+const char *nat_addresses_options = smap_get(_port->options,
  "nat-addresses");
 if (nat_addresses_options) {
 consider_nat_address(sbrec_chassis_by_name,
@@ -2220,6 +2264,7 @@ get_nat_addresses_and_keys(struct ovsdb_idl_index 
*sbrec_chassis_by_name,
 }
 }
 }
+shash_destroy(_vlan_ports);
 }
 
 static void
@@ -2255,7 +2300,7 @@ send_garp_run(struct ovsdb_idl_index 
*sbrec_chassis_by_name,

[ovs-dev] [PATCH v7 1/4] Avoid tunneling for VLAN packets redirected to a gateway chassis

[vkommadi]

From: venkata anil 

When a vm on a vlan tenant network sends traffic to an external network,
it is tunneled from host chassis to gateway chassis. In the earlier
discussion [1], Russel (also in his doc [2]) suggested if we can figure
out a way for OVN to do this redirect to the gateway host over a VLAN
network. This patch implements his suggestion i.e will redirect to
gateway chassis using incoming tenant vlan network. Gateway chassis are
expected to be configured with tenant vlan networks. In this approach,
new logical and physical flows introduced for packet processing in both
host and gateway chassis.

Packet processing in the host chassis:
1) A new ovs flow added in physical table 65, which sets MLF_RCV_FROM_VLAN
   flag for packets from vlan network entering into router pipeline
2) A new flow added in lr_in_ip_routing, for packets output through
   distributed gateway port and matching MLF_RCV_FROM_VLAN flag,
   set REGBIT_NAT_REDIRECT i.e
   table=7 (lr_in_ip_routing   ), priority=2, match=(
   ip4.dst == 0.0.0.0/0 && flags.rcv_from_vlan == 1 &&
   !is_chassis_resident("cr-alice")), action=(reg9[0] = 1; next;)
   This flow will be set only on chassis not hosting chassisredirect
   port i.e compute node.
   When REGBIT_NAT_REDIRECT set,
   a) lr_in_arp_resolve, will set packet eth.dst to distibuted gateway
  port MAC
   b) lr_in_gw_redirect, will set chassisredirect port as outport
3) A new ovs flow added in physical table 32 will use source vlan tenant
   network tag as vlan ID for sending the packet to gateway chassis.
   As this vlan packet destination MAC is distibuted gateway port MAC,
   packet will only reach the gateway chassis.
   table=32,priority=150,reg10=0x20/0x20,reg14=0x3,reg15=0x6,metadata=0x4
   actions=mod_vlan_vid:2010,output:25,strip_vlan
   This flow will be set only on chassis not hosting chassisredirect
   port i.e compute node.

Packet processing in the gateway chassis:
1) A new ovs flow added in physical table 0 for vlan traffic coming
   from localnet port with router distributed gateway port MAC as
   destination MAC address, resubmit to connected router ingress pipeline
   (i.e router attached to vlan tenant network).
   table=0,priority=150,in_port=67,dl_vlan=2010,dl_dst=00:00:02:01:02:03
   actions=strip_vlan,load:0x4->OXM_OF_METADATA[],load:0x3->NXM_NX_REG14[],
   load:0x1->NXM_NX_REG10[5],resubmit(,8)
   This flow will be set only on chassis hosting chassisredirect
   port i.e gateway node.
2) A new flow added in lr_in_admission which checks MLF_RCV_FROM_VLAN
   and allows the packet. This flow will be set only on chassis hosting
   chassisredirect port i.e gateway node.
   table=0 (lr_in_admission), priority=100  , match=(
   flags.rcv_from_vlan == 1 && inport == "lrp-44383893-613a-4bfe-b483-
   e7d0dc3055cd" && is_chassis_resident("cr-lrp-a6e3d2ab-313a-4ea3-
   8ec4-c3c774a11f49")), action=(next;)
   Then packet will pass through router ingress and egress pipelines and
   then to external switch pipeline.

[1] https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046557.html
[2] Point 3 in section 3.3.1 - Future Enhancements

https://docs.google.com/document/d/1JecGIXPH0RAqfGvD0nmtBdEU1zflHACp8WSRnKCFSgg/edit#

Reported-at: 
https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046543.html

Signed-off-by: Venkata Anil 
---

v6->v7:
* Rebased
* Addressed review comments

v5->v6:
* Rebased

v4->v5:
* No changes in this patch

v3->v4:
* Previous v3 patch became this patch of v4
* Updated the newly added flow in physical table 0 on gateway chassis
  to check for distributed gateway port MAC and then resubmit to
  router ingress pipeline
* Improved the test
* Added more comments

 ovn/controller/bfd.c|   3 +-
 ovn/controller/binding.c|  10 +-
 ovn/controller/ovn-controller.c |   3 +
 ovn/controller/ovn-controller.h |  17 ++-
 ovn/controller/physical.c   | 120 -
 ovn/lib/logical-fields.c|   4 +
 ovn/lib/logical-fields.h|   2 +
 ovn/northd/ovn-northd.c |  35 +
 tests/ovn.at| 278 
 9 files changed, 464 insertions(+), 8 deletions(-)

diff --git a/ovn/controller/bfd.c b/ovn/controller/bfd.c
index 051781f..c696741 100644
--- a/ovn/controller/bfd.c
+++ b/ovn/controller/bfd.c
@@ -139,8 +139,9 @@ bfd_travel_gw_related_chassis(
 LIST_FOR_EACH_POP (dp_binding, node, _list) {
 dp = dp_binding->dp;
 free(dp_binding);
+const struct sbrec_datapath_binding *pdp;
 for (size_t i = 0; i < dp->n_peer_dps; i++) {
-const struct sbrec_datapath_binding *pdp = dp->peer_dps[i];
+pdp = dp->peer_dps[i]->peer_dp;
 if (!pdp) {
 continue;
 }
diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
index 021ecdd..168b78d 100644
--- a/ovn/controller/binding.c
+++ b/ovn/controller/binding.c
@@ -145,10 +145,14 @@ add_local_datapath__(struct 

[ovs-dev] [PATCH v7 0/4] Use VLANs for VLAN packets redirected to a gateway chassis

[vkommadi]

From: venkata anil 

This patch avoids tunneling and instead uses source tenant vlan network
across hypervisors for traffic from vlan network on local hypervisor
towards gateway hypervisor hosting redirect chassiss port.

On the local hypervisor, when the packet enters logical router ingress
pipeline from tenant vlan network, router will set REGBIT_NAT_REDIRECT
and redirect the packet to gateway hypervisor, which is hosting the
chassis redirect port, using tenant vlan network.
Packet travelling across hypervisors will have source vlan tag and
distributed gateway port MAC as destination MAC (other packet data
unchanged).

Gateway hypervisor will check the vlan tag and destination MAC and
resubmit it to router logical ingress pipeline for routing and finding 
the logical output port(i.e it treats this packet as coming from the 
local patch port connected to tenant vlan network for routing).

No changes done for return path as return path to source hypervisor
always uses tenant vlan networks.

v6->v7:
* Rebased
* Addressed review comments
* New patch 4 for fixing issue 1 reported in
  https://mail.openvswitch.org/pipermail/ovs-dev/2018-July/349803.html

v5->v6:
* Rebased

v4->v5
* Rebased
* New patch 3 for Documentation(no changes in other patches)

v3->v4:
* Rebased
* Splitting patch into patch series. Entire patch of v3 became patch 1
  of this series.
* Updated flow in gateway chassis to check gateway port MAC address
  (in patch 1)
* New patch 2 for ARP/gARP of gateway port through router internal ports

venkata anil (4):
  Avoid tunneling for VLAN packets redirected to a gateway chassis
  Send gateway port ARP through router internal ports
  Document the flows for redirecting VLAN packets
  Replace router internal MAC with gateway MAC for reply packets

 ovn/controller/bfd.c|   3 +-
 ovn/controller/binding.c|  10 +-
 ovn/controller/ovn-controller.c |   3 +
 ovn/controller/ovn-controller.h |  17 ++-
 ovn/controller/physical.c   | 180 +++--
 ovn/controller/pinctrl.c|  57 +++-
 ovn/lib/logical-fields.c|   4 +
 ovn/lib/logical-fields.h|   2 +
 ovn/northd/ovn-northd.8.xml |  56 
 ovn/northd/ovn-northd.c | 121 +
 ovn/ovn-architecture.7.xml  |  30 -
 tests/ovn.at| 284 
 12 files changed, 748 insertions(+), 19 deletions(-)

-- 
1.8.3.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v6 3/3] Document the flows for redirecting VLAN packets

[vkommadi]

From: venkata anil 

We have added new flows for using vlans instead of tunnels for
redirecting VLAN packets to a gateway chassis. This patch documents
these flows in ovn-northd.8.xml and ovn-architecture.7.xml.

Signed-off-by: Venkata Anil 
---

v5->v6:
* Rebased

v4->v5:
* This patch is added to document the logical and physical flows

 ovn/northd/ovn-northd.8.xml | 46 +
 ovn/ovn-architecture.7.xml  | 26 -
 2 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index cfd3511..96493ef 100644
--- a/ovn/northd/ovn-northd.8.xml
+++ b/ovn/northd/ovn-northd.8.xml
@@ -988,6 +988,23 @@ output;
 
   
 
+  For each enabled router port P which is connected to
+  a VLAN network, a priority-100 flow that matches inport ==
+  P  flags.rcv_from_vlan == 1,
+  with action next;.
+
+
+
+  For the gateway port on a distributed logical router (where
+  one of the logical router ports specifies a
+  redirect-chassis), the above flow is only
+  programmed on the gateway port instance on the
+  redirect-chassis.
+
+  
+
+  
+
   For each enabled router port P with Ethernet address
   E, a priority-50 flow that matches inport ==
   P  (eth.mcast || eth.dst ==
@@ -1139,6 +1156,18 @@ output;
 
   For the gateway port on a distributed logical router (where
   one of the logical router ports specifies a
+  redirect-chassis), when the ARP request is
+  from router internal ports connected to vlan network (i.e
+  flags.rcv_from_vlan == 1), a priority-90 flow matches
+   flags.rcv_from_vlan == 1  arp.op == 1
+   arp.tpa == A will have the
+  above action but outport set to all router internal ports
+  which are connected to vlan network.
+
+
+
+  For the gateway port on a distributed logical router (where
+  one of the logical router ports specifies a
   redirect-chassis), the above flows are only
   programmed on the gateway port instance on the
   redirect-chassis.  This behavior avoids generation
@@ -1818,6 +1847,23 @@ next;
   If the address A is in the link-local scope, the
   route will be limited to sending on the ingress port.
 
+
+
+  If the route's outport is a gateway port on a
+  distributed logical router (where one of the logical router ports
+  specifies a redirect-chassis), for the packets matching
+  MLF_RCV_FROM_VLAN flag along with ip4.dst ==
+  N/M, or ip6.dst ==
+  N/M, add a flow with priority we get
+  by adding 1 to number of 1-bits in M, with an action
+  REGBIT_NAT_REDIRECT  =  1;  next;.
+  By setting the REGBIT_NAT_REDIRECT flag, in the ingress
+  table Gateway Redirect this will trigger a redirect to
+  the instance of the gateway port on the redict-chassis.
+  This flow is programmed on the gateway port instance other than the
+  redirect-chassis. This flow is also added if the route
+  is from a configured static route.
+
   
 
 
diff --git a/ovn/ovn-architecture.7.xml b/ovn/ovn-architecture.7.xml
index ae5ca8e..ad2101c 100644
--- a/ovn/ovn-architecture.7.xml
+++ b/ovn/ovn-architecture.7.xml
@@ -874,6 +874,19 @@
 Encapsulations for encoding details).  Then the actions resubmit
 to table 33 to enter the logical egress pipeline.
   
+
+  
+For VLAN packets coming through localnet port from remote chassis,
+table 0 sets logical datapath and logical ingress port based on
+localnet port. If these VLAN packets have distributed gateway port MAC
+(gateway port on a distributed logical router where one of the logical
+router ports specifies a redirect-chassis) as destination MAC address,
+a new flow with priority 200 is added which sets logical datapath to
+router metadata and logical ingress port to the patch port connecting
+router and vlan network, resubmit into the logical router ingress
+pipeline i.e table 8. This flow is only programmed  on the gateway
+port instance on the redirect-chassis.
+  
 
 
 
@@ -1020,6 +1033,16 @@
   determine the output port.
 
 
+  A higher-priority rule to match packets received from router ports
+  which are connected to vlan networks, based on flag
+  MLF_RCV_FROM_VLAN, where logical output port is a gateway port, on
+  a distributed logical router (where one of the logical router ports
+  specifies a redirect-chassis), but on remote hypervisor, the actions
+  tag the packet with input network VLAN id and output the packet

[ovs-dev] [PATCH v6 2/3] Send gateway port ARP through router internal ports

[vkommadi]

From: venkata anil 

External switches should learn the distributed gateway port MAC address
as they have to forward the packet tagged with tenant vlan network but
with this MAC as destination MAC address. So router has to send ARP
reply and gARP for this MAC address through router internal patch ports
connecting tenant vlan networks.

Signed-off-by: Venkata Anil 
---

v5->v6:
* Rebased

v4->v5:
* No changes in this patch

 ovn/controller/pinctrl.c | 57 +++-
 ovn/northd/ovn-northd.c  | 57 
 tests/ovn.at |  6 +
 3 files changed, 114 insertions(+), 6 deletions(-)

diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index a0bf602..37157aa 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -2185,8 +2185,47 @@ get_nat_addresses_and_keys(struct ovsdb_idl_index 
*sbrec_chassis_by_name,
struct sset *local_l3gw_ports,
const struct sbrec_chassis *chassis,
const struct sset *active_tunnels,
-   struct shash *nat_addresses)
+   struct shash *nat_addresses,
+   struct hmap *local_datapaths)
 {
+/* When a router has tenant vlan networks, gARP for distributed gateway
+ * router port has to be sent through internal tenant vlan network's
+ * localnet port, so that external switches can learn this MAC and forward
+ * tenant vlan network traffic with distributed gateway router port MAC
+ * as destination MAC address */
+
+struct local_datapath *ldp;
+struct shash router_vlan_ports;
+
+shash_init(_vlan_ports);
+HMAP_FOR_EACH (ldp, hmap_node, local_datapaths) {
+const struct sbrec_port_binding *crp;
+crp = ldp->chassisredirect_port;
+/* check if it a router with chassis redirect port,
+ * get corresponding distributed port */
+if (crp && crp->chassis &&
+!strcmp(crp->chassis->name, chassis->name)) {
+const struct sbrec_port_binding *dp = NULL;
+for (int i = 0; i < ldp->n_peer_dps; i++) {
+if (!strcmp(ldp->peer_dps[i]->patch->logical_port,
+smap_get(>options, "distributed-port"))) {
+dp = ldp->peer_dps[i]->peer;
+break;
+}
+}
+
+/* Save router internal port (patch port on tenant vlan network)
+ * along with distributed port. */
+for (int i = 0; i < ldp->n_peer_dps; i++) {
+if (strcmp(ldp->peer_dps[i]->patch->logical_port,
+   smap_get(>options, "distributed-port"))) {
+shash_add(_vlan_ports,
+  ldp->peer_dps[i]->peer->logical_port, dp);
+}
+}
+}
+}
+
 const char *gw_port;
 SSET_FOR_EACH(gw_port, local_l3gw_ports) {
 const struct sbrec_port_binding *pb;
@@ -2196,11 +2235,16 @@ get_nat_addresses_and_keys(struct ovsdb_idl_index 
*sbrec_chassis_by_name,
 continue;
 }
 
-if (pb->n_nat_addresses) {
-for (int i = 0; i < pb->n_nat_addresses; i++) {
+/* Router internatl ports should send gARP for distributed port
+ * NAT addresses */
+const struct sbrec_port_binding *dp;
+dp = shash_find_data(_vlan_ports, pb->logical_port);
+const struct sbrec_port_binding *nat_port = dp ? dp : pb;
+if (nat_port->n_nat_addresses) {
+for (int i = 0; i < nat_port->n_nat_addresses; i++) {
 consider_nat_address(sbrec_chassis_by_name,
  sbrec_port_binding_by_name,
- pb->nat_addresses[i], pb,
+ nat_port->nat_addresses[i], pb,
  nat_address_keys, chassis,
  active_tunnels,
  nat_addresses);
@@ -2208,7 +2252,7 @@ get_nat_addresses_and_keys(struct ovsdb_idl_index 
*sbrec_chassis_by_name,
 } else {
 /* Continue to support options:nat-addresses for version
  * upgrade. */
-const char *nat_addresses_options = smap_get(>options,
+const char *nat_addresses_options = smap_get(_port->options,
  "nat-addresses");
 if (nat_addresses_options) {
 consider_nat_address(sbrec_chassis_by_name,
@@ -2220,6 +2264,7 @@ get_nat_addresses_and_keys(struct ovsdb_idl_index 
*sbrec_chassis_by_name,
 }
 }
 }
+shash_destroy(_vlan_ports);
 }
 
 static void
@@ -2255,7 +2300,7 @@ send_garp_run(struct ovsdb_idl_index 
*sbrec_chassis_by_name,
sbrec_port_binding_by_name,
 

[ovs-dev] [PATCH v6 1/3] Avoid tunneling for VLAN packets redirected to a gateway chassis

[vkommadi]

From: venkata anil 

When a vm on a vlan tenant network sends traffic to an external network,
it is tunneled from host chassis to gateway chassis. In the earlier
discussion [1], Russel (also in his doc [2]) suggested if we can figure
out a way for OVN to do this redirect to the gateway host over a VLAN
network. This patch implements his suggestion i.e will redirect to
gateway chassis using incoming tenant vlan network. Gateway chassis are
expected to be configured with tenant vlan networks. In this approach,
new logical and physical flows introduced for packet processing in both
host and gateway chassis.

Packet processing in the host chassis:
1) A new ovs flow added in physical table 65, which sets MLF_RCV_FROM_VLAN
   flag for packets from vlan network entering into router pipeline
2) A new flow added in lr_in_ip_routing, for packets output through
   distributed gateway port and matching MLF_RCV_FROM_VLAN flag,
   set REGBIT_NAT_REDIRECT i.e
   table=7 (lr_in_ip_routing   ), priority=2, match=(
   ip4.dst == 0.0.0.0/0 && flags.rcv_from_vlan == 1 &&
   !is_chassis_resident("cr-alice")), action=(reg9[0] = 1; next;)
   This flow will be set only on chassis not hosting chassisredirect
   port i.e compute node.
   When REGBIT_NAT_REDIRECT set,
   a) lr_in_arp_resolve, will set packet eth.dst to distibuted gateway
  port MAC
   b) lr_in_gw_redirect, will set chassisredirect port as outport
3) A new ovs flow added in physical table 32 will use source vlan tenant
   network tag as vlan ID for sending the packet to gateway chassis.
   As this vlan packet destination MAC is distibuted gateway port MAC,
   packet will only reach the gateway chassis.
   table=32,priority=150,reg10=0x20/0x20,reg14=0x3,reg15=0x6,metadata=0x4
   actions=mod_vlan_vid:2010,output:25,strip_vlan
   This flow will be set only on chassis not hosting chassisredirect
   port i.e compute node.

Packet processing in the gateway chassis:
1) A new ovs flow added in physical table 0 for vlan traffic coming
   from localnet port with router distributed gateway port MAC as
   destination MAC address, resubmit to connected router ingress pipeline
   (i.e router attached to vlan tenant network).
   table=0,priority=150,in_port=67,dl_vlan=2010,dl_dst=00:00:02:01:02:03
   actions=strip_vlan,load:0x4->OXM_OF_METADATA[],load:0x3->NXM_NX_REG14[],
   load:0x1->NXM_NX_REG10[5],resubmit(,8)
   This flow will be set only on chassis hosting chassisredirect
   port i.e gateway node.
2) A new flow added in lr_in_admission which checks MLF_RCV_FROM_VLAN
   and allows the packet. This flow will be set only on chassis hosting
   chassisredirect port i.e gateway node.
   table=0 (lr_in_admission), priority=100  , match=(
   flags.rcv_from_vlan == 1 && inport == "lrp-44383893-613a-4bfe-b483-
   e7d0dc3055cd" && is_chassis_resident("cr-lrp-a6e3d2ab-313a-4ea3-
   8ec4-c3c774a11f49")), action=(next;)
   Then packet will pass through router ingress and egress pipelines and
   then to external switch pipeline.

[1] https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046557.html
[2] Point 3 in section 3.3.1 - Future Enhancements

https://docs.google.com/document/d/1JecGIXPH0RAqfGvD0nmtBdEU1zflHACp8WSRnKCFSgg/edit#

Reported-at: 
https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046543.html

Signed-off-by: Venkata Anil 
---

v5->v6:
* Rebased

v4->v5:
* No changes in this patch

v3->v4:
* Previous v3 patch became this patch of v4
* Updated the newly added flow in physical table 0 on gateway chassis
  to check for distributed gateway port MAC and then resubmit to
  router ingress pipeline
* Improved the test
* Added more comments

 ovn/controller/bfd.c|   3 +-
 ovn/controller/binding.c|  10 +-
 ovn/controller/ovn-controller.c |   3 +
 ovn/controller/ovn-controller.h |  17 ++-
 ovn/controller/physical.c   | 121 -
 ovn/lib/logical-fields.c|   4 +
 ovn/lib/logical-fields.h|   2 +
 ovn/northd/ovn-northd.c |  35 +
 tests/ovn.at| 278 
 9 files changed, 465 insertions(+), 8 deletions(-)

diff --git a/ovn/controller/bfd.c b/ovn/controller/bfd.c
index 051781f..c696741 100644
--- a/ovn/controller/bfd.c
+++ b/ovn/controller/bfd.c
@@ -139,8 +139,9 @@ bfd_travel_gw_related_chassis(
 LIST_FOR_EACH_POP (dp_binding, node, _list) {
 dp = dp_binding->dp;
 free(dp_binding);
+const struct sbrec_datapath_binding *pdp;
 for (size_t i = 0; i < dp->n_peer_dps; i++) {
-const struct sbrec_datapath_binding *pdp = dp->peer_dps[i];
+pdp = dp->peer_dps[i]->peer_dp;
 if (!pdp) {
 continue;
 }
diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
index 021ecdd..de4385f 100644
--- a/ovn/controller/binding.c
+++ b/ovn/controller/binding.c
@@ -145,10 +145,14 @@ add_local_datapath__(struct ovsdb_idl_index 
*sbrec_datapath_binding_by_key,
 

[ovs-dev] [PATCH v6 0/3] Use VLANs for VLAN packets redirected to a gateway chassis

[vkommadi]

From: venkata anil 


This patch avoids tunneling and instead uses source tenant vlan network
across hypervisors for traffic from vlan network on local hypervisor
towards gateway hypervisor hosting redirect chassiss port.

On the local hypervisor, when the packet enters logical router ingress
pipeline from tenant vlan network, router will set REGBIT_NAT_REDIRECT
and redirect the packet to gateway hypervisor, which is hosting the
chassis redirect port, using tenant vlan network.
Packet travelling across hypervisors will have source vlan tag and
distributed gateway port MAC as destination MAC (other packet data
unchanged).

Gateway hypervisor will check the vlan tag and destination MAC and
resubmit it to router logical ingress pipeline for routing and finding 
the logical output port(i.e it treats this packet as coming from the 
local patch port connected to tenant vlan network for routing).

No changes done for return path as return path to source hypervisor
always uses tenant vlan networks.

v5->v6:
* Rebased

v4->v5
* Rebased
* New patch 3 for Documentation(no changes in other patches)

v3->v4:
* Rebased
* Splitting patch into patch series. Entire patch of v3 became patch 1
  of this series.
* Updated flow in gateway chassis to check gateway port MAC address
  (in patch 1)
* New patch 2 for ARP/gARP of gateway port through router internal ports

venkata anil (3):
  Avoid tunneling for VLAN packets redirected to a gateway chassis
  Send gateway port ARP through router internal ports
  Document the flows for redirecting VLAN packets

 ovn/controller/bfd.c|   3 +-
 ovn/controller/binding.c|  10 +-
 ovn/controller/ovn-controller.c |   3 +
 ovn/controller/ovn-controller.h |  17 ++-
 ovn/controller/physical.c   | 121 -
 ovn/controller/pinctrl.c|  57 +++-
 ovn/lib/logical-fields.c|   4 +
 ovn/lib/logical-fields.h|   2 +
 ovn/northd/ovn-northd.8.xml |  46 +++
 ovn/northd/ovn-northd.c |  92 +
 ovn/ovn-architecture.7.xml  |  26 +++-
 tests/ovn.at| 284 
 12 files changed, 650 insertions(+), 15 deletions(-)

-- 
1.8.3.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v5 3/3] Document the flows for redirecting VLAN packets

[vkommadi]

From: Venkata Anil 

We have added new flows for using vlans instead of tunnels for
redirecting VLAN packets to a gateway chassis. This patch documents
these flows in ovn-northd.8.xml and ovn-architecture.7.xml.

Signed-off-by: Venkata Anil 
---

v4->v5:
* This patch is added to document the logical and physical flows

 ovn/northd/ovn-northd.8.xml | 46 +
 ovn/ovn-architecture.7.xml  | 26 -
 2 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index 1d68f1a..6c473f7 100644
--- a/ovn/northd/ovn-northd.8.xml
+++ b/ovn/northd/ovn-northd.8.xml
@@ -988,6 +988,23 @@ output;
 
   
 
+  For each enabled router port P which is connected to
+  a VLAN network, a priority-100 flow that matches inport ==
+  P  flags.rcv_from_vlan == 1,
+  with action next;.
+
+
+
+  For the gateway port on a distributed logical router (where
+  one of the logical router ports specifies a
+  redirect-chassis), the above flow is only
+  programmed on the gateway port instance on the
+  redirect-chassis.
+
+  
+
+  
+
   For each enabled router port P with Ethernet address
   E, a priority-50 flow that matches inport ==
   P  (eth.mcast || eth.dst ==
@@ -1139,6 +1156,18 @@ output;
 
   For the gateway port on a distributed logical router (where
   one of the logical router ports specifies a
+  redirect-chassis), when the ARP request is
+  from router internal ports connected to vlan network (i.e
+  flags.rcv_from_vlan == 1), a priority-90 flow matches
+   flags.rcv_from_vlan == 1  arp.op == 1
+   arp.tpa == A will have the
+  above action but outport set to all router internal ports
+  which are connected to vlan network.
+
+
+
+  For the gateway port on a distributed logical router (where
+  one of the logical router ports specifies a
   redirect-chassis), the above flows are only
   programmed on the gateway port instance on the
   redirect-chassis.  This behavior avoids generation
@@ -1834,6 +1863,23 @@ next;
   If the address A is in the link-local scope, the
   route will be limited to sending on the ingress port.
 
+
+
+  If the route's outport is a gateway port on a
+  distributed logical router (where one of the logical router ports
+  specifies a redirect-chassis), for the packets matching
+  MLF_RCV_FROM_VLAN flag along with ip4.dst ==
+  N/M, or ip6.dst ==
+  N/M, add a flow with priority we get
+  by adding 1 to number of 1-bits in M, with an action
+  REGBIT_NAT_REDIRECT  =  1;  next;.
+  By setting the REGBIT_NAT_REDIRECT flag, in the ingress
+  table Gateway Redirect this will trigger a redirect to
+  the instance of the gateway port on the redict-chassis.
+  This flow is programmed on the gateway port instance other than the
+  redirect-chassis. This flow is also added if the route
+  is from a configured static route.
+
   
 
 
diff --git a/ovn/ovn-architecture.7.xml b/ovn/ovn-architecture.7.xml
index ae5ca8e..ad2101c 100644
--- a/ovn/ovn-architecture.7.xml
+++ b/ovn/ovn-architecture.7.xml
@@ -874,6 +874,19 @@
 Encapsulations for encoding details).  Then the actions resubmit
 to table 33 to enter the logical egress pipeline.
   
+
+  
+For VLAN packets coming through localnet port from remote chassis,
+table 0 sets logical datapath and logical ingress port based on
+localnet port. If these VLAN packets have distributed gateway port MAC
+(gateway port on a distributed logical router where one of the logical
+router ports specifies a redirect-chassis) as destination MAC address,
+a new flow with priority 200 is added which sets logical datapath to
+router metadata and logical ingress port to the patch port connecting
+router and vlan network, resubmit into the logical router ingress
+pipeline i.e table 8. This flow is only programmed  on the gateway
+port instance on the redirect-chassis.
+  
 
 
 
@@ -1020,6 +1033,16 @@
   determine the output port.
 
 
+  A higher-priority rule to match packets received from router ports
+  which are connected to vlan networks, based on flag
+  MLF_RCV_FROM_VLAN, where logical output port is a gateway port, on
+  a distributed logical router (where one of the logical router ports
+  specifies a redirect-chassis), but on remote hypervisor, the actions
+  tag the packet with input network VLAN id and output the packet
+  through 

[ovs-dev] [PATCH v5 2/3] Send gateway port ARP through router internal ports

[vkommadi]

From: Venkata Anil 

External switches should learn the distributed gateway port MAC address
as they have to forward the packet tagged with tenant vlan network but
with this MAC as destination MAC address. So router has to send ARP
reply and gARP for this MAC address through router internal patch ports
connecting tenant vlan networks.

Signed-off-by: Venkata Anil 
---

v4->v5:
* No changes in this patch


 ovn/controller/pinctrl.c | 57 +++-
 ovn/northd/ovn-northd.c  | 57 
 tests/ovn.at |  6 +
 3 files changed, 114 insertions(+), 6 deletions(-)

diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index 305f206..222bc1c 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -2157,8 +2157,47 @@ get_nat_addresses_and_keys(struct controller_ctx *ctx,
const struct sbrec_chassis *chassis,
const struct chassis_index *chassis_index,
struct sset *active_tunnels,
-   struct shash *nat_addresses)
+   struct shash *nat_addresses,
+   struct hmap *local_datapaths)
 {
+/* When a router has tenant vlan networks, gARP for distributed gateway
+ * router port has to be sent through internal tenant vlan network's
+ * localnet port, so that external switches can learn this MAC and forward
+ * tenant vlan network traffic with distributed gateway router port MAC
+ * as destination MAC address */
+
+struct local_datapath *ldp;
+struct shash router_vlan_ports;
+
+shash_init(_vlan_ports);
+HMAP_FOR_EACH (ldp, hmap_node, local_datapaths) {
+const struct sbrec_port_binding *crp;
+crp = ldp->chassisredirect_port;
+/* check if it a router with chassis redirect port,
+ * get corresponding distributed port */
+if (crp && crp->chassis &&
+!strcmp(crp->chassis->name, chassis->name)) {
+const struct sbrec_port_binding *dp = NULL;
+for (int i = 0; i < ldp->n_peer_dps; i++) {
+if (!strcmp(ldp->peer_dps[i]->patch->logical_port,
+smap_get(>options, "distributed-port"))) {
+dp = ldp->peer_dps[i]->peer;
+break;
+}
+}
+
+/* Save router internal port (patch port on tenant vlan network)
+ * along with distributed port. */
+for (int i = 0; i < ldp->n_peer_dps; i++) {
+if (strcmp(ldp->peer_dps[i]->patch->logical_port,
+   smap_get(>options, "distributed-port"))) {
+shash_add(_vlan_ports,
+  ldp->peer_dps[i]->peer->logical_port, dp);
+}
+}
+}
+}
+
 const char *gw_port;
 SSET_FOR_EACH(gw_port, local_l3gw_ports) {
 const struct sbrec_port_binding *pb;
@@ -2168,9 +2207,14 @@ get_nat_addresses_and_keys(struct controller_ctx *ctx,
 continue;
 }
 
-if (pb->n_nat_addresses) {
-for (int i = 0; i < pb->n_nat_addresses; i++) {
-consider_nat_address(ctx, pb->nat_addresses[i], pb,
+/* Router internatl ports should send gARP for distributed port
+ * NAT addresses */
+const struct sbrec_port_binding *dp;
+dp = shash_find_data(_vlan_ports, pb->logical_port);
+const struct sbrec_port_binding *nat_port = dp ? dp : pb;
+if (nat_port->n_nat_addresses) {
+for (int i = 0; i < nat_port->n_nat_addresses; i++) {
+consider_nat_address(ctx, nat_port->nat_addresses[i], pb,
  nat_address_keys, chassis,
  chassis_index, active_tunnels,
  nat_addresses);
@@ -2178,7 +,7 @@ get_nat_addresses_and_keys(struct controller_ctx *ctx,
 } else {
 /* Continue to support options:nat-addresses for version
  * upgrade. */
-const char *nat_addresses_options = smap_get(>options,
+const char *nat_addresses_options = smap_get(_port->options,
  "nat-addresses");
 if (nat_addresses_options) {
 consider_nat_address(ctx, nat_addresses_options, pb,
@@ -2188,6 +2232,7 @@ get_nat_addresses_and_keys(struct controller_ctx *ctx,
 }
 }
 }
+   shash_destroy(_vlan_ports);
 }
 
 static void
@@ -2217,7 +2262,7 @@ send_garp_run(struct controller_ctx *ctx,
 
 get_nat_addresses_and_keys(ctx, _ip_keys, _l3gw_ports,
chassis, chassis_index, active_tunnels,
-   _addresses);
+   _addresses, local_datapaths);
 /* For deleted ports and deleted 

[ovs-dev] [PATCH v5 1/3] Avoid tunneling for VLAN packets redirected to a gateway chassis

[vkommadi]

From: Venkata Anil 

When a vm on a vlan tenant network sends traffic to an external network,
it is tunneled from host chassis to gateway chassis. In the earlier
discussion [1], Russel (also in his doc [2]) suggested if we can figure
out a way for OVN to do this redirect to the gateway host over a VLAN
network. This patch implements his suggestion i.e will redirect to
gateway chassis using incoming tenant vlan network. Gateway chassis are
expected to be configured with tenant vlan networks. In this approach,
new logical and physical flows introduced for packet processing in both
host and gateway chassis.

Packet processing in the host chassis:
1) A new ovs flow added in physical table 65, which sets MLF_RCV_FROM_VLAN
   flag for packets from vlan network entering into router pipeline
2) A new flow added in lr_in_ip_routing, for packets output through
   distributed gateway port and matching MLF_RCV_FROM_VLAN flag,
   set REGBIT_NAT_REDIRECT i.e
   table=7 (lr_in_ip_routing   ), priority=2, match=(
   ip4.dst == 0.0.0.0/0 && flags.rcv_from_vlan == 1 &&
   !is_chassis_resident("cr-alice")), action=(reg9[0] = 1; next;)
   This flow will be set only on chassis not hosting chassisredirect
   port i.e compute node.
   When REGBIT_NAT_REDIRECT set,
   a) lr_in_arp_resolve, will set packet eth.dst to distibuted gateway
  port MAC
   b) lr_in_gw_redirect, will set chassisredirect port as outport
3) A new ovs flow added in physical table 32 will use source vlan tenant
   network tag as vlan ID for sending the packet to gateway chassis.
   As this vlan packet destination MAC is distibuted gateway port MAC,
   packet will only reach the gateway chassis.
   table=32,priority=150,reg10=0x20/0x20,reg14=0x3,reg15=0x6,metadata=0x4
   actions=mod_vlan_vid:2010,output:25,strip_vlan
   This flow will be set only on chassis not hosting chassisredirect
   port i.e compute node.

Packet processing in the gateway chassis:
1) A new ovs flow added in physical table 0 for vlan traffic coming
   from localnet port with router distributed gateway port MAC as
   destination MAC address, resubmit to connected router ingress pipeline
   (i.e router attached to vlan tenant network).
   table=0,priority=150,in_port=67,dl_vlan=2010,dl_dst=00:00:02:01:02:03
   actions=strip_vlan,load:0x4->OXM_OF_METADATA[],load:0x3->NXM_NX_REG14[],
   load:0x1->NXM_NX_REG10[5],resubmit(,8)
   This flow will be set only on chassis hosting chassisredirect
   port i.e gateway node.
2) A new flow added in lr_in_admission which checks MLF_RCV_FROM_VLAN
   and allows the packet. This flow will be set only on chassis hosting
   chassisredirect port i.e gateway node.
   table=0 (lr_in_admission), priority=100  , match=(
   flags.rcv_from_vlan == 1 && inport == "lrp-44383893-613a-4bfe-b483-
   e7d0dc3055cd" && is_chassis_resident("cr-lrp-a6e3d2ab-313a-4ea3-
   8ec4-c3c774a11f49")), action=(next;)
   Then packet will pass through router ingress and egress pipelines and
   then to external switch pipeline.

[1] https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046557.html
[2] Point 3 in section 3.3.1 - Future Enhancements

https://docs.google.com/document/d/1JecGIXPH0RAqfGvD0nmtBdEU1zflHACp8WSRnKCFSgg/edit#

Reported-at: 
https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046543.html

Signed-off-by: Venkata Anil 
---

v4->v5:
* No changes in this patch

v3->v4:
* Previous v3 patch became this patch of v4
* Updated the newly added flow in physical table 0 on gateway chassis
  to check for distributed gateway port MAC and then resubmit to
  router ingress pipeline
* Improved the test
* Added more comments

 ovn/controller/bfd.c|   3 +-
 ovn/controller/binding.c|  10 +-
 ovn/controller/ovn-controller.c |   3 +
 ovn/controller/ovn-controller.h |  17 ++-
 ovn/controller/physical.c   | 121 -
 ovn/lib/logical-fields.c|   4 +
 ovn/lib/logical-fields.h|   2 +
 ovn/northd/ovn-northd.c |  35 +
 tests/ovn.at| 279 +++-
 9 files changed, 465 insertions(+), 9 deletions(-)

diff --git a/ovn/controller/bfd.c b/ovn/controller/bfd.c
index 8f020d5..cbbd3ba 100644
--- a/ovn/controller/bfd.c
+++ b/ovn/controller/bfd.c
@@ -139,8 +139,9 @@ bfd_travel_gw_related_chassis(struct local_datapath *dp,
   struct local_datapath_node, node);
 dp = dp_binding->dp;
 free(dp_binding);
+const struct sbrec_datapath_binding *pdp;
 for (size_t i = 0; i < dp->n_peer_dps; i++) {
-const struct sbrec_datapath_binding *pdp = dp->peer_dps[i];
+pdp = dp->peer_dps[i]->peer_dp;
 if (!pdp) {
 continue;
 }
diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
index 0785a94..f02bde5 100644
--- a/ovn/controller/binding.c
+++ b/ovn/controller/binding.c
@@ -148,10 +148,14 @@ add_local_datapath__(struct controller_ctx *ctx,
   

[ovs-dev] [PATCH v5 0/3] Use VLANs for VLAN packets redirected to a gateway chassis

[vkommadi]

From: Venkata Anil 

This patch avoids tunneling and instead uses source tenant vlan network
across hypervisors for traffic from vlan network on local hypervisor
towards gateway hypervisor hosting redirect chassiss port.

On the local hypervisor, when the packet enters logical router ingress
pipeline from tenant vlan network, router will set REGBIT_NAT_REDIRECT
and redirect the packet to gateway hypervisor, which is hosting the
chassis redirect port, using tenant vlan network.
Packet travelling across hypervisors will have source vlan tag and
distributed gateway port MAC as destination MAC (other packet data
unchanged).

Gateway hypervisor will check the vlan tag and destination MAC and
resubmit it to router logical ingress pipeline for routing and finding 
the logical output port(i.e it treats this packet as coming from the 
local patch port connected to tenant vlan network for routing).

No changes done for return path as return path to source hypervisor
always uses tenant vlan networks.

v4->v5
* Rebased
* New patch 3 for Documentation(no changes in other patches)

v3->v4:
* Rebased
* Splitting patch into patch series. Entire patch of v3 became patch 1
  of this series.
* Updated flow in gateway chassis to check gateway port MAC address
  (in patch 1)
* New patch 2 for ARP/gARP of gateway port through router internal ports


Venkata Anil (3):
  Avoid tunneling for VLAN packets redirected to a gateway chassis
  Send gateway port ARP through router internal ports
  Document the flows for redirecting VLAN packets

 ovn/controller/bfd.c|   3 +-
 ovn/controller/binding.c|  10 +-
 ovn/controller/ovn-controller.c |   3 +
 ovn/controller/ovn-controller.h |  17 ++-
 ovn/controller/physical.c   | 121 -
 ovn/controller/pinctrl.c|  57 +++-
 ovn/lib/logical-fields.c|   4 +
 ovn/lib/logical-fields.h|   2 +
 ovn/northd/ovn-northd.8.xml |  46 +++
 ovn/northd/ovn-northd.c |  92 +
 ovn/ovn-architecture.7.xml  |  26 +++-
 tests/ovn.at| 285 +++-
 12 files changed, 650 insertions(+), 16 deletions(-)

-- 
1.8.3.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v4 2/2] Send gateway port ARP through router internal ports

[vkommadi]

From: Venkata Anil 

External switches should learn the distributed gateway port MAC address
as they have to forward the packet tagged with tenant vlan network but
with this MAC as destination MAC address. So router has to send ARP
reply and gARP for this MAC address through router internal patch ports
connecting tenant vlan networks.

Signed-off-by: Venkata Anil 
---
 ovn/controller/pinctrl.c | 57 +++-
 ovn/northd/ovn-northd.c  | 57 
 tests/ovn.at |  6 +
 3 files changed, 114 insertions(+), 6 deletions(-)

diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index 305f206..222bc1c 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -2157,8 +2157,47 @@ get_nat_addresses_and_keys(struct controller_ctx *ctx,
const struct sbrec_chassis *chassis,
const struct chassis_index *chassis_index,
struct sset *active_tunnels,
-   struct shash *nat_addresses)
+   struct shash *nat_addresses,
+   struct hmap *local_datapaths)
 {
+/* When a router has tenant vlan networks, gARP for distributed gateway
+ * router port has to be sent through internal tenant vlan network's
+ * localnet port, so that external switches can learn this MAC and forward
+ * tenant vlan network traffic with distributed gateway router port MAC
+ * as destination MAC address */
+
+struct local_datapath *ldp;
+struct shash router_vlan_ports;
+
+shash_init(_vlan_ports);
+HMAP_FOR_EACH (ldp, hmap_node, local_datapaths) {
+const struct sbrec_port_binding *crp;
+crp = ldp->chassisredirect_port;
+/* check if it a router with chassis redirect port,
+ * get corresponding distributed port */
+if (crp && crp->chassis &&
+!strcmp(crp->chassis->name, chassis->name)) {
+const struct sbrec_port_binding *dp = NULL;
+for (int i = 0; i < ldp->n_peer_dps; i++) {
+if (!strcmp(ldp->peer_dps[i]->patch->logical_port,
+smap_get(>options, "distributed-port"))) {
+dp = ldp->peer_dps[i]->peer;
+break;
+}
+}
+
+/* Save router internal port (patch port on tenant vlan network)
+ * along with distributed port. */
+for (int i = 0; i < ldp->n_peer_dps; i++) {
+if (strcmp(ldp->peer_dps[i]->patch->logical_port,
+   smap_get(>options, "distributed-port"))) {
+shash_add(_vlan_ports,
+  ldp->peer_dps[i]->peer->logical_port, dp);
+}
+}
+}
+}
+
 const char *gw_port;
 SSET_FOR_EACH(gw_port, local_l3gw_ports) {
 const struct sbrec_port_binding *pb;
@@ -2168,9 +2207,14 @@ get_nat_addresses_and_keys(struct controller_ctx *ctx,
 continue;
 }
 
-if (pb->n_nat_addresses) {
-for (int i = 0; i < pb->n_nat_addresses; i++) {
-consider_nat_address(ctx, pb->nat_addresses[i], pb,
+/* Router internatl ports should send gARP for distributed port
+ * NAT addresses */
+const struct sbrec_port_binding *dp;
+dp = shash_find_data(_vlan_ports, pb->logical_port);
+const struct sbrec_port_binding *nat_port = dp ? dp : pb;
+if (nat_port->n_nat_addresses) {
+for (int i = 0; i < nat_port->n_nat_addresses; i++) {
+consider_nat_address(ctx, nat_port->nat_addresses[i], pb,
  nat_address_keys, chassis,
  chassis_index, active_tunnels,
  nat_addresses);
@@ -2178,7 +,7 @@ get_nat_addresses_and_keys(struct controller_ctx *ctx,
 } else {
 /* Continue to support options:nat-addresses for version
  * upgrade. */
-const char *nat_addresses_options = smap_get(>options,
+const char *nat_addresses_options = smap_get(_port->options,
  "nat-addresses");
 if (nat_addresses_options) {
 consider_nat_address(ctx, nat_addresses_options, pb,
@@ -2188,6 +2232,7 @@ get_nat_addresses_and_keys(struct controller_ctx *ctx,
 }
 }
 }
+   shash_destroy(_vlan_ports);
 }
 
 static void
@@ -2217,7 +2262,7 @@ send_garp_run(struct controller_ctx *ctx,
 
 get_nat_addresses_and_keys(ctx, _ip_keys, _l3gw_ports,
chassis, chassis_index, active_tunnels,
-   _addresses);
+   _addresses, local_datapaths);
 /* For deleted ports and deleted nat ips, remove from send_garp_data. 

[ovs-dev] [PATCH v4 0/2] Use VLANs for VLAN packets redirected to a gateway chassis

[vkommadi]

From: Venkata Anil 

This patch avoids tunneling and instead uses source tenant vlan network
across hypervisors for traffic from vlan network on local hypervisor
towards gateway hypervisor hosting redirect chassiss port.

On the local hypervisor, when the packet enters logical router ingress
pipeline from tenant vlan network, router will set REGBIT_NAT_REDIRECT
and redirect the packet to gateway hypervisor, which is hosting the
chassis redirect port, using tenant vlan network.
Packet travelling across hypervisors will have source vlan tag and
distributed gateway port MAC as destination MAC (other packet data
unchanged).

Gateway hypervisor will check the vlan tag and destination MAC and
resubmit it to router logical ingress pipeline for routing and finding 
the logical output port(i.e it treats this packet as coming from the 
local patch port connected to tenant vlan network for routing).

No changes done for return path as return path to source hypervisor
always uses tenant vlan networks.

v3->v4:
* Rebased
* Splitting patch into patch series. Entire patch of v3 became patch 1
  of this series.
* Updated flow in gateway chassis to check gateway port MAC address
  (in patch 1)
* New patch 2 for ARP/gARP of gateway port through router internal ports


Venkata Anil (2):
  Avoid tunneling for VLAN packets redirected to a gateway chassis
  Send gateway port ARP through router internal ports

 ovn/controller/bfd.c|   3 +-
 ovn/controller/binding.c|  10 +-
 ovn/controller/ovn-controller.c |   3 +
 ovn/controller/ovn-controller.h |  17 ++-
 ovn/controller/physical.c   | 121 -
 ovn/controller/pinctrl.c|  57 +++-
 ovn/lib/logical-fields.c|   4 +
 ovn/lib/logical-fields.h|   2 +
 ovn/northd/ovn-northd.c |  92 +
 tests/ovn.at| 285 +++-
 10 files changed, 579 insertions(+), 15 deletions(-)

-- 
1.8.3.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v4 1/2] Avoid tunneling for VLAN packets redirected to a gateway chassis

[vkommadi]

From: Venkata Anil 

When a vm on a vlan tenant network sends traffic to an external network,
it is tunneled from host chassis to gateway chassis. In the earlier
discussion [1], Russel (also in his doc [2]) suggested if we can figure
out a way for OVN to do this redirect to the gateway host over a VLAN
network. This patch implements his suggestion i.e will redirect to
gateway chassis using incoming tenant vlan network. Gateway chassis are
expected to be configured with tenant vlan networks. In this approach,
new logical and physical flows introduced for packet processing in both
host and gateway chassis.

Packet processing in the host chassis:
1) A new ovs flow added in physical table 65, which sets MLF_RCV_FROM_VLAN
   flag for packets from vlan network entering into router pipeline
2) A new flow added in lr_in_ip_routing, for packets output through
   distributed gateway port and matching MLF_RCV_FROM_VLAN flag,
   set REGBIT_NAT_REDIRECT i.e
   table=7 (lr_in_ip_routing   ), priority=2, match=(
   ip4.dst == 0.0.0.0/0 && flags.rcv_from_vlan == 1 &&
   !is_chassis_resident("cr-alice")), action=(reg9[0] = 1; next;)
   This flow will be set only on chassis not hosting chassisredirect
   port i.e compute node.
   When REGBIT_NAT_REDIRECT set,
   a) lr_in_arp_resolve, will set packet eth.dst to distibuted gateway
  port MAC
   b) lr_in_gw_redirect, will set chassisredirect port as outport
3) A new ovs flow added in physical table 32 will use source vlan tenant
   network tag as vlan ID for sending the packet to gateway chassis.
   As this vlan packet destination MAC is distibuted gateway port MAC,
   packet will only reach the gateway chassis.
   table=32,priority=150,reg10=0x20/0x20,reg14=0x3,reg15=0x6,metadata=0x4
   actions=mod_vlan_vid:2010,output:25,strip_vlan
   This flow will be set only on chassis not hosting chassisredirect
   port i.e compute node.

Packet processing in the gateway chassis:
1) A new ovs flow added in physical table 0 for vlan traffic coming
   from localnet port with router distributed gateway port MAC as
   destination MAC address, resubmit to connected router ingress pipeline
   (i.e router attached to vlan tenant network).
   table=0,priority=150,in_port=67,dl_vlan=2010,dl_dst=00:00:02:01:02:03
   actions=strip_vlan,load:0x4->OXM_OF_METADATA[],load:0x3->NXM_NX_REG14[],
   load:0x1->NXM_NX_REG10[5],resubmit(,8)
   This flow will be set only on chassis hosting chassisredirect
   port i.e gateway node.
2) A new flow added in lr_in_admission which checks MLF_RCV_FROM_VLAN
   and allows the packet. This flow will be set only on chassis hosting
   chassisredirect port i.e gateway node.
   table=0 (lr_in_admission), priority=100  , match=(
   flags.rcv_from_vlan == 1 && inport == "lrp-44383893-613a-4bfe-b483-
   e7d0dc3055cd" && is_chassis_resident("cr-lrp-a6e3d2ab-313a-4ea3-
   8ec4-c3c774a11f49")), action=(next;)
   Then packet will pass through router ingress and egress pipelines and
   then to external switch pipeline.

[1] https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046557.html
[2] Point 3 in section 3.3.1 - Future Enhancements

https://docs.google.com/document/d/1JecGIXPH0RAqfGvD0nmtBdEU1zflHACp8WSRnKCFSgg/edit#

Reported-at: 
https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046543.html

Signed-off-by: Venkata Anil 
---


v3->v4:
* Previous v3 patch became this patch of v4
* Updated the newly added flow in physical table 0 on gateway chassis
  to check for distributed gateway port MAC and then resubmit to
  router ingress pipeline
* Improved the test
* Added more comments


 ovn/controller/bfd.c|   3 +-
 ovn/controller/binding.c|  10 +-
 ovn/controller/ovn-controller.c |   3 +
 ovn/controller/ovn-controller.h |  17 ++-
 ovn/controller/physical.c   | 121 -
 ovn/lib/logical-fields.c|   4 +
 ovn/lib/logical-fields.h|   2 +
 ovn/northd/ovn-northd.c |  35 +
 tests/ovn.at| 279 +++-
 9 files changed, 465 insertions(+), 9 deletions(-)

diff --git a/ovn/controller/bfd.c b/ovn/controller/bfd.c
index 8f020d5..cbbd3ba 100644
--- a/ovn/controller/bfd.c
+++ b/ovn/controller/bfd.c
@@ -139,8 +139,9 @@ bfd_travel_gw_related_chassis(struct local_datapath *dp,
   struct local_datapath_node, node);
 dp = dp_binding->dp;
 free(dp_binding);
+const struct sbrec_datapath_binding *pdp;
 for (size_t i = 0; i < dp->n_peer_dps; i++) {
-const struct sbrec_datapath_binding *pdp = dp->peer_dps[i];
+pdp = dp->peer_dps[i]->peer_dp;
 if (!pdp) {
 continue;
 }
diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
index 0785a94..f02bde5 100644
--- a/ovn/controller/binding.c
+++ b/ovn/controller/binding.c
@@ -148,10 +148,14 @@ add_local_datapath__(struct controller_ctx *ctx,
 

[ovs-dev] [PATCH v3] Avoid tunneling for VLAN packets redirected to a gateway chassis

[vkommadi]

From: venkata anil 

When a vm on a vlan tenant network sends traffic to an external network,
it is tunneled from host chassis to gateway chassis. In the earlier
discussion [1], Russel (also in his doc [2]) suggested if we can figure
out a way for OVN to do this redirect to the gateway host over a VLAN
network. This patch implements his suggestion i.e will redirect to
gateway chassis using incoming tenant vlan network. Gateway chassis are
expected to be configured with tenant vlan networks. In this approach,
new logical and physical flows introduced for packet processing in both
host and gateway chassis.

Packet processing in the host chassis:
1) A new ovs flow added in physical table 65, which sets MLF_RCV_FROM_VLAN
   flag for packets from vlan network entering into router pipeline
2) A new flow added in lr_in_ip_routing, for packets output through
   distributed gateway port and matching MLF_RCV_FROM_VLAN flag,
   set REGBIT_NAT_REDIRECT i.e
   table=7 (lr_in_ip_routing   ), priority=2, match=(
   ip4.dst == 0.0.0.0/0 && flags.rcv_from_vlan == 1 &&
   !is_chassis_resident("cr-alice")), action=(reg9[0] = 1; next;)
   This flow will be set only on chassis not hosting chassisredirect
   port i.e compute node.
   When REGBIT_NAT_REDIRECT set,
   a) lr_in_arp_resolve, will set packet eth.dst to distibuted gateway
  port MAC
   b) lr_in_gw_redirect, will set chassisredirect port as outport
3) A new ovs flow added in physical table 32 will use source vlan tenant
   network tag as vlan ID for sending the packet to gateway chassis.
   As this vlan packet destination MAC is distibuted gateway port MAC,
   packet will only reach the gateway chassis.
   table=32,priority=150,reg14=0x3,reg15=0x6,metadata=0x4
   actions=mod_vlan_vid:2010,output:25,strip_vlan
   This flow will be set only on chassis not hosting chassisredirect
   port i.e compute node.

Packet processing in the gateway chassis:
1) A new ovs flow added in physical table 0 to pass vlan traffic coming
   from localnet port to the connected router pipeline(i.e router
   attached to vlan tenant network).
   This flow will set router metadata, reg14 to router's patch port(lrp)
   (i.e patch port connecting router and vlan tenant network) and a new
   MLF_RCV_FROM_VLAN flag.
   table=0,priority=150,in_port=67,dl_vlan=2010 actions=strip_vlan,
   load:0x4->OXM_OF_METADATA[],load:0x3->NXM_NX_REG14[],
   load:0x1->NXM_NX_REG10[5],resubmit(,8)
   This flow will be set only on chassis hosting chassisredirect
   port i.e gateway node.
2) A new flow added in lr_in_admission which checks MLF_RCV_FROM_VLAN
   and allows the packet. This flow will be set only on chassis hosting
   chassisredirect port i.e gateway node.
   table=0 (lr_in_admission), priority=100  , match=(
   flags.rcv_from_vlan == 1 && inport == "lrp-44383893-613a-4bfe-b483-
   e7d0dc3055cd" && is_chassis_resident("cr-lrp-a6e3d2ab-313a-4ea3-
   8ec4-c3c774a11f49")), action=(next;)
   Then packet will pass through router ingress and egress pipelines and
   then to external switch pipeline.

In a scenario where the traffic between two vms in the same tenant vlan
network across different chassis i.e if "vm1" on tenant vlan network
"net1" is on host chassis "ch1" and "vm2" on same tenant vlan network
"net1" is on gateway chassis "gw1". When the packet arrived on "gw1"
chassis from localnet port, we still send it to router pipeline and router
pipeline will send it to destination switch ("net1") pipeline.
But in this case when packet arrives at "vm2", it will have router MAC as
source MAC as the packet is routed in gateway chassis. This bevaviour can
be seen only for destination vms hosted on gateway node.

[1] https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046557.html
[2] Point 3 in section 3.3.1 - Future Enhancements
https://docs.google.com/document/d/1JecGIXPH0RAqfGvD0nmtBdEU1zflHACp8WSRnKCFSgg/edit#

Reported-at: 
https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046543.html

Signed-off-by: Venkata Anil 
---
 ovn/controller/bfd.c|   3 +-
 ovn/controller/binding.c|  10 +-
 ovn/controller/ovn-controller.c |   3 +
 ovn/controller/ovn-controller.h |  16 ++-
 ovn/controller/physical.c   |  94 -
 ovn/lib/logical-fields.c|   4 +
 ovn/lib/logical-fields.h|   2 +
 ovn/northd/ovn-northd.c |  35 +++
 tests/ovn.at| 227 
 9 files changed, 390 insertions(+), 4 deletions(-)

diff --git a/ovn/controller/bfd.c b/ovn/controller/bfd.c
index 8f020d5..cbbd3ba 100644
--- a/ovn/controller/bfd.c
+++ b/ovn/controller/bfd.c
@@ -139,8 +139,9 @@ bfd_travel_gw_related_chassis(struct local_datapath *dp,
   struct local_datapath_node, node);
 dp = dp_binding->dp;
 free(dp_binding);
+const struct sbrec_datapath_binding *pdp;
 for (size_t i = 0; i < dp->n_peer_dps; 

[ovs-dev] [PATCH v2] Avoid tunneling for VLAN packets redirected to a gateway chassis

[vkommadi]

From: venkata anil 

When a vm on a vlan tenant network sends traffic to an external network,
it is tunneled from host chassis to gateway chassis. In the earlier
discussion [1], Russel (also in his doc [2]) suggested if we can figure
out a way for OVN to do this redirect to the gateway host over a VLAN
network. This patch implements his suggestion i.e will redirect to
gateway chassis using incoming tenant vlan network. Gateway chassis are
expected to be configured with tenant vlan networks. In this approach,
new logical and physical flows introduced for packet processing in both
host and gateway chassis.

Packet processing in the host chassis:
1) Packet enters into router pipeline from switch pipeline
2) A new flow added in lr_in_ip_routing, for a packet coming from vlan
   tenant network and destined for external network, which sets
   REGBIT_NAT_REDIRECT i.e
   table=7 (lr_in_ip_routing   ), priority=1, match=(inport ==
   "lrp-44383893-613a-4bfe-b483-e7d0dc3055cd" && !is_chassis_resident("
   cr-lrp-a6e3d2ab-313a-4ea3-8ec4-c3c774a11f49")), action=(reg9[0] = 1;
   next;)
   When REGBIT_NAT_REDIRECT set,
   a) lr_in_arp_resolve, will set packet eth.dst to distibuted gateway
  port MAC
   b) lr_in_gw_redirect, will set chassisredirect port as outport
3) A new ovs flow added in physical table 32 will use source vlan tenant
   network tag as vlan ID for sending the packet to gateway chassis.
   As this vlan packet destination MAC is distibuted gateway port MAC,
   packet will only reach the gateway chassis.
   table=32,priority=150,reg14=0x3,reg15=0x6,metadata=0x4
   actions=mod_vlan_vid:2010,output:25,strip_vlan

Packet processing in the gateway chassis:
1) A new ovs flow added in physical table 0 to pass vlan traffic coming
   from localnet port to the connected router pipeline(i.e router
   attached to vlan tenant network).
   This flow will set router metadata, reg14 to router's patch port(lrp)
   (i.e patch port connecting router and vlan tenant network) and a new
   MLF_RCV_FROM_VLAN flag.
   table=0,priority=150,in_port=67,dl_vlan=2010 actions=strip_vlan,
   load:0x4->OXM_OF_METADATA[],load:0x3->NXM_NX_REG14[],
   load:0x1->NXM_NX_REG10[5],resubmit(,8)
2) A new flow added in lr_in_admission which checks MLF_RCV_FROM_VLAN
   and allows the packet.
   table=0 (lr_in_admission), priority=100  , match=(
   flags.rcv_from_vlan == 1 && inport == "lrp-44383893-613a-4bfe-b483-
   e7d0dc3055cd" && is_chassis_resident("cr-lrp-a6e3d2ab-313a-4ea3-
   8ec4-c3c774a11f49")), action=(next;)
   Then packet will pass through router ingress and egress pipelines and
   then to external switch pipeline.

In a scenario where the traffic between two vms in the same tenant vlan
network across different chassis i.e if "vm1" on tenant vlan network
"net1" is on host chassis "ch1" and "vm2" on same tenant vlan network
"net1" is on gateway chassis "gw1". When the packet arrived on "gw1"
chassis from localnet port, we still send it to router pipeline and router
pipeline will send it to destination switch ("net1") pipeline.
But in this case when packet arrives at "vm2", it will have router MAC as
source MAC as the packet is routed in gateway chassis.

[1] https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046557.html
[2] Point 3 in section 3.3.1 - Future Enhancements
https://docs.google.com/document/d/1JecGIXPH0RAqfGvD0nmtBdEU1zflHACp8WSRnKCFSgg/edit#

Reported-at: 
https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046543.html

Signed-off-by: Venkata Anil 
---
 ovn/controller/bfd.c|   3 +-
 ovn/controller/binding.c|  10 +-
 ovn/controller/ovn-controller.c |   3 +
 ovn/controller/ovn-controller.h |  16 ++-
 ovn/controller/physical.c   |  83 +++
 ovn/lib/logical-fields.c|   4 +
 ovn/lib/logical-fields.h|   2 +
 ovn/northd/ovn-northd.c |  50 -
 tests/ovn.at| 228 
 9 files changed, 392 insertions(+), 7 deletions(-)

diff --git a/ovn/controller/bfd.c b/ovn/controller/bfd.c
index 8f020d5..cbbd3ba 100644
--- a/ovn/controller/bfd.c
+++ b/ovn/controller/bfd.c
@@ -139,8 +139,9 @@ bfd_travel_gw_related_chassis(struct local_datapath *dp,
   struct local_datapath_node, node);
 dp = dp_binding->dp;
 free(dp_binding);
+const struct sbrec_datapath_binding *pdp;
 for (size_t i = 0; i < dp->n_peer_dps; i++) {
-const struct sbrec_datapath_binding *pdp = dp->peer_dps[i];
+pdp = dp->peer_dps[i]->peer_dp;
 if (!pdp) {
 continue;
 }
diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
index 0785a94..f02bde5 100644
--- a/ovn/controller/binding.c
+++ b/ovn/controller/binding.c
@@ -148,10 +148,14 @@ add_local_datapath__(struct controller_ctx *ctx,
 "lport-by-datapath", );
 
 

[ovs-dev] [PATCH] Avoid tunneling for VLAN packets redirected to a gateway chassis

[vkommadi]

From: Venkata Anil 

When a vm on a vlan tenant network sends traffic to an external network,
it is tunneled from host chassis to gateway chassis. In the earlier
discussion [1], Russel (also in his doc [2]) suggested if we can figure
out a way for OVN to do this redirect to the gateway host over a VLAN
network. This patch implements his suggestion i.e will redirect to
gateway chassis using incoming tenant vlan network. Gateway chassis are
expected to be configured with tenant vlan networks. In this approach,
new logical and physical flows introduced for packet processing in both
host and gateway chassis.

Packet processing in the host chassis:
1) Packet enters into router pipeline from switch pipeline
2) A new flow added in lr_in_ip_routing, for a packet coming from vlan
   tenant network and destined for external network, which sets
   REGBIT_NAT_REDIRECT i.e
   table=7 (lr_in_ip_routing   ), priority=1, match=(inport ==
   "lrp-44383893-613a-4bfe-b483-e7d0dc3055cd" && !is_chassis_resident("
   cr-lrp-a6e3d2ab-313a-4ea3-8ec4-c3c774a11f49")), action=(reg9[0] = 1;
   next;)
   When REGBIT_NAT_REDIRECT set,
   a) lr_in_arp_resolve, will set packet eth.dst to distibuted gateway
  port MAC
   b) lr_in_gw_redirect, will set chassisredirect port as outport
3) A new ovs flow added in physical table 32 will use source vlan tenant
   network tag as vlan ID for sending the packet to gateway chassis.
   As this vlan packet destination MAC is distibuted gateway port MAC,
   packet will only reach the gateway chassis.
   table=32,priority=150,reg14=0x3,reg15=0x6,metadata=0x4
   actions=mod_vlan_vid:2010,output:25,strip_vlan

Packet processing in the gateway chassis:
1) A new ovs flow added in physical table 0 to pass vlan traffic coming
   from localnet port to the connected router pipeline(i.e router
   attached to vlan tenant network).
   This flow will set router metadata, reg14 to router's patch port(lrp)
   (i.e patch port connecting router and vlan tenant network) and a new
   MLF_RCV_FROM_VLAN flag.
   table=0,priority=150,in_port=67,dl_vlan=2010 actions=strip_vlan,
   load:0x4->OXM_OF_METADATA[],load:0x3->NXM_NX_REG14[],
   load:0x1->NXM_NX_REG10[5],resubmit(,8)
2) A new flow added in lr_in_admission which checks MLF_RCV_FROM_VLAN
   and allows the packet.
   table=0 (lr_in_admission), priority=100  , match=(
   flags.rcv_from_vlan == 1 && inport == "lrp-44383893-613a-4bfe-b483-
   e7d0dc3055cd" && is_chassis_resident("cr-lrp-a6e3d2ab-313a-4ea3-
   8ec4-c3c774a11f49")), action=(next;)
   Then packet will pass through router ingress and egress pipelines and
   then to external switch pipeline.

In a scenario where the traffic between two vms in the same tenant vlan
network across different chassis i.e if "vm1" on tenant vlan network
"net1" is on host chassis "ch1" and "vm2" on same tenant vlan network
"net1" is on gateway chassis "gw1". When the packet arrived on "gw1"
chassis from localnet port, we still send it to router pipeline and router
pipeline will send it to destination switch ("net1") pipeline.
But in this case when packet arrives at "vm2", it will have router MAC as
source MAC as the packet is routed in gateway chassis.

[1] https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046557.html
[2] Point 3 in section 3.3.1 - Future Enhancements
https://docs.google.com/document/d/1JecGIXPH0RAqfGvD0nmtBdEU1zflHACp8WSRnKCFSgg/edit#

Reported-at: 
https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046543.html

Signed-off-by: Venkata Anil 
---
 ovn/controller/bfd.c|  3 +-
 ovn/controller/binding.c| 10 -
 ovn/controller/ovn-controller.c |  3 ++
 ovn/controller/ovn-controller.h | 16 +++-
 ovn/controller/physical.c   | 83 +
 ovn/lib/logical-fields.c|  4 ++
 ovn/lib/logical-fields.h|  2 +
 ovn/northd/ovn-northd.c | 32 
 8 files changed, 150 insertions(+), 3 deletions(-)

diff --git a/ovn/controller/bfd.c b/ovn/controller/bfd.c
index 8f020d5..cbbd3ba 100644
--- a/ovn/controller/bfd.c
+++ b/ovn/controller/bfd.c
@@ -139,8 +139,9 @@ bfd_travel_gw_related_chassis(struct local_datapath *dp,
   struct local_datapath_node, node);
 dp = dp_binding->dp;
 free(dp_binding);
+const struct sbrec_datapath_binding *pdp;
 for (size_t i = 0; i < dp->n_peer_dps; i++) {
-const struct sbrec_datapath_binding *pdp = dp->peer_dps[i];
+pdp = dp->peer_dps[i]->peer_dp;
 if (!pdp) {
 continue;
 }
diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
index 0785a94..f02bde5 100644
--- a/ovn/controller/binding.c
+++ b/ovn/controller/binding.c
@@ -148,10 +148,14 @@ add_local_datapath__(struct controller_ctx *ctx,
 "lport-by-datapath", );
 
 SBREC_PORT_BINDING_FOR_EACH_EQUAL (pb, , lpval) {
+  

[ovs-dev] [PATCH] Add unixctl option for ovn-northd

[vkommadi]

From: Venkata Anil 

Signed-off-by: Venkata Anil 
---
 lib/automake.mk |  3 ++-
 lib/unixctl.xml | 26 ++
 ovn/northd/ovn-northd.8.xml |  7 +--
 ovn/northd/ovn-northd.c |  9 -
 tests/ovn-northd.at | 39 +++
 5 files changed, 80 insertions(+), 4 deletions(-)
 create mode 100644 lib/unixctl.xml

diff --git a/lib/automake.mk b/lib/automake.mk
index 159319f..38d2a99 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -455,7 +455,8 @@ EXTRA_DIST += \
lib/ssl.xml \
lib/ssl-bootstrap.xml \
lib/table.xml \
-   lib/vlog.xml
+   lib/vlog.xml \
+   lib/unixctl.xml
 
 MAN_FRAGMENTS += \
lib/colors.man \
diff --git a/lib/unixctl.xml b/lib/unixctl.xml
new file mode 100644
index 000..51bfc5f
--- /dev/null
+++ b/lib/unixctl.xml
@@ -0,0 +1,26 @@
+
+
+  --unixctl=socket
+  
+Sets the name of the control socket on which
+program listens for runtime management commands
+(see RUNTIME MANAGEMENT COMMANDS, below).  If socket
+does not begin with /, it is interpreted as relative to
+@RUNDIR@. If --unixctl is not used at all,
+the default socket is
+@RUNDIR@/program.pid.ctl,
+where pid is program's process ID.
+  
+On Windows a local named pipe is used to listen for runtime management
+commands.  A file is created in the absolute path as pointed by
+socket or if --unixctl is not used at all,
+a file is created as program in the configured
+OVS_RUNDIR directory.  The file exists just to mimic the
+behavior of a Unix domain socket.
+  
+  
+Specifying none for socket disables the control
+socket feature.
+  
+  
+
diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index ee9cf8c..6bc2dd6 100644
--- a/ovn/northd/ovn-northd.8.xml
+++ b/ovn/northd/ovn-northd.8.xml
@@ -54,8 +54,11 @@
 http://www.w3.org/2003/XInclude"/>
 
 Other Options
-
-http://www.w3.org/2003/XInclude"/>
+http://www.w3.org/2003/XInclude"/>
+
+http://www.w3.org/2003/XInclude"/>
 
 Runtime Management Commands
 
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index f4edd8f..e206e0a 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -59,6 +59,7 @@ struct northd_context {
 
 static const char *ovnnb_db;
 static const char *ovnsb_db;
+static const char *unixctl_path;
 
 #define MAC_ADDR_PREFIX 0x0A00ULL
 #define MAC_ADDR_SPACE 0xff
@@ -239,6 +240,7 @@ Options:\n\
 (default: %s)\n\
   --ovnsb-db=DATABASE   connect to ovn-sb database at DATABASE\n\
 (default: %s)\n\
+  --unixctl = SOCKET  override default control socket name\n\
   -h, --helpdisplay this help message\n\
   -o, --options list available options\n\
   -V, --version display version information\n\
@@ -6663,6 +6665,7 @@ parse_options(int argc OVS_UNUSED, char *argv[] 
OVS_UNUSED)
 static const struct option long_options[] = {
 {"ovnsb-db", required_argument, NULL, 'd'},
 {"ovnnb-db", required_argument, NULL, 'D'},
+{"unixctl", required_argument, NULL, 'u'},
 {"help", no_argument, NULL, 'h'},
 {"options", no_argument, NULL, 'o'},
 {"version", no_argument, NULL, 'V'},
@@ -6694,6 +6697,10 @@ parse_options(int argc OVS_UNUSED, char *argv[] 
OVS_UNUSED)
 ovnnb_db = optarg;
 break;
 
+case 'u':
+unixctl_path = optarg;
+break;
+
 case 'h':
 usage();
 exit(EXIT_SUCCESS);
@@ -6746,7 +6753,7 @@ main(int argc, char *argv[])
 
 daemonize_start(false);
 
-retval = unixctl_server_create(NULL, );
+retval = unixctl_server_create(unixctl_path, );
 if (retval) {
 exit(EXIT_FAILURE);
 }
diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at
index baa2add..1878eb2 100644
--- a/tests/ovn-northd.at
+++ b/tests/ovn-northd.at
@@ -262,3 +262,42 @@ AT_CHECK_UNQUOTED([ovn-sbctl get Port_Binding ${uuid} 
options:ipv6_ra_prefixes],
 ])
 
 AT_CLEANUP
+
+AT_SETUP([ovn -- test unixctl])
+ovn_init_db ovn-sb; ovn-sbctl init
+ovn_init_db ovn-nb; ovn-nbctl init
+
+# test unixctl option
+mkdir "$ovs_base"/northd
+as northd start_daemon ovn-northd --unixctl="$ovs_base"/northd/ovn-northd.ctl 
--ovnnb-db=unix:"$ovs_base"/ovn-nb/ovn-nb.sock 
--ovnsb-db=unix:"$ovs_base"/ovn-sb/ovn-sb.sock
+ovn-nbctl ls-add sw
+ovn-nbctl --wait=sb lsp-add sw p1
+# northd created with unixctl option successfully created port_binding entry
+AT_CHECK([ovn-sbctl --bare --columns datapath find port_binding 
logical_port="p1" | wc -l], [0], [1
+])
+AT_CHECK([ovn-nbctl --wait=sb lsp-del p1])
+
+# ovs-appctl exit with unixctl option
+OVS_APP_EXIT_AND_WAIT_BY_TARGET(["$ovs_base"/northd/ovn-northd.ctl], 
["$ovs_base"/northd/ovn-northd.pid])
+
+# Check no