Securely configure Sophos switch ports, LAG and spanning tree

Ports, link aggregation and spanning tree must be planned as one coherent Layer 2 change. An uplink disabled by mistake disconnects management, while two unplanned links connected in parallel can form a loop. This runbook therefore configures the peer and protection mechanisms first, synchronizes the configuration in a controlled manner, and then validates the link, LAG and STP together.

The entry into Sophos Fusion is:

My Products > Switches > [Switch] > Port settings

Important: Changes on the page are only synchronized to the switch with Update. Save in the LAG dialog saves the LAG within the page configuration that has not yet been rolled out; it does not replace Update. Clear discards changes that have not yet been transferred.

Requirements and change plan

Before the change, these points are documented:

• affected switch, physical ports and peer connected to each cable
• current management path as well as an independent return path, for example local access or a second, unchanged uplink
• peer port type, supported speed and duplex setting
• desired LAG type on both sides and at least two available Ethernet or SFP ports
• LACP distribution method and timeout if LACP is used
• existing redundant Layer 2 paths, planned root bridge and expected blocking or forwarding STP ports
• initial state of Configuration source, Conflicts, LBD, STP, root bridge, port roles and port status
• maintenance window, test traffic, success criteria and rollback

All members of a LAG must be assigned to the same logical connection on both devices. Speed, duplex, LAG type and LACP behavior are checked for compatibility before cabling. An existing management uplink is not converted at the same time as the new connection as long as there is no tested return path.

This runbook assumes that the required VLANs have already been planned. Columns Untagged VLAN and Tagged VLAN are read here only as acceptance context; VLAN membership, PVID, GVRP and Voice VLAN belong in the separate VLAN change. Likewise, PoE, port mirroring for NDR, QoS and storm control are not part of this flow.

Clarify configuration source and conflicts first

In Basic settings, Configuration source shows whether a setting comes from Sophos Fusion or from the local switch configuration. For Flow control, Speed/Duplex and other supported fields, Not set means that the local setting is used. This is not a statement about which specific local value is active.

After the first registration or a factory reset, all ports and LAGs initially show Conflicts: The Fusion default is Not set, while the local switch defaults differ. Two actions are available:

• Resolve conflicts applies the local switch configuration for the individual port in Sophos Fusion.
• Resolve all conflicts adjusts all affected Fusion settings to the current switch configuration.

Before using Resolve all conflicts, verify that all local values really are the desired baseline. For a targeted change, using Resolve conflicts per port is less risky. After resolving a conflict, verify the imported value rather than simply dismissing the warning.

Attention: If a value of Not set is changed to an explicit status at the switch level, it does not automatically revert to Not set when later inheriting a site or stack configuration. The desired source must therefore be determined before the change.

Configure physical ports

Under Basic settings there are the following fields relevant to this process for each port:

• Port: physical port number
• Label: unique description, for example the peer and purpose
• Flow control: Enable, Disable or Not set
• Speed/Duplex: Auto, 10M/Half, 10M/Full, 100M/Half, 100M/Full, 1G/Full, Disabled or Not set
• Configuration source: Origin of setting
• Conflicts: Difference between Sophos Fusion and local configuration

Auto negotiates speed and duplex with the peer. Choose a fixed value only if the peer deliberately uses the same value. Mismatched negotiation or duplex settings can bring a link up but cause throughput and error problems. Disabled under Speed/Duplex switches off the port. Not set adopts the local value and is not the same as Disabled.

Choose Flow control to match the design of both endpoints. It cannot correct duplex, cabling or congestion problems. Set labels before rollout so that a technician can identify each port and its peer without having to decipher the network diagram.

Advanced port options

Under Advanced settings, these port-related options belong in the same change:

• Port isolation: Enable allows the port to communicate only with upstream ports; downstream communication is blocked. Disable removes the isolation, Not set uses the local setting.
• EEE: Enable activates Energy Efficient Ethernet according to IEEE 802.3az, Disable deactivates it, Not set uses the local value.
• Jumbo frame: desired frame size in bytes. The maximum is 9216 for CS101-8 and CS101-8FP, and 10240 bytes for all other models.

