Audit

Investigate the network state, search through configurations, and monitor device behavior without impacting the live environment, with the Audit module.

Compliance

The Compliance module checks that the operational state of your devices meets your requirements. You describe a requirement as a rule, Avalon runs it on the selected devices and produces a compliance report, which can be scheduled and tracked over time.

A rule is built visually by connecting blocks. It never changes the configuration: compliance is read-only.

Overview

List of compliance rules with their latest result and available actions.

The Compliance Rules page lists your rules; create one with New rule. Each rule offers these actions:

• Edit (pencil): open the rule in the builder.
• Trend: show the rule's compliance trend over time.
• Duplicate: duplicate the rule to adapt it.
• Run: launch the audit on a selection of devices.
• Delete: remove the rule.

Below, the Reports panel keeps the run history. Each report offers Show (detailed view), PDF and Excel export, and deletion; Delete all clears the whole history.

The rule builder

A rule is a directed graph: data flows along the links, from the sources (left) to the assertions (right). As soon as a block is connected to an upstream block, it automatically receives its output and transforms it according to its role. You run nothing manually: Avalon walks the graph in order at audit time.

Composing a rule: sources on the left, assertions on the right.

Each block has a specific role:

Block	Role
Source	Where the data comes from: a gathering template (read from the device, connection required) or a source from the Avalon database (Device, Device Ports), with no connection.
Scope	Restricts the devices audited according to their inventory attributes (model, version, device type...). Scopes are evaluated first: an out-of-scope device is skipped without a connection (when the inventory is enough to determine it) and does not count toward the compliance rates.
Filter	Restricts the rows of a source based on a field value (e.g., keep only trunk ports).
Join	Merges two sources on a common field (e.g., interface) to cross their columns.
Assertion	The requirement to check: a field, an operator, a value and a Quantifier.
Display	Chooses the columns shown in the report.

Connecting blocks

Each block type accepts a defined number of inputs, and some are mandatory for a rule to be valid:

Block	Inputs	Output	Mandatory
Source	None (starting point)	Yes	Yes, at least one
Scope	One	No	No (none, one or several)
Filter	One	Yes	No
Join	Two or more	Yes	No (only to cross sources)
Assertion	One	No	Yes, at least one
Display	One	No	No

• A single Source can feed several downstream blocks: the same dataset then serves several branches (e.g., a trust source checked by two different assertions).
• Scope, Filter, Assertion and Display accept only one input: a second link to the same block is rejected.
• You can (and should, if needed) place several Scope blocks. A device must satisfy all scopes to enter the perimeter (logical AND): handy to combine criteria, for example a specific model and a given device type.
• A Scope has no output: a Source (optionally filtered) feeds it and its branch ends there. It only selects the audited devices; it is therefore never linked to a Join or an Assertion, which have their own sources.
• A Join is only useful when you cross at least two sources on a common field.

Assertion and Quantifier

The assertion applies to the rows reaching it. The Quantifier defines the success rule:

• ALL: every row must satisfy the condition.
• EXISTS: at least one row must satisfy it.
• NONE: no row must satisfy it.

Data sources

Three families of sources are available:

• Gathering templates: data read from the device via a gathering template (Switchports, VLANs, NAC, DHCP Snooping, DAI, MAC Address Table, Hardware...). Collection requires a connection to the device. The full list and field details are on the Data gathering templates page.
• Device: one row per device from the inventory (hostname, model, version, device type...). No connection required, so this source can serve as a scope.
• Device Ports: one row per port from the inventory. Notably exposes the is_managed_uplink field: true for trunk ports (l2_8021q) connected to a managed switch that is upstream (toward the core) or on a horizontal link. Aggregates are reported under the name of their aggregation interface.

Field origin

In the selectors, each field shows its source in parentheses (e.g., Trust State (DAI Trust)) so you know where the checked attribute comes from.

Operators

