FortiWLC – Alarms

Alarms

When alarms are generated, the user has the option to either Acknowledge or Clear them by simply checking the box alongside the desired alarm and clicking the appropriate button towards the bottom of the window.

  • Clear—Moves the alarm from the Active Alarms table into the Alarm History table.
  • Acknowledge—Marks the alarm as acknowledged in the UserAcknowledged column.

As seen in the figure above, the Active Alarms table provides several columns, as described below.

489

TABLE 35: Active Alarm Columns

Column Description
Alarm Name The name of the alarm triggered.
Severity The severity level; can range from Information, Minor, Major, Critical.
Source The type of device that triggered the alarm (controller, AP).
FDN The name of the device that triggered the alarm.
Raised At The date and time at which the alarm was triggered.
Detail Detailed information regarding the alarm, including identifying device details.
UserAcknowledged Indicates whether the alarm has been flagged as Acknowledged.
Modifying Alarm Definitions

While FortiWLC (SD) provides a list of pre-configured alarms, users can also customize the alarms to the needs of their environment via the Alarms > Definition tab.

Figure 86: Alarm Definitions

As shown above, each alarm has a predetermined severity level, trigger condition, and threshold, but these values can be modified by clicking the small pencil icon next to the desired alarm. This will pop up the Alarm Configuration window, as seen in Figure 87 on page 491.

 

Figure 87: Editing an Alarm

Use the drop-downs provided in the window to tailor the alarm to the deployment’s needs and click Save when finished. If desired, the user can click Reload Default to reset the alarm’s configuration to its original values.

The Threshold field’s units will vary depending on the alarm selected—for example, when modifying AP Memory Usage High, the Threshold is measured in percentage of overall system memory (and defaults to 70%). However, in an alarm such as Link Down, no threshold is needed at all, as it is a binary alarm (i.e., it is triggered when a link to an AP goes down—there is no percentage involved).

List of Alarms
No. Alarm Severity Source Explanation
1. Alarm link up information all controller models Physical link on controller is up.
2. Alarm link down critical all controller models Physical link on the controller is down; check the connection.
3. Alarm auth fail information controller models An administrator failed to log in to the GUI due to an authentication failure.
4. AP down critical all AP models An AP is down. Possible reasons for this are an AP reboot, an AP crash, or an Ethernet cable from the controller may be down. Also the AP may have connected to another controller.
5. Radio Failure critical all AP models An alarm is generated when the Radio fails to turn operational during Initial bootup. This is occurred due to some Hardware issue on the AP Radio.
6. Rogue AP detected critical all controller models A rogue AP has been detected on the network.

The message looks something like this: Rogue

AP Detected               Critical  06/04/2010

10:04:51  CONTROLLER (1:24194)  ROGUE AP DETECTED. Station mac=0c:60:76:2d:fe:d9 bss=00:02:6f:3a:fd:89 by AP Ben-Cubei (18)

See the chapter Rogue AP Detection and Mitigation.

7. AP software version mismatch critical all AP models The software version on the AP does not match the version on the controller. Automatic AP upgrade must have been turned off. Update the AP from the controller with either the CLI command upgrade ap same <ap id> force or upgrade ap same all force. You can also turn automatic upgrade back on by with the CLI command autoap-upgrade enable.
8. AP init failure major all AP models AP initialization failed.

 

No. Alarm Severity Source Explanation
9. Software license expired major all controller

models

Controller software license has expired. To obtain additional licenses, see www.merunetworks.com/ license.
10. 802.1X auth failure major, minor, information all controller

models

RADIUS server authentication failed. To find out why, look at the RADIUS server log for the error message and also check the station log. If this happens only occasionally, you can ignore it. However, if this message appears repeatedly, the authentication failures could prevent a station from entering the network. In this case, check the RADIUS server to make sure the client and server have the same credentials.
11. MIC failure AP major all controller models The Michael MIC Authenticator Tx/Rx Keys provided in the Group Key Handshake are only used if the network is using TKIP to encrypt the data. A failure of the Michael MIC in a packet usually indicates that the WPA WPSK password is wrong.
12. MIC countermeasure activation major all controller

