How to configure FortiGate port bandwidth limits via CLI (FortiOS 7.x)

Limiting how much bandwidth a FortiGate interface can use is one of those jobs that looks small and quietly protects the whole network: stopping a backup job from flattening a site-to-site link, keeping a guest VLAN honest, or matching a WAN port to the bandwidth your provider actually delivers. This guide covers the current way to do it from the CLI on FortiOS 7.x, along with the hardware-offload caveats that catch people out, how to verify the limit is really working, and when you should reach for traffic shaping policies instead.

What interface bandwidth limits do

FortiOS lets you cap traffic per interface in both directions. The inbandwidth setting polices arriving traffic: packets beyond the limit are dropped at the interface before the firewall spends any processing on them. The outbandwidth setting shapes departing traffic on the egress side. Both are set in kilobits per second (kbps), and a value of 0 means unlimited, which is the default.

The kbps unit is the single most common mistake with this feature. If you want a 100 Mbps cap, the value is 100000, not 100. Setting 100 gives you a 100 kbps interface and a very quiet phone call asking why the internet has stopped.

Step 1: Set the limit on a physical interface

Connect over SSH or the console and enter the interface configuration. This example caps port1 at 200 Mbps inbound and 100 Mbps outbound:

config system interface
    edit "port1"
        set inbandwidth 200000
        set outbandwidth 100000
    next
end

The change takes effect immediately, no reboot needed. To remove a limit, set the value back to 0.

If you prefer the GUI for confirmation, the same settings appear under Network > Interfaces > edit the port > Traffic Shaping, as inbound and outbound bandwidth.

Step 2: VLAN interfaces

VLAN subinterfaces accept the same commands. Outbound limits on VLANs are fully supported on current FortiOS and are the standard way to stop one VLAN monopolising a trunk:

config system interface
    edit "vlan-guest"
        set outbandwidth 50000
    next
end

That caps the guest VLAN at 50 Mbps outbound. Fortinet's current documentation supports outbandwidth values on VLAN interfaces up to 100,000,000 kbps, with 0 meaning no maximum. Inbound limits on VLAN interfaces are less consistently honoured across hardware platforms, which brings us to the caveat that matters most.

Step 3: Know your hardware offload caveats

This is the part most older guides miss, and it is the number one reason people believe the feature is broken. On models with NP6 or NP6xlite network processors, most traffic is hardware-accelerated and never touches the CPU path where inbandwidth is enforced. The result, straight from Fortinet's own technical guidance: the inbandwidth setting has no effect on an NP6 or NP6xlite interface unless NP offloading is disabled for that traffic, and outbandwidth on those processors enforces a lower limit than the one configured.

If you genuinely need an inbound cap enforced on such a model, disable offload in the relevant firewall policy so the traffic takes the CPU path:

config firewall policy
    edit <policy-id>
        set auto-asic-offload disable
    next
end

Be deliberate about this: disabling offload trades throughput for enforcement, so scope it to a dedicated policy for the traffic you need policed rather than switching it off broadly. Newer NP7-based platforms handle interface-based shaping in hardware far better, and some E-series models support interface shaping with NP acceleration natively. If behaviour matters for a purchase or design decision, check the hardware acceleration notes for your exact model and FortiOS release.

Step 4: Verify the limit is working

Confirm the configuration took:

show system interface port1

You should see your set inbandwidth and set outbandwidth lines. Then prove it with traffic. Watch live throughput per interface with:

diagnose netlink interface list port1

or, for a friendlier rolling view of interface counters:

diagnose sys session stat
get system performance status

The practical test is an iperf3 run or a large file transfer across the interface: throughput should plateau at your configured ceiling. If it sails past the limit, you are almost certainly looking at the NP offload caveat above.

When to use traffic shaping policies instead

Interface limits are a blunt, reliable instrument: one ceiling for everything on the port. They are the right tool for matching a WAN interface to provider bandwidth or hard-capping a whole segment. They are the wrong tool when you want nuance, and FortiOS has a proper traffic shaping system for that:

• Shared shapers apply one bandwidth pool to all traffic matching a shaping policy, with guaranteed and maximum bandwidth plus priority, so you can promise VoIP its slice while capping bulk traffic.
• Per-IP shapers divide bandwidth per source address, the classic fair-usage answer for guest networks where no single device should hog the cap.
• Shaping policies (config firewall shaping-policy) match traffic by source, destination, service or application and apply shapers in both directions, which is how you shape a specific application rather than a whole port.

A sensible rule of thumb: set inbandwidth/outbandwidth to reflect physical or contractual reality on the interface, then use shaping policies for anything that involves the words "except", "guarantee" or "per user".

Common pitfalls, collected

• Units. Values are kbps. 100 Mbps is 100000.
• Zero means unlimited, not blocked.
• NP6/NP6xlite offload silently bypasses inbandwidth and undercuts outbandwidth; disable offload in a scoped policy if enforcement matters.
• Interface limits stack with policy shapers. The most restrictive control wins; if throughput is mysteriously low, check both layers.
• Inbound policing drops, it does not queue. TCP adapts, but latency-sensitive UDP (voice, video) suffers under an aggressive inbound cap; prefer shaping egress at the sending side where you can.
• Document the why. A bandwidth limit with no note attached becomes a mystery outage two years later.

Quick reference

# Cap a port (values in kbps)
config system interface
    edit "port1"
        set inbandwidth 200000
        set outbandwidth 100000
    next
end

# Remove the cap
config system interface
    edit "port1"
        set inbandwidth 0
        set outbandwidth 0
    next
end

# Verify
show system interface port1
diagnose netlink interface list port1

If you are sizing FortiGates, untangling shaping policies, or inheriting a firewall where nobody knows why the guest Wi-Fi is capped at dial-up speeds, this is exactly the kind of work we do. Get in touch and we will take a look.