[VxlanMgr] changes for EVPN VXLAN#1266
Conversation
|
need vs test for this feature. |
srj102
force-pushed
the
evpn_vxlan_vxlanmgr
branch
from
6c6aed7 to
5a371bf
Compare
|
retest this please |
| SWSS_LOG_NOTICE("Creating VxlanNetDevice %s", vxlan_dev_name.c_str()); | ||
| } | ||
|
|
||
| // Remove kernel device if it exists |
There was a problem hiding this comment.
When would this happen? All Vxlan netdevices are cleared as part of constructor init right?
There was a problem hiding this comment.
Yes this is not required. Will remove.
| 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 " + |
There was a problem hiding this comment.
This is not mentioned in HLD section. What is the purpose?
There was a problem hiding this comment.
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
| size_t found = vxlanTunnelMapName.find(delimiter); | ||
| const auto vxlanTunnelName = vxlanTunnelMapName.substr(0, found); | ||
|
|
||
| createVxlanNetdevice(vxlanTunnelName, vni_id, src_ip, dst_ip, vlan_id); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
|
|
||
| tuncache.fvt = kfvFieldsValues(t); | ||
| tuncache.vlan_vni_refcnt = 0; | ||
| tuncache.m_sourceIp = fvValue(tuncache.fvt.back()); |
There was a problem hiding this comment.
Is it possible to get the source ip from the tuple fvt using SOURCE_IP??
| tuncache.vlan_vni_refcnt = 0; | ||
| tuncache.m_sourceIp = fvValue(tuncache.fvt.back()); | ||
|
|
||
| m_appVxlanTunnelTable.set(vxlanTunnelName, kfvFieldsValues(t)); |
There was a problem hiding this comment.
check for existing tunnel before updating the tunnel table map??
There was a problem hiding this comment.
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
force-pushed
the
evpn_vxlan_vxlanmgr
branch
from
b4b0aab to
25f1a52
Compare
|
retest vs please |
| dst_ip = dstIp->second; | ||
| } | ||
| else | ||
| { |
There was a problem hiding this comment.
On what scenario, dst_ip can be null?
There was a problem hiding this comment.
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.
| { | ||
| vni_id = value; | ||
| } | ||
| } |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
This function handles the VXLAN_TUNNEL_MAP entry creation and will have VLAN-VNI mapping.
| return true; | ||
| } | ||
|
|
||
| if (m_vniMapCache.find(vni_id) != m_vniMapCache.end()) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
VNI-VRF Mapping is being handled in the VrfMgr.
| } | ||
|
|
||
| createAppDBTunnelMapTable(t); | ||
| createVxlanNetdevice(vxlanTunnelName, vni_id, src_ip, dst_ip, vlan_id); |
|
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]>
srj102
force-pushed
the
evpn_vxlan_vxlanmgr
branch
from
350ac93 to
2d9d371
Compare
| //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); |
There was a problem hiding this comment.
Is this newly added? I don't remember seeing this in the previous review, May be missed
There was a problem hiding this comment.
No was part of the first commit itself.
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.
|
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.
6 participants
this can be used during the deletion.
Create state db for vxlanmgr and vlanmgr to sync the tunnel association to vlan
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