This section contains the known behaviors, system maximums, and limitations in hardware and software in Junos OS Release 19.1R3 for vSRX.
Flow-Based and Packet-Bases Processing
By default, virtual function’s have no privileges to perform certain operations such as enabling multicast promiscuous mode and modifying the virtual function’s MAC address in the guest. These security measures are designed to prevent possible attacks. Virtual function trusted mode allows virtual function’s to become "trusted" by the physical function and perform some privileged operations, such as enabling virtual function promiscuous mode and changing the virtual function’s MAC address within the guest. The inability to modify MAC addresses in the guest prevents the users from easily setting up two virtual function’s in a failover bond in a guest. Without enabling virtual function trusted mode, the chassis cluster fabric link probes are not received when SR-IOV virtual function interfaces are used as chassis cluster fabric link members and SR-IOV interfaces used as redundant Ethernet (reth) interface members do not work either. Use the ip link set <pf-interface> vf <vf-index> trust on command to enable virtual function trusted mode (for certain Linux distributions, including Ubuntu 14.04.5 LTS and 16.04.5 LTS, the IP utility needs to be upgraded to support trust on or off options). PR1400940
A session sync issue occurs if OVS bound ports are used as fabric links. PR1400069
For J-Flow V9, only one collector can work under the families inet and inet6 even though Routing Engine CLI can be configured for four collectors under family inet. PR1396482
Interfaces and Routing
You must manually change the macro definition in file i40e.h and compile i40e driver on
HOST. #define I40E_DEFAULT_QUEUES_PER_VF 16. Otherwise, vSRX 3.0 might have 4 Packet Forwarding Engine cores instead of 8 or 16. Driver Building and Installation guide is in the driver's tarball at: https://downloadcenter.intel.com/download/28306/Intel-Network-Adapter-Drive r-for-PCIe-40-Gigabit-Ethernet-Network-Connections-Under-Linux-. PR1399599
Platform and Infrastructure
When the traffic flow is high (throughput of 2 Gbps or more), reboot of vSRX 3.0 running with Hyper-V on Windows Server 2016 is not recommended. vSRX 3.0 VM might hang during boot process. We recommend that you schedule a reboot or an upgrade when there is no traffic. As a workaround, to recover the vSRX 3.0 VM, restart the instance again when the traffic stops. PR1394792
vSRX 3.0 has a disk shortage issue when the server has less than 10 percent free disk space. The I/O rate is slow when the Hyper-V server disk runs out of storage. This causes vSRX 3.0 to stop, because it treats the disk as unreadable. To avoid this issue, we suggest that you leave more than 10 percent of disk space free on the Hyper-V server. PR1405808
With vSRX using SR-IOV in a chassis cluster, you cannot configure both the redundant (reth) child interfaces of the same reth interface from both vSRX nodes on Virtual Functions (VF) which belong to a single Physical Function (PF). This causes the both VFs to have the same reth MAC address, which is not supported on a single PF and causes traffic to be dropped. PR1422156
vSRX Limitations in Junos Space Security Director Integration with vSRX
The following vSRX features are not supported in Security Director:
Application QoS (AppQoS)
Layer 2 transparent mode
Specific Security Director limitations with respect to Application Firewall (AppFW), IDP, and UTM features:
UTM database updates are not supported.
Application ID (AppID) custom signatures are not supported.
The following vSRX features are not supported in Junos Space Security Director for IPsec and routing features:
Certificates for AutoVPN must be generated from the CLI.
All other IPsec settings can be configured using Junos Space Security Director.