The IGMP group could be accidentally learned on LR datapath instead
of LS. While the IGMP Group would be removed by northd if it was the
case this still creates some churn in SB database. This could happen
under the following conditions:
1) pinctrl thread will receive packet and stored IGMP group candidate
in hmap, with datapath tunnel_key as key.
2) The LS datapath tunnel_key is reused by LR.
3) ovn-controller will process those changes and will run
ip_mcast_sync().
4) The ip_mcast_sync() will walk through IGMP group candidates
retrieving datapath for given tunnel_key being LR at this point.
5) The IGMP group is stored in SB with a reference to LR.
There is one more condition, the pinctrl thread can't run after
2) otherwise it would update the in memory ip_mcast_snoop map.
To prevent that make sure we check if the retrieved datapath
is LS and skip the processing if that's not the case.
Fixes: 70ff8243040f ("OVN: Add IGMP SB definitions and ovn-controller support")
Acked-by: Dumitru Ceara <[email protected]>
Signed-off-by: Ales Musil <[email protected]>
---
v2: Add Dumitru's ack.
Add missing Fixes.
Fix typos in the commit message.
---
controller/pinctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/controller/pinctrl.c b/controller/pinctrl.c
index f8d5f9c66..3ccacfa2d 100644
--- a/controller/pinctrl.c
+++ b/controller/pinctrl.c
@@ -5771,7 +5771,7 @@ ip_mcast_sync(struct ovsdb_idl_txn *ovnsb_idl_txn,
struct local_datapath *local_dp =
get_local_datapath(local_datapaths, ip_ms->dp_key);
- if (!local_dp) {
+ if (!local_dp || !local_dp->is_switch) {
continue;
}
--
2.51.1
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
