Engineering rules¶

Engineering Rules represent the highest level of network automation in Avalon. They enable deployments conditioned by advanced filters, ensuring that configurations are applied only to devices or interfaces that meet specific technical criteria.

Rule composition & service orchestration¶

An Engineering Rule groups one or more services to be executed in sequence.

Empty Rule Container — Initializing a new rule before adding services.

Service selection & catalog¶

Avalon allows you to select from different types of services:

Avalon templates & Custom services: Management services provided by Avalon (User creation, RADIUS configuration etc.) and your own Jinja2 templates enabled for engineering rules.

Both types of services are mixed in the same selection interface and accessible by clicking the + Add service button

Native service provided by Avalon:¶

Native Service Selection — Accessing native Avalon templates like User or RadiusServer.

Custom service created by the user:¶

Custom Service Selection — Selecting a custom service.

In both cases, the service parameters must be filled in this window.

Warning

This means that it is not possible to configure different values for the same parameter (except for Interfaces type parameters).

Configured Services: Pre-configured services with predefined parameters.

Selecting Pre-configured Services — Choosing from existing pre-configured services.

In this case, the parameters have already been filled when creating the global service instance.

Instantiation and Parameters¶

When you select a service, you must define its parameters. You can group multiple services within the same rule.

Defining Parameters — Configuring specific parameters for a service within the rule.

Multi-service Parameters — A single rule managing multiple services and their respective parameters.

Drag & Drop¶

Services are executed top-down. You can reorder by dragging vertically to respect dependencies (e.g., create user before RADIUS assignment).

Ordering Services — Using drag-and-drop to define the execution priority.

Finalized Sequence — The finalized rule sequence ready for conditional deployment.

Multi-Rule Execution Priority¶

Avalon supports sequential execution of multiple rules. The order is vertical: the rule at the top executes first.

Rule Hierarchy — Orchestrating multiple rules for a bulk execution session.

By clicking Run, you select the target site and deployment mode (Dry Run or Deploy).

Bulk Rule Trigger — Configuring site-wide deployment for a group of rules.

The filtering engine¶

Conditions determine which device or interface will receive the configuration.

Database-Driven Logic¶

The filtering engine matches rules against the Avalon database, not against data retrieved in real-time.
It is important to schedule frequent Autodiscovery tasks to ensure the database accurately reflects the current network state.

Condition categories¶

Filters are organized into two categories:

Device: Targets hardware-level attributes (device model, global VLANs).
Interface: Targets port-specific attributes (interface name, type, configured VLAN).

Filter Categories — Selecting between device-level and interface-level filters.

Available device-level filters:

Device model - Filter based on the specific hardware model (e.g., Catalyst 9300, Nexus 9000)
VLAN on device - Target devices that have a specific VLAN configured

Available interface-level filters:

IP on interface - Match interfaces with specific IP addresses or subnets
VLAN on interface - Target interfaces associated with specific VLANs
Interface type - Filter by interface category:
- l2_access - Layer 2 access ports
- l2_8021q - Layer 2 trunk ports (802.1Q)
- l3_main - Layer 3 routed interfaces
- l3_subif - Layer 3 sub-interfaces
- svi - Switch Virtual Interfaces (VLAN interfaces)
Interface name - Match based on interface naming patterns (e.g., GigabitEthernet1/0/1)
Native VLAN - Target trunk interfaces with a specific native VLAN
Template name - Filter interfaces based on applied custom service templates

Custom interface types

Additional interface types can be added to Avalon upon request to match your specific network architecture requirements.

Operator reference¶

Avalon provides several matching operators. Each one exists in a NOT version (e.g., NOT EQUALS, NOT IN, NOT MATCHES).

Simple Operators:

EQUALS: Performs a strict equality match.
CONTAINS: Matches if the value found includes the specified string. E.g., a trunk port "contains" VLANs X and Y, even if other VLANs are also present.
IN: Matches if the value found is included in the provided list. E.g., verifying if an access port's VLAN is either X or Y.

Regex Operators:

MATCHES: Allows the use of Regular Expressions. E.g., to target a source interface with an IP starting with 192.168.254 or 192.168.255, the value might be: 192.168.25[4,5].

Simple Operators — Operators for standard equality and inclusion checks.

Regex Operators — Advanced pattern matching using regular expressions.

Practical example: port description update¶

In this scenario, we update the description of all Access ports configured on VLAN 10 or 20 within Building B1.

Step 1: Rule Configuration¶

The rule is defined with a service (LOOP_OVER_INTERFACES) and two matching conditions:

Interface type EQUALS l2_access.
VLAN on interface IN [10, 20].

Type Filter — Filtering for 'l2_access' port types.

VLAN Filter — Targeting specific user VLANs.

Final Logic — The finalized rule combining service parameters with interface filters.

Step 2: Scope Selection¶

When triggering the rule, we select Building B1 which contains access and aggregation switches.

Step 3: Dry Run¶

While triggering a dry run, Avalon identifies that only ACCESS-1-1a, ACCESS-1-1b, and ACCESS-1-2 contain ports matching these criteria.

Dry Run Summary — Identifying matching devices within the B1 perimeter.

Let's examine the results for ACCESS-1-1a

Dry Run Details — Reviewing the rendered configuration for the targeted interfaces.

Step 4: Build confidence¶

Using WebSSH, we verify that the ports retrieved by the dry run match our rule:

Initial State Check — Verifying the port status via CLI before deployment.

Step 5: Deployment and Final Verification¶

Once the service is deployed, a manual post-check via WebSSH confirms that the description has been correctly applied to the targeted interfaces. The complete audit trail for the execution is preserved in the Transaction History section.

Final State Check — Successful deployment confirmed via CLI post-check.

Execution History — Audit logs showing the success of all rule-generated transactions.

You can also check service deployment history in the approriate sub-section of the Inventory section.

In this example, we deployed a Custom Service so we need to navigate to Inventory / Network Services / Custom Services: