-
Notifications
You must be signed in to change notification settings - Fork 525
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
[EVPN]Handling error scenarios during route programming and IMR add #2670
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -665,6 +665,8 @@ void RouteOrch::doTask(Consumer& consumer) | |
NextHopGroupKey& nhg = ctx.nhg; | ||
vector<string> srv6_segv; | ||
vector<string> srv6_src; | ||
bool l3Vni = true; | ||
uint32_t vni = 0; | ||
|
||
/* Check if the next hop group is owned by the NhgOrch. */ | ||
if (nhg_index.empty()) | ||
|
@@ -696,6 +698,23 @@ void RouteOrch::doTask(Consumer& consumer) | |
ipv.resize(alsv.size()); | ||
} | ||
|
||
for (auto &vni_str: vni_labelv) | ||
{ | ||
vni = static_cast<uint32_t>(std::stoul(vni_str)); | ||
if (!m_vrfOrch->isL3VniVlan(vni)) | ||
{ | ||
SWSS_LOG_WARN("Route %s is received on non L3 VNI %s", key.c_str(), vni_str.c_str()); | ||
l3Vni = false; | ||
break; | ||
} | ||
} | ||
|
||
if (!l3Vni) | ||
{ | ||
it++; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Similar comment as for IMR handling. Not Removing this from the m_tosyncqueue in a scale scenario and in a misconfiguration case will unnecessarily load the OA. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Again, completely ignoring will lead to the message being lost. Since this is a error scenario, I would rather prefer retrying here. It won't affect regular use case scenarios There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @srj102 It is quite possible but I haven't encountered it. I believe my change would handle that scenario as well |
||
continue; | ||
} | ||
|
||
/* Set the empty ip(s) to zero | ||
* as IpAddress("") will construct a incorrect ip. */ | ||
for (auto &ip : ipv) | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2376,6 +2376,13 @@ bool EvpnRemoteVnip2pOrch::addOperation(const Request& request) | |
return false; | ||
} | ||
|
||
VRFOrch* vrf_orch = gDirectory.get<VRFOrch*>(); | ||
if (vrf_orch->isL3VniVlan(vni_id)) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
{ | ||
SWSS_LOG_WARN("Ignoring remote VNI add for L3 VNI:%d, remote:%s", vni_id, remote_vtep.c_str()); | ||
return false; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should this be return true instead of return false ? The log says "Ignore" but in reality it is being deferred. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I can correct the log. I prefer not to ignore but defer. If we ignore we might miss those remote. Since this is a corner error scenario I don't think it will overwhelm orchagent during regular processing |
||
} | ||
|
||
if (tunnel_orch->getTunnelPort(remote_vtep,tunnelPort)) | ||
{ | ||
SWSS_LOG_INFO("Vxlan tunnelPort exists: %s", remote_vtep.c_str()); | ||
|
@@ -2531,6 +2538,13 @@ bool EvpnRemoteVnip2mpOrch::addOperation(const Request& request) | |
return false; | ||
} | ||
|
||
VRFOrch* vrf_orch = gDirectory.get<VRFOrch*>(); | ||
if (vrf_orch->isL3VniVlan(vni_id)) | ||
{ | ||
SWSS_LOG_WARN("Ignoring remote VNI add for L3 VNI:%d, remote:%s", vni_id, end_point_ip.c_str()); | ||
return false; | ||
} | ||
|
||
auto src_vtep = vtep_ptr->getSrcIP().to_string(); | ||
if (tunnel_orch->getTunnelPort(src_vtep,tunnelPort, true)) | ||
{ | ||
|
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 the vrf-vni configuration is removed from OA and not from FRR after routes are installed then the routes still remain in the HW.
Is this scenario handled ?
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 our case the VNI removal leads to error logs in SAI since it has references. This scenario again depends on references to maintain which I believe we don't do it. IMO I am fixing the scenarios which are easier to fix with the current implementation and then document the ones which are harder to fix.
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.
yes thats correct we don't maintain the routes in the OA and handling this will be harder. If this leads to a SAI error and an OA crash we will need to see whether this can be handled at the SAI level.
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.
Currently SAI error is not creating orchagent crash since we are not handling status for this call. So we will get syslog error. For now I consider this a lower priority and document this.