Rafael Zalamena [Tue, 2 Nov 2021 21:54:23 +0000 (18:54 -0300)]
bgpd: fix BFD configuration update on TTL change
When altering the TTL of a eBGP peer also update the BFD
configuration. This was only working when the configuration happened
after the peer connection had been established.
pimd: In Prune Pending state, the holdtime change is not taking effect
Problem Statement:
In Prune pending state, when Join is received, and there is hold timer change
the Expiry timer is not getting updated with new Hold timer.
Root Cause:
When thread_add_timer function is called and the thread is already in the list
the thread api just returns, it does not modify the timer value.
So when we want to change the timer, we need to first call THREAD_OFF and then
call thread_add_timer.
The Expiry timer thread is not cancelled in PIM_IFJOIN_PRUNE_PENDING state,
therefore the timer change is not taking effect.
Hiroki Shirokura [Mon, 25 Oct 2021 23:36:14 +0000 (23:36 +0000)]
lib: fix srv6 route hardcode with BGP
zclient_send_localsid is called by various routing protocol daemons. To set the
srv6 endpoint function. Fix a hard-coded error in the initial implementation.
Before this PR, the srv6 function will be registered to zebra as a BGP route
even if isisd executes zclient_send_localsid.
Abhishek Naik [Tue, 19 Oct 2021 23:45:26 +0000 (23:45 +0000)]
bgpd: Reset dynamic peer counter
Dynamic peer count is inconsistent in
"show bgp summary json" and "show bgp summary failed json" due to
dynamic peer counter 'dn_count' being reused without resetting
Igor Ryzhov [Mon, 18 Oct 2021 14:16:35 +0000 (17:16 +0300)]
ospfd: fix crash when creating vlink in unknown vrf
if_create_name crashes when vrf_id is VRF_UNKNOWN:
```
nfware# conf t
nfware(config)# router ospf vrf doesnt-exist
nfware(config-router)# area 1.1.1.1 virtual-link 2.2.2.2
vtysh: error reading from ospfd: Success (0)Warning: closing connection to ospfd because of an I/O error!
```
Rafael Zalamena [Mon, 4 Oct 2021 21:10:58 +0000 (18:10 -0300)]
lib: prevent gRPC assert on missing YANG node
`yang_dnode_get` will `assert` if no YANG node/model exist, so lets test for
its existence first before trying to access it.
This `assert` is only acceptable for internal FRR usage otherwise we
might miss typos or unmatching YANG models nodes/leaves. For gRPC usage
we should let users attempt to use non existing models without
`assert`ing.
In startup, zebra would dump interface information from Kernel in 3
steps w/o lock: step1, get interface information; step2, get interface
ipv4 address; step3, get interface ipv6 address.
If any interface gets added after step1, but before step2/3, zebra
would get extra interface addresses in step2/3 that has not been added
into zebra in step1. Returning error in the referenced interface lookup
would cause the startup interface retrieval to be incomplete.
Igor Ryzhov [Fri, 8 Oct 2021 21:22:31 +0000 (00:22 +0300)]
lib: set type for newly created interfaces
Currently, the ll_type is set only in `netlink_interface` which is
executed only during startup. If the interface is created when the FRR
is already running, the type is not stored.
Igor Ryzhov [Tue, 5 Oct 2021 10:27:39 +0000 (13:27 +0300)]
yang: replace an empty pattern with a zero-length restriction
No functional difference, but `length "0"` is more comprehensible.
Suggested-by: Christian Hopps <chopps@labn.net> Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
(cherry picked from commit 405ebe45cf111376fe33bad45b4ec836e0157d9f)
rgirada [Tue, 5 Oct 2021 07:52:36 +0000 (00:52 -0700)]
ospf6d: ospf6d is crashing upon receiving duplicated Grace LSA.
Description:
When grace lsa received, DUT is adding
the copy of the lsas to all nbrs retransmission list as part of
flooding procedure and subsequently incrementing the rmt counter in
the original the LSA. This counter is supposed to be decremented
when ack is received by nbr and the lsa will be removed from retransmission list.
But in our current scenario,
Step-1:
When GR helper is disabled, if DUT receives the grace lsa
it adds the lsa copy to nbrs retransmission list but original
LSA will be discarded since GR helper disabled.
Step-2:
GR helper enabled and DUT receives the grace lsa, as part
of flooding process all nbrs have same copy of lsa in their
corresponding rmt list which was added in step -1 due to this
the corresponding rmt counter in the original lsa is not getting
incremented.
Step-3:
If the same copy of the grace lsa received by DUT, It considers
as implicit ack from nbr if the same copy of the lsa exits in its
rmt list and subsequently decrement the rmt counter.
Since counter is zero (because of step-1 and 2) , it is asserting while decrement.
Mark Stapp [Mon, 9 Aug 2021 15:57:17 +0000 (11:57 -0400)]
lib: avoid double-free in zmq wrapper callbacks
There were paths where the zmq wrapper lib could call user
callbacks that would free the internal context struct, but the
context was then used in the lib code. Use a boolean to avoid
freeing the context within an application callback.
Restore logic that frees the context within the 'cancel' api.
Mark Stapp [Mon, 9 Aug 2021 15:55:15 +0000 (11:55 -0400)]
lib: clear caller's pointer when freeing context struct
The zeromq lib wrapper uses an internal context struct to help
interact with the libfrr event mechanism. When freeing that
context struct, ensure the caller's pointer is also cleared.
Igor Ryzhov [Tue, 5 Oct 2021 14:38:21 +0000 (17:38 +0300)]
isisd: fix redistribute CLI
Currently, it is possible to configure IPv6 protocols for IPv4
redistribution and vice versa in CLI. The YANG model doesn't allow this
so the user receives the following error:
```
nfware(config-router)# redistribute ipv4 ospf6 level-1
% Failed to edit configuration.
YANG error(s):
Invalid enumeration value "ospf6".
Invalid enumeration value "ospf6".
Invalid enumeration value "ospf6".
YANG path: Schema location /frr-isisd:isis/instance/redistribute/ipv4/protocol.
```
Let's make CLI more user-friendly and allow only supported protocols in
redistribution commands.
Donald Sharp [Mon, 4 Oct 2021 12:37:16 +0000 (08:37 -0400)]
ospf6d: Ensure expire thread is properly stopped
The lsa->expire thread is for keeping track of when we
are expecting to expire(remove/delete) a lsa. There
are situations where we just decide to straight up
delete the lsa, but we are not ensuring that the
lsa is not already setup for expiration.
In that case just stop the expiry thread and
do the deletion.
Additionally there was a case where ospf6d was
just dropping the fact that a thread was already
scheduled for expiration. In that case we
should just setup the timer again and it will
reset it appropriately.
Fixes: #9721 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Low overhead bgp-evpn TPs have been added which push data out in a binary
format -
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
root@switch:~# lttng list --userspace |grep "frr_bgp:evpn"
frr_bgp:evpn_mh_nh_rmac_zsend (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint)
frr_bgp:evpn_mh_nh_zsend (loglevel: TRACE_INFO (6)) (type: tracepoint)
frr_bgp:evpn_mh_nhg_zsend (loglevel: TRACE_INFO (6)) (type: tracepoint)
frr_bgp:evpn_mh_vtep_zsend (loglevel: TRACE_INFO (6)) (type: tracepoint)
frr_bgp:evpn_bum_vtep_zsend (loglevel: TRACE_INFO (6)) (type: tracepoint)
frr_bgp:evpn_mac_ip_zsend (loglevel: TRACE_INFO (6)) (type: tracepoint)
root@switch:~#
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
In addition to the tracepoints a babeltrace python plugin for pretty
printing (binary data is converted into grepable strings). Sample usage -
frr_babeltrace.py trace_path
David Lamparter [Mon, 27 Sep 2021 08:33:33 +0000 (10:33 +0200)]
pimd: fix UAF/heap corruption in BSM code
This `XFREE()` call is in plainly in the wrong spot. `rp_all` (the
224.0.0.0/4 entry) isn't supposed to be free'd ever, and the
conditional above makes quite clear that it remains in use.
It may be possible to exploit this as a heap corruption bug, maybe even
as RCE. I haven't tried; I randomly noticed this while working on the
BSM code. Luckily this code is only run by the CLI for the clear
command, so the surface is very small.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Donald Sharp [Sun, 26 Sep 2021 23:36:03 +0000 (19:36 -0400)]
bgpd: Don't lookup paf structure get straight to the point
The paf data structure is stored based upon an internal
bgp enum. The code is looking over all AFI/SAFI's and
doing a paf_af_find which then calls afindex to find
the right paf structure. Let's just loop over the
peer->peer_af_array[] and cut straight to the chase.
Under some loads the paf_af_find was taking up 6%
of the run time. This removes it entirely.
Converting bgp_dest_lock_node/bgp_dest_unlock_node to non-inlined function
because LTTng can't work properly with inlined and the compiler does not like
it.
Not sure how it would be with the performance, but let's see.
Louis Scalbert [Thu, 10 Jun 2021 09:30:05 +0000 (11:30 +0200)]
ospf6d: reset areas and redistribution at router-id modification
The ospf6 router-id is provided by order of preference by:
ospf6d itself if the "ospf6 router-id X.X.X.X" command is set.
- zebra. If the "ip router-id X.X.X.X" zebra command is set, the
configured IP is provided as the ID or alternatively the highest
loopback IPv4 address or else the highest interface IPv4 address.
The running ospf6 router-id is stored in ospf6->router-id.
ospf6->router-id can change in the following conditions:
- A configuration change provides a new router-id value according to
the above rules. ospf6->router-id is updated to the new value if
there is no adjacency in FULL state. Otherwise, the ospf6d process
must be restarted to take the new router-id into account.
- On startup of both zebra and ospf6d, if ospf6d has not yet received a
valid router-id, ospf6d->router-id is set to 0 (i.e. 0.0.0.0). Then,
zebra notifies ospf6d that the router-id is available.
At ospf6->router-id, the current behavior of ospf6d is the following:
- The self generated LSAs that refer to the previous router-id as the
advertising router are kept.
- Self generated LSAs are created with router-id value.
- LSAs from the redistribution that refer to the previous router-id are
kept and no new redistribution LSAs are created.
As a consequence, the routers in the ospf6 areas will get incorrect
LSAs and might not be able to install prefixes of those LSAs into their
RIB.
This fix solves this issue by resetting the areas and the redistribution
when ospf6->router-id updated.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
projects / mirror / frr.git / log