E.g. Cisco sends AIGP attribute as transitive, but it's wrong. Hence, the session
is teared down, because of this bgp_attr_flag_invalid() test.
Relax this check if we have `neighbor X path-attribute <discard|treat-as-withdraw>`
configured.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 714e5be9a0)
When BGP receives an SRV6_LOCATOR_ADD message from zebra, it calls the
`bgp_zebra_process_srv6_locator_add()` function to process the message.
`bgp_zebra_process_srv6_locator_add()` decodes the message first, and
then if the pointer to the default BGP instance is NULL (i.e. the
default BGP instance is not configured yet), it returns early without
doing anything and without using the decoded message information.
This commit fixes the order of the operations executed by
`bgp_zebra_process_srv6_locator_add()`. We first ensure that the default
BGP instance is ready and we return early if it is not. Then, we decode
the message and do something with the information contained in it.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
(cherry picked from commit bdc2c7bc54)
When BGP receives a `SRV6_LOCATOR_DEL` from zebra, it invokes
`bgp_zebra_process_srv6_locator_delete` to process the message.
`bgp_zebra_process_srv6_locator_delete` obtains a pointer to the default
BGP instance and then dereferences this pointer.
If the default BGP instance is not ready / not configured yet, this
pointer this pointer is `NULL` and dereferencing it causes BGP to crash.
This commit fix the issue by adding a a check to verify if the pointer
is `NULL` and returning early if it is.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
(cherry picked from commit ae3241b96d)
c-ares has deprecated ares_gethostbyname() in version 1.28.0
Replace it with ares_getaddrinfo().
This fixes a build error on Fedora 40.
Signed-off-by: Andrew Cooks <acooks.at.bda@gmail.com>
(cherry picked from commit 89a2e4d825)
ares_process(...) has been deprecated.
Replace it with ares_process_fd(...)
Signed-off-by: Andrew Cooks <acooks.at.bda@gmail.com>
(cherry picked from commit 4540fa0a3e)
ospfv3 shows this unconditionally, and ospfv2 does not show `ip ospf network ...` if the type of the interface matches the specified network.
Fixes: https://github.com/FRRouting/frr/issues/15817
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
pimd crashs while unconfigure of rp ka timer as we are trying to access
a yand dnode(suppress timer) which does not exist at the moment.
User just configured rp keepalive timer and not suppress timer,
the yang dnode would not be present. Instead of directly accessing
yang_dnode_get_unit16, first check the yang node exist using
the xpath.
Ticket: #3874971
Testing:
Before:
------
tor-11(config)# no ip pim rp keep-alive-timer 3000
vtysh: error reading from pimd: Success (0)Warning: closing connection to pimd because of an I/O error!
Broadcast message from root@tor-11 (somewhere) (Mon Apr 22 17:29:12 2024):
cumulus-core: Running cl-support for core files "pimd.25467.1713806952.core"
After:
-----
tor-11(config)# no ip pim rp keep-alive-timer 3000
tor-11(config)#
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Vijayalaxmi Basavaraj <vbasavaraj@nvidia.com>
(cherry picked from commit 0c4b7c1f1f)
In zebra_interface_nhg_reinstall zebra is checking that the
nhg is a singleton and not a blackhole nhg. This was originally
done with checking that the nexthop is a NEXTHOP_TYPE_IFINDEX,
NEXTHOP_TYPE_IPV4_IFINDEX and NEXTHOP_TYPE_IPV6_IFINDEX. This
was excluding NEXTHOP_TYPE_IPV4 and NEXTHOP_TYPE_IPV6. These
were both possible to be received and maintained from the upper
level protocol for when a route is being recursively resolved.
If we have gotten to this point in zebra_interface_nhg_reinstall
the nexthop group has already been installed at least once
and we *know* that it is actually a valid nexthop. What the
test is really trying to do is ensure that we are not reinstalling
a blackhole nexthop group( Which is not possible to even be
here by the way, but safety first! ). So let's change
to test for that instead.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 29c1ff446e)
The usage of the `bgp bestpath med missing-as-worst` command
was being accepted and applied during bestpath, but during output
of the routes affected by this it would not give any indication
that this was happening or what med value was being used.
Fixes: #15718
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit bc9885b22e)
Currently BGP attempts to send route change information
to it's peers *before* the route is installed into zebra.
This creates a bug in suppress-fib-pending in the following
scenario:
a) bgp suppress-fib-pending and bgp has a route with
2 way ecmp.
b) bgp receives a route withdraw from peer 1. BGP
will send the route to zebra and mark the route as
FIB_INSTALL_PENDING.
c) bgp receives a route withdraw from peer 2. BGP
will see the route has the FIB_INSTALL_PENDING and
not send the withdrawal of the route to the peer.
bgp will then send the route deletion to zebra and
clean up the bgp_path_info's.
At this point BGP is stuck where it has not sent
a route withdrawal to downstream peers.
Let's modify the code in bgp_process_main_one to
send the route notification to zebra first before
attempting to announce the route. The route withdrawal
will remove the FIB_INSTALL_PENDING flag from the dest
and this will allow group_announce_route to believe
it can send the route withdrawal.
For the master branch this is ok because the recent
backpressure commits are in place and nothing is going
to change from an ordering perspective in that regards.
Ostensibly this fix is also for operators of Sonic and
will be backported to the 8.5 branch as well. This will
change the order of the send to peers to be after the
zebra installation but sonic users are using suppress-fib-pending
anyways so updates won't go out until rib ack has been
received anyways.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 329d5a5cbb)
When BGP has been asked to wait for FIB installation, on route
removal a return call is likely to not have the dest since BGP
will have cleaned up the node, entirely. Let's just note that
the prefix cannot be found if debugs are turned on and move on.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 7c60314652)
If we receive an attribute that is handled by bgp_attr_malformed(), use
treat-as-withdraw behavior for unknown (or missing to add - if new) attributes.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit babb23b748)
Without this patch, we always set the BGP Prefix SID attribute flag without
checking if it's malformed or not. RFC8669 says that this attribute MUST be discarded.
Also, this fixes the bgpd crash when a malformed Prefix SID attribute is received,
with malformed transitive flags and/or TLVs.
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit ba6a8f1a31)
Null-check the vxlan-vni array info coming into zebra from
the dataplane.
Signed-off-by: Mark Stapp <mjs@cisco.com>
(cherry picked from commit 75ef259b1d)
The asan memory leak has been detected:
> Direct leak of 16 byte(s) in 1 object(s) allocated from:
> #0 0x7f9066dadd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
> #1 0x7f9066779b5d in qcalloc lib/memory.c:105
> #2 0x556d6ca527c2 in vpn_leak_zebra_vrf_sid_update_per_af bgpd/bgp_mplsvpn.c:389
> #3 0x556d6ca530e1 in vpn_leak_zebra_vrf_sid_update bgpd/bgp_mplsvpn.c:451
> #4 0x556d6ca64b3b in vpn_leak_postchange bgpd/bgp_mplsvpn.h:311
> #5 0x556d6ca64b3b in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3751
> #6 0x556d6cb9f116 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3337
> #7 0x7f906685a6b6 in zclient_read lib/zclient.c:4490
> #8 0x7f9066826a32 in event_call lib/event.c:2011
> #9 0x7f906675c444 in frr_run lib/libfrr.c:1217
> #10 0x556d6c980d52 in main bgpd/bgp_main.c:545
> #11 0x7f9065784c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Fix this by freeing the previous memory chunk.
Fixes: b72c9e1475 ("bgpd: cli for SRv6 SID alloc to redirect to vrf (step4)")
Fixes: 527588aa78 ("bgpd: add support for per-VRF SRv6 SID")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit eea8a8ae24)
BGP is storing outgoing updates in a couple of different
fifo's. This is to ensure proper packet packing of
all bgp_dests that happen to use the same attribute.
How it's all put together currently: On initial update
BGP walks through all the bgp_dest's in a table. For each
path being sent a bgp_advertise is created. This bgp_advertise
is placed in fifo order on the bgp_synchronize->update queue.
The bgp_advertise has a pointer to the bgp_advertise_attr which
is associated iwth the actual attribute that is being sent to
it's peer. In turn this bgp_advertise is placed in a fifo off
of the bgp_advertise_attr structure. As such as we have paths
that share an attribute, the path/dest is placed on the
bgp_syncrhonize->update fifo as well as being placed on the fifo
associated with the advertised attribute.
On actual creation of a packet. The first item in the
bgp_synchronize->update fifo is popped. The bgp_advertise_attr
pointer is grabbed, we fill out the nlri part of the bgp packet
and then walk the bgp_advertise_attr fifo to place paths/dests in
the packet. As each path/dest is placed in the packet it is removed
from both the bgp_synchronize->update fifo and the bgp_advertise_attr
fifo.
The whole point of this change is to switch the *next, *prev
pointers in the bgp_advertise structure with a typesafe data
structure.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit b2e0c12d72)
Whenever a link up change was detected on a macvlan device where
the linked device wasn't visible in the namespace zebra was
running in, the linked zebra interface was NULL. This was already
handled in the event of a link down, but was ommitted from the
upside. Added the same null check to the up-side.
Signed-off-by: Tomi Salminen <tlsalmin@gmail.com>
(cherry picked from commit bdf6a9ba81)
If using with `bgp listen range ... peer-group x`, default_rmap[afi][safi] is not
updated, and after the hard-reset in other side, this is flushed and never updated
again without restarting the sender BGP daemon.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 4f1e2dcd7a)
Split zebra's vrf_terminate() into disable() and delete() stages.
The former enqueues all events for the dplane thread.
Memory freeing is performed in the second stage.
Signed-off-by: Alexander Skorichenko <askorichenko@netgate.com>
(cherry picked from commit 444ce317b2)
Customer has this valgrind trace:
Direct leak of 2829120 byte(s) in 70728 object(s) allocated from:
0 in community_new ../bgpd/bgp_community.c:39
1 in community_uniq_sort ../bgpd/bgp_community.c:170
2 in route_set_community ../bgpd/bgp_routemap.c:2342
3 in route_map_apply_ext ../lib/routemap.c:2673
4 in subgroup_announce_check ../bgpd/bgp_route.c:2367
5 in subgroup_process_announce_selected ../bgpd/bgp_route.c:2914
6 in group_announce_route_walkcb ../bgpd/bgp_updgrp_adv.c:199
7 in hash_walk ../lib/hash.c:285
8 in update_group_af_walk ../bgpd/bgp_updgrp.c:2061
9 in group_announce_route ../bgpd/bgp_updgrp_adv.c:1059
10 in bgp_process_main_one ../bgpd/bgp_route.c:3221
11 in bgp_process_wq ../bgpd/bgp_route.c:3221
12 in work_queue_run ../lib/workqueue.c:282
The above leak detected by valgrind was from a screenshot so I copied it
by hand. Any mistakes in line numbers are purely from my transcription.
Additionally this is against a slightly modified 8.5.1 version of FRR.
Code inspection of 8.5.1 -vs- latest master shows the same problem
exists. Code should be able to be followed from there to here.
What is happening:
There is a route-map being applied that modifes the outgoing community
to a peer. This is saved in the attr copy created in
subgroup_process_announce_selected. This community pointer is not
interned. So the community->refcount is still 0. Normally when
a prefix is announced, the attr and the prefix are placed on a
adjency out structure where the attribute is interned. This will
cause the community to be saved in the community hash list as well.
In a non-normal operation when the decision to send is aborted after
the route-map application, the attribute is just dropped and the
pointer to the community is just dropped too, leading to situations
where the memory is leaked. The usage of bgp suppress-fib would
would be a case where the community is caused to be leaked.
Additionally the previous commit where an unsuppress-map is used
to modify the outgoing attribute but since unsuppress-map was
not considered part of outgoing policy the attribute would be dropped as
well. This pointer drop also extends to any dynamically allocated
memory saved by the attribute pointer that was not interned yet as well.
So let's modify the return case where the decision is made to
not send the prefix to the peer to always just flush the attribute
to ensure memory is not leaked.
Fixes: #15459
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit addff17a55)
If unsuppress-map is setup for outgoing peers, consider that
policy is being applied as for RFC 8212.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 6814401c47)
Currently in subgroup_default_originate the attr.aspath
is set in bgp_attr_default_set, which hashs the aspath
and creates a refcount for it. If this is a withdraw
the subgroup_announce_check and bgp_adj_out_set_subgroup
is called which will intern the attribute. This will
cause the the attr.aspath to be set to a new value
finally at the bottom of the function it intentionally
uninterns the aspath which is not the one that was
created for this function. This reduces the other
aspath's refcount by 1 and if a clear bgp * is issued
fast enough the aspath for that will be removed
and the system will crash.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit e613e12f12)
6vPE enables the announcement of IPv6 VPN prefixes through an IPv4 BGP
session. In this scenario, the next hop addresses for these prefixes are
represented in an IPv4-mapped IPv6 format, noted as ::ffff:[IPv4]. This
format indicates to the peer that it should route these IPv6 addresses
using information from the IPv4 nexthop. For example:
> Path Attribute - MP_REACH_NLRI
> [...]
> Address family identifier (AFI): IPv6 (2)
> Subsequent address family identifier (SAFI): Labeled VPN Unicast (128)
> Next hop: RD=0:0 IPv6=::ffff:192.0.2.5 RD=0:0 Link-local=fe80::501d:42ff:feef:b021
> Number of Subnetwork points of attachment (SNPA): 0
This rule is set out in RFC4798:
> The IPv4 address of the egress 6PE router MUST be encoded as an
> IPv4-mapped IPv6 address in the BGP Next Hop field.
However, in some situations, bgpd sends a standard nexthop IPv6 address
instead of an IPv4-mapped IPv6 address because the outgoing interface for
the BGP session has a valid IPv6 address. This is problematic because
the peer router may not be able to route the nexthop IPv6 address (ie.
if the outgoing interface has not IPv6).
Fix the issue by always sending a IPv4-mapped IPv6 address as nexthop
when the BGP session is on IPv4 and address family IPv6.
Link: https://datatracker.ietf.org/doc/html/rfc4798#section-2
Fixes: 92d6f76 ("lib,zebra,bgpd: Fix for nexthop as IPv4 mapped IPv6 address")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit 0325116a27)
This test uses the connected ipv4 mapped ipv6 prefix
to resolve the received BGP routes.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: François Dumontet <francois.dumontet@6wind.com>
(cherry picked from commit 4d7df91752)
