Juniper MX Series

Junos

Junos is a purpose-built networking operating system based on one of the most stable and secure operating systems in the world: FreeBSD. Junos is designed as a monolithic kernel architecture that places all of the operating system services in the kernel space. Major components of Junos are written as daemons that provide complete process and memory separation.

One of the benefits of monolithic kernel architecture is that kernel functions are executed in supervisor mode on the CPU while the applications and daemons are executed in user space. A single failing daemon will not crash the operating system or impact other unrelated daemons. For example, if there was an issue with the SNMP daemon and it crashed, it wouldn’t impact the routing daemon that handles OSPF and BGP.

One Junos

Creating a single network operating system that’s able to be leveraged across routers, switches, and firewalls simplifies network operations, administration, and maintenance. Network operators need only learn Junos once and become instantly effective across other Juniper products. An added benefit of a single Junos is that there’s no need to reinvent the wheel and have 10 different implementations of BGP or OSPF. Being able to write these core protocols once and then reuse them across all products provides a high level of stability, as the code is very mature and field tested.

Software Releases

Every quarter for nearly 15 years there has been a consistent and predictable release of Junos. The development of the core operating system is a single release train. This allows developers to create new features or fix bugs once and share them across multiple platforms.

The release numbers are in a major and minor format. The major number is the version of Junos for a particular calendar year and the minor release indicates which quarter the software was released. This happens to line up nicely for Junos 11 and Junos 12 as they directly tied the year released. For example, Junos 11 was released in 2011.

This wasn’t always the case. Before Junos 10.1, the major release didn’t line up to the year released. Historically, the “.0” release was reserved for major events such as releasing software for new products like the MX240 with Junos 9.0.

Each release of Junos is supported for 18 months. The last release of Junos in the calendar year is known as the Extended End of Life (EEOL), and this release is supported for 36 months.

Figure 1-1. Junos release model

There are a couple of different types of Junos that are released more frequently to resolve issues: maintenance and service releases. Maintenance releases are released about every six weeks to fix a collection of issues and they are prefixed with “R.” For example, Junos 11.1R2 would be the second maintenance release for Junos 11.1. Service releases are released on demand to specifically fix a critical issue that has yet to be addressed by a maintenance release. These releases are prefixed with a “S.” An example would be Junos 11.1S2.

The general rule of thumb is that new features are added every minor release and bug fixes are added every maintenance release. For example, Junos 11.1 to 11.2 would introduce new features, whereas Junos 11.1R1 to 11.1R2 would introduce bug fixes.

Most production networks prefer to use the last Junos release of the previous calendar year; these Junos releases are EEOL releases that are supported for three years. The advantage is that the EEOL releases become more stable with time. Consider that 11.1 will stop providing bug fixes after 18 months, while 11.4 will continue to have bug fixes for 36 months.

Three Release Cadence

In 2012, Junos created a new release model to move from four releases per year to three. This increased the frequency of maintenance releases to resolve more issues more often. The other benefit is that all Junos releases as of 2012 are supported for 24 months, while the last release of Junos for the calendar year will still be considered EEOL and have support for 36 months.

Table 1-1. Junos End of Engineering and End-of-Life schedule

Release	Target	End of Engineering	End of Life
Junos 12.1	March	24 months	+ 6 months
Junos 12.2	July	24 months	+ 6 months
Junos 12.3	November	36 months	+ 6 months

By extending the engineering support and reducing the number of releases, network operators should be able to reduce the frequency of having to upgrade to a new release of code.

Figure 1-2. New 2012 Junos three-release candidate

With the new Junos three-release cadence, network operators can feel more confident using any version of Junos without feeling pressured to only use the EEOL release.

Software Architecture

Junos was designed from the beginning to support a separation of control and forwarding plane. This is true for the MX Series, where all of the control plane functions are performed by the routing engine while all of the forwarding is performed by the packet forwarding engine (PFE). Providing this level of separation ensures that one plane doesn’t impact the other. For example, the forwarding plane could be routing traffic at line-rate and performing many different services while the routing engine sits idle and unaffected.

