[Cake] dscp & tunneling

[Kevin Darbyshire-Bryant]

On 10/12/15 11:45, Dave Taht wrote:
> 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.
Ahh, ok.  And I've just confirmed this by running an ipv6 only 'rrul
with classification split' test, which shows a corresponding number of
'bulk flows' in line with the test.  Unfortunately.....
> 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.
the same test shows all those flows going in the best effort tin and
nothing being split out according to dscp.  Things are split out
correctly with ipv4.  Assuming that my installation of flent is doing
the right thing (putting dscp on its outbound ipv6 packets) and knowing
that both flent & cake handle the ipv4 version of the test correctly and
that by the time 'cake' sees my tunnel it's all ipv4 outer packets
anyway, this suggests dscp from inner ipv6 to outer ipv4 isn't taking
place, at least for 6in4 'sit' tunnels :-(



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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4816 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20151210/f0b59e2a/attachment-0001.bin>