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]
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
