Juniper NETWORKS Apstra Managed Devices User Guide

: June 23, 2024
: JUNIPER NETWORKS

Table of Contents

Apstra Managed Devices
Specifications
Product Information
Product Usage Instructions
Pre-Agent Install
Post-Agent Install
Device Added to Blueprint
- FAQ
When is the configuration pushed?
What is in Discovery-1 Config?
What is in service config?

Apstra Managed Devices

Specifications

Product: Juniper Apstra Config Rendering
Published: 2024-05-29

Product Information

The Juniper Apstra Config Rendering product is designed to
manage device configurations and ensure consistency between service
configuration and the golden configuration. It allows for easy
installation of agents on devices and provides a way to handle
differences in configurations effectively.

Product Usage Instructions

Pre-Agent Install

Factory Default Config: The Factory Default
config is the initial configuration when the device boots for the
first time. It contains default settings from the vendor.

User-Required Config: After the Factory Default
config, the admin initiates the Apstra Device Agent installation
either via the Apstra Server or through a ZTP boot script.

Post-Agent Install

Pristine Configuration: Any existing
configuration on the device becomes part of the Pristine Config
after installing an agent. Correcting configurations in this stage
can impact services.

Discovery-1 (Acknowledge Device): Acknowledging
a device prevents simple deletion. To remove a device from Apstra
management, follow the complete workflow.

Device Added to Blueprint

Discovery-2 (Assign Device): This step assigns
the device to a blueprint, selectively activating L2/L3
services.

Golden Configuration: After each successful
config deploy, the running config is stored internally as the
Golden configuration. Any deviation between the running rendered
config and the golden config is flagged as an anomaly on the
dashboard.

FAQ

When is the configuration pushed?

The configuration is pushed after each successful
deployment.

What is in Discovery-1 Config?

The goal of Discovery-1 Config is to enable auto-discovery
without affecting switching in routed mode.

What is in service config?

The service config puts the device into service and enables
cabling validation before deploying the service config.

Juniper Apstra Config Rendering
Published
2024-05-29

ii
Table of Contents
Introduction Pre-Agent Install Post-Agent Install Device Added to Blueprint Managing Differences Between Service Configuration and the Golden Configuration

1
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. The image below illustrates a typical lifeycle flow. For more information about an Apstra-managed device’s configuration lifecycle, see Device Configuration Lifecycle.

2
Pre-Agent Install
IN THIS SECTION Factory Default Config | 2 User-Required Config | 2
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 user 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)

3
After this is completed, the admin initiates the Apstra Device Agent installation either via the Apstra Server or through the previous ZTP boot script.
Post-Agent Install
IN THIS SECTION Pristine Configuration | 3 Discovery-1 (Acknowledge Device) | 4
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

4
· 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 reimported. 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.

5
Device Added to Blueprint
IN THIS SECTION Discovery-2 (Assign Device) | 5 Golden Configuration | 6

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 Device is allocated to blueprint not deployed

6

When is it pushed?

· Device connected to Apstra

· Ready for Service

· 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)

· 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

· 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

Goal: Enable cabling validation before deploying service config to the device

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:

7 · 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.
Managing Differences Between Service Configuration and the Golden Configuration
IN THIS SECTION Maintenance Operations | 8 Drain/Undrain | 8 Undeploy | 9

8
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).

9 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
Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered marks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. Copyright © 2024 Juniper Networks, Inc. All rights reserved.