Rate Limiting QoS Rules

Rate limiting controls the overall traffic throughput sent or received on a network interface. A specific bandwidth limit can be set for a network or device; then, if the actual traffic violates that policy at any time, the traffic is shaped in some way. In this implementation, packets are dropped until the traffic flow conforms to the policy with some queuing (delaying packets in transit) applied.

Rate Limiting with the CLI

You can rate limit traffic by turning on Traffic Control and using the Token Bucket Rate as the token bucket limiter. Follow these steps to rate limit the client 10.11.31.115 to approximately 3Mbps and then run a quick test to verify functionality.

1. Determine the token bucket rate to achieve the desired rate limit. In the example below, we’ll limit it to 3Mbps (3Mbps = 3000000bps. 3000000/8/8=46875).
2. Create a qosrule that does rate limiting for a client.

Controller1# sh qosrule 23

QoS and Firewall Rules

ID : 23

Id Class flow class : on

Destination IP : 10.11.31.115 (this is the client to be rate limited)

Destination IP match : on

Destination IP flow class : on

Destination Netmask : 255.255.255.255

Destination Port : 0

Destination Port match : none

Destination Port flow class : none

Source IP : 0.0.0.0

Source IP match : none

Source IP flow class : none

Source Netmask : 0.0.0.0

Rate Limiting QoS Rules

Source Port : 0

Source Port match : none

Source Port flow class : none

Network Protocol : 6

Network Protocol match : on Network Protocol flow class : on

Firewall Filter ID :

Filter Id match : none

Filter Id Flow Class : none

Packet minimum length : 0

Packet Length match : none

Packet Length flow class : none

Packet maximum length : 0

QoS Protocol : other

Average Packet Rate : 0

Action : forward

Drop Policy : head

Token Bucket Rate : 46875

Priority : 0

Traffic Control : on

DiffServ Codepoint : disabled

Qos Rule Logging : on

Qos Rule Logging Frequency : 31

Rate Limiting QoS Rules with the GUI

You can rate limit traffic for a single user by turning on Traffic Control and using the Token Bucket Rate as the token bucket limiter. Follow these steps to rate limit the traffic:

1. Click Configure > QoS Settings > QoS and Firewall rules tab > Add. The QoS and Firewall rules Add window displays.
2. Scroll down to the lower half of the QoS and Firewall rules Add window.
3. Set Traffic Control On.
4. Set the token bucket rate to achieve the desired rate limit. This can be entered in either Kbps (from 0-1000) or Mbps (from 0-64), depending on the needs of your deployment.
5. Click OK.

The rate limit is now set.

Rate Limiting Examples

Rate-Limit Clients in the Same Subnet for TCP

To rate-limit clients from the subnet 10.11.31.0, follow these steps:

1. Determine the token bucket rate to achieve the desired rate limit. In the example below, we’ll limit it to 3Mbps (3Mbps = 3000000bps. 3000000/8/8=46875).

Rate Limiting QoS Rules

2. Create the following qosrule to rate-limit clients from a particular subnet:

Controller1# sh qosrule 23

QoS and Firewall Rules

ID: 23

ID Class flow class : on

Destination : 10.11.31.0 (this is the subnet to be rate limited)

Destination IP match : on

Destination IP flow class : on

Destination Netmask : 255.255.255.0

Destination  Port  : 0

Destination  Port  match : none

Destination  Port  flow class : none

Source IP : 0.0.0.0

Source Netmask : 0.0.0.0

Source  Port  : 0

Source  Port  match : none

Source  Port  flow class : none

Network Protocol : 6

Network Protocol match : on Network Protocol flow class : on

Firewall Filter ID :

Filter Id match : none

Filter Id Flow Class : none

Packet minimum length : 0

Packet Length match : none

Packet Length flow class : none

Packet maximum length : 0

QoS Protocol : other

Average Packet Rate : 0

Action : forward

Drop Policy : head

Token Bucket Rate : 46875

Priority : 0

Traffic Control : on

DiffServ Codepoint : disabled

Qos Rule Logging : on

