-
Notifications
You must be signed in to change notification settings - Fork 539
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
Conversation
orchagent/portsorch.cpp
Outdated
else | ||
tunnel.m_learn_mode = "disable"; | ||
m_portList[tunnel_alias] = tunnel; | ||
portOidToName[tunnel_id] = tunnel_alias; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
orchagent/portsorch.cpp
Outdated
{ | ||
SWSS_LOG_ENTER(); | ||
|
||
portOidToName.erase(tunnel.m_tunnel_id); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same reply as above.
to allow for compilation of the PR sonic-net/sonic-swss#1264
to allow for compilation of the PR sonic-net/sonic-swss#1264
to allow for compilation of the PR sonic-net/sonic-swss#1264
098bcdb
to
39d2a50
Compare
This pull request introduces 5 alerts when merging dd6bdc2 into a3a010a - view on LGTM.com new alerts:
|
This pull request introduces 5 alerts when merging 8291755 into 17a2f93 - view on LGTM.com new alerts:
|
This pull request introduces 5 alerts when merging 4f69c4a into b4938a5 - view on LGTM.com new alerts:
|
4f69c4a
to
be9ca35
Compare
This pull request introduces 5 alerts when merging be9ca35 into 2f5d2d9 - view on LGTM.com new alerts:
|
attr.value.oid = port.m_lag_id; | ||
attrs.push_back(attr); | ||
} | ||
else if (port.m_type == Port::TUNNEL) |
There was a problem hiding this comment.
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
else | ||
tunnel.m_learn_mode = "disable"; | ||
m_portList[tunnel_alias] = tunnel; | ||
//portOidToName[tunnel_id] = tunnel_alias; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove commented code
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
// dest ip | ||
if ((dst_ip != nullptr) && p2p) | ||
{ | ||
attr.id = SAI_TUNNEL_ATTR_PEER_MODE; |
There was a problem hiding this comment.
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??
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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??
There was a problem hiding this comment.
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.
be9ca35
to
105f281
Compare
This pull request introduces 5 alerts when merging 105f281 into 3142693 - view on LGTM.com new alerts:
|
@@ -3319,6 +3335,48 @@ bool PortsOrch::addBridgePort(Port &port) | |||
sai_attribute_t attr; | |||
vector<sai_attribute_t> attrs; | |||
|
|||
if (port.m_type == Port::PHY) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
orchagent/vxlanorch.cpp
Outdated
remove_tunnel_termination(ids_.tunnel_term_id); | ||
} | ||
|
||
remove_tunnel_termination(ids_.tunnel_id); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
return true; | ||
} | ||
|
||
if (gPortsOrch->isVlanMember(vlanPort, tunnelPort)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
part of else??
There was a problem hiding this comment.
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.
|
||
return true; | ||
} | ||
|
||
void VxlanTunnelOrch::deleteTunnelPort(Port &tunnelPort) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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
4a4ca68
to
3c4a883
Compare
This pull request introduces 5 alerts when merging 3c4a883 into fea7ade - view on LGTM.com new alerts:
|
This was overwritten by a force push on Nov 13.
orchagent/portsorch.cpp
Outdated
else | ||
tunnel.m_learn_mode = "disable"; | ||
m_portList[tunnel_alias] = tunnel; | ||
//portOidToName[tunnel_id] = tunnel_alias; |
There was a problem hiding this comment.
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.h
Outdated
uint32_t ip_refcnt; | ||
uint32_t spurious_add_imr_refcnt; | ||
uint32_t spurious_del_imr_refcnt; | ||
VxlanTunnel* dip_tunnel; |
There was a problem hiding this comment.
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
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.
retest this please |
1 similar comment
retest this please |
retest vs please |
…#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]>
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.
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.
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
SAI interface function changes to support P2P tunnels.
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