Fortinet FortiSwitch – QOS Primer

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! 🙂

 

Posted in Fortinet | Leave a comment

Time For an Update!

I’m realizing that this blog has been neglected for far too long!

As part of updating the blog for the latest software patches, adding an SSL cert so that Google will continue to index us, and general maintenance being done, I realized I had a whole batch of drafts that were started over 18 months ago that never saw the light of day.

Oh how things have changed!

I intent to get content coming back to this blog regularly. This site, https://charlieclemmer.com/, will remain as my primary technical repository. Most things here will be wireless related, or derivatives that wireless professionals would be interested in, but may stray on occasion to other networking topics like virtualization or client devices as interesting topics come up.

I also considered combining my old motorcycle blog (which is https://rocketcowboy.net/ by the way) into this blog to cut down on the number of sites I’m maintaining, but that’s too far off topic to keep everyone’s attention. Anyway, with motorcycles fading into the past and photography being in the forefront, that site will evolve on it’s own and not detract from here.

My third site focuses on my event photography, so if you landed here as a result of Google, you probably want to check out https://charlieclemmerphotography.com instead to find your images.

With all that said, what’s been going on here? Since May of 2016, I left Aruba Networks to help an emerging ecosystem provider get established in the North American marketplace. Most of those draft posts that I mentioned above, were related to this change. Skyfii was a great learning opportunity for me and great for getting connected with the larger wifi market, but ultimately the travel and pace required to continue working dual time-zones (All US timezones as well as Australia) was more than I could say grace over. In July of 2017, I took a position with Fortinet, where I am focused on the company’s access technologies (switching and wireless) as well as products like network authentication and analytics.

As with my time at Aruba, this site is not an official outlet for news or information related to Fortinet. I will be using this to document my way through the various technologies that I encounter, however, so if there are particular topics that you’d like to see included here, drop me a comment and I’ll look at how that can be incorporated into my timeline.

If you’re still reading, thanks for sticking with me. I promise there will be more technical articles to come!

Posted in Uncategorized | Leave a comment

Mobility Field Day at Aruba Networks – Skyfii Integration with ArubaOS

On September 13, 2016, I presented on behalf of Skyfii how our analytics solution integrated with Aruba’s wireless APIs to leverage data collected from the wireless infrastructure to unlock operational insights for an organization.

Posted in Skyfii | Leave a comment

WLPC IPv6 Presentation

Long before I got involved with wireless, I had an opportunity to get hands on exposure with IPv6 while working at Nortel Networks. In 2015, the Wireless LAN Professionals Conference returned, and I got to do a presentation on IPv6 and how it impacts 802.11 wireless.

In some ways, a lot has changed regarding IPv6, but then alot has stayed the same. I’m still interested in tracking IPv6 deployments within wifi installations, so if you know of an interested deployment please let me know!

Posted in IPv6, Wireless | Leave a comment

WLPC Warehouse Design Presentation

In 2014, I had the honor of presenting at the inaugural Wireless LAN Professionals conference in Austin, TX.

The session I presented was on Designing WLANs for Hostile Environments, particular warehouse design considerations. While based on Aruba’s Retail Wireless VRD that was available at the time, the discussion was updated to take into account newer technologies such as 802.11n.

The link to the presentation is below:

Have any questions or follow-up? Don’t hesitate to comment below or reach me directly on Twitter or via email.

Posted in Wireless | Leave a comment

ClearPass and Airwave Updates

In the past two weeks, Aruba has rolled out big upgrades to both the ClearPass and Airwave product lines.

Last week, Airwave was updated to 8.2.0 from 8.0.x. Upgrade images and release notes can be found in their usual locations on the support site (support.arubanetworks.com), the biggest changes are the introduction of Clarity along with the updated user interface. Clarity Monitoring is considered a beta feature in Airwave 8.2.0 (and does require controllers running 6.4.3 or later), but does monitor and report on client association times, complete authentication times, as well as DHCP and DNS response times for clients.

The other big upgrade was ClearPass being updated from 6.5 to 6.6. Many new enhancements with this release as well, most visible is the new user interface for ClearPass Insight. Along with the changes to Insight, the Cluster Upgrade Tool is now natively available within the ClearPass appliance rather than requiring a separate install.

Posted in Aruba, Wireless | Leave a comment

Latest ArubaOS Releases

Last week, Aruba release 6.4.3.2 of ArubaOS for theMobility Controller products.

This week, Aruba also released 7.3.2.6 of ArubaOS for the Mobility Access Switch products.

Software and documentation for both releases can be found at http://support.arubanetworks.com.

Posted in Aruba, Wireless | Leave a comment