From Configuration Fidelity to YAML Bloat
When prefix filters were implemented in netlab 1.9.0, the data model was designed to resemble the resulting device configurations as closely as possible. That included using one matching prefix per entry, reflecting the individual sequence numbers found in device configurations.
This close correspondence made generated results easier to relate to the source model. It also came with a practical cost: every matching prefix required several lines of YAML. As policies grew, the lab definition accumulated repetitive entries that were harder to read and maintain.
The issue became even more apparent when applying the same design philosophy to access-control lists. A single logical operation such as “port not in range” has to be represented by multiple ACL entries on most platforms. Once one source entry could expand into several device-level entries, maintaining a strict one-to-one relationship with configuration sequence numbers was no longer realistic.
Why Prefix Sets Improve the Model
The initial netlab ACL implementation already accepted lists of prefixes and expanded them into individual ACL entries. Prefix sets build on the same underlying idea: describe related prefixes together instead of repeating them throughout the YAML model.
This separation is useful because it distinguishes two concerns:
Policy intent: which prefixes belong to a logical group.
Device rendering: how each platform translates that group into ordered ACL or prefix-filter entries.
For engineers maintaining multi-vendor labs, the result is a cleaner source of truth. A shared group can be changed in one place rather than edited repeatedly across multiple rules or filters.
Benefits for Multi-Vendor Testing
Prefix sets are particularly valuable when the same addressing policy must be validated on several platforms. Vendors may render ACLs and route filters differently, but the intended prefix membership should remain consistent.
A less repetitive model helps teams:
Reuse the same logical prefix group in ACL and routing-policy scenarios.
Reduce copy-and-paste errors in large YAML definitions.
Review policy intent without first navigating numerous generated entries.
Update test scenarios when an address block is added or removed.
Focus comparisons on vendor-specific rendering rather than duplicated input data.
This abstraction does not remove the need to inspect generated configurations. Entry order and platform-specific expansion still matter, especially when one logical expression becomes multiple device entries. Prefix sets simply make the test definition easier to maintain while netlab handles the expansion.
A Practical Testing Workflow
A disciplined workflow can keep abstraction from hiding important behavior:
Define prefixes according to their policy purpose rather than the syntax of one vendor.
Reuse those groups in the relevant ACL and route-filter tests.
Generate configurations for every target platform.
Inspect the expanded entries and their ordering.
Run the lab tests before promoting equivalent changes to production.
The important shift is that the YAML model captures intent, while generated configurations expose the implementation details that must still be validated.
Where ConnectMyAssets Fits
netlab prefix sets improve how engineers model and test multi-vendor policy. ConnectMyAssets addresses the operational side after those policies reach managed infrastructure.
Its Backup & History module records configuration versions and supports one-click rollback, helping teams compare changes and recover from an unwanted result. The Compliance Engine can assess managed configurations against organizational and regulatory requirements, while Automation & ZTP supports controlled execution of standardized network changes.
The Dynamic CMDB provides current asset context, and Firewall Management helps operators manage firewall policy across the environment. Because ConnectMyAssets is vendor-agnostic and deployed on premises, these capabilities can support multi-vendor operations without changing the value of lab-based validation.
There is no implied integration between netlab and ConnectMyAssets. They address complementary stages: netlab helps simplify and test the intended model, while ConnectMyAssets helps manage, track, and govern configurations on operational infrastructure.
Source: ipSpace.net
