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 <[email protected]> wrote: > > Ondrej Zajicek <[email protected] <mailto:[email protected]>> > writes: > >> On Sun, Jun 10, 2018 at 02:48:45PM +0200, Toke Høiland-Jørgensen wrote: >>> Ondrej Zajicek <[email protected]> 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
