Juniper vSRX Guide

PDF

Document

vSRX Deployment Guide for Private and

Public Cloud Platforms

Published

2021-07-26

Juniper Networks, Inc.

1133 Innovation Way

Sunnyvale, California 94089

USA

408-745-2000 www.juniper.net

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.

vSRX Deployment Guide for Private and Public Cloud Platforms

The information in this document is current as of the date on the title page.

YEAR 2000 NOTICE

Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.

END USER LICENSE AGREEMENT

The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks software. Use of such software is subject to the terms and conditions of the End User License

Agreement ("EULA") posted at https://support.juniper.net/support/eula/ . By downloading, installing or using such software, you agree to the terms and conditions of that EULA.

About This Guide | xvi

vSRX Deployment for KVM

Overview | 2

Understand vSRX with KVM | 2

Requirements for vSRX on KVM | 7

Install vSRX in KVM | 19

Prepare Your Server for vSRX Installation | 19

Enable Nested Virtualization | 19

Upgrade the Linux Kernel on Ubuntu | 21

Install vSRX with KVM | 21

Install vSRX with virt-manager | 22

Install vSRX with virt-install | 24

Example: Install and Launch vSRX on Ubuntu | 27

Requirements | 28

Overview | 28

Quick Configuration - Install and Launch a vSRX VM on Ubuntu | 29

| 32

Step by Step Configuration | 32

Load an Initial Configuration on a vSRX with KVM | 45

Create a vSRX Bootstrap ISO Image | 46

Provision vSRX with an ISO Bootstrap Image on KVM | 47

Use Cloud-Init in an OpenStack Environment to Automate the Initialization of vSRX Instances | 48

Perform Automatic Setup of a vSRX Instance Using an OpenStack Command-Line Interface | 51

Perform Automatic Setup of a vSRX Instance from the OpenStack Dashboard (Horizon) | 54

vSRX VM Management with KVM | 62

Configure vSRX Using the CLI | 62

Connect to the vSRX Management Console on KVM | 64

iii

Add a Virtual Network to a vSRX VM with KVM | 65

Add a Virtio Virtual Interface to a vSRX VM with KVM | 67

Configure SR-IOV and PCI on KVM | 69

SR-IOV Overview | 69

SR-IOV HA Support with Trust Mode Disabled (KVM only) | 70

Understand SR-IOV HA Support with Trust Mode Disabled (KVM only) | 70

Configure SR-IOV support with Trust Mode Disabled (KVM only) | 71

Limitations | 72

Configure an SR-IOV Interface on KVM | 72

Upgrade a Multi-core vSRX | 76

Configure the Queue Value for vSRX VM with KVM | 77

Shutdown the vSRX Instance with virt-manager | 77

Upgrade vSRX with virt-manager | 78

Monitor the vSRX VM in KVM | 79

Manage the vSRX Instance on KVM | 80

Power On the vSRX Instance with virt-manager | 81

Power On the vSRX Instance with virsh | 81

Pause the vSRX Instance with virt-manager | 81

Pause the vSRX Instance with virsh | 81

Rebooting the vSRX Instance with virt-manager | 82

Reboot the vSRX Instance with virsh | 82

Power Off the vSRX Instance with virt-manager | 82

Power Off the vSRX Instance with virsh | 83

Shutdown the vSRX Instance with virt-manager | 83

Shutdown the vSRX Instance with virsh | 84

Remove the vSRX Instance with virsh | 84

Recover the Root Password for vSRX in a KVM Environment | 85

Configure vSRX Chassis Clusters on KVM | 87

Configure a vSRX Chassis Cluster in Junos OS | 87

Chassis Cluster Overview | 87

Enable Chassis Cluster Formation | 88

Chassis Cluster Quick Setup with J-Web | 89

Manually Configure a Chassis Cluster with J-Web | 91

vSRX Cluster Staging and Provisioning for KVM | 98

Chassis Cluster Provisioning on vSRX | 98

Creating the Chassis Cluster Virtual Networks with virt-manager | 100

Creating the Chassis Cluster Virtual Networks with virsh | 100

Configuring the Control and Fabric Interfaces with virt-manager | 102

Configuring the Control and Fabric Interfaces with virsh | 102

Configuring Chassis Cluster Fabric Ports | 102

Verify the Chassis Cluster Configuration | 103

vii

Upload the vSRX Image with the OpenStack Glance CLI | 263

Use Cloud-Init in an OpenStack Environment to Automate the Initialization of vSRX Instances | 264

Perform Automatic Setup of a vSRX Instance Using an OpenStack Command-Line Interface | 267

Perform Automatic Setup of a vSRX Instance from the OpenStack Dashboard (Horizon) | 269

vSRX VM Management with Contrail | 278

Connect to the vSRX Management Console | 278

Connect to the vSRX Management Console with Horizon | 278

Connect to the vSRX Management Console with Contrail | 278

Manage the vSRX VM | 279

Power On the VM from OpenStack | 279

Pause the VM | 279

Restart the VM | 280

Power Off the VM from OpenStack | 280

Delete the vSRX VM from Contrail | 280

Upgrade Multicore vSRX with Contrail | 281

Configure Multi-queue Virtio Interface for vSRX VM with OpenStack | 281

Modify an Image Flavor for vSRX with the Dashboard | 282

Update a Service Template | 283

Monitor vSRX with Contrail | 283

vSRX Deployment for Nutanix

Overview | 286

Understand vSRX Deployment with Nutanix | 286

Nutanix Platform Overview | 286

vSRX Deployment with Nutanix Overview | 289

Understand vSRX Deployment with Nutanix AHV | 291

Sample vSRX Deployment Using Nutanix AHV | 293

Requirements for vSRX on Nutanix | 294

System Requirements for Nutanix | 294

Reference Requirements | 297

Install vSRX in Nutanix | 298

Launch and Deploy vSRX in Nutanix AHV Cluster | 298

viii

Adding a vSRX Image | 300

Network Creation | 300

Create and Deploy a vSRX VM | 301

Power on the vSRX VMs | 308

Launch vSRX VM Console | 310

Upgrade the Junos OS for vSRX Software Release | 310

vSRX Deployment for AWS

Overview | 313

Understand vSRX with AWS | 313

Requirements for vSRX on AWS | 319

Configure and Manage vSRX in AWS | 323

Configure an Amazon Virtual Private Cloud for vSRX | 323

Step 1: Create an Amazon VPC and Internet Gateway | 324

Step 2: Add Subnets for vSRX | 326

Step 3: Attach an interface to a Subnet | 327

Step 4: Add Route Tables for vSRX | 330

Step 5: Add Security Groups for vSRX | 331

Launch a vSRX Instance on an Amazon Virtual Private Cloud | 334

Step 1: Create an SSH Key Pair | 334

Step 2: Launch a vSRX Instance | 336

Step 3: View the AWS System Logs | 340

Step 4: AddNetwork Interfaces for vSRX | 340

Step 5: Allocate Elastic IP Addresses | 342

Step 6: Add the vSRX Private Interfaces to the Route Tables | 342

Step 7: Reboot the vSRX Instance | 343

Step 8: Log in to a vSRX Instance | 343

Using Cloud-Init to Automate the Initialization of vSRX Instances in AWS | 345

AWS Elastic Load Balancing and Elastic Network Adapter | 347

Overview of AWS Elastic Load Balancing | 348

Overview of Application Load Balancer | 349

Deployment of AWS Application Load Balancer | 350

Invoking Cloud Formation Template (CFT) Stack Creation for vSRX Behind AWS Application

Load Balancer Deployment | 354

Overview of AWS Elastic Network Adapter (ENA) for vSRX Instances | 363

Multi-Core Scaling Support on AWS with SWRSS and ENA | 364

Centralized Monitoring and Troubleshooting using AWS Features | 365

Understanding Centralized Monitoring Using Cloudwatch | 365

Integration of vSRX with AWS Monitoring and Troubleshooting Features | 373

Grant Permission for vSRX to access AWS CloudWatch and Security Hub | 373

Enable Monitoring of vSRX Instances with AWS CloudWatch Metric | 375

Collect, Store, and View vSRX Logs to AWS CloudWatch | 376

Enable and Configure Security Hub on vSRX | 377

Configure vSRX Using the CLI | 378

Understand vSRX on AWS Preconfiguration and Factory Defaults | 379

Add a Basic vSRX Configuration | 379

Add DNS Servers | 382

Add vSRX Feature Licenses | 382

Configure vSRX Using the J-Web Interface | 383

Access the J-Web Interface and Configure vSRX | 383

Apply the Configuration Settings for vSRX | 385

Add vSRX Feature Licenses | 386

Upgrade Junos OS Software on a vSRX Instance | 386

Upgrade the Junos OS for vSRX Software Release | 386

Replace the vSRX Instance on AWS | 387

Remove a vSRX Instance on AWS | 388

vSRX Deployment for Microsoft Azure

Overview | 390

Understand vSRX with Microsoft Azure Cloud | 390

Requirements for vSRX on Microsoft Azure | 393

Deploy vSRX from the Azure Portal | 400

Before You Deploy vSRX from the Azure Portal | 400

Create a Resource Group | 401

Create a Storage Account | 405

Create a Virtual Network | 410

Deploy the vSRX Image from Azure Marketplace | 415

Deploy the vSRX Image | 416

Verify Deployment of vSRX to Microsoft Azure | 429

Deploy vSRX from the Azure CLI | 432

Before You Deploy vSRX Using the Azure CLI | 432

Deploy vSRX from the Azure CLI | 434

Install the Microsoft Azure CLI | 435

Download the vSRX Deployment Tools | 436

Change Parameter Values in the vsrx.parameter.json File | 437

Deploy the vSRX Using the Shell Script | 440

Verify Deployment of vSRX to Microsoft Azure | 443

Configure and Manage vSRX for Microsoft Azure | 448

Configure vSRX Using the CLI | 448

Configure vSRX Using the J-Web Interface | 450

Access the J-Web Interface and Configuring vSRX | 450

Apply the Configuration | 453

Add vSRX Feature Licenses | 454

Remove a vSRX Instance from Microsoft Azure | 454

Upgrade Junos OS Software on a vSRX Instance | 455

Upgrade the Junos OS for vSRX Software Release | 455

Replace the vSRX Instance on Azure | 455

Configure Azure Features on vSRX and Use Cases | 457

Deployment of Microsoft Azure Hardware Security Module on vSRX 3.0 | 457

Microsoft Azure Key Vault Hardware Security Module Integration Overview | 457

Configure Microsoft Azure Key Vault HSM on vSRX 3.0 | 459

Change the Master Encryption Password | 463

Verify the Status of the HSM | 464

request security hsm master-encryption-password set | 465

show security hsm status | 466

Understanding VPN Functionality with Microsoft Azure Key Vault HSM Service | 469

CLI Behavior With and Without HSM | 472

request security pki local-certificate enroll scep | 473

Example: Configure an IPsec VPN Between Two vSRX Instances | 478

Before You Begin | 478

Overview | 478 vSRX IPsec VPN Configuration | 478

Verification | 482

Example: Configure an IPsec VPN Between a vSRX and Virtual Network Gateway in Microsoft

Azure | 483

Before You Begin | 483

Overview | 484 vSRX IPsec VPN Configuration | 484

Microsoft Azure Virtual Network Gateway Configuration | 486

Example: Configure Juniper Sky ATP for vSRX | 487

Before You Begin | 488

Overview | 488

Juniper Sky ATP Configuration | 488

vSRX Deployment for Google Cloud Platform

Overview | 491

Understand vSRX Deployment with Google Cloud | 491

Understand vSRX Deployment with Google Cloud Platform | 491

Requirements for vSRX on Google Cloud Platform | 494

Google Compute Engine Instance Types | 494

vSRX Support for Google Cloud | 496 vSRX Specifications for GCP | 496

Install vSRX in Google Cloud | 500

Prepare to setup vSRX Deployment on GCP | 500

Step 1: Google Cloud Platform Account Planning | 502

Step 2: Define Network Attributes and Generate SSH Key Pair for Authentication | 503

xii

Step 3: Plan Google Virtual Private Cloud (VPC) Network | 505

Deploy vSRX in Google Cloud Platform | 506

Deploy the vSRX Firewall from Marketplace Launcher | 506

Deploy the vSRX Instance from GCP Portal Using Custom Private Image | 514

Upload vSRX Image to Google Cloud Storage | 514

Create vSRX Image | 516

Deploy the vSRX Firewall from GCP Portal | 518

Deploy the vSRX Firewall Using Cloud-init | 521

Upgrade the Junos OS for vSRX Software Release | 524

vSRX Deployment for IBM Cloud

Overview | 526 vSRX Overview | 526

Getting Started with Juniper vSRX on IBM Cloud | 528

Overview of vSRX in IBM Cloud | 529

Choosing a vSRX license | 530

Ordering a vSRX | 532

Junos OS Features Supported on vSRX | 534

Installing and Configuring vSRX in IBM | 548

Performing vSRX Basics in IBM Cloud | 548

Viewing all gateway appliances | 548

Viewing gateway appliance details | 549

Renaming a gateway appliance | 549

Canceling a gateway appliance | 550

Performing additional vSRX tasks | 550

vSRX Readiness Checks in IBM Cloud | 552

Checking vSRX readiness | 553

Readiness status | 553

Correcting readiness errors | 554

Managing VLANs with a gateway appliance | 555

Associating a VLAN to a gateway appliance | 556

Routing an associated VLAN | 556

xiii

Bypassing gateway appliance routing for a VLAN | 557

Disassociating a VLAN from a gateway appliance | 557

Working with the vSRX Default Configurations | 558

Understanding the vSRX default configuration | 558

Importing and Exporting a vSRX Configuration | 559

Exporting part of the vSRX configuration | 560

Importing the entire vSRX configuration | 561

Importing part of the vSRX configuration | 561

Migrating Legacy Configurations to the Current vSRX Architecture | 562

Migrating 1G vSRX Standalone Configurations | 563

Migrating 1G vSRX High Availability configurations | 571

Allowing SSH and Ping to a Public Subnet | 571

Performing vSRX Advanced Tasks in IBM Cloud | 572

Working with Firewalls | 572

Zone Policies | 573

Firewall Filters | 574

Working with sNAT | 574

Working with Failover | 575

Working with Routing | 576

Working with VPN | 577

Securing the Host Operating System | 583

Configuring the Management Interfaces | 585

Upgrading the vSRX in IBM Cloud | 586

Upgrading | 586

General Upgrade Considerations | 589

Upgrading using OS Reload | 592

Rollback Options | 593

Unsupported Upgrades | 593

Managing vSRX in IBM Cloud | 595 vSRX Configuration and Management Tools | 595

Managing Security Policies for Virtual Machines Using Junos Space Security Director | 596

xiv

Monitoring and Troubleshooting | 598

Technical Support | 598

vSRX Deployment for OCI

Overview | 600

Understanding vSRX Deployment in Oracle Cloud Infrastructure | 600

Overview of Oracle VM Architecture | 600

vSRX with Oracle Cloud Infrastructure | 601

OCI Glossary | 601

Requirements for vSRX on Oracle Cloud Infrastructure | 602

Minimum System Requirements for OCI | 603

vSRX Default Settings with OCI | 604

Best Practices for Deploying vSRX | 604

Installing vSRX in OCI | 605 vSRX Deployment in Oracle Cloud Infrastructure | 605

Overview | 605

Launch vSRX Instances in the OCI | 607

Upgrade the Junos OS for vSRX Software Release | 622

vSRX Licensing | 624

Licenses for vSRX | 624

About This Guide

vSRX is the virtualized form of the Juniper Networks next-generation firewall. It is positioned for use in a virtualized or cloud environment where it can protect and secure east-west and north-south traffic.

This guide provides you details on deployment of vSRX on various private and public cloud platforms.

xvi

PART

vSRX Deployment for KVM

Overview | 2

Install vSRX in KVM | 19

vSRX VM Management with KVM | 62

Configure vSRX Chassis Clusters on KVM | 87

CHAPTER 1

Overview

IN THIS CHAPTER

Understand vSRX with KVM | 2

Requirements for vSRX on KVM | 7

Understand vSRX with KVM

IN THIS SECTION

vSRX on KVM | 2

vSRX Scale Up Performance | 3

This section presents an overview of vSRX on KVM.

vSRX on KVM

The Linux kernel uses the kernel-based virtual machine ( KVM) as a virtualization infrastructure. KVM is open source software that you can use to create multiple virtual machines (VMs) and to install security and networking appliances.

The basic components of KVM include:

• A loadable kernel module included in the Linux kernel that provides the basic virtualization infrastructure

• A processor-specific module

When loaded into the Linux kernel, the KVM software acts as a hypervisor. KVM supports multitenancy and allows you to run multiple vSRX VMs on the host OS. KVM manages and shares the system resources between the host OS and the multiple vSRX VMs.

NOTE: vSRX requires you to enable hardware-based virtualization on a host OS that contains an

Intel Virtualization Technology (VT) capable processor.

Figure 1 on page 3 illustrates the basic structure of a vSRX VM on an Ubuntu server.

Figure 1: vSRX VM on Ubuntu

vSRX Scale Up Performance

Table 1 on page 3

shows the vSRX scale up performance when deployed on KVM, based on the number of vCPUs and vRAM applied to a vSRX VM along with the Junos OS release in which a particular vSRX software specification was introduced.

Table 1: vSRX Scale Up Performance vCPUs vRAM NICs Release Introduced

2 vCPUs 4 GB • Virtio

• SR-IOV (Intel

82599, X520/540)

Junos OS Release

15.1X49-D15 and

Junos OS Release

17.3R1

Table 1: vSRX Scale Up Performance (Continued) vCPUs vRAM NICs

5 vCPUs 8 GB

Release Introduced

• Virtio

• SR-IOV (Intel

82599, X520/540)

Junos OS Release

15.1X49-D70 and

Junos OS Release

17.3R1

5 vCPUs 8 GB • SR-IOV (Intel X710/

XL710)

Junos OS Release

15.1X49-D90 and

Junos OS Release

17.3R1

You can scale the performance and capacity of a vSRX instance by increasing the number of vCPUs and the amount of vRAM allocated to the vSRX. The multi-core vSRX automatically selects the appropriate vCPUs and vRAM values at boot time, as well as the number of Receive Side Scaling (RSS) queues in the

NIC. If the vCPU and vRAM settings allocated to a vSRX VM do not match what is currently available, the vSRX scales down to the closest supported value for the instance. For example, if a vSRX VM has 3 vCPUs and 8 GB of vRAM, vSRX boots to the smaller vCPU size, which requires a minimum of 2 vCPUs.

You can scale up a vSRX instance to a higher number of vCPUs and amount of vRAM, but you cannot scale down an existing vSRX instance to a smaller setting.

NOTE: The number of RSS queues typically matches with the number of data plane vCPUs of a vSRX instance. For example, a vSRX with 4 data plane vCPUs should have 4 RSS queues.

vSRX Session Capacity Increase

vSRX solution is optimized to increase the session numbers by increasing the memory.

With the ability to increase the session numbers by increasing the memory, you can enable vSRX to:

• Provide highly scalable, flexible and high-performance security at strategic locations in the mobile network.

• Deliver the performance that service providers require to scale and protect their networks.

Run the show security flow session summary | grep maximum command to view the maximum number of sessions.

Starting in Junos OS Release 18.4R1, the number of flow sessions supported on a vSRX instance is increased based on the vRAM size used.

Starting in Junos OS Release 19.2R1, the number of flow sessions supported on a vSRX 3.0 instance is increased based on the vRAM size used.

NOTE: Maximum of 28M sessions are supported on vSRX 3.0. You can deploy vSRX 3.0 with more than 64G memory, but the maximum flow sessions can still be only 28M.

2/5

2/5/9

Table 2 on page 5

lists the flow session capacity.

Table 2: vSRX and vSRX 3.0 Flow Session Capacity Details vCPUs Memory Flow Session Capacity

2 4 GB 0.5 M

2/5

6 GB

8 GB

1 M

2 M

10 GB

12 GB

14 GB

16 GB

2 M

2.5 M

3 M

4 M

2/5/9

20 GB

24 GB

28 GB

6 M

8 M

10 M

Table 2: vSRX and vSRX 3.0 Flow Session Capacity Details (Continued) vCPUs Memory Flow Session Capacity

2/5/9/17 32 GB 12 M

2/5/9/17

40 GB

48 GB

16 M

20 M

2/5/9/17

56 GB

64 GB

24 M

28 M

Release History Table

Release Description

19.2R1

Starting in Junos OS Release 19.2R1, the number of flow sessions supported on a vSRX 3.0 instance is increased based on the vRAM size used.

18.4R1

Starting in Junos OS Release 18.4R1, the number of flow sessions supported on a vSRX instance is increased based on the vRAM size used.

RELATED DOCUMENTATION

Requirements for vSRX on KVM | 7

Upgrade a Multi-core vSRX | 76

Install vSRX with KVM | 21

Requirements for vSRX on KVM

IN THIS SECTION

Software Specifications | 7

Hardware Specifications | 13

Best Practices for Improving vSRX Performance | 14

Interface Mapping for vSRX on KVM | 16

vSRX Default Settings on KVM | 18

This section presents an overview of requirements for deploying a vSRX instance on KVM;

Software Specifications

Table 3 on page 7

lists the system software requirement specifications when deploying vSRX in a

KVM environment. The table outlines the Junos OS release in which a particular software specification for deploying vSRX on KVM was introduced. You will need to download a specific Junos OS release to take advantage of certain features.

CAUTION: A Page Modification Logging (PML) issue related to the KVM host kernel might prevent the vSRX from successfully booting. If you experience this behavior with the vSRX, we recommend that you disable the PML at the host kernel level. See

"Prepare Your Server for vSRX Installation" on page 19 for details about disabling the

PML as part of enabling nested virtualization.

Table 3: Specifications for vSRX

Component Specification Release Introduced

Linux KVM

Hypervisor support

Ubuntu 14.04.5, 16.04, 16.10, and 18.04

Junos OS Release 18.4R1

Red Hat Enterprise Linux (RHEL) 7.3

CentOS 7.2

Table 3: Specifications for vSRX (Continued)

Component Specification

CentOS 7.6 and 7.7

Memory

Red Hat Enterprise Linux (RHEL) 7.6 and

7.7

Junos OS Release 19.2R1

4 GB

8 GB

Junos OS Release 15.1X49-D15 and

Junos OS Release 17.3R1

Junos OS Release 15.1X49-D70 and

Junos OS Release 17.3R1

16 GB

Release Introduced

Junos OS Release 19.2R1

Disk space vCPUs

32 GB

16 GB IDE drive

2 vCPUs

Junos OS Release 15.1X49-D90 and

Junos OS Release 17.3R1

Junos OS Release 15.1X49-D100 and

Junos OS Release 17.4R1

Junos OS Release 15.1X49-D15 and

Junos OS Release 17.3R1

Junos OS Release 15.1X49-D15 and

Junos OS Release 17.3R1

5 vCPUs

9 vCPUs

17 vCPUs

Junos OS Release 15.1X49-D70 and

Junos OS Release 17.3R1

Junos OS Release 15.1X49-D90 and

Junos OS Release 17.3R1

Junos OS Release 15.1X49-D100 and

Junos OS Release 17.4R1

Table 3: Specifications for vSRX (Continued)

Component Specification vNICs 2-8 vNICs.

• Virtio

• SR-IOV (Intel 82599, X520/X540)

For SR-IOV limitations, see the Known

Behavior section of the vSRX Release

Notes.

Release Introduced

Junos OS Release 15.1X49-D15 and

Junos OS Release 17.3R1

• SR-IOV (X710/XL710) Junos OS Release 15.1X49-D90

• SR-IOV (Mellanox ConnectX-3/

ConnectX-3 Pro and Mellanox

ConnectX-4 EN/ConnectX-4 Lx EN)

Junos OS Release 18.1R1

Starting in Junos OS Release 19.4R1,

DPDK version 18.11 is supported on vSRX. With this feature the Mellanox

Connect Network Interface Card (NIC) on vSRX now supports OSPF Multicast and

VLANs.

Junos OS Release 19.4R1

NOTE: A vSRX on KVM deployment requires you to enable hardware-based virtualization on a host OS that contains an Intel Virtualization Technology (VT) capable processor. You can verify

CPU compatibility here: http://www.linux-kvm.org/page/Processor_support

Table 4 on page 10 lists the specifications on the vSRX VM.

Table 4: Specifications for vSRX 3.0

Component Specification

Linux KVM

Hypervisor support

CentOS 7.2

CentOS 7.6 and 7.7

Release Introduced

Junos OS Release 18.4R1

Junos OS Release 19.2R1

Red Hat Enterprise Linux (RHEL) 7.6 and

7.7

Junos OS Release 19.2R1

Memory

Red Hat Enterprise Linux (RHEL) 8.2

4 GB

8 GB

16 GB

Junos OS Release 20.4R1

Junos OS Release 18.2R1

Junos OS Release 18.4R1

Junos OS Release 19.1R1

vDisk vCPUs vNICs

2-8

32 GB

20G

Junos OS Release 19.1R1

Junos OS Release 18.2R1

Junos OS Release 18.4R1

Junos OS Release 19.1R1

Junos OS Release 18.2R1

Table 4: Specifications for vSRX 3.0 (Continued)

Component Specification

2-8 vSRX supports VIRTIO on KVM hypervisor.

Release Introduced

Junos OS Release 18.4R1

vSRX3.0 supports LiquidIO DPDK driver with KVM hypervisor. If you use the

LiquidIO II smart NICs, then you can use vSRX3.0 by the VF of SR-IOV.

Junos OS Release 20.4R1

SR-IOV 10-Gigabit High Availability on vSRX3.0. See [Configuring SR-IOV 10-

Gigabit High Availability on vSRX 3.0]

Junos OS Release 20.4R1

Mellanox ConnectX-4 and ConnectX-5 family adapters. For a summary of vSRX sizes (number of vCPU and amount of vRAM) that support the Mellanox

ConnectX-4 and ConnectX-5 Family

Adapters, see vSRX Scale Up Performance

Junos OS Release 21.2R1

DPDK 17.05

17.5.02

18.11

Junos OS Release 18.2R1

Junos OS Release 19.1R1

Junos OS Release 19.4R1

Table 4: Specifications for vSRX 3.0 (Continued)

Component Specification Release Introduced

Data Plane Development Kit (DPDK) version 20.11 on vSRX 3.0. The new version supports ICE Poll Mode Driver

(PMD), which enables you to integrate with the physical Intel E810 series 100G

NIC. Junos FreeBSD 12.X is vSRX 3.0

VM’s guest OS. The Routing Engine and

Packet Forwarding Engine run on Junos

FreeBSD OS as one VM, and the Packet

Forwarding Engine utilizes DPDK technologies such as DPDK ICE PMD and single-root I/O virtualization (SR-IOV).

Junos OS Release 21.2R1

Starting in Junos OS Release 19.1R1, the vSRX instance supports guest OS using 9 or 17 vCPUs with single-root I/O virtualization over Intel X710/XL710 on Linux KVM hypervisor for improved scalability and performance.

KVM Kernel Recommendations for vSRX

Table 5 on page 12 lists the recommended Linux kernel version for your Linux host OS when deploying

vSRX on KVM. The table outlines the Junos OS release in which support for a particular Linux kernel version was introduced.

Table 5: Kernel Recommendations for KVM

Linux

Distributi on

Linux Kernel Version Supported Junos OS Release

CentOS 3.10.0.229

Upgrade the Linux kernel to capture the recommended version.

Junos OS Release 15.1X49-D15 and Junos

OS Release 17.3R1 or later release

Ubuntu 3.16

Table 5: Kernel Recommendations for KVM (Continued)

Linux

Distributi on

Linux Kernel Version Supported Junos OS Release

4.4

RHEL 3.10

Additional Linux Packages for vSRX on KVM

Table 6 on page 13 lists the additional packages you need on your Linux host OS to run vSRX on KVM.

See your host OS documentation for how to install these packages if they are not present on your server.

Table 6: Additional Linux Packages for KVM

Package Version Download Link libvirt 0.10.0

libvirt download virt-manager (Recommended) 0.10.0

virt-manager download

Hardware Specifications

Table 7 on page 13 lists the hardware specifications for the host machine that runs the vSRX VM.

