Donald Sharp [Mon, 2 Nov 2020 17:55:45 +0000 (12:55 -0500)]
bgpd: Convert attr->evpn_overlay to accessor functions
Convert usage of the attr->evpn_overlay to get/set functionality.
Future commits will allow us to abstract this data to when
we actually need it for the `struct attr`.
Donald Sharp [Mon, 2 Nov 2020 15:52:40 +0000 (10:52 -0500)]
bgpd: Add accessor for bgp_attr.pmsi_tnl_type
Add an accessor for the bgp_attr.pmsi_tnl_type to allow
us to abstract where it is. Every attribute is paying
the price of this bit of data as part of `struct bgp_attr`
In the future we'll move it elsewhere.
Donald Sharp [Sat, 14 Nov 2020 22:33:43 +0000 (17:33 -0500)]
bgpd: on debug esi was not properly setup
There exists a code path where the esi would be passed
to a debug without the esi being setup with any values
causing us to display what ever is on the stack.
Donald Sharp [Sat, 14 Nov 2020 20:32:49 +0000 (15:32 -0500)]
bgpd: Fix missed unlocks
When iterating over the bgp_dest table, using this pattern:
for (dest = bgp_table_top(table); dest;
dest = bgp_route_next(dest)) {
If the code breaks or returns in the middle we will not have
properly unlocked the node as that bgp_table_top locks the top
dest and bgp_route_next locks the next dest and unlocks the old
dest.
From code inspection I have found a bunch of places that
we either return in the middle of or a break is issued.
Donald Sharp [Thu, 12 Nov 2020 15:27:24 +0000 (10:27 -0500)]
bgpd: Respect `-e X` value for multipath
When entering values for maximum-path if the user
has entered a value to respect from the bgp cli `-e X`
that is the maximum value we should use when accepting
values from the user.
Donald Sharp [Thu, 12 Nov 2020 20:15:52 +0000 (15:15 -0500)]
lib: Fix crash walking up command chain in bgp commands
As part of normal processing we allow bgp commands to walk
up the command node chain. We are experiencing this crash:
Thread 1 "bgpd" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
assertion=0x7ffff7f3ba4f "set", file=0x7ffff7f3ba44 "lib/yang.c", line=413, function=<optimized out>)
at assert.c:92
line=413, function=0x7ffff7f3bc50 <__PRETTY_FUNCTION__.9> "yang_dnode_get") at assert.c:101
vty=0x5555561715a0, argc=3, argv=0x555558601620) at bgpd/bgp_vty.c:9568
cmd=0x0) at lib/command.c:937
at lib/command.c:997
matched=0x0, vtysh=0) at lib/command.c:1161
at lib/vty.c:517
(gdb)
We are effectively sending in an array index based upon vty->xpath_index( which is zero) but
the VTY_CURR_XPATH macro subtracts 1 from that value to find the appropriate xpath to use.
This of course subtracts 1 from 0 and we underflow the array.
The relevant section in a config file is this:
address-family ipv6 flowspec
bgp maxim...
Effectively we were trying to walk up the command chain for flowspec to see
if the command is entered correctly. There is a function vty_check_node_for_xpath_decrement
that was looking at bgp sub-modes to make the decision to allow us to decrement
the vty->xpath_index which did not have the v4 or v6 flowspec bgp sub modes in the
check.
Donald Sharp [Sat, 7 Nov 2020 00:56:36 +0000 (19:56 -0500)]
bgpd: Shorten some `show memory` strings
Some of the `show memory` strings in bgp are longer than the
columns we have allocated for it. Shorten some strings to
make them fit and have the output pleasing to the eye.
Michael Hohl [Wed, 11 Nov 2020 15:56:15 +0000 (16:56 +0100)]
docs: mention activate keyword in user docs
As of now, the BGP user documentation does not explicitly mention how
to use IPv6. This commit adds documentation of the activate command to
the user documentation which is crucial to get IPv6 networks announced
using FRRouting.
Pat Ruddy [Thu, 29 Oct 2020 16:38:42 +0000 (16:38 +0000)]
bgpd: withdraw any exported routes when deleting a vrf
When a BGP vrf instance is deleted, the routes it exported into the
main VPN table are not deleted and they remain as stale routes
attached to an unknown bgp instance. When the new vrf instance comes
along, it imports these routes from the main table and thus we see
duplicatesalongside its own identical routes.
The solution is to call the unexport logic when a BGP vrf instance is
being deleted.
problem example
---------------
volta1# sh bgp vrf VRF-a ipv4 unicast
BGP table version is 4, local router ID is 18.0.0.1, vrf id 5
Default local pref 100, local AS 567
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
*> 7.0.0.6/32 7.0.0.5@0< 10 100 0 ?
*> 7.0.0.8/32 18.0.0.8 0 0 111 ?
*> 18.0.0.0/24 18.0.0.8 0 0 111 ?
*> 56.0.0.0/24 7.0.0.5@0< 0 100 0 ?
Displayed 4 routes and 4 total paths
volta1# conf t
volta1(config)# no router bgp 567 vrf VRF-a
volta1(config)#
volta1(config)# router bgp 567 vrf VRF-a
volta1(config-router)# bgp router-id 18.0.0.1
volta1(config-router)# no bgp ebgp-requires-policy
volta1(config-router)# no bgp network import-check
volta1(config-router)# neighbor 18.0.0.8 remote-as 111
volta1(config-router)# !
volta1(config-router)# address-family ipv4 unicast
volta1(config-router-af)# label vpn export 12345
volta1(config-router-af)# rd vpn export 567:111
volta1(config-router-af)# rt vpn both 567:100
volta1(config-router-af)# export vpn
volta1(config-router-af)# import vpn
volta1(config-router-af)# exit-address-family
volta1(config-router)# !
volta1(config-router)# end
volta1# sh bgp vrf VRF-a ipv4 unicast
BGP table version is 4, local router ID is 18.0.0.1, vrf id 5
Default local pref 100, local AS 567
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
*> 7.0.0.6/32 7.0.0.5@0< 10 100 0 ?
* 7.0.0.8/32 18.0.0.8 0 0 111 ?
*> 18.0.0.8@-< 0 0 111 ?
* 18.0.0.0/24 18.0.0.8 0 0 111 ?
*> 18.0.0.8@-< 0 0 111 ?
*> 56.0.0.0/24 7.0.0.5@0< 0 100 0 ?
Displayed 4 routes and 6 total paths
@- routes indicating unknown bgp instance are imported
Mark Stapp [Tue, 10 Nov 2020 19:14:23 +0000 (14:14 -0500)]
tests: reduce scale of the route scale test
Reduce the number of routes used in the route-scale test: we're
having memory troubles, and this may help the CI run with fewer
false failures. Also re-orged the route-scale test code a bit
so it can be driven from the json file, with fewer hard-coded
values.
Mark Stapp [Tue, 10 Nov 2020 14:50:50 +0000 (09:50 -0500)]
tests: only test count of nexthops in bgp max-paths test
Add support to compare the number of RIB nexthops, rather than the
specific nexthop addresses. Use this in the bgp_ecmp topotests that
test maximum-paths - testing the specific nexthops is wrong there,
it's not deterministic and we get spurious failures.
Soman K S [Fri, 6 Nov 2020 03:25:56 +0000 (08:55 +0530)]
bgpd: Advertise FIB installed routes to bgp peers (Part 3)
* Process FIB update in bgp_zebra_route_notify_owner() and call
group_announce_route() if route is installed
* When bgp update is received for a route which is not installed earlier
(flag BGP_NODE_FIB_INSTALLED is not set) and suppress fib is enabled
set the flag BGP_NODE_FIB_INSTALL_PENDING to indicate fib install is
pending for the route. The route will be advertised when zebra send
ZAPI_ROUTE_INSTALLED status.
* The advertisement delay (BGP_DEFAULT_UPDATE_ADVERTISEMENT_TIME)
is added to allow more routes to be sent in single update message.
This is required since zebra sends route notify message for each route.
The delay will be applied to update group timer which advertises
routes to peers.
Soman K S [Fri, 6 Nov 2020 03:16:04 +0000 (08:46 +0530)]
bgpd: Advertise FIB installed routes to bgp peers (Part 2)
* Added CLI command "[no] bgp suppress-fib-pending" to enable and
disable suppress-fib-pending
* Send ZEBRA_ROUTE_NOTIFY_REQUEST to zebra when "bgp suppress-fib-pending"
is enabled or disabled
* Define BGP_DEFAULT_UPDATE_ADVERTISEMENT_TIME which is the delay added
to update group timer.
* Added error codes
Soman K S [Fri, 6 Nov 2020 03:09:28 +0000 (08:39 +0530)]
bgpd: Advertise FIB installed routes to bgp peers (Part 1)
Issue:
The bgp routes learnt from peers which are not installed in kernel are
advertised to peers. This can cause routers to send traffic to these
destinations only to get dropped. The fix is to provide a configurable
option "bgp suppress-fib-pending". When the option is enabled, bgp will
advertise routes only if it these are successfully installed in kernel.
Fix (Part1) :
* Added message ZEBRA_ROUTE_NOTIFY_REQUEST used by client to request
FIB install status for routes
* Added AFI/SAFI to ZAPI messages
* Modified the functions zapi_route_notify_decode(), zsend_route_notify_owner()
and route_notify_internal() to include AFI, SAFI as parameters
Donald Sharp [Fri, 6 Nov 2020 01:42:03 +0000 (20:42 -0500)]
bgpd: Actually return the group peer
The code is returning the group peer data structure, which
is what is happening but we should not have assignment statements
in this return statement for a `struct peer *` return.
Donald Sharp [Fri, 30 Oct 2020 17:34:30 +0000 (13:34 -0400)]
bgpd: Remove pointer structure from `struct bgp_dest`
The `struct listnode *rt_node` data structure is adding
8 bytes of size to the `struct bgp_dest`. This is a large
amount of data for a flag we are already setting on each
node for this. Just set the flag and use that to figure
out who we are doing graceful restart on.
Renato Westphal [Sat, 24 Oct 2020 00:05:30 +0000 (21:05 -0300)]
isisd: detect Prefix-SID collisions and handle them appropriately
isisd relies on its YANG module to prevent the same SID index
from being configured multiple times for different prefixes. It's
possible, however, to have different routers assigning the same SID
index for different prefixes. When that happens, we say we have a
Prefix-SID collision, which is ultimately a misconfiguration issue.
The problem with Prefix-SID collisions is that the Prefix-SID that
is processed later overwrites the previous ones. Then, once the
Prefix-SID collision is fixed in the configuration, the overwritten
Prefix-SID isn't reinstalled since it's already marked as installed
and it didn't change. To prevent such inconsistency from happening,
add a safeguard in the SPF code to detect Prefix-SID collisions and
handle them appropriately (i.e. log a warning + ignore the Prefix-SID
Sub-TLV since it's already in use by another prefix). That way,
once the configuration is fixed, no Prefix-SID label entry will be
missing in the LFIB.
Reported-by: Emanuele Di Pascale <emanuele@voltanet.io> Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Donald Sharp [Wed, 4 Nov 2020 16:48:49 +0000 (11:48 -0500)]
zebra: Rework code to make SA happy
Clan SA was saying:
./zebra/zebra_vty_clippy.c: In function ‘show_route’:
zebra/zebra_vty.c:1775:4: warning: ‘zvrf’ may be used uninitialized in this function [-Wmaybe-uninitialized]
do_show_ip_route_all(vty, zvrf, afi, !!fib, !!json, tag,
^
I do not see a way that zvrf could ever be uninited in the code path
but rearrange the code a tiny bit to make it happier.
projects / mirror / frr.git / log