Re: [OSPF] BIRD <> Mikrotik checksum
On Thu, Sep 02, 2010 at 11:36:22AM +0200, Maciej Drobniuch wrote:
Hi! I have a problem with binding bird with mikrotik router os. The RouterOS says: 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
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.
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
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@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."
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
W dniu 2011-03-20 23:03, Adrian Czapek pisze:
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
participants (2)
-
Adrian Czapek -
Ondrej Zajicek