It's unclear to me why an NHT should *ever* trigger a state machine change. At this point, I'm more comfortable with going back to not changing BGP FSM state than introducing the three new FSM changes you have in the code...
Why do you think the state transitions are are appropriate based on an NHT_Update? What are the real sources of NHT_Updates? If BGP itself, as the prior case, these should certainly be ignored. Lou On 9/30/2016 9:41 AM, Paul Jakma wrote: > Hi Lou, > > On Fri, 30 Sep 2016, Paul Jakma wrote: > >> On Thu, 29 Sep 2016, Lou Berger wrote: >> >>> looks like the NHT code is generating an event into the state machine >>> that it shouldn't be. I removed this and checked it into my work >>> area. See >>> >>> https://github.com/LabNConsulting/quagga-vnc/commit/7162337f9261b91056b95a673a54ad595aef3e5f >>> Kudos to Martin for logs/pcaps/discussion and the system that id'ed this >>> issue and will verify the fix. >> Yeah, I'd come to the same conclusion yesterday with my own test-case (again >> based on logs and pcaps from Martin) and emailed him. :) > So, I have: > > http://git.savannah.gnu.org/cgit/quagga.git/commit/?id=26943e36 > > The whole bgp_fsm_nht_update can just be removed, and this second > NHT-dedicated, mini-sub-FSM removed and the event handled via the main > FSM. > > Indeed, is it even necessary to tickle Active/Connect connections to > make them reconnect cause of an NHT event? In which case, the fix is > just removing code. > > ? > > regards, _______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
