UIM 20.3 - nas 9.31 changes in regular expression matching criteria
search cancel

UIM 20.3 - nas 9.31 changes in regular expression matching criteria

book

Article ID: 202285

calendar_today

Updated On:

Products

DX Unified Infrastructure Management (Nimsoft / UIM)

Issue/Introduction

Nas 9.31 has introduced some changes in the way strings are matched using Regular Expressions (Regex).

In Versions of NAS < 9.31 the regex was based on string matching, so not strictly following regex. 

From NAS 9.31 the regex patterns must follow the regex rules for matching. 

 

Example:

In NAS version < 9.31 If we want to match for example a subsys id like: 3.1.2.1.4 (but we do not want to match 3.1.2.14) we could use the following matching string:

 

sid = 1.4.1.1.*

 

As seen below:

 

3.1.2.1.4 is matched: (this can be verified using F2 validator:

NAS 9.30:

 

but 3.1.2.1.14 NOT matched:

NAS 9.30:

 

 

 

This is no longer occurring in NAS 9.31 as  with the regex:

 

sid = 1.4.1.1.*

 

Also 3.1.2.1.14 is matched. 

 

 

Environment

Release : 20.3

Component : UIM NAS

Cause

Change to Pattern matching to Regular Expression starting nas 9.31

 

 

 

•  NAS 9.30 or earlier uses pattern matching

•  NAS 9.31 and later uses REGEX + nas 9.31 has a DEFECT(DE482613)  (that will be fixed in a future rlease) where it matches all alarms if regex pattern error string is configured. For this issue check this KB 

Resolution

In nas 9.31 the regex matching respects REGEX.

 

If for example you configure a regex as

sid = 3.1.2.1.*

 

This will mean that 

"3.1.2.1"  +  ".*"

 

".*" Means to match any characters any numbers of time so it is expected that 3.1.2.14 matches. 

 

This can be verified by validating the matching criteria:

In the nas by pressing F2:

 

Or on any regex online validator:

https://regex101.com/

 

 

If you'd like to match any subsys id like the following:

 

3.1.2.1.3

3.1.2.1.4

3.1.2.1.5

3.1.2.1.6

 

and so on.. you will have to "escape" the dot (".") to match the exact character:

 

So modify your regex as below:

 

3.1.2.1\.*

 

 

with the above mentioned regex,  3.1.2.14 and  3.1.2.15 won't be matched anymore. 

 

instead 3.1.2.1.5 and 3.1.2.1.3 etc., yes, they will be. 

 

 

 

This behaviour is being resolved in NAS 9.32HF1:

CAUIM HOTFIX Repository

nas 9.32 HF1

Solution Document: LU00962

  • Component: UNIFIED INFRASTRUCTURE MGMT
  • Release: 20.3.3
  • Hiper: NO
  • Operating System: MULTI-PLATFORM
  • Status: CONFIRMED
  • Distribution Code: AVAILABLE
  • Opened Date: 04/16/2021
  • Closed Date: 04/16/2021
 

 

Applicable for: UIM 20.3 (nas 9.31) and UIM 20.3.3 (nas 9.32)

Issues Fixed:
=============

1. UIM 20.3 - nas 9.31 changes in pattern/regular expression matching behavior

Reason: Prior to nas 9.31 (i.e. nas 9.30 or below), nas supported pattern/regex matching. With nas 9.31 we started supporting regular expressions only.

Resolution: With this hotfix, we provide a configuration parameter which will allow to select either both pattern/regex matching or only regular expressions matching. The below configuration parameter is provided:
Key used:
Configuration - Raw config under setup
UseRegexOnly = no (default, both pattern/regex matching)
             = yes (regex matching only)

Additional details:
- UseRegexOnly = no (default, both pattern/regex matching) 
Behavior similar to nas 9.30 and below

REGEX MATCHING:
If the pattern is starting and ending with a DELIMITER / (slash), it is treated as a true regular expression. Otherwise, it is treated as a pattern matching as described below.

PATTERN MATCHING:
The pattern matching mimics the below wildcard matching behavior. 
An asterisk (*)  matches one or more occurrences of any character, including no character.
Question mark (?)  represents or matches a single occurrence of any character.
Bracketed characters ([ ])  matches any occurrence of character enclosed in the square brackets.

Additionally, the tokens '/' '(' ')' and '.' in the pattern are treated as same character literally (not as pattern tokens) if they are not within [].

- UseRegexOnly = yes (regex matching only)
The expression is treated as a regular expression that is compliant with PCRE. It would be similar to expressions that can be checked with https://regex101.com/. The expectation is that the user provides only the regular expression without DELIMITER or FLAGS. Internally no flags are set.
For e.g. If you need to provide a regular expression you should not start and end with a delimiter like '/'.

If the regular expression is "file.*txt", you need to directly provide "file.*txt" but NOT "/file.*txt/" where / is a DELIMITER. This regular expression would match strings like "fil.txt", "fileeee.txt", "filxtxt", etc.

Regular expression validator in NAS UI will take only single regular expression as input for validation. Space and comma are NOT considered as seperators for providing multiple expressions.

Steps to apply the patch:
1. Import the zip into the local archive.
2. Deploy the imported package to the robot/hub.

Additional Information

Additionally to the change discussed in this KB, there currently is a defect in the probe where if a regex complication mistake is done, all alarms will be matched. 

If the regex string defined in the NAS contains an invalid REGEX format the nas will log the following: 

 

              Feb  8 12:06:07:690 [427596] 0 nas: Regex Issue : regex compilation error 
                Feb  8 12:06:07:690 [427596] 0 nas: _corrTriggerMatchAlarmPDS:: Regex Issue - regex compilation error 

 

And it will match ALL alarms for that rule

 

If you are facing this issue, please refer to the following KB:

UIM 20.3 - all alarms are matched by Nas auto-operator (AO) using regex
https://knowledge.broadcom.com/external/article?articleId=208066