Hello list! There is a problem in OSPFv2/v3 lsupdate flooding code triggering incorrect state machine change. The problem is triggered under the following OSPF instability conditions: a) bird falls down to init state b) DR router LSA seqnum immediately increases after that c) some problems (like CoPP/policer/high CPU load) preventing DR to send DBD packets fast. In that case the following can happen: * Our local/remote fsm state is EXCHANGE * Some small number of LSA's are sent (so we have no outstanding LSRequests other than DR router LSA) * DR is a bit slow on sending the next portion * Given router LSA is received via other neighbor (so we have empty LSR list) * We are changing state to FULL while other side is stuck in EXCHANGE state. (So in practice we can end with up to 50% neighbors stuck in EXCHANGE state (from DR point of view) in case of OSPF flapping..)
On 10.9.2013 21:00, Alexander V. Chernikov wrote:
Hello list!
Thank you, Alex! Adding to the main tree. Ondrej
There is a problem in OSPFv2/v3 lsupdate flooding code triggering incorrect state machine change.
The problem is triggered under the following OSPF instability conditions: a) bird falls down to init state b) DR router LSA seqnum immediately increases after that c) some problems (like CoPP/policer/high CPU load) preventing DR to send DBD packets fast.
In that case the following can happen: * Our local/remote fsm state is EXCHANGE * Some small number of LSA's are sent (so we have no outstanding LSRequests other than DR router LSA) * DR is a bit slow on sending the next portion * Given router LSA is received via other neighbor (so we have empty LSR list) * We are changing state to FULL while other side is stuck in EXCHANGE state.
(So in practice we can end with up to 50% neighbors stuck in EXCHANGE state (from DR point of view) in case of OSPF flapping..)
participants (2)
-
Alexander V. Chernikov -
Ondrej Filip