dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
5190
share rss forum feed

thevolman

join:2013-06-15
Wake Forest, NC

QoS on ZyXel USG 200 and USG 50 using IPSec VPN

I am having trouble getting QoS working over an IPSec VPN. I have two remote sites using USG 50s. The main site has a USG 200. I have the VPNs setup without issue and traffic is working fine. My problem is the remote sites have some VoIP phones which attach to a phone switch at the main site. These phones use UDP port 6000-6010 to attach to the main site.

I have tried to use Policy Routes and the BWM section to give this UDP traffic highest priority with some reserved bandwidth. However, I have used a test program which simulates the VoIP traffic and if I load the WAN port with egress traffic some of the VoIP traffic is getting dropped.

I have shaped the wan1 egress well below the up speed which is 5Mbps. I am starting to think since the traffic is encapsulated within the ESP protocol frame, the ZyXel does work at reserving bandwidth for this UDP traffic within the IPSec VPN.

I need help from some of you ZyXel experts.

OGalati

join:2005-08-19
Argentina
There are some pieces of info in the IP header that are not encapsulated. You could use them as classification criteria for QoS:
- ToS: bits 8-15. It's useful if you can set this info before the packets arrive to QoS engine. Some phones are able to do this.
- Lenght: bits 16-31. VoIP packets tend to be small. This will catch other small packets as well, as outgoing ACKs.

Regards.

lorennerol
Premium
join:2003-10-29
Seattle, WA
reply to thevolman
I tried for six months to get BWM/QoS for SIP working on both the USG series and older ZyXEL routers. I involved tech support and the case was escalated. I never made any improvement: Any heavy load on the upstream or downstream Internet connection would degrade voice quality.

thevolman

join:2013-06-15
Wake Forest, NC
reply to OGalati
I have also tried using the diff srv code points (TOS byte). The phones set this to x'46'. However, this doesn't seem to work either. I think there is something wrong with the way this device handles priority traffic in general!

I assume it is using Linux TC and I know TC can be set correctly to do this function. I hope ZyXel gets this fixed. Not having good QoS is really BAD!

JPedroT

join:2005-02-18
kudos:2
reply to lorennerol
Downstream is out of your control anyway, it needs to be done upstream to have it done well.

Upstream, just depends on the settings in my experience. Problem is how much do you want to sacrifice the rest of your traffic to have good VoIP.
--
"Perl is executable line noise, Python is executable pseudo-code."

lorennerol
Premium
join:2003-10-29
Seattle, WA
said by JPedroT:

Downstream is out of your control anyway, it needs to be done upstream to have it done well.

There a good bit of reasonable debate about downstream. Apparently it's somewhat controllable by delaying acks.

And upstream didn't make any difference. ZyXEL support threw in the towel as well. We ditched the SIP trunks and brought in a PRI.

JPedroT

join:2005-02-18
kudos:2
How do you delay acks on UDP?

lorennerol
Premium
join:2003-10-29
Seattle, WA
said by JPedroT:

How do you delay acks on UDP?

You don't. How much downstream traffic is UDP?

JPedroT

join:2005-02-18
kudos:2

1 edit
I expect quite a lot.

P2P and Streaming for instance are mainly UDP based.

So then the question is, how much of your data is TCP / UDP based.

Also ACK just acknowledges packets, its when it does not arrive you get TCP to backoff, but dependent on what type of congestion avoidance algorithm your hosts are running, what you will see/experience is a crapshot, go look at bufferbloat information for the gory details.

Most likely you will see the TCP sawtooth, where TCP blasts of and increases its rate until it backs off due to packet loss, where it halves its rate and starts to increase again. So you will have intermittent that packets will be dropped on an interface due to saturation. But this is dependent on what QoS runs on the interface.
If no QoS is done upstream then it most likely taildrops until the send buffer got room for the next packet. Ie your UDP/RTP goes down the drain and how many packets can you lose before the VoIP call goes down the drain?

