| Age | Commit message (Collapse) | Author |
|---|
|
populated. Intra-area routes only for now.
"I see no obvious issues. Should go in so you can move forward" claudio@
|
|
we never entered this code path before. This is just a temporary fix.
The kroute code desperately needs a sync to ospfd.
"Looks sensible to me" jsing@, "Yes and yes" claudio@
|
|
"consistency is a good thing" jsing@, ok claudio@
|
|
allocations fails.
looks right deraadt, krw
ok henning
|
|
This implements the first stage of the shortest path tree calculation
(Dijkstra calculation) as outlined in rfc5340, with the exception that
we do not yet treat multiple router LSAs originated by a single router
as an agregate. For now, we only use the Router LSA with the lowest link
state ID.
For each destination, show the calculated set of nexthops in the debug log.
We can stop doing this once spf tree calculation has been shown to be stable.
"A lot of debug code but yes why not. commit it." claudio@
|
|
last commit. Next hop IP addresses and outgoing interfaces can now
be correctly determined, paving the way for SPF tree calculation.
Arguments have changed, so update callers, too.
ok claudio@
|
|
next-hop calculation.
In OSPFv3, next-hop IP addresses are always link-local.
The kernel will want to know which interface the link-local
address belongs to, so we need an ifindex in struct v_nexthop
in addition to the IP address.
Because we cannot determine a link-local next hop IP address
for transit networks, only the outgoing interface will be recorded.
Update calc_nexthop_add() according to the above.
Also add new helpers calc_nexthop_lladdr() and calc_nexthop_transit_nbr(),
to figure out link-local addresses of nexthop neighbours.
ok claudio@
|
|
A router vertex w has a point-to-point link back to a router
vertex v if v's router ID occurs as neighbour ID in one of the
point-to-point links described in w's router LSA.
A router vertex w has a link back to a network vertex v if the router
ID of v's advertising router (i.e. DR) occurs as neighbour ID in one
of the transit links described in w's router LSA, and v's interface
ID to the network matches the neighbour interface ID of that transit
link.
A network vertex w has a link back to a router vertex v if v's router
ID occurs in the list of attached routers in w's network LSA.
Also, get_rtr_link() and get_net_link() take an unsigned int now.
"commit it" claudio@
|
|
use less local variables. Makes it consistent with get_rtr_link().
ok claudio@
|
|
it was always returning the first link in the LSA, no matter
which link was requested. Fix this bug. Also, decrease the
number of local variables while here, and convert the idx argument
to unsigned int. Adjust one caller to pass an unsigned int,
other callers will be handled in follow-up commits.
ok claudio@
|
|
pointed out by and ok claudio@
|
|
LSAs originated by the same router the one with the lowest link
state ID.
ok claudio@
|
|
are subtracted from the total length.
ok claudio@
|
|
Most obvious use is to log router IDs.
To facilitate logging of multiple IDs within the same format string,
we use NUM_LOGS static buffers, just like log_sockaddr() does.
help and ok claudio@
|
|
can make use of it much better. No functional change.
ok claudio@
|
|
In Network-LSAs, the only thing sitting between the LSA header
and the attached router list is the options field. We already
have lsa_net_link to represent elements of the attached router list,
so there's no need to have a single entry of this list in lsa_net.
ok claudio@
|
|
in hello packets by next-hop neighbours. So when notifying the
RDE of a new neighbour, send the source address, too.
ok claudio@
|
|
ok stsp@
|
|
buried inside of it that its caller relied on.
So split it up as follows:
lsa_self() Check whether an LSA is self-originated.
lsa_flush() Flush an LSA from the LSDB.
lsa_reflood() Prepare an LSA for reflooding (actual reflooding currently
requires sending an imsg which must be done by the caller).
ok claudio@
|
|
as "spf_calc" in fatal error messages.
|
|
|
|
as "spf_calc" in fatal error messages.
|
|
"Do we need anything fancy to determine whether *-prefix-LSAs
are self-originated?"
The answer is "No, we don't, see section 4.6 of RFC5340."
ok claudio@
|
|
We had code marked XXX searching an LSA tree manually using RB_FIND(),
switch it over to lsa_find_tree().
Make lsa_find() use the new function, too, to avoid code duplication.
ok claudio@
|
|
fails -- which should never happen -- the function does not return and is
accession the NULL set control pointer later on.
Found by Matthew Haub. OK deraadt@
|
|
"For sure!" claudio@
|
|
New Intra-Area-Prefix LSAs are originated when a neighbour
becomes adjacent, or when a neighbour loses adjacency,
or when an interface changes state.
ok claudio@
|
|
We now comply with RFC5340 and move prefixes between the two
ref-types of Intra-Area-Prefix LSAs (router and network).
In case an LSA ends up having all of its prefixes moved to another
one, the LSA is flushed from the LSDB by re-originating with MAX_AGE.
(This does not yet work reliably. We end up having LSAs with zero
prefixes in the LSDB in some cases. Should not affect SPF calculation,
so not much harm done, but will need to be fixed.)
This commit just adds the necessary code to do origination,
but it is not being called yet. This will be done in a separate
commit.
"Looks good." claudio@
|
|
Will soon be done in rde instead.
"Sure but don't wait too long before readding the code in rde" claudio@
|
|
Also syncs other fields the ospfe is syncing to when getting
iface updates from parent process.
None of these fields are used by the rde yet, but state will be
important soon, for proper origination of Intra-Area-Prefix LSAs.
ok claudio@
|
|
about nbr state change.
Intra-Area-Prefix LSAs refer to these LSAs. While not strictly necessary,
it makes sense for these LSAs to be up-to-date in the LSDB before new
Intra-Area-Prefix LSAs are originated.
This change has no effect yet because Intra-Area-Prefix LSAs are
currently originated during updates of LSA types it depends on,
but origination will soon be synced to state changes in the iface
and nbr state machines instead.
ok claudio@
|
|
ospfe was sending state from a local variable which does not
always reflect the true state of the neighbour. The RDE would
end up with an invalid nbr state of zero in some situations.
Send state saved in nbr structure instead, this is always valid.
ok claudio@
|
|
Save a pointer to the right LSA tree in new member v->lsa_tree.
This saves us the hassle of finding the right tree in vertex_free(),
we already know it at creation time so why not tuck it in there?
This might cause problems if the ospfe side ever decides to call
area_del() with a non-empty area->lsa_tree, without correctly
initialising v->lsa_tree. But grep shows that the area's lsa_tree
is currently just initialized on the ospfe side, but never modified.
ospf6d daemons which crashed after about 1 min with malloc options
FGJ are now happy.
ok claudio@
|
|
printing IFINFO while we are actually handling an IFDELETE imsg.
|
|
length, regardless of interface type.
Allowed by RFC5340 and ok claudio@
|
|
global-scope prefixes in iface->ifa_list.
ok claudio@
|
|
|
|
jmc@ has provided a complete list of manual pages to be fixed,
and suggested using uppercase (i.e., Point-to-Point) when discussing
the protocol, and lowercase (point-to-point) otherwise.
ok jmc@
|
|
LSAs which refer to Router LSAs.
ok claudio@
|
|
Routers can now advertise prefixes with global scope throughout
an area. This paves the way towards doing SPF calculations to
generate routing tables for a single area.
ok claudio@
|
|
But in Intra-Area-Prefix LSAs, #prefixes is a 16bit value.
lsa_intra_a_pref_check() was failing on little-endian machines because
it was trying to byte-swap a 32bit value.
ok claudio@
|
|
number of bytes left in the buffer. OK stsp@
|
|
LSAs to zero. We were using the interface index, which is not quite right
for this type of LSA.
This is part of a greater scheme:
Intra-Area-Prefix LSAs referencing Router LSAs (not yet implemented)
will initially have their Link State ID hard-coded to one.
Then, as soon as we implement fragmentation of Intra-Area-Prefix LSAs,
Link State IDs for both types of Intra-Area-Prefix LSA will have to be
generated dynamically in a non-overlapping fashion.
discussed with claudio@
|
|
Print not just the area, but also the interface to the link the LSA
is generated for.
ok claudio@
|
|
of IPv6 prefixes with a Network LSA (there's another type of this LSA which
associates prefixes with a Router LSA -- this remains to be done).
Add what is necessary to allow ospf6ctl to read the new LSA type via IMSG.
ok claudio@
|
|
to the RDE.
ok claudio@
|
|
ok stsp@
|
|
|
|
if present, and that a router ID must be manually configured on
IPv6-only routers.
|
|
regardless of link type. So don't ever use source addresses from the IP
header to match known neighbours when receiving hello packets.
ok claudio@
|
