By moving the spf datastructures to a header, fabricd can access the
results of the spf run for flooding optimization or fabric locality
calculation.
While this was deemed a sensible choice in this case, when compared with
the option of adding a lot of OpenFabric specific code to isis_spf.c,
the datastructures should still not be accessed randomly all over the
code base. To make this more clear, the new header was called
isis_spf_private.h (Think of a friend class)
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
OpenFabric uses an spf with the metric for all links set to one,
both for flooding optimization and for fabric locality detection.
So extend isisd's spf code to allow running it with such a metric
and have it run whenever normal spf runs.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
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>
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>
The 'no ip router isis' command would incorrectly output the afi if the
area to delete does not exist. Make it output the area name instead.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
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>
Extend extract.pl so it can deal with the isis source code being
compiled twice, once for isisd and once for fabricd.
Add the fabricd node and client to vtysh.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
fabricd is built using the sources of isisd. To allow differentiation
in the code, -DFABRICD=1 is added to its preprocessor flags.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
The ZEBRA_IPV4_ROUTE_IPV6_NEXTHOP_ADD zapi message has no creators and
no handlers. Let's just remove.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Addressed all of @qlyoung's "presentational nits
and a formatting suggestion". As well as
@rwestphal's idea of OS and FRR name+version
numbers.
Signed-off-by: Christoffer <netravnen@gmail.com>
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>
Move the aggregate pointer from the route_node into agg_node
so that people using struct route_node will see a savings
in data size.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Switch bgp and ripngd to use the new aggregate table and
route data structures. This was mainly a search and replace
operation.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
