You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When pasting configs, logs, shell output, backtraces, and other large chunks of text use Markdown code blocks
Include the FRR version; if you built from Git, please provide the commit hash
Write your issue in English
Describe the bug
Zebra core seen on config reload, on route_map_lookup_by_name/hash_get on different instances route del or route map get code path. Added different tracebacks below.
[X] Did you check if this is a duplicate issue?
[ ] Did you test it on the latest FRRouting/frr master branch?
To Reproduce
Steps to reproduce the behavior:
Running sonic-mgmt/acl test with presanity, which does config reload.
Issue is not seen every time, but 1 out or 4 iteration hitting this issue.
…16456)
Why I did it
Zebra core sometimes seen during config reload. Series of route-map deletions and then re-adds, and this triggers the hash table to realloc to grow to a larger size, then subsuquent route-map operations will be against a corrupted hash table.
Issue is seen when we have BFD Enable on Static Route table we see Static route-map being created/deleted based on bfd session state. However issue itself is very generic from FRR perspective.
Thie issue has detailed core info sonic-net/sonic-frr#37 . This PR fixes this issue.
Fixes#sonic-net/sonic-frr#37
Work item tracking
Microsoft ADO (17952227):
How I did it
This fix is already in Master frr/8.2.5. Porting this fix to 202205 branch to address this Zebra core.
sonic-net/sonic-frr@5f503e5
Solution:
The whole purpose of the delay of deletion and the storage of the route-map is to allow the using protocol the ability to process the route-map at a later time while still retaining the route-map name( for more efficient reprocessing ). The problem exists because we are keeping multiple copies of deletion events that are indistinguishable from each other causing hash havoc.
How to verify it
Verified running sonic-mgmt test, doing multiple config reloads.
Describe the bug
Zebra core seen on config reload, on route_map_lookup_by_name/hash_get on different instances route del or route map get code path. Added different tracebacks below.
[X] Did you check if this is a duplicate issue?
[ ] Did you test it on the latest FRRouting/frr master branch?
To Reproduce
Steps to reproduce the behavior:
Running sonic-mgmt/acl test with presanity, which does config reload.
Issue is not seen every time, but 1 out or 4 iteration hitting this issue.
Screenshots

Route_map_delete path
Versions
Additional context
Seeing the issue when the BFD is enabled.
viz
@abdosi , @anamehra , @vperumal
The text was updated successfully, but these errors were encountered: