Leaving Prime without adopting the Catalyst Center model

The model comes before the configuration

Prime worked with configuration templates: you wrote the template, you pushed it to the devices you chose. The logic was yours.

Catalyst Center starts from the other end. Its documentation is explicit: you must create at least one site before you can provision, and assigning a device to a site determines the settings, credentials and policies applied to it. Your network therefore has to be described in the platform hierarchy, sites, buildings and floors, before the first automated configuration goes out.

That approach is coherent, and genuinely useful on a network designed from scratch. It does assume modelling work up front, and it commits you to describing your infrastructure according to a model that is not your own.

Avalon imposes no hierarchy and no operating process. You keep your own structure, your conventions and your change procedures. The platform aligns with your architecture, and you and your integrator remain its authors.

Engineering rules rather than templates

This is the clearest difference from what you did under Prime. A template is static: it describes a configuration, and you decide where to apply it. An engineering rule describes an intent and the conditions under which it applies, based on filters over device model, interface type, VLANs, addresses or port names.

In practice this changes how a cross-cutting technology is rolled out. Network access control is the best example: rather than working through a template port by port, you express a rule that makes deployment conditional on the operational state observed, and it applies across the whole relevant estate in minutes.

The same mechanism serves VLAN propagation along a chain of switches, a port profile, or a composite service chaining several operations across different devices.

Modelling the whole path, up to the firewall

An estate that historically ran Prime is usually overwhelmingly Cisco, and multi-vendor support can look like a theoretical concern. It is not, because a network service does not stop at the access switch.

Opening a service for a new use means touching the access port, the transport links, and the perimeter security. The firewall, however, is rarely the same brand as the switches. Avalon models that path end to end, firewall included, and deploys the service across the whole switching and routing part of it, rather than stopping at the edge of one vendor catalogue.

• Cisco Catalyst on IOS and Nexus on NX-OS
• Aruba CX, standalone as well as VSX and VSF
• HP Comware and HP ProCurve
• Huawei VRP, including stacks and virtual chassis
• Hirschmann for industrial networks
• Palo Alto and Stormshield firewalls, recognised and placed on the map

Not seeing yours? Support for a new vendor usually takes five to ten days of development and is handled case by case. Tell us which one.

What the platform costs, before any licence

Catalyst Center now installs as a virtual machine, on ESXi or on AWS, rather than only on a hardware appliance. The resources it asks for are still those of an appliance: the Cisco deployment guide requires 32 vCPUs and 256 GB of memory, reserved and dedicated to the virtual machine, along with 3 TB of SSD sustaining 2,000 to 2,500 IOPS with write latency under 5 milliseconds.

Avalon consumes 4 vCPUs, 8 GB of memory and 160 GB of disk. The appliance boots in a few minutes, and discovering an estate of several hundred devices is measured in hours rather than weeks.

Pairing Catalyst Center with an external source of truth gets close to that flexibility. It is then an integration project in its own right: skills to hire or rent, a second tool to keep current, and a maintenance cost that never stops. That is exactly the work Avalon saves you.