The JUNOS platform architecture separates the control and forwarding functionality in the router:
The Routing Engine (RE) hardware module is the central control point for the system. Normally, you perform all system authentication, system management, system configuration, and monitoring in the Routing Engine. The Routing Engine operates all routing protocols and makes all routing decisions by creating a routing table that includes the best path to each destination. The router writes these paths to a forwarding table in the Routing Engine and then copies the same data to the forwarding table on the Packet Forwarding Engine (PFE) which actually forwards the packets. The PFE forwards packets through the router using ASIC-based switching.
The Physical Interface Cards, or PICs (of which the Multiservices PIC is one type), like the Routing Engine, are physical hardware modules that fit into the router chassis. PICs provide the physical connection to various network media types. The PICs are mounted on Flexible PIC Concentrators (FPCs), which are inserted into a slot in a router. A PIC typically occupies a single slot on an FPC.
PICs receive incoming packets from the network and transmit outgoing packets to the network. During this process, each PIC performs framing and high-speed signaling for its media type. Before transmitting outgoing packets, the PICs encapsulate the packets received from the FPCs. Each PIC is equipped with a media-specific ASIC that performs control functions tailored to the PIC's media type.
I/O PICs handle transit traffic: for example, packet encapsulation, input processing (CRC check), and output queuing. Services PICs take packet traffic from an I/O PIC, perform a service (such as GRE, NAT, and so forth) and send the result back to an I/O PIC.
The following figure shows the router architecture:
Juniper Router Architecture
The Routing Engine's key component is the JUNOS Software operating system. The basis of the JUNOS kernel comes from the FreeBSD UNIX operating system, an open-source software system. This mature, general-purpose system provides many of the essential basic functions of an operating system, such as scheduling resources. To transform it into a network operating system, it has been extensively modified and hardened for the specialized requirements of networking.
The task of managing the router is shared among the JUNOS kernel, many JUNOS daemons, and some ephemeral utility-style applications launched on demand.
The JUNOS system an be controlled by any of several user interfaces, but always in either an operational or configuration mode. As an operator issues operational or configuration commands to control the device, they first flow through the JUNOS management daemon (mgd). mgd directs operational requests and manages changes to the configuration database. Commands issued in the operational mode upgrade software, trigger events, or show status and statistics to inspect the system’s operation.
The configuration database is persistent across reboots. Configuration changes, made in configuration mode, are propagated to any daemons that subscribe to be notified about the given area of change in the database. The daemons have read-only access to the database so that they can detect changes and modify their behavior accordingly. The management daemon may also cause other daemons to be started or stopped because of configuration additions or deletions.
The database governs the enduring behavior of the system (mostly the daemons) between configuration changes. In addition to manual changes made to the configuration, changes in behavior can naturally arise due to outside communication or inter-process communication with another process or the kernel. In the JUNOS system, the control plane model stipulates that internal behavior changes are consistent with the configuration database.
On the control plane, the JUNOS kernel and many daemons expose interfaces so that other processes can dynamically and programmatically manipulate their states and use their services. The routing protocol (rpd) and dynamic firewall (dfwd) daemons both expose such interfaces and eventually control a large part of the data plane of the router. The routing protocol daemon manages the routes that eventually form the forwarding table. The dynamic firewall daemon controls stateless packet filters and rate limiters that are applied to the router’s network interfaces (ports) on ingress or egress.
JUNOS also creates processes ad hoc when needed, such as Simple Network Management Protocol (SNMP), Virtual Router Redundancy Protocol (VRRP), and Class of Service (CoS).
The JUNOS data plane spans many aspects of the chassis and its modules. It is collectively referred to and abstracted as the Packet Forwarding Engine (PFE), and comprised of ASIC-based hardware and software microcode to perform packet processing. The PFE’s extended abilities include rate limiting, shaping, and other CoS functions, all of which are controlled on the control plane. Aiming to perform at fast wire speeds and within its hardware resource limits, the PFE generally defers stateful packet processing to the services plane.
The services plane runs on the Multiservices PICs, which are optionally installable and hot swappable hardware. These connect to the data plane at speeds up to 10Gbps. The services plane is the collection of all Multiservices PIC modules in a chassis, and a given service can be deployed on more than one Multiservices PIC module.
Each Multiservices PIC module runs JUNOS Software with real-time processing capabilities. Yet while the kernel is basically the same one that is present on a Routing Engine, there are far fewer and different daemons running on the PIC. Also, the hardware resources differ greatly from those on the Routing Engine. Each Multiservices PIC module has a multiprocessing, multithreaded CPU and usually more memory than a Routing Engine, so that the software-based services on the PIC can process packets in parallel and maintain a large amount of state.
First, the service software must be installed on Multiservices PICs. Based on configuration, a process on the Routing Engine pushes the software on to each Multiservices PIC before it can be run, since the PICs have no disk. This could involve installing different software on different Multiservices PICs.
Second, once the service software starts on a Multiservices PIC, it needs to be configured with policies to administer, and it may want to report back information through the control plane’s user interface. In the JUNOS system, the model used to achieve this is to have a central management component (daemon) on the control plane for each type of service. The management component handles control-plane-specific functionality such as loading configuration changes, and can communicate that information (policies) to the corresponding service application running on a Multiservices PIC. Communication can flow in the other direction as well if the service application, for example, wanted to send statistics for eventual display in response to an operational command.
Third, the management component controls the data plane to steer packets to the services plane for servicing on a Multiservices PIC. Packets are steered using one of the following:
/usr/lib/libc. Once this package is mounted, everything needed to boot the system is present.
Additional startup events are as follows:
Once all the daemons are running and these activities are complete, the router can communicate with other routers in the network, know where each one is, and compute the packets' best next hop and final destination.