Guest VLAN Black Hole After FortiLink ISL Rebuild
A FortiGate 201F running FortiOS 7.6 manages a FortiLink aggregate (ports A and B) to two FortiSwitch 448D units. The switches are joined by a 2-port 10G managed ISL. VLANs 10 (corporate), 20 (voice), and 200 (guest) exist on the FortiGate fortilink interface. Corporate and voice clients work on both switches. A guest SSID is bridged locally on FortiAP 231F units, mapped to VLAN 200. Guests on APs connected to switch 1 obtain DHCP and reach the internet. Guests on APs connected to switch 2 get no DHCP lease and an APIPA address. The AP management VLAN is 10 and APs are online. A recent change replaced the ISL and re-authorized switch 2; the guest SSID VLAN was changed from 20 to 200 earlier the same day. Switch 2 port uplinks to APs show native VLAN 10 and allowed VLANs 10,20. The ISL shows allowed VLANs 10,20,200 on only one side.
1. Which observations make a Layer 2 VLAN path failure more likely than a DHCP or firewall fault, and what are your first three checks?
Read the worked answer
The failure follows the physical switch, not the SSID or user group: the same guest SSID, FortiGate, and DHCP scope work on switch 1 and fail on switch 2. The APs are online on management VLAN 10, so PoE, AP registration, and the AP-to-switch link are fundamentally healthy. A firewall fault or scope exhaustion would normally affect both switches. The strongest clue is that the AP-facing ports allow only VLANs 10 and 20 while the bridged guest SSID tags VLAN 200. Tagged guest frames arriving at switch 2 are dropped at ingress before DHCP can work.
First checks: (1) On switch 2, confirm the AP-facing ports have native VLAN 10 and allowed VLANs that include 200, not just 10 and 20. (2) Compare the ISL allowed VLAN list on both ends; an asymmetric list creates one-way forwarding and should be corrected. (3) Confirm the FortiGate fortilink interface actually has VLAN 200 and that the switch-controller port configuration matches the intended trunk. A packet capture on the FortiGate fortilink for VLAN 200 tagged frames will show whether any guest traffic from switch 2 arrives. Do not start with DHCP or firewall changes; the evidence points below Layer 3.
2. State the configuration intent for the AP-facing ports, the ISL, and the FortiGate fortilink VLAN, and explain why the AP management VLAN should stay native or untagged.
Read the worked answer
The AP-facing ports should be trunk ports. Native VLAN 10 carries the AP management IP untagged; allowed VLANs should include 10, 20, and 200 so the locally bridged guest SSID can carry 802.1Q-tagged VLAN 200 frames. The ISL must allow the same VLANs on both ends. If one side filters VLAN 200, guest traffic from switch 2 cannot reach the FortiGate, and return traffic may create confusing partial connectivity. On the FortiGate, VLAN 200 must exist on the fortilink interface with the correct DHCP scope and firewall policy.
Keep AP management native or untagged because the FortiAP management interface normally sends untagged frames and relies on the switch port PVID. If you change the native VLAN to 200 without changing the AP management VLAN, the AP loses management connectivity. The guest SSID VLAN is a tagged data VLAN, not the AP management VLAN. Verify with the switch VLAN and interface tables, then renew a guest DHCP lease. If the switch-controller pushes configuration, fix the FortiGate port profile rather than making a local-only change that will be overwritten.
3. How would you prevent the same VLAN mismatch when the guest VLAN changes again?
Read the worked answer
Treat the FortiLink VLAN database and switch-port allowed lists as one controlled object. Pre-provision the new VLAN on the FortiGate fortilink interface and on every managed switch and ISL before changing the SSID mapping. Use FortiGate switch-controller port profiles or VLAN templates so AP-facing trunks and ISLs are generated consistently, rather than edited switch by switch. Add a change checklist: create VLAN, add DHCP and firewall policy, allow VLAN on all ISLs and AP trunks, change SSID mapping, then test from an AP on each switch. Monitor FortiGate switch-controller logs and interface statistics for drops. A simple validation script or GUI audit that compares allowed VLANs on both ISL ends would have caught the one-sided ISL configuration. Avoid local VLAN changes on managed switches unless they are intentional and documented, because the controller can overwrite them or create drift.