Somehow the hello message debugging code slipped outside the debug
guard. Lets just remove it.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
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>
the realloc man page:
If ptr is NULL, then the call is equivalent to malloc(size)
This should be sufficient for our needs to not have to have
XMALLOC and XREALLOC
Signed-off-by: Donald Sharp <sharpd@nvidia.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>
Some BGP updates received by BGP invite local router to
install a route through itself. The system will not do it, and
the route should be considered as not valid at the earliest.
This case is detected on the zebra, and this detection prevents
from trying to install this route to the local system. However,
the nexthop tracking mechanism is called, and acts as if the route
was valid, which is not the case.
By detecting in BGP that use case, we avoid installing the invalid
routes.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.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>
Add `match src-port (1-65535)` and `match dst-port (1-65535)`
commands to allow pbr to pass these values down to zebra.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Start the inclusion of src_prt and dst_prt in
the internal data structures. At this point
we do not do anything with the data other
than pass down what we have stored in pbrd.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
