Copyright

Copyright
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 Addison-
Wesley was aware of a trademark claim, the designations have been printed with initial
capital letters or in all capitals.
The authors and publisher have taken care in the preparation of this book, but make no
expressed or implied warranty of any kind and assume no responsibility for errors or
omissions. No liability is assumed for incidental or consequential damages in connection
with or arising out of the use of the information or programs contained herein.
The publisher offers discounts on this book when ordered in quantity for bulk purchases
and special sales. For more information, please contact:
U.S. Corporate and Government Sales
(800) 382-3419
[email protected]

www.ebook-converter.com
For sales outside of the U.S., please contact:
International Sales
(317) 581-3793
[email protected]
Visit Addison-Wesley on the Web: www.awprofessional.com
Library of Congress Cataloging-in-Publication Data
Juniper Networks reference guide : JUNOS routing, configuration, and architecture /
Thomas M. Thomas II … [et al.].
Downloader demo watermarks
p.cm,
Includes bibliographical references and index.

1
 Copyright
ISBN 0-201-77592-1 (alk.paper)
1. Routers (Computer networks) 2. Juniper Networks, Inc. I. Thomas, Thomas M.
TK5105.543 .J87 2002
004.6—dc21 2002026263
Copyright © 2003 by Pearson Education, Inc.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval
system, or transmitted, in any form, or by any means, electronic, mechanical,
photocopying, recording, or otherwise, without the prior consent of the publisher. Printed
in the United States of America. Published simultaneously in Canada.
For information on obtaining permission for use of material from this work, please submit
a written request to:
Pearson Education, Inc.
Rights and Contracts Department

www.ebook-converter.com
75 Arlington Street, Suite 300
Boston, MA 02116
Fax: (617) 848-7047
Text printed on recycled paper
1 2 3 4 5 6 7 8 9 10—CRW—0605040302
First printing, October 2002

Downloader demo watermarks

2
 Preface
Preface
This book is designed to be an introduction to the Juniper Networks family of Internet
routers and the Juniper Networks Operating System (JUNOS). During the past several
years, Juniper Networks has grown immensely and captured a large share of the Internet-
router market, replacing Cisco in advanced routing solutions. Independent organizations
using industry-recognized test standards have identified Juniper Networks as the leader in
Internet and carrier-class core routing solutions. They have taken this lead and developed
an extremely effective router architecture and command-line interface (CLI) to become
the single largest threat to the dominance of Cisco Systems.
There is no doubt that the bookshelves are seeing more and more space dedicated to the
Juniper Networks product line. This book stands apart from the others because of its
range and depth: It covers the basics of Juniper Networks' product line, provides concise
explanations of internetworking theory, and contains detailed examples that will enable a
network engineer to configure the products. The chapters contained herein walk readers
through how Juniper Networks was formed and the industry need that its foundation
answered. A little background is good, but most network engineers want the technical
details of the topic. This book delves immediately into the architecture of a Juniper
Networks router and the intricacies of JUNOS. If you are new to JUNOS, these chapters
cover all you need to know, from logging into the router to ensuring you have enough
www.ebook-converter.com
knowledge to pass the Juniper Networks Certified Internet Specialist (JNCIS)
examination. If you are experienced, then the tested configuration examples provided
throughout the book will challenge you and provide vital references for application in
your network.
Juniper Networks is rapidly becoming the leader in shaping technology that affects the
Internet. This book focuses on the Internet building-block technologies, such as Border
Gateway Protocol (BGP), and policies; however, we also look to the future with in-depth
coverage of multiprotocol label switching (MPLS) and virtual private networks (VPNs).
In addition, this book contains a high level of information about the entire range of
products and the technologies behind them. This powerful approach gives you a deeper
understanding of the business drives and corporate culture that other books will not
provide.
Downloader demo watermarks
Intended Audience
This book is written for those who desire to learn more about JUNOS and Juniper
3
 Preface
Networks routers. It does not matter if you are new to Juniper Networks routers or
preparing to become a Juniper Networks Certified Internet Expert (JNCIE)—this book
has something for everyone.
People involved in networking and interested in learning how to design and deploy
Juniper-based network solutions
Individuals who need to deploy or maintain multivendor routing solutions
Networking professionals interested in learning what the primary competitor of Cisco
is doing and how its networks are designed
Cisco-certified engineers who want to remain current in a changing market
This book will serve as an excellent tool for building the necessary knowledge level
required to operate and configure Juniper Networks routers, as well as to aid in preparing
for the Juniper Networks Certification Exams.

Organization of This Book

This book is divided into four parts. Part I, “Juniper Networks: An Overview,” introduces

www.ebook-converter.com
readers to the strong entry of Juniper Networks into carrier-class routing and discusses
the company's efforts in education and certification with a brief review of core
technologies. Part II, “System Configuration,” covers all the steps needed to install a
Juniper Networks router and make it function to include network management and
security.
Part III, “Interface and Routing Protocol Configuration,” covers internal routing
protocols, such as Open Shortest Path First (OSPF) and Intermediate System to
Intermediate System (IS-IS), and provides an extensive discussion of external gateway
protocols, such as BGP. Part IV, “Advanced Router Operation and Configuration,”
covers routing policies, along with MPLS, VPNs, and Multicast.

How to Use This Book

Downloader demo watermarks
Many chapters end with case studies. These case studies are taken from real-world router
configurations and range from examples of implementing solutions using Juniper
Networks routers to templates that can be easily applied to your network or used to guide
you in preparation for the JNCIE.
4
 Preface
Each chapter has a bibliography that lists additional texts, Web sites, and the appropriate
standards relevant to each chapter. The chapters reference many Requests for Comments
(RFCs). The Internet Engineering Task Force (IETF) is the body responsible for
producing standards for Internet Protocol (IP) and routing protocols used for IP
networks. The IETF drafts the RFCs that can then be implemented as the standard for
that protocol or IP service. To access RFCs and drafts, go to the IETF Web site at
www.ietf.org. These standards are current at the time of this writing and are located
online at www.rfc-editor.org/rfc.html.
It is our hope that you can use this book as a reference for your network today and in the
future. Good luck.
Thomas M. Thomas II
Doris Pavlichek
Lawrence H. Dwyer III
Rajah Chowbay
Wayne W. Downing III

www.ebook-converter.com
James Sonderegger

Downloader demo watermarks

5
 Acknowledgments
Acknowledgments
Thomas M. Thomas II
This book was one of the most interesting projects I have been involved with. I also came
to have greater respect for (if that were possible) the other contributors who stuck with
the book and to their principles. They are truly impressive folks, and I thank them. I want
to acknowledge the hard work and overwhelming patience of everyone involved as we
tried to herd the cats and finish this book on time. In my life certain constants make it
possible for me to achieve the milestones that I have: my faith and having God answer
many of my prayers; my wife and children (Rebekah and Daniel), who are the lights in
my life and enable me to achieve goals I never dreamed of, thank you; and my friends,
many of whom are authors listed here and others of whom are not, such as Cary Riddock,
a true friend with so many talents its hard to keep track of them all, Peter Slow, the most
talented young man I have ever encountered, and Eric Blanton, who is the quietest friend
I have, but also the most steadfast. Thank you all for making me laugh and being a part of
my life! God bless.

Doris Pavlichek
www.ebook-converter.com
Many people were instrumental in helping me reach my goals for this book. First and
foremost, I would like to thank Tom for convincing me to make another contribution to
the world of technical books. I would also like to thank Larry, James, Rajah, and Wayne
for their assistance in getting me up to speed as I came in at a later stage of the project,
and for answering those frantic late-night e-mail requests. Thanks to Paul Pavlichek, from
whom I got a lot of feedback and background on some of the intricacies of Juniper
architecture. He was also a big help in obtaining practical examples. I would be remiss if I
did not also thank my children, Sean and Stephanie, for putting up with my ducking into
the library immediately after dinner every night while working on this book and Paul for
helping with homework and weekend entertainment. Thanks, guys!

Larry Dwyer
Downloader demo watermarks
The first time you agree to a project like this, you have absolutely no concept of the
effort involved in seeing it to completion. I have found new respect for all those involved
in these types of tasks. I would like to thank Tom Thomas for asking me to be a part of
this. I have learned far more than additional ways to configure a router. Lori Andrews
6
 Acknowledgments
and Ed Mills have been my sanity checks, and for that I am very grateful. Late nights can
do terrible things to one's intended words. Tommy Morris gave me that foot in the door,
trusting me to live up to what I said I could do, which eventually opened into this
wonderful world. But I owe the most, the all, to my loving wife, Patty, who has given up
time, time that can't be gained, purchased, or returned. She has done so with patience and
grace, just so I could fulfill a desire.

Rajah Chowbay
It is true that all things are possible if you just see them through. First, I would like to
thank the team, especially Tom for encouragement and James for a shoulder to lean on.
Second, I thank my children, Andrew, Max, and Marcus, for understanding that “Dad
can't right now.” Finally, a very special thanks to my best friend and soul mate, my wife,
Jacqui, for always believing in us. Jacqui, you make every day the best day of my life.

Wayne Downing
First and foremost, to James Sonderegger, thanks for your assistance in getting the job
done. To Rebecca Greenberg, thanks for your professionalism and constructive
comments during the editing phase. I want to send a special word of thanks to Karen

www.ebook-converter.com
Gettman and Emily Frey for putting up with the slips; your guidance during this project is
appreciated. To Jen Kelland for the last-minute edits. To Ronan McLaughlin, thanks for
the late-night conversations and keeping me focused on the job at hand; your guidance in
the realm of Juniper and this project was instrumental. And, of course, to the rest of the
author team, thanks for making this happen. It has been my pleasure to keep such great
company. On a personal note, I want to thank my dad, Big Wayne; Dude, I don't know
what to say, except thanks for everything! To my mom and sister for the non stop “How's
the book going?” questions, which were very inspirational. To Matt, Dad, and Kathy,
thanks for those first two computers, and to my big sis, Karen, thanks for loaning me the
500 bucks to expand them so I could start coding. To the El-hage, Misleh, Rafidi, and
Taweel families, I appreciate all the support. Chahine, thanks for your encouraging
remarks; they meant the world to me! Sam and Rima, thanks for knowing when I needed
a break—Sam and Harry's is on me next time! To John, Sanaa, Nicole, and Danielle, I'll
make the basketball games next season! To Renda, my lovely wife, this could not have
Downloader demo watermarks
happened if it were not for you and your support. Thanks be to God, our Father, and his
Son, Jesus Christ, who gave his life so I could live.
I dedicate my work on this book to the two people who have influenced my life the most:
7
 Acknowledgments
my wife, Renda, and my dad. Dad (a.k.a. Big Wayne, commonly referred to as Dude),
thanks for giving me the intestinal fortitude to overcome adversity and drive on! Most of
all I dedicate this book to my wife, Renda. I love you for all eternity. Thank you for
letting me be myself and showing the kindness, compassion, and loving touch only you
could provide. You both set the standard that all others should live by! MOMO, Daddy
can play now!

James Sonderegger
First, I thank my wife, Bonnie, and my daughter, Gabby, for being so supportive
throughout this project. They are my inspiration and strength, and I would be lost without
them. I thank my mom, Barbra, for not letting me forget who I am. I also thank my dad,
Gordon, for understanding how important this endeavor was to me and for tolerating my
reclusive behavior during the holidays last year. I thank all of the friends who continue to
speak to me, no matter how crazy things get. Lastly, I thank the instructors who have
helped me in my chosen profession: Matthew Shaul, Joe Staron, Orin Blomberg, and Paul
Masters.

www.ebook-converter.com

Downloader demo watermarks

8
 1. Juniper Networks from the Internet to the Classroom
Chapter 1. Juniper Networks from the Internet to the
Classroom
In today's ever-changing world of networking, there are a number of vendors striving to
bring the cure-all to market for current problems. Some of these problems include
network scalability, performance, and reliability. While many vendors are striving to
meet these needs with antiquated designs, Juniper Networks opted to start from the
ground up and create the first proven next-generation router platform. Juniper Networks
was established in February 1996, long after other vendors had already made a name for
themselves. Since then, they have been moving to the top, seizing a leadership role in the
industry.
This chapter will discuss the Internet and its recent growth, as well as its evolution and
how the architecture itself has changed. The chapter will also discuss the M-Series router
products and their positioning, as well as Juniper Networks' educational offerings and
certification program. The chapter will conclude with a recommended reading list to
supplement the knowledge acquired from this text.

The Growth of the Internet

www.ebook-converter.com
In the last several years, the Internet has grown exponentially. At the close of 1993, there
were approximately 623 sites on the Internet, as opposed to approximately 36,276,652
sites[1] at the end of 2001. Figure 1-1 shows the graphical representation of these
numbers.

Downloader demo watermarks

Figure 1-1. Exponential Growth of the Internet
To look further into these numbers, you must first look at the history of the Internet as a
whole. Providing a complete history of the Internet is beyond the scope of this text, but a
9
 1. Juniper Networks from the Internet to the Classroom
very detailed history can be found in Robert H. Zakon's “Hobbes' Internet Timeline.” The
following discusses some of the major events during this evolution.
From the late 1950s through the end of the 1960s, significant research was being done on
the concept of distributed-computing networks. This work led to the eventual activation
of the ARPANET in 1969. The early 1970s brought us further research in the first host-
to-host protocols, which preceded what we know of today as Transmission Control
Protocol over Internet Protocol (TCP/IP). These first host-based networks were
interconnected via 56Kbps point-to-point circuits. In 1986, the National Science
Foundation's NSFNET followed. In 1988, the top backbone speed was upgraded to T1
(1.544Mbps), then again in 1991, to DS3 (44.7Mbps). During this evolution, several
internetwork connection points were established for peering and connectivity through
various provider backbones.
In 1995, the NSFNET reverted back to a research-only network, and the remaining
networks evolved into what we now know as the Internet. The Internet now provides
global connectivity to either backbone or subscriber points virtually anywhere in the
world.

Use of the Internet—Commercial and Noncommercial

www.ebook-converter.com
As recently as 1993, the Internet was becoming a household buzzword, yet most people
had no idea what it really was. All they knew, from their limited perspective, was that
they were able to send a note to a colleague around the world and get a reply in less than
24 hours. This new method of rapid communication was quickly adopted as a business
enabler. We can now send electronic greeting cards and trade stocks through an Internet
connection, which has giving way to a new lifestyle.
The Internet has become a symbol of the change in our busy lives and hurried schedules.
Although there have been significant changes in how business on the Internet is done, it
still remains one of the highest-growth business sectors. Advocates of the Internet have
gone as far to say that if your business does not have a presence on the Internet, then you
are losing a significant amount of exposure and business potential.

Downloader demo watermarks

This progress does not come without a price. The volatility of the networked business
sector is greater than that of any other in history. We read about the failed Internet-based
companies, or “dot bombs,” of yesterday and see the correction made in the venture
capitalization of today's businesses. Today's companies have to show solid business plans
10
 1. Juniper Networks from the Internet to the Classroom
to get the capital they need. Even then, they might not survive in a tough industry such as
this. These players all need to compete, and they all need a solid infrastructure to
compete on.
Noncommercial use of the Internet has evolved as well. In the early 1990s, it was
considered a luxury to have a dedicated Internet connection in the home. Most people
connected only through analog modems connected to their phone lines. Then, connection
speeds were as low as 14Kbps and gradually went up from there. As any technology
emerges, however, it typically becomes more available, more affordable, and more
robust. Thus, the analog modems we used for connectivity in 1994 are being replaced by
broadband xDSL and cable connections in 2002.
Our current Internet infrastructure is the best it has ever been. However, we still want to
go faster and do more, all at lower prices! Users also demand constant uptime: They want
quality service that is always available, like television. Service quality is rather
predictable when things are constant, but with the introduction of variables (e.g., users,
applications), quality becomes harder to guarantee. Juniper Networks' market advantage
became apparent as the increasing demand for Internet bandwidth and service quality
became a high-priority in the networking industry.

Internet and Router Architectures

www.ebook-converter.com
From its humble beginnings and rapid growth, the Internet has grown exponentially. In
turn, the routers supporting this growth have progressed too. This section examines this
evolution, first by explaining the Integrated Services (IntServ) model and techniques
proposed to assist in the delivery of these services; then by discussing past architectures
and how the IntServ model struggled to become a reality on those platforms; and finally,
by looking at how next-generation routers are being developed to solve IntServ and other
service-related issues.

Past Architectures
In the early 1990s, before the major growth phase of the Internet, backbone transmission
lines had reached DS3 (44.7Mbps) speeds. Up until this point, the demand for bandwidth
Downloader demo watermarks
was not as great. Routers of this period were based on a single central processing unit
(CPU) and monolithic software design. However, as traffic volumes began to increase
and contention and congestion issues became more prevalent, we began to see a change
in how these routers handled the load.
11
 1. Juniper Networks from the Internet to the Classroom
In the single-CPU architecture, there are a finite number of CPU cycles per second that
can be used by the operating system for routine or ad hoc tasks. Early attempts at traffic
engineering were nothing more than additional processes for the CPU to handle. The
CPU was already dealing with processes like packet forwarding, routing table lookups,
access control lists (ACLs), and protocol processes, in addition to normal system-
management functions. As with any situation where there are finite resources available,
you must optimize them. The problem is that there is always a point where optimization
ends and best effort begins. Prior to any end-to-end traffic engineering, packet delivery
was always done on a best-effort basis. When best efforts no longer provided the level of
service necessary, other methods were developed.
In addition to the single-CPU architecture, routers had monolithic operating systems. A
router operating system typically performs four tasks:
1. Process Management
2. Memory Management
3. File System Management
4. I/O Device Management

www.ebook-converter.com
These functions can be performed in one of two ways:
1. At the user level
2. At the system level
In a monolithic structure, any management function or module can call any other
function or module because they are all running essentially at system level. When
operating systems are designed in a monolithic fashion, they typically have very large
kernels. The larger the base for a kernel, the greater the potential for instability.
In addition to kernel issues, the router might also have stability problems with individual
processes. For instance, in a monolithic structure, if a routing process stops working, it
may cause other processes, such as forwarding, to lock up as well, which can snowball
Downloader demo watermarks
into a systemwide problem. Such lock ups usually require a router reboot.
In the early 1990s, when the networking industry really began to evolve, computing
platforms were just beginning to gain momentum. So, as the need to increase
12
 1. Juniper Networks from the Internet to the Classroom
functionality grew, upward scalability hit a ceiling. In 1993, a 66-MHz Intel 486
processor was typical. Routing platforms were being developed to take advantage of
similar processor architectures and speeds. With this, distributed-computing networks
were becoming commonplace. Enterprise networks were becoming fairly large and
spanning the globe in some cases. With this increase in disparate networks, the amount of
wide-area network (WAN) traffic increased, as well.
When it came to computing power and software design, the use of centralized processing
(single CPUs) and monolithic software became the dominating architecture. This type of
platform had poor scalability. In a situation where the routing architecture was very
stable and packet-forwarding rates were low, there was not much of a problem. As soon
as new traffic-engineering methods and larger demands started hitting the marketplace,
the routers soon began to experience problems due to their limitations. One of the major
limiters was the need to provide IntServ end-to-end while still maintaining a certain level
of quality. These technologies, as the next section explains, require performance
guarantees based upon the particular service being used.

IntServ
IntServ consists of voice, video, and data, real-time or not, over a single communications
infrastructure—the Internet. The Internet is the place where you can find virtually all
www.ebook-converter.com
application technologies at work: voice communications, video conferencing solutions,
streaming services, other multimedia applications, and typical data traffic. The goal of the
network provider is to enable these services with end-to-end quality of service (QoS).
The old best-effort data delivery model still works for a lot of services, such as e-mail and
File Transfer Protocol (FTP), but voice and video are less tolerant of that type of delivery
and require newer delivery models using QoS. The IntServ model was defined in Request
for Comments (RFC) 1633, “Integrated Services in the Internet Architecture: An
Overview.” The following excerpt from RFC 1633 provides a solid definition for
Integrated Services.“The [IntServ] model we are proposing includes two sorts of service
targeted towards real-time traffic: guaranteed and predictive service.” The phrase
“guaranteed and predictive service” says quite a bit in itself as this is what everyone is
marketing in one form or another. In review, you cannot help but see how this can solve
quite a number of our problems. It also motivates companies like Juniper Networks to
Downloader demo watermarks
create purpose-built products.
To achieve end-to-end guaranteed quality, several technologies have been introduced,
such as Resource Reservation Protocol (RSVP) and Differentiated Services (DiffServ).
13
 1. Juniper Networks from the Internet to the Classroom
Again, we are looking at a model and not necessarily at a single method. These
technologies can be used to assist in the end-to-end QoS function and compliment one
another versus other solutions.
End-to-end QoS can be achieved through a variety of methods. RSVP, for instance, is
used as a signaling protocol to reserve resources through a network for a given flow.
DiffServ, on the other hand, is typically used on a hop-by-hop basis, where classes of
services are defined. Also on a per-hop basis, forwarding decisions are made. These
services can be used in conjunction with one another or independently. So, you can see
that there are mechanisms in the IntServ model that can be implemented to overcome the
typical best-effort delivery model for network traffic.
RSVP is used to reserve a path within single or multiple networks for end-to-end
communications. In other words, it is used to establish a flow from one end point to
another. When this flow is complete, RSVP can then tear down the reservation and free
up resources for other pending reservations. It provides the signaling required to prepare
these reservations based upon IntServ-defined service classes. Ultimately, these service
classes need to be defined with some equivalency between multiple networks. As with
any QoS implementation, interdomain QoS is of concern. The administrators of one
autonomous system (AS) are unlikely to allow automated or manual control of QoS
mechanisms by an outside administration. So, commonality can only be predicted within

www.ebook-converter.com
a single AS.
DiffServ uses a concept known as the differential service code point (DSCP), which uses
the type-of-service (ToS) bits in the Internet Protocol version 4 (IPv4) header and class-
of-service (CoS) bits in the Internet Protocol version 6 (IPv6) header. Service-class
parameters are set by the use of DSCP bits. These bits can be meaningful on a per-hop
basis.

Next-Generation Platforms and Architectures

There are several approaches to the delivery of end-to-end quality. Through the use of
technologies such as DiffServ and Multiprotocol Label Switching (MPLS), traffic-
engineering concepts are being developed. One such method is bandwidth brokering,
Downloader demo watermarks
which allows a single network administration to dynamically manage the bandwidth
requirements for a given flow of traffic. The model allows a single manager to control the
flows within a single routing domain. If the flow for a given destination needs to traverse
multiple domains, then the local bandwidth broker requests the resources from the
gaining domain, and so on, until the traffic reaches its destination. Bandwidth brokering
14
 1. Juniper Networks from the Internet to the Classroom
takes advantage of DSCP. For more information regarding bandwidth brokering, please
read “Bandwidth Brokers” by Lance Freedman, Steve Ni, Jason Pinkett, and Laura
Welsh of the Virginia Polytechnic Institute and State University Department of
Engineering. This document can be found at www.ee.vt.edu/~ldasilva/6504/BB_rep.doc.
MPLS traffic engineering also allows us to provide network topologies that can be
designed to optimize delivery methods for such services as voice and video. Through the
use of such traffic-engineering techniques, successful end-to-end QoS is achievable.
Before the Internet boom of the mid 1990s, traffic volume in the Internet and quality
were not very significant issues. However, once physical platforms began to reach line-
rate forwarding, and available bandwidth was depleted, end-to-end service began to be a
problem. Certainly, there is no single technology available to solve all congestion and
contention issues associated with exponential growth. However, two distinct
introductions occurred to help eliminate some of the bottleneck problems and get packets
moving through the network somewhat better.
With Internet traffic jams becoming a reality, relief was necessary. One method was the
simple introduction of “fatter pipes,” or larger bandwidth circuits. Internet Protocol over
Asynchronous Transfer Mode (IP/ATM) networks were also gaining popularity. The
larger data pipes and use of IP/ATM overlay networks resolved a great number of the

www.ebook-converter.com
congestion and contention issues.
During this same period, MPLS was being developed. The concept was that through the
use of labels only 4 bytes in length, lookup and forwarding could occur at much faster
rates. (However, as you will see later in this book, MPLS is no longer being used in the
way it was planned, and IP/ATM overlay networks are quickly being replaced by high-
speed Synchronous Optical Network (SONET) transmission systems that create even
larger bandwidth pipes.) At the same time, other advances in technology were being
developed. Although some of this technology was not exploited fully, a true leader
emerged in Juniper Networks.
When Juniper introduced its first product, the M40, it reinvented the wheel, so to speak.
The wheel was now more efficient, however. Instead of using a monolithic-operating-
systems approach, Juniper took a microkernel approach. Instead of using a single CPU
Downloader demo watermarks
for processing power, it moved to a distributed-processing architecture. This move was
made possible by the advent of high-performance processors and high-performance
application-specific integrated circuits (ASICs). Now, instead of having routing and
forwarding running on the same processor, separate processors (ASICs) handle each task.
15
 1. Juniper Networks from the Internet to the Classroom
Software no longer runs within the confines of one huge module; it is controlled by a
kernel making all the calls to the dedicated processors. This efficiency becomes apparent
when you have a problem with a single function. You can restart a process without
having to reboot the entire router. This is one of the real strengths of the Juniper
Networks Operating System (JUNOS): no more rebooting the entire router if a processor
gets stuck.
As they have in the past, future Internet architectures will rely more on underlying
physical technology. As advances are made and incorporated into our industry, network
service providers are in a better position to provide the level of service necessary.

Juniper Networks M-Series

The M-Series routers from Juniper Networks provide a full-featured advanced routing
platform that scales for continued next-generation support. Juniper Networks has
achieved the ability to provide superior performance, interoperability, and service
guarantees. These factors allow providers and enterprise operators to see a return on
investment within a reasonable period of time.
This section introduces the Juniper Networks M-Series family of routers, looks at how the
M-Series is being deployed, and reviews the various market segments.
www.ebook-converter.com
Introducing the M40—September 16, 1998
Juniper Networks' original product offerings came in the form of the M-Series of routers.
On September 16, 1998, Juniper Networks announced its first product to market. The
M40 was the first router of its kind capable of scaling to meet current Internet needs.
With the initial offering of the M40 came the Internet Processor I. The proprietary ASIC
was the fundamental core of the Juniper Networks packet forwarding engine (PFE),
which consists of shared memory, a single forwarding table, and one-write/one-read
architecture. The entire PFE is capable of forwarding 40Mbps, a capacity more than 100-
times greater than that of other available router architectures at the time. The fully
programmable Internet Processor I was engineered to scale with ease.

Downloader demo watermarks

With the release of the M40, Juniper Networks redefined how the Internet routed traffic.
The ability to achieve increased forwarding rates and dynamic updates to forwarding
information while maintaining wire-speed transmission was proof that the designers were
onto something.
16
 1. Juniper Networks from the Internet to the Classroom
This first offering also came with a large variety of interface types, and the nature of the
architecture provided maximum flexibility. The following section discusses the target
market that Juniper Networks aimed for with this product release. More specific
information on the M-Series components will be discussed in Chapter 3.

Juniper Networks Market Segments

With the advent of the M-Series, Juniper Networks was able to deploy solutions to
virtually each and every market segment. In this section, we will focus on how Juniper
Networks routers are positioned and how their product line is built to scale for the largest
provider networks.
Juniper Networks routers can be implemented in just about any scenario. There are three
market segments in which there is a concentrated focus on delivery:
1. Core
2. Edge
3. Mobile

www.ebook-converter.com
Core
The M-Series of routers are capable of handling core-traffic demands while addressing
both QoS and CoS issues. With the use of the new Internet Processor II and functionality
available in the JUNOS code, the M-Series routers outperform, with greater reliability,
any other core device.
The core segment consists of many different operational functions. Some of these
functions are line-rate forwarding, peering, IP/ATM, MPLS, Multicast, and Layer 2 and
Layer 3 virtual private networks (VPNs). Juniper Networks routers are capable of
providing all of these services on a single platform.

Edge
Downloader demo watermarks
Edge aggregation is currently one of the fastest growing sectors in the carrier market
space. The continuing growth of the Internet forces providers to develop greater
scalability at the edge and smooth migration strategies. The M-Series allows this. Its
17
 1. Juniper Networks from the Internet to the Classroom
design means the new core can be established and the dual-purpose router can be pushed
to the edge, providing maximum port density.
On the edge, the M-Series routers provide both dedicated access solutions and edge
aggregation. The ability to provide port density, forwarding performance, and packet
processing without sacrificing overall performance makes the M-Series a solid contender
in the service provider industry. The smaller access market is being addressed with the
M5 and M10 products. The current throughput capabilities of both the M5 and M10
positions make either a good choice for an enterprise core attached to an upstream of
M20 or M40 routers.

Mobile
The current mobile network infrastructures are migrating to next-generation (2.5G) and
third-generation (3G) networks. This creates a strong case for an Internet Protocol (IP)-
based core platform capable of providing end-to-end QoS and full scalability.
With this continuing evolution of wireless technologies, integrating these services into
existing architectures is essential. With current and projected growth of the subscriber
base for this aspect of the industry, robust functionality is key. The ability to provide
IPv4, IPv6, MPLS, and VPN solutions is critical to the mobile infrastructure. Juniper

www.ebook-converter.com
Networks provides a scalable architecture that will allow operators to grow while still
getting a good return on their investment.
In summary, Juniper Networks targets the core, edge, and mobile market segments. It
also deploys, however, into the smaller competitive local exchange carrier (CLEC) and
metropolitan area networks (MANs), as well as into large-enterprise infrastructures. Its
competitive edge in performance alone will likely continue to guarantee success in these
areas.

M-Series Models
Juniper Networks offers the M-Series family of routers to meet the needs for the three
key market segments. This section introduces these models in the order in which they
Downloader demo watermarks
appeared, but for more detailed information, refer to Chapter 3.

M40
18
 1. Juniper Networks from the Internet to the Classroom
The M40, introduced in September 1998, was the first model to market. With its 40Gbps
throughput, it typically is used at the network edge. Lack of component redundancy in
this architecture makes utilization as a core or peering device less desirable.

M20
The M20 was introduced in December 1999. It was the first Juniper Networks router to
use the improved Internet Processor II ASIC. The M20 is capable of 20Gbps throughput
and supports routing engine redundancy. This makes it a more attractive choice for
peering and midrange core applications.

M160
The M160 first shipped in March 2000 and was the first router to market with an optical
carrier (OC)-192 (10Gbps) interface. The M160 is capable of 160Gbps throughput, the
highest port density of any Juniper Networks offering and the best choice for the service-
provider core. Unlike smaller core networks, the Internet service provider (ISP) core is
based upon carrier-class performance. This means that the platform must operate within
defined parameters relating to redundancy, survivability, and uptime. Although the
numbers remain undisclosed by Juniper Networks, the mean time between failures
(MTBF) is estimated to be more than 200,000 hours. The numbers vary based upon
www.ebook-converter.com
platform and hardware configurations.
Independent testing has shown the M160 to outperform the competition in Border
Gateway Protocol (BGP) table capacity, MPLS label-switched-path (LSP) capacity,
route flapping recovery at OC-192 speeds, convergence at both OC-192 and OC-48
speeds, and filtering at both OC-192 and OC-48 speeds. In additional tests, the M160 has
matched or exceeded the competition in the areas of CoS at OC-48 and OC-192 speeds,
and IP and MPLS baseline testing at OC-48 and OC-192 speeds.[2] The M160 platform
provides maximum throughput and the port density necessary for the next generation of
Internet architectures. The leveraging of the M160 for core routing, anywhere
performance, and end-to-end QoS makes it a premier leader now and for the foreseeable
future.

Downloader demo watermarks

M5 and M10
The M5 and M10 models were both introduced in September 2000. They share
architectural similarities, but the M5 is capable of 5Gbps throughput, while the M10 is
19
 1. Juniper Networks from the Internet to the Classroom
capable of 10Gbps throughput. Although neither platform provides switching- or routing-
engine redundancy, they play a major role in smaller core networks as either a core or an
edge device. Because of their small footprint, their deployment in smaller CLEC and
MANs, as well as enterprise markets, is becoming more widespread.

M40e
The newest of the M-Series products, introduced in 2002, is the M40e. This model
provides a more resilient architecture than the M40 because it is equipped with redundant
switching and routing engines. This makes the platform a scalable replacement for the
M20 on the edge because of its higher port density. It is also a good choice for the
network core. The continuing evolution of Juniper Networks products provides more
evidence of their commitment to providing high-performance, resilient, scalable solutions.

Beyond the M-Series

Although they fall outside the scope of this book, two new Juniper Networks products are
reshaping the way networks are being designed:
1. The G10 [Cable Modem Termination System (CMTS)]

www.ebook-converter.com
The J20/AXB 250 06 Gateway GPRS Support Node (GGSN) (a joint venture with
2.
Ericsson)

G10
Through an acquisition, Juniper Networks has brought the G10 CMTS device to the
cable-based carrier network. The advanced capability of the G10 allows cable companies
to provide next-generation IP services to their customers at a low cost per port.

J20/AXB 250 06 GGSN

EJN Mobile IP is the joint venture of Ericsson and Juniper Networks formed to bring the
Downloader demo watermarks
J20/AXB 250 06 Gateway GPRS Support Node, or GGSN, to the mobile carrier market.
(GPRS stands for general packet radio service. It allows carriers to provide packet-based
services to their mobile subscribers.) This product will be sold exclusively by Ericsson.
The AXB 250 06 GGSN is the first GGSN-specific platform built to provide robust
20
 1. Juniper Networks from the Internet to the Classroom
routing and edge technology for mobile networks migrating to 2.5G and 3G architectures.
More information on this joint venture can be found at www.ejnmobileip.com.
Juniper Networks recognized the need to educate its user base in both its products and in
these new advances and, as a result, created the Juniper Networks Education Services.
The next section will take a closer look at this initiative.

Juniper Networks Education Services

Until recently, Juniper Networks only offered a set of minimodules that together lasted a
total of 5 days. This initial course was thus referred to collectively as the Five-Day
Bundle. As a starting point, it was not bad, but the needs of the customers soon outgrew
this course offering.
During the later half of 2001, Juniper Networks began releasing a whole new curriculum.
The new courses provide customers with a complete education and knowledge-
development track for Juniper Networks products. The full curriculum begins with
introductory networking information and progresses to advanced subjects, such as MPLS
and firewalls. If you want to see the latest educational offerings, as these are subject to
change, go to the Juniper Web site at www.juniper.net/support/training.

www.ebook-converter.com
Then, in late 2001, Juniper Networks Education altered their curriculum again and
returned to a week of training that is made up of two courses: Introduction to Juniper
Networks Routers 1 and 2.
Introduction to Juniper Networks Routers 1 (3 days)
Introduction to Juniper Networks Routers 2 (2 days)
Advanced MPLS
Advanced VPN Workshop
Advanced Policy

Downloader demo watermarks

These courses are now available at Juniper Networks Knowledge Centers across the
globe (the locations are listed later in this chapter). Since many people are familiar with
the Cisco curriculum, Table 1-1 provides a rough mapping of equivalent Cisco courses.
Juniper Networks recommends that students follow their curriculum using the course path
21
 1. Juniper Networks from the Internet to the Classroom
shown in Figure 1-2 to develop their knowledge and prepare for Juniper Networks
certification.

Figure 1-2. Juniper Networks Curriculum Path

Table 1-1. Comparison of Juniper Networks and Cisco Courses
Juniper Networks
Cisco Curriculum
Curriculum

www.ebook-converter.com
Introduction to Juniper Interconnecting Cisco Network Devices (ICND) and
Networks Routers 1 and 2 Building Scalable Cisco Internetworks (BSCI)
Advanced MPLS Avanced MPLS VPN Solutions
Advanced VPN Workshop
Advanced Policy No equivalent course[1]
Class of Service (not released Unknown
yet)
[1] An equivalent course would cover Cisco access-control-list (ACL) development and
deployment in depth.
The Juniper Networks Web site is a good source for any new information or changes. It
can also help you decide whether these courses will help prepare you for the Juniper
Networks Certified Internet Specialist (JNCIS) and Juniper Networks Certified Internet
Downloader demo watermarks
Expert (JNCIE) tests. These courses will not totally prepare you; however, according to
Juniper Networks, the “curriculum will increase the student's knowledge plus improve the
chances for quicker completion of Juniper Networks Technical Certification Program
requirements. None of the courses are required to qualify to take the exams for the
22
 1. Juniper Networks from the Internet to the Classroom
certifications” (Juniper Networks Web site, www.juniper.net/training/certification,
August 2001). So, although these courses will increase your knowledge and give you
insight into the Juniper Networks methodology, they will not, in and of themselves,
guarantee that you will pass the exams.

JNIPE = Juniper Networks Instructor Proficiency Exam

It is a 4-day test currently being administered in Amsterdam and Sunnyvale. It
has a written component, a practical (lab) component, and two days worth of
presenting topics to a review board. If you pass JNIPE then you are given the
title of JNAT (Juniper Networks Authorized Trainer).
Anyone wishing to teach the entry level course (IJNR) using Juniper Networks
branded courseware, must first pass JNIPE (there are other requirements such
as lab access, business case, training and center/partner status). After one
passes JNIPE, there are written exams that can be taken for authorization to
teach the branded advanced courses such as AJNR, Advanced Policy, and
VPNs.

Course Descriptions
www.ebook-converter.com
The following sections present an overview of each of the courses that Juniper Networks
has released as of this writing. The course descriptions reflect many of the advanced
topics and attention to detail that the new curriculum has in place. One of the most
important reasons for including this information in this book is that Juniper Networks has
published a series of stringent prerequisites.

Introduction to Juniper Networks Routers 1

Although this class is the beginning of the Juniper Networks Education curriculum, bear
in mind that Juniper Networks lists certain expectations on its Web site regarding student
knowledge prior to registering for the course (see
www.juniper.net/support/training/prerequisites.html). This 3-day course provides an
Downloader demo watermarks
entry-level overview that combines lectures and labs in an instructor-led environment. It
is taught by Juniper Networks–certified instructors. The course focuses on Juniper
Networks products; however, a discussion of routing protocols is also presented.

Introduction to Juniper Networks Routers 2

23
Introduction to Juniper Networks1.Routers 2
Juniper Networks from the Internet to the Classroom

Before taking this course, students should have solid knowledge of protocol
troubleshooting and JUNOS software operation and configuration. There are no official
pre requisites for this course, although it is recommended that the student first complete
“Introduction to Juniper Networks Routers 1”; keep in mind that Juniper has
expectations regarding student knowledge prior to registering for the course (see
www.juniper.net/support/training/prerequisites.html). This 2-day course builds on
Introduction to Juniper Networks Routers 1, providing additional information and
coverage of more advanced topics, such as MPLS, multicast, and firewalls. This course is
designed to prepare students for the more advanced courses.

Advanced MPLS
The following information is taken directly from the Juniper Networks Web site at
www.juniper.net/support/training/EDU-JUN-MPLS.html. Students should be able to
configure an internal BGP (IBGP) full mesh without assistance and should have
knowledge of static LSP configuration and no-CSPF-signaled LSP configuration to the
extent covered in the Juniper Networks Five-Day Bundle. This 3-day course provides a
detailed examination of MPLS and how it is implemented in the JUNOS Internet
software. The course starts with a review of MPLS, then provides detailed discussions of
RSVP, constraint-based routing, and traffic protection. The complexities of implementing
www.ebook-converter.com
LSPs in the network with forwarding adjacencies and traffic engineering are then
discussed. Other topics covered are controlling LSP performance through load balancing,
IP-LSP prefix binding, the time-to-live (TTL) field, CoS behavior, circuit cross connect
(CCC), which makes an LSP look like a Layer 2 circuit, Label Distribution Protocol
(LDP), and network management and troubleshooting. All course modules have
accompanying labs. The final lab of the course is a troubleshooting exercise in which the
student diagnoses and repairs a broken network.

Advanced VPN Workshop

The following information is taken directly from the Juniper Networks Web site at
www.juniper.net/support/training/EDU-JUN-VPN.html. Students should have taken

Downloader demo watermarks

either the M-Series Router Architecture and Configuration, Trouble shooting with JUNOS
software, and JUNOS Routing Policy courses (now replaced by the Internet engineer
course) or the Internet engineer course, or they should have the equivalent experience
from working with JUNOS Internet software in a production environment. A working
knowledge of an interior gateway protocol (IGP)—OSPF or IS-IS—and Border Gateway
24
 1. Juniper Networks from the Internet to the Classroom
Protocol version 4 (BGP4) is required for the hands-on portions of this course.
This advanced workshop focuses on designing, deploying, and troubleshooting the VPN
solutions available in JUNOS software. Day 1 focuses on general MPLS concepts with
the intent of preparing students for the following advanced VPN material. After a brief
lecture, students will perform key MPLS labs from the existing 2-day JUNOS MPLS
course offering. Students who have previously attended the 2-day MPLS workshop
should benefit from the review of these important topics and the additional hands-on
exposure to the JUNOS software configuration and troubleshooting environment.
Day 2 begins with a standards-based lecture on L2/L3 VPN solutions with emphasis
placed on the concepts surrounding 2547bis L3 VPNs. A JUNOS-software-specific
module addressing VPN configuration options, scalability issues, and the interpretation of
operational mode screen dumps follows the VPN technology primer. VPN
troubleshooting methodology is demonstrated throughout the workshop.
The remaining 3 days are spent in the lab with students engaging in a variety of 2547bis
configuration and troubleshooting scenarios. Each student team will be in control of its
own provider edge (PE) and customer edge (CE) router pairing, with the class sharing
three PE routers that make up the provider core.

www.ebook-converter.com
Juniper Networks Knowledge Centers
Juniper Networks–owned and –operated training centers are known as knowledge
centers. At these centers, you can take the courses discussed in this chapter from a
Juniper Networks Authorized Instructor (JNAT). JNAT is yet another certification, which
deals with the ability to deliver training courses effectively and accurately. The JNAT has
an equivalent certification in the Cisco Certified System Instructor (CCSI). As of this
printing, there are three locations where you can attend this training:
Herndon, Virginia, USA
Sunnyvale, California, USA

Downloader
Amsterdam, the Netherlands
demo watermarks
Juniper Networks does not currently offer any type of electronic or online learning
programs. However, they have expanded slightly the places where you can get training
through its Training Partner Program. You can find a listing of training partner program
25
 1. Juniper Networks from the Internet to the Classroom
locations on the Juniper Networks Web site at
www.juniper.net/contactus.html#education_services. Note that Juniper Networks offers
onsite and customized training, on a case-by-case basis. Please contact Juniper Networks
directly for assistance and information.

Authorized Education Centers

Juniper Networks' Training Partner Program is currently inactive, according to sources
within the company; however, four legacy training partner centers are currently active,
all of them international:
1. Belgium—Telindus High-Tech Institute (www.thti.telindus.be/homepage/index.asp)
2. Brazil—QoS Serviços (www.qos.com.br/html_ingles/index.htm)
3. Japan—Net One Systems Co., Ltd. (www.netone.co.jp/index.html)
4. United Kingdom—Telindus K-NET, Ltd. (www.thti-telindus.co.uk/home.htm)
You can also locate this information, centrally, at
www.juniper.net/support/training/authorized_education.html.

www.ebook-converter.com
Ericsson, which has OEM agreements on the entire line of Juniper Networks routers, also
offers training for these products. Ericsson has a product unit known as Ericsson IP
Infrastructure that has offices in Santa Barbara, California; Rockville, Maryland;
Brussels, Belgium; Hong Kong, China; and Stockholm, Sweden. They are not listed as
authorized education centers owing to the OEM agreement. They are sold as Ericsson-
labeled products.

Technical Certification Program

The Juniper Networks Technical Certification Program (JNTCP), introduced in 2001,
draws on on-the-job experience and Juniper Networks' recognition of the industry's ever-
widening acceptance of certification. Based on these factors, two certifications were
Downloader demo watermarks
developed: the JNCIS and JNCIE. Here is how they roughly compare with Cisco
certifications:
Cisco Foundation Routing and Switching (FRS) Exam versus Juniper Network's
26
 1. Juniper Networks from the Internet to the Classroom
JNCIS Exam: In complexity and breadth of coverage, the JNCIS exam is very similar
to the Cisco FRS Foundation Routing and Switching exam. In practice, passing the
JNCIS is like passing the Cisco Certified Internetworking Expert (CCIE) written
exam. The certification itself is roughly equivalent to achieving the Cisco Certified
Network Professional (CCNP) certification. Once you have gained the JNCIS
certification, you have completed the prerequisite for the JNCIE Practical Exam.
Cisco CCIE Practical Exam versus Juniper Networks' JNCIE Practical Exam: These
two exams are both intense, hands-on exams that allow each vendor to measure the
test-taker's networking expertise and experience with the product. Individuals taking
the test should expect to be tested on any topic supported by the vendor in hardware,
software, or the configuration of either.

JNCIS
The JNCIS is a 90-minute, 73-question, multiple-choice and task-driven test with a
passing score of 70 percent. This exam is computer-based and available at Prometric
testing centers for a cost of US$125. The test is geared directly towards individuals
working within the ISP industry who are using Juniper Networks products. Questions
stress knowledge of the JUNOS command-line interface (CLI) hierarchy, as well as BGP

www.ebook-converter.com
regular expressions. In one test taker's experience, the questions regarding router
configuration did not, as Cisco certification tests typically do, require typing commands
or choosing from a list of commands.
The scope of the material covered by the Juniper Networks multiple-choice exam is
great, and the difficulty of the test is compounded in an interesting way: For most
questions, there are Cisco-centric commands mixed in with the correct answers.
When taking the JNCIS be aware of the following 11 categories of questions:
OSPF
IS-IS

Downloader
BGP
Hardware
demo watermarks
MPLS
27
 1. Juniper Networks from the Internet to the Classroom
Network management
Security
Interfaces
Miscellaneous
Policy
Multicast protocols and architectures
Your printed test results will be provided to you upon completion of the exam. It will
show the percentage answered correctly in each area. For example, you may get 33
percent correct in the network-management category. This will help you to identify and
determine areas where you need to improve. Juniper Networks limits applicants to three
attempts in 6 months. After passing this test, you have 12 months to take the JNCIE
practical exam.

JNCIE

www.ebook-converter.com
The JNCIE is a 2-day exam (8 hours per day) held at select Juniper Networks locations
(these locations will be identified later in this chapter). To attempt this test, you must
have passed the JNCIS exam within the past year. The exam is monitored and
videotaped. Your pass/fail status will be available within 10 calendar days of completing
the exam. During this exam, you will be expected to deal with routes and traffic that is
both “live” and artificially generated. If you do not pass the exam, there is a mandatory
2-month waiting period instituted by Juniper Networks between test attempts. If you pass
the test, you must renew your certification every 2 years with an online test and
attendance at the Juniper Networks IP Focus conference.
The goal of the JNCIE Practical Exam is to have the candidate build and troubleshoot a
network using technologies that would be found in today's Internet. Specifically, this
means that you can expect a pure IP-based network with complex scenarios that test

Downloader demo watermarks

your knowledge of the technologies and how they should be properly implemented using
Juniper Networks equipment. The exam focuses on technologies, such as BGP, OSPF,
Asynchronous Transfer Mode (ATM), SONET, Packet over SONET (POS), Gigabit
Ethernet (GigE), MPLS, and VPNs.

28
 1. Juniper Networks from the Internet to the Classroom
As of the writing of this book, there are 16 JNCIEs worldwide, the majority of which are
employed by Juniper Networks. Chief Technology Officer Pradeep Sindhu of Juniper
Networks was granted JNCIE #1. The benefits of JNCIE certification include being
presented with an engraved crystal plaque recognizing your accomplishment, the ability
to use a Juniper Networks Certification Logo, and 24/7-priority access to the Juniper
Technical Assistance Center (JTAC).
You can take the JNCIE lab exam at three locations in the world:
1. Amsterdam, the Netherlands
2. Sunnyvale, California, USA
3. Herndon, Virginia, USA
The most up-to-date certification information can be found online at
www.juniper.net/training/certification/resources.html.

Studying for Juniper Networks Certification

There are not, at present, very many resources available to help you study for the Juniper

www.ebook-converter.com
Networks certifications. This text is one of the best resources for the information.
Another excellent source is the Juniper Web site, itself, at www.juniper.net/techpubs.
The documents at this site will be referenced throughout this book.

Certification Preparation Guide

This book is an excellent study guide for Juniper Networks certification. Juniper
Networks has an outline on its Web site, as shown later, that provides some guidelines
regarding technical requirements and how to prepare for both the JNCIS and JNCIE
examinations. You will notice, as you read this book, that we have endeavored to keep
our text within the recommended outline published by Juniper Networks. We feel this
makes the book a useful educational tool for you as you prepare for the JNCIS
certification.
Downloader demo watermarks
The list of references shown later should, of course, be viewed as a broad overview from
which the test designers construct the examination question bank. The information, from
the official Certification Preparation Guide on the Juniper Networks Web site at
29
 1. Juniper Networks from the Internet to the Classroom
www.juniper.net/training/certification/prep_guide.html, is included here for you to use as
a reference when preparing for the exam.

Recommended Reading
The first step in preparing to take any course or certification exam is adequate
preparation. This is especially true if you are preparing for a hands-on practical
certification test. One of the best ways to prepare for a Juniper Networks certification is,
of course, to read this book. The exam also presumes a certain level of knowledge. One
of the ways Juniper Networks developed the exam was to define the knowledge and
resources you should use to prepare. These requirements grow ever larger as you
approach the JNCIS level.
Based on the recommendations from Juniper Networks, we have developed a list of
books to help you prepare for the entire range of Juniper Networks certifications. This
recommended reading includes many popular networking books that have stood the test
of time and peer review, so we feel comfortable in recommending them.
Introductory text
Cisco Internetworking Handbook, 2nd ed., Cisco Press.

www.ebook-converter.com
TCP/IP theory
W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols, Addison-Wesley,
1994.
F. Baker (ed), RFC1812: Requirements for IP Version 4 Routers.
Jeff Doyle, Routing TCP/IP, Vols. 1 and 2, Cisco Press.
BSD Networking code
Gary R. Wright and W. Richard Stevens, TCP/IP Illustrated, Volume 2: The
Implementation, Addison-Wesley, 1995.
Downloader
BGP demo watermarks
Sam Halabi and Danny McPherson, Internet Routing Architectures, 2nd ed., Cisco
Press.
30
 1. Juniper Networks from the Internet to the Classroom
John W. Stewart, BGP4 Inter-Domain Routing in the Internet, Addison-Wesley,
1999.
OSPF
Thomas M. Thomas II, OSPF Network Design Solutions, 2nd ed., Cisco Press.
John T. Moy, OSPF: Anatomy of an Internet Routing Protocol, Addison-Wesley,
1998.
ISIS
ISO10589: IS-IS Intradomain Routing Protocol.
RFC1195: Use of Open Systems Interconnection (OSI) IS-IS for Routing in TCP/IP
and Dual Environments.
IGMP, DVMRP, PIM, and MSDP
Beau Williamson, Developing IP Multicast Networks, Cisco Press.
Dave Kosiur, IP Multicasting, Wiley Computer Publishing, 1998.

www.ebook-converter.com
Thomas A. Maufer, Deploying IP Multicast in the Enterprise, Prentice Hall, 1998.
RSVP
David Durham and Raj Yavatkar, Inside the Internet's Resource reSerVation
Protocol: Foundations for Quality of Service, John Wiley & Sons.
MPLS
Bruce S. Davie and Yakov Rekhter, MPLS: Technology and Applications, Morgan
Kaufmann Publishers.
Simple Network Management Protocol (SNMP)
Downloader
William Stallings, SNMP, SNMPv2,demo watermarks
SNMPv3, and RMON 1 and 2, Addison-Wesley,
1993.
QoS and DiffServ
31
 1. Juniper Networks from the Internet to the Classroom
Kalevi Kilkki, Differentiated Services for the Internet, New Riders Publishing.
Zheng Wang, Internet QoS: Architectures and Mechanisms for Quality of Service,
Morgan Kaufmann Publishers.
Paul Ferguson, Geoff Huston, Quality of Service, John Wiley & Sons.
Frame Relay
Walter J. Goralski, Frame Relay for High-Speed Networks, John Wiley & Sons.
SONET
Walter J. Goralski, SONET, McGraw Hill.
Uyless Black, SONET & T1 Architecture, Prentice Hall, 1997.
ATM
David E. McDysan and Darren L. Spohn, ATM Theory and Applications, McGraw-
Hill, 1998.

www.ebook-converter.com
David Ginsburg, ATM Solutions for Enterprise Internetworking, Second Edition,
Addison-Wesley, 1999.
Point-to-Point Protocol (PPP)
James Carlson, PPP Design, Implementation, and Debugging, Second Edition,
Addison-Wesley, 2000.

Solutions and Technology Resource Center

Juniper Networks has assembled a repository of technical data at
www.juniper.net/techcenter. This area of the Web site is available to everyone. If you do
not have access to all of the books listed previously, this is a great alternative for
accessing technical resources and reading material. You will find resources that range
Downloader demo watermarks
from solution documents, interoperability papers, performance analysis, technology
notes, and white papers on various topics. You are definitely encouraged to take a look at
this area.

32
 1. Juniper Networks from the Internet to the Classroom
Chapter Summary
In this chapter, we have discussed the evolution of the Internet and how router
architectures have changed to meet the demand of services being offered, such as voice
and video. This chapter pointed out some of the problems associated with the past and
current architectures and the ability to provide IntServ. It also provided an overview of
some of the methods of supporting IntServ, such as RSVP and DiffServ. These, coupled
with MPLS, are playing key roles in traffic engineering. In addition, MPLS is being
expanded further and further, supporting both traffic engineering and VPN technologies.
This chapter also discussed Juniper Networks' product positioning and how the M-Series
fits in to the key core, edge, and mobile markets. The M160 is used predominately in the
ISP carrier core space, while the M40e is making its way into the edge market with its
added redundancy over the original M40. The J20 GGSN node, created through a joint
venture with Ericsson, and the G10 CMTS, offered through an acquisition, were both also
discussed. With these product offerings, Juniper Networks is able to focus on multiple
market segments and to evolve into other markets. The company's ability to position a
product and provide a reliable path of scalability and support makes it not only a leader
of current times, but likely to be a major innovator of the future.
Finally, this chapter discussed Juniper Networks' commitment to education and
www.ebook-converter.com
certification. With the expansion of its curriculum, Juniper Networks now provides
introductory and advanced course offerings. Specialized courses, such as Advanced
MPLS and Advanced VPN, further signify the company's commitment to providing
quality education for emerging technologies. In addition to its educational offerings,
Juniper Networks has a certification program that not only tests platform knowledge, but
internetworking theory as well.

Bibliography

[1] See Robert H. Zakon, “Hobbes' Internet Timeline,” 1993–2002, at

Downloader demo watermarks

www.zakon.org/robert/internet/timeline.
[2] Based on independent testing performed by Light Reading and Network Test. See
www.lightreading.com for a full report.
33
 1. Juniper Networks from the Internet to the Classroom

www.ebook-converter.com

Downloader demo watermarks

34
[ch01rfc1633] IETF RFC—RFC 1633, Integrated Services in the Internet Architecture:
An Overview. B. Braden, D. Clark, S. Shenker. 1994.
[ch01bib02] Lance Freedman,, et al. (under the Auspices of Dr. Luiz DaSilva).
“Bandwidth Brokers.” Blacksburg, VA: Virginia Polytechnic Institute and State
University Department of Engineering, 2001.
[ch01bib03] Halabi, Sam, and Danny McPherson. Internet Routing Architectures, 2nd
ed. Cisco Press, <year>2000</year>.
[ch01bib04] www.juniper.net
[ch01bib05] www.lightreading.com
[ch01bib06] Zakon, H. Robert “Hobbes' Internet Timeline,” 1993–2002, at
www.zakon.org/robert/internet/timeline.

www.ebook-converter.com

Downloader demo watermarks

35
 2. Networking Primer
Chapter 2. Networking Primer
This chapter discusses the general concepts and features of network technologies
pertinent to routers from companies like Juniper Networks. If you have sufficient
knowledge of networking basics, you can probably either skip this chapter or just skim
unfamiliar sections. This chapter will give you the fundamental knowledge needed in Part
III to properly configure interfaces on Juniper Networks routers. A proper in-depth
discussion of networking technologies is beyond the scope of this book. For more
information regarding many of these technologies, please read the bibliography at the end
of this chapter and the recommended-reading list from Chapter 1.
Standards form the basis for all network interoperability. If standards are maintained,
then different vendors' equipment should work together seamlessly (at least in theory). A
quick review of the open systems interconnection, or OSI, model and the portions of it
we are concerned with will assist in understanding the different functional parts of
networking. This fundamental knowledge of layered networking is important for design
and configuration, but more importantly for troubleshooting. This discussion is followed
by an explanation of encapsulation using the analogy of a mailed letter, which explains
the method that keeps functional areas from affecting one another.
The rest of this chapter covers transmission technologies. Basic technologies, such as
www.ebook-converter.com
Ethernet, packet-switched networks, ATM, SONET, and others, will be discussed as the
technologies that carry IP. The last section discusses IP, how it is used, as well as
identifying a range of IP addresses with a subnet mask and how to manipulate that mask
for use in routing.

Overview of the OSI Model

There are many different parts of network systems that must interact to allow devices to
communicate with each other. People can make each of those various parts in different
companies across the world, but the parts must still function together. The ability of a
program written in Seattle to work on a computer made in Boston and communicate over
a network in Australia is achieved through strict adherence to published global standards.

Downloader demo watermarks

Networked devices use standards based on the OSI reference model. This model has
different layers, requiring component creators to focus on compatibility with the
standardized layers just above and below, and not with all the rest. This saves time and
keeps applications from becoming too complex. Thus, engineers need only know the
36
 2. Networking Primer
details of the layer that is their responsibility in order to create an application that will
perform properly with other applications.

OSI Layers and Functions

There are seven layers in the OSI model. These layers are stacked vertically, passing
information up and down to each other (Figure 2-1 illustrates these layers).
Application layer—Layer 7, the application layer, is at the top of the stack. It is the
program that the user accesses to send or receive information on the networked
device. E-mail, World Wide Web, and FTP are all popular applications that transfer
information. The information from this layer is sent to the presentation layer for
formatting.
Presentation layer—Layer 6, the presentation layer, is responsible for formatting and
presents data to the application layer in a manner that the application will
understand. For example, if you are watching video online, this layer presents the
video format that the application (video viewer) will understand and be able to
present properly for the user. It can translate 64-bit integers to 32 bits or invert for
medium access control (MAC), Motorola to Wintel bit orders. The data is then sent
to the session layer to have a connection created to send the data.
www.ebook-converter.com
Session layer—Layer 5, the session layer, is responsible for initiating and closing
down communications on behalf of the upper two layers. When data requires
transmission, the session layer can start the process of communicating that
information to a distant location. When you are ready to send e-mail, this layer opens
the session to the server to which the e-mail will be sent, then sends the data to the
transport layer. The session layer keeps track of the communication and ensures that
it is completely sent. When it has been, the session layer tears down the
communications channel.
Transport layer—Layer 4, the transport layer, works by chopping up the data into
usable segments and determines how the data will be sent. For example,
Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) are two
Downloader demo watermarks
different protocols that the transport layer can use to send data. TCP is connection-
oriented, where two devices will acknowledge the data being sent. UDP is
connectionless and is sent without any acknowledgment of a successful and complete
transmission. (TCP and UDP are discussed further later in this chapter.) After
37
 2. Networking Primer
segmentation and sequencing, the data is sent down to the network layer for network
addressing in a packet.
Network layer—Layer 3, the network layer, is the one we are most concerned about
in routing. This is the OSI layer that assigns and structures addressing for the Internet,
which is known as IP addressing. IP addressing allows data to travel across many
networks to a unique specific destination. This is analogous to the address on a letter
that ensures the letter gets to its destination: The network layer ensures that the data
gets to the proper recipient. It takes the segments from the transport layer and forms
a packet around the segment. This packet has the IP addressing information for the
destination. (IP and addressing are discussed in greater detail later in this chapter.)
Data link layer—Layer 2, the data link layer, sets up the data for sending in the
physical layer. Although the network layer destination address might be many
devices away, the data link layer is only worried about getting it to the next device on
the route. The data link layer takes the packet from the network layer and
encapsulates it in a frame, transferring it into a form that can then be passed to the
physical layer for transmission into bits. Ethernet and Frame Relay are two very
popular data link technologies. (These Layer 2 protocols and more are discussed
more in depth later in this chapter.)

www.ebook-converter.com
Physical layer—Layer 1, the physical layer, is the first layer and describes the set of
standards that convey the actual digital data. The data link layer sends a stream of
binary data to the physical layer that actually sends the 1s and 0s to the next device
along the route to the destination. Shielded wire, twisted pair, fiber, infrared, and
radio wave are all mediums in which devices can communicate on the physical layer.
When you plug a fiber cable into a port, the port is actually the start of the physical
layer.

Downloader demo watermarks

38
 2. Networking Primer

Figure 2-1. The OSI Model Network Standard

Note

www.ebook-converter.com
The physical layer is one of the most important places to start troubleshooting.
Hours upon end can be spent troubleshooting networks because a cable or
connector was bent and not making contact. Standard troubleshooting
techniques involve starting at the physical layer and working your way up.
A device will communicate down the OSI stack, across the network, and up the OSI stack
of the receiving device. This process ensures that as information is manipulated on
leaving the sending device, those manipulations are equally copied in reverse order by the
receiving device. In Figure 2-2, the application layer sends information down through the
layers on PC A, across the network, to PC B, which will then send the information up the
OSI stack to the application layer on the receiver. Once the application layer processes
the data on the receiver, it can then be useful to the user.

Downloader demo watermarks

39
 2. Networking Primer

Figure 2-2. OSI Communications between Devices

www.ebook-converter.com
IP Suite
IP was originally developed by the U.S. government for research. The original IP
specification was four layers and was known as the DoD IP model after the U.S.
Department of Defense, which developed the Internet for U.S. government agency
communications. Owing to the widespread use of the model, it is known now as the
Internet Protocol Suite.
The four layers of the DoD IP model and how they map to the OSI reference model are
shown in Figure 2-3. Layer 4 of the DoD model is the application services layer and
represents all of the functions of the top three layers of the OSI model. Layer 3 of the
DoD model is the transport layer, which is responsible for the same functions of
acknowledgment and sequencing as the OSI third layer. Layer 2 of the DoD model is
Downloader demo watermarks
known as the Internet layer and is the responsible for IP addressing. Layer 1 of the DoD
model combines the physical and data link layers of OSI and is known as the network
access layer.

40
 2. Networking Primer

Figure 2-3. The IP Suite—A Common Protocol Implementation

A good analogy of OSI stack system operation is the process of one person drafting and
sending a letter to another. There are some predefined rules between the sender and the
recipient that the sender would use to ensure the intended receiver was able to receive
the letter, keep the pages in order, and understand what information the sender wished to

www.ebook-converter.com
convey. The purpose of drawing this analogy is to show that as things change at Layers 1
and 2, the upper layer information stays the same. In this way, data can be sent across
various networks without being altered.
How does this model allow for layered separation and why the letter analogy? This is how
encapsulation works. Encapsulation is the process of taking one piece of data and adding
a front (header) and a back (trailer). This allows for different devices to use only those
layers they need through the process of chopping, packetizing, and framing the upper
layer data in a standard format. The following details how data would be transmitted
according to this analogy.
Layer 7—Application: A letter is written in a computer application (e.g., Netscape
Communicator or Microsoft Outlook).

Downloader
Layer 6—Presentation: A common demo
language and style watermarks
would have to be used.
Layer 5—Session: A standard envelope with a return receipt would be used. The
return of this receipt would acknowledge and end the mail sending process.
41
 2. Networking Primer
Layer 4—Transport: If multiple pages were created, they would be numbered. If too
many pages for one envelope were drafted, then several envelopes could be used,
and they too would be numbered as 1 of 4, 2 of 4, and so on, so that the correct order
could be kept on the receiving end.
Layer 3—Network: A destination address and a sending address (the source) would
be added to ensure that the letter reached the correct individual and the receiver
knew whence the letter originated.
Layer 2—Data link: The envelope with the far end address would be put into a
mailbag for use on trucks.
Layer 1—Physical: The truck mailbag would be put on the truck and travel until it
reached the end of the truck's route.
Layer 2—Data link: The address envelope (Layer 3 packet or package) would be
taken out of the truck mailbag and put in an airplane mailbag.
Layer 1—Physical: The airplane mailbag would then be placed on an airplane and
continue on until it was ready to be transferred again to a truck, which would require
a truck-type mail bag.

www.ebook-converter.com
Just as in the analogy above, Layers 1 and 2 can be changed several or even many times
as the packet makes progress towards the destination. Once the destination has been
reached, Layers 3, then 4 can be stripped by the receiver and the return receipt signed
(Layer 5) to present the data to the reader, ending the communications channel. The
letter inside, the envelope, and the destination-addressing scheme are never altered by
the lower two layers' independent processes. The truck and the airplane transportation
are not affected by what is in the envelope. The Layer 3 address would be looked at to
forward the letter appropriately, but it would not be altered. This is the layer separation
that allows the different components to work together as long as the standards are
adhered to.

Encapsulation at the Lower Layers

Downloader demo watermarks
Networking in general is predominately focused on Layers 1 to 4, or the lower layers
(with the upper layers consisting of 5 to 7). When discussing networks or systems, quite
often the terms upper layer and lower layer are used. Layers 1 to 4 are the layers that
Juniper Networks routers use to accomplish the task of getting data from point A to point
42
 2. Networking Primer
B. Although most routing functions do take place on Layer 3 at the network address,
Layer 4 TCP/UDP ports can be used for giving preference or forwarding decisions for
packets.
Components of Layers 1 to 4 accomplish network transmission and reception of the
upper-layered data. You can think of Juniper Networks routers as a very fast
transportation system. Figure 2-4 illustrates the encapsulation of data as it moves down
the layers for transmission. As the data moves down the stack, each layer adds
information for the corresponding layer on the receiver. At Layer 4, a segment of data is
created, then encapsulated in a Layer 3 network packet, which gets wrapped in a Layer 2
data link frame, then transmitted on the physical Layer 1.

www.ebook-converter.com
Figure 2-4. Data Encapsulation
In the receiving stack each layer reads the necessary information for its particular layer,
strips that information off, and forwards the data upwards.

Network Devices
Different network devices were created to aid in the transmission of data at the different
layers. At the data link layer, bridges and switches are used. Bridges and switches work at
Layer 2. They can connect various physical media as long as the data link protocol is the
same. At Layer 3, the network layer, routers from companies such as Juniper Networks
Downloader demo watermarks
are used. Routers can connect different data link networks as long as they use the same
network layer protocol. Each of these devices forwards data based on the standards of
the layer on which they work.
Most network devices and technologies can be thought of as part of one of two groups,
43
 2. Networking Primer
local or wide. Local-area network (LAN) devices usually connect users centered in a
close geographical area. These devices are usually switches or small-access routers.
WAN devices typically connect groups of LAN devices over long distances. For the most
part, a Juniper Networks router is a device that can connect groups of LANs and WANs
together. Since the OSI layers work together, different data link layers can be used to
forward a single type of network layer data. Going back to the example of the letter, the
envelope can travel in a truck, then an airplane, then in a truck again. The truck is used
locally and the airplane transports the letter across long distances.
So too can networking use different methods of transportation. It is very typical for data
to move from LAN to WAN to LAN in order to get from the sender to receiver. In Figure
2-5, there is a sender A and a receiver B. The data has to go through the LAN in
Washington D.C. to get to the WAN that will allow it to be transferred up the East Coast
WAN to the LAN in Boston. A Juniper Networks router connects the LAN to the WAN.
One port of the router is connected to the LAN and one is connected to the WAN. In
addition, the cloud representing the WAN could be made up of many Juniper Networks
routers in a network. Juniper Networks has developed a wide variety of ports, allowing
them the ability to forward data from and to LANs through WANs for many situations.

www.ebook-converter.com

Downloader demo watermarks

Figure 2-5. LAN-WAN-LAN Communication

44
 2. Networking Primer
Bridges and Switches
A bridge is normally used to connect two groups of similar data link devices, such as PCs
on Ethernet. A bridge can divide an overloaded LAN network in two groups, managing
the communications between them. This allows the LAN to continue to function
seemingly as a single group. As the LANs get larger, more ports are needed on a bridge to
divide the LAN into more groups. Eventually each data device is able to have its own
port; the bridge is then called a switch because it switches data between the ports. A
switch greatly increases a LAN's communication efficiency. Every device has its own
port—it's own private connection. With every device having a dedicated, rather than a
shared, connection, a device is able to send and receive more data through LANs and
ultimately through WANs. The switch can manage the communication between LAN
devices much more quickly and efficiently than the devices themselves when all of them
are essentially trying to talk at the same time.

Note
A bridge that connects dissimilar data link devices is called a translational
bridge and one that connects similar data link devices is properly called a
transparent bridge.

www.ebook-converter.com
Other types of switches operate in the WAN. These use protocols like ATM or frames
from a Frame Relay network. These are the types of switches in the middle of large
networks to which Juniper Networks routers are connected in order to pass data.

Routers
Routers work at the network layer. They look at the destination address of the IP packet
and forward the packet in the right direction. Juniper Networks routers can connect
different types of LANs and WANs. In addition, Juniper Networks routers can connect
different types of WANs together on a very large scale. In Figure 2-6, a Juniper Networks
router takes in a frame from the Layer 2 data link LAN protocol (2L), then strips off the
Layer 2 LAN information to look at the Layer 3 network information. The Layer 3
Downloader demo watermarks
information must be looked at to determine where the data must be sent, but it is not
manipulated or changed; it is merely observed. This is called a Layer 3 lookup because
the device is looking at the Layer 3 protocol address to determine the correct path to
forward it upon. Higher-layer information is usually not looked at. The router then
45
 2. Networking Primer
decides in which direction (out of which port) to forward the information, changes any
Layer 3 information needed (e.g, TTL), adds Layer 2 WAN (2W) information,
encapsulates the packet, and the router sends the data on its way.

Figure 2-6. Layer 3 Lookup

Transmission Technologies
The last section gave an overview of where a Juniper Networks router fits into the
scheme of a network; this section will discuss those LAN and WAN technologies at
Layer 2 that connect the routers to each other. As you learn to configure a Juniper

www.ebook-converter.com
Networks router in Part III, you will see it is best to configure the network by the layers
up the OSI model (starting at Layer 1 and moving upward through the layers). Starting at
Layer 1, the physical layer, if the cable or fiber is not plugged in or is plugged in
incorrectly at the physical layer, nothing else will work no matter how well it is
configured. If Layer 2 is not working properly, then Layer 3 will not communicate. This
is why even though routers work primarily at Layer 3 to forward packets, it is important
to know what is happening at the data link layer as this is the layer that the network
packets will flow across. After the physical layer is connected, the data link layer is
configured next. After the data link layer, the network layer addressing is assigned. That
is where the power of a Juniper Networks router resides, in its ability to forward IP
packets.
Data link protocols can be grouped into two categories: LAN and WAN protocols.
Originally, the difference between LAN and WAN technologies had to do with the
Downloader demo watermarks
distance the protocols could cover geographically. With advances in technology, that
distinction is no longer as clear. Ethernet is an example of a broadcast protocol (LAN),
while Frame Relay, ATM, PPP, and High-Level Data Link Control (HDLC) are
examples of nonbroadcast protocols (WANs).
46
 2. Networking Primer
LAN Protocols
Originally, data devices were connected directly to each other. This created a mess
quickly because as more devices wished to speak to each other, each would have to add
connections for all others. Ethernet is a standard LAN protocol that allows more than two
users to be connected to the network at the same time. As seen in Figure 2-7, five devices
are connected to the same Ethernet link. This allows all the devices to hear whenever any
device talks. Think of a hallway with five people standing in doorways. If one wishes to
talk to another three doors down, everyone else will hear him or her at the same time.
This is called a broadcast-type network protocol. When host A sends out data, every
device on the link will receive and look at it to determine if it is the intended receiver. If
not, it will discard the data.

www.ebook-converter.com

Figure 2-7. Example of Using Ethernet to Connect Devices

In Ethernet, the group of devices that can hear each other's transmissions is called a
collision domain because sometimes two devices try to talk at the same time and their
Downloader demo watermarks
transmissions collide. They will then send their transmissions again at slightly different,
randomly determined times. There has to be a random function in the resending, or the
devices would send again at the same time and have another collision. As more devices
fill a collision domain, more collisions occur. A bridge can be inserted to break the
collision domain in half, effectively allowing everyone more talking time.
47
 2. Networking Primer
When one device does not know the data link address for a destination, or if a device
wants to send data to everyone at once, it sends what is called a broadcast, a frame that
has an address that everyone will listen to. Bridges forward broadcast frames because
they do not know for whom the frame is intended. A bridge learns the Layer 2 addresses
of the connected devices on the different ports of the bridge, then records the data link
source addresses of the devices connected to each port by listening to the
communications. It can then determine when it has received a frame from one port that is
destined for a device located on another port (if a bridge does not know which port a
device is on, it will send the frame out to all but the incoming port).
As a bridge learns the addresses of the devices connected to each port, it will keep these
in a temporary table. A bridge can remove an address from the table if it hasn't heard
from a device for a specified time. If the frame is destined for a device that is not in the
bridge's table, it will forward the frame out of every port except the originating port.
For example, in Figure 2-8 a bridge connects two collision domains. The bridge keeps a
table that maps the Layer 2 addresses of devices to the ports they reside on. If collision
domain A sends a frame to collision domain B, then port 0 will hear the transmission and
look up the destination port for B. If the bridge knows that B is also off port 0, then it will
drop any traffic from A, since B will get it directly. If the bridge does not know on which
port B resides, then it will forward that traffic to any port except the one from which the

www.ebook-converter.com
transmission was received to ensure that no matter where B is, it will receive the
transmission (in this case the bridge would forward that data to collision domain B).

Downloader demo watermarks

48
 2. Networking Primer
Figure 2-8. A Bridge Forwarding Traffic Between Collision Domains
On a network, one device may wish to communicate with all other connected devices at
once and thus sends a broadcast. All devices that can receive a Layer 2 broadcast form a
group called the broadcast domain. Although bridges may have cut down collisions, by
forwarding broadcasts bridges can still create congestion. This can be a problem in LANs
if too many devices are broadcasting. Routers are then used to break up the broadcast
domain. As mentioned earlier, Ethernet is a type of broadcast protocol. For a wonderful
in-depth discussion of bridging concepts, read Radia Perlman's Interconnections, Second
Edition, (Addison-Wesley, 2000).

The Standard: Ethernet

Ethernet is a standard data link layer protocol that is used for LAN connections. Ethernet
is the basis for the 802.3 IEEE specifications that govern how the protocol is to be
implemented. This ensures that different manufacturers will make equipment components
that will communicate with each other. A router, a switch, and a server with Ethernet
interfaces should all communicate properly if the interfaces adhere to the standards.
Ethernet is a carrier-sense multiple-access with collision detection (CSMA-CD) protocol.
In the physical layer, bits are sent with low voltages of electricity called a carrier. An

www.ebook-converter.com
Ethernet device will listen for a carrier before sending to ensure no one else is using the
network. In this way, many stations can access the network. If a collision is detected, the
devices whose traffic collided send a blocking signal to ensure that everyone realizes that
a collision occurred and waits a certain amount of time, plus a small random amount,
before retransmitting. The random amount of time added to the specified time keeps two
devices that have collided from recolliding.
Regular Ethernet typically runs at 10Mbps, or 10 million bits every second, and is usually
transmitted over unshielded twisted pair (UTP), such as Category 5 cabling. In a
nonbridged environment, every device in a collision domain on the Ethernet has to share
the 10Mbps. In a desktop switching network, every (or at least most) devices will have
their own 10Mbps Ethernet connection directly connected to the switch, which reduces
the collision domain, but since every device can still receive all other's broadcasts, all are
Downloader demo watermarks
still all in the same broadcast domain. A switch has a backplane (sometimes called a
switch fabric) through which data passes when it has been received in one port and must
be forwarded out another.
The Ethernet protocol uses addresses in the Layer 2 frame to send and receive data. This
49
 2. Networking Primer
Layer 2 addressing is called the MAC address. This is a 48-bit address that uniquely
identifies the device on the network. On Juniper Networks interfaces these are called
hardware addresses and are written in a hexadecimal format, such as
00:90:69:9e:80:00. These addresses are usually hard-coded at the factory into the
Ethernet card and are often burned in to the network interface card (NIC), so they are
sometimes also known as burned-in addresses (BIAs).
Figure 2-9 shows an Ethernet frame separated into fields. The parts of an Ethernet frame
are used to deliver the frame to the receiver, allow the receiver to know which device
originated the frame, and to ensure that the frame arrived intact.
The 56-bit preamble field lets the receiving device know that an Ethernet frame is
coming. The preamble consists of alternating 1s and 0s.
The 8-bit start of frame delimiter (SFD) field tells the receiver exactly where that
frame starts by ending in two 1s.
The 48-bit destination IP address (DA) is the destination MAC address of the
destination Ethernet device.
The 48-bit source IP address (SA) field is the source MAC address of the device
sending the Ethernet frame.
www.ebook-converter.com
The 16-bit length field describes the length of the data in the frame. Older protocol
implementations had a type field for what type of data was in the frame. There are
several older implementations of Ethernet that were developed before the IEEE
drafted the standard.
The variable data field carries the Layer 3 packet and upper-layer data. The entire
Ethernet frame has to be a minimum of 64-bytes long. If the data field is so small that
the whole Ethernet packet will come in under this size, it must be padded to get it to
64 bytes total. The maximum size for the data field is 1,500 bytes.
Finally, the sending device creates the 32-bit frame-check-sequence (FCS) field by
running an algorithm on the bits of the frame. This produces a binary number that is
Downloader demo watermarks
added at the end of the frame as the check sequence. As the receiver reads the frame,
it runs the same process and comes up with a number that should match the FCS. If it
does, then the frame has not been scrambled or corrupted during transmission.

50
 2. Networking Primer

Figure 2-9. Fields in an Ethernet Frame

Ethernet can run in half-duplex or full-duplex mode. Half-duplex is the mode of
communications when only one party to the conversation can talk at a time. This is
similar to communicating by walkie-talkie: The receiver must wait until the sender
finishes before sending a reply. Full-duplex is the mode that allows both the devices to
send and receive at the same time. This would be similar to talking on a telephone: Both
devices can transmit and receive simultaneously.

Note
Most end-stations, like workstations or servers, are half-duplex by default,
whereas most switches and routers will either attempt to autonegotiate or be set
to full-duplex by default. It is usually best just to set what you wish to ensure
both sides of the link are set alike.
Since every device can hear a broadcast from any device in that broadcast domain, an

www.ebook-converter.com
easy way for a station to learn the Layer 2 MAC address for a destination Layer 3 IP
address is to broadcast a request for the owner. If you are device A and you have data for
a Layer 3 address B, but you don't know the Layer 2 MAC address for B, you simply
send out a broadcast Ethernet frame to everyone asking who owns Layer 3 address B and
what its Layer 2 MAC address is. Device B sends the proper MAC address, and now A
can send data across the physical link with the appropriate Layer 2 destination address.
This process of broadcasting to all stations in a broadcast domain for a particular Layer 2
address is called Address Resolution Protocol (ARP). It allows a sending device to find
out what the Layer 2 address is for a Layer 3 destination.
But what happens if the device determines that the Layer 3 address is not within the
broadcast domain? To determine whether or not a Layer 3 address is in the broadcast
domain, the source device sees if the destination address is within the range of the local
broadcast domain. An administrator has configured a router to allow the forwarding of
Downloader demo watermarks
data out of the network. The router in this case is known as a default gateway or gateway
of last resort. Once the device determines that the destination host is not in the broadcast
domain, it will send an ARP request to the router. The router is where a device sends data
that is destined for a nondirectly connected network to allow the router to pass the data
51
 2. Networking Primer
to another network.

Fast Ethernet
Sometimes the flow of data can cause bottlenecks at areas of congestion. Giving all the
devices on a network a full 10Mbps sounds like a good idea at first, but this can overload
connections that many devices try to access at once. Even if five users trying to send data
to the same server all have 10Mbps connections, the server can only receive at a rate of
10Mbps no matter what. The connection to the server would be a bottleneck. Another
common bottleneck can occur when many users on a switched 10Mbps Ethernet
connection are trying to send or receive information through one router or other single
exit point on a network. For example, everyone arrives at work in the morning and the
first thing they wish to do is check their e-mail, as shown in Figure 2-10.

www.ebook-converter.com

Figure 2-10. A 10Mbps Bottlenecked Ethernet Network

Fast Ethernet was created to eliminate some of the bottlenecks. This allows the Ethernet
standard to be implemented at 100Mbps. With an Ethernet switch able to manage faster
communications, devices could get a Fast Ethernet connection to the switch if that was
an area of congestion. Several users at a normal 10Mbps could then transfer data
Downloader demo watermarks
simultaneously to a server connected to the switch at 100Mbps as shown in Figure 2-11.
The server has a connection 10 times the speed of the connection that each of the clients
has. This means that the server can talk with all three of the devices and still have
70Mbps left in the bandwidth available to the switch for more data to be sent. In addition,
52
 2. Networking Primer
Fast Ethernet can be implemented over UTP copper (similar to standard Ethernet) or
fiber-optic cabling. Fiber-optic cabling allows transmission over much longer distances.

Figure 2-11. A Mixed 10- and 100Mbps Ethernet Network

Gigabit Ethernet

www.ebook-converter.com
Gigabit Ethernet is primarily run on fiber. With a speed of 1,000Mbps, this is a LAN
protocol suited to use between network devices where high bandwidth is needed. As a
100Mbps connection can alleviate bottlenecks from the end-stations for many 10Mbps
connections, so can Gigabit Ethernet alleviate bottlenecks caused by too many 100Mbps
connections accessing the same end-stations.
This covers the Ethernet protocol group and its various speeds. Next is the group of
WAN protocols and their specifics. These are the protocols that are primarily used to join
LANs or groups of LANs together over large geographic distances.

WAN Protocols
WAN technologies were developed to cross very large geographical distances. Originally,
Downloader demo watermarks
this might have applied to long-distance telephony. An early example of a WAN would
have been the connections that linked two small towns' switchboards. These towns'
switchboards were local for themselves, but were required to make connections across
distances to pass information. This section describes the modern protocols used to
53
 2. Networking Primer
transfer data across great distances.

WAN Technologies
The telephone is one of the earliest methods of using a network to pass information. The
circuits were set-up manually by an operator switching the connections together. One
circuit was required for each conversation, and the wire could only hold that one
conversation.
Once the telephone companies digitized voice telephone circuits, multiple conversations
could then be combined on a single wire. This process, called multiplexing, greatly
increased the numbers of circuits that could be transmitted on the available wire that
connected the large telephone switches. Instead of requiring a single set of wires for each
circuit, now one set could run many circuits simultaneously.
From this new development came a specific process for multiplexing digital circuits. It
based the mixing of different circuits on timing. Each circuit had a place in the stream of
1s and 0s and could take its turn having data sent. As long as both ends agreed on the
timing, the sending device and the receiving device would know which bits belonged to
which circuits. This is known as time division multiplexing (TDM). In Figure 2-12,
modem 1 is mixing the bits of circuits A, B, and C in a specific order using TDM. As long

www.ebook-converter.com
as modem B, on the right, is correspondingly configured, it knows which bits belong to
which circuits and can separate and demodulate them appropriately back to separate
circuits.

Figure 2-12. TDM

Downloader demo watermarks

TDM devices originally had to be set up manually on both sides to correlate which
circuits would be sent into which timeslots during the multiplexing. As this became more
cumbersome with the addition of many more circuits, devices were invented that would
have administrative digital information inserted into the normal circuit bits at regular
54
 2. Networking Primer
intervals. This allowed the TDM devices to communicate with each other to automate
many routine setup functions. This was known as in-band management because the
management communications were taking place in the same data stream as the circuits
were traveling.
In Figure 2-13, TDM device A has inserted management bits (M) into the data stream to
communicate with TDM device B.

Figure 2-13. TDM with In-Band Management

DS Hierarchy
Further developments of the TDM standard led to a full digital hierarchy in frastructure in

www.ebook-converter.com
America. Voice circuits are generated 8 bits at a time that are sampled 8,000 times per
second, for a constant 64,000-bps circuit, or 64Kbps (1,000 bits = 1 kilobit).
This digital hierarchy allows 64Kbps circuits to be multiplexed in greater numbers in a
scalable manner. The 64Kbps circuit became the standard and was named a digital
stream-0 (DS-0) to represent the base circuit. To allow the standard multiplexing of many
DS-0s, a digital stream (DS) hierarchy was implemented in North America.
When 24 DS-0s were multiplexed together, they created a DS-1. When DS-1s were no
longer sufficient to handle the number of circuits required, 28 DS-1s were combined to
create a DS-3. This ability to combine groups of circuits in great numbers allowed the
TDM networks to grow at rapid rates. Globally, a DS hierarchy was implemented on the
same DS-0, but on different multiplexed levels. The two most common DS hierarchies are
the U.S. standard and the worldwide standard (sometimes called E standard) listed in
Downloader demo watermarks
Table 2-1.
Table 2-1. DS Hierarchies

55
 2. Networking Primer
Mutliplex LevelNumber of DS 0sImplemented Bandwidth
DS-0 1Worldwide 64Kbps
DS-1 24United States 1.544Mbps
E-1 30Outside United States 2.048Mbps
E-3 480Outside United States34.368Mbps
DS-3 672United States 44.736Mbps
Due to the fact that the TDM networks were, at the lower level, the same 1s and 0s that
data networks used, devices were created that allowed data networks to call one another
just as people do using the phone: No modem was needed. A network administrator could
install a DS-0, several DS-0s, or a DS-1, depending on the requirement. This allowed
local networks to connect to each other over a wide area. Now, companies with LANs in
different geographic regions could have fast digital connections between them.
There is a disadvantage to circuit-switched networks, however. When a connection is
brought up, even if not much data is being passed, the full bandwidth is taken for that
particular connection. When a DS-0 connection is made, all 64Kbps is reserved for that
connection, even if it isn't being used. There was a need for a type of connection that
used only the bandwidth required or allowed traffic to multiple end points at once. This
type of network needed to switch the actual packets instead of the entire circuit.

www.ebook-converter.com
Frame Relay
A technology was developed that allowed one port on a device to have connections to
more than one destination device at the same time. The technology splits the physical
port, or interface, into logical multiple interfaces that can have different Layer 3
addresses as if they were physically separate. The data for a particular destination that
had been streamed in a specific timeslot would now be bundled in a packet. This allowed
the packets themselves to be switched between destinations. Frame Relay is a
nonbroadcast multiaccess (NBMA) technology. NBMA is considered nonbroadcast, for
two reasons:
1. A device cannot send to all the other devices on a particular network at once with a
single Layer 2 broadcast address.
Downloader demo watermarks
Multiple access means that each device can access more than one device on the same
2.
network.

56
 2. Networking Primer
Unlike an integrated services digital network (ISDN) circuit, Frame Relay allows one
physical connection to a WAN switch to have multiple Layer 3 addresses. NBMA
technology allows the splitting up of the physical layer interface into logical or virtual
data link layer units with different Layer 2 and Layer 3 addresses for each. The different
Layer 2 addresses are needed so that the WAN switch knows in which direction to switch
the frame.
Not every station on an NBMA network can be sent to at once; only those in which there
is a connection set up through the WAN switches can. In the header of the frame, there is
an identifier to allow the switch to forward the frame in the appropriate direction. Figure
2-14 shows an example of an NBMA network. Router A puts a Layer 2 identification
(ID) number of 25 on any frame to go to router B and of 33 for any frame to go to router
C. The switch node has a table that merely says: Any incoming ID 25 on Port 0, send out
Port 1, and any incoming ID 33, send out Port 2. In this manner, router A has access to
multiple devices with one physical connection, but cannot broadcast to both at once.
These connections to the other routers are called virtual because they are not real. The
routers act as if they are connected to each other, but in fact are connected to the switch
node.

www.ebook-converter.com

Downloader demo watermarks

Figure 2-14. NBMA Network
Frame Relay operates on the premise of circuit-like data links that are permanently
connected to other locations. These circuits are permanent because they don't have to be
57
 2. Networking Primer
brought up and torn down as an ISDN connection would, but they serve the same
purpose of maintaining a constant connection between two devices. In addition, they do
not take up the whole physical interface. The interface can be divided logically between
different Layer 3 addresses for different destinations. In Figure 2-15, office A has a
256Kbps leased line. The administrator wants two permanent virtual circuits (PVCs): one
128Kbps data link connection to office B and one 128Kbps data link connection to office
C. Now office A can communicate with offices B and C at the same time. If this were a
single connection circuit-switch technology, the connection between offices A and B
would have to be disconnected in order for office A to communicate with office C.

www.ebook-converter.com

Figure 2-15. Frame Relay PVCs

There are two different types of Frame Relay interfaces: point-to-point and multipoint.
Point-to-point allows only two devices to be connected to one PVC. Multipoint allows
more than two devices to be connected on the same PVC.

Downloader demo watermarks

But how does a packet-switched network (PSN) switch know where to send an incoming
frame? In the beginning of the frame, before the actual data, is the data link connection
identifier (DLCI), a 10-bit number that represents the PVC and is used as a Layer 2
address. Figure 2-16 shows an example of two point-to-point PVCs from New York, one
58
 2. Networking Primer
each going to Chicago and Boston. New York has PVCs set up on DLCIs 20 and 140.
Router Chicago has a PVC to New York using DLCI 315 and Boston has a PVC with
New York on DLCI 110. When the New York router has to send a packet to a Layer 3–
network destination through Chicago, it will send the frame out with a DLCI of 140. If it
has to send a packet through Boston, it will send the frame out with a DLCI of 20. When
the frame switch sees the DLCI from port 0, it references its switching table, which says
that any frame received on port 0 with DLCI 20 should be forwarded out port 2. Any
frame received on port 0 with DLCI 140 should be forwarded out port 1. This tells the
PSN switch in which direction the frame should be sent. This is the important part of the
Layer 3 to Layer 2 handoff. New York only has one interface connected to the frame
switch. The interface is split into virtual interfaces because you can have separate Layer
2 and 3 addresses on them. For the New York router, DLCI 20 would be mapped to one
Layer 3 address (the one that can communicate to Boston) and DLCI 140 would be
mapped to another Layer 3 address (one that could send and receive with Chicago).

www.ebook-converter.com

Figure 2-16. Frame Switch Using DLCIs

As more branch offices wished to be connected to New York, more PVCs could be
Downloader demo watermarks
added, and the DLCIs configured to send the frames along the PVCs to their appropriate
destinations.
This covers two popular WAN technologies of both the circuit-switched and packet-
switched types. As their speeds grew to the limits of electrical signals, optical devices
59
 2. Networking Primer
were needed to increase the speeds and allow larger aggregation of the network
connections. An optical standard that could accommodate both would be helpful. This
optical standard would need the capability to carry many multiplexed DS circuits on one
port. SONET and Synchronous Digital Hierarchy (SDH) were created to do just that.

SONET/SDH
In the TDM-standards arena, the DS standards evolved in North America (and Japan),
and the E standards evolved in Europe, then spread throughout the rest of the world. In
the optical-transmission arena, there are also two main standards: SONET was developed
in the United States while SDH was developed for international use. These are two very
similar physical standards for transmitting digital bits by light over fiber-optic cable.
When the copper-based TDM networks at the DS-3 speed were demanded more by end
users, a faster multiplexing scheme had to be implemented, one that could scale to much
greater speeds than electric pulses over copper. In addition, the new multiplexing scheme
would have to go further and be more flexible in inserting and dropping DS circuits. At
the time, to drop one DS-0 and add another to a DS-3 required that all of the DS-1s could
be separated (even if there was only one that needed to have a circuit inserted). An add-
drop multiplexer (ADM) was developed to allow a particular timeslot's data to be
removed and another's inserted in its place without the entire infrastructure having to be
www.ebook-converter.com
split apart and remultiplexed.
SONET was developed to carry multiplexed DS circuits. The SONET architecture is built
around a synchronous transport signal (STS). The STS is the electrical framing component
that is then transmitted into an optical signal called an optical carrier, or OC. Since
SONET is based on the TDM voice-circuit standards, the frame has to be sent 8,000
times a second to maintain DS hierarchy compatibility. This was extremely important
because SONET was first used primarily to multiplex ISDN circuits. Since the DS-0 is 8
bits sampled 8,000 times per second, SONET transmission had to match that for
consistency.
The STS-1 is built around the user data called a synchronous payload envelope (SPE).
The STS is broken into nine columns of 90 bytes for a total of 810 bytes. The
Downloader demo watermarks
transmission of 810 bytes at 8,000 times per second gives the base STS-1 a speed of
51.84Mbps. Out of 90 bytes in the column, there are a total of 3 bytes per row of header
information. Figure 2-17 shows the STS-1 and SPE format.

60
 2. Networking Primer

Figure 2-17. STS-1 and SPE Format

Bytes 1 to 3 are the header bytes. Each Row has 3 header bytes for a total of 27 for the
entire STS-1. Bytes 4 to 90 comprise the payload of each row. Each row is then sent one
right after the other. Byte 90 of row 1 is transmitted before byte 1 of row 2. The SPE is
packaged in 4-90-byte sections of the 9 rows. The main reason to show the STS in this
format is to illustrate the order in which the bytes are sent.
STS-3 combines three STS frames into a single set of rows and columns. Instead of 90
www.ebook-converter.com
bytes in a row, there are a total of 270 bytes in a row. The headers for STS #2 and STS #3
are added directly behind the headers of STS #1. SPEs 1, 2, and 3 are multiplexed at the
byte level, so the bytes are sent in the order 123, 123, 123 for the 261 bytes in the
payload part of the row.
Having a single STS capable of only carrying a single DS-3 did not help increase the
capacity of the lines between switches. A format of three STS frames multiplexed
together (called STS-3 or OC-3) allowed for three DS-3s to be combined together. The
total capacity of the OC-3 is 155.52Mbps (3 × 51.84). When more bandwidth was
required, standards were then implemented to combine 12 STS, 48 STS, and 192 STS
frames for data rates of 622.08Mbps, 2,488.32Mbps, and 9,953.28Mbps respectively.
To increase the flexibility of the SPE, not just a single DS-3 can be placed into an SPE to
Downloader demo watermarks
be framed in an STS, but many DS-1s, E-1s, or DS-0s can also be multiplexed in an SPE.
An SPE can be divided up into seven virtual tributaries (VTs). A VT can carry four DS-1s
or three E-1s, but cannot carry both. Different VTs in an SPE can carry different types of
circuits, but within a VT they all have to be of the same type. Four DS-1s in seven VTs
totals the 28 DS-1s in a DS-3.
61
 2. Networking Primer
Although circuit-switched networks developed the SONET protocol to multiplex many
DS circuits, packet-switched networks implemented SONET so they could use the
scalability of the STS-3 for carrying data. Instead of having three STS SPEs, each broken
into seven VTs, the STS-3 is left whole. This is called concatenation or unchannelized.
The whole STS-3 can be packed with ATM cells or IP packets, giving data rates greater
than 155Mbps. Sometimes this type of implementation is designated as OC-3c, with the
lowercased c designating the concatenated SONET frame. When the STS is filled with IP
packets, it is known as POS.
SDH is the standard developed and used outside the United States. This implementation is
based on synchronous transport module (STM) units, which use a base of 155.20Mbps
(STM-1). An STM-4 connection is 4 × 155.520Mbps, or 622.080Mbps. In terms of
bandwidth references, STM-1 equals an OC-3 (155.520Mbps). More information about
SONET and SONET standards can be found at
www.techfest.com/networking/wan/sonet.htm.

Dense Wave Division Multiplexing

Reaching up to OC-192 (approximately 10Gbps), SONET speeds have jumped
tremendously in the past several years, but a new technology using SONET technology
has increased these speeds by up to 64 times. This new technology is called dense wave
www.ebook-converter.com
division multiplexing (DWDM).
SONET is an optical technology that basically consists of shining a light or laser down a
glass fiber cable. Advances in laser and fiber technology have allowed different
wavelengths (colors) of light to be transmitted across a single fiber-optic cable. The way
this technology works is a wavelength multiplexer (wave mux) is fed several SONET
links. The wave mux will convert each of the SONET streams into a specific wavelength
on the DWDM link. One the far end, the wavelengths are demultiplexed into single
SONET links that are then sent to their destinations.
In Figure 2-18, routers Seattle, San Francisco, and San Diego have SONET links to a
wave mux. The wave max converts each SONET link to a different wavelength and
transmits them to the other end to be demultiplexed. Each wavelength is then converted
Downloader demo watermarks
back to normal and sent on its way to routers Boston, New York, and Washington D.C.
In this scenario, because router Seattle is only connected with router Boston, it cannot
transmit to router New York or router Washington D.C. In addition, router San Francisco
is connected only to router New York, and router San Diego to router Washington D.C.
62
 2. Networking Primer

Figure 2-18. DWDM

This is a tremendous advance in increasing the capacity available to high-bandwidth
networks. Each of the wavelengths of light can be a single data stream. As of this writing,
the bandwidth transmission record is 64 × OC-768 transmitted 2,500 miles. This equals
2.56 terabits per second, or 2,560Gbps! Although routers from Juniper Networks do not
have DWDM interfaces, there have been interoperability studies with DWDM device
manufacturers. DWDM can be a key component of a core network with long-haul (LH)
high-bandwidth links.
www.ebook-converter.com
HDLC
HDLC originally developed from protocols used to transport IBM systems network
architecture (SNA) traffic that was used by mainframe computers across WAN links.
HDLC is a full-duplex data link layer protocol for point-to-point, or sometimes
multipoint, serial networks and is one of the most widely used.
Originally IBM mainframes would talk to dumb terminals and poll them for data. The
dumb terminals could only speak when spoken to and would have to wait their turn. As
terminals became smarter, they were able to initiate their own communications with the
mainframe and with each other. These necessary actions preceded the current two types
of HDLC standard: unbalanced and balanced.
Downloader demo watermarks
Unbalanced mode is a master-slave-relationship-type mode. There is a primary and
secondary station when two devices are connected via HDLC in unbalanced mode. The
secondary station has to wait for the primary station to poll it before it is allowed to send
63
 2. Networking Primer
traffic. That traffic will then be acknowledged by the primary and passed on. This was
originally used for mainframe-to-terminal communications.
Balanced mode allows both devices to talk to each other at will and is the only network
implementation Juniper Networks uses for HDLC. Juniper Networks implements the
Cisco version of HDLC because of the wide use of that particular version.

PPP
PPP is another Layer 2 protocol only used for point-to-point connections, which is why it
is called the Point-to-Point Protocol. This protocol also had earlier roots. Originally,
Serial Line Internet Protocol (SLIP) was used in the earlier days of dialing into a device
with a modem. SLIP was not a very good protocol; it had no error detection, only
supported limited Layer 3 protocol implementations, and required complex IP
configuration before connecting.
PPP was then created and implemented (RFC 1331 www.ietf.org) as people started to
use modems and computers to connect into networks. If you wished to dial into different
networks, you did not wish to have to change your network configuration every time.
PPP allows for dynamic address assignments and Layer 3 protocol connection, increased
Layer 3 protocol support, error detection, encrypted authentication, and many other

www.ebook-converter.com
features. Most of the advanced features of PPP are used for the massive dialup
networking systems of ISPs or corporate networks. These advanced features can include
automatic IP address, default gateway, and subnet mask assignments after negotiating the
initial connection. PPP can be used on routers for the negotiation and error-detection
features. One of the best features of PPP is that because the negotiation has to take place
to bring up a connection, that is a perfect time to do authentication if you wish to
password some of the connections on your routers. The main thing to know about PPP is
that it is also a Layer 2 encapsulation alternative to HDLC and Frame Relay and that it is
the default interface encapsulation for T1/T3, E1/E3, and SONET Juniper Networks
routers.
PPP, HDLC, and Frame Relay are Layer 2 encapsulation types for POS. SONET can also
be used for TDM multiplexing, but how does one get the best of Frame Relay's dynamic
Downloader demo watermarks
bandwidth capabilities and a circuit-switched network's (CSN) ability to grant high-
quality service together with the speed of SONET? A technology was developed based on
cells. These switched cells were switched like a packet, but were much smaller to allow a
switch to minimize the delay as it switched them through the switch fabric. Instead of
having a connection take the full bandwidth available, even if not using it, as
64
 2. Networking Primer
synchronous networks did, this technology would allow dynamic bandwidth allocations
based on priority and was therefore named asynchronous.

ATM
As companies grew, they were faced with ever growing separate voice and data
networks. Large DS hierarchy voice-line infrastructures were installed next to large PSN
data networks. There surely had to be a way to combine the two, but there were problems
with combining these completely different types of information.
Voice connections are very sensitive to delay, but are not necessarily sensitive to
accuracy. If several bits of a voice conversation were lost, chances are they wouldn't be
noticed unless the problem grew too large. If, however, some of the bits were delayed,
then accelerated, then delayed, the conversation would become garbled.
Data transfers are sensitive to accuracy, but not necessarily to delay. A file being
transferred could be rendered unusable if even only one packet were missing, but it
wouldn't matter too much if the transfer were undergoing the same
acceleration/deceleration as a voice call. However, data usually requires a much higher
data transfer rate to move large files or it would not be considered productive.
Unfortunately, these data transfers that require high data rates can clog points through a

www.ebook-converter.com
network, causing delay.
How do you keep the data transfer traffic from hogging all of the connection bandwidth
to allow the delay-sensitive traffic some room to traverse the network unhindered? This is
where ATM comes in. ATM was developed as a combination of ISDN and Frame Relay.
This allows ATM the features needed to carry both delay-sensitive traffic and high data-
rate traffic at the same time on only one network. ATM is another NBMA technology.
The two main virtual connections of ATM are PVCs and switched virtual circuits (SVCs).
ATM PVCs are similar to the PVCs in Frame Relay. They are up all the time at a specific
bandwidth. SVCs, though, are demand connections: They are only created when needed.
They are connected when needed and disconnected when not. For detailed information
on ATM standards, visit www.atmforum.com.

Downloader demo watermarks

ATM uses virtual interfaces logical unit in a manner similar to Frame Relay for PVCs.
Instead of a single DLCI to identify for which data link PVC the frame was intended,
ATM was made much more scalable by creating paths and channels.

Virtual Paths and Channels

65
 2. Networking Primer

ATM has a physical interface that is split into virtual paths. Each path can then be
divided up into virtual channels. If a router has multiple PVCs on one interface to other
routers, the rest of the ATM network has to differentiate which data belongs to which
PVC so the ATM network devices can accurately forward the data. A PVC is identified
by the numbers that make up the path and channel. This path-channel pair makes an
identification that is unique on the ATM connection between the router and the switch or
from router to router. These identifiers for paths and channels are known as virtual path
identifiers (VPI) and virtual channel identifiers (VCI).
In Figure 2-19, three ATM interfaces are shown with logical paths and channels. Each
path and channel has an associated ID to differentiate data for one destination from
another, similar to a Frame Relay DLCI. The large left ATM interface has four virtual
channels assigned. Path 57 has virtual channel IDs of 39 and 40, which would be written
out as 57.39 and 57.40, respectively. Also on the left interface is path 68, which has VCI
37 and 38, which would be written out as 68.37 and 68.38. Both of the smaller right
interfaces have a path 68 configured. A VPI/VCI pair only has to be unique for that
interface.

www.ebook-converter.com
Figure 2-19. ATM Paths and Channels
The ATM switch has a switching table mapped for all the paths and channels for all the
ports. The PVCs through an ATM switch are manually configured either directly by an
administrator or through management software. This is the manner in which data is
passed switch to switch from the entry point of an ATM network to the exit through a
PVC. VPI 0 and VCI 32 and under are reserved for specific ATM functions—do not use
these VPI/VCI pairs.

Downloader demo watermarks

In Figure 2-20, the router in New York has two PVCs on the interface that connects to
the ATM switch. The ATM switch does not have to know anything about the Layer 3
addressing (switches work at Layer 2). When data is to be sent by the New York router
to Boston, it has to send the data out the proper PVC. This PVC is VPI 2 and VCI 20
66
 2. Networking Primer
(2.20). When data is to be sent to the Chicago router, it is sent on the PVC 1.40. The
ATM switch has a switching table to forward packets appropriately. When a cell is
received by the switch on the New York port (port 0), the table says in port 0 on 2.20,
“send it out port 2 on VPI/VCI 1.10.” If data comes in on port 0 on PVC 1.40, it says
“send it out port 1 on 3.15.” The number 3.15 represents a cell with path 3, channel 15
identified in the cell header.

Figure 2-20. Routing Using ATM PVCs

www.ebook-converter.com
ATM traffic can be given different priorities for leaving an interface. If many devices try
to send to destinations on the other side of an ATM connection, a bottleneck can occur.
This can create a situation where some data gets through and some doesn't. ATM circuits
can be assigned priorities that assure that intended higher priority data gets sent. When
the higher priority connections aren't fully using their assigned bandwidth, lower priority
connections can use it.
ATM can emulate TDM circuits like DS-0s, T-1s, or E-3s. This allows TDM connections
to be mapped across an ATM network. This is known as circuit emulation. Internet data,
such as e-mail, FTP, and Web pages, can also be transferred across an ATM network.
This type of data is known as best-effort. Internet-type data originally had no assurances
of being received at the destination if problems of congestion were encountered along the
way.
Downloader demo watermarks
A problem arises with the two different ways that TDM and best-effort handle data
traffic. TDM is based on a constant bandwidth speed requirement. Best-effort data is
usually bursty, which is to say that it has peaks (high usage) and valleys (low usage) of
67
 2. Networking Primer
bandwidth usage. ATM has controls to allow both types of data to be transmitted on the
same network and to apply extra bandwidth to the lower-priority data when the higher-
priority data is not using it.
Circuit emulation technology requires a PVC with a constant bit rate (CBR) profile. A
profile is a service category that allows ATM traffic to be treated differently. The CBR is
set based on a steady stream in bits per second on data and has the highest priority.
Variable bit rate (VBR) profiles allow for a steady sustained cell rate (SCR), but also a
higher bit rate that can be burst up to for a specific time period, known as the peak cell
rate (PCR). Bursting is the situation when an inordinately large group of cells is sent at
once. The VBR profile has second priority after CBR. Internet-type data uses a profile
called unspecified bit rate (UBR) because of the varied bandwidth requirements. There is
no specified bandwidth at all. UBR has the lowest priority and gets whatever is left over
after the CBR and VBR profiles have made their claim to the port. In Figure 2-21, the
port traffic profile structure is illustrated with the two CBR PVCs ensuring their needed
steady rates, then one VBR PVC getting the middle bandwidth, and any UBR traffic
getting whatever is left over. The CBR 1 and 2 are both configured for 15Mbps each; the
VBR has a sustained rate of 25Mbps with a peak of 10Mbps above the SCR; the UBR
gets the remainder.

www.ebook-converter.com

Figure 2-21. ATM Profiles with Constant, Variable, and Unspecified Bit Rates
Remember how ATM sends its data across a network in cells. As Frame Relay used
frames at Layer 2, ATM uses cells with the VPI/VCI addressing in the header. The cells
Downloader demo watermarks
are extremely small to allow for low delay (called latency) with mixed traffic types when
bandwidth is limited.

The Cell
68
 2. Networking Primer
The ATM cell is the standard unit used for transmission across an ATM network and is a
total of 53-bytes long: 5 bytes of the ATM cell are used for addressing and header
information, and 48 bytes of the cell are used for the payload of data. All ATM cells are
53-bytes long, allowing for consistency of transmission throughout the network.
Sometimes when a Layer 3 packet is segmented to fit into the ATM cells, it doesn't
completely fill the last cell. This cell has to be completed with padding. Padding is filler
that doesn't mean anything, but is used to ensure the cell is the proper size.
ATM cells come in two different types: user-network interface (UNI) and network node
interface (NNI). UNI is a specification for the communications between an end device
(such as a router) and an ATM switch. NNI describes the communication specification
between ATM switches themselves. Figure 2-22 shows the make up of an ATM UNI cell.
The 4-bit generic flow control (GFC) field is currently undefined and is set to all 0s.
The 8-bit VPI field identifies which path the cell is assigned to.
The 16-bit VCI field in the header identifies which channel the cell is assigned to.
The 3-bit payload type (PT) field informs the receiving device of whether the ATM
cell is carrying data to be transferred or administrative messages for the device.

www.ebook-converter.com
The 1-bit cell loss priority (CLP) field allows an ATM switch during times of
congestion to drop cells with this bit set to 1 (lower-priority) before cells with this bit
set to 0. This bit is sometimes called congestion loss priority.
The 8-bit header error control (HEC) field allows the receiver to ensure that the
header has been received correctly. A computation is run on the header, allowing the
correction of 1-bit of error to the header or the detection of more than 1-bit of error.

Downloader demo watermarks

69
 2. Networking Primer
Figure 2-22. Components of an ATM Cell
ATM has been around for a while and is very developed. It is also very flexible. One
downside of ATM is called the cell tax. This is the term that describes the large header of
an ATM cell relative to the payload portion of the cell. With a 5-bit header on 53 bytes,
the ATM cell header itself can consume 9.5 percent of the bandwidth of passing cells (5
divided by 53). On an OC-12 ATM link, 9.5 percent of 622Mbps is over 59Mbps!
All of these data link technologies use some form of addressing or identification to ensure
that the data gets to the proper device on the other end of the data link. Ethernet has
MAC addresses, Frame Relay has DLCIs, and ATM has VPI/VCI assignments. These
data link addresses are only relevant on that particular link between devices, so how does
data get sent from one device through hundreds of others to an intended destination?
That would be the responsibility of the IP at the network layer.

CCCs
Switching a frame is usually faster than forwarding a packet. A switch just has to look at
a Layer 2 header, where as a router has to look at a Layer 3 header. CCC, or circuit cross
connect, is the name of the feature set that allows a Juniper Networks router to perform
Layer 2 forwarding instead of Layer 2. In one instance, CCC functionality covers the

www.ebook-converter.com
Layer 2 label switching required in MPLS-enabled networks. MPLS is a large-scale core
networkwide implementation of routers acting like switches. MPLS is described in the
next section.
Another type of Layer 2 switching that Juniper Networks implements is used on a single
device for smaller-scale operation. This smaller-scale functionality is usually called CCC
as well and refers to functionality similar to a network switch, even though the term
officially describes all the Layer 2 switching functions.
CCC can switch between similar Layer 2 protocols. ATM in can switch to ATM out, and
Frame Relay can only switch to other Frame Relay. CCC can be configured on logical
interfaces and can switch packets to other similarly configured logical interfaces
(configuring CCC is discussed in Chapter 12).

Downloader demo watermarks

MPLS
If a path of routers through the core of a network could switch on a frame header towards
a Layer 3 destination, instead of having to do a Layer 3 lookup, the data might move
70
 2. Networking Primer
more quickly, achieving a much lower latency.
MPLS is a newer development that creates paths through a core network that allow data
to be switched instead of routed. Just as a Frame Relay, ATM, or TDM connection can
be set up through a network, so can an LSP. MPLS has several features that can increase
the efficiency of the core network.
In addition to speed, if different switched paths through the core routers were mapped
out for different priorities of data, a more efficient use the network's links would result.
Sending lower-priority data on longer paths, or on paths with less bandwidth, could free
up more direct links or preferred paths for higher-priority traffic.
Another advantage of using MPLS is the ability for the data to be switched over diverse
types of Layer 2 media. The MP in MPLS stands for Multiprotocol. If a core network has
different types of links, such as Gigabit Ethernet, POS, and ATM, MPLS doesn't care.
Previously, to enable the use of switching instead of routing, the network had to be of the
same protocol. MPLS frees the network of that limitation. Figure 2-23 shows a scenario
that uses LSPs through a core network. Company ABC contracts a provider get data
from router Chicago to router Boston. Company XYZ contracts for a connection between
routers New Orleans and New York. The provider can create an LSP for each company
through the network. These LSPs can have priorities or restrictions put on them based on

www.ebook-converter.com
the contract between the provider and the customer.

Downloader demo watermarks

71
 2. Networking Primer
Figure 2-23. LSPs Through a Core Network
MPLS adds a label ID in a frame or cell to inform the receiving router which path the
data is traversing. These label IDs are stored in a switching table and function in the same
way as a Frame Relay DLCI or ATM cell VPI/VCI pair. LSPs can be manually
configured or set up through dynamic protocols.
MPLS is a Layer 2 function that can make core network data transit more efficient, less
latent, with the addition of more administrative controls. MPLS is covered in detail in
Chapter 12.

IP
The most widely deployed version of IP is version 4, or IPv4, and that is the version
discussed here. IPv6 is available in JUNOSv5.1, but it is beyond the scope of this book.
IP is implemented at the network layer, which is the third layer of the OSI model. As a
packet travels from LAN to WAN to LAN, the different Layer 2 in formation is stripped
and replaced as it travels through routers. The destination IP address is not affected. The
router has to use the IP address to determine in which direction to forward the packet.
Each device on connecting networks has to have a unique IP address. IP networked
www.ebook-converter.com
devices can be grouped by IP addresses that are close to each other so a router can
forward a packet toward a range of addresses that gets smaller until the packet arrives at
the destination.
Because network devices actually transmit and receive in 1s and 0s of binary language, it
is important to know how to find your way around this numbering scheme. IP addressing
is usually written everyday for us mere mortals in decimal to allow easy comprehension.
But when it comes to manipulating IP addressing and groups of IP addresses representing
a network, you do need a basic understanding of binary numbering.

IP Addressing and Binary Conversion

The IPv4 addressing scheme is broken into four single bytes separated by a period:
Downloader demo watermarks
x.x.x.x. A byte is 8-bits long, and each byte has a decimal range of 0 to 255, or 256,
total values. This means that an IP address could look like this if written in decimal:
10.10.150.240. IP addresses are actually transmitted and received in binary,
consisting of 1s and 0s. In binary, numbers increase by a power of 2 as they move to the
72
 2. Networking Primer
left the same way that a decimal number increases by a power of 10 as the place the
number is in moves left. In Figure 2-24, a binary number on the bottom is shown as
11111111. There are 8 bit positions making one complete byte. Moving toward the left,
the value of each bit position is double the one to the right of it (power of 2, as shown in
the value row).

Figure 2-24. Binary Counting

To convert a binary number into a decimal number, add the values of the bit positions
together. If 128, 64, 32, 16, 8, 4, 2, and 1 are added, they equal 255. Since 0 is considered
a possibility, there are 256 numbers that can be generated from 8 bits.
If the binary number is 11010100 then only those bit positions with a 1 would be added.
Figure 2-25 shows the 8-bit binary value table for this number. Adding together the 1-
values 128, 64, 16, and 4 yields a decimal equivalent of 212.

www.ebook-converter.com

Figure 2-25. Converting from Binary to Decimal

To convert decimal numbers into binary, subtract the next lowest binary value bits from
the decimal number until the decimal number is 0.

To convert 189:
Subtracting 128 leaves 61 (the 128 represents a 1 in the eighth bit)
64 cannot be subtracted (this is a 0 in bit 7)
Downloader demo watermarks
Subtracting 32 from 61 leaves 29 (a 1 in the sixth bit)
Subtracting 16 from 29 leaves 13 (a 1 in the fifth bit)

Subtracting 8 from 13 leaves 5 (a 1 in the fourth bit)

73
Subtracting 8 from 13 leaves 5 (a 1 in the fourth bit) 2. Networking Primer
Subtracting 4 from 5 leaves 1 (a 1 in the third bit)
2 cannot be subtracted (a 0 in the second bit)
Subtracting 1 from 1 leaves 0 (a 1 in the first bit)

Using the preceding procedure, the binary for 189 is shown in Figure 2-26. A network
address of 10.10.150.240 can be represented in binary as
00001010.00001010.10010110.11110000.

Figure 2-26. Converting from Decimal to Binary

Network Masks and Subnet Masks

IP addressing has the primary purpose of uniquely identifying networks and hosts. To
determine towards which networks a packet should be sent, an IP address is divided
between a network number and a host number. Where this division occurs is called the
www.ebook-converter.com
network mask. A network mask is a bit-level representation of where the network number
and host number are divided. The network mask is represented by /xx. The xx equals
how many bits of the 32 available are used for the network portion of the address. The
remaining bits are used for the unique host addresses of that network.
Certain classes of network size used to exist. These networks were assigned to
administrators based on their needs and could not be broken up. In Table 2-2, the address
classes and their respective ranges are shown. The classes are A, B, and C. Class A
networks are the largest and were therefore given to the largest companies. Class A
networks use 8 bits of network mask (/8) and can have over 16.7 million hosts! Class B
networks are the next largest with 16 bits of network mask (/16) and can have over
65,000 hosts. Class C networks have 24 bits of network mask (/24) and can have 256
possible hosts. Class D addresses are reserved for multicast addressing. Multicast
Downloader demo watermarks
implementation will be covered in Chapter 14. Class E is an experimental IP space.
Table 2-2. IP Address Classes
Class A addresses 0.0.0.0–126.255.255.255
74
 2. Networking Primer
Class B addresses 128.0.0.0–191.255.255.255
Class C addresses 192.0.0.0–223.255.255.255
Class D addresses 224.0.0.0–239.255.255.255
Class E addresses 240.0.0.0–255.255.255.255
Notice that in Table 2-2, the 127.0.0.0 network is not shown. This is because the
127.0.0.1 address is set aside as a local address for devices' internal use.
The original authority for assigning network addresses was the Internet Assigned
Numbers Authority (IANA), although there are a number of registries today. These large
network blocks were assigned by IANA upon request (today they are assigned by ARIN,
RIPE, and APNIC). But if a company had 200,000 devices, it would have needed a Class
A address. This Class A address would have over 16 million addresses unused. A system
was devised to allow these large blocks of networks to be broken up into subnetworks.
This allowed portions of blocks to be allocated properly based on need. The network
mask of a subnetwork was a subnet mask because it was a subnetwork of the original-
sized class. From this came the term classless routing. Classless interdomain routing
(CIDR) is the implementation of the ability to shrink or grow the subnet mask based on
how many hosts or networks are needed. The ability to properly size your subnet mask is
called variable length subnet masking (VLSM).

www.ebook-converter.com
With four bytes of addressing space in an IP address, a subnet mask can be as large as a
/30, indicating that the address is for two devices on a point-to-point link. A single host
address would be a /32. When the binary is written out for a subnet mask, bits are
counted from left to right to indicate what portion is used for the network. The binary can
be written out broken into four groups of 8-bits each as shown in Figure 2-27.

Figure 2-27. Sample Binary Subnet Mask with 30-Bit Address

Figure 2-28 shows that if an IP network address is given with a /24, that means that 24
Downloader demo watermarks
bits of the address are used for the network portion, leaving 8 bits for the host portion.

75
 2. Networking Primer
Figure 2-28. Sample Binary Subnet Mask with 24-Bit Address
In the network mask in Figure 2-28, the network could have 256 potential host numbers,
0 to 255. 172.20.10.0/24 would range from 172.20.10.0 to 172.20.10.255.
The first number in a range is always used to identify the network as a whole. The last
number of the network range is used to broadcast to all the hosts on that network (called
a directed broadcast). Since these two numbers cannot be used for hosts, then the two
addresses must be subtracted from the pool of 256 available addresses leaving 254
available host addresses.
The subnet mask can also be represented in decimal. Converting the address in Figure 2-
28 from binary would give a subnet mask of 255.255.255.0.

Subnetting
If a network administrator is to use the range of IP addresses assigned efficiently, the
addressing range must be manipulable for different network implementations. For an
office of 100 to 200 people, a /24 might be the appropriate network mask for that
network, but what if it was a small office with only 20 to 40 people? Then there would a
large number of wasted IP addresses in that range. VLSM allows for breaking a very
large network range down into several parts as needed. If smaller networks are needed,

www.ebook-converter.com
then those parts can be broken down even further.
If a new company wishes to implement an IP addressed network, it can request a block of
addresses from its ISP. For this example, the ISP gives the company 10.10.0.0/21.
This range is from 10.10.0.0 to 10.10.7.255. The subnet mask of /21 in Figure 2-
29 denotes one network with 1,000 or more host numbers. The 1s in the mask represent
the network bits and the 0s are the bits available for host addresses.

Downloader demo watermarks

Figure 2-29. Sample Subnet Mask with 21-Bit Address
A single network of 1,000 or more devices is too large to use for one particular network.
It can be broken down into usable subnetworks that are connected by routers to make
76
 2. Networking Primer
more efficient use of the addressing space. The administrator can take this one block and
split it by increasing the number of 1 subnet bits to the right. This will create two blocks
from the original assigned network. The two networks would then be 10.10.0.0/22
and 10.10.4.0/22.
This can be most easily calculated using binary.
10.10.0.0/21 is represented as 00001010 00001010 00000000 00000000
The subnet mask is 11111111 11111111 11111000 00000000
The 10.10 portion of the network address is defined by the assigned mask.
To split the 10.10.0.0/21 range into two networks, moving the subnet bit to the right
by one bit allows for two network ranges.
10.10.0.0/22 is represented as 00001010 00001010 00000000 00000000
The subnet mask is 11111111 11111111 11111100 00000000
10.10.4.0/22 is represented as 00001010 00001010 00000100 00000000

www.ebook-converter.com
The subnet mask is 11111111 11111111 11111100 00000000
This can be achieved because the 10.10.0.0/22 range includes the 20-second bit as
either a 1 or a 0 because it is not part of the mask.
To split the 10.10.0.0/22 once more into /23s, the following would occur.
10.10.0.0/23 is represented as 00001010 00001010 00000000 00000000
The subnet mask is 11111111 11111111 11111110 00000000
10.10.2.0/23 is represented as 00001010 00001010 00000010 00000000
The subnet mask is 11111111 11111111 11111110 00000000
Downloader demo watermarks
This process can be used many times to reduce the size of the network to create a range
suitable for most purposes. If two routers are to be connected together with a point-to-
point connection, the very small network between them only needs four addresses: the
network number, the two router addresses, and the broadcast address. This would be
77
 2. Networking Primer
represented as 10.10.0.0/30.
10.10.0.0/30 is represented as 00001010 00001010 00000000 00000000
The subnet mask is 11111111 11111111 11111111 11111100
10.10.0.4/30 is represented as 00001010 00001010 00000000 00000100
The subnet mask is 11111111 11111111 11111111 11111100
For the network address 10.10.0.0, the two host addresses are 10.10.0.1 and
10.10.0.2. The broadcast address is 10.10.0.3. The next contiguous (adjacent or
next in line) /30 network is 10.10.0.4/30. The last digit of the network address is
increased by one to find the next contiguous network (bold above).

Aggregation
As the networks are broken down using the subnetting bits, many subnetworks will be
created. Routers have to tell each other about these subnetworks. Too many subnetworks
can take up a lot of time and bandwidth. In addition, keeping track of all of these
networks can put a heavy processing load on the routers. In the same binary manner that

www.ebook-converter.com
larger network blocks can be subnetted to create smaller blocks, smaller blocks can be
aggregated to form a larger network assignment. This is important when routers tell each
other about the networks that they know about (called advertising). Instead of many
advertisements, if networks are aggregated together, there may need to be only one
advertisement.
Aggregation is achieved by moving the mask bit to the left, which reduces the number of
1s in a mask, creating a larger network range of host addresses.
10.20.2.0/24 is represented as 00001010 00010100 00000010 00000000
10.20.3.0/24 is represented as 00001010 00010100 00000011 00000000
The common subnet mask is 11111111 11111111 11111110 00000000
Downloader demo watermarks
Figure 2-30 is an example of aggregation. If router B were to inform router A about the
existence of its two attached networks, router B would advertise both networks as /24s
to router A. Router A would have two entries for router B's attached networks. If router
B were to aggregate the two networks into a larger advertisement, then router A would
78
 2. Networking Primer
only have to receive one entry (10.20.2.0/23), which would encompass both
networks, instead of having to receive each /24 network individually.

Figure 2-30. Aggregation of Networks

Both network addresses in binary are the same to the twenty-third bit. Thus, they can
then be advertised as 10.20.2.0/23 because that address range includes both the 0
and the 1 of the twenty-fourth bit. Chapter 8 explains routers advertising networks to
each other in detail.
This seems like a small example, but each of the /24 networks in Figure 2-30 could have
been many smaller networks farther down. When networks are made up of thousands of
contiguous subnets, aggregation becomes extremely important.

www.ebook-converter.com
The IP Packet
The IP packet header contains information needed to transport the data from one host to
another on a best-effort basis. IP has no mechanism itself to ensure that the packet is
delivered. These functions are in different layers. IP header information primarily
consists of address and fragment information. In the event an IP packet has to be
fragmented, there has to be enough information to allow it to be defragmented at the
appropriate time in its entirety. Different network types use different packet sizes. If an
IP packet passes through a network that uses smaller packet sizes, the IP packet can be
broken into fragments. An IP packet header has 20 required bytes and can have more if
optional fields are used. Figure 2-31 is a representation of the required fields and the two
last optional fields.
Downloader demo watermarks
Figure 2-31. The IP Packet Header Fields
79
 2. Networking Primer

The 4-bit version (V) field informs the receiver of the version of IP being used. As stated
earlier, the most common version is IPv4.
The 4-bit IP header length (IHL) field describes the header length in 32-bit words (how
many groups of four bytes are in the header). This is important if the optional fields are
used so the receiver knows where the header ends and the data starts. The minimum is
five (5 × 4 is 20 bytes minimum IP header).
The 8-bit ToS field informs routers of precedence, delay, or service required. Speed
(minimum delay) can be requested over reliability and so forth. ToS bits are used in
DiffServ, allowing an administrator to configure different treatment of packets based on
the ToS bits.
The 16-bit total length (TL) field represents the total length of the IP packet.
The 16-bit ID field aids in defragmenting packets. If packets need to be fragmented in
transit, this ID can ensure that the receiver knows which fragments belong to which
packets.
The 3-bit flags (F) field informs a router if the packet can be fragmented.

www.ebook-converter.com
The 13-bit fragment offset (FO) field indicates where in the full packet a particular
fragment fits. The first fragment would have an offset of 0.
The 8-bit TTL field is decremented every time it is forwarded by a router. It has a
maximum value of 255, allowing it to traverse 255 routing devices before it reaches the
destination. When the TTL reaches 0, the packet is dropped. This keeps undeliverable
packets from endlessly circling the Internet.
The 8-bit protocol (P) field indicates the next upper-layer protocol used in the datagram.
The 16-bit header checksum (HC) field represents the check on the packet header only.
Since the packet header will change at every hop (decrementing TTL) towards the
destination, this has to be looked at every time the packet is forwarded.

Downloader demo watermarks

The 32-bit SA field is the IP address of the device that sent the packet.
The 32-bit DA field indicates the IP address of the destination of the packet.

80
 2. Networking Primer
The variable-length options (OPT) field can be used for control, measurement, source
routing, and time stamping, among other things.
The variable-bit padding (PAD) field is added if needed to ensure that the header ends
after a 4-byte boundary. This will allow the TTL field to be accurate since it counts the
number of 4-byte groups in the header.

TCP Versus UDP

There are different types of data to be sent and received across the Internet, and the
various types of data need to be treated differently. TCP and UDP are at Layer 4 in the
OSI model. The main difference between TCP and UDP is that TCP is connection-
oriented for reliability and accuracy; UDP is connectionless and oriented for speed and
consistent delay of transmission.
During a file transfer, accuracy is important. The packet transmission can be bursty in
nature: it can slow down or speed up and be received out of order. As long as all the
packets are received, the file can be assembled. But if one packet is corrupted or lost, the
file is quite often no good. This will require the receiving device to request the lost or
corrupt packet again to ensure the complete file is received. This is connection-oriented
communication. The sender and receiver set up communications before the data is sent to

www.ebook-converter.com
agree on the terms of transmission. These terms can be negotiations of such factors as
how many packets are sent before an acknowledgment.
Though video or music broadcasts on the Internet don't require perfect accuracy, they
require orderly transmission. UDP packets are connectionless and are just sent out
without the sender knowing if they are received. If a packet here and there is dropped or
corrupted, it won't affect the overall quality of the data being sent. This is an advantage
over TCP, which is connection-oriented. TCP would have the sender resend a packet that
was dropped. This could make an audio or video transmission worse than if the packets
were just lost. Order is more important than accuracy.
TCP and UDP use the same port numbers to distinguish which of the upper-layer
protocols the information is destined for. For example, FTP uses port 21, Telnet uses port

Downloader demo watermarks

23, HTTP, or the World Wide Web, uses port 80, and SNMP uses port 161. Refer to
www.iana.org/numbers.html for more information on port number assignments. When a
device has several applications open and sending and receiving IP traffic at the same
time, a differentiation has to be made between which IP packets belong to which upper-
layer applications. That is where Layer 4 port numbers come in. They allow the
81
 2. Networking Primer
TCP/UDP stack to forward traffic up the layers properly so that it gets to the appropriate
application.
TCP is very oriented on passing data reliably. TCP's header is larger than UDP's due to
the sequence numbers and acknowledgments that make up the protocol's reliability
functions. Sequence numbers have to be kept in order for the receiver to tell the
datagrams apart for acknowledgment. Figure 2-32 shows the fields of a 20-byte-minimum
TCP header.

Figure 2-32. The TCP Header Fields

The 16-bit source port (SP) field records the port from which the sending device sent the
datagram.
The 16-bit destination port (DP) field records the port that the data is being sent to on
the receiver.
The 32-bit sequence number (SN) field keeps the datagrams in order.

www.ebook-converter.com
The 32-bit acknowledgment number (AN) field is the next sequence number that should
be expected to be received.
The 32-bit data offset (DO) field is similar to a header length field. It describes where the
header ends and the data starts.
The 6-bit reserved (Res) field contains 6 bits all set to 0. They are for future use.
The 8-bit control (Co) field controls the connectivity between the sender and receiver.
These bits can inform the receiver that there is no more data from the sender, or either
device can reset the connection with these bits.
The 16-bit window (Win) field identifies the number of bytes starting with the byte in the
Downloader demo
acknowledgment field that the sender will accept.
watermarks
The 16-bit checksum (Chk) field is the result of a checksum being run on the header and
data.

82
 2. Networking Primer
The 16-bit urgent pointer (UP) field informs the receiver to offset the sequence number
of the first byte of regular data if there is urgent data.
The variable-length OPT field is not mandatory in the TCP header. This field can be used
for functions such as setting buffer sizes for receiving large chunks of data.
The variable-length PAD field is used to round out the header of a TCP datagram to the
nearest 32-bit group (4 bytes) so the DO field is correct.
UDP is very simple compared to TCP. Since UDP is connectionless, there is no need for
connection-controlling information. Acknowledgments, sequence numbers, and the like
are not needed. A UDP header is only 8-bytes long. Figure 2-33 illustrates the fields of a
UDP header.

Figure 2-33. The UDP Header Fields

www.ebook-converter.com
The 16-bit SP field records the port from which the sending device sent the datagram.
The 16-bit DP field records the port that the data is being sent to on the receiver.
The 16-bit length (Len) field specifies the length of the datagram header and data.
The 16-bit Chk field that is the checksum run from the header and data of the datagram.

Multicast
So far, this chapter has discussed unicast and broadcast IP addresses. Unicast IP
addresses send data to one host, whereas broadcast IP addresses send to all hosts in that
Downloader demo watermarks
network. What if you wish to send only to some of the devices on a particular network?
This is what a multicast IP address does. When a group of devices wishes to receive data
at the same time, a sender can send that data once to a multicast IP address to which the
group listens. These IP addresses are in the Class D group of IP addresses, which are in
83
 2. Networking Primer
the range of 224.0.0.0 to 239.255.255.255.
Often, a multicast address is applied to a device when a service requiring it is enabled.
Video streaming is a type of service that can use multicast. When a device wishes to
receive the video, it can listen in to the multicast IP address to which that particular video
is being sent.
In Figure 2-34 below, routers A, C, and D have enabled multicast. These three routers
will listen to any IP packet that is sent to the destination IP address of 224.0.1.5 in
addition to their normal unicast IP address in the 192.168.20.0/24 network. Routers
B and E will not pay any attention to packets addressed to this address because they are
not listening in for multicast addressing. They will only listen to their unicast IP address.
Multicast is explained in detail in Chapter 14.

www.ebook-converter.com
Figure 2-34. Multicast IP-Enabled Network

Chapter Summary
In this chapter, we started the discussion with the OSI model and what devices work at
which layers. It was pointed out that networking for the most part concerns Layers 1 to 4
of the OSI model. Acting as the post office, the job is to get data from point A to point B.
The electrical or optical signals on the cable are types of Layer 1 implementations. The
Layer 1 physical signals are used by data link Layer 2 as the connection between like
Downloader demo watermarks
Layer 2 switches. Layer 2 switches form the connection between Layer 3 routers. This
relationship is most important. An effectively built network starts from the ground
(lowest layer) up. Nothing will get anywhere if you don't plug in the cable.

84
 2. Networking Primer
After the OSI discussion, we discussed the basics of various types of Layer 2 data link
technology. Ethernet and the various speeds are examples of LAN broadcast protocols.
Frame Relay, PPP, and ATM are examples of WAN nonbroadcast technology. Typically,
data moves from a host on a LAN to WAN to LAN through the use of LAN/WAN
switches separated by routers. These data link protocols are the local transport between
devices for the Layer 3 protocols.
The Layer 3 protocol, we explained, is IP. This is the most widely used Layer 3 protocol
by far. It is the protocol that e-mail, the World Wide Web, Internet video, and Internet
chat protocols use to get from host to host. It uses an addressing scheme that allows
routers to forward IP packets in the appropriate direction until they get to their
destination. IP addresses can be grouped together using a subnet mask to represent a
range of IP addresses. These ranges can be made smaller to fit smaller networking needs
or larger to summarize several networks, all just by moving the bits of the subnet mask
right or left respectively.
Lastly, two types of Layer 4 protocol were explained: TCP and UDP. They are
completely different in nature and are used according to the upper-layer needs. You may
need connectionless, consistent bandwidth in a stream for jitter-free video (UDP) or
connection-oriented bursty bandwidth for file-transfer accuracy (TCP).

www.ebook-converter.com
These layers fit together handsomely. Physical connections transporting Layer 2
protocols carry Layer 3 IP laden with Layer 4 TCP or UDP depending on the needs of
the upper-layer application from one place to another. That is networking.

Bibliography

Downloader demo watermarks

85
[ch02bib01] Kevin Downes,, et al. Internetworking Technologies Handbook, 2nd ed.
Cisco Press, <year>2000</year>.
[ch02bib02] Walter J Goralski,. SONET. McGraw-Hill, <year>2000</year>.
[ch02bib03] David E., McDysan, and Darren L. Spohn. ATM Theory and Applications.
McGraw-Hill, <year>1998</year>.
[ch02bib04] Radia Perlman,. Interconnections, 2nd ed. Addison-Wesley,
<year>2000</year>.
[ch02bib05] www.juniper.net

www.ebook-converter.com

Downloader demo watermarks

86
 3. Juniper Networks Router Architecture
Chapter 3. Juniper Networks Router Architecture
When the routers produced by Juniper Networks first hit the market in 1998, they brought simplicity of
design, a logical UNIX-style CLI, and robust troubleshooting tools. The engineers who designed the
routers wanted to build a device that made sense. In doing so, they filled a void in the market and
appealed to other engineers who wanted a router that moved packets through as quickly as possible.
Juniper Networks' product offerings come in the form of the M-Series routers. The M40 was the first
router of its kind capable of scaling to meet current Internet needs. The initial M40 release was based on
the Internet Processor I. The Internet Processor I was the fundamental core of the packet forwarding
engine (PFE). The PFE consisted of a shared memory, a single forwarding table, and a one-write, one-
read architecture. The entire PFE was capable of forwarding 40Mbps, more than 100 times the capacity
of other available router architectures at the time.
Although the M40 was quite progressive, Juniper Networks was able to improve on its available
functionality by upgrading the processor, raising the available memory, adding redundancy, and including
the ability to filter traffic through ACLs in later iterations of the product.
This chapter introduces you to the router models and architectural differences of each product. In
addition, we will describe each hardware and software piece of the router and explain how that piece
contributes to the overall logic of the device. This will include the routing engine, the PFE, the switching
fabrics and control boards, the interfaces available, and the differences between the available router
models. It will also include an explanation of the router's boot process and how to upgrade the JUNOS
software.

www.ebook-converter.com
Since the architecture and operating-system commands of these routers differs from those of other
vendors, such as Cisco, with which you may already be quite familiar, the material covered here should
help you to understand the rest of the material in this book. It will also undoubtedly help in your pursuit
of Juniper Networks career certifications.

Juniper Networks Router Models

This section describes the different models of Juniper Networks routers. The physical dimension,
performance statistics, and some information about the internal architecture of the router itself are
provided for each model.

M5 and M10
The M5 and M10 routers were introduced in September 2000 as the latest additions to the router family.

Downloader demo watermarks

With their introduction, Juniper Networks hoped to gain a larger marketshare by appealing to networks
needing a smaller footprint router. Due to its minimal physical requirements—5.25 × 17.4 × 24 in., or
13.33 × 44.2 × 60.96 cm—single rack can hold 15 M5s, which creates a bandwidth-to-footprint-to-price
ratio that is hard to beat.

87
 3. Juniper Networks Router Architecture
The M5 and M10 were released at the same time because they had similar architectures with two
different throughput capabilities (5Gbps on the M5 and 10Gbps on the M10). Both routers employ the
Internet Processor II ASIC, providing forwarding table lookups at 40Mpps.The M10's chassis looks the
same as the M5's; however, there are two forwarding engine boards (FEBs) in the M10, allowing for a
maximum of eight physical interface cards (PICs) to be used.

M20
The second router introduced by Juniper Networks was the M20, released in December 1999. The M20
also uses the Internet Processor II ASIC and is capable of throughput in excess of 20Gbps.
With physical dimensions of 14 × 19 × 21 in., or 35.56 × 48.26 × 53.34 cm, a network administrator can
stack five chassis in a single equipment rack. The M20 was the first Juniper Networks router available
with redundancy (power supply, routing engine, and system and switch board [SSB]). This greatly
increased the appeal of the Juniper Networks routers to the marketplace. Component failure in an
operational network can be disastrous. By addressing the need for component redundancy, Juniper
Networks was able to allay this fear in the minds of potential customers.

M40
The M40 router was the first product launched by Juniper Networks. With a chassis size of 35 × 19 ×
23.5 in., or 88.9 × 48.26 × 59.69 cm, deployment is limited to two chassis per equipment rack. However,
the router's architecture provides over 40Gbps throughput. The M40 supports the same PICs as the M20.

www.ebook-converter.com
The PICs are compatible between both platforms.
Although initially deployed with the Internet Processor I and without ACL capability, the M40 now runs
on the Internet Processor II and has addressed the need for filtering. This platform, however, does not
provide for the same component redundancy as the M20 and M160 models, an important distinction for
most customers.

M40e
To answer the need for the throughput of the M40 coupled with redundant-component capability, Juniper
Networks introduced the M40e platform in February 2002. The M40e router has the same footprint and
port density as the M40, but it provides the optional redundancy that the M40 does not. This model is
compatible with most of the PICs from the M20, M40, and M160 models.

M160
Downloader demo watermarks
The M160 was introduced in March 2000 as the third box in the M-Series. It is a formidable router, both
in size and capacity. The M160 chassis is 35 × 19 × 29 in., or 88.9 × 48.26 × 73.66 cm. This allows for
two per equipment rack.

88
 3. Juniper Networks Router Architecture
The M160, to date, is the highest-rated core router on the market. Independent testing has shown that the
M160 outperforms the competition in areas of BGP table capacity, MPLS LSP capacity, route flapping
recovery at OC-192 speeds, convergence at both OC-192 and OC-48 speeds, and filtering at both OC-
192 and OC-48 speeds. In additional tests, the M160 has matched or exceeded the competition in the
areas of CoS at OC-48 and OC-192 speeds and IP and MPLS baseline testing at OC-48 and OC-192
speeds.
The M160 platform provides the maximum throughput and port density necessary for the next generation
of Internet architectures.

G10
In November 2001, Juniper Networks announced its intent to acquire Pacific Broadband
Communications and its CMTS. Subsequently, Juniper Networks rereleased that CMTS as its G10 router.
This product is aimed at the growing broadband-remote-access-service (BRAS) market that delivers
Internet service into private homes and small businesses primarily through cable modems.
A chief complaint of cable Internet subscribers is that as more subscribers join in a given area, the
amount of bandwidth available to each end user can drop dramatically. The G10 uses a custom-built
ASIC that has the capability of 20 legacy CMTS chips. The end result is that this device is capable of
supporting greater numbers of subscribers using less bandwidth.

Architecture Overview

www.ebook-converter.com
When Internet routers were first introduced, the amount of traffic processed was much less than it is
now. The router's brain, its CPU, was robust enough to handle its own tasks, the tasks of creating and
managing the routing tables, and the task of forwarding the packets. Some routers on the market today
still use this processor-based technology.
Juniper Networks has created a device that segregates the tasks and assigns them to different parts of the
router, sort of like an assembly line. You can see this process in Figure 3-1. Because Juniper Networks
routers are designed to serve the busy core of the network, the number of packets processed per second
is in the millions. If the router were required to manage everything from its CPU, throughput would
suffer, as would the ability to provide service guarantees.

Downloader demo watermarks

89
 3. Juniper Networks Router Architecture

Figure 3-1. Juniper Networks Routing Architecture

Most routers today are beginning to follow this model of separate processes within the router—routing
and forwarding. Either through the use of ASICs on the line cards containing the interfaces or through the
use of separate processors within the routing unit containing the CPU, the router manufacturers have all
started to turn towards this technology. It simply makes sense. Let's examine the way a Juniper Networks
router attacks this issue.
Juniper Networks routers consist of a simple architecture containing two basic components: a routing
engine and a PFE. The routing engine handles the more mundane tasks, such as routing protocol
calculations, control packet processing, and so on, while the PFE is allowed to move packets out of the

www.ebook-converter.com
router as quickly as possible. After all, the main duty of an Internet router is to handle the packets as little
as possible as they move through its realm. To achieve flawless, wirespeed performance, Juniper
Networks ensured that certain processes would be physically and logically segregated on their routers.
Figure 3-2 shows the segregation of processes between the two main components of a Juniper Networks
router. The rest of this chapter explains these components and processes further.

Downloader demo watermarks

90
 3. Juniper Networks Router Architecture

Figure 3-2. Routing Engine and PFE Processes

Routing Engine
The Juniper Networks routing engine is an integral part of the router architecture and provides for all of
the central processing and route processing requirements. As you will learn in this section, the routing
engine also provides storage for the operating system and provides the CLI through which the operating

www.ebook-converter.com
system is configured.
Although there are differences between the various Juniper Networks router models, which are outlined
in the Section 3.2.1.3, the design of the routing engine is similar in all of them. The routing engine is
primarily responsible for running the routing protocols, keeping the routing tables up-to-date, sending
routing updates to the PFE, and performing system management. The routing engine communicates
directly with the PFE through a 100Mbps connection.

Function of the Routing Engine

Functions provided by the routing engine include the following:
Handling of routing protocol packets
Management interface

Downloader demo watermarks

Configuration management
Accounting and alarms
Modular software
91
 3. Juniper Networks Router Architecture
Scalability
Routing protocol packets that arrive on the network are not handled on the PFE itself, but are passed
directly to the routing engine. This effectively reduces the amount of work that the PFE has to do,
enabling it to process packets to be forwarded efficiently. An example of a routing protocol packet would
be a link-state advertisement (LSA) from an OSPF router. The LSA would be received on an ingress
interface and sent directly to the routing engine. The routing engine would then perform the shortest-
path-first (SPF) route calculations and update its OSPF routing table, which, in turn, would send LSAs to
its neighbors. (For more information on the functions of OSPF, please refer to Section 8.4.)
The routing engine also provides several ways to manage the router. First, it provides the CLI, which
allows the system operator to interact with the JUNOS software, the PFE, and the interfaces through
configuration, modifications, and monitoring. The routing engine also runs SNMP, permitting
management of the system from a network management station running software, such as Hewlett-
Packard's Network Node Manager (HP-NNM), through a framework, such as Hewlett-Packard's
OpenView. Finally, the craft interface, discussed in Section 3.2.1.4, provides more information for
management of the router.
Accounting functionality and alarms provides further manageability of the router. Alarms, seen via the
craft interface, provide information to the system administrator about the condition of the router or
functions of the router. Accounting of packets is done in the routing engine, thus negating any impact on
wirespeed routing taking place in the PFE.
For change and configuration management, the routing engine allows for the storage of configuration
files, microcode, and system images in one primary and two secondary locations. A unique rollback

www.ebook-converter.com
feature, provided by JUNOS, also allows the system administrator to return to a previous configuration
quickly, should the new configuration prove problematic.
Finally, Juniper Networks routers use modular software that cleanly separates processes from each other.
The problems of one process will not impact other processes that may be running. Additionally, the
software is designed to scale well to the needs of tomorrow's Internet routing demands.

JUNOS
JUNOS is the operating system currently used on all Juniper Networks routers. JUNOS is not just an
operating system providing a CLI for configuration, but also a feature-rich platform providing
troubleshooting tools and advanced feature sets. The operating system also incorporates an application
programming interface (API) system for external program calls and scripting capabilities. JUNOS, in
conjunction with the Internet Processor II, comprises the industry's most advanced BSD-based router
operating system in today's marketplace. The routing engine is based on an Intel PCI platform running
JUNOS. JUNOS runs in flash memory with an alternate copy stored on the router's hard disk. As you can
Downloader demo watermarks
see in Figure 3-3, the operating-system kernel is layered on the PCI platform and establishes
communication between the PCI platform and the system processes. The kernel is also responsible for
making sure that the forwarding tables in use by the PFE are in sync with those in the routing engine.

92
 3. Juniper Networks Router Architecture

Figure 3-3. Routing Engine Components

There are five essential functions provided by JUNOS:
1. The routing protocol process provides all routing and routing control functions within the platform.
The modularity of this package allows for the addition and removal of protocols and functions,
providing both flexibility and scalability.
2. The interface process performs configuration of the physical interfaces and encapsulation.
3. The SNMP and management information base (MIB) II processes allow SNMP-capable systems to
communicate with the router platform. This also allows the platform to provide necessary SNMP
information to external agents. JUNOS is SNMP I and II compliant.
4. The management process starts and monitors all other software processes in JUNOS. If a particular

www.ebook-converter.com
management function stops, this process will attempt to restart it.
5. The routing kernel process controls everything else. In addition to providing the underlying
infrastructure to all JUNOS software processes, the routing kernel process provides the link between
the routing engine and the PFE.
One or more routing tables are maintained by the operating system. Routing policy is maintained on
JUNOS within the routing engine.
Let's take a closer look at the processes running on the routing engine. Figure 3-4 gives a visual
representation of how these processes all work together to carry out the business at hand. You'll notice
that nearly all of the processes communicate directly with the kernel. The exceptions are the user
process, which must access the kernel through the CLI, and the routing table, which is simply a product
of the routing protocol processes. Any communication between the routing engine and PFE originates
from the kernel itself.

Downloader demo watermarks

93
 3. Juniper Networks Router Architecture

Figure 3-4. Routing Engine Processes

Routing Engine Specifications

Routing engine specifications will depend upon the router model. The differences between the Juniper
Networks M-Series router models are listed in Table 3-1. Note that all of the routers provide for out-of-
band management, RS-232 DB9 ports for serial console and remote management access, and tertiary
storage using a removable PC card. The main difference between the models is the amount of flash or
SDRAM available. Of course, these differences only apply to the routing engines. There are substantial
differences in capacity, throughput and available interfaces between models, as well.

www.ebook-converter.com
Table 3-1. Routing Engines on Different Models
Available Compact
Model Platform Redundancy Flash SDRAM
M5 and M10 333MHz Pentium II with integrated NO 96MB 256, 512, or
256MB level 2 cache 768MB
M20, M40, and 333MHz Pentium II with 512MB cache M20—YES 80MB Up to 768MB
M40e
M40—NO
M160 333MHz Pentium II with integrated YES 80 or 768MB
256MB level 2 cache 96MB

The M160 Miscellaneous Control Subsystem

Only the M160 router uses the routing engine in conjunction with a miscellaneous control subsystem
(MCS). The two are installed adjacently in the rear of the chassis and together form a host module. Both
Downloader demo watermarks
components are required to function. If a routing engine is installed without the MCS, the routing engine
will not work—and vice versa. The router will accommodate up to two host modules.
The MCS performs the following functions:

94
 3. Juniper Networks Router Architecture
Acts as a middle man between the routing engine and the sensors throughout the system; relays
statistical information to the routing engine, and relays control messages and alarms out to the system
from the routing engine
Controls power-up and power-down of system components
Decides which of any given redundant components will act as master
Performs reset attempts on flexible PIC concentrators (FPCs), when necessary (the FPC will be
discussed later in this chapter in Section 3.2.2)
Acts as the SONET 19.44MHz clock source and monitors all other system clocks
You have probably noticed that some of these functions are performed by the routing engine itself on
other router modules. While this is true, no other M-Series model provides the port density and
forwarding speed of the M160. Some of the functions traditionally built into the routing engine have been
moved out into this new router component, the MCS, to focus the routing engine on more specific tasks.
The MCS comprises the following:
A PCI interface to the routing engine
Two BITS interfaces for external clock sources
A 100Mbps Ethernet interface to other system modules

www.ebook-converter.com
A 19.44MHz stratum 3 SONET clock source
A controller for monitoring the sensors
A debugging port (RS-232)
LEDs
An offline button

The Craft Interface

Positioned on the front of the chassis, the craft interface provides an external look into the internal
workings of the router. It can be used as a troubleshooting tool, a monitoring tool, or both. Although the
craft interface looks different on each model, the workings are very similar. The example figures in this
section are based on the M40 model.
Downloader demo watermarks
The main features of the craft interface are the following:
LED indicators

95
 3. Juniper Networks Router Architecture
Alarm indicators
Routing engine ports
LCD display screen (on the M40 and M160 only)
The craft interface on an M40 model, shown in Figure 3-5, displays the status of the FPCs, of the routing
engine and of general alarm conditions. Each FPC has a corresponding button on the craft interface.
LEDs above the button indicate whether the FPC's status is “OK” or it has failed to initialize.

Figure 3-5. M40 Craft Interface

www.ebook-converter.com
Alarm LEDs indicate the level of an alarm if one has occurred. On this alarm panel are two alarm relay
contacts. These can be used to connect external alarm devices to the craft interface. If a yellow or red
alarm occurs, the external alarm device would also be activated. Alarms can be silenced with the alarm
cutoff button, but this does not remove the alarm condition.
Red alarms indicate a condition in which a service interruption could occur, such as a component failure.
Yellow alarms are generally indicative of recoverable errors or maintenance alerts.
Routing engine access is provided on the right side of the craft interface through a console port, an
auxiliary port, and a management Ethernet port. The status of the routing engine is indicated as either OK
or Fail. More information about the LED status indicators is provided in Table 3-2.
Table 3-2. Craft Interface Indicators
LEDColor/Action Description
OK Green/BlinkingInitializing
Downloader demo watermarks
OK Green/Solid Running
Fail Red/Solid Offline, owing to failure (In the case of the routing engine, this could mean that the
system control board did not detect the routing engine.)
ALARMS
Red Alarm Red/Solid System failure, power supply failure, or system threshold exceeded
96
 3. Juniper Networks Router Architecture
ALARMS
Yellow AlarmAmber/SolidMaintenance alert or indication of temperature increase
The FPC buttons are used to take an FPC offline, before removing the FPC, for instance. To do this,
press and hold the button for three seconds, or until the red Fail LED becomes solid. Then, it is safe to
remove the FPC.
The LCD display screen, shown in Figure 3-6, works in either idle mode or in alarm mode. When in idle
mode, the LCD display will show the current system status. When in alarm mode, the LCD display will
provide more information about the alarm condition. To interact with the LCD menu, use the buttons and
directional arrows to the right of the LCD display screen.

Figure 3-6. Craft Interface LCD Panel

Finally, the craft interface provides three ways to interact with the CLI:

www.ebook-converter.com
1.

2.
Console port
Auxiliary port
3. Management Ethernet port
Using an RS-232 serial cable, an external console, such as a dumb terminal and keyboard, can be
connected to the console port to display system messages and information constantly or to enter the CLI.
A laptop computer or modem may be connected to the auxiliary port for quick, portable access to the
CLI.
The management Ethernet port can be used to connect the router to any Ethernet LAN through an
autosensing 10/100 RJ-45 port. Most network administrators connect this port to a management LAN for
out-of-band management of the routers. Unlike with routers from some other vendors, this management
port can be controlled via the CLI, but it will not route traffic and, therefore, cannot be used as a spare
port.
Downloader demo watermarks
Redundancy and Maintenance Options
In the busy network core, network availability is everything. Juniper Networks has designed its routers to
reduce single points of failure. Routing engines are no exception. Most router models can be configured
97
 3. Juniper Networks Router Architecture
with redundant routing engines, thereby reducing system downtime in the event of a failure. (There will
be an interruption of routing services during the failover, however, as there is whenever an routing engine
is inserted or removed.) Table 3-3 provides more information on redundant components in each router
model. (Note that some of the components described here will be covered in detail later in this chapter.)
Table 3-3. Redundancy in Components by Model
Model M5 and M10M20 M40 and M40e M160
Redundant routing engine functionsnone P/S P/S P/S
Cooling Cooling Cooling
Routing engine Host module
SSB PFE clock generator
SFM
The routing engine is said to be hot-pluggable, which simply means that it may be inserted while the
router is powered up. Routing functions will be interrupted whenever a routing engine is removed or
inserted, however.

Note
If the router does not have two routing engines, the router will not be operational without the

www.ebook-converter.com
single routing engine inserted.
Maintaining the routing engine requires attention to the LED on the craft interface to check for alarms or
other indications of operational problems. The system administrator can also find some information from
the CLI by using the following command:
system@m20# show chassis routing-engine

Routing Engine status:

Temperature 28 degrees C / 82 degrees F
DRAM 768 Mbytes
CPU utilization:
User 0 percent
Background 0 percent
Kernel 0 percent
Interrupt 0 percent

Downloader demo watermarks

Idle
Start time
Uptime
100 percent
2002-03-06 17:23:09 UTC
20 hours, 44 minutes, 41 seconds
Load averages: 1 minute 5 minute 15 minute
0.00 0.00 0.00

98
 3. Juniper Networks Router Architecture
Notice that you can see items such as router uptime (the amount of time the router has been powered up),
temperature of the chassis, and the amount of DRAM installed.
Many parts of the routing engine are field-serviceable (also called field-replaceable), meaning that
replacement or spare parts can be used to get the routing engine back into operation quickly without
having to ship it to Juniper Networks for repair. Replacement of these parts should be done under the
guidance of an engineer from the JTAC and is not recommended for inexperienced service personnel.

Packet Forwarding Engine (PFE)

The PFE is the second basic component of the Juniper Networks router. It is the mass-transit system part
of the router, so to speak. Whereas the routing engine is the brain of the router, the PFE tends to be more
of a workhorse, carrying out the instructions it has been given. The job of the PFE is to move packets as
quickly as possible back out of the router. If it can't do that, for instance when there is no entry in the
forwarding table for a given destination, it hurries the packets bound for that unknown destination off to
the routing engine and goes on about its business.
This section will give you an overview of the design and function of the PFE. It will also show you how
the packets move through the router so that you can fully understand the way the whole system works.

Design and Operation

On Juniper Networks routers, the PFE is designed to perform Layer 2 and Layer 3 switching, route
lookups, and rapid forwarding of packets. Using ASICs, the strategy of the PFE is to divide and conquer

www.ebook-converter.com
the business of forwarding. To that end, the PFE itself is split into several major components:
Midplane
PICs
FPCs
Control board (switching/forwarding)
The midplane, sometimes referred to as the backplane, is really the back of the cage that holds the line
cards. The line cards connect into the midplane when inserted into the chassis from the front. The routing
engine plugs into the rear of the midplane from the rear of the chassis. The purpose of the midplane is to
carry the electrical signals and power to each line card and to the routing engine.
The PICs are the actual components that contain the interface ports. Each PIC is plugged into a FPC,

Downloader demo watermarks

such as the one shown in Figure 3-7. Each individual PIC contains an ASIC that handles media-specific
functions, such as framing or encapsulation, and has its own LED status indicator on the front. PICs are
available for SDH/SONET, ATM, Gigabit Ethernet, Fast Ethernet, and DS3/E3.

99
 3. Juniper Networks Router Architecture

Figure 3-7. The FPC

The FPC can contain from one to four PICs in a mix-and-match style. In other words, you could have
four different kinds of PICs on a single FPC. This reflects a great deal of flexibility that is welcome in
most networks. Installed from the front of the chassis, the FPC carries the signals from the PICs to the
midplane. Each FPC has its own input-output (I/O) ASIC and buffer memory.
In the M5 and M10, PICs do not connect to an FPC, but to an FEB. In the M20, M40, and M160, PICs

www.ebook-converter.com
connect to an FPC. There are obviously other significant architectural differences. The PICs for the M5
and M10 are interchangeable; however, due to architectural differences these same PICs cannot be used
in the M20, M40, and M160.
The FPC performs the important functions of decapsulating the packet, parsing it, and breaking it up into
64-byte memory blocks, before passing it to the distributed buffer manager (DBM) ASIC. It is at this
point that the packet is first written to memory. The DBM ASIC manages and writes packets to the
shared memory across all FPCs. While writing the packets to buffer memory, the DBM ASIC is also
extracting information on the destination of the packet, as you will see this when we look at packet flow
later in this section.

Note
In each router slot, there must either be an FPC or a blank panel installed to ensure adequate
cooling and airflow through the router.

Downloader demo watermarks

The M160 router is the only exception to this overview of the FPC. The M160 actually can use two
different types of FPC—the FPC1 and the FPC2.
The control board is an add-on component in the PFE and will be covered in more detail in Section
3.2.2.2. Each control board performs part of the overall function of the PFE, such as communications
100
 3. Juniper Networks Router Architecture
with the routing engine through an internal interface and with the FPCs through an internal hub.

PFE Processes
As Figure 3-8 shows, the PFE has an embedded microkernel that serves as the brains of the PFE,
interacting with the interface process and the chassis process to monitor and control these functions. It is
the interface process that has direct communication with the kernel of the routing engine. This
communication includes forwarding exception and control packets to the routing engine, receiving
packets to be forwarded, receiving the forwarding table updates, providing information about the health
of the PFE, and permitting configuration of the interfaces from the user-CLI process on the routing
engine.

Figure 3-8. Packet Forward Engine Processes

The PFE contains a stored forwarding table, which is static until a new one is received from the routing
engine. No dynamic routing protocol processes run on the PFE. The interface process consults the
forwarding table to look up next-hop information. The interface process also has direct communication
with the ASICs on the PFE, which will be discussed in detail in the next section. Finally, the chassis
www.ebook-converter.com
processes—environment, health, and so on—communicate directly with the microkernel of the PFE and
with the ASICs.

ASICs
Now we will take a look at the location of the ASICs involved in packet processing and see how they
relate to one another. Figure 3-9 shows a section-by-section view of the positioning and communication.

Downloader demo watermarks

101
 3. Juniper Networks Router Architecture

Figure 3-9. System ASICs

Starting from the bottom of Figure 3-9, you can see that each of the PICs contain at least one I/O
manager ASIC responsible for media-specific tasks, such as encapsulation. The packets pass through
these I/O ASICs on their way into and out of the router. The I/O manager ASIC on the PIC is specifically
responsible for the following:
Managing the connection to the I/O manager ASIC on the FPC

www.ebook-converter.com
Managing link-layer framing and creating the bit stream
Performing cyclical redundancy checks (CRCs)
Detecting link-layer errors and generating alarms, when necessary
On the FPC is another I/O manager ASIC. This ASIC takes the packets from the PICs and breaks them
into 64-byte memory blocks, also known as J-cells, for storage in shared FPC memory. It is at this point
that accounting is performed and CoS policies, which define the handling of traffic based upon
classification of types of service, are implemented. This ASIC is specifically responsible for the following:
Breaking incoming packets (as bit streams) into 64-byte blocks, or J-cells
Sending the J-cells to the first DBM
Decoding encapsulation and protocol-specific information

Downloader demo watermarks

Counting packets and bytes for each logical circuit
Verifying packet integrity
Applying CoS rules to packets
102
 3. Juniper Networks Router Architecture
The first DBM ASICs encountered are responsible for receiving the J-cells and spreading them across the
shared memory. In the M40, it is the backplane that contains the DBM ASICs; on the M5, M10, M20 and
M160, the DBM ASICs are on the control boards.
In parallel, the first DBM ASIC passes forwarding-related information extracted from the packets to the
Internet processor, which then performs the route lookup and sends the information over to a second
DBM ASIC. The Internet processor ASIC also collects exception packets and sends them to the routing
engine. This second ASIC then takes this information and the 64-byte blocks and forwards them to the
I/O manager ASIC of the egress FPC—or multiple egress FPCs, in the case of multicast—for reassembly.
The DBM ASICs are responsible for the following:
Managing the packet memory distributed across all FPCs
Extracting forwarding-related information from packets
Telling the FPC where to forward packets
The Internet processor ASIC is responsible for the following:
Extracting next-hop information from the forwarding table
Passing the next-hop information to the second DBM ASIC
Collecting exception packets to send to the routing engine

www.ebook-converter.com
The I/O manager ASIC on the egress FPC can perform some value-added services. In addition to
incrementing TTL values and re-encapsulating the packet for handling by the PIC, it can also apply CoS
rules. To do this, it may queue a pointer to the packet (never the packet itself) in one of four available
queues, each having a share of link bandwidth, before applying the rules to the packet. Queuing can be
based on destination address, the random early detection (RED) or weighted RED (WRED) algorithm,
the value of precedence bits, and so on. Thus, we can say that the I/O manager ASIC on the FPC is
responsible for the following:
Receiving the J-cells from the second DBM ASIC
Incrementing TTL values, as needed
Queuing a pointer to the packet, if necessary, before applying CoS rules
Re-encapsulating the J-cells

Downloader demo watermarks

Sending the encapsulated packets to the PIC I/O manager ASIC

Packet Flow
Now that you have a little background information on the various ASICs, it is helpful to see exactly how
103
 3. Juniper Networks Router Architecture
a packet moves through the router. Knowing how the packets move through the router can help clarify
what you have learned about the architecture of the router. First, take a look at Figure 3-10, and then
read the explanations below to see how the forwarding decisions are made.

www.ebook-converter.com

Figure 3-10. Packet Flow Forwarding Decisions

The router first receives a packet on an ingress, or incoming, PIC. The PIC I/O manager ASIC performs
the type of checksum and frame checks that are required by the type of medium it serves. Once this is
done, the packet is passed, as a serial bit stream, to the FPC that houses the PIC.
The I/O manager ASIC on the FPC performs the important functions of decapsulating the packet, parsing
it, and breaking it up into 64-byte memory blocks, before passing it to the first DBM ASIC. At this point,
the packet is first written to memory. The DBM ASIC writes all packets to packet buffer memory, which
Downloader demo watermarks
is distributed across all FPCs on the router. While writing the packets to buffer memory, the DBM ASIC
is also extracting information on the destination of the packet.
Once destination information is determined, it is sent to the Internet processor ASIC, which performs the
lookup in the forwarding table. Note that the forwarding table is not omnipotent. It can handle unicast
104
 3. Juniper Networks Router Architecture
packets that do not have options, such as accounting, set. It can also handle multicast packets for which it
already has a cached entry. All other packets must go to the routing engine for advanced lookup and
resolution. If the PFE can handle the forwarding of the packet, it finds the next hop and egress interface.
The packet is then forwarded to the second DBM ASIC, which passes the packet to the I/O manager
ASIC on the FPC of the egress interface.
Now the packet may be queued. Actually, as stated earlier it is a pointer to the packet that is queued. The
packet itself remains in the shared FPC memory. All queuing decisions and CoS rules are applied in the
absence of the actual packet. When the pointer for the packet reaches the front of the line, the I/O
manager ASIC sends a request for the packet to the second DBM ASIC. The DBM ASIC reads the J-cells
from shared memory and sends them to the I/O manager ASIC on the FPC, which then serializes the bits
and sends them to the media-specific ASIC of the egress interface.
The I/O manager ASIC on the egress PIC applies the physical-layer framing, performs the CRC, and
sends the bit stream out over the wire.

Model Differences in Control Boards

Each model of router has its own component that performs part of the overall function of the PFE. Each
board will be described in a little more detail, but the operations performed by them are similar in nature.
Each board communicates with the routing engine through a 100Mbps internal interface and with the
FPCs through 10Mbps interfaces on an internal hub. The primary functions of the control boards are as
follows:
Reset of FPC when abnormal behavior is detected—The board will attempt to reset the FPC up to

www.ebook-converter.com
three times. If unsuccessful, the control process takes the FPC offline and sends a notification to the
routing engine.
Transfer of control and exception packets—The control board handles nearly all exception packets—
those packets for which there is no known path to the destination—passed to it from the Internet
processor ASIC. The board may then pass exception packets to the routing engine. It may also
communicate errors to the routing engine via syslog messages.
Route lookups—A copy of the forwarding table is stored in SSRAM. When packets are received to
be processed, the Internet processor ASIC performs the lookup on this table, makes a forwarding
decision, sends a message to the midplane about the decision, and forwards the packets to the egress
interface.
System monitoring—The control board keeps tabs on the condition of the router based on
information it receives from sensors. If an abnormal condition is detected, the board immediately
notifies the routing engine.
Downloader demo watermarks
On most of the M-Series routers, the control board is hot-pluggable, meaning that the router need not be
powered down to install or uninstall the control boards. A brief service interruption will occur, usually
about 500 ms. On the M5 and M10 routers, however, the FEB is not hot-pluggable. The system must be
powered down for maintenance and replacement of this board.
105
 3. Juniper Networks Router Architecture
M5 and M10 FEB
The M5 and M10 routers are the newest of the M-Series line. Despite their small footprint, these
powerful routers also use control boards in the PFE. The FEB installs in the rear of the M5 or M10
chassis, just above the power supply. The FEB on the M5 and M10 is neither hot-removable nor hot-
insertable! You must power down the chassis before removing or inserting these boards.
The FEB contains the following:
A processor
The Internet Processor II ASIC
Two DBM ASICs
I/O ASIC with 1MB SRAM—one on the M5, two on the M10
33MHz PCI bus connecting the system ASICs
The FEB also has its own storage—four slots of 2MB RAM to store forwarding tables associated with the
ASICs, 64MB DRAM for the microkernel, EEPROM for the storage of the serial number and version of
the FEB, and 512MB flash EPROM, which is programmable.

M20 SSB

www.ebook-converter.com
On the Juniper Networks M20 router, the SSB installs from the front of the chassis into the upper-most
slot. The SSB contains the Internet Processor II ASIC and two DBM ASICs. The SSB has its own
processor and its own storage—four slots of 2MB RAM to store forwarding tables associated with the
ASICs, 64MB DRAM for the microkernel, EEPROM for the storage of the serial number and version of
the SSB, and 512MB flash EPROM, which is programmable.

M40 System Control Board

On the Juniper Networks M40 router, the system control board (SCB) installs from the front of the
chassis into the center slot. The SCB contains its own processor, a PCI bus and the Internet processor
ASIC, as well as 1 to 4MB SSRAM (for forwarding tables), 64MB DRAM (for the microkernel),
EEPROM (which stores the SCB serial number and version), and 512MB flash EPROM (programmable).

M160 Switching and Forwarding Module

Downloader demo watermarks

On the Juniper Networks M160 router, up to four interconnected switching and forwarding modules
(SFMs) can be configured. Each SFM is a two-board system containing the following components:
Internet Processor II ASIC for route lookups and forwarding
Two DBM ASICs, one to send packets to the output buffer and another to communicate notifications
106
 3. Juniper Networks Router Architecture
to the I/O ASIC on the FPCs
8MB parity-protected SSRAM
A processor subsystem for the handling of exception and control packets
EEPROM for storage of board serial number and version information
LEDs and an offline button for use prior to module removal
As stated earlier in this section, the M160 control board may be removed without a complete service
interruption. There will, however, be a pause of about 500 ms while the router redistributes the functions
to all other SFMs still inserted in the chassis.

PFE Clock Generator

The Juniper Networks M160 router has an additional unique feature—an added board that acts as a clock
source. The PFE clock generator (PCG) is located in the rear of the chassis, beside the routing engine.
The PCG supplies a 125MHz clock source to the ASICs and modules that are part of the PFE. The M160
has two PCGs installed for redundancy. These PCGs are field replaceable and hot-pluggable.
The PCG has three LEDs—one to indicate an OK state, one to indicate a Fail condition, and one that will
illuminate if the PCG is the master. In addition, there is an offline button that will permit the user to take
the PCG offline before removing it.

www.ebook-converter.com
Management and Traffic Interfaces
This section will introduce you to the two types of interfaces available on the routers: management and
traffic. A management interface is a physical or virtual port through which the router can be configured,
maintained, or monitored, but which does not route traffic. A traffic interface is one through which
routable network conversations are forwarded.
Several methods are provided that permit for the management and administration of the routers. These
interfaces to the router include the following:
SNMP—Network engineering staff or administrators can not only learn about the health and activity
of the router through SNMP, but can also configure it from a network management workstation using
any popular SNMP tool. The benefit of this is that it makes configuration management simple. Past
configurations can be archived (and dated) on the management station. It also means that many
remote routers can be managed and configured from a central workstation.

Downloader demo watermarks

User CLI—The user process running on the routing engine permits management of the router through
the CLI. The network engineer or administrator can, in this way, configure routing protocols,
interface specifics, and systemwide instructions through a console, workstation, or laptop.
Craft interface—The craft interface, as we discussed in Section 3.2.1.4, provides a window into the
107
 3. Juniper Networks Router Architecture
operations of the router—its health, uptime, and alarms. The craft interface also allows the
administrator to take an FPC offline for removal and maintenance.
Table 3-4 shows the types of traffic interfaces that each M-Series model can support:
Table 3-4. Traffic Interface Types per Model
PIC Type M5 and M10 M20 and M40 M160
ATM Uses all ATM types Uses all ATM types Uses all ATM types
4-port DS-3
4-port E3
2-port OC-3/STM-1 MM and SMIR
1-port OC-12/STM-4 MM and SMIR
Channelized DS-3 Uses both Uses the 4 port only Uses the 4 port only
2-port DS-3 with 28 T1 channels per port
4-port DS-3 with 28 T1 channels per port
Channelized OC-12 to DS-3 Yes Yes Yes
1-port OC-12 SMIR with 12 DS-3 channels

www.ebook-converter.com
per port
Channelized STM-1 to E1 Yes Yes Yes
1-port STM-1 SMIR with 63 E1 channels
per port
DS-3 Uses both Uses the 4 port only Uses the 4 port only
2-port
4-port
E1 Yes Yes Yes
4-port
E3 Uses both Uses the 4-port onlyUses the 4-port only

Downloader demo watermarks

2-port
4-port

Fast Ethernet Uses the 4-port onlyUses the 4-port onlyUses both
108
Fast Ethernet 3. Juniper
Uses the 4-port onlyUses Networks
the 4-port Router
onlyUses bothArchitecture
PIC Type M5 and M10 M20 and M40 M160
4-port
48-port
Gigabit Ethernet Uses the1-port only Uses the1-port only Uses all
1-port LH, LX, SX
2-port LX and SX
4-port SX
SONET/SDH
2-port OC-3c/STM-1 MM and SMIR YesNo No
4-port OC-3x/STM-1 MM and SMIR YesNo No
1-port OC-12c/STM-1 MM and SMIR both in concatenated and nonconcatenated modesYesNo No
4-port OC-3c/STM-1 MM and SMIR No YesYes
1-port OC-12c/STM-4 MM and SMIR both in concatenated and nonconcatenated modesNo YesYes
4-port OC-12c/STM-4 MM and SMIR No No Yes
1-port OC-48c/STM-16 SMSR concatenated and nonconcatenated modes No YesYes
1-port OC-48c/STM-16 SMLR concatenated and nonconcatenated modes No YesNo
1-port OC-192x/STM-64 SR2 and LR both in concatenated and nonconcatenated modes No No Yes
T1 YesYesYes
4-port
Tunnel Services PIC YesYesYes

www.ebook-converter.com
The difference between the models lies primarily in the number of ports supported and in the type of
throughput that is available on the backplane. Table 3-5 lists the type of throughput, the number of PICs
supported, and the number of ports for each model.
Table 3-5. Port Density by Model
Model M5 M10 M20 M40 M160
Full-Duplex Throughput 6.4Gbps 10Gbps 20Gbps 40Gbps 160Gbps
Medium to Medium to Medium to
Target Network Size Large Large Large Large Very Large
Number of PICs 4 8 16 32 32
Supported
Number of Ports Up to 16 Up to 32 Up to 64 Up to Up to 32 OC-12
128
or
Downloader demo watermarks Up to 32 OC-48
or

109
 3. Juniper Networks Router Architecture
Model M5 M10 M20 M40 Up to 8 OC-192
M160
It is important to note that, by default, all physical interfaces on the Juniper Networks routers use PPP,
but can be configured to use other Layer 2 encapsulation types. If an interface is of a type that does not
support PPP, you must configure the appropriate encapsulation type. For specific information about
interface encapsulation options, including configuration examples, please refer to Chapter 8.

Cooling Systems
With the exception of the M5 and M10 routers, each Juniper Networks router incorporates redundancy in
the cooling system. This section provides a general familiarity with the airflow through each model of the
M-Series routers.

Caution
Never operate the router for more than one minute without the fan assembly installed! The
function of the fans is to keep all components cooled to an optimal operating level. Running the
unit without fans in place could void your warranty and limit any maintenance available to you.
Check with your Juniper Networks representative for more information.

M5 and M10
The single fan assembly on either an M5 or M10 is on the left side of the router if you are facing the front
of the chassis. The fan assembly contains four fans that pull air from the left to the right across the PICs.
Juniper Networks suggests leaving six inches on either side of any installed M-Series router, as shown in
www.ebook-converter.com
Figure 3-11, to ensure adequate airflow.

Figure 3-11. M5/M10 Airflow

M20
The M20 router has four fan assemblies—three on the front of the chassis and one in the rear. The three
fans on the front left side of the chassis provide side-to-side cooling for the FPCs and for the SSB. The
rear fan assembly is located to the right of the routing engine and provides cooling directly to the routing
Downloader demo watermarks
engine. All four fan assemblies plug directly into the router midplane. In addition, the power supplies on
the M20 router have integrated fans, providing built-in power-supply cooling. The airflow model is shown
in Figure 3-12.

110
 3. Juniper Networks Router Architecture

Figure 3-12. M20 Airflow

M40
The cooling system for the M40 router is a little more complex, consisting of three separate subsystems:
the impellers, the integrated power-supply fans, and the triple fan assemblies.
The router contains two sets of redundant impellers, located at the top of the chassis and at the bottom of

www.ebook-converter.com
the card cage. These impellers pull air in through the front of the card cage and across the PFE, forcing
the exhaust out the back of the chassis, thus cooling the PFE. You can see this process in Figure 3-13.
The impellers are designed to run at less than full capacity unless a condition is detected, such as a rise in
temperature, which would increase the cooling needs. At that point, the impellers can adjust the fan
speed to meet the new requirements. An air filter protects the impeller from drawing in foreign objects
that could damage the fans. It is a good idea to keep the air filter in place when the router is operational.

Downloader demo watermarks

111
 3. Juniper Networks Router Architecture

Figure 3-13. M40 Airflow

www.ebook-converter.com
A set of three load-sharing fan trays, located at the upper rear of the chassis, pull in air through a filter
and intake at the front of the chassis to keep the routing engine cool. Because the fan trays are load-
sharing, if one fan tray is removed, the others remaining will adjust to meet the current cooling
requirement.
Finally, the power supplies on the M40 router have integrated cooling fans, just like those on the M20.

M160
The M160 router also uses impellers and fan trays to keep the system cool. A front cooling system uses
an upper impeller that works with the fan tray (installed in front) to pull air through the front of the
chassis, up through the card cage, and then sends the exhaust out the rear of the chassis.
The rear cooling system uses two impellers in the upper and lower part of the chassis to pull air in over
the routing engine, SFM, MCS, and PCGs. As you can see in Figure 3-14, the air is drawn in through the
Downloader demo watermarks
front of the chassis, through the air intake cover, and the exhaust is sent out the rear of the chassis. The
power supplies are cooled by the front and rear cooling systems and do not have integrated fans.

112
 3. Juniper Networks Router Architecture

Figure 3-14. M160 Airflow

Router Power-up and Boot Process

www.ebook-converter.com
When the router is shipped, it comes with the latest version of JUNOS software loaded on nonrotating
flash memory. Additional copies are provided on the hard disk and on a PC card that is shipped with the
router. When the router is powered-up for the first time, it looks for the software in the following
sequence:
1. PC card, if installed
2. Flash memory
3. Hard disk
The first copy that it encounters is the one it will use. Therefore, it is important to not insert a PC card if
you want to boot from flash memory, for example.

Note
Downloader demo watermarks
It is a good idea to keep the original PC card (as well as any copies of future releases) in a safe
place in case the file system becomes corrupted or unstable. This will allow you to revert to the
original version by rebooting the router with the PC card in place.

113
 3. Juniper Networks Router Architecture
To power-up the router, perform the following steps:
1. Power-up the management device that is connected to the console, auxiliary, or management
Ethernet port on the routing engine.
2. Turn the power on for each power supply.
3. Check the power supply OK LEDs and the output to the management device to ensure that the
router booted properly.

Note
If nothing is plugged into the management Ethernet interface, a RED alarm will be generated.
Plug in any device cable with an RJ-45 connector to prevent this alarm.
Other visible activity to check at startup includes the following:
Craft interface displays, such as Starting routing engine, Starting PFE, and Starting Card
FPC LEDs, which blink green until testing is complete (if all tests pass, the lights should be solid
green)
Alarm LEDs, as appropriate
PIC LEDs, which remain off unless the interfaces have been configured

www.ebook-converter.com
Configuring the Router
During the initial configuration of the router, you will need to configure the following:
A password for user ROOT. This can be set in three different ways:
1. Plain text (not logged, if logging is enabled):
root@router# set system root-authentication plain-text-password
password (password is prompted on a separate line)
2. Pre-encrypted:
root@router# set system root-authentication
encrypted-password password

Downloader demo watermarks

3. Secure shell (SSH) key (on domestic U.S. systems only):
root@router# set system root-authentication
ssh-rsa key

114
 3. Juniper Networks Router Architecture
A hostname for the router: [edit] root@router# set system host-name name
The domain name:
[edit]
root@router# set system domain-name domain

The IP address and subnet mask of the management Ethernet port:

[edit]
root@router# set interfaces fxp0 unit 0 family inet
address ip-address/prefix-length

The default route:

[edit]
root@router# set system backup-router gateway-address
root@router# set routing-options static route default
nexthop gateway-address retain no-advertise

The domain name server (DNS) IP address:

[edit]
root@router# set system name-server dns-address

At least one NON-ROOT user:

[edit]

www.ebook-converter.com
root@router# set system login user username class class
authentication plain-text-password

Note
It is vitally important to configure a NON-ROOT user, as ROOT cannot Telnet into the router!
After configuring the preceding, save your changes:
[edit]
root@router# commit

JUNOS Software Upgrade Procedure

Juniper Networks releases several new versions of JUNOS software each year, as needed. This section
will prepare you to perform a JUNOS software upgrade to the router.
Downloader demo watermarks
Every JUNOS software release is actually a group of files bundled together. These files can be installed
all at once or individually. Table 3-6 lists the files contained in the release.
Table 3-6. JUNOS Upgrade Software Release Files

115
 3. Juniper Networks Router Architecture
Filename Contents
jbase Additions to JUNOS
jkernel The operating system package
jroute The routing engine software
jpfe The PFE software
jdocs Updated online reference documentation
jcrypto Security software (U.S. domestic only)
jbundle All of the files combined
To see the software that is currently installed on the router, use the following command:
root@router> show system software

Information for jbase:

Comment:
JUNOS Base OS Software Suite [5.0R3.3]
Information for jcrypto:
Comment:
JUNOS Crypto Software Suite [5.0R3.3]

Information for jdocs:

Comment:
JUNOS Online Documentation [5.0R3.3]

www.ebook-converter.com
Information for jkernel:
Comment:
JUNOS Kernel Software Suite [5.0R3.3]

Information for jpfe:

Comment:
JUNOS Packet Forwarding Engine Support [5.0R3.3]
Information for jroute:
Comment:
JUNOS Routing Software Suite [5.0R3.3]

Information for junos:

Comment:
JUNOS Base OS boot [5.0R3.3]

Downloader demo watermarks

To upgrade your software, there are several simple steps (following this list, we will explain each item in
more detail):
1. Download the software package(s) you need from the Juniper Networks Web site.

116
 3. Juniper Networks Router Architecture
2. Perform a system backup on the router you wish to upgrade.
3. Copy the software package(s) to the router you wish to upgrade.
4. Add the new software package(s) to the router you wish to upgrade (this will effectively delete the
old packages).
5. Reboot the router.

Downloading the Software

When you download JUNOS software from the Juniper Networks Web site at www.juniper.net/support
using your authorized username and password, you will notice that the packages use a standard naming
convention. The format is package-x.yZnumber.tgz:
Package is the name of the file (such as jbundle).
x.y is the software version.
Z is the type of release. For most customers, this will be an R for released version. For some
customers, it may be A (alpha release), B (beta release), or I (internal release).
number is the software release number and build, if applicable.

Backing Up the System

www.ebook-converter.com
You can create a recoverable snapshot of the current system, if it is stable, before proceeding. Using this
command, however, will make the running and backup versions of the software identical and will mean
that you cannot revert back to the original version that shipped with the router. To make the snapshot,
use the following command:
root@router# request system snapshot
This will back up the /root file system to /altroot and the /config file system to /altconfig
on the hard disk.

Copying the Package(s) to the Router

After you have backed up your system files, copy the new software bundle to the router's hard disk, using

Downloader demo watermarks

a command such as the following:
root@router# file copy
ftp://username:[email protected]/ filename
/var/tmp/filename

117
 3. Juniper Networks Router Architecture
This will copy the file from an FTP server to the /var/tmp directory on the router's hard disk. This is
simply an example of one way to copy the file. The M40 also has an LS-120 floppy drive that can be
used for the storage and transfer of files. When installing a new software version, you should do so from
an out-of-band management source, such as the console. An in-band source, such as Telnet, could be lost
while you are upgrading.

Adding the Package(s)

Once the files have been copied to the hard disk, upgrade the software using the following command:
root@router> request system software add package-name
Checking available free disk space...11600k available, 6076k suggested...
Installing package '/var/tmp/jbundle-package-name' ...
Auto-deleting old jroute...
Auto-deleting old jdocs...
Auto-deleting old jpfe...
Auto-deleting old jkernel...
Adding JUNOS base software release-number...
Adding jkernel...
Adding jpfe...
Adding jdocs...
Adding jroute...
NOTICE: uncommitted changes have been saved in
/var/db/config/juniper.conf.pre-install
www.ebook-converter.com
Saving package file in /var/sw/pkg/jbundle-package-name ...
As you can see in the example, once you begin to install the new jbundle, the system deletes the old
information and explodes (expands) the zipped files contained in the new bundle into the
/var/sw/pkg/jbundle-package-name file.

Finishing the Upgrade

Once the software upgrade has completed, you should perform a system reboot. This is the last step in
upgrading the JUNOS software package(s). Use the following command:
root@router> request system reboot

Note

Downloader demo watermarks

Special instructions for upgrading to version 5.0 or reverting to an earlier release from version
5.0 are available on the Juniper Networks Web site at
www.juniper.net/techpubs/software/junos50/swconfig50-getting-started/html/getting-started-
upgrade50.html#1017395.

118
 3. Juniper Networks Router Architecture
JUNOScript
As of JUNOSv4.3B2, the JUNOScript feature is available. This feature provides an alternate method for
communicating information to and from the router. This method is an extensible-markup-language
(XML) interface for communicating with the router. Because the JUNOScript API is an XML interface,
it enables you to build client applications for monitoring and communicating information to and from the
router using Perl. JUNOScript can also support HTML through the use of CGI scripts.
JUNOScript needs to be configured on a UNIX machine. The process to enable a client application can
be found on the Juniper Networks Web site at www.juniper.net/support/junoscript. This link lists the
required software components needed for the installation, as well as links to instructions and sample Perl
scripts for use with JUNOScript.

Chapter Summary
This chapter covered information about the M-Series routers, their architecture, port density, and design,
including the latest models introduced by Juniper Networks—the M40e and the G10. By focusing on the
structure, process flow, and components of each router model, the material has given you a solid basis by
which to understand and apply the information that you will be given in the rest of this book.
After reading this chapter, you should have a good idea of how routing takes place through a Juniper
Networks router, the function of the ASICs, and how fan trays and impellers keep the system
components cool. You have also been familiarized with the router startup process and in what order the
boot image locations are searched.

www.ebook-converter.com
In addition to information on architecture and processes, you were also given information on upgrading
the system software and some simple system administration. These topics will be covered in detail later in
the book.

Bibliography

Downloader demo watermarks

119
[ch03bib01] Ericsson IP Infrastructure, AXI-520/580 course material.
[ch03bib02] www.juniper.net
[ch03bib03] www.lightreading.com

www.ebook-converter.com

Downloader demo watermarks

120
 4. The Command Line Interface
Chapter 4. The Command Line Interface
Juniper Networks routers are equipped with a versatile and efficient interface that you can use to control and enable various JUNOS software
features. To unleash the power of JUNOS and to aid in the true understanding of the capabilities of the Juniper Networks routers, it is critical
that you have a mastery of the CLI. The CLI also serves as an interface in which you can create, modify, control, and manage the JUNOS
configuration files.
In JUNOS software, there are two CLI modes: operational and configuration. This chapter describes modes, their capabilities, and their
navigation. After you understand the capabilities of the CLI, you will be able to customize your CLI environment, understand CLI messages,
monitor users, and get help in each mode.

Operational Mode
The operational mode is used to monitor the current status and the real-time operation of the router. This section will introduce you to the use
of this CLI mode. In contrast to the configuration mode, which will be discussed later in this chapter, the operational mode is used to issue
commands that you want to make active immediately. The configuration mode, on the other hand, is used to edit files that can be saved and
enacted either now or later.

Entering and Exiting Operational Mode

The following example displays the user named lab logging into the router and entering the operational mode:
Chicago(ttyd0)
login: lab
Password:
Last login: Wed Nov 28 18:40:03 from 192.168.161.250
--- JUNOS 5.0R2.4 built 2001-09-25 02:34:13 UTC
lab@Chicago>
After a successful login, you will be at the top level of the CLI operational mode. You can identify this mode by the following operational-mode
prompt:
lab@Chicago>

www.ebook-converter.com
NOTE:The prompt name will vary and will reflect the name of the current
user. In our display the name of the user that has logged in is lab.
Exit the operational mode by using the quit command:
lab@Chicago> quit
Chicago (ttyd0)
login:

Operational-Mode Commands
If you type a question mark at the operational-mode prompt, the router will display all of the available commands as a list. This list displays
functions that can be performed in this mode. As you see in the example below, the operational mode primarily provides commands for
troubleshooting the software, network connectivity, and monitoring and debugging the router. However, in this chapter we will only cover the
commands pertinent to the CLI environment.
lab@Chicago> ?
Possible completions:
clear Clear information in the system
configure Manipulate software configuration information
file Perform file operations
help Provide help information

Downloader demo watermarks

monitor
ping
quit
request
Real-time debugging
Ping a remote target
Exit the management session
Make system-level requests
restart Restart a software process
set Set CLI properties, date, time, craft display text
show Show information about the system

121
 4. The Command Line Interface
ssh Open a secure shell to another host
start Start a software process
telnet Telnet to another host
test Diagnostic debugging commands
traceroute Trace the route to a remote host

set CLI Command

To set the CLI environment to your liking, you can use the set CLI command. The set CLI ?, in the example below, lists the available
parameter options. Explanations of each follow.
lab@Chicago> set CLI ?
Possible completions:
complete-on-space Toggle word completion on space
idle-timeout Set the CLI maximum idle time
prompt Set the CLI command prompt string
restart-on-upgrade Set CLI to prompt for restart after a software upgrade
screen-length Set number of lines on screen
screen-width Set number of characters on a line
terminal Set terminal type

set CLI complete-on-space

The set CLI complete-on-space command enables the automatic completion of a partial command when you press the space bar,
provided that the command is unambiguous. By default, this command is set to on. The syntax for this command is as follows:
set CLI complete-on-space <on|off>
The following example shows how to use this command. The user types show p and presses the space bar. There is not a command called p, so
the output displays that p is ambiguous. However, it also displays all of the commands that start with the letter p. The user now decides that she
wants to find out what types of policy are active on the router. She adds an o to the show p, and presses the space bar, which completes the
command policy.
lab@Chicago> show p

www.ebook-converter.com
'p' is ambiguous.
^

Possible completions:
pfe Show packet forwarding engine data
pim Show information about PIM
policy Show policy information
lab@Chicago> show po<space>
lab@Chicago> show policy

Note
Using the space bar is similar to pressing the tab key, however the tab key will also complete user-configured parameters in the
configuration mode, whereas the space bar will not.

set CLI idle-timeout

The set CLI idle-timeout command lets you set the maximum amount of time, in minutes, that the CLI session will remain open without
any activity. The time value is a range between 0 and 100,000 minutes. Setting the timeout value to 0 will disable the idle-timeout and CLI
session will not expire. The default idle-timeout is set to 0 or disabled. The syntax is as follows:

Downloader demo watermarks

set CLI idle-timeout <timeout> (0-100000 minutes)
The following example shows how idle-timeout works. The idle-timeout has been set to one minute, and there has been no activity for 50
seconds. When there are ten seconds remaining before the session is going to expire, the CLI warns the user that the session will be closed if
there is no further activity. The ten seconds then expire, and we are notified on the console that the idle-timeout has been exceeded and the
session is closing.
lab@Chicago> set CLI idle-timeout 1
122
 4. The Command Line Interface
Idle timeout set to 1 minute
lab@Chicago> Warning: session will be closed in 10 seconds if there is no activity
Idle timeout exceeded: closing session
Chicago (ttyd0)
login:

set CLI prompt

Changing the default prompt of a CLI session can be done by using the operation mode set cli prompt command to change the prompt as
it is displayed.
lab@Chicago> set cli prompt <cli-prompt>
The following example shows how to change the prompt Chicago to newprompt:
Chicago>set cli prompt newprompt
newprompt>

set CLI restart-on-upgrade

The default setting for the set CLI restart-on-upgrade command is on. This means that after a software upgrade is performed, you
will be prompted to restart the router. If you want to disable this for the session, you can set the parameter to off. The syntax required to
enable and disable the command is as follows:
set CLI restart-on-upgrade <on|off>

set CLI screen-length and screen-width

The set screen-length and set screen-width commands are used for making adjustments to the CLI screen. Setting the screen
length will affect the number of lines that are displayed on your screen at one time. After the specified number of lines, your output will pause,
and a -(more)- prompt will be displayed. This -(more)- prompt will allow you to advance the displayed output either one line at a time by
pressing the enter key or one page at a time by pressing the space bar. The size of the page corresponds to the number value set for the screen

www.ebook-converter.com
length. The default screen length is 24. Setting the screen length to 0 will allow the displayed output to scroll without pause. This is useful for
capturing output into a file or for using scripting languages when interacting with the router. Setting the screen width will adjust the number of
columns that are displayed on the screen. The default value for screen width is 80.
The syntax for setting the screen length and screen width are as follows:
set CLI screen-length <length> Number of lines on screen (0..100000)
set CLI screen-width <width> Number of characters on a line (0..100000)
The following examples show how to set these commands:
lab@Chicago> set CLI screen-length 2
Screen length set to 2
lab@m5upper> set CLI screen-width 5
Screen width set to 5

set CLI terminal

In the past, terminals have commonly been referred to as dumb terminals. They do not have a lot of intelligence built in. They usually consist of
a keyboard for entering data and a screen for displaying output. These terminals, however, have been used for many years as an inexpensive
way to monitor and control devices. In addition to these dumb terminals, terminal emulation is also available. Terminal emulation is used on a

Downloader demo watermarks

more intelligent device, such as a PC, to connect to the same devices that were once controlled by dumb terminals.
A good example of a terminal emulator is your PC running some type of terminal emulation software. This software and your PC together will
act as a dumb terminal and usually can be configured to speak several different terminal languages, such as vt100. The Juniper Networks router
can be configured to work with several different terminal types. Setting the terminal type can be done with the set CLI terminal
command. The example below lists the selectable terminal types:

123
 4. The Command Line Interface
lab@Chicago> set CLI terminal ?
Possible completions:
ansi ANSI-compatible terminal
small-xterm Small (24 line) xterm window
vt100 VT100-compatible terminal
xterm Large (65 line) xterm window

Note
Terminal settings that are set in operational mode are only valid for the length of the session. The default terminal type is unknown.

set date
Setting the date and time can be done by using operational-mode commands. The syntax for this is as follows:
set date <time> New date and time (YYYYMMDDhhmm.ss)
The following example shows a sample setting:
lab@Chicago> set date 200202171448.00
Sun Feb 17 14:48:00 UTC 2002

Note
It may be necessary to use the set date command even when using the Network Time Protocol (NTP), as NTP will fail if the time
difference between router and NTP server is large. This will be noted in the logs.

Note
When setting the date and time, do not use any slashes or dashes.

Navigating in Operational Mode

www.ebook-converter.com
While in operational mode, you may want to display a list of available commands. You might also want to list the possible parameters for a
single command. Maybe you want to repeat a part of the same command you just used, delete a character, or possibly even a word. Functions
like these can be performed on the command line by using CLI-provided features, such as the question mark, tab key, and some UNIX-style
keyboard sequences. These keyboard sequences can assist you in maneuvering through the CLI. Table 4-1 lists some of the different keyboard
sequences and their function.
Table 4-1. CLI Navigational Keyboard Sequences
Function Keyboard Sequence
Move cursor back one character Ctrl-b
Move cursor forward one character Ctrl-f
Move cursor to beginning of line Ctrl-a
Move cursor to end of line Ctrl-e
Delete character before the cursor Ctrl-h, Delete, Backspace
Delete character the cursor is on Ctrl-d
Delete word before cursor Ctrl-w, Esc-Backspace, Alt-Backspace
Insert most recently deleted text at the cursor Ctrl-y
Redraw the current line Ctrl-l
Scroll backward through history Ctrl-p
Scroll forward through history Ctrl-n

Downloader demo watermarks

Search CLI history in reverse order
Move cursor back one word
Move cursor forward one word
Delete the word after the cursor
Ctrl-r
Esc-b or Alt-b
Esc-f or Alt-f
Esc-d, Alt-d
Search CLI history Esc-/

Specify the number of times to execute a key-board sequence (number from one to nine)Esc-number sequence, Alt-number sequence
124
 4. The Command Line Interface
Interpreting CLI Messages
From time to time while navigating the CLI, there will be messages displayed on the screen. These messages occur when entering and exiting
configurations, as well as when committing a configuration change. Messages will also be displayed if you have entered invalid or incorrect
input to the CLI. In this section, we will show an example of CLI messages that could be displayed in the operational mode. Configuration-mode
messages will be covered in the next section.
In the following example, the user enters the ambiguous value con. Notice that the caret symbol (^) is displayed at the location in question. This
helps us to identify where we went wrong. The user then tries to set a CLI command and does not enter enough information. This is noted again
by the caret symbol, which is pointing this time to the space after the parameter CLI, and the message displayed lets us know that a command
was expected. In this event, the user may need to include a parameter, such as terminal or complete-on-space, for the expected
command value. This particular example lets us know that while what we have entered is not incorrect, it is not enough information.
lab@Chicago> show con
^
'con' is ambiguous.
lab@Chicago> set CLI
^
syntax error, expecting <command>

Controlling CLI Output on the Screen

When working in the JUNOS CLI, you may be looking for specific information, viewing the output of show commands for monitoring and
troubleshooting, or reading configuration files. These outputs and files can be very lengthy and difficult to read. To help you deal with this
output, the JUNOS CLI includes a variety of tools that will allow you to control how output is displayed and provide you with a mechanism for
filtering and searching the output.

Displaying Output
When output is displayed on the screen, it will be listed one page at a time. The size of the page is determined by the set CLI screen-
length command. This means that when the amount of information that needs to be displayed is greater than the screen length, the CLI will
separate each page of information with a -(more)- prompt. Once the -(more)- prompt is displayed, you can search the output. The
following example shows one page of the displayed output and the -(more)- prompt:

www.ebook-converter.com
lab@Chicago> show configuration
version 5.0R3.3;
system {
host-name Chicago;
login {
user test {
uid 2001;
class superuser;
authentication {
encrypted-password “$Upc0”; # SECRET-D
ATA
}
}
user lab {
uid 2000;
class superuser;
authentication {
encrypted-password “0”; # SECRET-D
ATA
---(more)---

Downloader demo watermarks

As was mentioned previously, there are many useful tools for displaying output to the CLI screen. The following example lists some of these
different tools. If you execute a command, you can use the pipe (|) parameter to customize the way output is displayed on the screen. The pipe
parameter, in this example, permits additional parameters that can be used to search and display information from the router output. This
parameter is quite useful and comes in handy when you are trying to find specific information in large files, such as routing tables.
lab@Chicago> show configuration | ?
Possible completions:
125
 4. The Command Line Interface
count Count occurrences
display Display additional information
except Show only text that does not match a pattern
find Search for the first occurrence of a pattern
hold Hold text without exiting the --More-- prompt
match Show only text that matches a pattern
no-more Don't paginate output
resolve Resolve IP addresses
save Save output text to a file
trim Trim specified number of columns from start of line

Note
The configuration-mode pipe options will include a compare parameter and some additional display commands. We will cover these
in the configuration-mode section.

Filtering Output
From time to time, you might find it helpful to filter the displayed output. Prior to executing a command that would display output to the CLI
screen, you have options to filter the displayed output. These options can be used to count the number of lines in a file, match specific items,
find a certain parameter, and so on. In the following examples, we will discuss these different options and show an example of each.

count
The count parameter is used for counting the number of lines in a file or table. The syntax is as follows:
show route protocol isis | count
The following examples show how to use the count parameter. In the first statement, the user counts the number of lines in the configuration
file. In the second, the user counts the number of lines in the isis section only of the same configuration file:
lab@Chicago> show configuration | count
Count: 143 lines

www.ebook-converter.com
lab@Chicago> show route protocol isis | count
Count: 59 lines

display
The display command is used to display the output in XML format. The syntax is as follows:
show configuration | display xml
The next example shows the output of the display command from the first instance of interfaces to the end of the file in XML format:
lab@Chicago> show configuration | display xml | find interfaces
<interfaces>
<interface>
<name junos:key=”key”>fxp0</name>
<speed>100m</speed>
<link-mode>full-duplex</link-mode>
<unit>
<name junos:key=”key”>0</name>
<encapsulation>802.3-llc</encapsulation>
<family>

Downloader demo watermarks

<inet>
<address>
<name junos:key=”key”>192.168.161.16/24</name>
</address>
</inet>
</family>
</unit>
</interface>
126
 4. The Command Line Interface
</interfaces>
</configuration>
</rpc-reply>

except
The except parameter allows you to display all output except what you specify after the except option. They syntax is as follows:
show configuration | except <pattern> pattern to avoid
The example below shows the configuration file, first without the except option and then with it. Notice that the uid parameter is visible in
the output. When we use the except option, we are going show everything in the configuration file except for uid.
lab@Chicago> show configuration
version 5.0R3.3;
system {
host-name m5lower;
login {
user test {
uid 2001;
class superuser;
authentication {
encrypted-password “$1$A”; # SECRET-DATA
}
}
user lab {
uid 2000;
class superuser;
authentication {
encrypted-password “niG0”; # SECRET-DATA
lab@Chicago> show configuration | except uid
version 5.0R3.3;
system {

www.ebook-converter.com
host-name m5lower;
login {
user test {
class superuser;
authentication {
encrypted-password “$1$A”; # SECRET-DATA
}
}
user lab {
class superuser;
authentication {
encrypted-password “niG0”; # SECRET-DATA

find and match

To find specific information in the Juniper Networks CLI, use the find and match parameters. The find option will display all output,
including the pattern you specify, to the end of the file. The match option will display exactly what you specify and only that. The syntax for
these is as follows:
show route | find <pattern> pattern to search for
show route | match <pattern> pattern to match against

Downloader demo watermarks

The following examples show how these parameters are used:
lab@Chicago> show route | find 192.168.161.0
192.168.161.0/24 *[Direct/0] 3d 02:05:58
> via fxp0.0
192.168.161.16/32 *[Local/0] 3d 02:05:58
Local

127
 4. The Command Line Interface
lab@Chicago> show route | match 192.168.161.0
192.168.161.0/24 *[Direct/0] 3d 02:06:08

Note
If you are using find or match on an entire Internet routing table, for example, there may be a noticeable delay as the Juniper
Networks router does the search. This is normal and should not alarm the user.

hold
The hold option is useful for scrolling up and down through files. Normally, when a command is displayed on the screen, it is displayed one
page at a time; when the output reaches the end of the file, you are sent back to the prompt. This hold option will cause the output to stop at
the end of the file before sending you back to the prompt. This gives you the ability to scroll up and down through the output.
The first output, in the example below, shows the configuration file. The user typing the show configuration command at the Chicago
prompt indicates this. When the output is displayed, the -(more)- prompt appears to indicate the end of that screen and to prompt the user to
press a key to see more. The user then presses the space bar, and the rest of the file is displayed, after which the user is returned to the prompt.
The second output shows the same command used again, but this time it includes the hold option. When the output is displayed in this
example, the first page is the same. However, when the last page is displayed, the user is not sent back to the prompt. Instead, the user sees
100%. This is an indication to the user that he has reached the end of the file, but not been sent back to the prompt. That being the case, the user
can now use the up and down arrows to scroll through the file. Pressing the enter key or space bar when 100% is displayed will return the user
to the prompt. Using Ctrl-c or pressing the q key at anytime will also cause an exit.
lab@Chicago> show configuration
version 5.0R2.4;
system {
host-name Chicago;
login {
class superuser {
permissions all;
}
user lab {
uid 2000;

www.ebook-converter.com
class superuser;
authentication {
encrypted-password “lGdV/”; # SECRET-DATA
}
}
}
services {
ftp;
ssh;
telnet;
}
}
interfaces {
---(more)---
fxp0 {
speed 100m;
link-mode full-duplex;
unit 0 {
encapsulation 802.3-llc;
family inet {
address 192.168.161.16/24;
}

}
Downloader demo watermarks
}
}

lab@Chicago> show configuration | hold

version 5.0R2.4;
system {

128
 4. The Command Line Interface
host-name Chicago;
login {
class superuser {
permissions all;
}
user lab {
uid 2000;
class superuser;
authentication {
encrypted-password “lGdV/”; # SECRET-DATA
}
}
}
services {
ftp;
ssh;
telnet;
}
}
interfaces {
---(more)---
fxp0 {
speed 100m;
link-mode full-duplex;
unit 0 {
encapsulation 802.3-llc;
family inet {
address 192.168.161.16/24;
}
}
}
}
---(more 100%)---

www.ebook-converter.com
save
There may be times when you find it necessary to save captured output to a file. If that is the case, you might want to use the save option. With
the save option, instead of the output being displayed on the screen, the output will be saved to a file. This functionality is similar to redirecting
output to a file in UNIX. The save option will allow the filename specified to be created and saved to a specified location. By default, if path is
not specified, the file will be stored in the user's home directory. It is also possible to send the file to a remote location via FTP.
If you want to see the files that you have saved locally, you can use the file list command to list them. If you type the file list
command on the command line, the list displayed shows the newly saved file. You can also read the files by using the file show command.
Saving a file to an FTP server can be accomplished by specifying the destination in URL format. The syntax for these commands is as follows:
show configuration | save <filename> Output file name (or URL)
file list <[Enter]>
file show <filename> Filename to display
The example below shows the process of saving the file, both locally and via FTP. The file named my_local_file has been created to
include the output of the show configuration command and is saved locally. This is done by using the command show
configuration | save my_local_file. This command will create a file named my_local_file and will redirect the output of the
show configuration command. To list the files saved on the router, the user can use the file list command. If the user wants to
display the contents of the newly saved file named my_local_file, he or she can do this by typing the file show my_local_file
command.

Downloader demo watermarks

lab@Chicago> show configuration | save my_local_file
Wrote 54 lines of output to 'my_local_file'
lab@Chicago> file list
.ssh/
my_local_file
lab@Chicago> file show my_local_file
129
 4. The Command Line Interface
version 4.3R1.4;
system {
host-name Chicago;
ports {
console type vt100;
}
login {
class superuser {
permissions all;
}
user lab {
uid 2000;
lab@Chicago> show configuration | save ftp://192.168.5.107/my_ftp_file
Wrote 54 lines of output to 'ftp://192.168.5.107/my_ftp_file'

trim
The trim option lets you trim columns off of the displayed output. The syntax for this is as follows:
show configuration | trim <columns> Number of columns to trim
In the example below, the user has typed the show configuration command with the trim set to three. Notice that the first three letters of
version and system are no longer displayed. They have been trimmed off.
lab@Chicago> show configuration | trim 3
sion 4.3R1.4;
tem {
host-name Chicago;
ports {
console type vt100;

Searching the Output

When the -(more)- prompt lets you know that there is more information to be displayed, you can use JUNOS CLI keyboard sequences to

www.ebook-converter.com
search and manipulate the on-screen data. Table 4-2 lists these keyboard sequences.
Table 4-2. Keyboard Sequences for Searching and Manipulating On-screen Data
Function Keyboard Sequence
List the keyboard sequences available when the -(more)- prompt is displayedh
Display output all at once (like no-more option) N
Repeat previous search for a string n
Search for a text string (like match option) m or M
Search, ignoring a text string (like except option) e or E
Do not redisplay prompt after displaying the output (like hold option) H
Clear match conditions and display complete output c or C
Save output to a file (like save option) s or S
Scroll down one line Enter, k, Ctrl-m, Ctrl-n, down arrow
Scroll down a half screen Tab, d, Ctrl-d, Ctrl-x
Scroll down whole screen Space, Ctrl-f
Scroll down to bottom of output Ctrl-e, G
Display previous line output j, Ctrl-h, Ctrl-p, up arrow
Scroll up a half screen u, Ctrl-u
Scroll up a whole screen b, Ctrl-b

Downloader demo watermarks

Scroll to top of screen
Search forward
Search backward
g, Ctrl-a
/string
?string
The / parameter can be quite useful for searching files. The following example explains its use. The user has typed the show
configuration command, and the output will now be displayed one page at a time. However, instead of scrolling through the configuration
file page by page, the / can be used to search the file for specific information. Here we want to find the first occurrence of bgp. The user can

130
 4. The Command Line Interface
do this by typing the / and entering the string to search for. In this case, the user types bgp when Search For: is displayed. The result is that
the first occurrence of bgp is displayed on the screen.
lab@Chicago> show configuration
version 5.0R2.4;
system {
host-name Chicago;
login {
class superuser {
permissions all;
}
user lab {
uid 2000;
class superuser;
authentication {
encrypted-password “lGdV/”; # SECRET-DATA
Search for: bgp
bgp {
traceoptions {
file 539test4again2;
flag all;
}
local-address 2.2.2.2;
group IPV4_IBGP_ONLY {
type internal;
family inet {
unicast;
}
family inet-vpn {
unicast;
}
neighbor 4.4.4.4 {
traceoptions {
file vpntest;
flag all;

www.ebook-converter.com
}
}
}
}

ospf {

Viewing the CLI Command History

When working in the CLI, it may be necessary to display the previously executed commands. This can be helpful in recalling the commands you
have recently executed. The JUNOS CLI maintains a command-history buffer of previously executed commands. This buffer is viewable and
searchable using the same options discussed in Section 4.5. The following example shows the output of the show CLI history command.
The default size of the buffer is 24 commands.
lab@Chicago> show CLI history
09:48:23 — show route table mpls.0
09:48:33 — show route table inet.0
09:48:42 — show chassis hardware
09:48:50 — show CLI history

Monitoring Users

Downloader demo watermarks

Another useful and fairly important feature of the CLI is the ability to monitor who is using it. This task can be accomplished by using the show
system users command at the CLI. The show system users command lets you know who is connected to the router, how other users
are connected, when they logged in, and what they are doing. In the following example, the user root is logged in at 8:03 A.M. and is working in
the CLI. The user lab logged in at 7:55 A.M. and is in a shell.
root@Chicago> show system users
8:04AM up 41 days, 18 hrs, 2 users, load averages: 0.02, 0.01, 0.00
131
 4. The Command Line Interface
USER TTY FROM LOGIN@ IDLE WHAT
root d0 - 8:03AM - CLI
lab p0 192.168.161.10 7:55AM 2 /bin/csh

Getting Help in the CLI

The JUNOS CLI is very user-friendly when it comes to help. There are features that you might be familiar with, such as the question mark. The
question mark can be used to tell you the possible next choices for typing commands on the command line. Some of the other features that might
be new to you are help topic, help reference and help apropos. These features support a very robust help facility that is available
through the CLI. It is like having a command reference and configuration guide built into the router. As you will see, these help features can be
very useful for aiding in the configuration of your Juniper Networks router.
The help topic command displays the usage guidelines for a command, and the help reference command displays summary
information about commands. The help apropos command offers syntax information about commands that contain a string you type on the
command line. This feature is available in configuration mode only and is described in the configuration-mode section.
lab@Chicago> help ?
Possible completions:
reference Reference material
topic Help for high level topics
The next example shows the output from the help topic msdp group command. It tells how to use the commands to configure Multicast
Source Discovery Protocol (MSDP).
lab@Chicago> help topic msdp group
Configure MSDP Groups
An MSDP router must know which routers are its peers (neighbors). You define
the peer relationships explicitly by configuring the neighboring routers that
are the MSDP peers of the local router. After peer relationships are
established, the MSDP peers exchange messages to advertise active multicast
sources. You can arrange peers into different groups. Each group must contain
at least one peer. Arranging peers into groups is useful if you want to block

www.ebook-converter.com
sources from some peers and accept them from others or set tracing options on
one group and not the others.
To configure MSDP groups, include one or more of the following statements at
the [edit protocols msdp group group-name] hierarchy level:
[edit protocols msdp]
group group-name {
disable;
export [ policy-name ];
import [ policy-name ];
local-address address;
mode <(mesh-group | standard)>;
traceoptions {
file name <replace> <size size> <files number> <no-stamp>
<(world-readable | no-world-readable)>;
traceflag flag <flag-modifier> <disable>;
}
peer address; {
disable;
export [ policy-name ];
import [ policy-name ];
local-address address;
traceoptions {

Downloader demo watermarks

<no-stamp>
file name <replace> <size size> <files number>
<(world-readable | no-world-readable)>;
flag flag <flag-modifier> <disable>;
}
}
The individual statements are discussed in separate sections.
132
 4. The Command Line Interface
The help reference command gives a little more detail and provides a summary of the commands for MSDP.
lab@Chicago> help reference msdp group
group
Syntax
group group-name {
disable;
export [ policy-name ];
import [ policy-name ];
local-address address;
mode (mesh-group|standard)
traceoptions {
file name <replace> <size size> <files number> <no-stamp>
<(world-readable | no-world-readable)>;
flag flag <flag-modifier> <disable>;
peer address; {
disable;
export [ policy-name ];
import [ policy-name ];
local-address address;
traceoptions {
file name <replace> <size size> <files number> <no-stamp>
<(world-readable | no-world-readable)>;
flag flag <flag-modifier> <disable>;
}
}
}
Hierarchy Level
[edit protocols msdp]

www.ebook-converter.com
Description

Define an MSDP peer group. MSDP peers within groups share common
traceoptions, if present and not overridden for an individual
peer with the peer statement. To configure multiple MSDP groups, include multiple group
statements.
By default, the group's options are identical to the global MSDP options.
To override the global options, include group-specific options within the
group statement.
The group must contain at least one peer.
Options
group-name—Name of the MSDP group.
The remaining statements are explained separately in this chapter.
Usage Guidelines

Downloader demo watermarks

See “Configure MSDP Groups”.
Required Privilege Level
routing—To view this statement in the configuration.
routing-control—To add this statement to the configuration.

133
 4. The Command Line Interface
Configuration Mode
The configuration mode is used to enable JUNOS software features, such as interfaces, generic routing information, and routing protocols,
among others. From the operational mode, you can find your way into the configuration mode where you can enable functions and begin to see
your router operate. The following sections describe the navigation, hierarchy, and use of the configuration mode. You will also find out how to
manipulate configuration files, how and where the files are stored, and how to use these files, once they are created.

Entering and Exiting Configuration Mode

The JUNOS CLI gives you two ways to enter configuration mode. The first is by using the edit command; the second is by using the
configure command. The following example shows you how to enter the configuration mode using each of the different commands:
lab@Chicago> edit
Entering configuration mode
[edit]
lab@Chicago#
lab@Chicago> configure
Entering configuration mode
[edit]
lab@Chicago#
Upon entering the configuration mode, you will notice the word edit in brackets above the prompt. This is tells you that you are in configuration
mode and is referred to in JUNOS as a configuration-mode banner. When you change positions in the hierarchy, the banner will change to let
you know where you are.
To move back to the operational mode, you can exit the configuration mode by typing exit at the command line. When you type exit and
press the enter key, Exiting configuration mode is displayed on the screen, and the configuration-mode banner goes away. This
returns you to an operational-mode prompt.
[edit]
lab@Chicago# exit

www.ebook-converter.com
Exiting configuration mode
lab@Chicago>

Configuration-Mode Hierarchy
The configuration mode offers many features and supports a wide range of configurations. It also serves as the doorway to enable the many
features that JUNOS brings to the core Internet space. This section highlights the available commands in the configuration mode and gives a
brief description of each command's functionality. The following example shows the output when typing a question mark at the configuration-
mode prompt. The available commands for the configuration mode are listed.
[edit]
lab@Chicago# ?
Possible completions:
<[Enter]> Execute this command
activate Remove the inactive tag from a statement
annotate Annotate the statement with a comment
commit Commit current set of changes
copy Copy a statement
deactivate Add the inactive tag to a statement

Downloader demo watermarks

delete
edit
exit
help
Delete a data element
Edit a sub-element
Exit from this level
Provide help information
insert Insert a new ordered data element
load Load configuration from an ASCII file
quit Quit from this level
rename Rename a statement
134
 4. The Command Line Interface
rollback Roll back database to last committed version
run Run an operational-mode command
save Save configuration to an ASCII file
set Set a parameter
show Show a parameter
status Display users currently editing the configuration
top Exit to top level of configuration
up Exit one level of configuration

Understanding the Configuration-Mode Banner

As discussed earlier, the CLI is an interface that you can use to monitor, troubleshoot, and configure your router. This section introduces you to
navigation within the configuration mode, which is similar to the operational mode.
Configuration-mode navigation is a fairly simple task. The first thing to look at when using the configuration mode is the banner. Remember that
the word edit is the first banner that you will see when entering the configuration mode. After that, as long as you stay in configuration mode,
that banner will change to correspond to the level of the hierarchy that you are configuring.
The next example shows the output of a user who has just entered the configuration mode and is preparing to configure bgp. When the user
types configure at the operational-mode prompt, the CLI displays Entering configuration mode, and the banner [edit] is added
to the top of the prompt, indicating that the user is now in configuration mode. Just type the word edit with the appropriate completions to
move to a specific level in the hierarchy. Notice that when the user types edit protocols bgp and presses the enter key, the banner
changes to reflect the protocols bgp level of the hierarchy. This location is two levels down from the top of the hierarchy.
lab@Chicago> configure
Entering configuration mode
[edit]
lab@Chicago#
[edit]
lab@Chicago# edit protocols bgp
[edit protocols bgp]

www.ebook-converter.com
lab@Chicago#

Navigating in Configuration Mode

While in the configuration hierarchy, you can move up one or more levels of the hierarchy, move to the top level of the hierarchy, or exit the
hierarchy completely and go back to the operational mode.
The following example explains how to move between levels in the hierarchy. The user named lab types edit protocols bgp family
inet any rib-group. This action takes the user into the appropriate configuration mode and changes the banner to display [edit
protocols bgp family inet any rib-group]. From this level in the hierarchy, the user can move up one level by typing the
command up. In this example, the user types the command up, and the banner changes to [edit protocols bgp family inet any].
He now types up 2, and the banner displays [edit protocols bgp], while the top command takes the user to the top of the
configuration-mode hierarchy. You can see that after the user types top, the banner displays [edit].
[edit]
lab@Chicago# edit protocols bgp family inet any rib-group
[edit protocols bgp family inet any rib-group]
lab@Chicago# top
[edit]
lab@Chicago# edit protocols bgp family inet any rib-group

Downloader demo watermarks

[edit protocols bgp family inet any rib-group]
lab@Chicago# up
[edit protocols bgp family inet any]
lab@Chicago# up 2
[edit protocols bgp]
135
 4. The Command Line Interface
lab@Chicago# top
[edit]

Understanding How and Where the Configuration Files Are Stored

The Juniper Networks router offers a very robust mechanism for managing your configuration files. JUNOS is based on FreeBSD UNIX, so there
are a lot of powerful UNIX features available in the CLI. In this section, we discuss how to manage your configuration files.
When you enter the configuration mode, JUNOS copies the current configuration to a file called the candidate configuration. This candidate
configuration allows you and other users to see changes that have been made to the configuration. However, any changes made will not take
effect until they have been committed. In other words, if you enter the configuration mode and change the system name to mynewsystem, that
new name is visible in the candidate configuration file. However, the prompt still displays the current name. When you commit the configuration
changes by typing the commit command, you will then see the new system name for the router.
JUNOS works with the active configuration file, candidate configuration file, and the previous nine committed configuration files. These files are
stored in different locations within the Juniper Networks router. The active configuration file is named juniper.conf and is stored in the
/config directory on the flash memory. In addition to the juniper.conf file, there are three more files stored in /config:
juniper.conf.1.gz, juniper.conf.2.gz, and juniper.conf.3.gz. These three files are zipped files, but the active configuration
file is not. The remaining five configuration files are stored on the hard disk in the /var/db/config directory and follow the same naming
convention as the others, starting with number four.
The following example shows the operational-mode syntax to display a listing of the files. It also shows an example of how to display their
content in the CLI.
lab@Chicago> file list ?
Possible completions:
<[Enter]> Execute this command
<path> Path to list
lab@Chicago> file list /config
juniper.conf
juniper.conf.1.gz
juniper.conf.2.gz
juniper.conf.3.gz

www.ebook-converter.com
lab@Chicago> file list /var/db/config/
juniper.conf++
juniper.conf.4.gz
juniper.conf.5.gz
juniper.conf.6.gz
juniper.conf.7.gz
juniper.conf.8.gz
juniper.conf.9.gz
juniper.conf.post-install
juniper.conf.pre-install
lab@Chicago> file show ?
Possible completions:
<filename> Filename to display
lab@Chicago> file show /config/juniper.conf
version 5.1R1.4;
system {
host-name Chicago;

Returning to a Previous Configuration

Downloader demo watermarks
The ability to save nine previously committed configuration files is quite useful. This feature allows you to have the router rollback to a previous
configuration with remarkable ease. The example below explains the use of the rollback command, lists the possible completions, and shows
a sample output from using the feature. In this example, the user lab types rollback 2. The result of this command is that the router loads
the second-to-last saved configuration file as the candidate configuration. Thus, a commit must be performed after the configuration file is
loaded for the changes to take effect. Notice that after the commit is performed, the router system name has changed to test.

136
 4. The Command Line Interface
[edit]
lab@Chicago# rollback 2
load complete
lab@Chicago# commit
commit complete
[edit]
lab@test#

Note
When using the rollback command without a number, the router will go back to the last committed configuration, regardless of any
unsaved changes. Before using the rollback command, you can view the contents of the saved files by using the file show
command. This can be useful in helping you to rollback to a specific configuration file. Also, using the show command with
rollback | compare can be helpful in displaying the differences between the current candidate configuration and the previously
saved configuration. The following example shows the output from of a show | compare rollback 0. The differences are
identified by the + (added) and – (removed) signs. These actions will take place, if the file is committed.
[edit]
lab@Chicago# show | compare rollback 0
version 5.1R1.4;
system {
- host-name Chicago;
+ host-name replace_Chicago

Executing Operational-Mode Commands in Configuration Mode

With Juniper Networks routers, it is possible to display the output of operational-mode commands while in the configuration mode. To do this,
you must use the run command in front of the operational-mode command that you want to execute. The following example shows how to
execute the operational-mode command show route protocol isis from the configuration mode:
[edit]
lab@Chicago# run show route protocol isis
inet.0: 32 destinations, 32 routes (32 active, 0 holddown, 0 hidden)

www.ebook-converter.com
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 *[IS-IS/18] 3d 11:20:48, metric 30, tag 2
> to 10.0.21.1 via ge-1/0/0.0
10.0.1.0/24 *[IS-IS/18] 3d 11:20:48, metric 30, tag 2
to 10.0.21.1 via ge-1/0/0.0

Displaying Your Configuration

While in configuration mode, you can display the complete candidate configuration by typing the show command at the top level of the
hierarchy. If you change levels in the hierarchy, then the show command will display the portion of the candidate configuration that
corresponds with the current level.
The example below explains how to use the show command in configuration mode. Typing show from the top-level edit displays the
complete candidate configuration, whereas typing the show command from edit protocols bgp shows only the configuration for bgp. In
addition to using the show command alone, it can be used from the top level of the hierarchy to display the configuration for a particular section
of the configuration. All you need to do is type the level of hierarchy that you wish to display.
[edit]
lab@Chicago# show
version 5.1R1.4;

Downloader demo watermarks

system {
host-name Chicago;
login {
class superuser-local {
permissions all;
[edit protocols bgp]
lab@Chicago# show
137
 4. The Command Line Interface
group internal {
type internal;
local-address 192.168.20.1;
neighbor 192.168.16.1;
}
group external {
type external;
peer-as 2;
neighbor 10.0.23.2;
}
[edit]
lab@Chicago# show routing-options static
route 172.16.252.0/24 {
next-hop 192.168.161.199;
retain;

Saving, Modifying, and Loading Configuration Files

The JUNOS CLI provides tools that give you the option to save, modify, and load configuration files to and from different locations. Files can be
uploaded and downloaded from an FTP server or stored locally on the router. The files can be saved in whole or in part. The JUNOS CLI also
offers some useful tools for modifying and annotating the configuration files. The following sections explain all these features and give
examples.

Saving Configuration Files

As in the operational mode, in configuration mode you can display the configuration and use the <save | > option to save the configuration
to the router or to an FTP server. You do this with the save command.

save
The first example below saves the configuration file on the router; the second example saves the configuration file to an FTP server.

www.ebook-converter.com
The user lab saves a file named testfile locally.
[edit]
lab@Chicago# save testfile
Wrote 94 lines of configuration to 'testfile'
Here the file is saved to an FTP server:
[edit]
lab@Chicago# save ftp://192.168.161.9/testftp
Receiving ftp://192.168.161.9/testftp (1832 bytes): 100%
1832 bytes transferred in 0.0 seconds (2.42 MBps)
Wrote 94 lines of configuration to 'ftp://192.168.161.9/testftp'

Modifying Configuration Files

When working in the CLI, you have the ability to annotate, copy, delete, rename, and insert configuration changes on a per-line or per-
command basis. In addition to these editing features, you also have the ability to deactivate and activate specific sections of the configuration.
This feature is especially useful for testing and for making changes ahead of time that may be enabled during a scheduled maintenance window.
The following commands are arranged in logical order.

Downloader demo watermarks

annotate
The annotate feature lets you store a note in the configuration. This annotation is a way to describe a section of the configuration. This
example shows how to add an annotation to the configuration. It adds the annotation externalannotation to the bgp group named
external.
[edit protocols bgp]

138
 4. The Command Line Interface
lab@Chicago# annotate group external externalannotation
[edit protocols bgp]
lab@Chicago# show
group internal {
type internal;
local-address 192.168.20.1;
neighbor 192.168.16.1;
}
/* externalannotation */
group external {
type external;
peer-as 2;
neighbor 10.0.23.2;

copy
The copy feature can be quite useful. If you need to add many PVCs or add several users, instead of typing each one in individually, you could
use the copy command to create new entries. The example below demonstrates copying the user named lab to a new user named labcopy:
[edit]
lab@Chicago# copy system login user lab to user labcopy

delete
The following command will delete the group named external from the protocols bgp hierarchy. If you wanted to disable bgp
completely, you could use the delete protocols bgp command.
[edit]
lab@Chicago# delete protocols bgp group external

rename
The rename parameter does exactly that—it allows you to change the name of a particular parameter without having to delete it. The example

www.ebook-converter.com
below renames the user labcopy to labcopy2:
[edit system login]
lab@Chicago# rename user labcopy to user labcopy2

insert
The insert command comes in very handy when dealing with the arrangement and order of lines in the configuration file, especially when
dealing with terms in policies. The insert command gives users the ability to move lines around and place them before or after other lines in
the configuration file. The following example shows how you can move and insert a line before another in the configuration file.

Note
The insert command does not create new lines of configuration. In order for lines to be placed before or after other lines, the lines
must already exist in the configuration file. In other words term 3 in this example must already be in the configuration before it can
be inserted before term 2.
[edit policy-options policy-statement insert_test]
lab@Chicago# show
term 1 {
from protocol static;
}
Downloader demo watermarks
then accept;
term 2 {
from protocol bgp;
then accept;
}
term 3 {
from protocol ospf;
139
 4. The Command Line Interface
then accept;
}
lab@Chicago# insert term 3 before term 2
[edit policy-options policy-statement insert_test]
lab@Chicago# show
term 1 {
from protocol static;
then accept;
}
term 3 {
from protocol ospf;
then accept;
}
term 2 {
from protocol bgp;
then accept;
}

deactivate and activate

The commands deactivate and activate are CLI features that can be used to turn parameters off and on without deleting them or
removing them from the configuration file. For instance, in the example below, if the user lab has left the company and will no longer need
access to the router, you can deactivate his account by using the deactivate command. Notice that the user information is still included in
the configuration, but it is listed as inactive. This command is also very useful for adding configurations to be activated later. Suppose that a new
customer will be coming on board next month. We could install the configuration for the customer in an inactive state, and when the time is
right, we can activate the customer's configuration for a very fast implementation.
[edit system login]
lab@Chicago# deactivate user lab
[edit system login]
lab@Chicago# show
class superuser-local {

www.ebook-converter.com
permissions all;
}
inactive: user lab {
uid 2000;
[edit system login]
lab@Chicago# activate user lab
[edit system login]
lab@Chicago# show
class superuser-local {
permissions all;
}
user lab {
uid 2000;

Loading Configuration Files from the CLI

Loading configurations can be performed in the configuration mode by using the load command. There are three variations to the command:
1. load merge combines the contents of new file with the existing candidate configuration file.

Downloader demo watermarks

2. load replace can be used to overwrite a specific section of the configuration.
3. load override will overwrite a complete configuration file.

load merge
The first output below shows the configured interfaces. At this time, the only interface is ge-1/0/0. When the load merge command is
used, the file named interfaces will be combined with the candidate configuration file. The result in this example is the addition of the so-
140
 4. The Command Line Interface
6/0/0 interface.
[edit]
lab@Chicago# show interfaces
ge-1/0/0 {
unit 0 {
family inet {
address 10.0.21.2/24;
}
family iso;
}
}
[edit]
lab@Chicago# load merge interfaces
load complete
[edit]
lab@Chicago# show interfaces
ge-1/0/0 {
unit 0 {
family inet {
address 10.0.21.2/24;
}
family iso;
}
}
so-6/0/0 {
unit 0 {
family inet {
address 10.0.23.1/24;
}
family iso;
}
}

www.ebook-converter.com
load replace
The load replace command is used to replace specified sections within the configuration file. The sections to be replaced need to be
marked with replace: tags. After completing the load replace, the inet address associated with the ge-1/0/0 interface has been
changed.
[edit]
lab@Chicago# show interfaces
ge-1/0/0 {
unit 0 {
family inet {
address 10.0.21.2/24;
}
family iso;
Contents of the replace_ge_inef file
interfaces {
replace:
ge-1/0/0 {
unit 0 {
family inet {

Downloader demo watermarks

}
}
address 10.0.44.2/24;
family iso;

[edit]
lab@Chicago# load replace replace_ge_inet
load complete
141
 4. The Command Line Interface
[edit]
lab@Chicago# show interfaces
ge-1/0/0 {
unit 0 {
family inet {
address 10.0.44.2/24;
}
family iso;

load override
The load override command is used for overwriting the complete configuration file. In the first part of the example below, the current
configuration has the system host-name set to Chicago, and a user account setup for lab. The load file override has only a system host-
name set and the services enabled. When the load override command is used, the filename override will overwrite the candidate
configuration completely.
[edit]
lab@Chicago# show
version 5.1R1.4;
system {
host-name Chicago;
login {
class superuser-local {
permissions all;
}
user lab {
uid 2000;
class superuser;
[edit]
lab@Chicago# load override override
load complete
[edit]

www.ebook-converter.com
lab@Chicago# show
system {
host-name override;
login {
class superuser-local {
permissions all;
}
user lab {
uid 2000;
class superuser;
authentication {
encrypted-password “$ /”; # SECRET-DATA
}
}
}
services {
ftp;
ssh;
telnet;
}
}

Downloader demo watermarks

Loading Configurations from the Terminal
In the JUNOS CLI, it is also possible to enter configuration parameters in ASCII format, either by typing or pasting directly into the terminal.
The following example shows how to do this. The user lab types load override terminal and pastes the configuration into the terminal.
The command will end when the user types Ctrl-d.

Note
142
 4. The Command Line Interface
The load command is dependant on the level of hierarchy. If you are in the middle of the hierarchy and try loading a configuration
with higher-level commands in it, it will error out. Therefore, this command will ONLY run at the top level.
[edit]
lab@Chicago# load override terminal
[Type ^D to end input]
system {
host-name override;
login {
class superuser-local {
permissions all;
}
user lab {
uid 2000;
class superuser;
authentication {
encrypted-password “$ /”; # SECRET-DATA
}
}
}
services {
ftp;
ssh;
telnet;
}
}
load complete

Note
The terminal parameter is available with all three load commands.

Creating Configuration Groups

www.ebook-converter.com
The ability to create configuration groups is a feature that can be used to make the configuration of bulk items much easier than adding a
separate entry for each parameter. The configuration groups will allow you to build a group that has certain characteristics. You can then apply
those features to many sections of the configuration by associating the group with the parameter. When using configuration groups, the section
to which you apply the group will inherit the features that are enabled within the group.
Groups are created in configuration mode. You type the set groups command, give the group a name, and define the parameters that should
be associated with the group. The syntax for configuring a group is as follows:
set groups <group_name> Group name
After creating the group, you need to apply the group to an item or items within the configuration. The syntax for doing this is as follows:
set interfaces apply-groups <value> Groups from which to inherit
configuration data
The following example shows how to configure a group and apply it to an interface. The group created is called encap_fr, and we have
assigned encapsulation frame relay to the group. By doing this, any interface that we apply the group to will inherit the
encapsulation frame relay parameter.
[edit]
lab@Chicago#set groups encap_fr interfaces <so*> encapsulation frame-relay
[edit]

Downloader demo watermarks

lab@Chicago# set interfaces so-6/0/0 apply-groups encap_fr
[edit]
lab@Chicago# show
version 5.0R2.4;
groups {
encap_fr {

143
 4. The Command Line Interface
interfaces {
<so*> {
encapsulation frame-relay;
interfaces {
so-6/0/0 {
apply-groups encap_fr;
unit 0;
}
so-6/0/1 {
unit 0;
}
so-6/0/2 {
unit 0;
}
so-6/0/3 {
unit 0;

Getting Help in Configuration Mode

The help features discussed in the operational-mode section, help topic and help reference, are also available in configuration mode.
We also mentioned the help apropos command earlier, which is a feature that is only available in configuration mode. The help apropos
command lets you display a snapshot of syntax examples for commands that include a specific user-entered string. The following example first
shows the help commands available in configuration mode, then the help apropos command in action. The user types help apropos
asp, and the returned output displays the syntax for all of the commands that include the string asp.
[edit]
lab@Chicago# help ?
Possible completions:
apropos Find help information about a topic
reference Reference material
topic Help for high level topics
[edit]
lab@Chicago# help apropos asp
set system time-zone <time-zone> Europe/Tiraspol

www.ebook-converter.com
Time zone for Transdniestria
set system time-zone <time-zone> Europe/Samara
Time zone for Moscow+01 - Caspian Sea
set protocols bgp traceoptions flag aspath
set protocols bgp group <group_name> traceoptions flag aspath
set protocols bgp group <group_name> neighbor <address> traceoptions flag aspath
set policy-options as-path <aspath_name>
Name to identify AS path regular expression
set routing-instances <instance_name> protocols bgp traceoptions flag aspath
set routing-instances <instance_name> protocols bgp group <group_name> traceoptions flag aspath
set routing-instances <instance_name> protocols bgp group <group_name> neighbor <address> traceoptions flag

Chapter Summary
This chapter introduced the CLI of the Juniper Networks router. It examined the hierarchy and discussed the different modes available for use in
the CLI. The operational mode provides a mechanism for examining status and retrieving statistics about the router. The configuration mode, on
the other hand, gives the ability to turn features on the router on and off. The functional differences between each of the modes were explained
through many examples of navigation through the CLI. This chapter served as a tool to help familiarize you with the CLI and to introduce the
concept of the advanced configuration-management features that set the Juniper Networks router apart from the products of other vendors.

Bibliography
Downloader demo watermarks
Case Study: User and Access Configuration
This case study shows a simple basic configuration of a Juniper Networks router. This configuration explains how to configure a user, enable
some system services like Telnet, FTP, and SSH, and enable the fxp0 management interface for IP connectivity. This basic configuration is
implemented in configuration mode.

144
 4. The Command Line Interface
The first statement creates a user named lab. When creating the user, the authentication plain-text will prompt you to enter and
verify a password for the user. The second set of three statements are individual statements that are used to enable Telnet, FTP, and SSH. The
default behavior for the router is with these services disabled. Lastly, we configure the fxp0 management interface to allow IP connectivity to
the router.

Note
The sample configuration output assumes that a console will be connected directly to the router or user access via IP to the router will
be within the same network segment. If remote access from another network is required, you would need to configure a routing
feature of some kind to make that happen. You can refer to Chapter 8 for details on routing configurations.
[edit]
lab@Chicago# set system login user lab class superuser authentication plain-text-password
New password:
Retype new password:
[edit]
lab@Chicago# set system services telnet
[edit]
lab@Chicago# set system services ftp
[edit]
lab@Chicago# set system services ssh
[edit]
lab@Chicago# set interfaces fxp0 unit 0 family inet address 192.168.161.16/24

Sample Basic Configuration for Router Chicago

The following output serves as a good basic starting configuration for the Juniper Networks router:
lab@Chicago> show configuration

www.ebook-converter.com
version 5.1R1.4;
system {
login {
user lab {
uid 2000;
class superuser;
authentication {
encrypted-password “$.”; # SECRET-DATA
}
}
}
services {
ssh;
}
}
interfaces {
fxp0 {
speed 100m;
link-mode full-duplex;
unit 0 {
encapsulation 802.3-llc;
family inet {

Downloader demo watermarks

}
}
}
address 192.168.161.16/24;

145
[ch04bib01] Ericsson IP Infrastructure, AXI-520/580 course material
[ch04bib02] www.juniper.net

www.ebook-converter.com

Downloader demo watermarks

146
 5. Router Access and System Administration
Chapter 5. Router Access and System Administration
There are two categories of methods for accessing any router. A physical connection can be made from relatively close proximity or a
connection can be made from a remote location. A physical close-proximity connection is by default the only way of connecting to the
router. Once a physical connection has been made and the appropriate configuration statements put into place, connections can be
established from remote locations as needed. With the convenience of remote access comes security risk; therefore, measures must be
taken to prevent unauthorized access to the device. These measures include enabling services that will allow authorized users to access
the system and defining permissions and restrictions for the users based on their individual job responsibilities. These activities are a
major part of the administrative duties of a network engineer.
This chapter describes the craft interfaces on the Juniper Networks M-Series routers and how to configure the settings for the console
port, auxiliary port, and the management Ethernet connections. It also outlines the broad range of administrative activities a network
engineer would perform during a typical router installation. This chapter concludes with a case study, which coherently demonstrates
the configuration components described throughout this portion of the book.

Communicating with the Router

Out-of-band communications with the router, which is the concept of communicating with the router without using resources reserved
for customer traffic, is accomplished through one of three connections that are built into the craft interface on all Juniper Networks M-
Series routers. During initial installation and startup, it is necessary to configure the router through the console port as this is the only
interface enabled by default. Once the auxiliary port and management Ethernet connections have been configured, they also can be
used to access the router's CLI. These interfaces are shown on a Juniper Networks M40 router in Figure 5-1.

www.ebook-converter.com
Figure 5-1. The Juniper Networks M40 Craft Interface
There is some variation in the layout of the craft interface within the Juniper Networks M-Series router family. As is shown in Figures 5-
2 and 5-3, the craft interface for the M160 has no management interface ports. The management interfaces for the M160 are built into
the connector interface panel (CIP), which inhabits a slot running down the left side of the chassis, parallel to the bank of FPCs.

Downloader demo watermarks

Figure 5-2. The Juniper Networks M160 Craft Interface
147
 5. Router Access and System Administration

Figure 5-3. The Juniper Networks M160 CIP

Figure 5-4 shows the craft interface of the Juniper Networks M20 router. Notice that there are two complete sets of management
interfaces, including two console ports, two auxiliary ports, and two management Ethernet connections, because this router has
redundant routing engines, and each engine has its own set of management interfaces. The craft interface used for Juniper Networks M5
and M10 routers is very similar to that of the M40. They each have only a single set of management interfaces due to the fact that they
do not possess redundant routing engines. Figures 5-5 and 5-6 show the craft interfaces of the M5 and M10. Regardless of the variation
in layout, the primary purpose of these connections is to give administrative access to the CLI. From the CLI it is possible to make
configuration changes, run diagnostic commands, upgrade software, and perform graceful shutdowns. If more detail is needed on the
variations between models in the Juniper Networks M-Series line, see Chapter 3.

www.ebook-converter.com
Figure 5-4. The Juniper Networks M20 Craft Interface

Downloader demo watermarks

Figure 5-5. The Juniper Networks M10 Craft Interface

148
 5. Router Access and System Administration

Figure 5-6. The Juniper Networks M5 Craft Interface

Changing the Settings for the Console Port

Of the three connections previously described, the console port is unique in that it is always used for the initial steps needed in
configuration because it is by default the only interface that can be used to access the CLI on a Juniper Networks router. All other
interfaces lack a functional configuration at initial startup. The console port is an RS232 male 9-pin connection on the craft interface of
every Juniper Networks M-Series router. Refer to Figures 5-1 through 5-6 to identify the location of the console port connection on the
craft interfaces of the routers.
By default the console port is considered to be secure in that it is permissible to log into the router as the root user through this
connection. Those familiar with UNIX will recall that the root user has special permissions. In the Juniper Networks world, the root user
is capable of accessing the UNIX kernel, as well as the core of JUNOS. Under normal conditions, root access should be permitted
through the console. However, should a network engineer find it necessary, the console port can be blocked from allowing root access.
The following example shows how to disable the root login on the console port:
[edit system ports console]

www.ebook-converter.com
lab@Chicago# set insecure
The default speed for the console connection is 9,600 baud. The following example shows the command completions for setting the
connection speeds. By using the question mark, the valid completions for any command string can be accessed from any point within
the JUNOS CLI.
[edit system ports console]
lab@Chicago# set speed ?
Possible completions:
115200 Standard terminal at 115200 baud
19200 Standard terminal at 19200 baud
38400 Standard terminal at 38400 baud
4800 Standard terminal at 4800 baud
57600 Standard terminal at 57600 baud
9600 Standard terminal at 9600 baud
If the baud rate on the console port is changed, any user logged in through that port will immediately be disconnected once the change is
committed. The configuration sample below shows how to set the link speed for the console port to 19.2Kbps. It also shows user lab
being logged off once the change is committed:
[edit system ports console]

Downloader demo watermarks

lab@Chicago# set speed 19200

[edit system ports console]

lab@Chicago# show
speed 19200;

[edit system ports console]

149
 5. Router Access and System Administration
lab@Chicago# commit

Chicago (ttyd0)

login:
By default the terminal type is unknown and in the JUNOS world this setting is compatible with most vt100 emulators. Depending on
the type of terminal being used to configure the router, it may be necessary to change the default terminal type. In situations where
something other than a vt100 emulator is being used, use the set type command at the [edit system ports console]
hierarchy level to change the terminal type setting. The options for terminal type are ansi, vt100, and smallterm. If one of these
three is specified, the screen size is set at 80 columns by 24 rows. It is also possible to specify xterm, which will change the screen size
to 80 columns by 65 rows. The configuration sample below shows the terminal type set to xterm:

Note
The set speed command is hidden in JUNOS 5.1 and is not supported in JUNOS 5.3 for the console and auxiliary ports.
[edit system ports console]
lab@Chicago# set type ?
Possible completions:
ansi ANSI-compatible terminal
small-xterm Small (24 line) xterm window
vt100 VT100-compatible terminal
xterm Large (65 line) xterm window

[edit system ports console]

lab@Chicago# set type xterm
[edit system ports console]
lab@Chicago# show
insecure;

www.ebook-converter.com
speed 19200;
type xterm;

Configuring the Auxiliary Port

Because it lacks a configuration, by default the auxiliary port on a Juniper Networks router is not usable. Once enabled, it can be
configured to serve the same purpose as the console port. However, in many implementations, the auxiliary port is connected to a
modem to permit remote users to configure the router by dialing into it. Like the console port, the auxiliary port is an RS232 male 9-pin
connection. Routers with multiple routing engines, specifically the Juniper Networks M160 and M20, will have multiple auxiliary ports.
Refer to Figures 5-1 through 5-6 to identify the location of the auxiliary port connection on the craft interface.
All commands used for configuring the auxiliary port are executed at the [edit system ports auxiliary] hierarchy level. The
command structure is similar to that used for changing the default settings for the console port.
[edit system ports auxiliary]
lab@Chicago# set speed 19200
[edit system ports auxiliary]
lab@Chicago# set type xterm

Downloader demo watermarks

[edit system
lab@Chicago#
[edit system
lab@Chicago#
ports auxiliary]
set insecure
ports auxiliary]
show
insecure;
speed 19200;
type xterm;
150
 5. Router Access and System Administration
The configuration sample below gives us the output from a show command executed at the [edit system ports] level of the
JUNOS hierarchy. Notice that the auxiliary port has a configuration, but the console port does not. As was mentioned previously, the
console port is active by default and has predefined settings. If it is necessary to change the default settings on the console port, as was
done in a previous example, then a configuration can be added for it. If configuration statements for the console port are added, then
they will be visible; otherwise, no configuration for the console port is seen. In this example you can see that the port is insecure, so root
can't access it, the baud rate is 19.2Kbps, and the terminal type is xterm.
[edit system ports]
lab@Chicago# show
auxiliary {
insecure;
speed 19200;
type xterm;
}

Configuring the Management Ethernet

Every Juniper Networks M-Series router has at least two interfaces that have been defined by Juniper Networks as permanent. They are
named fxp1 and fxp0. Fxp1 is an internal interface that is used to connect the routing engine to the PFE and is not configurable by
conventional means through the CLI in JUNOS. The connection between the routing engine and the PFE runs Trivial Network Protocol
(TNP). TNP uses IP at the network layer (Layer 3), but because it is not connection-oriented, it has less overhead than traditional
TCP/IP. Because of the nature of the connections within the router chassis (highly reliable, nodes in close proximity), TNP is more
appropriate than TCP/IP for this application. fxp0 is an external interface known as the management Ethernet interface. The fxp0
interface accommodates a standard RJ45 connection and can be configured to run the TCP/IP, ISO, or MPLS protocols. The
configuration of the fxp0 interface is discussed in detail in Sections 5.1.3.1 and 5.1.3.2 of this chapter.
As was mentioned previously, it is possible for a Juniper Networks M-Series router to have more than two permanent interfaces. The
Juniper Networks M20 and M160 can both support multiple routing engines and therefore require an extra permanent interface, known
as fxp2, to connect the extra routing engine to the TNP network that runs between the routing engines and the PFE. The management
Ethernet connection is referred to as fxp0 on both routing engines.
The console port is always used for initial configuration; however, following the initial installation and completion of a base

www.ebook-converter.com
configuration, the most common method of configuring a router is through a carefully controlled and protected management network.
This arrangement is called a management LAN, to which the Juniper Networks router would connect through the aforementioned fxp0
interface. Due to the popularity of the IP protocol, the management LAN is the most commonly used method of accessing a Juniper
Networks router. The out-of-band management network, if it is well designed, will usually have its own resources provisioned. In other
words, it will not consume the same bandwidth that is reserved for customer traffic. Refer to Figures 5-1 through 5-6 to identify the
location of the management Ethernet connection on the craft interface. Juniper Networks routers that support redundant routing engines
will have two management Ethernet connections on the craft interface.
Like the auxiliary port, the management Ethernet connection is disabled by default. To enable this interface, it is necessary to build a
configuration for it. This configuration is built under the [edit interfaces fxp0] hierarchy level and is described in the
following sections. It is important to note that configuration of the management Ethernet (fxp0) connection is a prerequisite for
accessing the router through Telnet sessions, SSH, or FTP across the management LAN. These protocols and their use in relation to a
Juniper Networks router will be discussed later in this chapter. Sections 5.1.3.1 and 5.1.3.2 describe the physical and logical components
of configuring the management Ethernet connection.

Note
This chapter only covers the minimal commands needed to configure the fxp0 interface. Chapter 7 goes into greater detail on
the steps involved in configuring a fast Ethernet interface.

Downloader demo watermarks

Physical Characteristics
All interface characteristics that precede the unit number are considered physical characteristics. If a physical characteristic is changed,
it will affect all logical interfaces that are configured for the physical interface. What this means is that if there are multiple logical
interfaces enabled on fxp0—a virtual LAN (VLAN), or multiple subnetworks connected to a single physical interface, for example—
changes made to the physical characteristics of the interface will affect all of the subnetwork connections.
151
 5. Router Access and System Administration
It is possible to disable the fxp0 interface physically without removing its configuration. You might want to disable it during various
testing or troubleshooting situations to bring down the link temporarily. The following configuration sample shows how to disable the
fxp0 interface without deleting its configuration by using the disable command at the [edit interfaces fxp0] hierarchy
level:
[edit interfaces fxp0]
lab@Chicago# set disable
[edit interfaces fxp0]
lab@Chicago# show
disable;
Once troubleshooting steps have been completed, it is necessary to delete the disable setting from the fxp0 port; otherwise, it will not
be able to send and receive packets. Use the command syntax below to delete the disable setting from the interface configuration:
[edit interfaces fxp0]
lab@Chicago# delete disable

[edit interfaces fxp0]

lab@Chicago# show
When configuring the management interface it is sometimes necessary to change physical characteristics. In some cases, the default
autonegotiate settings do not work with other vendors' products. In those situations, JUNOS software has provisions that allow
specification of a link speed or link mode as needed. By default the fxp0 interface uses autonegotiation to determine whether to
operate at 10Mbps or 100Mbps. In other words, it readily adapts to the speed of the device that it is connected to. As mentioned
previously, it is sometimes necessary to deactivate the autonegotiate default setting and specify a set link speed. To do this, use a
configuration statement to force the interface to operate at either 10 or 100Mbps. To configure the management Ethernet interface to
operate at a set speed, use the speed command at the [edit interfaces fxp0] hierarchy level. The configuration sample below
shows how to set the link speed to 100Mbps:
[edit interfaces fxp0]
lab@Chicago# set speed 100m

www.ebook-converter.com
[edit interfaces fxp0]
lab@Chicago# show
speed 100m;
By default, the management interface autonegotiates the link mode. In other words, it will adapt to the link mode of the device at the
other end of the wire, be it full- or half-duplex. As was the case with link speed, some vendor products do not readily adapt to the
autonegotiation of link mode. Therefore, to configure either full- or half-duplex mode explicitly, use the set link-mode command at
the [edit interfaces fxp0] hierarchy level. The example below shows how to set the link mode to full-duplex:
[edit interfaces fxp0]
lab@Chicago# set link-mode full-duplex
[edit interfaces fxp0]
lab@Chicago# show
speed 100m;
link-mode full-duplex;
It is possible to include a relevant description of the interface using the set description command under the [edit
interfaces fxp0] hierarchy level. Any description added is visible using the show interfaces command, but will have no
impact on the functionality or the performance of the fxp0 interface. In other words, it will be treated as a comment on the interface. If

Downloader demo watermarks

the description contains spaces, then it must be enclosed in quotation marks. The following example shows how to set the description
"Management link to London" on the management interface.
[edit interfaces fxp0]
lab@Chicago# set description “Management link to London”
[edit interfaces fxp0]

152
 5. Router Access and System Administration
lab@Chicago# show
speed 100m;
link-mode full-duplex;
description “Management link to London”;
By default, the router's management Ethernet interface (fxp0) uses the MAC address that is hard-coded into its Ethernet card. To see
this address, use the show chassis mac-address operational-mode command. To change the management Ethernet interface's
MAC address, use the set mac command at the [edit interfaces fxp0] hierarchy level. When a MAC address is added, it
must be in one of the two following hexadecimal formats: 00:99:88:77:66:55 or 00.99.88.77.66.55. In the configuration
sample below, the default MAC address, which is burned into the NIC of fxp0, is being overridden and set to 12:d4:23:5a:aa:87.
[edit interfaces fxp0]
lab@Chicago# set mac 12:d4:23:5a:aa:87
[edit interfaces fxp0]
lab@Chicago# show
description “Management link to London”;
speed 100m;
link-mode full-duplex;
mac 12:d4:23:5a:aa:87;
The output from the show command above is cumulative in that it gives us the settings for all the changes made in this section.

Logical Characteristics
For a physical interface to function, at least one logical interface must be configured. All Juniper Networks fast-Ethernet interfaces
support multiple logical interfaces; with fxp0, however, normally only one is used (unless VLAN tagging has been enabled). The
following configuration sample contains the statement unit 0. This identifies logical interface 0. All settings that precede the unit
number are pertinent to the physical interface and will therefore affect all logical interfaces. All settings that follow the unit number are
pertinent only to the logical interface specified by the unit number. The commands relevant to fxp0, our management connection, are
described in the paragraphs below.

www.ebook-converter.com
Each logical interface can have multiple protocol families and must have at least one protocol family configured. The management
interface will normally be configured with the inet family, as is shown in the following configuration sample. The inet family is the
IP protocol stack and includes the major routing protocols, OSPF, BGP, and Routing Information Protocol (RIP), as well as Internet
Control Message Protocol (ICMP) messages. To configure the inet family, include the set family command at the [edit
interface fxp0 unit <unit #>] hierarchy level. Other protocol families available include iso—which is needed for running
the IS-IS protocol, and mpls—which is needed to configure MPLS across an interface. The option of configuring protocol families
other than inet exists; however, this option is rarely used. Under normal situations, only TCP/IP protocols are utilized across the
management LAN. In the following example, the help feature is used to view valid command completions when adding a protocol
family to an interface. After viewing the valid options, family inet is chosen to allow IP protocols traffic across logical interface 0
for physical interface fxp0.
[edit interfaces fxp0 unit 0]
lab@Chicago# set family ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
> inet Internet protocol (IPv4) parameters
> inet6 IPv6 protocol parameters
> iso OSI ISO protocol parameters
> mpls MPLS protocol parameters
[edit interfaces fxp0 unit 0]

Downloader demo watermarks

lab@Chicago# set family inet

[edit interfaces fxp0 unit 0]

lab@Chicago# show
family inet;
After the protocol family has been identified, it is necessary to specify an address for the interface. For the inet family, we will use an
153
 5. Router Access and System Administration
IP address and subnet mask (if no subnet mask is specified, JUNOS software will default to /32).

Note
If the IS-IS protocol were being used across the management LAN, then it would be necessary to configure the iso family
and specify a network entity title (NET) for the node address.
To specify an address, use the set address <address/subnet mask> command at the [edit interfaces fxp0 unit
<unit #> family <protocol>] level of the JUNOS hierarchy. In the configuration sample below, we have set an IP address of
192.168.151.10 with a 24-bit subnet mask:
[edit interfaces fxp0]
lab@Chicago# set unit 0 family inet address 192.168.151.10/24
The following example shows the settings for all the changes made in this section.
[edit interfaces fxp0]
lab@Chicago# show
description “Management link to London”;
speed 100m;
link-mode full-duplex;
mac 12:d4:23:5a:aa:87;
unit 0 {
family inet {
address 192.168.151.10/24;
}
}

System Administration
System administration can be interpreted to encompass a very broad range of activities. For the purposes of this chapter, we will focus
primarily on the elements of system administration that are typically in the hands of a network engineer and involve securing the router

www.ebook-converter.com
from unauthorized access while providing convenient access to individuals responsible for managing the functions of the device.
Unauthorized access can take one of two forms. The first form is the least common but, because of Hollywood, most glamorized and is a
situation in which an unauthorized user gains access to the router. The more common and less-dramatized form of unauthorized access
is any situation in which an authorized user executes configuration statements beyond his ability or job description.

User Account Setup

User accounts in the Juniper Networks world are handled in a very similar manner to the UNIX strategy of assigning groups and
usernames. The terminology is slightly different, but the concept is essentially the same. Login classes are defined and configured first.
Each login class will have a predetermined set of permissions and restrictions assigned to it. After the classes are built, each individual
user is assigned to a class. In this way the system administrator's job is made easier as it is not necessary to build a unique set of
permissions and restrictions for every single user. When new employees are hired or new users added, they will more than likely fit into
one of the existing login classes.
All usernames configured on a Juniper Networks M-Series router must be in a single login class. JUNOS allows only one login class per
user, but multiple users can be assigned to each login class. As was mentioned in the previous paragraph, the login class is associated
with a set of permissions and restrictions that control the commands that are accessible to the users assigned to the class. Login classes
also permit the administrator to define how long a session can be idle before it times out and the user is logged off.
The steps for creating a login class are as follows:
Downloader demo watermarks
1. Define a login class.
2. Assign an idle-timeout interval.
3. Assign access privilege levels.

154
 5. Router Access and System Administration
4. Set Allow and Deny commands.
The following sections describe these steps.

Defining a Login Class

From an administrative perspective, the sensible thing to do is to look at the roles and responsibilities of the people who will be
accessing the router, determine which commands each user should be able to execute, then build login classes accordingly. After
creating the classes, you would then apply a login class to an individual user account. JUNOS contains four predefined login classes,
which cannot be modified. Table 5-1 lists the classes along with the permissions assigned to them.
Table 5-1. Predefined Login Classes
Login ClassesPermissions
operator Access to a limited set of commands, including clear, set, and view; no access to configuration mode
read-only Access to show, test, set cli, and file commands only; no access to configuration mode
super-user Access to all commands, including root access
unauthorized No access to any commands
Operators are unable to access configuration mode. They are able to issue show, set, test, and clear commands. They are also
able to issue a specific group of set cli commands that allow them to change the appearance of the CLI temporarily.
Members of the read-only login class are unable to access the configuration mode. They are only able to issue commands used to
view routing-table and chassis-environment-related processes.
Super-users have access to all commands, including the power to launch a UNIX shell. Membership in this login class is comparable
to having root access.
Members of the unauthorized class do not have access to any commands. The unauthorized login class is typically used in
conjunction with the syslog function in situations where an administrator does not want to allow a user to do anything on the
router, but wants to track the user's attempts. Logging operations will be discussed later in this chapter.

www.ebook-converter.com
Keywords are used to represent a specific command or group of commands that can be typed at the CLI. The keywords can be used to
create custom login classes for users with special access needs. When creating custom login classes, it is possible to configure access-
privilege levels using keywords. Individual commands can be explicitly denied or allowed within those access privilege levels, and the
timeout value for idle sessions can be configured. The configuration sample below shows the syntax of the options available for creating
a login class:
[edit]
lab@Chicago# set system login class bigdogs ?
Possible completions:
<[Enter]> Execute this command
allow-commands Regular expression for commands to allow explicitly
+ apply-groups Groups from which to inherit configuration data
deny-commands Regular expression for commands to deny explicitly
idle-timeout Maximum idle time before logout (minutes)
+ permissions Set of permitted operation categories
To define a login class (give it a name), use the set class command. The configuration sample below shows the definition of a login
class bigdogs:
[edit system login]
lab@Chicago# set class bigdogs

Downloader demo watermarks

[edit system login]
lab@Chicago# show
class bigdogs;

Assigning an idle-timeout Interval

155
 5. Router Access and System Administration
After a login class has been defined, it can be assigned an idle-timeout interval, the amount of time in minutes in which the system
will tolerate a lack of input from the keyboard. The default idle-timeout interval is eternity; a login session remains established
until a user manually logs out of the router. To configure an idle-time limit for a login class, include the set idle-timeout
command. The sample below shows the idle-timeout interval set to 30 minutes for bigdogs.
[edit system login]
lab@Chicago# edit class bigdogs
[edit system login class bigdogs]
lab@Chicago# set idle-timeout ?
Possible completions:
<idle-timeout> Maximum idle time before logout (minutes)
[edit system login class bigdogs]
lab@Chicago# set idle-timeout 30
[edit system login class bigdogs]
lab@Chicago# show
idle-timeout 30;
If a timeout value is configured and the user exceeds the inactivity period, JUNOS generates the following sequence of messages before
timing out the idle user. The following messages were pulled from a session that was timed out due to inactivity:
lab@Chicago# Session will be closed in 5 minutes if there is no activity

Warning: session will be closed in 1 minute if there is no activity

Warning: session will be closed in 10 seconds if there is no activity
Idle timeout exceeded: closing session
Chicago (ttyd0

www.ebook-converter.com
login:
Operational-mode monitor commands are a way to watch a protocol, view traffic crossing an interface, or track a log file as it is being
built. If the user is running an operational-mode monitor command, such as monitor traffic or monitor interfaces, the
session is immune to the normal idle-timeout rules. This allows users to launch and watch the output from the monitor commands
without having to type anything to keep the session alive.

Note
When a user is logged out due to inactivity, any uncommitted changes he or she has made are neither lost, nor committed. The
changes are kept as part of the JUNOS candidate configuration and can be manipulated by any subsequent user.

Assigning Access-Privilege Levels

After the login class has been named, it is necessary to assign the access-privilege levels that should be associated with it. To assign an
access-privilege level, use the set permissions command at the [edit system login class <classname>] level of the
JUNOS hierarchy. Proper usage of the set permissions command is shown in the configuration sample below. In this example,
login class bigdogs is being given access to all commands and functions within JUNOS.

Downloader demo watermarks

[edit system login class bigdogs]
lab@Chicago# set permissions all
[edit system login class bigdogs]
lab@Chicago# show
idle-timeout 30;
permissions all;

156
 5. Router Access and System Administration
When specifying permissions, use the keywords from the list below. Each of these keywords has a set of commands associated with it.
It is important to remember that the permissions keywords are not cumulative. In other words, if a user is assigned permissions that
allow him to change the configuration at the interfaces level of the JUNOS hierarchy, he most also be given the ability to enter the
configuration mode to get there. For each class, be sure to include all functions needed. New administrators commonly make the
mistake of leaving out essential functions like configure to enter configuration mode and view to display chunks of the
configuration. Type a question mark to view all command completion options. The result generates both a list of the keywords and a
brief description of each, as is shown in the CLI output below:
[edit system login class bigdogs]
lab@Chicago# set permissions ?
Possible completions:
[ Open a set of values
admin Can view user accounts
admin-control Can modify user accounts
all All permission bits turned on
clear Can clear learned network information
configure Can enter configuration mode
control Can modify any configuration values
edit Can edit full files
field Special for field (debug) support
firewall Can view firewall configuration
firewall-control Can modify firewall configuration
floppy Can read and write the floppy drive
interface Can view interface configuration
interface-control Can modify interface configuration
maintenance Can perform system maintenance (as wheel)
network Can access the network
reset Can reset and restart interfaces and processes
rollback Can rollback for depth greater than zero
routing Can view routing configuration
routing-control Can modify routing configuration
secret Can view secret configuration

www.ebook-converter.com
secret-control Can modify secret configuration
security Can view security configuration
security-control Can modify security configuration
shell Can start a local shell
snmp Can view SNMP configuration
snmp-control Can modify SNMP configuration
system Can view system configuration
system-control Can modify system configuration
trace Can view trace file settings
trace-control Can modify trace file settings
view Can view current values and statistics

Setting allow-commands and deny-commands

In some cases, after defining the login class and setting the permissions, it is necessary to explicitly deny or allow commands within the
predefined access-privilege level. This can be accomplished using the allow-commands or the deny-commands statement. To deny
a command that would otherwise be permitted by the permissions keywords, include the set deny-commands <commands to
be denied> command at the [edit system login class <class-name>] level in the JUNOS hierarchy. To allow
commands that would otherwise be denied by the permissions keywords, use set allow-commands.
[edit system login class bigdogs]

Downloader demo watermarks

lab@Chicago# set deny-commands ?
Possible completions:
<deny-commands> Regular expression for commands to deny explicitly
JUNOS allows the inclusion of only one deny-commands and only one allow-commands statement for each defined login class. If
it is necessary to have multiple commands listed in either the allow or deny category, then it is possible to use what is known as a
regular expression to build the configuration. Regular expressions contain wild cards, known as operators, that have special meaning
157
 5. Router Access and System Administration
when used within this command context. The most frequently used operator is | (the pipe). It is used to separate multiple commands
within a single allow-commands or deny-commands statement. Table 5-2 identifies | and other regular expression operators.
Table 5-2. Regular Expression Operators

Logical
Description
Operator
- This character is always placed at the beginning of an expression. It is used to indicate where the command must begin and is
used in situations where there could be multiple valid commands with the same beginning word that are executable at
different hierarchical levels within the configuration.
| This character is used to separate multiple commands within an allow-commands or deny-commands statement. It
functions as a logical OR.
[] These characters are used to indicate a range of letters or digits and are commonly used when it is necessary to restrict show
commands to a certain group.
() These characters indicate hierarchy within a regular expression. The commands they surround are to be evaluated first. The
result is then evaluated as part of the overall expression.
$ This character is always applied at the end of a command and is used to indicate the need for an exact match that stops at the
point of the $. For example, allow-commands "show interfaces $" means that the user cannot issue show
interfaces brief or show interfaces detail.
The configuration fragment below demonstrates the use of the | operator within a regular expression that is being used for the allow-
commands. The login class that is defined in the sample below would be appropriate for employees responsible for software
maintenance on the Juniper Networks router. The permissions settings deny access to all commands except show, but the allow-
commands setting explicitly permits the user to upgrade software. Remember that in order for a software update to take effect, the
router must be rebooted.
[edit system login class admin-trainee]
lab@Chicago# set permissions view
[edit system login class admin-trainee]
lab@Chicago# set allow-commands “request system software add | request system
reboot”

www.ebook-converter.com
[edit system login class admin-trainee]
lab@Chicago# show
permissions view;
allow-commands “request system software add | request system reboot”;
The next example shows the layout of a login class that will give all users assigned to it the normal administrative assistant privileges as
defined by keywords clear, network, reset, trace, and view, plus the ability to reboot or halt the router as needed:
[edit system login class orin-admin]
lab@Chicago# set permissions [clear network reset trace view]

[edit system login class orin-admin]

lab@Chicago# set allow-commands “request system halt | request system reboot”
[edit system login class orin-admin]
lab@Chicago# show
permissions [ clear network reset trace view ];
allow-commands “request system halt | request system reboot”;
The login class that is defined in the sample below has some administrative assistant privileges, but is explicitly denied the usage of any

Downloader demo watermarks

commands that begin with set, clear, or delete:
[edit system login class russell-admin]
lab@Chicago# set permissions [network reset trace view]
[edit system login class russell-admin]
lab@Chicago# set deny-commands “^set|^delete|^clear”
158
 5. Router Access and System Administration
[edit system login class russell-admin]
lab@Chicago# show
permissions [ network reset trace view ];
deny-commands “^set|^delete|^clear”;

Defining User Accounts

After the login classes have been completed, it is necessary to define a user account for each user that will be accessing the router. For
each of the accounts, the administrator should define a unique login name for the user. In versions of JUNOS up to and including 4.4,
the username is limited to eight characters. After JUNOS 5.0, the username is limited to 16 characters. There are also options available
for adding more detailed information to help identify the user. The options available are shown in the following example:
[edit system login user gsondere]
lab@Chicago# set ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
> authentication Authentication method
class Login class
full-name Full name
uid User identifier (uid) (100..64000)

Note
As soon as the account has been built and the configuration committed, JUNOS constructs a home directory for the user. The
home directory is located under /var/home/<username> in the UNIX directory structure.

Specifying a Login Class

The configuration example below shows how to specify a login class for a user. This configuration point is not optional. Executing this
specific command will both define the user's login name and identify a class to be associated with the user. See Section 5.2.1.1 for a

www.ebook-converter.com
complete description of the login-class concept.
[edit system login]
lab@Chicago# set user gsondere class admin-trainee

[edit system login]

lab@Chicago# edit user gsondere
[edit system login user gsondere]
lab@Chicago# show
class admin-trainee;
Once a username has been specified, adding the user's full name to the user configuration is a handy option. If the full name contains
spaces then it must be enclosed in quotation marks as is shown in the command string below:
[edit system login user gsondere]
lab@Chicago# set full-name “Gordon Sonderegger”

[edit system login user gsondere]

lab@Chicago# show
full-name “Gordon Sonderegger”;

Downloader demo watermarks

class admin-trainee;

Setting the User Identifier

The user identifier (UID) is an optional attribute that can be added to the user's configuration. It is used for tracking user activity by
some processes in JUNOS software and is a simple numeric identifier associated with the username. The identifier must fall within the

159
 5. Router Access and System Administration
range of 1,000 to 64,000 and must be unique within the router. If no UID is assigned to a username, JUNOS assigns one when the
configuration is successfully committed. The sample below shows the addition of a valid UID to the configuration for user gsondere.
[edit system login user gsondere ]
lab@Chicago# set uid 1001
[edit system login user gsondere]
lab@Chicago# show
full-name “Gordon Sonderegger”;
uid 1001;
class admin-trainee;

Setting Local Authentication

Setting local authentication is optional, and if it is not specified, then the user will not be prompted for a password when entering the
router. The authors recommend that every user have some form of authentication configured. There are several authentication options
available, including plain-text password and encrypted password. The plain-text-password option assumes that the user will be typing in
a password that will need to be put through the Message Digest 5 (MD5) encryption algorithm before being placed into the
configuration. The encrypted-password option assumes that the user will paste in a password that has already been put through the MD5
algorithm. In either case the configuration will always show the password as an encrypted password and will never contain an account
password in a plain-text format. For each method, specify the user's password. If the plain-text-password option is used, then the
password must be typed in twice, exactly the same way, to allow the operating system to confirm it. In the sample below, a plain-text
password is being set for user gsondere:
[edit system login user gsondere]
lab@Chicago# set authentication plain-text-password
New password: <password>
Retype new password: <retype password>
After password authentication has been added, it will appear in the user's configuration as shown in the sample below. Notice that the
password has been encrypted and is identified by the software as such.

www.ebook-converter.com
[edit system login user gsondere]
lab@Chicago# show
full-name “Gordon Sonderegger”;
uid 1001;
class superuser;
authentication {
encrypted-password “$1$oA5MLkba$g6j.laUNOl8EV2kK1QjXK0”; # SECRET-DATA
}
An account for the user root is by default built into the configuration and by default has no password. However, it is highly
recommended that one immediately set up password protection for the root account. The password for account root is configured using
the root-authentication statement at the [edit system] hierarchy level. This is a critical task in the responsibilities of a
system administrator and should not be overlooked.
[edit system]
lab@Chicago# set root-authentication plain-text-password
New password:
Retype new password:

[edit system]
lab@Chicago# show

Downloader demo watermarks

host-name Chicago;
root-authentication {

}
encrypted-password “$1$ccZHntfP$TcMEHnZp04/FfpVYJbnPX/”; # SECRET-DATA

login {
class admin-trainee {
permissions view;
160
 5. Router Access and System Administration
allow-commands “request system software add | request system reboot”;
}
class bigdogs {
idle-timeout 30;
permissions all;
}
class orin-admin {
permissions [ clear network reset trace view ];
allow-commands “request system halt | request system reboot”;
}
class russell-admin {
permissions [ network reset trace view ];
deny-commands “^set|^delete|^clear”;
}
user gsondere {
full-name “Gordon Sonderegger”;
uid 1001;
class admin-trainee;
}
}
In the configuration samples below, four user accounts are shown. For each of the users, a full name was added for clarity. The first two
users were given a password using the plain-text option. The third was given a password using the encrypted option. These samples
demonstrate some of the settings combinations available when adding users to the system.
[edit system login]
lab@Chicago# show
user branimir {
full-name “Branimir Maric”;
uid 1001;
class superuser;
authentication {
encrypted-password “awertcawexwer54gfwe”; # SECRET-DATA

www.ebook-converter.com
}
}
user mario {
full-name “Mario Jurcevic”;
uid 1002;
class admin-trainee;
authentication {
encrypted-password “786fvo8jo7674cd6u744*%&vo”; # SECRET-DATA
}
}
user drazen{
full-name “Drazen Kedmenec”;
uid 1003;
class admin-trainee;
authentication {
encrypted-password “iuycrbqewrts123654vuqwuq” # SECRET-DATA
}
}
user ladislov {
full-name “Ladislov Topic”;

}Downloader demo watermarks

uid 1004;
class unauthorized;

As was mentioned previously, the unauthorized login class may seem ridiculous at first. Why would an administrator want to build an
account for a user and then give him no permissions? In truth, there could be several valid reasons for adding this configuration element.
First, there may be future plans for allowing the user to execute commands on the router, at which time the user's login class will be

161
 5. Router Access and System Administration
updated to reflect the new responsibilities. A second possible reason could be a system administrator's desire to see what the user will
attempt to access. This could be tracked by turning on the logging features that are built into JUNOS. Logging features are described in
Section 5.2.8.

Password Recovery
Regardless of the ability and experience of the system administrator, organizational changes can sometimes make password recovery a
necessity. For those who have never encountered the term, password recovery is a means of gaining access to a router when a valid
password is unknown. Obviously, having a built-in back door such as this puts the entire network at risk for a security breach.
Therefore, measures must be taken to secure the Juniper Networks router from this type of unauthorized access. The measures should
include placing all critical network devices behind a locked door. This simple measure is an often-overlooked administrative duty.
Having explained the need for locked-door security, we present the steps below. They describe one possible method of gaining access to
the router without a valid password. These steps should only be used as a last resort and certainly at off-peak times in a production
network as they do require a reboot of the router.
1. First, obtain physical access to the router. This procedure cannot be completed through a remote-access connection as it requires
both a connection to the console port and a physical reboot of the router.
2. Next, power-cycle the router and boot it up in single-user mode by typing -s at the boot: prompt as is shown below:
Will try to boot from :
PCMCIA ATA Flash Card
Compact Flash
Primary IDE Hard Disk
Ethernet
Boot Sequence is reset due to Powerup

Trying to boot from PCMCIA ATA Flash Card

Trying to boot from Compact Flash

NO /boot/loader
>>FreeBSD i386 boot

www.ebook-converter.com
Default: 0:ad(0,a)/kernel
boot: -s

3. The router will go through its usual startup sequence. Then, there will be a prompt for pathname with the following syntax: Enter
pathname of shell or RETURN for sh:
4. When this prompt is seen, enter the following string: /usr/libexec/ui/recovery-mode
5. This will drill down through the directory structure and execute a premade script for password recovery. The system will continue
to boot as normal and bring the user to the following prompt: root@Chicago>.
6. At this point it will be possible to drop into configuration mode using the edit command. From there, one can make changes to
usernames and passwords as needed.
In the configuration sample below user jsclass is an administrator and has forgotten his password. He followed the steps listed above
to gain access to the CLI as root. He will now delete and rebuild his username, making sure to add a more memorable password.
root@Chicago> edit
Entering configuration mode
[edit]

Downloader demo watermarks

root@Chicago# delete system login user jsclass

[edit]
root@Chicago# set system login user jsclass class superuser authentication plain-text-password
New password:
Retype new password:
Once the changes are complete, it is necessary to commit. Once the commit completes, a request system reboot command is
162
 5. Router Access and System Administration
necessary to get out of single-user mode. The sample below shows execution of the reboot command:
[edit]
root@Chicago# commit
Commit complete
root@Chicago# exit
Exiting Configuration mode

root@Chicago> request system reboot

Reboot the system ? [yes,no] (no) yes
Following the reboot, it is possible to login as needed, using the new password.

Note
Juniper Networks' Technical Documentation Set version 5.1 includes a few other steps as part of the password-recovery
process. These steps involve manually mounting specific software processes while in the UNIX shell. Once started, these
processes will permit the M-Series router to forward traffic while the password-recovery steps are being executed. For a
complete list of the processes to be mounted, see Juniper Networks' Technical Documentation Set.

Authentication Methods
RADIUS and Terminal Access Controller Access Control System + (TACACS+) are authentication methods that rely on network
connectivity as opposed to local machine login/password authentication. The Juniper Networks router can be configured to authenticate
access attempts through Telnet using RADIUS or TACACS+, or both. In situations where both have been configured, it is also possible
to specify which method to try first. NTP should also be configured for either of the authentication methods to work. Both TACACS+
and RADIUS rely on a timestamp to keep people from sniffing packets and using them again to gain access, so if the clocks are not
synchronized, then authorization will fail. NTP configuration is described in detail in Section 5.2.9. The following sections introduce a
bit of operational theory for the two authentication methods and then the statements that will be used to configure each on the router.

RADIUS

www.ebook-converter.com
RADIUS uses the transport protocol UDP to move requests for access from the Juniper Networks router to the RADIUS server for
authentication. The password keyed in by the user is included in the request. At the RADIUS server, the password is checked against
the database to determine the legitimacy of the login attempt. If the username and password are valid according to the RADIUS server,
then access to the router is granted. If the username or password is invalid, then access to the router is not granted, and a denial message
is returned to the user. The paragraphs that follow include examples and descriptions of the commands used to configure RADIUS
authentication on the Juniper Networks M-Series routers.
RADIUS authentication is enabled on the router by configuring the location of a RADIUS server. To do this, use the radius-server
statement at the [edit system] hierarchy level. In the example below, the RADIUS server is located at IP address
192.168.100.1. For the sake of clarity, only output pertinent to the RADIUS configuration is listed under the show command
below:
[edit system]
lab@Chicago# set radius-server 192.168.100.1
[edit system]
lab@Chicago# show
radius-server {
192.168.100.1;

Downloader demo watermarks

}
As is specified in RFC 2138, when a RADIUS server is contacted, port 1812 is used for the connection. It is possible to override this
default by using the set port <port#> command at the [edit system radius-server <address>] hierarchy level in
the configuration. In the example below, the default port number is overridden and set to 1492, although in most situations such a
change is not necessary:

163
 5. Router Access and System Administration
[edit system radius-server 192.168.100.1]
lab@Chicago# set port 1492
[edit system radius-server 192.168.100.1]
lab@Chicago# show
192.168.100.1 port 1492;
For RADIUS authentication to function, it is necessary to specify a password that the Juniper Networks router can pass to the RADIUS
server. This is used to confirm the identity of the device that is requesting authentication of a potential user. The password must be
configured on both the router and the RADIUS server. On the router it is configured using the secret statement at the [edit
system radius-server <address>] hierarchy level. In the configuration sample below, we used Gabby as the password for
RADIUS-client authentication.
[edit system radius-server 192.168.100.1]
lab@Chicago# set secret gabby
As is shown in the configuration sample below, when the show command is used to view the password, the password has been
encrypted within the configuration:
[edit system radius-server 192.168.100.1]
lab@Chicago# show
192.168.100.1 {
port 1492;
secret “$9$kP5Fn6Au0IUjBE”; # SECRET-DATA
}
It is also possible to configure RADIUS to attempt to authenticate users multiple times. This is accomplished by using the set retry
command as shown below. In this example, the RADIUS server will attempt to authenticate the identity of the user three times.
[edit system radius-server 192.168.100.1 {
lab@Chicago# set retry 3

[edit system radius-server 192.168.100.1]

www.ebook-converter.com
lab@Chicago# show
192.168.100.1 {
port 1492;
secret “$9$kP5Fn6Au0IUjBE”; # SECRET-DATA
retry 3;
}
In some situations it may also be necessary to configure a higher timeout interval. By default, the router will wait three seconds for a
response from the server. Changing the default would be necessary in situations where network latency is expected or when there will
be a high number of users attempting to authenticate through the same server simultaneously. This situation is commonly experienced in
most businesses at around 8:00 A.M. every morning. The timeout interval is set using the set timeout command as is shown below.
In this example, there will be three attempts at authentication, each with a timeout interval of 90 seconds.
[edit system radius-server 192.168.100.1]
lab@Chicago# set timeout 90

[edit system radius-server 192.168.100.1]

lab@Chicago# show
192.168.100.1 {
port 1492;

Downloader demo watermarks

secret “$9$kP5Fn6Au0IUjBE”; # SECRET-DATA
timeout 90;
retry 3;
}

Juniper Networks–Specific RADIUS

164
 5. Router Access and System Administration
The Juniper Networks implementation of RADIUS supports some unique attributes. These are known as vendor-specific attributes
(VSAs) and are loosely described in RFC 2138. Juniper Networks VSAs are identified by vendor ID 2636 in the packets sent to the
RADIUS server. This is the vendor ID assigned to Juniper Networks, Inc. The following attributes are unique to Juniper Networks:
juniper-allow-commands: This attribute allows the RADIUS server to be aware of the explicitly configured allow-
commands connected to the login class to which the user belongs. Without this attribute, only the configured permission keywords
would be recognized.
juniper-deny-commands: This attribute allows the RADIUS server to be aware of the explicitly configured deny-commands
connected to the login class to which the user belongs. Without this attribute only the permission keywords would be recognized.
juniper-local-user-name: This attribute allows the RADIUS server to recognize shared user accounts.

Note
Because it uses UDP, RADIUS authentication has less overhead than TACACS+ and is therefore used more frequently in
high-traffic situations. This in no way implies that RADIUS authentication is less secure. It is simply based on a different
transport method.

TACACS+
TACACS+ uses a TCP connection for the transport of the encrypted password and access request. This method of authentication is
used less frequently in high-traffic situations as the TCP connection, by nature, has more overhead and burns up more bandwidth.
This section shows the commands used to configure TACACS+ authentication on Juniper Networks routers. In the first configuration
sample, we enable TACACS+ authentication by specifying the IP address of a TACACS+ server. In the following example, the server is
located at 192.168.100.2. For the sake of clarity, only output pertinent to the TACACS+ configuration is listed under the show
command.
[edit system]
lab@Chicago# set tacplus-server 192.168.100.2

www.ebook-converter.com
[edit system]
lab@Chicago# show
tacplus-server {
192.168.100.2;
}
As with RADIUS, with TACACS+ we must first specify a password to be sent to the server to authenticate the identity of the router that
is requesting authentication of a potential user. This step is necessary in order for TACACS+ authentication to function. We specify a
password using the secret statement as shown below. In this example, we use zappa as the password, but again, when the password
is viewed in the configuration, it is in an encrypted format:
[edit system tacplus-server 192.168.100.2]
lab@Chicago# set secret zappa
[edit system tacplus-server 192.168.100.2]
lab@Chicago# show
192.168.100.2 {
secret “$9$AJL/uEyleW8xdSreW”; # SECRET-DATA
}

Downloader demo watermarks

It is also possible to change the default timeout interval for connection attempts by the router to the TACACS+ server. The default
interval is three seconds. To change this interval, use the timeout statement at the [edit system tacplus-server
<address>] hierarchy level as is shown below. In this example, we anticipate some network delay and want to allow the TACACS+
server 45 seconds to respond to our authentication request. The maximum allowable limit for the timeout value is 90 seconds.
[edit system tacplus-server 192.168.100.2]
lab@Chicago# set timeout 45
165
 5. Router Access and System Administration
[edit system tacplus-server 192.168.100.2]
lab@Chicago# show
192.168.100.2 {
secret “$9$AJL/uEyleW8xdSreW”; # SECRET-DATA
timeout 45;
}
It is also possible to configure the router to order the server to permit only one open TCP connection for multiple requests. This reduces
the burden on bandwidth resources that would be caused by having an individual TCP connection open for every authentication
attempt. It is possible to configure the router to enforce the single-connection rule by using the set single-connection command
at the level of hierarchy shown below:
[edit system tacplus-server 192.168.100.2]
lab@Chicago# set single-connection

[edit system tacplus-server 192.168.100.2]

lab@Chicago# show
192.168.100.2 {
secret “$9$AJL/uEyleW8xdSreW”; # SECRET-DATA
timeout 45;
single-connection;
}
To configure multiple TACACS+ servers, simply include multiple set tacplus-server commands while at the [edit system]
hierarchy level as is shown in the configuration sample below. It really is just that simple. In this example, we want to configure three
authentication servers residing at addresses 192.168.100.1 through 192.168.100.3. All should be configured with the same
router authentication password, enforce a single TCP connection, and have a timeout value of 45 seconds. This is how it would be done
with minimal keystrokes:
[edit]
lab@Chicago# edit system tacplus-server 192.168.100.2

www.ebook-converter.com
[edit system tacplus-server 192.168.100.2]
lab@Chicago# set secret zappa

[edit system tacplus-server 192.168.100.2]

lab@Chicago# set timeout 45
[edit system tacplus-server 192.168.100.2]
lab@Chicago# set single-connection

[edit system tacplus-server 192.168.100.2]

lab@Chicago# up

[edit system tacplus-server]

lab@Chicago# copy 192.168.100.2 to 192.168.100.1
[edit system tacplus-server]
lab@Chicago# copy 192.168.100.2 to 192.168.100.3
[edit system tacplus-server]
lab@Chicago# show
192.168.100.2 {

}
Downloader demo watermarks
secret “$9$.fnCtpB1godEy9ApB”; # SECRET-DATA
timeout 45;
single-connection;

192.168.100.1 {
secret “$9$.fnCtpB1godEy9ApB”; # SECRET-DATA
timeout 45;

166
 5. Router Access and System Administration
single-connection;
}
192.168.100.3 {
secret “$9$.fnCtpB1godEy9ApB”; # SECRET-DATA
timeout 45;
single-connection;
}

Shared User Accounts

When using JUNOS software for local authentication, it is a good idea to create a private account for every individual who will be
accessing the router. It is possible, however, to create only a small number of user accounts and allow many users to utilize them. Both
RADIUS and TACACS+ authentication methods support shared accounts. Once a shared account is configured, any user who knows
the password can make use of it. To create a shared user account, build the account as normal and name it remote. The remote account
is recognized by both RADIUS and TACACS+ as a shared user account, and either server will allow multiple users to authenticate
simultaneously using this account.
The sample below shows the remote user account. We have chosen to give it a user ID number of 5555. We have also used a custom
login class named custom-restricted. We gave the account a full name of Remote Access Shared Account as a reminder of what this
user account was designed for. Configuration of an account named remote does not automatically enable remote authentication. It is
still necessary to configure a reachable authentication server.
[edit system login user remote]
lab@Chicago# show
full-name “Remote Access Shared Account”;
uid 5555;
class custom-restricted;

Dynamic Host Configuration Protocol Relay

The Juniper Networks router can be configured to function as a Dynamic Host Configuration Protocol (DHCP) relay agent. What this

www.ebook-converter.com
means is that a local host can request DHCP information, such as an IP address, subnet mask, and default gateway, and if no DHCP
server resides on the local network, the router will forward the request to a preconfigured DHCP server on a different network or
subnet. It is only necessary to configure the router to be a DHCP relay agent if there are locally attached hosts that rely on DHCP
information from a remote server. If there are no local hosts that require DHCP information, then this configuration step is not
recommended by the authors and is definitely not necessary.
To configure the router to function as a DHCP relay agent, use the set server <ip-address of server> command at the
[edit system dhcp-relay] level of hierarchy. In the example below, the router has local hosts relying on a remote DHCP server
that is located at IP address 40.10.10.5:
[edit system dhcp-relay]
lab@Chicago# set server 40.10.10.5
[edit system dhcp-relay]
lab@Chicago# show
server 40.10.10.5;

Note
The Juniper Networks M-Series router, itself, cannot function as a DHCP server. It can only forward requests for DHCP
information.
Downloader demo watermarks
System Services
By default, the server functionality of common services that would permit remote access is disabled on the Juniper Networks router.
While the client side is enabled by default, the server functionality for Telnet, SSH, and FTP must be enabled under the [edit
system services] level of the JUNOS hierarchy. The following sections describe how to configure the server functionality of these
167
 5. Router Access and System Administration
services.

Note
Configuration of the management Ethernet (fxp0) connection is a prerequisite for functioning as a server for Telnet sessions,
SSH, or FTP across the management LAN.

Telnet
The Telnet service is the workhorse of the remote-access world. Through Telnet, it is possible to establish a connection to a device and
generate a screen that looks and functions as if the user had logged directly into the device. In the Juniper Networks world, and in most
other implementations, the Telnet service requires that the user issuing the Telnet request have a valid user account and password on the
target device.
The Telnet service is enabled using the set telnet command as shown below. Keep in mind that enabling Telnet does not open
Telnet sessions; it simply allows sessions to be opened as needed.
[edit system services]
lab@Chicago# set telnet
JUNOS software includes provisions that make it possible to limit the number of simultaneous Telnet connections and set a limit on the
number of connection attempts per minute. The configuration example below shows Telnet enabled with a maximum of three
simultaneous connections and a maximum of ten connection attempts per minute. In these examples, the help feature is used to see the
maximum allowable settings for both the number of simultaneous connections and the number of connection attempts per minute.
[edit system services telnet]
lab@Chicago# set connection-limit ?
Possible completions:
<connection-limit> Maximum number of allowed connections (1..250)

[edit system services telnet]

lab@Chicago# set connection-limit 3

www.ebook-converter.com
[edit system services telnet]
lab@Chicago# set rate-limit ?
Possible completions:
<rate-limit> Maximum number of connections per minute (1..250)

[edit system services telnet]

lab@Chicago# set rate-limit 10
[edit system services telnet]
lab@Chicago# show
connection-limit 3;
rate-limit 10;
After the Telnet service has been configured, it can be used to connect to other devices on which Telnet is also enabled. The syntax for
making a Telnet connection from a Juniper Networks router is shown on the following page. The command is launched from operational
mode or can be launched from configuration mode if the run command is used. This example shows Telnet being launched from
operational mode to connect to a router with an IP address of 192.168.151.3:
lab@Chicago> telnet 192.168.151.3
Trying 192.168.151.3...

Downloader demo watermarks

Connected to 192.168.151.3.
Escape character is '^]'.

Denver (ttyp0)
login:

168
 5. Router Access and System Administration
The string shown below demonstrates the telnet command being executed from within configuration mode, using the run command:
[edit protocols ospf area 0]
lab@Chicago# run telnet 192.168.161.27
Trying 192.168.161.27...
Connected to 192.168.161.27.
Escape character is '^]'.
Melbourne (ttyp0)

login: bonnie
Password:
Last login: Thu Mar 7 08:43:31 from 192.168.161.10

--- JUNOS 5.1R1.4 built 2001-11-01 19:09:34 UTC

bonnie@Melbourne>
The telnet command was successful and user bonnie was prompted for a username and password to access the Melbourne router.
User bonnie was able to establish this connection because her UID and password had already been configured on the Melbourne
router.

Note
The Juniper Networks implementation of Telnet does not permit Telnet connections to be established by user root. This is a
built in safety feature of the operating system.

SSH
SSH is capable of accomplishing most, if not all, of the tasks that up until a few years ago were traditionally carried out using Telnet.
Because of its encryption features, it is now in common use by both ISP and enterprise network engineers. However, due to U.S.
government restrictions on encryption software, the SSH service is available only on the domestic version of the software. The SSH

www.ebook-converter.com
service is used first to open a connection to a remote router, then to execute individual commands on the remote router. The service
must be running on both Juniper Networks devices involved in SSH communication. To start the SSH service on the Juniper Networks
router, use the set ssh command from the [edit system services] level of hierarchy as is shown in the sample below:
[edit system services]
lab@Chicago# set ssh
As with Telnet, with SSH it is also possible to limit the number of simultaneous SSH connections and set a limit on the number of
connection attempts per minute. The configuration example below shows SSH enabled with a maximum of five simultaneous
connections and a maximum of ten connection attempts per minute. The help function is used to demonstrate the allowable parameters
for these options:
[edit system services ssh]
lab@Chicago# set connection-limit ?
Possible completions:
<connection-limit> Maximum number of allowed connections (1..250)
[edit system services ssh]
lab@Chicago# set connection-limit 5

Downloader demo watermarks

[edit system services ssh]
lab@Chicago# set rate-limit ?
Possible completions:
<rate-limit> Maximum number of connections per minute (1..250)

[edit system services ssh]

lab@Chicago# set rate-limit 10

169
 5. Router Access and System Administration
[edit system services ssh]
lab@Chicago# show
connection-limit 5;
rate-limit 10;
After the SSH service has been configured, it can be used from operational mode to establish a connection with another device and run
commands on the device. To establish a connection with a Juniper Networks M-Series router with an IP address of 192.168.161.17
and then run a show chassis hardware command, use the following syntax:
lab@Chicago> ssh 192.168.161.17
RSA key fingerprint is 7d:c7:5c:26:2d:90:12:fe:76:6b:35:3c:ca:b2:87:ea.
Are you sure you want to continue connecting (yes/no)? yes
[email protected]'s password:
Last login: Sun Mar 31 20:38:50 2002
--- JUNOS 5.2R1.4 built 2002-01-30 17:03:27 UTC
---
--- NOTICE: System is running on alternate media device (/dev/ad1s1a).
---
lab@HongKong> show chassis hardware
Hardware inventory:
Item Version Part number Serial number Description
Chassis 21009 M20
Backplane REV 07 710-001517 AB7116
Power Supply A REV 03 740-001465 001221 AC
Power Supply B REV 03 740-001465 001214 AC
Display REV 04 710-001519 AF3244
Host 0 dd00000792cf3401 teknor
SSB slot 0 REV 01 710-001951 AF1358 Internet Processor II
SSB slot 1 N/A N/A N/A backup
FPC 1 REV 01 710-001292 AC5929
PIC 1 REV 07 750-002303 AF7216 4x F/E, 100 BASE-TX
PIC 2 REV 03 750-000603 AA4506 4x OC-3 SONET, SMIR
PIC 3 REV 04 750-000611 AA4272 4x OC-3 SONET, MM

www.ebook-converter.com
FPC 2 REV 01 710-001292 AF3526
PIC 1 REV 06 750-000616 AA6698 1x OC-12 ATM, MM
FPC 3 REV 01 710-001292 AB2174
PIC 0 REV 08 750-001072 AG4470 1x G/E, 1000 BASE-SX
PIC 1 REV 08 750-001072 AC4777 1x G/E, 1000 BASE-SX

lab@HongKong>
The command string below shows user lab closing his SSH session to the Hong Kong router and returning to the Chicago CLI:
lab@HongKong> exit

Connection to 192.168.161.17 closed.

[edit]
lab@Chicago#

FTP
JUNOS also contains provisions that allow FTP to be enabled. FTP, for those unfamiliar with the protocol, does exactly what the name

Downloader demo watermarks

implies: It gives the ability to copy files efficiently from file system locations on one device to file system locations on another device
over an IP network connection. FTP uses TCP ports 20 and 21 to make the transfer. In order for FTP to function, it must be enabled on
both Juniper Networks devices involved in the transfer. The syntax for enabling FTP on a Juniper Networks M-Series router is
comparable to what we have seen for Telnet and SSH.
[edit system services]
lab@Chicago# set ftp
170
 5. Router Access and System Administration
[edit system services]
lab@Chicago# show
ftp;
As with the other services, limitations on the number of simultaneous connections and number of connection attempts can be placed on
FTP. The configuration sample below shows FTP enabled with a maximum of one connection and a maximum of five connection
attempts per minute. Again, the help feature is used to display the maximum allowable parameters for these options.
[edit system services ftp]
lab@Chicago# set connection-limit ?
Possible completions:
<connection-limit> Maximum number of allowed connections (1..250)

[edit system services ftp]

lab@Chicago# set connection-limit 1
[edit system services ftp]
lab@Chicago# set rate-limit ?
Possible completions:
<rate-limit> Maximum number of connections per minute (1..250)
[edit system services ftp]
lab@Chicago# set rate-limit 5

[edit system services ftp]

lab@Chicago# show
connection-limit 1;
rate-limit 5;
Enabling the FTP service does not open any FTP connections. To establish an FTP connection, it is necessary to launch an FTP session.
Once an FTP session is launched, the Juniper Networks implementation supports the full range of standard FTP commands, as well as
all FreeBSD UNIX commands. An FTP session is launched either from operational mode or from a UNIX shell. The syntax for

www.ebook-converter.com
launching FTP from a shell is shown next:
lab@Chicago> startshell
%ftp 192.168.161.14
Connected to 192.168.161.17.
220 HongKong FTP server (Version 6.00LS) ready.
Name (192.168.161.17:lab):
331 Password required for lab.
Password:
230 User lab logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
In the command string below, a file called baseline is being pulled through FTP from the Hong Kong router back to the Chicago
router. This file will be placed in the /var/home/lab directory under the filename baseline on the Chicago router.
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for '/bin/ls'.

Downloader demo watermarks

total 54
drwxr-xr-x 2 lab staff 512 Mar 21 15:40 .ssh
-rw-r---r--- 1 lab staff 5295 Mar 24 19:43 L2_vpn
-rw-r---r--- 1 lab staff 4806 Mar 24 13:13 L3_vpn
-rw-r---r--- 1 lab staff 1110 Mar 21 15:44 baseline
-rw-r---r--- 1 lab staff 3588 Mar 22 20:26 bgp_core
-rw-r---r--- 1 lab staff 5238 Mar 25 18:40 inter_prov_vpn

171
 5. Router Access and System Administration
-rw-r---r--- 1 lab staff 2427 Mar 22 15:42 interfaces
226 Transfer complete.
ftp> mget baseline
mget baseline?
200 PORT command successful.
150 Opening BINARY mode data connection for 'baseline' (1110 bytes).
100% 1110 00:00 ETA
226 Transfer complete.
1110 bytes received in 0.00 seconds (608.30 KB/s)
To end the FTP connection, use the bye command. This will return the cursor to a UNIX shell prompt. From within the UNIX shell, use
the exit command to get back to the CLI.
ftp> bye
221 Goodbye.
% exit

lab@Chicago>
While the protocol is useful in training-lab environments, Juniper Networks does not officially support FTP on the M-Series routers, and
it highly recommends that this service not be enabled on routers used in a production network. FTP is extremely useful in some
situations, such as when passing a new software release from router to router, but it could be exploited in negative ways. Because of its
encryption capabilities, a safer alternative to FTP is the Secure Copy Protocol (SCP).

SCP
SCP accomplishes the same functions as the FTP protocol, but operates through an SSH connection. Therefore, to run SCP, the SSH
service must be enabled on the router that is receiving the connection. See Section 5.2.7.2 for an explanation of how to configure SSH.
The example below shows the command string used to launch an SCP connection from the Chicago router to the Hong Kong router and
push a file called baseline from Chicago to Hong Kong. In this example, the Hong Kong router will function as an SSH server;
therefore, the SSH service must be enabled on Hong Kong.

www.ebook-converter.com
lab@Chicago> file list
.ssh/
baseline
jinstall-5.0R1.4-domestic.tgz
lab@Chicago> file copy baseline scp://192.168.161.17/var/home/lab/.
[email protected]'s password:
baseline 100% |*****************************| 1666 00:00
To confirm that the file has been copied to the Hong Kong router, we can establish an SSH connection and check the home directory of
user lab as is shown in the example below:
lab@Chicago> ssh 192.168.161.17
[email protected]'s password:
Last login: Sun Mar 31 20:40:43 2002 from 192.168.161.30
--- JUNOS 5.2R1.4 built 2002-01-30 17:03:27 UTC
---
--- NOTICE: System is running on alternate media device (/dev/ad1s1a).
---
lab@HongKong> file list

Downloader demo watermarks

.ssh/
baseline
ed-hongkong-032602
mplslab.conf
reset
rsvp.conf
venulab.conf
172
 5. Router Access and System Administration
lab@HongKong> exit

Connection to 192.168.161.17 closed.

lab@Chicago>

System Logging
System logging is a way to build files that store a record of activity within the router. This feature can track alarms, warning messages,
instances of users logging on and off, specific commands executed by users, and virtually any other event that takes place on the router.
System logging operations are enabled by default and record events that would be of importance to the system administrator, such as
component failure. System logging can be configured to catch more trivial events, such as execution of commands or user login
attempts.
To configure system-logging parameters and control how much information the system archives, use the set syslog <syslog
options> command at the [edit system] level of the JUNOS hierarchy as is shown in the example below. By default, the data
collected will be placed in 128K files. Up to ten of these files will be created as data is collected. Also by default, the only user who can
read the files is the user who created them, the root user, and users with a login class of super-user.
In the example below, some of the default syslog settings are overridden. The files option is used to specify the number of files, up to
five, to be used for the syslog data. The size option allows us to specify the maximum size, up to 5MB, for each of the syslog files. We
have designated these files as world-readable, which will permit all other users to view them.
[edit system syslog]
lab@Chicago# set archive files 5 size 5m world-readable

[edit system syslog]

lab@Chicago# show
archive size 5m files 5 world-readable;
The maximum allowable number of syslog files is 1,000. The minimum allowable syslog file size is 64K. The maximum size allowable

www.ebook-converter.com
per syslog file is 1GB. The syslog files will be stored in the /var/log/ directory.
Using CLI commands, it is also possible to create other files in which to store syslog information or to redirect syslog data to the console
port or even a specific host. Examples of these configurations are shown below:
[edit system syslog]
lab@Chicago# show
archive size 5m files 5 world-readable;
host 124.35.35.14 {
any emergency;
}
console {
any critical;
}
As was mentioned previously, it is possible to change the default class of messages (type of information being stored) and the severity
level within these classes. To change the class and severity level, it is necessary to use the keywords. The keyword options available are
listed in the command completion example below. This list shows the options for selecting a class of messages.
[edit system syslog]
lab@Chicago# set console ?

Downloader demo watermarks

Possible completions:
any
authorization
Matches any facility
The authorization system
change-log Configuration change log
cron The cron daemon
daemon Various system daemons
ftp The file transfer protocol daemon
173
 5. Router Access and System Administration
interactive-commands Commands executed by the UI
kernel Messages generated by the kernel
pfe Messages generated by the packet forwarding engine (PFE)
user Messages from random user processes
Table 5-3 gives a more detailed description of the different classes of messages available.
Table 5-3. Message Class for System Logging

Keyword Displays
any All events listed in the seven categories below
Authorization Any attempt to login to the router (successful or otherwise)
change-log Any changes made to the configuration (and committed)
cron Any cron daemon or scheduled task
daemon Any system daemon or background process
ftp Any messages that are generated by the FTP daemon
interactive-commandsAny command executed at the CLI
kernel Any message originating from the JUNOS kernel
pfe Any messages that the PFE generates
user Any message generated by a user process
Once a message class is determined, it is combined with a severity level to pinpoint the exact type of information to be stored in the
syslog files. Severity levels and their descriptions are shown in the command completion example below:
[edit system syslog]
lab@Chicago# set console any ?
Possible completions:
alert Conditions that should be corrected immediately
any Matches any level
critical Critical conditions
emergency Panic conditions

www.ebook-converter.com
error Error conditions
info Informational messages
notice Conditions that should be handled specially
warning Warning messages
Table 5-4 offers a more concise definition of the severity levels supported in descending order from most to least severe.
Using combinations of class and severity level, it is possible to gather the exact data sought by the system administrator. The syntax for
building a syslog archive using variations of these settings is shown in the next example, which uses a frequently employed combination
of class and severity level to track users who log into the system and attempt to configure the router. This is done by specifying class
interactive-commands and severity-level information.
Table 5-4. Severity Levels for System Logging
Severity LevelDescription
emergency Router is in a panic state or for some other reason has become unusable. This is the highest severity level.
alert Router is experiencing conditions that should be corrected immediately. An example would be a corrupted database.
critical Failure or errors on one of the system drives.
error Any standard error message.
warning Any standard system warning message.

Downloader demo watermarks

notice Any condition that is neither an error, nor a warning, but that might require attention.
info All informational messages. This is the JUNOS default setting.
any Any message generated.

[edit system syslog]

lab@Chicago# set file bigbrother interactive-commands info

174
 5. Router Access and System Administration
[edit system syslog]
lab@Chicago# set file bigbrother archive files 5 size 5m no-world-readable

[edit system syslog]

lab@Chicago# show
file bigbrother {
interactive-commands;
info;
archive size 5m files 5 no-world-readable;
}

Other Administrative Responsibilities

This section delves into some of the other tasks for which a system administrator is normally responsible. These tasks include setting a
name and the location of the router itself, specifying a DNS, and setting the time.

Setting a Host Name and Domain

Although it is not necessary, for organizational purposes every router should have a name. The router is assigned a name using the set
host-name <name of the router> command at the [edit system] level of hierarchy in JUNOS. In the following example,
the router's name is changed from Tokyo to Chicago. Remember that all of the changes made through the CLI are made to a candidate
configuration. These changes do not go into effect until the candidate is committed.
[edit]
lab@Tokyo# set system host-name Chicago

[edit]
lab@Tokyo# commit
commit complete
[edit]

www.ebook-converter.com
lab@Chicago#
The domain name in which the router is logically positioned can be defined on the router and, if configured, the domain name will be
appended to host names in some domain-name lookup situations. To configure the domain name, use the set domain-name
command as has been done in the sample below. For the sake of clarity only the output pertinent to the configuration tasks in this
section of the chapter are included in the example below.
[edit system]
lab@Chicago# set domain-name TPIndustries.net

[edit system]
lab@Chicago# show
host-name Chicago;
domain-name TPIndustries.net;

Setting Location
It is sometimes convenient to be able to learn the physical location of a router by reading its configuration, especially in remote access
situations. The options listed below allow a high degree of precision when defining the location of the device:
[edit system]

Downloader demo watermarks

lab@Chicago# set location ?
Possible completions:
altitude Feet above (or below) sea level
+ apply-groups Groups from which to inherit configuration data
country-code Two-letter country code
hcoord Bellcore horizontal coordinate
lata Long-distance service area
175
 5. Router Access and System Administration
latitude Latitude in degree format
longitude Longitude in degree format
npa-nxx First 6 digits of phone number (area code plus
exchange)
postal-code Zip code or postal code
vcoord Bellcore vertical coordinate
[edit system location]
lab@Chicago# set country-code DK

[edit system location]

lab@Chicago# show
country-code DK;

Note
The output from the CLI above mentions Bellcore several times. Bellcore is short for Bell Communications Research.
Among the many things, they have divided the world up into zones based on the magnitude of earthquakes possible in any
given area. Those areas with the potential for the strongest earthquakes, 7.1–8.3 on the Richter scale, are given a Bellcore
Zone rating of 4. Areas that are not subject to earthquakes, south Florida for example, are given a Bellcore Zone rating of 0.

Setting Time and Date

By default, all Juniper Networks routers are shipped set to Greenwich Mean Time (GMT). They are preconfigured to the correct time
and date per the GMT time zone. A small battery within the chassis, similar to that used in a standard personal computer, maintains a
running clock. Once the router has been installed, it may be necessary, or at least convenient, to change the time-zone setting. This is
accomplished by using the set time-zone <continent>/<major-city> command as is shown below:
[edit system]
lab@Chicago# set time-zone America/Guyana

[edit system]

www.ebook-converter.com
lab@Chicago# show
host-name Chicago;
domain-name TPIndustries.net;
time-zone America/Guyana;
location country-code DK;
It will more than likely be necessary to use the set time-zone ? command to view the list of valid continent and city combinations.
The list is rather lengthy. A small portion of it is shown next:
[edit system]
lab@Chicago# set time-zone ?
Possible completions:
Africa/Abidjan Time zone for Africa/Abidjan
Africa/Accra Time zone for Africa/Accra
Africa/Addis_Ababa Time zone for Africa/Addis_Ababa
Africa/Algiers Time zone for Africa/Algiers
Africa/Asmera Time zone for Africa/Asmera
Africa/Bamako Time zone for southwest Mali
Africa/Bangui Time zone for Africa/Bangui
Africa/Banjul Time zone for Africa/Banjul

Downloader demo watermarks

Africa/Bissau Time zone for Africa/Bissau
Africa/Blantyre Time zone for Africa/Blantyre
Africa/Brazzaville Time zone for Africa/Brazzaville
Africa/Bujumbura Time zone for Africa/Bujumbura
Africa/Cairo Time zone for Africa/Cairo
Africa/Casablanca Time zone for Africa/Casablanca
Africa/Ceuta Time zone for Ceuta & Melilla
Africa/Conakry Time zone for Africa/Conakry
176
 5. Router Access and System Administration
Africa/Dakar Time zone for Africa/Dakar
Africa/Dar_es_Salaam Time zone for Africa/Dar_es_Salaam
Africa/Djibouti Time zone for Africa/Djibouti
Africa/Douala Time zone for Africa/Douala
Africa/El_Aaiun Time zone for Africa/El_Aaiun
Africa/Freetown Time zone for Africa/Freetown
Africa/Gaborone Time zone for Africa/Gaborone
Africa/Harare Time zone for Africa/Harare
As with personal computers, it may occasionally be necessary to make an adjustment to the date or time on a Juniper Networks router.
This is accomplished by using the set date command in the operational mode. Table 5-5 shows the format for the dates.
Table 5-5. Date and Time Format for Routers

FormatDescription Example
YYYY Current year in a four-character numeric format 2003
MM Current month in a two-character numeric format 01
DD Current day in a two-character numeric format 09
HH Current hour using a 24-hour clock. 19
MM Current minute using a two-character numeric format 45
SS Current second using a two-character numeric format15
The configuration sample below demonstrates the syntax of the command as it is typed in the operational mode. In this example, the
date and time have been set to reflect 15 seconds past 7:45 P.M., January 9, 2003.
lab@Chicago> set date 200301091945.15
Thu Jan 9 19:45:15 UTC 2003

lab@Chicago> show system uptime

Current time: 2003-01-09 19:45:54 UTC
System booted: 2003-01-04 08:20:41 UTC (5d 11:25 ago)
Protocols started: 2003-01-04 08:22:01 UTC (5d 11:23 ago)

www.ebook-converter.com
Last configured: 2002-04-01 02:27:32 UTC (40w3d 17:18 ago) by lab
7:45PM up 5 days, 11:25, 1 user, load averages: 0.00, 0.00, 0.00

Using the NTP

In large-scale networks, it may be necessary to enable a means of synchronizing the routers. This is accomplished using NTP. NTP uses
a subnetwork of time servers organized and operating in a hierarchical manner. Within the group of servers, there are master and slave
relationships established based on the reliability of the clock within the time server. The master time server synchronizes its internal
clock to national time standards through radio connections. Once the master is synchronized, the slave servers on the subnetwork
synchronize to the master. The servers are then capable of distributing reference time to switches, routers, and other devices within the
network.
All Juniper Networks M-Series routers are capable of functioning as NTP servers with no degradation of performance or throughput.
The statements needed to configure a router to be an NTP server are detailed in later paragraphs. The sample below shows the range of
options available when configuring NTP. We will look in detail at some of the more commonly used options.
[edit system ntp]
lab@Chicago# set ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data

Downloader demo watermarks

> authentication-key
boot-server
> broadcast
broadcast-client
Authentication key information
Server to query during boot sequence
Broadcast parameters
Listen to broadcast NTP
> multicast-client Listen to multicast NTP
> peer Peer parameters
> server Server parameters
177
 5. Router Access and System Administration
+ trusted-key List of trusted authentication
The first step in configuring NTP on a Juniper Networks router is to specify the IP address of a boot server. The boot server is the NTP
server that will be contacted by the router at initial boot to help the router synchronize with the time settings on all devices on the rest of
the network. To specify a boot server, use the set boot-server command at the [edit system ntp] hierarchy. The example
below shows the setting that would be used for an NTP server with an IP address of 192.168.151.5:
[edit system ntp]
lab@Chicago# set boot-server 192.168.151.5

[edit system ntp]

lab@Chicago# show
boot-server 192.168.151.5;
Following the specification of a boot server, it is necessary to decide what type of role the Juniper Networks router will play with regard
to determining time in the network. There are three modes defined in JUNOS that relate to this role: client mode, broadcast mode, and
symmetric active mode.
A router operating in client mode will never function as an NTP server. It will always synchronize its internal clock to that of an
NTP server.
In broadcast mode, the router functions as the NTP server for client systems. Client systems are devices that rely on the NTP server
for synchronization.
In symmetric active mode, the router is capable of functioning as an NTP server. Symmetric active mode is typically used for
situations where there are two or more reliable clock sources on the network, making it sensible to allow one source to function as a
primary and the others to serve as backups to the primary.
To configure the router to operate in client mode, use the set server command at the [edit system ntp] level of hierarchy.
This will specify the NTP server to which the router will be a client. In the example below, we are designating our router as a client to
an NTP server located at IP address 192.168.10.5.
[edit system ntp]

www.ebook-converter.com
lab@Chicago# set server 192.168.10.5

[edit system ntp]

lab@Chicago# show
server 192.168.10.5;
To configure the router to operate as an NTP server, use the set broadcast command:
[edit system ntp]
lab@Chicago# set broadcast 192.168.0.0

[edit system ntp]

lab@Chicago# show
broadcast 192.168.0.0;
To configure the router to function as a backup or potential NTP server, use the set peer command. In the example shown below,
the router being configured is one of three capable of handling NTP responsibilities. The other two devices are found at IP addresses
192.168.5.5 and 192.168.5.6. The latter will be used as the master in this case, which is indicated by the prefer statement,
and will also function as a boot server.
[edit system ntp]

Downloader demo watermarks

lab@Chicago# set peer 192.168.5.6 prefer

[edit system ntp]

lab@Chicago# set peer 192.168.5.5

[edit system ntp]

lab@Chicago# show
178
 5. Router Access and System Administration
peer 192.168.5.6 prefer;
peer 192.168.5.5;

Note
NTP adjustments are only made in situations where the router's internal clock is set to more than 128 ms or less than 128
seconds different from the NTP master clock. If the router's internal time is less than 128 ms different, the time is slowly
stepped into sequence with the NTP clock. If the time is more than 128 seconds different from the master, then it is necessary
to use the set date command to bring the time to within 128 seconds of the NTP clock before synchronization will take
place.

Designating a DNS Server

To have the router resolve host names into IP addresses it is necessary to designate one or more DNSs. This is accomplished by using
the set name-server command. For the sake of clarity, only the elements pertinent to this example are included in the output of the
show command as follows:
[edit system]
lab@Chicago# set name-server 192.168.50.50

[edit system]
lab@Chicago# show
name-server {
192.168.50.50;
}

Chapter Summary
This chapter gives the reader an overview of the administrative responsibilities of a network engineer and how those responsibilities are
carried out on a Juniper Networks router. We first looked at the methods with which we would make a physical connection to the
router, including the console, auxiliary, and management Ethernet ports. We looked in detail at the structure of the commands needed

www.ebook-converter.com
to configure the management Ethernet connection. We then looked at methods of authenticating the identity and defining the
permissions and restrictions of system users. We also discussed ways of configuring the router to rely on network authentication
methods, including RADIUS and TACACS+. In Section 5.2.7 we learned how to enable FTP, Telnet, and SSH. We also learned some of
the commands to use at the prompts encountered when using these services. We covered the steps that can be taken to recover a lost
password. Finally, we looked at some of the other jobs that, although secondary, are still important to the configuration of the router.
These included setting a host name, adjusting system time and date, configuring NTP, and specifying DNS servers for host-name
resolution.

Bibliography
Case Study: A Typical Base Configuration
Now that we have discussed the individual statements that go into setting up users, enabling services, and enabling remote access to the
router we will look at a typical configuration example. The following statements are representative of a typical base configuration. The
elements included in this base would be found on almost any Juniper Networks M-Series router, be it located in a production network or
a lab environment.
No production network interfaces have been configured and no IGP has been put in place.
A user, lab, has been added and given the ability to execute all commands as needed. Another user, guest, has been added and given

Downloader demo watermarks

operator permissions. Other login classes and user accounts can be added as the need arises.
The network the router will be placed in uses NTP, and the boot server and NTP server have both been designated. The router is
physically located in the United States.
The auxiliary port has been administratively enabled and will serve as a backup connection in the event that problems are encountered
with the console port.
179
 5. Router Access and System Administration
SSH services have been enabled on the router to permit encrypted remote access and file transfer across the management LAN. FTP
and Telnet were intentionally left out of the configuration
System logging has been turned on and set to cache all interactive commands at the info level and higher. It will store these in up to five
files with each file being allowed to reach a maximum size of 5MB. The file will not be readable by anyone except lab, root, and
other super-users.
The management Ethernet interface has been configured with an IP address that puts it in the management LAN, but because there
were issues with connectivity, it was necessary to override the default link speed and mode.
lab@Chicago> edit

[edit]
lab@Chicago# show
version 5.0R1.4;
system {
host-name Chicago;
location {
country-code us
login {
user lab {
uid 2000;
class power-user;
authentication {
encrypted-password “$1$f4uMb$l.We41nx6.M8CfrFl.Wf81”; #
SECRET-DATA
}
}
user guest {
uid 2001;
class operator;
authentication {
encrypted-password “$1$f4uMb$l.WM8CfrFl.Wf81”; # SECRET-DATA

www.ebook-converter.com
}
}

ntp {
boot-server 192.168.151.5;
server 192.168.10.5;
}
ports {
auxiliary {
insecure;
speed 9600;
type vt100;
}
}
services {
ssh;
}
syslog {
file bigbrother {
interactive-commands info;
archive {

Downloader demo watermarks

}
files 5;
size 5M;
no-world-readable;
}
}
}

180
 5. Router Access and System Administration
interfaces {
fxp0 {
speed 100m;
link-mode full-duplex;
unit 0 {
family inet {
address 192.168.161.23/24;
}
}
}
}
[edit]
lab@Chicago#

www.ebook-converter.com

Downloader demo watermarks

181
[ch05bib01] Bill Burton,. Remote Access for Cisco Networks. McGraw-Hill,
<year>2000</year>.
[ch05bib02] Jeff Doyle,. Routing TCP/IP, Vol. I. Cisco Press, <year>1998</year>.
[ch05bib03] Radia Perlman,. Interconnections, 2nd ed. Addison-Wesley,
<year>1999</year>.
[ch05bib04] www.juniper.net
[ch05bib05] www.rfc-editor.org

www.ebook-converter.com

Downloader demo watermarks

182
 6. Router Management, Firewall Filters, and Accounting
Chapter 6. Router Management, Firewall Filters, and Accounting
This chapter deals with issues surrounding SNMP management and securing access to Juniper Networks routers
using JUNOS. It describes SNMP within the context of how it operates within JUNOS.
SNMP is the most commonly used protocol and methodology for performing router management. This chapter
will provide an overview of the protocol itself and how the data is stored and retrieved from a Juniper Networks
router. The important aspects of how Juniper Networks has implemented SNMP will also be discussed—this is
important because there are some unique points to be aware of.
Accounting on a Juniper Networks router is an essential part of making a network profitable. Thus, this chapter
will look at some of the most common accounting and billing implementations and provide real configurations
for reference.
Security in this chapter is defined as techniques and methods to secure your network through the use of firewall
filters. In JUNOS, the use of firewall filters allows the creation of packet filters and the logging of events to help
secure the network from hackers and control access.
The chapter ends with a variety of different security configuration examples. The case study looks at the many
possible ways to implement a secure network while protecting against denial of service (DoS) attacks and other
harmful activities prevalent on the Internet these days.

SNMP Overview
You may already know that before the Internet became the public, global entity that it is today, it was known as
ARPANET. Of course, it was much smaller then, but did you know that they used ping to manage the network?

www.ebook-converter.com
Essentially, network operators found system problems if a ping failed or if the phone rang!
This method, while functional at the time, did not scale well as the ARPANET evolved into the Internet. Thus,
another solution was needed. SGMP was the first solution after ping, and it quickly evolved into SNMP. The
goal was, and still is, to have a protocol that allows you to monitor and manage a network dynamically. SNMP is
a network management tool that enables you to do this. Interestingly enough, some networks still use ping today
as a method to manage the network and conduct performance monitoring.
SNMP is the most commonly used protocol in the arena of network management. Originally developed in 1988,
SNMP has evolved into a robust protocol dedicated to managing various network devices and is the de facto
standard for network management. As networks grow and evolve and their complexity increases, the ability to
determine the operational parameters and functionality of the network devices is crucial. SNMP is extensible
and easy to implement (i.e., little code is needed), which allows manufacturers to easily implement SNMP in
their products. SNMP also allows manufacturers to have an architecture dedicated to network management and,
thus, separate from the device's ability to perform the desired network function.
SNMP is an OSI application-layer protocol that provides for the exchange of information between SNMP-

Downloader demo watermarks

enabled network devices. By using, measuring, and evaluating the data, network administrators are able to use
SNMP to achieve the following goals:
Manage network performance
Identify and resolve network problems
183
 6. Router Management, Firewall Filters, and Accounting
Plan for network growth
Locate network trouble points
Determine the configuration of network devices
Thus, through the use of SNMP, you can determine the utilization of a router or circuit, be alerted when network
traffic thresholds are reached, or even get paged when a network device becomes unreachable. We will look at
some of the ways to accomplish this and the necessary tools.

Evolution of SNMP
SNMP evolved from RFC 1028 SGMP; version 1 is currently documented in RFC 1157. As acceptance of
SNMP grew, the Internet Engineering Task Force (IETF) began work on a new version of SNMP. Owing,
however, to strong opinions and a failure to compromise, SNMPv2 was never ratified. Two opposing groups
emerged, and to date, nothing has ever been formally completed. Recently—in IETF time—a new working
group was formed to develop SNMPv3. We can only hope they have learned from the past and that the
SNMPv3 standards will be ratified. In spite of the formal failure to adopt v2, it is still widely used for a variety of
purposes. It is currently implemented in both the Cisco Internetworking Operating System (IOS) and JUNOS,
owing to support for larger counters. SNMPv3 is considered superior, in large part due to its enhanced security
support.
Table 6-1 lists network-management-based RFCs and shows how SNMP has evolved to meet the needs of
today's complex internetworks.
Table 6-1. SNMP RFC Evolution

www.ebook-converter.com
SNMP Functional AreaRFC Status
SGMP
SNMPv1
Historic
Standard
Applicable RFCs
1028
1067 -> 1098 -> 1157
SNMPv2, SNMPv2p Historic 1441, 1445 -> 1449, 1452 -> 1901, 1905-1906, 1908
SNMPv2u Experimental 1909, 1910
SNMPv2 Proposed draft (expired)Not assigned a number
SNMPv2c Experimental 1901
SNMPv3 Draft standard 2261, 2265, 2271, 2275, 2571 -> 2575
MIB-I Standard 1066 -> 1156
MIB-II Proposed standard 2011, 1158 -> 1213, 2012, 2013
Interfaces group Proposed standard 1229 -> 1573 -> 2233
SMIv1 Standard 1065 -> 1155, 1212
SMIv2 Standard 1442 -> 1444, 1902 -> 1904, 2578, 2580
Get-bulk Experimental 1187
RMON Draft standard 1271 -> 1757
Downloader demo watermarks
RMONv2
SMON
Proposed standard
Proposed standard
2021
2613

-> Indicates standards that replace or update earlier RFCs

184
 6. Router Management, Firewall Filters, and Accounting
SNMP is part of an Internet network-management architecture based on the interactions of several separate
entities: agents, network-management stations, management information bases, and abstract syntax notation
(ASN). ASN is the method in which SNMP is written to create an SNMP MIB. These entities are described in
the following sections.

Agents
SNMP achieves the goal of managing network devices by sending messages known as protocol data units
(PDUs) to SNMP-enabled devices. These devices have compliant code within them that uses SNMP. When a
device becomes SNMP-enabled it is referred to as an agent. An SNMP agent will store data about the device, its
configuration, and its operation in a specialized database used by SNMP and known as an MIB. Agents can be
placed in almost any device. Figure 6-1 shows some of the devices agents can be in. It will not be long before
even our refrigerators are SNMP accessible as the technology we deal with is implemented in more aspects of
our everyday life. In Figure 6-1 you can see that the network-management station uses SNMP across the
network to access the SNMP agent in a network device to retrieve data. This data could be as simple as who
manufactured the device or as complex as the amount of data sent through an interface.

www.ebook-converter.com
Figure 6-1. SNMP Agents in Network Devices
In this figure the SNMP protocol is rather generic in its representation. In reality, SNMP has a variety of actions
that it can perform as a protocol. For example, SNMP can get a specific bit of information or get a bulk of
information. Perhaps the most common is where the SNMP agent tells the management station an event has
occurred (e.g., link down) via a special SNMP message known as a trap.

Network-Management Systems
Network management is done from network-management systems (NMSs), which are general-purpose
computers running special management software. The specialized management software usually employs a
version of SNMP so that the management station can communicate with the SNMP agents throughout the
network. You may have heard of the more popular NMSs, such as HP OpenView or Tivoli, but there are many

Downloader demo watermarks

others.
The management stations contain one or more processes that communicate with agents over the network, issuing
commands and getting responses. In this design, all the intelligence is in the management station's software to
keep the agents as simple as possible and minimize their impact on the devices they are running on. This is a
good design and has allowed many manufacturers to put SNMP agents into all kinds of devices, from large
185
 6. Router Management, Firewall Filters, and Accounting
routers to simple printers. Many management stations have a graphical user interface to allow the network
manager to inspect the status of the network and take action when required.
A managed item is a characteristic in a network device that is being measured. In Figure 6-2 you can see an
NMS communicating with the SNMP agent. The managed object has an active SNMP agent, and it can be a
switch or a router—it does not matter. The key thing to note is that the MIB database keeps the information
from each of the managed items within the managed items. These managed items could, for example, be
interface counters on a router or switch.

Figure 6-2. System and Object Management

MIB
As mentioned earlier, the MIB is a database that holds a variety of information about the SNMP-enabled device.
The SNMP agent stores this information in a database that resembles a tree. This structure can be seen in Figure

www.ebook-converter.com
6-3. Notice in this figure the numbers in parentheses; these numbers provide a map to the information stored by
the MIB. When these numbers are placed together in a string, they are known as an object identifier (OID); we
will look at an OID in more detail shortly.

Downloader demo watermarks

Figure 6-3. MIB Tree
In Figure 6-3 you will notice the arrow that highlights the MIB-2 (represents SNMPv2) groupings. Our
discussion of networking with routers will primarily be concerned with the groups at this level. Specifically, each
186
 6. Router Management, Firewall Filters, and Accounting
group will contain information as follows:
The system group provides information regarding the ownership and contacts for the device being queried.
These values are only retrievable if they have been configured on the router.
The interfaces group will provide SNMP with data on all the interfaces found on a device and how they are
operating. Specifically, note that the maximum transmission unit (MTU), speed, discards, description, and
more are available for retrieval here.
The address table (AT) group provides information about the physical and logical addresses associated with
each interface. For example, this is where to look for a MAC address.
The IP group deals with IP traffic into and out of the device. Consider for a moment the number of items
possible within this group. This group is huge and has data about various transmission counters, packet
discards, and IP routing. This is one reason why SNMP needs to be protected and secured. Figure 6-4 shows
a screen shot of a portion of the MIB tree, specifically the IP group, which lists all the directly connected
routers and what routes they are able to tell you about.

www.ebook-converter.com
Figure 6-4. IP Group in the MIB Tree
The ICMP group is about ICMP-related messages and statistics. Basically, it has a counter for each ICMP
message and records how many of that type have been seen. For example, it tracks how many times the
device was pinged and how many times the device replied to a ping, as well as the number ICMP error
messages.
The TCP group monitors the current and cumulative number of connections opened, segments sent and
received, and various error statistics. You could, for instance, monitor who was telnetted into your device
through this group because Telnet is TCP.
The UDP group logs the number of UDP datagrams sent and received and how many of the latter were

Downloader demo watermarks

undeliverable due to an unknown port or some other reason.
The Exterior Gateway Protocol (EGP) group is used for routers that support EGP. It keeps track of how
many packets of what kind went out, came in and were forwarded correctly, or came in and were discarded.

187
 6. Router Management, Firewall Filters, and Accounting
Note
The EGP MIB is deprecated since no one uses EGP anymore.
Additional groups can be added as you add more MIBs. OSPF, for example, has its own RFC that details the
OSPF MIBs, and if you load them into your SNMP browser, you can access the OSPF data that SNMP stores on
a router. You can retrieve OSPF information, like the whole OSPF link state database (LSDB). In this chapter
we used an MIB browser program to access the SNMP data on routers. This browser came from MG-SOFT
(www.mg-soft.com) and is a very robust tool that you should evaluate.

SNMP OID Example

An OID is a location within an MIB expressed in a string of numbers. These numbers are the map that navigates
through the MIB tree to specific data. Take for example the following OID: .1.3.6.1.2.1.2.2.1.3. This
OID will take your query through the MIB tree and identify all the 802.3 Ethernet interfaces on a network
device. You can see this by tracing each number to the corresponding tree entry as shown below. It might be
useful to reference Figure 6-3 and follow your way down the tree using the OID numbers below to match with
the numbers in parentheses:
.1 = ISO
.3 = identified organization
.6 = DOD
.1 = Internet

www.ebook-converter.com
.2 = mgmt
.1 = MIB-2
.2 = interfaces
.2 = IfTable
.1 = ifEntry
.3 = If Type
The process of retrieving this MIB data is known as walking the MIB in the vernacular of SNMP. This walking is
actually using the SNMP get command to get the data from the SNMP device.

Juniper Networks–Specific MIBs

Downloader demo watermarks

Many equipment vendors have developed MIBs for use within SNMP that are specific to their equipment.
Juniper Networks has done this as well. Figure 6-5 shows the specific MIBs that Juniper Networks has
developed. You can see that there are several options for Juniper Networks routers you can retrieve via SNMP,
ranging from chassis alarms to MPLS usage and traffic statistics. You can find the Juniper Networks–specific
MIBs online at www.juniper.net/techpubs/mibs.html.
188
 6. Router Management, Firewall Filters, and Accounting

Figure 6-5. Juniper Networks MIB Tree

There are a variety of excellent resources available should you wish to research SNMP further. We would
recommend the following online resource: www.snmp.com. For printed material on SNMP, the following two
books are also very good:
Mauro, Douglas R., and Kevin J. Schmidt. Essential SNMP. O'Reilly & Associates, 2001.
Miller, P., and M. Miller. Managing Internetworks with SNMP. 3rd ed. John Wiley & Sons, 1999.

Configuring SNMP on a Juniper Networks Router

Now that you have an understanding of how SNMP operates and what it was designed to do, let's discuss how to

www.ebook-converter.com
configure and enable SNMP on a Juniper Networks router. The following are the default conditions for SNMP
defined by Juniper Networks that will guide the configuration process:
SNMP is disabled.
When SNMP is enabled, it is activated on all router interfaces.
SNMPv1 and v2 are supported, and both are automatically activated, unless a version is specified.
Read-write SNMP communities are not really writeable.
The only time you can use an SNMP set command is through the use of the proxy ping set command
(JUNOS 5.0 and later).
Juniper Networks implementation of SNMP traps will transmit multiple traps (i.e., one for each version) if
the version to use it is not specified.

Downloader demo watermarks

If the SNMP passwords are known, anyone can get information from a Juniper Networks router.
Activating SNMP is rather straightforward as SNMP has its own configuration hierarchy level; thus, all
configuration statements will be made within the [edit SNMP] level. In a Juniper Networks router, there are a
large number of optional parameters that can be used when configuring SNMP as listed below:

189
 6. Router Management, Firewall Filters, and Accounting
[edit SNMP]
snmp {
description description;
location location;
contact contact;
interface [ interface-name ];
community community-name {
authorization authorization;
clients {
default restrict;
address <restrict>;
}
view view-name;
}
trap-group group-name {
categories category;
targets {
address;
}
version version;
}
view view-name {
oid object-identifier (include | exclude);
}
traceoptions {
file <files number> <size size>;
flag flag <disable>;

www.ebook-converter.com
}
}
It is beyond the scope of this chapter to discuss all these parameters, but we will look at enough of these options
for you to get SNMP operating on a complex internetwork. If additional information is needed, refer to the
appropriate RFC or the resources recommended in the bibliography, such as the Juniper Networks
documentation.

Basic SNMP Configuration

When configuring SNMP, there are two possible types of access to data that you must configure. In SNMP,
access types are referenced as read-only and read-write.
[edit snmp]
user@Chicago# set ?
Possible completions:

Downloader demo watermarks

+ apply-groups Groups from which to inherit config data
> community Configure a community string
contact Contact information for administrator
description System description
+ interface Restrict SNMP requests to interfaces
location Physical location of system
190
 6. Router Management, Firewall Filters, and Accounting
> traceoptions Trace options for SNMP
> trap-group Configure traps and notifications
> view Define MIB views
It is also recommended that you configure the descriptive properties of SNMP as well (e.g., location, description,
and contact). This provides network operation personnel with important information about who to contact if
necessary.
[edit snmp]
user@Chicago# set location "CHICAGO, NC"
user@Chicago# set description "JUNIPER NETWORKS ROUTER"
user@Chicago# set contact "TOM THOMAS"
When dealing with SNMP communities (read-only and read-write), you must configure a password known to
access the appropriate community. Note well that community strings are passwords and should be treated as
such. In the following example, the router is configured to provide read-only access to those that provide the
password public and read-write access to those who possess the password 800frIP.
[edit snmp]
user@Chicago# set community public authorization read-only

[edit snmp]
user@Chicago# set community 800frIP authorization read-write
The completed initial SNMP configuration looks as follows:
[edit snmp]

www.ebook-converter.com
user@Chicago# show
description "JUNIPER NETWORKS ROUTER";
location "CHICAGO, NC";
contact "TOM THOMAS";
community public {
authorization read-only;
}
community 800frIP {
authorization read-write;
}
Now that the initial SNMP configuration has been completed, you need to test access and operation. Once you
configure the MIB browser with the proper password, you can access the router. Refer to Figure 6-6, where an
SNMP query was sent to the router at 192.168.254.70 to retrieve the system description at the OID
1.3.6.1.2.1.1.1.0.

Downloader demo watermarks

191
 6. Router Management, Firewall Filters, and Accounting

Figure 6-6. Testing SNMP Access and Operation

www.ebook-converter.com
Configuring SNMP Trap Groups
SNMP traps are the notifications used by SNMP to alert you to a problem or change in status within a device.
Trap groups in SNMP are excellent tools that allow the distribution of certain specified traps to the devices that
you indicate. The trap-group name field will be transmitted within every trap sent as identified in that trap
group. When configuring a trap group, make sure that you specify a target, otherwise it will not be very
effective. A possible configuration is shown below:
[edit snmp]
user@Chicago# show
description "JUNIPER NETWORKS ROUTER";
location "CHICAGO, NC";
contact "Tom Thomas";
community public {
authorization read-only;

Downloader demo watermarks

}
community 800frIP {
authorization read-write;
}
trap-group ALERTS {
version v2;
192
 6. Router Management, Firewall Filters, and Accounting
categories link;
targets {
192.168.254.7;
}
}
[edit snmp]
user@Chicago#

Note
An SNMP trap group target is usually the IP Address of the SNMP server.
In addition to defining the target of a trap group, you can also specify which SNMP version of traps will be
transmitted. By default, Juniper Networks routers will transmit all versions; thus, you may end up receiving
multiple traps if you do not specify a version.
The NMS is configured to receive the link traps via the ALERT trap group. Link traps consist of reporting the
up-down status of router interfaces. In Figure 6-7, the NMS receives two traps: The first trap is a link-down
notification and tells who (router 192.168.254.70), what (link-down notification), where (interface fxp2),
and when (10/27/01—11:19). The second trap notifies us that the interface is back up.

www.ebook-converter.com

Figure 6-7. Link Down/LinkUp Trap Receipt

Controlling SNMP Access

Downloader demo watermarks

There has been some confusion about SNMP access and Juniper Networks routers. Note that you cannot use the
SNMP set command to change any value in a Juniper Networks router—they are read-only. Keep this in mind
when configuring SNMP on a Juniper Networks router as it is a key differentiator from other vendors and a
deviation from the SNMP standard. In general then, we can say that SNMP access is always read-only,
regardless of what the documentation or router tells you.

193
 6. Router Management, Firewall Filters, and Accounting
That a Juniper Networks router only supports read-only access does not mean you should allow just anyone to
retrieve SNMP data from your router. You may want to reduce or limit the OIDs that a certain NMS or netblock
has the ability to read on your routers. Say you only want to let customers read interface counters on the
interfaces they are connected to, thus allowing them to see the performance of their connection. In this case, you
would create an MIB VIEW associated with an SNMP community.
The following example creates a community called CUSTOMER and an MIB VIEW called CUSTOMER. When
you assign that MIB VIEW to the community as shown in the configuration output below, you restrict access to
the interface OIDs from the SNMP tree.
[edit snmp]
user@Chicago# show
description "JUNIPER NETWORKS ROUTER";
location "CHICAGO, NC";
contact "TOM THOMAS";
view CUSTOMER {
oid .1.3.6.1.2.1.2;
}
community public {
authorization read-only;
}
community 800frIP {
authorization read-write;
}
community CUSTOMER {
view CUSTOMER;
authorization read-only;

www.ebook-converter.com
}
trap-group ALERTS {
version v2;
categories link;
targets {
192.168.254.7;
}
}
[edit snmp]
It is important to note that the OID is inherited in Juniper Networks routers. Thus, the OID used here
(.1.3.6.1.2.1.2) is that for the interface group; all more specific OIDs beneath it are considered within it.
In Figure 6-8, the interface group is selected and its OID used in the configuration example. Notice that all the
interface characteristics and more specific entries beneath the interface group are accessible by default. Caution
is required when determining which OIDs are accessible. For example, it may not be appropriate to allow a
customer access to the MIBs, which contain all the routing data for your network.

Downloader demo watermarks

194
 6. Router Management, Firewall Filters, and Accounting

Figure 6-8. OID Inheritance

Configuring the Interfaces on Which SNMP Requests Can Be

Accepted
www.ebook-converter.com
In today's world, many networks are extremely security conscious, and Juniper Networks has provided a method
for changing the default behavior of accepting SNMP queries on any interface. You can specify the interface
names that you want to allow to receive and process SNMP requests. This feature is configured by specifying the
interface type at the [edit SNMP] configuration level in the JUNOS CLI, as shown below. If you wish to
allow multiple interfaces access to SNMP, then put the names of the interfaces within brackets.
[edit snmp]
interface [ interface-names ];
This example shows how combining MIB VIEWs and limiting interfaces increases the security of a Juniper
Networks router. When we consider MIB VIEWs combined with the interface-limiting concept, the security of a
Juniper Networks router is greatly increased.
One of the most common uses of by enabling SNMP on an interface is the presence of a separate network used
only to manage network devices. In this case you would just enable SNMP on the interface connected to the
dedicated management network.

Downloader demo watermarks

Verifying Operation and Troubleshooting SNMP
SNMP failures in operation are not complex, and indications of it are rather easy to determine. The preceding
sections showed how the ability to access and have traps reported is accomplished. SNMP failures or
195
 6. Router Management, Firewall Filters, and Accounting
misconfigurations will cause this feature not to work, which, unlike a routing failure, can be extremely
noticeable. In this section we will look at how to use the JUNOS trace options to track the operation of SNMP
and to display SNMP statistics.

Trace Options
To trace SNMP traffic, you specify trace options by including the traceoptions statement at the [edit
snmp] hierarchy level. As the following example shows, you can set the filename and size, among other things:
[edit snmp]
user@Chicago# set traceoptions filename files 10 size 500
user@Chicago# set flag ?
Possible completions:
all Trace everything
general Trace general events
interface-stats Trace interface statistics (logical and physical)
pdu Dump SNMP request/response packets
protocol-timeouts Trace SNMP request timeouts
routing-socket Trace routing socket calls
subagent Trace Sub-agent restarts
timer Trace internal timer events
varbind-error Trace varbind errors
[edit snmp traceoptions]
user@Chicago# set flag all
Using the all option would result in a configuration for SNMP that has tracing enabled as follows:

www.ebook-converter.com
[edit snmp]
user@Chicago# show
description "JUNIPER NETWORKS ROUTER";
location "CHICAGO, NC";
contact "TOM THOMAS";
view CUSTOMER {
oid .1.3.6.1.2.1.2;
}
community public {
authorization read-only;
}
community 800frIP {
authorization read-write;
}
community CUSTOMER {
view CUSTOMER;
authorization read-only;

Downloader demo watermarks

}
traceoptions {
file size 500 files 10;
flag all;
}

196
 6. Router Management, Firewall Filters, and Accounting
The output of the tracing operations is placed into the following three files, all of which are located in the
/var/log directory, which is accessible via the shell:
snmpd—. contains errors and communications between the server and subagents
mib2d—. contains all interface statistics
rmopd—. contains all ping MIB statistics
If you are interested in learning additional information on the trace options functionality and features, refer to
Section 15.6.

SNMP Statistics
You can see the operation and function of SNMP via the following commands:
show snmp statistics
clear snmp statistics
This next example of the show command demonstrates the various parameters and statistics that you can
recover from the statistics command:
user@Chicago> show snmp statistics
SNMP statistics:
Input:
Packets: 0, Bad versions: 0, Bad community names: 0,

www.ebook-converter.com
Bad community uses: 0, ASN parse errors: 0,
Too bigs: 0, No such names: 0, Bad values: 0,
Read onlys: 0, General errors: 0,
Total request varbinds: 0, Total set varbinds: 0,
Get requests: 0, Get nexts: 0, Set requests: 0,
Get responses: 0, Traps: 0,
Silent drops: 0, Proxy drops 0
Output:
Packets: 9, Too bigs: 0, No such names: 0,
Bad values: 0, General errors: 0,
Get requests: 0, Get nexts: 0, Set requests: 0,
Get responses: 0, Traps: 9
The clear SNMP command resets all the values displayed back to zero. This is useful when troubleshooting or
monitoring the operation of SNMP by resetting the values to zero.

Introduction to Firewall Filters

Downloader demo watermarks
Packet Filtering, as a concept, is the same regardless of the syntax needed to implement it. If you are reading this
book, you have presumably done some type of filtering during your career. When working with Juniper
Networks routers, the whole filtering process is known as firewall filtering.
Thus, this chapter will focus on understanding the syntax behind the functionality present in Juniper Networks
197
 6. Router Management, Firewall Filters, and Accounting
routers. The implementation of filtering within Juniper Networks routers is extremely powerful and based on
many of the RFCs governing advanced IP services. It is also documented in the following RFCs:
RFC 792, Internet Control Message Protocol (ICMP)
RFC 2474, Definition of the Differentiated Services (DS) Field
RFC 2475, An Architecture for Differentiated Services
RFC 2597, Assured Forwarding PHB
RFC 2598, An Expedited Forwarding PHB
Juniper Networks uses the name firewall filters not to imply in-depth firewall functionality, but rather, to
generalize on the JUNOS ability to filter IP packets based on their content. This type of packet filtering allows
you to protect your network and comes with a rich set of functions:
It protects IP services (e.g., Telnet, routing, SNMP).
Filters can be inbound or outbound.
It allows for rate-limiting, thereby thwarting certain DoS attacks.
The same filter can be applied to multiple interfaces.
It provides for verification of IP packet parameters, such as source address, protocol, and port.

Note
www.ebook-converter.com
Remember the caveat that JUNOS only allows for IP-based filters!
Filtering in a Juniper Networks router implies that upon the matching of criteria within a packet, an action can
then be taken. However, firewall filtering has some dependencies based on the hardware that you have deployed
in your network:
All routers can filter the packets sent to or by the routing engine.
Routers equipped with an Internet Processor II allow stronger filtering by allowing you to filter packets
forwarded by the router.
Firewall filters allow for the controlling of packets destined to and from the routing engine. There is no measured
limit to the length and depth of the filters possible. However, common sense applies here; the more terms and
conditions you apply with a filter, the longer it will take to process each IP packet against it. In practice, Juniper
Networks reports filters in use with over 1,000 terms and conditions.

Downloader demo watermarks

Firewall-Filter Terms and Processing
Standard filtering, more commonly known as ACL regardless of vendor, follows a series of conditions that can
be acted upon. These are known as conditions. When using Cisco Systems or Ericsson-manufactured routers, the

198
 6. Router Management, Firewall Filters, and Accounting
packet filtering conditions are collectively known as statements within an ACL. In JUNOS, we use firewall filters
that are built using terms. These terms, or statements, have conditions within them. As with other vendors'
products, the order of the terms affects the processing of the filter. When a match is found, the packet is
immediately processed without further processing of the filter. As expected, if no match is found, the packet is
discarded (implicit deny all).
There are two types of conditions that are possible in JUNOS firewall filters: match and action. A match
condition allows you to specify the conditions that a packet will be judged against. The possible parameters
available for matching are as follows:
Source address
Destination address
TCP or UDP port
Protocol
ICMP packet type
IP options
TCP flags
Incoming/outgoing interface
The action condition within a term specifies what the router is to do with the packet if it matches one of the
match conditions defined above. The possible actions are as follows:

www.ebook-converter.com
Accept the packet
Reject the packet
Take no action
With firewall filters, packets can be statistically sampled, counted, or logged to provide data on traffic within
your network, the effectiveness of your filter, or proof of possible attacks. Firewall filters can be applied to
either a physical or a logical interface. Through the use of filters, you can implement rate limiting to prevent your
router or network from being overwhelmed by certain types of packets. This can protect you from certain types
of DoS attacks.

How Firewall Filters Are Evaluated

When a router receives a packet and a firewall filter is present, the packet will be judged to see if it matches the

Downloader demo watermarks

various conditions. Figure 6-9 traces the steps that the router will take as it processes a packet through a firewall
filter. When a packet arrives (lower left of figure), the router checks its contents against each term in the filter.
When a match occurs, the packet is then subject to the match action. If a term does not contain a from
statement, the packet is considered a match and the action in the term's then statement is taken. If a term does
not contain a then statement, or if an action is not configured in the then statement, and the packet matches
the conditions in the term's from statement, the packet is accepted.
199
 6. Router Management, Firewall Filters, and Accounting

Figure 6-9. Packet Process Using a Firewall Filter

If a match does not occur, the packet is processed against the next term in the filter. These steps are repeated
until either the packet matches a term and is processed according to the match condition, or until there are no
more terms and the packet is discarded. Each firewall filter has an implicit discard action at the end of the filter,
which is equivalent to the following explicit filter term:
term implicit-rule {
then discard;
}
Therefore, if a packet matches none of the terms in the filter, it is discarded.
When a discard occurs, a Juniper Networks router does this silently. In essence, this means that the packet is
discarded and no ICMP message is sent back to the transmitter letting it know this discard has happened. Please
keep this in mind when troubleshooting your filters.

www.ebook-converter.com
Configuration Guidelines
When configuring a firewall-filter layout, you should plan the terms and their associated match conditions before
configuring the router to verify the logic. A good configuration rule of thumb is that you would want to place
your most specific terms first to ensure that the processing (top-down) makes the filter function as you desire.
There are a series of configuration steps that you must follow to activate and apply a filter properly.
You need to configure the firewall in the [edit firewall] configuration hierarchy level and apply the filter
to an interface for the filter to be considered active. When you create a firewall filter, the syntax needed is as
follows:
[edit firewall]
filter filter-name {
term term-name {
from {

Downloader demo watermarks

}
then {
match-condition;

action;
action-modifiers;
term implicit-rule {
200
 6. Router Management, Firewall Filters, and Accounting
then discard;
}
}
}
The steps for configuring a firewall filter correspond to the syntax the router expects to see. The filter in this
example stops IP packets sourced from martian routes from reaching the routing engine. In the many networks,
there is no reason for packets sourced from these martian networks to be transmitted. Of course, you can easily
apply a filter like this to prevent access to the routing engine from a network that is attacking your router. To
configure the firewall filter, you need to do the following:
1. Name your filter
2. Name each term in the filter
3. Determine the match conditions
4. Assign the action statement
5. Apply firewall filters to interfaces
The following sections describe how to use these steps to create a firewall filter.

Naming the Filter

Each firewall filter is introduced by the keyword filter and is identified by a unique filter name. In the
following example, we are in the process of creating a filter named RE-SECURE.

www.ebook-converter.com
set filter RE-SECURE
We always recommend that you name your filter something that bears a relation to the filter's purpose. In the
above example, RE-SECURE is a filter to secure access to the routing engine. The filter and term names can
contain letters, numbers, and hyphens, and they can be up to 24 characters long. To include spaces in the name,
enclose the entire name in quotation marks.

Naming Each Term in the Filter

Each filter statement consists of one or more terms. Each term is introduced by the keyword term and
identified by a term name. Each term name must be unique within the larger filter and allow for multiple terms to
be included within a single filter. In this example, we are creating our term with the name BLOCK-MARTIANS,
and if we desire, we can add additional filter terms, thereby creating a chain of possible conditions.
set filter RE-SECURE term BLOCK-MARTIANS

Downloader demo watermarks

Again, name your filters in such way that you understand what their function is at a later date. Be aware that
many Juniper Networks examples use names like Term 1, which is horrible and not self-documenting; we are
trying to avoid nonsensical naming conventions in this book as they don't reflect how things are done in the real
world.

201
 6. Router Management, Firewall Filters, and Accounting
Note
Firewall-filter terms are evaluated in the order in which you specify them in the configuration. To
reorder terms, use the configuration-mode insert command. For example, the command insert
term up before term start places the term up before the term start. This is definitely a very
useful feature.

Determining Match Conditions

In firewall filters you should use the from statement, which defines conditions that are used to match packets.
Essentially, this statement tells the router what to look for in each packet. There are a few caveats to be aware of
at this point in the configuration. You can specify none or many from conditions, and if you specify none, then
the router assumes that all packets match and acts accordingly.
In the following example, we chose the from source-address condition:
set filter RE-SECURE term BLOCK-MARTIANS from source-address
Then, we configured the various source addresses as shown below, after we did all the set commands for
brevity:
[edit firewall filter RE-SECURE term BLOCK-MARTIANS from source-address]
user@Chicago# show
127.0.0.0/8;
128.0.0.0/16;
191.255.0.0/16;
192.0.0.0/24;

www.ebook-converter.com
223.255.255.0/24;
240.0.0.0/4;
We mentioned earlier that the capabilities of firewall filters are rather extensive. The following configuration
output shows the long list of possible match conditions:
user@Chicago# set filter RE-SECURE term BLOCK-MARTIANS from ?
Possible completions:
> address Match IP source or destination address
+ apply-groups Groups from which to inherit configuration data
> destination-address Match IP destination address
+ destination-port Match TCP/UDP destination port
+ destination-port-except Don't match TCP/UDP destination port
> destination-prefix-list Match IP destination prefix-list
+ dscp Match diffserv codepoint
+ dscp-except Don't match diffserv codepoint
first-fragment Match if packet is the first fragment
Downloader demo watermarks
fragment-flags
+ fragment-offset
Match fragment flags
Match fragment offset
+ fragment-offset-except Don't match fragment offset
+ icmp-code Match ICMP message code
+ icmp-code-except Don't match ICMP message code
+ icmp-type Match ICMP message type
202
 6. Router Management, Firewall Filters, and Accounting
+ icmp-type-except Don't match ICMP message type
+ interface-group Match interface group
+ interface-group-except Don't match interface group
ip-options Match IP options
is-fragment Match if packet is a fragment
+ packet-length Match packet length
+ packet-length-except Don't match packet length
+ port Match TCP/UDP source or destination port
+ port-except Don't match TCP/UDP source or destination port
+ precedence Match IP precedence value
+ precedence-except Don't match IP precedence value
> prefix-list Match IP source or destination prefix-list
+ protocol Match IP protocol type
+ protocol-except Don't match IP protocol type
> source-address Match IP source address
+ source-port Match TCP/UDP source port
+ source-port-except Don't match TCP/UDP source port
> source-prefix-list Match IP source prefix-list
tcp-established Match packet of an established TCP connection
tcp-flags Match TCP flags
tcp-initial Match initial packet of a TCP connection
We should note that in the example we are using for this configuration explanation, there is but one single from
statement with lots of associated addresses. When the syntax is presented in this manner, any packet with any of
the listed source addresses indicated will be considered a match.
You can also use multiple from conditions. Notice the from protocol tcp statement in the following

www.ebook-converter.com
configuration:
[edit firewall]
user@Chicago# show
filter RE-SECURE {
term BLOCK-MARTIANS {
from {
source-address {
127.0.0.0/8;
128.0.0.0/16;
191.255.0.0/16;
192.0.0.0/24;
223.255.255.0/24;
240.0.0.0/4;
}
protocol tcp;
}

Downloader demo watermarks

}
}

This statement has the effect of introducing a second match condition. Logically, packets will now have to have
one of the source addresses as shown and be TCP-based packets. The order in which you specify the match
conditions is not important because the term must match all conditions in order for a match to occur.
203
 6. Router Management, Firewall Filters, and Accounting
Assigning the Action Statement
At this point, we have all the names of our filter and terms in place, and we know what kind of packets we are
looking to match. The next logical step is to tell the router what to do with the packets once they are matched
through the use of a then statement as follows:
[edit firewall filter RE-SECURE term BLOCK-MARTIANS]
user@Chicago# show
from {
source-address {
127.0.0.0/8;
128.0.0.0/16;
191.255.0.0/16;
192.0.0.0/24;
223.255.255.0/24;
240.0.0.0/4;
}
}
then {
log;
syslog;
reject administratively-prohibited;
}
In the case of a match, the router will this time log the match to a log file on the hard drive, send a syslog
message, and transmit back an administratively prohibited message. Of course, whether that
message has any impact on the sender is open to debate, but it will be sent because the RFC says it must.

www.ebook-converter.com
The following CLI example shows the then actions possible with a firewall filter:
user@Chicago# set then ?
Possible completions:
accept Accept the packet and transmit
count Count the packet in the named counter
discard Discard the packet
log Log the packet
output-queue Set output queue for packet (0..3)
plp Mark the packet (0..1)
policer Police the packet using the named policer
> reject Reject the packet and send reject message
routing-instance Provide routing instance
sample Sample the packet
syslog Syslog information about the packet

Downloader demo watermarks

Do not forget to tell the router what packets to accept as shown below. If you do not include an accept (permit)
statement, the router will silently discard all packets by default. This concept is identical to filtering in other
vendors' products.
user@Chicago# show
term BLOCK-MARTIANS {
204
 6. Router Management, Firewall Filters, and Accounting
from {
source-address {
127.0.0.0/8;
128.0.0.0/16;
191.255.0.0/16;
192.0.0.0/24;
223.255.255.0/24;
240.0.0.0/4;
}
}
then {
log;
syslog;
reject administratively-prohibited;
}
}
term PERMIT-OTHERS {
then accept;
}

Applying Firewall Filters to Interfaces

The last step in creating and using firewall filters is to assign them to an interface. Until you assign the filter to an
interface, it is not active on the router and is ineffective. When applying filters to an interface, you must decide
on the direction in which they are to be applied. The direction is an easy decision: You are either going to have
the router check packets coming inbound into the interface or packets trying to go outbound from the interface.
Once you have determined the direction in which to filter traffic, applying the filter is straightforward.

www.ebook-converter.com
In our sample, we are creating a filter to stop martian routes from being allowed to access the routing engine.
When using a Juniper Networks router you can restrict access to the routing engine by applying a filter to the
loopback interface. When applying our sample filter, RE-SECURE, to the loopback interface, we will choose a
direction as shown below:
[edit interfaces lo0]
user@Chicago# set unit 0 family inet filter input RE-SECURE
The completed interface and firewall filter configuration will appear in the router as follows:
}
}
lo0 {
description "ROUTING ENGINE IS ACCESSIBLE VIA THIS INTERFACE";
unit 0 {
family inet {

Downloader demo watermarks

filter {

}
input RE-SECURE;

}
}
}
205
 6. Router Management, Firewall Filters, and Accounting
}
}
firewall {
filter RE-SECURE {
term BLOCK-MARTIANS {
from {
source-address {
127.0.0.0/8;
128.0.0.0/16;
191.255.0.0/16;
192.0.0.0/24;
223.255.255.0/24;
240.0.0.0/4;
}
}
then {
log;
syslog;
reject administratively-prohibited;
}
}
term PERMIT-OTHERS {
from {
source-address {
0.0.0.0/0;
}
}

www.ebook-converter.com
then accept;
}
}
}

user@Chicago>
Remember that we can use the same filter multiple times and that the Internet Processor II from Juniper
Networks is required. Thus, if we had wanted to, we could have applied this same filter to every interface on the
router, thereby ensuring that our router never accepted invalid martian routes. The logic that we discussed in this
chapter forms the foundation for route filtering (route maps) and other ways to manipulate packets that we will
be discussing in later chapters.

IP-Packet Bit Matching

As IP routers, Juniper Networks routers are very powerful and allow you to build filters based on the following

Downloader demo watermarks

values within a packet's header:
IP options
IP fragmentation

206
 6. Router Management, Firewall Filters, and Accounting
TCP flags
ICMP (code or type)
Port number (source or destination)
Protocol (TCP or UDP)
The primary technology in use is of course TCP/IP in a Juniper Networks router. In Figure 6-10 the highlighted
fields are available to be looked at by a filter.

Figure 6-10. IP Header Fields

www.ebook-converter.com
To implement filtering based on the packet-header values, you will need to use a variety of keywords that have
been preprogrammed for you and represent the appropriate bit within the packet. These keywords always map to
a single bit value and can be used to match in either decimal or hexadecimal (if you really want to bake your
brain!). Fortunately though, there are a variety of keywords that represent common bit-field values to make filter
creation much easier (tcp-established is one such keyword).
We will discuss some of the mathematical and textual keywords in the following section, but let's first discuss
some guidelines to follow when using these terms.

Protocol Configuration Guidelines

There are several default conditions within JUNOS that affect how the router is configured. In Figure 6-11 the
highlighted fields are those available for use with filter match conditions.

Downloader demo watermarks

207
 6. Router Management, Firewall Filters, and Accounting

Figure 6-11. TCP Header Fields

When a firewall filter is configured to test a specific field in a packet, by default it does not check to ensure that
the packet being checked is an IP packet. Therefore, if you specify a filter to match on a port, TCP flag, or
ICMP, the filter is not checking to ensure the protocol type of the packet. Juniper Networks recommends that
you state explicitly the protocol (in a term statement) that you are testing to ensure a successful filter.
This is an interesting default behavior, so let's look at an example of how this will actually work. Consider that
you have created a filter that is to match on the destination port 23 (Telnet) of a TCP packet (see Figure 6-11).
The firewall filter will not look to determine what protocol the packet is; instead, it will look to determine only
the destination port being used by the packet.
There are a variety of match conditions that can be used to express the packet content. These values are listed in
Table 6-2 and are taken from Juniper Networks documentation.

www.ebook-converter.com
Table 6-2. Firewall-Filter Match Conditions

Match
Condition
(with
variables) Description
fragment- IP fragmentation flags are warranted when packets are fragmented and are identified by a
flags numeric value or name as shown below. In place of the numeric field value, you can specify one
number of the following keywords (the IP-header field values are also listed):
-dont-fragment (0x4000)
-more-fragments (0x2000)
-reserved (0x8000)
ip-options In place of the numeric value, you can specify one of the following text synonyms (the field
Downloader demo watermarks
number values are also listed):
-loose-source-route (131)
-record-route (7)

208
 6. Router Management, Firewall Filters, and Accounting
Match -router-alert (148)
Condition
(with -strict-source-route (137)
variables) Description
-timestamp (68)
tcp-flags Normally, you specify this match in conjunction with the protocol match statement to determine
number which protocol is being used on the port. In place of the numeric value, you can specify one of
the following text synonyms (the field values are also listed):
-ack (0x10)
-fin (0x01)
-push (0x08)
-rst (0x04)
-syn (0x02)
-urgent (0x20)
first- The first fragment of a fragmented packet is indicated in this match condition. When a packet is
fragment fragmented, there has to be a first one, and this is how the router detects the first. This condition
does not match unfragmented packets.
is-fragmentThis condition matches if the packet is a fragment and is usually applied in conjunction with the
first-fragment option, thereby allowing the router to filter all of the fragments of a packet and
make an action accordingly.
tcp- This condition matches TCP packets other than the first packet of a connection. This is a

www.ebook-converter.com
established synonym for (ack | rst) and is indicative of a TCP connection that has successfully
completed the three-way handshake. This condition does not implicitly check that the protocol
is TCP. To check this, specify the protocol tcp match condition. Traditionally, this match
condition is used to filter out traffic that did originate from inside a network.
tcp-initialThis condition matches the first TCP packet of a connection. This is a synonym for (syn &
!ack). This condition is used to prevent the initiation of a DoS attack; for example, attackers
may try to open many TCP connections with a host with a bogus source address, causing the
host to wait. This condition does not implicitly check that the protocol is TCP. To check this,
specify the protocol tcp match condition.
Like with regular expressions, the more detailed filters have several logical operators that can be used to
combine the filter match conditions. These operators allow you to group conditions and set a precedence of
order as Table 6-3 shows. The precedence is from the top of the table down and follows traditional mathematical
rules (i.e., the items in parenthesis are performed first, and then left to right).
Table 6-3. Firewall-Filter Logical Operators

Downloader demo watermarks

Logical Operator Description
(...) Parentheses group operators and all actions they enclose are processed first
! Negation (this means not)

& or + Logical AND

| or , Logical OR
209
| or , Logical OR 6. Router Management, Firewall Filters, and Accounting
Logical Operator Description
Using the keywords in Table 6-2 and values provided in Table 6-3, we can create some effective filter terms.
Some examples are as follows:
To negate a match, precede the value with an exclamation point. For example, a match occurs only if the
RST bit in the tcp-flags field is not set:
tcp-flags "!rst";

A match occurs if the packet is the initial packet on a TCP session:

tcp-flags "syn & !ack";

A match occurs if the packet is not the initial packet on a TCP session:
tcp-flags "!syn | ack";

Configuration Example: Blocking Telnet and SSH

We are network engineers and management has some concerns about who can access our routers. Apparently,
the security department has detected a substantial number of attempts to gain access through Telnet and SSH.
Your job as engineer 009 is to allow Telnet and SSH connections to every place, except a certain subnet, where
the financial info and payroll information for your company is held. It is very important to ensure that no one
interferes with your paycheck, so we eagerly implement a filter!
In this example, the subnet is 10.0.0.0/8, plus we want to log anyone who might be trying to access this
subnet. The filter will look as follows:

www.ebook-converter.com
[edit firewall filter VIRTUAL-ACCESS-CONTROL]
user@Chicago# show
term DENY-ACCESS {
from {
destination-address {
10.0.0.0/8;
}
protocol tcp;
port [ telnet ssh ];
}
then
log;
discard;
}
term PERMIT-ACCESS {
from {
address {
Downloader demo watermarks
}
}
0.0.0.0/0;

then accept;
}
210
 6. Router Management, Firewall Filters, and Accounting
[edit firewall filter VIRTUAL-ACCESS-CONTROL]
user@Chicago#
Now, keep in mind that those familiar with Cisco terminology might find the term DENY-ACCESS from
destination-address 10.0.0.0/8 a bit confusing because of the presence of the word from. Notice, however,
that we clarify that by choosing the destination-address keyword. Also, do not forget to apply the filter
to an interface.

Configuration Example: Blocking TFTP and Logging Occurrences

In this example, we want to clearly stop all TFTP from being used in our network, and once again, we log every
occurrence of this. This time, however, we want to send all the messages to a syslog server. Of course, in order
for this to work, we obviously will have already configured a syslog server first.
}
filter NO-TFTP {
term STOP {
from {
protocol udp;
port tftp;
}
then {
syslog;
discard;
}
}

www.ebook-converter.com
}

Additional Applications of Firewall Filters

This chapter has provided examples of the possible filters available to you with some sample configurations. The
scope of this book, however, does not support a detailed look into the many different possibilities, and you
should explore some of the following uses, as they would apply to your network and routers. Additional
information on firewall filters can be found in the Juniper Networks interfaces documentation. Please refer to the
case study for more examples.

Policing and Rate Limiting

There are times when you must police the traffic flow—be it incoming or outgoing—on an interface. This
policing is associated with many of the new CoS initiatives; however, it is still possible to use this concept as it
has been previously known, rate limiting. In fact JUNOS refers to policing and rate limiting as the same thing.

Downloader demo watermarks

You use rate limiting to limit the bandwidth on an interface to match the speed the customer is paying for. For
example, you can connect a customer to your router via a 100Mbps Fast-Ethernet interface, then rate-limit the
level of traffic you will accept, which will typically be equal to what that customer is paying for. This has the
added benefit of making it quite easy to quickly upgrade customers' speeds as they grow. Alternatively, you can
also thwart the impact of a DoS attack by rate-limiting a certain type of traffic. This chapter's case study
211
 6. Router Management, Firewall Filters, and Accounting
provides a bit more information on how to create a firewall filter to prevent a DoS attack.
JUNOS also has ability to rate limit. This is an excellent capability used by service providers all over the Internet
and around the globe. The idea behind this, as we discussed, is to sell a certain amount of bandwidth to a
customer. The connection to the customer will most likely come in the form of a much higher-bandwidth
connection, such as a Fast Ethernet or GigE, and the customer would be rate-limited down to, for example,
20Mbps or less.
When configuring rate limiting, make it as easy as possible to work going forward. The philosophy is as follows:
If there is a large-capacity router, lots of customers will be accessing it. To make the future configuration of the
router easier (when customers buy larger circuits), do a little extra work in the beginning. The first step is to
configure a prefix list for each of the five categories of service defined in Table 6-4.
Table 6-4. Comparison of Service Level
Customer Service CategoryRate Limited to Percentageof 100MB Fast-Ethernet LinkBurst Limit
Platinum 50% (50MB) 25MB
Gold 40% (40MB) 20MB
Silver 30% (30MB) 15MB
Bronze 20% (20MB) 10MB
Copper 10% (10MB) 5MB
All customers that purchase a certain level of service can easily be categorized, as the table shows. So, the first
thing to do is create a prefix-list for each of the service categories. Once they are defined, it is a simple matter to
add a specific customer's prefix to the list, instead of creating a whole new configuration for each. Consider the
following configuration scenario.

www.ebook-converter.com
The best thing to do is create and use prefix lists when configuring policing or rate limiting as this gives you the
added flexibility of just adding a customer's network prefix under the appropriate list. This, in turn, maps to a
policing statement where the actual rate limiting occurs. For this example, we enter into the [edit policy-
options] hierarchy level of the JUNOS configuration mode and create a prefix list for each of the five
categories defined previosly. Then it's a matter of applying the prefixes to each.
[edit policy-options]
user@Chicago# set prefix-list PLATINUM-CUSTOMERS
[edit policy-options prefix-list PLATINUM-CUSTOMERS]
user@Chicago# set 50.50.50.0/24
You can repeat these steps until you have created an entry for each classification and assigned a prefix. Of
course, in this configuration example, the prefixes correspond to the categories' traffic rates. When the
configuration is complete, it should look as follows:
[edit policy-options]
Downloader demo watermarks
user@Chicago# show
prefix-list PLATINUM-CUSTOMERS {
50.50.50.0/24;
}
prefix-list GOLD-CUSTOMERS {

212
 6. Router Management, Firewall Filters, and Accounting
40.40.40.0/24;
}
prefix-list SILVER-CUSTOMERS {
30.30.30.0/24;
}
prefix-list BRONZE-CUSTOMERS {
20.20.20.0/24;
}
prefix-list COPPER-CUSTOMERS {
10.10.10.0/24;
}

[edit policy-options]
user@Chicago#
Having completed the configuration of the prefix lists, the next step is to enter into the firewall configuration
hierarchy to begin building the firewall-filter statements. These statements are where the actual rate limiting is
configured. The JUNOS syntax here has us define a filter name, then name a policer, then give the actions to
take if the bandwidth is exceeded. The steps are not accomplished in quite the order that you would expect, but
we shall review the process:
1. Define the firewall filter.
2. Enter into the firewall configuration hierarchy and name the filter.
3. Define policer, transmission limits, and action.

www.ebook-converter.com
4. Name the policer so it can be referenced later; set the action (in this case, we want an action “if exceeded”);
then set the bandwidth and burst limit, as well the action to be taken (e.g., discard).
5. Configure the term statement to classify the source.
6. Create and name a term statement; assign the customer information to identify who should be subject to
the filter (in this example, we use the preceding prefix lists).
7. Assign a named policer to the term.
8. Assign the policer to the term as a then statement, thereby applying the limits and action to the identified
customer.
The following is the complete configuration using the prefix lists to identify the customer network(s) and
following the above configuration steps and explanations.
firewall {
filter PLATINUM-LIMIT {
Downloader demo watermarks
policer PLATINUM-CIR {
if-exceeding {
bandwidth-limit 50m;
burst-size-limit 25m;
}

213
 6. Router Management, Firewall Filters, and Accounting
then discard;
}
term ID-PLATINUM-CUSTOMERS {
from {
source-prefix-list {
PLATINUM;
}
}
then policer PLATINUM-CIR;
}
}
filter GOLD-LIMIT {
policer GOLD-CIR {
if-exceeding {
bandwidth-limit 40m;
burst-size-limit 20m;
}
then discard;
}
term ID-GOLD-CUSTOMERS {
from {
source-prefix-list {
GOLD;
}
}
then policer GOLD-CIR;
}

www.ebook-converter.com
}
filter SILVER-LIMIT {
policer SILVER-CIR {
if-exceeding {
bandwidth-limit 30m;
burst-size-limit 15m;
}
then discard;
}
term ID-SILVER-CUSTOMERS {
from {
source-prefix-list {
SILVER;
}
}
then policer SILVER-CIR;
}

Downloader demo watermarks

}
filter BRONZE-LIMIT {
policer BRONZE-CIR {
if-exceeding {
bandwidth-limit 20m;
burst-size-limit 10m;
214
 6. Router Management, Firewall Filters, and Accounting
}
then discard;
}
term ID-BRONZE-CUSTOMERS {
from {
source-prefix-list {
BRONZE;
}
}
then policer BRONZE-CIR;
}
}
filter COPPER-LIMIT {
policer COPPER-CIR {
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 5m;
}
then discard;
}
term ID-COPPER-CUSTOMERS {
from {
source-prefix-list {
COPPER;
}
}
then policer COPPER-CIR;

www.ebook-converter.com
}
}
}

Selectively Forward Packets

In a Juniper Networks router, it is possible to classify packets as determined by a firewall filter, then make
forwarding decisions based upon that classification. This feature is more commonly used when you have multiple
flows of traffic entering your router, and you must differentiate between them and act accordingly. Consider, for
example, a router connected at a global access point with multiple peers. This router has several customers
connected to it, each with different service level agreements and financial charges. Therefore, we filter their
traffic and forward it accordingly. This type of filtering can cover the spectrum of possibilities, from source IP
address, protocol, or even DiffServ precedence. The only limitation to this type of filter is that they can only be
applied against inbound traffic flows.

Verifying Filter Operation

Downloader demo watermarks
The actual operation of a filter must be verified. It is very important for network engineers to have such facilities
available for verification as a test lab or extra routers to practice on. This data is useful to determine that you are
achieving the desired results, obtain proof of possible security violations, and reveal misconfiguration of network
devices. To verify the operation of filters, Juniper Networks routers use interface counters.

215
 6. Router Management, Firewall Filters, and Accounting
Configuring Interface-Specific Counters
The configuration of interface counters allows for the tracking of packet matches from the firewall filter. Filters
can be used on multiple interfaces if desired, and when configuring counters, this fact must be clear as counters
are activated on a per-interface basis. To configure counters, you do not activate them in interface-configuration
mode, but rather within the firewall-configuration hierarchy, where you activate counting in the then section of
the filter, as shown in the following code. Counting enables you to count (sometimes known as log) the number
of times a filter is matched.
}
firewall {
filter FE-SECURE {
interface-specific;
term BLOCK-MARTIANS {
from {
source-address {
127.0.0.0/8;
128.0.0.0/16;
191.255.0.0/16;
192.0.0.0/24;
223.255.255.0/24;
240.0.0.0/4;
}
}
then {
count MARTIAN01;
log;

www.ebook-converter.com
}
syslog;
reject administratively-prohibited;

}
term PERMIT-OTHERS {
from {
source-address {
0.0.0.0/0;
}
}
then accept;
}
}
}
Once your filter is actively counting packets for you and has been applied to an interface, you are able to view
the packet counts. There is a catch when trying to view the counters found on the router. Juniper Networks
Downloader demo watermarks
routers append some data to the end of the log commands; the information will be the interface designation with
a dash and a letter. You can view the filename by using the show firewall log command to determine
what the actual filename is!
user@Chicago> show firewall log
Time Filter A Interface Pro Source address Destination address
216
 6. Router Management, Firewall Filters, and Accounting
15:43:39 MARTIAN01-fxp1.0-i R fxp0.0 IGM 192.168.100.1 224.0.0.1
15:43:30 MARTIAN01-fxp1.0-i R fxp0.0 TCP 192.168.254.2 192.168.254.70:23
15:43:24 MARTIAN01-fxp1.0-i R fxp0.0 TCP 192.168.254.2 192.168.254.70:23
15:43:21 MARTIAN01-fxp1.0-i R fxp0.0 TCP 192.168.254.2 192.168.254.70:23
15:40:39 MARTIAN01-fxp1.0-i R fxp0.0 IGM 192.168.100.1 224.0.0.1
15:39:27 MARTIAN01-fxp1.0-i R fxp0.0 UDP 192.168.254.69 255.255.255.255:68
15:39:27 MARTIAN01-fxp1.0-i R fxp0.0 UDP 192.168.254.69 255.255.255.255:67
15:39:19 MARTIAN01-fxp1.0-i R fxp0.0 UDP 192.168.254.69 255.255.255.255:68
You can also clear the various firewall counters with the clear firewall command as shown below:
user@Chicago> clear firewall ?
Possible completions:
all Clear all firewall counters
counter Counter name
filter Filter name

Accounting
It is a fundamental need of all networks to gather the statistics that enable effective billing. Being able to recover
your costs is key to being profitable and ultimately successful. JUNOS has two types of accounting profiles
available for your use:
1. Interface accounting
2. Firewall filters

www.ebook-converter.com
Each type is configured in a different hierarchical level in the CLI. You cannot, however, use both; you must use
one or the other. JUNOS will give you an error if you try to violate this. We are going to configure accounting
here, but a note of caution: There is not much tangible information on these features in the JUNOS
documentation, so we will do our best to make the process and results understandable.
In this configuration example, we were setting out to use accounting to count all the ICMP Echo Request &
Replies (e.g., pings) that are directed at interface fxp0, which represents the routing engine. The first thing we
configure is the accounting options, which control the creation of the actual files, which in turn record the
accounting activity as it occurs on the router. The specific configuration will allow for three files to be created.
user@Chicago# edit accounting-options

[edit accounting-options]
user@Chicago# show
file file1 {
files 3;
}

Downloader demo watermarks

While in the [edit accounting-options] configuration hierarchy, you assign the firewall-filter profile
name to be used for accounting (e.g., filter1). Once again, we reference the file to be created (e.g., file1),
which will hold the accounting data, the interval in minutes that the data is to be written to the file (e.g., one
minute), and the name of the counter the router is to draw the accounting data from (e.g., count1).

217
 6. Router Management, Firewall Filters, and Accounting
[edit accounting-options]
filter-profile filter1 {
file file1;
interval 1;
counters {
count1;
}
}
Since this is a firewall-filter-based accounting solution, we will need to configure a firewall filter to classify the
packets we wish to account for. In this example, we chose ICMP as described previously. The first part is to
create a firewall filter icmpcount and assign the name filter1 to the accounting profile. This accounting
profile name should match the filter profile name from the accounting-options configuration. We create our first
term statement (e.g., term1) to classify ICMP traffic, and then count it into the name count1, which also
corresponds to the name used in the accounting-options configuration. Then, the second term is added to allow
all other traffic through.
user@Chicago# top

[edit]
user@Chicago# edit firewall filter icmpcount

[edit firewall filter icmpcount]

user@Chicago# show
accounting-profile filter1;
term term1 {
from {

www.ebook-converter.com
icmp-type [ echo-reply echo-request ];
}

then {
count count1;
accept;
}
}
term term2 {
then accept;
}

[edit firewall filter icmpcount]

user@Chicago# top
The final aspect of configuring firewall-filter-based accounting is to assign the filter to the interface you wish
accounting to be configured on.

Downloader demo watermarks

[edit]
user@Chicago# edit interfaces fxp0

[edit interfaces fxp0]

user@Chicago# show
218
 6. Router Management, Firewall Filters, and Accounting
unit 0 {
family inet {
filter {
input icmpcount;
}
address 172.25.46.22/25;
}
}

[edit interfaces fxp0]

user@Chicago# top
Now, to see if the accounting is operating correctly, you can view the file (e.g., file1) that we configured to
receive the accounting data as shown below.
[edit]
user@Chicago# run file show /var/log/file1
#FILE CREATED 1012253230 2002-01-28-21:27:10
#hostname June01
#profile-layout filter1,epoch-timestamp,interfaces,filter-name,counter-
name,packet-count,byte-count
filter1,1012253229,fxp0.0,icmpcount,count1,68,6469
filter1,1012253289,fxp0.0,icmpcount,count1,100,9157
filter1,1012253349,fxp0.0,icmpcount,count1,160,14197
filter1,1012253409,fxp0.0,icmpcount,count1,186,16381
filter1,1012253469,fxp0.0,icmpcount,count1,186,16381
filter1,1012253529,fxp0.0,icmpcount,count1,186,16381

www.ebook-converter.com
filter1,1012253589,fxp0.0,icmpcount,count1,210,17469
filter1,1012253649,fxp0.0,icmpcount,count1,443,27339
filter1,1012253709,fxp0.0,icmpcount,count1,564,32650
filter1,1012253769,fxp0.0,icmpcount,count1,592,33794
filter1,1012253829,fxp0.0,icmpcount,count1,790,42077

[edit]
user@Chicago# exit
Exiting configuration mode
user@Chicago> exit

Chapter Summary
This chapter started with the mechanics surrounding managing a network through the use of SNMP. The
operation and history of SNMP were discussed briefly with a focus on how SNMP accomplishes the managing of
a network element. Then, some of the unique features surrounding SNMP in a Juniper Networks router and how
Downloader demo watermarks
to configure a router properly were examined.
This chapter also covered securing the router through the use of firewall filters. As you recall, this is the Juniper
Networks terminology for ACLs and packet filtering. Through the use of a firewall filter, how to configure a
router and deploy some of the advanced features was demonstrated. Some examples of how to secure a Juniper
Networks router using them were provided as well. Additionally, the use of firewall filters also provides the
219
 6. Router Management, Firewall Filters, and Accounting
ability to conduct rate limiting and traffic policing.
Many networks are now using and actively deploying accounting as a means to track traffic more efficiently.
This tracking could result in a bill for a customer or can allow for the monitoring of a circuit to an upstream
provider to ensure it is billing your network correctly.

References
Bibliography
Case Study: Securing a Juniper Networks Router
This case study has been designed to provide you with a secure template with comments that explain the various
firewall filters and other parameters. The goal of this template is to ensure that any Juniper Networks router can
be completely and fully secured. Of course, the configuration here is super safe; however, your network may
have other security tools in place already. Please feel free to alter and adjust this configuration file as needed to
meet your needs.
In Figure 6-12 we have named the Juniper Networks router secure-router-01 and placed it as the router
that connects our network to the Internet. This connection is, of course, GigE!

www.ebook-converter.com

Downloader demo watermarks

Figure 6-12. Case Study Network
220
 6. Router Management, Firewall Filters, and Accounting
As you read through this configuration, notice that we have highlighted various sections to reflect comments
placed therein. These comments are designed to help you understand the various configurations presented. The
comments are placed before the commands they will be discussing.
This configuration was developed under JUNOS 4.3R3 by Stephen R. Gill ([email protected]) to serve as a
reference and starting point for those interested in increasing the level of security on their Juniper Networks
routers, and in turn, on their networks. Its original annotations have been expanded, and it has been sourced with
express written permission from the author. Additionally, the most recent version of the template along with
other JUNOS-security-related articles can be found at www.qorbit.net.
/* ... begin template ... */
version 4.3R3;
system {
host-name secure-router-01;
/* Enable a backup router during boot for ntp. It will be used before
rpd has started or if it fails. */
backup-router 6.6.6.1 destination 7.7.7.0/24;
time-zone America/Chicago;
/* Do not send ICMP redirects */
no-redirects;
/* Use local password authentication if TACACS+ fails */
authentication-order [ tacplus password ];
location country-code US;
/* Configure authentication passwords */
diag-port-authentication {
encrypted-password "<PASSWORD>"; # SECRET-DATA
}

www.ebook-converter.com
root-authentication {
encrypted-password "<PASSWORD>"; # SECRET-DATA
}
/* Enable TACACS+ authentication. */
tacplus-server {
7.7.7.5 {
secret "<PASSWORD>"; # SECRET-DATA
/* Wait 5 seconds until timeout */
timeout 5;
}
}
login {
/* A stern Message of the Day (MOTD) banner */
message “********************************************************\n
* [WARNING] secure-router-01 *\n
* This system is owned by [COMPANY]. If you are not *\n
* authorized to access this system, exit immediately. *\n

Downloader demo watermarks

* Unauthorized access to this system is forbidden by *\n
* company policies, national, and international laws. *\n
* Unauthorized users are subject to criminal and civil *\n
* penalties as well as company initiated disciplinary *\n
* proceedings. *\n
* *\n
221
 6. Router Management, Firewall Filters, and Accounting
* By entry into this system you acknowledge that you *\n
* are authorized access and the level of privilege you *\n
* subsequently execute on this system. You further *\n
* acknowledge that by entry into this system you *\n
* expect no privacy from monitoring. *\n
********************************************************\n";
/* Configure an administrator class with all privileges. We cannot
modify the predefined classes, so we must create our own. */
class admin {
/* Causes telnet sessions to time out after 15 minutes of inactivity
*/
idle-timeout 15;
permissions all;
}
/* Configure a view-only account – especially good for use by junior
engineers or directors */
class view-only {
idle-timeout 15;
permissions [ configure firewall interface network routing snmp
system trace view];
}
/* This is a superuser account */
user admin {
full-name Administrator;
uid 2000;
class admin;
authentication {

www.ebook-converter.com
encrypted-password "<PASSWORD>"; # SECRET-DATA
}
}
/* This is a view-only user account */
user ops {
full-name Operations;
uid 2001;
class view-only;
authentication {
encrypted-password "<PASSWORD>"; # SECRET-DATA
}
}
/* This is the template account used by TACACS+ and MUST be here.
TACACS+ is limited to 1 template account, RADIUS can have many */
user remote {
full-name "All remote users";
uid 9999;

Downloader demo watermarks

}
}
class admin;

/* List of IPs and their hostnames to allow easy English reference to the
devices within the network */
static-host-mapping {
222
 6. Router Management, Firewall Filters, and Accounting
/* Put localhost entry for NTP to work */
localhost inet 127.0.0.1;
firewall-ext inet 6.6.6.1;
firewall-int inet 7.7.7.1;
upstream inet 5.5.5.1;
utility inet 7.7.7.5;
syslog inet 7.7.7.8;

}
/* Enable router services */
services {
/* Enable 5 ssh sessions. Max 10 connection attempts per minute. */
ssh connection-limit 5 rate-limit 10;
}
syslog {
/* Archive old files up to 10MB total (1 MB per file), thereby giving
a good historical view of what is happening on the router*/
archive size 1m files 10;
user * {
any emergency;
}
/* Transmit log data over to the corporate syslog server */
host 7.7.7.8 {
any info;
}
file messages {
any notice;

www.ebook-converter.com
authorization info;
}
}
/* Synchronize the clock with a trusted authenticated NTP server */
ntp {
authentication-key 6767 type md5 value "<PASSWORD>"; # SECRET-DATA
/* NTP will not sync if times are too different, so remember to set
the router's time at bootup */
boot-server 7.7.7.5;
server 7.7.7.5;

}
}
chassis {
/* Disable source routing */
no-source-route;
}

Downloader demo watermarks

interfaces {
/* Log additional interface information to aid in troubleshooting. To
view, use 'show log log-interfaces' */
traceoptions {
/* Rotate through 5 files at 1MB each */
file log-interfaces size 1m files 5;
223
 6. Router Management, Firewall Filters, and Accounting
/* Trace changes that produce configuration events */
flag change-events;
}
ge-0/0/0 {
description "Upstream Interface - facing Internet";
/* Enable snmp-traps for this interface */
traps;
link-mode full-duplex;
unit 0 {
family inet {
/* Do not send ICMP redirect messages */
no-redirects;
/* Filter inbound packets from the Internet */
filter {
input inbound-filter;
}
address 5.5.5.254/24;
}
}
}
ge-0/1/0 {
description "Protected Interface - facing DMZ"
traps;
link-mode full-duplex;
unit 0 {
family inet {
no-redirects;

www.ebook-converter.com
/* Filter outbound packets from the internal network */
filter {
input outbound-filter;
}
address 6.6.6.254/24;
}
}
}
/* Configure management interface. Cannot route over this. */
fxp0 {
description "Management Interface – OOB management"
unit 0 {
family inet {
no-redirects;
address 10.10.11.11/24;
}
}

Downloader demo watermarks

}
/* Configure loopback interface. Used for routing protocols and other
purposes. */
lo0 {
description "Loopback Interface – internal"
unit 0 {
224
 6. Router Management, Firewall Filters, and Accounting
family inet {
no-redirects;
/* Restrict connections coming to this router */
filter {
input router-protect;
}
address 10.10.10.10/32;
}
}
}
}
forwarding-options {
/* Enable packet sampling for CflowD */
sampling {
input {
family inet {
/* Sample 1 out of 100 packets + next 4 in sequence.
Total = 4/100 packets. You may want to just sample
the SYN/FIN packets instead. */
rate 100;
run-length 4;
/* This is a built-in max throttle, listed here for
completeness */
max-packets-per-second 7000;
}
}
/* Send the output to the designated CflowD collector using v 8 */

www.ebook-converter.com
output {
cflowd 7.7.7.5 {
port 2055;
version 8;
no-local-dump;
autonomous-system-type origin;
aggregation {
autonomous-system;
}
}
}
}
}
snmp {
description secure-router-01;
location "Site, Row, Rack, Shelf";
contact "(555) 555-5555";

Downloader demo watermarks

/* Restrict SNMP requests to a particular interface */
interface ge-0/1/0.0;
/* Configure the SNMP community. Replace COMMUNITY with your string */
community COMMUNITY {
authorization read-only;
/* Determine who is allowed access via SNMP */
225
 6. Router Management, Firewall Filters, and Accounting
clients {
default restrict;
/* Restrict access to ALL but the following */
7.7.7.5/32;
}
}
/* Send traps using v2 for all categories to designated trap server */
trap-group all {
version v2;
categories authentication chassis link routing startup;
targets {
7.7.7.5;
}
}
}
routing-options {
options {
/* Turn off DNS resolution */
no-resolve;
syslog {
level debug;
}
}
/* Configure static routes */
static {
/* Default route out to the Internet */
route 0.0.0.0/0 next-hop 5.5.5.1;

www.ebook-converter.com
/* Route to network on the other side of the Firewall */
route 7.7.7.0/24 next-hop 6.6.6.1;
/* Black-hole routes for traffic destined to these networks */
route 0.0.0.0/8 discard;
route 1.0.0.0/8 discard;
route 2.0.0.0/8 discard;
route 5.0.0.0/8 discard;
route 7.0.0.0/8 discard;
route 10.0.0.0/8 discard;
route 23.0.0.0/8 discard;
route 27.0.0.0/8 discard;
route 31.0.0.0/8 discard;
route 36.0.0.0/8 discard;
route 37.0.0.0/8 discard;
route 39.0.0.0/8 discard;
route 41.0.0.0/8 discard;
route 42.0.0.0/8 discard;

Downloader demo watermarks

route 49.0.0.0/8 discard;
route 50.0.0.0/8 discard;
route 58.0.0.0/8 discard;
route 59.0.0.0/8 discard;
route 60.0.0.0/8 discard;
route 69.0.0.0/8 discard;
226
 6. Router Management, Firewall Filters, and Accounting
route 70.0.0.0/8 discard;
route 71.0.0.0/8 discard;
route 72.0.0.0/8 discard;
route 73.0.0.0/8 discard;
route 74.0.0.0/8 discard;
route 75.0.0.0/8 discard;
route 76.0.0.0/8 discard;
route 77.0.0.0/8 discard;
route 78.0.0.0/8 discard;
route 79.0.0.0/8 discard;
route 82.0.0.0/8 discard;
route 83.0.0.0/8 discard;
route 84.0.0.0/8 discard;
route 85.0.0.0/8 discard;
route 86.0.0.0/8 discard;
route 87.0.0.0/8 discard;
route 88.0.0.0/8 discard;
route 89.0.0.0/8 discard;
route 90.0.0.0/8 discard;
route 91.0.0.0/8 discard;
route 92.0.0.0/8 discard;
route 93.0.0.0/8 discard;
route 94.0.0.0/8 discard;
route 95.0.0.0/8 discard;
route 96.0.0.0/8 discard;
route 97.0.0.0/8 discard;
route 98.0.0.0/8 discard;

www.ebook-converter.com
route 99.0.0.0/8 discard;
route 100.0.0.0/8 discard;
route 101.0.0.0/8 discard;
route 102.0.0.0/8 discard;
route 103.0.0.0/8 discard;
route 104.0.0.0/8 discard;
route 105.0.0.0/8 discard;
route 106.0.0.0/8 discard;
route 107.0.0.0/8 discard;
route 108.0.0.0/8 discard;
route 109.0.0.0/8 discard;
route 110.0.0.0/8 discard;
route 111.0.0.0/8 discard;
route 112.0.0.0/8 discard;
route 113.0.0.0/8 discard;
route 114.0.0.0/8 discard;
route 115.0.0.0/8 discard;

Downloader demo watermarks

route
route
route
116.0.0.0/8 discard;
117.0.0.0/8 discard;
118.0.0.0/8 discard;
route 119.0.0.0/8 discard;
route 120.0.0.0/8 discard;
route 121.0.0.0/8 discard;
227
 6. Router Management, Firewall Filters, and Accounting
route 122.0.0.0/8 discard;
route 123.0.0.0/8 discard;
route 124.0.0.0/8 discard;
route 125.0.0.0/8 discard;
route 126.0.0.0/8 discard;
route 127.0.0.0/8 discard;
route 169.254.0.0/16 discard;
route 172.16.0.0/12 discard;
route 192.0.2.0/24 discard;
route 192.168.0.0/16 discard;
route 197.0.0.0/8 discard;
route 201.0.0.0/8 discard;
route 220.0.0.0/8 discard;
route 221.0.0.0/8 discard;
route 222.0.0.0/8 discard;
route 223.0.0.0/8 discard;
route 240.0.0.0/4 discard;
}
}
policy-options {
prefix-list iana-reserved {
/* IANA reserved networks that are not supposed to be in use */
0.0.0.0/8;
1.0.0.0/8;
2.0.0.0/8;
5.0.0.0/8;
7.0.0.0/8;

www.ebook-converter.com
23.0.0.0/8;
27.0.0.0/8;
31.0.0.0/8;
36.0.0.0/8;
37.0.0.0/8;
39.0.0.0/8;
41.0.0.0/8;
42.0.0.0/8;
49.0.0.0/8;
50.0.0.0/8;
58.0.0.0/8;
59.0.0.0/8;
60.0.0.0/8;
69.0.0.0/8;
70.0.0.0/8;
71.0.0.0/8;
72.0.0.0/8;

Downloader demo watermarks

73.0.0.0/8;
74.0.0.0/8;
75.0.0.0/8;
76.0.0.0/8;
77.0.0.0/8;
78.0.0.0/8;
228
 6. Router Management, Firewall Filters, and Accounting
79.0.0.0/8;
82.0.0.0/8;
83.0.0.0/8;
84.0.0.0/8;
85.0.0.0/8;
86.0.0.0/8;
87.0.0.0/8;
88.0.0.0/8;
89.0.0.0/8;
90.0.0.0/8;
91.0.0.0/8;
92.0.0.0/8;
93.0.0.0/8;
94.0.0.0/8;
95.0.0.0/8;
96.0.0.0/8;
97.0.0.0/8;
98.0.0.0/8;
99.0.0.0/8;
100.0.0.0/8;
101.0.0.0/8;
102.0.0.0/8;
103.0.0.0/8;
104.0.0.0/8;
105.0.0.0/8;
106.0.0.0/8;
107.0.0.0/8;

www.ebook-converter.com
108.0.0.0/8;
109.0.0.0/8;
110.0.0.0/8;
111.0.0.0/8;
112.0.0.0/8;
113.0.0.0/8;
114.0.0.0/8;
115.0.0.0/8;
116.0.0.0/8;
117.0.0.0/8;
118.0.0.0/8;
119.0.0.0/8;
120.0.0.0/8;
121.0.0.0/8;
122.0.0.0/8;
123.0.0.0/8;
124.0.0.0/8;

Downloader demo watermarks

125.0.0.0/8;
126.0.0.0/8;
127.0.0.0/8;
169.254.0.0/16;
192.0.2.0/24;
197.0.0.0/8;
229
 6. Router Management, Firewall Filters, and Accounting
201.0.0.0/8;
220.0.0.0/8;
221.0.0.0/8;
222.0.0.0/8;
223.0.0.0/8;
/* Multicast and Experimental */
224.0.0.0/3;
}
prefix-list rfc1918 {
/* RFC 1918 addresses */
10.0.0.0/8;
192.168.0.0/16;
172.16.0.0/12;
}
}
firewall {
filter inbound-filter {
/* Rate-limit for 5 m/s used for multicast */
policer 5m {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 375k;
}
then discard;
}
/* Rate-limit for 500 k/s used for ICMP */
policer 500k {

www.ebook-converter.com
if-exceeding {
bandwidth-limit 500k;
burst-size-limit 62k;
}
then discard;
}
/* Rate-limit for 2 m/s used for UDP */
policer 2m {
if-exceeding {
bandwidth-limit 2m;
burst-size-limit 250k;
}
then discard;
}
/* The first three terms have been separated for accounting only */
term 1 {
from {

Downloader demo watermarks

source-address {
/* Spoof of inside networks */
6.6.6.0/24;
7.7.7.0/24;
}
}
230
 6. Router Management, Firewall Filters, and Accounting
then {
/* Count spoofed traffic. Type 'show firewall' to view */
count spoof-inbound-internal;
log;
discard;
}
}
/* The following prefix-list can be divided for finer granularity */
term 2 {
from {
prefix-list {
iana-reserved;
}
}
then {
count spoof-inbound-iana;
log;
discard;
}
}
term 3 {
from {
prefix-list {
rfc1918;
}
}
then {

www.ebook-converter.com
count spoof-inbound-rfc1918;
log;
discard;
}
}
/* Discard all ICMP fragments */
term 4 {
from {
is-fragment;
protocol icmp;
}
then {
count icmp-fragments;
log;
discard;
}
}

Downloader demo watermarks

/* Rate-limit ICMP traffic to 500 k/s */
term 5 {
from {
protocol icmp;
}
then {
231
 6. Router Management, Firewall Filters, and Accounting
count policer-icmp-500k;
policer 500k;
}
}
/* Rate-limit Multicast traffic to 5 m/s */
term 6 {
from {
destination-address {
224.0.0.0/4;
}
protocol udp;
}
then {
count policer-multicast-5m;
policer 5m;
accept;
}
}
/* Rate-limit other UDP traffic to 2 m/s */
term 7 {
from {
protocol udp;
}
then {
count policer-udp-2m;
policer 2m;
}

www.ebook-converter.com
}
/* Allow access to Intranet (firewall filters specific ports) */
term 8 {
from {
destination-address {
7.7.7.0/24;
}
}
then accept;
}

/* Our explicit (read: logged) drop all rule */

term 9 {
then {
log;
discard;
}

Downloader demo watermarks

}
}

/* Be a good netizen by preventing spoofing from within the network.

You may wish to add further 'terms' if more access is required. */
filter outbound-filter {
term 1 {
232
 6. Router Management, Firewall Filters, and Accounting
from {
source-address {
7.7.7.0/24;
6.6.6.1/32;
}
}
then accept;
}
term 2 {
then {
count spoof-outbound;
log;
discard;
}
}
}
/* You may apply this filter outbound on fxp0 to count and compare
TCP and TCP-SYN traffic. This can be used to detect a SYN-Flood
if you suspect you are under attack. A high 'packets-syn' to
'packets-tcp' ratio could be a good indicator. TCP-intercept is
not supported. */
filter syn-flood-detect {
term 1 {
from {
protocol tcp;
tcp-flags syn;
}

www.ebook-converter.com
then {
count packets-syn;
log;
accept;
}
}
term 2 {
from {
protocol tcp;
}
then {
count packets-tcp;
accept;
}
}
}
/* Apply this filter inbound on interface loopback 0 in order to restrict

Downloader demo watermarks

ssh, ntp,
and snmp connections destined to this router. You may wish to
add entries for ICMP, FTP, BGP, VRRP, TACACS+, etc. */
filter router-protect {
term 1 {
from {
233
 6. Router Management, Firewall Filters, and Accounting
/* Allow access from firewall, syslog, and utility server */
source-address {
0.0.0.0/0;
6.6.6.1/32 except;
7.7.7.5/32 except;
7.7.7.8/32 except;
}
protocol tcp;
destination-port ssh;
}
then {
count manage-discard-tcp;
log;
discard;
}
}
term 2 {
from {
/* Allow access from designated SNMP and NTP servers */
source-address {
0.0.0.0/0;
7.7.7.5/32 except;
}
protocol udp;
destination-port [ snmp ntp ];
}
then {

www.ebook-converter.com
count manage-discard-udp;
log;
discard;
}
}

Downloader demo watermarks

234
[ch06bib01] Juniper Networks. “Fortifying the Core.” September 2000, at
www.juniper.net/techcenter/app_note/350002.html.
[ch06bib02] Juniper Networks. “Minimizing the Effects of DoS Attacks.” November
2000, at www.juniper.net/techcenter/app_note/350001.html.
[ch06bib03] Stephen Gill,. “JUNOS Secure BGP Template.” October 2001, at
www.qorbit.net/documents/junos-bgp-template.pdf.
[ch06bib04] Rob Thomas,. “Cisco Secure IOS Template.” June 2001, at
www.cymru.com/~robt/Docs/Articles/secure-ios-template.html.
[ch06bib05] Rob Thomas,. “Cisco Secure BGP Template.” June 2001, at
www.cymru.com/~robt/Docs/Articles/secure-bgp-template.html.
[ch06bib06] www.qorbit.net
[ch06bib07] www.juniper.net

www.ebook-converter.com

Downloader demo watermarks

235
[ch06rfc792] IETF RFC—RFC 792, Internet Control Message Protocol (ICMP). J.
Postel. 1981.
[ch06rfc2474] IETF RFC—RFC 2474, Definition of the Differentiated Services (DS)
Field. K. Nichols, et al. 1998.
[ch06rfc2475] IETF RFC—RFC 2475, An Architecture for Differentiated Services. S.
Blake, et al. 1998.
[ch06rfc2597] IETF RFC—RFC 2597, Assured Forwarding PHB. J. Heinanen, 1999.
[ch06rfc2598] IETF RFC—RFC 2598, An Expedited Forwarding PHB. V. Jacobson, K.
Nichols, K. Poduri. 1999.
[ch06bib13] Douglas R. Mauro,, and Kevin J. Schmidt. Essential SNMP. O'Reilly &
Associates, <year>2001</year>.
[ch06bib14] P. Miller,, and M. Miller, Managing Internetworks with SNMP, 3rd ed. John
Wiley & Sons, <year>1999</year>.
[ch06bib15] www.juniper.net/techpubs/mibs.html

www.ebook-converter.com
[ch06bib16] www.snmp.com

Downloader demo watermarks

236
 7. Interface Configuration
Chapter 7. Interface Configuration
Webster's Dictionary defines the word interface as “the place at which independent and often unrelated systems meet and act
on or communicate with each other.” Interfaces allow communications between two entities. Examples of interfaces include
the keyboard, mouse, and monitor of your PC; they allow you to communicate with your computer. Layers of the OSI model
have standardized interfaces that allow communication up and down the protocol stack. Routers have interfaces that allow
communication to and through them. These router interfaces can be physical or virtual; for example, a virtual interface is used
as a logical process.
A router interface can also be known as a port, which also allows communication to another router or switch. An example is a
console port on a Juniper Networks router that is designed to allow direct communication to the Internet processor. All
interfaces and ports have the same function: to enable communication.
Interfaces are used to connect the router to other routers, network switches, or computers. Earlier chapters have demonstrated
how routers are installed, accessed, and maintained. This chapter will discuss and illustrate how to enable the router to
communicate with other devices—connecting and configuring two routers to form a communications link.
Juniper Networks routers have feature-rich interface implementations. In this chapter, the available interface types and their
configuration will be discussed. Virtual Router Redundancy Protocol (VRRP), MAC address filtering, VLAN support, QoS,
CoS, and automatic protection switching (APS) are just some of the features supported by Juniper Networks interfaces that will
be discussed here.

Introduction to Interfaces
The interfaces on a router are used to communicate with other connected network devices. Interfaces come in many different
types and speeds. Interfaces for Juniper Networks routers can be electrical or optical, and they can range in speed from
thousands to tens of billions of bits per second, depending on the need.
A router uses interfaces to connect to physically external devices. In addition, a router has some interfaces that are internal

www.ebook-converter.com
virtual interfaces to assist the Internet processor. These interfaces are created in router memory and cannot be physically
touched.
Juniper Networks routers support a diverse set of physical interfaces, or ports, that can accommodate the needs of most ISPs
and large-enterprise networks. The range in available bandwidths of interfaces for a Juniper Networks router is currently DS-0
(DS-3 with channels down to the 64Kbps level) to OC-192 (10Gbps). In addition to the wide range of bandwidths offered,
Juniper Networks offers a variety of different types of interfaces. POS, ATM, Fast Ethernet, and GigE are just some of the
different interfaces Juniper Networks offers for its routers. Physical interfaces technically also include the console interface
because it enables communications from outside the router. The list of available interfaces grows constantly as technology is
enhanced and bandwidth requirements increase.
Internal virtual router interfaces are created in memory and in the processes of the routing engine. Virtual interfaces serve a
variety of purposes, including acting as points for forwarding data in a manner similar to physical interfaces. One very
important virtual interface is the loopback interface. The loopback interface can be used for giving a router a stable IP address
for identity. Other virtual interfaces can include generic route encapsulation (GRE) and IP-IP tunnel interfaces. These types of
interfaces are internal to the Internet processor and are used to set up virtual connections to other routers with tunnel interfaces
for data forwarding. Some virtual interfaces, such as the GRE and IP-IP tunnel interfaces, require specialized hardware to
implement.

Downloader demo watermarks

Logical Units
The discussion on ATM in Section 2.2.2.9 discussed how some technologies have the ability to create many logical interfaces
that are assigned as part of one physical interface. This feature allows many different networks to be configured on one
physical port. These logical interfaces are called logical units. Each of the logical units on a port, or physical interface, has
features that can be configured independently of the other logical units. In addition, there are some global features that are
237
 7. Interface Configuration
configured on the physical interface that affect all the logical units at once. Juniper Networks assigns these logical unit
properties to a physical port. By creating different units, different properties can be assigned to each unit. Logical units are
known as subinterfaces with other vendors.
For example, in Figure 7-1, each of the three routers has a physical connection to an ATM switch. Router New York has two
configured logical units, one for each virtual circuit. One logical unit's data is switched via VPI/VCI to Chicago and the other to
Boston. Since these logical units are configured for different IP subnets, router New York has two network connections on one
physical interface. Any data destined for router Chicago from New York will leave New York from unit 128 with a different
VPI/VCI pair than unit 50, which would forward data towards router Boston. This logical use of units in JUNOS provides you
with a way to group different units that belong to a physical interface logically.

Figure 7-1. Physical and Logical Interfaces

www.ebook-converter.com
The physical port on router New York must be properly configured to communicate with the switch; otherwise, the logical
units will not be able to communicate properly with the other routers. Once the physical communication is working, then the
logical interfaces can be configured. In practice, both are configured at the same time or one at a time, but the important thing
to remember is that the logical unit is dependent on the physical interface.

Interface Naming and Numbering

Juniper Networks interface cards are called PICs and house the actual physical interface ports. PICs are carried on FPCs. A
PIC can contain only the one type of port, but different types of PICs can be installed in an FPC as explained in Chapter 3.
In Figure 7-2, an FPC is illustrated with two different PICs installed and two blank PIC slots. The FPC is the carrier card that
houses the PICs. Each PIC is made up of physical interfaces. For example, a one-port OC-12 ATM PIC could be installed in
the same FPC as a four-port OC-3 POS PIC.

Downloader demo watermarks

238
 7. Interface Configuration

Figure 7-2. PICs in an FPC

Juniper Networks currently has two routers that have the FPCs inserted into slots vertically and one router that has the FPCs
inserted horizontally. The FPCs in the M40 and M160 are inserted vertically and the M20 has the FPCs inserted horizontally.
The M5 and M10 do not use a removable FPC slot; the PICs can be inserted and removed individually, but the slots are called
FEBs. For the M20, M40, and M160, PICs are inserted first into the FPC; then, the full FPC is inserted into the appropriate slot

www.ebook-converter.com
on the router.
Since different types of PICs have different configuration parameters and characteristics, a way of differentiating between the
types of PICs must be used. To identify which type of PIC is being configured, Juniper Networks uses JUNOS software
designation codes listed in Table 7-1.
Table 7-1. Interface Types and JUNOS Software Designations

Type of Interface PICJUNOS CLI Designation

ATM At
E1 E1
E3 E3
Fast Ethernet Fe
GigE Ge
GRE tunnel gr
IP-IP tunnel ip
POS so
DS1POS t1 so

Downloader demo watermarks

DS3DS1
DS3
t3 t1
t3
Because there can be multiple FPCs, PICs, interfaces, and logical units (identified as units), each type is represented a little
differently in JUNOS for interface identification. For example:
“type”-x/y/z.a
239
 7. Interface Configuration
In this format
“type” is the type of interface that is referenced.
x is the slot position in which the FPC is inserted.
y is the PIC position on the FPC.
z is the port on the PIC.
a is the logical interface number (unit).
An example of a full interface name would be at-3/3/0.75. This represents an ATM interface, in FPC slot 3, in PIC 3, port
0, logical unit 75. The unit number is an arbitrary number from 0 to 16,384. Some interface encapsulations only support unit 0
(e.g., POS interfaces running PPP), while others support multiple units (e.g., ATM interfaces). When in configuration mode,
you can use the show command to see the output for the logical interface configuration, which is separated by unit, as is
shown below. The unit 75, has one set of parameters while unit 105 has another. The parameters in this case are the different
VCI assignments and the different IP network address, as we can see in the following code output:
[edit interfaces at-3/3/0]
lab@Boston# show
atm-options {
vpi 0 maximum-vcs 150;
}
unit 75 {
point-to-point;
vci 75;
family inet {
address 192.168.75.1/30;
}
}

www.ebook-converter.com
unit 105 {
vci 105;
family inet {
address 192.168.105.1/30;
}
}

[edit interfaces at-3/3/0]

lab@Boston#
When referring to a specific logical unit or showing interface statistics and its respective status, the decimal notation is used.
The command show interfaces (interfaces) can be used to show and observe information about the link status and
characteristics of the specified interface, as is shown in the following command output. Notice that the main physical interface
is shown, and then the logical units associated with it are displayed.
lab@Boston> show interfaces at-3/3/0
Physical interface: at-3/3/0, Enabled, Physical link is Up
Interface index: 24, SNMP ifIndex: 48
Link-level type: ATM-PVC, MTU: 4482, Clocking: Internal, SONET mode,

Downloader demo watermarks

Speed: OC3, Loopback: None, Payload scrambler: Enabled
Device flags
Link flags
Input rate
: Present Running
: None
: 0 bps (0 pps)
Output rate : 0 bps (0 pps)
SONET alarms : None
SONET defects : None
240
 7. Interface Configuration
Logical interface at-3/3/0.75 (Index 4) (SNMP ifIndex 50)
Flags: Point-To-Point SNMP-Traps Encapsulation: ATM-SNAP
Input packets : 0
Output packets: 0
Protocol inet, MTU: 4470, Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 192.168.75.0/30, Local: 192.168.75.1
VCI 0.75
Flags: Active
Total down time: 0 sec, Last down: Never
Traffic statistics:
Input packets: 0
Output packets: 0
Logical interface at-3/3/0.105 (Index 5) (SNMP ifIndex 51)
Flags: Point-To-Point SNMP-Traps Encapsulation: ATM-SNAP
Input packets : 0
Output packets: 0
Protocol inet, MTU: 4470, Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 192.168.105.0/30, Local: 192.168.105.1
VCI 0.105
Flags: Active
Total down time: 0 sec, Last down: Never
Traffic statistics:
Input packets: 0
Output packets: 0

lab@Boston>

www.ebook-converter.com
To find out which physical PICs are installed in the router, the show chassis hardware command can be used. As shown
here, when the command is run on router Boston, the various PICs installed in FPCs 0, 2, and 3 are shown below each FPC
entry:
[edit]
lab@Boston# run show chassis hardware
Hardware inventory:
Item Version Part number Serial number Description
Chassis 20797 m40
Backplane REV 02 710-001348 AB6859
Power supply A REV 04 740-000234 000963 AC
Power supply B REV 04 740-000234 000961 AC
Maxicab REV 07 710-000229 AF8436
Minicab REV 03 710-000482 AE9763
Display REV 08 710-000150 AE9963
Host Present
SCB REV 02 710-001838 AF7654 Internet Processor II
FPC 0 REV 10 710-000175 AA4830
PIC 0 REV 06 750-000616 AA6736 1x OC-12 ATM, MM

Downloader demo watermarks

PIC 1
PIC 2
FPC 2
REV 06
REV 07
REV 01
750-000616
750-002303
710-001292
AA5469
AK8035
AH4745
1x OC-12 ATM, MM
4x F/E, 100 BASE-TX
PIC 0 REV 02 750-001020 AD4661 1x OC-12 SONET, MM
PIC 1 REV 02 750-000618 AB1174 4x T3
PIC 2 REV 03 750-000611 AC0856 4x OC-3 SONET, MM

241
 7. Interface Configuration
FPC 3 REV 09 710-000175 AA6064
PIC 3 REV 03 750-000612 AA1774 2x OC-3 ATM, MM
Looking at the output, you can now differentiate the name assignments of the FPCs, PICs, interfaces, and logical units.

Position Numbering
The position and numbering of an FPC and a PIC can be a bit confusing and needs some explanation. The numbering changes
not only on the position the card holds in the router, but it also depends on the router that you are using, as we will explain in
the next section.

FPC and PIC Numbering for the M40 and M160

For the M40 and M160, the vertical FPC slots are numbered from left to right, 0 to 7 (the SCB slot on the M40 is not counted).
PICs in the FPCs are counted top to bottom. Four standard PICs can fit into an FPC, so they are numbered 0 to 3. Lastly the
ports are numbered, starting upper right in the PIC, and are counted down, moving from the upper left down. In Figure 7-3,
FPCs are installed with various PICs in an M40. Using the FPC/PIC/port format, the gray port is assigned 2/2/0. The shaded
port is assigned 0/2/2.

Figure 7-3. M40 Interface Assignment

www.ebook-converter.com
If there are only two ports in a PIC, the assignment number starts at 0 for the top port and the bottom will be 1. If there is only
one interface port on a PIC, then the port assignment is 0.

FPC and PIC Numbering for the M5, M10, and M20
The M5, M10, and M20 routers have much smaller chassis than the M40 and M160. The FPC slots are inserted horizontally to
ensure proper airflow. The FPC slots are numbered top to bottom; the PICs are numbered right to left. The ports are numbered
left to right, bottom to top starting at the bottom right and moving left. All Juniper Networks router-numbering schemes begin
with 0. Figure 7-4 illustrates the interface assignment for the horizontal chassis of the M20. The gray port is assigned the
number 0/3/0 and the shaded port is assigned the number 1/2/3.

Downloader demo watermarks

Figure 7-4. M20 Interface Assignment
With the M5 only having one FPC slot, the assignment for that slot is 0. Although it seems somewhat complicated to
remember, the M5/10/20 port numbering scheme is the same as that for the M40/M160 with your head tilted to the left.

242
 7. Interface Configuration
Interface Configuration Basics
Configuration commands for router interfaces in JUNOS software are located in the [edit interfaces (interface)]
command hierarchy of the command-line interface, where (interface) represents the interface you wish to configure. Both
the physical ports and logical units are configured from this hierarchy level. As you can see below, the configurable transient
physical interfaces, which already have some elements configured on router New York are shown. In addition, loopback0
(lo0) and the management fxp0 are listed.
[edit interfaces]
lab@newyork# set ?
Possible completions:
<interface_name> Interface name
+ apply-groups Groups from which to inherit configuration data
at-0/1/0
at-0/1/1
fe-0/0/0
fe-0/0/1
fe-0/0/3
fxp0
ge-0/2/0
ge-0/3/0
lo0
so-0/3/0
> traceoptions Interface trace options
[edit interfaces]
lab@newyork#
To configure a logical unit, the hierarchy for the physical interface that will carry that logical unit must be entered. To edit the
ATM interface for port 0/1/1 or to configure logical units on 0/1/1, the set commands must be entered. For this example, the
prompt was moved to the directories where the commands were located to show the possible command completions.

www.ebook-converter.com
[edit interfaces]
lab@newyork# edit at-0/1/1

[edit interfaces at-0/1/1]

lab@newyork# set ?
Possible completions:
accounting-profile Accounting profile name
+ apply-groups Groups from which to inherit configuration data
> atm-options ATM interface-specific options
clocking Interface clock source
description Text description of interface
disable Disable this interface
> e3-options E3 interface-specific options
encapsulation Physical link-layer encapsulation
> hold-time Hold time for link up and link down
mtu Maximum transmit packet size (256..9192)
no-traps Don't enable SNMP notifications on state changes
> sonet-options SONET interface-specific options

Downloader demo watermarks

> t3-options
> traceoptions
traps
> unit
T3 interface-specific options
Interface trace options
Enable SNMP notifications on state changes
Logical interface
[edit interfaces at-0/1/1]
lab@newyork#

243
 7. Interface Configuration
Changes made to the configuration of a physical interface will affect both the interface and all logical units created on it. For
example, if you use the set disable command on the physical interface, no logical units on the physical interface will be
able to communicate.

Logical Units Configuration

Logical units are noted by the number after the period in the naming scheme. For example, a logical unit designated at-
0/1/1.100 would be logical unit 100 of the ATM interface in 0/1/1. The range of possible logical unit numbers from 0 to
16,384 is shown below:
[edit interfaces at-0/1/1]
lab@newyork# set unit ?
Possible completions:
<interface_unit_number> Logical unit number (0..16384)
[edit interfaces at-0/1/1]
lab@newyork# set unit 380
It is common practice to try to associate the logical unit number with something about the network for which that the logical
unit will be configured. For instance, if an ATM logical unit were to be configured on a PVC with a VPI/VCI of 3:80, the unit
number could be configured as 380 for that particular logical unit. This can assist with troubleshooting or statistics gathering.
Once the logical unit is assigned a unit number, all of the logical network parameters for that logical unit can be configured.
Some of the parameters that can be configured on a logical unit are protocol family address assignment, the DLCI or VPI/VCI
assignments for NBMA PVCs, and packet filtering. If no unit configuration is required, such as when using a Fast Ethernet port
to connect a single network, a unit still has to be defined. In this instance, unit 0 must be used.

Network Addressing
Although there are several types of protocol families and addresses that can be assigned to a logical unit, the discussion in this
chapter will discuss IP network addressing (known as family inet). The other family addresses, such as MPLS and ISO, will be

www.ebook-converter.com
discussed in their respective protocol chapters. The IP protocol family is assigned to a unit using the command inet, and then
an IP address can be assigned under that family as shown below:
[edit interfaces fe-0/0/3 unit 0]
lab@newyork# set family ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
> inet Internet protocol (IPv4) parameters
> iso OSI ISO protocol parameters
> mpls MPLS protocol parameters
[edit interfaces fe-0/0/3 unit 0]
lab@newyork# set family
Once you are in the unit hierarchy of the logical unit, the command to add an IP address is set family inet address
(address/mask), as is demonstrated next:
[edit interfaces fe-0/0/3 unit 0]
lab@newyork# set family inet address 192.168.50.5/24

Downloader demo watermarks

[edit interfaces fe-0/0/3 unit 0]
lab@newyork# show
family inet {
address 192.168.50.5/24;
}

[edit interfaces fe-0/0/3 unit 0]

244
 7. Interface Configuration
lab@newyork#
The main thing to remember is that the protocol family has to be assigned on a logical unit to enable the protocol on that logical
unit.

Ethernet, Fast Ethernet, and GigE Interfaces

Ethernet is the most widely used LAN protocol. Juniper Networks routers have PICs that support both Ethernet at 10Mbps and
Fast Ethernet at 100Mbps, while certain PICs only support 100Mbps. The identifier for the port is “fe” (short for Fast
Ethernet), noting the speed is capable of 100Mbps and Juniper Networks' designation as Fast Ethernet, but some can be set to
10Mbps through either autonegotiation or manual configuration. In addition to different speeds, the Fast Ethernet PIC ports
can autonegotiate or be manually configured for half-duplex or full-duplex operation.
Fast Ethernet PICs can be 4-, 8-, 12-, or 48-port, although the 48-port Fast Ethernet PIC is only available on the M160. The 4-
port Fast Ethernet PIC has the standard RJ-45 connector for an interface. The 12-port PIC has a larger connector that must be
attached to a patch panel to access the individual ports. The 8-port PIC uses an MT-RJ fiber connector for each port.
GigE operates at 1Gbps and is an optical interface. GigE PICs come in 1-, 2-, and 4-ports per PIC variation, although the 2-
and 4-port variations are only available on the M160. Several different optical choices are available with the GigE card with
respect to the wavelengths available: SX, LX, and LH. SX identifies interfaces for use over short distances to around 650 ft.
The GigE LX interface can be used to over 6 mi. The LH version can be used to almost 50 mi. This allows great flexibility in
connecting Ethernet-type LANs without having to use a WAN in between.

Physical Interface Configuration

Configuring Fast Ethernet and GigE interfaces is fairly easy. For a single network interface, unit 0 can be set with an IP
address, as follows:
[edit]

www.ebook-converter.com
lab@chicago# edit interfaces fe-0/0/1

[edit interfaces fe-0/0/1]

lab@chicago# set unit 0 family inet address 192.168.20.2/24
[edit interfaces fe-0/0/1]
lab@chicago# show
unit 0 {
family inet {
address 192.168.20.2/24;
}
}
[edit interfaces fe-0/0/1]
lab@chicago#
Once the change has been committed, the show interfaces fe-0/0/1 command can be run from the CLI prompt to get
a detailed view of the state and statistics of fe-0/0/1 as is shown below:
lab@chicago> show interfaces fe-0/0/1
Downloader demo watermarks
Physical interface: fe-0/0/1, Enabled, Physical link is Up
Interface index: 10, SNMP ifIndex: 14
Link-level type: Ethernet, MTU: 1514, Speed: 100mbps, Loopback: Disabled,
Source filtering: Disabled, Flow control: Enabled
Device flags : Present Running
Interface flags: SNMP-Traps
245
 7. Interface Configuration
Current address: 00:90:69:9e:80:01, Hardware address: 00:90:69:9e:80:01
Input rate : 0 bps (0 pps)
Output rate : 0 bps (0 pps)
Active alarms : None
Active defects : None

Logical interface fe-0/0/1.0 (Index 7) (SNMP ifIndex 21)

Flags: SNMP-Traps Encapsulation: ENET2
Protocol inet, MTU: 1500, Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 192.168.20/24, Local: 192.168.20.2,
Broadcast: 192.168.20.255

lab@chicago>
Some key items are highlighted in the above output. First, note the split groups between the physical interface properties and
the logical interface properties. After the physical interface properties are listed, all logical units will be listed with their
configurations in unit order. Next, note that the physical interface is Enabled. If the interface were disabled by manual
configuration, this field would read Administratively Down. To administratively re-enable a physical interface that has
been disabled, use the command delete disable in the interface hierarchy.
To ensure connectivity and proper configuration to another connected router's interface, use the ping command from the CLI
operational command prompt to ping the configured IP address on the other router as shown below:
lab@chicago> ping 192.168.20.1
PING 192.168.20.1 (192.168.20.1): 56 data bytes
64 bytes from 192.168.20.1: icmp_seq=0 ttl=255 time=0.982 ms
64 bytes from 192.168.20.1: icmp_seq=1 ttl=255 time=0.808 ms
64 bytes from 192.168.20.1: icmp_seq=2 ttl=255 time=0.782 ms
64 bytes from 192.168.20.1: icmp_seq=3 ttl=255 time=0.829 ms
64 bytes from 192.168.20.1: icmp_seq=4 ttl=255 time=0.789 ms

www.ebook-converter.com
64 bytes from 192.168.20.1: icmp_seq=5 ttl=255 time=0.813 ms
^C
--- 192.168.20.1 ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.782/0.834/0.982/0.068 ms
lab@chicago>
The interface is now up and configured. On occasion, autonegotiation of speed and duplex mode can fail. This can be more
prevalent in older Ethernet implementations. In cases where the two connected interfaces cannot decide on an agreeable
configuration, it is necessary to manually configure, or “nail up,” the link to a particular speed and mode. The following
physical interface is set to full-duplex, and the speed to 100Mbps:
[edit interfaces fe-0/0/1]
lab@chicago# set speed 100m

[edit interfaces fe-0/0/1]

lab@chicago# set link-mode ?
Possible completions:

Downloader demo watermarks

full-duplex
half-duplex
Full-duplex operation
Half-duplex operation
[edit interfaces fe-0/0/1]
lab@chicago# set link-mode full-duplex

[edit interfaces fe-0/0/1]

246
 7. Interface Configuration
lab@chicago# show
speed 100m;
link-mode full-duplex;
unit 0 {
family inet {
address 192.168.20.2/24;
}
}

[edit interfaces fe-0/0/1]

lab@chicago#
To remove the speed or mode and return to autonegotiation, use the delete command.

VLAN and Logical Interface Configuration

Setting up VLAN configuration on Fast Ethernet or GigE requires using logical units. Using logical units allows different IP
networks to be assigned to the different VLANs. For the following configuration example, refer to Figure 7-5.

www.ebook-converter.com
Figure 7-5. VLAN Configuration
Router New York is directly connected to a VLAN-capable switch and needs to be configured to talk to Chicago on one subnet
and Boston on another over the same Fast Ethernet port. The first step in configuring VLANs is to enable VLAN tagging on the
physical interface, as shown below:
[edit interfaces fe-0/0/1]
lab@newyork# set vlan-tagging

[edit interfaces fe-0/0/1]

lab@newyork# show
vlan-tagging;
speed 100m;
link-mode full-duplex;

Downloader demo watermarks

[edit interfaces fe-0/0/1]
lab@newyork#
The next steps are to create the units, assign the units to the appropriate VLAN, and then configure the IP addresses in the
units. Since the scenario has VLANs 20 and 30, we can use those numbers for simplicity, but the unit number, as we have
discussed, is up to the network administrator. It does make sense, however, to give the unit number some kind of significance
247
 7. Interface Configuration
for ease of use.
[edit interfaces fe-0/0/1]
lab@newyork# set unit 20 vlan-id 20

[edit interfaces fe-0/0/1]

lab@newyork# set unit 20 family inet address 192.168.20.2/24

[edit interfaces fe-0/0/1]

lab@newyork# set unit 30 vlan-id 30 family inet address 192.168.30.3/24

[edit interfaces fe-0/0/1]

lab@newyork# show
vlan-tagging;
speed 100m;
link-mode full-duplex;
unit 20 {
vlan-id 20;
family inet {
address 192.168.20.2/24;
}
}
unit 30 {
vlan-id 30;
family inet {
address 192.168.30.3/24;
}
}

[edit interfaces fe-0/0/1]

lab@newyork#

www.ebook-converter.com
Fast Ethernet 0/0/1 now has two logical units configured in VLANs on unit 20 and unit 30. To check the connectivity and
operation of the VLANs, ping the interfaces of routers Chicago and Boston.
lab@newyork> ping 192.168.20.1
PING 192.168.20.1 (192.168.20.1): 56 data bytes
64 bytes from 192.168.20.1: icmp_seq=0 ttl=255 time=0.965 ms
64 bytes from 192.168.20.1: icmp_seq=1 ttl=255 time=0.788 ms
64 bytes from 192.168.20.1: icmp_seq=2 ttl=255 time=0.763 ms
64 bytes from 192.168.20.1: icmp_seq=3 ttl=255 time=0.783 ms
^C
--- 192.168.20.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.763/0.825/0.965/0.082 ms

lab@newyork> ping 192.168.30.1

PING 192.168.30.1 (192.168.30.1): 56 data bytes
64 bytes from 192.168.30.1: icmp_seq=0 ttl=255 time=0.951 ms

Downloader demo watermarks

64 bytes from 192.168.30.1: icmp_seq=1 ttl=255 time=0.784 ms
64 bytes from 192.168.30.1: icmp_seq=2 ttl=255 time=0.798 ms
^C
--- 192.168.30.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.776/0.808/0.951/0.055 ms

248
 7. Interface Configuration
lab@newyork>
All of the pings were successful, thus showing us that the VLANs are working. Check the interface using the CLI show
interfaces command to see the specifics of what is occurring on the interface.
lab@newyork> show interfaces fe-0/0/1
Physical interface: fe-0/0/1, Enabled, Physical link is Up
Interface index: 10, SNMP ifIndex: 14
Link-level type: Ethernet, MTU: 1518, Speed: 100mbps, Loopback: Disabled,
Source filtering: Disabled, Flow control: Enabled
Device flags : Present Running
Interface flags: SNMP-Traps
Current address: 00:90:69:9e:80:01, Hardware address: 00:90:69:9e:80:01
Input rate : 0 bps (0 pps)
Output rate : 0 bps (0 pps)
Active alarms : None
Active defects : None

Logical interface fe-0/0/1.20 (Index 13) (SNMP ifIndex 34)

Flags: SNMP-Traps VLAN 20 Encapsulation: ENET2
Input packets : 4
Output packets: 4
Protocol inet, MTU: 1500, Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 192.168.20/24, Local: 192.168.20.2,
Broadcast: 192.168.20.255

Logical interface fe-0/0/1.30 (Index 14) (SNMP ifIndex 35)

Flags: SNMP-Traps VLAN 30 Encapsulation: ENET2
Input packets : 3
Output packets: 3

www.ebook-converter.com
Protocol inet, MTU: 1500, Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 192.168.30/24, Local: 192.168.30.3,
Broadcast: 192.168.30.255

lab@newyork>
Two things to note in the output above: the VLAN ID for the logical unit and the packet counters. Each logical unit counts
packets that have been sent and received.

MAC Address Filtering

MAC address filtering enables an administrator to determine which devices attached to the Ethernet port are allowed to
communicate through or with the router. MAC filtering accomplishes this by only accepting packets from the administratively
designated MAC addresses of the directly connected devices.

Note

Downloader demo watermarks

This is done on the physical interface and will stop all nonassigned devices from being received even on logical
interfaces.
For this scenario, the previous VLAN configuration is used. The first step is to enable source filtering on the physical interface
in the [edit interfaces fe-0/0/1 fastether-options] hierarchy as shown below:

249
 7. Interface Configuration
[edit interfaces fe-0/0/1]
lab@newyork# edit fastether-options
[edit interfaces fe-0/0/1 fastether-options]
lab@newyork# set source-filtering
[edit interfaces fe-0/0/1 fastether-options]
lab@newyork#
Now try to ping either Chicago or Boston. The ping packets will be sent to them, but their replies will be ignored because there
is not an allowed MAC address list defined yet. This action is such that the router will implicitly deny all unless told to permit
something.
[edit interfaces fe-0/0/1 fastether-options]
lab@newyork# run ping 192.168.20.1
PING 192.168.20.1 (192.168.20.1): 56 data bytes
^C
--- 192.168.20.1 ping statistics ---
7 packets transmitted, 0 packets received, 100% packet loss
[edit interfaces fe-0/0/1 fastether-options]
lab@newyork#
The next step is to assign in a list the MAC addresses that are to be permitted access. Only those listed devices that have
permission to be received by router New York on that particular interface will have their packets flow through the router. This
list is created in the [edit interfaces fe-0/0/1 fastether-options] hierarchy. Use the set source-
address-filter (MAC address) command to add MAC addresses to the list. Router Chicago's MAC address,
00:90:69:a4:d8:01, will be added.
[edit interfaces fe-0/0/1 fastether-options]
lab@newyork# set source-address-filter 00:90:69:a4:d8:01

www.ebook-converter.com
lab@newyork> ping 192.168.20.1
PING 192.168.20.1 (192.168.20.1): 56 data bytes
64 bytes from 192.168.20.1: icmp_seq=0 ttl=255 time=1.661 ms
64 bytes from 192.168.20.1: icmp_seq=1 ttl=255 time=0.801 ms
64 bytes from 192.168.20.1: icmp_seq=2 ttl=255 time=0.785 ms
^C
--- 192.168.20.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.785/1.082/1.661/0.409 ms
lab@newyork> ping 192.168.30.1
PING 192.168.30.1 (192.168.30.1): 56 data bytes
^C
--- 192.168.30.1 ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss
Router New York can now receive ping replies from Chicago, but not from Boston because Boston's MAC address was not
added to the list of accepted addresses.

Downloader demo watermarks

VRRP
In networking design, one of the most important things to consider is reliability of the network. One way to increase reliability
is through redundancy, the availability of a backup device in case the primary device becomes nonfunctional. A router could
become nonfunctional due to a hardware component failure, a software process failure, or scheduled downtime for
250
 7. Interface Configuration
maintenance, for example.
Juniper Networks routers can have redundant items in the chassis, but what if the entire router were to fail or had to be taken
offline? The Ethernet (also Fast Ethernet and GigE) protocol uses ARP to bind a MAC address to an IP address. Devices on
the Ethernet link keep ARP tables so that they know the MAC address of the default gateway, which is typically the router.
Redundancy is introduced when we connect another router to the Ethernet segment. The question then becomes how to create
a redundant network that is transparent to our hosts on the Ethernet segment? To enable full router redundancy, a virtual IP
address and MAC address can be created and then shared by more than one router on an Ethernet network. If one router fails,
another router can receive Ethernet frames to that virtual MAC address to ensure that the data still gets forwarded. This allows
for transparent and redundant connectivity for the hosts on the LAN.
VRRP is an IETF standard (RFC 2338) used to provide router redundancy on Ethernet. VRRP defines a relationship between a
group of routers, one of which will answer for a specific IP address. This VRRP group of routers creates a virtual router
because more than one device (though only one at a time) is capable of receiving the Ethernet frames that a sending device
thinks it is sending to a single router. There could actually be no physical device with that intended address, just several routers
answering for that address. Normally, when a device sends packets to an address, that address is unique in a network. In a
VRRP group of routers, one router answers for an IP address (this router is called the master), and the other routers stay quiet
for that particular address until the master fails. The master is the “owner” of the virtual IP address and answers for it, until it
fails. Then the next backup router in line takes over for that virtual router address as the master.
Dynamic routing protocols enable the rerouting of data to other routers along the path (if they are configured to be in that
dynamic protocol) in the event of a failure of a router. There are instances, however, in which dynamic routing protocols will
not work. If static routes are used or host devices have only a single static default gateway configured in their IP
configurations, there will be no way out if the default gateway router fails. Even with the use of dynamic routing protocols,
certain hold timers and dead timers will have to expire before the other routers on the link consider the failed router no longer
to be a viable path. VRRP allows statically configured Ethernet devices to use backup routers in the event the primary fails.
In Figure 7-6 New York and Chicago both support the virtual router with the IP address 192.168.30.1. New York is the
master for that virtual router. If the hosts have a static default route or gateway configured as 192.168.30.1 when they send

www.ebook-converter.com
data through that IP address, New York will receive it and forward the data. If New York goes offline, Chicago will take over
receiving data for the virtual IP address.

Figure 7-6. VRRP Operation

Even though we have described the VRRP IP address as being independent of a single router, the virtual IP address could
actually be an interface address of one of the participating VRRP routers. If that is the case, then the router that has the
interface address is known as the IP address owner. An IP address owner has to be configured as the master for that virtual
router anytime it is online.
Downloader demo watermarks
What happens when multiple routers are all trying to be the one in charge of the virtual addresses? VRRP is a state and
election-process protocol. The state is whether or not a device is up; the election process defines which is the master router to
answer for the virtual group. A priority can be defined among routers to determine who is the master router and in which order
the backup routers will take over for a particular virtual router IP. Priority ranges from 0 to 255. The router with the highest
priority is elected as the master. Priority on Juniper Networks routers defaults to 100. If a router is an IP address owner, it must
251
 7. Interface Configuration
be configured with a priority of 255, ensuring that it is master for that virtual router group. In addition, the IP address owner
has to be configured for preemption.
Preemption refers to the taking over of a master from another master. If a router with a priority of 125 for a certain VRRP
group is master, and a router is brought online into that same group with a priority of 135, a decision has to be made. Should the
router with the higher priority take away masterhood of the virtual router from the current master when everything is working
just fine? This decision is left to the administrator's discretion except in the case of the IP address owner. A router that is an IP
address owner must be able to preempt any router acting as master for that virtual address because for the IP address owner
that address is real.

Balancing Bandwidth
Besides redundancy, another reason to have more than one router on a path out of a network is to have another router share in
the traffic forwarding. If groups of hosts or routers have different routers on the network manually set as the default gateway,
the traffic-forwarding load can be shared. But this is a labor-intensive process and does not protect the network if one router
goes down because, then, half the hosts would not be able to access the network. Thus, with VRRP you can create that single
virtual IP address that everyone can use and have the routers load-balance traffic for more effective use of them. By default, in
VRRP all the statically configured hosts will send traffic to the single master router for a given virtual IP. Truer load balancing
can be achieved through the use of multiple groups.
VRRP allows more than one group to be configured for a network. This will enable different routers to act as master and
backup for different virtual IP address. In Figure 7-7, router New York is master for 192.168.30.1 and backup for
192.168.30.2. Router Chicago is master for 192.168.30.2 and backup for 192.168.30.1.

www.ebook-converter.com
Figure 7-7. VRRP Multiple Groups
To enable multiple virtual IP addresses with differing priorities and such, separate groups can be configured on the network
interface. Each of these VRRP groups can have different settings for virtual IP addresses, priority, preemption, and so forth,
based on the desired default and fail-over forwarding. How do backup routers know when a master has failed?
Master routers send out advertisements to other routers in the group to let them know of the master's status. These
advertisements are sent, by default, once per second. The advertisements contain such information as the group ID, virtual IP
addresses of this group, the master's priority, the group's advertisement interval, and any authentication information used
between VRRP-enabled routers in a group.
Since devices have unique MAC addresses on a network, a virtual MAC address is also needed to allow different routers to

Downloader demo watermarks

answer for the virtual IP address. This virtual MAC address comes from a range that is specified in RFC 2338. The address
range is 00:00:5e:00:01:00-ff. The virtual MAC address is created when the VRRP group is created. The last byte of
two hexadecimal places has a decimal range of 0 to 255, which is the same range of configurable VRRP group ID numbers.
The last byte of the virtual MAC address will match the VRRP group ID. This is extremely important to know if MAC address
filtering is implemented. The virtual MAC address for each VRRP group must be added to the lists of accepted devices.

252
 7. Interface Configuration
VRRP Configuration
VRRP configuration on a Juniper Networks router takes place at the [edit interfaces (int#) unit (#) family
inet address (addr)] hierarchy level. Due to the fact that logical units are on different networks and each logical unit
can have multiple IP addresses, the VRRP group is defined under a specific IP address. The virtual IP address or addresses for
the group should fall within the same subnet as the address of the logical unit.
You first create the VRRP group; then, the virtual IP address is assigned. In Figure 7-8, routers New York and Chicago have
two VRRP groups configured. Router New York is the master of virtual IP address for Group 10, while router Chicago is the
master of Group 20.

Figure 7-8. VRRP Group Configuration

Refer to Figure 7-8 as you read through the following configuration example. The Fast Ethernet interfaces are already
configured on New York and Chicago, as is shown in the output below:
Router New York

www.ebook-converter.com
[edit interfaces fe-0/0/1]
lab@newyork# show
speed 100m;
link-mode full-duplex;
unit 0 {
family inet {
address 192.168.30.3/24;
}
}

[edit interfaces fe-0/0/1]

lab@newyork#

Router Chicago
[edit interfaces fe-0/0/1]
lab@chicago# show
speed 100m;
link-mode full-duplex;
unit 0 {

}
Downloader demo watermarks
family inet {
}
address 192.168.30.4/24;

[edit interfaces fe-0/0/1]

lab@chicago#
253
 7. Interface Configuration
The VRRP groups will be configured under the IP address of unit 0 on both routers. First, router New York will have a
configured priority of 110 for VRRP Group 10 for the virtual IP address of 192.168.30.1 and a priority of 90 for
192.168.30.2 in VRRP Group 20. The purpose is to create router New York as the master for Group 10 and the backup for
Group 20, thus balancing the load.
[edit interfaces fe-0/0/1]
lab@newyork# edit unit 0 family inet address 192.168.30.3/24

[edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.3/24]

lab@newyork# set vrrp-group 10 virtual-address 192.168.30.1

[edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.3/24]

lab@newyork# edit vrrp-group 10

[edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.3/24 vrrp-

group 10]
lab@newyork# set priority 110

[edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.3/24 vrrp-

group 10]
lab@newyork# up
[edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.3/24]
lab@newyork# set vrrp-group 20 virtual-address 192.168.30.2
[edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.3/24]
lab@newyork# edit vrrp-group 20
[edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.3/24 vrrp-
group 20]

www.ebook-converter.com
lab@newyork# set priority 90
New York's interface configuration looks as follows when completed:
[edit interfaces fe-0/0/1 unit 0 family inet]
lab@newyork# show
address 192.168.30.3/24 {
vrrp-group 10 {
virtual-address 192.168.30.1;
priority 110;
}
vrrp-group 20 {
virtual-address 192.168.30.2;
priority 90;
}
}
[edit interfaces fe-0/0/1 unit 0 family inet]
lab@newyork#

Downloader demo watermarks

Router New York will be master for and virtual IP addresses for VRRP Group 10 and a backup for VRRP Group 20. Using the
show vrrp command allows us to see what groups are set on interfaces and their states.
lab@newyork> show vrrp
Interface Unit Group Type Address Int state VR state Timer
fe-0/0/1 0 10 lcl 192.168.30.3 up master A
0.620
254
 7. Interface Configuration
vip 192.168.30.1
fe-0/0/1 0 20 lcl 192.168.30.3 up master A
0.290
vip 192.168.30.2

lab@newyork>
Router New York has two VRRP groups enabled on fe-0/0/1 unit 0. The local unit IP address is shown along with the
virtual IP address for that group. Currently, router New York is master for both groups because Chicago has not yet been
configured.

Note
If the no-preempt option is to be used, then configure the groups by master router first. If the groups are all
configured on one router at a time, the first router configured will be master for all the groups. None of the other
routers with higher priorities for those groups will be able to take over as intended because they are not allowed to
preempt the master, even if they have a higher priority. Only if the master were to fail would an election take place
for each group. In this example, if you were to use the no-preempt option, you would configure router New York's
VRRP Group 10 and then router Chicago's Group 20. Then New York and Chicago can be configured for their
backup groups.
Router Chicago will get the opposite configuration as New York, meaning that by design router Chicago will be the backup for
the group in which router New York is master, while Chicago is the master for the group in which router New York is the
backup. In this manner, the routers can split the duties and the work of being masters of the VRRP groups.
[edit interfaces fe-0/0/1]
lab@chicago# edit unit 0 family inet address 192.168.30.4/24
[edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.4/24]
lab@chicago# set vrrp-group 10 virtual-address 192.168.30.1

www.ebook-converter.com
[edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.4/24]
lab@chicago# set vrrp-group 10 priority 90

[edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.4/24]

lab@chicago# set vrrp-group 20 virtual-address 192.168.30.2

[edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.4/24]

lab@chicago# set vrrp-group 20 priority 110

[edit interfaces fe-0/0/1 unit 0 family inet address 192.168.30.4/24]

lab@chicago# up

[edit interfaces fe-0/0/1 unit 0 family inet]

lab@chicago# show
address 192.168.30.4/24 {
vrrp-group 10 {
virtual-address 192.168.30.1;
priority 90;

Downloader demo watermarks

}
vrrp-group 20 {
virtual-address 192.168.30.2;
priority 110;
}
}

255
 7. Interface Configuration
[edit interfaces fe-0/0/1 unit 0 family inet]
lab@chicago#
Showing the VRRP information on New York again, router Chicago has been configured as a higher priority for VRRP Group
20 than router New York. Router Chicago takes over.
lab@newyork> show vrrp
Interface Unit Group Type Address Int state VR state Timer
fe-0/0/1 0 10 lcl 192.168.30.3 up master A
0.890
vip 192.168.30.1
fe-0/0/1 0 20 lcl 192.168.30.3 up backup D
2.768
vip 192.168.30.2
mas 192.168.30.4
lab@newyork>
Notice one other change in the output shown here. Another Type and Address entry has been made for Group 20 that shows
who the master is for that group (using the actual interface address of Chicago) because the master is no longer router New
York.
Ethernet is the most popular of the LAN technologies because it is inexpensive, easily implemented, very scalable, and
available in a wide variety of interfaces, ranging from 10Mbps to 10Gbps. Although it is a broadcast-type data link protocol
that has the potential for problems in large broadcast domains, newer standards allow for improvements by supporting such
features as VRRP and MAC address filtering.

SONET/SDH Interfaces
Although SONET has actually been around for some time in the nonconcatenated form, POS is a relatively new

www.ebook-converter.com
implementation. Due to its extremely high bandwidth capabilities, coupled with its very low overhead, POS has been making
very fast in-roads in the Datacom world.
Juniper Networks supports the full range of current POS speeds, from OC-3 to OC-192. OC-192, at approximately 10Gbps, is
at the time of writing one of the fastest commercially available interfaces, and Juniper Networks is one of the few companies
that offers it. These high-bandwidth interfaces allow Internet providers to drastically increase the capability of their core
infrastructure to meet the high use demands of Internet users.
SONET and SDH are basically two sides of the same coin. SONET is primarily a U.S. standard, while most of the rest of the
world uses SDH. For configuration purposes, and unless otherwise specified, the term SONET in this section will represent both
SONET and SDH.
SONET is an optical timing protocol that works at the physical layer of the OSI model. An encapsulation type for the data link
layer needs to be defined and configured to enable the upper layers to communicate. Juniper Networks offers three
encapsulation types for physical SONET interfaces: PPP, Cisco-HDLC, and Frame Relay. PPP is the Juniper Networks
SONET default and does not need to be configured explicitly. Because Cisco-HDLC and PPP are both point-to-point
protocols, if they are configured on the physical interface, there can be only one logical unit configured. If the encapsulation is
Frame Relay, a multiaccess protocol, more than one unit can be configured on a physical interface.

Downloader demo watermarks

Configuring Framing on Optical Interfaces
The Juniper Networks optical interfaces are framed in either the SONET or SDH mode. Framing is the process of sequencing
the bits of data into standard patterns. SONET framing is described in more detail in Chapter 2. The commands to change the
framing type are entered at the [edit chassis] hierarchy level. In JUNOS software, you configure SONET to turn on the
SDH features. The PIC is called SONET, but is not limited to SONET framing. In the following sample output, the choices for
256
 7. Interface Configuration
framing SONET or SDH are shown:
[edit]
lab@Boston# edit chassis fpc 2 pic 2

[edit chassis fpc 2 pic 2]

lab@Boston# set ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
framing Framing mode
no-concatenate Don't concatenate channels
vtmapping VT mapping mode
[edit chassis fpc 2 pic 2]
lab@Boston# set framing ?
Possible completions:
sdh SONET/SDH mode
sonet SONET mode
[edit chassis fpc 2 pic 2]
lab@Boston#

PPP Configuration
SONET characteristics for the interface are configured at the physical interface hierarchy level. This is where such parameters
as clocking, keepalive intervals, and physical interface encapsulation are configured. In addition to those parameters listed
above, there is a subhierarchy called sonet-options, where SONET parameters, such as FCS, payload scrambling, and
header byte configuration options, can be configured.
POS interfaces on Juniper Networks routers default to the following settings: payload scrambling enabled, 16-bit FCS, 10-
second interval keepalives, PPP encapsulation, internal clocking, and 4,474-byte MTU. A default physical SONET
interface looks as follows:

www.ebook-converter.com
lab@newyork> show interfaces so-0/3/0
Physical interface: so-0/3/0, Enabled, Physical link is Up
Interface index: 16, SNMP ifIndex: 25
Link-level type: PPP, MTU: 4474, Clocking: Internal, SONET mode, Speed:
OC12,
Loopback: None, FCS: 16, Payload scrambler: Enabled
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps
Link flags : Keepalives
Keepalive settings: Interval 10 seconds, Up-count 1, Down-count 3
Keepalive: Input: 27 (00:00:03 ago), Output: 27 (00:00:08 ago)
LCP state: Opened
NCP state: inet: Opened, iso: Not-configured, mpls: Not-configured
Input rate : 0 bps (0 pps)
Output rate : 0 bps (0 pps)
SONET alarms : None
SONET defects : None

Downloader demo watermarks

Notice that some of the important physical parameters are highlighted. These include some of the items that must be checked
when connecting a Juniper Networks POS interface to that of another vendor. FCS is also referred to as a CRC. The FCS value
is either 16- or 32-bit. The following shows where you can configure SONET physical characteristics:
[edit interfaces so-0/3/0]
lab@chicago# set ?
Possible completions:
257
 7. Interface Configuration
accounting-profile Accounting profile name
+ apply-groups Groups from which to inherit configuration data
clocking Interface clock source
dce Respond to Frame Relay status enquiry messages
description Text description of interface
disable Disable this interface
encapsulation Physical link-layer encapsulation
> hold-time Hold time for link up and link down
> keepalives Send/demand keepalive messages
> lmi Local Management Interface settings
mtu Maximum transmit packet size (256..9192)
no-keepalives Don't send/demand keepalive messages
no-traps Don't enable SNMP notifications on state changes
> receive-bucket Set receive bucket parameters
> sonet-options SONET interface-specific options
> traceoptions Interface trace options
> transmit-bucket Set transmit bucket parameters
traps Enable SNMP notifications on state changes
> unit Logical interface
[edit interfaces so-0/3/0]
lab@chicago# edit sonet-options

[edit interfaces so-0/3/0 sonet-options]

lab@chicago# set ?
Possible completions:
aggregate Join a sonet aggregate
+ apply-groups Groups from which to inherit configuration data
> aps Automatic Protect Switching
> bytes Set SONET header bytes
fcs Frame checksum

www.ebook-converter.com
loopback Loopback mode
no-payload-scrambler Don't enable payload scrambling
no-z0-increment Don't increment Z0 in SDH mode
path-trace Path trace string
> payload-scrambler Enable payload scrambling
rfc-2615 RFC 2615 compliance
z0-increment Increment Z0 in SDH mode
[edit interfaces so-0/3/0 sonet-options]
lab@chicago#
Now we will look at the three encapsulation types (with their CCC counterparts) possible under the SONET interface
encapsulation. The following output is an example of the options for the set encapsulation command under a SONET
interface:
[edit interfaces so-0/3/0]
lab@chicago# set encapsulation ?
Possible completions:
cisco-hdlc Cisco-compatible HDLC framing
cisco-hdlc-ccc Cisco-compatible HDLC framing for a cross connection
frame-relay Frame Relay encapsulation

Downloader demo watermarks

frame-relay-ccc
ppp
ppp-ccc
Frame Relay encapsulation for cross connection
Serial PPP device
Serial PPP device for a cross connection
[edit interfaces so-0/3/0]
lab@chicago#
In Figure 7-9, router Chicago and router New York are connected by an OC-12 POS link. The FCS is set to a value of 32 and
258
 7. Interface Configuration
the New York interface will be used for clocking, which means that router Chicago has to be configured to use an external
clocking source on the link (i.e., router New York) to ensure that their timing is synchronized. Since POS provides internal
clocking by default, we only have to alter clocking on Chicago to recognize the external clocking source of New York.

Figure 7-9. SONET PPP Configuration

In the example below, router Chicago will have clocking configured to external to use the timing from router New York, the
FCS will be changed to 32, and an IP address will be applied. Since Juniper Networks routers default to PPP for SONET,
encapsulation does not need to be set.
[edit interfaces so-0/3/0]
lab@chicago# set clocking external
[edit interfaces so-0/3/0]
lab@chicago# set sonet-options fcs 32
[edit interfaces so-0/3/0]
lab@chicago# set unit 0 family inet address 192.168.40.1/30
Router New York is configured next with the same FCS options and the IP address of the link.
[edit interfaces]
lab@newyork# edit so-0/3/0
[edit interfaces so-0/3/0]
lab@newyork# set sonet-options fcs 32

www.ebook-converter.com
[edit interfaces so-0/3/0]
lab@newyork# set unit 0 family inet address 192.168.40.2/30
The configuration is checked by successfully pinging the other interface.
lab@newyork> ping 192.168.40.1
PING 192.168.40.1 (192.168.40.1): 56 data bytes
64 bytes from 192.168.40.1: icmp_seq=0 ttl=255 time=0.860 ms
64 bytes from 192.168.40.1: icmp_seq=1 ttl=255 time=0.748 ms
64 bytes from 192.168.40.1: icmp_seq=2 ttl=255 time=0.765 ms
^C
--- 192.168.40.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.748/0.791/0.860/0.049 ms
lab@newyork>
Now, look at the so-0/3/0 interface for router Chicago. The Link Control Protocol and Network Control Protocol (family

Downloader demo watermarks

inet) of PPP are in the Opened state.
lab@chicago> show interfaces so-0/3/0
Physical interface: so-0/3/0, Enabled, Physical link is Up
Interface index: 18, SNMP ifIndex: 31
Link-level type: PPP, MTU: 4474, Clocking: External, SONET mode, Speed:
OC12,
259
 7. Interface Configuration
Loopback: None, FCS: 32, Payload scrambler: Enabled
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps
Link flags : Keepalives
Keepalive settings: Interval 10 seconds, Up-count 1, Down-count 3
Keepalive: Input: 82 (00:00:09 ago), Output: 82 (00:00:04 ago)
LCP state: Opened
NCP state: inet: Opened, iso: Not-configured, mpls: Not-configured
Input rate : 0 bps (0 pps)
Output rate : 0 bps (0 pps)
SONET alarms : None
SONET defects : None
Logical interface so-0/3/0.0 (Index 12) (SNMP ifIndex 26)
Flags: Point-To-Point SNMP-Traps Encapsulation: PPP
Protocol inet, MTU: 4470, Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 192.168.40.0/30, Local: 192.168.40.1
lab@chicago>
The example above shows a basic single SONET PPP connection configuration. Since PPP is the default encapsulation, it did
not have to be specified. One side of the link (New York) provided the timing by designating router Chicago's interface timing
as external.

Frame Relay Configuration

SONET interfaces can also use Frame Relay encapsulation. There are a few differences when configuring Frame Relay on an
interface. Multiple logical units can be configured either point-to-point or multipoint. Keepalives are disabled on both
interfaces so that the local management interface (LMI) packets can be sent instead. LMI packets are used to maintain the

www.ebook-converter.com
Frame Relay PVCs. Juniper Networks routers support the two common LMI types: ANSI and ITU. A DLCI is configured on
the logical units to differentiate the origin of the data.
In Figure 7-10, routers Chicago and New York have a point-to-point Frame Relay connection between them using DLCI 103.
First New York is configured. Under the physical SONET interface, the encapsulation is set to Frame Relay. Afterwards, the
unit parameters and the IP address are configured. For back-to-back Frame Relay connections, either disable the sending of
keepalives on both sides of the connection, or configure one side of the connection as a DTE (the default JUNOS
configuration) and the other as a DCE.

Figure 7-10. SONET Frame Relay Configuration

[edit interfaces so-0/3/0]

Downloader demo watermarks

lab@newyork# set encapsulation frame-relay
[edit interfaces so-0/3/0]
lab@newyork# set no-keepalives
[edit interfaces so-0/3/0]
lab@newyork# edit unit 103
260
 7. Interface Configuration
[edit interfaces so-0/3/0 unit 103]
lab@newyork# set point-to-point
[edit interfaces so-0/3/0 unit 103]
lab@newyork# set dlci 103
[edit interfaces so-0/3/0 unit 103]
lab@newyork# set family inet address 192.168.50.10/30
The configuration looks as follows in a show command for the entire SONET interface:
[edit interfaces so-0/3/0]
lab@newyork# show
no-keepalives;
encapsulation frame-relay;
unit 103 {
point-to-point;
dlci 103;
family inet {
address 192.168.50.10/30;
}
}
[edit interfaces so-0/3/0]
lab@newyork#
Next, router Chicago is configured with the same SONET parameters as New York, except that the clocking is assigned as
external for Chicago.
[edit interfaces so-0/3/0]

www.ebook-converter.com
lab@chicago# set encapsulation frame-relay
[edit interfaces so-0/3/0]
lab@chicago# set no-keepalives
[edit interfaces so-0/3/0]
lab@chicago# set clocking external

[edit interfaces so-0/3/0]

lab@chicago# edit unit 103

[edit interfaces so-0/3/0 unit 103]

lab@chicago# set point-to-point

[edit interfaces so-0/3/0 unit 103]

lab@chicago# set dlci 103

[edit interfaces so-0/3/0 unit 103]

lab@chicago# set family inet address 192.168.50.9/30

Downloader demo watermarks

New York's SONET interface configuration is as follows:
[edit interfaces so-0/3/0]
lab@chicago# show
no-keepalives;
clocking external;
261
 7. Interface Configuration
encapsulation frame-relay;
unit 103 {
point-to-point;
dlci 103;
family inet {
address 192.168.50.9/30;
}
}
To test the configuration of the link between the two routers, ping the IP address of the directly connected router, in this case
New York's IP address.
[edit interfaces so-0/3/0]
lab@chicago# run ping 192.168.50.10
PING 192.168.50.10 (192.168.50.10): 56 data bytes
64 bytes from 192.168.50.10: icmp_seq=0 ttl=255 time=0.953 ms
64 bytes from 192.168.50.10: icmp_seq=1 ttl=255 time=0.727 ms
64 bytes from 192.168.50.10: icmp_seq=2 ttl=255 time=0.768 ms
64 bytes from 192.168.50.10: icmp_seq=3 ttl=255 time=0.745 ms
^C
--- 192.168.50.10 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.727/0.798/0.953/0.091 ms

[edit interfaces so-0/3/0]

lab@chicago#
Looking at the show interfaces command, notice there are some differences from the earlier PPP encapsulation
configuration. To start with, the link-level type is now shown as Frame Relay. Link flags shows that the interface is DTE, or
receiving the timing from the far end of the link. Also, the ANSI LMI settings have been added for the Frame Relay
parameters.

www.ebook-converter.com
lab@chicago> show interfaces so-0/3/0
Physical interface: so-0/3/0, Enabled, Physical link is Up
Interface index: 18, SNMP ifIndex: 31
Link-level type: Frame-Relay, MTU: 4474, Clocking: External, SONET mode,
Speed: OC12, Loopback: None, FCS: 16, Payload scrambler: Enabled
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps
Link flags : No-Keepalives DTE
ANSI LMI settings: n391dte 6, n392dte 3, n393dte 4, t391dte 10 seconds
LMI: Input: 0 (never), Output: 0 (never)
Input rate : 0 bps (0 pps)
Output rate : 0 bps (0 pps)
SONET alarms : None
SONET defects : None
Logical interface so-0/3/0.103 (Index 12) (SNMP ifIndex 36)
Flags: Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
Input packets : 10
Output packets: 10

Downloader demo watermarks

Protocol inet, MTU: 4470, Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 192.168.50.8/30, Local: 192.168.50.9
DLCI 103
Flags: Active
Total down time: 0 sec, Last down: Never
Traffic statistics:
262
 7. Interface Configuration
Input packets: 10
Output packets: 10

lab@chicago>
In the above output, the ANSI-specified LMI settings can be changed manually as long as both devices are properly
configured. These numbers represent the management functions, such as error thresholds, LMI keepalive timers, and so on.
In addition, the DLCI 103 is shown under the logical unit and the statistics for that PVC.

APS
APS, or automatic protection switching, is a system used to backup SONET connections by fail-over. With APS, devices can
have redundant SONET links between them, one active and one on standby. The active connection is called the working
circuit; the backup link is called the protect circuit. These standby circuits can be connected on another interface on the same
PIC, on another interface on a different FPC, or even on a different router.
APS can be configured between routers, or between ADMs and routers. Figure 7-11 illustrates router-to-router and ADM-to-
router APS configurations. In addition, APS can be configured for concatenated or nonconcatenated SONET interfaces.
SONET is in the nonconcatenated mode for use with channelized TDM circuits. SONET is in the concatenated mode for using
clear channel between devices. SONET concatenation was discussed in Chapter 2.

www.ebook-converter.com
Figure 7-11. APS Configuration Models
APS has several configurable parameters, such as keepalive intervals, authentication, and load sharing. Here we show the
possible commands in the [edit interfaces (interface) sonet-options aps] hierarchy.
[edit interfaces so-0/2/0]
lab@chicago# set sonet-options aps ?
Possible completions:
advertise-interval Advertise interval (milliseconds)
+ apply-groups Groups from which to inherit configuration data
> authentication-key Authentication parameters
force Force circuit state
hold-time Hold time (milliseconds)
lockout Lockout protection

Downloader demo watermarks

neighbor
paired-group
protect-circuit
request
Neighbor address
Name of paired APS group
Protect circuit group name
Request circuit state
revert-time Circuit revert time (seconds)
working-circuit Working circuit group name
[edit interfaces so-0/2/0]
263
 7. Interface Configuration
lab@chicago#
APS sends keepalives at designated intervals to inform devices that the working circuit is still operational. If a keepalive
is not received within three times the designated interval, the protect circuit will take over. The default interval for APS
keepalives on a Juniper Networks SONET interface is 1,000 ms (1 sec). This is called the advertise-interval, which
means that the default time for a switchover on a failed SONET connection is three seconds. If two routers are being used,
authentication can be enabled using the authentication-key parameter for security.
APS is configured under the aps subhierarchy of sonet-options. The first step is to determine which of the links will be
the primary (working) and which will be the secondary (protect). A group name is then defined after the circuit type to
designate the relationship between protecting interfaces and working interfaces. If a binding factor was not used, and a router
had several working and protect circuits, how would it know which circuits they were protecting? The same name is used on
both the working and protect interfaces to bind them in a group. Figure 7-12 shows a router-to-router APS scenario with the
APS ports in different PICs.

Figure 7-12. Router-to-Router APS Configuration

In this instance, both interfaces have the same IP address. Routers from other vendors may not have an APS implementation as
fully featured as Juniper Networks. In some cases, the router may have just primary and secondary interfaces. If this is the
case, the APS interfaces would have to have the same IP address. Here we see that router Chicago has been configured for
APS with the group name of juniper. Router New York has been configured in the same way with IP address

www.ebook-converter.com
192.168.50.2.
[edit interfaces]
lab@chicago# show
fe-0/0/0 {
<<<output omitted for brevity>>>
}
so-0/2/0 {
clocking external;
encapsulation cisco-hdlc;
sonet-options {
aps {
working-circuit juniper;
}
}
unit 0 {
family inet {
address 192.168.50.1/30;
}

Downloader demo watermarks

}
}
so-0/3/0 {
clocking external;
encapsulation cisco-hdlc;
sonet-options {
aps {
264
 7. Interface Configuration
protect-circuit juniper;
}
}
unit 0 {
family inet {
address 192.168.50.1/30;
}
}
}
<<<output omitted for brevity>>>
[edit interfaces]
lab@chicago#
To show the status of APS on a router, use the show aps command as shown below. This will show the groups to which the
interfaces are assigned, circuit types configured, and the interface state.
lab@chicago> show aps
Interface Group Circuit Intf State
so-0/2/0 juniper Working enabled, up
so-0/3/0 juniper Protect disabled, up

lab@chicago>
The first field of the interface state is the administrative state; the second is the physical state. When the protect circuit will not
be used for forwarding traffic while the working circuit is up, the protect circuit will be administratively disabled by the router.
However, the physical state of the interface is Up, as is shown below. Interface so-0/2/0 is Enabled and Up, while
interface so-0/3/0 is Administratively Down and Up.
lab@chicago> show interfaces so-0/2/0
Physical interface: so-0/2/0, Enabled, Physical link is Up
Interface index: 15, SNMP ifIndex: 17

www.ebook-converter.com
Link-level type: Cisco-HDLC, MTU: 4474, Clocking: External, SONET mode,
Speed: OC12, Loopback: None, FCS: 16, Payload scrambler: Enabled
Device flags : Present Running
Interface flags: Point-To-Point ...

lab@chicago show interfaces so-0/3/0

Physical interface: so-0/3/0, Administratively down, Physical link is Up
Interface index: 16, SNMP ifIndex: 31
Link-level type: Cisco-HDLC, MTU: 4474, Clocking: External, SONET mode,
Speed: OC12, Loopback: None, FCS: 16, Payload scrambler: Enabled
Device flags : Present Running
Interface flags: Down Link-Layer-Down Point-To-Point SNMP-Traps
Removing the fiber connection from so-0/2/0 will result in the connection failing over to so-0/3/0, because so-0/2/0
will go into a disabled and down state. Using the show aps command again, you can see that so-0/3/0 is now
enabled, while so-0/2/0 is now disabled. It is also, of course, physically down because the fiber is removed from the
interface.

Downloader demo watermarks

lab@chicago> show aps
Interface Group
so-0/2/0 juniper
Circuit
Working
Intf State
disabled, down
so-0/3/0 juniper Protect enabled, up

lab@chicago>
265
 7. Interface Configuration
The most important point of all is whether or not router Chicago can still communicate with router New York on the newly
enabled link. It can, as we see below:
lab@chicago> ping 192.168.50.2
PING 192.168.50.2 (192.168.50.2): 56 data bytes
64 bytes from 192.168.50.2: icmp_seq=0 ttl=255 time=0.795 ms
64 bytes from 192.168.50.2: icmp_seq=1 ttl=255 time=0.735 ms
^C
--- 192.168.50.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.735/0.765/0.795/0.030 ms

lab@chicago>
Of all the types of interfaces Juniper Networks has, SONET is the fastest and is generally preferred for WAN data
communications. Even though ATM is more widely used because of its installation base and acceptance in the Telecom
industry, SONET has much less overhead and can transfer data at much higher rates. Juniper Networks makes a strong case for
migrating core networks to SONET from ATM. This case gets stronger as IP-enhancing features are implemented that allow
policy and service guarantees that are not inherently found in the standard IP protocol.

ATM Interfaces
ATM is a very popular high-speed WAN protocol. Many logical units can be configured on each port, with each logical unit
configured for different QoS options. This can be a powerful tool for connectivity options. The disadvantages of ATM are
extremely high overhead and an upward speed limitation of OC-12.
In addition to the large cell header overhead, the segmentation and reassembly (SAR) of packets to ATM cells and back also
use many resources on an interface, further limiting the overall throughput. Juniper Networks has two ports per PIC for OC-3
ATM and one port per PIC for OC-12 ATM. In addition to the optical ATM interfaces, Juniper Networks implements ATM on
electrical DS-3 and E-3 ports using coaxial cable. Juniper Networks supports standard PVCs on ATM logical units.

www.ebook-converter.com
Juniper Networks enables either PVC encapsulation or ATM CCC encapsulation for cell relay on a physical interface. A
variety of ATM encapsulations can be configured on the PVC logical units. The most common of the PVC encapsulations (and
Juniper Networks default) is ATM-SNAP. ATM-NLPID and ATM-CISCO-NLPID are also available for routing packets. There
are two options for CCC: cell relay and VC-Mux.
Juniper Networks supports three QoS classes on PVCs, defaulting to UBR as the lowest class. VBR and CBR are the other two
classes supported, with CBR being the highest-priority class followed by VBR.
In addition to those features mentioned above, Juniper Networks supports integrated local management interface (ILMI) in its
ATM implementation. ILMI allows management information to flow between directly connected ATM devices, such as the
router and an ATM switch. ILMI is set at VPI 0 VCI 16 when configured on a physical interface.

Physical Interface Configuration

Since the optical transport for ATM is SONET/SDH, the same physical features can be configured under the options for
SONET on an ATM physical interface, including APS. Aggregating links is one feature that cannot be configured on an ATM
link. In addition to all of the options for SONET that are available, there are options for ATM that can be configured, such as

Downloader demo watermarks

enabling ILMI and configuring the virtual paths that can be used on the interface.
Juniper Networks ATM interfaces support more than 4,000 virtual circuits (VCs) per physical interface. To enable VC
assignment per logical unit, you must first assign the virtual path to the physical interface and define the maximum VCs for that
virtual path under the ATM options. The following example first shows the assignment of VPI 1 to ATM interface 0/1/1 on
router New York, then the assignment of the maximum VC number that can be used:

266
 7. Interface Configuration
[edit interfaces at-0/1/0]
lab@newyork# set atm-options ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
> ilmi Enable Interim Local Management Interface
> vpi Define a virtual path
[edit interfaces at-0/1/1]
lab@newyork# set atm-options vpi 1 ?
Possible completions:
maximum-vcs Maximum number of virtual circuits on this VP
[edit interfaces at-0/1/1]
lab@newyork# set atm-options vpi 1 maximum-vcs 250

[edit interfaces at-0/1/1]

lab@newyork#
If more virtual paths need to be configured, they can be assigned in a similar manner.

Logical Interface Configuration

The PVC in ATM is configured on the logical unit. Some of the unit logical unit parameters that can be configured include the
following:
ATM PVC-type encapsulation
VPI (optional)/VCI assignment
Family addressing
Type of PVC

www.ebook-converter.com
Any traffic-shaping QoS parameters
As mentioned earlier, the default encapsulation for ATM logical units is ATM-SNAP for standard ATM encapsulation of IP
packets. The other possible encapsulation alternatives are shown below:
[edit interfaces at-0/1/0 unit 200]
lab@newyork# set encapsulation ?
Possible completions:
atm-ccc-cell-relay ATM Cell Relay for CCC
atm-ccc-vc-mux ATM VC for CCC
atm-cisco-nlpid Cisco-compatible ATM NLPID encapsulation
atm-nlpid ATM NLPID encapsulation
atm-snap ATM LLC/SNAP encapsulation
atm-vc-mux ATM VC multiplexing
[edit interfaces at-0/1/1 unit 200]
lab@newyork#
The Network Layer Protocol ID (NLPID) is a field used in Frame Relay headers. Frame Relay–type service to ATM networks
requires a Frame Relay–type encapsulation of the packets before they are segmented into the payloads of ATM cells. The IETF
Downloader demo watermarks
standardized one Frame Relay encapsulation and Cisco created another. The difference between the IETF-based NLPID and
Cisco-based NLPID standards is as follows: VC-Mux is the VC-based-multiplexing encapsulation type used when each
protocol gets its own VC. These encapsulation types for ATM are defined in IETF RFC 1483; although RFC 2684 renders 1483
obsolete, Juniper Networks documentation references 1483 explicitly.
When configuring the VPI/VCI for a PVC, if only one VP were assigned to the entire physical interface with the vpi #
267
 7. Interface Configuration
maximum-vcs # command, then only one would need to be configured with the VCI assignment. If more than one VP were
assigned to the physical interface, the vpi.vci format would have to be used.
An ATM logical unit can be point-to-point or -multipoint. Juniper Networks ATM logical units default to point-to-point. If that
is the type you want, then you do not have to specify as much during configuration. If you want multipoint configured, then
you will have to configure a destination statement for each destination on the link. This is configured in the family inet
hierarchy with the multipoint-destination (address/xx) command, where the address is the IP address and xx
is the address prefix.
In Figure 7-13, router Chicago has an ATM PVC to router New York using VPI 2 VCI 200.

Figure 7-13. ATM Basic Configuration

Since the PVC is assigned values of VPI 2 VCI 200, VPI 2 must be assigned to the physical interface with the maximum
number of VCs that can be assigned for that virtual path. After that, the specific unit is configured. Since router Chicago has
more than one VPI assigned to the physical interface, the VPI must be designated in the unit configuration. For this example,
the point-to-point logical unit type is illustrated, although it does not have to be, since it is the default. If it is manually typed in,
it will be output in the configuration.
[edit interfaces at-0/1/0]
lab@chicago# set atm-options vpi 2 maximum-vcs 250

[edit interfaces at-0/1/0]

lab@chicago# edit unit 201

www.ebook-converter.com
[edit interfaces at-0/1/0 unit 201]
lab@chicago# set vci 2.200

[edit interfaces at-0/1/0 unit 201]

lab@chicago# set family inet address 192.168.20.1/30

[edit interfaces at-0/1/0 unit 201]

lab@chicago# set point-to-point

[edit interfaces at-0/1/0 unit 201]

lab@chicago# show
point-to-point;
vci 2.200;
family inet {
address 192.168.20.1/30;
}
[edit interfaces at-0/1/0 unit 201]
lab@chicago#

Downloader demo watermarks

Router New York is already configured appropriately to be connected to Chicago. The VPI and VCI are configured, along with
the IP address.
[edit interfaces at-0/1/0]
lab@newyork# show
atm-options {

268
 7. Interface Configuration
vpi 2 maximum-vcs 250;
}
unit 202 {
vci 2.200;
family inet {
address 192.168.20.2/30;
}
}

[edit interfaces at-0/1/0]

lab@newyork#
Notice in the output above from New York that even though the configuration does not show the point-to-point logical unit
(because it was not manually entered into the configuration), it is shown in the logical unit status and statistics below:
lab@newyork> show interfaces at-0/1/0
Physical interface: at-0/1/0, Enabled, Physical link is Up
Interface index: 13, SNMP ifIndex: 17
Link-level type: ATM-PVC, MTU: 4482, Clocking: Internal, SONET mode,
Speed: OC3, Loopback: None, Payload scrambler: Enabled
Device flags : Present Running
Link flags : None
Input rate : 0 bps (0 pps)
Output rate : 0 bps (0 pps)
SONET alarms : None
SONET defects : None
Logical interface at-0/1/0.202 (Index 13) (SNMP ifIndex 39)
Flags: Point-To-Point SNMP-Traps Encapsulation: ATM-SNAP
Input packets : 4
Output packets: 4

www.ebook-converter.com
Protocol inet, MTU: 4470, Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 192.168.20.0/30, Local: 192.168.20.2
VCI 2.200
Flags: Active
Total down time: 0 sec, Last down: Never
Traffic statistics:
Input packets: 4
Output packets: 4
lab@newyork>

ATM QoS Configuration

One of the advantages of ATM is the maturity of the QoS. These features allow priority and guaranteed service to the PVCs
that require it. Data that is time-sensitive or highest-priority can be sent along in the CBR class. Data that is more important
than best-effort, but is not of the highest priority, can be forwarded on a logical unit assigned the VBR class. Any other logical
units can be assigned UBR, whatever bandwidth is left when the other two classes have used what they need.

Downloader demo watermarks

QoS is configured in the logical unit hierarchy with the set shaping command. UBR is not a choice if CBR or VBR is
configured. If you want to change the setting to UBR, the CBR or VBR setting must be deleted. The following example shows
possible completions for this command.
[edit interfaces at-0/1/0 unit 201]
lab@chicago# set shaping ?
269
 7. Interface Configuration
Possible completions:
+ apply-groups Groups from which to inherit configuration data
cbr Continuous bandwidth utilization (33000..271000000)
queue-length Queue length (1..16383)
> vbr Variable bandwidth utilization
[edit interfaces at-0/1/0 unit 201]
lab@chicago#
Configuring for CBR only requires one value: the highest constant rate at which this logical unit is allowed to transmit.
[edit interfaces at-0/1/0 unit 201]
lab@chicago# set shaping cbr ?
Possible completions:
<cbr> Continuous bandwidth utilization (33000..271000000)
[edit interfaces at-0/1/0 unit 201]
lab@chicago#
CBR is defined in bits per second. Instead of typing out all of the numbers, letters may substitute for a number of zeros. The
letter k can be substituted for 1,000, m for 1,000,000, and g for 1,000,000,000. If you set a CBR of 12m, this is 12 million bits
per second, or bps. In addition to bps, cell per second, or cps, can be used as the CBR value to be configured. Each ATM cell
has 384 payload bits after the header (48 bytes × 8 bits/byte = 384). To calculate the equivalent bits per second, multiply the
number of cells by 384 with a small c behind the value. In the example below, 2,000 cps is configured as the CBR rate. When
shown, the output will be converted into the bit rate as is shown below with a CBR of 768k (768k/2k = 384).
[edit interfaces at-0/1/0 unit 201]
lab@chicago# set shaping cbr 2000c

[edit interfaces at-0/1/0 unit 201]

lab@chicago# show
point-to-point;
vci 2.200;

}www.ebook-converter.com
shaping {
cbr 768k;

family inet {
address 192.168.20.1/30;
}
[edit interfaces at-0/1/0 unit 201]
lab@chicago#
VBR has several different parameters. Since the bandwidth allowed is variable, a normal rate limit and a quick temporary high
limit are defined. In addition, the length of the temporary high limit is also defined. The normal limit for a VBR value is known
as the sustained rate, whereas the temporary high limit for a VBR logical unit is known as the peak rate. The maximum
number of cells allowed at the peak rate before the transmission must drop to the sustained rate is known as the burst length.
The configuration options are shown below:
[edit interfaces at-0/1/0 unit 201]
lab@chicago# set shaping vbr ?
Possible completions:

Downloader demo watermarks

burst
peak
sustained
Burst size (1..255)
Peak rate (33000..271000000)
Sustained rate (33000..271000000)
[edit interfaces at-0/1/0 unit 201]
lab@chicago#

270
 7. Interface Configuration
Note
Even though the rates in the parentheses above seem to allow 271Mbps, the ATM interfaces on router New York are
OC-3, with an actual bit rate limit of approximately 135.5Mbps. Juniper Networks implements a limit of 50 percent
of line rate on OC-12 ATM interfaces for CBR and VBR values of 271Mbps. The following is an example of setting
a VC to 384Kbps sustained rate (normal) and 512Kbps peak rate (high limit) and limiting the peak rate to a 32 cell
burst.
[edit interfaces at-0/1/0 unit 201]
lab@chicago# set shaping vbr sustained 384k peak 512k burst 32

[edit interfaces at-0/1/0 unit 201]

lab@chicago# show
point-to-point;
vci 2.200;
shaping {
vbr peak 512k sustained 384k burst 32;
}
family inet {
address 192.168.20.1/30;
}

[edit interfaces at-0/1/0 unit 201]

lab@chicago#
Building on the configuration for router Chicago, two more units, one each of UBR and CBR are added. In Figure 7-14, the
ATM interface at-0/1/0 is shown with three logical units, each with a different priority assigned.

www.ebook-converter.com
Figure 7-14. ATM QoS Configuration
You configure the unit 58 and unit 162 in the same manner as unit 201. Do not forget that vpi 1 will have to be
added in the atm-options on the physical interface because unit 58 has a VPI of 1. When it is complete, the
configuration will look as follows:
[edit interfaces at-0/1/0]
lab@chicago# show
atm-options {
vpi 0 maximum-vcs 250;
vpi 2 maximum-vcs 250;
vpi 1 maximum-vcs 250;
}
unit 58 {

Downloader demo watermarks

vci 1.90;
shaping {
cbr 1500000;
}
family inet {
address 192.168.60.201/30;
}
271
 7. Interface Configuration
}
unit 162 {
vci 0.67;
family inet {
address 192.168.130.13/30;
}
}
unit 201 {
point-to-point;
vci 2.200;
shaping {
vbr peak 512k sustained 384k burst 32;
}
family inet {
address 192.168.20.1/30;
}
}

[edit interfaces at-0/1/0]

lab@chicago#
This has covered basic ATM interface configuration. VPIs are assigned to interfaces and then the VPI/VCI area is assigned to
the logical units to connect to PVCs. QoS traffic priorities can be assigned to those logical units to give priority to certain
logical units over others.

Serial Interfaces
Serial interfaces come in several different types and speeds. These interfaces are based on the DS hierarchy from DS-0 to DS-3
of the circuit-switched network types discussed in Chapter 2. These interfaces can be either unchannelized or channelized.
Unchannelized DS hierarchy interfaces are referred to as concatenated because all the channels on the interface are linked

www.ebook-converter.com
together, forming one large bandwidth interface.
Interfaces that are multiplexed into smaller streams are channelized. These channels can be bonded together to transmit data
for a logical unit at a certain bandwidth. The root for these channels is the DS-0 or 64Kbps circuit that is used both in the global
and the U.S. DS hierarchy. DS-1, E1, E3, and DS-3 are all very common implementations of the DS hierarchy, each having a
certain number of DS0s. These DS-0s can be grouped together to form a channel of a required bandwidth. If a logical unit only
needs to be capable of 512Kbps, it can be created by assigning eight DS-0s.
When nonconcatenated, the channels must be assigned to create a single logical unit made up of all the assigned channels.
More detail on the DS hierarchy can be found in Chapter 2. The following sections describe how to configure physical, logical,
and channelized T3s and bit error rate test (BERT) interfaces.

Physical T3 Configuration
The T3 physical parameters are configured in the same manner as the SONET interfaces. Remember that nonconcatenated
SONET was derived from the need to multiplex DS circuits. The most common physical properties are configured under the
physical interface and the t3-options hierarchy. Under the [chassis fpc (#) pic (#)] command, the whole PIC
can be configured for nonconcatenation in the same manner as the SONET PICs. By default, the T3 interfaces are

Downloader demo watermarks

concatenated. With a T3 PIC in FPC 2 PIC position 1, the hierarchy and command (set no-concatenate) used to change
concatenation are shown below:
[edit chassis fpc 2 pic 1]
lab@Boston# set ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
272
 7. Interface Configuration
framing Framing mode
no-concatenate Don't concatenate channels
vtmapping VT mapping mode
[edit chassis fpc 2 pic 1]
user@Boston#
The default encapsulation for T3 interfaces is PPP, and the default clocking is internal. These two parameters are configured
directly in the [edit interfaces (interface)] hierarchy. The t3-options hierarchy under the interface contains
T3-specific parameters that can be modified, such as BERT parameters, parity configuration, 16- or 32-bit checksum, and
compatibility-mode configuration, among others, as shown below:
[edit interfaces t3-2/1/0]
lab@Boston# set t3-options ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
bert-algorithm Set BERT algorithm
bert-error-rate Bit error rate to use in BERT test (10^-n) (0..7)
bert-period Length of BERT test (1..240 seconds)
cbit-parity Enable C-bit parity mode
> compatibility-mode Set CSU compatibility mode
fcs Frame checksum
feac-loop-respond Respond to FEAC loop requests
idle-cycle-flag Value to transmit in idle cycles
long-buildout Set hardware to drive line longer than 255 feet
loop-timing Set loop-timing for all T1 channel under CT3
loopback Loopback mode
no-cbit-parity Don't enable C-bit parity mode
no-feac-loop-respond Don't respond to FEAC loop requests
no-long-buildout Don't set hardware to drive line longer than 255 feet
no-loop-timing Don't set loop-timing for all T1 channel under CT3
no-payload-scrambler Don't enable payload scrambling

www.ebook-converter.com
payload-scrambler
start-end-flag
Enable payload scrambling
Set start-end flags on transmission
[edit interfaces t3-2/1/0]
user@Boston#

Note
Do not forget to set clocking on one side of the T3 link to external.

T3 Logical Configuration
With a concatenated interface, logical unit configuration is no different than it is on single-interface ports. A single unit is used
for the family addressing and protocol assignment. Shown here is a concatenated T3 interface configured on router Boston.
Configuring the unit and family inet address is the same as on the previous interfaces in SONET. Notice the clocking
and encapsulation parameters.
[edit interfaces t3-2/1/0]
lab@Boston# show

Downloader demo watermarks

clocking external;
encapsulation cisco-hdlc;
unit 0 {
family inet {
address 192.168.100.1/30;
}
273
 7. Interface Configuration
}

[edit interfaces t3-2/1/0]

lab@Boston#
The output of a show interfaces (interfaces) command is shown below:
lab@Boston> show interfaces t3-2/1/0
Physical interface: t3-2/1/0, Enabled, Physical link is Up
Interface index: 16, SNMP ifIndex: 44
Link-level type: Cisco-HDLC, MTU: 4474, Clocking: External, Speed: T3,
Loopback: None, FCS: 16, Mode: C/Bit parity
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps
Link flags : Keepalives
Keepalive settings: Interval 10 seconds, Up-count 1, Down-count 3
Keepalive: Input: 348 (00:00:01 ago), Output: 360 (00:00:09 ago)
Input rate : 0 bps (0 pps)
Output rate : 0 bps (0 pps)
Active alarms : None
Active defects : None
Logical interface t3-2/1/0.0 (Index 7) (SNMP ifIndex 57)
Flags: Point-To-Point SNMP-Traps Encapsulation: Cisco-HDLC
Protocol inet, MTU: 4470, Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 192.168.100.0/30, Local: 192.168.100.1

lab@Boston>

www.ebook-converter.com
T3 Channelized Configuration
Configuring a channelized interface is a little more complicated. Since a channelized T3 is actually 28 T1s, these T1s can be
individually configured. Logical units are made from groups of DS-0s or DS-1s that are bound together to form a logical
interface. Since the T3 interface defaults to concatenated, the first configuration step is to deconcatenate the interface. This is
done on the entire PIC. If you have a 4-port T3 PIC, all four ports will be changed to channelized mode through the use of the
no-concatenate command. Below, PIC 1 of FPC 2 changed to channelized with the set no-concatenate command
in the [edit chassis fpc (x) pic (x)] hierarchy.
[edit]
lab@Boston# edit chassis fpc 2 pic 1

[edit chassis fpc 2 pic 1]

lab@Boston# set no-concatenate

[edit chassis fpc 2 pic 1]

lab@Boston#
To configure a specific T1 in a T3, a colon and the T1 number is added to the interface name. A T1 #2 located in interface

Downloader demo watermarks

t3-2/1/0 would be named t1-2/1/0:2. This is the third (remember that T1 0 is the first) T1 of the T3 interface in position
2/1/0. Enter the T1 configuration just as a regular interface, as shown below:
[edit interfaces]
lab@Boston# edit t1-2/1/0:2

[edit interfaces t1-2/1/0:2]

274
 7. Interface Configuration
lab@Boston#
Once in the T1 interface configuration hierarchy, the unit can be configured with protocol addressing on the logical units, as
was shown in previous sections.

BERT Configuration
A BERT is used to test the quality of a link. One device loops the receive signal to the transmit link, which sends whatever
comes into the interface back to the sender. The sender then can compare what it has sent to what it receives to ensure that
there are no errors. Any errors are counted and reported. In Figure 7-15, two T3 interfaces, A and B, are connected. The
arrows indicate the path the data takes, from Tx (transmit) on one, to Rx (receive) on the other.

Figure 7-15. A BERT Configuration

If an administrator had reason to believe that the link was not passing traffic properly, one of the T3 interfaces could be looped
to connect the Rx to the Tx. This would resend the same data that came in the interface back to the sender, as Figure 7-16
illustrates. In this example, any data that was sent to T3 A from T3 B would be sent back to T3 B.

www.ebook-converter.com
Figure 7-16. Testing a Looped Interface with a BERT
This loop allows T3 B to put out a stream of characters and compare what was sent to what is received, which in turn allows
testing for errors across the full link. The BER is the Bit Error Rate found during testing. DS-3 B should receive the stream of
123456 exactly as it sent it.
To test a line with the error tester, the far-end connection must be in looped mode. The BERT configuration takes place in the
t3-options of the physical interface, as is shown below. Here are the possible command completions of the set command
(use set b? to show only BERT options):
[edit interfaces t3-2/1/0 t3-options]
lab@chicago# set b?
Possible completions:
bert-algorithm Set BERT algorithm
bert-error-rate Bit error rate to use in BERT test (10^-n) (0..7)
bert-period Length of BERT test (1..240 seconds)
[edit interfaces t3-2/1/0 t3-options]
lab@chicago#

Downloader demo watermarks

The BERT algorithm is the data pattern you are sending. It is important to know the pattern of 1s and 0s that is sent to ensure
that it is received properly. In addition, the transmitted pattern can be observed along different parts of the link using test
equipment, which assists in determining where the pattern is getting corrupted, if appropriate. The following output
demonstrates the possible algorithms that can be selected:
lab@chicago# set bert-algorithm ?

275
 7. Interface Configuration
Possible completions:
all-ones-repeating Repeating one bits
all-zeros-repeating Repeating zero bits
alternating-double-ones-zeros Alternating pairs of ones and zeros
alternating-ones-zeros Alternating ones and zeros
pseudo-2e10 Pattern is 2^10 - 1
pseudo-2e11-o152 Pattern is 2^11 -1 (per O.152 standard)
pseudo-2e15-o151 Pattern is 2^15 - 1 (per O.152 standard)
pseudo-2e17 Pattern is 2^17 - 1
pseudo-2e18 Pattern is 2^18 - 1
pseudo-2e20-o151 Pattern is 2^20 - 1 (per O.151 standard)
pseudo-2e20-o153 Pattern is 2^20 - 1 (per O.153 standard)
pseudo-2e21 Pattern is 2^21 - 1
pseudo-2e22 Pattern is 2^22 - 1
pseudo-2e23-o151 Pattern is 2^23 (per O.151 standard)

[edit interfaces t3-2/1/0 t3-options]

lab@chicago#
Next, the BERT time period is configured. This is how long the test will last. The default is 10 seconds and can be up to 240
seconds. The example below sets it to 30 seconds and shows that the alternating-double-ones-zeros BERT
algorithm has also been set.
[edit interfaces t3-2/1/0 t3-options]
lab@chicago# set bert-period 30

[edit interfaces t3-2/1/0 t3-options]

lab@chicago# show
bert-algorithm alternating-double-ones-zeros;
bert-period 30;

www.ebook-converter.com
[edit interfaces t3-2/1/0 t3-options]
lab@chicago#
The last configurable item, the bit error rate, allows for errors to be inserted intentionally. It is set to 0 errors by default, but
ranges from 0 to 7. If 5 is entered, the BER becomes 10–5, or 1/100,000, and the BERT process would insert 1 error every
100,000 bits. Inserting errors at a specific rate can be helpful in determining the accuracy of the error checking equipment
along the connection. In addition, if the error rate the interface receives is the same as that it sent out, then the connection is
good both ways, and so is the error rate counter.
Once the configuration is complete, the interface must be disabled before the test can be run. The interface is disabled so that
no other data will be present on the link while the interface is sending the test stream. To run the test, the test command
completions you can use for that particular interface are as follows.
lab@Boston> test interface t3-2/1/0 ?
Possible completions:
e1-bert-start Start BERT
e1-bert-stop Stop BERT
e3-bert-start Start BERT
e3-bert-stop Stop BERT

Downloader demo watermarks

feac-loop-initiate
feac-loop-terminate
Initiate FEAC loopback
Terminate FEAC loopback
restart-auto-negotiation Restart Auto Negotiation
t1-bert-start Start BERT
t1-bert-stop Stop BERT
t3-bert-start Start BERT
276
 7. Interface Configuration
t3-bert-stop Stop BERT
lab@Boston>
Once you start BERT, you can show the interface with the extensive option to view the BERT results under the DS-3
BERT section, as is shown below. The show interfaces command output has been cut for brevity to show only the BERT
section of the output.
lab@Boston> show interfaces t3-2/1/0 extensive
Physical interface: t3-2/1/0, Administratively down, Physical link is Up
Interface index: 16, SNMP ifIndex: 44, Generation: 15

<<<output omitted for brevity>>>

DS3 BERT configuration:
BERT time period: 30 seconds, Elapsed: 15 seconds (in progress)
Algorithm: Double alternating ones/zeros, Repetitive (25), Induced Error rate: 10e-0
Bit count : 679742966, Overflows: 0
Error bit count: 217553, Overflows: 0
Error rate: 10e-3.5
LOS status: OK, LOS count: 1, LOS seconds: 15

<<<output omitted for brevity>>>

Notice the error rate. The errors are counted as 1 of every x. If an error occurs every 100 packets, that is 10–2; that is, 1/100 is
10 to the power of negative 2. To stop the complete BERT process, use the bert-stop command shown below:
lab@Chicago> test interface t3-2/1/0 t3-bert-stop
A BERT can be extremely useful when dealing with copper media, which can be more error prone than an optical media type.
It allows the transmission of a set pattern of bits to be sent and the pattern to be checked as it returns.

Aggregated Interfaces
www.ebook-converter.com
Aggregating links means adding them together. If, for instance, you have a 4-port Fast Ethernet PIC on two Juniper Networks
routers, you can use all four ports as one logical interface by aggregating them. This will yield 400Mbps aggregate bandwidth.
Aggregation can be an inexpensive way to increase bandwidth without incurring the cost of new PICs. For instance, an OC-3
SONET interface can have four ports per PIC. If two Juniper Networks routers have an OC-3 POS connection, a second could
be added, and the interfaces could be aggregated for 310Mbps. Ethernet can be aggregated, but the links must be the same
speed. For instance, Fast Ethernet and GigE cannot be mixed.
Aggregation configuration requires creating a single virtual interface to which physical interfaces are assigned. It is the opposite
of the logical unit concept. Logical units are many logical interfaces created in one physical interface. An aggregated interface
is many physical interfaces in a single logical interface. The aggregated interfaces are labeled ae for aggregated Ethernet and
as for aggregated SONET under the [edit interfaces] hierarchy. Once the aggregated interface is created, the same
protocol address families can be added under units in the same manner as a standard interface.
In Figure 7-17, router Chicago and router New York have two Fast Ethernet interfaces directly connected. In the example
below, these two interfaces will be aggregated into a single logical interface and placed in VLAN 50.

Downloader demo watermarks

Figure 7-17. Interface Aggregation
277
 7. Interface Configuration
The logical interface ae0 is created below and VLAN tagging is configured on the interface. An IP address and VLAN are
configured on unit 0.
[edit interfaces]
lab@chicago# edit ae0
[edit interfaces ae0]
lab@chicago# set vlan-tagging

[edit interfaces ae0]

lab@chicago# set unit 0 family inet address 192.168.50.1/30
[edit interfaces ae0]
lab@chicago# set unit 0 vlan-id 50

[edit interfaces ae0]

lab@chicago#
Next, we must configure the chassis for aggregated devices, including the type and number of devices. We wish to aggregate
two Ethernet interfaces.
[edit]
lab@chicago# edit chassis aggregated-devices

[edit chassis aggregated-devices]

lab@chicago# set ethernet device-count 2
[edit chassis aggregated-devices]
lab@chicago#
Lastly, the actual interfaces themselves must be enabled for the 802.3ad Aggregating Protocol and assigned to the aggregated

www.ebook-converter.com
interface ae0.
[edit interfaces]
lab@chicago# set fe-0/0/1 fastether-options 802.3ad ae0
[edit interfaces]
lab@chicago# set fe-0/0/2 fastether-options 802.3ad ae0

[edit interfaces]
lab@chicago#
When the configuration is complete, it appears as shown below (output has been cut for brevity to show only the pertinent
section):
[edit]
lab@chicago# show
version 5.0R3.3;
...cut
}

Downloader demo watermarks

chassis {
aggregated-devices {
ethernet {
device-count 2;
}
}
}
278
 7. Interface Configuration
interfaces {
fe-0/0/1 {
fastether-options {
802.3ad ae0;
}
}
fe-0/0/2 {
fastether-options {
802.3ad ae0;
}
}
ae0 {
vlan-tagging;
unit 0 {
vlan-id 50;
family inet {
address 192.168.50.1/30;
}
}
}
<<<output omitted for brevity>>>
Looking at the ae0 interface below, you can see some interesting things. The Speed is now 200Mbps, the Encapsulation
is now Aggregate, and the Statistics for the interface are labeled as Bundle.
lab@chicago> show interfaces ae0
Physical interface: ae0, Enabled, Physical link is Up
Interface index: 17, SNMP ifIndex: 29
Link-level type: Ethernet, MTU: 1518, Speed: 200mbps, Loopback: Disabled,
Source filtering: Disabled, Flow control: Disabled, Minimum links needed: 1
Device flags : Present Running

www.ebook-converter.com
Interface flags: SNMP-Traps
Current address: 00:90:69:a4:db:f0, Hardware address: 00:90:69:a4:db:f0
Input rate
Output rate
: 0 bps (0 pps)
: 0 bps (0 pps)

Logical interface ae0.0 (Index 10) (SNMP ifIndex 32)

Flags: SNMP-Traps VLAN 50 Encapsulation: Aggregate
Statistics Packets pps Bytes bps
Bundle:
Input : 14 0 1128 0
Output: 14 0 1658 0
Protocol inet, MTU: 1500, Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 192.168.50.0/30, Local: 192.168.50.1,
Broadcast: 192.168.50.3
lab@chicago>
Aggregation is a much less expensive way to increase the available bandwidth between two directly connected routers.

Downloader demo watermarks

Tunnel Interfaces
Tunnel interfaces are another type of nonphysical interface. They exist as a process in the router's memory for performing
certain routing functions. Tunnels create virtual paths through networks that have an entrance point and an exit point. When a
packet travels through a tunnel that spans many routers, it still thinks that it has only traveled through one. Think of it as
279
 7. Interface Configuration
driving through the mountains in a long tunnel. You are not aware of how many mountains and valleys you are driving under.
You are only aware that you went in one side and came out the other.
Tunnels can be used to connect two networks that, perhaps, you wish to have directly attached, but for cost, security, or
technical reasons, you have to connect through another network. These two networks can have their IP traffic tunneled to each
other so they can act as if they are connected to the same router. Since tunnels can be encrypted, this can greatly decrease the
cost of WAN connections for branch offices because they can use Internet connections. Instead of having an extremely
expensive WAN connection over thousands of miles, a company can connect branch offices to a local service provider that
will give the offices a connection the Internet. The branch offices can then set their IP traffic to travel to each other in tunnels
through the Internet, which alleviates the cost of having to connect the branch offices directly to each other with Frame Relay
or ATM.
Two tunnel types that are supported by Juniper Networks routers are GRE and IP encapsulated in IP-only (IP-IP). GRE is a
type of standardized tunnel encapsulation that allows different protocols to be encapsulated inside one another. GRE standards
are defined in RFC 2784. IP-IP tunneling predates the GRE standard. The main difference between GRE and IP-IP is that IP-
IP doesn't have any extra encapsulation header information. The inside IP header follows right after the outside.
An IP packet, when entering the tunnel, will be packaged in another IP header with a different destination address. When the
double packet gets to the destination of the tunnel IP packet, the outer IP encapsulation is stripped away and the original IP
packet is forwarded on.
In Figure 7-18, Company XYZ has its headquarters located in Chicago. When a branch office in London is opened and needs
to be connected to the headquarters network, Company XYZ could pay extremely high fees to get a direct connection from
London back to Chicago, or the company could find a service provider that has connections in both cities and will provide
XYZ with a tunnel.

www.ebook-converter.com

Figure 7-18. Tunnel Configuration

In Figure 7-18, the service provider administers routers Chicago, New York, and London. A GRE interface is configured using
the gr-x/y/z, where x/y/z is the position of the Tunnel PIC (for an IP-IP tunnel, use ip-x/y/z). The service provider
wishes to set up the tunnel and then route any packets destined for the London office to use that tunnel. The tunnel is
configured so that the service-provider-administered interfaces on routers Chicago and London are the endpoints. These IP
addresses will be the source and destination. Following is the Chicago GRE interface configuration; router London's
configuration will be the same, but with reversed source and destination, as follows (with abbreviated output for
brevity).

Downloader demo watermarks

[edit interfaces]
lab@Chicago# set gr-4/0/0 unit 0 tunnel source 10.0.16.1

[edit interfaces]
lab@Chicago# set gr-4/0/0 unit 0 tunnel destination 10.0.32.1

280
 7. Interface Configuration
[edit interfaces]
lab@Chicago# show
gr-4/0/0 {
unit 0 {
tunnel {
source 10.0.16.1;
destination 10.0.32.1;
}
family inet;
}
}
<<<output omitted for brevity>>>
To get the packets destined for the London network to go through the tunnel, a static route for that network with a next-hop
of the tunnel interface is added.
[edit routing-options]
lab@Chicago# show
static {
route 10.0.16.0/24 next-hop gr-4/0/0.0;
}
[edit routing-options]
lab@Chicago#
Now, anytime a packet from the headquarters network is destined for the London branch network, it will take the tunnel.
Tunnels are virtual connections that allow routers to think they are directly connected to another network when, in fact, they
are not. The requirement to be directly connected can be bypassed by encapsulating one set of IP packets in another as they
enter the tunnel. Upon tunnel egress, the outside encapsulation is stripped, and the original packet continues on.

www.ebook-converter.com
Loopback
IP devices come with an internal IP address of 127.0.0.1 that is for use internal to the device. The loopback interface is
used as an IP address holder that is independent of any other interface. Configuring a loopback interface creates a logical
internal IP interface for a router that can be used to identify the router to other routers. This use of the loopback as an
identification will be discussed in Chapter 8.
As you will see in Chapter 8 and beyond, when a second IP address is configured on the lo0 (Loopback0) interface, it will
serve as a stable identifier for the router to use in communications protocols. If a router uses an IP address of an interface to
identify itself to other routers, other routers could lose communications if that interface failed. This is because another device
cannot talk to a down interface. The lo0 interface, however, is always up as long as the router is up.
The addressing for the loopback interface is configured just like it is on other interfaces—the family type is assigned, and then
the address is configured. Even though there is no physical presence, the interface has both a physical and unit hierarchy
configuration to maintain configuration consistency. The following is a configured lo0 interface with the host IP address
192.168.5.2:
[edit interfaces lo0]
lab@chicago# show
Downloader demo watermarks
unit 0 {
family inet {
address 192.168.5.2/32;
}
}

281
 7. Interface Configuration
[edit interfaces lo0]
lab@chicago#
When a show interfaces command is used, the loopback interface information is displayed just as that of a typical
network interface is, with the physical and logical unit sections separated, as shown below.
lab@chicago> show interfaces lo0
Physical interface: lo0, Enabled, Physical link is Up
Interface index: 5, SNMP ifIndex: 7
Type: Loopback, MTU: Unlimited
Device flags : Present Running Loopback
Interface flags: SNMP-Traps
Link flags : None
Input packets : 10
Output packets: 10

Logical interface lo0.0 (Index 3) (SNMP ifIndex 25)

Flags: SNMP-Traps Encapsulation: Unspecified
Protocol inet, MTU: Unlimited, Flags: None
Addresses, Flags: Is-Default Is-Primary
Local: 192.168.5.2
The loopback is an internal interface kept by the router as an identifier. As long as the router is functional, the loopback will be
functional, allowing the router to possess an IP address for identification that will not be lost if an interface or link fails.

Chapter Summary
The interface is the point at which a router sends data to another device. Since the mission of a router is to forward data
packets through networks, the interface is the sending and receiving component that allows that forwarding to take place.

www.ebook-converter.com
Properly configuring an interface is the first step to the network configuration of a router. This configuration encompasses the
lowest three layers of the OSI model. Physical, data link, and network configurations all take place at the interface and logical
unit hierarchies.
Logical units allow the router to be connected to many more networks than if just the physical interfaces were to be used.
Thousands of network links can be configured on one router through the use of logical units, which Juniper Networks calls
logical units. These units are where the three family addresses are enabled. Even if an interface is not going to have multiple
logical units configured, the single interface has to be configured under a unit.
These interfaces are grouped together in a PIC mounted in a FPC. The FPC can have different types of PIC interfaces
installed, but individual PICs have the same type of interface. There is a system to identify these FPCs with PICs housing
interfaces with logical units. Juniper Networks has a naming convention that identifies them in a specific order from FPC to
logical unit. The two larger routers (M40 and M160) have vertical FPCs, whereas the M5, M10, and M20 have horizontal ones.
The naming convention for the three small chassis is actually the same as that for the larger two routers turned on their right
side (the administrator's right side facing the interfaces).
There are two main components to configuring the interfaces: the physical and the logical. The physical interface has properties
and parameters that affect the entire port and all of the logical units on that port. This can affect timing, signaling, framing, and
the like. The logical interface gets the NBMA and IP addressing assigned, along with any other family-associated configuration.

Downloader demo watermarks

Different interface types with different features that can be implemented have been discussed. Ethernet and the associated
speeds of Ethernet allow VRRP and MAC address filtering. ATM offers a QoS class that can be assigned to a logical unit.
SONET (ATM, POS, and nonconcatenated) offers APS link fail-over that can even be configured between two different
routers. Ethernet and SONET allow links to be aggregated to form a larger virtual link when more bandwidth is required
between two routers. SONET interfaces were originally formed to multiplex data stream circuits, which can also be
concatenated or not.
282
 7. Interface Configuration
Tunnel and loopback interfaces were also discussed; both interfaces have no physical components. These interfaces reside
purely in the processes of the router; they have specific and important functions though. The tunnel interface allows a virtual
connection to be set up through a network to another tunnel interface. This allows the two networks connected through the
tunnel to think they are directly connected. The loopback interface is a placeholder for an independent IP address that will not
fail unless the router does. This function allows the router to keep a stable identification.
Some of the configuration in this chapter is required for basic communication just to set up a network. Some of the features
described provide more stability and scalability in the network once it is up. The router is now able to communicate with
another device that is directly connected either physically or virtually. How does that help pass data through a network and
what communications does this enable? That is the subject of Chapter 8.

Bibliography

www.ebook-converter.com

Downloader demo watermarks

283
[ch07bib01] Kevin Downes,, et al. Internetworking Technologies Handbook, 2nd ed.,
Cisco Press, <year>1998</year>.
[ch07bib02] Walter Goralski,. SONET, 2nd ed. McGraw-Hill, <year>2000</year>.
[ch07rfc1483] IETF RFC—RFC 1483, Multiprotocol Encapsulation over ATM
Adaptation Layer 5. J. Heinanen. 1993.
[ch07rfc2338] IETF RFC—RFC 2338, Virtual Router Redundancy Protocol. S. Knight,
et al. 1998.
[ch07bib05] David McDysan,, and Darren L. Spohn. ATM Theory and Applications.
McGraw-Hill, <year>1998</year>.
[ch07bib06] www.atmforum.org
[ch07bib07] www.juniper.net

www.ebook-converter.com

Downloader demo watermarks

284
 8. IGP Routing Protocol Configuration
Chapter 8. IGP Routing Protocol Configuration
Everything you have read so far has allowed you to bring a router online, manage the files, manipulate system
software, and even configure a direct network connection between two routers. Now the fun starts. Routing
protocols are the bread and butter of all complex IP-based networks. Think of a routing protocol as a language that
allows the routers to tell each other about different networks and how to get to those different networks.
This chapter begins with an overview of routing protocols, describing what they are and what they are used for.
Different methods of implementing routing protocols are explored, and different parts of routing protocols are
explained.
After the overview, three different interior gateway routing protocols are examined: RIP, OSPF, and IS-IS. You will
also see several examples of configuration on Juniper Networks routers.

Routing Protocol Primer

Originally, all of the connections between routers were manually entered static routes. Each router had to have an
entry for every network, along with explicit paths by which to reach those other networks. Every time one network
was added, every router had to be manually configured with an entry for that network. In addition, if a failure
occurred, these entries would have to be changed, again manually, to route around the break. This could cause
quite an administrative headache to monitor as a network grew.
Dynamic routing protocols solved this administrative nightmare by enabling routers to tell each other of the
networks to which they were connected. They also allowed routers to decide on a path through a network based on
the status of the networks in between. This relieved the administrator from having to reconfigure the routers every
time something changed. Suddenly, the prospect of drastic network growth and redundancy was not so frightening.
Additions, deletions, modifications, and failures of networks no longer required the intervention of administrators at

www.ebook-converter.com
every network hop.
Dynamic routing protocols can be classified into two groups by function: interior and exterior routing. IGPs, or
Interior Gateway Protocols, are usually used within a network under a single administrative entity. This
administrative entity could be a single company or a single ISP. A very large company or ISP might have to break a
network into several administrative entities to maintain manageability. A network under a single administration is
called an autonomous system, or AS. EGPs, or Exterior Gateway Protocols, are the protocols that are used to
connect different ASs and will be discussed in Chapter 9.
A router's main function is to connect networks together for communication at Layer 3, the network layer of the
OSI model. A Juniper Networks router can be directly connected to hundreds of networks. One router telling
another router of its connected networks is known as advertising. Advertisements need to be standardized so that
routers from different manufacturers can all understand each other.
In Figure 8-1, routers A and B are connected through Network 300. Router A has a direct connection to Network
100, and router B has a direct connection to Network 200. Router A sends an advertisement to router B advertising
Network 100. When a device on Network 200 sends data destined for Network 100, router B understands that it
Downloader demo watermarks
should forward that data out of the interface connected to router A (via Network 300) for forwarding. Router B
knows router A as the next-hop for Network 100 because it is the next router in the route towards Network 100, the
destination.

285
 8. IGP Routing Protocol Configuration

Figure 8-1. Route Advertisement

As a router receives advertisements from neighboring routers, it will store them in a routing information base (RIB),
which will allow the router to make the best decision as to which direction or route it will use to forward packets to
a particular destination network.
With some protocols, routers will blindly send out an advertisement containing its entire set of known networks.
With other protocols, routers can form route exchange relationships called adjacencies. This communication
between adjacent routers allows the routers to keep track of the data they have sent to each other so the whole set
of advertisements does not have to be sent out every time.
Routers initially tell each other of their own directly connected networks. Routers will then pass on the information
they have learned from close neighbors to other close neighbors. This creates a growing chain of knowledge for
routers to use to forward to destinations many routers away. One issue that can complicate things is the availability
of more than one way to get to a particular destination network. A decision has to be made as to which path the
router will prefer.

Router Metrics

www.ebook-converter.com
When a router receives information about different routes to a destination network, it has to make a decision as to
which route is best. This is known as a routing decision. Different routing protocols will favor different elements of
route information over others. These elements of information, such as how far away a router is (how many routers
away, also known as the hop count) or which are the fastest links to a destination, are collectively known as routing
metrics. Metrics are informational units that can be measured and compared. If the distance to a network is a
determining factor in the routing decision, then the hop count is a metric. Metrics can be different things for
different protocols. RIP might use just the hop count. OSPF uses hop count and bandwidth availability to create a
metric for decision-making purposes.
Metrics can be described as additive in nature. These additive metrics are known as cost functions. The farther an
advertisement travels from the originating routers, the larger the metric grows. The metric to the destination
network in the advertisement is increased as it crosses each hop. In Figure 8-2, notice there are different metrics
associated with the networks connecting the routers. The metric between routers A and B is 2, while the metric
between routers A and D is 3. Router A advertises network 10.0.1.0/24 to routers B and D. When routers B
and D receive the advertisement, they forward their knowledge to router C with the associated metric for that link
added, as shown in Figure 8-3.

Downloader demo watermarks

286
 8. IGP Routing Protocol Configuration

Figure 8-2. Sending Advertisements to Other Routers

Figure 8-3. Forwarding Advertisements

Router C receives the two advertisements and computes which path to 10.0.1.0/24 has the lower metric, as
Figure 8-4 shows. When the workstation connected to router C sends data to router C intended for the device on
the 10.0.1.0/24 network, router C has two different routes to choose from. From the previous advertisements,
router C knows that 10.0.1.0/24 has a metric of 4 when going through the interface connected to router B. The
path to the same network has a metric of 6 when going through router D. Router C will make a decision to forward
the data out of the interface connected to router B for 10.0.1.0/24. The route through D can be used as a
backup, in case the route through router B suffers an outage.

www.ebook-converter.com
Figure 8-4. Evaluating Metrics
Metrics may also be manipulated administratively. This allows an administrator to change metrics, thereby causing
routers to change their forwarding behavior as the administrator desires. An administrator for the example shown in
Figure 8-4 could have manually changed the metric of the connection between router B and router A to 5. When
the advertisement reached router C, the total metric would have added up to 7, forcing router C to choose router D
for traffic forwarded to network 10.0.1.0/24.
Approved standards can describe the proper functioning of routers, routing protocols, connected networks, links,
and the way all of these are advertised to other devices. These actions comprise some of the standards for routing

Downloader demo watermarks

protocols. This is how a router learns about the network.

Distance Vector Versus Link State

Routing protocols can be also be classified into two different types that have to do with how the information they
287
 8. IGP Routing Protocol Configuration
receive is stored and how that information is sent to their neighbors. These two protocol types are distance vector
and link state. Distant vector protocols are blind to nondirectly connected networks and routers. They only keep
track of how many hops away a destination network is and out of which interface the router needs to send the
packet to get the packet to the next-hop. They have no sense of place in a network. Every router passes on every
route advertisement it receives.
Link state protocols, on the other hand, keep track of all the routers and routes in the network by keeping a
database on the topology of the network. When a router's interface is configured, the network on which the
interface resides is considered directly connected. Routers send their directly connected network information to
each other. One router will pass on another router's information without changing it. As this information is passed
around, each router can create a topological map of all the routers in the network, the links that connect them, and
the state of those links (hence the name link state).
Knowing the state of the networks and links allows a router to respond to changes in a network more quickly. The
term convergence describes a state when all of the routers have the same correct information on the state of the
network after a change. When a change occurs, such as a link failure, the convergence time is the time it takes for
the information to reach all of the routers (to the routers farthest from the outage) and for all of the routers to
recalculate their new routes. As opposed to a distance vector protocol, which has to send entire routing tables, link
state protocols allow for faster convergence by sending only the updated data.
If a link fails, routers can notify each other immediately or can wait for a period of time before telling the other
routers about the link failure. If a link is having problems and goes up and down many times (which is known as a
route flap condition), immediate notification can drastically increase the traffic on a network, causing a rippling
effect of the updates the point of failure. The alternative is to wait a certain amount of time before sending out the
news of a link failure. In addition, if a route to a distant network is not updated within a certain period of time, it
will be considered to be down.

www.ebook-converter.com
Juniper Networks Router Configuration
Basic configuration of routing protocols in JUNOS takes place in the [edit protocols (protocol)
command hierarchy of the CLI, where (protocol) represents which protocol you wish to configure. Most of the
configuration for the protocols is done in this command hierarchy. An example of a protocol action would be
configuring a protocol to run on an interface. Shown here is a CLI example of the protocols that can be configured
on a Juniper Networks router.
lab@Chicago> configure
Entering configuration mode

[edit]
lab@Chicago# edit protocols

[edit protocols]
lab@Chicago# set ?
Possible completions:

Downloader demo watermarks

+ apply-groups
> bgp
> connections
Groups from which to inherit configuration data
BGP options
Circuit cross-connect configuration
> dvmrp DVMRP options
> igmp IGMP options
> isis IS-IS options
288
 8. IGP Routing Protocol Configuration
> ldp LDP options
> mpls Multiprotocol Label Switching options
> msdp MSDP options
> ospf OSPF configuration
> pim PIM options
> rip RIP options
> router-discovery ICMP router discovery options
> rsvp RSVP options
> sap Session Advertisement Protocol options
> vrrp VRRP options
[edit protocols]
lab@Chicago#
Here you have learned what a routing protocol is. It is a set of communication standards that routers can use to
advertise networks. The information carried in these advertisements allows other routers to make an informed
decision as to the best route to use when forwarding traffic to a particular destination. Now we will introduce
specific routing protocols that can be used on Juniper Networks routers.

RIP
RIP is one of the oldest IGP protocols used today. RIP has its roots in the U.S. Department of Defense ARPANET
in 1969. There are also components in RIP from early Xerox Network Systems (XNS) and Free BSD (Berkeley
Software Design, Inc.) UNIX routing applications. (More history on RIP can be found at www.ietf.org/rfc.html
RFC 1058.)
There are two RIP versions that are still supported by most routers today: version 1 (RIPv1) and version 2 (RIPv2).
RIPv2 has been standardized by the IETF in RFC 2453. RIPv1 was never completely standardized, and although it

www.ebook-converter.com
is still used in some cases, its use is not recommended owing to its lack of flexibility. However, RIPv1 will be
covered here because it is still supported by Juniper Networks routers.

Theory of Operation
RIP is simple—it is the quick and easy routing protocol. Its simplicity and low processing requirements are two
reasons the implementation of RIP networks persists. RIP uses the Bellman-Ford algorithm (distance vector) to
determine the path to a destination network. When a RIP router learns routes from neighboring routers, it adds
these routes to its routing table and forwards a copy of all of the routes out of RIP-enabled interfaces every 30
seconds. An entry is made up of the destination network and the number of hops to get there. If there are 500
network route entries in the routing table, all 500 entries will be sent out of RIP interfaces every 30 seconds. This
can use considerable network bandwidth as the size of the network grows.
The RIP update consists of the destination prefix and the metric for each known network. When a RIPv1 router has
not had a network route updated from another for 180 seconds, it marks that router's networks as unreachable by
setting the metric to 16. If another 60 seconds pass, and it still has not received a network update for that network,
it will remove the network from the routing table.
Downloader demo watermarks
RIPv1 has two very important limitations. It can only be used in classful route advertisements and has a high metric
limit of 15. The classful route advertisement limitation is significant because it prevents RIPv1 from using CIDR
and VLSMs, which were created to drastically increase network address flexibility. The RIPv1 metric limit of 15
means that this routing protocol can only be used in smaller networks. If the metric for a RIPv1 network is set to

289
 8. IGP Routing Protocol Configuration
16, the network is considered unreachable by the router. A metric of 16 is also known as count-to-infinity because
it is beyond what RIP considers reachable.

RIP Metrics
RIP only uses one metric—hop count. A network segment is considered to be the link between two routers. In
Figure 8-5, router A has two different paths that it can use to forward packets toward network 10.10.10.0/24.
When router B advertises 10.10.10.0/24 to router A, it advertises a metric of 1. Adding the directly connected
link between router A and router B, router A sees 10.10.10.0/24 as two hops away, through router B. Router B
also advertises 10.10.10.0/24 to router C as one hop away. Router C adds a hop and advertises
10.10.10.0/24 as two hops away. Router A then adds a hop for the directly connected interface and sees
10.10.10.0/24 as three hops away through router C. Router A compares the two potential paths to the
destination network. The route through router B is entered into the routing table because it has the lowest metric.

Figure 8-5. RIP Metrics

Loop Avoidance

www.ebook-converter.com
The nature of distance vector can cause routing loops. In Figure 8-6, you can see a routing loop form. Network
10.10.1.0 is attached to router A. Router A advertises network 10.10.1.0 to router B. Router B then
advertises it to router C. Router C then advertises it to router D. Finally, Router D advertises the network back to
router A.

Downloader demo watermarks

Figure 8-6. Routing Loops
If network 10.10.1.0 has a malfunction, router A will send the update to router B and so on. Before those
updates can finish propagating through the network, router D could be telling router A that it knows how to get to
network 10.10.1.0. Router A may then start sending traffic bound for 10.10.1.0 to router D, thinking router
D still has a viable route to 10.10.1.0.
290
 8. IGP Routing Protocol Configuration
There are three features that RIP uses to assist in preventing routing loops and keeping routing information correct:
split horizon, split horizon with poison reverse, and triggered updates. Split horizon states that no network
advertisement will be sent out of the same interface through which it was received. This does help in preventing
loops, but it is slow to timeout the routes that might cause loops.
Poison reverse is another RIP feature that is implemented with split horizon. With split horizon only, potentially
loop-causing routes must timeout before being withdrawn. Split horizon with poison reverse allows that route to
always be advertised out of the incoming interface, but with an assigned metric of 16, which is considered
unreachable. Split horizon has advantages with and without poison reverse. A disadvantage of not using poison
reverse is long convergence times after a network change. When new routes are added that have a lower metric, or
a lower metric route fails, the routes must be timed out before they can be removed from the routing tables. An
advantage of not using poison reverse is that the routing updates are smaller because they only have to include the
best routes. What happens when adding poison reverse to split horizon? The advantages and disadvantages are
reversed. Network changes can be propagated quickly through the network because routes will not be removed
from the updates, just labeled unreachable, but all of the unusable routes in the update waste bandwidth when
updates are sent. This keeps RIP from being used efficiently in all but the smallest networks.
Triggered updates assist these other two features in propagating changes as soon as they happen. Triggered updates
allow a router to send an update almost immediately after a metric change. The advantage for triggered updates is
the rapid convergence time of the network. The disadvantage is the very large amount of excess network traffic
that can be generated in a large RIP network with frequent changes.

RIPv1 Versus RIPv2

The main difference between RIPv1 and RIPv2 is classless routing. RIPv2 incorporates the addition of the network
mask in the update to allow classless routing advertisements. This is extremely important for the flexibility needed
to efficiently utilize the network assignments for an ever-shrinking pool of IP addresses.

www.ebook-converter.com
There are other differences between RIPv1 and RIPv2. In RIPv2, the destination address for the updates is
multicast, instead of broadcast, as in RIPv1. This reduces the burden on network devices that do not need to listen
to RIP updates. With broadcast, every device in the broadcast domain must at least open the IP packet and process
the initial information to determine relevance. With multicast addressing, if a device needs that information, it will
listen to that specific address. If it does not need the RIP information, it does not have to process the multicast
address. The multicast address RIPv2 sends to is 224.0.0.9.
Another addition to RIPv2 is authentication. Authentication is used to ensure that routes being distributed
throughout the network are coming from authorized sources.

RIP Design Principles

If you are designing a network, only use RIP if you must. All Juniper Networks routers have enough processing
power to handle more robust and efficient routing protocols, such as OSPF or IS-IS. RIP may sometimes be used in
cases where Juniper Networks routers are being installed in a network already running RIP, for instance, before

Downloader demo watermarks

migrating to OSPF or IS-IS.
If you decide to use RIP, the next decision is which version to use. RIPv2 should be used if possible. Classless
routing, multicast updates, and authentication are advantages of RIPv2 over RIPv1. Since RIPv1 and RIPv2 can
both reside on an interface of a Juniper Networks router, a Juniper Networks router can be used as a gateway
between version types or for upgrading from RIP to OSPF.
291
 8. IGP Routing Protocol Configuration
Either RIP version should be monitored closely to ensure the paths the router is choosing for forwarding are the
most desirable. It is easy for a situation to occur in which RIP is sending data to destinations over very small
bandwidth links because its only metric is hop count.
Figure 8-7 illustrates a network running RIP. Because the number of hops to reach 10.10.1.0/24 from router A
is through the T1 link to router B, router A will ignore the faster T3 links between routers A and C and routers C
and B. Manual configuration of metrics on the direct link between routers A and B would be required to ensure that
RIP saw that path as having a higher hop count and, therefore, as less desirable.

Figure 8-7. RIP Path Evaluations

Since RIP sends the entire routing table out every 30 seconds, as the network grows so does the entire routing table
and all of the updates with it. RIP should be monitored to ensure that network congestion is not ensuing. Even using
RIPv2 with multicast updates, the updates will still take up valuable bandwidth.

Basic RIP Configuration

RIP is configured in two easy steps:

www.ebook-converter.com
1.

2.
Create a policy that will export routes from the routing table that RIP can advertise.
Add an interface to the RIP process so the interface may be allowed to advertise RIP routes.
In Figure 8-8, two routers will advertise their directly connected networks to each other using RIP.

Figure 8-8. RIP Configurations

Downloader demo watermarks

The first step in configuring RIP is to create a policy that will export routes from the routing table that RIP can
advertise. (Importing and exporting routing policy is discussed in detail in Chapter 11.) You create a policy in the
[edit policy-options] hierarchy level. We want RIP to advertise all directly connected networks, so in this
example, we will create a policy named rip1 on each of the three routers that export the directly connected
routes. Below, the configuration steps are followed by explanations of what the commands accomplish:

292
 8. IGP Routing Protocol Configuration
[edit]
lab@Chicago# edit policy-options
This enters the policy-options hierarchy.
[edit policy-options]
lab@Chicago# edit policy-statement rip1
This creates a policy-statement named rip1.
[edit policy-options policy-statement rip1]
lab@Chicago# set from protocol direct
This determines a match condition for directly connected routes.
[edit policy-options policy-statement rip1]
lab@Chicago# set then accept
This accepts the routes that meet the match condition.
[edit policy-options policy-statement rip1]
lab@Chicago# up
[edit policy-options]
lab@Chicago# show
<----- shows all configured policy-options
policy-statement rip1 {
from protocol direct;
then accept;
}

www.ebook-converter.com
[edit policy-options]
lab@Chicago#
The second step is to configure a RIP group that will represent all RIP neighbors that can be advertised to in the
same manner. Under the named group, the export policy statement is configured, and the interface through which
RIP will export that policy statement is selected.
[edit]
lab@Chicago# edit protocols rip
[edit protocols rip]
lab@Chicago# edit group boston
This creates group called boston.
[edit protocols rip group boston]

Downloader demo watermarks

lab@Chicago# set export rip1
This applies the policy-statement to generate advertisements.
[edit protocols rip group boston]
lab@Chicago# set neighbor fe-0/0/1

293
 8. IGP Routing Protocol Configuration
This tells RIP which interface will send those advertisements.
[edit protocols rip group boston]
lab@Chicago# up

[edit protocols rip]

lab@Chicago# show
group boston {
export rip1;
neighbor fe-0/0/1;
}

[edit protocols rip]

lab@Chicago# commit
commit complete

[edit protocols rip]

lab@Chicago#
RIP has now been configured on both Chicago and Boston. When showing the routing table of Chicago, we see the
routes learned from RIP. Chicago has network 30.30.30.0/24 via interface fe-0/0/1. The next-hop is the
interface on Boston. Chicago has learned this because of the advertisement for this network from Boston that was
received on Chicago's fe-0/0/1.0 interface. In addition, there is a multicast address of 224.0.0.9/32 that
has been added to the routing table. These addresses are highlighted below. This is the multicast address that RIPv2
uses to send updates to. This address is added when RIPv2 is implemented.
lab@Chicago> show route
inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)

www.ebook-converter.com
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 *[Direct/0] 07:26:38
• via fe-0/0/2.0
10.0.0.1/32 *[Local/0] 07:26:39
Local
30.30.30.0/24 *[RIP/100] 00:02:59, metric 2
51.0.0.0/24 *[Direct/0] 07:26:38
• via fe-0/0/1.0
51.0.0.1/32 *[Local/0] 07:26:39
Local
224.0.0.9/32 *[RIP/100] 00:03:22, metric 1

lab@Chicago>
On Boston, 10.0.0.0/24 is learned from Chicago, so Boston has added the entry into its routing table.
lab@Boston> show route
inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
Downloader demo watermarks
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24
30.30.30.0/24
*[RIP/100] 00:03:38, metric 2
*[Direct/0] 07:23:51
• via fe-0/0/1.0
30.30.30.2/32 *[Local/0] 07:23:51

294
 8. IGP Routing Protocol Configuration
Local
51.0.0.0/24 *[Direct/0] 07:23:51
• via fe-0/0/0.0
51.0.0.2/32 *[Local/0] 07:23:51
Local
224.0.0.9/32 *[RIP/100] 00:12:27, metric 1

lab@Boston>
RIPv1 and RIPv2 can be run simultaneously. You can use this feature to migrate an existing RIPv1 network to one
running RIPv2. In addition, this allows a Juniper Networks router to communicate and interact with older routers
that might not have the ability to run RIPv2. Configuring the router to send and receive specific versions of RIP can
be done in one of two places:
1. Under the main RIP heading
2. Individually under the group
This allows the grouping of RIPv1 and RIPv2 neighbors. Juniper Networks routers receive both RIPv1 and RIPv2
and send RIPv2 as a default. Below, RIP sending remains RIPv2 by default while RIP receiving has been set for
RIPv2 only:
[edit protocols rip]
lab@Chicago# set receive ?
Possible completions:
both Accept both RIPv1 and RIPv2 packets
none Do not receive RIP packets
version-1 Accept RIPv1 packets only

www.ebook-converter.com
version-2 Accept only RIPv2 packets
[edit protocols rip]
lab@Chicago#

[edit protocols rip]

lab@Chicago# set receive version-2
[edit protocols rip]
lab@Chicago# show
send version-2;
receive version-2;
group boston {
export rip1;
neighbor fe-0/0/1.0;
}

RIP Authentication
Downloader demo watermarks
As stated earlier in this section, RIPv2 allows for authentication. You can use authentication to ensure that routers
or hosts do not inject any routes not configured by the authorized administrators. This assists an administrator in
having the most control over which routers can communicate with each other and what networks they can
advertise.
Juniper Networks routers can use simple text passwords or MD5 authentication. Plain-text passwords are passed
295
 8. IGP Routing Protocol Configuration
through the network in simple, readable form, although when the password is typed in plain text in the CLI, it will
appear scrambled when shown in CLI output. MD5, or message digest version 5, passes encrypted keys so
passwords cannot be readily “snooped” on the network. A shared key authenticating the reader, in this case a
router, on the other end is the only way to view the contents of the message.
In the following example, an authentication-type of simple and a password of juniper01 are
configured. Following the configuration code, sample CLI output is also shown, demonstrating that the password
juniper01 has been encrypted by the router.
[edit protocols rip]
lab@Chicago# set authentication-type simple

[edit protocols rip]

lab@Chicago# set authentication-key juniper01

[edit protocols rip]

lab@Chicago# show
send multicast;
receive version-2;
authentication-type simple;
authentication-key "$9$0Eus1EyM87s2alK2aZU.mO1RErevWL"; # SECRET-DATA
group chicago {
export rip1;
neighbor fe-0/0/1.0;
}

[edit protocols rip]

lab@Chicago#

www.ebook-converter.com
RIP Parameters
RIP has several parameters that can be adjusted to fine tune network configuration: metrics, message-size, and
reserved-field validation for RFC compliance. Metrics are the most important. Administratively manipulating
metrics allows the administrator to pick the path the data will take through the RIP network. Juniper Networks
routers can change the number of routes the update contains to make the updates more efficient. This number can
range from 25 (default) to 255.
The command message-size is used either in the global RIP configuration or can be specified by neighbor
under the group, as shown next:
[edit protocols rip group chicago]
lab@Boston# set neighbor fe-0/0/0 message-size ?
Possible completions:
<message-size> Number of route entries per update message (25..255)

Downloader demo watermarks

[edit protocols rip group chicago]
lab@Boston# set neighbor fe-0/0/0 message-size
You should set the reserved fields of RIP updates to zero. By default, updates that do not comply with this standard
are dropped. If interoperability requires these updates to be received and acted on, then the no-check-zero
parameter can be used, as shown in the help context below.
296
 8. IGP Routing Protocol Configuration
[edit protocols rip group boston]
lab@Chicago# set neighbor fe-0/0/1 ?
Possible completions:
<[Enter]> Execute this command
advertise-default Generate advertisements for 0/0 with given metric (1..15)
apply-groups Groups from which to inherit configuration data
authentication-key Authentication key (password)
authentication-type Authentication type
check-zero Check reserved fields on incoming RIPv1 packets
import Import policy
message-size Number of route entries per update message (25..255)
metric-in Metric value to add to incoming routes (1..15)
no-check-zero Don't check reserved fields on incoming RIPv1 packets
receive Configure RIP receive options
send Configure RIP send options
| Pipe through a command
[edit protocols rip group boston]
lab@Chicago# set neighbor fe-0/0/1

Manipulating RIP Metrics

There are two ways to manipulate RIP metrics: incoming to the router and outgoing from the router. If a metric-
in is manipulated, it affects the advertisement as it enters the router, before it goes to the routing table. If the
metric-out is adjusted, then it changes the hop count to that which was advertised from the originating router.
Metric-in is used globally in RIP. This means it is configured directly in the [edit protocol rip] area
and affects all groups at the same time. Metric-out, on the other hand, can be specified by group. This allows an

www.ebook-converter.com
administrator to advertise routes differently depending on group.
In Figure 8-9, Chicago has network 192.168.254.0/24, and will advertise it to Boston and Washington D.C. If
Boston and Washington D.C. were in two different groups, Chicago could set the metric-out differently to
affect which way they send traffic. If Chicago keeps the default metrics, Boston and Washington D.C. will use their
directly connected links to forward to 192.168.254.0/24.

Downloader demo watermarks

Figure 8-9. RIP Metric Configuration
Looking at Boston's routing table, you will notice that the route for the network 192.168.254.0/24 is
forwarded out of interface fe-0/0/0, which is directly connected to Chicago with the address in that network of
192.168.254.1. When Chicago's metric-out to group Boston is manipulated to add three hops, Boston will
297
 8. IGP Routing Protocol Configuration
now forward packets bound for 192.168.254.0/24 to Chicago through Washington D.C.
lab@Boston> show route
inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 *[RIP/100] 00:00:12, metric 2
30.30.30.0/24 *[Direct/0] 1d 00:23:18
> via fe-0/0/1.0
30.30.30.2/32 *[Local/0] 1d 00:23:18
Local
51.0.0.0/24 *[Direct/0] 1d 00:23:18
• via fe-0/0/0.0
51.0.0.2/32 *[Local/0] 1d 00:23:18
Local
192.168.254.0/24 *[RIP/100] 00:00:12, metric 2
224.0.0.9/32 *[RIP/100] 00:00:14, metric 1

lab@Boston>
Chicago has a metric-out added to the Boston group, changing the metric on the received routes from Chicago
by adding three hop counts to each route.
[edit protocols rip]
lab@Chicago# edit group boston
[edit protocols rip group boston]
lab@Chicago# set metric-out 3

www.ebook-converter.com
[edit protocols rip group boston]
lab@Chicago# show
metric-out 3;
export rip1;
neighbor fe-0/0/1.0;

[edit protocols rip group boston]

lab@Chicago#
Looking at the Boston routing table, the route for 192.168.254.0/24 from Chicago now has a higher metric
than the route from Washington D.C. Boston enters the new lowest metric path through Washington D.C. out fe-
0/0/1 into the routing table.
lab@Boston> show route
inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
Downloader demo watermarks
10.0.0.0/24
30.30.30.0/24
*[RIP/100] 00:00:06, metric 2
> to 30.30.30.1 via fe-0/0/1.0
*[Direct/0] 1d 00:33:42
>via fe-0/0/1.0
30.30.30.2/32 *[Local/0] 1d 00:33:42

298
 8. IGP Routing Protocol Configuration
Local via fe-0/0/1.0
51.0.0.0/24 *[Direct/0] 1d 00:33:42
> via fe-0/0/0.0
[RIP/100] 00:00:06, metric 3
> to 30.30.30.1 via fe-0/0/1.0
51.0.0.2/32 *[Local/0] 1d 00:33:42
Local
192.168.254.0/24 *[RIP/100] 00:00:06, metric 3
> to 30.30.30.1 via fe-0/0/1.0
224.0.0.9/32 *[RIP/100] 00:10:38, metric 1
lab@Boston>
This has been a quick explanation of manipulating RIP metrics in a Juniper Networks router. Be advised that this is
something to be done with care. Doing this incorrectly can cause loops or, at least, suboptimal routing.

Checking RIP Operation

You can check the operation of the RIP process with some basic commands. The first thing that can be checked is
the presence of RIP routes in the routing table.
lab@Chicago> show route
inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 *[Direct/0] 16:41:11
> via fe-0/0/2.0
10.0.0.1/32 *[Local/0] 1d 01:20:56

www.ebook-converter.com
Local
30.30.30.0/24 *[RIP/100] 00:55:41, metric 2
> to 51.0.0.2 via fe-0/0/1.0
to 10.0.0.2 via fe-0/0/2.0
51.0.0.0/24 *[Direct/0] 17:06:31
> via fe-0/0/1.0
51.0.0.1/32 *[Local/0] 1d 01:20:56
Local
192.168.254.0/24 *[Direct/0] 1d 01:20:56
> via fe-0/0/0.0
192.168.254.1/32 *[Local/0] 1d 01:20:56
Local
224.0.0.9/32 *[RIP/100] 00:52:19, metric 1
RIP neighbor status can be an important piece of information to use in troubleshooting. The following command
output shows the state of the neighbor, the address of the neighboring router's interface, and the version of RIP
allowed to be received. In addition, it also shows if any metric-in values have been assigned.

Downloader demo watermarks

lab@Chicago> show rip neighbor

Neighbor
Source
State Address
Destination
Address
Send
Mode
Receive
Mode
In
Met
-------- ----- ------- ----------- ---- ---- ---
fe-0/0/1.0 Up 51.0.0.1 224.0.0.9 mcast v2 only 1
fe-0/0/2.0 Up 10.0.0.1 224.0.0.9 mcast v2 only 1
299
 8. IGP Routing Protocol Configuration
You can also gain insight into the proper functioning of RIP by viewing the statistics. Below is an example of the
statistics that can be of assistance in troubleshooting RIP. An output like the one below is created for each RIP-
enabled interface. Things to look for in the statistics are as follows:
Are there incrementally increasing received updates, and are they of the correct RIP version?
Is authentication in use?
Are there authentication failures?
lab@Chicago> show rip statistics
RIP info: port 520; update interval 30s; holddown 180s; timeout 120s.
rts learned rts held down rqsts dropped resps dropped
1 0 0 0
fe-0/0/1.0: 1 routes learned; 2 routes advertised
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 125 11 2
Triggered Updates Sent 1 0 0
Responses Sent 0 0 0
Bad Messages 0 0 0
RIPv1 Updates Received 0 0 0
RIPv1 Bad Route Entries 0 0 0
RIPv1 Updates Ignored 0 0 0
RIPv2 Updates Received 124 11 2
RIPv2 Bad Route Entries 0 0 0
RIPv2 Updates Ignored 0 0 0
Authentication Failures 0 0 0

www.ebook-converter.com
RIP Requests Received 0 0 0
RIP Requests Ignored 0 0 0
..........
lab@Chicago>
RIP is an older distance vector routing protocol that is still in use in many networks. Both versions of RIP are
supported by all Juniper Networks routers. RIPv2 is the more recommended version as it can use CIDR and VLSM
to create more scalable, flexible networks.

OSPF
OSPF is an IGP. The structure for OSPF was first drafted in 1989 by John Moy in RFC 1131, “OSPF
Specification.” This protocol uses an algorithm called the Dijkstra algorithm, after Edsger Dijkstra, the computer
scientist who first described the algorithm to determine which path is best (shortest) between two points. OSPF has
gone through many revisions and updates in the IETF drafts since 1989. OSPF version 2 (OSPFv2) is now IETF
standard 2328, finalized in 1998, also drafted by John Moy.

Downloader demo watermarks

Note
RFCs are mirrored on many other networking or university Web sites. Some of these have search engines
that are better than others. The site at www.rfc-editor.org/rfc.html has a good search engine and outputs

300
 8. IGP Routing Protocol Configuration
searches in an easy-to-read format.

Theory of Operation
OSPF is a link state routing protocol that permits a router to create a topology database of all the other routers and
connections in the network. OSPF is also hierarchical in nature, which means that there is more than one level to its
structure. OSPF is implemented in groupings of routers known as areas. The top-level area is known as area 0, or
the backbone area, so called because, just as information passing through the human central nervous system must
travel through the backbone, any data traveling from one area to another must pass through area 0. Other areas
attach to this backbone area. Figure 8-10 illustrates an OSPF network with four areas. Area 0 is connected to areas
9, 25, and 59. Any traffic from area 25, for example, needing to go to area 9 or 59, will need to go through area 0.

Figure 8-10. OSPF Hierarchical Areas

www.ebook-converter.com
OSPF uses active communication between neighbor routers on the same link. When neighbors form a
communications relationship, called an adjacency, they can send advertisements to each other about the state of
the network. The routers have to keep track of the updates they are sending and receiving to ensure that each has
the latest information. The updates that OSPF uses are called LSAs.

OSPF Metrics
OSPF uses the potential bandwidth of each link along a path for its metric. This is commonly referred to as the cost
of the path. These metrics provide more meaningful information than hop count alone because they are not simply
hops added along a path. They include the speed of the link.
The idea behind an OSPF route is that the lower the cost, the more preferred the network. The default formula used
to calculate metrics in OSPF is
cost = 100,000,000 (bps)/link bandwidth (bps)

Downloader demo watermarks

This formula gives a cost of 1 for a 100Mbps connection. When OSPF was being designed, 100Mbps was at the
highest end of possible network speeds. Now, this speed is common. Since OSPF metrics have a low end of 1, Fast
Ethernet, OC-3 POS, OC-12 ATM, and GigE would all have the same cost, although some links offer bandwidth
ten times greater than 100Mbps. To address this discrepancy, Juniper Networks' OSPF implementation allows you
to change the 100,000,000 into which the link bandwidth is divided. This is called the reference bandwidth. The
301
 8. IGP Routing Protocol Configuration
reference bandwidth should be set at least as high as the fastest link in the network and must be configured the
same on all routers using OSPF.
Figure 8-11 shows a network with the corresponding bandwidth of its links. The reference bandwidth is set at
1,000Mbps (1Gbps), and we can see the costs associated with these links. Just as RIP added the hop counts
together, OSPF adds costs together when determining the best path to a destination.

Figure 8-11. OSPF Links and Metrics

In the figure, we see that router A has received router D's update from router B with a total advertised cost of 1,296
for destination network 10.10.10.0/24. Conversely, the same destination is advertised from router C with a
cost of 694, making this the best path in OSPF metrics. If we were using RIP, RIP would just consider the number
of hops and would forward to router B. OSPF, however, uses the aggregate bandwidth from all hops to ensure that
the overall shortest and most effective path is used.

OSPF Areas

www.ebook-converter.com
The LSDB keeps track of the routers and links in a single area. As the networks grow, however, this topology table
can grow very large. To address this problem, OSPF can be broken into areas, as we mentioned before. The
backbone area and each nonbackbone area will have its own smaller LSDB. Links within each nonbackbone area
will be advertised to area 0.
You can use network summarization to cut down on the number of networks that are advertised from each area into
area 0. Two factors to consider when dividing your OSPF network into areas are the size of the LSDB and the
capability of the routers in that area.
Summarization is the combining of contiguous network advertisements by increasing the scope of the network
mask to cover the networks with fewer statements. In other words, instead of advertising four separate but
contiguous /24 networks, the routers can advertise one /22 network.
In essence, the main purposes of OSPF areas are to reduce the size of the LSDB, to filter advertisements into a
nonbackbone area, and to summarize nonbackbone areas into area 0.

Router Types
Downloader demo watermarks
Notice in Figure 8-12 that some routers have all of their interfaces in the same area, some have interfaces in more
than one area, and some have interfaces that use other protocols, such as RIP. These router types are referred to as
the internal router (IR), the area border router (ABR), and the autonomous system border router (ASBR). The
positions of these routers within the OSPF network are shown in Figure 8-12.
302
 8. IGP Routing Protocol Configuration

Figure 8-12. OSPF Routers

The IR router has all its interfaces in the same OSPF area. This router maintains the area topology database of a
single area, which stores knowledge about who is where and how to get there cheapest.
The ABR is a little different. This router's function is to connect nonbackbone areas to the area 0 backbone. Any
traffic going from the connected nonbackbone area to another nonbackbone area will have to pass through this
router. This router can also suppress certain external routes (outside OSPF) and advertise default routes in the
nonbackbone area. These routers must have a full topology database for every area in which they have an interface.
The ASBR router connects more than one autonomous system (AS) together through another routing protocol, such
as RIP or BGP. It can also be a router that simply has interfaces in OSPF and also has interfaces in a routing
protocol outside OSPF. This router could be the point at which a RIP and OSPF network come together, for

www.ebook-converter.com
example. Since the RIP routes are outside the OSPF process, RIP routes would be seen as external. The ASBR
router takes the routes from the other routing protocol and imports them into OSPF. There could be more than one
ASBR in an area, some importing routes from another AS, some exporting static routes and some importing RIP
routes. This is done with import and export features explained in detail in Chapter 11.

OSPF Database
The OSPF database is the storage area for the topology of a given area in which the router resides. The databases of
all the routers in a particular area are the same as each router has a complete map of every router and link in the
area. They all have the same picture of the state of the network and the paths to the area destinations. Anytime the
database is updated with new information, all the routers will receive the new information and pass it on to adjacent
routers. The routers within the area must then converge or return to the steady state where all databases are the
same. Once each router in an area receives new information, it must also run the Dijkstra SPF algorithm to update
its own LSDB.

Adjacency
Downloader demo watermarks
Once OSPF is configured on an interface, it begins sending hello packets. These packets are sent to multicast
address 224.0.0.5. A router sends these hello packets so that all other OSPF-enabled routers in an area are
aware of its presence. Even after all OSPF-enabled routers have established communication, hello packets continue
to be sent to inform the adjacent routers that the sending router is still alive.
303
 8. IGP Routing Protocol Configuration
A hello packet contains several key pieces of information: router priority, hello interval, router dead interval, a list
of all known neighbors, and subnet mask of the attached network. The router priority number is used in a special
election process, which will be explained later in Section 8.4.9. The hello interval establishes the frequency with
which hello packets will be sent. The router dead interval is the upper limit of time within which a hello packet must
be received from an adjacent router or it will be considered down. The subnet mask, in this instance, is for the
associated interface. Here is how a router forms an OSPF adjacency. It begins when one OSPF-enabled interface
receives a hello packet from another router. Both routers begin exchanging information about their OSPF
implementations to ensure that they are compatible. When a router receives a hello containing its own IP address in
the known-routers group, it knows that the “handshake” between itself and the neighboring router is valid. The
parameters contained in the hello packet for each router will have to match (with the exception of the known-
routers list), before the routers will be allowed to exchange OSPF information.
Sometimes, an OSPF interface does not need to form adjacencies. If this is the case, you can use the passive
interface command to prevent the interface from sending hello packets. Because the interface does not send
hellos, it will not form any adjacencies. This can also be used to ensure that a link is seen as internal, as opposed to
external, by OSPF.
When the routers have agreed on parameters, they begin to exchange OSPF database information. This is known as
the exchange state. The routers will keep track of the information in their database and compare it with that of the
adjacent router's to ensure that they have the same information. When this exchange is complete, the routers will
update all of their neighbors about the new adjacency. The state is now known as full.

LSAs
LSAs are the messages that keep the routers informed about the state of the network. Keeping track of an OSPF
area means keeping track of the different components of that area, such as router identification (RID) numbers,
network summaries, and so on. Because there are many components within an area, there are six different types of

www.ebook-converter.com
LSAs referenced by numbers 1 to 5 and 7. LSA type 6 is a group membership LSA used for a multicast
enhancement to OSPF or Multicast Open Shortest Path First (MOSPF) (to learn more about MOSPF, read
reference RFC 1584 at www.ietf.org).
LSA type 1 represents the router itself. This is how routers tell each other about themselves and the links by which
they are connected.
LSA type 2 is used to describe broadcast and NBMA networks and the routers attached to those networks. This
type of LSA is sent by the Designated Routers (DRs) of those networks (see Section 8.4.9). Figure 8-13 shows that
LSA types 1 and 2 stay within the area.

Downloader demo watermarks

Figure 8-13. OSPF LSA Types 1 and 2

304
 8. IGP Routing Protocol Configuration
LSA type 3 is used for advertising networks or network summaries between different areas within the AS. This LSA
type allows for the number of networks listed for other areas to be reduced and is generated by ABRs.
LSA type 4 is a summary link to an ASBR generated by the ABR to routers within its area. This LSA type will
announce the information about the ASBR for the area. In Figure 8-14, router C is sending a summary of area 25 as
an LSA type 3 and an advertisement for router A as an ASBR in a type 4 LSA.

Figure 8-14. OSPF LSA Types 3 and 4

LSA type 5 is the LSA for external networks and is generated by the ASBR.
LSA type 7 is an optional type of LSA that is used to advertise external routes into a stub area. Stub areas do not

www.ebook-converter.com
allow type 5 routes. Using a type 7 LSA makes the area a not-so-stubby area (NSSA). The ASBR originates type 7
LSAs. Figure 8-15 shows that as these type 7 LSAs reach the ABR for that area, the ABR changes them to type 5s
to be sent through the rest of the OSPF areas.

Downloader demo watermarks

Figure 8-15. OSPF LSA Types 5 and 7
This may seem somewhat daunting, but think about what comprises a topology. Routers and networks are the most
305
 8. IGP Routing Protocol Configuration
important things in an OSPF area (using LSA types 1 and 2). Internal and external summaries are next in
importance because they tell you how to get to your other areas and ASBRs (using LSA types 3 and 4). Then comes
everything outside of your OSPF domain (using types 5 and 7).
Here is an example of an OSPF database output on an ABR. This output includes examples of LSA types 1 to 5.
lab@Chicago> show ospf database

OSPF link state database, area 0.0.0.0

Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10.0.10.1 10.0.10.1 0x8000000d 195 0x2 0x7570 48
Router 10.200.0.1 10.200.0.1 0x80000005 385 0x2 0x909f 48
Summary *10.0.10.0 10.0.10.1 0x8000000c 195 0x2 0xc760 28
Summary *10.0.20.0 10.0.10.1 0x80000002 195 0x2 0x77af 28
Summary 10.200.0.0 10.200.0.1 0x80000004 685 0x2 0xdcd5 28
ASBRSum *10.0.20.1 10.0.10.1 0x80000002 195 0x2 0x55d0 28

OSPF link state database, area 0.0.0.25

Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10.0.10.1 10.0.10.1 0x80000004 195 0x2 0xdc1d 36
Router 10.0.20.1 10.0.20.1 0x80000009 27 0x2 0xccfa 84
Network 10.0.10.2 10.0.20.1 0x80000001 1317 0x2 0x935d 32
Summary *10.0.30.0 10.0.10.1 0x80000003 195 0x2 0xfc20 28
Summary *10.200.0.0 10.0.10.1 0x80000003 195 0x2 0xe888 28
OSPF external link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 10.220.0.0 10.0.20.1 0x80000001 27 0x2 0x19b3 36

www.ebook-converter.com
lab@Chicago>
The following are the names for the LSA types:
Router—type 1
Network—type 2
Summary—type 3
ASBRSum—type 4
Extern—type 5
In the example above, you can also see the RID of the advertising router, as well as the sequence number and age
of the advertisement.

OSPF Network Types

Downloader demo watermarks
OSPF is not recommended for a full-mesh network design because of the high processing requirements of such a
design. If each router had to form adjacencies with every other network in a 5-router OSPF mesh, there would be
10 adjacencies, whereas a 10-router full mesh would require 45 adjacencies. The formula for a full mesh is N(N –
1)/2, where N is the total number of routers. In Figure 8-16, there are five routers that have fully meshed
306
 8. IGP Routing Protocol Configuration
adjacencies. Because each router will be flooding updates, topology changes, and hellos, and because all routers in
the area must maintain the same database, you can probably imagine how processor-intensive this could be. You
would also waste a great deal of network bandwidth just with routing updates.

Figure 8-16. OSPF Full-Mesh Network Configuration

Instead of having all routers in an area maintain the same database, one router can maintain the database and
update all the other routers at once. Although the other routers maintain their own databases for forwarding
decisions, one router will control the flow of advertisements.
For multiple access links, a router is chosen from among all the routers to receive updates, keep a master topology
database, and update all of the other routers on the shared link. This router is known as the DR. In addition to the
DR, a backup DR (BDR) is chosen in case the DR fails. DRs are used on broadcast and NBMA links. These are the
links that can have many routers connected at once. Ethernet and ATM are examples of broadcast and NBMA,
respectively.

www.ebook-converter.com
OSPF has four basic network types that will determine how adjacencies are formed:
1. Point-to-point
2. Point-to-multipoint
3. Broadcast
4. NBMA
On point-to-point links or point-to-multipoint links, all routers form adjacencies with all other routers on the link in
a mesh style. In broadcast or NBMA network types, non-DR/BDR routers adjacencies are formed with all DRs and
BDRs. In Figure 8-17, adjacencies are formed only with the DR and BDR. In addition, an adjacency is formed
between the DR and BDR. How does a router get to be the DR or BDR? They are elected by all of the routers on
that link.

Downloader demo watermarks

307
 8. IGP Routing Protocol Configuration

Figure 8-17. OSPF DR and BDR Adjacencies

Router Elections
As you have just learned, certain OSPF network types use a special router type called the DR, which acts as the
leader. All routers on a link hold an election in which they select a DR and a BDR, for redundancy. All other
routers form adjacencies with the DR and BDR. This means that instead of 10 routers needing 45 adjacencies to be
fully meshed, the eight non-DR routers that are not DR or BDR will form adjacencies with the DR and BDR. When
updates need to be sent, the non-DR routers send the updates to the DR and BDR routers, which then send them
back out to all the non-DR routers at once.
How does this election work? OSPF routers constantly send hello packets out of all OSPF-configured interfaces.
The routers all have a priority that is included in the hello packet. The router with the highest priority becomes the
DR, and the router with the second highest on the link becomes the BDR. If their priorities are the same, then the
router with the highest RID becomes the tiebreaker. An OSPF router's RID is represented as an IP address (usually
the highest IP address configured on an interface). On Juniper Networks routers, 128 is the default priority, which is

www.ebook-converter.com
configurable within the range of 0 to 255. If you configure a router to 0 it will never be a DR/BDR. Unless you
adminstratively set the priority value, elections will produce a DR and BDR based solely on the RID, which may
not be ideal.
In Figure 8-18, five routers are on an Ethernet link. Since the routers know this is a broadcast network, a DR and
BDR must be elected following the process just described. All of the routers send their priorities along a broadcast
(Ethernet) network. The router with a priority of 175 wins DR status, while the router with a priority of 150
becomes the BDR. All of the non-DR/BDR routers form an adjacency with the DR and BDR and start sending
LSAs.

Downloader demo watermarks

Figure 8-18. OSPF DR and BDR Elections
Bear in mind that there will be circumstances in which it is very desirable to manipulate the DR/BDR election
process. The DR and BDR will need a little more processing power. If you have some smaller or older routers on
the network, they may not be robust enough to process the updates for several routers in a large area. Another
reason to set the priority is that a router may find itself connected to tens, or perhaps hundreds, of broadcast or
308
 8. IGP Routing Protocol Configuration
NBMA networks and wind up as the DR on all of them if one of its interfaces had the highest IP address. This
could be disastrous with a small router.
If another router comes up on the link with a higher RID or priority, OSPF will not select it as the new DR or BDR
unless a new election is held. Because of this attribute, OSPF is considered nonpreemptive. A new election will be
held if the current DR becomes disabled. Then the router with higher RID or priority has a chance of becoming the
DR.

Stub Areas
Breaking an AS into areas allows a router's OSPF databases to remain much smaller. If you want to reduce the
database size even further, you can use a special type of OSPF area called a stub area. If there is only one way in
and out of a nonzero area, then there is no need for all the backbone routes, other area routes, or external routes.
The area routers just need a default route to the ABR. Here we will discuss two methods for automatically filtering
routes from outside a nonzero area: stub and totally stubby area and NSSA.

Stub and Totally Stubby Areas

The terms stub and totally stubby are used to represent OSPF areas that have partially (stub) and completely
(totally stubby) shut off information from outside themselves because it is not necessary for proper operation. In
Figure 8-19, area 9 and 59 internal routers have only one way into and out of their areas—through their ABR. As
long as there is a default route in the internal routers' routing tables, area 9 and 59 routers do not need any other
information from the network. If there were multiple ABRs to an area, the default routes would have costs added so
that the router could select the least-cost path.

www.ebook-converter.com

Figure 8-19. OSPF Stub and Totally Stubby Areas

For area 9, router Boston filters out type 5 LSAs from the forwarded advertisements and is therefore a stub area. In
addition, router Boston also forwards a default route to area 9 so its routers can route out of the OSPF network.

Downloader demo watermarks

Router Washington D.C. is filtering out all LSAs and only sending a default route. This makes area 59 totally
stubby. The difference between these two is whether or not they are sending summary type 3 LSAs.
Stub is not as strict as totally stubby. Stub networks allow other area information in, excluding information on
external routes. The ABR in a stub will not pass type 5 LSAs, but will pass type 3 LSAs into the area. If an area has
more than one ABR, a stub area will allow the area internal routers to make a better decision as to the best path to
309
 8. IGP Routing Protocol Configuration
other areas because interarea routes will be advertised from the ABRs.
Totally stubby cuts out type 3, in addition to type 4 and 5, advertisements into an area. The routers only need know
about routes to all other internal routers and the default routes to ABRs (sent as a type 3).

Not-So-Stubby Areas
What would happen if, in Figure 8-19, area 25 had been a stub and an external RIP routing process needed to be
advertised to the area? External routes generate type 5 LSAs that are not allowed in stub or totally stubby areas. An
NSSA allows type 7 LSAs through the area, while still retaining other attributes of a stub area. A type 7 LSA is
basically a type 5, but because neither of the stubby area types will allow type 5 LSAs, a type 7 must be used.
When type 7 LSAs hit the ABR of the area, they are changed into normal external type 5 LSAs and permitted to
continue on throughout the OSPF domain. This allows the ASBRs of the stubby area to keep the routes down to a
minimum, but still serve as an entry point for an external routing protocol.
In Figure 8-20, router Chicago (ABR) sends no summary LSAs into area 25, but does send in a default route. This
NSSA differs from stub and totally stubby areas in that external routes (from the RIP network) have to be
propagated. The NSSA configuration allows router Seattle (ASBR) to advertise the RIP networks as type 7 LSAs.
Chicago then converts these to type 5 external LSAs for the rest of the OSPF network. This area is an example of
an NSSA no-summary area. It receives no summaries other than a default from the ABR and has an ASBR
advertising type 7 LSA.

www.ebook-converter.com

Figure 8-20. OSPF NSSA

Equal Cost Paths

OSPF can have multiple paths through a network to a destination, such as an ABR or ASBR. Several of the paths
can be tied for lowest cost. If such an occurrence takes place, Juniper Networks routers can load balance on the
paths of equal cost. Some traffic will take one path; other traffic will travel along the other path. This is called equal
Downloader demo watermarks
cost multipath (ECMP).
Juniper Networks implements what is called destination or per-prefix load balancing across up to 16 equal cost
paths. This is also known as per-flow load balancing. There is still only one route installed for a particular
destination, but if there are four equal cost paths through a single ABR to 400 destinations, Juniper Networks
310
 8. IGP Routing Protocol Configuration
routers will route the flows in round-robin style over the paths so that 100 routes will be assigned to each path.
Per-flow load balancing is a feature that was introduced with the Internet Processor II. The original Internet
Processor I capable of per-packet load balancing. This meant that packets to the same destination might take
different paths. Taking different paths could lead to the packets arriving out of order. Per-flow load balancing sends
the packets to the same destination along the same path.

Virtual Links
An OSPF nonbackbone area must be connected to area 0, the backbone area. OSPF standards dictate that all traffic
from one nonbackbone area to another must go through the backbone. In addition, area 0 must not be broken into
segments. Since no network is perfectly reliable, there are times when a nonbackbone area could lose its connection
to the backbone, or the backbone itself could be separated into several segments due to an area partition. When this
occurs, a virtual link must be created to form a temporary repair. In Figure 8-21, notice that area 59 is not directly
connected to area 0. Area 59 then needs a virtual link created between router Chicago and router Boston. The
dotted line in the figure represents the virtual link from area 59 to area 0 through area 25. This will allow area 59 to
participate in the OSPF network as if it were directly attached to area 0 with Chicago as the ABR.

www.ebook-converter.com
Figure 8-21. Creating an OSPF Virtual Link
If a failure were to produce a situation in which area 0 was segmented, a virtual link could be created through a
nonbackbone area as shown by the dashed line in Figure 8-22. Router Chicago and router Boston are providing the
backbone connection to area 59 through area 25 since it isn't directly connected to area 0. Chicago acts as an ABR
for area 0 and area 59 as if it were directly connected to area 0. The virtual link is a connection to area 0 that allows
the router to act as an ABR connected to area 0.

Downloader demo watermarks

311
 8. IGP Routing Protocol Configuration
Figure 8-22. Creating a Virtual Link for Area 0
Virtual links are not recommended as a permanent solution. They should be used in temporary situations that arise
from failure or unforeseen circumstances.

OSPF Single-Area Configuration

The minimum configuration for OSPF on Juniper Networks routers is accomplished by simply adding an interface
into an area. In Figure 8-23, we see a single OSPF area. The routers, their addresses, and their interfaces are
identified. Once the interfaces are configured, you just need to add them into the OSPF process.

Figure 8-23. Configuring an OSPF Single Area

Adding an interface into the OSPF process is done from the [edit protocols ospf] level of the
configuration hierarchy. The example below shows how to do this. Starting with Chicago, the area is identified
followed by the interface.

www.ebook-converter.com
[edit]
lab@Chicago# edit protocols ospf
[edit protocols ospf]
lab@Chicago# set area 0 interface at-0/1/0.20
[edit protocols ospf]
lab@Chicago# set area 0 interface at-0/1/1.10
[edit protocols ospf]
lab@Chicago# set area 0 interface fe-0/0/0.0
[edit protocols ospf]
lab@Chicago# show
area 0.0.0.0 {
interface at-0/1/0.20;
interface at-0/1/1.10;
Downloader demo watermarks
interface fe-0/0/0.0;
}
[edit protocols ospf]
lab@Chicago#

312
 8. IGP Routing Protocol Configuration
Knowing how to add individual interfaces is important when configuring ABRs or ASBRs. They will have
interfaces in different areas. For routers that have all interfaces in OSPF and in the same area, however, the
command set area x interface all will assign every interface into the specified OSPF area.
[edit]
lab@Boston# edit protocols ospf

[edit protocols ospf]

lab@Boston# set area 0 interface all

[edit protocols ospf]

lab@Boston# show
area 0.0.0.0 {
interface all;
}
[edit protocols ospf]
lab@Boston#

lab@Boston> show ospf interface brief

Interface State Area DR ID BDR ID Nbrs
at-2/2/0.10 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 0
at-2/2/1.10 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
fe-2/0/0.0 DR 0.0.0.0 10.0.20.2 10.0.20.1 1
lo0.0 DR 0.0.0.0 10.0.20.2 0.0.0.0 0
lab@Boston>

www.ebook-converter.com
The run show ospf interface brief command shows all OSPF interfaces and their assigned areas. In
addition, it will list the DRs, BDRs, and number of neighbors on those links.
Once router Washington D.C. has had its interfaces entered in OSPF area 0, all routers will have formed
adjacencies and advertised routes.
lab@Wash-DC> show route
inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.10.0/24 *[Direct/0] 00:39:17

> via fe-0/0/0.0
10.0.10.2/32 *[Local/0] 00:39:17
Local

Downloader demo watermarks

10.0.20.0/24 *[Direct/0] 00:39:17
> via fe-0/0/1.0
10.0.20.1/32 *[Local/0] 00:39:17
Local
10.0.30.0/24 *[OSPF/10] 00:02:09, metric 2
> to 10.0.20.2 via fe-0/0/1.0
313
 8. IGP Routing Protocol Configuration
to 10.0.10.1 via fe-0/0/0.0
10.100.0.0/24 *[OSPF/10] 00:02:26, metric 2
> to 10.0.10.1 via fe-0/0/0.0
10.200.0.0/24 *[OSPF/10] 00:02:09, metric 2
> to 10.0.20.2 via fe-0/0/1.0
224.0.0.5/32 *[OSPF/10] 00:03:13, metric 1
lab@Wash-DC>
This example shows all five networks configured in OSPF. Looking at routes with multiple entries, we see that there
are equal cost paths that can be taken to the highlighted destination network. Referring back to Figure 8-23, the
cost to network 10.0.30.0/24 from router Washington D.C. should be equal, since both of the links to the
network are the same. In this instance, ECMP can be used to load balance to this destination.

OSPF Multiple-Area Configuration

The minimum configuration for OSPF in multiple areas is not much different from RIP, with the exception that
OSPF does not require an export policy. OSPF will enter the links and networks into the LSDB for the area in
which the interfaces are assigned. OSPF will then advertise those LSDB entries to adjacent routers without
exporting the routes. In Figure 8-24, area 0 is connecting area 25 and area 59. Interface fe-0/0/1 on the
Washington D.C. router has three more network addresses added to populate the routing table with more routes.

www.ebook-converter.com

Figure 8-24. OSPF Multiple Areas

With router Washington D.C., use of the quick OSPF command set area x interface all to add all of the
interfaces is allowable because all of the interfaces are in the same area.
[edit]
lab@Wash-DC# edit protocols ospf

Downloader demo watermarks

[edit protocols ospf]
lab@Wash-DC# set area 25 interface all
[edit protocols ospf]
lab@Wash-DC#

314
 8. IGP Routing Protocol Configuration
Router Washington D.C. is now an internal router. For routers Chicago and Boston, each interface must be
configured for the appropriate area.
[edit]
lab@Chicago# edit protocols ospf
[edit protocols ospf]
lab@Chicago# set area 0 interface at-0/1/1.10
[edit protocols ospf]
lab@Chicago# set area 25 interface fe-0/0/0.0
----
[edit]
lab@Boston# edit protocols ospf
[edit protocols ospf]
lab@Boston# set area 0 interface at-2/2/1.10
[edit protocols ospf]
lab@Boston# set area 59 interface at-2/2/0.10
[edit protocols ospf]
lab@Boston#
Routers Chicago and Boston now need separate OSPF databases for each area in which they have interfaces
configured. Taking a look at router Chicago's database in the following example. Notice that the LSAs are grouped

www.ebook-converter.com
by type and by area in ascending order.
lab@Chicago> show ospf database
OSPF link state database, area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10.0.10.1 10.0.10.1 0x80000002 250 0x2 0x8b65 48
Router 10.200.0.1 10.200.0.1 0x80000002 248 0x2 0x969c 48
Summary *10.0.10.0 10.0.10.1 0x80000002 374 0x2 0xdb56 28
Summary *10.0.20.0 10.0.10.1 0x80000001 374 0x2 0x79ae 28
Summary *10.40.0.0 10.0.10.1 0x80000001 374 0x2 0x749f 28
Summary *10.50.0.0 10.0.10.1 0x80000001 374 0x2 0xfb0e 28
Summary *10.60.0.0 10.0.10.1 0x80000001 374 0x2 0x837c 28
Summary 10.200.0.0 10.200.0.1 0x80000001 249 0x2 0xe2d2 28
OSPF link state database, area 0.0.0.25
Type ID Adv Rtr Seq Age Opt Cksum Len

Downloader demo watermarks

Router *10.0.10.1 10.0.10.1 0x80000003 378 0x2 0xde1c 36
Router 10.0.20.1 10.0.20.1 0x80000004 379 0x2 0xd0fd 84
Network 10.0.10.2 10.0.20.1 0x80000001 379 0x2 0x935d 32
Summary *10.0.30.0 10.0.10.1 0x80000001 419 0x2 0x11e 28
Summary *10.200.0.0 10.0.10.1 0x80000001 245 0x2 0xec86 28

315
 8. IGP Routing Protocol Configuration
Ultimately, the routes will be in the routing table. Showing the routes on Boston also shows all the routes from
Washington D.C.
lab@Boston> show route
inet.0: 12 destinations, 12 routes (11 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
. . . cut
10.0.30.0/24 *[Direct/0] 1d 00:16:21
> via at-2/2/1.10
[OSPF/10] 00:11:00, metric 1
> via at-2/2/1.10
10.0.30.1/32 *[Local/0] 1d 00:16:21
Local
10.40.0.0/24 *[OSPF/10] 00:10:55, metric 3
> via at-2/2/1.10
10.50.0.0/24 *[OSPF/10] 00:10:55, metric 3
> via at-2/2/1.10
10.60.0.0/24 *[OSPF/10] 00:10:55, metric 3
> via at-2/2/1.10
10.200.0.0/24 *[Direct/0] 00:31:19
> via at-2/2/0.10
[OSPF/10] 00:11:00, metric 1
> via at-2/2/0.10
10.200.0.1/32 *[Local/0] 1d 00:16:21
Local . . . . cut

www.ebook-converter.com
Also, notice the metric costs for the routes from router Boston to the far side of router Washington D.C. The metric
is three, even though the path is 155Mbps ATM through two 100Mbps Fast Ethernet links. Remember, in Section
8.1.1 we discussed reference bandwidths as they relate to the metric (cost).
Changing the reference bandwidth to 1,000Mbps (1Gbps) will show a more accurate cost for the path. The
reference bandwidth should be at least equal to your fastest network link in OSPF. After changing the reference
bandwidth of all the routers, the metrics will have changed.
[edit protocols ospf]
lab@Wash-DC# set reference-bandwidth 1000000000
(commit)
lab@Boston> show route
inet.0: 12 destinations, 12 routes (11 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

Downloader demo watermarks

. . . cut
10.0.30.0/24 *[Direct/0] 1d 00:18:19
> via at-2/2/1.10
[OSPF/10] 00:00:30, metric 6
> via at-2/2/1.10
316
 8. IGP Routing Protocol Configuration
10.0.30.1/32 *[Local/0] 1d 00:18:19
Local
10.40.0.0/24 *[OSPF/10] 00:00:02, metric 26
> via at-2/2/1.10
10.50.0.0/24 *[OSPF/10] 00:00:02, metric 26
> via at-2/2/1.10
10.60.0.0/24 *[OSPF/10] 00:00:02, metric 26
> via at-2/2/1.10
10.200.0.0/24 *[Direct/0] 00:33:17
> via at-2/2/0.10
[OSPF/10] 00:00:30, metric 6
> via at-2/2/0.10 . . . cut
Now the costs more accurately reflect the network state. The Fast Ethernet links will have a higher cost per link
than the higher-bandwidth links.

OSPF Stub Configuration

Filtering the external LSAs with a stub configuration can drastically cut down the size of the routing table for each.
Using the same scenario in Figure 8-24 for the multiple-area configuration, the stub configuration can be added to
routers Chicago and Washington D.C.
Looking at the LSAs on router Washington D.C., notice that there are two summary LSAs.
lab@Wash-DC> show ospf database
OSPF link state database, area 0.0.0.25

www.ebook-converter.com
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 10.0.10.1 10.0.10.1 0x80000006 848 0x2 0x7b73 36
Router *10.0.20.1 10.0.20.1 0x80000005 1671 0x2 0x3868 84
Network *10.0.10.2 10.0.20.1 0x80000001 2574 0x2 0x935d 32
Summary 10.0.30.0 10.0.10.1 0x80000004 520 0x2 0x2de9 28
Summary 10.200.0.0 10.0.10.1 0x80000004 220 0x2 0x4b1b 28
To change area 25 to a stub network, the configuration must be applied to all the internal routers and ABRs for that
particular area. The following example shows the no-summaries option, which will filter out type 3, 4, and 5
LSAs, creating a totally stubby area. If type 3s are to be received and only type 4s and 5s to be filtered, then the
no-summaries option is configured.
Router Chicago
[edit protocols ospf]
lab@Chicago# set area 25 stub no-summaries
Router Washington D.C.
Downloader demo watermarks
[edit protocols ospf]
lab@Wash-DC# set area 25 stub no-summaries
lab@Wash-DC> show ospf database
OSPF link state database, area 0.0.0.25
317
 8. IGP Routing Protocol Configuration
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 10.0.10.1 10.0.10.1 0x80000003 5 0x0 0x955f 36
Router *10.0.20.1 10.0.20.1 0x80000002 2 0x0 0x5254 84
Network 10.0.10.1 10.0.10.1 0x80000001 5 0x0 0x2ad3 32
lab@Wash-DC>
The summary LSAs have been filtered. This is an extremely important feature to use for areas that do not need to
know all of the routes. If areas have thousands of routes and there are many areas, the routing engine could be
overworked. The stub and totally stubby configuration must be applied to every router in the area to be effective.
One final configuration step that must be taken on Washington D.C. because it has been cut off from all route
advertisements, is to add a default route to the ABR. With no knowledge of any router outside of area 25,
Washington D.C. must have a way to get to routers external to the area. Router Washington D.C. cannot get to
router Boston, as shown below when router Washington D.C. tries to ping Boston:
lab@Wash-DC> ping 10.0.30.1
PING 10.0.30.1 (10.0.30.1): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
^C
--- 10.0.30.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
To have the ABR advertise a default route into an area, use the default-metric parameter of the area stub
command on the ABR. For this scenario, Chicago is the ABR for area 25.

www.ebook-converter.com
Configuration for router Chicago:
[edit protocols ospf]
lab@Chicago# set area 25 stub default-metric 2
Configuration for router Washington D.C.:
lab@Wash-DC> show route
inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/10] 00:00:06, metric 3
> to 10.0.10.1 via fe-0/0/0.0
10.0.10.0/24 *[Direct/0] 1d 22:54:50
> via fe-0/0/0.0
10.0.10.2/32 *[Local/0] 1d 22:54:50
Local . . .cut
Downloader demo watermarks
Router Washington D.C. now has a default route that covers anything not known to the area. Washington D.C. can
now ping Boston.
lab @Wash-DC> ping 10.0.30.1
PING 10.0.30.1 (10.0.30.1): 56 data bytes
318
 8. IGP Routing Protocol Configuration
64 bytes from 10.0.30.1: icmp_seq=0 ttl=254 time=1.478 ms
64 bytes from 10.0.30.1: icmp_seq=1 ttl=254 time=1.372 ms
64 bytes from 10.0.30.1: icmp_seq=2 ttl=254 time=1.329 ms
64 bytes from 10.0.30.1: icmp_seq=3 ttl=254 time=1.271 ms
^C
--- 10.0.30.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.271/1.363/1.478/0.076 ms
lab @Wash-DC>

OSPF NSSA Configuration

NSSA configuration is similar to stub configuration. The difference is the presence of external routes. The need for
an NSSA stems from the requirement to inject external routes into OSPF in that area and the desire to restrict
external or summary routes into that area from the other OSPF areas.
In Figure 8-25, area 25 has static routes forwarding out of interface fe-0/0/1. There is a policy named ospf_stat
that matches these routes, and they are exported into OSPF. This is shown below in router Washington D.C.'s
configuration.

www.ebook-converter.com
Figure 8-25. OSPF NSSA Configuration
Before an NSSA area is configured, the database has many different types of LSAs in router Washington D.C., as
follows:
lab@Wash-DC> show ospf database
OSPF link state database, area 0.0.0.25
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 10.0.10.1 10.0.10.1 0x80000004 260 0x2 0x7f71 36

Downloader demo watermarks

Router *10.0.20.1
Network *10.0.10.2
Summary 10.0.30.0
10.0.20.1
10.0.20.1
10.0.10.1
0x80000006
0x80000001
0x80000002
43
545
258
0x2
0x2
0x2
0xd8c7 48
0x935d 32
0x31e7 28
Summary 10.40.0.0 10.0.10.1 0x80000001 42 0x2 0xd831 28
Summary 10.50.0.0 10.0.10.1 0x80000001 42 0x2 0x609f 28
Summary 10.60.0.0 10.0.10.1 0x80000001 42 0x2 0xe70e 28
319
 8. IGP Routing Protocol Configuration
Summary 10.200.0.0 10.0.10.1 0x80000003 258 0x2 0x4d1a 28
OSPF external link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern *10.220.0.0 10.0.20.1 0x80000003 546 0x2 0x15b5 36
Extern *10.221.0.0 10.0.20.1 0x80000003 546 0x2 0x9c0 36
Extern *10.222.0.0 10.0.20.1 0x80000001 610 0x2 0x1c9 36
Here we apply the NSSA configuration to router Washington D.C. and router Chicago, not forgetting to set a
default metric for generating a default route into area 25.
[edit protocols ospf]
lab@Chicago# set area 25 nssa no-summaries
[edit protocols ospf]
lab@Chicago# set area 25 nssa default-lsa default-metric 2
--
[edit protocols ospf]
lab@Wash-DC# set area 25 nssa no-summaries

(commmit)
[edit protocols ospf]
lab@Wash-DC# run show ospf database

OSPF link state database, area 0.0.0.25

Type ID Adv Rtr Seq Age Opt Cksum Len
Router 10.0.10.1 10.0.10.1 0x80000003 15 0x0 0xf803 36

www.ebook-converter.com
Router *10.0.20.1 10.0.20.1 0x80000002 10 0x0 0xeee2 84
Network 10.0.10.1 10.0.10.1 0x80000001 14 0x0 0x2ad3 32
Summary 0.0.0.0 10.0.10.1 0x80000001 110 0x0 0xf651 28
NSSA *10.220.0.0 10.0.20.1 0x80000001 14 0x8 0x2481 36
NSSA *10.221.0.0 10.0.20.1 0x80000001 14 0x8 0x188c 36
NSSA *10.222.0.0 10.0.20.1 0x80000001 14 0x8 0xc97 36
[edit protocols ospf]
lab@Wash-DC#

Note
In the configuration example shown here, the show ospf database command was run from the
configuration mode. This can actually be quite preferrable during configuration. The run option in
configuration mode can save you the work of going in and out of configuration mode.
Router Washington D.C. sees only the necessary LSAs. The NSSA in the first column represents the type 7 LSA.

Downloader demo watermarks

The only summary LSA is the default route at the ABR. Router Chicago (ABR) is turning type 7 NSSA LSAs into
type 5 external LSAs, as shown below:
lab@Chicago> show ospf database
OSPF link state database, area 0.0.0.0
320
 8. IGP Routing Protocol Configuration
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10.0.10.1 10.0.10.1 0x80000014 285 0x2 0x591a 48
Router 10.40.0.1 10.40.0.1 0x80000002 641 0x2 0x1456 48
Router 10.200.0.1 10.200.0.1 0x80000007 737 0x2 0x8ca1 48
Summary *10.0.10.0 10.0.10.1 0x80000013 236 0x2 0x1404 28
Summary *10.0.20.0 10.0.10.1 0x80000001 236 0x2 0x2ee7 28
Summary 10.40.0.0 10.40.0.1 0x80000002 13 0x2 0x9f51 28
Summary 10.40.0.0 10.200.0.1 0x80000001 737 0x2 0x6aeb 28
Summary 10.50.0.0 10.40.0.1 0x80000001 646 0x2 0x29be 28
Summary 10.50.0.0 10.200.0.1 0x80000001 737 0x2 0xf15a 28
Summary 10.60.0.0 10.40.0.1 0x80000001 646 0x2 0xb02d 28
Summary 10.60.0.0 10.200.0.1 0x80000001 737 0x2 0x79c8 28
Summary 10.200.0.0 10.40.0.1 0x80000001 646 0x2 0x1a37 28
Summary 10.200.0.0 10.200.0.1 0x80000006 737 0x2 0xd8d7 28
ASBRSum *10.0.20.1 10.0.10.1 0x80000001 236 0x2 0xb16c 28
OSPF link state database, area 0.0.0.25
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10.0.10.1 10.0.10.1 0x80000003 240 0x0 0xa54c 36
Router 10.0.20.1 10.0.20.1 0x80000003 242 0x0 0xfca8 48
Network 10.0.10.2 10.0.20.1 0x80000001 242 0x0 0xb141 32
Summary *0.0.0.0 10.0.10.1 0x80000001 285 0x0 0xf651 28
NSSA 10.220.0.0 10.0.20.1 0x80000001 309 0x8 0x2481 36
NSSA 10.221.0.0 10.0.20.1 0x80000001 309 0x8 0x188c 36
NSSA 10.222.0.0 10.0.20.1 0x80000001 309 0x8 0xc97 36
OSPF external link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 10.220.0.0 10.0.20.1 0x80000003 923 0x2 0x15b5 36

www.ebook-converter.com
Extern
Extern
10.221.0.0
10.222.0.0
10.0.20.1
10.0.20.1
0x80000003
0x80000002
923
366
0x2
0x2
0x9c0 36
0xfeca 36
lab@Chicago>
This is the final configuration for router Chicago and router Washington D.C. (export policies are explained in
detail in Chapter 11).
[edit]
lab@Chicago# show
cut . .
}
}
protocols {
ospf {
reference-bandwidth 1g;
area 0.0.0.25 {

Downloader demo watermarks

nssa {
default-lsa default-metric 2;
no-summaries;
}
interface fe-0/0/0.0;
}
321
 8. IGP Routing Protocol Configuration
area 0.0.0.0 {
interface at-0/1/1.10;
}
}
}
[edit]
lab@Chicago#

[edit]
lab@Wash-DC#
cut . . .
}
}
routing-options {
static {
route 10.220.0.0/24 next-hop 10.0.20.2;
route 10.221.0.0/24 next-hop 10.0.20.2;
route 10.222.0.0/24 next-hop 10.0.20.2;
}
}
protocols {
ospf {
export ospf_stat;
reference-bandwidth 1g;
area 0.0.0.25 {
nssa no-summaries;
interface all;

www.ebook-converter.com
}
}
}

policy-options {
policy-statement ospf_stat {
from protocol static;
then accept;
}
}

[edit]
lab@Wash-DC#

OSPF Virtual-Link Configuration

In order for a virtual link to be created through an area, the virtual link has to be between two routers whose
interfaces are in the given area. One router has to be an ABR with interfaces in area 0. The second router has to
Downloader demo watermarks
have an interface in the area that is not attached.
In Figure 8-26, area 0 has been partitioned, possibly through a link failure. Area 0 must therefore use area 25 to
make the connection between backbone areas through a virtual link until it can be fixed.

322
 8. IGP Routing Protocol Configuration

Figure 8-26. OSPF Virtual Link

You first need to configure the virtual link to ensure that the proper far-end RID is referenced in the command as
shown below. The destination interface for the virtual link is not necessarily the RID, which is either the highest IP
address on the router or the loopback address, if properly configured.
[edit protocols ospf]
lab@Wash-DC# set area 0 virtual-link neighbor-id 10.0.10.1 transit-area 25

[edit protocols ospf]

lab@Wash-DC# show
reference-bandwidth 1g;
area 0.0.0.25 {

www.ebook-converter.com
}
interface fe-0/0/0.0;
area 0.0.0.0 {
virtual-link neighbor-id 10.0.10.1 transit-area 0.0.0.25;
interface fe-0/0/1.0;
}
[edit protocols ospf]
lab@Wash-DC#
[edit protocols ospf]
lab@Chicago# set area 0 virtual-link neighbor-id 10.0.20.1 transit-area 25
[edit protocols ospf]
lab@Chicago# show
reference-bandwidth 1g;
area 0.0.0.25 {
interface fe-0/0/0.0;

Downloader demo watermarks

}
area 0.0.0.0 {
virtual-link neighbor-id 10.0.20.1 transit-area 0.0.0.25;
interface at-0/1/1.10;
}

323
 8. IGP Routing Protocol Configuration
The best way to ensure that the virtual link is up is to use the show ospf interface command as shown
below. This will show the status of the virtual link and neighbor on the far end. If the neighbor ID is set incorrectly,
then the status will be down for that link.
lab@Chicago> show ospf interface
Interface State Area DR ID BDR ID Nbrs
at-0/1/1.10 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
vl-10.0.20.1 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
fe-0/0/0.0 BDR 0.0.0.25 10.0.20.1 10.0.10.1 1
lab@Chicago>
Router Chicago now has an interface in area 0 with one neighbor. Notice the interface is assigned as a vl for
virtual link. Router Chicago can now participate as an ABR connected to area 0.

OSPF Authentication and Configuration

Authentication of adjacent routers can be implemented to prevent unauthorized routes from being injected into an
OSPF network. This can also prevent unauthorized adjacency formation. With authentication in place, adding a
router to an OSPF area would require permission from the controlling authority. Without authentication, any router
that has the same OSPF parameters configured could become adjacent. In Figure 8-27, router Chicago and router
Boston will have authentication configured to secure their communications. Before the authentication is configured,
both routers form an adjacency. Once authentication is configured on one router, the adjacency will fail because of
the mismatch. When authentication is configured on the second router, the adjacency will be re-established.

www.ebook-converter.com

Figure 8-27. OSPF Authentication

There are three types of authentication: none, simple (plain-text), and MD5.
The option none is self-explanatory.
The option simple is just a plain-text password that is sent unencrypted.
Downloader demo watermarks
MD5 uses a scrambling algorithm to create an encoded key, which is sent instead of the actual password to
prevent sniffers from acquiring it as it traverses the link.
The first step to configuring authentication is to specify the type of authentication desired. The following shows the
command to specify the authentication features you wish to configure. This is done from the [edit protocols
324
 8. IGP Routing Protocol Configuration
ospf area x] heirarchy level. Authentication must be the same for the whole area.
[edit protocols ospf area 0.0.0.0]
lab@Chicago# set authentication-type ?
Possible completions:
md5 MD5 authentication
none No authentication
simple Simple password authentication
[edit protocols ospf area 0.0.0.0]
lab@Chicago# set authentication-type md5
After the area authentication is configured, the key must be applied to the interfaces. Different keys can be applied
to different interfaces. The command to apply an authentication key is set authentication-key key key-
id #. Key represents the actual password and the key-id # is a number assigned to identify it. Once the key is
applied to the interface and committed, router Chicago loses router Boston as a neighbor. When the same type of
authentication and the same key is configured on router Boston, the neighbor relationship is re-established.
For this example, router Chicago has 10.0.30.1 as a neighbor (router Boston).
lab@Chicago> show ospf neighbor brief
Address Interface State ID Pri Dead
10.0.30.1 at-0/1/1.10 Full 10.40.0.1 128 38
10.0.10.2 fe-0/0/0.0 Full 10.0.20.1 128 36
lab@Chicago>
The key is password1 and the key-id is 1:

www.ebook-converter.com
[edit protocols ospf area 0.0.0.0]
lab@Chicago# edit interface at-0/1/1.10
[edit protocols ospf area 0.0.0.0 interface at-0/1/1.10]
lab@Chicago# set authentication-key password1 key-id 1

[edit protocols ospf area 0.0.0.0 interface at-0/1/1.10]

lab@Chicago#
The following shows all of the area 0 configuration:
[edit protocols ospf area 0.0.0.0]
lab@Chicago# show
authentication-type md5;
interface at-0/1/1.10 {
authentication-key “$9$-6dYoJZjqPQUj0IclLXUjHk.5QFn” key-id 1;
}

Downloader demo watermarks

After the commit, Router Chicago has lost neighbor Boston:
lab@Chicago> show ospf neighbor
Address Interface State ID Pri Dead
10.0.10.2 fe-0/0/0.0 Full 10.0.20.1 128 32

325
 8. IGP Routing Protocol Configuration
lab@Chicago>
After a matching configuration is committed on router Boston, the neighbor relationship is established:
[edit protocols ospf area 0.0.0.0]
lab@Boston# show
authentication-type md5;
interface at-2/2/1.10 {
authentication-key “$9$V/bgJGUHm5FjHBEyKx7jHq.PQFn/” key-id 1;
}

[edit protocols ospf area 0.0.0.0]

lab@Boston# run show ospf neighbor
Address Interface State ID Pri Dead
10.0.30.2 at-2/2/1.10 Full 10.0.10.1 128 32

Configuring OSPF Options

There are many options for fine-tuning an OSPF network. Several have already been discussed in this chapter, such
as authentication, setting the reference bandwidth statement, and setting a default route into an area with the
default-metric command. There are other features of OSPF that Juniper Networks routers allow for network tuning.
Summarizing by area-range, adding OSPF cost to an interface, and changing priority to set a DR on a link are
just a few more features you can use to increase network efficiency and stability. These features are described in
the following sections.

area-range

www.ebook-converter.com
The area-range command allows the summarization of an area at an ABR. This is key to reducing the volume of
network statements that must be passed between areas. In Figure 8-28, area 25 has four contiguous /24 networks
that can be summarized into one /22 network advertisement by ABR router Chicago to area 0. This will cut the
number of advertisements from area 25 into area 0 down significantly.

Downloader demo watermarks

Figure 8-28. OSPF area-range

326
 8. IGP Routing Protocol Configuration
First, observe the current routing table on router Boston before the summarization is configured:
lab@Boston> show route
inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.8.0/24 *[OSPF/10] 00:00:05, metric 26

> via at-2/2/1.10
10.0.9.0/24 *[OSPF/10] 00:00:05, metric 26
> via at-2/2/1.10
10.0.10.0/24 *[OSPF/10] 00:00:05, metric 16
> via at-2/2/1.10
10.0.11.0/24 *[OSPF/10] 00:00:05, metric 26
> via at-2/2/1.10
10.0.20.2/32 *[Local/0] 5d 22:59:45
Reject
10.0.30.0/24 *[Direct/0] 5d 22:59:45
> via at-2/2/1.10
[OSPF/10] 00:06:59, metric 6
> via at-2/2/1.10
10.0.30.1/32 *[Local/0] 5d 22:59:45
Local
10.200.0.1/32 *[Local/0] 5d 22:59:45
Reject
224.0.0.5/32 *[OSPF/10] 4d 00:11:31, metric 1
Going to router Chicago, an area summarization is entered for area 25 for the contiguous 10.0.8.0/22, covering

www.ebook-converter.com
all four networks of the area. This command is applied from the area that is to be summarized.
[edit protocols ospf area 0.0.0.25]
lab@Chicago# set area-range 10.0.8.0/22
Now, looking at router Boston's routing table, we see the more specific routes behind router Chicago have been
grouped into the 10.0.8.0/22.
lab@Boston> show route
inet.0: 7 destinations, 7 routes (6 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.8.0/22 *[OSPF/10] 00:00:08, metric 26

> via at-2/2/1.10
10.0.20.2/32 *[Local/0] 5d 23:02:22
Reject
10.0.30.0/24 *[Direct/0] 5d 23:02:22
Downloader demo watermarks > via at-2/2/1.10
[OSPF/10] 00:09:36, metric 6
> via at-2/2/1.10
10.0.30.1/32 *[Local/0] 5d 23:02:22
Local
10.200.0.1/32 *[Local/0] 5d 23:02:22
327
 8. IGP Routing Protocol Configuration
Reject
224.0.0.5/32 *[OSPF/10] 4d 00:14:08, metric 1

lab@Boston>

Changing Cost
Each interface in OSPF has a metric cost associated with it. This is what is added at each hop of an advertised
route. If you do not desire the least-cost path to be used as the primary forwarding path, cost can be added to the
interface to make it less preferred. This would be analogous to adding hops in RIP. In both cases, the metric on the
best route is being increased, forcing the other routers to adopt another path. In Figure 8-29, router Boston has a
route to 10.100.0.0/24 directly through router Chicago because that path has the lowest cost with a metric of
12.

www.ebook-converter.com
Figure 8-29. OSPF Metric Costs
The cost to 10.100.0.0/24 is 6—the cost of the originating interface, plus 6 added for the directly connected
link with Boston. With the reference bandwidth set at 1Gbps, Fast Ethernet has a cost of 10, and 155Mbps ATM
has a cost of 6.
lab@Boston> show route
inet.0: 9 destinations, 9 routes (8 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.10.0/24 *[OSPF/10] 00:03:16, metric 16
> via at-2/2/1.10
10.0.20.0/24 *[Direct/0] 00:41:22
> via fe-2/0/0.0
10.0.20.2/32 *[Local/0] 5d 23:57:51
Local

Downloader demo watermarks

10.0.30.0/24 *[Direct/0] 5d 23:57:51
> via at-2/2/1.10
[OSPF/10] 00:03:16, metric 6
> via at-2/2/1.10
10.0.30.1/32 *[Local/0] 5d 23:57:51
Local
328
 8. IGP Routing Protocol Configuration
10.100.0.0/24 *[OSPF/10] 00:03:16, metric 12
> via at-2/2/1.10
10.200.0.1/32 *[Local/0] 5d 23:57:51
Reject
224.0.0.5/32 *[OSPF/10] 00:41:03, metric 1
lab@Boston>
Increasing the cost on router Boston's interface directly connected to router Chicago to 21 will increase the total
path metric to 27. The path to 10.100.0.0/24 through Washington D.C. has a metric of 26 which is 6 + 10 + 10
for the three links. Increasing the cost of Boston's interface to Chicago will increase the metric to one more than the
cost through Washington D.C. The preferred route to 10.100.0.0 will then be through Washington D.C. The
metric is modified in the [edit protocols ospf area x interface (interface)] hierarchy.
[edit protocols ospf area 0.0.0.0 interface at-2/2/1.10]
lab@Boston# set metric 21
[edit protocols ospf area 0.0.0.0 interface at-2/2/1.10]
lab@Boston#

lab@Boston> show route

inet.0: 9 destinations, 9 routes (8 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.10.0/24 *[OSPF/10] 00:01:14, metric 20

> to 10.0.20.1 via fe-2/0/0.0
10.0.20.0/24 *[Direct/0] 00:32:17

www.ebook-converter.com
10.0.20.2/32
> via fe-2/0/0.0
*[Local/0] 5d 23:48:46
Local
10.0.30.0/24 *[Direct/0] 5d 23:48:46
> via at-2/2/1.10
[OSPF/10] 00:01:14, metric 21
> via at-2/2/1.10
10.0.30.1/32 *[Local/0] 5d 23:48:46
Local
10.100.0.0/24 *[OSPF/10] 00:01:14, metric 26
> to 10.0.20.1 via fe-2/0/0.0
10.200.0.1/32 *[Local/0] 5d 23:48:46
Reject
224.0.0.5/32 *[OSPF/10] 00:31:58, metric 1

lab@Boston>

Downloader demo watermarks

The route is now pointing towards Washington D.C. for 10.100.0.0/24 with a metric of 26.

Changing OSPF Priority

Unless otherwise shown, the priority a router has is set at 128. If you want to manipulate the election of a router as
329
 8. IGP Routing Protocol Configuration
DR or BDR, you can change the router's priority. The router best suited to be the link's DR should be set with the
highest priority. The router to be the BDR should be set with a priority higher than the non-DR routers', but not as
high as the DR's. Both of the DR and BDR priorities should be above 128 to ensure that a new router with a default
priority doesn't take over as DR or BDR at a later date. If a router is completely unsuited to be DR or BDR, it
should be configured with a priority of 0, because a priority 0 router will never become DR or BDR.
The command to change OSPF priority on an interface is as follows:
[edit protocols ospf area 0.0.0.25 interface fe-0/0/0.0]
lab@Wash-DC# set priority 150
This is shown under the OSPF area interface as follows:
[edit protocols ospf]
lab@Wash-DC# show
export stat_ospf;
area 0.0.0.25 {
nssa {
default-lsa {
metric-type 2;
type-7;
}
no-summaries;
}
interface fe-0/0/1.0;
interface fe-0/0/0.0 {
priority 150;
}

www.ebook-converter.com
}

[edit protocols ospf]

lab@Wash-DC#
Router Washington D.C. has had its OSPF priority changed from a default of 128 to 150.

Checking OSPF Operation

Certain commands can be used to ensure the basic functioning of OSPF. They can be used for verification that
configuration is working correctly or as a tool to assist in troubleshooting.
To see all interfaces on which OSPF is configured, use the show ospf interface brief or show ospf
interface detail command. Here is an example of the output of the same interface using first the brief
option, then the detail option. This shows the interface, whether it is a DR or BDR, which routers are DR and
BDR, and how many neighbors are on that particular interface.

Downloader demo watermarks

lab@Wash-DC> show ospf interface brief
Interface
fe-0/0/0.0
State
DR
Area
0.0.0.25
DR ID
10.0.10.2
BDR ID
10.0.10.1
Nbrs
1
fe-0/0/1.0 DR 0.0.0.25 10.0.10.2 0.0.0.0 0
lab@Wash-DC> show ospf interface detail
330
 8. IGP Routing Protocol Configuration
Interface State Area DR ID BDR ID Nbrs
fe-0/0/0.0 DR 0.0.0.25 10.0.10.2 10.0.10.1 1
Type LAN, address 10.0.10.2, mask 255.255.255.0, MTU 1500, cost 10
DR addr 10.0.10.2, BDR addr 10.0.10.1, adj count 1
Hello 10, Dead 40, ReXmit 5, Stub NSSA
fe-0/0/1.0 DR 0.0.0.25 10.0.10.2 0.0.0.0 0
Type LAN, address 10.0.20.1, mask 255.255.255.0, MTU 1500, cost 10
DR addr 10.0.20.1, BDR addr 0.0.0.0, adj count 0
Hello 10, Dead 40, ReXmit 5, Stub NSSA

lab@Wash-DC>
After checking the interfaces, the next step is to check for OSPF neighbors using the show ospf neighbors
command. This command also has a brief and detailed option. It shows the address of the neighbors and
associated interfaces, the state of the OSPF adjacency, and the RID. Also included in the output is the priority of
that interface and the dead time before the neighbor is considered down.
lab@Wash-DC> show ospf neighbor brief
Address Interface State ID Pri Dead
10.0.10.1 fe-0/0/0.0 Full 10.0.10.1 128 36
lab@Wash-DC> show ospf neighbor detail
Address Interface State ID Pri Dead
10.0.10.1 fe-0/0/0.0 Full 10.0.10.1 128 31
area 0.0.0.25, opt 0x40, DR 10.0.10.2, BDR 10.0.10.1
Up 00:32:26, adjacent 00:32:26

lab@Wash-DC>

www.ebook-converter.com
If the interface is configured correctly, and the neighbors are in a full state, you can also check the OSPF database.
This should have the appropriate store of LSAs. You will want to verify that all of the area internal routers and
network links are there.
lab@Wash-DC> show ospf database
OSPF link state database, area 0.0.0.25
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 10.0.10.1 10.0.10.1 0x80000008 237 0x0 0x9b51 36
Router *10.0.10.2 10.0.10.2 0x8000000a 582 0x0 0x931d 48
Network *10.0.10.2 10.0.10.2 0x80000005 595 0x0 0x9967 32
NSSA *10.220.0.0 10.0.10.2 0x80000005 582 0x8 0xe7cb 36
NSSA *10.221.0.0 10.0.10.2 0x80000005 582 0x8 0xdbd6 36
NSSA *10.222.0.0 10.0.10.2 0x80000005 582 0x8 0xcfe1 36
lab@Wash-DC>

Downloader demo watermarks

Design Principles
Properly utilizing assigned IP network space is an important design consideration. With a routing protocol like
OSPF, it is even more so. Improper use of discontinuous subnets can increase the size of a routing table drastically.
It can keep the area-range summarization feature from being used to its fullest potential. Ideally, an OSPF area

331
 8. IGP Routing Protocol Configuration
can be summarized by one network statement.
Quite often, network implementations and IP addressing schemes are not ideal, which can lead to larger LSDBs and
routing tables. There are features of OSPF that can ease the burden of maintaining routing tables. The idea is to
have an LSDB that is as small as possible, but still maintains optimal routing. Use not just area-ranges into the core,
but also the stub configuration to filter type 5 external advertisements.
Create areas wisely. All routers in an area must have a full database of all routers and networks in the area. It
makes sense to create more areas if maintaining the database in a given area becomes taxing. If they are properly
addressed to keep routing table sizes down, having more areas can be efficient. Bear in mind that a robust backbone
is necessary to handle links for increased interarea traffic.

IS-IS
IS-IS, or Intermediate System to Intermediate System, is a hierarchical link IGP similar in function to OSPF. IS-IS is
rooted in the DECnet Phase V routing protocol designed by Radia Perlman around 1985 and standardized by the
International Standards Organization (ISO) in 1988. The ISO had implemented IS-IS for use with Connectionless
Network Protocol (CLNP), but IS-IS could be extended for use with any Layer 3 protocol. CLNP specified IS-IS
and End System to Intermediate System (ES-IS) communications parameters. End systems are devices that send
and receive data, such as PCs. Intermediate systems are those that primarily forward data (but can send and receive
data as required), such as routers. IS-IS defines the communications parameters between intermediate system
devices.
IS-IS was then extended to cover IP routing in addition to CLNP. This extended protocol is sometimes known as
Integrated IS-IS or Dual IS-IS. RFC 1195 (December 1990) is the proposed IETF standard. Since 1990, many
implementations of IS-IS have added features that have gone above and beyond the proposed standard. Three
common practice, or informational, RFCs were drafted in 2000. These newer IS-IS RFCs are 2763, 2966, and 2973.

www.ebook-converter.com
Another version of IS-IS was developed for the Internetwork Packet Exchange (IPX) protocoland was named
NetWare Link State Routing Protocol (NLSP) (although NLSP and IS-IS are not compatible). So, as you can see,
the IS-IS design is flexible enough to be used with many Layer 3 protocols, but IP is the protocol we are concerned
with in this book.

IS-IS Overview
How does a routing protocol that was designed originally for CLNP differ from OSPF, which is designed
specifically for IP? There are the following differences:
IS-IS has a DR, but not a BDR, and its DR is preemptive.
The IS-IS election priority range is 0 through 127 (with a default of 64 on Juniper Networks routers), while the
range for OSPF is 0 through 255 (with a default of 128).
OSPF runs on IP, while IS-IS specifies a Layer 2 encapsulation

Downloader demo watermarks

IS-IS does not have a virtual link feature.
For the most part, however, IS-IS and OSPF have the following root features in common:
Hierarchical area routing

332
 8. IGP Routing Protocol Configuration
A link state topology database of a particular area
Dijkstra algorithm for finding the shortest path
Cost-based metric (bandwidth)
Neighboring routers that establish adjacencies
OSPF LSA-like link state PDU (LSPs)
The use of a DR (or Designated IS) on multiaccess links
If you recall, OSPF had a backbone area called area 0, with all other areas attached to it. IS-IS also has multiple
areas, called Level 1 areas and Level 2 areas, with Level 2 areas representing the backbone and having the same
function as area 0 in OSPF. Figure 8-30 shows several Level 1 areas connected through Level 1/2 (L1/2) routers to
a Level 2 area.

www.ebook-converter.com
Figure 8-30. IS-IS Areas
The L1/L2 routers have the same function as ABRs in OSPF. They filter unnecessary advertisements into a Level 1
area and can summarize network advertisements out of a Level 1 area.
In IS-IS and OSPF each router has an RID used for election purposes (DR configured priority, notwithstanding) and
for identification in the link state topology database. Because of the origin of IS-IS, a CLNP-type address is used
instead of an IP address to identify the router to other routers. Unlike OSPF, which will use an IP address, this
CNLP address must be configured manually on the loopback, and all interfaces that will participate in IS-IS must be
configured to use the loopback address.
Going back to the interface configuration in Chapter 7, the family iso command is used when IS-IS is the IP
routing protocol of choice. The ISO address is placed on the loopback interface. All other interfaces that need to
run IS-IS have family iso added to their configuration.
IS-IS also uses a cost metric and can be configured in the same way as OSPF, but the default metric behavior is
Downloader demo watermarks
slightly different. IS-IS gives all links a default metric of 10 and uses no reference bandwidth until it is configured to
do so. It would be wise to set a reference bandwidth, just as in OSPF.

ISO CLNP and Addressing

333
 8. IGP Routing Protocol Configuration
The CLNP address used for the RID is called a network entity title, or NET. This address is stored as a loopback
and is assigned to all of the interfaces that run IS-IS. The interfaces that run IS-IS are called network service access
points (NSAPs), which is just another term for an IS-IS-enabled interface.
ISO addressing is a bit different than IP addressing. The addresses can range in size from 8 to 20 bytes. There are
different levels of ISO addressing. The shortest and least complicated is called a simple NET. This addressing
scheme uses one byte for the area, a minimum of six bytes for the system ID, and one last trailing byte for a
selector. Figure 8-31 illustrates a simple NET ISO address. The address, written in hexadecimal
(30.0101.c5af.6001.00), is shown in sections.

Figure 8-31. IS-IS Simple Net ISO Address

In OSPF, the area ID cannot be derived by the RID. In IS-IS the area and RID are combined. In Figure 8-31, the
area ID is one byte and the system ID is six bytes. The last byte is the selector byte, which is set to 0. The router's
NET on the loopback will normally be configured as 0x00. IS-IS just takes two similar portions of the identification
used in OSPF and combines them.

Note
For L1 routers to form adjacencies, they must have a common area field. The LSP identifies them as
being intra-area. L2 routers can have different area identifiers.
There are two other NET types that are more complicated and have more than three parts. These addresses can be

www.ebook-converter.com
as many as 20 bytes in length. These are the ISO NSAP and Government Open Systems Interconnection Profile
(GOSIP). The ISO NSAP is 14 bytes in length and has an additional field—the domain field—as compared to the
simple NET. Figure 8-32 illustrates an ISO NSAP. It the same as the simple NET with an extra six bytes on the
front.

Figure 8-32. IS-IS ISO NSAP Address

The domain field was intended to break large IS-IS networks up into smaller domains, using CLNP extensively. The
domain field was to be used for interdomain routing in a manner similar to an AS number for BGP. Since IP has
become much more popular than CLNP, this usage has not caught on.
GOSIP is the most complicated addressing CLNP scheme. GOSIP addresses are controlled by government
authorities, and the fields that make them up are analogous to country codes and area codes in phone numbers.
Downloader demo watermarks
Figure 8-33 shows the fields of a GOSIP address. This address is 20 bytes in length.

334
 8. IGP Routing Protocol Configuration
Figure 8-33. IS-IS GOSIP Address
The abbreviations for the field names in Figure 8-33 are defined as follows
AFI—Authority and format identifier
IDI—International domain identifier
DFI—Domain specific part (DSP) format identifier
AA—Administrative authority
Rsvd—Reserved
RDI—Routing domain identifier
Area—Area ID
System ID—Individual RID
Sel—Selector bit
Notice that the end part of the addressing scheme is the same as in the earlier addressing schemes. In some texts,
the IDI is also called an ICD, or international code designator. A detailed explanation of the usage of these fields is
beyond the scope of this book. Instead, see RFC 1237 “Guidelines for OSI NSAP Allocation in the Internet,” at
www.ietf.org/rfc.html.

DRs
www.ebook-converter.com
IS-IS elections are very similar to OSPF elections. When an interface is configured for IS-IS, it immediately starts
sending out hellos. The priority is checked, and the router with the highest priority becomes the DR. One difference
from OSPF is that in IS-IS the DR will change when a higher-priority router is configured onto the link. This
behavior is called preemptive, because a higher priority router can preempt the status quo. This is important to
know if a router with a high priority is to be added to a multiaccess link with many routers. Routing processes could
be interrupted as all of the adjacencies drop from the old DR and are set up with the new DR.

IS-IS PDUs
IS-IS uses three main PDUs to exchange information. These PDU types are hello, link state, and sequence number
packets (SNPs). The hello PDU serves the same function as it does in OSPF. The packet is sent out of IS-IS-enabled
interfaces to find neighbors. Once neighbors are found, adjacencies can be formed. After an adjacency is
established, the hellos continue to inform the adjacent routers that the sending router is still up. There are three
types of hello PDUs that IS-IS routers use: L1 broadcast network, L2 broadcast network, and any point-to-point
network.

Downloader demo watermarks

Link state PDUs (LSPs) are quite similar to LSAs in OSPF. They allow the exchange of route information between
IS-IS-enabled routers. The main difference is that in OSPF there are many types of LSAs, each carrying different
information. In IS-IS, there are two types of LSPs: Level 1 LSPs and Level 2 LSPs. Each contains all of the
information for its level.

335
 8. IGP Routing Protocol Configuration
SNPs are used to ensure that all the routers on a link have the same information. They are used in a similar manner
as acknowledgments. There are four types of SNPs: Level 1 and Level 2 can each send a partial SNP (PSNP) or a
complete SNP (CSNP). A PSNP is similar to an acknowledgment and lists the sequence numbers of the most recent
LSPs; however, a PSNP can acknowledge more than one LSP at a time. PSNPs can also request missing LSPs on a
multiaccess link. A CSNP contains the latest sequence numbers of all of the LSPs in the database and is used to
synchronize the client router's database to the DR's database.

Default Stub Areas

By default, IS-IS L1 areas are in a state similar to an NSSA in OSPF. This means that there are no routes, other than
the Level 1 routes for the IS-IS network. The L1 router has no awareness of the intra-area destinations in the
routing table. When the route is unknown, the packet is forwarded toward the nearest L1/L2.
When an L1/L2 router receives information on other Level 1 routers, it sets an attached field in the L1 LSP,
indicating that it is attached to the Level 2 backbone and can forward to destinations that are unknown to the Level
1 routers. When a Level 1 router receives the LSP with the attached field set, it sets a default route to that router.
There are no virtual link features in IS-IS. If a Level 2 area is partitioned, a Level 1 area cannot be used to transit
the traffic. If an L1/L2 router loses connection to the Level 2 area, it will notify adjacent routers through its LSPs
that it is not attached to Level 2 (by ceasing to set the attached field), and the other Level 1 routers will then send
their unknown traffic to the next nearest L1/L2 router.

IS-IS Route Leaking

L1 routers set default routes to L1/L2 routes. In most cases, for redundancy, there will be more than one L1/L2
router for the L1 area. External and interarea routes can be advertised into the L1 area from specific L1/L2 routers.

www.ebook-converter.com
This is known as route leaking.
If only default routes are used to forward traffic out of an L1 area, suboptimal routing can occur when an L1 area
has more than one L1/L2 router. Figure 8-34 shows router Chicago in an L1 area. Routers Boston and New York
are the L1/L2 routers for Chicago's area. They will both advertise an attached bits area 11. If router Chicago has a
better metric to router Boston than New York for the default route, then all of the out-of-area traffic will pass
through Boston, even the traffic destined for network 192.168.10.0/24.

Downloader demo watermarks

Figure 8-34. IS-IS Route Leaking
If New York advertises 192.168.10.0/24 into Chicago's area, then the longest match will allow Chicago to
336
 8. IGP Routing Protocol Configuration
forward to New York despite what the default metrics are. New York is leaking the route into area 11. Route
leaking can also be used to make a more deterministic forwarding decision by area routers to spread link usage. If
the link between New York and Paris is underutilized, both routers can be configured to leak a few routes for more
efficient use of the L1/L2 routers.
Route leaking is accomplished by exporting routes into the IS-IS area from the L1/L2 router that you desire to use
as the gateway out of the area for those destinations. Exporting routes will be covered in detail in Chapter 11.

IS-IS Single-Area Configuration

IS-IS configuration requires an ISO address on the loopback interface. This will be the area ID and RID equivalent.
To allow the interface to process incoming IS-IS packets, you use the family iso command in the [edit
interfaces (interface)] configuration. The interface command does not actually involve an address; it
simply binds that interface to the ISO address on the loopback interface. Lastly, just as in OSPF, interfaces are
assigned to IS-IS in the protocol directory.
Figure 8-35 shows a single L1 area 10. All of the ISO addresses for the loopback interface will begin with 10. For
the system ID, the IP address of an interface can always be used. This can help you quickly identify the router by
the RID when the system ID is a recognizable address that has been configured on the router (especially the
loopback).

www.ebook-converter.com
Figure 8-35. IS-IS Single-Area Configuration
For the configuration of the system ID portion of the NET, Washington D.C. and Chicago will use the last two
bytes of the fe-0/0/0.0 interface IP address. Boston will use the last two bytes of the fe-2/0/0 IP address.
Remember that these values in the address field are hexadecimal.
Router Chicago:
[edit interfaces lo0]
lab@Chicago# set unit 0 family iso address 10.0000.0010.0001.00
[edit interfaces lo0]
lab@Chicago# show
Downloader demo watermarks
unit 0 {
family iso {
address 10.0000.0010.0001.00;
}
}

337
 8. IGP Routing Protocol Configuration
[edit interfaces lo0]
lab@Chicago#
Router Washington D.C.:
[edit interfaces lo0 unit 0]
lab@Wash-DC# set family iso address 10.0000.0010.0002.00
Router Boston:
[edit interfaces lo0 unit 0]
lab@Boston# set family iso address 10.0000.0020.0002.00
The next step is to add the family iso command to the interfaces that will be included in the IS-IS protocol.
[edit interfaces]
lab@Chicago# set fe-0/0/0 unit 0 family iso

[edit interfaces]
lab@Chicago# set at-0/1/0 unit 20 family iso

[edit interfaces]
lab@Chicago# set at-0/1/1 unit 10 family iso

[edit interfaces]
lab@Chicago# show
. . .cut

www.ebook-converter.com
}
at-0/1/0 {
atm-options {
vpi 0 maximum-vcs 250;
}
unit 20 {
vci 100;
family inet {
address 10.100.0.1/24;
}
family iso;
}
}at-0/1/1 {
atm-options {
vpi 0 maximum-vcs 250;
}
unit 10 {
vci 200;
Downloader demo watermarks
family inet {

}
address 10.0.30.2/24;
family iso;
}
}cut . .
338
 8. IGP Routing Protocol Configuration
Finally, you need to configure the interfaces in the routing protocol. Just as in OSPF, if all interfaces will be in the
same area, then the set interface all command can be used. When an IS-IS level is not specified for an
interface, an L1/L2 is set up by default. To keep only Level 1 on the interfaces, you can disable L2 routing. In
addition, the loopback 0 (lo0) interface must be added to ensure that the interface that the NET is configured on is
in IS-IS.
[edit protocols]
lab@Chicago# set isis interface all level 2 disable

[edit protocols]
lab@Chicago# show
isis {
interface all;
}
[edit protocols isis]
lab@Wash-DC# set interface lo0 level 2 disable
[edit protocols isis]
lab@Wash-DC# set interface fe-0/0/0 level 2 disable
[edit protocols isis]
lab@Wash-DC# set interface fe-0/0/1 level 2 disable
[edit protocols isis]
lab@Wash-DC# set reference-bandwidth 1g
[edit protocols isis]

www.ebook-converter.com
lab@Wash-DC# show
reference-bandwidth 1g;
interface fe-0/0/0.0 {
level 2 disable;
}
interface fe-0/0/1.0 {
level 2 disable;
}
interface lo0.0 {
level 2 disable;
}
[edit protocols isis]
lab@Wash-DC#
Now all three routers should have NETs, should have family iso assigned to the interfaces, and should have all
interfaces, including the loopback, in IS-IS with Level 2 information disabled. To see on which interfaces IS-IS is

Downloader demo watermarks

implemented, and for which area levels, use the show isis interface command. This will show which
interface is in which level, as well as DR information. The DR information is the name of the DR router and the
selector bit assigned for the connected interface, as is shown below:
lab@Wash-DC> show isis interface
IS-IS interface database:
339
 8. IGP Routing Protocol Configuration
Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric
fe-0/0/0.0 1 0x2 Chicago.02 Disabled 10/10
fe-0/0/1.0 1 0x3 Wash-DC.03 Disabled 10/10
lo0.0 0 0x1 Passive Disabled 0/0
lab@Wash-DC>
To see the status of neighbor adjacencies, use the show isis adjacency command. This command is slightly
different from OSPF's show ospf neighbor command, but the function is the same.
lab@Wash-DC> show isis adjacency
IS-IS adjacency database:
Interface System L State Hold (secs) SNPA
fe-0/0/0.0 Chicago 1 Up 7 0:90:69:a4:d8:0
fe-0/0/1.0 Boston 1 Up 20 0:90:69:52:94:fc

lab@Wash-DC>
The contents and state of the LSP database for IS-IS can be shown with the show isis database command.
As in OSPF, the sequence number of the LSP is shown. Unlike OSPF, instead of the Age of the advertisement, the
Lifetime, or amount of time left to the LSP, is shown.
lab@Wash-DC> show isis database
IS-IS level 1 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
Chicago.00-00 0x7 0xbbb 515 L1
Chicago.02-00 0x3 0x95c4 487 L1
Wash-DC.00-00 0x7 0xef53 648 L1

www.ebook-converter.com
Wash-DC.03-00 0x4 0xd85c 648 L1
Boston.00-00 0x4 0x1003 552 L1
0100.0010.0001.00-00 0x4 0 0 L1
0100.0010.0001.02-00 0x1 0 0 L1
0100.0010.0002.00-00 0x6 0 0 L1
0100.0010.0002.03-00 0x1 0 0 L1
0100.0010.0003.00-00 0x7 0 0 L1
10 LSPs
IS-IS level 2 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
Wash-DC.00-00 0x8 0x28e5 648 L1 L2
0100.0010.0002.00-00 0x7 0 0 L1 L2
2 LSPs

lab@Wash-DC>
As previously mentioned, the actions, commands, and functions of OSPF and IS-IS are very similar, since they are
both Link State Protocols (LSPs).
Downloader demo watermarks
IS-IS Multiple-Area Configuration
In the single-area scenario, Level 2 routing is disabled on all interfaces to create a single Level 1 area. To create a
Level 2 area and connect Level 1 areas, L1/L2 routers have to be created. In a large Level 2 area, L2-only routers
340
 8. IGP Routing Protocol Configuration
would be configured. In Figure 8-36, an L2 area connects L1 area 25 and area 59.

Figure 8-36. IS-IS L1-L2 Connection

Configuring routers Washington D.C. and London is the same as for the single-area configuration example. The
loopback addresses are configured, all interfaces are installed in IS-IS with Level 2 disabled, and the reference
bandwidth is set.
[edit interfaces lo0 unit 0 family iso]
lab@Wash-DC# set address 10.0000.0010.0002.00

[edit protocols isis]

lab@Wash-DC# set interface all level 2 disable

www.ebook-converter.com
[edit protocols isis]
lab@Wash-DC# set reference-bandwidth 1g
Router Chicago is an L1/L2 router. After configuring the lo0 interface, the interfaces have to be added to different
levels. Be sure to add the loopback to IS-IS.
[edit protocols isis]
lab@Chicago# set interface fe-0/0/0 level 2 disable

[edit protocols isis]

lab@Chicago# set interface at-0/1/1.10 level 1 disable

[edit protocols isis]

lab@Chicago# set interface lo0

[edit protocols isis]

lab@Chicago# set reference-bandwidth 1g

Downloader demo watermarks

[edit protocols isis]
lab@Chicago# show
reference-bandwidth 1g;
interface fe-0/0/0.0 {
level 2 disable;
}
341
 8. IGP Routing Protocol Configuration
interface at-0/1/1.10 {
level 1 disable;
}
interface lo0.0;
Looking at the adjacencies of router Chicago, you can see one Level 2 and one Level 1 adjacency.
lab@Chicago> show isis adjacency
IS-IS adjacency database:
Interface System L State Hold (secs) SNPA
at-0/1/1.10 Boston 2 Up 26
fe-0/0/0.0 Wash-DC 1 Up 22 0:90:69:9e:80:0
Chicago has full knowledge of all routes that are being advertised from both Level 1 areas.
lab@Chicago> show route
inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.10.0/24 *[Direct/0] 1w2d 02:19:24
> via fe-0/0/0.0
10.0.10.1/32 *[Local/0] 1w2d 02:19:24
Local
10.0.20.0/24 *[IS-IS/15] 00:35:01, metric 20, tag 1
> to 10.0.10.2 via fe-0/0/0.0
10.0.30.0/24 *[Direct/0] 1w2d 02:19:24
> via at-0/1/1.10

www.ebook-converter.com
10.0.30.2/32 *[Local/0] 1w2d 02:19:24
Local
10.100.0.0/24 *[Direct/0] 1w1d 02:38:17
> via at-0/1/0.20
10.100.0.1/32 *[Local/0] 1w2d 02:19:24
Local
10.150.0.0/24 *[Static/5] 3d 01:50:25
> to 10.100.0.2 via at-0/1/0.20
10.200.0.0/24 *[IS-IS/18] 00:26:58, metric 12, tag 2
> to 10.0.30.1 via at-0/1/1.10
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0000.0010.0001.00/64
*[Direct/0] 00:35:33
> via lo0.0

Downloader demo watermarks

No stub area was configured, but remember, IS-IS defaults to an NSSA (stub with no summaries) when a Level 1
area is attached to a Level 2 area. When Chicago is configured as an L1/L2 area, it filters out all other nonarea 10
routes from area 25 and advertises attached status. Router Washington D.C. may not know about any routes any
other router has, but it now has a way to exit area 10. Notice that 10.0.30.0/24 and 10.200.0.0/24 are no
longer in the routing table. They have been replaced by a 0.0.0.0/0 default route to router Chicago.

342
 8. IGP Routing Protocol Configuration
lab@Wash-DC> show route

inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[IS-IS/15] 00:30:01, metric 10, tag 1
> to 10.0.10.1 via fe-0/0/0.0
10.0.10.0/24 *[Direct/0] 1w2d 02:21:08
> via fe-0/0/0.0
10.0.10.2/32 *[Local/0] 1w2d 02:21:08
Local
10.0.20.0/24 *[Direct/0] 3d 03:14:36
> via fe-0/0/1.0
10.0.20.1/32 *[Local/0] 3d 03:14:36
Local

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

10.0000.0010.0002.00/64
*[Direct/0] 00:41:00
> via lo0.0

lab@Wash-DC>

IS-IS Authentication Configuration

There are two different ways to configure authentication for IS-IS: global and hello packet. Global is configured for

www.ebook-converter.com
the entire IS-IS routing protocol and any router wishing to form an adjacency. Hello authentication is configured
between two particular routers at the interface level.
Global IS-IS authentication for IS-IS adjacency is very similar to OSPF. The difference in configuration is that in
OSPF under the [edit protocols ospf (area)] directory, the authentication type is defined and then the
key is defined under the [edit protocols ospf area (interface)] directory. In IS-IS, the
configuration for the authentication type and the key configuration can take place globally [edit protocols
isis], under the level [edit protocols isis level #], or under an interface [edit protocols
isis interface (interface)].
Under the directory [edit protocols isis interface (interface)], the authentication-type
and authentication-key are used for validation of hello packets. In Figure 8-37, Level 2 will have global
authentication configured, while hello authentication will be configured between the Level 1 routers of area 25. The
global L2 authentication will require any router that wishes an L2 adjacency with Boston to be configured in the
same way.

Downloader demo watermarks

343
 8. IGP Routing Protocol Configuration

Figure 8-37. IS-IS Authentication

Setting up the authentication between router Chicago and router Boston is rather straightforward. This is a
levelwide authentication, so it will go under the level directory for Level 2. This example starts with router Boston.
[edit protocols isis]
lab@Boston# set level 2 authentication-type md5

[edit protocols isis]

lab@Boston# set level 2 authentication-key test123

[edit protocols isis]

lab@Boston# show

www.ebook-converter.com
reference-bandwidth 1g;
level 2 {
authentication-key “$9$f5nCOBEyeWRhdbY2aJn/9”; # SECRET-DATA
authentication-type md5;
}
interface at-2/2/0.10 {
level 2 disable;
}
interface at-2/2/1.10 {
level 1 disable;
}
interface lo0.0;

[edit protocols isis]

lab@Boston#
Once the Level 2 authentication is configured, the interface in Level 1 will be configured for hello authentication.
This requires leaving the Level 2 directory and moving into the IS-IS interface directory. The hello authentication is
Downloader demo watermarks
configured on the IS-IS interface and will only affect the IS-IS adjacencies on that link.
[edit protocols isis]
lab@Chicago# set level 2 authentication-type md5

[edit protocols isis]

344
 8. IGP Routing Protocol Configuration
lab@Chicago# set level 2 authentication-key test123
[edit protocols isis]
lab@Chicago# edit interface fe-0/0/0

[edit protocols isis interface fe-0/0/0.0]

lab@Chicago# set hello-authentication-type md5

[edit protocols isis interface fe-0/0/0.0]

lab@Chicago# set hello-authentication-key 123test

[edit protocols isis]

lab@Chicago# show
reference-bandwidth 1g;
level 2 {
authentication-key “$9$pgd/uRSvMX-b2LxUjkqf5Rhc”; # SECRET-DATA
authentication-type md5;
}
interface fe-0/0/0.0 {
hello-authentication-key “$9$P536Ctu1EcApIclex7Hqm”; # SECRET-DATA
hello-authentication-type md5;
level 2 disable;
}
interface at-0/1/1.10 {
level 1 disable;
}
interface lo0.0;

www.ebook-converter.com
How can you tell that authentication is working? With global IS-IS authentication configuration, if any routers
wishing to form an adjacency are not properly configured, the adjacency will not form. This differs from hello
authentication, which is done between specific neighbors. Look at the adjacencies for router Chicago. Routers
Boston and Chicago have had authentication configured, but router Washington D.C. has not. Notice the rejection
of adjacency to Washington D.C.
[edit protocols isis]
lab@Chicago# run show isis adjacency
IS-IS adjacency database:
Interface System L State Hold (secs) SNPA
at-0/1/1.10 Boston 2 Up 22
fe-0/0/0.0 Wash-DC 1 Rejected 11 0:90:69:9e:80:0

[edit protocols isis]

lab@Chicago#

Downloader demo watermarks

Add the configuration to Washington D.C., and the adjacency between Washington D.C. and Chicago is now re-
established because the adjacency authentication is now the same on both routers.
[edit protocols isis interface fe-0/0/0.0]
lab@Wash-DC# set hello-authentication-type md5

345
 8. IGP Routing Protocol Configuration
[edit protocols isis interface fe-0/0/0.0]
lab@Wash-DC# set hello-authentication-key 123test

[edit protocols isis interface fe-0/0/0.0]

lab@Wash-DC#

[edit protocols isis interface fe-0/0/0.0]

lab@Wash-DC# run show isis adjacency
IS-IS adjacency database:
Interface System L State Hold (secs) SNPA
fe-0/0/0.0 Chicago 1 Up 6 0:90:69:a4:d8:0
[edit protocols isis interface fe-0/0/0.0]
lab@Wash-DC#
This section has demonstrated both IS-IS global and hello authentication. Global authentication is for any router on
any link to communicate; hello authentication is interface- and link-specific.

Checking IS-IS Operation

As shown in the preceding configuration sections, troubleshooting IS-IS consists of checking the interface, the
adjacency states, and the database. The only difference from OSPF in IS-IS show commands is that show isis
adjacency is used instead of show ospf neighbor.
Checking interfaces will show which interfaces have IS-IS configured, which level they are assigned, the DR for
that interface, and what the metric is.

www.ebook-converter.com
lab@Wash-DC> show isis interface
IS-IS interface database:
Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric
fe-0/0/0.0 1 0x2 Chicago.02 Disabled 10/10
fe-0/0/1.0 1 0x3 Wash-DC.03 Disabled 10/10
lo0.0 0 0x1 Passive Disabled 0/0
lab@Wash-DC>
Checking the adjacency states will provide information on the relationship with adjoining routers. This includes to
which interface the adjacent router is connected, which the adjacent router is, what the state of the relationship is
currently, and how long it has been up.
lab@Chicago> show isis adjacency
IS-IS adjacency database:
Interface System L State Hold (secs) SNPA
at-0/1/1.10 Boston 2 Up 22
fe-0/0/0.0 Wash-DC 1 Rejected 11 0:90:69:9e:80:0
Downloader demo watermarks
lab@Chicago>
Looking at the contents of the LSDB can assist in ensuring that all the devices that are supposed to be in the area
are in fact in the database. Are all of the routers and links listed? Are there supposed to be summaries in the
database or just a default route? Checking the routing table is most important. The whole purpose of using and
346
 8. IGP Routing Protocol Configuration
tuning routing protocols is to ensure that the next-hop is what you expect it to be. This will ensure that the routers
have the proper information to make an informed decision for packet forwarding.

Chapter Summary
Routing protocols help make up the map that allows the Internet to exist by telling each other about the networks
they know of, where they are, and how far away. These pieces of information allow a router to make a forwarding
decision for a particular destination. There are two major groups of protocols: those that communicate between
different administrative entities (called EGPs), and those that operate within an administrative entity (IGPs). IGPs
are routing protocols that service networks under the control of one administrative entity. IGPs can be either
distance vector, based on hop count, or link state, based on a complete picture of routers and links for a given area.
RIP is a type of distance vector protocol and has many limitations. OSPF and IS-IS are both LSPs that use a
database to keep track of routers, links, and networks in an area. Both of these link state networks can be broken
down into multiple areas that connect to a backbone through which all traffic to another area must pass.
With careful planning and proper feature implementation, the Juniper Networks router can create a high-speed,
fault-tolerant, scalable network for the internal administrative entity.

Bibliography

www.ebook-converter.com

Downloader demo watermarks

347
[ch08bib01] Kevin Downes,, et al. Internetworking Technologies Handbook, 2nd ed.
Cisco Press, <year>2000</year>.
[ch08bib02] Jeff. Doyle, Routing TCP/IP, Vol. I. Cisco Press, <year>1998</year>.
[ch08rfc1195] IETF RFC—RFC 1195, Use of OSI IS-IS for Routing in TCP/IP and Dual
Environments. R. Callon. 1990.
[ch08rfc1237] IETF RFC—RFC 1237, Guidelines for OSI NSAP Allocation in the
Internet, R. Colella, et al. 1991.
[ch08rfc1058] IETF RFC—RFC 1058, Routing Information Protocol. C. Hedrick. 1998.
[ch08rfc2453] IETF RFC—RFC 2453, RIP Version 2. G. Malkin. 1998.
[ch08rfc2328] IETF RFC—RFC 2328, OSPF Version 2. J. Moy. 1998.
[ch08bib08] IETF RFCs, at www.rfc-editor.org.
[ch08bib09] Radia Perlman,. Interconnections, 2nd ed. Addison-Wesley,
<year>1999</year>.

www.ebook-converter.com
[ch08bib10] Tom Thomas,. OSPF Network Design Solutions. Cisco Press,
<year>1998</year>.
[ch08bib11] www.juniper.net

Downloader demo watermarks

348
 9. BGP Routing Configuration
Chapter 9. BGP Routing Configuration
This chapter will discuss interdomain routing protocols and EGPs. Currently BGP4 is the de facto interdomain
routing protocol. The primary concern of this chapter, therefore, is to prepare you to configure BGP on Juniper
Networks routers. Though there are Juniper Networks–specific examples throughout this chapter, fundamentals
and theoretical topics are also covered. This means that if you have experience with other router vendors,
drawing the parallels between JUNOS and the others will be easy.
This chapter is not meant to be a complete reference on BGP. There are several other texts written on the
subject that provide a more in-depth look into the protocol. The objective here is to provide a concise overview
of the routing protocol, its major operational aspects, and JUNOS implementation and configuration. This will
be accomplished by providing theoretical discussion supported by illustration and Chapter 10's case studies.
The chapter will begin by discussing the role of BGP and its relationship to the internetworking world. Then, it
will examine the protocol's basic operational parameters and how they apply to routing. Next, it will examine
the Juniper Networks implementation and how to configure the base protocol. Finally, it will cover scaling
BGP.

BGP Overview
EGPs, in a nutshell, provide the information necessary for interdomain routing. More specifically, they provide
network layer reachability information (NLRI), which is used to determine the best paths through multiple ASs.
As discussed in Section 8.1, IGP provides the best route information within an AS. This chapter will focus on a
larger scale.
BGP4 is the implemented standard across the Internet and is in the EGP family. Figure 9-1 shows an overview

www.ebook-converter.com
of the relationship of BGP and a given IGP to the Internet. BGP provides NLRI between any two or more ASs.
Furthermore, any AS can use a different IGP to accomplish intradomain routing. Although not listed in the
figure, there are also cases in which BGP is used internally to provide reachability information. Doing so can
better optimize the intradomain routing to provide detailed routing information for multiple points of egress.

Downloader demo watermarks

Figure 9-1. BGP/IGP AS Overview

External BGP and Internal BGP Conceptual Model

349
 9. BGP Routing Configuration
BGP was developed to handle interdomain routing and eliminate issues surrounding such topics as routing
loops, backbone-to-backbone peering, and reachability information for IGPs for external networks. BGP is
used for both internal (IBGP) and external (EBGP) peering.
Figure 9-2 shows a very basic BGP logical view. Washington D.C., in AS100, has an EBGP session with New
York, in AS200. This session is considered external because it includes two neighbors, each in its own AS.
They are therefore external neighbors. There is also an IBGP session between New York and Boston in AS200,
so they are internal neighbors. Notice that there is no physical connection between the two. IBGP does not
require that the peers be directly connected. To take it one step further, we have included an internal router in
the physical path. There can be several non-BGP speaking routers within an AS. As long as the BGP speakers
can create a connection logically to each other, the peering session can be established.

Figure 9-2. IBGP and EBGP Conceptual Model

www.ebook-converter.com
The main distinguishers between EBGP and IBGP include how the BGP process handles routing updates, the
use of attributes, and the propagation of routing information.
EBGP sessions work differently than IBGP sessions. Typical EBGP peering routers are directly connected.
However, EBGP can take advantage of logical connectivity, like IBGP sessions, through the use of the
multihop statement. This will be covered later in Section 9.4.2.21. Again, EBGP peers are not in the same
AS; therefore, when setting up peering, EBGP peers typically will not listen to other devices advertising BGP
routes to them unless they are explicitly configured to do so.
IBGP sessions, on the other hand, operate differently. Peer sessions can be established either through directly
connected interfaces or logical connectivity. There is no true dependence on physical topology. In BGP, the
next-hop is almost always validated by a recursive lookup in the IGP routing table. If there is no next-hop route
to the border router (NEXT_HOP attribute), then BGP will not allow the route to be installed into the routing
table. IBGP also mandates that each IBGP-speaking router have a peering session with every other IBGP-
speaking router. This concept is known as IBGP full-mesh, or the IBGP mesh. In IBGP when a route is learned
from another IBGP peer, the receiving system will not advertise the route to other IBGP neighbors, owing to
the full-mesh concept. Since the advertisement will already have been sent to all peers from the original sender,

Downloader demo watermarks

there is no need to duplicate this information.
In Figure 9-3, we see a sample of IBGP peering sessions. Routers Washington D.C., New York, Atlanta, and
Dallas are configured to create a logical full-mesh. They do not have a physical full-mesh topology, however.
Washington D.C. does not have a physical connection to Dallas; New York does not have a physical
connection to Atlanta. However, in terms of IBGP connectivity, each router must have a peering session with
350
 9. BGP Routing Configuration
every other IBGP-speaking router. Because there is no longer a requirement for the IBGP session to be
established over a physically meshed topology, Washington D.C. and Dallas can establish a peering session
through either Atlanta or New York. In this particular scenario, if Atlanta were to fail, the IBGP session would
remain up through New York.

Figure 9-3. IBGP Logical Connectivity

Because IBGP can be established through logical connectivity, it is recommended that all IBGP sessions be
established between loopback interfaces because, if the loopback addresses are advertised into the IGP

www.ebook-converter.com
properly and a single physical interface to the local system is up, IBGP peering can be established.

Autonomous System Numbers

The introductory discussion of IBGP and EBGP mentioned autonomous systems, or ASs, which are basically
single administrative entities when it comes to the Internet. Each AS is unique, with no duplication occurring,
and is typically managed by a single network administration. Autonomous systems numbers (ASNs) can range
from 1 to 65,535; however, 32,768 to 64,511 are reserved for future use, and 64,512 to 65,535 are reserved for
use as private ASs. For larger enterprise networks and some carrier networks, the use of private ASNs works
well for scalability and for certain designs. These numbers should not be advertised beyond the boundary of the
public AS using them. If this sounds familiar, it is because private ASNs are not unlike private IP address
blocks referenced by IANA in RFC 1918.
For instance, a large carrier network may have an ASN of 100. This ASN is advertised throughout the Internet.
Through the use of BGP, prefixes are associated with AS100. BGP advertises or announces a given prefix to
other ASs. They, in turn, will announce the prefixes associated with AS100 to their neighbors. As this occurs,
Downloader demo watermarks
each AS attaches its own ASN to the advertisement, creating a path list. The AS_PATH attribute, explained in
Section 9.2.5.2, provides a listing of all ASs that have announced the prefix that originated in AS100. A remote
system in AS333 might receive an advertisement of a prefix from multiple external neighbors. Through the
route-selection process, explained in Section 9.1.4, the router will make a decision about which one of these
routes it will install into the local routing table.
351
 9. BGP Routing Configuration
Three regional Internet registries located throughout the world assign ASNs.
1. ARIN (www.arin.net) assigns numbers for North America, South America, the Caribbean, and sub-Saharan
Africa.
2. RIPE NCC (www.ripe.net) assigns numbers for Europe, the Middle East, and part of Africa.
3. APNIC (www.apnic.net) assigns numbers for Asia Pacific.
These registries provide IP and ASN assignment and allocation. The private address space and private ASNs
can be used without any approval. However, take caution in ensuring that no private IP or ASNs are advertised
into the public space. In JUNOS, this can be accomplished through the use of policy. ASNs can also be filtered
with the remove-private statement. Since it is vitally important that private ASNs do not get advertised
into the Internet routing table, providers have routing policy in place to ensure this type of information does not
traverse the external border routers.
In order for BGP to operate properly, the ASNs must be set. This is accomplished with the following command:
set routing-options autonomous-system ASN
routing-options {
autonomous-system 100;
}

Topologies: Transit and Homing

www.ebook-converter.com
BGP provides reachability information for the Internet. This section will discuss a few of the common
scenarios regarding transit and nontransit AS and homing.

Transit and Nontransit AS

The nature of internetworking has resulted in several different types of network topologies. Depending on
topology and how networks are connected to other networks, unintended results, such as suboptimal routing or
loss of routing information altogether, can occur. Figure 9-4 illustrates two topologies. In diagram 1, AS100 is
connected to AS200 and AS300. In diagram 2, AS100 is connected to AS200 in two places. These scenarios
can create a transit AS, which allows traffic not destined for networks residing in the AS to pass through to the
intended destination. Nontransit means that only traffic destined for the given AS should enter. Usually this is
not a problem, but when multihoming to different ASs and having large geographical topologies, the potential
for unintended transit issues to arise is greater. Maintaining a specific peering policy with upstream providers
and downstream customers can eliminate some transit problems. By performing in-depth analysis of your
peering arrangements and understanding all external connection points, you can administer your network and
cut down on the number of potential problems.

Downloader demo watermarks

352
 9. BGP Routing Configuration

Figure 9-4. Transit/Homing Overview Topologies

Homing
Homing generally refers to how an AS is interconnected. This section describes common homing topologies
and provides more detailed explanation of transit and nontransit ASs. There are three different characteristics
that an AS may take on:
1. Single-homed (stub AS), which has one ingress/egress point for all traffic
2. Multihomed nontransit, which has multiple ingress/egress points for traffic flow (nontransit indicates that
the AS should not be used to carry traffic or advertise routes for traffic not destined for the AS)
3. Multihomed transit, which also has multiple ingress/egress points for traffic flow (transit means policy
conditions are applied to allow negotiated traffic not destined for the AS to flow through the AS)

www.ebook-converter.com
A quick way to determine if a topology is considered multihomed or not is to determine if there are multiple
border routers or multiple links exiting a single router or AS.
Figure 9-5 illustrates a stub/single-homed router. Washington D.C. is connected to New York via some circuit.
New York has multiple connections to the rest of the Internet. Since Washington D.C. only has one egress
point it is single-homed and a stub. Figure 9-6 has a similar topology as Figure 9-5, but now there are two
circuits between Washington D.C. and New York. Washington D.C. is still a stub, but it is multihomed. It
would not make any sense to attempt to use Washington D.C. in this case for any transit traffic. It would only
add an additional hop to the path and would be a poor implementation of policy.

Downloader demo watermarks

Figure 9-5. Single-Homed Router (Stub)

353
 9. BGP Routing Configuration

Figure 9-6. Stub/Multihomed Router

Figure 9-7 shows how the same physical topology is applied in the context of ASs and BGP. Washington D.C.
is in AS100 and New York is in AS200. As long as Washington D.C. is the only border router in AS100 running
EBGP, then the AS100 is single-homed. There is only one circuit connected to its upstream provider. AS100
would also be considered a stub AS. In reality, if Washington D.C. in AS100 were a customer of the provider
AS200, then AS200 would most likely assign a private ASN to the customer.

Figure 9-7. Stub/Single-Homed AS

In Figure 9-8 there are two circuits between Washington D.C. and New York. The dual circuits and the fact
that multipath can be run tells us that the topology is multihomed. Again any attempt to take advantage of

www.ebook-converter.com
AS100 for transit would be a waste of time, and in reality AS100 probably would not advertise itself as being
able to reach any prefixes other than those assigned to the AS itself. Nonetheless, if poor policy is used,
suboptimal routing conditions could occur. It is vital to understand your connection points and policy.

Figure 9-8. Stub/Multihomed AS

In Figure 9-9, Washington D.C. in AS100 is connected to New York and Boston in AS200. In this situation,
AS100 is still only using one border router running EBGP; thus, it is still considered a stub AS. However,
having two circuits, it is also considered multihomed due to the multiple routers to which it has connectivity. In
Downloader demo watermarks
this scenario, Washington D.C. would probably receive prefixes for the same networks from both New York
and Boston. Washington D.C. could manipulate the LOCAL_PREF attribute to make more efficient use of both
links. AS200 could also manipulate the MULTI_EXIT_DISC (MED) value of prefixes sent to AS100 in an
attempt to influence how AS100 will send traffic. More likely, AS200 would be a provider and AS100 would
be a customer. AS200 would probably work with AS100 to establish policy that lets both organizations utilize
354
 9. BGP Routing Configuration
the links in the most efficient manner.

Figure 9-9. Stub/Multihomed Dual Routers

Figure 9-10 shows a slightly different environment. Both AS100 and AS200 are connected to each other in Los
Angeles and New York. AS100 is still a stub AS and multihomed with AS200. A common problem would entail
either AS100 or AS200 taking advantage of the other. The New York router in AS100 could send traffic
destined to Los Angeles by using the New York router in AS200. AS100 would essentially be using AS200
resources to traverse the country instead of using its own. Depending on each AS's policy, the New York router
in AS200 could send the traffic right back to AS100, thereby creating a route loop. The advantage to this
scenario, however, is that AS100, as the customer, can advertise certain prefixes to AS200 in an attempt to
influence how traffic is sent into the customer network. Thus, traffic destined to Los Angeles would come from
the Los Angeles router in AS200.

www.ebook-converter.com

Figure 9-10. Stub/Multihomed AS with Load-Sharing and Multipath Configurations

Downloader demo watermarks

In Figure 9-11, Los Angeles and Atlanta in AS100 are connected to Denver in AS300 and Boston in AS400,
respectively. This is a multihomed scenario. There is a potential for AS400 to use AS100 as a transit AS to
AS300. If AS100 does not have arrangements with either AS300 or AS400 to use it as a transit AS, then strict
policy should be implemented to prevent the exploitation of AS100 connection points. It would also be in
AS100's best interest to advertise prefixes in the western region to prefer router Los Angeles and prefixes in the
355
 9. BGP Routing Configuration
eastern region to prefer router Atlanta.

Figure 9-11. Multihomed AS and Transit AS Scenario 1

Figure 9-12 shows a slightly different type of multihomed environment. In this figure, Denver in AS100 is
connected to Los Angeles in AS200 and New York in AS300. Though there is only a single router in AS100,
the same conditions apply as those in Figure 9-11. Proper design would attempt to utilize both links for
resiliency and prefix influence.

www.ebook-converter.com

Figure 9-12. Multihomed AS and Transit AS Scenario 2

Figure 9-13 adds a new twist to the previous two scenarios. Though this scenario is similar to that presented in

Downloader demo watermarks

Figure 9-10, three ASs are being used instead of two. In this situation, AS100 and AS300 both have routers in
Los Angeles, and AS100 and AS400 each have a router in New York. There is a link between AS300 and
AS400, but it is expensive to use it. AS300 or AS400 could take advantage of the cross-country link between
Los Angeles and New York in AS100 by sending their own transit traffic to AS100 to get across the country.

356
 9. BGP Routing Configuration

Figure 9-13. Multihomed AS and Transit AS Scenario 3

Consider the flip side. AS100 could take advantage of the link between AS300 and AS400 to pass nonpriority
traffic cross-country. Ultimately, each AS here has a responsibility to apply policy and announce prefixes
responsibly. It is easy in situations in which this topology can be applied to create suboptimal routing domains
and be taken advantage of by poor prefix advertisement and poor policy implementation.
Ultimately, both the customer and provider are responsible for maintaining the most optimized routing

www.ebook-converter.com
architecture they can. These scenarios have pointed out just a few of the potential cases that can occur,
depending on transit and homing conditions.

Routing
Routing, in general, is the process for selecting a path over which to route traffic. BGP evaluates several
attributes prior to selecting a route to a prefix and installing it into the routing table. You will recall that an IGP
is typically based on either distance vector or link state routing principles. These are used to determine a loop-
free routing topology internal to the AS. BGP, on the other hand, is a path vector protocol and uses a list of
ASNs within the routing information to determine a loop-free path to destination networks.
The next few sections will look at how route-preference and default-route selection criteria play key roles in
how JUNOS decides to select routes. The first subject is the RIB and how it applies to BGP.

RIB

Downloader demo watermarks

RIB stores routing information for incoming route advertisements, locally stored routing information, and
outbound route advertisements. There are three types of RIBs:
1. Adj-RIB-In contains all inbound routes received from other BGP peers. There is an Adj-RIB-In for
each BGP peer. The default behavior of JUNOS is to store learned BGP routes here that do not have

357
 9. BGP Routing Configuration
AS_PATH routing loops. The routes here have not been manipulated by any import policies. These are the
routes on which your BGP import policy would be performed, as would recursive lookups in the routing
table for valid next-hop addresses. See the keep statement in Section 9.4.2 for additional information.
2. Loc-RIB contains routes that have come from the Adj-RIB-In tables and have gone through validation
and policy. These would be considered your inet.0 routing table, which is discussed in Section 9.1.4.2.
3. Adj-RIB-Out contains routes that will be advertised by the local router to its BGP peers. This table is
where routes would be placed after being evaluated by your BGP export policy. Once here, they will be
advertised to the corresponding BGP peer.
Chapter 11 provides in-depth explanation of JUNOS policy.

Routing Tables
JUNOS places all unicast routes in table inet.0. So, the routes that are learned via BGP, which pass through
the import policy and have a valid next-hop, will be placed here. Table 9-1 lists the various predefined routing
tables in JUNOS and their use.
Table 9-1. JUNOS Routing Tables

Table Function
inet.0 Default unicast routing table
Instance-name.inet.0Unicast routing table for a given routing instance
inet.1 Multicast forwarding cache
inet.2 Unicast routes used for multicast reverse path forwarding (RPF) lookup

www.ebook-converter.com
inet.3 MPLS routing table for path information
mpls.0 MPLS routing table for LSP next-hops
BGP route decisions work a bit differently from IGP route decisions. JUNOS will prefer routes in table
inet.3 for next-hop resolution over those listed in table inet.0 when MPLS and traffic engineering are
enabled and in use. Details on inet.3 can be found in Section 12.3.3. In addition to these tables, you have the
ability to create your own tables for customized purposes. You can apply import and export policies to these
tables just as you would to any of the default tables.

Route Preference
JUNOS uses protocol preference to choose which routes will become active in the routing table. This can be
easily manipulated in JUNOS and can be useful in scenarios where it is necessary to prefer routes learned from
one protocol over those learned from another. There is also the ability to use preference in tiebreaking. The
preference statement is used to specify a preference of the protocol in terms of its association with the
other protocols. Thus, you can cause BGP to be preferred over OSPF, for example. Table 9-2 lists the protocols

Downloader demo watermarks

and their default preference. The lower the value associated with the protocol, the more preferred it is to
others. Care should be taken when manipulating these preferences as unintended results may occur, causing
suboptimal routing within your particular routing domain.
Table 9-2. JUNOS Routing Protocol Ranking

358
 9. BGP Routing Configuration
Routing Protocol JUNOS Default Preference Value
Direct 0
Static 5
MPLS (RSVP) 7
MPLS (LDP) 9
OSPF Internal Route 10
IS-IS Level 1 Internal Route15
IS-IS Level 2 Internal Route18
Redirects 30
RIP 100
Point-to-Point Interfaces 110
Generated or Aggregate 130
OSPF AS External Routes 150
IS-IS Level 1 Internal Route160
IS-IS Level 2 Internal Route165
BGP 170

BGP Route Selection

JUNOS typically chooses routes to become active by their preference. When it comes to BGP, there is an even
more defined set of criteria for route selection.
1. For each route available to a given destination in the routing table, JUNOS must select one of those routes
as the active route and install it into the master forwarding table. JUNOS uses a process to select the active

www.ebook-converter.com
route. It chooses first based upon protocol preference, as listed in Table 9-2. For instance, RIP routes
(default preference value of 100) will take preference over OSPF AS external routes (default preference
value of 150), while OSPF internal routes (default preference value of 10) will take preference over RIP
routes. Routes that are rejected and marked (as unusable) are given a preference of –1. These routes will
never be installed as active routes, regardless of their protocol ranking. If the decision-making process
decides to use BGP routes, the following process is followed.
2. As long as BGP can do a recursive lookup and resolve the next-hop for a prefix in the existing routing
table, then the route will be installed in the LOC-In RIB. If there is no valid next-hop in the routing table,
then JUNOS will hide the route. Once routes make it to the LOC-In, JUNOS will continue through the
route-selection process.
3. JUNOS will then select the BGP route with the highest LOCAL_PREF. The higher the value, the more
preferred the route is. LOCAL_PREF is set internally to the AS according to policy. If this is equal, then
JUNOS will move on to the next step.
4. If the routes being compared both contain AS_PATH information, JUNOS will select the route with the

Downloader demo watermarks

shortest AS_PATH list. Confederation sequences are given a path length of 0, where as Confederation sets
and AS_SET are treated has having a path length of 1. This can be seen in Section 10.4.2.
5. The next step in the route-selection process is to evaluate the ORIGIN attribute. Values for ORIGIN rank
as follows:

359
 9. BGP Routing Configuration
1. IGP
2. EGP
3. Incomplete
6. MED value is the next criteria to be compared. The path with the lowest MED value will be chosen. Think of
MED as a metric, which are typically preferred based on the lowest value. This only occurs if prefixes are
learned from the same AS. There is a MED case study to refer to in Section 10.2.4.
7. JUNOS will next choose routes learned via EBGP over IBGP. EBGP is generated externally and is
considered cheaper than internally generated routes. This is commonly referred to as hot potato routing.
8. Next, JUNOS will prefer routes with whose next-hop has the lowest IGP metric to the border router.
9. Routes in table inet.3 will be chosen over routes in inet.0 (MPLS-centric).
10. Routes with a greater number of next-hops will be preferred. This means if prefix 172.16/16 has two
next-hops, and next-hop A has four routes in the IGP, and next-hop B has two routes in the IGP, BGP will
install the route with next-hop A.
11. If route reflectors are used, BGP will choose the route with the shorter CLUSTER_LIST.
12. The route with the lowest RID will be chosen.
13. Routes from the peer with the lowest peer ID will be selected.

www.ebook-converter.com
This process is valid only for BGP route selection. Route selection in JUNOS, in general, encompasses these
criteria, plus more relating to individual IGPs. Policy can also be used to manipulate routes, so you can force
them to pass certain criteria in this selection process. Use caution when doing this, as suboptimal routing may
occur.

Default Routes
A default route will be used if no other more specific route for a given destination exists in the current routing
table. In BGP, this is important for several reasons. If your local AS is not receiving full Internet routes, or does
not need to receive full Internet routes, then you may attempt to send data to a destination that is not listed in
the routing table. You do not want to statically assign this default route unless it is absolutely necessary. The
preferred method is to have the upstream provider announce a default (0.0.0.0/0) route to your BGP
border router. In turn, you want your border router to announce the default into the IGP. In this way, your
entire routing domain should be able to see the default route. If the link for the default should go away, the
default route will go away, and the packet will be dropped, as it should be.
The benefit of doing this over static definition is obvious. If static definition were used, the default route could
Downloader demo watermarks
point to a destination that may not actually be reachable or that could go away due to a change. The dynamic
method of introducing the default route is preferred because it will go away only when it is not physically
accessible.

The Finite State Machine

360
 9. BGP Routing Configuration
The operational functions of BGP are defined in RFC 1771. These definitions should be complied with for any
implementation to be successful. Failure to do so could give rise to serious concerns about the integrity of the
information provided by the protocol and potentially create a chaotic state of routing.
It is necessary to understand that BGP operates as a finite state machine (FSM). This means, that at all times of
operation, there is a defined state of the process. This process cannot move on to the next state or perform
other functions without first meeting a predetermined set of criteria. Once these criteria are met, based on the
conclusion, the process will proceed to another predefined state, and go through the process of meeting certain
criteria, before proceeding. And on and on it goes. This also implies the ability to handle error conditions.

Transport
BGP uses TCP (port 179) as the underlying transport protocol. This provides the reliable transport function,
error correction, and retransmission of the higher-level data, if necessary. TCP relies on IP as the network layer
protocol. So, if there is IP connectivity to a destination, the TCP session should remain active. This will become
relevant during our discussion on peering and how logical peering works.

Events
In BGP there are 13 different events that cause the FSM to change states. Since an FSM is based on a
calculated response to a predetermined number of possible events, the state change is predictable. However,
the state-event correlation relies not only on the event, but on the current state of the FSM. The following
events allow the FSM state to change:
BGP start

www.ebook-converter.com
BGP stop
BGP transport connection Open
BGP transport connection Closed
BGP transport connection open Failed
BGP transport fatal error
Connect-retry timer expired
Hold timer expired
Keepalive timer expired

Downloader demo watermarks

Receive OPEN message
Receive KEEPALIVE message
Receive UPDATE message

361
 9. BGP Routing Configuration
Receive NOTIFICATION message
The next section will discuss the various connection states and how the above listed events determine state
change.

Connection States
There are six different states to the FSM as documented in RFC 1771. Each state represents where the BGP
process is in terms of operation, but also predicates what type of events can occur to cause the state to change.

Idle
The initial state of the BGP process is Idle. In this state, the local system is essentially waiting for some start
event to get the process moving. The most common start event is nothing more than the network administrator
configuring the local system to peer with a remote system.
Depending on which configuration parameters are used, the local system will either wait for incoming TCP
connection on port 179 and subsequent OPEN messages, or it will attempt to establish a TCP connection and
begin sending OPEN messages. In JUNOS, if the passive parameter is used, the local system will listen for an
incoming TCP connection on TCP port 179, then listen for incoming OPEN messages. If the passive parameter
is not used, the local system will start a connect-retry timer and attempt to establish a TCP connection on port
179 to the remote system. BGP is typically configured on one router and then on the other, so the first one is
usually trying to establish a connection prior to the remote system being configured. Regardless, if both systems
attempt to create a peering session at the same time, the potential for two peering sessions between the same
neighbors exists. RFC 1771 outlines a mechanism called connection-collision detection, which will prevent

www.ebook-converter.com
multiple sessions between the same neighbors from being established. Once the TCP connection attempt is
started, the FSM will transition to the Connect state.

Connect
This state occurs when the local system sees a TCP connection initiated on port 179. This state is key to the
overall operation of BGP. If the local system cannot transition out of the Connect state, there is a potential
problem with establishing the TCP connection. This can be a useful tip in troubleshooting BGP peering
problems.
When the TCP connection is established, the local system will reset the connect-retry timer it started earlier
and will send an OPEN message to the remote system. When the local system sends the first OPEN message, the
FSM transitions to the OpenSent state.

Active
If the router is unable to create the TCP connection, the FSM will transition to the Active state. In this state,
Downloader demo watermarks
the local system will still try to create the TCP connection. If it is able to complete the connection, the local
system will send out the OPEN message to the potential peer, and the FSM will transition to the OpenSent
state. In the Active state, the local system is capable of receiving a connection attempt from a potential
neighbor.

362
 9. BGP Routing Configuration
OpenSent
When the local system sends out its OPEN message, the FSM will transition to the OpenSent state. When this
occurs, the local system will listen for an OPEN message from the remote system. When the local system
receives an OPEN message from the remote system, it sends out a KEEPALIVE message to the remote, and the
FSM transitions to the OpenConfirm state.
When the OPEN message is received from the remote system, the local system is able to determine certain
characteristics about the session. If the ASN is different than the local system, the session will be external; if it
is the same, then it will be internal.

OpenConfirm
When the FSM in the local system reaches this state, it waits for the KEEPALIVE message to be sent from the
remote system. When the local system receives the KEEPALIVE message from the remote system, the FSM
will then change to the Established state. If the hold timers expire here, the local system will send a
NOTIFICATION message to the remote system, and the FSM will change to the Idle state.

Established
When the FSM for the peering session transitions to the Established state, the peers are now ready to begin
sending UPDATE messages to exchange reachability information.
When a BGP session is truly UP and the FSM is in the Established state, the following can be assumed:
The BGP process has been started.

www.ebook-converter.com
A reliable transport session has been created.
OPEN messages have been exchanged successfully, and session parameters have been negotiated.
KEEPALIVE messages have been received successfully, and no error condition exists.

Message Types and Formats

The importance of messages was shown in the previous section on FSM events and states. If you refer to the
list of events, you will see the last four events involve the OPEN, UPDATE, NOTIFICATION, and KEEPALIVE
messages. Each message has a distinct purpose and provides details necessary for establishing, maintaining, and
discontinuing BGP peer sessions between local and remote systems.
The maximum message size supported in BGP is 4,096 bytes, and the minimum message size is 19 bytes. The
minimum size message contains only the BGP header without any trailing data and is used as the KEEPALIVE

Downloader demo watermarks

message. Each message header has a fixed length and does not have to contain data in each bit. There are three
parts to a message header (see Figure 9-14):
1. Marker (16 bytes)—. contains all 1s for the OPEN message (also used when authentication is configured
for BGP peering session)

363
 9. BGP Routing Configuration
2. Length (2 bytes)—. indicates the total length of the BGP message to a receiving system
3. Type (1 byte)—. indicates the message type
OPEN—. 0001 (1)
UPDATE—. 0010 (2)
NOTIFICATION—. 0011 (3)
KEEPALIVE—. 0100 (4)

Figure 9-14. BGP Message Header

OPEN Message
The OPEN message is sent by the local system once the TCP connection between the two potential peers has
been created. Figure 9-15 illustrates the following OPEN message fields:
Version (1 byte)—. This indicates the version of BGP used by the local system (in the case of Juniper
Networks, it is BGP4).

www.ebook-converter.com
My AS (2 bytes)—. This indicates the local system's ASN.
Hold time (2 bytes)—. This indicates the configured hold time of the local system. The hold time will be
negotiated between local and remote systems if they are not equal. A value of 0 indicates no use of the
hold timer or keepalive timer.
BGP identifier (4 bytes)—. This is the RID field. In JUNOS, the use of the router-id statement will set
this value. Otherwise, the value will be taken from the lowest configured IP address on the router.
Optional parameters length (1 byte)—. This indicates the length of the optional parameters field. When
this field is set to 0, there will not be any optional parameters in the packet.
Optional parameters (variable)—. This is a variable-length field comprising the following parameters (see
Figure 9-16):
Parameter type (1 byte)—. This indicates the type of parameter that will be used. RFC 1771 only
defines one optional parameter, authentication information (parameter type 1). RFC 2842 makes a

Downloader demo watermarks

provision to negotiate a list of capabilities. Without this, when a BGP implementation would see a
parameter type that it did not recognize, it would cause an error and close the peering session.
Parameter length (1 byte)—. This indicates the length of the variable-length parameter value field,
listed next.

364
 9. BGP Routing Configuration
Parameter value (variable)—. This is assigned based upon the parameter type field.

Figure 9-16. OPEN Message Parameters

Figure 9-15. OPEN Message Format

UPDATE Message
BGP uses UPDATE messages to exchange all routing information related to BGP. A single message can contain
both NLRI with attributes and a list of withdrawn routes. If the attributes are equal, multiple prefixes can be
sent in a single message. This functionality provides an efficient method of information exchange by combining
multiple functions into a single message.
The UPDATE message can be thought of as having three distinct categories:
1. Unfeasible routes (withdrawn routes that no longer exist)
2. NLRI (prefix and mask, such as 192.168.0.0/16)

www.ebook-converter.com
3. Path attributes (such as MED or AS_PATH)
Unlike some IGPs, where route information is used to construct a topology (usually with the local system as
root of that tree), BGP uses a list of ASs that the NLRI has passed through. This list is built on the concept of
creating a loop-free path to the destination prefix.
Figure 9-17 illustrates the format of the UPDATE message. The BGP UPDATE message fields are as follows:
Unfeasible routes length (2 bytes)—. This indicates the length of the withdrawn routes field. A value of 0
tells the receiving system that no withdrawn routes are listed in this UPDATE message.
Withdrawn routes (variable)—. This consists of IP prefixes to be removed or withdrawn from the routing
table. Each prefix is actually broken down to two parts, prefix length and prefix (see Figure 9-18). The
length in this case is not related to the actual physical space of the prefix field, but rather to the subnet
mask in terms of bits:

Downloader demo watermarks

Prefix length (16)—. refers to a mask of 255.255.0.0
Prefix (10.5.0.0)

365
 9. BGP Routing Configuration

Figure 9-18. UPDATE—IP Prefix and Prefix Length Fields

Figure 9-17. UPDATE Message

The above example refers to 10.5.0.0/16.

There are two important bits of information regarding the withdrawn routes field. First, the prefix length and
value can be set to 0, which would withdraw all routes learned from the advertising neighbor. Second,
regardless of the length of the actual prefix field, RFC 1771 calls for it to add trailing bits to keep the length of
the field equal to the next highest byte count. These trailing bits are insignificant as they are only used for
padding.
Figure 9-19 illustrates the attribute encoding of the UPDATE message.
Total path attribute length (2 bytes)—. This gives the length of the variable path attribute field. It is
necessary, and given a value of 0 would indicate that NLRI would not be present in the UPDATE message.
Path attribute—. This comprises two parts: attribute type (2 bytes) and attribute flags (1 byte).

www.ebook-converter.com
The first four high-order bits determine the category of the attribute.

Figure 9-19. UPDATE—Attribute Encoding

Attributes are used to provide specific information regarding the characteristic of a particular prefix being
advertised. Each of these attributes and their meanings are described in Section 9.2.5. However, for now it is
important to understand that BGP interprets and advertises attributes based upon four distinct categories as
defined in RFC 1771 and shown in Figure 9-20. The first high-order bit is representative of either a well-known
or optional attribute (0 = well known, 1 = optional). The second high-order bit is representative of either
transitive or nontransitive (0 = nontransitive, 1 = transitive). For well-known attributes, the bit must be set to 1

Downloader demo watermarks

for transitive. The third high-order bit is representative of the partial bit. This bit must be set to 0 for well-
known and optional nontransitive attributes. The fourth high-order bit is representative of the extended length
bit. If this bit is set to 1, then the extended length may be used, but only if the length of the attribute is greater
then 255 bytes. The four low-order bits are not currently used in BGP:
Attribute type code (1 byte)
366
 9. BGP Routing Configuration
Attribute length—. length of the attribute field
Attribute value—. actual value of the attribute

Figure 9-20. UPDATE—Attribute Type Field

NOTIFICATION Message
Any BGP-speaking router will send a NOTIFICATION message whenever an error condition exists. When this
message is sent, the sending router closes the BGP session and transitions to the Idle state. The notification
message consist of three fields (see Figure 9-21):
1. Data (variable)—. provides additional information on the error (e.g., incorrect RID information received
for a session would cause an error condition. This piece of data could be placed here).
2. Error code (1 byte)—. see Table 9-3 for values.
3. Error subcode (1 byte)—. see Table 9-3 for values.

www.ebook-converter.com
Figure 9-21. NOTIFICATION Message Format
The error codes and subcodes indicate the major and minor reasons for which the error was detected. The
various error codes and subcodes are essential to the control of the BGP process over the session. If this
particular information was not evaluated and the error codes were not available, there would be devastating
effects on the integrity of the route information passed through ASs and the Internet. Table 9-3 lists these error
codes. The numbers following each code indicate the decimal equivalent.
Table 9-3. NOTIFICATION Message Error Codes

Message Header Error (1) (Error Code)

Connection Not Synchronized (1) (Error Subcode)
Bad Message Length (2) (Error Subcode)
Bad Message Type (3) (Error Subcode)

Downloader demo watermarks

OPEN Message Error (2) (Error Code)
Unsupported Version Number (1) (Error Subcode)
Bad Peer AS (2)(Error Subcode)
Bad BGP Identifier (3) (Error Subcode)
Unsupported Optional
Authentication Failure Parameter (4) (Error Subcode)
(5) (Error Subcode)
367
Authentication Failure (5) (Error Subcode) 9. BGP Routing Configuration
Unacceptable Hold Time (6) (Error Subcode)
UPDATE Message Error (3) (Error Code)
Malformed Attribute List (1) (Error Subcode)
Unrecognized Well-known Attribute (2) (Error Subcode)
Missing Well-know Attribute (3) (Error Subcode)
Attribute Flags Error (4) (Error Subcode)
Attribute Length Error (5) (Error Subcode)
Invalid Origin Attribute (6) (Error Subcode)
AS Routing Loop (7) (Error Subcode)
Invalid NEXT_HOP Attribute (8) (Error Subcode)
Optional Attribute Error (9) (Error Subcode)
Invalid Network Field (10) (Error Subcode)
Malformed AS_PATH (11) (Error Subcode)
Hold Timer Expired (4) (Error Code)
Finite State Machine Error (5) (Error Code)
Cease (6) (Error Code)

KEEPALIVE Message
KEEPALIVE messages are exchanged to let each peering neighbor know that the other is there (see Figure 9-
22). Two other elements are used: the hold timer and the KEEPALIVE messages. These messages cannot be
any more frequent than one per second. When the BGP session is first negotiated, the HoldTime is agreed
upon. If the agreed upon HoldTime is set to 0, then no KEEPALIVE messages will be sent. As noted
previously, the KEEPALIVE messages consist only of the BGP header.

www.ebook-converter.com
Figure 9-22. KEEPALIVE Message Format

Attributes
This section will discuss the attributes associated with BGP and what each means. Attributes are passed in
UPDATE messages. There are four categories of BGP path attributes:
1. Well-known mandatory—. must accompany each advertisement of the prefix
Well-known discretionary—. must be recognized by the BGP implementation, but it is at the discretion of
Downloader demo watermarks
2.
the local system as to whether or not the attribute will be sent in any UPDATE messages
3. Optional transitive—. does not need to be known by the BGP implementation, but it is recommended, due
to the attribute's transitive nature, for the local system to pass the attribute when announcing the prefix to
other systems
368
 9. BGP Routing Configuration
4. Optional nontransitive—. does not need to be known by the BGP implementation, but, due to the nature
of the attribute, it is recommended that it not be passed to other peering neighbors via the UPDATE
message
Table 9-4 lists the ten most common attributes used in BGP by category name and type code. The type code is
the decimal value that is used in the UPDATE message to specify the type of attribute being passed.
Table 9-4. BGP Path Attributes
Attribute Category Type Code
ORIGIN Well-known mandatory 1
AS_PATH Well-known mandatory 2
NEXT_HOP Well-known mandatory 3
MULTI_EXIT_DISC Optional transitive 4
LOCAL_PREF Well-known discretionary5
ATOMIC_AGGREGATEWell-known discretionary6
AGGREGATOR Optional transitive 7
COMMUNITY Optional transitive 8
ORIGINATOR ID Optional nontransitive 9
CLUSTER_LIST Optional nontransitive 10

ORIGIN
This attribute gives an indication of how this particular prefix was learned. The following possible values can
be used:

www.ebook-converter.com
0 (IGP)—learned from the IGP in the originating AS
1 (EGP)—learned from the EGP in the originating AS
2 (Incomplete)—origin of this prefix cannot be determined
By default, JUNOS uses the ORIGIN code value 0, whether or not the route was learned from the IGP,
statically defined, or part of an aggregate route.

AS_PATH
The AS_PATH attribute lists ASs for which a prefix has been announced. This attribute serves two functions:
routing loop avoidance and path selection. If the receiving AS sees its own ASN in the AS_PATH list, it will
ignore that announcement.

Downloader demo watermarks

When a prefix is announced, the AS_PATH only lists the AS that announced the prefix. A single AS may have
10 routers or 100. So, the AS_PATH provides no additional granularity into how the packet would travel to a
destination within a given AS.
The AS_PATH is set using the type field. If the type field has a value of 1 (AS_SET), then the resulting list is
an unordered set of ASs. When an AS_SET is included, if the type value is 2 (AS_SEQUENCE), then the list
369
 9. BGP Routing Configuration
that results is an ordered set of ASs. This means that when the local system readvertises the prefix, it will
prepend the AS_SEQUENCE with the local system's ASN. Prepending always occurs in the left-most bits of the
field.
If the prefix originates in the local AS, then the border router will add the local AS to the prefix and send it to
the external neighbor. If the prefix is advertised internally, then no prepending is necessary. Remember, the
AS_PATH is the listing of ASs that have ANNOUNCED the prefix, ANNOUNCED meaning advertising to other
external neighboring ASs.

NEXT_HOP
This attribute is vital in the route-selection process. In short, the NEXT_HOP attribute indicates the IP address
of the border router that can be used to reach a given destination, not the next-hop as in interface or gateway to
the next Layer 3 device. The show route <prefix> detail or show route <prefix>
extensive commands can be used to see both physical next-hops and protocol or border router next-hops.
Understanding NEXT_HOP and how it is used is essential to understanding BGP route selection. A case study in
Sections 10.2.2 and 10.2.3 covers NEXT_HOP.

MED
MED is a metric specified by an announcing external neighbor to identify the ingress point to use in the
announcing AS for a given prefix. This attribute is used by the announcing system to influence the local
system's decision process. When it is received, it can be propagated via IBGP, but does not get propagated
when the local AS advertises the route to another external AS. A case study in Section 10.2.4 can be
referenced for more information.

www.ebook-converter.com
LOCAL_PREF
LOCAL_PREF is used by IBGP to influence internal routers to use a particular border router to reach a given
prefix. The higher the value, the better the degree of preference. This means that if border router A advertises
prefix 10.10.0.0/16 with a LOCAL_PREF of 100, and border router B advertises 10.10.0.0/16 with a
LOCAL_PREF of 150, the internal routers will choose to send packets via border router B.

ATOMIC_AGGREGATE
Aggregation is a method by which the local system advertises a route representative of several more specific
routes that it knows about. When this occurs, there is a potential loss of information relating to the more
specific prefixes, such as AS_PATH. When this occurs, the local system will attach the ATOMIC_AGGREGATE
attribute to the prefix when advertising it. This is important for the receiving system of the route. If a local
system receives a prefix with the ATOMIC_AGGREGATE attribute set and does have a more specific
route, it will not advertise the more specific route. With this being said, it can be assumed in some cases that
routes with the ATOMIC_AGGREGATE attribute included will traverse ASs that may not be in the AS_PATH
Downloader demo watermarks
list. Aggregation can naturally cause loss of path information, hence the need to signal other systems that this
has occurred.

AGGREGATOR

370
 9. BGP Routing Configuration
If a local system performs aggregation on a series of routes, it will include in the aggregated prefix
advertisement the local system ASN and local system IP address that performed the aggregation.

COMMUNITY
Communities and policy go hand in hand with BGP. You can assign several prefixes the same values by
including them in a particular community. Associated with this attribute are three well-known communities, as
defined in RFC 1997:
1. NO_EXPORT (0xFFFFFF01)—. Routes with this attribute value must not be advertised outside the AS
boundary.
2. NO_ADVERTISE (0xFFFFFF02)—. When this attribute is set, the local system does not advertise this
route to other BGP neighbors.
3. NO_EXPORT_SUBCONFED (0xFFFFFF03)—. Routes with this attribute set must not be advertised
outside the local AS to external peers. In confederation scenarios, a confederation boundary router will not
advertise the route to other external routers, even in the same parent AS.
Communities are essential in service provider networks. They can play a vital role in route coloring and further
enhancing the routing domain's ability to maintain routing-policy control. Section 11.7 provides coverage on
the use of communities.

ORIGINATOR_ID
This attribute is defined in RFC 1966. Simply put, the ORIGINATOR_ID is the RID of the router that

www.ebook-converter.com
originated the route into the AS. Route reflectors will not send a route learned from an originator back to that
originator. The route-reflector server will set this attribute when advertising the prefix to internal neighbors.
This attribute will not be sent to external neighbors.

CLUSTER_LIST
This is an optional nontransitive attribute and is used by BGP in route-reflector scenarios as well. The route-
reflector server sets the CLUSTER_LIST value. Any routes received with this attribute set to the local
CLUSTER_ID will be ignored. This, too, is part of the loop avoidance scheme in BGP route reflection and is
especially useful when implementing multiple route-reflector clusters within a single AS.

JUNOS BGP Minimum Configuration

Previous sections of this chapter have discussed the fundamentals of BGP. This section will now take a look at
basic configuration for both internal and external peering sessions.

Downloader demo watermarks

Minimum Configuration Parameters
Activation of BGP in JUNOS is relatively straightforward. The following example shows the combined
parameters necessary for both IBGP and EBGP peering sessions. These are listed together so you can become
familiar with the various parameters that are necessary for both types of sessions.
371
 9. BGP Routing Configuration
routing-options {
autonomous-system autonomous-system;
}
protocols {
bgp {
group group-name {
type type;
neighbor address;
local-address address;
peer-as autonomous-system;
}
}
}
}
The next two sections will show the minimum requirements for both internal and external peering sessions.

IBGP Minimum Configuration

The following example lists the minimum configuration parameters for an IBGP peering session under the
[edit routing-options] hierarchy the ASN of the local system and under the [edit protocols
bgp] hierarchy, group, type, and neighbor.
routing-options {
autonomous-system autonomous-system;
}

www.ebook-converter.com
protocols {
bgp {
group group-name {
type type;
neighbor address;
}
}
}

IBGP Between Physical Interfaces

We will now establish a peering session between Los Angeles and San Francisco. Even though a minimum
configuration is shown, two scenarios will actually be covered: simple peering between physical interfaces (see
Figure 9-23) and peering between loopback interfaces. The latter method is more common, but understanding
both is necessary.

Downloader demo watermarks

372
 9. BGP Routing Configuration

Figure 9-23. IBGP Configuration—Physical Interface

The configuration for router Los Angeles is shown below. The ASN for Los Angeles is 100; the group name for
the peering session is IBGP. The type of session, of course, is internal, and the neighbor that we are peering
with is 10.0.23.2. Remember, for now we are peering only through the physical interfaces.
routing-options {
autonomous-system 100;
}
protocols {
bgp {
group IBGP {

www.ebook-converter.com
type internal;
neighbor 10.0.23.2;
}
}
}
The above configuration can be created with the following two commands while in [edit] mode.
[edit]
lab@LosAngeles# set routing-options autonomous-system 100
[edit]
lab@LosAngeles# set protocols bgp group IBGP type internal neighbor 10.0.23.2
The configuration for San Francisco is shown next. The ASN for San Francisco is 100; the group name for the
peering session is IBGP. The type of session, of course, is internal, and the neighbor that we are peering with is
10.0.23.1.
routing-options {
Downloader demo watermarks
}
autonomous-system 100;

protocols {
bgp {
group IBGP {
373
 9. BGP Routing Configuration
type internal;
neighbor 10.0.23.1;
}
}
}
Now, because we are only peering between physical interface addresses, we are done. We can issue several
commands to check the state of the peering session. We choose to use the show bgp neighbor command.
When we issue this command on Los Angeles, we see the output as shown below. The first highlighted item
shows the peer address and port number, peer AS100, local address and port, and local AS100. The type of
session is internal, and it is in the Established state, which indicates that the peering session is up.
lab@LosAngeles> show bgp neighbor 10.0.23.2
Peer: 10.0.23.2+179 AS100 Local: 10.0.23.1+1037 AS100
Type: Internal State: Established Flags: <>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: Open Message Error
Options: <Preference HoldTime Refresh>
Holdtime: 90 Preference: 170
Number of flaps: 0
Error: 'Open Message Error' Sent: 1 Recv: 0
Peer ID: 192.168.28.1 Local ID: 192.168.20.1 Active Holdtime: 90
Keepalive Interval: 30
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Table inet.0 Bit: 10000

www.ebook-converter.com
Send state: in sync
Active prefixes: 0
Received prefixes: 0
Suppressed due to damping: 0
Last traffic (seconds): Received 1 Sent 1 Checked 1
Input messages: Total 8 Updates 0 Refreshes 0 Octets 152
Output messages: Total 12 Updates 0 Refreshes 0 Octets 282
Output Queue[0]: 0

IBGP Between Loopback Interfaces

Now that we have seen how to configure IBGP between physical interface addresses, let's take a look at
configuring an IBGP session between loopback interface addresses (see Figure 9-24). We know from our
earlier discussion of IBGP that it is preferable to use the loopback interface address for IBGP peering. This
allows our peering session to remain up as long as a single physical interface to our router is up.

Downloader demo watermarks

374
 9. BGP Routing Configuration

Figure 9-24. IBGP Configuration—Logical Interface

First, we have the required parameters necessary for IBGP peering between loopback interfaces. The only real
change here is the addition of the local-address statement. This allows us to peer between loopback
addresses because, instead of using our physical interface address to establish the peering session, we will use
our own loopback address. Make sure when configuring for this type of peering that you do the following two
things: set the neighbor address on each router to the loopback address of the router you wish to peer with, and
set the local-address statement to the local system's loopback interface IP address. If either of these is left
out, the peering session will not become active. In addition, there must be either an IGP running on both
routers with the loopback interfaces being advertised, or static routes set up to the neighbor router for the
loopback address. The local systems must know how to route to the loopback address to establish the peering
session. If none of these routing mechanisms is in place, the IBGP session will not be established.

www.ebook-converter.com
routing-options {
autonomous-system autonomous-system;
}
protocols {
bgp {
group group-name {
type type;
neighbor address;
local-address address;
}
}
}
}
The configuration for router Los Angeles is shown below. The ASN for Los Angeles is 100; the group name for
the peering session is IBGP. The type of session, of course, is internal, and the neighbor that we are peering
Downloader demo watermarks
with is 192.168.28.1, which we know is the loopback interface address of the router we will peer with. In
addition, we now include the local-address statement, which, in this case, is 192.168.20.1. We now
have a configuration for IBGP to peer with our neighbor's loopback interface.
routing-options {
375
 9. BGP Routing Configuration
autonomous-system 100;
}
protocols {
bgp {
group IBGP {
type internal;
neighbor 192.168.28.1;
local-address 192.168.20.1;
}
}
}
}
We choose to use the show bgp neighbor command. When we issue this command on Los Angeles, we
see the output listed below. The first highlighted item shows the peer address and port number, peer AS100,
local address and port, and local AS100. The type of session is internal, and the state is established, which
indicates the peering session is up. In this example, you will also see the Local Address field used. In this
case, it shows our own loopback interface address.
lab@LosAngeles> show bgp neighbor 192.168.28.1
Peer: 192.168.28.1+179 AS100 Local: 192.168.20.1+1038 AS100
Type: Internal State: Established Flags: <>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options: <Preference LocalAddress HoldTime Refresh>
Local Address: 192.168.20.1 Holdtime: 90 Preference: 170
Number of flaps: 0

www.ebook-converter.com
Peer ID: 192.168.28.1
Keepalive Interval: 30
Local ID: 192.168.20.1

NLRI advertised by peer: inet-unicast

Active Holdtime: 90

NLRI for this session: inet-unicast

Peer supports Refresh capability (2)
Table inet.0 Bit: 10000
Send state: in sync
Active prefixes: 0
Received prefixes: 0
Suppressed due to damping: 0
Last traffic (seconds): Received 18 Sent 18 Checked 18
Input messages: Total 2 Updates 0 Refreshes 0 Octets 38
Output messages: Total 4 Updates 0 Refreshes 0 Octets 102
Output Queue[0]: 0
Now that we have seen two methods of creating our IBGP sessions, we will move on to creating EBGP session.

Downloader demo watermarks

EBGP Minimum Configuration
The following example lists the minimum configuration parameters for an EBGP peering session. Under the
[edit routing-options] hierarchy the ASN of the local system is specified, and under the [edit

376
 9. BGP Routing Configuration
protocols bgp] hierarchy, group, type, neighbor, and peer-as are specified. Though local-address is
not necessary for a typical directly connected interface peering session, you will see how the local-
address and multihop statement can be used in the second EBGP configuration scenario.
routing-options {
autonomous-system autonomous-system;
}
protocols {
bgp {
group group-name {
type type;
neighbor address;
peer-as autonomous-system;
}
}
}
}

EBGP Between Physical Interfaces

We will now establish a peering session between Los Angeles and San Francisco. No topology diagram is
necessary as there are only two routers involved. Even though there are several methods by which an EBGP
peering session can be established, we will only be looking at the directly connected scenario (see Figure 9-24).
Multihop EBGP peering is addressed separately in Sections 9.2.5.3,9.4.2.21 and 10.3.3.
The configuration for router Los Angeles is shown next as well as the topology in Figure 9-25. The ASN for

www.ebook-converter.com
Los Angeles is 100; the group name for the peering session is EBGP. The type of session, of course, is external,
and the neighbor that we are peering with is 10.0.23.2. Remember, for now we are peering only through the
physical interfaces.

Figure 9-25. EBGP Configuration—Physical Interface

routing-options {
autonomous-system 100;

Downloader demo watermarks

}
protocols {
bgp {
group EBGP {
type external;
neighbor 10.0.23.2;
377
 9. BGP Routing Configuration
peer-AS200;
}
}
}
}
The configuration for San Francisco is shown next. The ASN for San Francisco is 200; the group name for the
peering sessions EBGP. The type of session, of course, is external, and the neighbor that we are peering with is
10.0.23.1.
routing-options {
autonomous-system 200;
}
protocols {
bgp {
group EBGP {
type external;
neighbor 10.0.23.1;
peer-AS100;
}
}
}
}
Now, since we are only peering between physical interface addresses, we are done. We can issue several
commands to check the state of the peering session. We choose the show bgp neighbor command. When
we issue this command on Los Angeles, we see the output listed below. The first highlighted item shows the

www.ebook-converter.com
peer address and port number: peer AS200, local address and port, and local AS100. The type of session is
external, and the state is Established, which indicates the peering session is up.
lab@LosAngeles> show bgp neighbor 10.0.23.2
Peer: 10.0.23.2+179 AS200 Local: 10.0.23.1+1040 AS100
Type: External State: Established Flags: <>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: Open Message Error
Options: <Preference HoldTime PeerAS Refresh>
Holdtime: 90 Preference: 170
Number of flaps: 0
Error: 'Open Message Error' Sent: 1 Recv: 0
Peer ID: 192.168.28.1 Local ID: 192.168.20.1 Active Holdtime: 90
Keepalive Interval: 30
Local Interface: fe-0/1/0.0
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Downloader demo watermarks
Peer supports Refresh capability (2)
Table inet.0 Bit: 10000
Send state: in sync
Active prefixes: 0
Received prefixes: 0

378
 9. BGP Routing Configuration
Suppressed due to damping: 0
Last traffic (seconds): Received 2 Sent 2 Checked 2
Input messages: Total 3 Updates 0 Refreshes 0 Octets 57
Output messages: Total 7 Updates 0 Refreshes 0 Octets 187
Output Queue[0]: 0

RID
BGP uses an RID to identify the system from which an advertisement comes. In the case of JUNOS, one either
has to be defined in the [edit routing-options] hierarchy or taken from the first interface with an IP
address assigned, typically the loopback interface. The simplest way to figure out what your RID is by
assigning one. The following example shows the set command to use while in [edit] mode.
set routing-options router-id 100.100.100.100

routing-options {
router-id 100.100.100.100;
}

Configuration Parameters
Before we get into configuration scenarios, it is important to understand what configurable options you will
have under the JUNOS command hierarchy. Due to the infinite number of configuration scenarios for BGP,
only the most common configuration parameters are listed here. BGP in JUNOS can be configured under
multiple hierarchies. The different hierarchies are listed in Table 9-5. However, for clarity, we will provide
configuration examples using the basic [edit protocols bgp] hierarchy, but you should understand that

www.ebook-converter.com
the same configuration parameters are valid for all the various listed hierarchies.
Table 9-5. BGP Protocol Hierarchy Levels and Command Syntaxes
Level Number Hierarchy
[edit protocols bgp]
1 set protocols bgp ...
2 [edit protocols bgp group group-name]
set protocols bgp group group-name ...
[edit protocols bgp group group-name neighbor address]
3 set protocols bgp group group-name neighbor
address ...
[edit routing-instances routing-instance-name
4 protocols bgp]
set routing-instances routing-instance-name
protocols bgp ...
5 [edit routing-instances routing-instance-name
protocols bgp
group group-name]
set routing-instances routing-instance-name
protocols bgp
group group-name ...
[edit routing-instances routing-instance-name
6
Downloader demo watermarks
protocols bgp
group group-name neighbor address]
set routing-instances routing-instance-name
protocols bgp
group group-name neighbor address ...

Configuration Hierarchy
379
 9. BGP Routing Configuration
As has been mentioned earlier, there are several instances in which some protocol-independent routing
properties must be configured to use certain features. These can be found under the [routing-options]
and [policy-options] hierarchy. Due to the scope of this chapter, we will not deviate outside the
properties that directly relate to the BGP protocol.
Under the [edit protocols bgp] hierarchy, there are three distinct levels of configuration:
1. Global
2. Group
3. Peer
JUNOS uses a very hierarchical configuration process. Each hierarchy takes precedence over the previous.
This means that parameters configured at the group level will take precedence over anything configured at the
global level. This approach provides a very structured configuration file that is easy to read. Developing a
configuration policy or guideline will help to ensure that configurations are implemented in a specific manner
and to eliminate the use of several different styles of configuration across the network.
As mentioned before, there are several ways to configure BGP in JUNOS and achieve the same desired end
result. For ease of explanation and clarity, we will list each configuration statement, its syntax, the hierarchy
level at which the statement can be configured (see Table 9-5 for a list of hierarchy names and their levels).

Configuration Statements
The following statements are listed to provide insight into the BGP options configurable in JUNOS BGP.

www.ebook-converter.com
Although there are several configuration scenarios and multiple ways to accomplish tasks like peering, this
should provide adequate explanation to help you understand the basics and get BGP up and running.

advertise-inactive
JUNOS learns routes from various sources. Owing to policy and configuration, some of these routes will not be
chosen as the preferred route and thus will not be marked active. The routes remain in the routing table, while
the active routes are sent to the master forwarding table in the PFE. In BGP you can advertise these inactive
routes, thereby transporting them to another router. That router, owing to its policy, may or may not utilize the
routes received. Regardless, you can advertise the inactive routes in the routing table. Table 9-6 shows the
advertise-inactive configuration statement's syntax and the levels at which it can be configured.
Table 9-6. advertise-inactive Configuration Statement

Syntaxadvertise-inactive;
Level 1, 2, 3, 4, 5, 6

Downloader demo watermarks

allow
In BGP we typically specify the neighbor we want to peer with in our configuration. This is typically done
through the use of the neighbor statement, followed by the explicit IP address of the neighbor with which we
want to peer. In JUNOS we can use the allow statement to identify the peer in the form of a prefix. This
380
 9. BGP Routing Configuration
feature can be used when peering with other routers that fall within a range that can be defined with a prefix
and mask. The use of 0.0.0.0/0 is an implicit ALL. This should be used with caution as the JUNOS BGP
implementation does not allow the use of authentication when the allow statement is used. Table 9-7 shows
the allow configuration statement's syntax and the levels at which it can be configured.
Table 9-7. allow Configuration Statement

Syntax allow [network/mask-length]

allow 192.168.250/24
Level 2, 5

as-override
The default behavior of BGP is to reject routes that have the local ASN in the AS_PATH for the advertised
route to avoid routing loops. The as-override parameter allows JUNOS to override this characteristic and
accept the route advertisement. Great caution should be used when implementing this parameter, as routing
loops and suboptimal routing conditions can occur. Table 9-8 shows the as-override configuration
statement's syntax and the levels at which it can be configured.
Table 9-8. as-override Configuration Statement

Syntaxas-override;
Level 2, 3, 5, 6

authentication-key
BGP4 supports authentication. This authentication is used to send an encrypted checksum between two

www.ebook-converter.com
routers, using a predetermined authentication key. When entering the key, you can use up to 255 characters of
plain text. However, when displayed, the encrypted version of the key is shown. If there is a need to use spaces
as part of the key, make sure the key is enclosed in quotation marks. Although the use of authentication can
ensure peering with authorized peers, the implementation will not work with the allow statement. Table 9-9
shows the authentication-key configuration statement's syntax and the levels at which it can be
configured.
Table 9-9. authentication-key Configuration Statement

Syntax authentication-key key;

authentication-key secure;
authentication-key "this is a secure key";
Level 1, 2, 3, 4, 5, 6

bgp
BGP4 is the only EGP available in Juniper Networks routers. When configuring BGP, you cannot just issue the

Downloader demo watermarks

set protocols bgp statement. It must be followed by additional parameters. Table 9-10 shows the bgp
configuration statement's syntax and the levels at which it can be configured.
Table 9-10. bgp Configuration Statement

Syntaxbgp { … }
Level 1, 4 381
 9. BGP Routing Configuration
Level 1, 4

cluster
For scaling purposes, BGP supports a function known as route reflection. Each route-reflector cluster requires
a cluster-identifier, which is unique to the AS or confederation in which the system resides. The
identifier is in the form of an IP address. Table 9-11 shows the cluster configuration statement's syntax and
the levels at which it can be configured.
Table 9-11. cluster Configuration Statement

Syntax cluster cluster-identifier;

cluster 192.168.250.59;
Level 1, 2, 3, 4, 5, 6

damping
BGP routes commonly consist of reachability information from ASs throughout the Internet. Reliability of
these ASs is typically outside the local AS's control and responsibility. Thus, the continual adding or withdrawl
of routes—a condition known as flapping—can cause a large number of UPDATE messages to be injected into
the BGP routing domain, in turn causing instability within the local AS routing infrastructure.
Damping is a method by which you can control how often BGP recalculates your BGP tables in a route flap
condition. By default, damping is disabled in JUNOS. Once damping is enabled, specific parameters, such as
decay, hold-down, reuse, and cutoff, can be configured under the [edit policy-options]
hierarchy. Table 9-12 shows the damping configuration statement's syntax and the levels at which it can be
configured.

www.ebook-converter.com
Table 9-12. damping Configuration Statement

Syntaxdamping;
Level 1, 2, 3, 4, 5, 6

description
Within the configuration of JUNOS, you can place descriptions annotating configuration parameters and
statements. This provides the opportunity to add clarity to otherwise complex portions of the configuration. If
the description is going to have spaces, then the use of quotation marks to enclose it is necessary. Table 9-13
shows the description configuration statement's syntax and the levels at which it can be configured.
Table 9-13. description Configuration Statement

Syntax description text-description;

description MGMT_INTFC;

Downloader demo watermarks

description "Do not disable, this interface is for
Mgmt
purposes";

Level 1, 2, 3, 4, 5, 6

disable
382
 9. BGP Routing Configuration
JUNOS supports the disabling of a set of configuration statements without removing them from the actual
configuration. Pay close attention to the hierarchy in which the statement can be applied. Table 9-14 shows the
disable configuration statement's syntax and the levels at which it can be configured.
Table 9-14. disable Configuration Statement

Syntaxdisable;
Level 1, 4

export
The export parameter is used to indicate which policies are to be used to move routes from the routing table
into the BGP protocol for advertisement. Table 9-15 shows the export configuration statement's syntax and
the levels at which it can be configured.
Table 9-15. export Configuration Statement

Syntax export [policy-name];

export static-routes;
Level 1, 2, 3, 4, 5, 6

family
By default, BGP only sends unicast reachability information. By using the family inet statement, we are
enabling Multiprotocol BGP (MBGP). This allows the local router to propagate NLRI for multicast and unicast
systems. JUNOS must have an MBGP peer to send multicast NLRI. Otherwise, only unicast NLRI will be
passed. Table 9-16 shows the family configuration statement's syntax and the levels at which it can be

www.ebook-converter.com
configured.
Table 9-16. family Configuration Statement

Syntax family(any
inet {
| multicast | unicast_{
prefix-limit {V
maximum number;
teardown <percentage>;
}
rib-group routing-table-group-name;
}
}
Level 1, 2, 3, 4, 5, 6

group
Groups can be defined in JUNOS BGP for peer relationships that share the same characteristics. If a group is
assigned, any configuration parameters applied affect not only the whole group, but override any parameters
applied at the global level. Table 9-17 shows the group configuration statement's syntax and the levels at
Downloader demo watermarks
which it can be configured.
Table 9-17. group Configuration Statement

Syntax group group-name;

group IBGP;
Level 1, 4
383
Level 1, 4 9. BGP Routing Configuration

hold-time
Earlier in this chapter, we discussed, in general terms, the establishment of BGP sessions in Sections 9.1 and
9.2. Part of this establishment was the exchange of KeepAlive and UPDATE messages. However, in the
exchange of these messages, the time period for the hold-time counter is exchanged. In JUNOS, the hold-
time default value is 90 seconds. Most implementations of BGP autonegotiate the hold-time during the
session-establishment process. If one side of the session wants to use a different value, this can be negotiated.
If a value of 0 is configured, then the local system will not pass KEEPALIVE messages. If the remote system is
not configured properly for this characteristic, the BGP session will not establish properly. Table 9-18 shows
the hold-time configuration statement's syntax and the levels at which it can be configured.
Table 9-18. hold-time Configuration Statement

Syntaxhold-time seconds;
Level 1, 2, 3, 4, 5, 6

import
The import parameter is used to list the policies to apply to routes sent from BGP to the routing table. Table 9-
19 shows the import configuration statement's syntax and the levels at which it can be configured.
Table 9-19. import Configuration Statement

Syntax import [policy-name];

import no24s;

www.ebook-converter.com
Level 1, 2, 3, 4, 5, 6

keep
This statement manipulates how JUNOS treats BGP routes in the Adj-RIB-In table. By default, JUNOS,
which does not use the keep statement, keeps all routes that are received by BGP and not looped in the Adj-
RIB-In table. If the keep all statement is used, JUNOS will keep all of the routes, regardless of any loops
in the path. If the keep none statement is used, then JUNOS will discard all BGP routes in the Adj_RIB-In
table, once the input policy has been run on them. If the input policy is changed and needs to be run again,
JUNOS will have to request that the peer readvertise the routes, then run the import policy on the routes again.
If the default of not using the keep statement or keep all statement is used, JUNOS will simply run the
import policy against the Adj-RIB-In table upon a change to the policy. This is similar to the soft-
reconfigure on a Cisco router. See Section 9.1.4 for additional RIB information. Table 9-20 shows the keep
configuration statement's syntax and the levels at which it can be configured.
Table 9-20. keep Configuration Statement

Downloader demo watermarks

Syntaxkeep (all | none);
Level 1, 2, 3, 4, 5, 6

local-address

384
 9. BGP Routing Configuration
When establishing a BGP peering session, part of the validation process is to check the incoming RID against
that which is configured for the peer. If there is a mismatch of these addresses, the session will not establish.
When configuring a session, unless specified otherwise, the address of the egress interface will be used in the
BGP session. This works most of the time for EBGP sessions. However, in IBGP it is more common to peer
with loopback interface addresses. Using the local-address statement will instruct JUNOS to use a
specified address in the BGP header. It is important that if this is used in the local system, the remote system
must use the same address as its neighbor. Table 9-21 shows the local-address configuration statement's
syntax and the levels at which it can be configured.
Table 9-21. local-address Configuration Statement

Syntax local-address address;

local-address 172.16.24.1;
Level 1, 2, 3, 4, 5, 6

local-as
Configuration of this statement allows for a virtual AS on the router. When using this statement, the local
router will use this ASN for the peering relationship. Thus, when receiving an update from a remote peer, the
local system will prepend the path with the local-as prior to installing it in the routing table. If the keyword
private is specified in the statement, then the local-as information will not be prepended to the AS_PATH.
This is a useful feature at times when multiple ASNs are necessary for peering purposes, but what gets
advertised out does not need this additional AS. Table 9-22 shows the local-as configuration statement's
syntax and the levels at which it can be configured.
Table 9-22. local-as Configuration Statement

www.ebook-converter.com
Syntaxlocal-as autonomous-system <private>;
Level 1, 2, 3, 4, 5, 6

local-preference
In IBGP the LOCAL_PREF attribute is used to establish a level of preference to certain prefixes. For instance,
if there are multiple egress points from the local AS to the rest of the Internet, then a preference can be given
to a particular egress point. This is essential when trying to shape traffic towards certain egress points. The
higher the local preference, the more preferred it is over others. The default LOCAL_PREF value in JUNOS is
100. Table 9-23 shows the local-preference configuration statement's syntax and the levels at which it
can be configured.
Table 9-23. local-preference Configuration Statement

Syntax local-preference local-preference;

local-preference 150;
Level 1, 2, 3, 4, 5, 6
Downloader demo watermarks
log-updown
Once BGP sessions are established, it is important that they remain up until it is administratively viable to bring
them down. When peering sessions transition (flap), you can experience computational strain on your local
385
 9. BGP Routing Configuration
system, as well as on the integrity of route information supplied by the local system to remote peers. In JUNOS,
the log-updown function will notify the syslog function on the local system if such transitions in the BGP
session occur. This can be used to maintain the network proactively and intervene immediately once a session
has been identified as going up and down. This will not prevent flaps, but if they are monitored properly, you
can resolve issues prior to getting that angry phone call from an upstream provider or downstream customer.
Table 9-24 shows the log-updown configuration statement's syntax and the levels at which it can be
configured.
Table 9-24. log-updown Configuration Statement

Syntaxlog-updown;
Level 1, 2, 3, 4, 5, 6

metric-out
When sending MED values to external peers, the metric-out statement can be used to set this value
explicitly. When presented with multiple exit points, and all things being equal, the receiving AS will prefer the
egress point with the lowest MED value. The metric-out option provides a constant MED value. There is a lot
of flexibility with the statement; however, policy on a per-peer basis will allow the same amount of flexibility,
if not more. Table 9-25 shows the metric-out configuration statement's syntax and the levels at which it can
be configured.
Table 9-25. metric-out Configuration Statement

Syntaxmetric-out (metric | minimum-igp <offset> | igp <offset>);

Level 1, 2, 3, 4, 5, 6

www.ebook-converter.com
multihop
A characteristic of EBGP is that the IP packets used for the BGP sessions and messages have a TTL value of 1
by default. This means that BGP peers needing to establish an EBGP session must be directly connected. The
multihop statement can be used to change this characteristic of EBGP sessions by providing the ability to
assign the TTL value and provide flexibility in implementation.
There are often times when it is necessary to establish an EBGP session between two systems that are not
directly connected. This is common in Network Access Points (NAPs) and peering points where individual
systems may be connected to a third-party system, such as a Layer 3 switch. This means the individual systems
are not directly connected. In our typical EBGP scenario, the IP packets with the BGP information would be
dropped after the first hop owing to the TTL expiring. When we use the multihop statement in our
configuration, we arbitrarily set the TTL to 255 to prevent it from expiring. Now, when we attempt to establish
our EBGP session between nondirectly connected peers, it will establish.

Downloader demo watermarks

Note that using multihop and arbitrarily setting the TTL to 255 also makes the local system vulnerable to
having BGP sessions spoofed by other systems. It is good practice to assign the TTL parameter to the
appropriate hop value when using the multihop statement to minimize the potential for outside systems to
establish sessions with local systems. Table 9-26 shows the multihop configuration statement's syntax and
the levels at which it can be configured.

386
 9. BGP Routing Configuration
group EBGP-Mhop {
type external;
multihop ttl 3;
neighbor 10.0.23.1 {
peer-AS300;
}
}
Table 9-26. multiphop Configuration Statement

Syntax multiphop;
multihop ttl <ttl-value>;
Level 1, 2, 3, 4, 5, 6

multipath
This is an essential part of load balancing. Juniper Networks routers support 8 or 16 equal-cost paths,
depending on the type of Internet processor ASIC installed on the local system. If the local system is using the
Internet Processor I, then there is the possibility for 8 equal-cost paths; if the Internet Processor II ASIC is in
the system, there is a capability of 16 equal-cost paths. The multipath statement allows JUNOS to bypass
the lowest RID decision, which is the last tiebreaker for route selection. Table 9-27 shows the multipath
configuration statement's syntax and the levels at which it can be configured.
Table 9-27. multipath Configuration Statement

Syntaxmultipath;
Level 2, 3, 5, 6

www.ebook-converter.com
neighbor
BGP requires a neighbor to peer with. The address used is the same address that will be considered as the RID
of the remote system. If it is not set correctly, the session will not establish. Table 9-28 shows the neighbor
configuration statement's syntax and the levels at which it can be configured.
Table 9-28. neighbor Configuration Statement

Syntaxneighbor address;
Level 2 and 5

no-aggregator-id
Juniper Networks routers are capable of route aggregation. This allows for fewer routes to be advertised by
using less-specific network statements, thereby covering more hosts and networks with a single statement.

Downloader demo watermarks

When aggregation occurs, the local system adds the local AS and RID to the AGGREGATOR path attribute.
Using a the no-aggregator-id statement will cause JUNOS to place a 0 in the RID field and eliminate the
possibility of having multiple aggregate advertisements floating around the network, each with different path
information. Table 9-29 shows the no-aggregator-id configuration statement's syntax and the levels at
which it can be configured.

387
 9. BGP Routing Configuration
Table 9-29. no-aggregator-id Configuration Statement

Syntaxno-aggregator-id;
Level 1, 2, 3, 4, 5, 6

no-client-reflect
In route reflection, the route reflector receives a route from a route-reflector client, and then propagates that
route to other clients in the cluster. The typical scenario for the clients in this case is to peer only with the route
reflector. In the event that a client is fully meshed with other clients (this is common in migration scenarios), it
is undesirable for the route reflector to advertise redundant routing information. JUNOS allows us to control
this with the no-client-reflect statement. In the event the client is fully meshed with other clients, it
will send out its advertisement to everyone with whom it peers. The route reflector would still send the route
information to everyone with whom it peers, as well. This excess information does not need to be advertised
out because of the full-mesh. The use of no-client-reflect prevents the route reflector from readvertising routes
learned from a client that we know to be fully meshed with the other IBGP speakers. Table 9-30 shows the
no-client-reflect configuration statement's syntax and the levels at which it can be configured.
Table 9-30. no-client-reflect Configuration Statement

Syntaxno-client-reflect;
Level 1, 2, 3, 4, 5, 6

out-delay
In JUNOS, when a route is installed in the routing table and BGP is operational, the route will immediately be

www.ebook-converter.com
imported into BGP. The out-delay statement requires the route to remain in the table for a predetermined
amount of time before being imported into the BGP process. This can be useful in scenarios where flapping
becomes a problem and other controls besides damping need to be implemented. Table 9-31 shows the out-
delay configuration statement's syntax and the levels at which it can be configured.
Table 9-31. out-delay Configuration Statement

Syntaxout-delay second;
Level 1, 2, 3, 4, 5, 6

passive
JUNOS implements a parameter to allow for the establishment of passive BGP peering sessions. The passive
statement allows the BGP speaker to be configured for BGP, but will suppress the sending of the OPEN
message to a peer. Instead, it will stand by, waiting to receive an OPEN message, then go through the peer-
establishment process. This can be useful in migration scenarios where peers are being added. The local

Downloader demo watermarks

systems can be configured to establish peering-sessions to remote peers as they are integrated. Essentially, the
local system will stand by for an attempted peer establishment from a remote system and will not initiate any
peer establishment actions, such as creating a TCP session to allow the BGP session to establish over. Table 9-
32 shows the passive configuration statement's syntax and the levels at which it can be configured.
Table 9-32. passive Configuration Statement
388
 9. BGP Routing Configuration
Syntaxpassive;
Level 1, 2, 3, 4, 5, 6

path-selection
Part of the path-selection process in JUNOS includes the comparison of the MED value. This only occurs when
the local AS receives a prefix more than once from a single peer AS. If the prefix is received from two different
peer ASs, then the MED value will not be compared. JUNOS would simply go to the next path-selection criteria,
as outlined in Section 9.1.4.4. When MEDs are compared, JUNOS uses a deterministic method. By comparison,
Cisco defaults to a nondeterministic method, although Cisco does recommend the use of the bgp
deterministic-med statement when configuring BGP on their routers.
The difference between deterministic and nondeterministic methods is the way in which the MED value is
compared. The deterministic method will group routes together based on the announcing AS. So, if prefix
10.10.0.0/16 were announced from AS100 once and AS200 twice, they would be grouped. However, only
the MED values from AS200 would be compared, because JUNOS only will compare MED values from
advertisements received from the same AS. If the MED values were compared between AS200 announcements,
the winner of that comparison would then be compared to the AS100 announcement, and some other selection
criteria would choose which prefix advertisement to select.
When using Cisco-nondeterministic as the path-selection criteria, the routes will be compared in the order of
their receipt. So, if the announcement order were AS100, AS200, AS100, JUNOS would not compare the MEDs
of the first announcements because they are from different ASs. The winning route of this first announcement
would then be compared to the second announcement from AS100. Thus, if the first announcement won over
AS200, then AS100 would be compared against the second AS100 announcement. Whichever MED value was
preferred will be selected.

www.ebook-converter.com
When using the path-selection always-compare-med statement, JUNOS will compare MEDs
regardless of whether the announcement comes from the same AS or not. If an announcement for a prefix
comes in AS100, AS200, AS100, JUNOS will compare the MED of the first two announcements AS100 and
AS200, even though they are each from a different AS. Then, the winner will be compared to the third
announcement from AS100.
Note that due to potential loops, Cisco-nondeterministic is not recommended. Table 9-33 shows the path-
selection configuration statement's syntax and the levels at which it can be configured.
Table 9-33. path-selection Configuration Statement

Syntaxpath-selection (cisco-non-deterministic | always-compare-med)

Level 1, 4

peer-as

Downloader demo watermarks

When configuring a BGP session, the peer-as parameter must be specified. This tells the local system which
AS it will be peering. Table 9-34 shows the peer-as configuration statement's syntax and the levels at which
it can be configured.
Table 9-34. peer-as Configuration Statement
389
 9. BGP Routing Configuration
SyntaxPeer-as autonomous-system;
Level 1,2,3,4,5,6

preference
In JUNOS, there is a preference placed on each protocol used. This preference is the same as the administrative
distance on Cisco routers. It is used to determine which route to make active in the routing table. All other
things being equal, the protocol with the lowest preference will be used. The preference statement can be used
to manipulate the default characteristics and modify the values assigned for each protocol. Table 9-35 shows
the preference configuration statement's syntax and the levels at which it can be configured.
Table 9-35. preference Configuration Statement

Syntaxpreference preference;
Level 1,2,3,4,5,6

prefix-limit
This statement allows us to limit the number of prefixes that will be accepted and would typically be set on a
per-peer basis. If customer A and the ISP have agreed that customer A will not send more than 10 prefix
advertisements to the ISP, the ISP would want to be able to enforce this. The maximum limit to 10 could be set
with the prefix-limit statement. A teardown would then be set, using a percentage of 90. This will log a
message when 90 percent of the maximum allowed prefixes have been sent and tear down the peering session
once the maximum threshold has been crossed. We can also specify a duration of how long to keep the peering
session down before attempting to re-establish the session. Table 9-36 shows the prefix-limit
configuration statement's syntax and the levels at which it can be configured.

www.ebook-converter.com
Table 9-36. prefix-limit Configuration Statement

Syntax prefix-limit {
maximum number;
teardown <percentage> idle-timeout (forever |
timelimit in minutes);
}

group cx-A {
type external;
peer-AS200;
neighbor 10.0.23.2 {
family inet {
unicast {
prefix-limit {
maximum 10;
teardown 90;
}
}
}
}
}
Level 1, 2, 3, 4, 5, 6

Downloader demo watermarks

protocol
JUNOS has the ability to run multiple IGP protocols. For next-hop resolution, BGP does a recursive lookup to
make sure the next-hop for a route is reachable, prior to installing a route into the routing table. This statement
allows us to tell the BGP process which IGP to use for the next-hop resolution. Table 9-37 shows the
390
 9. BGP Routing Configuration
protocol configuration statement's syntax and the levels at which it can be configured.
Table 9-37. protocol Configuration Statement

Syntaxprotocol protocol;
Level 2 and 5

remove-private
In BGP you can use private ASNs. These include confederation, private networks, or networks multihomed to
an AS with no official ASNs assigned to them. It is possible to propagate these private ASs through BGP.
JUNOS implements a mechanism to strip these private ASs from the AS_PATH, so they are not used or sent
further. To achieve this effect, use the remove-private statement. Table 9-38 shows the remove-
private configuration statement's syntax and the levels at which it can be configured.
Table 9-38. remove-private Configuration Statement

Syntaxremove-private;
Level 1, 2, 3, 4, 5, 6

trace-options
In JUNOS we can debug certain events by using the trace-options statement. This powerful feature allows
the user to view virtually all processes and functions of the BGP protocol, as well as other functions. This
information is especially valuable when troubleshooting session- and update-related problems in BGP. Table 9-
39 shows the trace-options configuration statement's syntax and the levels at which it can be configured.

www.ebook-converter.com
Table 9-39. trace-options Configuration Statement

Syntax Syntaxfile
traceoption {
name <replace> <size size> <files number>
<no-stamp> <(world
readable | no-world-readable)>;
flag flag <flag-modifier> <disable>;
}
Level 1, 2, 3, 4, 5, 6

type
In BGP there are two types of sessions that can be created. In the configuration, we use the type statement to
specify whether the session will be internal or external. Table 9-40 shows the type configuration statement's
syntax and the levels at which it can be configured.
Table 9-40. type Configuration Statement

Downloader demo watermarks

Syntaxtype type;
Level 2, 5

Scaling BGP
391
 9. BGP Routing Configuration
Now that the concepts and configuration of BGP have been covered, this section will show how to scale BGP
as the network grows. Consider that for each IBGP router in the full-mesh, the number of connections that
must be active per router is n – 1, where n is the total number of IBGP routers. If there are 30 routers in a
carrier core, each with 29 IBGP sessions running, there are a total of 435 IBGP sessions up at one time [n(n –
1)/2]. Assume that full tables need to be propagated throughout the entire AS, owing to architectural design
requirements. Add in several thousand customer routes, and, in short, a lot of data has to traverse your core
network just to cover the IBGP routing information. On top of that, you will have some IGP running in the
core, as well. That is quite a bit of in-band data, not to mention the complexity of having to troubleshoot the
platform and any potential instability issues. When BGP is scaled properly, the potential of an unstable routing
domain decreases, while the ease of overall management increases.
To assist in scaling to these design requirements, two techniques are used: route reflectors and confederations.
Route reflectors manipulate how IBGP sessions communicate with each other and eliminate the total number
of IBGP sessions required to propagate the same information. This is done through a reflector-client
relationship. Confederations, on the other hand, take what we know about BGP and allow the same type of
implementations, including route reflectors, to be used in smaller, more manageable, private ASs, combining
them all into a group of confederations. The real benefit to using route reflectors is that they assist in fixing
IBGP full-mesh scaling issues. They are easier to manage in smaller, more static networks. Confederations, on
the other hand, are a far superior approach and are very common in provider networks. They are inherently
more scalable than route reflectors, as well. Where route reflectors assist in managing the IBGP full-mesh,
confederations help to reduce the IBGP full-mesh and can also reduce the load on the IGP.

Route Reflectors
Route reflectors are typically implemented to reduce the overall cost of maintaining an IBGP full-mesh,

www.ebook-converter.com
allowing for scalability to greater proportions. One of the rules in IBGP is that no IBGP router shall advertise
routes previously learned from an IBGP neighbor. This works, because each IBGP router has a session to all
other IBGP routers (full-mesh). Essentially, all IBGP peers have the same routers as neighbors.
We will refer to Figure 9-26 to discuss IBGP route propagation. We see in this figure that router San Francisco
advertises the prefix 172.17/16 to router Denver over an EBGP session. Router Denver is a border router
for the AS, so it will run both EBGP and IBGP sessions. Because IBGP is set up with a full-mesh relationship
to all other IBGP routers in the domain, it will, in turn, advertise the 172.17/16 prefix to both Washington
D.C. and Atlanta. Even though Denver and Atlanta do not have a physical link connecting them, they are
IBGP peers due to a logical connection provided by Washington D.C. and the IGP routing domain. Since this is
a full-mesh, Washington D.C. and Atlanta received the prefix from Denver. Atlanta will not readvertise to
Washington D.C. because of the previously discussed rule on IBGP route advertisements. However,
Washington D.C. and Atlanta will receive prefix information from their EBGP peers and will propagate this
information throughout the IBGP mesh, as well.

Downloader demo watermarks

392
 9. BGP Routing Configuration

Figure 9-26. IBGP Route Propagation

Next, we want to take a look at Figure 9-27, where the concept changes, and we are able to scale our IBGP
domain without the huge increase in session numbers and route advertisements. In this scenario, New York,
San Francisco, and Boston are each advertising a network to AS100. We will follow the prefix advertised from
San Francisco to Denver again. Denver receives prefix 172.17/16 from San Francisco. Denver, in a normal
full-mesh environment, would advertise to all IBGP peers. Since this is a route-reflector scenario, Denver no
longer peers with Denver and only peers with Washington D.C. So now Washington D.C., being the route
reflector, will readvertise the prefix to Atlanta. For three routers, route reflection is not necessary. However, if
there were 40 other IBGP routers in the AS, overall session count would be significantly reduced.

www.ebook-converter.com

Figure 9-27. Route-Reflector Theory

With route reflection, we introduce a two new attributes into our BGP world: ORIGINATOR_ID and
CLUSTER_LIST. These are used as loop avoidance mechanisms.
When a route reflector originates a route, it will set the ORIGINATOR_ID with the ROUTER_ID from where
the route was received. The CLUSTER_LIST is a list of route-reflector clusters that a prefix has traversed. The
CLUSTER_LIST is updated with a cluster ID that is assigned by the route reflector and unique to each route-
reflector cluster. Typically, you want to use the RID or the loopback interface of the local system. According
Downloader demo watermarks
to the rules of BGP, if a route is received and the local system sees its own ID in this field, it will ignore the
route. The next example shows the code necessary to set the cluster ID.
lab@DC# set protocols bgp group group-name cluster number
Any single AS can implement route reflectors to manage their IBGP topology easily. They are fairly simple to
393
 9. BGP Routing Configuration
implement and significantly reduce the resources necessary to manage an IBGP routing domain.
Next we will talk about confederations and how they can play a role in our scaling of BGP.

Confederations
Use of confederations is the other common technique for scaling IBGP. Confederations are not as easy to
implement as route reflectors and take much time and analysis to implement successfully. However, due to
design restrictions or scaling opportunities, confederations may be the best solution. Confederations can be
used to enhance the overall simplicity of the AS routing domain. In ISP networks, confederations are by far the
preferred method of scalability.
Before we talk directly about confederations, let's look at some of the benefits. When you are dealing with a
large provider network or redesigning a large enterprise, confederations can be used to simplify a lot of
functions. For instance, the IGP can be better scaled. In a large network, it can sometimes be difficult to
manage an IGP's growth, regardless of the simplicity of the actual protocol. With confederations, you can scale
the IGP down into smaller, more manageable subdomains. These subdomains can take advantage of their BGP
connections to the rest of the AS confederations by advertising fewer routes, summarizing in more places, and
making routing easier to administer.
The main reason for using confederations is to scale the BGP implementation. BGP itself is a fairly easy
protocol to manage. However, as the BGP domain grows, it easily can become cumbersome. For the same
reasons confederations help an IGP scale, it will help BGP scale. You can reduce the number of advertised
prefixes within a single confederation AS, thus making routing simpler. The ability to segregate the network
addressing scheme into manageable portions becomes easier, as well. The IBGP full-mesh can also be reduced.
Some people hesitate to use confederations, perhaps because of a lack of understanding. Confederations work

www.ebook-converter.com
in the same way as BGP, for the most part. Aside from the special rules concerning confederations and route
advertisements, it is a lot like setting up small BGP domains.
Now that we have simplified things a bit, remember that confederations are used to help in scaling. Pay
attention when configuring for confederations. If this is done improperly, then the likelihood of making a
difficult situation worse is fairly certain. If you are lucky enough to get involved in a large network design from
the ground up, then you can take advantage of confederations from the start.
Working with confederations requires using EBGP inside an AS. Confederation EBGP sessions are created
between each sub-AS boundary router. In addition to the use of EBGP between sub-AS boundary routers, two
new path attributes are introduced: AS_CONFED_SEQUENCE and AS_CONFED_SET. Both of these new
attributes are defined in RFC 3065. AS_CONFED_SEQUENCE is the ordered set of member ASNs in the local
confederation that the UPDATE message has traversed; AS_CONFED_SET is the unordered set of member
ASNs in the local confederation that the UPDATE message has traversed. These are used in the same manner as
the AS_SET and AS_SEQUENCE; however, their information relates to the confederations. These attributes are
removed prior to sending route information externally from the confederation AS (see Figure 9-28).

Downloader demo watermarks

394
 9. BGP Routing Configuration

Figure 9-28. Confederation Diagram

Chapter Summary
In this chapter you have learned the fundamentals of BGP. During our discussion, you should have become
familiar with the various topologies, homing, and the difference between transit and nontransit.

www.ebook-converter.com
The routing section covered details of the RIB and how BGP routes relate to the three types of RIB. In
addition, we covered the various routing tables JUNOS uses and how route preference and JUNOS BGP path
selection work to create active routes.
With the coverage of the FSM, we are now familiar with the six states of a BGP session:
1. Idle
2. Connect
3. Active
4. OpenSent
5. OpenConfirm
6. Established

Downloader demo watermarks

We know the four different messages used in BGP and what they do:
1. OPEN—negotiates and establishes a BGP session
2. UPDATE—provides NLRI and route withdrawal information
395
 9. BGP Routing Configuration
3. NOTIFICATION—notifies the remote system when an error condition occurs
4. KEEPALIVE—maintains a BGP session
Lastly, we covered the minimum configuration requirements for BGP for both internal and external peering
sessions. This, along with the listing of common JUNOS BGP statements, has prepared you for Chapter 10,
“BGP Routing Case Studies.”

Bibliography

www.ebook-converter.com

Downloader demo watermarks

396
[ch09bib01] Sam Halabi,, and Danny McPherson. Internet Routing Architectures, 2nd
ed. Cisco Press, <year>2000</year>.
[ch09rfc1771] IETF RFC—RFC 1771, A Border Gateway Protocol 4 (BGP-4). Y.
Rekhter, T. Li. 1995.
[ch09rfc1772] IETF RFC—RFC 1772, Application of the Border Gateway Protocol in
the Internet. Y. Rekhter, P. Gross. 1995.
[ch09rfc1965] IETF RFC—RFC 1965 (OBSOLETE), Autonomous System
Confederations for BGP. P. Traina. 1996.
[ch09rfc1966] IETF RFC—RFC 1966, BGP Route Reflection: An Alternative to Full-
Mesh IBGP. T. Bates, R. Chandra. 1996.
[ch09rfc1997] IETF RFC—RFC 1997, BGP Communities Attribute. R. Chandra, P.
Traina, T. Li. 1996.
[ch09rfc2270] IETF RFC—RFC 2270, Using a Dedicated AS for Sites Homed to a Single
Provider, J. W. Stewart, III, et al. 1998.
[ch09rfc2283] IETF RFC—RFC 2283, Multiprotocol Extension for BGP-4. T. Bates, R.
www.ebook-converter.com
Chandra, D. Katz, Y. Rekhter. 1998.
[ch09rfc2385] IETF RFC—RFC 2385, Protection of BGP Sessions via the TCP MD5
Signature Option. A. Heffernan. 1998.
[ch09rfc2439] IETF RFC—RFC 2439, BGP Route Flap Damping. C. Villamisar, R.
Chandra, R. Govindan. 1998.
[ch09rfc2842] IETF RFC—RFC 2842, Capabilities Advertisement with BGP-4. R.
Chandra, J. G. Scudder. 2000.
[ch09rfc2918] IETF RFC—RFC 2918, Route Refresh Capability for BGP-4. E. Chen.
2000.

Downloader demo watermarks

[ch09rfc3065] IETF RFC—RFC 3065, Autonomous System Confederation for BGP. P.
Traina, D. McPherson, J. G. Scudder. 2001.
[ch09bib14] JUNOS Internet Software Configuration Guide: Routing and Routing
397
Protocols, Release 5.0. Juniper Networks, <year>2001</year>.
[ch09bib15] JUNOS Internet Software Operational Mode Command Reference, Release
5.0. Juniper Networks, <year>2001</year>.
[ch09bib16] W., John Stewart,, III. BGP4 Interdomain Routing in the Internet. Addison-
Wesley, <year>1999</year>.
[ch09bib17] www.apnic.net
[ch09bib18] www.arin.net
[ch09bib19] www.iab.org
[ch09bib20] www.iana.org
[ch09bib21] www.icann.org
[ch09bib22] www.juniper.net
[ch09bib23] www.ripe.net

www.ebook-converter.com

Downloader demo watermarks

398
 10. BGP Routing Case Studies
Chapter 10. BGP Routing Case Studies
In Chapter 9, we discussed the fundamentals of the BGP protocol. We also covered the implementation of BGP in Juniper
Networks routers and provided an overview of several BGP configuration statements. This chapter brings certain aspects of
Chapter 9 together in the form of case studies. These are meant to help reinforce what has been covered up to this point by
examining various characteristics of BGP routing scenarios. There are so many possibilities when it comes to configuration that
they cannot all be covered. However, the goal of this chapter is to take the foundation of what we have covered and show it in
action.
These case studies will cover common configuration scenarios with various topologies. These should be used as a guide to help
you accomplish similar tasks in your network. We know, through the evolution of the Internet, that there are so many vast
mixtures of topologies that no single solution works for every scenario. Here, we will concentrate on some fundamental designs
and how they can be expanded.

Case Study 1: Path Selection

For this first case study, we refer to Figure 10-1 for our topology. This is a very simple setup and can be used to reinforce our
understanding of concepts discussed in Chapter 9. In these scenarios, we have four different ASs.

Figure 10-1. Path-Selection Case Study

www.ebook-converter.com
Path Selection with RID
We will first look at some common examples of route selection. In this scenario, the Washington D.C. router is advertising the
172.18.0.0/16 network to both Atlanta and Denver, who in turn advertise the prefix to their neighbors. When the prefix
advertisement reaches the Houston router, Houston must select a path, based upon our previous discussion on route selection in
Section 9.1.4.4.
When we issue the show route 172.18.0.0 detail command, we see the output in the example below. Path selection
has gone through each step in the route-selection process. To outline briefly, LOCAL_PREF is equal (at 100) for each route
received. When the comparison of AS_PATH length is processed, they are equal. They both have a path list of two ASs each, and
the ORIGIN is set to I for each, meaning that the route was learned in the originating AS by the IGP. Since Houston is learning
the prefix 172.18.0.0/16 from two internal neighbors, there will be no advertisement of the MED attribute. Both of these
routes were learned via IBGP peering sessions, so there is no comparison of EBGP-learned routes to be accepted over IBGP-
learned routes. Also, there is no IGP metric associated with these links because both border routers are directly connected to the
Houston router. When the route reaches the RID comparison, we finally have a difference. The RID assigned to Dallas is
192.168.12.1, and the RID assigned to San Francisco is 192.168.16.1. Since Dallas has the lower of the two RIDs, it will
be selected as the active route. If you look at the output from San Francisco, 192.168.16.1, you will see Inactive

Downloader demo watermarks

reason: Router ID. JUNOS lets you know why a route was not selected.
lab@houston> show route 172.18.0.0 detail

inet.0: 14 destinations, 14 routes (13 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both

399
 10. BGP Routing Case Studies
172.18.0.0/16 (2 entries, 1 announced)
*BGP Preference: 170/-101
Source: 192.168.12.1
Nexthop: 10.0.13.2 via fe-0/1/0.0, selected
Protocol Nexthop: 10.0.8.1 Indirect nexthop: 83784c8 37
State: <Active Int Ext>
Local AS: 600 Peer AS: 600
Age: 13:19 Metric2: 20
Task: BGP_600.192.168.12.1+179
Announcement bits (2): 0-KRT 4-Resolve inet.0
AS path: 400 100 I
Localpref: 100
Router ID: 192.168.12.1

BGP Preference: 170/-101

Source: 192.168.16.1
Nexthop: 10.0.15.2 via fe-0/1/1.0, selected
Protocol Nexthop: 10.0.16.2 Indirect nexthop: 8378550 38
State: <Int Ext>
Inactive reason: Router ID
Local AS: 600 Peer AS: 600
Age: 12:46 Metric2: 20
Task: BGP_600.192.168.16.1+3881
AS path: 700 100 I
Localpref: 100
Router ID: 192.168.16.1
Next, we will look at the routing table for Denver. This example will show how AS_PATH length comes into play when selecting
an active route. In this scenario, Washington D.C. advertises the 172.18.0.0/16 prefix to Atlanta and Denver. Atlanta will
announce the prefix to Dallas and Denver, and Denver will announce the prefix to San Francisco and Denver.

www.ebook-converter.com
Path Selection with AS_PATH
In the example below, we see the show route 172.18.0.0/16 detail output from the Denver router. Denver knows about
the 172.18.0.0/16 prefix from both Washington D.C. and Atlanta. The link between Denver and Washington D.C. is chosen
as the active route because the AS_PATH length is shorter than that for Denver to Atlanta to Washington D.C. The highlighted
portions of the output reinforce this.
lab@denver> show route 172.18.0.0/16 detail

inet.0: 9 destinations, 9 routes (8 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both

172.18.0.0/16 (2 entries, 1 announced)

*BGP Preference: 170/-101
Source: 10.0.1.1
Nexthop: 10.0.1.1 via fe-0/1/2.0, selected
State: <Active Ext>
Local AS: 700 Peer AS: 100
Age: 1:44:59

Downloader demo watermarks

Task: BGP_100.10.0.1.1+1059
Announcement bits (2): 0-KRT 1-BGP.0.0.0.0+179
AS path: 100 I
Localpref: 100
Router ID: 192.168.2.1

BGP Preference: 170/-101

400
 10. BGP Routing Case Studies
Source: 10.0.0.2
Nexthop: 10.0.0.2 via fe-0/1/0.0, selected
State: <Ext>
Inactive reason: AS path
Local AS: 700 Peer AS: 400
Age: 1:44:59
Task: BGP_400.10.0.0.2+1044
AS path: 400 100 I
Localpref: 100
Router ID: 192.168.5.1

Path Selection EBGP over IBGP

The next example is show route 172.18.0.0/16 detail from the Dallas router. Dallas will receive the
172.18.0.0/16 prefix from external neighbor Atlanta and from internal neighbor Houston. Path selection for an active route
will not occur until we reach the selection criteria of EBGP routes chosen over IBGP routes. Because of this, Dallas is going to
prefer the advertisement from Atlanta to that from San Francisco. The nature of BGP is often characterized as hot potato routing,
or “get the packet out of the AS via the shortest path.”
lab@dallas> show route 172.18.0.0/16 detail
inet.0: 14 destinations, 14 routes (13 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

172.18.0.0/16 (2 entries, 1 announced)

*BGP Preference: 170/-101
Source: 10.0.8.1
Nexthop: 10.0.8.1 via fe-0/1/1.0, selected
State: <Active Ext>
Local AS: 600 Peer AS: 400

www.ebook-converter.com
Age: 1:19:05
Task: BGP_400.10.0.8.1+1060
Announcement bits (3): 0-KRT 3-BGP.0.0.0.0+179 4-Resolve inet.0
AS path: 400 100 I
Localpref: 100
Router ID: 192.168.5.1

BGP Preference: 170/-101

Source: 192.168.16.1
Nexthop: 10.0.13.1 via fe-0/1/0.0, selected
Protocol Nexthop: 10.0.16.2 Indirect nexthop: 83784c8 38
State: <Int Ext>
Inactive reason: Interior > Exterior > Exterior via Interior
Local AS: 600 Peer AS: 600
Age: 1:18:31 Metric2: 30
Task: BGP_600.192.168.16.1+3883
AS path: 700 100 I
Localpref: 100
Router ID: 192.168.16.1

Downloader demo watermarks

AS_PATH Prepend
Next, we are going to influence how we wish to route traffic to our destination network of 172.18.0.0/16 sent inbound to our
AS100. In Figure 10-1, we see the link between Washington D.C. and Atlanta is a DS-3, and the link between Washington D.C.
and Denver is and OC3. We prefer traffic coming to us over the higher-speed OC3 circuit from Denver. You might initially think
that setting the MED value would influence how the external neighbors send traffic to AS100. MED, in this case, will not provide
401
 10. BGP Routing Case Studies
any benefit because we are not multihomed to a single AS. The next thought is to use AS path prepending. AS path prepending is a
method by which we can attempt to influence how traffic will be sent to our AS by external networks. Up to now, we have
advertised our network 172.18.0.0/16 without any additional tweaking. Now we want to have external networks send traffic
to us via our OC3 link between Washington D.C. and Denver. To do so, we will prepend our own ASN to our AS_PATH attribute
when we advertise our route to Atlanta in AS400. This is done through setting policy.
If we take a look at Atlanta's routing table in the example below, we see there are two routes for network 172.18.0.0/16, one
that is directly connected and the other through AS700.
lab@Atlanta> show route 172.18.0.0

inet.0: 9 destinations, 9 routes (8 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both
172.18.0.0/16 *[BGP/170] 00:00:03, localpref 100
AS path: 100 I
> to 10.0.2.1 via fe-0/1/2.0
[BGP/170] 00:41:05, localpref 100
AS path: 700 100 I
> to 10.0.0.1 via fe-0/1/0.0
Our next example shows the routing table in Atlanta after we implement AS path prepending. We now see that Atlanta prefers to
use the path to Denver to get to Washington D.C., rather than its own direct path to Washington D.C. This influence could
potentially cause problems in how the rest of the world is seeing route advertisements due to the prepended path being advertised
out to other neighbors of Atlanta.
lab@Atlanta> show route 172.18.0.0

inet.0: 9 destinations, 9 routes (8 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both

www.ebook-converter.com
172.18.0.0/16 *[BGP/170] 00:44:08, localpref 100
AS path: 700 100 I
> to 10.0.0.1 via fe-0/1/0.0
[BGP/170] 00:00:23, localpref 100
AS path: 100 100 I
> to 10.0.2.1 via fe-0/1/2.0
[BGP/170] 00:00:23, localpref 100
AS path: 600 700 100 I
> to 10.0.8.2 via fe-0/1/1.0
When we issue the show route 172.18.0.0/16 detail command, we see why the new route is preferred. The last route
in the table fails because of AS_PATH length. The second route is not active because it loses out in the RID comparison.
lab@Atlanta> show route 172.18.0.0/16 detail
inet.0: 9 destinations, 9 routes (8 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

172.18.0.0/16 (3 entries, 1 announced)

*BGP Preference: 170/-101

Downloader demo watermarks

Source: 10.0.0.1
Nexthop: 10.0.0.1 via fe-0/1/0.0, selected
State: <Active Ext>
Local AS: 400 Peer AS: 700
Age: 46:13
Task: BGP_700.10.0.0.1+179
Announcement bits (2): 0-KRT 1-BGP.0.0.0.0+179
402
 10. BGP Routing Case Studies
AS path: 700 100 I
Localpref: 100
Router ID: 192.168.0.1

BGP Preference: 170/-101

Source: 10.0.2.1
Nexthop: 10.0.2.1 via fe-0/1/2.0, selected
State: <Ext>
Inactive reason: Router ID
Local AS: 400 Peer AS: 100
Age: 2:28
Task: BGP_100.10.0.2.1+1073
AS path: 100 100 I
Localpref: 100
Router ID: 192.168.2.1

BGP Preference: 170/-101

Source: 10.0.8.2
Nexthop: 10.0.8.2 via fe-0/1/1.0, selected
State: <Ext>
Inactive reason: AS path
Local AS: 400 Peer AS: 600
Age: 2:28
Task: BGP_600.10.0.8.2+179
AS path: 600 700 100 I
Localpref: 100
Router ID: 192.168.12.1
When we perform AS path prepending, another interesting characteristic of route advertisement shows up. Because Atlanta now
prefers the path to Denver to get to Washington D.C. in AS100, it will also advertise that same route to Dallas. However, Dallas
also receives an advertisement from San Francisco with a shorter AS_PATH list. Consequently, Dallas will now send any traffic

www.ebook-converter.com
for prefix 172.18.0.0/16 through Houston, then to San Francisco, then to Denver, and finally off to Washington D.C.,
whereas before the prepending took place, Dallas would have sent traffic for 172.18.0.0/16 to Atlanta, and Atlanta would
have sent it directly to Washington D.C.
lab@dallas> show route 172.18.0.0

inet.0: 14 destinations, 14 routes (13 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both
172.18.0.0/16 *[BGP/170] 00:04:38, localpref 100, from 192.168.16.1
AS path: 700 100 I
> to 10.0.13.1 via fe-0/1/0.0
[BGP/170] 00:04:38, localpref 100
AS path: 400 700 100 I
> to 10.0.8.1 via fe-0/1/1.0
Let's see what happens when we lose the link between Atlanta and Denver with the prepended path. Dallas now sees an
advertisement for prefix 172.18.0.0/16 from Atlanta, but the AS_PATH list is longer than that of the advertisement from San
Francisco.

Downloader demo watermarks

Essentially, though, the prepending has had the desired effect of causing all traffic inbound to Washington D.C. to come through
the link between Denver and Washington D.C.
lab@dallas> show route 172.18.0.0

inet.0: 14 destinations, 14 routes (13 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both
403
 10. BGP Routing Case Studies
172.18.0.0/16 *[BGP/170] 00:10:32, localpref 100, from 192.168.16.1
AS path: 700 100 I
> to 10.0.13.1 via fe-0/1/0.0
[BGP/170] 00:00:09, localpref 100
AS path: 400 100 100 I
> to 10.0.8.1 via fe-0/1/1.0
What we have seen up to this point are some simplified examples of route selection in JUNOS. The preceding examples should
reinforce the route-selection criteria, as well as provide a foundation for the remainder of this chapter.

Case Study 2: Advanced Path Selection

This case study will present some more advanced route-selection scenarios and discuss both how IGP metrics come into play and
how LOCAL_PREF can affect the way an AS routes traffic to external networks. In Figure 10-2, two networks are being
advertised. Washington D.C. is advertising 172.1.0.0/16, and Atlanta is advertising 172.4.0.0/16.

Figure 10-2. Advanced Path-Selection Case Study

www.ebook-converter.com
LOCAL_PREF and IGP Metric
Let's first look at how the border router, Denver, interprets the route advertisements. In the following example, we have the
output of show route protocol bgp. We use this command, since we are only injecting two routes into BGP. We could
also cover all of these routes with the show route 172.0.0.0/13 command. We see that Denver received the
172.1.0.0/16 network advertisement from AS100 and AS400. The active route is through the shorter AS_PATH list due from
AS100, which is what we expect to see.
lab@dallas> show route protocol bgp

inet.0: 18 destinations, 18 routes (17 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both

172.1.0.0/16 *[BGP/170] 00:27:32, localpref 100, from 192.168.0.1

AS path: 100 I
> to 10.0.13.1 via fe-0/1/0.0
[BGP/170] 00:36:43, localpref 100
AS path: 400 100 I
> to 10.0.8.1 via fe-0/1/1.0

Downloader demo watermarks

172.4.0.0/16 *[BGP/170] 00:27:13, localpref
AS path: 400 I
> to 10.0.8.1 via fe-0/1/1.0
[BGP/170] 00:20:07, localpref
100

100, from 192.168.0.1

AS path: 400 I
> to 10.0.13.1 via fe-0/1/0.0

404
 10. BGP Routing Case Studies
Next, we issue the show route protocol bgp on border router Dallas. Dallas will get to network 172.1.0.0 via border
router Denver. For network 172.4.0.0/16, Dallas will send to AS400 out the directly connected interface.
lab@denver> show route protocol bgp

inet.0: 17 destinations, 17 routes (16 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both
172.1.0.0/16 *[BGP/170] 00:29:11, localpref 100
AS path: 100 I
> to 10.0.1.1 via fe-0/1/2.0
[BGP/170] 00:15:42, localpref 100
AS path: 400 100 I
> to 10.0.0.2 via fe-0/1/0.0
172.4.0.0/16 *[BGP/170] 00:15:42, localpref 100
AS path: 400 I
> to 10.0.0.2 via fe-0/1/0.0
[BGP/170] 00:22:49, localpref 100, from 192.168.12.1
AS path: 400 I
> to 10.0.16.1 via fe-0/1/1.0
[BGP/170] 00:22:49, localpref 100
AS path: 100 400 I
> to 10.0.1.1 via fe-0/1/2.0
The way in which the routes are set up is typical for this scenario. Houston and San Francisco will route traffic for the
172.1.0.0/16 network through the border router in Denver. This path is selected because the AS_PATH list is shorter.
When it comes to the 172.4.0.0/16 network, San Francisco will send traffic through Denver, and Houston will send traffic
through Dallas. Each sees an equal AS_PATH list. The difference between the two is the IGP metric. This can be seen in the next
example, which shows the routing table from San Francisco.

www.ebook-converter.com
172.4.0.0/16 (2 entries, 1 announced)
*BGP Preference: 170/-101
Source: 192.168.0.1
Nexthop: 10.0.16.2 via fe-0/1/1.0, selected
Protocol Nexthop: 10.0.0.2 Indirect nexthop: 83786e8 41
State: <Active Int Ext>
Local AS: 600 Peer AS: 600
Age: 37:56 Metric2: 20
Task: BGP_600.192.168.0.1+179
Announcement bits (2): 0-KRT 4-Resolve inet.0
AS path: 400 I
Localpref: 100
Router ID: 192.168.0.1

BGP Preference: 170/-101

Source: 192.168.12.1
Nexthop: 10.0.15.1 via fe-0/1/2.0, selected
Protocol Nexthop: 10.0.8.1 Indirect nexthop: 8378440 39
State: <NotBest Int Ext>
Inactive reason: IGP metric

Downloader demo watermarks

Local AS:
Age: 38:33
600 Peer AS:
Metric2: 30
600

Task: BGP_600.192.168.12.1+179
AS path: 400 I
Localpref: 100
Router ID: 192.168.12.1

405
 10. BGP Routing Case Studies
Now that we have a grasp on how the typical routing scenario works, we will set our LOCAL_PREF attribute on Denver to cause
it to be the preferred point of egress to reach the 172.4.0.0/16 network and set the LOCAL_PREF on Dallas to cause it to be
the preferred point of egress to reach the 172.1.0.0/16 network. This is not the most optimal way to route traffic, given this
topology, but it serves the purpose of showing how LOCAL_PREF will affect routing and, potentially, how it could be misused.
Now, if we take a look at the routing table from Dallas to network 172.4.0.0/16, we see that the active route is now going
through the Denver border router.
lab@dallas> show route 172.4.0.0/16

inet.0: 18 destinations, 18 routes (17 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both

172.4.0.0/16 *[BGP/170] 01:02:57, localpref 200, from 192.168.0.1

AS path: 400 I
> to 10.0.13.1 via fe-0/1/0.0
[BGP/170] 01:03:41, localpref 100
AS path: 400 I
> to 10.0.8.1 via fe-0/1/1.0
When we look at the routing table from Denver to network 172.1.0.0/16, we see that the active route is now going through
the Dallas border router.
lab@denver> show route 172.1.0.0/16
inet.0: 17 destinations, 17 routes (16 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
172.1.0.0/16 *[BGP/170] 00:05:03, localpref 200, from 192.168.12.1
AS path: 400 100 I
> to 10.0.16.1 via fe-0/1/1.0

www.ebook-converter.com
[BGP/170] 01:05:10, localpref 100
AS path: 100 I
> to 10.0.1.1 via fe-0/1/2.0
[BGP/170] 01:05:06, localpref 100
AS path: 400 100 I
> to 10.0.0.2 via fe-0/1/0.0
Again, these are not the most optimal routing scenarios, which is all the more reason to pay close attention when manipulating
LOCAL_PREF to change the routing characteristics of your AS.

NEXT_HOP
We will now take a look at the NEXT_HOP attribute and how it works in an operational environment. When we speak about the
term next-hop in routing, especially when BGP is involved, we can be talking about two different subjects. First, there is the next-
hop that most people are familiar with, that being the next-hop to send a packet to. Basically a next-hop identifies an address and
an egress interface. The second next-hop is a bit more involved as we are referring to protocol next-hop. This is important because
BGP will need to be able to resolve this next-hop, which is the NEXT_HOP attribute. In order for BGP to install a route into the
routing table, it must be able to do a recursive lookup to the routing table and resolve the address in the NEXT_HOP attribute. If
the address in the NEXT_HOP attribute cannot be resolved, then the route will not be installed into the routing table. When a route

Downloader demo watermarks

is advertised from one AS to another, the route is sent from one EBGP router to another. The gaining EBGP router usually has no
problem resolving the next-hop, because the next-hop is usually the address of the directly connected subnet that hosts the EBGP
session. In IBGP the NEXT_HOP attribute takes on a different value. We will see this and come to understand how the
NEXT_HOP attribute is used.
In Figure 10-3, you can see that router Atlanta in AS200 is sending prefix 172.16.16.0/24 to router Washington D.C. in
AS100. In this case, Washington D.C. will receive the route with the NEXT_HOP attribute set to 10.0.2.2. The reason for this is
406
 10. BGP Routing Case Studies
that Atlanta sends the prefix to Washington D.C., setting the NEXT_HOP attribute to the address of the physical interface that is
used to establish the peering session. So, in the case of this connection, 10.0.2.2 is being used.

Figure 10-3. NEXT_HOP Case Study

The following example shows router Washington D.C.'s routing table. You can see the route for the 172.16.16.0/24 network
learned through BGP with a next-hop of 10.0.2.2. This will become clearer in the next example.
lab@DC> show route 172.16.16.0
inet.0: 20 destinations, 20 routes (19 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

www.ebook-converter.com
172.16.16.0/24 *[BGP/170] 01:15:10, MED 0, localpref 100
AS path: 200 I
> to 10.0.2.2 via fe-0/1/0.0
The next example shows the same route with the show route 172.16.16.0 extensive command on Washington D.C.
You can see that the NEXT_HOP advertised was 10.0.2.2, which is exactly how BGP works. The advertising router Atlanta is
sending itself as the NEXT_HOP. The output will vary between EBGP and IBGP sessions. We will show this over the next few
examples.
lab@DC> show route 172.16.16.0 extensive
inet.0: 20 destinations, 20 routes (19 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.16.0/24 (1 entry, 1 announced)
TSI:
KRT in-kernel 172.16.16.0/24 -> {10.0.2.2}
Page 0 idx 0 Type 1 val 8382d20
Nexthop: 10.0.2.2 (this is the attribute NEXT_HOP)
MED: 0

Downloader demo watermarks

Localpref: 100
AS path: 200 I
Communities:
Page 0 idx 1 Type 1 val 8382cb0
Nexthop: 10.0.2.2
AS path: 200 I

407
 10. BGP Routing Case Studies
Communities:
Path 172.16.16.0 from 10.0.2.2 Vector len 4. Val: 0 1

*BGP Preference: 170/-101

Source: 10.0.2.2
Nexthop: 10.0.2.2 via fe-0/1/0.0, selected
State: <Active Ext>
Local AS: 100 Peer AS: 200
Age: 1:17:51 Metric: 0
Task: BGP_200.10.0.2.2+179
Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 4-Resolve inet.0
AS path: 200 I
Localpref: 100
Router ID: 4.4.4.4
This next example of the routing table for router New York shows things coming together. You can see again the route
172.16.16.0/24 was learned through BGP and from ID 1.1.1.1, which is router Washington D.C. The next-hop listed for
this route is 10.0.24.1. Now, we discussed a few moments ago how the term next-hop can be either the physical next-hop to a
destination or a protocol next-hop, as in the BGP NEXT_HOP attribute. In the show route listing here, the portion that shows to
10.0.24.1 via fe-0/1/1.0 is actually the gateway to be used to get to the prefix. There is also a route in there for the
10.0.2.0/24 network. Remember this for we will discuss it further shortly.
lab@NewYork> show route

inet.0: 11 destinations, 11 routes (10 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both

1.1.1.1/32 *[OSPF/10] 00:19:12, metric 10

> to 10.0.24.1 via fe-0/1/1.0
2.2.2.2/32 *[Direct/0] 02:30:01
> via lo0.0

www.ebook-converter.com
10.0.2.0/24 *[OSPF/10] 00:19:12, metric 20
> to 10.0.24.1 via fe-0/1/1.0
10.0.24.0/24 *[Direct/0] 1w1d 00:03:15
> via fe-0/1/1.0
10.0.24.2/32 *[Local/0] 1w1d 00:03:15
Local
172.16.16.0/24 *[BGP/170] 00:32:47, MED 0, localpref 100, from 1.1.1.1
AS path: 200 I
> to 10.0.24.1 via fe-0/1/1.0
The example below shows the show route 172.16.16.0 extensive command. About halfway through the listing you
see Nexthop: 10.0.24.1 via fe-0/1/1.0, and immediately following, you see Protocol Nexthop: 10.0.2.2.
This last part is the actual NEXT_HOP attribute being passed. It also indicates that it is an indirect next-hop, which should clue you
in on the contents. This is where it all comes together. BGP passes the NEXT_HOP attribute, which is the border router
10.0.2.2. The reason that we are able to see this route as the active route is that BGP was able to resolve the NEXT_HOP
attribute in the IGP, which is 10.0.2.0/24. Taking a close look at this, we see that the route 10.0.2.0 uses a gateway
address of 10.0.24.1.
lab@NewYork> show route 172.16.16.0 extensive

Downloader demo watermarks

inet.0: 15 destinations, 15 routes (14 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.16.0/24 (1 entry, 1 announced)
TSI:
KRT in-kernel 172.16.16.0/24 -> {indirect(43)}

408
 10. BGP Routing Case Studies
*BGP Preference: 170/-101
Source: 1.1.1.1
Nexthop: 10.0.24.1 via fe-0/1/1.0, selected
Protocol Nexthop: 10.0.2.2 Indirect nexthop: 83785d8 43
State: <Active Int Ext>
Local AS: 100 Peer AS: 100
Age: 27:05 Metric: 0 Metric2: 20
Task: BGP_100.1.1.1.1+179
Announcement bits (2): 0-KRT 4-Resolve inet.0
AS path: 200 I
Localpref: 100
Router ID: 1.1.1.1
Indirect nexthops: 1
Protocol nexthop: 10.0.2.2 Metric: 20 Indirect nexthop: 83785d8 43
Indirect path forwarding nexthops: 1
Nexthop: 10.0.24.1 via fe-0/1/1.0
Next, we will see what happens when we remove the 10.0.2.0/24 network from our IGP. Looking at the routing table for
Washington D.C., we see that nothing has changed and that we still see the route. This is because the NEXT_HOP that needs to be
resolved is a directly connected network, and thus the recursive lookup will be successful.
lab@DC> show route 172.16.16.0
inet.0: 20 destinations, 20 routes (19 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.16.0/24 *[BGP/170] 01:39:04, MED 0, localpref 100
AS path: 200 I
> to 10.0.2.2 via fe-0/1/0.0
However, if we take a look in the routing table for New York, we will not see the route. The route does not exist anymore, or does

www.ebook-converter.com
it?
lab@NewYork> show route 172.16.16.0
The next example shows the output from the show route 172.16.16.0 hidden extensive command. You can see the
route is here because it was advertised by BGP. However, BGP was unable to resolve the next-hop information because our IGP
knows nothing about the 10.0.2.0/24 network.
lab@NewYork> show route 172.16.16.0 hidden extensive

inet.0: 14 destinations, 14 routes (9 active, 0 holddown, 5 hidden)

+ = Active Route, - = Last Active, * = Both

172.16.16.0/24 (1 entry, 0 announced)

TSI:

BGP Preference: 170/-101

Next-hop type: Unusable
State: <Hidden Int Ext>
Local AS: 100 Peer AS: 100

Downloader demo watermarks

Age: 44:24 Metric: 0
Task: BGP_100.1.1.1.1+179
AS path: 200 I
Localpref: 100
Router ID: 1.1.1.1
Indirect nexthops: 1
Protocol nexthop: 10.0.2.2 Indirect nexthop: 83785d8 43
409
 10. BGP Routing Case Studies
Nexthop-Self
The next part of this case study will deal with nexthop-self. Figure 10-4 shows the topology we will use for this scenario. As we
discussed a few moments ago, BGP will need to be able to resolve the NEXT_HOP address before it can make a route active in the
routing table. In the following scenario, we will show how the nexthop-self policy can be used to achieve our desired results. Up
until now, we have been taking the network between EBGP peers and advertising it into our IGP through the use of the passive
command for a given interface. We know from Section 8.4.6 that the use of the passive command will allow the interface and
network associated with it to be advertised into the IGP, but it will not form any adjacencies to any neighbors on that interface.
There are times when putting the EBGP link into the IGP may not be desirable. There are also times when you want a BGP router
to simply advertise itself as the NEXT_HOP for a given network.

Figure 10-4. Nexthop-Self Case Study

www.ebook-converter.com
We will first see what our routing table looks like when we have the IGP advertising the EBGP link between Washington D.C.
and Denver into AS200. In the Atlanta router, we see that the next-hop advertised in Protocol Nexthop: 10.0.1.2 can be
reached via Nexthop: 10.0.2.1 via fe-0/1/2.0 is because OSPF is running passively on interface fe-0/1/2.
lab@Atlanta> show route 172.16.0.0/16 detail

inet.0: 16 destinations, 16 routes (15 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both

172.16.0.0/16 (1 entry, 1 announced)

*BGP Preference: 170/-101
Source: 192.168.2.1
Nexthop: 10.0.2.1 via fe-0/1/2.0, selected
Protocol Nexthop: 10.0.1.2 Indirect nexthop: 83784c8 23
State: <Active Int Ext>
Local AS: 200 Peer AS: 200
Age: 12:24 Metric2: 20
Task: BGP_200.192.168.2.1+179
Announcement bits (2): 0-KRT 4-Resolve inet.0
AS path: 100 I

Downloader demo watermarks

Localpref: 100
Router ID: 192.168.2.1
Next, we see what happens when we remove the passive from our configuration on fe-0/1/2. We know that Washington
D.C. will still be able to reach the network 172.16.0.0/16 because it is directly connected to the subnet that the next-hop is
on. But, when we look at Atlanta, we get no result. You will notice that there is now a second hidden route when we issue our
show route 172.16.0.0/16 command.
410
 10. BGP Routing Case Studies
lab@Atlanta> show route 172.16.0.0/16
inet.0: 15 destinations, 15 routes (13 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both
This second hidden route is our BGP route. It is hidden from us and will never become active owing to the inability of Atlanta to
resolve the next-hop during the recursive lookup. If we issue the show route 172.16.0.0/16 hidden detail
command, we see the following results. The next-hop type is listed as unusable because the recursive lookup was unsuccessful.
lab@Atlanta> show route 172.16.0.0/16 hidden detail

inet.0: 15 destinations, 15 routes (13 active, 0 holddown, 2 hidden)

+ = Active Route, - = Last Active, * = Both

172.16.0.0/16 (1 entry, 0 announced)

BGP Preference: 170/-101
Next-hop type: Unusable
State: <Hidden Int Ext>
Local AS: 200 Peer AS: 200
Age: 21:28
Task: BGP_200.192.168.2.1+179
AS path: 100 I
Localpref: 100
Router ID: 192.168.2.1
The way we can solve this without using the passive interface in our IGP is to use the nexthop-self policy. Our policy is listed
here:
policy-options {
policy-statement nexthop-self {
from protocol bgp;

www.ebook-converter.com
then {
next-hop self;
}
}
}
The policy is implemented in our BGP session in the following way:
protocols {
bgp {
group IBGP {
type internal;
local-address 192.168.2.1;
export nexthop-self;
neighbor 192.168.5.1;
neighbor 192.168.12.1;
}
}

Downloader demo watermarks

Now, if we go into our Atlanta router and issue the show route 172.16.0.0/16 detail command, we get the following
results. You will notice that the Protocol Next-hop is 192.168.2.1, whereas before it was 10.0.1.2. Our nexthop-self
policy does this for us. It is a very simple method of controlling next-hop for BGP in cases where the present IGP may not be able
to do a recursive lookup on the next-hop. What would happen here is that a packet destined for 172.16.0.0/16 would come to
Washington D.C. We would then rely on Washington D.C. to route the packet through the rest of the network.

411
 10. BGP Routing Case Studies
lab@Atlanta> show route 172.16.0.0/16 detail
inet.0: 15 destinations, 15 routes (14 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.0/16 (1 entry, 1 announced)
*BGP Preference: 170/-101
Source: 192.168.2.1
Nexthop: 10.0.2.1 via fe-0/1/2.0, selected
Protocol Nexthop: 192.168.2.1 Indirect nexthop: 8378550 23
State: <Active Int Ext>
Local AS: 200 Peer AS: 200
Age: 29:16 Metric2: 10
Task: BGP_200.192.168.2.1+179
Announcement bits (2): 0-KRT 4-Resolve inet.0
AS path: 100 I
Localpref: 100
Router ID: 192.168.2.1
This concludes the case study for next-hop. You have seen how next-hop applies to the interior and exterior of an AS and the
interpretation of each. You now know why the IGP is so important to BGP for recursive lookups and how the lack of routing
information in IGP can cause your BGP routes not to be installed. We can also overcome some obstacles of the recursive lookup
problem through implementation of nexthop-self policy.

MED
The MED attribute is used to tell a remote AS which links to prefer when sending traffic to the local AS. In this scenario, we will
refer to Figure 10-5. In this example, Renda's Travel Service uses MOMO ISP for Internet connectivity. Since Renda's Travel
Services is a nationwide operation, there are two major gateways: one in Los Angeles, California, and the other in Raleigh, North
Carolina. Everything east of the Mississippi comes into the Raleigh site, and everything west of the Mississippi comes into the Los

www.ebook-converter.com
Angeles site. Because of the 24-7 support that Renda's Travel Service provides to its customer base, there must be Internet
connectivity at all times.

Downloader demo watermarks

Figure 10-5. MED Case Study

MOMO ISP has assigned two blocks of address space to Renda's Travel Service. The travel service's network engineers utilize the
172.16.0.0/23 address space for the western region and 172.16.2.0/23 for the eastern region. In general terms, both Los
Angeles and Raleigh could advertise the entire address space equally with an advertisement of 172.16.0.0/22. This would tell
MOMO ISP to send the traffic for the entire address space to either location. Bandwidth is expensive, however, and we want to
provide the best use of the bandwidth for our client. Instead, we will have Los Angeles advertise 172.16.0.0/23 with a MED =
412
 10. BGP Routing Case Studies
50 and 172.16.2.0/23 with a MED = 100.
In addition, we will have Raleigh do just the opposite: 172.16.0.0/23 with a MED = 100 and 172.16.2.0/23 with a MED =
50. With this we are telling MOMO to prefer the link between San Francisco and Los Angeles for the 172.16.0.0/23 address
space and the link between Washington D.C. and Raleigh for the 172.16.2.0/23 address space. MOMO does not have to do
anything with this MED value and can completely ignore it, but since we are a persistent integrator, we finally negotiate a policy
for MOMO to use our MED values. This setup also allows us a backup in case either the San Francisco or Los Angeles ISP links go
down.
ISPs and customers do not always “listen” to the MED value, mostly because there is potential for dishonesty in the use of the MED
value for manipulation of how the other side is going to pass traffic. In a well-negotiated environment, though, where the trust has
been built between the client and provider, use of this attribute can be very beneficial.
Now that we have laid some groundwork, let's see how it all works together. We will be looking at the routing table in router San
Francisco. Notice that there are two routes: one for the 172.16.0.0/23 network and another for the 172.16.2.0/23
network. Each of these is sent to San Francisco from Los Angeles with different MED values. With these settings, any traffic sent
to San Francisco destined for network 172.16.0.0/23 will be sent to Los Angeles. If traffic is destined for the
172.16.2.0/23 network, it will traverse the link from San Francisco to Washington D.C., then to Raleigh. If for some reason
there is a link failure between San Francisco and Washington D.C., then all traffic intended for the 172.16.2.0/23 network
would be sent to Los Angeles via San Francisco.
lab@SanFrancisco> show route 172.16.0.0/22

inet.0: 19 destinations, 19 routes (18 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both

172.16.0.0/23 *[BGP/170] 01:05:05, MED 50, localpref 100

AS path: 100 I
> to 10.0.24.2 via fe-0/1/1.0
172.16.2.0/23 *[BGP/170] 00:23:39, MED 50, localpref 100, from 4.4.4.4
AS path: 100 I

www.ebook-converter.com
> to 10.0.2.2 via fe-0/1/0.0
[BGP/170] 01:05:05, MED 100, localpref 100
AS path: 100 I
> to 10.0.24.2 via fe-0/1/1.0
Next, we have the routing table for Washington D.C. In this case, you can see just the opposite effect with the different networks.
The path information will switch.
lab@DC> show route 172.16.0.0/22

inet.0: 17 destinations, 17 routes (16 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both

172.16.0.0/23 *[BGP/170] 01:06:51, MED 50, localpref 100, from 1.1.1.1

AS path: 100 I
> to 10.0.2.1 via fe-0/1/2.0
[BGP/170] 00:25:25, MED 100, localpref 100
AS path: 100 I
> to 10.0.8.2 via fe-0/1/1.0
172.16.2.0/23 *[BGP/170] 00:25:25, MED 50, localpref 100

Downloader demo watermarks AS path: 100 I

> to 10.0.8.2 via fe-0/1/1.0
In this next example, we are going to take down the link between San Francisco and Los Angeles. We will see, in the next two
examples, the changes to the routing table. The first example is the routing table for San Francisco. We now will route through
Washington D.C. for all traffic destined to any network in the 172.16.0.0/22 block.

413
 10. BGP Routing Case Studies
lab@SanFrancisco> show route 172.16.0.0/22

inet.0: 17 destinations, 17 routes (16 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both

172.16.0.0/23 *[BGP/170] 00:00:13, MED 100, localpref 100, from 4.4.4.4

AS path: 100 I
> to 10.0.2.2 via fe-0/1/0.0
172.16.2.0/23 *[BGP/170] 00:35:23, MED 50, localpref 100, from 4.4.4.4
AS path: 100 I
> to 10.0.2.2 via fe-0/1/0.0
For good measure, the following shows the table for Washington D.C. We see that any traffic for the 172.16.0.0/23 or
172.16.2.0/23 networks will be sent out of the link from Washington D.C. to Raleigh.
lab@DC> show route 172.16.0.0/22

inet.0: 15 destinations, 15 routes (14 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both

172.16.0.0/23 *[BGP/170] 00:37:34, MED 100, localpref 100

AS path: 100 I
> to 10.0.8.2 via fe-0/1/1.0
172.16.2.0/23 *[BGP/170] 00:37:34, MED 50, localpref 100
AS path: 100 I
> to 10.0.8.2 via fe-0/1/1.0
If we were to flip this scenario around and break the link between Washington D.C. and Raleigh, we would see similar results.
Through the use of MED, we now understand how to manipulate the way the neighboring AS sees our route advertisements. MED
can be used to take advantage of links the local AS prefers and to balance inbound traffic patterns to an extent.

www.ebook-converter.com
Case Study 3: Load Balancing—Multipath and Multihop
JUNOS supports load balancing via three different methods:
1. EBGP load balancing using the multipath statement
2. IBGP load balancing using the multipath statement
3. EBGP load balancing using the multihop statement
We will cover the theory of each of these. This is an important topic due to the connected nature of most networks. Large-
enterprise networks have several connection points to the same or different ISPs, and ISPs themselves may have several
connection points to other peering ISPs.
Load balancing essentially means the sharing of multiple equal-cost paths over which to distribute outbound traffic. In Juniper
Networks routers, systems with the Internet Processor I ASIC can support up to 8 equal-cost paths, while systems with the
Internet Processor II ASIC can support up to 16 equal-cost paths.
To summarize, here are the three methods of load balancing:

Downloader demo watermarks

Load balancing across multiple links between ASs using EBGP multipath
Load balancing across multiple links within an AS using IBGP multipath
Load balancing across multiple links between ASs using EBGP multihop and static routes

414
 10. BGP Routing Case Studies
EBGP Multipath
The first method of load balancing across multiple links between ASs using EBGP multipath is probably the most common. This is
because you may have scenarios where you have either links going to more than one AS receiving equal-cost routing information,
or multiple links going to multiple routers in the same AS receiving equal-cost routing information. We will take a look at both of
these.
Figure 10-6 shows a simple topology where AS400 is advertising the 172.16.0.0/16 network to both AS200 and AS300. In
turn, AS200 and AS300 advertise the same route to AS100. Assuming the link to AS200 and AS300 from AS100 is the same
speed, and AS100 has no desire to manipulate any of the attributes, AS100 now has two equal-cost paths to network
172.16.0.0/16.

Figure 10-6. Load Balancing Across Multiple Links Between ASs Using EBGP Multipath Scenario 1
Our second scenario for load balancing across multiple links between AS is similar to what we have just seen. Figure 10-7 shows
our new topology. In this situation, we still have a network advertisement coming from AS200 of 172.16.0.0/16, but the
advertisement to AS100 is coming from two routers in AS200. If the policy in AS200 were to modify the MED value to try to
manipulate the way AS100 sees the route, then it would not be a truly equal-cost path. However, with policy, AS100 can make the

www.ebook-converter.com
advertisement look the same and implement load balancing.

Figure 10-7. Load Balancing Across Multiple Links Between ASs Using EBGP Multipath Scenario 2

IBGP Multipath

Downloader demo watermarks

Our next scenario consists of load balancing across multiple links within an AS using IBGP multipath. Typically, load balancing
within an AS is performed solely by the IGP. However, by using the multipath statement with our IBGP sessions, we can
change this characteristic and allow our load balancing to occur based upon BGP routes in conjunction with our IGP.
Figure 10-8 shows how IBGP, when used with the multipath statement, can provide equal-cost routing. In this scenario, router
Tokyo in AS100 is advertising NLRI for 10.10.0.0/16 to both routers San Francisco and Los Angeles, in AS200. In AS200, all
routers are peering via an IBGP full-mesh. When router Washington D.C. receives the route advertisement for 10.10.0.0/16,
415
 10. BGP Routing Case Studies
it receives the information twice; once with 172.16.0.1 for the NEXT_HOP, and once with 172.16.0.2 for the NEXT_HOP.

Figure 10-8. Load Balancing Using IBGP and the multipath Statement Scenario 3

Recalling our discussion on BGP route selection, all things being equal, BGP will install the route from the router with the lowest
RID. In this case router San Francisco has the lowest RID, so BGP will select the route to 10.10.0.0/16 via next-hop
172.16.0.1. When BGP does a recursive lookup for the route 172.16.0.1, it will find that there are two equal paths in the
IGP for 172.16.0.1: one via Atlanta and one via Dallas. In this case, Washington D.C. will forward any packets destined for
10.10.0.0/16 equally over the links between Washington D.C. to Atlanta and Washington D.C. to Dallas. This does not
present a serious problem, unless of course our goal is to provide as much equal distribution of traffic through our network as
possible. With the inclusion of the multipath statement, we can manipulate how BGP sees the 10.10.0.0/16 prefix and
provide equal distribution of traffic.
Let's now take a look at how Washington D.C. will view the routes with multipath enabled. When Washington D.C. receives the
two routes, one with a next-hop of 172.16.0.1 and the other with 172.16.0.2, it will install both routes into the routing
table. This is because the multipath statement allows BGP to install multiple routes in the routing table as long as they are
equal in cost. In this case, when Washington D.C. does a recursive lookup for 172.16.0.1 and 172.16.0.2, it will see that

www.ebook-converter.com
the IGP has equal-cost routes to both next-hop addresses. Thus, it will override the RID rule and allow both BGP routes to be
installed. When this occurs, Washington D.C. will distribute traffic for prefix 10.10.0.0/16 over all four links leading to the
border routers.
This scenario is probably one of the least commonly used, but it does illustrate how multipath can be used to take advantage of
equal-cost paths.

EBGP Multihop
This next scenario concerns load balancing between two EBGP peering routers with multiple links. Previously, it was mentioned
that peering between EBGP peers is typically done using the physical interface addresses. This works in general and is the best
way to peer (via EBGP) when only one link exists. However, we want to be able to take advantage of the multiple links that are
there primarily for resiliency.
For this scenario, take a look at Figure 10-9. The topology shows Washington D.C. in AS100 with three links to New York in
AS200. For ease of understanding, we will only refer to links A and B for the time being.

Downloader demo watermarks

416
 10. BGP Routing Case Studies

Figure 10-9. Load Balancing EBGP Using the multihop Statement

AS100 and AS200 want to peer with each other through Washington D.C. and New York, respectively. In a typical EBGP peering
scenario using only one link, we would create an EBGP session between Washington D.C. and New York using the physical
interface addresses. However, in this case we want to maintain a higher level of resiliency and take advantage of the multiple
links. Why? There are two reasons. The first is to take advantage of the link redundancy in case of link failure; the second is to
take advantage of the second link to load-balance traffic.
The easiest way to do this is to create an EBGP session between AS100 and AS200 by using the loopback interfaces of each
router. To do this, we need to address two issues: loopback interface routing and EBGP TTL.
In IBGP, we are able to peer between two routers using the loopback interface because we have an IGP running in our AS that

www.ebook-converter.com
knows about all internal interfaces to the AS and provides routing information to each router within the routing domain. Thus,
there is a logical connection. In this scenario, however, there is no IGP running between AS100 and AS200, and we do not want
one. In order for Washington D.C. to know about the loopback interface address on New York, we must configure a static route
to the loopback address via link A and link B. We do the same thing in New York. We create two static routes to Washington
D.C.'s loopback interface address via link A and link B. With this accomplished, each router can now see the other's loopback
interface.
The second issue we need to overcome is the EBGP TTL. In EBGP the TTL is set to 1, so you have basically one hop to create
your BGP session. Through the use of the multihop statement, we can increase our TTL to 2 and create an EBGP session
between loopback interfaces.
Now that we have addressed our connectivity issues, we can explain our ability to take advantage of the two characteristics
provided by the links: redundancy against failure and multiple links for load balancing.
For EBGP session redundancy, we are peering between the two loopback interface addresses on each router: Washington D.C.
and New York. If link A fails, the characteristics of TCP will allow our BGP EBGP peering session, which uses TCP as a
transport protocol, to remain up over link B. As for load balancing, our EBGP peering session is between loopback interfaces.
When AS100 receives routes from AS200, Washington D.C. (in AS100) will do its recursive lookup to the routing table. In the
routing table, we have two equal-cost static routes pointing to the loopback interface's address on New York, thereby giving our
router two equal-cost paths over which to route traffic.
Downloader demo watermarks
What about link C? If we were to add an additional link between the two peers, we would only have to add an additional static
route to each router pointing to the neighbor's loopback interface address.

Case Study 4: Scaling BGP

417
 10. BGP Routing Case Studies
Route Reflector
Figure 10-10 shows the topology we will implement. Typically you will not want to place your route-reflector server as a border
router for an AS. We have included this scenario so that route propagation can be understood easily. For this case study, we will
only implement one route-reflector server, and two route-reflector clients. AS100 is running OSPF area 0.0.0.0 on each of the
routers with passive interfaces on the external links.

Figure 10-10. Route-Reflector Case Study Topology

Now we will take a look at the configurations for this topology and detail what is going on. First, we will take a look at San
Francisco, Boston, and San Jose. These routers are external routers and are running only EBGP to AS100.
The configurations for San Francisco, Boston, and San Jose are nothing more than your typical EBGP peering sessions. Each one
of the routers is advertising a single prefix into BGP. We accomplish this by setting up a static route for our network to be
advertised under the routing-options hierarchy. We then export static-routes in the group EBGP hierarchy. The
first example shows the configuration for San Francisco.

www.ebook-converter.com
interfaces {
fe-0/1/1 {
unit 0 {
family inet {
address 10.0.16.1/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.16.1/32;
}
}
}
}
routing-options {
static {

Downloader demo watermarks

}
route 172.16.5.0/24 receive;

router-id 192.168.16.1;
autonomous-system 500;
}
protocols {

418
 10. BGP Routing Case Studies
bgp {
group EBGP {
type external;
export static-routes;
neighbor 10.0.16.2 {
peer-as 100;
}
}
}
}
policy-options {
policy-statement static-routes {
from protocol static;
then accept;
}
}
The Boston and San Jose configurations are identical, except for the advertising addresses. The next two examples show their
configurations.
The configuration for Boston is listed here:
interfaces {
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.29.1/24;
}
}
}
lo0 {

www.ebook-converter.com
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.28.1/32;
}
}
}
}
routing-options {
static {
route 172.16.6.0/24 receive;
}
router-id 192.168.28.1;
autonomous-system 600;
}
protocols {
bgp {
group EBGP {
type external;
export static-routes;

Downloader demo watermarks

}
neighbor 10.0.29.2 {

}
peer-as 100;

}
}
policy-options {
419
 10. BGP Routing Case Studies
policy-statement static-routes {
from protocol static;
then accept;
}
}
The configuration for San Jose is listed here:
interfaces {
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.50.1/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.20.1/32;
}
}
}
}
routing-options {
static {
route 172.16.7.0/24 receive;
}
router-id 192.168.20.1;
autonomous-system 700;

www.ebook-converter.com
}
protocols {
bgp {
group EBGP {
type external;
export static-routes;
neighbor 10.0.50.2 {
peer-as 100;
}
}
}
}
policy-options {
policy-statement static-routes {
from protocol static;
then accept;
}
}
When using route-reflector designs, each route reflector must be part of the AS's IBGP full-mesh. Next, we list the configuration

Downloader demo watermarks

for the nonclient IBGP peer in AS100, New York. New York is configured as a typical IBGP router. The peer session is set up on
the physical interfaces for this example. This does not impact routing in this topology.
interfaces {
fe-0/1/0 {
unit 0 {
family inet {
420
 10. BGP Routing Case Studies
address 10.0.29.2/24;
}
}
}
fe-0/1/1 {
unit 0 {
family inet {
address 10.0.24.2/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.24.1/32;
}
}
}
}
routing-options {
router-id 192.168.24.1;
autonomous-system 100;
}
protocols {
bgp {
group IBGP {
type internal;
local-address 192.168.24.1;
neighbor 192.168.2.1;
}

www.ebook-converter.com
group EBGP {
type external;
neighbor 10.0.29.1 {
peer-as 600;
}
}
}
ospf {
area 0.0.0.0 {
interface lo0.0;
interface fe-0/1/1.0;
interface fe-0/1/0.0 {
passive;
}
}
}
}
Until now, we have seen nothing more than typical BGP configurations. We did deviate from the typical loopback address peering
for the IBGP neighbors in this study.

Downloader demo watermarks

Now we will discuss our route reflector and the clients. Washington D.C. is the route reflector. We need to do two things to make
this topology successful. The first is to identify Washington D.C. as a route reflector by specifying the cluster ID in the BGP
configuration, and the second is to create the IBGP links between Washington D.C. and Denver and between Washington D.C.
and Atlanta. Owing to the nature of IBGP and the use of route reflectors to reduce the IBGP full-mesh problem, you will not see a
peering session between Denver and Atlanta.

421
 10. BGP Routing Case Studies
Washington D.C.'s configuration is listed below. The group RRCLIENTS contains the route-reflector configuration. We will be
using 192.168.2.1 as the cluster ID. This is also the loopback interface address and the RID. The cluster ID, you will recall, is
unique to each route-reflector cluster. It is used for loop detection. Essentially, a cluster will not accept routes that have its own
cluster ID in the prefix advertisement. In the [protocols bgp group RRCLIENT] hierarchy, we also specify our peers;
these will be Denver and Atlanta, our route-reflector clients.
interfaces {
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.2.1/24;
}
}
}
fe-0/1/1 {
unit 0 {
family inet {
address 10.0.24.1/24;
}
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.1.1/24;
}
}
}
fe-0/1/3 {
unit 0 {
family inet {

www.ebook-converter.com
address 10.0.50.2/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.2.1/32;
}
}
}
}
routing-options {
router-id 192.168.2.1;
autonomous-system 100;
}
protocols {
bgp {
group RRCLIENTS {

Downloader demo watermarks

type internal;
local-address 192.168.2.1;
cluster 192.168.2.1;
neighbor 192.168.0.1;
neighbor 192.168.5.1;
}

422
 10. BGP Routing Case Studies
group EBGP {
type external;
neighbor 10.0.50.1 {
peer-as 700;
}
}
group IBGP {
type internal;
local-address 192.168.2.1;
neighbor 192.168.24.1;
}
}
ospf {
area 0.0.0.0 {
interface all;
interface fe-0/1/3.0 {
passive;
}
}
}
}
This next example shows Denver's configuration. Denver is one of the two route-reflector clients. The configuration for the
peering session to the route reflection can be found under the [protocols bgp group RR] hierarchy. We also have Denver
injecting a route into the BGP protocol, so we can view what the route will look like in the routing tables. Denver also has an
external connection to AS500.
interfaces {
fe-0/1/1 {
unit 0 {
family inet {

www.ebook-converter.com
address 10.0.16.2/24;
}
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.1.2/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.0.1/32;
}
}
}
}

Downloader demo watermarks

routing-options {
static {
route 172.16.2.0/24 receive;
}
router-id 192.168.0.1;
autonomous-system 100;
}
423
 10. BGP Routing Case Studies
protocols {
bgp {
export static-routes;
group RR {
type internal;
local-address 192.168.0.1;
neighbor 192.168.2.1;
}
group EBGP {
type external;
neighbor 10.0.16.1 {
peer-as 500;
}
}
}
ospf {
area 0.0.0.0 {
interface lo0.0;
interface fe-0/1/2.0;
interface fe-0/1/1.0 {
passive;
}
}
}
}
policy-options {
policy-statement static-routes {
from protocol static;
then accept;
}
}

www.ebook-converter.com
Atlanta is the second route-reflector client. It only connects to Washington D.C. The configuration for Atlanta is below:
interfaces {
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.2.2/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.5.1/32;
}
}
}
}

}
Downloader demo watermarks
routing-options {
router-id 192.168.5.1;
autonomous-system 100;

protocols {
bgp {
group RR {
424
 10. BGP Routing Case Studies
type internal;
local-address 192.168.5.1;
neighbor 192.168.2.1;
}
}
ospf {
area 0.0.0.0 {
interface lo0.0;
interface fe-0/1/2.0;
}
}
}
Now that we have covered the configurations, we will take a look at how it all works together. The focus here is on Washington
D.C., Denver, and Atlanta. In this situation, Denver is advertising a route 172.16.2.0/24 to Washington D.C. Washington
D.C. will receive this route and advertise it, as it should, to the external peers, internal nonclient peers, and internal client peers.
This differs from what we are used to with IBGP. When normal IBGP rules apply, Washington D.C. would not readvertise the
prefix 172.16.2.0/24 to either Denver or New York. Since route reflection uses a relaxed rule set, the route-reflector server is
able to make the necessary advertisements, so that the route can be propagated properly throughout the AS. The following output
is of the show route 172.16.2.0 detail command. There is nothing significant here indicating that this is a reflector-
client relationship. However, Washington D.C. will now advertise this route to Atlanta, New York, and San Jose.
lab@DC> show route 172.16.2.0/24 detail
inet.0: 20 destinations, 20 routes (19 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.2.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Source: 192.168.0.1
Nexthop: 10.0.1.2 via fe-0/1/2.0, selected
Protocol Nexthop: 192.168.0.1 Indirect nexthop: 83784c8 63

www.ebook-converter.com
State: <Active Int Ext>
Local AS: 100 Peer AS: 100
Age: 11:44 Metric2: 10
Task: BGP_100.192.168.0.1+179
Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 4-Resolve inet.0
AS path: I
Localpref: 100
Router ID: 192.168.0.1
The next example is the same show route 172.16.2.0/24 detail from router New York. You can see that the
CLUSTER_LIST is 192.168.2.1. This is the cluster ID we assigned to the router Washington D.C. The Originator ID is
192.168.0.1. Router Washington D.C. adds the both of these to the prefix, before advertising it to another IBGP peer. If this
route were to somehow be advertised back into this same route-reflector cluster, the route reflector would see its own cluster ID
in this list and would not accept the advertisement. If the originator of a route receives a prefix with its RID as the Originator
ID of the prefix, the router will not accept the announcement.
lab@NewYork> show route 172.16.2.0/24 detail
inet.0: 18 destinations, 18 routes (17 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

Downloader demo watermarks

172.16.2.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Source: 192.168.2.1
Nexthop: 10.0.24.1 via fe-0/1/1.0, selected
Protocol Nexthop: 192.168.0.1 Indirect nexthop: 83784c8 47

425
 10. BGP Routing Case Studies
State: <Active Int Ext>
Local AS: 100 Peer AS: 100
Age: 12:40 Metric2: 20
Task: BGP_100.192.168.2.1+179
Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 2-Resolve inet.0
AS path: I <Originator>
Cluster list: 192.168.2.1
Originator ID: 192.168.0.1
Localpref: 100
Router ID: 192.168.2.1
The following example shows the output for show route 172.16.2.0 on Atlanta. It has the same type of results as the
nonclient peer.
lab@Atlanta> show route 172.16.2.0/24 detail
inet.0: 17 destinations, 17 routes (16 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.2.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Source: 192.168.2.1
Nexthop: 10.0.2.1 via fe-0/1/2.0, selected
Protocol Nexthop: 192.168.0.1 Indirect nexthop: 8378550 58
State: <Active Int Ext>
Local AS: 100 Peer AS: 100
Age: 15:40 Metric2: 20
Task: BGP_100.192.168.2.1+179
Announcement bits (2): 0-KRT 4-Resolve inet.0
AS path: I <Originator>
Cluster list: 192.168.2.1

www.ebook-converter.com
Originator ID: 192.168.0.1
Localpref: 100
Router ID: 192.168.2.1
Next, we will take a look at the routes that are advertised into AS100 from our external neighbors. Our next example shows the
routing table for New York, looking for prefix 172.16.6.0/24 from Boston. There is nothing unusual about this route
advertisement. It is a typical EBGP-advertised route. We will not show Washington D.C.'s table for this as there is no change in
the route. The next-hop is shown to be New York.
lab@NewYork> show route 172.16.6.0/24 detail
inet.0: 18 destinations, 18 routes (17 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.6.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Source: 10.0.29.1
Nexthop: 10.0.29.1 via fe-0/1/0.0, selected
State: <Active Ext>
Local AS: 100 Peer AS: 600

Downloader demo watermarks

Age: 1:39:19
Task: BGP_600.10.0.29.1+2948
Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 2-Resolve inet.0
AS path: 600 I
Localpref: 100
Router ID: 192.168.28.1

426
 10. BGP Routing Case Studies
Now we want to look at Denver's routing table. Here we see the Cluster list that was inserted by router Washington D.C.
and the Originator ID. The Originator ID is the border router that learned the external route—in this case, New York.
lab@Denver> show route 172.16.6.0/24 detail
inet.0: 18 destinations, 18 routes (17 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.6.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Source: 192.168.2.1
Nexthop: 10.0.1.1 via fe-0/1/2.0, selected
Protocol Nexthop: 10.0.29.1 Indirect nexthop: 8378550 46
State: <Active Int Ext>
Local AS: 100 Peer AS: 100
Age: 27:59 Metric2: 30
Task: BGP_100.192.168.2.1+1263
Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 4-Resolve inet.0
AS path: 600 I <Originator>
Cluster list: 192.168.2.1
Originator ID: 192.168.24.1
Localpref: 100
Router ID: 192.168.2.1
Next, we see the routing table in route San Francisco. Notice that the Cluster list and Originator ID fields are no
longer in the advertisement. This is because these attributes will not traverse outside the AS in which the route reflector resides.
lab@SanFrancisco> show route 172.16.6.0/24 detail
inet.0: 12 destinations, 12 routes (11 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

www.ebook-converter.com
172.16.6.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Source: 10.0.16.2
Nexthop: 10.0.16.2 via fe-0/1/1.0, selected
State: <Active Ext>
Local AS: 500 Peer AS: 100
Age: 31:29
Task: BGP_100.10.0.16.2+1383
Announcement bits (2): 0-KRT 1-BGP.0.0.0.0+179
AS path: 100 600 I
Localpref: 100
Router ID: 192.168.0.1
In this case study, we have seen the configuration necessary to implement route reflectors. We understand through this discussion
and our theory discussion in Section 9.5.1 how route reflectors can be used to scale BGP and further reduce the IBGP full-mesh
problem that can exist in large networks. We have also seen how loop-avoidance mechanisms are in place in route-reflector
scenarios, and how different announcements will affect which attributes will be passed to internal neighbors and external
neighbors. In the next case study, we will see how confederations can be used to scale BGP.

Downloader demo watermarks

Confederation
In this case study, we will configure a simple confederation topology. Figure 10-11 shows the topology we will be using for this
case study. We will look at the configuration for confederation BGP (CBGP) and how it can be used to scale your typical BGP
implementation. We will use AS100 for our “real world” AS. This AS comprises all sub-ASs or confederations. AS100 will consist
of three sub-ASs: 65501, 65504, and 65507. Remember in Section 9.1.2 our discussion of ASNs? We will be using ASNs from the
427
 10. BGP Routing Case Studies
private AS range. For the sake of ease, in this example we will not regionalize the IGP. However, we will use OSPF and multiple
areas. We will place the sub-AS boundary routers Washington D.C., Atlanta, and Denver in OSPF area 0.0.0.0 and each
sub-AS in its own area. Routers San Jose and Boston will be used as external peers to the AS100.

Figure 10-11. Confederation Case Study Topology

First, we will take a look at our configuration for the external neighbors to the confederation AS. We will begin by looking at the
configuration of San Jose in AS900. San Jose has an EBGP peering session with router San Francisco, which is in sub-AS 65507.
interfaces {
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.21.2/24;
}

www.ebook-converter.com
}
}
lo0 {
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.20.1/32;
}
}
}
}
routing-options {
router-id 192.168.20.1;
autonomous-system 900;
}
protocols {
bgp {
group EBGP {
type external;
neighbor 10.0.21.1 {

Downloader demo watermarks

}
}
}
peer-as 100;

}
Next, we have our configuration for AS300. Boston's configuration is similar to that of San Jose. In addition, Boston will be
428
 10. BGP Routing Case Studies
injecting a route for the 172.16.0.0/16 network, which we will be tracking during this case study.
Interfaces {
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.29.1/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.28.1/32;
}
}
}
}
routing-options {
static {
route 172.16.0.0/16 receive;
router-id 192.168.28.1;
autonomous-system 300;
}
protocols {
bgp {
group EBGP {
type external;
export static-routes;
neighbor 10.0.29.2 {

www.ebook-converter.com
peer-as 100;
}
}
}
}
policy-options {
policy-statement static-routes {
from protocol static;
then accept;
}
}
In the two previous configurations for San Jose and Boston, you will notice that the peer-as is AS100. This is because
ultimately the AS with the confederations will appear to the outside world as a single AS. We will see that a bit more when we see
the configurations for New York and San Francisco.
We will now look at our configuration for AS100. AS100 is our confederation AS and is comprised of three confederations, or
sub-ASs. The configuration for router New York is listed below. There exists a single EBGP connection between New York and
Boston. In the configuration for Boston, you will notice that under the [routing-options] hierarchy, we set the ASN to
65501. In addition, there is a statement reading confederation 100 members [ 65501 65504 65507 ]. The

Downloader demo watermarks

confederation statement lets the BGP configuration process know that ASs 65501, 65504, and 65507 are all part of AS100.
The global view of the AS will still be as AS100. Sub-AS 65501 consists of router Washington D.C. and New York. New York will
also have an IBGP peering session with Washington D.C. We are running OSPF area 0.0.0.1 internal to sub-AS 65501.
interfaces {
fe-0/1/0 {
unit 0 {
429
 10. BGP Routing Case Studies
family inet {
address 10.0.29.2/24;
}
}
}
fe-0/1/1 {
unit 0 {
family inet {
address 10.0.24.2/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.24.1/32;
}
}
}
}
routing-options {
router-id 192.168.24.1;
autonomous-system 65501;
confederation 100 members [ 65501 65504 65507 ];
}
protocols {
bgp {
group IBGP {
type internal;
local-address 192.168.24.1;

www.ebook-converter.com
neighbor 192.168.2.1;
}
group EBGP {
type external;
neighbor 10.0.29.1 {
peer-as 300;
}
}
}
ospf {
area 0.0.0.1 {
interface lo0.0;
interface fe-0/1/1.0;
interface fe-0/1/0.0 {
passive;
}
}
}
}

Downloader demo watermarks

The next example shows Washington D.C.'s configuration. Washington D.C., in sub-AS 65501, is configured to peer with the
other sub-ASs in the confederation AS100. Washington D.C. has a typical IBGP session with New York. Washington D.C. also
has two EBGP sessions: Atlanta and Denver. An important note about these EBGP sessions is that they still have the TTL 1
restriction tied to them. Even though in CBGP the handling of several attributes have been relaxed, the handling of this one has
not. In our case, we are peering between the physical interface IP addresses; therefore, the TTL limit of an EBGP session is not an
issue. However, if we were going to be using a more resilient topology where redundant links would exist between several core

430
 10. BGP Routing Case Studies
members or potential customers, the use of the multihop statement and loopback address peering would be recommended.
Peering with the use of the multihop statement is covered in the load-balancing case study in Section 10.3.
As mentioned earlier, we are running OSPF for our IGP. Between all the boundary routers, we are running area 0.0.0.0, and
within sub-AS 65501 we use area 0.0.0.1. Thus, we see our configuration for OSPF has interfaces fe-0/1/0 and fe-0/1/2
in area 0.0.0.0 and fe-0/1/1 in area 0.0.0.1.
interfaces {
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.2.1/24;
}
}
}
fe-0/1/1 {
unit 0 {
family inet {
address 10.0.24.1/24;
}
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.1.1/24;
}
}
}
lo0 {
unit 0 {

www.ebook-converter.com
family inet {
address 127.0.0.1/32;
address 192.168.2.1/32;
}
}
}
}
routing-options {
router-id 192.168.2.1;
autonomous-system 65501;
confederation 100 members [ 65501 65504 65507 ];
}
protocols {
bgp {
group IBGP {
type internal;
local-address 192.168.2.1;
neighbor 192.168.24.1;
}
group CEBGP {

Downloader demo watermarks

type external;
neighbor 10.0.1.2 {
peer-as 65507;
}
neighbor 10.0.2.2 {
peer-as 65504;
}
431
 10. BGP Routing Case Studies
}
}
ospf {
area 0.0.0.0 {
interface lo0.0;
interface fe-0/1/0.0;
interface fe-0/1/2.0;
}
area 0.0.0.1 {
interface fe-0/1/1.0;
}
}
}
The concepts for the remaining routers' configuration are the same as those we have just seen. We will now take a very quick look
at the configuration for sub-AS 65507. In the next example, you can see that Denver peers via EBGP with Washington D.C.
sub-AS 65501 and Atlanta sub-AS 65504. Interfaces fe-0/1/0 and fe-0/1/2 are in OSPF area 0.0.0.0, while fe-0/1/1
is in area 0.0.0.7.
interfaces {
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.0.1/24;
}
}
}
fe-0/1/1 {
unit 0 {
family inet {
address 10.0.16.2/24;

www.ebook-converter.com
}
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.1.2/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.0.1/32;
}
}
}
}
routing-options {

Downloader demo watermarks

router-id 192.168.0.1;
autonomous-system 65507;
confederation 100 members [ 65501 65504 65507 ];
}
protocols {
bgp {
group CEBGP {
432
 10. BGP Routing Case Studies
type external;
neighbor 10.0.1.1 {
peer-as 65501;
}
neighbor 10.0.0.2 {
peer-as 65504;
}
}
group IBGP {
type internal;
local-address 192.168.0.1;
neighbor 192.168.16.1;
}
}
ospf {
area 0.0.0.0 {
interface lo0.0;
interface fe-0/1/0.0;
interface fe-0/1/2.0;
}
area 0.0.0.7 {
interface fe-0/1/1.0;
}
}
}
San Francisco, as you can see next, has an IBGP session with Denver and an EBGP session with San Jose in AS900:
interfaces {
fe-0/1/0 {
unit 0 {

www.ebook-converter.com
family inet {
address 10.0.21.1/24;
}
}
}
fe-0/1/1 {
unit 0 {
family inet {
address 10.0.16.1/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.16.1/32;
}
}
}
}
Downloader demo watermarks
routing-options {
router-id 192.168.16.1;
autonomous-system 65507;
confederation 100 members [ 65501 65504 65507 ];
}
protocols {
433
 10. BGP Routing Case Studies
bgp {
group IBGP {
type internal;
local-address 192.168.16.1;
neighbor 192.168.0.1;
}
group EBGP {
type external;
neighbor 10.0.21.2 {
peer-as 900;
}
}
}
ospf {
area 0.0.0.7 {
interface lo0.0;
interface fe-0/1/1.0;
interface fe-0/1/0.0 {
passive;
}
}
}
}
Next is sub-AS 65504. Atlanta is the sub-AS boundary router and has EBGP peering sessions with Washington D.C. and Denver.
In addition, Atlanta takes part of an IBGP full-mesh within the sub-AS by peering with Dallas and Houston via IBGP. OSPF is
running in area 0.0.0.0 on interfaces fe-0/1/0 and fe-0/1/2. Area 0.0.0.4 is being used on interface fe-0/1/1.
interfaces {
fe-0/1/0 {
unit 0 {

www.ebook-converter.com
family inet {
address 10.0.0.2/24;
}
}
}
fe-0/1/1 {
unit 0 {
family inet {
address 10.0.8.1/24;
}
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.2.2/24;
}
}
}
lo0 {

Downloader demo watermarks

unit 0 {
family inet
address
address
{
127.0.0.1/32;
192.168.5.1/32;
}
}
}
434
 10. BGP Routing Case Studies
}
routing-options {
router-id 192.168.5.1;
autonomous-system 65504;
confederation 100 members [ 65501 65504 65507 ];
}
protocols {
bgp {
group CEBGP {
type external;
neighbor 10.0.2.1 {
peer-as 65501;
}
neighbor 10.0.0.1 {
peer-as 65507;
}
}
group IBGP {
type internal;
local-address 192.168.5.1;
neighbor 192.168.12.1;
neighbor 192.168.8.1;
}
}
ospf {
area 0.0.0.0 {
interface lo0.0;
interface fe-0/1/0.0;
interface fe-0/1/2.0;
}
area 0.0.0.4 {

www.ebook-converter.com
interface fe-0/1/1.0;
}
}
}
Dallas' configuration is shown next. Dallas is part of the IBGP full-mesh with Atlanta and Houston. OSPF area 0.0.0.4 is
running on interfaces fe-0/1/0 and fe-0/1/1.
interfaces {
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.13.2/24;
}
}
}
fe-0/1/1 {
unit 0 {
family inet {
address 10.0.8.2/24;

Downloader demo watermarks

}
}
lo0 {
}

unit 0 {
family inet {
address 127.0.0.1/32;
435
 10. BGP Routing Case Studies
address 192.168.12.1/32;
}
}
}
}
routing-options {
router-id 192.168.12.1;
autonomous-system 65504;
confederation 100 members [ 65501 65504 65507 ];
}
protocols {
bgp {
group IBGP {
type internal;
local-address 192.168.12.1;
neighbor 192.168.5.1;
neighbor 192.168.8.1;
}
}
ospf {
area 0.0.0.4 {
interface fe-0/1/1.0;
interface fe-0/1/0.0;
interface lo0.0;
}
}
}
Houston is running in the IBGP full-mesh with Atlanta and Dallas, and OSPF area 0.0.0.4 on interface fe-0/1/0.
interfaces {

www.ebook-converter.com
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.13.1/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.8.1/32;
}
}
}
}
routing-options {
router-id 192.168.8.1;

Downloader demo watermarks

}
autonomous-system 65504;
confederation 100 members [ 65501 65504 65507 ];
protocols {
bgp {
group IBGP {
type internal;
436
 10. BGP Routing Case Studies
local-address 192.168.8.1;
neighbor 192.168.5.1;
neighbor 192.168.12.1;
}
}
ospf {
area 0.0.0.4 {
interface lo0.0;
interface fe-0/1/0.0;
}
}
}
Now that we have covered the configurations for our topology, let's take a look at what is happening. First, we have router Boston
in AS300, advertising route 172.16.0.0/16 to the rest of the world. These networks are going to be used to gain a better
understanding of how confederation route advertisement occurs.
First, though, let's talk a little bit about our IGP implementation and how it fits into our topology. We are using OSPF for the IGP.
Area 0.0.0.0 consists of the sub-AS boundary routers, Washington D.C., Atlanta, and Denver. Within each sub-AS, we run a
different OSPF area. We could keep everything in area 0.0.0.0, but that would not help teach you about scaling. We want to
show you how you can set up an IGP to fit along with the topology.
Now we will want to take a look at how our route from Boston is being propagated throughout our AS. In the example below, we
see the show route 172.16.0.0/16 detail output from New York. This is a very typical looking route, learned via an
EBGP session. The next-hop is New York in AS300; the AS_PATH list is 300 I, which is normal. However, look at the Local
AS field; the value is 65501. Our peering session on Boston was set up to peer with AS100 though. Remember the
confederation and autonomous-system statements under the [routing-options] hierarchy? They take care of all
of the AS manipulation for us. Once it is defined in the configuration, we are done.
lab@ny> show route 172.16.0.0/16 detail

www.ebook-converter.com
inet.0: 26 destinations, 26 routes (24 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.0.0/16 (1 entry, 1 announced)

*BGP Preference: 170/-101
Source: 10.0.29.1
Nexthop: 10.0.29.1 via fe-0/1/0.0, selected
State: <Active Ext>
Local AS: 65501 Peer AS: 300
Age: 1:51:32
Task: BGP_300.10.0.29.1+3110
Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 2-Resolve inet.0
AS path: 300 I
Localpref: 100
Router ID: 192.168.28.1
Our next example shows us the output from Washington D.C., using the show route 172.16.0.0/16 detail command.
We see that the Local AS is 65501, and the Peer AS is 65501, as well. The AS_PATH list is still 300 I, which is exactly as it
should be.

Downloader demo watermarks

lab@dc> show route 172.16.0.0/16 detail
inet.0: 25 destinations, 25 routes (24 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.0/16 (1 entry, 1 announced)
*BGP Preference: 170/-101
437
 10. BGP Routing Case Studies
Source: 192.168.24.1
Nexthop: 10.0.24.2 via fe-0/1/1.0, selected
Protocol Nexthop: 10.0.29.1 Indirect nexthop: 83784c8 37
State: <Active Int Ext>
Local AS: 65501 Peer AS: 65501
Age: 1:56:29 Metric2: 20
Task: BGP_65501.192.168.24.1+1365
Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 2-Resolve inet.0
AS path: 300 I
Localpref: 100
Router ID: 192.168.24.1
Next, we take a look at Denver in sub-AS 65507. We see here that the AS path information looks a bit different. There is the
inclusion of our confederation information in the path listing. Notice that our next-hop has not changed. Even though we have
learned this route via an EBGP peering session, the next-hop rule is relaxed in the sense that it is maintained through the entire
AS. It is very important when scaling through the use of confederations to take care in IGP implementation. If for some reason we
were using different IGPs in sub-AS 65501 and 65507, and there was not a clean passing of route information between the two
IGPs, there would be potential for sub-AS 65507 not to be able to resolve the next-hop, rendering the route useless. With the way
we have our IGP (OSPF) configured in this case study, we allow for an unrestricted flow of routing information between the
different OSPF areas. If we were using a mixture of OSPF and IS-IS, and redistribution policies were not configured properly, we
might lose visibility of information that BGP needs to do a recursive lookup of the next-hop.
lab@denver> show route 172.16.0.0/16 detail
inet.0: 23 destinations, 23 routes (22 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.0/16 (1 entry, 1 announced)
*BGP Preference: 170/-101
Source: 10.0.1.1
Nexthop: 10.0.1.1 via fe-0/1/2.0, selected

www.ebook-converter.com
Protocol Nexthop: 10.0.29.1 Indirect nexthop: 83784c8 56
State: <Active Int Ext>
Local AS: 65507 Peer AS: 65501
Age: 2:11:32 Metric2: 3
Task: BGP_65501.10.0.1.1+179
Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 2-Resolve inet.0
AS path: (65501) 300 I
Localpref: 100
Router ID: 192.168.2.1
Our next example shows the routing table from Atlanta. Our concerns are the same as they were when looking at Denver. In
addition, we see that Atlanta has two routes to the destination 172.16.0.0/16. Because of the way confederations work with
next-hop, the next-hop is retained. This is a perfect example of some different routing information you may see.
Let's step through this. Atlanta receives a route for 172.16.0.0/16 from Washington D.C. and Denver. The path list from
Washington D.C. is AS path: (65501) 300 I. The path list from Denver is AS path: (65507 65501) 300 I. You
would naturally believe Denver was the longer path, but it's not in terms of how BGP sees it. Each path, in this case, consists of
valid AS_PATH information with ASNs and Confed_Sequence. Going back to our path-selection discussion in Section 9.5.2,
we know that Confed_Sequence is given a value of 0 when being evaluated. Thus, the resulting value of the AS_PATH
attribute from Washington D.C. and Denver is 1. Ultimately, the prefix advertisement is chosen based upon the RID. Denver

Downloader demo watermarks

happens to have a lower RID than Washington D.C., so the prefix advertisement from Denver is our active route.
What about the physical next-hop? It is 10.0.2.1. Let's take a look at the details. When using confederations, the next-hop
information is retained throughout the entire confederation AS. This means that the protocol next-hop—the next-hop that BGP
will do a recursive lookup on—is 10.0.29.1. When BGP on Atlanta looks at the 10.0.29.1 route in the IGP, it has a next-
hop of 10.0.2.1, which we already know is on Washington D.C.

438
 10. BGP Routing Case Studies
lab@Atlanta> show route 172.16.0.0/16 detail
inet.0: 23 destinations, 23 routes (22 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.0/16 (2 entries, 1 announced)
*BGP Preference: 170/-101
Source: 10.0.0.1
Nexthop: 10.0.2.1 via fe-0/1/2.0, selected
Protocol Nexthop: 10.0.29.1 Indirect nexthop: 83784c8 23
State: <Active Int Ext>
Local AS: 65504 Peer AS: 65507
Age: 2:21:27 Metric2: 30
Task: BGP_65507.10.0.0.1+179
Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 4-Resolve inet.0
AS path: (65507 65501) 300 I
Localpref: 100
Router ID: 192.168.0.1
BGP Preference: 170/-101
Source: 10.0.2.1
Nexthop: 10.0.2.1 via fe-0/1/2.0, selected
Protocol Nexthop: 10.0.29.1 Indirect nexthop: 83784c8 23
State: <NotBest Int Ext>
Inactive reason: Router ID
Local AS: 65504 Peer AS: 65501
Age: 2:21:29 Metric2: 30
Task: BGP_65501.10.0.2.1+1309
AS path: (65501) 300 I
Localpref: 100
Router ID: 192.168.2.1

www.ebook-converter.com
The following output is the show route 10.0.29.1 command showing the next-hop as 10.0.2.1.
lab@Atlanta> show route 10.0.29.1

inet.0: 23 destinations, 23 routes (22 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both
10.0.29.0/24 *[OSPF/10] 02:34:27, metric 30
> to 10.0.2.1 via fe-0/1/2.0
Last, we will look at the routing table for San Jose for our advertised prefix of 172.16.0.0/16. The AS path list is right on
target for our topology. Our next-hop is 10.0.21.1, which is the EBGP peer from which we learned the route.
lab@sj> show route 172.16.0.0/16 detail
inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden)
172.16.0.0/16 (1 entry, 1 announced)
*BGP Preference: 170/-101
Source: 10.0.21.1
Nexthop: 10.0.21.1 via fe-0/1/0.0, selected

Downloader demo watermarks

State: <Active Ext>
Local AS:
Age: 2:47:38
900 Peer AS:

Task: BGP_100.10.0.21.1+179
100

Announcement bits (2): 0-KRT 1-BGP.0.0.0.0+179

AS path: 100 300 I
Localpref: 100
439
 10. BGP Routing Case Studies
Router ID: 192.168.16.1
This study has looked at the basic concept of confederations and how to implement them. It has also talked about how route
information is propagated through a confederation and discussed some of the differences. The use of confederations is
recommended when scaling BGP as it offers the greatest flexibility and truly scalable functionality.

Aggregation
In this case study, we will show how to perform route aggregation in JUNOS. We will use the topology shown in Figure 10-12.
The purpose of this case study is to show how aggregation occurs and to configure it in JUNOS. First, we will discuss the topology
as this will provide insight into aggregation for those unfamiliar with it.

www.ebook-converter.com
Figure 10-12. Route-Aggregation Case Study Topology
In this scenario, we have two routers that will be providing feeder routes: Boston and Dallas. Boston will announce networks
172.16.0.0/24 and 172.16.1.0/24, and Dallas will announce 172.16.2.0/24 and 172.16.3.0/24. The purpose of
this is to provide routes for New York to aggregate. In this study, aggregation is configured such that New York announces the
aggregate of 172.16.0.0/22 only if there is a contributing route in its own routing table.
The first two examples below show the configurations for Boston and Dallas, respectively. These are pretty basic and are only
used to get the routes into BGP. All of the routers in AS200 are in the IBGP mesh and use OSPF for the IGP.
routing-options {
static {
route 172.16.0.0/24 receive;
route 172.16.1.0/24 receive;
}
autonomous-system 200;

Downloader demo watermarks

}
protocols {
bgp {
group ibgp {
type internal;
local-address 3.3.3.3;
export static-routes;
440
 10. BGP Routing Case Studies
neighbor 2.2.2.2;
neighbor 5.5.5.5;
}
}
}
policy-options {
policy-statement static-routes {
from protocol static;
then accept;
}
}
routing-options {
static {
route 172.16.2.0/24 receive;
route 172.16.3.0/24 receive;
}
autonomous-system 200;
}
protocols {
bgp {
group ibgp {
type internal;
local-address 5.5.5.5;
export static-routes;
neighbor 2.2.2.2;
neighbor 3.3.3.3;
}
}
}
policy-options {

www.ebook-converter.com
policy-statement static-routes {
from protocol static;
then accept;
}
}
Next is the configuration for New York. This is where the aggregation will occur. New York receives the routes from Boston and
Dallas. The aggregate route is configured under the [routing-options] hierarchy. The active parameter tells JUNOS to
keep the route active only if there is a contributing route. We can force the route to stay in the table, but for now that is not
necessary.
Policy plays a major role here though. In the policy-statement announce, the term pass-agg tells JUNOS to filter on
the aggregate with which we are concerned. It is possible to have multiple aggregates for different address spaces defined,
especially on AS boundary routers; therefore, specifying the exact match criteria proves to be beneficial in exporting the correct
route. The second portion of the policy, the term filter-more-specific, tells JUNOS to filter the more specific routes and
reject them. This accomplishes our goal for getting the aggregate route advertised. There are times when you may wish to leak the
more specific routes, perhaps to influence traffic flow to a particular network. Leaking more specific route information can be a
useful way to attract more inbound traffic from a given upstream provider, as well. Either way, the more specific the information
advertised, the higher the risk of route flaps during unstable conditions. The tradeoff can only be measured on a case-by-case
basis.
Downloader demo watermarks
routing-options {
aggregate {
route 172.16.0.0/22 active;
}
autonomous-system 200;

441
 10. BGP Routing Case Studies
}
protocols {
bgp {
group ibgp {
type internal;
local-address 2.2.2.2;
neighbor 3.3.3.3;
neighbor 5.5.5.5;
}
group ebgp {
type external;
export announce;
neighbor 10.0.24.1 {
peer-as 100;
}
}
}
}
policy-options {
policy-statement announce {
term pass-agg {
from {
protocol aggregate;
route-filter 172.16.0.0/22 exact;
}
then accept;
}
term filter-more-specific {
from {
route-filter 172.16.0.0/22 longer;
}

www.ebook-converter.com
then reject;
}
}
}
Next, we want to take a look at the routing table for Washington D.C. This is more to prove the theory of operation than anything
else. This next example shows the routing table prior to the aggregate-route policy being invoked.
lab@DC> show route protocol bgp
inet.0: 14 destinations, 14 routes (13 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.0/24 *[BGP/170] 00:18:06, localpref 100
AS path: 200 I
> to 10.0.24.2 via fe-0/1/1.0
172.16.1.0/24 *[BGP/170] 00:18:06, localpref 100
AS path: 200 I
> to 10.0.24.2 via fe-0/1/1.0
172.16.2.0/24 *[BGP/170] 00:18:06, localpref 100

Downloader demo watermarks

172.16.3.0/24
AS path: 200 I
> to 10.0.24.2 via fe-0/1/1.0
*[BGP/170] 00:18:06, localpref
AS path: 200 I
100

> to 10.0.24.2 via fe-0/1/1.0

Once we implement our announce policy on New York, we see that the /24 addresses are replaced with the less specific
442
 10. BGP Routing Case Studies
aggregate of 172.16.0.0/22.
lab@DC> show route protocol bgp

inet.0: 11 destinations, 11 routes (10 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both

172.16.0.0/22 *[BGP/170] 00:06:51, localpref 100

AS path: 200 I
> to 10.0.24.2 via fe-0/1/1.0
Our next example shows what happens when we remove our four contributing routes from Boston and Dallas. When we do this,
we no longer see the aggregate in the routing table of Washington D.C.
lab@DC> show route protocol bgp

inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both
You have now seen the basic process of creating and advertising aggregate routes. Earlier in this case study, we filtered all
contributing routes and advertised the aggregate only. This is acceptable, but some domains may wish to leak more specific route
information for a given network or block of networks to influence inbound traffic. Since there are times when aggregation
suppresses detailed information about a prefix, you may choose to let a more specific route, with your detailed path attributes,
leak through.
This next example will now show you how to let this route slip through, along with the aggregate, looking at New York and the
table in Washington D.C. Notice the new addition to the policy-statement announce. The route-filter 172.16.3.0/24
exact accept statement will allow the one single route to pass, while the next statement will reject all of the other contributing
routes.
policy-statement announce {

www.ebook-converter.com
term pass-agg {
from {
protocol aggregate;
route-filter 172.16.0.0/22 exact;
}
then accept;
}
term specific-pass-filter {
from {
route-filter 172.16.3.0/24 exact accept;
route-filter 172.16.0.0/22 orlonger;
}
then reject;
}
}
Next you can see Washington D.C.'s routing table, which proves our concept.
lab@DC> show route protocol bgp

Downloader demo watermarks

inet.0: 12 destinations, 12 routes (11 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.0.0/22 *[BGP/170] 00:18:24, localpref 100

AS path: 200 I
> to 10.0.24.2 via fe-0/1/1.0
172.16.3.0/24 *[BGP/170] 00:02:26, localpref 100
443
 10. BGP Routing Case Studies
AS path: 200 I
> to 10.0.24.2 via fe-0/1/1.0
In addition to using contributing routes, we can configure JUNOS to send an aggregate route, even when no contributing routes
exist. We accomplish this by using the passive statement when configuring our aggregate route under the [routing-
options] hierarchy. The following example shows the configuration necessary to accomplish this:
routing-options {
aggregate {
route 172.16.0.0/22 passive;
}
autonomous-system 200;
}
protocols {
bgp {
group ebgp {
type external;
export announce;
neighbor 10.0.24.1 {
peer-as 100;
}
}
}
}
policy-options {
policy-statement announce {
term pass-agg {
from {
protocol aggregate;
route-filter 172.16.0.0/22 exact;
}

www.ebook-converter.com
then accept;
}
term filter-more-specific {
from {
route-filter 172.16.0.0/22 longer;
}
then reject;
}
}
}
This concludes our case study on aggregate routes. You should now understand the basic concept of aggregation and how to
configure it in JUNOS. Remember, when configuring aggregates, take into account the effect you will be having on any subset of
routes that fall under the aggregate. Aggregation, while a useful tool, can cause undesired results if not implemented properly.

Chapter Summary
As this chapter comes to a close, so does this book's discussion of BGP and interdomain routing. The case studies in this chapter
are a foundation for further exploration into the BGP protocol and JUNOS implementation.

Downloader demo watermarks

This chapter discussed path selection and a few of the methods BGP uses to select an active path such as Router ID and
AS_PATH. It also examined some of the more common advanced features of path selection through the use and manipulation of
AS_PATH prepending, LOCAL_PREF, MED, and NEXT_HOP. It has shown how BGP scaling can be used to make our
administration of a large BGP network easier. The use of route reflectors can eliminate the IBGP full-mesh problem. The use of
confederations can conquer not only the IBGP full-mesh problem, but also scale IGP and BGP domains into smaller more
manageable domains.
444
 10. BGP Routing Case Studies
Lastly, you should have an understanding of route aggregation. Aggregation can be used to simplify prefix advertisement. With
aggregation you can reduce the potential for route flaps throughout the network and give attention to specific routes that have
certain characteristics that need to be passed directly to upstream neighbors.

www.ebook-converter.com

Downloader demo watermarks

445
 11. Defining and Implementing Routing Policies
Chapter 11. Defining and Implementing Routing Policies
This chapter aims to give you an understanding of routing policies and how they are implemented on the Juniper
Networks M-Series routers. It begins by outlining what a routing policy is and where routing policy can be found in
today's Internet. Routing policy specification language (RPSL) is then discussed with examples of RPSL objects and what
they mean. After this theoretical introduction on routing policy, the application of policy in the JUNOS environment is
reviewed along with a routing-policy design model called the designing, implementing, executing, and testing (DIET)
policy method. The chapter ends with a look at some more advanced topics, such as route filtering, BGP regular
expressions, and community attribute matching.
The chapter gives the beginner a firm foundation for grasping the fundamentals of routing-policy creation, while
providing more in-depth knowledge for the advanced user. This knowledge can then be used to ensure that the routes
coming into and out of your ISP or corporate network conform to predefined rules for the exchange of these routes at
peering points. The methodology and ideas in this chapter do not pertain solely to Juniper Networks routers. No matter
what types of routers are deployed in your network, you will still need to configure some sort of policy, and for this, the
concepts presented here are still valid.

Routing Policy Overview

Routing policy can be described as a set of rules governing the interaction of protocols and the way in which routes are
exchanged on a router. It could be said that it is protocol for protocols, if you will excuse the pun. Routing policy is one
of the most important areas of a router's configuration, especially when it comes to defining external peering relationships
with other routers at an interautonomous system level. There are many reasons to implement a set of rules in the form of
a routing policy. Primarily, policy is necessary to control the following:
Incoming routing information before it is stored in a routing table
Routing information sent out from the routing table to other routers

www.ebook-converter.com
Hence, there are two types of routing policies that reflect control over incoming and outgoing routing information:
1. Import policy—. contains criteria governing routing information entering the routing table as it is received from
another protocol or neighbor
2. Export policy—. contains criteria governing route information leaving the routing table either to be sent to a
neighboring router or redistributed to another protocol
Figure 11-1 illustrates these policies. INET's router receives routes from Telco123's autonomous system boundary router,
but before the routes are put in the routing table, they are passed through whatever input policies have been configured
on INET's autonomous system boundary router.

Downloader demo watermarks

Figure 11-1. Import and Export Policies
446
 11. Defining and Implementing Routing Policies
Note
Routing policy is defined on a per-AS basis as much as on a per-router basis. Although there may be differing
configurations on different routers in an AS, they work together to express an AS's routing policy.
The routes that pass through the input policies are then stored in the inbound routing table of INET's router. This inbound
table is normally referred to as adj-rib-in. On the outgoing side of INET's autonomous system boundary router, the
router peers with two more routers within the INET network. The routes that get passed to these ISPs are first subjected
to whatever export policies have been configured on INET's router. This outbound routing table that passes the export
policy is commonly referred to as adj-rib-out.
A routing policy is also an important way of enforcing a contractual agreement between an ISP and a customer or
between a smaller and a larger ISP. As illustrated in Figure 11-2, we can see that there are several smaller companies
attached to the INET AS. Each one of these companies will likely have different routing requirements, and therefore, a
different policy must be applied to each.

Figure 11-2. Policy Applied to Routes Coming into a Large ISP from Smaller ISPs

www.ebook-converter.com
Policies can be used to establish a list of trusted systems that you will allow updates from. They give a high degree of
control over what information is passed to and from a router's routing tables, and they serve in an administrative capacity
where route parameters, such as metric and preference, can be modified.
For example, in Juniper Networks M-Series routers, regular expressions and BGP route flap damping (both of which will
be covered in this chapter) are implemented in JUNOS through routing policies. Tools such as these assist a network
engineer in providing optimum stability in a network and ensure that the routing information passing between routers is
expressly permitted. This is where policy comes into its own as a policing tool.
To ensure that policies can be applied on routers from different manufacturers, RPSL was created. Operators use this
language to share knowledge with other engineers about what policies are applied to each other. The following section
examines RPSL in more detail.

RPSL
In 1999 RPSL was designed to replace RIPE-181 [16], the first common language widely deployed in the Internet for
routing-policy definition. A new language was needed because operators found it hard to express policies used in practice

Downloader demo watermarks

in the RIPE policy language. As a result, RPSL was developed and released by the IETF Routing Policy System Working
Group.
A common RPSL has been defined in RFC 2622 [2], a proposed standard as of the time of this writing. Before we talk
about RPSL, it is important to understand where the language originated and the role played by a group called the
Internet Routing Registry (IRR, www.irr.net), a collection of databases made up of routing policies from a number of
447
 11. Defining and Implementing Routing Policies
international participants. The idea behind the IRR was to provide a central repository for routing and addressing
information. The IRR was originally made up of five registries and today consists of about 50 members, including
operators such as Verio, Cogent (formerly Netrail), and Level 3, who each run their own registries.
These registries register routing policies from different operators in databases that are synchronized with each other
several times a day. Among these databases are the Route Arbiter Database (RADB) registry in the United States, and the
RIPE registry in Europe. What sets these registries apart is that they are both public registries in which any ISP can
publish its policies. It is recommended that ISPs publish their policies with a single registry as registering with multiple
registries can lead to inconsistencies when the databases synchronize.
Objects registered in the IRR can be queried using the UNIX whois command, which is an Internet domain name and
network number directory service query tool. The general usage for the whois command is as follows:
whois [-adptr][-h host] name
[-adptr] has two options:
-a for the American Registry for Internet Numbers (ARIN) database
–d for the US military Defense Data Network (DDN)
[-h host] has two options:
-p to use the Asia Pacific Network Information Center (APNIC) database
-r to use the Réseaux IP Européens (RIPE) database
If no options are specified, the command searches the default network information center (NIC),
whois.internic.net, which is the central repository. A whois query is normally performed for a real Internet
address. However, for the purposes of this book, we will use a private network address and private ASNs as defined by
RFC 1918 [6] and RFC 1930 [7], respectively, so as not to infringe on any public IP address space or AS space. Private
addresses will suffice for demonstration purposes.
The following is an example of a whois query of the RIPE database -r for the network 192.168.4.0:

www.ebook-converter.com
UnixServer> whois -r 192.168.4.0
% This is the RIPE Whois server.
% The objects are in RPSL format.
% Please visit www.ripe.net/rpsl for more information.
% Rights restricted by copyright.
% See www.ripe.net/ripencc/pub-services/db/copyright.html
inetnum: 192.168.4.0 - 192.168.7.255
netname: customer1-net
descr: Telco123
descr: Unit 30a
descr: Littletown
country: Ireland
admin-c: XX3241-RIPE
tech-c: ABEC1-RIPE
rev-srv: ns1.ec.abxy.net
rev-srv: ns2.ec.abxy.net
status: ASSIGNED PA
mnt-by: INETEC-MNT
Downloader demo watermarks
changed:
source:
[email protected] 19991217
RIPE
route: 192.168.0.0/19
descr: INET EC Block 4
origin: AS65535
448
 11. Defining and Implementing Routing Policies
mnt-by: INETEC-MNT
changed: [email protected] 19980513
changed: [email protected] 19990929
source: RIPE
role: INET Ireland IP-oper
address: INET – An Internet Company
address: bigstreet
address: Dublin
address: Ireland
phone: +353 99 233445
fax-no: : +353 99 233446
e-mail: [email protected]
trouble: [email protected]
admin-c: ANR13-RIPE
admin-c: OC855-RIPE
tech-c: BMS13-RIPE
tech-c: AND9-RIPE
tech-c: LBST4-RIPE
tech-c: EHU1-RIPE
tech-c: LBUJ1-RIPE
nic-hdl: BNEC1-RIPE
remarks: --------------------------------------------------------
remarks: For complaints about abusive/malicious behavior
remarks: please contact one of the following addresses:
remarks: E-mail abuse(SPAM/UCE): [email protected]
remarks: USENET/Newsgroup abuse: abuse-news@INET
remarks: Security/hacking/etc : [email protected]
remarks: All other issues : [email protected]
remarks: --------------------------------------------------------

www.ebook-converter.com
remarks: *** IF ABUSE IS GOING ON AT THIS VERY MOMENT ***
remarks: *** PLEASE CALL 919-555-1212,OPTION 2,3,1 Ask for RORO *
remarks: --------------------------------------------------------
notify: [email protected]
notify: [email protected]
mnt-by: INETEC1-MNT
changed: [email protected] 20010429
changed: [email protected] 20010602
source: RIPE

person: I. M. Responsible
address: Unit 30a
address: a street, Littletown
address: Ireland
phone: +353 11 361921
fax-no: +353 11 361736
e-mail: [email protected]
nic-hdl: XC6541-RIPE
mnt-by: INETEC1-MNT
Downloader demo watermarks
changed:
source:
lcr@19990416
RIPE
Table 11-1 describes the less intuitive fields returned from the previous whois network query.
More information about these fields can be obtained from www.ripe.net/ripe/docs/databaseref-manual.html.
449
 11. Defining and Implementing Routing Policies
Table 11-1. whois Network Query Fields

Field
Information Displayed
Name
inetnumThe Internet address. In this example, 192.168.4.0 is actually part of an address space ranging from
192.168.4.0 to 192.168.7.255.
netnameThe name of the network. In this example, 192.168.4.0 is called customer1-net.
descr Who the network belongs to and where the company is located.
route Which block the range is from. In this example, the range is part of the 192.168.0.0/19 block.
mnt-by The name of the company that maintains the network.
changedAll changes to the entry, including when it was last changed and the e-mail address of the person who changed
it.
admin-cAdministrative contacts.
tech-c Technical contacts.
nic-hdlThe NIC handle.
remarksOptional fields for an operator to provide extra information.

If you do not have access to a UNIX box, then whois queries can be performed over the Web at numerous Web sites,
the main ones being the following:
RIPE—www.ripe.net/perl/whois
APNIC—www.apnic.org/apnic-bin/whois2.pl
InterNIC—www.internic.org/whois.html
Note that RPSL is not a router configuration language. It is an object-oriented language that permits the generation of a
router configuration from the description of a router combined with the description of an AS.

www.ebook-converter.com
When policy objects are registered in the IRR, they can also be queried using the whois service. Any public ASN in the
range of 1 to 64,511 can be queried. The block of ASNs from 64,512 to 65,535 are reserved for private use as defined in
RFC 1930. In the following example, we can see how the whois command can be adopted to query an entire AS. This
is, of course, a private ASN, but imagine the depth of publicly available data that is obtainable through a public AS query.
unixserver> whois -r as65535
% This is the RIPE Whois server.
% The objects are in RPSL format.
% Please visit www.ripe.net/rpsl for more information.
% Rights restricted by copyright.
% See www.ripe.net/ripencc/pub-services/db/copyright.html

as-block: AS64512 – AS65535

descr: RIPE NCC ASN block
remarks: These AS numbers are further assigned by RIPE NCC
remarks: to LIRs and end-users in the RIPE NCC region
remarks: Please refer to RIPE Document ripe-185
remarks: and RIPE Document ripe-147
Downloader demo watermarks
admin-c:
tech-c:
mnt-by:
MM45-RIPE
OPT5-RIPE
RIPE-NCC-TT-MNT
mnt-lower: RIPE-NCC-TT-MNT
changed: [email protected] 20010526
source: RIPE
450
 11. Defining and Implementing Routing Policies
aut-num: AS65535
as-name: UNSPECIFIED
descr: Telecommunications 123 Ltd
descr: Unit 30a
descr: A street, Littletown
descr: Ireland
import: from AS65534
action pref=100;
accept ANY AND NOT {0.0.0.0/0}
export: to AS65534
announce AS-TELCO123
import: from AS65533
action pref=100;
accept ANY AND NOT {0.0.0.0/0}
export: to AS65533
announce AS- AS-TELCO123
import: from AS65532
action pref=100;
accept ANY AND NOT {0.0.0.0/0}
export: to AS65532
announce AS- AS-TELCO123
import: from AS65531
action pref=100;
accept ANY AND NOT {0.0.0.0/0}
export: to AS65531
announce AS- AS-TELCO123
import: from AS65530
action pref=100;

www.ebook-converter.com
accept ANY AND NOT {0.0.0.0/0}
export: to AS65530
announce AS- AS-TELCO123
admin-c: ACBN1-RIPE
tech-c: ACBN1-RIPE
tech-c: ADAM1-RIPE
mnt-by: TELCO123-MNTNR
notify: [email protected]
changed: [email protected] 19990921
changed: [email protected] 20011014
source: RIPE
role: RIPE NCC Operations
address: OP Centre
address: BigCity
address: EC-Country
phone: +11 21 545 4321
fax-no: +11 21 545 4323
e-mail: [email protected]
Downloader demo watermarks
admin-c:
admin-c:
tech-c:
JMSD1-RIPE
DEL132-RIPE
DEL132-RIPE
tech-c: LX627-RIPE
tech-c: GM8331-RIPE
tech-c: MBLI3-RIPE
451
 11. Defining and Implementing Routing Policies
tech-c: DL785-RIPE
tech-c: EQ4727-RIPE
tech-c: DN11627-RIPE
tech-c: MDS4-RIPE
tech-c: PW3458-RIPE
tech-c: JLSE2-RIPE
tech-c: LI2176-RIPE
nic-hdl: OPT5-RIPE
mnt-by: RIPE-NCC-MNT
changed: [email protected] 19991208
changed: [email protected] 20000803
changed: [email protected] 20001101
changed: [email protected] 20010308
changed: [email protected] 20010622
source: RIPE

person: Adam Contact

address: Telco 123
address: 3rd Floor
address: Unit 30a
address: A street, Little Town
address: Ireland
phone: +353 11 21 8917 4621
fax-no: +353 11 20 8917 4623
e-mail: [email protected]
nic-hdl: ADAM1-RIPE
notify: [email protected]
changed: [email protected] 20000519
changed: [email protected] 20010329

www.ebook-converter.com
source: RIPE
person: RIPE Engineer
address: RIPE Network Coordination Centre (NCC)
address: OP Centre
address: BigCity
address: EC-Country
phone: +11 21 545 4321
fax-no: +11 21 545 4323
nic-hdl: MM43-RIPE
mnt-by: RIPE-NCC-HM-MNT
changed: [email protected] 20000805
changed: [email protected] 20010615
source: RIPE
In the example shown, a whois query is performed on AS 65535. Remember that this ASN belongs to INET. Most of the
fields contained in the output from the previous whois command are present here again.
The main fields we are concerned with here are the as-block, aut-num, as-name, import, and export fields.
Downloader demo watermarks
The as-block field tells us that AS 65535 belongs to a block of ASNs ranging from 64,512 to 65,535. The aut-num
field is the ASN that we queried. In this case, the AS is not named as the as-name field has returned a value of
UNSPECIFIED.
The import and export fields display the policies applied by AS 65535 on incoming and outgoing routes, respectively.
In the first set of import and export fields, you can see that AS 65535 has a policy in place to accept any route from
452
 11. Defining and Implementing Routing Policies
AS 65534 as long as it is not a default route:
import: from AS65534
action pref=100;
accept ANY AND NOT {0.0.0.0/0}
export: to AS65534
The above excerpt describes the policy rules that AS 65535 has set for its peering interaction with AS 65534. We see that
on the import side from AS 65534, AS 65535 sets the preference value to 100. AS 65535 will accept all routes, except the
default 0.0.0.0/0 route. On the outgoing side, the export policy merely states that AS 65535 is to announce its
presence to AS 65534. This is an example of a typical policy entry in the RADB.
RFC 2650 [3], “Using RPSL in Practice,” is an informational RFC that fully describes the IRR and RPSL. There are a
number of tools available today to enable a routing configuration to be developed from information stored in the IRR.
One collection of tools is RAToolSet, which includes a configuration generator called Rtconfig that supports
configuration generation for Cisco, Juniper Networks, Nortel, Gated, and RSd routers with BGP policies. More
information on the RAToolSet can be found on the University of California Web site at www.isi.edu/ra/RAToolSet.

Structure of JUNOS Routing Policy Language

The JUNOS policy language is very similar to a programming language in the way the configuration is laid out and how it
can be subdivided into modules. Individuals familiar with programming will see that JUNOS policy configurations are
similar in layout to Pascal or C programs. The same parsing rules apply for curly braces ({ ) and semicolons (;) in JUNOS
as they do in the aforementioned programming languages.
The most important aspect of using any good programming language is its implementation. The same can be said of the
JUNOS policy language. Policies can be broken down into modules with specific actions; this makes the language very
scalable and adaptable to the needs of today's large networks.

www.ebook-converter.com
Policy definition is carried out in configuration mode at the [edit policy-options] level of the JUNOS CLI.
Policies are defined by using the policy-statement command as follows:
[edit]
user@SanFrancisco# edit policy-options
[edit policy-options]
root@SanFran# set policy-statement policyname ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
> from Conditions to match a route's source
> term Policy term
> then Actions to take if 'from' and 'to' conditions match
> to Conditions to match a route's destination
After naming a policy, as shown above, you have the option of creating terms or defining a simple policy without terms.
The same concepts for configuration development presented in Section 6.3 on firewall filters apply here. Each policy
consists of zero or more terms with each term consisting of match conditions specified using a from or to statement and

Downloader demo watermarks

match actions specified using a then statement. If no terms are specified, match conditions and match actions are
specified at the policy level only. An analogy to this would be a computer program consisting of subroutines with if …
then … else statements. The computer program represents the policy, and the subroutines are the individual terms
within the policy.
In a from statement, a match condition is specified to correspond to one or more routes received from neighbors,
453
 11. Defining and Implementing Routing Policies
adjacencies, peers, or a specific protocol.
In a to statement, a match condition is specified to match against one or more routes being advertised from the
routing table destined for neighbors, adjacent routers, peers, or a specific routing protocol.
In a then statement, the actions to be taken once a match is made are specified.
Multiple routing policies can be combined to create a policy chain, which uses an ordered list of policies. In a policy
chain, each link is a predefined policy. This is a very efficient way of developing complex policies by reusing predefined
policies instead of creating longer and more complex ones. The chain of match conditions is stopped once an accept or
reject match action is reached in any of the policies.
Why would we want to use a chain as opposed to a single policy with multiple terms? Policy chains can assist in
optimizing smaller, more concise configurations by restricting common elements to specific policies and reusing those
policies instead of re-creating them. A good example of this would be a policy to reject inbound default routes and
private addresses from an external AS. This type of policy could be applied to BGP neighbors at the beginning of a chain.
The remaining policies included in the chain could apply to specific BGP groups or neighbors. More examples of policy
chains are discussed in subsequent sections of this chapter and are shown in Figure 11-3.

Figure 11-3. Rating Policy Chain

Default Routing Policy Actions

www.ebook-converter.com
Each routing protocol has a certain default action that it performs when a routing policy is applied to it. As we have
discussed there are both import and export routing policies and if you have not explicitly configured a desired routing
policy then the defaults listed in Table 11-2.
When referring to this table keep in mind that Juniper Networks refers to directly connected and explicitly routes (ex.
Static) as pseudoprotocol routes since they do not originate from a specific routing protocol.
Table 11-2. Default Routing Policies

Imported/Exported
Default Import Policy Operation Default Export Policy Operation
Protocol
RIP Import all RIP routes learned from RIP will not export any routes by default. To export RIP routes,
configured neighbors into the you must configure an export policy.
inet.0 routing table.
RIPng Import all RIPng routes learned RIP will not export any routes by default. To export RIPng
from configured neighbors into the routes, you must configure an export policy.
inet6.0 routing table.
IS-IS Import all IS-IS routes into the Export all active IS-IS routes.
Downloader demo watermarks
inet.0 and inet6.0 routing
tables. (You cannot override or
change this default policy.)
Export all direct (interface) routes for the interfaces on
which IS-IS is explicitly configured.

OSPF OSPF Import all OSPF routes into Export all active OSPF routes.
the inet.0 routing table. (You
454
 11. Defining and Implementing Routing Policies
Imported/Exported cannot override or change this Export all direct (interface) routes for the interfaces on
Default Import Policy Operation Default Export Policy Operation
Protocol default policy.) which OSPF is explicitly configured.
BGP Import all BGP IPv4 routes Export all active BGP routes.
learned from the routers
configured neighbors into the
inet.0 routing table.
Import all BGP IPv6 routes
learned from configured
neighbors into the inet6.0
routing table.
LDP Import all LDP routes into the Export all active LDP routes.
inet.3 routing table.
MPLS Import all MPLS routes into the Export all active MPLS routes.
inet.3 routing table.
DVMRP Import all DVMRP routes into the Export all active DVMRP routes.
inet.1 routing table.
PIM Dense Mode Import all PIM dense mode routes Export all active PIM dense mode routes.
into the inet.1 routing table.
PIM Sparse Mode Import all PIM sparse mode Export all active PIM sparse mode routes.
routesinto the inet.1 routing
table.
Pseudoprotocol Import all direct and explicitly Does not by default export any routes. The pseudoprotocol
Routes Include: configured routes into the inet.0 cannot export any routes from the routing table because it is
routing table. not a routing protocol, rather it is a collection of routes that
Direct routes fir into one of the listed categories.

www.ebook-converter.com
Explicitly
configured
routes:
Routing protocols can export these or any routes from the
routing table.

Aggregate
routes
Generated
routes
Static routes

Note
You cannot change the default import policy for the link-state protocols IS-IS and OSPF. As link-state
protocols, IS-IS and OSPF exchange routes between routers within an autonomous system (AS). All routers

Downloader demo watermarks

within an AS (or area) must share the same link-state database, which includes routes to reachable prefixes and
the metrics associated with the prefixes. If an import policy were configured and applied to IS-IS or OSPF,
some routes might not be learned or advertised or the metrics for learned routes might be altered, which would
make a consistent link-state database impossible.

Policy-Chain Terms
455
 11. Defining and Implementing Routing Policies
A term is a segment of a policy designed to match routes against user-specified criteria and perform specific actions on
them once a match is made. A policy may have a single term, multiple terms, or none at all. Each policy can have specific
match actions within each term, as well as default actions outside of the terms. This concept is illustrated in Figure 11-4.

Figure 11-4. Policy Structure

Routes are sequentially passed into the first policy in the chain—in this example it is referred to as Policy 1. Policy 1
sends the routes through Term 1 and compares them to the match conditions specified. If a match is made against a route
and if the route is accepted or rejected, no further comparisons are made and any other actions specified are carried out.
If an accept or reject is not specified in the match actions or if there are no matches in Term 1, then the routes are passed
on to Term 2.
Keep in mind that match actions may occur against a route that simply modifies the properties of a route without
accepting or rejecting it. Routes that are not explicitly accepted or rejected by a match action continue to be evaluated in

www.ebook-converter.com
the policy chain. This procedure continues for T terms in Policy 1 where T is a numeric integer defining the number of
terms in a policy. If Term T has been evaluated without a match, then the routes are passed to the next policy in the
chain, which in this case is Policy 2. Routes that do not match any policies in the chain through an accept action will be
rejected.
Not all policies or terms will have from, to, and then statements present. There are a number of rules to determine
what occurs if all or only some of these statements are present. This process is illustrated in Figure 11-5 and described
below.
The following default actions are taken if one of the following situations arise during policy evaluation:
If a policy does not specify a match condition, all routes evaluated against the policy match.
If a match occurs but the policy does not specify an accept, reject, next term, or next policy action, one of the
following occurs:
The next term, if present, is evaluated.
If no other terms are present, the next policy is evaluated.
Downloader demo watermarks
If no other policies are present, the action specified by the default policy is taken.
If a match does not occur with a term in a policy and subsequent terms in the same policy exist, the next term is
evaluated.

456
 11. Defining and Implementing Routing Policies
If a match does not occur with any terms in a policy and subsequent policies exist, the next policy is evaluated.
If a match does not occur by the end of a policy or all policies, the accept or reject action specified by the default
policy is taken.

Figure 11-5. Policy Flow

Match Conditions
Both from and to statements are made up of match conditions. There are many conditions that a route can be matched
against, which are divided into generic and protocol categories. As previously discussed, a protocol-specific match
condition, such as the OSPF area number, is considered to be a unique characteristic used by that protocol. A complete
list of the possible from statements is contained in the following example from the CLI:

www.ebook-converter.com
[edit]
user@Chicago# edit policy-options policy-statement my-new-policy
[edit policy-options policy-statement my-new-policy]
user@Chicago# set from ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
area OSPF area identifier
+ as-path Name of AS path regular expression (BGP only)
color Color (preference) value
color2 Color (preference) value 2
+ community BGP community
> external External route
instance Routing protocol instance
+ interface Interface name or address
level IS-IS level
local-preference Local preference associated with a route

Downloader demo watermarks

metric
metric2
metric3
metric4
Metric value
Metric value 2
Metric value 3
Metric value 4
+ neighbor Neighboring router
+ next-hop Next-hop router

457
 11. Defining and Implementing Routing Policies
origin BGP origin attribute
+ policy Name of policy to evaluate
preference Preference value
preference2 Preference value 2
> prefix-list List of prefix-lists of routes to match
+ protocol Protocol from which route was learned
rib Routing table
> route-filter List of routes to match
> source-address-filter List of source addresses to match
tag Tag string
tag2 Tag string 2
Table 11-3 describes the each of the generic match conditions in more detail.
Table 11-3. Generic Match Conditions
Match
Description
Condition
color and Matches fine-grained preference values; often associated with BGP communities.
color2
external Matches external routes, including those exported from one level to another. A metric or type can be
specified. If a type is not specified, then all external routes are matched, but if a type is specified, then
the match will look for external type 1 or 2 routes, which are a feature of the OSPF protocol.
instance Matches routes coming from a specific protocol entity on the router.
interface Matches all routes learned via a specific interface. Do not use this with protocols that are not interface
specific, such as IBGP.
metric, Matches routes against four specifiable metric values. For BGP, metric corresponds to MED, and
metric2, metric2 corresponds to the IGP metric if the BGP next-hop traverses another route.
metric3,

www.ebook-converter.com
metric4
neighbor Matches routes from an OSPF or BGP neighbor or an IS-IS adjacency.
next-hop Matches routes tagged with a specific next-hop address.
policy Used to invoke routes that passed another policy. It saves having to rewrite policy statements.
preference Two preference values can be specified for a route. The preference2 value is used if there is a tie in
and the evaluation of the primary preference values. Also, color and color2 can be used as finer-grained
preference2 preference values.
protocol Matches against the protocol from which the route was learned.
rib Routes can be matched against a specific routing table. This defaults to the unicast routing table
inet.0 if a routing table is not specified, such as inet.1, inet.2, or mpls.0.
The following example shows a simple policy that rejects OSPF type 2 external routes:
policy-statement external-type2-reject {
from {
protocol ospf;
external {
type 2;
Downloader demo watermarks
}
}

then reject;
}
The next example shows a policy that could be used to change the metric of routes from a specific routing instance, in
458
 11. Defining and Implementing Routing Policies
this case ospf2, assuming the router is running multiple instances of OSPF. ospf2 is the second instance of OSPF
routing configured on the router:
policy-statement routes-from-ospf2 {
from {
instance ospf2;
protocol ospf;
}
then {
metric 10;
accept;
}
}
Another example is a simple routing policy that matches all RIP routes, as follows:
policy-statement match-rip-routes {
from protocol rip;
then accept;
}
There are also protocol-specific match conditions for OSPF, IS-IS, and BGP. Table 11-4 lists and describes each of the
protocol-specific match conditions.
Table 11-4. Protocol-Specific Match Conditions

Match Condition ProtocolDescription

area OSPF Matches routes learned from a specific OSPF area when exporting routes
as-path BGP Matches routes against an AS path regular expression

www.ebook-converter.com
community BGP Matches routes against one or more BGP communities
level IS-IS Matches routes based on the IS-IS router level as received
local- BGP Matches routes based on their BGP local preference value
preference
origin BGP Matches routes based on the source of the AS path information (IGP, EGP, or
incomplete)
tag and tag2 OSPF Matches routes against the contents of OSPF's external LSA 32-bit tag fields
Examples of the various BGP match conditions will be explored in greater depth later in the chapter and in Chapter 10.

Match Actions
After the match conditions in the from and to statements have been selected, it is then time to select a corresponding
match action for the policy. All match actions are specified as part of a then statement. As with match conditions, there
are many match actions. The possible match actions are listed below:
[edit policy-options policy-statement policyname]

Downloader demo watermarks

Lab@Chicago# set then ?
Possible completions:
accept Accept a route
+ apply-groups Groups from which to inherit configuration data
as-path-prepend Prepend AS numbers to an AS path (BGP only)
class Set class-of-service parameters
> color Color (preference) value
459
 11. Defining and Implementing Routing Policies
> color2 Color (preference) value 2
> community BGP community properties associated with a route
cos-next-hop-map Set CoS based next hop map in forwarding table
damping Define BGP route flap damping parameters
destination-class Set destination class in forwarding table
> external External route
> install-nexthop Choose the next-hop to be used for forwarding
> load-balance Type of load balancing in forwarding table
> local-preference Local preference associated with a route
> metric Metric value
> metric2 Metric value 2
> metric3 Metric value 3
> metric4 Metric value 4
next Skip to next policy or term
> next-hop Set the address of the next-hop router
origin BGP path origin
> preference Preference value
> preference2 Preference value 2
reject Reject a route
> tag Tag string
> tag2 Tag string 2
trace Log matches to a trace file
Match actions can be divided into three distinct groups:
1. Control actions
2. Tracing action
General policy actions

www.ebook-converter.com
3.

Control actions govern the policy flow. These are the most fundamental match actions and the most frequently used.
Table 11-5 lists and describes each of the control actions.
Table 11-5. Control Actions

Match Description
Action
acceptThe matched route is accepted and no further matching is carried out.
rejectThe matched route is rejected and no further matching is carried out.
ext Skips ahead to the next policy. If an accept or reject action is not specified, and a match has occurred, then
policy this is the default action. If there are no further policies, a default policy action is taken.
next Skips to the next term. This is also default behavior if an accept or reject action is not specified in the term.
term If there are no further terms, then the next policy is evaluated, and if there are no further policies, a default
policy action is taken.
The trace action logs the match to a trace file. You will already have some information on trace files from Section
6.2.5.1, and more tracing examples will be explored in the next chapter. Trace file configurations appear at the routing-
Downloader demo watermarks
options level as follows:
routing-options {
traceoptions {
file matchactionlog replace size 640k files 5 no-world-readable;
flag policy;
460
 11. Defining and Implementing Routing Policies
}
}
The remaining match actions fall under the general policy-actions category and are normally used to modify parameters
associated with a route. Table 11-6 lists each of these actions.
Table 11-6. General Policy Actions

Match Action Description

as-path- Prepends one's ASN one or more times to the beginning of an AS path to make a route less favorable to
prepend BGP.
class Applies CoS parameters to routes before they are installed in the routing table.
color and Sets the preference of a route to a value between 1 and 2321. A color can be seen as an internal
color2 preference value that is local to the router and nontransitive.
A color option specified on its own is used to denote a preference where there previously was
none. If dealing with a preference value that is already present, it can be modified by adding or
subtracting a constant, using the add and subtract options.
community Sets the BGP community attribute where there previously was none or overwrites an attribute that is
set already present.
community Adds a BGP community attribute to a route.
add
community Deletes a BGP community attribute from a route.
delete
damping Configures route flap damping parameters as part of routing policy. Enables suppression of
flapping routes.
destination- Relates destination class usage to maintain packet counts for specific routes. Destination class usage
class policies are applied to the forwarding table.

www.ebook-converter.com
external Sets the external metric type of an OSPF route.
install- Used in conjunction with an MPLS LSP to specify which next-hops are installed in the routing table.
nexthop lsp
load- Installs all next-hop addresses in the forwarding table for the active route and performs per-packet load
balance-per- balancing.
packet
local- Sets a BGP local preference parameter for a route.
preference
metric Like from and to statements, comprises four possible metrics for each route: metric, metric2,
metric3, and metric4. The add and subtract options exist to modify existing metric options.
Otherwise, any existing metrics are overwritten.
anext-hop Sets the next-hop information for BGP. A common scenario where this is used is in the next-hop
self statement, which is used to replace the existing next-hop with the address of the local router.
origin Can be set to one of three values: igp, egp, or incomplete.
preference Associates a preference value with a route. By default, all routes will have their preference set
or based on protocol origin. Routes with the lowest preference are preferred. The preference2 value
preference2 serves as a tiebreaker if preference values are equal. Furthermore the color and color2 values can
be used for further granularity. As with the color and color2 actions, add and subtract options
Downloader demo watermarks
exist for both preference and preference2 to modify an existing preference. Otherwise any
existing preference values are overwritten.
tag and tag2Sets the tag and tag2 fields in OSPF external LSA packets. The add and subtract options are also
used to modify existing values in either of these fields.
In the following example, the AS path attribute of all routes received from BGP peer 10.0.0.1 will be prepended with
461
 11. Defining and Implementing Routing Policies
"2 2 2 2", making these routes less attractive to BGP for inbound traffic, where 2 is the number of the local AS.
policy-options {
policy-statement as-path-prepend {
from neighbor 10.0.0.1;
then as-path-prepend “2 2 2 2”;
accept;
}
}
The next example enables damping with the options contained in lots-of-damping. The damping parameters for
lots-of-damping are specified in a separate section of policy. This will be examined in greater detail in Section 11.6.
policy-options {
policy-statement my-damp {
from neighbor 10.0.0.1;
then damping lots-of-damping;
}
The following example matches against routes coming from a specific next-hop 10.0.0.1 and going to OSPF area 3
while setting the preference value to 10.
policy-statement change-pref {
from next-hop 10.0.0.1;
to area 0.0.0.3;
then {
preference 10;
}
}

www.ebook-converter.com
Match conditions can be also specified using route filters. Route filtering is a method of picking out a route or specific
routes from the routing table and performing a common action on them. Route filtering will be examined in greater detail
later in this chapter.

DIET Policies
Earlier in the chapter we observed the similarity between a policy and a computer program. This concept will now be
explored further by applying a few computer program design rules. The first rule is that there are many ways to design, or
write, a computer program. Likewise, there are many different methods of policy composition. Often, if the syntax is
correct and the program or policy works, then you have achieved your goal. However, often elements of simplicity and
performance tend to fall by the wayside. It is important to design our policies in the most modular, scalable, and efficient
fashion possible. This makes our policies easier to parse, configure, and interpret.
We propose calling this the DIET policy design method. You may ask how this name was determined. Seeing as how the
fellow playing at being our manager while writing this book could stand to lose a few pounds, it was decided that the idea
of shedding excess weight could apply to policy as well. If you chuckled when you read this, then the likelihood is that
you will remember the four steps of policy dieting when needed and that you also had “one of those” kinds of managers!

Downloader demo watermarks

The four steps of the DIET are outlined in Figure 11-6.

Figure 11-6. DIET Policy Design Model

462
 11. Defining and Implementing Routing Policies
The four steps of the DIET policy method that will aid in proper design and implementation of an effective policy are as
follows:
1. Design—. First, follow a set of specialized policy design rules to create an effective routing policy.

2. Implement—. After applying good design practice, the policy must then be put to work. Implementing the policy in
JUNOS is key at this point. Though the policy has been configured, it has not yet been assigned to a routing protocol
or activated.
3. Execute—. Policy execution is the act of activating the policy by applying it to a specific routing policy.

4. Test—. The testing stage is the last phase. It is always good idea to verify that the policy functions as intended.

In the next section you will begin your policy creation using the DIET methodology. The objective will be to design
polices that are easy to understand and implement and that carry out the functions defined in the design stage.

Designing Policies
The world of computer programming has given us subroutines. Subroutines are a way of breaking down a complex
problem into smaller pieces so that each section can solve a subset of the overall problem, leading to a solution that is
easy to implement and understand. There are many reasons to break down a program into subroutines. Consider the
following from an online Perl programming guide by Emmie Lewis [13]:
Reduce complexity—Each subroutine represents a building block of the overall solution.
Facilitate modification—Future modification is easier if a program is divided into subroutines.
Hide order—Subroutines can be used to hide the order in which a program processes.

www.ebook-converter.com
Improve performance—There are fewer lines to compile and execute.
Hide complex detail—Programs are easier to read and understand.
Reuse parts of code—Once a subroutine is defined, it can be reused anywhere.
Now here's the same text again, but with the word “program” replaced with “policy” and the word “subroutine” with
“term”:
Reduce complexity—Each term represents a building block of the overall solution.
Facilitate modification—Future modification is easier if a policy is divided into terms.
Hide order—Terms can be used to hide the order in which a policy processes.
Improve performance—There are fewer lines to compile and execute.
Hide complex detail—Policies are easier to read and understand.

Downloader demo watermarks

Reuse parts of code—Once a policy is defined, it can be reused anywhere.
The essence of good policy design is taking a policy you want to design and separating it into as many terms as there are
tasks.
There are also similarities between the if, then, and else statements used in programming and the from, to, and
463
 11. Defining and Implementing Routing Policies
then statements used in policy. The if statement represents the match conditions of the from and to statement. The
then statement is executed if the from and to statements match, and the else statement represents the default policy
action for all routes that did not match.
For example, to define a policy that selects all OSPF routes from the routing table learned from a particular neighbor
(10.0.1.1) and sets them to a metric of 10, the code could look as follows:
policy-options {
policy-statement get-ospf {
from {
protocol ospf;
neighbor 10.0.1.1;
}
then {
metric 10;
accept;
}
}
}
Using the DIET methodology, the objectives of the policy were divided into two tasks:
1. Look at OSPF routes only; ignore all other routes, such as BGP.
2. From the OSPF routes, select only the routes originating from neighbor 10.0.1.1 and set their metric to 10.
Most of simple policies are designed with a single term. A single-term policy contains only one term. However, a term
does not need to be explicitly specified in the policy. In the following example, we see a policy named redistribute-
isis with one term, get-isis. The get-isis term matches and accepts all IS-IS routes in the routing table.

www.ebook-converter.com
policy-statement redistribute-isis {
term get-isis {
from protocol isis;
then accept;
}
}
This policy can be rewritten without a term statement as follows:
policy-statement redistribute-isis {
from protocol isis;
then accept;
}
Both policies have the exact same effect. The only difference between the two is that the explicit term definition was
dropped in the second example. The policy is called redistribute-isis and contains two statements. The from
protocol isis statement selects all IS-IS routes, which are in turn accepted with the accept statement.

Downloader demo watermarks

The second example may seem like good practice, and in some cases it is. However, it is recommended to keep the
explicit term definition, which is more in line with the scalability rule defined earlier. There is an old saying that a stitch in
time saves nine. That saying can be applied here. If you must modify a single-term policy at a later stage, then having
spent an extra few seconds on explicitly defining a term makes the policy easier to modify and scale. This is not so much
a rule as a recommendation. At the end of the day, a policy will wear the mark of its designer. The recommended design
rules can be summed up as follows:
464
 11. Defining and Implementing Routing Policies
Work out where you need policy and why.
Decide on how many policies are required.
Decide on how many terms are needed in each policy and include at least one for scalability.
Name each term and policy appropriately.
Implement the policy as you have defined it.

Implementing Policies
After a policy has been designed, the next step is to implement it. All policies are implemented in the CLI under the
[edit policy-options] level of the hierarchy. There are a number of commands used to implement a policy. A
typical implementation could take the following three steps:
1. Assuming you are at the [edit] level of the CLI hierarchy, then enter the edit policy-options policy-
statement policy-name command, policy-1 being the chosen name of the policy. This will place you at the
[edit policy-options policy-statement policy-1] hierarchy level like so:
[edit]
user@Chicago# edit policy-options policy-statement policy-1

[edit policy-options policy-statement policy-1]

user@Chicago#

Terms can then be implemented within the policy. Under each term, match conditions are created using from and to
statements, while match actions are created using the then statement. Possible match actions and match conditions
have been described earlier in the chapter.

www.ebook-converter.com
Terms are created with match actions and match conditions. Match conditions for the from statement are created
using the set term term-name from match-condition command, where match-condition matches one
of the conditions observed earlier in the chapter, and term-1 is the chosen name of the term. For example:
[edit policy-options policy-statement policy-1]
user@Chicago# set term term-1 from protocol ospf
[edit policy-options policy-statement policy-1]
user@Chicago# show
term term-1 {
from protocol ospf;
}

The same concept applies to the to statement using a valid match condition described previously in this chapter. For
example:
[edit policy-options policy-statement policy-1]
user@Chicago# set term term-1 to neighbor 10.0.0.1
[edit policy-options policy-statement policy-1]
user@Chicago# show

Downloader demo watermarks

term term-1 {
from protocol ospf;
to neighbor 10.0.0.1;
}

Match actions for the then statement are created using the set term term-name then match-action
command, where match-action matches one of the possible actions described earlier in the chapter. For example:

465
 11. Defining and Implementing Routing Policies
[edit policy-options policy-statement policy-1]
user@Chicago# set term term-1 then accept

[edit policy-options policy-statement policy-1]

user@Chicago# show
term term-1 {
from protocol ospf;
to neighbor 10.0.0.1;
then accept;
}

2. Next, the second term can be implemented, and so on, to create the policy chain, as shown below:
[edit policy-options policy-statement policy-1]
user@Chicago# set term term-2 from protocol bgp
[edit policy-options policy-statement policy-1]
user@Chicago# set term term-2 to neighbor 10.0.0.2
[edit policy-options policy-statement policy-1]
user@Chicago# set term term-2 then metric 20

[edit policy-options policy-statement policy-1]

user@Chicago# set term term-2 then accept
[edit policy-options policy-statement policy-1]
user@Chicago# show
term term-1 {
from protocol bgp;
to neighbor 10.0.0.1;
then accept;
}
term term-2 {
from protocol bgp;
to neighbor 10.0.0.2;

www.ebook-converter.com
then {
metric 10;
accept;
}
}

3. Lastly, it is a good idea to implement a default action term that contains only a then reject or then accept
statement. This catches everything that did not match the other terms and ensures that the final action is not being
left to system defaults. This final term is implemented using the set term finalterm then reject
statement, which leaves us with a complete policy as shown below:
[edit policy-options policy-statement policy-1]
user@Chicago# set term finalterm then reject

[edit policy-options policy-statement policy-1]

user@Chicago# show
term term-1 {
from protocol ospf;
to neighbor 10.0.0.1;
then accept;
}
term term-2 {

Downloader demo watermarks

from protocol bgp;
to neighbor 10.0.0.2;
then {
metric 10;
accept;
}
}

466
 11. Defining and Implementing Routing Policies
term finalterm {
then reject;
}

The order in which policies are implemented under the [edit policy-options] hierarchy level does not matter; it
is the order of their execution that is important. The order in which terms are defined within a policy is also important.
Whenever the active configuration is being compiled by the routing engine, policies are read in the order in which they
are applied. Terms, however, are read from top to bottom (see Figure 11-5). Policies are executed term by term from top
to bottom unless another policy is called within a term.
There are two other methods of policy implementation that we have not mentioned yet. These include route filters and
regular expressions. Both are very important areas of policy implementation and will be covered in detail in subsequent
sections.

Executing Policies
Policies do not automatically take effect after implementation. Rather, they are executed after they are applied to the
appropriate routing protocol, such as RIP, IS-IS, OSPF, BGP, or Distance Vector Multicast Routing Protocol (DVMRP).
Earlier in the chapter we reviewed import and export policies. At this stage we must set the rules for policy application.
The primary rule is that we cannot set an import policy for IS-IS or OSPF, which would be detrimental to routing stability.
We can, however, set up import and export policies for BGP. A policy is executed using the set protocols
command under the [edit] hierarchy level of the CLI. Let us suppose that we have two other export policies, namely
policy-2 and policy-3, to apply under the BGP hierarchy level. This would appear in the configuration as follows:
[edit]
user@Chicago# set protocols bgp export [policy-1 policy-2 policy-3]
Extract from bgp configuration:
protocols {
bgp {

www.ebook-converter.com
}
export [ policy-1 policy-2 policy-3 ];

Order is very important here because we are creating a policy chain. Our chain is made up of three policies. First
policy-1 is evaluated and only if there are no matches in policy-1, policy-2 is evaluated. Again, if there are no
matches in policy-2, policy-3 is evaluated as the last step. The policy chain is read by the router from left to right
and is treated as an ordered list. Thus, policy-1 is applied and executed first, and so forth. The insert command can
be used to change the order in which policies are evaluated and has two options: before and after. The following
example illustrates its use:
[edit]
user@Chicago# show protocols bgp
export [ policy-1 policy-2 policy-3 ];

[edit]
user@Chicago# insert protocols bgp export policy-2 before policy-1

[edit]

Downloader demo watermarks

user@Chicago# show protocols bgp
export [ policy-2 policy-1 policy-3 ];
[edit]
user@Chicago# insert protocols bgp export policy-2 after policy-3

467
 11. Defining and Implementing Routing Policies
[edit]
user@Chicago# show protocols bgp
export [ policy-1 policy-3 policy-2 ];
In the above example we have modified the order in which the policies are executed by moving around policy-2.
Within BGP, import and export policies can be applied at three different levels:
1. Global level—. under the [edit protocols bgp] hierarchy level
2. Group level—. under the [edit protocols bgp group groupname] hierarchy level, where groupname is
the name of the BGP group
3. Neighbor level—. under the [edit protocols bgp group groupname neighbor neighbor-
address] hierarchy level, where neighbor-address is the address of the specific BGP neighbor that the policy
applies to
The general rule is that neighbor-level policies supercede group-level policies, and group-level policies take precedence
over global-level policies.
The next example shows a BGP configuration that includes two BGP peer groups, one for internal and one for external
peers. For the purpose of this example, we have specifically used private addresses and ASNs. It is important to note that
external peer addresses would usually be public addresses, that is addresses other that those reserved for private use as
specified in RFC 1918 [6]. There are three policies configured as follows:
1. global-bgp-policy—. only applies to the internal-peers group since the external-peers group
contains its own group policy, which overrides the global policy
2. group-policy—. only applies to neighbors 192.168.1.2 and 192.168.1.3 as neighbor 192.168.1.1
contains its own policy, which overrides the group and global policies

www.ebook-converter.com
3. special-policy—. only applies to neighbor 192.168.1.1 in the external-peers group and overrides
both group and global policies
[edit]
user@Chicago# show protocols bgp
export global-bgp-policy;
group external-peers {
type external;
export group-policy;
peer-as 65535;
neighbor 192.168.1.1 {
export special-policy;
}
neighbor 192.168.1.2;
neighbor 192.168.1.3;
}
group internal-peers {

Downloader demo watermarks

type internal;
neighbor 172.16.1.1;
neighbor 172.16.1.2;
}

Testing Policies
468
 11. Defining and Implementing Routing Policies
After your policies have been designed, implemented, and executed, you are nearly finished with your policy DIET! The
last step is to test the policies. Aside from actual use and implementation, policies can be router tested in two ways:
1. Against a specific route using the test policy policy-1 a.b.c.d/e command
2. Against the entire unicast routing table inet.0 using the test policy policy-1 0.0.0.0/0 command
In the above commands, policy-1 is the name of the policy being tested, a.b.c.d/e is a specific route being tested,
and 0.0.0.0/0 signifies all the routes contained in the inet.0 routing table.
Through the use of the test policy command, it is possible to determine whether or not the policy implemented
meets the intended design criteria. Consider the simple network in Figure 11-7, which shows three routers: Washington
D.C., Chicago, and San Francisco. All routers are running OSPF and belong to backbone area 0. The 172.16.x/24
networks are static routes used to simulate attached customer networks. Table 11-7 lists the aggregate required on each
router to encompass each of the static routes.

Figure 11-7. Simple Network to Illustrate Policy Testing

www.ebook-converter.com
Table 11-7. Aggregate Routes

Router Aggregate
Washington D.C172.16.0.0/22
Chicago 172.16.4.0/22
San Francisco 172.16.8.0/22
The network is set up so that the aggregates are shared into OSPF through use of policy, while the specific networks are
not. This is achieved by means of a simple export policy named aggregate-2-ospf. The aggregate routes will be
accepted by this policy, while everything else will be rejected. As you review the configurations, notice that each policy
is applied as an export statement within OSPF before the actual policy is listed. The relevant pieces of the
configuration have been highlighted for you. Following are the configurations for each of the three routers.
1. Router Washington D.C. configuration:
[edit]
user@Chicago# show

Downloader demo watermarks

version 5.0R1.4;
system {
host-name DC;
root-authentication {
encrypted-password “$1$yqlMb$pgnl6m0eYT/pAIa7bENbl/”; #
SECRET-DATA
}

469
 11. Defining and Implementing Routing Policies
login {
user lab {
uid 2000;
class superuser;
authentication {
encrypted-password “$1$er32.$ZLaup5gYipIjmWcUmBMEr0”; #
SECRET-DATA
}
}
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
}
}
interfaces {
so-1/0/0 {
unit 0 {
family inet {
address 192.168.10.1/30;
}
}
}
so-1/0/1 {
unit 0 {
family inet {
address 192.168.30.2/30;
}
}
}
}

www.ebook-converter.com
routing-options {
static {
route 172.16.1.0/24 receive;
route 172.16.2.0/24 receive;
route 172.16.0.0/24 receive;
route 172.16.3.0/24 receive;
}
aggregate {
route 172.16.0.0/22;
}
}
protocols {
ospf {
export aggregate-2-ospf;
area 0.0.0.0 {
interface all;
}
}
}
policy-options {
policy-statement aggregate-2-ospf {
term match-aggregate {

Downloader demo watermarks

from protocol aggregate;
then accept;
}
term reject-all-else {
then reject;
}
}
}
470
 11. Defining and Implementing Routing Policies
2. Router Chicago configuration:
[edit]
lab@Chicago# show
version 5.0R1.4;
system {
host-name Chicago;
root-authentication {
encrypted-password “$1$a99Mb$PBmrtU.60ftgPmFQVSeKU/”; # SECRET-
DATA
}
login {
user lab {
uid 2000;
class superuser;
authentication {
encrypted-password “$1$i5Z2.$XHJgtMPiz7gqFHjOQUma9/”; #
SECRET-DATA
}
}
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
}
}
interfaces {
so-2/0/0 {
unit 0 {
family inet {

www.ebook-converter.com
address 192.168.10.2/30;
}
}
}
so-2/0/1{
unit 0 {
family inet {
address 192.168.20.1/30;
}
}
}
}
routing-options {
static {
route 172.16.4.0/24 receive;
route 172.16.5.0/24 receive;
route 172.16.6.0/24 receive;
route 172.16.7.0/24 receive;
}
aggregate {
route 172.16.4.0/22;
}
}

Downloader demo watermarks

protocols {
ospf {
export aggregate-2-ospf;
area 0.0.0.0 {
interface all;
}
}
}
471
 11. Defining and Implementing Routing Policies
policy-options {
policy-statement aggregate-2-ospf {
term match-aggregate {
from protocol aggregate;
then accept;
}
term reject-all-else {
then reject;
}
}
}

3. Router San Francisco configuration:

[edit]
lab@SanFran# show
version 4.4R3.4;
system {
host-name SanFran;
root-authentication {
encrypted-password “$1$w5MMb$bA04r6A7VAEMOwKs3Fa0l0”; # SECRET-
DATA
}
login {
user lab {
uid 2000;
class superuser;
authentication {
encrypted-password “$1$7nPMb$Gfjes5RfwJh8zBNYR45rk1”; #
SECRET-DATA
}
}
}
syslog {
user * {

www.ebook-converter.com
any emergency;
}
file messages {
any notice;
authorization info;
}
}
}
interfaces {
so-1/2/0 {
unit 0 {
family inet {
address 192.168.30.1/30;
}
}
}
so-1/2/1 {
unit 0 {
family inet {
address 192.168.20.2/30;
}
}
}

Downloader demo watermarks

}
routing-options {
static {
route 172.16.8.0/24 receive;
route 172.16.9.0/24 receive;
route 172.16.10.0/24 receive;
route 172.16.11.0/24 receive;
}
472
 11. Defining and Implementing Routing Policies
aggregate {
route 172.16.8.0/22;
}
}
protocols {
ospf {
export aggregate-2-ospf;
area 0.0.0.0 {
interface all;
}
}
}
policy-options {
policy-statement aggregate-2-ospf {
term match-aggregate {
from protocol aggregate;
then accept;
}
term reject-all-else {
then reject;
}
}

You can test the effect of the policies by issuing the show policy command on any of the three routers in the
example. As previously described, there are two ways of using the test policy command: testing against the entire
routing table or against a specific route. The following example uses the Washington D.C. router to test aggregate-2-
ospf against the aggregate route 172.16.0.0/22 and against all routes in the routing table. The output is as follows:
user@Chicago> test policy aggregate-2-ospf 172.16.0.0/22

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)

Prefixes passing policy:

www.ebook-converter.com
172.16.0.0/22 *[Aggregate/130] 03:34:06
Reject

Policy aggregate-2-ospf: 1 prefix accepted, 4 prefixes rejected

The sample output confirms that the aggregate route passes the policy, but how can we be sure that no other routes will
match? You should also issue a test policy 0.0.0.0/0 command, as follows, to ensure that no unexpected routes
slip through the policy:
user@Chicago> test policy aggregate-2-ospf 0.0.0.0/0

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)

Prefixes passing policy:

172.16.0.0/22 *[Aggregate/130] 03:51:24

Reject

Policy aggregate-2-ospf: 1 prefix accepted, 12 prefixes rejected

Downloader demo watermarks

As you can see, the results are very similar to the previous output, which in this case is a good sign. Washington D.C.'s
routing table contains 13 active routes, but only the aggregate passed the policy, which is exactly what it was designed
for.
Another useful command, the show policy command, lists all configured policies on a router.

473
 11. Defining and Implementing Routing Policies
user@Chicago> show policy
Configured policies:
Aggregate-2-ospf
In the previous example, there is only one policy configured on the router. If you would like to see what is configured in a
policy, you can issue the show policy policy-name command, where policy-name is the name of the policy
you are examining. Issuing the show policy aggregate-2-ospf command shows the rules defined within the
policy as follows:
user@Chicago> show policy aggregate-2-ospf
Policy aggregate-2-ospf:
Term match-aggregate:
from proto Aggregate
then accept
Term reject-all-else:
then reject

Route Redistribution and Filtering

Another important use of a routing policy on a Juniper Networks router is in route redistribution. You have seen
examples of route redistribution for IGP and EGP in Chapters 9 and 10. Those of you familiar with Cisco routers are
likely to be aware of the redistribute command. There is no equivalent redistribute command in JUNOS. All
redistribution of routes between protocols is done through the creation of a routing policy through the use of import and
export statements. This provides much more flexibility in that a policy can also be designed to modify route parameters
as they are being redistributed.

Route Redistribution

www.ebook-converter.com
A common example is that you want to redistribute RIP routes into OSPF. You may also want to modify the metric on
the RIP routes prior to redistributing them. The resulting policy would look similar to the following:
policy-statement rip-2-ospf {
from protocol rip;
then {
metric 5;
accept;
}
}
}

ospf {
export rip-2-ospf;
}
In JUNOS, the BGP protocol often relies on having routes put into the protocol through a redistribution export
policy. It is common to redistribute OSPF or static routes into BGP so they are seen as IBGP routes. This can be achieved

Downloader demo watermarks

using the following policy:
policy-statement ospf-2-bgp {
term match-ospf {
from protocol ospf;
then accept;
}
474
 11. Defining and Implementing Routing Policies
}
Another common redistribution policy is importing static routes into BGP, while modifying the next-hop address in the
process:
policy-statement static-2-bgp {
term match-static {
from protocol static;
then {
next-hop self;
accept;
}
}
An important observation from the above example is that the from protocol static statement is used. JUNOS
considers local, static, direct, and aggregate routes as separate protocols among other obvious choices like RIP, OSPF, IS-
IS, BGP, DVMRP, Protocol Independent Multicast (PIM), and MSDP:
user@Chicago# set policy-options policy-statement policy-name from protocol ?
Possible completions:
[ Open a set of values
aggregate Aggregate routes
bgp BGP
direct Directly connected routes
dvmrp DVMRP
isis IS-IS
local Local system addresses
msdp Multicast Source Discovery
ospf OSPF

www.ebook-converter.com
pim PIM
rip RIP
static Statically defined addresses
Sometimes when routes are being redistributed from one protocol to another, you might want to limit the routes to a
certain subset. Route filters were specifically designed for this purpose, as is discussed in the following section.

Route Filtering
Route filtering is a way of identifying a specific route or a group of routes and performing a common action on them.
Common actions include setting route metrics, preference values, or BGP communities. The ability to modify route
parameters increases the scalability of IP. By controlling routing parameters, such as metrics and protocol preferences,
network data paths can be customized at the discretion of the network administrator.
Route filtering is a very useful feature that enables a policy to be implemented in a number of stages. At each point,
specific groups of routes are selected and receive a set of actions. Actions may include the modification of metrics or
route rejection to deny routes from entering or passing through the network. Route rejection could be used to prevent a
neighboring AS from using the local network as a transit AS for nonlocal traffic that is not covered under a neighboring

Downloader demo watermarks

peering agreement.
A route filter operates in much the same way as any other type of filter. Consider the analogy of a rock quarry for
limestone or asphalt. In a quarry, rock is blasted from a rock face and then passed through rock filters. Each filter
removes a different size of rock, and at the finest filter, you are left with small stones useful for a sidewalk or driveway.
Figure 11-8 shows how such a filter would operate.
475
 11. Defining and Implementing Routing Policies

Figure 11-8. Analogy: Rock Filtering and Route Filtering

Now, imagine that instead of rocks, you want to filter routes prior to their redistribution into another protocol. The coarse
filter could operate on aggregate routes, the medium filter on more specific routes, and the fine filter on the most specific
routes. Because the routes are removed at different levels, different actions can be performed once a match is made.
Route filters reside under the from statement in policy configuration and are designed to operate on routes that a router
has learned prior to importing them into the routing table or passing them to other routers. JUNOS permits standard route
filtering and source address filtering.
Source address filtering is used to pick out prefixes from PIM sessions and either allow an address to join a multicast tree
by accepting a session from a specific source address or not allow the session to join the tree by rejecting the session.
More examples of this will be presented in Chapter 14.
A route filter looks for a route or group of routes using a set of match conditions. The first match condition is the network

www.ebook-converter.com
address. This address needs additional information in the form of a match type to determine if it matches or not. In
addition to the network address, one of the following match types is required:
[edit]
user@Chicago# set policyoptions policy-statement policyname from route-filter
192.168.1.0/24 ?
Possible completions:
exact Exactly match the prefix length
longer Mask is greater than the prefix length
orlonger Mask is greater than or equal to the prefix length
prefix-length-range Mask falls between two prefix lengths
through Route falls between two prefixes
upto Mask falls between two prefix lengths
It is possible to specify multiple route filters in a single from statement. In fact, this is standard practice. In the case of
multiple route filters matching a route within a from statement, a longest-prefix match rule applies. That is, the longest
match prevails over all other matches. Match actions can also be specified as part of the route-filter statement. If a
match action exists on the same line, then it overrules any match actions listed in the then portion of the policy. Some of

Downloader demo watermarks

these features are best observed in an example.
policy-statement filter {
term all-route-filter {
from {
route-filter 192.168.0.0/24 longer reject;
route-filter 10.0.0.0/8 orlonger reject;
476
 11. Defining and Implementing Routing Policies
route-filter 10.10.0.0/16 exact;
}
then {
metric 10;
accept;
}
}
term final-term {
then reject;
}
}
Three filter statements are listed above. If you pass the route 192.168.10.1/32 through the filter, it will be rejected
because all routes with prefixes larger than this network have been rejected by the first route-filter statement. The
route 10.10.10.10 would match both the 10.0.0.0/8 and 10.10.0.0/16 filters. It does not matter which of
these filters is defined first in the configuration. Keep in mind that when multiple filters exist in a from statement, the
longest match always wins. In this case, the 10.10.0.0/16 match prevails due to a longer prefix match. Since no
action is specified at the end of the filter statement, the action in the then statement is taken. That is, the route's
metric is set to 10, and the route is accepted.
The following example illustrates the use of route filters by rejecting all private addresses (RFC 1918) from external BGP
peers.
policy-statement rfc-1918 {
from {
route-filter 10.0.0.0/8 orlonger;
route-filter 172.16.0.0/12 orlonger;
route-filter 192.168.0.0/16 orlonger;
}

www.ebook-converter.com
then reject;
}

Route Flap Damping

Route damping may be a relatively new term in routing, but the problems caused by route flapping have been around for
many years. Damping is a method of suppression of BGP updates for routes that are deemed unstable. The need for
damping came about owing to the increase in the number and volatility of routes in the Internet. Unstable routes may
have a profound effect on the interdomain routing table because changes must propagate throughout the entire Internet.
Route flapping results from instability in an upstream system that causes routes to be advertised and withdrawn in excess.
Essentially, an UPDATE message is sent to provide NLRI for a prefix; then, another subsequent UPDATE message is sent
withdrawing the same prefix. The repetition of this process over and over for the same prefix is called route flapping.
In many cases, if the oscillation of a flapping route is repetitive enough, it is considered good practice to withdraw the
advertisement until the route has stabilized. Such a large volume of route volatility could cause an otherwise stable BGP
session to go down owing to overloading, but this is a very extreme case.

Downloader demo watermarks

When route flapping occurs, two significant problems can arise: The first is protocol convergence; the second is the
potential to perpetuate the flapping by sending similar UPDATE messages to other external peers, advertising and then
withdrawing the same prefix. This can go on and on, causing significant instability in multiple routing domains.
Consider the following analogy. You are sitting at home and, all of a sudden, your electricity goes out. What should you
do? You should call the electricity supplier of course. Two minutes after your call the electricity returns, but there is a
477
 11. Defining and Implementing Routing Policies
technician on the way to your house. So you call the supply company again to tell them everything is fine. Five minutes
after you get off the phone, the electricity goes out again, and again you call the supply company.
It is likely that you are not the only caller for this issue. The supply center has been overrun with calls because all of your
neighbors have been reporting problems as well. Apparently, an industrial company had been overloading the circuit that
feeds your home, causing the power outages. The unfortunate result was that a few hundred simultaneous calls were
made to the supply center's help line. However, not all calls were able to make it through. Some were dropped, owing to
the lack of answering capability. Route flapping is a lot like this, where a route fluctuation causes a flood of updates to be
sent out if no damping measures are in effect. Updates can sometimes increase route instability if they are received more
quickly than a router can handle.
Juniper Networks routers are designed to withstand great amounts of route instability due to the separation of the routing
engine from the PFE. In addition, they have built-in route-damping capabilities to minimize routing instability. In general,
we can classify Internet routes as falling into two categories:
1. Stable—. routes that do not flap very often, if at all

2. Unstable—. routes that are volatile and flap regularly

Damping is a process to subdue the problem of route flaps by providing a calculated method for the suppression of
UPDATE messages. Damping is typically implemented in exterior border routers to keep the flapping routes from being
injected into and withdrawn from the internal routing domain (IGP routing process). This type of implementation causes
minimal impact to the underlying AS routing domain.
Route flap damping devises a mechanism whereby the unstable routes are penalized for their volatility. The goals of BGP
route flap damping are defined and outlined in RFC 2439 [4] as follows:
To provide a mechanism capable of reducing router processing load caused by instability

www.ebook-converter.com
To prevent sustained routing oscillations
To avoid sacrificing route convergence time for generally well-behaved routes
RFC 2439 outlines a number of parameters that should be used to implement route flap damping.
JUNOS implements damping in accordance to RFC 2439. The configurable parameters (default values listed in
parentheses) are as follows:
half-life decay (15 minutes)—the time used to compute the rate of decay of the figure of merit
max-suppress threshold parameters (60 minutes)—the maximum number of minutes that the route can be
suppressed without reinstalling the prefix in the route table and starting the process over again
reuse threshold (750)—the figure-of-merit value that must be reached through the decay process to reuse the prefix
information (install in route table and propagate)
cutoff or suppress threshold (3,000)—the figure-of-merit value used to define the threshold to meet and exceed
before suppression of the prefix will occur

Downloader demo watermarks

The example below shows the sample code for implementation. If the default values are to be used, there is no reason to
use the policy-options configuration.
protocols {
bgp {

478
 11. Defining and Implementing Routing Policies
group ebgp {
type external;
neighbor 10.0.23.1 {
damping;
peer-as 100;
}
}
}
}
policy-options {
damping test {
half-life 15;
reuse 60;
suppress 750;
max-suppress 3000;
}
}
Each of these parameters will be discussed, along with the penalties that a route can incur for flapping, but to understand
them, you must first be familiar with the concepts of figure of merit and exponential decay. A figure of merit is a graph
that plots representative information. The figure of merit that is used for route flap damping is an exponential half-life
decay. Fortunately, this is easier to understand that it would seem!

Half-life Decay
Half-life decay is the amount of time that it takes for half of the particles in a sample to decay. A well-known half-life
used today is that of the Carbon-14 isotope. Scientists are able to date an object based on measurements of the amount of
Carbon-14 present in an object. This carbon dating method was developed by a group of scientists led by the late Willard

www.ebook-converter.com
F. Libby of the University of Chicago who received the Nobel Prize in Chemistry in 1960 for this discovery. The half-life
of Carbon-14 is 5,568 years. This means that if you take a sample today of an object that is 5,568 years old, half the
original amount of Carbon-14 will remain. In 11,136 years (2 × 5,568), one quarter of the original amount will remain
because half of the remainder after 5,568 years will have decayed. In 16,704 years there will be one-eighth of the original
amount of Carbon-14 left, and so forth.
So, how does all this apply to route flap damping? Exponential decay is used as a method of reducing the figure of merit
for a route because the rate of decay slows over the course of time. This means that a damped route will remain in the
figure of merit for a period of observation or until its damping value has reached a predefined reuse threshold.
All routes begin with a figure-of-merit value of 0. On a two-dimensional graph, the figure of merit is plotted on the
vertical axis and time is plotted on the horizontal axis. If a route fluctuates, then it is penalized as follows:
Route withdrawn—penalty of 1,000
Route readvertised—penalty of 1,000
BGP attribute change—penalty of 500

Downloader demo watermarks

The default values for route flap damping are as follows:
A decay half-life of 15 minutes—the amount of time that it takes the figure-of-merit value to decrease by half;
configurable for a range of 1 to 45 minutes
max-suppress time for a route of 60 minutes—the maximum amount of time for which a route can be suppressed;
479
 11. Defining and Implementing Routing Policies
configurable for a range of 1 to 720 minutes
cut-off threshold for a route of 3,000—figure-of-merit value at which a route is withdrawn from service and
deemed unusable until its value decays to the reuse threshold; configurable for a range of 1 to 20,000
reuse threshold for a route of 750—the figure-of-merit value at which a route is put back into service; configurable
for a range of 1 to 20,000 and should be lower than the cut-off threshold
Damping works on a figure of merit. Table 11-8 lists the figures of merit JUNOS applies based upon the associated event.
Table 11-8. Figures of Merit

Prefix Action Figure-of-Merit Points

withdrawn +1,000
readvertised +1,000
path attributes change+500

Figure 11-9 illustrates an example of a figure of merit using default values. The example has a given route that begins
with a figure-of-merit value of 0. When the route flaps for the first time, it is given a penalty of 1,000. The route
immediately begins to decay based on a half-life of 15 minutes. After a few minutes, the route flaps once more, so it is
penalized again by another 1,000 points. Since the figure of merit has decayed, this leaves the value at around the 1,800
mark. The route flaps a third time, but again after a period of decay. This leaves the value at around the 1,900 mark.
After another period of decay, the route flaps a fourth time, taking us up to 2,500 on the figure of merit. The route still
remains in the table because it has not met the cut-off threshold. The figure of merit then decays slightly, but the fifth flap
results in the route being withdrawn from service after the figure of merit reaches 3,100. The route is kept out of service
until the figure of merit decays enough to fall under the reuse threshold value of 750; however, the hold time will not
exceed a maximum of 60 minutes. In this example, the decay took two half-lives, or 30 minutes.

www.ebook-converter.com

Figure 11-9. Figure of Merit

Note
Note that this example was fairly lenient because the route flapped five times before it was suppressed. A lower
Downloader demo watermarks
decay threshold would have caused the route to be suppressed much sooner.
Next, we have a simple example of a route being advertised, withdrawn, and readvertised. We will follow the JUNOS
method of damping. Damping is enabled, as was shown in the previous configuration example. Prefix 172.16.0.0/20
is advertised to our local system. Our local system receives the prefix and installs it into the routing and forwarding
tables.
480
 11. Defining and Implementing Routing Policies
The remote system withdraws the route, causing our figure of merit to increase by 1,000, per the event values listed in
Table 11-8. Because we are using default values, the decay period is set to 15 minutes. Because the figure of merit has
not met or exceeded our default cut-off threshold of 3,000, the prefix will not be suppressed. However, the decay process
will start because there is a figure of merit. Based upon the half-life calculation, the figure of merit will decrease to 500
after 15 minutes, then to 250 after another 15 minutes, and so on.
For this example, let's assume that immediately after the prefix is withdrawn, it is immediately readvertised and
withdrawn again. This will add 1,000 to the figure of merit for the readvertisement, and another 1,000 for the withdrawal.
This brings our total figure of merit to 3,000. Looking at Table 11-9, we can see how the decay process decrease the
figure of merit every 15 minutes. According to our reuse threshold, we see that after 30 minutes of suppression, we can
reuse the prefix information.
Table 11-9. Figure-of-Merit Decay
Figure of MeritDecay Value Minutes
3,000 1,500 15
1,500 750 30
750 375 45
375 187.5 60
187.5 93.75 75
93.75 46.875 90
46.875 23.4375 105
23.4375 11.71875 120
11.71875 5.859375 135
5.859375 2.9296875 150
2.9296875 1.46484375 165
1.46484375 0.732421875180

www.ebook-converter.com
If damping is configured, we can view the parameters by issuing the show policy damping command. We can also
use the show route detail command to view damping information on a given prefix.

Damping Policies
Damping policies are normally implemented using route filters. Different damping parameters can be applied based on
prefix length. A well-known publication entitled “RIPE Routing-WG Recommendations for Coordinated Route-Flap
Damping Parameters,” better known as RIPE-229 [17], provides excellent watermarks on which to base BGP route-
damping parameters. The following example has been subdivided into two sections to improve readability and reduce
complexity:
protocols {
/* Dont enable damping globally - we want it to just apply to our eBGP peers.*/
bgp {
group your-flappy-peername {
/* turn on damping for this external peergroup */
damping;

Downloader demo watermarks

type external;
/* process the damping policy “graded-flap-damping” on the input side */
import graded-flap-damping;
peer-as 65500;
neighbor 192.168.1.1;
}

481
 11. Defining and Implementing Routing Policies
}
In general, damping should only be applied to external BGP peers. Routes that are advertised by internal peers should
have already been damped when they entered the network from an external peer. The graded-flap-damping import
policy is applied to the external BGP peer group, which sets the appropriate damping parameters. Among those
parameters is a list of special networks, such as the DNS netblocks, which should never be damped, owing to their high-
level importance. These networks are defined in the golden-networks prefix list, used to group all special networks
together.
policy-options {
/* Define Golden Networks here. Keep these current */
prefix-list golden-networks {
198.41.0.0/24;
128.9.0.0/24;
192.33.4.0/24;
128.8.0.0/16;
192.203.230.0/24;
192.5.4.0/23;
192.112.36.0/24;
128.63.0.0/16;
192.36.148.0/24;
193.0.14.0/24;
198.32.64.0/24;
202.12.27.0/24;
}
/* Define a damping policy. */
policy-statement graded-flap-damping {
term exclude {
from {

www.ebook-converter.com
prefix-list golden-networks;
}
then {
damping set-none;
next policy;
}
}
term damping {
from {
/* Lower penalty for prefixes of size /21 and smaller */
route-filter 0.0.0.0/0 upto /21 damping set-normal;
/* Medium penalty for prefixes of size /22 to /23 */
route-filter 0.0.0.0/0 upto /23 damping set-medium;
/* Higher penalty for prefixes greater than /24 */
route-filter 0.0.0.0/0 orlonger damping set-high;
}
then {
next policy;
}
Downloader demo watermarks
}
damping set-high {
half-life 30;
reuse 1640;
suppress 6000;
max-suppress 60;
482
 11. Defining and Implementing Routing Policies
}
damping set-medium {
half-life 15;
reuse 1500;
suppress 6000;
max-suppress 45;
}
damping set-normal {
half-life 10;
reuse 3000;
suppress 6000;
max-suppress 30;
}
damping set-none {
disable;
}
}
Four levels of damping exist based on the recommendations laid out by RIPE: set-high, set-medium, set-
normal, and set-none. Each of these specifies a different group of damping parameters applied within the policy.
Those networks that fall in the golden-networks category should never be damped and are ignored, using the set-
none parameter. Prefixes with lengths of size /21 and smaller are given lower restrictions according to the set-
medium parameters. Aside from the golden-networks, each of the parameters is based on the size of the prefixes
that it is applied to. The most restrictive of damping policies are applied to those prefixes that are /24 and larger because
fewer hosts are presumably affected. Larger networks are given higher priority and credibility over smaller route
announcements.
The half-life for the set-normal parameters is set to 10 minutes, so if the route is suppressed, the figure of merit will
decay quickly with suppression not to exceed 30 minutes. In all three of the damping parameters, it would take three

www.ebook-converter.com
flaps to reach the suppress value of 6,000. Recall that one route withdrawal and route readvertisement add up to 2,000.
The longest period of time that a route will be damped is one hour if it is of size /24 or larger.
All of the configured damping parameters, along with computed threshold values, can be viewed by issuing the show
policy damping command at the CLI prompt while in user mode:
user@Chicago> show policy damping
Default damping information:
Halflife: 15 minutes
Reuse merit: 750 Suppress/cutoff merit: 3000
Maximum suppress time: 60 minutes
Computed values:
Merit ceiling: 12110
Maximum decay: 6193
Damping information for “set-none”:
Damping disabled
Damping information for “set-normal”:
Halflife: 10 minutes

Downloader demo watermarks

Reuse merit: 3000 Suppress/cutoff merit: 6000
Maximum suppress time: 30 minutes
Computed values:
Merit ceiling: 24090
Maximum decay: 12453
Damping information for “set-medium”:
Halflife: 15 minutes
483
 11. Defining and Implementing Routing Policies
Reuse merit: 1500 Suppress/cutoff merit: 6000
Maximum suppress time: 45 minutes
Computed values:
Merit ceiling: 12049
Maximum decay: 12449
Damping information for “set-high”:
Halflife: 30 minutes
Reuse merit: 1640 Suppress/cutoff merit: 6000
Maximum suppress time: 60 minutes
Computed values:
Merit ceiling: 6577
Maximum decay: 24933
The next section shows how different levels of damping can be applied and configured through the use of AS path regular
expressions and BGP communities.

Regular Expressions and Communities

Regular expressions are an important part of today's policy applications. They are used especially in situations where a
router is situated at an Internet peering point, and they operate on BGP AS paths. Using regular expressions, a router can
match against occurrences of a number of different ASNs through a single expression. It can also match against a number
of BGP community attributes.

Regular Expressions for AS Paths

The use of JUNOS regular expressions as they apply to BGP AS path matching was discussed in Chapter 10. Before
covering the implementation of regular expressions in greater detail, you must first be familiar with the regular expression
operators and how they are put together.

www.ebook-converter.com
Regular expressions are made up of characters, numbers, and operators. Operators are used to match against patterns of
characters, patterns of numbers, or a combination of both. They contain individual grouping functions that enable a user
to construct complex match conditions, such as searching for multiple, rather than a single, numbers or characters. The
different operators that can be used to design a regular expression are explained as follows:
t{a, b}—. When used in a regular expression, this means that there must be at least a matches and at most b matches
of a term t, a character string or number preceding the operator. Both a and b are positive integers, and b is greater
than a.
One example would be 24{1,2} which would match sequences 24 and 24 24 because we requested a match for
at least one occurrence, and at most two occurrences, of the number 24. The number 24 in this example could be
an ASN where the matching is carried out using an expression on an AS-path list that is received in a BGP
update.
The {a, b} operator can also reside in the middle of an expression, for example, 24{1,2} 34. This expression
would match at least one occurrence, and at most two occurrences, of the number 24 immediately followed by
the number 34. Therefore this would match sequences 24 34 and 24 24 34.

Downloader demo watermarks

A special case of the {a, b} operator is {0,1}, which is normally represented by a ? symbol. The {0,1} or ?
operator matches zero or more occurrences of a term. Either format is acceptable in a regular expression.
t{a}—. When used in a regular expression preceded by a term t, there must be exactly a occurrences of the term t,
where a is a positive integer.

484
 11. Defining and Implementing Routing Policies
One example is 24{3}. This would match the sequence 24 24 24, or more specifically, three successive
occurrences of the number 24.
t{a,}—. When used in a regular expression, this means that there must be a or more repetitions of a term t, where a
is a positive integer.
One example is 24{3,}. This would match the sequences 24 24 24; 24 24 24 24; 24 24 24 24 24; and so on.
There are two special cases of this operator:
t{0,} is normally represented by a * symbol. The * or {0,} operators are used to match against zero or more
repetitions of a term t. Either format is acceptable in a regular expression.
t{1,} is normally represented by a + symbol. The + or {1,} operators are used to match against one or more
occurrences of a term t. Either format is acceptable in a regular expression.
|—When used in a regular expression, the logical OR operator matches against either of the terms specified on each
side of the | symbol.
One example is 24|34 this would match 24 or 34.
()—When used in a regular expression, round parentheses define a group of terms.
a–b—. When used in regular expressions, the minus sign between two terms is used to indicate a range.
One example is 23–34. This would match 23, 24, 25, and so on, up to 34.
There exist three additional operators that cannot be used with AS path expressions. We will review them later when we
look at communities. These operators are as follows:

www.ebook-converter.com
1.

2.
^—. When used in a regular expression, the carat symbol represents the beginning of a BGP community string.
$—. When used in a regular expression, the dollar sign represents the end of a community string.
3. []—. When used in a regular expression, square brackets are used to enclose a range of letters or digits.
Wildcard matching can be invoked using dot-star (.*) notation. Examples of this are as follows:
Dot-star— 24 25 26.*—matches the explicit sequence 24 25 26 followed by the occurrence of any other term.
Figure 11-10 illustrates the use of AS path regular expressions in JUNOS. A route X originates from AS 65535. We are
observing this route from the point of view of AS 65531. AS 65535 prepends route X with two instances of its own ASN
to make the inbound path from AS 65534 less attractive than the path from AS 65533. The route X passes through each
AS with each AS prepending the route with its own ASN. The route X arrives at AS 65531 through two different paths,
which gives AS 65531 two choices. If AS 65531 would like to use only path X: 65534 65535 65535 65535, even though
it is the longer of the two, then the configuration would look as follows:
policy-statement routex {

Downloader demo watermarks

term match-path {
from as-path routex;
then accept;
}
term other-paths {
then reject;
}
485
 11. Defining and Implementing Routing Policies
}
as-path routex “65534 65535{3}”;

Figure 11-10. AS Path Matching Using Regular Expressions

If AS 65531 wants to match against any AS path, then more AS path operators can be employed to assist in this task. For
AS 65531 to allow the use of all paths to AS 65535, then the following configuration could be used:
policy-statement routex {
from as-path routex_all-paths;
then {
preference 100;
accept;
}
}
as-path routex_all-paths “(65532|65534) 65533* 65535+ “;
The above expression reads as follows: Match against a sequence containing a first term of 65532 or 65534, followed by
zero or more occurrences of 65533, followed by one or more occurrences of 65535.

www.ebook-converter.com
Community Regular Expressions
At this stage you should be familiar with BGP communities, which were discussed in Chapter 10, and the regular
expression operators discussed earlier in this chapter. For those of you familiar with Cisco products, a useful piece of
information is that all community regular expressions begin with ^ and end with $. JUNOS requires the use of the
quotation marks to enclose the regular expression. The community regular expressions used in JUNOS are the same as the
standard UNIX regular expressions.
In JUNOS, community-attribute matching is very similar to AS path matching. Communities are defined in the same way
through the use of policy statements. Community definitions require a name and appropriate member IDs, such as the
following:
community sample-community members [ 65535:1 no_export no_advertise
no_export_subconfed ];
The above example illustrates all of the possible community IDs that are configurable. A regular community ID takes the
format of AS-number:Community-ID, such as 65535:1.

Downloader demo watermarks

The above three community IDs are outlined in RFC 1997, “BGP Communities Attribute” [5]. Once the communities
have been defined, they can be matched against in regular expressions. To do this, one would use the same operators as
in AS path matching. A few examples include the following:
65535:*—. This matches all communities from AS 65535, as * is a wildcard operator.

486
 11. Defining and Implementing Routing Policies
*:*—. This matches all incoming communities.
65535:1.0—. This matches communities 110,120,130 … 190 in AS 65535.
Community attributes are transitive if present, but upon receiving a route with a community, a router can add, delete, or
modify this attribute.
A very simple policy can be configured to keep from advertising any community attributes at all:
policy-statement no-community-export {
then {
community delete match-all;
}
}
community match-all members *.*;
Because there is no from statement, all routes match and all community attributes are removed. JUNOS also supports
the configuration of the BGP extended communities attribute, but no regular expressions are supported for this as of yet.

Chapter Summary
This chapter has introduced you to routing policy, where policy is used, and how to implement it in JUNOS. A routing
policy, as was discussed, allows a network engineer to apply business considerations onto the operation of a network.
Recall that the routing policy extended throughout an AS and differed depending on the routers placement within the
network. The examples throughout the chapter should enable you to configure an abundance of flexible policies.
Whether they are for route redistribution, route parameter modification, or for more complex applications like regular
expressions, you now have the necessary tools to tackle these problems successfully.
You were introduced to the DIET policy methodology, a design model for policy deployment that can be also applied in

www.ebook-converter.com
many other areas of configuration. The chapter reviewed route redistribution and filtering and the flexibility that they
provide in controlling the information that flows into and out from your routers. In the regular expressions section you
also learned how to construct complex matching patterns for BGP AS path lists using operators as building blocks.
Finally, remember that the secret to any good policy is simplicity. Simplicity can be clearly implemented when your goals
are clearly defined.

Bibliography

Downloader demo watermarks

487
[ch11rfc1918] IETF RFC—RFC 1918, Address Allocation for Private Internets. Y.
Rekhter, et al. 1996.
[ch11rfc1930] IETF RFC—RFC 1930, Guidelines for Creation, Selection, and
Registration of an Autonomous System (AS). J. Hawkinson, T. Bates. 1996.
[ch11rfc1997] IETF RFC—RFC 1997, BGP Communities Attribute. R. Chandra, P.
Traina, T. Li. 1996.
[ch11rfc2439] IETF RFC—RFC 2439, BGP Route Flap Damping. C. Villamizar, R.
Chandra, R. Govindan. 1998.
[ch11rfc2622] IETF RFC—RFC 2622, Routing Policy Specification Language (RPSL).
C. Alaettinoglu, et al. 1999.
[ch11rfc2650] IETF RFC—RFC 2650, Using RPSL in Practice. D. Meyer, et al. 1999.
[ch11bib07] JUNOS Internet Software Configuration Guide—Routing and Routing
Protocols, Release 5.1. Juniper Networks, Inc., <year>2001</year>.
[ch11bib08] perl.about.com

www.ebook-converter.com
[ch11bib09] RIPE-181, Representation of IP Routing Policies in a Routing Registry. T.
Bates, et al. 1994.
[ch11bib10] RIPE-229, RIPE Routing-WG Recommendations for Coordinated Route-
Flap Damping Parameters. C. Panigl, et al. 2001.
[ch11bib11] www.arin.net
[ch11bib12] www.c14dating.com/int.html
[ch11bib13] www.colorado.edu/physics/2000/isotopes/radioactive_decay3.html
[ch11bib14] www.ep.net

Downloader demo watermarks

[ch11bib15] www.irr.net
[ch11bib16] www.isi.edu/ra
[ch11bib17] www.ripe.net/ripe/docs/databaseref-manual.html
488
www.ebook-converter.com

Downloader demo watermarks

489
 12. MPLS and Traffic Engineering
Chapter 12. MPLS and Traffic Engineering
As the Internet has grown, more and more platforms are accessing it and in doing so generating an ever-increasing
amount of traffic. Some of these platforms are server farms that may store user data or provide streaming e-learning
content. Then there are the more complex networks in the enterprise infrastructure that may span multiple geographic
regions, even the world. Add to this the Internet backbone, which is comprised of several heterogeneous data networks,
each providing different levels of connectivity. The end result is more than just the Web pages and e-mail, which are so
familiar. The growth and expansion of the Internet has happened very quickly and has lead to a number of problems,
one of the largest being control.
Traffic engineering is the process of controlling the flow of traffic across a physical network topology to obtain optimal
resource use. When implemented properly, traffic engineering helps a carrier to use all available bandwidth resources
efficiently. JUNOS uses MPLS in combination with RSVP as its primary method of traffic engineering.
This chapter begins with an introduction to traffic-engineering problems and solutions, MPLS, and RSVP, then
describes how they are implemented in JUNOS and shows how to build a minimal MPLS/RSVP configuration. The case
studies included at the end of this chapter help the reader explore the concept of traffic engineering as it is applied in
different network scenarios.

Traffic-Engineering Problems
The Internet's level of complexity has rendered simple IGP-based methods of controlling traffic flow insufficient.
Figures 12-1 and 12-2 demonstrate why it is not always best to use metrics to control traffic flow. In Figure 12-1, traffic
from Chicago destined for Tampa and Miami is crossing the link from Chicago to Atlanta. This path is chosen because it
has a lower metric than the path through Washington D.C. In this situation the link from Chicago to Atlanta could
become overutilized, while the path through Washington D.C. remains underutilized.

www.ebook-converter.com

Figure 12-1. The Underutilized Path Through Washington D.C

Downloader demo watermarks

Figure 12-2. The Underutilized Link from Chicago to Atlanta
In Figure 12-2, an attempt is made to force use of the path through Washington D.C. The metric for the link directly
between Chicago and Atlanta is raised to 5. This forces the use of the path through Washington D.C., which has a
combined metric of 2. With these settings, traffic destined for both Tampa and Miami will follow the path through

490
 12. MPLS and Traffic Engineering
Washington D.C., which will become overutilized, while the link directly from Chicago to Atlanta is underutilized. This
change did not resolve the issue; it simply moved it.
One way to resolve the dilemma shown in Figures 12-1 and 12-2 would be to have traffic destined for Tampa use the
direct link from Chicago to Atlanta and to have traffic destined for Miami follow the path through Washington D.C., as
shown in Figure 12-3.

Figure 12-3. Both Routes Utilized

Figures 12-1 and 12-2 demonstrate the lack-of-control issues faced by network engineers. Figure 12-3 represents the
essence of traffic engineering as a means to resolve the control issue. In Figure 12-3, neither link is underutilized, and
traffic is routed by the Chicago router, based on the final destination of the traffic (Tampa or Miami). The next section
focuses on traffic-engineering solutions.

Traffic-Engineering Solutions
Although the concept has been around for some time, traffic engineering in IP is still in its early stages because Internet
usage only began to truly push the edge of the envelope in the middle to late 1990s. This strain on resources forced the

www.ebook-converter.com
rapid development of feasible solutions. The three most prevalent of these in the networking world are Routed IP,
switched transport, and MPLS. These solutions are described in the following sections.

Routed IP
IGP routing protocol solutions are used to route IP, and as they have been extended, they have been used to manipulate
how traffic flows through the network. By tweaking metrics on specific links, it is possible to cause certain links to look
more desirable than others. One major problem with metric manipulation is the possibility of unwanted side effects. For
example, modifying link metrics in one part of a network may cause traffic to be routed suboptimally through other
parts, as was demonstrated in Figures 12-1 and 12-2.
By itself, IGP route manipulation works well in small networks of limited complexity, where the effects of metric
tweaking would not be as widely felt and would definitely be more manageable and predictable than in a large-scale
network. While IGP metric tweaking is still possible and indeed currently implemented in larger-scale networks, it is not
the most accurate or predictable approach available.

Switched Transport
Downloader demo watermarks
Switched-transport networks, also known as overlay networks, have historically been one of the more successful means
of accomplishing traffic-engineering goals. Switched-transport networks are based on a core of ATM switches
connected to each other and to routers by logical links known as PVCs that live at Layer 2 of the OSI reference model.
Figure 12-4 shows this type of topology.
491
 12. MPLS and Traffic Engineering

Figure 12-4. Routers Connected by PVCs Ringing the Edge of an ATM Core
The routers that operate at the edge of the switched-transport network see each PVC as a point-to-point circuit to other
distinct routers. These routers being OSI Layer 3 devices, they have a completely different view of the switched-
transport network topology, as is shown in Figure 12-5.

www.ebook-converter.com

Figure 12-5. The Routers' View of a Switched-Transport Network

After the routers are linked over the ATM core, the router's IGP is configured across each of the PVCs to establish peer
relationships with the other routers and exchange routing information. A handy feature of the switched-transport
solution to traffic engineering is its ability to handle link failure through the use of redundant PVCs. With redundant
PVCs configured, IGP metrics can be used to ensure that backup PVCs are used when the primary PVC is not available.
Also, if the primary PVC becomes available after an outage, traffic can automatically be sent back over the primary
PVC, again through the metrics of the router's IGP.

Downloader demo watermarks

Although it is a feasible and commonly used traffic-engineering mechanism, this method has the following pitfalls:
The N-Squared Issue—N-squared refers to a common simplification of the equation that is used to calculate how
many connections are required to establish a full-mesh topology. The equation, (N(N–1))/2, where N is the number
of routers in a network, shows that to establish a full-mesh topology in a network with 100 routers, 4,500 PVCs
must be configured. Deploying a full mesh of PVCs stresses the IGP. This stress results from the number of IGP
492
 12. MPLS and Traffic Engineering
peer relationships that must be maintained by the router.
ATM Cell Tax—Every ATM cell is 53 bytes in length: 48 bytes are used for the cell payload and 5 bytes are used
for the cell header. Therefore, ATM overhead is never less than about 10 percent, which means that when ATM is
used, the ATM cell header consumes 10 percent of the available bandwidth. This wastes expensive WAN
bandwidth.
ATM SAR Speed—Since ATM cells are used between the routers, and IP packets are used within the routers, each
ATM router interface must have a SAR chip, which breaks IP packets into ATM cells as they leave the router on an
ATM interface and reassembles ATM cells into IP packets when they arrive on a router's ATM interface. The
problem is that ATM SAR processing speed has fallen behind the faster processing speeds provided by the SONET
SAR chip. This means that ATM technology has not advanced enough to enable its use in higher-speed networks.
Separate Autonomous Control Planes—With switched-transport networks, there are two separate and autonomous
control planes. In the first plane are the routers. The routers rely on IGP calculations to forward traffic. In the
second plane are the switches. The switches rely on a provisioning tool to build PVCs. The IGP has no control over
the switches. The PVC provisioning tool has no control over the routers.
Additional Points of Failure—Switched-transport networks require the use of complex ATM switches that require a
high degree of competence to configure. The addition of these devices adds additional points of both human and
mechanical failure to the network environment.
Because of these drawbacks, switched-transport networks are seldom the best solution for traffic engineering.

MPLS
The original purpose of MPLS was to make IP routers faster. It was perceived that if the router could be forced to
function more like a switch with regards to making forwarding decisions based on OSI Layer 2 information, then it

www.ebook-converter.com
could move traffic as fast as a switch.
This was the perception in the mid 1990s of the primary purpose for MPLS. Since that time, routers have evolved to the
point where they are capable of making forwarding decisions based on OSI Layer 3 information just as quickly as, if not
more quickly than, a switch can make its Layer 2–based forwarding decision. Some engineers still believe that the use
of MPLS brings improvements over IP routing with regards to packet forwarding speed. This is simply not true.
MPLS has not been abandoned as an outdated mechanism because it is the best traffic-engineering tool available for IP
networks. It can control traffic over numerous physical media types or across a network without interfering with native
IGPs while remaining immune to their metrics-based decisions. MPLS offers the same level of control as seen with an
ATM core without being burdened with traditional ATM drawbacks. It offers a solution to the complexity and expense
of supporting two autonomous sets of equipment. MPLS is not automatically subjected to the bandwidth limitations of
ATM SAR interfaces. And lastly, MPLS takes some of the burden off of the IGP, rather than stressing it the way ATM
PVCs do.
The question as to why MPLS is good for traffic engineering has now been answered. The following sections discuss
how MPLS works.

Downloader demo watermarks

MPLS Operation and Design Principles
MPLS offers functionality that works in unison with, rather than replacing, the existing infrastructure. MPLS can also
be used for VPNs, intradomain routing, and interdomain routing. Before launching into a technical discussion of the
intricacies of MPLS, it is necessary to explain the basic functionality of the protocol, as well as to introduce the reader

493
 12. MPLS and Traffic Engineering
to the terminology that will be used throughout the rest of this chapter. The following section offers a functional
overview of MPLS and includes an introduction to common MPLS terminology.

Functional Overview
An MPLS-enabled network gives the network engineer precise control over how traffic flows from source to
destination. To provide this control, MPLS allows packets to move independently of the IGP routing algorithms native
to the network being crossed. To accomplish this, MPLS relies on predefined paths, known as LSPs.
LSPs are composed of connections between MPLS-enabled routers. A router that is running MPLS is known as a label-
switching router (LSR). LSRs tag each packet passing through the LSP with a label. This label accomplishes several
things, the most important of which is distinguishing the MPLS packet from a regular IP packet, thereby entitling the
packet to continue crossing each LSR along the LSP without being subjected to Layer 3 scrutiny. The packet's label is
changed by the LSR at every hop, hence the name label-switching router.
JUNOS uses MPLS as the foundation for two types of services: traffic engineering and RFC 2547bis (BGP/MPLS)
VPNs. For a detailed explanation of VPNs, see Chapter 13.

Labels
Labels are a way of marking packets destined for a specific address. Packets are assigned labels by LSRs. Once they are
assigned labels, they can be forwarded through the network to the next LSR along a preconfigured path. When the
packet arrives at an LSR, the label distinguishes this packet from other IP traffic and allows it to be handled by the
MPLS protocol. This form of packet distinction permits the MPLS protocol to function on the same interfaces as the
native IGP without interfering with the IGP's routing calculations or processes.
Figure 12-6 illustrates the MPLS label format, as well as the location of the MPLS label with regard to the Layer 2 and

www.ebook-converter.com
Layer 3 headers. The following list defines the label fields shown in Figure 12-6.
20-bit label field—This is the actual label value itself. This is where the label value is inserted.
3-bit experimental field—These bits are used for CoS. They are defined as experimental because a concrete
decision has not yet been reached as to which version of CoS they will support (IP Precedence or Differentiated
Services).
1-bit stacking field—This field value is either 1 or 0. A value of 1 denotes the label is the bottom of a label stack. A
value of 0 indicates that there are multiple labels stacked on this packet. Label stacking is discussed in Chapter 13.
8-bit TTL field—In some situations the value in this field is copied from the IP header TTL field. This is
decremented as it passes through MPLS hops. When the label is popped, this value can overwrite the IP header TTL
field.

Downloader demo watermarks

Figure 12-6. MPLS Label Format
494
 12. MPLS and Traffic Engineering
Figure 12-6 also shows the positioning of the MPLS label with regard to a typical IP packet. The diagram shows that the
label resides between the Layer 2 frame and Layer 3 packet. Table 12-1 lists details about the label value ranges and
use and introduces two previously unmentioned terms, penultimate hop popping (PHP) and ultimate hop popping
(UHP). These terms are covered in Section 12.5 and Case Study 1 at the end of this chapter.
Table 12-1. JUNOS MPLS Label Values
Label
Label Use
Value
0 IPv4 Explicit NULL Label—When receiving a label of level 0, the local system must pop the MPLS stack and
route the packet by traditional IPv4 routing. This is known as ultimate hop popping (UHP).
1 Router Alert Label—Similar use as the Router Alert Option in IP packets. This level would signal the local
system to send the packet to a local software module for processing.
2 IPv6 Explicit NULL Label—When receiving a label of level 2, the local system must pop the MPLS stack and
route the packet by traditional IPv6 routing.
3 Implicit NULL Label—This label is used to signal the penultimate LSR (the one before the egress LSR) to pop
the MPLS stack. This is known as penultimate hop popping (PHP).
4–15 This level is reserved by RFC standards.
16–1,023 These labels are not used by JUNOS in the automated process of creating labels for an LSP. The
administrator uses these labels when defining static LSPs. This eliminates the possibility of dual assignments
by JUNOS when establishing labels for LSPs.
1,024– This level is reserved in JUNOS for future support, but can currently be used by the administrator when
99,999 defining static LSPs.
100,000– These are per-box labels assigned by JUNOS when establishing labels for LSPs.
799,999
800,000– JUNOS uses this level for per-interface labels.
1,048,575

www.ebook-converter.com
The combination of label number and inbound interface is cross-referenced against a table to determine the outbound
interface and label. Once these have been determined, three common operations can be performed by LSRs on labels:
1. Push—. The MPLS label is added to packets and the packets are forwarded along the LSP. This operation is
performed as the packet enters the LSP.
2. Swap—. The MPLS label is changed as the packet carrying it passes through an LSR. This process is performed at
each transit hop along the LSP.
3. Pop—. The MPLS label is removed from the packet and a normal IP packet is forwarded by the LSR. This process
is performed by the penultimate (second-to-last) LSR.

LSPs
MPLS is based on the creation of LSPs. These LSPs are used to forward packets from a source to a destination. LSPs
are engineered on top of an already existing IP-based core network. The LSPs themselves are created in a unidirectional

Downloader demo watermarks

manner. Traffic engineering controls data flows; thus, each given direction of a bidirectional flow may be engineered to
meet specific requirements. This allows finer control of path engineering. Usually, the return path is engineered across
the same set of hops, although this is not a necessity. MPLS does not, however, guarantee the delivery of the packet.
This must still occur at higher layers, such as the transport layer or the application level.
MPLS LSPs can be formed either statically or dynamically. In static configuration, the network administrative team

495
 12. MPLS and Traffic Engineering
must define which label number to use and the next-hop information. In dynamic configuration, protocols like RSVP are
used to signal label information between the ingress LSR and the egress LSR. This eliminates the need for
administrators to define which label values and next-hops to use, however, there is the capability to use administrative
constraints within JUNOS to further control LSP negotiation and setup. For a detailed description of constraints, see
Sections 12.3.2.2 and 12.3.2.3.
The MPLS signaling protocol RSVP provides the ability to configure constraints (path requirements) along the LSP. By
employing these constraints the engineer is able to define specific LSRs along the LSP as being either strict hops or
loose hops. A strict hop is a requirement that the path be formed through a specific interface to an immediately
connected LSR. A loose hop is a requirement that an LSP pass through a specific LSR. However, with loose hops there
is no requirement that a specific interface be used.
To form the LSP, Constrained Shortest Path First (CSPF) relies on specific pieces of information that are stored in a
traffic-engineering database (TED) created based on information carried by the IGP, be it IS-IS or OSPF.
Manually configuring and defining the swapping of labels at each hop creates static LSPs. Static LSP creation is useful
when implementing MPLS across small networks, or in situations where there is simply not enough bandwidth to
support a signaling protocol. See Section 12.5 for an example of creating a minimal configuration for static LSPs.

LSRs
An LSP is built across the following component LSRs:
Ingress—This is the point of origin of the LSP. By definition, it is the first router in the LSP.
Transit—This is any router in the LSP that does not provide ingress or egress functionality.
Penultimate—This is the second-to-last transit router in an LSP. The penultimate router is capable of popping the
MPLS label and sending a true IP packet to the egress router.

www.ebook-converter.com
Egress—This is the last router in an LSP.
A single router is capable of filling multiple roles for different LSPs. A transit router for one LSP could also be the
ingress router for another LSP. The egress router for one LSP could be a transit router for another LSP. There are no
mandatory hardware differences between ingress routers and transit or egress routers.
Figure 12-7 illustrates the flow of a packet through these router types. MPLS packets travel across an LSP and are
assigned labels based on the configuration present in the LSR. In this case the packets travelling between Santiago and
Rio are given a label value of 0. Label value 0 represents an explicit NULL label; therefore, this figure represents a
network scenario that uses UHP.

Downloader demo watermarks

Figure 12-7. LSP Router Types
An LSR possesses the following the major characteristics of MPLS forwarding:
No Layer 3 lookup by transit routers—An LSR consults the traditional routing table only when functioning as an
LSP ingress point or egress point. MPLS transit routers don't rely on the Layer 3 lookup algorithms for best-
496
 12. MPLS and Traffic Engineering
path/next-hop lookups.
Label swapping on transit routers—Transit routers possess a table, known as mpls.0, that maps an inbound
interface and label to an outbound interface and label for each LSP. The LSR is capable of swapping labels and
forwarding packets based on the contents of this table.
Coexistence of MPLS and Layer 3 technologies—LSRs are normally capable of forwarding both traditional
network layer packets and MPLS packets without interfering with the native routing algorithm.
Any given LSR must also be capable of performing several key functions for MPLS:
Ingress functionality
Transit functionality
Egress functionality
The ingress router, also known as the head-end router, marks the entry point of an LSP. The ingress router will take an
incoming packet and look at the destination IP address. If an LSP exists to that address, it will assign the packet a label
and forward it to the next LSR—either a transit LSR or the egress point—along the LSP. If an LSP to the destination
address does not exist, then the router will use other routing table entries to resolve the next-hop.
When a transit router receives a packet with an MPLS label, it will then treat the packet as an MPLS packet, and no
Layer 3 decisions will be applied. This router will compare the incoming interface and label of the packet to an MPLS
table to determine the outbound interface and label. If this router is the penultimate router, then it will either tell the
egress router what to do with the packet or pop the label and forward the unlabelled packet to the ultimate router
(PHP).
The egress router will typically receive a label value of 0, unless PHP has been configured. In that case the egress router

www.ebook-converter.com
receives from the penultimate router an IP packet with no MPLS encapsulation. If, however, PHP has not been
configured, and the egress router receives a packet with a label, it will pop the label and forward the packet based upon
its original characteristics. There is a case where the label received by the egress router is different from those listed
here. If this is the case, it is usually on a statically defined LSP, and specific configuration statements are included to tell
the router to pop the label and forward accordingly.

Establishing an LSP
As was mentioned previously in Section 12.3.1.2, there are several ways of creating an LSP. These methods include
LDP, RSVP, and CSPF and are explored in detail in the following sections.

LDP
LDP is used to create dynamic LSPs in an MPLS network. Defined in RFC 3037, LDP is typically used in nonexplicit
and non-traffic-engineered scenarios. LDP typically establishes LSPs based upon the already running IGP's routes. In
addition to typical hop-by-hop LSP establishment, LDP can tunnel through RSVP-created LSPs. This one of several
methods used for construction of MPLS-based VPNs. More details on VPNs can be found in Chapter 13.
Downloader demo watermarks
LDP operations are quite simple and based on a set of four different messages. The bibliography at the end of this
chapter lists additional documentation to refer to for detailed explanations of LDP, as well as MPLS and RSVP.
LDP works on a peer-to-neighbor relationship. As with all LSPs, an LDP LSP can be a single hop from one router to
another or across the entire network. The four message types outlined by RFC 3036 used in LDP are as follows:
497
 12. MPLS and Traffic Engineering
1. Discovery messages
2. Session messages
3. Advertisement messages
4. Notification messages
These messages each play a specific role in the creation of LDP-based LSPs.
Discovery messages are used to create a neighbor or peer adjacency. LDP will send hello messages out an LDP-enabled
interface. Hello messages are sent on UDP port 646. When a neighbor answers this hello message, an adjacency is
formed. Further communication is then sent via a TCP session.
Session messages are used to maintain each LDP session with each LDP peer. Session messages are responsible for
handling the following:
Peer establishment—This session message is used for building a relationship with a neighboring LSR running LDP.
Peer adjacency—This session message is used for maintaining a relationship with a neighboring LSR running LDP.
Peer termination—This session message is used for ending a relationship with a neighboring LSR running LDP.
Advertisement messages are responsible for the following functions relating to the FEC table in each LSR:
Label creation—This message is responsible for the assignment of labels to an LSP.
Label deletion—This message is responsible for the removal of labels from an LSP, essentially tearing down the
LSP.

www.ebook-converter.com
Label modification—This message is responsible for making changes to the labels assigned to an LSP.
When a label is created in the local system, it will send an advertisement message to the associated peer advising of the
creation. If the IGP path for the LDP-based LSP goes away, then advertisement messages are used to delete the label
associated for the path between the two peers.
Notification messages come in two forms:
Advisory notifications—These are typically used when sending information about the LDP session.
Error notifications—These are used when there is an adverse condition where the LDP session needs to be
terminated. When this occurs each side of the peering will remove all labels associated with the session.

RSVP
RSVP was designed to signal bandwidth requirements on a per-flow basis. Juniper Networks has implemented an
extended version of RSVP [RSVP with traffic-engineering extensions (RSVP-TE)]. RSVP within the JUNOS
implementations is for use in support of MPLS LSPs. The Juniper Networks implementation of RSVP will continue to
Downloader demo watermarks
be referred to as RSVP in this text as this is how it is referenced in the JUNOS software. RSVP is used to reserve
resources in a given path for either multicast or unicast traffic. It uses its own messaging system within the protocol to
make these reservations. RSVP also allows a given path to be established (reserved) with specific QoS parameters.
Juniper Networks' implementation of traffic engineering takes advantage of the characteristics of RSVP and uses the
protocol to establish dynamic LSPs. These LSPs can contain strict or loose hops in their definition.
498
 12. MPLS and Traffic Engineering
RSVP uses a messaging system to create LSPs. The message types are as follows:
Path Message—. sent periodically towards the downstream router; used to allow the routers to learn previous-hop
and next-hop for a given session
Resv Message—. sent from the downstream receiver of a flow towards the upstream originator; tells each router
along the path to make the reservation for the flow
PathTear Message—. signals the routers to tear down the path created by the Resv Message; flows from the
upstream router towards the downstream router
ResvTear Message—. signals each router in the flow to remove the reservation states that were set up by the
Resv Message; flows form the downstream router towards the upstream router
PathErr Message—. sent when a problem along the path occurs; advisory only; do not affect the state of the path
ResvErr Message—. used primarily when a reservation request fails; if allowed to flow through, each router
involved should receive this message
The JUNOS implementation of RSVP also contains extensions that provide traffic-engineering enhancements. These
enhancements include the following:
Explicit route object (ERO)—carries the strict and loose hop configuration elements; tells downstream routers how
to set up the LSP to the destination based on these constraints
Label request object—used to request a label on a segment from the downstream router
Label object—passes the label value chosen by the downstream LSR in the Resv Message sent to the upstream
LSR

www.ebook-converter.com
Record route object—used to track the sequence of IP addresses that the LSP crosses to reach the destination
Session attribute object—carries the name of the LSP
There are many configurable attributes within the RSVP structure, including timers for path reservations and bandwidth
settings per interface, session, and traffic flow. These are all configurable with the RSVP/MPLS configuration
parameters. See Case Study 2 at the end of this chapter for a look at some of the options available when configuring
RSVP.

CSPF
CSPF, or Constrained Shortest Path First, is used in JUNOS to compute LSPs with constraints. CSPF is used to add
variables to the TED. These variables are then used in conjunction with the TED and the SPF algorithm to create the
most efficient LSP for the network.
In CSPF, several attributes must be considered. These are classified in two distinct families: LSP attributes and link
attributes. The LSP attributes consist of the following:

Downloader demo watermarks

Bandwidth requirements for the LSP—the minimum bandwidth requirement for each hop along the LSP
Hop limitations—the maximum number of LSR hops permitted along the LSP
Administrative groups—a method of specifying that an LSP only be created over links within a certain

499
 12. MPLS and Traffic Engineering
administratively defined group
Priority—a configurable value that allows one LSP's creation to take precedence over the creation of other LSPs
Explicit route criteria—the explicitly defined strict or loose hops that the LSP must cross on route to the destination
The link attributes consist of the following:
Reservable bandwidth—calculated by taking the link bandwidth and subtracting the currently provisioned or
reserved bandwidth
Administrative groups—a method of grouping links by administratively defined characteristics, most commonly
bandwidth

Prefix Mapping and Routing Table Integration

This section looks at two interrelated topics: prefix mapping and routing table integration. Prefix mapping refers to the
ability to set up the equivalent of a static route to force packets destined for a prefix to use a specific, pre-established
LSP. This feature is useful when establishing a connection to a distant network that is not advertised through BGP or
IGP. With MPLS enabled, the local system is told to use a specific LSP to forward traffic to a given prefix. This can be
beneficial when it becomes necessary to provide connectivity to a group of networks that may be open, but not
reachable by the rest of the network resources.
Routing table integration describes the concept of relying on multiple tables when resolving the next-hop. Each of the
different routing tables is populated by specific protocols. However, depending on the configuration of the LSR, it is
possible to have information from one routing table carried over into other tables. Chapter 8 describes routing tables
used within JUNOS. Each of these routing tables has a specific function. When referring to MPLS and traffic
engineering, the following routing tables are relevant:

www.ebook-converter.com
inet.0—the default unicast routing table where typical IGP routes are stored
inet.3—where entries created by RSVP are stored; maps a specific LSP to a destination address
mpls.0—where entries created by MPLS are stored; maps inbound interface and label combinations to outbound
interface and label combinations
The following example shows the output of the show route table inet.3 command. Here there is a route to
address 192.168.24.1. This is because the RSVP LSP configuration points to the loopback address of the remote
router.
lab@Chicago> show route table inet.3

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

192.168.24.1/32 *[RSVP/7] 00:12:04, metric 30, metric2 0

Downloader demo watermarks

> to 10.0.15.1 via ge-3/0/0.0, label-switched-path 1
The next example shows the mpls.0 table from a router running RSVP. Notice the label number 251042. This is the
label used in the router for the LSP created by RSVP.
lab@Chicago> show route table mpls.0

500
 12. MPLS and Traffic Engineering
mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0 *[MPLS/0] 6d 05:43:22, metric 1

Receive
1 *[MPLS/0] 6d 05:43:22, metric 1
Receive
251042 *[RSVP/7] 00:15:16, metric 1
> to 10.0.13.2 via ge-1/1/1.0, label-switched-path 1
Recall from Chapter 9 that BGP will prefer routes in inet.3 over routes in inet.0. The example below shows this.
The show route protocol bgp command has been issued. The route for the 192.168.24.0 network is not the
typical route that was there before. This route exists because it was chosen from the inet.3 table.
lab@Chicago> show route protocol bgp

inet.0: 26 destinations, 26 routes (25 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both

192.168.24.0/24 *[BGP/170] 5d 23:02:50, MED 0, localpref 100, from 192.168.24.1

AS path: I
> to 10.0.15.1 via ge-3/0/0.0, label-switched-path 1
These commands are invaluable when troubleshooting MPLS-related issues. For more troubleshooting tactics, see
Chapter 15. This section illustrated the contents of the routing tables that can be involved in MPLS traffic engineering.
Further examples of routing table contents can be found in the case studies at the end of this chapter.

Traffic Protection

www.ebook-converter.com
Traffic protection typically refers to a network's resiliency against outage. This section shows how Juniper Networks
routers provide this capability in a traffic-engineered network.
In a typical IGP scenario, when a link goes down, the IGP will recalculate the best path to the destination address so
long as it is still reachable. In MPLS, traffic protection occurs in a similar manner. Keepalive messages are
periodically sent between LSRs by way of the signaling protocol (RSVP). When there is an outage, the LSR upstream of
the outage uses RSVP to signal the ingress LSR that there is a failure. The ingress LSR then recalculates a new path to
the destination and builds a new LSP. A potential problem is the time required to recalculate a new route for the LSP.
RSVP relies on the native underlying network IGP; therefore, the underlying IGP must reconverge following link failure
before the RSVP protocol is capable of starting the process of establishing a new LSP.
To combat this issue, JUNOS implements two key features: secondary paths and fast reroute. With secondary paths,
JUNOS can define a secondary LSP to use in the event there is a failure of the primary LSP. Caution should be used
when engineering the secondary path. For the sake of true redundancy and the elimination of single points of failure, it
is best to create a secondary path that uses different routers and circuits than the primary.
Fast reroute is a method employed to patch a link failure prior to creating a new LSP. Figure 12-8 illustrates this. There

Downloader demo watermarks

are six routers involved in this network. Chicago is the ingress router, and London is the egress router. The active LSP
from Chicago to London traverses through routers San Francisco and New York.

501
 12. MPLS and Traffic Engineering

Figure 12-8. MPLS—Traffic Protection Fast Reroute

Let's assume there is a failure of the link between San Francisco and New York. In Figure 12-8, San Francisco, having
fast reroute enabled, would attempt to rebuild the LSP from its point of failure. In this case, San Francisco would signal
the repaired portion of the path from San Francisco to Brussels to Amsterdam to New York. This gets the LSP up in the
least amount of time.
In addition to this repairing of the LSP, San Francisco would then signal to Chicago to establish a new end-to-end LSP
with London. In a scenario where maximum protection is necessary, it is possible to employ both standby secondary
path and fast reroute. In this scenario the LSP failure due to link failure could immediately be repaired with fast reroute,
while at the same time, the upstream router from the failure would signal the ingress router of the failure and request use
of the secondary path. With both methods being deployed, the ingress router would switch to the pre-engineered
secondary path.
When using standby secondary path or fast reroute, it is important to understand potential bottlenecks in the physical
topology. If the physical infrastructure is not completely understood, then the potential exists to have configured and
assumed operability of traffic protection without actually having the protection. Testing such scenarios is suggested to

www.ebook-converter.com
set a minimal level of expectation.
This section covered the operational theory behind the methods of establishing an LSP. This included the signaling
protocols RSVP and LDP and the use of CSPF and the TED. This section also described routing table integration issues
and the theory behind configuring secondary LSPs and fast rerouting as methods of protecting traffic. The following
sections demonstrate how to build functional configurations that employ MPLS, RSVP, and LDP.

MPLS Configuration
This section shows how to build a minimal configuration for MPLS. For MPLS to be activated, it is necessary to add the
MPLS protocol family to the interfaces that will bear MPLS traffic. MPLS must also be configured under the [edit
protocols] level of hierarchy as shown below.
[edit interfaces]
lab@Chicago# set fe-0/0/0 unit 0 family mpls

[edit interfaces]
lab@Chicago# set fe-0/0/1 unit 0 family mpls

Downloader demo watermarks

[edit interfaces]
lab@Chicago# show
fe-0/0/0 {
unit 0 {
family inet {
502
 12. MPLS and Traffic Engineering
address 10.0.24.2/24;
}
family mpls;
}
}
fe-0/0/1 {
unit 0 {
family inet {
address 10.0.31.1/24;
}
family mpls;
}
}
}

[edit interfaces]
lab@Chicago# top

[edit]
lab@Chicago# edit protocols

[edit protocols]
lab@Chicago# set mpls interface all

[edit protocols]
lab@Chicago# show
mpls {
interface all
}

www.ebook-converter.com
[edit protocols]
lab@Chicago# commit
The example below shows the routing table MPLS information. There are two labels, 0 and 1, created automatically by
JUNOS. These are actual MPLS routes in the table. Label 0 is the IPv4 explicit NULL, and 1 is the router alert label
(refer back to Section 12.3.1.1 for more information).
[edit]
lab@Chicago# show route table mpls.0

mpls.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

0 *[MPLS/0] 00:09:26, metric 1

Receive
1 *[MPLS/0] 00:09:26, metric 1
Receive

Downloader demo watermarks

This configuration sample showed the minimum number of steps required to enable MPLS on an interface to permit the
FPC that the interface resides on to understand MPLS traffic. This sample also showed the steps used to launch the
MPLS protocol on the routing engine. Lastly, this configuration sample showed the two labels that are automatically
created by JUNOS when the MPLS protocol is launched.

503
 12. MPLS and Traffic Engineering
Static LSP Configuration
This section shows how to build a minimum configuration for a static LSP. The example uses the topology shown in
Figure 12-9. A static LSP will be created from San Francisco to Tokyo. Typically, the IGP would choose the path from
San Francisco to Chicago to Tokyo. MPLS will be used to engineer a path from San Francisco, through Chicago, then
through London, to Tokyo.

Figure 12-9. Static LSP Topology

The first configuration output below shows San Francisco's routing table prior to the configuration of a static LSP. The
native IGP, OSPF, prefers the path from San Francisco through Chicago to Tokyo for address 10.10.10.5/32.
lab@SanFran> show route 10.10.10.5

www.ebook-converter.com
inet.0: 20 destinations, 20 routes (19 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.5/32 *[OSPF/10] 00:00:21, metric 20
> to 10.0.24.1 via fxp1.0
The next configuration examples show the steps necessary to configure a static LSP from San Francisco through
Chicago, then through London, to Tokyo. The example below shows the configuration used for San Francisco. In
addition to adding family MPLS to all involved interfaces and launching the MPLS protocol, as was shown above, it
is necessary to add the static-path inet statement to the configuration. This essentially inserts a static route in
the routing table for the address 10.10.10.5/32. With the next-hop thus statically defined, label 100 will be pushed
onto the packets destined for 10.10.10.5 as they leave the LSR bound for the next-hop, 10.0.24.1.
[edit protocols mpls]
lab@SanFran# set static-path inet 10.10.10.5 next-hop 10.0.24.1 push 100

[edit protocols mpls]

lab@SanFran# show

Downloader demo watermarks

static-path inet {
10.10.10.5/32 {
next-hop 10.0.24.1;
push 100;
}
interface all;
504
 12. MPLS and Traffic Engineering
}
Since Chicago and London are considered transit routers in MPLS, the only function they will serve is to swap labels.
The example below shows the configuration of Chicago. Again, family MPLS has already been added to all
appropriate interfaces and the MPLS protocol has already been launched.
[edit protocols mpls]
lab@Chicago# set interface fe-1/1/2 label-map 100 next-hop 10.0.2.2 swap 200

[edit protocols mpls]

lab@Chicago# show
interface all;
interface fe-1/1/2.0 {
label-map 100 {
next-hop 10.0.2.2;
swap 200;
}
}
The next example shows the configuration for router London. In this example, label 200 is being received from
Chicago and swapped with label 0, which will be sent to Tokyo. In this example, the penultimate router sets the label to
0. When the egress router receives the label 0, it will know to pop the label and route the packet in the traditional IPv4
fashion. Again, family MPLS has already been added to all appropriate interfaces and the MPLS protocol has already
been launched.
[edit protocols mpls]
lab@London# set interface fe-2/0/1 label-map 200 next-hop 10.0.0.1 swap 0

[edit protocols mpls]

www.ebook-converter.com
lab@London# show
interface all;
interface fe-2/0/1.0 {
label-map 200 {
next-hop 10.0.0.1;
swap 0;
}
}
The next example shows the route table for route 10.10.10.5/32 from router San Francisco. In this case, the LSP
has been configured and is showing as a static path. Static routes in JUNOS take a protocol preference of 5. MPLS takes
a protocol preference of 7, while OSPF takes a protocol preference of 10.
The static route shows the interface to be used for the next-hop. Most importantly, this output shows Push 100 for
this route, indicating that traffic destined for 10.10.10.5/32 will take the LSP that was defined in the configuration.
JUNOS assigns a numerical value to routes depending on how they have been derived. This numerical value is called the
protocol preference. The lower the protocol preference, the more favorable the route. For example, statically defined

Downloader demo watermarks

LSPs are static routes; therefore, they are given a protocol preference of 5, just as any other static route would be.
Routes derived by LDP are given a protocol preference of 9. Because 5 is less than 9, the static route is preferred over
the LDP route. For a complete listing of protocol preferences, see Chapter 8.
A statically used LSP has a protocol preference of 5, which is preferable to the IGP OSPF preference of 10. JUNOS
places an asterisk (*) in front of routes that have been selected for placement in the forwarding table. This is shown for
505
 12. MPLS and Traffic Engineering
the static LSP in the following example:
lab@SanFran> show route 10.10.10.5/32

inet.0: 21 destinations, 21 routes (20 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both

10.10.10.5/32 *[Static/5] 11:57:46

> to 10.0.24.1 via fe-0/0/0.0, Push 100
[OSPF/10] 11:57:45, metric 20
> to 10.0.24.1 via fe-0/0/0.0
This section demonstrated the steps necessary to build a static LSP. This section also showed the contents of the routing
table that result from creating a static LSP.

RSVP-Based Dynamic-LSP Configuration

The first example below shows the statements required to configure RSVP on a Juniper Networks M-Series router. It
also demonstrates the common practice of disabling the signaling protocol across fxp0, the management Ethernet
interface. In most situations LSPs are not configured across the management LAN; therefore, running the RSVP
signaling protocol on the management Ethernet interface is unnecessary.
[edit protocols rsvp]
lab@Chicago# set interface all

[edit protocols rsvp]

lab@Chicago# set interface fxp0 disable

www.ebook-converter.com
[edit protocols rsvp]
lab@Chicago# show
interface all;
interface fxp0.0 {
disable;
}
Now that the RSVP protocol has been configured it is necessary to add the configuration elements that will build an
LSP. Figure 12-10 shows the topology that will be used for the RSVP configuration example.

Downloader demo watermarks

Figure 12-10. RSVP LSP Topology
In this example, an LSP will be established from Chicago to destination 192.168.24.1 on the Tokyo router. To
configure the LSP, use the set mpls label-switched-path label-name to egress-router-address

506
 12. MPLS and Traffic Engineering
no-cspf command at the [edit protocols] level of hierarchy as shown below.
[edit protocols]
lab@Chicago# set mpls label-switched-path 1 to 192.168.24.1

[edit protocols]
lab@Chicago# set mpls label-switched-path 1 no-cspf

[edit protocols]
lab@Chicago# show
mpls {
label-switched-path 1 {
to 192.168.24.1;
no-cspf;
}
}
The no-cspf statement included here makes sure that the LSR will not try to create the LSP based on the contents of
the TED.
The following example illustrates the output of the show mpls lsp command. An LSP has been established to egress
address 192.168.24.1 from ingress address 192.168.5.1. The LSPname is explicitly shown in the output of this
command. This is important as there could be multiple LSPs configured.
lab@Chicago> show mpls lsp
Ingress LSP: 1 sessions
To From State Rt ActivePath P LSPname
192.168.24.1 192.168.16.1 Up 2 * 1
Total 1 displayed, Up 1, Down 0

www.ebook-converter.com
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit LSP: 0 sessions

Total 0 displayed, Up 0, Down 0
The next example includes the output from the show mplS lsp extensive command. Adding the extensive
switch to the end of the command dramatically increases the information shown in the output, including whether the
LSP is a primary or secondary path, whether hops are loose or strict, the actual hops taken, and the time of LSP
creation.
lab@Chicago> show mpls lsp extensive
Ingress LSP: 1 sessions

192.168.24.1
From: 192.168.16.1, State: Up, ActiveRoute: 2, LSPname: 1
ActivePath: (primary)

Downloader demo watermarks

LoadBalance: Random
*Primary State: Up
Received RRO (S [L] denotes strict [loose] hops):
10.0.15.1 S 10.0.13.2 S 10.0.31.1 S
10 Jan 2 03:13:07 Selected as active path
9 Jan 2 03:13:07 Record Route: 10.0.15.1 S 10.0.13.2 S 10.0.31.1 S

507
 12. MPLS and Traffic Engineering
8 Jan 2 03:13:07 Up
7 Jan 2 03:13:04 Deselected as active
6 Jan 2 03:13:04 No Route[2 times]
5 Jan 2 03:13:04 Clear Call
4 Jan 2 03:11:33 Selected as active path
3 Jan 2 03:11:33 Record Route: 10.0.15.1 S 10.0.13.2 S 10.0.31.1 S
2 Jan 2 03:11:33 Up
1 Jan 2 03:11:33 Originate Call
Created: Wed Jan 2 03:11:34 2002
Total 1 displayed, Up 1, Down 0

Egress LSP: 0 sessions

Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
The show route 192.168.24.1 command shows that there is a route installed in both inet.0 and inet.3. As
the reader will recall from the discussion on RSVP and routing tables, the default behavior is for MPLS to install LSPs
into inet.3. The route in inet.1 is based on the native IGP, which in this case is IS-IS. As discussed earlier in
Section 12.3.3, BGP will prefer routes in inet.3 over routes to the same prefix in inet.0. The next example
reiterates this point.
lab@Chicago> show route 192.168.24.1

inet.0: 24 destinations, 24 routes (23 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both

192.168.24.1/32 *[IS-IS/18] 00:08:09, metric 30, tag 2

> to 10.0.15.1 via ge-3/0/0.0

www.ebook-converter.com
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.24.1/32 *[RSVP/7] 00:00:26, metric 30, metric2 0

> to 10.0.15.1 via ge-3/0/0.0, label-switched-path 1
The next example illustrates the show mpls lsp command on the egress LSR (Tokyo) of the Figure 12-10 topology.
Notice the Labelin field has a value of 3. Section 12.3.1.1 explained that label 3 is used as an implicit null label,
which is used in RSVP- and LDP-based LSPs to tell the upstream router to pop the label. Although what is shown in the
label in column is a 3, the router is actually receiving IP packets without an MPLS from the upstream router. This
demonstrates the PHP concept.
lab@Tokyo> show mpls lsp
Ingress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Egress LSP: 1 sessions

Downloader demo watermarks

To
192.168.24.1
From
192.168.16.1
Total 1 displayed, Up 1, Down 0
State Rt Style Labelin Labelout LSPname
Up 0 1 FF 3 - 1

Transit LSP: 0 sessions

Total 0 displayed, Up 0, Down 0
508
 12. MPLS and Traffic Engineering
Compare the output for Tokyo to the output for the upstream router, Amsterdam, below. The Labelout field shows a
label value of 3.
lab@Amsterdam> show mpls lsp
Ingress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Egress LSP: 0 sessions

Total 0 displayed, Up 0, Down 0

Transit LSP: 1 sessions

To From State Rt Style Labelin Labelout LSPname
192.168.24.1 192.168.16.1 Up 1 1 FF 100304 3 1
Total 1 displayed, Up 1, Down 0
This section demonstrated the commands used to configure the MPLS signaling protocol RSVP. It also compared the
output from various show commands run on LSRs that are crossed by the LSP.

LDP-Based Dynamic-LSP Configuration

This section shows how to configure LDP LSPs on a Juniper Networks M-Series router. LDP created LSPs are not used
for traffic engineering in the general sense of the term. They are sometimes used in VPN scenarios, therefore LDP
configuration does merit mention.
This example also uses the topology shown in Figure 12-10. In this example, each router will be configured to run LDP.
To configure LDP, issue the set ldp interface all and set ldp interface fxp0 disable commands
under the [edit protocols] level of hierarchy. This will activate LDP on the router. Once again, the signaling
protocol is disabled across fxp0, as the management LAN will not need LSPs.

www.ebook-converter.com
[edit protocols]
lab@Chicago# set ldp interface all
[edit protocols]
lab@Chicago# set ldp interface fxp0 disable

[edit protocols]
lab@Chicago# show
ldp {
interface all;
interface fxp0.0 {
disable;
}
}
The example below shows the output from a show route command issued on Chicago. To save space, the output has
been truncated, and only the output for prefixes 192.168.24/24 and 192.168.8/24 is shown.

Downloader demo watermarks

Some interesting information is learned from this output. There is no label associated with the 192.168.8.x/n
prefixes owing to their being only one hop away. There is a label associated with the 192.168.24.x/n prefix. In this
case BGP has preferred routes from inet.3 as was discussed earlier.
lab@Chicago> show route

509
 12. MPLS and Traffic Engineering
inet.0: 26 destinations, 26 routes (25 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.8.0/24 *[BGP/170] 5d 23:32:52, MED 0, localpref 100, from
192.168.8.1
AS path: I
> to 10.0.15.1 via ge-3/0/0.0
192.168.8.1/32 *[IS-IS/18] 01:24:42, metric 10, tag 2
> to 10.0.15.1 via ge-3/0/0.0
192.168.24.0/24 *[BGP/170] 5d 23:42:42, MED 0, localpref 100, from 192.168.24.1
AS path: I
> to 10.0.15.1 via ge-3/0/0.0, Push 251047
192.168.24.1/32 *[IS-IS/18] 01:24:42, metric 30, tag 2
> to 10.0.15.1 via ge-3/0/0.0

inet.3: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

192.168.8.1/32 *[LDP/9] 00:14:18, metric 1

> to 10.0.15.1 via ge-3/0/0.0
192.168.24.1/32 *[LDP/9] 00:13:55, metric 1
> to 10.0.15.1 via ge-3/0/0.0, Push 251047
LDP is considered an LSPs-gone-wild situation in that they are created based upon the IGP routes installed already.
When LDP is configured, LSPs are created for each of the destination prefixes listed in the routing table.
This section showed the steps necessary to build a minimal configuration for static, RSVP-based, and LDP- based LSPs.
This section also showed that static LSPs are configured at every hop along the LSP, whereas signaled LSPs are
configured only at the point of ingress. The case studies at the end of this chapter offer more details on configuring
LSPs including the use of constraints.

www.ebook-converter.com
CCCs
Up to now, this chapter has focused on MPLS and the use of LDP and RSVP in an MPLS implementation. It also
showed how LDP is used in most non-traffic-engineering scenarios, and how RSVP can be used in both MPLS LSP
establishment and traffic engineering. This section introduces CCCs, or circuit cross connects, and how they are applied
to the traffic-engineering model.
CCC is not directly related to MPLS and its operation, at least in the same regard as LDP or RSVP. However, there are
certain functions of CCC that can be used with MPLS LSPs to further enhance traffic-engineering capabilities. CCC is a
proprietary function of JUNOS and will not interoperate with other vendors' systems.
CCC is a tool used to map two Layer 2 circuits of the same type within a router to each other. This functionality
expands JUNOS-based routers from typical Layer 3 operations to perform Layer 2 switching. This functionality offers
the ability to perform essential flow functions without having to go through a series of decapsulation and encapsulation
functions first. This means that flow control functions can be processed at Layer 2, versus having to decapsulate the
Layer 2 frame, analyze the Layer 3 information, encapsulate back to Layer 2, then forward. CCC also yields the ability

Downloader demo watermarks

to switch frames from inbound interfaces to outbound interfaces based on predetermined Layer 2 associations. The
Layer 3 header is never examined.
There are three types of cross connects supported by JUNOS:
1. Layer 2 switching—can only be performed on logical interfaces such as Frame Relay DLCIs, ATM virtual circuits,
Ethernet VLANs, and PPP interfaces
510
 12. MPLS and Traffic Engineering
2. MPLS tunneling—takes advantage of being able to connect to nonlocal circuits of the same interface type by
creating an MPLS tunnel between the two systems
3. LSP stitching—allows two LSPs that terminate on one given router to be stitched together
All Layer 2 and MPLS tunneling functions are bidirectional in nature. This is due in part to how the cross connects are
created. LSP stitching, on the other hand, is unidirectional. As was mentioned in Section 12.3.1.2, LSPs are created in a
unidirectional manner; thus, two LSPs would be needed for bidirectional communication between networks residing on
the ingress and egress routers.
Figure 12-11 illustrates this concept. It shows a simple scenario using Frame Relay interfaces. Routers Chicago and
New York can be any customer router using Frame Relay to connect to router San Francisco. With CCC it is possible to
cross connect DLCI 201 to 203 in router San Francisco. This would eliminate having to extract Layer 3 packets from
the Frame Relay frame and make a Layer 3 decision, encapsulate back to Frame Relay, and send out to New York.

Figure 12-11. MPLS and CCC Sample Topology

In Figure 12-11, PPP, ATM VCs, Cisco HDLC, or VLANs could have easily been used as the Layer 2 technology
instead of Frame Relay. The point here is that in certain scenarios, CCC can become a more efficient method of
forwarding. It is important to reiterate that when using CCC, the circuit types must be the same. For example, it is not
possible to build a CCC between a Frame Relay link with DLCI 201 and an ATM link with a VC 203.
CCC works with Layer 2 of the OSI model. If Layer 3 addressing is on the interface being used for CCC, then the
configuration will not commit. The following example shows the CCC configuration sample necessary to establish the

www.ebook-converter.com
connection.
[edit protocols connections interface-switch Chicago-NewYork]
lab@SanFran# set interface at-1/2/1.100

[edit protocols connections interface-switch Chicago-NewYork]

lab@SanFran# set interface at-1/2/0.100

[edit protocols connections interface-switch Chicago-NewYork]

lab@SanFran# up

[edit protocols connections]

lab@SanFran# show
interface-switch Chicago-NewYork {
interface at-1/2/1.100;
interface at-1/2/0.100;
}

Downloader demo watermarks

In addition to the CCC connection configuration, it is necessary to specify under the interface the type of encapsulation
for the logical unit.
The next example shows configuring the switch interface on the router doing the switching:
[edit interfaces]

511
 12. MPLS and Traffic Engineering
lab@SanFran# set interface-switch frame-relay-ccc
[edit interfaces]
lab@SanFran# edit so-1/0/0 unit 0

[edit interfaces so-1/0/0 unit 0]

lab@SanFran# set encapsulation frame-relay-ccc

[edit interfaces so-1/0/0 unit 0]

lab@SanFran# exit

[edit interfaces]
lab@SanFran# show
interface-switch frame-relay-ccc;
so-1/0/0 {
unit 0 {
point-to-point;
encapsulation frame-relay-ccc;
dlci 501;
}
}

Chapter Summary
This chapter describe some of the past and current traffic-engineering implementations. It identified the problems that
traffic engineering is intended to solve. It described different options for traffic engineering and focused on MPLS as
the most complete option available. The chapter also pointed out the need for full awareness of not only the logical
routed portion of a network, but also the underlying transport mechanisms, and physical topology. This chapter
provided an overview of MPLS and its base operation functions, including label assignment. Following the discussion of

www.ebook-converter.com
label assignment, this chapter introduced methods of configuring LSPs, including static, signaled, and signaled with
constraints. The signaling protocols in this chapter included RSVP and LDP. This chapter also discussed the TED and its
relationship to CSPF. The section covering CCC also defined a method for traffic engineering at Layer 2 of the OSI
reference model.

Bibliography
Case Study 1: Prefix Mapping and BGP
This case study continues to use the same topology used for most of the signaled LSP examples earlier in this chapter.
Figure 12-10 shows the topology used. Earlier in the chapter, the focus was on the ingress and egress points of the LSP
with a few quick looks at some of the transit LSRs. This section will focus more on using MPLS LSPs and how to get
from specific networks to the LSP destination. In Figure 12-10, Tokyo has network 192.168.10.0/30 attached.
The configuration sample below shows that interface fe-1/0/0 is set up as an IS-IS passive interface in the IGP. The
example below also shows the output of the show route 192.168.10.0/30 command, which demonstrates that
this route is known by IS-IS.

Downloader demo watermarks

[edit protocols isis]
lab@Chicago# show
interface {
fe-1/0/0 passive;
}

512
 12. MPLS and Traffic Engineering
[edit protocols isis]
lab@Chicago# exit configuration-mode

lab@Chicago> show route 192.168.10.0/30

inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

192.168.10.0/30 *[IS-IS/18] 00:00:12, metric 40, tag 2

> to 10.0.15.1 via ge-3/0/0.0
The interface address for this network is 192.168.10.2. The passive statement is now removed from the IS-IS
protocol, referring to interface fe-1/0/0, which is 192.168.10.2.
[edit protocols isis]
lab@Chicago# delete interface fe-1/0/0 passive

[edit protocols isis]

lab@Chicago# show
interface {
fe-1/0/0;
}
After this configuration change is committed, the show route 192.168.10.0/30 command does not return
anything, indicating that the prefix is no longer reachable by the IS-IS protocol.
lab@Chicago> show route 192.168.10.0/30

www.ebook-converter.com
lab@Chicago>
The next configuration sample shows the addition of an LSP mapped to a destination prefix on the egress router.
[edit protocols rsvp]
lab@Chicago# set interface all

[edit protocols rsvp]

lab@Chicago# set interface fxp0 disable

[edit protocols rsvp]

lab@Chicago# up

[edit protocols]
lab@Chicago# edit mpls

[edit protocols mpls]

lab@Chicago# set interface all

Downloader demo watermarks

[edit protocols mpls]
lab@Chicago# edit label-switched-path 1

[edit protocols mpls label-switched-path 1]

lab@Chicago# set to 192.168.24.1

513
 12. MPLS and Traffic Engineering
[edit protocols mpls label-switched-path 1]
lab@Chicago# set install 192.168.10.0/30

[edit protocols mpls label-switched-path 1]

lab@Chicago# set no-cspf

[edit protocols mpls label-switched-path 1]

lab@Chicago# exit

[edit protocols mpls]

lab@Chicago# exit

[edit protocols]
lab@Chicago# show
rsvp {
interface all;
}
mpls {
label-switched-path example1 {
to 192.168.24.1;
install 20.171.15.0/30;
no-cspf;
}
interface all;
}
The example below shows the routing table for network 192.168.10.0/30 installed in inet.3. However, if an
attempt is made to ping or run a traceroute, no route is found because inet.3 is only used for BGP next-hop
resolution.

www.ebook-converter.com
lab@Chicago> show route 192.168.10.0/30

inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

192.168.10.0/30 *[RSVP/7] 00:00:11, metric 30, metric2 0

> to 10.0.15.1 via ge-3/0/0.0, label-switched-path example1
lab@Chicago> traceroute 192.168.10.0
traceroute to 192.168.10.0 (192.168.10.0), 30 hops max, 40 byte packets
traceroute: sendto: No route to host
1 traceroute: wrote 192.168.10.0 40 chars, ret=-1
*traceroute: sendto: No route to host
traceroute: wrote 192.168.10.0 40 chars, ret=-1
*traceroute: sendto: No route to host
traceroute: wrote 192.168.10.0 40 chars, ret=-1
When the active switch is added to the same configuration, then the traceroute will use the LSP because it has

Downloader demo watermarks

now been added to the inet.0 routing table.
[edit protocols mpls label-switched-path 1]
lab@Chicago# set install 192.168.10.0/30 active

[edit protocols mpls label-switched-path 1]

514
 12. MPLS and Traffic Engineering
lab@Chicago# show
to 192.168.24.1;
install 192.168.10.0/30 active;
no-cspf;
}

lab@Chicago# commit
The traceroute for the network goes through the LSP to get to 192.168.10.1.
lab@Chicago> traceroute 192.168.10.1
traceroute to 192.168.10.1 (192.168.10.1), 30 hops max, 40 byte packets
1 10.0.15.1 (10.0.15.1) 0.973 ms 0.779 ms 0.715 ms
MPLS Label=251050 CoS=0 TTL=1 S=1
2 10.0.13.2 (10.0.13.2) 0.780 ms 0.702 ms 0.681 ms
MPLS Label=100312 CoS=0 TTL=1 S=1
3 10.0.31.1 (10.0.31.1) 0.551 ms 0.532 ms 0.511 ms
4 192.168.10.1 (192.168.10.1) 0.499 ms 0.475 ms 0.453 ms
When the active switch is added to the end of the install statement, it takes the route and installs it into inet.0.
BGP would still reference the route if necessary for next-hop resolution.
The next configuration sample takes a look at something that at first might seem a bit peculiar. First, the interface fe-
1/0/0 is put back into IS-IS as a passive interface. After this change is committed, both routes are installed, and the
LSP is the active one. This is because they are both in inet.0 and MPLS routes have a protocol preference of 7
versus 18 for IS-IS routes. This is shown in the configuration sample below.
[edit protocols isis]
lab@Chicago# set interface fe-1/0/0 passive

www.ebook-converter.com
lab@Chicago> show route 192.168.10.0

inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

192.168.10.0/30 *[RSVP/7] 00:03:27, metric 30, metric2 0

> to 10.0.15.1 via ge-3/0/0.0, label-switched-path 1
[IS-IS/18] 00:00:14, metric 40, tag 2
> to 10.0.15.1 via ge-3/0/0.0
In the next example, the active switch is removed from the LSP configuration. As can be seen below, the IS-IS route is
active.
[edit protocols mpls label-switched-path 1]
lab@Chicago# delete install 192.168.10.0/30 active

[edit protocols mpls label-switched-path 1]

Downloader demo watermarks

lab@Chicago# show
to 192.168.24.1;
install 192.168.10.0/30;
no-cspf;
}

[edit protocols mpls label-switched-path 1]

515
 12. MPLS and Traffic Engineering
lab@Chicago# commit and-quit
commit

lab@Chicago> show route 192.168.10.0

inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

192.168.10.0/30 *[IS-IS/18] 00:03:43, metric 40, tag 2

> to 10.0.15.1 via ge-3/0/0.0

inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

192.168.10.0/30 *[RSVP/7] 00:00:08, metric 30, metric2 0

> to 10.0.15.1 via ge-3/0/0.0, label-switched-path 1
The following example shows a traceroute to 192.168.10.1. Once again, the IGP route is most favorable.
lab@Chicago> traceroute 192.168.10.1
traceroute to 192.168.10.1 (192.168.10.1), 30 hops max, 40 byte packets
1 10.0.15.1 (10.0.15.1) 0.667 ms 0.558 ms 0.512 ms
2 10.0.13.2 (10.0.13.2) 0.543 ms 0.528 ms 0.506 ms
10.0.31.1 (10.0.31.1) 0.544 ms 0.527 ms 0.513 ms
192.168.10.1 (192.168.10.1) 0.482 ms 0.467 ms 0.598 ms

Case Study 2: Using Constraints in RSVP LSPs

This study shows the addition of two simple constraints to the RSVP LSP configuration. Additionally, it offers an

www.ebook-converter.com
opportunity to see the primary and secondary LSP functions. It also shows how to use the traffic-engineering
statement to place routes in inet.0 and inet.3.
The topology for this study is shown in Figure 12-11. Here, two routing paths for the primary and secondary LSPs are
established. These will travel from Chicago to Tokyo. The primary path will be established through San Francisco, New
York, and London, while the secondary path will be established through Brussels and Amsterdam.
The path command is used in the MPLS configuration as shown next. In the following example, two constraints have
been configured. Both are loose constraints. Path Tokyo-primary will force the LSP to traverse through New
York, while path Tokyo-secondary will force the LSP to traverse through Amsterdam.
[edit protocols mpls]
lab@Chicago# edit label-switched-path Tokyo

[edit protocols mpls label-switched-path Tokyo]

lab@Chicago# set to 192.168.24.1

[edit protocols mpls label-switched-path Tokyo]

Downloader demo watermarks
lab@Chicago# set primary Tokyo-primary

[edit protocols mpls label-switched-path Tokyo]

lab@Chicago# up

[edit protocols mpls]

516
 12. MPLS and Traffic Engineering
lab@Chicago# edit label-switched-path Tokyo-backup

[edit protocols mpls label-switched-path Tokyo-backup]

lab@Chicago# set to 192.168.24.1

[edit protocols mpls label-switched-path Tokyo-backup]

lab@Chicago# set secondary Tokyo-secondary
[edit protocols mpls label-switched-path Tokyo-backup]
lab@Chicago# up

[edit protocols mpls]

lab@Chicago# set path Tokyo-primary 192.168.5.1 loose

[edit protocols mpls]

lab@Chicago# set path Tokyo-secondary 192.168.12.1 loose

[edit protocols mpls]

lab@Chicago# set interface all

[edit protocols mpls]

lab@Chicago# show
mpls {
label-switched-path Tokyo {
to 192.168.24.1;
primary Tokyo-primary;
}
label-switched-path Tokyo-backup {
to 192.168.24.1;
secondary Tokyo-secondary;

www.ebook-converter.com
}
path Tokyo-primary {

}
192.168.5.1 loose;

path Tokyo-secondary {
192.168.12.1 loose;
}
interface all;
}
Now that the paths have been configured and committed, the results can be seen by using the show mpls lsp
command. The example below shows that there are two LSPs that have been created, and they are both up.
lab@Cicago> show mpls lsp
Ingress LSP: 2 sessions
To From State Rt ActivePath P LSPname
192.168.24.1 192.168.16.1 Up 1 Tokyo * Tokyo
192.168.24.1 192.168.16.1 Up 0 Tokyo-backup Tokyo-backup

Downloader demo watermarks

Total 2 displayed, Up 2, Down 0

Egress LSP: 0 sessions

Total 0 displayed, Up 0, Down 0

Transit LSP: 0 sessions

517
 12. MPLS and Traffic Engineering
Total 0 displayed, Up 0, Down 0
The next example shows the results of the show mpls lsp extensive command. This command shows the path
that each LSP is taking. In addition, it is possible to see the differences in metrics between the two paths.
lab@Chicago> show mpls lsp extensive
Ingress LSP: 2 sessions

192.168.24.1
From: 192.168.16.1, State: Up, ActiveRoute: 1, LSPname: Tokyo
ActivePath: Tokyo (primary)
LoadBalance: Random
*Primary Tokyo State: Up
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 40)
10.0.16.2 S 10.0.0.2 S 10.0.2.1 S 10.0.24.2 S
Received RRO (S [L] denotes strict [loose] hops):
10.0.16.2 S 10.0.0.2 S 10.0.2.1 S 10.0.24.2 S
6 Jan 2 07:49:33 Selected as active path
5 Jan 2 07:49:33 Record Route: 10.0.16.2 S 10.0.0.2 S 10.0.2.1 S 10.0.24.2 S
4 Jan 2 07:49:33 Up
3 Jan 2 07:49:33 Originate Call
2 Jan 2 07:49:33 CSPF: computation result accepted
1 Jan 2 07:49:04 CSPF failed: no route toward 192.168.5.1
Created: Wed Jan 2 07:49:03 2002
192.168.24.1
From: 192.168.16.1, State: Up, ActiveRoute: 0, LSPname: Tokyo-secondary
ActivePath: Tokyo-backup (secondary)
LoadBalance: Random
*Secondary Tokyo-backup State: Up

www.ebook-converter.com
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30)
10.0.15.1 S 10.0.13.2 S 10.0.31.1 S
Received RRO (S [L] denotes strict [loose] hops):
10.0.15.1 S 10.0.13.2 S 10.0.31.1 S
6 Jan 2 07:49:34 Selected as active path
5 Jan 2 07:49:34 Record Route: 10.0.15.1 S 10.0.13.2 S 10.0.31.1 S
4 Jan 2 07:49:34 Up
3 Jan 2 07:49:33 Originate Call
2 Jan 2 07:49:33 CSPF: computation result accepted
1 Jan 2 07:49:04 CSPF failed: no route toward 192.168.12.1
Created: Wed Jan 2 07:49:03 2002
Total 2 displayed, Up 2, Down 0

Egress LSP: 0 sessions

Total 0 displayed, Up 0, Down 0

Transit LSP: 0 sessions

Total 0 displayed, Up 0, Down 0

Downloader demo watermarks

The next sample of output from the CLI shows that the LSP is listed in inet.3 and the IS-IS route is listed in inet.0.
lab@Chicago> show route 192.168.24.1

inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)

518
 12. MPLS and Traffic Engineering
+ = Active Route, - = Last Active, * = Both

192.168.24.1/32 *[IS-IS/18] 00:26:09, metric 30, tag 2

> to 10.0.15.1 via ge-3/0/0.0

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

192.168.24.1/32 *[RSVP/7] 00:20:04, metric 30, metric2 0

via at-2/1/0.100, label-switched-path Tokyo
to 10.0.15.1 via ge-3/0/0.0, label-switched-path Tokyo
There are several ways to get the LSP into the inet.0 table. Once in the inet.0 routing table, the LSP can be used
by protocols other than BGP for traffic forwarding. In this example, the set protocols mpls traffic-
engineering bgp-igp command is used to force the LSP into inet.0. The configuration for this scenario
follows:
[edit]
lab@Chicago# set protocols mpls traffic-engineering bgp-igp

[edit]
lab@Chicago# show protocols mpls traffic-engineering
bgp-igp;
A show route command demonstrates that both the IS-IS route and RSVP route are now listed in inet.0.
lab@Chicago> show route 192.168.24.1

inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)

www.ebook-converter.com
+ = Active Route, - = Last Active, * = Both
192.168.24.1/32 *[RSVP/7] 00:04:36, metric 30, metric2 0
via at-2/1/0.100, label-switched-path Tokyo
> to 10.0.15.1 via ge-3/0/0.0, label-switched-path Tokyo-
backup
[IS-IS/18] 00:04:40, metric 30, tag 2
> to 10.0.15.1 via ge-3/0/0.0
In the following example, a link in the primary path has been broken, making it possible to observe how the routing
table changes over to using the configured secondary path. Only one LSP, Tokyo-backup and the IS-IS route are
visible in the routing table.
lab@Chicago> show route 192.168.24.1

inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

Downloader demo watermarks

192.168.24.1/32

backup
*[RSVP/7] 00:07:09, metric 30, metric2 0
> to 10.0.15.1 via ge-3/0/0.0, label-switched-path Tokyo-

[IS-IS/18] 00:07:13, metric 30, tag 2

to 10.0.15.1 via ge-3/0/0.0
This case study demonstrated the configuration of redundant LSPs. It also explored some of the commands used to
519
 12. MPLS and Traffic Engineering
verify LSP functionality and view the impact of various configuration options on the routing tables.

Case Study 3: CCC Configuration

This case study shows how to switch an ATM VC in the Juniper Networks M-Series router. Figure 12-12 shows the
topology that will be used for this case study. In this scenario, San Francisco will switch two ATM VCs. Router Chicago
connects to San Francisco via ATM. Router New York connects to San Francisco via ATM as well.

Figure 12-12. CCC Topology for Case Study 3

The sample below shows the interface configuration for New York. This router does not need any custom configuration
above and beyond the normal ATM settings to make CCC work on San Francisco.
[edit]
lab@Chicago# show interfaces
at-1/2/0 {
atm-options {
vpi 0 maximum-vcs 200;
}
unit 100 {
vci 0.100;
family inet {
address 10.0.0.1/24;
}

www.ebook-converter.com
}
}

lab@NewYork# show interfaces

at-6/2/0 {
atm-options {
vpi 0 maximum-vcs 200;
}
unit 100 {
vci 0.100;
family inet {
address 10.0.0.2/24;
}
}
}
The next example shows the configuration for router San Francisco. Notice the configurational differences between

Downloader demo watermarks

Chicago and San Francisco. Herein is the addition in the protocol hierarchy that accomplishes the CCC. The interfaces
involved are being used to make this cross connect. In addition, the interface configurations do not have any Layer 3
addressing on them. As this is a Layer 2 connection (Layer 2 switching) there is no need for Layer 3 addressing. As a
matter of fact, JUNOS will fail the self check (commit) of the configuration for CCC if Layer 3 addresses are assigned
to the interfaces being switched.

520
 12. MPLS and Traffic Engineering
[edit interfaces at-1/2/0]
lab@SanFran# set atm-options vpi 0 maximum vcs 200

[edit interfaces at-1/2/0]

lab@SanFran# edit unit 100

[edit interfaces at-1/2/0 unit 100]

lab@SanFran# set encapsulation atm-ccc-vc-mux

[edit interfaces at-1/2/0 unit 100]

lab@SanFran# set vci 0.100

[edit interfaces at-1/2/0 unit 100]

lab@SanFran# top

[edit]
lab@SanFran# edit interfaces at-1/2/1

[edit interfaces at-1/2/1]

lab@SanFran# set atm-options vpi 0 maximum vcs 200

[edit interfaces at-1/2/1]

lab@SanFran# edit unit 100

[edit interfaces at-1/2/1 unit 100]

lab@SanFran# set encapsulation atm-ccc-vc-mux

[edit interfaces at-1/2/1 unit 100]

lab@SanFran# set vci 0.100

www.ebook-converter.com
[edit interfaces at-1/2/1 unit 100]
lab@SanFran# top

[edit]
lab@SanFran# edit protocols connections interface-switch Chicago-NewYork
[edit protocols connections interface-switch Chicago-NewYork]
lab@SanFran# set interface at-1/2/1.100

[edit protocols connections interface-switch Chicago-NewYork]

lab@SanFran# set interface at-1/2/0.100

[edit protocols connections interface-switch Chicago-NewYork]

lab@SanFran# commit

[edit protocols connections interface-switch Chicago-NewYork]

lab@SanFran# top

Downloader demo watermarks

[edit]
lab@SanFran# show interfaces
at-1/2/0 {
atm-options {
vpi 0 maximum-vcs 200;
521
 12. MPLS and Traffic Engineering
}
unit 100 {
encapsulation atm-ccc-vc-mux;
vci 0.100;
}
}
at-1/2/1 {
atm-options {
vpi 0 maximum-vcs 200;
}
unit 100 {
encapsulation atm-ccc-vc-mux;
vci 0.100;
}
}

[edit]
lab@SanFran# show protocols
connections {
interface-switch Chicago-NewYork{
interface at-1/2/1.100;
interface at-1/2/0.100;
}
}
To further validate the configuration, it is necessary to check the routing tables. The examples below show the relevant
contents of the routing table for LSRs Chicago and New York, respectively. IS-IS is used for the IGP on Chicago and
New York. In this case study, Chicago has a route to the configured loopback address for New York, and New York has
a route to the configured loopback address for Chicago.

www.ebook-converter.com
lab@Chicago > show route 192.168.2.1

inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

192.168.2.1/32 *[IS-IS/18] 01:19:04, metric 10, tag 2

> to 10.0.0.2 via at-1/2/0.100

lab@NewYork> show route 192.168.0.1

inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

192.168.0.1/32 *[IS-IS/18] 01:21:20, metric 10, tag 2

> to 10.0.0.1 via at-6/2/0.100

Downloader demo watermarks

The presence of these IS-IS routes in the routing tables of Chicago and New York indicates that the CCC connection is
working.
This case study demonstrated the configuration components necessary to enable CCC on a Juniper Networks M-Series
router. It also demonstrated that a simple show route command can be used to confirm the functionality of the CCC.

522
[ch12bib01] “Extensions to RSVP for LSP Tunnels,” Internet-Draft, draft-ietf-mpls-rsvp-
lsp-tunnel-05.txt.
[ch12bib02] Eric W Gray,. MPLS: Implementing the Technology. Addison-Wesley,
<year>2001</year>.
[ch12bib03] “ICMP Extensions for Multiprotocol Label Switching,” Internet-Draft,
draft-ietf-mpls-icmp-02.txt.
[ch12rfc2205] IETF RFC—RFC 2205, Resource ReSerVation Protocol (RSVP) Version
1 Functional Specification. B. Braden, et al. 1997.
[ch12rfc2209] IETF RFC—RFC 2209, Resource Reservation Protocol (RSVP) Version 1
Message Processing Rules. B. Braden, L. Zhang. 1997.
[ch12rfc2210] IETF RFC—RFC 2210, The Use of RSVP with IETF Integrated Services.
J. Wroclawski. 1997.
[ch12rfc2211] IETF RFC—RFC 2211, Specification of the Controlled-Load Network
Element Service. J. Wroclawski. 1997.
[ch12rfc2215] IETF RFC—RFC 2215, General Characterization Parameters for
www.ebook-converter.com
Integrated Service Network Elements. S. Shenker, J. Wroclawski. 1997.
[ch12rfc2216] IETF RFC—RFC 2216, Network Element Service Specification Template.
S. Shenker, J. Wroclawski. 1997.
[ch12rfc2702] IETF RFC—RFC 2702, Requirements for Traffic Engineering over
MPLS. D. O. Awduche, et al. 1999.
[ch12rfc2747] IETF RFC—RFC 2747, RSVP Cryptographic Authentication. F. Baker,
Lindell B,, M. Talwar. 2000.
[ch12rfc3031] IETF RFC—RFC 3031, Multiprotocol Label Switching Architecture. E. C.
Rosen, et al. 2001.

Downloader demo watermarks

[ch12rfc3032] IETF RFC—RFC 3032, MPLS Label Stack Encoding. E. C. Rosen, et al.
2001.
[ch12rfc3036] IETF RFC—RFC 3036, LDP Specification. L. Andersson, et al. 2001.
523
[ch12rfc3037] IETF RFC—RFC 3037, LDP Applicability. E. Gray, B. Thomas. 2001.
[ch12rfc3097] IETF RFC—RFC 3097, RSVP Cryptographic Authentication—Updated
Message Type Value. B. Braden, L. Zhang. 2001.
[ch12bib17] “IS-IS Extensions for Traffic Engineering,” Internet-Draft, draft-ietf-isis-
traffic-02.txt.
[ch12bib18] JUNOS Internet Software Configuration Guide: MPLS Applications,
Release 5.0. Juniper Networks, <year>2001</year>.
[ch12bib19] JUNOS Internet Software Configuration Guide: Routing and Routing
Protocols, Release 5.0. Juniper Networks, <year>2001</year>.
[ch12bib20] JUNOS Internet Software Operational Mode Command Reference, Release
5.0. Juniper Networks, <year>2001</year>.
[ch12bib21] “Label Distribution Protocol (LDP)—Version 1 Functional Specification,”
Internet-Draft, draft-ietf-mpls-ldp-06.txt.
[ch12bib22] “RSVP Refresh Reduction Extensions,” Internet-Draft, draft-ietf-rsvp-
refresh-educt-05.txt.
www.ebook-converter.com
[ch12bib23] “Traffic Engineering Extension to OSPF,” Internet-Draft, draft-katz-yeung-
ospf-traffic-04.txt.
[ch12bib24] www.juniper.net

Downloader demo watermarks

524
 13. Virtual Private Networks
Chapter 13. Virtual Private Networks
The demand for VPNs is growing each day. VPNs today give customers many different options for connectivity between
multiple sites across a shared infrastructure. Today's VPNs also serve to provide more reliable, scalable, and cost-effective
ways for service providers to offer services to customers, utilizing their existing IP infrastructures. This chapter describes the
different design models and network topologies used when implementing VPNs. In addition, it will cover some of the
different VPN applications and business cases for their use. After allowing the reader to become familiar with this technology,
case studies will be used to shift gears and focus primarily on the implementation and configuration of BGP/MPLS VPNs.
This is the RFC 2547bis implementation of Layer 3 VPNs that is supported by the Juniper Networks routers.

Overview of VPNs
VPNs were initially introduced through technologies such as Frame Relay and ATM. These technologies make use of virtual
circuits for communicating between devices. These virtual connections are private and identified by a DLCI or VPI/VCI.
These identifiers are used to keep different users' traffic in different circuits, while passing the traffic on the same physical
infrastructure. Thus the term “virtual private network has evolved from the private circuits of the past to the very secure and
separate networks seen today.”
The key concept that has remained the same with VPNs is that the data of many different customers' traffic can be sent
across the same physical medium, but separated by using the virtual connection. As VPNs continue to evolve, new and better
ways are being found to implement the technology. Modern-day VPN technology service providers are using VPNs to help
reduce costs for themselves and their customers by replacing multiple networks, whether they are Frame Relay leased line or
otherwise, while still providing similar service offerings to their customers.
To provide a more thorough understanding of VPN technology and its implementations, it is necessary first to introduce some
of the terms used in the world of VPNs. This section identifies the devices used in BGP/MPLS VPNs, and the network
displayed in Figure 13-1 gives a general topological view of a VPN-enabled network. Notice the customer edge, or CE,
device. This is typically customer-premise equipment that connects to the provider's network and is usually a router or a
switch. The provider edge, or PE, device is a router located in the provider network that connects to the CE devices. These

www.ebook-converter.com
routers support VPN and label capabilities. PE routers are connected across the provider network through tunnels. The
provider router (P) devices are routers that are used in the core of the service provider network and do not connect to any CE
devices. The P routers must support MPLS, but do not have to support VPN functionality. These routers are used as a part of
the physical path that makes up the logical tunnel between the PE routers.

Figure 13-1. VPN Routers

VPN Implementation and Topologies

Downloader demo watermarks
With today's VPNs come many different implementations. There are different models referred to when using VPNs. The
overlay model and the peer-to-peer model are the two most commonly used. The overlay model is one in which the
traditional network-layer forwarding path is built on top of an underlying infrastructure, like ATM or Frame Relay.
In the overlay model, there are two separate networks, each having their own control and forwarding mechanism (e.g.,

525
 13. Virtual Private Networks
routing table). For example, to route a packet in an IP network that is overlaid on a Frame Relay network, it would be
necessary to know the IP next-hop address (Layer 3) to reach the packet's destination network. Once the IP next-hop address
is determined, then a lookup must be done to find out which Frame Relay DLCI (Layer 2) is needed for the traffic to be
shipped across the overlay network. Thus, there exists one set of control and forwarding mechanisms for the IP network and
another for the Frame Relay network. Figure 13-2 shows an overlay model example. The network being used is made up of
three CE sites connected over a Frame Relay network. The connection between each site is a Frame Relay PVC. The Layer 2
Frame Relay topology determines the forwarding path. IP VPN traffic would be forwarded over the PVCs that connect each
site.

Figure 13-2. VPN Overlay Model

In the peer-to-peer model, shown in Figure 13-3, routing is simplified due to the minimal connections required in order for the
customer to achieve any-to-any communications. In this implementation, each customer site will only need to be connected
to a PE router. The service provider will ensure optimal routing and connectivity for the customer's sites through an exchange
of VPN routing information between PE routers. This benefit greatly reduces the number of connections that would be

www.ebook-converter.com
required if an overlay model were used. Another benefit that the peer-to-peer model offers is a single connection to bring
additional sites on line. In the overlay model, when adding a new site, a new virtual circuit from the newly added site may
need to be added to each of the existing sites in the VPN. The single-connection requirement can bring significant cost
savings to customers and reduce the complexity of their network configuration management responsibilities.

Downloader demo watermarks

Figure 13-3. The Peer-to-Peer Model

VPN Physical Topologies

When building networks to support VPNs, various physical topologies can be used, including hub-and-spoke, full-mesh, and

526
 13. Virtual Private Networks
partial-mesh. These topologies used for VPNs are very similar to those that would normally be seen in Frame Relay or ATM
networks. A quick overview of each will be given. The hub-and-spoke is a configuration with several remote sites all having
connections to one central site. With VPN implementations these connections can exist between CE routers and PE routers.
Figure 13-4 examines a VPN hub-and-spoke topology; Washington D.C. and San Francisco are the CE spokes with
connections through the provider net work to CE hub Dallas. Notice that in the VPN deployment there are two hub-and-
spoke configurations. One type of VPN implementation uses the provider's equipment and another uses the customer's
equipment for connectivity.

Figure 13-4. Hub-and-Spoke Topology

The full-mesh topology provides a connection from every site to every site, allowing greater redundancy in the event of a
failure. In a majority of environments, the hub-and-spoke topology is chosen due the large number of VCs required to
implement a full-mesh, which can drastically increase on the amount of money required to implement the full-mesh solution,
as well as the administrative burden of managing the network. With all of that said, this solution might be necessary in some
environments that may require that additional level of redundancy and resiliency. The partial-mesh may be more suitable for

www.ebook-converter.com
the global company that finds it more economical to exchange information between sites within the same country, as opposed
to paying for long-haul cross-ocean links from a central site to all of the remote sites.

Figure 13-5. Full-Mesh Topology

Downloader demo watermarks

Dedicated Extranet VPN
Dedicated extranet VPNs use VPNs to allow any-to-any communications between different companies. This type of VPN
allows sharing of external data between separate companies and enables companies to exchange data with each other over
the Internet with a specific level of security. The extranet topology can be implemented with either the overlay model or the

527
 13. Virtual Private Networks
peer-to-peer model. A dedicated extranet topology could be used to construct a network of VPNs that would allow any-to-
any communications for a company and its partners. This type of implementation can assist in increasing productivity for an
organization by allowing the many businesses to exchange information freely to enhance productivity for each organization.
The organizations involved would usually be in the same industry, for example the airlines and the travel agents. One might
ask, why not just use the Internet to provide this any-to-any communication? That is not a bad idea, but what about the
quality of the communication? This extranet implementation is used to provide the QoS levels required for dependable data
transfer. Figure 13-6 shows an example of a full-mesh dedicated extranet application. The airline network and travel agent
network are both made up of two sites. Through this configuration, VPNs will be created that will allow any one of the CE
sites to communicate with any other CE site.

Figure 13-6. Dedicated Extranet Application

Centralized Extranet VPN

www.ebook-converter.com
The centralized extranet differs from the dedicated extranet by providing more restricted communications between sites.
Instead of any-to-any communications, the centralized extranet allows data exchange between a central site and the allowed
remote sites. In this implementation, the remote sites do not exchange data with each other; instead, they exchange data only
with the central site. This implementation is like the traditional hub-and-spoke overlay model. There is one central site or hub
and several remote sites or spokes. The spokes sites do not talk to each other; rather, they talk to the hub only. Centralized
extranet VPNs exist because they are an effective way to allow secure data exchange between a central site and many remote
sites. This security feature comes from the fact that, in this implementation, the policy defined in the software configuration
will control which sites will be able to access the hub's, or central site's, data. Any site does not have carte blanche to access
any other site; instead, access is limited to one location. Figure 13-7 shows an application that might be used with this
implementation. In this example, the hospital CE router is the central site, and the drug, linen, and medical equipment
companies are the remote sites. Data exchange would be allowed between the drug company and the hospital, and between
the linen company and the hospital, but not between the drug company and the linen company.

Downloader demo watermarks

528
 13. Virtual Private Networks

Figure 13-7. Centralized Extranet Application

Layer 3 VPNs
Service providers can implement VPN services for their customers over their existing IP infrastructures (see RFC 2547bis for
details). In this implementation, the VPN is made up of a collection of different routers that includes the P and PE routers.
These are the routers belonging to the provider that exchange routing information with each other using the service provider's
existing infrastructure. These types of VPNs are known as BGP/MPLS VPNs because they use BGP to distribute the VPN
routing information, while MPLS provides the forwarding mechanism for VPN traffic.
These types of VPNs are made up of customer equipment and provider equipment. The customer equipment is the router
located at each customer's site, and the provider equipment is in the service provider's network. In this configuration, the
provider's network will function as the glue to connect the customers' sites together. To keep one customer's traffic separate
from another's, the provider will implement different types of policy that govern how traffic from different customers will be
treated. Customers will have at least one VPN configured by the provider that will carry only their traffic. The service

www.ebook-converter.com
provider can support many VPNs, but must ensure that traffic from one VPN is not mixed with traffic from another. The
customer connecting to the provider's network and using the VPN can choose to use either public addressing or private
addressing as defined in RFC 1918.
The following sections describe BGP/MPLS VPN implementation based on RFC 2547bis. It explains how these VPNs
operate and how the supporting protocols, like BGP and MPLS, play a role in today's VPN implementations.

Route Distinguishers
If customers are using RFC 1918 addressing, it is possible for addresses to overlap between two different VPNs. This overlap
is tolerable because with this implementation of VPNs, there is a special identifier that is carried with the traffic to preserve
uniqueness. This VPN identifier is known as a route distinguisher (RD), which, as defined in RFC 2547, is used “to allow one
to create distinct routes to a common IPv4 address prefix.” The RD is a part of the VPN-IPv4 address family and is used to
identify the VPN routes exchanged between PE routers. The notation for the VPN-IPv4 identifier is a 12-byte field that
includes an 8-byte RD and a 4-byte IPv4 prefix. To break this down further, the RD field is divided into a 2-byte type field,
and a 6-byte value field. The value of the type field will determine the encoding used by the RD. In other words, if the
type field value is 0, then the RD will be encoded with an ASN. If the type field value is 1, then the RD will be an IP
address. Figure 13-8 shows the structure of the RD.

Downloader demo watermarks

529
 13. Virtual Private Networks

Figure 13-8. Route Distinguisher (RD)

This VPN-IPv4 address family is an address notation used by the multiprotocol extensions of BGP that allow BGP to carry
routes from multiple address families. Traditionally, BGP could only carry routes for IPv4. Through the use of these
multiprotocol extensions defined in RFC 2858, BGP can now carry routes from other address families. This is how the route
information that is exchanged between the service provider's PE routers is carried in 2547bis VPNs.
In this configuration, one PE router will service many different customers and will use the RD to prefix each customer's
routes to uniquely identify its traffic. Figure 13-9 shows an example of how the RD is being used. Let's say that PE router
Chicago has two different customer sites (CEs) connected using two different VPNs. The first site is Rome, and the other is
Seattle. When PE router Chicago advertises the received routes from the two CE sites, they will be uniquely identified with
an RD. The RD is represented either by an ASN and an assigned number or by an IP address and an assigned number. These
values are chosen when configuring the routing-instance for the VPN. The next example will use the ASN. Chicago
will add the RD 64000:100 to the route coming in from Rome and the RD 64000:200 for the route from Seattle. With the
use of the RD, the two different 172.16.0.0 networks can be uniquely identified. If an IP address is used in the RD instead
of an ASN, then the PE router will prefix the customer's routes with its own IP address. One uses the AS or a global IP simply

www.ebook-converter.com
to ensure uniqueness of the RD itself because these numbers are controlled. Hence, privately owned IP addresses or privately
owned ASNs are always used to populate these fields.

Figure 13-9. Using a Route Distinguisher (RD)

Downloader demo watermarks
In Figure 13-9, PE router New York receives the 10.100.0.0/16 routes from CE router Berlin and CE router Hong Kong.
The New York PE router will add an RD based on its own IP address to distinguish it from other routes with the same prefix.
The New York PE router will advertise the route from Berlin with an RD of 192.168.2.1:0 and the route from Hong
Kong with an RD of 192.168.2.1:1. This, again, will uniquely identify the routes coming from different customers. This
combination of the RD and the IP prefix is known as the VPNv4 address. The VPN routing information is distributed across
530
 13. Virtual Private Networks
the provider network and is exchanged between PE routers using BGP.
In this type of configuration, the provider's equipment includes the routers that make up their Internet network and provide
the VPN and other services to customers. The provider equipment used for VPN services can be defined as PE routers and P
routers. The PE routers are the workhorses of the service provider's VPN infrastructure. These routers connect the customer
equipment to the service provider's network and are used in the VPN service as the beginning point and endpoint of the
MPLS tunnel. These tunnels are used for forwarding the customer's traffic across the service provider's backbone. The PE
routers must be able to support VPN services and have MPLS functionality. The P router sits in the service provider's
infrastructure and does not connect to any customer equipment. It is used as a part of the MPLS path that the customer's
traffic will flow on. These routers must have MPLS functionality, but do not need to support VPN services as the PE routers
will initiate and terminate the VPN.
The customer equipment is made up of the CE router. The CE router is located on the customer's premises and is used to
connect to the service provider's network. The customer can announce to the service provider the networks that should be
used in the VPN by using static routes or configuring a dynamic routing protocol, such as RIP, OSPF, and BGP.

Note
In the JUNOS implementation, IS-IS for the CE router is not supported.

Forwarding Tables
As was mentioned earlier, BGP/MPLS VPNs use BGP to distribute routes. More specifically the PE routers will control how
routing information is distributed between other PE routers within the service provider network. Each of these PE routers will
maintain at least one per-site forwarding table. These forwarding tables will contain all of the route information learned from
the CE routers about all of the networks that they know about and want the PE routers to distribute to other PE routers and
all other CE routers in the same VPN.
The PE routers will only install routes into those per-site forwarding, or virtual routing and forwarding (VRF), tables learned

www.ebook-converter.com
from CE routers that are directly connected to the PE router or routes from the same VPN received from other PEs. All
routing look ups for packets destined for networks in the per-site-forwarding table will be handled within the VRF. If there
are packets destined for other networks the look up will be based on the standard IP routing table, inet.0. To control how
the routing information is distributed between the PE routers within the service provider network, the per-site forwarding
table will be associated with target VPNs or route targets.
The route target is a new BGP extended community attribute defined in RFC 2547 used to control how VPN routing
information is distributed between PE routers within the service provider network. When a VPN route is created, it will be
associated with one or more route-target attributes and carried in BGP as attributes of the route. This information will be used
to identify to each of the PE routers within the service provider network which routes belong to which VPN. Any route that is
marked as a VPN route and associated with a route target must be distributed to all PE routers that have the same route
target. When a PE router receives a BGP route with the route target attribute set, it identifies that route as eligible to be
installed in the per-site forwarding table. Whether or not the route is actually installed into the table is still based on the BGP
route decision process.
The route target has a type code of 16 and is encoded in 8 octets. Each extended community attribute has a type field and a
value field. The type field is either one or two bytes and the value field will be the remaining bytes. If the type field is
one byte, it defines a regular type; if it is two bytes, it defines an extended type. The first bit of the type field is the IANA
authority bit. If this bit is set to 0, it defines an IANA-assigned type; if it is set to 1, it defines a vendor-specific type. The
Downloader demo watermarks
second bit of the type field determines whether or not this is a transitive attribute. With the route target community used
with VPNs, the type field will be 0x0002 or 0x0102 (notice that the low-order byte is always 0x02). The values of these
fields are important in determining whether the assignment of the attribute was based on an IP address or ASN. If the type
field value is set to 0x00, it identifies that the assignment of this attribute is based on an ASN, while a value of 0x01 defines
an IP address. Another newly defined attribute used with VPNs is the site-of-origin attribute. This attribute is used to identify
the router or routers that inject routes into BGP. It is also transitive across the AS and is used to prevent routing loops
531
 13. Virtual Private Networks
between member sites in the VPN. Just like the route target community, the site of origin will have a high-order type field
value of either 0x00 or 0x01, and if this value is 0x00, the ASN in the local administrator field must be unique across the AS
defined in the global administrator field. The low-order byte for the route of origin will be 0x03.
Figure 13-10 explains how the route target community is used. When PE router Chicago receives routes from CE router
Rome, Chicago will mark these routes and distribute them to the other PE routers in the network. In the example in Figure
13-10, CE routers Rome and Berlin are member sites of the VPN named “VPN-Red,” and CE router Hong Kong is a member
site of the VPN named “VPN-Blue.” PE router Chicago will distribute the routes for VPN-Red with a route target of
2:64000:100. PE routers New York and Seattle will receive these routes from the Chicago PE router. New York will
install the routes into the VRF for VPN-Red because it has a routing-instance associated with VPN Red that has been
configured to import routes with the extended community string set to 2:64000:100. However, the Seattle PE router's
configuration is set to handle routes for VPN Blue, and therefore, will not accept routes for VPN Red.

Figure 13-10. Route Target Operation

www.ebook-converter.com
Configuring BGP MPLS VPNs
When configuring Layer 3 VPNs in a JUNOS environment, it is necessary to enable a signaling protocol and activate MPLS
on all routers involved in constructing the VPN. A special configuration is required on all of the PE routers to include the
configuration of the VPN functionality, in addition to a signaling protocol and MPLS. The following sections describe the
required steps for configuring VPNs in a JUNOS environment. Each step is explained and discussed with reference to several
different VPN configuration examples. Each example will include a network diagram with the corresponding configurations,
as well as some useful show commands that detail the configuration and operation of the VPN implementation and protocol
behavior. It is important to understand that the VPN functionality being implemented relies upon an MPLS-enabled network
and that a full mesh of LSPs must exist between the PE routers in order for the VPNs to function properly. To implement
BGP/MPLS VPNs on Juniper Networks routers, it is necessary to configure a signaling protocol on the PE routers. Either the
RSVP or LDP as signaling options are available.

Activating RSVP Signaling Options

In the JUNOS environment RSVP will be enabled on a per-interface basis.
1. From the configuration mode, type the following commands to enable RSVP.

Downloader demo watermarks

[edit protocols rsvp]
lab@Chicago#set interface fe-1/0/3

This command will enable RSVP on the fe-1/0/3 interface.

2. If RSVP is to be enabled on all interfaces on the router, then the all parameter can be used.
532
 13. Virtual Private Networks
[edit protocols rsvp]
lab@Chicago#set interface all

3. Once RSVP has been enabled, it is possible to verify a configuration with the following show commands from
operational mode:
show rsvp neighbor—. displays a summary list of the router's RSVP neighbors
lab@Chicago# run show rsvp neighbor
RSVP neighbor: 1 learned
Address Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd Status
10.0.0.1 5 1/0 49:43 3 971/971 47 –

Note—

Remember that JUNOS allows operational-mode commands to be executed while still in configuration
mode by using the run command.
show rsvp interface—. This command displays a summary list of the router interfaces configured for RSVP,
the state of the interface, and resource information.
lab@Chicago# run show rsvp interface
RSVP interface: 3 active
High-
Active Subscr- Static Available Reserved water
Interface State resv iption BW BW BW mark
fxp0.0 Up 0 100% 100Mbps 100Mbps 0bps 0bps
fe-1/0/3.0 Up 0 100% 100Mbps 100Mbps 0bps 0bps
at-1/2/1.100 Up 1 100% 155.52Mbps 155.52Mbps 0bps 0bps

show rsvp interface detail—. This command provides a more in-depth look at the RSVP functionality and
keeps track of the different types of RSVP messages. This can be a useful command to determine if the RSVP
messages are being exchanged properly.

www.ebook-converter.com
lab@Chicago# show rsvp interface detail
RSVP interface: 3 active
at-1/2/1.100 Index 6, State Ena/Up, ActiveResv 1, PreemptionCnt 0
NoAuthentication, NoAggregate, NoReliable, HelloInterval
3(second)
Address 10.0.0.2, 192.168.5.1
Subscription 100%, StaticBW 155.52Mbps, AvailableBW 155.52Mbps
ReservedBW [0] 0bps[1] 0bps[2] 0bps[3] 0bps[4] 0bps[5] 0bps[6]
0bps[7] 0bps
PacketType Total Last 5 seconds
Sent Received Sent Received
Path 35 38 0 0
PathErr 0 0 0 0
PathTear 0 1 0 0
Resv 38 35 0 0
ResvErr 0 0 0 0
ResvTear 0 0 0 0
Hello 1175 1175 1 1
Ack 0 0 0 0
Srefresh 0 0 0 0

show rsvp session—. This command displays information about the RSVP session to include the name of the

Downloader demo watermarks

LSP being used to transport the packets.
lab@Chicago# run show rsvp session
Ingress RSVP: 1 sessions
To From State Rt Style Labelin Labelout
LSPname
192.168.2.1 192.168.5.1 Up 0 1 FF - 100014 Chicago-to-newyork
Total 1 displayed, Up 1, Down 0
533
 13. Virtual Private Networks
Egress RSVP: 1 sessions
To From State Rt Style Labelin Labelout
LSPname
192.168.5.1 192.168.2.1 Up 0 1 FF 3 - newyork-to-Chicago
Total 1 displayed, Up 1, Down 0
Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

show rsvp session detail—. This command provides a detailed look at the RSVP sessions configured on
the router. It is useful for checking how RSVP information is being exchanged between RSVP neighbors.
lab@Chicago# run show rsvp session detail
Ingress RSVP: 1 sessions
192.168.2.1
From: 192.168.5.1, LSPstate: Up, ActiveRoute: 0, LSPname: Chicago-to-newyork
Resv style: 1 FF, Label in: -, Label out: 100014
Time left: -, Since: Fri Aug 24 14:25:14 2001
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 2 receiver 17 protocol 0
PATH rcvfrom: localclient
PATH sentto: 10.0.0.1 (at-1/2/1.100) 22 pkts
RESV rcvfrom: 10.0.0.1 (at-1/2/1.100) 22 pkts
Explct route: 10.0.0.1 10.0.1.1
Record route: <self> 10.0.0.1 10.0.1.1
Total 1 displayed, Up 1, Down 0
Egress RSVP: 1 sessions

192.168.5.1
From: 192.168.2.1, LSPstate: Up, ActiveRoute: 0, LSPname: newyork-to-Chicago
Resv style: 1 FF, Label in: 3, Label out: -
Time left: 123, Since: Fri Aug 24 14:25:40 2001
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500

www.ebook-converter.com
Port number: sender 3 receiver 17 protocol 0
PATH rcvfrom: 10.0.0.1 (at-1/2/1.100) 21 pkts
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.0.1.1 10.0.0.1 <self>
Total 1 displayed, Up 1, Down 0
Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Activating LDP Signaling Options

When using LDP for signaling, it is necessary to configure all of the PE and P routers for LDP. It is only necessary to
configure the interfaces that fall soley within the service provider network. It is not necessary to enable LDP on the interfaces
between the PE and CE. Use the following commands to enable LDP:
1. From the configuration mode, type the following to enable LDP:
[edit protocols ldp]
lab@Chicago# set interface interface name

Downloader demo watermarks

2. MPLS must also be configured on each LDP-configured interface.
[edit protocols mpls]
lab@Chicago# set interface interface name

In order for LDP to function properly, it is necessary to configure either IS-IS or OSPF. More details for enabling IGPs
can be found in Chapters 8 and 11.
534
 13. Virtual Private Networks
Like RSVP, MPLS needs to be configured on a per-interface basis. The all parameter is also available with MPLS. The
following example builds a configuration that will allow an RSVP signaled MPLS LSP.
3. From the configuration mode, type the following to enable MPLS.
[edit protocols mpls]
lab@Chicago# set interface interface name

4. In addition to enabling MPLS on each participating interface, it is important to also configure the interface to handle
MPLS traffic.
[edit interfaces]
lab@Chicago# set interfaces interface name unit interface unit number
family mpls

5. The LSP that is created will be used as a forwarding mechanism for the VPN traffic.
[edit protocols mpls]
lab@Chicago# set label-switched-path path name to to

Note

The value for to should be the IP address of the egress router. The path name is a name given as a
description for this LSP. When naming items in JUNOS, be as descriptive as possible to make reading the
configuration easier later on. This is how the command is displayed in the JUNOS CLI.
This configuration statement defines the IP address of the egress router that should be used to set up an LSP
dynamically. Use the following show commands to verify the MPLS configuration:
show mpls lsp—. This command displays the LSPs configured on the router by LSPname, the IP address of the
beginning and endpoint of the LSP, the state, and the type of LSP, type being ingress, egress or transit.

www.ebook-converter.com
lab@Chicago# run show mpls lsp
Ingress LSP: 1 sessions
To From State Rt ActivePath P LSPname
192.168.2.1 192.168.5.1 Up 0 * Chicago-to-newyork
Total 1 displayed, Up 1, Down 0
Egress LSP: 1 sessions
To From State Rt Style Labelin Labelout LSPname
192.168.5.1 192.168.2.1 Up 0 1 FF 3 - newyork-to-Chicago
Total 1 displayed, Up 1, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

show mpls lsp detail—. This command provides a more in-depth analysis of the LSP. It displays information
about the computed route objects, as well as the received route objects.
lab@Chicago# run show mpls lsp detail
Ingress LSP: 1 sessions
192.168.2.1
From: 192.168.5.1, State: Up, ActiveRoute: 0, LSPname: Chicago-to-newyork
ActivePath: (primary)

Downloader demo watermarks

LoadBalance: Random
*Primary State: Up
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20)
10.0.0.1 S 10.0.1.1 S
Received RRO (S [L] denotes strict [loose] hops):
10.0.0.1 S 10.0.1.1 S
Total 1 displayed, Up 1, Down 0

535
 13. Virtual Private Networks
Egress LSP: 1 sessions
192.168.5.1
From: 192.168.2.1, LSPstate: Up, ActiveRoute: 0, LSPname: newyork-to-Chicago
Resv style: 1 FF, Label in: 3, Label out: -
Time left: 148, Since: Fri Aug 24 14:25:40 2001
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 3 receiver 17 protocol 0
PATH rcvfrom: 10.0.0.1 (at-1/2/1.100) 22 pkts
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.0.1.1 10.0.0.1 <self>
Total 1 displayed, Up 1, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Note
The output displays both an ingress and egress path. The ingress path is the path that was configured on the other
PE router. Each MPLS path is constructed in a unidirectional manner.

Configuring an IGP
In order for the provider equipment to be able to exchange routing information within the network, it is necessary to
configure either static routes or a dynamic routing protocol. This section describes the commands used to enable an interior
routing protocol in support of the VPN configuration.

Note
The coverage mentioned here is only enough to support the VPN configuration. More detailed explanations can be
found in Chapter 8.

www.ebook-converter.com
IS-IS
[edit protocols isis]
lab@Chicago# set interface interface name
[edit interfaces]
lab@Chicago# set interface name unit interface unit number family iso address address

Note
A common mistake made when configuring IS-IS is forgetting to configure an ISO address on the loopback0
interface.
When configuring IS-IS each interface that will run IS-IS must be assigned to the ISO family.
The show route table inet.0 command displays the router's routing table. Note that routes are being learned from
other IS-IS speaking routers. Use the following commands to verify the IS-IS configuration:
lab@Chicago# run show route table inet.0

Downloader demo watermarks

inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 *[Direct/0] 00:49:28
> via at-1/2/1.100
536
 13. Virtual Private Networks
10.0.0.2/32 *[Local/0] 00:49:33
Local
10.0.1.0/24 *[IS-IS/18] 00:13:25, metric 20, tag 2
> to 10.0.0.1 via at-1/2/1.100
10.0.2.0/24 *[IS-IS/18] 00:13:25, metric 30, tag 2
> to 10.0.0.1 via at-1/2/1.100
192.168.0.1/32 *[IS-IS/18] 00:48:45, metric 10, tag 2
> to 10.0.0.1 via at-1/2/1.100
192.168.2.1/32 *[IS-IS/18] 00:13:25, metric 20, tag 2
> to 10.0.0.1 via at-1/2/1.100
192.168.5.1/32 *[Direct/0] 00:50:29
> via lo0.0
192.168.161.0/24 *[Direct/0] 00:50:29
> via fxp0.0
192.168.161.20/32 *[Local/0] 00:50:29
Local

OSPF
[edit protocols ospf area 0.0.0.0]
set interface interface name
The previous configuration example shows how to enable OSPF on an interface.

Note
The keyword all is available when selecting the interfaces. However, it is good practice to specify the interfaces
individually. This will help to ensure that the protocol is not enabled on an interface where it is not needed.

www.ebook-converter.com
Static Routes
The following example lists the configuration statements for static routes:
[edit routing-options]
set static route destination next-hop value

Note
The value field should be the next-hop IP address.

Configuring M-BGP on the PE Routers

This VPN configuration requires that the PE routers have IBGP sessions between them to exchange the VPN routing
information. When configuring BGP on these routers, don't forget to define the ASN. This is done in the [edit routing-
options] level of the hierarchy. It is also necessary to configure a local-address. The local-address is only
relevant when peering from loopback interfaces; however, this is the normal method of peering when configuring IBGP.
Since BGP should peer with the loopback interfaces, the BGP configuration will require the addition of configuration
Downloader demo watermarks
statements at both the [edit routing-options] and [edit protocols bgp] levels of the hierarchy.
[edit routing-options]
lab@Chicago# set autonomous-system as number
[edit protocols bgp group internal]
lab@Chicago# set local-address local-address
537
 13. Virtual Private Networks
Note
The local-address defines the source address for establishing the BGP connection. For IBGP sessions, it is
necessary to define the loopback0 IP address as the local-address.
[edit protocols bgp]
lab@Chicago# set group group name type [internal|external]
[edit protocols bgp]
lab@Chicago# set group group name neighbor address
[edit protocols bgp]
lab@Chicago# set group group name family inet-vpn unicast
The family inet-vpn statement is required to turn up MBGP advertisements of
the correct address family
Use the following commands to verify the BGP configuration:
lab@Chicago> show bgp group MY-PE-IBGP-SESSION
Group Type: Internal AS: 100 Local AS: 100
Name: MY-PE-IBGP-SESSION
Total peers: 1 Established: 1
192.168.2.1+4827
Route Queue Timer: unset Route Queue: empty
show bgp group—. This command lists the BGP information on a per-group basis. It can be very useful in providing
BGP information for a specific group or routers instead of all routers.
lab@Chicago> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp
State Pending
inet.0 12 10 0 0 0 0

www.ebook-converter.com
inet.2 0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last
Up/Dwn State|#Active/Received/Damped...
192.168.2.1 100 24 5 0 0 1:21 10/12/0 0/0/0

show bgp summary—. This command lists a brief summary of the peering sessions with this router.
lab@Chicago> show bgp neighbor
Peer: 192.168.2.1+4827 AS 100 Local: 192.168.5.1+179 AS 100
Type: Internal State: Established Flags: <>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options: <Preference HoldTime Refresh>
Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.2.1 Local ID: 192.168.5.1 Active
Holdtime: 90
Keepalive Interval: 30
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Table inet.0 Bit: 10000
Send state: in sync

Downloader demo watermarks

Active prefixes: 0
Received prefixes: 2
Suppressed due to damping: 0
Last traffic (seconds): Received 4 Sent 0 Checked 0
Input messages: Total 42 Updates 40 Refreshes 0 Octets 2501
Output messages: Total 8 Updates 0 Refreshes 0 Octets 178
Output Queue[0]: 0

538
 13. Virtual Private Networks
Configuring the VRF for the VPN
Each VPN is required to have its own routing-instance. A routing instance is a section in the configuration hierarchy
where the individual characteristics are assigned to the VPN. The VRF import and export policy to be used and the
association of an interface to the VRF will be defined in the routing-instance. This procedure covers the necessary
configuration steps to create the routing-instance to support each VPN.
[edit]
lab@Chicago# edit routing-instances instance name
The following statement is used to name the routing-instance:
[edit routing-instances instance name]
lab@Chicago# set instance-type vrf
The following statement defines the routing-instance as the VRF to be used for the VPN named VPN-Red:
[edit routing-instances instance name]
lab@Chicago# set interface interface name
The interface statement configured under the routing-instance should specify the interface that is physically
connected to the CE router. However, when manipulating JUNOS, this is the logical interface, not the physical. In other
words, it is necessary to include the logical unit number when performing this configuration.
[edit routing-instances instance name]
lab@Chicago# set route-distinguisher rd type

Note
The RD will be specified as mentioned earlier. The rd type value will be either a [16 bit:32 bit] or an

www.ebook-converter.com
[IP address:16 bit] value.

VPN Policy
The following policy-statements are used to determine which learned routes would be installed into the VRF on the PE
router. Refer to Chapter 10 for more detailed explanations of general policy. The examples in this section are used strictly for
VPNs.
[edit]
lab@Chicago# edit policy-options policy-statement policy name
[edit policy-options policy-statement policy name]
lab@Chicago# set term A from protocol bgp community value

Note
The entry for the value field should be the route target community used when the PE router distributes these
routes to other PE routers.

Downloader demo watermarks

[edit policy-options policy-statement policy name]
lab@Chicago# set term A then accept
[edit policy-options policy-statement policy name]
lab@Chicago# set term B then reject
The following statement will be used to associate the routing-instance VRF to the policy-statement. All routes
539
 13. Virtual Private Networks
that match that policy-statement will be imported into the VRF.
[edit routing-instances VPN-Red]
lab@Chicago# set vrf-import MY-IMPORT
The following statements define the export policy to be used to control which routes are distributed from the PE router to
other PE routers in the network:
[edit policy-options policy-statement policy name]
lab@Chicago# set term A from protocol ospf

Note
In this example, OSPF is the protocol used to exchange routes with the CE router. If using BGP or static routes,
that option would be chosen instead of OSPF.
[edit policy-options policy-statement policy name]
lab@Chicago# set term A then community add community name

Note
The community string that is being added through this policy tells the PE router to add this community string to the
routes that are being received from the CE router. These routes will be announced via MBGP to the other PE
router. Their import policy should be configured to accept routes with the same community.
[edit policy-options policy-statement policy_statement]
lab@Chicago# set term A then accept
[edit policy-options policy-statement policy_statement]
lab@Chicago# set term B then reject

www.ebook-converter.com
The following statement will be used to associate the policy-statement with the routing-instance VRF. All routes
that match that policy-statement will be exported from the VRF. These are the routes that will be sent to other PE
routers in the network.
[edit routing-instances instance name]
lab@Chicago# set vrf-export instance name
The following command defines the BGP extended route target community:
[edit policy-options]
lab@Chicago# set community community name members target:value

PE-CE Configuration
In order for routes to be exchanged between the PE routers and CE routers, there must be some kind of routing protocol
configured. The options available include RIP, OSPF, or BGP. Static routes are also supported, but IS-IS is not. This protocol
is configured with the routing-instance and is only used with that individual instance.

Downloader demo watermarks

OSPF
[edit routing-instances VPN-Red]
lab@Chicago# set protocols ospf area 0 interface fe-1/0/3
This command enables OSPF as the routing protocol that will be used between the CE router and the PE router. Note that the

540
 13. Virtual Private Networks
only interface configured for OSPF is the Fast Ethernet interface connected to the CE router.

BGP
[edit protocols bgp]
lab@Chicago# set group group name type [internal|external]
[edit protocols bgp group internal]
lab @Chicago# set neighbor address
The set group command under [edit protocols bgp] is used to create a BGP peer group. Configuring peers or
neighbors is done with the set neighbor command.

Static Routes
The following example lists the configuration statements for static routes:
[edit routing-options]
set static route destination next-hop value

Chapter Summary
VPNs can be identified in many different ways. This chapter focused mainly on BGP/MPLS VPNs. The discussion covered
different VPN models and some of the various topologies that can be used with these models to implement VPN services.
Reference was made to the overlay model and the peer-to-peer model. The chapter also examined the operation of full-mesh,
partial-mesh, and hub-and-spoke topologies used in VPN implementations.
A major point to understand with VPNs and their implementation is the way that routing information is exchanged, based

www.ebook-converter.com
upon the VPN implementation model. When dealing with the RFC 2547bis implementation, remember that RDs are used to
identify each route that should populate each PE router's VRF for a specific VPN. In the peer-to-peer model, this routing
information is exchanged between the customer routers and the provider's routers. In the overlay model, the provider
provides virtual circuits to the customer routers, and they exchange routing information directly between themselves. This is a
new concept of provider-managed versus customer-managed routing, and it is one of the main drivers behind this technology.

Bibliography
The following RFCs and drafts define the evolution of VPN technology and the business case for its implementation:

Case Study 1: Full-Mesh VPN Configuration

The topology displayed in Figure 13-11 shows CE routers Rome and Berlin as being member sites of VPN-Red. Chicago and
New York are PE routers and Seattle is a P router. The router configurations follow the explanation below:
1. The CE router Rome will advertise routes to PE router Chicago, which, upon receipt of the routes, will install them into
its VRF table for VPN-Red. The name of this table will be VPN-Red.

Downloader demo watermarks

2. Chicago will then create an MPLS label for the interface that connects to Rome.
3. Chicago will then check its export policy MY-EXPORT, and for all of the routes learned from OSPF, the community
VPN-Red will be added.
4. PE router Chicago will also add the RD 64512:01 to these routes, and then distribute them to PE router New York
across the IBGP session between Chicago and New York.
541
 13. Virtual Private Networks
5. When PE router New York receives the routes from PE router Chicago, PE router New York will check the routes
against its import policy; in this case, the import policy used is MY-IMPORT. This policy says that routes learned from
BGP with the community set to VPN-Red should be accepted, and all other routes should be rejected.
6. That being the case, the routes learned by PE router New York from PE router Chicago will be installed into the
BGP/Layer 3 VPN routing table. This table is identified in JUNOS as bgp.l3vpn.0.
7. From this table, the RDs will be removed and the IPv4 routes will be installed into the VRF for VPN-Red.
8. PE router New York will now advertise these routes to CE router Berlin, using OSPF.
9. CE router Berlin will install these routes into its main routing table.
10. When packets destined for CE router Rome are received by PE router New York from CE router Berlin, the label and PE
router Chicago will be used to forward the packets switched-path between PE router New York.

Figure 13-11. Case Study 1

The following examples show working BGP/MPLS VPN configurations on Juniper Networks routers. Each section is labeled

www.ebook-converter.com
with the router name and displays the configuration for the routers listed in Figure 13-11.

PE Router Chicago
The following output is the configuration used by PE router Chicago in Case Study 1. This router will exchange routing
information with PE router New York.
interfaces {
fe-1/0/3 {
unit 0 {
family inet {
address 10.0.8.1/24;
}
family mpls;
at-1/2/1 {
atm-options {
vpi 0 maximum-vcs 200;
}

Downloader demo watermarks

unit 100 {
vci 0.100;
family inet {
address 10.0.0.2/24;
}
family iso;
family mpls;
542
 13. Virtual Private Networks
lo0 {
unit 0 {
family inet {
address 192.168.5.1/32;
}
family iso {
address 49.0000.0000.0001.00;
routing-options {
router-id 192.168.5.1;
autonomous-system 100;
}
protocols {
rsvp {
interface all;
}
mpls {
label-switched-path Chicago-to-newyork {
to 192.168.2.1;
}
interface all;
}
bgp {
local-address 192.168.5.1;
family inet-vpn {
unicast;
}
group internal {
type internal;
neighbor 192.168.0.1;
neighbor 192.168.2.1;

www.ebook-converter.com
}
}
isis {
level 1 disable;
interface all;
}
}
policy-options {
policy-statement MY-EXPORT {
term a {
from protocol ospf;
then {
community add VPN-Red;
accept;
}
}
term b {
then reject;
}

Downloader demo watermarks

}
policy-statement MY-IMPORT {
term a {
from {
protocol bgp;
community VPN-Red;
}
543
 13. Virtual Private Networks
then accept;
}
term b {
then reject;
}
}
community VPN-Red members target:64512:01;
}
routing-instances {
vpntest {
instance-type vrf;
interface fe-1/0/3.0;
route-distinguisher 64512:01;
vrf-import MY-IMPORT;
vrf-export MY-EXPORT;
protocols {
ospf {
area 0.0.0.0 {
interface fe-1/0/3.0;

PE Router New York

PE router New York exchanges routing information with PE router Chicago and connects to CE router Berlin. The
configuration for PE router New York is displayed below:
interfaces {
so-0/1/0 {
unit 0 {
family inet {

www.ebook-converter.com
address 10.0.24.1/24;
}
family mpls;
}
}
so-0/3/0 {
unit 0 {
family inet {
address 10.0.1.1/24;
}
family iso;
family mpls;
lo0 {
unit 0 {
family inet {
address 192.168.2.1/32;
}
family iso {
address 49.0000.0000.0003.00;

Downloader demo watermarks

}
}
}
}
routing-options {
router-id 192.168.2.1;
autonomous-system 100;
544
 13. Virtual Private Networks
}
protocols {
rsvp {
interface all;
}
mpls {
label-switched-path newyork-to-Chicago {
to 192.168.5.1;
}
interface all;
}
bgp {
local-address 192.168.2.1;
group internal {
type internal;
neighbor 192.168.0.1;
neighbor 192.168.5.1;
}
}
isis {
level 1 disable;
interface all;
}
}
policy-options {
policy-statement MY-IMPORT {
term a {
from {
protocol bgp;
community VPN-Red;

www.ebook-converter.com
}
then accept;
}
term b {
then reject;
}
}
policy-statement MY-EXPORT {
term a {
from protocol ospf;
then {
community add VPN-Red;
accept;
}
}
term b {
then reject;
}
}

Downloader demo watermarks

}
community VPN-Red members target:64512:01;
routing-instances {
vpntest {
instance-type vrf;
interface so-0/1/0.0;
route-distinguisher 64512:01;
545
 13. Virtual Private Networks
vrf-import MY-IMPORT;
vrf-export MY-EXPORT;
protocols {
ospf {
area 0.0.0.0 {
interface so-0/1/0.0;

P Router Seattle
Seattle is being used as a provider router and will only function as a part of the MPLS paths between PE routers. The
configuration for Seattle is displayed below:
interfaces {
at-1/2/0 {
atm-options {
vpi 0 maximum-vcs 200;
}
unit 100 {
vci 0.100;
family inet {
address 10.0.0.1/24;
}
family iso;
family mpls;
}
}
so-2/0/0 {
unit 0 {
family inet {

www.ebook-converter.com
address 10.0.1.2/24;
}
family iso;
family mpls;
lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
family iso {
address 49.0000.0000.0002.00;
routing-options {
router-id 192.168.0.1;
autonomous-system 100;
}
protocols {
rsvp {
interface all;
}

Downloader demo watermarks

mpls {
interface all;
}
isis {
level 1 disable;
interface all;

546
 13. Virtual Private Networks
CE Router Rome
CE router Rome is site one for the VPN-Red and connects to PE router Chicago. Rome's configuration is displayed below:
interfaces {
fe-1/0/3 {
unit 0 {
family inet {
address 10.0.8.2/24;
lo0 {
unit 0 {
family inet {
address 192.168.12.1/32;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
interface all;

CE Router Berlin
CE router Berlin is site two for the VPN-Red and connects to PE router New York. The Berlin router's configuration is
displayed below:
interfaces {
so-1/1/0 {

www.ebook-converter.com
unit 0 {
family inet {
address 10.0.24.2/24;
lo0 {
unit 0 {
family inet {
address 192.168.24.1/32;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
interface all;

Case Study 2: Hub-and-Spoke VPN Configuration

In the example of the Layer 3 VPN hub-and-spoke configuration displayed in Figure 13-12, there are three PE routers and
Downloader demo watermarks
three CE routers. With both sets of routers, there will be one hub and two spokes. PE router Chicago will be configured as the
PE hub, while Rome and New York will be configured as PE spokes. Seattle will be the CE hub, while Singapore and Berlin
will be the CE spokes. The configurations for the routers are listed following the explanation below:
1. The routing-instance associated with interface at-1/2/1.100 on the PE hub router Chicago will be used to
send routes to the CE hub router Seattle, while the other routing-instance associated with interface at-
547
 13. Virtual Private Networks
1/2/1.102 will be used to receive routes.
2. With this hub-and-spoke configuration, CE router Singapore will announce its routes to PE spoke router Rome.
3. Rome will then install the learned routes into the VRF for the VPN.
4. Rome's export policy To-Spoke will be examined, and for all matching routes and the community, SPOKE will be
added. These routes are then announced to PE hub router Chicago.
5. Chicago's import policy is configured to accept any routes with the community set to SPOKE and install them into the
bgp.l3vpn.0 routing table. In the bgp.l3vpn.0 routing table, the routes are listed with the RD.
6. Before these routes are removed for forwarding to the CE hub, they are checked against the VRF import policy, and the
routes will be installed into the VRF for the VPN.
7. From the VPN's VRF, the routes will be sent to the CE hub. For the configuration shown, this announcement will take
place over the at-1/2/1.100 interface.
8. Once CE hub router Seattle receives the routes, they will be announced from Seattle back to PE hub router Chicago. This
information will be sent on the at-1/2/1.102 interface. Now, the policy-statement To-Hub will be applied.
9. The matching routes will be installed into the VRF “CE-Routes-To-Spokes.” From this VRF, the export policy will be
applied and the routes will be forwarded to all of the other PE spokes in the network with the community HUB added.

www.ebook-converter.com
Figure 13-12. Case Study 2

Note
When using BGP as the protocol between the CE hub and PE hub, BGP should be configured to accept routes with
its own ASN listed more than once in the AS path list.
[edit routing-options]
set autonomous-system as-number loops number of loops from 0-10
The following examples show working Layer 3 VPN configurations on Juniper Networks routers. Each section is labeled with
the router name and displays the configuration for the routers listed in Figure 13-12.

Downloader demo watermarks

PE Hub Router Chicago
The following output is the configuration used by PE router Chicago in Case Study 2. This router will be used as the PE hub
and exchange routing information with the other two PE routers. Chicago's configuration is displayed below:
interfaces {
548
 13. Virtual Private Networks
fe-1/0/3 {
unit 0 {
family inet {
address 10.0.8.1/24;
}
family mpls;
}
}
at-1/2/1 {
atm-options {
vpi 0 maximum-vcs 200;
}
unit 100 {
vci 0.100;
family inet {
address 10.0.0.2/24;
}
family mpls;
}
unit 102 {
vci 0.102;
family inet {
address 172.16.1.1/24;
}
family mpls;
}
}
}
lo0 {
unit 0 {

www.ebook-converter.com
family inet {
address 192.168.5.1/32;
}
}
}
}
routing-options {
router-id 192.168.5.1;
autonomous-system 100;
}
protocols {
mpls {
interface at-1/2/1.100;
interface at-1/2/1.102;
interface fe-1/0/3.0;
interface at-1/2/0.100;
}
bgp {
local-address 192.168.5.1;

Downloader demo watermarks

family inet-vpn {
}
unicast;
group VPN-PE-Routers {
type internal;
neighbor 192.168.12.1;
neighbor 192.168.2.1;
549
 13. Virtual Private Networks
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface at-1/2/0.100;
interface fe-1/0/3.0;
interface lo0.0;
}
}
ldp {
interface fe-1/0/3.0;
interface at-1/2/0.100;
}
}
policy-options {
policy-statement REJECT {
then reject;
}
policy-statement HUB {
term A {
from protocol ospf;
then {
community add HUB;
accept;
}
}
term B {
then reject;
}

www.ebook-converter.com
}
policy-statement SPOKE {
term A {
from {
protocol bgp;
community SPOKE;
}
then accept;
}
term B {
then reject;
}
}
policy-statement SEND-VPN {
term A {
from protocol bgp;
then accept;
}
term B {

Downloader demo watermarks

}
}
then reject;

community HUB members target:64512:01;

community SPOKE members target:64512:02;
}
routing-instances {
550
 13. Virtual Private Networks
CE-Hub-Routes-to-Spokes {
instance-type vrf;
interface at-1/2/1.102;
route-distinguisher 192.168.5.1:64512;
vrf-import REJECT;
vrf-export HUB;
protocols {
ospf {
export SEND-VPN;
area 0.0.0.0 {
interface at-1/2/1.102;
}
}
}
}
Spoke-Routes-to-CE-Hub {
instance-type vrf;
interface at-1/2/1.100;
route-distinguisher 192.168.5.1:64512;
vrf-import SPOKE;
vrf-export REJECT;
protocols {
ospf {
export SEND-VPN;
area 0.0.0.0 {
interface at-1/2/1.100;

PE Spoke Router Rome

www.ebook-converter.com
The Rome router is being used in Case Study 2 as a PE spoke. The configuration is displayed below:
interfaces {
fe-1/0/3 {
unit 0 {
family inet {
address 10.0.8.2/24;
}
family mpls;
}
}
ge-1/2/0 {
unit 0 {
family inet {
address 10.0.13.2/24;
}
family mpls;
}
}

Downloader demo watermarks

lo0 {
unit 0 {
family inet {
address 192.168.12.1/32;
}
}
}
551
 13. Virtual Private Networks
}
routing-options {
router-id 192.168.12.1;
autonomous-system 100;
}
protocols {
mpls {
interface fe-1/0/3.0;
interface ge-1/2/0.0;
}
bgp {
local-address 192.168.12.1;
family inet-vpn {
unicast;
}
group VPN-PE-Routers {
type internal;
neighbor 192.168.5.1;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fe-1/0/3.0;
interface lo0.0;
}
}
ldp {
interface fe-1/0/3.0;
}

www.ebook-converter.com
}
policy-options {
policy-statement To-Hub {
term A {
from {
protocol bgp;
community HUB;
}
then accept;
}
term B {
then reject;
}
}
policy-statement To-Spoke {
term A {
from protocol ospf;
then {
community add SPOKE;

Downloader demo watermarks

}
}
term B {
accept;

then reject;
}
}
552
 13. Virtual Private Networks
policy-statement SEND-VPN {
term A {
from protocol bgp;
then accept;
}
term B {
then reject;
}
}
community HUB members target:64512:01;
community SPOKE members target:64512:02;
}
routing-instances {
PE-Spoke-Rome-to-PE-Hub {
instance-type vrf;
interface ge-1/2/0.0;
route-distinguisher 192.168.12.1:64512;
vrf-import To-Hub;
vrf-export To-Spoke;
protocols {
ospf {
export SEND-VPN;
area 0.0.0.0 {
interface ge-1/2/0.0;

PE Spoke Router New York

PE spoke router New York is one of the two PE spokes that exchanges routing information with PE hub Chicago. New
York's configuration is displayed below:

www.ebook-converter.com
interfaces {
so-0/1/0 {
unit 0 {
family inet {
address 10.0.24.1/24;
}
family mpls;
}
}
at-6/2/0 {
atm-options {
vpi 0 maximum-vcs 200;
}
unit 100 {
vci 0.100;
family inet {
address 10.0.2.1/24;
}

Downloader demo watermarks

}
}
lo0 {
unit 0 {
family inet {
address 192.168.2.1/32;
}
553
 13. Virtual Private Networks
}
}
}
routing-options {
router-id 192.168.2.1;
autonomous-system 100;
}
protocols {
mpls {
interface at-6/2/0.100;
interface so-0/1/0.0;
}
bgp {
local-address 192.168.2.1;
group VPN-PE-Routers {
type internal;
neighbor 192.168.5.1 {
family inet-vpn {
unicast;
}
}
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface at-6/2/0.100;
interface lo0.0;
}
}

www.ebook-converter.com
ldp {
interface at-6/2/0.100;
}
}
policy-options {
policy-statement To-Hub {
term A {
from {
protocol bgp;
community HUB;
}
then accept;
}
term B {
then reject;
}
}
policy-statement To-Spoke {
term A {

Downloader demo watermarks

from protocol ospf;
then {
community add SPOKE;
accept;
}
}
term B {
554
 13. Virtual Private Networks
then reject;
}
}
policy-statement SEND-VPN {
term A {
from protocol bgp;
then accept;
}
term B {
then reject;
}
}
community HUB members target:64512:01;
community SPOKE members target:64512:02;
}
routing-instances {
PE-Spoke-NewYork-to-PE-Hub {
instance-type vrf;
interface so-0/1/0.0;
route-distinguisher 192.168.2.1:64512;
vrf-import To-Hub;
vrf-export To-Spoke;
protocols {
ospf {
export SEND-VPN;
area 0.0.0.0 {
interface so-0/1/0.0;

CE Hub Router Seattle

www.ebook-converter.com
CE hub router Seattle uses the router configuration displayed below. This router will serve as a hub router for the other two
CE routers, Berlin and Singapore.
interfaces {
at-1/2/0 {
atm-options {
vpi 0 maximum-vcs 200;
}
unit 100 {
vci 0.100;
family inet {
address 10.0.0.1/24;
}
}
unit 102 {
vci 0.102;
family inet {
address 172.16.1.2/24;

Downloader demo watermarks

lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
}
555
 13. Virtual Private Networks
}
}
routing-options {
router-id 192.168.0.1;
}
protocols {
ospf {
area 0.0.0.0 {
interface all;

CE Spoke Router Singapore

The configuration of the CE spoke router Singapore is displayed below:
interfaces {
ge-1/1/1 {
unit 0 {
family inet {
address 10.0.13.1/24;
lo0 {
unit 0 {
family inet {
address 192.168.8.1/32;
routing-options {
router-id 192.168.8.1;
}
protocols {
ospf {
area 0.0.0.0 {

www.ebook-converter.com
interface all;

CE Spoke Router Berlin

The configuration for the CE spoke router Berlin is displayed below:
interfaces {
so-1/1/0 {
unit 0 {
family inet {
lo0 {
unit 0 {
family inet {
address 192.168.24.1/32;
routing-options {
router-id 192.168.24.1;
}
protocols {
ospf {

Downloader demo watermarks

area 0.0.0.0 {
interface all;

556
[ch13bib01] “BGP/MPLS VPNs,” Internet-Draft, draft-rosen-rfc2547bis. Juniper
Networks uses this document to implement BGP/MPLS VPNs.
[ch13rfc2547] IETF RFC—RFC 2547, BGP/MPLS VPNs. E. Rosen, Y. Rekhter. 1999.
This RFC has been made obsolete by RFC2547bis.
[ch13rfc2685] IETF RFC—RFC 2685, Virtual Private Networks Identifier. B. Fox, B.
Gleeson, 1999.
[ch13rfc2764] IETF RFC—RFC 2764, A Framework for IP Based Virtual Private
Networks. B. Glesson, et al. 2000.
[ch13rfc2917] IETF RFC—RFC 2917, A Core MPLS IP VPN Architecture. K.
Muthukrishnan, A. Malis, 2000.

www.ebook-converter.com

Downloader demo watermarks

557
 14. Multicast Protocols
Chapter 14. Multicast Protocols
Demand for multimedia, combining audio, video, and data streams over a network, is rapidly increasing. Users are
clamoring for it; Web sites are deploying it; businesses and industry see it as a profit center. Some of the more popular
uses of multimedia are real-time interactive applications, such as desktop video and audio conferencing, collaborative
engineering, shared whiteboards, transmission of training lectures to remote audiences, and animated simulations. Even
when data compression is used, multimedia applications require lots of bandwidth.
Enter multicasting, which at its simplest level allows a single transmission to be sent from a server, for example, to
multiple receivers. This means that every receiver need not have a unicast transmission with the server. This results in
reduced load on the server because it only needs to send the data once and reduced network utilization, leaving
expensive WAN bandwidth for other traffic.
Consider the bandwidth utilization chart shown in Figure 14-1. We can see that when unicast transmission is employed
to send data, utilization is exponential; however, with multicast it is much more even. This allows for a more
manageable and economic use of the available bandwidth. Thus, it is this economic benefit that will continue to drive
the adoption of multicast throughout the Internet.

www.ebook-converter.com
Figure 14-1. Comparison of Unicast and Multicast Bandwidth Utilization
This chapter provides an overview of the more commonly deployed multicast technologies possible on Juniper
Networks routers. It will explain them, discuss how they operate, and look at methods for implementing them. While
this is a technical discussion and not a sales presentation, the reasons to consider multicast in your network are growing
ever stronger and should be considered carefully.
It should also be noted that there are many RFCs dedicated to describing each of the different multicast technologies
discussed in this chapter as well as in entire books devoted just to multicast. This chapter does not try to be a complete
solution or provide final word on anything multicast; it is an introduction. The goal of this chapter is to introduce you to
the world of multicast by opening the door, sharing some perspectives, and demonstrating how multicast is configured
on a Juniper Networks router. Some readers will decide they need more information; others will find this chapter's
coverage perfect for their needs. For those needing more information, interspersed throughout this chapter are
references to additional sources, and readers are encouraged to take advantage of the bibliography as well.

Multicast Backbone
Downloader demo watermarks
Intel, Microsoft, Cisco Systems, and children's favorite Toys-R-Us are all companies that have deployed cost-saving and
business-enabling multicast solutions. These are just companies with large enterprise networks and even ISPs are
activating multicast on their production networks.
Multicast is a unique aspect of routing in networks that has been steadily growing in use across the Internet. However,
558
 14. Multicast Protocols
many engineers have yet to acknowledge its growing role. Certainly your everyday Internet consumer is completely
oblivious to its existence as an overlay on the Internet known as the multicast backbone (mbone).
In a typical IPv4 unicast routing scenario, delivery, ordering, and delay are not guaranteed. Although multicast employs
techniques to use bandwidth more efficiently, there is still no guarantee of delay and ordering. Thus, in addition to
multicast techniques, proper application deployment and internal application correction methods need to be
implemented to take advantage of multicast fully. Do not misunderstand—multicast does have some issues associated
with it, the largest being that network engineers do not seem to believe in it as a solution, it has no built-in network
congestion avoidance mechanism, there are packet duplication issues, and because multicast commonly uses UDP as
the transport mechanism, packet delivery can be unreliable at times.
As multimedia in all its forms more strongly dominates the realm of networking in general and the Internet in particular,
the use of multicast becomes ever more important. Juniper Networks has a strong multicast implementation that enables
the issues associated with multicast to be better addressed through the support of many of the newer multicast protocols
designed to cope with these issues.
Mbone was at its inception like many fundamental stalwarts of the Internet today—an experiment. The IETF wanted to
broadcast its meetings to those unable to be present who were located across the globe. The idea at the time was to
create a volunteer-based experiment to explore how to successfully transmit audio and video from one source to many
destinations. The technology to provide this type of host and network capabilities evolved into several new technologies
known collectively as multicasting.
Mbone is an interconnected set of subnetworks of routers that support multicast. These routers are grouped together
into multicast islands that are then overlaid onto the Internet as shown in Figure 14-2. An island is connected to another
island over the Internet via a tunnel (a virtual point-to-point link). These tunnels allow multicast traffic to pass
undisturbed through the portions of the Internet that are not multicast-enabled.

www.ebook-converter.com

Figure 14-2. Multicast Islands in Mbone Architecture

The deployment and continued growth of mbone is important to multicast and its use, as well as its evolution. However,
the need, or more specifically, the commercial and business factors involved in driving growth in multicast is even more
important.
In conclusion mbone is winding down, and the experiment is over. The experiment was extremely successful and
Downloader demo watermarks
demonstrated that multicast and tunneling could be accomplished. Today and in the future, we will see many large ISPs,
including Sprint, Level3, and WorldCom, continue to incorporate multicast into their production networks. These
networks, in general, are using PIM as their multicast protocol of choice, instead of DVMRP, through either MBGP or
MSDP. Later, this chapter will introduce and discuss these protocols.

559
 14. Multicast Protocols
The standards relating to multicast are as follows:
RFC 1112, “Host Extensions for IP Multicasting” (defines IGMP Version 1)
RFC 2236, “Internet Group Management Protocol, Version 2”
RFC 2327, “SDP: Session Description Protocol”
RFC 2362, “Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification”
RFC 2365, “Administratively Scoped IP Multicast”
“Protocol Independent Multicast Version 2 Dense Mode Specification,” Internet draft, draft-ietf-pim-v2-dm-03.txt
“Distance Vector Multicast Routing Protocol,” Internet draft, draft-ietf-idmr-dvmrp-v3-07
“SAP: Session Announcement Protocol,” Internet draft, draft-ietf-mmusic-sap-00
“MSDP,” Internet draft, draft-ietf-msdp-spec-01.txt
“Anycast RP Mechanism Using PIM and MSDP,” Internet draft, draft-ietf-mboned-anycast-rp-05.txt
To access Internet RFCs and drafts, go to the IETF Web site at www.ietf.org. These standards are current in their status
at the time of this writing. It is always good to look beyond the standards to how they have been interpreted. The
following additional resources can assist:
ftp://parcftp.xerox.com/pub/net-research/mbone/maps/mbone-map.pdf
www.savetz.com/mbone/

www.ebook-converter.com
www-itg.lbl.gov/mbone/

Benefits of Multicasting
Before this chapter delves into the details of how multicasting works, the following list describes some of the benefits of
multicasting. We will look at these benefits first from a network engineer's perspective and then from a cost-profit
business perspective.
Provides economic benefits through savings in costs and server resources
Allows increased users in a multicast group without an exponential networkwide increase in bandwidth use
Reduces the load on the sending server, which no longer has to support many sequential or concurrent unicast
sessions (this benefit can be just as significant as the bandwidth savings)
Decreases LAN traffic, thus reducing potential bottlenecks and scaling issues

Downloader demo watermarks

Reduces WAN traffic, which has a positive impact on overall network management
Events in the arenas of both Internet politics and personal Internet use are also contributing to the continued growth of
multicast. Consider the following more specific snapshot of factors and business or personal uses for multicast:
Deployment of new applications that can save your company money or possibly become a source of income

560
 14. Multicast Protocols
Multimedia conferencing, including audio and video, electronic whiteboards, and Microsoft's Net Meeting
Data distribution and sharing information, such as files and data, Gnuetella and Bear Share (file sharing
applications), and Napster or clone
Real-time data, like stock tickers and news reports (certainly it will not be long before sporting events and concerts
are multicast regularly over the Internet)
The hosting and selling subscriptions to participate in Internet games like Doom, Quake, Dungeon Siege, and
Everquest and military warfare simulations
As the Internet has evolved and information sharing has increased, many different models to share information via the
Internet have been developed. Some have gotten the rest of the world really stirred up, but the point here is that
multicasting applications are on the rise and this will continue! Are you ready?

JUNOS Multicast Implementations

Multicast routing is the key to multicast and is the framework upon which multicast packets are routed to recipients.
Some of the concepts that we will introduce here will be explained in other sections, but it is good to get comfortable
with the proper multicast terminology at the outset. JUNOS implements the following protocols to support IP multicast
routing:
Internet Group Management Protocol (IGMP), versions 1, 2, and 3—This protocol is used by routers to solicit from
their directly connected hosts if they wish to participate in a multicast group.
DVMRP—This is the first true multicast routing protocol that operates in dense mode and determines path
information via a distance vector algorithm. It has been many years since DVMRP was introduced, and it is now
considered a legacy multicast protocol, like RIPv1.

www.ebook-converter.com
PIM—PIM supports two modes of operation (dense and sparse) and is used for efficiently routing to multicast
groups that might span wide-area and interdomain internetworks. It is referred to as protocol independent because
it is not dependent on any particular unicast routing protocol. JUNOS also supports dense-sparse mode, which is a
combination of features from both modes.
MSDP—This multicast routing protocol is used by PIM when in sparse mode to span multicast domains to discover
other multicast sources in other domains.
MBGP—BGP was extended to carry multicast family information, allowing the sharing of multicast information
between ASs. MSDP will not function properly without MBGP as we will see later in this chapter.
Session Announcement Protocol (SAP) and Session Description Protocol (SDP)—These protocols handle
conference session announcements.
It is commonly understandood that when discussing multicast and BGP, the “m” in MBGP stands for “multicast,” even
though the RFC defines it as “multiprotocol.”

Downloader demo watermarks

Multicast Characteristics
In Chapter 2 we discussed that IPv4 has three fundamental address types: unicast, broadcast, and multicast. The only
difference between a multicast IP packet and a unicast IP packet is the presence of a group address in the IP header
destination address field. Multicast addresses use the Class D address format. This chapter is concerned with the
technologies that enable multicast to operate effectively. Let's review the purpose of a multicast addresses and
561
 14. Multicast Protocols
operation.
The Multicast Transmission Model is used to move a single packet across the network from one sender to multiple
receivers. This differs from broadcasts in that the packet is intended for multiple nodes, but not necessarily every node
on the network. These concepts are shown in Figure 14-3. In the figure, traffic flow is moving from the source on the
left to a select group of destination hosts on the right.

Figure 14-3. Comparison of Multicasting and Multiple Unicasts

Specifically the server is transmitting to Hosts A, B, and C. Through the use of the multicast model, the server is able to
transmit once, and later on the network routers will transmit separately to each host in the multicast group (A, B, and C)
as shown in Figure 14-4. This allows for bandwidth and load savings by many devices in the network.

www.ebook-converter.com
Figure 14-4. Multicast Transmission Model

Multicast Addresses
Multicast addresses utilize addresses out of the IANA reserved Class D range. This range has all addresses with their
high-order bits as 1110, and all addresses are expressed in the dotted decimal notation as
224.0.0.0–239.255.255.255 or 224.0.0.0/4. Out of the range of possible addresses available, Table 14-1
shows those that have been allocated or reserved. To review the format of IP addresses, refer to Chapter 2.
Table 14-1. Multicast Address Allocations

Downloader demo watermarks

Address
224.0.0.0
Function/Reservation
Reserved for future use
224.0.0.1 All hosts on a subnet used to address all IP multicast hosts on the directly
connected network
224.0.0.2 All routers on a subnet
562
224.0.0.2 All routers on a subnet 14. Multicast Protocols
Address
224.0.0.4 Function/Reservation
All DVMRP (Distance Vector Multicast Routing Protocol) routers
224.0.0.5 All OSPF routers
224.0.0.6 All OSPF DRs
224.0.0.9 All RIPv2 routers
224.0.0.11 Mobile IP Agent Devices
224.0.0.13 All PIM routers
224.0.0.18 VRRP
224.0.0.19–224.0.0.255 Unassigned
224.0.0.0 and 224.0.0.255Reserved for routing protocols and other low-level topology discovery or
maintenance protocols
224.0.1.1 NTP
224.0.1.2 SGI Dogfight
224.0.1.7 Audio News
224.0.1.11 IETF Audio
224.0.1.12 IETF Video
224.0.13.000–224.0.13.255Net News
239.0.0.0–239.255.255.255Administratively scoped addresses
IANA owns a block of Ethernet addresses that in hexadecimal is represented as 00:00:5e. This is the high-order 24
bits of the Ethernet address, meaning that this block includes addresses in the range 00:00:5e:00:00:00 to
00:00:5e:ff:ff:ff. The IANA allocates half of this block for multicast addresses. Given that the first byte of any
Ethernet address must be 01 to specify a multicast address, the Ethernet addresses corresponding to IP multicasting are
in the range 01:00:5e:00:00:00 to 01:00:5e:7f:ff:ff.
This allocation allows for 23 bits in the Ethernet address to correspond to the IP multicast group ID. The mapping places
the low-order 23 bits of the multicast group ID into these 23 bits of the Ethernet address, as shown in Figure 14-5.
Because the upper five bits of the multicast address are ignored in this mapping, the resulting address is not unique. It is

www.ebook-converter.com
thus possible to map 32 different multicast group IDs map to each Ethernet address as shown in Figure 14-5.

Figure 14-5. Ethernet Address Allocations for Multicast

Because the mapping is not unique and because the interface card might receive multicast frames in which the host is
really not interested, the device driver or IP modules must perform filtering to determine which are destined for it and
which are not.

Downloader demo watermarks

Multicast Functional Overview
In multicast there are some fundamental and general differences between the different solutions that we will be
discussing. It is important to understand these issues prior to learning about the specific implementations of the different
types of multicasting available. The differences form the foundation of multicast operation and are key learning points.
This section will look at some of the functional aspects of multicast routing and how it differs from the routing protocols
563
 14. Multicast Protocols
that we have discussed in previous chapters.
Let's begin by doing an operational comparison between unicast routing and multicasting. Multicast routing differs from
unicast routing in several fundamental areas as shown in Table 14-2.
Table 14-2. Comparison Between Unicast and Multicast Routing

Unicast Routing Multicast Routing

Hosts are individuals Hosts are grouped as belonging to a
multicast event
Datagram reception is standardized Receiving of datagrams has additional steps
Builds route tables Builds distribution trees
TTL works normally TTL values can have additional uses
Uses a variety of forward route selection methodologies (e.g., link, distance Uses RPF
vector, path)
Many different varieties; OSPF and BGP preferred Two categories: dense and sparse
Routing decisions are based on the destination Routing decisions are based on the source

Hosts and Groups

Multicast events allow users to join and participate. When a host decides to join, it becomes part of that multicast group.
The use of groups allows the server to transmit once, then have that transmission replicated by routers and delivered
wherever there may be hosts in that group. There are no physical restrictions on the location of hosts or the number that
can join a multicast group. Plus, a host can be a member of multiple groups at the same time.
Routers use a group membership protocol that enables them to learn about the presence of hosts wishing to join the
multicast group on their directly connected networks (e.g., Ethernet segment). The concepts of groups and hosts are
shown in Figure 14-6, which shows a network running a multicast routing protocol. This protocol will provide the

www.ebook-converter.com
routing of the multicast transmission, and the next step is to determine which of the potential hosts would like to receive
this multicast transmission. Determining host membership is the responsibility of the group membership protocol as it
probes the Ethernet listening for requests to join the multicast transmission group.

Downloader demo watermarks

Figure 14-6. Multicast Routing and Group Membership Protocols
When a host wishes to join a group, it transmits a join request for the group(s) from which it wishes to receive multicast
packets. As a part of this process of joining a multicast group, the host's NIC begins to accept additional packets, as we
will discuss in the next section.

564
 14. Multicast Protocols
Receiving IP Datagrams
Multicast sends a packet by specifying a group of multicast participants as the destination. This makes sense and is
straightforward because we have already discussed how one of the benefits of multicast is its ability to group users
together; you know, however, that there is a but coming! But, when a host receives a multicast packet, the process to
understand it is a bit more complicated.
Before a host can receive a multicast packet, it must first request to be a part of a multicast group (e.g., “I want to view
today's live press conference with the President”). This membership request is sent to the host local router and
potentially to others as well. This gets interesting when we recall that for the router to forward the multicast event over
the LAN, the MAC address must be known. Multicast, however, is a one-to-many technology, so a new virtual MAC
address is created and the hosts on the LAN that have joined the group now listen to their native MAC address and this
newly created multicast group MAC address for their LAN. Thus, when the LAN router receives the multicast stream, it
forwards the datagrams with the destination address of the multicast group. The receiving host(s) participating in the
multicast event will, upon receiving a multicast frame destined for them, read the entire message. They de-encapsulate
the frame passing the multicast message up to the TCP/IP protocol stack until the user's application presents the data to
the user and he or she can see or hear the company's president speaking or, perhaps, the Super Bowl!
Multicast has been implemented very nicely here in the sense that the LAN router does not track the destination host's
MAC address. Recall that in unicast IP, MAC addresses and IP addresses are bound together; this is not so in multicast.
Multicast-enabled routers only need to know the list of multicast groups that are on its LAN. Thus, a multicast router
attached to an Ethernet segment need associate only a single Ethernet multicast address with each host group having a
local participant. This means the router doesn't care who the receivers are, only that a group has one local member on
the LAN.

Distribution Trees
Referring back for a moment to Figure 14-4, we can see how multiple branches in a tree need to be created to track the

www.ebook-converter.com
flow of multicast packets. This is similar to how IP routing determines path data as well. In multicast this function is
handled by the multicast routing protocol in use.
In cases where more than one router is present in a subnetwork, the one physically closer to the source of a multicast
message is elected to be in charge of forwarding multicast messages. All other routers will simply discard the multicast
messages sent from that source. If there is more than one router on the subnetwork with the same distance from the
source, the router with the lowest IP address is elected to forward the multicast. IGMPv2 uses the multicast address of
224.0.0.1 for the entire multicast system to compare the IP addresses on every network; the router with the lowest is
elected to be in charge.

TTL
The scope (transmission range) of an IP multicast packet can be limited by using the TTL field in the IP header. Each IP
multicast packet uses the TTL field of the IP header as a scope-limiting parameter. The TTL field controls the number of
hops that an IP multicast packet is allowed to propagate. Each time a router forwards a packet, its TTL is decremented.
A multicast packet whose TTL has expired (is 0) is dropped without an error notification to the sender. Table 14-3 lists
the conventional TTL values used to limit the scope of multicast packets. This mechanism prevents messages from

Downloader demo watermarks

needless transmission to regions of the worldwide Internet that lie beyond the subnets containing the multicast group
members.
Table 14-3. TTL Values for Limiting the Scope of Multicast Packets

TTLMulticast Scoping
0 Restricted to same host
565
0 Restricted to same host 14. Multicast Protocols
TTLMulticast
1 Restricted Scoping
to same subnet
15 Restricted to same site
63 Restricted to same region
127 Worldwide
191 Worldwide limited bandwidth
255 Unlimited
TTL thresholds in multicast routers prevent datagrams with less than a certain TTL from traversing certain subnets. This
can provide a convenient mechanism for confining multicast traffic to within campus or enterprise networks.
Juniper Networks documentation does clearly point out that though this is a viable method of scoping, there have been
issues with this type of scoping deployment. Specifically, sometimes shortening the route can result in the multicast
information from not reaching a router anymore. Needless to say, each implementation will be different, so keep an eye
on this just in case as some features from TTL used in scoping can in fact increase the reliability and stability of the
multicast platform.

IGMP
Multicast packets need to be forwarded by the routers in between the source and destination just like in unicast routing.
In multicast you must ensure that your multicast packets are only forwarded to LANs where a host is located that
belongs to the multicast group. In other words do not send multicast transmissions to a LAN if no one has asked. IGMP
must be enabled on routers that wish to receive multicast information. IGMP is also the transport protocol for multicast
protocols (DVMRP and PIM).
Multicast-enabled routers need to learn which directly connected host wish to participate in a given multicast group use
IGMP. This is accomplished by having the router send an IGMP query message onto the subnet to which a host will
reply with the group membership information; we will look at this process in more detail shortly. Based on this

www.ebook-converter.com
information the routing of multicast data will be altered accordingly.

IGMP Operational Overview

IGMP messages are encapsulated in IP datagrams. IGMP has only two kinds of packets, host membership query and
host membership report, with the same simple fixed format containing some control information in the first 32 bits and a
Class D address in the second 32 bits as shown in Figure 14-7.

Figure 14-7. IGMP Message Format

In order for a router to determine if any hosts on a local subnet belong to a multicast group, one multicast-enabled
router per LAN (subnet) periodically sends a hardware (data link layer) multicast IGMP host membership query to all

Downloader demo watermarks

IP hosts on its LAN, asking them to report back on their multicast groups memberships. This membership query
message is sent to the all-hosts group (destination address 224.0.0.1) and a TTL of 1 is used so that these messages
are not propagated outside of the LAN. Each host sends back one IGMP host membership report message per multicast
group, sent to the group address (224.5.5.5), so all group members see it (only one member reports back
membership). This process is shown in Figure 14-8, where you can see the router sending the IGMP query to all
multicast hosts on the LAN.
566
 14. Multicast Protocols

Figure 14-8. IGMP Messages on a LAN

Periodically, IGMP will resend this message to verify the membership of each host. To avoid an immediate flood of
responses as every host on the LAN responds, each host will reply at a random interval so the responses are staggered.
When a host wants to leave a multicast group, it sends an IGMP leave message, as shown in Figure 14-9, to the
multicast address 224.0.0.2.

www.ebook-converter.com
Figure 14-9. Host Leaving a Multicast Group
IGMP has three versions (1, 2, and 3), and in order for a router to interop, just make sure you are using the right
version! Juniper Networks routers support all three versions. Version 3 inherently provides interoperability with versions
1 and 2. Also, the default version of IGMP, unless specified, is version 2. IGMP is defined in the following documents:
RFC 1112, “Host Extensions for IP Multicasting” (defines IGMP Version 1)
RFC 2236, “Internet Group Management Protocol, Version 2”
“Internet Group Management Protocol, Version 3,” draft-ietf-idmr-igmp-v3-01.txt

Configuring IGMP
In JUNOS the presence of IGMP is activated by default on broadcast interfaces once you turn on a multicast routing
protocol. This is an extremely intelligent implementation of IGMP by Juniper Networks. You are thus freed from
configuring the background communication of the dynamic routing protocol when, say, DVMRP or PIM is activated,

Downloader demo watermarks

provided your network and the default parameters of IGMP are compatible. Now, the chances of you running multicast
on an all broadcast net works is not likely in the real world, so let's look at the various steps to activate IGMP and set its
parameters. To activate IGMP manually, you enter the edit protocols igmp command in configuration mode.
[edit]
Lab@Chicago# edit protocols igmp

567
 14. Multicast Protocols
As you are by now aware, the various configuration options are accessible as you have entered into the IGMP protocol
edit mode. In this instance IGMP provides you with the ability to activate it by interface (all are now on, unless an
interface is specified). The example below shows the parameters that can be set, but we strongly suggest that you do not
alter the defaults unless necessary and only after careful consideration. Consult the Juniper Networks documentation for
the operational range of each parameter and the impact possible to your network.
[edit protocols igmp]
Lab@Chicago# set ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
> interface Interface options for IGMP
query-interval When to send host-query messages (1..1024 seconds)
query-last-member-interval When to send group query messages (seconds)
query-response-interval How long to wait for a host-query response (seconds)
robust-count Expected packet loss on a subnet (2..10)
> traceoptions Trace options for IGMP

Verifying an IGMP Configuration

To verify that your configuration of IGMP was successful you can execute a show igmp keyword command at the
CLI to determine IGMP's status.
Lab@Chicago> show igmp ?
Possible completions:
group Show IGMP group members
interface Show IGMP interfaces
statistics Show IGMP statistics

www.ebook-converter.com
The following example shows an executed show igmp interface command. By default, JUNOS activates IGMP
on all router interfaces if none are specified in edit mode.
Lab@Chicago> show igmp interface
Interface State Querier Timeout Version Groups
fe-0/0/0.0 Up 192.168.254.70 None 2 1
fe-0/0/1.0 Up 51.0.0.1 None 2 0
fe-0/0/2.0 Up 10.0.0.1 None 2 0

Configured Parameters:
IGMP Query Interval (1/10 secs): 1250
IGMP Query Response Interval (1/10 secs): 100
IGMP Last Member Query Interval (1/10 secs): 10
IGMP Robustness Count: 2

Derived Parameters:
IGMP Membership Timeout (1/10 secs): 2600
IGMP Other Querier Present Timeout (1/10 secs): 2550

Downloader demo watermarks

Lab@Chicago>
Monitoring the transmission statistics for IGMP is also possible through the use of the show igmp statistics
command, as shown below. Notice in the command output that you see individual reports on the various types of
multicast transmissions the router is sending and receiving; plus, the JUNOS implementation is multivendor capable as

568
 14. Multicast Protocols
well!
Lab@Chicago> show igmp statistics
IGMP packet statistics for all interfaces
IGMP Message type Received Sent Rx errors
Membership Query 9 42 0
V1 Membership Report 17 0 0
DVMRP 0 0 0
PIM V1 0 0 0
Cisco Trace 0 0 0
V2 Membership Report 0 0 0
Group Leave 0 0 0
Mtrace Response 0 0 0
Mtrace Request 0 0 0
Domain Wide Report 0 0 0
V3 Membership Report 0 0 0
Other Unknown types 0
IGMP v3 unsupported type 0
IGMP v3 source required for SSM 0
IGMP v3 mode not applicable for SSM 0
IGMP Global Statistics
Bad Length 0
Bad Checksum 0
Bad Receive If 0
Rx non-local 9

Lab@Chicago>
You can use the show igmp statistics command to see not only all the IGMP processes running, but, if you

www.ebook-converter.com
recall, OSPF also uses multicast, and the multicast OSPF-assigned addresses show up in this command, giving you a
nice way to see OSPF's operation in the most unlikely place. As the network is running IGMP and OSPF to the same
neighbor, the entries are there for each multicast address (IGMP, IGMP Group, OSPF ALL, OSPF DR). Specifically,
the use of the show igmp group brief command shows you the multicast addresses that are being used on a per-
interface basis.
Lab@Chicago> show igmp group ?
Possible completions:
<[Enter]> Execute this command
<group-name> Show a particular IGMP group
brief Show brief view
detail Show detail view
| Pipe through a command

Lab@Chicago> show igmp group brief

Interface Group Source Last Reported Timeout
fe-0/0/0.0 224.0.0.2 0.0.0.0 192.168.254.69 225
fe-0/0/1.0 224.0.0.2 0.0.0.0 51.0.0.2 229

Downloader demo watermarks

fe-0/0/1.0
fe-0/0/1.0
fe-0/0/1.0
224.0.0.5
224.0.0.6
224.0.0.22
0.0.0.0
0.0.0.0
0.0.0.0
51.0.0.2
51.0.0.2
51.0.0.2
228
225
233
fe-0/0/2.0 224.0.0.5 0.0.0.0 10.0.0.2 229
fe-0/0/2.0 224.0.0.6 0.0.0.0 10.0.0.2 224

569
 14. Multicast Protocols
The output below shows the actual OSPF neighbors that are present.
Lab@Chicago> show ospf neighbor
Address Interface State ID Pri Dead
192.168.254.253 fe-0/0/0.0 Full 10.10.10.10 1 33
10.0.0.2 fe-0/0/2.0 Full 10.0.0.2 128 34
51.0.0.2 fe-0/0/1.0 Full 51.0.0.2 128 38
Lab@Chicago>

Multicast Routing
Networks of all types are constructed of myriad subnets provided connectivity by routers at Layer 3. The importance of
knowing who you are (source IP address) and where you are going (destination IP address) is how IP unicast routing
operates. This is a rather simplistic way of explaining how IP routing works; however, that is okay for purposes of
comparing and explaining how multicast routing works. The IP routing procedure is relatively straightforward, but the
fundamental point to keep in mind is the binding of a single address to a single host.
Multicast routing, however, is a bit more complex than IP routing because a multicast address identifies a multicast
group instead of a physical destination. An individual host is able to join a multicast group by using IGMP to
communicate the join message to its LAN router. Because the number of receivers for a multicast session can be quite
large, the source of the multicast transmission does not need to know all the relevant destination addresses of the hosts
that have elected to receive (i.e., join) the multicast session. The routers only need to know that on a given LAN, there
is at least one host interested in this multicast group. The basic principal involved in multicast routing is that routers
interact with each other to exchange information about neighboring multicast routers.
To avoid duplication of effort, a single router is selected (via IGMP) as the DR for each physical network. The DR
constructs a tree from the source that connects each IGMP interface (port) reporting group members to the multicast

www.ebook-converter.com
group. This tree stretches throughout your WAN and is also referred to as the spanning tree, distribution tree, and
source tree.
The tree employs technology to ensure that it is loop-free in nature. Figure 14-10 shows a tree that has no loops and also
compares a normal IP routing structure based on subnets (left) and a multicast distribution tree (right).

Downloader demo watermarks

Figure 14-10. Comparisons of IP Subnet Structure for Routing and a Multicast Distribution Tree
As you can see in the figure, the multicast distribution tree (right) is built with a single active multicast path to each
router that has interfaces (connected to each router) that need to receive the multicast event. There can be one or more
570
 14. Multicast Protocols
hosts that are part of the multicast group on the networks connected to these interfaces. Multicast messages are
replicated only at those points where the tree branches, thus minimizing the number of copies of the messages that are
transmitted through the network. Multicast-enabled applications send one copy of each packet using a multicast
address, and the network routers forward the packets to only those LANs that have receivers.
As already discussed, hosts can join or leave multicast groups at anytime. This ability requires that the multicast tree
have the ability to be dynamically updated to reflect these changes. Imagine if the router was forwarding the multicast
information to a LAN where only one host was designated to receive it and that host left the tree. This could have a
serious effect on the tree. Thus, the tree is designed to be dynamically updatable by pruning (removing) branches that
no longer need the multicast data.
Branches with no listeners are discarded (pruned). The type of distribution tree used and the way multicast routers
interact depend on the objectives of the routing protocol. For example, the multicast routing protocols have different
philosophies with regard to receiver distribution, number of sources, reliability of data delivery, speed of network
convergence, shared path versus source path, and, if shared path, the direction of data flow. We could devote many
pages to discussing these concepts and comparing them. However, to do so is really beyond the scope of this book. For
additional information, refer to the bibliography for more resources.

Shared and Source Trees

There are two different types of multicast trees possible: shared and source. Each type of tree, as you will see, has
various benefits and risks as well. The type of tree used is determined by the multicast routing protocol being used in the
network.
When the multicast routing protocol creates a shared distribution tree, the route to and from a source of a multicast
broadcast can be shared and accessed by all sources over a topology that is either one-way or bidirectional. This has the
added benefit of using less memory because a router will be the root of multiple multicast flows, thus aggregating them
at one central point. However, the most important issue is that you may get suboptimal paths from the multicast event

www.ebook-converter.com
source(s) to all receivers, and shared trees may introduce extra delay in your network. Notice in Figure 14-11 that the
shared root router D has induced an additional two hops from source 1.

Figure 14-11. Shared Distribution Tree

Downloader demo watermarks

A multicast routing protocol creates a source distribution tree as a separate tree for each source via a single path
through the network. The routers use a greater amount of memory as multiple paths are created, but you get more
optimal paths from source to all receivers and delay is minimized. An example of a source-based distribution tree is
shown in Figure 14-12. You can see the tree is developed completely from the multicast source.

571
 14. Multicast Protocols

Figure 14-12. Source Distribution Tree

Dense- and Sparse-Mode Routing Techniques

As described earlier, IP multicast traffic is generated by a source and is transmitted to a group of receivers. The path to
each group is calculated via the creation of a tree. There are two types of trees, shared and source, to distribute
multicast traffic.
Multicast routing algorithms and protocols follow one of two basic approaches to route: dense mode or sparse mode.
The selection of the appropriate approach to use is based on the distribution of the multicast group members across the
network. Members are either densely or sparsely distributed, and this forms the basis of each type.
A dense-mode approach is based on the assumption that multicast group members are densely distributed across the

www.ebook-converter.com
network and that available bandwidth is plentiful. Multicast routing protocols that rely on this mode will use periodic
flooding to set up and maintain their distribution trees. Examples of protocols that use dense mode are DVMRP,
MOSPF, and Protocol-Independent Multicast—Dense Mode (PIM-DM).
A sparse-mode approach is based on the assumption that multicast group members are sparsely distributed across the
network and that available bandwidth is not plentiful. Sparse mode addresses concerns opposite to those addressed by
dense mode and is typically used when multicasting across multiple routing domains, including Internet scenarios. An
important design and use point is that sparse mode does not imply that a group has few members, just that they are
widely dispersed. This means that sparse mode will not use flooding to accomplish the creation of its distribution tree;
instead, it will use more selective techniques, which we will discuss in that protocol-specific section. Sparse-mode
routing protocols include Core-Based Trees (CBT) and Protocol-Independent Multicast—Sparse Mode (PIM-SM).
PIM-SM is the most common multicast technology used on the Internet today.
In conclusion, if you are trying to decide which PIM mode to use and when, many networks with a lot of multicast users
on a LAN should use PIM-DM. Enterprise networks with heavy multicast transmission needs. Service providers should
use PIM-SM.

Routing with JUNOS and Multicast

Downloader demo watermarks
A separate routing table, known as a RIB, is needed for DVMRP to operate correctly. The IP unicast routing table is
needed as DVMRP relies on the presence of routes in the inet.0 routing table to function properly.
Because we are going to enter into the realm of RIBs again, let's take a moment to review what they are and what their
function is. We first introduced RIBs when discussing BGP; however, they are used in multicasting as well. Table 14-4
572
 14. Multicast Protocols
lists the various predefined routing tables in JUNOS and their use.
Table 14-4. JUNOS Routing Tables
Table Function
inet.0 Default unicast routing table
instance-name.inet.0Unicast routing table for a given routing instance
inet.1 Multicast forwarding cache
inet.2 Unicast routes used for multicast RPF lookup
inet.3 MPLS routing table for path information
mpls.0 MPLS routing table for LSP next-hops
When using multicast function in JUNOS, you cannot transfer routing information from one family type to another.
Unicast routes cannot be placed in the multicast table, and multicast routes cannot be placed in the unicast table. To
work around this, JUNOS uses the rib-group statement, which will allow JUNOS to install unicast or multicast route
information in the rib-group.
Thus, the rib-group is where JUNOS will place the unicast and multicast routes once the group is defined. We will
look at how this configuration is done as part of configuring each multicast protocol. Two other aspects of rib-
groups important to configuring them are the export-rib and import-rib statements, which allow the placing
of routing information into and out of the rib-group. This allows us to exercise some granular control, which also will
be demonstrated later. A brief example will suffice for now. In this example, we will use the inet.2 RIB to hold the
multicast routing information. The use of inet.2 for this purpose is recommended in the Juniper Networks
documentation and is shown in Table 14-4 above.
routing-options {
rib-groups {
multicast-rib {

www.ebook-converter.com
export-rib inet.2;
import-rib inet.2;
}
}
}
As the above example shows, we can create a rib-group to hold our multicast routes, and once that occurs, the
group can then be used by a multicast protocol.

Dense-Mode Multicast Routing Protocols

Dense-mode multicast routing protocols assume that all routers in the network are to receive multicasts packets. As a
result, they use a flood-and-prune mechanism to build their multicast distribution tree. This flood-and-prune mechanism
floods multicast traffic out of all ports of the multicast-enabled router, except the one port closest to the multicast
source. When a receiving router processes these messages and determines that it does not need to receive the multicast
because it has no receivers indicating interest in the group with IGMP needing the transmission, a prune message is sent
back to the flooding router. In the process of sending the flood-and-prune messages, routers running a dense-mode
protocol create a source-based distribution tree. The root of the tree is the DR closest to the source of Group 1's
Downloader demo watermarks
multicast transmission. This concept is shown in Figure 14-13.

573
 14. Multicast Protocols

Figure 14-13. Dense-Mode Operation

In the figure, the network is operating in dense mode. As the example shows, the DR for the source has flooded
multicast packets because in dense mode, it is assumed every router wants to participate. Once the flooding occurs to
the DR's direct neighbors, they will continue the flooding, again because dense mode presumes all routers want to
participate.
The router that is directly connected to a host and that has indicated it is to join the multicast group continues to accept
the multicast packets. However, if the router has redundant links open by which multicast traffic is received, it sends a
prune message out of one of the redundant links. Routers that do not have receivers and that are members of the
multicast group send a prune message to the upstream router to indicate the branch is to be pruned. This process is
known as a flood-and-prune technique where each router is assumed to be a part of the multicast group, unless it
indicates otherwise to the upstream router and is pruned.
The use of dense-mode routing protocols guarantees the shortest, most efficient paths, but uses considerable bandwidth
to maintain the distribution tree as flooding is periodically repeated. Because of dense mode's ability to create an

www.ebook-converter.com
efficient distribution tree, it is ideal as an enterprise or single routing domain solution; dense mode does not scale well
across the Internet, which is, of course, why you do not use it there.

DVMRP
The first multicast protocol designed specifically to support multicast routing was DVMRP, which is described in RFC
1075. DVMRP was the first true multicast routing protocol to see widespread use. Based on Steve Deering's seminal
work, DVMRP is similar in many ways to Routing Information Protocol (RIP) with some minor variations added to
support the unique requirements of multicast. Some key characteristics of DVMRP include the following:
Distance-vector-based (similar to RIP)
Periodic route updates (every 60 seconds)
Infinity = 32 hops (versus 16 for RIP)
Poison reverse has special use in multicasting

Downloader demo watermarks

Classless (that is, route updates include masks)
DVMRP is a distance-vector multicast routing protocol designed to be used as an IGP within a multicast-enabled
network. DVMRP provides connectionless delivery of multicast packets by dynamically generating distribution trees.
For routers that do not support multicasting, DVMRP comes with the ability to tunnel multicast packets. Because
DVMRP was the first protocol, some unexpected limitations since its creation have come to light:
574
 14. Multicast Protocols
Slow convergence time
Limited network scope due to the infinity = 32 restriction
Inability to detect routing loops.
Only one metric—the hop count; the link-transfer rate is not taken into consideration
Will choose one path if several possible paths exist; does not permit load balancing.
DVMRP is defined in the following standard:
RFC 1075, “Distance Vector Multicast Routing Protocol”
There are not very many multicast resources, but if you wish to read more on the subject, consider the following
resources:
Williamson, Beau. Developing IP Multicast Networks. Cisco Press, 2000.
Maufer, Thomas A. Deploying IP Multicast in the Enterprise. Prentice Hall, 1997.

DVMRP Operational Overview

DVMRP assumes initially that every host on the network is part of the multicast group. The DR connected to the source
of the multicast transmission subnet, that is, the router that has been selected to handle routing for all sources on its
subnet, begins by transmitting a multicast message to all adjacent routers. Each of these routers then forwards the
message to downstream routers.
DVMRP constructs a different distribution tree for each source and its corresponding destination host group. The

www.ebook-converter.com
distribution tree provides a shortest path between the source and each multicast receiver in the group, based on the
number of hops in the path, which is the DVMRP metric. A distribution tree is constructed on demand, using the
broadcast-and-prune technique.
When a router receives a multicast message, it checks its unicast routing tables to determine the interface that provides
the shortest path back to the source. If this was the interface over which the multicast message arrived, then the router
enters some state information to identify the multicast group in its internal tables (specifying interfaces over which
messages for that group should be forwarded) and forwards the multicast message to all adjacent routers, other than that
which sent the message. This mechanism, called reverse path forwarding, or RPF, ensures that there will be no loops in
the distribution tree.
Figures 14-14 to 14-16 show how DVMRP works. In Figure 14-14, DVMRP floods IGMP messages out from the course
throughout the entire network.

Downloader demo watermarks

575
 14. Multicast Protocols

Figure 14-14. DVMRP Flooding

www.ebook-converter.com

Figure 14-15. Prune Messages Altering the Tree

Downloader demo watermarks

576
 14. Multicast Protocols

Figure 14-16. Graft Messages

The next step in DVMRP convergence is the receiving of prune messages from sections of the network that do not need
the multicast transmissions, as shown in Figure 14-15. The resulting network topology reflects the membership of hosts
only located via routers C and D.
As the multicast transmission continues and the company president continues to speak, a new host wishes to join. A
graft message is then sent from router F to join the distribution tree as shown in Figure 14-16.
These series of figures show the process that DVMRP uses to flood the network, prune routers that do not need to be a
part of the multicast group, and graft routers into the multicast group that now need to receive the transmission. The

www.ebook-converter.com
next section will look at the basics involved in configuring DVMRP.

Configuring DVMRP
This section describes how to configure DVMRP on a Juniper Networks router. By default, DVMRP is disabled, and
interfaces that can route DVMRP can either be physical or tunnel to support the connecting of multicast domains like
those discussed in Section 14.1. You will also need to create a separate routing table for DVMRP routes, as this section
will show.

Note
According to the JUNOS 5.0 documentation, you can configure DVMRP for either forwarding or unicast
routing modes. In forwarding mode, DVMRP operates its protocol normally (for example, it does the routing
as well as the multicast data forwarding). In unicast routing mode, you can use DVMRP for unicast routing
only; the actual forwarding of multicast data is done by enabling PIM on that interface. If you have
configured PIM on the interface, you can configure DVMRP in unicast routing mode only. You cannot
configure PIM and DVMRP in forwarding mode at the same time.

Downloader demo watermarks

The first step is to create the routing table that is going to reflect your DVMRP routes. Juniper Networks documentation
recommends that the DVMRP use inet.2 for its routing table entries, and we will follow that recommendation here.
You create the routing table in the [edit routing options] level of the hierarchy, as shown below:
Lab@Chicago# set interface-routes rib-group IN_FOR_MCAST
577
 14. Multicast Protocols
[edit routing-options]
Lab@Chicago# set rib-groups IN_FOR_MCAST import-rib inet.0
Lab@Chicago# set rib-groups IN_FOR_MCAST import-rib inet.2

[edit routing-options]
Lab@Chicago# set interface-routes rib-group IN_FOR_MCAST

[edit routing-options]
Lab@Chicago# set rib-groups OUT-DVMRP import-rib inet.2
[edit routing-options]
Lab@Chicago# set rib-groups OUT-DVMRP export-rib inet.2

[edit routing-options]
Lab@Chicago# show
interface-routes {
rib-group inet OUT-DVMRP;
}
rib-groups {
IN_FOR_MCAST {
import-rib inet.0;
}
OUT-DVMRP {
export-rib inet.2;
import-rib inet.2;
}
}
To activate DVMRP, enter the [edit protocols] hierarchy level and edit DVMRP as shown below:

www.ebook-converter.com
[edit protocols]
Lab@Chicago# edit dvmrp

[edit protocols dvmrp]

Lab@Chicago#
There are not very many optional parameters in DVMRP, and that reflects its simplicity and ease of use. However,
recall the limitations of DVMRP. JUNOS does provide you with the ability to apply policies to the DVMRP routing
table as needed. The important command is the rib-group assignment so that we can map the RIB created in the
previous step to DVMRP.
[edit protocols dvmrp]
Lab@Chicago# set ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
disable Disable DVMRP
+ export Export policy

Downloader demo watermarks

+ import
> interface
> rib-group
Import policy
DVMRP interface options
Routing table group
> traceoptions Trace options for DVMRP
We now need to assign the routing table inet.2 that we created to the DVMRP protocol to ensure we can route

578
 14. Multicast Protocols
multicast properly. The following example shows how to do this:
[edit protocols dvmrp]
Lab@Chicago# set rib-group OUT_DVMRP
Lab@Chicago#
To activate DVMRP on an interface, you execute the set command, as shown below. You could also use the all
keyword to activate DVMRP on every interface on the router.
[edit protocols dvmrp]
Lab@Chicago# set interface ?
Possible completions:
<interface_name> Interface name
[edit protocols dvmrp]
Lab@Chicago# set interface fe-0/0/1
Lab@Chicago#
The final configuration for IGMP and DVMRP is as follows:
routing-options {
interface-routes {
rib-group inet IN_FOR_MCAST;
}
rib-groups {
IN_FOR_MCAST {
import-rib [ inet.0 inet.2 ];
}
OUT-DVMRP {
export-rib inet.2;

www.ebook-converter.com
import-rib inet.2;
}
}
}
protocols {
igmp;
dvmrp {
rib-group inet OUT-DVMRP;
interface fe-0/0/1.0;
}
This configuration has successfully activated IGMP and DVMRP on a Juniper Networks router—at least we hope so.
The next section gives us the tools necessary to verify the correct operation.

Verifying a DVMRP Configuration

It is important to be able to verify the proper operation of DVMRP after you have configured it and when
troubleshooting. The show commands available to assist in this are shown below:

Downloader demo watermarks

Lab@Chicago> show dvmrp ?
Possible completions:
grafts Show the DVMRP graft retransmission queue
interfaces Show DVMRP interfaces
neighbors Show DVMRP neighbors
579
 14. Multicast Protocols
prefix Show DVMRP prefixes
prunes Show DVMRP prunes
The command explanations are accurate for what you can expect to see. Now that you have created a new routing table
for DVMRP, inet.2, looking at its contents will also be of assistance. Consider the following output and keep in mind
that the router has IGMP configured on all interfaces, but only DVMRP on fe-0/0/1, so the contents of the inet.2
routing table will reflect that multicast does not know about the 30.30.30.0/24 network.
Lab@Chicago> show route terse

inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

A Destination P Prf Metric 1 Metric 2 Next hop AS path

* 10.0.0.0/24 D 0 >fe-0/0/2.0
* 10.0.0.1/32 L 0 Local
* 30.30.30.0/24 O 10 20 >51.0.0.2
* 51.0.0.0/24 D 0 >fe-0/0/1.0
* 51.0.0.1/32 L 0 Local
* 192.168.254.0/24 D 0 >fe-0/0/0.0
* 192.168.254.70/32 L 0 Local
* 224.0.0.4/32 D 110 MultiRecv
* 224.0.0.5/32 O 10 1 MultiRecv

inet.2: 6 destinations, 6 routes (6 active, 1 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 10.0.0.0/24 D 0 >fe-0/0/2.0
* 10.0.0.1/32 L 0 Local

www.ebook-converter.com
* 51.0.0.0/24 D 0 >fe-0/0/1.0
D 0 >fe-0/0/1.0
* 51.0.0.1/32 L 0 Local
* 192.168.254.0/24 D 0 >fe-0/0/0.0
* 192.168.254.70/32 L 0 Local

Lab@Chicago>
This command provides you with an abbreviated high-level view of the contents of the routing table; you can see simple
things, like if a route is active, as well as the destination network, metric, and next-hop—all crucial bits for effective
routing.

PIM Routing Protocol

The PIM routing protocol is currently under development by an IETF working group and has been since 1998, so don't
hold your breath for it to be finalized. Regardless, PIM is being deployed widely on the Internet for intradomain
multicast routing because, as we discussed, DVMRP is just too limited for use in the Internet.

Downloader demo watermarks

The objective of PIM was to develop a standard multicast routing protocol that could provide scalable intradomain
multicast routing across the Internet, independent of the mechanisms provided by any particular unicast routing
protocol. PIM has two operational modes:
1. PIM-DM for densely distributed multicast groups

580
 14. Multicast Protocols
2. PIM-SM for sparsely distributed multicast groups
Dense-mode routing protocols all rely on the periodic flooding of messages throughout the network with the assumption
that every router wants to be a part of the multicast group. This approach can be quite effective under certain
circumstances; however, it is not without its problems and drawbacks. For example, consider what would happen to a
network if several thousand different multicast conferences started at once. The network would get quite busy!
Clearly a different solution is needed for group members widely dispersed across a WAN. While dense-mode protocols
use a data-driven approach to construct multicast distribution trees, sparse-mode protocols use a receiver-initiated
process; that is, a router becomes involved as part of a multicast distribution tree only when one of the hosts on its
subnet requests membership in a particular multicast group.
In sparse mode, routers must join the distribution tree explicitly because other routers do not automatically forward
multicast traffic. When a host joins a multicast group the local LAN router sends a join message to the router that has
been designated as the rendezvous point (RP) for the multicast group. This RP designation for a router is similar to the
DR designation that we discussed in Section 14.4. In sparse mode, the RP serves as the root of the shared multicast
distribution tree. The RP router is responsible for forwarding multicast data from different sources to those who have
joined the group and, thus, elected to receive it. The following sections describe these two modes.

PIM-DM
PIM-DM is similar to DVMRP. Both protocols employ reverse path multicasting (RPM) to construct source-rooted
distribution trees. The major differences between DVMRP and PIM-DM are that PIM is completely independent of the
unicast routing protocol used on the network, while DVMRP relies on specific mechanisms of the associated unicast
routing protocol. PIM-DM is also less complex than DVMRP. Some key characteristics of PIM-DM are as follows:
PIM-DM uses an underlying unicast routing protocol (RIP, IGRP, OSPF) to build its multicast routing tables, which
is one of the strongest reasons that PIM is replacing DVMRP.

www.ebook-converter.com
A router running PIM assumes that all other routers want to forward multicast packets for a group.
If a router receives a multicast packet and has no directly connected members or no PIM neighbors, a prune packet
is sent back to the source.
PIM-DM creates a source-based multicast distribution tree.
PIM-DM is used when bandwidth is plentiful.
PIM-DM is defined in draft-ietf-idmr-pim-dm-spec-05.txt.

PIM-DM Operational Overview

Figures 14-17 to 14-19 show how PIM-DM works. In Figure 14-17 you can see that PIM has flooded the entire
network, starting at the source and sending multicast flood messages throughout the network.

Downloader demo watermarks

581
 14. Multicast Protocols

Figure 14-17. PIM Flooding

www.ebook-converter.com
Figure 14-18. PIM Pruning

Downloader demo watermarks

Figure 14-19. PIM Graft Request

582
 14. Multicast Protocols
In Figure 14-18 the network between routers B and C is pruned because it does not complete the RFP neighbor
requirements. Also, during this time, routers E and I get pruned as well because they do not have receivers.
In Figure 14-19, receiver 3 has entered the multicast group and the graft request is being sent to make receiver 3 part of
the tree.
This series of figures demonstrate the process that PIM goes through upon activation of a new multicast group, flooding,
pruning, and possibly grafting. The next section will look at how basic PIM-DM is configured on a Juniper Networks
router.

Configuring PIM-DM
This section describes how to configure PIM-DM on a Juniper Networks router. By default, on a Juniper Networks
router, PIM operates in dense mode. The configuration here will be the basic configuration from which you can alter its
mode of operation should you desire to operate in PIM-SM, which we will be discussing in Section 14.5.2.2. Keep in
mind that with PIM you do not need to configure a separate routing table because PIM is protocol-independent and
designed not to rely on an IP unicast routing protocol like DVMRP was. You can, however, create a routing table just
for multicast data if you want, although it is unnecessary.
As with all protocols in JUNOS software, you must activate the protocol by telling the router which interfaces it should
operate over as shown below:
[edit protocols]
Lab@Chicago# edit pim

[edit protocols pim]

Lab@Chicago# set interface all
The completed basic configuration will look as follows:

www.ebook-converter.com
protocols {
igmp;
ospf {
area 0.0.0.0 {
interface fe-0/0/0.0;
}
area 0.0.0.10 {
interface fe-0/0/2.0;
}
area 0.0.0.51 {
interface fe-0/0/1.0;
}
}
pim {
interface all;
}
}
Downloader demo watermarks
There are a couple of configuration tips and JUNOS implementation nuances that you should be aware of with PIM
when it is operating in dense mode.
All PIM routers on the same subnet must run the same version of PIM.

583
 14. Multicast Protocols
A PIM-enabled interface has a default priority of 1, which is the lowest priority; thus, the likelihood of it becoming
the PIM DR is reduced.
There are additional considerations if you are running PIM-SM, which we will discuss in Section 14.5.2.2.

Verifying a PIM-DM Configuration

To verify the operation and configuration of PIM there are a variety of useful show commands. The first example
below shows the output from the show pim ? command:
Lab@Chicago> show pim ?
Possible completions:
bootstrap Show PIM bootstrap routers
interfaces Show PIM interfaces
join Show PIM join/prune state
neighbors Show PIM neighbors
rps Show PIM rendezvous points
source Show the PIM source RPF state
statistics Show PIM statistics
wildcard Show PIM (*,*,RP) Join/Prune state
This next example shows which interfaces are running PIM on your router, which is very useful when you have a router
with a large number of ports:
Lab@Chicago> show pim interfaces
Name Stat Mode V State Priority DR address Neighbors
fe-0/0/0.0 Up Dense 2 DR 1 192.168.254.70 0
fe-0/0/1.0 Up Dense 2 NotDR 1 51.0.0.2 1
fe-0/0/2.0 Up Dense 2 NotDR 1 10.0.0.2 1

www.ebook-converter.com
The following command output is very useful in determining the status of your PIM neighbors and their address. When
trying to determine the flow of the multicast event, this is a great place to start as it's only going to neighbors!
Lab@Chicago> show pim neighbors
Interface DR priority Neighbor addr V Mode Holdtime Timeout
fe-0/0/1.0 1 51.0.0.2 2 Unknown 105 98
fe-0/0/2.0 1 10.0.0.2 2 Unknown 105 79

PIM-SM
PIM-SM is referred to as protocol-independent, just like PIM-DM. In fact, both are independent of the underlying
routing protocol; they just function in different ways. PIM-SM does not flood like a dense-mode protocol, and it has an
RP. The RP keeps track of multicast groups by requiring that they register before any traffic gets transmitted. From a
host's perspective they register with their directly connected router, which in turn registers them to the RP. The RP then
sends a join message towards the source of the multicast transmission. At this point, packets are forwarded on a shared
distribution tree. If the multicast traffic from a specific source is sufficient, the receiver's first-hop router may send join
messages toward the source to build a source-based distribution tree. A RP has the following characteristics:
Downloader demo watermarks
The RP can be selected statically or by allowing the network to determine it dynamically.
It is used to keep track of multicast group.
A multicast source is registered with the RP by the source's first hop router.
584
 14. Multicast Protocols
Some of the key operational characteristics of PIM-SM are as follows:
PIM-SM assumes that the source and destination are distant and is more appropriate for WAN links where
bandwidth is limited.
It is similar to PIM-DM, but requires an explicit join message from downstream receivers instead of assuming that
all receivers want to receive traffic.
Its multicast tree is built around a central RP.
Members who want to receive the multicast graft themselves to the RP.
PIM-SM is defined in the following documents:
RFC 2362, “Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification.”
“Anycast RP Mechanism Using PIM and MSDP,” Internet draft, draft-ietf-mboned-anycast-rp-05.txt.

Bootstrap Router
The Bootstrap router (BSR) mechanism is used for PIM-SM to learn the multicast group mappings to the RP. As we
have discussed, the RP serves as a distribution point
Sparse mode uses a BSR, an RP, and a shared tree topology to route multicast traffic. Within multicast domains, the RP
serves as a distribution point for the router in a specific set of multicast groups. Each RP informs the BSR of the
multicast group it serves. The BSR collects the RP to multicast group mappings (RP-set) within its domain, builds a
database, and dynamically distributes the RP information to the multicast routers within its domain.

Configuring PIM-SM
www.ebook-converter.com
This section will discuss how to configure PIM-SM on a Juniper Networks router. As mentioned earlier, the default
mode of operation is dense mode. Instead of rebuilding our PIM configuration, we will specify the mode of operation.
Note, however, that we do this on a per-interface basis and not globally. Plus, it is done in interface configuration mode.
The following example shows the completions for the set interface all command:
[edit protocols pim]
Lab@Chicago# set interface all ?
Possible completions:
<[Enter]> Execute this command
+ apply-groups Groups from which to inherit configuration data
disable Disable PIM on this interface
hello-interval Hello interval (0..255 seconds)
mode Mode of interface
priority Hello option DR priority (0..4294967295)
version Force PIM version (1..2)
| Pipe through a command
Downloader demo watermarks
Lab@Chicago#
This example shows the completions for the set interface all mode command:
[edit protocols pim]
Lab@Chicago# set interface all mode ?
585
 14. Multicast Protocols
Possible completions:
dense Dense mode
sparse Sparse mode
sparse-dense Sparse-dense mode
Lab@Chicago#
This command sets all interfaces on the router to be in PIM-SM.
[edit protocols pim]
Lab@Chicago# set interface all mode sparse
Lab@Chicago#
In this command output we will take a quick look at what we have configured by running a show command, which will
show us what our configuration is within that configuration level:
[edit protocols pim]
Lab@Chicago# show
interface all {
mode sparse;
}

[edit protocols pim]

Lab@Chicago#
There are a couple of configuration tips and JUNOS implementation nuances that you should be aware of with PIM
when it is operating in sparse mode:
All PIM routers on the same subnet must run the same version of PIM. By default, PIM operates using version 2.

www.ebook-converter.com
A PIM-enabled interface has a default priority of 1, which is the lowest. Thus, the likelihood of it becoming the
multicast DR is reduced.
RP can be modified to force election of a router.
There is a reduced set of operational and implementation considerations that are relevant if you are running PIM dense
mode that we discussed in that section.

Verifying a PIM-SM Configuration

The verification commands available were discussed in the PIM-DM section and are the same; additional commands
reflect the RP and sparse-mode elections.

Interdomain Multicast Routing

Up until this point, this chapter has discussed multicasting solutions and technologies that would easily run within a
single routing domain. This solution is straightforward if you are an enterprise network using multicast to provide

Downloader demo watermarks

information only to your employees. However, the providers of multicast content across the Internet are growing every
day.
A solution was needed to look at the practical realities we are faced with when considering routing between ASs. In
most cases, this is routing between ISPs. As a result, they are competitors on one level, but because they must meet the
needs of their customers, cooperation is paramount as multicast becomes more prevalent. The current multicast

586
 14. Multicast Protocols
requirements place new challenges on today's providers. Specifically let's address some of them here to help us
understand the technologies that we will be discussing.
One specific area of concern is that PIM-SM requires only one active RP within a multicast group. Obviously, ISPs do
not want to rely upon a third-party RP, so they must have their own RP for each multicast group. Another area of
concern revolves around business factors, and there are many of them. Suffice it to say that an ISP and its customers are
better served when the RP is within their AS (e.g., under their control). The final point we will mention is that ISPs may
want to control traffic within their network to ensure effective utilization. Consider that unicast traffic might have a
certain set of policies applied, when a different set of policies is needed for multicast.
Yes, there are ways around this issue using the technologies presented so far; however, they have fallen short, and in
many cases, the factors behind using them are not strong enough for them to be considered permanent solutions. As a
result two technologies have emerged to address this concern: MSDP and MBGP, which are addressed in the Sections
14.5.3.1 and 14.5.3.2, respectively.
MBGP creates extensions to the widely used BGP to support this requirement. MBGP adds a multicast-only
reachability table to the existing unicast reachability table of BGP. With MBGP, a router can effectively have two BGP
tables, one for multicast and one for unicast. Routers can be configured to look first at the multicast reachability table
when making RPF checks. If a network is not in the multicast reachability table, it will then use the unicast routing
protocol to perform the RPF. Experienced BGP users should have no difficulty learning to configure and maintain the
extensions of MBGP. Furthermore, MBGP is backward compatible with BGP.

MSDP
MSDP is a protocol allowing the connection of multiple PIM-SM domains. If you recall the discussion about mbone at
the beginning of the chapter, it is actually composed of multicast islands. Consider for a moment that in the Internet an
mbone multicast island is analogous to an AS. Keep this analogy in mind as we discuss the way MSDP can be used as a
solution.

www.ebook-converter.com
MSDP allows the multicast sources for a multicast group to be known to all RPs in different multicast domains. Each
PIM-SM domain uses its own RPs and need not depend on RPs in other domains. An RP runs MSDP over TCP to
discover multicast sources in other domains.
An RP in a PIM-SM domain has an MSDP peering relationship with MSDP-enabled routers in another domain. The
peering relationship occurs over a TCP connection, where primarily a list of sources sending to multicast groups is
exchanged. The TCP connections between RPs are achieved by the underlying routing system (BGP). The receiving RP
uses the source lists to establish a source path. Through these peerings, RPs exchange source active (SA) messages,
which describe all of the registered sources within their respective domains. In this way, RPs learn all of the active
sources from other domains, in addition to the sources from their own domain.

Configuring MSDP
When you set out to configure MSDP on your Juniper Networks routers, you will have a variety of options. As an
introduction, this book will discuss the basic MSDP configuration; additional configuration options can be found in the
Juniper Networks multicast documentation.

Downloader demo watermarks

Enable MSDP by setting the local-address that the other MSDP router will use to communicate with the router
you are configuring, as follows:
[edit protocols msdp]
Lab@Chicago# set local-address 30.30.30.2

587
 14. Multicast Protocols
[edit protocols msdp]
Lab@Chicago#
MSDP also requires the configuration of peers, and there must be at least one peer configured for proper operation. We
can see the configuration as shown below:
[edit protocols msdp]
Lab@Chicago# set peer 30.30.30.1

[edit protocols msdp]

Lab@Chicago#
JUNOS provides you with a several options that can further expand the capabilities of MSDP. These options reflect the
role MSDP plays in providing connections between routing domains. Briefly, the additional configuration options that
are possible are route import/export and peer groups. In the next section we will introduce MBGP and how it is
configured on a Juniper Networks router.

MBGP
MBGP is the other technology used to provide connectivity between different multicast domains. Now, many people
think MBGP means Multicast BGP, and in fact it does not. The regular BGP that we all know and love was designed for
IPv4, which while a great idea, left many protocols unsupported. RFC 2283 defined MBGP and states that the use of
MBGP will allow BGP to carry different routing information for multiple network layer protocols (e.g., IPv6, IPX). You
would use MBGP when ISP-to-ISP multicast peering was needed or if your network was multihomed to two different
providers. For the purposes of multicast, MBGP uses a wide variety of BGP characteristics to provide connectivity for
multicast groups between different domains. Some of its characteristics are as follows:
Unicast and multicast routes can be carried in the same BGP session.

www.ebook-converter.com
It uses the same route-selection criteria as BGP, while allowing access to the same attributes.
Different policies and topologies are possible for unicast and multicast.
This chapter presents just a few of the more important characteristics to be aware of. MBGP accomplishes the
advanced ability of adding several new multiprotocol attributes, specifically the following:
MP_REACH_NLRI—defines and carries the reachable prefixes and the next-hop address for that prefix
MP_UNREACH_NLRI—defines and carries the unreachable prefixes and the next-hop address for that prefix
These multiprotocol attributes allow multicast to be carried along with unicast traffic. The actual use of these attributes
is reflected in the presence of multicast routes in the inet.2 routing table, as we have already discussed.
The presence of an internal multicast routing protocol for internal routing is still needed. Juniper Networks recommends
the use of PIM-SM to build the multicast distribution trees and provide the mechanism for forwarding multicast traffic.
In Section 14.5.2.2, we discussed the operation and configuration of PIM-SM.

Downloader demo watermarks

If you want to learn more about MBGP and specifics on how it operates within JUNOS, do not look under the multicast
section of their documentation. Remember that this is multiprotocol BGP, so consult the BGP section!

Configuring MBGP
BGP uses NLRI, as was discussed in Chapter 9. When using MBGP for multicast, the challenge is getting BGP to carry
588
 14. Multicast Protocols
NRLI information for the multicast routes. You can configure the router for MBGP by individual BGP peer or for an
entire group. In the following configuration example, we can activate MBGP as shown:
[edit]
Lab@Chicago# edit protocols bgp group MCAST neighbor 30.30.30.1 family inet ?
Possible completions:
<[Enter]> Execute this command
> any Include unicast or multicast NLRI
> multicast Include multicast NLRI
> unicast Include unicast NLRI
| Pipe through a command
[edit]
Lab@Chicago#
The default configuration is unicast; if you want to cons a peer for just multicast, you select the multicast option. If,
however, you want to run both IP unicast and multicast, then use the any keyword. A configuration for MBGP and
unicast would look similar to the following sample:
[edit protocols bgp group MCAST]
Lab@Chicago# show
neighbor 30.30.30.1 {
family inet {
any;
}
}

[edit protocols bgp group MCAST]

Lab@Chicago#

www.ebook-converter.com
As discussed in Part III, JUNOS has multiple routing tables and families of protocols. When you complete the above
configuration of MBGP, the multicast routes learned are placed into a separate routing table from the unicast routes, as
we discussed. An address family indicator (AFI) and a subaddress family indicator (SAFI) identify each of these routing
tables and families of protocols. JUNOS supports the following:
AFI inet and SAFI 1 for unicast routes
AFI inet and SAFI 2 for multicast sources
AFI inet and SAFI 3 for both unicast and multicast prefixes.
Consider, then, if BGP receives a unicast prefix with SAFI 1, it places this route into the inet.0 routing table, SAFI 2
prefixes go into inet.2, and SAFI 3 prefixes go into both routing tables. This is important to note as the prefixes
present in inet.2 are those sent to MBGP peers. Of course, you can also set a policy to import or export routes
between the routing tables if that functionality is needed.

Chapter Summary
Downloader demo watermarks
This chapter introduced and discussed the more important aspects of multicast. It provided an overview of the most
popular and widely implemented multicast routing protocols both currently and historically. This chapter discussed and
compared the differences between PIM-DM and PIM-SM, as well as looking at how multicast evolved through
DVMRP.
While comparing and contrasting the differences between their modes of operation, each of the protocols was covered
589
 14. Multicast Protocols
with a focus on the method of configuring it on a Juniper Networks router. The needs of multicast to be distributed
properly between different ASs through the use of MSDP and MBGP were also examined.
This chapter was an introduction to multicast and its brief entry into the world of multicast. Additional information on
multicast and Juniper Networks can be found in Brian Edwards and Leonard A. Giuliano's Interdomain Multicast
Routing: Practical Juniper Networks and Cisco Systems Solutions, my favorite in the Juniper Networks
documentation.

Bibliography

www.ebook-converter.com

Downloader demo watermarks

590
[ch14bib01] “Anycast RP Mechanism Using PIM and MSDP,” Internet-Draft, draft-ietf-
mboned-anycast-rp-05.txt.
[ch14bib02] “Distance Vector Multicast Routing Protocol,” Internet-Draft, draft-ietf-
idmr-dvmrp-v3-07.
[ch14rfc1075] IETF RFC—RFC 1075, Distance Vector Multicast Routing Protocol. D.
Waitzman, C. Partridge, S. Deering. 1988.
[ch14rfc1112] IETF RFC—RFC 1112, Host Extensions for IP Multicasting (defines
IGMP Version 1). S. Deering. 1989.
[ch14rfc2236] IETF RFC—RFC 2236, Internet Group Management Protocol, Version 2.
W. Fenner. 1997.
[ch14rfc2327] IETF RFC—RFC 2327, SDP: Session Description Protocol. M. Handley,
V. Jacobson. 1998.
[ch14rfc2362] IETF RFC—RFC 2362, Protocol Independent Multicast-Sparse Mode
(PIM-SM): Protocol Specification. D. Estrin, et al. 1998.
[ch14rfc2365] IETF RFC—RFC 2365, Administratively Scoped IP Multicast. D. Meyer.
www.ebook-converter.com
1998.
[ch14rfc2205] “Internet Group Management Protocol, Version 3,” Internet-Draft, draft-
ietf-idmr-igmp-v3-01.txt.
[ch14bib10] Thomas A. Maufer, Deploying IP Multicast in the Enterprise. Prentice Hall,
<year>1997</year>.
[ch14bib11] “MSDP,” Internet-Draft, draft-ietf-msdp-spec-13.txt.
[ch14bib12] “Protocol Independent Multicast Version 2 Dense Mode Specification,”
Internet-Draft, draft-ietf-pim-v2-dm-03.txt.
[ch14bib13] “SAP: Session Announcement Protocol,” Internet-Draft, draft-ietf-mmusic-
Downloader demo watermarks
sap-00.
[ch14bib14] Draft-ietf-idmr-pim-dm-spec-05.txt.

591
[ch14bib15] Beau Williamson,. Developing IP Multicast Networks: The Definitive Guide
to Designing and Deploying CISCO IP Multicast Networks. Cisco Press, <year>2000.
</year>

www.ebook-converter.com

Downloader demo watermarks

592
 15. Troubleshooting Juniper Networks Routers
Chapter 15. Troubleshooting Juniper Networks Routers
So far, you have been provided with a lot of information on everything from the architecture of the router to
the command structure of JUNOS, from the configuration of interfaces to the configuration of routing
protocols. All of this information has helped you to gain insight into the structure and reasoning behind not
only the router, but the Internet itself. However, consider that even the most reliable router in the most stable
network will encounter problems sooner or later. What happens when you encounter a problem on a Juniper
Networks router?
This chapter is designed to explain the process of troubleshooting the routers and to provide you with some
sample output, in addition to what has already been provided in earlier chapters. Besides pointing out ways to
identify problems from hardware clues, you will be introduced to further traceoptions commands and the
Juniper Networks recommended troubleshooting model to use when problems occur.
This chapter will focus mainly on the commands to use for troubleshooting RIP, OSPF, IS-IS, BGP, and
multicast and will also provide some guidance on debugging MPLS and VPNs when troubleshooting a router
or network problem. Because this is an introduction to troubleshooting on the Juniper Networks router, this
chapter will spend more time on the tools than on complex scenarios.

Introduction to Troubleshooting
Troubleshooting can best be described as the process of finding the root cause of a system problem by
methodically working from a broad spectrum of possibilities and narrowing them down to a final solution.
Most network engineers have some personalized method of troubleshooting that they instinctively use
whenever a problem occurs. Some prefer to look at the big picture—how broad is the problem, which remote

www.ebook-converter.com
sites are being affected, and so forth. Some engineers like to keep a knowledge base of information about past
network outages so they can do quick searches for relevant information. Some engineers, of course, use a
combination. Troubleshooting can be described as both an art and a science, using proven scientific methods
in a uniquely personal way to achieve the fastest, best result.
Many engineers prefer to use the bottom-up philosophy based on the OSI network model (refer to Figure 2-1
and its accompanying text for a review of the OSI model). By using Layers 1 through 3—physical, data link,
and network—the engineer can dissect and analyze a problem in a methodical fashion.
Using this model, the engineer would first assess the physical layer of the network, asking the following
questions:
Is everything connected physically?
Are there any utility outages, such as a fiber cut?
Are all indicators normal?
Downloader demo watermarks
Are there any active alarms?
The next step would be to assess the link layer, or Layer 2, indicators for framing errors, transmit and receive
errors, and so on. Finally, Layer 3, the network layer, is where the engineer could gather information
necessary for understanding the routing information that is being passed or received by the router. Using this
593
 15. Troubleshooting Juniper Networks Routers
model, each layer represents another way of analyzing the problem until all methods have been exhausted or
until the problem is found and resolved.
Another troubleshooting method many engineers use involves finding out what, if any, changes were made in
the network since it was last known to be stable. Then, the method is to work backwards from the current
situation until reaching the point at which the network restabilizes. Sometimes a software upgrade is found to
be the cause of the problem. More often, though, a configuration change is the root cause.
Regardless of the method used, the goal is to get the network running smoothly again as quickly as possible.
The JTAC prescribes a tried-and-true troubleshooting method for networks using their routers. The following
sections discuss this troubleshooting methodology, describe trouble indicators, and introduce hardware
troubleshooting commands.

Juniper Networks Troubleshooting Model

Juniper Networks prescribes a particular troubleshooting model, shown in Figure 15-1, for network and router
troubleshooting. This simple method adapts well to any given network situation. The following sections take it
step-by-step.

Figure 15-1. Juniper Networks Troubleshooting Model

www.ebook-converter.com
Identify the Symptoms
What exactly is leading you to believe there is a network or router problem? Are there alarms or LEDs
illuminated on the router? Do you see information on the craft interface that indicates a problem? We will
cover both of these types of indicators in this section. Perhaps it is a network outage that first alerts you to a
problem. It could be a kind of catastrophic event that does not allow for normal trouble indicators to let you
know that a situation is beginning to occur. It is vital that you begin to act as soon as the symptom of a
problem is noted.

Isolate Possible Causes

Now that you have identified some of the symptoms that you are seeing, you need to evaluate the possible
causes. The faster you find the cause of the problem, the faster the network will be running smoothly again.
In Figure 15-2, New York's connection to router 2 via serial 1/0 has gone down. New York sends an SNMP

Downloader demo watermarks

trap to the network management station (NMS), indicating an interface-down condition (the symptom). This
symptom then gives a network manager or engineer cause to believe that the problem is isolated between
New York and router 2 on the serial line. This is where troubleshooting should begin. From experience, you
may know that the problem may be beyond that single connection, but unless there are other indications of a
larger problem, you should start with serial 1/0.

594
 15. Troubleshooting Juniper Networks Routers

Figure 15-2. Isolating the Cause of a Problem

The following are good ways to isolate possible causes:
Taking note of any known activity, such as maintenance, that may be happening in the network
Noting any other information, such as SNMP traps that have been received
Working on the problem in parts; in other words, dividing all the possible symptoms into manageable
parts
If more than one symptom exists, find the common ground and start working there. If router 2 in Figure 15-2
connects all users from New York's Ethernet LAN to the Internet, users on the New York Ethernet LAN will,
of course, be unable to reach the Internet. However, if users on the router 2 side also complain that they
cannot reach the Internet, suddenly the possible causes have changed. Work in the area of the common
ground (router 2) to locate the problem. If problems being experienced by users on the router 2 LAN are

www.ebook-converter.com
unrelated (printer problems, for example), work each problem separately and according to its priority (e.g.,
total network outages before user problems). Draw on your own experience or the experience of the staff to
brainstorm quickly. Ask questions: Have you seen this happen before? If so, under what conditions? No one
can be aware of every occurrence in a large network. It is helpful to leverage everyone's knowledge.

Take Action to Diagnose the Problem Correctly

A good network troubleshooter is very much like a medical doctor in the emergency room of a hospital. You
assess the symptoms, and based on the information you have, you try to come up with the possible causes of
the symptoms. Once you have possible causes, you run tests or otherwise evaluate your possible diagnoses.
For example, if you thought that a possible cause of the network outage in Figure 15-2 is a loose cable, you
would take action by going to New York to evaluate the condition of the cable and the connection. This is a
very simple example, but it gives you an idea of one possibility and one way to troubleshoot it.
It is vital that you log each step or action taken to try to resolve the problem. The worst thing to do is to keep

Downloader demo watermarks

trying different actions, only to end up causing more problems. If you don't have an accurate log of what you
have changed, you will find that it is nearly impossible to retrace your steps, should you need to do so.
Often an inexperienced network troubleshooter cannot tell you how the problem was ultimately resolved,
only that something finally worked. The same can be said, however, of experienced troubleshooters. Often it
is hard to pinpoint the exact cause of a problem, but part of good troubleshooting is getting into the habit of
595
 15. Troubleshooting Juniper Networks Routers
documenting all of the steps, so that you can try to discover the root cause of the original problem. This also
allows you to backtrack, if necessary.

TIP
Use the logging feature on your terminal session to capture every keystroke.

Evaluate the Solution

One way to evaluate this particular solution is to see if the interface returns to an up state on the NMS.
Another way is to perform a show interfaces command on the console for New York to determine the
up or down status of the interface. This is the moment of truth, when you determine whether or not the
problem is completely resolved. If it is not, you must return to an appropriate step in the process.
For instance, if this problem has been resolved, only to be replaced by a new problem, you must return to step
one. If this problem has not been resolved, you may go back to step three and try a new course of action
against another possible cause of the symptoms. Troubleshooting will not be complete until the symptoms
have all been resolved and the network is once again stable.
This method of troubleshooting works well for most network situations. In the remainder of this chapter, we
will discuss how to recognize and use various problem indicators that will help you in your daily network
troubleshooting.

Trouble Indicators

www.ebook-converter.com
In this section we discuss various ways that you can gain clues to network problems from the Juniper
Networks router itself. The router is designed in such a way as to provide real-time, accurate information on
the status of the router's components, the status of network reachability, in some instances, and so on. Juniper
Networks routers provide this information in three ways: system LEDs, the craft interface LCD display (on
some models), and SNMP traps.

LEDs
As discussed in Chapter 3, each Juniper Networks router has a craft interface on the front of the router
chassis. The craft interface contains the system LEDs that indicate the overall status of the router
components. The LEDs shown in Figure 15-3 include the following:
Alarm LEDs
Routing engine LEDs

Downloader demo watermarks

FPC LEDs

596
 15. Troubleshooting Juniper Networks Routers

Figure 15-3. M40 Craft Interface

The alarm panel shown in Figure 15-3 has a red alarm LED and a yellow alarm LED. Red alarms indicate a
condition in which a service interruption could occur, such as total component failures. Yellow alarms are
generally symptomatic of recoverable errors or maintenance alerts. If an alarm is present, the LCD of the
craft interface (on certain models) will display more information about the cause of the system alarm.
Two alarm relay contacts allow external devices to be connected to the craft interface to provide an audible
alarm, for example. An alarm cutoff button will silence the alarm, but will not clear the alarm. Resolving the
issue causing the alarm is the only way to clear alarms.
The routing engine has two LEDs: OK and Fail. In a normal operational state, the OK LED will remain
illuminated, solid and green. If this LED is blinking, it indicates that the routing engine is initializing. If the
Fail LED is illuminated a solid red, it indicates that the routing engine has failed or that the system control
board cannot make contact with the routing engine.

www.ebook-converter.com
Over each number corresponding to an FPC slot there are also OK and Fail LEDs. In normal operational
status, the OK LED will remain illuminated solid and green. If it is blinking, it indicates that the FPC is
initializing. If the Fail LED should illuminate solid and red, it indicates that the router has lost contact with the
FPC. This could indicate a hardware failure or an improperly inserted FPC.
Other LEDs are contained on the components themselves. For instance, the power supplies each have OK
and Fail LEDs. There are instances in which a given router condition, such as increased temperature, can
generate a red alarm and shut down one or both power supplies. Specific information about troubleshooting
each hardware component of the Juniper Networks routers can be found in your hardware installation manual
or online at www.juniper.net.

SNMP Traps
If you desire, SNMP can be enabled on the router. SNMP can then send traps, or alerts, to an NMS when
certain conditions or events occur on the router. The NMS can be configured to alert network-engineering

Downloader demo watermarks

staff when a problem occurs. As discussed in Chapter 6, the following trap types are supported on all Juniper
Networks routers:
cold start/warm start
Link up/link down
597
 15. Troubleshooting Juniper Networks Routers
Authentication failure
jnxPowerSupplyFailure (enterprise)
jnxChassisTraps (enterprise)
jnxFanFailure (enterprise)
jnxOverTemperature (enterprise)
OSPF, MPLS, and BGP traps
If a power supply fails on New York in Figure 15-4, a jnxPowerSupplyFailure trap will be sent from
New York to the NMS. If so configured, the NMS can then send a page (or other type of notification) to a
network engineer immediately.

www.ebook-converter.com
Figure 15-4. SNMP Traps
Using SNMP traps and an NMS should be part of a proactive network-management environment. By
proactive, we mean that it is always better to monitor the health of the routers and the network overall
constantly and consistently than to be surprised by a network outage. If the master power supply in New York
fails, and a redundant power supply is available, the system will continue to operate by failing over to the
backup power supply. If the master power supply fails and no one is alerted, the backup power supply could
fail at some point and leave the router completely down. By using the SNMP traps, the initial problem can be
resolved before a more major problem occurs.

Troubleshooting the Chassis

It is important to be able to check on the health of the overall router and of individual components at will.
This section will provide you with the commands needed to perform this task and will explain the various
qualifiers for each command. This will be a section to earmark as you work with the Juniper Networks routers
until you become proficient enough to know the commands by heart.

Downloader demo watermarks

Environmental Monitoring
This section addresses how to monitor the temperature, alarms, and general environment of the router. It is
important to be able to do these both locally and remotely because there is often no one present at the router.
598
 15. Troubleshooting Juniper Networks Routers
With more and more networks becoming centrally managed, this is a critical component of overall network
health control.

Remote Craft Interface Monitoring on the M40, M40e, and M160 Routers
When it is impossible to be in front of the router you wish to troubleshoot, it is handy to be able to view
virtually the information that is currently being displayed on that router's craft interface. Note that this is only
true for data that is displayed on an M40, M40e, or M160 router equipped with an LCD display on the craft
interface. The following command can be used in JUNOS view privilege mode from a terminal session to
retrieve this data:
lab@Chicago> show chassis craft-interface
This command would offer output similar to that displayed below. Notice that there are no alarms and no
known problems on this M20 router. Because there is no LCD screen on the craft interface of the M20 router,
this command is the only way to discover this information. There are FPCs present in every available slot,
again, with no problems.
Red alarm: LED off, relay off
Yellow alarm: LED off, relay off
Host OK LED: On
Host fail LED: Off
FPCs 0 1 2 3
-------------------
Green * * * *

www.ebook-converter.com
Red . . . .
LCD screen:\LCD Screen:
New York
Up: 10+7:05:32
Temperature OK
Each router type has a different output for this command. Please refer to your JUNOS software configuration
manual or go online to the Juniper Networks Web site at www.juniper.net/techpubs/software.html.

Chassis Alarms
We mentioned chassis alarms earlier in Section 15.3.1. You can also gather this information remotely. A
chassis alarm is defined as an alarm that originates in a router component, such as the power supply. If a
power supply fails, a chassis alarm will be generated. Of course, on the M40, M40e, and M160 models, which

Downloader demo watermarks

are equipped with an LCD display on the craft interface, you can view these alarms if you are standing at the
router. By using the CLI from a local or remote terminal session, you can gather information on active chassis
alarms by using the command:
lab@Chicago> show chassis alarms

599
 15. Troubleshooting Juniper Networks Routers
Tables 15-1 and 15-2 show the output you will see for each type of alarm for models M5, M10, M20, and
M40 and for model M160.
Table 15-1. Chassis Alarm CLI Output for Models M5, M10, M20, and M40

CLI Output Alarm Type

Fan-name stopped spinning Fan failure
Fan-name removed Fan removed
Too few fans installed or working Too many fans inoperable
Temperature-sensor temperature sensor failed Failure of temperature sensor
A temperature sensor exceeds 54°C Temperature too high
Power supply power-supply-name not providing Power-supply failure
power
Power supply power-supply-name 3.3V failed
Power supply power-supply-name 5V failed
Craft interface not responding Craft-interface failure
Too many unrecoverable errors FPC or PIC[*] errors (per slot
information)
Too many recoverable errors
[*] PIC errors are shown in the case of an M5 or M10 router.

Table 15-2. Chassis Alarm CLI Output for Model M160

CLI Output Alarm Type

www.ebook-converter.com
RED ALARM – fan-name Failure
YELLOW ALARM – fan-name Removed
RED ALARM – Too many fans missing or
Fan failure
Fan removed
Fan(s) missing
failing
YELLOW ALARM – Temperature Warm Internal chassis temperature greater than
65°C
RED ALARM – Temperature Hot greater than 75°C Internal chassis temperature
RED ALARM – Temperature sensor failure Internal chassis temperature-sensor failure
YELLOW ALARM – PEM pem-number Removed Power supply removed
RED ALARM – PEM pem-number High Temperature Power supply too hot
RED ALARM – PEM pem-number Output Failure Power-supply output failed
RED ALARM – PEM pem-number Input Failure Power-supply input failed
RED ALARM – SFM sfm-number Failure Switch fabric module failed
RED ALARM – SFM sfm-number Removed Switch fabric module removed
RED ALARM – Host host-number Failure Host module failed

Downloader demo watermarks

RED ALARM – Host host-number Removed
YELLOW ALARM – Craft Failure
Host module removed
Craft-interface failure

Power-Supply Monitoring
600
 15. Troubleshooting Juniper Networks Routers
It is important to check the power supplies on the routers regularly. Although all Juniper Networks M-Series
routers have redundant power supplies, it is critical that you know the status of all power supplies at all times.
Doing so will help to head off any future total failure of the router if one power supply is nonfunctional and
the standby (which has become the master) fails.
There are three ways to monitor the power supply for operational status:
1. Using the show chassis craft-interface command, as described in Section 15.4.1.1
2. Using information gained from SNMP traps on the NMS, as described earlier in Section 15.3.2
3. Using visual inspection, which is our primary focus in this section
Visual inspection can provide the status of the system LEDs, as was discussed earlier in Section 15.3.1, and of
the output on the LCD display of the craft interface on M40, M40e, and M160 models only. If the power
supply is functioning normally, you should see a solid green OK LED illuminated on the power-supply
faceplate, no system alarms, and no trouble indicated in the LCD display of the craft interface. Table 15-3
offers some tips on troubleshooting a power supply that is not functioning normally.

Control Board Monitoring

It is at least as important to monitor the health of the system control boards as it is to monitor any other
system component. These boards are integral to the router's functioning, as you learned in Chapter 3. When
troubleshooting the router, take careful note of the condition of the control boards. Here are a few tips:
If the LEDs are all faintly illuminated, the control board may not be properly seated. Try reseating and

www.ebook-converter.com
securing the board.
If the LED does not indicate normal operation on the control board (more information is provided for
each model in Sections 15.4.3.1 to 15.4.3.4), the board may not be making solid contact with the
backplane. Try tightening the top and bottom screws to see if the problem resolves. If it doesn't, try
reseating and securing the control board.
If the control board doesn't appear to be functioning normally, the craft interface may be malfunctioning
as well. You may receive alarms about fans, impellers, or other system components when in fact these
components are working properly. If you encounter these issues, troubleshoot the control board.
The following sections address how to determine the status of the system control boards for each type of
Juniper Networks router by visually inspecting the LEDs.
Table 15-3. Power-Supply Troubleshooting

Applicable
Downloader demo watermarks
Symptom Possible Cause Possible Solution Router
Models
Status Fail Power supply has failed Try replacing it. If a new power supply works, M20, M40
contact Juniper Networks to return the faulty
LED is red power supply. If the new power supply does not
601
 15. Troubleshooting Juniper Networks Routers
work, contact the JTAC. Applicable
Symptom
Status OK Possible Cause
Power supply has not yet Possible Solution
Router may not be fully initialized. Wait a few Router
M20, M40
initialized minutes. Models
LED is green
and blinking
Power supply Power supply may have failed Check for alarms. Check condition and status of All models
has no because temperature threshold power cables, UPS, and power source.
power; no exceeded or loss of power from
LEDs are lit source
OUTPUT OK Power supply has failed Try replacing it. If a new power supply works, M5, M10,
contact Juniper Networks to return the faulty M160
LED is blue power supply. If the new power supply does not
and blinking work, contact the JTAC.

M5 and M10 Control Board

The M5 and M10 routers do not have a control board.

M20 Control Board

The M20 model has five LED indicators on the front faceplate.
1. The amber OFFLINE LED is illuminated and solid when the SSB is offline.
2. The green ONLINE LED is illuminated and solid when the SSB is online.

www.ebook-converter.com
3.

4.
If the SSB is acting as master, the blue MASTER LED is illuminated and solid.
The left-most green STATUS LED blinks faintly when the SSB is operating and grows brighter when
many exception packets are being processed.
5. The right-most green STATUS LED flashes rapidly when I/O activity is occurring.

M40 Control Board

The M40 model has an SCB on which there are four LED indicators:
1. The green ACTIVE LED flashes rapidly when there is I/O activity on the SCB.
2. The green RUN LED blinks slowly when the SCB processor is handling exception packets. Normally
rather faint, this LED becomes brighter when many exception packets are being processed.

Downloader
3.
demo watermarks
Two amber STAT1 and STAT2 LEDs flash when internal diagnostics are running.

M160 Control Board

The M160 model has two types of control module: the SFM and PCG. The health and operational status of
602
 15. Troubleshooting Juniper Networks Routers
both components can be discovered through a visual inspection of the LEDs on the components. The SFM
has two LEDs on the front faceplate: green for OK and amber for FAIL. Similar to LEDs on other component
LEDs, solid green indicates an operational status, blinking green indicates that the component is still
initializing, and solid amber indicates a component failure. If an SFM fails, try swapping it out with a spare
SFM. If the new SFM works, contact Juniper Networks for replacement of the faulty module.
The PCG is located in the rear of the chassis beside the routing engine and has three LED indicators:
1. The blue MASTER LED is illuminated and solid when the PCG is acting as master.
2. The green OK LED is illuminated and solid when the PCG is in a normal operational state and blinks
when the PCG is initializing.
3. The amber FAIL LED is illuminated and solid when the PCG has failed to operate normally.

Monitoring Interfaces
Now that you have a little information about troubleshooting the chassis and the major hardware components
of the router, we want to spend some time talking about how to monitor the proper operational status of the
interfaces. There are two categories of interface monitoring and troubleshooting commands: static and
real-time.
Note that it is outside the scope of this chapter to list all possible interface-monitoring commands along with
their qualifiers, but you can find this information in your JUNOS operational command reference guide or
online in the Technical Documentation section of the Juniper Networks Web site at www.juniper.net.

www.ebook-converter.com
Static Monitoring
Static monitoring of the router interfaces refers to commands that are one-time, or snapshot, commands used
to capture a moment in time in the life of the router. Using a static command, you can see—at that one
second—what has transpired since the last clearing of the counters. You can also check the status of an
interface. You must remember, however, that once the response to the command appears on your screen, it is
immediately outdated. That does not mean that it is useless information. It simply means that you got a status
update.
The static monitoring commands for use on the router interfaces all start with the root command in operation
mode: show interfaces. You can optionally add the interface name, as well as the qualifiers detail or
extensive. The detail option provides detailed information on each interface. The extensive option
provides even more detail about the interfaces. The output for a simple show interfaces interface-
name command on an ATM interface is shown below:
lab@Chicago> show interfaces at-2/1/1
Downloader demo watermarks
Physical Interface at-2/1/1, Enabled, Physical link is UP
Interface index: 30 SNMP ifIndex: 13
Link-level type: ATM-PVC, MTU: 4482, Clocking: Internal, SONET mode,
Speed: OC3, Loopback: None, Payload scrambler: Enabled
Device Flags : Present Running
603
 15. Troubleshooting Juniper Networks Routers
Link Flags : None
Input Rate : 0 bps (0 pps)
Output Rate : 0 bps (0 pps)
SONET alarms : None
SONET defects : None
Logical interface at-2/1/1.0 (Index 11) (SNMP ifIndex 56)
Flags: Point-to-Point Encapsulation: ATM-SNAP
Input packets: 0
Output packets: 0
VCI: 0.100
Flags: Active
Total down time: 0 sec, Last down: Never
In this example, you can see that there are no active SONET alarms or defects present. You can also gather
some information about the type of encapsulation in use and the I/O rate of the interface. The output of this
command will look a little different for each interface type. Refer to your JUNOS operational command
reference for details.
Short summary information, with much less detail, can be obtained by adding the terse option to the
command as shown below. Notice that you only see the status, protocol type, and the local and remote
addresses. If you need to quickly check the status of an interface, this is a good command to use.
lab@Chicago> show interfaces terse
Interface Admin Link Proto Local Remote
at-2/1/1 UP UP

www.ebook-converter.com
at-2/1/1.0 UP UP inet 10.1.1.1 10.1.1.2
at-2/1/1.100 DOWN DOWN
at-2/1/1.3748 DOWN DOWN
To obtain only descriptions of the interfaces, use the descriptions qualifier as shown below. As in the
above example, you will see the interface name, followed by its status, and a short description, as manually
entered. This can be helpful if you name your interfaces by location or another unique identifier. For instance,
in this example, the descriptions seem to identify a location and the PVC in use:
lab@Chicago> show interfaces descriptions
Interface Admin Link Description
at-2/1/1.0 UP UP Nassau-0
at-2/1/1.100 UP UP Nassau-100
at-2/1/1.3748 DOWN DOWN Nassau-3748
Using the show interfaces routing command gives you the routing information for each specific
interface. You can also include the optional qualifiers interface-name, brief (default), detail, and

Downloader demo watermarks

summary. Using the interface name, you will view only the information for that particular interface. Using
brief, you will get the default display information—a brief view of the basic information for all interfaces
(unless you combine this with the interface name).
lab@Chicago> show interfaces routing brief
Interface State Addresses
604
 15. Troubleshooting Juniper Networks Routers
at-2/1/1.0 Up ISO enabled
at-2/1/1.100 Up INET 10.1.1.1
at-2/1/1.3748 Down ISO enabled
Using detail, you get a more detailed view of each (or a single) interface. The summary option will give
you a short summary of the interfaces on the router and their statuses.
lab@Chicago> show interfaces routing summary
5 physical interfaces (4 up)
3 INET protocol addresses (3 up)
5 ISO protocol addresses (4 up)
0 MPLS protocol addresses (0 up)
0 CCC protocol addresses (0 up)

Interface Index Metric Trans. Status

at-2/1/1.0 6 0 0 Broadcast PointToPoint Multicast
at-2/1/1.100 5 0 5 Broadcast PointToPoint Multicast
at-2/1/1.3748 4 0 1 Broadcast PointToPoint Multicast
lo0.0 3 0 0 Broadcast PointToPoint Multicast
fxp1.0 2 0 0 Broadcast Multicast
fxp0.0 1 0 1 Broadcast Multicast
To gather media-specific information about the interfaces, use the media qualifier. In this example, we are
looking at a Fast Ethernet interface. Notice the specific information generated by this command, such as
autonegotiation, MAC statistics, and flow control.
lab@Chicago> show interfaces media

www.ebook-converter.com
Physical interface: fe-1/0/0, Enabled, Physical link is UP
Interface index: 37, SNMP ifIndex: 14
Link-level type: Ethernet, MTU: 1514, Source filtering: Disabled
Speed: 100 mbps, Loopback: Disabled, Flow control: Enabled
Device flags: Present Running
Interface flags: SNMP-Traps
Link flags: None
Current address: 00:90:69:0e:0c:69, Hardware address: 00:90:69:0e:0c:69
Input rate: 0 bps (0 pps), Output rate: 0 bps (0 pps)
Active alarms: None
Active defects: None
MAC statistics:
Input octets: 0, Input packets: 0, Output octets: 0, Output packets: 0
Filter statistics:
Filtered packets: 0, Padded packets: 0, Output packet errors: 0
Autonegotiation information:

Downloader demo watermarks

Negotiated status: Complete, Link partner status: OK
Link partner: Full-duplex, Flow control: None
For statistical information, the command is show interfaces statistics. The default qualifier is
detail. You may also specify a particular interface, as we have in the example below, which shows I/O
rates in bits per second, as well as clocking information, and so on:
605
 15. Troubleshooting Juniper Networks Routers
lab@Chicago> show interfaces t1-3/1/0 statistics
Physical interface: t1-3/1/0, Enabled, Physical link is Up
Interface index: 129, SNMP ifIndex: 1300
Link-level type: Cisco-HDLC, MTU: 4474, Clocking: Line
Speed: T1, Loopback: Local, FCS: 16, Framing: ESF
Device flags : Present Running
Interface flags : Point-to-Point
Link flags : Keepalives
Statistics last cleared: Never
Input rate : 0 bps (0 pps), Output rate: 0 bps (0 pps)
Input errors : 0, Output errors: 0
Active alarms : None
Active defects : None
Logical interface t1-3/1/0.0 (Index 4) (SNMP ifIndex 1380)
Flags: Point-to-Point, Encapsulation: Cisco-HDLC
Protocol inet, MTU: 4470
Addresses, Flags: Is-Preferred, Is-Primary
Destination: 10.0.3.2, Local: 10.0.3.1
Static monitoring using the show interfaces command provides you with a way to get a snapshot of a
moment in time of a particular interface. By using different parameters with this command, you can gather a
great deal of useful troubleshooting information, such as clocking, encapsulation, interface status, and alarms.
The next section takes a look at how you can gather ongoing information about an interface with real-time
monitoring.

Real-time Monitoring
www.ebook-converter.com
Suppose you don't want just a status update. What if you need a running output that is continuously updated?
This is when you need real-time monitoring. There are two primary commands that can be used to monitor
router interfaces in real-time for immediate feedback: monitor interface and monitor traffic.
The monitor interface command shows statistics for a physical interface updated once per second.
You will also see the difference between the statistics at the beginning of the monitoring (or since you last
cleared the statistics) and the present update. This is quite helpful when troubleshooting an ongoing problem.
Another feature of this command is its ability to discover and display common interface problems like alarms
and framing errors. The usage for this command is as follows:
lab@Chicago> monitor interface <interface-name | traffic>
If you do not specify an interface name, you will get output for all interfaces. Adding the traffic qualifier
will provide you with traffic data (input and output packets per second, for example) for one or all interfaces.

Downloader demo watermarks

Table 15-4 lists the key sequences for use with the monitor interface command. These key sequences
are not case sensitive.
Table 15-4. Control Keys for the monitor interface Command

606
 15. Troubleshooting Juniper Networks Routers
Keystroke Action
C This key will clear the delta values of the statistics since the last time you cleared them or since
the monitor interface command was executed. It will not clear the cumulative statistics on
the interface.
F Use this key to “freeze” the display.
T Use this key to “thaw” a display that was frozen.
N The monitor interface command displays interfaces sequentially, in the same order in
which they would be displayed by the show interfaces terse command. You can use this
key to jump to the next interface in the sequence.
I This key allows you to specify a given interface to display. Using this key will cause the monitor to
prompt you for the name of an interface.
Q Use this key to quit monitoring.
The monitor traffic command can be compared to the UNIX command tcpdump, which also can be
used to display the traffic flowing through an interface. Using the monitor traffic command with
Boolean expressions, you can print and examine packet headers on traffic on an interface. The monitor
traffic command should be used with caution. If you do not use specific parameters to filter the output, it
could impact your router's performance, throughput, or both. If you have any questions about the use of this
command, contact JTAC before using it. In addition, you can refer to the Juniper Networks Web site or your
copy of the JUNOS documentation for software command reference documents for the version of JUNOS you
are using. Search for the section on the traffic match condition. The optional qualifiers that can be used
with the monitor traffic command are listed in Table 15-5, along with a short description of each.
Table 15-5. Optional Qualifiers for the monitor traffic Command

www.ebook-converter.com
Qualifier Description
absolute- Prints absolute TCP sequence numbers
sequence
brief The default; displays only the minimal protocol-related information, therefore keeping the tax
on the router to a minimum
count Allows you to specify a finite number of headers to display, which helps keep the capture short
and less space-intensive; ceases output once this limit is reached—the range is 1 to 1,000,000
detail Shows some detail—though not as much as extensive—such as TTL, from the TCP packet.
extensive Shows even more detail from TCP packets
NOTE

For detail and extensive to work with some protocols, you must increase the
size option to permit higher output for each packet matched by the monitor
traffic command.
interfaceSpecifies the interface on which to print the packet data; if no interface is specified, the

Downloader demo watermarks

layer2-
headers
command prints data for the traffic arriving on the lowest numbered interface
Displays the link-level header for each line
NOTE

The extensive option will do this for you, as well.

matching Used when you wish to use regular expression matching to filter the output 607
 15. Troubleshooting Juniper Networks Routers
matching
Qualifier Used when you wish to use regular expression matching to filter the output
Description
no-domain- Suppresses the domain portion of hostnames printed
names
no-resolve Suppresses printing of symbolic addresses
ano- Suppresses the printing of the timestamps
timestamp
print-ascii Enables the printing of each packet in ASCII
print-hex Enables the printing of each packet in hexadecimal format, except for the link-level header
size Allows the output to receive a certain number of bytes per packet (The default value is 68 bytes
and can be increased, if necessary. If the sizing is not adequate, data will be truncated.)

Troubleshooting Routing Protocols with the traceoptions

Command
Up until now, we have focused mainly on hardware troubleshooting—chassis, interface, and component
problems. You also need to be able to troubleshoot the routing protocols running on your router effectively.
We will focus on three ways to do this—through show commands, through debug commands, and through
the routing table.
You may be familiar with using show commands with other vendor products. You probably also have a good
idea of how to troubleshoot routing problems through the use of the routing table (described in Chapter 14).
You may not, however, be familiar with the Juniper Networks routers' traceoptions command set, which
can be used to monitor protocol traffic.
The traceoptions command set is similar to Cisco Systems' debug command set. Both command toolkits

www.ebook-converter.com
can be used to perform diagnostics related to protocol status and network activity. Both can be CPU-intensive
on the router itself because of the power and memory it takes to examine and capture the volume of traffic
and tasks flowing through and taking place on today's high-speed routers. Enabling any kind of
traceoptions command on a Juniper Networks router can be detrimental to performance and should be
used with caution.
While the Cisco Systems' debugging commands are complex enough to warrant a separate command
reference, the traceoptions commands are simple yet powerful. Knowing how and when to use
traceoptions commands is a key skill in good troubleshooting. Each protocol section in this chapter will
discuss how to use them; knowing when to use traceoptions commands is partially based on experience.
If you find yourself in a troubleshooting scenario that requires some advanced techniques, try the
traceoptions commands. Using the traceoptions command set is a good way to become familiar
with how valuable it can be.

Note

Downloader demo watermarks

A good way to use traceoptions is to set the commonly used traceoptions commands and
parameters ahead of time in the configuration and leave them disabled. When you need to run
tracing, you simply have to go into your configuration and enable the trace commands needed. This
is a great timesaver.

608
 15. Troubleshooting Juniper Networks Routers
Viewing traceoptions Output
This section will discuss protocol-specific information and how to get it later. Here it specifies what you need
to know to retrieve the output gathered by the traceoptions command. There are two ways to see this
information: by monitoring it in real-time or by viewing it from a saved file with the show log command.
The monitor command allows you to display the end of either a system log file or a trace file, along with
additional entries as they are being added. It can be a very valuable tool during active troubleshooting
because you can watch the output and receive immediate feedback on what is happening in the router or
network. The syntax of the monitor command is as follows:
lab@Chicago> monitor (start | stop) list
The list qualifier prompts the system to provide you with a list of log files from which to select. This list
will include not only traceoptions output files, but syslog-produced files as well. To stop the output,
enter <ESC>-Q.
The show log command can be used to list log files on the system, view the contents of the log files, or list
user logins. The syntax of this command is as follows:
lab@Chicago> show log [user username] [filename]
The user qualifier is optional, as is username. If you enter user and do not enter a username, you will
see logged information about all users with recent logins. The filename is also optional. If you identify a
filename, you will view the contents of that file. The use of no optional qualifiers simply provides a list of all
available log files that you can view. Here is an example of the show log output:

www.ebook-converter.com
lab@Chicago> show log user
lab ttyd0 Thu Apr 4 13:17 still logged in
ted ttyd0 Tue Apr 2 11:24 – 13:13 (2+01:49)
In this example, we see that on Chicago, two users are logged on. We see our session, user lab, and another
session, user ted. User ted has been online for 2 days, 1 hour, and 49 minutes. Notice that, because we are
still logged in, we do not see an accounting of the amount of time we have been logged in.

Enabling Global traceoptions

For capturing traffic and activity on the Juniper Networks router, you can enable some global parameters for
traceoptions, before editing specific parameters for protocols or interfaces. You would do this in the
[edit routing-options] configuration mode as shown below:
[edit routing-options]
Downloader demo watermarks
lab@Chicago# edit traceoptions file | filename <replace> <size size> <files
number> <no-stamp> <(world-readable | no-world-readable)> flag flag <flag-
modifier> <disable>
Notice that you can specify a particular filename for the trace, such as /var/log/trace-all. Enabling
609
 15. Troubleshooting Juniper Networks Routers
the options at this level is optional, but can be beneficial if you want all routing options tracing to go into a
single output file. Table 15-6 describes the parameters you can use with the traceoptions command. This
table applies to these parameters regardless of the configuration hierarchy level you are at.
Table 15-6. Configuration Parameters for the traceoptions Command

Parameter Description
files Allows you to specify a number of log files that can be created. In other words, if you set files
to 5, the system will create /var/log/rip-trace.0, then /var/log/rip-trace.1, and
so on, through .5. When the maximum number of files is reached, the system will overwrite the
first file in the series. The default for this parameter is to create one file only. The maximum
number that can be set is 1,000 files.
flag Allows you to flag the particular options you wish to trace. The possible choices are listed in
Table 15-7.
no-stampAn optional parameter that can be used when you do not want to have a timestamp on your
traces.
no- This allows only the user who created the file to access its contents.
world-
readable
replace This saves space by replacing a file of the same name that already exists. If you do not specify the
replace option, the new tracing will be appended to the file that already exists.
size This limits the amount of space consumed by the file. You can specify a range from 10KB
through the maximum file size supported by your hard disk. To specify KB, use k, as in 400k to
represent 400KB. Use m for MB and g for GB. The default size is 1MB. Once a file reaches its
limit, it will begin overwriting from the beginning of the trace.

www.ebook-converter.com
Table 15-7 lists the required and optional flag options you want to trace.
Table 15-7. Required and Optional flag parameters for the traceoptions Command

Options Description
all Required; enables all possible tracing operations
detail Optional; results in more detailed trace information
disable Optional; turns off the tracing operation preceding the disable flag
general Required; captures all normal operations and routing table changes (the equivalent of the
normal and route trace flags together)
normal Required; traces all normal operations
policy Required; captures all instances of policy operations
receive Optional; logs only packets being received
receive- Optional; logs details of packets being received
detail

Downloader demo watermarks

route
send
send-
Required; traces routing table changes
Optional; logs only packets being sent
Optional; logs details of packets being sent
detail
state Required; captures state transitions
task Required; captures interface transactions
610
task Required; captures interface transactions 15. Troubleshooting Juniper Networks Routers
Options
timer Description
Required; traces timer usage
An example of the syntax for a traceoptions command at this level is as follows:
lab@Chicago# edit traceoptions file | trace-all replace size 1m
files 4 world-readable flag receive
In this example, we have enabled traceoptions at the [edit routing-options] hierarchy. We are
directing all output to a file called trace-all, which will replace any file already in existence with that
name. We have set the maximum file size at 1MB, limiting the total number of file versions with this name to
4. We are allowing all users to read this file and are looking at received traffic only.
Now that you have traceoptions enabled globally, let's look at the ways you can use traceoptions
with each routing protocol.

Using traceoptions with RIP

Probably the least complex routing protocol you will run in the core is RIP, usually version 2, although
Juniper Networks routers also support version 1. Section 15.6.2 described how to set up traceoptions
globally. If you prefer, you may specify certain parameters that you want to see on your RIP protocol traffic
at the [edit protocols rip] hierarchy. Bear in mind that the more specific you get, the easier it will
be to use the file for troubleshooting purposes. More specific logging also takes up less space on the router's
hard disk and is less CPU-intensive. Here is how you would enable traceoptions for RIP protocol traffic
in configuration mode:

www.ebook-converter.com
lab@Chicago# edit protocols rip
[edit protocols rip]
lab@Chicago# set traceoptions file filename <replace> <size size> <files
number> <no-stamp>
lab@Chicago# set traceoptions flag flag <flag-modifier> <disable>
The RIP protocol-specific flags can help narrow down the output that you receive. Table 15-8 lists each flag
and provides a short description.
The following example shows how to enable the trigger, request, and update flags for RIP:
[edit protocols rip]
lab@Chicago# set traceoptions file | rip-trace size 400k files 4 no-stamp
world-readable
lab@Chicago# set flag request update trigger
Table 15-8. RIP traceoptions Flags

Downloader demo watermarks

Flag
auth
Description
Captures RIP authentication packets
disable Turns off the tracing operation of the flag preceding it
error Captures RIP error packets
expirationTraces RIP route expiration transaction processing
611
 15. Troubleshooting Juniper Networks Routers
expirationTraces RIP route expiration transaction processing
Flag
holddown Description
Captures RIP hold-down processing
packets Traces any packets that are RIP-related
request Captures only RIP informational packets

trigger Captures any RIP triggered updates

update Captures all RIP update packets
The following example shows how to disable the trigger flag for the above RIP traceoptions setting:
[edit protocols rip]
lab@Chicago# set traceoptions
lab@Chicago# set flag trigger disable

Using traceoptions with OSPF

Most large networks are running OSPF in the core. Using the traceoptions command, you can specify
certain types of OSPF packets you want to capture. To do this, follow the instructions below to set up specific
OSPF parameters within the [edit protocols ospf] hierarchy:
lab@Chicago# edit protocols ospf
[edit protocols ospf]
lab@Chicago# set traceoptions file | filename <replace> <size size> <files
number> <no-stamp>
lab@Chicago# set traceoptions flag flag <flag-modifier> <disable>

www.ebook-converter.com
Flags allow you to set up some OSPF-specific information that you may want to see. Table 15-9 shows flags
that are available for OSPF traceoptions. Alternately, you can enter a partial command for a list of the
possible completions you can use as follows:
lab@chicago# set flag <enter> Will give you a list of the available flags.
Table 15-9. OSPF traceoptions Flags

Flags Description
database- Captures all database description packets used when synchronizing the OSPF
description topological database
lsa-ack Captures the link-state update acknowledgment packets used when synchronizing the
OSPF topological database
lsa-request Captures the link-state request packets sent from OSPF routers
lsa-update Shows all link-state update packets on the network
error Captures only OSPF error packets

Downloader demo watermarks

flooding
event
hello
Traces link-state packets that are flooded to all routers
Traces OSPF state transitions
Captures the OSPF hello packets sent between neighbors
packets Traces all OSPF packets on the network
spf Shows all SPF calculations on the router
packet-dump Opens and dumps the contents of selected packet types
612
packet-dump 15. Troubleshooting
Opens and dumps the contents of selected packet types Juniper Networks Routers
Flags Description
The following example shows how to run traceoptions in OSPF to capture all OSPF state transitions, as
well as all hello packets. The output is being logged to a file called ospf-trace.
[edit protocols ospf]
lab@Chicago# set traceoptions file | ospf-trace
lab@Chicago# set traceoptions flag event hello
Although some OSPF show commands were discussed in Chapter 8, we wanted to include all of the possible
commands here, so that you can use them in your troubleshooting process. To gather information about OSPF
databases, processes and routes, you can use show commands. These commands can be used to get a current
status of specific OSPF components at a given moment in time. Table 15-10 provides a brief description of
each command.
Table 15-10. OSPF show Commands

Command Description
show ospf Provides information about LSA packets from the link-state database. Options include brief,
database detail, and extensive. You may also choose to show data about only a single named
OSPF instance or run the output through an LSA filter.
show ospf Displays the status of all interfaces that are running OSPF. Options include brief, detail,
interface and extensive. You may also view the interfaces connected to a particular OSPF instance
and may specify an interface or an interface name using a wildcard.
show ospf Provides information on the shortest-path calculations that have been logged. You can view
log this for one or all routing-instances. The output fields include when the calculation
occurred, what type of calculation was run, and how much time has elapsed since the

www.ebook-converter.com
calculation was last run.
show ospf Displays neighboring OSPF routers. Options include brief, detail, and extensive. You
neighbor may also view the neighbors per routing-instance or you may specify one neighbor in
particular that you wish to view.
show ospf Displays the OSPF routing table entries. Options include detail, abr, asbr, extern,
route instance instance-name, inter, or intra providing detailed output, routes to area
border routers or AS border routers, external routes, routes for a particular routing-
instance, inter-area routes, and intra-area routes, respectively.
show ospf Displays the protocol statistics for OSPF, such as packets in, packets out, and so on.
statistics
In this example, we are running a show ospf neighbor command on Chicago. We can see three
neighbors, the interface through which we know each neighbor, the state, and the neighbor's router ID. We
also see the value of the dead timer and that router's priority value. For more information on the meaning of
these OSPF values, please refer to Chapter 8.

Downloader demo watermarks

[edit protocols]
lab@Chicago# run show ospf neighbor
Address Interface State ID Pri Dead
10.10.0.130 ae1.0 Full 10.10.1.1 128 38
10.10.0.138 at-1/2/0.235 Full 10.10.0.2 128 36
10.10.0.134 at-1/2/1.167 Full 10.10.0.3 128 38
613
 15. Troubleshooting Juniper Networks Routers
Note that you can use the clear ospf command with the database, neighbors, or statistics
qualifiers to clear out some or all of the data in the OSPF databases and routing table. This comes in very
handy when troubleshooting, especially when you make a change and need to see the results right away.

Using traceoptions with IS-IS

You can also use the traceoptions command to monitor the behavior of the IS-IS routing protocol. The
following example uses the [edit protocols isis] hierarchy:
lab@Chicago# edit protocols isis
[edit protocols isis]
lab@Chicago# set traceoptions file | filename <replace> <size size> <files
number> <no-stamp>
lab@Chicago# set traceoptions flag flag <flag-modifier> <disable>
Flags allow you to set up some IS-IS-specific information that you may want to see. Table 15-11 lists flags
that are available for traceoptions. To see a list of all possible flags available from the CLI, hit enter after
typing set flag to bring up a list of possible completions.
In the following example, you can see that we are going to trace all IS-IS protocol traffic that is being sent.
We are logging all traceoptions output to a file called isis-trace.
[edit protocols isis]
lab@Chicago# set traceoptions file | isis-trace
lab@Chicago# set traceoptions flag all send

www.ebook-converter.com
In addition to using the traceoptions command for monitoring IS-IS, you can also use the show isis
command. While this command can be used alone, you can also add six different qualifiers to gather even
more specific information. Table 15-12 lists these qualifiers.
Table 15-11. IS-IS traceoptions Flags

Flags Description
all Traces everything
csn Traces complete sequence number PDUs (CSNP)
error Shows errored packets
general Traces all general IS-IS events
hello Shows all hello packets transmitted
lsp Traces all LSP packets
lsp-generationTraces all LSP generation packets
normal Trace all normal IS-IS events
packets Captures all IS-IS-related packets
Downloader demo watermarks
policy
psn
Traces all policy processing
Traces all PSNPs
route Captures all IS-IS routing-update packets
spf Captures all SPF calculations performed
state Captures just state transitions
614
state Captures just state transitions 15. Troubleshooting Juniper Networks Routers
Flags
task Description
Captures routing-protocol task processing
timer Traces routing-protocol timer processing
Table 15-12. show isis Command Qualifiers

Qualifier Description
adjacency Use with system-ID or as brief or detail output to view all neighboring routers
database Use with system-ID or as brief, detail, or extensive output to show the entries in
the IS-IS link-state database
interface Use with either brief (default) or detail to show the status of all interfaces running IS-IS
routes Shows the summary of all IS-IS routes in the routing table
spf Shows information about SPF calculations that have run
statisticsShows statistics related to IS-IS, such as packets in, and so on
In this example, we use the show isis route command to view the IS-IS routing table. Notice that it
gives us the network prefix, the version of JUNOS running on the router, metrics for the route, and the
associated interface through which we connect to this network.
[edit protocols]
lab@Chicago# run show isis route
IS-IS routing table Current version: L1: 38 L2: 55
Prefix L Version Metric Type Interface Via
10.10.0.2/32 2 55 10 int at-1/2/0.235 Montreal
10.10.0.3/32 2 55 10 int at-1/2/1.167 SanJose
10.10.0.4/32 2 55 20 int at-1/2/0.235 Montreal

www.ebook-converter.com
10.10.0.160/30
10.10.0.164/30
2
2
55
55
at-1/2/1.167 SanJose
20 int at-1/2/0.235 Montreal
20 int at-1/2/1.167 SanJose
at-1/2/0.235 Montreal
10.10.0.192/30 2 55 20 int at-1/2/1.167 SanJose
10.10.0.224/30 2 55 30 int at-1/2/0.235 Montreal
at-1/2/1.167 SanJose
10.10.0.228/30 2 55 30 int at-1/2/0.235 Montreal
at-1/2/1.167 SanJose
10.10.2.132/30 2 55 20 int at-1/2/0.235 Montreal
17.185.36.224/30 2 55 20 int at-1/2/1.167 SanJose
192.168.18.4/30 2 55 20 int at-1/2/1.167 SanJose
Note that you can use the clear isis command and the same qualifiers to clear out some or all of the data
in the IS-IS databases and routing table. This comes in very handy when troubleshooting, especially when you
make a change and want to watch the counters and so on.

Downloader demo watermarks

Using traceoptions with BGP
To enable the monitoring of the BGP on the router, set up BGP-specific flags within the [edit
protocols bgp] hierarchy as follows:
615
 15. Troubleshooting Juniper Networks Routers
lab@Chicago# edit protocols bgp
[edit protocols bgp]
lab@Chicago# set traceoptions file | filename <replace> <size size> <files
number> <no-stamp>
lab@Chicago# set traceoptions flag flag <flag-modifier> <disable>
Notice that you may specify an output file of a name of your choosing. You may also instruct the router to
replace the current output file, use a specified maximum size for the file, use a certain number of files before
overwriting the first one, and indicate that no timestamp should be used. Flags allow you to set up some BGP-
specific information that you may want to see. Table 15-13 lists flags that are available for traceoptions.
To see a list of all possible flags available from the CLI, hit enter after typing set flag to bring up a list of
possible completions.
Table 15-13. BGP traceoptions Flags

Flags Description
aspath Traces AS path regular expression operations
damping Traces route damping operations
keepaliveCaptures the BGP keepalive messages
open Shows the open packets sent between BGP peers when establishing a session
packets Captures all BGP packets of any type
update Shows all BGP update packets sent during routing updates on BGP ASs
In the following example, you can see that we are going to trace all BGP protocol traffic that is being
received. We are logging all traceoptions output to a file called bgp-trace.

www.ebook-converter.com
[edit protocols bgp]
lab@Chicago# set traceoptions file | bgp-trace
lab@Chicago# set traceoptions flag all receive
In addition to using the traceoptions command for monitoring BGP, you can use the show bgp
command. While this command can be used alone, you can also add four different qualifiers to gather even
more specific information. Table 15-14 lists these qualifiers.
Table 15-14. show bgp Command Qualifiers

Qualifiers Description
group Displays information about configured BGP groups
neighbor Displays information about all BGP peers; you can further specify a particular neighbor by
address
next- Displays the entries from the internal BGP synchronization database; you can further specify a
hop- next-hop router by address or specify that you would like to see the output in brief or detail

Downloader demo watermarks

database mode
summary Shows general BGP information
Notice that in the following example, we provide you with a show bgp summary from Chicago. It gives us
a look at the number of groups and peers. It also provides us with a little information about the peering
sessions between routers, such as up time and state.
616
 15. Troubleshooting Juniper Networks Routers
[edit]
lab@Chicago# run show bgp summary
Groups: 3 Peers: 4 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 0 0 0 0 0 0
inet.2 0 0 0 0 0 0
bgp.l3vpn.0 18 18 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn
State|#Active/Received/Damped...
10.10.0.2 7500 522 527 0 2 4:20:26 Establ
bgp.l3vpn.0: 0/0/0
10.10.0.3 7500 530 533 0 2 4:23:18 Establ
bgp.l3vpn.0: 9/9/0
10.10.0.4 7500 583 584 0 0 4:50:47 Establ
inet.0: 0/0/0
10.10.0.130 3000 583 592 0 0 4:49:09 Establ
inet.0: 0/0/0
inet.2: 0/0/0
bgp.l3vpn.0: 9/9/0
Note that you can use the clear bgp command and the same qualifiers to clear out some or all of the data
or counters in the BGP routing table and processes. This comes in very handy when troubleshooting,
especially when you make a change and want to watch the counters and so on.

Troubleshooting Commands for MPLS and VPNs

www.ebook-converter.com
Chapter 12 on MPLS has a lot of background and configuration information for this popular new style of
routing over Layer 2 virtual private networks (L2VPNs) using MPLS to carry the connection. Juniper
Networks routers support traceoptions functionality for advanced MPLS and VPN troubleshooting. As
with other protocols, you must first enable traceoptions globally before you set up the tracing of MPLS
tunnels. Once global traceoptions are enabled, you can enable certain traceoptions parameters for
MPLS as shown below:
lab@Chicago# edit protocols mpls
[edit protocols mpls]
lab@Chicago# set traceoptions file | filename <replace> <size size> <files
number> <no-stamp>
lab@Chicago# set flag flag <flag-modifier> <disable>
Again, by setting certain flags, you can selectively enable different elements to trace within the MPLS
protocol. Table 15-15 lists the flags that are available for traceoptions. To see a list of all possible flags
available from the CLI, hit enter after typing set flag to bring up a list of possible completions.

Downloader demo watermarks

Table 15-15. MPLS traceoptions Flags

Flags Description
connection Captures all activity within CCCs.
connection-detailProvides a higher level of detail than the connection flag
617
 15.theTroubleshooting
connection-detailProvides a higher level of detail than Juniper Networks Routers
connection flag
Flags Description
cspf Captures calculations performed for CSPF
cspf-link Captures all links visited during CSPF calculations
cspf-node Captures all nodes visited during CSPF calculations
error Traces only MPLS error packets
state Shows all LSP state transitions
You can also trace information about traffic on an L2VPN by using traceoptions. To do so, use the
following syntax:
lab@Chicago# edit routing-instances routing-instance-name protocols l2vpn
[edit routing-instances routing-instance-name protocols l2vpn]
lab@Chicago# set traceoptions file | filename <replace> <size size> <files
number> <no-stamp>
lab@Chicago# set traceoptions flag flag <flag-modifier> <disable>
Flags that you can use for tracing L2VPN information are shown in Table 15-16.
Table 15-16. L2VPN traceoptions Flags

Flags Description
All Captures everything
ConnectionsCaptures just events and state changes in the L2VPN
Error Displays only error packets
Nlri Captures L2VPN send/receive advertisements from BGP
Route Displays only the exchange of routing information

www.ebook-converter.com
Topology Captures information related to the change of topology due to reconfiguration or
advertisements
While traceoptions are important, the additional load they put on the router can sometimes be more than
you are willing to use to troubleshoot a problem. This is where show and clear commands come in handy.
They are simple tools that can be used to monitor counters, link information, and LSP information in an
MPLS or L2VPN environment. Some of the commands you can use when you want to keep it simple are
shown in Table 15-17. If you want to see a list quickly of all possible commands to use with show or clear,
you can press enter after typing in show l2vpn or clear l2vpn. The system will then display a list of
possible completions.
Table 15-17. MPLS and L2VPN show and clear Commands

Commands Descriptions
show/clear Shows (or alternately clears) the active, configured LSPs of which this router is a
mpls lsp participant; useful when troubleshooting basic communication problems

Downloader demo watermarks

Can be used to find information about configured CCCs on the router; a powerful command
show
connections with a long list of optional parameters
show mpls Displays the administrative groups configured on this router for MPLS
admin-
groups
show mpls Provides a display of statistical information related to CSPF calculations
618
 15. Troubleshooting Juniper Networks Routers
cspf
Commands Descriptions
show mpls Displays information about the interfaces on which MPLS is configured; a very similar
interface command to that on other protocols
show mpls Useful if you are using named paths in conjunction with your MPLS configuration; you can
path display one or all MPLS paths by choosing whether or not to specify a path name
show ted Displays a lot of information in brief, detail, or extensive mode about everything
database known in the TED—nodes, links, protocols, administrative groups, and so on
show ted Shows in brief or detail mode the information for links contained in the TED
link
show ted Gives you some information about which protocols, such as IS-IS, are contributing to the
protocol TED; protocols will be ranked according to the credibility of their routing information
The following is an example of the show mpls lsp command in use. It shows both ingress (incoming) and
egress (outgoing) LSPs, their states, path information, and names. It also shows for the egress LSP, the
LabelIn/LabelOut information and summary information at the end.
[edit]
instruct@Denver# run show mpls lsp
Ingress LSP: 2 sessions
To From State Rt ActivePath P LSPname
10.10.0.2 10.10.0.1 Up 0 * vpn-dev-mont
10.10.0.3 10.10.0.1 Up 0 * uunet-denv-sj
Total 2 displayed, Up 2, Down 0
Egress LSP: 2 sessions
To From State Rt Style Labelin Labelout LSPname

www.ebook-converter.com
10.10.0.1 10.10.0.2 Up 0 1 FF 3 - vpn-mont-denv
10.10.0.1 192.168.161.19 Up 0 1 FF 3 - uunet-sj-denv
Total 2 displayed, Up 2, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
The next example shows the show mpls interface command. With this command, we can get a quick
summary of all of our MPLS-enabled interfaces, along with their states and the administrative groups to
which they belong.
[edit]
lab@Chicago# run show mpls interface
Interface State Administrative groups
at-1/2/0.235 Up <none>
at-1/2/1.167 Up <none>
fe-1/0/1.0 Up <none>
Downloader demo watermarks
fe-1/0/0.0
ae1.0
Up
Up
<none>
<none>

Troubleshooting Commands for Multicast Protocols

619
 15. Troubleshooting Juniper Networks Routers
There are several different multicast protocols supported by the Juniper Networks routers. In this section, we
will discuss commands you can use to troubleshoot each of them. As with other protocols, the
traceoptions commands are invaluable in advanced troubleshooting. You can enable specific multicast
protocol traceoptions within the [edit routing-options] hierarchy, then set up protocol-specific
flags within the [edit protocols multicast protocol] hierarchy. Each of these is discussed
below.

DVMRP
This section addresses the commands used to turn on the traceoptions capabilities in DVMRP. With an
output filename of your choosing, enable traceoptions by using the commands shown below. Then, set
up specific output parameters with DVMRP-specific flags.
lab@Chicago# edit protocols dvmrp
[edit protocols dvmrp]
lab@Chicago# set traceoptions file | filename <replace> <size size> <files
number> <no-stamp>
lab@Chicago# set traceoptions flag flag <flag-modifier> <disable>
Flags allow you to gather output for some DVMRP-specific information that you may want to see. Table 15-
18 lists flags that are available for DVMRP traceoptions.
Table 15-18. DVMRP traceoptions Flags

Flags Descriptions
all Traces everything

www.ebook-converter.com
general Logs general DVMRP events
graft Logs DVMRP graft messages
neighborCaptures the neighbor probe messages
normal Traces normal events (The default is to capture abnormal or error events only.)
packets Captures all DVMRP-related packets
poison Shows only poison-route-reverse packets
policy Logs any policy processing activity in the router
probe Traces all probe packets versus the probe packets from neighbors only
prune Traces all prune messages
report Captures all DVMRP route report packets
route Traces all routing updates for DVMRP
state Displays any DVMRP state transitions
task Displays protocol task processing
timer Shows routing-protocol timer processing

Downloader demo watermarks

The following example sets up a trace for DVMRP prune messages with detailed logging. All
traceoptions output is being sent to a file called dvmrp-trace.
[edit protocols dvmrp]
lab@Chicago# set traceoptions file | dvmrp-trace
lab@Chicago# set traceoptions flag prune detail
620
 15. Troubleshooting Juniper Networks Routers
Additionally, you can use certain show commands in conjunction with DVMRP for real-time troubleshooting
without taking up valuable disk space. Table 15-19 lists these commands.
Table 15-19. DVMRP show Commands

Commands Descriptions
show dvmrp Shows any entries in the graft retransmission queue in either brief or detail mode
grafts (Normally, this queue should be empty.)
show dvmrp Displays some information about DVMRP-enabled neighbors
neighbors
show dvmrp Displays the table of known IP prefixes in this protocol instance
prefix
show dvmrp Shows all active and transmitted DVMRP prunes
prunes
show dvmrp Shows interfaces on which DVMRP is enabled
interfaces
show multicast Displays all multicast tunnels in use for either PIM or DVMRP
tunnels
show multicast Shows a list of the 10 most active DVMRP or PIM groups
usage

MSDP
As with DVMRP, you can enable tracing for MSDP as follows:
lab@Chicago# edit protocols msdp

www.ebook-converter.com
[edit protocols msdp]
lab@Chicago# set traceoptions file | filename <replace> <size size> <files
number> <no-stamp>
lab@Chicago# set traceoptions flag flag <flag-modifier> <disable>
In addition to enabling the tracing for MSDP globally, you can specify tracing for all peers in a group using
the [edit protocols msdp group group-name] hierarchy, or for an individual peer using the
[edit protocols msdp group group-name peer-address] hierarchy. Setting
traceoptions for a group will override anything you set for a peer within that group. You can also add
MSDP-specific flags that allow you to gather configurable output from the protocol. The flags used for MSDP
are listed in Table 15-20.
The following example shows how to trace all MSDP sa packets. This example logs all traceoptions
output to a file called msdp-trace.
[edit protocols msdp]

Downloader demo watermarks

lab@Chicago# set traceoptions file | msdp-trace
lab@Chicago# set traceoptions flag sa
Table 15-20. MSDP traceoptions Flags

Flags
keepalive Descriptions
Traces just the MSDP keepalive packets between peers 621
 15. Troubleshooting Juniper Networks Routers
keepalive Traces just the MSDP keepalive packets between peers
Flags
packets Descriptions
Traces all MSDP packets
route Traces only MSDP routing updates
sa Traces source-active packets
sa-request Traces source-active request packets only
sa-responseTraces responses to source-active requests
As you have seen with other protocols, show commands can be helpful in determining statistical information,
current status, and cache entries. Table 15-21 lists the commands that are useful in troubleshooting MSDP:
Table 15-21. MSDP Troubleshooting Commands

Commands Descriptions
clear msdp Clears entries from the MSDP source-active cache
cache
clear msdp Clears current MSDP statistics
statistics
show msdp Gathers general information about MSDP; options include brief and detail (You can also
execute this command for a single peer by specifying the qualifier peer followed by the peer
address. Additional options include source-active <group | originator |
source> to get specific information about entries in the sa queue.)
show msdp Provides information about all MSDP peers, or about a single peer, if you use the qualifier
statistics peer followed by the peer address
test msdp Allows you to find downstream MSDP peers; options include the dependent-peer prefix
to show downstream dependent MSDP peers or the rpf-peer originator to find the
RPF peer for the identified originator

www.ebook-converter.com
SAP/SDP
If your network is running videoteleconferencing and other multimedia conferences and presentations, you
may use SAP/SDP in your network. There are no traceoptions capabilities for SAP/SDP, but you can
take a look at the addresses to which the router is listening for multicast announcements by using the
following command:
User1@NewYork> show sap listen [brief | detail]
The output of this command will show you both the address and the port to which the router is listening.

IGMP
IGMP is one of the oldest multicast protocols. It uses join and leave messages to indicate members entering or
leaving the multicast group. In that respect, it is like a subscription-based service, sending information only to
Downloader demo watermarks
the members wishing to receive it. Tracing IGMP is similar to that in other protocols.
lab@Chicago# edit protocols igmp
[edit protocols igmp]
lab@Chicago# set traceoptions file | filename <replace> <size size> <files
622
 15. Troubleshooting Juniper Networks Routers
number> <no-stamp>
lab@Chicago# set traceoptions flag flag <flag-modifier> <disable>
IGMP-specific flags for the traceoptions command are provided in Table 15-22. To see a complete list of
flags available, press enter after typing set flag, and you will see a list of possible completions for the
command.
Table 15-22. IGMP traceoptions Flags

Flags Descriptions
leave Traces IGMP group leave messages for IGMPv2 only
mtrace Captures only mtrace packets
packetsCaptures all IGMP packets
query Show all membership queries to any group type
report Captures group membership report messages
In the following example, you can see that we are going to trace all IGMP leave packets being sent. All
traceoptions output is logged to a file called igmp-trace.
[edit protocols igmp]
lab@Chicago# set traceoptions file | igmp-trace
lab@Chicago# set traceoptions flag leave send
Table 15-23 lists other helpful commands you can use to troubleshoot IGMP problems.
Table 15-23. IGMP Troubleshooting Commands

www.ebook-converter.com
Commands Description
show igmp group Displays information about all IGMP groups; you can get this output in brief or
detail mode and specify a particular group name if you like
show/clear igmp Allows you to show or clear information on one or all interfaces that are running
interface IGMP
show/clear igmp Allows you to view or clear statistics for one or all IGMP-enabled interfaces
statistics

PIM
PIM is a popular multicast routing protocol because it is not dependent on a particular unicast protocol, such
as IP. Whether you are running PIM-SM or PIM-DM, you can use the following commands to enable tracing:
lab@Chicago# edit protocols pim
[edit protocols pim]
Downloader demo watermarks
lab@Chicago# set traceoptions file | filename <replace> <size size> <files
number> <no-stamp>
lab@Chicago# set traceoptions flag flag <flag-modifier> <disable>
Flags that can be used when tracing PIM output are shown in Table 15-24, along with a brief description of

623
 15. Troubleshooting Juniper Networks Routers
each.
Table 15-24. PIM traceoptions Flags

Flags Description
assert Captures assert messages used to discover which of the parallel routers is responsible for
forwarding packets on a network
bootstrapTraces Bootstrap packets sent out by the PIM (PIM-SM only) domain's designated Bootstrap
router
cache Captures packets in the PIM routing cache
graft Traces both graft and graft-acknowledgment packets
hello Captures all hello packets sent by the PIM routers to each other join Traces all join
messages sent to multicast groups
packets Traces all PIM packets on the network
prune Captures prune messages only
register Traces both register messages sent to the RP when a multicast source first starts
communicating with a group and register-stop messages
rp Captures candidate rp announcements
Here is an example of how to setup traceoptions for capturing all join packets received by a PIM-
enabled router. All traceoptions output is logged to a file called pim-trace.
[edit protocols pim]
lab@Chicago# set traceoptions file | pim-trace
lab@Chicago# set traceoptions flag join receive

www.ebook-converter.com
Table 15-25 lists additional commands that can be helpful in narrowing down a problem within PIM.
Table 15-25. PIM Troubleshooting Commands
Commands Descriptions
show pim Shows the status and detail of the Bootstrap router in a PIM-SM domain; no optional
bootstrap qualifiers
show/clear Displays or clears information about PIM groups; options include brief, detail, and
pim join extensive, and you can also specify a range of groups to display by prefix/prefix-
length
show pim Displays the status of interfaces on which PIM is configured; no optional qualifiers
interfaces
show pim Displays brief or detail information about the status of PIM neighboring routers
neighbors
show pim rps Displays the status of PIM RPs; options include brief, detail, or extensive output,
and output can be narrowed down to a single group-address
Downloader demo watermarks
show pim
source
Shows the status of the PIM RPF state; options include brief, detail, or extensive
output, and output can also be narrowed down to a single range by using source-prefix
show pim Displays (*,*.RP) RP join information; no optional parameters
wildcard
show/clear Allows you to display or clear the statistics for all interfaces running PIM; a single interface
624
show/clear Allows you to display or clear the statistics15.
for Troubleshooting Juniper
all interfaces running PIM;Networks Routers
a single interface
Commands
pim Descriptions
can be specified by using interface interface-name
statistics
show Shows you a list of the 10 most active DVMRP or PIM groups
multicast
usage
show Displays all multicast tunnels in use for either PIM or DVMRP
multicast
tunnels

Working with JTAC

There will come a time when you will need to log a call with JTAC to receive additional help with return
merchandise authorization (RMA), advanced troubleshooting, or bug fixes. You can execute the following
command in advance to provide more information to the JTAC engineers. Notice that the <save
filename> component of the command is optional. Because the output can be lengthy, we suggest that you
direct the output to a file as shown below:
lab@Chicago> request support information <save filename>
This command runs a script that executes all of the following individual commands:
show version
show chassis firmware
show chassis hardware

www.ebook-converter.com
show chassis environment
show interfaces extensive
show configuration
The show interfaces extensive command will be executed for every configured interface. The
show configuration command will not include sensitive data, such as passwords. By having this
information readily available when logging a case, you may either paste it into the support request (if logging
it via the Web) or e-mail it to the engineers (if logging the request via telephone), if they require the data.

Chapter Summary
This chapter covered material related to the simple and more advanced troubleshooting of Juniper Networks
routers. Specifically, it introduced you to overall network troubleshooting and the Juniper Networks–
prescribed model of troubleshooting, recommended for all of their customers.
Downloader demo watermarks
You have learned how to gather information by visually inspecting the router and its components, such as the
power supplies and control boards. You found that you can do this either locally or remotely through the CLI.
In this way, you can tell how the router is functioning from a chassis and interface perspective. The system
LEDs and craft interface give you much of the information you need to make a rapid assessment.
625
 15. Troubleshooting Juniper Networks Routers
Besides the chassis information, you can use static monitoring for snapshots of a moment in the life of your
Juniper Networks router. This information can provide important baseline information or clues to a problem
that is developing.
Real-time information can be gleaned from traps sent to your NMS or from traceoptions commands. The
traceoptions command set, as you have discovered, is a powerful debugging tool that, when used
judiciously, can help you find the root of a complex problem. Enabling traceoptions from the [edit
routing-options] hierarchy gives you a global perspective on the network. The chapter then showed
you how to enable tracing flags to get more specific information per protocol.
By running traceoptions on different routing protocols, you can gain valuable insight into peering
operations, exchange of periodic information, routing up dates, and so on. You will find this helpful in both
preparing for the JNCIS exam and daily troubleshooting of simple and advanced network problems.
Remember to use the JTAC when advanced problems frustrate normal troubleshooting, or refer to the Juniper
Networks Web site or router technical manuals for further assistance.

Bibliography

www.ebook-converter.com

Downloader demo watermarks

626
[ch15bib01] Ericsson IP Infrastructure, AXI-520/580 course material.
[ch15bib02] www.juniper.net

www.ebook-converter.com

Downloader demo watermarks

627
 Acronyms
Chapter . Acronyms
2.5G next-generation
3G third-generation
ABR area border router
ACL access control list
ADM add-drop multiplexer
AN acknowledgment number
API application programming interface
APS automatic protection switching
ARP Address Resolution Protocol
AS autonomous system
ASBR autonomous system border router
ASIC application-specific integrated circuit
ASN abstract syntax notation
AT address table
ATM Asynchronous Transfer Mode
BDR backup Designated Router
BERT bit error rate test

www.ebook-converter.com
BGP Border Gateway Protocol
BGP4 Border Gateway Protocol version 4
BSR Bootstrap router
CBGP confederation BGP
CBR constant bit rate
CBT core-based tree
CCC circuit cross connect
CCSI Cisco Certified System Instructor
CE customer edge
Chk checksum
CIDR classless interdomain routing
CIP connector interface panel
CLI command-line interface
Downloader demo watermarks
CLNP
CLP
Connectionless Network Protocol
cell loss priority
CMTS Cable Modem Termination System
Co control
628
Co control Acronyms
CoS class of service
cps cell per second
CPU central processing unit
CRC cyclical redundancy check
CRU central routing unit
CSNP complete SNP
CSPF Constrained Shortest Path First
DA destination IP address
DBM distributed buffer manager
DHCP Dynamic Host Configuration Protocol
DIET designing, implementing, executing, and testing
DiffServ Differentiated Services
DLCI data link connection identifier
DNS domain name server
DO data offset
DoS denial of service
DP destination port
DR Designated Router
DS Differentiated Services; digital stream

www.ebook-converter.com
DS-0 digital stream-0
DSCP differential service code point
DSP domain specific Part
EBGP External Border Gateway Protocol
ECMP equal cost multipath
EGP Exterior Gateway Protocol
ERO explicit route object
FCS frame check sequence
FEB forwarding engine board
FEM forwarding engine module
FPC flexible PIC concentrator
FSM finite state machine
FTP File Transfer Protocol
Downloader demo watermarks
GFC
GGSN
generic flow control
gateway GPRS support node
GigE gigabit Ethernet
GRE generic route encapsulation
629
 Acronyms
HC header checksum
HP-NNM Hewlett-Packard's Network Node Manager
HTTP Hyper Text Transfer Protocol
IBGP Internal BGP
ICMP Internet Control Message Protocol
ID identification
IETF Internet Engineering Task Force
IGMP Internet Group Management Protocol
IGP Interior Gateway Protocol
IHL IP header length
ILMI integrated local management interface
IntServ Integrated Services
IP Internet Protocol
IP/ATM Internet Protocol over Asynchronous Transfer Mode
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
IR internal router
IRR Internet routing registry
IS-IS Intermediate System-to-Intermediate System

www.ebook-converter.com
ISO International Standards Organization
ISP Internet service provider
J-cell 64-byte block
JNAI Juniper Networks Authorized Instructor
JNCIE Juniper Networks Certified Internet Expert
JNCIS Juniper Networks Certified Internet Specialist
JNNTC Juniper Networks Technical Certification Program
JTAC Juniper Technical Assistance Center
JUNOS Juniper Network Operating System
L1/2 level 1/2
L2VPN Layer 2 virtual private network
LAN local area network
LDP Label Distribution Protocol
Downloader demo watermarks
Len
LH
length
long haul
LMI local management interface
LSA link-state advertisement
630
LSA link-state advertisement Acronyms
LSDB link state database
LSP label switched path; link state PDU
LSR label switching router
M management bit
MAN metropolitan area network
MBGP Multicast BGP
mbone multicast backbone
MCS miscellaneous control Subsystem
MD5 message digest
MED MULTI_EXIT_DISC
MIB management information base
MOSPF Multicast Open Shortest Path First
MPLS multiprotocol label switching
MSDP Multicast Routing Protocol Protocol
MTBF mean time between failure
MTU maximum transmission unit
NBMA nonbroadcast multiaccess
NET network entity title
NIC network information center; network interface card

www.ebook-converter.com
NLPID
NLRI
Network Layer Protocol ID
network layer reachability information
NLSP NetWare Link State Routing Protocol
NMS network management station or system
NNI network node interface
NSAP network service access point
NSSA not-so-stubby area
NTP Network Time Protocol
OC optical carrier
OID object identifier
Opt option
OSI open systems interconnection
Downloader demo watermarks
OSPF
P
Open Shortest Path First
protocol; provider
PCG PFE clock generator
PCR
PDU peak celldata
protocol rate unit
631
PDU protocol data unit Acronyms

PE provider edge
PFE packet forwarding engine
PFM packet forwarding module
PHP penultimate hop Popping
PIC physical interface card
PIM-DM Protocol Independent Multicast—Dense Mode
PIM-SM Protocol Independent Multicast-Sparse Mode
POS Packet over SONET
PPP Point-to-Point Protocol
PSNP partial SNP
PT payload type
p-t-p point-to-point
PVC permanent virtual circuit
QoS quality of service
RADB route arbiter database
RD route distinguisher
RE routing engine
RED random early detection
Res reserved
www.ebook-converter.com
RFC
RIB
request for comment
routing information base
RID router identification
RIP Routing Information Protocol
RMA return merchandise authorization
RP rendezvous point
RPM reverse path multicasting
RPSL routing policy specification language
RSVP Resource Reservation Protocol
RSVP-TE RSVP with traffic engineering extensions
RTM routing table manager
SA source active; source IP address
Downloader demo watermarks
SAP
SAP/SDP
Session Announcement Protocol
Session Announcement Protocol/Session Description Protocol
SAR segmentation and reassembly
SCP Secure Copy Protocol
SCR sustained cell rate 632
 Acronyms
SCR sustained cell rate
SDH Synchronous Digital Hierarchy
SDP Session Description Protocol
SE system engineer
SFD start of frame delimiter
SFM switching and forwarding module
SGMP Standard Gateway Monitoring Protocol
SLIP Serial Line Internet Protocol
SN sequence number
SNA systems network architecture
SNMP Simple Network Management Protocol
SNP sequence number packet
SONET Synchronous Optical Network
SP source port
SPE synchronous payload envelope
SPF shortest path first
SSB system and switch Board
SSH secure shell
STM synchronous transport module

www.ebook-converter.com
STS
SVC
synchronous transport signal
switched virtual circuit
TACACS+Terminal Access Controller Access Control System +
TCP Transmission Control Protocol
TCP/IP Transmission Control Protocol over Internet Protocol
TDM time division multiplexing
TED traffic-engineering database
TL total Length
TNP Trivial Network Protocol
ToS type of service
TTL time to live
UBR unspecified bit rate
Downloader demo watermarks
UDP
UHP
User Datagram Protocol
ultimate hop popping
UID user identifier
UNI
UP user-network
urgent pointerinterface
633
UP urgent pointer Acronyms
UTP unshielded twisted pair
v version
VBR variable bit rate
VCI virtual channel identifier
VLSM variable length subnet masks or masking
VPI virtual path identifier
VPN virtual private network
VRF virtual routing and forwarding
VRRP Virtual Router Redundancy Protocol
VSA vendor specific attribute
VT virtual tributarie
WAN wide-area network
WRED Weighted RED
XML extensible markup language
XNS Xerox Network Systems

www.ebook-converter.com

Downloader demo watermarks

634
 About the Authors
Chapter . About the Authors
Thomas M. Thomas II is a self-proclaimed nerd and country boy who holds his Cisco
Certified Internetworking Expert (CCIE #9360) as well as his Certified Cisco Systems
Instructor (CCSI #21702), CCNP, CCDA, and CCNA certifications and claims he never
works because he loves what he does. Tom is the founder of NetCerts.com (now
CCPrep.com) and the International Network Resource Group (www.inrgi.net), where he
is on the board of directors, providing vision and focus. He was previously an instructor
for Chesapeake Computer Consultants and a course developer for Cisco Systems. He is
the author of OSPF Network Design Solutions (Cisco Press, 1999) and a variety of other
networking books designed to help his fellow engineers. Tom is currently working for
Hired Guns. Tom lives in Raleigh, NC, with his family, and although he doesn't live in the
country, he observes that you can see it from his house.
Doris Pavlichek is a CCNA and CCDA and works as a project manager for Ericsson IP
Infrastructure in charge of managing product life-cycles and releases. She was formerly
the director of customer service, where she led a team of senior engineers performing
Tier 3 support of Ericsson routers (including OEM products from Juniper). She has
fifteen years of networking experience, including design, implementation, and advanced
troubleshooting in both government and business environments. She has also spent time
teaching, performing site surveys, and specializing in network management and security.
www.ebook-converter.com
She is the author of Cisco Internetwork Design (McGraw-Hill, 2001).
Lawrence H. Dwyer III holds CCNA and MCSE certifications. Lawrence is currently
the director of the Technical Support Lab for Ericsson IP Infrastructure. Prior to joining
Ericsson, Lawrence worked as a senior consulting engineer for Integrated
Communications Solutions, a Cisco Silver Channel Partner, and has written white papers
for CCPrep.com. In addition, Lawrence has worked as a government contract project
officer for the U.S. Army Medical's Telemedicine Advanced Technology Research
Center (TATRC) and served eight years in the U.S. Navy providing tactical voice and
data communications.
Rajah Chowbay is a Juniper Networks Certified Internet Specialist (JNCIS), Cisco
Certified Internetwork Expert (CCIE # 3445), Certified Ericsson Datacom Technician
Downloader demo watermarks
(E1), Certified Ericsson Instructor, and Certified Cisco Systems Instructor (CCSI). Rajah
is currently working as Senior Technical Trainer/Technical Support Engineer with
Ericsson IP Infrastructure. Before joining Ericsson, Rajah taught certified Cisco courses
for Mentor Technologies and Automation Research Systems. Rajah has written white
635
 About the Authors
papers for CCPrep.com and performed technical peer reviews for Coriolis Group.
Wayne W. Downing III is a Senior Consulting Engineer with Ericsson IP Infrastructure,
consulting on ISP solutions, including IP and MPLS based multi vendor core and mobile
infrastructures. Wayne has held technical leadership positions with several service
providers (MCI, Sprint, and AT&T), where he was responsible for network architecture,
routing, and other business-related functions. Wayne also worked for Network
Integration Services, Inc. (NISI), providing consulting services to Fortune 100 clients with
a focus on design and integration strategies. He is a Juniper Networks Certified Internet
Specialist (JNCIS) and also holds a variety of Cisco certifications. During his military
service, Wayne was awarded the Presidential Service Badge while working as a
Presidential Senior Radio Technician with the White House Communications Agency
providing communications solutions for the President of the United States, during the
G.H.W. Bush and W.J. Clinton administrations. Wayne is also the founder of
NET3SOLUTIONS, an information technology consulting firm. NET3SOLUTIONS
assists businesses in utilizing and deploying Information Technology solutions.
James Sonderegger holds a B.S. in political science and is a Juniper Networks Certified
Internet Specialist (JNCIS) as well as a Juniper Networks Authorized Trainer (JNAT). He
also holds Cisco and Ericsson proprietary certifications. James currently works as a
course developer and senior instructor for Ericsson Training. Before joining Ericsson,

www.ebook-converter.com
James worked as a technical analyst for Automated Data Processing, and as an
instructor's assistant for the Cisco Networking Academy courses at Kennesaw State
University. Prior to that he spent several years touring the East Coast with the now
defunct punk-rock band Hey, Zeus and the Tall Boys.

Downloader demo watermarks

636
 A. Practice JNCIS Questions
Appendix A. Practice JNCIS Questions
This appendix is a great section and we are pleased to make it available. At the time of
this writing, Boson Software (www.boson.com) is the only company selling any self-test
software relating to the JNCIS. The questions and answers here are presented through the
courtesy of Boson Software.
Currently Boson sells a practice test that was written by two CCNPs who work as part of
JTAC. This sample test currently has 212 practice questions available for you and is
identified as test number 70042.
The Boson testing software is extremely useful and has some advanced customizable
features (see Figure A-1). The characteristics of the Boson Software worth mentioning
include the following:
By default, the question bank is segmented into smaller quizzes, thereby allowing you
to pick the quiz you would like to practice on. You can adjust the number of
questions to be asked.
It allows you to focus practice on specific technical categories where you may need
more practice.

www.ebook-converter.com
It tracks your historical scores to see how your learning has progressed. You can
even have the software ask you only the questions you have gotten wrong.
It randomizes the order of the questions and answers so you cannot memorize them
very easily. This is an excellent option, and we highly recommend using it.
It provides the ability to turn questions into flash cards, allowing you to use the
questions as a learning aid.
Its simulator mode allows you to take a timed practice quiz with the characteristics of
the actual exam.

Downloader demo watermarks

637
 A. Practice JNCIS Questions

Figure A-1. Boson Test Configuration Screen

1: Which is the shortest AS-Path?

1. (64515 65001 64972 65101) 172
2. 178 182 172
www.ebook-converter.com
(65101 64972) 190 172
3.

4. (64972) 178 192 172

A1: A. (64515 65001 64972 65101) 172

ASs included within parentheses are interior to a confederation. These ASs's

numbers are not included in the total AS-Path length because they are affiliated
with a confederation. Therefore, the (64515 65001 64972 65101) 172 path
is the shortest because only one AS is included in its length.
2: In IS-IS, what is used to limit excessive packet transmissions in a fully meshed
NBMA network?
Downloader demo watermarks
IS-IS elects a DIS in such a situation
1.

2. IS-IS elects a DR in such a situation

638
 A. Practice JNCIS Questions
3. IS-IS cannot be used over ATM circuits
4. IS-IS uses mesh groups to limit excessive packets

A2: D. IS-IS uses mesh groups to limit excessive packets

IS-IS can only be used on broadcast or point-to-point links. Broadcast links use a
DIS to limit excessive packet transmissions, but there is no DIS elected for point-
to-point links. To keep excessive packets from being transmitted over point-to-
point links, mesh groups were created. When an IS-IS router receives an LSP from
a member of its mesh group, it does not flood this LSP to other mesh-group
members. This limits duplicate packets from being transmitted over an NBMA
cloud.
3: What is the maximum metric value that an IS-IS route can have if wide metrics are
not used?
1. 255
2. 1023
3. 63

www.ebook-converter.com
65534
4.

A3: C. 63
The maximum metric value allowed for IS-IS routes is 63 unless wide metrics are
specified to be used exclusively via the wide-metrics-only command.
4: Assuming that all inet.3 routes have not been merged into inet.0, which
command, used under the [edit protocols mpls label-switch path
NAME] hierarchy will result in a route that can be pinged?
1. Install 10.0.0.0/8
2. Install 10.0.0.0/8 active
Downloader demo
Install 10.0.0.0/8 rib
3. inet.0 watermarks
4. Install 10.0.0.0/8 enable ping

A4: B. Install 10.0.0.0/8 active 639

 A. Practice JNCIS Questions
A4: B. Install 10.0.0.0/8 active

The install command causes a route, in addition to the standard host route to
the egress of the LSP, to be installed into the inet.3 routing table. Routes in
inet.3 are not installed into the forwarding table; therefore, it is not possible to
ping these routes from another router, and they are only available for use by BGP
as next-hops. By using the active keyword, you specify that a particular route
should be installed into inet.0, which will result in a route that can be used for
BGP next-hops and can also be pinged by other routers.
5: When configuring setup and hold priority for an LSP, what is true?
1. Setup and hold priority are independent and can be configured as you like.
2. Setup priority must be higher than hold priority.
3. Hold priority must be higher than or equal to setup priority.
4. They must be the same.

A5: C. Hold priority must be higher than or equal to setup priority.

When there is a lack of bandwidth, an LSP with a higher priority can cause a
www.ebook-converter.com
lower-priority LSP to be torn down to free up the necessary bandwidth. The setup
priority is used to determine whether a given LSP should cause a less-important
LSP to be torn down. The hold priority is used to determine if a given LSP will be
allowed to remain up after it has been established. To prevent flapping of LSPs, it
is required that the hold priority be equal to or greater than the setup priority.
6: Which of the following OSPF routes will be chosen to reach a given destination?
1. Intra-area route with a cost of 15
2. Inter-area route with a cost of 10
3. External type 1 route with a cost of 25

Downloader demo watermarks

4. External type 2 route with a cost of 5

A6: A. Intra-area route with a cost of 15

OSPF intra-area routes are always preferred over inter-area and external routes, no
640
 A. Practice JNCIS Questions
matter what the cost is.
7: What is true about LSA type 4s?
1. They describe the traffic-engineering information needed for CSPF.
2. They are flooded throughout the entire OSPF domain just like LSA type 5s.
3. They are only flooded throughout one area.
4. They are allowed in every area type, including stub areas.

A7: C. They are only flooded throughout one area.

LSA type 4s are ASBR summary LSAs. They are used to indicate a path to an
ASBR much like an LSA type 3. Summary LSA indicates a path to an inter-area
network. They have nothing to do with traffic engineering and are only flooded
throughout a single area. They are originated by ABRs and are not allowed in stub
areas, just like LSA type 5s. See RFC 2328 Section 12.4.3.
8: When a BGP route has the no_export community added to it, what effect does
that have on the route?

www.ebook-converter.com
1. A router will never advertise a no_export route to any of its neighbors.
A router will never allow a no_export route to be exported into an IGP.
2.

3. A router will never allow a no_export route to leave the sub_as within a
confederation.
4. A router will never allow a no_export route to leave the AS (or
confederation, if confederations are used).

A8: D. A router will never allow a no_export route to leave the AS (or
confederation, if confederations are used).
There are a number of well-defined communities that can be used to indicate with
Downloader demo watermarks
whom a route should be distributed. The no_export community indicates that a
route should not leave the confederation (or AS if confederations aren't used).
9: MSDP is used to link the domains of which protocol?

641
 A. Practice JNCIS Questions
1. MOSPF
2. IS-IS
3. DVMRP
PIM
4.
A9: D. PIM

MSDP is used to interconnect PIM routing domains. Two MSDP routers establish
adjacencies similar to EBGP. Multicast source information is then transferred back
and forth between the two PIM domains.
10: What is true about the BGP path attribute Local Preference?
1. The lower the number, the more preferred the route.
2. It can be used to affect the routing of peer-ASs.
3. It can only be used to affect your local-AS.
4. It can only be used to affect the routing of the local router.

www.ebook-converter.com
A10: C. It can only be used to affect your local-AS.

Local Preference is a BGP attribute that is shared within an AS. The higher
the local preference, the more preferred the route is. It does not leave the AS, but it
is shared between all members of the AS.
11: While monitoring an RSVP session, you notice that one of your routers is
periodically sending a PATH message. What is the likely cause of this?
1. Your link is flapping.
2. Your bandwidth allocation is changing too frequently.
3. This is standard RSVP behavior.
Downloader demo watermarks
Your LSP never initialized correctly.
4.

A11: C.This is standard RSVP behavior.

642
 A. Practice JNCIS Questions
In a correctly functioning network, RSVP will send PATH messages every 30
seconds (the default refresh time) to maintain the state of the LSP. Without these
periodic PATH messages, the LSP would age out and be removed by all the routers
in the path.
12: What command must be used to cause an ABR of a stub area to inject a default
LSA type 3 route into an area?
1. No command is necessary; this is done by default
2. Stub default-metric
3. Stub generate-default
4. Stub summary

A12: B. Stub default-metric

Juniper Networks stub ABRs do not automatically inject a default LSA type 3 into
the area. To generate this LSA you must use the default-metric command
and specify a metric to be used for the LSA.
13: If you have a route to the same destination from the following four sources, which
will be picked?
www.ebook-converter.com
OSPF External route
1.

2. IS-IS Level 1 External route

3. BGP
4. RIP

A13: D. RIP
Of the IGPs, RIP has the worst preference value (100); however, external routes
from OSPF and IS-IS level 1 have worse preference than RIP does (150 and 160
Downloader demo watermarks
respectively). BGP has the worst of all: 170. The lower the preference, the more
preferred the protocol.
14: What is the default encapsulation on a SONET link?

1. PPP
643
 A. Practice JNCIS Questions
2. Cisco-HDLC
3. Frame-Relay
4. Juniper-HDLC

A14: A. PPP
The default encapsulation on a SONET link is PPP. There is no Juniper-HDLC.
15: Two Juniper Networks routers are advertising their presence via IRDP (ICMP
router discovery protocol). Router A is using the default preference and router B is
using a preference of 50. Which router will become the default router for the
network?
1. Router A
2. Router B
3. Neither
4. They will load balance
www.ebook-converter.com
A15: B. Router B
The default preference value for IRDP is 0 and the default router is determined by
which router has the greatest preference. In this case router A has a preference of 0
(the default preference) and router B has a preference of 50, so router B will
become the default router.
16: You have an AS-Path of 65425 65126 4285 196. In your external peering
session, you have remove-private configured. Which AS-Path will be
advertised to the external peer?
1. 65425 65126 4285 196

Downloader
2.

4285 196
3.
demo watermarks
65126 4285 196

4. 65425 65126
644
 A. Practice JNCIS Questions
A16: C. 4285 196

The remove-private command will strip the private ASNs off of the AS-Path
before transmitting the path information to the external neighbor.
17: What is the default half-life value for route dampening?

1. 10
2. 15
3. 20
4. 40
5. 50

A17: B. 15
Route dampening is used to limit the disturbance caused by flapping routes. Every
time a route flaps, it will be penalized by having its figure of metric added to. Once
its figure of metric reaches a certain level, the route will be suppressed. The route

www.ebook-converter.com
will not be eligible for use until the figure of metric has been lowered below the
reuse level. After every half-life elapses, the figure of metric will be cut in half. The
default is 15 minutes.
18: What is the result of the following configuration statement: set system ntp
boot-server 192.168.20.1
1. Tells the system to advertise the address 192.168.20.1 as a boot server
2. Tells the system to synchronize its time with the NTP time server at address
192.168.20.1 when the router boots
3. Tells the system to only allow host 192.168.20.1 to connect to the boot
server

Downloader
Provides NTP relay processesdemo
4.
192.168.20.1
and directs all NTPwatermarks
messages to

A18: B. Tells the system to synchronize its time with the time server at address
645
A18: B. Tells the system to synchronize its time with the time A.
server at JNCIS
Practice address
Questions
192.168.20.1 when the router boots
It sets a designated server to provide a time to the router when it boots. At boot,
the router issues an ntpdate request, which polls the network server to determine
19: the localNetworks
Juniper date and routers
time. consist of two main units. They are

1. Packet forwarding engine (PFE)

2. Routing engine
3. Packet forwarding module (PFM)
4. Central routing unit (CRU)
5. Forwarding engine module (FEM)
6. Routing table manager (RTM)

A19: A. Packet forwarding engine (PFE)

B. Routing engine

www.ebook-converter.com
Juniper Networks routers consist of two main units that are interconnected. These
units are the PFE, which forwards traffic through the interfaces and does route
lookups, and the routing engine, which handles router management and protocol
management and contains the storage devices (Flash drive and hard drive).
20: The inet.3 routing table is used for

1. Default unicast routing table

2. Unicast routing table for a particular routing-instance
3. Multicast forwarding cache
4. Unicast routes used for multicast reverse-path-forwarding RPF lookup

Downloader demo watermarks

MPLS routing table for path information
5.

6. MPLS routing table for label-switched path (LSP) next-hops

A20: E. MPLS routing table for path information 646

 A. Practice JNCIS Questions
A20: E. MPLS routing table for path information
The inet.3 routing table contains MPLS LSP information.
21: Which of the following will match this routing-policy statement: route-filter
192.168.231.0/24 exact
1. 192.168.231.0
2. 192.168.231.0/16
3. 192.168.231.0/30
4. 192.168.231.0/24

A21: D. 192.168.231.0/24
The exact statement requires that the prefix length be exactly 24 bits; therefore
the /16 and /30 routes would not fit this description. Even though
192.168.231.20 is a Class C network address, there is no prefix length
associated with it, so a default prefix of /32 is assumed. Therefore the /32 does
not match the filter rules.
22: Which of the following matches the AS regular expression (1485 193+ 425?
www.ebook-converter.com
1226*.)?
1. 1485 193 193 482
2. 1485 193 425 1226 485
3. 193 1226
4. 1485 425 1356

A22: A. 1485 193 193 482

B. 1485 193 425 1226 485

Downloader
1485 must be present. 193+ means demo watermarks
1 or more repetition of 193, so at least 1
instance of 193 must be present. 425? means 0 or 1 repetitions of 425, so it can be
present or missing. 1226* means 0 or more repetitions of 1226, so it can be
present or missing. The . signifies that there must be a term following the previous
647
 A. Practice JNCIS Questions
terms, but it doesn't matter what it is.
23: Where would you specify SDH framing for a SONET interface?
1. At the [interface so-x/y/z sonet-options] level
2. At the [interface so-x/y/z] level
3. At the [chassis fpc (slot-number) pic (pic-number)] level
4. At the [chassis fpc (slot-number)] level

A23: C. At the [chassis fpc (slot-number) pic (pic-number)] level

SONET framing is set at the [chassis fpc (slot) pic (pic)] level of
the configuration.
[edit chassis]
user@host# set fpc slot-number pic pic-number framing sdh
24: Which version(s) of RSVP are supported by Juniper (up to v5.4)?

1. RSVPv1
2. RSVPv2
www.ebook-converter.com
RSVPv1 and v2
3.

4. RSVP support was not added until JUNOS 5.0

A24: A. RSVPv1
JUNOS currently supports RSVPv1 only (up through v4.4). Future implementations
may change the level of RSVP support.
25: In what mode must PIM be running for auto-rp to function (assuming you have
not configured a static RP)?
1. Sparse mode

Downloader
Dense mode
2. demo watermarks
3. Sparse-dense mode

648
 A. Practice JNCIS Questions
4.Multicast mode
A25: C. Sparse-dense mode
In order for auto-rp to function, the router must be operating in sparse-dense
mode. This allows the control traffic to reach the router via the dense groups
224.0.1.39 and 224.0.1.40, while allowing the rest of the groups to remain
in static mode as long as they have an RP dynamically configured for them.
Another option would be to leave the router in sparse mode and statically configure
an RP for the 224.0.1.39 and 224.0.1.40 multicast groups.
26: Router A receives an MPLS encapsulated packet with a label of 100020, which is
not included in the routing table. What does router A do with the packet?
1. Checks second to top label; if recognized, forwards accordingly
2. Drops the packet
3. Removes label stack and forwards according to the network address
4. Creates a new label and forwards to all routers

A26: B. Drops the packet

www.ebook-converter.com
When an LSR does not recognize the top label of a label stack, it will drop the
packet.
27: If a firewall filter is defined on an interface and a packet does not match any of the
terms, what action is taken?
1. The packet is accepted.
2. The packet is discarded.
3. The packet is rejected.
4. The packet is stored.

Downloader demo watermarks

A27: B. The packet is discarded.
The default action for a firewall filter is to discard all packets that do not match any
of the defined terms. The difference between discarding and rejecting a packet is
649
 A. Practice JNCIS Questions
that discard is a silent discard—no ICMP message is returned—but reject
28: causes an ICMP “Destination Unreachable”
If traffic-engineering message
bgp is enabled to beand
for MPLS, returned.
there are two routes
to the next-hop, one in inet.0 and one in inet.3, that have equal preference,
which next-hop will be chosen?
1. inet.0
2. inet.3
3. They will be load balanced
4. This will be randomly determined

A28: B. inet.3
The traffic-engineering bgp command causes routes to MPLS LSPs to be
installed in the inet.3 routing table only. When selecting next-hop, BGP always
gives preference to routes in inet.3 when they are equal to routes in inet.0.
29: MPLS provides what type of functioning to a router?

1. Multiprotocol Label Switching functionality

www.ebook-converter.com
Multiple Protocol Layered System
2.

3. Switch-like forwarding capabilities in a router

4. A system for running multiple protocols on a router

A29: A. Multiprotocol Label Switching functionality

C. Switch-like forwarding capabilities in a router
MPLS stands for multiprotocol label switching, which is a label switching function
on a router. It is designed to provide switch-like forwarding capabilities on a router
where forwarding decisions are based on labels rather than IP-route lookup
Downloader demo watermarks
information.
30: Which Juniper Networks routers support redundant routing engines?

1. M5
650
 A. Practice JNCIS Questions
2. M10
3. M20
4. M40
5. M160
A30: C. M20
E. M160
Only the M20 and M160 support redundant routing engines.

www.ebook-converter.com

Downloader demo watermarks

651