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