[ovs-dev] [PATCH ovn v2] controller, northd: pass arp/nd from HW VTEP to lrouter pipeline

2023-05-30 Thread Vladislav Odintsov 
This patch is intended to make next two changes:

1. Support create/update of MAC_Binding for GARP/ND from HW VTEP.

Prior to this patch MAC_Binding records were created only when LRP issued
ARP request/Neighbor solicitation.  If IP to MAC in network attached via
vtep lport was changed the old MAC_Binding prevented normal
communication.  Now router port (chassisredirect) in logical switch with
vtep lport catches GARP or Neighbor Solicitation and updates MAC_Binding.

New flow with max priority was added in ls_in_arp_nd_resp and additional
OF rule in table 37 (OFTABLE_REMOTE_OUTPUT) to process multicast packets
received from RAMP_SWITCH.

2. Answer to ARP/ND on requests coming from HW VTEP in lrouter pipeline.

This is needed to reduce duplicated arp-responses, which were generated
by OVN arp-responder flows in node, where chassisredirect port located
with responses coming directly from VM interfaces.

As a result of this change, now vifs located on same chassis, where
chassisredirect ports are located receive ARP/ND mcast packets, which
previously were suppressed by arp-responder on the node.

Tests and documentation were updated to conform to new behaviour.

Signed-off-by: Vladislav Odintsov 
---
v1 -> v2:
  - Addressed Dumitru's review comments.

---
 NEWS|  2 +
 controller/binding.c| 47 +++
 controller/local_data.h |  3 ++
 controller/physical.c   | 45 ++-
 northd/northd.c | 10 +
 northd/ovn-northd.8.xml |  6 +++
 tests/ovn.at| 99 -
 7 files changed, 208 insertions(+), 4 deletions(-)

diff --git a/NEWS b/NEWS
index ec79e5fe7..2c31e5259 100644
--- a/NEWS
+++ b/NEWS
@@ -37,6 +37,8 @@ OVN v23.06.0 - xx xxx 
   - Support for tiered ACLs has been added. This allows for ACLs to be layered
 into separate tiers of priority. For more information, please see the
 ovn-nb and ovn-northd manpages.
+  - Support to create/update MAC_Binding when GARP received from VTEP (RAMP)
+switch on l3dgw port.
 
 OVN v23.03.0 - 03 Mar 2023
 --
diff --git a/controller/binding.c b/controller/binding.c
index c7a2b3f10..a90466bd6 100644
--- a/controller/binding.c
+++ b/controller/binding.c
@@ -509,6 +509,30 @@ update_ld_multichassis_ports(const struct 
sbrec_port_binding *binding_rec,
 }
 }
 
+static void
+update_ld_vtep_port(const struct sbrec_port_binding *binding_rec,
+struct hmap *local_datapaths)
+{
+struct local_datapath *ld
+= get_local_datapath(local_datapaths,
+ binding_rec->datapath->tunnel_key);
+if (!ld) {
+return;
+}
+
+if (ld->vtep_port && strcmp(ld->vtep_port->logical_port,
+binding_rec->logical_port)) {
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
+VLOG_WARN_RL(&rl, "vtep port '%s' already set for datapath "
+ "'%"PRId64"', skipping the new port '%s'.",
+ ld->vtep_port->logical_port,
+ binding_rec->datapath->tunnel_key,
+ binding_rec->logical_port);
+return;
+}
+ld->vtep_port = binding_rec;
+}
+
 static void
 update_ld_localnet_port(const struct sbrec_port_binding *binding_rec,
 struct shash *bridge_mappings,
@@ -1987,6 +2011,7 @@ binding_run(struct binding_ctx_in *b_ctx_in, struct 
binding_ctx_out *b_ctx_out)
 struct ovs_list external_lports = OVS_LIST_INITIALIZER(&external_lports);
 struct ovs_list multichassis_ports = OVS_LIST_INITIALIZER(
 &multichassis_ports);
+struct ovs_list vtep_lports = OVS_LIST_INITIALIZER(&vtep_lports);
 
 struct lport {
 struct ovs_list list_node;
@@ -2010,8 +2035,13 @@ binding_run(struct binding_ctx_in *b_ctx_in, struct 
binding_ctx_out *b_ctx_out)
 
 switch (lport_type) {
 case LP_PATCH:
+update_related_lport(pb, b_ctx_out);
+break;
 case LP_VTEP:
 update_related_lport(pb, b_ctx_out);
+struct lport *vtep_lport = xmalloc(sizeof *vtep_lport);
+vtep_lport->pb = pb;
+ovs_list_push_back(&vtep_lports, &vtep_lport->list_node);
 break;
 
 case LP_LOCALPORT:
@@ -2111,6 +2141,15 @@ binding_run(struct binding_ctx_in *b_ctx_in, struct 
binding_ctx_out *b_ctx_out)
 free(multichassis_lport);
 }
 
+/* Run through vtep lport list to see if there are vtep ports
+ * on local datapaths discovered from above loop, and update the
+ * corresponding local datapath accordingly. */
+struct lport *vtep_lport;
+LIST_FOR_EACH_POP (vtep_lport, list_node, &vtep_lports) {
+update_ld_vtep_port(vtep_lport->pb, b_ctx_out->local_datapaths);
+free(vtep_lport);
+}
+
 shash_destroy(&bridge_mappings);
 /* Remove stale QoS entries. */
 ovs_qos_entri

Re: [ovs-dev] [PATCH ovn v2] controller, northd: pass arp/nd from HW VTEP to lrouter pipeline

2023-06-14 Thread Dumitru Ceara 
On 5/30/23 17:03, Vladislav Odintsov wrote:
> This patch is intended to make next two changes:
> 
> 1. Support create/update of MAC_Binding for GARP/ND from HW VTEP.
> 
> Prior to this patch MAC_Binding records were created only when LRP issued
> ARP request/Neighbor solicitation.  If IP to MAC in network attached via
> vtep lport was changed the old MAC_Binding prevented normal
> communication.  Now router port (chassisredirect) in logical switch with
> vtep lport catches GARP or Neighbor Solicitation and updates MAC_Binding.
> 
> New flow with max priority was added in ls_in_arp_nd_resp and additional
> OF rule in table 37 (OFTABLE_REMOTE_OUTPUT) to process multicast packets
> received from RAMP_SWITCH.
> 
> 2. Answer to ARP/ND on requests coming from HW VTEP in lrouter pipeline.
> 
> This is needed to reduce duplicated arp-responses, which were generated
> by OVN arp-responder flows in node, where chassisredirect port located
> with responses coming directly from VM interfaces.
> 
> As a result of this change, now vifs located on same chassis, where
> chassisredirect ports are located receive ARP/ND mcast packets, which
> previously were suppressed by arp-responder on the node.
> 
> Tests and documentation were updated to conform to new behaviour.
> 
> Signed-off-by: Vladislav Odintsov 
> ---

Thanks, Vladislav, for the new support!  I applied this to the main
branch and it will be available in the next release.

Regards,
Dumitru

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

Re: [ovs-dev] [PATCH ovn v2] controller, northd: pass arp/nd from HW VTEP to lrouter pipeline

2023-06-14 Thread Vladislav Odintsov 
Thanks Dumitru!

> On 14 Jun 2023, at 16:37, Dumitru Ceara  wrote:
> 
> On 5/30/23 17:03, Vladislav Odintsov wrote:
>> This patch is intended to make next two changes:
>> 
>> 1. Support create/update of MAC_Binding for GARP/ND from HW VTEP.
>> 
>> Prior to this patch MAC_Binding records were created only when LRP issued
>> ARP request/Neighbor solicitation.  If IP to MAC in network attached via
>> vtep lport was changed the old MAC_Binding prevented normal
>> communication.  Now router port (chassisredirect) in logical switch with
>> vtep lport catches GARP or Neighbor Solicitation and updates MAC_Binding.
>> 
>> New flow with max priority was added in ls_in_arp_nd_resp and additional
>> OF rule in table 37 (OFTABLE_REMOTE_OUTPUT) to process multicast packets
>> received from RAMP_SWITCH.
>> 
>> 2. Answer to ARP/ND on requests coming from HW VTEP in lrouter pipeline.
>> 
>> This is needed to reduce duplicated arp-responses, which were generated
>> by OVN arp-responder flows in node, where chassisredirect port located
>> with responses coming directly from VM interfaces.
>> 
>> As a result of this change, now vifs located on same chassis, where
>> chassisredirect ports are located receive ARP/ND mcast packets, which
>> previously were suppressed by arp-responder on the node.
>> 
>> Tests and documentation were updated to conform to new behaviour.
>> 
>> Signed-off-by: Vladislav Odintsov 
>> ---
> 
> Thanks, Vladislav, for the new support!  I applied this to the main
> branch and it will be available in the next release.
> 
> Regards,
> Dumitru
> 
> ___
> dev mailing list
> d...@openvswitch.org 
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Regards,
Vladislav Odintsov

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