Juniper Apstra Config Rendering

Introduction

Juniper Apstra creates configurations for devices that are managed by Apstra. This document explains the different configurations that Juniper Apstra renders based on the state of Apstra-managed devices. This document explains config rendering as it relates to the typical lifecycle of a network device within an Apstra-managed topology. For more information about an Apstra-managed device's configuration lifecycle, see Device Configuration Lifecycle.

AOS Device Lifecycle

The AOS Device Lifecycle diagram illustrates the progression of a network device managed by Juniper Apstra. It begins with a 'Factory Default Cfg', followed by 'Add Pre-AOS Mgmt Cfg', then 'Factory + Pre-AOS Mgmt Cfg', and finally 'Install AOS Device Agent' leading to 'Pristine Cfg [OOS Quarantine]'. After acknowledging the device, it enters 'AOS Discovery-1 Cfg [OOS - READY]' or 'AOS Discovery-1 Cfg [OOS - DECOMM]'. Devices can be assigned or unassigned to a Blueprint. The lifecycle branches into 'IN SERVICE (IS) - READY' and 'IN SERVICE (IS) - ACTIVE' states. In the 'IN SERVICE (IS) - READY' state, devices are in 'AOS Discovery-1 Cfg' or 'AOS Discovery-2 Cfg', with deploy modes such as 'Undeploy' or 'Ready'. In the 'IN SERVICE (IS) - ACTIVE' state, devices are in 'AOS Service Cfg' with deploy mode 'Deploy', allowing 'Commit Cfg Diff / Rollback'. The diagram also indicates states like 'OOS - MAINT' and 'IS - MAINT'. A note clarifies that when the device admin state is set to 'MAINT', the device state becomes either 'IN SERVICE (IS) - MAINT' or 'OUT OF SERVICE (OOS) - MAINT', but the device configuration remains unchanged.

Pre-Agent Install

Factory Default Config

The Factory Default config is the configuration on the device when it boots for the first time after being removed from the original shipping container (before you connected it to the network). All of this config's settings are the default settings from the vendor for the installed OS version.

User-Required Config

Operators must configure devices before they are available for configuration by Juniper Apstra. This can be accomplished with the following methods:

• ZTP automated boot script
• Manual configuration via console port

You can use either method, but an IP address must be added to the Ethernet management port before the Apstra agent is installed. Admins typically set the following options before proceeding:

• Management IP Address
• Management Default Gateway
• Change default username/password (optional for some platforms)
• Add trusted keys to device for remote access (optional)
• Add trusted IPs or subnets for remote access (optional)
• Disable services according to security requirements (optional)

Post-Agent Install

Pristine Configuration

When you install an onbox agent on a device (or an offbox agent on the server), the device connects and registers with Juniper Apstra in the Quarantined state. Depending on the vendor and agent type, Juniper Apstra applies partial configuration to the pre-Apstra configuration. This configuration is called Pristine configuration. Pristine configuration is the basis for all subsequent device configuration.

If the enable_push_quarantine_config variable is enabled in the aos.conf file, the following changes are made to devices:

• All fabric ports are shut down when a device is onboarded.

The Pristine configuration is not validated; it is accepted by Juniper Apstra without inspection. Validation is implicit for this configuration because Apstra assumes the pristine configuration is correct and we are importing it from the device. Note that errors in the Pristine configuration might cause significant problems on the device's lifecycle.

NOTE: When you install an agent on a device, any configuration that was already there becomes part of the Pristine Config, which means it's included in the device's entire configuration lifecycle. Any corrections that you make will be service-impacting.

Items that are usually set in the pristine configuration include:

• Banner
• Tacacs AAA settings
• TCAM settings
• Logging settings
• Other configuration to enable 3rd party monitoring.

The Pristine configuration is also used for all Full configuration pushes from Apstra. Apstra combines the Pristine configuration and the Apstra-generated configuration to create a Full configuration that is deployed to the switch.

