On Mon, Apr 13, 2020 at 02:08:31PM +0200, Remi Locherer wrote: > On Mon, Apr 13, 2020 at 12:05:10PM +0100, Richard Chivers wrote: > > Thanks. Please see my comments below. > > > > On Mon, 13 Apr 2020, 10:18 Remi Locherer, <remi.loche...@relo.ch> wrote: > > > > > Hi Richard, > > > > > > On Mon, Apr 13, 2020 at 08:38:31AM +0100, Richard Chivers wrote: > > > > We have been having a strange issue, whereby OSPF stops updating > > > properly. > > > > > > > > We can see an entry for an ip route in the database but it is not in the > > > > kernel routing table, and when it is the DR, other routers then do not > > > have > > > > the route at all. > > > > > > > > We are seeing this across multiple boxes. We have 10+ ospf speakers, and > > > > seem to see the issue at different times. > > > > > > > > The problem starts with: > > > > > > > > ospfd[6960]: recv_db_description: neighbor ID x.x.x.x: seq num mismatch, > > > > bad flags > > > > > > The neighbor sent a db desc with the master flag set differently than what > > > this ospfd instance recorded before for that particular neighbor. > > > > > > See 2nd last item on page 100 of RFC 2328: > > > https://tools.ietf.org/html/rfc2328#page-100 > > > > > > Thanks, should the routers just recover then from this scenario even if it > > was happening due to lost packets, CPU pause etc. > > I think so. But it may take quite a while. It might also be an bug in ospfd > or in another implementation.
Since this issues happen with 5.8 and 6.4 ospfd I would suggest to update to at least 6.6 (especially the 5.8). IIRC there was some issue with ospfd neighbor selection that caused troubles when sessions flapped. This was fixed some time ago but I doubt 5.8 has that fix in. -- :wq Claudio
