The motivation for this patch is to address a concerning behavior of
tx-addpath-bestpath-per-AS. Prior to this patch, all paths' TX ID was
pre-determined as the path was received from a peer. However, this meant
that any time the path selected as best from an AS changed, bgpd had no
choice but to withdraw the previous best path, and advertise the new
best-path under a new TX ID. This could cause significant network
disruption, especially for the subset of prefixes coming from only one
AS that were also communicated over a bestpath-per-AS session.
The patch's general approach is best illustrated by
txaddpath_update_ids. After a bestpath run (required for best-per-AS to
know what will and will not be sent as addpaths) ID numbers will be
stripped from paths that no longer need to be sent, and held in a pool.
Then, paths that will be sent as addpaths and do not already have ID
numbers will allocate new ID numbers, pulling first from that pool.
Finally, anything left in the pool will be returned to the allocator.
In order for this to work, ID numbers had to be split by strategy. The
tx-addpath-All strategy would keep every ID number "in use" constantly,
preventing IDs from being transferred to different paths. Rather than
create two variables for ID, this patch create a more generic array that
will easily enable more addpath strategies to be implemented. The
previously described ID manipulations will happen per addpath strategy,
and will only be run for strategies that are enabled on at least one
peer.
Finally, the ID numbers are allocated from an allocator that tracks per
AFI/SAFI/Addpath Strategy which IDs are in use. Though it would be very
improbable, there was the possibility with the free-running counter
approach for rollover to cause two paths on the same prefix to get
assigned the same TX ID. As remote as the possibility is, we prefer to
not leave it to chance.
This ID re-use method is not perfect. In some cases you could still get
withdraw-then-add behaviors where not strictly necessary. In the case of
bestpath-per-AS this requires one AS to advertise a prefix for the first
time, then a second AS withdraws that prefix, all within the space of an
already pending MRAI timer. In those situations a withdraw-then-add is
more forgivable, and fixing it would probably require a much more
significant effort, as IDs would need to be moved to ADVs instead of
paths.
Signed-off-by Mitchell Skiba <mskiba@amazon.com>
Same sequence number handling is specified by RFC 7432 -
[
If two (or more) PEs advertise the same MAC address with the same
sequence number but different Ethernet segment identifiers, a PE that
receives these routes selects the route advertised by the PE with the
lowest IP address as the best route.
If the PE is the originator of the MAC route and it receives the same
MAC address with the same sequence number that it generated, it will
compare its own IP address with the IP address of the remote PE and
will select the lowest IP. If its own route is not the best one, it
will withdraw the route.
]
To implement that specification this commit uses nexthop IP as a tie
breaker between two paths of equal seq number with lower IP winning.
Now if a local path already exists with the same sequence number but higher
(local-VTEP) IP it is evicted (deleted and withdrawn from the peers) and
the winning new remote path is installed in zebra. This is existing code
and handled implicitly via evpn_route_select_install.
If a local path is rxed from zebra with the same sequence as the
current remote winner it is rejected (not installed in the bgp
routing tables) and zebra is asked to re-install the older/remote winner.
This is a race condition that can only happen if bgp's add and zebra's add
cross paths. Additional handling has been added in this commit via
evpn_cleanup_local_non_best_route to take care of the race condition.
Ticket: CM-22674
Reviewed By: CCR-7937
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Problems were reported with the name of the default vrf and the
default bgp instance being different, creating confusion. This
fix changes both to "default" for consistency.
Ticket: CM-21791
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-7658
Testing: manual testing and automated tests before pushing
community_free, lcommunity_free and ecommunity_free are similar type of functions. Most of the places, these three are called together. The signature of community_free is different from other two functions. Modified the community_free API signature to align with other two functions to avoid any confusion. There is no functionality impact with this and this is just to avoid any confusion.
Testing: manual testing and show commands
Signed-off-by: Sri Mohana Singamsetty msingamsetty@vmware.com
as prefix is opaque for flowspec, and json needs to have a non empty
full of meaning value in prefix, the proposal is to encode the
displayable form of flowspec entry.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add the ability to aggregate routes to handle
extended communities. Make the actions similiar
to what we do for normal communities.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1. "show bgp ipv4 json"
- Added "network" field which displays a prefix in 'prefix/prefixlen' format.
2. "show bgp ipv6 json"
- Added "network" field which displays a prefix in 'prefix/prefixlen' format.
- JSON does not have "prefix", "prefixLen" fields which are present in IPv4
command. Added these fields as they are useful.
3. "show bgp ipv4/ipv6 neighbor <neighbor_addr> advertised-routes json"
- Added "network" field.
4. "show bgp ipv4/ipv6 summary json"
- Added "pfxSnt" for peers. This count is obtained from corresponding
update_subgroup.
5. "show bgp neighbor json"
- Added "sentPrefixCounter"
Signed-off-by: Ameya Dharkar <adharkar@vmware.org>
Do a straight conversion of `struct bgp_info` to `struct bgp_path_info`.
This commit will setup the rename of variables as well.
This is being done because `struct bgp_info` is not descriptive
of what this data actually is. It is path information for routes
that we keep to build the actual routes nexthops plus some extra
information.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp->peerhash is a secretive bit of data that we use
to quickly lookup data about peers. Unfortunately
since we had not way to look at it, we had no way
of knowing if it had gotten in or out of sync.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1. "show bgp ipv4 json"
- Corresponding CLI has "network" field which displays a prefix in
'prefix/prefixlen' format. Added this "network" field to JSON as well.
- Following fields have different names in JSON and CLI.
CLI JSON
metric med
locPrf localPref
path aspath
Added fields "metric", "locPrf" and "path" in JSON for CLI/JSON
consistency. Older JSON fields med, localPref, aspath will be
deprecated in future.
2. "show bgp ipv6 json"
- Similar changes as "show bgp ipv4 json"
- JSON does not have "prefix", "prefixLen" fields which are present in IPv4
command. Added these fields as they are useful.
3. "show bgp ipv4/ipv6 neighbor <neighbor_addr> advertised-routes json"
- Added "network" field.
- Added locPrf, path fields for CLI/JSON consistency. localPref, aspath will
be deprecated in future.
4. "show bgp ipv4/ipv6 summary json"
- Added "pfxRcd" for CLI/JSON consistency.
"prefixReceivedCount" will be deprecated in future.
- Added "pfxSnt" for peers. This count is obtalned from corresponding
update_subgroup. This needed a fix in the code where we copy fields
for a split update_subgroup from the parent update_subgrp.
New subgrp should inherit subgrp->scount(Count of advertized prefixes)
of the parent subgrp.
5. "show bgp neighbor json"
- Added "sentPrefixCounter"
6. "show bgp ipv4/ipv6 <prefix> json"
- Added "metric" field for CLI/JSON consistency.
"med" will be deprecated in future.
Signed-off-by: Ameya Dharkar <adharkar@vmware.org>
When this description code was added, it was all dead code since none of
the bools that checked if the communities were present were ever changed
from 0.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Problem reported that frr-relaod.py was not installing an aggregate
properly. Problem was actually that frr-reload.py does the command
twice, and the second time the aggregate command was entered, it would
appear in the config but the aggregate was removed from the bgp table
and not advertised to peers. Solved by noticing when an aggregate
was marked for deletion (info_invalid) and allowing the re-entry if
the old one was being removed.
Ticket: CM-22509
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
The bgp_static data is stored as a void pointer in `struct bgp_node`.
Abstract retrieval of this data and setting of this data
into functions so that in the future we can move around
what is stored in bgp_node.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_distance data is stored as a void pointer in `struct bgp_node`.
Abstract retrieval of this data and setting of this data
into functions so that in the future we can move around
what is stored in bgp_node.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The aggregate data is stored as a void pointer in `struct bgp_node`.
Abstract retrieval of this data and setting of this data
into functions so that in the future we can move around
what is stored in bgp_node.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When the origin changed we must honor and update the aggregate
to the peer. This code adds a bit of code to the bgp_aggregate_info_same
code to see if the origin has changed and to indicate that it has.
Fixes: #2993
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problem reported that some bgp and ospf json commands did not return
any json output at all if the bgp/ospf instance did not exist.
Additionally, some bgp and ospf json commands did not return any json
output if the instance existed but no neighbors were defined. This
fix makes these commands more consistent in returning empty braces for
json output and issue a message if not using json output. Additionally,
made the flag "use_json" a bool to make it consistent since previously,
it had been defined as an int, char, u_char, and bool at various places.
Ticket: CM-21040
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Coded as part of #2684 and most code written while participating at
BornHack@2018.
bgp_route.c: Changes regarding adding explanations for the IANA
well-known communities added in #2684
Signed-off-by: Christoffer <netravnen@gmail.com>
Several zlog_warns were being used to tell the end
user that bgp had detected a bug. These all look like information
added during development that can be noted as debugs or logged
as an error situation.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
A warn with a backtrace does not need another warn
to file an issue with Quagga, so just remove it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Root Cause: In the function bgp_show_table(), we are creating a
json object and a json array with the same name as “json_paths”.
First it will create a json object variable "json_paths" pointing
to the memory allocated for the json object. Then it will create
a json array for each bap node rn (if rn->info is available) with
the same name as json_paths. Because of this, json_paths which was
pointing to the memory allocated for the json object earlier, now
will be overwritten with the memory allocated for the json array.
As per the existing code, at the end of each iteration loop of bgp
node, it will deallocate the memory used by the json array and
assigned NULL to the variable json_paths. Since we don’t have the
pointer pointing to the memory allocated for json object, will be
not able to de-allocate the memory, which is a memory leak here.
Fix: Removing this json object since it is never getting used in
this function.
Testing: Reproduced the memory leak with valgrind.
With the fix, memory leak gets resolved and checked with valgrind.
Signed-off-by: Sarita Patra saritap@vmware.com
Make the wart slightly less bad... also there is still a possible write
after free here. This needs to be fixed again, properly, by some
structure changes.
Signed-off-by: David Lamparter <equinox@diac24.net>
Avoid memory leak in bgp flowspec list.
Usage of bool parameter instead of int, to handle the number of entries
PBR.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
There exists a few places where actual debugs were being
displayed as warns. Convert them over to debugs and
guard as appropriate.
Signed-off-by: Donald Sharp <sharpd@cumulsunetworks.com>
