show/clear DEFUNs always require either peer label or IP address to be
specified, so if `label` is NULL then `peer_str` is definitely not NULL.
But Coverity doesn't know about that, so it complains about possible
NULL dereference of `peer_str`. This commit should make Coverity happy.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Currently there is a single interval for both RX and TX echo functions.
This commit introduces separate RX and TX timers for echo packets.
The main advantage is to be able to set the receive interval to zero
when we don't want to receive echo packets from the remote system.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Current behavior is inconsistent. When the session is created by another
daemon, it is up by default. When we later configure peer in bfdd, the
session is still up, but the NB layer thinks that it is down.
More than that, even when the session is created in bfdd using peer
command, it is created in DOWN state, not ADM_DOWN. And it actually
starts sending and receiving packets. The sessions is marked with
SHUTDOWN flag only when we try to reconfigure some parameter. This
behavior is also very unexpected.
Fixes#7780.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
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>
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>
And again for the name. Why on earth would we centralize this, just so
people can forget to update it?
Signed-off-by: David Lamparter <equinox@diac24.net>
Same as before, instead of shoving this into a big central list we can
just put the parent node in cmd_node.
Signed-off-by: David Lamparter <equinox@diac24.net>
There is really no reason to not put this in the cmd_node.
And while we're add it, rename from pointless ".func" to ".config_write".
[v2: fix forgotten ldpd config_write]
Signed-off-by: David Lamparter <equinox@diac24.net>
The only nodes that have this as 0 don't have a "->func" anyway, so the
entire thing is really just pointless.
Signed-off-by: David Lamparter <equinox@diac24.net>
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>
It's been a year search and destroy.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Adding fields "detect-multiplier" and "remote-detect-multiplier"
for JSON to to reflect changes in "show bfd peers output"
Signed-off-by: Sayed Mohd Saquib sayed.saquib@broadcom.com
Adding new CLI clear bfd counters,
This CLI wil only reset Rx/Tx counters,
it will not reset session UP/DOWN and Zebra event count
Signed-off-by: Sayed Mohd Saquib <sayed.saquib@broadcom.com>
Current autocompletion works only for simple "vrf NAME" case.
This commit expands it also for the following cases:
- "nexthop-vrf NAME" in staticd
- usage of $varname in many daemons
All daemons are updated to use single varname "$vrf_name".
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
This helps northbound to create the `bfd` node on the configuration
output sooner than adding a peer.
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>
the vrf keyword is possible through show bfd command. However, there is
a change with previous version, since that show command was accepting
vrf keyword, only after peer keyword. Now, the vrf keyword is accepted,
but before peer keyword.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
it is possible to configure both iface and vrfname. also, the
appropriate vrf is used, in case an iface is given.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
there is no specific constraints that should prevent from configuring a
multihop bfd session within a bfd session.
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>
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>
Single hop sessions already allow you to select the interface, which
should be enough to determine the VRF we are running in.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>