Re: tc and IPv6 : any experiences ?

[Andy Furniss <adf.lists@gmail.com>]

Dave Taht wrote:
> On Fri, Jan 13, 2017 at 10:02 AM, Andy Furniss <adf.lists@gmail.com> wrote:
>> Dave Taht wrote:
>>>
>>> On Fri, Jan 13, 2017 at 5:49 AM, Alan Goodman
>>> <notifications@yescomputersolutions.com> wrote:
>>>>
>>>> 'Just works' for me.
>>>>
>>>> TF + HFSC + FQ_Codel.  QoS categoriser written in iptables rules which
>>>> mark
>>>> the traffic was 'cloned' across using ip6tables. Slight adjustments
>>>> needed.
>>>
>>>
>>> I pointed to a common mistake folk tend to make when dealing with
>>> ipv6, in writing a filter rule, or a default bin, here:
>>>
>>> https://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die/
>>>
>>> When I started that rant I was seeing in nearly every off the shelf
>>> shaper a tc pattern match that looked like this:
>>>
>>> tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
>>>      0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
>>>
>>> Instead of
>>>
>>> tc filter add dev ${DEV} parent ffff: protocol all match u32 0 0 \
>>> police rate ${DOWNLINK}kbit burst 100k drop flowid :1
>>>
>>>
>>> Not matching protocol "all", thus ipv4 only - and thus the instant you
>>> added ipv6 to a network, the shaper (or policer in this case),  failed
>>> to shape successfully any traffic. Additional problems listed in the
>>> link above. I went on a search-and-destroy mission on every shaper I
>>> could find that was public to fix it a few years ago, but there's so
>>> much copy/pasted tc code out there...
>>
>>
>> I was about to post that ip is just v4, but would also add - be careful
>> with protocol all as well. You may end up shaping/dropping "critical"
>> packets like arp.
>
> Not sure I understand, arp is matched with all? ip v4 is not?

Both are matched with all, I am just saying that if you modify some
setup by changing protocol ip to protocol all in order to catch ipv6
then you may or may not (depending on exact setup) need to modify things
because all catches arp/other traffic as well as ipv6.
You could just add another filter, protocol ipv6 ... is valid.

> We ended up adding an explicit arp prioritization to cake recently.
>
> (see https://github.com/dtaht/sch_cake/commit/644b7efb2a552ba76871e65033c58275c15207f9
> )
>
> cake eliminates a whole raft of other oft-required tc magic, I hope we
> get around to mainlining it this year.

I do like the sound of cake a lot and have skimmed the archives a bit.