Ondřej Surý [Mon, 15 Feb 2021 07:43:26 +0000 (08:43 +0100)]
doc: Use dpkg-buildpackage to build packages (add note about debuild)
The debuild command fails when we are doing source package only build
because it expects the arch-dependent .changes file to be present. Thus
in the instructions we switch to using dpkg-buildpackage directly and
add a note about using debuild in more complicated scenarios.
Ondřej Surý [Mon, 15 Feb 2021 07:40:08 +0000 (08:40 +0100)]
doc: Add instructions on how to build only source packages
In the CI, it's better to build the source package only once and then
instead of checking out the whole repository, only distribute the source
packages to the individual jobs.
Philippe Guibert [Wed, 30 Jun 2021 12:07:52 +0000 (14:07 +0200)]
bgpd: nht unresolved with global address next-hop
When bgp peers with ipv6 link local addresses, it may receive a
BGP update with next-hop containing both LL and GA information.
By default, nexthop tracking applies to GA, and ignores presence
of LL, when both addresses are present. This is a problem for
resolving GA as next-hop as the next-hop information can be solved
by using the LL address only.
The solution consists in defaulting the nexthop ipv6 choice to LL
when available, and moving back to GA if a route-map is locally
configured at inbound.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
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>
Christian Hopps [Tue, 29 Jun 2021 22:03:31 +0000 (22:03 +0000)]
tests: collect support bundle data in parallel, fix bugs
Speedup (large topo): OLD: ~6 minutes NEW: ~1 second.
(when paired with common_config.py changes)
- Collect each "proc" support in parallel
- For each "proc" only call vtysh once with all commands
Bug fixes:
- output was broken, a dump of python "repr" format of str.
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.
projects / matthieu / frr.git / log