Hi all, for a current project I’m planning on using Babel as a lightweight, dual-stack routing protocol for a couple of simple tasks. For a proof of concept I’ve been using BIRD, and a plan to continue using BIRD at least in the backend. Sadly, I quickly hit a showstopper: none of the routes (neither v4 nor v6) exported from one side were imported on the other side. While investigating the problem I quickly stumbled over the following line in the debug log: “bird: bb: Bad TLV from fe80::xxx via vh type 8 pos 16 - parse error” After playing around for a little bit I found out: The problem appears whenever the route advertisement contains v4 routes. I’m using BIRD 2.0.2. I used the following setup to reproduce the problem: Two network namespaces, “default" and “test", connected via an veth pair. In both namespaces I’m running a BIRD instance with the following configs: default: ############################################ debug protocols all; router id 127.0.0.17; protocol device { } protocol babel bb { interface "v*" { }; ipv4 { import all; export none; }; ipv6 { import all; export none; }; }; ############################################ test: ############################################ debug protocols all; router id 127.0.0.18; protocol device { } protocol kernel v4 { ipv4 { import all; export all; }; learn; } protocol kernel v6 { ipv6 { import all; export all; }; learn; }; protocol babel bb { interface "v*" { }; ipv4 { import none; export all; }; ipv6 { import none; export all; }; } ############################################ (1) In test, I create an IPv6 route. It gets propagates to default: test> show route: fd77:8888::/32 unicast [v6 09:02:15.854] * (10) via fd54:7777::1 on gre0 test> show route export bb: fd77:8888::/32 unicast [v6 09:02:15.854] * (10) via fd54:7777::1 on gre0 test> show protocol all bb: ipv4: 0 exported, ipv6: 1 exported default> show route: fd77:8888::/32 unicast [bb 09:04:23.648] * (130/96) [00:00:00:00:7f:00:00:12] via fe80::3028:9aff:fea7:4a62 on vh default> show protocol all bb: ipv4: 0 imported, ipv6: 1 imported (2) Now, I add a v4 route on test: test> ip r a 1.2.3.0/24 via 10.10.10.16 dev gre0 show route [export] now shows both routes, v4 and v6. show protocol all bb show 1 exported for each v4 and v6. In this moment, I start receiving parse errors in the debug log of the other side (default): Bad TLV from fe80::3028:9aff:fea7:4a62 via vh type 8 pos 16 - parse error Interestingly, when retracting the route, the update seems to work: test> ip r d 1.2.3.0/24 via 10.10.10.16 dev gre0 Debug output on other side (default): Handling update for 1.2.3.0/24 with seqno 1 metric 65535 TL;DR: There _seems_ to be a bug in the babel protocol implementation that leads to parse errors and thus missed route advertisements if ipv4 routes are conveyed. This does not happen with ipv4 route retractions. I would really appreciate any help. If it’s a bug I would happily test source code patches. Thanks in advance and best Regards Julian Schuh
On Sun, Jun 10, 2018 at 11:22:17AM +0200, Julian Schuh wrote:
Hi all,
for a current project I’m planning on using Babel as a lightweight, dual-stack routing protocol for a couple of simple tasks. For a proof of concept I’ve been using BIRD, and a plan to continue using BIRD at least in the backend.
Sadly, I quickly hit a showstopper: none of the routes (neither v4 nor v6) exported from one side were imported on the other side. While investigating the problem I quickly stumbled over the following line in the debug log: “bird: bb: Bad TLV from fe80::xxx via vh type 8 pos 16 - parse error” After playing around for a little bit I found out: The problem appears whenever the route advertisement contains v4 routes.
I’m using BIRD 2.0.2. I used the following setup to reproduce the problem: Two network namespaces, “default" and “test", connected via an veth pair. In both namespaces I’m running a BIRD instance with the following configs:
Hi Tested it, works for me. Do you have IPv4 addresses on veth ifaces? Otherwise it would complain about no IPv4 next hop, probably send IPv4 routes without one and report parse error on the other side. Could you get tcpdump (-vv -s 0) from the communication? -- 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."
Ondrej Zajicek <santiago@crfreenet.org> writes:
On Sun, Jun 10, 2018 at 11:22:17AM +0200, Julian Schuh wrote:
Hi all,
for a current project I’m planning on using Babel as a lightweight, dual-stack routing protocol for a couple of simple tasks. For a proof of concept I’ve been using BIRD, and a plan to continue using BIRD at least in the backend.
Sadly, I quickly hit a showstopper: none of the routes (neither v4 nor v6) exported from one side were imported on the other side. While investigating the problem I quickly stumbled over the following line in the debug log: “bird: bb: Bad TLV from fe80::xxx via vh type 8 pos 16 - parse error” After playing around for a little bit I found out: The problem appears whenever the route advertisement contains v4 routes.
I’m using BIRD 2.0.2. I used the following setup to reproduce the problem: Two network namespaces, “default" and “test", connected via an veth pair. In both namespaces I’m running a BIRD instance with the following configs:
Hi
Tested it, works for me. Do you have IPv4 addresses on veth ifaces? Otherwise it would complain about no IPv4 next hop, probably send IPv4 routes without one and report parse error on the other side.
Yeah, my thought went to missing v4 addresses as well; maybe we should avoid sending the TLV entirely if no nexthop is found (and make the warning louder or something)? -Toke
On Sun, Jun 10, 2018 at 02:48:45PM +0200, Toke Høiland-Jørgensen wrote:
Ondrej Zajicek <santiago@crfreenet.org> writes:
On Sun, Jun 10, 2018 at 11:22:17AM +0200, Julian Schuh wrote:
Hi all,
for a current project I’m planning on using Babel as a lightweight, dual-stack routing protocol for a couple of simple tasks. For a proof of concept I’ve been using BIRD, and a plan to continue using BIRD at least in the backend.
Sadly, I quickly hit a showstopper: none of the routes (neither v4 nor v6) exported from one side were imported on the other side. While investigating the problem I quickly stumbled over the following line in the debug log: “bird: bb: Bad TLV from fe80::xxx via vh type 8 pos 16 - parse error” After playing around for a little bit I found out: The problem appears whenever the route advertisement contains v4 routes.
I’m using BIRD 2.0.2. I used the following setup to reproduce the problem: Two network namespaces, “default" and “test", connected via an veth pair. In both namespaces I’m running a BIRD instance with the following configs:
Hi
Tested it, works for me. Do you have IPv4 addresses on veth ifaces? Otherwise it would complain about no IPv4 next hop, probably send IPv4 routes without one and report parse error on the other side.
Yeah, my thought went to missing v4 addresses as well; maybe we should avoid sending the TLV entirely if no nexthop is found (and make the warning louder or something)?
Hi Avoid sending the TLV would make sense to me if it is forbidden by spec. -- 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."
Ondrej Zajicek <santiago@crfreenet.org> writes:
On Sun, Jun 10, 2018 at 02:48:45PM +0200, Toke Høiland-Jørgensen wrote:
Ondrej Zajicek <santiago@crfreenet.org> writes:
On Sun, Jun 10, 2018 at 11:22:17AM +0200, Julian Schuh wrote:
Hi all,
for a current project I’m planning on using Babel as a lightweight, dual-stack routing protocol for a couple of simple tasks. For a proof of concept I’ve been using BIRD, and a plan to continue using BIRD at least in the backend.
Sadly, I quickly hit a showstopper: none of the routes (neither v4 nor v6) exported from one side were imported on the other side. While investigating the problem I quickly stumbled over the following line in the debug log: “bird: bb: Bad TLV from fe80::xxx via vh type 8 pos 16 - parse error” After playing around for a little bit I found out: The problem appears whenever the route advertisement contains v4 routes.
I’m using BIRD 2.0.2. I used the following setup to reproduce the problem: Two network namespaces, “default" and “test", connected via an veth pair. In both namespaces I’m running a BIRD instance with the following configs:
Hi
Tested it, works for me. Do you have IPv4 addresses on veth ifaces? Otherwise it would complain about no IPv4 next hop, probably send IPv4 routes without one and report parse error on the other side.
Yeah, my thought went to missing v4 addresses as well; maybe we should avoid sending the TLV entirely if no nexthop is found (and make the warning louder or something)?
Hi
Avoid sending the TLV would make sense to me if it is forbidden by spec.
Hmm, the spec doesn't actually say anything about this; but maybe it should. I'll bring it up on the Babel list :) -Toke
Hi, thanks you all for your reply. You were right, it was indeed the missing IPv4 addresses. I think I’m quite spoiled by the IPv6 link-local addresses, so I forgot about having to manually configure IPv4 addresses ;-) Does anybody still want to get any information from me (tcpdump or anything else)? Thanks and Best Regards Julian Schuh
On 10. Jun 2018, at 15:36, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
Ondrej Zajicek <santiago@crfreenet.org <mailto:santiago@crfreenet.org>> writes:
On Sun, Jun 10, 2018 at 02:48:45PM +0200, Toke Høiland-Jørgensen wrote:
Ondrej Zajicek <santiago@crfreenet.org> writes:
On Sun, Jun 10, 2018 at 11:22:17AM +0200, Julian Schuh wrote:
Hi all,
for a current project I’m planning on using Babel as a lightweight, dual-stack routing protocol for a couple of simple tasks. For a proof of concept I’ve been using BIRD, and a plan to continue using BIRD at least in the backend.
Sadly, I quickly hit a showstopper: none of the routes (neither v4 nor v6) exported from one side were imported on the other side. While investigating the problem I quickly stumbled over the following line in the debug log: “bird: bb: Bad TLV from fe80::xxx via vh type 8 pos 16 - parse error” After playing around for a little bit I found out: The problem appears whenever the route advertisement contains v4 routes.
I’m using BIRD 2.0.2. I used the following setup to reproduce the problem: Two network namespaces, “default" and “test", connected via an veth pair. In both namespaces I’m running a BIRD instance with the following configs:
Hi
Tested it, works for me. Do you have IPv4 addresses on veth ifaces? Otherwise it would complain about no IPv4 next hop, probably send IPv4 routes without one and report parse error on the other side.
Yeah, my thought went to missing v4 addresses as well; maybe we should avoid sending the TLV entirely if no nexthop is found (and make the warning louder or something)?
Hi
Avoid sending the TLV would make sense to me if it is forbidden by spec.
Hmm, the spec doesn't actually say anything about this; but maybe it should. I'll bring it up on the Babel list :)
-Toke
Julian Schuh <julez@julez.in> writes:
Hi,
thanks you all for your reply.
You were right, it was indeed the missing IPv4 addresses. I think I’m quite spoiled by the IPv6 link-local addresses, so I forgot about having to manually configure IPv4 addresses ;-)
Does anybody still want to get any information from me (tcpdump or anything else)?
If adding v4 addresses fixes the issue I think we are good :) -Toke
Julian Schuh <julez@julez.in> writes:
Hi all,
for a current project I’m planning on using Babel as a lightweight, dual-stack routing protocol for a couple of simple tasks. For a proof of concept I’ve been using BIRD, and a plan to continue using BIRD at least in the backend.
Sadly, I quickly hit a showstopper: none of the routes (neither v4 nor v6) exported from one side were imported on the other side. While investigating the problem I quickly stumbled over the following line in the debug log: “bird: bb: Bad TLV from fe80::xxx via vh type 8 pos 16 - parse error” After playing around for a little bit I found out: The problem appears whenever the route advertisement contains v4 routes.
Well, I'm running bird just fine with v4 routes, so it's not a total failure, at least ;) What's the output in birdc of 'show babel interfaces', 'show babel routes' and 'show babel entries' on both sides? -Toke
participants (3)
-
Julian Schuh -
Ondrej Zajicek -
Toke Høiland-Jørgensen