Use Case and Reference Architecture

Solution Functional Elements

This JVD is part of a series of JVDs using the same scale-out principle. However, that is detailed for each use case, each one having some particularities applying to your use cases. The following use cases are described with a common part and specific parts.

This JVD document covers enterprise use case for IPsec Security Gateway.

Juniper Scale-Out Security Services Solution architecture includes two main functional blocks:

• The security services device is formed by standalone vSRX virtual network functions or SRX4600 Firewall or a redundant pair of the same device. This section covers a standalone case, former section covers details on redundant solution architectures.
• The MX Series Routers as load balancer routers provide 100G or 400G interfaces to the vSRX servers or the SRX4600s forming the services complexes. Both access side and Internet side peering are enabled through MX Series Router dedicated ports are used for high throughput.

Figure 1: Scale Out Solution Functional Blocks

With the new Trio 6 MX10004 and 10008 systems, capacity per slot is up to 9.6 Tbps and with compact MX304 systems, capacity per system is up to 4.8 Tbps, enabling a high number of 100G ports. An MX304 router can provide up to 48 x 100G interfaces and an LC9600 line card in a modular MX10000 system, up to 96 x 100G ports.

To optimize port usage, it is recommended to implement an intermediate distribution layer with two (or more) QFX Series switches to aggregate multiple SRX (and vSRX Series on compute servers) Series Firewalls nodes into a bundled 400GE links on the MX Series Router. In such case, the aggregate links terminate from the MX Series Routers onto the distribution layer rather than on physical SRX Series Firewalls (or the computes for vSRX).

SRX4600 offers a 400Gbps throughput capacity of up to 4 x 100GE interfaces in a 1RU appliance, perfectly fitting the use case interconnection with the MX Series Router.

If vSRX is the choice for the security element, it rolls out on top of the KVM or VMware virtual network function, running on open compute servers. You can bring your own server based on prescribed server specifications (CPU cores, memory, Linux OS, KVM versions). For more information about server specifications, see the vSRX server specifications in the references.

vSRX is a Virtual Network Function (VNF) running on KVM or VMware hypervisors, with a flexible compute allocation of cores (up to 32) and memory (up to 64G). vSRX can use virtio or SR-IOV (Single Root I/O Virtualization) with smart NICs such as Mellanox ConnectX 6. On the available platforms, hardware acceleration can be leveraged for IKE and IPsec encryption (such as AES-NI for DH and RSA algorithms).

An external BGP (eBGP) protocol with BFD provides a routing and control function between network elements while you can implement load-balancing using following two approaches:

• Equal-cost multipath (ECMP) load-balancing function with Consistent Hashing (CHASH)
• RE based traffic load balancer function (TLB) on MX Series Routers

Two routing instances – Internet and Internal – are used on MX Series Router to peer with corresponding network segments of the enterprise or data center network infrastructure and the security node. eBGP enables scalable and flexible exchange of routing information for the Internet side routing and the internal networks. The failure detection is based on BFD with timers as low as 100ms, enabling fast reconvergence and fast automatic adjustment for the ECMP load balancing.

The IPsec services on the Internet are load balanced between services nodes dynamically based on ECMP CHASH with source IPv4 or IPv6 addresses. The IKE and IPsec termination point (the common IPsec gateway) needs to be distributed through eBGP to the external peers. For the decrypted traffic coming out of the IPsec tunnels on the Internal side, an eBGP routing and BFD failure detection is required. Source based IPv4 or IPv6 ECMP CHASH is used on the Internet side with the IPsec services.

Essentially ECMP CHASH limits the impact on existing traffic flows in the event of service-node failure or addition of new service node to the scale-out architecture. In case of a service-node failure event, only the impacted flows are rehashed and rebalanced to other nodes; while in case of a service-node addition, an equal number or flows from each node in the cluster are rehashed and rebalanced to the new member in the cluster, limiting the impact while maintaining the equal-cost load balancing.

This architecture effectively scales the service complex with tens of service nodes (SRX/vSRX), with efficient load-balancing of flows between service nodes, and minimizing the effect (blast radius) due to a single node failure. The eBGP routing on the MX Series Router scales beyond Internet tables to millions of routes if required and easily beyond.

Solution Deployment Scenarios

Following the Scale-Out Security Services solution architecture, you can consider a few deployment scenarios where the MX Series Routers and SRX Series Firewalls are connected in either standalone or redundant pairs (see topologies). It uses network redundancy mechanisms to provide flow resiliency between the MX Series Router Forwarding Layer and SRX Series Router Service’s. Also, the BFD protocol is used to achieve a quicker failover mechanism on routing when any other failure occurs. If SRX’s MNHA provides session synchronization (stateful sessions and IPsec security associations) between two nodes, then the existing traffic and tunnels can continue uninterrupted.