Qos Rule Logging Frequency : 60

3. Configure Chariot to send a TCP downstream to the client 10.11.31.115 using the throughput script. You should see throughput averaging around3Mbps on Chariot.

As a result of this QoS rule, each client in the 10.11.31.xxx network will get approximately get 3 mbps from each individual source in the same subnet.

Rate-Limit Clients From Different Subnets for TCP

To rate-limit clients from any subnet other than the one that those clients are currently using, follow these steps:

Rate Limiting QoS Rules

1. Determine the token bucket rate to achieve the desired rate limit. In the example below, we’ll limit it to 3Mbps (3Mbps = 3000000bps. 3000000/8/8=46875).
2. Create the following qosrule to rate-limit clients from a particular subnet:

Controller1# sh qosrule 23

QoS and Firewall Rules

ID : 23

Id Class flow class : on

Destination IP : 10.11.31.0 (this is the subnet to be rate limited)

Destination IP match : on

Destination IP flow class : none

Destination Netmask : 255.255.255.0

Destination  Port  : 0

Destination  Port  match : none

Destination  Port  flow class : none

Source IP : 0.0.0.0

Source Netmask : 0.0.0.0

Source  Port  : 0

Source  Port  match : none

Source  Port  flow class : none

Network Protocol : 6

Network Protocol match : on Network Protocol flow class : on

Firewall Filter ID :

Filter Id match : none

Filter Id Flow Class : none

Packet minimum length : 0

Packet Length match : none

Packet Length flow class : none

Packet maximum length : 0

QoS Protocol : other

Average Packet Rate : 0

Action : forward

Drop Policy : head

Token Bucket Rate : 46875

Priority : 0

Traffic Control : on

DiffServ Codepoint : disabled

Qos Rule Logging : on

Qos Rule Logging Frequency : 60 

3. Configure Chariot to send a TCP downstream to the different clients in 10.11.31.xxx using the throughput script.

All the clients in 10.11.31.xxx network should now share the 3 Mbps from each individual source.

Rate Limiting QoS Rules

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Global QoS Settings

Global QoS parameters configure settings that determine call quality on a global level. These settings allow you to fine tune Call Admission Control (CAC), client load balancing, bandwidth scaling, and time-to-live settings.

You can configure the following global quality-of-service parameters:

TABLE 27: Global Quality-of-Service Parameters

Command	Purpose
qosvars admission { admitall | pending | reject }	Admission control. Valid values are admitall, pending, and reject.
qosvars ttl ttl-value	Default time-to-live in seconds for all other protocols besides TCP and UDP.
qosvars tcpttl ttl-value	Time-to-live for TCP protocol, in seconds.
qosvars udpttl ttl-value	Time-to-live for UDP protocol, in seconds.
qosvars bwscaling value	Scale factor for Tspec bandwidth, in percent. May range from 1% to as high as 100% ; 100% is typical
qosvars cac-deauth {on | off}	Configures the optional 802.11 de-authentication behavior.
qosvars calls-per-ap max	Configures the maximum number of calls per AP.
qosvars calls-per-bssid max	Configures the maximum number of calls per BSSID.
qosvars drop-policy {head|tail}	Configures the drop policy. Valid values are head or tail respectively.
qosvars load-balance overflow {on | off}	Enables and disables load balancing across BSSIDs.
qosvars max-stations-per-radio max	Configures the maximum stations (0-128) allowed to associate with a single radio. 128 is the default. Recommendation: •  14 voice clients per radio for all AP models •  40 data clients per radio for all AP models except AP122, and 20 data clients for AP122
qosvars max-stations-per-bssid max	Configures the maximum stations (0-1023) allowed to associate with an BSSID.

Global QoS Settings

TABLE 27: Global Quality-of-Service Parameters

Command	Purpose
qosvars no enable	Turns off QoS.
SIP Idle Timeout	Sets the time period after which an idle SIP connection will time out.
Station Assignment Aging Time (s)	Sets the time period after which stations will begin aging out.
Maximum Calls Per Interference Region	Specifies the number of calls that are permitted in a given interference area.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Optimizing Voice Over IP

