Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Results Summary and Analysis

All the test results are summarized in different documents detailing all aspects of the testing. This JVD shows that scale-out can leverage the use of important functions both on the MX Series Routers and SRX Series Firewalls for their respective target usage:

  • The MX Series Router is used as a load balancer with different options, ECMP CHASH and TLB.
  • The SRX Series Firewalls are used as an IPsec security service with simple integration with the MX Series Router.
  • Both physical SRX Series Firewalls and virtual SRX Series Firewalls are used the same way.
  • Simple network integration using BGP and BFD helps in fast convergence time.
  • Though no scale is tested, the simplicity of adding a new service node shows that this architecture can help to scale in many directions (performances, scaling, and so on) by simply adding new service node without disturbing the global service.

ECMP CHASH shows steady restoration (time in milliseconds.)

Note:

With ECMP, all the SRX Series Firewalls need to be of the same model, whereas with TLB, it is not mandatory to have same devices, for example some SRX Series Firewalls in an IPsec group and other vSRX Series Firewalls in different IPsec groups. The number of groups is around 2,000 per MX Series Router and the number of SRX Series Firewalls members are around 256.

With TLB being used mainly on MX Series Router platforms, it also works with non-tested MX Series Router models, where TLB uses a control function on the RE (like MX304) or on a service card (for example, MS-MPC for MX240). TLB has been in Junos OS since Junos OS Release 18.1R1 when BGP acquired multipath function. This connection with BGP offers a good solution for service providers who often use it internally and externally.

TLB use case works with fast restoration timers and shows more flexibility in deployment options (aka single or dual MX Series Routers), as well as a better handling of SRX Series Firewalls in the MNHA cluster.

SRX Series Firewalls features leveraged in this JVD focus on IPsec security gateway, leveraging easy central gateway with standard security protocols like AES-GCM (Advanced Encryption Standard in Galois Counter Mode using 128 bits or 256 bits key length). However, any other encryption mode can also be used. AES-GCM became the preferred de facto standard for the security industry. One can add any method to it from IKEv1 and IKEv2, using Pre shared Keys or PKI (digital certificates). A SRX Series Firewall, and moreover multiple scale-out SRX Series Firewalls are used to terminate multiple tunnels with various methods at the same time with many other remote sites or remote users.

SRX Series Firewalls are used as a terminating, and not initiating, all the IPsec VPN from remote entities as it listens and wait for remote entities -- that all have the ability to contact the gateway (like from an initial DNS request) – to start the IKE negotiation to negotiate an IPsec VPN. This applies to all the SRX Series Firewalls in that group listening on the same configuration that needs a very simple and single IKE/IPsec entry in its configuration. The opposite is complex to contact from those SRX Series Firewalls to many remote sites, as it requires a specific configuration for each remote entity (configuration multiplied by the number of remote sites) and more complex to tell to a single SRX Series Firewall to start the IKE/IPsec negotiation outbound (and not all of them); these firewalls cannot share the same IKE/IPsec configuration, then removing the interest of scaling out.

Note:

SRX Series Firewalls are always performing a stateful firewall in addition to IPsec for both its IPsec headers. However, for the tunneled traffic that is encrypted/decrypted, it uses same Layer 4 to Layer 7 protocol and application firewall, if this is set to be checked in the security policies configuration. This document is at the IKE/IPsec configuration level. However, it does not mention some security policies for the received (and decrypted) traffic coming through IPsec from the remote sites.

The scale-out solution is considered as an alternative to the monolithic scale-up approach. It uses the chassis based SRX Series Firewalls or security services on MX240/480/960 with MX-SPC3 service cards independently. However, nothing prevents such architectures from benefitting from both leverage possibilities to add new services and the power of those existing platforms. The existing smaller platforms like the MX304 and SRX4600 help to create smaller footprint architectures.

On the management front, automation is used to build and test the solution with the various use cases and tests. In summary, scripting is used with Junos OS access using Netconf. Lots of scripting already exists in the field (or Juniper automation places like GitHub) using Ansible, Terraform, Python, PyEZ (Python Easy for Junos OS), etc. Some advanced users have scripted Junos OS, and API that are available to integrate with the existing management framework.

The Security Director (on-prem or cloud) has an important place for delivering common configuration to the security service layer (like security policies, address objects, NAT pools, etc.). This gives visibility to the security events and logs generated by each SRX Series Firewalls.

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 matching environment with Juniper solutions working seamlessly together. The redundancy of each router and security solution allows you to maintain steady traffic while providing addition of new capacities in a simple way. Similar configuration statements on both routers (MX Series Router) and security (SRX Series Firewalls) provide a simple and seamless management of this solution.