There are different schools of thought when it comes to operating system design.
Junipers Juniors and Cisco's iOS, for example,
take very different approaches We're going to see the advantages
to the Juno's modular design when it comes to operating systems.
There are two main designs monolithic and modular
The monolithic architecture is very simple.
All processes, including memory management, file management,
device management and process management are contained directly in the kernel.
This can be used for very specific purposes, and it can be very fast, too.
Unfortunately, there are also downsides
The entire operating system uses a single memory space,
which means that a fault in one component can take down the entire kernel.
It's also difficult to port to different hardware as the drives are part
of the kernel too.
I've put a link in
the description if learning about this kind of thing interests you
A modular operating system is a bit different.
Each process operates independently, separate
from the kernel in its own protected memory space.
If there's a fault in one process, it will not damage another.
Drivers are also independent, which means that the operating system
can be more easily ported to other hardware.
Overall, this is a more modern, sophisticated design,
which improves stability and uptime
for comparison reasons.
Let me point out that Cisco's traditional iOS is a monolithic operating system.
iOS has been around a long time, so monolithic is pretty normal.
Considering its age.
Cisco improved on this with iOS XP,
which is using their modern routers and switches.
It has Linux as the base operating system
and iOS runs as a monolithic application in a container.
There's a link in the description
which explains Cisco's operating systems as calls of all things.
It's actually a really good read.
I recommend having a look.
High end Cisco routers run
iOS Expr, which like Junos, is modular
everything runs in its own protected memory space.
This was, in fact one of Juniper's primary design goals when they created
Juno's separation of modules for stability.
One of the advantages of this is that we can restart certain processes
without restarting the entire device
while we're talking about processes.
Let's look at the common ones.
You can practice with these in the Associated Lab.
First, we have the chassis process called chassis
This runs shortly after boot up and is responsible for bringing the line
cards on line as well as the interfaces in our hardware components
chassis runs on the tree as well as on the PFA.
You'll notice that most
processes end with a D, which is short for Daimon,
which is the traditional Unix name for a process or service.
Next, we have the device control process
DCD, which manages interfaces.
This includes encapsulation timers,
VLANs, IP addresses and so on.
If you have a need to troubleshoot this process,
run show log dcd
the management daymond mgd is used for management traffic.
This includes incoming sage and Telnet requests.
This also handles commands we send to the device
and device configuration.
Avoid the routing protocol.
Daemon manages all routing protocols.
This includes our SPF BGP, ISIS, and ribbon
ARP IDs job includes performing calculations like finding
the shortest path through a network and adding routes to the routing table.
This process is multithreaded and uses scheduling
so it doesn't devote all its time to a single task.
This is important as it can't be allowed to get too busy working on one thing
and then missing routing updates.
Finally, Speedy
manages S&P requests and responses as well as SNMP traps.
There are plenty more processes.
These are just some of the common ones you might come across from time to time.
In fact, let's take a look at them now.
With this command, we can see the name of the process,
the percentage of the CPU that it's using,
as well as some other details
The restart command
lets us restart these processes if we need to.
In this video, you can probably see how an underlying Linux or FreeBSD
operating system affects the philosophy that Juniper has towards their devices.
So we've got a good idea around Juniper's
philosophy on hardware and software architecture.
The next video changes it up a bit and looks at the structure of firewall
filters, components that are used for many functions in Junos.
Click the video here to get started.