vlan interfaces and tc

[Michal Soltys]

Hello

I have few questions regarding tc functionality (qdiscs, classes, etc.) when
vlans are in use. For example, consider interface eth0, for which I create
and extra vlan with vconfig, let's say eth0.11. Then using tc I can add
usual things - qdiscs, filters, ... - to both eth0 and eth0.11. The
questions are:

- on which interface - virtual or real, should I actually use tc ? Or are
either of them allowed, depending on what I need ? If so:

- what happens if both interfaces - virtual and real have disciplines /
filters ? Does packet traverse both (I'd assume, first through eth0.11 than
through eth0) ?

[Christian Benvenuti]

This post might be inappropriate. Click to display it.

[Michal Soltys]

Post by Christian Benvenuti
Hi,
[cut]
Yes they are both allowed.
This means, for example, that the traffic that originates from
or that is addressed to a VLAN interface can potentially go through
two independent QoS configurations.
Depending on what you want to achieve, you may configure QoS
only on the VLAN interface, only on the real interface, or
on both.
[cut]

Thanks for the answers. I've made some simple tests and there seems to
be one thing that doesn't work on virtual interfaces - classifying.
Whenever I used filters - u32, or fw paired with iptables' mark target,
or simply classify target - it was completely ignored on vlan interface,
while the same setup on real interface worked fine (if it wasn't going
through vlan earlier - look question below). So maybe queuing, despite
it's possible to set on vlan, shouldn't be used ? (it's weird a bit,
especially if someone wanted to have both disciplines at the same time).

One more question though - I've noticed that marks or direct classify
don't survive going through vlan interface (seems logical), so I can't
use them later on the real one. In the past someone asked it on the
list, and the answer was to use negative offsets with u32 filter,
looking for vlan tags in layer 2 header. It seems to work fine, but is
it actually safe to use ?

[Christian Benvenuti]

Post by Michal Soltys

Post by Christian Benvenuti
Hi,
[cut]
Yes they are both allowed.
This means, for example, that the traffic that originates from
or that is addressed to a VLAN interface can potentially go through
two independent QoS configurations.
Depending on what you want to achieve, you may configure QoS
only on the VLAN interface, only on the real interface, or
on both.
[cut]

Thanks for the answers. I've made some simple tests and there seems to
be one thing that doesn't work on virtual interfaces - classifying.
Whenever I used filters - u32, or fw paired with iptables' mark target,
or simply classify target - it was completely ignored on vlan interface,
while the same setup on real interface worked fine (if it wasn't going
through vlan earlier - look question below). So maybe queuing, despite
it's possible to set on vlan, shouldn't be used ? (it's weird a bit,
especially if someone wanted to have both disciplines at the same time).
(Note that in this case the VLAN interface is a L3 interface)

If you assign an IP address to the VLAN interface and you transmit
IP traffic on that interface, than the traffic goes through the VLAN
qdisc config and classification works (*).

#vconfig add eth2 500
#ifconfig eth2.500 10.0.10.1 netmask 255.255.255.0
<htb config here>
#tc filter add dev eth2.500 parent 1: protocol ip prio 1 \
u32 match ip dst 10.0.10.2 flowid 1:12
#ping 10.0.10.2

#tc -s -d filter list dev eth2.500
filter parent 1: protocol ip pref 1 u32
filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:12 (rule hit 120 success 120)
match 0a000a02/ffffffff at 16 (success 120 )
^^^^^^^^^^^

Post by Michal Soltys
One more question though - I've noticed that marks or direct classify
don't survive going through vlan interface (seems logical), so I can't
use them later on the real one.
In the past someone asked it on the
list, and the answer was to use negative offsets with u32 filter,
looking for vlan tags in layer 2 header. It seems to work fine, but is
it actually safe to use ?

To me it seems they do survive (I just tested it).
Can it be the same issue above (*) ?