Table 7: Hardware Specifications for the Host Machine

Component Specification

Host processor type Intel x86_64 multi-core CPU

NOTE: DPDK requires Intel Virtualization VT-x/VT-d support in the CPU. See

About Intel Virtualization Technology.

Table 7: Hardware Specifications for the Host Machine (Continued)

Component Specification

Physical NIC support for vSRX and vSRX

3.0

• Virtio

• SR-IOV (Intel X710/XL710, X520/540, 82599)

• SR-IOV (Mellanox ConnectX-3/ConnectX-3 Pro and Mellanox ConnectX-4

EN/ConnectX-4 Lx EN)

NOTE: If using SR-IOV with either the Mellanox ConnectX-3 or ConnectX-4

Family Adapters, on the Linux host, if necessary, install the latest

MLNX_OFED Linux driver. See Mellanox OpenFabrics Enterprise Distribution for Linux (MLNX_OFED) .

NOTE: You must enable the Intel VT-d extensions to provide hardware

support for directly assigning physical devices per guest. See "Configure SR-

IOV and PCI on KVM" on page 69 .

Starting in Junos OS Release 21.2R1, a vSRX 3.0 instance deployed on KVM supports SR-IOV on the Mellanox ConnectX-3 and ConnectX-4 family adapters. For a summary of vSRX sizes (number of vCPU and amount of vRAM) that support the Mellanox ConnectX-3 and ConnectX-4 Family

Adapters.

Physical NIC support for vSRX 3.0

Support SR-IOV on Intel X710/XL710/XXV710 and Intel E810

Best Practices for Improving vSRX Performance

Review the following practices to improve vSRX performance.

NUMA Nodes

The x86 server architecture consists of multiple sockets and multiple cores within a socket. Each socket has memory that is used to store packets during I/O transfers from the NIC to the host. To efficiently read packets from memory, guest applications and associated peripherals (such as the NIC) should reside within a single socket. A penalty is associated with spanning CPU sockets for memory accesses, which might result in nondeterministic performance. For vSRX, we recommend that all vCPUs for the vSRX VM are in the same physical non-uniform memory access (NUMA) node for optimal performance.

CAUTION: The Packet Forwarding Engine (PFE) on the vSRX will become unresponsive if the NUMA nodes topology is configured in the hypervisor to spread the instance’s vCPUs across multiple host NUMA nodes. vSRX requires that you ensure that all vCPUs reside on the same NUMA node.

We recommend that you bind the vSRX instance with a specific NUMA node by setting

NUMA node affinity. NUMA node affinity constrains the vSRX VM resource scheduling to only the specified NUMA node.

Mapping Virtual Interfaces to a vSRX VM

To determine which virtual interfaces on your Linux host OS map to a vSRX VM:

1. Use the virsh list command on your Linux host OS to list the running VMs.

hostOS# virsh list

Id Name State

----------------------------------------------------

9 centos1 running

15 centos2 running

16 centos3 running

48 vsrx running

50 1117-2 running

51 1117-3 running

2. Use the virsh domiflist vsrx-name command to list the virtual interfaces on that vSRX VM.

hostOS# virsh domiflist vsrx

Interface Type Source Model MAC

------------------------------------------------------vnet1 bridge brem2 virtio 52:54:00:8f:75:a5 vnet2 bridge br1 virtio 52:54:00:12:37:62 vnet3 bridge brconnect virtio 52:54:00:b2:cd:f4

NOTE: The first virtual interface maps to the fxp0 interface in Junos OS.

Interface Mapping for vSRX on KVM

Each network adapter defined for a vSRX is mapped to a specific interface, depending on whether the vSRX instance is a standalone VM or one of a cluster pair for high availability. The interface names and

mappings in vSRX are shown in Table 8 on page 16

and Table 9 on page 17 .

Note the following:

• In standalone mode:

• fxp0 is the out-of-band management interface.

• ge-0/0/0 is the first traffic (revenue) interface.

• In cluster mode:

• fxp0 is the out-of-band management interface.

• em0 is the cluster control link for both nodes.

• Any of the traffic interfaces can be specified as the fabric links, such as ge-0/0/0 for fab0 on node

0 and ge-7/0/0 for fab1 on node 1.

Table 8 on page 16 shows the interface names and mappings for a standalone vSRX VM.

Table 8: Interface Names for a Standalone vSRX VM

Network

Adapter

Interface Name in Junos OS for vSRX

1 fxp0 ge-0/0/0 ge-0/0/1 ge-0/0/2

Table 8: Interface Names for a Standalone vSRX VM (Continued)

Network

Adapter

Interface Name in Junos OS for vSRX

5 ge-0/0/3

8 ge-0/0/4 ge-0/0/5 ge-0/0/6

Table 9 on page 17 shows the interface names and mappings for a pair of vSRX VMs in a cluster (node

0 and node 1).

Table 9: Interface Names for a vSRX Cluster Pair

Network

Adapter

Interface Name in Junos OS for vSRX

1 fxp0 (node 0 and 1) em0 (node 0 and 1) ge-0/0/0 (node 0) ge-7/0/0 (node 1)

6 ge-0/0/1 (node 0) ge-7/0/1 (node 1) ge-0/0/2 (node 0) ge-7/0/2 (node 1) ge-0/0/3 (node 0) ge-7/0/3 (node 1)

Table 9: Interface Names for a vSRX Cluster Pair (Continued)

Network

Adapter

Interface Name in Junos OS for vSRX

7 ge-0/0/4 (node 0) ge-7/0/4 (node 1)

8 ge-0/0/5 (node 0) ge-7/0/5 (node 1)

vSRX Default Settings on KVM

vSRX requires the following basic configuration settings:

• Interfaces must be assigned IP addresses.

• Interfaces must be bound to zones.

• Policies must be configured between zones to permit or deny traffic.

Table 10 on page 18

lists the factory-default settings for security policies on the vSRX.

Table 10: Factory Default Settings for Security Policies

Source Zone Destination Zone Policy Action trust untrust permit trust untrust trust trust permit deny

RELATED DOCUMENTATION

About Intel Virtualization Technology

DPDK Release Notes

CHAPTER 2

Install vSRX in KVM

IN THIS CHAPTER

Prepare Your Server for vSRX Installation | 19

Install vSRX with KVM | 21

Example: Install and Launch vSRX on Ubuntu | 27

Load an Initial Configuration on a vSRX with KVM | 45

Use Cloud-Init in an OpenStack Environment to Automate the Initialization of vSRX Instances | 48

Prepare Your Server for vSRX Installation

IN THIS SECTION

Enable Nested Virtualization | 19

Upgrade the Linux Kernel on Ubuntu | 21

Enable Nested Virtualization

We recommend that you enable nested virtualization on your host OS or OpenStack compute node.

Nested virtualization is enabled by default on Ubuntu but is disabled by default on CentOS.

Use the following command to determine if nested virtualization is enabled on your host OS. The result should be Y.

hostOS# cat /sys/module/kvm_intel/parameters/nested hostOS# Y

NOTE: APIC virtualization (APICv) does not work well with nested VMs such as those used with

KVM. On Intel CPUs that support APICv (typically v2 models, for example E5 v2 and E7 v2), you must disable APICv on the host server before deploying vSRX.

To enable nested virtualization on the host OS:

1. Depending on your host operating system, perform the following:

• On CentOS, open the /etc/modprobe.d/dist.conf file in your default editor.

hostOS# vi /etc/modprobe.d/dist.conf

• On Ubuntu, open the /etc/modprobe.d/qemu-system-x86.conf file in your default editor.

hostOS# vi /etc/modprobe.d/qemu-system-x86.conf

2. Add the following line to the file: hostOS# options kvm-intel nested=y enable_apicv=n

NOTE: A Page Modification Logging (PML) issue related to the KVM host kernel might prevent the vSRX from successfully booting. We recommend that you add the following line to the file instead of the line listed above in Step 2: hostOS# options kvm-intel nested=y enable_apicv=n pml=n

3. Save the file and reboot the host OS.

4. (Optional) After the reboot, verify that nested virtualization is enabled.

hostOS# cat /sys/module/kvm_intel/parameters/nested hostOS# Y

5. On Intel CPUs that support APICv ( for example, E5 v2 and E7 v2), disable APICv on the host OS.

root@host# sudo rmmod kvm-intel root@host# sudo sh -c “echo ’options kvm-intel enable_apicv=n’ >> /etc/modprobe.d/dist.conf” root@host# sudo modprobe kvm-intel

6. Optionally, verify that APICv is now disabled.

root@host# cat /sys/module/kvm_intel/parameters/enable_apicv

Upgrade the Linux Kernel on Ubuntu

To upgrade to the latest stable Linux kernel on Ubuntu:

1. Get and install the available updated kernel.

hostOS:$ sudo apt-get install linux-image-generic-lts-utopic

2. Reboot the host OS.

hostOS:$ reboot

3. Optionally, type uname -a in a terminal on your host OS to verify that the host OS is using the latest kernel version.

hostOS:$ uname -a

3.16.0-48-generic

Install vSRX with KVM

IN THIS SECTION

Install vSRX with virt-manager | 22

Install vSRX with virt-install | 24

You use virt-manager or virt-install to install vSRX VMs. See your host OS documentation for complete details on these packages.

NOTE: To upgrade an existing vSRX instance, see Migration, Upgrade, and Downgrade in the vSRX Release Notes.

Install vSRX with virt-manager

Ensure that sure you have already installed KVM, qemu, virt-manager, and libvirt on your host OS. You must also configure the required virtual networks and storage pool in the host OS for the vSRX VM. See your host OS documentation for details.

You can install and launch vSRX with the KVM virt-manager GUI package.

To install vSRX with virt-manager :

Download the vSRX QCOW2 image from the Juniper software download site.

On your host OS, type virt-manager. The Virtual Machine Manager appears. See Figure 2 on page

NOTE: You must have admin rights on the host OS to use virt-manager .

Figure 2: virt-manager

Click Create a new virtual machine as seen in Figure 3 on page 23

. The New VM wizard appears .

Figure 3: Create a New Virtual Machine

Select Import existing disk image, and click Forward.

Browse to the location of the downloaded vSRX QCOW2 image and select the vSRX image.

Select Linux from the OS type list and select Show all OS options from the Version list.

Select Red Hat Enterprise Linux 7 from the expanded Version list and click Forward.

Set the RAM to 4096 MB and set CPUs to 2. Click Forward.

Set the disk image size to 16 GB and click Forward.

10. Name the vSRX VM, and select Customize this configuration before install to change parameters before you create and launch the VM. Click Finish. The Configuration dialog box appears.

11. Select Processor and expand the Configuration list.

12. Select Copy Host CPU Configuration.

13. Set CPU Feature invtsc to disabled on CPUs that support that feature. Set vmx to require for optimal throughput. You can optionally set aes to require for improved cryptographic throughput

NOTE: If the CPU feature option is not present in your version of virt-manager, you need start and stop the VM once, and then edit the vSRX VM XML file, typically found in /etc/ libvirt/qemu directory on your host OS. Use virsh edit to edit the VM XML file to configure

<feature policy='require' name='vmx'/> under the <cpu mode> element. Also add <feature policy='disable' name='invtsc'/> if your host OS supports this CPU flag. Use the virsh capabilities command on your host OS to list the host OS and CPU virtualization capabilities.

The following example shows the relevant portion of the vSRX XML file on a CentOS host:

<model fallback='allow'>SandyBridge</model>

<vendor>Intel</vendor>

</cpu>

14. Select the disk and expand Advanced Options.

15. Select IDE from the Disk bus list.

16. Select the NIC, and select virtio from the Device model field. This first NIC is the fpx0

(management) interface for vSRX.

17. Click Add Hardware to add more virtual networks, and select virtio from the Device model list.

18. Click Apply, and click x to close the dialog box.

19. Click Begin Installation. The VM manager creates and launches the vSRX VM.

NOTE: The default vSRX VM login ID is root with no password. By default, if a DHCP server is on the network, it assigns an IP address to the vSRX VM.

Install vSRX with virt-install

Ensure that sure you have already installed KVM, qemu, virt-install, and libvirt on your host OS. You must also configure the required virtual networks and storage pool in the host OS for the vSRX VM. See your host OS documentation for details.

NOTE: You must have root access on the host OS to use the virt-install command.

The virt-install and virsh tools are CLI alternatives to installing and managing vSRX VMs on a Linux host.

To install vSRX with virt-install :

1. Download the vSRX QCOW2 image from the Juniper software download site.

2. On your host OS, use the virt-install command with the mandatory options listed in Table 11 on page

25 .

NOTE: See the official virt-install documentation for a complete description of available options.

Table 11: virt-install Options

Command Option Description

--name name Name the vSRX VM.

--ram megabytes

--vcpus number

Allocate RAM for the VM, in megabytes.

--cpu cpu-model, cpu-flags Enable the vmx feature for optimal throughput. You can also enable aes for improved cryptographic throughput.

NOTE: CPU flag support depends on your host OS and CPU.

Use virsh capabilities to list the virtualization capabilities of your host OS and CPU.

Allocate the number of vCPUs for the vSRX VM.

Table 11: virt-install Options (Continued)

Command Option Description

--disk path Specify disk storage media and size for the VM. Include the following options:

• size= gigabytes

• device=disk

• bus=ide

• format=qcow2

--os-type os-type

--os-variant os-type

Configure the guest OS type and variant.

--import Create and boot the vSRX VM from an existing image.

The following example creates a vSRX VM with 4096 MB RAM, 2 vCPUs, and disk storage up to 16

GB: hostOS# virt-install --name vSRXVM --ram 4096 --cpu SandyBridge,+vmx,-invtsc --vcpus=2 -- arch=x86_64 --disk path=/mnt/vsrx.qcow2,size=16,device=disk,bus=ide,format=qcow2 --os-type linux --os-variant rhel7 --import

The following example shows the relevant portion of the vSRX XML file on a CentOS host:

<model fallback='allow'>SandyBridge</model>

<vendor>Intel</vendor>

</cpu>

NOTE: The default vSRX VM login ID is root with no password. By default, if a DHCP server is on the network, it assigns an IP address to the vSRX VM.

RELATED DOCUMENTATION

Installing a virtual machine using virt-install

Migration, Upgrade, and Downgrade

Linux CPU Flags

Example: Install and Launch vSRX on Ubuntu

IN THIS SECTION

Requirements | 28

Overview | 28

Quick Configuration - Install and Launch a vSRX VM on Ubuntu | 29

| 32

Step by Step Configuration | 32

This example shows how to install and launch a vSRX instance on an Ubuntu server with KVM.

Requirements

This example uses the following hardware and software components:

• Generic x86 server

• Junos OS Release 15.1X49-D20 for vSRX

• Ubuntu version 14.04.2

Before you begin:

• This example assumes a fresh install of the Ubuntu server software.

• Ensure that your host OS meets the requirements specified in "Requirements for vSRX on KVM" on page 7 .

Overview

This example shows how to set up your Ubuntu host server and install and launch a vSRX VM. Figure 4 on page 28 shows the basic structure of a vSRX VM on an Ubuntu server.

Figure 4: vSRX VM on Ubuntu

NOTE: This example uses static IP addresses. If you are configuring the vSRX instance in an NFV environment, you should use DHCP.

Quick Configuration - Install and Launch a vSRX VM on Ubuntu

IN THIS SECTION

CLI Quick Configuration | 29

Procedure | 29

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and copy and paste the commands into the Ubuntu server terminal or vSRX console as specified.

Procedure

Step-by-Step Procedure

1. If the default virtual network does not already exist, copy the following commands and paste them into the Ubuntu server terminal to create the default virtual network.

cat <<EOF> /etc/libvirt/qemu/networks/default.xml

<network>

<name>default</name>

<forward mode='nat'/>

<nat>

<port start ='1024' end='65535' />

</nat>

<bridge name='virbr0' stp='on' delay='0' />

<ip address='192.168.2.1' netmask='255.255.255.0'>

<dhcp>

<range start='192.168.2.2' end='192.168.2.254' />

</dhcp>

</ip>

</network>

EOF virsh net-define /etc/libvirt/qemu/networks/default.xml

virsh net-start default

virsh net-autostart default

2. Create the left, or trusted, virtual network on the Ubuntu server.

cat <<EOF> /etc/libvirt/qemu/networks/testleftnetwork.xml

<network>

<name>TestLeft</name>

<forward mode='route'/>

<bridge name='virbr1' stp='on' delay='0' />

<ip address='192.168.123.1' netmask='255.255.255.0'>

<dhcp>

<range start='192.168.123.100' end='192.168.123.250' />

</dhcp>

</ip>

</network>

EOF virsh net-define /etc/libvirt/qemu/networks/testleftnetwork.xml

virsh net-start TestLeft virsh net-autostart TestLeft

3. Create the right, or untrusted, virtual network on the Ubuntu server.

cat <<EOF > /etc/libvirt/qemu/networks/testrightnetwork.xml

<network>

<name>TestRight</name>

<forward mode='nat'/>

<nat>

<port start ='1024' end='65535' />

</nat>

<bridge name='virbr2' stp='on' delay='0' />

<ip address='192.168.124.1' netmask='255.255.255.0'>

<dhcp>

<range start='192.168.124.100' end='192.168.124.250' />

</dhcp>

</ip>

</network>

EOF virsh net-define /etc/libvirt/qemu/networks/testrightnetwork.xml

virsh net-start TestRight

virsh net-autostart TestRight

4. Download the vSRX KVM image from the Juniper Networks website at https://www.juniper.net/ support/downloads/?p=vsrx#sw .

5. Copy the following commands and modify the cpu parameter and flags to match your Ubuntu server

CPU. Paste the resulting commands into the Ubuntu server terminal to copy the image to a mount point and create the vSRX VM.

cp junos-vsrx-vmdisk-15.1X49-D20.2.qcow2 /mnt/vsrx20one.qcow2

virt-install --name vSRX20One --ram 4096 --cpu SandyBridge,+vmx,-invtc, --vcpus=2 -arch=x86_64 --disk path=/mnt/vsrx20one.qcow2,size=16,device=disk,bus=ide,format=qcow2 --ostype linux --os-variant rhel7 --import --network=network:default,model=virtio -network=network:TestLeft,model=virtio --network=network:TestRight,model=virtio

NOTE: The CPU model and flags in the virt-install command might vary based on the CPU and features in the Ubuntu server.

6. To set the root password on the vSRX VM, copy and paste the command into the vSRX CLI at the

[edit] hierarchy level.

set system root-authentication plain-text-password

7. To create a base configuration on the vSRX VM, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the following commands into the vSRX CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

set interfaces fxp0 unit 0 family inet dhcp-client

set interfaces ge-0/0/0 unit 0 family inet address 192.168.123.254/24 set interfaces ge-0/0/1 unit 0 family inet dhcp-client set security zones security-zone trust interfaces ge-0/0/0.0 host-inbound-traffic systemservices all set security zones security-zone untrust interfaces ge-0/0/1.0 host-inbound-traffic systemservices dhcp set routing-instances CUSTOMER-VR instance-type virtual-router set routing-instances CUSTOMER-VR interface ge-0/0/0.0

set routing-instances CUSTOMER-VR interface ge-0/0/1.0

set security nat source rule-set source-nat from zone trust set security nat source rule-set source-nat to zone untrust set security nat source rule-set source-nat rule nat1 match source-address 0.0.0.0/0 set security nat source rule-set source-nat rule nat1 then source-nat interface

IN THIS SECTION

| 32

Step-by-Step Procedure

Step by Step Configuration

IN THIS SECTION

Add Virtual Networks | 33

Verify the Virtual Networks | 36

Download and Installing the vSRX Image | 37

Verify the vSRX Installation | 37

Create a Base Configuration on the vSRX Instance | 40

Verify the Basic Configuration on the vSRX Instance | 43

Use the following sections for a more detailed set of procedures to install and launch a vSRX VM.

Add Virtual Networks

Step-by-Step Procedure

You need to create virtual networks on the Ubuntu server to provide network connectivity to interfaces on the vSRX VM. Copy and paste these command into a terminal on the Ubuntu server.

This example uses three virtual networks:

• default— Connects the fxp0 management interface.

NOTE: The default virtual network should already exist on the Ubuntu server. Use the virsh net-list command to verify that the default network is present and active.

• TestLeft— Connects the ge-0/0/0 interface to the trusted zone.

• TestRight— Connects the ge-0/0/1 interface to the untrusted zone.

1. If the default network does not exist, follow these steps:

Step-by-Step Procedure

a. Open a text editor on the Ubuntu server and create the default network XML (default.xml) file.

emacs /etc/libvirt/qemu/networks/default.xml

b. Set the forward mode to nat , configure an IP address and subnet mask, and a bridge interface, and configure DHCP to assign IP addresses to interfaces on this virtual network.

NOTE: Use the XML format specified by libvirt.

<network>

<name>default</name>

<forward mode='nat'/>

<nat>

<port start ='1024' end='65535' />

</nat>

<bridge name='virbr0' stp='on' delay='0' />

<ip address='192.168.2.1' netmask='255.255.255.0'>

<dhcp>

<range start='192.168.2.2' end='192.168.2.254' />

</dhcp>

</ip>

</network> c. Define and start the default virtual network, based on the default.xml file you created.

virsh net-define /etc/libvirt/qemu/networks/default.xml

virsh net-start default virsh net-autostart default

2. Remove any previously configured TestLeft virtual network.

virsh net-destroy TestLeft virsh net-undefine TestLeft

3. Remove any previously configured TestRight virtual network.

virsh net-destroy TestRight virsh net-undefine TestRight

4. Open a text editor on the Ubuntu server and create the TestLeft network XML (testleftnetwork.xml) file.

emacs /etc/libvirt/qemu/networks/testleftnetwork.xml

5. Set the forward mode to route , configure an IP address and subnet mask, and a bridge interface, and configure DHCP to assign IP addresses to interfaces on this virtual network.

NOTE: Use the XML format specified by libvirt.

<network>

<name>TestLeft</name>

<forward mode='route'/>

<bridge name='virbr1' stp='on' delay='0' />

<ip address='192.168.123.1' netmask='255.255.255.0'>

<dhcp>

<range start='192.168.123.100' end='192.168.123.250' />

</dhcp>

</ip>

</network>

6. Open a text editor on the Ubuntu server and create the TestRight network XML

(testrightnetwork.xml) file.

emacs /etc/libvirt/qemu/networks/testrightnetwork.xml

7. Set the forward mode to nat , configure an IP address and subnet mask, and a bridge interface, and configure DHCP to assign IP addresses to interfaces on this virtual network.

NOTE: Use the XML format specified by libvirt.

<network>

<name>TestRight</name>

<forward mode='nat'/>

<nat>

<port start ='1024' end='65535' />

</nat>

<bridge name='virbr2' stp='on' delay='0' />

<ip address='192.168.124.1' netmask='255.255.255.0'>

<dhcp>

<range start='192.168.124.100' end='192.168.124.250' />

</dhcp>

</ip>

</network>

8. Define and start the TestLeft virtual network, based on the testleftnetwork.xml file you created.

virsh net-define /etc/libvirt/qemu/networks/testleftnetwork.xml

virsh net-start TestLeft virsh net-autostart TestLeft

9. Define and start the TestRight virtual network, based on the testrightnetwork.xml file you created.

virsh net-define /etc/libvirt/qemu/networks/testrightnetwork.xml

virsh net-start TestRight virsh net-autostart TestRight

Verify the Virtual Networks

Purpose

Verify the new virtual network configuration on the Ubuntu server.

Action

Use the virsh net-list command on the Ubuntu server to verify that the new virtual interfaces are active and are set to autostart on reboot.

virsh net-list

Name State Autostart Persistent

---------------------------------------------------------default active yes yes

TestLeft active yes yes

TestRight active yes yes

Download and Installing the vSRX Image

Step-by-Step Procedure

To download and install the vSRX image on the Ubuntu server:

1. Download the vSRX KVM image from the Juniper Networks website: https://www.juniper.net/ support/downloads/?p=vsrx#sw

2. Copy the vSRX image to an appropriate mount point.

hostOS# cp junos-vsrx-vmdisk-15.1X49-D20.2.qcow2 /mnt/vsrx20one.qcow2

3. Use the virt-install command to create a vSRX VM. Modify the cpu parameter and flags to match your Ubuntu server CPU.

hostOS# virt-install --name vSRX20One --ram 4096 --cpu SandyBridge,+vmx,-invtc, --vcpus=2 -- arch=x86_64 --disk path=/mnt/vsrx20one.qcow2,size=16,device=disk,bus=ide,format=qcow2 --ostype linux --os-variant rhel7 --import --network=network:default,model=virtio -network=network:TestLeft,model=virtio --network=network:TestRight,model=virtio

NOTE: The CPU model and flags in the virt-install command might vary based on the CPU and features in the Ubuntu server.

Verify the vSRX Installation

Purpose

Verify the vSRX Installation.

Action

1. Use the virsh console command on the Ubuntu server to access the vSRX console and watch the progress of the installation. The installation can take several minutes to complete.

hostOS# virsh console vSRx200ne

Starting install...

ERROR internal error: process exited while connecting to monitor: libust[11994/11994]:

Warning: HOME environment variable not set. Disabling LTTng-UST per-user tracing. (in setup_local_apps() at lttng-ust-comm.c:305) libust[11994/11995]: Error: Error opening shm /lttng-ust-wait-5 (in get_wait_shm() at lttngust-comm.c:886) libust[11994/11995]: Error: Error opening shm /lttng-ust-wait-5 (in get_wait_shm() at lttngust-comm.c:886)

