Trouble with IPv6 and VRFs: Cannot assign requested address
Hi all, I am playing around with VRFs in our network, and I am having trouble getting bird6 to establish its BGP sessions inside a VRF. Strangely, bird for IPv4 works with pretty much the same configuration. I have attached the full configuration. The (I think) interesting bits are
template bgp ffrl_uplink { table ffrl; vrf "vrf_freifunk"; local as 64899; import keep filtered; import filter ebgp_ffrl_import_filter; export filter ebgp_ffrl_export_filter; next hop self; direct; };
protocol bgp ffrl_b_ak from ffrl_uplink { source address 2a03:2260:0:195::2; neighbor 2a03:2260:0:195::1 as 201701; };
In the logs, all I get (with `debug all;` added) is
Dez 28 13:05:25 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Connecting to 2a03:2260:0:195::1 from local address 2a03:2260:0:195::2 Dez 28 13:05:25 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Socket error: bind: Cannot assign requested address Dez 28 13:05:25 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Connection closed Dez 28 13:05:26 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Connect delayed by 5 seconds
I tried adding `interface "tun-up-ffrl_b_ak";` (that's the interface which has the address 2a03:2260:0:194::2), to no avail. I also tried adding `interface "vrf_freifunk";`, which made the error messages go away but still no peer is listed in `birdc6 show route table ffrl`. My IPv4 configuration is almost the same, and yet there finding peers works. (Actually routing traffic doesn't work yet, but that may also be a problem with our NAT setup.) Note that I have very little experience with BGP, we use it only in an internal instance for peering with our uplink.
From some googling I found <https://bird.network.cz/pipermail/bird-users/2017-August/011440.html> which recommends adding `direct;`, but I already have that set.
This is using bird 1.6.4, Linux 4.18, Debian stable. Any help would be greatly appreciated. Kind regards, Ralf
What about putting the interface with the IPv6 address of "2a03:2260:0:195::2" into the VRF in kernel? What is the output of `ip vrf show vrf_freifunk`? On 28/12/2018 15:10, Ralf Jung wrote:
Hi all,
I am playing around with VRFs in our network, and I am having trouble getting bird6 to establish its BGP sessions inside a VRF. Strangely, bird for IPv4 works with pretty much the same configuration.
I have attached the full configuration. The (I think) interesting bits are
template bgp ffrl_uplink { table ffrl; vrf "vrf_freifunk"; local as 64899; import keep filtered; import filter ebgp_ffrl_import_filter; export filter ebgp_ffrl_export_filter; next hop self; direct; };
protocol bgp ffrl_b_ak from ffrl_uplink { source address 2a03:2260:0:195::2; neighbor 2a03:2260:0:195::1 as 201701; };
In the logs, all I get (with `debug all;` added) is
Dez 28 13:05:25 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Connecting to 2a03:2260:0:195::1 from local address 2a03:2260:0:195::2 Dez 28 13:05:25 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Socket error: bind: Cannot assign requested address Dez 28 13:05:25 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Connection closed Dez 28 13:05:26 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Connect delayed by 5 seconds
I tried adding `interface "tun-up-ffrl_b_ak";` (that's the interface which has the address 2a03:2260:0:194::2), to no avail. I also tried adding `interface "vrf_freifunk";`, which made the error messages go away but still no peer is listed in `birdc6 show route table ffrl`. My IPv4 configuration is almost the same, and yet there finding peers works. (Actually routing traffic doesn't work yet, but that may also be a problem with our NAT setup.)
Note that I have very little experience with BGP, we use it only in an internal instance for peering with our uplink.
From some googling I found <https://bird.network.cz/pipermail/bird-users/2017-August/011440.html> which recommends adding `direct;`, but I already have that set.
This is using bird 1.6.4, Linux 4.18, Debian stable.
Any help would be greatly appreciated.
Kind regards, Ralf
-- Cheers Christoffer
Hi, On 28.12.18 15:43, Christoffer Hansen wrote:
What about putting the interface with the IPv6 address of "2a03:2260:0:195::2" into the VRF in kernel?
It already is:
13: tun-up-b_ak@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue master vrf_freifunk state UNKNOWN group default qlen 1000 link/gre 82.165.162.239 peer 185.66.195.1 inet 100.64.3.23/31 brd 255.255.255.255 scope global tun-up-b_ak valid_lft forever preferred_lft forever inet6 2a03:2260:0:195::2/64 scope global valid_lft forever preferred_lft forever inet6 fe80::200:5efe:52a5:a2ef/64 scope link valid_lft forever preferred_lft forever
What is the output of `ip vrf show vrf_freifunk`?
My "ip" seems to be too old:
Object "vrf" is unknown, try "ip help".
; Ralf
On 28/12/2018 15:10, Ralf Jung wrote:
Hi all,
I am playing around with VRFs in our network, and I am having trouble getting bird6 to establish its BGP sessions inside a VRF. Strangely, bird for IPv4 works with pretty much the same configuration.
I have attached the full configuration. The (I think) interesting bits are
template bgp ffrl_uplink { table ffrl; vrf "vrf_freifunk"; local as 64899; import keep filtered; import filter ebgp_ffrl_import_filter; export filter ebgp_ffrl_export_filter; next hop self; direct; };
protocol bgp ffrl_b_ak from ffrl_uplink { source address 2a03:2260:0:195::2; neighbor 2a03:2260:0:195::1 as 201701; };
In the logs, all I get (with `debug all;` added) is
Dez 28 13:05:25 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Connecting to 2a03:2260:0:195::1 from local address 2a03:2260:0:195::2 Dez 28 13:05:25 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Socket error: bind: Cannot assign requested address Dez 28 13:05:25 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Connection closed Dez 28 13:05:26 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Connect delayed by 5 seconds
I tried adding `interface "tun-up-ffrl_b_ak";` (that's the interface which has the address 2a03:2260:0:194::2), to no avail. I also tried adding `interface "vrf_freifunk";`, which made the error messages go away but still no peer is listed in `birdc6 show route table ffrl`. My IPv4 configuration is almost the same, and yet there finding peers works. (Actually routing traffic doesn't work yet, but that may also be a problem with our NAT setup.)
Note that I have very little experience with BGP, we use it only in an internal instance for peering with our uplink.
From some googling I found <https://bird.network.cz/pipermail/bird-users/2017-August/011440.html> which recommends adding `direct;`, but I already have that set.
This is using bird 1.6.4, Linux 4.18, Debian stable.
Any help would be greatly appreciated.
Kind regards, Ralf
Hi again, On 28.12.18 15:43, Christoffer Hansen wrote:
What about putting the interface with the IPv6 address of "2a03:2260:0:195::2" into the VRF in kernel?
What is the output of `ip vrf show vrf_freifunk`?
I updated my "ip", now it says:
$ ip vrf show vrf_freifunk vrf_freifunk 1042
; Ralf
On 28/12/2018 15:10, Ralf Jung wrote:
Hi all,
I am playing around with VRFs in our network, and I am having trouble getting bird6 to establish its BGP sessions inside a VRF. Strangely, bird for IPv4 works with pretty much the same configuration.
I have attached the full configuration. The (I think) interesting bits are
template bgp ffrl_uplink { table ffrl; vrf "vrf_freifunk"; local as 64899; import keep filtered; import filter ebgp_ffrl_import_filter; export filter ebgp_ffrl_export_filter; next hop self; direct; };
protocol bgp ffrl_b_ak from ffrl_uplink { source address 2a03:2260:0:195::2; neighbor 2a03:2260:0:195::1 as 201701; };
In the logs, all I get (with `debug all;` added) is
Dez 28 13:05:25 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Connecting to 2a03:2260:0:195::1 from local address 2a03:2260:0:195::2 Dez 28 13:05:25 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Socket error: bind: Cannot assign requested address Dez 28 13:05:25 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Connection closed Dez 28 13:05:26 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Connect delayed by 5 seconds
I tried adding `interface "tun-up-ffrl_b_ak";` (that's the interface which has the address 2a03:2260:0:194::2), to no avail. I also tried adding `interface "vrf_freifunk";`, which made the error messages go away but still no peer is listed in `birdc6 show route table ffrl`. My IPv4 configuration is almost the same, and yet there finding peers works. (Actually routing traffic doesn't work yet, but that may also be a problem with our NAT setup.)
Note that I have very little experience with BGP, we use it only in an internal instance for peering with our uplink.
From some googling I found <https://bird.network.cz/pipermail/bird-users/2017-August/011440.html> which recommends adding `direct;`, but I already have that set.
This is using bird 1.6.4, Linux 4.18, Debian stable.
Any help would be greatly appreciated.
Kind regards, Ralf
On Fri, Dec 28, 2018 at 03:10:28PM +0100, Ralf Jung wrote:
Hi all,
I am playing around with VRFs in our network, and I am having trouble getting bird6 to establish its BGP sessions inside a VRF. Strangely, bird for IPv4 works with pretty much the same configuration.
Hi What is the output of 'birdc show interfaces'? -- 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."
Hi,
I am playing around with VRFs in our network, and I am having trouble getting bird6 to establish its BGP sessions inside a VRF. Strangely, bird for IPv4 works with pretty much the same configuration.
Hi
What is the output of 'birdc show interfaces'?
"birdc6", I assume?
BIRD 1.6.4 ready. lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=65536 ::1/128 (Primary, scope host) eth0 up (index=2) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 2001:8d8:1801:56::1/64 (Primary, scope univ) fe80::250:56ff:fe2b:60f/64 (Unselected, scope link) vrf_freifunk DOWN (index=3) MultiAccess AdminUp LinkUp MTU=65536 saarBR up (index=4 master=vrf_freifunk) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1280 2a03:2260:3009::2/48 (Primary, scope univ) fd4e:f2d7:88d2:ffff::2/64 (Unselected, scope site) fe80::ecee:eeff:feee:1/64 (Unselected, scope link) dummy0 DOWN (index=5) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 saarBR-mtu DOWN (index=6 master=saarBR) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1280 saarBAT up (index=8 master=saarBR) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1374 fe80::c0c3:b0ff:fe2c:961e/64 (Primary, scope link) gre0 DOWN (index=9) MultiAccess AdminDown LinkDown MTU=1476 gretap0 DOWN (index=10) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1462 erspan0 DOWN (index=11) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1450 tun-up-a_ak up (index=12 master=vrf_freifunk) PtP Multicast AdminUp LinkUp MTU=1280 2a03:2260:0:194::2/64 (Primary, scope univ) fe80::200:5efe:52a5:a2ef/64 (Unselected, scope link) tun-up-b_ak up (index=13 master=vrf_freifunk) PtP Multicast AdminUp LinkUp MTU=1280 2a03:2260:0:195::2/64 (Primary, scope univ) fe80::200:5efe:52a5:a2ef/64 (Unselected, scope link) tun-up-a_ix up (index=14 master=vrf_freifunk) PtP Multicast AdminUp LinkUp MTU=1280 2a03:2260:0:196::2/64 (Primary, scope univ) fe80::200:5efe:52a5:a2ef/64 (Unselected, scope link) tun-up-b_ix up (index=15 master=vrf_freifunk) PtP Multicast AdminUp LinkUp MTU=1280 2a03:2260:0:197::2/64 (Primary, scope univ) fe80::200:5efe:52a5:a2ef/64 (Unselected, scope link) tun-up-a_fra up (index=16 master=vrf_freifunk) PtP Multicast AdminUp LinkUp MTU=1280 2a03:2260:0:1e9::2/64 (Primary, scope univ) fe80::200:5efe:52a5:a2ef/64 (Unselected, scope link) tun-up-b_fra up (index=17 master=vrf_freifunk) PtP Multicast AdminUp LinkUp MTU=1280 2a03:2260:0:1ea::2/64 (Primary, scope univ) fe80::200:5efe:52a5:a2ef/64 (Unselected, scope link) ffrl_lo up (index=18 master=vrf_freifunk) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 fe80::4086:b9ff:fe3e:1efc/64 (Primary, scope link) tun-peer-gw2 up (index=19 master=saarBAT) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1406 fe80::4c25:5dff:fe9d:b3d3/64 (Primary, scope link) tun-peer-gw3 up (index=20 master=saarBAT) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1406 fe80::905d:9aff:fefa:a748/64 (Primary, scope link) tun-peer-gw4 up (index=21 master=saarBAT) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1406 fe80::d408:ebff:fed8:a66c/64 (Primary, scope link) tun-peer-mgmt up (index=22 master=saarBAT) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1406 fe80::642d:31ff:fe73:74f8/64 (Primary, scope link) saarFASTD up (index=23 master=saarVPN) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1406 fe80::248f:27ff:fe14:a639/64 (Primary, scope link) l2tp100-100 up (index=27 master=saarVPN) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1406 fe80::c03c:daff:fe95:6092/64 (Primary, scope link) saarVPN up (index=7 master=saarBAT) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1406 fe80::c8fe:baff:febe:1/64 (Primary, scope link)
; Ralf
Hi again, I have now also played around with bird 2.0 a bit, but got the same result: IPv4 works, but IPv6 says "Cannot assign requested address". I have attached my stripped-down configuration, which (as far as I can tell) is entirely symmetric for IPv4 and IPv6. I am starting bird as
sudo ./bird -c bird.conf -d
The log looks like:
2018-12-30 14:45:22.302 <TRACE> ffrl_a_ak_v4: Channel ipv4 connected to table ffrl_v4 2018-12-30 14:45:22.302 <TRACE> ffrl_a_ak_v4: Initializing 2018-12-30 14:45:22.302 <TRACE> ffrl_a_ak_v6: Channel ipv6 connected to table ffrl_v6 2018-12-30 14:45:22.302 <TRACE> ffrl_a_ak_v6: Initializing 2018-12-30 14:45:22.302 <WARN> Missing broadcast address for interface saarBR 2018-12-30 14:45:22.302 <TRACE> ffrl_a_ak_v4: Starting 2018-12-30 14:45:22.302 <TRACE> ffrl_a_ak_v4: State changed to start 2018-12-30 14:45:22.302 <TRACE> ffrl_a_ak_v6: Starting 2018-12-30 14:45:22.302 <TRACE> ffrl_a_ak_v6: State changed to start 2018-12-30 14:45:22.302 <INFO> Started 2018-12-30 14:45:22.307 <TRACE> ffrl_a_ak_v6: Started 2018-12-30 14:45:22.307 <TRACE> ffrl_a_ak_v6: Connect delayed by 5 seconds 2018-12-30 14:45:22.307 <TRACE> ffrl_a_ak_v4: Started 2018-12-30 14:45:22.307 <TRACE> ffrl_a_ak_v4: Connect delayed by 5 seconds 2018-12-30 14:45:26.312 <TRACE> ffrl_a_ak_v6: Connecting to 2a03:2260:0:194::1 from local address 2a03:2260:0:194::2 2018-12-30 14:45:26.312 <ERR> ffrl_a_ak_v6: Socket error: bind: Cannot assign requested address 2018-12-30 14:45:26.312 <TRACE> ffrl_a_ak_v6: Connection closed 2018-12-30 14:45:26.526 <TRACE> ffrl_a_ak_v6: Connect delayed by 5 seconds 2018-12-30 14:45:26.526 <TRACE> ffrl_a_ak_v4: Connecting to 100.64.3.20 from local address 100.64.3.21 2018-12-30 14:45:26.544 <TRACE> ffrl_a_ak_v4: Connected 2018-12-30 14:45:26.544 <TRACE> ffrl_a_ak_v4: Sending OPEN(ver=4,as=64899,hold=240,id=52a5a2ef) 2018-12-30 14:45:26.562 <TRACE> ffrl_a_ak_v4: Got OPEN(as=23456,hold=240,id=185.66.192.3) 2018-12-30 14:45:26.562 <TRACE> ffrl_a_ak_v4: Sending KEEPALIVE 2018-12-30 14:45:26.580 <TRACE> ffrl_a_ak_v4: Got KEEPALIVE 2018-12-30 14:45:26.580 <TRACE> ffrl_a_ak_v4: BGP session established
Some snapshots from strace:
socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 7 fcntl(7, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 setsockopt(7, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0 setsockopt(7, SOL_IPV6, IPV6_UNICAST_HOPS, [255], 4) = 0 setsockopt(7, SOL_IPV6, IPV6_TCLASS, [192], 4) = 0 setsockopt(7, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 bind(7, {sa_family=AF_INET6, sin6_port=htons(179), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 32) = 0 listen(7, 8) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 8 fcntl(8, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 setsockopt(8, SOL_IP, IP_TTL, [255], 4) = 0 setsockopt(8, SOL_IP, IP_TOS, [192], 4) = 0 setsockopt(8, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 bind(8, {sa_family=AF_INET, sin_port=htons(179), sin_addr=inet_addr("0.0.0.0")}, 32) = 0 listen(8, 8) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 9 fcntl(9, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 setsockopt(9, SOL_SOCKET, SO_BINDTODEVICE, "tun-up-a_ak\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 0 setsockopt(9, SOL_SOCKET, SO_DONTROUTE, [1], 4) = 0 setsockopt(9, SOL_IP, IP_TTL, [1], 4) = 0 setsockopt(9, SOL_IP, IP_TOS, [192], 4) = 0 bind(9, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("100.64.3.21")}, 32) = 0
socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 10 fcntl(10, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 setsockopt(10, SOL_SOCKET, SO_BINDTODEVICE, "tun-up-a_ak\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 0 setsockopt(10, SOL_SOCKET, SO_DONTROUTE, [1], 4) = 0 setsockopt(10, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0 setsockopt(10, SOL_IPV6, IPV6_UNICAST_HOPS, [1], 4) = 0 setsockopt(10, SOL_IPV6, IPV6_TCLASS, [192], 4) = 0 bind(10, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "2a03:2260:0:194::2", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 32) = -1 EADDRNOTAVAIL (Cannot assign requested address)
This, too, looks entirely symmetric between IPv4 and IPv6. Is it possible that this is a kernel bug? Kind regards, Ralf
On Sun, Dec 30, 2018 at 03:52:53PM +0100, Ralf Jung wrote:
Hi again,
I have now also played around with bird 2.0 a bit, but got the same result: IPv4 works, but IPv6 says "Cannot assign requested address". I have attached my stripped-down configuration, which (as far as I can tell) is entirely symmetric for IPv4 and IPv6.
I am starting bird as
sudo ./bird -c bird.conf -d
The log looks like:
This, too, looks entirely symmetric between IPv4 and IPv6. Is it possible that this is a kernel bug?
Hi Thanks for interesting logs, it is possible that this is a kernel bug, the implementation is pretty fresh and there were few issues with it in the past. You could try modified configurations (e.g. multihop instead of direct, real ethernet interface (or dummy interface) instead of tun interface) to see if the issue is related to some of these variants. -- 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."
Hi,
Thanks for interesting logs, it is possible that this is a kernel bug, the implementation is pretty fresh and there were few issues with it in the past.
I was beginning to suspect the same. What would be a good place for the bug report? Some kernel teams seem to prefer Bugzilla and others their mailing lists, and I have a very mixed track record for getting any reaction at all from kernel bug reports (as in, about half my reports never got any reply).
You could try modified configurations (e.g. multihop instead of direct, real ethernet interface (or dummy interface) instead of tun interface) to see if the issue is related to some of these variants.
Unfortunately I only control one side of the BGP session here, and I don't have any BGP experience so I wouldn't even know how to go about doing such experiments. Kind regards, Ralf
On Sun, Dec 30, 2018 at 07:25:50PM +0100, Ralf Jung wrote:
Hi,
Thanks for interesting logs, it is possible that this is a kernel bug, the implementation is pretty fresh and there were few issues with it in the past.
I was beginning to suspect the same.
What would be a good place for the bug report? Some kernel teams seem to prefer Bugzilla and others their mailing lists, and I have a very mixed track record for getting any reaction at all from kernel bug reports (as in, about half my reports never got any reply).
I would suggest linux-netdev mailing list and Cc to David Ahern <dsahern@gmail.com>.
You could try modified configurations (e.g. multihop instead of direct, real ethernet interface (or dummy interface) instead of tun interface) to see if the issue is related to some of these variants.
Unfortunately I only control one side of the BGP session here, and I don't have any BGP experience so I wouldn't even know how to go about doing such experiments.
For this you do not need the other side - the error happens immediately when BIRD tries to initiate the connection, so it does not matter if anyone listens on the other side. -- 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."
Hi,
I was beginning to suspect the same.
What would be a good place for the bug report? Some kernel teams seem to prefer Bugzilla and others their mailing lists, and I have a very mixed track record for getting any reaction at all from kernel bug reports (as in, about half my reports never got any reply).
I would suggest linux-netdev mailing list and Cc to David Ahern <dsahern@gmail.com>.
I'll try that, thanks.
You could try modified configurations (e.g. multihop instead of direct, real ethernet interface (or dummy interface) instead of tun interface) to see if the issue is related to some of these variants.
Unfortunately I only control one side of the BGP session here, and I don't have any BGP experience so I wouldn't even know how to go about doing such experiments.
For this you do not need the other side - the error happens immediately when BIRD tries to initiate the connection, so it does not matter if anyone listens on the other side.
Oh, of course. I tried a dummy device, no change in behavior. I tried removing the "direct;", no change in behavior. Unfortunately this machine only has one "real" interface (and it's a VPS so even that is not really real), so I'll probably just lock myself out if I try to put that into a VRF. Kind regards, Ralf
On December 30, 2018 7:25:50 PM GMT+01:00, Ralf Jung <post@ralfj.de> wrote:
Hi,
Thanks for interesting logs, it is possible that this is a kernel bug, the implementation is pretty fresh and there were few issues with it in the past.
I was beginning to suspect the same.
What would be a good place for the bug report? Some kernel teams seem to prefer Bugzilla and others their mailing lists, and I have a very mixed track record for getting any reaction at all from kernel bug reports (as in, about half my reports never got any reply).
You could try modified configurations (e.g. multihop instead of direct, real ethernet interface (or dummy interface) instead of tun interface) to see if the issue is related to some of these variants.
Unfortunately I only control one side of the BGP session here, and I don't have any BGP experience so I wouldn't even know how to go about doing such experiments.
Kind regards, Ralf
AFAIK netdev is OK to just send the bugreport via mail. Please cc me when sending the bugreport there. Thanks Maria
participants (4)
-
Christoffer Hansen -
Maria Jan Matějka -
Ondrej Zajicek -
Ralf Jung