Use Case and Reference Architecture

Solution Functional Elements

• Juniper Scale-Out Security Services solution architecture includes two main functional blocks. The security services device formed by standalone vSRX virtual network functions or SRX4600 or a redundant pair of the same device. This section focuses on the standalone use case, former section shares details on the redundant solution architectures.
• The MX Series Routers as load balancer router provides 100G or 400G interfaces to the servers hosting vSRXs or the SRX4600s forming the complex of services. Both access side and Internet side peering (see Figure 1 ) are enabled through MX Series Router dedicated ports being used for high throughput.

With 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 the port usage, it is recommended to implement an intermediate distribution layer with two (or more) QFX-series switches to aggregate multiple SRX Series Firewalls nodes (and vSRX Series on compute servers) 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).

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

vSRX is a Virtual Network Function (VNF) running on KVM or VMware hypervisors, with a flexible compute server allocated by number of cores (up to 32) and memory (up to 64G). Networking wise vSRX can use virtio or SR-IOV with smart NICs like Mellanox ConnectX-6. Hardware acceleration in the form of available platforms can be leveraged for IKE and IPsec encryption (such as AES-NI for DH and RSA algorithms).

For this JVD, an external BGP (eBGP) protocol with BFD provides a routing and control function between network elements of the complex while implementing load balancing with two approaches:

• Equal-Cost Multipath (ECMP) load balancing function with Consistent Hashing (CHASH)
• RE based traffic load balancer (TLB) function on MX Series Router

Two routing instances – Access and Internet – are used on the MX Series Router to peer with corresponding network segments of the SP mobile network infrastructure and the security node. eBGP enables scalable and flexible exchange of routing information for the access and the Internet side routing (see Figure 2 ). The failure detection is based on BFD with timers as low as 100ms, enabling fast reconvergence and fast and automatic adjustment for the ECMP load balancing.

To maintain a higher level of security like Managed Security Gateway service - where injection of your routes into the security layer is not preferred - static routes with BFD protection are the preferred control and traffic distribution methods.

The Access side traffic is load balanced between services nodes dynamically based on ECMP with source IPv4 or IPv6 addresses CHASH. This is essentially load balancing the IPsec traffic flows toward the security gateway function on the mobile side, and for this, eBGP routing and BFD failure detection is required. On the Internet side, the IP address associated with the mobile device is known within the IPsec negotiation that provides this information through eBGP to the router outside, and then allowing the return traffic back to its respective mobile device through the correct IPsec tunnel.

ECMP with CHASH limits the impact of service node failure on existing traffic flows in the event of or addition of new service node to the complex. On service node failure, impacted events flows are rehashed and rebalanced, while on addition of new service nodes, limited equal number of flows from each member in cluster are rehashed and rebalanced as a new member in the cluster, limiting the impact while maintaining the equal cost load balancing.

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

Solution Deployment Scenarios

Following the suggested solution architecture, the deployment scenarios are considered where MX Series Router and SRX Series Firewalls are connected in either standalone or redundant pairs (see topologies). The architecture uses network redundancy mechanisms to provide flow resiliency between the MX Series Router forwarding layer and SRX Series Firewalls services layer (MNHA, aka L3 cluster, is explained later in the document). For dual MX Series Router with ECMP, this scenario is not retained in favor of TLB handling a better solution using SRX High Availability (MNHA). Also, the BFD protocol is used to achieve a quicker failover mechanism on routing when any other failure occurs. If SRX Series Firewalls MNHA provides session synchronization (stateful sessions and IPsec security associations) between two nodes, then the existing traffic and tunnels can continue to operate uninterrupted.

The following diagram shows four main topologies covered in this JVD, combining standalone/dual MX Series Router with standalone/MNHA pairs 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.

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

• ECMP CHASH is simple to use, leverages standard protocols and well known ECMP mechanism, which might be a preferable option for some SP or enterprise network operations department, though this method is limited when it comes to failover capabilities.
• TLB has load balancing capabilities (at the time of publishing this JVD), which leverages services to load balancing, offers better redundancy capabilities, and can be multiplied with different local groups. It is useful when you need to combine different use cases on the same architecture. This method might not be backward compatible with older Junos OS releases.

Table 1: Validated Features Combination

Load-Balancing Method	Junos OS Release for MX Series Router	Number of MX Series Routers	Security Features	SRX Series Firewalls Standalone	SRXs MNHA Cluster
ECMP with Consistent Hashing	23.4R2	Single MX Series Router	IPsec SECGW	Yes	No
Traffic Load Balancer (TLB) with Health Checking	23.4R2	Single MX Series Router	IPsec SECGW	Yes	Yes
		Dual MX Series Router	IPsec SECGW	Yes	Yes

Note:

Scale-out solution only uses standard mechanisms and protocols between the components and does not require any special proprietary protocols. The exception is how load balancing is implemented internally (how the MX Series Router manages and distributes sessions). From a networking point of view, this solution uses standard protocols.

Following are some recommendations that might help you in selecting the deployment method.

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

This topology is simple and least redundant. The resiliency is provided at MX Series Router, with a redundant RE, PSU. However, there is no protection against MX Series Router failure. Deployment provides protection against service node failure by redistributing traffic flows between two remaining security nodes. Absence of IKE/IPsec session synchronization between the SRX Series Firewalls leads to longer restoration time for the affected flows.

Network operators that are not concerned about stateful failover might want to simply augment security service capacities by adding more SRX Series Firewalls. The application sessions transported over the IPsec sessions might be short lived anyway. For example, a redundancy mechanism might be managed at the application level so IPsec session sync between two different firewalls is not required. Some of the eNodeBs uses dual tunnel to two separate locations).

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

Deployment Scenario 2 – TLB – Single MX Scaled Out MNHA SRX Pairs (Multiple Pairs of SRX Series Firewalls)

This topology does offer redundancy for the SRX Series Firewalls however, not for the MX Series Routers, though this one might have a second Routing Engine (RE) installed in the appropriate slot and is not using two MX Series Routers in that case.

MNHA offer sessions synchronization within a cluster and help with any failure scenario at the SRX Series Firewalls level. BFD helps to detect failures earlier than other mechanisms.

• 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 Scaled Out MNHA SRX Pairs (Multiple Pairs of SRX Series Firewalls)

This last topology offers the most redundancy for both MX Series Router and SRX Series Firewalls nodes and takes advantage of having all components used at the same time. Any failover scenario can be covered.

MX Series Routers handle traffic on any of the two routers, while SRX Series Firewalls can be 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 role as active at a time when the failure occurs (consider 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.