The ospf6 router-id is provided by order of preference by:
ospf6d itself if the "ospf6 router-id X.X.X.X" command is set.
- zebra. If the "ip router-id X.X.X.X" zebra command is set, the
configured IP is provided as the ID or alternatively the highest
loopback IPv4 address or else the highest interface IPv4 address.
The running ospf6 router-id is stored in ospf6->router-id.
ospf6->router-id can change in the following conditions:
- A configuration change provides a new router-id value according to
the above rules. ospf6->router-id is updated to the new value if
there is no adjacency in FULL state. Otherwise, the ospf6d process
must be restarted to take the new router-id into account.
- On startup of both zebra and ospf6d, if ospf6d has not yet received a
valid router-id, ospf6d->router-id is set to 0 (i.e. 0.0.0.0). Then,
zebra notifies ospf6d that the router-id is available.
At ospf6->router-id, the current behavior of ospf6d is the following:
- The self generated LSAs that refer to the previous router-id as the
advertising router are kept.
- Self generated LSAs are created with router-id value.
- LSAs from the redistribution that refer to the previous router-id are
kept and no new redistribution LSAs are created.
As a consequence, the routers in the ospf6 areas will get incorrect
LSAs and might not be able to install prefixes of those LSAs into their
RIB.
This fix solves this issue by resetting the areas and the redistribution
when ospf6->router-id updated.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add the "default-information-originate" option to the "area X nssa"
command. That option allows the origination of Type-7 default routes
on NSSA ABRs and ASBRs.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The route created by the "default-information-originate" command
isn't a regular external route. As such, an NSSA ABR shouldn't
originate a corresponding Type-7 LSA for it (there's a separate
configuration knob to generate Type-7 default routes).
While here, fix a small issue in ospf6_asbr_redistribute_add()
where routes created by "default-information-originate" were being
displayed with an incorrect "unknown" type.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When set to its default value, the metric type associated to a
"redistribute" statement shouldn't be displayed as part of the
running configuration.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Fix wrong comparison since route->path.metric_type is always set
to either 1 or 2. The OSPF6_PATH_TYPE_EXTERNAL2 constant, whose
value is 4, refers to a route type so its usage was incorrect here.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
ospf6_router_id_update function is used by ospf6_router_id_update_zebra
to update the running the ospf6 router-id.
This patches makes the functions to (un)configure ospf6 router-id use
the same function as ospf6_router_id_update_zebra.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When a router-id change is notified by zebra to ospf6d, we only take
into account the change if no adjacencies are in Full state.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Considering that both the GR helper mode and restarting mode can be
enabled at the same time, the "graceful-restart helper-only" command
can be a bit misleading since it implies that only the helper mode
is enabled. Rename the command to "graceful-restart helper enable"
to clarify what the command does.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When looking up the o_path->ls_prefix if it is not found
the debug statement was using a buf that was never initialized.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The ospfv3 spf reason strings are just presented internally in the code
without any real context. Give a tiny bit more useful information for
the developer and convert the integer to a uint32_t
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Issue #9535 describes how the export-list/import-list commands work
differently on ospfd and ospf6d.
In short:
* On ospfd, "area A.B.C.D export-list" filters which internal
routes an ABR exports to other areas. On ospf6d, instead, that
command filters which inter-area routes an ABR exports to the
configured area (which is quite counter-intuitive). In other words,
both commands do the same but in opposite directions.
* On ospfd, "area A.B.C.D import-list" filters which inter-area
routes an ABR imports into the configured area. On ospf6d, that
command filters which inter-area routes an interior router accepts.
* On both daemons, "area A.B.C.D filter-list prefix NAME <in|out>"
works exactly the same as import/export lists, but using prefix-lists
instead of ACLs.
The inconsistency on how those commands work is undesirable. This
PR proposes to adapt the ospf6d commands to behave like they do
in ospfd.
These changes are obviously backward incompatible and this PR doesn't
propose any mitigation strategy other than warning users about the
changes in the next release notes. Since these ospf6d commands are
undocumented and work in such a peculiar way, it's unlikely many
users will be affected (if any at all).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Some CI VMs are using really old versions of json-c (pre 2013 [1])
that expect filenames to be passed as "char *" instead of "const char *".
Add some explicit casts to fix the resulting compiler errors on those
VMs (passing "char *" when the API expects "const char *" is fine).
Hopefully this commit should be reverted once the CI is updated to use
newer versions of json-c.
[1] https://github.com/json-c/json-c/commit/20e4708c
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
RFC 5187 specifies the Graceful Restart enhancement to the OSPFv3
routing protocol. This commit implements support for the GR
restarting mode.
Here's a quick summary of how the GR restarting mode works:
* GR can be enabled on a per-instance basis using the `graceful-restart
[grace-period (1-1800)]` command;
* To perform a graceful shutdown, the `graceful-restart prepare ipv6
ospf` EXEC-level command needs to be issued before restarting the
ospf6d daemon (there's no specific requirement on how the daemon
should be restarted);
* `graceful-restart prepare ospf` will initiate the graceful restart
for all GR-enabled instances by taking the following actions:
o Flooding Grace-LSAs over all interfaces
o Freezing the OSPF routes in the RIB
o Saving the end of the grace period in non-volatile memory (a JSON
file stored in `$frr_statedir`)
* Once ospf6d is started again, it will follow the procedures
described in RFC 3623 until it detects it's time to exit the graceful
restart (either successfully or unsuccessfully).
Testing done:
* New topotest featuring a multi-area OSPF topology (including stub
and NSSA areas);
* Successful interop tests against IOS-XR routers acting as helpers.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Add a knob to turn a NSSA area into a totally stub area. In this
configuration a Type-3 default summary route is generated by default.
Syntax: `area A.B.C.D nssa no-summary`.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
With this sequence of events:
eva# conf
eva(config)# router ospf6
eva(config-ospf6)# end
eva# show ipv6 ospf data adv-router 0.0.0.0 linkstate-id 0.0.0.0
OSPF6: Received signal 11 at 1630442431 (si_addr 0x0, PC 0x559dcfa3a656); aborting...
OSPF6: zlog_signal+0x18c 7fd2cc8229f7 7fff606775d0 /lib/libfrr.so.0 (mapped at 0x7fd2cc770000)
OSPF6: core_handler+0xe3 7fd2cc8616ad 7fff606776f0 /lib/libfrr.so.0 (mapped at 0x7fd2cc770000)
OSPF6: funlockfile+0x50 7fd2cc74f140 7fff60677840 /lib/x86_64-linux-gnu/libpthread.so.0 (mapped at 0x7fd2cc73b000)
OSPF6: ---- signal ----
OSPF6: ospf6_lsdb_type_show_wrapper+0x5d 559dcfa3a656 7fff60677dd0 /usr/lib/frr/ospf6d (mapped at 0x559dcf9a5000)
OSPF6: show_ipv6_ospf6_database_adv_router_linkstate_id+0x1f9 559dcfa3c24a 7fff60677e50 /usr/lib/frr/ospf6d (mapped at 0x559dcf9a5000)
OSPF6 crashes. Fix.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The message about ignoring a one-way hello should only be logged
when the router is acting a helper for another one.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Add the "metric" and "metric-type" options to the "redistribute"
command.
This is a small commit since the logic of setting the metric
value and type of external routes was already present due to the
implementation of the "default-information originate" command months
ago. This commit merely extends the "redistribute" command to
leverage that functionality.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The prefix of routes to border routers consists of two pieces of
information embedded in a single struct (prefix.u.lp):
struct prefix {
uint8_t family;
uint16_t prefixlen;
union {
[snip]
struct {
struct in_addr id;
struct in_addr adv_router;
} lp;
} u __attribute__((aligned(8)));
};
As such, using prefix2str() (or the %pFX format specifier) isn't
correct when logging such routes.
This commit adds a few special cases here and there to handle
OSPF6_DEST_TYPE_ROUTER routes differently. It'd probably be a good
idea to add a helper function to handle all cases in a single place,
but that can be left for a second moment.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Also, update the ospf6_topo2 topotest since the expected output
was wrong. With this fix, NSSA routes will be created on r2
("redistribute connected"), and NSSA routes appear in the routing
table as regular external routes.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Once NSSA is unconfigured on an area, all self-originated Type-7
LSAs need to be flushed. The existing code was iterating over the
LSDB in the wrong way, causing ospf6_nssa_flush_area() to flush
LSAs of all types. Use the ALL_LSDB_TYPED_ADVRTR macro to perform
the intended iteration correctly.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Once NSSA is unconfigured, the OSPF area should still be operational
as a normal area instead of being deleted.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
RFC 3101 - Section 2.1 says:
"(..) Interfaces associated with an NSSA will not send or receive
Type-5 LSAs on that interface but may send and receive Type-7 LSAs.
Therefore, if the N-bit is set in the options field, the E-bit must
be clear."
If the E-bit isn't cleared on an NSSA ABR, that will cause hello
packets to be dropped (due to parameters mismatch), which will
prevent the ABR from forming adjacencies with others routers in
the NSSA area.
This problem didn't affect the existing NSSA topotest by chance
of luck. In that topotest, in the NSSA ABR, the NSSA area is
configured before any interface is associated to it. That caused
ospf6_check_and_set_router_abr() to return false, leading to
the unsetting of the E-bit. With this fix, the order in which
areas/interfaces are configured shouldn't matter because the E-bit
will always be unset on NSSA areas.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
