This adds 2 commands, one that should just straight up SEGV, another
that should trip an ASAN warning for an use-after-free.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
watchfrr is currently being started with $frr_global_options
This is problematic as that it has a entirely different cli
than the rest of the daemons and we have no plans to make
this equivalent.
Fixes: #18107
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Replace the LSDB callbacks with LSA update and delete hooks using the
the FRR hook mechanism. Remove redundant callbacks by placing the LSA
update and delete hooks in a single place so that deletes don't need
to be handled by the update hook. Simplify existing OSPF TE and OSPF
API Server callbacks now that there is no ambiguity or redundancy.
Also cleanup the debugging by separating out opaque-lsa debugging
from the overloaded event debugging.
Signed-off-by: Acee Lindem <acee@lindem.com>
When a BGP instance with a manually assigned VPN label is deleted, the
label is not released from the Zebra label registry. As a result,
reapplying a configuration with the same manual label leads to VPN
prefix export failures.
For example, with the following configuration:
> router bgp 65000 vrf BLUE
> address-family ipv4 unicast
> label vpn export <int>
Release zebra label registry on unconfiguration.
Fixes: d162d5f6f5 ("bgpd: fix hardset l3vpn label available in mpls pool")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
In bgp_show_table_rd(), the is_last argument is determined using the
expression "next == NULL" to check if the RD table is the last one. This
helps ensure proper JSON formatting.
However, if next is not NULL but is no longer associated with a BGP
table, the JSON output becomes malformed.
Updates the condition to also verify the existence of the next bgp_dest
table.
Fixes: 1ae44dfcba ("bgpd: unify 'show bgp' with RD with normal unicast bgp show")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
According to the YANG specification, the revision statements should be
ordered with the most recent revision first
Signed-off-by: y-bharath14 <y.bharath@samsung.com>
Currently when the fpm_listener attempts to read say X
bytes it may only get Y( which is less than X ). In this
case we should assume that the dplane_fpm_nl code is just
being slow, as that we know it is possible for it to send
a partial fpm message. Let's just loosen the constraints
a bit and allow data to flow.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Even if we have unnumbered peering, let's respect `no neighbor X capability link-local`
and disable it per-neighbor on demand.
Fixes: db853cc97e ("bgpd: Implement Link-Local Next Hop capability")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Make it consistent and call it `event` when formatting something to
display. Much less confusing for some user seeing it too, since threads
aren't involved.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
FRR's event loop prints a warning if a timer is executed more than some
given threshold late, default being 4s. Set a more appropriate
threshold for BFD TX timers (half TX interval).
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Refactor the "timer getting executed too late" warning:
- warning threshold is now adjustable
- check is performed when event actually executes, rather than when it's
thrown on ready list
- ignore_late_timer replaced with threshold = 0
- system load averages printed in log message
- warning ratelimited to once per 10s rather than once per poll()
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Sometimes, NHRP receives L2 information on a cache entry with the
0.0.0.0 IP address. NHRP considers it as valid and updates the binding
with the new IP address.
> Feb 09 20:09:54 aws-sin-vpn01 nhrpd[2695]: [QQ0NK-1H449] Netlink: new-neigh 10.2.114.238 dev dmvpn1 lladdr 162.251.180.10 nud 0x2 cache used 0 type 4
> Feb 09 20:10:35 aws-sin-vpn01 nhrpd[2695]: [QQ0NK-1H449] Netlink: new-neigh 10.2.114.238 dev dmvpn1 lladdr 162.251.180.10 nud 0x4 cache used 1 type 4
> Feb 09 20:10:48 aws-sin-vpn01 nhrpd[2695]: [QQ0NK-1H449] Netlink: del-neigh 10.2.114.238 dev dmvpn1 lladdr 162.251.180.10 nud 0x4 cache used 1 type 4
> Feb 09 20:10:49 aws-sin-vpn01 nhrpd[2695]: [QQ0NK-1H449] Netlink: who-has 10.2.114.238 dev dmvpn1 lladdr (unspec) nud 0x1 cache used 1 type 4
> Feb 09 20:10:49 aws-sin-vpn01 nhrpd[2695]: [QVXNM-NVHEQ] Netlink: update binding for 10.2.114.238 dev dmvpn1 from c 162.251.180.10 peer.vc.nbma 162.251.180.10 to lladdr (unspec)
> Feb 09 20:10:49 aws-sin-vpn01 nhrpd[2695]: [QQ0NK-1H449] Netlink: new-neigh 10.2.114.238 dev dmvpn1 lladdr 0.0.0.0 nud 0x2 cache used 1 type 4
> Feb 09 20:11:30 aws-sin-vpn01 nhrpd[2695]: [QQ0NK-1H449] Netlink: new-neigh 10.2.114.238 dev dmvpn1 lladdr 0.0.0.0 nud 0x4 cache used 1 type 4
Actually, the 0.0.0.0 IP addressed mentiones in the 'who-has' message is
wrong because the nud state value means that value is incomplete and
should not be handled as a valid entry. Instead of considering it, fix
this by by invalidating the current binding. This step is necessary in
order to permit NHRP to trigger resolution requests again.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The transmitted AS value in te tx open message of the peer up loc-rib
message is set to 0. Actually, it should reflect the AS value of the
current BGP instance.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When forging BMP open message, the BGP router-id of tx open message of
the BMP LOC-RIB peer up message is always set to 0.0.0.0, whatever the
configured value of 'bgp router-id'.
Actually, when forging a peer up LOC-RIB message, the BGP router-id
value should be taken from the main BGP instance, and not from the peer
bgp identifier. Fix this by refreshing the router-id whenever a peer up
loc-rib message should be sent.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
