Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Understanding Containerized RPD

The Junos® containerized routing protocol process (cRPD) offers deployment-hardened, feature-rich routing functionality in a container for cloud-native deployments.

Benefits of cRPD

  • Results in faster deployment as usage of containers reduces the time requirements for service boot up from several minutes to a few seconds.

  • Runs on any Linux server that supports Docker.

  • Supports small footprint and minimum resource requirements that easily scale to keep up with customers’ peak demand.

  • Provides significantly higher density without requiring resource reservation on the host.

  • Provides stable routing software on Linux with cRPD.

cRPD Overview

Containerized routing protocol process (cRPD) is Juniper’s routing protocol process (rpd). cRPD software image is packaged as a Docker container to run in Linux-based environments.

rpd runs as an application to:

  • Learn the route state through various routing protocols.

  • Maintain the complete set of routing information in routing information base (RIB), also known as routing table.

  • Starts all configured routing protocols and handles all routing messages. It maintains one or more routing tables, which consolidate the routing information learned from all routing protocols.

  • Implements a routing policy, which enables you to control the routing information that transfers between the routing protocols and the routing table. Using the routing policy, you can filter and limit the transfer of information as well as set properties associated with specific routes.

  • Download the routes based on local selection criteria into the forwarding information base (FIB) known as forwarding table.

Figure 1 shows the cRPD overview.

Figure 1: cRPD Overview cRPD Overview

The Packet Forwarding Engine (PFE) in Juniper Networks router holds the FIB and forwards the packet for cRPD. The host Linux kernel stores the FIB and performs packet forwarding.

cRPD forwards the routes into FIB that are based on local route selection criteria. cRPD contains the RPD, PPMD, CLI, MGD, and BFD processes.

cRPD defines how routing protocols such as ISIS, OSPF, and BGP operate on the device.

The routing protocol process performs the following functions:

  • Controls the routing protocols that run on a router.

  • Determines the active routes for the network destinations that are based on the routing information and installs these routes into the Routing Engine’s forwarding table.

Figure 2 shows the architecture of cRPD able to run natively on Linux.

Figure 2: cRPD on Linux Architecture cRPD on Linux Architecture

How cRPD Works?

When multiple cRPD applications are running on a system, that is in bridge mode, the containers connect to the host network stack through bridges. cRPD connects to the Linux OS using bridges. The host interfaces connect to the container using bridges. Multiple containers connect to the same bridge and communicate with each other. The default Docker bridge enables NAT. NAT bridges act as a management port for the container. In this scenario, the clients cannot initiate connections to the containerized route reflector (cRR). If the bridge connects to the host OS network interfaces, external communication is feasible. For routing purposes, you can assign all or a subset of physical interfaces for use by a Docker container. This mode is useful for cRR and partitioning the system into multiple routing domains.

The network interfaces present in the underlying OS kernel are exposed to the cRPD on Linux container. cRPD learns about all network interfaces and adds route state for all network interfaces. If there are additional Docker containers running in the system, all the containers and applications running in the same network namespace can access the same set of network interfaces and state.

Route Reflector

You can also deploy cRPD to provide control plane only services such as BGP route reflection.

Route Reflection networking service must not depend on the same hardware or the controllers that host the application software containers that are using the reachability learnt by using the Route Reflection service. cRR service must work independently.

Routing Engine Kernel

The Routing Engine software consists of several software processes that control router functionality and a kernel that provides the communication among all the processes.

The Routing Engine kernel provides:

  • Link between the routing tables and the Routing Engine’s forwarding table.

  • Communication with the Packet Forwarding Engine, which includes keeping the Packet Forwarding Engine’s copy of the forwarding table synchronized with the primary copy in the Routing Engine.

The RPD runs natively on Linux and communicates program routes into the Linux kernel using Netlink. Netlink is a Linux kernel interface used for communication between both the kernel and user space processes, and between different userspace processes. cRPD is an example of a userspace process.

The Netlink messages are used to:

  • Install FIB state generated by RPD to Linux kernel.

  • Interact with mgd and CLI for configuration and management.

  • Maintain protocol sessions using PPMD.

  • Detect liveness using BFD. RPD learns the interface attributes such as their name, addresses, MTU settings and link status from the Netlink messages.

Docker Overview

cRPD runs on any Linux distribution system that supports Docker.

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. The Docker container packages the applications in “containers”. These containers are portable on any Linux Operating System (OS). A container provides an OS-level virtualization approach for an application. Containers are not VMs, rather they isolate virtual environments with dedicated CPU, memory, I/O, and networking.

The 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 it shares the kernel of its Linux host’s OS.

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

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

Figure 3: Docker Container EnvironmentDocker Container Environment

Supported Features on cRPD

cRPD supports the following features:

  • BGP Route Reflector in the Linux container

  • BGP add-path, multipath, graceful restart helper mode

  • BGP, OSPF, OSPFv3, IS-IS, and Static

  • BMP, BFD, and Linux-FIB

  • Equal-Cost Multipath (ECMP)

  • JET for Programmable RPD

  • Junos OS CLI

  • Management using open interfaces NETCONF, and SSH

  • IPv4 and IPv6 routing

  • MPLS routing

Licensing

The cRPD software features require a license to activate the feature. To understand more about cRPD licenses, see Supported Features on cRPD, Flex Licenses for cRPD, and Managing cRPD Licenses.