Device Added to Blueprint

Discovery-2 (Assign Device)

When you assign a device to a blueprint and set its Deploy Mode to Ready, you're putting it in the Ready (Discovery 2) state. The device is staged, but not yet committed (deployed) to the active blueprint. Ready config applies a complete configuration (Full config push) to ensure config integrity. Ready configuration brings up network interfaces and configures interface descriptions and validates telemetry, such as LLDP, to ensure it's properly wired and configured. This configuration is non-disruptive to other services in the fabric. Links are up, but they are configured in L3-mode to prevent STP/L2 operations.

The table below shows Discovery-1 through Service Config, with L2/L3 services being selectively activated.

Discovery-1 (Acknowledge Device) config	Discovery-2 (Assign Device) config	Service config
Device is ready to be managed by Apstra	Device is allocated to blueprint but not deployed	Device is allocated to blueprint
When is it pushed? Device connected to Apstra Ready for Service Not allocated to Blueprint What is in Discovery-1 Config? All ports up in routed mode & at default speeds No BGP configuration LLDP is enabled on the device Goal: Enable auto-discovery (up) but do not affect switching (routed mode)	When is it pushed? Device connected to Apstra Ready for service Allocated to blueprint Device's deploy mode is “ready” What is in Discovery-2 config? All ports up in routed mode & at speed/breakout as defined in blueprint interface descriptions Hostname No BGP configuration Goal: Enable cabling validation before deploying service config to the device	When is it pushed? Device connected to Apstra Ready for service Allocated to blueprint, device’s deploy mode is “deploy” What is in service config? All ports up in routed mode & at speed/breakout as defined in blueprint Hostname configuration BGP configuration Goal: Put device into service

Golden Configuration

After each successful config deploy, the running config is collected and stored internally as the Golden configuration.

The Rendered config is the generated configuration from the staged blueprint. Any difference between the actual running rendered config and the golden config results in a config deviation anomaly on the blueprint's dashboard. The golden config is updated every time a config push is successfully applied to a device.

The golden config is the configuration on the device after the last successful config application. In certain special circumstances, users can modify a configuration directly on device and tell Apstra to absorb this deviation as Golden. This is not recommended for any part of the device that Apstra directly modifies. We strongly recommend that you use configlets to manage these customizations. It’s important to note, accepting config changes is not persistent.

Key points:

• Each successful configuration deployment results in an updated Golden Config.
• If configuration deployment fails, Golden Config is not set. This means both a config deviation and deployment failure anomaly are raised.
• Running configuration telemetry is continuously collected and matched against the Golden Config. Any difference result in a deviation anomaly.
• Configuration anomalies can be 'suppressed' using the "Accept Changes feature". This does NOT mean the change is added to golden config or Intent.

The Golden configuration is the basis for Apstra to ensure that the device is in acceptable state, according to the established intent. This synchronization is enforced via a monitor that runs once every 60s on the device.