Regards
/Christian
[ http://benve.info ]

[Michal Soltys]

Post by Christian Benvenuti

Post by Christian Benvenuti
(Note that in this case the VLAN interface is a L3 interface)

If you assign an IP address to the VLAN interface and you transmit
IP traffic on that interface, than the traffic goes through the VLAN
qdisc config and classification works (*).
[config cut]

When I was doing testing with some trivial setup, I did pretty much the same
thing as in your config (forward note - also checked htb, smaller mtu, vlan
if up and down).

In order:

#vconfig add eth0 11
#ip add add 192.168.20.10/24 dev eth0.11 broad +
#ip li set eth0.11 up

#tc qdisc add dev eth0.11 root handle 1:0 hfsc default 1
#tc class add dev eth0.11 parent 1:0 classid 1:1 hfsc sc rate 10mbit
#tc class add dev eth0.11 parent 1:0 classid 1:21 hfsc sc rate 10mbit

#tc filter add dev eth0.11 parent 1:0 proto ip prio 10 u32 flowid 1:21 \
match ip dst 192.168.20.1

#ip add sh dev eth0.11

12: ***@eth0: <BROADCAST,MULTICAST,SLAVE,UP,10000> mtu 1500 qdisc hfsc
link/ether 00:0c:f1:da:e9:46 brd ff:ff:ff:ff:ff:ff
inet 192.168.20.10/24 brd 192.168.20.255 scope global eth0.11

#tc -d filter sh dev eth0.11

filter parent 1: protocol ip pref 10 u32
filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800
bkt 0 flowid 1:21 match c0a81401/ffffffff at 16

#tc -d class sh dev eth0.11

class hfsc 1: root
class hfsc 1:1 parent 1: sc m1 0bit d 0ns m2 10000Kbit
class hfsc 1:21 parent 1: sc m1 0bit d 0ns m2 10000Kbit

... then I did

ping 192.168.20.1

... and ended with

#tc -d -s class sh dev eth0.11

class hfsc 1: root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
period 0 level 1

class hfsc 1:1 parent 1: sc m1 0bit d 0ns m2 10000Kbit
Sent 348 bytes 9 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
period 9 work 348 bytes rtwork 348 bytes level 0

class hfsc 1:21 parent 1: sc m1 0bit d 0ns m2 10000Kbit
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
period 0 level 0

#tc -d -s filter sh dev eth0.11

filter parent 1: protocol ip pref 10 u32
filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800
bkt 0 flowid 1:21 (rule hit 0 success 0)
match c0a81401/ffffffff at 16 (success 0 )


... so I'm probably missing / not seeing something simple, or I don't know.
This setup works for real interface, as well as for bonding. During testing,
real interface is normally working in 192.168.100/24 subnet.

"Moving" from OBSD I'm checking what I can and cannot do under linux, so my
kernel is a bit full atm, with majority of stuff compiled into it.

I'm using clean & patched gentoo here.

[Stephen Hemminger]

This post might be inappropriate. Click to display it.

[Christian Benvenuti]

Hi,

Post by Michal Soltys
.. so I'm probably missing / not seeing something simple, or I don't
know.
This setup works for real interface, as well as for bonding. During testing,
real interface is normally working in 192.168.100/24 subnet.

Is there an interface configured on the same VLAN on the other side
of the link?
If there is not, ARP fails (no one replies to the requests) and you
never transmit anything to 192.168.20.1 (which is why the filter is
not even tested).
For a quick test, you can hardcode the IP/MAC mapping with

ip neigh add 192.168.20.1 lladdr <PUT_HERE_A_MAC_ADDR> dev eth1.11

Your exact same config works on my system.

Regards
/Christian
[ http://benve.info ]

[Michal Soltys]

Post by Christian Benvenuti
Is there an interface configured on the same VLAN on the other side
of the link?
If there is not, ARP fails (no one replies to the requests) and you
[cut]

Bloody hell. I knew I missed something embarassing. Faked mac solved the
"issue".

Thanks for help !