Control plane functions come in many shapes and sizes. There’s a common misconception that the control plane only handles routing protocol updates. In fact, there are many more control plane functions. Some examples include:

• Updating the routing table

• Answering SNMP queries

• Processing SSH or HTTP traffic to administer the router

• Changing fan speed

• Controlling the craft interface

• Providing a Junos micro kernel to the PFEs

• Updating the forwarding table on the PFEs

Figure 1-3. Junos software architecture

At a high level, the control plane is implemented entirely within the routing engine while the forwarding plane is implemented within each PFE using a small, purpose-built kernel that contains only the required functions to route and switch traffic.

The benefit of control and forwarding separation is that any traffic that is being routed or switched through the router will always be processed at line-rate on the PFEs and switch fabric; for example, if a router was processing traffic between web servers and the Internet, all of the processing would be performed by the forwarding plane.

Daemons

The Junos kernel has four major daemons; each of these daemons play a critical role within the MX and work together via Interprocess Communication (IPC) and routing sockets to communicate with the Junos kernel and other daemons. The following daemons take center stage and are required for the operation of Junos.

• Management daemon (mgd)

• Routing protocol daemon (rpd)

• Device control daemon (dcd)

• Chassis daemon (chassisd)

There are many more daemons for tasks such as NTP, VRRP, DHCP, and other technologies, but they play a smaller and more specific role in the software architecture.

Management Daemon

The Junos User Interface (UI) keeps everything in a centralized database. This allows Junos to handle data in interesting ways and open the door to advanced features such as configuration rollback, apply groups, and activating and deactivating entire portions of the configuration.

The UI has four major components: the configuration database, database schema, management daemon (mgd), and the command line interface (cli).

The management daemon (mgd) is the glue that holds the entire Junos User Interface (UI) together. At a high level, mgd provides a mechanism to process information for both network operators and daemons.

The interactive component of mgd is the Junos cli; this is a terminal-based application that allows the network operator an interface into Junos. The other side of mgd is the extensible markup language (XML) remote procedure call (RPC) interface; This provides an API through Junoscript and Netconf to allow for the development of automation applications.

The cli responsibilities are:

• Command-line editing

• Terminal emulation

• Terminal paging

• Displaying command and variable completions

• Monitoring log files and interfaces

• Executing child processes such as ping, traceroute, and ssh

mgd responsibilities include:

• Passing commands from the cli to the appropriate daemon

• Finding command and variable completions

• Parsing commands

It’s interesting to note that the majority of the Junos operational commands use XML to pass data. To see an example of this, simply add the pipe command display xml to any command. Let’s take a look at a simple command such as show isis adjacency.

{master}
dhanks@R1-RE0> show isis adjacency
Interface             System         L State        Hold (secs) SNPA
ae0.1                 R2-RE0         2  Up                   23

So far everything looks normal. Let’s add the display xml to take a closer look.

{master}dhanks@R1-RE0> show isis adjacency | display xml
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/11.4R1/junos">
    <isis-adjacency-information xmlns="http://xml.juniper.net/junos/11.4R1/junos-routing"
      junos:style="brief">
        <isis-adjacency>
            <interface-name>ae0.1</interface-name>
            <system-name>R2-RE0</system-name>
            <level>2</level>
            <adjacency-state>Up</adjacency-state>
            <holdtime>22</holdtime>
        </isis-adjacency>
    </isis-adjacency-information>
   <cli>
        <banner>{master}</banner>
    </cli>
</rpc-reply>

As you can see, the data is formatted in XML and received from mgd via RPC.

Routing Protocol Daemon

The routing protocol daemon (rpd) handles all of the routing protocols configured within Junos. At a high level, its responsibilities are receiving routing advertisements and updates, maintaining the routing table, and installing active routes into the forwarding table. In order to maintain process separation, each routing protocol configured on the system runs as a separate task within rpd. The other responsibility of rpd it to exchange information with the Junos kernel to receive interface modifications, send route information, and send interface changes.

