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>
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>
