959 Juniper MX Series ebook Free download

  Juniper MX Series

Douglas Richard Hanks, Jr. and Harry Reynolds

  Juniper MX Series by Douglas Richard Hanks, Jr. and Harry Reynolds Copyright © 2012 Douglas Hanks, Jr., Harry Reynolds. All rights reserved.

  Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.

O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions

are also available for most titles For more information, contact our

corporate/institutional sales department: 800-998-9938 or

  Mike Loukides and Meghan Blanchette Bob Pfahler Editors: Indexer:

  Patrick Ames Karen Montgomery Development Editor: Cover Designer:

  

Holly Bauer David Futato

Production Editor: Interior Designer:

  Absolute Service, Inc. Rebecca Demarest Copyeditor: Illustrator: Proofreader: Rachel Leach October 2012: First Edition.

  Revision History for the First Edition: 2012-09-24 First release See

  

Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of

O’Reilly Media, Inc. Juniper MX Series, the image of a tawny-shouldered podargus, and related trade

dress are trademarks of O’Reilly Media, Inc.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as

trademarks. Where those designations appear in this book, and O’Reilly Media, Inc., was aware of a

trademark claim, the designations have been printed in caps or initial caps.

While every precaution has been taken in the preparation of this book, the publisher and authors assume

no responsibility for errors or omissions, or for damages resulting from the use of the information con-

tained herein.

  ISBN: 978-1-449-31971-7 [LSI] 1348575579

  Dedicated to my wife and my parents. You guys are the best. Love you.

  —Douglas

  

I would like to acknowledge my wife, Anita, and

our two lovely daughters, Christina and Marissa,

for once again understanding and accommodating

my desire to engage in this project. And thanks to

  

Doug, that plucky young lad who managed to

goad me into engaging in this project when my day

job was already rather action-packed. A special

thanks to my manager, Andrew Pangelinan at

  

Juniper Networks, for his understanding and

support in this project.

  

—Harry

Table of Contents

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

About the Authors

  

Douglas Richard Hanks, Jr. is a Data Center Architect with Juniper Networks and

  focuses on solution architecture. Previously, he was a Senior Systems Engineer with Juniper Networks, supporting large enterprise accounts such as Chevron, HP, and Zynga. He is certified with Juniper Networks as JNCIE-ENT #213 and JNCIE-SP #875. Douglas’ interests are network engineering and architecture for enterprise and service provider technologies. He is the author of several Day One books published by Juniper Networks Books. Douglas is also the cofounder of the Bay Area Juniper Users Group (BAJUG). When he isn’t busy with networking, Douglas enjoys computer pro- gramming, photography, and Arduino hacking. Douglas can be reached at

  doug@juniper.net or on Twitter @douglashanksjr.

  

Harry Reynolds has over 30 years of experience in the networking industry, with the

  last 20 years focused on LANs and LAN interconnection. He is CCIE # 4977 and JNCIE # 3 and also holds various other industry and teaching certifications. Harry was a contributing author to Juniper Network Complete Reference (McGraw-Hill) and wrote the JNCIE and JNCIP Study Guides (Sybex Books). He coauthored

  

(O’Reilly). Prior to joining Juniper, Harry served

  in the US Navy as an Avionics Technician, worked for equipment manufacturer Micom Systems, and spent much time developing and presenting hands-on technical training curricula targeted to both enterprise and service provider needs. Harry has developed and presented internetworking classes for organizations such as American Institute, American Research Group, Hill Associates, and Data Training Resources. Currently, Harry performs Customer Specific Testing that simulates one of the nation's largest private IP backbones at multidimensional scale. When the testing and writing is done (a rare event, to be sure), Harry can be found in his backyard metal shop trying to make Japanese-style blades.

About the Lead Technical Reviewers

  

Stefan Fouant is a Technical Trainer and JNCP Proctor at Juniper Networks with over

  15 years of experience in the networking industry. His first exposure to Junos was with Junos 3.4 on the original M40 back in 1998, and it has been a love affair ever since. His background includes launching an industry-first DDoS Mitigation and Detection ser- vice at Verizon Business, as well as building customized solutions for various mission- critical networks. He holds several patents in the areas of DDoS Detection and Miti- gation, as well as many industry certifications including CISSP, JNCIE-SP, JNCIE- ENT, and JNCIE-SEC.

  

Artur Makutunowicz has over five years of experience in Information Technology.

  He was a Technical Team Leader at a large Juniper Elite partner. His main areas of interest are Service Provider technologies, network device architecture, and Software Defined Networking (SDN). He was awarded with JNCIE-ENT #297 certification. Artur was also a technical reviewer of Day One: Scaling Beyond a Single Juniper SRX in

  

