On Fri, 1 Apr 2016 08:23:34 -0400 Donald Sharp <sha...@cumulusnetworks.com> wrote:
> My understanding - > > Paul and I are working through a bunch of issues in the background. > I'm slammed getting a new release out so am pretty busy right now. > The take-3 branch has been rebased to the latest release already. > Paul was going to take a schwag at fixing up a couple of the issues > he had with the branch( Is my memory correct here Paul? ) > > I believe the nhrp code has already been rebased ontop of the take-3 > branch as well. I was looking at the just now reported multipath issue. And while debugging that I noticed that the take-3 branch next hop tracking probably has some issues. Running it under valgrind reports (with the simple test case of two static routes; same prefix, different nexthop): ==5157== Conditional jump or move depends on uninitialised value(s) ==5157== at 0x52BE36D: family2afi (prefix.c:217) ==5157== by 0x131AC3: zebra_lookup_rnh (zebra_rnh.c:119) ==5157== by 0x131E17: zebra_deregister_rnh_static_nh (zebra_rnh.c:208) ==5157== by 0x131C50: zebra_deregister_rnh_static_nexthops (zebra_rnh.c:239) ==5157== by 0x11F609: rib_unlink (zebra_rib.c:1857) ==5157== by 0x11F609: rib_process (zebra_rib.c:1514) ==5157== by 0x11F609: process_subq (zebra_rib.c:1541) ==5157== by 0x11F609: meta_queue_process (zebra_rib.c:1582) ==5157== by 0x52D5EF1: work_queue_run (workqueue.c:304) ==5157== by 0x52C067A: thread_call (thread.c:1266) ==5157== by 0x114F75: main (main.c:485) ==5157== Use of uninitialised value of size 8 ==5157== at 0x131AC6: zebra_lookup_rnh (zebra_rnh.c:119) ==5157== by 0x131E17: zebra_deregister_rnh_static_nh (zebra_rnh.c:208) ==5157== by 0x131C50: zebra_deregister_rnh_static_nexthops (zebra_rnh.c:239) ==5157== by 0x11F609: rib_unlink (zebra_rib.c:1857) ==5157== by 0x11F609: rib_process (zebra_rib.c:1514) ==5157== by 0x11F609: process_subq (zebra_rib.c:1541) ==5157== by 0x11F609: meta_queue_process (zebra_rib.c:1582) ==5157== by 0x52D5EF1: work_queue_run (workqueue.c:304) ==5157== by 0x52C067A: thread_call (thread.c:1266) ==5157== by 0x114F75: main (main.c:485) Also to me the some of the changes to RIB_ENTRY_NEXTHOPS_CHANGED handling in the rib_process() look redundant. And probably not worth adding. E.g. the flag checking before calling nexthop_active_update(rn,rib,0) is unneeded because the flag is reset in the beginning of the loop. Cheers, Timo Cheers, Timo _______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev