Note that we do not return the actual tlv_type and offset
of the erroneous TLV. This is because unpacking tlvs currently
uses a chain of function calls, where the notification can only
be sent at the start of the chain, but the tlv_type and offset
information are only available at the end. Unless we change the
code to propagate those values, we have no way to feed them to
the notification. So these leafs are not generated.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
the original isisd code did not distinguish between
authentication_failure and authentication_type_failure, so
additional code had to be added to differentiate between the two
and to return the raw_pdu as requested by the IETF YANG model.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
Note that the original IETF YANG model also included
a requirement to throttle such notifications so that they would
not be sent more often than once every 5 seconds. I did not
implement any throttling mechanism yet, mostly because I am
not sure whether this limit should apply to the entire isis daemon,
to each area, to each neighbor etc.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
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>
To allow easier debugging of LSP transmission scheduling, add a debug
mode where all tx-queue insertions/deletions are logged.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Add a function send_hello_sched so that the logic for scheduling a
hello is not replicated inconsistently into different locations.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
This reverts commit 48944eb65e.
We're using GNU C, not ISO C - and this commit triggers new (real)
warnings about {0} instead of bogus ones about {}.
Signed-off-by: David Lamparter <equinox@diac24.net>
We should only update and reflood our own LSPs when the received LSP
is newer than the local copy.
In all other cases, we should simply acknowledge it or resend our own
LSP.
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>
The OpenFabric draft prescribes that any IS-IS PDUs not needed for
OpenFabric operation MUST be ignored. So this commit makes fabricd
ignore any LAN IIHs and any L1 LSPs.
Also the draft specifies that any reachabilities given as narrow-metric
TLVs SHALL be ignored, so adhere to that too.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Implement RFC 6232, optionally allowing to flood isisd's NET and
hostname in purges it originates.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
OpenFabric makes use of flooding scope LSPs to reduce the amount of
reflooding caused by the update process. Implement transmission and
reception of such PDUs.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Before this commit, isisd/fabricd maintained a bitfield for each LSP
to track the SRM bit for each circuit, which specifies whether an LSP
needs to be sent on that circuit. Every second, it would scan over all
LSPs in `lsp_tick` and queue them up for transmission accordingly.
This design has two drawbacks: a) it scales poorly b) it adds
unacceptable latency to the update process: each router takes a random
amount of time between 0 and 1 seconds to forward an update. In a
network with a diamter of 10, it might already take 10 seconds for an
update to traverse the network.
To mitigate this, a new design was chosen. Instead of tracking SRM in a
bitfield, have one tx_queue per circuit and declare that an LSP is in
that queue if and only if it would have SRM set for that circuit.
This way, we can track SRM similarly as we did before, however, on
insertion into the LSP queue, we can add a timer for (re)transmission,
alleviating the need for a periodic scan with LSP tick and reducing the
latency for forwarding of updates.
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>
isisd verifies whether the neighboring IPv4 addresses overlap with its own
unless the interface is running in unnumbered mode. If no overlap is found
and IPv6 is also not enabled, IIHs will be ignored.
Add a debug message for this case, to avoid people wondering why adjacencies
are not coming up.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
The following types are nonstandard:
- u_char
- u_short
- u_int
- u_long
- u_int8_t
- u_int16_t
- u_int32_t
Replace them with the C99 standard types:
- uint8_t
- unsigned short
- unsigned int
- unsigned long
- uint8_t
- uint16_t
- uint32_t
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Convert the list_delete(struct list *) function to use
struct list **. This is to allow the list pointer to be nulled.
I keep running into uses of this list_delete function where we
forget to set the returned pointer to NULL and attempt to use
it and then experience a crash, usually after the developer
has long since left the building.
Let's make the api explicit in it setting the list pointer
to null.
Cynical Prediction: This code will expose a attempt
to use the NULL'ed list pointer in some obscure bit
of code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This reverts commit c14777c6bf.
clang 5 is not widely available enough for people to indent with. This
is particularly problematic when rebasing/adjusting branches.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The FSF's address changed, and we had a mixture of comment styles for
the GPL file header. (The style with * at the beginning won out with
580 to 141 in existing files.)
Note: I've intentionally left intact other "variations" of the copyright
header, e.g. whether it says "Zebra", "Quagga", "FRR", or nothing.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The way thread.c is written, a caller who wishes to be able to cancel a
thread or avoid scheduling it twice must keep a reference to the thread.
Typically this is done with a long lived pointer whose value is checked
for null in order to know if the thread is currently scheduled. The
check-and-schedule idiom is so common that several wrapper macros in
thread.h existed solely to provide it.
This patch removes those macros and adds a new parameter to all
thread_add_* functions which is a pointer to the struct thread * to
store the result of a scheduling call. If the value passed is non-null,
the thread will only be scheduled if the value is null. This helps with
consistency.
A Coccinelle spatch has been used to transform code of the form:
if (t == NULL)
t = thread_add_* (...)
to the form
thread_add_* (..., &t)
The THREAD_ON macros have also been transformed to the underlying
thread.c calls.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This reduces code duplication and the likelihood of a bug like 186534
("isisd: fix loss of packets after circuit is brought up") to happen
again.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
There's no need to provide two definitions of the isis_receive()
function (one for GNU_LINUX and the other for !GNU_LINUX). Both differ
only slightly so it makes more sense to define isis_receive() just once
and use a smaller #ifdef to account for these differences. This improves
code readability.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
bgpd/bgpd.c had a typo
zebra/zebra_mpls_netlink.c was derived from rt_netlink.c
isisd/include-netbsd/* are not needed (2 constants moved over)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
These patches is an implementation of RFC5305 that enable the
support of Traffic Engineering in IS-IS
* isisd/Makefile.am: Add new files isis_te.c and isis_te.h
* isisd/isis_circuit.[c,h]: Add new mpls_te_circuit structure to isis_circuit
structure to handle new Traffic Engineering TLVs
* isisd/isis_lsp.c: Update LSP handler to mux/demux Traffic Engineering TLVs
* isisd/isis_main.c: Add initialisation of ISIS TE
* isisd/isis_pdu.c: Update function process_p2p_hello() to retrieve remote IP
address to populate Traffic Engineering TLV.
* isisd/isis_te.[c,]: Implementation of RFC5305
* isisd/isis_tlv.[c,h]: Update TLV definition and function to handle
Traffic Engineering ones
* isisd/isis_zebra.c: Add new function isis_zebra_link_params() to retrieve
the link parameters of interfaces from ZBus to populate the Traffic Engineering
TLVs
* isisd/isisd.[c,h]: Add Traffic Engineering support with new debug command
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
isisd had a few places that mixed up size_t vs. unsigned long, and %zd
vs. %ld. Clean out.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit 01da6176b88fe59b3c6ceaf3630df88046c83159)
isis_pdu.c :
New adjacency did not always get added to LSP neighbor list.
The adjacencies that were created once minimum time allowed before LSP
retransmission had surpassed, instantly got their LSP regenerated, but
the adjacency circuit type was not set to IIH PDU circuit type before
the LSP was regenerated , hence didn't pass the check for adjacency
circuit type in lsp_build(), and the adjacency was not added to neighbor list.
When a new adjacency is up, to build LSP with neighbor entry corresponding
to the adjacency, set adjacency circuit type to circuit type from hello PDU
header before new LSP is regenerated/built. This will result in the new
adjacency entry getting added to the LSP neighbor list TLV.
Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
(cherry picked from commit 06cc655c0345d610eb946bd41968caa03dc118ed)
isis_pdu.c :
isisd crashes if router's own p2p hello packets get processed
thereby creating an adjacecncy with itself. Asserts at
isis_find_vertex. So discard own p2p IIH PDU and avoid
creating adjacency with self. This would also fix duplicate
systemID on an interface. These checks already exists for IS-IS
LAN Level 1/2 Hello PDU in process_lan_hello, but not for
point-to-point IIH PDUs.
Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit 491417ac6383e2ea557951b24eb7bd3fffb69394)
isis_pdu.c: match adjacency with source of hellos,
check for source ID on receiving hello
If an adjacency exists, check the adjacency is with the
same router as the source of the hellos. In case a mismatch
is detected, bring down the adjacency and let the next
hellos trigger creating the new adjacency.
Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit 3c28aaf437d8d473adb89c5e74574a61a9ea7cc6)
These pre-initialized arrays are not modified.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Feng Lu <lu.feng@6wind.com>
(cherry picked from commit 88d37b902bc8127379d3293b9671aa6a11479c23)
The changed messages are actually located before transmission is
attempted. Therefore, the tense is somewhat misleading, especially
since transmission may not always succeed.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
New circuits should be initialized to match the is_type
of their area. Also add an additional check to make sure
that no IIHs are sent for levels which are not enabled.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
Whoops, these are in6_addrs, not prefix_ipv6... funnily enough, it does the
right thing either way, if it compiles, which it only does on Linux because
IN6_IS_ADDR_LINKLOCAL contains a cast to the right type. On BSD there is no
such cast, hence it explodes on trying to compile, trying to access struct
members of in6_addrs while operating on prefix_ipv6...
Fixes: 28a8cfc ("isisd: don't require IPv4 for adjacency")
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This was precluding isisd from IPv6-only operation; no adjacency would
come up unless there was IPv4 in parallel.
Reported-by: Martin Winter <mwinter@netdef.org>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
isisd should not form adjacencies on receiving an IS-IS Hello without a
list of supported protocols (cf. RFC 1195 s4.4 p32 "Maintaining Router
Adjacencies") Also fixes memleaks in these error cases.
* isisd/isis_pdu.c: improve TLVFLAG_NLPID handling
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Tested-by: Martin Winter <mwinter@opensourcerouting.org>
isisd would form an adjacency with another router despite the system IDs
being identical. This would later cause an assertion failure like this:
assertion=0x555555596db8 "isis_find_vertex (spftree->paths, id, vtype) == ((void *)0)",
file=0x555555596c60 "isis_spf.c", line=515, function=0x555555597900 "isis_spf_add2tent") at log.c:619
which is caused by trying to add a path expected to not exist, but
suddenly colliding due to the duplicate system ID.
* isis_pdu.c: check for system ID collision on receiving Hello
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
isisd currently has a list of supported protocols as a fixed array of
size 4. this can be overran, leading to an overwrite of the ipv4_addrs
pointer.
* isisd/isis_pdu.c: don't accept more protocols than there's space for
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* isisd/isis_pdu.c: (send_lsp) Handle case where there are no LSPs
on the LSP transmission queue. This can happen if, for instance,
the queue is cleared because of protocol events before the
send_lsp thread gets a chance to run.
* isisd/isis_pdu.c: Fix problem where isisd would crash if it
received a LAN IIH with the 'pdu length' field set to zero.
Similar problems can occur in parsing other ISIS PDUs as well --
check that the PDU length in an ISIS hello, LSP or SNP packet is
at least as big as the size of the respective fixed header.
