Discussion:
[OSPF] BIRD <> Mikrotik checksum
Adrian Czapek
2011-03-17 11:03:16 UTC
Permalink
Hi!
I have a problem with binding bird with mikrotik router os.
Discarding packet: wrong checksum.
Strange. I will check that.
Did you find anything? I've experienced the same problem last evening.
Suddenly I've found my routeros logs flooded by:
mar/16 23:32:31 route,ospf,info Discarding packet: wrong chekcsum
mar/16 23:32:31 route,ospf,info source=78.31.143.69

this is backup link, with cost set to 100 on both sides - main link,
between the same bird and the same routeros has been working perfectly.
I first tried to reload ospf1 from bird console and guess what
happened... main link went dead too... wrong checksums on both links.
Then I did reload ospf1 again, main link went up, backup link stayed
dead, but suddenly, other routeros in this area went dead:

mar/16 23:37:27 route,ospf,info Discarding packet: wrong chekcsum
mar/16 23:37:27 route,ospf,info source=78.31.136.169

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.

What may be wrong?

Regards
--
Adrian
Adrian Czapek
2011-03-19 15:22:20 UTC
Permalink
Post by Adrian Czapek
Did you find anything? I've experienced the same problem last evening.
mar/16 23:32:31 route,ospf,info Discarding packet: wrong chekcsum
mar/16 23:32:31 route,ospf,info source=78.31.143.69
this is backup link, with cost set to 100 on both sides - main link,
between the same bird and the same routeros has been working perfectly.
I first tried to reload ospf1 from bird console and guess what
happened... main link went dead too... wrong checksums on both links.
Then I did reload ospf1 again, main link went up, backup link stayed
mar/16 23:37:27 route,ospf,info Discarding packet: wrong chekcsum
mar/16 23:37:27 route,ospf,info source=78.31.136.169
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?

Regards
--
Adrian
Ondrej Zajicek
2011-03-20 14:58:41 UTC
Permalink
Post by Adrian Czapek
Post by Adrian Czapek
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: ***@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."
Adrian Czapek
2011-03-20 22:03:35 UTC
Permalink
Post by Ondrej Zajicek
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
I am not quite sure if it is LSA checksum. I don't have tcpdump stored
anywhere, because I was watching it "live", but it looked like RouterOS
had a problem with Hello packet itself.
The moment I've seen Hello packet broadcasted to the link, the wrong
checksum entry poped in RouterOS logs.
--
Adrian
Adrian Czapek
2011-05-13 10:33:13 UTC
Permalink
Post by Adrian Czapek
Post by Ondrej Zajicek
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
I am not quite sure if it is LSA checksum. I don't have tcpdump stored
anywhere, because I was watching it "live", but it looked like RouterOS
had a problem with Hello packet itself.
The moment I've seen Hello packet broadcasted to the link, the wrong
checksum entry poped in RouterOS logs.
I am back with this issue after few months. I encountered the same issue
on the other subnet, when I was trying to upgrade bird.
Everytime I shutdown bird and start it again, my OSPF don't go UP. On
mikrotiks, I have "wrong checksum" as described in previous mails. Here
is 'show ospf lsadb' during that state:
bird> show ospf lsadb

Global

Type LS ID Router Age Sequence Checksum
0005 0.0.0.0 78.31.136.246 23 80000001 c2ed
0005 10.100.64.0 78.31.136.246 23 80000001 c839
0005 10.111.65.0 78.31.136.246 23 80000001 de26
0005 10.128.0.0 78.31.136.246 23 80000001 35f1
0005 78.31.138.128 78.31.136.246 23 80000001 5d5a

Area 0.0.0.1

Type LS ID Router Age Sequence Checksum
0001 78.31.136.246 78.31.136.246 14 80000001 ec42


tcpdump file sent private.

Regards
--
Adrian Czapek
Loading...