Enable jumbo frames only if every hop and endpoint supports the selected size; the configured size must not exceed the maximum of any device in the path. For per-port configuration, use the gear at the top of the column to enable Show per port setting. Per-port jumbo frames are available only at switch level, not at site or stack level.

Multicast filtering is not changed on the fly. Technically, it is part of multicast planning because it influences which ports multicast traffic is forwarded to.

For independent port changes whose ports are not intended as members of a new LAG, the following applies after the port changes:

1. Compare changed lines and Configuration source again.
2. Ensure that the active management port is not unintentionally set to Disabled.
3. Click Update.
4. Wait for synchronization and link status and immediately test management access again.

Attention for future LAG members: Their port changes will not be rolled out with this early Update as unbundled, parallel-connected individual ports. All additional cables remain physically disconnected or the relevant ports disabled. Port, LAG and protection configuration are prepared together and only activated in the controlled order of the following LAG sequence.

Select LACP or static LAG

Under LAG ports, Member ports shows the members of each logical LAG. A LAG bundles at least two Ethernet or SFP links between two network devices and can provide greater throughput and availability.

There are four values for Type:

• LACP: recommended choice. The Link Aggregation Control Protocol controls bundling and negotiates participating links with a peer that is also configured for LACP.
• Static: use only if the peer also expects a static bundle or does not support LACP. There is no LACP negotiation; membership and cabling must be planned precisely on both sides.
• Disabled: LAG is switched off.
• Not set: use local LAG configuration of the switch.

LACP is preferred for new bundles. Static is not a quick substitute for nonfunctional LACP: changing the type on only one side can cause links to forward outside the expected bundle control. Never simply connect multiple cables in parallel if the peer has neither LACP nor a static LAG configured.

A LAG increases the total available capacity across multiple traffic flows. The chosen System policy assigns each traffic stream to a member based on the specified hash fields and keeps it there. It does not follow from this that a single connection automatically achieves the sum of all link speeds.

Create LACP LAG in a controlled manner

1. Leave all future LAG cables physically disconnected until controlled activation or deactivate the relevant ports. An already productive individual path initially remains unchanged.
2. Prepare the peer with the same LAG type and exactly the associated physical ports, without activating an additional individual path.
3. Open the desired LAG under LAG ports.
4. Set Type to LACP.
5. Select at least two planned ports under Ports.
6. Click Save.
7. Give the LAG a unique Label.
8. Set Flow control to match the peer; the Sophos instructions use Enable for the LACP procedure.
9. Under Speed/Duplex, select the agreed value or Auto.
10. Under LACP settings, check system parameters and port timeouts.
11. Prepare the planned protection configuration before link activation, then compare the port lists and all pending changes on both sides again. If the existing single path remains in parallel when the new path is activated, STP must already protect the redundant topology; LBD alone is not a substitute.
12. Transfer port, LAG and protection configuration to the Sophos switch with Update and apply the corresponding remote configuration in the coordinated maintenance window.
13. Verify successful synchronization, management access, and effective STP and supplemental LBD while additional links remain disconnected or disabled. If no active STP is planned for the parallel path, the old path must be separated in a controlled manner before activating the first new member.
14. First connect or activate exactly one intended LAG member according to the cable plan and check its LAG and STP status.
15. Only then connect or activate additional members individually. Check LACP, LAG and STP status as well as management access for each member.

If the previous individual management uplink itself is a future LAG member, it cannot be reconfigured without a transition: both sides are converted in a coordinated manner in a maintenance window. This requires an independent management path; a switch that can only be reached via this link will not be switched remotely without an independent access path.

For a static LAG, the process is the same, except that Type: Static is chosen and there is no LACP negotiation as protection against a different counterparty. Therefore, the port lists and the static LAG status of both sites are compared again immediately before Update and before each link activation.

