Bug #406

quagga does not propagate default 6to4 route

Added by Dave Täht on Aug 10, 2012. Updated on Dec 3, 2012.
In Progress Normal Denis Ovsienko


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 :: 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.



Updated by Dave Täht on Aug 10, 2012.
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::164
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’

Updated by Dave Täht on Aug 11, 2012.
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. metric 0 (exported) metric 0 (exported) metric 0 (exported) metric 0 (exported) metric 0 (exported) metric 0 (exported) metric 0 (exported) metric 0 (exported)
:: metric 0 (exported)
2002::/16 metric 0 (exported)
2002:328a:a616:bab5::1128 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.

Updated by Dave Täht on Aug 11, 2012.
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)

Updated by Dave Täht on Aug 11, 2012.
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.

Updated by Denis Ovsienko on Aug 21, 2012.
Could you post the output of “show ipv6 route” vtysh command with and without the workaround?
Updated by David Taht on Sep 24, 2012.
On Wed, Sep 19, 2012 at 3:58 PM, Chris Lawrence lordsutch@gmail.com 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.


Updated by Jo-Philipp Wich on Sep 25, 2012.
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.
Updated by Dave Täht on Dec 3, 2012.
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.

This is a static export of the original bufferbloat.net issue database. As such, no further commenting is possible; the information is solely here for archival purposes.
RSS feed

Recent News & Articles

Mar 17, 2019 Wiki page
Jake Holland's Stance on ECN
Sep 6, 2018 Wiki page
Pete Heist's Thoughts on ECN
Sep 5, 2018 Wiki page
Dave Taht's Stance on ECN
Sep 4, 2018 Wiki page
Jonathan Morton's Take on ECN
Sep 3, 2018 Wiki page
ECN-Sane Project

Find us elsewhere

Bufferbloat Mailing Lists
#bufferbloat on Twitter
Google+ group
Archived Bufferbloat pages from the Wayback Machine


Comcast Research Innovation Fund
Nlnet Foundation
Shuttleworth Foundation

Bufferbloat Related Projects

Congestion Control Blog
Lede Project (OpenWrt)
Flent Network Test Suite
The Cake shaper

Network Performance Related Resources

Jim Gettys' Blog - The chairman of the Fjord
Toke's Blog - Karlstad University's work on bloat
Voip Users Conference - Weekly Videoconference mostly about voip
Candelatech - A wifi testing company that "gets it".