Add build-essential and, for platforms with systemd, libsystemd-dev to
the package list for builds
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
For VRF route leak, enable route map filter based
on "source-vrf" check.
Implemented match filter rule for "source-vrf" which
compares leaked routes original vrf_id (where it leaked from)
during importing into target VRF.
Ticket:CM-23776
Reviewed By:
Testing Done:
Configure vrf route leak from vrf1 to vrf2,
configure import vrf under vrf2 along with route-map
with source-vrf filter.
Add and remove source-vrf filter and checked routes
were added and removed to vrf2 table via vpn (default) table.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
I just straight up forgot checking VTYSH_PAGER at startup, and the
"terminal paginate" command is only installed to VIEW_NODE so it can't
be processed from vtysh.conf in CONFIG_NODE...
Signed-off-by: David Lamparter <equinox@diac24.net>
Since LSP fragments are also on our lspdb dict, lsp_tick() needs to skip
over them after calling lsp_destroy(). Otherwise it ends up accessing
free'd memory.
Fixes: #3533
Signed-off-by: David Lamparter <equinox@diac24.net>
Commit fdbd8086b1 removed the explicit -lconfd flag from
lib_confd_la_LIBADD in favor of using the CONFD_LIBS variable. The
problem, however, is that ConfD doesn't use pkg-config nor anything
similar, so CONFD_LIBS is not created automatically by autotools.
Fix this problem by manually assigning -lconfd to the CONFD_LIBS
variable in the configure script.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
"When building without VNC, automake sees that the `bgpd_bgpd_CFLAGS`
variable exists, although it is only set in the VNC-enabled case... but
since the variable exists, it unconditionally drops `AM_CFLAGS` for the
two bgp targets and uses `bgpd_bgpd_CFLAGS` instead, which will
contain... _nothing_."
This was breaking builds of bgpd binaries with MSAN enabled.
Signed-off-by: David Lamparter <equinox@diac24.net>
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
there are some events where the list of interfaces per area should be
reviewed due to an interface is being removed. This fix avoids having
some memory leak.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Apply new timers when only one side is negotiating new settings: when
sending the final bit we must apply the remote settings, otherwise
we'll keep the previous transmission rate.
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>
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>
`echo-mode` should and will automatically start after session goes up
and it is allowed by the remote peer. See `bs_echo_timer_handler` for
more information.
This avoids having echo controling code spread.
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>
RFC 5880 says that it is only necessary to run polling in two cases:
- Desired minimum transmission interval;
- Required minimum receive interval;
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
