Configuring SNMP traps on Brocade SAN switches

SAN switches are the core components in your Storage Area Network. Therefore it’s important to monitor the devices correctly to ensure the operational continuity of your storage infrastructure.

The first approach is by implementing Brocade Network Advisor (BNA). BNA is a tool used to manage, monitor and report (performance -, throughput visualization and many more) on fiber channel SAN switches and comes with a cost (platform hosting the software + software licenses/support). Brocade Network Advisor can be integrated with Microsoft System Center Operations Manager with a Management Pack (plugin).

A different approach is by monitoring the devices with plain SNMP traps. This blogpost will guide you through the configuration process of SNMP on Brocade SAN switches. We will be using Microsoft System Center Orchestrator to collect the information in the SNMP traps and push it into a incident management tool. The use of Microsoft System Center is not mandatory, a Nagios could do the trick as well.

Configure the SNMP trap recipients on the SAN switch.
Before we can configure the traps, we need to perform some basic SNMP configuration. Open an SSH connection to the SAN switch with an administrative account and execute the following command. We decided to use SNMPv3.

SANSW001:FID128:admin> snmpconfig –set snmpv3
SNMP Informs Enabled (true, t, false, f): [false

User (ro): [customuseraccount]
Auth Protocol [MD5(1)/SHA(2)/noAuth(3)]: (1..3) [1]
New Auth Passwd: [password]
Priv Protocol [DES(1)/noPriv(2)/AES128(3)/AES256(4)]): (1..4) [2]

SNMPv3 trap recipient configuration:
Trap Recipient’s IP address : []
UserIndex: (1..6) [4]  (refers to the customeruseraccount listed above)
Trap recipient Severity level : (0..5) [4] 3 (see below for more details)
Trap recipient Port : (0..65535) [162]
Trap Recipient’s IP address : []
UserIndex: (1..6) [4]
Trap recipient Severity level : (0..5) [3]
Trap recipient Port : (0..65535) [162]

Committing configuration…..done.

Trap recipient severity can be one of the following values: [0] none, [1] critical, [2] error, [3] warning, [4] informational or [5] debug. When an event occurs and it’s severity level is equal or below the configured value, an SNMP trap is sent to the configured SNMP trap recipients.

Define the SNMP traps you want to catch.
The easiest way is to consult the “Fabric OS MIB Reference Guide” and list the traps you want to catch. We decided to catch only the traps: “swEventTrap” and “swStateChangeTrap“, where “swEventTrap” contains events added to the system error log and “swstatechangetrap” is triggered when the switch goes from “Online” to “Offline” or “Marginal”.

These traps are not active by default, execute the following commands to activate them:

SANSW001:FID128:admin> snmpconfig –set mibcapability -mib_name SW-MIB -bitmask  1
SANSW001:FID128:admin> snmpconfig –enable mibcapability -mib_name SW-MIB -trap_name swEventTrap
SANSW001:FID128:admin> snmpconfig –enable mibcapability -mib_name SW-MIB -trap_name swStateChangeTrap

Reconfigure the switch status policy to correctly send events upon port changes (faulty- and/or marginal ports). You need to change this carefully, as we don’t want an incident to be created upon a server reboot.

In the SSH session, execute the following commands and configure the values according to the switch type and number of utilized ports. We don’t want to transition the switch into a “Down” status because too many ports are faulty or down, we do want to change the status to “Marginal” as this will trigger both the “swEventTrap” (bad port is listed in the event log) and “swStateChangeTrap” as the switch transitioned into a “Marginal” status.

SANSW001:FID128:admin> switchstatuspolicyset
To change the overall switch status policy parameters the current overall switch status policy parameters:

The minimum number of

Bad PowerSupplies contributing to DOWN status: (0..2) [2]
Bad PowerSupplies contributing to MARGINAL status: (0..2) [1]
Bad Temperatures contributing to DOWN status: (0..1) [1]
Bad Temperatures contributing to MARGINAL status: (0..1) [1]
Bad Fans contributing to DOWN status: (0..2) [2]
Bad Fans contributing to MARGINAL status: (0..2) [1]
Out of range Flash contributing to DOWN status: (0..1) [0]
Out of range Flash contributing to MARGINAL status: (0..1) [1]
MarginalPorts contributing to DOWN status: (0..100) [25.00]
MarginalPorts contributing to MARGINAL status: (0..100) [10.00] 1
FaultyPorts contributing to DOWN status: (0..100) [25.00]
FaultyPorts contributing to MARGINAL status: (0..100) [10.00] 1
MissingSFPs contributing to DOWN status: (0..100) [0.00]
MissingSFPs contributing to MARGINAL status: (0..100) [0.00]
ErrorPorts contributing to DOWN status: (0..100) [0.00]
ErrorPorts contributing to MARGINAL status: (0..100) [0.00]
Policy parameter set has been changed

Remark: I have to admit we need to validate this setup with NPIV ports. An NPIV port does not immediately correlate with a physical port, hence the port status will be unchanged. The creation of an SNMP trap is purely based on an event in the system eveng log. This requires a more detailed validation!

Finally, we can send out a test trap to validate if the monitoring tool successfully catches the trap and pushes it into the Incident Management platform. A test trap can be sent from the SSH session by using the following command:

SANSW001:FID128:admin> snmptraps –send -trap_name sw-event-trap -ipaddress
Number of traps sent : 1

You successfully configured basic monitoring on a HPE SN6000B Brocade SAN switch. You can go a little bit further in the setup by allowing Microsoft System Center to collect the throughput/performance details. Statistics can be collected by using the “Bottleneck Detection (BD) MIB objects“. As this setup is for a rather small environment, we decided to use basic monitoring only.

Hope this helps!


Leave a Reply