FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Description This document provides an overview of functionality, as well as example SNMP traps, that can be generated by the 5140 Shelf Manager.
Documentation reference : "FortiGate 5140 or 5050 Chassis Guide" at http://docs.forticare.com/fgt5k.html - Chapter "Using the shelf manager CLI".
This article will refer to the management operating system located on the Shelf Manager, additional documentation, can be found on http://www.pigeonpoint.com.
Introduction to Platform Event Filtering (PEF) and Baseboard Management Controller (BMC)
The Platform Event Filtering (PEF) provides a regular mechanism for configuring the Baseboard Management Controller (BMC) to take selected actions on event messages that it receives or has internally generated. These actions include operations such as system power off, system reset, as well as triggering the generation of an Alert.
The BMC maintains an event filter table that is used to select which events can trigger for example a page and which actions to perform on receipt. Each time the BMC receives an event message (either externally or internally generated) it compares the event data against the entries in the event filter table. The BMC scans all entries in the table and collects a set of actions to be performed as determined by the entries that were matched.
When an Alert is triggered via PEF, the alerting process is directed by an Alert Policy. An alert policy is a collection of one or more alert destinations. An alert policy can support a mix of different alert destination types and channels. For example, one policy could include LAN, dial page, and TAP alerts to different locations. An implementation can support multiple policies. A policy number identifies different policies in the table. The alert policy number is used in the Event Filter Entry to select what alert policy is used when a match occurs. This mechanism allows different alert policies to be associated with different classes of events.
The combination of Event Filter Entry and alert destination are used to select a given Alert String from a set of strings kept in the PEF configuration parameters. This enables different strings to be sent based on what event filter was matched and where the alert is being sent”
FRU (Field Replaceable Unit) State Changes
The Shelf Manager can obtain information from the different IPMC (Intelligent Platform Management Controller) controllers/ FRU installed in a chassis through sensors installed on these devices. The example and tests presented hereafter focus on the hot swap sensor which provide the FRU operational state (see PICMG 3.0/ATCA specifications).
The FRU states M0-M7 are defined in the PICMG 3.0 specification as follows:
M0 – Not Installed M1 – Inactive M2 – Activation Request M3 – Activation in Progress M4 – FRU Active M5 – Deactivation Request M6 – Deactivation in Progress M7 – Communication Lost
Scope Shelf Manager
Solution The following example highlights a configuration of the Event filter table, Alert Policy table and Alert String table to send alerts following FRU state changes.
The alerts which will be sent from the shelf manager will be SNMP traps whose formats are defined in the Platform Event Trap Format specification.
The CLI commands (see Pigeon Point External Interface Reference guide for 2.3.2 for syntax and command description) have been used to send SNMP traps when a FRU state change occurs for certain devices in the chassis.
This creates event filter entries for events occurring on slot1 (5003), slot 6, 8, 10, 11 (5005FA2 blades) and for FRUs which are at IPMB address 20 (PEMs, Fans, SAP,...)
3. PEF config : alert policy and string tables
setpefconfig alert_policy 8 5 8 1 2 7
Set alert policy table entry 8 with alert policy number 5 , policy enabled, alert always sent, destination channel 1, destination address 2 and alert string selector 7
setpefconfig alert_string 7 “test alert message”
Set the alert string selector 7 equal to “test alert message”
Please note that all the assertion events are enabled for the hot swap sensor and therefore the assertion event mask is set to 0x00ff , tol allow tracking of any FRU state change
4. Test and results
4.1 PEM deactivation/activation
To verify if traps can be received when there is a FRU state change for a PEM, you can use the CLI to deactivate/activate the PEM B of the 5140 chassis.
Initial state of PEM B is active :
CLI> fru 20 7
20: FRU # 7 Entity: (0xa, 0x61) Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0) Device ID String: "PEM B"
There are two state changes above : M4 -> M6 -> M1
Two SNMP traps are generated, and below are more details concerning one of these traps (the one sent when PEM B goes into an M6 state).
When activating the PEM B, there are three state changes (M1 -> M2 -> M3 -> M4) and three traps are sent.
Please note that the SNMP trap format is specified in the Platform Event Trap Format Specification document.
4.2 SNMP Trap Details
The traps below are sent when PEM B state changes from M4 to M6.
Two important pieces of information are the specific trap field (in red below) and the variable bindings fields (in blue).
Byte 2 of the specific trap field shows the sensor type (f0 = hot swap) and the 4th byte is the event offset (06 = assertion to state 6= M6)
The variable bindings fields which are in bold, italic, underlined blue in the trace below are the following bytes:
- Byte 26 = Event Source Type = Class of device or type of software that originated the event - Byte 27 = Event Severity - Byte 28 = Sensor Device byte = Identifies the instance of the device that holds the sensor that generated the event - Byte 29 = Sensor Number
From v2.5.2 of the Pigeon Point System Shelf Manager software you can choose between three PET formats. Up until v2.5.1 the only available format was 0. Format 1 and 2 are more user-friendly
The values are defined as follows:
0 = the default IPMI format defined by IPMI Platform Event Trap Format v1.0 specification. 1 = plain text format; all the event details are sent as plain ASCII text in a single variable. 2 = multi-variable format; each event field is encoded as a separate variable
4.3 Fan Tray Removal and Insertion
This example, shows the sequence when a fan tray (1) is removed and and re-inserted.
When removed, it will cause a state change (M4 -> M7) and an SNMP trap will be sent with byte 4 of specific trap field = 07.
Byte 29 of variable binding fields was equal to 06 = FRU 4 hot swap sensor.
See the FAN tray state after having been re-inserted and operationally active.
CLI> fru 20 4
20: FRU # 4 Entity: (0x1e, 0x61) Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0) Device ID String: "Fan Tray 1"
When inserted, there are 4 state changes and 4 SNMP traps sent.
4.4 Chassis power cycle
Note that when a chassis is power cycled, several traps generated for the slots that are monitored including state changes for the monitored FRU units.