Test Objectives
JVD is a cross-functional collaboration between Juniper solution architects and test teams to develop coherent multidimensional solutions for domain-specific use cases. The JVD team comprises technical leaders in the industry with a wealth of experience supporting your complex use cases. The scenarios selected for validation are based on industry standards to solve critical business needs with practical network and solution designs.
The key goals of the JVD initiative include:
- Validate overall solution integrity and resilience
- Support configuration and design guidance
- Deliver practical, validated, and deployable solutions
A reference architecture is selected after consultation with Juniper Networks global theaters and a deep analysis of your use cases. The design concepts that are deployed use best practices and leverage relevant technologies to deliver the solution. Key performance indicators (KPIs) are identified as part of an extensive test plan that focuses on functionality, performance integrity, and service delivery.
Once the physical infrastructure that is required to support the validation is built, the design is sanity-checked and optimized. Our test teams conduct a series of rigorous validations to prove solution viability, capturing, and recording results. Throughout the validation process, our engineers engage with software developers to quickly address any issues found.
Test Goals
The test objective is to validate the Scale-Out architecture, showing the various topologies with single/dual MX Series Routers and multiple SRX Series Firewalls, and demonstrate its ability to respond to various use cases while being able to scale. Different possibilities are offered to cover the routing with the two main load balancing methods, using different platform sizes for MX Series Routers and/or SRX Series Firewalls, in addition to using high availability of the various components.
Additional goals are to demonstrate Scale-Out capability of the solution, which allows linear performance and logical scale (stateful traffic flows) growth in the process of new SRX/vSRX Series Firewalls addition to the security services complex.
Use this JVD validate system behavior under the following administrative events, with a general expectation to have no or little effect on the traffic:
- Adding a new SRX Series Firewall to the service layer - a redistribution of traffic to get an even distribution, minor percentage of traffic disturbance [depends on the number of SRX Series Firewalls next-hops] is seen on all other SRX Series Firewall due to change in next-hops and then the hash.
- Removing a SRX Series Firewall from the service layer - traffic redistribution only for those associated with this removed SRX Series Firewall.
- Having a SRX Series Firewall failover to its peer (MNHA case) and return to normal state - no traffic disruption expected, sessions and IPsec Security Associations are preserved.
- Having an MX Series Router failover (dual MX Series Router) - no traffic disruption expected.
- Variation among these themes and failure scenarios - no traffic disruption expected.
The following networking features are deployed and validated in this JVD:
- Dynamic Routing using BGP
- Dynamic fault detection using BFD
- Load Balancing of sessions across multiple SRX Series Firewalls in standalone or high availability
- Load Balancing using ECMP CHASH, first appeared in Junos OS Release 13.3R3
- Load Balancing using Traffic Load Balancer on the MX Series Router first appeared in Junos OS Release 16.1R6
- MX Series Router redundancy using BGP Dynamic Routing between two MX Series Router with TLB
- SRX Series Firewalls redundancy using Multi-Node High Availability (MNHA) as Active/Backup with sessions and IPsec security associations synchronization
- Dual stack solution with IPv4 and IPv6 (for outer IPsec and for inner tunneled traffic)
- IKE/ IPsec tunnel negotiation using AES-GCM encryption protocols as responder mode (waiting for IPsec peers, SRX Series Firewalls IPsec configured with auto-vpn mode)
- Stateful firewall is implicitly used with simple long protocol sessions (HTTP, UDP) for traffic inside the IPsec tunnels
- Dead Peer Detection (DPD) helps in detecting unreachable IKE peers. It helps to maintain a link active while no traffic flows inside and detect end to end VPN reachability issues
Individual tests of failure, failover, upgrades, and downgrades are used to show how the architecture behaves and verify its ability to react to failures, including resiliency of MX Series Router and SRX Series Firewalls in various conditions. It also shows the consistency of the traffic distribution and its possibility to scale when adding new service nodes.
Fixed performance/scaling of traffic is tested across each platform with the idea of showing linearity in the process of SRX Series Firewalls addition (standalone or MNHA pair) to the Scale-Out solution.
Test Non-Goals
Maximum scale and performance of the individual network elements constitute the solution.
There are no preferred specifications for the hypervisor hosting the vSRX, nor specific vSRX sizes (in vCPU/vRAM/vNIC quantity). Simple vSRX is sufficient for testing the required features. Note that vSRX runs on many hypervisors including: ESXi, KVM, Microsoft for on-prem. Though vSRX can also be deployed in public clouds (AWS, Azure and GCP), the purpose of the architecture is not to run with vSRX in those external clouds where it is questionable to consider the networking plumbing to get them connected.
This JVD does not mention about automation. However, automation is used to build and test the solution with various use cases and tests.
Following features and functions are not included in the current JVD:
- Automated onboarding of the vSRX
- Security Director Cloud or on-prem
- Application and Advanced Security features (App ID, IDP, URL filtering and other Layer 7)
- IKE/IPsec tunnel negotiation using protocols other than AES-GCM or other initiator mode (to other peers)
- IKE using Public Key Infrastructure (PKI) is not used; however, it works the same
Event Testing
SRX Series Firewalls failure events:
- MX Series Router to SRX Series Firewalls link failures
- SRX Series Firewalls reboot
- SRX Series Firewalls power off
- Complete MNHA pair power off
- IKE/IPsec failures
MX Series Router failure events:
- Reboot MX Series Router
- Restart routing process
- Restart traffic-dird deamon
- Restart Network-monitor deamon
- Restart sdk-process
- GRES (Graceful REStart of routing daemon)
- ECMP/TLB next-hop addition/deletion (adding/deleting new scale out SRX MNHA pair)
- SRD based cli switchover between MX Series Router (ECMP)
Traffic recovery is validated post all failure scenarios.
UDP traffic generated using IXnetwork for all the failure related test cases is used to measure the failover convergence time.
Tested Traffic Profiles
Tested traffic profiles are composed of multiple simultaneous flows showing the same for either a standalone SRX Series Firewalls or a SRX MNHA pair in Active/Backup mode.
| Tunnel Count/ MNHA-Pair | Packet Size | Traffic Type | Throughput | Platform |
|---|---|---|---|---|
| 1000 | SECGW-IMIX | UDP | 40Gbps | SRX4600 |
| 1000 | SECGW-IMIX | UDP | 40Gbps | vSRX, CPU/vSRX :90% |
These performances are not at the maximum capability for each platform however, it is a steady performance representative to test among multiple SRX4600/vSRX in similar conditions.
Packet size is using the Internet mix with average packet size of ~700bytes. The “Packet Size: Weight” distribution is as follows:
- 64: 8
- 127:36
- 255:11
- 511:4
- 1024:2
- 1518:39
Lab used end to end 9000 for MTU to prevent fragmentation.
Test Bed Configuration
Contact your Juniper representative to obtain a full archive of the test bed configuration used for this JVD.