Hi Santiago, BIRD running on Centos. The 2nd working session also use the same MD5 password and same hardware. The funny part is we have just fixed the issue by removing the MD5 password. We then tried a different MD5 password but the session flaps again. The funny part, when the BGP is established during the flap, I don't get any routes from the neighbour. But the neighbour claims that they received all prefixes that are advertised by us. Is there any other aspect that might cause this? By the way, the firewall rules are the same on both route servers running BIRD: [root etc]# ip6tables -L Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all anywhere anywhere state RELATED,ESTABLISHED ACCEPT ipv6-icmp anywhere anywhere ACCEPT all anywhere anywhere ACCEPT tcp anywhere anywhere state NEW tcp dpt:ssh ACCEPT tcp anywhere anywhere state NEW tcp dpt:bgp REJECT all anywhere anywhere reject-with icmp6-adm-prohibited Chain FORWARD (policy ACCEPT) target prot opt source destination REJECT all anywhere anywhere reject-with icmp6-adm-prohibited Chain OUTPUT (policy ACCEPT) target prot opt source destination Thanks, Jimmy On 5/9/13 5:44 PM, "Ondrej Zajicek" <santiago@crfreenet.org> wrote:
On Wed, Sep 04, 2013 at 11:43:31PM +0800, Jimmy Halim wrote:
Hi guys,
I had problem bringing up 1 IPv6 BGP neighbour after migration from OpenBGPd to BIRD. The session keeps flapping and no routes have been exchanged as well.
The log in BIRD: Sep 5 00:13:38 ixrs2 kernel: MD5 Hash mismatch for (2001:0de8:0005:0000:0000:0000:1234:0001, 56545)->(2001:0de8:0005:0000:0000:0002:1234:0002, 179) ... Have you guys encountered the same issue before? I have confirmed that the MD5 password is matching. The same neighbour has BGP session to my other BIRD server and the session is running fine! The next step from my side probably is to remove the MD5 password on my end and on other end.
Hello
BIRD is running on Linux or on BSD? The second working session also uses MD5 password? The other BIRD server uses the same kind of hardware (esp. the network card)?
We heard about such kind of problems with MD5 checksums, but as it is handled almost completely by OS kernel, i would guess that the problem is there (probably in some network card IP offloading or in some firewall rules).
-- 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."