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.
Signed-off-by: Ondřej Surý <ondrej@sury.org>
The Debian autopkgtest would fail with new PAM introduced in Debian bullseye.
Add a little loop to wait a little longer for the changes to propagate.
Signed-off-by: Ondřej Surý <ondrej@sury.org>
Basically, this is handled by JSON-C library. I've compiled with the
latest release of json-c and it works well.
Didn't test with various distribution versions, but this change is kinda
dependend from the json-c lib version the distra has.
Before:
```
"192.168.100.1\/32":[
{
"prefix":"192.168.100.1\/32",
```
After:
```
"192.168.100.1/32":[
{
"prefix":"192.168.100.1/32",
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
New peers should be initialized with a usual max packet size and later
determined on OPEN messages.
Testing with different peers supporting/not supporting extended support.
2021/07/02 13:48:00 BGP: [WEV7K-2GAQ5] u2:s2 send UPDATE len 8991 (max message len: 65535) numpfx 1788
2021/07/02 13:48:03 BGP: [WEV7K-2GAQ5] u3:s3 send UPDATE len 4096 (max message len: 4096) numpfx 809
2021/07/02 13:48:03 BGP: [WEV7K-2GAQ5] u3:s3 send UPDATE len 4096 (max message len: 4096) numpfx 809
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
This should be garuanteed that we create a separate update-group if
bgp max packet size differs.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
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>
Harmonize the code of functions ospf6_asbr_redistribute_disable and
ospf6_asbr_redistribute_reset.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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>
ospf6_router_id_update function is used by ospf6_router_id_update_zebra
to update the running the ospf6 router-id.
This patches makes the functions to (un)configure ospf6 router-id use
the same function as ospf6_router_id_update_zebra.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
---
When a router-id change is notified by zebra to ospf6d, we only take
into account the change if no adjacencies are in Full state.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Speedup (large topo): OLD: ~6 minutes NEW: ~1 second
(when paired with generate_support_bundle.py changes)
- Collect from each node in parallel
Bug fixes:
- sub-directory test name was the same internal pytest function name
for any test, and not the actual test name.
Signed-off-by: Christian Hopps <chopps@labn.net>
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.
Signed-off-by: Christian Hopps <chopps@labn.net>
Example output:
flk# show version
% 2021/06/29 00:25:01.562
FRRouting 8.1-dev-my-manual-build (flk).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
...
Signed-off-by: Christian Hopps <chopps@labn.net>
