[EVPN] When VRF to VNI map gets processed before VLAN to VNI mapping, it results in fails to create VLAN to VNI mapping

[dgsudharsan]

Description

When VRF – VNI mapping arrives before VLAN – VNI mapping (It happens all the time during config reload), the VxLAN tunnel gets created with just VRF to VNI mapper. This is an issue because the encap mappers and decap mappers are create only attributes in tunnel and cannot be added when vlan to vni mapping arrives later. In all other places VLAN to VNI and VRF to VNI are created together and set in tunnel. Is the below case intentional or should be fixed? I also see the createTunnel is used only in this place and all other places use createTunnelHw which almost has same functionality. Should createTunnel be removed?

https://github.com/Azure/sonic-swss/blob/93af69c5cb9a78465604974b59d1b1ed709d2b10/orchagent/vxlanorch.cpp#L2220

Steps to reproduce the issue:

1. Add VRF to VNI mapping first followed by VLAN to VNI mapping
2. Perform config load.

Describe the results you received:

VLAN to VNI mapping creation fails

Describe the results you expected:

VLAN to VNI mapping should succeed

Output of show version:

SONiC Software Version: SONiC.master.370-4fb6cf03e_Internal
Distribution: Debian 11.3
Kernel: 5.10.0-12-2-amd64
Build commit: 4fb6cf03e
Build date: Tue Jul  5 08:28:28 UTC 2022
Built by: sw-r2d2-bot@r-build-sonic-ci02-244

Platform: x86_64-mlnx_msn3700c-r0
HwSKU: ACS-MSN3700C
ASIC: mellanox
ASIC Count: 1
Serial Number: MT1852X03897
Model Number: MSN3700-CS2F
Hardware Revision: A3
Uptime: 22:43:31 up  1:22,  1 user,  load average: 0.42, 0.61, 0.69
Date: Tue 12 Jul 2022 22:43:31

Docker images:
REPOSITORY                    TAG                             IMAGE ID       SIZE
docker-macsec                 latest                          2d9447c3e23f   460MB
docker-dhcp-relay             latest                          f99691ffb6da   451MB
docker-syncd-mlnx             latest                          f140fd933603   991MB
docker-syncd-mlnx             master.370-4fb6cf03e_Internal   f140fd933603   991MB
docker-sonic-telemetry        latest                          a5257d5d0f9d   522MB
docker-sonic-telemetry        master.370-4fb6cf03e_Internal   a5257d5d0f9d   522MB
docker-router-advertiser      latest                          f2a879e1a04d   442MB
docker-router-advertiser      master.370-4fb6cf03e_Internal   f2a879e1a04d   442MB
docker-platform-monitor       latest                          205a6186e0ac   994MB
docker-platform-monitor       master.370-4fb6cf03e_Internal   205a6186e0ac   994MB
docker-orchagent              latest                          f4a0b52c8f56   476MB
docker-orchagent              master.370-4fb6cf03e_Internal   f4a0b52c8f56   476MB
docker-mux                    latest                          ed2b817bd52c   490MB
docker-mux                    master.370-4fb6cf03e_Internal   ed2b817bd52c   490MB
docker-database               latest                          a9ee6bd703a6   442MB
docker-database               master.370-4fb6cf03e_Internal   a9ee6bd703a6   442MB
docker-teamd                  latest                          3aedfac22e52   427MB
docker-teamd                  master.370-4fb6cf03e_Internal   3aedfac22e52   427MB
docker-sonic-mgmt-framework   latest                          020f72a9284b   556MB
docker-sonic-mgmt-framework   master.370-4fb6cf03e_Internal   020f72a9284b   556MB
docker-snmp                   latest                          5cdc307ec95d   456MB
docker-snmp                   master.370-4fb6cf03e_Internal   5cdc307ec95d   456MB
docker-sflow                  latest                          feded85a0f31   428MB
docker-sflow                  master.370-4fb6cf03e_Internal   feded85a0f31   428MB
docker-nat                    latest                          dae3c27e75da   430MB
docker-nat                    master.370-4fb6cf03e_Internal   dae3c27e75da   430MB
docker-lldp                   latest                          ff1fa590d900   452MB
docker-lldp                   master.370-4fb6cf03e_Internal   ff1fa590d900   452MB
docker-fpm-frr                latest                          357d2d39f11f   456MB
docker-fpm-frr                master.370-4fb6cf03e_Internal   357d2d39f11f   456MB

Output of show techsupport:

(paste your output here or download and attach the file here )

Additional information you deem important (e.g. issue happens only occasionally):

[tapashdas]

orchagent/vxlanorch.cpp#L2218
if (!tunnel_obj->isActive())
{
++ return false;
-- tunnel_obj->createTunnel(MAP_T::VRID_TO_VNI, MAP_T::VNI_TO_VRID);
}

As part of Vlan to VNI mapping, createTunnelHw() will be called and isActive() will be set.
createTunnel() can be replaced with createTunnelHw().

[dgsudharsan]

As part of Vlan to VNI mapping, createTunnelHw() will be called and isActive() will be set.

Thanks. Can you please fix this flow and raise PR?