Technical Article

Custom SNMP Traps

All BIG-IP systems are pre-configured with a set of trap definitions that are helpful for managing the hardware and software components of the device. In most cases the default traps are sufficient for monitoring and managing the system. Some deployments, however, require custom SNMP traps on other logged events. In this article, I will show you the process of building a custom SNMP trap for BIG-IP.

BIG-IP uses a standard syslog-ng / alertd framework for generating alerts, including SNMP traps. In BIG-IP version 9.x, SNMP traps are triggered when the alertd process receives input from the syslog-ng utility that matches an alert code or match string. The alertd process then performs the action specified in the /etc/alertd/alert.conf or /config/user_alert.conffile, such as sending an SNMP trap.

If, as in our original example, the match string is not defined in the alert definition itself, you can find it in the /var/tmpfs/run/bigip_error_maps.dat by searching for the alert name with this command:

(Regular expressions may be used in the alert.conf/user_alert.conf file, while C-style variable substitutions such as %s (string) and %u (unsigned integer) are used in bigip_error_maps.dat.

When the alertd process starts, the runtime configuation file, /var/tmpfs/run/alert.conf, is created by appending the /config/user_alert.conf file to the /etc/alertd/alert.conf file, and the /var/run/bigip_error_maps.dat file is dynamically generated using entries from all of the map files in the /etc/alertd/ directory that end with the _maps.h file extension. The alertd process uses the /var/run/bigip_error_maps.dat file to map input it receives from the syslog-ng utility to an alert name. When alertd receives input from syslog-ng utility that matches an alert code, the alert code is mapped to the alert name. The alertd process then performs the alert actions specified for that alert name in the /etc/alertd/alertd.conf file, such as issuing an LCD warning, or sending an SNMP trap.

So now that we some understanding of the underpinnings, let's move on to defining a custom trap.

Step 1: Identify trappable log event

Any event that is logged by syslog-ng may be used to configure a custom SNMP trap. For example, a normally functioning system commonly logs messages related to node or pool member status changes. We will use one of those log messages as an example to demonstrate the creation of a custom SNMP traps.

For example, when a pool member changes status, a line is logged to the LTM Local Traffic log (/var/log/ltm) that indicates the the pool member's identity and current status:

From the example above, we know there is already a default trap that is generated for all pool member status changes. For demonstration purposes, let's assume that the host at 10.0.0.154:80 is a critical system, and we would like to define a custom trap with its own OID.

Step 2: Create the custom match expression

To create a pool member specific trap, you will need to make the match expression specific to that pool member: Using the existing trap as a template, we can insert the specific pool member IP and port, and since the alert match string for custom traps is always defined in the user_alert.conf file, we must replace the %s status variable with a corresponding regular expression to catch all status changes for this pool member, creating the following match expression:

"Pool member 10.0.0.154:80 monitor status (.*?)."

Step 3: Choose an OID

An SNMP OID (Object ID) is simply a unique numeric index for the event you wish to trap.

In version 4.x, F5 Networks recommended that you use traps in the range 1.3.6.1.4.1.3375.1.1.110.200 - 1.3.6.1.4.1.3375.1.1.110.999, in order to prevent conflict with official traps added by F5 in the future. As of 9.x, however, we recommend updating this to a range of 1.3.6.1.4.1.3375.2.4.0.300 - 1.3.6.1.4.1.3375.2.4.0.999 to avoid conflicts. For example, if you're running v9.x or later, when you add your first custom SNMP trap use OID 1.3.6.1.4.1.3375.2.4.0.300. When you add another SNMP trap, use 1.3.6.1.4.1.3375.2.4.0.301.

However, you can use any object ID that meets all of the following criteria:

is in standard OID format, such as .1.3.6.1.4.1.3375.2.4.0.500

is in a numeric range that can be processed by your trap receiving tool

does not already exist in the /usr/share/snmp/mibs/F5-BIGIP-COMMON-MIB.txt MIB file

is not already used in another custom trap

For our example, we will use 1.3.6.1.4.1.3375.1.1.110.200.

Step 4: Modify the alertd configuration

Note: Custom, user-defined SNMP traps are defined in the /config/user_alert.conf file. Standard, pre-configured SNMP traps are defined in the /etc/alertd/alert.conf file. Do not add or remove traps from the alert.conf file. When the alertd process starts, it creates a dynamic configuration file, /var/tmpfs/run/alert.conf, by appending the /config/user_alert.conf file to the /etc/alertd/alert.conf file.

To add your custom trap, edit the /config/user_alert.conf file and add a new SNMP trap using the parts we constructed above and a unique alert name, following the expected format:

Hello,
i did add custom alertname as you did with "_serverx" suffix but this doesn't work when a pool is going down (it did work when using manual logger command)
It seems that only exact existing alertname works. Is that correct ?
We do not have any access to modify alert code or alertname, as far as i understand. We can add a regex type matching pattern to the alertname definition to catch only event we want and trigger the custom action desired; and send the oid we want.
thanks a lot for your attention guys.

0

About DevCentral

We are a community of 300,000+ technical peers who solve problems together.