JN0-480 Apstra Design Phase

Apstra Design Phase Detailed Explanation

The design phase in Juniper Apstra is the cornerstone of building a reliable, scalable, and intent-driven network. It’s where you translate your business requirements into a detailed technical design using Apstra's blueprint framework. This section will take you through the steps, principles, and best practices in the design phase with clear explanations and examples.

3.1 Overview of the Design Phase

What Happens in the Design Phase?

The design phase is where you lay the groundwork for your data center network. This includes:

• Establishing the architecture (e.g., spine-leaf topology).
• Defining high-level business and technical goals (intent).
• Configuring logical elements like VLANs, VXLANs, and routing policies.
• Selecting physical hardware to implement the design.

Why Is the Design Phase Critical?

• Ensures Alignment with Business Goals: Helps achieve redundancy, scalability, and performance objectives.
• Simplifies Deployment: A well-designed blueprint automates much of the configuration and reduces errors.
• Supports Continuous Validation: Ensures that the deployed network matches the original intent.

Steps in the Design Phase

Step 1: Define Network Intent

Network intent is the high-level goal or outcome you want your network to achieve. Examples include:

1. Redundancy:
   • Ensure that no single device or link failure can disrupt the network.
   • Example: Dual-homed connections between leaf switches and servers.
2. Scalability:
   • Allow the network to grow as business demands increase.
   • Example: Modular spine-leaf design to add switches without redesigning the entire network.
3. Multi-Tenancy:
   • Support isolated environments for different tenants or applications.
   • Example: Use VXLAN to create logical segmentation for each tenant.

Step 2: Create a Blueprint

The blueprint is a logical representation of your data center network. It’s the central piece of Apstra's design phase.

1. Choose a Predefined Topology:

   • Select from common designs like Spine-Leaf.
   • Example:
     • 2 spine switches.
     • 4 leaf switches.
     • Servers connected to leaves.

2. Define Device Roles:

   • Assign roles like Spine, Leaf, or Access to each switch.
   • Example: In a spine-leaf topology:
     • Spine switches: Handle inter-leaf traffic.
     • Leaf switches: Connect to servers and spines.

3. Logical Network Configurations:

   • Configure key elements within the blueprint:
     • VLANs: Group devices within the same Layer 2 domain.
     • VXLANs: Extend Layer 2 domains across Layer 3 boundaries using unique VNIs.
     • VRFs (Virtual Routing and Forwarding): Isolate Layer 3 routing tables for multi-tenancy.

Step 3: Hardware Selection

Once the blueprint is defined, you assign actual devices to the design.

1. Physical Device Mapping:

   • Link logical devices in the blueprint to real physical switches and routers.
   • Example:
     • Spine1 → Switch Model X.
     • Leaf1 → Switch Model Y.

2. Interface Mapping:

   • Specify which physical ports are used for connections.
   • Example:
     • Port 1 on Leaf1 connects to Spine1.

Step 4: Validation

Before deployment, ensure that the design meets your intent.

1. Consistency Checks:

   • Validate that all devices in the blueprint are properly configured and connected.
   • Example:
     • Check if VLANs are consistently assigned across all switches.

2. Simulation:

   • Use Apstra’s tools to simulate traffic flows and identify potential bottlenecks.

3.2 Key Design Principles

The design phase should follow several principles to ensure a robust and scalable network:

1. Redundancy

Redundancy ensures that no single failure can disrupt the network. This involves:

1. Dual-Homed Connections:
   • Each server connects to two leaf switches for failover.
   • Example: If Leaf1 fails, traffic automatically switches to Leaf2.
2. Redundant Links:
   • Spine and leaf switches have multiple connections to ensure high availability.

2. Scalability

Design the network to support future growth without major reconfigurations.

1. Modular Design:
   • Use spine-leaf topology, where adding new leaves or spines increases capacity.
2. Addressing Scheme:
   • Plan IP addressing with future expansion in mind.
   • Example: Reserve extra subnets for future devices.

3. Policy Definition

Set policies during the design phase to simplify management and enhance security.

1. Access Control Lists (ACLs):
   • Define rules to control traffic flow and enhance security.
   • Example: Block unauthorized access between tenant networks.
