The current strategy for fine-grained debugging across FRR is to use
static long int bitfields, in combination with helper macros that are
copy-pasted between daemons, to hold state on what debugging information
should be collected at any given time. This has a couple of problems:
* These bitfields are generally extern'd and accessed everywhere, so
they are not MT-safe or easy to make MT-safe
* Lots of code duplication from copy-pasting the DEBUG_* macros...
* Code duplication because of the "term" vs "conf" debugging concept
This patch aims to remedy that by providing some infrastructure to work
with debugs. The core concept of using bitfields has been retained, but
the number of these for each debug has been reduced to 1. This allows
easy use of lock-free methods for synchronizing access to debugging
info.
The helper macros have also been retained but they are now collected in
one place and perform exclusively atomic operations.
Finally there is a bit of code that allows daemons to register
callbacks, which I used to implement a command that will toggle all
debugging for any daemons that use these facilities.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Error message for missing sphinx-build wasn't clear enough when
explaining how to change the path to the sphinx-build binary as it said
'environment variable' instead of 'make variable'
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* New manpage: mtracebis.rst
* Makefile.am includes mtracebis.rst
* configure.ac lines removed
* Debian packaging files updated
* Fixed up manpage |seealso-programs| in the process
* Centos7 build package list updated to include systemd-devel
* New paragraph on netns vrf support in zebra manpage
Conflicts:
configure.ac
debianpkg/backports/ubuntu14.04/debian/frr.install
debianpkg/frr.install
doc/Makefile.am
doc/developer/Building_FRR_on_CentOS7.rst
doc/zebra.8.in
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
The route being added check its origin matches,
with any of the existing path (list of paths).
Remove the existing path, add if its cost is
eqaual or less than any of the existing path.
For a given route and of existing path cost is lower
(better) than one being added, discard new route update.
The existing path cost is higher (lower) than one being
added, ospf6_route_add replaces existing with new route
info.
Compare cost between delete request and with existing
route.
Ticket:CM-16139
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Causes build issues on a certain 7 year old platform with a severely out
of date sphinx package, requires a full texinfo distribution to build a
package and nobody reads book-style manuals in 2018 anyway, its all
about the web docs...
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Add the originating routes type and instance to the nexthop
update message. This is necessary because there exist
scenarios where BGP needs to make a decision about the
originating route type and instance to know if it is
going to be doing a route replace to a route that would
resolve to itself.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
So when a ospf SR is sending down routes to the kernel
ensure that the nexthop vrf_id is set appropriately.
Yes SR is in the default VRF. But for people who
run across this code in the future, they will know
to do the right thing from it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When decoding and creating the appropriate data structures
for a nexthop, use the passed in vrf.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The addition of some rmac code snuck in the usage of a
stream_get instead of a STREAM_GET()
We need to be using STREAM_GET()
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Implement support for EVPN symmetric routing for IPv6 routes. The next hop
for EVPN routes is the IP address of the remote VTEP which is only an IPv4
address. This means that for IPv6 symmetric routing, there will be IPv6
destinations with IPv4 next hops. To make this work, the IPv4 next hops are
converted into IPv4-mapped IPv6 addresses.
As part of support, ensure that "L3" route-targets are not announced with
IPv6 link-local addresses so that they won't be installed in the routing
table.
Signed-off-by: Vivek Venkatraman vivek@cumulusnetworks.com
Reviewed-by: Mitesh Kanjariya mitesh@cumulusnetworks.com
Reviewed-by: Donald Sharp sharpd@cumulusnetworks.com
- To ease checking the Segment Routing conformity in topotest,
add json output to 'show ip ospf database segment-routing' CLI.
- Update ospfd user guide accordingly
- Update OSPF-SR documentation with supported features and interoperability
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
We have af_flags in struct bgp which holds address family related flags.
Seems like we had a conflict between two flags.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
This limitation ignores the creation of a new NS context, when an
already present NS is available with the same NSID. This limitation
removes confusion, so that only the first NS will be used for
configuration.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
So as to get the correct NETNS where some discovery must be done and
populated, the zns pointer is directly retrieved from zvrf, instead of
checking that the VRF is a backend NETNS or not.
In the case where the interfaces are discovered before the VRF is enabled
( VRF-lite populate), then the default NS is retrieved.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The change consists in taking into account of the VRF identifier upon
which the ospf socket is created. Moreover, if the VRF is a netns
backend, then it is not necessary to perform the bind operations to vrf
device.
Also, when a VRF instance is enabled, it informs ospf VRF, and automatically
OSPF VRF benefits from it. Reversely, when VRF instance is disabled,
then OSPF VRF will be disabled too.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Instead of relying on local usage of vrf bind operation, the vrf API for
that usage is done.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
fixup bgp
Because socket creation is tightly linked with socket binding for vrf
lite, the proposal is made to extend socket creation APIs and to create
a new API called vrf_bind that applies to vrf lite. The passed interface
name is the interface that will be bound to the socket passed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
That API can be used to wrap the ioctl call with various vrf instances.
This permits transparently doing the ioctl() call without taking into
consideration the vrf backend kind.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
NETNS is initialised from the VRF, instead of being directly called,
because this is not up to BGP daemon to initialise the various VRF
backend.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The logical router node goes from NS_NODE to LOGICALROUTER_NODE.
Vty commands are renamed accordingly.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The zebra daemon introduces the logical router initialisation.
Because right now, the usage of logical router and vrf NETNS is
exclusive, then the logical router and VRF are initialised accordingly.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This split is introducing logicalrouter.[ch] as the file that contains
the vty commands to configure logical router feature. The split has as
consequence that the backend of logical router is linux_netns.c formerly
called ns.c. The same relationship exists between VRF and its backend
which may be linux_netns.c file.
The split is adapting ns and vrf fiels so as to :
- clarify header
- ensure that the daemon persepctive, the feature VRF or logical router
is called instead of calling directly ns.
- this implies that VRF will call NS apis, as logical router does.
Also, like it is done for default NS and default VRF, the associated VRF
is enabled first, before NETNS is enabled, so that zvrf->zns pointer is
valid when NETNS discovery applies.
Also, other_netns.c file is a stub handler that will be used for non
linux systems. As NETNS feature is only used by Linux, some BSD systems
may want to use the same backend API to benefit from NETNS. This is what
that file has been done.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