LACP system settings

LACP settings offers the following controls:

• System priority: 0 to 65535, default 32768. The device with the lower system priority determines which ports participate in the LAG.
• System policy: determines the distribution of traffic flows.
• Timeout: is set to Not set, Short or Long per port.

Available System policy values are:

The policy is selected based on the expected diversity of traffic flows and documented in the change. Frequent policy switching is not a useful substitute for distribution measurement.

With Short, an LACP PDU is sent every second and the LACP information expires after three seconds without a received PDU. Long sends every 30 seconds and expires the information after 90 seconds. Not set uses the locally configured timeout. Short detects failures faster but generates protocol packets more frequently; consider both peers and operational requirements before choosing.

Use loopback detection

Loopback detection (LBD) sends its own loop protocol packets from ports on which loop protection is active. If the switch receives a self-sent packet back, it shuts down the receiving port. LBD is therefore targeted additional protection against a returned connection.

1. In section Loopback detection select Status On. Off deactivates LBD; Not set uses the local switch setting.
2. Click Update.
3. Then check the LBD status of the ports. The view also shows whether a port was shut down by LBD.

LBD and STP do not solve the same task. STP uses BPDUs to calculate a loop-free topology with replacement paths. LBD reacts to the return of its own test packet and can switch off the receive port. Redundant switch paths are therefore designed using STP; LBD is used as a supplement and not as a replacement for a missing STP design.

Plan RSTP or MSTP

In tab STP, Global settings - STP configures the switch. STP exchanges Bridge Protocol Data Units (BPDUs), chooses a loop-free path, and can release a replacement path after a failure.

• RSTP converges quickly and forms exactly one spanning tree. It suits smaller or simple Layer 2 topologies.
• MSTP forms multiple spanning trees for VLAN groups. It is suitable for larger networks in which different VLAN groups require separate topologies or load distribution.

MSTP is not chosen solely because of the network size: all switches in an MST region must be operated with a consistent region design. Without scheduled instances and VLAN groups, RSTP is the easier choice.

Global STP Settings

1. Set STP state to On. Off deactivates STP, Not set applies the local setting.
2. Select BPDU forwarding to suit the design.
3. Select among Forced version RSTP or MSTP.
4. Adjust bridge priority and timers only according to the documented STP design.
5. For MSTP, set Configuration name and Configuration revision consistently across the region.
6. Check the changes and transfer them to the switch with Update. If you instead want to discard them before transferring them with Update, click Clear.

Restriction: STP state and BPDU forwarding cannot be turned on at the same time. BPDU forwarding is therefore not an additional switch to active STP.

The global fields and boundaries are:

The root bridge is deliberately set via Priority, not randomly via MAC addresses. Timers are not reduced individually for the supposed acceleration: their effect is planned for the entire STP domain and checked on all relevant switches after the change.

RSTP port parameters

After Forced version: RSTP, RSTP port settings per port shows:

• Priority: Multiples of 16 between 0 and 240
• Path cost configuration and operation: 0 to 200000000
• Edge port configuration/operation
• P2P MAC configuration/operation: Not set, Auto, Enabled or Disabled
• Port status: Enabled, Disabled or Not set
• Migration start time: Enabled, Disabled or Not set
• BPDU guard, Root guard and BPDU forward: each Enabled, Disabled or Not set
• Configuration source

An Edge port is intended exclusively for true endpoint devices such as clients or servers and enables a quick transition to the forwarding state when the link comes up. If a switch, a bridge or an unknown downstream Layer 2 infrastructure is connected to a port, it must not be treated as an edge port. BPDU guard is available as a configurable field. Edge is not a general switch to accelerate convergence.

A P2P link connects network devices. Auto lets the switch recognize the link type; Enabled or Disabled sets it explicitly. When a P2P port becomes root port or designated port, it can switch directly to the forwarding state for faster convergence.

