DevOps Intro to Junos

In this lesson we’re going to be doing an introduction to the Junos OS. Talking about the architecture of Junos and giving a configuration crash course for Juniper Devices. Now this lesson is really for you if you haven’t touched Juniper devices in quite some time, or if you don’t have your JNCIA-Junos certification yet.

I do really recommend that you take my JNCIA-Junos course first before attempting the JNCIA-DevOps, however if you haven’t yet it’s no problem. This lesson in particular is my attempt to give you a crash course in everything you need to know for being able to speak the same language and terminology and have a good overview of Juniper devices so that we can really get running into the JNCIA-DevOps.

First up, with Junos OS is a Unix-based operating system, specifically using the FreeBSD flavor of Unix. Using Unix allows us to split our software processes into various daemons. These separate processes allow for a segregation of tasks, which shields each process from one another in their own separate memory and execution space. What this really helps us with is, if any problem happens with one of these processes it is unlikely to affect the other processes. If our SNMP process runs into an issue, or our routing protocol process runs into an issue, it’s unlikely that it will cause issues with other processes on the box.

The other thing that is enabled by using Unix-based FreeBSD is that we have the same source code base on all of our juniper platforms. Where this is very helpful to you as the administrator, is that it allows for our maintenance and setup tasks to remain largely similar from device to device. Whether you’re using an SRX branch office router, or an MX480 data center router, your management or maintenance and setup tasks will be largely similar between those devices.

Routing Engine Vs. Packet Forwarding Engine

Our Juniper devices are architecturally split cleanly in two. We have very distinct control and forwarding planes, and where these concepts manifest themselves is in the Routing Engine (RE) and Packet Forwarding Engine (PFE).

First, let’s take a look at this diagram here. The things I want to point out are that we have our packet forwarding engine on the bottom and our routing engine on the top. This is a conceptual diagram for how Junos organizes its management capabilities and its segregation of tasks when it comes to routing and packet forwarding. Our Routing Protocol Daemon (rpd) which is what handles our dynamic routing protocols and also handles updates to our routing table, is running in the Routing Engine.

Among running the rpd, the RE is also responsible for maintaining both the routing and forwarding tables, providing the user interface and configuration management, controlling and monitoring the chassis and managing the PFE. So let’s look at each of these a little closer.

Maintaining the routing and forwarding tables:

We already mentioned our routing table (RT) is built by our rpd. Now, the routing table can have static routes that are configured by us the administrators, or it can also have routes that are learned dynamically from routing protocols. Our routers on the network talking to each other and exchanging routing information. From our routing table, it derives our forwarding table (FT). The FT is really a much more refined version of our routing table. It stores information like our exit interface, our next hop information of both the IP address and MAC address, as well as the type of action that’s taken for certain destinations be it to forward or to drop or to reject.

Our master copy of the forwarding table lives up in our RE which will then copy that forwarding table down to our PFE, which uses the forwarding table to forward transit traffic.

Transit traffic is never destined for the local device

What else does the RE do? We did mention here that it provides user interface and configuration management, our mgd, which is our management daemon, lives up in our RE as well. This daemon is what provides management interfaces for our device, our Command Line Interface (CLI) runs up on the RE and interacts with the mgd. The mgd also applies our candidate or active configuration to our device, and sends the messages to our other demons that control our device, like the chassisd daemon which controls the physical chassis.

Our RE controls and monitors the chassis, if you have an LCD screen on the front of your router where it shows you perhaps which unit number your device is or has other status indicators, then these are things that are controlled by your RE. The RE is also responsible for bringing interfaces online or bringing different Flexible PIC Concentrators (FPCs) online, which we’re discuss more later this lesson.

What is arguably the most important responsibility of the RE is it manages the PFE. The RE copies our forwarding table updates as well as programs other types of policies into our PFE to be implemented at that section of the device.

The PFE uses the Layer 2 and Layer 3 forwarding tables provided by the RE to forward traffic as fast as possible. That is the primary responsibility of the PFE. Some other policies as well are implemented at the PFE, like policing, stateless firewalling and queueing or prioritization of traffic for Class of Service or Quality of Service.

Transit and Exception Traffic

The PFE handles transit traffic mostly. So, what is transit traffic really, and how does that differ from exception traffic?

