Quality of Service – QOS

Overview

I originally planned to have my first few Fortinet posts be wireless specific, but since getting questioned about migrating QoS configurations from various 3rd party manufacturers into FortiOS syntax … this is a good place to start documenting this stuff for myself.

As background, Fortinet’s FortiSwitch has two primary modes that it can operate under: standalone, or integrated into the switch-controller built into Fortinet’s Fortigate firewall products. The hierarchy used to configure QoS is basically the same across both platforms, with the primary difference being that profiles can be shared across multiple switches when operating in Integrated mode, vs each switch needing to have profiles created locally when running in standalone mode. But before I get into those details, how ’bout the basics on what QoS profiles are available?

When working with QoS, there are a couple of criteria that will be important, that the switch will then use to make decisions on. This criteria will fall into one of two buckets based on the direction of traffic flow: ingress or egress.

On ingress into the switch, the switch will inspect the traffic to make a determination on how it should prioritize the traffic. For most switches including FortiSwitch, the switch can either look at information included in the layer 2 phy, also referred to as the 802.1p priority code point. This 3-bit field is a part of the overall 802.1Q tag that can be added, that also includes VLAN information for tagged trunk links. Similarly, FortiSwitch can look at the IP header in order to determine the Differentiated Services Code Point, or DiffServ Code Point (DSCP). Some devices may mark one or the other, or both, depending on whether they operate at layer 2 only, layer 3, or a mix of both.

Probably not surprisingly, FortiSwitch provides two profiles to be used on ingress: the dot1p-map and the ip-dscp-map, for mapping 802.1p and DSCP priority bits into the appropriate queues, respectively. By configuring profiles, different profiles can be applied to different ports, so if we find a device out on the network that is incorrectly mixing 802.1p and DSCP, profiles can be created to handle that mix correctly for the ports those devices plug into.

Implementing queueing consistently across an enterprise can be interesting, as different devices or manufacturers may support different numbers of queues. For Fortinet, 8 queues are supported. For some of the integrations with typical Cisco implementations I’ve seen, only four queues are used.

802.1p Queue Mapping

A typical 802.1p mapping policy might look as follows:

config switch qos dot1p-map
edit “custom-dot1p”
set priority-0 queue-4
set priority-1 queue-4
set priority-2 queue-3
set priority-3 queue-2
set priority-4 queue-3
set priority-5 queue-1
set priority-6 queue-2
set priority-7 queue-2
next
end

With the 802.1p priority levels, this map is effectively mapping out the following:
– PCP/Priority values 0 and 1, Background (BK) and Best Effort (BE) map to queue 4
– PCP/Priority values 2 and 4, Excellent Effort (EE) and Video (VI) map to queue 3
– PCP/Priority values 3, 6, and 7, Critical Applications (CA), Internetwork Control (IC), and Network Control (NC) map to queue 2
– PCP/Priority value 5, Voice (VO) maps to queue 1

We’ll talk more about these queues in a moment.

DiffServ Queue Mapping

As I mentioned above, devices like IP phones might mark QoS settings using 802.1p as above, or may choose to mark via DSCP instead (or in addition to). A typical DSCP mapping policy might look as follows:

config switch qos ip-dscp-map
edit “custom-dscp”
config map
edit “1”
set cos-queue 1
set value 46
next
edit “2”
set cos-queue 2
set value 24,26,48,56
next
edit “5”
set cos-queue 3
set value 34
next
end
next
end

With typical DSCP values, this map is mapping out the following:
– DSCP value 46, Expedited Forwarding (EF) map to queue 1
– DSCP values 24, 26, 48, and 56, CS3 Signalling, Assured Forwarding 31 (AF31), CS6 Network Control, and CS7 map to queue 2
– DSCP value 34,  Assured Forwarding 41 (AF41) map to queue 3

Queue Policy

There’s a trend starting to form. High priority traffic, either marked with DSCP EF or an 802.1p VO priority, goes to queue 1. While the DSCP marking of Expedited Forwarding isn’t as obvious as marking voice traffic as VO (in 802.1p), the switch is grabbing low latency traffic and putting it into queue 1. Queue 2 then is grabbing network control traffic; things like routing protocols, and signalling protocols. Queue 3 is next up, primarily handling video traffic; whether that be marked with PCP VI (for Video) or DSCP 34 for AF41. Finally, queue 4 is picking up background and best effort traffic. Anything not captured here, stays in queue 0.

