tc and IPv6 : any experiences ?

tc and IPv6 : any experiences ?

[Willy MANGA]

Hello,
is there somebody here who can share a little bit how he is using tc
with native IPv6 address ?

I'm using Debian jessie and I may be wrong but I don't find a good
documentation on that topic. :-\

Actually, I have a dual network and only shaping v4 traffic [1]



1.
https://wiki.auf.org/wikiteki/ZAC/Yaound%C3%A9/Configuration/Contr%C3%B4leDuTraffic

Re: tc and IPv6 : any experiences ?

[Alan Goodman]

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

Alan


On 13/01/17 13:21, Willy MANGA wrote:
> Hello,
> is there somebody here who can share a little bit how he is using tc
> with native IPv6 address ?
>
> I'm using Debian jessie and I may be wrong but I don't find a good
> documentation on that topic. :-\
>
> Actually, I have a dual network and only shaping v4 traffic [1]
>
>
>
> 1.
> https://wiki.auf.org/wikiteki/ZAC/Yaound%C3%A9/Configuration/Contr%C3%B4leDuTraffic
> --
> To unsubscribe from this list: send the line "unsubscribe lartc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tc and IPv6 : any experiences ?

[Dave Taht]

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


> Alan
>
>
>
> On 13/01/17 13:21, Willy MANGA wrote:
>>
>> Hello,
>> is there somebody here who can share a little bit how he is using tc
>> with native IPv6 address ?
>>
>> I'm using Debian jessie and I may be wrong but I don't find a good
>> documentation on that topic. :-\
>>
>> Actually, I have a dual network and only shaping v4 traffic [1]
>>
>>
>>
>> 1.
>>
>> https://wiki.auf.org/wikiteki/ZAC/Yaound%C3%A9/Configuration/Contr%C3%B4leDuTraffic
>> --
>> To unsubscribe from this list: send the line "unsubscribe lartc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe lartc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: tc and IPv6 : any experiences ?

[Andy Furniss]

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.

Re: tc and IPv6 : any experiences ?

[Dave Taht]

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?

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.




-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: tc and IPv6 : any experiences ?

[Andy Furniss]

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.