Babel + IPv4 = parse error

Julian Schuh julez at julez.in
Tue Jun 12 09:51:14 CEST 2018


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20180612/7f64cfc0/attachment.html>


More information about the Bird-users mailing list