When an EVPN prefix flaps too quickly such that the new advertisement
is received prior to the full processing of the prior withdraw, we may
get into a state where the route doesn't get imported properly into
MAC or IP VRFs. Ensure that we do the route import in such cases.
Suggested-by: Sri Mohana Singamsetty <msingamsetty@vmware.com>
Suggested-by: Ameya Dharkar <adharkar@vmware.com>
Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
Add a bit of code to allow for auto-completion of the community
alias command when attempting to use it for show commands.
example:
eva(config)# bgp community alias 11:22 FOO
eva(config)# end
eva# show bgp ipv4 uni alias
ALIAS_NAME BGP community alias
FOO
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Some BGP updates received by BGP invite local router to
install a route through itself. The system will not do it, and
the route should be considered as not valid at the earliest.
This case is detected on the zebra, and this detection prevents
from trying to install this route to the local system. However,
the nexthop tracking mechanism is called, and acts as if the route
was valid, which is not the case.
By detecting in BGP that use case, we avoid installing the invalid
routes.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Force the processing of existing network configurations when VRF is
created, otherwise will be skipped in bgp_static_update().
Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
Add a terse option to show bgp summary to shorten output.
Do not show the following information about the BGP
instances: the number of RIB entries, the table version and the used memory.
The "terse" option can be used in combination with the "remote-as", "neighbor",
"failed" and "established" filters, and with the "wide" option as well.
Before patch:
ubuntu# show bgp summary remote-as 123456
IPv4 Unicast Summary (VRF default):
BGP router identifier X.X.X.X, local AS number XXX vrf-id 0
BGP table version 0
RIB entries 3, using 552 bytes of memory
Peers 5, using 3635 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
10.200.200.2 4 123456 81432 4 0 56092 0 00:00:13 572106 0 N/A
Displayed neighbors 1
Total number of neighbors 4
IPv6 Unicast Summary (VRF default):
BGP router identifier X.X.X.X, local AS number XXX vrf-id 0
BGP table version 0
RIB entries 3, using 552 bytes of memory
Peers 5, using 3635 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
% No matching neighbor
Total number of neighbors 5
After patch:
ubuntu# show bgp summary remote-as 123456 terse
IPv4 Unicast Summary (VRF default):
BGP router identifier X.X.X.X, local AS number XXX vrf-id 0
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
10.200.200.2 4 123456 81432 4 0 56092 0 00:00:13 572106 0 N/A
Displayed neighbors 1
Total number of neighbors 4
IPv6 Unicast Summary (VRF default):
BGP router identifier X.X.X.X, local AS number XXX vrf-id 1
% No matching neighbor
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
While installing this route in the EVPN table, make sure all the conditions
mentioned in the draft
https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement-11 are
met.
Draft mentions following conditions:
- ESI and gateway IP cannot be both nonzero at the same time.
- ESI, gateway IP, RMAC and VNI label all cannot be 0 at the same time.
If the received EVPN RT-5 route does not meet these conditions, the route is
treated as withdraw.
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
Gateway IP overlay index is generated for EVPN RT-5 when following CLI is
configured.
router bgp 100 vrf vrf-blue
address-family l2vpn evpn
advertise ipv4 unicast gateway-ip
advertise ipv6 unicast gateway-ip
BGP nexthop of the VRF IP/IPv6 route is set as the gateway IP of the
corresponding EVPN RT-5
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
We are inconsistently using peer_establiahed(peer) with
sometimes using `peer->status == Established`. Just Convert
over to using the function for consistency.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
BGP configuration changes that imply recomputing the BGP route table
(e.g. modifying route-maps, setting bgp graceful-shutdown) might be a
long time process depending on the size of the BGP table and the
route-map numbers and complexity. For example, setups with full
Internet routes take something like one minute to reprocess all the
prefixes when graceful-shutdown is configured. During this time, a
"show bgp commands" request on vtysh results in blocking the shell until
the soft reconfigure table task is over.
This patch splits bgp_soft_reconfig_table task into thread jobs of 25K
prefixes.
Some tests on a full Internet route setup show that after reconfiguring
route-maps or graceful-shutdown, vtysh is not stucked anymore. We are
now able to request commands like "show bgp summary" after 1 or 2
seconds instead of 30 to 60s.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
For EVPN routes, there is specific logic in place for path selection
surrounding MAC Mobility. For pure type-5 routes, if a route is
advertised with a MED, this is ignored since it ultimately falls inside
of the EVPN specific path selection logic, and ultimately selects the
lower IP address. This change ensures only type-2 routes fall into the
EVPN BGP path selection.
Signed-off-by: Neal Shrader <neal@digitalocean.com>
Show alias name instead of numerical value in `show bgp <prefix>. E.g.:
```
root@exit1-debian-9:~/frr# vtysh -c 'sh run' | grep 'bgp community alias'
bgp community alias 65001:123 community-1
bgp community alias 65001:123:1 lcommunity-1
root@exit1-debian-9:~/frr#
```
```
exit1-debian-9# sh ip bgp 172.16.16.1/32
BGP routing table entry for 172.16.16.1/32, version 21
Paths: (2 available, best #2, table default)
Advertised to non peer-group peers:
65030
192.168.0.2 from home-spine1.donatas.net(192.168.0.2) (172.16.16.1)
Origin incomplete, metric 0, valid, external, best (Neighbor IP)
Community: 65001:12 65001:13 community-1 65001:65534
Large Community: lcommunity-1 65001:123:2
Last update: Fri Apr 16 12:51:27 2021
exit1-debian-9#
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Absolutetly cosmetic change, but let it be consistent with other checks
for optional attributes.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
This is useful to go back in the past and check when was that prefix appeared,
changed, etc.
```
exit1-debian-9# show ip bgp 172.16.16.1/32
BGP routing table entry for 172.16.16.1/32, version 6
Paths: (2 available, best #2, table default)
Advertised to non peer-group peers:
home-spine1.donatas.net(192.168.0.2) home-spine1.donatas.net(2a02:bbd::2)
65030
192.168.0.2 from home-spine1.donatas.net(2a02:bbd::2) (172.16.16.1)
Origin incomplete, metric 0, valid, external
Last update: Thu Apr 8 20:15:25 2021
65030
192.168.0.2 from home-spine1.donatas.net(192.168.0.2) (172.16.16.1)
Origin incomplete, metric 0, valid, external, best (Neighbor IP)
Last update: Thu Apr 8 20:15:25 2021
exit1-debian-9#
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Just to be more informant, copying from Cisco.
```
exit1-debian-9# sh ip bgp
BGP table version is 4, local router ID is 192.168.100.1, vrf id 0
Default local pref 100, local AS 65534
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
N*> 10.0.2.0/24 0.0.0.0 0 32768 ?
N*> 192.168.0.0/24 0.0.0.0 0 32768 ?
N*> 192.168.10.0/24 0.0.0.0 0 32768 ?
N*> 192.168.100.1/32 0.0.0.0 0 32768 ?
Displayed 4 routes and 4 total paths
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
set_vpn_nexthop/no_set_vpn_nexthop were failing due to missing
declarations and unused variables.
This adds the missing declaration and removes unused variables.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
New and improved submission for this commit -- updated to accommodate
changes from 4027d19b0.
Adds support for 'rd all' matching for EVPN and L3VPN show commands.
Introduces evpn_show_route_rd_all_macip().
Cleans up some show commands to use SHOW_DISPLAY string constants.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
During Review it was suggested that appending rpki_
to curr_state and target_state would be better
variable names. Instead of going and fixing
3 or so commits up. Just do this one.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add the ability for the end operator to query the state of valid
or invalid or no information rpki prefix information.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When displaying data about the rpki state, use the
string `rpki validation-state` instead of `validation-state:`
to avoid confusion with `(valid)`
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Setup a mh_info indirection in the path extra. This has been done to
avoid increasing evpn route's path size to add new (type based) pointers
in path_info_extra.
Ticket: CM-31398
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
There are two changes in this commit -
1. Maintain a list of global MAC-IP routes per-ES. This list is maintained
for quick processing on the following events -
a. When the first VTEP/PE becomes active in the ES-VRF, the L3 NHG is
activated and the route can be sent to zebra.
b. When there are no active PEs in the ES-VRF the L3 NHG is
de-activated and -
- If the ES is present in the VRF -
The route is not installed in zebra as there are no active PEs for
the ES-VRF
- If the ES is not present in the VRF -
The route is installed with a flat multi-path list i.e. without L3NHG.
This is to handle the case where there are no locally attached L2VNIs
on the ES (for that tenant VRF).
2. Reinstall VRF route when an ES is installed or uninstalled in a
tenant VRF (the global MAC-IP list in #1 is used for this purpose also).
If an ES is present in the VRF we use L3NHG to enable fast-failover of
routed traffic.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
This new BGP configuration is akin to "bgp bestpath aspath
multipath-relax". When applied, paths learned from different peer types
will be eligible to be considered for multipath (ECMP). Paths from all
of eBGP, iBGP, and confederation peers may be included in multipaths
if they are otherwise equal cost.
This change preserves the existing bestpath behavior of step 10's result
being returned, not the result from steps 8 and 9, in the case where
both 8+9 and 10 determine a winner.
Signed-off-by: Joanne Mikkelson <jmmikkel@arista.com>
Adds support for 'rd all' matching for EVPN and L3VPN show commands.
Introduces evpn_show_route_rd_all_macip().
Cleanup some show commands to use SHOW_DISPLAY string constants.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
When dumping data about prefixes in bgp. Let's dump the
rpki validation state as well:
Output if rpki is turned on:
janelle# show rpki prefix 2003::/19
Prefix Prefix Length Origin-AS
2003:: 19 - 19 3320
janelle# show bgp ipv6 uni 2003::/19
BGP routing table entry for 2003::/19
Paths: (1 available, best #1, table default)
Not advertised to any peer
15096 6939 3320
::ffff:4113:867a from 65.19.134.122 (193.72.216.231)
(fe80::e063:daff:fe79:1dab) (used)
Origin IGP, valid, external, best (First path received), validation-state: valid
Last update: Sat Mar 6 09:20:51 2021
janelle# show rpki prefix 8.8.8.0/24
Prefix Prefix Length Origin-AS
janelle# show bgp ipv4 uni 8.8.8.0/24
BGP routing table entry for 8.8.8.0/24
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
100.99.229.142
15096 6939 15169
65.19.134.122 from 65.19.134.122 (193.72.216.231)
Origin IGP, valid, external, best (First path received), validation-state: not found
Last update: Sat Mar 6 09:21:25 2021
Example output when rpki is not configured:
eva# show bgp ipv4 uni 8.8.8.0/24
BGP routing table entry for 8.8.8.0/24
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
janelle(192.168.161.137)
64539 15096 6939 15169
192.168.161.137(janelle) from janelle(192.168.161.137) (192.168.44.1)
Origin IGP, valid, external, bestpath-from-AS 64539, best (First path received)
Last update: Sat Mar 6 09:33:51 2021
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
'show bgp l2vpn evpn statistics' was returning 0 for all stats
because bgp_table_stats_walker bailed out if afi != AFI_IP or AFI_IP6.
Add case condition to catch AFI_L2VPN.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
If we are filtering a route due to any of the filter reasons
we should not be setting the BGP_NODE_FIB_INSTALL_FIB_PENDING
flag. This is especially evident with say a loopback that
is covered by a network statement. When we receive the route
back from our peer we should not be setting the
BGP_NODE_FIB_INSTALL_PENDING flag on it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
'show bgp ipv[46] vpn neighbors ... advertised-routes' was displaying
empty output due to new command syntax using show_adj_routes() which
assumed each bgp_table was single-tier (not nested). This fixes that
assumption for safis with a two-tier bgp_table (SAFI_MPLS_VPN,
SAFI_ENCAP, and SAFI_EVPN).
Before:
ub18# show bgp ipv6 vpn neighbors 2001:db8:cafe::2 advertised-routes
ub18#
After:
ub20# show bgp ipv6 vpn neighbors 2001:db8:cafe::1 advertised-routes
BGP table version is 2, local router ID is 100.64.0.222, vrf id 0
Default local pref 100, local AS 1
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 30:30
*> 2::2/128 :: 0 100 32768 i
*> 2::22/128 :: 0 100 32768 i
Route Distinguisher: 33:33
*> 2::2/128 :: 0 100 32768 i
*> 2::22/128 :: 0 100 32768 i
Total number of prefixes 4
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
`same_attr` has been computed and `hook_call(bgp_process)` (calling
BMP module) would not change it. We could reuse the value to filter
same attribute updates, avoiding an extra comparison.
Signed-off-by: zyxwvu Shi <i@shiyc.cn>
Already not necessary, because if BGP aggregator AS attribute is with
value of 0, then the attribute is already discarded at early processing.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Description:
clear ip bgp dampening was not triggering the route
calculation for the prefix, Due to this prefix are not install in
RIB(Zebra) and not adv to neighbor
Problem Description/Summary :
clear ip bgp dampening was not triggering the route
calculation for the prefix, Due to this prefix are not install in
RIB(Zebra) and not adv to neighbor
Fix: When clear ip bgp dampening, route are put for route-calculation as
that it is install in the Zebra and adv to neighbor.
Signed-off-by: sudhanshukumar22 <sudhanshu.kumar@broadcom.com>
If we are using a nexthop for a MPLS VPN route make sure the
nexthop is over a labeled path. This new check mirrors the one
in validate_paths (where routes are enabled when a nexthop
becomes reachable). The check is introduced to the code path
where routes are added and the nexthop is looked up.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
community_str2com("no-export"); returns ALWAYS non-NULL.
If NULL returned here, we really have a bigger problems in the call path.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
RFC says to prevent propagation of the prefix outside the local AS.
So, let's use NO_EXPORT.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Issue: bgpd got kill due to out of memory, when show bgp
neighbor json and show ip bgp neighbor <ip> routes json
commands executed multiple times in a setup having 320554
routes.
RCA: Heap allocated for bgpd keeps increasing. This is verified
using top command and show memory command.
Memleak Fix-1: show ip bgp route json command
When dumping a large bit of table data via bgp_show_route
and if there is no information to display for a particular
struct bgp_node *` the data allocated via json_object_new_array()
is not freed. This is resolved now.
Memleak Fix-2:
The function bgp_peer_counts() doesn't free the memory allocated for
json_loop when there is No such neighbor or address family. This is
fixed now.
Signed-off-by: Sarita Patra <saritap@vmware.com>
rfc7999:
A BGP speaker receiving an announcement tagged with the BLACKHOLE
community SHOULD add the NO_ADVERTISE or NO_EXPORT community as
defined in [RFC1997], or a similar community, to prevent propagation
of the prefix outside the local AS. The community to prevent
propagation SHOULD be chosen according to the operator's routing
policy.
Sent:
```
router bgp 65534
no bgp ebgp-requires-policy
neighbor 192.168.0.2 remote-as 65030
!
address-family ipv4 unicast
redistribute connected
neighbor 192.168.0.2 route-map spine out
exit-address-family
!
!
ip prefix-list self seq 5 permit 192.168.100.1/32
!
route-map spine permit 10
match ip address prefix-list self
set community blackhole
!
```
Received:
```
spine1-debian-9# show ip bgp 192.168.100.1/32
BGP routing table entry for 192.168.100.1/32
Paths: (1 available, best #1, table default, inform peer to blackhole prefix)
Not advertised to any peer
65534
192.168.0.1 from 192.168.0.1 (192.168.100.1)
Origin incomplete, metric 0, valid, external, best (First path received)
Community: blackhole no-advertise
Last update: Thu Jan 21 12:56:39 2021
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
When bgp is using wait for install semantics it would be nice
to be able to debug it when it is running.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
To prepare for fixing an issue where labels do not get released back
to the labelpool when the route is deleted some refactoring is
necessary. There are 2 parts to this.
1. restructure the code to remove the circular nature of label
allocations via the labelpool and decouple the label type decision
from the notification fo the FEC.
The code to notify the FEC association to zebra has been split out
into a separate function so that it can be called from the synchronous
path (for registration of index-based labels and de-registration of all
labels), and from the asynchronous path where we need to wait for a
callback from the labelpool code with a label allocation.
The decision about whether we are using an index-based label or an
allocated label is reflected in the state of the BGP_NODE_LABEL_REQUESTED
flag so the checks on the path_info in the labelpool callback code are
no longer required.
2. change the owned of a labelpool allocated label from the path info
structure to the bgp_dest structure. This allows labels to be released
(in a subsequent commit) when the owner (bgp_dest) goes away.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
Remove awful test of a strmatch against a call to get_afi_safi_str.
These are the easy ones as that the real decision point is/was
underneath this test. This is just duplicate expensive testing.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Use user provided AD for local routes (aggregate).
address-family ipv4 unicast
distance bgp 20 200 210
network 47.2.2.8/30
aggregate-address 51.1.0.0/16
Testing Done:
Before aggr route uses default 200 AD even user provided local AD.
B>* 51.1.0.0/16 [200/0] unreachable (blackhole), weight 1, 00:01:14
After:
B>* 51.1.0.0/16 [210/0] unreachable (blackhole), weight 1, 00:00:01
Signed-off-by: Chirag Shah <chirag@nvidia.com>
bgp aggregate address installs route with self peer which
can have peer->su of unspecifed type.
bgp_distance_apply bailed out as it fails to parse
sockunion2hostprefix for af type unspec.
config:
address-family ipv4 unicast
aggregate-address 50.1.0.0/16 summary-only
Testing Done:
Before:
B>* 50.1.0.0/16 [20/0] unreachable (blackhole), weight 1, 00:00:02
After:
B>* 50.1.0.0/16 [200/0] unreachable (blackhole), weight 1, 00:01:28
Signed-off-by: Chirag Shah <chirag@nvidia.com>
1. MAC-IP routes in the VPN routing table are linked to the
destination ES for efficient handling for remote ES link flaps.
2. Only MAC-IP paths whose nexthops are active (added via EAD-ES)
are imported into the VRF routing table.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
The return from sockunion2hostprefix tells us if the conversion
succeeded or not. There are places in the code where we
always assume that it just `works`, since it can fail
notice and try to do the right thing.
Please note that failure of this function for most cases
of sockunion2hostprefix is highly highly unlikely as that
the sockunion was already created and tested elsewhere
it's just that this function can fail.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
