Replaces next-hop-self keyword "all" with "force" to match the CLI.
Also mentions third-party next-hops will be bypassed by next-hop-self.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Adds a knob that sets the time between loc-rib scans for conditional
advertisement.
I chose the range (5-240) because 1 second seems dumb and too easy to
hurt yourself at even moderate scale, 5 seconds you can still hurt
yourself but I could see a use case for it, and 4 minutes should be
enough for anyone (tm)
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
There are two problems with the current code for processing the attached
bit:
- we should process it when acting both a level-1-only and level-1-2
- we should add the default route when we don't have L2 adjacensies, not
when we don't have other routers configured on the device
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Current code related to setting of the attached bit checks for existence
of L2 adjacencies in other routers configured on the device. This makes
no sense. We should check for L2 adjacencies in the same router where we
have L1 adjacencies.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
There is no need to test for null values in the hash compare
function as that we are guaranteed to send in data in
the hash compare functions.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
There's a delay in FreeBSD between issuing a command to leave a
multicast group and an actual leave. If we execute "no router ospf6" and
"router ospf6" fast enough, we can end up in a situation when OS
performs the leave later than it performs the join and the interface
remains without a multicast group.
Instead of counting on a one second delay, we must wait until the
interface actually leaves the group.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
There is no need to test for null values in the hash compare
function as that we are guaranteed to send in data in
the hash compare functions.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When setting bgp configuration using peers referencing link local
ipv6 addresses, the bgp should be able to handle incoming bgp
connections, and find out the appropriate interface where the
connection comes from.
ipv6 link local sessions work by using bgp unnumbered interfaces
config, but it does not work if we have a shared media with
multiple potential link local ipv6 addresses on the network.
The fix consists in finding out the appropriate interface, when
the local configuration references a link local ipv6 addresses,
and the source address used references an interface. below
configuration illustrates what can be done then:
neighbor fe80::4113:5bba:2b61:b20c remote-as 55
neighbor fe80::4113:5bba:2b61:b20c update-source eth0
note: this change does not solve the ability for such config to
create an outgoing connection to remote peer (as the link local
ipv6 address config does not indicate which interface to use).
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
If a static route is added to a not-yet-existing VRF, the blackhole type
is not initialized. Initialization must be done before the VRF existence
check.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
Move code to its own function and remove most of the code indentation
(e.g. test for failure and quit as soon as possible).
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Move `is_default_prefix` variations to `lib/prefix.h` and make the code
use the library version instead of implementing it again.
NOTE
----
The function was split into per family versions to cover all types.
Using `union prefixconstptr` is not possible due to static analyzer
warnings which cause CI to fail.
The specific cases that would cause this failure were:
- Caller used `struct prefix_ipv4` and called the generic function.
- `is_default_prefix` with signature using `const struct prefix *` or
`union prefixconstptr`.
The compiler would complain about reading bytes outside of the memory
bounds even though it did not take into account the `prefix->family`
part.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
This code has been wrong ~ever (according to git history). There are 3
conditional blocks with the added assertion that both the LSA and the
vertex being checked can't both be network LSAs.
The third block is clearly assuming both LSA and vertex are router
LSAs b/c it is accessing the backlink and lsdesc as router lsdesc's also
making sure both are p2p links (which they would have to be to point at
each other).
The programming error here is that (A && B) == False does NOT imply !A,
but the code is written that way.
So we end up in the third block one of LSA or vertex being network LSAs
rather easily (whenever that is the case and the desc isn't the backlink
being sought).
This was caught by ASAN b/c the lsdesc and backlinks are being accessed
(> 4 byte field offsets) as if they were router lsdesc's in the third
block, when in fact one of them is a network lsdesc which is only 4
bytes long -- so ASAN flags the access beyond bounds.
Signed-off-by: Christian Hopps <chopps@labn.net>
Problem: Sometimes the configured Local GR state is not reflected in
show command and peer node. This is causing failures in few of the
BGP-GR topotests.
RCA: This problem is seen when the configuration of local GR state
happens when the BGP session is in OpenSent state and moves to
Established after the configuration is complete.
When the session gets established, we move the GR state value from stub peer
to the config peer. This will result in overriding the GR state to
previous value.
Fix: The local GR state is modified only through CLI configuration and
does not change during BGP FSM transition. In this case it is not necessary
to transfer the GR state value from stub peer to config peer. This way we
can ensure that always the most recent config value is present in peer
datastructure.
Signed-off-by: Prerana-GB <prerana@vmware.com>
We are sending up to ZAPI_MESSAGE_OPAQUE_LENGTH but checking
for one less. We know the data will fit in it to that size.
Also we have asserts on the write to ensure we don't go over
it
Fixes: #8995
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There's nothing that can be done here with an error. Try to make
Coverity understand that this is intentional.
(I don't know if the `(void)` will actually fix the coverity warning,
but I don't really have a better way to figure it out beyond just
getting this merged and waiting for a result...)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This is pretty much common sense ("runtime knobs are easier to adjust
than a compile-time setting"), but maybe it should be said just for
reference.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Issue: Crash observed when LSAs are removed from LSDB after max age
when there is no area configured.
(gdb) bt
0 raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
1 0x00007fdb190548bc in core_handler (signo=6, siginfo=0x7ffdd2f5a470, context=<optimized out>) at lib/sigevent.c:262
2 <signal handler called>
3 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
4 0x00007fdb185ad921 in __GI_abort () at abort.c:79
5 0x00007fdb1907f199 in _zlog_assert_failed (xref=xref@entry=0x55f30902aa20 <_xref.21999>, extra=extra@entry=0x0) at lib/zlog.c:581
6 0x000055f308dc4f78 in ospf6_asbr_lsa_remove (lsa=0x55f30a7546d0, asbr_entry=0x0) at ospf6d/ospf6_asbr.c:696
7 0x000055f308dd8f0d in ospf6_lsdb_remove (lsa=0x55f30a7546d0, lsdb=lsdb@entry=0x55f30a73d300) at ospf6d/ospf6_lsdb.c:166
8 0x000055f308dd9701 in ospf6_lsdb_maxage_remover (lsdb=0x55f30a73d300) at ospf6d/ospf6_lsdb.c:376
9 0x000055f308dee724 in ospf6_maxage_remover (thread=<optimized out>) at ospf6d/ospf6_top.c:603
10 0x00007fdb1906520d in thread_call (thread=thread@entry=0x7ffdd2f5ae90) at lib/thread.c:1919
11 0x00007fdb19023e48 in frr_run (master=0x55f30a569b70) at lib/libfrr.c:1155
12 0x000055f308dc09b6 in main (argc=6, argv=0x7ffdd2f5b198, envp=<optimized out>) at ospf6d/ospf6_main.c:235
(gdb)
Steps to reproduce the issue:
1. router ospf6
2. redistribute static
3. ipv6 route 1::1/128 Null0
4. no redistribute static
5. wait for Max aged LSA to flush
6. Check DB, crash occurs.
RCA:
Crash occurred while accessing listgetdata(listhead(ospf6->area_list))
When there is no area attached to any of the interface listhead(ospf6->area_list)
is NULL. Therefore it crashed due to NULL access.
Fix:
Check before accessing null pointer.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
