QoS forwarding based on DSCP

[ewaizel]

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    nextend

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:low08:low    09:low    10:low    11:low    12:low    13:low    14:low    15:low16:low    17:low    18:low    19:low    20:low    21:low    22:low    23:low24:low    25:low    26:low    27:low    28:low    29:low    30:low    31:low32:low    33:low    34:medium 35:low    36:low    37:low    38:low    39:low40:high   41:low    42:low    43:low    44:low    45:low    46:high   47:low48:low    49:low    50:low    51:low    52:low    53:low    54:low    55:low56: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.

[slemke]

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]

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