JUNOS OS For Dummies

Part I

Discovering Junos OS

In this part . . .

You know that nuclear reactor thingy that Robert Downey in the Iron Man movie put in this chest to power his rocket books and extraordinary powers? Well, that’s what Junos is to Juniper Networks devices.

This part introduces the Junos OS that is used for switching, routing, MPLS, and security. It also includes a section on migrating from other platforms. You find out all about Junos and how you can power your network at speeds way past the sound barrier.

Chapter 1

Junos Is Everywhere You Need to Be

In This Chapter

arrow Understanding the functions of a network operating system

arrow Discovering how Junos OS is different

arrow Looking beyond the operating system to the Junos Platform

The Junos operating system (Junos OS) is the software that runs networking and security devices from Juniper Networks. Administrators use Junos OS to set up devices and connect them together in a network, and dictate how the devices move, service, and secure traffic across the network. They also use it to monitor and, when necessary, restore the network.

Note: In this book, we use both Junos OS and Junos as one and the same.

This chapter introduces Junos OS by describing the functions of a network operating system and then discussing how they work in Junos. The chapter also explores key differences in how Juniper develops Junos software versus how other vendors create their network operating systems, and introduces additional components of the Junos portfolio.

Functions of a Network OS

Networks consist of specialized devices that pass along traffic from one to another. Each device must know what to do with each arriving bundle of traffic, or packet, so that the packet can continue its journey to its destination. The devices perform three primary functions to process each packet:

check.png Controls where the device sends the packets.

check.png Applies services such as prioritization or security.

check.png Forwards the packet to the next connecting device.

These actions are the primary functions of the network operating system that runs on the device. In simplest terms, the control plane of the network operating system is the brain of the device with the forwarding plane providing the brawn to quickly move packets through the system. Depending on the type of packet, the services plane may also provide packet services such as address translation, prioritization, and security.

Control functions

This essential map for connectivity, security, and other orchestrating processes is the function of the network operating system’s control plane. The processes and information of the control plane must provide answers to two essential questions:

check.png How does the network direct the delivery of packets from one place to another? In other words, what are the routes or paths to establish, how do they change, and how does each device know which route to use for each packet?

check.png What does the network do with each of the packets along its journey? In other words, what are the handling rules, or policies, along with the security and services plane established for traffic delivery?

Although the questions can be simply stated, the possible responses are virtually limitless. You can define dozens and dozens of protocols to answer these questions for different types of network maps and all the different types of traffic, not to mention how the control plane monitors and manages everything. The many processes to control the network delivery of packets fill the industry with all those three- and four-letter acronyms that you’ve somehow managed to file into your memory.

Service functions

The service needs of users grow with new applications triggering new requirements for quality, security, addressing, and content delivery, among others. Applying the specialized processing is the role of the services plane.

For example, as the packets flow through each device, the devices must typically apply a range of filters, policies, and services for protecting the network (and its clients and applications) and assigning priorities for the use of its resources. Visualize watching a YouTube video. Now visualize all your users watching the video all at the same time because some clown in your office passed along an e-mail with the link to everyone. And now think about all the traffic hitting your network all at once, just as your president is on a critical call with your biggest customer. Oofta!

This is just one example of where you may want to define a few of those extra rules that your network can follow in making its packet deliveries. (We provide Chapter 15 to help you set up class of service in your devices.)

Forwarding functions

Along with assembling the intelligence to properly deliver the traffic from one place to another and applying services, the network operating system (and its hardware) must actually deliver packets to the correct destination using this intelligence. Moving packets through a networking device is the function of the network operating system’s forwarding plane, also sometimes known as the data plane.

Packet forwarding takes care of the handling required to move each packet quickly from its inbound device interface to the proper outbound interface(s). For large networking devices that carry terabits of traffic, this handling must occur at an ultra-über fast rate to maintain the high packet throughput of the machines.

Taking Advantage of One Network OS

Network operating systems have a lot do and can have a big impact on the performance, ease of operations, reliability, and security of your network. Junos OS is different, in that it’s one operating system. But why does having one operating system matter?

One operating system means the Juniper engineers build upon the same set of code and then share this code, as appropriate, across all the platforms running Junos. For example, enterprise platforms use the same hardened implementation of the routing protocol Open Shortest Path First (OSPF) that has been running in large service provider networks for many years. It’s not a different code set, but the same one. (To set up OSPF, see Chapter 10.)

So, if your responsibilities include administrating the network, you find that many features are configured and managed in the same way on the different platforms, whether they are routers, switches, or security devices. One operating system, therefore, saves you time, potentially lots of it, in everything from training to setup to ongoing operations. Also, if you plan changes in the network, one operating system can save you time there, too. With far less variation to evaluate, test, and deploy, it’s less effort for feature roll out, software upgrades, and other network modifications.

Taking a Peek Inside the Junos OS

How engineers design a network operating system impacts the reliability, security, scalability and performance of not just the devices, but also the overall network, particularly in large-scale systems. The operating system must handle the many different processes essential to running today’s global networks, while also assuring fair sharing of resources so that no process or service can starve out others.

World-class architecture

The architecture of the Junos operating system cleanly divides the functions of control, services, and forwarding into different planes. The control and services planes include many different processes that run in different modules of the operating system. The explicit division of responsibility allows the software to run on different engines of processing, memory, and other resources. This division of labor is what enables Junos to run all types of platforms in all matter of sizes, from a small box in a home office to the largest boxes in the world handling terabits of data every second.

Figure 1-1 provides a high-level view of the Junos OS software architecture with its three functional processing planes. Shown above the dashed line is the control plane that runs on what is known as the Routing Engine (RE) of the Juniper device. Below the dashed line is the packet forwarding plane, which runs on a separate Packet Forwarding Engine (PFE) in larger Juniper platforms. The services plane, which provides specialized processing, such as for quality classification and security, is on the right.

Figure 1-1: Architecture of the Junos OS.

Do you want faster platforms in your network? That’s like asking if you’d like to have today off (with pay, of course). Yes, it would be good to have the network go a little faster. Faster, faster, faster is a constant drumbeat for networks. In over ten years of product delivery, Juniper has scaled the throughput of its fastest devices from 40GB per second to multiple terabits per second with a fast expanding set of services. The use of separate processors for the RE, the PFE, and services cards has been the essential architecture element to each performance breakthrough. In particular, separation lets the PFE and services throughput follow in lock-step with the increasing speeds of the custom Application-Specific Integrated Circuits (ASICs) on which the PFE and services run in the largest platforms.

Separating the engines also reduces interdependencies between them. Not only does this separation help preserve the operation of each when another is experiencing problems, it also gives the Juniper engineers more ways to provide system redundancy and failover. For example, you find dual REs in some platforms, whereas the EX Series Ethernet Switches offer a capability called Virtual Chassis to provide redundancy, among other benefits. (See Chapter 11 for the details of this switching feature.)

Plain smart: The planes of Junos OS

Each of the planes of Junos OS provides a critical set of functionality in the operation of the network.

It’s all under control

All the functions of the control plane run on the Routing Engine (whether you have a router, switch, or security platform running Junos). Figure 1-1, shown earlier in this chapter, shows the high-level design of the control plane — a set of modules, with clean interfaces between them, and an underlying kernel that controls the modules and manages all the needed communication back and forth among all the components. The kernel also handles the RE communications with the Packet Forwarding Engine and the services. Each of the different modules provides a different control process, such as control for the chassis components, Ethernet switching, routing protocols, interfaces, management, and so on.

technicalstuff.eps The basis of the Junos kernel comes from the FreeBSD UNIX operating system, an open source software system. This mature, general-purpose system provides many of the essential functions of an operating system, such as the scheduling of resources. To transform it into a network operating system, the Juniper engineers extensively modified and hardened the code for the specialized requirements of networking.

You may be wondering if you have a way in Junos OS to protect the control plane itself from a security attack. Yes, you can configure filters and rate-limit the traffic that reaches your RE. (For more on this topic, see Chapter 9.)

Moving forward

The Packet Forwarding Engine is the central processing element of the forwarding plane, systematically moving the packets in and out of the device. In the Junos OS, the PFE has a locally stored forwarding table. The forwarding table is a synchronized copy of all the information from the RE that the forwarding plane needs to handle each packet, including outgoing interfaces, addresses, and so on. Storing a local copy of this information allows the PFE to get its job done without going to the control plane every time that it needs to process a packet.

Another benefit to having a local copy is that the PFE can continue forwarding packets, even when a disruption occurs to the control plane, such as when a routing or other process issue happens.

At your service

The services plane provides special handling required by many different types of packets. By separating the processing of services from other functions of the operating systems, Junos OS is able to support a wide variety of different service types in different kinds of platforms.

These services might include prioritizing a packet carrying time-sensitive information, such as a voice call, ahead of others on a congested link; guarding which users can get to what sections or applications of the network; translating addresses where one network meets another; or mediating how the network serves video content.

That’s not a problem: The many benefits of modular architecture

Have you ever had a router continually reboot, and when you look on the console, you see that an error occurred in a single nonessential process?

With the Junos OS, you don’t see that problem. The modular architecture of Junos OS allows individual control plane processes to run in their own module (also sometimes called a daemon). Each module has specified processing resources and runs in its own protected memory space, avoiding the processing conflicts that can occur in other platforms. If a malfunction in a module causes an issue, the rest of the system can continue to operate. For example, one module can’t disrupt another by scribbling on its memory.

What about a minor hiccup in SNMP bringing down your whole system? That’s another misfortune that you won’t miss with Junos OS, because its clean separation between control processes helps to isolate small problems so that they can’t create worse havoc.

In our many discussions with users, we hear over and over that the stability of Junos OS is the biggest difference that they see after deploying Juniper platforms in their network. They tell us about their boxes running for months and months, even years without interruption. How they popped the device into the rack, set up the configuration, and never looked back. It just keeps going and going and going — oh, that’s another company’s line.

The modular architecture also eases fault isolation. With each process functioning within its own module, when the occasional problem does occur, pinpointing the exact reason is far less complicated for both you and the Juniper support team. With quick identification and a good understanding of the root cause, you can apply a fix that works, the first time you try.

We have one more benefit to highlight — flexible innovation. The organized structure of the architecture enables deep integration of new capabilities with high functioning interaction with existing processes. For you, this means that native support of new services and features delivers a richness of capability with the high performance that you expect. For example, among the integrations to Junos OS are the security services derived from Juniper’s ScreenOS operating system. (You can find out more about some of these features in Chapter 12.)

Developing Junos OS

Software development probably isn’t a topic that you expected to find in a networking book. After all, you don’t need to build the Junos operating system. Juniper’s engineers do that for you.

However, we include a little about this topic because we think it’s important. The disciplined development process is an essential reason why Junos OS is different. Unlike most other vendors, Juniper develops new versions of the operating system along a common release path, as shown in Figure 1-2.

Figure 1-2: Junos release path.

Asking the right questions

Consider reviewing the software development processes of vendors as a part of your evaluation of new network and security equipment, because it can save you time and money down the road. Here are some questions that you can ask vendors about their software development processes:

check.png Software versions: Find out how many different software versions exist for the products you are buying, and ask why the different versions exist. Know the differences between versions, and when to use one version versus another. Also, ask about the support and end of life policies for each version.

check.png New features: Ask what steps do development engineers follow when adding new features. How do they support changes and fixes to the features in different software versions or release trains? You also want to know how they decide which features to add to which version?

check.png Fixes: Ask about the steps for adding fixes to the code. What procedures ensure that a new fix is a part of all releases, including those in the future? In what types of releases are fixes available and how often?

check.png Testing: Find out how the vendor tests newly developed features (and fixes). What guidelines determine when a release is ready for customers? How thoroughly is each type of release tested before being released to customers? Ask whether a new release can affect previously working features, and find out whether the vendor’s testing includes use-cases to assess how features interact. Ask how the vendor performs performance and scalability testing.

When it’s time to upgrade, you simply choose a higher release number, and not only do you get all the newly developed features, you also keep all the important features you’ve already been using in your network. Also, you’re not running a specialized version of software that may be prone to issues; you’re running software used by Juniper customers everywhere. (Find out more about Junos release versions and upgrades in Chapter 3.)

Beyond the OS

Since we wrote the first edition of this book, Juniper has expanded its Junos software portfolio beyond the operating system, adding new capabilities to link into the application space as well as client software for mobile and personal computing devices. Together, the Junos operating system, the Junos Space network application platform, and the Junos Pulse client form the Junos Platform. By integrating these software layers of the network into one platform, Juniper is expanding the ways that applications can interact with the network from the cloud out to the end user.

As part of the Junos Platform, Juniper provides a set of programming interfaces and software development kits (SDKs) that developers can use to specify the application interactions. Unlike other platforms that merely enable third parties to interface through APIs, these SDKs give application developers a broad set of development interfaces and tools to build a wide variety of applications richly integrated to the Junos Platform.

The following sections provide a short introduction to these additional components of the Junos portfolio. To learn more about Junos Space and Junos Pulse visit http://www.juniper.net/us/en/products-services/software/junos-platform.

Junos Space

Junos Space is an open network platform for developing and hosting applications that interact with the network. The Junos Space platform provides multilayered network abstractions and workflows that allow users to automate network operations and increase operator efficiency.

The software includes a scalable runtime environment with multitenant, hot-pluggable network application support, a network application development framework, and a Web 2.0 user interface.

