Christian Hopps [Mon, 30 Oct 2023 07:37:52 +0000 (03:37 -0400)]
tests: add gdb integration with valgrind
Allows you to run daemons under valgrind integrated with gdb. When daemons are
run with the ``--gdb-daemons/--gdb-routers`` options they will be wired up to
valgrind using vgdb (valgrind tool) so gdb will stop when valgrind errors are
encountered.
Donald Sharp [Sat, 28 Oct 2023 14:03:39 +0000 (10:03 -0400)]
zebra: Add encap type when building packet for FPM
Currently in the single nexthop case w/ evpn sending
down via the FPM the encap type is not being set
for the nexthop.
This looks like the result of some code reorg for the
nexthop happened but the fpm failed to be accounted for.
Let's just move the encap type encoding to where it
will happen.
'detail' and 'josn' keyword is given as an optional parameter
for cli arguments. Hence 'detail' keyword was consider as a
pbr 'name' for "show pbr map detail json" command.
Donatas Abraitis [Thu, 26 Oct 2023 11:56:52 +0000 (14:56 +0300)]
bgpd: Enable `enforce-first-as` by default
It's been for a while disabled by default, but this seems reasonable to flip it.
We had `bgp enforce-first-as` as a global BGP knob to enable/disable this
behavior globally, later we introduced `enforce-first-as` per neighbor, with disabled
by default. Now let's enable this by default by bringing a global `bgp enforce-first-as`
command back.
If the interface type is point-
to-multipoint or the interface is in the state Loopback, the
global scope IPv6 addresses associated with the interface (if any)
are copied into the intra-area-prefix-LSA with the PrefixOptions
LA-bit set, the PrefixLength set to 128, and the metric set to 0.
Donald Sharp [Tue, 24 Oct 2023 20:14:40 +0000 (16:14 -0400)]
bgpd: combine import_check_table and nexthop_check_table
In zebra, the import check table and the nexthop check tables
were combined. This leaves an issue where when bgp happens
to have a tracked address in both the import check table
and the nexthop track table that are the same address.
When the the item is removed from one table the call
to remove it from zebra removes tracking for the other
table.
Combine the two tables together and keep track where
they came from for processing in bgpd.
There is no command to choose to send or not the bgp4-mibv2 traps.
Since the MIB bgp4-mibv2 notification are redundant with MIB RFC4273
we added a command:
- [no] bgp snmp traps bgp4-mibv2
By default, the bgp4-mibv2 traps will be disabled, to prevent from
redundancy.
This commit add the support of traps for bgp4-mibv2.
It is conformant to draft-ietf-idr-bgp4-mibv2-11.
The following traps are supported:
- bgp4V2EstablishedNotification
- bgp4V2BackwardTransitionNotification
There is no cli command to prevent the router to send traps
implemented in the rfc4273. If not done, when introducing
the traps from bgp4v2mib, traps will be send for each of
the two mibs: there will be redundancy in the sent information.
Add a new command:
- [no] bgp snmp traps rfc4273
Using this command will allow or not the notification of
the following traps:
- bgpEstablishedNotification
- bgpBackwardTransNotification
Donatas Abraitis [Mon, 23 Oct 2023 20:34:10 +0000 (23:34 +0300)]
bgpd: Check mandatory attributes more carefully for UPDATE message
If we send a crafted BGP UPDATE message without mandatory attributes, we do
not check if the length of the path attributes is zero or not. We only check
if attr->flag is at least set or not. Imagine we send only unknown transit
attribute, then attr->flag is always 0. Also, this is true only if graceful-restart
capability is received.
Thread 1 "bgpd" received signal SIGSEGV, Segmentation fault.
0x00005555556e37be in route_set_aspath_prepend (rule=0x555555aac0d0, prefix=0x7fffffffe050,
object=0x7fffffffdb00) at bgpd/bgp_routemap.c:2282
2282 if (path->attr->aspath->refcnt)
(gdb)
```
Donald Sharp [Thu, 19 Oct 2023 20:38:12 +0000 (16:38 -0400)]
zebra: Allow longer prefix matches for nexthops
Zebra currently does a shortest prefix match for
resolving nexthops for a prefix. This is typically
an ok thing to do but fails in several specific scenarios.
If a nexthop matches to a route that is not usable, nexthop
resolution just gives up and refuses to use that particular
route. For example if zebra currently has a covering prefix
say a 10.0.0.0/8. And about the same time it receives a
10.1.0.0/16 ( a more specific than the /8 ) and another
route A, who's nexthop is 10.1.1.1. Imagine the 10.1.0.0/16
is processed enough to know we want to install it and the
prefix is sent to the dataplane for installation( it is queued )
and then route A is processed, nexthop resolution will fail
and the route A will be left in limbo as uninstallable.
Let's modify the nexthop resolution code in zebra such that
if a nexthop's most specific match is unusable, continue looking
up the table till we get to the 0.0.0.0/0 route( if it's even
installed ). If we find a usable route for the nexthop accept
it and use it.
The bgp_default_originate topology test is frequently failing
with this exact problem:
B>* 0.0.0.0/0 [200/0] via 192.168.1.1, r2-r1-eth0, weight 1, 00:00:21
B 1.0.1.17/32 [200/0] via 192.168.0.1 inactive, weight 1, 00:00:21
B>* 1.0.2.17/32 [200/0] via 192.168.1.1, r2-r1-eth0, weight 1, 00:00:21
C>* 1.0.3.17/32 is directly connected, lo, 00:02:00
B>* 1.0.5.17/32 [20/0] via 192.168.2.2, r2-r3-eth1, weight 1, 00:00:32
B>* 192.168.0.0/24 [200/0] via 192.168.1.1, r2-r1-eth0, weight 1, 00:00:21
B 192.168.1.0/24 [200/0] via 192.168.1.1 inactive, weight 1, 00:00:21
C>* 192.168.1.0/24 is directly connected, r2-r1-eth0, 00:02:00
C>* 192.168.2.0/24 is directly connected, r2-r3-eth1, 00:02:00
B>* 192.168.3.0/24 [20/0] via 192.168.2.2, r2-r3-eth1, weight 1, 00:00:32
B 198.51.1.1/32 [200/0] via 192.168.0.1 inactive, weight 1, 00:00:21
B>* 198.51.1.2/32 [20/0] via 192.168.2.2, r2-r3-eth1, weight 1, 00:00:32
Notice that the 1.0.1.17/32 route is inactive but the nexthop
192.168.0.1 is covered by both the 192.168.0.0/24 prefix( shortest match )
*and* the 0.0.0.0/0 route ( longest match ). When looking at the logs
the 1.0.1.17/32 route was not being installed because the matching
route was not in a usable state, which is because the 192.168.0.0/24
route was in the process of being installed.
Igor Ryzhov [Sat, 21 Oct 2023 09:56:49 +0000 (12:56 +0300)]
lib: remove incorrect comment from northbound
This was true when we had only a CLI for configuration. Now mgmtd has a
public frontend interface that can be used by external applications, and
they can send invalid requests that lead to errors.
This is still true for CLI though, so the same comment still stays in
`nb_cli_apply_changes_internal`.
Donatas Abraitis [Fri, 20 Oct 2023 08:59:59 +0000 (11:59 +0300)]
bgpd: Do not suppress conditional advertisement updates if triggered
If we have a prefix-list with one entry, and after some time we append a prefix-list
with some more additional entries, conditional advertisement is triggered, and the
old entries are suppressed (because they look identical as sent before).
Hence, the old entries are sent as withdrawals and only new entries sent as updates.
Force re-sending all BGP updates for conditional advertisement. The same is done
for route-refresh, and/or soft clear operations.
Donald Sharp [Wed, 18 Oct 2023 18:30:03 +0000 (14:30 -0400)]
watchfrr: Extend ignore option to daemon being killed
When testing GR features, it is desired to kill bgp
(or really any daemon )and not immediately have bgp start up again.
Modify the code to not attempt to restart the daemon
by hand to let us developers work when the `watchfrr ignore XXX`
command is issued.
Testing:
watchfrr ignore bgpd
kill -9 bgpd
start bgp by `/usr/lib/frr/watchfrr.sh start bgpd` at some point in time
in the future
leaf-1# show watchfrr
watchfrr global phase: Idle
Restart Command: "/usr/lib/frr/watchfrr.sh restart %s"
Start Command: "/usr/lib/frr/watchfrr.sh start %s"
Stop Command: "/usr/lib/frr/watchfrr.sh stop %s"
Min Restart Interval: 60
Max Restart Interval: 600
Restart Timeout: 90
zebra Up
bgpd Up/Ignoring Timeout
staticd Up
leaf-1#
Louis Scalbert [Tue, 26 Sep 2023 12:29:42 +0000 (14:29 +0200)]
topotests: add bgp_l3vpn_label_export test
There is no test that checks for the label allocation mechanisms
involved when using BGP and/or LDP.
- Some configuration changes are applied in the BGP configuration,
and the impact is checked on the BGP contexts, and on the label
manager.
- The label manager dynamic range is reconfigured, BGP auto mode
is checked against the new range, along with LDP when restarting.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The expected tableVersion is wrong, when checking r1 table.
The tableVersion value increments at each route updates. The
previous commit brought an additional route update with the
'vpn_leak_postchange_all()' call.
Keep the function call, and do not check the table version
in bgp_srv6l3vpn_to_bgp_vrf[2,3] tests.
Fixes: 205b62ffae2c ("bgpd: fix hardset l3vpn label available in mpls pool") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Manuel Schweizer [Wed, 18 Oct 2023 15:11:22 +0000 (17:11 +0200)]
doc: add "enforce-first-as" to BGP doc
With the deprecation of the global "bgp enforce-first-as" command back
in https://github.com/FRRouting/frr/pull/2259 the newly introduced
option to enable that setting on a specific peer was not documented.
This commit adds the necessary documentation and states the command's
default.
Signed-off-by: Manuel Schweizer <manuel.schweizer@cloudscale.ch>
topotests: fix bgp_vpnv[4,6]_per_nexthop prefix not updated
The bgp_vpnv[4,6]_table_check() functions analyze the
expected label value of VPN prefixes present in the BGP table.
However, it doesn't verify if the prefixes exist before doing
this. Consequently, the tests will fail if the prefixes do not
show up immediately.
Ensure that all expected VPN prefixes are present before
executing the function.
Fixes: ae5a6bc1f6ba ("topotests: add bgp mpls allocation per next-hop test") Fixes: 37a02a8dcb0d ("topotests: add bgp_vpnv6 test allocation") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
zebra: add label chunk allocation in the dynamic block range
This commit adds support for the label chunk allocation in
the configured dynamic block range.
An additional check ensures the upper bound does not go
over the upper bound of the dynamic-block.
Otherwise, a chunk is created with the lower bound set
to the first label element available in the defined
range.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Hardset label values (eg. ISIS Segment-routing label blocks,
hardset BGP L3VPN service label) may conflict with label chunks
dynamically allocated by zebra.
Add an optional 'mpls label dynamic-block' command to let the user
define a range that is not in conflict with the hardset values.
Restarting control planes is recommended when dynamic label
chunks are already allocated. Command is aborted when any hardset
label chunks conflict with the dynamic block.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
zebra: fix label allocation when room space before first chunk
After ISIS first allocates a label chunk at [1000;2000],
the '16' label value is not used when BGP tries to
allocate a label chunk in auto mode. This does not happen
when BGP is the only one to do the label allocation.
When a label chunk has been accepted, the next label
request checks if there is room space before the existing
label chunk, and uses the lower label value to 17, and not
16.
Fix this by changing the previous range end 'prev_end' label
value to 15 which is the end of the reserved MPLS label
range.
Fixes: 3c8449794318 ("zebra: label manager should never return a reserved block") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Fri, 29 Sep 2023 15:35:54 +0000 (17:35 +0200)]
bgpd: fix wrong 'pending' labelpool counter value at startup
If BGP starts with a l3vpn configuration, the 'pending' value
of the 'show bgp labelpool summary' command is set to 128,
whereas the 'pending' value is 0 if the l3vpn configuration is
applied after.
with no config at startup:
> show bgp labelpool summary
> Labelpool Summary
> -----------------
> Ledger: 1
> InUse: 1
> Requests: 0
> LabelChunks: 1
> Pending: 0
> Reconnects: 1
When BGP configuration is applied at startup, the label request fails,
because the zapi connection with zebra is not yet up. At zebra
up event, the label request is done again, succeeds, decrements the
'pending_count' value in 'bgp_lp_event_chunk() function, then sets
the 'pending_count' value to the 'labels_needed' value.
This method was correct when label requests were asyncronous: the
'pending_count' value was first set, then decremented. In syncronous
label requests, the operations are swapped.
Fix this by incrementing the expected 'labels_needed' value instead.
Fixes: 0043ebab996e ("bgpd: Use synchronous way to get labels from Zebra") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Wed, 27 Sep 2023 05:58:22 +0000 (07:58 +0200)]
bgpd: fix release label chunk when label pool unused
A label chunk is used by BGP for L3VPN or LU purposes,
by picking up labels from that chunk; but when those
labels are release, the label chunks are never released.
The below configuration sequence shows that the label
chunks are not released.
The '128' value stands for the default label chunk size,
which is not released after unconfiguration.
Fix this by checking after each label release, that
the label chunk is still used. If not, release it.
Reset the 'next_chunksize' value to the default value.
topotests: fix accept_own test, bgp label value conflict with ldp
When configuring manual label value in BGP L3VPN, the label
allocation conflicts with the LDP label pool which is in use.
Choose BGP label values different that the ones from LDP.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Today, BGP uses this value without checks, leading to potential
conflicts with other control planes like LDP. For instance, if
LDP initiates with a label chunk of [16;72] and BGP also uses the
50 label value, a conflict arises.
The 'label manager' service in zebra oversees label allocations.
While all the control plane daemons use it, BGP doesn't when a
hardset label is in place.
This update fixes this problem. Now, when a hardset label is set for
l3vpn export, a request is made to the label manager for approval,
ensuring no conflicts with other daemons. But, this means some existing
BGP configurations might become non-operational if they conflict with
labels already allocated to another daemon but not used.
note: Labels below 16 are reserved and won't be checked for consistency
by the label manager.
Fixes: ddb5b4880ba8 ("bgpd: vpn-vrf route leaking") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
projects / matthieu / frr.git / log