Transmitting voice over IP (VoIP) connections is, in most senses, like any other network application. Packets are transmitted and received from one IP address to another. The voice data is encoded into binary data at one end and decoded at the other end. In some sense, voice is just another form of data. However, there are a few special problems.

The requirements for quality voice traffic are not exactly the same as the requirements for most data traffic:

• If a data packet arrives a second late, it is usually of no consequence. The data can be buffered until the late packet is received. If a voice packet arrives a second late, it is useless and might as well be thrown away.
• If a data packet takes a third of second to arrive at the destination, that is usually fast enough. If voice packets routinely take a third of a second to arrive, the users will begin to take long pauses between sentences to make sure that they don’t interfere with the other person’s speech.

Optimizing Voice Over IP

Quality VoIP calls need data to be delivered consistently and quickly. Meeting the requirements of VoIP data requires either a connection with plenty of bandwidth all along the data route or a means of ensuring a certain quality of service (QoS) for the duration of the call.

Even if the bandwidth is available, setting up the phone call can be a non-trivial task. When a phone call is initiated, the destination of the call might be a standard telephone on the public switched network (PSTN) or an IP-to- device at a particular IP number, or one of several computers (for example, a computer at home or office). If the destination device is a phone on the public network, the initiation protocol must locate a gateway between the Internet and the telephone network. If the destination device is in the local network, the initiation protocol must determine which computer or device to call.

After the destination device has been found, the initiating and the destination devices must negotiate the means of coding and decoding the data. This process of finding a destination device and establishing the means of communication is called session initiation.

The two main standards for initiating sessions are:

• Session Initiation Protocol, or SIP, used for most VoIP telephone calls.
• 323, used for multimedia communication, for example by Microsoft NetMeeting.

In both cases, the initiating device queries a server, which then finds the destination device and establishes the communications method.

After the two devices have been matched and the communication standards chosen, the call is established. The VoIP server may remain in the communication loop or it may step out of the loop depending on the server configuration.

Using QoS Rules for VoIP

The Wireless LAN System is designed to automatically provision voice traffic with a level of QoS appropriate for voice calls. Incoming traffic are matched against the pre-defined QoS rules and depending on the match, the traffic is assigned with appropriate prioritization.

The port numbers monitored for incoming traffic are:

• 5060 for SIP service (UDP or TCP)
• 1720 for H.323 service (TCP)
• 5200 for Vocera (UDP)

If your VoIP devices and servers are configured to use different ports, modify the QoS rules on the controller to match the ports your system uses. Change QoS rules with either the Web UI or the CLI.

Optimizing Voice Over IP

Modifying QoS Rules for Nonstandard Ports

The controller is pre-configured to detect the bandwidth requirements for a SIP or H.323 call and make a bandwidth reservation. Change QoS rules with either the Web UI or the CLI. The following default QoS rules are configured at the factory:

default(15)# show qosrule

ID    Dst IP          Dst Mask        DPort Src IP          Src Mask        SPort Prot Firewall Filter Qos   Action

• 0.0.0 0.0.0.0         1720  0.0.0.0         0.0.0.0         0     6                    h323  capture
• 0.0.0 0.0.0.0         0     0.0.0.0         0.0.0.0         1720  6                    h323  capture
• 0.0.0 0.0.0.0         5060  0.0.0.0         0.0.0.0         0    

17                   sip   capture

• 0.0.0 0.0.0.0         5060  0.0.0.0         0.0.0.0         0    
• sip capture
• 0.0.0 0.0.0.0         5200  0.0.0.0         0.0.0.0         0     17                   other forward
• 0.0.0 0.0.0.0         0     0.0.0.0         0.0.0.0         5200  17                   other forward
• 0.0.0 0.0.0.0         80    0.0.0.0         0.0.0.0         0     17                   other capture
• 0.0.0 0.0.0.0         0     0.0.0.0         0.0.0.0         5060  6                    other capture

        QoS and Firewall Rules(8 entries)

