You've probably heard about control and data planes before.
Juniper was one of the companies that pioneered these concepts,
and they do an amazing job of putting it into practice.
This video will discuss what these planes are
and how they're used in a practical sense.
So what are the control and data planes To put it simply,
each network device is separated into two logical parts.
One part called the data plane
focuses on forwarding traffic from one location to another.
The other part, called the control plane,
is responsible for managing traffic sent to or from the device.
This includes routing protocol, traffic management, traffic and so on.
This is not unique to our control and data.
Planes are concepts that apply to all modern network devices
When a switch or router is forwarding traffic,
it passes through the data plane, also known as the forwarding plane.
Does this use any special hardware
Sort of, but not exactly.
A plane is a logical concept, which explains how traffic is handled
when traffic comes in a switch, for example,
a likely need to be forwarded out to another location.
This is called transit traffic as it is transiting through the switch.
This traffic is passing through the data plane.
But while devices spend a lot of their time
forwarding transit traffic, that's not all they do.
Routers deal with routing protocol traffic switches respond
to up requests and everything needs to be managed with S.H.
as an MP, HDP, or some other protocol.
These types of traffic are sent to or from a switch, or rather not through it.
This is not transit traffic.
Instead, this is called exception traffic
network devices need to receive process and reply to exception traffic.
This is handled in the control plane.
Sometimes you will hear the term management plane.
This is just referring to the management traffic to or from a device.
This is really just a part of the control plane.
The device uses its CPU to process control plane traffic.
For example, I randomly receive opf traffic from a neighbor.
This is exception traffic
These updates are processed by the routing CPU to determine
the best paths to each network and to update the routing table.
The data plane on the other hand, does
not use the CPU route as an switches will use special hardware
to forward the traffic quickly and efficiently.
Why around is an switch is designed this way.
There are a few reasons.
One is to separate these main functions completely.
If a router gets overwhelmed with traffic and the CPU hits 100%,
the router may not be able to process any more exceptional traffic.
The data plane, however, will still be able to forward transit traffic.
I've actually seen this myself where a switch would continue
passing traffic, but I couldn't edge to it at all.
This was simply because of a failure in the control plane.
The users connected through the switch
were blissfully unaware that there was even an issue.
This operation is something that Juniper seems to pride themselves on.
It was one of their major design goals when they were creating Junos.
We'll see how they've done that in this video and the next
You got a break
from quizzes in the last video, but that's over now.
I would like to stress how important it is
to understand the split between the control plane and the data plane.
And the difference between exception traffic and transit traffic
as you go through the rest of this video.
Please pay close attention to these concepts
Let's start by looking at this.
Rather, it has a few interfaces or ports
package flow into one interface called the Ingress Interface.
And flow out of another interface the egress interface.
Inside the router, we can see that it is divided into two parts.
One is called the routing engine or RC, which handles exception traffic.
The other is the packet forwarding engine, or PFI,
which handles transit traffic
The other is a component that handles control plane traffic.
The PFA is a data plane.
The PFA is, practically speaking,
the line cards that contain interfaces where our cables are connected
in a Juniper system, they called PHP, CS
or flexible peak concentrators
Fix may be built into a switch or router, or there may be a separate module
that has been added to increase the number of available ports.
More accurately
The PSA includes not only the line card, but also includes
the firmware that controls it, package that transit the device
ingress and egress through the PFA
There is likely to be more than one NPC in a system
inside the switch.
These are connected through a switch fabric,
a packet may ingress on a port, be forwarded across the fabric
to a new FBC and egress out another port.
So the data plan includes
the feces as well as the internal fabric that connects them.
Can you see how the data plane is isolated from the control plane here?
The RC has a few tasks.
One of these is to run Junos.
The ARIA contains the Junos Kernel and runs the processes
that manage chassis resources.
We'll take a look at
the processes in the next video.
So we can see that another task of the ARIA
is to manage the chassis, which includes monitoring its health.
This includes checking temperature, band
speed, alarms, packet counters and so on.
It also has a two way relationship with the PFA.
For one, the PFA provides it with raw data,
enabling it to monitor things like packet counters and errors.
But also the RB needs to manage the PFA, including pushing microcode down
to the pieces and making sure as an up to date copy of the forwarding table.
And of course, the routing engine needs to live up to its name
by participating in routing protocols, building the routing table
and maintaining the forwarding table.
We'll see more of that soon.
You might be familiar with the term supervisor as used by other vendors.
This is roughly the same thing as the routing engine.
Larger devices will have two routing engines for backup
as well as to support in-service software upgrade.
This is a way of updating Junos without impacting traffic flow.
There's more on this in this study notes.
If you're interested
Modern routers have advanced this concept of control.
Plane and data plane split considerably.
It improves performance,
but sometimes it can blur the lines between the two planes.
The Army is generally responsible for handling exception traffic
that is traffic sent to or from the router.
Traffic would arrive at an ingress interface
flow through the PC and up to the ARI.
The Army would process the traffic if it needs to respond
It will send the traffic back to the PFI,
which will forwarded out the egress interface.
Now consider this example.
Traffic arrives at the router for the router, does not have a route
for this traffic and therefore can't forward the traffic.
The router would then need to create and send
an ICMP message back to the sender
as this traffic comes from the router itself.
You would think this is handled by the IRS.
However, on a modern Juniper router,
this function is offloaded to the PFA.
This lightens the load on the three other features that are offloaded
to the PFA include quality of service, policing
and stateless firewall filtering
There's something interesting about the way that the R.A.
and PFA interact.
If you're completely new to Juniper, this might seem a bit foreign
inside there and there is a special link that connects
the hardware to the hardware.
This comes with a special interface which on an Amex router is called one
Other
platforms might call it E-m1 or some other name.
For the purposes of this video.
We'll just call it P1.
This acts as a small switch between
the ARI and PFA components.
When the PFA needs to send exceptional traffic to the ARI,
he will send it over this interface
Transit traffic will not pass over this interface.
The bigger systems that have to Ari's will have to interfaces
f exp one and b two.
Oh and don't get these mixed up with XP zero,
which is a management interface.
We do not need to configure XB one at all.
We don't need to configure IP addresses, unit numbers, families, or any of it.
This is all managed internally by Junos
This link has a built in right limiter.
This limits how much traffic can be pushed from the PFA to the ARI.
This limiter is here as a protection against denial of service attacks.
We can't configure the right limiter ourselves.
However, we can create our own firewall filter to further limit traffic to the Ari
For example, we might apply a filter to allow BGP traffic from known peers,
but deny BGP traffic from any other peer.
We'll take a look at firewall filters in video 18.
This leads us into you considering how routing
and forwarding works with a split between the RC and the
routing information such as oh, SPF
or BGP comes from neighbor routes.
This is an example of exception traffic
and needs to be handled by the R.A..
The IRS will take this information along with static,
connected and local routes, and it will build the routing table.
The routing table also known as the routing information base
or rib, contains valid routes to reach destination networks.
This is maintained by the R.E.,
so you can think of the routing table as part of the control plane
The ARI will take all the best routes
from the routing table and will use them to build the forwarding table.
The forwarding table is also known as the forwarding
information base or fib.
The ARI will push a copy
of the boarding table to the PFA using this table.
The PFA can make forwarding decisions for transit traffic
without consulting the ARI.
We can see then that the forwarding table is part of the data plane.
Do you see the distinction between the routing table and the forwarding table?
The routing table contains all valid routes and is stored in the array.
The boarding table contains the best routes.
Any stored in both the R-E and the PFA.
The following table is more than just layer three routes, though
it also contains Layer two and Layer one information.
This is so the PFA knows which destination Mac
and interface to use for egress traffic.
This model, along with specialized hardware,
makes forwarding very fast
How did you go with the control plane and data plane concepts?
Do you understand how the NPF is fit into the larger picture?
It was challenging to create a hub for this video, but if you're interested,
head over to the member section of the website and check it out.
Do you notice a bit different
under the hood compared to, say, Cisco's iOS?
It uses an entirely different approach to operating system design.
Click the video shown here to learn more.