the Data Center, published by Juniper Networks Books. He is currently an independent

contractor and can be reached at artur@makutunowicz.net.

About the Technical Reviewers

  Many Junos engineers reviewed this book. They are, in the authors’ opinion, some of smartest and most capable networking people around. They include but are not limited to: Kannan Kothandaraman, Ramesh Prabagaran, Dogu Narin, Russell Gerald Kelly, Rohit Puri, Sunesh Rustagi, Ajay Gaonkar, Shiva Shenoy, Massimo Magnani, Eswaran Srinivasan, Nitin Kumar, Ariful Huq, Nayan Patel, Deepak Ojha, Ramasamy Rama- nathan, Brandon Bennett, Scott Mackie, Sergio Danelli, Qi-Zhong Cao, Eric Cheung Young Sen, Richard Fairclough, Madhu Kopalle, Jarek Sawczuk, Philip Seavey, and Amy Buchanan.

Proof of Concept Laboratory

  In addition, the authors humbly thank the POC Lab in Sunnyvale, California, where the test bed for this book was cared for and fed by Roberto Hernandez, Ridha Hamidi, and Matt Bianchi. Without access to test equipment, this book would have been im- possible.

Preface

  One of the most popular routers in the enterprise and service provider market is the Juniper MX Series. The industry is moving to high-speed, high port-density Ethernet- based routers, and the Juniper MX was designed from the ground up to solve these challenges.

  This book is going to show you, step-by-step, how to build a better network using the Juniper MX—it’s such a versatile platform that it can be placed in the core, aggregation, or edge of any type of network and provide instant value. The Juniper MX was designed to be a network virtualization beast. You can virtualize the physical interfaces, logical interfaces, control plane, data plane, network services, and even have virtualized serv- ices span several Juniper MX routers. What was traditionally done with an entire army of routers can now be consolidated and virtualized into a single Juniper MX router.

No Apologies

  We’re avid readers of technology books, and we always get a bit giddy when a new book is released because we can’t wait to read it and learn more about a specific tech- nology. However, one trend we have noticed is that every networking book tends to regurgitate the basics over and over. There are only so many times you can force yourself to read about spanning tree, the split horizon rule, or OSPF LSA types. One of the goals of this book is to introduce new and fresh content that hasn’t been published before.

  There was a conscious decision made between the authors to keep the technical quality of this book very high; this created a constant debate whether or not to include primer or introductory material in the book to help refresh a reader’s memory with certain technologies and networking features. In short, here’s what we decided:

  Spanning Tree

  There’s a large chapter on bridging, VLAN mapping, IRB, and virtual switches. A logical choice would be to include the spanning tree protocol in this chapter. However, spanning tree has been around forever and quite frankly there’s nothing special or interesting about it. Spanning tree is covered in great detail in every JNCIA and CCNA book on the market. If you want to learn more about spanning tree check out

  Basic Firewall Filters

  We decided to skip the basic firewall filter introduction and jump right into the advanced filtering and policing that’s available on the Juniper MX. Hierarchical policers, two-rate three-color policers, and cascading firewall filters are much more interesting.

  Class of Service

  This was a difficult decision because

  hierarchal class of service. Adding another 50 pages of class of service basics would have exceeded page count constraints and provided no additional value. If you would like to learn more about basic class of service check out QoS-Enabled Net-

  works by Wiley, by Juniper Networks. Routing Protocols

  There are various routing protocols such as OSPF and IS-IS used throughout this book in case studies. No introduction chapters are included for IS-IS or OSPF, and it’s assumed that you are already familiar with these routing protocols. If you want to learn more about OSPF or IS-IS, check out the Junos Enterprise Routing, Second Edition by O’Reilly or by Juniper Networks.

  Virtual Chassis

  This was an interesting problem to solve. On one hand, virtual chassis was covered indepth in the book Junos Enterprise Switching by O’Reilly, but on the other hand there are many caveats and features that are only available on the Juniper MX. It was decided to provide enough content in the introduction that a new user could grasp the concepts, but someone already familiar with virtual chassis wouldn’t become frustrated.

  books when it comes to introductory material and keep the content of this book at an expert level. We expect that most of our readers already have their JNCIE or CCIE (or are well on their way) and will enjoy the technical quality of this book. For beginning readers, we want to share an existing list of books that are widely respected within the networking community:

  Junos Enterprise Routing, Second Edition, O’Reilly Junos Enterprise Switching, O’Reilly Junos Cookbook, O’Reilly Junos Security, O’Reilly Junos High Availability, O’Reilly QoS-Enabled Networks, Wiley & Sons

  MPLS-Enabled Applications, Third Edition, Wiley & Sons Network Mergers and Migrations, Wiley Juniper Networks Certified Internet Expert, Juniper Networks Juniper Networks Certified Internet Professional, Juniper Networks Juniper Networks Certified Internet Specialist, Juniper Networks Juniper Networks Certified Internet Associate, Juniper Networks CCIE Routing and Switching, Fourth Edition, Cisco Press Routing TCP/IP, Volumes I and II, Cisco Press OSPF and IS-IS, Addison-Wesley OSPF: Anatomy of an Internet Routing Protocol, Addison-Wesley The Art of Computer Programming, Addison-Wesley

  TCP/IP Illustrated, Volumes 1, 2, and 3, Addison-Wesley

  UNIX Network Programming, Volumes 1 and 2, Prentice Hall PTR Network Algorithmics: An Interdisciplinary Approach to Designing Fast Networked Devices, Morgan Kaufmann

