FortiGate LACP Troubleshooting Guide & CLI Commands – 2026

Note: The commands, concepts, and debug workflows detailed in this guide are verified for modern FortiOS firmware (v7.0, v7.2, and v7.4). However, the core netlink and lacpd commands remain applicable across legacy versions as well.

FortiGate LACP troubleshooting

When designing high-throughput, resilient enterprise networks, relying on a single physical cable between your core switch and your firewall is a massive single point of failure. To mitigate this risk, network engineers deploy IEEE 802.3ad Link Aggregation Control Protocol (LACP).

LACP allows you to bundle multiple physical interfaces into a single, highly available logical interface. While configuring a basic aggregate interface in the FortiGate GUI is relatively simple, troubleshooting a failed negotiation or an asymmetric traffic imbalance requires a deep dive into the FortiOS command-line interface (CLI).

In this guide, we will explore the exact show, get, and diagnose debug commands you need to build, verify, and fix LACP connections on your Fortinet firewalls.

SECTION 1 — LACP OVERVIEW & CONCEPTS

What LACP Is on FortiGate

LACP (Link Aggregation Control Protocol, IEEE 802.3ad) combines multiple physical interfaces into a single logical aggregate interface (trunk). FortiGate implements this as a redundant interface or 802.3ad aggregate depending on the mode selected:

All commands in this reference cover the 802.3ad aggregate mode unless stated otherwise.

SECTION 2 — SHOW & GET COMMANDS

Interface Configuration Commands

Show aggregate interface configuration

show system interface <agg-interface-name>

Shows the full aggregate interface config — member interfaces, LACP mode, min-links, algorithm, and IP assignment.

Example output fields:

Show all interfaces including aggregate members

show system interface

Lists every interface. Aggregate member interfaces show their parent in the aggregate field. Useful for finding which physical ports belong to which aggregate.

Show redundant interface configuration

show system interface <redundant-interface-name>

Same command for redundant (non-LACP) aggregates. Key difference — no lacp-mode or lacp-speed fields, and type redundant instead of type aggregate.

Get physical interface hardware state

get hardware nic <physical-interface>

Shows the raw NIC-level statistics for a physical member interface:

Run this on every member interface individually:

get hardware nic port1
get hardware nic port2
get hardware nic port3

Get aggregate interface logical status

get system interface | grep -A5 <agg-interface-name>

Quick view of aggregate interface IP, status, and member count from the logical interface table.

Show interface physical status including speed and duplex

get system interface physical

Shows all physical interfaces with their current speed, duplex, link state, and traffic counters. Run this to confirm all aggregate member links are up at the same speed — a 1G member mixed with 10G members will cause LACP negotiation issues on some switches.

Show specific interface physical details

get system interface physical <interface-name>

Filters to a single interface. Confirms speed, duplex, and link state for a specific aggregate member.

SECTION 3 — DIAGNOSE STATUS COMMANDS

Core LACP Status Commands

Check aggregate interface and member status — primary command

diagnose netlink aggregate name <agg-interface-name>

The most important LACP verification command. Shows the aggregate interface state and every member’s LACP negotiation status.

Output fields per member:

LACP port state flags decoded

A healthy active member shows: ACTIVITY, AGGREGATION, SYNCHRONIZATION, COLLECTING, DISTRIBUTING all set. A port showing DEFAULTED means LACP PDUs have stopped — check the peer switch port. A port showing EXPIRED means the LACP session timed out — check cable and switch config.

Check aggregate via netlink interface list

diagnose netlink interface list <agg-interface-name>

Shows the aggregate interface from the kernel network stack perspective — MAC address, MTU, flags, and member count. Confirms the aggregate is registered at the OS level.

Check all netlink interfaces including aggregates

diagnose netlink interface list

Lists every interface in the kernel — physical, aggregate, VLAN, and tunnel. Aggregate interfaces appear with MASTER flag. Member interfaces appear with SLAVE flag showing their parent aggregate.

Check LACP PDU statistics per member

diagnose netlink aggregate member <physical-interface>

