Problem:
Prefix-list with mulitiple rules, an update to
a rule/sequence with different prefix/prefixlen
reset prefix-list next-base pointer to avoid
having stale value.
In some case the old next-bast's reference leads
to an assert in tri (trie_install_fn ) add.
bt:
(object=0x55576a4c8a00, updptr=0x55576a4b97e0) at lib/plist.c:560
(plist=0x55576a4a1770, pentry=0x55576a4c8a00) at lib/plist.c:585
(ple=0x55576a4c8a00) at lib/plist.c:745
(args=0x7fffe04beb50) at lib/filter_nb.c:1181
Solution:
Reset prefix-list next-base pointer whenver a
sequence/rule is updated.
Ticket:CM-33109
Testing Done:
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
In prefix-list nortbound callback's validation
phase, use type as enum rather string for better
performance.
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Following patch
" lib: disallow access list duplicated values"
introduce a libyang dnode iterator for every prefix-list
config which adds an overhead of traversal all prefix dnodes
and degrades the performance in scaled prefix-list config.
This check is not necessary in prefix-list northbound callbacks
as there won't be a case where prefix-list config comes to nb
callback without sequence number.
The dup check is only necessary for the vtysh case for backward
compatiblity reason where cli can be accepted without sequence number.
Ticket: CM-32035
Reviewed By: CCR-11096
Testing Done:
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Remove when statements from prefix-list yang OM,
and do the same check in frr validation phase.
This helps a bit in perfomance of prefix-lists
scale config.
Ticket:CM-32035
Reviewed By:CCR-11096
Testing Done:
Signed-off-by: Chirag Shah <chirag@nvidia.com>
The output from `show thread cpu` was not lined up appropriately
for the header line. As well as the function name we were
calling in the output. Fix it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
```
2523558-==2523558==
2523558-==2523558== Conditional jump or move depends on uninitialised value(s)
2523558:==2523558== at 0x47F242: bgp_notify_admin_message (bgp_debug.c:505)
2523558-==2523558== by 0x47F242: bgp_notify_print (bgp_debug.c:534)
2523558-==2523558== by 0x4BA9BC: bgp_notify_receive (bgp_packet.c:1905)
2523558-==2523558== by 0x4BA9BC: bgp_process_packet (bgp_packet.c:2602)
2523558-==2523558== by 0x4904B7E: thread_call (thread.c:1681)
2523558-==2523558== by 0x48CAA27: frr_run (libfrr.c:1126)
2523558-==2523558== by 0x474B1A: main (bgp_main.c:540)
2523558-==2523558== Uninitialised value was created by a stack allocation
2523558:==2523558== at 0x4BA33D: bgp_process_packet (bgp_packet.c:2529)
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
This command was put in place to allow upgrades for the
neighbor command from the BGP_NODE and have it put
into the ipv4 uni node instead. Since this
utterly kills the yang conversion. I believe we need
to remove this. Since people upgrading will just loose
the route-map applicatoin( if they are using such an old
config ) and RFC 8212 will come into play. They'll figure
it out pretty fast.
Fixes: #7983
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The calling function of ospf_nbr_nbma_lookup_next calls
this function and then immediately returns when it
gets the NULL. Just cleanup a bit more code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
I am not even sure what the goal of this code was in any
way shape fashion or form. But since it's pbr_nht.c
I as the original author should know... But I don't.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Looks like the #if 0 code in this place was for ESI support
on solaris. We do not support solaris anymore. So let's
remove with prejudice.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The #if 0 code in ospfd, has not been compiled since at least
2012. If we are at least 9 years old at this point with no effort
to use or save, we should just get rid of it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Unconfig not resetting the peer-group member allowas_in[afi][safi]
This is causing remote route to be accept.
Signed-off-by: Kishore Kunal <kishorekunal01@broadcom.com>
