I've pushed that patch to 'accepted'.
I'll wait to hear the results of Martin's compliance run and if that is
good I will push the round-3 accepted over to master.
Thanks,
Paul
On Tue, 29 Sep 2015, Martin Winter wrote:
Michael,
your patch fixes at least some of the issues (maybe all). Thanks.
I’m rerunning the full OSPFv3 suite again with the patch and will know
the details in another 24hrs.
But looking good…
For Paul and others questioning why this happens
$ grep libospf.h *
ospf6d.h:#include "libospf.h"
ospf6_network.c:#include "libospf.h"
So it seems ospf6d uses libospf.h.
Now if this is a mistake, bad design or ok, is up to the community
to decide.
- Martin
On 29 Sep 2015, at 6:06, Michael Rossberg wrote:
Martin,
I did not have the chance to look at v6. Could you have a look whether the
attached patch
fixes the behaviour?
Thanks
Michael
On 29 Sep 2015, at 13:23, Martin Winter <[email protected]> wrote:
Found the bad commit. This is the source of at least 3 of the OSPFv3 failures
(I have not verified it for all to save time)
commit 2ef762ed9b88e5745012c5829f8f526c95443ddf
Author: Michael Rossberg <[email protected]>
Date: Mon Jul 27 07:56:25 2015 +0200
ospfd: Fast OSPF convergence
When considering small networks that have extreme requirements on
availability and thus convergence delay, the timers given in the OSPF RFC
seem a little “conservative”, i.e., the delay between accepted LSAs and the
rate at which LSAs are sent. Cisco introduced two commands 'timers throttle
lsa all’ and 'timers lsa arrival’, which allow operators to tune these
parameters.
I have been writing a patch to also support 'timers lsa arrival’ fully and
‘timers throttle lsa all’ (without the throttling part) also in quagga.
Not sure how this affects OSPFv3. (Maybe lib/libospf.h is used by OSPFv3 as
well?)
I’ve added one of the failing tests (ANVL-OSPFV3-8.9) to the limited set which
I run on every commit and restarted the test for proposed and accepted branch.
(see https://ci1.netdef.org/browse/QUAGGA-QMASTER2/latest for results on
accepted/3 branch)
- Martin Winter
[email protected]
On 27 Sep 2015, at 3:34, Martin Winter wrote:
Full compliance run is done for the accepted patches @ commit d3ac733
Most of it looks the same as the last release.
With the exception of OSPFv3, approx 4 results have changed:
- new ISIS Ipv6 failures: ISISV6-26.2 & ISISV6-28.3
- OSPF-12.4 now unpredictable (inconsistent results, was good before)
- OSPF-24.6 now fixed.
I’ll analyze them on monday to make sure they are real issues.
OSPF IPv6 on the other side looks much worse.
Comparing to Git master @ 6064613 (2015-08-04), we have approx 20 new
failures. (and I have not yet looked at the specifics either)
Here is a quick list of the tests which now fail:
Quagga Git Master Git Master Git Master Git
Accepted
0.99.24 Round-3
f191f1e f1fc327 55cfa2f 6064613 d3ac733
2015-03-02 2015-05-14 2015-06-03 2015-08-04 2015-09-24
ANVL-OSPFV3-8.9 MUST pass pass pass pass
FAILED
ANVL-OSPFV3-16.5 MUST UNPREDICT pass UNPREDICT pass
FAILED
ANVL-OSPFV3-16.14 MUST pass pass pass pass
FAILED
ANVL-OSPFV3-16.15 MUST pass pass pass pass
FAILED
ANVL-OSPFV3-16.16 MUST pass pass pass pass
FAILED
ANVL-OSPFV3-17.1 MUST UNPREDICT pass pass pass
FAILED
ANVL-OSPFV3-18.1 MUST pass pass pass pass
FAILED
ANVL-OSPFV3-18.23 MUST pass pass pass pass
FAILED
ANVL-OSPFV3-20.1 MUST pass pass pass pass
FAILED
ANVL-OSPFV3-24.1 MUST pass pass pass pass
FAILED
ANVL-OSPFV3-25.3 MUST pass pass pass pass
FAILED
ANVL-OSPFV3-25.4 MUST pass pass pass pass
FAILED
ANVL-OSPFV3-26.5 MUST pass pass pass pass
FAILED
ANVL-OSPFV3-26.10 MUST pass pass pass pass
FAILED
ANVL-OSPFV3-28.6 MUST pass pass pass pass
FAILED
ANVL-OSPFV3-41.2 MUST UNPREDICT UNPREDICT pass pass
FAILED
ANVL-OSPFV3-43.6 MUST pass pass pass pass
FAILED
ANVL-OSPFV3-43.7 MUST pass pass pass pass
FAILED
ANVL-OSPFV3-43.8 MUST pass pass pass pass
FAILED
ANVL-OSPFV3-43.9 MUST pass pass pass pass
FAILED
For details (and some basic test description), see PDF on
https://drive.google.com/file/d/0B9on53yIVRYVNnQzY3lBbGI1WEU/view?usp=sharing
I’ll do some git bisect on monday and look into the details, but if someone
wants to
guess which commits in the accepted branch may break OSPFv3, then please let me
know.
- Martin Winter
[email protected]
On 26 Sep 2015, at 1:31, Martin Winter wrote:
I’ve noticed that Paul (I assume) started a branch for accepted and rejected
patches.
I’ve added the branch with the accepted commits to the CI system
https://ci1.netdef.org/browse/QUAGGA-QMASTER and then select the branch next to
title.
You should see the “volatile-patch-tracking-3-accepted” branch there.
Whenever a new commit is pushed, it should get kicked off automatically. (But
with some delay
as our git mirror only syncs up to savannah every hour).
At the current time (at commit d3ac733) it passes the build and the basic
compliance tests.
Disclaimer: the —enable-werror is NOT yet pushed and not specifically selected
in my build,
so warnings won’t fail the build at this time.
As it currently passes the basic checks, I’ve kicked off a full RFC compliance
run for it.
I will have the results by Sunday evening latest.
Regards,
Martin Winter
[email protected]
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
"A complex system that works is invariably found to have evolved from a simple
system that worked."
-- John Gall, _Systemantics_
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
