On Mon, Dec 16, 2019 at 03:40:18PM +0100, Nico Schottelius wrote:
Ondrej Zajicek <santiago@crfreenet.org> writes:
On Mon, Dec 16, 2019 at 01:43:09AM +0100, Nico Schottelius wrote:
Follow up 2:
it seems that bird1.6 behaves differently to bird 2.0.7:
bird> show route all for 2a0a:e5c1:111:111:6aa6:5bc:535a:8e21 2a0a:e5c1:100::/40 via 2a0a:e5c0:1:8::6 on bond0.8 [router2_place6_ungleich_ch_v6 2019-12-03] * (100) [i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 2a0a:e5c0:2:2:0:84ff:fe41:f24d BGP.local_pref: 500 bird>
(this is from the 2nd router pair, still running bird 1.6)
Is it possible that the nexthop resolution algorithm changed in bird2 vs bird1?
Yes, in BIRD 1 direct mode, there was a fallback that uses IP address of BGP peer as gateway if BGP NEXT_HOP failed to resolve.
We removed this fallback in BIRD 2.
Ha, that explains a lot! I am still puzzled though, because the description of bird2 on the topic of gateway direct seems to imply that this is still the case.
That is mistake in docs.
Is there any way to restore the 1.6 behaviour?
No, it just hides misconfigurations. If you use 'next hop self' then there should not be difference between BGP NEXT_HOP and peer IP address and it would work even in cases where both IPv4 and IPv6 routes are propagated over one BGP session. -- 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."