Blueprint operations in Juniper Apstra are essential for managing, monitoring, and updating a deployed network. This phase ensures that the network remains aligned with its design intent while addressing real-time operational needs.
Blueprint operations are built around three primary functions: change management, troubleshooting, and monitoring and alerts.
Change management involves making updates or modifications to the network, such as adding new resources or adjusting policies. These changes are made directly in the blueprint and propagated to the devices.
Blueprint operations make troubleshooting easier by providing a comprehensive view of the network and its current state. Issues such as misconfigurations, link failures, or performance degradation can be quickly identified and resolved.
Monitoring and alerting are critical for maintaining the health and performance of the network. Apstra continuously tracks key metrics and notifies you of deviations from the intended state.
Updating the blueprint allows you to adapt the network to changing requirements without disrupting service. This includes adding resources, modifying policies, or making structural changes.
When new devices or links are added to the network, the blueprint must be updated to reflect these changes.
Network policies such as access control lists (ACLs), routing rules, or tenant isolation policies may need updates over time.
Situation:
Steps to Handle This Using Blueprint Operations:
Situation:
Steps:
Situation:
Steps:
Check VLAN-to-VNI Mapping:
Validate BGP EVPN Routes:
Check that the tenant’s MAC/IP routes are advertised correctly using:
show bgp evpn
Inspect VXLAN Tunnels:
Verify that VXLAN tunnels are up between leaf switches acting as VTEPs.
show evpn vtep
Resolve Issues:
Troubleshooting in Juniper Apstra is streamlined through its centralized blueprint and telemetry capabilities. Here’s a systematic workflow for addressing common issues:
Logical Map:
Configuration Review:
Check the configurations generated by the blueprint for potential misconfigurations.
show configuration
Examine real-time metrics, such as:
Interface Status: Check for link failures or misconfigured interfaces.
Routing Table: Validate that routes are advertised correctly.
show route
Traffic Data: Look for unusual bandwidth usage or congestion.
A new compliance rule requires:
Monitoring in Apstra provides continuous visibility into your network’s performance and health. The following techniques ensure proactive management and early detection of issues.
Telemetry is the backbone of monitoring in Apstra, providing up-to-date metrics and status information.
Interface Health:
Device Status:
Traffic Flow:
The alerting system in Apstra notifies you of potential issues before they escalate into major problems.
Apstra provides customizable dashboards to visualize your network’s performance and health.
View the health and status of devices in the blueprint:
show device status
Ensure that BGP sessions and EVPN advertisements are working correctly:
show bgp summary
show bgp evpn
Check the status of VXLAN tunnels and verify endpoint reachability:
show evpn vtep
Monitor interface bandwidth, errors, and utilization:
show interfaces statistics
Validate routing configurations and identify missing routes:
show route
show route vrf <VRF_NAME>
Produce detailed reports on network health, resource allocation, and device configurations:
show blueprint report
Blueprint operations are designed to make troubleshooting intuitive and efficient. Below are common issues and how to resolve them.
Symptoms:
Steps to Resolve:
Check Peer Connectivity:
Verify that spine and leaf devices can reach each other.
Use:
ping <PEER_IP>
Inspect BGP Configuration:
Ensure ASNs and peer IPs are correctly configured.
show configuration protocols bgp
Review Interface Status:
Symptoms:
Steps to Resolve:
Verify VTEP Configuration:
Ensure VXLAN tunnel endpoints are configured correctly.
show evpn vtep
Check VLAN-to-VNI Mapping:
Validate EVPN Advertisements:
Symptoms:
Steps to Resolve:
Inspect Interface Metrics:
Check for high utilization or errors on specific interfaces.
show interfaces statistics
Review Traffic Flows:
Test Alternate Paths:
Apstra treats each change to a blueprint as a versioned snapshot of the network’s intent. These snapshots can be viewed, compared, audited, and even rolled back.
| Feature | Description |
|---|---|
| Time Voyager | A built-in version control system for tracking and managing blueprint states |
| Diff Comparison | Allows users to compare any two versions to see granular configuration changes |
| Rollback Action | Reverts the blueprint to a previous valid version and redeploys the intent |
A misconfigured ACL breaks inter-VXLAN routing between two tenants.
Using Time Voyager, an operator:
Reviews the diff between the current and previous versions.
Identifies the incorrect change.
Clicks Rollback, and Apstra auto-generates the reverse configuration for redeployment.
You may encounter questions like:
“Which feature in Apstra allows users to audit, compare, and revert blueprint changes?”
Correct answer: Time Voyager.
In multi-tenant environments, services like DNS, DHCP, NAT, or firewall appliances often need to be shared across tenants without compromising isolation.
| Strategy | Description |
|---|---|
| Shared Services VRF | Create a dedicated VRF to host shared services; tenants route selectively to it |
| Inter-VRF Route Leaking | Enable controlled route export/import between tenant VRFs and shared VRF |
| Service Nodes in Blueprint | Define external service devices (e.g., DNS, NAT) as part of the blueprint fabric |
VRF-TenantA and VRF-TenantB require access to a central DNS server.
Create VRF-Shared and configure policy-based routing or static route leaking to allow DNS queries.
Use Apstra’s blueprint policies to automate VNI and next-hop mappings.
This must be declared during blueprint design so that overlay routing policies and ACLs are pre-defined.
Apstra generates event-driven logs for all blueprint-related actions and system-detected anomalies.
| Type of Event | Examples |
|---|---|
| Change Logs | Deployment history, policy updates, user-triggered changes |
| System Events | BGP session down, interface flaps, VXLAN tunnel loss |
| Intent Deviations | Detected mismatches between blueprint and actual device configuration |
Blueprint Dashboard → Events Tab
API endpoint: /api/blueprints/<blueprint-id>/events
Exportable in JSON or syslog format
Intent drift occurs when the actual state of the network no longer matches the defined blueprint intent.
Apstra uses real-time validation checks and intent-based rules to identify drift conditions.
| Drift Type | Trigger | Suggested Remediation |
|---|---|---|
| Missing VXLAN configuration | VNI missing on one leaf | Apstra flags and suggests template reapply |
| Route missing in VRF | BGP EVPN route not imported | Suggests checking policy-export configuration |
| Unauthorized config change | CLI edit made outside Apstra | Highlights conflict and offers overwrite |
Some drift conditions can be auto-resolved via “Reapply Intent” button.
Others require operator review and confirmation.
All drift events are timestamped and auditable.
| Enhancement Area | Description |
|---|---|
| Version Control & Rollback | Time Voyager enables version diff, audit history, and rollback capability |
| Multi-Tenant Service Coordination | Shared service VRFs and route leaking strategies for tenant-to-service traffic |
| Event Logging | Real-time, exportable logs for configuration, deployment, and anomaly tracking |
| Intent Drift Detection | Automated detection of configuration inconsistencies with guided remediation suggestions |
Can a blueprint be modified after the fabric has already been deployed?
Yes, a blueprint can be modified after deployment, and Apstra will automatically generate and apply the necessary configuration changes to the fabric.
One of the advantages of Apstra’s intent-based model is that the blueprint remains the authoritative design throughout the lifecycle of the network.
Administrators can modify the blueprint to:
Add new racks or switches
Change routing policies
Modify tenant connectivity
Adjust network services
When the blueprint is updated, Apstra recalculates the configuration changes required for each device. These changes can then be deployed to the fabric in a controlled manner.
Because the blueprint drives all configurations, the network can evolve without requiring manual configuration changes on individual devices.
Demand Score: 76
Exam Relevance Score: 90
How does Apstra ensure the running network remains consistent with the blueprint?
Apstra continuously compares telemetry and operational state from network devices with the blueprint’s intended configuration.
Apstra performs continuous validation, which means the system constantly monitors the operational state of the network.
The process involves:
Collecting telemetry and operational data from switches
Comparing the current network state with the blueprint model
Identifying mismatches or policy violations
Alerting administrators or suggesting corrective actions
Examples of inconsistencies include:
Incorrect routing configurations
Missing VXLAN tunnels
Device configuration drift
This validation mechanism ensures the network remains aligned with the defined intent and helps operators quickly detect operational problems.
Demand Score: 72
Exam Relevance Score: 92
What is configuration drift and how does Apstra handle it?
Configuration drift occurs when device configurations differ from the intended blueprint design, and Apstra detects it through continuous validation.
Configuration drift often happens when manual changes are applied directly to devices using the CLI.
In traditional networks, these changes can remain undetected for long periods. Apstra prevents this by constantly validating device state against the blueprint.
If drift is detected, Apstra can:
Flag the issue as an intent violation
Identify the affected device or configuration element
Provide visibility into the discrepancy
Operators can then decide whether to restore the intended configuration or modify the blueprint to reflect a new design requirement.
Demand Score: 70
Exam Relevance Score: 89
Why should administrators avoid making manual CLI changes on Apstra-managed devices?
Manual CLI changes can create configuration drift and cause the network state to deviate from the blueprint.
Apstra is designed to operate using an intent-driven model, where the blueprint defines the authoritative network configuration.
If administrators manually modify switch configurations using the CLI:
The changes may not match the blueprint
Apstra will detect them as intent violations
Future deployments could overwrite the manual changes
Instead of modifying devices directly, administrators should update the blueprint so that Apstra can generate and deploy the correct configuration.
This approach maintains consistency across the fabric and prevents operational conflicts.
Demand Score: 68
Exam Relevance Score: 88