[LARTC] Re: vlan interfaces and tc

[LARTC] Re: vlan interfaces and tc

[Christian Benvenuti]

Hi, 

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

It depends on what you want to control.

The QoS you configure on the VLAN interface is only enforced for the
traffic that goes through the VLAN interface.
(Note that in this case the VLAN interface is a L3 interface).

The QoS you configure on the real interface is enforced for all the
traffic that goes through that interface (regardless of whether it
is injected through a virtual interface).

> Or are either of them allowed, depending on what I need ?

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.

> 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) ?

Yes, it traverses both.
On the egress path, it traverses first eth0.11 and then eth0.
On the ingress path, it traverses first eth0 and then eth0.11

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


_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Re: vlan interfaces and tc

[Michal Soltys]

Christian Benvenuti wrote:
> 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 ?
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[LARTC] Re: vlan interfaces and tc

[Christian Benvenuti]

>Christian Benvenuti wrote: 
>> 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).

This is one important detail you probably missed:

>(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 )
                                 ^^^^^^^^^^^

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


_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Re: vlan interfaces and tc

[Michal Soltys]

Christian Benvenuti wrote:
> 
> This is one important detail you probably missed:
> 
>> (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.11@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.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[LARTC] Re: vlan interfaces and tc

[Christian Benvenuti]

Hi,
>.. 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 ]




_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Re: vlan interfaces and tc

[Stephen Hemminger]

On Mon, 11 Jun 2007 22:11:09 +0200
Michal Soltys <nozo@ziu.info> wrote:

> Christian Benvenuti wrote:
> > 
> > This is one important detail you probably missed:
> > 
> >> (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.11@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.

Doing traffic control on vlan's may work as expected because
the vlan pseudo-device does not have any transmit queue.

-- 
Stephen Hemminger <shemminger@linux-foundation.org>
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc