Shouldn't validate the label after 'decode_label'. If we validate
the label after 'decode_label', even the 'MPLS_INVALID_LABEL' will
be valid then.
Signed-off-by: Valerian_He <1826906282@qq.com>
This is based on @donaldsharp's work
The current code base is the struct bgp_node data structure.
The problem with this is that it creates a bunch of
extra data per route_node.
The table structure generates ‘holder’ nodes
that are never going to receive bgp routes,
and now the memory of those nodes is allocated
as if they are a full bgp_node.
After splitting up the bgp_node into bgp_dest and route_node,
the memory of ‘holder’ node which does not have any bgp data
will be allocated as the route_node, not the bgp_node,
and the memory usage is reduced.
The memory usage of BGP node will be reduced from 200B to 96B.
The total memory usage optimization of this part is ~16.00%.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Yuqing Zhao <xiaopanghu99@163.com>
The status and ostatus are a function of the `struct peer_connection`
move it into that data structure.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Even if some of the attributes in bgp_path_info_extra are
not used, their memory is still allocated every time. It
cause a waste of memory.
This commit code deletes all unnecessary attributes and
changes the optional attributes to pointer storage. Memory
will only be allocated when they are actually used. After
optimization, extra info related memory is reduced by about
half(~400B -> ~200B).
Signed-off-by: Valerian_He <1826906282@qq.com>
Include an event ptr-to-ptr in the event_execute() api
call, like the various schedule api calls. This allows the
execute() api to cancel an existing scheduled task if that
task is being executed inline.
Signed-off-by: Mark Stapp <mjs@labn.net>
Currently, json output of show BGP commands are no pretty format.
This is an extremely expensive operation for huge scale (lots of
routes with lots of paths).
BGP json non-pretty commands support added:
```
show bgp neighbors <nbr-id> advertised-routes json
show bgp neighbors <nbr-id> received-routes json
show bgp neighbors <nbr-id> advertised-routes detail json
show bgp neighbors <nbr-id> received-routes detail json
```
Ticket:#3513256
Issue:3513256
Testing: UT done
Signed-off-by: Sindhu Parvathi Gopinathan's <sgopinathan@nvidia.com>
When switching `router bgp`, `no router bgp` and doing redistributions, we should
ignore this action, otherwise memory leak happens:
```
Indirect leak of 400 byte(s) in 2 object(s) allocated from:
0 0x7f81b36b3a06 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
1 0x7f81b327bd2e in qcalloc lib/memory.c:105
2 0x55f301d28628 in bgp_node_create bgpd/bgp_table.c:92
3 0x7f81b3309d0b in route_node_new lib/table.c:52
4 0x7f81b3309d0b in route_node_set lib/table.c:61
5 0x7f81b330be0a in route_node_get lib/table.c:319
6 0x55f301ce89df in bgp_redistribute_add bgpd/bgp_route.c:8907
7 0x55f301dac182 in zebra_read_route bgpd/bgp_zebra.c:593
8 0x7f81b334dcd7 in zclient_read lib/zclient.c:4179
9 0x7f81b331d702 in event_call lib/event.c:1995
10 0x7f81b325d597 in frr_run lib/libfrr.c:1213
11 0x55f301b94b12 in main bgpd/bgp_main.c:505
12 0x7f81b2b57082 in __libc_start_main ../csu/libc-start.c:308
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Imagine the following scenario:
when a neighbor has an inbound policy set to modify the next hop, but no outbound route-map is configured.
In this case, if(!post_attr && (ROUTE_MAP_OUT_NAME(filter) || bgp_path_suppressed(pi))) returns false, causing rmap_in_change_flag to not be correctly cleared, and mistakenly identified as rmap_out_change_flag, leading to the failure of the subsequent neighbor-nexthop-self command.
Signed-off-by: Jack.zhang <hanyu.zly@alibaba-inc.com>
'{}' extra output may present JSON output from bgp_show_table_rd() when
no prefix are seen.
> {
> "vrfId": 0,
> "vrfName": "default",
> "tableVersion": 0,
> "routerId": "1.1.1.1",
> "defaultLocPrf": 100,
> "localAS": 65500,
> "routes": { "routeDistinguishers" : { "444:1" : { } } } }
> {}
Do not output '{}' when bgp_show_table() returns a valid JSON.
Tested without rd in config, bgp_show_table() returns nothing and the
JSON output is only '{}'
Fixes: 0224b3296c ("bgpd: Print empty JSON `{}` if no entries under `show bgp ipv4 vpn json`")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
By default, bgpd stores all MPLS VPN SAFI prefixes unless the "no bgp
retain route-target all" option is used to store only prefixes that are
imported into local VRFs. The "no retain" option temporarily uses too
much memory, as all prefixes are stored in memory before the deletion of
non-imported prefixes is done.
Filter out non-imported prefixes before they are set into the BGP adj
RIB out.
Fixes: a486300b26 ("bgpd: implement retain route-target all behaviour")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Partially revert a486300b26 ("bgpd: implement retain route-target all
behaviour") in order to fix a memory consumption issue in the next
commit.
Fixes: a486300b26 ("bgpd: implement retain route-target all behaviour")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Remove the check about pi->peer value different from null.
Introducing this check introduces a SA warning on the value
of the from value (derived from pi->peer).
Actually, peer is set when bgp_path_info_make() call is
performed; peer is never null.
Fixes: 23bb4a9b5c64 ("bgpd: advertise mpls vpn routes with appropriate label")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When using the bgp-accept-own community, with the
'attribute-unchanged next-hop' command, the advertised
mpls vpn updates that are reflected by a route reflector
are received, but are not selected.
Once the accept-own community is detected, a new bgp_path
is created, in addition of the original one; then the
next-hop of the NLRI is checked, but fails for two reasons:
- the next-hop tracking returns the real IP reachability
status for prefixes that have the BGP_ROUTE_IMPORTED subtype.
This is what happens with bgp updates with the accept-own
community.
- as the next-hop was unchanged and was the peer IP in the VRF.
Consequently, the new bgp_path is considered inactive in the
default VRF, and is not selected.
The incoming bgp updates with the accept-own community should
not be checked against the next-hop tracking. As the bgp_path
subtype has been changed to BGP_ROUTE_IMPORTED, let us check
the bgp subtype before calling the 'bgp_find_or_add_nexthop()'
function in the 'bgp_update()' call.
Fixes: 46dbf9d0c0 bgpd: ("Implement ACCEPT_OWN extended community")
Fixes: 376797711f4d - bgpd: track mpls vpn nexthops
Fixes: e6110f755718 bgpd: ("fix use nexthop tracking for exported vpn paths")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The advertised label value from mpls vpn routes is not modified
when the advertised next-hop is modified to next-hop-self.
Actually, the original label value received is redistributed as
is, whereas the new_label value bound in the nexthop label
bind entry should be used.
Only the VPN entries that contain MPLS information, and that
are redistributed between distinct peers, will have a label
value to advertise.
- no SRv6 attribute
- no local prefix
- no exported VPN prefixes from a VRF
If the advertisement to a given peer has the next-hop modified,
then the new label value will be picked up. The considered cases
are peers configured with 'next-hop-self' option, or ebgp peerings
without the 'next-hop-unchanged' option.
Note that the the NLRI format will follow the rfc3107 format, as
multiple label values for MPLS VPN NLRIs are not supported (the
rfc8277 is not supported).
Note also that the case where an outgoing route-map is applied to
the outgoing neighbor is not considered in this commit.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Current implementation does not offer a new label to bind
to a received VPN route entry to redistribute with that new
label.
This commit allocates a label for VPN entries that have
a valid label, and a reachable next-hop interface that is
configured as follows:
> interface eth0
> mpls bgp l3vpn-multi-domain-switching
> exit
An mplsvpn next-hop label binding entry is created in an mpls
vpn nexthop label bind hash table of the current BGP instance.
That mpls vpn next-hop label entry is indexed by the (next-hop,
orig_label) values provided by the incoming updates, and shared
with other updates having the same (next-hop, orig_label) values.
A new 'LP_TYPE_BGP_L3VPN_BIND' label value is picked up from the
zebra mpls label pool, and assigned to the new_label attribute.
The 'bgp_path_info' appends a 'bgp_mplsvpn_nh_label_bind' structure
to the 'mplsvpn' union structure. Both structures in the union are not
used at the same, as the paths are either VRF updates to export, or MPLS
VPN updates. Using an union gives a 24 bytes memory gain compared to if
the structures had not been in an union (24 bytes compared to 48 bytes).
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The label allocation mechanism is called implicitly for
labeled unicast paths. The check should be explicit, because
the current patch set will extend the mechanism for mpls vpn
paths, and the code should explicitly tell which safi calls
which code.
Fix this implicit call by checking the safi value. Move the
code to a specific function.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
There is no nexthop reachability information for
received MPLS VPN prefixes.
This information is necessary when BGP also acts
as LSR device, and is needed to create an MPLS entry
between two BGP speakers: the next-hop to pick-up
in the MPLS entry has to be connected.
The nexthop reachability information is available
for other non MPLS VPN prefixes, and is handled
by the bgp nexthop cache (bnc) contexts.
Extend the usage of the BNC contexts for L3VPN
prefixes.
Note that the MPLS VPN routes had to be redistributed
as before, to avoid breaking existing deployments
that use FRR as route reflectors. Because of this, the
nexthop reachability status has been maintained to OK
for MPLS VPN prefixes.
Note also that the label allocation per nexthop tracking
was wrongly using the MPLS VPN safi to get a valid BNC
context, when choosing which label to return in the
'vpn_leak_from_vrf_get_per_nexthop_label()' function.
Fix this by using SAFI_UNICAST instead.
Fixes: 577be36a41 ("bgpd: add support for l3vpn per-nexthop label")
Link: https://github.com/FRRouting/frr/pull/13380
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
BGP cannot decide to disseminate the safi based upon the
bgp suppress-fib command. Modify the code to look at
the safi for the decision to communicate to a peer the
particular node.
Ticket: #3402926
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When using `addpath-tx-all` BGP announces all known paths instead of announcing
only an arbitrary number of best paths.
With this new command we can send N best paths to the neighbor. That means, we
send the best path, then send the second best path excluding the previous one,
and so on. In other words, we run best path selection algorithm N times before
we finish.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Consider the scenario of evpn, the box has some type-5 ECMP routes.
After one of its remote peers is removed ( or down ), `show evpn rmac vni all`
kept no change **sometimes**, it means the rmac of the removed peer maybe is
still in this box, and the traffic will be wrongly forwarded to the removed
peer.
The root cause is that the best path selection for type-5 routes maybe
keep no change and the best path is not routed to the removed peer, so `bgpd`
wrongly doesn't tell `zebra` to remove ( withdraw ) the type-5 routes owned
by the removed peer.
So, add a new flag to force the deletion.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Not sure why it's here, but looks like it was since the beginning, let's see
if we can drop it.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Reuse subgroup_process_announce_selected(). It does the same as we do here
duplicating the logic.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
In the json output of show bgp all json, the l2VpnEvpn afi-safi is
missing the 'routes' key making the json output format invalid.
Before Fix:
torm-11# sh bgp all json
{
<SNIP>....................
"l2VpnEvpn":{
{
"27.0.0.15:2":{
"rd":"27.0.0.15:2",
"[4]:[03:44:38:39:ff:ff:01:00:00:01]:[32]:[27.0.0.15]":{
"prefix":"[4]:[03:44:38:39:ff:ff:01:00:00:01]:[32]:[27.0.0.15]",
"prefixLen":352,
"paths":[
<SNIP>....................
After Fix:
torm-11# sh bgp all json
{
<SNIP>....................
"l2VpnEvpn":{
"routes":{
"27.0.0.15:2":{
"rd":"27.0.0.15:2",
"[1]:[0]:[03:44:38:39:ff:ff:01:00:00:01]:[128]:[::]:[0]":{
"prefix":"[1]:[0]:[03:44:38:39:ff:ff:01:00:00:01]:[128]:[::]:[0]",
"prefixLen":352,
"paths":[
Issue: 3472865
Ticket:#3472865
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
This can lead into some garbage outputs, that can't be decoded in utf-8 or so.
This was catched when testing 76b246aa1f.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
In ebgp+ ibgp deployment aggregate summary-only route
selected path should always be locally originated
summary route.
When aggregate route summary-only config is removed
The selected path is iBGP peer as its lower cost
Upon reconfiguring aggregate route summary-only,
the locally originated is not selected due to
always choosing first path attribute and bailing
out as no change in route update.
Ticket:#3467890
Issue:3467890
Testing Done:
Config:
------
TORC11(config-router)#router bgp
TORC11(config-router)# address-family ipv4 unicast
TORC11(config-router-af)# aggregate-address 184.123.0.0/16
summary-only
TORC11(config-router-af)# no aggregate-address 184.123.0.0/16
summary-only
TORC11(config-router-af)# aggregate-address 184.123.0.0/16
summary-only
Before fix:
-----------
*> 184.123.0.0/16 ::(TORC11) 0 32768 i
* uplink1 0 4435 5546 i
* uplink2 0 4435 5546 i
* i peerlink-3 0 100 0 i
After fix:
----------
*> 184.123.0.0/16 ::(TORC11) 0 32768 i
* i peerlink-3 0 100 0 i
* uplink2 0 4435 5546 i
* uplink1 0 4435 5546 i
Signed-off-by: Chirag Shah <chirag@nvidia.com>
This is a preliminary work to export redistributed routes from
a given VRF in an VPN network. The exportation works well, when
the label allocation is based on an per-vrf mode, but not on
a per nexthop mode.
To associate a label with a connected nexthop, the nexthop
tracking contexts are used. Until today, there was no tracking
context for redistributed routes. But when using this vpn
allocation mode, one needs to know whether the route is directly
connected or not. When using the nexthop tracking context, the
nexthop attribute of the bgp update needs to have the nexthop
properly set. This was not the case for the mp_nexthop_global_in
attribute which was empty.
This commit is mandatory in order to later use nexthop tracking
context.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit addresses an issue with an MPLS VPN network
redistributing static routes that are exported to the VPN,
and where the labels are allocated per next-hop.
For that purpose, the nexthop of the static routes is
checked against the nexthop tracking. The validation
of a valid nexthop will trigger the use of a unique
label for all prefixes using that destination.
However, the nexthop fails to be validated, with the
following message:
> evaluate_paths: prefix 172:31::14/128 (vrf vrf1), ignoring path due to
> martian or self-next-hop
The reason is due to the way the attr is created.
By default, the ATTR_NEXTHOP attribute is set for
all prefixes, whereas this flag should only be valid
for IPv4. In the case there is an IPv6 nexthop, remove
the ATTR_NEXTHOP flag.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Adding support to show cmds like show bgp vrf all detail, show bgp
<afi> <safi> detail & show bgp <vrf> <afi> <safi> detail
Issue:3168406
Ticket:#3168406
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
Until now, the bgp local paths were using the default null label
defined. It was not possible to select the null label for the ipv4
or the ipv6 address families.
This commit addresses this issues by adding two extra-parameters
to the BGP labeled-unicast command.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The command `show bgp ipv4 uni neigh A.B.C.D received-routes detail`
was not displaying anything.
Fix the code to display the received routes from the ones that
have been filtered. In this case we need to fudge up a bgp_dest
and a bgp_path_info to make it work.
Old output:
janelle.pinkbelly.org# show bgp ipv4 uni neighbors 192.168.119.224 received-routes detail
BGP table version is 1711405, local router ID is 192.168.44.1, vrf id 0
Default local pref 100, local AS 64539
Total number of prefixes 3 (3 filtered)
janelle.pinkbelly.org#
New output:
janelle.pinkbelly.org# show bgp ipv4 uni neighbors 192.168.119.224 received-routes detail
BGP table version is 0, local router ID is 192.168.44.1, vrf id 0
Default local pref 100, local AS 64539
BGP routing table entry for 1.2.3.0/24, version 0
Paths: (1 available, no best path)
Not advertised to any peer
3291, (aggregated by 3291 192.168.122.1)
192.168.119.224 (inaccessible, import-check enabled) from 192.168.119.224 (192.168.122.1)
Origin IGP, metric 0, invalid, external, atomic-aggregate, rpki validation-state: not found
Community: 55:66
Last update: Fri Apr 14 08:46:48 2023
BGP routing table entry for 1.2.3.4/32, version 0
Paths: (1 available, no best path)
Not advertised to any peer
3291
192.168.119.224 (inaccessible, import-check enabled) from 192.168.119.224 (192.168.122.1)
Origin IGP, metric 0, invalid, external, rpki validation-state: not found
Community: 33:44
Last update: Fri Apr 14 08:46:48 2023
BGP routing table entry for 1.2.3.5/32, version 0
Paths: (1 available, no best path)
Not advertised to any peer
3291
192.168.119.224 (inaccessible, import-check enabled) from 192.168.119.224 (192.168.122.1)
Origin IGP, metric 0, invalid, external, rpki validation-state: not found
Community: 33:44
Last update: Fri Apr 14 08:46:48 2023
Total number of prefixes 3 (3 filtered)
janelle.pinkbelly.org# show bgp ipv4 uni
No BGP prefixes displayed, 0 exist
janelle.pinkbelly.org#
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Coverity points out that rd_str has already been
deref'ed in all paths leading to this spot. No
need to keep at it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
1. Consider a established L2VPN EVPN BGP peer with soft-reconfiguartion
inbound configured
2. When the interface of this directly connected BGP peer is shutdown,
bgp_soft_reconfig_table_update() is called, which memsets the evpn buffer
and calls bgp_update() with received attributes stored in ain table(ain->attr).
In bgp_update(), evpn_overlay attribute in ain->attr (which is an interned
attr) was modified by doing a memcpy
3. Above action causes 2 attributes in the attrhash (which were previously different)
to match!
4. Later during fsm change event of the peer, bgp_adj_in_remove() is called
to clean up the ain->attr. But, because 2 attrs in attrhash match, it causes
BGP to assert in bgp_attr_unintern()
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
kttps://datatracker.ietf.org/doc/html/draft-ietf-idr-node-target-ext-comm
unet> sh r1 vtysh -c 'sh ip bgp nei 192.168.1.2 adver'
BGP table version is 1, local router ID is 192.168.1.1, vrf id 0
Default local pref 100, local AS 65001
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.10.10.10/32 0.0.0.0 0 32768 i
Total number of prefixes 1
unet> sh r1 vtysh -c 'sh ip bgp nei 192.168.1.3 adver'
BGP table version is 1, local router ID is 192.168.1.1, vrf id 0
Default local pref 100, local AS 65001
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.10.10.10/32 0.0.0.0 0 32768 i
Total number of prefixes 1
unet> sh r2 vtysh -c 'show ip bgp 10.10.10.10/32'
% Network not in table
unet> sh r3 vtysh -c 'show ip bgp 10.10.10.10/32'
BGP routing table entry for 10.10.10.10/32, version 1
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
192.168.1.1
65001
192.168.1.1 from 192.168.1.1 (192.168.1.1)
Origin IGP, metric 0, valid, external, best (First path received)
Extended Community: NT:192.168.1.3 NT:192.168.1.4
Last update: Tue Apr 11 23:19:33 2023
unet>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The BGP local label value is not re-set when the prefix
is either a network or an aggregate prefix. Ensure to
get the appropriate label value each time the 'need_imp_null_label()'
function has to return true.
Fixes: 7ee70320d3 ("bgpd: add cli command to control explicit-null label usage")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
In BGP labeled unicast address-family, it is not possible to
send explicit-null label values with redistributed or network
declared prefixes.
A new CLI command is introduced:
> [no] bgp labeled-unicast explicit-null
When used, the explicit-null value for IPv4 ('0' value) or
IPv6 ('2' value) will be used.
It is necessary to reconfigure the networks or the
redistribution in order to inherit this new behaviour.
Add the documentation.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The json structure changes used for 'json detail' show commands are not
very straightforward and might require code analysis to understand.
This addscommentary to the flow to explain the change in structure.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Memory leaks are observed in the cleanup code. When “no router bgp" is executed,
cleanup in that flow for aggregate-address command is not taken care.
fixes the below leak:
--
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444:Direct leak of 152 byte(s) in 1 object(s) allocated from:
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #0 0x7f163e911037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #1 0x7f163e4b9259 in qcalloc lib/memory.c:105
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #2 0x562bf42ebbd5 in bgp_aggregate_new bgpd/bgp_route.c:7239
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #3 0x562bf42f14e8 in bgp_aggregate_set bgpd/bgp_route.c:8421
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #4 0x562bf42f1e55 in aggregate_addressv6_magic bgpd/bgp_route.c:8592
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #5 0x562bf42be3f5 in aggregate_addressv6 bgpd/bgp_route_clippy.c:341
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #6 0x7f163e3f1e1b in cmd_execute_command_real lib/command.c:988
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #7 0x7f163e3f219c in cmd_execute_command lib/command.c:1048
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #8 0x7f163e3f2df4 in cmd_execute lib/command.c:1215
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #9 0x7f163e5a2d73 in vty_command lib/vty.c:544
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #10 0x7f163e5a79c8 in vty_execute lib/vty.c:1307
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #11 0x7f163e5ad299 in vtysh_read lib/vty.c:2216
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #12 0x7f163e593f16 in event_call lib/event.c:1995
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #13 0x7f163e47c839 in frr_run lib/libfrr.c:1185
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #14 0x562bf414e58d in main bgpd/bgp_main.c:505
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #15 0x7f163de66d09 in __libc_start_main ../csu/libc-start.c:308
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444:Direct leak of 152 byte(s) in 1 object(s) allocated from:
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #0 0x7f163e911037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #1 0x7f163e4b9259 in qcalloc lib/memory.c:105
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #2 0x562bf42ebbd5 in bgp_aggregate_new bgpd/bgp_route.c:7239
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #3 0x562bf42f14e8 in bgp_aggregate_set bgpd/bgp_route.c:8421
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #4 0x562bf42f1cde in aggregate_addressv4_magic bgpd/bgp_route.c:8543
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #5 0x562bf42bd258 in aggregate_addressv4 bgpd/bgp_route_clippy.c:255
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #6 0x7f163e3f1e1b in cmd_execute_command_real lib/command.c:988
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #7 0x7f163e3f219c in cmd_execute_command lib/command.c:1048
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #8 0x7f163e3f2df4 in cmd_execute lib/command.c:1215
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #9 0x7f163e5a2d73 in vty_command lib/vty.c:544
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #10 0x7f163e5a79c8 in vty_execute lib/vty.c:1307
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #11 0x7f163e5ad299 in vtysh_read lib/vty.c:2216
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #12 0x7f163e593f16 in event_call lib/event.c:1995
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #13 0x7f163e47c839 in frr_run lib/libfrr.c:1185
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #14 0x562bf414e58d in main bgpd/bgp_main.c:505
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444- #15 0x7f163de66d09 in __libc_start_main ../csu/libc-start.c:308
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-
./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-SUMMARY: AddressSanitizer: 304 byte(s) leaked in 2 allocation(s).
Signed-off-by: Samanvitha B Bhargav <bsamanvitha@vmware.com>
For instance, if we receive the routes from the peer with the next-hop as me,
but those routes shares the same network, we can fake the next-hop.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Effectively a massive search and replace of
`struct thread` to `struct event`. Using the
term `thread` gives people the thought that
this event system is a pthread when it is not
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This is a first in a series of commits, whose goal is to rename
the thread system in FRR to an event system. There is a continual
problem where people are confusing `struct thread` with a true
pthread. In reality, our entire thread.c is an event system.
In this commit rename the thread.[ch] files to event.[ch].
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The flag for telling BGP that a route is expected to be installed
first before notifying a peer was always being set upon receipt
of a path that could be accepted as bestpath. This is not correct:
imagine that you have a peer sending you a route and you have a
network statement that covers the same route. Irrelevant if the
network statement would win the flag on the dest was being set
in bgp_update. Thus you could get into a situation where
the network statement path wins but since the flag is set on
the node, it will never be announced to a peer.
Let's just move the setting of the flag into bgp_zebra_announce
and _withdraw. In _announce set the flag to TRUE when suppress-fib
is enabled. In _withdraw just always unset the flag as that a withdrawal
does not need to wait for rib removal before announcing. This will
cover the case when a network statement is added after the route has
been learned from a peer.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This is a preliminary work to export redistributed routes from
a given VRF in an VPN network. The exportation works well, when
the label allocation is based on an per-vrf mode, but not on
a per nexthop mode.
To associate a label with a connected nexthop, the nexthop
tracking contexts are used. Until today, there was no tracking
context for redistributed routes. But when using this vpn
allocation mode, one needs to know whether the route is directly
connected or not. When using the nexthop tracking context, the
nexthop attribute of the bgp update needs to have the nexthop
properly set. This was not the case for the mp_nexthop_global_in
attribute which was empty.
This commit is mandatory in order to later use nexthop tracking
context.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit addresses an issue with an MPLS VPN network
redistributing static routes that are exported to the VPN,
and where the labels are allocated per next-hop.
For that purpose, the nexthop of the static routes is
checked against the nexthop tracking. The validation
of a valid nexthop will trigger the use of a unique
label for all prefixes using that destination.
However, the nexthop fails to be validated, with the
following message:
> evaluate_paths: prefix 172:31::14/128 (vrf vrf1), ignoring path due to
> martian or self-next-hop
The reason is due to the way the attr is created.
By default, the ATTR_NEXTHOP attribute is set for
all prefixes, whereas this flag should only be valid
for IPv4. In the case there is an IPv6 nexthop, remove
the ATTR_NEXTHOP flag.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Some debugs were especially hard to figure out in bgp_route.c
a) If using a %p pointer to print the bgp_path_info this
is pretty useless. Print where it came from instead
b) Use A.B.C.D/M(VRFNAME) when outputing the prefix
Just basically give more useful information.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add a hash_clean_and_free() function as well as convert
the code to use it. This function also takes a double
pointer to the hash to set it NULL. Also it cleanly
does nothing if the pointer is NULL( as a bunch of
code tested for ).
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If route-map deny match is returned, we should free previously dup'ed
attributes: aspath, community, large community, extended community.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
a) Make it legible what type of message is being passed
back and forth instead of having to guess it from
the insufficient debugs
b) Make it explicit which bgp instance is sending this
data
c) Cleanup bgp_zebra_update to have a cleaner api
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
```
==21860==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 80 byte(s) in 2 object(s) allocated from:
0 0x7f8065294d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
1 0x7f8064cfd216 in qcalloc lib/memory.c:105
2 0x5646b7024073 in ecommunity_dup bgpd/bgp_ecommunity.c:252
3 0x5646b7153585 in route_set_ecommunity_lb bgpd/bgp_routemap.c:2925
4 0x7f8064d459be in route_map_apply_ext lib/routemap.c:2675
5 0x5646b7116584 in subgroup_announce_check bgpd/bgp_route.c:2374
6 0x5646b711b907 in subgroup_process_announce_selected bgpd/bgp_route.c:2918
7 0x5646b717ceb8 in group_announce_route_walkcb bgpd/bgp_updgrp_adv.c:184
8 0x7f8064cc6acd in hash_walk lib/hash.c:270
9 0x5646b717ae0c in update_group_af_walk bgpd/bgp_updgrp.c:2046
10 0x5646b7181275 in group_announce_route bgpd/bgp_updgrp_adv.c:1030
11 0x5646b711a986 in bgp_process_main_one bgpd/bgp_route.c:3303
12 0x5646b711b5bf in bgp_process_wq bgpd/bgp_route.c:3444
13 0x7f8064da12d7 in work_queue_run lib/workqueue.c:267
14 0x7f8064d891fb in thread_call lib/thread.c:1991
15 0x7f8064cdffcf in frr_run lib/libfrr.c:1185
16 0x5646b6feca67 in main bgpd/bgp_main.c:505
17 0x7f8063f96c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 16 byte(s) in 2 object(s) allocated from:
0 0x7f8065294b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
1 0x7f8064cfcf01 in qmalloc lib/memory.c:100
2 0x5646b7024151 in ecommunity_dup bgpd/bgp_ecommunity.c:256
3 0x5646b7153585 in route_set_ecommunity_lb bgpd/bgp_routemap.c:2925
4 0x7f8064d459be in route_map_apply_ext lib/routemap.c:2675
5 0x5646b7116584 in subgroup_announce_check bgpd/bgp_route.c:2374
6 0x5646b711b907 in subgroup_process_announce_selected bgpd/bgp_route.c:2918
7 0x5646b717ceb8 in group_announce_route_walkcb bgpd/bgp_updgrp_adv.c:184
8 0x7f8064cc6acd in hash_walk lib/hash.c:270
9 0x5646b717ae0c in update_group_af_walk bgpd/bgp_updgrp.c:2046
10 0x5646b7181275 in group_announce_route bgpd/bgp_updgrp_adv.c:1030
11 0x5646b711a986 in bgp_process_main_one bgpd/bgp_route.c:3303
12 0x5646b711b5bf in bgp_process_wq bgpd/bgp_route.c:3444
13 0x7f8064da12d7 in work_queue_run lib/workqueue.c:267
14 0x7f8064d891fb in thread_call lib/thread.c:1991
15 0x7f8064cdffcf in frr_run lib/libfrr.c:1185
16 0x5646b6feca67 in main bgpd/bgp_main.c:505
17 0x7f8063f96c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The BGP path info debugging information should dump the
real peer information for imported prefixes.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The bgp_path_info_cmp() function needs to get the peer of
imported prefixes in many parts of the algorithm. Use two
local variables to get the original peer either for vpn
imported prefixes or from standard prefixes.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Until now, when calculating the bgp bestpath route, the peer
comparison could not be performed for imported prefixes, as
the peer origin could not be retrieved. As consequence, the
reason why a given prefix as chosen was wrong: "Locally
configured route" was the main reason, whereas the prefix
was imported from a remote peer.
Fix this by searching for the real peer.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
"show bgp <afi> <safi> json detail" was incorrectly displaying header
information from route_vty_out_detail_header() as an element of the
"paths" array. This corrects the behavior for 'json detail' so that a
route holds a dictionary with keys for "paths" and header info, which
aligns with how we structure the output for a specific prefix, e.g.
"show bgp <afi> <safi> <prefix> json".
Before:
```
ub20# show ip bgp json detail
{
"vrfId": 0,
"vrfName": "default",
"tableVersion": 3,
"routerId": "100.64.0.222",
"defaultLocPrf": 100,
"localAS": 1,
"routes": { "2.2.2.2/32": [
{ <<<<<<<<< should be outside the array
"prefix":"2.2.2.2/32",
"version":1,
"advertisedTo":{
"192.168.122.12":{
"hostname":"ub20-2"
}
}
},
{
"aspath":{
"string":"Local",
"segments":[
],
"length":0
},
<snip>
```
After:
```
ub20# show ip bgp json detail
{
"vrfId": 0,
"vrfName": "default",
"tableVersion": 3,
"routerId": "100.64.0.222",
"defaultLocPrf": 100,
"localAS": 1,
"routes": { "2.2.2.2/32": {
"prefix": "2.2.2.2/32",
"version": "1",
"advertisedTo": {
"192.168.122.12":{
"hostname":"ub20-2"
}
}
,"paths": [
{
"aspath":{
"string":"Local",
"segments":[
],
"length":0
},
```
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Ensure that a multipath set is fully comprised of EVPN paths (i.e.,
paths imported into the VRF from EVPN address-family) or non-EVPN
paths. This is actually a condition that existed already in the code
but was not properly enforced.
This change, as a side effect, eliminates the known trigger condition
for bad or missing RMAC programming in an EVPN deployment, described
in tickets CM-29043 and CM-31222. Routes (actually, paths) in a VRF
routing table that require VXLAN tunneling to the next hop currently
need some special handling in zebra to deal with the nexthop (neigh)
and RMAC programming, and this is implemented for the entire route
(prefix), not per-path. This can lead to the bad or missing RMAC
situation, which is now eliminated by ensuring all paths in the route
are 'similar'.
The longer-term solution in CL 5.x will be to deal with the special
programming by means of explicit communication between bgpd and zebra.
This is already implemented for EVPN-MH via CM-31398. These changes
will be extended to non-MH also and the special code in zebra removed
or refined.
Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
Acked-by: Trey Aspelund <taspelund@nvidia.com>
Acked-by: Anuradha Karuppiah <anuradhak@nvidia.com>
Acked-by: Chirag Shah <chirag@nvidia.com>
Ticket: CM-29043
Testing Done:
1. Manual testing
2. precommit on both MLX and BCM platforms
3. evpn-smoke - BCM and VX
Results described in the ticket
When performing deterministic MED processing, ensure that the peer
status is not checked when we encounter a stale path. Otherwise, this
path will be skipped from the DMED consideration leading to it potentially
not being installed.
Test scenario: Consider a prefix with 2 (multi)paths. The peer that
announces the path with the winning DMED undergoes a graceful-restart.
Before it comes back up, the other path goes away. Prior to the fix, a
third router that receives both these paths would have ended up not
having any path installed to the prefix after the above events.
Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
For internal use:
Ticket: CM-32032
Testing done: Multiple manual testing
Add a keyword self-originate" to extend current CLI commands to filter out self-originated routes only
a\) CLI to show ipv4/ipv6 self-originated routes
"show [ip] bgp [afi] [safi] [all] self-originate [wide|json]"
b\) CLI to show evpn self-originated routes
"show bgp l2vpn evpn route [detail] [type <ead|macip|multicast|es|prefix|1|2|3|4|5>] self-originate [json]"
Signed-off-by: Karl Quan <kquan@nvidia.com>
The bgp network command creates static routes with an optional
route-distinguisher parameter for VPN and EVPN address families.
Store the rd parameter in those static routes. This will be used
by the 'show running-config' later.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The route-distinguisher string can be expressed in different
ways when the AS number is part of the RD. And the configured
string value has to be kept intact.
The following vty commands store the string value internally:
- router bgp / address-family ipv4 unicast / rd vpn export <>
- router bgp / address-family l2vpn evpn / rd <>
- router bgp / address-family l2vpn evpn / vni <> / rd <>
The vty commands where RD is configured in the below places is
not considered:
- router bgp / rfapi related commands
- router bgp / address-family xxx xxx / network .. rd <>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
RD may be built based on an AS number. Like for the AS, the RD
may use the AS notation. The two below examples can illustrate:
RD 1.1:20 stands for an AS4B:NN RD with AS4B=65536 in dot format.
RD 0.1:20 stands for an AS2B:NNNN RD with AS2B=0.1 in dot+ format.
This commit adds the asnotation mode to prefix_rd2str() API so as
to pick up the relevant display.
Two new printfrr extensions are available to display the RD with
the two above display methods.
- The pRDD extension stands for dot asnotation format
- The pRDE extension stands for dot+ asnotation format.
- The pRD extension has been renamed to pRDP extension
The code is changed each time '%pRD' printf extension is called.
Possibly, the asnotation may change the output, then a macro defines
the asnotation mode to use. A side effect of forging the mode to
use is that the string could not be concatenated with other strings
in vty_out and snprintfrr. Those functions have been called multiple
times. When zlog_debug needs to display the RD with some other string,
the prefix_rd2str() old API is used instead of the printf extension.
Some code has been kept untouched:
- code related to running-config. Actually, wherever an RD is displayed,
its configured name should be dumped.
- bgp rfapi code
- bgp evpn multihoming code (partially done), since the logic is
missing to get the asnotation of 'struct bgp_evpn_es'.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
A json AS number API is created in order to output a
given AS number. In order to keep backward compatibility,
if the as-notation uses a number, then the json is encoded
as an integer, otherwise the encoding will be a string.
For what is not relevant to running-configuration, the
as-notation mode is the one used for the BGP instance.
Also, the vty completion gets the configured 'as_pretty'
string value, when an user wants to get the available
BGP instances.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Each BGP prefix may have an as-path list attached. A forged
string is stored in the BGP attribute and shows the as-path
list output.
Before this commit, the as-path list output was expressed as
a list of AS values in plain format. Now, if a given BGP instance
uses a specific asnotation, then the output is changed:
new output:
router bgp 1.1 asnotation dot
!
address-family ipv4 unicast
network 10.200.0.0/24 route-map rmap
network 10.201.0.0/24 route-map rmap
redistribute connected route-map rmap
exit-address-family
exit
!
route-map rmap permit 1
set as-path prepend 1.1 5433.55 264564564
exit
ubuntu2004# do show bgp ipv4
BGP table version is 2, local router ID is 10.0.2.15, vrf id 0
Default local pref 100, local AS 1.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
*> 4.4.4.4/32 0.0.0.0 0 32768 1.1 5433.55 4036.61268 ?
*> 10.0.2.0/24 0.0.0.0 0 32768 1.1 5433.55 4036.61268 ?
10.200.0.0/24 0.0.0.0 0 32768 1.1 5433.55 4036.61268 i
10.201.0.0/24 0.0.0.0 0 32768 1.1 5433.55 4036.61268 i
The changes include:
- the aspath structure has a new field: asnotation type
The ashash list will differentiate 2 aspaths using a different
asnotation.
- 3 new printf extensions display the as number in the wished
format: pASP, pASD, pASE for plain, dot, or dot+ format (extended).
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This introduces the option for a user to lookup one specific prefix in
the advertised-routes or received-routes table of a peer.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Initial commit: 23b2a7ef52
changed the json output of `show bgp <afi> <safi> json` to
not have pretty print because when under a situation where
there are a bunch of routes with a large scale ecmp show
output was taking forever and this commit cut 2 minutes out
of vtysh run time.
Subusequent commit: f4ec52f7cc
changed this back.
When upgrading to latest version the long run time was noticed
due to testing. Let's add back this functionality such that
FRR can have reduced run times with vtysh when it's really
needed.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
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.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
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.
Fixes: 35ac9b53f2 ("bgpd: fix vpnv6 nexthop encoding")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
MPLS VPN networks can either peer with iBGP or eBGP. When
calculating the distance to send to zebra, the imported prefix
is never sent with distance information, even if the vty
command is used under the ipv4 unicast address family:
router bgp 65505 vrf vrf1
address-family ipv4 unicast
distance bgp 26 27 28
[vpn config]
The observation is that the distance sent to zebra for an
imported prefix is still 20:
[..]
VRF vrf1:
B> 192.168.0.0/24 [20/0] via 2.2.2.2 (vrf default) (recursive), label 20, weight 1, 00:00:12
* via 10.125.0.6, ntfp3 (vrf default), label implicit-null/20, weight 1, 00:00:12
The expectation is that the incoming prefix has to follow the
distance that is configured, or the distance derived from the peer
relationship established by the parent prefix.
In the case, an iBGP relationship is done, and no distance
configuration is done, the below show is expected:
[..]
VRF vrf1:
B*> 192.168.0.0/24 [200/0] via 192.168.0.2, r1-gre0 (vrf default), label 20, weight 1, 00:00:12
In the case an iBGP relationship is done, and distance configuration
is performed as below:
[..]
distance bgp 21 201 41
[..]
Then the below show is expected:
[..]
VRF vrf1:
B*> 192.168.0.0/24 [201/0] via 192.168.0.2, r1-gre0 (vrf default), label 20, weight 1, 00:00:12
To get this behaviour, get the peer origin where the prefix is coming
from.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Before this patch, we needed to explicitly define a neighbor to be SOLO
(= separate update-group). Let's ease this functionality for an operator to
avoid confusions.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Introduce a "detail" keyword for per-neighbor/per-afi-safi
advertised-routes and received-routes show commands.
Includes json support.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Shutdown of bgp results in both the bgp_path_info,
bgp_dest and bgp_table's not being freed because
the bgp_path_info remains locked.
Effectively static routes are scheduled for deletion but bgp_process
skips the work because the work queue sees that the bgp router
is marked for deletion. Effectively not doing any work and leaving
data on the floor.
Modify the code when attempting to put into the work queue to
notice and not do so but just unlock the path info.
This is effectively the same as what goes on for normal peering
as that it checks for shutdown and just calls bgp_path_info_free
too.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
```
unet> sh pe2 vtysh -c 'sh ip bgp ipv4 vpn detail-routes'
BGP table version is 4, local router ID is 10.10.10.20, vrf id 0
Default local pref 100, local AS 65001
Route Distinguisher: 192.168.2.2:2
BGP routing table entry for 192.168.2.2:2:10.0.0.0/24, version 1
not allocated
Paths: (1 available, best #1)
Not advertised to any peer
65000
192.168.2.1 from 0.0.0.0 (10.10.10.20) vrf RED(4) announce-nh-self
Origin incomplete, metric 0, localpref 50, valid, sourced, local, best (First path received)
Extended Community: RT:192.168.2.2:2
Originator: 10.10.10.20
Remote label: 2222
Last update: Tue Dec 20 13:01:20 2022
BGP routing table entry for 192.168.2.2:2:172.16.255.1/32, version 2
not allocated
Paths: (1 available, best #1)
Not advertised to any peer
65000
192.168.2.1 from 0.0.0.0 (10.10.10.20) vrf RED(4) announce-nh-self
Origin incomplete, localpref 50, valid, sourced, local, best (First path received)
Extended Community: RT:192.168.2.2:2
Originator: 10.10.10.20
Remote label: 2222
Last update: Tue Dec 20 13:01:20 2022
BGP routing table entry for 192.168.2.2:2:192.168.1.0/24, version 3
not allocated
Paths: (1 available, best #1)
Not advertised to any peer
65000
192.168.2.1 from 0.0.0.0 (10.10.10.20) vrf RED(4) announce-nh-self
Origin incomplete, localpref 50, valid, sourced, local, best (First path received)
Extended Community: RT:192.168.2.2:2
Originator: 10.10.10.20
Remote label: 2222
Last update: Tue Dec 20 13:01:20 2022
BGP routing table entry for 192.168.2.2:2:192.168.2.0/24, version 4
not allocated
Paths: (1 available, best #1)
Not advertised to any peer
65000
192.168.2.1 from 0.0.0.0 (10.10.10.20) vrf RED(4) announce-nh-self
Origin incomplete, metric 0, localpref 50, valid, sourced, local, best (First path received)
Extended Community: RT:192.168.2.2:2
Originator: 10.10.10.20
Remote label: 2222
Last update: Tue Dec 20 13:01:20 2022
Displayed 4 routes and 4 total paths
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Absolutely not possible to read the output and even distinguish the prefix
we are looking for.
Before:
```
donatas-pc# show ip bgp detail
BGP table version is 12, local router ID is 192.168.10.17, vrf id 0
Default local pref 100, local AS 65002
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
65001
2a02:4780:abc::2 from 2a02:4780:abc::2 (200.200.200.202)
(fe80::a00:27ff:fe5e:d19e) (used)
Origin incomplete, metric 0, valid, external, multipath
Last update: Tue Dec 13 22:53:16 2022
65001
192.168.10.124 from 192.168.10.124 (200.200.200.202)
Origin incomplete, metric 0, valid, external, otc 65001, multipath, best (Neighbor IP)
Last update: Tue Dec 13 22:53:16 2022
65001
2a02:4780:abc::2 from 2a02:4780:abc::2 (200.200.200.202)
(fe80::a00:27ff:fe5e:d19e) (used)
Origin IGP, metric 0, valid, external, multipath
Last update: Tue Dec 13 22:53:16 2022
65001
192.168.10.124 from 192.168.10.124 (200.200.200.202)
Origin IGP, metric 0, valid, external, otc 65001, multipath, best (Neighbor IP)
Last update: Tue Dec 13 22:53:16 2022
```
After:
```
donatas-pc# show ip bgp detail
BGP table version is 12, local router ID is 192.168.10.17, vrf id 0
Default local pref 100, local AS 65002
BGP routing table entry for 10.0.2.0/24, version 1
Paths: (2 available, best #2, table default)
Advertised to non peer-group peers:
2a02:4780:abc::2
65001
2a02:4780:abc::2 from 2a02:4780:abc::2 (200.200.200.202)
(fe80::a00:27ff:fe5e:d19e) (used)
Origin incomplete, metric 0, valid, external, multipath
Last update: Tue Dec 13 22:47:16 2022
BGP routing table entry for 10.0.2.0/24, version 1
Paths: (2 available, best #2, table default)
Advertised to non peer-group peers:
2a02:4780:abc::2
65001
192.168.10.124 from 192.168.10.124 (200.200.200.202)
Origin incomplete, metric 0, valid, external, otc 65001, multipath, best (Neighbor IP)
Last update: Tue Dec 13 22:47:16 2022
BGP routing table entry for 10.10.100.0/24, version 2
Paths: (2 available, best #2, table default)
Advertised to non peer-group peers:
2a02:4780:abc::2
65001
2a02:4780:abc::2 from 2a02:4780:abc::2 (200.200.200.202)
(fe80::a00:27ff:fe5e:d19e) (used)
Origin IGP, metric 0, valid, external, multipath
Last update: Tue Dec 13 22:47:16 2022
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Previous commits have introduced a new 8 bits nh_flag in the attr
struct that has increased the memory footprint.
Move the mp_nexthop_prefer_global boolean in the attr structure that
takes 8 bits to the new nh_flag in order to go back to the previous
memory utilization.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
At bgpd startup, VRF instances are sent from zebra before the
interfaces. When importing a l3vpn prefix from another local VRF
instance, the interfaces are not known yet. The prefix nexthop interface
cannot be set to the loopback or the VRF interface, which causes setting
invalid routes in zebra.
Update route leaking when the loopback or a VRF interface is received
from zebra.
At a VRF interface deletion, zebra voluntarily sends a
ZEBRA_INTERFACE_ADD message to move it to VRF_DEFAULT. Do not update if
such a message is received. VRF destruction will destroy all the related
routes without adding codes.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Display IGP metric of the ultimate path in the command
"show bgp vrf X ipv(4|6)".
Fixes: da0c0ef70c ("bgpd: VRF-Lite fix best path selection")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
The withdraw message and announcement message of a prefix are received continuously within 50ms, which may lead to abnormal aggregation route reference count.
Steps to reproduce:
--------------------------
step1:
local config aggregate route 111.0.0.0/24
received route：111.0.0.1/32 111.0.0.02/32
ref_count:2
step2:
peer withdraw 111.0.0.1/32 and network 111.0.0.1/32 in 50ms
received route：111.0.0.1/32 111.0.0.02/32
ref_count:1
step3:
peer withdraw 111.0.0.1/32
received route：111.0.0.02/32
ref_count:0
aggregate route will be withdrawn abnormally
Signed-off-by: liuze03 <liuze03@baidu.com>
```
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>