Shows LACP PDU counters for a specific member interface:

If lacp_in_pkts is zero and lacp_out_pkts is incrementing, the FortiGate is sending LACP PDUs but the peer switch is not responding — check switch-side LACP configuration.

If both are zero, LACP PDUs are not flowing at all — check physical link and LACP mode settings.

Check interface error counters on all members

diagnose netlink interface list port1
diagnose netlink interface list port2
diagnose netlink interface list port3

Run per member interface. Shows TX/RX error counters at the kernel level — these are more granular than get hardware nic and update in real time.

Show system link monitor status

diagnose sys link-monitor interface

Shows the link monitor state for aggregate interfaces — used in SD-WAN and routing failover scenarios where aggregate link health triggers route changes.

Check ARP table for aggregate interface

diagnose ip arp list | grep <agg-ip>

Confirms ARP resolution is working through the aggregate. If the ARP entry shows a wrong MAC or is missing, check that only one MAC is presented by the aggregate.

Check MAC address table consistency

diagnose netlink brctl name <bridge-or-agg>

On FortiGate units where the aggregate participates in a software switch or bridge, this shows the MAC forwarding table. Duplicate MAC entries indicate a loop or misconfigured aggregate.

SECTION 4 — TRAFFIC DISTRIBUTION VERIFICATION

Hashing Algorithm Commands

Check current hashing algorithm

show system interface <agg-interface-name> | grep algorithm

Shows which load-balancing algorithm is active:

Check per-member traffic distribution

diagnose netlink aggregate name <agg-interface-name>

In the output, look at the tx_bytes and rx_bytes per member. In a balanced aggregate, these should be roughly equal. Severe imbalance (one member at 90%, others at 10%) indicates the hash algorithm is not distributing your specific traffic patterns well — consider changing the algorithm L4. Keep in mind that how traffic is load-shared and offloaded at the hardware level is heavily dependent on your specific Fortinet FortiASIC architecture (such as the NP7 or NP6 processor).

Check per-member packet counters in real time

diagnose netlink interface list port1
diagnose netlink interface list port2

Run repeatedly with a few seconds between each run — watch the tx_packets and rx_packets counters increment. Uneven increment rates show how traffic is being distributed across members.

Packet capture to verify traffic leaving on correct member

diagnose sniffer packet port1 "host <dst-ip>" 4 50 l
diagnose sniffer packet port2 "host <dst-ip>" 4 50 l

Run on each member simultaneously (open two CLI sessions). If all packets for a destination appear on only one member, the hash is directing all that flow to one link — expected per-flow behaviour, but check if multiple flows are also all landing on the same member.

SECTION 5 — DEBUG COMMANDS

Core LACP Debug

LACP protocol debug — primary debug command

diagnose debug application lacpd -1
diagnose debug enable

lacpd is the LACP protocol daemon on FortiGate. Shows every LACP event:

• LACP PDU sent and received per interface
• State machine transitions (DETACHED → WAITING → ATTACHED → COLLECTING → DISTRIBUTING)
• Partner information updates (partner MAC, port, key, state flags)
• Bundle formation and member add/remove events
• LACP PDU timeout and expiry events

This is the only debug you need for most LACP negotiation failures.

LACP with lower verbosity — errors only

diagnose debug application lacpd 4
diagnose debug enable

Level 4 shows only state machine errors and timeout events. Use on production systems where level -1 generates too much output.

LACP state machine debug

diagnose debug application lacpd 8
diagnose debug enable

Level 8 shows detailed state machine transitions with the specific inputs that triggered each transition. Use when a member is stuck in an unexpected state (e.g. WAITING never transitioning to COLLECTING).

Network link daemon debug — physical link events

diagnose debug application linkd -1
diagnose debug enable

linkd Monitors physical link state changes and notifies LACP. Use this if LACP is not reacting when you physically pull a fiber cable. If your aggregate interface is up, but traffic is still failing to pass, you will need to step away from LACP debugging and trace the actual session. Check out our ultimate FortiGate packet flow and debug command guide to trace the dropped packets.

Interface manager debug — aggregate interface management

diagnose debug application ifmd -1
diagnose debug enable

ifmd manages interface configuration changes. Shows aggregate interface create/delete events, member add/remove operations, and IP address assignment changes on aggregate interfaces. Use when aggregate interface changes are not taking effect.

Kernel network stack debug for aggregate

diagnose debug kernel level 7
diagnose debug enable

Kernel-level debug showing network stack events including aggregate frame distribution and member selection decisions at the lowest level. Very verbose — use only when lacpd debug is not showing the issue.

Full LACP debug stack — run all together for complex issues

diagnose debug reset
diagnose debug disable
diagnose debug application lacpd -1
diagnose debug application linkd -1
diagnose debug application ifmd -1
diagnose debug enable

Captures the full event chain: physical link changes (linkd) → aggregate management (ifmd) → LACP protocol (lacpd). Use for bring-up issues where the aggregate won’t form at all.

SECTION 6 — LACP TROUBLESHOOTING SCENARIOS

Scenario 1 — Aggregate Interface Not Coming Up

# Step 1 — check physical member link state
get system interface physical
# All members must show 'link: up'

# Step 2 — check LACP negotiation state
diagnose netlink aggregate name <agg-name>
# Look for 'lacp state: selected' on each member
# If showing 'detached' — LACP not negotiated

# Step 3 — check LACP PDU counters
diagnose netlink aggregate member port1
diagnose netlink aggregate member port2
# lacp_in_pkts should be incrementing
# If lacp_in_pkts = 0 — peer switch not sending LACP PDUs

# Step 4 — check LACP mode matches peer
show system interface <agg-name> | grep lacp-mode
# If FortiGate is 'passive' and switch is also 'passive' — neither sends PDUs
# At least one side must be 'active'

# Step 5 — live debug
diagnose debug application lacpd -1
diagnose debug enable
# Watch for state transitions — DETACHED means no partner seen

Scenario 2 — Only Some Members Active (Partial Bundle)

# Step 1 — check which members are selected vs standby
diagnose netlink aggregate name <agg-name>
# Selected = active in bundle, Standby = excluded

# Step 2 — check actor key matches on all members
diagnose netlink aggregate name <agg-name>
# 'actor key' must be identical on all members
# Different keys mean members cannot bundle together

# Step 3 — check partner key
# partner key must match actor key
# Mismatch = peer switch has the port in a different LAG group

# Step 4 — check speed consistency
get hardware nic port1
get hardware nic port2
# All members must negotiate the same speed
# A 100M member will be excluded from a 1G aggregate

# Step 5 — check min-links setting
show system interface <agg-name> | grep min-links
# If min-links is met by partial bundle, aggregate stays up with fewer members
# Increase min-links to force down on partial failure if required

Scenario 3 — LACP Flapping (Members Repeatedly Joining and Leaving)

# Step 1 — check LACP PDU timeout events
diagnose debug application lacpd -1
diagnose debug enable
# Look for 'EXPIRED' state entries — PDU timeout firing
# Look for rapid DETACHED -> DISTRIBUTING cycles

# Step 2 — check lacp-speed setting
show system interface <agg-name> | grep lacp-speed
# 'slow' = 30-second PDU interval, 3x timeout = 90 seconds before expiry
# 'fast' = 1-second PDU interval, 3x timeout = 3 seconds before expiry
# If network has intermittent delays, switch from fast to slow

# Step 3 — check physical errors on member interfaces
get hardware nic port1
# Look for rising CRC_Errors or Rx_Errors
# Physical errors cause PDU loss which triggers LACP timeout

# Step 4 — check switch-side LACP timers
# Ensure switch LACP PDU interval matches FortiGate setting
# Mismatched fast/slow causes unnecessary flapping

# Step 5 — check for STP interference
# STP topology changes on the switch can temporarily block ports
# Blocked ports stop sending LACP PDUs causing FortiGate to see expiry

Scenario 4 — Traffic Imbalance Across Members

# Step 1 — confirm imbalance exists
diagnose netlink aggregate name <agg-name>
# Compare tx_bytes across members
# 80%+ on one member with others near zero = hash imbalance

# Step 2 — identify traffic type
diagnose sys session list
# Check whether sessions are all between same src/dst IP pair
# L3 hash on same src/dst = all sessions hash to same member — expected

# Step 3 — change hashing algorithm
config system interface
    edit <agg-name>
        set algorithm L4
    next
end
# L4 adds port numbers to hash — better for same src/dst with many ports

# Step 4 — verify improvement
diagnose netlink aggregate name <agg-name>
# Check tx_bytes distribution after algorithm change
# Allow 60 seconds for new sessions to distribute

# Step 5 — if traffic is all from one source IP
# Per-flow hashing means one source = one member — by design
# Consider whether flow count justifies additional members

Scenario 5 — Aggregate IP Unreachable After Config Change

# Step 1 — check aggregate interface is up
diagnose netlink interface list <agg-name>
# Must show 'UP' flag and correct IP

# Step 2 — check at least one member is in distributing state
diagnose netlink aggregate name <agg-name>
# At least one member must show DISTRIBUTING

# Step 3 — check ARP
diagnose ip arp list | grep <agg-ip-or-gateway>
# Confirm gateway ARP is resolving via aggregate

# Step 4 — check routing uses aggregate
get router info routing-table details <destination-ip>
# Route must show egress via aggregate interface, not a member port

# Step 5 — check firewall policy
diagnose sys session filter src <test-src>
diagnose sys session filter dst <agg-ip>
diagnose sys session list
# Confirm session is being established and not dropped by policy

SECTION 7 — LACP WITH HA

When deploying LACP aggregates inside a High Availability (HA) cluster, special rules apply. If you are experiencing broader cluster instability beyond just your aggregate links, we highly recommend reviewing our complete guide on FortiGate HA commands and failover troubleshooting.

Additional Commands When LACP and HA Are Combined

Check aggregate member status on both HA units

# On primary:
diagnose netlink aggregate name <agg-name>

# On secondary:
execute ha manage 1 admin
diagnose netlink aggregate name <agg-name>

Member states must be healthy on both units. In HA active-passive mode, the secondary’s aggregate members should also be in DISTRIBUTING state because LACP negotiation runs independently on each unit.

Verify HA heartbeat is not running over the aggregate

show system ha | grep hbdev
show system interface <hbdev-interface>

HA heartbeat should never run over an LACP aggregate — heartbeat loss during aggregate renegotiation would trigger unnecessary HA failover. Heartbeat should use dedicated physical interfaces.

Check aggregate consistency across HA cluster

diagnose sys ha checksum show | grep interface

Interface configuration checksums must match between primary and secondary. An aggregate config difference between units causes the secondary to come up with a different aggregate configuration after failover.

QUICK REFERENCE — ALL LACP COMMANDS BY CATEGORY

Configuration & Status

LACP Negotiation Status

Traffic & Distribution

Debug Daemons

Troubleshooting

UNIVERSAL CLEANUP

diagnose debug disable
diagnose debug reset

Always run after any debug session. lacpd debug at level -1 is particularly verbose on high-traffic aggregates and will noticeably impact the management plane if left running.

Frequently Asked Questions (FAQ)

Q1: Why is my 2x1Gbps LACP aggregate not giving me 2Gbps of throughput on a single file transfer? A: This is the most common misunderstanding of LACP. Link aggregation provides load sharing, not true load balancing. Traffic distribution is based on a hashing algorithm (usually Source/Destination IP). A single session (like one large SMB file transfer) will hash to one specific physical link, capping its maximum speed at 1Gbps. To see the full 2Gbps utilized, you need multiple diverse sessions from different source/destination pairs.

Q2: How should I cable an LACP trunk from a FortiGate HA cluster to my core switches? A: It depends on your core switches. If your switches support MC-LAG (Multi-Chassis Link Aggregation) or stacking (like Cisco VSS/StackWise), you should cable one port from FortiGate-A to Switch 1, and one to Switch 2, creating a single LACP bundle. If your switches do not support MC-LAG, you must create two separate LACP bundles.

