[Cake] Recommendations for using cake in complex setup (wireguard + vlan + bond)

Alban albeu at free.fr
Mon Jul 1 07:52:51 EDT 2019


Hi everybody,

I am setting a new router with a non trivial setup and I really like to
get some recommendations on how to best use cake. First of all the
router is using VLAN on top of 2 bonded gigabit Ethernet interface:

                        +--> VLAN1 (LAN)
 eth0 <--+              |
         +---> bond0 <--+--> VLAN2 (WAN1)
 eth1 <--+              |
                        +--> VLAN3 (WAN2)

The bond is using LACP, but mainly for redundancy and not for the
increased bandwidth. Both WAN VLAN are going to ISP provided FritzBox
connected to 50/10Mbit VDSL2 lines.

As far as i understand I should use cake on the WAN VLAN interfaces.
But what about the bond and physical Ethernet interface? Per default
the Ethernet interfaces use the fq_codel qdisc, should I replace it
with noqueue if cake is running on the VLAN interface? Any other
recommendation regarding queuing in general with such layering of
interfaces?

But there is one more component, on each WAN interface there is a
wireguard tunnel which is used to encrypt most of the traffic going out
on the interface. Unlike unencrypted IP in IP tunnel the kernel flow
dissector is not able to distinguish the flows, so all the encrypted
traffic is just one big flow for cake. Ideally I would like to achieve a
setup where cake can handle the encrypted traffic just like unencrypted
traffic.

Looking at the wireguard code it seems that the incoming skb get
encrypted/encapsulated and resent again while still using the same skb.
This give me the hope that it might be possible to classify the traffic
entering the wireguard tunnel and somehow pass this information down to
the cake instance running on the lower device.

I have seen that cake can use classifier and that the tin can be passed
via fw mark, however I'm unsure if that would really be useful/usable in
this case. Any suggestion would be welcome, from what can be done with
the current code, up to what kind of changes would be needed to achieve
the ideal case.

Alban
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20190701/4d120487/attachment.sig>


More information about the Cake mailing list