Hi Ondrej,
Thank you very much.
For as test I removed the IPv6 channel and sniffed the packets again. As
you expected IPv4 AFI was listed and (after fixing the MikroTik IPv6
AFI, obviously) stuff kept working.
Very likely I didn't have channels, early in the process.
Cheers,
Kees
On 18-06-2021 17:13, Ondrej Zajicek wrote:
On Fri, Jun 18, 2021 at 11:12:39AM +0200, Kees Meijs | Nefos wrote:
Hi list,
Using tcpdump(8) I was able to pin point the issue.
Please note the difference (BIRD):
Optional parameters, length: 8
Option Capabilities Advertisement (2), length: 6
32-Bit AS Number (65), length: 4
4 Byte AS REDACTED
0x0000: 0000 9b06
and the MikroTik:
Optional parameters, length: 16
Option Capabilities Advertisement (2), length: 14
Route Refresh (2), length: 0
32-Bit AS Number (65), length: 4
4 Byte AS REDACTED
0x0000: 0003 280d
Multiprotocol Extensions (1), length: 4
AFI IPv4 (1), SAFI Unicast (1)
0x0000: 0001 0001
I can work around the problem by adding a IPv4 and IPv6 channel and enable
IPv6 on the MikroTik as well.
Is it possible to configure BIRD2 to enforce Multiprotocol Extensions when
only IPv4 is in use?
Hi
Perhaps you have no channel configured? AFAIK if there is only IPv4
channel, BIRD still announces multiprotocol capability with IPv4 AFI.
I suspected the ver=4 is the problem so I've added:
advertise ipv4 off;
But alas, BIRD2 is now complaining:
Seems like a bug in documentation, this option was removed during
bird1 -> bird2 transition, but should not matter.