Hi,
I get relatively much "log spam" about one specific BGP session which logs
dozens of 'Invalid NEXT_HOP attribute' messages.
I haven't found much information online, but have already tried to find out
which code path in BIRD produces the message.
(The peers all have a BIRD-2.0.7 installation).
The following code paths in 'proto/bgp/packets.c:bgp_update_next_hop_ip' are
hit:
--snip--
/* Forbid zero next hop */
if (ipa_zero(nh[0]) && ((len != 32) || ipa_zero(nh[1])))
WITHDRAW(BAD_NEXT_HOP);
/* Forbid next hop equal to neighbor IP */
if (ipa_equal(peer, nh[0]) || ((len == 32) && ipa_equal(peer, nh[1])))
WITHDRAW(BAD_NEXT_HOP);
--end snip--
Thus, I already concluded that one source of the error is a 'zeroed' next hop.
But I don't really understand what the second check does and why.
I found out that sometimes (after some printf-debugging), 'peer' is equal to
'nh[0]', but the second code path isn't always hit when that is the case, but
only sometimes.
The error only seems to happen if the BGP update message contains a next-hop
with the same AF as the 'peer' has. If the peer sends the same BGP message, but
via IPv6,
and same IPv4 next_hop (which is equal to the peer ll address), the message is
(somewhat inconsistent with the other behavior) accepted.
The error does only happen if the previous if block 'if (!a ||
!bgp_use_next_hop(s, a))' is not hit.
If it is hit, the next hop is updated to point at the local ll address and the
message is accepted.
I don't really know how to fix this problem, but I already tried to adjust the
config to modify the 'bgp_next_hop' variable or use 'next hop self;' to no
avail.
Cheers
Erik
