Requirements for vSRX Virtual Firewall on VMware
Software Specifications
The table below lists the system software requirement specifications when deploying vSRX Virtual Firewall on VMware. The table outlines the Junos OS release in which a particular software specification for deploying vSRX Virtual Firewall on VMware was introduced. You must need to download a specific Junos OS release to take advantage of certain features.
Features | Specification | Junos OS Release Introduced |
---|---|---|
vCPUs/Memory |
2 vCPUs / 4 GB RAM |
Junos OS Release 15.1X49-D15 and Junos OS Release 17.3R1 (vSRX Virtual Firewall) |
5 vCPUs / 8 GB RAM |
Junos OS Release 15.1X49-D70 and Junos OS Release 17.3R1 (vSRX Virtual Firewall) |
|
9 vCPUs / 16 GB RAM |
Junos OS Release 18.4R1 (vSRX Virtual Firewall) Junos OS Release 19.1R1 (vSRX Virtual Firewall 3.0) |
|
17 vCPUs / 32 GB RAM |
Junos OS Release 18.4R1 (vSRX Virtual Firewall) Junos OS Release 19.1R1 (vSRX Virtual Firewall 3.0) |
|
Flexible flow session capacity scaling by an additional vRAM |
NA |
Junos OS Release 19.1R1 (vSRX Virtual Firewall) Junos OS Release 19.2R1 (vSRX Virtual Firewall 3.0) |
Multicore scaling support (Software RSS) |
NA | Junos OS Release 19.3R1 (vSRX Virtual Firewall 3.0 only) |
Reserve additional vCPU cores for the Routing Engine (vSRX Virtual Firewall and vSRX Virtual Firewall 3.0) |
NA | |
Virtio (virtio-net, vhost-net) (vSRX Virtual Firewall and vSRX Virtual Firewall 3.0) |
NA | |
Supported Hypervisors | ||
Hypervisor support |
VMware ESXi 5.1, 5.5, 6.0, and 6.5 (vSRX Virtual Firewall and vSRX Virtual Firewall 3.0) |
Junos OS Release 18.4R1 |
VMware ESXi 6.7 (vSRX Virtual Firewall 3.0 only) | Junos OS Release 19.3R1 | |
VMware ESXi 7.0 (vSRX Virtual Firewall 3.0 only) | Junos OS Release 20.1R2 | |
Other Features | ||
Cloud-init |
NA | |
Powermode IPSec (PMI) |
NA | |
Chassis cluster |
NA | |
GTP TEID based session distribution using Software RSS |
NA | Junos OS Release 19.3R1 onwards |
On-device antivirus scan engine (Avira) |
NA | Junos OS Release 19.4R1 onwards |
LLDP |
NA | Junos OS Release 21.1R1 onwards |
Junos Telemetry Interface |
NA | Junos OS Release 20.3R1 onwards |
System Requirements | ||
Hardware acceleration/enabled VMX CPU flag in the hypervisor (vSRX Virtual Firewall only) |
NA | |
Disk space |
16 GB (IDE or SCSI drives) (vSRX Virtual Firewall) |
Junos OS Release 15.1X49-D15 and Junos OS Release 17.3R1 |
18 GB (vSRX Virtual Firewall 3.0) |
vNICs | Junos OS Release Introduced |
---|---|
VMXNET3 SA and HA | |
SR-IOV SA and HA over Intel X710/XL710/XXV710 series (vSRX Virtual Firewall 3.0) |
Junos OS Release 20.4R2 onwards |
SR-IOV HA on I40E ( X710,X740,X722 and so on) (vSRX Virtual Firewall 3.0) | Not supported |
SR-IOV SA and HA over Intel E810 series (vSRX Virtual Firewall 3.0) | Junos release 21.2R1 onwards |
SR-IOV SA and HA over Mellanox ConnectX-3 | Not supported |
SR-IOV SA and HA over Mellanox ConnectX-4/5/6 (MLX5 driver only) |
(SA from Junos OS Release 21.2R1 onwards) (HA from Junos OS Release 21.2R2 onwards) |
PCI passthrough over Intel 82599/X520 series | Not supported |
PCI passthrough over Intel X710/XL710 series | Not supported on vSRX Virtual Firewall 3.0 |
DPDK version has been upgraded from 17.02 to 17.11.2 to support the Mellanox Family Adapters. |
Junos OS Release 18.4R1 |
Data Plane Development Kit (DPDK) version 18.11 DPDK version 18.11 is supported on vSRX Virtual Firewall. With this feature the Mellanox Connect Network Interface Card (NIC) on vSRX Virtual Firewall now supports OSPF Multicast and VLANs. |
Junos OS Release 19.4R1 |
Best Practices for Improving vSRX Virtual Firewall Performance
Review the following practices to improve vSRX Virtual Firewall 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 Virtual Firewall, we recommend that all vCPUs for the vSRX Virtual Firewall VM are in the same physical non-uniform memory access (NUMA) node for optimal performance.
The Packet Forwarding Engine (PFE) on the vSRX Virtual Firewall 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 Virtual Firewall requires that you ensure that all vCPUs reside on the same NUMA node.
We recommend that you bind the vSRX Virtual Firewall instance with a specific NUMA node by setting NUMA node affinity. NUMA node affinity constrains the vSRX Virtual Firewall VM resource scheduling to only the specified NUMA node.
PCI NIC-to-VM Mapping
If the node on which vSRX Virtual Firewall is running is different from the node to which the
Intel PCI NIC is connected, then packets will have to traverse an additional hop
in the QPI link, and this will reduce overall throughput. Use the
esxtop
command to view information about relative physical
NIC locations. On some servers where this information is not available, refer to
the hardware documentation for the slot-to-NUMA node topology.
Interface Mapping for vSRX Virtual Firewall on VMware
Each network adapter defined for a vSRX Virtual Firewall is mapped to a specific interface, depending on whether the vSRX Virtual Firewall instance is a standalone VM or one of a cluster pair for high availability. The interface names and mappings in vSRX Virtual Firewall are shown in Table 3 and Table 4.
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 3 shows the interface names and mappings for a standalone vSRX Virtual Firewall VM.
Network Adapter |
Interface Name in Junos OS |
---|---|
1 |
fxp0 |
2 |
ge-0/0/0 |
3 |
ge-0/0/1 |
4 |
ge-0/0/2 |
5 |
ge-0/0/3 |
6 |
ge-0/0/4 |
7 |
ge-0/0/5 |
8 |
ge-0/0/6 |
Table 4 shows the interface names and mappings for a pair of vSRX Virtual Firewall VMs in a cluster (node 0 and node 1).
Network Adapter |
Interface Name in Junos OS |
---|---|
1 |
fxp0 (node 0 and 1) |
2 |
em0 (node 0 and 1) |
3 |
ge-0/0/0 (node 0)ge-7/0/0 (node 1) |
4 |
ge-0/0/1 (node 0)ge-7/0/1 (node 1) |
5 |
ge-0/0/2 (node 0)ge-7/0/2 (node 1) |
6 |
ge-0/0/3 (node 0)ge-7/0/3 (node 1) |
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 Virtual Firewall Default Settings on VMware
vSRX Virtual Firewall 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.
With vSRX Virtual Firewall platforms, VMware uses the VMXNET 3 vNIC and requires promiscuous mode on the vSwitch for the management interface, fxp0.
Table 5 lists the factory default settings for the vSRX Virtual Firewall security policies.
Source Zone |
Destination Zone |
Policy Action |
---|---|---|
trust |
untrust |
permit |
trust |
trust |
permit |
untrust |
trust |
deny |