| Age | Commit message (Collapse) | Author |
|---|
|
Include an event ptr-to-ptr in the event_execute() api
call, like the various schedule api calls. This allows the
execute() api to cancel an existing scheduled task if that
task is being executed inline.
Signed-off-by: Mark Stapp <mjs@labn.net>
|
|
Make the ospf6_lsa_unlock take the same parameters
that the ospf_lsa_unlock does to make it consistent
and to also ensure that no-one can make the mistake
of getting the pointer cleared up.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
ospf6d: Fix crash because neighbor structure was freed
|
|
The loading_done event needs a event pointer to prevent
use after free's. Testing found this:
ERROR: AddressSanitizer: heap-use-after-free on address 0x613000035130 at pc 0x55ad42d54e5f bp 0x7ffff1e942a0 sp 0x7ffff1e94290
READ of size 1 at 0x613000035130 thread T0
#0 0x55ad42d54e5e in loading_done ospf6d/ospf6_neighbor.c:447
#1 0x55ad42ed7be4 in event_call lib/event.c:1995
#2 0x55ad42e1df75 in frr_run lib/libfrr.c:1213
#3 0x55ad42cf332e in main ospf6d/ospf6_main.c:250
#4 0x7f5798133c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
#5 0x55ad42cf2b19 in _start (/usr/lib/frr/ospf6d+0x248b19)
0x613000035130 is located 48 bytes inside of 384-byte region [0x613000035100,0x613000035280)
freed by thread T0 here:
#0 0x7f57998d77a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8)
#1 0x55ad42e3b4b6 in qfree lib/memory.c:130
#2 0x55ad42d5d049 in ospf6_neighbor_delete ospf6d/ospf6_neighbor.c:180
#3 0x55ad42d1e1ea in interface_down ospf6d/ospf6_interface.c:930
#4 0x55ad42ed7be4 in event_call lib/event.c:1995
#5 0x55ad42ed84fe in _event_execute lib/event.c:2086
#6 0x55ad42d26d7b in ospf6_interface_clear ospf6d/ospf6_interface.c:2847
#7 0x55ad42d73f16 in ospf6_process_reset ospf6d/ospf6_top.c:755
#8 0x55ad42d7e98c in clear_router_ospf6_magic ospf6d/ospf6_top.c:778
#9 0x55ad42d7e98c in clear_router_ospf6 ospf6d/ospf6_top_clippy.c:42
#10 0x55ad42dc2665 in cmd_execute_command_real lib/command.c:994
#11 0x55ad42dc2b32 in cmd_execute_command lib/command.c:1053
#12 0x55ad42dc2fa9 in cmd_execute lib/command.c:1221
#13 0x55ad42ee3cd6 in vty_command lib/vty.c:591
#14 0x55ad42ee4170 in vty_execute lib/vty.c:1354
#15 0x55ad42eec94f in vtysh_read lib/vty.c:2362
#16 0x55ad42ed7be4 in event_call lib/event.c:1995
#17 0x55ad42e1df75 in frr_run lib/libfrr.c:1213
#18 0x55ad42cf332e in main ospf6d/ospf6_main.c:250
#19 0x7f5798133c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
previously allocated by thread T0 here:
#0 0x7f57998d7d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x55ad42e3ab22 in qcalloc lib/memory.c:105
#2 0x55ad42d5c8ff in ospf6_neighbor_create ospf6d/ospf6_neighbor.c:119
#3 0x55ad42d4c86a in ospf6_hello_recv ospf6d/ospf6_message.c:464
#4 0x55ad42d4c86a in ospf6_read_helper ospf6d/ospf6_message.c:1884
#5 0x55ad42d4c86a in ospf6_receive ospf6d/ospf6_message.c:1925
#6 0x55ad42ed7be4 in event_call lib/event.c:1995
#7 0x55ad42e1df75 in frr_run lib/libfrr.c:1213
#8 0x55ad42cf332e in main ospf6d/ospf6_main.c:250
#9 0x7f5798133c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Add an actual event pointer and just track it appropriately.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
I'm seeing crashes in ospf6_write on the `assert(node)`. The only
sequence of events that I see that could possibly cause this to happen
is this:
a) Someone has scheduled a outgoing write to the ospf6->t_write and
placed item(s) on the ospf6->oi_write_q
b) A decision is made in ospf6_send_lsupdate() to send an immediate
packet via a event_execute(..., ospf6_write,....).
c) ospf6_write is called and the oi_write_q is cleaned out.
d) the t_write event is now popped and the oi_write_q is empty
and FRR asserts on the `assert(node)` <crash>
When event_execute is called for ospf6_write, just cancel the t_write
event. If ospf6_write has more data to send at the end of the function
it will reschedule itself. I've only seen this crash one time and am
unable to reliably reproduce this at all. But this is the only mechanism
that I can see that could make this happen, given how little the oi_write_q
is actually touched in code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
bgpd/isisd message.
Signed-off-by: Acee <aceelindem@gmail.com>
|
|
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>
|
|
We should probably prevent any type of namespace collision
with something else.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
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>
|
|
Basically just router-id or interface/IP.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Done with a combination of regex'ing and banging my head against a wall.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
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>
|
|
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>
|
|
last_serviced_oi is always NULL. Remove
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
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>
|
|
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>
|
|
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>
|
|
The int return value is never used. Modify the code
base to just return a void instead.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Fixed below coverity issues
________________________________________________________________________________________________________
*** CID 1511366: (TAINTED_SCALAR)
/ospf6d/ospf6_message.c: 2631 in ospf6_make_lsupdate_list()
2625 + OSPF6_HEADER_SIZE)
2626 > ospf6_packet_max(on->ospf6_if)) {
2627 ospf6_fill_header(on->ospf6_if, (*op)->s,
2628 length + OSPF6_HEADER_SIZE);
2629 (*op)->length = length + OSPF6_HEADER_SIZE;
2630 ospf6_fill_lsupdate_header((*op)->s, *lsa_cnt);
>>> CID 1511366: (TAINTED_SCALAR)
>>> Passing tainted variable "(*op)->length" to a tainted sink.
2631 ospf6_send_lsupdate(on, NULL, *op);
2632
2633 /* refresh packet */
2634 *op = ospf6_packet_new(on->ospf6_if->ifmtu);
2635 length = OSPF6_LS_UPD_MIN_SIZE;
2636 *lsa_cnt = 0;
/ospf6d/ospf6_message.c: 2631 in ospf6_make_lsupdate_list()
2625 + OSPF6_HEADER_SIZE)
2626 > ospf6_packet_max(on->ospf6_if)) {
2627 ospf6_fill_header(on->ospf6_if, (*op)->s,
2628 length + OSPF6_HEADER_SIZE);
2629 (*op)->length = length + OSPF6_HEADER_SIZE;
2630 ospf6_fill_lsupdate_header((*op)->s, *lsa_cnt);
>>> CID 1511366: (TAINTED_SCALAR)
>>> Passing tainted variable "(*op)->length" to a tainted sink.
2631 ospf6_send_lsupdate(on, NULL, *op);
________________________________________________________________________________________________________
*** CID 1511365: (TAINTED_SCALAR)
/ospf6d/ospf6_message.c: 2674 in ospf6_make_ls_retrans_list()
2669 if (on->ospf6_if->state == OSPF6_INTERFACE_POINTTOPOINT)
2670 (*op)->dst = allspfrouters6;
2671 else
2672 (*op)->dst = on->linklocal_addr;
2673
>>> CID 1511365: (TAINTED_SCALAR)
>>> Passing tainted variable "(*op)->length" to a tainted sink.
2674 ospf6_fill_hdr_checksum(on->ospf6_if, *op);
2675 ospf6_packet_add(on->ospf6_if, *op);
2676 OSPF6_MESSAGE_WRITE_ON(on->ospf6_if);
/ospf6d/ospf6_message.c: 2674 in ospf6_make_ls_retrans_list()
2669 if (on->ospf6_if->state == OSPF6_INTERFACE_POINTTOPOINT)
2670 (*op)->dst = allspfrouters6;
2671 else
2672 (*op)->dst = on->linklocal_addr;
2673
>>> CID 1511365: (TAINTED_SCALAR)
>>> Passing tainted variable "(*op)->length" to a tainted sink.
2674 ospf6_fill_hdr_checksum(on->ospf6_if, *op);
2675 ospf6_packet_add(on->ospf6_if, *op);
2676 OSPF6_MESSAGE_WRITE_ON(on->ospf6_if);
/ospf6d/ospf6_message.c: 2674 in ospf6_make_ls_retrans_list()
2668 ospf6_fill_lsupdate_header((*op)->s, *lsa_cnt);
2669 if (on->ospf6_if->state == OSPF6_INTERFACE_POINTTOPOINT)
2670 (*op)->dst = allspfrouters6;
2671 else
2672 (*op)->dst = on->linklocal_addr;
2673
>>> CID 1511365: (TAINTED_SCALAR)
>>> Passing tainted variable "(*op)->length" to a tainted sink.
2674 ospf6_fill_hdr_checksum(on->ospf6_if, *op);
2675 ospf6_packet_add(on->ospf6_if, *op);
2676 OSPF6_MESSAGE_WRITE_ON(on->ospf6_if);
________________________________________________________________________________________________________
*** CID 1511364: Insecure data handling (TAINTED_SCALAR)
/ospf6d/ospf6_message.c: 2125 in ospf6_write()
2120 if (oi->at_data.flags != 0) {
2121 at_len = ospf6_auth_len_get(oi);
2122 if (at_len) {
2123 iovector[0].iov_len =
2124 ntohs(oh->length) + at_len;
>>> CID 1511364: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted variable "iovector[0].iov_len" to a tainted sink.
2125 ospf6_auth_digest_send(oi->linklocal_addr, oi,
2126 oh, at_len,
2127 iovector[0].iov_len);
2128 } else {
2129 iovector[0].iov_len = ntohs(oh->length);
2130 }
________________________________________________________________________________________________________
*** CID 1511363: (DEADCODE)
/ospf6d/ospf6_auth_trailer.c: 275 in ospf6_hash_hmac_sha_digest()
269 case KEYCHAIN_ALGO_HMAC_SHA512:
270 #ifdef CRYPTO_OPENSSL
271 sha512_digest(mes, len, digest);
272 #endif
273 break;
274 case KEYCHAIN_ALGO_NULL:
>>> CID 1511363: (DEADCODE)
>>> Execution cannot reach this statement: "case KEYCHAIN_ALGO_MAX:".
275 case KEYCHAIN_ALGO_MAX:
276 default:
/ospf6d/ospf6_auth_trailer.c: 274 in ospf6_hash_hmac_sha_digest()
269 case KEYCHAIN_ALGO_HMAC_SHA512:
270 #ifdef CRYPTO_OPENSSL
271 sha512_digest(mes, len, digest);
272 #endif
273 break;
>>> CID 1511363: (DEADCODE)
>>> Execution cannot reach this statement: "case KEYCHAIN_ALGO_NULL:".
274 case KEYCHAIN_ALGO_NULL:
275 case KEYCHAIN_ALGO_MAX:
276 default:
________________________________________________________________________________________________________
*** CID 1511362: Insecure data handling (TAINTED_SCALAR)
/ospf6d/ospf6_auth_trailer.c: 541 in ospf6_auth_check_digest()
535
536 auth_len = ntohs(ospf6_auth->length);
537
538 memcpy(temp_hash, ospf6_auth->data, hash_len);
539 memcpy(ospf6_auth->data, apad, hash_len);
540
>>> CID 1511362: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted variable "oh_len + auth_len + lls_block_len" to a tainted sink.
541 ospf6_auth_update_digest(oi, oh, ospf6_auth, auth_str,
542 (oh_len + auth_len + lls_block_len),
543 hash_algo);
________________________________________________________________________________________________________
*** CID 1511361: Insecure data handling (TAINTED_SCALAR)
/ospf6d/ospf6_auth_trailer.c: 124 in ospf6_auth_hdr_dump_recv()
118 at_len = length - (oh_len + lls_len);
119 if (at_len > 0) {
120 ospf6_at_hdr =
121 (struct ospf6_auth_hdr *)((uint8_t *)ospfh + oh_len);
122 at_hdr_len = ntohs(ospf6_at_hdr->length);
123 hash_len = at_hdr_len - OSPF6_AUTH_HDR_MIN_SIZE;
>>> CID 1511361: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted variable "hash_len" to a tainted sink.
124 memcpy(temp, ospf6_at_hdr->data, hash_len);
125 temp[hash_len] = '\0';
________________________________________________________________________________________________________
*** CID 1482146: Insecure data handling (TAINTED_SCALAR)
/ospf6d/ospf6_message.c: 2787 in ospf6_lsupdate_send_neighbor_now()
2781
2782 if (IS_OSPF6_DEBUG_FLOODING
2783 || IS_OSPF6_DEBUG_MESSAGE(OSPF6_MESSAGE_TYPE_LSUPDATE, SEND_HDR))
2784 zlog_debug("%s: Send lsupdate with lsa %s (age %u)", __func__,
2785 lsa->name, ntohs(lsa->header->age));
2786
>>> CID 1482146: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted variable "op->length" to a tainted sink.
2787 ospf6_send_lsupdate(on, NULL, op);
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
|
|
Problem Statement:
==================
RFC 7166 support for OSPF6 in FRR code.
RCA:
====
This feature is newly supported in FRR
Fix:
====
Core functionality implemented in previous commit is
stitched with rest of ospf6 code as part of this commit.
Risk:
=====
Low risk
Tests Executed:
===============
Have executed the combination of commands.
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
|
|
RFC 3101 states both E-bit and N-bit need to be checked when receiving a Hello packet.
"To support the NSSA option an additional check must be made in the function
that handles the receiving of the Hello packet to verify that both the N-bit
and the E-bit found in the Hello packet's option field match the area type and
ExternalRoutingCapability of the area of the receiving interface."
This PR adds the check for the N-bit
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
|
|
Since f60a1188 we store a pointer to the VRF in the interface structure.
There's no need anymore to store a separate vrf_id field.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
|
|
I am seeing a crash of ospf6d with this stack trace:
OSPF6: Received signal 11 at 1636042827 (si_addr 0x0, PC 0x55efc2d09ec2); aborting...
OSPF6: zlog_signal+0x18c 7fe20c8ca19a 7ffd08035590 /lib/libfrr.so.0 (mapped at 0x7fe20c819000)
OSPF6: core_handler+0xe3 7fe20c90805e 7ffd080356b0 /lib/libfrr.so.0 (mapped at 0x7fe20c819000)
OSPF6: funlockfile+0x50 7fe20c7f8140 7ffd08035800 /lib/x86_64-linux-gnu/libpthread.so.0 (mapped at 0x7fe20c7e4000)
OSPF6: ---- signal ----
OSPF6: ospf6_neighbor_state_change+0xdc 55efc2d09ec2 7ffd08035d90 /usr/lib/frr/ospf6d (mapped at 0x55efc2c8e000)
OSPF6: exchange_done+0x15c 55efc2d0ab4a 7ffd08035dc0 /usr/lib/frr/ospf6d (mapped at 0x55efc2c8e000)
OSPF6: thread_call+0xc2 7fe20c91ee32 7ffd08035df0 /lib/libfrr.so.0 (mapped at 0x7fe20c819000)
OSPF6: frr_run+0x217 7fe20c8bf7f3 7ffd08035eb0 /lib/libfrr.so.0 (mapped at 0x7fe20c819000)
OSPF6: main+0xf3 55efc2cd7573 7ffd08035fc0 /usr/lib/frr/ospf6d (mapped at 0x55efc2c8e000)
OSPF6: __libc_start_main+0xea 7fe20c645d0a 7ffd08036000 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x7fe20c61f000)
OSPF6: _start+0x2a 55efc2cd706a 7ffd080360d0 /usr/lib/frr/ospf6d (mapped at 0x55efc2c8e000)
OSPF6: in thread exchange_done scheduled from ospf6d/ospf6_message.c:2264 ospf6_dbdesc_send_newone()
The stack trace when decoded is:
(gdb) l *(ospf6_neighbor_state_change+0xdc)
0x7bec2 is in ospf6_neighbor_state_change (ospf6d/ospf6_neighbor.c:200).
warning: Source file is more recent than executable.
195 on->name, ospf6_neighbor_state_str[prev_state],
196 ospf6_neighbor_state_str[next_state],
197 ospf6_neighbor_event_string(event));
198 }
199
200 /* Optionally notify about adjacency changes */
201 if (CHECK_FLAG(on->ospf6_if->area->ospf6->config_flags,
202 OSPF6_LOG_ADJACENCY_CHANGES)
203 && (CHECK_FLAG(on->ospf6_if->area->ospf6->config_flags,
204 OSPF6_LOG_ADJACENCY_DETAIL)
OSPFv3 is creating the event without a managing thread and as such
if the event is not run before a deletion event comes in memory
will be freed up and we'll start trying to access memory we should
not. Modify ospfv3 to track the thread and appropriately stop
it when the memory is deleted or it is no longer need to run
that bit of code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
ospf6d: minor struct compare issues.
|
|
removal of some of the deadcode in ospf6d.
Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
|
|
FRR should only ever use the appropriate THREAD_ON/THREAD_OFF
semantics. This is espacially true for the functions we
end up calling the thread for.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
When making the ospf6 header, let's actually fill
in all the header values
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
RFC 5187 specifies the Graceful Restart enhancement to the OSPFv3
routing protocol. This commit implements support for the GR
restarting mode.
Here's a quick summary of how the GR restarting mode works:
* GR can be enabled on a per-instance basis using the `graceful-restart
[grace-period (1-1800)]` command;
* To perform a graceful shutdown, the `graceful-restart prepare ipv6
ospf` EXEC-level command needs to be issued before restarting the
ospf6d daemon (there's no specific requirement on how the daemon
should be restarted);
* `graceful-restart prepare ospf` will initiate the graceful restart
for all GR-enabled instances by taking the following actions:
o Flooding Grace-LSAs over all interfaces
o Freezing the OSPF routes in the RIB
o Saving the end of the grace period in non-volatile memory (a JSON
file stored in `$frr_statedir`)
* Once ospf6d is started again, it will follow the procedures
described in RFC 3623 until it detects it's time to exit the graceful
restart (either successfully or unsuccessfully).
Testing done:
* New topotest featuring a multi-area OSPF topology (including stub
and NSSA areas);
* Successful interop tests against IOS-XR routers acting as helpers.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
|
The message about ignoring a one-way hello should only be logged
when the router is acting a helper for another one.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
|
Description:
Adding the following cli commands to enable/disable GR helper
functionality.
1. [no] graceful-restart helper-only [A.B.C.D]
2. [no] graceful-restart helper lsa-check-disable
3. [no] graceful-restart helper planned-only
4. [no] graceful-restart helper supported-grace-time (10-1800)
show commands:
show ipv6 ospf6 graceful-restart helper [detail] [json]
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
|
|
Description:
1. changes to process GRACE LSA packet.
2. Validation changes to enter Helper role.
3. Helper functionality during graceful restart.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
|
|
Somehow the hello message debugging code slipped outside the debug
guard. Lets just remove it.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
|
|
ospf6d : Send LSA update immediately when ospf instance is deleted
|
|
Fix: The fix is to call ospf6_write to send the packet immediately to all neighbors
Signed-off-by: kssoman <somanks@gmail.com>
|
|
Ospf6 packet debug
|
|
substitute pI6 formatter.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
|
|
Some unprotected debugs need to have macro protection,
Split these into the existing covering macro section to remove
a check per-packet from the main path.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
|
|
Coverity flagged the possibility of an overflow in the latency
calculation, ensure that 64 bit integers are used in the
calculation to avoid this error.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
|
|
When OSPFv3 router is configured in both default and non-default VRFs,
every packet destined to a non-default VRF is read twice. This makes it
impossible to establish neighborship because every DbDesc packet is
treated as duplicated and we end up infinitely exchanging DbDescs.
We should drop packets received in the default VRF if an interface we
received it on is bound to another VRF.
Same thing was done for OSPFv2 in 555691e.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
|
|
OSPFv3 socket rework
|
|
allow amount of work done by read and write threads in a single
invocation to be tuned to between 1 and 100 packets (default 20)
Signed-off-by: Pat Ruddy <pat@voltanet.io>
|
|
On transmit and receive calculate the time since the last hello was seen
and log a warning if it is late by more than the hello period.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
|
|
queue outgoing lsupdate messages to the interface tx FIFO and schedule
the ospf_write task to deal with them.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
|
|
queue outgoing lsack messages to the interface tx FIFO and schedule
the ospf_write task to deal with them.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
|
|
queue outgoing lsreq messages to the interface tx FIFO and schedule
the ospf_write task to deal with them.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
|
|
enqueue outgoing dbdesc messages to the end of the tx FIFO and
schedule the ospf6_write task to deal with them.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
|