2. Tenant Policies:
   • Isolate tenant networks using VRFs and VXLANs.
   • Example: Assign each tenant a unique VXLAN VNI.
3. Routing Policies:
   • Optimize routing by defining how traffic flows between devices.
   • Example: Use BGP EVPN for efficient route distribution.

Detailed Example Walkthrough

Scenario

You are designing a network for a small data center with the following requirements:

• Topology: Spine-leaf with 2 spines and 4 leaves.
• Redundancy: Each server is dual-homed to two leaf switches.
• Multi-Tenancy: Three tenants, each requiring isolated networks.

Step-by-Step Process

1. Define Intent:

   • High availability for critical workloads.
   • Logical isolation for tenants.

2. Create the Blueprint:

   • Topology:
     • Spines: Spine1, Spine2.
     • Leaves: Leaf1, Leaf2, Leaf3, Leaf4.
   • Device roles:
     • Assign Spine role to Spine1 and Spine2.
     • Assign Leaf role to Leaf1 through Leaf4.

3. Configure Logical Networks:

   • VLANs:
     • Tenant 1: VLAN 10.
     • Tenant 2: VLAN 20.
     • Tenant 3: VLAN 30.
   • VXLANs:
     • Map VLANs to VXLAN VNIs.
     • VLAN 10 → VNI 1000.
     • VLAN 20 → VNI 2000.
     • VLAN 30 → VNI 3000.
   • VRFs:
     • Create separate VRFs for each tenant.

4. Assign Hardware:

   • Map blueprint devices to physical hardware:
     • Spine1 → Switch Model A.
     • Leaf1 → Switch Model B.

5. Validate:

   • Check for consistency in VLAN and IP configurations.
   • Simulate tenant traffic to verify isolation.

3.3 Practical Example of Design Phase in Apstra

Scenario

A small-to-medium data center requires:

• Topology: 2 spines, 4 leaves.
• Tenant Isolation: 3 tenants, each with their own isolated network.
• High Availability: Servers must have dual connections to leaf switches for redundancy.
• VXLAN for Scalability: Use VXLAN to scale beyond VLAN limitations.

Step 1: Define Intent

Before starting the design, clearly define the intent of the network:

1. Redundancy:
   • Ensure no single point of failure in the network.
   • All servers are dual-homed to two leaf switches.
2. Scalability:
   • Use spine-leaf topology with VXLAN overlays to enable horizontal growth.
3. Tenant Isolation:
   • Assign unique VNIs for each tenant’s traffic to ensure logical segmentation.

Step 2: Create a Blueprint

1. Define Topology:

   • Select Spine-Leaf from Apstra’s predefined topology templates.
   • Specify the number of devices:
     • Spines: 2.
     • Leaves: 4.

2. Assign Device Roles:

   • Assign “Spine” role to Spine1 and Spine2.
   • Assign “Leaf” role to Leaf1 through Leaf4.

3. Logical Network Configurations:

   • VLANs:
     • Tenant 1: VLAN 10.
     • Tenant 2: VLAN 20.
     • Tenant 3: VLAN 30.
   • VXLANs:
     • VLAN 10 → VNI 1000.
     • VLAN 20 → VNI 2000.
     • VLAN 30 → VNI 3000.
   • VRFs:
     • Tenant 1: VRF-Tenant1.
     • Tenant 2: VRF-Tenant2.
     • Tenant 3: VRF-Tenant3.

4. Allocate IP Addressing:

   • Underlay: Assign IP ranges for spine-leaf interconnections.
     • Spine1 to Leaf1: 192.168.1.0/31.
     • Spine1 to Leaf2: 192.168.1.2/31.
   • Overlay: Assign unique subnets for each tenant.
     • Tenant 1: 10.1.1.0/24.
     • Tenant 2: 10.2.2.0/24.
     • Tenant 3: 10.3.3.0/24.

5. Policy Configuration:

   • Define tenant isolation policies in the blueprint.
   • Restrict inter-tenant communication using VRFs and ACLs.

Step 3: Hardware Selection

1. Device Mapping:

   • Map the blueprint’s logical devices to real physical switches:
     • Spine1 → Switch Model A.
     • Leaf1 → Switch Model B.