Book Topology

  Using the same methodology found in the JNCIP-M and JNCIE-M Study Guides, this book will use a master topology and each chapter will use a subset of the devices that are needed to illustrate features and case studies. The master topology is quite extensive and includes four Juniper MX240s, two EX4500s, two EX4200s, and various port test- ers which can generate traffic and emulate peering and transit links. The topology is broken into three major pieces:

  Data Center 1

  The left side of the topology represents Data Center 1. The devices include W1, W2, S1, S2, R1, R2, P1, and T2. The address space can be summarized as 10.0.0.0/14.

  Data Center 2

  The right side of the topology represents Data Center 2. It’s common for networks to have more than one data center, so it made sense to create a master topology that closely resembles a real production network. The devices include W3, W4, S3, S4, R3, R4, P2, and T2.

  The Core

  The core is really just a subset of the two data centers combined. Typically when interconnecting data centers a full mesh of WAN links aren’t cost effective, so we decided to only use a pair of links between Data Center 1 and Data Center 2. For the sake of clarity and readability, the master topology has been broken into five figures, : Interface Names, Aggregate Ethernet Assign- ments, Layer 2, IPv4 Addressing, and IPv6 Addressing. The breakdown and configu- ration of the equipment is as follows:

  W1: Web Server 1. This is a tester port that’s able to generate traffic. W2: Web Server 2. This is a tester port that’s able to generate traffic. S1: Access Switch 1. This is a Juniper EX4500 providing both Layer 2 and Layer 3 access.

  S2: Access Switch 2. This is a Juniper EX4500 providing both Layer 2 and Layer 3 access. R1: Core Router/WAN Router 1. Juniper MX240 with a MPC2 Enhanced Queuing line card. R2: Core Router/WAN Router 2. Juniper MX240 with a MPC2 Enhanced Queuing line card. R3: Core Router/WAN Router 3. Juniper MX240 with a MPC2 line card. R4: Core Router/WAN Router 4. Juniper MX240 with a MPC2 Queuing line card.

S3: Access Switch 3. Juniper EX4200 providing both Layer 2 and Layer 3 access.

S4: Access Switch 4. Juniper EX4200 providing both Layer 2 and Layer 3 access.

W3: Web Server 3. This is a tester port that’s able to generate traffic. W4: Web Server 4. This is a tester port that’s able to generate traffic. P1: Peering Router 1. This is a tester port that’s able to generate traffic. P2: Peering Router 2. This is a tester port that’s able to generate traffic. T1: Transit Router 1. This is a tester port that’s able to generate traffic. T2: Transit Router 2. This is a tester port that’s able to generate traffic.

  Interface Names Figure P-1. Master topology: Interface names

  Aggregate Ethernet Assignments

Figure P-2. Master topology: Aggregate ethernet assignments

  Layer 2 Figure P-3. Master topology: Layer 2

  IPv4 Addressing Figure P-4. Master topology: IPv4 addressing

  IPv6 Addressing Figure P-5. Master topology: IPv6 addressing

