- Forums
- Knowledge Base
- Customer Service
- FortiGate
- FortiClient
- FortiAP
- FortiAnalyzer
- FortiADC
- FortiAuthenticator
- FortiBridge
- FortiCache
- FortiCarrier
- FortiCASB
- FortiConnect
- FortiConverter
- FortiCNP
- FortiDAST
- FortiDDoS
- FortiDB
- FortiDNS
- FortiDeceptor
- FortiDevSec
- FortiDirector
- FortiEDR
- FortiExtender
- FortiGate Cloud
- FortiGuard
- FortiHypervisor
- FortiInsight
- FortiIsolator
- FortiMail
- FortiManager
- FortiMonitor
- FortiNAC
- FortiNAC-F
- FortiNDR (on-premise)
- FortiNDRCloud
- FortiPAM
- FortiPortal
- FortiProxy
- FortiRecon
- FortiRecorder
- FortiSandbox
- FortiSASE
- FortiScan
- FortiSIEM
- FortiSOAR
- FortiSwitch
- FortiTester
- FortiToken
- FortiVoice
- FortiWAN
- FortiWeb
- Wireless Controller
- RMA Information and Announcements
- FortiCloud Products
- ZTNA
- 4D Documents
- Customer Service
- Community Groups
- Blogs
FortiGate
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.
- Fortinet Community
- Knowledge Base
- FortiGate
- Technical Note : Advanced SNMP Trap Configuration ...
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
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).
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.
1. LAN alert destination config
setlanconfig 1 destination_type 2 0 0 0
Set the type of alert (an unacknowledged PET trap) for destination number 2 and channel 1 (LAN channel used by the external Ethernet interface Eth0)
setlanconfig 1 destination_address 2 0 192.168.182.86 00:09:0f:09:32:03
Set the IP and MAC destination alert address and indicate to use the default gateway
setlanconfig 1 community “community name”
Set community name used in PET traps
setpefconfig control f
Enable PEF, generation of event messages for PEF action, startup delays, alert startup delays
setpefconfig action_control 1
Enable alert action
setpefconfig startup_delay 60
Delay PEF for 60 seconds after system power-ups
setpefconfig alert_startup_delay 60
Delay alerts for 60 seconds after system power-ups
setpefconfig event_filter N <value1><value2> ........ <value19>
Configure the event filter entry number N, where N is an arbitrary decimal number.
See IPMI specification (Intelligent Platform Management Interface), version 1.5 for more details for the table below.
The following event filter entries have been configured for this example. The last line (filter 20) is using the values of the above table :
setpefconfig event_filter 1 80 1 5 02 82 FF F0 FF FF FF FF 0 0 0 0 0 0 0 0 0
setpefconfig event_filter 6 80 1 5 02 8C FF F0 FF FF FF FF 0 0 0 0 0 0 0 0 0
setpefconfig event_filter 8 80 1 5 02 90 FF F0 FF FF FF FF 0 0 0 0 0 0 0 0 0
setpefconfig event_filter 10 80 1 5 02 94 FF F0 FF FF FF FF 0 0 0 0 0 0 0 0 0
setpefconfig event_filter 11 80 1 5 02 96 FF F0 FF FF FF FF 0 0 0 0 0 0 0 0 0
setpefconfig event_filter 20 80 1 5 02 20 FF F0 FF FF FF FF 0 0 0 0 0 0 0 0 0
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
Initial state of PEM B is active :
CLI> fru 20 7
Then deactivate PEM B :
CLI> deactivate 20 7
CLI> sel
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.
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
Sensor number 9 is the hot swap sensor for PEM B
CLI> sensor 20 9
SNMP trap from packet sniffer :
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
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
CLI> sensor 20 6
When inserted, there are 4 state changes and 4 SNMP traps sent.
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:
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.
1. LAN alert destination config
setlanconfig 1 destination_type 2 0 0 0
Set the type of alert (an unacknowledged PET trap) for destination number 2 and channel 1 (LAN channel used by the external Ethernet interface Eth0)
setlanconfig 1 destination_address 2 0 192.168.182.86 00:09:0f:09:32:03
Set the IP and MAC destination alert address and indicate to use the default gateway
setlanconfig 1 community “community name”
Set community name used in PET traps
2. PEF Config: Event Filter Table
setpefconfig control f
Enable PEF, generation of event messages for PEF action, startup delays, alert startup delays
setpefconfig action_control 1
Enable alert action
setpefconfig startup_delay 60
Delay PEF for 60 seconds after system power-ups
setpefconfig alert_startup_delay 60
Delay alerts for 60 seconds after system power-ups
setpefconfig event_filter N <value1><value2> ........ <value19>
Configure the event filter entry number N, where N is an arbitrary decimal number.
See IPMI specification (Intelligent Platform Management Interface), version 1.5 for more details for the table below.
|
Byte |
Field |
Value |
Description |
|
1 |
Filter configuration |
80 |
Enable filter |
|
2 |
Filter action |
1 |
Set action = alert |
|
3 |
Alert policy # |
5 |
Select an alerting policy from the Alert Policy Table. |
|
4 |
Severity |
02 |
Fill in the Event Severity field in a PET alert/trap : 02 = Information |
|
5 |
Slave/IPMB address |
20 |
Select the IPMB address to match (20 = address where are the fans, pems, sap, ....) |
|
6 |
Channel/LUN # |
FF |
Channel/LUN to match (FF= any) |
|
7 |
Sensor type |
F0 |
Type of sensor (F0= hot swap) |
|
8 |
Sensor number |
FF |
FF= any |
|
9 |
Event/reading type |
FF |
FF= any |
|
10,11 |
Event Data 1 Event Offset Mask |
FF FF |
FF FF = match all event offset values |
|
12 |
event data 1 AND mask |
0 |
|
|
13 |
event data 1 compare 1 |
0 |
Allow to add granularity and boolean logic to select particular(s) event(s) |
|
14 |
event data 1 compare 2 |
0 |
|
|
15 |
event data 2 AND mask |
0 |
With all values set to 0, there is no further “refinement” |
|
16 |
event data 2 compare 1 |
0 |
|
|
17 |
event data 2 compare 2 |
0 |
|
|
18 |
event data 3 AND mask |
0 |
|
|
19 |
event data 3 compare 1 |
0 |
|
|
20 |
event data 3 compare 2 |
0 |
|
The following event filter entries have been configured for this example. The last line (filter 20) is using the values of the above table :
setpefconfig event_filter 1 80 1 5 02 82 FF F0 FF FF FF FF 0 0 0 0 0 0 0 0 0
setpefconfig event_filter 6 80 1 5 02 8C FF F0 FF FF FF FF 0 0 0 0 0 0 0 0 0
setpefconfig event_filter 8 80 1 5 02 90 FF F0 FF FF FF FF 0 0 0 0 0 0 0 0 0
setpefconfig event_filter 10 80 1 5 02 94 FF F0 FF FF FF FF 0 0 0 0 0 0 0 0 0
setpefconfig event_filter 11 80 1 5 02 96 FF F0 FF FF FF FF 0 0 0 0 0 0 0 0 0
setpefconfig event_filter 20 80 1 5 02 20 FF F0 FF FF FF FF 0 0 0 0 0 0 0 0 0
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" |
Then deactivate PEM B :
CLI> deactivate 20 7
| Command executed successfully |
CLI> sel
| 0x0001: Event: at Jul 8 17:12:21 2008; from:(0x20,0,0); sensor:(0xf0,9); event:0x6f(asserted): HotSwap: FRU 7 M4->M6, Cause=0x1 0x0002: Event: at Jul 8 17:12:21 2008; from:(0x20,0,0); sensor:(0x12,133); event:0x6f(asserted): 0xC4 0x01 0x00 0x0003: Event: at Jul 8 17:12:21 2008; from:(0x20,0,0); sensor:(0xf0,9); event:0x6f(asserted): HotSwap: FRU 7 M6->M1, Cause=0x0 0x0004: Event: at Jul 8 17:12:21 2008; from:(0x20,0,0); sensor:(0x12,133); event:0x6f(asserted): 0xC4 0x01 0x00 |
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
Sensor number 9 is the hot swap sensor for PEM B
CLI> sensor 20 9
| 20: LUN: 0, Sensor # 9 ("FRU 7 HOT_SWAP") Type: Discrete (0x6f), "Hot Swap" (0xf0) Belongs to entity: (0xa, 97) [FRU # 7] |
SNMP trap from packet sniffer :
| No. Time Source Destination Protocol Info 1 17:11:21.469567 192.168.181.66 192.168.182.86 SNMP trap Frame 1 (177 bytes on wire, 177 bytes captured) Ethernet II, Src: RapidCit_5f:cc:97 (00:e0:16:5f:cc:97), Dst: Vmware_3c:55:c0 (00:0c:29:3c:55:c0) Destination: Vmware_3c:55:c0 (00:0c:29:3c:55:c0) Source: RapidCit_5f:cc:97 (00:e0:16:5f:cc:97) Type: IP (0x0800) Internet Protocol, Src: 192.168.181.66 (192.168.181.66), Dst: 192.168.182.86 (192.168.182.86) User Datagram Protocol, Src Port: 1024 (1024), Dst Port: snmptrap (162) Simple Network Management Protocol version: version-1 (0) community: public data: trap (4) trap enterprise: 1.3.6.1.4.1.3183.1.1 (SNMPv2-SMI::enterprises.3183.1.1) agent-addr: internet (0) internet: 192.168.181.66 (192.168.181.66) generic-trap: enterpriseSpecific (6) specific-trap: 15757062 time-stamp: 1975765011 variable-bindings: 1 item Item name: 1.3.6.1.4.1.3183.1.1.1 (SNMPv2-SMI::enterprises.3183.1.1.1) valueType: value (0) value: simple (4294967295) simple: string-value (1) Value: Hex-STRING: 54 FA FC B6 41 50 11 DD 00 80 00 50 C2 3F F0 9A 00 4F 13 C8 C3 75 00 00 20 20 02 20 09 00 00 A6 14 07 00 00 00 00 00 19 0A 40 00 00 00 00 80 53 01 74 65 73 74 20 61 6C 65 72 74 20 6D 65 73 73 61 67 65 00 C1 Packet bytes : 0000 00 0c 29 3c 55 c0 00 e0 16 5f cc 97 08 00 45 00 ..)<U...._....E. 0010 00 a3 00 00 40 00 3e 11 4f 60 c0 a8 b5 42 c0 a8 ....@.>.O`...B.. 0020 b6 56 04 00 00 a2 00 8f 6a 28 30 81 84 02 01 00 .V......j(0..... 0030 04 06 70 75 62 6c 69 63 a4 77 06 09 2b 06 01 04 ..public.w..+... 0040 01 98 6f 01 01 40 04 c0 a8 b5 42 02 01 06 02 04 ..o..@....B..... 0050 00 f0 6f 06 43 04 75 c3 c8 13 30 55 30 53 06 0a ..o.C.u...0U0S.. 0060 2b 06 01 04 01 98 6f 01 01 01 04 45 54 fa fc b6 +.....o....ET... 0070 41 50 11 dd 00 80 00 50 c2 3f f0 9a 00 4f 13 c8 AP.....P.?...O.. 0080 c3 75 00 00 20 20 02 20 09 00 00 a6 14 07 00 00 .u.. . ........ 0090 00 00 00 19 0a 40 00 00 00 00 80 53 01 74 65 73 .....@.....S.tes 00a0 74 20 61 6c 65 72 74 20 6d 65 73 73 61 67 65 00 t alert message. 00b0 c1 |
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" |
CLI> sensor 20 6
| 20: LUN: 0, Sensor # 6 ("FRU 4 HOT_SWAP") Type: Discrete (0x6f), "Hot Swap" (0xf0) Belongs to entity: (0x1e, 97) [FRU # 4] |
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.Related Articles
Commonly used FortiGate-5000 chassis shelf manager commands
Technical Note : FortiGate Chassis - Shelf-Manager Management Overview
Labels:
Broad. Integrated. Automated.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Security Research
Company
News & Articles
Copyright 2024 Fortinet, Inc. All Rights Reserved.