[Cake] dscp & tunneling

Dave Taht dave.taht at gmail.com
Thu Dec 10 06:45:00 EST 2015


On Thu, Dec 10, 2015 at 12:18 PM, Kevin Darbyshire-Bryant
<kevin at darbyshire-bryant.me.uk> wrote:
>
>
> On 06/12/15 11:08, Kevin Darbyshire-Bryant wrote:
>> So there I was pondering the problem of getting the IPv6 DSCP coding
>> onto the outer IPv4 packets of my '6in4' tunnel (kindly provided for
>> free by Hurricane Electric) when I stumbled across this in a man page:
>>
>>
>>        ip tunnel { add | change | del | show | prl } [ NAME ]
>>                [ mode MODE ] [ remote ADDR ] [ local ADDR ]
>>                [ [i|o]seq ] [ [i|o]key KEY ] [ [i|o]csum ] ]
>>                [ encaplimit ELIM ] [ ttl TTL ]
>>                [ tos TOS ] [ flowlabel FLOWLABEL ]
>>                [ prl-default ADDR ] [ prl-nodefault ADDR ] [ prl-delete
>> ADDR ]
>>                [ [no]pmtudisc ] [ dev PHYS_DEV ] [ dscp inherit ]
>>
>> dscp inherit - just what I need!  Unfortunately it turns out it's for
>> 'things being tunnelled over ipv6' and not 'ipv6 being tunnelled over
>> ipv4'.   Aaaarrghhh!  So close.
> Of course I'm a complete muppet!  This would be a fairly pointless
> exercise as cake has already classified the tunnel as it's a single flow
> (from my router to the tunnel server) and no amount of dscp bit fiddling
> from inner to outer headers is going to make different parts of the
> tunnel flow move to different cake tins.  Oh I am stupid.  Sigh.

No... for the hashing part, the skb_dissect routines in the kernel
already pull apart the stuff inside ip, ipv6, and gre *version 0)
tunnels and give you a hash based on the inner headers. So you do end
up with more than one hashed flow in the ipv6 tunnel. (this was not
the case at least as far back as 3.6, but it was one of the first
things we fixed) - see approximately line 458 in
net/core/flow_dissector.c.

The dscp is hopefully, with inherit, copied back and forth correctly,
although it is worrisome on some other OSes regarding dealing with the
ecn bits.

VPNs like ipsec or openvpn are not handled this way, not enough data.
Arguably you could pull apart some forms of tinc (stalled out research
project) in a really sane way...

> I'm going to persist with my dscp 'dye' option (wash cleans, dye
> 'colours' the packets with certain dscp codes per tin - wash/dye -
> geddit?  I'll fetch my coat)
>
>>
>>
>>
>> _______________________________________________
>> Cake mailing list
>> Cake at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>
>
>
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>



More information about the Cake mailing list