Use Regular Expressions to Refine the Set of Events That Trigger a Policy

You can more precisely define which events trigger an event policy by using regular expression matching.

You can use regular expression matching to more precisely control which events trigger an event policy. When you define an event policy, you specify the events that trigger the policy. Many events have one or more attributes that provide details about each specific event, for example, an interface name, a port number, or an error code. You can define an event policy that references an event's attributes and triggers only if the attribute value matches some specified regular expression.

To match an event attribute against a regular expression, include the matches statement at the [edit event-options policy policy-name attributes-match] hierarchy level. Specify the event and the attribute to evaluate. The referenced event must be either the trigger event or a correlating event included in the event policy’s within statement. Then define the regular expression that the attribute value must match to trigger the policy.

When you specify the regular expression, use the notation defined in POSIX Standard 1003.2 for extended (modern) UNIX regular expressions. Table 1 outlines some of the regular expression operators that you can use in the matches statement. In the descriptions, term refers to either a single alphanumeric character or a set of characters enclosed in square brackets, parentheses, or braces.

Note:

The matches statement is not case-sensitive.

Table 1: Regular Expression Operators for the matches Statement
Operator	Matches
. (period)	One instance of any character.
* (asterisk)	Zero or more instances of the immediately preceding term.
+ (plus sign)	One or more instances of the immediately preceding term.
? (question mark)	Zero or one instance of the immediately preceding term.
\| (pipe)	One of the terms that appear on either side of the pipe operator.
! (exclamation point)	Any string except the one specified by the expression, when the exclamation point appears at the start of the expression. Use of the exclamation point is specific to Junos OS.
^ (caret)	The start of a line, when the caret appears outside square brackets. One instance of any character that does not follow it within square brackets, when the caret is the first character inside square brackets.
$ (dollar sign)	The end of a line.
`[ ]` (paired square brackets)	One instance of one of the enclosed alphanumeric characters. To indicate a range of characters, use a hyphen ( `-` ) to separate the beginning and ending characters of the range. For example, `[a-z0-9]` matches any letter or number.
`( )` (paired parentheses)	One instance of the evaluated value of the enclosed term. Parentheses are used to indicate the order of evaluation in the regular expression.

Note:

To test your regular expressions within a test environment, you can use the Junos logger utility to simulate an event notification with the appropriate attributes and message. For more information, see Junos Logger Utility.

Explaining regular expression syntax is beyond the scope of this document. For some additional information, see Regular Expressions.

Examples: Controlling Event Policy Using a Regular Expression

In the following example, the event policy triggers if an SNMP_TRAP_LINK_DOWN event occurs within 120 seconds of an SNMP_TRAP_LINK_UP event. However, the event policy only triggers if the interface-name attribute in both traps match each other and the interface-name attribute in the SNMP_TRAP_LINK_DOWN trap starts with letter g. Thus, the event policy triggers only for ge-* interface events. The policy does not trigger when the eventd process receives traps from other interfaces.

Note:

In system log files, the message tags appear in all uppercase letters. In the CLI, the message tags appear in all lowercase letters.

The following example slightly modifies the previous event policy. The policy still only triggers if the interface-name attribute in both traps match each other. However, in this case, the interface-name attribute in the SNMP_TRAP_LINK_DOWN must not start with ge-0/0. Thus the event policy would trigger for interface names ge-0/1/0 and xe-0/2/0 but would not trigger for ge-0/0/0, ge-0/0/1, and so on.