Figure 2 shows the three main topologies covered in the JVD, combining standalone/dual MX Series Router with standalone/MNHA for SRX Series Firewalls, each on a particular load balancing mechanism (ECMP or TLB). It uses three SRX Series Firewalls for the first topology and doubles them to three pairs for the other topologies.

Figure 2: Validated Topologies

There are numerous trade-offs with each of the architectural choices. In general, complexity increases as more redundancies are added. For example, SRX MNHA Pairs introduce some requirements like a network link for high availability communications. Based on dependencies, load balancing method is used on the MX Series Router (namely ECMP CHASH or TLB). This selection of topologies covers the most important considerations from simple to more redundancy scenarios.

• ECMP CHASH is simpler to use, leverages standard protocols and well know ECMP mechanism, which might be a preferable option for some enterprise network operations department, though this method is somewhat limited when it comes to failover capabilities.
• TLB is the latest load balancing capability (at the time of publishing this JVD), which leverages services to load balancing, offers better redundancy capabilities and multiplies with different local groups. It is useful when there is a need to combine different use cases with the same architecture. Though this method might not be backward compatible with older Junos OS releases.

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 (standalone or high availability)
• Load balancing using ECMP CHASH (first appeared in Junos OS Release 13.3R3)
• Load balancing using Traffic Load Balancer (TLB) on the MX Series Router (first appeared in Junos OS Release 16.1R6)
• MX Series Routers redundancy between two MX Series Routers with TLB
• MX Series Routers redundancy using Dynamic Routing between two MX Series Routers with TLB
• SRX Series Firewalls redundancy using MNHA as Active/Backup with sessions synchronization
• Dual stack solution with IPv4 and IPv6 (for outer IPsec and for inner tunnelled traffic)
• IPsec (auto VPN with responder only mode). AES-256-GCM is used for IPsec Encryption
• Stateful firewall (SFW) is inherently used for traffic inside the IPsec tunnels with simple long protocol sessions (HTTP, UDP)

Each JVD is tested with the following platforms:

• Routing and Load Balancer: MX304 with Junos OS Release 23.4R2
• Security Services: vSRX and SRX4600 with Junos OS Release 23.4R2

Deployment Scenario 1 – ECMP CHASH – Single MX Series Router with Scaled Out Multiple Standalone SRX Series Firewalls

This topology is the simplest, however, the least redundant. The resiliency is provided at MX Series Router hardware – redundant RE, PSU, and so on. There is no protection against MX Series Router failure. Deployment allows protection against service node failure by redistributing traffic flows between two remaining security-nodes. Though there is no session synchronization between the SRXs which leads to longer restoration time for the affected flows (IPsec sessions need to reestablish).

Figure 3: Deployment Scenario 1 – ECMP CHASH - Single MX, Multiple Standalone SRX Firewalls

Network operators that are not concerned about stateful failover can augment security service capacities by adding more SRX Series Firewalls in this simple manner as application sessions are short lived anyway (a redundancy mechanism is handled at the application level, so session sync between two different firewalls is not required).

• Pros: Simplicity and scaling with each individual SRX Series Firewalls
• Cons: No redundancy

Deployment Scenario 2 – TLB – Single MX Series Router with multiple SRX MNHA pairs

This topology offers redundancy for the SRX Series Firewalls and not for the MX Series Router. This topology has a second Routing Engine (RE) installed in the appropriate slot; however, this does not use two MX Series Routers in that case. All SRX Series Firewalls are in MNHA pairs to offer sessions synchronization and failover capabilities.

Figure 4: Topology 3 – TLB - Single MX, Multiple SRX MNHA Pairs

• Pros: Redundancy and scaling with each SRX Series Firewalls pair
• Cons: No redundancy on the router (except using dual RE)

Deployment Scenario 3 – TLB – Dual MX Series Router with Multiple SRX MNHA Pairs

This last topology offers the most redundancy both for MX Series Routers and SRX Series Firewalls and takes advantage of having all components used at the same time. Any failover scenario can be covered using BGP routes announced and BFD accelerating the error detection.

Figure 5: Topology 4 – TLB – Dual MX, Multiple SRX MNHA Pairs

MX Series Router can handle traffic on any of the two routers, while SRX Series Firewalls are used either in Active/Backup role or in Active/Active role, making use of both nodes at the same time. This augments the capacity of the network during normal operation. However, this leaves one node active at a time when a failure occurs (considering a single MNHA cluster).

Each SRX Series Firewall is connected to both MX Series Routers. If any of one node fails within a cluster, all other SRX Series Firewalls pairs might have an independent failover from the other SRX Series Firewalls pairs and the MX Series Router.

• Pros: Full redundancy and scaling for MX Series Router and SRX Series Firewalls pairs.
• Cons: More interfaces used on the MX Series Router if directly connected. Then, an optional distribution layer can cover more connectivity needs when SRX Series Firewall count augments.