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? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!