Donald Sharp [Mon, 4 Oct 2021 12:37:16 +0000 (08:37 -0400)]
ospf6d: Ensure expire thread is properly stopped
The lsa->expire thread is for keeping track of when we
are expecting to expire(remove/delete) a lsa. There
are situations where we just decide to straight up
delete the lsa, but we are not ensuring that the
lsa is not already setup for expiration.
In that case just stop the expiry thread and
do the deletion.
Additionally there was a case where ospf6d was
just dropping the fact that a thread was already
scheduled for expiration. In that case we
should just setup the timer again and it will
reset it appropriately.
Fixes: #9721 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Low overhead bgp-evpn TPs have been added which push data out in a binary
format -
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
root@switch:~# lttng list --userspace |grep "frr_bgp:evpn"
frr_bgp:evpn_mh_nh_rmac_zsend (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint)
frr_bgp:evpn_mh_nh_zsend (loglevel: TRACE_INFO (6)) (type: tracepoint)
frr_bgp:evpn_mh_nhg_zsend (loglevel: TRACE_INFO (6)) (type: tracepoint)
frr_bgp:evpn_mh_vtep_zsend (loglevel: TRACE_INFO (6)) (type: tracepoint)
frr_bgp:evpn_bum_vtep_zsend (loglevel: TRACE_INFO (6)) (type: tracepoint)
frr_bgp:evpn_mac_ip_zsend (loglevel: TRACE_INFO (6)) (type: tracepoint)
root@switch:~#
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
In addition to the tracepoints a babeltrace python plugin for pretty
printing (binary data is converted into grepable strings). Sample usage -
frr_babeltrace.py trace_path
David Lamparter [Mon, 27 Sep 2021 08:33:33 +0000 (10:33 +0200)]
pimd: fix UAF/heap corruption in BSM code
This `XFREE()` call is in plainly in the wrong spot. `rp_all` (the
224.0.0.0/4 entry) isn't supposed to be free'd ever, and the
conditional above makes quite clear that it remains in use.
It may be possible to exploit this as a heap corruption bug, maybe even
as RCE. I haven't tried; I randomly noticed this while working on the
BSM code. Luckily this code is only run by the CLI for the clear
command, so the surface is very small.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Donald Sharp [Sun, 26 Sep 2021 23:36:03 +0000 (19:36 -0400)]
bgpd: Don't lookup paf structure get straight to the point
The paf data structure is stored based upon an internal
bgp enum. The code is looking over all AFI/SAFI's and
doing a paf_af_find which then calls afindex to find
the right paf structure. Let's just loop over the
peer->peer_af_array[] and cut straight to the chase.
Under some loads the paf_af_find was taking up 6%
of the run time. This removes it entirely.
Converting bgp_dest_lock_node/bgp_dest_unlock_node to non-inlined function
because LTTng can't work properly with inlined and the compiler does not like
it.
Not sure how it would be with the performance, but let's see.
Louis Scalbert [Thu, 10 Jun 2021 09:30:05 +0000 (11:30 +0200)]
ospf6d: reset areas and redistribution at router-id modification
The ospf6 router-id is provided by order of preference by:
ospf6d itself if the "ospf6 router-id X.X.X.X" command is set.
- zebra. If the "ip router-id X.X.X.X" zebra command is set, the
configured IP is provided as the ID or alternatively the highest
loopback IPv4 address or else the highest interface IPv4 address.
The running ospf6 router-id is stored in ospf6->router-id.
ospf6->router-id can change in the following conditions:
- A configuration change provides a new router-id value according to
the above rules. ospf6->router-id is updated to the new value if
there is no adjacency in FULL state. Otherwise, the ospf6d process
must be restarted to take the new router-id into account.
- On startup of both zebra and ospf6d, if ospf6d has not yet received a
valid router-id, ospf6d->router-id is set to 0 (i.e. 0.0.0.0). Then,
zebra notifies ospf6d that the router-id is available.
At ospf6->router-id, the current behavior of ospf6d is the following:
- The self generated LSAs that refer to the previous router-id as the
advertising router are kept.
- Self generated LSAs are created with router-id value.
- LSAs from the redistribution that refer to the previous router-id are
kept and no new redistribution LSAs are created.
As a consequence, the routers in the ospf6 areas will get incorrect
LSAs and might not be able to install prefixes of those LSAs into their
RIB.
This fix solves this issue by resetting the areas and the redistribution
when ospf6->router-id updated.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
David Lamparter [Wed, 22 Sep 2021 09:59:08 +0000 (11:59 +0200)]
doc/workflow: prefer typesafe containers
The typesafe containers have been around for quite a while now and
haven't gone up in a blaze of flames, so let's add a "strong
recommendation" to use them for new code and refactors.
For the nhrpd custom lists I'm already working to remove them; meanwhile
the old skiplists are primarily used in RFAPI (4 users outside of that),
so those could be next.
What remains are the old `list_*` and `hash_*`, which have >300 and >100
users respectively, making them a much harder problem to tackle. And
the new hash implementation doesn't have the same level of
debug/introspection yet (it's on my TODO.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Philippe Guibert [Wed, 22 Sep 2021 07:59:44 +0000 (09:59 +0200)]
bgpd: add carriage return when dumping tags from all evpn rds
following command: show bgp l2vpn evpn rd all tags
does not append rd contexts one after the other
before:
dut-vm# show bgp l2vpn evpn rd all tags
Network Next Hop In tag/Out tag
Route Distinguisher: 65000:999
*> [5]:[0]:[24]:[10.40.1.0]
10.209.36.1 Route Distinguisher: 65000:1000
*> [5]:[0]:[24]:[10.40.1.0]
10.209.36.1
Displayed 2 out of 2 total prefixes
after:
dut-vm# show bgp l2vpn evpn rd all tags
Network Next Hop In tag/Out tag
Route Distinguisher: 65000:999
*> [5]:[0]:[24]:[10.40.1.0]
10.209.36.1
Route Distinguisher: 65000:1000
*> [5]:[0]:[24]:[10.40.1.0]
10.209.36.1
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
currently, has_valid_label is only used to check need to print debug,
but if route has normal nexthops and mpls nexthops, label information
will be printed even for normal nexthops.
ospf6d: implement Type-7 default routes for NSSA areas
Add the "default-information-originate" option to the "area X nssa"
command. That option allows the origination of Type-7 default routes
on NSSA ABRs and ASBRs.
ospf6d: don't generate Type-7 LSA for route created by "default-information-originate"
The route created by the "default-information-originate" command
isn't a regular external route. As such, an NSSA ABR shouldn't
originate a corresponding Type-7 LSA for it (there's a separate
configuration knob to generate Type-7 default routes).
While here, fix a small issue in ospf6_asbr_redistribute_add()
where routes created by "default-information-originate" were being
displayed with an incorrect "unknown" type.
Fix wrong comparison since route->path.metric_type is always set
to either 1 or 2. The OSPF6_PATH_TYPE_EXTERNAL2 constant, whose
value is 4, refers to a route type so its usage was incorrect here.
ospfd: rename the "graceful-restart helper-only" command
Considering that both the GR helper mode and restarting mode can be
enabled at the same time, the "graceful-restart helper-only" command
can be a bit misleading since it implies that only the helper mode
is enabled. Rename the command to "graceful-restart helper enable"
to clarify what the command does.
Start a deprecation cycle of one year before removing the original
command
Mark Stapp [Tue, 21 Sep 2021 20:33:28 +0000 (16:33 -0400)]
zebra: stop asking for AF_BRIDGE interface info twice
There were two identical blocks of code run at init time that
requested info about AF_BRIDGE - don't see any reason to do that
twice, so remove one block.
ospf6d: rename the "graceful-restart helper-only" command
Considering that both the GR helper mode and restarting mode can be
enabled at the same time, the "graceful-restart helper-only" command
can be a bit misleading since it implies that only the helper mode
is enabled. Rename the command to "graceful-restart helper enable"
to clarify what the command does.
After `<daemon_name> is not running` message vtysh does not return
error. For example if you disable ospf in `/etc/frr/daemons` and run
`vtysh -c configure -c "router ospf"` it prints the message to stderr,
but returns 0.
This commit will make vtysh return error when not in interractive mode.
But if you run commands from vtysh, you will still be able to enter
views and exit them if daemon is not running.
Donald Sharp [Fri, 17 Sep 2021 09:41:37 +0000 (05:41 -0400)]
pimd: Prevent uninited usage of nexthop
pim_msdp_peer_rpf_check creates an nexthop to do
a rpf search against and doesn't initialize it
sucht that the pim_nexthop_lookup function is
making decisions against the nexthop just
created that was uninitialized.
Donald Sharp [Tue, 21 Sep 2021 11:52:54 +0000 (07:52 -0400)]
ospf6d: Use appropriate integer size and more context for reason strings
The ospfv3 spf reason strings are just presented internally in the code
without any real context. Give a tiny bit more useful information for
the developer and convert the integer to a uint32_t
Igor Ryzhov [Wed, 15 Sep 2021 15:22:47 +0000 (18:22 +0300)]
vtysh: remove sorting of vrf node commands
A simple strcmp-based sorting done by `config_add_line_uniq` breaks the
correct advanced sorting of static routes done by staticd. We don't
actually need to check vrf node commands for uniqueness as all commands
are daemon specific, so let's use simple `config_add_line` that doesn't
sort commands.
ospf6d: rework filtering commands to be in line with ospfd
Issue #9535 describes how the export-list/import-list commands work
differently on ospfd and ospf6d.
In short:
* On ospfd, "area A.B.C.D export-list" filters which internal
routes an ABR exports to other areas. On ospf6d, instead, that
command filters which inter-area routes an ABR exports to the
configured area (which is quite counter-intuitive). In other words,
both commands do the same but in opposite directions.
* On ospfd, "area A.B.C.D import-list" filters which inter-area
routes an ABR imports into the configured area. On ospf6d, that
command filters which inter-area routes an interior router accepts.
* On both daemons, "area A.B.C.D filter-list prefix NAME <in|out>"
works exactly the same as import/export lists, but using prefix-lists
instead of ACLs.
The inconsistency on how those commands work is undesirable. This
PR proposes to adapt the ospf6d commands to behave like they do
in ospfd.
These changes are obviously backward incompatible and this PR doesn't
propose any mitigation strategy other than warning users about the
changes in the next release notes. Since these ospf6d commands are
undocumented and work in such a peculiar way, it's unlikely many
users will be affected (if any at all).
Philippe Guibert [Tue, 17 Aug 2021 08:56:32 +0000 (10:56 +0200)]
zebra: refresh vxlan evpn contexts, when bridge interface goes up
When using bgp evpn rt5 setup, after BGP configuration has been
loaded, if the user attempts to detach and reattach the bridged
vxlan interface from the bridge, then BGP loses its BGP EVPN
contexts, and a refresh of BGP configuration is necessary to
maintain consistency between linux configuration and BGP EVPN
contexts (RIB). The following command can lead to inconsistency:
ip netns exec cust1 ip link set dev vxlan1000 nomaster
ip netns exec cust1 ip link set dev vxlan1000 master br1000
consecutive to the, BGP l2vpn evpn RIB is empty, and the way to
solve this until now is to reconfigure EVPN like this:
vrf cust1
no vni 1000
vni 1000
exit-vrf
Actually, the link information is correctly handled. In fact,
at the time of link event, the lower link status of the bridge
interface was not yet up, thus preventing from establishing
BGP EVPN contexts. In fact, when a bridge interface does not
have any slave interface, the link status of the bridge interface
is down. That change of status comes a bit after, and is not
detected by slave interfaces, as this event is not intercepted.
This commit intercepts the bridge link up event, and triggers
a check on slaved vxlan interfaces.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Tue, 17 Aug 2021 08:42:51 +0000 (10:42 +0200)]
zebra: handle bridge mac address update in evpn contexts
when running bgp evpn rt5 setup, the Rmac sent in BGP updates
stands for the MAC address of the bridge interface. After
having loaded frr configuration, the Rmac address is not refreshed.
This issue can be easily reproduced by executing some commands:
ip netns exec cust1 ip link set dev br1000 address 2e:ab:45:aa:bb:cc
Actually, the BGP EVPN contexts are kept unchanged.
That commit proposes to fix this by intercepting the mac address
change, and refreshing the vxlan interfaces attached to te bridge
interface that changed its MAC address.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Donald Sharp [Thu, 16 Sep 2021 19:12:13 +0000 (15:12 -0400)]
tests: Do not do a initial_timeout of 2 seconds for verify_bgp_rib
A bunch of tests have this pattern:
a) Install a new prefix into bgp
b) Run this loop:
foreach (router in topology) {
verify_bgp_rib(router)
}
This is to ensure that the prefix is actually disseminated.
The problem with this, of course, is that a wait of 2 seconds
for every item in that loop makes no sense. As that the initial
router verification of it's bgp rib will wait 2 seconds and
all the remaining bgp routers in the topology will have gotten
the data. So we end up waiting a bunch of extra time.
Remove the initial_wait time for verify_bgp_rib. Also
increase the failure wait time to 30 seconds. This is
to give a bigger window for bgp to send it's data for
our test systems that could be under heavy load. In the
normal case tests will never hit this.
projects / matthieu / frr.git / log