summaryrefslogtreecommitdiff
path: root/ospfd/ospf_vty.c
AgeCommit message (Collapse)Author
2024-09-13ospfd: fix missing '[no]ip ospf graceful-restart hello-delay <N>' commandsDmitrii Turlupov
Signed-off-by: Dmitrii Turlupov <turlupov@bk.ru> (cherry picked from commit 69e31a547f8520fd967cc34dc0cd3a8f915d07f8)
2024-05-08Merge pull request #15953 from FRRouting/mergify/bp/stable/9.1/pr-15846Donatas Abraitis
ospfd: fix the bug where ip_ospf_dead-interval_minimal_hello-multiplier did not reset hello timer (backport #15846)
2024-05-07ospfd:fix the bug where ip_ospf_dead-interval_minimal_hello-multiplier did ↵Bing Shui
not reset hello timer Signed-off-by: Bing Shui <652023330037@smail.nju.edu.cn> (cherry picked from commit d733fe2c048cd75948d9f30ced77ed828e92ee18)
2024-04-29vtysh: Show `ip ospf network ...` even if it's not the same as the interface ↵Donatas Abraitis
type ospfv3 shows this unconditionally, and ospfv2 does not show `ip ospf network ...` if the type of the interface matches the specified network. Fixes: https://github.com/FRRouting/frr/issues/15817 Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-12-14ospfd: fix ospf dead-interval minimal hello-multiplier param rangeBing Shui
Signed-off-by: Bing Shui <652023330037@smail.nju.edu.cn> (cherry picked from commit a1793303c0e8a531812f4176b62ff2ebf9ef9539)
2023-11-21ospfd: fix show_ip_ospf_gr_helperteletajp
Fix for the command "show ip ospf vrf NAME graceful-restart helper". FRR did not show information by vrf's name. If i have router ospf vrf red, vtysh's command 'show ip ospf vrf red graceful-restart helper' will not show anything. But command 'show ip ospf vrf all graceful-restart helper' will work normally. This fix fixes the display of information by vrf's name. Example: frr1# show ip ospf vrf vrf-1 graceful-restart helper VRF Name: vrf-1 OSPF Router with ID (192.168.255.81) Graceful restart helper support enabled. Strict LSA check is enabled. Helper supported for Planned and Unplanned Restarts. Supported Graceful restart interval: 1800(in seconds). Signed-off-by: teletajp <teletajp@yandex.ru> (cherry picked from commit 62754e102965ed0cef1d0d8819514391e6629e3e)
2023-10-30ospfd, ospf6d: Fix spacing nit for `show ... summary-address` commandDonatas Abraitis
``` r1# sh ipv6 ospf6 summary-address VRF Name: default aggregation delay interval :5(in seconds) ``` Just hit this random and looks ugly, let's fix it. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org> (cherry picked from commit ed2b5937207e60a523a4029bd24836660ecde5c9)
2023-09-16[ospfd]: add support for RFC 5709 HMAC-SHA AuthMahdi Varasteh
This patch includes: * Implementation of RFC 5709 support in OSPF. Using openssl library and FRR key-chain, one can use SHA1, SHA256, SHA384, SHA512 and keyed-MD5( backward compatibility with RFC 2328) HMAC algs. * Updating documentation of OSPF * add topotests for new HMAC algorithms Signed-off-by: Mahdi Varasteh <varasteh@amnesh.ir>
2023-07-25ospfd: fix SPF calculation when changing ABR typeAlexander Chernavin
Currently, when changing ABR type on a working router, SPF recalculation will only be initiated if the OSPF flags have changed after this. Otherwise, SPF recalculation will be omitted and OSPF RIB update will not occur. In other words, changing ABR type might not result in inter-area routes addition/deletion. With this fix, when ABR type is changed, the command handler initiates SPF recalculation. Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
2023-07-25Merge pull request #14056 from achernavin22/ospf-fix-def-metric-updRuss White
ospfd: fix default-metric change if external LSAs already sent
2023-07-21Merge pull request #14034 from LabNConsulting/aceelindem/ospf_prefix_suppressionDonatas Abraitis
ospfd: Implement OSPF prefix-suppression as specified in RFC 6860
2023-07-20ospfd: Implement OSPF prefix-suppression as specified in RFC 6860Acee
Signed-off-by: Acee <aceelindem@gmail.com>
2023-07-19ospfd: fix default-metric change if external LSAs already sentAlexander Chernavin
Currently, when redistribution of routes was configured, external LSAs were already advertised to peers, and then default-metric is changed, external LSAs refresh will not occur. In other words, the peers will not receive the refreshed external LSAs with the new metric. With this fix, changing default-metric will cause external LSAs to be refreshed and flooded. There is a similar task to refresh external LSAs when NSSA settings are changed. And there is a function that accomplishes it - ospf_schedule_asbr_nssa_redist_update(). Since the function does the general work of refreshing external LSAs and is not specific to NSSA settings, the idea is to give it a more general name and call it when default-metric changes in order to fix the problem. Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
2023-07-18ospfd: Support show intra-area network type in 'show ip ospf route' commandZhiyuan Wan
User can now use 'show ip ospf route detail' command to distinguish intra-area stub network and transit network. Transit network will be displayed as 'N T prefix ...'. NOTICE: Json output format has been changed, intra-area transit networks will have a new attribute 'transit' and value is 'true'. And 'adv' (means advertise router) change to 'advertisedRouter'. Example output: bsp-debianrt-exp1# show ip ospf route detail Codes: N - network T - transitive IA - inter-area E - external route D - destination R - router ============ OSPF network routing table ============ N T 10.0.0.0/24 [32] area: 0.0.0.0 via 192.168.124.67, ens192 adv 10.0.0.5 N 10.0.30.0/24 [33] area: 0.0.0.0 via 192.168.124.67, ens192 adv 10.0.0.5 ... Signed-off-by: Zhiyuan Wan <h@iloli.bid>
2023-07-18ospfd: Support show advertise router in 'show ip ospf route' commandZhiyuan Wan
Users can now use 'show ip ospf route [detail]' command to show the originator of each OSPF route item. Signed-off-by: Zhiyuan Wan <h@iloli.bid>
2023-07-11Merge pull request #13691 from ↵Russ White
LabNConsulting/aceelindem/ospf-opaque-interface-disable ospfd: Configurable interface-level 'capability opaque' support
2023-07-03ospfd: Ensure `show ip ospf interface` json code is guardedDonald Sharp
When not using json, do not allocate json memory. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-06-30ospfd: check for NULLs in vty codeMark Stapp
There were a couple of cli paths that NULL-checked in the vtysh output path, but not in the json path. Signed-off-by: Mark Stapp <mjs@labn.net>
2023-06-28 ospfd: Configurable interface-level 'capability opaque' supportAcee
Add support for "[no] ip ospf capbility opaque" at the interface level with the default being capability opaque enabled. The command "no ip ospf capability opaque" will disable opaque LSA database exchange and flooding on the interface. A change in configuration will result in the interface being flapped to update our options for neighbors but no attempt will be made to purge existing LSAs as in dense topologies, these may received by neighbors through different interfaces. Topotests are added to test both the configuration and the LSA opaque flooding suppression. Signed-off-by: Acee <aceelindem@gmail.com>
2023-05-26ospfd: re-added old json hierarchy for ospf intf jsonPooja Jagadeesh Doijode
Re-added the old JSON hierarchy for "show ip ospf interface json" command in addition to new, so that the scripts don't break. Old hierarchy will be deprecated after a year. Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
2023-05-24ospfd: fix json object name for newly added fieldsPooja Jagadeesh Doijode
Fixed the JSON object name for "grHelloDelaySecs" and "p2mpDelayReflood" JSON fields. Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
2023-05-24ospfd: fix the json object namePooja Jagadeesh Doijode
Fixed the JSON object name for "drId" and "drAddress" JSON fields Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
2023-05-24ospfd: add oi to show ip ospf interface jsonTrey Aspelund
Currently "show ip ospf interface json" will walk all oi's bound to a given interface, but every oi overwrites the same json keys. This adds a new hierarchy to the json output which will allow each oi to have its info displayed separately (instead of stomping on each other). Before: ``` tor-11# show ip ospf interface swp2 json { "interfaces":{ "swp2":{ "ifUp":true, "ifIndex":4, "mtuBytes":9216, "bandwidthMbit":10000, "ifFlags":"<UP,BROADCAST,RUNNING,MULTICAST>", "ospfEnabled":true, "ipAddress":"100.64.3.15", "ipAddressPrefixlen":24, "ospfIfType":"Broadcast", "localIfUsed":"100.64.3.255", "area":"0.0.0.1", "routerId":"6.0.0.15", "networkType":"NBMA", "cost":10, "transmitDelaySecs":1, "state":"Backup", "priority":100, "bdrId":"6.0.0.15", "bdrAddress":"100.64.3.15", "mcastMemberOspfAllRouters":true, "timerMsecs":10000, "timerDeadSecs":40, "timerWaitSecs":40, "timerRetransmitSecs":5, "timerHelloInMsecs":2502, "nbrCount":1, "nbrAdjacentCount":1 } } } ``` After: ``` leaf-12# show ip ospf interface swp3 json { "interfaces":{ "swp3":{ "ifUp":true, "ifIndex":5, "mtuBytes":9216, "bandwidthMbit":10000, "ifFlags":"<UP,BROADCAST,RUNNING,MULTICAST>", "ospfEnabled":true, "interfaceIp":{ "100.64.2.6":{ "ipAddress":"100.64.2.6", "ipAddressPrefixlen":24, "ospfIfType":"Broadcast", "localIfUsed":"100.64.2.255", "area":"0.0.0.0", "routerId":"6.0.0.6", "networkType":"NBMA", "cost":10, "transmitDelaySecs":1, "state":"DR", "priority":2, "bdrId":"6.0.0.15", "bdrAddress":"100.64.2.15", "networkLsaSequence":2147483652, "mcastMemberOspfAllRouters":true, "timerMsecs":10000, "timerDeadSecs":40, "timerWaitSecs":40, "timerRetransmitSecs":5, "timerHelloInMsecs":1559, "nbrCount":1, "nbrAdjacentCount":1 }, "100.64.3.6":{ "ipAddress":"100.64.3.6", "ipAddressPrefixlen":24, "ospfIfType":"Broadcast", "localIfUsed":"100.64.3.255", "area":"0.0.0.1", "routerId":"6.0.0.6", "networkType":"NBMA", "cost":10, "transmitDelaySecs":1, "state":"DR", "priority":222, "bdrId":"6.0.0.15", "bdrAddress":"100.64.3.15", "networkLsaSequence":2147483651, "mcastMemberOspfAllRouters":true, "timerMsecs":10000, "timerDeadSecs":40, "timerWaitSecs":40, "timerRetransmitSecs":5, "timerHelloInMsecs":1559, "nbrCount":1, "nbrAdjacentCount":1 } } } } } ``` Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
2023-05-22ospfd: OSPF P2MP Delayed Reflooding configurationAcee
Currently, delayed reflooding on P2MP interfaces for LSAs received from neighbors on the interface is unconditionally (see commit c706f0e32ba8aa8780a0618b6fbba364c383ae05). In some cases, this change wasn't desirable and this feature makes delayed reflooding configurable for P2MP interfaces via the CLI command: "ip ospf network point-to-multipoint delay-reflood" in interface submode. Signed-off-by: Acee <aceelindem@gmail.com>
2023-05-08ospfd, ospf6d: introduce the "graceful-restart hello-delay" commandRenato Westphal
This command makes unplanned GR more reliable by manipulating the sending of Grace-LSAs and Hello packets for a certain amount of time, increasing the chance that the neighboring routers are aware of the ongoing graceful restart before resuming normal OSPF operation. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2023-05-08ospfd: add support for unplanned graceful restartRenato Westphal
In practical terms, unplanned GR refers to the act of recovering from a software crash without affecting the forwarding plane. Unplanned GR and Planned GR work virtually the same, except for the following difference: on planned GR, the router sends the Grace-LSAs *before* restarting, whereas in unplanned GR the router sends the Grace-LSAs immediately *after* restarting. For unplanned GR to work, ospf6d was modified to send a ZEBRA_CLIENT_GR_CAPABILITIES message to zebra as soon as GR is enabled. This causes zebra to freeze the OSPF routes in the RIB as soon as the ospfd daemon dies, for as long as the configured grace period (the defaults is 120 seconds). Similarly, ospfd now stores in non-volatile memory that GR is enabled as soon as GR is configured. Those two things are no longer done during the GR preparation phase, which only happens for planned GRs. Unplanned GR will only take effect when the daemon is killed abruptly (e.g. SIGSEGV, SIGKILL), otherwise all OSPF routes will be uninstalled while ospfd is exiting. Once ospfd starts, it will check whether GR is enabled and enter in the GR mode if necessary, sending Grace-LSAs out all operational interfaces. One disadvantage of unplanned GR is that the neighboring routers might time out their corresponding adjacencies if ospfd takes too long to come back up. This is especially the case when short dead intervals are used (or BFD). For this and other reasons, planned GR should be preferred whenever possible. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2023-05-04ospfd: Fix memory leaks w/ `show ip ospf int X json` commandsDonald Sharp
FRR has a memory leak in the case when int X does not exist and a memory leak when int X does exist. Fix these Fixes: #13434 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-04-16Merge pull request #13141 from mjstapp/fix_ospf_json_keysDonatas Abraitis
ospfd: remove deprecated json attrs for neighbor show
2023-04-12Merge pull request #13177 from mjstapp/fix_ospf_supoort_typoDonald Sharp
ospf,ospf6: fix json key typo supoort
2023-04-11ospfd: support write socket per interfaceMark Stapp
Add support for a write socket per interface, enabled by default at the ospf instance level. An ospf instance-level config allows this to be disabled, reverting to the older behavior where a single per-instance socket is used for sending and receiving packets. Signed-off-by: Mark Stapp <mjs@labn.net>
2023-04-07ospf,ospf6: fix json key typo supoortMark Stapp
Fix json key 'supoort' -> 'support'; add 1-year deprecation notice; fix topotests to use corrected json key. Signed-off-by: Mark Stapp <mjs@labn.net>
2023-04-07ospfd: remove deprecated json attrs for neighbor showMark Stapp
The date for removing some deprecated json attributes from 'show neighbor' has arrived, so remove the attrs (and the CPP_NOTICE block). Signed-off-by: Mark Stapp <mjs@labn.net>
2023-04-06ospfd: support configuration of socket buffer sizesMark Stapp
Add configurable socket send and receive buffer sizes, configured at the instance level. Signed-off-by: Mark Stapp <mjs@labn.net>
2023-04-04Merge pull request #13160 from chiragshah6/fdev2Russ White
ospfd:display correct DR-BDR router-id in nbr cmd
2023-04-02ospfd:display correct DR-BDR router-id in nbr cmdSindhu Parvathi Gopinathan
ospf neighbor DR and BDR router-id wrongly displays with interface ip-address instead of router-id. It is fixed to display the correct DR & BDR router-id for JSON and CLI commands. Commands: ``` show ip ospf vrf <vrf-name> neighbor detail json show ip ospf vrf <vrf-name> neighbor detail ``` Before Fix:- ``` r1# show ip ospf vrf default neighbor swp1 detail Neighbor 0.0.0.17, interface address 11.0.0.1 In the area 0.0.0.0 via interface swp1 local interface IP 11.0.0.2 Neighbor priority is 1, State is Full, Role is DR, 6 state changes Most recent state change statistics: Progressive change 1d15h05m ago DR is 11.0.0.1, BDR is 11.0.0.2 ======> DR and BDR shows the intef & local intf ipaddress Options 2 *|-|-|-|-|-|E|- Dead timer due in 35.178s Database Summary List 0 Link State Request List 0 Link State Retransmission List 0 Thread Inactivity Timer on Thread Database Description Retransmision off Thread Link State Request Retransmission on Thread Link State Update Retransmission on r1# r1# show ip ospf vrf default neighbor swp1 detail json { "0.0.0.17":[ { "ifaceAddress":"11.0.0.1", "areaId":"0.0.0.0", "ifaceName":"swp1", "localIfaceAddress":"11.0.0.2", "nbrPriority":1, "nbrState":"Full", "role":"DR", "stateChangeCounter":6, "lastPrgrsvChangeMsec":141141533, "routerDesignatedId":"11.0.0.1", =============> interface ip instead of DR rotuer-id "routerDesignatedBackupId":"11.0.0.2", =======> lo-interface ip instead of BDR rotuer-id "optionsCounter":2, "optionsList":"*|-|-|-|-|-|E|-", "routerDeadIntervalTimerDueMsec":32272, "databaseSummaryListCounter":0, "linkStateRequestListCounter":0, "linkStateRetransmissionListCounter":0, "threadInactivityTimer":"on", "threadLinkStateRequestRetransmission":"on", "threadLinkStateUpdateRetransmission":"on" } ] } r1# ``` After Fix:- ``` r1# show ip ospf vrf default neighbor detail json { "default":{ "vrfName":"default", "vrfId":0, "neighbors":{ "0.0.0.17":[ { "ifaceAddress":"11.0.0.1", "areaId":"0.0.0.0", "ifaceName":"swp1", "localIfaceAddress":"11.0.0.2", "nbrPriority":1, "nbrState":"Full", "role":"DR", "stateChangeCounter":6, "lastPrgrsvChangeMsec":4531505, "routerDesignatedId":"0.0.0.17", =====> DR Router-Id "routerDesignatedBackupId":"0.0.0.12", =====> BDR Router-Id "optionsCounter":2, "optionsList":"*|-|-|-|-|-|E|-", "routerDeadIntervalTimerDueMsec":38495, "databaseSummaryListCounter":0, "linkStateRequestListCounter":0, "linkStateRetransmissionListCounter":0, "threadInactivityTimer":"on", "threadLinkStateRequestRetransmission":"on", "threadLinkStateUpdateRetransmission":"on" } ], "0.0.0.13":[ { "ifaceAddress":"11.0.2.2", "areaId":"0.0.0.0", "ifaceName":"swp2", "localIfaceAddress":"11.0.2.1", "nbrPriority":1, "nbrState":"Full", "role":"DR", "stateChangeCounter":6, "lastPrgrsvChangeMsec":4522182, "routerDesignatedId":"0.0.0.13", =====> DR Router-Id "routerDesignatedBackupId":"0.0.0.12", =====> BDR Router-Id "optionsCounter":2, "optionsList":"*|-|-|-|-|-|E|-", "routerDeadIntervalTimerDueMsec":37840, "databaseSummaryListCounter":0, "linkStateRequestListCounter":0, "linkStateRetransmissionListCounter":0, "threadInactivityTimer":"on", "threadLinkStateRequestRetransmission":"on", "threadLinkStateUpdateRetransmission":"on" } ], "0.0.0.14":[ { "ifaceAddress":"11.0.3.2", "areaId":"0.0.0.0", "ifaceName":"swp3", "localIfaceAddress":"11.0.3.1", "nbrPriority":1, "nbrState":"Full", "role":"DR", "stateChangeCounter":6, "lastPrgrsvChangeMsec":4522182, "routerDesignatedId":"0.0.0.14", =====> DR Router-Id "routerDesignatedBackupId":"0.0.0.12", =====> BDR Router-Id "optionsCounter":2, "optionsList":"*|-|-|-|-|-|E|-", "routerDeadIntervalTimerDueMsec":37840, "databaseSummaryListCounter":0, "linkStateRequestListCounter":0, "linkStateRetransmissionListCounter":0, "threadInactivityTimer":"on", "threadLinkStateRequestRetransmission":"on", "threadLinkStateUpdateRetransmission":"on" } ] } } } r1# r1# show ip ospf vrf default neighbor swp1 detail Neighbor 0.0.0.17, interface address 11.0.0.1 In the area 0.0.0.0 via interface swp1 local interface IP 11.0.0.2 Neighbor priority is 1, State is Full, Role is DR, 6 state changes Most recent state change statistics: Progressive change 1h18m11s ago DR is 0.0.0.17, BDR is 0.0.0.12 =======> correct DR and BDR router-id Options 2 *|-|-|-|-|-|E|- Dead timer due in 38.339s Database Summary List 0 Link State Request List 0 Link State Retransmission List 0 Thread Inactivity Timer on Thread Database Description Retransmision off Thread Link State Request Retransmission on Thread Link State Update Retransmission on r1# r1# show ip ospf vrf default neighbor swp swp1 swp2 swp3 swp4 r1# show ip ospf vrf default neighbor swp2 detail Neighbor 0.0.0.13, interface address 11.0.2.2 In the area 0.0.0.0 via interface swp2 local interface IP 11.0.2.1 Neighbor priority is 1, State is Full, Role is DR, 6 state changes Most recent state change statistics: Progressive change 12m02s ago DR is 0.0.0.13, BDR is 0.0.0.12 =======> correct DR and BDR router-id Options 2 *|-|-|-|-|-|E|- Dead timer due in 37.136s Database Summary List 0 Link State Request List 0 Link State Retransmission List 0 Thread Inactivity Timer on Thread Database Description Retransmision off Thread Link State Request Retransmission on Thread Link State Update Retransmission on r1# ``` Ticket:#3395270 Issue:3395270 Testing: UT done Signed-off-by: Sindhu Parvathi Gopinathan's <sgopinathan@nvidia.com>
2023-03-31ospfd: add support for NSSA Type-7 address rangesRenato Westphal
Implement NSSA address ranges as specified by RFC 3101: NSSA border routers may be configured with Type-7 address ranges. Each Type-7 address range is defined as an [address,mask] pair. Many separate Type-7 networks may fall into a single Type-7 address range, just as a subnetted network is composed of many separate subnets. NSSA border routers may aggregate Type-7 routes by advertising a single Type-5 LSA for each Type-7 address range. The Type-5 LSA resulting from a Type-7 address range match will be distributed to all Type-5 capable areas. Syntax: area A.B.C.D nssa range A.B.C.D/M [<not-advertise|cost (0-16777215)>] Example: router ospf router-id 1.1.1.1 area 1 nssa area 1 nssa range 172.16.0.0/16 area 1 nssa range 10.1.0.0/16 ! Since regular area ranges and NSSA ranges have a lot in common, this commit reuses the existing infrastructure for area ranges as much as possible to avoid code duplication. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2023-03-31ospfd: refactor range commandsRenato Westphal
* Update the "range" helpers to accept an area pointer instead of an area ID; * Always call ospf_area_display_format_set() after every "range" command to ensure consistency. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2023-03-31ospfd: implement Type-7 default routes for NSSA areasRenato Westphal
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>
2023-03-31ospfd: refactor the "area nssa" command using DEFPYRenato Westphal
Combine all variation of the "area nssa" command into a single DEFPY to improve code maintainability. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2023-03-24*: Convert event.h to frrevent.hDonald Sharp
We should probably prevent any type of namespace collision with something else. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-24*: Convert THREAD_XXX macros to EVENT_XXX macrosDonald Sharp
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-24*: Convert thread_timer_remain_XXX to event_timer_remain_XXXDonald Sharp
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-24*: Rename thread.[ch] to event.[ch]Donald Sharp
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>
2023-03-17ospfd: Fix inconsistency in LSDB JSON outputRenato Westphal
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>
2023-03-17ospfd: Add "detail" option to "show ip ospf database"Renato Westphal
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>
2023-03-17ospfd: Refactor the "show ip ospf database" commandRenato Westphal
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>
2023-02-24Merge pull request #12751 from Pdoijode/pdoijode/ospf-vrf-neighbor-detail-1Donatas Abraitis
ospfd: Added missing fields and option to query specific neighbor in VRF
2023-02-21Merge pull request #12366 from manojvn/ospfv2-flood-reductionRuss White
ospfd: Support OSPF Refresh and Flooding Reduction RFC4136.
2023-02-09*: auto-convert to SPDX License IDsDavid Lamparter
Done with a combination of regex'ing and banging my head against a wall. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2023-02-08ospfd: Fix "show ip ospf neighbor swp1 detail json" outputPooja Jagadeesh Doijode
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>