Skip to main content

6. Notification Filtering

Notification filtering provides a mechanism to selectively send notifications to management targets based on the content of the notification. This allows fine-grained control over which management targets receive which types of notifications.

Notification filtering uses three MIB tables:

  • snmpNotifyFilterProfileTable: Associates a filter profile name with a set of target parameters.
  • snmpNotifyFilterTable: Defines the actual filter rules based on notification content.
  • snmpTargetParamsTable: Contains the target parameter names referenced by the filter profile table.

Filter Processing Algorithm​

When a notification originator generates a notification for a management target, it applies notification filtering as follows:

  1. Retrieve the target parameters name from the snmpTargetAddrParams object for the management target.

  2. Look up the filter profile in the snmpNotifyFilterProfileTable using the target parameters name as the index.

  3. If no filter profile is found, the notification is sent (no filtering is applied).

  4. If a filter profile is found, the snmpNotifyFilterProfileName identifies a set of filter entries in the snmpNotifyFilterTable.

  5. For each variable-binding in the notification:

    a. Search the snmpNotifyFilterTable for entries matching the filter profile name.

    b. Entries are processed in lexicographical order of their indices.

    c. For each filter entry, check if the subtree specified by snmpNotifyFilterSubtree matches the variable's object identifier.

    d. A match occurs if the variable's OID is within or equal to the filter subtree, considering the snmpNotifyFilterMask if specified.

    e. If a match is found:

    • If snmpNotifyFilterType is included(1), continue checking other variables.
    • If snmpNotifyFilterType is excluded(2), do not send the notification to this management target.

    f. If no match is found for a variable after checking all filter entries, do not send the notification.

  6. If all variable-bindings pass the filter, send the notification to the management target.

Filter Mask Semantics​

The snmpNotifyFilterMask object provides bit-level control over subtree matching. It is a bit mask with the following semantics:

  • Each octet in the mask corresponds to a sub-identifier in the filter subtree OID.
  • Each bit in an octet corresponds to a bit in the sub-identifier.
  • If a bit in the mask is 1, the corresponding bit in the sub-identifier must match the variable's OID.
  • If a bit in the mask is 0, the corresponding bit in the sub-identifier is ignored (wildcard).

A zero-length mask (the default) means all sub-identifiers must match exactly.

Example Mask Usage:​

Filter Subtree: 1.3.6.1.2.1.2.2.1.8
Mask: 0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFE

This mask allows matching of both 1.3.6.1.2.1.2.2.1.8 (ifOperStatus) and 1.3.6.1.2.1.2.2.1.9 (ifLastChange), because the last bit of the final sub-identifier is wildcarded.

Configuration Examples​

Example 1: Sending All Notifications to a Management Target​

To send all notifications to a management target without filtering:

  1. Do not create an entry in the snmpNotifyFilterProfileTable for the target's parameter name.

OR

  1. Create a filter profile with a single inclusive filter:
    • snmpNotifyFilterSubtree: 1 (or any root OID)
    • snmpNotifyFilterMask: "" (empty)
    • snmpNotifyFilterType: included(1)

To send only notifications related to interfaces (ifTable):

snmpNotifyFilterProfileTable Entry:

  • snmpNotifyFilterProfileName: "interfaceFilter"
  • Associated with target parameters name: "stationAParams"

snmpNotifyFilterTable Entries:

Entry 1:

  • snmpNotifyFilterProfileName: "interfaceFilter"
  • snmpNotifyFilterSubtree: 1.3.6.1.2.1.2
  • snmpNotifyFilterMask: ""
  • snmpNotifyFilterType: included(1)

This configuration allows notifications containing variables from the interfaces group (1.3.6.1.2.1.2) to be sent, while filtering out all other notifications.

Example 3: Excluding Specific Notifications​

To send all notifications except those related to the TCP connection table:

snmpNotifyFilterProfileTable Entry:

  • snmpNotifyFilterProfileName: "noTcpConnections"
  • Associated with target parameters name: "stationBParams"

snmpNotifyFilterTable Entries:

Entry 1:

  • snmpNotifyFilterProfileName: "noTcpConnections"
  • snmpNotifyFilterSubtree: 1
  • snmpNotifyFilterMask: ""
  • snmpNotifyFilterType: included(1)

Entry 2:

  • snmpNotifyFilterProfileName: "noTcpConnections"
  • snmpNotifyFilterSubtree: 1.3.6.1.2.1.6.13
  • snmpNotifyFilterMask: ""
  • snmpNotifyFilterType: excluded(2)

This configuration includes all notifications (Entry 1), but explicitly excludes those containing variables from the tcpConnTable (Entry 2).

Implementation Considerations​

Performance​

Notification filtering requires OID comparisons for each variable-binding against potentially multiple filter entries. Implementations should optimize this process:

  • Use efficient data structures (e.g., tries or hash tables) for OID lookups.
  • Cache filter profile lookups for frequently used management targets.
  • Consider pre-compiling filter rules at configuration time.

Filter Order​

Filter entries are processed in lexicographical order of their indices. This means:

  • More specific (longer OID) exclusions should be configured appropriately relative to broader inclusions.
  • The order of filter entries can affect the outcome of filtering.

Default Behavior​

If no filter profile exists for a target's parameters:

  • The default behavior is to send the notification (no filtering).
  • This ensures backward compatibility with systems that do not use notification filtering.

Variable-Binding Requirements​

RFC 3416 requires that notifications include at least two variable-bindings:

  1. sysUpTime.0
  2. snmpTrapOID.0

These mandatory variable-bindings must pass the filter for the notification to be sent. If the filter excludes these OIDs, the notification will not be sent to that management target.

Security Considerations​

Notification filtering can impact security in several ways:

  1. Information Disclosure Prevention: Filtering can prevent sensitive information from being sent to unauthorized management stations.

  2. Configuration Protection: The filter configuration tables (snmpNotifyFilterProfileTable and snmpNotifyFilterTable) should be protected by access control to prevent unauthorized modification.

  3. Filter Bypass: Improper filter configuration (e.g., overly broad inclusion rules) can allow unintended notifications to be sent.

  4. Denial of Service: Overly complex filter rules can consume excessive processing resources, potentially causing a denial of service.

It is recommended to use notification filtering in conjunction with proper access control (such as VACM) and SNMPv3 security features to ensure comprehensive security.

Last updated on