summaryrefslogtreecommitdiffstats
path: root/ospf6d (follow)
Commit message (Collapse)AuthorAgeFilesLines
* ospf6d: Fixing memory leak in ospf6_lsa_create_headeronly for both master ↵Manoj Naragund2022-12-191-42/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and slave. Problem Statement: ================= Memory leak backtraces 2022-11-23 01:51:10,525 - ERROR: ==842== 1,100 (1,000 direct, 100 indirect) bytes in 5 blocks are definitely lost in loss record 29 of 31 2022-11-23 01:51:10,525 - ERROR: ==842== at 0x4C31FAC: calloc (vg_replace_malloc.c:762) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x4E8A1BF: qcalloc (memory.c:111) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x13555A: ospf6_lsa_alloc (ospf6_lsa.c:723) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x1355F3: ospf6_lsa_create_headeronly (ospf6_lsa.c:756) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x135702: ospf6_lsa_copy (ospf6_lsa.c:790) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x13B64B: ospf6_dbdesc_recv_slave (ospf6_message.c:976) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x13B64B: ospf6_dbdesc_recv (ospf6_message.c:1038) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x13B64B: ospf6_read_helper (ospf6_message.c:1838) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x13B64B: ospf6_receive (ospf6_message.c:1875) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x4EB741B: thread_call (thread.c:1692) 2022-11-23 01:51:10,526 - ERROR: ==842== by 0x4E85B17: frr_run (libfrr.c:1068) 2022-11-23 01:51:10,526 - ERROR: ==842== by 0x119585: main (ospf6_main.c:228) 2022-11-23 01:51:10,526 - ERROR: ==842== 2022-11-23 01:51:10,524 - ERROR: Found memory leak in module ospf6d 2022-11-23 01:51:10,525 - ERROR: ==842== 220 (200 direct, 20 indirect) bytes in 1 blocks are definitely lost in loss record 21 of 31 2022-11-23 01:51:10,525 - ERROR: ==842== at 0x4C31FAC: calloc (vg_replace_malloc.c:762) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x4E8A1BF: qcalloc (memory.c:111) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x13555A: ospf6_lsa_alloc (ospf6_lsa.c:723) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x1355F3: ospf6_lsa_create_headeronly (ospf6_lsa.c:756) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x135702: ospf6_lsa_copy (ospf6_lsa.c:790) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x13BBCE: ospf6_dbdesc_recv_master (ospf6_message.c:760) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x13BBCE: ospf6_dbdesc_recv (ospf6_message.c:1036) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x13BBCE: ospf6_read_helper (ospf6_message.c:1838) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x13BBCE: ospf6_receive (ospf6_message.c:1875) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x4EB741B: thread_call (thread.c:1692) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x4E85B17: frr_run (libfrr.c:1068) 2022-11-23 01:51:10,525 - ERROR: ==842== by 0x119585: main (ospf6_main.c:228) 2022-11-23 01:51:10,525 - ERROR: ==842== RCA: ==== These memory leaks are beacuse of last lsa in neighbour's request_list is not getting freed beacuse of lsa lock. The last request has an addtional lock which is added as a part of ospf6_make_lsreq, this lock needs to be removed in order for the lsa to get freed. Fix: ==== Check and remove the lock on the last request in all the functions. Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
* ospf6d: Fix auth_key string memory leakDonald Sharp2022-12-152-0/+6
| | | | | | | When using auth keys in ospfv3, there are some memory leaks when you change the key or remove the interface Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* Merge pull request #12191 from manojvn/463777Russ White2022-12-131-0/+48
|\ | | | | ospf6d: ospf6 route installation when changed from nssa to regular area.
| * ospf6d: ospf6 route installation when changed from nssa to regular area.Manoj Naragund2022-11-141-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Delay in ospfv3 route installation when area gets converted to regular from NSSA. RCA: when area gets converted from NSSA to normal the type-7(NSSA_LSAs) gets flushed from the area, as a result the external routes learnt from these type-7s gets removed. Once the area is moved to nomral the type 5 lsas needs to flooded through the area so that routes are re-learnt. however there is a delay in flooding of these routes until these routes are refreshed. Due to this there is delay installation of these routes. Fix: The Fix involves refreshing of the type 5 lsas once the area is changed from nssa to regular area. Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
* | ospf6d: Don't allocate json memory in non-json pathDonald Sharp2022-12-091-1/+2
| | | | | | | | Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | ospf6d: Stop using MTYPE_TMP in some casesDonald Sharp2022-12-051-2/+2
| | | | | | | | Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | ospf6d: Consolidate to ospf6_route_is_identicalDonald Sharp2022-11-281-6/+1
| | | | | | | | Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | ospf6d: ospf6_route_cmp_nexthops make return saneDonald Sharp2022-11-283-15/+18
| | | | | | | | | | | | | | | | The ospf6_route_cmp_nexthops function was returning 0 for same and 1 for not same. Let's reverse the polarity and actually make the returns useful long term. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | ospf6d: fix infinite loop when adding ASBR routeRenato Westphal2022-11-242-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 8f359e1593c414322 removed a check that prevented the same route from being added twice. In certain topologies, that change resulted in the following infinite loop when adding an ASBR route: ospf6_route_add ospf6_top_brouter_hook_add ospf6_abr_examin_brouter ospf6_abr_examin_summary ospf6_route_add (repeat until stack overflow) Revert the offending commit and update `ospf6_route_is_identical()` to not do comparison using `memcmp()`. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
* | Merge pull request #12280 from ↵Jafar Al-Gharaibeh2022-11-091-3/+10
|\ \ | | | | | | | | | | | | opensourcerouting/fix/ospv6_show_passive_interface ospf6d: Show if the interface is passive for `show ipv6 ospf6 interface`
| * | ospf6d: Show if the interface is passive for `show ipv6 ospf6 interface`Donatas Abraitis2022-11-081-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | donatas-pc# sh ipv6 ospf6 interface enp3s0 enp3s0 is up, type BROADCAST Interface ID: 2 Internet Address: inet : 192.168.10.17/24 inet6: fe80::ca5d:fd0d:cd8:1bb7/64 Instance ID 0, Interface MTU 1500 (autodetect: 1500) MTU mismatch detection: enabled Area ID 0.0.0.0, Cost 1000 State Waiting, Transmit Delay 1 sec, Priority 1 Timer intervals configured: Hello 10(8.149), Dead 40, Retransmit 5 DR: 0.0.0.0 BDR: 0.0.0.0 Number of I/F scoped LSAs is 1 0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off] 0 Pending LSAs for LSAck in Time 00:00:00 [thread off] Authentication Trailer is disabled donatas-pc# con donatas-pc(config)# int enp3s0 donatas-pc(config-if)# ipv6 ospf6 passive donatas-pc(config-if)# do sh ipv6 ospf6 interface enp3s0 enp3s0 is up, type BROADCAST Interface ID: 2 Internet Address: inet : 192.168.10.17/24 inet6: fe80::ca5d:fd0d:cd8:1bb7/64 Instance ID 0, Interface MTU 1500 (autodetect: 1500) MTU mismatch detection: enabled Area ID 0.0.0.0, Cost 1000 State Waiting, Transmit Delay 1 sec, Priority 1 Timer intervals configured: No Hellos (Passive interface) DR: 0.0.0.0 BDR: 0.0.0.0 Number of I/F scoped LSAs is 1 0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off] 0 Pending LSAs for LSAck in Time 00:00:00 [thread off] Authentication Trailer is disabled donatas-pc(config-if)# Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
* | | Merge pull request #11302 from punith-shivakumar/masterDonatas Abraitis2022-11-082-2/+5
|\ \ \ | |/ / |/| | ospf6d: add missing ABR task on interface start and change default task delay to 5
| * | ospf6d: fix test_ospf6_gr_topo1 topotestPunith Kumar S2022-07-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. topo test failure seen in below mentioned step of execution with routes not synced with ABR ospf6_gr_topo1/test_ospf6_gr_topo1.py::test_gr_rt3 - AssertionError: "rt1" JSON output mismatches the expected result. 2. as experimental, increasing the sleep interval(21), cleared the above step but failed in the step FAILED ospf6_gr_topo1/test_ospf6_gr_topo1.py::test_gr_rt5 - AssertionError: "rt2" JSON output mismatches the expected result fix: tuning retry parameter in check_routers cleared the topotest. so, changing default value of ospf6 ABR task delay to 5 seconds. Signed-off-by: Punith Kumar S <punith.shivakumar@sophos.com>
| * | ospf6d: routes are not synced by ABR.Punith Kumar S2022-07-131-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | topology: C1--R1---R2---R3--C2 client C1 connected to router node R1 client C2 connected to router node R3 router nodes R1,R2 and R3 are back to back connected area 0 configured between R1 and R2 R1: all routes of area 0 are learnt successfully R2: all routes of area 0 are learnt successfully area 1 configured between R2 and R3 R2: all routes are learnt from R3 R3: routes learnt from C1 on ABR router R2 does not get forward to R3 root cause: on interface start, ABR schedule task is missing. fix: handle ABR schedule during interface start event Signed-off-by: Punith Kumar S <punith.shivakumar@sophos.com>
* | | Merge pull request #12196 from opensourcerouting/xref-vtyshDonald Sharp2022-11-039-45/+8
|\ \ \ | | | | | | | | *: rewrite `extract.pl` using `xref` infra
| * | | ospfd, ospf6d: align CLI help stringsDavid Lamparter2022-10-261-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ospfd and ospf6d define the same metric-type route-map commands. Make them have the same help string too. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
| * | | build, vtysh: extract vtysh commands from .xrefDavid Lamparter2022-10-269-37/+0
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge pull request #12201 from donaldsharp/clang-16-robotsJafar Al-Gharaibeh2022-10-271-4/+2
|\ \ \ | | | | | | | | Clang 16 robots
| * | | ospf6d: Make ospf6d happy with clang-16Donald Sharp2022-10-261-4/+2
| |/ / | | | | | | | | | Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* / / ospf6d: Fix for memory leak issues in ospf6.Manoj Naragund2022-10-252-1/+19
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Multiple memory leaks in ospf6. 260 ==6637== 32 bytes in 1 blocks are definitely lost in loss record 5 of 24 261 ==6637== at 0x4C31FAC: calloc (vg_replace_malloc.c:762) 262 ==6637== by 0x4E8A1BF: qcalloc (memory.c:111) 263 ==6637== by 0x11EE27: ospf6_summary_add_aggr_route_and_blackhole (ospf6_asbr.c:2779) 264 ==6637== by 0x11EEBA: ospf6_originate_new_aggr_lsa (ospf6_asbr.c:2811) 265 ==6637== by 0x4E7C6A7: hash_clean (hash.c:325) 266 ==6637== by 0x11FA93: ospf6_handle_external_aggr_update (ospf6_asbr.c:3164) 267 ==6637== by 0x11FA93: ospf6_asbr_summary_process (ospf6_asbr.c:3386) 268 ==6637== by 0x4EB739B: thread_call (thread.c:1692) 269 ==6637== by 0x4E85B17: frr_run (libfrr.c:1068) 270 ==6637== by 0x119535: main (ospf6_main.c:228) 356 ==6637== 240 bytes in 12 blocks are indirectly lost in loss record 13 of 24 357 ==6637== at 0x4C2FE96: malloc (vg_replace_malloc.c:309) 358 ==6637== by 0x4E8A0DA: qmalloc (memory.c:106) 359 ==6637== by 0x13545C: ospf6_lsa_alloc (ospf6_lsa.c:724) 360 ==6637== by 0x1354E3: ospf6_lsa_create_headeronly (ospf6_lsa.c:756) 361 ==6637== by 0x1355F2: ospf6_lsa_copy (ospf6_lsa.c:790) 362 ==6637== by 0x13B58B: ospf6_dbdesc_recv_slave (ospf6_message.c:976) 363 ==6637== by 0x13B58B: ospf6_dbdesc_recv (ospf6_message.c:1038) 364 ==6637== by 0x13B58B: ospf6_read_helper (ospf6_message.c:1838) 365 ==6637== by 0x13B58B: ospf6_receive (ospf6_message.c:1875) 366 ==6637== by 0x4EB739B: thread_call (thread.c:1692) 367 ==6637== by 0x4E85B17: frr_run (libfrr.c:1068) 368 ==6637== by 0x119535: main (ospf6_main.c:228) RCA: 1. when the ospf6 area is being deleted, the neighbor related information was not being cleaned up. 2. when aggr route gets deleted from rt_aggr_tbl the corrsponding summary route attched to the aggr route was not being deleted. Fix: Added the ospf6_neighbor_delete in ospf6_area_delete to free the neighbor related information and added ospf6_route_delete while freeing external aggr route to free the summary route. Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
* | Merge pull request #12146 from rgirada/frr_grDonatas Abraitis2022-10-191-0/+5
|\ \ | | | | | | ospf6d: adding missing json fields
| * | ospf6d: adding missing json fieldsrgirada2022-10-181-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Description: Active GR count field is missing in json o/p of 'show ipv6 ospf gr helper' command. Issue: #12100 Signed-off-by: Rajesh Girada <rgirada@vmware.com>
* | | *: Create and use infrastructure to show debugs in libDonald Sharp2022-10-071-0/+2
|/ / | | | | | | | | | | | | | | | | 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>
* | ospf6d: Don't remove summary route if it is a rangeXiaodong Xu2022-08-201-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix issue #11839. When the user defines a range in an area other than the backbone area, the summary route will be announced to the backbone area as an inter-area LSA. However, if the prefix defined in the range is the same prefix as a connected route in that area, the LSA won't be announced to the backbone area. This is because when ospf6d is originating the summary route for the intra-area route, it finds the range configured by the user and tries to suppress the route by deleting the existing summary route, which happens to be the one created by the range. Although the range definition is not necessary in this case, it should not fail this use case. So let's just keep the summary route there if it is created from the user defined range. Signed-off-by: Xiaodong Xu <stid.smth@gmail.com>
* | Merge pull request #11781 from donaldsharp/ospf_packet_helperDonatas Abraitis2022-08-151-5/+1
|\ \ | | | | | | Ospf packet helper
| * | ospf6d: Remove unused variableDonald Sharp2022-08-111-5/+1
| | | | | | | | | | | | | | | | | | last_serviced_oi is always NULL. Remove Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | | Merge pull request #11785 from ↵Donald Sharp2022-08-131-8/+1
|\ \ \ | | | | | | | | | | | | | | | | opensourcerouting/fix/remove_ospf6Enabled_from_JSON ospf6d: Remove ospf6Enabled from JSON output
| * | | ospf6d: Remove ospf6Enabled from JSON outputDonatas Abraitis2022-08-111-8/+1
| |/ / | | | | | | | | | | | | | | | Time to deprecate it. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
* / / ospf6d: fix missing cost changeanlan_cs2022-08-111-1/+4
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After all needed interfaces ( for example: interface "a1", vrf "vrf1", and "a1" is binded to "vrf1" ) are ready/created, then restart/start frr. zebra at startup will call `netlink_interface()` to process all interfaces and notify all clients, but its calling `get_iflink_speed()` maybe fails for unexpected order of the coming interfaces: when processing "a1", "vrf1" maybe is unknown at that time. `if_zebra_speed_update()` timer is introduced to deal with this order problem. Currently only ospfd and ospf6d deal with this speed change to recalculated route cost. ospfd can deal with this change, but ospf6d will wrongly missed it. Since both `ipv6 ospf6 cost COST` and `auto-cost reference-bandwidth COST` are not set, cost of this ospf6 interface should be calculated with interface speed, but it is wrongly kept to `10`, which is based on interface speed being `0` for it missed speed change. Further, ECMP function becomes invalid after restart frr, beacuse some ospf6 interfaces of one ECMP are wrongly with cost `10`. To avoid missing, recalculate cost for ospf6 interfaces based on potentially changed speed. Signed-off-by: anlan_cs <vic.lan@pica8.com>
* | ospf6d: combine two conditions for lsa prefixanlan_cs2022-08-031-4/+2
| | | | | | | | | | | | | | For both router and network LSAs, combine the two conditions and process lsa prefix uniformly. Signed-off-by: anlan_cs <vic.lan@pica8.com>
* | ospf6d: corrected the debug stringsri-mohan12022-07-271-1/+1
| | | | | | | | | | | | Corrected the gramatical error for debug string Signed-off-by: sri-mohan1 <sri.mohan@samsung.com>
* | Merge pull request #11462 from donaldsharp/random_stuff_rightmobash-rasool2022-06-241-1/+7
|\ \ | | | | | | Random stuff right
| * | ospf6d: Ensure that ospf6d does not memcpy beyond end of dataDonald Sharp2022-06-231-1/+7
| | | | | | | | | | | | | | | | | | | | | Ensure that received data size can fit into temp variable that is used to dump data. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | | Merge pull request #11430 from mjstapp/fix_ospf6_zebra_delRafael Zalamena2022-06-241-9/+18
|\ \ \ | |/ / |/| | ospf6: permit route delete without nexthops
| * | ospf6: permit route delete without nexthopsMark Stapp2022-06-171-9/+18
| | | | | | | | | | | | | | | | | | | | | | | | It's possible for ospf6 to decide to delete a route after it's removed all of the route's nexthops. It's ok to delete a prefix alone - be a little more forgiving when preparing a route delete. Signed-off-by: Mark Stapp <mstapp@nvidia.com>
* | | ospf6d: cost is uint32_t so it cannot be greater than UINT32_MAXDonald Sharp2022-06-161-2/+0
| | | | | | | | | | | | | | | | | | Remove the extra test. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | | *: Use autocomplete for route-maps under commands that require itDonatas Abraitis2022-06-131-4/+4
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For example: ``` donatas-laptop# show bgp ipv4 unicast neighbors 127.0.0.2 advertised-routes route-map ? RMAP_NAME Name of the route map testas2 testas donatas-laptop(config)# router bgp donatas-laptop(config-router)# address-family ipv4 donatas-laptop(config-router-af)# redistribute connected route-map ? RMAP_NAME Pointer to route-map entries testas2 testas donatas-laptop(config-router-af)# network 192.168.0.0/23 route-map ? RMAP_NAME Name of the route map testas2 testas ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
* / ospf6d: fix rx/tx buffer sizesDavid Lamparter2022-06-011-11/+16
|/ | | | | | | | | | | | | | OSPFv3 packets can be fragmented and up to 64k long, regardless of interface MTU. Trying to size these buffers to MTU is just plain wrong. To not make this a super intrusive change during the 8.3 release freeze, just code this into ospf6_iobuf_size(). Since the buffer is now always 64k, don't waste time zeroing the entire thing in receive; instead just zero kind of a "sled" of 128 bytes after the buffer as a security precaution. Fixes: #11298 Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* ospf6d: Clean up thread interfaceDonald Sharp2022-05-209-53/+59
| | | | | | | | | a) Remove setting of thread pointer to NULL after thread invocation, this is already done. b) Use thread_is_scheduled() Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* ospf6d: Remove double check of default prefixDonald Sharp2022-05-201-8/+4
| | | | | | | | The ospf6_is_valid_summary_addr function is checking to see if a prefix is the default and also then double comparing it against the v6 prefix part. No need to do this. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* ospf6d: Ensure the ospf6 interface hello timer pops in all casesDonald Sharp2022-05-162-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a end users does something like this: int enp39s0 ipv6 ospf6 hello-interval 65535 And then the timer pops and we send the hello and immediately if the end user does this: ipv6 ospf6 hello-interval 5 The timer is not being reset and FRR waits the full 65k seconds before sending the hello again, which then immediately sets the next hello to go out in 5 seconds. When FRR receives the new timer value, look at how much time is left on the timer in seconds. If this value is greater than the new hello timer, stop the timer and set it too that value. This should fix a CI system test failure found, where the system is testing setting timer from things like 12 seconds to 65k seconds then back down to 12 and that the ospf6 neighbor relationship stays up. The code was also changed from thread_add_event to thread_add_timer in all cases. I am not sure what would happen if a show command comes in for a thread timer remaining with an event instead of a timer just make it consistent. This was chased down because the support bundle showed this: r0# show ipv6 ospf6 vrf all interface r0-r1-eth0 is up, type BROADCAST Interface ID: 6 Internet Address: inet6: fe80::a4ea:d3ff:fe35:cef1/64 inet6: fd00::1/64 Instance ID 0, Interface MTU 1500 (autodetect: 1500) MTU mismatch detection: enabled Area ID 0.0.0.0, Cost 10 State DR, Transmit Delay 1 sec, Priority 1 Timer intervals configured: Hello 12(65480.960), Dead 48, Retransmit 5 And looking at the test code is doing stuff like this: 2022/05/16 17:08:15 OSPF6: [M7Q4P-46WDR] vty[5]@(config)# interface r1-r0-eth0 2022/05/16 17:08:15 OSPF6: [M7Q4P-46WDR] vty[5]@(config-if)# ipv6 ospf6 hello-interval 65535 2022/05/16 17:08:15 OSPF6: [M7Q4P-46WDR] vty[5]@(config-if)# no ipv6 ospf6 hello-interval 2022/05/16 17:08:16 OSPF6: [M7Q4P-46WDR] vty[5]@(config-if)# ipv6 ospf6 hello-interval 1 2022/05/16 17:08:16 OSPF6: [M7Q4P-46WDR] vty[5]@(config-if)# ipv6 ospf6 hello-interval 12 If the old timer value pops, the hello interval is set to 65k and never reset again. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* ospf6d: Give time left in hello timer for `show ipv6 ospf6 int`Donald Sharp2022-05-161-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | When running `show ipv6 ospf6 interface` the hello timer period is shown, but there is no indication on how much time is left on the timer. Add a clue: sharpd@eva ~/frr5 (master)> vtysh -c "show ipv6 ospf6 int" enp39s0 is up, type BROADCAST Interface ID: 2 Internet Address: inet : 192.168.119.224/24 inet6: 2603:6080:602:509e:9a14:998:b154:9e9/64 Instance ID 0, Interface MTU 1500 (autodetect: 1500) MTU mismatch detection: enabled Area ID 0.0.0.0, Cost 1000 State DR, Transmit Delay 1 sec, Priority 1 Timer intervals configured: Hello 10(2.652), Dead 40, Retransmit 5 DR: 192.168.122.1 BDR: 0.0.0.0 Number of I/F scoped LSAs is 1 0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off] 0 Pending LSAs for LSAck in Time 00:00:00 [thread off] Authentication Trailer is disabled Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* Merge pull request #11177 from opensourcerouting/fix/memset_memcpyDonald Sharp2022-05-137-12/+12
|\ | | | | *: memcpy/memset zeroing
| * *: Properly use memset() when zeroingDonatas Abraitis2022-05-117-12/+12
| | | | | | | | | | | | | | Wrong: memset(&a, 0, sizeof(struct ...)); Good: memset(&a, 0, sizeof(a)); Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
* | ospf6d: add header size check for LSAanlan_cs2022-05-101-0/+12
|/ | | | | | | Add header size check for safe. If the check fails, just jump out of current function. Signed-off-by: anlan_cs <vic.lan@pica8.com>
* Merge pull request #11163 from opensourcerouting/fix/same_type_castingIgor Ryzhov2022-05-091-6/+6
|\ | | | | *: Avoid casting to the same type as on the left
| * *: Avoid casting to the same type as on the leftDonatas Abraitis2022-05-081-6/+6
| | | | | | | | | | | | Just not necessary. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
* | zebra, ospf6d: Do not check if NULL for XCALLOC()Donatas Abraitis2022-05-081-2/+0
|/ | | | Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
* *: remove the checking returned value for hash_get()anlan_cs2022-05-022-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge pull request #11051 from donaldsharp/speell_moreDonatas Abraitis2022-04-202-2/+2
|\ | | | | Speell more
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-04 13:58:09 +0100