2. Interface Assignment:

   • Specify which physical ports will be used for interconnections:
     • Spine1 Port 1 → Leaf1 Port 1.

Step 4: Validate the Blueprint

1. Consistency Checks:
   • Ensure all VLANs and VXLANs are correctly mapped.
   • Example: VLAN 10 should map to VNI 1000 on all devices.
2. Simulation:
   • Simulate tenant traffic flows to confirm proper isolation.
   • Test failover scenarios by simulating link failures.

Step 5: Deploy

Once validated, the blueprint is ready for deployment. Apstra automatically pushes the configurations to devices.

3.4 Blueprint Validation

Blueprint validation is a critical step to ensure the design meets the intended goals before deployment. Juniper Apstra provides built-in tools to simplify this process.

Key Validation Features

1. Consistency Checking:

   • Verifies that all configurations in the blueprint are aligned.
   • Example: Ensures VLAN 10 is consistently mapped to VNI 1000 on all leaf switches.

2. Resource Validation:

   • Confirms that all required resources (e.g., IP addresses, VLAN IDs) are available.
   • Flags issues like overlapping IP subnets or missing VNIs.

3. Redundancy Validation:

   • Checks for redundant links and devices to ensure high availability.

4. Policy Compliance:

   • Validates that security and routing policies are applied correctly.

Practical Example of Validation

Scenario: Tenant 1’s traffic is not being properly isolated.

Steps to Validate:

1. Check VLAN-to-VNI Mapping:

   • Ensure that VLAN 10 is mapped to VNI 1000 across all devices.

   • Use the following command:

     show vlan mapping
     

2. Verify VRF Configuration:

   • Confirm that Tenant 1 is assigned to VRF-Tenant1.

   • Check route tables to ensure traffic is not leaking into other VRFs:

     show route vrf VRF-Tenant1
     

3. Simulate Traffic:

   • Generate traffic between two Tenant 1 devices to confirm isolation.
   • Apstra tools allow you to simulate flows directly within the dashboard.

3.5 Troubleshooting During the Design Phase

Even during the design phase, issues may arise. Here are some common problems and how to address them:

Problem 1: Overlapping IP Addressing

• Cause: Two subnets are accidentally assigned the same IP range.
• Solution:
  1. Review the IP allocation table in the blueprint.
  2. Assign unique subnets to each network segment.

Problem 2: Misconfigured VLANs

• Cause: VLANs are not consistently mapped across all devices.
• Solution:
  1. Validate VLAN configurations for each device in the blueprint.
  2. Correct any mismatched VLAN-to-VNI mappings.

Problem 3: Redundancy Gaps

• Cause: A device or link is missing from the redundant path.
• Solution:
  1. Use Apstra’s validation tools to identify missing connections.
  2. Update the blueprint to include the redundant paths.

3.6 Advanced Validation Techniques

Validation Categories

1. Resource Availability Validation:

   • Ensures that critical resources (IP addresses, VLANs, VNIs, and ASNs) are correctly allocated and have no conflicts.
   • Example:
     • Overlapping subnets between tenant VRFs.
     • VNI duplication across VXLAN segments.
   • Solution:
     • Use Apstra’s resource allocation report to detect conflicts.
     • Reallocate resources as needed.

2. Redundancy Testing:

   • Validates that redundant paths and devices are configured to handle failures.
   • Example:
     • Simulate a spine switch failure to ensure traffic reroutes via alternate paths.
   • Tools:
     • Use Apstra’s fault simulation feature to test failover scenarios.

3. Policy Compliance Checks:

   • Verifies that access control policies, tenant isolation rules, and routing configurations align with the intent.
   • Example:
     • Ensure tenant traffic does not cross VRFs unless explicitly allowed by a policy.

4. Underlay and Overlay Verification:

   • Underlay:
     • Checks IP connectivity between all spine and leaf switches.
     • Ensures proper routing protocol configurations (e.g., OSPF, BGP).
   • Overlay:
     • Verifies VXLAN tunnel integrity.
     • Confirms VLAN-to-VNI mappings are correct.

Automated Validation with Apstra

Juniper Apstra automates much of the validation process, reducing manual effort. Key tools include:

• Blueprint Health Check:
  • Provides a summary of inconsistencies or misconfigurations within the blueprint.
• Telemetry Dashboards:
  • Offers real-time insights into device states and traffic flows.
• Intent Assurance:
  • Compares the actual network state to the intended state and flags deviations.

3.7 Real-World Scenarios

Scenario 1: Designing a Multi-Tenant Network

Requirements:

• Three tenants (A, B, C) need isolated networks.
• Each tenant requires its own VRF and VXLAN segments.

Steps:

1. Create Logical Segmentation:

   • Tenant A: VLAN 100 → VNI 1000 → Subnet 10.1.1.0/24.
   • Tenant B: VLAN 200 → VNI 2000 → Subnet 10.2.2.0/24.
   • Tenant C: VLAN 300 → VNI 3000 → Subnet 10.3.3.0/24.

2. Apply Security Policies:

   • Block inter-tenant traffic by default using ACLs.
   • Allow specific communication between Tenant A and Tenant B if required.

3. Validate:

   • Simulate traffic between tenant devices to confirm isolation.

Scenario 2: Adding a New Leaf Switch

Requirements:

• Expand the existing network to accommodate more servers by adding a new leaf switch.

Steps:

1. Update the Blueprint:

   • Add the new leaf switch to the logical topology.
   • Assign a unique IP address for underlay routing.

2. Reallocate Resources:

   • Reserve additional VLANs and VXLAN VNIs for future workloads.

3. Validate:

   • Ensure the new leaf switch has proper connectivity with all spines.
   • Check if the configuration aligns with the intent.

Scenario 3: Troubleshooting Traffic Issues

Problem: Tenant B devices cannot communicate with each other.

Steps to Troubleshoot:

1. Verify VLAN-to-VNI Mapping:

   • Check that VLAN 200 is correctly mapped to VNI 2000 on all leaf switches.

   • Use the following command:

     show vlan mapping
     

2. Inspect VXLAN Tunnels:

   • Verify that the VXLAN tunnels are up and running between all VTEPs.

3. Check Routing Tables:

   • Ensure that the Tenant B subnet (10.2.2.0/24) is present in the routing table for all relevant devices:

     show route vrf VRF-TenantB
     

4. Resolve:

   • Correct any misconfigurations in the blueprint and reapply the changes.

3.8 Best Practices for Blueprint Design

1. Start with a Clear Intent

• Clearly define business and technical requirements before creating the blueprint.
• Examples:
  • "Ensure high availability for all critical applications."
  • "Support 10% growth in server capacity annually."

2. Use Modular Designs

• Design blueprints that can be easily updated or expanded.
• Example: Use spine-leaf topology to add new switches without major changes.

3. Reserve Resources

• Plan for future growth by reserving extra VLANs, VNIs, and IP addresses.

4. Validate Early and Often

• Use Apstra’s automated validation tools after every major change.
• Simulate common failure scenarios to ensure the network meets the intent.

5. Document the Blueprint

• Maintain clear documentation of the blueprint design for troubleshooting and training purposes.

3.9 Example: Full Blueprint Workflow

Objective:

Create a blueprint for a data center with:

• 2 spine switches, 4 leaf switches.
• Dual-homed servers.
• Isolated tenant networks using VXLAN.

Step-by-Step Workflow:

1. Intent Definition:

   • Ensure high availability and tenant isolation.

2. Blueprint Creation:

   • Topology: Spine-leaf with 2 spines, 4 leaves.
   • VLANs:
     • Tenant 1: VLAN 10, Subnet 10.1.1.0/24.
     • Tenant 2: VLAN 20, Subnet 10.2.2.0/24.
   • VNIs:
     • VLAN 10 → VNI 1000.
     • VLAN 20 → VNI 2000.

3. Resource Allocation:

   • IP ranges for spine-leaf connections: 192.168.1.0/31.
   • Underlay ASN: 65000.
   • Overlay BGP ASN: 65100.

4. Hardware Mapping:

   • Assign real devices to logical blueprint roles:
     • Spine1 → Switch Model A.
     • Leaf1 → Switch Model B.

5. Validation:

   • Check VLAN/VNI mappings.
   • Simulate tenant traffic to confirm isolation.

6. Deployment:

   • Push configurations to devices.
   • Use telemetry to monitor the network after deployment.

Apstra Design Phase (Additional Content)

1. Apstra Blueprint Template Types (Reference Designs)

Overview

Juniper Apstra provides predefined reference designs, also known as blueprint templates, which form the foundation for new data center fabrics.

Common Blueprint Types

Template Name	Description	Use Case
EVPN-VXLAN Spine-Leaf (L3 Clos)	Layer 3 routed fabric with EVPN-VXLAN overlay, full ECMP support, scalable architecture	Medium-to-large data centers
Collapsed Spine (2-Tier Design)	Combines spine and leaf functions in a single device role (collapsed topology)	Small or edge data centers with <10 switches
3-Stage Clos	Supports larger, modular fabrics; can include super spines	Cloud-scale environments

Selection Criteria

• Fabric Size: Choose Collapsed Spine for <5 devices, L3 Clos for scalable deployments.

• Latency & Redundancy Requirements: L3 Clos ensures better fault tolerance and horizontal scaling.

• Automation Scope: All templates are designed to work with Apstra's full automation lifecycle.

2. Overlay and Underlay Protocol Recommendations

Key Concepts in Underlay/Overlay Separation

In Apstra’s design model, the network is split into underlay (IP fabric) and overlay (tenant services). Understanding protocol choice is crucial even though Apstra automates configuration generation.

Underlay Recommendations

Protocol	Role	Notes
OSPF	Used for IP connectivity between fabric nodes	Common for Juniper implementations
ISIS	Alternative to OSPF, often vendor-preferred	Less common in Apstra labs
iBGP	Some deployments use BGP even for underlay	Simpler for uniform protocol stack

Overlay Recommendations

Protocol	Role	Notes
eBGP EVPN	Recommended overlay control plane	Handles MAC/IP distribution, multi-tenancy, and VXLAN route signaling
iBGP EVPN	Optional in homogeneous environments	Used when all devices are in same ASN (less common with Apstra)

Important: Apstra will manage both underlay and overlay setup automatically, but you define these protocol choices during the design phase.

3. Default Resource Pools in Blueprints

What Are Resource Pools?

Apstra uses resource pools to manage reusable ranges of configuration data such as:

• IP address subnets

• ASN ranges

• VLAN IDs

• VXLAN VNIs

• Loopback addresses

Why Resource Pools Matter

• Consistency: Avoids overlap or manual tracking errors in large-scale deployments.

• Scalability: Blueprint templates can be cloned or expanded across multiple sites using the same resource logic.

• Reusability: Enables “templated” designs for multi-site or greenfield rollouts.

Example Configuration

• VXLAN VNIs: 1000–1999

• Loopback Range: 192.168.100.0/24

• Spine ASN Pool: 65000–65010

• Leaf ASN Pool: 65100–65150

These pools are selected during blueprint creation and consumed automatically during build and deploy phases.

4. Device Configuration Profiles and Interface Mapping Templates

Device Profiles (Templates)

A Device Profile defines the hardware and interface layout for a specific switch or router model.

Parameter	Description
Platform type	e.g., QFX5120, QFX10002
Number of uplink/downlink ports	Used for spine-leaf interface logic
Interface naming convention	Ensures correct interface mapping (e.g., xe-0/0/1)

Interface Mapping

• When designing the fabric, Apstra maps physical links based on device profiles.

• Uplink/downlink roles are auto-assigned during fabric stitching.

• Port labels can be customized for logical roles (e.g., server-facing, fabric-facing).

Benefits

• No need to manually assign ports per switch.

• Ensures that blueprint is hardware-aware.

• Allows bulk provisioning across dissimilar devices with abstract logic.

Summary of Key Enhancements for the Design Phase

Topic	Key Contribution
Blueprint Templates	Spine-leaf, Collapsed Spine, and 3-stage Clos models explained
Overlay/Underlay Protocols	Recommends BGP EVPN for overlay, OSPF/ISIS for underlay, design-time selection
Resource Pools	ASN, IP, VNI pools ensure reusable, scalable designs
Device Profiles	Interface logic abstracted through platform-aware configuration templates