Got the results back and this fixes all the new OSPFv3 issues.
(Updated the doc at
https://drive.google.com/file/d/0B9on53yIVRYVNnQzY3lBbGI1WEU/view?usp=sharing
if someone wants to look at the details)
Thanks Michael for the fix and Paul for a quick acceptance into the
approved list.
- Martin
On 30 Sep 2015, at 8:54, Paul Jakma wrote:
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
