Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Orchagent] Vxlanorch and Portsorch changes for EVPN VXLAN #1264

Merged
merged 9 commits into from
Dec 2, 2020

Conversation

srj102
Copy link
Contributor

@srj102 srj102 commented Apr 20, 2020

  1. Existing code supports a single mapper type to be created. Either
    BRIDGE or VRF type mappers are supported.
    Change to support multiple mapper type creations is being added.
    Here mappers of type VLAN-VNI as well as VRF-VNI will be supported.
    support for single mapper type creation is not changed.
    Only one mode is accepted at a time.

  2. Changes to support P2P tunnel creation and deletion.
    A refcnt is maintained per resource type (IMR or IP prefix)
    and based on this a P2P tunnel is created or deleted.
    The VxlanTunnel object is reused for P2P and P2MP tunnels.
    State DB updation for every P2P VXLAN tunnel discovered.

  3. Changes to support handling of VXLAN_REMOTE_VNI table.
    Interfaces with portsorch to create a Port object of type
    TUNNEL on tunnel discovery. This is also used to extend

  4. SAI interface function changes to support P2P tunnels.

  5. EVPN NVO table handling.

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

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

What I did
Please refer to the details above.

Why I did it
EVPN VXLAN Implementation

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

Details if related

@srj102 srj102 changed the title Vxlanorch and Portsorch changes for EVPN VXLAN [Orchagent] Vxlanorch and Portsorch changes for EVPN VXLAN Apr 21, 2020
orchagent/vxlanorch.h Outdated Show resolved Hide resolved
orchagent/portsorch.cpp Outdated Show resolved Hide resolved
else
tunnel.m_learn_mode = "disable";
m_portList[tunnel_alias] = tunnel;
portOidToName[tunnel_id] = tunnel_alias;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this an unused variable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is due to dependency on #885 . Will check
on whether the dependency can be removed.

{
SWSS_LOG_ENTER();

portOidToName.erase(tunnel.m_tunnel_id);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this an unused variable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same reply as above.

orchagent/vxlanorch.cpp Outdated Show resolved Hide resolved
orchagent/vxlanorch.cpp Outdated Show resolved Hide resolved
orchagent/vxlanorch.cpp Outdated Show resolved Hide resolved
orchagent/vxlanorch.cpp Outdated Show resolved Hide resolved
orchagent/vxlanorch.cpp Outdated Show resolved Hide resolved
srj102 added a commit to srj102/sonic-swss-common that referenced this pull request May 20, 2020
srj102 added a commit to srj102/sonic-swss-common that referenced this pull request Jun 3, 2020
srj102 added a commit to srj102/sonic-swss-common that referenced this pull request Jun 3, 2020
@srj102 srj102 force-pushed the evpn_vxlan_orchagent branch from 098bcdb to 39d2a50 Compare June 3, 2020 09:28
@srj102 srj102 marked this pull request as ready for review June 10, 2020 10:10
@lgtm-com
Copy link

lgtm-com bot commented Jun 10, 2020

This pull request introduces 5 alerts when merging dd6bdc2 into a3a010a - view on LGTM.com

new alerts:

  • 5 for FIXME comment

@lgtm-com
Copy link

lgtm-com bot commented Jun 22, 2020

This pull request introduces 5 alerts when merging 8291755 into 17a2f93 - view on LGTM.com

new alerts:

  • 5 for FIXME comment

@lgtm-com
Copy link

lgtm-com bot commented Sep 18, 2020

This pull request introduces 5 alerts when merging 4f69c4a into b4938a5 - view on LGTM.com

new alerts:

  • 5 for FIXME comment

@srj102 srj102 force-pushed the evpn_vxlan_orchagent branch from 4f69c4a to be9ca35 Compare September 21, 2020 14:42
@lgtm-com
Copy link

lgtm-com bot commented Sep 21, 2020

This pull request introduces 5 alerts when merging be9ca35 into 2f5d2d9 - view on LGTM.com

new alerts:

  • 5 for FIXME comment

orchagent/portsorch.cpp Show resolved Hide resolved
orchagent/portsorch.cpp Outdated Show resolved Hide resolved
attr.value.oid = port.m_lag_id;
attrs.push_back(attr);
}
else if (port.m_type == Port::TUNNEL)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove this block and add this section to the original if/else case. And remove the #if 0

