It has been a lonnnnng time since I have posted. That is my fault. Sometimes you need to relax. I relaxed, a LOT and got fat in the process. I am back now! and FortiOS 6.6 which is upcoming in the next few months will have LTS (long term support) with a renewed focus on security and stability. If that doesn’t make your worm wiggle I dunno what will.
The WebUI provides a Mesh Topology view to quickly assess the current mesh deployment. To access it, navigate to Configuration > Wireless > Mesh > [select mesh] > Mesh Topology.
Within the Mesh Topology tab, click the displayed mesh nodes to expand the tree and view connections between the various nodes.
Enterprise Mesh Troubleshooting
| Problem | Possible Cause & Solution |
| Wireless APs are not connecting to their designated parent AP. | Ensure that per-essid bridge is not enabled on wireless or gateway APs. |
| APs are picking up a configuration that I did not create | Your APs may have inherited an old configuration from a previously-used AP. Try resetting all APs to factory defaults with the CLI command reload ap id default (for one AP) or reload all default. Then, follow the setup directions in “Installing and Configuring an Enterprise Mesh System” on page 435. |
| APs are rebooting | A possibility could be bad channel conditions. Check the backhaul channel condition using a wireless sniffer. |
Enterprise Mesh Troubleshooting
Mesh APs now supports VLAN trunking.
Before you enable VLAN trunking on a mesh network, follow the recommendations listed below:
controller(15)# configure terminal controller(15)(config)# port‐profile vlantrunk controller(15)(config‐port‐profile)# enable controller(15)(config‐port‐profile)# vlantrunk enable controller(15)(config‐port‐profile)# multicast‐enable controller(15)(config‐port‐profile)# end controller(15)(config)# mesh vlantest controller(15)(config‐mesh)# admin‐mode enable controller(15)(config‐mesh)# psk key 12345678 controller(15)(config‐mesh)# meshvlantrunk enable controller(15)(config‐mesh)# end
Configuring VLAN in MESH
controller(15)# controller(15)# sh mesh‐profile
Name Description Admin Mode PlugNPlay Status VLAN Trunking St vlantrunk enable disable enable testvlan enable disable enable vlantest enable disable enable
Mesh Configuration(3) controller(15)# configure terminal controller(15)(config)# mesh‐profile vlantest controller(15)(config‐mesh)# mesh‐ap 65 controller(15)(config‐mesh‐mesh‐ap)# end controller(15)# controller(15)# sh port‐profile
Profile Name Enable/Disable VlanTrunk Dataplane Mode VLAN Name Security Profile Allow Multicast IPv6 Bridging
default enable enable bridged on off
vlantrunk enable enable bridged off off
Port Table(2)
An Enterprise Mesh uses APs (as repeaters) to extend the range of wireless coverage. An AP in a Enterprise Mesh configuration is directed to look for a signal from a Parent AP. As such, antenna placement and reception is important for the optimum performance of the system.
If there are obstacles in the radio path, the quality and strength of the radio signal are degraded. Calculating the maximum clearance from objects on a path is important and should affect the decision on antenna placement and height. It is especially critical for long-distance links, where the radio signal could easily be lost.
When planning the radio path for a wireless hop, consider these factors:
Enterprise Mesh APs are configured in five phases.
These steps assume that the deployment is not being configured via the PlugNPlay functionality. See “Adding Mesh APs Via PlugNPlay” on page 440 for additional details.
In a standard initial mesh setup, the user can configure all mesh APs desired at once via wired connection through a local switch. (This configuration is intended to happen prior to remote deployment.) For an alternative mechanism that allows APs to be deployed remotely prior to them being configured locally, refer to Adding Mesh APs Via PlugNPlay.
A single controller can manage multiple separate meshes as desired. Follow these steps to create a mesh profile.
Now that the mesh has been created, you can add your APs to it. Follow the instructions below.
The mesh APs must exist in the controller’s AP table (i.e., they must be added manually or have been connected to the controller as performed in previous steps) before they can be added to the mesh.
Figure 74: Modifying the Mesh
Repeat these steps for all desired APs. Once all APs have been added, they can be configured to utilize mesh operation.
Despite the fact that the APs have been added to a mesh profile, they still must be configured to utilize mesh operation. Follow the steps below.
Figure 75: Enabling Mesh Service
Repeat these steps for all APs that are part of the mesh. Verify that they are all displayed in the Mesh-AP member table, as shown in Figure 76. Figure 76: Mesh AP Member Table
Phase 5 consists of removing the cables, deploying the APs in their final locations, and turning them on. They will then be picked up by the controller as wireless APs.
To deploy the APs, follow these steps:
Once deployed, the APs will automatically determine the appropriate parent configurations to provide backhaul access. Provided the APs are in range with each other as per design, they should appear online automatically with no further settings. Your installation is complete.
As mentioned in “Phase 2: Create a Mesh Profile” on page 437, the PlugNPlay option allows mesh nodes to be connected to an existing mesh, without requiring them to be wired directly to the controller. This function is disabled by default.
With PlugNPlay enabled on an existing mesh, deploying a mesh-capable AP to its intended location allows the AP to automatically seek out a mesh within range and add itself to the controller. In effect, this means that a user can set up a mesh profile with only one AP configured for mesh service (by following the instructions earlier in this chapter) and then install additional mesh-capable APs to their intended locations. Once the new APs are powered up, they will link with the previously-configured mesh AP and add themselves to the controller’s AP database.
This does not mean that the new AP automatically assumes mesh operation. PlugNPlay operation allows it to add itself to the database directly, but it must still be added to the Mesh AP table on the controller and configured for mesh operation. PlugNPlay simply allows the AP to sync with the controller without requiring a physical connection.
Follow the steps below to install a new mesh AP using the PlugNPlay mechanism. Note that this scenario assumes that a mesh profile has already been created and has at least one active mesh AP added to it and configured via the steps detailed in “Phase 2: Create a Mesh Profile” on page 437 and “Phase 3: Add APs to the Mesh” on page 438 above.
Now that the AP is part of the mesh, you can enable mesh service on it by performing the following steps.
These steps can be repeated for as many new mesh nodes need to be configured. Once all the desired nodes have been added, it is recommended that PlugNPlay be disabled on the mesh until additional nodes are needed.
Enterprise Mesh is an optional wireless alternative for the Ethernet links connecting APs to controllers. Deploy the Enterprise Mesh system to replace a switched wired backbone with a completely wireless 802.11 backbone, while providing similar levels of throughput, QoS, and service fidelity.
The following are Enterprise Mesh features:
Mesh deployments are not intended for use in:
The following restrictions apply to the design and implementation of Fortinet mesh networks.
431
Enterprise Mesh is typically composed of hub-and-spoke configurations (as shown in Figure 72), chain configurations (as shown in Figure 73), or a variation of these.
In a dense network, hub-and-spoke (all APs point to the gateway) is the best topology, although collisions can occur.
Figure 72: Enterprise Mesh Network – Hub and Spoke Design
Figure 73: Three Hop Enterprise Mesh – Chain Design
A gateway AP is located at the wired edge of the Enterprise Mesh network, and provides the link between wired and wireless service. The gateway AP is the only AP that has a wired connection to the network.
Mesh APs refer to all APs that are not acting as gateway APs. They can provide intermediate service between other mesh APs or used as the endpoint in a mesh chain (as shown in Figure 73).Mesh APs can have wired connection to the network.
The unused Ethernet port on a Mesh AP can be configured and used in the same manner as a wired port on an Ethernet switch. As such, users can connect a hub/switch with other wired devices to it in order to access the corporate network. In order to use the port, a Port Profile must be configured for it. Refer to Configuring Port Profiles for details.
An AP that is connected to the controller via a wireless back haul connection but cannot provide wireless back haul service to other nodes.
Unused Ethernet port (interface 1) of an AP400, AP332, AP122, AP832, AP832, AP822 and FAP-U421EV, and FAP-U423EV configured as a Mesh AP can be used to connect up to 512 wired clients.
Any controller model can be used for a mesh deployment. The following AP models currently support mesh operation:
The following are the various discovery scenarios in a mesh network:
In a regular discovery process, a mesh AP uses the process as mentioned in the “CAPWAP and Legacy Reference” on page 335 .
Scenario 2: L2/L3 discovery failure.
In L2/L3 discovery failure, the AP switches to mesh discovery. In this mode, the AP searches (on 5G for AP122, 822, FAP-U4xx, OAP832 and for other supported APs, on 5G and then followed by 2.4G) for a mesh beacon (a hidden ESS-Id). When it finds this hidden ESS-Id, it creates an association. After the association is complete, the AP starts the DHCP process to get an IP address from the controller. However, this AP (mesh AP) must be in the same mesh cloud in order to establish a connection.
NOTE: Backhaul links are always encrypted.
Refer to the online help for more information on creating mesh cloud
If the AP is unable to find a suitable backhaul service or if key exchange fails, the AP scans to wireless medium for recovery service.
When a recovery service is found, the AP completes key exchange and 4-way handshake to discover the controller. After the discovery is complete, the configuration is downloaded. However, this AP does not provide any WLAN services.
To enable WLAN services, this AP must be added to a mesh cloud.
NOTE: A mesh AP can be part of only one cloud at a time.
In a mesh cloud, if a mesh AP or a leaf AP loses contact with its parent, the AP switches to discovery mode. The discovery process begins with scenario 1-regular AP discovery process..
In a mesh cloud, an AP selects its best parent AP using a match to the following parameters and values.
The above are default values and they can be customized to your RF environment using the following AP-CLI commands: mesh {parent_selection | psel}
Set/Get weights for parent selection parameters
To set:
mesh parent_selection [snr|child|hop] <integer>
To get:
mesh parent_selection
To reset:
mesh parent_selection reset
You can apply Differentiated Services Code Point (DSCP) values to management and application traffic (see Application Visibility Enhancements section). DSCP value is a selectable field that can be used to assign various levels of precedence to network traffic.
By default, traffic packets contained an EF value and with the introduction of this feature you can change the priority bit from EF to an appropriate DSCP value that meets your requirements.
Management traffic between the following can be assigned DSCP values:
DSCP Marking for Management Packets
To configure DSCP from WebUI, go to Configuration > Policies > QoS Settings > Marking Management Packets (tab).
Select the DSCP values for each traffic and click the SAVE button.
DSCP Marking for Management Packets
You can configure load balancing to effectively distribute wireless clients to alternate access points. The load balancing is performed by the controller based on two factors; Current Load of the AP and RSSI value of the client.
When a new client joins the network, the controller will connect the client to an AP that is running below its maximum load threshold and providing the best RSSI value.
To enable load balancing, configure the Load Threshold for the access point. Go to Configuration > Wireless > Load Balance.
| 20 MHz | 40 MHz | 80 MHz | 160 Mhz / 80+80 Mhz | |
| 802.11b | -76 dbm | NA | NA | NA |
| 802.11a/g | -65 dbm | NA | NA | NA |
Load Balancing for APs in Virtual Cell
| 20 MHz | 40 MHz | 80 MHz | 160 Mhz / 80+80 Mhz | |
| 802.11n | -64 dbm | -61 dbm | -58 dbm | NA |
| 802.11ac | -57 dbm | -54 dbm | -51 dbm | -48 dbm |
nPlus1 Support: The load balance feature allows the clients to connect to the best available access point during roaming in an nplus1 set up.
The following table illustrates various load balancing scenarios between two APs (AP1 and AP2) and the expected result when a client tries to join the network. :
| Scenario | Expected Result |
| L1=1, L2=0 and R1=0 and R2=0 | Since AP1 is running in full capacity the client will be assigned to AP2. |
| • L1=0, L2=0 and R1=0 ,R2=0
• L1=0 , L2=0 and R1=-1, R1=-1 • L1=1, L2=1 and R1=1 and R2=1 |
In these scenarios, the controller will use default association mechanism to assign the client to AP. |
| • L1=0, L2=1 and R1=1, R2=0 • L1=1, L2=0 and R1=1, R2=0 • L1=1, L2=0 and R1=1, R2=1
• L1=1, L2=1 and R1=1, R2=0 |
In these scenarios, the client will be assigned to AP2. |
| For other cases where L1 or L2 =1 | The client stay associated with the current AP i.e. AP1 |
How to debug the packet flow
Traffic should come in and leave the FortiGate unit. If you have determined that network traffic is not entering and leaving the FortiGate unit as expected, debug the packet flow.
Debugging can only be performed using CLI commands. Debugging the packet flow requires a number of debug commands to be entered as each one configures part of the debug action, with the final command starting the debug.
If your FortiGate unit has FortiASIC NP4 interface pairs that are offloading traffic, this will change the packet flow. Before performing the debug on any NP4 interfaces, you should disable offloading on those interfaces.
The following configuration assumes that PC1 is connected to the internal interface of the FortiGate unit and has an IP address of 10.11.101.200. PC1 is the host name of the computer.
To debug the packet flow in the CLI, enter the following commands:
FGT# diag debug disable
FGT# diag debug flow filter add <PC1> FGT# diag debug flow show console enable
FGT# diag debug flow show function-name enable
FGT# diag debug flow trace start 100
FGT# diag debug enable
The start 100 argument in the above list of commands will limit the output to 100 packets from the flow. This is useful for looking at the flow without flooding your log or displaying too much information.
To stop all other debug activities, enter the command:
FGT# diag debug flow trace stop
The following is an example of debug flow output for traffic that has no matching security policy, and is in turn blocked by the FortiGate unit. The denied message indicates that the traffic was blocked.
id=20085 trace_id=319 func=resolve_ip_tuple_fast line=2825 msg=”vd-root received a packet (proto=6, 192.168.129.136:2854->192.168.96.153:1863) from port3.”
id=20085 trace_id=319 func=resolve_ip_tuple line=2924 msg=”allocate a new session-013004ac”
id=20085 trace_id=319 func=vf_ip4_route_input line=1597 msg=”find a route: gw-192.168.150.129 via port1″
id=20085 trace_id=319 func=fw_forward_handler line=248 msg=” Denied by forward policy check”