What’s in This Book?

  This book was written for network engineers by network engineers. The ultimate goal of this book is to share with the reader the logical underpinnings of the Juniper MX. Each chapter represents a specific vertical within the Juniper MX and will provide enough depth and knowledge to provide the reader with enough confidence to imple- ment and design new architectures for their network using the Juniper MX. Here’s a short summary of the chapters and what you’ll find inside:

   Learn a little bit about the history and pedigree of the Juniper MX and what factors

  prompted its creation. Junos is the “secret sauce” that’s common throughout all of the hardware; this chapter will take a deep dive into the control plane and explain some of the recent important changes to the release cycle and support structure of Junos. The star of the chapter is of course the Juniper MX; the chapter will thoroughly explain all of the components such as line cards, switch fabric, and routing engines.

   It always seems to surprise people that the Juniper MX is capable of switching; not

  only can it switch, it has some of the best bridging features and scalability on the market. The VLAN mapping is capable of popping, swapping, and pushing new

  IEEE 802.1Q headers with ease. When it comes to scale, it can support over 8,000 virtual switches.

   Discover the world of advanced policing where the norm is creating two-rate three-

  color markers, hierarchical policers, cascading firewall filters, and logical band- width policers. You think you already know about Junos policing and firewall filters? You’re wrong; this is a must-read chapter.

   Everyone has been through the process of creating a 200-line firewall filter and

  applying it to the loopback interface to protect the routing engine. This chapter presents an alternative method of creating a firewall filter framework and only applies the filters that are specific to your network via firewall filter chains. As of Junos 10.4, there’s a new feature called Distributed Denial-of-Service Protection ( ddos-protection ) that can be combined with firewall filters to add an extra layer of security to the routing engine.

   This chapter answers the question, “What is hierarchical class of service and why

  do I need it?” The land of CoS is filled with mystery and adventure; come join Harry and discover the advantages of hierarchical scheduling.

   What’s better than a Juniper MX router? Two Juniper MX routers, of course, unless

  you’re talking about virtual chassis; it takes several Juniper MX Routers and combines them into a single, logical router.

   Services such as Network Address Translation (NAT), IP Information Flow Export

  (IPFIX), and tunneling protocols traditionally require a separate services card. Trio inline services turns this model upside down and allows the network engineer to install network services directly inside of the Trio chipset, which eliminates the need for special services hardware.

   An alternative to virtual chassis is a feature called MC-LAG, which allows two

  routers to form a logical IEEE 802.3ad connection to a downstream router and appear as a single entity. The twist is that MC-LAG allows the two routers to function independently.

   Some of us take high availability for granted. GRES, NSR, NSB, and ISSU make

  you feel warm and fuzzy. But how do you really know they work? Put on your hard hat and go spelunking inside of these features and protocols like you never have before. Each chapter includes a set of review questions and exam topics, all designed to get you thinking about what you’ve just read and digested. If you’re not in the certification mode, the questions will provide a mechanism for critical thinking, potentially prompt- ing you to locate other resources to further your knowledge.

Conventions Used in This Book

  The following typographical conventions are used in this book:

  Italic

  Indicates new terms, URLs, email addresses, filenames, file extensions, pathnames, directories, and Unix utilities.

  Constant width

  Indicates commands, options, switches, variables, attributes, keys, functions, types, classes, namespaces, methods, modules, properties, parameters, values, objects, events, event handlers, XML tags, macros, the contents of files, and the output from commands.

  Constant width bold

  Shows commands and other text that should be typed literally by the user, as well as important lines of code.

  Constant width italic Shows text that should be replaced with user-supplied values.

  This icon signifies a tip, suggestion, or general note.

  This icon indicates a warning or caution.

Using Code Examples

  This book is here to help you get your job done. In general, you may use the code in this book in your own configuration and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the material. For example, deploying a network based on actual configurations from this book does not require permission. Selling or distributing a CD-ROM of examples from this book does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of sample con- figurations or operational output from this book into your product’s documentation does require permission. We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN, for example: “Juniper MX Series by Douglas Richard Hanks, Jr., and Harry Reynolds. Copyright 2012, Douglas Hanks, Jr., and Harry Rey- nolds, 978-1-449-31971-7.” If you feel your use of code examples falls outside fair use or the permission given here, feel free to contact us at .

  As with most deep-dive books, the reader will be exposed to a variety of hidden, Junos Shell, and even MPC-level VTY commands performed after forming an internal connection to a PFE component. As always, the standard disclaimers apply.

  In general, a command being hidden indicates that the feature is not officially supported in that release. Such commands should only be used in production networks after consultation with JTAC. Likewise, the shell is not officially supported or documented. The commands available can change, and you can render a router unbootable with careless use of shell commands. The same holds true for PFE compo- nent-level shell commands, often called VTY commands, that, again, when undocumented, are capable of causing network disruption or damage to the routing platform that can render it inoperable. The hidden and shell commands that are used in this book were selected because they were the only way to illustrate certain operational charac- teristics or the results of complex configuration parameters. Again, hidden and shell commands should only be used under JTAC guidance; this is especially true when dealing with a router that is part of a production network. You have been duly warned.

