19. Junos Software Architecture
Let’s talk about the Junos software architecture.
The Junos kernel is based on the FreeBSD Unix operating system, which is an open-source software. So, the Junos kernel or, in other words, the core of the Junos operating system is based on FreeBSD Unix operating system.
The Junos functionality is compartmentalized into multiple software processes, and each process handles a portion of the devices functionality and runs in its own protected memory space.
Having an architecture like this has its own advantages because every process is running in its own protected memory space. Even if a single process fails, the entire system will not feel. And every process is responsible for handling a specific functionality. For example, there’s a process that’s responsible for providing the CLI; there’s a process that’s responsible for managing routing protocol updates; there’s a process that’s responsible for system logging and so on.
The architecture of Junos looks like this. So, the Junos device is divided into two planes. You have a control plane and you have a forwarding plane. The control plane consists of the routing engine, which is the brain of the device, and the forwarding plane contains the packet forwarding engine, which is the muscle of the device. So, all of the important tasks like maintaining the routing table, providing the user interface, all of that is managed by the routing engine while activities like forwarding traffic is managed by the packet forwarding engine. Both these engines – routing engine and packet forwarding engine – are connected using an internal link.
In the next video, we’ll understand the different functions of the routing engine and the packet forwarding engine.
20. Routing Engine and Packet Forwarding Engine
Let’s now talk about the functions of the routing engine (RE) and the packet forwarding engine (PFE).
The routing engine is the brain of the device. And it is responsible for performing important functions like routing protocol updates and a system management. It is based on x86 or PowerPC architecture, depending on the platform that’s running Junos. It is responsible for maintaining routing tables, bringing table and the primary forwarding table. So, it is the job of the routing engine to construct the routing table.
The routing table is a table of all the known routes. This table is used to build what is known as the forwarding table, and the forwarding table only contains the active routes.
So, the routing engine starts by collecting all the known routes and puts them into a table called as the routing table. This is then used to create another table called forwarding table, which only contains the active routes, and a copy of this is sent to the packet forwarding engine.
What is the advantage of doing this? We’ll talk about it shortly. The routing engine is also responsible for controlling the interfaces, chassis components, system management and access to the device. This means it is the routing engine that’s responsible for providing the command line interface (CLI) and the J-Web graphical user interface (GUI). These are the two ways to connect to a Junos device. You can connect with the command line interface or you can connect with other graphical user interface, which is known as the J-Web. And it is the responsibility of the routing engine to provide these interfaces.
The routing engine also creates and maintains one or more routing tables. And this is used to create the forwarding table that contains the active routes.
Let’s now talk about the packet forwarding engine.
The packet forwarding engine usually runs on a separate hardware. So, there is a hardware-level separation between the control plane and the forwarding plane. This makes the system fault tolerant. So, even if the routing engine fails, the packet forwarding engine can continue to operate because it is on a separate hardware.
It is responsible for forwarding transit traffic through the device. So, any traffic that enters the Junos device through one of the interfaces gets processed by the packet forwarding engine and it’s sent out another interface. That’s what is known as the transit traffic. And it is the responsibility of the packet forwarding engine to manage transit traffic.
The packet forwarding engine receives a copy of the forwarding table from the routing engine using an internal link, and we can see that in the diagram here. The routing engine creates the routing table, which is then used to populate the forwarding table. The forwarding table is then copied over to the packet forwarding engine using an internal link that connects the routing engine and the packet forwarding engine. The updates that are sent on this internal link are high priority updates, and they are incremental in nature. That means only the changes are sent over, the entire copy is not sent each time.
Having a copy of the forwarding table on the packet forwarding engine has its own advantages. When traffic comes in through one of the interfaces and when it needs to be forwarded out another interface, the packet forwarding engine does not need to consult the routing engine because it already has a copy of the forwarding table.
Remember, the routing engine is the brain of the device. It’s the most important part of the device and increasing load on the routing engine is not a good idea. So, the packet forwarding engine keeps a copy of the forwarding table, so it can make its own decisions. When packet comes in, it checks a forwarding table. If there is a route available, the packet is sent out without having to consult the routing engine.
Also, having a separation like this where the packet forwarding engine is running on a separate hardware results in fault tolerance. Even if the routing engine becomes unavailable, the packet forwarding engine can continue to operate because it has its own copy of the forwarding table.
Moving on, the packet forwarding engine usually runs on separate hardware. We spoke about this. And in some cases it uses application specific integrated circuits, also known as ASICs, for increased performance. If you’re wondering what an ASICs is, it is just a specialized hardware used to improve performance. So, on some Junos devices that need high performance, the packet forwarding engine may be hosted using specialized hardware known as ASICs.
The packet forwarding engine is also responsible for implementing services such as rate limiting, stateless firewall filters, and a class of service (CoS).
I’ve opened up a document here which is called as the Junos OS Architecture Overview. And scrolling down on this document, we can see a beautiful picture that shows the differences between the routing engine and the packet forwarding engine. As you can see here, the routing engine is responsible for key functions like maintaining routing tables, controlling the routing protocol process, interface process, providing the user interface like the command line interface and the J-Web GUI, and also to create a copy of the forwarding table. The packet forwarding engine is usually hosted on a separate hardware. It has its own copy of the forwarding table and sometimes may also use ASICs for improved performance.
21. Protocol Daemons
Welcome to this short video on protocol daemons.
We spoke about this earlier that each Junos process runs in its own protected memory space. And this process is what is known as a daemon. Each daemon has a specific function. For example, here I have some of the common Junos daemons.
The first one is routing protocol daemon (rpd). This is responsible for providing routing protocol, intelligence.
Then we have dcd, also known as device control daemon. And this is responsible for managing the interfaces.
Then we have mgd, or management daemon. This is responsible for providing user configuration access to the system, like the command line interface.
Another important one is alarm daemon, or alarmd. This is responsible for managing system alarm notifications.
And we also have system log daemon (syslogd), which is responsible for managing the logging functions.
There is a long list of daemons that run on a Junos device. What I’m showing you on the screen are just some of the important ones. The daemons can also be viewed on the Junos device by running the command show system processes from the operational mode. We haven’t logged into a Junos device yet, but when we get to the device configuration, we’ll run this command to see the list of protocol daemons.
From the examination standpoint, you do not need to memorize the name and function of every daemon. However, it’s a good idea to keep in mind some of the important ones, like the routing protocol daemon or the syslog daemon.
Also, from the examination standpoint, you should remember the command that is used to view the protocol daemons.
22. Transit and Exception Traffic
Now, let’s talk about transit traffic and exception traffic and let’s understand the differences between these two.
Let’s begin with transit traffic. Traffic that enters and ingress port, is compared against the forwarding table, and is finally forwarded out an egress port is known as transit traffic. So, traffic that enters the device through an interface, is compared against the entries in the forwarding table and is forwarded out another interface is what we call as transit traffic.
For the traffic to be forwarded, the forwarding table must have an entry for the destination. If there is no entry in the forwarding table for the destination of that packet, the packet will be dropped. It will not be forwarded.
Very important to remember that transit traffic is handled only by the forwarding plane. And this is because the forwarding plane has a copy of the forwarding table.
So, back to the diagram that we saw earlier. Here’s the Junos device, which has a control plane and a forwarding plane. When the packet comes in… Let’s assume the orange block is the packet. When the packet comes in through an ingress port, it is compared against the forwarding table. This is done by the forwarding plane because the forwarding plane has a copy of the forwarding table. And if there exists an entry for the destination of that packet in the forwarding table, the packet will be forwarded out. This is what is called as transit traffic.
An important thing to keep in mind is that transit traffic can be unicast or multicast. Unicast traffic is the one that enters through one ingress port and exits through one egress port. But transit traffic can also be multicast. Multicast traffic is the one that enters the device through one ingress port and is forwarded out through multiple egress ports. So, keep in mind that transit traffic does not have to be unicast only. It can be unicast or it can be multicast.
Now, let’s talk about exception traffic. Exception traffic does not pass through the local device, but requires special handling. So, any traffic that is this time to terminate on the Junos device itself, meaning when the Junos device is the destination of that traffic, that’s what we call as exception traffic.
For example, when you try to ping the Junos device, that traffic is going to terminate on the Junos device. That is exception traffic. Or let’s say you try to SSH into the Junos device. That is also going to terminate on the Junos device. And that is called exception traffic. So, examples of exception traffic include packets addressed to the chassis, like routing protocol updates, because routing protocol updates are consumed by the device itself, SSH or Telnet sessions, ping and traceroute traffic, this time for the Junos device itself.
Another example is TCP/IP packets with the options field set. The TCP/IP packet header has different fields. And one of the field is the options field. By setting the options field, you are instructing for special handling of that packet. So, if the IP options field is set, that is also an example of exception traffic.
Going back to the diagram, when the packet comes in, it is first going to hit the forwarding plane. Remember, traffic always comes in through the forwarding plane, but the destination of this packet is the Junos device itself. So, this packet will be forwarded to the routing engine.
Some other key points to keep in mind, all exception traffic destined for the routing engine is sent over the internal link that connects the control and the forwarding planes. Any traffic that is traversing through the internal link is rate limited to protect the routing engine from denial-of-service (DoS) attacks. Rate limiting means that there is a limit on the number of package that you can send per second. So all exception traffic that passes through the internal link over to the routing engine is rate limited to protect the routing engine. The rate limiter off the internal link is not configurable.
So, key points to keep in mind, any traffic that enters an ingress port and exits an egress port is called as transit traffic while exception traffic is any traffic that is destined to the Junos device itself.
