When running valgrind there are some possible memory leaks.
These memory leaks we have absolutely no control over, mark
them as not worthy of being reported.
Finally move the valgrind suppressions file from bgpd/ to tools/
this is because this suppressions file can be used beyond bgpd
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When creating a large number of vrf's we are creating a fairly
large number of hash tables per vrf. Reduce memory usage on
startup as well as let us identify the table these things come
from.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
We are creating 2 hash tables per vni in zebra. Once we start to
scale the number of vni's we start to see some serious memory
usage in zebra. Let's reduce the memory usage at startup
for scale of vni's.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Show alias name instead of numerical value in `show bgp <prefix>. E.g.:
```
root@exit1-debian-9:~/frr# vtysh -c 'sh run' | grep 'bgp community alias'
bgp community alias 65001:123 community-1
bgp community alias 65001:123:1 lcommunity-1
root@exit1-debian-9:~/frr#
```
```
exit1-debian-9# sh ip bgp 172.16.16.1/32
BGP routing table entry for 172.16.16.1/32, version 21
Paths: (2 available, best #2, table default)
Advertised to non peer-group peers:
65030
192.168.0.2 from home-spine1.donatas.net(192.168.0.2) (172.16.16.1)
Origin incomplete, metric 0, valid, external, best (Neighbor IP)
Community: 65001:12 65001:13 community-1 65001:65534
Large Community: lcommunity-1 65001:123:2
Last update: Fri Apr 16 12:51:27 2021
exit1-debian-9#
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
The router->register_suppress_time is used to derive the
rp_keep_alive_time, but when the suppress time was changed, pim was
not recalculating the rp_keep_alive_time and left it at the old value.
This fix applies the changes when a new suppress_time is entered
(or removed.)
Signed-off-by: Don Slice <dslice@nvidia.com>
Problem reported that when certain pim commands were entered, they
showed up duplicated in the configuration both under default instance
and every vrf (whether pim was used there or not.) This was because
these particular parameters are global only and the function doing
the display would repeat for each vrf. This fix only displays those
in the default case (and removes them from the help for entering
under a vrf.)
Signed-off-by: Don Slice <dslice@nvidia.com>
Prevent another call path that uses uninited data in
bgp_pbr.c
This was found through more clang sa runs.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
parse_topology function doesn't correctly process vertex types with
spaces. Therefore the reference topology files are completely messed up,
we have values in incorrect fields - types in metrics, metrics in
parents, etc.
This commit fixes the parsing function and the reference files.
The same fix was done for isis-topo1-vrf in #8365.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
vtysh will return an informational message to the user that changing any
graceful-shutdown related parameter will require a peer reset. This is should
not be treated as an error message (resulting in a return code of 1) but
rather as a simple information to the user.
This fixes GitHub issue https://github.com/FRRouting/frr/issues/8403
$ vtysh -c configure -c 'router bgp 100' -c 'bgp graceful-restart'
Graceful restart configuration changed, reset all peers to take effect
$ echo $?
0
Signed-off-by: Christian Poessinger <christian@poessinger.com>
For whatever reason the dampening show run code was outside the normal
loop of code that handles the afi/safi portion. consolidate it into
the rest of the normal code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
bgp_config_write_peer_af already checks to see if we are
a dynamic peer. No need to do so right before we call it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When we are cycling through all peers and looking for
dampening data to dump, do not consider non-configed
peers( dopplegangers ).
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The distribute_list_init command is not used and is setup
code that will never be used because it makes assumptions about
how distribute-lists work that are fundamentally incorrect.
Remove the code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The `distribute-list` commands were registered but never setup
properly to work. Put the commands in place.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Abstract the parsing of distribute lists so that we
don't have as much cut-n-paste code.
This is a setup commit for future work. In effect
current distribute-list handling is all kinds of messed up
a) eigrp and babel both attempt to use distribute-lists, they just plain
don't work.
b) `distribute-list` is only sent to rip. `ipv6 distribute-list`
is sent to ripngd. If you use `distribute-list` under `router ripng`
it sends the command to rip but ripd is in the wrong mode and it
never works.
c) Should ripngd care about v4 and v6 specific distribute-lists?
This dichotomy was added for babel but babel has been broke
about this since day 1( see a ).
All in all we need to unwind this whole mess. Make distribute-list
commands specific to the daemons( so that we can be in the right
sub-mode ). But the parsing is going to be the same across all
daemons. So let's provide that functionality in `lib/distribute.c`
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add a simpler, more limited nexthop comparison function. This
compares a few key attributes, such as vrf, gateway, labels.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
When an "export-filter" or "filter-list out" was configured on an area the
filter was not applied to existing database. The user would either have
to restart the neighboring router in the other area or issue a "clear ipv6
ospf6 interface" to cause the neighbor router to resend it's LSAs. The
new filter would then be applied to these LSAs and permit or deny summary
LSAs from being added/removed from the database. The code now applies the
filters to the existing database without user needing to take any action
to clear ospfv3 adjacencies.
The second part of the problem was if a rule changed the updated filter was
not applied. The code has been modifed to now process the rule update and
reapply the filter.
Signed-off-by: Lynne Morrison <lynne@voltanet.io>
frr(config)# bgp large-community-list expanded com1 permit .*
% Malformed community-list value
The check to validate large-community against UINT_MAX is added for
both standard and expanded community. But however it needs to be
validated only for standard community.
Signed-off-by: Prerana-GB <prerana@vmware.com>
Found a couple spots where FRR was using `case default` when
using a switch over an enum. In this case we *must* enumerate
all states as part of the switch.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