orchagent/portsorch.cpp Outdated Show resolved Hide resolved
else
tunnel.m_learn_mode = "disable";
m_portList[tunnel_alias] = tunnel;
//portOidToName[tunnel_id] = tunnel_alias;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove commented code

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will need to uncomment once the changes related to portOidToName in PR #1275 are merged.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed, this can be removed and later added based on the other PR

orchagent/vxlanorch.cpp Outdated Show resolved Hide resolved
orchagent/vxlanorch.cpp Outdated Show resolved Hide resolved
orchagent/vxlanorch.cpp Outdated Show resolved Hide resolved
orchagent/vxlanorch.cpp Outdated Show resolved Hide resolved
orchagent/vxlanorch.cpp Outdated Show resolved Hide resolved
orchagent/portsorch.cpp Show resolved Hide resolved
// dest ip
if ((dst_ip != nullptr) && p2p)
{
attr.id = SAI_TUNNEL_ATTR_PEER_MODE;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this P2P tunnel mode used only for L2 EVPN??

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the EVPN feature, the P2P tunnels will be created irrespective of L2 or L3 VXLAN. However the Tunnel Nexthops for the L3VXLAN case use the P2MP tunnel. MAC and IMET point to the created P2P tunnel.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@srj102 Since P2P tunnels are used only for L2 EVPN, we could create these tunnel objects only for L2 EVPNs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would mean the SAI driver has to handle creation of tunnels in the device based on both schemes. Instead creating P2P tunnels also would mean that SAI implementation can create the tunnels in the device based on
either of the triggers.

Other aspects like P2P tunnel operstatus, P2P tunnel stats(though not added as part of this release) is useful and
applicable for L3 VXLAN as well.

attr.value.s32 = SAI_TUNNEL_PEER_MODE_P2P;
tunnel_attrs.push_back(attr);
attr.id = SAI_TUNNEL_ATTR_ENCAP_DST_IP;
attr.value.ipaddr = *dst_ip;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If P2P mode used for L3 EVPN, SAI doesn't specify preference of DST_IP from tunnel object or tunnel nexthop object. Which one is used for rewrite??

Copy link
Contributor Author

@srj102 srj102 Oct 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When the SAI_NEXT_HOP_ATTR_TUNNEL_ID refers to a P2P tunnel object, it is expected that the SAI_NEXT_HOP_ATTR_IP and the SAI_TUNNEL_ATTR_ENCAP_DST_IP be the same. In the event of a mismatch, The SAI spec doesn't specify
a preference, however since the p2p tunnel id is being specified instead of a p2mp tunnel id, the p2p tunnel's DIP should be chosen.

@srj102 srj102 force-pushed the evpn_vxlan_orchagent branch from be9ca35 to 105f281 Compare October 23, 2020 09:49
@lgtm-com
Copy link

lgtm-com bot commented Oct 23, 2020

This pull request introduces 5 alerts when merging 105f281 into 3142693 - view on LGTM.com

new alerts:

  • 5 for FIXME comment

@@ -3319,6 +3335,48 @@ bool PortsOrch::addBridgePort(Port &port)
sai_attribute_t attr;
vector<sai_attribute_t> attrs;

if (port.m_type == Port::PHY)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can it be convereted to switch stmt instead if-else?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Original code also had if else and hence retained it.

remove_tunnel_termination(ids_.tunnel_term_id);
}

remove_tunnel_termination(ids_.tunnel_id);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In case of tunnel p2p mode, one tunnel mapper entry could be part of multiple tunnel objects. In that case, I think it is better to check any valid tunnelObject references before removing the mapper entry.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

p2p tunnels would have used TUNNEL_MAP_USE_COMMON_ENCAP_DECAP which is a no-op in the deleteMapperHw. So this should not be an issue

orchagent/vxlanorch.cpp Outdated Show resolved Hide resolved
orchagent/vxlanorch.cpp Outdated Show resolved Hide resolved
return true;
}

if (gPortsOrch->isVlanMember(vlanPort, tunnelPort))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

part of else??

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you elaborate ? Didnt understand.