Operator	Meaning
EQUALS / NOT_EQUALS	Equal / different (case-insensitive).
CONTAINS / NOT_CONTAINS	The found value includes / does not include what is specified (e.g., a trunk's VLANs include 10).
CONTAINS_ALL / CONTAINS_ANY	The found value includes all / at least one of the values in the list. Multi-value version of CONTAINS, tokenized for VLAN lists (handles ranges like 10-12).
IN / NOT_IN	The found value belongs / does not belong to the provided list (e.g., an access port's VLAN is 10 or 20).
MATCHES / NOT_MATCHES	Matches / does not match a regular expression (e.g., an IP starting with 192.168.254 or 192.168.255 → 192.168.25[4,5]).
EXISTS / NOT_EXISTS	The field is set / empty (or, with a value, present / absent on the device).

Checking a VLAN list

To validate that a list (e.g., snooping_vlans) covers a set of VLANs, use CONTAINS_ALL with the tenant VLANs. CONTAINS only tests a substring and would give a false positive (e.g., 10 found in 100).

Joins and missing items

A Join crosses two sources (or more) on a common field (e.g., interface). Current behavior:

• If one branch is filtered (e.g., the uplinks from Device Ports filtered on is_managed_uplink), it defines the tested set. The other sources graft onto it on the key: their columns are added where the key matches, left empty otherwise. A key present only in an unfiltered source is ignored.
• If no branch is filtered, only the keys present in all sources are kept (intersection).

So an uplink without trust keeps its row with an empty trust column: the trusted == yes assertion fails and it comes out non-compliant.

Scheduling, reports and trend

• Scheduling: a rule can run periodically and send a summary email (SMTP configuration must be done beforehand).
• Reports: each run produces a report you can view, exportable to PDF and Excel. The report documents the rule as audited (definition frozen at run time) and presents the results per assertion, with the compliance rate per device and global.
• Trend: compliance evolution is tracked over time since the rule's first report.

Compliance report: rule definition and global summary.

Results per device and detail per assertion.

Use case: DHCP snooping and Dynamic ARP Inspection (DAI)

Goal: verify that trust is set on the right ports (the links to other switches) and that snooping and DAI cover the user VLANs. A single rule carries both features, through several assertions.

The complete rule: uplink trust and VLAN coverage, for both snooping and DAI.

1. Trust is on the right ports

1. Source Device Ports.
2. Filter: is_managed_uplink EQUALS true (keeps only upstream and horizontal links).
3. Join on interface with DHCP Snooping Trust and DAI Trust.
4. Two assertions (Quantifier ALL): trusted EQUALS yes and trust_state EQUALS Trusted.

2. Snooping and DAI cover the declared VLANs

1. Source DHCP Snooping → assertion snooping_vlans CONTAINS_ALL [tenant VLANs].
2. Source DAI → assertion dai_vlans CONTAINS_ALL [tenant VLANs].

(Quantifier ALL for both.)

A misconfigured trust port comes out as Non-compliant, a compliant device as Compliant.

Link aggregates

Trust applies to the aggregate. Avalon automatically reports the physical member ports under the name of their aggregation interface, both on the ports side and on the device output side, so the join lines up.

Data gathering

Retrieve operational state data (non-configuration data) from your devices in real-time. Generate network-wide reports: MAC address tables, CDP neighbors, VLANs, interface counters, etc.

Data collection

Data gathering interface with filters and report history.

The collection form lets you configure your query:

1. Data: Select one or more data types to collect (e.g., Switchports, MAC Address Table, NAC).
2. Sites: Select the sites to query.
3. Quick select devices: Quick selection by device type.
4. Devices: Fine-grained selection of individual devices.
5. Send results to: (Optional) Select one or more recipients to receive the report by email. SMTP configuration must be done beforehand.
6. Report mode: The report grouping mode (Per service or Per device).
7. Fetch data: Launches the collection on the selected devices.

Reports

Each collection generates a report available in the Reports section. A report contains:

• Report ID: Unique report identifier.
• Inventory: Number of devices and services queried.
• Start time: Launch date and time, with execution duration.
• Status: Collection result (success, error).

Available actions:

• Show results: Displays the detailed report results.
• Export: Downloads the data in CSV/Excel format.
• Delete: Removes the report from history.

Results visualization

Report results with filtering and pagination.

The Results section offers two perspectives to analyze the data. Toggle between them using the Services and Devices buttons:

• Services: Groups data by collection type. Ideal for global audits (e.g., "all VLAN interfaces across the entire site").
• Devices: Groups data by device. Ideal for targeted checks on a specific device.

A Pattern field lets you filter the displayed results.

Available gathering templates

Avalon ships a set of templates (VLANs, Switchports, MAC Address Table, Hardware, NAC, DHCP Snooping, DAI...), usable here for collection as well as in Compliance rules.

Each template and its columns are detailed on the Data gathering templates page.

Explore configurations

Search for specific configuration lines across hundreds of backup files without opening them individually.

Usage

• Pattern: Enter a text string or Regex (e.g., telnet, password 7, 192.168.1.1).
• Scope: Select the sites or device types to search.

Searching for 'telnet' usage across the site configuration backups.

Results

The table displays the match status for each device.

• Pattern match: Shows whether the string was found.
• Download: You can download the specific configuration file directly from this view.

Compare configurations

The Compare tool provides a visual "Diff" between two configuration files.

Usage

• Change Validation: Compare the running-config of a device at two different dates (e.g., "Before" vs "After" maintenance).
• Standardization: Compare the configurations of two similar devices (e.g., ACCESS-1-1a vs ACCESS-1-1b).

Visual comparison highlighting additions (green) and deletions (red).

Visual indicators

• Green Lines present in the right file but missing in the left (Additions).
• Red Lines present in the left file but missing in the right (Deletions).

Devices logs

This section provides a centralized interface to search through Syslog messages exported by devices to Avalon.

Usage

You can narrow down the search using:

• Pattern: Keyword search (e.g., link-flap, OSPF, user-login).
• Time Window: Start date and End date.
• Scope: Specific Sites or Devices.

Historical view of syslog messages matching a specific pattern.

Mail alerts

While Devices logs is for historical investigation, Mail alerts allows for proactive monitoring. You can configure Avalon to send an email notification immediately when a specific log pattern is detected.

Creating an alert

1. Alert Type: Currently supports Device Logs.
2. Alert name: A descriptive name for the alert.
3. Recipient / Send to: Select the email address to notify.
4. Pattern: The Regex or string to watch for (e.g., root, fan fail).
5. Devices to watch: Define which devices to monitor.

Configuring a proactive alert for STP Topology changes.

Email example

When triggered, the email provides the context required for troubleshooting: the Device IP, the matched pattern, and the raw log line.

Mail triggered by STP Root change.