| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Lou Berger <lberger@labn.net>
|
| |
|
|
|
|
|
| |
The `isisd` will receive a northbound version of the BFD command, so
this is the first step to implement it.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
|
| |
|
|
|
|
|
| |
We should update our neighbors list immediately when an adjacency
changes state, not when we run SPF.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
|
| |
|
|
| |
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
|
| |
|
|
|
|
|
| |
Also track when we received an LSP as do not reflood, as well as the
time when we last considered flooding it.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
|
| |
|
|
|
|
| |
Add a command to show to what neighbors an LSP has been flooded.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this commit, fabricd can run without any IPv4 addresses configured
except on loopback. There are two changes to achieve this:
a) If a circuit has no IPv4 address configured, fabricd will resort to
advertise the routers loopback IP in the OpenFabric hellos.
b) All the routes from OpenFabric are sent with ZEBRA_FLAG_ONLINK set,
so that zebra will install them into the fib without checking whether
the nexthop is reachable
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
|
| |
|
|
|
|
|
| |
Have fabricd send out a CSNP whenever a circuit scoped LSP is received,
and log a warning if the CSNP showed resynchronization was necessary.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
|
| |
|
|
|
|
|
|
|
|
| |
Regular IS-IS will flood any LSP updates out to all circuits except the
one where it was received on. This is done in `lsp_flood`.
Change `lsp_flood` for fabricd to use the optimized flooding algorithm
instead.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
While OpenFabric calculates most tier numbers automatically by the
fabric locality calculation algorithm, that algorithm requires two
systems to be manually configured as tier 0, so it has reference points.
Also, completely manual configuration is possible.
To support this, introduce appropriate CLI commands and flood the
configured information.
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>
|
