Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Understanding cSRX with Contrail

    The cSRX Container Firewall is a containerized version of the SRX Series Services Gateway with a low memory footprint. cSRX provides advanced security services, including content security, AppSecure, and unified threat management in a container form factor. By using a Docker container in Contrail the cSRX can substantially reduce overhead because each container shares the Linux host’s OS kernel. Regardless of how many containers a Linux server hosts, only one OS instance is in use. And because of the containers’ lightweight quality, a server can host many more container instances than it can virtual machines (VMs), yielding tremendous improvements in utilization. With its small footprint and Docker as a container management system, the cSRX Container Firewall enables agile, high-density security service deployment.

    This section includes the following topics:

    cSRX Overview

    The cSRX Container Firewall deploys as a single container on a Docker Engine compute node running in a Contrail cluster. It runs on a Linux bare-metal server as the hosting platform for the Docker container environment. The cSRX container packages all of the dependent processes (or daemons) and libraries to support the different Linux host distribution methods (Ubuntu, Red Hat Enterprise Linux, or CentOS). cSRX is built on the Junos operating system (Junos OS) and delivers networking and security features similar to those available on the software releases for the SRX Series.

    When the cSRX container runs, there are several processes (or daemons) inside the Docker container that launch automatically when the cSRX becomes active. Some daemons support Linux features, providing the same service as if they are running on a Linux host (for example, sshd, rsyslogd, monit, and so on). Other daemons are compiled and ported from Junos OS to perform configuration and control jobs for security service (for example, MGD, NSD, UTM, IDP, AppID, and so on). srxpfe is the data-plane daemon that receives and sends packets from the two revenue ports of a cSRX container. The cSRX uses srxpfe for Layer 2 through 3 forwarding functions as well as for Layer 4 through 7 network security services.

    The cSRX Container Firewall enables advanced security at the network edge in a multitenant virtualized environment. cSRX provides Layer 4 through 7 advanced security features such as firewall, IPS, and AppSecure. The cSRX container provides a pair of revenue ports attached to the trusted and untrusted zones. The cSRX container also provides an additional interface to manage the cSRX. When cSRX is operating in Layer 2 mode, incoming Layer 2 frames from one interface go through Layer 4 through 7 processing based on the configured cSRX services. cSRX then sends the frames out of the other interface. The cSRX container either allows the frames to pass through unaltered or drops the frames, based on the configured security policies.

    Figure 1 illustrates a high-level view of a cSRX container instance. It is an example of how a cSRX container is bridged with an external network. In this illustration, cSRX eth1 is bridged with host physical NIC eth1 and cSRX eth2 is bridged with host physical NIC eth2.

    Note: As part of your Docker container configuration, you must connect the cSRX container to three virtual networks: one virtual network for out-of-band management sessions, and the other two virtual networks to receive and transmit in-band data traffic. See Configuring cSRX in a Contrail Service Chain.

    Figure 1: cSRX Container Overview

    cSRX Container
Overview

    cSRX Benefits and Uses

    The cSRX Container Firewall enables you to quickly introduce new firewall services, deliver customized services to customers, and scale security services based on dynamic needs. The cSRX container differs from VMs in several important ways. It runs with no guest OS overhead, has a notably smaller footprint, and is easier to migrate or download. The cSRX container uses less memory, and its spin-up time measures in subseconds—all leading to higher density at a lower cost. The boot time is reduced from several minutes with a VM-based environment to less than a few seconds for the cSRX container. The cSRX is ideal for public, private, and hybrid cloud environments.

    Some of the key benefits of cSRX in a containerized private or public cloud multitenant environment include:

    • Stateful firewall protection at the tenant edge.

    • Faster deployment of containerized firewall services into new sites.

    • With a small footprint and minimum resource reservation requirements, the cSRX can easily scale to keep up with customers’ peak demand.

    • Provides significantly higher density without requiring resource reservation on the host than what is offered by VM-based firewall solutions.

    • Flexibility to run on a bare-metal Linux server or Juniper Networks Contrail.

      • In the Contrail Networking cloud platform, cSRX can be used to provide differentiated Layer 4 through 7 security services for multiple tenants as part of a service chain.

      • With the Contrail orchestrator, cSRX can be deployed as a large scale security service.

    • Application security features (including IPS and AppSecure).

    • UTM content security features (including antispam, Sophos Antivirus, web filtering, and content filtering).

    • Authentication and integrated user firewall features.

    Note: While the security services features between cSRX and vSRX are similar, there are scenarios in which each product is the optimal option in your environment. For example, the cSRX does not support routing instances and protocols, switching features, MPLS LSPs and MPLS applications, chassis cluster, and software upgrade features. For environments that require routing or switching, a vSRX VM provides the best feature set. For environments focused on security services in a Docker containerized deployment, cSRX is a better fit.


    See Junos OS Features Supported on cSRX for a summary of the feature categories supported on cSRX, and also for a summary of features not supported on cSRX.

    You can deploy the cSRX Container Firewall in the following scenarios:

    • Cloud CPE–For service providers (SPs) and managed security service providers (MSSPs) where there is a large subscriber base of branch offices or residential subscribers. MSSPs can offer differentiated services to individual subscribers.

    • Contrail microsegmentation–Within a Contrail environment running mixed workloads of VMs and containers, cSRX can provide security for Layer 4 through 7 traffic, managed by Security Director.

    • Private clouds–cSRX can provide security services in a private cloud running containerized workloads and can include Contrail integration.

    Docker Overview

    Docker is an open source software platform that simplifies the creation, management, and teardown of a virtual container that can run on any Linux server. A Docker container is an open source software development platform, with its main benefit being to package applications in “containers” to allow them to be portable among any system running the Linux operating system (OS). A container provides an OS-level virtualization approach for an application and associated dependencies that allow the application to run on a specific platform. Containers are not VMs, rather they are isolated virtual environments with dedicated CPU, memory, I/O, and networking.

    A container image is a lightweight, standalone, executable package of a piece of software that includes everything required to run it: code, runtime, system tools, system libraries, settings, and so on. Because containers include all dependencies for an application, multiple containers with conflicting dependencies can run on the same Linux distribution. Containers use the host OS Linux kernel features, such as groups and namespace isolation, to allow multiple containers to run in isolation on the same Linux host OS. An application in a container can have a small memory footprint because the container does not require a guest OS, which is required with VMs, because it shares the kernel of its Linux host’s OS.

    Containers have a high spin-up speed and can take much less time to boot up as compared to VMs. This enables you to install, run, and upgrade applications quickly and efficiently.

    Figure 2 provides an overview of a typical Docker container environment.

    Figure 2: Docker Container Environment

    Docker Container
Environment

    Juniper Networks Contrail Overview

    Juniper Networks Contrail is an open, standards-based software-defined networking (SDN) platform that delivers network virtualization and service automation for federated cloud networks. It provides self-service provisioning and improves network troubleshooting and diagnostics. It also enables service chaining for dynamic application environments across an enterprise virtual private cloud (VPC), managed Infrastructure as a Service (IaaS), and Network Functions Virtualization (NFV) use cases. You can use Contrail with open cloud orchestration systems such as OpenStack or CloudStack to instantiate instances of cSRX in a containerized environment.

    The cSRX Container Firewall can be deployed on a Docker Engine compute node as a dedicated firewall in the Contrail Networking cloud environment to provide differentiated Layer 4 through 7 security services for multiple tenants as part of a service chain. With the Contrail orchestrator, cSRX is deployed as a large scale security service, and is configured to steer traffic from vRouter with vRouter interface (VIF). Traffic and health statistics are monitored by the Contrail service orchestrator.

    When you deploy the cSRX container in a Contrail Networking cloud environment, Contrail:

    • Stores the cSRX image in an Openstack glance service so it can be used to launch new service instances.

    • Distributes the cSRX image to different computer nodes from the Docker registry service.

    • Launches the cSRX container with the Openstack Nova service.

    • Spawns a cSRX service chain in the Contrail controller with a service template, virtual network, service instance, and network policy.

    • Monitors cSRX container status and statistics in the Contrail service orchestrator.

    Figure 3 illustrates how the cSRX Container Firewall provides security services in a Contrail Networking cloud environment.

    Figure 3: cSRX Container Firewall in an SDN Environment

    cSRX Container
Firewall in an SDN Environment

    Contrail is logically centralized and behaves as a single logical unit, despite the fact that it is implemented as a cluster of multiple nodes. Contrail Networking nodes include:

    • Contrail Control Nodes–Control nodes implement the logically centralized portion of the control plane. Control nodes are responsible for the routing control plane, configuration management, analytics, and UI.

    • Contrail Compute Nodes–Compute nodes are general-purpose virtualized servers that host VMs and containers (such as the cSRX). These VMs can be tenants running general applications, or these VMs can be service VMs running network services such as a virtual load balancer or virtual firewall. Each compute node contains a vRouter that implements the forwarding plane and the distributed part of the control plane. Compute nodes are responsible for managing the data plane.

    In the Contrail network, a compute node is a general-purpose x86 server that hosts VMs and containers running applications such as Web servers, database servers, enterprise applications or hosting virtualized services used to create service chains. You install and configure the Docker Engine on at least one compute node to implement the Linux container environment, and the cSRX container is installed on the compute node that is running the Docker Engine. A cSRX service pool can consist of multiple Docker Engine compute nodes.

    The control node hosts the Docker registry, Openstack Controller, and Contrail Controller to orchestrate the virtual services. The cSRX image is automatically pulled from the Docker registry to the Docker Engine compute node when a cSRX instance is initially launched. The cSRX compute node communicates with the control node to receive instructions to start each cSRX container and to set up the service chain by inserting the cSRX network interface into the different vRouter virtual networks in the Contrail cluster. Virtual networks can be shared across different tenants.

    Figure 4 illustrates the role of the cSRX Container Firewall in a Contrail Networking cloud environment and how it provides multitenancy.

    Figure 4: cSRX Service in Contrail Networking Cloud Environment

    cSRX Service
in Contrail Networking Cloud Environment

    Figure 5 illustrates the cSRX compute nodes in a Contrail Networking cloud environment.

    A dedicated Nova Docker Agent runs on the cSRX compute node to receive instructions from the Openstack Controller and to act on behalf of the cSRX. When the Nova Docker Agent starts the cSRX container, the agent will first check if the cSRX image is located in the local host Docker Engine. If not, the agent will then attempt to pull the cSRX image from the remote Docker registry. Once a cSRX container starts, the Nova Docker Agent also creates a vRouter interface (VIF) for the cSRX container and “plugs” the VIF to the different virtual routing and forwarding (VRF) instances of the vRouter according to the service template’s virtual network configuration.

    Figure 5: cSRX Compute Node

    cSRX Compute Node

    cSRX Scale-Up Performance

    You can scale the performance and capacity of a cSRX container by increasing the allocated amount of virtual memory or the number of flow sessions. Table 1 shows the cSRX scale-up performance applied to a cSRX container based on its supported sizes: small, medium, and large. The default size for a cSRX container is large.

    Note: See cSRX Scale-Up Performance Configuration for the procedure on how to scale the performance and capacity of a cSRX container.

    Table 1: cSRX Scale Up Performance

    cSRX Size

    Physical Memory Overhead

    Number of Flow Sessions

    Release Introduced

    Small

    256M

    8K

    Junos OS Release 18.1R1

    Medium

    1G

    64K

    Large

    4G

    512K

    Modified: 2018-06-19