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>
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 usage of bgp_vrf does not need to be tested
at this point since it's already been derefed in all
paths to this point.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
problem:
In CLI config codeflow there are memory leaks in failure scenario
Fix:
Code changes are done to free ecommunity
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
The `bgp_vrf->vrf_prd_pretty` string was not properly freed, leading to a memory leak.
This commit resolves the memory leak by freeing the memory allocated for `bgp_vrf->vrf_prd_pretty` before returning from the function.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in evpn_type5_test_topo1.test_evpn_type5_topo1/e1.asan.bgpd.17689
=================================================================
==17689==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 15 byte(s) in 1 object(s) allocated from:
#0 0x7fdd94fc0538 in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x77538)
#1 0x55e28d9c4c6c in qstrdup lib/memory.c:117
#2 0x55e28d6c0d27 in evpn_configure_vrf_rd bgpd/bgp_evpn_vty.c:2297
#3 0x55e28d6c0d27 in bgp_evpn_vrf_rd bgpd/bgp_evpn_vty.c:6271
#4 0x55e28d94c155 in cmd_execute_command_real lib/command.c:994
#5 0x55e28d94c622 in cmd_execute_command lib/command.c:1053
#6 0x55e28d94ca99 in cmd_execute lib/command.c:1221
#7 0x55e28da6d7d4 in vty_command lib/vty.c:591
#8 0x55e28da6dc6e in vty_execute lib/vty.c:1354
#9 0x55e28da7644d in vtysh_read lib/vty.c:2362
#10 0x55e28da616e2 in event_call lib/event.c:1995
#11 0x55e28d9a7a65 in frr_run lib/libfrr.c:1213
#12 0x55e28d63ef00 in main bgpd/bgp_main.c:505
#13 0x7fdd93883c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 15 byte(s) leaked in 1 allocation(s).
***********************************************************************************
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
In CI, CLANG static analyzer started complaining about possible null
dereferences of pre-existing fields. Let's make it happy and do a null
check.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Change CMD_WARNING -> CMD_WARNING_CONFIG_FAILED so that the rc is
non-zero and the caller can detect a failure.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Initial support for configuring an SoO for all MAC-VRFs (EVIs/L2VNIs).
This provides a topology-independent method of preventing EVPN routes
from one MAC-VRF "site" (an L2 domain) from being imported by other PEs
in the same MAC-VRF "site", similar to how SoO is traditionally used in
L3VPN to identify and break loops for an L3/IP-VRF "site".
One example of where a MAC-VRF SoO can be used to avoid an L2 control
plane loop is with Active/Active MLAG VTEPs. For a given L2 site only
one control plane should be active. SoO can be used to ID/ignore entries
originated from the local MAC-VRF site so that EVPN will not attempt to
manage entries that are already handled by MLAG.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
The output of show bgp all json is inconsistent across Address-families
i.e. ipv4/ipv6 is a no pretty format while l2vpn-evpn is in a pretty
format. For huge scale (lots of routes with lots of paths), it is better
to use no_pretty format.
Before fix:
torm-11# sh bgp all json
{
"ipv4Unicast":{
"vrfId": 0,
"vrfName": "default",
"tableVersion": 1,
"routerId": "27.0.0.15",
"defaultLocPrf": 100,
"localAS": 65000,
"routes": { } }
,
"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":[
<SNIP>.............
After fix:
torm-11# sh bgp all json
{
"ipv4Unicast":{
"vrfId": 0,
"vrfName": "default",
"tableVersion": 1,
"routerId": "27.0.0.15",
"defaultLocPrf": 100,
"localAS": 65000,
"routes": { } }
,
"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":[[{"valid":true,"bestpath":true,"selectionReason":"First path received","pathFrom":"external","routeType":1,"weight":32768,"peerId":"(unspec)","path":"","origin":"IGP","extendedCommunity"
<SNIP>.............
Issue: 3472865
Ticket:#3472865
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.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>
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 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>
```
anlan(config-router-af)# vni 33
anlan(config-router-af-vni)# route-target both 44:55
anlan(config-router-af-vni)# no route-target both 44:55
vtysh: error reading from bgpd: Resource temporarily unavailable (11)Warning: closing connection to bgpd because of an I/O error!
```
When `bgp_evpn_vni_rt_cmd` deals with "both" type, it wrongly created
only one node ( should be two nodes ) for lists of both `vpn->import_rtl` and
`vpn->export_rtl`. At this time, the two lists are already wrong.
In `no route-target both RT`, it will free the single node from lists of both
`vpn->import_rtl` and `vpn->export_rtl`. After freed from `vpn->import_rtl`,
it is "use-after-free" at the time of freeing it from `vpn->export_rtl`.
It causes crash sometimes, or other unexpected behaviours.
This issue is introduced by commit `3b7e8d`, which have adjusted both
`bgp_evpn_vni_rt_cmd` and `bgp_evpn_vrf_rt_cmd`.
Since `bgp_evpn_vrf_rt_cmd/no_bgp_evpn_vrf_rt_cmd` works well again
unintentionally with commit `7022da`, only `bgp_evpn_vni_rt_cmd` needs to
modify - add two nodes for "both" type and some explicit comments for this
special case of "both" type.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Commit: 3cdb03fba7
changed the vty_json output to not be pretty printing.
The previous commit in the tree added vty_json_no_pretty
let's use that instead
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
For BGP evpn route table detail json to use
non pretty form of display.
Problem:
In scaled evpn route table detail json dump
occupies high resources (CPU + memory) of the system.
In high scale evpn route dump using pretty form
hogs CPU for a while which can trigger watchfrr
to kill bgpd.
Solution:
Avoid pretty JSON print for detail version dump
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Use %pI4/%pI6 where possible, otherwise at least atjust stack buffer sizes
for inet_ntop() calls.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
In the case of without ':' in `ecom_str`, memleak on this `ecom_str` will
occur. Just free `ecom_str` for this case.
Signed-off-by: anlan_cs <vic.lan@pica8.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>
The "RTLIST..." list should be maintained integrity. If wildcard check
failed, it should immediately return failure. Otherwise user configuration
will be partial.
```
anlan(config-router-af)# route-target export *:55 33:33
% Wildcard '*' only applicable for import
anlan(config-router-af)# route-target both *:55 33:33
% Wildcard '*' only applicable for import
```
With this commit, the RTs without wildcard will not be executed as before. And
the same for `no` form.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Fix the vni_str NULL check for wildcard route-targets
in evpn show run. This will never be NULL if we add 1
here. Though it should also never be NULL since ":" should
always exist. Better to be safe than sorry.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Add add show bgp vni <VNI|all> json commands.
This is very similar to the old `show bgp evpn l2vpn vni route json`
commands but adds a new `macTable` object under the normal output.
This may change in the future but doing it like this for now
VNI ALL:
```
{
"1002":{
"vni":1002,
"[2]:[0]:[48]:[00:00:00:00:00:00]:[128]:[fe80::202:ff:fe00:9]":{
"prefix":"[2]:[0]:[48]:[00:00:00:00:00:00]:[128]:[fe80::202:ff:fe00:9]",
"prefixLen":352,
"paths":[
[
{
"valid":true,
"pathFrom":"external",
...
...
...
"numPrefix":4,
"numPaths":7,
"macTable":{
"[2]:[0]:[48]:[00:02:00:00:00:09]":{
"prefix":"[2]:[0]:[48]:[00:02:00:00:00:09]",
"prefixLen":352,
"paths":[
[
{
"valid":true,
"pathFrom":"external",
```
VNI 1002:
```
{
"[2]:[0]:[48]:[00:00:00:00:00:00]:[128]:[fe80::202:ff:fe00:9]":{
"prefix":"[2]:[0]:[48]:[00:00:00:00:00:00]:[128]:[fe80::202:ff:fe00:9]",
"prefixLen":352,
"paths":[
[
{
"valid":true,
"pathFrom":"external",
...
...
...
"numPrefix":4,
"numPaths":7,
"macTable":{
"[2]:[0]:[48]:[00:02:00:00:00:09]":{
"prefix":"[2]:[0]:[48]:[00:02:00:00:00:09]",
"prefixLen":352,
"paths":[
[
{
"valid":true,
"pathFrom":"external",
```
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Re-work the bgp vni table to use separately keyed tables for type2
routes.
So, with type2 routes, we have the main table keyed off of the IP and a
new MAC table keyed off of MACs.
By separating out the two, we are able to run path selection separately
for the neigh and mac. Keeping the two separate is also more in-line
with what happens in zebra (they are managed comptletely seperate).
With this change type2 routes go into each table like so:
```
Remote MAC-IP -> IP Table & MAC Table
Remote MAC -> MAC Table
Local MAC-IP -> IP Table
Local MAC -> MAC Table
```
The difference for local is necessary because we should not ever allow
multiple paths for a local MAC.
Also cleaned up the commands for querying the vni tables:
```
show bgp vni all type ...
show bgp vni VNI type ...
```
Old commands will be deprecated in a separate commit.
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>
