Results Summary and Analysis

Performance and Scale

This JVD demonstrates the validation of scale-out property of the complex and ability to demonstrate linear performance and scale growth by adding new service elements to the complex. Initial test is done with a single SRX Series Firewalls pair to a typical traffic within IPsec (40Gbps) as a baseline, a second SRX Series Firewalls pair is added to the 1st one to validate the addition of the same capacity that the first pair is handling.

In this case, the performance and scaling 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 Series Router throughput limits, every new SRX MNHA pair adds a similar amount of performance to the scale-out complex.

IPsec performance of a single SRX Series Firewalls is leveraging some form of hardware acceleration depending on the platform. This helps to establish each individual IPsec session in a more effective way (typically with Diffie Hellmann algorithms) and the performance of the encrypted traffic using hardware acceleration (For example, AES-GCM done in ASIC for the SRX4600 platforms, and QAT leveraged for vSRX running on Intel platform).

However, when it needs to scale in large number of tunnels, every SRX Series Firewalls platform has a limit (set either by memory, positioning and physical capacity), and the Scale-Out architecture helps in augmenting that capacity to new maximums. It does not depend anymore on the single SRX Series Firewalls capacities and performances, however on the whole architecture to load balance seamlessly a larger number of SRX Series Firewalls for the same IPsec service.

If you want to understand how to reach a maximum performance/capacity, you can calculate it with an example. Add any number of SRX Series Firewalls until the capacity of the router is reached (for example a MX304 can handle 3.2Tbps of forwarding capacity with redundant REs or 4.8Tbps without redundant REs, which is high) or its maximum port capacity (for example 16 x 100GE links per line card, up to 2 cards with redundant REs, then 32 x 100GE ports, or 3 line cards without redundant Res, then 48 x 100GE ports).

On the SRX Series Firewalls side, scaling depends on the quantity traffic and its ability to encrypt/decrypt using IPsec. Taking the tested 100Gbps then reaches a MX304 with two line cards at 3.2Tbps / 100Gbps = 32 SRX, or three line cards at 4.8Tbps / 100Gbps = 48 SRX. Consider the second MX Series Router and other SRX Series Firewalls, second members of each pair as backup to be able to handle a full load in case of large failure.

If only counting the number of available ports (without a distribution layer like QFX), this provides MX304 with two line cards (and 2 RE) * 16 ports = 32 ports, or three line cards (and 1 RE) * 16 ports = 48 ports. This stays within theorical limits as it does not consider using an aggregate interface (2 ports) per SRX Series Firewalls, which divides those numbers by 2.

Load Balancing

ECMP CHASH has shown steady restoration time in milliseconds.

With TLB mainly used on the MX Series Router platform, you can show that it also works with non-tested MX Series Routers here, where TLB uses a Control function on the RE (like MX304) or on a service card (MS-MPC for MX240 for example). TLB has been in Junos OS since Junos OS Release 18.1R1 when BGP acquired multipath function. This connection with BGP results in Service Providers often using it internally and externally.

TLB scenario is working with restoration timers and shows flexibility in deployment options (aka single or dual MX Series Router is used) as well as a better handling of SRX Series Firewalls in MNHA pairs.

Security Services

SRX Series Firewalls features leveraged in this JVD focus on IPsec security gateway use case however, it does not get into higher layer security features for tunneled packets. The fact that Scale-Out architecture can handle standalone and SRX Series Firewalls clusters, using an even distribution among multiple SRX Series Firewalls, without disturbing traffic, shows that the SRX Series Firewalls layer 7 security service can easily be added to this usage for the decrypted traffics.

Note:

With ECMP, all SRX Series Firewalls need to be of the same model whereas, with TLB, this can leverage the notion of TLB groups to have groups of usage (for example, some SRX Series Firewalls in a SFW group and other SRX Series Firewalls in a CGNAT group). The number of groups is around 2,000 per MX Series Router and the number of SRX Series Firewalls member is around 256.

Scale-Out vs Chassis

The Scale-Out solution is considered as an alternative to the monolithic Scale-Up approach with the chassis based SRX Series Firewalls or security services on MX960/480 with MX-SPC3 service cards, however nothing prevents such architectures from being used to benefit both to leverage the possibility to add new services and the power of those existing platforms. The upcoming small platforms like MX304 and SRX4700 helps to create smaller footprint architectures.

Routing

Junos OS integration with BGP peering between the MX Series Router and the SRX Series Firewalls, including the right BFD timers, allows you to create a perfectly matching environment with all Juniper solutions working seamlessly together. More distributed BFD mechanisms allow to better scale when the number of SRX Series Firewalls to monitor augments, which also take an important part in the speed to react to any network or physical issue.

The redundancy of each router and security solution allows you to maintain steady IPsec traffic while providing addition of new capacities in a simple way. Similar configuration statements of MX Series Routers and SRX Series Firewalls security devices allows a simple and seamless management of this solution.

Management and Automation

On the management front, configuration automation is not covered, however it is indeed used to help build and test the solution with the various use cases and tests. Basically, scripting is used with Junos OS access using Netconf. Lots of scripting already exists in the field (or Juniper automation places such as GitHub) using Ansible, Terraform, Python, and PyEZ (Python Easy for Junos OS). Some advanced users have already scripted their Junos OS, mostly in the Service Provider space, where APIs are important to integrate with their own management framework.

Security Director (on-prem or cloud) has an important place for delivering common configurations to the security service layer (like security policies, address objects, and IKE/IPsec policies), and for providing visibility on the security events and logs generated by each SRX Series Firewalls.

When the Connected Security Distributed Services (CSDS) architecture is released, which is based on the same Scale-Out principles, it uses a common management framework that helps to configure and manage this whole architecture from a single pane of glass. Whether CLI based (through Juniper Network Unifier – JNU – and through the Juniper Device Manager – JDM – to manage vSRX on compute platforms), or through web-based management with Security Director (Cloud or on-prem), this framework helps enterprises and service providers to provision their Scale-Out architecture in a simple way.