Now if you got some QoS running upstream, for instance something simple as a L2 802.11p you can prioritise your VoIP traffic to not be dropped and what ever the other traffic does, really doesn't matter.

Now if you QoS on your WAN interface and your WAN link is 1Mbps and there is 10Mbps heading your way, the interface upstream from you will drop 9Mbps. And I can assure you that a big chunk of your VoIP call is a part of those 9Mbps.

For upstream and it not working, I have no reason to doubt you, but you are sure that your VoIP data was not dropped before it arrived at the USG? On an intermittent Switch etc?

I do not have access from home, but I can find out the ratio of udp vs tcp on customers network, their an ISP and it will be a nice rule of thumb to go by.

--
"Perl is executable line noise, Python is executable pseudo-code."

JPedroT

join:2005-02-18
kudos:2
Ok, I did a quick check with a colleague and he said right now, in the network he was monitoring, udp was about 15% of total amount of data in the network. Thats a network with about 5000k customers and a mix of 70-30 consumer/business users.

--
"Perl is executable line noise, Python is executable pseudo-code."

lorennerol
Premium
join:2003-10-29
Seattle, WA
reply to thevolman
What I can say with certainly, is that in a small office with less than a dozen employees, but pretty heavy Internet usage, mostly downstream, SIP trunks to an internally hosted FreePBX server were not at all viable. I can't say for certain where or in which direction packets were dropping, but it was bad enough that most calls were impacted and many dropped outright. We tried all sorts of things with the two ZyWALLs (a Z5 and a USG100) and nothing made any tangible difference.

If there is way to delay acks on TCP traffic to effect some kind of downstream QoS, it might have helped, even if TCP is only 85% of the usage. This is a business-only network, so we can easily block all P2P traffic.

thevolman

join:2013-06-15
Wake Forest, NC
reply to JPedroT
In my case, I was ONLY testing with the uplink traffic. I know controlling the downlink traffic is not really possible unless I control the TCP traffic using acks to control the TCP window size and reserve bandwidth for the UDP traffic.

Just using the uplink traffic, this router doesn't do QoS correctly.

JPedroT

join:2005-02-18
kudos:2
Are you able to get packet captures etc and document a proof? IFfyou can fire it off to ZyXEL and somebody there will look at it.
--
"Perl is executable line noise, Python is executable pseudo-code."


Brano
I hate Vogons
Premium,MVM
join:2002-06-25
Burlington, ON
kudos:12
Reviews:
·TekSavvy DSL
·Bell Fibe
reply to thevolman
The key thing for BWM / QoS working properly is setting your interface speed.
Some pointers:
»Re: SIP BWM for Zywall USG 20W V3.00
»Re: SIP BWM for Zywall USG 20W V3.00

To be hones though, this seems to work but I never gave it proper stress testing.

thevolman

join:2013-06-15
Wake Forest, NC
reply to JPedroT
I have given ZyXel plenty of information. They have been working on the issue for two weeks. I have exchanged several emails with them.

thevolman

join:2013-06-15
Wake Forest, NC
reply to Brano
Try the stress test, I think you might be surprised.!

dtaht

join:2013-08-02
reply to JPedroT
controlling the downlink traffic is totally feasible using an ingress shaper tied to (in the case of linux), ifb or imq. You will want to then shape the traffic using some form of aqm + some sort of packet scheduler. Multiple forms of this advanced qos exist in things like openwrt, dd-wrt, cerowrt, gargoyle, etc, with htb or hfsc + fq_codel rapidly becoming the default across those oses.

JPedroT

join:2005-02-18
kudos:2
Dave, I'm in awe of your work on bufferbloat, but I do not agree that you will get complete control with an ingress shaper when a interface upstream manages to saturate the link down to the device you run your shaper on. My assumption is that the upstream interface is managing to keep your link full.

This is my experience in deployed settings and own test, especially observable when the link is smaller ala dsl and low tier cable etc. 100Mbps and 1Gbps I expect that you have more bandwidth than you really use.
--
"Perl is executable line noise, Python is executable pseudo-code."