1. Fix ospf opaque LSA function table memory leak.
2. Remove incorrect one-to-one association of OSPF info-per-type
to function table (since there many be many).
3. Fix a problem with opaque AS external cleanup that was exposed
by #2.
4. Fix LSA memory leak in ospf_opaque_type9_lsa_if_cleanup().
Signed-off-by: Acee <aceelindem@gmail.com>
Traffic Engineering Database (TED) is fulfill from the various LSA advertised
and received by the router. To remove information on the TED, 2 mechanisms are
used: i) parse TE Opaque LSA when there are flushed and ii) compare the list of
prefixes advertised in the Router LSA with the list of corresponding edges and
subnets contained in the TED. However, this second mechanism assumes that the
Router LSA is unique and contains all prefixes of the advertised router.
But, this is wrong. Prefixes could be advertised with several Router LSA.
This conduct to remove edge and subnet in the TED while it should be maintained.
The result is a faulty test with ospf_sr_te_topo1 topotest when server is heavy
loaded.
This simple patch removed deletion of edges and subnets when parsing the Router
LSA and only removed them when the corresponding TE Opaque LSA is flushed. In
addition, TE Opaque LSA are not flushed when OSPF ajacency goes down. This
patch also correct this second problem.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Segment Router Identifier (SID) could be an index (4 bytes) within a range
(SRGB or SRLB) or an MPLS label (3 bytes). Thus, before calling check_size
macro to verify SID TLVs size, it is mandatory to determine the SID type to
avoid wrong assert.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
The ospfd cleanup code is relatively complicated given the need to
appropriately handle the "max-metric router-lsa on-shutdown (5-100)"
command. When that command is configured and an OSPF instance is
unconfigured, the removal of the instance should be deferred to allow
other routers sufficient time to find alternate paths before the
local Router-LSAs are flushed. When ospfd is killed, however, deferred
shutdown shouldn't take place and all instances should be cleared
immediately.
This commit fixes a problem where ospf_deferred_shutdown_finish()
was prematurely exiting the daemon when no instances were left,
inadvertently preventing ospf_terminate() from clearing the ospfd
global variables. Additionally, the commit includes code refactoring
to enhance readability and maintainability.
Fixes#14855.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
* On ospf_terminate(), proceed to clear the ospfd global variables even
when no OSPF instance is configured
* Remove double call to route_map_finish()
* Call ospf_opaque_term() to clear the opaque LSA infrastructure
* Clear the `OspfRI.area_info` and `om->ospf` global lists.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
1. When an OSPF interface is deleted, remove the references in link-local
LSA. Delete the LSA from the LSDB so that the callback has accessibily
to the interface prior to deletion.
2. Fix a double free for the opaque function table data structure.
3. Assure that the opaque per-type information and opaque function table
structures are removed at the same time since they have back pointers
to one another.
4. Add a topotest variation for the link-local opaque LSA crash.
Signed-off-by: Acee <aceelindem@gmail.com>
... and use it instead of fiddling with the `.synchronous` field.
(Make it const while at it.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Replace `struct list *` with `DLIST(if_connected, ...)`.
NB: while converting this, I found multiple places using connected
prefixes assuming they were IPv4 without checking:
- vrrpd/vrrp.c: vrrp_socket()
- zebra/irdp_interface.c: irdp_get_prefix(), irdp_if_start(),
irdp_advert_off()
(these fixes are really hard to split off into separate commits as that
would require going back and reapplying the change but with the old list
handling)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
INTERFACE_NAMSIZ is just a redefine of IFNAMSIZ and IFNAMSIZ
is the standard for interface name length on all platforms
that FRR currently compiles on.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Fix for the command "show ip ospf vrf NAME graceful-restart helper".
FRR did not show information by vrf's name.
If i have router ospf vrf red, vtysh's command
'show ip ospf vrf red graceful-restart helper' will not show anything.
But command 'show ip ospf vrf all graceful-restart helper' will work
normally. This fix fixes the display of information by vrf's name.
Example:
frr1# show ip ospf vrf vrf-1 graceful-restart helper
VRF Name: vrf-1
OSPF Router with ID (192.168.255.81)
Graceful restart helper support enabled.
Strict LSA check is enabled.
Helper supported for Planned and Unplanned Restarts.
Supported Graceful restart interval: 1800(in seconds).
Signed-off-by: teletajp <teletajp@yandex.ru>
...so that multiple functions can be subscribed.
The create/destroy hooks are renamed to real/unreal because that's what
they *actually* signal.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
```
r1# sh ipv6 ospf6 summary-address
VRF Name: default
aggregation delay interval :5(in seconds)
```
Just hit this random and looks ugly, let's fix it.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Modify empty json object to take input obj
instead of allocating always one.
There are situation where in error condition or no data
case print empty json (`{}`) with already allocated
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Also:
- replace all /* fallthrough */ comments with portable fallthrough;
pseudo keyword to accomodate both gcc and clang
- add missing break; statements as required by older versions of gcc
- cleanup some code to remove unnecessary fallthrough
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The problem was happening because the ospf->oiflist has this behaviour, each interface was removed and added at the end of the list in each ospf_network_run_subnet call, generation an infinite loop.
As a solution, a copy of the list was generated and we interacted with a fixed list.
Signed-off-by: Rodrigo Nardi <rnardi@netdef.org>
Currently when one interface changes its VRF, zebra will send these messages to
all daemons in *order*:
1) `ZEBRA_INTERFACE_DELETE` ( notify them delete from old VRF )
2) `ZEBRA_INTERFACE_VRF_UPDATE` ( notify them move from old to new VRF )
3) `ZEBRA_INTERFACE_ADD` ( notify them added into new VRF )
When daemons deal with `VRF_UPDATE`, they use
`zebra_interface_vrf_update_read()->if_lookup_by_name()`
to check the interface exist or not in old VRF. This check will always return
*NULL* because `DELETE` ( deleted from old VRF ) is already done, so can't
find this interface in old VRF.
Send `VRF_UPDATE` is redundant and unuseful. `DELETE` and `ADD` are enough,
they will deal with RB tree, so don't send this `VRF_UPDATE` message when
vrf changes.
Since all daemons have good mechanism to deal with changing vrf, and don't
use this `VRF_UPDATE` mechanism. So, it is safe to completely remove
all the code with `VRF_UPDATE`.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
This patch includes:
* Implementation of RFC 5709 support in OSPF. Using
openssl library and FRR key-chain,
one can use SHA1, SHA256, SHA384, SHA512 and
keyed-MD5( backward compatibility with RFC 2328) HMAC algs.
* Updating documentation of OSPF
* add topotests for new HMAC algorithms
Signed-off-by: Mahdi Varasteh <varasteh@amnesh.ir>
Fixes a memory leak in ospfd where the external aggregator
was not released after its associated route node is deleted.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in ospf_basic_functionality.test_ospf_asbr_summary_topo1/r0.asan.ospfd.31502
=================================================================
==31502==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 200 byte(s) in 5 object(s) allocated from:
#0 0x7fdb30665d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fdb300620da in qcalloc lib/memory.c:105
#2 0x55e53c2da5fa in ospf_external_aggregator_new ospfd/ospf_asbr.c:396
#3 0x55e53c2dead3 in ospf_asbr_external_aggregator_set ospfd/ospf_asbr.c:1123
#4 0x55e53c27c921 in ospf_external_route_aggregation ospfd/ospf_vty.c:10264
#5 0x7fdb2ffe5428 in cmd_execute_command_real lib/command.c:993
#6 0x7fdb2ffe58ec in cmd_execute_command lib/command.c:1051
#7 0x7fdb2ffe5d6b in cmd_execute lib/command.c:1218
#8 0x7fdb3010ce2a in vty_command lib/vty.c:591
#9 0x7fdb3010d2d5 in vty_execute lib/vty.c:1354
#10 0x7fdb30115b9b in vtysh_read lib/vty.c:2362
#11 0x7fdb30100b99 in event_call lib/event.c:1979
#12 0x7fdb30045379 in frr_run lib/libfrr.c:1213
#13 0x55e53c1ccab4 in main ospfd/ospf_main.c:249
#14 0x7fdb2f65dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7fdb30665d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fdb300620da in qcalloc lib/memory.c:105
#2 0x55e53c2da5fa in ospf_external_aggregator_new ospfd/ospf_asbr.c:396
#3 0x55e53c2dedd3 in ospf_asbr_external_rt_no_advertise ospfd/ospf_asbr.c:1182
#4 0x55e53c27cf10 in ospf_external_route_aggregation_no_adrvertise ospfd/ospf_vty.c:10626
#5 0x7fdb2ffe5428 in cmd_execute_command_real lib/command.c:993
#6 0x7fdb2ffe58ec in cmd_execute_command lib/command.c:1051
#7 0x7fdb2ffe5d6b in cmd_execute lib/command.c:1218
#8 0x7fdb3010ce2a in vty_command lib/vty.c:591
#9 0x7fdb3010d2d5 in vty_execute lib/vty.c:1354
#10 0x7fdb30115b9b in vtysh_read lib/vty.c:2362
#11 0x7fdb30100b99 in event_call lib/event.c:1979
#12 0x7fdb30045379 in frr_run lib/libfrr.c:1213
#13 0x55e53c1ccab4 in main ospfd/ospf_main.c:249
#14 0x7fdb2f65dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 240 byte(s) leaked in 6 allocation(s).
***********************************************************************************
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Addressed a memory leak in OSPF by fixing the improper deallocation of
area range nodes when removed from the table. Introducing a new function,
`ospf_range_table_node_destroy` for proper node cleanup, resolved the issue.
The ASan leak log for reference:
```
Direct leak of 56 byte(s) in 2 object(s) allocated from:
#0 0x7faf661d1d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7faf65bce1e9 in qcalloc lib/memory.c:105
#2 0x55a66e0b61cd in ospf_area_range_new ospfd/ospf_abr.c:43
#3 0x55a66e0b61cd in ospf_area_range_set ospfd/ospf_abr.c:195
#4 0x55a66e07f2eb in ospf_area_range ospfd/ospf_vty.c:631
#5 0x7faf65b51548 in cmd_execute_command_real lib/command.c:993
#6 0x7faf65b51f79 in cmd_execute_command_strict lib/command.c:1102
#7 0x7faf65b51fd8 in command_config_read_one_line lib/command.c:1262
#8 0x7faf65b522bf in config_from_file lib/command.c:1315
#9 0x7faf65c832df in vty_read_file lib/vty.c:2605
#10 0x7faf65c83409 in vty_read_config lib/vty.c:2851
#11 0x7faf65bb0341 in frr_config_read_in lib/libfrr.c:977
#12 0x7faf65c6cceb in event_call lib/event.c:1979
#13 0x7faf65bb1488 in frr_run lib/libfrr.c:1213
#14 0x55a66dfb28c4 in main ospfd/ospf_main.c:249
#15 0x7faf651c9c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 56 byte(s) leaked in 2 allocation(s).
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Consider this config:
router ospf
redistribute kernel
Then you issue:
no router ospf
ospf will crash with a use after free.
The problem is that the event's associated with the
ospf pointer were shut off then the ospf_external_delete
was called which rescheduled the event. Let's just move
event deletion to the end of the no router ospf.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In scenarios where no backup paths are available, ensure proper
memory management by deleting `q_space->vertex_list`. This prevents
memory leaks.
The ASan leak log for reference:
```
Direct leak of 80 byte(s) in 2 object(s) allocated from:
#0 0x7fcf8c70aa37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fcf8c2a8a45 in qcalloc ../lib/memory.c:105
#2 0x7fcf8c27d0cc in list_new ../lib/linklist.c:49
#3 0x55d6e8385e35 in ospf_spf_init ../ospfd/ospf_spf.c:540
#4 0x55d6e838c30d in ospf_spf_calculate ../ospfd/ospf_spf.c:1736
#5 0x55d6e83933cf in ospf_ti_lfa_generate_q_spaces ../ospfd/ospf_ti_lfa.c:673
#6 0x55d6e8394214 in ospf_ti_lfa_generate_p_space ../ospfd/ospf_ti_lfa.c:812
#7 0x55d6e8394c63 in ospf_ti_lfa_generate_p_spaces ../ospfd/ospf_ti_lfa.c:923
#8 0x55d6e8396390 in ospf_ti_lfa_compute ../ospfd/ospf_ti_lfa.c:1101
#9 0x55d6e838ca48 in ospf_spf_calculate_area ../ospfd/ospf_spf.c:1811
#10 0x55d6e838cd73 in ospf_spf_calculate_areas ../ospfd/ospf_spf.c:1840
#11 0x55d6e838cfb0 in ospf_spf_calculate_schedule_worker ../ospfd/ospf_spf.c:1871
#12 0x7fcf8c3922e4 in event_call ../lib/event.c:1979
#13 0x7fcf8c27c828 in frr_run ../lib/libfrr.c:1213
#14 0x55d6e82eeb6d in main ../ospfd/ospf_main.c:249
#15 0x7fcf8bd59d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Coverity is complaining that listnode can return a NULL
value and thus FRR could derefence the returned value.
Since this is not crashing we know that this is not happening
in the wild. Let's make this an assert or check that it is
legal to use the value.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently, when changing ABR type on a working router, SPF recalculation
will only be initiated if the OSPF flags have changed after this.
Otherwise, SPF recalculation will be omitted and OSPF RIB update will
not occur. In other words, changing ABR type might not result in
inter-area routes addition/deletion.
With this fix, when ABR type is changed, the command handler initiates
SPF recalculation.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Include an event ptr-to-ptr in the event_execute() api
call, like the various schedule api calls. This allows the
execute() api to cancel an existing scheduled task if that
task is being executed inline.
Signed-off-by: Mark Stapp <mjs@labn.net>
Currently, when redistribution of routes was configured, external LSAs
were already advertised to peers, and then default-metric is changed,
external LSAs refresh will not occur. In other words, the peers will not
receive the refreshed external LSAs with the new metric.
With this fix, changing default-metric will cause external LSAs to be
refreshed and flooded.
There is a similar task to refresh external LSAs when NSSA settings are
changed. And there is a function that accomplishes it -
ospf_schedule_asbr_nssa_redist_update(). Since the function does the
general work of refreshing external LSAs and is not specific to NSSA
settings, the idea is to give it a more general name and call it when
default-metric changes in order to fix the problem.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
User can now use 'show ip ospf route detail' command to distinguish
intra-area stub network and transit network.
Transit network will be displayed as 'N T prefix ...'.
NOTICE: Json output format has been changed, intra-area transit networks
will have a new attribute 'transit' and value is 'true'.
And 'adv' (means advertise router) change to 'advertisedRouter'.
Example output:
bsp-debianrt-exp1# show ip ospf route detail
Codes: N - network T - transitive
IA - inter-area E - external route
D - destination R - router
============ OSPF network routing table ============
N T 10.0.0.0/24 [32] area: 0.0.0.0
via 192.168.124.67, ens192
adv 10.0.0.5
N 10.0.30.0/24 [33] area: 0.0.0.0
via 192.168.124.67, ens192
adv 10.0.0.5
...
Signed-off-by: Zhiyuan Wan <h@iloli.bid>
The ospfd mistakenly copy advertise router from vertex->id, which may
not be correct in an OSPF transit network.
Signed-off-by: Zhiyuan Wan <h@iloli.bid>
Some fixes for the per-interface write sockets: better align
opening and closing them with ospf config actions; set
read buffer to zero since these sockets are used only for
writing packets.
Signed-off-by: Mark Stapp <mjs@labn.net>
Add support for "[no] ip ospf capbility opaque" at the interface
level with the default being capability opaque enabled. The command
"no ip ospf capability opaque" will disable opaque LSA database
exchange and flooding on the interface. A change in configuration
will result in the interface being flapped to update our options
for neighbors but no attempt will be made to purge existing LSAs
as in dense topologies, these may received by neighbors through
different interfaces.
Topotests are added to test both the configuration and the LSA
opaque flooding suppression.
Signed-off-by: Acee <aceelindem@gmail.com>
When running all daemons with config for most of them, FRR has
sharpd@janelle:~/frr$ vtysh -c "show debug hashtable" | grep "VRF BIT HASH" | wc -l
3570
3570 hashes for bitmaps associated with the vrf. This is a very
large number of hashes. Let's do two things:
a) Reduce the created size of the actually created hashes to 2
instead of 32.
b) Delay generation of the hash *until* a set operation happens.
As that no hash directly implies a unset value if/when checked.
This reduces the number of hashes to 61 in my setup for normal
operation.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
interface link update event needs
to be handle properly in ospf interface
cache.
Example:
When vrf (interface) is created its default type
would be set to BROADCAST because ifp->status
is not set to VRF.
Subsequent link event sets ifp->status to vrf,
ospf interface update need to compare current type
to new default type which would be VRF (OSPF_IFTYPE_LOOPBACK).
Since ospf type param was created in first add event,
ifp vrf link event didn't update ospf type param which
leads to treat vrf as non loopback interface.
Ticket:#3459451
Testing Done:
Running config suppose to bypass rendering default
network broadcast for loopback/vrf types.
Before fix:
vrf vrf1
vni 4001
exit-vrf
!
interface vrf1
ip ospf network broadcast
exit
After fix: (interface vrf1 is not displayed).
vrf vrf1
vni 4001
exit-vrf
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Change timestamp parameter from int to time_t to avoid truncation.
Found by Coverity Scan (CID 1563226 and 1563222)
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The rn variable has its info attribute being replaced with a new ospf route before being freed properly.
Signed-off-by: ryndia <dindyalsarvesh@gmail.com>
Re-added the old JSON hierarchy for "show ip ospf interface json"
command in addition to new, so that the scripts don't break.
Old hierarchy will be deprecated after a year.
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
Currently, delayed reflooding on P2MP interfaces for LSAs received
from neighbors on the interface is unconditionally (see commit
c706f0e32b). In some cases, this
change wasn't desirable and this feature makes delayed reflooding
configurable for P2MP interfaces via the CLI command:
"ip ospf network point-to-multipoint delay-reflood" in interface
submode.
Signed-off-by: Acee <aceelindem@gmail.com>
When setting an loopback's cost, set the value to 0, unless the operator
has assigned a value for the loopback's cost.
RFC states:
If the state of the interface is Loopback, add a Type 3
link (stub network) as long as this is not an interface
to an unnumbered point-to-point network. The Link ID
should be set to the IP interface address, the Link Data
set to the mask 0xffffffff (indicating a host route),
and the cost set to 0.
FRR is going to allow this to be overridden if the operator specifically
sets a value too.
Fixes: #13472
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The new create range attribute is send to add to ranges, but not use if the prefix already exist in the ranges.
Signed-off-by: ryndia <dindyalsarvesh@gmail.com>
1. Fix OSPF opaque LSA processing to preserve the stale opaque
LSAs in the Link State Database for 60 seconds consistent with
what is done for other LSA types.
2. Add a topotest that tests for cases where ospfd is restarted
and a stale OSPF opaque LSA exists in the OSPF routing domain
both when the LSA is purged and when the LSA is reoriginagted
with a more recent instance.
Signed-off-by: Acee <aceelindem@gmail.com>
This command makes unplanned GR more reliable by manipulating the
sending of Grace-LSAs and Hello packets for a certain amount of time,
increasing the chance that the neighboring routers are aware of
the ongoing graceful restart before resuming normal OSPF operation.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
In practical terms, unplanned GR refers to the act of recovering
from a software crash without affecting the forwarding plane.
Unplanned GR and Planned GR work virtually the same, except for the
following difference: on planned GR, the router sends the Grace-LSAs
*before* restarting, whereas in unplanned GR the router sends the
Grace-LSAs immediately *after* restarting.
For unplanned GR to work, ospf6d was modified to send a
ZEBRA_CLIENT_GR_CAPABILITIES message to zebra as soon as GR is
enabled. This causes zebra to freeze the OSPF routes in the RIB as
soon as the ospfd daemon dies, for as long as the configured grace
period (the defaults is 120 seconds). Similarly, ospfd now stores in
non-volatile memory that GR is enabled as soon as GR is configured.
Those two things are no longer done during the GR preparation phase,
which only happens for planned GRs.
Unplanned GR will only take effect when the daemon is killed
abruptly (e.g. SIGSEGV, SIGKILL), otherwise all OSPF routes will
be uninstalled while ospfd is exiting. Once ospfd starts, it will
check whether GR is enabled and enter in the GR mode if necessary,
sending Grace-LSAs out all operational interfaces.
One disadvantage of unplanned GR is that the neighboring routers
might time out their corresponding adjacencies if ospfd takes too
long to come back up. This is especially the case when short dead
intervals are used (or BFD). For this and other reasons, planned
GR should be preferred whenever possible.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
FRR has a memory leak in the case when int X does not
exist and a memory leak when int X does exist. Fix
these
Fixes: #13434
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Ospf segfault when Router Information is enabled in a non default VRF,
see issue #13144.
This patch forces vrf_id to default VRF for Opaque LSA and extension based
on Opaque LSA: Router Information, Traffic Engineering, Extended Prefix,
Extended Link and Segment Routing. Indeed, non default VRF is not yet
supported for Opaque LSA & co.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
When using route maps with external routes in OSPF as follows:
```
set metric +10
```
The current behavior is to use the default ospf metric as the base and then add
to 10 to it. The behavior isn't useful as-is. A value 30 (20 dfeault + 10) can
be set directly instead. the behavior is also not consistent with bgp. bgp does
use the rib metric in this case as the base. The current behavior also doesn't
allow the metric to accumulate when crossing different routing domains such as
vrfs causing the metric to reset every time the route enters a new vrf with a new
ospf network.
This PR changes the behavior such that the rib metric is used as a base for
ospf exteral routes when used with `set metric -/+`
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
Add support for a write socket per interface, enabled by
default at the ospf instance level. An ospf instance-level
config allows this to be disabled, reverting to the older
behavior where a single per-instance socket is used for
sending and receiving packets.
Signed-off-by: Mark Stapp <mjs@labn.net>
The date for removing some deprecated json attributes from
'show neighbor' has arrived, so remove the attrs (and the
CPP_NOTICE block).
Signed-off-by: Mark Stapp <mjs@labn.net>
Following the modification of the edge key in link state database
this patch updates the ospf_te.c file to replace the old uint64_t edge key by
the new ls_edge_key structure. For ospf, only IPv4 address is take into
account.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
When passing a prefix into a function let's pass by address instead
of pass by value. Let's save our stack space.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
ospf neighbor DR and BDR router-id wrongly displays with interface
ip-address instead of router-id.
It is fixed to display the correct DR & BDR router-id for
JSON and CLI commands.
Commands:
```
show ip ospf vrf <vrf-name> neighbor detail json
show ip ospf vrf <vrf-name> neighbor detail
```
Before Fix:-
```
r1# show ip ospf vrf default neighbor swp1 detail
Neighbor 0.0.0.17, interface address 11.0.0.1
In the area 0.0.0.0 via interface swp1 local interface IP 11.0.0.2
Neighbor priority is 1, State is Full, Role is DR, 6 state changes
Most recent state change statistics:
Progressive change 1d15h05m ago
DR is 11.0.0.1, BDR is 11.0.0.2 ======> DR and BDR shows the intef &
local intf ipaddress
Options 2 *|-|-|-|-|-|E|-
Dead timer due in 35.178s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on
r1#
r1# show ip ospf vrf default neighbor swp1 detail json
{
"0.0.0.17":[
{
"ifaceAddress":"11.0.0.1",
"areaId":"0.0.0.0",
"ifaceName":"swp1",
"localIfaceAddress":"11.0.0.2",
"nbrPriority":1,
"nbrState":"Full",
"role":"DR",
"stateChangeCounter":6,
"lastPrgrsvChangeMsec":141141533,
"routerDesignatedId":"11.0.0.1", =============> interface ip
instead of DR rotuer-id
"routerDesignatedBackupId":"11.0.0.2", =======> lo-interface ip
instead of BDR rotuer-id
"optionsCounter":2,
"optionsList":"*|-|-|-|-|-|E|-",
"routerDeadIntervalTimerDueMsec":32272,
"databaseSummaryListCounter":0,
"linkStateRequestListCounter":0,
"linkStateRetransmissionListCounter":0,
"threadInactivityTimer":"on",
"threadLinkStateRequestRetransmission":"on",
"threadLinkStateUpdateRetransmission":"on"
}
]
}
r1#
```
After Fix:-
```
r1# show ip ospf vrf default neighbor detail json
{
"default":{
"vrfName":"default",
"vrfId":0,
"neighbors":{
"0.0.0.17":[
{
"ifaceAddress":"11.0.0.1",
"areaId":"0.0.0.0",
"ifaceName":"swp1",
"localIfaceAddress":"11.0.0.2",
"nbrPriority":1,
"nbrState":"Full",
"role":"DR",
"stateChangeCounter":6,
"lastPrgrsvChangeMsec":4531505,
"routerDesignatedId":"0.0.0.17", =====> DR Router-Id
"routerDesignatedBackupId":"0.0.0.12", =====> BDR Router-Id
"optionsCounter":2,
"optionsList":"*|-|-|-|-|-|E|-",
"routerDeadIntervalTimerDueMsec":38495,
"databaseSummaryListCounter":0,
"linkStateRequestListCounter":0,
"linkStateRetransmissionListCounter":0,
"threadInactivityTimer":"on",
"threadLinkStateRequestRetransmission":"on",
"threadLinkStateUpdateRetransmission":"on"
}
],
"0.0.0.13":[
{
"ifaceAddress":"11.0.2.2",
"areaId":"0.0.0.0",
"ifaceName":"swp2",
"localIfaceAddress":"11.0.2.1",
"nbrPriority":1,
"nbrState":"Full",
"role":"DR",
"stateChangeCounter":6,
"lastPrgrsvChangeMsec":4522182,
"routerDesignatedId":"0.0.0.13", =====> DR Router-Id
"routerDesignatedBackupId":"0.0.0.12", =====> BDR Router-Id
"optionsCounter":2,
"optionsList":"*|-|-|-|-|-|E|-",
"routerDeadIntervalTimerDueMsec":37840,
"databaseSummaryListCounter":0,
"linkStateRequestListCounter":0,
"linkStateRetransmissionListCounter":0,
"threadInactivityTimer":"on",
"threadLinkStateRequestRetransmission":"on",
"threadLinkStateUpdateRetransmission":"on"
}
],
"0.0.0.14":[
{
"ifaceAddress":"11.0.3.2",
"areaId":"0.0.0.0",
"ifaceName":"swp3",
"localIfaceAddress":"11.0.3.1",
"nbrPriority":1,
"nbrState":"Full",
"role":"DR",
"stateChangeCounter":6,
"lastPrgrsvChangeMsec":4522182,
"routerDesignatedId":"0.0.0.14", =====> DR Router-Id
"routerDesignatedBackupId":"0.0.0.12", =====> BDR Router-Id
"optionsCounter":2,
"optionsList":"*|-|-|-|-|-|E|-",
"routerDeadIntervalTimerDueMsec":37840,
"databaseSummaryListCounter":0,
"linkStateRequestListCounter":0,
"linkStateRetransmissionListCounter":0,
"threadInactivityTimer":"on",
"threadLinkStateRequestRetransmission":"on",
"threadLinkStateUpdateRetransmission":"on"
}
]
}
}
}
r1#
r1# show ip ospf vrf default neighbor swp1 detail
Neighbor 0.0.0.17, interface address 11.0.0.1
In the area 0.0.0.0 via interface swp1 local interface IP 11.0.0.2
Neighbor priority is 1, State is Full, Role is DR, 6 state changes
Most recent state change statistics:
Progressive change 1h18m11s ago
DR is 0.0.0.17, BDR is 0.0.0.12 =======> correct DR and BDR
router-id
Options 2 *|-|-|-|-|-|E|-
Dead timer due in 38.339s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on
r1#
r1# show ip ospf vrf default neighbor swp
swp1 swp2 swp3 swp4
r1# show ip ospf vrf default neighbor swp2 detail
Neighbor 0.0.0.13, interface address 11.0.2.2
In the area 0.0.0.0 via interface swp2 local interface IP 11.0.2.1
Neighbor priority is 1, State is Full, Role is DR, 6 state changes
Most recent state change statistics:
Progressive change 12m02s ago
DR is 0.0.0.13, BDR is 0.0.0.12 =======> correct DR and BDR
router-id
Options 2 *|-|-|-|-|-|E|-
Dead timer due in 37.136s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on
r1#
```
Ticket:#3395270
Issue:3395270
Testing: UT done
Signed-off-by: Sindhu Parvathi Gopinathan's <sgopinathan@nvidia.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 A.B.C.D/M [<not-advertise|cost (0-16777215)>]
Example:
router ospf
router-id 1.1.1.1
area 1 nssa
area 1 nssa range 172.16.0.0/16
area 1 nssa range 10.1.0.0/16
!
Since regular area ranges and NSSA ranges have a lot in common,
this commit reuses the existing infrastructure for area ranges as
much as possible to avoid code duplication.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
* Update the "range" helpers to accept an area pointer instead of
an area ID;
* Always call ospf_area_display_format_set() after every "range"
command to ensure consistency.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
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>
Combine all variation of the "area nssa" command into a single
DEFPY to improve code maintainability.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Whenever OSPF virtual-link is created, a virtual interface is
associated with it. Name of the virtual interface is derived by
combining "VLINK" string with the value of vlink_count, which is a global
variable.
Problem:
Consider a scenario where 2 virtual links A and B are created in OSPF with
virtual interfaces VLINK0 and VLINK1 respectively. When virtual-link A is unconfigured
and reconfigured, new interface name derived for it will be VLINK1, which is already
associated with virtual-link B. Due to this, both virtual-links A and B will
point to the same interface, VLINK1.
During FRR restart when signal handler is called, OSPF goes through all the virtual
links and deletes the interface(oi) associated with it. During the deletion of interface
for virtual-link B,it accesses the interface which was deleted already(which was deleted
during deletion of virual-link A) and whose fields were set to NULL. This
leads to OSPF crash.
Fixed it by not decrementing vlink_count during unconfig/deletion for virtual-link.
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
All the event changes exposed a bunch of places where
we were not properly following our standards. Just
clean them up in one big fell swoop.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Effectively a massive search and replace of
`struct thread` to `struct event`. Using the
term `thread` gives people the thought that
this event system is a pthread when it is not
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This is a first in a series of commits, whose goal is to rename
the thread system in FRR to an event system. There is a continual
problem where people are confusing `struct thread` with a true
pthread. In reality, our entire thread.c is an event system.
In this commit rename the thread.[ch] files to event.[ch].
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Problem:
Multiple memory leaks after pr12366
RCA:
ospf_lsa_unlock was not happening for the few of the LSAs in
ospf_lsa_refresh_walker after pr12366 due to which memory
related to lsas was leaking.
Fix:
Moved the ospf_lsa_unlock outside if check.
Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
Add a hash_clean_and_free() function as well as convert
the code to use it. This function also takes a double
pointer to the hash to set it NULL. Also it cleanly
does nothing if the pointer is NULL( as a bunch of
code tested for ).
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Description:
After area range config, summary lsas are aggerated to configured
route but later it was being flushed instead of the actual summary
lsa. This was seen when prefix-id of the aggregated route is same
as one of the actual summary route.
Here, aggregated summary lsa need to be returned to set the flag
SUMMARY_APPROVE after originating aggregated summary lsa but its not.
Which is being cleaned up as part of unapproved summary cleanup.
Corrected this now.
Issue: #13028
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
As it can be seen below, the LSDB JSON output varies depending
whether a filter option is specified or not (e.g. "adv-router",
"self-originate"):
> show ip ospf database router json
{
"routerId":"3.3.3.3",
"routerLinkStates":{
"areas":{
"0.0.0.0":[
{
"lsaAge":175,
"options":"*|-|-|-|-|-|E|-",
[snip]
> show ip ospf database router adv-router 2.2.2.2 json
{
"routerId":"3.3.3.3",
"Router Link States":{
"0.0.0.0":{
"2.2.2.2":{
"lsaAge":193,
"options":"*|-|-|-|-|-|E|-",
[snip]
This inconsistency is undesirable since it makes this data harder to
consume programmatically. Also, in the second output, "Router Link
States" is used as a JSON key, which doesn't conform to our JSON
guidelines (JSON keys need to be camelCased).
Make the required changes to ensure the first output structure is used,
regardless if any output filter is used or not.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This option is useful to dump detailed information about the LSDB using
a single command (instead of one command per LSA type).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Combine all variations of this command into a single DEFPY to
improve maintainability. No behavioral changes intended.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Description:
OSPF ABR will summarise the networks based on configured range
and re-advtertise the summarised route. But if configured range
prefix id is same as one of the subset of routes prefix id then
as per rcf2328 Appendex-E recommendation, it will prepare the LSID and originate.
While re-advertising, it is using ospf LSDB instead of area specific
LSDB which is making it fail to re-advertise the summary lsa.
Fixed this by passing correct LSDB pointer.
Issue: #12995
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Fix obvious bug where the wrong area filter-lists were being updated
in response to a prefix-list update.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
