# Verify both ends of pfSense LACP instead of treating bundled ports as automatic capacity

> Member speed, MTU, duplex, switch negotiation, and transmit hashing all affect the design.

- Canonical URL: https://update.dsesecurity.com/updates/verify-both-ends-of-pfsense-lacp-instead-of-treating-bundled-ports-as-automatic-capacity/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:16:18+00:00
- Modified: 2026-10-20T18:34:35+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Member speed, MTU, duplex, switch negotiation, and transmit hashing all affect the design.

## Potentially affected

This concerns pfSense LACP link aggregation.

## DSE recommendation

DSE recommends documenting the peer's supported aggregation design before attaching multiple cables.

## Article

Member speed, MTU, duplex, switch negotiation, and transmit hashing all affect the design.

## Source facts

Netgate states that LACP requires configuration on both pfSense and its switch peer. Member ports must have identical speed and MTU and operate full-duplex. A failed member reduces available capacity while the group continues. The firewall’s hash selection controls its transmitted traffic and does not determine how the peer distributes traffic in the reverse direction.

Source: [Netgate — LAGG (Link Aggregation)](https://docs.netgate.com/pfsense/en/latest/interfaces/lagg.html).

## Applicability

This concerns pfSense LACP link aggregation.

## DSE recommendation

DSE recommends documenting the peer’s supported aggregation design before attaching multiple cables. Compare every member’s physical and logical settings and agree on the traffic characteristics used for distribution. Size remaining capacity for a member-loss event. Review receive-path distribution on the switch separately from transmit-path settings on the firewall. Maintain a recovery port outside the aggregate while changing its membership or negotiation. Ask both firewall and switch owners to predict the transmit member for a defined set of flows. Measure the two directions separately and include an approved member-loss case. Label single-flow results honestly instead of presenting an aggregate multi-flow total as one application’s expected bandwidth.

## Verification

Confirm negotiated membership on both endpoints and inspect per-member counters under authorized varied traffic. Remove one member during an approved test and observe continuity and remaining capacity. Reconnect it and verify that the peer and firewall agree on its return to the group without a loop or unintended standalone port.

## Official reference

[Netgate — LAGG (Link Aggregation)](https://docs.netgate.com/pfsense/en/latest/interfaces/lagg.html). Reviewed October 20, 2026.

## Primary reference

- Name: Netgate — LAGG (Link Aggregation)
- Authority: docs.netgate.com
- URL: https://docs.netgate.com/pfsense/en/latest/interfaces/lagg.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Verify both ends of pfSense LACP instead of treating bundled ports as automatic capacity,” DSE Security, https://update.dsesecurity.com/updates/verify-both-ends-of-pfsense-lacp-instead-of-treating-bundled-ports-as-automatic-capacity/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.