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>
