JN0-480 Apstra Build and Deploy Phases

Apstra Build and Deploy Phases Detailed Explanation

The Build and Deploy Phases in Juniper Apstra take your design blueprint and transform it into a live, operational network. These phases involve generating configurations, assigning resources, deploying them to devices, and validating the deployment.

4.1 Build Phase: Translating Design into Configurations

Overview of the Build Phase

• The build phase focuses on preparing all configurations and resources necessary to deploy the network. It converts the logical design from the blueprint into physical, device-specific configurations.

Key Steps in the Build Phase

1. Configuration Generation

• What Happens:

  • Apstra automatically generates the configurations for each device based on the validated blueprint.

• What’s Included:

  • BGP Configurations:
    • Defines BGP sessions for spine-leaf communication.
    • Configures route reflectors (typically spines) to simplify BGP peering.
  • EVPN:
    • Configures the EVPN control plane for VXLAN.
    • Distributes MAC and IP address information across the fabric.
  • VLANs and VXLANs:
    • Maps VLANs to VXLAN VNIs for tenant isolation.
  • IP Addressing:
    • Assigns IP addresses for underlay routing (spine-leaf links) and overlay subnets (tenant traffic).

• Example Configuration for a Leaf Switch:

  set interfaces lo0 unit 0 family inet address 192.168.1.1/32
  set interfaces xe-0/0/0 unit 0 family inet address 10.0.0.1/31
  set protocols bgp group EVPN type internal
  set protocols bgp group EVPN peer-as 65000
  set protocols bgp group EVPN family evpn signaling
  

2. Device Role Assignment

• What Happens:
  • Each physical device is mapped to a logical role defined in the blueprint (e.g., Spine, Leaf).
• Why It’s Important:
  • Ensures that the configurations match the specific responsibilities of each device.
• Example:
  • Spine switches handle route reflection and inter-leaf communication.
  • Leaf switches connect to servers and spines.

3. Resource Allocation

• What Happens:

  • Apstra assigns critical network resources like VLAN IDs, VXLAN VNIs, and Autonomous System Numbers (ASNs).

• Example:

  • VLAN 10 → VNI 1000.
  • ASN 65001 is assigned to all leaf switches.

• Benefits:

  • Prevents resource conflicts.
  • Simplifies network expansion by pre-allocating unused resources.

Validation During Build

1. Pre-deployment Checks

• What Happens:
  • Ensures that the design blueprint is compatible with the physical devices.
• What’s Validated:
  • Device hardware and software compatibility.
  • Proper allocation of IP addresses, VLANs, and VNIs.

2. Design-to-Build Consistency

• What Happens:
  • Verifies that the generated configurations align with the intent defined in the blueprint.
• Example:
  • VLAN 10 is consistently mapped to VNI 1000 across all devices.

4.2 Deploy Phase: Applying Configurations to Devices

Overview of the Deploy Phase

The deploy phase focuses on applying the generated configurations to devices, ensuring the network becomes operational. This includes pushing configurations, validating device states, and performing post-deployment testing.

Key Steps in the Deploy Phase

1. Configuration Push

• What Happens:

  • Apstra pushes the configurations generated during the build phase to devices using automation tools like APIs or CLI.

• How It Works:

  • Each device receives only the configurations relevant to its role (e.g., spine, leaf).
  • Devices are configured with minimal manual intervention.

• Example:

  • Leaf1 receives its configuration:

    set interfaces xe-0/0/0 unit 0 family inet address 192.168.1.2/31
    set protocols bgp group EVPN type internal
    set routing-instances VXLAN-10 vlan-id 10
    

2. Device Validation

• What Happens:

  • Apstra verifies that all devices are in the correct state after the configurations are applied.

• What’s Validated:

  • Routing Adjacencies:
    • Ensures that BGP sessions are established between spines and leaves.
  • Interface States:
    • Confirms that all relevant interfaces are operational.

• Example:

  • Use the following command to check BGP sessions:

    show bgp summary
    

3. Post-deployment Testing

• What Happens:
  • Apstra performs end-to-end testing to ensure the network is functioning as intended.
• Tests Include:
  • Connectivity Tests:
    • Pinging devices or endpoints in different VXLAN segments.
  • Traffic Isolation Tests:
    • Simulating traffic between tenants to confirm isolation.

Validation During Deploy

1. Continuous State Comparison

• What Happens:
  • Apstra continuously compares the actual network state with the intended state defined in the blueprint.
• What’s Detected:
  • Configuration mismatches.
  • Device or link failures.

2. Telemetry and Monitoring

• What Happens:
  • Apstra collects real-time data from devices to detect anomalies.
• Example:
  • Interface down events or abnormal latency.

Advantages of Apstra Build and Deploy Phases

1. Automation-Driven:

   • Reduces the time and effort required to configure devices.
   • Minimizes human errors by automating complex configurations.

2. Real-Time Feedback:

   • Immediate validation ensures that issues are detected and resolved during deployment.

3. Scalable:

   • Handles complex environments, including multi-vendor networks, with ease.

