fabricd: adjacency formation optimization as per section 2.4
OpenFabric changes IS-IS's initial database synchronization. While
regular IS-IS will simultaneuously exchange LSPs with all neighboring
routers during startup, this is considered too much churn for a densely
connected fabric.
To mitigate this, OpenFabric prescribes that a router should only
bring up an adjacency with a single neighbor and perform a full
synchronization with that neighbor, before bringing up further
adjacencies.
This is implemented by having a field `initial_sync_state` in the
fabricd datastructure which tracks whether an initial sync is still
pending, currently in progress, or complete.
When an initial sync is pending, the state will transition to the
in-progress state when the first IIH is received.
During this state, all IIHs from other routers are ignored. Any
IIHs transmitted on any link other than the one to the router with
which we are performing the initial sync will always report the far
end as DOWN in their threeway handshake state, avoiding the formation of
additional adjacencies.
The state will be left if all the SRM and SSN flags on the
initial-sync circuit are cleared (meaning that initial sync has
completed). This is checked in `lsp_tick`. When this condition occurrs,
we progress to the initial-sync-complete state, allowing other
adjacencies to form.
The state can also be left if the initial synchronization is taking too
long to succeed, for whatever reason. In that case, we fall back to the
initial-sync-pending state and will reattempt initial synchronization
with a different neighbor.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Christian Franke [Thu, 22 Mar 2018 13:58:53 +0000 (14:58 +0100)]
fabricd: adjust IS-IS defaults as per draft
OpenFabric specifies that it should always be run with wide metrics via
P2P links and only as Level-2. Implement this as default and remove all
the knobs from fabricd which allow other configuration.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Christian Franke [Thu, 22 Mar 2018 13:44:01 +0000 (14:44 +0100)]
isis: Cleanup CLI, split into parts which are shared, fabricd and isisd
Remove isis_vty.c and create three new files isis_vty_common.c,
isis_vty_fabricd.c and isis_vty_isisd.c which are built into both
daemons, only fabricd and only isisd, respectively.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Donald Sharp [Wed, 29 Aug 2018 02:45:06 +0000 (22:45 -0400)]
staticd: Fix mixup in vrf translations
When we store the nexthop for ref-counting, keep
track of the nexthop vrf_id as well. This will allow
us to track the nexthop per vrf!
Additionally when we get the callback from zebra about
a nexthop update, iterate over all static routes to
see if the nexthop we are getting a callback is
one we are concerned about.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 3 Aug 2018 17:18:59 +0000 (13:18 -0400)]
lib: Add Aggregate Table and Aggregate_node
Add a abstraction for `struct route_node` and `struct route_table`
such that we can have an aggregate route_node and table. This
is because only bgp/rfapi and ripng use the aggregate data pointer
in `struct route_node`. For full route tables other routing
protocols and tables are paying a 8 byte overhead per node.
A full bgp table ends up being ~1.2 million routes in bgp
and zebra. This is not an insiginificant amount of data.
So create the data structures for this replacement, but
do not replace the aggregate pointer yet. This is because
later commits will convert rfapi and ripng over to this
new data, and finally we'll move the aggregate pointer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Don Slice [Wed, 29 Aug 2018 12:19:54 +0000 (12:19 +0000)]
bgpd/ospfd: make bgp and ospf json response a bit more consistent
Problem reported that some bgp and ospf json commands did not return
any json output at all if the bgp/ospf instance did not exist.
Additionally, some bgp and ospf json commands did not return any json
output if the instance existed but no neighbors were defined. This
fix makes these commands more consistent in returning empty braces for
json output and issue a message if not using json output. Additionally,
made the flag "use_json" a bool to make it consistent since previously,
it had been defined as an int, char, u_char, and bool at various places.
Ticket: CM-21040 Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
David Lamparter [Wed, 29 Aug 2018 03:28:06 +0000 (05:28 +0200)]
doc: drop colspan/rowspan elements
The sphinx 'text' writer apparently doesn't support these, and the
'dummy' writer is only available on recent versions, and all of this
makes the build a bit annoying...
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Wed, 22 Aug 2018 04:04:32 +0000 (06:04 +0200)]
build: improve python search pattern
- try pythonN.N-config after pythonN-config
- use "python-config --ldflags" instead of --libs
- add Python 3.6 to explicitly searched versions
- if linking fails, try with "-lz" added
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Tue, 21 Aug 2018 18:33:13 +0000 (20:33 +0200)]
build: add warning when overwriting vars on "make"
doing things like `make CC="mmix-linux-musl-gcc"` breaks the hosttools/
cross-compilation setup pretty hard and just straight up should not be
done. These vars belong on `configure`, not `make`.
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Wed, 15 Aug 2018 20:59:31 +0000 (22:59 +0200)]
build: non-recursive doc + parallel sphinx
Sphinx actually does work with a parallel build, if the doctree creation
is a separate step (which the other builds will then just read
unmodified.) This can be done with the "dummy" target.
This also adds "-j6" to sphinx-build and adds a "--disable-doc-html"
switch on ./configure to turn on/off building HTML docs separately.
Also, HTML docs are now installed by "make install" to
/usr/share/doc/frr/html.
Signed-off-by: David Lamparter <equinox@diac24.net>
Philippe Guibert [Fri, 22 Jun 2018 14:01:07 +0000 (16:01 +0200)]
doc: add information about dynamic update of default vrf name
It is possible to dynamically change default VRF name, if vrf backend is
a netns backend. By creating a link to the default netns in
/var/run/netns folder, then the file name will be used to name the
default VRF. If no backend netns is chosen, it is explained that it is
still possible to statically configure the default vrf name to new
define.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Fri, 22 Jun 2018 14:03:11 +0000 (16:03 +0200)]
lib: protect newly created vrfs against default vrf naming.
Prevent from creating vrf, if the default vrf name is the same as the
vrf to be created.
Also, prevent at startup from creating default vrf with a name already
used in vrf list.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Thu, 31 May 2018 08:12:11 +0000 (10:12 +0200)]
bgpd: handle vrf aliases in vty API
Because a VRF name can be used for default VRF, or an alias of an
already created VRF can be passed as parameter, the default VRF name
must be found out. This avoids creating double BGP instances for
example.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Tue, 29 May 2018 09:17:10 +0000 (11:17 +0200)]
*: add a vrf update hook to be informed of the vrf name
The Vrf aliases can be known with a specific hook. That hook will then,
from zebra propagate the information to the relevant zapi clients.
The registration hook function is the same for all daemons.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
projects / matthieu / frr.git / log