[OSPF] BIRD <> Mikrotik checksum

[Ondrej Zajicek]

On Sat, Mar 19, 2011 at 04:22:20PM +0100, Adrian Czapek wrote:
>> I started to freak out and pullled bigger cannon: restart ospf1 -
>> result: those 2 routeros went up (besides backup link -
>> source=78.31.143.69), but heh, 3rd routeros went down
>>
>> mar/16 23:39:57 route,ospf,info Discarding packet: wrong chekcsum
>> mar/16 23:39:57 route,ospf,info source=78.31.139.21
>>
>> well, that was to much, I shutdown whole bird and started it again...
>> all went up except the first mentioned backup link (which never went up
>> btw).
>> So I decided to go back to quagga and check it there with the same
>> config. Disabled ospf in bird, started quagga and everything went up,
>> even that backup link. I've left it for about an hour and stopped
>> quagga, enabled ospf on bird, and everyting works fine, all links are
>> up, backup link too.
>>
>
> And it happened today again, wrong checksums all of the sudden, on  
> various links. Have to go back to quagga and wait for a fix. Any clue?

I have no idea. It is true that BIRD does not check checksums of
LSAs later when they are stored, but it checks that when it receives
them. If you did restart of a BIRD (or at least OSPF protocol) then no
bad LSA could survive that. It might be useful if you could get a
tcpdump copy of the OSPF communication [*] on the problematic link (when
there is a problem). and output of 'show ospf lsadb'.

[*] tcpdump -i ethX -s 0 -w dumpfile ip proto 89

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20110320/2489795d/attachment-0001.asc>