After rolling out, Designated root bridge, External root cost, Designated bridge, Port role and Port state are also checked at the switch level. A port in a blocking STP state is not automatically faulty if a redundant path is present.

Configure MSTP region and instances

After Forced version: MSTP, CIST port settings, MST instance settings and MST port settings appear.

The CIST port settings connect the MST regions via the Common and Internal Spanning Tree. They contain the same essential port fields as RSTP: priority, configured and operational path cost, edge and P2P status, port status, Migration start time, BPDU guard, Root guard, BPDU forward and Configuration source. At the switch level, Regional root bridge, Designated root bridge, External root cost, Designated bridge, Port role and Port state are also displayed. Changes are applied with Update.

A maximum of four MST instances can be created under MST instance settings:

1. Click Add.
2. Enter a MST ID from 1 to 4.
3. Enter a single VLAN ID or a range such as 1-100 under VLAN list.
4. Set Priority to a multiple of 4096.
5. Click Save.

The assignment in VLAN list maps existing VLANs to an STP instance; it does not create VLANs or port memberships. Before saving, the region name, revision, and instance mapping are verified to match the region-wide plan. Instances are selected and deleted with Delete; do not do this without checking the resulting CIST topology.

Under MST port settings, MST ID is selected first. The following can be configured per port:

• Priority: Multiples of 16 between 0 and 240
• Internal path cost configuration and operation: 0 to 200000000
• Port status: Enabled, Disabled or Not set

For acceptance, the view shows Regional root bridge, Designated root bridge, Internal root cost, Port role, Port state and Configuration source. Finally, click Update.

Secure sequence for a productive change

1. Record the initial state, cable plan, peer configuration, management return path and expected root bridge.
2. Evaluate existing Conflicts individually and determine the desired Configuration source.
3. Check LBD and STP design on paper first; in particular root priority, edge ports and MST region parameters.
4. Leave all additional LAG cables disconnected or their ports disabled; initially retain the previous unique individual path.
5. Prepare the peer for LACP or Static without inadvertently activating a second Layer 2 path.
6. Configure the ports and LAG in Sophos Fusion; use Save in the LAG dialog.
7. Configure STP and, if necessary, additional LBD before link activation and check all changes that have not yet been transferred. If the old path is to remain temporarily in parallel, STP must protect this redundant topology; otherwise, disconnect the old path in a controlled manner before activating the new one.
8. Synchronize the port, LAG and protection configuration with Update, and apply the peer configuration in coordination. Do not install additional VLAN, PoE, mirroring or QoS changes in parallel.
9. Check management access and the effective protection configuration before activating an additional path.
10. During the maintenance window, first connect or activate exactly one intended LAG member and only after checking other members individually. If an existing uplink needs to be reconfigured, the coordinated switchover of both sides takes place via the prepared return path.
11. After each step, check the port and LAG status, LACP members, root bridge, port roles and test traffic.
12. Only after stable acceptance can you remove or deactivate the old uplink that does not belong to the LAG.

If the change affects the only current management path, independent out-of-band or on-site access is required. Without this return path, the steps are not carried out exclusively remotely.

Acceptance

A successful synchronization alone is not a technical acceptance. The following points are checked immediately and after an observation phase:

Ports and LAG

• No unexpected Conflicts; Configuration source corresponds to plan.
• Each changed port has the correct Label, Flow control and Speed/Duplex.
• Physical link is stable; no repeated link changes or obvious speed/duplex deviations.
• Member ports contains exactly the planned LAG members.
• LAG type matches on both sides; with LACP, the expected links take part.
• A test over the logical connection works in both directions.
• With planned redundancy, test the failure of exactly one member in a controlled manner; the remaining path must then carry traffic, and the removed link must rejoin the LAG after reconnection.
• A load test with several suitable traffic flows checks the capacity. A single flow is not evidence of distribution to all members.

LBD and STP