models

Two consecutive MIC failures have occurred (see above).
13. RADIUS Server Switchover major all controller

models

A switchover from the Primary  Authentication

RADIUS Server to the Secondary Authentication RADIUS Server occurred. When this message occurs, the Primary RADIUS server is configured but not reachable and the Secondary RADIUS server is both configured and reachable.

This message is generated only for 802.1x switchover, not for Captive Portal switchover.

An example looks like this:

RADIUS Server Switchover        Major     06/07/ 2010 14:09:57  RADIUS Server switches over from Primary <172.18.1.7> to Secondary

<172.18.1.3> for Profile <wpa>

 

No. Alarm Severity Source Explanation
14. RADIUS Server Switchover Failed major all controller

models

A switchover from the Primary  Authentication

RADIUS Server to the Secondary Authentication RADIUS Server  failed because the secondary server is not configured. When this message occurs, the Primary RADIUS server is configured but not reachable and the Secondary RADIUS server is not configured.

This message is generated only for 802.1x switchover failure, not for Captive Portal switchover failure.

An example looks like this:

RADIUS Server Switchover Failed Major     06/

07/2010 14:02:47  Primary RADIUS Server

<172.18.1.7> failed. No valid Secondary RADIUS

Server present. Switchover FAILED for Profile

<wpa> Alarms Table(1 entry)

15. Restore Primary RADIUS Server major all controller

models

A switchover from the Secondary Authentication

RADIUS Server to the Primary Authentication RADIUS Server occurred. This alarm was generated while doing RADIUS fall back to the primary server after 15 minutes.

This message is generated only for 802.1x primary RADIUS restore, not for Captive Portal restore.

An example looks like this:

Restore Primary RADIUS Server   Major     06/07/ 2010 15:54:10  Security Profile <wpa> restored back to the Primary RADIUS server <172.18.1.7>

 

No. Alarm Severity Source Explanation
16. Acct RADIUS server switchover major all controller

models

A switchover from either Accounting RADIUS Server (primary or secondary) to the other one occurred. This message is generated only for 802.1x switchover, not for Captive Portal switchover.

An example when the primary to secondary switch occurred looks like this:

Accounting RADIUS Server Switch Major     06/ 07/2010 14:39:00  Accounting RADIUS Server switches over from Primary <172.18.1.7> to Secondary <172.18.1.3> for Profile <wpa>

17. Acct RADIUS server switchover failed major all controller models An attempted switchover from one Accounting RADIUS Server to the other server failed.When this message occurs, the Primary Accounting RADIUS server is configured but not reachable and the Secondary Accounting RADIUS server is not configured.

This message is generated only for 802.1x switchover failure, not for Captive Portal switchover fail lure.

An example looks like this:

Accounting RADIUS Server Switch Major     06/

07/2010 14:22:26  Primary Accounting RADIUS

Server <172.18.1.7> failed. No valid Secondary

Accounting RADIUS Server present. Switchover

FAILED for Profile <wpa>

18. Master down critical all controller models N+1 Master controller is down and no longer in control; the slave controller will now take over.
19. Master up critical all controller models N+1 Master controller is up and running; this controller will now take control away from the slave controller.
20. CAC limit reached major all controller models Admission control in ATM networks is known as Connection Admission Control (CAC) – this process determines which traffic is admitted into a network. If this message occurs, the maximum amount of traffic is now occurring on the network and no more can be added.

 


Having trouble configuring your Fortinet hardware or have some questions you need answered? Ask your questions in the comments below!!! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Leave a Reply

Name *
Email *
Website

This site uses Akismet to reduce spam. Learn how your comment data is processed.