[VxlanMgr] changes for EVPN VXLAN #1266

srj102 · 2020-04-21T11:43:02Z

Add support for EVPN NVO config table.
VxlanTunnel and TunnelMap handlers are enhanced to also cache the data so that
this can be used during the deletion.
ARP suppression changes
Create state db for vxlanmgr and vlanmgr to sync the tunnel association to vlan
Changes to support warm reboot.

HLD Location : https://github.com/Azure/SONiC/pull/437/commits

Signed-off-by: Rajesh Sankaran [email protected]

What I did
Please refer to details provided above.

Why I did it
EVPN VXLAN Implementation

How I verified it
Tested along with PR 1264. Used test script in PR 1318.
Also ran test_vnet.py from master branch to verify there were no failures.

Details if related

lguohan · 2020-04-29T21:19:11Z

need vs test for this feature.

cfgmgr/vxlanmgr.h

cfgmgr/vxlanmgr.cpp

cfgmgr/vxlanmgrd.cpp

cfgmgr/vxlanmgr.cpp

prsunny · 2020-09-10T22:44:20Z

retest this please

cfgmgr/vxlanmgr.cpp

cfgmgr/vxlanmgrd.cpp

cfgmgr/vxlanmgr.h

cfgmgr/vxlanmgr.cpp

prsunny · 2020-10-07T17:04:33Z

cfgmgr/vxlanmgr.cpp

+        SWSS_LOG_NOTICE("Creating VxlanNetDevice %s", vxlan_dev_name.c_str());
+    }
+
+    // Remove kernel device if it exists


When would this happen? All Vxlan netdevices are cleared as part of constructor init right?

Yes this is not required. Will remove.

cfgmgr/vxlanmgr.cpp

prsunny · 2020-10-07T17:06:04Z

cfgmgr/vxlanmgr.cpp

+    bridge_untagged_add_cmd = std::string("") + BRIDGE_CMD + " vlan add vid " + 
+                              std::string(vlan_id) + " untagged pvid dev " + vxlan_dev_name;
+
+    bridge_del_vid_cmd = std::string("") + BRIDGE_CMD + " vlan del vid 1 dev " + 


This is not mentioned in HLD section. What is the purpose?

After the command ip link set <vxlan_dev_name> master DOT1Q_BRIDGE_NAME the vxlan dev automatically
gets added to vid 1.. We wanted to avoid flooding vid-1 packets to vxlan device unless explicitly added.

ip link add vtep1-22 type vxlan id 100 local 1.1.1.1 dstport 4789
ip link set vtep1-22 master Bridge

root@sonic:/home/admin# bridge vlan show
port vlan ids
docker0 1 PVID Egress Untagged

Bridge None
dummy 1 PVID Egress Untagged

vtep1-22 1 PVID Egress Untagged

prsunny · 2020-10-07T18:30:27Z

cfgmgr/vxlanmgr.cpp

+        size_t found = vxlanTunnelMapName.find(delimiter);
+        const auto vxlanTunnelName = vxlanTunnelMapName.substr(0, found);
+
+        createVxlanNetdevice(vxlanTunnelName, vni_id, src_ip, dst_ip, vlan_id);


in this, it wouldn't be creating the netdevice right, since m_in_reconcile will be true? Just to clarify, will discuss in the review meeting

Yes, this is correct.
During the initialization, vxlanmgrd reads the kernel and creates a cache of all the existing new devices.
When the configuration is restored, if the cache contains the corresponding kernel device, it will skip to create the kernel netdevice creation.
Typically for the swss docker restart, the cache will contain all the kernel netdevice and hence will not try to recreate it.
However for system warmboot, the kernel cache will be empty and hence while restoring the configuration, the corresponding kernel netdevices are created.

The m_in_reconcile is set to true (beginReconcile) before the configuration is restored.

kperumalbfn · 2020-10-15T22:44:01Z

cfgmgr/vxlanmgr.cpp

+
+    tuncache.fvt = kfvFieldsValues(t);
+    tuncache.vlan_vni_refcnt = 0;
+    tuncache.m_sourceIp = fvValue(tuncache.fvt.back());


Is it possible to get the source ip from the tuple fvt using SOURCE_IP??

kperumalbfn · 2020-10-15T22:47:23Z

cfgmgr/vxlanmgr.cpp