Before the Apstra 4.2 release, adding a new configuration item to the Pristine config after a device is in operation, (day2 operations) required the device to be removed from the Apstra System and re-imported. In the AOS 4.2 and subsequent releases, changes to the pristine configuration can be done while a switch is in the Blueprint.

Discovery-1 (Acknowledge Device)

When you acknowledge a device, you're putting it in the Ready state and acknowledging it in the Apstra UI. This acknowledgment signals to Apstra that you want Apstra to manage the device. As a result, Apstra adds a minimal base configuration (Discovery-1) to the Pristine config. This base config, or Discovery-1, is essential to Apstra agent operation and applies a complete configuration (Full config push), which overwrites all exisiting configuration to ensure config integrity. This config push does the following:

• All interfaces are rendered with interface speeds for the assigned device profile
• All interfaces are no shutdown to allow you to view LLDP neighbor information
• All interfaces are moved to L3 mode (default) to prevent the device from participating in the fabric.

NOTE: Devices that have been acknowledged cannot simply be deleted. Since the device would still have an active agent installed, the devices would re-appear within seconds. To remove a device from Apstra management, see Remove (Decommission) Device from Managed Devices for the complete workflow.

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.

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.

A visual comparison highlights configuration differences. The 'Intended running configuration' section shows configuration lines for system settings, hostname, and root authentication. The 'Actual running configuration' section includes similar system settings but also details 'scripts' with an 'op' file and 'enable-chassis-beacon.slax'. It is labeled as 'Manual Config' and provides options to 'Apply Full Config' and 'Accept Changes'. A warning symbol indicates 'Actual config deviated from golden config'.

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.

Managing Differences Between Service Configuration and the Golden Configuration

Maintenance Operations

Drain/Undrain

Apstra allows the operator to gracefully drain traffic off a device in the fabric without impacting existing TCP flows. Configuration changes in this state include:

• Route-maps inbound/outbound for L3 neighbors
• L2 Server facing ports are shutdown
• MLAG/ESI peer ports are shutdown

For L2 Servers:

• MLAG peer-links port channels and bond interfaces on any NOS are not changed.
• For Arista EOS, Cisco NX-OS, all interfaces towards L2 servers in the blueprint are shutdown.

For Network L3 Switches:

The device uses Inbound/Outbound route-maps with 'deny' statements to prevent advertisements to 0.0.0.0/0 le 32. This ensures uninterrupted L3 TCP flows. TCP sessions re-establish after a few seconds, or negotiate a new TCP port. The new TCP port prompts the devices to be routed onto a fresh ECMP path from the available links. Since no ECMP routes are available in the presence of a route map, traffic bypasses the device in Drain mode. The device is drained of traffic and can be safely removed from the fabric by switching Deploy mode to Undeploy.

During the draining process of TCP sessions (which may take some time, particularly in EVPN scenarios), you can expect BGP anomalies. These anomalies are temporary however, and are resolved after configuration deployment completes.

Switching the deploy mode to Drain on a device can also affect the configuration of neighboring devices. For example, when a spine device is drained, the configuration of all connected leaf devices changes. Neighboring leaf devices employ Inbound/Outbound route filters (route-maps) with 'reject (deny)' statements to prevent advertisements to 0.0.0.0/0 le 32, for both EVPN (overlay) and FABRIC (underlay).

Similarly, when you drain a leaf device, the configuration on connected spine devices changes. Neighboring spine devices use Inbound/Outbound route filters (route-maps) 'reject (deny)' statements to block any advertisements to 0.0.0.0/0 le 32, for both EVPN (overlay) and FABRIC (underlay).

In the case of an MLAG-based topology, in addition to the configuration on connected spine devices changing, the configuration on the paired leaf device also changes.

Undeploy

Undeploying a device removes the complete service configuration. These devices still have their service config enabled but anomalies are suppressed as the device is likely about to be taken offline by the operator. If the traffic is present on the device, we recommend that you put it in Drain mode (and commit the change) before setting it to Undeploy.

RELATED DOCUMENTATION

Deploy Modes