Prior to this fix, restarting the client just failed b/c the code tried to
"refresh" the existing LSA being added, except that code checked for meta-data
to exist, which was deleted when the client disconnected previously (or had
never connected and the LSA state was picked up from the network).
Signed-off-by: Christian Hopps <chopps@labn.net>
Reachable router information is used by OSPF opaque clients in order
to determine if the router advertising the opaque LSA data is
reachable (i.e., 2-way conectivity check).
Signed-off-by: Christian Hopps <chopps@labn.net>
The reachable router table is used by OSPF opaque clients in order to
determine if the router advertising the opaque LSA data is
reachable (i.e., 2-way conectivity check).
Signed-off-by: Christian Hopps <chopps@labn.net>
Firstly, *keep no change* for `hash_get()` with NULL
`alloc_func`.
Only focus on cases with non-NULL `alloc_func` of
`hash_get()`.
Since `hash_get()` with non-NULL `alloc_func` parameter
shall not fail, just ignore the returned value of it.
The returned value must not be NULL.
So in this case, remove the unnecessary checking NULL
or not for the returned value and add `void` in front
of it.
Importantly, also *keep no change* for the two cases with
non-NULL `alloc_func` -
1) Use `assert(<returned_data> == <searching_data>)` to
ensure it is a created node, not a found node.
Refer to `isis_vertex_queue_insert()` of isisd, there
are many examples of this case in isid.
2) Use `<returned_data> != <searching_data>` to judge it
is a found node, then free <searching_data>.
Refer to `aspath_intern()` of bgpd, there are many
examples of this case in bgpd.
Here, <returned_data> is the returned value from `hash_get()`,
and <searching_data> is the data, which is to be put into
hash table.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
The commands:
router isis 1
mpls-te on
no mpls-te on
mpls-te on
no mpls-te on
!
Will crash
Valgrind gives us this:
==652336== Invalid read of size 8
==652336== at 0x49AB25C: typed_rb_min (typerb.c:495)
==652336== by 0x4943B54: vertices_const_first (link_state.h:424)
==652336== by 0x493DCE4: vertices_first (link_state.h:424)
==652336== by 0x493DADC: ls_ted_del_all (link_state.c:1010)
==652336== by 0x47E77B: isis_instance_mpls_te_destroy (isis_nb_config.c:1871)
==652336== by 0x495BE20: nb_callback_destroy (northbound.c:1131)
==652336== by 0x495B5AC: nb_callback_configuration (northbound.c:1356)
==652336== by 0x4958127: nb_transaction_process (northbound.c:1473)
==652336== by 0x4958275: nb_candidate_commit_apply (northbound.c:906)
==652336== by 0x49585B8: nb_candidate_commit (northbound.c:938)
==652336== by 0x495CE4A: nb_cli_classic_commit (northbound_cli.c:64)
==652336== by 0x495D6C5: nb_cli_apply_changes_internal (northbound_cli.c:250)
==652336== Address 0x6f928e0 is 272 bytes inside a block of size 320 free'd
==652336== at 0x48399AB: free (vg_replace_malloc.c:538)
==652336== by 0x494BA30: qfree (memory.c:141)
==652336== by 0x493D99D: ls_ted_del (link_state.c:997)
==652336== by 0x493DC20: ls_ted_del_all (link_state.c:1018)
==652336== by 0x47E77B: isis_instance_mpls_te_destroy (isis_nb_config.c:1871)
==652336== by 0x495BE20: nb_callback_destroy (northbound.c:1131)
==652336== by 0x495B5AC: nb_callback_configuration (northbound.c:1356)
==652336== by 0x4958127: nb_transaction_process (northbound.c:1473)
==652336== by 0x4958275: nb_candidate_commit_apply (northbound.c:906)
==652336== by 0x49585B8: nb_candidate_commit (northbound.c:938)
==652336== by 0x495CE4A: nb_cli_classic_commit (northbound_cli.c:64)
==652336== by 0x495D6C5: nb_cli_apply_changes_internal (northbound_cli.c:250)
==652336== Block was alloc'd at
==652336== at 0x483AB65: calloc (vg_replace_malloc.c:760)
==652336== by 0x494B6F8: qcalloc (memory.c:116)
==652336== by 0x493D7D2: ls_ted_new (link_state.c:967)
==652336== by 0x47E4DD: isis_instance_mpls_te_create (isis_nb_config.c:1832)
==652336== by 0x495BB29: nb_callback_create (northbound.c:1034)
==652336== by 0x495B547: nb_callback_configuration (northbound.c:1348)
==652336== by 0x4958127: nb_transaction_process (northbound.c:1473)
==652336== by 0x4958275: nb_candidate_commit_apply (northbound.c:906)
==652336== by 0x49585B8: nb_candidate_commit (northbound.c:938)
==652336== by 0x495CE4A: nb_cli_classic_commit (northbound_cli.c:64)
==652336== by 0x495D6C5: nb_cli_apply_changes_internal (northbound_cli.c:250)
==652336== by 0x495D23E: nb_cli_apply_changes (northbound_cli.c:268)
Let's null out the pointer. After this change. Valgrind no longer reports issues
and isisd no longer crashes.
Fixes: #10939
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
That commit aim is to fix an invalid behavior when
default-information is activated on ospf router without always option.
Consider an ASBR with:
-one default route coming from ospf,
-and another default route coming from another deaemon (such BGP or static).
When the daemon bgp stops advertising its default route,
-ospf continues to advertise its previous default route (with aging 0),
-this may create default routing loops.
Expected behavior: is to update the removed external default route with
MAXAGING value.
Updating with MAXAGING value will notify the fact the route is currently
invalid. A later removal from ospf external LSA database will be made.
Analysis: all default routes have their type overwritten by a
DEFAULT_ROUTE type. Thus all default routes whatever its origin (ospf,
bgp, static...) is treated in a same way. But this is not pertinent for
ospf originated default routes.
Fix: avoid overwiting of route type when default route is ospf type.
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
The following configuration:
router ospf
segment-routing global-block 16000 23999 local-block 1000 2000
!
appears in the 'show running-config' like below:
router ospf
local-block 1000 2000
!
When there are custom Adjacencies, display the SRGB even if SRGB
has the default settings.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
There is no need to have an interface available to configure
SRGB. Conversely, it should be possible to remove the SRGB
when no interfaces are available.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
At the moment it's inconsistent, and very annoying. Let's just fix this, and
add a deprecation period to remove them after that.
```
vr_ib# show ip ospf neighbor json
{
"neighbors":{
"192.10.120.2":[
{
"priority":1,
"state":"Full\/DROther",
"deadTimeMsecs":36543,
"address":"192.10.120.2",
"ifaceName":"VLINK0",
"retransmitCounter":0,
"requestCounter":0,
"dbSummaryCounter":0
},
```
```
vr_ib# show ip ospf neighbor detail json
{
"neighbors":{
"192.10.120.2":[
{
"ifaceAddress":"192.10.120.2",
"areaId":"0.0.0.0",
"ifaceName":"VLINK0",
"nbrPriority":1,
"nbrState":"Full",
"stateChangeCounter":5,
"lastPrgrsvChangeMsec":53367612,
"routerDesignatedId":"0.0.0.0",
"routerDesignatedBackupId":"0.0.0.0",
"optionsCounter":66,
"optionsList":"*|O|-|-|-|-|E|-",
"routerDeadIntervalTimerDueMsec":33126,
"databaseSummaryListCounter":0,
"linkStateRequestListCounter":0,
"linkStateRetransmissionListCounter":0,
"threadInactivityTimer":"on",
"threadLinkStateRequestRetransmission":"on",
"threadLinkStateUpdateRetransmission":"on",
"grHelperStatus":"None"
},
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Description:
Default route is not getting flushed from neighbours though originator
triggered flush and deleted LSA from its database. It become as stale
LSA in neighbours databse forever. This could seen in the following
sequence of configurations with less than a second interval b/w configs.
And this could happen only when originator shouldnt have default route
in its rib so it originates default route only when configure with 'always'
option.
step-1:default-information originate always
step-2:no default-information originate always
step-3:default-information originate
In step-1, default route will be originated to AS.
In step-2, default route will be flushed to AS, but neighbours will be
discarding this update due to minlsainterval condition.
And it is expected that DUT need to keep send this update
until it receives the ack from neighbours by adding each
neighbour's retransmission list.
In Step-3: It is deleting the lsas from nbr's retransmission list
by assuming it initiated the flush. This is cuasing to not
send the lsa update anymore to neighbours which makes
stale lsa in nbrs forever.
Fix:
Allowed to delete the lsa from retransmission list only when lsa is
not in maxage during flushing procedure.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
before:
```
r1# show ip ospf vrf blue
% OSPF instance not found
r1# show ip ospf vrf default
% OSPF instance not found
r1# show ip ospf
% OSPF instance not found
```
after:
```
r1# show ip ospf vrf blue
% OSPF is not enabled in vrf blue
r1# show ip ospf vrf default
% OSPF is not enabled in vrf default
r1# show ip ospf
% OSPF is not enabled in vrf default
```
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
Description:
NULL pointer wrongly passed instead of 'ei' pointer to
ospf_external_lsa_originate() API in opaque capability enable/disable
which always make it to fail in origination.
Corrected it by passing actual ei pointer.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Skip marking routes as changed in ospf_if_down if there's now
new_table present, which might be the case when the instance is
being finished
The backtrace for the core was:
raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:50
core_handler (signo=11, siginfo=0x7fffffffe170, context=<optimized out>) at lib/sigevent.c:262
<signal handler called>
route_top (table=0x0) at lib/table.c:401
ospf_if_down (oi=oi@entry=0x555555999090) at ospfd/ospf_interface.c:849
ospf_if_free (oi=0x555555999090) at ospfd/ospf_interface.c:339
ospf_finish_final (ospf=0x55555599c830) at ospfd/ospfd.c:749
ospf_deferred_shutdown_finish (ospf=0x55555599c830) at ospfd/ospfd.c:578
ospf_deferred_shutdown_check (ospf=<optimized out>) at ospfd/ospfd.c:627
ospf_finish (ospf=<optimized out>) at ospfd/ospfd.c:683
ospf_terminate () at ospfd/ospfd.c:653
sigint () at ospfd/ospf_main.c:109
quagga_sigevent_process () at lib/sigevent.c:130
thread_fetch (m=m@entry=0x5555556e45e0, fetch=fetch@entry=0x7fffffffe9b0) at lib/thread.c:1709
frr_run (master=0x5555556e45e0) at lib/libfrr.c:1174
main (argc=9, argv=0x7fffffffecb8) at ospfd/ospf_main.c:254
Signed-off-by: Tomi Salminen <tsalminen@forcepoint.com>
if r1 has a route received from a neighbor with the default administrative
distance configured
r1# sh ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, 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.1/32 [110/20] via 10.0.12.2, r1-r2-eth0, weight 1, 00:00:41
if we change the administrative distance
r1(config)# router ospf
r1(config-router)# distance 50
this is not applied as there are no changes in the routing table
r1# sh ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, 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.1/32 [110/20] via 10.0.12.2, r1-r2-eth0, weight 1, 00:00:13
This commit will force the update of the routing table with the new configured distance
r1# sh ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, 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.1/32 [50/20] via 10.0.12.2, r1-r2-eth0, weight 1, 00:00:14
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
FRR stores the route_tag in network byte order. Bug filed indicates
that the `show ip ospf route` command shows the correct value.
Every place route_tag is dumped in ospf_vty.c the ntohl function
is used first.
Fixes: #10450
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Two minor fixes:
- remove redundant "(a.b.c.d/m)" in "prefix" description
- remove some annoying space in "summary-address" and "tag"
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Currently "range" command can only accept `cost` or `substitute`
individually, and `show running` will mix them.
So need make it accept mixed form with both of them, otherwise
configuration file in mixed form will fail to start.
Signed-off-by: anlan_cs <vic.lan@pica8.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>
Description:
This LSID alogithm added as per rcf2328 Appendex-E recommendation.
This applies only for AS-external lsas and summary lsas.
As an example of the algorithm, consider its operation when the
following sequence of events occurs in a single router (Router A).
(1) Router A wants to originate an AS-external-LSA for
[10.0.0.0,255.255.255.0]:
(a) A Link State ID of 10.0.0.0 is used.
(2) Router A then wants to originate an AS-external-LSA for
[10.0.0.0,255.255.0.0]:
(a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated using a
new Link State ID of 10.0.0.255.
(b) A Link State ID of 10.0.0.0 is used for
[10.0.0.0,255.255.0.0].
(3) Router A then wants to originate an AS-external-LSA for
[10.0.0.0,255.0.0.0]:
(a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a
new Link State ID of 10.0.255.255.
(b) A Link State ID of 10.0.0.0 is used for
[10.0.0.0,255.0.0.0].
(c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID
of 10.0.0.255.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
The ospf instance code is not properly handling the default route
when using default-information originate. This is because
the code is looking for the default route to be saved with an
instance of <ospf instance id> but we always save it as a instance
id of 0. In fact OSPF asks zebra for the default route as a special
case in instance 0, always.
Here is the correct behavior:
eva# show ip ospf data
OSPF Instance: 3
OSPF Router with ID (192.168.122.1)
AS External Link States
Link ID ADV Router Age Seq# CkSum Route
0.0.0.0 192.168.122.1 8 0x80000001 0xdb08 E2 0.0.0.0/0 [0x0]
eva# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp39s0, 00:02:03
Fixes: #10251
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
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>
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>
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>
When the summary-address is deleted, `ospf_aggr_handle_external_info` is
called for each aggregated route for the cleanup. It needs to find the
corresponding OSPF instance and it does it using the `ei->instance`
which is totally wrong, because it's the instance from which the route
is redistributed, not the local OSPF instance. A pointer to the correct
OSPF instance is already stored in the external_info structure.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
An OSPF ABR, while in the process of announcing summary LSAs,
checks whether it's connected to the backbone area. If not, then
all summary LSAs are invalidated and not announced (or flushed)
while the missing backbone connectivity persists.
The backbone connectivity check consists of assessing whether
there's at least one fully formed adjacency in the backbone area. The
problem is that this check can fail unexpectedly if the router is
acting as a helper for a neighbor that is performing a graceful
restart. This is because there's a short interim of time in which
that neighbor's state will oscillate between ExStart and Full during
the LSDB synchronization process.
To address that issue, update ospf_act_bb_connection() to consider
neighbors performing a graceful restart as if they were fully
adjacent (which is what a GR helper should do).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This commit fixes a rather obscure bug that was causing the GR
topotest to fail on a frequent basis.
RFC 3623 specifies that a router acting as a helper to a restarting
neighbor should monitor topology changes and abort the GR procedures
when one is detected, falling back to normal OSPF operation.
ospfd uses the ospf_lsa_different() function to detect when the
content of an LSA has changed, which is considered as a topology
change. The problem is that ospf_lsa_different() can return true
even when the two LSAs passed as parameters are identical, provided
one LSA has the OSPF_LSA_RECEIVED flag set and the other not.
In the context of the ospf_gr_topo1 test, router rt6 performs
a graceful restart and a few seconds later acts as a helper for
router rt7. When it's acting as a helper for rt7, it still didn't
translate its NSSA Type-7 LSAs, something that happens only after 7
seconds (OSPF_ABR_TASK_DELAY) of the first SPF run. The translated
Type-5 LSAs on its LSDB were learned from the helping neighbors
(rt3 and rt7). It's then possible that the NSSA Type-7 LSAs might
be translated while rt6 is acting as helper for rt7, which causes
the daemon to detect a non-existent topology change only because
the OSPF_LSA_RECEIVED flag is unset in the recently originated
Type-5 LSA.
Fix this problem by ignoring the OSPF_LSA_RECEIVED flag when
comparing LSAs for the purpose of topology change detection.
In short, the bug would only show up when the restarting router
would start acting as a helper immediately after coming back up
(which would be hard to happen in the real world). The topotest
failures became more frequent after commit 6255aad0bc because of
the removal of the 'sleep' calls, which used to give ospfd more time
to converge before start acting as a helper for other routers. The
problem still occurred from time to time though.
Fixes#9983.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
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>
Description:
When changing the area from normal to NSSA, previous area's
ASBR router's type-5 also calculated and added to routing table along
with Type-7 lsas.
Made a change in route calculation such that it will not consider Type-5
lsas in calculation if it is originated from NSSA ASBR router.
These lsas will be age out at MAX age.
log:
frr(config-router)# do show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, 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
K>* 0.0.0.0/0 [0/0] via 10.112.157.253, ens160, 00:32:47
C>* 10.112.156.0/23 is directly connected, ens160, 00:32:47
S>* 22.22.22.2/32 [1/0] is directly connected, ens192, weight 1, 00:20:03
O>* 33.33.33.0/24 [110/20] via 100.1.1.220, ens192, weight 1, 00:08:55
via 100.1.1.220, ens192, weight 1, 00:08:55
O 100.1.1.0/24 [110/10] is directly connected, ens192, weight 1, 00:21:32
C>* 100.1.1.0/24 is directly connected, ens192, 00:23:11
frr(config-router)# do show ip ospf route
============ OSPF network routing table ============
N 100.1.1.0/24 [10] area: 0.0.0.1
directly attached to ens192
============ OSPF router routing table =============
R 2.2.2.2 [10] area: 0.0.0.1, ASBR
via 100.1.1.220, ens192
============ OSPF external routing table ===========
N E2 33.33.33.0/24 [10/20] tag: 0
via 100.1.1.220, ens192
via 100.1.1.220, ens192
Signed-off-by: Rajesh Girada <rgirada@vmware.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>
Function ospf_te_parse_te() and ospf_te_delete_te() browse TE TLV but also
subTLV. The loop that parse the subTLV check that cummulative read data doesn't
exceed the total size of the TLV. However, the sum variable that counts the
number of read data was wrongly intialize to 0 instead to 4 (i.e. the initial
TLV Header size that is located at the TOP of subTLV).
This patch adjust accordingly the initial value of the counter.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
The no-form should use the same arguments as the regular command, hence
replace "period" with "grace-period".
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Running ospf_topo_vrf1 leads us to this valgrind issue:
==2386518== Invalid read of size 8
==2386518== at 0x4971520: route_top (table.c:401)
==2386518== by 0x181F08: ospf_interface_bfd_apply (ospf_bfd.c:126)
==2386518== by 0x182069: ospf_interface_disable_bfd (ospf_bfd.c:158)
==2386518== by 0x18BF51: ospf_del_if_params (ospf_interface.c:557)
==2386518== by 0x18C584: ospf_if_delete_hook (ospf_interface.c:712)
==2386518== by 0x490CA0B: hook_call_if_del (if.c:61)
==2386518== by 0x490D1F3: if_delete_retain (if.c:286)
==2386518== by 0x490D337: if_delete (if.c:309)
==2386518== by 0x490CDED: if_destroy_via_zapi (if.c:200)
==2386518== by 0x49940A9: zclient_interface_delete (zclient.c:2237)
==2386518== by 0x4998062: zclient_read (zclient.c:3969)
==2386518== by 0x4979529: thread_call (thread.c:1908)
==2386518== by 0x4919918: frr_run (libfrr.c:1164)
==2386518== by 0x181AC7: main (ospf_main.c:235)
==2386518== Address 0x5df39a0 is 0 bytes inside a block of size 56 free'd
==2386518== at 0x48399AB: free (vg_replace_malloc.c:538)
==2386518== by 0x492A03E: qfree (memory.c:141)
==2386518== by 0x4970C6F: route_table_free (table.c:141)
==2386518== by 0x4970A36: route_table_finish (table.c:61)
==2386518== by 0x18C543: ospf_if_delete_hook (ospf_interface.c:708)
==2386518== by 0x490CA0B: hook_call_if_del (if.c:61)
==2386518== by 0x490D1F3: if_delete_retain (if.c:286)
==2386518== by 0x490D337: if_delete (if.c:309)
==2386518== by 0x490CDED: if_destroy_via_zapi (if.c:200)
==2386518== by 0x49940A9: zclient_interface_delete (zclient.c:2237)
==2386518== by 0x4998062: zclient_read (zclient.c:3969)
==2386518== by 0x4979529: thread_call (thread.c:1908)
==2386518== by 0x4919918: frr_run (libfrr.c:1164)
==2386518== by 0x181AC7: main (ospf_main.c:235)
==2386518== Block was alloc'd at
==2386518== at 0x483AB65: calloc (vg_replace_malloc.c:760)
==2386518== by 0x4929EFC: qcalloc (memory.c:116)
==2386518== by 0x49709F8: route_table_init_with_delegate (table.c:53)
==2386518== by 0x49717F4: route_table_init (table.c:528)
==2386518== by 0x18C328: ospf_if_new_hook (ospf_interface.c:659)
==2386518== by 0x490C97D: hook_call_if_add (if.c:60)
==2386518== by 0x490CE85: if_create_name (if.c:223)
==2386518== by 0x490DF32: if_get_by_name (if.c:622)
==2386518== by 0x4993F73: zclient_interface_add (zclient.c:2186)
==2386518== by 0x4998062: zclient_read (zclient.c:3969)
==2386518== by 0x4979529: thread_call (thread.c:1908)
==2386518== by 0x4919918: frr_run (libfrr.c:1164)
==2386518== by 0x181AC7: main (ospf_main.c:235)
==2386518==
Fix the ordering to do the individual node tree cleanup after we delete
the data we care about.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently, we automatically delete an inactive VRF when its last
interface is deleted. This code introduces a couple of crashes because
of the following problems:
- vrf_delete is called before calling if_del hook, so daemons may try to
dereference an ifp->vrf pointer which is freed
- in if_terminate, we continue to use the VRF in the loop condition
after the last interface is deleted
This check is needed only when the interface is deleted by the user,
because if the interface is deleted by the system, VRF must still exist
in the system. Move the check to appropriate places to fix crashes.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Issue #9983 explains what is wrong with the GR helper mode.
To unblock the CI that fails almost all the time on the ospf_gr_topo1
test, remove the commands and disable the test. Also add a reminder to
completely remove the helper mode if no one fixes the code in a month.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Description:
timerval datastructure is being used without initialization.
Using these uninitialized parameters can lead unexpected results
so initializing before using it.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Description:
In PointToPoint networks, There wont be DR and BDR.
But by default, All neighbours ism state is shown as
DR_OTHER.
Changed the nbr state format to <nbrsate>/- (ex : FULL/-)
to P2pnetworks.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Description:
1. Adding uptime to the 'show ip ospf neighbor' o/p.
2. Adding uptime and deadtime in string format for json consumption.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Do not return pointer to the newly created thread from various thread_add
functions. This should prevent developers from storing a thread pointer
into some variable without letting the lib know that the pointer is
stored. When the lib doesn't know that the pointer is stored, it doesn't
prevent rescheduling and it can lead to hard to find bugs. If someone
wants to store the pointer, they should pass a double pointer as the last
argument.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
When doing a normal exit from ospf we should close
the log file as that we are leaving a bunch of
unterminated logging processes by not doing so.
Signed-off-by: Donald Sharp <sharpd@nvidia.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>
The `show ip ospf neighbor json` command was displaying
state:`Full\/DR`
Where state was both the role and whether or not the neigbhor
was converged. While from a OSPF perspective this is the state.
This state is a combination of two things.
This creates a problem in testing because we have no guarantee
that a particular ospf router will actually have a particular role
given how loaded our topotest systems are. So add a bit of json
output to display both the converged status as well as the
role this router is playing on this neighbor/interface.
The above becomes:
state:`Full\/DR`
converged:`Full`
role:`DR`
Tests can now be modified to look for `Full` and allow it to
continue. Most of the tests do not actually care if this
router is the DR or Backup.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Commit 3551ee9e90304 introduced a regression that causes GR to fail
under certain circumstances. In short, while ISM events should
be ignored while acting as a helper for a restarting router, the
DR/BDR fields of the neighbor structure should still be updated
while processing a Hello packet. If that isn't done, it can cause
the helper to elect the wrong DR while exiting from the helper mode,
leading to a situation where there are two DRs for the same network
segment (and a failed GR by consequence). Fix this.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Before starting the graceful restart procedures, ospf_gr_prepare()
verifies for each configured OSPF instance whether it has the opaque
capability enabled (a pre-requisite for GR). If not, a warning is
emitted and GR isn't performed on that instance.
This PR introduces an additional opaque capability check that will
return a CLI error when the opaque capability isn't enabled. The
idea is to make it easier for the user to identify when the GR
activation has failed, instead of requiring him or her to check
the logs for errors.
The original opaque capability check from ospf_gr_prepare() was
retaining as it's possible that that function might be called from
other contexts in the future.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The ospfd opaque LSA infrastruture has an issue where it can't store
different versions of the same Type-9 LSA for different interfaces.
When flushing the self-originated Grace-LSAs upon exiting from the GR
mode, the code was looking up the single self-originated Grace-LSA
from the LSDB, setting its age to MaxAge and sending it out on all
interfaces.
The problem is that Grace-LSAs sent on broadcast interfaces have
their own unique "IP interface address" TLV that is used to identify
the restarting router. That way, just reusing the same Grace-LSA for
all interfaces doesn't work.
Fix this by generating a new Grace-LSA with its age manually set
to MaxAge whenever one needs to be flushed. This will allow the "IP
interface address" TLV to be set correctly and make GR work even in
the presence of multiple broadcast interfaces.
In the long term, the opaque LSA infrastructure should be updated
to support Type-9 link-local LSAs correctly so that we don't need to
resort to hacks like this.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Add a 'json' parameter to the 'show_opaque_info' callback definition,
and update all instances of that callback to not display plain-text
data when the user requested JSON data.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
RFC 3623 says:
"If the restarting router determines that it was the Designated
Router on a given segment prior to the restart, it elects
itself as the Designated Router again. The restarting router
knows that it was the Designated Router if, while the
associated interface is in Waiting state, a Hello packet is
received from a neighbor listing the router as the Designated
Router".
Implement that logic when processing Hello messages to ensure DR
interfaces will preserve their DR status across a graceful restart.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
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>
Issue:
===================
OSPF neighbors are not going down even after 10 mins when
having a mismatch in hello and dead interval.
First neighbors are formed and then a mismatch in the interval
is created, it is observed that the neighbor is not going down.
Root Cause Analysis:
====================
The event HelloReceived defined in RFC 2328 was named as PacketReceived
and this event was scheduled whenever LS Update, LS Ack, LS Request,
DD description packet or Hello packet is received.
Although there is a mismatch in the Hello packet contents, the
event PacketReceived gets triggered due to LS Update received and the
dead timer gets reset and hence the neighbor was never going Down and
remains FULL.
Fix:
==================
As per RFC 2328, the HelloReceived needs to be triggered only when
valid OSPF Hello packet is received and not when other OSPF packets
are received. Modified the function name as well.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Description:
As per the RFC 3623 section 3.2,
OSPF nbr shouldn't be deleted even in unsuccessful helper exit.
1. Made the changes to keep neighbour even after exit.
2. Restart the dead timer after expiry in helper. Otherwise, Restarter
will be in FULL state in helper forever until it receives the 'hello'.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
There's a helper function to check whether the interface is loopback or
VRF - if_is_loopback_or_vrf. Let's use it whenever we need to check that.
There's no functional change in this commit.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The capability opaque command can trigger asserts through a rather
round-about mechanism. The command eventually calls
ospf_renegotiate_optional_capabilities, which will call
ospf_flush_self_originated_lsas_now, which has the side effect of
marking the OSPF instance as shutting down. This was causing the
flooding logic to call ospf_write immediately insted of waiting for the
select IO loop every time it was sending a maxage LSA. This could cause
the list of OSPF interfaces needing to send packets to be drained while
there was a call to ospf_write pending from the IO loop. When the
pending call ran, it would see the empty list of interfaces and assert.
Signed-off-by: Yuan Yuan <yyuanam@amazon.com>
The existing logic was not comparing the prefix of the extended
prefix TLV. As a result, the code was removing all of the prefix
SIDs except the one received on every LSA update.
Signed-off-by: Fredi Raspall <fredi@voltanet.io>
In update_ext_prefix_sid(), the sr_prefix is associated to the
SR node and inherits the adv router ID regardless.
Signed-off-by: Fredi Raspall <fredi@voltanet.io>
The code was not checking if in these label ranges [a,b], a is
smaller than b, which is assumed in several places, including when
determining the size of the block as b-a+1. As a consequence, the
results of a bad configuration can be unpredictable. Some effects
observed were: 1) segfault 2) de-activation of SR due to label
reservation failure.
The added validation function also checks if the SR blocks are
larger than some minimal size. RFC 8665 mandates that the blocks
be srictly larger than zero. In this patch, the minimum sized is
arbitrarily defined to be 16.
Checking if ranges would fall outside [16,1048575] is omitted
since the vty filtering takes care of that.
Signed-off-by: Fredi Raspall <fredi@voltanet.io>
The prior condition was wrong since it ended up allowing for
labels past the end of the SRLB. Variable 'current' should be in
range [0, size-1] for labels not to exceed the SRLB upper boundary.
In addition, emit a warning log when all labels in the SRLB have
been used.
Signed-off-by: Fredi Raspall <fredi@voltanet.io>
Replaces several complex if conditions by a lookup to a utility
to determine if two ranges of numbers overlap.
Signed-off-by: Fredi Raspall <fredi@voltanet.io>
Homogenize the code dealing with SRGBs and SRLBs by defining the
same set of utility functions for their reservation.
Unify also the logs and don't display function names since the
operations are only performed from the same functions.
Signed-off-by: Fredi Raspall <fredi@voltanet.io>
Homogenize the code dealing with SRGBs and SRLBs by defining the
same set of utility functions for the deletion of SR blocks.
Signed-off-by: Fredi Raspall <fredi@voltanet.io>
* Some of the debug flags were not shown in show debugging.
* The check for TI-LFA debug was made against the wrong variable.
* Some of the debugs were not cleared with 'no debug ospf'
Signed-off-by: Fredi Raspall <fredi@voltanet.io>
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.
Start a deprecation cycle of one year before removing the original
command
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
min lsa packet sizes are not always directly corresponding
to the actual LSA. Add a bit of comments so it's easier
for future people to figure out.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In some cases FRR is receiving a lsa data packet
with a length set to the length of the header only.
If we are expecting data from a peer in the form
of lsa data. Let's enforce it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Several functions in ospf_vty.c were allocating json memory
irrelevant if it was needed or not and then at the end of the loop
free'ing it if it was not used. Clean up the access pattern.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The usage of json_object_to_json_string_ext is meant for
generation of output string and returns a `char *` pointer
to the `formatted` output. Just calling it does nothing
and it's expensive to boot.
Modify the code in ospfd to just output with the NOSLASHESCAPE
when outputting.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Problem Statement :
===================
LSA with InitialSequenceNumber is not originated
after MaxSequenceNumber.
ANVL Test case 25.33 states:
============================
As soon as this flooding of a LSA with LS sequence number
MaxSequenceNumber has been acknowledged by all adjacent neighbors,
a new instance can be originated with sequence number of InitialSequenceNumber.
RCA :
=====
DUT did not originated LSA with INITIAL_SEQUENCE number even
after receiving ACK for max sequence LSA.
Code is not present to handle this situation in the lsa ack flow.
Fix :
=====
Add code to originate LSA with initial sequence number in the
LSA ack flow in case of wrap around sequence number.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
ANVL Test case 28.11
If the database copy has LS age equal to MaxAge and LS sequence number
equal to MaxSequenceNumber, simply discard the received LSA
without acknowledging it.
ANVL Test Case 25.22
When an attempt is made to increment the sequence number past the maximum
value of N - 1 (0x7fffffff; also referred to as MaxSequenceNumber),
the current instance of the LSA must first be flushed from the routing domain.
ANVL Test Case 25.23
As soon as this flooding of a LSA with LS sequence number MaxSequenceNumber
has been acknowledged by all adjacent neighbors, a new instance can be
originated with sequence number of InitialSequenceNumber.
RCA:
When IXIA sent LS Seq num as MAX and LS Age as (MAX - 3),
DUT dropped the packet instead of sending ACK.
In function ospf_ls_upd, at Line 2106 the code is there to drop the LSA.
Hence its failing.
Fix:
LSAs ACK must be sent when received LSA is having max sequence number
but not max-aged.
Considering /* CVE-2017-3224 */ issue, have corrected the existing
code to prevent attacker from sending LSAs with max sequence number
and higher checksum and blocking the flooding of the Max-sequence numbered LSAs.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Problem Statement:
===================
DUT selecting itself as DR when RR goes for reload.
Test Case 7.2
DUT (GR Helper) receives the Hello packet from the OSPF GR RESTARTER
(ANVL here) with DR and BDR set to 0.0.0.0 and DUT in its hello
neighbor list. DUT triggers the DR and BDR election although it is
in the Helper mode for that neighbor.
Root Cause Analysis:
====================
When hello packet is received with self router ID in the neighbor list,
there is no check in the code to handle this scenario. Hence the DR/BDR
election happens and it changes the DR although it is helper.
Fix:
===================
As per RFC 3623 Section 3. Operation of Helper Neighbor, below point,
we need to maintain the DR relationship.
Also, if X was the Designated Router on network segment S when the
helping relationship began, Y maintains X as the Designated Router
until the helping relationship is terminated.
Adding the check when DUT is under neighbor helper mode, we need to avoid
ISM state change when hello packet is received with DR/BDR set to 0.0.0.0.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Problem Statement:
==================
Memory Leak seen at show_ip_ospf_neighbor_all_common (ospf_vty.c:4635)
RCA:
=================
In function show_ip_ospf_neighbor_all_common, one child json object is not
added to the parent child object when there is no nbma neighbor. Hence
the memory leak.
Fix:
=================
Add the child object to the parent json object.
Fixes: #9548
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Problem Statement:
==================
Summary LSA is not originated when router-id is modified or process is reset
Root Cause Analysis:
====================
When router-id is modified or process is cleared, all the external LSAs are
flushed then LSA is re-originated using ospf_external_lsa_rid_change
When the LSAs are flushed, the aggregate flags are not reset.
Fix:
===============
Reset the aggregation flag when the LSAs
are flushed.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Problem Statement:
==================
When hello-interval is configured as 5, automatically dead interval becomes
4 times of hello i.e 20 seconds. But user wants the dead interval as
40 seconds and hello as 5 seconds. Therefore user configures it.
Now "ip ospf dead-interval 40" is not shown in "show running-config"
Therefore when user restarts the daemon, the dead interval goes back to
20 seconds and the neighbors are down.
Fix:
==================
If user configures dead-interval as 40, show it in show running config.
Fixes: #9401
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
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>
Fix CI Failure test_ospf_type5_summary_tc45_p0
Problem Statement:
==================
Summarised LSA is not flushed in OSPFv2 in below scenario:
1. Configure summary-address in ospfv2
2. redistribute static and connected.
3. Check the LSAs are received on neighbor.
4. Now remove all OSPFv2 configs, so neighbor will still have the summarised LSA.
5. Configure router ospf with redistribute static and connected.
6. Check the DB, summarised LSA is present although the configuration is not present.
7. Now configure the summary-address and remove the configuration after sometime.
8. The summarised LSA will be still present.
RCA:
==================
When self originated LSA is received from the neighbor and that
LSA is summarised one, the LSA is refreshed but a flag is not set
due to which it was not able to remove it later.
Fix:
==================
Set the originated flag when refreshing summarised LSA.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
There are a couple of things that are not initialized if the OSPF router
is created in a non-existent VRF:
- ospf_lsa_maxage_walker
- ospf_lsa_refresh_walker
- ospf_opaque_type11_lsa_init
Rearrange some code to always initialize them and make it easier to find
similar problems in the future.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
When OSPF is disabled on interface and enabled again, the IP which is
not matching the prefix-list is getting originated as External LSA.
Fixes: #9362
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Problem Statement:
==================
OSPF Peer gets stuck in EXSTART with ARISTA Device.
Root Cause:
=================
First peer is form with Arista device in normal area and then
the area type is changed to NSSA. Due to this Type-4 and Type-5
LSAs advertised by Arista router is still present in
the OSPF DB. While DD exchange the Type-5 LSAs are omitted but
the Type-4 LSAs are not omitted due to which Arista device gets
stuck in EXSTART and it keeps moving between EXCHANGE And EXSTART.
Fix:
=================
When the area is NSSA, we should not send Type-4 LSAs in DD
exchange packet.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
This command is currently always treated as an "unset" command, assuming
that active is the default type of the interface. In reality, the default
type of the interface can be changed using "passive-interface default"
command. Both "no" and regular commands can be "set" commands, depending
on the default value. They are treated as an "unset" when there's already
a config of the opposite type.
All this logic is in ospf_passive_interface_update.
Fixes#9240.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.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>
Let's be less radical. There's no reason to stop the whole daemon when
there's a socket creation error in a single VRF. The user can always
restart this single VRF to retry to create a socket.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
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>
ospf_distribute_list_update currently passes two arguments to
ospf_distribute_list_update_timer - pointer to the ospf structure and
protocol type. The protocol type is only used for logging and is not
even correct because if multiple changes happen during one
ospf->min_ls_interval, then only the type of the first change is logged.
It is better to completely remove the protocol type argument to have a
correct log and eliminate the need for memory allocation.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Description:
Ospf process crashes upon giving 'clear ip ospf neighbor' with
self routerId. It is asserting if it is a self neighbor in ospf
neighbour kill event processing.
Added a check to validate the provided router-id is self
router-id.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
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>
RFC 3623 specifies the Graceful Restart enhancement to the OSPF
routing protocol. This PR implements support for the restarting mode,
whereas the helper mode was implemented by #6811.
This work is based on #6782, which implemented the pre-restart part
and settled the foundations for the post-restart part (behavioral
changes, GR exit conditions, and on-exit actions).
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 ospf`
EXEC-level command needs to be issued before restarting the ospfd
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 ospfd 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.
Co-authored-by: GalaxyGorilla <sascha@netdef.org>
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Both the GR helper code and the upcoming GR restarting code are going
to share a lot of definitions. As such, rename ospf_gr_helper.h to
ospf_gr.h, which will be the central point of all GR definitions
and prototypes.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Remove previous log config
debug ospf graceful-restart helper
and just use
debug ospf graceful-restart
for everything related to OSPF GR.
Signed-off-by: GalaxyGorilla <sascha@netdef.org>
Log the LSA advertising router in addition to the LSA type and
ID in the places where that information is necessary to uniquely
identify the LSA in the LSDB.
This is useful, for example, to know exactly which LSA has changed
when the router is exiting from the GR helper mode when a topology
change was detected.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Problem Statement:
==================
[FRR OSPF] show ip ospf route json does not shown metric and tag.
Root Cause Analysis:
===================
In function show_ip_ospf_route_external, type 2 cost is not added in json.
Hence it is not displayed.
Fix:
=================
1. Add type2cost in the json display
2. Tag was also missing, added that as well
Issue: #8729
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Adding defensive code to the interface_link_params zebra callback
to check if the link params changed before taking action.
Signed-off-by: Karen Schoener <karen@voltanet.io>
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>
Description:
When opaque capability disabled/enabled , all the self-originated lsa will be
flushed and it will make the neighbours to renegotiate.
But here, external lsas are not being re-originated after negotiation
Fix:
Refresh/re-originate external lsas(Type-5 and Type-7) explicitly after
re-negotiation.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Currently, if the routemap already exists, we delete the pointer to it
when it is updated. We should delete the pointer only if the route-map
is actually deleted.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Add a null check to protect against the case where the neighbor
inactive timer is disabled. That can happen when the router is
acting as a helper for another router that is attempting to restart
gracefully.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The %p printf format specifier does already print the pointer address
with a leading "0x" prefix (indicating a hexadecimal number). There's
no need to add that prefix manually.
While here, replace explicit function names in log messages by
__func__.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
During shutdown, the ospf->maxage_lsa table is iterated over to
clean up all existing entries. While doing that, route_unlock_node()
should be called only for the nodes that have an associated entry,
otherwise the table will get corrupted and ospfd will crash.
As a side note, using a routing table to store MaxAge LSAs was a
very poor choice of a data structure, considering that a simple
rb-tree or hash table would get the job done with a much simpler
(and less error-prone) API. Something to cleanup in the future...
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Call ospf_lsa_flush() before free_opaque_info_per_id() since the
latter can deallocate the LSA that is going to be flushed.
Also, there's no need to set the LSA MaxAge to OSPF_LSA_MAXAGE
manually as the ospf_lsa_flush() function already takes care of that.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When exiting from the helper mode for a given router after an
unsuccessful graceful restart, removing the neighborship to that
router straight away leads to a dangling pointer in the associated
interface, which inevitably leads to a crash. To solve this
problem, schedule the removal of the neighbor instead of removing
it immediately.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Change the "show_ospf_grace_lsa_info" callback to account for the
fact that the "vty" parameter can be null.
This fixes a crash that happens when "debug ospf packet ls-update
detail" is configured and a Grace-LSA is sent or received.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When exiting from the GR helper mode, recalculate the DR only for
interfaces of the appropriate types (broadcast and NMBA).
This fixes a problem where the state of a neighbor reachable over a
p2p interface was changing from Full/DROther to Full/Backup across
a graceful restart.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Since a single ospfd process can have multiple OSPF interfaces
configured, we need to separate the global GR initialization and
termination from per-instance initialization and termination.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
To reproduce the issue:
1. Create summary-address: `summary-address 1.1.1.0/24`.
2. Try to delete it with the wrong tag: `no summary-address 1.1.1.0/24 tag 1`.
Each time this command is executed, route_node_lookup is called which
locks route node one more time. As the tag is wrong, the function
return immediately without unlock.
3. Finally delete the summary-address: `no summary-address 1.1.1.0/24`.
The route node won't be deleted.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Currently, passive interface flag is configured from the router node
using "passive-interface IFNAME". 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 "ip ospf"
prefix
- it is not in line with OSPFv3 - passive flag is configured from the
interface node using "ipv6 ospf6 passive" command
- most importantly, it doesn't work correctly when the interface is in
a different VRF - when using VRF-lite, it incorrectly changes the
vrf_id of the interface and it becomes desynced with the actual state;
when using netns, it creates a new fake interface and configures it
instead of configuring the necessary interface
To fix all the problems, this commit adds a new command to the interface
configuration node - "ip ospf passive". 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>
similarly to what was done for IS-IS in commit 01d43141, combine
the SRGB and SRLB commands for OSPF-SR, so that we can replace
overlapping ranges in one sweep change.
Also allow the range configuration to be stored before SR is enabled.
There is no reason why we should not - in fact that constraint meant
that we were always requesting the default label ranges regardless
of what we actually wanted to use.
Finally, update the topotests now that we do not need to refresh
the SRGB/SRLB/MSD after disabling SR. Note that the prefix-sid still
needs to be re-added.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
When we get this sequence of events:
- zebra receives interface up, sends to ospf
- ospf receives intf up, processes( including neighbor formation and spf )
and sends route to zebra for installation.
- zebra receives route for processing, schedules it too happen in the future
- zebra receives interface down event, sends to ospf
- zebra processes route X and marks it inactive because nexthop
interface is down
- zebra receives interface up event, sends to ospf
- ospf receives both events and processes the change and decides
that nothing has changed so it does not send any route change for X to zebra.
At this point zebra has a route from ospf that is marked as inactive, while
ospf believes that the route should be installed properly.
Modify the code such that on an interface down event, ospf marks the routes
as changed if the ifindex is being used for a nexthop, so that when ospf
is deciding if routes have changed post spf that it can just automatically
send that route down again if it still exists.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Found that in some circumstances, when the "ip ospf area"
command was entered for the default vrf, the wrong ospf
process would be used to check for the presence of a
"network" statement, causing the "ip ospf area" command to
be rejected. This was due to the command using the ospf
instance lookup to find the right ospf process, which can
be in error depending on when the processes were created.
Signed-off-by: Don Slice <dslice@nvidia.com>
When browsing or parsing OSPF LSA TLVs, we need to use the LSA length which is
part of the LSA header. This length, encoded in 16 bits, must be first
converted to host byte order with ntohs() function. However, Coverity Scan
considers that ntohs() function return TAINTED data. Thus, when the length is
used to control for() loop, Coverity Scan marks this part of the code as defect
with "Untrusted Loop Bound" due to the usage of Tainted variable. Similar
problems occur when browsing sub-TLV where length is extracted with ntohs().
To overcome this limitation, a size attribute has been added to the ospf_lsa
structure. The size is set when lsa->data buffer is allocated. In addition,
when an OSPF packet is received, the size of the payload is controlled before
contains is processed. For OSPF LSA, this allow a secure buffer allocation.
Thus, new size attribute contains the exact buffer allocation allowing a
strict control during TLV browsing.
This patch adds extra control to bound for() loop during TLV browsing to
avoid potential problem as suggested by Coverity Scan. Controls are based
on new size attribute of the ospf_lsa structure to avoid any ambiguity.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
If the default route redistribution is configured in OSPF 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>
Currently ospfd relies on vrf bitmaps in zclient to check that the
redistribution is configured. This doesn't work when the VRF for OSPF
instance doesn't exist yet, because vrf bitmaps ignore VRF_UNKNOWN id.
Because of this, the following problems occur when the VRF doesn't exist:
- repeated "redistribute smth" command is processed as a first-time
instead of an update
- "no redistribute smth" doesn't work at all
This commit fixes both issues by relying on internal redistribution
config instead of zclient vrf bitmaps.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Found a couple spots where FRR was using `case default` when
using a switch over an enum. In this case we *must* enumerate
all states as part of the switch.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Description:
DR information is missing under "show ip ospf interface [json]".
Added DR infomation to display in "show ip ospf interface".
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
This fixes 2 asan errors:
If we only have a TLV_ROUTER_ADDR don't continue after we skipped it.
Fixed length when parsing EXT_TLV_LINK_SIZE.
Signed-off-by: Erik Kooistra <me@erikkooistra.nl>
`config.h` has all the defines from autoconf, which may include things
that switch behavior of other included headers (e.g. _GNU_SOURCE
enabling prototypes for additional functions.)
So, the first include in any `.c` file must be either `config.h` (with
the appropriate guard) or `zebra.h` (which includes `config.h` first
thing.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Currently this flag is only helpful in an extremely rare situation when
the BFD session registration was unsuccessful and after that zebra is
restarted. Let's remove this flag to simplify the API. If we ever want
to solve the problem of unsuccessful registration/deregistration, this
can be done using internal flags, without API modification.
Also add the error log to help user understand why the BFD session is
not working.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
`CFLAGS` is a "user variable", not intended to be controlled by
configure itself. Let's put all the "important" stuff in AC_CFLAGS and
only leave debug/optimization controls in CFLAGS.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
... by referencing all autogenerated headers relative to the root
directory. (90% of the changes here is `version.h`.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Description:
All matching external routes are added to matching external hash table
of aggregate route when aggregation is enabled.
But these external info pointers are not delinked from this hash table
before freeing the corresponding memory while disabling redistribution.
Addressing these memory issues in this change.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Currently, if NSSA area is configured before redistribution is enabled,
Type-7 LSA's are installed and flooded. But if NSSA area is configured
after redistribution is enabled, Type-7 LSA's are not installed.
With this change, when NSSA area is configured, schedule a task that
scans for external LSA's. If they exist, install Type-7 and flood to
all NSSA Areas.
There already was an attempt to fix this problem in 0f321812f where
ospf_asbr_nssa_redist_task() was triggered in ospf_abr_task_timer().
This turns out to be incorrect place for this operation because it's
a one-off operation needed only after "area <ID> nssa" execution. And
ospf_abr_task_timer() is a periodic operation. Triggering
ospf_asbr_nssa_redist_task() in ospf_abr_task_timer() caused a problem
that was fixed in 945eec2b6 making the problem with NSSA area
configured after redistribution actual again.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Most of these are many, many years out of date. All of them vary
randomly in quality. They show up by default in packages where they
aren't really useful now that we use integrated config. Remove them.
The useful ones have been moved to the docs.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
The interface parameters deletion must be called before
`route_table_finish` due to the usage of the route data structures to
search neighbors in the same interface. If the route info is removed
before that we get the following crash:
```
6 0x00007f5c6ed50394 in core_handler at lib/sigevent.c:255
7 <signal handler called>
8 ospf_interface_bfd_apply (ifp=<optimized out>) at ospfd/ospf_bfd.c:130
9 0x000055d4c306d076 in ospf_interface_disable_bfd at ospfd/ospf_bfd.c:159
10 0x000055d4c3071781 in ospf_del_if_params at ospfd/ospf_interface.c:553
11 0x000055d4c3071900 in ospf_if_delete_hook at ospfd/ospf_interface.c:704
12 0x00007f5c6ed17935 in hook_call_if_del at lib/if.c:59
13 if_delete_retain at lib/if.c:290
14 0x00007f5c6ed19bc5 in if_delete at lib/if.c:313
15 0x00007f5c6ed19d88 in if_terminate at lib/if.c:1067
16 0x00007f5c6ed63a04 in vrf_delete at lib/vrf.c:297
17 0x00007f5c6ed76784 in zclient_vrf_delete at lib/zclient.c:1974
18 zclient_read at lib/zclient.c:3686
19 0x00007f5c6ed60f85 in thread_call at lib/thread.c:1815
20 0x00007f5c6ed20228 in frr_run at lib/libfrr.c:1149
21 0x000055d4c306bc70 in main at ospfd/ospf_main.c:233
```
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Allow over-write of message-digest-key interface config. Most
attributes handle multi-instance by ... ignoring instances,
and tolerating repeated config: do the same for md5 auth.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
When you set OSPF hello-interval for an interface and dead-interval is
not set for this interface, dead-interval will be calculated and set
automatically. "show running-config" will contain an invalid command:
test(config)# interface vpp1
test(config-if)# ip ospf area 0
test(config-if)# ip ospf hello-interval 1
test(config-if)# exit
test(config)#
test(config)# do show running-config
...
interface if1
ip ospf area 0
ip ospf dead-interval minimal hello-multiplier 0
ip ospf hello-interval 1
!
...
It causes frr-reload.py to fail because of this:
# vtysh -c "show running-config no-header" | vtysh -m -f -
line 9: % Unknown command: ip ospf dead-interval minimal hello-multiplier 0
...
With this change, output "ip ospf dead-interval" only if it has value
configured explicitly.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
When ip nhrp map multicast is being used, this is usually accompanied by an
iptables rule to block the original multicast packet. This causes sendmsg to
return EPERM.
Signed-off-by: Reuben Dowle <reuben.dowle@4rf.com>
This commit introduces the implementation for the north-bound
callbacks for the ospfd-specific route-map match and set clauses.
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
Signed-off-by: Sarita Patra <saritap@vmware.com>
Instead of trying to maintain if_ospf_cli_count, let's directly count
the number of configured interfaces when it is needed. Current approach
sometimes leads to an incorrect counter.
Fixes#8321.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Description:
OSPF does not have an option to control the maximum multiple
equal cost paths to reach a destination/route(ECMP).
Currently, it is using the system specific max multiple paths.
But Somtimes, It requires to control the multiple paths from ospf.
This cli helps to configure the max number multiple paths in ospf.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
This command will trigger the OSPF forwarding address suppression in
translated type-5 LSAs, causing a NSSA ABR to use 0.0.0.0 as a forwarding
address instead of copying the address from the type-7 LSA
Example: In a topology like: R1 --- R2(ABR) --- R3(ASBR)
R3 is announcing a type-7 LSA that is translated to type-5 by the R2 ABR.
The forwarding address in the type-5 is by default copied from the type-7
r1# sh ip os da external
AS External Link States
LS age: 6
Options: 0x2 : *|-|-|-|-|-|E|-
LS Flags: 0x6
LS Type: AS-external-LSA
Link State ID: 3.3.3.3 (External Network Number)
Advertising Router: 10.0.25.2
LS Seq Number: 80000001
Checksum: 0xcf99
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 10.0.23.3 <--- address copied from type-7 lsa
External Route Tag: 0
r2# sh ip os database
NSSA-external Link States (Area 0.0.0.1 [NSSA])
Link ID ADV Router Age Seq# CkSum Route
3.3.3.3 10.0.23.3 8 0x80000001 0x431d E2 3.3.3.3/32 [0x0]
AS External Link States
Link ID ADV Router Age Seq# CkSum Route
3.3.3.3 10.0.25.2 0 0x80000001 0xcf99 E2 3.3.3.3/32 [0x0]
r2# conf t
r2(config)# router ospf
r2(config-router)# area 1 nssa suppress-fa
r2(config-router)# exit
r2(config)# exit
r2# sh ip os database
NSSA-external Link States (Area 0.0.0.1 [NSSA])
Link ID ADV Router Age Seq# CkSum Route
3.3.3.3 10.0.23.3 66 0x80000001 0x431d E2 3.3.3.3/32 [0x0]
AS External Link States
Link ID ADV Router Age Seq# CkSum Route
3.3.3.3 10.0.25.2 16 0x80000002 0x0983 E2 3.3.3.3/32 [0x0]
r1# sh ip os da external
OSPF Router with ID (11.11.11.11)
AS External Link States
LS age: 34
Options: 0x2 : *|-|-|-|-|-|E|-
LS Flags: 0x6
LS Type: AS-external-LSA
Link State ID: 3.3.3.3 (External Network Number)
Advertising Router: 10.0.25.2
LS Seq Number: 80000002
Checksum: 0x0983
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0 <--- address set to 0
External Route Tag: 0
r2# conf t
r2(config)# router ospf
r2(config-router)# no area 1 nssa suppress-fa
r2(config-router)# exit
r1# sh ip os da external
OSPF Router with ID (11.11.11.11)
AS External Link States
LS age: 1
Options: 0x2 : *|-|-|-|-|-|E|-
LS Flags: 0x6
LS Type: AS-external-LSA
Link State ID: 3.3.3.3 (External Network Number)
Advertising Router: 10.0.25.2
LS Seq Number: 80000003
Checksum: 0xcb9b
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0 <--- address set to 0
External Route Tag: 0
r2# conf t
r2(config)# router ospf
r2(config-router)# no area 1 nssa suppress-fa
r2(config-router)# exit
r1# sh ip os da external
OSPF Router with ID (11.11.11.11)
AS External Link States
LS age: 1
Options: 0x2 : *|-|-|-|-|-|E|-
LS Flags: 0x6
LS Type: AS-external-LSA
Link State ID: 3.3.3.3 (External Network Number)
Advertising Router: 10.0.25.2
LS Seq Number: 80000003
Checksum: 0xcb9b
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 10.0.23.3 <--- address copied from type-7 lsa
External Route Tag: 0
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
This patch allows to store Link State Information received through the various
LSAs into a dedicated Traffic Engineering Database (TED). This feature is
automatically activated once mpls-te is enabled.
A new CLI command `mpls-te export` permits to export the TED to other daemons
through the new ZAPI Opaque Link State messages. In complement, a new CLI
command `show ip ospf mpls-te database ...` output the contains of the TED to
the console.
Major modifications take place in ospf_te.[c, h]. File ospf_zebra.c has been
modified to handle TED synchronisation request.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
This patch corrects two problems that affect Inter-AS LSA:
1/ Inter-LSA are never flood due to an incorrect setting of specific flag.
2/ When looking to the detail of the OSPF LSA with the command
`show ip ospf database opaque-xxx`, it appears that only the Inter-AS
advertising router is abble to show the detail of the Inter-AS LSA. Foreign
routers are only abble to show the header of this Inster-AS LSA. The problem
comes from the registration of Inter-AS management functions which is done
only on the advetising router. So, the function `ospf_mpls_te_show_info()` is
never call on neighbor routers that have not resgistered Inter-AS management
callback functions.
First, this patch modify functions `set_linkparams_inter_as()` and
`unset_linkparams_inter_as()` to respectively set and unset flags that control
the Inter-AS LSA flooding. Flag & Type from `struct mpls_te_link` have been
redefined: Flag is used to determine if flooding is AS or not and Type is only
used to determine the type of the LSA.
Second, this patch register Inter-AS management functions for both AS and Area
flooding with a different function for LSA origination as parameter is passed
as void and it is mandatory to determine the flooding context:
`struct *ospf` for AS flooding and `struct *ospf_area` for Area flooding.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
When an interface goes down, if it is MPLS-TE enabled, the corresponding
TE Opaque LSA is not flushed and continue to be advertised.
The problem is due to bugs in ISM and NSM handler functions of ospf_te.c file:
- ospf_mpls_te_ism_change():
- flag associated with Link Parameters is reset
- ISM_Down state is not correctly handle
- ospf_mpls_te_nsm_change():
- flag associated with Link Parameters is reset
- NSM_Down and NSM_Delete states are not handle
This patch correct this problem.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Current implementation of commands `show_ip_ospf_instance_database_cmd`
and `show_ip_ospf_instance_database_type_adv_router_cmd` have the
following problems:
- they doesn't have "vrf all" argument, however the processing of this
argument is implemented,
- they incorrectly implement json output for instances - they don't
output anything to the vty and don't release the json object.
To fix the problems, let's do the following:
1. Split `show_ip_ospf_instance_database_cmd` into two aliases to
`show_ip_ospf_database_max_cmd` and `show_ip_ospf_instance_database_max_cmd`.
The code is the same and doesn't need to be duplicated.
2. Split `show_ip_ospf_instance_database_type_adv_router_cmd` into two
separate functions - one regular and one for instances, which now
correctly implements the processing for json output.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Back when I put this together in 2015, ISO C11 was still reasonably new
and we couldn't require it just yet. Without ISO C11, there is no
"good" way (only bad hacks) to require a semicolon after a macro that
ends with a function definition. And if you added one anyway, you'd get
"spurious semicolon" warnings on some compilers...
With C11, `_Static_assert()` at the end of a macro will make it so that
the semicolon is properly required, consumed, and not warned about.
Consistently requiring semicolons after "file-level" macros matches
Linux kernel coding style and helps some editors against mis-syntax'ing
these macros.
Signed-off-by: David Lamparter <equinox@diac24.net>
The point of the `-std=gnu99` was to override a `-std=c99` that may be
coming in from net-snmp. However, we want C11, not C99.
Signed-off-by: David Lamparter <equinox@diac24.net>
This patch solves 2 Segment Routing prefix bugs:
- If Segment Routing is not enabled in the initial configuration, Extended
Prefix Opaque LSA is not flood. This is due to a control flag which is
set only when Segment Routing is enabled at startup and not latter.
- Attempting to modify Segment Routing prefix flag e.g. adding or removing
no-php or explicit-null flag, doesn't work as expected: Corresponding entry
in the MPLS table is not updated, Extended Prefix Opaque LSA carry wrong flag
value, and neighbor set a wrong configuration in the MPLS table for this
Segment Routing prefix.
The first bug is corrected in ospfd/ospf_ext.c:
- Flag setting is moved from ospf_ext_ism_change() to set_ext_prefix() function
The seconf one is corrected in ospfd/ospf_sr.c:
- For self node, previous MPLS entry is removed if needed and flag reset before
setting the new Segment Routing prefix configuration
- For neighbor node, srnext field of sr_prefix structure is always set and not
only for new SR Prefix.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Store instance index at startup and use it when processing vty commands.
The instance itself may be created and deleted by the user in runtime
using `[no] router ospf X` command.
Fixes#7908
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Neither tabs nor newlines are acceptable in syslog messages. They also
break line-based parsing of file logs.
Signed-off-by: David Lamparter <equinox@diac24.net>
Replaces some hard-coded function names with __func__,
adds some additional references to neighbor/interface,
and cleans up some debug strings to be more readable.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Issue #7926 hilight a race condition in Segment Routing processing.
The problem occurs when Router Information Opaque LSA is received late, in
particular after SPF run and after ospf_sr_nhlfe_update() was called. This
scenario is unfrequent and takes place due to a slow DR election.
In this particular case, SR Prefix are handle but not fully fill. In fact,
SRGB for the nexthop is not yet received and thus, output label could not
be computed.
When Router Information Opaque LSA is received and processed, if the
corresponding SR node is a direct neighbor of the self node, update_out_nhlfe()
is called against all SR nodes to adjust SR prefix if the next hop is the new
SR node. The function wrongly computes output label and configure a bad MPLS
LFIB entries.
Another way to hilight the problem is to change through CLI the SRGB of a node
and look to MPLS LFIB of direct neighbor, in particular those who announce
EXPLICIT NULL Prefix SID.
This patch correct the update_out_nhlfe() function by calling the appropriate
function (sr_prefix_out_label() instead of index2label()) to compute the output
label.
Some log debugs were adjusted and unused prefix route table was removed too.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Currently if the sysctl net.ipv4.raw_l3mdev_accept is 1, packets
destined to a specific vrf also end up being delivered to the default
vrf. We will see logs like this in ospf:
2021/02/10 21:17:05.245727 OSPF: ospf_recv_packet: fd 20(default) on interface 1265(swp1s1.26)
2021/02/10 21:17:05.245740 OSPF: Hello received from [9.9.36.12] via [swp1s1.26:200.254.26.13]
2021/02/10 21:17:05.245741 OSPF: src [200.254.26.14],
2021/02/10 21:17:05.245743 OSPF: dst [224.0.0.5]
2021/02/10 21:17:05.245769 OSPF: ospf_recv_packet: fd 45(vrf1036) on interface 1265(swp1s1.26)
2021/02/10 21:17:05.245774 OSPF: Hello received from [9.9.36.12] via [swp1s1.26:200.254.26.13]
2021/02/10 21:17:05.245775 OSPF: src [200.254.26.14],
2021/02/10 21:17:05.245777 OSPF: dst [224.0.0.5]
This really really makes ospf unhappy in the vrf we are running in.
I am approaching the problem by just dropping the packet if read in the
default vrf because of:
commit 0556fc33c7
Author: Donald Sharp <sharpd@cumulusnetworks.com>
Date: Fri Feb 1 11:54:59 2019 -0500
lib: Allow bgp to always create a listen socket for the vrf
Effectively if we have `router ospf vrf BLUE` but no ospf running
in the default vrf, we will not have a listener and that would
require a fundamental change in our approach to handle the ospf->fd
at a global level. I think this is less than ideal at the moment
but it will get us moving again and allow FRR to work with
a bunch of vrf's and ospf neighbors.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Valgrind reports:
469901-==469901==
469901-==469901== Conditional jump or move depends on uninitialised value(s)
469901:==469901== at 0x3A090D: bgp_bfd_dest_update (bgp_bfd.c:416)
469901-==469901== by 0x497469E: zclient_read (zclient.c:3701)
469901-==469901== by 0x4955AEC: thread_call (thread.c:1684)
469901-==469901== by 0x48FF64E: frr_run (libfrr.c:1126)
469901-==469901== by 0x213AB3: main (bgp_main.c:540)
469901-==469901== Uninitialised value was created by a stack allocation
469901:==469901== at 0x3A0725: bgp_bfd_dest_update (bgp_bfd.c:376)
469901-==469901==
469901-==469901== Conditional jump or move depends on uninitialised value(s)
469901:==469901== at 0x3A093C: bgp_bfd_dest_update (bgp_bfd.c:421)
469901-==469901== by 0x497469E: zclient_read (zclient.c:3701)
469901-==469901== by 0x4955AEC: thread_call (thread.c:1684)
469901-==469901== by 0x48FF64E: frr_run (libfrr.c:1126)
469901-==469901== by 0x213AB3: main (bgp_main.c:540)
469901-==469901== Uninitialised value was created by a stack allocation
469901:==469901== at 0x3A0725: bgp_bfd_dest_update (bgp_bfd.c:376)
On looking at bgp_bfd_dest_update the function call into bfd_get_peer_info
when it fails to lookup the ifindex ifp pointer just returns leaving
the dest and src prefix pointers pointing to whatever was passed in.
Let's do two things:
a) The src pointer was sometimes assumed to be passed in and sometimes not.
Forget that. Make it always be passed in
b) memset the src and dst pointers to be all zeros. Then when we look
at either of the pointers we are not making decisions based upon random
data in the pointers.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Valgrind reports:
2174600-==2174600==
2174600-==2174600== Syscall param write(buf) points to uninitialised byte(s)
2174600:==2174600== at 0x49C7FB3: write (write.c:26)
2174600-==2174600== by 0x48A4EA0: buffer_write (buffer.c:475)
2174600-==2174600== by 0x4915AD9: zclient_send_message (zclient.c:298)
2174600-==2174600== by 0x12DB97: ospf_ldp_sync_state_req_msg (ospf_ldp_sync.c:114)
2174600-==2174600== by 0x12E4F0: ospf_ldp_sync_if_start (ospf_ldp_sync.c:160)
2174600-==2174600== by 0x12E4F0: ospf_ldp_sync_ism_change (ospf_ldp_sync.c:339)
2174600-==2174600== by 0x12E4F0: ospf_ldp_sync_ism_change (ospf_ldp_sync.c:332)
2174600-==2174600== by 0x12C6A2: hook_call_ospf_ism_change (ospf_ism.c:46)
2174600-==2174600== by 0x12C6A2: ism_change_state (ospf_ism.c:540)
2174600-==2174600== by 0x12C6A2: ospf_ism_event (ospf_ism.c:600)
2174600-==2174600== by 0x4904846: thread_call (thread.c:1681)
When we send the request structure we are sending the whole thing and the
interface name string has junk at the end. Not a big deal, but cleans
up valgrind going wumple on us.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The calling function of ospf_nbr_nbma_lookup_next calls
this function and then immediately returns when it
gets the NULL. Just cleanup a bit more code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The #if 0 code in ospfd, has not been compiled since at least
2012. If we are at least 9 years old at this point with no effort
to use or save, we should just get rid of it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Use a pre-built backup path from the post-convergence SPF tree to
make the overall calculation deterministic. This is also a
requirement for non-adjacent P/Q spaces since it's way easier
to organize multiple P and Q spaces using a 'fixed' backup path.
Signed-off-by: GalaxyGorilla <sascha@netdef.org>
When P and Q spaces are adjacent then it makes sense to use adjacency SIDs to
from the P node to the Q node. There are some other corner cases where this
makes also sense like when a P/Q node adjacent to root node.
Signed-off-by: GalaxyGorilla <sascha@netdef.org>
A reverse SPF is important in the context of TI-LFA, e.g. for
computing so called Q spaces. In case the weights of the links are
symmetric there is no difference to the 'normal' SPF and hence this
patch is really just needed for the case with asymmetric link
weights.
Signed-off-by: GalaxyGorilla <sascha@netdef.org>
Topology diagram:
-------------------------
+---+ A0 +---+
+R1 +------------+R2 |
+-+-+- +--++
| -- -- |
| -- A0 -- |
A0| ---- |
| ---- | A0
| -- -- |
| -- -- |
+-+-+- +-+-+
+R0 +-------------+R3 |
+---+ A0 +---+
Steps to reproduce:
--------------------------
1. Bring up the base config as per the topology
2. Configure OSPF on all the routers of the topology.
3. Configure 5 static routes from the same network on R0 , 5 static routes from different networks and redistribute in R0
4. Configure External Route summary in R0 to summarise 5 routes to one route.
5. Delete the configured summary
6. configure the summary again and delete static routes .
7. Add back static routes.
8. Configure new static route which is matching the configured summary.
9. Delete one of the static route.
10. Configure redistribute connected and configure ospf external summary address to summarise the connected routes.
11. Clear ospf process and check for any errors.
[New LWP 2346]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/lib/frr/ospfd'.
Program terminated with signal SIGABRT, Aborted.
54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
0 0x00007f296f278428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
1 0x00007f296f27a02a in __GI_abort () at abort.c:89
2 0x00007f296fca4110 in core_handler (signo=11, siginfo=0x7ffcd52044f0, context=<optimized out>) at lib/sigevent.c:254
3 <signal handler called>
4 0x000055949b9dfdff in ospf_lsdb_lookup (lsdb=lsdb@entry=0x55949bfd3688, lsa=lsa@entry=0x55949bfe1290) at ospfd/ospf_lsdb.c:179
5 0x000055949ba28fbe in ospf_ls_retransmit_lookup (lsa=0x55949bfe1290, nbr=0x55949bfd3610) at ospfd/ospf_flood.c:918
6 ospf_ls_retransmit_delete_nbr_if (oi=oi@entry=0x55949bfd2590, lsa=lsa@entry=0x55949bfe1290) at ospfd/ospf_flood.c:932
7 0x000055949ba2916b in ospf_ls_retransmit_delete_nbr_if (lsa=0x55949bfe1290, oi=0x55949bfd2590) at ospfd/ospf_flood.c:928
8 ospf_ls_retransmit_delete_nbr_as (ospf=ospf@entry=0x55949bfbdb30, lsa=lsa@entry=0x55949bfe1290) at ospfd/ospf_flood.c:959
9 0x000055949b9dcd7e in ospf_discard_from_db (ospf=ospf@entry=0x55949bfbdb30, lsdb=<optimized out>, lsa=lsa@entry=0x55949bfe1630) at ospfd/ospf_lsa.c:2552
10 0x000055949b9df1b3 in ospf_maxage_lsa_remover (thread=0x55949bfde930) at ospfd/ospf_lsa.c:2848
11 0x00007f296fcb1770 in thread_call (thread=0x55949bfde930) at lib/thread.c:1557
12 0x00007f296fcb19d6 in funcname_thread_execute (m=0x55949be0a630, func=func@entry=0x55949b9df0a0 <ospf_maxage_lsa_remover>, arg=arg@entry=0x55949bfbdb30, val=val@entry=0,
funcname=funcname@entry=0x55949ba31b41 "ospf_maxage_lsa_remover", schedfrom=schedfrom@entry=0x55949ba31917 "ospfd/ospf_lsa.c", fromln=3364) at lib/thread.c:1628
13 0x000055949b9de90b in ospf_flush_self_originated_lsas_now (ospf=ospf@entry=0x55949bfbdb30) at ospfd/ospf_lsa.c:3364
14 0x000055949ba19a55 in ospf_process_refresh_data (ospf=0x55949bfbdb30, reset=reset@entry=true) at ospfd/ospfd.c:138
15 0x000055949ba1aeef in ospf_process_reset (ospf=<optimized out>) at ospfd/ospfd.c:206
16 0x000055949ba0729b in clear_ip_ospf_process_magic (self=<optimized out>, vty=<optimized out>, argc=<optimized out>, argv=<optimized out>, instance_str=<optimized out>,
instance=<optimized out>) at ospfd/ospf_vty.c:11930
17 clear_ip_ospf_process (self=<optimized out>, vty=0x55949bfe2600, argc=<optimized out>, argv=<optimized out>) at ./ospfd/ospf_vty_clippy.c:306
18 0x00007f296fc66523 in cmd_execute_command_real (vline=vline@entry=0x55949bfd2fb0, vty=vty@entry=0x55949bfe2600, cmd=cmd@entry=0x0, filter=FILTER_RELAXED) at lib/command.c:1060
19 0x00007f296fc6869a in cmd_execute_command (vline=vline@entry=0x55949bfd2fb0, vty=vty@entry=0x55949bfe2600, cmd=0x0, vtysh=vtysh@entry=0) at lib/command.c:1119
20 0x00007f296fc68817 in cmd_execute (vty=vty@entry=0x55949bfe2600, cmd=cmd@entry=0x55949bfe7f80 "clear ip ospf pro", matched=matched@entry=0x0, vtysh=vtysh@entry=0)
at lib/command.c:1275
21 0x00007f296fcb6c13 in vty_command (vty=vty@entry=0x55949bfe2600, buf=0x55949bfe7f80 "clear ip ospf pro") at lib/vty.c:514
22 0x00007f296fcb6ea6 in vty_execute (vty=vty@entry=0x55949bfe2600) at lib/vty.c:1281
23 0x00007f296fcb97f4 in vtysh_read (thread=<optimized out>) at lib/vty.c:2123
24 0x00007f296fcb1770 in thread_call (thread=thread@entry=0x7ffcd5209590) at lib/thread.c:1557
25 0x00007f296fc82e78 in frr_run (master=0x55949be0a630) at lib/libfrr.c:1026
26 0x000055949b9d0f07 in main (argc=1, argv=0x7ffcd52098b8) at ospfd/ospf_main.c:230
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Implement the below 2 CLIs to clear the current data in the process
and neighbor data structure.
1. clear ip ospf process
2. clear ip ospf neighbor
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
