Bug #406

quagga does not propagate default 6to4 route

Added by Dave Täht 10 months ago. Updated 7 months ago.

Status:In Progress Start date:08/10/2012
Priority:Normal Due date:
Assignee:Denis Ovsienko % Done:

0%
Category:Networking Spent time: 5.00 hours
Target version:1st Public Cerowrt release

Description

When 6to4 is used on Cerowrt 3.3.8-14 and prior, the default route for ipv6 is not propagated via quagga-babeld.

root@gw:/etc/quagga# ip -6 route | grep default
default via ::192.88.99.1 dev 6to4-ge01 metric 1024

The 2002::/16 route is propagated to all clients. Note that it ends up in the kernel table.

root@gw:/etc/quagga# ip -6 route | grep 6to4
2002::/16 dev 6to4-ge01 proto kernel metric 256

If I manually on the client add the default route via

ip -6 route add default via fe80::204e:7fff:fe4a:9627 dev gw11

Things work.

So my guess is that the default route in the 6to4 netifd script needs to also be inserted into the kernel table in order to be passed to clients via quagga.

I have denis's patch as well installed for RT_PROT messages, but that doesn't appear to affect this behavior.

badlist.png (114.1 kB) Dave Täht, 08/10/2012 08:32 pm

History

#1
Updated by Dave Täht 10 months ago

I am dealing with three additional different bugs here.

0) quagga is not pushing the 6to4 default route out to other babel nodes.

1) On the local interface,
the following syntax only adds one 2002:: based addresses to the listed
interfaces. (se00)

config interface 'ge01'
option proto '6to4'
option adv_subnet '1'
option wan_device 'ge00'
option metric '1'
option ttl '64'
list adv_interface 'gw00'
list adv_interface 'gw10'
list adv_interface 'se00'
list adv_interface 'sw00'
list adv_interface 'sw10'

Interestingly, although luci will write this syntax, when it re-reads it only finds the first (gw00) interface. (see pic)

(it will also read the old syntax and convert to this)

I have been refreshing luci a lot, but somehow perhaps I'm out of sync? (no,
my last commit was 6c6af10f0859cbe5d61f5d2d60dfc9ea5215285e

And regardless only the third (se00) of these interfaces gain a 2002 address.

2) This generates a radvd file for the one interface that works as below.
Perhaps I need to put in a default route statement explicitly?

interface se00 {
AdvLinkMTU 1480;
AdvDefaultPreference medium;
IgnoreIfMissing on;
AdvSendAdvert on;
AdvOtherConfigFlag on;
AdvSourceLLAddress on;

prefix 2002:328a:a616:1::1/64
{
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr off;
        };
RDNSS fe80::204e:7fff:fe4a:9623
{
        };
DNSSL home.lan
{
        };
};

The one client connected that way (haven't verified it's functionality)
isn't getting out.

3) when netifd runs it deletes up the addresses gained via ahcp, wiping out the mesh.

config interface 'gw01'
option proto 'ahcp'

config interface 'gw11'
option proto 'ahcp'

#2
Updated by Dave Täht 10 months ago

Both I and jow changed netifd to insert user routes as static (which is arguably more correct, anyway)

But although I changed quagga to distribute static as well, it still doesn't pick up the 6to4-ge01 default route for ipv6. I tried adding the device to the quagga "network" stanza, to no luck... It is not shown as an export from vtysh, either.

0.0.0.0/0 metric 0 (exported)
50.138.160.0/21 metric 0 (exported)
192.168.1.0/27 metric 0 (exported)
192.168.1.64/27 metric 0 (exported)
192.168.1.96/27 metric 0 (exported)
192.168.1.128/27 metric 0 (exported)
192.168.1.160/27 metric 0 (exported)
192.168.1.224/32 metric 0 (exported)
::50.138.166.22/128 metric 0 (exported)
2002::/16 metric 0 (exported)
2002:328a:a616:bab5::1/128 metric 0 (exported)

Perhaps I can statically add it to the zebra config?

moving on to the other issues...

the 6to4 portion of the netifd scripts does not do address assignment. I'm not sure if it should, actually, when controlled by the adv_subnet variable. Perhaps a new variable, "assign_subnet" would be more appropro, or rs solicitations enabled in this case to automagically get a slaac address...

(btw, I like the scripts they are very clean and easy to read)

and have no idea how to tell it to ignore interfaces run with ahcp.

#3
Updated by Dave Täht 10 months ago

I was successfully able to propagate a default ipv6 route for 6to4 via adding
a stanza in zebra.conf

interface 6to4-ge01
 ipv6 route ::/0 2002:c058:6301::

I'm not certain I wanted to do it that way (certainly I don't want to announce routes via that interface)

#4
Updated by Dave Täht 10 months ago

  • Status changed from New to In Progress

Jow fixed portions of this bug (1 and 2)

In packages:

proto/6x4: cast 6to4 adv_interface to string when saving to uci, fixes 6in4.

Jow moved netifd to install userspace routes as static

[package] netifd: bump to git head, userspace routes are installed with RTPR_STATIC

This did not actually fix quagga. I put in a workaround in #note-3 - but I'm not happy with having to embed the
anycast route there, even if it is pretty generic...

This leaves netifd mucking with ahcpd managed interfaces when it shouldn't be as the last big remaining issue here.

Thx jow for leaping on this.

#5
Updated by Denis Ovsienko 10 months ago

  • Assignee changed from Dave Täht to Denis Ovsienko

Could you post the output of "show ipv6 route" vtysh command with and without the workaround?

#6
Updated by David Taht 9 months ago

On Wed, Sep 19, 2012 at 3:58 PM, Chris Lawrence <> wrote:

I've only noticed one real problem thus far: radvd is still advertising incorrect subnet addresses for 6to4 connections (addresses that start with 0:0:0:$adv_subnet, which clearly are wrong since all the addresses should be under 2002: to be routable on the ipv6 Internet). The fix is simple: in /lib/netifd/proto/6to4.sh, line 162 should read:

"$wancfg" "$subnet6" \

instead of the printf call that's there now. This is probably an upstream OpenWRT problem too.

Actually, no, the correct line would be:

set_6to4_radvd_prefix    "$sid" "$adv_interface" \
                                "$wancfg" "$(printf "%s:%x::/64" 
$prefix6 $adv_subnet) \
                                "$adv_valid_lifetime" "$adv_preferred_lifetime"

arguably "subnet6" is misnamed.

There is another bug in this script in correctly adding multiple
interfaces. It succeeds on the first, but not the rest, and thus far I
can't figure out why.

There is another bug in that arguably the interface itself should have
a prefix lifetime (monitored somehow) and mtu set and I'd argue for
marking it secondary in the hope that someday real ipv6 addresses
would become common.

And last bug, in that with the latest quagga OR dnsmasq, radvd is not
needed, except for detecting and generating the 6to4 prefix.

Chris

#7
Updated by Jo-Philipp Wich 9 months ago

Setting the radvd adv subnet with leading zeros is deliberate and not a bug.
Thats a special feature of radvd, it will populate the leading zeros with the prefix of the Base6to4 interface specified in the same prefix section. See the radvd man page for details on this.

#8
Updated by Dave Täht 7 months ago

I have no idea what's going to happen vs a vs dnsmasq vs quagga vs the new relay6d stuff.

I'm just happy radvd is going to go away. soon.

Also available in: Atom PDF