Paragon Insights Tagging

Policy

A policy is the top-level element in a tagging profile. You can add multiple policies within a single tagging profile. Multiple policies that exist within a tagging profile can have their own rules and terms.

Usage Notes:

• Defining multiple policies within a single profile allows you to define terms for each rule in one profile rather than having to create one profile for each rule.

Rules

A rule is any defined Paragon Insights rule. The rule element type in a tagging profile is a list element. You can apply a specific policy profile to the rule(s) ([rule1, rule2]) included within the tagging profile.

Usage Notes:

You can describe the topic-name/rule-name requirement for the rules element in the following ways:

• To name specific rules within a tagging profile, use the form: topic-name/rule-name.

  For example, protocol.bgp/check-bgp-advertised-routes. Navigate to Configuration>Rules to view configured rules.

• Use an asterisk (*) with no other value or brackets to match all rules.

• Use python-based fnmatch patterns to select all rules within a specific topic. For example, line-cards/*.

  For more information, see fnmatch — Unix filename pattern matching.

Terms

The term section of the tagging profile is where the match conditions are set and examined, and actions based on those matches are set and carried out. Set the conditions for a match in a when statement. Set the actions to be carried out upon completing a match in one or more then statements.

Usage Notes:

• Each term can contain a when statement but it is not mandatory.

• Each term must contain at least one then statement.

• Multiple terms can be set within a single policy.

• Terms are processed sequentially from top to bottom until a match is found. If a match is found, processing stops after completing the statements found in the then section. Other terms, if present, are not processed unless the next flag is enabled within the matched term. If the matched term has the next flag enabled, then subsequent terms are processed in order.

When Statements

When statements define the match conditions that you specify. When statements ultimately resolve to be true or false. You can define a term without a when statement. This equates to a default term wherein the match is assumed true and the subsequent then statement is carried out. Conversely, multiple conditions can be checked within one when statement.

If one or more of the conditions set forth in a when statement are not met, the statement is false and the term has failed to match; processing moves to the next term, if present.

Usage Notes:

When statements perform boolean operations on the received data to determine if it matches the criteria you set. The supported operations are:

• Numeric Operations:

  • equal-to

  • not-equal-to

  • greater-than

  • greater-than-or-equal-to

  • less-than

  • less-than-or-equal-to

• String Operations:

  • matches-with

  • does-not-match-with

• Time Operations:

  • matches-with-scheduler

  Note:

  The matches-with-scheduler option requires that a discreet scheduler be configured in the Administration > Ingest Settings > Scheduler page. The name of the scheduler can then be used in the matches-with-scheduler when statement

• Go Language Expressions:

  • eval <simple-go-expression>

  For example: eval a + b <= c.

Then Statements

Then statements implement the tagging instructions that you provide. This is done only after there is a complete match of the conditions set forth in a when statement contained in the same term. Each term defined must have at least one then statement. Each then statement must have one or more than one action(s) defined; the actions available in then statements are:

Usage Notes:

• You can set the next flag to true within a then statement. When this flag is set to true, the next term in the policy gets evaluated if all of the conditions of the current term match.

Example Configuration: Elements of a Tagging Profile

Paragon Insights configuration elements are displayed as pseudo-config. This configuration resembles the hierarchical method used by Junos OS.

Elements of a Tagging Profile shows how tagging profile elements are named and how they are related to each other.

Elements of a Tagging Profile

Sample Static Tagging Configuration

In this sample static tagging configuration, the lack of a when statement means that any device that this tagging profile is applied to will have the field tenant-id assigned with the value tenant1. The fields and values defined in this profile are assigned to all rules that are applied to a device or device-group because of the * in the rules parameter.

You can also create a static tagging profile from the Paragon Insights graphical user interface (GUI). Navigate to Configuration > Sensor > Settings > Tagging Profile page to create a tagging profile.

Application Identification

Table 1 shows an example application identification scenario based on source-port, destination-port, and protocol of traffic seen in a NetFlow stream.

To create the derived-application field as given in Table 1 from the received data (data under source-port, destination port, and protocol), you must use a tagging profile definition that looks like this:

Benefits of Dynamic Tagging

• Values stored in Redis database are current and dynamic.

• Redis database can be used as a cache memory to store real-time data.

Understanding Redis Database and Dynamic Tagging Configurations

Understanding Redis Database and Dynamic Tagging Configurations

• Key structure is <Device-group-name>:<device-id>::key-name__network:<network-group-name>::key-name , where :: is the key separator.

  Example key structures:

  • Device Group

    Syntax:

    <Device-group-name>:<device-id>::key-name

    Example:

    Device GroupCore:r1::/components/

  • Network Group

    Syntax:

    __network:<network-group-name>::key-name

    Example:

    network::net_check::topic/rule

• Values are stored in JSON string format <json dump as string> in Redis. However, values are provided in string, integer, and float formats.

  Example value formats:

  • Core:r1::/components/= value1

  • Core:r1::/components/='{“key1”: value1, “key2”: value2}’

  • Core:r1::/components/='{“key1”: {“key2”: value1, “key3”: value2}’

  • Core:r1::/components/='{“key1”: {“key2”: ‘[list of values]’, “key3”: value1}’

• • Sample tagging-profile configurations using when statement.

  • Use a . operator between interfaces.

    In the following example, key3 interface is nested within key2 interface in the right operand.

• • Sample tagging-profile configurations using then statement.

  • Use a . operator between interfaces.

    In the following example, key3 interface is nested within key2 interface in the right operand.

• Using exist operator in configurations.

  • Using exist as key.

    Redis Data Structure

    tagging-profile Using when Statement

  • Using exist as value in list.

    Redis Data Structure

    tagging-profile Using when Statement

• Using $ in then statements.

  When you use $<field-name> within a Redis key, $<field-name> is replaced with a value from the already processed database value.

  As an example, consider that ge-1/0/2 is present within Redis key.

  Redis Data Structure

  Example tagging -profile

  In this scenario, the tagging-profile checks if $interface-name is present in the Redis database, and if key1 value for the given interface name is greater than 30. If the statement is true, the tagging-profile fetches key2 value from name field. In this example tagging profile, the name value is interface-meta-data.

• To enable dynamic tagging, set in-memory value to true.

  By default in-memory value is set to false.