+    tuncache.vlan_vni_refcnt = 0;
+    tuncache.m_sourceIp = fvValue(tuncache.fvt.back());
+
+    m_appVxlanTunnelTable.set(vxlanTunnelName, kfvFieldsValues(t));


check for existing tunnel before updating the tunnel table map??

When using Click there is a check for existence of a VTEP object and rejected. Otherwise the code is the same as what exists today.

srj102 · 2020-10-30T16:20:40Z

retest vs please

kperumalbfn · 2020-12-04T02:48:12Z

cfgmgr/vxlanmgr.cpp

+        dst_ip = dstIp->second;
+    }
+    else
+    {


On what scenario, dst_ip can be null?

The dst_ip is that of the VXLAN_TUNNEL object. For EVPN it is expected to be NULL. Since the non EVPN cases had the support for destination IP in the VXLAN_TUNNEL object, this check was added.

kperumalbfn · 2020-12-04T02:58:38Z

cfgmgr/vxlanmgr.cpp

+        {
+            vni_id = value;
+        }
+    }


For a tunnel without vlan-vni mapper, we could bypass all these checks and return. I believe vlan <--> VNI mapper is required only for L3 EVPN asymmetric IRB and L2 EVPN.

This function handles the VXLAN_TUNNEL_MAP entry creation and will have VLAN-VNI mapping.

kperumalbfn · 2020-12-04T03:02:37Z

cfgmgr/vxlanmgr.cpp

+        return true;
+    }
+
+    if (m_vniMapCache.find(vni_id) != m_vniMapCache.end())


m_vniMapCache maintains only vlan <--> VNI map cache. Should we check for VRF <--> VNI mapper as well? There is no cache maintained as of now for that mapper in vxlanmgr.

VNI-VRF Mapping is being handled in the VrfMgr.

kperumalbfn · 2020-12-04T03:03:58Z

cfgmgr/vxlanmgr.cpp

+    }
+
+    createAppDBTunnelMapTable(t);
+    createVxlanNetdevice(vxlanTunnelName, vni_id, src_ip, dst_ip, vlan_id);


Check for error state.

prsunny · 2020-12-04T16:17:24Z

retest this please

1. Add support for EVPN NVO config table. 2. Changes to VxlanTunnel create handler to support KLISH and openconfig. The VXLAN_TUNNEL table in the config db gets populated as follows. NULL,NULL - interface vxlan create NULL,NULL,src_ip,<a.b.c.d> - when SIP is set. NULL,NULL - when SIP is unset. src_ip,<a.b.c.d> - This format is when click is used. 3. VxlanTunnel and TunnelMap handlers are enhanced to also cache the data so that this can be used during the deletion. 4. ARP suppression changes Create state db for vxlanmgr and vlanmgr to sync the tunnel association to vlan 5. Changes to support warm reboot. HLD Location : https://github.com/Azure/SONiC/pull/437/commits Signed-off-by: Rajesh Sankaran <[email protected]>

… pytest.

cfgmgr/vxlanmgr.cpp

prsunny · 2020-12-10T03:39:19Z

cfgmgr/vxlanmgr.cpp

+    //Inform the Vlan Mgr to update the tunnel flags if Arp/Nd Suppression is set.
+    std::string key = "Vlan" + std::string(vlan_id);
+    vector<FieldValueTuple> fvVector;
+    FieldValueTuple s("netdev", vxlan_dev_name);


Is this newly added? I don't remember seeing this in the previous review, May be missed

No was part of the first commit itself.

cfgmgr/vxlanmgr.cpp

1. Changes to logging from NOTICE to INFO. 2. Return value for createVxlanNEtDevice handled. changed the createvxlannetdevice to be similar to vnet to call swss:exec instead of EXEC_WITH_THROW macro. 3. Changes to portsorch for lowering the severity levels of couple of logs.

srj102 · 2020-12-10T18:19:36Z

retest vs please

* VxlanMgr changes for EVPN VXLAN 1. Add support for EVPN NVO config table. 2. VxlanTunnel and TunnelMap handlers are enhanced to also cache the data so that this can be used during the deletion. 3. ARP suppression changes 4. Create state db for vxlanmgr and vlanmgr to sync the tunnel association to vlan 5. Changes to support warm reboot. Signed-off-by: Rajesh Sankaran <[email protected]> Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan <[email protected]>

…onic-net#1266) Added pytests for "config qos reload" commands.

…ommands (sonic-net#1266)" This reverts commit 6202a81.

prsunny self-assigned this Apr 22, 2020