Ondrej Zajicek <santi...@crfreenet.org> writes: > On Sun, Jun 10, 2018 at 02:48:45PM +0200, Toke Høiland-Jørgensen wrote: >> Ondrej Zajicek <santi...@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
