www.zeroshell.org Forum Index www.zeroshell.org
Linux Distribution for server and embedded devices
 
 SearchSearch  RegisterRegister  UsergroupsUsergroups 
 ProfileProfile  Log inLog in  Log in to check your private messagesPrivate Message 

Issue in QoS tagging

 
Post new topic   Reply to topic    www.zeroshell.org Forum Index -> Signal a BUG
View previous topic :: View next topic  
Author Message
atheling



Joined: 24 Sep 2009
Posts: 212

PostPosted: Sun Nov 29, 2009 4:28 am    Post subject: Issue in QoS tagging Reply with quote

I've set up a couple of simple rules for QoS. Basically following the documentation found elsewhere on this site. But I've noticed an issue with the QoS tagging.

Code:

Chain FORWARD (policy ACCEPT 644K packets, 473M bytes)
 pkts bytes target     prot opt in     out     source               destination         
 692K  497M MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK set 0x0
10007 2768K MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           LAYER7 l7proto sip MARK set 0xb
10007 2768K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match !0x0
 2440  664K MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           LAYER7 l7proto rtp MARK set 0xb
 2440  664K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match !0x0
 1804  176K MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           LAYER7 l7proto skypetoskype MARK set 0xe
 1804  176K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match !0x0
15364  921K MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spt:25 MARK set 0xd
15364  921K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match !0x0
18790   20M MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:25 MARK set 0xd
18790   20M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match !0x0


Please note my rule added before all others to clear the mark. This rule is not automatically generated by ZS and is my fix for the issue.

If you are running with multiple ISPs/WAN interfaces then packets may already be tagged with a value indicating the routing realm. So the first QoS rule will be properly evaluated then the rule following will be erroneously triggered because mark is not 0x0 (already set by the pre-routing rules).

I haven't yet looked into the scripts to see which one would be the best place to fix this by the simple addition of a rule to clear the mark before tagging for the QoS queue to use.
Back to top
View user's profile Send private message
fulvio
Site Admin


Joined: 01 Nov 2006
Posts: 1036

PostPosted: Sun Nov 29, 2009 6:35 am    Post subject: Reply with quote

QoS and net balancer cannot take place on the same box. On my opinion what you suggest breaks the connection persistence on a gateway.
Let me know if you used your configuration successfully instead.

Regards
Fulvio
Back to top
View user's profile Send private message Send e-mail
atheling



Joined: 24 Sep 2009
Posts: 212

PostPosted: Sun Nov 29, 2009 1:02 pm    Post subject: Reply with quote

Hi fulvio,

Thank you for the prompt reply to both my posts.

I do have my box setup this way at the moment. I don't know if the QoS queuing is working as I haven't looked into how to monitor that yet.

I am running in failover so I don't know if load balance works. But the connections that are coming in on my slow link are definitely being replied to on my slow link.

I haven't found an explanation on when/where the queuing decision is made. But if the routing realm is saved to the connection in the mangle FORWARD chain prior to setting the mark for QoS then it seems like both load balance and QoS should work on the same box.

Thanks for a great program!
Back to top
View user's profile Send private message
atheling



Joined: 24 Sep 2009
Posts: 212

PostPosted: Sun Nov 29, 2009 1:12 pm    Post subject: Reply with quote

Actually, this should not break connection persistence at all because the realm of the connection is picked up then immediately saved in the mangle POSTROUTING chain.

I probably does, however, break QoS. (I'm guessing that the actually device queuing happens after the POSTROUTING chain and at that point the mark is set based on the routing realm.)

Can the QoS tagging be moved to the POSTROUTING chain and be done after the realm tag is saved in the connection?
Back to top
View user's profile Send private message
fulvio
Site Admin


Joined: 01 Nov 2006
Posts: 1036

PostPosted: Sun Nov 29, 2009 1:42 pm    Post subject: Reply with quote

Probably you are right. Let me investigate about.

Regards
Fulvio
Back to top
View user's profile Send private message Send e-mail
atheling



Joined: 24 Sep 2009
Posts: 212

PostPosted: Mon Nov 30, 2009 2:11 am    Post subject: Reply with quote

fulvio wrote:
Probably you are right. Let me investigate about.

Regards
Fulvio


Hi Fulvio!

For what is it worth, I've added the equivalent QoS tagging as ZS creates in the mangle FORWARD chain to my mangle POSTROUTING chain as follows. The ZS created QoS marks in the mangle FORWARD chain are meaninglyless as they are overwritten by the load balance/failover marking at the beginning of the POSTROUTING chain. This setup seems to do both QoS and load balance/failover. At least conntrack shows the connections where I'd expect them and tc seems to show traffic in each queue.

Code:

root@zeroshell root> iptables -t mangle -L -v -n
Chain PREROUTING (policy ACCEPT 1912K packets, 1371M bytes)
 pkts bytes target     prot opt in     out     source               destination         
1912K 1371M CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0           CONNMARK restore
1912K 1371M NetBalancer  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
56966 6938K custom_preroute  all  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW

Chain INPUT (policy ACCEPT 97148 packets, 8731K bytes)
 pkts bytes target     prot opt in     out     source               destination         
97148 8731K NetBalancer  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 1739K packets, 1333M bytes)
 pkts bytes target     prot opt in     out     source               destination         