4.3 Practical Example: From Build to Deployment

Scenario

You are setting up a network with:

• 2 spines and 4 leaves.
• VXLAN for tenant isolation.
• BGP EVPN for routing.

Build Phase

1. Configuration Generation:
   • Generate configurations for all spines and leaves.
   • Assign:
     • VLAN 10 → VNI 1000.
     • IP addressing: 192.168.1.0/31 for spine-leaf links.
2. Device Role Assignment:
   • Spine1 and Spine2 → Route reflectors.
   • Leaf1 to Leaf4 → VXLAN VTEPs.
3. Validation:
   • Check for resource conflicts (e.g., overlapping IPs).

Deploy Phase

1. Push Configurations:

   • Apply configurations to all devices.
   • Example: Use Apstra’s API to push configurations to Leaf1.

2. Validation:

   • Verify BGP sessions and VXLAN tunnels.
   • Test connectivity between tenants.

3. Post-deployment Testing:

   • Simulate link failures to test redundancy.

Apstra Build and Deploy Phases (Additional Content)

1. Rollback & Remediation

Overview

Juniper Apstra provides built-in rollback and remediation capabilities to ensure safe, reliable deployments—even in the face of partial failures.

Key Capabilities

• Automatic Rollback:

  • If a deployment fails due to errors (e.g., device timeout, config rejection), Apstra can automatically roll back to the last known good configuration state.

• Manual Rollback:

  • Operators can manually trigger a rollback using the GUI or API by selecting a previous deployment snapshot (via the Time Voyager feature).

When Is Rollback Triggered?

Scenario	Response
Device unreachable during push	Deployment halted and config reverted on reachable devices
Intent mismatch detected post-push	Remediation flagged; optional rollback prompted
Operator cancels deployment mid-way	Partial changes are undone (if rollback enabled)

Exam Focus

Sample Question Format:
"What happens when a blueprint deployment fails due to a misconfigured interface on one leaf device?"

Correct answer should reflect rollback capability or deployment halt with remediation options.

2. Deployment Modes: Full vs Staged Deployment

Deployment Strategies in Apstra

Juniper Apstra supports two key deployment approaches:

Mode	Description
Full Deployment	Pushes the entire blueprint to all devices in a single operation
Staged Deployment	Allows deployment in phases (e.g., one tenant, one rack, or one region at a time)

Why Use Staged Deployment?

• Gradual onboarding of multi-tenant environments

• Rolling updates to production networks

• Testing in lab or edge fabric before full rollout

Staging Methods

• Per-device or per-rack staging using blueprint deployment options

• Per-role staging (e.g., deploy all spines, then leaves)

• Controlled via GUI or REST API (e.g., using PATCH operations)

Pro Tip: In real environments, staged deployments reduce blast radius and simplify rollback paths.

3. Multi-Vendor Handling During Deployment

Why It Matters

In real-world data centers, devices often come from multiple vendors. Apstra abstracts vendor differences during build and deploy via intent-based abstraction.

How Apstra Handles It

Element	Multi-vendor Strategy
Device Profiles	Define vendor-specific syntax and capabilities (e.g., Junos vs EOS)
Template Engine	Generates appropriate CLI/config per device OS (e.g., Juniper, Cisco, Arista)
Transport Methods	Communicates via vendor-supported protocols (NETCONF, REST, SSH)

Example

If one leaf is a Juniper QFX5120 and another is an Arista 7050:

• Apstra uses a common intent blueprint for both.

• It translates this into:

  • Junos CLI for QFX.

  • EOS CLI or eAPI calls for Arista.

Exam Insight: Questions may ask how Apstra supports multi-vendor fabric deployment. Correct answers should reference vendor abstraction or device profile translation.

4. Error Handling & Deployment Logs

Deployment Error Detection

Apstra actively validates and monitors deployment success using several mechanisms:

Error Type	Detection Method
Configuration Mismatch	Detected via intent comparison before and after deployment
Protocol Session Failures	Detected via telemetry and validation rules (e.g., BGP down)
CLI Syntax Rejection	Detected from device API/CLI response parsing

Logging and Reporting Tools

Tool or Format	Function
Deployment Logs (JSON)	Per-device deployment actions and results (viewable via UI/API)
Intent Mismatch Reports	Highlights discrepancies between expected vs actual state
Telemetry Alerts	Real-time feedback on failed sessions, interface flaps, etc.
Audit Trail (Time Voyager)	Tracks who made what changes and when

Common Logging Locations

• GUI: “Deploy Logs” tab within blueprint view

• API: /api/blueprints/<id>/deployments/<deployment-id>/logs

• CLI-integrated environments (for example via Ansible)

Summary of Key Enhancements for Build & Deploy Phase

Area	Enhancement
Rollback & Remediation	Automatic/manual rollback on failed deployment, rollback logic explanation
Deployment Modes	Full vs staged deployment for tenant onboarding and partial rollout
Multi-vendor Handling	CLI abstraction via device profiles and cross-platform support
Error Reporting & Logs	Intent mismatch detection, JSON logs, telemetry events, audit trail support