The first two pre-configured QoS rules give priority to H.323 traffic sent to and from TCP port 1720 respectively. The next two QoS rules give priority to SIP traffic sent to and from UDP/ TCP port 5060 respectively. Rules 7 and 8 are for Vocera badges and use port 5200 with UDP.

You normally do not need to configure QoS rules in the controller, unless you have special requirements in your configuration. For example:

• You want to drop packets coming from certain ports or IP addresses.
• You want to configure the controller to give priority to traffic other than H.323 and SIP traffic.

You can configure rules to provide priority-based or reserved QoS. QoS is applied with reserved traffic being allocated the first portion of total bandwidth, followed by fixed priority levels, and finally by the best-effort (default) traffic class. You can configure reserved QoS for new applications using the average packet rate and token bucket rate parameters together as the traffic specification (also called TSpec in IETF IntServ RFCs).

Optimizing Voice Over IP

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Configuring QoS Rules With the CLI

To configure QoS rules with the CLI, you need to be in QoS Rule configuration mode. Enter configure terminal, then specify a QoS rule with the command qosrule <rule-id>. See the chart below for the options for these two commands.

Command	Purpose
configure terminal	Enter global configuration mode.
qosrule rule-id netprotocol {6|17|protocolnumber} qosprotocol {H323|sip|none|other|sccp}	Enter QoS Rule configuration for the specified rule ID. Use show qosrules to obtain a list of rule IDs. The required parameters are: netprotocol: The network protocol is a standard network protocol number such as 6 for TCP or 17 for UDP. It can be any valid protocol number such as 119 for the SVP protocol, used with Spectralink phones. [Full listing at: http://www.iana.org/ assignments/ protocol-numbers] qosprotocol: The QoS protocol. This can be one of the following: H.323 sip (SIP – Session Initiation Protocol) none (Used to denote all other protocols)
… commands …	Enter the QoS rule configuration commands here (see the following table).
end	Return to privileged EXEC mode.
copy running-config startup-config	This is an optional step to save your entries in the configuration file.

Commands for QoS Rule CLI Configuration

Once you are in QoS rule configuration mode (see directions above), you can issue any of these QoS rule configuration commands:

Configuring QoS Rules With the CLI

Command	Purpose
dstip ip	Destination IP in the format 255.255.255.255.
dstmask ipmask	Destination netmask in the format 255.255.255.255
dstport port	Destination port number from 0 to 65535.
srcip ip	Source IP in the format 255.255.255.255.
srcmask ipmask	Source netmask in the format 255.255.255.255.
srcport port	Source port number from 0 to 65535.
action {forward | capture | drop}	Action to take for packets matching the rule. This can be one of the following: forward—A flow is given an explicit resource request, bypassing the QoS protocol detector and regardless of whether a QoS protocol was specified. capture—The flow is passed through the QoS protocol detector, using the specified QoS protocol. This is the recommended action for static QoS rules that are H.323/SIP based. drop—The flow is dropped.
dscp class	The DiffServ codepoint class. This lets you choose a per-hop forwarding behavior for the packets in the flow. It is recommended that you be familiar with RFCs 2475 and 2597 before changing these values.
priority rate	The number (0-8) that specifies best effort priority queue, where 0 is default (best-effort) and 8 is highest priority. Priority may be turned on (non-zero) or the average packet rate and TSpec token bucket rate may be specified, but not both. Defaults to 0.
avgpacketrate rate	Average packet rate: from 0 to 200 packets per second. If this is a nonzero value, then the TSpec token bucket rate must also be a non-zero value, and priority cannot be set to a non-zero value. Defaults to 0.
tokenbucketrate rate	TSpec token bucket rate, from 0 to 1000 Kbps or 1-64 Mbps, depending on the box checked. If this is a non-zero value, then the average packet rate must also be non-zero, and the priority cannot be set to a non-zero value. Defaults to 0.
trafficcontrol-enable	Turns traffic control policing on. When traffic control is on, traffic assigned a priority will travel at the assigned rate and no faster.
no trafficcontrol	Turns traffic control policing off. This is the default setting.

Configuring QoS Rules With the CLI

QoS Rule CLI Configuration Example

The following commands configure QoS rule 10 for the set of IP phones whose server is at the IP address 10.8.1.1:

controller (config)# qosrule 10 netprotocol 17 qosprotocol none controller (config‐qosrule)# srcip 10.8.1.1 controller (config‐qosrule)# srcmask 255.255.255.0 controller (config‐qosrule)# srcport 0 controller (config‐qosrule)# dstip 10.8.1.1 controller (config‐qosrule)# dstmask 255.255.255.0 controller (config‐qosrule)# dstport 0 controller (config‐qosrule)# action forward controller (config‐qosrule)# tokenbucketrate 9400 controller (config‐qosrule)# avgpacketrate 35 controller (config‐qosrule)# end

When SCCP phones are used, we recommend that you create a separate VLAN for the SCCP phones and create the following qosrules for G.711 (20ms) codec to handle qosflow traffic:

controller (config)# qosrule 123 netprotocol 17 qosprotocol none controller (config‐qosrule)# srcmask subnet_mask (for example, 255.255.192.0) controller (config‐qosrule)# srcip subnet_IP_addr (for example,172.27.128.0) controller (config‐qosrule)# action forward controller (config‐qosrule)# avgpacketrate 50 controller (config‐qosrule)# tokenbucketrate 10000  controller (config‐qosrule)# exit

controller (config)# qosrule 124 netprotocol 17 qosprotocol none

controller (config‐qosrule)# dstip subnet_IP_addr  (for example,172.27.128.0) controller (config‐qosrule)# dstmask subnet_mask (for example, 255.255.192.0) controller (config‐qosrule)# action forward controller (config‐qosrule)# avgpacketrate 50 controller (config‐qosrule)# tokenbucketrate 10000 controller (config‐qosrule)# exit

The following example configures a QoS rule for a 1 Mbps CBR-encoded video streamed from Windows Media Server 9 over UDP transport.

The following lists the example’s configuration parameters:

• Rule ID: 11
• Network protocol: 17 (UDP)
• QoS protocol: None
• Source IP address: 0.0.0.0
• Source subnet mask: 0.0.0.0
• Source port: 0

Configuring QoS Rules With the CLI

• Destination IP address:10.10.43.100 (This is the IP address of the wireless station receiving the video stream.)
• Destination subnet mask: 255.255.255.255
• Destination port: 5004
• Action to take if packets match rule: Forward
• Drop policy: Head
• Token bucket rate: 128 kbytes/second
• Average packet rate: 10 packets/second

The following commands configure the QoS rule for the video streamed from Windows Media Server 9 over UDP transport:

controller (config)# qosrule 11 netprotocol 17 qosprotocol none controller (config‐qosrule)# srcip 0.0.0.0 controller (config‐qosrule)# srcmask 0.0.0.0 controller (config‐qosrule)# srcport 0 controller (config‐qosrule)# dstip 10.10.43.100 controller (config‐qosrule)# dstmask 255.255.255.255 controller (config‐qosrule)# dstport 0 controller (config‐qosrule)# action forward controller (config‐qosrule)# tokenbucketrate 128000 controller (config‐qosrule)# avgpacketrate 10 controller (config‐qosrule)# end

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Configuring Quality of Service

Quality of Service rules evaluate and prioritize network traffic types. For example, you can prioritize phone calls (VoIP) or prioritize traffic from a certain department (group, VLANs) in a company. This chapter describes QoS settings for Wireless LAN System.

Configuring QoS Rules With the Web UI

To configure QoS rules from the GUI, follow these steps:

1. Click Configuration > QoS Settings > QoS and Firewall Rules (tab).
2. Click Add. The screen below appears.

Figure 69: Add a QoS Rule — change..

3. In the ID field, type a unique numeric identifier for the QoS rule. The valid range is from 0 to 6000.
4. In the Destination IP fields, type the destination IP address to be used as criteria for matching the QoS rule. The destination IP address is used with the destination subnet mask to determine matching.
5. In the Destination Netmask fields, type the subnet mask for the destination IP address.
6. In the Destination Port field, type the TCP or UDP port to be used as criteria for matching the QoS rule. To specify any port, type 0 (zero).
7. In the Source IP fields, type the source IP address to be used as the criteria for matching the QoS rule. The source IP address is used with the source subnet mask to determine matching.
8. In the Source Netmask fields, type the subnet mask for the source IP address.
9. In the Source Port field, type the TCP or UDP port to be used as criteria for matching the QoS rule. To specify any port, type 0 (zero).

10.In the Network Protocol field, type the protocol number of the flow protocol for the QoS rule. The protocol number can be a number 0 through 255. The protocol number of TCP is 6, and the protocol number for UDP is 17. For a list of protocol numbers, see http:// www.iana.org/assignments/protocol-numbers.

If you are also using a QoS protocol detector, you must match the network protocol with the type of QoS protocol. Use the following network protocol and QoS protocol matches:

• UDP: SIP
• TCP: H.323 or SIP

 

11.In the Firewall Filter ID field, enter the filter-ID to be used (per-user or per-ESS), if Policy Enforcement Module configuration is enabled (optional feature). This ID must be between 1 and 16 alphanumeric characters.

12.In the Packet minimum length field, specify the size of the minimum packet length needed to match the rule. (Valid range: 0-1500.)

13.In the Packet maximum length field, specify the size of the maximum packet length needed to match the rule. (Valid range: 0-1500.)

14.In the QoS Protocol dropdown list, select one of the following:

• SIP
• 323
• Other
• None

For capture rules, the QoS protocol determines which QoS protocol detector automatically derives the resources needed for the flow (implicitly). Select Other if you want to specify the resource requirements for matched flows explicitly. The QoS protocol value is ignored for non-capture rules.

15.In the Average Packet rate box, type the average flow packet rate. The rate can be from 0 through 200 packets/second.

16.In the Action list, select the action the rule specifies: • Forward: A flow is given an explicit resource request, bypassing the QoS protocol detector and regardless of whether a QoS protocol was specified.

• Capture: The system, using a QoS protocol detector, analyzes the flow for its resource requirements.
• Drop: The flow is dropped.

17.In the Token Bucket Rate box, type the rate (in Kbps or Mbps, depending on the option checked) at which tokens are placed into an imaginary token bucket. Each flow has its own bucket, to which tokens are added at a fixed rate. To send a packet, the system must remove the number of tokens equal to the size of the packet from the bucket. If there are not enough tokens, the system waits until enough tokens are in the bucket.

18.In the Priority box, type the priority at which the flow is placed in a best-effort queue. Packets in a higher priority best-effort queue are transmitted by access points before packets in lower-priority queues, but after packets for reserved flows.

Priority can be a value from 0 through 8, with 0 specifying no priority and 8 specifying the highest priority. The default value is 0. If you enable priority (specify a non-zero value), you cannot specify an average packet rate or token bucket rate.

19.In the Traffic Control list, select one of the following:

• On
• Off

For all types of flows (explicit, detected, and best-effort), selecting On for traffic control restricts the flow to the rate you specified. Packets above that rate are dropped.

20.In the DiffServ Codepoint list, select the appropriate DiffServ setting, if applicable.

21.In the QoS Rule Logging list, select whether to enable or disable logging activity for this QoS rule:

• On Off

22.In the QoS Rule Logging Frequency field, change the default collection interval in which packets related to this rule are logged, if QoS Logging is enabled. The interval must be a number between 30 and 60 (seconds).

23.Match Checkbox: For any field with the corresponding Match checkbox selected, the action mentioned in the ACTION field is performed on the matched packets. If the match checkbox is not checked, packets with any value are matched regardless of the data in the field and the action mentioned in the ACTION field is not performed on the packets. Also see “More About the Match Checkbox and Flow Class Checkbox” on page 383.

24.Flow Class Checkbox: Flow Class options are relevant only for Flow Control rules (rules with Traffic Control enabled and Token Bucket Rate specified) and Firewall rules. This is typically rate limiting. When Flow Class is checked for a field, if a packet has matched a rule (either Flow Control or Firewall types), these fields are stored in the Flow Class entry. A Flow Class entry is used by the system for aggregating a set of flows so that they can be subjected to similar behavior, be it dropping the packets, or rate limiting them.

For example, if a rule has a Src IP address of 0.0.0.0 and the Flow Class box checked, and Token Bucket Rate set to 10 kbytes/sec, all packets passing through the system must match this rule, and each flow will be allowed a maximum throughput of 10000 bytes/sec. If the rule were to have Src IP address of 10.0.0.10 and the Flow Class box checked, with a Token Bucket Rate of 10 kbytes/sec, all packets coming from a machine with IP address 10.0.0.10, must match this rule, and the cumulative throughput allowed for this machine shall be no more than 10000bytes/sec. Also see “More About the Match Checkbox and Flow Class Checkbox” on page 383.

25.To add the QoS rule, click OK.

QoS Rules for Bridge Mode Traffic

QoS rules support bridge mode traffic (IPv4). For bridge mode traffic the following conditions are matched to either Forward or Drop packets.

• Destination IP
• Destination Port
• Source IP
• Source Port
• Network Protocol: A QoS rule for bridge mode traffic must mandatorily include the network protocol if the destination or source port is specified.

The following are some points to consider while creating QoS rules for bridge mode traffic: • You can specify ports only for the protocols that support specifying ports. Protocols that do not have port specifications (example, ICMP etc.,) will be ignored by the AP.

• QoS rules with firewall filter-ID are ignored.
• Any rule with match value set to ‘0’ will be considered as a wildcard and will match ANY traffic.
• The QoS rules for bridge mode traffic do not support any other conditions including the Capture action. If application visibility is enabled, and if either QoS rule OR the app-visibility policy dictates a DROP action for a packet, the packet is going to be dropped. Packet is forwarded only if BOTH QoS and app-visibility allow it.

NOTES:

• Any rules that block traffic between controller and AP will cause AP – controller dis-connectivity and such rules should not be created.
• If the number of QoS rules exceed 50, it may affect overall system performance.

More About the Match Checkbox and Flow Class Checkbox

The two checkboxes Match and Flow Class operate independently from each other; they perform two different functions. Match will almost always be used because checking this box indicates that the setting on the left must match – this sets the matching criteria for the QoS rule. You can check more than one matching criteria. Matching is the first phase of QoS rule execution – see the green box in Figure 70.

After criteria are matched, the action phase of the QoS rule is executed. This phase is enclosed in the orange box in Figure 70. Here are the directions that describe what to do with the matched packet from phase 1, Matching. For example, the rule can capture the packet from a named source and drop it. Action is phase 2 of QoS rule execution.

The Flow Class column is all about rate limiting. If a rule involves rate limiting, the actions Traffic Control and Token Bucket Rate must have been turned on. When the QoS rule executes traffic control, it looks at the check marks in the flow class column. If there are no check marks at all, the rate limiting is applied to everything. If Destination, Source, or Network Protocol have Flow Class checked, the following happens:

• Destination Flow Class – Each destination flow is limited to the rate.
• Source Flow Class – All source flows combined must be less than or equal to the rate.
• Network Protocol Flow Class – Any data transported using this protocol is limited to the rate.

Figure 70: How QoS Rules Work — change

 

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Automatic AP Upgrade

The automatic AP upgrade features is enabled by default. It allows an AP’s firmware to be automatically upgraded by the controller when the AP joins the WLAN. An AP cannot provide service (and consequently be part of the WLAN) if its firmware is at a different level than that of the controller.

When an AP initiates its discovery phase, the controller checks the firmware version and initiates an upgrade if the version is not at the same level as that of the controller. This feature simplifies the process of adding and maintaining a group of APs on an existing WLAN.

When the automatic AP upgrade feature is enabled, you can check the upgrade status of affected APs through syslog messages and SNMP traps that warn of an AP/controller software version mismatch. An alarm is dispatched to an SNMP manager if a mismatch exists. After the firmware is downloaded to the AP, the AP boots, attempts discovery, is checked, and after upgrading, runs the new software version. Once the match is confirmed, another set of syslog messages and SNMP traps are sent notifying that the AP/controller software versions match. Alarms are then cleared.

To disable this feature:

default# auto‐ap‐upgrade disable default# show controller

Global Controller Parameters

Configure Gain for External Antennas

Controller ID                                         : 1

Description                                           : 3dot4dot1 Controller

Host Name                                             : DC9

Uptime                                                : 03d:01h:17m:33s

Location                                              : Qa scale testbed near IT room

Contact                                               : Raju

Operational State                                     : Enabled

Availability Status                                   : Online

Alarm State                                           : No Alarm

Automatic AP Upgrade                                  : off

Virtual IP Address                                    : 192.168.9.3

Virtual Netmask                                       : 255.255.255.0

Default Gateway                                       : 192.168.9.1

DHCP Server                                           : 10.0.0.10

Statistics Polling Period (seconds)/0 disable Polling : 60

Audit Polling Period (seconds)/0 disable Polling      : 60

Software Version                                      : 3.7‐49

Network Device Id                                     : 00:90:0b:07:9f:6a

System Id                                             : 245AA7436A21

Default AP Init Script                                :

DHCP Relay Passthrough                                : on

Controller Model                                      : mc3200

Country Setting                                       : United States Of America

Manufacturing Serial #                                : N/A

Management by wireless stations                       : on

Controller Index                                      : 0

Topology Information Update                           : off Viewing AP Status

From the Web UI, view AP radio status by clicking Monitor > Dashboard > Radio or Monitor > Diagnostics > Radio. Click Help for descriptions of the charts. The icons at the bottom of all screens include a green AP (enabled) and a red AP (disabled); you can also see the same information at Monitor > Dashboard > System.

There are several CLI commands you can use to view AP status:

Automatic AP Upgrade

TABLE 26: Commands to View System Status

Command	Purpose
show ap [index]	Displays the status of the AP, such as serial number, uptime, operational status, availability, alarm state, security mode, privacy bit, boot script, AP model, and FPGA version. If the AP index is not specified, a summary of the AP status is displayed.
show antenna-property	Displays the antenna properties.
show ap-connectivity	Displays the access point connections.
show ap-discovered	Displays the list of discovered access points and stations.
show ap-limit	Displays how many APs are licensed for this controller.
show ap-siblings	Displays the AP Siblings table. APs operating in the same channel that can hear each other are AP-siblings. APs can hear beacons with RSSI as low as -80 to -85dbm, but RSSI values lower than this are not heard.
show ap-swap	Displays the access point replacement table.
show ess-ap	Displays the ESS-AP table for the access point.
show interfaces Dot11radio	Displays the configuration of the wireless interface.
show interfaces Dot11Radio statistics	Displays the statistics related to the wireless interface.
show regulatory-domain	Displays the regulatory information for the country.
show statistics top10-ap-problem	Displays a list of the top 10 problem access points.
show statistics top10-ap-talker	Displays a list of the top 10 most active access points.
show topoap	Displays the topology of all access points as seen by the coordinator.
show topoapap	Displays the Received Signal Strength Indicator (RSSI) between all pairs of APs.

Automatic AP Upgrade

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Configure Gain for External Antennas

The total power that an AP produces must not exceed 30dbi; this number includes any antenna gain. Therefore, if an antenna produces 2dbi, the radio can produce 28dbi. FortiWLC

(SD) automatically sets antenna gain; in the case of an AP400, it assumes an antenna with 5dbi and therefore sets the AP400 to 25dbi. This may or may not be correct for your antenna.

To check and change antenna gain, follow these steps from FortiWLC (SD):

1. Click Configuration > APs (under Devices).
2. Select an AP ID.
3. Click the Antenna Property tab.
4. Select an Interface (1/2).
5. Change the gain if needed.
6. Click OK.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

When APs are in a Virtualization

All APs on the same channel in a Virtualization must have the same setting for these values:

• RF-Mode
• Channel Width
• N-only Mode
• Channel and MIMO mode

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!