FortiGate Bandwidth Management: Inside the Architecture of Traffic Control
.
FortiGate bandwidth management: traffic shaping, per-IP limits, interface controls, and QoS configuration for enterprise network performance.
The Mechanics of Network Discipline
Bandwidth management on FortiGate platforms operates through a layered architecture that extends beyond simple rate limiting. Traffic shaping functions as both a policing mechanism—enforcing hard bandwidth ceilings—and a priority queuing system that redistributes available capacity during congestion events. This dual approach allows administrators to guarantee minimum throughput for critical services while preventing any single flow from monopolizing shared resources.
The distinction matters: policing drops packets exceeding defined thresholds, whereas queuing reorders transmission sequences to favor designated traffic classes. FortiOS implements both strategies within a unified framework, enabling granular control without requiring separate policy constructs.
Interface-Level Enforcement
Administrators can impose bandwidth constraints directly at the interface layer, intercepting excess traffic before it consumes processing resources deeper in the inspection pipeline. This preemptive filtering proves particularly valuable on high-throughput links where late-stage packet rejection would waste CPU cycles.
Configuration proceeds through either the graphical interface—navigating to Network > Interfaces and enabling Inbound/Outbound Bandwidth fields—or via CLI commands set inbandwidth and set outbandwidth within the interface configuration block. Values default to kilobits per second, though the unit of measurement remains adjustable to accommodate diverse network scales.
Shaping Strategies: Shared Versus Per-IP Allocation
The Shared Shaper Model
Shared traffic shapers allocate a collective bandwidth pool among matching flows. When applied to an FTP service, for instance, all users uploading to that server collectively consume the designated maximum—say, 10 Mbps—regardless of individual activity levels. This approach suits scenarios where aggregate service consumption requires containment rather than per-user fairness.
Critical nuance: shared shapers primarily affect upload direction traffic. Limiting download speeds from a remote server necessitates configuring the shaper as a reverse shaper, altering the inspection perspective to evaluate inbound flows against the policy.
Per-IP Precision
Per-IP traffic shapers distribute bandwidth guarantees individually. Assigning a 1 Mbps per-IP limit ensures each source address receives that allocation independently; ten concurrent users would collectively utilize up to 10 Mbps. This model prevents bandwidth starvation when aggressive applications compete for finite capacity.
Configuration requires three sequential actions: establishing a firewall policy defining the traffic scope, creating the per-IP shaper object with maximum bandwidth and optional concurrent session limits, then binding both through a shaping policy. The CLI workflow mirrors this logic through distinct configuration blocks for firewall policy, firewall shaper per-ip-shaper, and firewall shaping-policy.
Verification and Operational Intelligence
Diagnostic Command Sequences
Effective bandwidth management demands continuous validation. The command diagnose firewall iprope list reveals which shaper attaches to specific policy indices, confirming policy-to-shaper mappings. Session-level verification employs diagnose sys session list, where the per_ip_shaper field indicates active shaping assignments for individual connections.
Shaper operational status appears via diagnose firewall shaper per-ip-shaper list, displaying real-time metrics including packets dropped, bytes discarded, and per-address bandwidth consumption. These diagnostics enable rapid isolation of misconfigurations or unexpected traffic patterns.
Monitoring Integration
Forward-direction traffic shaped through standard policies appears within FortiView analytics, providing visual correlation between policy application and network behavior. Reverse shapers and per-IP constructs, however, operate outside this visibility layer—a design consideration requiring administrators to supplement dashboard monitoring with CLI-based diagnostics for comprehensive oversight.
Planning QoS Requirements
Successful deployment begins with quantifying actual service demands rather than applying arbitrary limits. Administrators should measure baseline consumption for critical applications, then establish guarantees slightly exceeding observed peaks to accommodate legitimate growth while preserving headroom for congestion management.
Priority assignment follows business logic: real-time services like VoIP or IPTV warrant elevated queues, while bulk transfers accept lower precedence. The six priority queues available per physical interface enable nuanced differentiation, though excessive granularity can introduce management overhead without proportional benefit.
Frequently Asked Questions
How does FortiGate handle bandwidth allocation when multiple shaping policies apply to the same traffic?
FortiOS evaluates shaping policies in sequential order, applying the first matching rule. Administrators should position specific, high-priority policies above broader catch-all constructs to ensure intended precedence.
Can interface bandwidth limits coexist with policy-based shapers?
Yes. Interface limits act as absolute ceilings, while policy shapers provide finer granularity within that boundary. Traffic exceeding interface thresholds drops immediately; traffic within interface limits but exceeding policy allocations undergoes queuing or policing per policy configuration.
What occurs when guaranteed bandwidth exceeds available capacity?
Guaranteed rates represent minimum allocations during congestion, not absolute reservations. If total guaranteed commitments exceed physical interface capacity, FortiOS proportionally scales allocations while maintaining relative priority relationships among traffic classes.
How do shaping policies interact with SSL inspection?
Traffic shaping operates independently of inspection mode. However, proxy-mode SSL inspection introduces additional processing latency that may affect real-time shaping responsiveness. Flow-mode inspection generally provides more predictable shaping behavior for encrypted flows.
Is bandwidth shaping applied before or after security profile inspection?
Shaping occurs after policy acceptance but before deep inspection in the processing pipeline. This sequencing ensures that only authorized traffic consumes shaped bandwidth, while maintaining inspection efficacy for threat detection.