FortiLink over RADWIN 5000 PtMP - Multiple FortiSwitches go Offline while user traffic continues to work

Hello LuisTorresRojas, 

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible. 

Regards,

Regards,

Hello again Luis,

I found this answer to your issue, can you tell us if it helps, please?

You are experiencing an issue where multiple FortiSwitches connected via FortiLink over a Radwin 5000 PTMP (Point-to-Multipoint) Layer 2 wireless bridge go offline in FortiGate management, even though user traffic continues to flow normally. The problem only occurs when more than one remote site is powered on; with a single site, FortiLink management works as expected.

Key Questions Addressed

1. Is FortiLink officially supported over a Layer 2 PTMP wireless bridge such as Radwin 5000?

Official Support:
FortiLink is designed to operate over Layer 2 networks, and in principle, it can work over any transparent Layer 2 bridge, including wireless bridges. However, official support and reliability are best guaranteed on wired, low-latency, low-jitter links. Wireless PTMP bridges, especially those not specifically designed for enterprise switching, may introduce behaviors (e.g., MAC address learning limits, broadcast/multicast suppression, or non-standard handling of control frames) that can disrupt FortiLink management.

Documentation:
There is no explicit statement in Fortinet documentation confirming or denying support for FortiLink over PTMP wireless bridges. Such deployments are considered non-standard and may not be fully supported.

2. Does FortiLink have any limitations when multiple FortiSwitches are connected through the same transparent Layer 2 wireless bridge?

Potential Limitations:

• MAC Address Table Limitations: PTMP bridges may have limited MAC address table sizes or may not handle multiple MAC addresses per port efficiently, leading to MAC flapping or flooding.
• Broadcast/Multicast Handling: FortiLink relies on protocols like LLDP, STP, and CAPWAP (UDP/5246, 5247). If the bridge suppresses or mishandles these frames, management connectivity can break.
• Control Plane Sensitivity: FortiLink management is more sensitive to latency, jitter, and packet loss than user data traffic.

3. Could this behavior be related to LLDP, STP/BPDU forwarding, MAC learning, or MAC flapping within the PTMP bridge?

Yes, very likely.

• LLDP and BPDUs: If the Radwin bridge does not forward LLDP or BPDU frames correctly, FortiLink discovery and management can fail.
• MAC Flapping: In PTMP mode, the bridge may see the same MAC addresses (e.g., FortiGate or FortiSwitch management MACs) appearing on multiple subscriber units, causing the bridge to "flap" the MAC address between ports and disrupt management sessions.
• MAC Table Overflow: If the bridge's MAC table is exceeded, it may start flooding or dropping frames, affecting control plane traffic.

4. Are there any FortiGate or FortiSwitch settings that should be adjusted for this type of deployment?

Recommended Checks and Adjustments:

On FortiSwitch:

• LLDP Profile: Ensure the uplink port uses default-auto-isl LLDP profile.

  config switch physical-port
  edit <uplink-port>
  set lldp-profile default-auto-isl
  end
  

• NTP Sync: Ensure NTP is synchronized with FortiGate.
• Management VLAN: Confirm mgmt-vlan is set to 4094 (or as required).

On FortiGate:

• FortiLink Interface: Ensure the FortiLink interface is configured correctly and is not split or aggregated in a way that could confuse the bridge.
• STP Settings: Consider disabling STP on FortiSwitch uplinks if the wireless bridge does not forward BPDUs reliably.
• CAPWAP Keepalive: Increase CAPWAP keepalive timers to tolerate higher latency/jitter.

On Radwin Bridge:

• MAC Table Size: Check and increase MAC address table size if possible.
• BPDU/LLDP Forwarding: Ensure the bridge is configured to forward all Layer 2 frames, including BPDUs and LLDP.
• Multicast/Broadcast Handling: Disable any suppression or filtering of broadcast/multicast traffic.

Troubleshooting Recommendations

1. Monitor MAC Address Table on Radwin:
   Check if the same MAC addresses are flapping between SU-1 and SU-2 when both are online.

2. Packet Capture:
   Capture traffic on the FortiLink interface and on the Radwin bridge to see if LLDP, CAPWAP, and BPDU frames are being forwarded correctly.

3. Test with Static MAC Entries:
   If possible, configure static MAC entries on the Radwin bridge for the FortiGate and FortiSwitch management MACs to prevent flapping.

4. Check for Loops:
   Ensure there are no Layer 2 loops in the topology.

5. Firmware Updates:
   Ensure all devices (FortiGate, FortiSwitch, Radwin) are running the latest stable firmware.

6. Consult Radwin Documentation/Support:
   Ask Radwin if there are known issues or recommended settings for enterprise switch management protocols over PTMP.

Related Fortinet Documentation

• Replacing a managed FortiSwitch unit (MCLAG)
• Troubleshooting Tip: Fix FortiSwitch showing with the 'Offline' status
• Determining the network topology

Follow-up and Clarification Questions

To assist further, please clarify:

• What are the exact FortiGate, FortiSwitch, and Radwin firmware versions?
• Are there any logs or error messages on the FortiGate or FortiSwitch when the switches go offline?
• Can you provide output from the following commands when the issue occurs?
  • diagnose switch physical-port summary
  • diagnose switch trunk summary
  • execute switch-controller get-conn-status
• Is there any evidence of MAC flapping or flooding on the Radwin bridge?
• Are you using any VLAN trunking or tagging on the wireless bridge interfaces?

If you can provide these details, more targeted troubleshooting can be suggested.

Hi ​@LuisTorresRojas 

You have not mentioned the version being used. However, as of 7.6.1 LLDP is used for FortiSwitch discovery. In many cases, a third-party layer 2 device will not pass this traffic by default as LLDP packets are link-local. The solution would be to ensure that the third-party device can forward the LLDP packets. Alternatively, you could try setting the discovery method to FortiLink:

config system interface

edit "fortilink"

set fortilink-neighbor-detect {fortilink | lldp}

next

end

I hope that helps.

Regards