Juniper MX Series ebook free download

You can virtualize the physical interfaces, logicalinterfaces, control plane, data plane, network services, and even have virtualized serv-ices span several Juniper MX routers.. tree che

Juniper MX Series

Douglas Richard Hanks, Jr and Harry Reynolds

Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo

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 (http://my.safaribooksonline.com) For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com.

Editors: Mike Loukides and Meghan Blanchette

Development Editor: Patrick Ames

Production Editor: Holly Bauer

Copyeditor: Absolute Service, Inc.

Proofreader: Rachel Leach

Indexer: Bob Pfahler

Cover Designer: Karen Montgomery

Interior Designer: David Futato

Illustrator: Rebecca Demarest

October 2012: First Edition

Revision History for the First Edition:

2012-09-24 First release

See http://oreilly.com/catalog/errata.csp?isbn=9781449319717 for release details.

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 tained herein.

con-ISBN: 978-1-449-31971-7

[LSI]

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

Ethernet Switch 48

2 Bridging, VLAN Mapping, IRB, and Virtual Switches 71

Basic Comparison of Service Provider versus Enterprise Style 80Service Provider Interface Bridge Configuration 83

Service Provider Bridge Domain Configuration 91

IRB Attributes 142

3 Stateless Filters, Hierarchical Policing, and Tri-Color Marking 153

Filter Processing in Bridged and Routed Environments 213Monitor and Troubleshoot Filters and Policers 214Bridge Family Filter and Policing Case Study 221

4 Routing Engine Protection and DDoS Prevention 235

Table of Contents | ix

Configuration and Operational Verification 279

5 Trio Class of Service 319

MX Trio CoS Defaults 430Four Forwarding Classes, but Only Two Queues 431

7 Trio Inline Services 589

8 Multi-Chassis Link Aggregation 643

Multi-Chassis Link Aggregation versus MX Virtual-Chassis 647

ICCP Topology Guidelines 652

9 Junos High Availability on MX Routers 721

Graceful Restart and other Routing Protocols 747

Replication, the Magic That Keeps Protocols Running 762

Table of Contents | xiii

ISSU Layer 2 Support 819

Index 839

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 withJuniper Networks, supporting large enterprise accounts such as Chevron, HP, andZynga 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 UsersGroup (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 Junos Enterprise Routing and Junos Enterprise Switching (O’Reilly) Prior to joining Juniper, Harry served

in the US Navy as an Avionics Technician, worked for equipment manufacturer MicomSystems, and spent much time developing and presenting hands-on technical trainingcurricula targeted to both enterprise and service provider needs Harry has developedand 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 largestprivate 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 makeJapanese-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 withJunos 3.4 on the original M40 back in 1998, and it has been a love affair ever since His

xv

background includes launching an industry-first DDoS Mitigation and Detection 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.

ser-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 ofinterest are Service Provider technologies, network device architecture, and SoftwareDefined 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 ofsmartest and most capable networking people around They include but are not limitedto: Kannan Kothandaraman, Ramesh Prabagaran, Dogu Narin, Russell Gerald Kelly,Rohit Puri, Sunesh Rustagi, Ajay Gaonkar, Shiva Shenoy, Massimo Magnani, EswaranSrinivasan, Nitin Kumar, Ariful Huq, Nayan Patel, Deepak Ojha, Ramasamy Rama-nathan, Brandon Bennett, Scott Mackie, Sergio Danelli, Qi-Zhong Cao, Eric CheungYoung Sen, Richard Fairclough, Madhu Kopalle, Jarek Sawczuk, Philip Seavey, andAmy Buchanan

Proof of Concept Laboratory

In addition, the authors humbly thank the POC Lab in Sunnyvale, California, wherethe 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

One of the most popular routers in the enterprise and service provider market is theJuniper 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 thesechallenges

This book is going to show you, step-by-step, how to build a better network using theJuniper 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, logicalinterfaces, 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 newbook 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 toregurgitate 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 certaintechnologies 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 Alogical choice would be to include the spanning tree protocol in this chapter.However, spanning tree has been around forever and quite frankly there’s nothingspecial or interesting about it Spanning tree is covered in great detail in everyJNCIA and CCNA book on the market If you want to learn more about spanning

xvii

tree check out Junos Enterprise Switching by O’Reilly or CCNA ICND2 Official Exam and Certification Guide, Second Edition by Cisco Press.

Basic Firewall Filters

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

Class of Service

This was a difficult decision because Chapter 5 is over 170 pages of advancedhierarchal class of service Adding another 50 pages of class of service basics wouldhave 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, Junos Enterprise Routing, Second Edition by O’Reilly, or Juniper

Routing Protocols

There are various routing protocols such as OSPF and IS-IS used throughout thisbook in case studies No introduction chapters are included for IS-IS or OSPF, andit’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 Juniper Networks Certified Internet Expert Study Guide byJuniper 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 Itwas decided to provide enough content in the introduction that a new user couldgrasp the concepts, but someone already familiar with virtual chassis wouldn’tbecome frustrated Chapter 6 specifically focuses on the technical prowess of vir-tual chassis and the Juniper MX implementation of virtual chassis

After many hours of debate over Skype, it was decided that we should defer to otherbooks when it comes to introductory material and keep the content of this book at anexpert level We expect that most of our readers already have their JNCIE or CCIE (orare well on their way) and will enjoy the technical quality of this book For beginningreaders, we want to share an existing list of books that are widely respected within thenetworking 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, thisbook will use a master topology and each chapter will use a subset of the devices thatare needed to illustrate features and case studies The master topology is quite extensiveand 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 isbroken 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 as10.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 topologythat 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 wheninterconnecting data centers a full mesh of WAN links aren’t cost effective, so wedecided 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 fivefigures, Figure P-1 through Figure P-5: Interface Names, Aggregate Ethernet Assign-ments, Layer 2, IPv4 Addressing, and IPv6 Addressing The breakdown and configu-ration of the equipment is as follows:

Preface | xix

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

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

Preface | xxi

Aggregate Ethernet Assignments

Figure P-2 Master topology: Aggregate ethernet assignments

Layer 2

Figure P-3 Master topology: Layer 2

Preface | xxiii

IPv4 Addressing

Figure P-4 Master topology: IPv4 addressing

IPv6 Addressing

Figure P-5 Master topology: IPv6 addressing

Preface | xxv

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 provideenough 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:

Chapter 1, Juniper MX Architecture

Learn a little bit about the history and pedigree of the Juniper MX and what factorsprompted 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 explainsome of the recent important changes to the release cycle and support structure ofJunos The star of the chapter is of course the Juniper MX; the chapter willthoroughly explain all of the components such as line cards, switch fabric, androuting engines

Chapter 2, Bridging, VLAN Mapping, IRB, and Virtual Switches

It always seems to surprise people that the Juniper MX is capable of switching; notonly can it switch, it has some of the best bridging features and scalability on themarket The VLAN mapping is capable of popping, swapping, and pushing newIEEE 802.1Q headers with ease When it comes to scale, it can support over 8,000virtual switches

Chapter 3, Stateless Filters, Hierarchical Policing, and Tri-Color Marking

Discover the world of advanced policing where the norm is creating two-rate color markers, hierarchical policers, cascading firewall filters, and logical band-width policers You think you already know about Junos policing and firewallfilters? You’re wrong; this is a must-read chapter

three-Chapter 4, Routing Engine Protection and DDoS Prevention

Everyone has been through the process of creating a 200-line firewall filter andapplying it to the loopback interface to protect the routing engine This chapterpresents an alternative method of creating a firewall filter framework and onlyapplies the filters that are specific to your network via firewall filter chains As ofJunos 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

Chapter 5, Trio Class of Service

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 Harryand discover the advantages of hierarchical scheduling

Chapter 6, MX Virtual Chassis

What’s better than a Juniper MX router? Two Juniper MX routers, of course, unlessyou’re talking about virtual chassis; it takes several Juniper MX Routers andcombines them into a single, logical router

Chapter 7, Trio Inline Services

Services such as Network Address Translation (NAT), IP Information Flow Export(IPFIX), and tunneling protocols traditionally require a separate services card Trioinline services turns this model upside down and allows the network engineer toinstall network services directly inside of the Trio chipset, which eliminates theneed for special services hardware

Chapter 8, Multi-Chassis Link Aggregation

An alternative to virtual chassis is a feature called MC-LAG, which allows tworouters to form a logical IEEE 802.3ad connection to a downstream router andappear as a single entity The twist is that MC-LAG allows the two routers tofunction independently

Chapter 9, Junos High Availability on MX Routers

Some of us take high availability for granted GRES, NSR, NSB, and ISSU makeyou feel warm and fuzzy But how do you really know they work? Put on your hardhat and go spelunking inside of these features and protocols like you never havebefore

Each chapter includes a set of review questions and exam topics, all designed to getyou thinking about what you’ve just read and digested If you’re not in the certificationmode, 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:

Constant width bold

Shows commands and other text that should be typed literally by the user, as well

as important lines of code

Preface | xxvii

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 inthis 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 Forexample, deploying a network based on actual configurations from this book does notrequire permission Selling or distributing a CD-ROM of examples from this book doesrequire permission Answering a question by citing this book and quoting examplecode does not require permission Incorporating a significant amount of sample con-figurations or operational output from this book into your product’s documentationdoes 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 nolds, 978-1-449-31971-7.”

Rey-If you feel your use of code examples falls outside fair use or the permission given here,feel free to contact us at permissions@oreilly.com

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 (www.safaribooksonline.com) is an on-demand digitallibrary that delivers expert content in both book and video form from theworld’s leading authors in technology and business

Technology professionals, software developers, web designers, and business andcreative professionals use Safari Books Online as their primary resource for research,problem solving, learning, and certification training

Safari Books Online offers a range of product mixes and pricing programs for

organizations, government agencies, and individuals Subscribers have access to sands of books, training videos, and prepublication manuscripts in one fully searchabledatabase from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, CiscoPress, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, AdobePress, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, CourseTechnology, and dozens more For more information about Safari Books Online, pleasevisit us online

thou-Preface | xxix

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

at http://www.oreilly.com

Find us on Facebook: http://facebook.com/oreilly

Follow us on Twitter: http://twitter.com/oreillymedia

Watch us on YouTube: http://www.youtube.com/oreillymedia

CHAPTER 1

Juniper MX Architecture

Back in 1998, Juniper Networks released its first router, the M40 Leveraging cation Specific Integrated Circuits (ASICs), the M40 was able to outperform any otherrouter architecture The M40 was also the first router to have a true separation of thecontrol and data planes, and the M Series was born Originally, the model name M40referred to its ability to process 40 million packets per second (Mpps) As the productportfolio 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

Appli-to allow Service Providers Appli-to deliver services based on IP while at the same time porting legacy frame relay and ATM networks

sup-Fast forward 10 years and the number of customers that Service Providers have tosupport has increased exponentially Frame relay and ATM have been decimated, ascustomers 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 derstood and deployed networking technologies used today Companies have chal-lenging requirements to reduce operating costs and at the same time provide moreservices Ethernet enables the simplification in network operations, administration, andmaintenance

un-The MX Series was introduced in 2007 to solve these new challenges It is optimizedfor 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 ing capability and focus on 10G interfaces and beyond; it’s also interesting to note thatthe Roman numeral for the number 10 is “X.”

switch-It’s no easy task to create a platform that’s able to solve these new challenges The MXSeries has a strong pedigree: although mechanically different, it leverages technologyfrom both the M and T Series for chassis management, switching fabric, and the routingengine

1

Features that you have come to know and love on the M and T Series are certainlypresent 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 andbroadband network gateway (BNG) Here’s just a sample of what is available on theMX:

High availability

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

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 Enterpriseproviding edge routing or core switching

This chapter introduces the MX platform, features, and architecture We’ll review thehardware, components, and redundancy in detail

Junos

Junos is a purpose-built networking operating system based on one of the most stableand secure operating systems in the world: FreeBSD Junos is designed as a monolithickernel 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 andmemory separation

One of the benefits of monolithic kernel architecture is that kernel functions are cuted in supervisor mode on the CPU while the applications and daemons are executed

exe-in user space A sexe-ingle failexe-ing daemon will not crash the operatexe-ing system or impactother unrelated daemons For example, if there was an issue with the SNMP daemonand 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 effectiveacross 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 Beingable 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 ofJunos The development of the core operating system is a single release train Thisallows developers to create new features or fix bugs once and share them across multipleplatforms

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 quarterthe software was released This happens to line up nicely for Junos 11 and Junos 12 asthey 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 theyear 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 thecalendar year is known as the Extended End of Life (EEOL), and this release is sup-ported for 36 months

Junos | 3

Figure 1-1 Junos release model

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

The general rule of thumb is that new features are added every minor release and bugfixes are added every maintenance release For example, Junos 11.1 to 11.2 wouldintroduce 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 calendaryear; these Junos releases are EEOL releases that are supported for three years Theadvantage is that the EEOL releases become more stable with time Consider that 11.1will stop providing bug fixes after 18 months, while 11.4 will continue to have bug fixesfor 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 andhave 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, networkoperators 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 confidentusing 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 warding plane This is true for the MX Series, where all of the control plane functionsare performed by the routing engine while all of the forwarding is performed by thepacket forwarding engine (PFE) Providing this level of separation ensures that oneplane doesn’t impact the other For example, the forwarding plane could be routingtraffic at line-rate and performing many different services while the routing engine sitsidle and unaffected

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

miscon-• Updating the routing table

• Answering SNMP queries

• Processing SSH or HTTP traffic to administer the router

• Changing fan speed

Junos | 5

• 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 enginewhile 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 andswitch fabric; for example, if a router was processing traffic between web servers andthe 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 rolewithin the MX and work together via Interprocess Communication (IPC) and routingsockets 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 nologies, but they play a smaller and more specific role in the software architecture

The interactive component of mgd is the Junos cli; this is a terminal-based applicationthat allows the network operator an interface into Junos The other side of mgd is theextensible 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.

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 toany 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

Junos | 7

{master}dhanks@R1-RE0> show isis adjacency | display xml

<rpc-reply xmlns:junos="http://xml.juniper.net/junos/11.4R1/junos">

<isis-adjacency-information routing"

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 configuredwithin Junos At a high level, its responsibilities are receiving routing advertisementsand updates, maintaining the routing table, and installing active routes into the for-warding table In order to maintain process separation, each routing protocol config-ured 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 theresults

{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 betteridea of what’s using the routing engine CPU Let’s wait a few minutes for it to collectsome 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