Junos Space provides a development environment for fast development of network-aware applications. The application development framework includes a common infrastructure, a software development kit (SDK) with prebuilt core services and widgets to allow easy user-interface prototyping, and standards-based APIs for third-party application integration. Using the Junos Space SDK, developers have the option of creating different classes of applications. These include mashups, customized business process workflows, and native applications.

Junos Pulse

Junos Pulse is an integrated, multi-service network client to secure and control application delivery on mobile and personal computing devices. The client is both identity- and location-aware, enabling seamless migration from one access method to another so that users effortlessly, yet securely, retain access to their applications regardless of their location.

Users can download the Junos Pulse client free of charge from most mobile application stores. In this way, the solution can support not only devices managed by the network provider, but also those managed by the user. Once installed, the client provides secure, authenticated access to corporate networks and resources using SSL VPN technology. Junos Pulse provides a comprehensive mobile security, management, and control solution to protect end devices from viruses, malware, spam, loss, theft, physical compromise, and other threats.

Chapter 2

Jumping Into Junos

In This Chapter

arrow Logging into the Junos operating system for the first time

arrow Navigating the command-line interface (CLI) operational mode and configuration mode

arrow Creating and then committing to your first configuration

arrow Restoring to a prior configuration

arrow Saving and archiving your work

When you first get access to the Junos operating system, you may want to log in and start exploring what you can do with it right away. Perhaps you’ve heard that running a network with Junos can save you time, and you want to see for yourself what Junos can do. This chapter lays out the basics of how to log in, shares a few of our favorite power tools for operators, gives a guided tour to its two modes of operation, and helps you set up your first configuration.

Jumpstart Instructions

First-time users most typically access the Junos OS running on their device in one of two ways:

check.png Over a network: Someone else installed the device and can provide you with the hostname as well as the username and password assigned to you. The device may be on a separate subnet behind a gateway device that protects unauthorized access to it, in which case, you will also need the login credentials of the gateway server.

check.png In direct connection: You are directly connected to the device through the console or a management port using a null-modem or rollover cable. The first time you log in to a device that has never been configured, you will be logging in as the root user, and you will not need a password. The root user is a super-administrator who can perform any operation, from benign checks such as looking at the status of the device to disruptive operations such as changing the configuration and rebooting the device.

Junos in the Cloud

Junosphere is a cloud-based environment where users can configure and connect virtual devices that are running Junos to support training, network modeling, and other lab activities. The Junosphere services from Juniper Networks enable realistic, large-scale virtual networks, including a means to interoperate the virtual network with physical network elements. Additionally, users can incorporate Junos Space (see Chapter 1), the Junos and Junos Space SDKs (see Chapter 1), virtualized testing equipment and other lab elements into their network. Together these elements enable organizations to create a highly scalable virtual network of devices running the Junos operating system without requiring dedicated lab resources. For more about Junosphere services, turn to Chapter 19.

tip.eps To install and access your new device out of the box, check out the Quick Start Guide for your product at www.juniper.net/techpubs. Navigate to your specific product to find the guide for your device.

Whichever way you access your Junos device, follow these steps to log in:

1. If you are accessing a previously configured device (otherwise skip this step), use a terminal emulation program, such as Telnet, to open a connection. In this and other examples in the book, we use netnik as the hostname:

telnet netnik

2. At the login prompt, enter your username (use the username root if you are logging in for the first time). At the password prompt enter your password (or press Enter if you are logging in for the first time as the root user):

netnik (ttyp0)

login: wiley

password: ********

3. If you logged in with the root username (otherwise skip this step), you see a shell, similar to a UNIX shell. Type cli to enter the Junos command-line interface (CLI).

root@Amnesiac% cli

4. You are now in the operational mode of the CLI. You see a command-line prompt, which shows your username followed by an @ sign and the hostname of the device. You can enter a ? anywhere in the command-line and receive a list of possible entries.

wiley@netnik> ?

A few users may access the Junos operating system their first time through one of the Junosphere services available from Juniper Networks. Junosphere offers a virtual network running Junos in a cloud-based delivery model. See the sidebar for more about Junos in the cloud.

Command-Line Essentials

The Junos CLI is the starting point to most operator tasks, providing an intuitive, text-based command shell. If you’ve used a UNIX-based host, you’ll see many similarities.

Most users find the Junos operating system CLI fairly easy to grasp. Many commands are similar to those used by other networking vendors. For example, if you are familiar with the Cisco CLI, you’ll find that many Junos CLI commands are the same. The only difference is that you don’t need to use the keyword IP.

After looking around the interface for a few minutes, new users begin to find some of the advanced tools provided by the Juniper engineers to make configuring, monitoring, and managing the system easy to do. Some familiar tools include the ?, which provides a list of possible completions, and the Tab key, which provides completion of partially typed commands, saving you many keystrokes.

Among the many intuitive aspects of the CLI are a structured command hierarchy, extensive fail-safe mechanisms that help to catch configuration mistakes and errors, automation tools for speeding and delivering accuracy to your daily operator tasks, and comprehensive online help.

In addition to the CLI, the Junos operating system offers J-Web GUI access. The simplicity of the J-Web interface allows users to quickly and easily deploy many Juniper devices in an enterprise network. J-Web provides a series of quick configuration wizards that simplify device setup and enable real-time network-management service changes and upgrades. See the J-Web sidebar for a brief introduction to the graphical tool with Chapter 5 providing more information.

tip.eps As J-Web essentially provides a graphical interface and setup wizards for the underlying command-line interface, it’s helpful to understand at least the basics about the CLI.

J-Web

The J-Web interface allows you to monitor, configure, troubleshoot, and manage your device by means of an HTTP- or HTTPS-enabled web browser. J-Web provides access to the configuration statements supported by the device, so you can fully configure it without using the CLI editor. For example, in the SRX Series of security gateways, J-Web includes wizards to assist you in configuring firewall policies, NAT, and IPSec VPNs.

A tale of two command modes

A fundamental trait to understand about Junos OS is that it separates the CLI commands into two groups:

check.png Operational mode: A set of commands to manage and monitor device operations. For example, you can monitor the status of the hardware and software and perform maintenance tasks, such as upgrading software or managing device files.

check.png Configuration mode: A set of commands to set up the device and the network. For example, you can configure user access, the system properties, and the device’s interfaces, protocols, and services.

The Junos CLI further structures the activities of each mode into a set of hierarchies, as illustrated in Figure 2-1. The hierarchy of each mode is made up of cascading branches of related functions commonly used together where deeper levels are more and more specific.

The structured hierarchy of the CLI brings practical elegance, and it’s a favorite trait of long-time Junos users. By logically grouping activities, the Junos CLI provides a familiar, consistent structure for knowing where you are, finding what you want, moving around the interface, and entering commands. Also, when you are setting up a configuration for a particular aspect of the network, such as its protocols, or verifying or troubleshooting the network, everything is in the same place.

The convenient hierarchical structure of Junos means that you don’t waste a lot of time scrolling through the entire configuration every time you need to make a change. You simply navigate your way to the necessary section of the command tree.

Figure 2-1: Each Junos CLI mode has a hierarchical command structure.

Knowing your location in the CLI

Because of the hierarchy of the Junos CLI, you always know just where you are in the command hierarchy. When you first log into the CLI, Junos places you in operational mode. You enter configuration mode by using the configure command:

wiley@netnik> configure

Entering configuration mode

[edit]

wiley@netnik#

remember.eps You can identify which mode you are in by the command prompt.

check.png In operational mode, the prompt is a > symbol:

wiley@netnik>

check.png In configuration mode, the prompt is a # symbol:

wiley@netnik#

Knowing your place in the hierarchy

In configuration mode, you must apply new commands precisely where they belong — for example, to a specific interface or policy group — so it’s important that you know exactly where you are in the hierarchy. Fortunately, configuration mode uses indentation, which helps you recognize its hierarchy. This indentation may remind you of the outline you did in high school for your sophomore research paper.

Before looking at an example of a configuration listing, you may find it helpful to become familiar with two different types of configuration statements:

check.png Container statements: Contain subordinate levels of the hierarchy.

check.png Leaf statements: End a hierarchy — that is, they have no subordinate statements.

Now, here’s an example configuration listing that shows off the svelte moves of configuration mode:

[edit]

system {

  services {

    ftp;

  }

}

check.png The [edit] banner indicates the starting hierarchical level of the listing.

check.png Indentation of each subordinate level shows the configuration hierarchy. Here, ftp is under services, which is under system.

check.png The CLI indicates container statements with open and closed curly braces ({ }). Here, system and services are container statements.

check.png The CLI indicates leaf statements with a semicolon (;). Here, ftp; is a leaf statement.

Junos ensures that you can easily make your way up and down its configuration interface.

Before moving on to the next section, we want to show you one more smooth move of the CLI. In the preceding example, you find simply the [edit] banner at the very top of the configuration mode. But Junos allows you to look at this same setup from anywhere along its hierarchical path, for example:

[edit system services]

ftp;

In configuration mode, when you are in deeper levels of the hierarchy, the edit banner always gives you the complete hierarchical path. Here, [edit systems services] indicates that you are in the second level node of system, and then within it, you are in the third level node of services.

When you want to focus on only a small part