orchagent/vxlanorch.cpp Outdated Show resolved Hide resolved
orchagent/vxlanorch.cpp Show resolved Hide resolved

return true;
}

void VxlanTunnelOrch::deleteTunnelPort(Port &tunnelPort)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When is this method instead of delTunnelUser?? There is no caller to this method.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will be used by fdborch to delete the tunnel once all the MACs learnt against a tunnel are removed. Not part of this PR.

srj102 and others added 6 commits November 13, 2020 07:35
1. Existing code supports a single mapper type to be created. Either
   BRIDGE or VRF type mappers are supported.
   Change to support multiple mapper type creations is being added.
   Here mappers of type VLAN-VNI as well as VRF-VNI will be supported.
   support for single mapper type creation is not changed.
   Only one mode is accepted at a time.

2. Changes to support P2P tunnel creation and deletion.
   A refcnt is maintained per resource type (IMR or IP prefix)
   and based on this a P2P tunnel is created or deleted.
   The VxlanTunnel object is reused for P2P and P2MP tunnels.
   State DB updation for every P2P VXLAN tunnel discovered.

3. Changes to support handling of VXLAN_REMOTE_VNI table.
   Interfaces with portsorch to create a Port object of type
   TUNNEL on tunnel discovery. This is also used to extend

4. SAI interface function changes to support P2P tunnels.

5. EVPN NVO table handling.

Signed-off-by: Rajesh Sankaran <[email protected]>
2. Re-instated changes which were overwritten by the force push
@srj102 srj102 force-pushed the evpn_vxlan_orchagent branch from 4a4ca68 to 3c4a883 Compare November 13, 2020 15:37
@lgtm-com
Copy link

lgtm-com bot commented Nov 13, 2020

This pull request introduces 5 alerts when merging 3c4a883 into fea7ade - view on LGTM.com

new alerts:

  • 5 for FIXME comment

orchagent/portsorch.cpp Outdated Show resolved Hide resolved
else
tunnel.m_learn_mode = "disable";
m_portList[tunnel_alias] = tunnel;
//portOidToName[tunnel_id] = tunnel_alias;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed, this can be removed and later added based on the other PR

orchagent/portsorch.cpp Outdated Show resolved Hide resolved
uint32_t ip_refcnt;
uint32_t spurious_add_imr_refcnt;
uint32_t spurious_del_imr_refcnt;
VxlanTunnel* dip_tunnel;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this comment is not addressed

orchagent/vxlanorch.cpp Show resolved Hide resolved
orchagent/vxlanorch.cpp Outdated Show resolved Hide resolved
1. Code styling issues.
2. dip_tunnel removed from refcnts structure
   getDipTunnel function which was referring to the above is now removed.
   callers for the above function now call VxlanTunnelOrch::getVxlanTunnel
3. Changes to introduce a new method to get the tunnel name given the DIP.
@srj102
Copy link
Contributor Author

srj102 commented Nov 23, 2020

retest this please

1 similar comment
@srj102
Copy link
Contributor Author

srj102 commented Nov 23, 2020

retest this please

@prsunny
Copy link
Collaborator

prsunny commented Nov 23, 2020

retest vs please

@prsunny prsunny merged commit 095f481 into sonic-net:master Dec 2, 2020
daall pushed a commit to daall/sonic-swss that referenced this pull request Dec 7, 2020
…#1264)

* https://github.com/Azure/SONiC/pull/437/commits

1. Existing code supports a single mapper type to be created. Either BRIDGE or VRF type mappers are supported.
   Change to support multiple mapper type creations is being added.
2. Changes to support P2P tunnel creation and deletion.  A refcnt is maintained per resource type (IMR or IP prefix)
   and based on this a P2P tunnel is created or deleted.
3. Changes to support handling of VXLAN_REMOTE_VNI table. Interfaces with portsorch to create a Port object of type
   TUNNEL on tunnel discovery.
4. SAI interface function changes to support P2P tunnels.
5. EVPN NVO table handling.

Signed-off-by: Rajesh Sankaran <[email protected]>
Co-authored-by: Tapash Das <[email protected]>
@srj102 srj102 deleted the evpn_vxlan_orchagent branch December 12, 2024 06:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants