13 min readApr 30, 2021

Hi everyone, I’m Neelesh Patel,Back in 2020 when i got certified as JNCIA-Junos (JN0–103) from Juniper Networks.It is my first Juniper certification and might be the last. However, I haven’t completely ruled out pursuing a higher-level certification.

I have shared my notes for JNCIA-Junos (JN0–103) for free,i hope this will help you too while preparing for your certification.

#1. Juniper Networks JNCIA-Junos: Junos Operating System Fundamentals.

Introducing the Junos OS

The Junos OS is the trusted, secure network operating system powering the
high-performance network infrastructure offered by Juniper Networks. The Junos kernel is based on the FreeBSD UNIX operating system, which is an open-source software system.

This same OS is run across the complete range of Juniper routing, switching, and security platforms.Some other vendors have different operating systems for various product lines, and this can get confusing. Juniper used to be thought of as a vendor whose equipment was mainly deployed in internet service provider networks, but this is no longer the case.
From the point of view of someone learning Junos, this is fantastic.

Juniper Product Families

ROUTING PRODUCT LINE

1.ACX Series
These routers have been optimized for mobile backhaul so that mobile users are able to experience the best possible connectivity over service provider mobile networks.
They have a temperature hardened design and fanless cooling, which means that they can be deployed in extreme environments.

2.MX Series
The MX series routing platform is aimed at enterprises, service providers, and cloud operators, and provides all the capabilities that these type of customers require for scalable, rooted infrastructure. There are features in this range that allow for nonstop availability, even when performing upgrades, which is vital for service providers and ecommerce customers where downtime is unacceptable. As well as different hardware versions, there is also a virtual version, the vMX, which is a fully featured virtual router running Junos that allows for rapid deployment and scalability.

SWITCHING PRODUCT LINE

EX Series
The EX series is Juniper’s range of high‑performance, high‑availability Ethernet switches. You’ll see these switches deployed everywhere from the small business LAN through to large, high‑density datacenters, and also service provider networks, great performing, reliable Ethernet switch that can be used in a wide range of deployment scenarios. Using the Juniper Virtual Chassis and other technologies, multiple EX switches can be operated as a single logical device.
Think of switch stacking using StackWise technology from Cisco, well, this is Juniper’s equivalent. The EX series switches have all the features that you need for the enterprise, such as quality of service, access control, and other security features.
The EX series starts from the EX2200 model that are low‑power, low‑noise, one‑rack unit switches suitable for the branch office right through to the EX9200 series that offer higher performance, port density, and scalability for datacenter and campus core networks.
QFX Series:-The QFX series of Ethernet switches are truly aimed at the datacenter market. They can be deployed in top of rack, end of row, spine, and core configurations and offer 10, 40, and 100 GbE connectivity. They also utilize Juniper Virtual Chassis and other technologies to allow you to build high‑performance, highly available, and scalable datacenter architectures. They’re built to offer high performance with ultra‑low latency switching for the most demanding applications.

SECURITY PRODUCT LINE

1.SRX Range

Juniper’s SRX range, or Services Gateway devices. SRX is a security device, so think firewall, but they’re also much more than this with features like dynamic routing and even Ethernet switching capabilities. As with all Junos products, you will find SRX devices deployed in all kinds of networks, from a small branch where an SRX could be the only device required, providing internet connectivity with security plus routing and switching, right through to a large‑scale ecommerce business using the SRX to provide its internet presence and customer website connectivity. The SRXs can be deployed in highly available clusters so that if one device in the cluster has a problem, then the other device will detect this automatically and take over, meaning that any connections passing through the firewall will be maintained seamlessly. Like the MX series routers, there also virtual versions of the SRX platform known as, you guessed it, the vSRX, and this allows you to run a fully featured, next generation firewall in a virtual instance. You would see this used in large‑scale public and private clouds where the ability to scale up and expand your infrastructure quickly is vital.

Junos Software Architecture

What Is a Network Operating System?

So, let’s get started. First of all, let’s answer the question, what is a network operating system? Well, a network operating system is similar in many ways to the operating system that runs on a laptop, PC or a server. It needs to manage all of the processes that are running on the machine and to allocate system resources such as memory to each of these processes. So if we think of an operating system that runs on a piece of networking equipment, what kinds of processes does it need to run for the switch, router or firewall to do its job? Well first of all, it needs to run all of the processes that are required for management of the device. For example, running the Simple Network Management Protocol, SNMP, to allow a remote server to monitor and manage it. Also, there are processes like Secure Shell, SSH, that has to be running to allow an engineer to log onto the device securely and manage it. These processes are known as daemons.

The purpose of any network device is ultimately to take a data packet in on one of its interfaces, and then forward it out of another interface on its way to its destination. So the network operating system has to work out how to do all of this packet forwarding, and to do this, it has to run processes like dynamic routing protocols, such as OSPF for example, so that it can learn routes to remote networks. Once the OS has worked out how to forward all the packets it receives, it must also then work out how it should handle those packets based on any policies that you, as an engineer, have configured, such as blocking or discarding traffic based on firewall rules or processing packets based on their priority. For example, to ensure that the quality of service is maintained for critical traffic such as voice over IP, which will not tolerate delay of packets. On top of all this, the network device then has to get on with the job of actually forwarding the packets from one interface to another as quickly as possible and without interruption.

JUNOS ENGINEERING

Junos is built upon an existing, general‑purpose, open source UNIX operating system called FreeBSD. Basing Junos on FreeBSD means that the basic functions required of an operating system, such as allocating resources to daemons, are already taken care of. The Juniper software developers then took FreeBSD and were able to modify and harden it, which means to make it more secure, and add the functions required for a network operating system. One very important aspect to bear in mind is that even though all devices running Junos will run their own platform‑specific version of the code, there is a single source code base that all devices run. So, for example, an SRX Services Gateway and an EX series switch will both run their own platform‑specific version of the code to allow for things like firewalling and high‑availability clustering, but the core features run in exactly the same way across all platforms. So, if you can configure OSPF on an SRX, then you can also configure it in the same way on an EX series switch. The great benefit of this is that managing a whole network of Juniper devices becomes easier because you have a standard way of configuring and managing the whole network. The benefits of a simple, standard approach to running your network cannot be underestimated.

Control and Forwarding Planes

Juniper has separated the control plane and the forwarding plane in its architecture. What does this actually mean? Well, remember, we also talked about one of the functions of a network operating system is to work out how to forward packets from one interface to another, whether that is rooting a packet onwards to the next hop or switching a packet from one interface to another. In other words, the network device needs to build and maintain tables of routes or switching paths so it knows how to move a packet onwards to its destination. Well, both of these jobs are handled by what is known as the control plane of the operating system. So if the control plane is all about working out how to handle and move packets, the forwarding plane actually does the work of shifting those packets from ingress to egress interface as quickly as possible.
Remember also that it needs to apply any policies that the engineer may have configured when processing packets that it receives on a given interface, for example applying a firewall filter or a quality of service policy. Juniper has clearly separated the functions of the control plane and the forwarding plane from each other, and this allows the software to run in two separate engines.

The Juniper software engineers took a modular approach to building Junos, and what this means is that each of the software processes runs in its own isolated and protected memory space. The big benefit of this approach is that if one process has a problem or crashes, then only that one process is affected. For example, if there was an issue with the SNMP process, then only SNMP would be affected, and all the other processes would carry on running uninterrupted. The other big advantage of this modular approach is that new features can be added to Junos with a greatly reduced risk of them affecting any current functionality. What this also leads to is easier troubleshooting of network problems where the modular approach means isolating a fault in the OS can be a much easier task than with some other network operating systems. Another benefit of the modular approach is that by its very nature, it leads to a very stable network. And in today’s modern enterprise or service provider network, stability and reliability are absolutely vital.

Routing Engine and Packet Forwarding Engine

Juniper separate the control and forwarding operations of a device so that they operate in their own engines. But what is an engine, you might be wondering? Well, put simply, it means that the two functions or planes each have their own separate, dedicated processes and memory resources. So in the case of Junos, we have the control plane running in what is known as the routing engine, and the forwarding plane running in what is known as the packet forwarding engine.

A good way to think of the routing engine is that it is the brains of the operation, running all the various protocol and management processes.
It’s also responsible for building and maintaining the routing table, the bridging or switching table, and the primary forwarding table. It also controls the packet forwarding engine and sends it updated copies of the layer 2 and layer 3 forwarding tables. The packet forwarding engine, on the other hand, provides the brawn needed to move packets and frames from one interface to another as quickly as possible.
It uses application‑specific integrated circuits, or ASICs, to achieve the required performance.
It also has a copy of the forwarding table that has been sent by the routing engine, and because it has this local copy, it doesn’t need to consult the routing engine every time it has a frame or packet to forward. Finally, it also applies those policies, such as firewall filters and quality of service.

CONCEPT OF ROUTING ENGINE AND FORWARDING ENGINE

It is home to the control plane and the Junos operating system itself. It also builds and maintains the primary forwarding table made up of the routing and bridging tables. There’s an internal link between the routing engine and the packet forwarding engine, and it’s across this link that the routing engine sends the forwarding table information to the packet forwarding engine, which does all of the hard work of actually forwarding the frames and packets. The Junos kernel treats any updates to the forwarding table as a high priority to ensure there is no delay in making the packet forwarding engine aware of a network change that requires an update to the forwarding table. It’s important to mention again that all devices running Junos share this common architecture, even though the actual physical components that make up the switch, router or security device may differ. So, this separation of the two engines means that each engine can concentrate solely on its own functions. For example, the packet forwarding engine only has to worry about forwarding packets and frames, and it can do this in a very fast and reliable way. Another advantage of this separation is that it makes possible some of Juniper’s high availability features like graceful routing engine switchover, nonstop active routing, and in‑service software upgrades. The reason for this is that even if the packet forwarding engine loses contact with the routing engine briefly, say in the case of a software upgrade, that it can just keep forwarding packets and frames based on its local copy of the forwarding table. So, for example, with ISSU, you can upgrade the Junos code or switch and it would just keep forwarding frames without any interruption during the upgrade process.

TRANSIT TRAFFIC PROCESSING AND EXCEPTION TRAFFIC

Transit Traffic

Transit traffic is all network traffic that passes through the device on route to another destination device. For example, this could be packets of data being routed on their way to their next hop, which could be another router, or frames being switched between two client PCs attached to the same Ethernet switch.
Transit traffic can either be unicast or multicast. With unicast, there is a one‑to‑one relationship between ingress and egress ports, which means that traffic is received on a single ingress port, and then it’s forwarded out of exactly one egress ports.For example packets flowing between a server and a single PC on a network.

Multicast traffic, on the other hand, is where there is a one ingress port to many egress port relationship. For example, a multicast server streaming video content is connected to one port, the ingress port on a switch, and there are two client PCs connected to egress ports that are viewing the video stream.

A frame or packet is received on an ingress network port. The frame or packet is then compared against the forwarding table. When a matching forwarding table entry is found, then the packet or frame is then forwarded out of an egress port towards its destination. In order for traffic to transit through the device, then there must be a matching entry for it in the forwarding table. Don’t forget that for traffic being routed at layer 3, there could still be a default route in the table, even if there is no exact match. Also, another thing to remember is that transit traffic is never forwarded over the internal link up to the routing engine. It only ever stays within that packet forwarding engine. Again, this comes back to the way that Junos has been architected, and the effect of this is that traffic can be reliably forwarded through the device at maximum speed.

Exception Traffic

If transit traffic is traffic that is passing through the device and can be handled by the packet forwarding engine, then logically it follows that exception traffic must be traffic that cannot be handled by the packet forwarding engine. So you’re thinking, what kind of traffic could this be? Well, there are three main types that you need to be aware of.

Firstly, there is ICMP message traffic that requires a response from the routing engine. ICMP is used by the Ping and traceroute utilities, for example. Most ICMP traffic is actually handled by the packet forwarding engine, but some message types, such as those reporting errors such as destination unreachable or TTL expired, need to go to the routing engine for processing.

Then there is traffic destined for the device itself, which includes things like dynamic routing protocol updates from pair routers. Let’s say, for example, that there is a link that has gone down on a neighboring OSPF router, and when the topology change notifications get sent to our router, it is classed as exception traffic as it is addressed to the router itself. Other types of similar traffic could be SNMP for network management, or the traffic generated were you connect over SSH to manage your switch or router.

Lastly, the other type of exception traffic to be aware of is actually quite obscure, but it is when the IP Options field in the header of an IP packet is set. Again, this type of packet cannot be handled by the packet forwarding engine, so it must be sent up to the routing engine to be processed. We can use a slightly simplified version of our diagram of the routing engine and packet forwarding engines to illustrate the process of how exception traffic is handled. It’s very straightforward in that when exception traffic is received on an ingress port, it is then passed across the internal link up to the routing engine. The routing engine then processes the packets and sends any return traffic back down across the internal link to be forwarded back out of the same interface to the source of the original packet. So, example of a dynamic routing protocol update, these packets would be received and sent back out of the interface that was connected to our neighboring router.
One important factor you should remember is that Junos supplies rate limiting to the internal link between the routing engine and the packet forwarding engine. The reason for this is to protect the routing engine from a denial of service attack, which would be when an attacker is trying to overwhelm the router or switch by flooding it with packets that it has to process. The rate limiting feature will prevent such an attack.