Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Applications in the Junos Architecture

The Junos operating system (OS) is a single network operating system that integrates routing, switching, and security. Most Juniper Networks platforms run the Junos OS and also support applications created by third-parties, referred to in this guide as providers.

This topic presents the Junos OS architecture at a high level and in detail where it pertains to building applications. It continues explaining how the architecture fits over the hardware, and what types of applications are best suited to the environments described.

Figure 1: Architecture Summary and Traffic Paths

Control Plane

The control plane in the Junos OS is a logical element that manages and controls the behavior of the device and the other two planes, the data plane and the services plane. The control plane runs on the Routing Engine. The Routing Engine may be a separate physical module or may be integrated into a device. In some products the Routing Engine cards are hot-swappable physical modules in the chassis. A chassis option for a redundant Routing Engine backing up the master Routing Engine is also available. Applications can take advantage of this redundant Routing Engine to enable their own high availability.

• Has a global view of the device hardware and software
• Exposes the user interface and manages the native Junos OS features

The Routing Engine's key component is the Junos OS. The Junos OS is based on the FreeBSD operating system, an open-source software system. This mature, general-purpose system provides many of the essential functions of an operating system, such as scheduling resources. To transform it into a network operating system, Juniper Networks engineers have extensively modified and hardened it for the specialized requirements of networking.

On the control plane, the Junos kernel, many of the Junos daemons, and some ephemeral utility-style tools launched on demand are run. The daemons and tools that come bundled with the Junos OS are considered part of the Junos OS platform.

Applications for the control plane resemble these daemons and tools. In fact. These applications then become part of the common platform and Junos OS software bundle. Applications can programmatically manipulate the states of the platform software and make use of their services in a dynamic way. The daemons that control the Junos OS user interface also allow for programmatic and seamless extensibility of the user interface. You can configure and administer a modified user interface in the same way as you do for applications.

Data Plane

The data plane in the Junos OS is a logical element that spans many aspects of a device’s chassis and its modules. The data plane’s role is to forward traffic according to the forwarding table, primarily formed through the routing control service on the control plane. The data plane’s main extended abilities include switching, filtering, rate limiting, shaping, and other quality-of-service (QoS) functions. These functions are controlled by the control plane.

In the Junos environment and the Junos applications architecture, the data plane abstraction is often specifically referred to as the Packet Forwarding Engine. It comprises ASIC-based hardware and software microcode to perform packet processing. Aiming to perform at fast wire speeds and within its hardware resource limits, the Packet Forwarding Engine generally defers stateful packet processing to the services plane. Applications do not run in the data plane, which is tightly bound to the hardware. An application running in the control or services plane can influence the packet processing mechanism in the data plane, however.

Services Plane

The services plane in the Junos OS is a logical element that can be thought of as an extension to the data plane to perform stateful services and any services non-native to the Packet Forwarding Engine. A classic example of a Junos OS service application is the stateful firewall.

In traditional forwarding devices, the data plane usually handles much of the packet processing and the services plane runs on optionally installable and hot-swappable hardware, which are generically called services modules. The services plane spans the collection of all services modules in a chassis, and a given service application can be deployed on more than one module. For the M Series, T Series, and MX Series routers, the specific modules supporting the services plane are the Multiservices PIC and the Multiservices DPC.

In security and service-oriented devices, the services plane is the primary packet processor, and the data plane merely connects a chassis containing many services modules. While these devices can perform forwarding, they are purpose built and deployed to service traffic in stateful ways implemented in software running on the services modules.

The Junos kernel on a services engine further logically divides packet handling for applications in two sub-planes. Its services plane (data plane extension) is for fast customized transit traffic processing. Its control plane is for traffic termination with the IP stack. The control plane components frequently implement a server or signaling to communicate outside the device or simply to other components on the Routing Engine.

Applications in the services sub-plane of a service module can take on two roles involving inline packet processing: transforming and monitoring. Transforming applications have access to any traffic flowing through the Packet Forwarding Engine that is selected for servicing at the given service module. They can modify, drop, hold, and create entire packets. Monitoring applications work similarly, but the packets they receive are duplicates of some traffic originally transiting the Packet Forwarding Engine. When monitoring is used, the original traffic is not impacted or serviced. The selection and configuration of either packet processing option is application specific. A hybrid application can differentiate and deal with both original and duplicated packets. Sometimes hybrid applications are named gateways, and may combine a server or signaling control plane component with a transforming or monitoring services plane component. Many familiar service applications, such as the Junos IPsec service, work with both styles of components.

Traffic Types

Applications deal with two different types of traffic: control traffic and data traffic.

Control traffic is in the control plane. You can classify control traffic as traffic that is either internal to the device entirely (for example, interprocess communication) or, more generally, as traffic destined to or sourced from a device address. Most addresses configured on the device belong to the master Routing Engine. For example all addresses configured on network interfaces for I/O ports and the loop back interface pertain to the Routing Engine, so control traffic destined to those addresses is forwarded to the master Routing Engine and handled there. The Junos OS also allows the configuration of addresses on interfaces representing a service module. Traffic destined to those addresses is forwarded to and handled on the given service engine’s control sub-plane.

Data traffic flows through the data plane. You can classify data traffic that relates especially to any application as the traffic selected for servicing or monitoring. This is the traffic seen in the services plane handled by transforming or monitoring applications. Data traffic naturally flows through the Packet Forwarding Engine as transit traffic, but there are application-specific mechanisms by which it can be selected for steering through the service engine’s services plane. On exit, the steered traffic is re-routed and filtered in the Packet Forwarding Engine as if it was entering the device from any I/O interface.