```
Direct leak of 112 byte(s) in 1 object(s) allocated from:
0 0x7feb66337a06 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
1 0x7feb660cbcc3 in qcalloc lib/memory.c:116
2 0x55cc3cba02d1 in info_make bgpd/bgp_route.c:3831
3 0x55cc3cbab4f1 in bgp_update bgpd/bgp_route.c:4733
4 0x55cc3cbb0620 in bgp_nlri_parse_ip bgpd/bgp_route.c:6111
5 0x55cc3cb79473 in bgp_update_receive bgpd/bgp_packet.c:2020
6 0x55cc3cb7c34a in bgp_process_packet bgpd/bgp_packet.c:2929
7 0x7feb6610ecc5 in thread_call lib/thread.c:2006
8 0x7feb660bfb77 in frr_run lib/libfrr.c:1198
9 0x55cc3cb17232 in main bgpd/bgp_main.c:520
10 0x7feb65ae5082 in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: 112 byte(s) leaked in 1 allocation(s).
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This commit eaeba5e868 changed a bit a formatting,
but this part was missed, let's fix it.
An example before the patch:
```
r3# sh ip bgp ipv4 labeled-unicast neighbors 192.168.34.4 advertised-routes
BGP table version is 3, local router ID is 192.168.34.3, vrf id 0
Default local pref 100, local AS 65003
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.1/32 0.0.0.0 0 65001 ?
Total number of prefixes 1
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Use %pI4/%pI6 where possible, otherwise at least atjust stack buffer sizes
for inet_ntop() calls.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
bgp_pcount_adjust() is called only when calling bgp_path_info_set_flag().
Before this patch the pcount is not advanced before checking for overflow.
Additionally, print:
```
[RZMGQ-A03CG] 192.168.255.1(r1) rcvd UPDATE about 172.16.255.254/32 IPv4 unicast -- DENIED due to: maximum-prefix overflow
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
currently the following configuration
dut:
!
interface ntfp2
ip router isis 1
!
router bgp 200
no bgp ebgp-requires-policy
bgp confederation identifier 300
bgp confederation peers 300
neighbor 192.168.1.1 remote-as 100
neighbor 192.168.2.2 remote-as 300
!
address-family ipv4 unicast
neighbor 192.168.2.2 default-originate
exit-address-family
!
router isis 1
is-type level-2-only
net 49.0001.0002.0002.0002.00
redistribute ipv4 connected level-2
!
end
router:
!
interface ntfp2
ip router isis 1
isis circuit-type level-2-only
!
router bgp 300
no bgp ebgp-requires-policy
bgp confederation identifier 300
bgp confederation peers 200
neighbor 192.168.2.1 remote-as 200
neighbor 192.168.3.2 remote-as 400
!
address-family ipv4 unicast
network 3.3.3.0/24
exit-address-family
!
router isis 1
is-type level-2-only
net 49.0001.0003.0003.0003.00
redistribute ipv4 connected level-2
!
end
on dut result of show bgp ipv4 unicast command is:
show bgp ipv4 unicast
BGP table version is 1, local router ID is 192.168.2.1, vrf id 0
Default local pref 100, local AS 200
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 192.168.1.1 0 0 100 i
instead of
sho bgp ipv4 unicast
BGP table version is 3, local router ID is 192.168.2.1, vrf id 0
Default local pref 100, local AS 200
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 192.168.1.1 0 0 100 i
*> 3.3.3.0/24 192.168.2.2 0 100 0 (300) i
*> 4.4.4.0/24 192.168.3.2 0 100 0 (300) 400 i
Displayed 3 routes and 3 total paths
According to RFC 5065:the usage of one of the member AS number as the
confederation identifier is not forbidden.
fixes are the following
in bgp_route.c:
in bgp_update remove the test for presence of confederation id in
as_path since, this case is allowed;
in bgp_vty.c
bgp_confederation_peers, remove the test on peer as value
in bgpd.c
bgp_confederation_peers_add
remove the test on peer as value
invert the order of setting peer->sort value and peer->local_as,
since peer->sort is depending from current peer->local_as value
bgp_confederation_peers_remove
invert the order of setting peer->sort value and peer->local_as,
since peer->sort is depending from current peer->local_as value
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
We already have a global knob for graceful-shutdown, but it's handy having
per neighbor knob as well.
Especially when a single neighbor needs to be restarted/shutdown gracefuly.
We can do this route-maps, but this is a faster/cleaner way doing the same
for an operator.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This commit addresses an issue that happens when using bgp
peering with a rr client, with a received prefix which is the
local ip address of the bgp session.
When using bgp ipv4 unicast session, the local prefix is
received by a peer, and finds out that the proposed prefix
and its next-hop are the same. To avoid a route loop locally,
no nexthop entry is referenced for that prefix, and the route
will not be selected.
When the received peer is a route reflector, the prefix has
to be selected, even if the route can not be installed locally.
Fixes: ("fb8ae704615c") bgpd: prevent routes loop through itself
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Not all places were checking to see if soft reconfiguration
was turned on before calling into it to do all that work.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When deciding whether to apply "neighbor soo" filtering towards a peer,
we were only looking for SoO ecoms that use either AS or AS4 encoding.
This makes sure we also check for IPv4 encoding, since we allow a user
to configure that encoding style against the peer.
Config:
```
router bgp 1
address-family ipv4 unicast
network 100.64.0.2/32 route-map soo-foo
neighbor 192.168.122.12 soo 3.3.3.3:20
exit-address-family
!
route-map soo-foo permit 10
set extcommunity soo 3.3.3.3:20
exit
```
Before:
```
ub20# show ip bgp neighbors 192.168.122.12 advertised-routes
BGP table version is 5, local router ID is 100.64.0.222, vrf id 0
Default local pref 100, local AS 1
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 0.0.0.0 0 100 32768 i
*> 100.64.0.2/32 0.0.0.0 0 100 32768 i
Total number of prefixes 2
```
After:
```
ub20# show ip bgp neighbors 192.168.122.12 advertised-routes
BGP table version is 5, local router ID is 100.64.0.222, vrf id 0
Default local pref 100, local AS 1
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 0.0.0.0 0 100 32768 i
Total number of prefixes 1
```
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Rather than running selected source files through the preprocessor and a
bunch of perl regex'ing to get the list of all DEFUNs, use the data
collected in frr.xref.
This not only eliminates issues we've been having with preprocessor
failures due to nonexistent header files, but is also much faster.
Where extract.pl would take 5s, this now finishes in 0.2s. And since
this is a non-parallelizable build step towards the end of the build
(dependent on a lot of other things being done already), the speedup is
actually noticeable.
Also files containing CLI no longer need to be listed in `vtysh_scan`
since the .xref data covers everything. `#ifndef VTYSH_EXTRACT_PL`
checks are equally obsolete.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Column headers in BGP routes table are not aligned with data when
RPKI status is available. This was fixed to insert a space at the
beginning of the header and at the beginning of lines that do not
have RPKI status.
This fix requires that several testing templates be adjusted to
match the new output.
Signed-off-by: Wayne Morrison <wmorrison@netgate.com>
Ensure that un-configuring allowas-in for a peer or group
clears the related flags and integer value. Tighten the use
of the integer counter so that it's only used when the config
flag is set. Add show output if allowas-in is enabled.
Signed-off-by: Mark Stapp <mstapp@nvidia.com>
Fix vni table output broken by 8304dabfab
The "Imported from" output was not getting delimitted by a newline
after the mentioned commit. This fixes that and retains the output
wanted by the original change.
Before:
'''
Route [2]:[0]:[48]:[b6:3a:cc:d5:a1:cd]:[128]:[fe80::b43a:ccff:fed5:a1cd] VNI 30/10 Imported from 2.2.2.2:4:[2]:[0]:[48]:[b6:3a:cc:d5:a1:cd]:[128]:[fe80::b43a:ccff:fed5:a1cd], VNI 30/10
2
2.2.2.2(alfred) from alfred(veth1) (2.2.2.2)
Origin IGP, valid, external, bestpath-from-AS 2, best (First path received)
Extended Community: RT:2:30 ET:8
Last update: Fri Oct 7 16:04:59 2022
'''
After:
'''
Route [2]:[0]:[48]:[b2:cf:96:70:4f:b6]:[128]:[fe80::b0cf:96ff:fe70:4fb6] VNI 30/10
Imported from 2.2.2.2:4:[2]:[0]:[48]:[b2:cf:96:70:4f:b6]:[128]:[fe80::b0cf:96ff:fe70:4fb6], VNI 30/10
2
2.2.2.2(alfred) from alfred(veth1) (2.2.2.2)
Origin IGP, valid, external, bestpath-from-AS 2, best (First path received)
Extended Community: RT:2:30 ET:8
Last update: Fri Oct 7 17:02:28 2022
'''
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Use the IP addr of type2/macip routes only for the hash/key
of the VNI table and carry the MAC in a path_info_extra attribute.
There is exists situations that can be hit during extended MAC mobility events
where two MACs could be pointing to the same IP in our global table. It
is requires very specific timings.
When that happens, BPG would (because we key'd on both MAC and IP)
install both into it's VNI table as separate entries, but zebra only
knows/needs to know about a single IP -> MAC relationship for it's VNI
table's type2 routes. So it was compleletly undeterministic which one
zebra would end up with in these timing situations.
With these changes, we move BGP's VNI table to key'd the same as Zebra's
and now a single IP will have multiple path_info's with a path_info_extra
that is carrying the MAC info for each path.
BGP will then run best path to deterministically decide which one to send to
zebra during the occasions where there exist's two possible MACs.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
There is code that sets the pi based upon matching it against
the same peer. In this code the type and sub-type are also
compared to the passed in type and sub-type. Let's just use
type and sub-type as that if we have a pi we know type and sub-type
are already correct. This should also make the first iteration
work correctly when the pi has not been created yet when we call
the martian_update function.bgpd: Remove unnecessary check for pi and setting type and sub-type
There is code that sets the pi based upon matching it against
the same peer. In this code the type and sub-type are also
compared to the passed in type and sub-type. Let's just use
type and sub-type as that if we have a pi we know type and sub-type
are already correct. This should also make the first iteration
work correctly when the pi has not been created yet when we call
the martian_update function.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
```
donatas-pc# show ip bgp 100.100.100.0/24 longer-prefixes
BGP table version is 13, local router ID is 10.10.10.10, vrf id 0
Default local pref 100, local AS 65000
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
100.100.100.0/24 0.0.0.0 0 32768 i
Displayed 1 routes and 15 total paths
donatas-pc# show ip bgp 100.100.100.0/24
BGP routing table entry for 100.100.100.0/24, version 0
Paths: (1 available, no best path)
Not advertised to any peer
Local
0.0.0.0 (inaccessible, import-check enabled) from 0.0.0.0 (10.10.10.10)
Origin IGP, metric 0, weight 32768, invalid, sourced, local
Last update: Tue Oct 4 11:31:44 2022
donatas-pc# show ip bgp 100.100.100.0/24 json
{
"prefix":"100.100.100.0\/24",
"version":0,
"paths":[
{
"aspath":{
"string":"Local",
"segments":[
],
"length":0
},
"origin":"IGP",
"metric":0,
"weight":32768,
"valid":false,
"version":0,
"sourced":true,
"local":true,
"lastUpdate":{
"epoch":1664872304,
"string":"Tue Oct 4 11:31:44 2022\n"
},
"nexthops":[
{
"ip":"0.0.0.0",
"hostname":"donatas-pc",
"afi":"ipv4",
"accessible":false,
"importCheckEnabled":true,
"used":true
}
],
"peer":{
"peerId":"0.0.0.0",
"routerId":"10.10.10.10"
}
}
]
}
donatas-pc#
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Before returning an error, unlock bgp dest which is locked by
bgp_node_lookup()/bgp_node_get().
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
==536197== 400 (160 direct, 240 indirect) bytes in 4 blocks are definitely lost in loss record 19 of 21
==536197== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==536197== by 0x491C753: qcalloc (memory.c:116)
==536197== by 0x303FA9: aspath_dup (bgp_aspath.c:698)
==536197== by 0x304B2A: aspath_replace_specific_asn (bgp_aspath.c:1219)
==536197== by 0x256840: bgp_peer_as_override (bgp_route.c:1781)
==536197== by 0x256840: subgroup_announce_check (bgp_route.c:2216)
==536197== by 0x258345: subgroup_process_announce_selected (bgp_route.c:2804)
==536197== by 0x27F2CA: group_announce_route_walkcb (bgp_updgrp_adv.c:199)
==536197== by 0x4905A51: hash_walk (hash.c:285)
==536197== by 0x27E8D1: update_group_af_walk (bgp_updgrp.c:1866)
==536197== by 0x2809D3: group_announce_route (bgp_updgrp_adv.c:1022)
==536197== by 0x257DC4: bgp_process_main_one (bgp_route.c:3189)
==536197== by 0x257DC4: bgp_process_main_one (bgp_route.c:2975)
==536197== by 0x2581F7: bgp_process_wq (bgp_route.c:3330)
==536197== by 0x4961787: work_queue_run (workqueue.c:285)
==536197== by 0x4957745: thread_call (thread.c:2008)
==536197== by 0x4910B77: frr_run (libfrr.c:1198)
==536197== by 0x1ED6AC: main (bgp_main.c:520)
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Before it worked only when configured initially via CLI. Later, when we
receive a new route, that should match a decent MED, we just skip it, because
MED mismatch is not recalculated.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When redistributing connected addresses, the address family has
to be figured out. The calculation was not done, the next-hop
address length was not set, and as consequence, the nexthop
is displayed like if it was an ipv6 address, which is wrong for
ipv4 addresses.
Calculate the family for connected addresses.
Change the topotests accordingly.
Fixes: ("7226bc40d606") bgpd: ignore NEXT_HOP for MP_REACH_NLRI
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
