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