Booting `Juniper Linux'

Loading Linux ...

Consoles: serial port

BIOS drive C: is disk0

BIOS drive D: is disk1

BIOS drive E: is disk2

BIOS drive F: is disk3

BIOS 639kB/999416kB available memory

FreeBSD/i386 bootstrap loader, Revision 1.2

([email protected], Thu Jul 30 23:20:10 UTC 2015)

Loading /boot/defaults/loader.conf

/kernel text=0xa3a2c0 data=0x6219c+0x11f8e0 syms=[0x4+0xb2ed0+0x4+0x1061bb]

/boot/modules/libmbpool.ko text=0xce8 data=0x114

/boot/modules/if_em_vsrx.ko text=0x184c4 data=0x7fc+0x20

/boot/modules/virtio.ko text=0x2168 data=0x208 syms=[0x4+0x7e0+0x4+0x972]

/boot/modules/virtio_pci.ko text=0x2de8 data=0x200+0x8 syms=[0x4+0x8f0+0x4+0xb22]

/boot/modules/virtio_blk.ko text=0x299c data=0x1dc+0xc syms=[0x4+0x960+0x4+0xa0f]

/boot/modules/if_vtnet.ko text=0x5ff0 data=0x360+0x10 syms=[0x4+0xdf0+0x4+0xf19]

/boot/modules/pci_hgcomm.ko text=0x12fc data=0x1a4+0x44 syms=[0x4+0x560+0x4+0x61d]

/boot/modules/chassis.ko text=0x9bc data=0x1d0+0x10 syms=[0x4+0x390+0x4+0x399]

Hit [Enter] to boot immediately, or space bar for command prompt.

Booting [/kernel]...

platform_early_bootinit: Early Boot Initialization

GDB: debug ports: sio

GDB: current port: sio

KDB: debugger backends: ddb gdb

KDB: current backend: ddb

FreeBSD is a registered trademark of The FreeBSD Foundation.

JUNOS 15.1X49-D15.4 #0: 2015-07-31 02:20:21 UTC

The machine id is empty.

Cleaning up ...

Thu Aug 27 12:06:22 UTC 2015

Aug 27 12:06:22 init: exec_command: /usr/sbin/dhcpd (PID 1422) started

Aug 27 12:06:22 init: dhcp (PID 1422) started

Aug 27 12:06:23 init: exec_command: /usr/sbin/pppd (PID 1428) started

Amnesiac (ttyd0) login:

2. On the vSRX console, log in and verify the vSRX version installed.

--- JUNOS 15.1X49-D15.4 built 2015-07-31 02:20:21 UTC root@% root@% cli root> root> show version

Model: vSRX

Junos: 15.1X49-D15.4

JUNOS Software Release [15.1X49-D15.4]

Create a Base Configuration on the vSRX Instance

Step-by-Step Procedure

To configure a base setup on the vSRX instance, enter the following steps in edit mode:

1. Create a root password.

[edit]

set system root-authentication plain-text-password

2. Set the IP address family for the management interface, and enable the DHCP client for this interface.

set interfaces fxp0 unit 0 family inet dhcp-client

3. Set the IP address for the ge-0/0/0.0 interface.

set interfaces ge-0/0/0 unit 0 family inet address 192.168.123.254/24

4. Set the IP address family for the ge-0/0/1.0 interface, and enable the DHCP client for this interface.

set interfaces ge-0/0/1 unit 0 family inet dhcp-client

5. Add the ge-0/0/0.0 interface to the trust security zone and allow all system services from inbound traffic on that interface.

set security zones security-zone trust interfaces ge-0/0/0.0 host-inbound-traffic systemservices all

6. Add the ge-0/0/1.0 interface to the untrust security zone and allow only DHCP system services from inbound traffic on that interface.

set security zones security-zone untrust interfaces ge-0/0/1.0 host-inbound-traffic systemservices dhcp

7. Create a virtual router routing instance and add the two interfaces to that routing instance.

set routing-instances CUSTOMER-VR instance-type virtual-router set routing-instances CUSTOMER-VR interface ge-0/0/0.0

set routing-instances CUSTOMER-VR interface ge-0/0/1.0

8. Create a source NAT rule set.

set security nat source rule-set source-nat from zone trust set security nat source rule-set source-nat to zone untrust

9. Configure a rule that matches packets and translates the source address to the address of the egress interface.

set security nat source rule-set source-nat rule nat1 match source-address 0.0.0.0/0 set security nat source rule-set source-nat rule nat1 then source-nat interface

Results

From configuration mode, confirm your configuration by entering the show interfaces command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

show interfaces

From configuration mode, confirm your security policies by entering the show security policies command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

show security policies from-zone trust to-zone trust {

policy default-permit {

match {

source-address any;

destination-address any;

application any;

}

then {

permit;

}

} from-zone trust to-zone untrust {

policy default-permit {

match {

source-address any;

destination-address any;

application any;

}

then {

permit;

}

} from-zone untrust to-zone trust {

policy default-deny {

match {

source-address any;

destination-address any;

application any;

}

then {

deny;

}

If you are done configuring the device, enter commit from configuration mode.

NOTE: As a final step, exit configuration mode and use the request system reboot command to reboot the vSRX VM. You can use the virsh console command on the Ubuntu server to reconnect to the vSRX after reboot.

Verify the Basic Configuration on the vSRX Instance

Purpose

Verify the basic configuration on the vSRX instance.

Action

Verify that the ge-0/0/0.0 interface has an assigned IP address from the TestLeft network DHCP address range, and that the ge-0/0/1.0 has an assigned IP address from the TestRight network DHCP address range.

root> show interfaces terse

Interface Admin Link Proto Local Remote ge-0/0/0 up up ge-0/0/0.0 up up inet 192.168.123.254/24 gr-0/0/0 up up ip-0/0/0 up up lsq-0/0/0 up up lt-0/0/0 up up mt-0/0/0 up up sp-0/0/0 up up sp-0/0/0.0 up up inet

inet6 sp-0/0/0.16383 up up inet ge-0/0/1 up up ge-0/0/1.0 up up inet 192.168.124.238/24 dsc up up em0 up up em0.0 up up inet 128.0.0.1/2 em1 up up em1.32768 up up inet 192.168.1.2/24 em2 up up fxp0 up up fxp0.0 up up inet 192.168.2.1/24 ipip up up irb up up lo0 up up lo0.16384 up up inet 127.0.0.1 --> 0/0 lo0.16385 up up inet 10.0.0.1 --> 0/0

10.0.0.16 --> 0/0

128.0.0.1 --> 0/0

128.0.0.4 --> 0/0

128.0.1.16 --> 0/0 lo0.32768 up up lsi up up

mtun up up pimd up up pime up up pp0 up up ppd0 up up ppe0 up up st0 up up tap up up vlan up down

RELATED DOCUMENTATION libvirt Network XML Format libvirt Command Reference

Load an Initial Configuration on a vSRX with KVM

IN THIS SECTION

Create a vSRX Bootstrap ISO Image | 46

Provision vSRX with an ISO Bootstrap Image on KVM | 47

Starting in Junos OS Release 15.1X49-D40 and Junos OS Release 17.3R1, you can use a mounted ISO image to pass the initial startup Junos OS configuration to a vSRX VM. This ISO image contains a file in the root directory called juniper.conf. This file uses the standard Junos OS command syntax to define configuration details, such as root password, management IP address, default gateway, and other configuration statements.

The process to bootstrap a vSRX VM with an ISO configuration image is as follows:

1. Create the juniper.conf configuration file with your Junos OS configuration.

2. Create an ISO image that includes the juniper.conf file.

3. Mount the ISO image to the vSRX VM.

4. Boot or reboot the vSRX VM. vSRX will boot using the juniper.conf file included in the mounted ISO image.

5. Unmount the ISO image from the vSRX VM.

NOTE: If you do not unmount the ISO image after the initial boot or reboot, all subsequent configuration changes to the vSRX are overwritten by the ISO image on the next reboot.

Create a vSRX Bootstrap ISO Image

This task uses a Linux system to create the ISO image.

To create a vSRX bootstrap ISO image:

1. Create a configuration file in plaintext with the Junos OS command syntax and save in a file called

juniper.conf.

2. Create a new directory.

hostOS$ mkdir iso_dir

3. Copy juniper.conf to the new ISO directory.

hostOS$ cp juniper.conf iso_dir

NOTE: The juniper.conf file must contain the full vSRX configuration. The ISO bootstrap process overwrites any existing vSRX configuration.

4. Use the Linux mkisofs command to create the ISO image.

hostOS$ mkisofs -l -o test.iso iso_dir

I: -input-charset not specified, using utf-8 (detected in locale settings)

Total translation table size: 0

Total rockridge attributes bytes: 0

Total directory bytes: 0

Path table size(bytes): 10

Max brk space used 0

175 extents written (0 MB)

NOTE: The -l option allows for a long filename.

Provision vSRX with an ISO Bootstrap Image on KVM

To provision a vSRX VM from an ISO bootstrap image:

1. Use the virsh edit command on the KVM host server where the vSRX VM resides to add the bootstrap ISO image as a disk device.

</disk>

2. Boot or reboot the vSRX VM.

user@host# virsh start ixvSRX

Connected to domain ixvSRX

3. Optionally, use the virsh domblklist Linux command to verify that the bootstrap ISO image is part of the VM.

hostOS# virsh domblklist ixvSRX

Target Source

------------------------------------------------

hda /home/test/vsrx209.qcow2

hdc /home/test/test.iso

4. Verify the configuration, then power down the vSRX VM to remove the ISO image.

5. Use the virsh edit command on the KVM host server to remove the ISO image xml statements added in step 1, and then reboot the vSRX VM.

Release History Table

Release Description

15.1X49-D80 Starting in Junos OS Release 15.1X49-D40 and Junos OS Release 17.3R1, you can use a mounted

ISO image to pass the initial startup Junos OS configuration to a vSRX VM. This ISO image contains a file in the root directory called juniper.conf. This file uses the standard Junos OS command syntax to define configuration details, such as root password, management IP address, default gateway, and other configuration statements.

RELATED DOCUMENTATION

Linux mkisofs command

Use Cloud-Init in an OpenStack Environment to Automate the

Initialization of vSRX Instances

IN THIS SECTION

Perform Automatic Setup of a vSRX Instance Using an OpenStack Command-Line Interface | 51

Perform Automatic Setup of a vSRX Instance from the OpenStack Dashboard (Horizon) | 54

Starting in Junos OS Release 15.1X49-D100 and Junos OS Release 17.4R1, the cloud-init package

(version 0.7x) comes pre-installed in the vSRX image to help simplify configuring new vSRX instances operating in an OpenStack environment according to a specified user-data file. Cloud-init is performed during the first-time boot of a vSRX instance.

be directly used in multiple hypervisors and cloud instances without any modification. Cloud-init support in a VM instance runs at boot time (first-time boot) and initializes the VM instance according to the specified user-data file.

A user-data file is a special key in the metadata service that contains a file that cloud-aware applications in the VM instance can access upon a first-time boot. In this case, it is the validated Junos OS configuration file that you intend to upload to a vSRX instance as the active configuration. This file uses the standard Junos OS command syntax to define configuration details, such as root password, management IP address, default gateway, and other configuration statements.

When you create a vSRX instance, you can use cloud-init with a validated Junos OS configuration file

(juniper.conf) to automate the initialization of new vSRX instances. The user-data file uses the standard

Junos OS syntax to define all the configuration details for your vSRX instance. The default Junos OS configuration is replaced during the vSRX instance launch with a validated Junos OS configuration that you supply in the form of a user-data file.

NOTE: If using a release earlier than Junos OS Release 15.1X49-D130 and Junos OS Release

18.4R1, the user-data configuration file cannot exceed 16 KB. If your user-data file exceeds this limit, you must compress the file using gzip and use the compressed file. For example, the gzip junos.conf command results in the junos.conf.gz file.

Starting in Junos OS Release 15.1X49-D130 and Junos OS Release 18.4R1, if using a configuration drive data source in an OpenStack environment, the user-data configuration file size can be up to 64 MB.

The configuration must be validated and include details for the fxp0 interface, login, and authentication.

It must also have a default route for traffic on fxp0. If any of this information is missing or incorrect, the instance is inaccessible and you must launch a new one.

WARNING: Ensure that the user-data configuration file is not configured to perform autoinstallation on interfaces using Dynamic Host Configuration Protocol (DHCP) to assign an IP address to the vSRX. Autoinstallation with DHCP will result in a "commit fail" for the user-data configuration file.

Starting in Junos OS Release 15.1X49-D130 and Junos OS Release 18.4R1, the cloud-init functionality in vSRX has been extended to support the use of a configuration drive data source in an OpenStack environment. The configuration drive uses the user-data attribute to pass a validated Junos OS configuration file to the vSRX instance. The user-data can be plain text or MIME file type text/plain. The configuration drive is typically used in conjunction with the Compute service, and is present to the instance as a disk partition labeled config-2 . The configuration drive has a maximum size of 64 MB, and must be formatted with either the vfat or ISO 9660 filesystem.

The configuration drive data source also provides the flexibility to add more than one file that can be used for configuration. A typical use case would be to add a Day0 configuration file and a license file. In this case, there are two methods that can be employed to use a configuration drive data source with a vSRX instance:

• User-data (Junos OS Configuration File) alone—This approach uses the user-data attribute to pass the

Junos OS configuration file to each vSRX instance. The user-data can be plain text or MIME file type text/plain.

• Junos OS configuration file and license file—This approach uses the configuration drive data source to send the Junos OS configuration and license file(s) to each vSRX instance.

NOTE: If a license file is to be configured in vSRX, it is recommended to use the –file option rather than the user-data option to provide the flexibility to configure files larger than the 16

KB limit of user-data.

To use a configuration drive data source to send Junos OS configuration and license file(s) to a vSRX instance, the files needs to be sent in a specific folder structure. In this application, the folder structure of the configuration drive data source in vSRX is as follows:

- OpenStack

- latest

- junos-config

- configuration.txt

- junos-license

- License_file_name.lic

//OpenStack//latest/junos-config/configuration.txt

//OpenStack//latest/junos-license/license.lic

Before you begin:

• Create a configuration file with the Junos OS command syntax and save it. The configuration file can be plain text or MIME file type text/plain. The string #junos-config must be the first line of the userdata configuration file before the Junos OS configuration.

NOTE: The #junos-config string is mandatory in the user-data configuration file; if it is not included, the configuration will not be applied to the vSRX instance as the active configuration.

• Determine the name for the vSRX instance you want to initialize with a validated Junos OS configuration file.

• Determine the flavor for your vSRX instance, which defines the compute, memory, and storage capacity of the vSRX instance.

• Starting in Junos OS Release 15.1X49-D130 and Junos OS Release 18.4R1, if using a configuration drive, ensure the following criteria is met to enable cloud-init support for a configuration drive in

OpenStack:

• The configuration drive must be formatted with either the vfat or iso9660 filesystem.

NOTE: The default format of a configuration drive is an ISO 9660 file system. To explicitly specify the ISO 9660/vfat format, add the config_drive_format=iso9660/vfat line to the nova.conf

file.

• The configuration drive must have a filesystem label of config-2 .

• The folder size must be no greater than 64 MB.

Depending on your OpenStack environment, you can use either an OpenStack command-line interface

(such as nova boot or openstack server create ) or the OpenStack Dashboard (“Horizon”) to launch and initialize a vSRX instance.

Perform Automatic Setup of a vSRX Instance Using an OpenStack Command-Line

Interface

You can launch and manage a vSRX instance using either the nova boot or openstack server create commands, which includes the use of a validated Junos OS configuration user-data file from your local directory to initialize the active configuration of the target vSRX instance.

To initiate the automatic setup of a vSRX instance from an OpenStack command-line client:

1. If you have not done so already, create a configuration file with the Junos OS command syntax and save the file. The configuration file can be plain text or MIME file type text/plain.

The user-data configuration file must contain the full vSRX configuration that is to be used as the active configuration on each vSRX instance, and the string #junos-config must be the first line of the user-data configuration file before the Junos OS configuration.

NOTE: The #junos-config string is mandatory in the user-data configuration file; if it is not included, the configuration will not be applied to the vSRX instance as the active configuration.

2. Copy the Junos OS configuration file to an accessible location from where it can be retrieved to launch the vSRX instance.

3. Depending on your OpenStack environment, use the nova boot or openstack server create command to launch the vSRX instance with a validated Junos OS configuration file as the specified user-data.

NOTE: You can also use the nova boot equivalent in an Orchestration service such as HEAT.

For example:

• nova boot -user-data </path/to/vsrx_configuration.txt> --image vSRX_image --flavor vSRX_flavor_instance

• openstack server create -user-data </path/to/vsrx_configuration.txt> --image vSRX_image -flavor vSRX_flavor_instance

Where:

-user-data </path/to/vsrx_configuration.txt> specifies the location of the Junos OS configuration file. The user-data configuration file size is limited to approximately 16,384 bytes.

--image vSRX_image identifies the name of a unique vSRX image.

--flavor vSRX_flavor_instance identifies the vSRX flavor (ID or name).

Starting in Junos OS Release 15.1X49-D130 and Junos OS Release 18.4R1, to enable the use of a configuration drive for a specific request in the OpenStack compute environment, include the config-drive true parameter in the nova boot or openstack server create command.

NOTE: It is possible to enable the configuration drive automatically on all instances by configuring the OpenStack Compute service to always create a configuration drive. To do this, specify the force_config_drive=True option in the nova.conf

file.

For example, to use the user-data attribute to pass the Junos OS configuration to each vSRX instance: nova boot -config-drive true -flavor vSRX_flavor_instance -image vSRX_image -user-data </path/to/ vsrx_configuration.txt>

Where:

-user-data </path/to/vsrx_configuration.txt> specifies the location of the Junos OS configuration file. The user-data configuration file size is limited to approximately 64 MB.

-image vSRX_image identifies the name of a unique vSRX image.

-flavor vSRX_flavor_instance identifies the vSRX flavor (ID or name).

For example, to specify the configuration drive with multiple files (Junos OS configuration file and license file): nova boot -config-drive true -flavor vSRX_flavor_instance -image vSRX_image [-file /junos-config/

configuration.txt=/path/to/file] [-file /junos-license/license.lic=path/to/license]

Where:

[-file /junos-config/configuration.txt=/path/to/file] specifies the location of the Junos OS configuration file.

[-file /junos-license/license.lic=path/to/license] specifies the location of the Junos OS configuration file.

-image vSRX_image identifies the name of a unique vSRX image.

-flavor vSRX_flavor_instance identifies the vSRX flavor (ID or name).

4. Boot or reboot the vSRX instance. During the initial boot-up sequence, the vSRX instance processes the cloud-init request.

NOTE: The boot time for the vSRX instance might increase with the use of the cloud-init package. This additional time in the initial boot sequence is due to the operations performed by the cloud-init package. During this operation, the cloud-init package halts the boot sequence and performs a lookup for the configuration data in each data source identified in the cloud.cfg. The time required to look up and populate the cloud data is directly proportional to the number of data sources defined. In the absence of a data source, the lookup process continues until it reaches a predefined timeout of 30 seconds for each data source.

5. When the initial boot-up sequence resumes, the user-data file replaces the original factory-default

Junos OS configuration loaded on the vSRX instance. If the commit succeeds, the factory-default configuration will be permanently replaced. If the configuration is not supported or cannot be applied to the vSRX instance, the vSRX will boot using the default Junos OS configuration.

SEE ALSO

Cloud-Init Documentation

OpenStack command-line clients

Compute service (nova) command-line client

Openstack Server Create

Enabling the configuration drive (configdrive)

Instances

Perform Automatic Setup of a vSRX Instance from the OpenStack Dashboard

(Horizon)

Horizon is the canonical implementation of the OpenStack Dashboard. It provides a Web-based user interface to OpenStack services including Nova, Swift, Keystone, and so on. You can launch and manage a vSRX instance from the OpenStack Dashboard, which includes the use of a validated Junos OS configuration user-data file from your local directory to initialize the active configuration of the target vSRX instance.

To initiate the automatic setup of a vSRX instance from the OpenStack Dashboard:

If you have not done so already, create a configuration file with the Junos OS command syntax and save the file. The configuration file can be plain text or MIME file type text/plain.

NOTE: The #junos-config string is mandatory in the user-data configuration file; if it is not included, the configuration will not be applied to the vSRX instance as the active configuration.

Copy the Junos OS configuration file to an accessible location from where it can be retrieved to launch the vSRX instance.

Log in to the OpenStack Dashboard using your login credentials and then select the appropriate project from the drop-down menu at the top left.

On the Project tab, click the Compute tab and select Instances. The dashboard shows the various instances with its image name, its private and floating IP addresses, size, status, availability zone, task, power state, and so on.

Click Launch Instance. The Launch Instance dialog box appears.

From the Details tab (see

Figure 5 on page 55 ), enter an instance name for the vSRX VM along

with the associated availability zone (for example, Nova) and then click Next. We recommend that you keep this name the same as the hostname assigned to the vSRX VM.

Figure 5: Launch Instance Details Tab

From the Source tab (see Figure 6 on page 56

), select a vSRX VM image source file from the

Available list and then click +(Plus). The selected vSRX image appears under Allocated. Click Next.

Figure 6: Launch Instance Source Tab

From the Flavor tab (see

Figure 7 on page 57 ), select a vSRX instance with a specific compute,

memory, and storage capacity from the Available list and then click +(plus sign). The selected vSRX flavor appears under Allocated. Click Next.

Figure 7: Launch Instance Flavor Tab

From the Networks tab (see Figure 8 on page 58

), select the specific network of the vSRX instance from the Available list and then click +(plus sign). The selected network appears under Allocated.

Click Next.

NOTE: Do not update any parameters in the Network Ports, Security Groups, or Key Pair tabs in the Launch Instance dialog box.

Figure 8: Launch Instance Networks Tab

10. From the Configuration tab (see Figure 9 on page 59

), click Browse and navigate to the location of the validated Junos OS configuration file from your local directory that you want to use as the userdata file. Click Next.

Figure 9: Launch Instance Configuration Tab

11. Confirm that the loaded Junos OS configuration contains the #junos-config string in the first line of the user-data configuration file (see

Figure 10 on page 60

) and then click Next.

NOTE: Do not update any parameters in the Metadata tab of the Launch Instance dialog box.

Figure 10: Launch Instance Configuration Tab with Loaded Junos OS Configuration

12. Click Launch Instance. During the initial boot-up sequence, the vSRX instance processes the cloudinit request.

13. When the initial boot-up sequence resumes, the user-data file replaces the original factory-default

SEE ALSO

Cloud-Init Documentation

OpenStack Dashboard

Launch and Manage Instances

Horizon: The OpenStack Dashboard Project

Release History Table

Release Description

15.1X49-

D130

15.1X49-

D100

Starting in Junos OS Release 15.1X49-D100 and Junos OS Release 17.4R1, the cloud-init package

(version 0.7x) comes pre-installed in the vSRX image to help simplify configuring new vSRX instances operating in an OpenStack environment according to a specified user-data file. Cloudinit is performed during the first-time boot of a vSRX instance.

CHAPTER 3

vSRX VM Management with KVM

IN THIS CHAPTER

Configure vSRX Using the CLI | 62

Connect to the vSRX Management Console on KVM | 64

Add a Virtual Network to a vSRX VM with KVM | 65

Add a Virtio Virtual Interface to a vSRX VM with KVM | 67

Configure SR-IOV and PCI on KVM | 69

Upgrade a Multi-core vSRX | 76

Monitor the vSRX VM in KVM | 79

Manage the vSRX Instance on KVM | 80

Recover the Root Password for vSRX in a KVM Environment | 85

Configure vSRX Using the CLI

To configure the vSRX instance using the CLI:

Verify that the vSRX is powered on.

Start the CLI.

root#cli root@>

Enter configuration mode.

configure

[edit] root@#

Set the root authentication password by entering a cleartext password, an encrypted password, or an SSH public key string ( DSA or RSA).

[edit] root@# set system root-authentication plain-text-password

New password: password

Retype new password: password

Configure the hostname.

[edit] root@# set system host-name host-name

Configure the management interface.

[edit] root@# set interfaces fxp0 unit 0 family inet dhcp-client

Configure the traffic interfaces.

[edit] root@# set interfaces ge-0/0/0 unit 0 family inet dhcp-client

Configure basic security zones and bind them to traffic interfaces.

[edit] root@# set security zones security-zone trust interfaces ge-0/0/0.0

10. Verify the configuration.

[edit] root@# commit check configuration check succeeds

11. Commit the configuration to activate it on the vSRX instance.

[edit] root@# commit commit complete

12. Optionally, use the show command to display the configuration to verify that it is correct.

NOTE: Certain Junos OS software features require a license to activate the feature. To enable a licensed feature, you need to purchase, install, manage, and verify a license key that corresponds to each licensed feature. To conform to software feature licensing requirements, you must purchase one license per feature per instance. The presence of the appropriate software unlocking key on your virtual instance allows you to configure and use the licensed feature.

See Managing Licenses for vSRX for details.

RELATED DOCUMENTATION

CLI User Guide

Connect to the vSRX Management Console on KVM

Ensure that you have the virt-manager package or virsh installed on your host OS.

To connect to the vSRX management console using virt-manager :

1. Launch virt-manager .

2. Highlight the vSRX VM you want to connect to from the list of VMs displayed.

3. Click Open.

4. Select View>Text Consoles>Serial 1. The vSRX console appears.

To connect to the vSRX VM with virsh :

1. Use the virsh console command on the Linux host OS.

user@host# virsh console vSRX-kvm-2

Connected to domain vSRX-kvm-2

2. The vSRX console appears.

Add a Virtual Network to a vSRX VM with KVM

You can extend an existing vSRX VM to use additional virtual networks.

To create a virtual network with virt-manager :

1. Launch virt-manager and select Edit>Connection Details. The Connection details dialog box appears.

2. Select Virtual Networks. The list of existing virtual networks appears.

3. Click + to create a new virtual network for the control link. The Create a new virtual network wizard appears.

4. Set the subnet for this virtual network and click Forward.

5. Optionally, select Enable DHCP and click Forward.

6. Select the network type from the list and click Forward.

7. Verify the settings and click Finish to create the virtual network.

To create a virtual network with virsh :

1. Use the virsh net-define command on the host OS to create an XML file that defines the new virtual

network. Include the XML fields described in Table 12 on page 66

to define this network.

NOTE: See the official virsh documentation for a complete description of available options, including how to configure IPv6 networks.

Table 12: virsh net-define XML Fields

Field Description

<network>...</network> Use this XML wrapper element to define a virtual network.

Specify the virtual network name.

Specify the name of the host bridge used for this virtual network.

<forward mode=” forward-option” /> Specify routed or nat. Do not use the <forward> element for isolated mode.

<ip address=” ip-address” netmask=” net-mask”

Specify the IP address and subnet mask used by this virtual network, along with the DHCP address range.

The following example shows a sample XML file that defines a new virtual network.

<dhcp>

</dhcp>

</ip>

</network>

2. Use the virsh net-start command in the host OS to start the new virtual network.

hostOS# virsh net-start mgmt

3. Use the virsh net-autostart command in the host OS to automatically start the new virtual network when the host OS boots.

hostOS# virsh net-autostart mgmt

4. Optionally, use the virsh net-list –all command in the host OS to verify the new virtual network.

HostOS# # virsh net-list --all

Name State Autostart Persistent

----------------------------------------------------------

mgmt active yes yes

default active yes yes

RELATED DOCUMENTATION virt tools

Add a Virtio Virtual Interface to a vSRX VM with KVM

You can add additional virtio virtual interfaces to an existing vSRX VM with KVM.

To add additional virtio virtual interfaces to a vSRX VM using virt-manager :

1. In virt-manager , double-click the vSRX VM and select View>Details. The vSRX Virtual Machine details dialog box appears.

2. Click Add Hardware. The Add Hardware dialog box appears.

3. Select Network from the left navigation panel.

4. Select the host device or virtual network on which you want this new virtual interface from the

Network source list.

5. Select virtio from the Device model list and click Finish.

6. From the vSRX console, reboot the vSRX instance.

vsrx# request system reboot.

vSRX reboots both Junos OS and the vSRX guest VM.

To add additional virtio virtual interfaces to a vSRX VM using virsh :

1. Use the virsh attach-interface command on the host OS with the mandatory options listed in

Table

13 on page 68

NOTE: See the official virsh documentation for a complete description of available options.

Table 13: virsh attach-interface Options

Command Option Description

--domain name Specify the name of the guest VM.

--type Specify the host OS connection type as bridge or network .

--source interface Specify the physical or logical interface on the host OS to associate with this vNIC.

--target vnic

--model

Specify the name for the new vNIC.

Specify the vNIC model.

The following example creates a new virtio vNIC from the host OS virbr0 bridge.

user@host# virsh attach-interface --domain vsrxVM --type bridge --source virbr0 --target vsrx- mgmt --model virtio

Interface attached successfully user@host# virsh dumpxml vsrxVM

</interface>

2. From the vSRX console, reboot the vSRX instance.

vsrx# request system reboot.

vSRX reboots both Junos OS and the VSRX guest VM.

RELATED DOCUMENTATION virt tools

Configure SR-IOV and PCI on KVM

IN THIS SECTION

SR-IOV Overview | 69

SR-IOV HA Support with Trust Mode Disabled (KVM only) | 70

Configure an SR-IOV Interface on KVM | 72

This section includes the following topics on SR-IOV for a vSRX instance deployed on KVM:

SR-IOV Overview

vSRX on KVM supports single-root I/O virtualization ( SR-IOV) interface types. SR-IOV is a standard that allows a single physical NIC to present itself as multiple vNICs, or virtual functions (VFs), that a virtual machine (VM) can attach to. SR-IOV combines with other virtualization technologies, such as Intel VT-d, to improve the I/O performance of the VM. SR-IOV allows each VM to have direct access to packets queued up for the VFs attached to the VM. You use SR-IOV when you need I/O performance that approaches that of the physical bare metal interfaces.

NOTE: SR-IOV in KVM does not remap interface numbers. The interface sequence in the vSRX

VM XML file matches the interface sequence shown in the Junos OS CLI on the vSRX instance.

SR-IOV uses two PCI functions:

• Physical Functions (PFs)—Full PCIe devices that include SR-IOV capabilities. Physical Functions are discovered, managed, and configured as normal PCI devices. Physical Functions configure and manage the SR-IOV functionality by assigning Virtual Functions. When SR-IOV is disabled, the host creates a single PF on one physical NIC.

• Virtual Functions (VFs)—Simple PCIe functions that only process I/O. Each Virtual Function is derived from a Physical Function. The number of Virtual Functions a device may have is limited by the device hardware. A single Ethernet port, the Physical Device, may map to many Virtual Functions that can be shared to guests. When SR-IOV is enabled, the host creates a single PF and multiple VFs on one physical NIC. The number of VFs depends on the configuration and driver support.

SR-IOV HA Support with Trust Mode Disabled (KVM only)

IN THIS SECTION

Understand SR-IOV HA Support with Trust Mode Disabled (KVM only) | 70

Configure SR-IOV support with Trust Mode Disabled (KVM only) | 71

Limitations | 72

Understand SR-IOV HA Support with Trust Mode Disabled (KVM only)

A Redundant Ethernet Interface (RETH) is a virtual interface consisting of equal number of member interfaces from each participating node of an SRX cluster. All logical configurations such as IP address,

QoS, zones, and VPNs are bound to this interface. Physical properties are applied to the member or child interfaces. A RETH interface has a virtual MAC address which is calculated using the cluster id. RETH has been implemented as an aggregated interface/LAG in Junos OS. For a LAG, the parent (logical) IFDs

MAC address is copied to each of the child interfaces. When you configure the child interface under the

RETH interface, the RETH interface’s virtual MAC gets overwritten on the current MAC address field of the child physical interface. This also requires the virtual MAC address to be programmed on the corresponding NIC.

Junos OS runs as a VM on vSRX. Junos OS does not have direct access to the NIC and only has a virtual

NIC access provided by the hypervisor which might be shared with other VMs running on the same host

machine. This virtual access comes with certain restrictions such as a special mode called trust mode, which is required to program a virtual MAC address on the NIC. During deployments, providing the trust mode access might not be feasible because of possible security issues. To enable RETH model to work in such environments, MAC rewrite behavior is modified. Instead of copying the parent virtual MAC address to the children, we keep the children’s physical MAC address intact and copy the physical MAC address of the child belonging to the active node of the cluster to the current MAC of the reth interface.

This way, MAC rewrite access is not required when trust mode is disabled.

In case of vSRX, the DPDK reads the physical MAC address provided by the hypervisor and shares it with the Junos OS control plane. In standalone mode, this physical MAC address is programmed on the physical IFDs. But the support for the same is unavailable in cluster mode, because of which the MAC address for the physical interface is taken from the Juniper reserved MAC pool. In an environment where trust mode is not feasible, the hypervisor is unable to provide the physical MAC address.

To overcome this problem, we have added support to use the hypervisor provided physical MAC address

instead of allocating it from the reserved MAC pool. See "Configure SR-IOV support with Trust Mode

Disabled (KVM only)" on page 71 .

Configure SR-IOV support with Trust Mode Disabled (KVM only)

Figure 11: Copying MAC address from active child interface to parent RETH

Starting in Junos OS Release 19.4R1, SR-IOV HA is supported with trust mode disabled. You can enable this mode by configuring the use-active-child-mac-on-reth and use-actual-mac-on-physical-interfaces configuration statements at the [edit chassis cluster] hierarchy level. If you configure commands in a

cluster, the hypervisor assigns the child physical interface’s MAC address and the parent RETH interface’s MAC address is overwritten by the active child physical interface’s MAC address

You need to reboot the vSRX instance to enable this mode. Both the nodes in the cluster need to be rebooted for the commands to take effect.

You need to configure the commands use-active-child-mac-on-reth and use-actual-mac-on-physicalinterfaces together to enable this feature.

SEE ALSO use-active-child-mac-on-reth use-actual-mac-on-physical-interfaces

Limitations

SR-IOV HA support with trust mode disabled on KVM has the following limitations:

• SR-IOV HA support with trust mode disabled is only supported on KVM based systems.

• A reth interface can have maximum one port as a member on each vSRX cluster node.

• You cannot use security nat proxy-arp feature for NAT pools because no G-ARP is sent out on failover for the IP addresses in NAT pools. Instead, one can set the routes to the NAT pool range in the upstream router to point to the vSRX reth interface’s IP address as the next-hop. Or, if directly connected hosts need to access the NAT pool addresses, these NAT pool addresses can be configured for proxy ARP under the reth interface.

• If the reth interface is configured with many VLANs, it might take some time to send all the G-ARPs on a failover. This might lead to a noticeable interruption in traffic.

• A dataplane failover will result in a change of the MAC address of the reth interface. Therefore the failover is not transparent to directly connected neighboring Layer 3 devices (routers or servers). The vSRX reth IP address must be mapped to a new MAC address in the ARP table on the neighboring devices. vSRX will send out a G-ARP which will help these devices. In case these neighboring devices do not act on the G-ARP received from the vSRX or show a slow response, the traffic might be interrupted until that device updates it’s ARP table correctly.

Configure an SR-IOV Interface on KVM

If you have a physical NIC that supports SR-IOV, you can attach SR-IOV-enabled vNICs or virtual functions (VFs) to the vSRX instance to improve performance. We recommend that if you use SR-IOV, all revenue ports are configured as SR-IOV.

Note the following about SR-IOV support for vSRX on KVM:

• Starting in Junos OS Release 15.1X49-D90 and Junos OS Release 17.3R1, a vSRX instance deployed on KVM supports SR-IOV on an Intel X710/XL710 NIC in addition to Intel 82599 or X520/540.

• Starting in Junos OS Release 18.1R1, a vSRX instance deployed on KVM supports SR-IOV on the

Mellanox ConnectX-3 and ConnectX-4 Family Adapters.

NOTE: See the

vSRX Performance Scale Up discussion in "Understand vSRX with KVM" on page

for the vSRX scale up performance when deployed on KVM, based on vNIC and the number of vCPUs and vRAM applied to a vSRX VM.

Before you can attach an SR-IOV enabled VF to the vSRX instance, you must complete the following tasks:

• Insert an SR-IOV-capable physical network adapter in the host server.

• Enable the Intel VT-d CPU virtualization extensions in BIOS on your host server. The Intel VT-d extensions provides hardware support for directly assigning a physical devices to guest. Verify the process with the vendor because different systems have different methods to enable VT-d.

• Ensure that SR-IOV is enabled at the system/server BIOS level by going into the BIOS settings during the host server boot-up sequence to confirm the SR-IOV setting. Different server manufacturers have different naming conventions for the BIOS parameter used to enable SR-IOV at the BIOS level.

For example, for a Dell server ensure that the SR-IOV Global Enable option is set to Enabled.

NOTE: We recommend that you use virt-manager to configure SR-IOV interfaces. See the virsh attach-device command documentation if you want to learn how to add a PCI host device to a

VM with the virsh CLI commands.

To add an SR-IOV VF to a vSRX VM using the virt-manager graphical interface:

1. In the Junos OS CLI, shut down the vSRX VM if it is running.

vsrx> request system power-off

2. In virt-manager , double-click the vSRX VM and select View>Details. The vSRX Virtual Machine details dialog box appears.

3. Select the Hardware tab, then click Add Hardware. The Add Hardware dialog box appears.

4. Select PCI Host Device from the Hardware list on the left.

5. Select the SR-IOV VF for this new virtual interface from the host device list.

6. Click Finish to add the new device. The setup is complete and the vSRX VM now has direct access to the device.

7. From the virt-manager icon bar at the upper-left side of the window, click the Power On arrow. The vSRX VM starts. Once the vSRX is powered on the Running status will display in the window.

You can connect to the management console to watch the boot-up sequence.

NOTE: After the boot starts, you need to select View>Text Consoles>Serial 1 in virt-manager to connect to the vSRX console.

To add an SR-IOV VF to a vSRX VM using virsh CLI commands:

1. Define four virtual functions for eno2 interface, update the sriov_numvfs file with number 4.

root@LabHost:~# echo 4 > /sys/class/net/eno2/device/sriov_numvfs root@LabHost:~# more /sys/class/net/eno2/device/sriov_numvfs

2. Identify the device.

Identify the PCI device designated for device assignment to the virtual machine. Use the lspci command to list the available PCI devices. You can refine the output of lspci with grep .

Use command lspci to check the VF number according to the VF ID.

root@ kvmsrv:~# lspci | grep Ether

……

83:00.0 Ethernet controller: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ (rev

02) - Physical Function

83:00.1 Ethernet controller: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ (rev

02) - Physical Function

83:02.0 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02)

83:02.1 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02)

83:02.2 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02)

83:02.3 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02)

83:02.4 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02)

83:02.5 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02)

83:02.6 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02)

83:02.7 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02)

83:0a.0 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02)

83:0a.1 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02)

83:0a.2 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02)

83:0a.3 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02)

83:0a.4 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02)

83:0a.5 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02)

83:0a.6 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02)

83:0a.7 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02)

………

3. Add SR-IOV device assignment from a vSRX XML profile on KVM and review device information.

The driver could use either vfio or kvm, depends on KVM server OS/kernel version and drivers for virtualization support. The address type references the unique PCI slot number for each SR-IOV VF

(Virtual Function).

Information on the domain, bus, and function are available from output of the virsh nodedev-dumpxml command.

</source>

</interface>

4. Add PCI device in edit setting and select VF according to the VF number.

NOTE: This operation should be done when VM is powered off. Also, do not clone VMs with

PCI devices which might lead to VF or MAC conflict.

5. Start the VM using the # virsh start name of virtual machine command.

Release History Table

Release Description

18.1R1

Starting in Junos OS Release 18.1R1, a vSRX instance deployed on KVM supports SR-IOV on the

Mellanox ConnectX-3 and ConnectX-4 Family Adapters.

15.1X49-D90 Starting in Junos OS Release 15.1X49-D90 and Junos OS Release 17.3R1, a vSRX instance deployed on KVM supports SR-IOV on an Intel X710/XL710 NIC in addition to Intel 82599 or

X520/540.

RELATED DOCUMENTATION

Requirements for vSRX on KVM | 7

Intel SR-IOV Explanation

PCI-SIG SR-IOV Primer

SR-IOV

Intel - SR-IOV Configuration Guide

Red Hat - SR–IOV - PCI Devices

Upgrade a Multi-core vSRX

IN THIS SECTION

Configure the Queue Value for vSRX VM with KVM | 77

Shutdown the vSRX Instance with virt-manager | 77

Upgrade vSRX with virt-manager | 78

Starting in Junos OS Release 15.1X49-D70 and Junos OS Release 17.3R1, you can use virt-manager to scale the performance and capacity of a vSRX instance by increasing the number of vCPUs or the

amount of vRAM allocated to the vSRX. See "Requirements for vSRX on KVM" on page 7 for the

software requirement specifications for a vSRX VM.

See your host OS documentation for complete details on the virt-manager package

NOTE: You cannot scale down the number of vCPUs or decrease the amount of vRAM for an existing vSRX VM.

Configure the Queue Value for vSRX VM with KVM

Before you plan to scale up vSRX performance, modify the vSRX VM XML file to configure network multi-queuing as a means to support an increased number of dataplane vCPUs for the vSRX VM. This setting updates the libvirt driver to enable multi-queue virtio-net so that network performance can scale as the number of dataplane vCPUs increases. Multi-queue virtio is an approach that enables the processing of packet sending and receiving to be scaled to the number of available virtual CPUs (vCPUs) of a guest, through the use of multiple queues.

The configuration of multi-queue virtio-net, however, can only be performed in the XML file. OpenStack does not support multi-queue.

To update the queue, at the <driver name='vhost' queues='x'/> line in the vSRX VM XML file, match the number of queues with number of dataplane vCPUs you plan to configure for the vSRX VM. The default is 4 dataplane vCPUs, but you can scale that number to 4, 8, or 16 vCPUs.

The following XML file example configures 8 queues for a vSRX VM with 8 dataplane vCPUs:

</interface>

Shutdown the vSRX Instance with virt-manager

In situations where you want to edit and modify the vSRX VM XML file, you need to completely shut down vSRX and the associated VM.

To gracefully shutdown the vSRX instance with virt-manager :

1. Launch virt-manager .

2. Check the vSRX instance you want to power off.

3. Select Open to open a console window to the vSRX instance.

4. From the vSRX console, reboot the vSRX instance.

vsrx# request system power-off.

5. From virt-manager , select Shut Down to completely shutdown the VM so you can edit the XML file.

NOTE: Do not use Force Reset or Force Off on any active VM as it may create file corruptions.

Upgrade vSRX with virt-manager

You must shut down the vSRX VM before you can update vCPU or vRAM values for the VM.

You can upgrade and launch vSRX with the KVM virt-manager GUI package.

To scale up a vSRX VM with virt-manager to a higher number of vCPUs or to an increased amount of vRAM:

1. On your host OS, type virt-manager. The Virtual Machine Manager appears. See

Figure 12 on page

78 .

NOTE: You must have admin rights on the host OS to use virt-manager .

Figure 12: virt-manager

2. Select Open to open the powered down vSRX VM and select Edit Hardware Details to open the virtual machine details window.

3. Select Processor and set the number of vCPUs. Click Apply.

4. Select Memory and set the vRAM to the desired size. Click Apply.

5. Click Power On. The VM manager launches the vSRX VM with the new vCPU and vRAM settings.

NOTE: vSRX scales down to the closest supported value if the vCPU or vRAM settings do not match what is currently available.

Release History Table

Release Description

15.1X49-D70 Starting in Junos OS Release 15.1X49-D70 and Junos OS Release 17.3R1, you can use virtmanager to scale the performance and capacity of a vSRX instance by increasing the number of vCPUs or the amount of vRAM allocated to the vSRX

RELATED DOCUMENTATION

Understand vSRX with KVM | 2

Requirements for vSRX on KVM | 7

Installing a virtual machine using virt-install

Monitor the vSRX VM in KVM

You can monitor the overall state of the vSRX VM with virt-manager or virsh .

To monitor the vSRX VM with virt-manager :

1. From the virt-manager GUI, select the vSRX VM you want to monitor.

2. Select View>Graph and select the statistics you want to monitor. Options include CPU, memory, disk

I/O, and network interface statistics.

The window updates with thumbnail graphs for the statistics you selected.

3. Optionally, double-click on the thumbnail graph to expand the view.

To monitor the vSRX VM with virsh , use the commands listed in

Table 14 on page 79 .

Table 14: virsh Monitor Commands

Command Description virsh cpu-stats vm-name Lists the CPU statistics for the VM.

Table 14: virsh Monitor Commands (Continued)

Command virsh domifstat vm-name interface-name virsh dommemstat vm-name virsh vcpuinfo vm-name virsh nodecpustats

Description

Displays the vNIC statistics for the VM.

Displays memory statistics for the VM.

Displays vCPU details for the VM.

Displays CPU statistics for the host OS.

RELATED DOCUMENTATION virt tools

Manage the vSRX Instance on KVM

IN THIS SECTION

Power On the vSRX Instance with virt-manager | 81

Power On the vSRX Instance with virsh | 81

Pause the vSRX Instance with virt-manager | 81

Pause the vSRX Instance with virsh | 81

Rebooting the vSRX Instance with virt-manager | 82

Reboot the vSRX Instance with virsh | 82

Power Off the vSRX Instance with virt-manager | 82

Power Off the vSRX Instance with virsh | 83

Shutdown the vSRX Instance with virt-manager | 83

Shutdown the vSRX Instance with virsh | 84

Remove the vSRX Instance with virsh | 84

Each vSRX instance is an independent VM that you can power on, pause, or shut down. You can manage the vSRX VM with multiple tools, including virt-manager and virsh .

Power On the vSRX Instance with virt-manager

To power on the vSRX instance with virt-manager :

1. Launch virt-manager .

2. Check the vSRX instance you want to power on.

3. From the icon bar, select the power on arrow. The vSRX VM starts. You can connect to the management console to watch the boot-up sequence.

NOTE: After the boot starts, you need to select View>Text Consoles>Serial 1 in virt-manager to connect to the vSRX console.

Power On the vSRX Instance with virsh

To power on the vSRX instance with virsh :

Use the virsh start command on the host OS to start a vSRX VM.

user@host# virsh start vSRX-kvm-2

Domain vSRX-kvm-2 started

Pause the vSRX Instance with virt-manager

To pause the vSRX instance with virt-manager :

1. Launch virt-manager .

2. Check the vSRX instance you want to pause.

3. From the icon bar, select the power on pause icon. The vSRX VM pauses.

Pause the vSRX Instance with virsh

To pause the vSRX instance with virsh :

Use the virsh suspend command on the host OS to pause a vSRX VM.

user@host# virsh suspend vSRX-kvm-2

Domain vSRX-kvm-2 suspended

Rebooting the vSRX Instance with virt-manager

To reboot the vSRX instance with virt-manager :

1. Launch virt-manager .

2. Check the vSRX instance you want to reboot.

3. Select Open to open a console window to the vSRX instance.

4. From the vSRX console, reboot the vSRX instance.

vsrx# request system reboot.

vSRX reboots both Junos OS and the VSRX guest VM.

Reboot the vSRX Instance with virsh

To reboot the vSRX VM with virsh :

1. Use the virsh console command on the host OS to connect to the vSRX VM.

2. On the vSRX console, use the request system reboot command to reboot Junos OS and the vSRX

VM.

user@host# virsh console vSRX-kvm-2

Connected to domain vSRX-kvm-2 vsrx# request system reboot

Power Off the vSRX Instance with virt-manager

To power off the vSRX instance with virt-manager :

1. Launch virt-manager .

2. Check the vSRX instance you want to power off.

3. Select Open to open a console window to the vSRX instance.

4. From the vSRX console, power off the vSRX instance.

vsrx> request system power-off vSRX powers off both Junos OS and the guest VM.

Power Off the vSRX Instance with virsh

To power off the vSRX instance with virsh :

1. Use the virsh console command on the host OS to connect to the vSRX VM.

2. On the vSRX console, use the request system power-off command to power off Junos OS and the vSRX VM.

user@host# virsh console vSRX-kvm-2

Connected to domain vSRX-kvm-2 vsrx# request system power-off

Shutdown the vSRX Instance with virt-manager

In situations where you want to edit and modify the vSRX VM XML file, you need to completely shut down vSRX and the associated VM.

To gracefully shutdown the vSRX instance with virt-manager :

1. Launch virt-manager .

2. Check the vSRX instance you want to power off.

3. Select Open to open a console window to the vSRX instance.

4. From the vSRX console, reboot the vSRX instance.

vsrx# request system power-off.

5. From virt-manager , select Shut Down to completely shutdown the VM so you can edit the XML file.

NOTE: Do not use Force Reset or Force Off on any active VM as it may create file corruptions.

Shutdown the vSRX Instance with virsh

In situations where you want to modify the vSRX VM XML file, you need to completely shut down vSRX and the associated VM.

To gracefully shutdown the vSRX instance with virsh :

1. Use the virsh console command on the host OS to connect to the vSRX VM.

2. On the vSRX console, use the request system power-off command to power off Junos OS and the vSRX VM.

3. On the host OS, use the virsh shutdown command to shut down the VM after vSRX has powered off.

user@host# virsh console vSRX-kvm-2

Connected to domain vSRX-kvm-2 vsrx# request system power-off user@host# virsh shutdown vSRX-kvm-2

NOTE: Do not use the virsh destroy command on any active VM as it may create file corruptions.

Remove the vSRX Instance with virsh

In situations where you want to completely remove the vSRX instance, you need to destroy the vSRX

VM and undefine the associated XML file.

To completely remove the vSRX instance with virsh :

1. On the host OS, use the virsh destroy command to destroy the vSRX VM.

2. On the host OS, use the virsh undefine command to undefine the vSRX XML file.

user@host# virsh destroy vSRX-kvm-2 user@host# virsh undefine vSRX-kvm-2

RELATED DOCUMENTATION virt tools

Recover the Root Password for vSRX in a KVM Environment

If you forget the root password for a vSRX instance deployed in a KVM environment, use this password recovery procedure to reset the root password. (KB article 31790).

NOTE: You need console access to recover the root password

To recover the root password for a vSRX instance:

Reboot the vSRX instance by entering the virsh reboot command, specifying either domain-id or domain-name .

Immediately attempt to login to the vSRX instance by entering the virsh console domain-name command to access the vSRX console.

NOTE: We recommend that you specify domain-name when attempting the vSRX instance login. It is possible that domain-id might change after the vSRX instance reboot.

After login you will see a prompt similar to Escape character is ^] . Press Enter two or three times until the boot process begins. Continue with the boot process until you see the following prompt:

Hit [Enter] to boot immediately, or space bar for command prompt. Booting [kernel] in 9 seconds...

Press the space bar two or three times to stop the boot sequence, and then enter boot -s to login to single-user mode.

Enter recovery to start the root password recovery procedure.

Enter full pathname of shell or 'recovery' for root password recovery or RETURN for /bin/ sh: recovery

Once the script terminates you will be in vSRX operational mode.

Enter configuration mode in the CLI.

Set the root password.

[edit] user@host# set system root-authentication plain-text-password

Enter the new root password.

New password: xxxxxxxx

Retype new password:

At the second prompt, reenter the new root password.

10. If you are finished configuring the new root password for the vSRX instance, commit the configuration.

root@host# commit commit complete

11. Exit from configuration mode.

12. Exit from operational mode.

13. Enter y to reboot the device.

Reboot the system? [y/n] y

The start up messages display on the screen.

14. Once again, press the space bar two or three times to access the bootstrap loader prompt.

15. The vSRX instance starts up again and prompts you to enter a user name and password. Enter the newly configured password.

Password: xxxxxxxx

CHAPTER 4

Configure vSRX Chassis Clusters on KVM

IN THIS CHAPTER

Configure a vSRX Chassis Cluster in Junos OS | 87

vSRX Cluster Staging and Provisioning for KVM | 98

Verify the Chassis Cluster Configuration | 103

Configure a vSRX Chassis Cluster in Junos OS

IN THIS SECTION

Chassis Cluster Overview | 87

Enable Chassis Cluster Formation | 88

Chassis Cluster Quick Setup with J-Web | 89

Manually Configure a Chassis Cluster with J-Web | 91

Chassis Cluster Overview

Chassis cluster groups a pair of the same kind of vSRX instances into a cluster to provide network node redundancy. The vSRX instances in a chassis cluster must be running the same Junos OS release, and each instance becomes a node in the chassis cluster. You connect the control virtual interfaces on the respective nodes to form a control plane that synchronizes the configuration and Junos OS kernel state on both nodes in the cluster. The control link (a virtual network or vSwitch) facilitates the redundancy of interfaces and services. Similarly, you connect the data plane on the respective nodes over the fabric virtual interfaces to form a unified data plane. The fabric link (a virtual network or vSwitch) allows for the management of cross-node flow processing and for the management of session redundancy.

The control plane software operates in active/passive mode. When configured as a chassis cluster, one node acts as the primary and the other as the secondary to ensure stateful failover of processes and

services in the event of a system or hardware failure on the primary . If the primary fails, the secondary takes over processing of control plane traffic.

NOTE: If you configure a chassis cluster across two hosts, disable igmp-snooping on the bridge that each host physical interface belongs to and that the control virtual NICs (vNICs) use. This ensures that the control link heartbeat is received by both nodes in the chassis cluster.

The chassis cluster data plane operates in active/active mode. In a chassis cluster, the data plane updates session information as traffic traverses either node, and it transmits information between the nodes over the fabric link to guarantee that established sessions are not dropped when a failover occurs.

In active/active mode, traffic can enter the cluster on one node and exit from the other node.

Chassis cluster functionality includes:

• Resilient system architecture, with a single active control plane for the entire cluster and multiple

Packet Forwarding Engines. This architecture presents a single device view of the cluster.

• Synchronization of configuration and dynamic runtime states between nodes within a cluster.

• Monitoring of physical interfaces, and failover if the failure parameters cross a configured threshold.

• Support for generic routing encapsulation ( GRE) and IP-over-IP (IP-IP) tunnels used to route encapsulated IPv4 or IPv6 traffic by means of two internal interfaces, gr-0/0/0 and ip-0/0/0, respectively. Junos OS creates these interfaces at system startup and uses these interfaces only for processing GRE and IP-IP tunnels.

At any given instant, a cluster node can be in one of the following states: hold, primary, secondary-hold, secondary, ineligible, or disabled. Multiple event types, such as interface monitoring, Services Processing

Unit (SPU) monitoring, failures, and manual failovers, can trigger a state transition.

Enable Chassis Cluster Formation

You create two vSRX instances to form a chassis cluster, and then you set the cluster ID and node ID on each instance to join the cluster. When a vSRX instance joins a cluster, it becomes a node of that cluster.

With the exception of unique node settings and management IP addresses, nodes in a cluster share the same configuration.

You can deploy up to 255 chassis clusters in a Layer 2 domain. Clusters and nodes are identified in the following ways:

• The cluster ID (a number from 1 to 255) identifies the cluster.

• The node ID (a number from 0 to 1) identifies the cluster node.

Generally, on SRX Series devices, the cluster ID and node ID are written into EEPROM. On the vSRX instance, vSRX stores and reads the IDs from boot/loader.conf and uses the IDs to initialize the chassis cluster during startup.

Prerequisites

Ensure that your vSRX instances comply with the following prerequisites before you enable chassis clustering:

• You have committed a basic configuration to both vSRX instances that form the chassis cluster. See

"Configure vSRX Using the CLI" on page 62

• Use show version in Junos OS to ensure that both vSRX instances have the same software version.

• Use show system license in Junos OS to ensure that both vSRX instances have the same licenses installed.

You must set the same chassis cluster ID on each vSRX node and reboot the vSRX VM to enable chassis cluster formation.

1. In operational command mode, set the chassis cluster ID and node number on vSRX node 0.

user@vsrx0>set chassis cluster cluster-id number node 0 reboot

2. In operational command mode, set the chassis cluster ID and node number on vSRX node 1.

user@vsrx1>set chassis cluster cluster-id number node 1 reboot

NOTE: The vSRX interface naming and mapping to vNICs changes when you enable chassis clustering. See

"Requirements for vSRX on KVM" on page 7

for a summary of interface names and mappings for a pair of vSRX VMs in a cluster (node 0 and node 1).

Chassis Cluster Quick Setup with J-Web

To configure chassis cluster from J-Web:

Enter the vSRX node 0 interface IP address in a Web browser.

Enter the vSRX username and password, and click Log In. The J-Web dashboard appears.

Click Configuration Wizards> Cluster (HA) Setup from the left panel. The Chassis Cluster Setup

Wizard appears. Follow the steps in the setup wizard to configure the cluster ID and the two nodes in the cluster, and to verify connectivity.

NOTE: Use the built-in Help icon in J-Web for further details on the Chassis Cluster Setup wizard.

NOTE: Navigate to Configure>Device Settings>Cluster (HA) Setup from Junos OS release

18.1 and later to configure the chassis cluster setup.

Configure the secondary node Node1 by selecting Yes, this is the secondary unit to be setup (Node

1) using radio button.

Click Next.

Specify the settings such as Enter password, Re-enter password, Node 0 FXP0 IP, and Node 1 FXP0

IP for secondary node access.

Click Next.

Select the secondary unit’s Control Port and Fabric Port.

Click Next.

10. (Optional) Select Save a backup file before proceeding with shutdown using check box to reconfigure it for chassis cluster.

11. Click Next.

12. Click Shutdown and continue to connect to other unit.

13. Click Refresh Browser.

14. Configure the primary node Node0 by selecting No, this is the primary unit to be setup (Node 0) to configure primary unit and establish a chassis cluster configuration.

15. Click Next.

16. Specify the settings such as Enter password, Re-enter password, Node 0 FXP0 IP, and Node 1 FXP0

IP for primary node access.

17. Click Next to restart the primary unit.

18. (Optional) Select Save a backup file before proceeding with shutdown to save a backup file of current settings before proceeding.

19. Click Reboot and continue. After completing the reboot, power on the secondary unit to establish the chassis cluster connection.

20. Login to the device console and add static route to get the J-Web access.

21. Login to the J-Web and click Configuration Wizards> Cluster (HA) Setup from the left panel. The

Chassis Cluster Setup Wizard appears.

22. Click Next to get the primary unit connected.

23. Configure the basic settings DHCP Client, IP address, Default gateway, Member interface Node 0,

Member interface Node 1.

24. Click Next to complete the chassis cluster configuration.

25. Click Finish to exit the wizard. You can access the primary node using J-Web.

Manually Configure a Chassis Cluster with J-Web

You can use the J-Web interface to configure the primary node 0 vSRX instance in the cluster. Once you have set the cluster and node IDs and rebooted each vSRX, the following configuration will automatically be synced to the secondary node 1 vSRX instance.

Select Configure>Chassis Cluster>Cluster Configuration. The Chassis Cluster configuration page appears.

NOTE: Navigate to Configure>Device Settings>Cluster (HA) Setup from Junos OS release 18.1

and later to configure the HA cluster setup.

Table 15 on page 91

explains the contents of the HA Cluster Settings tab.

Table 16 on page 93

explains how to edit the Node Settings tab.

Table 17 on page 94

explains how to add or edit the HA Cluster Interfaces table.

Table 18 on page 95

explains how to add or edit the HA Cluster Redundancy Groups table.

Table 15: Chassis Cluster Configuration Page

Field Function

Node Settings

Node ID

Cluster ID

Displays the node ID.

Displays the cluster ID configured for the node.

Host Name

Backup Router

Management Interface

Displays the name of the node.

Displays the router used as a gateway while the Routing Engine is in secondary state for redundancy-group 0 in a chassis cluster.

Displays the management interface of the node.

Table 15: Chassis Cluster Configuration Page (Continued)

Field Function

IP Address Displays the management IP address of the node.

Status Displays the state of the redundancy group.

• Primary–Redundancy group is active.

• Secondary–Redundancy group is passive.

Chassis Cluster>HA Cluster Settings>Interfaces

Name Displays the physical interface name.

Member Interfaces/IP

Address

Displays the member interface name or IP address configured for an interface.

Redundancy Group Displays the redundancy group.

Chassis Cluster>HA Cluster Settings>Redundancy Group

Group

Preempt

Gratuitous ARP Count

Displays the redundancy group identification number.

Displays the selected preempt option.

• True–Primary Role can be preempted based on priority.

• False–Primary Role cannot be preempted based on priority.

Displays the number of gratuitous Address Resolution Protocol ( ARP) requests that a newly elected primary device in a chassis cluster sends out to announce its presence to the other network devices.

Table 15: Chassis Cluster Configuration Page (Continued)

Field Function

Node Priority Displays the assigned priority for the redundancy group on that node.

The eligible node with the highest priority is elected as primary for the redundant group.

Table 16: Edit Node Setting Configuration Details

Field Function

Node Settings

Action

Host Name Specifies the name of the host.

Backup Router Displays the device used as a gateway while the

Routing Engine is in the secondary state for redundancy-group 0 in a chassis cluster.

Enter the name of the host.

Enter the IP address of the backup router.

Destination

IP Adds the destination address.

Deletes the destination address.

Delete

Interface

Click Add.

Click Delete.

Specifies the interfaces available for the router.

NOTE: Allows you to add and edit two interfaces for each fabric link.

Specifies the interface IP address.

Select an option.

Enter the interface IP address.

Table 16: Edit Node Setting Configuration Details (Continued)

Field Function

Add Adds the interface.

Delete Deletes the interface.

Table 17: Add HA Cluster Interface Configuration Details

Field Function

Fabric Link > Fabric Link 0 (fab0)

Action

Click Add.

Click Delete.

Interface

Add

Specifies fabric link 0.

Adds fabric interface 0.

Delete Deletes fabric interface 0.

Fabric Link > Fabric Link 1 (fab1)

Interface Specifies fabric link 1.

Enter the interface IP fabric link 0.

Click Add.

Click Delete.

Add

Delete

Adds fabric interface 1.

Deletes fabric interface 1.

Enter the interface IP for fabric link

Click Add.

Click Delete.

Redundant Ethernet

Interface Specifies a logical interface consisting of two physical Ethernet interfaces, one on each chassis.

Enter the logical interface.

Table 17: Add HA Cluster Interface Configuration Details (Continued)

Field Function Action

IP Specifies a redundant Ethernet IP address.

Enter a redundant Ethernet IP address.

Redundancy Group Specifies the redundancy group ID number in the chassis cluster.

Select a redundancy group from the list.

Add

Delete

Adds a redundant Ethernet IP address.

Table 18: Add Redundancy Groups Configuration Details

Field Function

Redundancy Group Specifies the redundancy group name.

Click Add.

Deletes a redundant Ethernet IP address.

Click Delete.

Action

Enter the redundancy group name.

Allow preemption of primaryship

Allows a node with a better priority to initiate a failover for a redundancy group.

NOTE: By default, this feature is disabled.

When disabled, a node with a better priority does not initiate a redundancy group failover

(unless some other factor, such as faulty network connectivity identified for monitored interfaces, causes a failover).

–

Gratuitous ARP

Count

Specifies the number of gratuitous Address

Resolution Protocol requests that a newly elected primary sends out on the active redundant Ethernet interface child links to notify network devices of a change in primary role on the redundant Ethernet interface links.

Enter a value from 1 to 16.

The default is 4.

Table 18: Add Redundancy Groups Configuration Details (Continued)

Field Function Action node0 priority Specifies the priority value of node0 for a redundancy group.

Enter the node priority number as 0.

node1 priority Specifies the priority value of node1 for a redundancy group.

Select the node priority number as 1.

Interface Monitor

Interface

Weight

Add

Specifies the number of redundant Ethernet interfaces to be created for the cluster.

Select an interface from the list.

Enter a value from 1 to 125.

Specifies the weight for the interface to be monitored.

Adds interfaces to be monitored by the redundancy group along with their respective weights.

Click Add.

Delete Deletes interfaces to be monitored by the redundancy group along with their respective weights.

Select the interface from the configured list and click

Delete.

IP Monitoring

Weight

Threshold

Retry Count

Specifies the global weight for IP monitoring.

Specifies the global threshold for IP monitoring.

Specifies the number of retries needed to declare reachability failure.

Enter a value from 0 to 255.

Enter a value from 5 to 15.

Table 18: Add Redundancy Groups Configuration Details (Continued)

Field Function Action

Retry Interval Specifies the time interval in seconds between retries.

Enter a value from 1 to 30.

IPV4 Addresses to Be Monitored

IP Specifies the IPv4 addresses to be monitored for reachability.

Enter the IPv4 addresses.

Weight Specifies the weight for the redundancy group interface to be monitored.

Enter the weight.

Interface

Secondary IP address

Add

Delete

Specifies the logical interface through which to monitor this IP address.

Enter the logical interface address.

Specifies the source address for monitoring packets on a secondary link.

Enter the secondary IP address.

Click Add.

Adds the IPv4 address to be monitored.

Deletes the IPv4 address to be monitored.

Select the IPv4 address from the list and click Delete.

SEE ALSO

Chassis Cluster Feature Guide for Security Devices

vSRX Cluster Staging and Provisioning for KVM

IN THIS SECTION

Chassis Cluster Provisioning on vSRX | 98

Creating the Chassis Cluster Virtual Networks with virt-manager | 100

Creating the Chassis Cluster Virtual Networks with virsh | 100

Configuring the Control and Fabric Interfaces with virt-manager | 102

Configuring the Control and Fabric Interfaces with virsh | 102

Configuring Chassis Cluster Fabric Ports | 102

You can provision the vSRX VMs and virtual networks to configure chassis clustering.

The staging and provisioning of the vSRX chassis cluster includes the following tasks:

Chassis Cluster Provisioning on vSRX

Chassis cluster requires the following direct connections between the two vSRX instances:

• Control link, or virtual network, which acts in active/passive mode for the control plane traffic between the two vSRX instances

• Fabric link, or virtual network, which acts in active/active mode for the data traffic between the two vSRX instances

NOTE: You can optionally create two fabric links for more redundancy.

The vSRX cluster uses the following interfaces:

• Out-of-band Management interface (fxp0)

• Cluster control interface (em0)

• Cluster fabric interface (fab0 on node0, fab1 on node1)

NOTE: The control interface must be the second vNIC. You can optionally configure a second fabric link for increased redundancy.

Figure 13: vSRX Chassis Cluster vSRX supports chassis cluster using the virtio driver and interfaces, with the following considerations:

• When you enable chassis cluster, you must also enable jumbo frames (MTU size = 9000) to support the fabric link on the virtio network interface.

• If you configure a chassis cluster across two physical hosts, disable igmp-snooping on each host physical interface that the vSRX control link uses to ensure that the control link heartbeat is received by both nodes in the chassis cluster.

hostOS# echo 0 > /sys/devices/virtual/net/ <bridge-name>/bridge/multicast_snooping

• After you enable chassis cluster, the vSRX instance maps the second vNIC to the control link, em0.

You can map any other vNICs to the fabric link.

NOTE: For virtio interfaces, link status update is not supported. The link status of virtio interfaces is always reported as Up. For this reason, a vSRX instance using virtio and chassis cluster cannot receive link up and link down messages from virtio interfaces.

The virtual network MAC aging time determines the amount of time that an entry remains in the

MAC table. We recommend that you reduce the MAC aging time on the virtual networks to minimize the downtime during failover.

For example, you can use the brctl setageing bridge 1 command to set aging to 1 second for the

Linux bridge.

You configure the virtual networks for the control and fabric links, then create and connect the control interface to the control virtual network and the fabric interface to the fabric virtual network.

Creating the Chassis Cluster Virtual Networks with virt-manager

In KVM, you create two virtual networks (control and fabric) to which you can connect each vSRX instance for chassis clustering.

To create a virtual network with virt-manager :

1. Launch virt-manager and select Edit>Connection Details. The Connection details dialog box appears.

2. Select Virtual Networks. The list of existing virtual networks appears.

3. Click + to create a new virtual network for the control link. The Create a new virtual network wizard appears.

4. Set the subnet for this virtual network and click Forward.

5. Select Enable DHCP and click Forward.

6. Select Isolated virtual network and click forward.

7. Verify the settings and click Finish to create the virtual network.

Creating the Chassis Cluster Virtual Networks with virsh

In KVM, you create two virtual networks (control and fabric) to which you can connect each vSRX for chassis clustering.

To create the control network with virsh :

1. Use the virsh net-define command on the host OS to create an XML file that defines the new virtual

network. Include the XML fields described in Table 19 on page 100 to define this network.

NOTE: See the official virsh documentation for a complete description of available options.

Table 19: virsh net-define XML Fields

Field Description

<network>...</network> Use this XML wrapper element to define a virtual network.

Specify the virtual network name.

Specify the name of the host bridge used for this virtual network.

100

Table 19: virsh net-define XML Fields (Continued)

Field Description

<forward mode=” forward-option” /> Specify routed or nat. Do not use the <forward> element for isolated mode.

<ip address=” ip-address” netmask=” net-mask”

Specify the IP address and subnet mask used by this virtual network, along with the DHCP address range.

The following example shows a sample XML file that defines a control virtual network.

<name>control</name>

<dhcp>

</dhcp>

</ip>

</network>

2. Use the virsh net-start command to start the new virtual network.

hostOS# virsh net-start control

3. Use the virsh net-autostart command to automatically start the new virtual network when the host

OS boots.

hostOS# virsh net-autostart control

4. Optionally, use the virsh net-list –all command in the host OS to verify the new virtual network.

hostOS# # virsh net-list --all

Name State Autostart Persistent

----------------------------------------------------------

control active yes yes

default active yes yes

5. Repeat this procedure to create the fabric virtual network.

101

Configuring the Control and Fabric Interfaces with virt-manager

To configure the control and fabric interfaces for chassis clustering with virt-manager :

1. In virt-manager , double-click the vSRX VM and select View>Details. The vSRX Virtual Machine details dialog box appears.

2. Select the second vNIC and select the control virtual network from the Source device list.

3. Select virtio from the Device model list and click Apply.

4. Select a subsequent vNIC, and select the fabric virtual network from the Source device list.

5. Select virtio from the Device model list and click Apply.

6. For the fabric interface, use the ifconfig command on the host OS to set the MTU to 9000.

hostOS# ifconfig vnet1 mtu 9000

Configuring the Control and Fabric Interfaces with virsh

To configure control and fabric interfaces to a vSRX VM with virsh :

1. Type virsh attach-interface --domain vsrx-vm-name --type network --source control-vnetwork --

target control --model virtio on the host OS.

This command creates a virtual interface called control and connects it to the control virtual network.

2. Type virsh attach-interface --domain vsrx-vm-name --type network --source fabric-vnetwork --

target fabric --model virtio on the host OS.

This command creates a virtual interface called fabric and connects it to the fabric virtual network.

3. For the fabric interface, use the ifconfig command on the host OS to set the MTU to 9000.

hostOS# ifconfig vnet1 mtu 9000

Configuring Chassis Cluster Fabric Ports

After the chassis cluster is formed, you must configure the interfaces that make up the fabric (data) ports.

Ensure that you have configured the following:

• Set the chassis cluster IDs on both vSRX instances and rebooted the vSRX instances.

• Configured the control and fabric links.

1. On the vSRX node 0 console in configuration mode, configure the fabric (data) ports of the cluster that are used to pass real-time objects (RTOs). The configuration will be synchronized directly through the control port to vSRX node 1.

102

NOTE: A fabric port can be any unused revenue interface.

user@vsrx0# set interfaces fab0 fabric-options member-interfaces ge-0/0/0 user@vsrx0# set interfaces fab1 fabric-options member-interfaces ge-7/0/0 user@vsrx0# set chassis cluster reth-count 2 user@vsrx0# set chassis cluster redundancy-group 0 node 0 priority 100 user@vsrx0# set chassis cluster redundancy-group 0 node 1 priority 10 user@vsrx0# set chassis cluster redundancy-group 1 node 0 priority 100 user@vsrx0# set chassis cluster redundancy-group 1 node 1 priority 10 user@vsrx0# commit

2. Reboot vSRX node 0.

RELATED DOCUMENTATION virt tools

Verify the Chassis Cluster Configuration

IN THIS SECTION

Purpose | 103

Action | 104

Purpose

Verify that the chassis cluster is operational after you set up the vSRX instances for clustering and set the cluster ID and the node ID.

103

Action

After reboot, the two nodes are reachable on interface fxp0 with SSH. If the configuration is operational, the show chassis cluster status command displays output similar to that shown in the following sample output.

vsrx> show chassis cluster status

Cluster ID: 1

Node Priority Status Preempt Manual Monitor-failures

Redundancy group: 0 , Failover count: 1

node0 100 secondary no no None

node1 10 primary no no None

Redundancy group: 1 , Failover count: 2

node0 100 secondary no no None

node1 10 primary no no None

A cluster is healthy when both the primary and the secondary nodes are present and when both have a priority greater than 0.

104

PART

vSRX Deployment for VMware

Overview | 106

Install vSRX in VMware | 124

vSRX VM Management with VMware | 138

Configure vSRX Chassis Clusters in VMware | 144

CHAPTER 5

Overview

IN THIS CHAPTER

Understand vSRX with VMware | 106

Requirements for vSRX on VMware | 114

Understand vSRX with VMware

IN THIS SECTION

vSRX Overview | 106

vSRX Benefits and Use Cases | 109

vSRX on VMWare ESXi deployment | 110

vSRX Scale Up Performance | 111

vSRX Session Capacity Increase | 112

This section presents an overview of vSRX on VMware

vSRX Overview

vSRX is a virtual security appliance that provides security and networking services at the perimeter or edge in virtualized private or public cloud environments. vSRX runs as a virtual machine (VM) on a standard x86 server. vSRX is built on the Junos operating system (Junos OS) and delivers networking and security features similar to those available on the software releases for the SRX Series Services

Gateways.

The vSRX provides you with a complete Next-Generation Firewall (NGFW) solution, including core firewall, VPN, NAT, advanced Layer 4 through Layer 7 security services such as Application Security, intrusion detection and prevention (IPS), and UTM features including Enhanced Web Filtering and Anti-

106

Virus. Combined with Sky ATP, the vSRX offers a cloud-based advanced anti-malware service with dynamic analysis to protect against sophisticated malware, and provides built-in machine learning to improve verdict efficacy and decrease time to remediation.

Figure 14 on page 107 shows the high-level architecture.

Figure 14: vSRX Architecture

107 vSRX includes the Junos control plane (JCP) and the packet forwarding engine (PFE) components that make up the data plane. vSRX uses one virtual CPU (vCPU) for the JCP and at least one vCPU for the

PFE. Starting in Junos OS Release 15.1X49-D70 and Junos OS Release 17.3R1, multi-core vSRX supports scaling vCPUs and GB virtual RAM (vRAM). Additional vCPUs are applied to the data plane to increase performance.

Junos OS Release 18.4R1 supports a new software architecture vSRX 3.0 that removes dual OS and nested virtualization requirement of existing vSRX architecture.

In vSRX 3.0 architecture, FreeBSD 11.x is used as the guest OS and the Routing Engine and Packet

Forwarding Engine runs on FreeBSD 11.x as single virtual machine for improved performance and scalability. vSRX 3.0 uses DPDK to process the data packets in the data plane. A direct Junos upgrade from vSRX to vSRX 3.0 software is not supported.

vSRX 3.0 has the following enhancements compared to vSRX:

• Removed the restriction of requiring nested VM support in hypervisors.

• Removed the restriction of requiring ports connected to control plane to have Promiscuous mode enabled.

• Improved boot time and enhanced responsiveness of the control plane during management operations.

• Improved live migration.

108

Figure 15 on page 109 shows the high-level software architecture for vSRX 3.0

Figure 15: vSRX 3.0 Architecture

109

vSRX Benefits and Use Cases

vSRX on standard x86 servers enables you to quickly introduce new services, deliver customized services to customers, and scale security services based on dynamic needs. vSRX is ideal for public, private, and hybrid cloud environments.

Some of the key benefits of vSRX in a virtualized private or public cloud multitenant environment include:

• Stateful firewall protection at the tenant edge

• Faster deployment of virtual firewalls into new sites

• Ability to run on top of various hypervisors and public cloud infrastructures

• Full routing, VPN, core security, and networking capabilities

• Application security features (including IPS and App-Secure)

• Content security features (including Anti Virus, Web Filtering, Anti Spam, and Content Filtering)

• Centralized management with Junos Space Security Director and local management with J-Web

Interface

• Juniper Networks Sky Advanced Threat Prevention (Sky ATP) integration

vSRX on VMWare ESXi deployment

VMware vSphere is a virtualization environment for systems supporting the x86 architecture. VMware

ESXi® is the hypervisor used to create and run virtual machines (VMs) and virtual appliances on a host machine. The VMware vCenter Server® is a service that manages the resources of multiple ESXi hosts.

The VMware vSphere Web Client is used to deploy the vSRX VM.

Figure 16 on page 110 shows an example of how vSRX can be deployed to provide security for

applications running on one or more virtual machines. The vSRX virtual switch has a connection to a physical adapter (the uplink) so that all application traffic flows through the vSRX VM to the external network.

Figure 16: Example of vSRX Deployment

110

vSRX Scale Up Performance

Table 20 on page 111

shows the vSRX scale up performance based on the number of vCPUs and vRAM applied to a vSRX VM. The table outlines the Junos OS release in which a particular software specification for deploying vSRX on VMware was introduced. You will need to download a specific Junos

OS release to take advantage of certain scale up performance features.

Table 20: vSRX Scale Up Performance vCPUs vRAM NICs Junos OS Release

Introduced

2 vCPUs 4 GB • SR-IOV (Intel 82599, X520/X540)

• VMNET3

Junos OS Release

15.1X49-D15 and

Junos OS Release

17.3R1

5 vCPUs 8 GB • SR-IOV (Intel 82599, X520/X540)

• VMNET3

Junos OS Release

15.1X49-D70 and

Junos OS Release

17.3R1

9 vCPUs 16 GB • SR-IOV (Mellanox ConnectX-3/ConnectX-3 Pro and

Mellanox ConnectX-4 EN/ConnectX-4 Lx EN)

Junos OS Release

18.4R1

NOTE: SR-IOV (Mellanox ConnectX-3/ConnectX-3 Pro and Mellanox ConnectX-4 EN/ConnectX-4 Lx EN) is required if you intend to scale the performance and capacity of a vSRX to 9 vCPUs and 16 GB vRAM.

17 vCPUs 32 GB • SR-IOV (Mellanox ConnectX-3/ConnectX-3 Pro and

Mellanox ConnectX-4 EN/ConnectX-4 Lx EN)

Junos OS Release

18.4R1

NOTE: SR-IOV (Mellanox ConnectX-3/ConnectX-3 Pro and Mellanox ConnectX-4 EN/ConnectX-4 Lx EN) is required if you intend to scale the performance and capacity of a vSRX to 17 vCPUs and 32 GB vRAM.

111

You can scale up a vSRX instance to a higher number of vCPUs and amount of vRAM, but you cannot scale down an existing vSRX instance to a smaller setting.

NOTE: The number of RSS queues typically matches with the number of data plane vCPUs of a vSRX instance. For example, a vSRX with 4 data plane vCPUs should have 4 RSS queues.

vSRX Session Capacity Increase

vSRX solution is optimized to increase the session numbers by increasing the memory.

With the ability to increase the session numbers by increasing the memory, you can enable vSRX to:

• Provide highly scalable, flexible and high-performance security at strategic locations in the mobile network.

• Deliver the performance that service providers require to scale and protect their networks.

Run the show security flow session summary | grep maximum command to view the maximum number of sessions.

Starting in Junos OS Release 18.4R1, the number of flow sessions supported on a vSRX instance is increased based on the vRAM size used.

Starting in Junos OS Release 19.2R1, the number of flow sessions supported on a vSRX 3.0 instance is increased based on the vRAM size used.

Table 21 on page 112

lists the flow session capacity.

Table 21: vSRX and vSRX 3.0 Flow Session Capacity Details vCPUs Memory Flow Session Capacity

2 4 GB 0.5 M

2/5

6 GB

8 GB

1 M

2 M

112

2/5/9/17

2/5/9

Table 21: vSRX and vSRX 3.0 Flow Session Capacity Details (Continued) vCPUs Memory Flow Session Capacity

2/5 10 GB 2 M

2/5

12 GB

14 GB

2.5 M

3 M

16 GB

20 GB

24 GB

28 GB

4 M

6 M

8 M

10 M

32 GB

40 GB

48 GB

56 GB

64 GB

12 M

16 M

20 M

24 M

28 M

Release History Table

Release Description

19.2R1

Starting in Junos OS Release 19.2R1, the number of flow sessions supported on a vSRX 3.0

instance is increased based on the vRAM size used.

113

18.4R1

Starting in Junos OS Release 18.4R1, the number of flow sessions supported on a vSRX instance is increased based on the vRAM size used.

15.1X49-D70 Starting in Junos OS Release 15.1X49-D70 and Junos OS Release 17.3R1, multi-core vSRX supports scaling vCPUs and GB virtual RAM (vRAM). Additional vCPUs are applied to the data plane to increase performance.

RELATED DOCUMENTATION

VMware vSphere

RSS: Receive Side Scaling

Requirements for vSRX on VMware

IN THIS SECTION

Software Specifications | 114

Hardware Specifications | 118

Best Practices for Improving vSRX Performance | 119

Interface Mapping for vSRX on VMware | 120

vSRX Default Settings on VMware | 122

Software Specifications

Table 22 on page 115

lists the system software requirement specifications when deploying vSRX on

VMware. The table outlines the Junos OS release in which a particular software specification for deploying vSRX on VMware was introduced. You must need to download a specific Junos OS release to take advantage of certain features.

114

Table 22: Specifications for vSRX and vSRX 3.0 on VMware

Component Specification Junos OS Release Introduced

Hypervisor support

VMware ESXi 5.1, 5.5, or 6.0

Junos OS Release 15.1X49-D15 and

Junos OS Release 17.3R1

Memory

VMware ESXi 5.5, 6.0, 6.5

Junos OS Release 17.4R1, 18.1R1,

18.2R1, 18.3R1

Junos OS Release 18.4R1

VMware ESXi 6.5

VMware ESXi 6.5 and 6.7 (For vSRX 3.0

only)

Junos OS Release 19.3R1

VMware ESXi 7.0 (For vSRX 3.0 only)

4 GB

8GB

16 GB

32 GB

Disk space 16 GB (IDE or SCSI drives)

Junos OS Release 20.1R2

Junos OS Release 15.1X49-D15 and

Junos OS Release 17.3R1

Junos OS Release 15.1X49-D70 and

Junos OS Release 17.3R1

Junos OS Release 18.4R1

vCPUs 2 vCPUs

5 vCPUs

Junos OS Release 15.1X49-D15 and

Junos OS Release 17.3R1

Junos OS Release 15.1X49-D15 and

Junos OS Release 17.3R1

Junos OS Release 15.1X49-D70 and

Junos OS Release 17.3R1

115

Table 22: Specifications for vSRX and vSRX 3.0 on VMware (Continued)

Component Specification Junos OS Release Introduced

9 vCPUs Junos OS Release 18.4R1

vNICs

17 vCPUs Junos OS Release 18.4R1

Up to 10 vNICs

• SR-IOV

NOTE: We recommend the Intel

X520/X540 physical NICs for SR-IOV support on vSRX. For SR-IOV limitations, see the Known Behavior section of the vSRX Release Notes.

• VMNET3

NOTE: The Intel DPDK drivers use polling mode for all vNICs, so the NAPI and interrupt mode features in

VMXNET3 are not currently supported.

NOTE: Starting in Junos OS Release

15.1X49-D20, in vSRX deployments using VMware ESX, changing the default speed (1000 Mbps) or the default link mode (full duplex) is not supported on VMXNET3 vNICs.

Junos OS Release 15.1X49-D15 and

Junos OS Release 17.3R1

116

Table 22: Specifications for vSRX and vSRX 3.0 on VMware (Continued)

Component Specification Junos OS Release Introduced

Starting in Junos OS Release 18.4R1:

• SR-IOV (Mellanox ConnectX-3/

ConnectX-3 Pro and Mellanox

ConnectX-4 EN/ConnectX-4 Lx EN) is required if you intend to scale the performance and capacity of a vSRX

VM to 9 or 17 vCPUs and 16 or 32 GB vRAM.

NOTE: Mellanox NIC (any ConnectX) cards are not support on VMWare.

Junos OS Release 18.4R1

• The DPDK version has been upgraded from 17.02 to 17.11.2 to support the

Mellanox Family Adapters.

Starting in Junos OS Release 19.4R1,

DPDK version 18.11 is supported on vSRX. With this feature the Mellanox

Connect Network Interface Card (NIC) on vSRX now supports OSPF Multicast and

VLANs.

Junos OS Release 19.4R1

Table 23 on page 117

lists the specifications on the vSRX 3.0 virtual machine (VM).

Table 23: Specifications for vSRX 3.0 on VMware vCPU vRAM DPDK Hugepage vNICs vDisk Junos OS Release

Introduced

2 4G 17.05

2G 2-10 20G Junos OS Release

18.2R1

117

Table 23: Specifications for vSRX 3.0 on VMware (Continued) vCPU vRAM DPDK Hugepage vNICs

5 8G 17.05

6G 2–10 vSRX on VMWare supports

VMXNET3 through DPDK and

PMD, and SR-IOV (82599).

A maximum number of eight interfaces are supported.

DPDK uses HugePage for improved performance.

vDisk Junos OS Release

Introduced

20G Junos OS Release

18.4R1

Hardware Specifications

Table 24 on page 118

lists the hardware specifications for the host machine that runs the vSRX VM.

Table 24: Hardware Specifications for the Host Machine

Component Specification

Host processor type Intel x86_64 multicore CPU

NOTE: DPDK requires Intel Virtualization VT-x/VT-d support in the CPU. See

About Intel Virtualization Technology.

Virtual network adapter

VMXNet3 device or VMware Virtual NIC

NOTE: Virtual Machine Communication Interface (VMCI) communication channel is internal to the ESXi hypervisor and the vSRX VM.

118

Table 24: Hardware Specifications for the Host Machine (Continued)

Component Specification

Physical NIC support on vSRX 3.0

Support SR-IOV on X710/XL710 vSRX3.0 SR-IOV HA on I40E ( X710,X740,X722 and so on) are not supported on VMware.

Mellanox NIC (any ConnectX) cards are not support on VMWare.

Chassis Cluster is not supported with SRIOV interface adapters.

Best Practices for Improving vSRX Performance

Review the following practices to improve vSRX performance.

NUMA Nodes

The x86 server architecture consists of multiple sockets and multiple cores within a socket. Each socket also has memory that is used to store packets during I/O transfers from the NIC to the host. To efficiently read packets from memory, guest applications and associated peripherals (such as the NIC) should reside within a single socket. A penalty is associated with spanning CPU sockets for memory accesses, which might result in nondeterministic performance. For vSRX, we recommend that all vCPUs for the vSRX VM are in the same physical non-uniform memory access (NUMA) node for optimal performance.

We recommend that you bind the vSRX instance with a specific NUMA node by setting

NUMA node affinity. NUMA node affinity constrains the vSRX VM resource scheduling to only the specified NUMA node.

PCI NIC-to-VM Mapping

119

3 some servers where this information is not available, refer to the hardware documentation for the slotto-NUMA node topology.

Interface Mapping for vSRX on VMware

mappings in vSRX are shown in Table 25 on page 120 and

Table 26 on page 121

Note the following:

• In standalone mode:

• fxp0 is the out-of-band management interface.

• ge-0/0/0 is the first traffic (revenue) interface.

• In cluster mode:

• fxp0 is the out-of-band management interface.

• em0 is the cluster control link for both nodes.

• Any of the traffic interfaces can be specified as the fabric links, such as ge-0/0/0 for fab0 on node

0 and ge-7/0/0 for fab1 on node 1.

Table 25 on page 120

shows the interface names and mappings for a standalone vSRX VM.

Table 25: Interface Names for a Standalone vSRX VM

Network

Adapter

Interface Name in Junos OS

1 fxp0 ge-0/0/0 ge-0/0/1 ge-0/0/2 ge-0/0/3

120

Table 25: Interface Names for a Standalone vSRX VM (Continued)

Network

Adapter

Interface Name in Junos OS

6 ge-0/0/4 ge-0/0/5 ge-0/0/6

Table 26 on page 121

shows the interface names and mappings for a pair of vSRX VMs in a cluster (node

0 and node 1).

Table 26: Interface Names for a vSRX Cluster Pair

Network

Adapter

Interface Name in Junos OS

1 fxp0 (node 0 and 1) em0 (node 0 and 1) ge-0/0/0 (node 0) ge-7/0/0 (node 1)

6 ge-0/0/1 (node 0) ge-7/0/1 (node 1) ge-0/0/2 (node 0) ge-7/0/2 (node 1) ge-0/0/3 (node 0) ge-7/0/3 (node 1)

121

Table 26: Interface Names for a vSRX Cluster Pair (Continued)

Network

Adapter

Interface Name in Junos OS

7 ge-0/0/4 (node 0) ge-7/0/4 (node 1)

8 ge-0/0/5 (node 0) ge-7/0/5 (node 1)

vSRX Default Settings on VMware

vSRX requires the following basic configuration settings:

• Interfaces must be assigned IP addresses.

• Interfaces must be bound to zones.

• Policies must be configured between zones to permit or deny traffic.

NOTE: For the management interface, fxp0, VMware uses the VMXNET 3 vNIC and requires promiscuous mode on the vSwitch.

Table 27 on page 122

lists the factory default settings for the vSRX security policies.

Table 27: Factory Default Settings for Security Policies

Source Zone Destination Zone Policy Action trust untrust permit trust untrust trust trust permit deny

122

RELATED DOCUMENTATION

About Intel Virtualization Technology

DPDK Release Notes

123

CHAPTER 6

Install vSRX in VMware

IN THIS CHAPTER

Install vSRX with VMware vSphere Web Client | 124

Load an Initial Configuration on a vSRX with VMware | 128

Validate the vSRX .ova File for VMware | 134

Install vSRX with VMware vSphere Web Client

The following procedure describes how to install vSRX and connect vSRX interfaces to the virtual switches for the appropriate applications. Only the vSRX virtual switch has a connection to a physical adapter (the uplink) so that all application traffic flows through the vSRX VM to the external network.

To install vSRX with the VMware vSphere Web Client:

NOTE: To upgrade an existing vSRX instance, see Migration, Upgrade, and Downgrade in the vSRX Release Notes.

Download the vSRX software package for VMware from the Juniper Networks website .

NOTE: Do not change the filename of the downloaded software image or the installation will fail.

Validate the vSRX .ova file if required. For more information, see "Validate the vSRX .ova File for

VMware" on page 134

Enter the vCenter server hostname or address in your browser (https://< ipaddress>:9443) to access the vSphere Web Client, and log in to the vCenter server with your credentials.

Select a host or other valid parent for a virtual machine and click Actions > All vCenter Actions >

Deploy OVF Template.

124

NOTE: The Client Integration Plug-in must be installed before you can deploy OVF templates (see your VMware documentation).

Click Browse to locate the vSRX software package, and then click Next.

Click Next in the OVF Template Details window.

Click Accept in the End User License Agreement window, and then click Next.

Change the default vSRX VM name in the Name box and click Next. It is advisable to keep this name the same as the hostname you intend to give to the VM.

In the Datastore window, do not change the default settings for:

• Datastore

• Available Space

Table 28 on page 125 lists the disk formats available to store the virtual disk. You can choose one of

the three options listed.

NOTE: For detailed information on the disk formats, see Virtual Disk Provisioning .

Table 28: Disk Formats for Virtual Disk Storage

Disk Format Description

Thick Provision Lazy

Zeroed

Allocates disk space to the virtual disk without erasing the previously stored data. The previous data is erased when the VM is used for the first time.

Thick Provision

Eager Zeroed

Thin Provision

Erases the previously stored data completely and then allocates the disk space to the virtual disk. Creation of disks in this format is time consuming.

Allocates only as much datastore space as the disk needs for its initial operations. Use this format to save storage space.

125

10. Select a datastore to store the configuration file and virtual disk files in OVF template, and then click Next.

11. Select your management network from the list, and then click Next. The management network is assigned to the first network adapter, which is reserved for the management interface (fxp0).

12. Click Finish to complete the installation.

13. Open the Edit Settings page of the vSRX VM and select a virtual switch for each network adapter.

Three network adapters are created by default. Network adapter 1 is for the management network

(fxp0). To add a fourth adapter, select Network from New device list at the bottom of the page. To

add more adapters, see "Add vSRX Interfaces" on page 138

126

In Figure 17 on page 127 , network adapter 2 uses the management network for the uplink to the

external network.

Figure 17: vSRX Edit Settings Page

127

14. Enable promiscuous mode for the management virtual switch: a. Select the host where the vSRX VM is installed, and select Manage > Networking > Virtual switches.

b. In the list of virtual switches, select vSwitch0 to view the topology diagram for the management network connected to network adapter 1.

c. Click the Edit icon at the top of the list, select Security, and select Accept next to Promiscuous mode. Click OK.

NOTE: vSwitch1 corresponds to network adapter 2, vSwitch2 corresponds to network adapter 3, and so on.

15. Enable hardware-assisted virtualization to optimize performance of the vSRX Routing Engine that runs in a nested VM: a. Power off the vSRX VM.

b. Right-click on the vSRX VM and select Edit Settings.

c. On the Virtual Hardware tab, expand CPU, select Expose hardware-assisted virtualization to guest OS, and click OK.

On the Manage tab, select Settings > VM Hardware and expand CPU to verify that the Hardware virtualization option is shown as Enabled.

NOTE: The default vSRX VM login ID is root with no password. By default, vSRX is assigned a

DHCP-based IP address if a DHCP server is available on the network.

RELATED DOCUMENTATION

Using Virtual NUMA

Virtual Machine vCPU and vNUMA Rightsizing

Load an Initial Configuration on a vSRX with VMware

IN THIS SECTION

Create a vSRX Bootstrap ISO Image | 132

128

Upload an ISO Image to a VMWare Datastore | 133

Provision vSRX with an ISO Bootstrap Image on VMWare | 133

Starting in Junos OS Release 15.1X49-D40 and Junos OS Release 17.3R1, you can use a mounted ISO image to pass the initial startup Junos OS configuration to a vSRX VM. This ISO image contains a file in the root directory called juniper.conf. The configuration file uses curly brackets ({) and indentation to display the hierarchical structure of the configuration. Terminating or leaf statements in the configuration hierarchy are displayed with a trailing semicolon (;) to define configuration details, such as root password, management IP address, default gateway, and other configuration statements.

NOTE: The juniper.conf file must be in the format same as displayed using show configuration command and it cannot be in set command format.

The process to bootstrap a vSRX VM with an ISO configuration image is as follows:

1. Create the juniper.conf configuration file with your Junos OS configuration.

An example of a juniper.conf file follows.

system {

host-name iso-mount-test;

root-authentication {

encrypted-password "$5$wCXP/Ma4$aqMJBhy82.wI643ijb73yHKKl9TXApPycGKKn.PjpA8"; ##

SECRET-DATA

}

user regress {

uid 2001;

class super-user;

authentication {

encrypted-password "$6$FGJM2YEb

$KTGIehvNt9Mf.u3ESWGB1aSQeXrSeg6zoCWZw0D6M6vnmWb8DAWsprNXyKZeW6M3kErFFTFtAuNpGjDjfwX4t."; ##

SECRET-DATA

}

services {

ssh {

129

root-login allow;

}

telnet;

web-management {

http {

interface fxp0.0;

}

syslog {

user * {

any emergency;

}

file messages {

any any;

authorization info;

}

file interactive-commands {

interactive-commands any;

}

license {

autoupdate {

url https://ae1.juniper.net/junos/key_retrieval;

}

} security {

forwarding-options {

family {

inet6 {

mode flow-based;

}

policies {

default-policy {

permit-all;

}

zones {

security-zone AAA {

interfaces {

130

all;

}

} interfaces {

ge-0/0/0 {

vlan-tagging;

unit 0 {

vlan-id 77;

family inet {

address 10.1.1.0/24 {

arp 10.1.1.10 mac 00:10:12:34:12:34;

}

ge-0/0/1 {

vlan-tagging;

unit 0 {

vlan-id 1177;

family inet {

address 10.1.1.1/24 {

arp 10.1.1.10 mac 00:10:22:34:22:34;

}

fxp0 {

unit 0 {

family inet {

address 192.168.70.9/19;

}

} routing-options {

static {

route 0.0.0.0/0 next-hop 192.168.64.1;

}

131

}

2. Create an ISO image that includes the juniper.conf file.

3. Mount the ISO image to the vSRX VM.

4. Boot or reboot the vSRX VM. vSRX will boot using the juniper.conf file included in the mounted ISO image.

5. Unmount the ISO image from the vSRX VM. To unmount the ISO image see Dismount ISO Image from VM .

NOTE: If you do not unmount the ISO image after the initial boot or reboot, all subsequent configuration changes to the vSRX are overwritten by the ISO image on the next reboot.

Create a vSRX Bootstrap ISO Image

This task uses a Linux system to create the ISO image.

To create a vSRX bootstrap ISO image:

1. Create a configuration file in plaintext with the Junos OS command syntax and save in a file called

juniper.conf.

2. Create a new directory.

hostOS$ mkdir iso_dir

3. Copy juniper.conf to the new ISO directory.

hostOS$ cp juniper.conf iso_dir

132

NOTE: The juniper.conf file must contain the full vSRX configuration. The ISO bootstrap process overwrites any existing vSRX configuration.

4. Use the Linux mkisofs command to create the ISO image.

hostOS$ mkisofs -l -o test.iso iso_dir

I: -input-charset not specified, using utf-8 (detected in locale settings)

Total translation table size: 0

Total rockridge attributes bytes: 0

Total directory bytes: 0

Path table size(bytes): 10

Max brk space used 0

175 extents written (0 MB)

NOTE: The -l option allows for a long filename.

SEE ALSO

Linux mkisofs command

Upload an ISO Image to a VMWare Datastore

To upload an ISO image to a datastore:

1. On the VMware vSphere Web Client, select the datastore you want to upload the file to.

2. Select the folder where you want to store the file and click Upload a File from the task bar.

3. Browse to the file on your local computer and click Upload.

Optionally, refresh the datastore to see the new file.

Provision vSRX with an ISO Bootstrap Image on VMWare

To provision a vSRX VM with an ISO bootstrap image:

From VMware vSphere client, select the host server where the vSRX VM resides.

Right-click the vSRX VM and select Edit Settings. The Edit Setting dialogue box appears.

Select the Hardware tab and click Add. The Add Hardware dialog box opens.

Select the CD/DVD drive and click Next.

Select Use ISO image and click Next.

Click Datastore ISO File, browse to your boostrap ISO image, and click Next.

133

Click Next and Finish to save this setting.

Click OK to save this CD drive to the VM.

Right-click the vSRX VM and select Power>Power On to boot the vSRX VM.

10. After the vSRX boots, verify the configuration and then select Power> Power down to shut down the vSRX so you can remove the ISO image.

11. Select the CD/DVD drive from the Hardware tab in the VMWare vSphere client.

12. Select the CD drive for the ISO file and click Remove to remove your boostrap ISO image.

13. Click OK to save this setting.

14. Right-click the vSRX VM and select Power>Power On to boot the vSRX VM.

Release History Table

Release Description

15.1X49-

D80

Starting in Junos OS Release 15.1X49-D40 and Junos OS Release 17.3R1, you can use a mounted

ISO image to pass the initial startup Junos OS configuration to a vSRX VM. This ISO image contains a file in the root directory called juniper.conf. The configuration file uses curly brackets ({) and indentation to display the hierarchical structure of the configuration. Terminating or leaf statements in the configuration hierarchy are displayed with a trailing semicolon (;) to define configuration details, such as root password, management IP address, default gateway, and other configuration statements.

RELATED DOCUMENTATION

Linux mkisofs command

Validate the vSRX .ova File for VMware

The vSRX open virtual application (OVA) image is securely signed. You can validate the OVA image, if necessary, but you can install or upgrade vSRX without validating the OVA image.

Before you validate the OVA image, ensure that the Linux/UNIX PC or Windows PC on which you are performing the validation has the following utilities available: tar, openssl, and ovftool. See the OVF Tool

Documentation for details about the VMware Open Virtualization Format (OVF) tool, including a

Software Download link.

To validate the OVA image on a Linux machine:

1. Download the vSRX OVA image and the Juniper Networks Root certificate file

(JuniperRootRSACA.pem) from the vSRX Juniper Networks Software Download page.

134

NOTE: You need to download the Juniper Networks Root certificate file only once; you can use the same file to validate OVA images for future releases of vSRX.

2. (Optional) If you downloaded the OVA image and the certificate file to a PC running Windows, copy the two files to a temporary directory on a PC running Linux or UNIX. You can also copy the OVA image and the certificate file to a temporary directory (/var/tmp or /tmp) on a vSRX node.

Ensure that the OVA image file and the Juniper Networks Root certificate file are not modified during the validation procedure. You can do this by providing write access to these files only to the user performing the validation procedure. This is especially important if you use an accessible temporary directory, such as /tmp or /var/tmp, because such directories can be accessed by several users. Take precautions to ensure that the files are not modified by other users during the validation procedure.

3. Navigate to the directory containing the OVA image.

-bash-4.1$ ls

JuniperRootCA.pem junos-vsrx-15.1X49-DXX.4-domestic.ova

4. Unpack the OVA image by running the following command: tar xf ova-filename where ova-filename is the filename of the previously downloaded OVA image.

-bash-4.1$ mkdir tmp

-bash-4.1$ cd tmp

-bash-4.1$ tar xf ../junos-vsrx-15.1X49-DXX.4-domestic.ova

5. Verify that the unpacked OVA image contains a certificate chain file (certchain.pem) and a signature file (vsrx.cert).

-bash-4.1$ ls certchain.pem junos-vsrx-15.1X49-DXX.4-domestic.cert junos-vsrx-15.1X49-DXX.4-domesticdisk1.vmdk junos-vsrx-15.1X49-DXX.4-domestic.mf junos-vsrx-15.1X49-DXX.4-domestic.ovf

6. Validate the unpacked OVF file (extension .ovf) by running the following command: ovftool ovf- filename where ovf-filename is the filename of the unpacked OVF file contained within the previously downloaded OVA image.

135

-bash-4.1$ /usr/lib/vmware-ovftool/ovftool junos-vsrx-15.1X49-DXX.4-domestic.ovf

OVF version: 1.0

VirtualApp: false

Name: vSRX

Version: JUNOS 15.1

Vendor: Juniper Networks Inc.

Product URL:

https://www.juniper.net/us/en/products-services/software/security/vsrxseries/

Vendor URL: https://www.juniper.net/

Download Size: 227.29 MB

Deployment Sizes:

Flat disks: 2.00 GB

Sparse disks: 265.25 MB

Networks:

Name: VM Network

Description: The VM Network network

Virtual Machines:

Name: Juniper Virtual SRX

Operating System: freebsdguest

Virtual Hardware:

Families: vmx-07

Number of CPUs: 2

Cores per socket: 1

Memory: 2.00 GB

Disks:

Index: 0

Instance ID: 5

Capacity: 2.00 GB

Disk Types: IDE

NICs:

Adapter Type: E1000

Connection: VM Network

Adapter Type: E1000

Connection: VM Network

136

Deployment Options:

Id: 2GvRAM

Label: 2G vRAM

Description:

2G Memory

7. Validate the signing certificate with the Juniper Networks Root CA file by running the following command: openssl verify -CAfile JuniperRootRSACA.pem -untrusted Certificate-Chain-File Signature-file where JuniperRootRSACA.pem is the Juniper Networks Root CA file, Certificate-Chain-File is the filename of the unpacked certificate chain file (extension .pem) and Signature-file is the filename of the unpacked signature file (extension .cert).

-bash-4.1$ openssl verify -CAfile ../JuniperRootCA.pem -untrusted certchain.pem junosvsrx-15.1X49-DXX.4-domestic.cert

junos-vsrx-15.1X49-DXX.4-domestic.cert: OK

8. (Optional) If you encounter validation issues with the OVA image: a. Determine if the contents of the OVA image have been modified. If the contents have been modified, download the OVA image from the vSRX downloads page.

b. Determine whether the Juniper Networks Root CA file is corrupted or modified. If it was corrupted or modified, download the certificate file from the vSRX downloads page.

c. Retry the preceding validation steps using one or both new files.

137

CHAPTER 7

vSRX VM Management with VMware

IN THIS CHAPTER

Add vSRX Interfaces | 138

Upgrade a Multicore vSRX with VMware | 141

Add vSRX Interfaces

IN THIS SECTION

Add SR-IOV Interfaces | 139

Add VMXNET 3 Interfaces | 141

The network adapter for each interface uses SR-IOV or VMXNET 3 as the adapter type. The first network adapter is for the management interface (fxp0) and must use VMXNET 3. All additional network adapters should have the same adapter type. The three network adapters created by default use VMXNET 3.

NOTE: Starting in Junos OS Release 18.4R1:

• SR-IOV (Mellanox ConnectX-3/ConnectX-3 Pro and Mellanox ConnectX-4 EN/ConnectX-4

Lx EN) is required if you intend to scale the performance and capacity of a vSRX VM to 9 or

17 vCPUs and 16 or 32 GB vRAM.

• The DPDK version has been upgraded from 17.02 to 17.11.2 to support the Mellanox Family

Adapters .

138

Starting in Junos OS Release 19.4R1, DPDK version 18.11 is supported on vSRX. With this feature the Mellanox Connect Network Interface Card (NIC) on vSRX now supports OSPF

Multicast and VLANs.

The network adapters are mapped sequentially to the vSRX interfaces, as shown in "Requirements for vSRX on VMware" on page 114

NOTE: If you have used the interface mapping workaround required for prior Junos releases, you do not need to make any changes when you upgrade to Junos Release 15.1X49-D70 for vSRX.

The following procedures describe how to add more network adapters:

Add SR-IOV Interfaces

SR-IOV interfaces must be added as PCI devices on VMware. To add an SR-IOV interface as a PCI

Device, you must first select an available Virtual Function (VF) on the device.

Use the following procedure to locate available VFs and add PCI devices:

1. To locate one or more VFs: a. Use SSH to log in to the ESXi server and enter the following command to view the VFs for vmnic6

(or another vNIC):

# esxcli network sriovnic vf list -n vmnic6

VF ID Active PCI Address Owner World ID

----- ------ ----------- --------------

0 true 005:16.0 982641

1 true 005:16.2 982641

2 true 005:16.4 982641

3 false 005:16.6 -

4 false 005:17.0 -

5 false 005:17.2 -

6 false 005:17.4 -

Choose one or more VF IDs that are not active, such as 3 through 6. Note that a VF assigned to a

VM that is powered off is shown as inactive.

139

b. Enter the lspci command to view the VF number of the chosen VF IDs. In the following example, find the entry that ends with [vmnic6], scroll down to the next entry ending in VF_3, and note the associated VF number 05:10.6. Note that the next VF_3 entry is for vmnic7.

# lspci

0000:05:00.0 Network controller: Intel Corporation 82599EB 10-Gig ... [vmnic6]

0000:05:00.1 Network controller: Intel Corporation 82599EB 10-Gig ... [vmnic7]

0000:05:10.0 Network controller: Intel Corporation 82599 Ethernet Controller Virtual

Function [PF_0.5.0_VF_0]

0000:05:10.1 Network controller: Intel Corporation 82599 Ethernet Controller Virtual

Function [PF_0.5.1_VF_0]

0000:05:10.2 Network controller: Intel Corporation 82599 Ethernet Controller Virtual

Function [PF_0.5.0_VF_1]

0000:05:10.3 Network controller: Intel Corporation 82599 Ethernet Controller Virtual

Function [PF_0.5.1_VF_1]

0000:05:10.4 Network controller: Intel Corporation 82599 Ethernet Controller Virtual

Function [PF_0.5.0_VF_2]

0000:05:10.5 Network controller: Intel Corporation 82599 Ethernet Controller Virtual

Function [PF_0.5.1_VF_2]

0000:05:10.6 Network controller: Intel Corporation 82599 Ethernet Controller Virtual

Function [PF_0.5.0_VF_3] ----- VF ID 3 on vmnic6, with VF number 05:10.6.

0000:05:10.7 Network controller: Intel Corporation 82599 Ethernet Controller Virtual

Function [PF_0.5.1_VF_3] ----- VF ID 3 on vmnic7.

2. To add SR-IOV interfaces to the vSRX VM: a. Power off the vSRX VM and open the Edit Settings page. By default there are three network adapters using VMXNET 3.

b. Add one or more PCI devices on the Virtual Hardware page. For each device, you must select an entry with an available VF number from Step 1. For example:

05:10.6 | Intel Corporation 82599 Ethernet Controller Virtual Function c. Click OK and open the Edit Settings page to verify that the new network adaptors are shown on the Virtual Hardware page (one VMXNET 3 network adapter and up to nine SR-IOV interfaces as

PCI devices).

To view the SR-IOV interface MAC addresses, select the VM Options tab, click Advanced in the left frame, and then click Edit Configuration. In the parameters pciPassthruN.generatedMACAddress

N indicates the PCI device number (0 through 9).

140

d. Power on the vSRX VM and log in to the VM to verify that VMXNET 3 network adapter 1 is mapped to fxp0, PCI device 0 is mapped to ge-0/0/0, PCI device 1 is mapped to ge-0/0/1, and so on.

NOTE: A vSRX VM with SR-IOV interfaces cannot be cloned. You must deploy a new vSRX VM and add the SR-IOV interfaces as described here.

Add VMXNET 3 Interfaces

Use the following procedure to add VMXNET 3 interfaces:

1. Power off the vSRX VM and open the Edit Settings page on vSphere Web Client.

2. Add network adapters on the Virtual Hardware page. For each network adapter, select Network from

New device list at the bottom of the page, expand New Network, and select VMXNET 3 as the adapter type.

3. Click OK and open the Edit Settings page to verify that the new network adaptors are shown on the

Virtual Hardware page.

4. Power on the vSRX VM and log in to the VM to verify that network adapter 1 is mapped to fxp0, network adapter 2 is mapped to ge-0/0/0, and so on. Use the show interfaces terse CLI command to verify that the fxp0 and ge-0/0/n interfaces are up.

Upgrade a Multicore vSRX with VMware

IN THIS SECTION

Power Down vSRX VM with VMware vSphere Web Client | 142

Upgrade a Multicore vSRX with VMware vSphere Web Client | 142

Optimize Performance of vSRX | 142

Starting in Junos OS Release 15.1X49-70 and Junos OS Release 17.3R1, you can scale the performance and capacity of a vSRX instance by increasing the number of vCPUs and the amount of vRAM allocated to the vSRX. See

"Requirements for vSRX on VMware" on page 114 for the software requirement

specifications of a vSRX VM.

141

NOTE: You cannot scale down the number of vCPUs or decrease the amount of vRAM for an existing vSRX VM.

Power Down vSRX VM with VMware vSphere Web Client

In situations where you want to modify the vSRX VM XML file, you need to completely shut down vSRX and the associated VM.

To gracefully shutdown the vSRX instance with VMware vSphere Web Client:

1. Enter the vCenter server hostname or address in your browser (https://<ipaddress>:9443) to access the vSphere Web Client, and log in to the vCenter server with your credentials.

2. Check the vSRX VM you want to power off.

3. Select Open Console to open a console window to the vSRX VM.

4. From the vSRX console, reboot the vSRX instance.

vsrx# request system power-off.

Upgrade a Multicore vSRX with VMware vSphere Web Client

You must power down the vSRX VM before you can update the vCPU and vRAM values for the VM.

To scale up the vSRX VM to a higher number of vCPUs or to an increased amount of vRAM:

1. On VMware vSphere Web Client, Select Edit Settings to open the powered down vSRX VM to open the virtual machine details window.

2. Select Memory and set the vRAM to the desired size.

3. Select Processor and set the number of vCPUs. Click OK.

4. Click Power On. The VM manager launches the vSRX VM with the new vCPU and vRAM settings.

NOTE: vSRX scales down to the closest supported value if the vCPU or vRAM settings do not match what is currently available.

Optimize Performance of vSRX

To optimize performance of vSRX on VMware:

1. For memory, select the NUMA node that line cards connect to.

2. For the CPU: a. Disable hyper-threading.

142

b. Select CPUs on the selected NUMA node.

c. Select n sockets and each socket has one core.

d. Reserve the CPU resource.

3. For the TX thread:

• Configure a separate ESXi transmit thread per vNIC.

• Place transmit threads on the same NUMA node.

4. For vNICs, use either 2 vNICs or 4 vNICs if you want to scale the performance of the vSRX VM.

Release History Table

Release Description

15.1X49-D70 Starting in Junos OS Release 15.1X49-70 and Junos OS Release 17.3R1, you can scale the performance and capacity of a vSRX instance by increasing the number of vCPUs and the amount of vRAM allocated to the vSRX.

143

CHAPTER 8

Configure vSRX Chassis Clusters in VMware

IN THIS CHAPTER

Configure a vSRX Chassis Cluster in Junos OS | 144

vSRX Cluster Staging and Provisioning for VMware | 154

Deploy vSRX Chassis Cluster Nodes Across Different ESXi Hosts Using dvSwitch | 165

Configure a vSRX Chassis Cluster in Junos OS

IN THIS SECTION

Chassis Cluster Overview | 144

Enable Chassis Cluster Formation | 145

Chassis Cluster Quick Setup with J-Web | 146

Manually Configure a Chassis Cluster with J-Web | 147

Chassis Cluster Overview

Prerequisites

Ensure that your vSRX instances comply with the following prerequisites before you enable chassis clustering:

• Use show version in Junos OS to ensure that both vSRX instances have the same software version.

• Use show system license in Junos OS to ensure that both vSRX instances have the same licenses installed.

144

interfaces on the respective nodes to form a control plane that synchronizes the configuration and Junos

OS kernel state. The control link (a virtual network or vSwitch) facilitates the redundancy of interfaces and services. Similarly, you connect the data plane on the respective nodes over the fabric virtual interfaces to form a unified data plane. The fabric link (a virtual network or vSwitch) allows for the management of cross-node flow processing and for the management of session redundancy.

The control plane software operates in active/passive mode. When configured as a chassis cluster, one node acts as the primary device and the other as the secondary device to ensure stateful failover of processes and services in the event of a system or hardware failure on the primary device. If the primary device fails, the secondary device takes over processing of control plane traffic.

NOTE: If you configure a chassis cluster on vSRX nodes across two physical hosts, disable igmpsnooping on the bridge that each host physical interface belongs to that the control vNICs use.

This ensures that the control link heartbeat is received by both nodes in the chassis cluster.

The chassis cluster data plane operates in active/active mode. In a chassis cluster, the data plane updates session information as traffic traverses either device, and it transmits information between the nodes over the fabric link to guarantee that established sessions are not dropped when a failover occurs.

In active/active mode, traffic can enter the cluster on one node and exit from the other node.

Chassis cluster functionality includes:

• Resilient system architecture, with a single active control plane for the entire cluster and multiple

Packet Forwarding Engines. This architecture presents a single device view of the cluster.

• Synchronization of configuration and dynamic runtime states between nodes within a cluster.

• Monitoring of physical interfaces, and failover if the failure parameters cross a configured threshold.

Unit (SPU) monitoring, failures, and manual failovers, can trigger a state transition.

Enable Chassis Cluster Formation

You create two vSRX instances to form a chassis cluster, and then you set the cluster ID and node ID on each instance to join the cluster. When a vSRX VM joins a cluster, it becomes a node of that cluster.

With the exception of unique node settings and management IP addresses, nodes in a cluster share the same configuration.

145

You can deploy up to 255 chassis clusters in a Layer 2 domain. Clusters and nodes are identified in the following ways:

• The cluster ID (a number from 1 to 255) identifies the cluster.

• The node ID (a number from 0 to 1) identifies the cluster node.

On SRX Series devices, the cluster ID and node ID are written into EEPROM. On the vSRX VM, vSRX stores and reads the IDs from boot/loader.conf and uses the IDs to initialize the chassis cluster during startup.

The chassis cluster formation commands for node 0 and node 1 are as follows:

• On vSRX node 0: user@vsrx0>set chassis cluster cluster-id number node 0 reboot

• On vSRX node 1: user@vsrx1>set chassis cluster cluster-id number node 1 reboot

The vSRX interface naming and mapping to vNICs changes when you enable chassis clustering. Use the same cluster ID number for each node in the cluster.

NOTE: When using multiple clusters that are connected to the same L2 domain, a unique clusterid needs to be used for each cluster. Otherwise you may get duplicate mac addresses on the network, because the cluster-id is used to form the virtual interface mac addresses.

After reboot, on node 0, configure the fabric (data) ports of the cluster that are used to pass real-time objects (RTOs):

• user@vsrx0# set interfaces fab0 fabric-options member-interfaces ge-0/0/0 user@vsrx0# set interfaces fab1 fabric-options member-interfaces ge-7/0/0

Chassis Cluster Quick Setup with J-Web

To configure chassis cluster from J-Web:

1. Enter the vSRX node 0 interface IP address in a Web browser.

2. Enter the vSRX username and password, and click Log In. The J-Web dashboard appears.

146

3. Click Configuration Wizards>Chassis Cluster from the left panel. The Chassis Cluster Setup wizard appears. Follow the steps in the setup wizard to configure the cluster ID and the two nodes in the cluster, and to verify connectivity.

NOTE: Use the built-in Help icon in J-Web for further details on the Chassis Cluster Setup wizard.

Manually Configure a Chassis Cluster with J-Web

Select Configure>Chassis Cluster>Cluster Configuration. The Chassis Cluster configuration page appears.

Table 29 on page 147

explains the contents of the HA Cluster Settings tab.

Table 30 on page 149

explains how to edit the Node Settings tab.

Table 31 on page 150

explains how to add or edit the HA Cluster Interfaces table.

Table 32 on page 151

explains how to add or edit the HA Cluster Redundancy Groups table.

Table 29: Chassis Cluster Configuration Page

Field Function

Node Settings

Node ID

Cluster ID

Host Name

Backup Router

Displays the node ID.

Displays the cluster ID configured for the node.

Displays the name of the node.

Displays the router used as a gateway while the Routing Engine is in secondary state for redundancy-group 0 in a chassis cluster.

147

Table 29: Chassis Cluster Configuration Page (Continued)

Field Function

Management Interface Displays the management interface of the node.

IP Address

Status

Displays the management IP address of the node.

Displays the state of the redundancy group.

• Primary–Redundancy group is active.

• Secondary–Redundancy group is passive.

Chassis Cluster>HA Cluster Settings>Interfaces

Name Displays the physical interface name.

Member Interfaces/IP

Address

Displays the member interface name or IP address configured for an interface.

Redundancy Group Displays the redundancy group.

Chassis Cluster>HA Cluster Settings>Redundancy Group

Group

Preempt

Gratuitous ARP Count

Displays the redundancy group identification number.

Displays the selected preempt option.

• True–Primary Role can be preempted based on priority.

• False–Primary Role cannot be preempted based on priority.

Displays the number of gratuitous Address Resolution Protocol ( ARP) requests that a newly elected primary device in a chassis cluster sends out to announce its presence to the other network devices.

148

Table 29: Chassis Cluster Configuration Page (Continued)

Field Function

Node Priority Displays the assigned priority for the redundancy group on that node.

The eligible node with the highest priority is elected as primary for the redundant group.

Table 30: Edit Node Setting Configuration Details

Field Function

Node Settings

Action

Host Name Specifies the name of the host.

Backup Router Displays the device used as a gateway while the

Routing Engine is in the secondary state for redundancy-group 0 in a chassis cluster.

Enter the name of the host.

Enter the IP address of the backup router.

Destination

IP Adds the destination address.

Deletes the destination address.

Delete

Interface

Click Add.

Click Delete.

Specifies the interfaces available for the router.

NOTE: Allows you to add and edit two interfaces for each fabric link.

Specifies the interface IP address.

Select an option.

Enter the interface IP address.

149

Table 30: Edit Node Setting Configuration Details (Continued)

Field Function

Add Adds the interface.

Delete Deletes the interface.

Table 31: Add HA Cluster Interface Configuration Details

Field Function

Fabric Link > Fabric Link 0 (fab0)

Action

Click Add.

Click Delete.

Interface

Add

Specifies fabric link 0.

Adds fabric interface 0.

Delete Deletes fabric interface 0.

Fabric Link > Fabric Link 1 (fab1)

Interface Specifies fabric link 1.

Enter the interface IP fabric link 0.

Click Add.

Click Delete.

Add

Delete

Adds fabric interface 1.

Deletes fabric interface 1.

Enter the interface IP for fabric link

Click Add.

Click Delete.

Redundant Ethernet

Interface Specifies a logical interface consisting of two physical Ethernet interfaces, one on each chassis.

Enter the logical interface.

150

Table 31: Add HA Cluster Interface Configuration Details (Continued)

Field Function Action

IP Specifies a redundant Ethernet IP address.

Enter a redundant Ethernet IP address.

Redundancy Group Specifies the redundancy group ID number in the chassis cluster.

Select a redundancy group from the list.

Add

Delete

Adds a redundant Ethernet IP address.

Table 32: Add Redundancy Groups Configuration Details

Field Function

Redundancy Group Specifies the redundancy group name.

Click Add.

Deletes a redundant Ethernet IP address.

Click Delete.

Action

Enter the redundancy group name.

Allow preemption of primaryship

Allows a node with a better priority to initiate a failover for a redundancy group.

NOTE: By default, this feature is disabled.

When disabled, a node with a better priority does not initiate a redundancy group failover

(unless some other factor, such as faulty network connectivity identified for monitored interfaces, causes a failover).

–

Gratuitous ARP

Count

Specifies the number of gratuitous Address

Enter a value from 1 to 16.

The default is 4.

151

Table 32: Add Redundancy Groups Configuration Details (Continued)

Field Function Action node0 priority Specifies the priority value of node0 for a redundancy group.

Enter the node priority number as 0.

node1 priority Specifies the priority value of node1 for a redundancy group.

Select the node priority number as 1.

Interface Monitor

Interface

Weight

Add

Specifies the number of redundant Ethernet interfaces to be created for the cluster.

Select an interface from the list.

Enter a value from 1 to 125.

Specifies the weight for the interface to be monitored.

Adds interfaces to be monitored by the redundancy group along with their respective weights.

Click Add.

Delete Deletes interfaces to be monitored by the redundancy group along with their respective weights.

Select the interface from the configured list and click

Delete.

IP Monitoring

Weight

Threshold

Retry Count

Specifies the global weight for IP monitoring.

Specifies the global threshold for IP monitoring.

Specifies the number of retries needed to declare reachability failure.

Enter a value from 0 to 255.

Enter a value from 5 to 15.

152

Table 32: Add Redundancy Groups Configuration Details (Continued)

Field Function Action

Retry Interval Specifies the time interval in seconds between retries.

Enter a value from 1 to 30.

IPV4 Addresses to Be Monitored

IP Specifies the IPv4 addresses to be monitored for reachability.

Enter the IPv4 addresses.

Weight Specifies the weight for the redundancy group interface to be monitored.

Enter the weight.

Interface

Secondary IP address

Add

Delete

Specifies the logical interface through which to monitor this IP address.

Enter the logical interface address.

Specifies the source address for monitoring packets on a secondary link.

Enter the secondary IP address.

Click Add.

Adds the IPv4 address to be monitored.

Deletes the IPv4 address to be monitored.

Select the IPv4 address from the list and click Delete.

153

SEE ALSO

Chassis Cluster Feature Guide for Security Devices

vSRX Cluster Staging and Provisioning for VMware

IN THIS SECTION

Deploying the VMs and Additional Network Interfaces | 154

Creating the Control Link Connection Using VMware | 155

Creating the Fabric Link Connection Using VMware | 159

Creating the Data Interfaces Using VMware | 162

Prestaging the Configuration from the Console | 163

Connecting and Installing the Staging Configuration | 164

Staging and provisioning a vSRX cluster includes the following tasks:

Deploying the VMs and Additional Network Interfaces

The vSRX cluster uses three interfaces exclusively for clustering (the first two are predefined):

• Out-of-band management interface (fxp0).

• Cluster control link (em0).

• Cluster fabric links (fab0 and fab1). For example, you can specify ge-0/0/0 as fab0 on node0 and ge-7/0/0 as fab1 on node1.

Initially, the VM has only two interfaces. A cluster requires three interfaces (two for the cluster and one for management) and additional interfaces to forward data. You can add interfaces through the VMware vSphere Web Client.

1. On the VMware vSphere Web Client, click Edit Virtual Machine Settings for each VM to create additional interfaces.

2. Click Add Hardware and specify the attributes in Table 33 on page 154 .

Table 33: Hardware Attributes

Attribute Description

Adapter Type Select VMXNET 3 from the list.

154

Table 33: Hardware Attributes (Continued)

Attribute Description

Network label Select the network label from the list.

Connect at power on Ensure that there is a check mark next to this option.

Creating the Control Link Connection Using VMware

To connect the control interface through the control vSwitch using the VMware vSphere Web Client:

1. Choose Configuration > Networking.

2. Click Add Networking to create a vSwitch for the control link.

Choose the following attributes:

• Connection Type

• Virtual Machines

• Network Access

• Create a vSphere switch

• No physical adapters

• Port Group Properties

• Network Label: HA Control

• VLAN ID: None(0)

NOTE: Port groups are not VLANs. The port group does not segment the vSwitch into separate broadcast domains unless the domains have different VLAN tags.

• To use a VLAN as a dedicated vSwitch, you can use the default VLAN tag (0) or specify a VLAN tag.

• To use a VLAN as a shared vSwitch and use a port group, assign a VLAN tag on the port group for each chassis cluster link.

3. Right-click on the control network, click Edit Settings, and select Security.

155

4. Set the promiscuous mode to Accept, and click OK, as shown in Figure 18 on page 156 .

Figure 18: Promiscuous Mode

156

NOTE: You must enable promiscuous mode on the control vSwitch for chassis cluster.

You can use the vSwitch default settings for the remaining parameters.

5. Click Edit Settings for both vSRX VMs to add the control interface (Network adapter 2) into the control vSwitch.

See Figure 19 on page 157

for vSwitch properties and Figure 20 on page 158 for VM properties for the

control vSwitch.

Figure 19: Control vSwitch Properties

157

Figure 20: Virtual Machine Properties for the Control vSwitch

158

The control interface will be connected through the control vSwitch. See Figure 21 on page 158 .

Figure 21: Control Interface Connected through the Control vSwitch

Creating the Fabric Link Connection Using VMware

To connect the fabric interface through the fabric vSwitch using the VMware vSphere Web Client:

1. Choose Configuration > Networking.

2. Click Add Networking to create a vSwitch for the fabric link.

Choose the following attributes:

• Connection Type

• Virtual Machines

• Network Access

• Create a vSphere switch

• No physical adapters

• Port Group Properties

• Network Label: HA Fabric

• VLAN ID: None(0)

NOTE: Port groups are not VLANs. The port group does not segment the vSwitch into separate broadcast domains unless the domains have different VLAN tags.

• To use a VLAN as a dedicated vSwitch, you can use the default VLAN tag (0) or specify a VLAN tag.

• To use VLAN as a shared vSwitch and use a port group, assign a VLAN tag on the port group for each chassis cluster link.

Click Properties to enable the following features:

• General-> Advanced Properties:

• MTU: 9000

• Security-> Effective Polices:

• MAC Address Changes: Accept

• Forged Transmits: Accept

3. Click Edit Settings for both vSRX VMs to add the fabric interface into the fabric vSwitch.

159

See Figure 22 on page 160

for vSwitch properties and Figure 23 on page 161 for VM properties for the

fabric vSwitch.

Figure 22: Fabric vSwitch Properties

160

Figure 23: Virtual Machine Properties for the Fabric vSwitch

161

The fabric interface will be connected through the fabric vSwitch. See Figure 24 on page 162 .

Figure 24: Fabric Interface Connected Through the Fabric vSwitch

162

Creating the Data Interfaces Using VMware

To map all the data interfaces to the desired networks:

1. Choose Configuration > Networking.

2. Click Add Networking to create a vSwitch for fabric link.

Choose the following attributes:

• Connection Type

• Virtual Machines

• Network Access

• Create a vSphere switch

• No physical adapters

• Port Group Properties

• Network Label: chassis cluster Reth

• VLAN ID: None(0)

Click Properties to enable the following features:

• Security-> Effective Polices:

• MAC Address Changes: Accept

• Forged Transmits: Accept

The data interface will be connected through the data vSwitch using the above procedure.

Prestaging the Configuration from the Console

The following procedure explains the configuration commands required to set up the vSRX chassis cluster. The procedure powers up both nodes, adds the configuration to the cluster, and allows SSH remote access.

1. Log in as the root user. There is no password.

2. Start the CLI.

root#cli root@>

3. Enter configuration mode.

configure

[edit] root@#

4. Copy the following commands and paste them into the CLI: set groups node0 interfaces fxp0 unit 0 family inet address 192.168.42.81/24 set groups node0 system hostname vsrx-node0 set groups node1 interfaces fxp0 unit 0 family inet address 192.168.42.82/24 set groups node1 system hostname vsrx-node1 set apply-groups "${node}"

5. Set the root authentication password by entering a cleartext password, an encrypted password, or an

SSH public key string (DSA or RSA).

root@# set system root-authentication plain-text-password

New password: password

163

Retype new password: password set system root-authentication encrypted-password "$ABC123"

6. To enable SSH remote access: user@host#set system services ssh

7. To enable IPv6: user@host#set security forwarding-options family inet6 mode flow-based

This step is optional and requires a system reboot.

8. Commit the configuration to activate it on the device.

user@host#commit commit complete

9. When you have finished configuring the device, exit configuration mode.

user@host#exit

Connecting and Installing the Staging Configuration

After the vSRX cluster initial setup, set the cluster ID and the node ID, as described in

"Configure a vSRX

Chassis Cluster in Junos OS" on page 144

vsrx> show chassis cluster status

Cluster ID: 1

Node Priority Status Preempt Manual failover

Redundancy group: 0 , Failover count: 1

node0 100 secondary no no

node1 150 primary no no

164

Redundancy group: 1 , Failover count: 1

node0 100 secondary no no

node1 150 primary no no

A cluster is healthy when the primary and secondary nodes are present and both have a priority greater than 0.

Deploy vSRX Chassis Cluster Nodes Across Different ESXi Hosts Using dvSwitch

Before you deploy the vSRX chassis cluster nodes for ESXi 6.0 (or greater) hosts using distributed virtual switch (dvSwitch), ensure that you make the following configuration settings from the vSphere Web

Client to ensure that the high-availability cluster control link works properly between the two nodes:

• In the dvSwitch switch settings of the vSphere Web Client, disable IGMP snooping for Multicast filtering mode (see Multicast Snooping on a vSphere Distributed Switch ).

• In the dvSwitch port group configuration of the vSphere Web Client, enable promiscuous mode (see

Configure the Security Policy for a Distributed Port Group or Distributed Port ).

This chassis cluster method uses the private virtual LAN (PVLAN) feature of dvSwitch to deploy the vSRX chassis cluster nodes at different ESXi hosts. There is no need to change the external switch configurations.

On the VMware vSphere Web Client, for dvSwitch, there are two PVLAN IDs for the primary and secondary VLANs. Select Community in the menu for the secondary VLAN ID type.

165

Use the two secondary PVLAN IDs for the vSRX control and fabric links. See

Figure 25 on page 166

and

Figure 26 on page 167 .

Figure 25: dvPortGroup3 Settings

166

Figure 26: dvPortGroup6 Settings

167

NOTE: The configurations described above must reside at an external switch to which distributed switch uplinks are connected. If the link at the external switch supports native VLAN, then VLAN can be set to none in the distributed switch port group configuration. If native VLAN is not supported on the link, this configuration should have VLAN enabled.

You can also use regular VLAN on a distributed switch to deploy vSRX chassis cluster nodes at different

ESXi hosts using dvSwitch. Regular VLAN works similarly to a physical switch. If you want to use regular

VLAN instead of PVLAN, disable IGMP snooping for chassis cluster links.

However, use of PVLAN is recommended because:

• PVLAN does not impose IGMP snooping.

• PVLAN can save VLAN IDs.

NOTE: When the vSRX cluster across multiple ESXi hosts communicates through physical switches, then you need to consider the other Layer 2 parameters at: https://kb.juniper.net/ library/CUSTOMERSERVICE/GLOBAL_JTAC/NT21/ LAHAAppNotev4.pdf

168

PART

vSRX Deployment for Microsoft

Hyper-V

Overview | 170

Install vSRX in Microsoft Hyper-V | 179

vSRX VM Management with Microsoft Hyper-V | 196

Configure vSRX Chassis Clusters | 212

CHAPTER 9

Overview

IN THIS CHAPTER

Understand vSRX with Microsoft Hyper-V | 170

Requirements for vSRX on Microsoft Hyper-V | 172

Understand vSRX with Microsoft Hyper-V

IN THIS SECTION

vSRX in Microsoft Hyper-V | 170

This section presents an overview of vSRX as deployed in Microsoft Hyper-V.

vSRX in Microsoft Hyper-V

Microsoft Hyper-V is a hypervisor-based virtualization technology. It provides software infrastructure and basic management tools that you can use to create and manage a virtualized server computing environment. This virtualized environment can be used to address a variety of business goals aimed at improving efficiency and reducing costs. Hyper-V works on x86- and x64-based systems running

Windows.

You deploy a vSRX virtual security appliance on a Microsoft Hyper-V server to provide networking security features for the virtualized server computing environment. Hyper-V implements isolation of virtual machines in terms of a partition. The vSRX virtual machine runs in Microsoft Hyper-V as a child partition.

Note the following for deploying vSRX on a Microsoft Hyper-V server:

• Starting in Junos OS Release 15.1X49-D80 and Junos OS Release 17.3R1, you can deploy the vSRX only on Microsoft Hyper-V Server 2012 R2 or 2012.

170

• Starting in Junos OS Release 15.1X49-D100 and Junos OS Release 17.4R1, you can deploy the vSRX on Microsoft Hyper-V Server 2016.

Figure 27 on page 171 illustrates the deployment of a vSRX in a Hyper-V environment to provide

security for applications running on one or more virtual machines.

Figure 27: vSRX Deployment in Hyper-V

171

Release History Table

Release Description

15.1X49-D80 Starting in Junos OS Release 15.1X49-D80 and Junos OS Release 17.3R1, you can deploy the vSRX only on Microsoft Hyper-V Server 2012 R2 or 2012.

15.1X49-D100 Starting in Junos OS Release 15.1X49-D100 and Junos OS Release 17.4R1, you can deploy the vSRX on Microsoft Hyper-V Server 2016.

RELATED DOCUMENTATION

Hyper-V on Windows Server 2016

Microsoft Hyper-V Overview

Microsoft Hyper-V

Requirements for vSRX on Microsoft Hyper-V

IN THIS SECTION

Software Requirements | 172

Hardware Requirements | 173

Best Practices for Improving vSRX Performance | 174

Interface Mapping for vSRX on Microsoft Hyper-V | 175

vSRX Default Settings on Microsoft Hyper-V | 177

This section presents an overview of requirements for deploying a vSRX instance on Microsoft Hyper-V.

Software Requirements

Table 34 on page 172

lists the software requirements for the vSRX instance on Microsoft Hyper-V.

NOTE: Only the vSRX small flavor is supported on Microsoft Hyper-V.

Table 34: Specifications for vSRX for Microsoft Hyper-V

Component Specification

Hypervisor support

• Starting in Junos OS Release 15.1X49-D80 and Junos OS Release 17.3R1, you can deploy the vSRX only on Microsoft Hyper-V Server 2012 R2 or 2012.

• Starting in Junos OS Release 15.1X49-D100 and Junos OS Release 17.4R1, you can deploy the vSRX on Microsoft Hyper-V Server 2016.

Memory 4 GB

Disk space 16 GB (IDE or SCSI drives)

172

Table 34: Specifications for vSRX for Microsoft Hyper-V (Continued)

Component Specification vCPUs 2

Virtual network adapters

8 Hyper-V specific network adapters

Table 35: Specifications for vSRX 3.0 for Microsoft Hyper-V

Component Specification

Hypervisor support

Microsoft Hyper-V Windows Server 2016

Memory 4 GB

Disk space 18 GB (IDE) vCPUs

Virtual network adapters

8 Hyper-V specific network adapters

Starting in Junos OS Release 19.1R1, the vSRX 3.0 instance supports guest OS with 2 vCPUs, 4-GB virtual RAM, and a 18-GB disk space on Microsoft Hyper-V and Azure for improved performance.

Hardware Requirements

Table 36 on page 174

lists the hardware specifications for the host machine that runs the vSRX VM.

173

Table 36: Hardware Specifications for the Host Machine

Component Specification

Host memory size Minimum 4 GB

Host processor type

Gigabit (10/100/1000baseT)

Ethernet adapter x86 or x64-based multicore processor

NOTE: DPDK requires Intel Virtualization VT-x/VT-d support in the CPU. See About Intel Virtualization Technology.

Emulates the multiport DEC 21140 10/100TX 100 MB

Ethernet network adapter with one to four network connections.

Best Practices for Improving vSRX Performance

Review the following practices to improve vSRX performance.

NUMA Nodes

We recommend that you bind the vSRX instance with a specific NUMA node by setting

NUMA node affinity. NUMA node affinity constrains the vSRX VM resource scheduling to only the specified NUMA node.

174

Interface Mapping for vSRX on Microsoft Hyper-V

Each network adapter defined for a vSRX is mapped to a specific interface, depending on whether the vSRX instance is a standalone VM or one of a cluster pair for high availability.

NOTE: Starting in Junos OS Release 15.1X49-D100 for vSRX, support for chassis clustering to provide network node redundancy is only available on Microsoft Hyper-V Server 2016.

Note the following:

• In standalone mode:

• fxp0 is the out-of-band management interface.

• ge-0/0/0 is the first traffic (revenue) interface.

• In cluster mode:

• fxp0 is the out-of-band management interface.

• em0 is the cluster control link for both nodes.

• Any of the traffic interfaces can be specified as the fabric links, such as ge-0/0/0 for fab0 on node

0 and ge-7/0/0 for fab1 on node 1.

Table 37 on page 175

shows the interface names and mappings for a standalone vSRX VM.

Table 37: Interface Names for a Standalone vSRX VM

Network

Adapter

Interface Name in Junos OS

1 fxp0

4 ge-0/0/0 ge-0/0/1 ge-0/0/2

175

Table 37: Interface Names for a Standalone vSRX VM (Continued)

Network

Adapter

Interface Name in Junos OS

5 ge-0/0/3

8 ge-0/0/4 ge-0/0/5 ge-0/0/6

Table 38 on page 176

shows the interface names and mappings for a pair of vSRX VMs in a cluster (node

0 and node 1).

Table 38: Interface Names for a vSRX Cluster Pair

Network

Adapter

Interface Name in Junos OS

1 fxp0 (node 0 and 1) em0 (node 0 and 1) ge-0/0/0 (node 0) ge-7/0/0 (node 1)

6 ge-0/0/1 (node 0) ge-7/0/1 (node 1) ge-0/0/2 (node 0) ge-7/0/2 (node 1) ge-0/0/3 (node 0) ge-7/0/3 (node 1)

176

Table 38: Interface Names for a vSRX Cluster Pair (Continued)

Network

Adapter

Interface Name in Junos OS

7 ge-0/0/4 (node 0) ge-7/0/4 (node 1)

8 ge-0/0/5 (node 0) ge-7/0/5 (node 1)

vSRX Default Settings on Microsoft Hyper-V

vSRX requires the following basic configuration settings:

• Interfaces must be assigned IP addresses.

• Interfaces must be bound to zones.

• Policies must be configured between zones to permit or deny traffic.

Table 39 on page 177

lists the factory-default settings for security policies on the vSRX.

Table 39: Factory Default Settings for Security Policies

Source Zone Destination Zone Policy Action trust untrust permit trust untrust trust trust permit deny

177

Release History Table

Release Description

19.1R1

Starting in Junos OS Release 19.1R1, the vSRX 3.0 instance supports guest OS with 2 vCPUs, 4-

GB virtual RAM, and a 18-GB disk space on Microsoft Hyper-V and Azure for improved performance.

15.1X49-D80 Starting in Junos OS Release 15.1X49-D80 and Junos OS Release 17.3R1, you can deploy the vSRX only on Microsoft Hyper-V Server 2012 R2 or 2012.

15.1X49-D100 Starting in Junos OS Release 15.1X49-D100 and Junos OS Release 17.4R1, you can deploy the vSRX on Microsoft Hyper-V Server 2016.

15.1X49-D100 Starting in Junos OS Release 15.1X49-D100 for vSRX, support for chassis clustering to provide network node redundancy is only available on Microsoft Hyper-V Server 2016.

RELATED DOCUMENTATION

KB Article - Interface must be in the same routing instance as the other interfaces in the zone

About Intel Virtualization Technology

DPDK Release Notes

178

CHAPTER 10

Install vSRX in Microsoft Hyper-V

IN THIS CHAPTER

Prepare for vSRX Deployment in Microsoft Hyper-V | 179

Deploy vSRX in a Hyper-V Host Using the Hyper-V Manager | 181

Deploy vSRX in a Hyper-V Host Using Windows PowerShell | 191

Prepare for vSRX Deployment in Microsoft Hyper-V

Note the following guidelines when deploying vSRX on a Microsoft Hyper-V server:

• Starting in Junos OS Release 15.1X49-D80 and Junos OS Release 17.3R1, you can deploy the vSRX only on Microsoft Hyper-V Server 2012 R2 or 2012.

• Starting in Junos OS Release 15.1X49-D100 and Junos OS Release 17.4R1, you can deploy the vSRX on Microsoft Hyper-V Server 2016.

• Ensure that the host CPU supports a 64-bit x86 Intel processor and is running Windows.

• Ensure that you have a user account with administrator permissions to enable the computer to deploy a vSRX virtual machine (VM) using either Microsoft Hyper-V Manager or Windows

PowerShell.

• Create the virtual switches on the Hyper-V host computer necessary to support the fxp0 (out-ofband management) interface and the traffic (revenue) interface supported by the vSRX VM. You create virtual switches using either the Microsoft Hyper-V Manager or Windows PowerShell. See

"Add vSRX Interfaces" on page 201 for details on adding virtual switches for the vSRX VM using the

Virtual Switch Manager.

179

Figure 28 on page 180 illustrates the deployment of a vSRX in a Hyper-V environment to provide

security for applications running on one or more virtual machines.

Figure 28: Example of vSRX Deployment in Hyper-V

180

Release History Table

Release Description

15.1X49-D80 Starting in Junos OS Release 15.1X49-D80 and Junos OS Release 17.3R1, you can deploy the vSRX only on Microsoft Hyper-V Server 2012 R2 or 2012.

15.1X49-D100 Starting in Junos OS Release 15.1X49-D100 and Junos OS Release 17.4R1, you can deploy the vSRX on Microsoft Hyper-V Server 2016.

RELATED DOCUMENTATION

Install Hyper-V and Create a Virtual Machine

Create a Virtual Machine in Hyper-V

Create a Virtual Switch for Hyper-V Virtual Machines

Hyper-V Virtual Switch

Deploy vSRX in a Hyper-V Host Using the Hyper-V Manager

Use this procedure to deploy and configure the vSRX as a virtual security appliance in the Hyper-V environment using Hyper-V Manager.

Note the following for deploying vSRX on a Microsoft Hyper-V server:

• Starting in Junos OS Release 15.1X49-D80 and Junos OS Release 17.3R1, you can deploy the vSRX only on Microsoft Hyper-V Server 2012 R2 or 2012.

• Starting in Junos OS Release 15.1X49-D100 and Junos OS Release 17.4R1, you can deploy the vSRX on Microsoft Hyper-V Server 2016.

NOTE: To upgrade an existing vSRX instance, see Migration, Upgrade, and Downgrade in the vSRX Release Notes.

To deploy vSRX using Hyper-V Manager:

Download the vSRX software image for Microsoft Hyper-V from the Juniper Networks website . The vSRX disk image supported by Microsoft Hyper-V is a virtual hard disk (VHD) format file.

CAUTION: Do not change the filename of the downloaded software image or the installation will fail.

Log onto your Hyper-V host computer using the Administrator account.

Open the Hyper-V Manager by selecting Start > Administrative Tools > Hyper-V Manager. The welcome page for Hyper-V appears the first time that you open Hyper-V Manager.

Create a virtual machine by selecting Action > New > Virtual Machine. The Before You Begin screen appears for the New Virtual Machine Wizard. Click Next to move through each page of the wizard, or you can click the name of a page in the left pane to move directly to that page.

181

From the Specify Name and Location page (see Figure 29 on page 182 ), enter a name and location

for the vSRX VM that you are creating and then click Next. We recommend that you keep this name the same as the hostname you intend to assign to the vSRX VM.

Figure 29: Specify Name and Location Page

182

From the Specify Generation page (see Figure 30 on page 183 ), keep the default setting of

Generation 1 as the generation of the vSRX VM and then click Next.

Figure 30: Specify Generation Page

183

From the Assign Memory page (see

Figure 31 on page 184

), enter 4096 MB as the amount of startup memory to assign to the vSRX VM. Leave Use Dynamic Memory for this virtual machine clear. Click Next.

Figure 31: Assign Memory Page

184

From the Configure Networking page (see Figure 32 on page 185

), select a virtual switch from a list of existing virtual switches on the Hyper-V host computer to connect to the vSRX management interface. The default is Not connected. Click Next.

NOTE: See "Add vSRX Interfaces" on page 201

for the procedure on adding virtual switches for the vSRX VM using the Virtual Switch Manager.

Figure 32: Configure Networking Page

185

From the Connect Virtual Hard Disk page (see Figure 33 on page 186 ), click Use an existing virtual

hard disk and browse to the location of the vSRX virtual hard disk (VHD) file (downloaded in Step

1). Click Next.

Figure 33: Connect Virtual Hard Disk Page

186

10. After you have finished configuring the new virtual machine, verify your selections in the Summary

page (see Figure 34 on page 187 ) and then click Finish to complete the installation.

Figure 34: Summary Page

187

11. Right-click the vSRX VM and select Settings from the context menu.

12. From the Settings dialog box, under the Hardware section, select Processor. The Processor pane

appears (see Figure 35 on page 188 ). Enter 2 in the Number of virtual processors field (the default

is 1).

Figure 35: Processor Pane

188

13. From the Settings dialog box, under the Hardware section, select Network Adapter. The Network

Adapter pane appears (see Figure 36 on page 189 ).

From the Virtual switch drop-down list, select a virtual switch to assign to a network adapter to be used by the vSRX VM (see

"Add vSRX Interfaces" on page 201 for details on adding virtual

switches). Each network adapter that is defined for a vSRX is mapped to a specific interface. See

"Requirements for vSRX on Microsoft Hyper-V" on page 172 for a summary of interface names and

mappings for a vSRX VM.

NOTE: If you need to add a network adapter to assign to a virtual switch, click Add

Hardware > Network Adapter > Add.

Figure 36: Network Adapter Pane

189

14. Enable the MAC address spoofing function for the vSRX VM if a network adapter is to be used as an interface for Layer 2 mode support on the vSRX. From the Network Adapter pane select

Advanced Features. The Advanced Features pane appears (see

Figure 37 on page 190

). Click the

Enable MAC address spoofing check box.

MAC address spoofing allows each network adapter to change its source MAC address for outgoing packets to one that is not assigned to them. Enabling MAC address spoofing ensures those packets

are not dropped by the network adapter if the source MAC address fails to match the outgoing interface MAC address.

Click OK when you complete your vSRX VM selections.

Figure 37: Network Adapter Advanced Features Pane

190

15. On Microsoft Hyper-V Server 2016, you will need to enable nested virtualization for the vSRX VM before you power on the vSRX instance. This procedure can only be performed in the Hyper-V environment using Windows PowerShell (see,

"Deploy vSRX in a Hyper-V Host Using Windows

PowerShell" on page 191 , Step 9). You cannot enable nested virtualization from the Hyper-V

Manager because nessted virtualization is not supported on Microsoft Hyper-V Server 2012.

NOTE: Nested virtualization can only be configured on a host running Microsoft Hyper-V

Server 2016. In addition, Dynamic Memory must be disabled on the virtual machine containing the nested instance of Hyper-V.

16. Launch and power on the vSRX instance in the Hyper-V Manager by selecting the vSRX VM from the list of virtual machines. Right-click and select Start from the context menu (or select Action >

Start).

17. Configure the basic settings for the vSRX (see

"Configure vSRX Using the CLI" on page 196 ).

Release History Table

Release Description

15.1X49-D80 Starting in Junos OS Release 15.1X49-D80 and Junos OS Release 17.3R1, you can deploy the vSRX only on Microsoft Hyper-V Server 2012 R2 or 2012.

15.1X49-D100 Starting in Junos OS Release 15.1X49-D100 and Junos OS Release 17.4R1, you can deploy the vSRX on Microsoft Hyper-V Server 2016.

RELATED DOCUMENTATION

Install Hyper-V and Create a Virtual Machine

Create a Virtual Machine in Hyper-V

Virtual Machine Settings in Hyper-V Manager Explained

Deploy vSRX in a Hyper-V Host Using Windows PowerShell

Use this procedure to deploy and configure the vSRX as a virtual security appliance in the Hyper-V environment using Windows PowerShell.

Note the following for deploying vSRX on a Microsoft Hyper-V server:

• Starting in Junos OS Release 15.1X49-D80 and Junos OS Release 17.3R1, you can deploy the vSRX only on Microsoft Hyper-V Server 2012 R2 or 2012.

• Starting in Junos OS Release 15.1X49-D100 and Junos OS Release 17.4R1, you can deploy the vSRX on Microsoft Hyper-V Server 2016.

191

NOTE: To upgrade an existing vSRX instance, see Migration, Upgrade, and Downgrade in the vSRX Release Notes.

To deploy vSRX using Windows PowerShell:

Download the vSRX software image for Microsoft Hyper-V from the Juniper Networks website . The vSRX disk image supported by Microsoft Hyper-V is a virtual hard disk (VHD) format file.

CAUTION: Do not change the filename of the downloaded software image or the installation will fail.

On the Windows desktop, click the Start button and type Windows PowerShell.

Right-click Windows PowerShell and select Run as administrator.

Run the following command to enable Hyper–V using PowerShell:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

Enter the New-VM command to create the vSRX VM. The command syntax is as follows:

PS C:>\Users\Administrator> New-VM -Name <Name> -MemoryStartupBytes <Memory> -BootDevice

<BootDevice> -VHDPath <VHDPath> -Path <Path> -Generation <Generation> -Switch <SwitchName>

See

Table 40 on page 192

for a summary of the parameters in the New-VM command.

Table 40: New-VM Command Parameters

Parameter Description

-Name Specify a name for the vSRX VM that you are creating. We recommend keeping this name the same as the hostname you intend to give to the vSRX VM.

-MemoryStartupBytes

-BootDevice

Enter 4GB as the amount of startup memory to assign to the vSRX VM.

Enter VHD as the device that the vSRX VM boots to when it starts.

192

Table 40: New-VM Command Parameters (Continued)

Parameter Description

-VHDPath Specify the location of the vSRX virtual hard disk (VHD) file that you want to deploy.

-Path Specify the location to store the vSRX VM configuration files.

-Generation

-SwitchName

Enter 1 to create a generation 1 virtual machine for the vSRX.

Specify the name of the virtual switch that you want the vSRX

VM to assign to a network adapter used by the vSRX VM. Each network adapter that is defined for a vSRX is mapped to a specific interface. See

"Requirements for vSRX on Microsoft

Hyper-V" on page 172 for a summary of interface names and

mappings for a vSRX VM.

NOTE: To locate the name of a previously created virtual switch, use the Get-VMSwitch command. See

"Add vSRX

Interfaces" on page 201 for the procedure on adding virtual

switches for the vSRX VM using the Virtual Switch Manager.

The following is an example of the New-VM command syntax for creating a vSRX VM:

PS C:>\Users\Administrator> New-VM -Name vSRX_0109 -MemoryStartupBytes 4GB -BootDevice VHD -

VHDPath C:\Users\Public\Documents\Hyper-V\vsrx-0109-powershell\vsrx\media-vsrxvmdisk-151X49D80.hyper-v.vhd -Path ’C:\Users\Public\Documents\Hyper-V\vsrx-0109\’ Generation 1

SwitchName test

Set the number of processors for the newly created vSRX VM by entering the Set-VMProcessor command. Specify Count 2 for the number of processors. For example:

PS C:>\Users\Administrator> Set-VMProcessor -VMName <vSRVName> -Count 2

Verify the newly created vSRX VM by entering the Get-VM command. For example:

PS C:>\Users\Administrator> Get-VM -VMName <vSRVName>

193

The output for the command is as follows:

Name State CPUUSage(%) MemoryAssigned(M) Uptime State Version vSRX_0109 Off 0 0 00:00:00 Operating normally 8.0

Enable the MAC address spoofing function for the vSRX VM if a network adapter is to be used as an interface for Layer 2 mode support on the vSRX. MAC address spoofing allows the vSRX VM’s network adapter to change its source MAC address for outgoing packets to one that is not assigned to them. Enabling MAC address spoofing ensures those packets are not dropped by the network adapter if the source MAC address fails to match the outgoing interface MAC address.

The command syntax is as follows:

PS C:>\Users\Administrator> Set-VMNetworkAdapter -VMName <vSRVName> –computerName

<HyperVHostName> –VMNetworkAdapter <NetworkAdapterName> -MacAddressSpoofing On

Verify that MacAddressSpoofing is On.

PS C:>\Users\Administrator> Get-VMNetworkAdapter -VMName <vSRVName> –computerName

<HyperVHostName> | fl <HyperVHostName>name,macaddressspoofing

The output for the command is as follows:

Name : vSRX_0109

MacAddressSpoofing : On

Enable nested virtualization for the vSRX VM by using the Set-VMProcessor command, where VMName is the name of the vSRX VM you created. By default, the virtualization extensions are disabled for each VM. Nested virtualization allows you to run Hyper-V inside of a Hyper-V virtual machine. For example:

PS C:>\Users\Administrator> Set-VMProcessor -VMName <vSRX_0109> -ExposeVirtualizationExtensions

$true

NOTE: Nested virtualization can only be configured on a host running Microsoft Hyper-V

Server 2016. In addition, Dynamic Memory must be disabled on the virtual machine containing the nested instance of Hyper-V.

10. Launch and power on the vSRX VM by using the Start-VM command, where Name is the name of the vSRX VM you created. For example:

PS C:>\Users\Administrator> Start-VM -Name <vSRX_0109>

194

11. Configure the basic settings for the vSRX (see

"Configure vSRX Using the CLI" on page 196 ).

Release History Table

Release Description

15.1X49-D80 Starting in Junos OS Release 15.1X49-D80 and Junos OS Release 17.3R1, you can deploy the vSRX only on Microsoft Hyper-V Server 2012 R2 or 2012.

15.1X49-D100 Starting in Junos OS Release 15.1X49-D100 and Junos OS Release 17.4R1, you can deploy the vSRX on Microsoft Hyper-V Server 2016.

RELATED DOCUMENTATION

Hyper-V Module for Windows PowerShell

Create a Virtual Machine in Hyper-V

Run Hyper-V in a Virtual Machine with Nested Virtualization

195

CHAPTER 11

vSRX VM Management with Microsoft Hyper-V

IN THIS CHAPTER

Configure vSRX Using the CLI | 196

Configure vSRX Using the J-Web Interface | 198

Add vSRX Interfaces | 201

Power Down a vSRX VM with Hyper-V | 211

Configure vSRX Using the CLI

To configure the instance using the CLI:

Verify that the vSRX instance is powered on.

Start the CLI.

root#cli root@>

Enter configuration mode.

configure

[edit] root@#

Set the root authentication password by entering a cleartext password, an encrypted password, or an SSH public key string ( DSA or RSA). The following is an example of a plain-text password. The

CLI prompts you for the password and then encrypts it.

[edit] root@# set system root-authentication plain-text-password

196

New password: password

Retype new password: password

Configure the hostname.

[edit] root@# set system host-name host-name

Configure the management interface.

[edit] root@# set interfaces fxp0 unit 0 family inet dhcp-client

Configure the traffic interfaces.

[edit] root@# set interfaces ge-0/0/0 unit 0 family inet dhcp-client

Configure basic security zones and bind them to traffic interfaces.

[edit] root@# set security zones security-zone trust interfaces ge-0/0/0.0

10. Verify the configuration changes.

[edit] root@# commit check configuration check succeeds

11. Commit the configuration to activate it on the instance.

[edit] root@# commit commit complete

NOTE: Certain Junos OS software features require a license to activate the feature. To enable a licensed feature, you need to purchase, install, manage, and verify a license key that corresponds

197

to each licensed feature. To conform to software feature licensing requirements, you must purchase one license per feature per instance. The presence of the appropriate software unlocking key on your virtual instance allows you to configure and use the licensed feature.

See Managing Licenses for vSRX for details.

RELATED DOCUMENTATION

CLI User Guide

Junos OS for SRX Series

Configure vSRX Using the J-Web Interface

IN THIS SECTION

Access the J-Web Interface and Configuring vSRX | 198

Apply the Configuration | 201

Add vSRX Feature Licenses | 201

Access the J-Web Interface and Configuring vSRX

To configure vSRX using the J-Web Interface:

1. Launch the J-Web interface from a Web browser.

NOTE: You will be prompted to accept a system-generated certificate to access a vSRX VM using the J-Web interface.

2. Enter the vSRX out-of-band management (fxp0) interface IP address in the Address box.

3. Specify the username and password.

4. Click Log In, and select the Configuration Wizards tab from the left navigation panel. The J-Web

Setup wizard page opens.

198

5. Click Setup.

You can use the Setup wizard to configure the vSRX VM or edit an existing configuration.

• Select Edit Existing Configuration if you have already configured the wizard using the factory mode.

• Select Create New Configuration to configure the vSRX VM using the wizard.

The following configuration options are available in the guided setup:

• Basic

Select basic to configure the vSRX VM name and user account information as shown in

Table

41 on page 199

• Instance name and user account information

Table 41: Instance Name and User Account Information

Field Description

Instance name Type the name of the vSRX instance.

Root password Create a default root user password.

Verify password

Verify the default root user password.

Operator Add an optional administrative account in addition to the root account.

User role options include:

• Super User: This user has full system administration rights and can add, modify, and delete settings and users.

• Operator: This user can perform system operations such as a system reset but cannot change the configuration or add or modify users.

• Read only: This user can only access the system and view the configuration.

• Disabled: This user cannot access the system.

199

• Select either Time Server or Manual. Table 42 on page 200 lists the system time options.

Table 42: System Time Options

Field Description

Time Server

Host Name Type the hostname of the time server. For example: ntp.example.com.

IP Type the IP address of the time server in the IP address entry field. For example: 192.0.2.254.

NOTE: You can enter either the hostname or the IP address.

Manual

Date

Time

Click the current date in the calendar.

Set the hour, minute, and seconds. Choose AM or PM.

Time Zone (mandatory)

Time Zone Select the time zone from the list. For example: GMT Greenwich Mean Time

GMT.

• Expert a. Select Expert to configure the basic options as well as the following advanced options:

• Four or more internal zones

• Internal zone services

• Application of security policies between internal zones b. Click the Need Help icon for detailed configuration information.

You see a success message after the basic configuration is complete.

200

Apply the Configuration

To apply the configuration settings for vSRX:

1. Review and ensure that the configuration settings are correct, and click Next. The Commit

Configuration page appears.

2. Click Apply Settings to apply the configuration changes to vSRX.

3. Check the connectivity to vSRX, as you might lose connectivity if you have changed the management zone IP. Click the URL for reconnection instructions on how to reconnect to the instance.

4. Click Done to complete the setup.

After successful completion of the setup, you are redirected to the J-Web interface.

CAUTION: After you complete the initial setup, you can relaunch the J-Web Setup wizard by clicking Configuration>Setup. You can either edit an existing configuration or create a new configuration. If you create a new configuration, the current configuration in vSRX will be deleted.

Add vSRX Feature Licenses

Certain Junos OS software features require a license to activate the feature. To enable a licensed feature, you need to purchase, install, manage, and verify a license key that corresponds to each licensed feature. To conform to software feature licensing requirements, you must purchase one license per feature per instance. The presence of the appropriate software unlocking key on your virtual instance allows you to configure and use the licensed feature.

See Managing Licenses for vSRX for details.

Add vSRX Interfaces

IN THIS SECTION

Add Virtual Switches | 202

Configure the vSRX to Use a VLAN | 209

201

The Hyper-V virtual switch is a software-based Layer 2 Ethernet network switch that connects VMs to either physical or virtual networks. A virtual switch can be configured from Hyper-V Manager or

Windows PowerShell . The Hyper-V host uses the virtual switches to connect virtual machines to the internet through the host computer's network connection. You configure networking for the vSRX by adding, removing, and modifying its associated network adapters in the Hyper-V host as necessary.

NOTE: To perform this procedure, you must have appropriate permissions. Contact your Virtual

Server administrator to request the proper permissions to add a virtual switch and network adapter..

For the vSRX VM, you pair a network adapter with a virtual switch for the vSRX to receive and transmit traffic. You map network adapters to the specific vSRX interfaces: Network adapter 1 is mapped to the fxp0 (out-of-band management) interface, network adapter 2 is mapped to the ge-0/0/0 (revenue)

interface, network adapter 3 is mapped to ge-0/0/1, and so on (see "Requirements for vSRX on

Microsoft Hyper-V" on page 172 ). Hyper-V supports a maximum of eight network adapters.

NOTE: When adding virtual switches, there are no limits imposed by Hyper-V. The practical limit depends on the available computing resources.

This section includes the following topics on adding vSRX interfaces in Hyper-V:

Add Virtual Switches

To add virtual switches for the vSRX VM using the Virtual Switch Manager in the Hyper-V Manager:

Open the Hyper-V Manager by selecting Start > Administrative Tools > Hyper-V Manager.

Select Action > Virtual Switch Manager. The Virtual Switch Manager appears.

202

Under the Virtual Switches section, select New virtual network switch. The Create Virtual Switch

pane appears (see Figure 38 on page 203 ).

Figure 38: Create Virtual Switch Pane

203

Choose the type of virtual switch to create:

• External—Gives virtual machines access to a physical network to communicate with servers and clients on an external network. It allows virtual machines on the same Hyper-V server to communicate with each other.

• Internal—Allows communication between virtual machines on the same Hyper-V server, and between the virtual machines and the management host operating system.

• Private—Allows communication only between virtual machines on the same Hyper-V server. A private network is isolated from all external network traffic on the Hyper-V server. This type of network is useful when you must create an isolated networking environment, like an isolated test domain.

In most cases when adding a vSRX network adapter, select External as the type of virtual switch.

Internal and private virtual switches are intended to keep network traffic within the Hyper-V server.

NOTE: For the fxp0 (out-of-band management) interface, connect it to External virtual switch, which could connect to an external network.

For the ge-0/0/0 (revenue port) interface, if only communication between VMs in the same

Hyper-V server is needed, Internal or Private virtual switch should be sufficient. However, if communication between the VM and an external network is needed, connect it to External virtual switch.

204

Select Create Virtual Switch. The Virtual Switch Properties pane appears (see Figure 39 on page

205

Figure 39: Virtual Switch Properties Pane

205

Specify a name for the virtual switch.

Choose the physical network interface card b(NIC) that you want to use (only a requirement when you select External).

Isolate network traffic from the management Hyper-V host operating system or other virtual machines that share the same virtual switch by selecting Enable virtual LAN identification. You can change the VLAN ID to any number or leave the default. See

"Configure the vSRX to Use a VLAN" on page 209

for details.

Click OK, then click Yes to apply networking changes and to close the Virtual Switch Manager window.

10. If necessary, repeat Steps 3 through 9 to add additional network adapters for use by the vSRX VM.

11. Right-click the vSRX VM and select Settings from the context menu. From the Settings dialog box, under the Hardware section, click Network Adapter. The Network Adapter pane appears (see

Figure 40 on page 207

206

12. From the Virtual switch drop-down list, select the virtual switch that you want to assign to this network adapter. See

"Requirements for vSRX on Microsoft Hyper-V" on page 172

for a summary of interface names and mappings for a vSRX VM.

Figure 40: Adding Virtual Switch to Network Adapter Example

207

13. If a network adapter is to be used as an interface for Layer 2 mode support on the vSRX, then from the Network Adapter pane select Advanced Features. Select the Enable MAC address spoofing

check box to enable the MAC address spoofing function for the network adapter (see Figure 41 on page 208

MAC address spoofing allows each network adapter to change its source MAC address for outgoing packets to one that is not assigned to them. Enabling MAC address spoofing ensures those packets are not dropped by the network adapter if the source MAC address fails to match the outgoing interface MAC address.

Figure 41: Network Adapter Enable MAC Address Spoofing Example

208

14. Click Apply and OK to save the changes in the Settings dialog box.

15. Launch and power on the vSRX instance in the Hyper-V Manager by selecting the vSRX VM from the list of virtual machines, and then right-click and select Start from the context menu (or select

Action > Start).

SEE ALSO

Create a Virtual Switch for Hyper-V Virtual Machines

Create a Virtual Network

Configure the vSRX to Use a VLAN

Hyper-V supports the configuration of VLANs on a network adapter in the host computer. For each network adapter that you configure for the vSRX VM, if required, you can add a VLAN identifier to specify the VLAN that the vSRX VM will use for all network communications through the network adapter.

By default, Hyper-V enables trunk mode for a VLAN. Trunk mode allows multiple VLAN IDs to share a connection between the physical network adapter and the physical network.

To give the vSRX VM external access on the virtual network in multiple VLANs, you will need to configure the port on the physical network to be in trunk mode. You will also need to know the specific

VLANs that are used and all of the VLAN IDs used by the virtual machines that the virtual network supports.

To utilize a Hyper-V VLAN, ensure that you are using a physical network adapter that supports 802.1q

VLAN tagging. By default, the virtual network adapter in Hyper-V is in untagged mode and you might need to enable the feature on a virtual network adapter.

NOTE: By using Windows PowerShell, you can determine the mode of the vNIC ( Get-

VmNetworkAdapterVlan command) and change the mode of the vNIC ( Set-VmNetworkAdapterVlan command). See Get-VMNetworkAdapterVlan and Set-VMNetworkAdapterVlan for details on both Windows PowerShell virtual network adapter commands.

To add a VLAN for a vSRX VM virtual network adapter:

1. Open the Hyper-V Manager by selecting Start > Administrative Tools > Hyper-V Manager.

2. Right-click the vSRX VM and select Settings from the context menu.

3. From the Settings dialog box, under the Hardware section, select the network adapter connected to the external virtual network. The Network Adapter pane appears.

4. Select Enable virtual LAN identification, and then enter the VLAN ID you intend to use (see Figure 42 on page 210 ). You can change the VLAN ID to any number or leave the default. This is the VLAN

209

identification number that the vSRX will use for all network communication through this network adapter.

Figure 42: Enable VLAN Identification Example

210

5. Click OK, and then click Yes to apply networking changes.

6. If necessary, repeat Steps 3 through 5 to add VLAN identification to additional network adapters in use by the vSRX VM.

SEE ALSO

Hyper-V: Configure VLANs and VLAN Tagging

Understanding Hyper-V VLANs

Power Down a vSRX VM with Hyper-V

In situations where you need to modify the vSRX VM settings from Hyper-V, you must first perform a graceful shut down of the vSRX VM using the Shut Down command. The vSRX VM performs an orderly closing of all programs and attempts to shut off power to avoid data loss.

NOTE: If you are using Microsoft PowerShell, use the Stop-VM command to perform a graceful shutdown of the vSRX VM.

To gracefully shut down the vSRX instance on the Hyper-V host computer:

1. Log onto your Hyper-V host computer using the Administrator account.

2. Open the Hyper-V Manager by selecting Start > Administrative Tools > Hyper-V Manager.

3. Power down the vSRX instance in the Hyper-V Manager by selecting the vSRX VM from the list of virtual machines, and then ight-click and select Shut Down from the context menu (or select Action >

Shut Down).

4. Power on the vSRX instance in the Hyper-V Manager by selecting the vSRX VM from the list of virtual machines, and then right-click and select Start from the context menu (or select Action >

Start).

NOTE: If you are using Microsoft PowerShell, use the Start-VM command to start the vSRX

VM.

211

CHAPTER 12

Configure vSRX Chassis Clusters

IN THIS CHAPTER

Configure a vSRX Chassis Cluster in Junos OS | 212

vSRX Cluster Staging and Provisioning in Hyper-V | 221

Configure a vSRX Chassis Cluster in Junos OS

IN THIS SECTION

Chassis Cluster Overview | 212

Enable Chassis Cluster Formation | 213

Chassis Cluster Quick Setup with J-Web | 214

Manually Configure a Chassis Cluster with J-Web | 215

Chassis Cluster Overview

Prerequisites

Ensure that your vSRX instances comply with the following prerequisites before you enable chassis clustering:

• Use show version in Junos OS to ensure that both vSRX instances have the same software version.

• Use show system license in Junos OS to ensure that both vSRX instances have the same licenses installed.

Chassis cluster groups a pair of the same kind of vSRX instances into a cluster to provide network node redundancy. The devices must be running the same Junos OS release. You connect the control virtual interfaces on the respective nodes to form a control plane that synchronizes the configuration and Junos

OS kernel state. The control link (a virtual network or vSwitch) facilitates the redundancy of interfaces

212

and services. Similarly, you connect the data plane on the respective nodes over the fabric virtual interfaces to form a unified data plane. The fabric link (a virtual network or vSwitch) allows for the management of cross-node flow processing and for the management of session redundancy.

NOTE: If you configure a chassis cluster on vSRX nodes across two physical hosts, disable igmpsnooping on the bridge that each host physical interface belongs to that the control vNICs use.

This ensures that the control link heartbeat is received by both nodes in the chassis cluster.

In active/active mode, traffic can enter the cluster on one node and exit from the other node.

Chassis cluster functionality includes:

• Resilient system architecture, with a single active control plane for the entire cluster and multiple

Packet Forwarding Engines. This architecture presents a single device view of the cluster.

• Synchronization of configuration and dynamic runtime states between nodes within a cluster.

• Monitoring of physical interfaces, and failover if the failure parameters cross a configured threshold.

Unit (SPU) monitoring, failures, and manual failovers, can trigger a state transition.

Enable Chassis Cluster Formation

With the exception of unique node settings and management IP addresses, nodes in a cluster share the same configuration.

You can deploy up to 255 chassis clusters in a Layer 2 domain. Clusters and nodes are identified in the following ways:

213