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>
The GR code should check for topology changes only upon the receipt
of Router-LSAs and Network-LSAs. Other LSAs types don't affect the
topology as far as a restarting router is concerned.
This optimization reduces unnecessary computations when the
restarting router receives thousands of inter-area LSAs or external
LSAs while coming back up.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Use the already existing mpls label code to store VNI
info for vxlan. VNI's are defined as labels just like mpls,
we should be using the same code for both.
This patch is the first part of that. Next we will need to
abstract the label code to not be so mpls specific. Currently
in this, we are just treating VXLAN as a label type and storing
it that way.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
When using access-list and the access-list is not specified
let's give the operator some clue about what is going on.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
1. When OSPF unnumbered neighbor doesn't exist in any VRF,
OSPFD prints a bunch of empty JSON objects. Fixed it
by adding an outer JSON object with VRF information in it
2. Added "vrf" option to this command so that per VRF
unnumbered OSPF neighbor information can be retrieved
JSON output:
nl1# show ip ospf neighbor swp1 detail json
{
"default":{
},
"vrf1012":{
},
"vrf1013":{
},
"vrf1014":{
}
}
nl1# show ip ospf vrf vrf1012 neighbor swp4.2 detail json
{
"9.9.12.10":[
{
"ifaceAddress":"200.254.2.46",
"areaId":"0.0.0.0",
"ifaceName":"swp4.2",
"localIfaceAddress":"200.254.2.45",
"nbrPriority":1,
"nbrState":"Full",
"role":"DR",
"stateChangeCounter":6,
"lastPrgrsvChangeMsec":1462758,
"routerDesignatedId":"200.254.2.46",
"routerDesignatedBackupId":"200.254.2.45",
"optionsCounter":2,
"optionsList":"*|-|-|-|-|-|E|-",
"routerDeadIntervalTimerDueMsec":37140,
"databaseSummaryListCounter":0,
"linkStateRequestListCounter":0,
"linkStateRetransmissionListCounter":0,
"threadInactivityTimer":"on",
"threadLinkStateRequestRetransmission":"on",
"threadLinkStateUpdateRetransmission":"on"
}
]
}
nl1#
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
Added VRF option to
"show ip ospf [vrf NAME] neighbor X.X.X.X [detail] [json]"
command so that the user can query information regarding a
specific neighbor within a VRF.
r1# show ip ospf vrf default neighbor 10.0.255.2
10.0.255.2 1 Full/- 33m10s 9.891s 10.0.3.2 r1-eth1:10.0.3.4 0 0 0
r1# show ip ospf vrf default neighbor 10.0.255.2 json
{
"10.0.255.2":[
{
"priority":1,
"state":"Full/-",
"nbrPriority":1,
"nbrState":"Full/-",
"converged":"Full",
"role":"DROther",
"upTimeInMsec":13877947,
"deadTimeMsecs":9498,
"routerDeadIntervalTimerDueMsec":9498,
"upTime":"3h51m17s",
"deadTime":"9.498s",
"address":"10.0.3.2",
"ifaceAddress":"10.0.3.2",
"ifaceName":"r1-eth1:10.0.3.4",
"retransmitCounter":0,
"linkStateRetransmissionListCounter":0,
"requestCounter":0,
"linkStateRequestListCounter":0,
"dbSummaryCounter":0,
"databaseSummaryListCounter":0
}
]
}
r1# show ip ospf vrf default neighbor 10.0.255.2 detail
Neighbor 10.0.255.2, interface address 10.0.3.2
In the area 0.0.0.0 via interface r1-eth1 local interface IP 10.0.3.4
Neighbor priority is 1, State is Full/-, Role is DROther, 5 state changes
Most recent state change statistics:
Progressive change 3h51m27s ago
DR is 0.0.0.0, BDR is 0.0.0.0
Options 2 *|-|-|-|-|-|E|-
Dead timer due in 8.458s
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
Graceful restart Helper info:
Graceful Restart HELPER Status : None
r1# show ip ospf vrf default neighbor 10.0.255.2 detail json
{
"10.0.255.2":[
{
"ifaceAddress":"10.0.3.2",
"areaId":"0.0.0.0",
"ifaceName":"r1-eth1",
"localIfaceAddress":"10.0.3.4",
"nbrPriority":1,
"nbrState":"Full/-",
"role":"DROther",
"stateChangeCounter":5,
"lastPrgrsvChangeMsec":13889856,
"routerDesignatedId":"0.0.0.0",
"routerDesignatedBackupId":"0.0.0.0",
"optionsCounter":2,
"optionsList":"*|-|-|-|-|-|E|-",
"routerDeadIntervalTimerDueMsec":9715,
"databaseSummaryListCounter":0,
"linkStateRequestListCounter":0,
"linkStateRetransmissionListCounter":0,
"threadInactivityTimer":"on",
"threadLinkStateRequestRetransmission":"on",
"threadLinkStateUpdateRetransmission":"on",
"grHelperStatus":"None"
}
]
}
r1#
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
"role" and "local interface address" fields were missing in
"show ip ospf neighbor detail" command.
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
When show ip ospf border-routers json (without vrf)
specificed, it leads to crash if there no border-routers
information.
Fix:
Do not free json object if use_vrf flag (means vrf option
is not passed) is not set.
Ticket:#3229017
Issue:3229017
Testing Done:
with fix:
l1# show ip ospf border-routers json
{
}
l1# show ip ospf vrf default border-routers json
{
}
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Don't directly use `time()` for generating sequence numbers for two
reasons:
1. `time()` can go backwards (due to NTP or time adjustments)
2. Coverity Scan warns every time we truncate a `time_t` variable for
good reason (verify that we are Y2K38 ready).
Found by Coverity Scan (CID 1519812, 1519786, 1519783 and 1519772)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Description:
code changes involve changes on abr routers to generate and flush
indication LSAs, on backbone and non-backbone areas in different
scenarios.
Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
Description:
Code changes involves.
1. Count the no.of router LSAs received with DC options bit set,
supporting do not age(DNA).
2. If no of router LSAs received with DC bit set is equal to total
no of LSAs in the router lsdb, then all the routers in the
area support do not age processing.
3. Flood the self originated LSAs with DNA flag if all routers in the area
supports the feature.
4. Stop aging of the LSAs recived with DO_NOT_AGE bit set from
other routers.
5. Self originated DO_NOT_AGE lsas will still be aging in their own
database.
Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
Description:
The changes involve setting DC bit on ospf hellos and
addition of new DO_NOT_AGE flag.
Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
Description:
Code changes involve following things.
1. an additional structure containing flood reduction related info
per area.
2. a knob variable in the ospf structure for enabling/disabling the feature.
3. initialization of above mentioned variables.
Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
a) if show_function happened to be NULL we would leak json memory
b) json_lsa_type was being allocated but only used in the default case, leaking memory
c) json output would sometimes produce text output and that is incorrect
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
After `free()`ing a table also set it to NULL so when the instance
release function is called we know whether the pointer is valid or not.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Fix the following problems:
- Always free vertex next hops on `vertex_parent_free`
- Signalize failure on `ospf_spf_add_parent` when parent already exists
so the caller has the chance to `free()` any allocated resources.
- Don't reuse vertex next hops without the reference count logic in
`ospf_nexthop_calculation`. Instead allocate a new copy so it can be
`free()`d later without complications
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Every 1/2 hour my logs are filling up with this:
2022-11-26 13:54:47.531 [DEBG] ospfd: [P4PQ9-K4XFD] DR-Election[1st]: Backup 192.168.119.229
2022-11-26 13:54:47.531 [DEBG] ospfd: [HBZ7F-65Y86] DR-Election[1st]: DR 192.168.119.229
2022-11-26 13:54:47.531 [DEBG] ospfd: [H01MF-RN00N] DR-Election[2nd]: Backup 0.0.0.0
2022-11-26 13:54:47.531 [DEBG] ospfd: [R7BJ4-KP8JT] DR-Election[2nd]: DR 192.168.119.229
This should be guarded by an if check to ensure that the operator really
wants to see this.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
My log file is filling up with:
2022-11-26 13:24:47.532 [DEBG] ospfd: [RY794-DQ7AK] interface 192.168.119.229 [2] join AllDRouters Multicast group.
Every 1/2 hour. There is nothing an operator needs to do here and nothing
that they can change. Let's guard this output.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Description:
As part of signal handler ospf_finish_final(), lsas are originated
and added to refresh queues are not freed.
One such leak is :
==2869285== 432 (40 direct, 392 indirect) bytes in 1 blocks are definitely lost in loss record 159 of 221
==2869285== at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==2869285== by 0x4910EC3: qcalloc (memory.c:116)
==2869285== by 0x199024: ospf_refresher_register_lsa (ospf_lsa.c:4017)
==2869285== by 0x199024: ospf_refresher_register_lsa (ospf_lsa.c:3979)
==2869285== by 0x19A37F: ospf_network_lsa_install (ospf_lsa.c:2680)
==2869285== by 0x19A37F: ospf_lsa_install (ospf_lsa.c:2941)
==2869285== by 0x19C18F: ospf_network_lsa_update (ospf_lsa.c:1099)
==2869285== by 0x1931ED: ism_change_state (ospf_ism.c:556)
==2869285== by 0x1931ED: ospf_ism_event (ospf_ism.c:596)
==2869285== by 0x494E0B0: thread_call (thread.c:2006)
==2869285== by 0x494E395: _thread_execute (thread.c:2098)
==2869285== by 0x19FBC6: nsm_change_state (ospf_nsm.c:695)
==2869285== by 0x19FBC6: ospf_nsm_event (ospf_nsm.c:861)
==2869285== by 0x494E0B0: thread_call (thread.c:2006)
==2869285== by 0x494E395: _thread_execute (thread.c:2098)
==2869285== by 0x19020B: ospf_if_cleanup (ospf_interface.c:322)
==2869285== by 0x192D0C: ism_interface_down (ospf_ism.c:393)
==2869285== by 0x193028: ospf_ism_event (ospf_ism.c:584)
==2869285== by 0x494E0B0: thread_call (thread.c:2006)
==2869285== by 0x494E395: _thread_execute (thread.c:2098)
==2869285== by 0x190F10: ospf_if_down (ospf_interface.c:851)
==2869285== by 0x1911D6: ospf_if_free (ospf_interface.c:341)
==2869285== by 0x1E6E98: ospf_finish_final (ospfd.c:748)
==2869285== by 0x1E6E98: ospf_deferred_shutdown_finish (ospfd.c:578)
==2869285== by 0x1E7727: ospf_finish (ospfd.c:682)
==2869285== by 0x1E7727: ospf_terminate (ospfd.c:652)
==2869285== by 0x18852B: sigint (ospf_main.c:105)
==2869285== by 0x493BE12: frr_sigevent_process (sigevent.c:130)
==2869285== by 0x494DCD4: thread_fetch (thread.c:1775)
==2869285== by 0x4905022: frr_run (libfrr.c:1197)
==2869285== by 0x187891: main (ospf_main.c:235)
Added a fix to cleanup all these queue pointers and corresponing lsas in it.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Steps to reproduce:
--------------------------
1. ANVL: Establish full adjacency with DUT for neighbor Rtr-0-A on DIface-0 with DUT as DR.
2. ANVL: Listen (for up to 2 * <RxmtInterval> seconds) on DIface-0.
3. DUT: Send <OSPF-LSU> packet.
4. ANVL: Verify that the received <OSPF-LSU> packet contains a Network- LSA for network N1
originated by DUT, and the LS Sequence Number is set to <InitialSequenceNumber>.
5. ANVL: Establish full adjacency with DUT for neighbor Rtr-0-B on DIface-0 with DUT as DR.
6. ANVL: Listen (for up to 2 * <RxmtInterval> seconds) on DIface-0.
7. DUT: Send <OSPF-LSU> packet.
8. ANVL: Verify that the received <OSPF-LSU> packet contains a new instance of the
Network-LSA for network N1 originated by DUT, and the LS Sequence Number
is set to (<InitialSequenceNumber> + 1).
Both the test cases were failing while verifying the initial sequence number for network LSA.
This is because currently OSPF does not reset its LSA sequence number when it is going down.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
OSPF_MAX_LSA_SIZE does not represent the actual maximum size of LSA packets which may be larger than 1500 bytes. If relaying a large OSPF packet to the OSPF API, we do not allocate a big enough buffer to send over the API. This patch increases the maximum size of OSPF packets transmitted over the API.
Signed-off-by: ylopez <yoann.lopez@gmail.com>
When using debug mode, the ei parameter may be NULL. In that
case, do not display the log trace, otherwise a crash will
happen.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Rather than running selected source files through the preprocessor and a
bunch of perl regex'ing to get the list of all DEFUNs, use the data
collected in frr.xref.
This not only eliminates issues we've been having with preprocessor
failures due to nonexistent header files, but is also much faster.
Where extract.pl would take 5s, this now finishes in 0.2s. And since
this is a non-parallelizable build step towards the end of the build
(dependent on a lot of other things being done already), the speedup is
actually noticeable.
Also files containing CLI no longer need to be listed in `vtysh_scan`
since the .xref data covers everything. `#ifndef VTYSH_EXTRACT_PL`
checks are equally obsolete.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
```
(ospf) max-metric router-lsa administrative
```
Currently this running config depends at least one `area` with *active*
`network`, otherwise it will not occur.
The check on this dependency is redundant and wrong, just remove it.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
FRR implements a non-standard, but compatible approach for
sending update LSAs (it always send to 224.0.0.5) on P2MP
interfaces. This change makes it so acks are also sent to
224.0.0.5.
Since the acks are multicast, this allows an optimization
where we don't send back out the incoming P2MP interface
immediately allow time to rx multicast ack from neighbors
on the same net that rx'ed the original (multicast) update.
Signed-off-by: Lou Berger <lberger@labn.net>
When forming a neighbor relationship on an interface, ospf is
currently evaluating unnumbered as highest priority, without
any consideration for if you have /32's and non /32's on the
interface. Effectively if I have something like this:
int foo0
ip address 192.168.119.1/24
!
router ospf
network 0.0.0.0/0 area 0
!
ospf will form a neighbor on foo0 if it exists. Now
suppose someone does this:
int foo0
ip address 192.168.120.1/32
This will create the unnumbered interface on foo0 and
the peering will come down immediately.
The problem here is that the original designers of the unnumbered
code for ospf didn't envision end operators mixing and matching
addresses on an interface like this ( for perfectly legitimate
reasons I might add ).
So if ospf has both numbered and unnumbered let's match against
the numbered first and then unnumbered. This solves the problem
Fixes: #6823
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There are lib debugs being set but never show up in
`show debug` commands because there was no way to show
that they were being used. Add a bit of infrastructure
to allow this and then use it for `debug route-map`
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
It is not possible to build ospf_spf.c file with --disable-ospfapi because
ospf_apiserver.c has SUPPORT_OSPF_API around all function definitions and
that results in an undefined reference to the ospf_apiserver_notify_reachable
function error while building.
Signed-off-by: Michal Ruprich <mruprich@redhat.com>
Description:
Added hidden clis that will allow you to reset the default timers
for LSA refresh and LSA maxage remove delay, these will help in testing
LSA refresh scenarios in upcoming OSPFv2 Flood reduction feature(rfc4136).
IETF Link : https://datatracker.ietf.org/doc/html/rfc4136
Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
Description:
ospf process is crashing when the current router acts
as GR helper and it received a new lsa.
Here, ospf_lsa_different() is being called without checking
'old' pointer. It is asserted in ospf_lsa_different() api
if the 'old' pointer is NULL.
corrected this by validaing old pointer before calling
ospf_lsa_different() api.
back tarce:
Program terminated with signal SIGABRT, Aborted.
0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
[Current thread is 1 (Thread 0x6b84348827c0 (LWP 3155))]
0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
1 0x00006b8433aa4801 in __GI_abort () at abort.c:79
2 0x00006b8433a9439a in __assert_fail_base (fmt=0x6b8433c1b7d8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x162ffc0630bc "l1", file=file@entry=0x162ffc062ff7 "ospfd/ospf_lsa.c", line=line@entry=3520, function=function@entry=0x162ffc0646f0 <__PRETTY_FUNCTION__.18732> "ospf_lsa_different") at assert.c:92
3 0x00006b8433a94412 in __GI___assert_fail (assertion=assertion@entry=0x162ffc0630bc "l1", file=file@entry=0x162ffc062ff7 "ospfd/ospf_lsa.c", line=line@entry=3520, function=function@entry=0x162ffc0646f0 <__PRETTY_FUNCTION__.18732> "ospf_lsa_different") at assert.c:101
4 0x0000162ffc008c25 in ospf_lsa_different (l1=l1@entry=0x0, l2=l2@entry=0x162ffe535c60, ignore_rcvd_flag=ignore_rcvd_flag@entry=true) at ospfd/ospf_lsa.c:3520
5 0x0000162ffc00a8e8 in ospf_lsa_install (ospf=ospf@entry=0x162ffe513650, oi=oi@entry=0x162ffe531c30, lsa=lsa@entry=0x162ffe535c60) at ospfd/ospf_lsa.c:2892
6 0x0000162ffc059d16 in ospf_flood (ospf=0x162ffe513650, nbr=nbr@entry=0x162ffe52cc90, current=current@entry=0x0, new=new@entry=0x162ffe535c60) at ospfd/ospf_flood.c:429
7 0x0000162ffc01838f in ospf_ls_upd (size=<optimized out>, oi=0x162ffe531c30, s=<optimized out>, ospfh=<optimized out>, iph=<optimized out>, ospf=<optimized out>) at ospfd/ospf_packet.c:2162
8 ospf_read_helper (ospf=<optimized out>) at ospfd/ospf_packet.c:3241
9 ospf_read (thread=<optimized out>) at ospfd/ospf_packet.c:3272
10 0x00006b843450139c in thread_call (thread=thread@entry=0x7780f42c7480) at lib/thread.c:1692
11 0x00006b84344cfb18 in frr_run (master=0x162ffe34d130) at lib/libfrr.c:1068
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Description:
Per neighbor GR enabled information is missing from json
output in "show ip ospf gr helper details json" command.
Example config:
frr(config-router)# graceful-restart helper enable 2.2.2.2
frr(config-router)#
frr(config-router)# do show ip ospf graceful-restart helper detail
OSPF Router with ID (10.112.156.220)
Graceful restart helper support disabled.
Strict LSA check is enabled.
Helper supported for Planned and Unplanned Restarts.
Supported Graceful restart interval: 1800(in seconds).
Enable Router list:
2.2.2.2,
frr(config-router)# do show ip ospf graceful-restart helper detail json
{
"routerId":"10.112.156.220",
"helperSupport":"Disabled",
"strictLsaCheck":"Enabled",
"restartSupoort":"Planned and Unplanned Restarts",
"supportedGracePeriod":1800,
}
frr(config-router)#
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
When a neighbor goes down on an interface and that interface
has no more neighbors in a viable state where packets should
be being sent, then let's clear up the oi->obuf associated
with the interface the neighbor is on.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
ospf_write pulls an interface off the ospf->oi_write_q
then writes one packet and places it back on the queue,
keeping track of the first one sent. Then it will
stop sending packets even if we get back to the first
interface written too but before we have sent the full
pkt_count. I do not believe this makes a whole bunch
of sense and is very restrictive of how much data can
be sent especially if you have a limited number of peers
but large amounts of data. Why be so restrictive?
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In ospf_handle_exnl_lsa_lsId_chg there is a code path
where that we may be using uninitialized data for decisions.
Doubtful that this happens but let's make it less likely to
even more.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Let's just use THREAD_OFF consistently in the code base
instead of each daemon having a special macro that needs to
be looked at and remembered what it does.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Before this patch we can enable 'ip ospf bfd' via '[no] ip ospf bfd profile ...' commads.
After patch '[no] ip ospf bfd profile ...' actual only if 'ip ospf bfd' is set.
Signed-off-by: Dmitrii Turlupov <dturlupov@factor-ts.ru>
Description:
timerval data structure 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:
"show ip ospf neighbour [nbrid] [json]" is expected to give brief output
of the specific neighbour. But it gives the detailed output without
the detail keyword.
"show ip ospf neighbour [nbrid] [deatil] [json]" command is failed to
fetch the ecpected o/p. Corrected it.
Ex o/p:
frr(config-if)# do show ip ospf neighbor
Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
8.8.8.8 1 Full/DR 17m03s 31.192s 20.1.1.194 ens192:20.1.1.220 0 0 0
30.1.1.100 1 Full/DR 56.229s 32.000s 30.1.1.100 ens224:30.1.1.220 0 0 0
frr(config-if)#
frr(config-if)#
frr(config-if)# do show ip ospf neighbor 8.8.8.8
Neighbor 8.8.8.8, interface address 20.1.1.194
In the area 0.0.0.0 via interface ens192
Neighbor priority is 1, State is Full/DR, 6 state changes
Most recent state change statistics:
Progressive change 17m18s ago
DR is 20.1.1.194, BDR is 20.1.1.220
Options 2 *|-|-|-|-|-|E|-
Dead timer due in 35.833s
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
Graceful restart Helper info:
Graceful Restart HELPER Status : None
frr(config-if)# do show ip ospf neighbor 8.8.8.8 detail
No such interface.
frr(config-if)# do show ip ospf neighbor 8.8.8.8 detail json
{}
frr(config-if)#
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
This extra newline was adding a weird output to `show debugging`
display where there would be extra newlines sometims and not
others. Make it consistent.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
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>
