| Age | Commit message (Collapse) | Author |
|---|
|
BT:
```
3 <signal handler called>
4 0x00005616837546fc in bgp_static_update (bgp=bgp@entry=0x5616865eac50, p=0x561686639e40,
bgp_static=0x561686639f50, afi=afi@entry=AFI_IP6, safi=safi@entry=SAFI_UNICAST) at ../bgpd/bgp_route.c:7232
5 0x0000561683754ad0 in bgp_static_add (bgp=0x5616865eac50) at ../bgpd/bgp_table.h:413
6 0x0000561683785e2e in no_bgp_network_import_check (self=<optimized out>, vty=0x5616865e04c0,
argc=<optimized out>, argv=<optimized out>) at ../bgpd/bgp_vty.c:4609
7 0x00007fdbcc294820 in cmd_execute_command_real (vline=vline@entry=0x561686663000,
```
The program encountered a SEG FAULT when attempting to access pi->extra->vrfleak->bgp_orig because
pi->extra->vrfleak was NULL.
```
(gdb) p pi->extra->vrfleak
$1 = (struct bgp_path_info_extra_vrfleak *) 0x0
(gdb) p pi->extra->vrfleak->bgp_orig
Cannot access memory at address 0x8
```
Added NOT NULL check on pi->extra->vrfleak before accessing pi->extra->vrfleak->bgp_orig
to prevent the segmentation fault.
Signed-off-by: Manpreet Kaur <manpreetk@nvidia.com>
(cherry picked from commit bc1008b970541c090e36fc1d50c720df822fcb99)
|
|
In bgp_show_table_rd(), the is_last argument is determined using the
expression "next == NULL" to check if the RD table is the last one. This
helps ensure proper JSON formatting.
However, if next is not NULL but is no longer associated with a BGP
table, the JSON output becomes malformed.
Updates the condition to also verify the existence of the next bgp_dest
table.
Fixes: 1ae44dfcba ("bgpd: unify 'show bgp' with RD with normal unicast bgp show")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit cf0269649cdd09b8d3f2dd8815caf6ecf9cdeef9)
|
|
This reverts commit a73b0f88c7715bfcf5dc8ffd46d2fd0bbc9a8aff.
|
|
draft-uttaro-idr-bgp-oad says:
Extended communities which are non-transitive across an AS boundary MAY be
advertised over an EBGP-OAD session if allowed by explicit policy configuration.
If allowed, all the members of the OAD SHOULD be configured to use the same
criteria.
For example, the Origin Validation State Extended Community, defined as
non-transitive in [RFC8097], can be advertised to peers in the same OAD.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit f2759c46ceda2a5f13b40213381baf71997b6b87)
# Conflicts:
# bgpd/bgp_route.c
|
|
When you have suppress-fib-pending turned on it is possible
to end up in a situation where the prefix is not withdrawn
from downstream peers.
Here is the timing that I believe is happening:
a) have 2 paths to a peer.
b) receive a withdrawal from 1 path, set BGP_NODE_FIB_INSTALL_PENDING
and send the route install to zebra.
c) receive a withdrawal from the other path.
d) At this point we have a dest->flags set BGP_NODE_FIB_INSTALL_PENDING
old_select the path_info going away, new_select is NULL
e) A bit further down we call group_announce_route() which calls
the code to see if we should advertise the path. It sees the
BGP_NODE_FIB_INSTALL_PENDING flag and says, nope.
f) the route is sent to zebra to withdraw, which unsets the
BGP_NODE_FIB_INSTALL_PENDING.
g) This function winds up and deletes the path_info. Dest now
has no path infos.
h) BGP receives the route install(from step b) and unsets the
BGP_NODE_FIB_INSTALL_PENDING flag
i) BGP receives the route removed from zebra (from step f) and
unsets the flag again.
We know if there is no new_select, let's go ahead and just
unset the PENDING flag to allow the withdrawal to go out
at the time when the second withdrawal is received.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 4e8eda74ec7d30ba84e7f53f077f4b896728505a)
|
|
The json display of the version attribute is originally an
integer. It has changed, most probably mistakenly.
> {
> "vrfId": 7,
> "vrfName": "vrf1",
> "tableVersion": 3,
> "routerId": "192.0.2.1",
> "defaultLocPrf": 100,
> "localAS": 65500,
> "routes": {
> "172.31.0.1/32": {
> "prefix": "172.31.0.1/32",
> "version": "1", <--- int or string ??
Let us fix it, by using the integer display instead.
Fixes: f9f2d188e398 ("bgpd: fix 'json detail' output structure")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit c5d7815cccb92c192ca6b752843b8b827a607b53)
|
|
If we receive an IPv6 prefix e.g.: 2001:db8:100::/64 with nextop: 0.0.0.0, and
mp_nexthop: fc00::2, we should not treat this with an invalid nexthop because
of 0.0.0.0. We MUST check for MP_REACH attribute also and decide later if we
have at least one a valid nexthop.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit a0d2734e879f78fbef5f1815429de331b9940c73)
|
|
A redistribute cmd can have a route-map attached to it and adding the
match source-protocol to that route-map means BGP to filter which
protocol routes to accept among the bunch of routes zebra is sending.
Fixing this since this wasnt implemented earlier.
Ticket :#4119692
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
(cherry picked from commit 68358c0f928eafe50c9e73b0cb6a443c03f2a33f)
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit f93e5aa1663d9b375e0673f4eed367f9a009fa88)
|
|
We iterated over all bgp_path_info's, but once we remove the path, we didn't
check for other paths under the same bgp_dest.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Fix the display of the local label in show bgp.
> r1# show bgp ipv4 labeled-unicast 172.16.2.2/32
> BGP routing table entry for 172.16.2.2/32, version 2
> Local label: 16 <---- MISSING
> Paths: (1 available, best #1, table default, vrf (null))
> Advertised to non peer-group peers:
> 192.168.1.2
> 65501
> 192.168.1.2 from 192.168.1.2 (172.16.2.2)
> Origin IGP, metric 0, valid, external, best (First path received)
> Remote label: 3
> Last update: Fri Oct 25 17:55:45 2024
Fixes: 67f67ba481 ("bgpd: Drop label_ntop/label_pton functions")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit e7b3276ace65d59edb4d614158d4f2959f12f868)
|
|
For consistency between RIB and BGP, the aigp comparison should
be made after the local route check in bgp bestpath selection.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
|
|
OAD is treated as an _internal_ BGP peer, and some of the rules (including BGP
attributes) can be relaxed.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit e63b1520f1ad1036455c1626a388ac3afb7f9d6d)
|
|
Fix several issues in sourcing AIGP attribute:
1) AIGP should not be set as default for a redistributed route or a
static network. It should be set by config instead.
2) AIGP sourced by "set aigp-metric igp-metric" in a route-map does
not set the correct value for a redistributed route.
3) When redistribute a connected route like loopback, the AGIP (with
value 0) is sourced by "set aigp-metric igp-metric", but the
attribute is not propagated as the attribute flag is not set.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
(cherry picked from commit f65356d8bb9a43b1725fafdbd30aba0de9d214fa)
|
|
The nexthop metric should be added to AIGP when calculating the
bestpath in bgp_path_info_cmp().
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
(cherry picked from commit 081422e8e71085d3a3d4d2ff0bc1e1abaff0d52e)
|
|
RFC 8212 should be restricted for eBGP peers.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit fa2cc09d45d3f843564f7bd1e02346373c5741a8)
|
|
RFC 8212 defines leak prevention for eBGP peers, but BGP-OAD defines a new
peering type One Administrative Domain (OAD), where multiple ASNs could be used
inside a single administrative domain. OAD allows sending non-transitive attributes,
so this prevention should be relaxed too.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 3b98ddf5018cf7526b50c15018cbaf71a38fa752)
|
|
Route-distinguisher (RD) is not printed properly in show run:
> address-family ipv6 vpn
> network ff01::/64 rd (null) label 7
> network ff01::/64 rd (null) label 8
ad151f66aa ("bgpd: Refactor bgp_static_set/bgp_static_set_safi") merged
bgp_static_set_safi into bgp_static_set but inadvertently omitted the
handling of prd_pretty.
Copy the pretty RD string if available.
> address-family ipv6 vpn
> network ff01::/64 rd 75:5 label 7
> network ff01::/64 rd 85:5 label 8
Fixes: ad151f66aa ("bgpd: Refactor bgp_static_set/bgp_static_set_safi")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit 3d3a138f5a177a2ef5996c17c76c4f7778f9c3aa)
|
|
bgpd: Fix display when using `missing-as-worst` (backport #15726)
|
|
Before:
```
{
"vrfId": 0,
"vrfName": "default",
"tableVersion": 2,
"routerId": "1.1.1.1",
"defaultLocPrf": 100,
"localAS": 65001,
"routes": { "192.168.1.0/24": {
"prefix": "192.168.1.0/24",
"version": "1",
"paths": [{"aspath":{"string":"Local","segments":[],"length":0},"origin":"IGP","metric":0,"weight":32768,"valid":true,"version":1,"sourced":true,"local":true,"bestpath":{"overall":true,"selectionReason":"First path received"},"lastUpdate":{"epoch":1713035588,"string":"Sat Apr 13 22:13:08 2024\n"},"nexthops":[{"ip":"0.0.0.0","hostname":"donatas.net","afi":"ipv4","metric":0,"accessible":true,"used":true}],"peer":{"peerId":"0.0.0.0","routerId":"1.1.1.1"}}]
} ,"192.168.11.0/24": {
"prefix": "192.168.11.0/24",
"version": "2",
"paths": [{"aspath":{"string":"Local","segments":[],"length":0},"origin":"IGP","metric":0,"weight":32768,"valid":true,"version":2,"sourced":true,"local":true,"bestpath":{"overall":true,"selectionReason":"First path received"},"lastUpdate":{"epoch":1713035588,"string":"Sat Apr 13 22:13:08 2024\n"},"nexthops":[{"ip":"0.0.0.0","hostname":"donatas.net","afi":"ipv4","metric":0,"accessible":true,"used":true}],"peer":{"peerId":"0.0.0.0","routerId":"1.1.1.1"}}]
} } }
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 1dc28e1d735614715bab5d438bddcb2def6c8f3c)
|
|
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 bc9885b22e79ac14fd931517582d0d6d80f68c85)
|
|
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 329d5a5cbba23ec740b6ee3e223be5b13a631eb8)
|
|
Bgp filter fun (backport #15466)
|
|
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 addff17a555240a4ccb5d0c5733a780256837651)
|
|
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 6814401c47b948a50c6db93d60ac793a8cdce45f)
|
|
A route and its nexthop might belong to different VRFs. Therefore, we need
both the bgp and bgp_nexthop pointers.
Fixes: 8d51fafdcbef3dcf06df796e4f9b83d2bbd5edc2 ("bgpd: Drop bgp_static_update_safi() function")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 778357e9efd8deaa4612587959c9ef94b50ef288)
|
|
Ticket: #3534718 #3720960
Testing Done:
Config:
router bgp 65564 vrf sym_2
bgp router-id 27.0.0.9
!
address-family ipv4 unicast
redistribute static
exit-address-family
vrf sym_2
vni 8889
ip route 63.2.1.0/24 blackhole
ip route 63.2.1.2/32 blackhole
ip route 63.2.1.3/32 blackhole
exit-vrf
tor-1:# vtysh -c "show bgp l2vpn evpn route" | grep -A3 63.2
*> [5]:[0]:[24]:[63.2.1.0] RD 27.0.0.9:19
27.0.0.9 (tor-1)
0 32768 ?
ET:8 RT:28:8889 Rmac:44:38:39:ff:ff:29
--
*> [5]:[0]:[32]:[63.2.1.2] RD 27.0.0.9:19
27.0.0.9 (tor-1)
0 32768 ?
ET:8 RT:28:8889 Rmac:44:38:39:ff:ff:29
*> [5]:[0]:[32]:[63.2.1.3] RD 27.0.0.9:19
27.0.0.9 (tor-1)
0 32768 ?
ET:8 RT:28:8889 Rmac:44:38:39:ff:ff:29
tor-1(config)# router bgp 65564 vrf sym_2
tor-1(config-router)# address-family ipv4 unicast
tor-1(config-router-af)# aggregate-address 63.2.0.0/16 summary-only
tor-1(config-rou-f)# end
tor-1:# vtysh -c "show bgp l2vpn evpn route" | grep -A3 63.2.1
tor-1:# vtysh -c "show bgp l2vpn evpn route" | grep -A3 63.2
*> [5]:[0]:[16]:[63.2.0.0] RD 27.0.0.9:19
27.0.0.9 (tor-1)
0 32768 ?
ET:8 RT:28:8889 Rmac:44:38:39:ff:ff:29
Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit 5cb7712b3edb88ff43fce464d67a1548f183d410)
|
|
opensourcerouting/feature/bgpd_announce_rpki_state_knob
bgpd: Add neighbor X send-community extended rpki command
|
|
When a BGP flowspec peering stops, the BGP RIB entries for IPv6
flowspec entries are removed, but not the ZEBRA RIB IPv6 entries.
Actually, when calling bgp_zebra_withdraw() function call, only
the AFI_IP parameter is passed to the bgp_pbr_update_entry() function
in charge of the Flowspec add/delete in zebra. Fix this by passing
the AFI parameter to the bgp_zebra_withdraw() function.
Note that using topotest does not show up the problem as the
flowspec driver code is not present and was refused. Without that,
routes are not installed, and can not be uninstalled.
Fixes: 529efa234655 ("bgpd: allow flowspec entries to be announced to zebra")
Link: https://github.com/FRRouting/frr/pull/2025
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
|
|
By default, iBGP and eBGP-OAD peers exchange RPKI extended community by default.
Add a command to disable sending RPKI extended community if needed.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
No need to init new_attr. It is not used until it is overridden.
> new_attr = *attr;
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
|
|
Structure size of bgp_path_info_extra when compiled
with vnc is 184 bytes. Reduce this size to 72 bytes
when compiled w/ vnc but not necessarily turned
on vnc.
With 2 full bgp feeds this saves aproximately 100mb
when compiling with vnc and not using vnc.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Without this change when we change the route-map, we never reinstall the route
if the route-map has changed.
We checked only some attributes like aspath, communities, large-communities,
extended-communities, but ignoring the rest of attributes.
With this change, let's check if the route-map has changed.
bgp_route_map_process_update() is triggered on route-map change, and we set
`changed` to true, which treats aggregated route as not the same as it was before.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Use bgp_labels_same() for all label comparisons in bgpd.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
|
|
Comparing pointers is not the appropriate way to know
if the label values are the same or not. Perform a
memcmp call instead is better.
Fixes: 8ba710505735 ("bgpd: fix valgrind flagged errors")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
|
|
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
https://datatracker.ietf.org/doc/html/draft-uttaro-idr-bgp-oad#section-3.13
Extended communities which are non-transitive across an AS boundary MAY be
advertised over an EBGP-OAD session if allowed by explicit policy configuration.
If allowed, all the members of the OAD SHOULD be configured to use the same
criteria.
For example, the Origin Validation State Extended Community, defined as
non-transitive in [RFC8097], can be advertised to peers in the same OAD.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
```
r1# sh ip bgp 10.10.10.10/32
BGP routing table entry for 10.10.10.10/32, version 1
Paths: (2 available, best #2, table default)
Advertised to non peer-group peers:
192.168.1.2 192.168.1.4
65002 65003
192.168.1.2 from 192.168.1.2 (192.168.2.2)
Origin incomplete, metric 123, localpref 123, valid, external (oad)
Last update: Thu Jan 11 10:46:32 2024
65004 65005
192.168.1.4 from 192.168.1.4 (192.168.4.4)
Origin incomplete, metric 123, localpref 123, valid, external, best (Peer Type)
Last update: Thu Jan 11 10:46:30 2024
r1#
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
If at least one of the candidate routes was received via EBGP, remove from
consideration all routes that were received via EBGP-OAD and IBGP.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
When bgp update is received for EVPN prefix
where for an existing path's nexthop becomes unreachable,
the path is marked as not VALID but the routes
were not unimported from tenant vrfs, which lead to
stale unicast route(s) and nexthop(s).
In Multipath scenario only a specific path may have marked as
not VALID, then specific path info for the EVPN prefix required to be
unimported from tenant vrf.
Ticket: #3671288
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Prevent "default-originate" from withdrawing non-default routes like
0.0.0.0/1 by checking prefix length.
Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
|
|
opensourcerouting/fix/bgpd_route-map_default_originate_peer-group
tests: Check if default-originate works combined with peer-groups + route-maps
|
|
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Signed-off-by: zyxwvu Shi <i@shiyc.cn>
|
|
It holds only 0/1.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
When exporting bgp vrf instance unicast route into
EVPN as type-5, check for suppressed ones and do not
export them.
Ticket:#3534718
Testing Done:
Config:
router bgp 660000 vrf vrf1
bgp router-id 144.1.1.2
no bgp network import-check
neighbor 144.1.1.1 remote-as external
!
address-family ipv4 unicast
aggregate-address 50.1.0.0/16 summary-only
redistribute connected
exit-address-family
!
address-family l2vpn evpn
advertise ipv4 unicast
exit-address-family
exit
v4 suppressed route: (5 suppressed routes not exported to evpn)
tor1# vtysh -c "show bgp vrf vrf1 ipv4 unicast" | grep "50.1"
*> 50.1.0.0/16 0.0.0.0(bordertor-11)
s> 50.1.1.212/32 6.0.0.30(leaf-11)<
s> 50.1.1.222/32 6.0.0.31(leaf-11)<
s> 50.1.110.0/24 0.0.0.0(bordertor-11)
s> 50.1.210.214/32 6.0.0.30(leaf-11)<
s> 50.1.220.224/32 6.0.0.31(leaf-11)<
tor1# vtysh -c "show bgp l2vpn evpn route" | grep -A3 "*> \[5\].*\[50.1"
*> [5]:[0]:[16]:[50.1.0.0] RD 144.1.1.2:7
6.0.0.1 (bordertor-11)
0 32768 ?
ET:8 RT:4640:104001 Rmac:00:02:00:00:00:04
Signed-off-by: Chirag Shah <chirag@nvidia.com>
|
|
bgpd: fix bgp_best_selection heap-use-after-free
|
|
Fix bgp_best_selection heap-use-after-free
> ==2521540==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d000032810 at pc 0x000000716f45 bp 0x7ffedc6229d0 sp 0x7ffedc6229c8
> READ of size 8 at 0x60d000032810 thread T0
> #0 0x716f44 in bgp_best_selection /home/lscalber/git/frr/bgpd/bgp_route.c:2834:5
> #1 0x71a05e in bgp_process_main_one /home/lscalber/git/frr/bgpd/bgp_route.c:3344:2
> #2 0x71c265 in bgp_process_wq /home/lscalber/git/frr/bgpd/bgp_route.c:3622:3
> #3 0x7fe630a6669c in work_queue_run /home/lscalber/git/frr/lib/workqueue.c:282:10
> #4 0x7fe630a294e2 in event_call /home/lscalber/git/frr/lib/event.c:1974:2
> #5 0x7fe630898f3f in frr_run /home/lscalber/git/frr/lib/libfrr.c:1214:3
> #6 0x4f4ace in main /home/lscalber/git/frr/bgpd/bgp_main.c:510:2
> #7 0x7fe63018bd09 in __libc_start_main csu/../csu/libc-start.c:308:16
> #8 0x449629 in _start (/usr/lib/frr/bgpd+0x449629)
>
> 0x60d000032810 is located 48 bytes inside of 144-byte region [0x60d0000327e0,0x60d000032870)
> freed by thread T0 here:
> #0 0x4c341d in free (/usr/lib/frr/bgpd+0x4c341d)
> #1 0x7fe6308d7420 in qfree /home/lscalber/git/frr/lib/memory.c:130:2
> #2 0x702632 in bgp_path_info_free_with_caller /home/lscalber/git/frr/bgpd/bgp_route.c:300:2
> #3 0x702023 in bgp_path_info_unlock /home/lscalber/git/frr/bgpd/bgp_route.c:315:3
> #4 0x703bc6 in bgp_path_info_reap /home/lscalber/git/frr/bgpd/bgp_route.c:461:2
> #5 0x716e5d in bgp_best_selection /home/lscalber/git/frr/bgpd/bgp_route.c:2829:12
> #6 0x71a05e in bgp_process_main_one /home/lscalber/git/frr/bgpd/bgp_route.c:3344:2
> #7 0x71c265 in bgp_process_wq /home/lscalber/git/frr/bgpd/bgp_route.c:3622:3
> #8 0x7fe630a6669c in work_queue_run /home/lscalber/git/frr/lib/workqueue.c:282:10
> #9 0x7fe630a294e2 in event_call /home/lscalber/git/frr/lib/event.c:1974:2
> #10 0x7fe630898f3f in frr_run /home/lscalber/git/frr/lib/libfrr.c:1214:3
> #11 0x4f4ace in main /home/lscalber/git/frr/bgpd/bgp_main.c:510:2
> #12 0x7fe63018bd09 in __libc_start_main csu/../csu/libc-start.c:308:16
>
> previously allocated by thread T0 here:
> #0 0x4c3812 in calloc (/usr/lib/frr/bgpd+0x4c3812)
> #1 0x7fe6308d7178 in qcalloc /home/lscalber/git/frr/lib/memory.c:105:27
> #2 0x71f5b4 in info_make /home/lscalber/git/frr/bgpd/bgp_route.c:3985:8
> #3 0x725293 in bgp_update /home/lscalber/git/frr/bgpd/bgp_route.c:4881:8
> #4 0x73083d in bgp_nlri_parse_ip /home/lscalber/git/frr/bgpd/bgp_route.c:6230:4
> #5 0x6ba980 in bgp_nlri_parse /home/lscalber/git/frr/bgpd/bgp_packet.c:341:10
> #6 0x6cca2a in bgp_update_receive /home/lscalber/git/frr/bgpd/bgp_packet.c:2412:15
> #7 0x6c6788 in bgp_process_packet /home/lscalber/git/frr/bgpd/bgp_packet.c:3887:11
> #8 0x7fe630a294e2 in event_call /home/lscalber/git/frr/lib/event.c:1974:2
> #9 0x7fe630898f3f in frr_run /home/lscalber/git/frr/lib/libfrr.c:1214:3
> #10 0x4f4ace in main /home/lscalber/git/frr/bgpd/bgp_main.c:510:2
> #11 0x7fe63018bd09 in __libc_start_main csu/../csu/libc-start.c:308:16
Fixes: ddb5b4880b ("bgpd: vpn-vrf route leaking")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
|
|
The MTYPE_BGP memory type was being over used as
both the handler for the bgp instance itself as
well as memory associated with name strings.
Let's separate out the two.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
bgpd: BMP Loc-Rib Monitoring (RFC9069) Implementation
|
|
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