1815K 1363M MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK set 0x0
16381 5068K MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           LAYER7 l7proto sip MARK set 0xb
16381 5068K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match !0x0
 4014 1120K MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           LAYER7 l7proto rtp MARK set 0xb
 4014 1120K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match !0x0
 3760  392K MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           LAYER7 l7proto skypetoskype MARK set 0xe
 3760  392K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match !0x0
26795 1581K MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spt:25 MARK set 0xd
26795 1581K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match !0x0
24958   21M MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:25 MARK set 0xd
24958   21M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match !0x0

Chain OUTPUT (policy ACCEPT 92498 packets, 19M bytes)
 pkts bytes target     prot opt in     out     source               destination         
92498   19M NetBalancer  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
92498   19M OpenVPN    all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain POSTROUTING (policy ACCEPT 1901K packets, 1380M bytes)
 pkts bytes target     prot opt in     out     source               destination         
 106K   11M NB_CT_POST  all  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW
1907K 1381M NB_STAT    all  --  *      *       0.0.0.0/0            0.0.0.0/0           
 720K  601M custom_postroute  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain NB_CT_POST (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           realm 0x66 MARK set 0x66
34590 2506K MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           realm 0x65 MARK set 0x65
 106K   11M CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0           CONNMARK save 

Chain NB_STAT (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0            all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x66
34590 2506K            all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x65

Chain NetBalancer (3 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain OpenVPN (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain custom_postroute (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 720K  601M MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK set 0x0
 1329  517K MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           LAYER7 l7proto sip MARK set 0xb
 1329  517K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match !0x0
  542  181K MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           LAYER7 l7proto rtp MARK set 0xb
  542  181K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match !0x0
  893  102K MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           LAYER7 l7proto skypetoskype MARK set 0xe
  893  102K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match !0x0
 1069  127K MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:25 MARK set 0xd
 1069  127K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match !0x0
 1980  124K MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spt:25 MARK set 0xd
 1980  124K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match !0x0

Chain custom_preroute (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 6668  380K MARK       all  --  ETH01  *       0.0.0.0/0            0.0.0.0/0           MARK set 0x65
 6668  380K CONNMARK   all  --  ETH01  *       0.0.0.0/0            0.0.0.0/0           CONNMARK save 
 4355  213K MARK       all  --  ppp0   *       0.0.0.0/0            0.0.0.0/0           MARK set 0x66
 4355  213K CONNMARK   all  --  ppp0   *       0.0.0.0/0            0.0.0.0/0           CONNMARK save 
root@zeroshell root> tc -s class show dev ETH01
class htb 1:11 parent 1:1 leaf 11: prio 0 rate 200000bit ceil 18000Kbit burst 1699b cburst 10633b
 Sent 142731 bytes 183 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 lended: 124 borrowed: 59 giants: 0
 tokens: 62656 ctokens: 4575

class htb 1:10 parent 1:1 leaf 10: prio 1 rate 8bit ceil 18000Kbit burst 1600b cburst 10633b
 Sent 282561507 bytes 719771 pkt (dropped 0, overlimits 0 requeues 0)
 rate 568bit 1pps backlog 0b 0p requeues 0
 lended: 654912 borrowed: 64859 giants: 0
 tokens: -58593719 ctokens: 4575

class htb 1:1 root rate 18000Kbit ceil 18000Kbit burst 10633b cburst 10633b
 Sent 285631267 bytes 747936 pkt (dropped 0, overlimits 0 requeues 0)
 rate 896bit 1pps backlog 0b 0p requeues 0
 lended: 64918 borrowed: 0 giants: 0
 tokens: 4575 ctokens: 4575

class htb 1:13 parent 1:1 leaf 13: prio 2 rate 8bit ceil 18000Kbit burst 1600b cburst 10633b
 Sent 2799425 bytes 27063 pkt (dropped 0, overlimits 0 requeues 0)
 rate 320bit 1pps backlog 0b 0p requeues 0
 lended: 27063 borrowed: 0 giants: 0
 tokens: -58593719 ctokens: 4596

class htb 1:14 parent 1:1 leaf 14: prio 0 rate 8bit ceil 18000Kbit burst 1600b cburst 10633b
 Sent 127604 bytes 919 pkt (dropped 0, overlimits 0 requeues 0)
 rate 8bit 0pps backlog 0b 0p requeues 0
 lended: 919 borrowed: 0 giants: 0
 tokens: -58593719 ctokens: 4540

root@zeroshell root>


By the way, I am loving the way ZS's iptables and conntrack handle SIP calls. I can now have my Asterisk server allow reinvites and the IP phones/ATAs on my LAN reconnect correctly with external end points. I keep making test calls, each one works perfectly and conntrack shows just exactly what I'd hope for the connections.

Thank you so much for putting a great package together!
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    www.zeroshell.org Forum Index -> Signal a BUG All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group