The external_id_table was only ever used to store pointers to data
and was never used for lookup during the course of normal operations.
However it did lead to crashes because somewhere along the way
external routes stored in the external_table never had their
id associated into the external_id_table and we would assert
on the node lookup failing.
Since this code was never used for anything other than
storing data and it was never retrieved for anything useful
let's just remove it from ospf6d.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
It allows FRR to read the interface config even when the necessary VRFs
are not yet created and interfaces are in "wrong" VRFs. Currently, such
config is rejected.
For VRF-lite backend, we don't care at all about the VRF of the inactive
interface. When the interface is created in the OS and becomes active,
we always use its actual VRF instead of the configured one. So there's
no need to reject the config.
For netns backend, we may have multiple interfaces with the same name in
different VRFs. So we care about the VRF of inactive interfaces. And we
must allow to preconfigure the interface in a VRF even before it is
moved to the corresponding netns. From now on, we allow to create
multiple configs for the same interface name in different VRFs and
the necessary config is applied once the OS interface is moved to the
corresponding netns.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
FRR should only ever use the appropriate THREAD_ON/THREAD_OFF
semantics. This is espacially true for the functions we
end up calling the thread for.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
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>
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>
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>
There is a possibility that the same line can be matched as a command in
some node and its parent node. In this case, when reading the config,
this line is always executed as a command of the child node.
For example, with the following config:
```
router ospf
network 193.168.0.0/16 area 0
!
mpls ldp
discovery hello interval 111
!
```
Line `mpls ldp` is processed as command `mpls ldp-sync` inside the
`router ospf` node. This leads to a complete loss of `mpls ldp` node
configuration.
To eliminate this issue and all possible similar issues, let's print an
explicit "exit" at the end of every node config.
This commit also changes indentation for a couple of existing exit
commands so that all existing commands are on the same level as their
corresponding node-entering commands.
Fixes#9206.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Description:
1. changes to process GRACE LSA packet.
2. Validation changes to enter Helper role.
3. Helper functionality during graceful restart.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Feature Implementation.
========================
This feature will help in advertising the External LSAs with aggregation.
The commands allow us to tune the advertisement with different parameters
as mentioned in the CLI List below.
It can also help in case we do not want to advertise any prefix with the
no-advertise option.
New CLIs added:
===============
summary-address X:X::X:X/M$prefix [tag (1-4294967295)] [{metric (0-16777215) | metric-type (1-2)}]
no summary-address X:X::X:X/M$prefix [tag (1-4294967295)] [{metric (0-16777215) | metric-type (1-2)}]
summary-address X:X::X:X/M$prefix no-advertise
no summary-address X:X::X:X/M$prefix no-advertise
aggregation timer (5-1800)
no aggregation timer (5-1800)
show ipv6 ospf6 summary-address [detail$detail] [json]
debug ospf6 lsa aggregation
CAT RUN:
========
QE to add test scripts
Signed-Off-by: Mobashshera Rasool <mrassol@vmware.com>
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>
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>
Adding the "clear ipv6 ospf6 command" . It resets
the ospfv3 datastructures and clears the database
as well as route tables. It resets the neighborship
by restarting the interface state machine.
If the user wants to change the router-id, this
command updates the router-id to the latest static
router-id and starts the neighbor formation with
the new router-id.
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
If we have the following configuration:
```
vrf red
smth
exit-vrf
!
interface red vrf red
smth
```
And we delete the VRF using "no vrf red" command, we end up with:
```
interface red
smth
```
Interface config is preserved but moved to the default VRF.
This is not an expected behavior. We should remove the interface config
when the VRF is deleted.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
allow amount of work done by read and write threads in a single
invocation to be tuned to between 1 and 100 packets (default 20)
Signed-off-by: Pat Ruddy <pat@voltanet.io>
Add per interface fifo and per instance write list as a precursor
to implementing fairer sharing of the ospf6 oscket resources.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
The ospf6_is_router_abr is checking to see if ospfv3 is an abr router
and also setting values. Let's rename it too `ospf6_check_and_set_router_abr`
to more accurately reflect what it is doing.
Additionally fix coverity #1505176 where we were not checking the return
value of ospf6_is_router_abr like we did every other time. In this
case we don't care about the return value so indicate that we do not.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There exists a code path where ospf6 could be NULL and passing
to a function where it would always be derefed is a bad idea.
Put some small code in place to prevent this and allow this to be debuged
if it happens in the future.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently the interface area is configured from the router node using
"interface IFNAME area ID" command. There are multiple problems with
this command:
- it is not in line with all other interface-related commands - other
parameters are configured from the interface node using "ipv6 ospf6"
prefix
- it is not in line with OSPFv2 - area is configured from the interface
node using "ip ospf area" command
- most importantly, it doesn't work correctly when the interface is in
a different VRF - instead of configuring the interface, it creates a
new fake interface and configuring it instead
To fix all the problems, this commit adds a new command to the interface
configuration node - "ipv6 ospf6 area ID". The purpose of the command is
completely the same, but it works correctly in a multi-VRF environment.
The old command is preserved for the backward compatibility, but the
warning is added that it is deprecated because it doesn't work correctly
with VRFs.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The following is implemented.
1. Configuring area as NSSA.
2. Generating Type 7 LSA.
3. Conversion of Type 7 to Type 5 ( Default Behavior).
4. NSSA ABR selection.
Reviewed-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Co-authored-by: Kaushik <kaushiknath.null@gmail.com>
Co-authored-by: Soman K.S <somanks@gmail.com>
Signed-off-by: Kaushik <kaushiknath.null@gmail.com>
If the default route redistribution is configured in OSPF6 router before
the VRF is created, then this is not currently registered in zebra after
the VRF creation.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The code had no limits on addresses configured on an interface running
ospf6d. The code would crash when more than 100 addresses were added.
This change limits the number of interface address to 100 if mtu is set
to the default value. If the mtu is set to a jumbo packet size or larger
we will support 200 interface addresses.
Signed-off-by: Lynne Morrison <lynne@voltanet.io>
Issue: When maximum-path is configured in ospf6 view, the
function ospf6_restart_spf deletes the external table as well
which is not required since that stores the redistribute routes.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
When oi->area == NULL, it tries to print the
interface's area name, but no area is present.
Print the area name from the command argument instead.
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
this command summarises the ospf6 instances along with the router-id and
the vrf_id associated.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
