It's a new-ish Checkpoint firewall, but I have no idea what code it is running. I was sent a snippet of their logs and I see a lot of the following:
OSPF LSA: different instance of lsa on retranmission list received: type RTR OSPF LSA: different instance of lsa on retranmission list received: type NTW I verified the the firewall *is* setting the LR-bit indicating that it is capable of OOB Resync. The RFC says that if the LR-bit is set in the hello messages, DBD packets should have the R-bit set during an OOB Resync. If those DBD packets do not have the R-bit set, the receiving device is supposed to drop them and log a sequence number mismatch. I suspect that is what happened here. It looks like "something" is causing their database to become unsynchronized and the firewall triggers an OOB Resync but then doesn't set the R-bit in the DBD packets. I'm not exactly sure, though. That's just what I'm thinking, so far. On Sat, Feb 9, 2013 at 3:25 AM, Phil Mayers <[email protected]> wrote: > On 02/09/2013 05:05 AM, John Neiberger wrote: > > 1. What triggered the OOB resync in the first place? >> > > I assume there is nothing in the logs for the device, or adjacent devices, > at the time? > > > 2. If the firewall isn't capable of doing OOB resync, why would it send >> DBD >> packets with the R-bit set? (Perhaps it is capable and just wasn't >> previously setting the LR-bit in hello messages) >> > > You didn't specify the model of the firewall and it's software version, so > it's difficult to say. > > ______________________________**_________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/**mailman/listinfo/cisco-nsp<https://puck.nether.net/mailman/listinfo/cisco-nsp> > archive at > http://puck.nether.net/**pipermail/cisco-nsp/<http://puck.nether.net/pipermail/cisco-nsp/> > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
