Issue in QoS tagging

Home Page Forums Network Management Signal a BUG Issue in QoS tagging

This topic contains 4 replies, has 0 voices, and was last updated by  atheling 9 years, 7 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #42067

    atheling
    Member

    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.

    #49170

    imported_fulvio
    Participant

    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

    #49171

    atheling
    Member

    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!

    #49172

    atheling
    Member

    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?

    #49173

    imported_fulvio
    Participant

    Probably you are right. Let me investigate about.

    Regards
    Fulvio

    #49174

    atheling
    Member

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


    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!

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.