Hi, We have sent the pcap directly for the raw packets.
In terms of the above change, we haven't compiled ospf previously, we will give it a go and see how we get on. Are we ok to clone off the github mirror? Cheers Richard On Tue, May 5, 2020 at 10:22 AM Claudio Jeker <[email protected]> wrote: > On Tue, May 05, 2020 at 10:51:40AM +0200, Claudio Jeker wrote: > > On Tue, May 05, 2020 at 09:07:34AM +0100, Richard Chivers wrote: > > > After some more work this morning we have managed to extract the > > > information from tcpdump of the full LS-Update packet, we couldn't see > it > > > on bsd, but running: > > > > > > tcpdump -v -r ~/Downloads/ospf.pcap on osx did the trick. > > > > > > What we are seeing is that a pair of firewalls are both sending updates > > > like this: > > > > > > 07:16:09.346525 IP (tos 0xc0, ttl 1, id 47473, offset 0, flags [+], > proto > > > OSPF (89), length 1500) > > > x.x.x.x > ospf-dsig.mcast.net: OSPFv2, LS-Update, length 1480 > [len 1672] > > > Router-ID x.x.x.x, Backbone Area, Authentication Type: simple (1) > > > Simple text password: dslkfjld, 1 LSA > > > LSA #1 > > > Advertising Router x.x.x.x, seq 0x8000006e, age 0s, length 1624 > > > Router LSA (1), LSA-ID: x.x.x.x > > > Options: [External] > > > Router LSA Options: [ASBR] > > > Stub Network: 10.128.32.128, Mask: 255.255.255.128 > > > topology default (0), metric 10 > > > Stub Network: 10.128.9.0, Mask: 255.255.255.128 > > > *{ another 50 or so networks here}* > > > > > > Each time we get one of these updates the DR logs the lsa_check: bad > age. > > > > > > Another 5 or so seconds later the same LS-Update comes in with the > same seq > > > number. This appears to continue indefinitely. Our only fix appears to > be > > > restarting ospfd on the routers. > > > > > > Does anyone have an idea what is going wrong here? > > > > > > Something we have considered being a problem is that we do have many > > > interfaces, we have 90 or so, so the LS-Update packets are quite large > and > > > do get fragmented, as we are using a 1500mtu. > > > > > > The fact that ospfd sees the age and complains though makes us think > this > > > is not a problem. > > > > > > > Looking at the tcpdump output there is something strange with the various > > reported length fields. Is it possible to get the raw packet dumps? > > > > Can you try the following diff and see if it fixes the issue? > > -- > :wq Claudio > > Index: lsupdate.c > =================================================================== > RCS file: /cvs/src/usr.sbin/ospfd/lsupdate.c,v > retrieving revision 1.47 > diff -u -p -r1.47 lsupdate.c > --- lsupdate.c 19 Nov 2019 09:55:55 -0000 1.47 > +++ lsupdate.c 5 May 2020 09:20:50 -0000 > @@ -186,7 +186,7 @@ add_ls_update(struct ibuf *buf, struct i > return (0); > } > > - lsage = ibuf_reserve(buf, 0); > + lsage = ibuf_reserve(buf, len); > if (ibuf_add(buf, data, len)) { > log_warn("add_ls_update"); > return (0); >
