Show BFD sessions updated counters by asking the data plane for this
information and show data plane statistics.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Add hooks in the correct places so the BFD daemon uses the data plane
instead of the software packet sending implementation to monitor the
session.
This code also adds some handlers to support fallback to FRR BFD session
handling, however since this complicates the code it won't work at the
moment (the BFD sockets are disabled by default when using data plane).
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Distributed BFD is a term used for BFD implementations that do not run
on the routing engine, instead it is run on a data plane (software or
hardware based).
The current code implements the basic communication between FRR BFD
daemon with an external BFD data plane and defines the protocol format
in the file `bfddp_packet.h`.
To enable/use data plane you need to start BFD daemon with the command
line `--dplaneaddr <type>:<address>`, then a socket will be opened to
listen for incoming data plane connections.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Initial BFD protocol implementation had a hard coded value of maximum 5
hops, now we have a configurable hop amount with a safe default of 1
hop.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
The passive mode is briefly described in the RFC 5880 Bidirectional
Forwarding Detection (BFD), Section 6.1. Overview:
> A system may take either an Active role or a Passive role in session
> initialization. A system taking the Active role MUST send BFD
> Control packets for a particular session, regardless of whether it
> has received any BFD packets for that session. A system taking the
> Passive role MUST NOT begin sending BFD packets for a particular
> session until it has received a BFD packet for that session, and thus
> has learned the remote system's discriminator value. At least one
> system MUST take the Active role (possibly both). The role that a
> system takes is specific to the application of BFD, and is outside
> the scope of this specification.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
During the shutdown phase don't attempt to apply settings to peers
as it is useless and will crash if the peer hash is gone.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Allow user to pre-configure peers with a profile. If a peer is using a
profile any configuration made to the peer will take precedence over
the profile configuration.
In order to track the peer configuration we have now an extra copy of
the peer configuration in `peer_profile` inside `struct bfd_session`.
This information will help the profile functions to detect user
configurations and avoid overriding what the user configured. This is
especially important for peers created via other protocols where the
default `shutdown` state is disabled (peers created manually are
`shutdown` by default).
Profiles can be used before they exist: if no profile exists then it
will use the default configuration.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Move most of the log messages to debug guards so they only get activated
if the user configured the proper debug level.
Current debug levels:
- Peer events.
- Zebra events.
- Network layer debugs.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Always bind the created sockets to their respective VRF devices. With
this it should be possible to run BFD on VRFs without needing to weaken
the security setting `net.ipv4.udp_l3mdev_accept=1`.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Rearrange the bfdd northbound callbacks as following:
* bfd_nb.h: prototypes of all northbound callbacks.
* bfd_nb.c: definition of all northbound callbacks and their
associated YANG data paths.
* bfd_nb_config.c: implementation of YANG configuration nodes.
* bfd_nb_state.c: implementation of YANG state nodes.
This should help to keep to code more organized and easier to
maintain.
No behavior changes intended.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Scenarios where this code change is required:
1. BFD is un-configured from BGP at remote end.
Neighbour BFD sends ADMIN_DOWN state, but BFD on local side will send
DOWN to BGP, resulting in BGP session DOWN.
Removing BFD session administratively shouldn't bring DOWN BGP session
at local or remote.
2. BFD is un-configured from BGP or shutdown locally.
BFD will send state DOWN to BGP resulting in BGP session DOWN.
(This is akin to saying do not use BFD for BGP)
Removing BFD session administratively shouldn't bring DOWN BGP session at
local or remote.
Signed-off-by: Sayed Mohd Saquib sayed.saquib@broadcom.com
Don't be selective about what to observe, always observe all possible
aspects of the session that may change on run-time (i.e. bind address,
interface and VRF existence).
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
if the bfd session is already enabled, then dynamically change the vrf
name if the vrf where bfd is executed changed its name.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add command 'no bfd' to remove all BFD sessions configuration and fix
other daemon integration.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Lets start using the new BFD yang model and translate the BFD session
configuration commands to use the northbound.
One important change: all sessions will default to use
`VRF_DEFAULT_NAME` (usually "default") when no VRF is configured. All
places which search for BFD sessions must now take this into account.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
These functions are going to be used by the future northbound
implementation to handle BFD sessions.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
MTYPE definitions should be local to the file using them whereever
possible. Also remove some superfluous ;
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
bfd cbit is a value carried out in bfd messages, that permit to keep or
not, the independence between control plane and dataplane. In other
words, while most of the cases plan to flush entries, when bfd goes
down, there are some cases where that bfd event should be ignored. this
is the case with non stop forwarding mechanisms where entries may be
kept. this is the case for BGP, when graceful restart capability is
used. If BFD event down happens, and bgp is in graceful restart mode, it
is wished to ignore the BFD event while waiting for the remote router to
restart.
The changes take into account the following:
- add a config flag across zebra layer so that daemon can set or not the
cbit capability.
- ability for daemons to read the remote bfd capability associated to a bfd
notification.
- in bfdd, according to the value, the cbit value is set
- in bfdd, the received value is retrived and stored in the bfd session
context.
- by default, the local cbit announced to remote is set to 1 while
preservation of the local path is not set.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
this structure contains the bfdd_privs structure in charge of the
privilege settings. The initialisation has moved a bit, in order that
the preinit settings are done.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
parse observer list, and update bs context if vrf pointer is not yet populated.
this is helpful for validation, but also will permit bfd to send
notification to remote daemon.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
vrf initialisation is done. hooks are installed. no specific action is
done, except the vrf initialisation.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
this is a change to be more consistent with function naming convention
in bfd. a small change for 3 functions.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
RFC 5881 Section 4 tells us that the BFD source port must be between
49152 and 65535 inclusive.
Spotted by Lucian Cristian.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
there are cases where bfd sessions are created from remote daemons. in
that case, the bfd daemon were appearing in both operational and
configuration contexts of bfd. Change that by only keeping operational
contexts.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When the local-address configured by the peer doesn't exist, then we
must observe the session until the mentioned address comes up.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Use simplier data structure key to avoid having to do complex and
error-prone key building (e.g. avoid expecting caller to know IPv6
scope id, interface index, vrf index etc...).
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Allow `bfdd` to configure inexisting interfaces / VRF and only activate
them once the interface/VRF start existing. This implementation doesn't
handle dynamic VRFs yet.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Use internal data to lookup sessions. This approach has two main
advantages:
* it uses less memory because it doesn't use strings for interface /
vrf, it uses OS indexes instead;
* prepares code to support VRF;
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Remove some legacy left overs of the old timer data structure bits and
use a simpler version:
We always keep the current configuration in the timer structure, but
also keep the running timers (before poll transition) in
`cur_timers`.
With this we can remove `new_timers` and avoid timer copy
configuration copy on final handler (this also simplifies peer
show command).
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