Let’s take a peek into rpd and see what’s going on. The hidden command set task accounting toggles CPU accounting on and off. Use show task accounting to see the results.

{master}
dhanks@R1-RE0> set task accounting on
Task accounting enabled.

Now we’re good to go. Junos is currently profiling daemons and tasks to get a better idea of what’s using the routing engine CPU. Let’s wait a few minutes for it to collect some data.

OK, let’s check it out:

{master}
dhanks@R1-RE0> show task accounting
Task accounting is enabled.

Task                       Started    User Time  System Time  Longest Run
Scheduler                      265        0.003        0.000        0.000
Memory                           2        0.000        0.000        0.000
hakr                             1        0.000            0        0.000
ES-IS I/O./var/run/ppmd_c        6        0.000            0        0.000
IS-IS I/O./var/run/ppmd_c       46        0.000        0.000        0.000
PIM I/O./var/run/ppmd_con        9        0.000        0.000        0.000
IS-IS                           90        0.001        0.000        0.000
BFD I/O./var/run/bfdd_con        9        0.000            0        0.000
Mirror Task.128.0.0.6+598       33        0.000        0.000        0.000
KRT                             25        0.000        0.000        0.000
Redirect                         1        0.000        0.000        0.000
MGMT_Listen./var/run/rpd_        7        0.000        0.000        0.000
SNMP Subagent./var/run/sn       15        0.000        0.000        0.000

Not too much going on here, but you get the idea. Currently, running daemons and tasks within rpd are present and accounted for.

Warning

The set task accounting command is hidden for a reason. It’s possible to put additional load on the Junos kernel while accounting is turned on. It isn’t recommended to run this command on a production network unless instructed by JTAC. After your debugging is finished, don’t forget to turn it back off with set task accounting off.

Don’t forget to turn off accounting.

{master}
dhanks@R1-RE0> set task accounting off
Task accounting disabled.

Device Control Daemon

The device control daemon (dcd) is responsible for configuring interfaces based on the current configuration and available hardware. One feature of Junos is being able to configure nonexistent hardware, as the assumption is that the hardware can be added at a later date and “just work.” An example is the expectation that you can configure set interfaces ge-1/0/0.0 family inet address 192.168.1.1/24 and commit. Assuming there’s no hardware in FPC1, this configuration will not do anything. As soon as hardware is installed into FPC1, the first port will be configured immediately with the address 192.168.1.1/24.

Chassis Daemon (and Friends)

The chassis daemon (chassisd) supports all chassis, alarm, and environmental processes. At a high level, this includes monitoring the health of hardware, managing a real-time database of hardware inventory, and coordinating with the alarm daemon (alarmd) and the craft daemon (craftd) to manage alarms and LEDs.

Figure 1-4. Juniper MX960 craft interface

It should all seem self-explanatory except for craftd; the craft interface that is the front panel of the device. Let’s take a closer look at the MX960 craft interface.

The craft interfaces is a collection of buttons and LED lights to display the current status of the hardware and alarms. Information can also be obtained.

dhanks@R1-RE0> show chassis craft-interface

Front Panel System LEDs:
Routing Engine    0    1
--------------------------
OK                *    *
Fail              .    .
Master            *    .

Front Panel Alarm Indicators:
-----------------------------
Red LED      .
Yellow LED   .
Major relay  .
Minor relay  .

Front Panel FPC LEDs:
FPC    0   1   2
------------------
Red    .   .   .
Green  .   *   *

CB LEDs:
 CB    0   1
--------------
Amber  .   .
Green  *   *

PS LEDs:
  PS   0   1   2   3
--------------------
Red    .   .   .   .
Green  *   .   .   .

Fan Tray LEDs:
  FT   0
----------
Red    .
Green  *