• LBD does not show an unexpectedly down port.
• Under Root bridge information, Root address, Priority, Cost and Port match the design.
• Bridge address, Forward delay, Maximum age and Hello time are plausible.
• Port role and Port state correspond to the expected active and redundant topology.
• For RSTP, edge, P2P, guard and path cost values are correct.
• For MSTP, Configuration name, Configuration revision, MST IDs, VLAN lists as well as regional root bridges and port status of each instance are correct.
• A planned path failure converges to the replacement path; upon recovery, the network returns to the expected stable state.

Root bridge information is only available at the switch level, not at the site or stack level. The individual switch is therefore opened for this check.

Troubleshoot by symptom

After the update, the port is down

• Check whether Speed/Duplex: Disabled has been set.
• Compare Auto or the fixed value with the peer setting.
• Check the cable, SFP module and supported speed.
• Check whether LBD has shut down the port or whether STP is just not allowing it to forward.
• Check Configuration source and whether a new Conflict has appeared.

An LACP member is not participating

• Confirm Type: LACP on both sides.
• Compare physical ports and Member ports against the cable plan.
• Check speed/duplex and link status of each member.
• Do not change LACP System priority, System policy and especially the port-related timeout on suspicion; first compare the peer status.
• Ensure that Update was clicked after Save.

Static LAG creates loss or a loop

• Disconnect additional links in a controlled manner until exactly a safe path exists again.
• Check whether the peer has the same ports in a static LAG.
• Do not unilaterally switch the LAG between Static and LACP.
• Check STP and LBD status, then correct both sides according to a common plan.

LBD shuts down a port

• Treat the event as evidence of a loop; do not repeatedly reactivate the port without investigating.
• Follow the cabling behind the receiving port, especially patch panels, small unmanaged switches and duplicate connections.
• Return the port to service according to the change plan only after eliminating the loopback path.
• Then check the LBD status and STP topology again.

Unexpected root bridge or incorrect path

• Compare Root address, bridge priorities and MAC addresses.
• Check whether the desired Priority was saved and synchronized as a multiple of 4096.
• Change port priority and path cost only if the desired path is documented.
• For MSTP, compare the region name, revision and VLAN instance assignment on all switches involved.
• Do not hastily force a blocking redundant port to become active; first understand the root, designated and port roles.

STP cannot be activated together with BPDU forwarding

This is the documented product limit: global STP state: On and BPDU forwarding: On exclude each other. It must be determined whether the switch itself participates in STP or forwards BPDUs according to the intended scenario. Both switches must not be forced at the same time.

Change does not appear on the switch

• Check whether only Save has been executed in the LAG or instance dialog, but not Update on the page.
• After Update, check the Configuration source and Conflicts.
• For Not set, check the value actually configured locally; Not set is not a specific operating status.
• Changes that have not yet been transferred to the switch with Update should not be discarded with Clear as long as they are still needed.

Rollback

A rollback restores the documented previous state rather than choosing Not set indiscriminately:

1. Disconnect or deactivate the newly activated redundant physical paths in a controlled manner so that no parallel individual connections can form a loop. The independent management return path remains available.
2. Determine a clear, documented single path for the rollback and ensure that it can be cabled and configured identically on both sides.
3. During the maintenance window, coordinate the rollback of the LAG and associated port configuration on the peer and in Sophos Fusion to this single path. If the remaining link itself is removed from the LAG, the switchover of both sides takes place via the independent management path and not unilaterally.
4. Use Save in the dialog, then synchronize with Update and only check the management access and data traffic after the individual path has been confirmed.
5. Only after the LAG has been removed, exactly one stable path is forwarding, and no redundant individual connections remain, restore the previous STP priorities, port parameters and LBD setting and synchronize with Update.
6. Recheck Configuration source, Conflicts, root bridge, port roles, link status, management access and test traffic.

Returning to Not set is correct only if the local switch configuration is deliberately intended to apply again. It does not guarantee that the previous explicit fusion value will be automatically reconstructed.