Traffic Shaping with VoIP/RDP over Ipsec

eri--

Because you need to prioritize even IKE traffic

mphilippi

Can you go deeper on that?
You mean setting the whole ipsec traffic to "higher priority" in the wizard?
What I've already done is prioritize VoIP on the ipsec interface, as I said.

BTW: We use HFSC for the queues. Is this possible with HFSC or should we switch to PRIQ or even CBQ?

MLIT

@mphilippi:

I already created a rule on the ipsec interface. It puts TCP/UDP traffic which goes to the PBX at office A in the qVoip queue.
On the queue status page, I can see packets in the qVoip queue when there are calls to office B. All other queues are empty if there is no other traffic going on so I'm quite sure that pfSense puts the traffic in the right queue but there are still package drops in the qVoip queue when the internet connection is under load.

Did you use "match" on the rules and not "pass" ?

I think I ended up putting my rules in the floating rules.

mphilippi

That's what I did now. Removed every queue rule from the interfaces and added floating rules, then resetted states.
Attached, you can see the floating rules. VoIP_hosts includes the office B phones, the office B router and the PBX adresses.

I also changed some queue bandwith values:

queue root_pppoe1 on pppoe1 bandwidth 900Kb priority 0 {qInternet}
queue  qInternet on pppoe1 bandwidth 900Kb hfsc( red ecn upperlimit 900Kb ) {qACK, qDefault, qVoIP, qOthersHigh, qOthersLow}
queue   qACK on pppoe1 bandwidth 135Kb hfsc( red ecn ) 
queue   qDefault on pppoe1 bandwidth 135Kb hfsc( red ecn default ) 
queue   qVoIP on pppoe1 bandwidth 315Kb hfsc( red ecn realtime 315Kb ) 
queue   qOthersHigh on pppoe1 bandwidth 270Kb hfsc( red ecn ) 
queue   qOthersLow on pppoe1 bandwidth 45Kb hfsc( red ecn ) 
queue root_bge1 on bge1 bandwidth 1Gb priority 0 {qLink, qInternet}
queue  qLink on bge1 bandwidth 200Mb qlimit 500 hfsc( red ecn default ) 
queue  qInternet on bge1 bandwidth 15Mb hfsc( red ecn upperlimit 15Mb ) {qACK, qVoIP, qOthersHigh, qOthersLow}
queue   qACK on bge1 bandwidth 2.25Mb hfsc( red ecn ) 
queue   qVoIP on bge1 bandwidth 5.25Mb hfsc( red ecn realtime 5.25Mb ) 
queue   qOthersHigh on bge1 bandwidth 4.50Mb hfsc( red ecn ) 
queue   qOthersLow on bge1 bandwidth 750Kb hfsc( red ecn )

Is this the correct way of doing it or do you have some more tips? There are still some issues with voice quality.

floatingrules.jpg_thumb

MLIT

I believe the last rule that matches gets applied unless you check the "Quick" box in the rules (I think that tells it to stop processing the rules when it matches that specific rule).

So I think all your rules are written backwards.

mphilippi

Ah, thanks for the hint!

We are running the new configuration for 3 days now and it looks quite smooth. Sometimes, calls are interupted for about a second. You then can't even hear the static noise in the call.
It only happens when the internet connection is used very much. Do you have another hint on what to check?
The queues are still the same as before.

Harvy66

Are you sure 150Kb/s is enough for your VoIP? HSFC realtime will penalize you for going over your allotted amount. If you have it set to 150Kb/s and you start using more, the amount more that you use will count negatively towards your future realtime bandwidth, reducing it below 150Kb/s. The goal is never to use link share for realtime traffic.

It rarely hurts to allocate more bandwidth to low bandwidth traffic, since any unused bandwidth gets shared out anyway.

This is probably due to some of my lack of understanding of HFSC, but personally, I stopped using Realtime specifically because it gets punished for using any link share. Rule of thumb is a link is at saturation when it reaches 80% load. At this point, jitter starts to become common place. For traffic that doesn't care about jitter or latency, like bulk transfers, they can use 100% can not care. For VoIP traffic, it cares. Find your target bandwidth and add 25% more.

Of course, if your issue is lack of bandwidth, there is nothing you can do but add more. All traffic shaping does is allow your to chose winners and losers in a well defined way when fighting for a limit resource.

mphilippi

I think you've missed the newer configuration, posted earlier but not in the first post.

queue root_pppoe1 on pppoe1 bandwidth 900Kb priority 0 {qInternet}
queue  qInternet on pppoe1 bandwidth 900Kb hfsc( red ecn upperlimit 900Kb ) {qACK, qDefault, qVoIP, qOthersHigh, qOthersLow}
queue   qACK on pppoe1 bandwidth 135Kb hfsc( red ecn ) 
queue   qDefault on pppoe1 bandwidth 135Kb hfsc( red ecn default ) 
queue   qVoIP on pppoe1 bandwidth 315Kb hfsc( red ecn realtime 315Kb ) 
queue   qOthersHigh on pppoe1 bandwidth 270Kb hfsc( red ecn ) 
queue   qOthersLow on pppoe1 bandwidth 45Kb hfsc( red ecn ) 
queue root_bge1 on bge1 bandwidth 1Gb priority 0 {qLink, qInternet}
queue  qLink on bge1 bandwidth 200Mb qlimit 500 hfsc( red ecn default ) 
queue  qInternet on bge1 bandwidth 15Mb hfsc( red ecn upperlimit 15Mb ) {qACK, qVoIP, qOthersHigh, qOthersLow}
queue   qACK on bge1 bandwidth 2.25Mb hfsc( red ecn ) 
queue   qVoIP on bge1 bandwidth 5.25Mb hfsc( red ecn realtime 5.25Mb ) 
queue   qOthersHigh on bge1 bandwidth 4.50Mb hfsc( red ecn ) 
queue   qOthersLow on bge1 bandwidth 750Kb hfsc( red ecn )

I assigned 35% of my upload bandwidth (~ 900 Kbit/s) to VoIP which is 315 Kbit/s. From what I've seen, one VoIP call consumes about 100-150 Kbit/s.

Nullity

@Harvy66:

Are you sure 150Kb/s is enough for your VoIP? HSFC realtime will penalize you for going over your allotted amount. If you have it set to 150Kb/s and you start using more, the amount more that you use will count negatively towards your future realtime bandwidth, reducing it below 150Kb/s. The goal is never to use link share for realtime traffic.

It rarely hurts to allocate more bandwidth to low bandwidth traffic, since any unused bandwidth gets shared out anyway.

This is probably due to some of my lack of understanding of HFSC, but personally, I stopped using Realtime specifically because it gets punished for using any link share. Rule of thumb is a link is at saturation when it reaches 80% load. At this point, jitter starts to become common place. For traffic that doesn't care about jitter or latency, like bulk transfers, they can use 100% can not care. For VoIP traffic, it cares. Find your target bandwidth and add 25% more.

Of course, if your issue is lack of bandwidth, there is nothing you can do but add more. All traffic shaping does is allow your to chose winners and losers in a well defined way when fighting for a limit resource.

Kinda maybe, but it is a moot point since it is near impossible (I tried; failed) to exclusively set real-time in pfSense. "Bandwidth" is link-share, meaning real-time's value will be exceeded as link-share will proportionally make use of all excess bandwidth.

Nullity

With pftop, confirm that everything is going to the proper queues. This is usually my problem.

Queue bitrates on sending interface must be the lowest bitrate of the route. (I think you have success already)

What you have seems like it should work.

I dunno crap about IPSEC/VPN.