If 802.1p and DSCP are used at ingress for determining what queue to sort traffic into, the queueing policy itself is used on egress of the switch to determine how packets are ordered when leaving the switch. If no configuration is done on uplink/outbound ports, the default policy is applied. That policy looks like this:

config switch qos qos-policy
edit “default”
config cos-queue
edit “queue-0”
next
edit “queue-1”
next
edit “queue-2”
next
edit “queue-3”
next
edit “queue-4”
next
edit “queue-5”
next
edit “queue-6”
next
edit “queue-7”
next
end
set schedule round-robin
next
end

Basically, there is no difference in how the queues get treated. Each queue gets serviced in a round-robin order.

In order to provide priority to the different traffic classes, a queuing profile like the following would be more preferred:

config switch qos qos-policy
edit “voice_policy”
config cos-queue
edit “queue-0”
next
edit “queue-1”
set weight 0
next
edit “queue-2”
set weight 6
next
edit “queue-3”
set weight 37
next
edit “queue-4”
set weight 12
next
edit “queue-5”
next
edit “queue-6”
next
edit “queue-7”
next
end
set schedule weighted
next
end

Applying QOS Policy to Ports

Once the queue policy has been configured, the last step is to apply this policy to the egress ports. With QoS, the point is to affect how queues are serviced when traffic starts to queue on the ports. If ports are operating under capacity, there shouldn’t be traffic queueing, so the queueing policy we created will typically be applied to uplink interfaces were traffic is aggregated. Conversely, the switch needs to decide where to queue traffic when it ingresses the switch, so the mapping profiles for 802.1p and DSCP are applied to the edge ports where the priority traffic is generated.

For setting the queueing policy for trunk ports, the following example would apply:

config ports
edit “port20”
set qos-policy “voice_policy”
next
end

To add the queue mapping profiles to edge ports, the following example would apply:

config ports
edit “port1”
set trust-dot1p-map “dot1p-map”
set trust-ip-dscp-map “ip-dscp-map”
next
edit “port2”
set trust-dot1p-map “dot1p-map”
set trust-ip-dscp-map “ip-dscp-map”
next
end

If different mapping profiles were created, either because devices weren’t using both 802.1p and DSCP … or if they were using them differently, then those different profiles could be added per port as needed.

Conclusion

Finally, the last remaining point to make relates to whether the switch is operating in standalone mode or integrated into the Fortigate’s switch controller.

With standalone switches, the config context is not shared across switches, so profiles and port configuration is done per switch. The examples above can be cookie cutter applied to switches, and then applied to ports as part of the standard config rollout.

With integrated switches, all of the configuration is applied at the Fortigate itself. This provides easy reuse and standardization of the mapping and queue profiles across multiple switches for consistent operation. The difference then is in applying the profiles to individual switch ports.

With switches in integrated, or Fortilink mode, the “config switch-controller managed-switch” context is used in order to identify switch specific configurations. Because the profiles are leveraged across all the switches, this context is not needed for creating policies … regardless of the operating mode. The context only comes into play when applying specific settings to ports.

Switches are listed on the Fortigate by their switch ID. Effectively, the switch ID is an abbreviation of the switch model number, followed by the serial number. To apply the port specific settings on the Fortigate then, the following example shows the logic:

config switch-controller managed-switch
edit S224DF3X12345678
config ports
edit “port1”
next
end
next
edit “FS108D3W12345678”
config ports
edit “port1”
next
end
next

Similarly, when applying the configuration to multiple switches, whether standalone or integration, it’s best to ensure that all switches are capable of performing QOS functionality. As of this writing, the D series switches are the prevalent models, while the E series switches are just starting to release. With that, QOS functionality is supported across the FS-2xxD, FS-4xxD, and FS-5XXD switches, as well as on the new FS-2xxE series access switches. It should be noted that the recently EOO’ed FS-1xxD and the newly available FS-1xxE do not support QOS based priority queuing.

Comments?

While I wrote this article more to memorialize what I learned about configuring QOS on FortiSwitch equipment, I welcome any feedback in the form of questions or comments. I plan to review similar configurations for other enterprise switching gear that I have in my lab, but first … I need to get back to more wireless! 🙂