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>
Coverity is pointing out that bfd_key_delete is
passing by value instead of reference for a very
large structure. Double plus not good.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The function bfd_key_lookup is currently sending by value for
a now very large structure. Let's convert this over to pass
by reference. This is noticed by coverity.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
sbfd will use bfdname for key hash, We introduced a bfd-name for every sbfd session, normal BFD sessions can leave it as NULL.
A unique bfd-name can be used to identify a sbfd session quickly. This is quite useful in our Srv6 deployment for path protection case.
For example, if use the sbfd session to protect the SRv6 path A-B-D, we would assign the name 'path-a-b-d' or 'a-b-d' to the session.
Signed-off-by: wumu.zsl <wumu.zsl@alibaba-inc.com>
When using bfd in remote-dataplane client mode, don't close
a new client socket if we're going to try to use it.
Signed-off-by: Mark Stapp <mjs@cisco.com>
Lets avoid a performance penalty in forwarding when not using the BFD
echo feature. The echo socket uses raw packet capturing along with a BPF
filter which causes performance issues.
While here change code to use `-1` for closed sockets instead of valid
FD number `0`.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
The minimum and maximum values for BFD timers and multiplier settings
have been updated to align with RFC 5880 requirements.
Since the values inputted via VTY are in milliseconds, the maximum
permissible value on the VTY interface is 4,294,967 milliseconds.
For the multiplier setting, the minimum value is now restricted to be
greater than zero, as zero is not allowed.
The minimum transmit interval has been set to 10 milliseconds to ensure
reliable service performance.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Let's remove the obsolete BFD control socket. If the functionality is
needed then YANG/northbound notifications / getting should be used
instead.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Create a single registry of default port values that daemons
are using. Most of these are vty ports, but there are some
others for features like ospfapi and zebra FPM.
Signed-off-by: Mark Stapp <mjs@labn.net>
clang-format doesn't understand FRR_DAEMON_INFO is a long macro where
laying out items semantically makes sense.
(Also use only one `FRR_DAEMON_INFO(` in isisd so editors don't get
confused with the mismatching `( ( )`.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Practically no-one uses this and ioctls are pretty much
wrappered. Further wrappering could make this even better.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
INTERFACE_NAMSIZ is just a redefine of IFNAMSIZ and IFNAMSIZ
is the standard for interface name length on all platforms
that FRR currently compiles on.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The headers associated with netlink code
really only belong in those that need it.
Move these headers out of lib/zebra.h and
into more appropriate places. bgp's usage
of the RT_TABLE_XXX defines are probably not
appropriate and will be cleaned up in future
commits.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
...so that multiple functions can be subscribed.
The create/destroy hooks are renamed to real/unreal because that's what
they *actually* signal.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Currently when one interface changes its VRF, zebra will send these messages to
all daemons in *order*:
1) `ZEBRA_INTERFACE_DELETE` ( notify them delete from old VRF )
2) `ZEBRA_INTERFACE_VRF_UPDATE` ( notify them move from old to new VRF )
3) `ZEBRA_INTERFACE_ADD` ( notify them added into new VRF )
When daemons deal with `VRF_UPDATE`, they use
`zebra_interface_vrf_update_read()->if_lookup_by_name()`
to check the interface exist or not in old VRF. This check will always return
*NULL* because `DELETE` ( deleted from old VRF ) is already done, so can't
find this interface in old VRF.
Send `VRF_UPDATE` is redundant and unuseful. `DELETE` and `ADD` are enough,
they will deal with RB tree, so don't send this `VRF_UPDATE` message when
vrf changes.
Since all daemons have good mechanism to deal with changing vrf, and don't
use this `VRF_UPDATE` mechanism. So, it is safe to completely remove
all the code with `VRF_UPDATE`.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
Add parameters to the "show bfd peers json" command to
display interface and type of BFD session.
Signed-off-by: Lynne Morrison <lynne.morrison@ibm.com>
