[vxlan decap]: Don't remove tunnel when it has tunnel maps configured #1047
Conversation
| first = false; | ||
| } | ||
| SWSS_LOG_WARN("Vxlan tunnel '%s' has tunnel maps configured [%s]. Can't remove now.", tunnel_name.c_str(), vni_list.c_str()); | ||
| return false; |
There was a problem hiding this comment.
do we do retry here if mapper is not empty?
There was a problem hiding this comment.
if orchagent gets tunnel remove first and then tunnel map, then we should pend the tunnel remove (retry) later to resolve the dependency issue.
There was a problem hiding this comment.
'return false' mean don't erase from the queue. So the operation will be retried later
We don't have such infrastructure for pending anything in orchagent.
Our common way to deal with this:
If we see that request tries to remove something which has dependencies, just don't do anything and don't erase it from the queue. Later the request is going to be retried, if the dependency still not removed, it will be postponed again. We don't have counters or anything to limit number of attempts to remove something with dependency.
|
Currently master branch doesn't have stable sai implementation for this feature. So I'll have it as a draft until we got vxlan support in master. |
|
retest this please |
* Fix the fast-reboot-dump.py error when it try to use inet_aton to translate ipv6 address * Add send_ndp as TODO in fast-reboot-dump.py to ipv6 target
What I did
Fix the issue in orchagent: orchagent allowed removing of a tunnel even if the tunnel has tunnel maps configured.
Why I did it
Because it was an issue.
How I verified it
Add a tunnel and tunnel map, then try to remove tunnel only
Details if related