LumiNode / LumiCore – RSTP Support and Updated Redundancy Behavior

Minimal firmware version: v2.8

Introduction

Starting from firmware v2.8, LumiNode and LumiCore devices have full support for Rapid Spanning Tree Protocol (RSTP). This significantly improves behavior when both network ports of a unit are connected to the same switch or into a redundant network structure.

In previous firmware versions, certain port combinations could lead to loops or packet storms, especially when a switch’s loop‑protection settings did not match the LumiNode configuration. Failover times were also relatively long. The use of RSTP inside the LumiNode / LumiCore resolves these issues and enables stable, predictable redundant network topologies.

Why RSTP Matters

When both Ethernet interfaces of a LumiNode / LumiCore are connected into the same physical network, a loop is formed. Without RSTP, this could cause:

• broadcast or multicast storms
• loss of management connectivity
• slow or unpredictable failover behavior

With the new v2.8 firmware, LumiNode / LumiCore participates correctly in RSTP alongside network switches. This ensures that one port is placed into a forwarding role and the other into a discarding role (alternate/backup) depending on the network topology. If the active path fails, the redundant path becomes active much faster than in previous versions.

BPDU Guard: Some switches implement BPDU guard. When they receive an RSTP BPDU on a certain port where it is not 'expected', they will disable that port. This will cause the LumiNode / LumiCore to become unreachable!
Luminex GigaCore switches do not have BPDU guard and are therefore not affected by this problem.

When using managed switches from another manufacturer, align with your IT department to make sure RSTP BPDU guard is disabled on the LumiNode / LumiCore ports before upgrading to a v2.8 firmware or newer.
Alternatively, RSTP can be disabled in the LumiNode using API through the stp_mode field under /api/network_config. Do this before connecting the LumiNode / LumiCore to the switch.

How RSTP Works on LumiNode / LumiCore

Automatic Enable and Disable

The device automatically enables or disables RSTP depending on port configuration. Port configuration can be done by using "Advanced Networking configuration".

• If both interfaces participate in network groups that overlap (for example: same VLAN, same management group, or ISL trunk that shares at least one group), RSTP is enabled.
• If the interfaces are placed in non‑overlapping groups (e.g., Management on ETH1 and sACN on ETH2), RSTP is disabled to prevent a switch from incorrectly treating this configuration as a loop.
• RSTP is also enabled when trunking / ISL is used, provided there is overlap in the groups (VLANs) assigned to the trunks in use.
• LumiNode does not support link aggregation (LACP). The device participates in RSTP as an endpoint with two independent interfaces.
  

RSTP Roles and Terms (as used by LumiNode)

• Root Port – The port that offers the best path toward the RSTP root bridge (LumiNode is configured so that it should not become the root bridge).
• Designated Port – The forwarding port for a segment.
• Alternate Port – A port providing an alternate path toward the root bridge.
• Forwarding – The active data‑carrying state.
• Discarding – The non‑forwarding state used to prevent loops.

The LumiNode parameters (path cost, root bridge priority,...) are tuned so that switches take priority in determining the active path and so that LumiNode devices do not claim the role of root bridge.

API Control and Monitoring

• RSTP behavior can be changed through the stp_mode field under /api/network_config.
• Current spanning tree status can be retrieved using /api/spanning_tree.
  

Scenarios and Updated Behavior

Below is a summary of the scenarios from older firmware, along with how they behave with the new RSTP support.

1. Both ports in the same group (e.g., both in Management group 1)

• Worked only if RLinkX was enabled on the GigaCore switch.
• Failover delays up to around 15 seconds.
• Misconfiguration could cause packet storms.

New behavior:

• RSTP automatically enabled on the LumiNode
• One port becomes Designated (Forwarding); the other becomes Alternate (Discarding).
• Failover is significantly faster.
• Packet storms are avoided.
  

2. Mixed groups (e.g., Management on ETH1, sACN on ETH2)

Older behavior:

• Worked, but required careful switch configuration to avoid loops or blocked ports.

New behavior:

• RSTP is automatically disabled because the groups do not overlap.
  
• RSTP BPDU's (packets) are no longer bridged between ETH1 and ETH2
• Each port forwards normally in its own group.
• Switches do not block either interface.

3. ISL / Trunk use

Older behavior:

• Inconsistent depending on switch RLinkX settings.
• Could produce loops if RLinkX was off.

New behavior:

• If the trunk/ISL carries at least one overlapping group on both interfaces, RSTP is enabled.
• One port becomes forwarding; the other becomes alternate.
• Failover is fast and stable.

4. Misconfigurations that previously caused storms

Older behavior:

• Connecting both ports without switch loop protection or RLinkX could cause a broadcast storm.

New behavior:

• LumiNode participates in RSTP, preventing loops from forming.
• Packet storms are avoided even when switch loop protection is disabled.
  

Summary

The introduction of RSTP in LumiNode / LumiCore provides:

• stable redundancy when both network ports are used
• fast failover on link loss
• protection against loops and packet storms
• automatic enabling/disabling depending on VLAN/group configuration
• compatibility with switch‑based RSTP without requiring special configuration
• monitoring and control via API

This update ensures that redundant network cabling can be used safely and predictably in lighting networks involving LumiNode and LumiCore devices.