Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Validation Framework

Test Objectives

The test objective is to validate the Scale-Out architecture, showing the various topologies with single or dual MX Series Router and multiple SRX Series Firewalls, and demonstrating its ability to respond to various use cases while being able to scale.

The different features offered by routing, and the two main load balancing methods, using different platform sizes for MX Series Router and/or SRX Series Firewalls, using high availability of the various components, offer a wide range of possibilities. This document focuses on the four main topologies, which covers different use cases proposed in this document.

The configuration examples (shown later) illustrate the important parts in the configuration to achieve these results. A complete configuration can be delivered on demand.

Test Bed Topology

The network design follows the examples described with four topologies. As explained in the configuration example later, some key elements need to be put in place, like the network IP scheme to make it simple to understand and the BGP peering between the MX Series Router, the external Gateway (if any), and with each SRX Series Firewalls.

To test this architecture, you need an MX Series Router as the base system, and several physical SRX or vSRX Series Firewalls on a hypervisor system. These can use scripts to launch and onboard the physical and virtual SRX firewalls and copy configurations from the configuration examples given below.

One MX Series Router is the minimum for testing Load Balancing, as well as Standalone SRXs in the distributed sessions.

Two MX Series Router are needed to provide routing redundancy, and some SRX Series Firewalls (of same model) in MNHA pairs allow to test the sessions synchronization and traffic resiliency.

Figure 1 shows a test bed for single MX Series Router and ECMP CHASH and an example of IP addressing used during testing. Note the aggregate interfaces used (ae) indicating a dual attachment of each SRX Series Firewall to the MX Series Router platforms. A gateway router is used to bring the traffic to/from the clients and Internet.

Figure 1: Test bed – ECMP CHASH - Single MX Series Router, Standalone SRXs Test bed – ECMP CHASH - Single MX Series Router, Standalone SRXs

Figure 2 shows a test bed for Dual MX Series Routers and ECMP CHASH. Here you can observe also the dual links used between each SRX Series Firewall and the MX Series Router. In addition, you can see the virtual link for SRX’s sessions synchronization crossing the aggregate interfaces on a specific VLAN. This prevents us from using an additional connection between the SRX Series Firewall themselves (they could be in a remote location).

Figure 2: Test Bed – ECMP CHASH - Dual MX Series Routers, SRX MNHA Pairs A diagram of a computer system Description automatically generated

Supported Platforms

Table 1: Supported Platforms
Name Convention Supported Platforms OS
Forwarding node MX304 Junos OS Release 23.4R2
Service Node SRX4600 Junos OS Release 23.4R2
Service Node vSRX Junos OS Release 23.4R2 running on VMWARE ESXi

Tested Optics

The Fiber optic transceivers used in that test bed are:

  • QSFP-100GBASE-SR4: between MX304 and SRX4600s
  • QSFP28-100G-AOC-3M: between MX304 and servers hosting vSRXs

This JVD has been validated with the fiber optics reference above. However, the technical validation is larger regarding hardware compatible optics. For more information, see the following references on Juniper’s Hardware Compatibility Tool.

Test Bed Configuration

Test goals ensure that the Scale-Out environment matches all the required use cases that are exposed (with the four topologies for the various use cases).

Each test reiterates the same test cases among the four topologies by looking at less disturbance in traffic flows (keeping steady traffic) when actions or events happen. The general expectation is to have no or little effect on the traffic.

  • Adding a new SRX Series Firewall to the service layer redistributes the traffic to get an even distribution, no traffic disruption is expected for other traffic.
  • Removing a SRX Series Firewall from the service layer redistributes traffic only for those associated with this removed SRX Series Firewall.
  • Having an SRX Series Firewall failover to its peer (MNHA case) and return to normal state does not cause any traffic disruption. It also preserves firewall sessions.
  • Having an MX Series Router failover (dual MX) does not cause any traffic disruption.
  • Varying themes and failure scenarios cause no traffic disruption.

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 Routers and SRX Series Firewalls in various conditions. It shows consistency of the traffic distribution and its possibility to scale when adding new service nodes.

Test Goals

Performance or scaling is tested with an idea of showing linearity in the process of SRX Series Firewall addition (standalone or MNHA pair) to the Scale-Out solution. Initial test is done with a single SRX Series Firewall pair to a maximum combination of traffic.

A second SRX Series Firewall pair is added to the first SRX series firewall pair to show that it is adding the same capacity as the first SRX firewall pair.

In this case, linearity is obvious when adding more SRX Series Firewalls pairs as the MX Series Router is agnostic to the number of sessions. While the amount of traffic stays within MX-PE throughput limits for every new MNHA pair, this adds a similar amount of performance to the scale-out complex.

Test Non-Goals

Performance or scaling is not designed to test the maximum capacity of each SRX Series Firewall or of the full solution.

If there is a requirement to go to maximum capacity, then one could calculate it with an example. You can add any number of SRX Series Firewalls until the capacity of the router is reached (for example 3.2Tbps of MX Series Router forwarding capacity with redundant REs or 4.8Tbps with single RE switch is pretty high) or its maximum port capacity (for example, MX Series Router with 16 x 100GE links per line card, up to two cards with redundant REs or three line cards with single REs).

On the SRX Series Firewalls, maximum throughput depends on the traffic type as it is analyzing content - the more content the more work it needs. For example, 200Gbps requires MX304 with two-line cards at 3.2Tbps / 200Gbps = 16 SRX, or 3-line cards at 4.8Tbps or 200Gbps = 24 SRX. Consider the second MX Series Router and other SRX Series Firewalls, a second member of the pairs as a backup to be able to handle full load in case of large failure.

If only considering the number of available ports (without a distribution layer like QFX), this requires a MX304 with two-line cards at 3.2Tbps / 2 cards / 16 ports = 66 SRX ports, or three-line cards at 4.8Tbps / 2 cards / 16 ports = 100 SRX ports. All these are within theorical limits.

There is no preferred specification for the hypervisor hosting the vSRX, nor specific vSRX sizes (in vCPU/vRAM/vNIC quantity), simple vSRX is just enough for testing the 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.

No automation is mentioned in the document. However, it is indeed used to help build and test the solution with various use cases and tests. Automation is considered as a later addition to this JVD.