One final responsibility of chassisd is monitoring the power and cooling environmentals. chassisd constantly monitors the voltages of all components within the chassis and will send alerts if the voltage crosses any thresholds. The same is true for the cooling. The chassis daemon constantly monitors the temperature on all of the different components and chips, as well as fan speeds. If anything is out of the ordinary, chassisd will create alerts. Under extreme temperature conditions, chassisd may also shut down components to avoid damage.

Routing Sockets

Routing sockets are a UNIX mechanism for controlling the routing table. The Junos kernel takes this same mechanism and extends it to include additional information to support additional attributes to create a carrier-class network operating system.

Figure 1-5. Routing socket architecture

At a high level, there are two actors when using routing sockets: state producer and state consumer. The rpd daemon is responsible for processing routing updates and thus is the state producer. Other daemons are considered state consumers because they process information received from the routing sockets.

Let’s take a peek into the routing sockets and see what happens when we configure ge-1/0/0.0 with an IP address of 192.168.1.1/24. Using the rtsockmon command from the shell will allow us to see the commands being pushed to the kernel from the Junos daemons.

{master}
dhanks@R1-RE0> start shell
dhanks@R1-RE0% rtsockmon -st
        sender    flag   type       op
[16:37:52] dcd      P    iflogical  add     ge-1/0/0.0 flags=0x8000
[16:37:52] dcd      P    ifdev      change  ge-1/0/0 mtu=1514 dflags=0x3
[16:37:52] dcd      P    iffamily   add     inet mtu=1500 flags=0x8000000200000000
[16:37:52] dcd      P    nexthop    add     inet 192.168.1.255 nh=bcst
[16:37:52] dcd      P    nexthop    add     inet 192.168.1.0 nh=recv
[16:37:52] dcd      P    route      add     inet 192.168.1.255
[16:37:52] dcd      P    route      add     inet 192.168.1.0
[16:37:52] dcd      P    route      add     inet 192.168.1.1
[16:37:52] dcd      P    nexthop    add     inet 192.168.1.1 nh=locl
[16:37:52] dcd      P    ifaddr     add     inet local=192.168.1.1
[16:37:52] dcd      P    route      add     inet 192.168.1.1 tid=0
[16:37:52] dcd      P    nexthop    add     inet nh=rslv flags=0x0
[16:37:52] dcd      P    route      add     inet 192.168.1.0 tid=0
[16:37:52] dcd      P    nexthop    change  inet nh=rslv
[16:37:52] dcd      P    ifaddr     add     inet local=192.168.1.1 dest=192.168.1.0
[16:37:52] rpd      P    ifdest     change  ge-1/0/0.0, af 2, up, pfx 192.168.1.0/24

Note

The author configured the interface ge-1/0/0 in a different terminal window and committed the change while the rtstockmon command was running.

The command rtsockmon is a Junos shell command that gives the user visibility into the messages being passed by the routing socket. The routing sockets are broken into four major components: sender, type, operation, and arguments. The sender field is used to identify which daemon is writing into the routing socket. The type identifies which attribute is being modified. The operation field is showing what is actually being performed. There are three basic operations: add, change, and delete. The last field is the arguments passed to the Junos kernel. These are sets of key and value pairs that are being changed.

In the previous example, you can see how dcd interacts with the routing socket to configure ge-1/0/0.0 and assign an IPv4 address.

• dcd creates a new logical interface (IFL).

• dcd changes the interface device (IFD) to set the proper MTU.

• dcd adds a new interface family (IFF) to support IPv4.

• dcd sets the nexthop, broadcast, and other attributes that are needed for the RIB and FIB.

• dcd adds the interface address (IFA) of 192.168.1.1.

• rpd finally adds a route for 192.168.1.1 and brings it up.

Warning

The rtsockmon command is only used to demonstrate the functionality of routing sockets and how daemons such as dcd and rpd use routing sockets to communicate routing changes to the Junos kernel.