- This topic is empty.
-
Posts
-
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.
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.
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
FulvioHi 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!
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?
@fulvio wrote:
Probably you are right. Let me investigate about.
Regards
FulvioHi 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.
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!
- You must be logged in to reply to this topic.