FRR has a provision to give exact-match in match clause for
standard community, but this option is missing for lcommunity.
Part 3 : show related changes for match clause
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
FRR has no option for the as-set for aggregate route
under IPV6 address family. Added the command to
configure the as-set option for IPV6.
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
This is mostly relevant for Solaris, where config.h sets up some #define
that affect overall header behaviour, so it needs to be before anything
else.
Signed-off-by: David Lamparter <equinox@diac24.net>
Issue:
ip route 15.1.1.0/24 10.112.158.15
ip route 15.1.1.0/32 10.112.158.15
Brought up ebgp session between two FRR routers and
redistributed static routes via BGP and verfied the advertising
routes in the peer.
Verify the command "show ip bgp neighbors <neighbor address>
advertised-routes json". It only shows 15.1.1.0/32 route details.
Root casue:
For both the routes "15.1.1.0/24" and "15.1.1.0/32" the advertised
routes key is the prefix i.e. "15.1.1.0".
Fix:
Modify the key to prefix/prefix-length.
Signed-off-by: Sarita Patra <saritap@vmware.com>
* When the bgp is being deleted and routes are in clear workqueue
and new aggregate address being allocated
* Added flag BGP_FLAG_DELETE_IN_PROGRESS in bgp structure to
bgp instance is being deleted
* When adding aggregate route check this flag and peer_self is valid
Signed-off-by: Soman K S <somanks@vmware.com>
The BGP_OPT_CONFIG_CISCO command could no longer be set
as such remove it from the system as a viable option to
be used.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Issue1: When "neighbor X.X.X.X route-map RM-VNI-FILTER in" is configured under evpn address-family,
all the received routes are dropped regardless of whether the route has a matching vni or not.
Issue2: Routes with 2 labels are not filtered correctly
Issue3: Interpreting the label based on tunnel type, vxlan was not done correctly.
Vxlan label has 24 bits, whereas, MPLS label is 20 bits long
Fix1: The handler bgp_update() that services the received route ignored the route's label while deciding whether to filter it or not. As part of the fix, the handler now uses the label info to make the decision about whether to filter the route or not.
Fix2: route_match_vni() now tries to match both the labels within the route, not just the one.
Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP
Traditionally route map MATCH rule apis were designed to return
a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH.
(Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR).
Depending on this response, the following statemachine decided the
course of action:
Action: Apply route-map match and return the result (RMAP_MATCH/RMAP_NOMATCH)
State1: Receveived RMAP_MATCH
THEN: If Routemap type is PERMIT, execute other rules if applicable,
otherwise we PERMIT!
Else: If Routemap type is DENY, we DENYMATCH right away
State2: Received RMAP_NOMATCH, continue on to next route-map, otherwise,
return DENYMATCH by default if nothing matched.
With reference to PR 4078 (https://github.com/FRRouting/frr/pull/4078),
we require a 3rd state because of the following situation:
The issue - what if, the rule api needs to abort or ignore a rule?:
"match evpn vni xx" route-map filter can be applied to incoming routes
regardless of whether the tunnel type is vxlan or mpls.
This rule should be N/A for mpls based evpn route, but applicable to only
vxlan based evpn route.
Today, the filter produces either a match or nomatch response regardless of
whether it is mpls/vxlan, resulting in either permitting or denying the
route.. So an mpls evpn route may get filtered out incorrectly.
Eg: "route-map RM1 permit 10 ; match evpn vni 20" or
"route-map RM2 deny 20 ; match vni 20"
With the introduction of the 3rd state, we can abort this rule check safely.
How? The rules api can now return RMAP_NOOP (or another enum) to indicate
that it encountered an invalid check, and needs to abort just that rule,
but continue with other rules.
Question: Do we repurpose an existing enum RMAP_OKAY or RMAP_ERROR
as the 3rd state (or create a new enum like RMAP_NOOP)?
RMAP_OKAY and RMAP_ERROR are used to return the result of set cmd.
We chose to go with RMAP_NOOP (but open to ideas),
as a way to bypass the rmap filter
As a result we have a 3rd state:
State3: Received RMAP_NOOP
Then, proceed to other route-map, otherwise return RMAP_PERMITMATCH by default.
Signed-off-by:Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
We already show this information in `show [ip] bgp <prefix`, thus why don't
show it in global output. It's very handy when using at scale and to see
the whole picture instead of resolving neighbor manually.
It will show FQDN only if `bgp default show-hostname` is toggled.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
As part of detailed bgp route detail, include the
reason why a route was selected as best path.
robot# show bgp ipv4 uni 223.255.254.0
BGP routing table entry for 223.255.254.0/24
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
annie(192.168.201.136)
64539 15096 6939 7473 3758 55415
192.168.201.136 from annie(192.168.201.136) (192.168.201.136)
Origin IGP, valid, external, bestpath-from-AS 64539, best (First path received)
Last update: Wed May 15 21:15:48 2019
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Store in bgp_node the reason why we choose a particular
best path over another. At this point we do not do
anything other than just store this data when we make
the decision. Future commits will display it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Instead of just passing in the prefix, pass in the particular
bgp_node we are using.
This is setup for a future commit to use this data.
The long term goal is to collect data about why
a particular bgp_path_info was selected as best and
to display that reason.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Display a debug message while sending a BGP route if the route is filtered by a
route-map.
Debug for incoming filtered route is already present.
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
Prevent the ebgp sender from changing the nexthop( which is same as the ebgp neighbour ipv6 address),
while sending updates to its ipv6 neighbor.So,if the nexthop of the ipv6 route is same as the ipv6
neighbour address do not change the next hop to your own ip.
Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
Prevent IPv6 routes received via a ibgp session with one of its own interface
ip as nexthop from getting installed in the BGP table.
Implemented IPV6 HASH table, where we need to add any ipv6 address as they
gets configured and delete them from the HASH table as the ipv6 addresses
get unconfigured. The above hash table is used to verify if any route learned
via BGP has nexthop which is equal to one of its its connected ipv6 interface.
Signed-off-by: Biswajit Sadhu sadhub@vmware.com
EVPN routes (type-2/type-5) are imported from
default bgp instance (where they are learnt) to
non-default vrf instance.
When a bgp instance (default) is deleted,
unimport evpn routes from vrfs.
In absence of unimport, the imported routes in vrf
has parent path info points to default instance's path
info which is no longer valid (if instance is deleted).
When accessing parent path info leads to a crash
in non-default vrf instance.
The bgp instance is not cleaned up when
'no router bgp ASN' is performed, the instance's
reference count remains for evpn imported routes.
Ticket:CM-24484
Reviewed By:
Testing Done:
Validated via learning EVPN type-2/type-5 routes in symmetric
routing scenario.
The routes are imported to VRFs based on corresponding
L3VNI. When the default instance is removed, the evpn routes
are cleaned up from the VRF instance.
TURTLE(config)# do show bgp vrf vrf3 ipv4 unicast
Network Next Hop Metric LocPrf Weight Path
*> 70.1.0.0/16 0.0.0.0 32768 i
s 70.1.1.24/32 110.0.0.2 0 65100 65002 i
s> 110.0.0.2 0 65100 65002 i
s 70.1.1.43/32 110.0.0.4 0 65100 65004 i
s> 110.0.0.4 0 65100 65004 i
TURTLE(config)# no router bgp 65050
TURTLE(config)# do show bgp vrf vrf3 ipv4 unicast
No BGP prefixes displayed, 0 exist
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
The bgp_path_info_new function whenever it was called
pretty much duplicated the info_make function call. So
convert over to using it and remove the bgp_path_info_new
function so people are not tempted.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The creation of a new `struct bgp_path_info` requires a legitimate
peer being passed in for creation. There exists no code paths
where this is not true. As such checking pi->peer for null convinces
SA that it might happen.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In order to iterate over MPLS VPN routes, it's necessary to use
two nested loops (the outer loop iterates over the MPLS VPN RDs,
and the inner loop iterates over the VPN routes from that RD).
The bgp_table_stats_walker() function wasn't giving this special
treatment to the MPLS VPN safi as it should, which was leading to
crashes and malfunctioning. Fix this.
Signed-off-by: Renato Westphal <renatowestphal@gmail.com>
pinum (renamed from rinum) was never used for anything useful since
the initial revision ~17 years ago. Get rid of it.
Signed-off-by: Renato Westphal <renatowestphal@gmail.com>
while labeled_unicast routes should be fetched in the
unicast table, we cannot set the safi to SAFI_UNICAST
else the peer afc checks and subgroup retrieval will fail
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
bgp entries in bgp_extra_path structure will be allocated as lists, only
when needed, that is to say when bgp fs entries will be received and
installed on the underlying system.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
bgp update can contain router mac address same as one of SVIs
mac address, during processing of evpn route in bpg_update()
check for the flag is set and filter the route from installing.
This check is done prior to attribute lookup or storing in database.
Parse check and set is done once during attribute parse
because all the NLRIs containing evpn prefix
(type-2/type-5) will have same exntended community applicable.
Ticket:CM-23674
Reviewed By:CCR-8336
Testing Done:
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
The code that causes the bottleneck has been written generically to
handle the below two cases:
a) When a new aggregate-address is configured.
b) When new routes, that can be aggregated under an existing
aggregate-address, are received.
This change optimizes the code that handles case-(b).
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
With this commit:
1) 'struct bgp_aggregate' is moved to bgp_route.h from bgp_route.c
2) Hashes to accommodate the as-path, communities, extended-communities and
large-communities attributes of all the routes aggregated by an
aggregate route is introduced in 'struct bgp_aggregate'.
3) Place-holders for the aggregate route's as-path, communities,
extended-communities and large-communities attributes are introduced in
'struct bgp_aggregate'.
4) The code to manage the as-path of the routes that are aggregatable under
a configured aggregate-address is introduced.
5) The code to compute the aggregate-route's as-path is introduced.
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
Refine check on whether a route can be injected into EVPN to allow
EVPN-sourced routes to be injected back into another instance.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
When a IPv4 or IPv6 route that was formerly allowed by the route-map
to be injected into EVPN gets an updated set of attributes that now
causes it to be filtered, the route needs to be pulled out of EVPN.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
If path->net is NULL in the bgp_path_info_free() function, then
bgpd would crash in bgp_addpath_free_info_data() with the following
backtrace:
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ff7b267a42a in __GI_abort () at abort.c:89
#2 0x00007ff7b39c1ca0 in core_handler (signo=11, siginfo=0x7ffff66414f0, context=<optimized out>) at lib/sigevent.c:249
#3 <signal handler called>
#4 idalloc_free_to_pool (pool_ptr=pool_ptr@entry=0x0, id=3) at lib/id_alloc.c:368
#5 0x0000560096246688 in bgp_addpath_free_info_data (d=d@entry=0x560098665468, nd=0x0) at bgpd/bgp_addpath.c:100
#6 0x00005600961bb522 in bgp_path_info_free (path=0x560098665400) at bgpd/bgp_route.c:252
#7 bgp_path_info_unlock (path=0x560098665400) at bgpd/bgp_route.c:276
#8 0x00005600961bb719 in bgp_path_info_reap (rn=rn@entry=0x5600986b2110, pi=pi@entry=0x560098665400) at bgpd/bgp_route.c:320
#9 0x00005600961bf4db in bgp_process_main_one (safi=SAFI_MPLS_VPN, afi=AFI_IP, rn=0x5600986b2110, bgp=0x560098587320) at bgpd/bgp_route.c:2476
#10 bgp_process_wq (wq=<optimized out>, data=0x56009869b8f0) at bgpd/bgp_route.c:2503
#11 0x00007ff7b39d5fcc in work_queue_run (thread=0x7ffff6641e10) at lib/workqueue.c:294
#12 0x00007ff7b39ce3b1 in thread_call (thread=thread@entry=0x7ffff6641e10) at lib/thread.c:1606
#13 0x00007ff7b39a3538 in frr_run (master=0x5600980795b0) at lib/libfrr.c:1011
#14 0x000056009618a5a3 in main (argc=3, argv=0x7ffff6642078) at bgpd/bgp_main.c:481
Add a null-check protection to fix this problem.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Made changes and updated the routemap applied counter in the following flows.
1.Increment when route map attached to a list.
2.Decrement when route map removed / modified from a list.
3.Increment/decrement when route map create/delete callback triggered.
4.Besides ,This counter need not be updated when a route map is got updated.
i.e changing/adding a match value to the existing routemap.
In BGP , same update api called for all three add/delete/update operation .
But this counter have to be updated only for routemap addition.
Addressed this specific change by identifying the routemap operation based
on routemap pointer.
Signed-off-by: RajeshGirada <rgirada@vmware.com>
Executed some evpn related tests with valgrind and saw some errors
related to uninitialized memory and overlapping memcpy. This commit
fixes those.
Ticket: CM-21218
Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com>
Reviewed-by: CCR-8249
the list of iprules is displayed in the 'show bgp ipv4 flowspec detail'
The list of iprules is displayed, only if it is installed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
when removing bgp instance, the parsing of rm->info contexts must be
protected. Also, the main level of hierarchy of rds must not be
allocated more than once.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
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>
