Problem Statement:
=================
The feature is not enabled, needs to be enabled by doing required
initialization.
RCA:
====
Changes to support the feature is present, but the feature macro
needs to be enabled.
Fix:
====
This commit has changes to enable the code.
Risk:
=====
Medium
Need to ensure all existing ospf6 related topotests pass. to ensure
packet processing is not impacted.
Tests Executed:
===============
Have tested the functionality with enabling openssl and also disabling
openssl.
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Problem Statement:
==================
RFC 7166 support for OSPF6 in FRR code.
RCA:
====
This feature is newly supported in FRR
Fix:
====
Core functionality implemented in previous commit is
stitched with rest of ospf6 code as part of this commit.
Risk:
=====
Low risk
Tests Executed:
===============
Have executed the combination of commands.
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Problem Statement:
==================
Implement RFC 7166 support for OSPF6 in FRR code.
RCA:
====
This feature is newly supported in FRR.
Fix:
====
Changes are done to implement ospf6 ingress and egress
packet processing.
This commit has the core functionality.
It supports below debugability commands:
---------------------------------------
debug ospf6 authentication [<tx|rx>]
It supports below clear command:
--------------------------------
clear ipv6 ospf6 auth-counters interface [IFNAME]
It supports below show commands:
--------------------------------
frr# show ipv6 ospf6 interface ens192
ens192 is up, type BROADCAST
Interface ID: 5
Number of I/F scoped LSAs is 2
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication trailer is enabled with manual key ==> new info added
Packet drop Tx 0, Packet drop Rx 0 ==> drop counters
frr# show ipv6 ospf6 neighbor 2.2.2.2 detail
Neighbor 2.2.2.2%ens192
Area 1 via interface ens192 (ifindex 3)
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header present ==> new info added
hello DBDesc LSReq LSUpd LSAck
Higher sequence no 0x0 0x0 0x0 0x0 0x0
Lower sequence no 0x242E 0x1DC4 0x1DC3 0x23CC 0x1DDA
frr# show ipv6 ospf6
OSPFv3 Routing Process (0) with Router-ID 2.2.2.2
Number of areas in this router is 1
Authentication Sequence number info ==> new info added
Higher sequence no 3, Lower sequence no 1656
Risk:
=====
Low risk
Tests Executed:
===============
Have executed the combination of commands.
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Problem Statement:
==================
RFC 7166 support for OSPF6 in FRR code.
RCA:
====
This feature is newly supported in FRR
Fix:
====
Changes are done to add support for two new CLIs to configure
ospf6 authentication trailer feature.
One CLI is to support manual key configuration.
Other CLI is to configure key using keychain.
below CLIs are implemented as part of this commit. this configuration
is applied on interface level.
Without openssl:
ipv6 ospf6 authentication key-id (1-65535) hash-algo <md5|hmac-sha-256> key WORD
With openssl:
ipv6 ospf6 authentication key-id (1-65535) hash-algo <md5|hmac-sha-256|hmac-sha-1|hmac-sha-384|hmac-sha-512> key WORD
With keychain support:
ipv6 ospf6 authentication keychain KEYCHAIN_NAME
Running config for these command:
frr# show running-config
Building configuration...
Current configuration:
!
interface ens192
ipv6 address 2001:DB8:1::2/64
ipv6 ospf6 authentication key-id 10 hash-algo hmac-sha-256 key abhinay
!
interface ens224
ipv6 address 2001:DB8:2::2/64
ipv6 ospf6 authentication keychain abhinay
!
Risk:
=====
Low risk
Tests Executed:
===============
Have executed the combination of commands.
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Problem Statement:
==================
As of now there is no support for ospf6 authentication.
To support ospf6 authentication need to have keychain support for
managing the auth key.
RCA:
====
New support
Fix:
====
Enabling keychain for ospf6 authentication feature.
Risk:
=====
Low risk
Tests Executed:
===============
Have verified the support for ospf6 auth trailer feature.
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
if r1 has a route received from a neighbor and the same route
configured as static, the administrative distance will determine
which route to use
r1(config)# ipv6 route 1:1::1/128 Null0 70
r1# sh ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
S>* 1:1::1/128 [70/0] unreachable (blackhole), weight 1, 00:00:12
O 1:1::1/128 [110/20] via fe80::1833:c9ff:fe7b:3e43, r1-r2-eth0, weight 1, 00:00:49
The static route is selected. If we now change the administrative distance
in ospf6, the OSPF route should be selected
r1(config)# router ospf6
r1(config-ospf6)# distance 50
r1# sh ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
S>* 1:1::1/128 [70/0] unreachable (blackhole), weight 1, 00:00:39
O 1:1::1/128 [110/20] via fe80::1833:c9ff:fe7b:3e43, r1-r2-eth0, weight 1, 00:01:16
However the distance is not applied as there are no changes in the routing table
This commit will force the update of the routing table with the new configured distance
r1# sh ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
O>* 1:1::1/128 [50/20] via fe80::8cb7:e6ff:fef5:2344, r1-r2-eth0, weight 1, 00:00:03
S 1:1::1/128 [70/0] unreachable (blackhole), weight 1, 00:00:19
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
This PR will include if the area is NSSA in the output of "show ipv6 ospf"
r2# show ipv6 ospf
...
Area 0.0.0.0
Number of Area scoped LSAs is 8
Interface attached to this area: r2-eth1
SPF last executed 20.46717s ago
Area 0.0.0.1[Stub]
Number of Area scoped LSAs is 9
Interface attached to this area: r2-eth0
SPF last executed 20.46911s ago
Area 0.0.0.2[NSSA]
Number of Area scoped LSAs is 14
Interface attached to this area: r2-eth2
SPF last executed 20.46801s ago
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
Opaque data takes up a lot of memory when there are a lot of routes on
the box. Given that this is just a cosmetic info, I propose to disable
it by default to not shock people who start using FRR for the first time
or upgrades from an old version.
Fixes#10101.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
VRF name should not be printed in the config since 574445ec. The update
was done for NB config output but I missed it for regular vty output.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Fixes#9720. When updating an ECMP inter-area route, we compute
a new route and check whether that already exists. If so, we keep the old
route and only update its nexthops. Previously, we merged the new route's
nexthops into the old one's, but this way, it's impossible to remove
nexthops from the old route, resulting in stale nexthops.
This commit fixes this by first removing all nexthops from the old route and
then copying all nexthops from the new route into it. If the new route has
fewer nexthops, the old one will have as well afterwards.
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
Update ospfd and ospf6d to send opaque route attributes to
zebra. Those attributes are stored in the RIB and can be viewed
using the "show ip[v6] route" commands (other than that, they are
completely ignored by zebra).
Example:
```
debian# show ip route 192.168.1.0/24
Routing entry for 192.168.1.0/24
Known via "ospf", distance 110, metric 20, best
Last update 01:57:08 ago
* 10.0.1.2, via eth-rt2, weight 1
OSPF path type : External-2
OSPF tag : 0
debian#
debian# show ip route 192.168.1.0/24 json
{
"192.168.1.0\/24":[
{
"prefix":"192.168.1.0\/24",
"prefixLen":24,
"protocol":"ospf",
"vrfId":0,
"vrfName":"default",
"selected":true,
[snip]
"ospfPathType":"External-2",
"ospfTag":"0"
}
]
}
```
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Currently the ospf6d's commands with non-exist vrfs can't give the error
informations to users.
This commit adds a macro "OSPF6_CMD_CHECK_VRF" to give error information
if with non-exist vrfs. As usual, skip the checking process in the case
of json.
So one command can call this macro to do the checking process in its
end. At that time it need know json style or not, so add "json" parameter for
several related functions.
BTW, suppress the build warning of the macro `OSPF6_FIND_VRF_ARGS`:
"Macros starting with if should be enclosed by a do - while loop to avoid
possible if/else logic defects."
Signed-off-by: anlan_cs <anlan_cs@tom.com>
Comparison of the two pointer is confusing, they have no relevance
except the time both of them are empty.
Additionly modify one variable name and correct some comment words, they
are same in both ospfd and ospf6d.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
The OSPF6_LSA_UNAPPROVED flag is set in the function above
ospf6_lsa_translated_nssa_new, so there is no need to set
the flag again
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
When running topotest ospf6_topo2 we can see a log message with wrong lsa id
2021/12/20 23:14:40.330 OSPF6: [V8P0C-HB5Z2] ASBR[default:Status:3]: Update
2021/12/20 23:14:40.330 OSPF6: [Z489N-JAJ6P] ASBR[default:Status:3]: Already ASBR
2021/12/20 23:14:40.330 OSPF6: [Z9D0B-12SBJ] Redistribute 2001:db8:2::/64 (connected)
2021/12/20 23:14:40.330 OSPF6: [N66XP-ANN4G] Advertise as AS-External Id:8.70.41.177 prefix 2001:db8:2::/64 metric 2 (**)
2021/12/20 23:14:40.330 OSPF6: [K4Y9R-C22T6] Advertise new AS-External Id:0.0.0.3 prefix 2001:db8:2::/64 metric 2
2021/12/20 23:14:40.330 OSPF6: [PKX0N-KNRQR] Originate AS-External-LSA for 2001:db8:2::/64
This PR removes the log (instead of fixing it) as same information is printed
in the following entry
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
Since ospf6Enabled and attachedToArea are denoting the same thing.
It is decided to remove ospf6Enabled from json output to make
CLI and json output similar.
Fixes: #9286
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
With the current code, in a topology like this:
r1 ---- 0.0.0.0 ---- r2(ABR) ---- 1.1.1.1 -----r3(ASBR)
NSSA
where r3 is redistributing statics within the NSSA area, the ABR (r2)
is translating type-7 lsa to type-5.
Everytime the function ospf6_abr_nssa_task() is executed all translated
type-5 are aged out and refreshed for no reason. So for instance having 3
lsas already advertised:
r1# sh ipv6 os database
AS Scoped Link State Database
Type LSId AdvRouter Age SeqNum Payload
ASE 0.0.0.1 2.2.2.2 39 80000001 3:3::3/128
ASE 0.0.0.2 2.2.2.2 39 80000001 4:4::4/128
ASE 0.0.0.3 2.2.2.2 39 80000001 5:5::5/128
Adversting a new route from r3:
r3(config)# ipv6 route 6:6::6/128 Null0
r1# sh ipv6 os database
AS Scoped Link State Database
Type LSId AdvRouter Age SeqNum Payload
ASE 0.0.0.1 2.2.2.2 124 80000001 3:3::3/128
ASE 0.0.0.2 2.2.2.2 124 80000001 4:4::4/128
ASE 0.0.0.3 2.2.2.2 124 80000001 5:5::5/128
ASE 0.0.0.4 2.2.2.2 8 80000001 6:6::6/128
That seems okay, however a few seconds later we see all prefixes refreshed
r1# sh ipv6 os database
AS Scoped Link State Database
Type LSId AdvRouter Age SeqNum Payload
ASE 0.0.0.1 2.2.2.2 3600 80000001 3:3::3/128
ASE 0.0.0.2 2.2.2.2 3600 80000001 4:4::4/128
ASE 0.0.0.3 2.2.2.2 3600 80000001 5:5::5/128
ASE 0.0.0.4 2.2.2.2 3600 80000001 6:6::6/128
ASE 0.0.0.5 2.2.2.2 3 80000001 3:3::3/128
ASE 0.0.0.6 2.2.2.2 3 80000001 4:4::4/128
ASE 0.0.0.7 2.2.2.2 3 80000001 5:5::5/128
ASE 0.0.0.8 2.2.2.2 3 80000001 6:6::6/128
This PR prevents the LSA of being refreshed by unsetting the OSPF6_LSA_UNAPPROVED
flag so advertising the last prefix will not refresh all of them:
r1# sh ipv6 os database
AS Scoped Link State Database
Type LSId AdvRouter Age SeqNum Payload
ASE 0.0.0.1 2.2.2.2 90 80000001 3:3::3/128
ASE 0.0.0.2 2.2.2.2 47 80000001 4:4::4/128
ASE 0.0.0.3 2.2.2.2 35 80000001 5:5::5/128
ASE 0.0.0.4 2.2.2.2 7 80000001 6:6::6/128
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
Currently, it is possible to rename the default VRF either by passing
`-o` option to zebra or by creating a file in `/var/run/netns` and
binding it to `/proc/self/ns/net`.
In both cases, only zebra knows about the rename and other daemons learn
about it only after they connect to zebra. This is a problem, because
daemons may read their config before they connect to zebra. To handle
this rename after the config is read, we have some special code in every
single daemon, which is not very bad but not desirable in my opinion.
But things are getting worse when we need to handle this in northbound
layer as we have to manually rewrite the config nodes. This approach is
already hacky, but still works as every daemon handles its own NB
structures. But it is completely incompatible with the central
management daemon architecture we are aiming for, as mgmtd doesn't even
have a connection with zebra to learn from it. And it shouldn't have it,
because operational state changes should never affect configuration.
To solve the problem and simplify the code, I propose to expand the `-o`
option to all daemons. By using the startup option, we let daemons know
about the rename before they read their configs so we don't need any
special code to deal with it. There's an easy way to pass the option to
all daemons by using `frr_global_options` variable.
Unfortunately, the second way of renaming by creating a file in
`/var/run/netns` is incompatible with the new mgmtd architecture.
Theoretically, we could force daemons to read their configs only after
they connect to zebra, but it means adding even more code to handle a
very specific use-case. And anyway this won't work for mgmtd as it
doesn't have a connection with zebra. So I had to remove this option.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
RFC 3101 states both E-bit and N-bit need to be checked when receiving a Hello packet.
"To support the NSSA option an additional check must be made in the function
that handles the receiving of the Hello packet to verify that both the N-bit
and the E-bit found in the Hello packet's option field match the area type and
ExternalRoutingCapability of the area of the receiving interface."
This PR adds the check for the N-bit
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
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>
Since f60a1188 we store a pointer to the VRF in the interface structure.
There's no need anymore to store a separate vrf_id field.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
In a topology like:
r1(ASBR) ---- 0.0.0.0 ---- r2(ABR) ---- 1.1.1.1 -----r3
where r1 is redistributing statics and area 1.1.1.1 is NSSA, the ABR r2 should
not originate type-4 LSA into the NSSA area. From RFC 3101: "NSSA border routers
should not originate Type-4 summary-LSAs into their NSSAs."
This PR prevents the above LSA of being originated by the ABR r2
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
In a topology like:
r1 ---- 0.0.0.0 ---- r2(ABR) ---- 1.1.1.1 -----r3(ASBR)
where r3 is redistributing statics and area 1.1.1.1 is NSSA, the ABR r2 should
not originate type-4 LSA, according to RFC 3101, section 1.3:
"also an NSSA's border routers never originate Type-4 summary-LSAs for the
NSSA's AS boundary routers, since Type-7 AS-external-LSAs are never flooded
beyond the NSSA's border"
r1# sh ipv6 os database inter-router
Area Scoped Link State Database (Area 0.0.0.0)
Type LSId AdvRouter Age SeqNum Payload
IAR 3.3.3.3 2.2.2.2 49 80000001 3.3.3.3
This PR prevents the above LSA of being originated by the ABR r2
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
We should always treat the VRF interface as a loopback. Currently, this
is not the case, because in some old pre-VRF code we use if_is_loopback
instead of if_is_loopback_or_vrf. To avoid any future problems, the
proposal is to rename if_is_loopback_or_vrf to if_is_loopback and use it
everywhere. if_is_loopback is renamed to if_is_loopback_exact in case
it's ever needed, but currently it's not used anywhere.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Using memcmp with complex structures like prefix or ospf6_ls_origin is
not correct, because even two structures with same values in all fields
may have different values in padding bytes and comparison will fail.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
As part of the check, it memcompares two structs ospf6_path. This struct
has a pointer field nh_list which is allocated every time a new path is
created, which means it can never be the same for two different paths.
Therefore this check is always false and can be completely removed.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The adj_ok thread event is being added but not killed
when the underlying interface is deleted. I am seeing
this crash:
OSPF6: Received signal 11 at 1636142186 (si_addr 0x0, PC 0x561d7fc42285); aborting...
OSPF6: zlog_signal+0x18c 7f227e93519a 7ffdae024590 /lib/libfrr.so.0 (mapped at 0x7f227e884000)
OSPF6: core_handler+0xe3 7f227e97305e 7ffdae0246b0 /lib/libfrr.so.0 (mapped at 0x7f227e884000)
OSPF6: funlockfile+0x50 7f227e863140 7ffdae024800 /lib/x86_64-linux-gnu/libpthread.so.0 (mapped at 0x7f227e84f000)
OSPF6: ---- signal ----
OSPF6: need_adjacency+0x10 561d7fc42285 7ffdae024db0 /usr/lib/frr/ospf6d (mapped at 0x561d7fbc6000)
OSPF6: adj_ok+0x180 561d7fc42f0b 7ffdae024dc0 /usr/lib/frr/ospf6d (mapped at 0x561d7fbc6000)
OSPF6: thread_call+0xc2 7f227e989e32 7ffdae024e00 /lib/libfrr.so.0 (mapped at 0x7f227e884000)
OSPF6: frr_run+0x217 7f227e92a7f3 7ffdae024ec0 /lib/libfrr.so.0 (mapped at 0x7f227e884000)
OSPF6: main+0xf3 561d7fc0f573 7ffdae024fd0 /usr/lib/frr/ospf6d (mapped at 0x561d7fbc6000)
OSPF6: __libc_start_main+0xea 7f227e6b0d0a 7ffdae025010 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x7f227e68a000)
OSPF6: _start+0x2a 561d7fc0f06a 7ffdae0250e0 /usr/lib/frr/ospf6d (mapped at 0x561d7fbc6000)
OSPF6: in thread adj_ok scheduled from ospf6d/ospf6_interface.c:678 dr_election()
The crash is in the on->ospf6_if pointer is NULL. The only way this could
happen from what I can tell is that the event is added to the system
and then we immediately delete the interface, removing the memory
but not freeing up the adj_ok thread event.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
I am seeing a crash of ospf6d with this stack trace:
OSPF6: Received signal 11 at 1636042827 (si_addr 0x0, PC 0x55efc2d09ec2); aborting...
OSPF6: zlog_signal+0x18c 7fe20c8ca19a 7ffd08035590 /lib/libfrr.so.0 (mapped at 0x7fe20c819000)
OSPF6: core_handler+0xe3 7fe20c90805e 7ffd080356b0 /lib/libfrr.so.0 (mapped at 0x7fe20c819000)
OSPF6: funlockfile+0x50 7fe20c7f8140 7ffd08035800 /lib/x86_64-linux-gnu/libpthread.so.0 (mapped at 0x7fe20c7e4000)
OSPF6: ---- signal ----
OSPF6: ospf6_neighbor_state_change+0xdc 55efc2d09ec2 7ffd08035d90 /usr/lib/frr/ospf6d (mapped at 0x55efc2c8e000)
OSPF6: exchange_done+0x15c 55efc2d0ab4a 7ffd08035dc0 /usr/lib/frr/ospf6d (mapped at 0x55efc2c8e000)
OSPF6: thread_call+0xc2 7fe20c91ee32 7ffd08035df0 /lib/libfrr.so.0 (mapped at 0x7fe20c819000)
OSPF6: frr_run+0x217 7fe20c8bf7f3 7ffd08035eb0 /lib/libfrr.so.0 (mapped at 0x7fe20c819000)
OSPF6: main+0xf3 55efc2cd7573 7ffd08035fc0 /usr/lib/frr/ospf6d (mapped at 0x55efc2c8e000)
OSPF6: __libc_start_main+0xea 7fe20c645d0a 7ffd08036000 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x7fe20c61f000)
OSPF6: _start+0x2a 55efc2cd706a 7ffd080360d0 /usr/lib/frr/ospf6d (mapped at 0x55efc2c8e000)
OSPF6: in thread exchange_done scheduled from ospf6d/ospf6_message.c:2264 ospf6_dbdesc_send_newone()
The stack trace when decoded is:
(gdb) l *(ospf6_neighbor_state_change+0xdc)
0x7bec2 is in ospf6_neighbor_state_change (ospf6d/ospf6_neighbor.c:200).
warning: Source file is more recent than executable.
195 on->name, ospf6_neighbor_state_str[prev_state],
196 ospf6_neighbor_state_str[next_state],
197 ospf6_neighbor_event_string(event));
198 }
199
200 /* Optionally notify about adjacency changes */
201 if (CHECK_FLAG(on->ospf6_if->area->ospf6->config_flags,
202 OSPF6_LOG_ADJACENCY_CHANGES)
203 && (CHECK_FLAG(on->ospf6_if->area->ospf6->config_flags,
204 OSPF6_LOG_ADJACENCY_DETAIL)
OSPFv3 is creating the event without a managing thread and as such
if the event is not run before a deletion event comes in memory
will be freed up and we'll start trying to access memory we should
not. Modify ospfv3 to track the thread and appropriately stop
it when the memory is deleted or it is no longer need to run
that bit of code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
in show: 'show ipv6 ospf6' handler command, the reason of SPF
executation is looked up and displayed. At startup, SPF has been
started, but shows no specific reason. Instead of dumping non
initialised string context, reset the string context.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Description:
Addressed the following TAINTED_SCALAR issue which can possibly
leads to memory currption.
1. *** CID 1506514: Insecure data handling (TAINTED_SddddddCALAR)
/ospf6d/ospf6_gr_helper.c: 1222 in ospf6_grace_lsa_show_info()
2. *** CID 1506513: Insecure data handling (TAINTED_SCALAR)
/ospf6d/ospf6_gr_helper.c: 160 in ospf6_extract_grace_lsa_fields()
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
if_lookup_by_index_all_vrf doesn't work correctly with netns VRF backend
as the same index may be used in multiple netns simultaneously.
We always know the OSPF6 instance we work with, so use its VRF id for
the interface lookup.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Description:
code changes involve removal of increment and decrement operators
during function calls. These expressions make code less readable.
Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
This removes a giant `switch { }` block from lib/zclient.c and
harmonizes all zclient callback function types to be the same (some had
a subset of the args, some had a void return, now they all have
ZAPI_CALLBACK_ARGS and int return.)
Apart from getting rid of the giant switch, this is a minor security
benefit since the function pointers are now in a `const` array, so they
can't be overwritten by e.g. heap overflows for code execution anymore.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
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>
if_lookup_by_name_all_vrf doesn't work correctly with netns VRF backend
as the same index may be used in multiple netns simultaneously.
Use the appropriate VRF when looking for the interface.
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>
Add the ability to specify the router-id/area-id when deleting the debug
ospf6 configuration.
The new commands are as follow:
no debug ospf6 border-routers router-id [A.B.C.D]
no debug ospf6 border-routers area-id [A.B.C.D]
Update the doc as well.
Signed-off-by: Ahmad Caracalli <ahmad.caracalli@6wind.com>
Implement NSSA address ranges as specified by RFC 3101:
NSSA border routers may be configured with Type-7 address ranges.
Each Type-7 address range is defined as an [address,mask] pair. Many
separate Type-7 networks may fall into a single Type-7 address range,
just as a subnetted network is composed of many separate subnets.
NSSA border routers may aggregate Type-7 routes by advertising a
single Type-5 LSA for each Type-7 address range. The Type-5 LSA
resulting from a Type-7 address range match will be distributed to
all Type-5 capable areas.
Syntax:
area A.B.C.D nssa range X:X::X:X/M [<not-advertise|cost (0-16777215)>]
Example:
router ospf6
ospf6 router-id 1.1.1.1
area 1 nssa
area 1 nssa range 2001:db8:1000::/64
area 1 nssa range 2001:db8:2000::/64
!
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Type-7 LSAs and their corresponding Type-5 LSAs don't share the same
LS IDs (unlike in the case of OSPFv2). As such, do not attempt to find
a translated Type-5 LSA using the LS ID of a Type-7 LSA. Instead,
use the LS-ID stored in the OSPF routing table.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This commits consists of several changes that positively impact
code reability without introducing any logical change.
Summary of the changes:
* Return earlier in ospf6_abr_range_update() in order to reduce one
level of indentation;
* Remove ospf6_translated_nssa_originate() since it's nothing other
than a useless wrapper around ospf6_lsa_translated_nssa_new();
* Change ospf6_abr_translate_nssa() to return void;
* Change ospf6_abr_process_nssa_translates() checking for NSSA areas
before anything else;
* Remove ospf6_abr_remove_unapproved_translates_apply() since it's a
small function that is only called in one place;
* Change ospf6_abr_check_translate_nssa() to avoid an LSDB lookup when
the router isn't an ABR.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
In addition to being unnecessary, this check is problematic for the
upcoming NSSA ranges feature since NSSA ranges aren't added to the
OSPF routing table. Remove this for simplicity.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This code tries to summarize NSSA Type-7 LSAs using normal ranges
which are intended to summarize Type-3 LSAs only. This is not only
wrong, but the code is incomplete and lacking lots of things. Better
to remove it before implementing NSSA ranges correctly.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The iteration performed on ospf6_abr_unapprove_translates() was
wrong since AS-external LSAs are stored in the global LSDB and not
in the area LSDBs. As such, the "unapproved" flag wasn't being set
in any translated AS-external LSA, leading them to linger forever.
Fix the LSDB iteration and make the required changes to unset the
"unapproved" flag for AS-external LSAs that shouldn't be removed.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The ABR task already takes care of refreshing translated Type-5
LSAs that correspond to self-originated Type-7 LSAs. There's no
need to do that in ospf_external_lsa_install() as well. The ospfd
NSSA code takes the same precaution.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Change ospf6_get_nssa_fwd_addr() to try finding a global address
on any interface of the area and not on the first one only.
Additionally, do a micro-optimization in
ospf6_interface_get_global_address() to return as soon as a global
address is found.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Every received or originated LSA is automatically scheduled to be
refreshed periodically, there's no need to do that manually here.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Description:
When grace lsa received, DUT is adding
the copy of the lsas to all nbrs retransmission list as part of
flooding procedure and subsequently incrementing the rmt counter in
the original the LSA. This counter is supposed to be decremented
when ack is received by nbr and the lsa will be removed from retransmission list.
But in our current scenario,
Step-1:
When GR helper is disabled, if DUT receives the grace lsa
it adds the lsa copy to nbrs retransmission list but original
LSA will be discarded since GR helper disabled.
Step-2:
GR helper enabled and DUT receives the grace lsa, as part
of flooding process all nbrs have same copy of lsa in their
corresponding rmt list which was added in step -1 due to this
the corresponding rmt counter in the original lsa is not getting
incremented.
Step-3:
If the same copy of the grace lsa received by DUT, It considers
as implicit ack from nbr if the same copy of the lsa exits in its
rmt list and subsequently decrement the rmt counter.
Since counter is zero (because of step-1 and 2) , it is asserting while decrement.
Signed-off-by: Rajesh Girada <rgirada@vmware.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 lsa->expire thread is for keeping track of when we
are expecting to expire(remove/delete) a lsa. There
are situations where we just decide to straight up
delete the lsa, but we are not ensuring that the
lsa is not already setup for expiration.
In that case just stop the expiry thread and
do the deletion.
Additionally there was a case where ospf6d was
just dropping the fact that a thread was already
scheduled for expiration. In that case we
should just setup the timer again and it will
reset it appropriately.
Fixes: #9721
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Problem Statement:
Multiple struct compare using memcmp, which might result in issue due to
structure padding/alignment.
Fix:
The code changes involve structure member by member comparison to
remove any issues related to padding/alignment.
Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
(cherry picked from commit 67db821a1d6d68b19862d50b68ed19278c5f2422)
OSPFv3 recently introduced the usage of import route. Switch it
back to using the normal ZEBRA_NEXTHOP_REGISTER command.
Signed-off-by: Donald Sharp <sharpd@nvidia.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>
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>
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>
Problem Statement:
==================
Everytime redistribute CLI is executed, external LSAs are
re-originated. When there is no change in the CLI parameters
the LSAs should not get re-originated.
Fix:
=================
Check if the CLI params are same, do not re-originate the LSA.
Fixes: #9445
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
The lsa and lsanext must be unlocked if break out of ALL_LSDB loop.
Incidentally correct the comment of ALL_LSDB.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
Description:
Changes to cover all the following GR helper exit scenarios.
1. Upon receiving max age grace lsa.( successful graceful restart)
2. Topo change
3. Grace timer expiry.
4. User changes( like config deletion , interface down)
Signed-off-by: Rajesh Girada <rgirada@vmware.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>
Fix:
When summarised Type-5 LSA is removed, the corresponding Type-7
LSAs also need to be removed from area.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Fix:
1. The assert at line ospf6_asbr.c:2849 is not required.
2. When Individual LSAs are present and summarisation is configured
we need to remove such LSAs and originate the summarised ones.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
For ECMP routes, the metric cost and metric type are compared
even when the asbr entry is not present. This stops the routes
from getting removed when max age LSAs are received for the
ECMP routes.
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
The only difference in daemons' interface node definition is the config
write function. No need to define the node in every daemon, just pass
the callback as an argument to a library function and define the node
there.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
RCA: When Type-7 LSA is updated, the LSDB is searched, if the
LSA is present in the LSDB then the LSA is updated with next
sequence number and if not then it is originated with the
INITIAL sequence number.
Here while originating Type-7 LSA Process Level LSDB is searched
for instead of area level LSDB.
Fix: Search in the area level LSDB and not in the process level.
Fixes#9099
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
* When the "cost" argument isn't present, the default cost should be
used instead of preserving the previously configured one (if any);
* When the "not-advertise" argument isn't present, the "not-advertise"
flag should be unset regardless if it was previously configured or
not.
Configuration commands should be deterministic and work in the same
way regardless of the current state.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
like the other automake variables, setting `xyz_LDFLAGS` causes
`AM_LDFLAGS` to be ignored for `xyz`. For some reason I had in my mind
that automake doesn't do this for LDFLAGS, but... it does. (Which is
consistent with `_CFLAGS` and co.)
So, all the libraries and modules have been ignoring `AM_LDFLAGS` (which
includes `SAN_FLAGS` too). Set up new `LIB_LDFLAGS` and
`MODULE_LDFLAGS` to handle all of this correctly (and move these bits to
a central location.)
Fixes: #9034
Fixes: 0c4285d77e ("build: properly split CFLAGS from AC_CFLAGS")
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This is a requirement for avoiding sending traffic somewhere it was not
supposed to go: install summary route to local RIB to send traffic to
Null0.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
This feature is required for creating summary routes that drop traffic
without more specific routes.
Authored-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Signed-off-by: Mobashshera Rasool <mrasool@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>
In RFC 2328 OSPF Version 2, Section 12.4.3.1 "Originating summary-LSAs
into stub areas" mentions that the stub areas should not import external
routes and instead should generate a 'default summary-LSA' set to
default destination.
> In a stub area, instead of importing external routes
> each area border router originates a "default summary-
> LSA" into the area. The Link State ID for the default
> summary-LSA is set to DefaultDestination, and the metric
> set to the (per-area) configurable parameter
> StubDefaultCost. Note that StubDefaultCost need not be
> configured identically in all of the stub area's area
> border routers.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
The route linked list in ospf6d is ordered in prefix batches which
are associated with a the route node denoting the prefix. So if
you look up the prefix in the tree and start walking the list, if you
find a prefix which differs from the one you are interested in then
you have gone beyond the batch of routes for that prefix.
In some cases the route database linked list is used on a per-prefix
basis. The existing code simply does a continue when the prefix does
not match and continues to walk. This works with small numbers of
routes because the walk continues through unrelated prefix batches and
never finds anything to operate on. However if we have many thousands
of routes these walks become expensive and can cause the SPF thread
(amongst others) to run very long, causing issues with adjacencies
where the dead timer is short.
Add a break to these prefix-based loops to exit early if we get a
prefix mismatch to avoid continuing down the route list if we have
overshot.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
The OSPF6_INTERFACE_LOOPBACK interface state wasn't entered anywhere,
even if the interface was OSPF6_IFTYPE_LOOPBACK. Fix.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
When ospf6d comes up, it gets interface and address state before it
decides on its router ID. This results in a bunch of LSAs with
advertising router ID 0.0.0.0 in the LSDB. Not quite right.
There's a whole bunch of paths leading to this, so just drop the LSA in
ospf6_lsa_originate. The router-ID change causes everything to be
readvertised anyway (... but the delete doesn't catch the 0.0.0.0 stuff
because the router-ID is now different.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Prefix options are per-prefix, not per-path. As evident by the fact
that the field is never used on ECMP paths. Move it where it belongs.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Somehow the hello message debugging code slipped outside the debug
guard. Lets just remove it.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
There's a delay in FreeBSD between issuing a command to leave a
multicast group and an actual leave. If we execute "no router ospf6" and
"router ospf6" fast enough, we can end up in a situation when OS
performs the leave later than it performs the join and the interface
remains without a multicast group.
Instead of counting on a one second delay, we must wait until the
interface actually leaves the group.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Move code to its own function and remove most of the code indentation
(e.g. test for failure and quit as soon as possible).
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Move `is_default_prefix` variations to `lib/prefix.h` and make the code
use the library version instead of implementing it again.
NOTE
----
The function was split into per family versions to cover all types.
Using `union prefixconstptr` is not possible due to static analyzer
warnings which cause CI to fail.
The specific cases that would cause this failure were:
- Caller used `struct prefix_ipv4` and called the generic function.
- `is_default_prefix` with signature using `const struct prefix *` or
`union prefixconstptr`.
The compiler would complain about reading bytes outside of the memory
bounds even though it did not take into account the `prefix->family`
part.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
This code has been wrong ~ever (according to git history). There are 3
conditional blocks with the added assertion that both the LSA and the
vertex being checked can't both be network LSAs.
The third block is clearly assuming both LSA and vertex are router
LSAs b/c it is accessing the backlink and lsdesc as router lsdesc's also
making sure both are p2p links (which they would have to be to point at
each other).
The programming error here is that (A && B) == False does NOT imply !A,
but the code is written that way.
So we end up in the third block one of LSA or vertex being network LSAs
rather easily (whenever that is the case and the desc isn't the backlink
being sought).
This was caught by ASAN b/c the lsdesc and backlinks are being accessed
(> 4 byte field offsets) as if they were router lsdesc's in the third
block, when in fact one of them is a network lsdesc which is only 4
bytes long -- so ASAN flags the access beyond bounds.
Signed-off-by: Christian Hopps <chopps@labn.net>
Issue: Crash observed when LSAs are removed from LSDB after max age
when there is no area configured.
(gdb) bt
0 raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
1 0x00007fdb190548bc in core_handler (signo=6, siginfo=0x7ffdd2f5a470, context=<optimized out>) at lib/sigevent.c:262
2 <signal handler called>
3 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
4 0x00007fdb185ad921 in __GI_abort () at abort.c:79
5 0x00007fdb1907f199 in _zlog_assert_failed (xref=xref@entry=0x55f30902aa20 <_xref.21999>, extra=extra@entry=0x0) at lib/zlog.c:581
6 0x000055f308dc4f78 in ospf6_asbr_lsa_remove (lsa=0x55f30a7546d0, asbr_entry=0x0) at ospf6d/ospf6_asbr.c:696
7 0x000055f308dd8f0d in ospf6_lsdb_remove (lsa=0x55f30a7546d0, lsdb=lsdb@entry=0x55f30a73d300) at ospf6d/ospf6_lsdb.c:166
8 0x000055f308dd9701 in ospf6_lsdb_maxage_remover (lsdb=0x55f30a73d300) at ospf6d/ospf6_lsdb.c:376
9 0x000055f308dee724 in ospf6_maxage_remover (thread=<optimized out>) at ospf6d/ospf6_top.c:603
10 0x00007fdb1906520d in thread_call (thread=thread@entry=0x7ffdd2f5ae90) at lib/thread.c:1919
11 0x00007fdb19023e48 in frr_run (master=0x55f30a569b70) at lib/libfrr.c:1155
12 0x000055f308dc09b6 in main (argc=6, argv=0x7ffdd2f5b198, envp=<optimized out>) at ospf6d/ospf6_main.c:235
(gdb)
Steps to reproduce the issue:
1. router ospf6
2. redistribute static
3. ipv6 route 1::1/128 Null0
4. no redistribute static
5. wait for Max aged LSA to flush
6. Check DB, crash occurs.
RCA:
Crash occurred while accessing listgetdata(listhead(ospf6->area_list))
When there is no area attached to any of the interface listhead(ospf6->area_list)
is NULL. Therefore it crashed due to NULL access.
Fix:
Check before accessing null pointer.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Harmonize the code of functions ospf6_asbr_redistribute_disable and
ospf6_asbr_redistribute_reset.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.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>
Problem Statement:
==================
when route-map config is changed from permit to deny, it is not getting
applied to both connected and static and vice versa
RCA:
==================
When route-map changes from permit to deny or vice versa, a notification is
sent to ospf6 daemon via ospf6_asbr_routemap_update. In this function, a thread
is scheduled after 5 seconds to apply the route-map changes. In this thread
(ospf6_asbr_routemap_update_timer), only the first type is passed as argument
and only the first type i.e "connected" is passed and hence in callback only
on this type of route route-map gets applied.
Fix:
====
Need to loop through all the route-types in the call back and process
the route-map changes. Added a flag to mark which all route-types needs
to be processed.
Test Executed:
===============
1. Change route-map from permit to deny.
2. Change route-map from deny to permit.
3. Add new route and checked.
4. Verified summarised routes.
Risk:
============
Low
Signed-off-by: Mobashshera Rasool <mrasool@vmware.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>
Some unprotected debugs need to have macro protection,
Split these into the existing covering macro section to remove
a check per-packet from the main path.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
Coverity flagged the possibility of an overflow in the latency
calculation, ensure that 64 bit integers are used in the
calculation to avoid this error.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
When OSPFv3 router is configured in both default and non-default VRFs,
every packet destined to a non-default VRF is read twice. This makes it
impossible to establish neighborship because every DbDesc packet is
treated as duplicated and we end up infinitely exchanging DbDescs.
We should drop packets received in the default VRF if an interface we
received it on is bound to another VRF.
Same thing was done for OSPFv2 in 555691e.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Problem Statement:
==================
Max aged LSAs are not getting deleted from DB when there are multiple
neighbors in a LAN.
Root Cause Analysis:
====================
When the LSA is added to the neighbor's retransmit list, the LSA retrans count
is incremented but it is not checked if the LSA is already present in the
retransmit list leading to the count being incremented multiple times
untill the ack is not received and when the ack is received the count is
decremented once and hence the count never becomes 0 and
it remains in the DB forever.
Fix:
====================
Do not increment the retrans count multiple times if the LSA is already
present in the retransmit list of the neighbor. Also do not add the LSA
in the retransmit List if already present.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
