Have a client that will be going over an MPLS for VOIP. They are currently on 5.2.1.
Their provider requires the following DSCP coding and priorities:
DSCP 24 - SIP Signaling - Medium High DSCP 34 - Notifier Signaling - Medium High DSCP 46 - RTP Audio - EF Top Priority All other traffic best effort.
What is the best way to configure this? Note - the current setup is a single VLAN for VOIP and the idea is all traffic going in and out of the MPLS needs to recognize and respond to the various DSCP codes for this traffic appropriately.
I've looked over the documentation for DSCP and TOS, and it appears there is multiple ways to accomplish this.
One way I suspect would be multiple traffic shapers for each DSCP code a separate policy for each one with each traffic shaper applied, although it seems to me this is not the best way to do it.
Any thoughts/suggestions?
Thanks!
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
You can build a fwpolicy with fwd/rev dscp enabled and set the value per-interesting traffic. This works very well if you have a handful of policies to manage
e.g
edit 126 set srcintf "port1" set dstintf "wan1" set srcaddr "SoftSWITCHOccidental" set dstaddr "SoftSWITCHOriental" set action accept set schedule "always" set service "CUST-90" set diffserv-forward enable set diffservcode-forward 101000
set comments " TO ALLOW SIGNAL " next end
You can also allow prioritization within the firewall using a predefine 3 queues model for the scheduler
set traffic-shaper
and a shaper
edit "SIPudp-rate" set guaranteed-bandwidth 8000 set maximum-bandwidth 10000 set per-policy enable set priority low low medium high next
Just ensure you honer DSCP/TOS and trust it along your interfaces if you have any QoS enabled switches. It might beneficial to spot check DSCP values are no dropped or clear to 00/00 on each end of the MPLS provider.
Ken
PCNSE
NSE
StrongSwan
emnoc wrote:You can build a fwpolicy with fwd/rev dscp enabled and set the value per-interesting traffic. This works very well if you have a handful of policies to manage
e.g
edit 126 set srcintf "port1" set dstintf "wan1" set srcaddr "SoftSWITCHOccidental" set dstaddr "SoftSWITCHOriental" set action accept set schedule "always" set service "CUST-90" set diffserv-forward enable set diffservcode-forward 101000
set comments " TO ALLOW SIGNAL " next end
You can also allow prioritization within the firewall using a predefine 3 queues model for the scheduler
set traffic-shaper
and a shaper
edit "SIPudp-rate" set guaranteed-bandwidth 8000 set maximum-bandwidth 10000 set per-policy enable set priority low low medium high next
Just ensure you honer DSCP/TOS and trust it along your interfaces if you have any QoS enabled switches. It might beneficial to spot check DSCP values are no dropped or clear to 00/00 on each end of the MPLS provider.
Ken
So - for the first example, I'd essentially have a policy for each of the three types of traffic and set the DSCP inside the policy for each one - does that also set the priorities automatically, then, based on the DSCP value, or do I specify that somewhere else? I like this, currently there's not a ton of policies and I can't see a need for a lot of policies for this because its a devoted VLAN.
For the second possibility - if I create 3 shapers - one for each DSCP code, do I then need to identify a max/min bandwidth, or just make sure I have the priorities right? The way I see it - (and I could be wrong) - this one MIGHT be easier to implement as I could use a service of all, and then, one policy for each shaper with same source/destination?
Thanks,
Brent
Your understanding is correct, but one part needs to be cleared. If you set the DSCP on the policy and there's not TrafficShaper profile, you won't have QoS schedule against the 3 queues. All traffic is treat the same.
FWIW, The firewall has 4 queues;
BE ( best effort )
low
medium
high
And with no TSprofile defined, all is riding against BE. If your model is complex or become complex, you need to keep in consideration all of the totals within in TSprofiles to be sure you don't oversubscribe or deplete a queue limit.
But every else you said is correct, you defined your 3 TS profiles with the guaranteed bandwidth and queue. You can apply the DSCP l3 header fix up within the TS profile & apply it to the policy(s). I've always built mind with unique TS profiles for realtime data ( voice-path and signaling )
Also you can adjust the TOS or DSCP mapping in the system global setting and monitor TS usage in the monitor.
config sys global
set traffic-priority tos or dscp
end
I believe this set do we look and match on the 6bit TOS or full DSCP for matching.
And then remember to carry DSCP from the carrier inbound if you need to carry across the "ingress" interface to the application. Outside of that,you logic is correct.
If your using a ATT Eman or whatever it's not called, make you sure you monitor the DSCP markings after the turn up or activation. They have bad practices & history and will screw it up now or later from my experience. US Sprint and Patec was silghtly better ;)
PCNSE
NSE
StrongSwan
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1712 | |
1093 | |
752 | |
447 | |
231 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.