[LARTC] Re: vlan interfaces and tc
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
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 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/ 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
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: [EMAIL PROTECTED]: BROADCAST,MULTICAST,SLAVE,UP,1 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/ 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 1Kbit class hfsc 1:21 parent 1: sc m1 0bit d 0ns m2 1Kbit ... 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 1Kbit 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 1Kbit 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/ 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
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 [solved]
Christian Benvenuti wrote: 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 ! ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Re: vlan interfaces and tc
On Mon, 11 Jun 2007 22:11:09 +0200 Michal Soltys [EMAIL PROTECTED] 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: [EMAIL PROTECTED]: BROADCAST,MULTICAST,SLAVE,UP,1 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/ 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 1Kbit class hfsc 1:21 parent 1: sc m1 0bit d 0ns m2 1Kbit ... 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 1Kbit 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 1Kbit 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/ 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 [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