Transit traffic by definition is traffic handled by the PFE in its entirety. Transit traffic is never seen by the RE, it is traffic that comes in on an interface to our Juniper device and leaves either the same or another interface on our Juniper device. It does not require additional processing by the RE, it is never destined for our local device, and it is has an entry in our forwarding table which can be handled entirely by our PFE.

Where this differs from exception traffic is that exception traffic is traffic that can be destined for the router itself, or traffic that requires additional processing in some way. VPN traffic that needs to be decrypted can be exception traffic, along with much traffic destined for the router itself.

Some examples of traffic destined for our router itself that is exception traffic is management traffic, things like our SSH sessions, Telnet sessions and SNMP polling are exception traffic. Pings that are destined for our device our exception traffic, they will come in and be destined for our device itself and the responses will be generated by our RE. Our routing protocols, OSPF and BGP and others, these routing protocol packets from the network as we see on the diagram is also exception traffic.

The connection between our PFE and our RE is actually an internal ethernet connection, and that internal ethernet connection is rate limited to protect the RE. You can imagine a situation where someone purposefully sends a whole bunch of exception traffic to your device, that may be for the purpose of denying you management access. If they flood that connection so heavily you might not be able to get your SSH and Telnet through, and more than that you could bring down your whole device without being able to handle all of this exception traffic. So, it is rate limited for the purpose of protecting our RE.

Logging In

Let’s move a little bit into the management aspect of our devices. First up is our command line interface, the CLI, and specifically logging in.

There are two different primary ways to log in, logging in as a root user versus logging in as a non-root user. Logging in as a root user there are a couple things that you’ll notice about this. First, you will be placed directly into the BSD shell. This we in our screenshot above, that we have our @: prompt, that this is our FreeBSD shell prompt. The ~ here indicates we are at our home directory within the Unix shell.

Your underlying Unix commands are accessible here, things like top for viewing the current processes that are running, mkdir to create a directory on the underlying file system, mount for mounting some external file system, cat which is to display a file’s contents, etc.

These Unix commands are accessible here though none of our routing or switching or security operations are done here. In order to interact with our routing functions, we need to enter the CLI of our Junos OS, and to enter the cli we use the cli command press enter, as shown in the above screenshot.

The > prompt shows we are in operational mode, we’ll get more into the cli modes a little later, but we can see through this greater than sign or carrot that we are at our operational mode.

When you log in as a non-root user, you are placed directly into the cli, at Operational mode. Here, we log into test-router and we are logging in as ‘ben’ user, so that is a non-root user, and we see our initial splash here of the version of the OS we’re running and we are placed directly into operational mode as we can see with the greater than sign, the > prompt.

We can still get into the BSD shell from our cli when you’re logging in as a non-root user, and this is done with the start shell command, and then we see the % prompt that tells us we are now at the BSD shell.

CLI Modes

There are specifically two modes to our CLI, the first we mentioned is the operational mode. This mode allows for monitoring and troubleshooting of the device. This is where your show commands are all given, as well as your request system commands. This is where you would reboot your device, or bring other cards online and run your show commands to gather information about the current state of your device. This mode is indicated by your angle bracket prompt >, your carrot or greater than sign. That is how you can easily determine that the CLI is currently in operational mode.

The second mode is edit mode or configuration mode. It’s officially named configuration mode, though some call it edit mode due to the [edit] prompt that you get. You can use the command edit instead of configure to be able to enter the edit mode or configuration mode as well.

This mode is determined by having our hash # prompt.

You can run operational mode commands from edit mode, by using the first keyword run before your show command. If in operational mode I’d enter show interfaces, then in edit mode I’d enter run show interfaces.

However, if I just enter show interfaces from my edit mode, that is going to try to show me the interfaces section of the configuration hierarchy, rather than actually run the show interfaces operational mode command.

Active and Candidate Configuration

So, talking about configuration mode, this is where we edit our device configuration. Juniper presents the configuration as the active and candidate configuration. If you’re familiar with Cisco or other vendor devices, you may be used to the idea of putting in commands and having the configuration change take effect immediately. That is not the case with juniper devices, as we have this active vs. candidate configuration.

The candidate configuration has not yet been committed. When you commit the candidate configuration, it becomes the active configuration. The candidate configuration is not yet active on the device, and when entering configuration mode we are reminded of this if uncommitted changes are present, as shown in the screenshot above.

