Donald Sharp [Mon, 30 Jan 2023 21:02:23 +0000 (16:02 -0500)]
bgpd: bgp_update and bgp_withdraw never return failures
These two functions always return 0. As such any and all
tests against this make no sense. Remove the return 0
to a void and follow the chain, logically, to remove all
the dead code.
Donald Sharp [Sat, 28 Jan 2023 14:32:34 +0000 (09:32 -0500)]
babeld: During intf startup, ignore address already in use
When listening on a multicast group. No need to actually
fail the operation when it's already being used.
Let's not treat the Address already in use error message
as one that is stopping everything from working. Especially
since multiple interface events cause this to happen.
Without this, if config is read in before full connection
to zebra, babel will never establish neighbors.
Trey Aspelund [Wed, 25 Jan 2023 18:25:20 +0000 (13:25 -0500)]
bgpd: move tunnel-ip comparison into handler
Moves the old/new IP comparison into handle_tunnel_ip_change instead of
expecting the caller to do the check on their own.
Also changes handle_tunnel_ip_change to return void since it only ever
returned 0 in all cases.
Trey Aspelund [Wed, 25 Jan 2023 18:07:43 +0000 (13:07 -0500)]
bgpd: only unimport routes if tunnel-ip changes
When processing a new local VNI, we were always walking the global EVPN
table to look for routes that needed to be removed due to a martian
nexthop change (specifically a tunnel-ip change).
Since the martian TIP table is global (all VNIs) + the walk is also in
the global table (all VNIs), we can trust that any new TIP from any VNI
would result in routes getting removed from the global table and
unimported from all live (L2)VNIs.
i.e.
The only time this update is actionable is if we are adding/removing an
IP from the martian TIP table, and we do not need to walk the table for
normal refcount adjustments.
1. Renamed "gates" to "nexthops"
2. Displaying afi of the nexthops being dispalyed in place of
"nexthops" JSON object in the old JSON output
3. Calling show_route_nexthop_helper() and show_nexthop_json_helper()
instead of print_nh() inorder to keeps the fields in "nexthops"
JSON object in sync with "nexthops" JSON object of
"show nexthop-group rib json".
Updated vtysh:
r1# show ip nht
192.168.0.2
resolved via connected
is directly connected, r1-eth0 (vrf default)
Client list: static(fd 28)
192.168.0.4
resolved via connected
is directly connected, r1-eth0 (vrf default)
Client list: static(fd 28)
Daemons like staticd already implement nexthop zapi (un)registration. b7ca809d1c ("lib: BFD automatic source selection") has implemented a
concurrent nexthop (un)registration. Some nexthop could be unregistred
by the bfd whereas they were still needed by the daemon.
Let the deamons deal with nexthop zapi (un)registration.
Louis Scalbert [Mon, 23 Jan 2023 10:57:57 +0000 (11:57 +0100)]
lib: do not reopen a zclient socket for bfd
b7ca809d1c ("lib: BFD automatic source selection") has added a dedicated
zclient socket for nht tracking. Since the bfd lib is used by daemons
that already has a zclient socket, those daemons has now a second
zclient socket. However, zebra does not distinguish the two zclient
sessions. For example, the interfaces are asked a second via
zebra_message_send(zclient, ZEBRA_INTERFACE_ADD, VRF_DEFAULT) in
zclient_start(). As a result, callbacks functions like bgp_ifp_create()
are called a second time, which causes some processing overhead and
might cause bugs.
Re-use the existing zclient socket for nht tracking.
Note that BFD automatic source selection is only currently implemented
in staticd. Other daemons will require to add the following in their
ZEBRA_NEXTHOP_UPDATE callback function:
> if (zclient->bfd_integration)
> bfd_nht_update(&matched, &nhr);
Louis Scalbert [Mon, 23 Jan 2023 17:03:58 +0000 (18:03 +0100)]
topotests: fix bgp_vpnv4_noretain
Fix the following issues:
- two tests are done in one function. Dispatch the tests in two
functions to help the test debug.
- the first test passes even if a third prefix is not filtered. Match
the exact to avoid false positive.
- the expected values contains variable like version. Do no check
variable values.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Philippe Guibert [Mon, 23 Jan 2023 15:31:12 +0000 (16:31 +0100)]
bgpd: fix when route-map changes the link local nexthop for vpnv6
This fix updates the nexthop length of a bgp update to be
transmitted to a remote peer. Before the previous commit,
the ipv6 nexthop length was internally set to 32 bytes which
was not correct, as it should be 48 bytes which is conform
to the vpnv6 encoding format.
However, without the previous match, even if internally, the
nexthop length was set to 32, the real nexthop length was set
to 48 bytes, and everything was operating ok.
Now, if we use the following route-map, and attach it to
outgoing for vpnv6 address family, then we have a malformed
packet detected, and the peering breaks.
> route-map rmap permit 1
> set ipv6 next-hop global 5:5::3:6
> set ipv6 next-hop local fe80:55::333:222
Maintain the mp_nexthop_len to 48 bytes if it was already set
to 48 previously.
Chirag Shah [Tue, 24 Jan 2023 06:18:24 +0000 (22:18 -0800)]
bgpd: evpn route detail json display non prett
For BGP evpn route table detail json to use
non pretty form of display.
Problem:
In scaled evpn route table detail json dump
occupies high resources (CPU + memory) of the system.
In high scale evpn route dump using pretty form
hogs CPU for a while which can trigger watchfrr
to kill bgpd.
Solution:
Avoid pretty JSON print for detail version dump
Spoorthi K [Mon, 23 Jan 2023 03:34:04 +0000 (09:04 +0530)]
zebra_fpm: Add support for other protocols in fpm:netlink
fpm:netlink format doesn't indicate the protocol information
in routes of BGP, OSPF and other protocols. Routes of those
protocols just indicate protocol as zebra.
The below route is actually BGP route but 'proto': 11
indicates that it is zebra.
Philippe Guibert [Mon, 23 Jan 2023 15:27:45 +0000 (16:27 +0100)]
bgpd: encode properly vpnv6 nexthop
This change updates the nexthop attribute length
accordingly to the safi used. Actually, with the
previous commit, the length calculated was not
aligned with the real nexthop length. Such packet
received by remote peer was malformed, and this
was resulting in breaking vpnv6 peering.
Fix this by updating appropriately the real
nexthop length.
Rafael Zalamena [Thu, 19 Jan 2023 15:16:11 +0000 (12:16 -0300)]
*: introduce function for sequence numbers
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).
Yuxiang Zhu [Wed, 18 Jan 2023 19:16:22 +0000 (19:16 +0000)]
babeld: Fix --terminal option
babeld's `--terminal` option doesn't work because it replaces `stdin`
with `/dev/null`. It seems to me this function can be removed as `frr_run`
handles that in daemon mode.
Philippe Guibert [Thu, 19 Jan 2023 10:04:37 +0000 (11:04 +0100)]
bgpd: fix vpnv6 nexthop encoding
In ipv6 vpn, when the global and the local ipv6 address are received,
when re-transmitting the bgp ipv6 update, the nexthop attribute
length must still be 48 bytes.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Ryoga Saito [Thu, 19 Jan 2023 11:51:44 +0000 (20:51 +0900)]
bgpd: Skip RD match if ACCEPT_OWN is not enabled
RFC7611 introduces new extended community ACCEPT_OWN and is already
implemented for FRR in the previous PR. However, this PR broke
compatibility about importing VPN routes.
Let's consider the following situation. There are 2 routers and these
routers connects with iBGP session. These routers have two VRF, vrf10
and vrf20, and RD 0:10, 0:20 is configured as the route distinguisher
of vrf10 and vrf20 respectively.
In this situation, the VPN routes from R1's VRF10 should be imported to
R2's VRF10 and the VPN routes from R2's VRF10 should be imported to R2's
VRF20. However, the current implementation of ACCEPT_OWN will always
reject routes if the RD of VPN routes are matched with the RD of VRF.
Similar issues will happen in local VRF2VRF route leaks. In such cases,
the route reaked from VRF10 should be imported to VRF20. However, the
current implementation of ACCEPT_OWN will not permit them.
Ryoga Saito [Thu, 19 Jan 2023 11:51:33 +0000 (20:51 +0900)]
tests: Add test to check importing routes to VRF
After implementing ACCEPT_OWN extended community, bgpd can't import VPN
routes to the VRFs whose RD is matched with that of VPN routes. This
commit adds new test to check the effect of the next commit.
Donald Sharp [Thu, 19 Jan 2023 16:43:12 +0000 (11:43 -0500)]
bgpd: Limit peer output queue length like input queue length
Consider this scenario:
Lots of peers with a bunch of route information that is changing
fast. One of the peers happens to be really slow for whatever
reason. The way the output queue is filled is that bgpd puts
64 packets at a time and then reschedules itself to send more
in the future. Now suppose that peer has hit it's input Queue
limit and is slow. As such bgp will continue to add data to
the output Queue, irrelevant if the other side is receiving
this data.
Let's limit the Output Queue to the same limit as the Input
Queue. This should prevent bgp eating up large amounts of
memory as stream data when under severe network trauma.
Rafael Zalamena [Thu, 19 Jan 2023 15:09:29 +0000 (12:09 -0300)]
pimd: fix mtracebis tool warning
Use `getpid()` to initialize the sequence number. This change silences
Coverity Scan warning about truncated use of `time()` which in this case
is not a problem.
Rafael Zalamena [Thu, 19 Jan 2023 13:32:18 +0000 (10:32 -0300)]
zebra: fix possible null dereference
Don't attempt to dereference `ifp` directly if it might be null: there
is a check right before this usage: `ifp ? ifp->info : NULL`.
In this context it should be safe to assume `ifp` is not NULL because
the only caller of this function checks that for this `ifindex`. For
consistency we'll check for null anyway in case this ever changes (and
with this the coverity scan warning gets silenced).
Kuldeep Kashyap [Mon, 21 Nov 2022 07:47:33 +0000 (23:47 -0800)]
tests: Fix for multicast_pim6_static_rp tests failure
Multicast pim6 static RP tests are failing
when run in parallel using micronet. There
are APIs to clean mcast traffic before
starting new test but these cleanups
are not needed when socat is used.
projects / mirror_frr.git / log