Safari® Books Online

  Safari Books Online in both book and video form from the world’s leading authors in technology and business. Technology professionals, software developers, web designers, and business and creative professionals use Safari Books Online as their primary resource for research, problem solving, learning, and certification training. Safari Books Online offers a range of and pricing programs for

  

Subscribers have access to thou-

  sands of books, training videos, and prepublication manuscripts in one fully searchable database from publishers like O’Reilly Media, Prentice Hall Professional, Addison- Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technology, and .

How to Contact Us

  Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc.

  1005 Gravenstein Highway North Sebastopol, CA 95472 800-998-9938 (in the United States or Canada) 707-829-0515 (international or local) 707-829-0104 (fax)

  We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at

  

  To comment or ask technical questions about this book, send email to . For more information about our books, courses, conferences, and news, see our website Find us on Facebook:

CHAPTER 1 Juniper MX Architecture Back in 1998, Juniper Networks released its first router, the M40. Leveraging Appli-

  cation Specific Integrated Circuits (ASICs), the M40 was able to outperform any other router architecture. The M40 was also the first router to have a true separation of the control and data planes, and the M Series was born. Originally, the model name M40 referred to its ability to process 40 million packets per second (Mpps). As the product portfolio expanded, the “M” now refers to the multiple services available on the router, such as MPLS with a wide variety of VPNs. The primary use case for the M Series was to allow Service Providers to deliver services based on IP while at the same time sup- porting legacy frame relay and ATM networks.

  Fast forward 10 years and the number of customers that Service Providers have to support has increased exponentially. Frame relay and ATM have been decimated, as customers are demanding high-speed Layer 2 and Layer 3 Ethernet-based services. Large enterprise companies are becoming more Service Provider-like and are offering IP services to departments and subsidiaries.

  Nearly all networking equipment connects via Ethernet. It’s one of the most well un- derstood and deployed networking technologies used today. Companies have chal- lenging requirements to reduce operating costs and at the same time provide more services. Ethernet enables the simplification in network operations, administration, and maintenance. The MX Series was introduced in 2007 to solve these new challenges. It is optimized for delivering high-density and high-speed Layer 2 and Layer 3 Ethernet services. The “M” still refers to the multiple services heritage, while the “X” refers to the new switch- ing capability and focus on 10G interfaces and beyond; it’s also interesting to note that the Roman numeral for the number 10 is “X.” It’s no easy task to create a platform that’s able to solve these new challenges. The MX Series has a strong pedigree: although mechanically different, it leverages technology from both the M and T Series for chassis management, switching fabric, and the routing engine.

  Features that you have come to know and love on the M and T Series are certainly present on the MX Series as it runs on the same image of Junos. In addition to the “oldies, but goodies,” is an entire featureset focused on Service Provider switching and broadband network gateway (BNG). Here’s just a sample of what is available on the MX:

  High availability

  Non-Stop Routing (NSR), Non-Stop Bridging (NSB), Graceful Routing Engine Switch over (GRES), Graceful Restart (GR), and In-Service Software Upgrade (ISSU)

  Routing

  RIP, OSPF, IS-IS, BGP, and Multicast

  Switching

  Full suite of Spanning Tree Protocols (STP), Service Provider VLAN tag manipu- lation, QinQ, and the ability to scale beyond 4,094 bridge domains by leveraging virtual switches

  Inline services

  Network Address Translation (NAT), IP Flow Information Export (IPFIX), Tunnel Services, and Port Mirroring

  MPLS

  L3VPN, L2VPNs, and VPLS

  Broadband services

  PPPoX, DHCP, Hierarchical QoS, and IP address tracking

  Virtualization

  Multi-Chassis Link Aggregation, Virtual Chassis, Logical Systems, Virtual Switches

  With such a large featureset, the use case of the MX Series is very broad. It’s common to see it in the core of a Service Provider network, providing BNG, or in the Enterprise providing edge routing or core switching. This chapter introduces the MX platform, features, and architecture. We’ll review the hardware, components, and redundancy in detail.

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 exe- cuted 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 mainte- nance. 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 re- leasing 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 sup- ported 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

  Release Target End of Engineering End of Life 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 for- warding 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 miscon- ception 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 dae- mons 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 tech- nologies, 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 pro- vides an API through Junoscript and Netconf to allow for the development of auto- mation applications.

  cli

  The 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: cli

• Passing commands from the 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

  display xml

  to pass data. To see an example of this, simply add the pipe command 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 rpd

  The routing protocol daemon ( ) 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 for- warding table. In order to maintain process separation, each routing protocol config-

  rpd rpd

  ured on the system runs as a separate task within . The other responsibility of 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 show task accounting

  toggles CPU accounting on and off. Use 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.