Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
ewaizel
New Contributor II

QoS forwarding based on DSCP

We approach this forum to compare ideas and validate if any other user is experiencing the same problems and tried to apply a similar approach.

 

Our objective is simply for the Fortinet Firewalls to honor DSCP markings and queue different flows based on these priorities.  The overall challenge with Fortinet is how to make this possible. The platform in general seems a bit immature in the area of QoS; all related configuration and examples are very limited.

 

Fortinet typically focuses on traffic shaping as a way to influence flow priorities. Nevertheless, this approach will consider a traffic shaping option is applied to every single security policy.  We consider this does not scale for a busy firewall with hundreds of policies.  Instead, we explore the approach of applying QoS priorities on a packet by packet basis. This is briefly documented in Fortinet’s manuals. Nevertheless, there are few users that report having something like this in production.

 

We start by defining a system wide priority for all packets. By default in a new install, all flows are considered “medium” priority.  We decide to assume “low” as the standard priority for most flows which should be treated as best-effort.

 

In addition we decided to follow the DSCP approach which was recently introduced in version 5.2. Before this version Fortinet typically used ToS values that from our perspective is a very old approach that nobody else in the industry follows. 

 

The following command is applied to use DSCP.

 

config system global

   set traffic-priority dscp

 

Then, all flows are considered “low” priority by default.

 

config system global

   set traffic-priority-level low

 

Next, we proceed to define specific DSCP values with a higher priority. We consider this should be included by default in the OS. In ver 5.2.2 it is still not the case. In this brief list we mark the most typical flows to have a higher priority. DSCP=EF is considered as high; same as DSCP=CS5 & CS7. In our case, DSCP=41 will be considered medium priority.

 

config system dscp-based-priority

    edit 46

      # EF

        set ds 46

        set priority high

    next

    edit 34

      # AF41

        set ds 34

        set priority medium

    next

    edit 40

      # CS5

        set ds 40

        set priority high

    next

      # CS7

    edit 56

        set ds 56

        set priority high

    next

end

 

The following command helps confirm these values are properly applied:

 

diagnose sys traffic-priority list

 

Here is the output produced by this:

 

Traffic priority type is set to DSCP (DiffServ).

00:low    01:low    02:low    03:low    04:low    05:low    06:low    07:low

08:low    09:low    10:low    11:low    12:low    13:low    14:low    15:low

16:low    17:low    18:low    19:low    20:low    21:low    22:low    23:low

24:low    25:low    26:low    27:low    28:low    29:low    30:low    31:low

32:low    33:low    34:medium 35:low    36:low    37:low    38:low    39:low

40:high   41:low    42:low    43:low    44:low    45:low    46:high   47:low

48:low    49:low    50:low    51:low    52:low    53:low    54:low    55:low

56:high   57:low    58:low    59:low    60:low    61:low    62:low    63:low

 

Queuing

 

Considering all different flows are assigned to a specific priority, the next point is about queuing this on egress. Based on the documentation, packets will only use up to three of the six possible interface queues (queue 0 to queue 2; queue 0 is the highest priority one).

We can say queue 0 offers strict priority based on the FortiOS Handbook statement: “All traffic in a higher priority traffic queue must be completely transmitted before traffic in lower priority queues will be transmitted.”

 

The final challenge is about testing and validating queuing works as expected. We can find no diagnostic commands able to show egress queuing activity on the Firewall interfaces.  One possible test approach is to create congestion in the Firewall by making it forward flows with different priorities; high priority flows should always go through as long as the aggregated capacity is less than the interface speed.

 

Any feedback of comments will be appreciated.

 

 

3 REPLIES 3
slemke
New Contributor II

Hello,

 

thanks for this helpful post.

 

I have one more question; when setting "set traffic-priority-level low" does this also effect policies without any traffic shaper defined?

 

The default setting is a high priority to all policies without any traffic shaper defined ("If you do not apply any traffic shaping rule to a policy, the policy is set to high priority by default" - from the Traffic Shaping Handbook 5.2.0).

 

If I use the above global command is this true anymore or does this affect this behaviour?

 

The idea is to use DSCP for VoIP Systems without any traffic shaping rule (in the firewall policy) and to define some other services (without DSCP but) with traffic shaping rules set to medium.

 

Will it work this way?

 

Thanks,

Sebastian

 

packetpusher

Sebastian,

 

Did you get an answer?

 

Thanks

emnoc
Esteemed Contributor III

1:You can set a control-traffic-flow+policy when you flood the  firewall and monitor that flow for duration x and any plos or latency

 

2:For diagnostics montoring you can use the  firewall gui  for TS-monitor or  the  correct cli-cmd diag firewall shaper

 

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors