FortiWLC – Option 43

Leave a reply

Option 43

Option 43 is not part of any Fortinet product; it is a method for mapping controllers. With DHCP Option 43, you can specify a primary and backup controller for APs. With this configuration, the backup controller can be in a different subnet from the primary controller. Option 43 implements redundancy by specifying which controllers (primary and secondary) an AP should associate to. This feature is supported across all access points. A backup controller can be configured using either DHCP or DNS.

Option 43

For example, using Option 43, if “wlan-controller” is mapped to P1 (and P1 has a redirect to P2) and “wlan-controller-2” is mapped to S1 (and S1 has a redirect to S2), the discovery order would be P1, P2, S1, S2. If a controller has both a DNS entry and Option 43 enabled, the AP will first use the host address as configured on the AP (default value = wlan-controller). If the host address is configured as 0.0.0.0 or if the host is a name and the name cannot be resolved using DNS, only then will the AP look at the DHCP Option 43 value. For specific Option 43 configuration directions, see the Support Portal How-To 4062-125.

AP Aware Redundancy using DHCP Option 43
  • Configure APs with L3 preferred and the controller name as 0.0.0.0
  • On the DHCP server, Option 43 values need to be configured with primary and secondary controller IPs and/or hostnames. Then, when an AP contacts the DHCP server to obtain an IP address, it also receives primary and secondary controller IP information using the Option 43 value from the DHCP server.
AP Aware Redundancy using DNS
  • Configure APs with L3 preferred and the controller name as the hostname of the controller.
  • Configure a DNS entry to resolve the primary hostname on the DNS server. Configure a DNS entry to resolve the secondary hostname on the DNS server.
  • Configure the hostname of the primary controller on the AP with L3 preferred mode.

FortiWLC – N+1 Redundancy

Leave a reply

N+1 Redundancy

The optional N+1 redundancy software feature, when implemented, allows a standby N+1 slave controller in the same subnet to monitor and seamlessly failover more than one master controller.

A set of master controllers and a standby slave controller are configured via static IP addressing to reside in the same subnet, and are considered to be an N+1 cluster. The standby slave monitors the availability of the master controllers in the cluster by receiving advertisement messages sent by the masters over a well known UDP port at expected intervals. If four successive advertisements are not received, the standby slave changes state to an active slave, assumes the IP address of the failed master, and takes over operations for the failed master. Because the standby slave already has a copy of the master’s latest saved configuration, all configured services continue with a short pause while the slave switches from standby to active state.

N+1 Fallback

While in the active slave role, the slave controller’s cluster monitoring activities are put on hold until the failed master rejoins the cluster. An active Slave detects the restart of a master through ARP. When the active slave is aware of the master’s return (via the advertisement message) it will continue to remain as active slave and the original master moves to passive state. The now passive master is assigned with original slave’s IP address. To move passive master to active master status, use the nplus1 revert command in active slave.

NP‐MC4200‐master(15)(config)# nplus1 revert

NP‐MC4200‐master(15)(config)# end

NP‐MC4200‐master(15)# sh nplus1

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

            Current State : Active‐>Passive Slave

         Heartbeat Period : 1000 milliseconds

      Heartbeat Threshold : 4 threshold

                Master IP : 172.19.215.31

          Master Hostname : NP‐MC4200‐master                  Slave IP : 172.19.215.32

           Slave Hostname : NP1‐MC4200‐slave              License Type : Demo

License Usage (Used/Tot) : 1/1

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

             Master Controllers

            Hostname       IP Address  Admin    Status

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

    NP‐MC4200‐master    172.19.215.31  Enable   Passive‐>Active

If it is necessary for the failed master to be off-line for a lengthy interval, the administrator can manually set the active slave back to the standby slave, thereby ensuring the standby slave is able to failover for another master.

Auto Fallback

After a failover, the passive master listens to advertisements (at time intervals specified using the nplus1 period command) from active slave. If the passive master does not receive advertisements from active slave within the time period the passive master initiates auto-fallback.

Auto Revert

When the master controller goes down, the slave controller takes over as active slave controller. When the master controller that was down became active, it continues to stay as passive controller till the nplus1 revert command is executed on the active slave controller. You can enable auto revert so that after the master controller come online, it takes over as the original master controller.

By default this option is disabled. To enable auto-revert, use the nplus1 autorevert enable command. By enabling auto revert; the active slave controller triggers a fallback by itself.

Failover Scenarios
Scenario Description
Power outage Failover is initiated on power outage on the master controller.
Switch Port Failure Failover is initiated during a port failure in the switch.
Ethernet cable unplugged If the Ethernet cable in the master controller is unplugged, the slave controller takes over and becomes active slave.
Manual Failover You can execute the nplus1 takeover command in the master controller to force a failover.
np1adv process kill Failover is initiated if the np1 process in the master is killed.
Auto Failover Auto failover is initiated if heartbeats from a controller is not received within the time specified in the nplus1 period command.
Failover on “no reload” no reload commands trigger a failover. In such scenario, the master must be manually enabled. Reload commands sends a notification to slave about force enabling master and hence the master status becomes disable on the slave.

In most cases with a cluster of N+1 Masters, the APs all have to be in L3 Connectivity mode, but if you only have one Master and one Slave unit (N=1) the APs can be in L3 only connectivity mode. However, if the APs are in L2 mode, then they will move to reboot after failover.

Heartbeat Period and Heartbeat Timeout Recommendations

Various factors in your network environment including latency can impact the N+1 failover. In networks with high latency, missing heartbeats between master and slave controller can trigger N+1 failover. We recommend that if your network experiences high latency, you should set the heartbeat period and heartbeat timeout to higher values.

The default heartbeat period is 1000ms and heartbeat timeout is 4 timeouts. Use the following commands to set high values:

# nplus1 timeout 40 # nplus1 period 100

The failure detection time (to initiate failover) is calculated as Heartbeat Period x Heartbeat Timeout.

Default timeout and period:

  • Heartbeat Period (HP): Default 1000 ms, Range 100 – 30,000 (ms)
  • Heartbeat Timeout (HT): The lost heartbeat threshold is the number of consecutive heartbeat packets. Default 4 timeouts, Range 4 – 60 (timeouts)
  • Actual Failure Detection Time (AFDT) = HP (1000 ms) x HT (4) = 4000 ms = 4 Seconds
Preparing the Network

The N+1 cluster must be configured within a set of guidelines to operate as described in the previous section. While configuring your network for N+1 redundancy, the following guidelines must be followed:

  • The following table lists the supported pairing (master and slave) of controller models in an N+1 cluster, with the MC series as the master.
Slave     Master      
MC1550 MC1550VE MC3200 MC3200VE MC4200 MC4200VE MC6000
MC1550 ✓ x X x x x x
MC3200 x x ✓ x x x x
MC4200 x x X x ✓ x x
MC6000 x x X x x x ✓
MC1550-VE ✓ ✓ X x x x x
MC3200-VE ✓ ✓ ✓ ✓ x x x
MC4200-VE ✓ ✓ ✓ ✓ ✓ ✓ x
FWC-50D x x X x x x x
FWC-VM-50 x x X x x x x
FWC-200D x x ✓ x x x x
FWC-VM-200 x x X x x x x
FWC-500D x x X x ✓ x x
FWC-VM-500 x x X x x x x
FWC-1000D x x X x x x x
FWC-VM1000 x x X x x x x
FWC-3000D x x X x x x x
FWC-VM3000 x x x x x x x
  • The following table lists the supported pairing (master and slave) of controller models in an N+1 cluster, with the FWC series as the master.
Slave     Master        
FWC50D FWC-

VM-

50

 FWC200D FWC-

VM-

200

 FWC500D FWC-

VM-

500

 FWC-

1000

D

 FWC-

VM1000

 FWC-

3000

D

 FWC-

VM3000
MC1550 x x x x x x x X x X
MC3200 x x ✓ x x x x x x x
MC4200 x x x x ✓ x x x x x
MC6000 x x x x x x x x x x
MC1550-VE x x x x x x x x x x
MC3200-VE ✓ x ✓ x x x x x x x
MC4200-VE ✓ x ✓ x ✓ x x x x x
FWC-50D ✓ x x X x x x x x x
FWC-VM-50 x ✓ x X x x x x x x
FWC-200D x x ✓ X x x x x x x
FWC-VM200 x x x ✓ x x x x x x
FWC-500D x x x X ✓ x x x x x
FWC-VM500 x x x X x ✓ x x x x
FWC-1000D x x x X x x ✓ x x x
FWC-VM1000 x x x X x x x ✓ x x
FWC-3000D x x x X x x x x ✓ x
FWC-VM3000 x x x X x x x x x ✓
  • All master and slave controllers must use static IP addressing to ensure consistency and control of N+1 clustering. (DHCP addresses are not supported for controllers participating in the N+1 cluster).
  • Master and slave controllers must be on the same IP subnet.
  • All APs in the network should be configured for Layer 3 connectivity with the controller.
  • Spanning tree should be disabled on the switch port to which the controllers are connected. To disable spanning tree on the port, refer to your switch configuration documentation.
  • Set same date and time on the master and slave controller. Mismatch in date and time between master and slave will result in incorrect AP uptime information after a failover. You can also configure NTP on the master to avoid incorrect AP uptime information.

Configuring the N+1 Clusters shows a simplified network diagram of a recommended N+1 deployment.

Figure 37: Example N+1 Redundancy Network Deployment

Configuring the N+1 Clusters

This can only be configured using the CLI and up to five masters and one slave. You will need passwords for all controllers involved in the N+1 configuration. A summary of the steps to configure and start N+1 follows:

Step Command Description
1. nplus1 start master On each master, start N+1 redundancy.
2. nplus1 start slave Start N+1on the slave controller.
3. nplus1 add master_hostname master_IP_address Add the master controller’s hostname and IP address to the slave’s cluster list.
Starting N+1 on Master Controllers

N+1 must first be started on the Master Controllers.

To configure a master controller:

  1. On each master controller, enter configuration mode and start the N+1 software:

NP‐MC4200‐master(15)# configure terminal

NP‐MC4200‐master(15)(config)# nplus1 start master

  1. Exit configuration mode and check that the N+1 software has been started on that controller:

NP‐MC4200‐master(15)(config)# exit

NP‐MC4200‐master(15)# sh nplus1

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐Master controller

Master IP : 172.19.215.31

Master Hostname : NP‐MC4200‐master

Master Status : Active

Slave IP : 172.19.215.32 <– This is not displayed if Slave is not started

Slave Status : Passive <– This is displayed as Unknown if slave is not started

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

Configuring N+1 on the Slave Controller

After starting N+1 on each of the Master Controllers, start N+1 on the Slave Controller, and then add each Master Controller to the Slave Controller.

The Slave Controller must be the last controller in the cluster to start N+1. All Master Controllers must be added to the cluster before starting N+1 on the Slave Controller.

To configure N+1 on the slave controller, follow these steps:

  1. Enter configuration mode and start the N+1 software:

NP1‐MC4200‐slave(15)# configure terminal

NP1‐MC4200‐slave(15)(config)# nplus1 start slave

Setting up this controller as a Passive Slave controller

  1. Check that the software has started on the slave with the show nplus1 command (note that no masters display in the Master Controllers list):

NP1‐MC4200‐slave(15)(config)# show nplus1

Current State : Passive

Heartbeat Period : 1000 milliseconds

Heartbeat Threshold : 4 threshold Slave IP : 172.19.215.32

Slave Hostname : NP1‐MC4200‐slave

License Type : Demo

License Usage (Used/Tot) : 0/1

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐        Master Controllers

                                                                                        

Hostname  IP Address  Admin Status Switch  Reason Missed Adverts SW Version ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

  1. Supply the hostname and IP address of each master controller in the cluster. You will be prompted for the controller’s password to complete the addition:

NP1‐MC4200‐slave(15)# configure terminal

NP1‐MC4200‐slave(15)(config)# nplus1 add NP‐MC4200‐master  172.19.215.31 admin@172.19.215.31 Password:

  1. Exit configuration mode and check that the master controller has been enabled (the Admin status is now Enable):

NP1‐MC4200‐slave(15)#sh nplus1

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

            Current State : Passive

         Heartbeat Period : 1000 milliseconds

      Heartbeat Threshold : 4 threshold

                 Slave IP : 172.19.215.32

           Slave Hostname : NP1‐MC4200‐slave

             License Type : Demo

 License Usage (Used/Tot) : 1/1

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐                       Master Controllers

                                                                                          Hostname   IP Address  Admin  Status Switch  Reason  MissedAdverts  SW Version

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

NP‐MC4200‐master 172.19.215.31  Enable  Active  Yes     ‐    0        6.1‐2‐15

Monitoring the N+1 Installation

The show nplus1 command allows you to check the current controller configuration and show the status of the controller. Some sample output displays are included to show the information displayed in the various controller states.

  • N+1 on master—displays both basic master and slave controller identification information

NP‐MC4200‐master(15)# sh nplus1

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐Master controller

Master IP : 172.19.215.31

Master Hostname : NP‐MC4200‐master

Master Status : Active

Slave IP : 172.19.215.32

Slave Status : Passive

  • N+1 on a standby slave—basic slave controller identification information plus the status for the master control-lers in the cluster (accompanying table describes status fields)

NP1‐MC4200‐slave(15)#sh nplus1

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

            Current State : Passive

         Heartbeat Period : 1000 milliseconds

      Heartbeat Threshold : 4 threshold

                 Slave IP : 172.19.215.32

           Slave Hostname : NP1‐MC4200‐slave

             License Type : Demo

 License Usage (Used/Tot) : 1/1

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐                       Master Controllers

                                                                                          Hostname   IP Address  Admin  Status Switch  Reason  MissedAdverts  SW Version

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

NP‐MC4200‐master 172.19.215.31  Enable  Active  Yes     ‐    0        6.1‐2‐15 The descriptions of the display fields are provided in the following table:

Field Description
Hostname Hostname of the master controller
IP Address Static IP address assigned to the master controller
Admin Status of N+1 redundancy on the master:

•  Enable—N+1 redundancy has been enabled on the master

•  Disable—N+1 redundancy has been disabled
Switch Ability of the slave to assume active slave for the master:

•  Yes—Slave and master model/FortiWLC (SD) version number are compatible

•  No—Slave and master model/sFortiWLC (SD) version number are incompatible or the administrator has disabled N+1 on the master
Field Description
Reason If Switch is No, describes why switch cannot be made:

•  Down: Master has been disabled by the user

•  SW Mismatch: The FortiWLC (SD) software is out of sync (update the Master Controller).

•  No Access: The Passive Slave was not able to access the Master because it did not receive a copy of the configuration. This is a rare message that occurs if show nplus1 is executed almost immediately after adding a controller.
Missed Adverts Number of consecutively missed (not received) advertisements (a maximum of 4 triggers a failover if the Switch field is Yes).
SW Version The software version of FortiWLC (SD) on the controller.
  • N+1 on an active slave—the master IP address, hostname, and status are added to the display. Passive status indicates the original master is UP, Down status indicates the original master is not reachable.

NP‐MC4200‐master(15)# sh nplus1

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

            Current State : Active Slave

         Heartbeat Period : 1000 milliseconds

      Heartbeat Threshold : 4 threshold

                Master IP : 172.19.215.31

          Master Hostname : NP‐MC4200‐master                  Slave IP : 172.19.215.32

           Slave Hostname : NP1‐MC4200‐slave

             License Type : Demo

 License Usage (Used/Tot) : 1/1

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

              Master Controllers

            Hostname       IP Address  Admin    Status

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

    NP‐MC4200‐master    172.19.215.31  Enable   Passive  

Managing the N+1 Installation

The tasks to manage an N+1 installation include:

  • Syncing Running Configuration
  • Disabling and Deleting N+1 Master Controllers
  • Stopping N+1 Installations
  • Replacing a Master Controller
  • Working with N+1 Syslog

Syncing Running Configuration

Running configuration between master and slave are automatically synced every 30 minute.

Disabling and Deleting N+1 Master Controllers

To disable N+1 operation on a master controller, but still maintain its configuration in the cluster, from the slave controller, use the nplus1 disable command, with the IP address of the controller you are deleting:

NP1‐MC4200‐slave# configure terminal

NP1‐MC4200‐slave(config)# nplus1 disable 10.1.1.10 NP1‐MC4200‐slave(config)# end

To remove an N+1 master controller from the cluster, from the slave controller, use the nplus1 delete command, with the IP address of the controller you are deleting:

NP1‐MC4200‐slave# configure terminal

NP1‐MC4200‐slave(config)# nplus1 delete 10.1.1.10

NP1‐MC4200‐slave(config)# end

Stopping N+1 Installations

N+1 Slave and N+1 Master Controllers must be stopped separately.

Stopping N+1 Slave Controllers

To stop N+1 on a Slave Controller:

NP1‐MC4200‐slave# configure terminal

NP1‐MC4200‐slave(config)# nplus1 stop

Making this a normal controller.

NP1‐MC4200‐slave(config)# exit NP1‐MC4200‐slave#

Stopping N+1 Master Controllers To stop N+1 on a Master Controller:

3000‐1# configure terminal

3000‐1(config)# nplus1 stop

3000‐1(config)# exit

The following commands cannot be executed in an active slave controller and if executed on an active master, these commands will not trigger failover.

  • poweroff controller
  • reload
  • reload default
  • reload default factory
Replacing a Master Controller

To replace a a new master controller, do the following:

  1. Power off the original master controller. The slave controller becomes the active controller.
  2. Replace the new controller. Ensure that the new controller contains the same configuration for bonding, interface mode, and IP address(es) as the original master controller.
  3. Run “nplus1 start master” command on the new controller in order to make this new controller the master controller.
  4. Run “nplus1 slave <slave’s IP address>” command on the the new master controller in order to detect slave controller. The new master controller takes passive role.
  5. Run “nplus1 access <slave’s IP address>” command on active slave controller in order to generate authorized key on the new passive master controller.
  6. Then, copy the latest running configuration to the new passive master controller after executing the “nplus1 revert” command on the active slave controller

The the new active master controller automatically runs with the latest running configuration.

Working with N+1 Syslog

The show nplus1 debugloglevel command shows the level of verboseness set for the N+1 log messages.

NP1‐MC4200‐slave# sh nplus1 debugloglevel nplus1 Debug Logging Level: 0 NP1‐MC4200‐slave#

Setting the syslog Debug Level

The nplus1set debugloglevel command sets the level of verboseness for the N+1 log messages. The level can be set from 0 to 3, where 1 is the least verbose. The default 0 setting disables syslog messaging.

NP1‐MC4200‐slave(config)# nplus1 setdebugloglevel 1

N+1 Syslog Messages

Syslog messages are generated and sent to a log file on the syslog server configured with the syslog-host command. These message are sent by a standalone N+1 slave controller when an error condition occurs. A sample syslog message follows:

Oct 26 14:02:45 slave nplus1_Slave: <error message> The list of syslog messages are as follows:

Error Message Description/Remedy
IP address not assigned. Please run setup before using nplus1 The command nplus1 start slave executed, but no IP address exists for the controller. Run the setup command on that controller and assign the controller a static IP address.
ERROR: Could not get software version from file: meru_sw_version_file Couldn’t determine the FortiWLC (SD) software version.
Rejecting record number due to parsing issues Error reading the persistent record of configured masters. Manually add the Master Controllers again.
Could not open socket for CLI server Problem initializing the N+1 CLI.
CLI server: Bind error for server ip: ip port: port Issues in initializing N+1 CLI.
ALERT: Software Mismatch: Master (master_ip): software_version Slave (slave_ip): software_version The Master Controller advertisement revealed a software mismatch. While the version mismatch occurs, the Master Controller cannot provide redundancy. Install on the Master Controller the same software version as the Slave Controller (or vice versa).
Copyback failed for master controller: master_ip Configuration of Master Controller changed while the Slave was active, and the copyback failed. Remove the new Master Controller configuration changes, failback the Master Controller, and then perform the needed configuration changes.

 

For MC: master_ip State:  SW

Mismatch ->  No Access – Saved Config does not exist

 Software mismatch was resolved, but the Master Controller is not accessible from the Slave Controller and cannot provide redundancy. Ensure that the Master Controller is accessible using the command nplus1 access master_ip.
Could not access host: master_ip. Setting No Access Count to: count Could not access the Master Controller. The Master Controller cannot provide redundancy until it is accessible. Access will be rechecked after count (default is 60 seconds). The problem may be caused by a gateway failure. Ensure that the Master Controller is accessible, and verify by using the command nplus1 access master_ip.
Upgrading

Controllers in a N+1 network can be upgraded like any controller in a standalone deployment. However, only active master and standby slave controllers can be upgraded. Controllers in failover mode cannot be upgraded.

Recovering From N+1 Failover

When an N+1 master controller goes down, the slave controller transitions from passive slave to active slave (failover) and starts acting as the master controller. When the original master comes back up, the active slave continues to be active slave and the original master becomes passive master. The APs (if in L2 mode) will now reboot.

Recovering From N+1 with Dual Ethernet Failover

On the Master controller, when the first Ethernet interface goes down, the controller fails over to second interface of the same controller. If the second interface goes down, Nplus1 failover takes place and the N+1 passive slave becomes an active slave with Dual Ethernet redundant configuration.

The active slave is now in control. If the first active slave Ethernet interface goes down, the slave controller fails over to the second Ethernet interface.

To revert the failover, verify that the first interface on the Slave controller is up and running. Then, bring up the first interface of the original Master controller. The N+1 active slave continues to be active slave and the original N+1 master becomes passive.

FortiWLC – Redundant Ethernet

Leave a reply

Redundant Ethernet

When operating an MC1500, Ethernet redundancy can be enabled at any time by simply following the steps outlined in the following sections. However, for the following controller models enable dual port bonding before activating Ethernet redundancy:

  • MC3200
  • MC4200
  • MC5000 (with accelerator card)
  • MC6000

To enable dual bonding, enter the following commands and reboot the controller:

Redundant Ethernet

default# configure terminal default(config)# bonding dual default(config)# exit default# copy running‐config startup‐config

Configure Redundant Ethernet Failover With the CLI

The following commands configure Ethernet interface 2 on a controller as a backup to Ethernet interface 1:

default# configure terminal default(config)# interface FastEthernet 2 default(config‐if‐FastEth)# type redundant default(config‐if‐FastEth)# exit default(config)# exit

default# copy running‐config startup‐config

In the redundant configuration, the IP address for the second Ethernet interface cannot be configured. It will receive the IP address of the primary Ethernet interface when the failover occurs.

The system requires a reboot for the change to become effective. Reboot the system now, and then check the redundant second interface configuration with the show second_interface_status command: default# show second_interface_status

Recovering From Redundant Ethernet Failover

Once Dual Ethernet Redundant mode configuration is complete, the controller needs to be rebooted – see directions above. After the reboot, if the first Ethernet interface link goes down, then the second Ethernet interface takes over the controller connectivity. Redundant Ethernet failover is based on LinkID and does not require any spanning-tree configuration. When a LinkID is missing, the failover will occur in under one second. This failover will be transparent to the access points. The second interface remains active and serving all APs, even if the first interface comes up again. Verify this with the CLI command show second-interface-status. Only when the second interface goes down will the first interface (if it is up) take over the controller connectivity.

In hardware controllers bringing the switch port down will be detected as interface down and a link down alarm will be generated, rather in a virtual controller bringing the switch port down will not be detected as interface down and hence no link down alarm will be generated.

An alarm will be generated when the mapped interface in the VMWare client software is configured as disconnected.

When N+1 or L3 redundancy is also configured and controller 1 fails, the APs move to controller 2. When controller 1 comes back online, the APs immediately begin to move back to controller 2. Also see Recovering From N+1 with Dual Ethernet Failover.

Redundant Ethernet

 

FortiWLC – Time Based ESS

Leave a reply
Time Based ESS

You can schedule the availability of an ESS based on pre-define time intervals. By default, ESS profiles are always ON and available to clients/devices. By adding a timer, you can control the availability of an ESS profile based on pre-defined times during a day or across multiple days.

To create a time based ESS profile, you must first create a timer profile and then associate the timer profile to the ESS profile.

Creating a Timer Profile

You can create timer profile using WebUI or CLI.

Time Based ESS

Using WebUI

Go to Configuration > Timer and click the Add button.

In the Add Timer Profile pop up window, enter Timer Profile Name and select Timer Type:

  • Absolute timer profiles can enable and disable ESS visibility for time durations across multiple days. You can create up to 3 specific start and end time per timer profile. To enter start of the end time, click the Date picker box. See label 1 in figure 1.
  • Periodic timer profiles are a set of start and end timestamp that can be applied across multiple days of a week. To create a period timer profile, enter the time in hh:mm format. Where hh, represent hours in 2-digits and mm represent minutes in 2-digits. Figure 2, illustrates a timer profile that will be applied on Sunday, Monday, Tuesday, and Thursday from 08:10 a.m. or 14:45 (2.45 p.m).

Time Based ESS

Using CLI

A new CLI command timer-profile with various options is available to create a timer profile.

Syntax

#(config‐mode) timer‐profile <profile‐name>

#(timer‐config‐mode) <timer‐type> <timer‐slot> start‐time <“mm/dd/yyyy hh:mm”> end‐time <“mm/dd/yyyy hh:mm”>

  • timer‐type is either absolute‐timer or periodic timer
  • Absolute timer profile allows creation of 3 timer slots.
  • Time must be specified within double quotes in this format: mm/dd/yyyy <space> hh:mm

Example: Creating an absolute timer profile default# configure terminal default (config)# timer‐profile monthly‐access

default (config‐timer)# absolute‐timer time‐slot‐1 start‐time “01/01/2014 10:10” end‐time “02/02/2014 08:45”

 

FortiWLC – Utilizing Multiple IPs on a Single MAC

Leave a reply
Utilizing Multiple IPs on a Single MAC

In current implementations, a typical client machine (or station) is granted a single IP Address per wireless adapter in use. However, with the growing use of Virtual Machine models (provided by VMware, Parallels, etc.), a single station can run multiple Operating Systems from a single client. With this release of Fortinet FortiWLC (SD), each Virtual Machine can now be provided with an individual IP Address, making it much easier to troubleshoot packet transmissions.

To support this function, the FortiWLC (SD) ESS Profile screen has a new function labeled MIPS, which is disabled by default. With this function enabled, packets are bridged across from the “host”, or main, Operating System to the “guest”, or virtual, system(s) as needed. The following notes apply:

  • All data packets sent from the client will have the host OS MAC address as their source address.

Utilizing Multiple IPs on a Single MAC

  • All data packets sent to the client will have the host OS MAC address as their destination address. Each OS has a different client hardware address that is transmitted as part of the DHCP payload. • “Guest” OS hardware devices have MAC addresses that start “00:0c:29”; this is the global standard OUI for VMware. This hardware address is used by the DHCP server to identify guest OSes, allowing them to be provided separate IP addresses.
  • Grat ARP packets transmitted by any IP will have their corresponding unique client hardware addresses.
  • All broadcast packets received by the host OS will also be delivered to the guest OS(es).
  • All unicast packets received by the host OS will be delivered to the guest OS(es) based on the packets’ destination IP address.

In order to support this capability, a command has been added to the CLI:

  • show station multiple-ip—Displays all IP addresses provided by each individual station along with MAC addresses (labeled ‘vmac’ for virtual devices). Note that for the host device, the Client MAC and Virtual MAC will be identical.
  • IPv4 and IPv6 address types are supported.
  • All IP addresses belonging to a single station are assumed to be part of the same VLAN.
  • IP addresses provided to Virtual OSes are always dynamic; static addresses are not supported.
  • ICR is not supported when this feature is enabled.

FortiWLC – Multiple ESSID Mapping

Leave a reply
Multiple ESSID Mapping

The following configuration example shows how to create three ESSIDs and map them to three different VLANs to separate guest users, corporate users, and retail traffic.

The first ESSID, guest-users, is mapped to a VLAN named guest. This ESSID is configured to use the default security profile, which requires no authentication method or encryption method. The VLAN IP address is 10.1.1.2/24 with a default gateway of 10.1.1.1. The DHCP server IP address is 10.1.1.254. This ESSID is configured so that it is added to each access point automatically and is also part of a Virtual Cell. (All access points on the same channel with this ESSID share the same BSSID.)

The second ESSID, corp-users, is mapped to a VLAN named corp. This ESSID is configured to use a security profile called corp-access, which requires 64-bit WEP for an  authentication/ encryption method. The static WEP key is set to corp1. The VLAN IP address is 10.1.2.2/24 with a default gateway of 10.1.2.1. The DHCP server IP address is 10.1.2.254. This ESSID is configured so that it is added to each AP automatically and is also part of a Virtual Cell.

The third ESSID, retail-users, is mapped to a VLAN named retail. This ESSID is configured to use a security profile called retail-access, which requires 802.1X as an authentication method.

Multiple ESSID Mapping

 

The 802.1X rekey period is set to 1000 seconds. The primary RADIUS server IP address is set to 10.1.3.200, the primary RADIUS port is set to 1812, and the primary RADIUS secret is set to secure-retail. The VLAN IP address is set to 10.1.3.2/24 with a default gateway of 10.1.3.1. The DHCP server IP address is 10.1.3.254. This ESSID is configured so that it is added to the access point with node id 1 only. Also, the broadcasting of this ESSID value in the beacons from the access point is disabled, and the ESS is given a BSSID of 00:0c:e6:02:7c:84.

Use the show vlan command to verify the VLAN configuration:

controller# show vlan

VLAN Configuration

VLAN Name   Tag  IP Address      NetMask          Default Gateway guest       1    10.1.1.2        255.255.255.0    10.1.1.1        corp        2    10.1.2.2        255.255.255.0    10.1.2.1        retail      3    10.1.3.2        255.255.255.0    10.1.3.1

Now that the VLANs and security profiles have been created, the new ESSIDs can be created and configured.

controller# configure terminal controller(config)# essid guest-users controller(config‐essid)# security-profile default controller(config‐essid)# vlan guest controller(config‐essid)# exit controller(config)# essid corp-users

controller(config‐essid)# security-profile corp-access controller(config‐essid)# vlan corp controller(config‐essid)# exit controller(config)# essid retail-users

controller(config‐essid)# security-profile retail-access controller(config‐essid)# vlan retail controller(config‐essid)# no ap-discovery join-ess controller(config‐essid)# no publish-essid controller(config‐essid)# ess-ap 1 1 controller(config‐essid‐ess‐ap)# bssid 00:0c:e6:03:f9:a4 controller(config‐essid‐ess‐ap)# exit controller(config‐essid)# exit controller(config)# exit controller#

To verify the creation of the new ESSIDs, use the show essid command.

To view detailed configuration for each of the new ESSIDs, use the show essid essid-name command.

Multiple ESSID Mapping

To verify that the guest-users and corp-users ESSIDs were automatically joined to both access points connected to the controller and that the retail-users ESSID was only joined to

AP 1, use the show ess-ap ap ap-node-id or the show ess-ap essid essid-name commands.

controller# show ess-ap ap 1

ESS‐AP Configuration

AP ID: 1

ESSID                   AP Name        Channel  BSSID guest‐users             AP‐1            6       00:0c:e6:01:d5:c1 corp‐users              AP‐1            6       00:0c:e6:02:eb:b5 retail‐users            AP‐1            6       00:0c:e6:03:f9:a4

controller# show ess-ap ap 2

ESS‐AP Configuration

AP ID: 2

ESSID                   AP Name        Channel  BSSID guest‐users             AP‐2            6       00:0c:e6:01:d5:c1 corp‐users              AP‐2            6       00:0c:e6:02:eb:b5 controller# show ess-ap essid retail-users

ESS‐AP Configuration

ESSID: retail‐users

AP ID   AP Name        Channel  BSSID

1       AP‐1            6       00:0c:e6:03:f9:a4 controller# show ess-ap essid corp-users

ESS‐AP Configuration

ESSID: corp‐users

AP ID   AP Name        Channel  BSSID

  • AP‐1 6       00:0c:e6:02:eb:b5
  • AP‐2 6       00:0c:e6:02:eb:b5

Bridged AP300 in a Remote Location

When bridged mode is configured in an ESSID, an AP using that ESSID can be installed and managed at a location separated from the controller by a WAN or ISP, for example at a satellite office. The controller monitors remote APs with a keep‐alive signal. Remote APs exchange control information, including authentication and accounting information, with the controller but cannot exchange data. Remote APs exchange data with other APs within their subnet.

Because Remote APs cannot exchange data-plane traffic (including DHCP) with the controller, certain Fortinet Wireless LAN features are not available for remote AP configurations. These include:

  • QoS
  • Captive Portal
  • L3 mobility

The features that are available are:

Multiple ESSID Mapping

  • VLAN
  • Virtual Cell
  • 1X authentication
  • High user density
  • Multiple ESSIDs
  • Dataplane encryption for backhoe on L3 tunnel
Configure Bridged Mode with the Web UI

Configure bridged mode when you add or modify an ESS with the Web UI; for directions, see “Add an ESS with the Web UI” on page 137.

Configure Bridged Mode with the CLI

This example creates the ESSID abcjk, sets its mode to bridged, assigns a tag, and then gives top priority to abcjk.

test (config‐essid)# test# configure terminal test (config)# essid abcjk

test (config‐essid)# dataplane bridged test (config‐essid)# ap‐vlan‐tag 11 test (config‐essid)# ap‐vlan‐priority test (config‐essid)# end

For details of the commands used here, see the Command Reference Guide.

FortiWLC – Band Steering Feature

Leave a reply
Band Steering Feature

Band steering works with multi-band capable clients by letting you assign bands to clients based on their capabilities. Without band steering, an ABG client could formerly associate on either the A or the B/G channels, leading to overcrowding on one band or the other. With band steering, you can direct some of this traffic to the A band. Another example of using band steering is to separate  and data traffic. You can leave all -capable clients the B/G channels (where bandwidth is not a concern) and move data-only clients to the A bands to achieve higher data rates. To use band steering for ABGN traffic, you could use A-Steering to direct dual mode clients with A capability to the 5GHz band and use N-Steering to direct all dual mode clients with AN capability to the 5GHz band. Band steering is also useful for directing multicast traffic.

Configure Band Steering with the Web UI

Band Steering is enabled on a per-ESS basis. When you create or modify an ESS, you can enable band steering. To do this with the Web UI, follow the directions “Add an ESS with the Web UI” on page 137 setting the field Enable Band Steering to On. The field Band Steering Timeout defaults to 5 seconds; this is the number of seconds that assignment for a steered client is blocked on the forbidden band while it is unassociated. For this command to work as clients are added, also set the field New APs Join ESS to on in the ESS.

Multicast Restriction per VLAN

 

Configure Band Steering with the CLI

Two new CLI commands have been added for band steering. band-steering-mode enables band steering on an ESS and band-steering-timeout sets the number of seconds that assignment for a steered client is blocked on the forbidden band while it is unassociated. The command band-steering-mode disable turns off band steering. To use band steering, create an ESS with the following configuration:

ESS Profile

ESS Profile                               : bandsteering Enable/Disable                            : enable

SSID                                      : bandsteering

Security Profile                          : default Primary RADIUS Accounting Server          : Secondary RADIUS Accounting Server        :

Accounting Interim Interval (seconds)     : 3600

Beacon Interval (msec)                    : 100

SSID Broadcast                            : on

Bridging                                  : none New AP’s Join ESS                         : on

Tunnel Interface Type                     : none VLAN Name                                 : Virtual Interface Profile Name            :

GRE Tunnel Profile Name                   :

Allow Multicast Flag                      : off

Isolate Wireless To Wireless traffic      : off

Multicast‐to‐Unicast Conversion           : on

RF Virtualization Mode                    : VirtualCell

Overflow from                             :

APSD Support                              : on

DTIM Period (number of beacons)           : 1

Dataplane Mode                            : tunneled AP VLAN Tag                               : 0

AP VLAN Priority                          : off Countermeasure                            : on

Multicast MAC Transparency                : off

Band Steering Mode                        : a‐steering Band Steering Timeout(seconds)            : 5

This example sets band steering to the A channel on the existing ESS named bandsteering:

default(15)# configure terminal default(15)(config)# essid bandsteering default(15)(config‐essid)# dataplane bridged default(15)(config‐essid)# band‐steering‐mode a‐steering default(15)(config‐essid)# end default(15)#

default(15)# show essid bandsteering ESS Profile  
ESS Profile bandsteering
Enable/Disable enable
SSID bandsteering
Security Profile default

Primary RADIUS Accounting Server          Secondary RADIUS Accounting Server

Accounting Interim Interval (seconds)     : 3600

Beacon Interval (msec)                    : 100

SSID Broadcast                            : on

Bridging                                  : none New AP’s Join ESS                         : on

Tunnel Interface Type                     : none

VLAN Name                                 :

Virtual Interface Profile Name            : GRE Tunnel Profile Name                   :

Allow Multicast Flag                      : off

Isolate Wireless To Wireless traffic      : off

Multicast‐to‐Unicast Conversion           : on

RF Virtualization Mode                    : VirtualPort

Overflow from                             :

APSD Support                              : on

DTIM Period (number of beacons)           : 1

Dataplane Mode                            : bridged AP VLAN Tag                               : 0

AP VLAN Priority                          : off Countermeasure                            : on

Multicast MAC Transparency                : off

Band Steering Mode                        : a‐steering Band Steering Timeout(seconds)            : 5 This example disables band steering:

default(15)# configure terminal

default(15)(config)# essid bandsteering default(15)(config‐essid)# band‐steering‐mode disable default(15)(config‐essid)# end default(15)#

default(15)# sh essid bandsteering

ESS Profile

ESS Profile                               : bandsteering Enable/Disable                            : enable

SSID                                      : bandsteering

Security Profile                          default

Primary RADIUS Accounting Server

Secondary RADIUS Accounting Server

Band Steering Feature

Accounting Interim Interval (seconds) 3600
Beacon Interval (msec) 100
SSID Broadcast on
Bridging none
New AP’s Join ESS on
Tunnel Interface Type none

VLAN Name                                 Virtual Interface Profile Name

GRE Tunnel Profile Name                   :

Allow Multicast Flag                      : off

Isolate Wireless To Wireless traffic      : off

Multicast‐to‐Unicast Conversion           : on

RF Virtualization Mode                    : VirtualPort

Overflow from                             :

APSD Support                              : on

DTIM Period (number of beacons)           : 1

Dataplane Mode                            : bridged AP VLAN Tag                               : 0

AP VLAN Priority                          : off

Countermeasure                            : on

Multicast MAC Transparency                : off

Band Steering Mode                        : disable

Band Steering Timeout(seconds)            : 5

Expedited Forward Override

The Expedited Forward Override option is implemented to override the system’s default DSCP-to-WMM priority mapping. IP datagrams marked with DSCP Expedited Forwarding (46) will be sent from the WMM  queue (AC_VO) of the AP rather than the Video queue (AC_VI) in downstream (to stations). This feature is specific to AP400 and is disabled by Default. It is configured on a per-ESS Profile basis and works in both bridged and tunneled ESS profiles.

Steps to configure Expedited Forward Override

  1. Steps to Enable Expedited Forward Override Feature in ESSID:

default # config terminal default(config)# essid meru

default(config‐essid)# expedited‐forward‐override default(config‐essid)# end

default# show essid meru

ESS Profile

ESS Profile                               meru

Enable/Disable                            enable

SSID                                      meru

 

Security Profile                          Primary RADIUS Accounting Server          Secondary RADIUS Accounting Server default
Accounting Interim Interval (seconds) 3600
Beacon Interval (msec) 100
SSID Broadcast on
Bridging none
New AP’s Join ESS on

Tunnel Interface Type                     : none

VLAN Name                                 :

Virtual Interface Profile Name            : GRE Tunnel Profile Name                   :

Allow Multicast Flag                      : off

Isolate Wireless To Wireless traffic      : off

Multicast‐to‐Unicast Conversion           : on

RF Virtualization Mode                    : VirtualPort Overflow from                             :

APSD Support                              : on

DTIM Period (number of beacons)           : 1

Dataplane Mode                            : tunneled AP VLAN Tag                               : 0

AP VLAN Priority                          : off

Countermeasure                            : on

Multicast MAC Transparency                : off

Band Steering Mode                        : disable

Band Steering Timeout(seconds)            : 5

Expedited Forward Override                : on

SSID Broadcast Preference                 : till‐association

B Supported Transmit Rates  (Mbps)        : 1,2,5.5,11 B Base Transmit Rates  (Mbps)             : 11

  1. Steps to Disable Expedited Forward Override Feature in ESSID:

Meru# config terminal

Meru(config)# essid meru

Meru (config‐essid)# no expedited‐forward‐override

Meru(config‐essid)# end

Meru # show essid meru

ESS Profile

ESS Profile                               : meru

Enable/Disable                            : enable SSID                                      : meru

Security Profile                          : default

Primary RADIUS Accounting Server          : Secondary RADIUS Accounting Server

Accounting Interim Interval (seconds)     3600

Beacon Interval (msec)                    100

Band Steering Feature

SSID Broadcast on
Bridging none
New AP’s Join ESS on
Tunnel Interface Type                     VLAN Name                                 Virtual Interface Profile Name            GRE Tunnel Profile Name none
Allow Multicast Flag off

Isolate Wireless To Wireless traffic      : off

Multicast‐to‐Unicast Conversion           : on

RF Virtualization Mode                    : VirtualPort

Overflow from                             :

APSD Support                              : on

DTIM Period (number of beacons)           : 1

Dataplane Mode                            : tunneled AP VLAN Tag                               : 0

AP VLAN Priority                          : off Countermeasure                            : on

Multicast MAC Transparency                : off

Band Steering Mode                        : disable

Band Steering Timeout(seconds)            : 5

Expedited Forward Override                : off

SSID Broadcast Preference                 : till‐association

B Supported Transmit Rates  (Mbps)        : 1,2,5.5,11

B Base Transmit Rates  (Mbps)             : 11

SSID Broadcast for Vport

The SSID Broadcast for Vport function is designed to improve connectivity when using Cisco phones.

Configuration of SSID Broadcast for Vport

The SSID Broadcast for Vport option is similar to that for the ESSID configuration parameter. From the ESSID configuration, the SSID Broadcast for Vport option has three configurable parameters  from GUI and IOSCLI as follows:

  1. Disable: This is the default configuration on the ESSID profile page. Configuring the parameter to “Disable” makes the AP not to advertise the SSID in the beacon.

Example for configuring the option to Disable from IOSCLI:

default# configure terminal default(config)# essid assign

default(config‐essid)# publish‐essid‐vport disabled default(config‐essid)# exit default(config)# exit
  1. Always: Configuring the parameter to “Always” enables the AP to advertise the SSID on the beacons always. This must not be configured unless recommended. Example for configuring the option to till association from IOSCLI:
default# conf terminal default(config)# essid assign

default(config‐essid)# publish‐essid‐vport always default(config‐essid)# end
  1. Till-Association: Configuring the parameter to “Till-Association” enables the AP to advertise the SSID in the beacons until the association stage of the client and disables the SSID broadcast in the later part of connectivity. This parameter is preferable to configure for the certain version of phones which will resolves the connectivity issues with the Vport ON. Once station associated, The AP will stop broadcasting SSID string. Here the users are allowed to configure SSID broadcast for VPort parameter from controller GUI per ESS basis in addition to AP CLI.

Example for configuring the option to till association from IOSCLI:

default# conf terminal default(config)# essid assign

default(config‐essid)# publish‐essid‐vport till‐association default(config‐essid)# end