Q3: I am connecting my FortiGate to a Cisco/Meraki switch and the LACP bundle drops after 20 seconds. What is wrong? A: This is almost always a mismatch in the LACP timer speeds. FortiOS defaults its lacp-speed to fast (sending PDUs every 1 second, timing out after 3 seconds). Many Cisco and Meraki switches default to slow (sending PDUs every 30 seconds, timing out after 90 seconds). You must align the timers by changing the FortiGate to set lacp-speed slow under the interface configuration.

Q4: Can I use LACP to connect a FortiGate directly to two independent FortiSwitches? A: Yes, but you must utilize FortiLink split-interface mode or ensure the two FortiSwitches are configured with MC-LAG (Multi-Chassis LAG) via an Inter-Switch Link (ISL). If the switches are completely standalone and not clustered, the FortiGate cannot form a standard 802.3ad LACP aggregate across two independent MAC domains.

Q5: What is the difference between an 802.3ad aggregate interface and a redundant interface in FortiOS? A: An 802.3ad aggregate relies on the formal Link Aggregation Control Protocol. It sends and receives LACP PDUs to ensure the peer switch is healthy before passing traffic, and it load-shares traffic across all active links. A redundant interface does not use LACP PDUs; it simply puts one link in an active forwarding state and holds the other in a passive standby state based on physical link status.

Q6: Can I mix a 1Gbps port and a 10Gbps port in the same FortiGate LACP bundle? A: While FortiOS CLI may allow you to add ports of different physical speeds into an aggregate, doing so violates the IEEE 802.3ad standard. The LACP negotiation will fail or the slower port will be marked as suspended (standby or detached). All member interfaces in an LACP bundle must negotiate to the exact same speed and duplex.

Q7: In an Active-Passive HA pair, does the secondary FortiGate participate in LACP? A: By default, yes. The secondary FortiGate brings up its physical ports and negotiates LACP with the upstream switch to ensure a seamless, sub-second failover. If your upstream switch does not support MC-LAG and gets confused by seeing two LACP bundles, you can configure set lacp-ha-slave disable on the FortiGate to prevent the standby unit from negotiating LACP until a failover occurs.

Q8: Why are my VLANs not passing traffic over my FortiGate LACP trunk to my D-Link/3rd-party switch? A: If the aggregate is up but VLANs are failing, check your native VLAN and tagging configuration. Ensure the aggregate interface on the switch is explicitly configured as an 802.1Q trunk. Additionally, verify that the hashing algorithm on the switch matches the hashing algorithm on the FortiGate (e.g., L3/L4 hash).

Q9: What happens if one physical link in my 4-port LACP bundle gets disconnected? A: The FortiGate will detect the loss of physical link (or the loss of LACP PDUs) and immediately remove that specific port from the DISTRIBUTING state. The remaining 3 links will continue passing traffic without bringing the logical interface down. You can control this behavior using the min-links configuration parameter.

Q10: Can Spanning Tree Protocol (STP) interfere with FortiGate LACP negotiation? A: Yes. If the upstream switch sees a topology change and STP places the switch ports into a Blocking or Listening state, it will temporarily stop sending LACP PDUs. The FortiGate will hit its LACP timeout, mark the ports as EXPIRED, and drop the bundle. Always ensure the switch ports connected to the FortiGate are configured as STP Edge ports (PortFast).

Bhardwaj Vishnu

Bhardwaj Vishnu is a Network Security Engineer with hands-on expertise in enterprise firewall management, network automation, and multi-vendor infrastructure. He holds Fortinet NSE 4/NSE 5, a Cisco CCNA, and the full Cisco Meraki certification track. He architects FortiGate security policies, manages Cisco Meraki MX/MS/MR deployments, and handles enterprise routing and switching. Every guide on netconfig.io comes from direct production experience — real CLI commands, verified configs.