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>
Donald Sharp [Wed, 30 Jun 2021 14:25:43 +0000 (10:25 -0400)]
bgpd: Ensure v6 LL address is available before establishing peering
There are startup situations where we will attempt to connect to a remote
peer before bgp has received the v6 LL address. If we do not have this address
we must not allow the connection to come up until we have one available to use
in those situations where we must have a v6 LL address.
ospf6d: route-map config changed, not getting applied on all types of routes
Problem Statement:
==================
when route-map config is changed from permit to deny, it is not getting
applied to both connected and static and vice versa
RCA:
==================
When route-map changes from permit to deny or vice versa, a notification is
sent to ospf6 daemon via ospf6_asbr_routemap_update. In this function, a thread
is scheduled after 5 seconds to apply the route-map changes. In this thread
(ospf6_asbr_routemap_update_timer), only the first type is passed as argument
and only the first type i.e "connected" is passed and hence in callback only
on this type of route route-map gets applied.
Fix:
====
Need to loop through all the route-types in the call back and process
the route-map changes. Added a flag to mark which all route-types needs
to be processed.
Test Executed:
===============
1. Change route-map from permit to deny.
2. Change route-map from deny to permit.
3. Add new route and checked.
4. Verified summarised routes.
Trey Aspelund [Thu, 24 Jun 2021 07:04:52 +0000 (07:04 +0000)]
bgpd: Expand 'bgp default <afi>-<safi>' cmds
Adds new commands to allow a user to default 'default' address-families
to be inherited by all new peers. Previously this was limited to just
ipv4/ipv6 unicast, now the full list is:
---
ipv4-unicast
ipv4-multicast
ipv4-vpn
ipv4-labeled-unicast
ipv4-flowspec
ipv6-unicast
ipv6-multicast
ipv6-vpn
ipv6-labeled-unicast
ipv6-flowspec
l2vpn-evpn
---
Introduces bgp->default_af to selectively enable various default
afi/safis to be inherited by new peers.
Makes default_af flag logic consistent for all address-families, i.e.
instead of a "no default" flag for ipv4 and a "default" flag for ipv6,
just use "default" for both and make it true for ipv4 by default.
Removes old BGP_FLAG_NO_DEFAULT_IPV4 and BGP_FLAG_DEFAULT_IPV6, and
cleans up bgp->flags bit definitions to avoid gaps for unused bits. Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Yash Ranjan [Mon, 3 May 2021 11:46:41 +0000 (04:46 -0700)]
ospf6d: "clear ipv6 ospf6 process" command
Adding the "clear ipv6 ospf6 command" . It resets
the ospfv3 datastructures and clears the database
as well as route tables. It resets the neighborship
by restarting the interface state machine.
If the user wants to change the router-id, this
command updates the router-id to the latest static
router-id and starts the neighbor formation with
the new router-id.
Igor Ryzhov [Fri, 25 Jun 2021 11:59:28 +0000 (14:59 +0300)]
ospf6d: fix duplicated packet read
When OSPFv3 router is configured in both default and non-default VRFs,
every packet destined to a non-default VRF is read twice. This makes it
impossible to establish neighborship because every DbDesc packet is
treated as duplicated and we end up infinitely exchanging DbDescs.
We should drop packets received in the default VRF if an interface we
received it on is bound to another VRF.
Rafael Zalamena [Fri, 25 Jun 2021 19:00:09 +0000 (16:00 -0300)]
pimd: make function names consistent
Rename functions (`pim_msdp_peer_new` => `pim_msdp_peer_add` and
`pim_msdp_peer_do_del` => `pim_msdp_peer_del`) to keep consistency and
update the `pim_msdp_peer_add` documentation to tell users that this is
also used for non meshed group peers.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Christian Hopps [Sat, 19 Jun 2021 12:09:06 +0000 (12:09 +0000)]
tests: apply KISS to retry fixture
This python fixture was way too complex for what is needed.
Eliminate gratuitous options/over-engineering:
- Change from non-deterministic `wait` and `attempts` to a single
`retry_timeout` value. This is both more deterministic, as well as
what the user should actually be thinking about.
- Use a fixed 2 second pause between executing the wrapped function
rather than a bunch of arbitrary choices of 2, 3 and 4 seconds
spread all over the test code.
- Get rid of the multiple variables for determining what "Positive" and
"Negative" results are. Instead just implement what all the user code
already wants, i.e., boolean False or a str (errormsg) means
"Negative" result otherwise it's a "Positive" result.
- As part of the above the inversion logic is much more comprehensible
in the fixture code (and more correct to boot).
David Lamparter [Tue, 13 Apr 2021 18:57:25 +0000 (20:57 +0200)]
build: add `-Werror` to xrelfo log format warnings
Adding a `\n' should now produce a warning. Controlled by `-Werror` so
if you're doing a dev build and it's warning about some `prefix2str`
that should be converted to `%pFX`, you can turn off `-Werror` to fix it
later like with all other warnings.
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Tue, 13 Apr 2021 18:49:26 +0000 (20:49 +0200)]
lib: try CLOCK_THREAD_CPUTIME_ID
This might be faster if at some point in the future the Linux vDSO
supports CLOCK_THREAD_CPUTIME_ID without making a syscall. (Same
applies for other OSes.)
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Tue, 13 Apr 2021 18:38:09 +0000 (20:38 +0200)]
lib: make cputime checks runtime options (v2)
...really no reason to force this into a compile time decision. The
only point is avoiding the getrusage() syscall, which can easily be a
runtime decision.
[v2: also split cputime & walltime limits]
Signed-off-by: David Lamparter <equinox@diac24.net>
Donald Sharp [Tue, 23 Mar 2021 12:48:54 +0000 (08:48 -0400)]
tools: limit bgp route-maps to direct changes only
When using frr-reload.py to modify a bgp neighbors route-map
the code was doing this:
a) deleting the previous route-map: `no neighbor XX route-map YY (in|out)`
b) Adding the new route-map back in `neighbor XX route-may ZZ (in|out)`
Now imagine that we have an outgoing route-map that we are changing
and the reload is large because of a large number of lines in frr.conf
Item (a) will happen. BGP will immediately start sending all local
routes. At some point in time in the future (b) will be applied.
This of course causes a withdraw but for a short amount of time we
are leaking unintended routes. This is bad for several reasons
not 1) route churn upstream, 2) we might influence traffic to go the
wrong way. 3) if upstream has a maximum-prefix command the routes
being sent might trip its circuitry and shutdown the peer entirely
not even allowing you to get to (b).
Ticket: #2589685 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Igor Ryzhov [Tue, 22 Jun 2021 21:27:55 +0000 (00:27 +0300)]
isisd: fix interface ldp-sync configuration
There are two checks done when configuring ldp-sync on an interface:
- interface is not a loopback
- interface is in the default VRF
Both checks are incorrectly done using the operational data.
The second check can be done using only config data - do that.
The first check can't be done using only configurational data, but it's
not necessary. LDP sync code doesn't operate on loopback interfaces
already. There's no harm in allowing this to be configured.
projects / mirror_frr.git / log