This happens if the candidate configuration has been changed, and you left edit mode and then came back in. It will remind you to help avoid committing unintended changes.

The candidate configuration has no effect until it has been committed. When changes are committed, all changes are committed at once. This can be a saving grace sometimes. I know I personally have run into situations where I need to do certain configuration changes that will end up cutting me off from management access and bring it back again. With Cisco devices my only real option is to physically be present.

So, the Active configuration, as you may have realized, is the currently running configuration. It is what is currently running and has been previously committed, or is the default configuration. If you’re turning on your device brand new from the factory, you will load a default configuration, so that is the active configuration as opposed to the first time you commit something, which would then be the active configuration.

Working with Junos Configurations

There are multiple ways of viewing your configuration. In the screenshot above we see the default hierarchical display. This uses braces { } and semicolons ; to denote configuration sections. This can be nice for seeing the hierarchical relationship of the configuration, though can be difficult to read when there are many lines of this. I personally like to read configuration in set display, as shown below.

Not only is there hierarchical and set display, you can also view configuration text in XML, and as of Junos 14.2 we can also display in JSON. We’ll go over JSON structure and syntax in a later lesson.

Each of these output formats are equivalent, representing the same information. display set is an output modifier, applied by using a pipe | after the command. With the set display, you can copy these set commands and paste them directly in at the top of the configuration hierarchy in edit mode and be able to apply the same configuration on a different device, or on the same device! I will often do this when I am saving a configuration text to apply during a maintenance window at a later time. I’ll apply the needed configuration to the candidate configuration, do a show | display set and copy that to save for applying during a maintenance window at a later time.

Since we do have a commit model for our configuration database, we have the ability to roll back to a previous commit. We have listed here our various rollbacks to our commits, something that you’ll want to get very used to if you’re not already is the question mark (?) command which gives us our contextual help, as is common among many vendor devices.

We can store up to 50 previously committed configurations, and something important is that with Juniper devices almost everything is ‘zero indexed’, which means the first item will always be the 0th item. We can roll back our candidate configuration to a previous commit by doing a rollback # command in edit mode, replacing # with the number of the previous commit. This will load that previously committed configuration into our candidate configuration and from there we can apply it if we wish by doing a commit.

Entering rollback 0 would be applying our currently active configuration as the candidate configuration. Why would you want to do this? Well if you want to eliminate or delete your current changes to the candidate configuration, this is a good way to go back to your currently active configuration. rollback 1 would load the configuration from one commit ago, rollback 2 would be two commits ago, etc.

We can view the difference between our candidate configuration and our currently active configuration through the show | compare command. Piping the compare output modifier will give a display of the delta or diff of the candidate configuration in reference to the active configuration. Lines which appear in the active configuration and not in the candidate will have a minus sign next to them, and lines added in the candidate which are not in the active will have a plus sign next to them.

Network Interfaces

Let’s take a look at network interfaces on our device. A quick way to verify the state of your network interfaces is with the show interfaces terse command. You can leave this as just show interfaces terse, and that will give you the status of all of your interfaces, or we can specify a particular interface or range of interfaces.

This will give you information like the interface name and logical unit number, the administrative status as to whether it is enabled or not, the link status as to whether you have link lights, meaning your layer one or two connectivity is up. This also includes protocols that are running on the interface like IPv4 and IPv6, denoted by inet and inet6, the local addresses assigned to that interface.

The ge-0/0/1 interface name, what does this really mean?

First, ge is the interface type, some interface types are:

Interface Name Prefix	Interface Speed / Type
fe-	Fast Ethernet (100Mbps)
ge-	Gigabit Ethernet (1Gbps)
xe-	Ten Gigabit Ethernet (10Gbps)
et-	One Hundred Gigabit Ethernet (100Gbps)

The numbers after the name prefix follow the format of:

FPC / PIC / Port . Unit

For example, ge-1/0/2.40 would be the gigabit interface on FPC 1, PIC 0, port 2, and the logical unit 40 configured on that interface.

Our logical unit is just that, a logical construct. It is something that we the network administrators configure, whereas everything else here is something physical.

So that should be enough of a rundown to have the Junos basics to work through the JNCIA-DevOps. If you’re interested to go into Junos in more depth, please take a look at our JNCIA-Junos course!