Further refine the previous commit to store the hash value in
both the `struct community_list` as well as the `struct rmap_community`
structures. This allows us to know a priori what our hash value
is. This change cuts another couple of seconds of convergence
off to ~55 seconds and further reduces cpu load of bgp:
16 40061.706 433732 92 330102 129 1242965 RWTEX TOTAL
Down from ~43 seconds previously.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
in bgp, even if the main vrf implementation relies on tables, the fact
is some vrf implementation rely on network namespaces, and then the
table used is the default table from the network namespace. Use the
wording vrf instead of table.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit is the last missing piece to complete BGP LU support in bgpd. To this moment, bgpd (and zebra) supported auto label assignment only for prefixes leaked from VRFs to vpn and for MPLS SR prefixes. This adds auto label assignment to other routes types in bgpd. The following enhancements have been made:
* bgp_route.c:bgp_process_main_one() now sets implicit-null local_label to all local, aggregate and redistributed routes.
* bgp_route.c:bgp_process_main_one() now will request a label from the label pool for any prefix that loses the label for some reason (for example, when the static label assignment config is removed)
* bgp_label.c:bgp_reg_dereg_for_label() now requests labels from label pool for routes which have no associated label index
* zebra_mpls.c:zebra_mpls_fec_register() now expects both label and label_index from the calling function, one of which must be set to MPLS_INVALID_LABEL or MPLS_INVALID_LABEL_INDEX, based on this it will decide how to register the provided FEC.
Signed-off-by: Anton Degtyarev <anton@cumulusnetworks.com>
Default vrf name has been changed in show route. Because the default vrf
name can be configured in zebra, the default vrf name in bgp is changed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
if default vrf is not Default, then nexthop vrf name returned may be
"Default", which is not the correct name of default vrf. change it
accordingly.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add some code that will reject local mac's from
being installed and add some code that will cause
a rescan when we have a local mac change.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com.
When you have configured soft reconfiguration inbound
for evpn allow it to notice and send in the evpn data
as appropriate.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The adj_out data structure is a linked list of adjacencies
1 per update group. In a large scale env where we are
not using peer groups, this list lookup starts to become
rather costly. Convert to a better data structure for this.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1. "show bgp ipv4/ipv6 [json]"
2. "show bgp ipv4/ipv6 neighbor <peer> routes [json]"
3. "show bgp ipv4/ipv6 neighbors <peer> advertised-routes [json]"
In the above show commands, when a BGP path is displayed, we do not display the
local preference if it is EBGP route. Route calculation assumes the default
local preference. But, we can change the default local preference using
configuration in FRR. In this case, user should know the default local
preference value that is being used in the route calculation. Thus, adding a
new field 'default local preferece' in the show commands where a BGP path is
displayed.
When a BGP path is displayed in the above show commands, as-path does not
include the local AS. So, user has to execute another show command to display
the local-AS. To avoid this, adding a new field local-AS to above show commands.
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
The bgp_distance_set_node_info and bgp_distance_get_node_info
function names were slightly backwards lets fix them up
to bgp_node_get_bgp_distance_info and bgp_node_set_bgp_distance_info
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_static_set_node_info and bgp_static_get_node_info
function names were slightly backwards rename to
bgp_node_get_bgp_static_info and bgp_node_set_bgp_static_info
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_aggregate_set_node_info and bgp_aggregate_get_node_info
functions names were slightly backwards, rename to
bgp_node_get_bgp_aggregate_info and bgp_node_set_bgp_aggregate_info
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_info 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 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>
Classful networking has been obsolete for ages and there is currently an
inconsistency between `show ip route` and `show bgp`, where the first
one always displays the CIDR mask while the second one hides classful
network masks.
This commit adjusts the behavior of `show bgp` to always show the CIDR
mask for a route, even when it is classful.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
There is no need to check for failure of a ALLOC call
as that any failure to do so will result in a assert
happening. So we can safely remove all of this code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Avoid displaying default configured local preference as
part of bgp route's detail output.
Local preference is for iBGP learnt route's. The value could be
default (100) or configured value (via routemap or local pref config cmd).
show bgp afi safi (brief output) does not display,
if the local pref attribute is not set.
Similarly, show bgp afi safi detail route output should display
if the the attribute is set, and should not display configured value.
This way both output would be consistent.
The configured local preference can be seen via running-config.
Ticket:CM-12769
Reviewed By:
Testing Done:
eBGP output:
show bgp ipv4 45.0.3.0/24
BGP routing table entry for 45.0.3.0/24
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
MSP1(uplink-1) MSP2(uplink-2)
Local
0.0.0.0 from 0.0.0.0 (27.0.0.9)
Origin incomplete, metric 0, weight 32768, valid,sourced, bestpath-from-AS Local, best
AddPath ID: RX 0, TX 7
Last update: Thu Jul 26 02:10:02 2018
iBGP output:
show bgp ipv4 unicast 6.0.0.16/32
BGP routing table entry for 6.0.0.16/32
Paths: (1 available, best #1, table default)
Not advertised to any peer
Local
6.0.0.16 (metric 20) from tor-12(6.0.0.16) (6.0.0.16)
Origin incomplete, metric 0, localpref 100, valid, internal, bestpath-from-AS Local, best
AddPath ID: RX 0, TX 13
Last update: Thu Jul 26 05:26:18 2018
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
The bi->net pointer that is being unlocked had a commit
that removed the `bi->net = NULL;` recently. This code
was preventing a use after free crash being experienced
in other code paths. While commit 37e679629f was fixing
a different code path crash.
Make the parent->net pointer aware it may be locked/freed
from multiple places and to not NULL the pointer to it
unless we have actually freed the data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There is a default BGP VPN and BGP VRF instance in L3VPN configuration.
The routes are imported and exported between BGP VPN and BGP VRF.
Suppose there is one route in BGP VRF and exported to BGP VPN.
In BGP VPN there is bgp_info struct with bgp_info_extra struct has parent pointer pointing to the bgp_info of BGP VRF.
We take the lock for bgp_node and bgp_info of BGP VRF in the context of BGP VPN.
bgp_info has a back pointer to bgp_node via net.
Now when we have done "no rd vpn" in BGP VRF then in bgp_info_extra_free we have to free the parent resources.
In this context only unlocking is required. It should not set the BGP VRF (bgp_info->net) to NULL.
Signed-off-by: vishaldhingra vdhingra@vmware.com
because the IP destination criterium may match several entries, the show
command may return more than one entry.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Because one flowspec entry can create 1-N bgp pbr entries, the list is
now updated and visible. Also, because the bgp_extra structure is used,
this list is flushed when the bgp_extra structure is deleted.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit removes various parts of the bgpd implementation code which
are unused/useless, e.g. unused functions, unused variable
initializations, unused structs, ...
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
The warning given by PVS-Studio is related to per-element overflow (there is
no real overflow, because of how elements are mapped in the union). This
same warning is typically reported by Coverity, too.
Signed-off-by: F. Aragon <paco@voltanet.io>
In order to make EVPN behavior work without special casing
the code, bring the evpn commands under HAVE_CUMULUS into
the fold.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This commit fixes the issue mentioned in #2419, which is caused by a
double-free. The problem of the current implementation is that
*bgp_input_modifier* already frees the passed attributes under specific
circumstances, which can then lead to a double-free as *bgp_attr_undup*
does not check if the attributes are set to NULL.
As it is not transparent to the function caller if the attributes get
freed or not and the similar function *bgp_output_modifier* also does
not flush the passed attributes, the line has been removed altogether.
All callers of *bgp_input_modifier* already deal by themself with
freeing/flushing/unduping BGP attributes, so it is safe to remove.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
When evpn configured wiht route-map with vni which is not
configured. Upon receiving evpn routes (i.e Type-2, Type-3),
route-map match will be triggered. Since there is no l2vni
exists in db, some of the member fields in bgp_info (i.e.
dummy_info_extra) are passed uninitialized to evpn filter match cb.
This results in inaccessible memory causes crash.
Fix is to memset the bgp_info prior to passing to evpn filter cb.
In evpn vni filter cb, ensure to have NULL check for member filed
of the bgp_info.
memset bgp_info at few places where it is passed to route_match.
Ticket:CM-21335
Reviewed By:
Testing Done:
Configure route-map with not configured l2vni
Simulate to learn l2vpn type-2, 3 route
Restart frr.service with below config
address-family l2vpn evpn
neighbor fear route-map EVPN_VNI out
route-map EVPN_VNI deny 10
match evpn vni 140010
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
The bgp_info_extra_free code was the correct place to free
up data associated with the bgp_info pointer when we are
deleting the bgp_info node.
Additionally, if we have a parent pointer, we may not have a net
pointer. So make sure we do.
Finally clean up the bgp_info_extra_free code so it is a bit
easier to read. Use variables instead of multiple level
of casting.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
With a new version of clang 6.0, the compiler is detecting more
issues where we may be possibly be truncating the output string.
Fix by increasing the size of the output string to make the compiler
happy.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
These two functions are functionally the same, except
bgp_aggregate_route is meant to handle the addition and
deletion of routes, while aggregate_add is meant for all of them.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The aggregated route was being sent in updates to peers every
time a route changed that we were aggregating. Modify
the code such that we only send aggregated route updates
if we actually have something different to tell the peer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The function bgp_aggregate_delete function was forward
declared and not static. Move it so we can clean that
up.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This is a transitional commit, to get us where we want to go.
Seperate out the install/removal of the aggregate route from
the bgp_aggregate_delete and bgp_aggregate_route functions.
In the future we'll write a bit of code to determine if the
aggregate add has actually changed any information we care
about.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We were allowing useless aggregation commands (/32 and /128).
These were being silently accepted and nvgenned and then
just ignored.
When a user enters a value that should be rejected tell
them and reject.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Make bgp_aggregate_route easier to read. It was indented so many
levels that it was extremely hard to figure out what it was doing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The #define AGGREGATE_NEXTHOP_CHECK has not been used
for a very very long time. Since this is effectively
dead code, let's remove it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The safi passed in to short-circuit the aggregate lookup
adds code complexity and little speed improvements for
the case where we actually may have aggregates configured!
Since bgp_table_top_nolock() actually tells us if there
are any aggregates installed and safely returns if there
is nothing to do, trust it. As that we know for those
safi's were we don't want to have, we dissallow the
creation via the cli anyways.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_aggregate_set/unset functions are only called from the cli
invocations which control what AFI/SAFI we are looking at. Tests
for safi are unimportant.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There exists cases where we will attempt to hard delete
the bgp instance( say a `no router bgp` is issued )
when we have vrf route leaking. If we do have this
lock the bgp instance of the originator and do not
let it be deleted out from under us until we are
finished processing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Issue Found by Coverity Scan. When we call peer_clear we
are checking the return code in every other call. Add
a bit of extra code to notice the failure and note it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Added improved error message text to other places that could also
encounter the same condition. In testing found that in certain
case, duplicate error messages were previously issued. This fix
also removes the duplicates.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
There exists code paths where the rn was being used after free.
This eliminates these code paths.
Fixes: CM-21019
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This commit tries to adapt a similar codeflow within the `show bgp [afi]
[safi] neighbor <neighbor> advertised-routes` command compared to its
`received-routes` and `filtered-routes` opponents. Some branching code
has been restructured to achieve this.
Additionally, this commit fixes a memory leak within `received-routes`
(and `filtered-routes`, although the issue has been present before the
previous commit!) where the previous implementation forgot to
deduplicate the BGP attributes.
When a user called `<...> received-routes route-map <RM-TEST>` and that
routemap changed any AS path or community parameters, the duplicated
memory for these parameters was never freed. This has been fixed by
ensuring to call `bgp_attr_undup()` accordingly.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
This commit changes the behavior of `show bgp [afi] [safi] neighbor
<neighbor> received-routes [json]` to return all received prefixes
instead of filtering rejected/denied prefixes.
Compared to Cisco and Juniper products, this is the usual way how this
command is supposed to work, as `show bgp [afi] [safi] neighbor
<neighbor> routes` will already return all accepted prefixes.
Additionally, the new command `show bgp [afi] [safi] neighbor <neighbor>
filtered-routes` has been added, which returns a list of all prefixes
that got filtered away, so it can be roughly described as a subset of
"received prefixes - accepted prefixes".
As the already available `filtered_count` variable inside
`show_adj_route` has not been used before, the last output line
summarizing the amount of prefixes found was extended to also mention
the amount of filtered prefixes if present.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
The current implementation of building JSON output is greatly different
for large communities compared to standard communities. This is mainly
noticeable by the missing 'list' attribute, which usually offers an
array of all communities present on a BGP route.
This commit adds the missing functionality of properly returning a
'list' attribute in JSON output and also tries a similar approach like
the standard communities are using to implement this feature.
Additionally, the 'format' specifier has been completely removed from
large communities string/JSON rendering, as the official RFC8092 specifies that
there is only one canonical representation:
> The canonical representation of BGP Large Communities is three
> separate unsigned integers in decimal notation in the following
> order: Global Administrator, Local Data 1, Local Data 2. Numbers
> MUST NOT contain leading zeros; a zero value MUST be represented with
> a single zero. Each number is separated from the next by a single
> colon. For example: 64496:4294967295:2, 64496:0:0.
As the 'format' specifier has not been used/checked and only one
canonical representation exists per today, there was no reason to keep
the 'format' parameter in the function signature.
Last but not least, the struct attribute 'community_entry.config' is no
longer being used for large communities and instead 'lcommunity_str' is
being called to maintain a similar approach to standard communities.
As a side effect, this also fixed a memory leak inside 'community_entry_free'
which did not free the allocated memory for the 'config' attribute when
dealing with a large community.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
Imported routes in a VRF routing table have a reference to their parent
route entry which resides in the EVPN or IPVPN routing table. Ensure that
this reference uses appropriate locking so that the parent entry doesn't
get freed prematurely.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit 13cb6b22ba9d558b1b4a1e8752f63f13242462a7)
Conflicts:
bgpd/bgp_mplsvpn.c
Ticket: CM-20471
Testing Done:
a) Ran vrf_route_leak tests without fix and hit crash, ran twice with fix
and did not see the crash.
b) Ran evpn-smoke and ensured there were no new failures.
In the FRR implementation of EVPN,
eBGP leaf-spine peering for EVPN is fully supported by allowing
the next hop to be propagated and not rewritten at each hop.
There are other changes also related to route import to facilitate this.
However, propagating the next hop is not correct in some cases.
Specifically, if the DC is comprised of multiple PODs
with distinct intra-POD and inter-POD VxLAN tunnels,
EVPN routes received from an adjacent POD by a border/exit leaf
must be propagated into the local POD with the next hop rewritten (to self).
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
We install type-5 routes as ipv4/ipv6 unicast routes in the vrf table.
along with these routes, we also install the RMAC
and the nexthop Neigh entries.
There might be scenarios were the bestpath has changed and
we are now pointing to a new nexthop with a different RMAC.
As per BGP logic, we just send an update for the route and the nexthop
is replaced. However, this causes problem because the RMAC and neigh entry
corresponding to the previous nexthop are still lingering in the system.
We need to clear those entries for proper functoning.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
A newly added ipv4/ipv6 route in BGP RIB might be advertised as type-5 EVPN route.
The user might have configured a route-map for advertising type-5 routes.
We need to apply this route-map while advertising ipv4/ipv6 routes as type-5.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
EVPN prefix depends on the EVPN route type.
Currently, in FRR we have a prefix_evpn/evpn_addr which relates to a evpn prefix.
We need to convert this to encompass an union of various EVPN route-types.
This diff handles the necessary code changes to adopt the new struct evpn_addr.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Add a policy-route API to handle flowspec entry.
The entry is analysed, converted, and
selected if it is possible to inject the flowspec entry in local policy
routing entries.
redirect IP and redirect VRF actions are handled. The former extracts
the IPv4 address to redirect traffic to. The latter calculates the
matching VRF to redirect traffic to.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
As part of recent vpn-vrf leaking changes, it is now possible for a
route to refer to a nexthop in a different vrf. There is also a new
route flag that means "when announcing this route, indicate myself
as the next-hop."
route_vty_out(): nexthops are appended with:
"@VRFID" (where VRFID is the numerical vrf id) when different from
the route's vrf;
"<" when the route's BGP_INFO_ANNC_NH_SELF is set
This change also shows the route table's vrf id in the table header.
route_vty_out_detail(): show nexthop's vrf and announce-nh-self flag if
appropriate.
Both functions are also augmented to add json elements nhVrfId, nhVrfName,
and announceNexthopSelf as appropriate.
The intent of these changes is to make it easier to understand/debug
the relationship between a route and its nexthops.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
The vrf 2 vrf route leaking auto-derives RD and RT and
installs the routes into the appropriate vpn table.
These routes when a operator configured ipv[4|6] vpn
neighbors were showing up off box. The RD and RT
values choosen are localy significant but globaly
useless and may cause confusion.
Put a special bit of code in to notice that we
should not be advertising these routes off box.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Here we have a block conditional on the nullity of a pointer, followed
by a dereferennce of the same pointer. Move the deref into the
conditional block.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Most presumably, the nexthop IP is present, only when ECOM redirect IP
is present. The nexthop is displayed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Routes that have labels must be sent via a nexthop that also has labels.
This change notes whether any path in a nexthop update from zebra contains
labels. If so, then the nexthop is valid for routes that have labels.
If a nexthop update has no labeled paths, then any labeled routes
referencing the nexthop are marked not valid.
Add a route flag BGP_INFO_ANNC_NH_SELF that means "advertise myself
as nexthop when announcing" so that we can track our notion of the
nexthop without revealing it to peers.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
This command gives detail about a FS entry which contains an IP that
matches one of the rules of the FS entry. The output is the same output
as when one does show bgp ipv4 flowspec detail
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The json format is returd when requested from the two commands:
- show bgp ipv4 flowspec
- show bgp ipv4 flowspec detail
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The show bgp ipv4 flowspec routine is made available, displays the
flowspec rules contained in the BGP FIB database, as well as the actions
to be done on those rules. Two routines are available:
show bgp ipv4 flowspec
show bgp ipv4 flowspec detail
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Flowspec entries do not need aggregation feature.
Actually, all flowspec entries are unique.
So, some check is done against aggregate functionalities in the code.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Ensure that only EVPN routes are flagged as such when installing into or
withdrawing from zebra, the earlier check broke L3VPN or VRF route-leaked
routes. Also, fix an incorrect check related to imported routes in path
selection.
Updates: bgpd: Use BGP_ROUTE_IMPORTED for EVPN [vivek]
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
The following types are nonstandard:
- u_char
- u_short
- u_int
- u_long
- u_int8_t
- u_int16_t
- u_int32_t
Replace them with the C99 standard types:
- uint8_t
- unsigned short
- unsigned int
- unsigned long
- uint8_t
- uint16_t
- uint32_t
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
When uninstalling routes from zebra, ensure that the BGP instance for
which processing is being done is used to derive the VRF. It is incorrect
to derive the VRF from the peer when dealing with scenarios like VRF route
leaking, EVPN symmetric/external routing etc., where the peer which sourced
the route could belong to a different VRF.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Ticket: CM-18413
Reviewed By: CCR-6778
Testing Done: Manual testing of BGP route withdraw/delete, bgp-min
When a peer is removed the routes are withdrawn via bgp_process_main_one
As such we need to put a bit of code in to handle this situation
for the vpn/vrf route leaking code.
I think this code path is also called for when a vrf's route is
changed and I believe we will end up putting a bit more code
here to handle the nexthop changes.
I've also started trying to document the bgp_process_main_one
function a bit better.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Set EVPN routes imported into a VRF to (sub)type BGP_ROUTE_IMPORTED and
use this for passing appropriate information to zebra. This is needed
because relying on the Router MAC for this purpose was incorrect and
impacted routing to/from external destinations, particularly for IPv6.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
In bgp_update_receive the first thing we do is establish
that the peer->status is Established. We then do a bunch
of work and call bgp_nlri_parse where we break out for
each address family. Each AFI is then checking for
being peer->status is Established again. There is no
point in checking this again.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
- add "debug bgp vpn label" CLI
- improved debug messages for "debug bgp bestpath"
- send vrf label to zebra after zebra informs bgpd of vrf_id
- withdraw vrf_label from zebra if zebra informs bgpd that vrf_id is disabled
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
Received PMSI tunnel attributes (in EVPN type-3 route) were not recognized.
Parse them and display the tunnel type when looking at routes. Note that
the only tunnel type currently supported is ingress replication (IR). A
warning message will be logged if the received tunnel type is something
else, but the attribute is otherwise ignored.
Updates: a21bd7a (bgpd: add PMSI_TUNNEL_ATTRIBUTE to EVPN IMET routes)
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Type-5 routes can be useful in multiple scenarios such as advertise-subnet,
default-originate etc. Currently, the code has a restriction that to allow
advertising type-5 routes, user has to first enable advertise ipvX command.
This restriction is not necessary and should be removed.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
EVPN type-2 and type-5 routes received with a L3 VNI and corresponding RTs
are installed into the appropriate BGP RIB. Ensure that these routes are not
re-injected back into EVPN as type-5 routes when type-5 advertisement is
enabled; only regular IPv4 routes (and IPv6 routes in future) in the RIB
should be injected into EVPN.
As a benefit of this change, no longer restrict that EVPN type-5 routes
should be non-host routes - i.e., allow /32 IPv4 routes (and /128 IPv6
routes in future).
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Ticket: CM-19456
Reviewed By: CCR-7117
Testing Done:
1. Manual replication of problem and verification of fix
2. evpn-min
Turns out we had 3 different ways to define labels
all of them overlapping with the same meanings.
Consolidate to 1. This one choosen is consistent
naming wise with what the *bsd and linux kernels
use.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When an IPv4 or IPv6 unicast route is injected into EVPN as a type-5 route
(upon user configuration), ensure that the source route (best path)'s path
attributes are used to build the EVPN type-5 route. This will result in
correct AS_PATH and ORIGIN attributes for the type-5 route so that it doesn't
appear that all type-5 routes are locally sourced. This is necessary to
ensure that external paths (IPv4 or IPv6 from EBGP peer) are preferred over
internal EVPN paths, if both exist.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-19051
Reviewed By: CCR-7009
Testing Done: Verify failed scenario
In EVPN symmetric routing, not all subnets are presents everywhere.
We have multiple scenarios where a host might not get learned locally.
1. GARP miss
2. SVI down/up
3. Silent host
We need a mechanism to resolve such hosts. In order to achieve this,
we will be advertising a subnet route from a box and that box will help
in resolving the ARP to such hosts.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
When doing symmetric routing,
EVPN type-2 (MACIP) routes need to be advertised with two labels (VNIs)
the first being the L2 VNI (identifying the VLAN) and
the second being the L3 VNI (identifying the VRF).
The receive processing needs to handle one or two labels too.
Ticket: CM-18489
Review: CCR-6949
Testing: manual and bgp/evpn/mpls smoke
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
-Werror=sign-compare is failing with signed/unsigned usage
in the conditional expression.
Fixes: #1593
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problems reported with inconsistent use of parameters for bgp network
statements. Converted 12 DEFUNs to 2 DEFPY statements, making the
parameter use consistent with the exception of keeping the "backdoor"
keywork ipv4 only. Also verified that if a route-map or label-index
is specified in the "no" case it matches what had been previously
defined. Manual testing looks good and bgp-smoke will be performed
before pushing.
Ticket: CM-16860
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-7056
The json code was freeing json_paths and then
turning around and free'ing it again. Newer
versions of json-c have started to assert
this bad behavior.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When bgp has a metric butt-load of routes w/ ecmp, this command
can take an inordinate amount of time to run and complete via
vtysh.
Converting the bgp route output in this case back to not
using the json pretty-print drops ~2 minutes of runtime
off.
It is assumed that if users would like pretty output they
can run it through an appropriate tool via a pipe command.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The prefix_rd2str uses a buffer size of RD_ADDRSTRLEN.
Modify the code to consistently use this for all of BGP.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ignoring the return from argv_find_and_parse_afi
makes the SA system assume that you could pass a AFI_MAX
value to bgp_show_route. Which in turn would cause
an array out of bounds read.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
So we have the ability to apply speculative route-maps to
neighbor display to see what the changes would look like
via some show commands. When we do this we make a
shallow copy of the attr data structure and then pass
it around for applying the routemap. After we've applied
this route-map and displayed it we really need to clean
up memory that the route-map application applied.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are applying an experimental route-map type
to a peer( as part of a show command ) save and
restore the peer's ->rmap_type.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we display the advertised-routes and we don't have a route-map
to apply do not re-apply the route-map. This does two things:
1) Fixes a display issue with the show command.
2) More importantly stops leaking memory like a sieve for when
you have a full bgp table.
Fixes: #1345
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This commit fixes a bug where json output would display
',,,,,,,' because we were deciding to not display information
about some routes due to a selection criteria.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Building a communities json object every time is
both expensive and memory wasteful. Modify
code to only build the json object when needed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The creation of the json object for the aspath
is both memory intensive and expensive to
create. Only create the json object when
it is needed and stash it for further usage
at that point.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When BGP is being redistributed prefixes, allow it to
understand the nexthop type.
This fixes the issue where a blackhole route was being interpreted
to having a nexthop of 1.0.0.0( ruh-roh!!! ). This broke
downstream neighbors as that they would receive a 1.0.0.0 nexthop,
which is bad, very very bad.
This commit sets us up for the future where we can match
a route-map against a nexthop type. In that bgp is
now at least nominally paying attention to the type.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ignore the return value of some functions in the places we know they
can't fail, and other small fixes.
Regarding the change in bgpd/rfapi/rfapi_rib.c, asserting that
rfapiRaddr2Qprefix() didn't fail is the common idiom inside the rfapi
code.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
These commands don't belong in the BGP_IPV6L_NODE node anymore. A similar
change was done for BGP_IPV4L_NODE in commit 9bedbb1e5.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The json option for displaying a bgp table
with route Distinguishers in it was not properly
working. This code cleans this issue up.
Additionally attempt to make the code a bit
easier to read and handle.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Perf results at scale( >1k peers) showed a non-trivial
amount of time spent in bgp_multiaccess_check_v4. Upon
function examination we are looking up the nexthops
connected node in each call as well as having to unlock
it after each iteration. Rewrite to lookup the nexthop
node once.
This should reduce the node lookup by aproximately 1/2
which should yield some performance results. There are
probably better things to do here but would require
deeper thought.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This fixes the broken indentation of several foreach loops throughout
the code.
From clang's documentation[1]:
ForEachMacros: A vector of macros that should be interpreted as foreach
loops instead of as function calls.
[1] http://clang.llvm.org/docs/ClangFormatStyleOptions.html
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
VARIABLE tokens must be all uppercase, this allows us to support WORD
tokens that begin with an uppercase letter. The "Null0" keyword is an
example of where this is needed.
The only VARIABLE we had that wasn't already all uppercase was
ASN:nn_or_IP-address:nn
bgp_route.c:6393:7: error: ‘len’ may be used uninitialized in this function
gcc 5.4.0 isn't intelligent enough to notice it's set on all paths.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Some of this was so egregiously stupid, I couldn't look at it without
gouging my eyes out...
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
afi_header_vty_out() is easily replaced with vty_frame(), which means we
can drop a whole batch of "int *write" args as well as the entirety of
bgp_config_write_family_header().
=> AFI/SAFI config writing is now a lot simpler.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Some differences compared to the old API:
* Now the redistributed routes are sent using address-family
independent messages (ZEBRA_REDISTRIBUTE_ROUTE_ADD and
ZEBRA_REDISTRIBUTE_ROUTE_DEL). This allows us to unify the ipv4/ipv6
zclient callbacks in the client daemons and thus remove a lot of
duplicate code;
* Now zebra sends all nexthops of the redistributed routes to the client
daemons, not only the first one. This shouldn't have any noticeable
performance implications and will allow us to remove an ugly exception
we had for ldpd (which needs to know all nexthops of the redistributed
routes). The other client daemons can simply ignore the nexthops if
they want or consult just the first one (e.g. ospfd/ospf6d/ripd/ripngd).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
There are several code paths that dump nodes to the queue for route
processing in a loop. This patch tries to reduce memory allocations/freeing
(work item, list node) and thread scheduling overhead by batching the nodes
in a simple queue list.
In the past when route processing wasn't event driven (bgp_scan()), this used
to have a noticeable impact in table loading, convergence time and memory heap
fragmentation due to reduced alloc's/free's.
Signed-off-by: Jorge Boncompte <jbonor@gmail.com>
When the MAC changes for a local neighbor, ensure that the neighbor data
structure as well as the link between the neighbor and MAC data structures
is updated correctly.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-17565
Reviewed By: CCR-6605
Testing Done: Manual, evpn-smoke
Ensure that the registration for the "in" label for a unicast prefix
is done only in the default instance. The zebra label manager as well
as other code in BGP only has support for assigning labels in the
default instance.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-17110
Reviewed By: CCR-6588
Testing Done: Manual tests, mpls
There are two parts to this commit:
1. create a database of self tunnel-ip for used in martian nexthop check
In a CLAG setup, the tunnel-ip (VNI UP) notification comes before the clag-anycast-ip comes up in the system.
This was causing our self next hop check to fail and we were instaling routes with martian nexthop in zebra.
We need to keep this info in a seperate database for all local tunnel-ip.
This database will be used in parallel with the self next hop database to martian nexthop checks.
2. When a local VNI comes up, update the tunnel-ip database and filter routes in the RD table if necessary
In case of EVPN we might receive routes from clag peer before the clag-anycast ip and VNI is up on the system.
We will store the routes in the RD table for later processing.
When VNI comes UP, we loop thorugh all the routes and install them in zebra if required.
However, we were missing the martian nexthop check in this code path.
From now onwards, when a VNI comes UP,
we will first update the tunnel-ip database
We then loop through all the routes in RD table and apply martian next hop filter if required.
Things not covered in this commit but are required:
This processing is needed in general when an address becomes a connected address.
We need to loop through all the routes in BGP and apply martian nexthop filter if necessary.
This will be taken care in a seperate bug
Ticket:CM-17271/CM-16911
Reviewed By: ccr-6542
Testing Done: Manual
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
When issuing a 'show ip bgp' command and the nexthop is
a interface, if the interface name was greater than 7 characters
we would arbitrarily start a new-line and setup the next
line to start at the wrong spot.
Modify the interface field to allow 16 characters than 7( to
match v6 display ), and if the interface name is greater than
16 characters properly setup the next line for display
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1. provision to add match clause with a vni under route-map
Ticket: CM-16349
Review: CCR-6190
Unit-test: Manual (logs attached to ticket)
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
1. Added support to create mac filters
2. Enabled route-map commands for EVPN address family
3. Provision to add mac filters under match clause in route-maps
Ticket: CM-16349
Review: CCR-6190
Unit-test: Manual (logs attached to ticket)
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
If you are doing multipath in a VRF and bounce one of the multipaths for
a prefix, bgp is not updating the zebra entry for that prefix with the
new multipaths. We start with:
cel-redxp-10# show bgp vrf RED ipv4 unicast 6.0.0.16/32
BGP routing table entry for 6.0.0.16/32
Paths: (4 available, best #4, table RED)
Advertised to non peer-group peers:
spine-1(swp1) spine-2(swp2) spine-3(swp3) spine-4(swp4)
104 65104 65002
fe80::202:ff:fe00:2d from spine-4(swp4) (6.0.0.12)
(fe80::202:ff:fe00:2d) (used)
Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 104
AddPath ID: RX 0, TX 21
Last update: Tue Aug 1 18:28:33 2017
102 65104 65002
fe80::202:ff:fe00:25 from spine-2(swp2) (6.0.0.10)
(fe80::202:ff:fe00:25) (used)
Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 102
AddPath ID: RX 0, TX 20
Last update: Tue Aug 1 18:28:33 2017
103 65104 65002
fe80::202:ff:fe00:29 from spine-3(swp3) (6.0.0.11)
(fe80::202:ff:fe00:29) (used)
Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 103
AddPath ID: RX 0, TX 17
Last update: Tue Aug 1 18:28:33 2017
101 65104 65002
fe80::202:ff:fe00:21 from spine-1(swp1) (6.0.0.9)
(fe80::202:ff:fe00:21) (used)
Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 101, best
AddPath ID: RX 0, TX 8
Last update: Tue Aug 1 18:28:33 2017
cel-redxp-10#
cel-redxp-10# show ip route vrf RED 6.0.0.16/32
Routing entry for 6.0.0.16/32
Known via "bgp", distance 20, metric 0, vrf RED, best
Last update 00:00:25 ago
* fe80::202:ff:fe00:21, via swp1
* fe80::202:ff:fe00:25, via swp2
* fe80::202:ff:fe00:29, via swp3
* fe80::202:ff:fe00:2d, via swp4
cel-redxp-10#
And then on spine-1 we bounce all peers
spine-1# clear ip bgp *
spine-1#
On the leaf (cel-redxp-10) we remove the route from spine-1
cel-redxp-10# show ip route vrf RED 6.0.0.16/32
Routing entry for 6.0.0.16/32
Known via "bgp", distance 20, metric 0, vrf RED, best
Last update 00:00:01 ago
* fe80::202:ff:fe00:25, via swp2
* fe80::202:ff:fe00:29, via swp3
* fe80::202:ff:fe00:2d, via swp4
cel-redxp-10#
So far so good. The problem is when the session to spine-1 comes back up
bgp will mark the flag from spine-1 as `multipath` but does not update
zebra. We end up in a state where BGP has 4 paths flags as multipath but
only 3 paths are in the RIB.
This reverts commit c14777c6bf.
clang 5 is not widely available enough for people to indent with. This
is particularly problematic when rebasing/adjusting branches.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The label initializer & nhrpd variable are just to shut up GCC 7,
the other two are actual bugs.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
This allows frr-reload.py (or anything else that scripts via vtysh)
to know if the vtysh command worked or hit an error.
Most of the attributes in 'struct attr_extra' allow for
the more interesting cases of using bgp. The extra
overhead of managing it will induce errors as we add
more attributes and the extra memory overhead is
negligible on anything but full bgp feeds.
Additionally this greatly simplifies the code for
the handling of data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
bgpd: Fix missing label set
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Core EVPN route handling functionality. This includes support for the
following:
- interface with zebra to learn about local VNIs and MACIPs as well as
to install remote VTEPs (per VNI) and remote MACIPs
- create/update/delete EVPN type-2 and type-3 routes
- attribute creation, route selection and install
- route handling per VNI and for the global routing table
- parsing of received EVPN routes and handling by route type
- encoding attributes for EVPN routes and EVPN prefix creation (for
Updates)
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Ensure that the AFI/SAFI is relevant to the FIB before attempting to install
or remove the route from zebra.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ensure that the check for martian next hop is correct, including for MP
nexthops, if IPv4.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
labeled-unicast routes are installed in the unicast table, to make
troubleshooting easier we need "show bgp ipv4 labeled-unicast x.x.x.x"
to show the x.x.x.x route in the unicast table.
* Pass ->text to functions that now do full string matching
* Remove cases for l2vpn and evpn where they cannot occur
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
- All ipv4 labeled-unicast routes are now installed in the ipv4 unicast
table. This allows us to do things like take routes from an ipv4
unicast peer, allocate a label for them and TX them to a ipv4
labeled-unicast peer. We can do the opposite where we take routes from
a labeled-unicast peer, remove the label and advertise them to an ipv4
unicast peer.
- Multipath over a labeled route and non-labeled route is not allowed.
- You cannot activate a peer for both 'ipv4 unicast' and 'ipv4
labeled-unicast'
- The 'tag' variable was overloaded for zebra's route tag feature as
well as the mpls label. I added a 'mpls_label_t mpls' variable to
avoid this. This is much cleaner but resulted in touching a lot of
code.
Based on suggestions made in the FRR technical meeting, making the
label-index range 2^20-16 for the max label size minus the reserved
labels.
Ticket: CM-16513
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Added the ability to set the label-index value based on criteria other
than the network statement. Manual testing looks good and added to the
ticket.
Ticket: CM-16513
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-6339
Problem reported with the inability to define "network x❌x::/64 label-index" to
the config. Found that the install_element was pointing to the wrong node.
Ticket: CM-16615
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Problem seen in testing import-check using labeled-unicast address-family. When
transitioning from "no bgp network import-check" to "bgp network import-check",
previously installed networks were not removed. This fix resolves this.
Ticket: CM-16512
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Modify EVPN prefix to use the generic IP address structure. Add support
for EVPN type-2 and type-3 prefix dump. Fix references to modified fields
as needed.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Static encap routes don't have an MPLS label. Also, use %u instead of
%d to print the label.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The FSF's address changed, and we had a mixture of comment styles for
the GPL file header. (The style with * at the beginning won out with
580 to 141 in existing files.)
Note: I've intentionally left intact other "variations" of the copyright
header, e.g. whether it says "Zebra", "Quagga", "FRR", or nothing.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
These commands were causing bgpd to crash if a static VPN route was
configured.
While here, fix a bug in bgp_static_add() and bgp_static_delete().
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Pass pointer to pointer instead of assigning by return value. See
previous commit message.
To ensure that the behavior stays functionally correct, any assignments
with the result of a thread_add* function have been transformed to set
the pointer to null before passing it. These can be removed wherever the
pointer is known to already be null.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
The way thread.c is written, a caller who wishes to be able to cancel a
thread or avoid scheduling it twice must keep a reference to the thread.
Typically this is done with a long lived pointer whose value is checked
for null in order to know if the thread is currently scheduled. The
check-and-schedule idiom is so common that several wrapper macros in
thread.h existed solely to provide it.
This patch removes those macros and adds a new parameter to all
thread_add_* functions which is a pointer to the struct thread * to
store the result of a scheduling call. If the value passed is non-null,
the thread will only be scheduled if the value is null. This helps with
consistency.
A Coccinelle spatch has been used to transform code of the form:
if (t == NULL)
t = thread_add_* (...)
to the form
thread_add_* (..., &t)
The THREAD_ON macros have also been transformed to the underlying
thread.c calls.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Crash uncovered when workqueue item was pulled with safi set to 7
(SAFI_LABELED_UNICAST) without labled-unicast being configured.
Also fixed minor issue removing aggregate-address command due to bad
index.
Ticket: CM-16169
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
If you specified A.B.C.D, the code would still try to
read A.B.C.D/M and not find it and pass in a NULL pointer
which crashed the code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
The initial implementation was against draft-keyupate-idr-bgp-prefix-sid-02
This updates our label-index implementation up to draft-ietf-idr-bgp-prefix-sid-05
- changed BGP_ATTR_LABEL_INDEX to BGP_ATTR_PREFIX_SID
- since there are multiple TLVs in BGP_ATTR_PREFIX_SID you can no longer
rely on that flag to know if there is a label-index for the path. I
changed bgp_attr_extra_new() to init the label_index to
BGP_INVALID_LABEL_INDEX
- put some placeholder code in for the other two TLVs (IPv6 and
Originator SRGB)
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
- cleaned up the "show bgp ipv4 labeled-unicast x.x.x.x" output
- fixed some json keys to use camelCase
- bgp_attr_label_index() was clearing BGP_ATTR_LABEL_INDEX because it
was comparing mp_update->afi against SAFI_LABELED_UNICAST instead of
mp_update->safi
- added BGP_ATTR_LABEL_INDEX to attr_str
1) Some commands were installed in the wrong node
2) Fix output to show labeled information to correctly display
3) Whitespace issue in route-map command
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* Fix a segfault when the "show bgp large-community" command is given
without any optional large communities;
* Fix parsing of optional large communities. Without this fix a
"Large-community malformed" error is shown even for valid large
communities.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Implement BGP Prefix-SID IETF draft to be able to signal a labeled-unicast
prefix with a label index (segment ID). This makes it easier to deploy
global MPLS labels with BGP, even without other aspects of Segment Routing
implemented.
This patch implements the handling of the BGP-Prefix-SID Label Index
attribute. When received from a peer and the index is acceptable, the local
label is picked up from the SRGB and is programmed as the incoming label as
well as advertised to peers. If the index is not acceptable, no local label
is assigned. The outgoing label will always be the one advertised by the
downstream neighbor.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Implement BGP Prefix-SID IETF draft to be able to signal a labeled-unicast
prefix with a label index (segment ID). This makes it easier to deploy
global MPLS labels with BGP, even without other aspects of Segment Routing
implemented.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Implement BGP Prefix-SID IETF draft to be able to signal a labeled-unicast
prefix with a label index (segment ID). This makes it easier to deploy
global MPLS labels with BGP, even without other aspects of Segment Routing
implemented.
This patch implements configuration of the global label block (SRGB) and
configuration of a label-index for a network in BGP.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Implement support for negotiating IPv4 or IPv6 labeled-unicast address
family, exchanging prefixes and installing them in the routing table, as
well as interactions with Zebra for FEC registration. This is the
implementation of RFC 3107.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Implement support for activating the labeled-unicast address family in
BGP and relevant configuration for this address family.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Code inspection showed a bunch more spots where
we were assigning the safi inside of a if statement
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When outputting routes associated with a 'struct bgp'
do not force the safi to bee SAFI_EVPN and cause output
to be hosed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The original code on shutdown assumed a 'forced' mode
if there was no process_main_queue. This construct
was violated by commit 2e02b9b2d1
due to not fully understanding the shutdown process.
If we are shutting down, don't store work to do later,
just gracefully don't do it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The buffer needs to be set to length 0 if nothing is written into
it, otherwise bgpd will log uninitialized memory, disclosing information
and possibly leading to a crash.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
As the prefix call function for mac handling has prefix_ prepended
before, the change must be propagated to all locations where those
functions are called.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
EVPN code adaptation to replace old mac string internal utility with the
new one available in lib folder.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Transmission and Reception routines have a part of code that is
conditionnally compiled to the usage of HAVE_EVPN. Also, each time a
subfield of prefix evpn is reached, like in configuration also, then a
conditionnaly compilation with HAVE_EVPN is used.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit fixes the nexthop display behaviour when an evpn entry is
matched. The commit handles both cases where IPv4 or IPv6 nexthop is
detected.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
In case a manual set of MPLS, ENCAP, or EVPN entry is set, then the
nexthop attribute localted in attr->extra structure must be changed too.
In standard cases, where IPv4 IGP nexthop address is picked up, the same
address ie chosen.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
A new vty command available under evpn address family. This command
takes following format:
(af-evpn)# [no] network <A.B.C.D/M|X:X::X:X/M> rd ASN:nn_or_IP-address:nn ethtag WORD
label WORD esi WORD gwip A.B.C.D routermac WORD
[route-map WORD]
Among new parameters, ethtag stands for the ethernet tag indentifier.
ESI stands for the ethernet segment identifier, and must be entered in
following format: 00:11:22:33:44:55:66:77:88:99.
gwip stands for the gateway IP address contained in RT5 message. A
check is done on that value since if gwip is ipv4, then ip prefix must
be ipv4. The same for ipv6.
RouterMAc is the gateway mac address sent as extended community
attribute.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
L2VPN route prefix are composed of ethtag, mac address and ip address.
vty command "show bgp l2vpn rd <>" show macip prefix in the following
template: [ethtag][macaddress/len][ipaddress/len]
Signed-off-by: Julien Courtat <julien.courtat@6wind.com>
e
This patch introduces show show bgp evpn commands to dump
NLRI entries configured or received on BGP, related to EVPN
New command introduced is the following:
show [ip] bgp l2vpn evpn [all | rd <rd name> ] [overlay]
Like for MPLS, similar set of commands is added for EVPN:
show [ip] bgp l2vpn evpn [all|rd <RDNAME>]
show [ip] bgp l2vpn evpn all neighbor <NEIGHBOR> routes
show [ip] bgp l2vpn evpn all neighbor <NEIGHBOR> advertised-routes
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
For each received routermac extended community, the mac address is
copied into routermac extended community context. For each emission,
a check is done against routermac extended community, if L2VPN is
enabled. If enabled, the extended community is appended.
Signed-off-by: Philippe Gubiert <philippe.guibert@6wind.com>
This field can be either IPv4 or IPv6 address and is filled in in
bgp_static configuration structure.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
As per draft-ietf-idr-tunnel-encaps-02, section 3.2.1, BGP Encap
attribute supports vxlan tunnel type. A new tunnel attribute has been
appended to subtlv list, describing the vxlan network identifier to
be used for the routing information of the BGP update message.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The commit introduces the changes to be done to carry route type 5 EVPN
information in bgp extra attribute information. The commit also handles
the update processing for route type 5 information, including ESI,
gatewayIP and label information.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This patch introduces code to receive a NLRI message with route type
5, as defined in draft-ietf-bess-evpn-prefix-advertisement-02. It
It increases the number of parameters to extract from the NLRI and
to store into bgp extra information structure. Those parameters are
the ESI (ethernet segment identifier), the gateway IP Address (which
acts like nexthop attribute but is contained inside the NLRI itself)
and the ethernet tag identifier ( that acts for the VXLan Identifier)
This patch updates bgp_update() and bgp_withdraw() api, and then does the
necessary adapations for rfapi.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
To handle BGP NLRI EVPN messages, bgp is modified to handle AFI_L2VPN
and SAFI_EVPN values.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This fix addresses these things:
1) Clean up documentation as requested
2) Fix a wrong search for "exact-match"
3) Fix possible crash.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
