Advanced Junos Routing

Advanced Junos Service Provider
Routing
10.b
Student Guide
Worldwide Education Services

1194 North Mathilda Avenue
Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Course Number: EDU-JUN-AJSPR
This document is produced by Juniper Networks, Inc.

This document or any part thereof may not be reproduced or transmitted in any form under penalty of law, without the prior written permission of Juniper Networks
Education Services.
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other
countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered
trademarks, or registered service marks are the property of their respective owners.
Advanced Junos Service Provider Routing Student Guide, Revision 10.b
Copyright 2011 Juniper Networks, Inc. All rights reserved.
Printed in USA.
Revision History:
Revision 10.a March 2011
Revision 10.bSeptember 2011.
The information in this document is current as of the date listed above.
The information in this document has been carefully verified and is believed to be accurate for software Release 10.4R5.5. Juniper Networks assumes no
responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary,
incidental, or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.
Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has
no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an
agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and
agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper
Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should
consult the software license for further details.
Contents
Chapter 1: Course Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1
Chapter 2: OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1
OSPFv2 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Link-State Advertisements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-13
Protocol Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-40
OSPF Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-61
Lab 1: OSPF Multiarea Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-69
Chapter 3: OSPF Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

Review of OSPF Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Stub Area Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Stub Area Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-16
NSSA Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-19
NSSA Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-24
Route Summarization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-28
Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization . . . . . . . . . . . . . .3-35
Chapter 4: OSPF Case Studies and Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

Virtual Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
OSPF Multiarea Adjacencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-19
External Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-28
Lab 3: Advanced OSPF Options and Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-44
Chapter 5: IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

Overview of IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
IS-IS PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12
Neighbors and Adjacencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-43
Configuring and Monitoring IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-48
Lab 4: IS-IS Configuration and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-65
Chapter 6: Advanced IS-IS Operations and Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . .6-1

IS-IS Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
IS-IS Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-16
IS-IS Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-31
Lab 5: Advanced IS-IS Configuration Options and Routing Policy . . . . . . . . . . . . . . . . . . . . . .6-43
Chapter 7: Multilevel IS-IS Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1

Level 1 and Level 2 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Multilevel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-10
Lab 6: Configuring a Multilevel IS-IS Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-22
www.juniper.net
Contents iii
Chapter 8: BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Review of BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
BGP Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-23
BGP Path Selection Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-31
Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-41
Lab 7: BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-59
Chapter 9: BGP Attributes and PolicyPart 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

BGP Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10
Origin and MED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-25
AS Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-45
Lab 8: BGP Attributes: Next-Hop, Origin, MED, and AS Path . . . . . . . . . . . . . . . . . . . . . . . . . .9-72
Chapter 10: BGP Attributes and PolicyPart 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Local Preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3
Communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-13
Lab 9: BGP Attributes: Local Preference and Communities . . . . . . . . . . . . . . . . . . . . . . . . . .10-49
Chapter 11: Route Reflection and Confederations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Route Reflection Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-3
Configuration and Routing Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-9
BGP Confederations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-19
Lab 10: Scaling BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-28
Chapter 12: BGP Route Damping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1

Route Flap and Damping Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-3
Route Damping Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-10
Configuring and Monitoring Route Damping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-17
Lab 11: BGP Route Damping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-28
Appendix A: Acronym List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

Appendix B: Answer Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1
iv Contents
www.juniper.net
Course Overview
This four-day course is designed to provide students with detailed coverage of OSPF, IS-IS, BGP, and
routing policy. Through demonstrations and hands-on labs, students will gain experience in
configuring and monitoring the Junos operating system and in monitoring device and protocol
operations. This course is based on the Junos OS Release 10.4R5.5.
Objectives
After successfully completing this course, you should be able to:
www.juniper.net
Describe the various OSPF link-state advertisement (LSA) types.
Explain the flooding of LSAs in an OSPF network.
Describe the shortest-path-first (SPF) algorithm.
List key differences between OSPFv2 and OSPFv3.
Describe OSPF area types and operations.
Configure various OSPF area types.
Summarize and restrict routes.
Identify some scenarios in a service provider network that can be solved using routing
policy or specific configuration options.
Use routing policy and specific configuration options to implement solutions for
various scenarios.
Explain the concepts and operation of IS-IS.
Describe various IS-IS link-state protocol data unit (PDU) types.
List IS-IS adjacency rules and troubleshoot common adjacency issues.
Configure and monitor IS-IS.
Display and interpret the link-state database (LSDB).
Perform advanced IS-IS configuration options.
Implement IS-IS routing policy.
Explain the default operation in multiarea IS-IS.
Describe IS-IS address summarization methods.
Configure and monitor a multiarea IS-IS network.
Describe basic BGP operation.
List common BGP attributes.
Explain the route selection process for BGP.
Describe how to alter the route selection process.
Configure some advanced options for BGP peers.
Describe various BGP attributes in detail and explain the operation of those attributes.
Manipulate BGP attributes using routing policy.
Explain the causes for route instability.
Describe the effect of damping on BGP routing.
Explain the default behavior of damping on links.
Describe the operation of BGP route reflection.
Configure a route reflector.

Course Overview v
Describe the operation of a BGP confederation.
Configure confederations.
Describe peering relationships in a confederation.
Control damping using routing policy.
View damped routes using command-line interface (CLI) commands.
Intended Audience
This course benefits individuals responsible for implementing, monitoring, and troubleshooting
Layer 3 components of a service providers network.
Course Level
Advanced Junos Service Provider Routing is an advanced-level course.
Prerequisites
Students should have intermediate-level networking knowledge and an understanding of the Open
Systems Interconnection (OSI) model and the TCP/IP protocol suite. Students should also attend
the Introduction to the Junos Operating System (IJOS), Junos Routing Essentials (JRE), and Junos
Intermediate Routing (JIR) courses prior to attending this class.
vi Course Overview
www.juniper.net
Course Agenda
Day 1
Chapter 1: Course Introduction
Chapter 2: OSPF
Lab 1: OSPF Multiarea Networks
Chapter 3: OSPF Areas
Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization
Chapter 4: OSPF Case Studies and Solutions
Lab 3: Advanced OSPF Options and Policy
Day 2
Chapter 5: IS-IS
Lab 4: IS-IS Configuration and Monitoring
Chapter 6: Advanced IS-IS Operations and Configuration Options
Lab 5: Advanced IS-IS Configuration Options and Routing Policy
Chapter 7:
Multilevel IS-IS Networks

Lab 6: Configuring a Multilevel IS-IS Network
Day 3
Chapter 8: BGP
Lab 7: BGP
Chapter 9: BGP Attributes and PolicyPart 1
Lab 8: BGP Attributes: Next-Hop, Origin, MED, and AS Path
Day 4
Lab 9: BGP Attributes: Local Preference and Communities
Chapter 11: Route Reflection and Confederations
Lab 10: Scaling BGP (Detailed)
Chapter 12: BGP Route Damping
Lab 11: BGP Route Damping (Detailed)
www.juniper.net
Course Agenda vii
Document Conventions
CLI and GUI Text
Frequently throughout this course, we refer to text that appears in a command-line interface (CLI)
or a graphical user interface (GUI). To make the language of these documents easier to read, we
distinguish GUI and CLI text from chapter text according to the following table.
Style
Description
Usage Example
Franklin Gothic
Normal text.
Most of what you read in the Lab Guide

and Student Guide.
Courier New
Console text:
Screen captures
commit complete
Noncommand-related
syntax
Exiting configuration mode
GUI text elements:

Menu names
Text field entry
Select File > Open, and then click

Configuration.conf in the
Filename text box.
Input Text Versus Output Text

You will also frequently see cases where you must enter input text yourself. Often these instances
will be shown in the context of where you must enter them. We use bold style to distinguish text
that is input versus text that is simply displayed.
Style
Description
Usage Example
Normal CLI
No distinguishing variant.
Physical interface:fxp0,
Enabled
Normal GUI
View configuration history by clicking

Configuration > History.
CLI Input
Text that you must enter.
lab@San_Jose> show route

Select File > Save, and type
config.ini in the Filename field.
GUI Input
Defined and Undefined Syntax Variables

Finally, this course distinguishes between regular text and syntax variables, and it also
distinguishes between syntax variables where the value is already assigned (defined variables) and
syntax variables where you must assign the value (undefined variables). Note that these styles can
be combined with the input style as well.
Style
Description
Usage Example
CLI Variable
Text where variable value is already

assigned.
policy my-peers
Text where the variables value is

the users discretion or text where
the variables value as shown in
the lab guide might differ from the
value the user must input
according to the lab topology.
Type set policy policy-name.
GUI Variable
CLI Undefined
GUI Undefined
viii Document Conventions
Click my-peers in the dialog.
ping 10.0.x.y
Select File > Save, and type
filename in the Filename field.
www.juniper.net
Additional Information
Education Services Offerings
You can obtain information on the latest Education Services offerings, course dates, and class
locations from the World Wide Web by pointing your Web browser to:
http://www.juniper.net/training/education/.
About This Publication

The Advanced Junos Service Provider Routing Student Guide was developed and tested using
software Release 10.4R5.5. Previous and later versions of software might behave differently so
you should always consult the documentation and release notes for the version of code you are
running before reporting errors.
This document is written and maintained by the Juniper Networks Education Services development
team. Please send questions and suggestions for improvement to training@juniper.net.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats:
Go to http://www.juniper.net/techpubs/.
Locate the specific software or hardware release and title you need, and choose the
format in which you want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or
account representative.
Juniper Networks Support

For technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or
at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the United States).
www.juniper.net
Additional Information ix
x Additional Information
www.juniper.net

Routing
Chapter 1: Course Introduction
Advanced Junos Service Provider Routing
This Chapter Discusses:
Objectives and course content information;
Additional Juniper Networks, Inc. courses; and
The Juniper Networks Certification Program.
Chapter 12 Course Introduction
www.juniper.net
Introductions
The slide asks several questions for you to answer during class introductions.
www.juniper.net
Course Introduction Chapter 13
Course Contents
The slide lists the topics we discuss in this course.
www.juniper.net
Prerequisites
The slide lists the prerequisites for this course.
www.juniper.net
General Course Administration

The slide documents general aspects of classroom administration.
www.juniper.net
Training and Study Materials

The slide describes Education Services materials that are available for reference both in the
classroom and online.
www.juniper.net
Additional Resources
The slide provides links to additional resources available to assist you in the installation,
configuration, and operation of Juniper Networks products.
www.juniper.net
Satisfaction Feedback
Juniper Networks uses an electronic survey system to collect and analyze your comments and
feedback. Depending on the class you are taking, please complete the survey at the end of the class,
or be sure to look for an e-mail about two weeks from class completion that directs you to complete
an online survey form. (Be sure to provide us with your current e-mail address.)
Submitting your feedback entitles you to a certificate of class completion. We thank you in advance
for taking the time to help us improve our educational offerings.
www.juniper.net
Juniper Networks Education Services Curriculum

Juniper Networks Education Services can help ensure that you have the knowledge and skills to
deploy and maintain cost-effective, high-performance networks for both enterprise and service
provider environments. We have expert training staff with deep technical and industry knowledge,
providing you with instructor-led hands-on courses in the classroom and online, as well as
convenient, self-paced eLearning courses.
Course List
You can access the latest Education Services offerings covering a wide range of platforms at
http://www.juniper.net/training/technical_education/.
www.juniper.net
Juniper Networks Certification Program

A Juniper Networks certification is the benchmark of skills and competence on Juniper Networks
technologies.
www.juniper.net
Juniper Networks Certification Program Overview

The Juniper Networks Certification Program (JNCP) consists of platform-specific, multitiered tracks
that enable participants to demonstrate competence with Juniper Networks technology through a
combination of written proficiency exams and hands-on configuration and troubleshooting exams.
Successful candidates demonstrate thorough understanding of Internet and security technologies
and Juniper Networks platform configuration and troubleshooting skills.
The JNCP offers the following features:
Multiple tracks;
Multiple certification levels;
Written proficiency exams; and
Hands-on configuration and troubleshooting exams.
Each JNCP track has one to four certification levelsAssociate-level, Specialist-level,

Professional-level, and Expert-level. Associate-level and Specialist-level exams are computer-based
exams composed of multiple choice questions administered at Prometric testing centers worldwide.
Professional-level and Expert-level exams are composed of hands-on lab exercises administered at
select Juniper Networks testing centers. Professional-level and Expert-level exams require that you
first obtain the next lower certification in the track. Please visit the JNCP Web site at
http://www.juniper.net/certification for detailed exam information, exam pricing, and exam
registration.
www.juniper.net
Preparing and Studying

The slide lists some options for those interested in preparing for Juniper Networks certification.
www.juniper.net
Find Us Online
The slide lists some online resources to learn and share information about Juniper Networks.
www.juniper.net
Any Questions?
If you have any questions or concerns about the class you are attending, we suggest that you voice
them now so that your instructor can best address your needs during class.
www.juniper.net
www.juniper.net

Routing
Chapter 2: OSPF
Chapter 22 OSPF
OSPF link-state advertisements (LSAs);
The flooding of LSAs throughout the network;
The shortest-path-first (SPF) algorithm; and
The key differences between OSPFv2 and OSPFv3.
www.juniper.net
OSPFv2 Review
The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
www.juniper.net
OSPF Chapter 23
Link-State Protocol
OSPF is an interior gateway protocol (IGP) based on the concept of a link-state database (LSDB). As
such, each OSPF-speaking router in the network attempts to form an adjacency with each
neighboring OSPF router. When these adjacencies are in place, each router generates and floods
LSAs into the network in a reliable manner. The LSAs are placed into the LSDB on each router where
the SPF algorithm is calculated to find the best path to each end node in the network.
Neighbors Use Hello Packets

OSPF routers send out hello packets to form and maintain adjacencies with their neighbors.
LSAs Are Flooded

OSPF uses IP protocol number 89 and the AllSPFRouters multicast address of 224.0.0.5 to flood
LSAs. OSPF routers forward all LSAs through all OSPF configured interfaces except the one on which
an LSA was received:
LSAs are installed in the OSPF database that forms the topology map of the network;
and
The SPF algorithm is run to determine the shortest path to each destination subnet.
Continued on the next page.
Chapter 24 OSPF
www.juniper.net
Hierarchical Design
OSPF gains scalability as a protocol through the use of a hierarchical design. Portions of the network
are designated as separate areas. These remote areas are then connected through a common area
known as the backbone.
Designated Router Election

On a broadcast segment, OSPF routers elect a single node to represent the segment to the network.
This node is called the designated router (DR). It forms an OSPF adjacency with all routers on the
segment and floods a network LSA into the appropriate area. The criteria for electing the DR is the
highest configured priority on the segment, which is set to 128 by default. The second criteria for
electing a DR is the highest router ID on the segment.
The election of a DR on a broadcast segment is a nondeterministic event. Thus, the router with the
best criteria might not always be the DR for the segment. An operational DR maintains its status on
the segment until it stops operating.
The first OSPF router on a link determines itself as the DR if it does not detect a Hello from another
router.
Most Ethernet segments are point-to-point, full-duplex these days, which eliminates the need for a
DR election. Use the interface-type p2p command to change the default interface type.
www.juniper.net
OSPF Chapter 25
The LSDB
In addition to discovering neighbors and flooding LSAs, a third major task of the OSPF protocol is to
create and maintain the LSDB. The link-state, or topological, database stores the LSAs as a series of
records. The contents stored within the LSDB include details such as the advertising routers ID, its
attached networks and neighboring routers, and the cost associated with those networks or
neighbors. According to the OSPF RFC, each router in an OSPF area must have an identical LSDB to
ensure accurate routing knowledge. We discuss OSPF areas later in this course.
The information recorded in the database is used as input data to calculate the shortest paths (that
is, least-cost paths) for all destination prefixes within the network. OSPF uses the SPF algorithm or
Dijkstra algorithm to calculate, all at once, the shortest paths to all destinations. It performs this
calculation by creating a tree of shortest paths incrementally and picking the best candidate from
that tree. The results of this calculation are then handed to the routers routing table for the actual
forwarding of data packets.
Chapter 26 OSPF
www.juniper.net
Packet Types
Every OSPF router uses a specific set of packets to perform its functions. The packet types include
the following:
www.juniper.net
Hello: Sent by each router to form and maintain adjacencies with its neighbors.
Database description: Used by the router during the adjacency formation process. It
contains the header information for the contents of the LSDB on the router.
Link-state request: Used by the router to request an updated copy of a neighbors LSA.
Link-state update: Used by the router to advertise LSAs into the network.
Link-state acknowledgment: Used by the router to ensure the reliable flooding of LSAs
throughout the network.
OSPF Chapter 27

.
Hierarchical Design
The slide graphically displays the hierarchical nature of OSPF. A backbone area (0.0.0.0) is the
connecting point for all other areas. By specification, each area must attach to the backbone in at
least one location.
Area 1, Area 2, and Area 3 each contain routers internal to that area as well as a single area border
router (ABR). The ABR generates summary LSAs that represent the routes within its area and floods
those to the backbone. The ABR is also responsible for generating summary LSAs that represent the
backbone routes and injecting those into its attached area.
Chapter 28 OSPF
www.juniper.net
OSPF Routers
OSPF routers can take on a number of different roles within an OSPF domain. The following list
shows the common types of OSPF routers along with a brief description:
www.juniper.net
ABR: An OSPF router with links in two areas, the ABR is responsible for connecting OSPF
areas to the backbone. It transmits network information between the backbone and
other areas.
Autonomous system boundary router (ASBR): An OSPF router that injects routing
information from outside the OSPF AS, an ASBR is typically located in the backbone.
However, the OSPF specification allows an ASBR to be in other areas as well.
Backbone router: Defined as any OSPF router with a link to Area 0 (the backbone), this
router can also be an internal or ABR depending on whether it has links to other,
nonbackbone areas.
Internal router: An internal router is an OSPF router with all its links within an area. If
that router is located within the backbone area (Area 0.0.0.0), it is also known as a
backbone router.
OSPF Chapter 29
Single Area Configuration Example

The slide illustrates the basic hierarchy and syntax used to configure an OSPFv2 single area. OSPFv2
is configured at the [edit protocols ospf] hierarchy as shown in the example.
OSPF Interfaces
All logical interfaces associated with the area should be listed under the area. Remember the
loopback interface, if it should be advertised.
Chapter 210 OSPF
www.juniper.net
Multiarea Configuration Example

The slide illustrates the basic hierarchy and syntax used to configure the OSPFv2 multiarea. As in the
single area example previously shown, the configuration is performed at the [edit protocols
ospf] hierarchy.
OSPF Interfaces
All logical interfaces associated with the particular area should be listed under that area. Remember
the loopback interface, if it should be advertised.
www.juniper.net
OSPF Chapter 211
OSPFv3 Protocol Highlights

OSPFv3 is to IP version 6 (IPv6) what OSPFv2 is to IP version 4 (IPv4). OSPFv3 is defined in RFC
5340 and supports IPv6 addressing.
OSPFv3 Versus OSPFv2

OSPFv3 and OSPFv2 have much in common, but OSPF has many differences that take advantage of
the new features of IPv6. Some but not all of the differences are listed on this slide.
Beyond the Scope

An in-depth discussion of OSPFv3 is beyond the scope of this course.
Chapter 212 OSPF
www.juniper.net
Link-State Advertisements
The slide highlights the topic we discuss next.
www.juniper.net
OSPF Chapter 213
Multiple LSAs in a Single Update

Each link-state update packet sent into the network by an OSPF-speaking router can carry multiple
different LSAs. This ability saves network resources by allowing routers to use transmission and
routing capacity more efficiently.
Link-State Update Format

The graphic illustrates the format of the link-state update packet. Following the standard OSPF
header, the update packet contains a 4-byte field used to notify other routers as to the number of
advertisements stored in the update message. This field is followed by the LSAs themselves, each
with its own header and data.
Chapter 214 OSPF
www.juniper.net
LSA Types
The following list provides the details of the LSA types:
Router LSA: Sent by each router to describe its individual links and their status.
Network LSA: Sent by the DR on the broadcast network.
Summary LSA: Sent by an ABR to describe routes or other information from one area
into another.
AS external LSA: Sent by an ASBR to describe routes external to the OSPF domain.
Group membership LSA: Used to support Multicast OSPF (MOSPF).
NSSA LSA: Sent by an ASBR in a not-so-stubby area (NSSA) to describe routes external
to the OSPF domain.
External attributes LSA: Used to tunnel attributes used by other routing protocols
through OSPF.
Opaque LSAs: Used to transmit information not currently supported by other LSA types.
Examples include graceful restart and traffic engineering information.
www.juniper.net
OSPF Chapter 215
LSA Functions
Each of the LSA types listed previously has a specific function within the OSPF domain. They each
describe a portion of the topology used by the Dijkstra (SPF) algorithm to supply routing information
to a routing table. We discuss each LSA in more detail on future slides.
Each LSA has a maximum age of 3600 seconds (1 hour) associated with it. This maximum provides
a mechanism for removing stale information from the database. To ensure that its LSAs are
up-to-date, each OSPF router periodically refreshes them prior to reaching the maximum age limit.
The Junos operating system performs this refresh every 50 minutes (3000 seconds).
LSAs Not Supported

The Junos OS does not support some of the previously listed LSA types. These LSAs are the group
membership (Type 6), external attributes (Type 8), and the domain-scope opaque (Type 11)
advertisements.
Chapter 216 OSPF
www.juniper.net
LSA Header
The following list details the information contained in the LSA header:
www.juniper.net
LS age (2 bytes): Measured in seconds, the link state age is the time since the LSA was
first originated. Each router increments this field prior to reflooding the LSA.
Options (1 byte): Indicates support for OSPF options. Within the context of an individual
LSA, the E bit (position 7) is set in all External LSAs and the P bit (position 5) is set in all
NSSA external LSAs.
LS type (1 byte): Encodes the specific LSA type.
Link-state ID (4 bytes): Describes various portions of the OSPF domain. Each LSA type
uses this field in a different manner.
Advertising router (4 bytes): The router ID of the router that first originated the LSA.
LS sequence number (4 bytes): Verifies that each router has the most recent version of
an LSA. This field is incremented each time a new version is generated. Values range
from 0x80000000 to 0x7FFFFFFF.
LS checksum (2 bytes): The checksum of the entire LSA contents, minus the link state
age field. This field is used to ensure data integrity in the LSDB.
Length (2 bytes): The entire length of the individual LSA, including the header.
OSPF Chapter 217
Router LSA
Each OSPF-speaking router generates a Type 1 LSA to describe the status and cost (metric) of all
interfaces on the router. This LSA is flooded to each router in the OSPF area. It is defined as having
an area scope; therefore, it is not flooded across an area boundary. In addition to the standard LSA
header, the router LSA also contains the following fields:
Chapter 218 OSPF
V, E, and B bits (1 byte): Following five bits set to a value of 0, the V, E, and B bits
represent the characteristics of the originating router. The V bit is set when a virtual link
is established. An ASBR sets the E bit. An ABR sets the B bit.
Number of links (2 bytes): This value gives the total number of links represented by the
following set of fields.
Link ID (4 bytes): This field represents to what the far side of the link is connected. It is
used in conjunction with the link type field.
Link data (4 bytes): This field represents to what the near side of the link is connected.
It is used in conjunction with the link type field.
Link type (1 byte): This field describes the type of link.
Number of ToS metrics (1 byte): This field lists the number of type of service (ToS)
metrics encoded. Only a value of 0 is supported.
Metric (2 bytes): This field provides the cost to transmit data out of the interface.
Additional ToS data (4 bytes): This field is unused.

www.juniper.net
Link ID and Link Data Fields

The information in the router LSAs link ID and link data fields is associated with the type of link OSPF
is operating. The following link types are supported:
www.juniper.net
Point-to-point (Type 1): On a point-to-point interface, an OSPF router always forms an

adjacency with its peer over an unnumbered connection. As such, the link ID field
contains the neighbors router ID. The link data field contains the IP address of the
interface on the local router.
Transit (Type 2): A connection to a broadcast segment is always noted as a transit link.
The link ID field contains the interface IP address of the segments designated router.
The link data field contains the interface IP address of the local router.
Stub (Type 3): A router advertises a stub network when a subnet does not connect to
any OSPF neighbors. Advertising a stub network occurs for the loopback interface and
any passive interfaces. In addition, the IP subnet for any point-to-point interface is
advertised as a stub because the adjacency was formed over an unnumbered interface.
The link ID field for a stub network contains the IP network number and the link data
field contains the subnet mask.
Virtual link (Type 4): A virtual link operates between an ABR connected to Area 0 and an
ABR that is not connected to Area 0. Once established, the virtual link appears in the
Area 0 router LSA of each endpoint. The link ID field contains the neighbors router ID,
and the link data field contains the interface IP address of the local router.
OSPF Chapter 219
Router LSA Example

The slide shows the details of the router LSA in the example. By using the keyword extensive, you
can see each of the LSA fields. You can gather some important details about the local router by
examining the LSA closely:
This router is both an ABR as well as an ASBR, which we can see by the setting of bits
0x3. Recall that position 7 (0x2) is for the E bit, which is set when the originating router
is an ASBR. Bit position 8 (0x1) is for the B bit, which is set when the originating router
is an ABR. Combining these two fields results in a value of 0x3, which we see in the
database capture.
This router has three links connected to Area 0, which we can determine because of two
factors. First, the link count field is set to a value of 3. Second, the LSA is shown in the
database within the Area 0.0.0.0 section. Recall that a router LSA has area scope, so a
separate LSA is generated for each area representing the links only within that area.
A single point-to-point link exists, and two links are connected to stub networks. This
fact is clearly visible from the information in the type fields.
Chapter 220 OSPF
www.juniper.net
Router LSA Example (contd.)
www.juniper.net
The router LSA will be regenerated in 48 minutes and 50 seconds as indicated by the
Gen timer. The OSPF standard requires that every LSA be refreshed every 60 minutes.
The Juniper implementation refreshes LSAs every 50 minutes. By default, any LSA that
is not refreshed expires after 60 minutes.
This router LSA was originated by the same router from which the capture was taken.
Notice the asterisk (*) next to the link-state ID value of 192.168.20.1. Also note that
the last line of the capture states that this LSA is Ours.
The router LSA was installed 1 minutes and 10 seconds ago. If not refreshed, the LSA
will expire in 58 minutes and 50 seconds, when its 3600 second maximum age is
exceeded. The LSA was last flooded 1 minutes and 8 seconds ago. These details are
shown in the Installed, expires, and sent fields, and they are present for every
LSA in the show ospf database extensive output.
OSPF Chapter 221
Add Type 1 LSAs to an OSPF Network

Using the information in the router LSA, we can begin to draw a network map based on the LSDB:
Chapter 222 OSPF
We know of three routers within area 0.0.0.0192.168.20.1 (the local router),

192.168.100.1, and 192.168.21.1;
Two point-to-point subnets connect the three routers172.22.121.0/24 and

172.22.122.0/24;
The IP address of the interface connecting 192.168.20.1 to 192.168.100.1 is

172.22.121.1;
The IP address of the interface connecting 192.168.21.1 to 192.168.100.1 is

172.22.122.1.
www.juniper.net
Network LSA
Each OSPF router elected to be the DR on a broadcast link generates a Type 2 LSA. This LSA lists
each router connected to the broadcast link, including the DR itself. In addition to the standard LSA
header, the network LSA also contains the following fields:
www.juniper.net
Network mask (4 bytes): This field denotes the IP subnet mask for the interface
connected to the broadcast network.
Attached router (4 bytes): This field is repeated for each router connected to the
broadcast network. The value of each instance is the router ID of the attached routers.
You can deduce the total number of routers listed by the length of the LSA.
OSPF Chapter 223
Network LSA Example

You can see the details of the network LSA in the example on the slide. By using the keyword
extensive, you can see each of the LSA fields. You can gather some important details about this
network by examining the LSA closely:
Chapter 224 OSPF
The designated router for this network is 10.0.12.2, which you can determine by
examining the link-state ID field. This field lists the DRs IP address.
Because only two instances of the attached router field are present, you can safely
deduce that only two routers are connected to the link. The router IDs of those two
routers are 192.168.20.2 and 192.168.20.4.
www.juniper.net

Using the information in the network LSA, we can add information to our OSPF network map.
Remember that all information is from the perspective of the 192.168.20.1 router.
www.juniper.net
We know of two routers within area 0.0.0.10192.168.20.2 and 192.168.20.4;
A broadcast segment connects the two routers together whose address is

10.0.12.0/24; and
The designated router for the segment is 192.168.20.4 and its interface address is
10.0.12.2.
OSPF Chapter 225
Summary LSA
Each ABR that transmits information from one OSPF area into another generates a Type 3 LSA to
describe that information. This LSA is flooded to each router in the OSPF area. This LSA has an area
scope; therefore, it is not reflooded across the area boundary by another ABR. Instead, the receiving
ABR generates a new Type 3 LSA describing the link and floods it into the adjacent area.
In addition to the standard LSA header, the summary LSA also contains the following fields:
Chapter 226 OSPF
Network mask (4 bytes): This field represents the subnet mask associated with the
network advertised. It is used in conjunction with the link-state ID field, which
encapsulates the network address in a Type 3 LSA.
Metric (3 bytes): This field provides the cost of the route to the network destination.
When the summary LSA is representing an aggregated route (using the area-range
command), this field is set to the largest current metric of the contributing routes.
ToS (1 byte): This field describes any optional ToS information encoded within the
network described. The Junos OS does not use this field.
ToS metric (3 bytes): This field is not used.
www.juniper.net
Summary LSA Example

The slide shows the details of the summary LSA in the example. By using the keyword extensive,
you can see each of the LSA fields. You can gather some important details about the local router by
examining the LSA closely:
This router is an ABR because it contains a database for area 0.0.0.0. Within that area,
three summary LSAs are listed. Two of the LSAs (the first and second ones listed) are
from the router where the capture was taken. As with the router LSA earlier, notice that
an asterisk (*) is next to the link-state ID values of 10.0.10.0 and 10.0.12.0. Also
note that the last line of the LSA states that the LSA is Ours.
A second router in the backbone (192.168.21.1) generates the other summary LSA.
The network advertised by that ABR is 10.0.14.0/24. The network has a metric of 1
encoded within the LSA. The local router adds the cost to reach 192.168.21.1 to the
metric of 1 prior to calculation of the SPF algorithm.
Note that the command output on the slide is truncated.
www.juniper.net
OSPF Chapter 227

Once again, we view the database from the 192.168.20.1 router. Using the information in the
summary LSAs, we can add the following information to our map:
Chapter 228 OSPF
A new router exists in an OSPF area connected to 192.168.21.1.
We do not know the 32-bit value for the area, but we know that an internal area router
exists within it192.168.21.2.
Using the metric values in the summary LSAs, we can determine that the area router
and the ABR are connected over the 10.0.14.0/24 subnet.
Within area 0.0.0.10, we now know that the 192.168.20.2 router is directly connected
to our local router of 192.168.20.1. We use the summary LSA metric value to make that
determination.
www.juniper.net
ASBR Summary LSA

Each ABR that must transmit information about an ASBR from one OSPF area into another generates
a Type 4 LSA to describe that information. This LSA is flooded to each router in the OSPF area. It is
defined as having an area scope; therefore, another ABR does not reflood it across the area
boundary. In addition to the standard LSA header, the ASBR summary LSA also contains the
following fields:
www.juniper.net
Network mask (4 bytes): This field has no meaning in a Type 4 LSA and is set to 0.0.0.0.
The address of the ASBR is encoded in the link-state ID field.
Metric (3 bytes): This field provides the cost of the route to the ASBR.
ToS (1 byte): This field describes any optional type of service information used to reach
the ASBR described. This field is not used.
ToS metric (3 bytes): This field is not used.
OSPF Chapter 229
ASBR Summary LSA Example

The slide shows the details of the ASBR summary LSA in the example. By using the keyword
extensive, you can see each of the LSA fields. You can gather some important details about the
local router by examining the LSA closely.
Chapter 230 OSPF
This router is an ABR because it contains a database for Area 0.0.0.0. Within that area,
two ASBR summary LSAs are listed on the slide. The second LSA is from the local router
(where the capture was taken). As with the router LSA earlier, notice that an asterisk (*)
is next to the link-state ID value and that the last line of the LSA states that the LSA is
Ours.
The second router in the backbone (192.168.21.1) generates the other ASBR summary
LSA.
The two ASBRs being advertised are 192.168.21.2 and 192.168.20.4. You can see this
information coded in the link-state ID fields. Because the router ID of the ASBR is a full
32-bit value, the network mask is not needed and is set to a value of 0.0.0.0.
The metrics to each of the ASBRs are encoded in the appropriate field in the LSA. As
with the summary LSA (Type 3), the local router must add the cost to reach a remote
ABR to the encoded metric prior to calculation of the SPF algorithm.
www.juniper.net

The network map does not change based on the information in the ASBR summary LSAs. However,
these LSAs do provide a clue as to the capabilities of the OSPF routers:
www.juniper.net
Routers 192.168.20.4 and 192.168.21.2 both have export policies configured within
OSPF, which means that they have set the E bit in their router LSAs.
Based on the E bit setting in the router LSAs, the ABRs of 192.168.20.1 and
192.168.21.1 generate ASBR summary LSAs across the area boundaries. In our case,
we see the type 4 LSAs within area 0.0.0.0.
OSPF Chapter 231
AS External LSA
Each ASBR generates a Type 5 LSA to advertise any networks external to the OSPF domain. This LSA
is flooded to each nonstub router in the entire OSPF domain. In addition to the standard LSA header,
the AS external LSA also contains the following fields:
Chapter 232 OSPF
Network mask (4 bytes): This field represents the subnet mask associated with the
network advertised. It is used in conjunction with the link-state ID field, which
encapsulates the network address in a Type 5 LSA.
E bit (1 byte): The E bit determines the type of external metric represented by the metric
field. It is followed by 7 bits, all set to 0 to make up the entire byte. A value of 0, the
default value, indicates that this is a Type 2 external metric. Thus, any local router
should use the encoded metric as the total cost for the route when performing an SPF
calculation. A value of 1 indicates that this is a Type 1 external metric. Therefore, the
encoded metric of the route should be added to the cost to reach the advertising ASBR.
This additive value then represents the total cost for the route.
Metric (3 bytes): This field represents the cost of the network as set by the ASBR.
Forwarding address (4 bytes): This field provides the address toward which packets
should be sent to reach the network. A value of 0.0.0.0 represents the ASBR itself.
External route tag (4 bytes): This 32-bit value field can be assigned to the external
route. OSPF does not use this value, but it might be interpreted by other protocols.
Optional ToS fields (4 bytes): These fields are unused.

www.juniper.net
AS External LSA Example

The slide shows the details of the AS external LSA in the example. By using the keyword
extensive, you can see each of the LSA fields. You can gather some important details about the
local router by examining the LSA closely:
www.juniper.net
The external LSDB lists all the LSAs. This listing denotes their domain scope status as
not belonging to a particular OSPF area.
This router is generating the first LSA listed. As with the router LSA earlier, an asterisk
(*) exists next to the link-state ID value, and the last line of the LSA states that the LSA
is Ours.
Different routers generate each of the other three LSAs because the advertising router
field is different for each LSA.
Examination of the link-state ID and the network mask fields shows that the four
different networks advertised are 20.20.1.0/24, 20.20.3.0/24, 20.20.5.0/24, and
20.20.6.0/24. Each of these networks has a metric value of 0 encoded. In addition,
each of these LSAs is a Type 2 metric (as seen by the type field). Type 2 is the default
type for route redistribution. It reflects only the cost of the path from the ASBR to the
destination. A Type 1 tells the local router to add the cost to reach the remote ASBR to
the encoded metric prior to calculation of the SPF algorithm. The metric to the ASBR is
used because the forwarding address field for each LSA is listed as 0.0.0.0.
OSPF Chapter 233

The addition of AS external LSAs to our network map displays the external routes being advertised
into the network:
Chapter 234 OSPF
The 20.20.1.0/24 route is being injected by the 192.168.20.1 router;
The 20.20.3.0/24 route is being injected by the 192.168.21.1 router;
The 20.20.5.0/24 route is being injected by the 192.168.20.4 router; and
The 20.20.6.0/24 route is being injected by the 192.168.21.2 router.
www.juniper.net
NSSA External LSA Origination

Each ASBR within the NSSA generates a Type 7 LSA to advertise any networks external to the OSPF
domain. This LSA is flooded to each router within the NSSA. Because the LSA has only an area
flooding scope, it is not sent into other adjacent areas.
The format of the NSSA external LSA is exactly the same as the AS external LSA (Type 5) described on
an earlier slide. The only difference between the two LSAs is in the use of the forwarding address
field. With the Type 7 LSA, the forwarding address depends on whether the network connecting the
NSSA to the adjacent system is known as an internal route to the NSSA. If the network is known, the
next-hop address of the remote router is placed into the forwarding address field. If the network is
not known, the forwarding address field contains the router ID of the ASBR.
www.juniper.net
OSPF Chapter 235
NSSA External LSA Translation

By definition, only NSSA-capable routers can interpret a Type 7 LSA. Having only NSSA-capable
routers able to interpret this LSA type causes a problem with flooding the routing knowledge
throughout the OSPF domain because not all routers are configured to support NSSA. Furthermore,
the NSSA external LSA represents the same type of information as the AS external LSA, and each
OSPF router expects to receive an LSA for all external routes. This apparent contradiction is resolved
by allowing the ABR to generate an AS external LSA (Type 5) on behalf of the NSSA ASBR. For each
Type 7 LSA received, the ABR translates the information into a Type 5 LSA and sends that
information into the backbone. This translation is performed by the ABR with the highest router ID.
The other backbone routers do not know that the original information came from an NSSA and
perform their duties as previously discussed.
When an ASBR is also an ABR with an NSSA area attached to it, a Type 7 LSA is exported into the
NSSA area by default. If the ABR is attached to multiple NSSAs, a separate Type 7 LSA is exported
into each NSSA by default. Use the no-nssa-abr command to disable the export.
Chapter 236 OSPF
www.juniper.net
NSSA External LSA Example

The slide shows the details of the NSSA external LSAs in the example. The 192.168.21.2 ASBR
generated the second LSA. By using the keyword extensive, you can see each of the LSA fields.
You can gather some important details about the local router by examining the LSA closely:
www.juniper.net
Notice that the LSA is listed within the area 0.0.0.20 database. This listing denotes its
area scope status as belonging to a single NSSA area.
An examination of the link-state ID and the network mask fields shows that the network
advertised is 20.20.6.0/24. This network has a metric value of 0 encoded. It also is
listed as a Type 2 metric (as seen by the type field).
The NSSA does know the network connecting the ASBR to the remote domain. You can
see this fact by examining the forwarding address field where it lists the router ID of the
ASBR, 192.168.21.2.
OSPF Chapter 237

When we focus our attention on the 192.168.21.1 ABR, we now get some added information about
the network composition:
Chapter 238 OSPF
The area attached to the 192.168.21.1 router is area 0.0.0.20. It is also currently
configured as an NSSA.
The 20.20.6.0/24 route is being injected into area 0.0.0.20 as a Type 7 LSA. It is
translated into a Type 5 LSA by the 192.168.21.1 router.
www.juniper.net
Future Extensibility
RFC 2370 defines the OSPF opaque LSA. It was designed to extend the protocol to support future
enhancements without generating new LSA types. As of this writing, production networks use both
the Type 9 and Type 10 opaque LSAs. The Type 9 LSA supports graceful restart. The Type 10 LSA
supports MPLS traffic engineering. The Type 11 opaque LSA is not used at this time.
Flooding Scope
The main difference between the opaque LSAs is in the flooding scope of each type: the Type 9 LSA
has a link-local scope, the Type 10 LSA has an area scope, and the Type 11 LSA has domain scope.
Opaque LSA Format

The format of the opaque LSA has the standard LSA header followed by some number of octets
containing application-specific information. You can interpret the total number of octets contained in
the message by examining the length field in the LSA header. In addition, the link-state ID field is
segmented into a 1-byte opaque type field and a 3-byte opaque ID field. The Internet Assigned
Numbers Authority (IANA) has the responsibility of assigning new opaque type codes in the
0127 range. Values between 128 and 255 are set aside for private and experimental use only.
Opaque-capable routers communicate their ability to each other by using a new bit in the options
field. Bit position 2 is defined as the O bit. A value of 1 in this bit position allows a remote router to
flood opaque LSAs to the local router. A value of 0 tells the remote router not to flood those LSA
types.
www.juniper.net
OSPF Chapter 239
Protocol Operations
Chapter 240 OSPF
www.juniper.net
LSA Flooding Scopes

As discussed on previous slides, each LSA in the OSPF protocol has a specific scope within which it
can be flooded. This slide graphically displays those flooding scopes.
LSA Types 1 and 2 are generated within each area. Because these LSAs have an area flooding
scope, they remain within their own particular area and are not seen in other areas. The ABR places
the routing information contained within these LSAs into a Type 3 LSA and forwards it across the
area boundary. In addition, existing Type 3 LSAs within the backbone are forwarded into the
nonbackbone areas to provide routing knowledge to those routers. This results in Type 3 LSAs within
every area that represent all OSPF routes. Within Area 1, for example, Type 3 LSAs exist that
represent Area 0, Area 2, and Area 3.
In the diagram, two ASBRs inject routes into the OSPF domain. The AS external LSAs (Type 5) that
represent those routes have domain flooding scope (with the exception of stub areas). As such, they
exist within each OSPF area. To reach those external routes, the OSPF routers use either router LSAs
or ASBR summary LSAs (Type 4) to have knowledge of the ASBRs. Much like the Type 3 LSAs, the
ASBR summary LSAs have area scope, so the area border binds them. Each ABR regenerates the
Type 4 summary LSAs into their respective areas to provide the knowledge of how to route towards
the ASBR that is advertising a given external prefix. This capability leads to Type 4 LSAs for Area 0
being injected into Area 1, Area 2, and Area 3, while a Type 4 for Area 3 is injected into Area 0, Area
1, and Area 2.
www.juniper.net
OSPF Chapter 241
Sample OSPF Database

You can see key details of the OSPF database in the database example on the slide, which has been
edited for brevity. To this point, we have examined small portions of the database through the use of
the extensive keyword. We now take a step back and examine the database as a whole. As
before, you can gather some details by examining the database closely:
Chapter 242 OSPF
The local router is an ABR between the backbone and Area 0.0.0.1, which you can see
clearly through the existence of two databases on the router.
Within Area 0.0.0.1, a broadcast link is in use. In addition, the DR on that link is the
router whose address is 10.222.1.1. Notice the Type 2 LSA within the Area 0.0.0.1
database. The link-state ID is 10.222.1.1, the DRs IP address on the link.
Multiple routers act as ASBRs and inject routes into the OSPF domain. Those routers
are 192.168.16.1, 192.168.20.1, 192.168.32.1, and 192.168.36.1. The routes
advertised by those ASBRs can be used once the local router has knowledge of how to
reach the ASBR.
One of the ASBRs is the local router, 192.168.16.1. One of the external LSAs lists this
router ID, and that LSA is marked with an asterisk (*). A second ASBR is a router within
Area 0.0.0.1 (192.168.20.1). This router ID is found within a router LSA in the Area
0.0.0.1 database. A third ASBR is a router within the backbone (192.168.36.1). This
router ID is found within a router LSA in the Area 0.0.0.0 database. The fourth ASBR is a
router in an area beyond the backbone (192.168.32.1). This router ID is found within an
ASBR summary LSA in both the Area 0.0.0.0 and the Area 0.0.0.1 databases.
www.juniper.net
OSPF Database Protection

This feature limits the number of LSAs that were not generated by the local router. This limit protects
the LSDB from being flooded with excessive LSAs. Once the specified maximum LSA count is
exceeded, the database typically enters the ignore state. In this state, all neighbors are brought
down, and nonself-generated LSAs are destroyed. In addition, the database will send out hellos but
ignore all received packets, not form any full neighbors, and therefore not learn about new LSAs.
However, if you had configured the warning-only option, only a warning is issued and the database
does not enter the ignore state but continues to operate as before.
Overall, this feature can be very useful if a VPN routing and forwarding (VRF) instance is configured
to use OSPF between the PE and CE routers.
www.juniper.net
OSPF Chapter 243
Dijkstra Algorithm
After a router receives a new LSA and places it into the LSDB, the router runs an algorithm known as
the Dijkstra algorithm (also called the shortest-path-first algorithm). This computation uses the
database as a data source and results in a loop-free network topology using the best metric from the
local router to all nodes in the network.
During the course of this calculation, the algorithm uses three databasesthe LSDB, the candidate
database, and the tree database. As we have explored, the LSDB is the total compilation of routing
knowledge in the network. Conceptually, it consists of multiple tuples in the form of (router ID,
neighbor ID, and cost), which describe each link in the network.
OSPF evaluates each tuple in the candidate database and delete any tuples whose neighbor ID is
currently in the tree database and whose cost to the root is greater than the entry currently in the
tree database. This evaluation is repeated until only the lowest-cost tuple per neighbor ID remains.
Chapter 244 OSPF
www.juniper.net
Dijkstra Algorithm (contd.)

When the algorithm operates, the local router moves its own local tuple into the tree database and
all tuples for its links into the candidate database. It then performs the following steps until the
candidate database is empty:
1.
For each new entry in the candidate database, determine the cost from the root to each
neighbor ID. Move the tuple with the lowest cost from the candidate database into the
tree database. If multiple tuples exist with an equal cost, choose one randomly.
2.
If a new neighbor ID appears in the tree database, move all tuples in the LSDB with a
router ID equal to the new tree entrys neighbor ID into the candidate database.
Run on a Per-Area Basis

The router calculates the Dijkstra algorithm for each LSDB present on the local router. Recall from an
earlier slide that each OSPF area maintains a separate copy of the database. These copies allow
each area to have a separate forwarding topology independent of another area.
Results Are Passed to the Routing Engine

Once the algorithm is run, the routing table on the Routing Engine receives the results of the tree
database. At this point, the Routing Engine controls the determination of whether to use any
individual OSPF route to forward traffic. The preference value assigned to each route often handles
this choice.
The action of calculating the best OSPF route prior to the route being placed into the routing table
has a consequence in regards to the filtering of routing knowledge. An individual filter (or policy)
operates on IP routes that enter the router as IP routes and are placed into the routing table. This
form of data flow is not present in OSPF because the routing information enters the router as an LSA
and is only placed into the routing table after the Dijkstra algorithm is performed. Hence, the best
method of filtering OSPF routing knowledge is to keep that information from being placed into the
database (on a per-area basis) in the first place.
OSPF does offer a limited import-policy functionality. You can use the import statement at [edit
protocols ospf] configuration hierarchy to block external routesthose learned from Type 5
and Type 7 LSAsfrom being installed in the routing table. This import policy does not, however,
prevent LSAs from being flooded. We strongly discourage the use of OSPF import policy because of
the potential for unknowingly discarding traffic.
www.juniper.net
OSPF Chapter 245
SPF Calculation Example: Part 1

In the following slides, a sample SPF calculation is displayed. This graphic shows the beginning state
of the network including the routers involved, the configured link metrics, and the LSDB. The network
and the LSDB have recently converged and the local router, RTR-A, is running an SPF calculation to
determine the shortest path to each node in the network.
Chapter 246 OSPF
www.juniper.net

RTR-A begins by moving is own local database tuple (A,A,0) into the candidate database. The total
cost from the neighbor ID to the root is calculated, which results in a 0 value. In other words, RTR-A is
directly connected to itself!
The lowest, and only, tuple in the candidate database is moved to the tree database and RTR-A
places itself on the network map.
www.juniper.net
OSPF Chapter 247

All tuples from the most recent node added to the tree database are now added to the candidate
database. Because RTR-A is the most recent entry to the tree database, all of RTR-As tuples are
moved from the LSDB into the candidate database.
All known nodes in the tree database are removed from the candidate, of which there are none. (For
example, if B was already in the tree database, the tuple (A,B,1) would be eliminated.)
The cost to each neighbor ID from the root is then calculated. It costs RTR-A 0 to reach itself and 1 to
reach RTR-B, so the total cost to RTR-B is 1. The same calculation is done for RTR-C, and the total
cost of 2 is placed into the candidate database.
The lowest cost tuple in the candidate database, (A,B,1), is now moved to the tree database, and
RTR-B is placed on the network map.
The candidate database is not empty, so the algorithm continues.
Chapter 248 OSPF
www.juniper.net

RTR-B is the most recent entry to the tree database, so all RTR-Bs tuples are moved from the LSDB
into the candidate database.
All known nodes in the tree database are then removed from the candidate. Thus, the (B,A,3) tuple is
removed because RTR-A already has the shortest path to RTR-A.
The cost to each neighbor ID from the root is then calculated. It costs RTR-B 3 to reach RTR-D, and it
costs 1 to reach RTR-B from the root. Therefore, the total cost to reach RTR-D from the root through
RTR-B is 4.
The lowest cost tuple in the candidate database, (A,C,2), is now moved over to the tree database,
and RTR-C is placed on the network map.
www.juniper.net
OSPF Chapter 249

Because RTR-C is the most recent entry to the tree database, its tuples are moved from the LSDB
All known nodes in the tree database are then removed from the candidate. Thus, the (C,A,4) tuple is
removed because RTR-A already has the shortest path to RTR-A
The cost to each neighbor ID from the root is then calculated. It costs RTR-C 4 to reach RTR-D, and it
costs 2 to reach RTR-C from the root. So the total cost to reach RTR-A through RTR-C is 6.
The lowest cost tuple in the candidate database, (B,D,3), is moved to the tree database, and RTR-D
is placed on the network map.
Chapter 250 OSPF
www.juniper.net

RTR-D, through its link to router B, is the most recent entry to the tree database. Therefore, its tuples
are moved from the LSDB into the candidate database.
All known nodes in the tree database are then removed from the candidate. Thus, the (C,D,4),
(D,B,1), and (D,C,2) tuples are removed because RTR-A already has paths to RTR-B, RTR-C, and
RTR-D. The candidate database is now empty of all tuples, so the algorithm stops at this point.
RTR-A now has a complete network map built with the total cost to each node calculated. This
information is then passed to the Junos routing table for its use.
www.juniper.net
OSPF Chapter 251
Consecutive SPF Calculations

To enhance the convergence time of an OSPF network during a time of topology changes, the
Junos OS by default allows for the SPF calculation to be run three times in a back-to-back fashion
before encountering a mandatory hold-down period. The 5-second hold-down timer used to be
hardcoded into the software but is now configurable. The timer ensures that the network can
continue to forward packets, with potentially incorrect routing knowledge, during the convergence
period. The timer also allows the routing process (rpd) to not consume excessive CPU resources at
the expense of other router functions.
Preconfigured Delay Between Calculations

A configurable timer slightly delays consecutive SPF calculations. The default timer value is
200 milliseconds (ms); you can alter it with the spf-options delay statement. The
spf-options delay statement is supported both at the global OSPF configuration hierarchy and
within an OSPF routing instance. Delay values ranging from 50 ms to 1000 ms (1 second) are
supported.
Regardless of the configuration of this timer, the mandatory 5-second hold-down timer still starts
after the third consecutive rapid SPF calculation.
A current best practice in todays networking environment is setting the delay value to be slightly
larger than the worst possible propagation delay found in your network. For example, if the delay
across the network is 200 ms, you might set the delay to 250 ms. This setting allows time for all of
the duplicate LSAs to arrive at all routers before the SPF calculation is performed.
Chapter 252 OSPF
www.juniper.net
Cost of an Interface
Prior to advertising a network into the OSPF domain, each router must determine the cost associated
with that network. Often referred to as the metric, the cost is simply what the router views as the
overhead associated with transmitting a packet on that interface. Because each OSPF-speaking
router advertises these cost values in its router LSAs, each router can determine the total cost (or
metric) to reach any destination in the network.
OSPF Default Cost

Each router uses an algorithm to determine the cost of each interfacethe calculation is
100,000,000 divided by the bandwidth of the interface. If the result of this calculation is less than 1,
it is rounded up to a value of 1. Because 100,000,000 is the same as the bandwidth of a Fast
Ethernet interface (100 Mbps), all interfaces operating at a faster bandwidth have their calculated
cost less than 1, which becomes rounded up to 1.
Set on a Per-Interface Basis

If you want to alter the automatic cost calculated by the previous formula, you can manually set the
cost for each interface. Within the interface portion of the [edit protocols ospf]
configuration hierarchy, the metric command assigns a permanent cost to that interface. Each
individual interface on the router can have a separate cost assigned to it.
www.juniper.net
OSPF Chapter 253
Change the Cost Calculation

Although each interface can have a cost assigned to it statically, assigning static costs often proves
to be an administrative hassle in all but the smallest networking environments. A middle ground is
available to administrators who would like an automatic calculation but have large bandwidth links in
their network.
The solution is to alter the values used in the bandwidth calculation. This alteration not only allows
for an automatic cost assignment but also maintains a consistent ratio across all the router
interfaces.
Reference Bandwidth
To alter the calculation values, use the reference-bandwidth command within the [edit
protocols ospf] configuration hierarchy. The value entered has a value in bits per second. You
can use the standard Junos shortcut notations of k (kilobits per second), m (megabits), and g
(gigabits). The entered value becomes the new numerator value in the bandwidth calculation. As
noted on the slide, you still can assign a metric statically to an individual interface.
Chapter 254 OSPF
www.juniper.net
Advertisement of Metric Values

After the OSPF process on a router decides what metric to assign to each interface, that information
is flooded into the OSPF domain within either a Type 1 LSA or a Type 2 LSA. Because these LSAs
have an area flooding scope, each router in the OSPF area receives a copy of the metric values.
SPF Calculations
After receiving a new LSA from another router in the area, the local router performs an SPF
calculation using all the values contained in the router and network LSAs. As mentioned on a
previous slide, the cost is calculated from the root node to every other node in the network using the
metric cost of the outgoing interfaces.
Routers Can Disagree

Because each individual router performs a separate SPF calculation, two routers on either side of a
link can disagree on the metric of that link. The example on the slide shows that each router has
decided upon a different metric value for its attached links. This discrepancy results in the R1 router
calculating a total cost of 45 to reach the R4 router, while the R4 router calculates a total cost of 60
to reach the R1 router.
While the configuration of different metrics for a single link does not affect the operation of OSPF,
asymmetric routing might occur within the network. Asymmetric routing might cause response delays
for some end users and make it challenging for network administrators to troubleshoot the network.
www.juniper.net
OSPF Chapter 255
Avoid Transit Traffic

OSPF borrows the overload concept from the IS-IS protocol. Its function is to advertise information
into the OSPF area, but it is not to be used for transit traffic, if possible. This function can be useful in
two situationswhen a router must be taken out of the network for maintenance, and when the
router has many BGP peers. In the first case, traffic should avoid the router because it can
compromise its ability to forward traffic. In the second case, a network administrator might want the
router to establish its BGP peering sessions fully before handling transit traffic.
Because the overload concept is not native to OSPF, the software is modified to allow for this
functionality. When you configure an OSPF-speaking router for overload, the metrics for all transit
interfaces are set to the maximum value of 65,535. The overload router floods these LSAs into the
network, where an SPF calculation is performed in each router. The large metric values generally
ensure that transit traffic through the overload router uses alternative paths through the network.
Unlike IS-IS, traffic transits the overload router if no alternative path exists to a given destination.
Overload Settings
You can turn on the overload setting, turn it off as a permanent value, or have a timer associated
with it. If the timer is omitted, the metric values are changed when you commit the configuration. The
values will remain until you remove the overload setting from the configuration and commit it again.
However, if you assign a timer value, the metrics are not changed automatically. The timer
associated with the overload setting only initializes when the routing protocol daemon (RPD)
initializes. This timer can run from 601800 seconds. When the timer expires, the metrics return to
normal in the router LSAs, but the configuration still contains the overload option.
Chapter 256 OSPF
www.juniper.net
Case Study
Service provider networks are typically built with multiple paths from ingress and egress points for
redundancy. During maintenance operations on a router, preventing the router from receiving and
forwarding transit traffic can be beneficial. The overload feature provides this function.
In the graphic, R2 is scheduled for maintenance. An alternate path exists through R3. Once R2 is put
in overload mode, the other routers will be notified and transit traffic will traverse R3. Any traffic
destined for networks that terminate on R2 will be forwarded to R2.
www.juniper.net
OSPF Chapter 257
OSPF Router ID
Each OSPF-speaking router in a network must select a 32-bit value to use as the router ID (RID) of
the router. This RID uniquely identifies the router within the OSPF domain. It is transmitted within the
LSAs used to populate the LSDB and is used to calculate the shortest-path tree using the method
described on a previous slide.
It is very important in a link-state network that no two routers share the same RID value. If two
routers share the same RID value, the LSDB might not be consistent on all routers. This
inconsistency happens because the RID is one method to verify if an LSA is already present in the
database. Therefore, new critical information from one of the routers is never present in all the
routers. In addition, because the Dijkstra calculation uses the RID, it is possible that an individual
router might not generate a loop-free shortest path topology. This scenario could have a disastrous
affect on IP routing.
Router ID Is the Primary Interface

Whenever the RPD restarts on a Juniper Networks router, the selection of the routers primary
interface takes place. This selection states that the primary interface will be the smallest non-127/8
IP address configured on the loopback interface. If there is only a 127/8 address configured on the
loopback, the router will choose the first available IP address on an interface as the Router ID.
Chapter 258 OSPF
www.juniper.net
Router ID Is the Primary Interface (contd.)

Because the OSPF routing process uses an IP address as the RID, its selection can have a very
important consequence. If the router addressing changes, the OSPF RID might also change, and a
duplicate RID situation might arise. The hazards of this type of situation are outlined in the previous
section.
Manual Router ID Selection

To avoid possible problems with the OSPF RID changing, you can set the router ID manually within
the Junos configuration. Within the [edit routing-options] configuration hierarchy, the
router-id command assigns a 32-bit value to the RID. By setting this value, the process of using
the routers primary interface value is not used.
www.juniper.net
OSPF Chapter 259
Loopback Is Often the Router ID

In most networks, routers will have a unique IP address configured as their loopback address. As
such, the loopback address automatically becomes the router ID of the router, unless configured
manually using the router-id command.
Automatic Advertisement of the Router ID

As of release 8.5, the Junos OS no longer automatically advertises your loopback IP address, which
might also be your RID, into the network. However, keep several important points in mind when
configuring your router.
If you do not configure interface lo0.0 within an OSPF area, the loopback IP address will not
be advertised. Thus, the loopback address will not be reachable.
When you configure interface lo0.0 within a specific OSPF area, the loopback IP address will
then only be advertised in the router LSA for that specific area. The ABR attached to Area 2 has its
loopback configured within Area 0. It then advertises the loopback in its Area 0 router LSA only. The
address is still visible to Area 2, but it is encoded in a summary LSA as all the other backbone routes
are.
Chapter 260 OSPF
www.juniper.net
OSPF Authentication
www.juniper.net
OSPF Chapter 261
Authentication
The four different forms of authentication that the Junos OS supports are none, simple, MD5, and
IPsec. IPsec was added as of the Junos OS release 8.3. IPsec is configured at the [edit
protocols ospf area area-id interface interface-name] hierarchy using the set
ipsec-sa name; command. See the Junos OS Routing Protocols Configuration Guide for more
information.
Authentication Default
The default operation of the OSPF process is the none mode. Thus, no authentication key is
configured on any interface.
Plain-Text Passwords
With simple authentication type configured, each OSPF packet includes a plain-text password. This
password can be captured easily through a packet analysis system. Therefore, although this
password protects against an inadvertent configuration, it does not provide any security.
Chapter 262 OSPF
www.juniper.net
Encrypted Checksum
To provide better security in an OSPF network, we recommend that you use an authentication type of
MD5. MD5 includes an encrypted checksum in all OSPF packets instead of a simple-text password.
Each OSPF-speaking router uses the same MD5 algorithm to calculate the checksum value, so
interoperability and a correct result can be virtually guaranteed.
Authentication Keys
The actual password to verify and authenticate packets is contained within the authentication
command. You can configure each individual interface with an authentication value.
Key ID Values
You configure each individual interface with a key value. All interfaces in the area might share the
same key value, or each interface might contain a separate value.
www.juniper.net
OSPF Chapter 263
Multiple Key Values

When configuring multiple key vales you can also specify a start time for the router to begin using a
new MD5 key. This setting aids in the graceful transition from one password key to another. The
example on the slide displays the format of the start-time command. When the local routers
time reaches the specified value, the router begins to transmit all OSPF packets using the new key ID
value and password. To begin using a new MD5 key ID immediately, you can use the keyword of now
in place of a specific time and date. The router automatically places the current system time in the
configuration for you.
Chapter 264 OSPF
www.juniper.net
View Authentication Information

The show ospf interface detail command displays the type of authentication used on the
interface with the Auth type output. Displaying this output occurs regardless of whether you use
per-area or per-interface authentication in your network.
The possible values displayed in the output are None, Password, and MD5. When MD5
authentication is in use, the router also displays the current key ID value and the time which that ID
was first used. If start-time is not specified in the configuration, the value of the Start time
field in the show ospf interface detail command output is the UNIX epoch (1970 Jan 1
00:00:00 UTC).
www.juniper.net
OSPF Chapter 265
Authentication Mismatch
OSPF routers must agree on the authentication method to be neighbors. Use the traceoptions
commands if you suspect there might be an authentication mismatch.
The log shows that the local router is ignoring an OSPF packet from 172.20.77.1 due to an
authentication mismatch. No authentication method is configured on the local router, so the type is
none. The remote router has MD5 authentication configured.
Chapter 266 OSPF
www.juniper.net
This Chapter Discussed:
www.juniper.net
OSPF LSAs;
The flooding of LSAs throughout the network;
The SPF algorithm; and
The key difference between OSPFv2 and OSPFv3.
OSPF Chapter 267
Review Questions
1.
2.
3.
Chapter 268 OSPF
www.juniper.net
Lab 1: OSPF Multiarea Networks

The slide lists the objectives for this lab.
www.juniper.net
OSPF Chapter 269
Chapter 270 OSPF
www.juniper.net

Routing
Chapter 3: OSPF Areas
OSPF area types and operations;
The configuration of various OSPF area types; and
The summarization and restriction of routes.
Chapter 32 OSPF Areas
www.juniper.net
Review of OSPF Areas

www.juniper.net
OSPF Areas Chapter 33
OSPF Scalability
With a link-state protocol, flooding link-state update packets and running the shortest-path-first (SPF)
algorithm consumes router resources. As the size of the network grows and more routers are added
to the autonomous system (AS), this use of resources becomes a bigger and bigger issue. This issue
stems from the RFC requirement that all OSPF routers share an identical link-state database (LSDB).
Eventually, the routers spend so much time flooding and running the SPF algorithm that they cannot
route data packets. Clearly, this scenario is not optimal.
Shrinking the Link-State Database

The solution to this problem (and link-state protocol scalability in general) is to reduce the size of the
LSDB. You can reduce the size of the LSDB using multiple OSPF areas rather than a single area that
encompasses the entire AS. Note that the type of OSPF areas used is important when attempting to
shrink the size of the LSDB. We discuss the various OSPF area types on a subsequent slide.
In addition to adding new OSPF areas that restrict LSA flooding, you can also perform route
summarization on the borders between OSPF areas. Route summarization has two key benefits:
It reduces the size of the LSDB; and
It can hide some instabilities in one OSPF area from all other OSPF areas.
For route summarization to be effective, you must carefully plan the addressing within your OSPF
network so that subnets can be more easily summarized. Complete coverage of route summarization
is beyond the scope of this course.
www.juniper.net
OSPF Areas
Using OSPF, you can segment an AS into smaller groups known as areas. Using areas achieves the
OSPF hierarchy that can facilitate growth and scalability. You can constrain LSA flooding by using
multiple areas, which can effectively reduce the size of the LSDB on an individual OSPF router. Each
OSPF router maintains a separate and identical LSDB for each area to which it is connected.
To ensure correct routing knowledge and connectivity, OSPF maintains a special area known as the
backbone area. The backbone area is designated as Area 0.0.0.0 (or simply Area 0). All other OSPF
areas must connect themselves to the backbone area. By default, all data traffic between OSPF
areas transits the backbone. You can alter this default behavior and eliminate the requirement of all
interarea traffic transiting Area 0.0.0.0 by configuring a multiarea adjacency on the same logical
interface. The multiarea adjacency feature is documented in RFC 5185 and is discussed in the next
chapter.
www.juniper.net
OSPF Routers
OSPF routers can perform several different roles within an OSPF domain. The following list shows the
common types of OSPF routers along with a brief description:
Area border router (ABR): An OSPF router with links in two areas, the ABR is responsible
for connecting OSPF areas to the backbone. It transmits network information between
the backbone and other areas.
Autonomous system boundary router (ASBR): An OSPF router that injects routing
information from outside the OSPF AS, an ASBR is typically located in the backbone.
However, the OSPF specification allows an ASBR to be in other areas as well.
Backbone router: Defined as any OSPF router with a link to Area 0 (the backbone), this
router can also be an internal or area border router depending on whether it has links to
other, nonbackbone areas.
Internal router: An internal router is an OSPF router with all its links within an area. If
that router is located within the backbone area (Area 0.0.0.0), it is also known as a
backbone router.
www.juniper.net
OSPF Area Types

The slide introduces some OSPF area types and illustrates the relationship between these areas,
including the types of routes exchanged between them. On the slide, all areas are connected directly
to the backbone. In the rare situations where a new area is introduced that cannot have direct
physical access to the backbone, you can configure a virtual link. Virtual links are covered in the next
chapter.
OSPF classifies different types of routing information as follows:
Intra-area or internal routes: Routes that are generated from within an area, where the
destination belongs to the area;
Interarea or summary routes: Routes that originate from other areas; and
External routes: Routes that originate from other routing protocols, or different OSPF
processes, and that are injected into OSPF through redistribution.
www.juniper.net
OSPF Area Types (contd.)

Stub areas are areas through which, or into which, AS external advertisements are not flooded (LSA
Type 4 and Type 5). You might want to create stub areas when much of the topological database
consists of AS external advertisements. Doing so reduces the size of the topological databases and,
therefore, the amount of memory required on the internal routers in the stub area.
When you configure an ABR for stub area operation, a default route is normally advertised in the
place of the external routes that are blocked from stub areas. The default route provides routers in
the stub area with reachability to external destinations. In the Junos operating system, ABRs require
explicit configuration for default route generation.
Note that you cannot create a virtual link through a stub area, and a stub area cannot contain an AS
boundary router.
A stub area with no-summaries is a stub area that receives only the default route from the backbone.
ABRs do not flood LSA Type 3, Type 4, or Type 5 into totally stubby areas.
An OSPF stub area has no external routes in it, so you cannot redistribute routes from another
protocol into a stub area. A not-so-stubby-area (NSSA) allows external routes to be flooded within the
area. These routes are then leaked into other areas. However, external routes from other areas still
do not enter the NSSA. (ABR does not flood LSA Type 4 and Type 5 into an attached NSSA.)
www.juniper.net
Stub Area Operation

www.juniper.net
Default LSA Flooding Scopes

As discussed in a previous chapter, each LSA in the OSPF protocol has a specific scope within which
it can be flooded. The slide graphically displays those flooding scopes.
Note that LSA Types 1 and 2 are generated within each area. Because these LSAs have an area
flooding scope, they remain within their own particular area and are not seen in other areas. The
ABR places the routing information contained within these LSAs into a Type 3 LSA and forwards it
across the area boundary. In addition, existing Type 3 LSAs within the backbone are forwarded into
the non-backbone areas to provide routing information to those routers. This process results in
Type 3 LSAs within every area that represent all OSPF internal routes. Within Area 1, for example,
Type 3 LSAs exist that represent Area 0, Area 2, and Area 3.
In the diagram, two ASBRs inject routes into the OSPF domain. The AS external LSAs (Type 5)
representing those routes have a domain flooding scope (with the exception of stub areas). As such,
they exist within each OSPF area. The OSPF routers use either the router LSA or the ASBR summary
LSAs (Type 4) to gain knowledge of how to best route to the advertising ASBRs. Much like the Type 3
LSAs, the ASBR summary LSAs have area scope, so they are bound by the area border. However, the
ABR has the capability to regenerate and forward Type 4 LSAs across area boundaries to provide the
required knowledge of the best routes to each ASBR. This capability leads to Type 4 LSAs for Area 0
and Area 3 being within all the OSPF areas in the network.
www.juniper.net
Reduce LSDB Size

The operation of an OSPF stub area reduces the size of the LSDB within that area by eliminating AS
external routing information. When all of an areas routers agree to operate in stub mode, the ABR
stops forwarding Type 5 external LSAs into the area. In addition, the ABR also stops generating Type
4 summary LSAs, because they are no longer needed because of the suppression of Type 5 external
LSAs.
ABR Provides Reachability

The routers within the stub area still might require IP reachability to the external routes they no
longer have in their databases. A 0.0.0.0/0 default route generated by the ABR in the area
accomplishes this reachability. Within the Junos OS, the advertisement of a default route does not
occur automatically, which allows for better control of which ABR, if any, should be used for outbound
traffic flows.
No ASBRs in a Stub Area

Because the definition of a stub area does not allow the use of external LSA information within the
area, no functional AS boundary routers can exist within a stub area. If any ASBR configuration
exists, the router will generate one or more Type 5 LSAs and place them into its local database.
However, these external LSAs cannot be sent out any interfaces supporting stub operation.
www.juniper.net
No Virtual Links in a Stub Area

For similar reasons, a stub area cannot support a virtual link because the area attached to the
backbone through the stub area might require external LSA information. Because the transit routers
cannot forward the Type 5 LSAs, the far-end area would not receive the correct information.
www.juniper.net
Stub Area Flooding Scopes

In this example, Area 1 is now configured as a stub area, which causes the ABR of Area 1 to stop
forwarding the Type 5 LSAs from Area 0 and Area 3. Because the routers within Area 1 no longer
have the external LSA information, they also no longer require the knowledge of any ASBRs in the
network. As such, the Area 1 ABR stops generating Type 4 LSAs for reachability of the ASBRs in
Area 0 and Area 3.
www.juniper.net
Further Reduces LSDB Size

The operation of an OSPF stub area with no summaries further reduces the size of the LSDB within
that area by also omitting Type 3 summary LSAs. This behavior has the effect of the routers within
the area only having Type 1 router and Type 2 network LSAs in their databases. This type of area is
known as a Totally Stubby Area because a default route is now needed to reach AS external and
interarea prefixes.

The routers within a stub area with no summaries still might require IP reachability to interarea and
external routes that are no longer represented in their databases. A 0.0.0.0/0 default route
generated by the ABR in the area accomplishes this reachability. Within the Junos OS, this
advertisement is a manual step for the network administrator that allows for better control of which
ABR, if any, should be used for traffic flowing to interarea or external destinations.
No ASBRs in a Stub Area

As before, no functional AS boundary routers can exist within a stub area, regardless of whether
summaries are permitted.
No Virtual Links in a Stub Area

Like a stub area, a stub area with no summaries cannot support virtual links.
www.juniper.net
Flooding Scopes for Stub Area with No Summaries

The slide shows that Area 1 is still configured as a stub area as shown on a previous slide. In
addition, Area 3 has now been configured as a stub area with no summaries.
As discussed previously, the ABR of Area 3 has stopped forwarding the Type 5 LSAs from Area 0 and
has also stopped generating the Type 4 LSAs from Area 0. In addition, Area 3s ABR also no longer
generates Type 3 LSAs for the other OSPF areas. This fact has left the LSDB for Area 3 quite small.
Another interesting phenomenon has occurred as well. Recall that one of the Area 3 routers
previously acted as an ASBR. While the ASBR portion of that routers configuration did not change,
its operation changed into a stub network. This change causes the router to generate Type 5 LSAs
and place them into its own database. However, because all interfaces are now operating in stub
mode, the router has no ability to forward them. As such, notice that the entire network has lost
knowledge of the Type 5 LSAs from Area 3.
www.juniper.net
Stub Area Configuration

www.juniper.net
Configuration on All Routers

For an OSPF stub area to function successfully, you must configure each router in that area to treat
the area as a stub. This configuration alters the E bit setting in the options field of the OSPF hello
packet to notify all neighbors that the local router does not support external LSAs. An OSPF router will
only form an adjacency with another router when the E bit values matchhence, the requirement
that all routers agree on whether the area is a stub area.
ABR Injects a Default Route

The ABR of the stub area can optionally inject a 0.0.0.0/0 default route into the stub area. Using the
default-metric command accomplishes this task, which causes the ABR to generate a Type 3
summary LSA advertising the 0.0.0.0/0 route with the associated metric attached.
The need to manually assign the metric before the default route is generated provides additional
control. The administrator can control how, or if, traffic will leave the stub area by controlling which (if
any) ABRs advertise a default route as well as the metric for that route.
www.juniper.net
Configuration on ABR Only

Because the ABR generates new Type 3 summary LSAs for injection into the areas it serves, you
configure the no-summaries option only on ABR routers by adding the no-summaries command
to the stub areas stanza. Because non-ABR routers in the area do not require the suppression of
Type 3 LSAs, you do not have to perform this configuration on those routers.

The ABR of an area configured as a stub with no summaries can optionally inject a 0.0.0.0/0 default
route into the stub area. Use the default-metric command to accomplish this task, as
described on previous pages.
www.juniper.net
NSSA Operation
www.juniper.net
Altering the Stub Area Behavior

Much like a stub area, the operation of an OSPF NSSA assists the routers within that area by
reducing the size of the LSDB. The main difference between a stub area and an NSSA is that external
routing information, in the form of a Type 7 LSA, is allowed within the NSSA area. The ABR with the
highest router ID converts the Type 7 LSAs into Type 5 LSAs and forwards them towards the
backbone as if they had originated from an ASBR in a non-stub area. This process keeps knowledge
of the NSSA contained within the area.

The routers within the NSSA might require IP reachability to the external routes from the backbone
they no longer have in their databases. A 0.0.0.0/0 default route generated by the ABR in the area
can accomplish this reachability. Within the Junos OS, this advertisement is a manual step for the
network administrator, which allows for better control over which ABR should be used for outbound
traffic flows. For an NSSA, the default route will be carried in a Type 7 LSA by default. If the area is an
NSSA with no-summaries the default route will be in a Type 3 LSA.
No Virtual Links in an NSSA

In a similar fashion to a stub area, an NSSA cannot support a virtual link. Again, the area attached to
the backbone through the NSSA area might require external LSA information. Because the transit
routers cannot forward the Type 5 LSAs, the far-end area does not receive the correct information.
www.juniper.net
NSSA Flooding Scopes

Area 3 is now configured as a not-so-stubby area. This configuration causes the ABR of Area 3 to
stop forwarding the Type 5 LSAs from Area 0. Because the routers within Area 3 cannot use the
external LSA information, they also do not require the knowledge of any ASBRs in the rest of the
network. As such, the Area 3 ABR stops generating Type 4 LSAs from Area 0.
Recall that an ASBR is configured within Area 3. To allow that routing information to be propagated to
the rest of the OSPF domain, the ASBR generates a Type 7 LSA for these routes. Each of the routers
in Area 3 now can forward these LSAs because they each are configured as an NSSA router. When
the information reaches the Area 3 ABR, it performs a Type 7 LSA to Type 5 LSA conversion and
injects the Type 5 LSA into the backbone. All other OSPF routers in the domain use the Type 5 LSA as
normal and have no knowledge that the routes originated within an NSSA.
www.juniper.net
Behaves Like Stub Area with No Summaries

The operation of an OSPF NSSA with no summaries assists the routers within that area by further
reducing the size of the LSDB. In addition to the ABR not forwarding Type 5 external LSAs, and not
generating Type 4 summary LSAs, the ABR also stops flooding Type 3 LSAs into the NSSA. This
process has the effect of the routers within the area having only Type 1 router, Type 2 network, and
Type 7 (NSSA) LSAs in their databases.

The routers within the NSSA with no summaries might require IP reachability to routes they no longer
have in their databases. A 0.0.0.0/0 Type 3 LSA is generated by the ABRs to provide this reachability,
when so configured. The advertisement of a default route is a manual step for the network
administrator, which allows for better control over which ABR (if any) should be used for outbound
traffic flows.
No Virtual Links in an NSSA with No Summaries

Like a regular NSSA, an NSSA with no summaries cannot support a virtual link.
www.juniper.net
NSSA with No Summaries Flooding Scopes

Area 3 is now configured as an NSSA with no summaries. In addition to the functionality described
on a previous slide, the ABR of Area 3 stops generating Type 3 summary LSAs from Area 0.
www.juniper.net
NSSA Configuration
www.juniper.net
Configuration on All Routers

To operate an OSPF NSSA successfully, you must configure each router to participate. This
configuration alters the N/P bit setting in the Options field of the OSPF hello packet to notify all
neighbors that the local router does not support Type 5 external LSAs, but does support Type 7
external LSAs. An OSPF router only forms an adjacency with another router when the N/P bit values
matchhence, the requirement that all routers perform the configuration.

The ABR of the NSSA can optionally inject a 0.0.0.0/0 default route into the area. Within the
default-lsa configuration hierarchy, the default-metric command accomplishes this
injection. The command causes the ABR to generate a Type 7 NSSA External Links LSA to advertise
the 0.0.0.0/0 default route into the area with the configured metric. If the NSSA is configured with
no-summaries a Type 3 Summary LSA is advertised.
www.juniper.net
Configuration Only on the ABR

Because it is the job of the ABR to generate new Type 3 summary LSAs into the area, configuration
takes place only on this router to create a no-summaries area. To configure an ABR to support a no
summaries configuration, apply the no-summaries command to the NSSA setting within the ABR.
Because all other routers in the area do not require the suppression of a Type 3 LSA, you do not need
configuration on those routers.

The ABR of the NSSA no-summaries area can inject a 0.0.0.0/0 default route into the NSSA when
the default-metric command is issued, which causes the ABR to advertise a default route with
the configured metric.
Type 3 LSA Generated by Default

When the NSSA is configured with the no-summaries command, the 0.0.0.0/0 default route is
advertised using a Type 3 summary LSA. The type-7 command within the default-lsa
hierarchy causes the ABR to generate a Type 7 LSA advertising the 0.0.0.0/0 route with the
associated metric.
www.juniper.net
Type 3 LSA Generated by Default (contd.)

The Type 7 LSA is advertised using an External Type 1 (E1) metric, which means that all routers
calculate the cost to the ABR and add to it the advertised default metric. You can alter this behavior
with the metric-type command within the default-lsa hierarchy. The Type 7 LSA is then
advertised using an External Type 2 (E2) metric, which means that each area router uses only the
advertised metric of the route.
www.juniper.net
Route Summarization
This slide highlights the topic we discuss next.
www.juniper.net
Local Area Routes Forwarded to Area 0.0.0.0

The default operation of an ABR is to generate a Type 3 summary LSA into the backbone area for each
Type 1 and Type 2 LSA in the LSDB. The configuration of a stub or stub area with no summaries does not
affect this operation because a stub configuration only alters information that enters the nonbackbone
area.
Route Summarization
To reduce the size of the LSDB in Area 0.0.0.0 (and other remote OSPF areas), you can configure the
ABR not to perform its default one-for-one mapping function, which is accomplished using an
address range statement on the ABR with the area-range command. All Type 1 and Type 2 LSAs
that fall within that address range will no longer be advertised individually into the backbone.
Instead, a single Type 3 summary LSA is advertised. The metric associated with this summary route
will be equal to the highest metric associated with the individual contributing routes.
Because only the ABR performs this mapping function, you configure the area-range command
on ABR routers only.
www.juniper.net
Type 7 External Routes Forwarded to Area 0.0.0.0

The default operation of the ABR for Type 7 LSA routes local to a non-backbone area is to generate a
single Type 5 external LSA for each Type 7 LSA in the LSDB. The configuration of an NSSA or an NSSA
area with no summaries does not affect this operation because an NSSA configuration only alters
information that enters the nonbackbone area.
Route Summarization
To reduce the size of the LSDB in Area 0.0.0.0 (and other remote OSPF areas), you can configure the
ABR not to perform its default one-for-one mapping function. You can configure an address range on
the ABR by using the area-range command within the NSSA configuration hierarchy. All Type 7
LSAs that fall within that address range are not advertised individually into the backbone. Instead, a
single Type 5 external LSA is advertised.
Because only the ABR performs this mapping function, only the ABR is configured with the
area-range command.
Note that the area-range command referenced on this page is specific to the NSSA configuration
hierarchy and affects only Type 7 LSA routes. The area-range command discussed in the previous
slide was within the area hierarchy itself and affected Type 1 and Type 2 LSA routes. The
configuration can have these two commands in place at the same time, and they will summarize
different aspects of the local area routing domain.
www.juniper.net
Suppressing Routes
The default action of the area-range command causes the generation of a single Type 3 summary
LSA into the backbone for all prefixes that fall within the defined range. You can configure the ABR
with the restrict keyword to block one or more prefixes from advertisement into the OSPF
backbone. Such a configuration will prevent routing information from each Type 1 and Type 2 LSA
that falls within the address range from being advertised to the backbone, which in turn can block
connectivity to those prefixes for routers in other areas.
Use the restrict function when you want to prevent interarea routing, or when you want a default
route to be used instead of the more preferred summary information that would otherwise be
generated.
Because only the ABR is responsible for this mapping function, you configure only ABR routers with
the area-range restrict command.
www.juniper.net
The restrict Command Suppresses Routes

The default action of the area-range command is to send a single Type 5 external LSA into the
backbone. This functionality already alters the default OSPF protocol operation. You then can configure
the ABR additionally with the keyword restrict. This keyword prevents routing information from each
Type 7 LSA that falls within the address range from being advertised to the backbone at all.
Because only the ABR is responsible for this mapping function, you must configure only the ABR with the
area-range restrict command.
www.juniper.net
www.juniper.net
OSPF area types and operations;
The configuration of various OSPF area types; and
The summarization and restriction of routes.
Review Questions
1.
2.
3.
4.
www.juniper.net
Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization

The slide provides the objectives for this lab.
www.juniper.net
www.juniper.net

Routing
Chapter 4: OSPF Case Studies and Solutions
The configuration of OSPF virtual links;
The configuration of OSPF multiarea adjacencies; and
OSPF external reachability.
Chapter 42 OSPF Case Studies and Solutions
www.juniper.net
Virtual Links
www.juniper.net
OSPF Case Studies and Solutions Chapter 43
Area Border Router

Technically speaking, an area border router (ABR) is a router that connects two OSPF areas together.
In normal cases, ABRs will be connecting Area 0 to other areas. However, networks can actually
function without an Area 0 and with only two areas. So, is this router an ABR? How does OSPF
indicate its ABR status to other routers?
www.juniper.net
The Router LSA

An OSPF router is an ABR when the B bit is set in the router link-state advertisement (LSA), also
referred to as a Type 1 LSA. The slide indicates this setting by the bits field of 0x1. The other bits in
the field are used to indicate virtual links or autonomous system boundary routers (ASBRs).
www.juniper.net
Summary LSA
One of the primary jobs of the ABR router is to generate summary LSAs into its attached areas. This
function provides interarea connectivity for the non-ABR routers.
www.juniper.net
Adding a Third Area

To change things up a bit, connect another area to R5. In this case, Area 0 is connected to R5. As
soon as R5 establishes an adjacency with Area 0, routes to R1 and R2 disappear from the routing
table.
www.juniper.net
Summary LSAs Are Still Present

Building on the previous slide and issuing a show ospf database netsummary command, the
summary LSAs are present on R5 for R1 and R2. R5 is also generating summary LSAs for its
attached areas as designated by the asterisk (*) in the output.
SPF Does Not Install

Even though the LSAs are present in the OSPF database, a show ospf route command does not
show the routes to R1 and R2. The SPF calculation is removing those entries in its decision tree. The
loop detection mechanism in OSPF causes this action. Essentially, R5 will only accept summary LSAs
from routers from the backbone. Because an ABR would have a full view of each connected area,
and it does not see R1 and R2, it ignores the summary LSA.
www.juniper.net
Technical OSPF
From the OSPF RFC 2324:
Any router running OSPF attached to multiple areas is known as Area Border Router
(ABR). An ABR will have topological information of all attached areas and will run SPF for
each area. (Section 3.3)
Technically, you can create a multiarea OSPF network with no Area 0. However, we do not
recommend this configuration, because SPF will process all LSAs in all areas and the ABR loses its
OSPF loop detection mechanism.
Functional OSPF
In practice, an ABR should always be connected to Area 0. Because the ABR calculation is similar to
a distance vector protocol when processing the Type 3 LSA, a loop avoidance mechanism must be in
place. This requirement is met with an Area 0 and a rule that SPF will only process LSAs within that
area database.
www.juniper.net
Acquisitions and Mergers

Companies are acquired or merged with other companies every day. These mergers present many
interesting challenges, including how to combine the IP networks into one network. For example,
imagine two companies running OSPF that must merge networks. For OSPF to work correctly, each
company must connect their respective Area 0s together to form a single contiguous backbone. The
easiest solution will be new physical connections between the routers in each company. However,
this solution is often easier said than done, and time can be a deciding factor. For these cases, a
temporary solution such as virtual tunnels or virtual links can be deployed.
www.juniper.net
Case Study
In this case study, ISP A has acquired ISP B. Both networks are running multiarea OSPF and they
must get both networks communicating with each other.
www.juniper.net
Integration Case Study

During the acquisition phase, an integration team is formed to look at all facets of combining the two
companies, including their OSPF networks. The determination is that connecting both Area 0
networks together with physical connections is not a viable short term option. An alternative solution
must be used.
www.juniper.net
Initial Physical Connection

The first step is to establish some physical connectivity between the two companies. In this case, the
integration team chose to connect ISP As A6 router and ISP Bs B4 router. For now, the new interface
will be configured in Area 10 on the A6 and B4 routers.
www.juniper.net
Connectivity Issues
As soon as the physical connection is created, limited connectivity is achieved. For example, the B6
router can now reach the A1 router in ISP As Area 0. However, ISP As Area 0 routers cannot reach
ISP Bs Area 0 routers. The cause of this limited connectivity is the lack of a contiguous Area 0
backbone.
www.juniper.net
Virtual Tunnels
One solution to the connectivity problem is to create a virtual tunnel between the two backbone
areas of the companies. This feature, known as a virtual link, provides a logical connection between
areas. Essentially, OSPF packets are tunneled through a transit area to establish an OSPF adjacency
and logically connect the two areas together. This establishes full connectivity between the two
companies.
Remember that a virtual tunnel is a control plane feature only. SPF will still calculate the shortest
physical path between two points, which might not be the same path as the virtual tunnel. This
calculation could create some confusion when troubleshooting, which is one of the primary reasons
virtual tunnels are not considered long term solutions.
www.juniper.net
Virtual Link Established

In this case, a virtual link is established between ABRs in each company. These ABRs must be
attached to Area 0.
www.juniper.net
Virtual Link Configuration

The configuration of a virtual link takes place within the Area 0.0.0.0 portion of the OSPF hierarchy.
The virtual-link command itself requires both a transit area and a neighbor ID to be
configured. The transit area is the OSPF area through which you configure the virtual link. The
neighbor ID is the 32-bit router ID (RID) of the router on the far end of the virtual link. Once each side
completes this configuration, each router begins to send unicast OSPF traffic towards the far-end
router to complete the link setup and form an adjacency.
Virtual Link as an Interface

Once the two ends of the link can communicate, the virtual link becomes an operational OSPF
interface. It appears in show commands and within the OSPF link-state database (LSDB). It is always
noted in a format of vl-neighbor-id, where vl denotes it as a virtual link, and the
neighbor-id is the RID of the far-end router.
www.juniper.net
Contiguous Area 0
Once the neighbor is established over the virtual link, connectivity is restored, all LSAs are
processed, and routes to each company are installed into the routing table.
www.juniper.net
OSPF Multiarea Adjacencies

www.juniper.net
Multiarea Adjacencies
By default, a single interface can belong to only one OSPF area. However, in some situations, you
might want to configure an interface to belong to more than one area. Doing so allows the
corresponding link to be considered an intra-area link in multiple areas and to be preferred over
other higher-cost intra-area paths. For example, you configure an interface to belong to multiple
areas with a high-speed backbone link between two ABRs to enable you to create multiarea
adjacencies that belong to different areas.
As defined in RFC 5185, OSPF Multi-Area Adjacency, the ABRs establish multiple adjacencies
belonging to different areas over the same logical interface. Each multiarea adjacency is announced
as a point-to-point unnumbered link in the configured area by the routers connected to the link. For
each area, one of the logical interfaces is treated as primary, and the remaining interfaces that are
configured for the area are designated as secondary.
www.juniper.net
Case Study
The slide displays the case study topology.
www.juniper.net
Link Failure
In normal operation, if a link failure occurred between R1 and R3, traffic from R1 to R3 would flow
from R4 to R2 and then to R3, which creates three hops to reach a router that was previously one
hop away.
www.juniper.net
Link Failure with Multiarea Adjacency

With multiarea adjacency configured, a hop to reach R3 is eliminated.
www.juniper.net
Adjacency Verification
Verify adjacencies with the show ospf neighbor command.
Normal Trace
For the case study, R1 is one hop away from R3.
www.juniper.net
Disable the Interface

To test normal operations, disable the interface between R1 and R3.
Trace Under Link Failure

The trace from R1 to R3 now takes a 3 hop path.
www.juniper.net
Multiarea Adjacency Configuration

To configure multiarea adjacency in the Junos operating system, configure a secondary logical
interface for an OSPF area using the secondary statement. Any logical interface not configured as
a secondary interface for an area is treated as a primary interface for that area. A logical interface
can be configured as a primary interface for only one area. For any other area in which you configure
the interface, you must configure it as a secondary interface.
Point-to-Point Interface
Interface ge-1/0/4.1100 now has two OSPF links, however, the secondary link show up as a
point-to-point interface.
www.juniper.net
Adjacency Is Formed
Two adjacencies are now formed over ge-1/0/4.1100 for Area 0 and Area 100.
Trace with Multiarea

With the multiarea adjacency feature configured, the trace now requires only 2 hops, compared with
the default case of 3 hops.
www.juniper.net
External Reachability
www.juniper.net
OSPF Default Export Policy

Recall that any policy applied to OSPF affects only external routes that are either Type 5 or Type 7
LSAs. Because OSPF does not inject any external routes by default, the default export policy is to
reject all routes. In other words, no external routes are send without a routing policy applied.
Route Redistribution
For route distribution to occur, an export policy must be written and applied. Because external routes
in OSPF have an interarea flooding scope, the policies are applied globally. This feature allows
external routes to be sent into all areas that allow it. When an external route is brought into OSPF, it
appears as an external Type 5 LSA of Type 2. If an external LSA Type 1 must be configured, you can
modify it with a policy.
www.juniper.net
Mutual Redistribution
Special care must be taken when redistribution is configured in a network. When multiple
redistribution points are present sub-optimal routing and loops could occur. Generally, if the source
route has a lower preference than the protocol into which it is being redistributed, no issues occur.
However, when the source route has a higher preference, issues can occur. Several methods exist to
resolve these issue, but the easiest method usually involves modifying route preference values.
www.juniper.net
Case Study Topology

The slide displays the case study topology that will be used in subsequent slides. R1, R2 and C1 are
all running RIP.
www.juniper.net
Case Study Background

The slide describes the goal of the case study. The goal is to advertise a single RIP route into OSPF
as well as send a default route to RIP.
www.juniper.net
Create a Policy for the RIP Route

The first step is to create a policy and apply the policy to OSPF. In this case, two match conditions
were used, creating a logical AND. This policy will be applied to both R1 and R2 under [edit
protocols ospf] by performing a set protocols ospf export redistribute-rip
command.
Verify Policy Operation

Verify that the policy is working by examining the database and finding the Type 7 LSA associated
with the RIP route.
www.juniper.net
ABR Translation
Because the route was originated from the NSSA, the ABR must convert the Type 7 LSA to a Type 5
for interarea advertisement.
Forwarding Address
When the ABR translates the Type 7 into a Type 5, it places the ASBRs address into the forwarding
address. This action supports optimal routing because only one ABR will translate the Type 7s to
Type 5s in the presence of multiple ABRs. This router might not be in the optimal path for routers in
other areas.
ASBR Summary
The ABRs also create a Type 4 LSA to represent the ASBR to other areas.
www.juniper.net
Redistribution of Default Route

The next step is to redistribute the default route into OSPF using an export policy under RIP. By
default, RIP has a lower preference than OSPF external routes.
Because RIP has a better preference, the default route for RIP is preferred. In the sample network,
this preference creates a loop, because the OSPF routers point to the RIP router as their gateway,
and the RIP router points to the OSPF ASBRs.
To fix the loop, modify the OSPF route preference to a lower value than the RIP route.
www.juniper.net
The Result
The result of the preference change is now a default that points properly to the ABRs in the NSSA.
www.juniper.net
SPF Review
After a router receives a new LSA and places it into the LSDB, the router runs an algorithm known as
the Dijkstra algorithm (also called the shortest-path-first [SPF] algorithm). This computation uses the
database as a data source and results in a loop-free network topology using the best metric from the
local router to all nodes in the network.
database, and the tree database. As we have explored, the LSDB is the total compilation of routing
knowledge in the network. Conceptually, it consists of multiple tuples in the form of (router ID,
neighbor ID, and cost), which describe each link in the network.
www.juniper.net
Import Policy
An import policy can be applied between the tree database and the routing table. This policy allows
filtering of routes from the LSDB to the routing table, but it only applies to external routes, as in the
case for OSPF export policy. Note that the database stays consistent and the import policy does not
block any normal LSA flooding.
www.juniper.net
The Junos OS Supports Large Numbers of Routes

Some OSPF implementations encounter problems when large numbers of external routes are
injected into the LSDB. The Junos OS does not behave in this manner, however, and a large number
of routes are handled without a problem. While this protocol stability is a nice feature, a
configuration mistake could make a portion of your network unusable, because only the Juniper
Networks routers would be operating effectively.
To help you when a configuration mistake occurs, the Junos OS allows a limit to be placed on the
number of external routes exported into OSPF. The prefix-export-limit command informs the
router how many routes to accept using a routing policy configuration. The command accepts a
32-bit value, which provides a range of routes from 1 to 4,294,967,295. Once the route limit is
reached, the router transitions into an overload state where the local links are set to a metric of
65,535 in the router LSA. Additionally, all Type 5 LSAs from the router are purged from the database
and the network in general. The local router remains in this state until the number of external routes
returns to a level below the configured limit. This situation requires the administrator to manually
change the existing configuration; either the number of advertised routes must be reduced or the
routing policy must be changed.
www.juniper.net
Modify Policy
To see prefix limits in action, a policy is modified to send all RIP routes into OSPF.
RIP Redistribution
This policy causes all RIP routes to be sent into OSPF.
www.juniper.net
Prefix Limit
To stop the large amount of LSAs that could enter the router, a prefix limit of zero is configured.
The Result
The result is that no RIP routes are distributed. This prefix limit setting ensures that a configuration
error does not affect your network.
www.juniper.net
The configuration of OSPF virtual links;
The configuration of OSPF multiarea adjacencies; and
OSPF external reachability.
www.juniper.net
Review Questions
1.
2.
3.
www.juniper.net
Lab 3: Advanced OSPF Options and Policy

www.juniper.net

Routing
Chapter 5: IS-IS
Chapter 52 IS-IS
IS-IS concepts and operation;
IS-IS link-state protocol data unit (PDU) types;
IS-IS adjacency rules and troubleshooting; and
The configuration and monitoring of IS-IS in the Junos operating system;
www.juniper.net
Overview of IS-IS
www.juniper.net
IS-IS Chapter 53
The IS-IS Protocol

The IS-IS protocol is an IGP that uses link-state information to make routing decisions. It also uses
the shortest-path-first (SPF) algorithm, similar to OSPF.
The ISO
The protocol was developed by Digital Equipment Corporation for its DECnet Phase V. The
International Organization for Standardization (ISO) standardized IS-IS to be the routing protocol for
the ISO's Connectionless Network Protocol (CLNP) and is described in ISO 10589. The ISO was
working on IS-IS at the same time as the Internet Advisory Board (IAB) was working on OSPF. ISO
proposed that IS-IS be adopted as the routing protocol for TCP/IP in place of OSPF. This proposal was
driven by the opinion that TCP/IP was an interim protocol suite that would eventually be replaced by
the Open Systems Interconnection (OSI) suite.
Chapter 54 IS-IS
www.juniper.net
CNLS
Connectionless Network Service (CLNS) is the service that CLNP provides to route messages to their
destinations. This service is independent of any other messages and can transmit data before a
circuit is established. M, MX, and T Series routers only support IP routing with IS-IS. They do not
support CLNP or CLNS routing. Full IS-IS CLNP routing (including End SystemtoIntermediate
System [ES-IS] routing) is supported on SRX Series Gateways and J Series Routers.
Dual IS-IS
The Integrated IS-IS protocol was proposed to support the transition from TCP/IP to OSI. Integrated
IS-IS, also known as dual IS-IS, provides a single routing protocol capable of routing both CLNS and
IP. Integrated IS-IS was developed to operate in a CLNS, IP, or CLNS/IP setting.
Single Algorithm
Like all integrated routing protocols, Integrated IS-IS requires that all routers run a single routing
algorithm. LSPs sent by routers running Integrated IS-IS include all destinations running either IP or
CLNP Network Layer protocols. Routers running Integrated IS-IS still must support protocols such as
the Address Resolution Protocol (ARP), the Internet Control Message Protocol (ICMP) for IP, and the
ES-IS protocol for CLNP.
www.juniper.net
IS-IS Chapter 55
LSPs
Standard IS-IS packets must be modified to support multiple Network Layer protocols. IS-IS packet
formats were designed to support the addition of new fields without a loss of compatibility with
nonintegrated versions of IS-IS.
IS-IS adds type/length/value (TLV) objects (discussed further on the following pages) to support
integrated routing. These TLVs tell intermediate systems (ISs) which Network Layer protocols are
supported by other ISs and whether end stations running other protocols can be reached. They also
include any other required Network Layer, protocol-specific information.
Chapter 56 IS-IS
www.juniper.net
Operation of IS-IS
An IS-IS network is a single AS, also called a routing domain, that consists of end systems (ESs) and
intermediate systems (ISs). End systems are network entities that send and receive packets.
Intermediate systemswhich is the OSI term for a routersend and receive packets and relay, or
forward, packets. IS-IS packets are called PDUs.
IS-IS Areas
In IS-IS, a single AS can be divided into smaller groups called areas. Routing between areas is
organized hierarchically, allowing a domain to be divided administratively into smaller areas. IS-IS
accomplishes this organization by configuring Level 1 and Level 2 intermediate systems. Level 1
systems route within an area, and Level 2 intermediate systems route between areas and toward
other ASs. A Level 1/Level 2 system routes within an area on one interface and between areas on
another.
A Level 1/Level 2 system sets the attached bit in the Level 1 PDUs that it generates into a Level 1
area to indicate that it is a Level 2-attached backbone router and that it can be used to reach
prefixes outside the Level 1 area. Level 1 routers create a default route for interarea prefixes, which
points to the closest (in terms of metrics) Level 1/Level 2-attached router.
www.juniper.net
IS-IS Chapter 57
Network Entity Title

The slide displays a sample IS-IS network with two distinct areas configured49.0001 and 49.0002.
The area address can range from 1 to 13 bytes in length and is always the first component of the
Network Entity Title (NET) address. The middle portion of the NET is the system ID of the router,
which should be unique throughout the entire domain.
The system ID is always 6 bytes and can be any set of hexadecimal digits you want. One common
convention is placing the IP address of the loopback interface into the system ID portion of the NET.
You accomplish this convention by ensuring that the dotted-decimal IP address is written with all of
the leading zeros filled in. On the slide, the router in the top left of the network has 192.168.16.1
configured as its loopback address. This address can also be written as 192.168.016.001. We now
have an address with 12 digits in it, exactly the number we need for the system ID. We simply move
the dots between the digits into a format used in the hexadecimal notation. This process results in a
system ID of 1921.6801.6001.
Chapter 58 IS-IS
www.juniper.net
IS-IS and OSPF Common Features

The slide lists the commonalities between IS-IS and OSPF.
www.juniper.net
IS-IS Chapter 59
OSPF Areas
IS-IS and OSPF are link-state routing protocols with many similarities. Differences exist between
them as well. Recall that, under OSPF, routers separate areas. The slide shows how a typical OSPF
network might be broken up into areas. Some interfaces are in one area, and other interfaces are in
another area. When an OSPF router has interfaces in more than one area, it is an ABR.
Chapter 510 IS-IS
www.juniper.net
IS-IS Areas
In IS-IS areas, a Level 1/Level 2 router fulfills the same purpose as an area border router (ABR) in
OSPF. Likewise, the collection of Level 2 routers in IS-IS is the backbone, while Area 0 is the
backbone in OSPF. However, in IS-IS, all routers are completely within an area, and the area borders
are on the links, not on the routers. The routers that connect areas are Level 2 routers, and routers
that have no direct connectivity to another area are Level 1 routers. An intermediate system can be a
Level 1 router, a Level 2 router, or both (an L1/L2 router).
www.juniper.net
IS-IS Chapter 511
IS-IS PDUs
Chapter 512 IS-IS
www.juniper.net
Describes Adjacency State

The LSP that each IS-IS router generates describes the state of the local router and its adjacencies in
the network.
Some fields of interest in the LSP header include the ID length and the maximum area address,
which are set to a constant value of 0x00. This value does not mean that the Junos OS does not
support their functionality. Instead, these fields are used for backward compatibility with older
protocol implementations. The system ID is always 6 bytes in length, and the maximum area
addresses supported is always 3 bytes. By setting these two fields to a value of 0, the Junos OS is
reporting that it supports the default values for these two settings.
You might also notice that the LSP header contains two version fields. The first of these fields,
according to the original IS-IS specification, was designed as an extension of the protocol ID field.
Most modern implementations, including the Junos OS, do not support this function and instead
place a constant value of 0x01 in the field to represent the version of the protocol. The second
version field is the actual specified location for the protocol version, which is also set to a value of
0x01the current version of the protocol.
www.juniper.net
IS-IS Chapter 513
Flooded Periodically
The IS-IS LSPs are flooded when either a network change occurs or often enough to keep the
database from having stale information. Each LSP has a 2-byte field named the remaining lifetime.
Each IS-IS router initializes this field to a certain value when the LSP is created. By default, this timer
value is set to 1200 seconds, or 20 minutes. Each router takes this value and begins a countdown
toward 0. Before the timer expires (at approximately 317 seconds), the originating system
regenerates the LSP and floods it to all its neighbors.
Contains TLV Segments

Each individual LSP contains multiple TLV segments that describe the originating router. Many
possible TLVs can be sent, but each system only sends those that it needs to communicate to
adjacent systems. The details of the TLV segments are discussed in future slides using the output of
the show isis database extensive command. You can also view the received TLVs using the
monitor traffic detail command. The following output shows a sample from this command:
user@router> monitor traffic detail interface so-0/1/0 size 1514
Listening on so-0/1/0
11:55:48.470418 In ISIS(186), 30:30:30:30:30:30 > 30:30:30:30:30:30, hlen: 27, v: 1,
sys-id-len: 6 (0), max-area: 3 (0), L2 LSP
lsp-id: 1921.6804.8001.00-00, seq: 0x00000008, lifetime: 1189s
chksum: 0x86c9 (correct), PDU length: 186, L1L2 IS
Area address(es) TLV #1, length: 4
Area address (3): 49.0001
Protocols supported TLV #129, length: 2
NLPID(s): IPv4, IPv6
Traffic Engineering Router ID TLV #134, length: 4
Traffic Engineering Router ID: 192.168.48.1
IPv4 Interface address(es) TLV #132, length: 4
IPv4 interface address: 192.168.48.1
Hostname TLV #137, length: 8
Hostname: SaoPaulo
IPv4 Internal reachability TLV #128, length: 24
IPv4 prefix: 192.168.48.1/32
Default Metric: 00, Internal, Distribution: up
IPv4 prefix: 10.222.60.0/24
Extended IPv4 reachability TLV #135, length: 17
IPv4 prefix: 192.168.48.1/32
Metric: 0, Distribution: up, no sub-TLVs present
IPv4 prefix: 10.222.60.0/24
IPv4 External reachability TLV #130, length: 12
IPv4 prefix: 192.168.49.0/24
Extended IPv4 reachability TLV #135, length: 8
IPv4 prefix: 192.168.49.0/24
IS Reachability TLV #2, length: 12
IsNotVirtual
IS Neighbor: 1921.6805.2001.00, Default Metric: 10, Internal
Extended IS Reachability TLV #22, length: 23
IS Neighbor: 1921.6805.2001.00, Metric: 10, sub-TLVs present (12)
IPv4 interface address: 10.222.60.2
IPv4 neighbor address: 10.222.60.1
Authentication TLV #10, length: 17
HMAC-MD5 password: 00bb32fd7712bcea6003e516e2333077
Chapter 514 IS-IS
www.juniper.net
PDU Type
The 1-byte PDU type field denotes whether the PDU is Level 1 or Level 2 PDU. A value of 18
represents a Level 1 PDU and a value of 20 is a Level 2 PDU. With this exception as well as different
multicast destination addresses, the PDU contents and formats are identical to each other.
LSP ID Field
The ID of the LSP uniquely identifies it within the IS-IS domain. The 8-octet field is comprised of the
routers system ID (6 bytes), the circuit ID (1 byte), and the LSP number (1 byte). The system ID is
located within the NET address of the router and is used exactly as is. The LSP number field
represents a fragmented LSP. The initial LSP receives a value of 0x00, and it is incremented by 1 for
each following fragment.
The circuit ID field helps distinguish LSPs advertised from a single router. By default, all LSPs
representing the router as a node use a value of 0x00 for the circuit ID field. When a router is
operating as a designated intermediate system (DIS), it places the value of the circuit ID into this
field and generates a separate LSP for the broadcast segment. The Junos OS uses a constant value
circuit ID value of 0x01 for the loopback interface as well as all point-to-point interfaces. Each
broadcast segment receives a unique circuit ID value beginning at 0x02 and incrementing to a
maximum value of 0xff.
www.juniper.net
IS-IS Chapter 515
Attached Bit
Any IS-IS router with a Level 2 adjacency to a system in another area sets the Attached bit in its
Level 1 LSP. Level 1 routers can then forward data packets to that attached router for transport out
of the local area.
Overload Bit
An IS-IS router can set the overload bit to inform the other routers in the network that it is incapable
of reliably transmitting transit packets to other portions of the network. While the original intent of
the bit was to ease memory problems on individual routers, modern-era routers do not have such
constraints. In todays network environment, the bit is often used to take a router out of service for
maintenance or to allow it to fully converge within the network before forwarding traffic.
IS Type Bits
The IS type bits inform other routers in the network about the capabilities of the local router. Two
possible settings are available for these bits. When the bits are set to a value of 01 (0x01), the local
router can support only Level 1 routing. A value of 11 (0x03), however, means that the local router
can support both Level 1 and Level 2 routing. These settings are the only two settings possible for
these bits.
Chapter 516 IS-IS
www.juniper.net
Purpose of IS-IS Hello PDUs

The purpose of the IS-IS hello PDU is to allow IS-IS routers to discover IS-IS neighbors on a link. Once
the neighbors have been discovered and are adjacent, the hello PDU acts as a keepalive to maintain
the adjacency and to inform the neighbors of any changes in the adjacency parameters.
IS-IS Hello PDU Types

Two kinds of IS-IS hellos PDUs exist: LAN hello PDUs and point-to-point hello PDUs. The LAN hello
PDUs can be divided further into Level 1 and Level 2 hello PDUs. The format of the two types of LAN
hello PDUs is identical. Note that on broadcast networks IS-IS Level 1 and Level 2 hellos are coded
with multicast address 01-80-C2-00-00-14 or 01-80-C2-00-00-15 respectively.
Hello Transmission
Routers send hello packets at a fixed interval on all interfaces to establish and maintain neighbor
relationships. The hello interval field advertises this interval in the hello packet. By default, a DIS
router sends hello packets every 3 seconds, and a non-DIS router sends hello packets every 9
seconds.
www.juniper.net
IS-IS Chapter 517
PDU Fields
The following list provides the details of the PDU fields:
Chapter 518 IS-IS
Circuit type: Defines the router as an Level 1, Level 2, or Level 1/Level 2 router;
Source ID: Identifies the system ID of the router that originated the hello PDU;
Holding time: Specifies the period a neighbor should wait to receive the next hello PDU
before declaring the originating router dead;
PDU length: Specifies the length of the entire PDU in octets;
Priority: Provides a value between 0 and 127 used for DIS election; and
LAN ID: Identifies the system ID or the DIS plus one more octet (the pseudo-node ID) to
differentiate this LAN ID from another LAN ID that might have the same DIS.
www.juniper.net
IS-IS LSPs
IS-IS sends LSPs at regular intervals and when an IS discovers any of the following:
Its link to a neighbor is down;
It has a new neighbor; or
The cost of a link to an existing neighbor has changed.
Once LSPs are distributed appropriately, IS-IS runs the Dijkstra algorithm to compute optimal paths
to each ES. This algorithm iterates on the length of a path, examining the LSPs of all ISs working
outward from the host IS. At the end of the computation, IS-IS forms a connectivity tree yielding the
shortest paths, including all intermediate hops, to each IS.
www.juniper.net
IS-IS Chapter 519
Partial Sequence Number PDUs

A receiver multicasts partial sequence number PDUs (PSNPs) when it detects that it is missing an
LSP or when its LSP database is out of date. The receiver sends a PSNP to the system that
transmitted the complete sequence number PDUs (CSNPs), effectively requesting that the missing
LSP be transmitted. That router, in turn, forwards the missing LSP to the requesting router.
Complete Sequence Number PDUs

CSNPs contain a complete description of all LSPs in the IS-IS database. IS-IS sends CSNPs
periodically on all links. The receiving systems use the information in the CSNP to update and
synchronize their LSP databases. The DIS router multicasts CSNPs on broadcast links in place of
sending explicit acknowledgments for each LSP.
Chapter 520 IS-IS
www.juniper.net
IS-IS Information Objects

IS-IS PDUs use TLV encoding as the basic structure for all routing information. TLV encoding requires
that the length of any field be defined explicitly when a PDU uses that field. IS-IS ignores all unknown
TLVs, making the protocol easily extensible.
www.juniper.net
IS-IS Chapter 521
TLV Variables: Part 1

The following list provides the details of several of the TLVs:
Chapter 522 IS-IS
TLV 1 (Area address): Provides the area address encoded within the IS-IS NET on the
loopback 0 (lo0) interface.
TLV 2 (IS reachability): Advertises the IS neighbors adjacent to the local router as well as
the metric used to reach those neighbors.
TLV 10 (Authentication): Contains the authentication type and the configured password.
TLV 22 (Extended IS reachability): Advertises the IS neighbors adjacent to the local

router and the routers that support traffic engineering capabilities. This TLV also
contains multiple sub-TLVs that describe the user constraints placed on the router by
the network administrator. This TLV also populates the traffic engineering database
(TED).
TLV 128 (IP internal reachability): Advertises the IP address and subnet mask for each
of the routers interfaces capable of supporting IP version 4 (IPv4) traffic.
TLV 129 (Protocols supported): Informs other routers in the network which Layer 3
protocols the local router supports. By default, the Junos OS supports both IPv4 and IP
version 6 (IPv6). On the J Series Services Router and the SRX Series Services Gateways,
you can also use the Junos OS to support CLNS.
www.juniper.net
TLV Variables: Part 2

The following list is a continuation of the details of several TLV variables:
TLV 130 (IP external reachability): Advertises the network and subnet mask for all
routes advertised into IS-IS by using a policy.
TLV 132 (IP interface address): Advertises the host IP address for all router interfaces.
TLV 134 (Traffic engineering IP router ID): Advertises the 32-bit router ID (RID) of the
local router.
TLV 135 (Extended IP reachability): Advertises the IP address and subnet mask for
router interfaces that can support traffic engineering. This TLV also populates the TED.
TLV 137 (Dynamic hostname resolution): Advertises the ASCII hostname configured on
the local router. Other IS systems use this TLV to resolve the hostname of the router for
use in show command output and within certain TLVs.
www.juniper.net
IS-IS Chapter 523
Multiple Topology TLVs

The following list provides the details of the TLVs that support multiple topologies:
TLV 222 (Multiple topology IS reachability): Advertises the IS neighbors adjacent to the
local router and the routers that support multiple topologies of IS-IS.
TLV 229 (Multiple topologies supported): Advertises which multiple topologies of IS-IS
the local router supports. Each topology is identified by a 12-bit ID field.
TLV 235 (Multiple topology IP reachability): Advertises the IP information for interfaces
that support multiple topologies. This TLV contains multiple sub-TLVs, which define the
actual information. Each set of sub-TLVs is accompanied by the 12-bit topology ID field.
IPv6 TLVs
The following list provides the details of the TLVs that support IPv6:
Chapter 524 IS-IS
TLV 232 (IPv6 interface address): Advertises the IPv6 interface address for those
interfaces that support IPv6 traffic.
TLV 236 (IPv6 reachability): Advertises information about the network link on which the
IPv6 protocol is operating. This TLV contains multiple sub-TLVs that contain the actual
metric information, among other things.
www.juniper.net
Area Address TLV

Each IS-IS router sends this TLV in both its Level 1 and its Level 2 LSPs. At times, during a network
migration, for instance, when you might need more than one area configured on the router, so up to
three area addresses are configurable per system. The area ID field is repeated for each unique area
address. The area address TLV contains the following fields:
www.juniper.net
TLV type (1 byte): The type of the TLV is encoded in this field with a constant value of 1.
TLV length (1 byte): This field contains the length of the remaining fields in the TLV.
Together, the TLV length and area length fields allow an IS-IS router to determine the
number of area addresses encoded within the TLV.
Area length (1 byte): The length of the following advertised area is encoded in this field.
Area ID (variable): This field can range from 1 to 13 bytes. It contains the actual area
address configured within the NET ID of the router.
IS-IS Chapter 525
IS Reachability TLV
Each IS-IS router advertises its adjacencies with neighboring systems through this TLV. The various
metric fields as well as the neighbor ID field are repeated for each adjacent neighbor. The metric
values are encoded in a 6-bit field resulting in possible metrics between 0 and 63. These values are
sometimes referred to as old-style or small metrics. The IS reachability TLV contains the following
fields:
TLV length (1 byte): The length of the remaining fields in the TLV is placed in this field.
This length allows the router to determine the number of neighbors encoded within the
TLV. Each set of neighbors and metrics occupies 11 octets of space. Therefore, the field
length minus 1 (for the virtual flag) should be divisible by 11, resulting in the number of
adjacent neighbors.
Virtual flag (1 byte): An IS-IS router sets this flag when the advertised information
should be used to repair a nonadjacent Level 2 area. The Junos OS does not support
partition repair and this field is set to a constant value of 0x00.
Chapter 526 IS-IS
www.juniper.net
IS Reachability TLV (contd.)
www.juniper.net
Default metric (1 byte): The first bit in this field is a reserved bit and is set to a value of
0. The second bit in this field can be used to support internal and external metrics by
indicating the metric type; internal and external metrics are not comparable. Because
this TLV is never leaked, the I/E bit is always coded to a zero to indicate an internal type.
The remaining 6 bits are used to encode the metric cost to reach the adjacent neighbor.
Delay metric (1 byte): The Junos OS does not support the use of type of service (ToS)
metrics within IS-IS. The S bit is set to a constant value of 1 (not supported), while the
I/E and metric bits are all set to a constant value of 0.
Expense metric (1 byte): The Junos OS does not support the use of ToS metrics within
IS-IS. The S bit is set to a constant value of 1 (not supported), while the I/E and metric
bits are all set to a constant value of 0.
Error metric (1 byte): The Junos OS does not support the use of ToS metrics within IS-IS.
The S bit is set to a constant value of 1 (not supported), while the I/E and metric bits are
all set to a constant value of 0.
Neighbor ID (7 bytes): The ID of the adjacent neighbor is encoded in this field. It is

comprised of the 6-byte system ID and the 1-byte circuit ID of the neighbor.
IS-IS Chapter 527
Authentication TLV
If configured to support authentication, an IS-IS router includes this TLV in all advertised link-state
PDUs. The authentication TLV contains the following fields:
Chapter 528 IS-IS
Authentication type (1 byte): The specific form of authentication is encoded in this field.
Plain-text authentication uses a value of 1, while Message Digest 5 (MD5)
authentication uses a value of 54.
Password (Variable): The actual authentication data is stored in this field. When MD5 is
used, the size of this field is always 16 bytes.
www.juniper.net
Extended IS Reachability TLV

Each IS-IS router also advertises its adjacencies with neighboring systems through this TLV. The
system ID, metric field, and optional sub-TLV fields are repeated for each adjacent neighbor. The
main use of TLV 22 for regular IS-IS is the larger metric values it supports. The extended IS
reachability TLV uses a 24-bit field that results in possible metrics between 0 and 16,777,215. This
range of metric values is often referred to as new-style or wide metrics. The extended IS reachability
TLV contains the following fields:
System ID (7 bytes): The ID of the adjacent neighbor is encoded in this field. It is

comprised of the 6-byte system ID and the 1-byte circuit ID of the neighbor.
Wide metric (3 bytes): The metric cost to reach the adjacent neighbor is encoded in this
field.
www.juniper.net
IS-IS Chapter 529
Extended IS Reachability TLV (contd.)

The following list is a continuation of the fields contained in the extended IS reachability TLV:
Chapter 530 IS-IS
Sub-TLV length (1 byte): The length of any optional sub-TLVs is encoded in this field. If no
sub-TLVs are present, the field is set to a value of 0.
Sub-TLVs (Variable): Additional traffic engineering information is advertised in these

fields, each with a separate type code, length, and value portion. Each of the fields is
placed within the TED on the router. In addition, some sub-TLVs are placed into the
LSDB on the router. The possible sub-TLVs include the following:
Administrative group (Type 3);
IPv4 interface address (Type 6);
IPv4 neighbor address (Type 8);
Maximum link bandwidth (Type 9);
Reservable link bandwidth (Type 10); and
Unreserved bandwidth (Type 11).
www.juniper.net
IP Internal Reachability TLV

Each IS-IS router advertises its locally connected IP prefixes with the IP internal reachability TLV. The
metric fields, the IP address, and the subnet mask are repeated for each advertised prefix. As with
the IS reachability TLV, the metric values are encoded in a 6-bit field resulting in possible metrics
between 0 and 63 (small metrics). The IP internal reachability TLV contains the following fields:
TLV type (1 byte): The type of the TLV is encoded in this field, which holds a constant
value of 128.
This length allows the router to determine the number of prefixes advertised within the
TLV. Each set of metrics and addresses occupies 12 octets of space.
Default metric (1 byte): The first bit in this field is known as the Up/Down (U/D) bit. It is
used to provide information to IS-IS routers in a multilevel network to allow for prefix
advertisements across a level boundary and to prevent routing loops. The second bit in
this field can be used to indicate whether a given pair of metrics are comparable by
indicating a metric type of either internal or external. Although some Junos OS versions
made use of the I/E bit for TLV 128, the current release ignores this bit upon reception
and treats all prefixes as internal. The final 6 bits represent the metric cost to reach the
advertised prefix.
www.juniper.net
IS-IS Chapter 531
IP Internal Reachability TLV (contd.)

The following list details the remaining fields in the IP internal reachability TLV:
Chapter 532 IS-IS
Delay metric (1 byte): The Junos OS does not support the use of ToS metrics within IS-IS.
The S bit, the R bit, and the metric bits are all set to a constant value of 0.
IS-IS. The S bit, the R bit, and the metric bits are all set to a constant value of 0.
www.juniper.net
Protocols Supported TLV

Every IS-IS router sends this TLV in all LSPs. It lists the Layer 3 protocols supported by the local
router, making IS-IS a true multiprotocol routing protocol. The network layer protocol identifier
(NLPID) is repeated for each supported protocol. The TLV contains the following fields:
www.juniper.net
TLV type (1 byte): The type of the TLV is encoded in this field. A constant value of 129 is
placed in this field.
This length allows a router to determine the number of NLPIDs encoded within the TLV.
Network Layer protocol ID (1 byte): The 8-bit NLPID is placed within this field. By default,
the Junos OS supports both IPv4 (0xCC) and IPv6 (0x8E) and encodes those values in
this TLV. On J Series routers and SRX Series devices, you can also configure the
Junos OS to support the CLNS protocol by configuring clns-routing at the [edit
protocols isis] configuration hierarchy.
IS-IS Chapter 533
IP External Reachability TLV

Each IS-IS router advertises prefixes that are natively external to IS-IS with the IP external reachability
TLV. As with the IP internal reachability TLV, the metric, IP address, and subnet mask fields are
repeated for each advertised prefix. The metric values are again encoded in a 6-bit small metrics
field. The IP external reachability TLV contains the following fields:
TLV type (1 byte): The type of the TLV is encoded in this field with a constant value of
130.
TLV. Each set of metrics and addresses occupies 12 octets of space.
Default metric (1 byte): The first bit in this field is the U/D bit. It is used by IS-IS routers
in a multilevel network to allow for prefix advertisements across a level boundary and to
prevent routing loops. The second bit in this field can be used to indicate whether a
given pair of metrics are comparable by indicating a metric type of either internal or
external. Although some Junos OS versions made use of the I/E bit for TLV 130, the
current release ignores this bit upon reception and treats all prefixes as external by
virtue of their being carried within TLV 130. The final 6 bits represent the metric cost to
reach the advertised prefix.
Chapter 534 IS-IS
www.juniper.net
IP External Reachability TLV (contd.)

The following list details the fields remaining in the IP external reachability TLV:
www.juniper.net
Delay metric (1 byte): The Junos OS does not support the use of ToS metrics within IS-IS.
IS-IS. The S bit, the R bit, and the metric bits are all set to a constant value of 0.
IP address (4 bytes): The IPv4 prefix being advertised in the TLV is encoded in this field.
Subnet mask (4 bytes): The subnet mask associated with the advertised prefix is stored
in this field.
IS-IS Chapter 535
IP Interface Address TLV

IS-IS routers send this TLV in all LSPs, which list IP addresses configured on the originating router. At
least one interface address must be advertised while each router interface can be advertised. By
default, the Junos OS encodes the RID of the local system in this TLV. This RID is often the same as
the primary address of the router's lo0.0 interface. The IP interface address TLV contains the
following fields:
Chapter 536 IS-IS
132.
This length allows a router to determine the number of addresses encoded within the
TLV.
IPv4 address (4 bytes): The RID is placed in this field.
www.juniper.net
TE IP RID TLV
All routers configured to support traffic engineering, which is the Junos OS default setting, generate
this TLV. The RID of the local router is placed in this field for use in the TED. The TE IP RID TLV
contains the following fields:
www.juniper.net
134;
TLV length (1 byte): The length of the remaining fields in the TLV is placed in this field
with a constant value of 4; and
IPv4 address (4 bytes): The RID of the local router is placed in this field.
IS-IS Chapter 537
Extended IP Reachability TLV

Each IS-IS router configured to support traffic engineering advertises its local IP prefix information
using this TLV. Both locally connected and nonnative IS-IS routes use this TLV for reachability
information, with no concept of internal or external metrics. The metric, prefix length, prefix, and
sub-TLV fields are repeated for each advertised address.
The metric field uses 32 bits (wide metrics) for each advertised prefix, which results in possible
metrics between 0 and 4,294,967,295. The extended IP reachability TLV contains the following
fields:
135.
TLV.
Metric (4 bytes): The metric of the advertised prefix is encoded in this field.
Chapter 538 IS-IS
www.juniper.net
Extended IP Reachability TLV (contd.)

The following list details the remaining fields of the extended IP reachability TLV:
www.juniper.net
Prefix length (1 byte): The first bit in this field is the U/D bit, which is used to allow
prefixes to be advertised across a level boundary and to prevent routing loops. The
second bit in this field is the sub bit, which denotes if any optional sub-TLVs are
associated with the advertised prefix. The final 6 bits represent the length of the
advertised prefix.
Prefix (variable): The advertised prefix is placed in this field.
Optional sub-TLV type (1 byte): The type of the sub-TLV is encoded in this field. The
Junos OS currently supports only one sub-TLV type, which is a 32-bit route tag with a
type code of 1.
Optional sub-TLV length (1 byte): The length of the remaining fields in the sub-TLV is
placed in this field.
Optional sub-TLV (variable): For the supported route tag sub-TLV, the 32-bit tag value is
placed in this field. IS-IS route tagging offers the same administrative filtering
capabilities as the OSPF protocol. IS-IS traffic engineering extensions, which enable
TLV 135, must be enabled to support route tagging. TE extensions are enabled for IS-IS
by default.
IS-IS Chapter 539
Dynamic Host Name TLV

All IS-IS routers advertise their configured hostname into the network using this TLV. This
advertisement allows network operators to view information about the network routers using a
symbolic name instead of the hexadecimal system ID in various show commands. The dynamic host
name TLV contains the following fields:
Chapter 540 IS-IS
137.
TLV length (1 byte): The length of the hostname field is placed in this field. Possible
values range from 1 to 255 octets.
Hostname (Variable): The locally configured ASCII hostname of the router is placed in
this field.
www.juniper.net
Level 2 PDU TLVs Example

The example on the slide shows the details of a level 2 PDU. By using the extensive keyword, you
can see each of the TLV fields. You can gather important details about this network by examining the
TLVs closely:
The local router is configured within Area 49.0001, and the area length is 3 bytes. This
information is available in the Area Address field and TLV 1.
The local routers RID is 192.168.48.1. This information is available in the IP router
id field and TLV 134.
The LSP was originated by the Sao Paulo router, because the Hostname field of TLV
137 lists SaoPaulo in its payload.
The local router has an IS adjacency with the Sydney routers at a metric of 10. This
information is available in the IS Neighbor field and TLV 2.
The IP address of the routers interface toward Sydney is 10.222.60.2, as seen in TLV
22, sub-TLV 6.
The local router is advertising two internal local IS-IS routes, 10.222.60.0/24 and
192.168.48.1/32. This information is available from the IP Prefix field and TLV
128.
www.juniper.net
IS-IS Chapter 541
Level 2 PDU TLVs Example (contd.)
Chapter 542 IS-IS
The local router has a policy configured to advertise the external prefix of
192.168.49.0/24. This information is available in the IP external prefix field
and TLV 130.
All three prefixes advertised by the local router are carried in TLV 135 and are visible in
the IP extended prefix field.
www.juniper.net
Neighbors and Adjacencies

www.juniper.net
IS-IS Chapter 543
Neighbors and Adjacencies

The slide lists the rules Level 1 and Level 2 routers must follow when forming an adjacency.
Chapter 544 IS-IS
www.juniper.net
DIS Election
The IS-IS DIS election process is achieved by assigning a Level 1 priority and a Level 2 priority on
every IS-IS router interface, with a range of 0 through 127. The Junos OS uses a default priority of 64
for both levels. The router advertises its priority in the hello PDUs sent from each interface. The L1
priority is advertised in L1 hello PDUs, and the L2 priority is advertised in L2 hello PDUs. If the priority
is 0, the router is ineligible to become the DIS. Interfaces to nonbroadcast networks automatically
have a priority of 0. The router with the higher priority value becomes the DIS. In the event of a tie,
the router with the numerically highest subnetwork point of attachment (SNPA), which is a fancy
name for a MAC address, wins the election.
DIS Characteristics
Unlike OSPF, however, an IS-IS router attached to a broadcast, multi-access network establishes
adjacencies with all of its neighbors on the network, not just the DIS. Each router multicasts its LSPs
to all of its neighbors, and the DIS uses a system of PDUscalled sequence number PDUsto ensure
that the flooding of LSPs is reliable. Also unlike OSPF, no election of a backup designated router
occurs in IS-IS. If the IS-IS DIS fails, a new DIS is elected. Another characteristic is that if a new router
with a higher priority than the existing DIS becomes active, or if the new router has an equal priority
and a higher subnetwork point of attachment (MAC address), the new router becomes the DIS. When
the DIS changes, a new set of LSPs must be flooded.
www.juniper.net
IS-IS Chapter 545
Pseudo-Node
IS-IS elects a DIS on broadcast and multi-access networks for the same reason as OSPF. Rather than
having each router connected to the LAN advertise an adjacency with every other router connected
to the LAN, the network itself is considered a routera pseudo-node. Each router, including the DIS,
advertises a single link to the pseudo-node. The DIS also advertises, as the representative of the
pseudo-node, a link to all of the attached routers.
Chapter 546 IS-IS
www.juniper.net
IP Configuration Necessary
You can check several things while troubleshooting IS-IS adjacency problems. When establishing
adjacencies in IS-IS, all routers on a link must agree upon the IP subnet to which they belong, except
on point-to-point links, which can be unnumbered or use /32 addressing. The Junos OS needs the IP
portion of the network to function so that the IS-IS adjacency will work.
www.juniper.net
IS-IS Chapter 547
Configuring and Monitoring IS-IS

Chapter 548 IS-IS
www.juniper.net
Configuring IS-IS: Part 1

For IS-IS to run on the router, you must enable IS-IS on the router, configure a NET on one of the
routers interfaces (preferably the loopback interface, lo0), and configure the ISO family on all
interfaces on which you want IS-IS to run.
The Junos OS supports the assignment of multiple ISO NETs to the routers loopback interface. Such
a configuration might prove helpful when migrating two previously independent IS-IS domains into a
single routing domain.
www.juniper.net
IS-IS Chapter 549
Configuring IS-IS: Part 2

By default, all IS-IS interfaces are Level 1 and Level 2 interfaces. You might need to disable a
particular level on a given interface. Notice that configuring IS-IS on Junos devices requires minimal
configuration.
Chapter 550 IS-IS
www.juniper.net
Metric Cost of an Interface

Each IS-IS router must determine the metric (or cost) associated with that network. Often referred to
as simply the metric, the cost is simply what the router views as the overhead associated with
transmitting a packet on that interface. Each IS-IS-speaking router advertises these cost values in its
LSPs; each router can determine the total cost (or metric) to reach any destination in the network.
IS-IS Default Metric

Each router in as IS-IS network uses a default metric of 10 for all interfaces on the router. The
notable exception to this default setting is the loopback interface of the router, which has a default
metric of 0.
When you configure an IS-IS interface to operate in passive mode, the default metric is still set to a
value of 10. This default is different from the operation of other router vendors, so be careful in a
multivendor environment to ensure a consistent metric calculation.
Set on a Per-Interface Basis

If you want to alter the metrics in the network, you can set the cost for each interface. Within the
interface portion of the [edit protocols isis] configuration hierarchy, the metric
command assigns a permanent cost to that interface for a particular level. Each interface on the
router can have a separate cost assigned to it.
www.juniper.net
IS-IS Chapter 551
Change the Cost Calculation

Although you can statically assign each interface with a cost, this process often proves to be an
administrative hassle in all but the smallest networking environments. However, an option is
available to administrators who want an automatic calculation of metrics in their networks.
The solution is to enable a bandwidth calculation similar to that used in OSPF. This calculation takes
a supplied valuethe reference bandwidthand divides it by the bandwidth of the physical interface.
This solution not only allows for an automatic cost assignment, but it also maintains a consistent
ratio across all the router interfaces.
Reference Bandwidth
To enable the calculation, use the reference-bandwidth command within the [edit
protocols isis] configuration hierarchy. The value entered has a value in bits per second. Use
the standard Junos shortcut notations of k (kilobits per second), m (megabits), and g (gigabits). The
entered value becomes the numerator value in the bandwidth calculation.
Chapter 552 IS-IS
www.juniper.net
Monitoring IS-IS Operation

This slide lists the show commands discussed on the following pages.
www.juniper.net
IS-IS Chapter 553
Displaying Interface Status

The show isis interface command displays the status of an interface. Use this command to
ensure that IS-IS is configured correctly on the router. The output of this command includes the
following fields:
interface-name (detail output only): Displays the name of the interface.
Index (detail output only): Displays the interface index assigned by the Junos kernel.
State (detail output only): Displays the internal implementation information.
Circuit ID (detail output only): Displays the circuit identifier.
Circuit type (detail output only): Displays the circuit type, which can be 1Level 1
only, 2Level 2 only, or 3Level 1 and Level 2.
LSP interval (detail output only): Displays the interfaces link-state PDU interval.
Sysid (detail output only): Displays the system identifier.
Interface (brief output only): Displays the interface through which the adjacency is
made.
Chapter 554 IS-IS
www.juniper.net
Displaying Interface Status (contd.)
www.juniper.net
Level 1 DR/Level 2 DR (brief output only): Displays the Level 1 or Level 2

designated intermediate system.
L1/L2 Metric: Displays the interfaces metric for Level 1 and Level 2. If no
information exists, the metric is 0.
Adjacencies (detail output only): Displays the number of adjacencies established on

this interface.
Priority (detail output only): Displays the priority value for this interface.
Metric (detail output only): Displays the metric value for this interface.
Hello (s) (detail output only): Displays the interfaces hello interval.
Hold (s) (detail output only): Displays the interfaces hold time.
IS-IS Chapter 555
Displaying IS-IS Adjacency Status

The show isis adjacency command displays the status of IS-IS adjacencies. The output of this
command includes the following fields:
Chapter 556 IS-IS
Interface: Displays the interface through which the neighbor is reachable.
System (brief output only): Displays the system identifier (sysid), printed as a name if
possible.
L: Displays the level, which can be 1Level 1 only; 2Level 2 only;

or 3Level 1 and Level 2. An exclamation point (!) preceding the level number
indicates that the adjacency is missing an IP address.
State: Displays the state of the adjacency. It can be Up, Down, New, One-way,
Initializing, or Rejected.
Hold (secs) (brief/standard output only): Displays the remaining hold time of the
adjacency. Note that the show isis adjacency command returns brief output by
default.
SNPA (brief output only): Displays the subnetwork point of attachment (MAC address of
the next hop).
www.juniper.net
Displaying Detailed Adjacency Information

The show isis adjacency detail command displays detailed IS-IS adjacency information.
The output of this command includes the following fields:
www.juniper.net
Expires in (detail output only): Displays how long until the adjacency expires, in
seconds;
Priority (detail output only): Displays the priority to become the DIS;
Up/Down transitions (detail output only): Displays the count of adjacency status
changes from up to down or from down to up;
Last transition (detail output only): Displays the time of the last up/down
transition;
Circuit type (detail output only): Displays the bit mask of levels on this interface,
which can be 1Level 1 router, 2Level 2 router, or 1/2both Level 1 and Level 2
routers;
Speaks (detail output only): Displays the protocols supported by this neighbor; and
IP addresses (detail output only): Displays the IP address of this neighbor.
IS-IS Chapter 557
Displaying SPF Operation

The show isis spf log command displays the elapsed time to perform SPF calculations and
the reasons why they were triggered. The output fields of this command are the following:
Chapter 558 IS-IS
Node: Displays the sysid of a node;
Metric: Displays the metric to the node;
Interface: Displays the interface of the next hop;
Via: Displays the sysid of the next hop;
SNPA: Displays the subnetwork point of attachment (MAC address of the next hop);
Start time (log output only): Displays the time that the SPF computation started;
Elapsed time (log output only): Displays the length of time required to complete the
SPF computation in seconds;
Count (log output only): Displays the number of times the SPF was triggered; and
Reason (log output only): Displays the reason that the SPF computation was
completed.
www.juniper.net
Displaying IS-IS Statistics

The show isis statistics command displays statistics about IS-IS traffic. The output fields of
this command are the following:
PDU type: Displays the protocol data unit type.
Received: Displays the number of PDUs received since IS-IS started or since the
statistics were zeroed.
Processed: Displays the number of PDUs received less the number dropped.
Drops: Displays the number of PDUs dropped.
Sent: Displays the number of PDUs transmitted since IS-IS started or since the
Rexmit: Displays the number of PDUs retransmitted since IS-IS started or since the
Total packets received/sent: Displays the total number of PDUs received and
transmitted since IS-IS started or since the statistics were zeroed.
SNP queue length: Displays the number of CSNPs and PSNPs sitting on the SNP
queue waiting for processing. This value is almost always 0.
www.juniper.net
IS-IS Chapter 559
Displaying IS-IS Statistics (contd.)
Chapter 560 IS-IS
LSP queue length: Displays the number of LSPs sitting on the link-state PDU queue
waiting for processing. This value is almost always 0.
SPF runs: Displays the number of SPF calculations performed. If this number is
incrementing rapidly, it indicates that the network is unstable.
Fragments rebuilt: Displays the number of link-state PDU fragments that the local
system has computed.
LSP regenerations: Displays the number of link-state PDUs that have been
regenerated. An link-state PDU is regenerated when it is nearing the end of its lifetime
and it has not changed.
Purges initiated: Displays the number of purges that the system initiated. A
purge is initiated if the software decides that an link-state PDU must be removed from
the network.
www.juniper.net
Displaying IS-IS Routes

The show isis route command displays the routes in the IS-IS routing table. The output of this
command includes the following fields:
www.juniper.net
Current version: Displays the number of the current version of the IS-IS routing
table.
L1: Displays the version of Level 1 SPF that was run.
L2: Displays the version of Level 2 SPF that was run.
Prefix: Displays the destination of the route.
L: Displays the level, which can be 1Level 1 only; 2Level 2 only; and 3Level 1 and
Level 2.
Version: Displays the version (or run) of SPF that generated the route.
Metric: Displays the metric value associated with the route.
Type: Displays the metric type. It can be int (internal) or ext (external).
Interface: Displays the interface to the next hop.
Via: Displays the system identifier of the next hop, displayed as a name if possible.
IS-IS Chapter 561
Displaying Detailed IS-IS Database Information

The show isis database extensive command provides detailed output for the contents of
the IS-IS LSDB. The output of this command includes the following fields:
LSP ID: Displays the LSP identifier.
Sequence: Displays the sequence number of the LSP.
Checksum: Displays the checksum value of the LSP.
Lifetime (in seconds): Displays the remaining lifetime of the LSP, in seconds.
IP prefix (detail and extensive output only): Displays the prefix advertised by this
LSP.
IS neighbor (detail output only): Displays an IS-IS neighbor of the advertising

system.
Metric (detail and extensive output only): Displays the metric of the prefix or neighbor.
The command output then displays detailed packet content information.
Chapter 562 IS-IS
www.juniper.net
www.juniper.net
IS-IS concepts and operation;
IS-IS LSP types;
IS-IS adjacency rules and troubleshooting; and
The configuration and monitoring of IS-IS in the Junos OS.
IS-IS Chapter 563
Review Questions
1.
2.
3.
4.
Chapter 564 IS-IS
www.juniper.net
Lab 4: IS-IS Configuration and Monitoring

The slide provides the objective for this lab.
www.juniper.net
IS-IS Chapter 565
Chapter 566 IS-IS
www.juniper.net

Routing
Chapter 6: Advanced IS-IS Operations and
Configuration Options
The display and interpretation of the IS-IS link-state database (LSDB);
Advanced IS-IS configuration options; and
The implementation of IS-IS routing policy.
Chapter 62 Advanced IS-IS Operations and Configuration Options
www.juniper.net
IS-IS Operations
www.juniper.net
Advanced IS-IS Operations and Configuration Options Chapter 63
Link-State PDU Flooding Scopes

Each link-state protocol data unit (PDU) in the IS-IS protocol has a specific scope within which it can be
flooded. The slide graphically displays these flooding scopes.
Note that the Level 1 link-state PDUs (LSPs) are generated within each area. Because these LSPs have a
Level 1 flooding scope, they remain within their own particular area and are not seen in other areas. The
L1/L2 router at the edge of the area places the routing information contained within the LSP into a
Level 2 LSP and forwards it across the area boundary.
All Level 2 LSPs are flooded across every contiguous Level 2 area. This flooding results in Level 2 LSPs
within every area that represent all IS-IS routes. Within Area 49.1111, for example, Level 2 LSPs exist
that represent Area 49.2222 and Area 49.3333.
www.juniper.net
Sample IS-IS Database

The example on the slide shows the details of the IS-IS database. To this point, we have been examining
small portions of the database through the use of the extensive keyword. Now, we take a step back
and examine the database as a whole. You can gather details by examining the database closely:
www.juniper.net
This router has both Level 1 and Level 2 adjacencies. You can determine this fact by the
existence of two databases on the router.
Within the Level 1 area, R1 is the router that can communicate with other Level 2
systems. You can determine this fact by the Attached keyword in its Level 1 LSP.
The R2 and R3 routers are configured to operate at Level 1 only because their
attributes are set to 0x01 (not shown in the output). Notice the L1 designation and the
absence of a L2 notation within the Attributes field.
The R3 router is the designated intermediate system (DIS) for one of its links in the
network. You can determine this fact by the extra LSP advertised as R3.02-00. The
circuit ID of the interface upon which it is the DIS is 0x02.
Dijkstra Algorithm
After a router receives a new LSP and places it into the LSDB, the router runs an algorithm known as
the Dijkstra algorithm (or shortest-path-first [SPF] algorithm). This computation uses the database as
a data source and results in a loop-free network topology using the best metric from the local router
to all nodes in the network.
database, and the tree database. Remember that the LSDB is the total compilation of routing
knowledge in the network. Conceptually, it consists of multiple tuples in the form of router ID (RID),
neighbor ID, and cost, which describe each link in the network.
When the algorithm operates, the local router moves its own local tuple into the tree database and
all tuples for its links into the candidate database. It then performs the following steps until the
candidate database is empty:
1.
For each new entry in the candidate database, the router determines the cost from root
to each neighbor ID. The SPF algorithm moves the tuple with the lowest cost from the
candidate database into the tree database. If multiple tuples exist with an equal cost,
one is chosen randomly.
2.
If a new neighbor ID appears in the tree database, any tuples in the LSDB with a router
ID equal to the new tree entrys neighbor ID are moved into the candidate database.
www.juniper.net
Dijkstra Algorithm (contd.)

3.
Each tuple in the candidate database is evaluated and any tuples whose neighbor ID is
currently in the tree database and whose cost to the root is greater than the entry
currently in the tree database are deleted. Step 1 is repeated until the candidate
database is empty.
Run on a Per-Level Basis

The Dijkstra algorithm is calculated for each LSDB present on the local router. Recall that each IS-IS
level maintains a separate copy of the database. These separate copies allow each level to have a
separate forwarding topology independent of another level.
Results Are Passed to the Routing Engine

Once the algorithm is run, the routing table on the Routing Engine receives the results in the tree
database. At this point, the Routing Engine controls the determination of whether to use any
individual IS-IS route to forward traffic. The preference value assigned to each route often handles
this choice.
The action of calculating the best IS-IS route prior to the route being placed into the routing table has
a consequence in regards to the filtering of routing knowledge. An individual filter (or policy) operates
on IP routes that enter the router as IP routes and are placed into the routing table. This form of data
flow is not present in IS-IS because the routing information enters the router as an LSP and is only
placed into the routing table after the router performs the Dijkstra algorithm. Hence, the only method
of filtering IS-IS routing knowledge is to keep that information from being placed into the database
(on a per-level basis) in the first place.
www.juniper.net

In the following slides, an example SPF calculation is displayed. This graphic shows the beginning
state of the network including the routers involved, the configured link metrics, and the LSDB. The
network and the LSDB have recently converged and the local router, RTR-A, is running an SPF
calculation to determine the shortest path to each node in the network.
www.juniper.net

RTR-A begins by moving its own local database tuple (A,A,0) into the candidate database. The total
cost from the neighbor ID to the root is calculated, which results in a 0 value. In other words, RTR-A is
directly connected to itself!
The lowest, and only, tuple in the candidate database is moved to the tree database and RTR-A
places itself on the network map.
www.juniper.net

All tuples from the most recent node added to the tree database are now added to the candidate
database. Because RTR-A is the most recent entry to the tree database, all of RTR-As tuples are
moved from the LSDB into the candidate database.
All known nodes in the tree database are removed from the candidate, of which there are none. (For
example, if B were already in the tree database, the tuple (A,B,1) would be eliminated.)
The cost to each neighbor ID from the root is then calculated. It costs RTR-A 0 to reach itself and 1 to
reach RTR-B, so the total cost to RTR-B is 1. The same calculation is done for RTR-C, and the total
cost of 2 is placed into the candidate database.
The lowest cost tuple in the candidate database, (A,B,1), is now moved to the tree database, and
RTR-B is placed on the network map.
www.juniper.net

RTR-B is the most recent entry to the tree database, so all RTR-Bs tuples are moved from the LSDB
All known nodes in the tree database are then removed from the candidate. Thus, the (B,A,3) tuple is
The cost to each neighbor ID from the root is then calculated. It costs RTR-B 3 to reach RTR-D, and it
costs 1 to reach RTR-B from the root. So the total cost to reach RTR-D from the root through RTR-B is
4.
The lowest cost tuple in the candidate database, (A,C,2), is now moved over to the tree database,
and RTR-C is placed on the network map.
www.juniper.net

Because RTR-C is the most recent entry to the tree database, its tuples are moved from the LSDB
All known nodes in the tree database are then removed from the candidate. Thus, the (C,A,4) tuple is
The cost to each neighbor ID from the root is then calculated. It costs RTR-C 4 to reach RTR-D, and it
costs 2 to reach RTR-C from the root. So the total cost to reach RTR-A through RTR-C is 6.
The lowest cost tuple in the candidate database, (B,D,3), is moved to the tree database, and RTR-D
is placed on the network map.
www.juniper.net

RTR-D, through its link to RTR-B, is the most recent entry to the tree database. Therefore, its tuples
are moved from the LSDB into the candidate database.
All known nodes in the tree database are then removed from the candidate. Thus, the (C,D,4),
(D,B,1), and (D,C,2) tuples are removed because RTR-A already has paths to RTR-B, RTR-C, and
RTR-D. The candidate database is now empty of all tuples, so the algorithm stops.
RTR-A now has a complete network map built with the total cost to each node calculated. This
information is then passed to the Junos OS routing table for its use.
www.juniper.net
Back-to-Back SPF Calculations

To enhance the convergence time of IS-IS during topology changes, the Junos OS enables the SPF
calculation to be run three times in a back-to-back fashion before encountering a mandatory
hold-down period. The 5-second hold-down timer is hardcoded into the software and is not
configurable. The timer ensures that the network can continue to forward packets with potentially
incorrect routing knowledge during the convergence period. The timer also allows the routing
process to not control the CPU at the expense of other routing functions.
Controlling the Delay Between Calculations

A configurable timer slightly delays consecutive SPF calculations. The default timer value is
200 milliseconds (ms), which you can alter with the spf-delay statement. The spf-delay
statement is supported both at the global IS-IS configuration hierarchy and within an IS-IS routing
instance. Delay values ranging from 50 ms to 1000 ms (1 second) are supported.
The mandatory 5-second hold-down timer is still brought to bear after the third consecutive rapid
SPF calculation, regardless of the spf-delay setting.
As a best practice, we recommend you set the spf-delay value slightly larger than the worst
possible propagation delay found in your network. For example, if the delay across the network is
200 ms, then you might set the spf-delay to 250 ms. This setting allows time for all of the
duplicate LSPs to arrive at all routers before the SPF calculation begins.
www.juniper.net
Full SPF Is Actually Two Steps

The IS-IS routing protocol actually performs two separate calculations during each SPF computation.
The first stage of this full SPF is the generation of a tree representing all IS nodes in the network. The
second stage then maps the advertised IP prefixes onto the IS tree for determining the shortest path
to each router. These routes are then placed into the routing table on the router.
Only Recalculate IP Reachability

If an IS-IS router begins advertising a prefix (or removes a prefix from the network), but does not alter
its IS reachability, no need exists to recalculate the IS tree for the network. This partial route
calculation (PRC) reruns only the IP reachability portion of the SPF algorithm. Each router in the
network makes the decision to run a full or partial SPF independently based on the contents of the
received LSP. Each field is examined to determine the extent of the changes (if any). Should a router
find that only IP information is changed, a PRC is scheduled and run, after which the results are
passed to the routing table on the router.
Automatically Enabled
The functionality of the PRC is automatically enabled when you configure IS-IS within the Junos OS
you do not have to do anything to benefit from the enhancement. Conversely, no configuration option
is available to disable this feature.
www.juniper.net
IS-IS Configuration Options

www.juniper.net
Small Metric TLVs

The IS-IS protocol uses 6 bits in type/length/values (TLVs)2, 128, and 130to advertise the metric
of an individual interface or external route respectively. Therefore, the largest possible metric that an
interface can be assigned is 63. Any larger value configured on the interface, or calculated using the
reference-bandwidth, is advertised as a 63 in those TLVs in all LSPs. This value does not affect the
total metric to reach a network as determined by the SPF algorithm. The algorithm adds multiple
63 values together to reach a total cost. The largest value possible for this total metric cost is 1023
to any destination in the network.
Wide Metric TLVs

With the creation of the traffic engineering TLVs (22 and 135), the concept of limiting an interface
cost to six bits was changed to allow for greater granularity and scalability. The new TLVs use 24 bits
to advertise the metric, for a maximum link cost of 16,777,215 and the field for the total cost is
expanded to 32 bits.
www.juniper.net
Only Advertise Wide Metrics

The default operation of IS-IS is to advertise both the small and wide metric TLVs in all LSPs. You can
inform the local router to use only the wide metric TLVs with the wide-metrics-only command.
This command is applied on a per-level basis and allows the local router to advertise larger metrics
using only the extended TLVs. Note that wide metrics cannot differentiate between internal and
external prefixes. As a result, the use of only wide metrics results in the automatic leaking of external
prefixes from Level 1 areas into Level 2 areas. You can use routing policy to block the leaking of
external prefixes into the backbone area if needed.
www.juniper.net
Wide Metrics Operation: Part 1

The example on the slide (as well as the following slides) shows a small IS-IS network consisting of
2 routers. Each of the routers is running only Level 2 on all of its interfaces and is using all of the
default settings.
We see that the current cost to the R2 routers loopback address of 192.168.48.1/32 is 10. This
cost accounts for the cost to reach R2 over the ge-1/1/0.0 interface (10.222.60.0/24) on R1 in
addition to the metric advertised by R2 for its loopback address (0 by default). A look at the LSDB
information advertised by R1 shows that both TLV 128 (IP prefix) and TLV 135 (IP extended prefix)
are being sent to announce the IP prefixes available on R1.
www.juniper.net

The R1 router has configured a metric value of 10,000 on its interface toward R2. After committing
the configuration, we see that the metric cost to reach R2s loopback is now 63. The LSDB shows
both TLV 128 and TLV 135 being advertised with a metric of 63, the maximum metric available to the
IP internal reachability TLV.
www.juniper.net

Sydney has now configured its Level 2 operation to use only wide metrics through the
wide-metrics-only command. The metric cost to R2s loopback address is now listed as
10,000 in the routing table. The LSDB now shows that only TLV 135 is being advertised with a metric
value of 10,000 assigned to it.
www.juniper.net
Advertisement of Metric Values

After the IS-IS process on a router decides which metric to assign to each interface, that information
is flooded into the domain within either a Level 1 LSP or a Level 2 LSP.
SPF Calculations
After receiving a new LSP from another router, the local router performs an SPF calculation using all
the values contained in the LSPs in the database. As mentioned on a previous slide, the cost is
calculated from the root node to every other node in the network using the metric cost of the
outgoing interfaces.
Routers Can Disagree

Because each router performs a separate SPF calculation, two routers on either side of a
point-to-point link can disagree on the metric of that link. The example on the slide shows that each
router has determined a different metric value for its attached links. This difference results in the
R1 router calculating a total cost of 45 (5+15+25=45) to reach the R4 router, while the R4 router
calculates a total cost of 60 (30+20+10=60) to reach R1 router.
Although the configuration of different metrics for a single link does not affect the operation of IS-IS,
asynchronous routing can occur within the network, which might cause response delays for some
end users and make troubleshooting the network challenging for network administrators.
www.juniper.net
Authentication Configured in Various Places

Within the IS-IS protocol, you can enable authentication in multiple places within the configuration
hierarchy. Each specific location encrypts certain IS-IS PDU packets. Any authentication configured
at either Level 1 or Level 2 secures all hello PDUs, LSPs, and sequence number PDUs sent by the
local router for that specific level.
Authentication at the interface level secures only hello PDUs. Again, this configuration occurs for
either Level 1 or Level 2.
Authentication Types
The Junos OS supports three different forms of authentication for the IS-IS protocol. These types are
none, simple, and Message Digest 5 (MD5). The type of authentication used must match on all
routers within a level.
MD5 Authentication Checksum

For better security in an IS-IS network, we recommend you use authentication type MD5. MD5
includes an encrypted checksum in all IS-IS packetsnot a simple text password. Each IS-IS router
uses the same MD5 algorithm to calculate the checksum value, so it virtually guarantees
interoperability and a correct result.
www.juniper.net
Level Authentication
Configuration of any authentication at either Level 1 or Level 2 secures hello, link-state, and
sequence number PDUs.
In the example on the slide, MD5 authentication is enabled for Level 1, and simple authentication is
configured for Level 2.
Note
Take care when configuring authentication on a
point-to-point interface. IS-IS uses a single hello
PDU on these interfaces (as opposed to a
broadcast interface having a Level 1 and a Level
2 hello). Thus, the local router uses the
authentication configured at the lowest level for
the hello PDUs on this interface. Potential
problems might arise if one side of the interface
is operating both Level 1 and Level 2 while the
other side is operating only Level 2.
www.juniper.net
Per-Interface Authentication
As is a common practice within the Junos OS configuration hierarchy, IS-IS authentication options
configured at an interface level supercede any options configured at a higher level.
Interface fe-0/0/0.0 on the slide has MD5 authentication configured for hello PDUs sent at Level 2
using the hello-authentication commands. This hello authentication will be used only on
that specific interface.
www.juniper.net
Selectively Disable Authentication

For easier interoperability with implementations from other vendors as well as for more control by
network operators, the Junos OS can selectively disable authentication for certain PDUs. This ability
stops both the securing of transmitted PDUs as well as the verification of received PDUs. In essence,
the router operates as if no authentication was ever configured within IS-IS for the specific PDUs
configured.
No Authentication Verification on Received PDUs

To aid you during a migration period or for troubleshooting an authentication problem, you can ignore
the verification on received packets with the no-authentication-check command.
Transmitted packets are still secured, but all received packets are used, regardless of any
authentication information contained in them.
www.juniper.net
Default IS-IS Flooding

As mentioned on previous slides, the default IS-IS operation is to flood all LSPs to any adjacent
router for a configured level.
Full-Mesh Topologies
At times, the default flooding mechanism might be a disadvantage. Such is the case with a full-mesh
physical or logical topology. In this type of an environment, each IS-IS router receives extra copies of
the same LSP. These extra copies are not needed and can be discarded safely.
In the example on the slide, the R4 router receives an LSP generated from the R1 router three times.
Mesh Group Members

The IS-IS protocol has the option of configuring a mesh group for certain peers. Once configured, the
mesh group members do not re-flood LSPs within their group. Only LSPs received from outside the
group membership are flooded within the group.
If a mesh group were configured in the example on the slide, the R4 router would receive only a
single copy of the LSP from the R1 router.
www.juniper.net
Group Numbers
To configure a mesh group within the Junos OS, assign each interface within IS-IS a group number by
using the mesh-group command. This number can be any 32-bit value. Within each local router,
any LSPs received on an interface assigned to a mesh group are not flooded out any interfaces
within that same mesh group.
Prevent All Flooding

Because the mesh-group command alters the default IS-IS flooding, you can disable all flooding
out a particular interface by using the mesh-group blocked command. This command might be
useful in an environment where a local IS-IS router might want to receive LSPs from an adjacent
neighbor but not send any LSPs to that neighbor.
[edit protocols isis]
user@router# show
interface ge-0/0/1.0 {
mesh-group blocked;
}
www.juniper.net
Avoid Transit Traffic

The concept of the overload bit was first available within the IS-IS protocol. Put simply, its function is
to advertise information into the IS-IS network, but to prevent transit traffic on the router. This
functionality can be useful in two situationsfirst, when a router must be taken out of the network for
maintenance, and second, when the router has many BGP peers. In the first case, traffic should
avoid the router because its ability to forward traffic can be compromised. In the second case, a
network administrator might want the router to fully establish its BGP peering sessions before
handling transit traffic.
When an IS-IS router is configured for overload, a bit is set to 1 within the attributes field in the LSP
header. This configuration is then visible to all other routers in the level within the LSDB.
In the example on the slide, the Router-2.00-00 LSP is advertised with the overload bit set.
Overload Settings
You can turn the overload setting on or off as a permanent value, or you can associate a timer
with it. If the timer is omitted, then the overload bit is set once you commit the configuration. The bit
remains until you remove the overload setting from the configuration, and the configuration is
committed once again. However, if you assign a timer value, the bit is not set automatically. The timer
associated with the overload bit initializes only when the routing protocol daemon (rpd) also
initializes. This timer can run from between 60 and 1800 seconds. Once the timer expires, the bit is
removed from the LSPs, but the configuration still contains the overload command.
www.juniper.net
CSNP Packets on a LAN Interface

By default, the DIS router on a LAN interface advertises a complete sequence number PDU (CSNP)
every 10 seconds. This advertisement allows other routers on the link to ensure that their databases
are complete. Perhaps more importantly, it allows the other IS-IS routers to know when the DIS is no
longer available. This fast CSNP timer allows IS-IS to not require the election of a backup DIS.
Alter the Timers

If you do not need the quick timer of the CSNP, you can change it. One possible situation where this
change might be useful is on a broadcast link with only two routers. If the DIS is not available any
longer, the other router becomes aware of this unavailability from a lost adjacency or downed
network link.
To lengthen or shorten the timer value, you can use the csnp-interval command.
On a per-interface basis, you can set the timer value as short as 1 second or as long as
65,535 seconds.
www.juniper.net
IS-IS Routing Policy

www.juniper.net
IS-IS Import Policies

Like OSPF, IS-IS is a link-state protocol. The routing table is populated by the results of the SPF
algorithm. User-defined import policies are allowed but might affect database consistency.
Default Export Policy for IS-IS

Remember that policies affect routes into and out of the routing table. The information in an IS-IS
LSP is not gathered from inet.0. Instead, the LSP is populated through the configuration of IS-IS
within the [edit protocols isis] configuration hierarchy. However, for IS-IS you can block
internal subnets as well as external subnets from entering the LSP in an export policy, essentially
overriding the inherit first term. This behavior is different from OSPF, where export policy affects only
external subnets.
www.juniper.net
Route Redistribution in IS-IS

You can add routes to an advertised LSP through an export policy. A new TLV is added to the update
for each route accepted by the policy. These types of policies often match and accept all routes from
a particular protocol. For example, the redistribute-routes-into-isis policy on the slide
advertises all RIP and OSPF routes into the network.
Routing Loop Concerns

Again, you must take care when redistributing routes between protocols to avoid a routing loop.
www.juniper.net
IS-IS Export Attributes

IS-IS can change the advertised metric value for routes redistributed into the protocol. A policy action
of then metric value changes the value in the advertised LSP.
IS-IS Route Tagging

IS-IS route tagging offers the same administrative filtering capabilities as the OSPF protocol. Route
tagging for IS-IS requires traffic engineering extensions, which are enabled by default.
The example on the slide shows an IS-IS export policy that matches all active static routes in inet.0
and advertises them into IS-IS with a metric of 40 and a route tag of 68.
www.juniper.net
Case Study Topology

The slide displays the case study topology that will be used in subsequent slides. R1, R2, and C1 all
run RIP.
www.juniper.net
Case Study Background

The slide describes the goal of the case study. The goal is to advertise a single RIP route into IS-IS as
well as send a default route to RIP.
www.juniper.net
Create a Policy for the RIP Route

The first step is to create a policy and apply the policy to IS-IS. In this case, two match conditions
were used, creating a logical AND. This policy will then be applied under the [edit protocols
isis] hierarchy by performing a set protocols isis export redistribute-rip
command.

The next step is to redistribute the default IS-IS route into RIP using an export policy under RIP. We
will use two match conditions again. This policy will be applied under [edit protocols rip].
www.juniper.net

By default, RIP has a lower preference than IS-IS external routes. Because RIP has a better
preference, the default route for RIP is preferred. In this sample network, this preference creates a
loop, because the IS-IS routers point to the RIP router as its gateway while the RIP router points to the
IS-IS routers.
To fix the loop, modify the IS-IS route preference to a lower value than the RIP route.
www.juniper.net
The Result
The result of the preference change is now a default that points properly to the IS-IS router.
www.juniper.net
Junos OS Supports Large Numbers of Routes

IS-IS implementations can encounter problems when large numbers of external routes are injected
into the LSDB. The Junos OS has great protocol stability and handles these external routes without
failing. However, a configuration mistake could make a portion of your network unusable, because
only the Juniper Networks routers would be left operating.
Limit External Routes

To help network administrators when a configuration mistake occurs, the Junos OS allows a limit to
be placed on the number of external routes exported into IS-IS. The prefix-export-limit
command informs the router how many routes to accept using a routing policy configuration. You
configure this option at a specific level using a 32-bit value, which provides a range of routes from
1 to 4,294,967,295. Once the route limit is reached, the router transitions into an overload state
where the bit is set in all LSPs. The external routing information is no longer transmitted in the LSPs
as well. The local router remains in this state until the number of external routes returns to a level
below the configured limit. This level reduction requires the administrator to manually change the
existing configuration; either the number of advertised routes must be reduced or the routing policy
must be changed.
www.juniper.net
www.juniper.net
The display and interpretation of the IS-IS LSDB;
Advanced IS-IS configuration options; and
The implementation of IS-IS routing policy.
Review Questions
1.
2.
3.
www.juniper.net
Lab 5: Advanced IS-IS Configuration Options and Routing Policy

www.juniper.net
www.juniper.net

Routing
Chapter 7: Multilevel IS-IS Networks
The default operation in a multilevel IS-IS network;
IS-IS address summarization methods; and
The configuration and monitoring of a multilevel IS-IS network.
Chapter 72 Multilevel IS-IS Networks
www.juniper.net
Level 1 and Level 2 Operations

www.juniper.net
Multilevel IS-IS Networks Chapter 73
IS-IS Level 2 Operation

As discussed in a previous chapter, the IS-IS protocol advertises either a Level 1 LSP or a Level 2 LSP
for each adjacency formed with a neighbor. The type of LSP advertised depends on the level at which
the adjacency is formed.
Also recall that an IS-IS Level 1 LSP can be flooded only within a specific area because a Level 1
adjacency cannot form across an area boundary. Level 2 LSPs include the routing information
carried in Level 1 LSPs, which results in the L2 backbone knowing routes for all areas and levels.
In the example on the slide, routing information from all routers is present in all databases in the
network. The presence of a single L2 database shared by all routers occurs because all of the
adjacencies in the network are at Level 2, and Level 2 LSPs are flooded both within, and across, IS-IS
area boundaries.
www.juniper.net
IS-IS Level 1 Operation

This slide details a single area Level 1 IS-IS network. In this example, all routers in the network share
a Level 1 database containing identical information. The presence of a common Level 1 database in
all routers occurs in this case because all adjacencies are Level 1 in nature, and all routers are
within the same IS-IS area (49.4444). Level 1 LSP flooding will reach all routers in the network
because of the single area.
www.juniper.net
Multilevel IS-IS Operation

In this example, routing information for each router is present in all Level 2 databases in the network.
This routing information is present because Level 1 routing information is summarized at the L1/L2
boundary and flooded throughout the Level 2 backbone in Level 2 link-state protocol data units
(PDUs). The Level 1 routers within each Level 1 area have a single Level 1 database that contains
routing information for that area only. The Level 1 routers use the attached bit in an advertised
Level 1 link-state PDU (LSP) to install a local default route. The Level 1 router forwards packets to the
metrically closest attached router when routing to destinations outside of their Level 1 area.
Level 1 routers are isolated from routing changes in other areas, and summarization of Level 1
information prevents Level 2 routers from having to perform a full SPF calculation for topology
changes within a Level 1 area. This isolation and summarization of routing information improves the
scalability of a multilevel IS-IS network.
www.juniper.net
Multilevel IS-IS Operation Is Similar to OSPF NSSA

You can readily compare the operation of a multiarea IS-IS network to an OSPF not-so-stubby area
(NSSA) with the no-summaries and default-metric options configured. In a multiarea IS-IS
network, each Level 1 IS-IS router has complete routing knowledge of the routes local to its Level 1
area only. Level 1 routers reach other IS-IS destinations by using a 0.0.0.0/0 default route generated
by the detection of L1/L2 attached routers. As with an OSPF NSSA, you can inject external routing
information into the Level 1 area. The Level 2 LSPs of the attached routers in the area advertise the
internal Level 1 routes to other IS-IS Level 2 areas.
L1/L2 Border Router Is a Natural Boundary

Although a Level 2 LSP advertises all Level 1 internal routes, routing information for the Level 2
backbone is constrained by the L1/L2-attached router. Thus, Level 2 routes are not advertised into
the Level 1 area by default; hence the need for a default route in the Level 1 area. Level 1 routes
advertised as external routes into Level 1 are not advertised to any Level 2 routers by default; routing
policy is needed to effect the leaking of Level 1 externals into the L2 backbone. Note that the use of
wide-metrics-only alters the natural L1/L2 boundary in that routes are no longer
distinguishable as being internal or external. The use of wide metrics therefore results in the
automatic leaking of all Level 1 routes into Level 2, because they will all appear to be internal routes.
www.juniper.net
L2 Routers Set the Attached Bit

To provide interarea reachability for Level 1 routers, an L1/L2 router with a Level 2 adjacency to a
router in another area sets its attached bit in its Level 1 LSPs. Level 1 routers install a 0.0.0.0/0
default route to the metrically closest attached router when they detect Level 1 LSPs with the
attached bit set. Note that while each possible metric type (default, delay, expense, and error) is
associated with its own attached bit, the Junos OS supports only the default metric type.
You can disable the generation of a default route by including the ignore-attached-bit
statement at the [edit protocols isis] configuration hierarchy.
www.juniper.net
Ignoring the Attached Bit

In some corner situations you might want to prevent the installation of a default route based on the
presence of Level 1 LSPs with attached bits. The slide provides an example of one such application
in which a multilevel IS-IS network with Level 2 to Level 1 route leaking in place.
Because the leaking of Level 2 routing information into the Level 1 areas provides all routers with
complete IS-IS routing information, a default route is no longer needed for routing to destinations
outside of a given Level 1 area. Because the goal of a multilevel IS-IS design is normally to reduce
database size for routers in Level 1 areas, you might ask yourself why someone would design a
multilevel IS-IS topology only to leak Level 2 routes into Level 1.
In this example, the network operator wants to leverage the built-in LSP flooding scope of a multilevel
IS-IS network to provide some level of isolation in the event that a malformed LSP is generated. For
example, if a malformed Level 1 LSP is generated in area 49.7777, this LSP will not be flooded into
the Level 2 backbone (the contents of Level 1 LSPs are repackaged into a Level 2 LSP for
submission to the Level 2 backbone by an attached router, but the Level 1 LSP itself is not flooded
into Level 2).
Another application for the ignore-attached-bit option relates to the fact that using the
metrically closest attached router might not always yield optimal interarea routing. In these cases it
might be desirable to use a locally defined static or generated route, in which case the IS-IS derived
default route might no longer be needed.
www.juniper.net
Multilevel Configuration
www.juniper.net
IS-IS Interfaces Operate in L1/L2 Mode

The default operation of the IS-IS protocol within the Junos OS is to enable both Level 1 and Level 2
capabilities for all interfaces. This default behavior is designed to promote connectivity with all
neighbors. If an adjacency can be formed between two routers, it will. One consequence of this
default, however, is that you might form both a Level 1 and a Level 2 relationship with a given
neighbor, which results in two separate adjacencies and two separate LSP flooding topologies.
To disable the operation of a particular level on an interface, use the disable keyword as shown on
the slide. The so-0/0/0.0 interface only operates at Level 2, and the ge-0/1/0.0 interface only
operates at Level 1. As a shortcut, you can disable all Level 1 or Level 2 processing on the router,
which will result in all interfaces being Level 2, or Level 1, respectively. For example, the set
protocols isis level 1 disable statement will result in all interfaces operating at Level 2
only.
We recommend that you explicitly configure the lo0.0 interface within the IS-IS protocol, even when
the router's network entity title (NET) is assigned to another interface. Although its omission does not
harm the operational aspects of IS-IS (adjacencies still form), the IP address configured on the lo0
interface will not be advertised in TLV 128 or TLV 135, making the loopback address unreachable.
Note that in most cases you must run the IS-IS protocol on the lo0 interface for proper operation
because the routers NET is normally assigned to loopback interface for resiliency reasons.
www.juniper.net
IS-IS Interfaces Operate in L1/L2 Mode (contd.)

Because the loopback interface operates in passive mode, you do not need to disable a particular
level on that interface. By default, the IP address on the interface is advertised in both the Level 1
and Level 2 LSPs generated by the router. You can restrict the advertisement of the routers
loopback address in a particular level by disabling that level in the lo0.0 statement in the isis
stanza.
www.juniper.net
Case Study: Route Leaking

As previously discussed, Level 2 routes are not advertised into Level 1 areas by default. In this
example, the network operator wants to advertise, or leak, Level 2 routes into Area 49.0001. This
action will require a routing policy on R2, the L1/L2 area border router (ABR), specifying that the
matching routes are Level 2 and will be advertised in Level1.
www.juniper.net
Policy Used to Advertise Routes

Because the L1/L2 border router naturally stops the transmission of Level 2 routes into a Level 1
area, it is the logical location to override that default. You can accomplish this goal with a Junos
routing policy.
You configure this policy within the [edit policy-options] configuration hierarchy, and then
apply the policy to the IS-IS instance at the global IS-IS level, that is, [edit protocols isis].
In the example on the slide, the match criterion within the route-leak policy is all IS-IS routes
within the subnet 192.168.16.0/20 that are currently Level 2 routes and are eligible to be sent to
Level 1. Once these routes are found, the configured action is to accept these routes. The use of the
from and to keywords allows granular control about the desired direction of route leaking.
Once the routing policy is exported into the IS-IS protocol, the Level 2 routes are inserted into the
Level 1 LSP of the L1/L2 border router and are advertised into the Level 1 area.
Recall from a previous slide that the L1/L2 border router also blocks external Level 1 routes from
being advertised into Level 2. A similar policy is used to advertise Level 1 external routes into the
Level 2 backbone. This new policy simply reverses the Level 2 and Level 1 notations and makes use
of an appropriate route filter statement. Once you apply this policy, the external routes are included
in the Level 2 LSPs.
www.juniper.net
Up/Down Bit Prevents Looping

Previous slides described the default action of an L1/L2 router with regard to the advertisement of
internal Level 1 routes within its Level 2 LSP. Conceptually, the policy referenced on the slide could
interact with this default action to create a routing loop.
For example, consider the case illustrated on the slide. If R1 has a policy to advertise Level 2 routes
into Level 1, then R1 will include the Level 2 routes in its Level 1 LSP. As this LSP is flooded
throughout the Level 2 area, it eventually arrives at R2. R2 has a policy in place that will leak Level 2
LSPs into its Level 1. Eventually, this information makes it way around to R4. If R4 advertises the
Level 2 routes back into Level 2, a routing loop can form.
The potential for route leaking-induced routing loops is averted by a bit in the LSP known as the
up/down (U/D) bit. The purpose of this bit is to inform the L1/L2 routers whether a configured policy
can advertise a route. Only routes marked with the up direction are eligible for advertisement from
Level 1 to Level 2. All internal Level 1 routes will have the up/down bit set in this manner. If the
up/down bit is set to down, the route has already been leaked from Level 2 into a Level 1 area and,
as such, the route cannot be sent back into the Level 2 backbone by R4.
www.juniper.net
Summarize Routes at the L1/L2 Router

Routes that are naturally bound by the L1/L2 border router are eligible for route summarization.
These routes include external Level 1 routes and Level 2 routes from other IS-IS areas. In addition,
you can also summarize internal Level 1 routes that are normally advertised into Level 2
automatically.
Create an Aggregate Route and Advertise It with Policy

No concept of an area-range command exists in IS-IS. To summarize routes, you must create an
aggregate route on the L1/L2 border router within the [edit routing-options] hierarchy that
encompasses the routes you want to summarize.
To advertise the aggregate route, you create a policy similar to the example shown on the slide. This
policy is applied as an export to the IS-IS instance at the global [edit protocols isis] level.
In this example, the goal is to advertise a 172.16.20.0/22 aggregate into the Level 2 backbone to
represent Level 1 external routing information in the Level 1 area.
When summarizing routes from one level into another, you might need to alter the default IS-IS
export policy to ensure that specific prefixes are not advertised along with the corresponding
aggregate. You can accomplish the altering of the export policy with a reject action associated
with a route filter that will match on the specific routes in question.
www.juniper.net
Internal Level 1 Route Summarization

Internal Level 1 routes are automatically advertised in a Level 2 LSP into the Level 2 backbone. The
Junos OS provides a method for altering this default action with a routing policy. The example on the
slide shows that the Level 1 Area 49.0001 contains multiple internal routes within the 10.0.4.0/22
address space. These routes are currently advertised individually to R3, as shown in the following
output:
user@R3# show route 10.0.4/22
inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.4.12/30
10.0.5.0/24
10.0.6.1/32
*[IS-IS/18] 00:28:50, metric 20

> to 10.0.2.2 via ge-0/2/1.0
*[IS-IS/18] 00:28:50, metric 30
> to 10.0.2.2 via ge-0/2/1.0
*[IS-IS/18] 00:28:50, metric 20
> to 10.0.2.2 via ge-0/2/1.0
Administratively, we want to suppress these specific internal Level 1 routes while advertising a single
10.0.4.0/22 summary in their place. We accomplish this configuration by using a combination of a
routing policy and a local aggregate route defined on R2.
www.juniper.net
Level 1 Route Summarization Policy

The sample policy shown on the slide meets our administrative requirements of advertising only a
single summary route for the internal Level 1 routes. The first term in the policy matches and accepts
the locally defined summary route on R2 for advertisement to the Level 2 backbone. The second
policy term serves to override the default IS-IS export policy for routes matching the 10.0.4.0/22
route filter. It specifies that these routes will not be advertised to R3 in the Level 2 LSP generated by
R2.
After applying the internal-L1-summary-route policy as an export policy in R2s IS-IS
instance, we can confirm its success on R3:
user@R3# show route 10.0.4/22
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.4.0/22
*[IS-IS/165] 00:00:20, metric 20

> to 10.0.2.2 via ge-0/2/1.0
www.juniper.net
Apply Export Policy at Global Level of the IS-IS Instance

One or more export policies can be applied at the global level of an IS-IS instance, as shown on the
slide. Both the external-L1-summary-route and internal-L1-summary-route policies
will be used to control the routes advertised by the local router.
When wanted, you can apply multiple export policies to the same IS-IS instance. The same effect is
normally possible through the use of a single policy containing multiple terms, but in some cases it
might be easier to reuse existing policies in such a manner. Note that normal policy processing will
proceed from left to right, and that policy processing will terminate once a given route meets with
either an accept or reject action.
www.juniper.net
The default operation of a multilevel IS-IS network;
IS-IS summarization methods; and
The configuration and monitoring a multilevel IS-IS network.
www.juniper.net
Review Questions
1.
2.
3.
4.
www.juniper.net
Lab 6: Configuring a Multilevel IS-IS Network

www.juniper.net

Routing
Chapter 8: BGP
Chapter 82 BGP
Basic BGP operation;
Common BGP attributes;
The route selection process;
The alteration of the route selection process; and
The configuration of some advanced options for BGP peers.
www.juniper.net
Review of BGP
www.juniper.net
BGP Chapter 83
What Is BGP?
The Border Gateway Protocol (BGP) is a routing protocol between autonomous systems (ASs) and is
sometimes referred to as a path-vector routing protocol because it uses an AS path, used as a
vector, to prevent interdomain routing loops. The term path vector, in relation to BGP, means that
BGP routing information includes a series of AS numbers, indicating the path that a route takes
through the network. Although BGP is primarily used for inter-AS routing, BGP is also used in large
networks for MPLS-based VPNs and is used to separate large OSPF domains. BGP is much more
scalable and offers a greater amount of control through policy than an IGP.
BGP exchanges routing information among ASs. An AS is a set of routers that operate under the
same administration. BGP routing information includes the complete route to each destination. BGP
uses the routing information to maintain an information base of Network Layer reachability
information (NLRI), which it exchanges with other BGP systems.
BGP is a classless routing protocol, that supports prefix routing, regardless of the class definitions of
IP version 4 (IPv4) addresses. BGP routers exchange routing information between peers. The peers
must be connected directly for inter-AS BGP routing (unless certain configuration changes are done).
The peers depend on established TCP connections, which we address later in this chapter.
BGP version 4 (BGP4) is essentially the only exterior gateway protocol (EGP) currently used in the
Internet. It is defined in RFC 4271, which made the former standard of more than 10 years,
RFC 1771, obsolete.
Chapter 84 BGP
www.juniper.net
When Should I Use BGP?

Networks with a single upstream connection receive little benefit from running a dynamic routing
protocol with their Internet service provider (ISP). These customers typically use a static default route
to send all external traffic toward the Internet. Their provider also typically uses a static route to
direct traffic destined for the customers addresses to the customer. Normally, a single-homed
network uses addresses assigned by the provider from the providers aggregate. Because these
addresses are assigned to the provider and can only be used by the customer while they are a
customer of the provider, they are known as nonportable addresses. Using these addresses allows
the provider to announce a single aggregate route for many customer networks, reducing global
routing table growth. Currently, the Internet routing table contains hundreds of thousands of routes,
which highlights the need for a scalable and robust protocol such as BGP.
BGP is normally used when a network has multiple upstream connections, either to a single ISP or to
multiple ISPs. BGPs policy controls provide the ability to optimize inbound and outbound traffic flows
based on a networks technical and business constraints. Although BGP can detect and route around
failures in redundant environments, BGP sessions within the same AS do not typically react as
quickly as an IGP, and they often rely on the IGP used in the AS to remain operational when failures
occur.
Networks that are multihomed to a single ISP likely use nonportable addresses assigned by the
provider. Networks that are multihomed to multiple ISPs are likely to use portable addresses
assigned directly by the regional address registry.
www.juniper.net
BGP Chapter 85
EBGP and IBGP Peers

BGP supports two different types of exchanges of routing information. Exchanges between ASs are
known as external BGP or EBGP sessions and handle inter-AS routing. Exchanges within an AS are
known as internal BGP or IBGP sessions, and handle intra-AS routing.
An EBGP peer connection is between a device in one AS and another device in a different AS. The
connection between the two ASs consists of a physical connection and a BGP connection. The
physical connection is a shared Data Link Layer subnetwork between the two ASs. On this shared
subnetwork, each AS has at least one border gateway belonging to that AS. The BGP connection
exists between BGP speakers in each of the ASs. This session can communicate destinations that
can be reached through the advertising AS. The EBGP connection typically is established between
immediately connected devices located in two different ASs because the time-to-live (TTL) value of
the EBGP packets is equal to 1, by default.
An IBGP connection is typically established between loopback interfaces of the routers not
immediately connected (of course, everything depends on the ASs topology). BGP uses the loopback
interfaces for stability reasonsthese interfaces are always alive, unless the router itself dies.
Because the IBGP connection typically exists between remotely connected routers, an IGP is required
within the AS. BGPs TCP session is established using regular routing tables.
Chapter 86 BGP
www.juniper.net
BGP Peering Sessions

Unlike other dynamic protocols, BGP requires that you manually define the neighbors with which you
want the local device to peer. Because BGP peers must be manually defined, no automatic neighbor
discovery exists as with other protocols.
BGP uses TCP as its transport protocol (port 179). TCP provides a full-duplex, connection-oriented,
reliable, byte-stream service to BGP. BGP considers a connection between two peers to be idle until a
TCP connection is established between them. With the TCP connection established, the endpoints
are assured of a reliable connection. The following list describes the various BGP neighbor states:
Idle: The Idle state is the initial state when all incoming BGP connections are refused. A
start event is required for the local system to initialize BGP resources and prepare for a
transport connection with the other BGP peer.
Connect: In the Connect state, BGP is waiting for the transport protocol connection to
be completed. If the transport protocol connection succeeds, the local system sends an
Open message and transitions to the OpenSent state. If the transport protocol
connection fails, the local system restarts the ConnectRetryTimer, searches for a
connection initiated by the remote BGP peer, and changes its state to Active.
www.juniper.net
BGP Chapter 87
BGP Peering Sessions (contd.)
Chapter 88 BGP
Active: In the Active state, BGP is trying to acquire a peer by initiating a transport
protocol connection. If the transport protocol connection succeeds, the local system
sends an Open message to its peer and transitions to the OpenSent state. If the local
systems BGP state remains in the Active state, you should check physical connectivity
as well as the configuration on both peers.
OpenSent: In the OpenSent state, BGP waits for an Open message from its peer. When
an Open message is received, it is checked and verified to ensure that no errors exist. If
an error is detected, the system transitions back to the Idle state. If no errors are
detected, BGP sends a Keepalive message.
OpenConfirm: In the OpenConfirm state, BGP waits for a Keepalive or Notification

message. If no Keepalive message is received before the negotiated hold timer expires,
the local system sends a Notification message stating that the hold timer has expired
and changes its state to Idle. Likewise, if the local system receives a Notification
message, it changes its state to Idle. If the local system receives a Keepalive message,
it changes its state to Established.
Established: In the Established state, BGP can exchange Update, Notification, and
Keepalive messages with its peer. When the local system receives an Update or
Keepalive message and when the negotiated hold timer value is nonzero, it restarts its
hold timer. If the negotiated hold timer reaches zero, the local system sends out a
Keepalive message and restarts the hold timer.
www.juniper.net
BGP Message Types

BGP processes a message only after the entire message is received. The maximum message size is
4096 octets; the smallest BGP message is a header without any data, or 19 octets. The following list
details the BGP message types:
Open: The open message is sent once the TCP three-way handshake is complete. The
open message initiates the BGP session and contains details about the BGP neighbor
and information about supported and negotiated options.
Update: BGP uses update messages to transport routing information between BGP
peers. Depending on the receiving devices routing policy, this routing information is
either added to the routing table or ignored.
Keepalive: BGP does not use keepalives at the Transport LayerTCP fills this need.
Instead, peers exchange keepalives as often as needed to ensure that the hold timer
does not expire.
www.juniper.net
BGP Chapter 89
BGP Message Types (contd.)
Notification: BGP uses notification messages to signal when something is wrong with
the BGP session. A notification is sent when an unsupported option is sent in an open
message and when a peer fails to send an update or keepalive. When an error is
detected, the BGP session is closed.
Refresh: Normally a BGP speaker cannot be made to readvertise routes that have
already been sent and acknowledged (using TCP). The route refresh message supports
soft clearing of BGP sessions by allowing a peer to readvertise routes that have already
been sent. This soft clearing has some very specific uses when working with
MPLS-based VPNs and adding new customer sites to existing customer VPN structures.
Each BGP message uses the same fixed size header, which is 19 bytes. BGP keepalive messages do
not include any data portion following the header.
Chapter 810 BGP
www.juniper.net
BGP Update Messages

BGP update messages describe a single path and then list multiple prefixes that can be reached
through this same path. BGP peers assume that this information is unchanged unless a subsequent
update advertises a new path for a prefix or lists the prefix as unreachable. Updates can list any
prefixes that are no longer reachable, regardless of the path associated with those prefixes. BGP
peers use update messages to ensure that their neighbors have the most up-to-date information
about BGP routes.
BGP uses TCP to provide reliable communication, which ensures that BGP neighbors never miss an
update. A system of keepalives also allows each BGP peer to ensure that its neighbor is still
functioning properly. If a neighbor goes down, the BGP speaker deletes all routes learned from that
peer and updates its other peers accordingly.
BGP uses the information within the update messages, in particular the BGP attributes, to detect
routing loops and determine the best path for a given destination prefix.
www.juniper.net
BGP Chapter 811
BGP Attributes
The primary purpose of BGP is not to find the shortest path to a given destination; rather, its purpose
is to find the best path. Each AS determines the best path to a prefix by determining its own
outbound routing preferences, the inbound routing preferences of the routes originator (as updated
by ASs along the path between the source and destination ASs), and some information that is
collected about the path itself. All this information is contained in path attributes that describe the
path to a prefix. The path attributes contain the information that BGP uses to implement the routing
policies of source, destination, and transit ASs.
The slide lists some common BGP attributes. We cover the listed attributes in greater detail on
subsequent pages.
Chapter 812 BGP
www.juniper.net
High-Level BGP Example

The example on the slide explains the operation of BGP at a very high level. Consider the way traffic
is routed to Customer A. Customer A has a single connection to ISP A. ISP A has assigned Customer A
a prefix (172.20.21.0/24) from its aggregate address range (172.20.0.0/16).
Because Customer A is a single-homed network, it has a static default route to reach all destinations
on the Internet through its connection to ISP A. Likewise, ISP A has a static route to reach
Customer As prefix.
www.juniper.net
BGP Chapter 813
ISP As Network
The slide highlights a portion of ISP As network. Internally, ISP A maintains reachability information
for each prefix within its aggregate address range. Therefore, every router in ISP A has knowledge
about the /24 prefix assigned to Customer A. This reachability information can be maintained by
either an IGP or by IBGP.
Even though ISP A has reachability information about each prefix internally, it advertises the
aggregate prefixes externally only. Because other networks use the same path to reach all prefixes
available on ISP As network, other networks do not need the more specific information. To reduce
the size of the global routing table, ISPs typically do not transmit the prefixes of their statically routed
customers to their peers; rather, they just transmit the aggregate prefixes from which their
addresses are assigned.
Chapter 814 BGP
www.juniper.net
ISP A Advertises Its Aggregate

ISP A advertises its aggregate address range of 172.20.0.0/16 through BGP along with some
information about the path to reach that route. One of these path attributes is the AS path, which is
a list of the autonomous systems through which the path to this aggregate passes. By examining the
AS path, ISP B knows that the 172.20.0.0/16 network was originated within ISP A.
ISP B then advertises the 172.20.0.0/16 prefix to ISP C. It updates the path attributes, including the
AS path, when it transmits the route. ISP C further advertises this prefix to Customer B, again
updating the path attributes when it transmits the route.
www.juniper.net
BGP Chapter 815
Customer Bs Aggregate
Customer B is currently a single-homed network but is planning on adding a second connection to
another ISP in the near future. Customer B advertises its portable /20 prefix to ISP C with an
AS path, indicating that it was originated locally. ISP C sends the advertisement to ISP B, who sends
it to ISP A, with each ISP updating the path attributes as it sends the route.
ISP A does not have a BGP session to Customer A, so Customer A does not receive any routing
information for Customer Bs prefix. However, receiving the route information is not necessary
because Customer A has a static default route that directs all Internet-bound traffic to ISP A. Once
the traffic reaches ISP A, ISP A follows the BGP-received route to Customer B.
Chapter 816 BGP
www.juniper.net
Customer B Becomes Multi-Homed

Customer B decides to add a connection to ISP B. Therefore, Customer B now advertises its prefix to
both its providers. In this example, ISP B receives routing information for Customer Bs prefix both
from ISP C and directly from Customer B. ISP B chooses one of the paths as the best path and places
a corresponding route for the prefix in the routing table. It then advertises the prefix with the
associated path attributes to ISP A. Because ISP B chose the path directly to Customer B as the best
path, it advertises the path attributes associated with that advertisement to ISP A. Note that it
advertises an AS path that reflects that it can directly reach Customer B and does not include any
information about ISP C. Because the path through ISP C was not chosen as the best path, ISP B
does not send ISP A any of the path attributes associated with the advertisement from ISP C.
If ISP B ceases to hear the announcement about Customer Bs prefix directly from Customer B (for
example, because the circuit fails), it will begin using the path it received from ISP C and will send
updated announcements to its peers to reflect the new path.
Although not shown, Customer B now also receives two advertisements for ISP As aggregate. It
chooses one of those advertisements as the best path and installs a corresponding route in the
routing table.
We cover the path selection process and many of the BGP attributes in greater detail later in this
chapter.
www.juniper.net
BGP Chapter 817
Loopback Peering
You maintain only one IBGP session between each internal peer. The IGP is used to maintain
reachability between the loopback addresses regardless of the physical topology, allowing the IBGP
sessions to stay up even when the physical topology changes.
The physical topology is relevant in one respect: each router along the path between BGP speakers
must have enough information to make consistent routing decisions about packet forwarding. In
many cases, this requirement means that all routers along all possible physical paths between BGP
speakers must run BGP; however, in some networks this requirement is not necessary.
Interface Peering
Recall that EBGP sessions are simply BGP sessions between two routers in different autonomous
systems. When two EBGP peers have a single path between them, EBGP sessions are usually
established over the shared subnet between two peers, using the IP addresses assigned to the
interfaces on that subnet as the session endpoints. By establishing the EBGP session using the IP
address assigned to the interfaces on the shared subnet, you gain many advantages. One of these
advantages is that you prevent either AS from needing to maintain any routing information about the
other AS (besides what it received through BGP). You also ensure that all traffic flows over this
particular shared subnet.
Chapter 818 BGP
www.juniper.net
Configuring BGP
The slide illustrates the sample configuration.
In this configuration example, we see some parameters defined under the [edit
routing-options] and [edit protocols bgp] hierarchies. Under the [edit
routing-options] hierarchy, we defined the systems router identifier (RID) and the local AS
number. Optionally, you can configure the systems local AS number under the global BGP hierarchy
for a specific BGP group, or, for a specific BGP neighbor, use the local-as configuration option.
When the AS number is configured at multiple hierarchy levels, the AS number specified at the most
specific hierarchy level is used. The ability to specify different AS numbers at different hierarchy
levels can be quite useful, especially when merging networks with different AS numbers.
Because we are using loopback-based peering for the internal BGP group, we must reference
loopback addresses in the related BGP configuration. In this case, the neighbor address is the
remote peers loopback address. The local-address is the local devices loopback address. If
the local address is not specified, the system uses the interface address of the egress interface
used to reach the referenced peer address. Because the peer is expecting to form an IBGP peering
session using the 192.168.100.1 address, you must specify that address as the local-address
in the configuration.
www.juniper.net
BGP Chapter 819
Configuring BGP (contd.)

As mentioned on the slide, the session type determines whether the peering session is IBGP or
EBGP. You specify an external session type for EBGP and an internal session type for IBGP. If
you omit the session type, you must specify the peer-as number, which can be a remote AS
number or the local AS number. If the specified AS number does not match the AS number defined
on the router, BGP assumes the session type is external. If the specified AS number does match the
AS number defined on the router, BGP assumes the session type is internal. The software notifies
you if you did not include the required details, as shown in the following sample output:
[edit protocols bgp]
user@router# show
group x100 {
neighbor 10.1.1.1;
}
user@R1# commit
[edit protocols]
'bgp'
Error in neighbor 10.1.1.1 of group x100:
peer AS number must be configured for an external peer
error: configuration check-out failed
Chapter 820 BGP
www.juniper.net
BGP Authentication
All BGP protocol exchanges can be authenticated to guarantee that only trusted routing devices
participate in the ASs routing. By default, authentication is disabled. You can configure Message
Digest 5 (MD5) authentication. The MD5 algorithm creates an encoded checksum that is included in
the transmitted packet. The receiving routing device uses an authentication key (password) to verify
the packets MD5 checksum.
Hitless Key Rollover

Hitless authentication key rollover allows users to choose the algorithm through which
authentication is established. The user associates a keychain and an authentication algorithm with a
BGP neighbor session. The keychain includes multiple keys. Each key contains an identifier and a
secret. The key is also configured with a unique start time and an end time.
authentication-key-chain bgp key chain
group int-65503 {
type internal;
local-address 192.168.100.1;
neighbor 192.168.100.2
}
www.juniper.net
BGP Chapter 821
Hitless Key Rollover (contd.)

[edit security]
authentication-key-chains {
key-chain bgp key chain {
key 1 {
secret juniper1;
start-time 2011-03-01.02:00:00;
}
key 2 {
secret juniper2;
start-time 2011-04-01.02:00:00;
}
}
}
Chapter 822 BGP
www.juniper.net
BGP Operations
www.juniper.net
BGP Chapter 823
BGP Route Tables

BGP uses three different storage tables known as routing information bases (RIBs) as databases to
maintain routing knowledge. A separate Adjacency-RIB-IN table exists for each established BGP peer
to store all routes received from that peer. The RIB-LOCAL table is where BGP stores routes used for
traffic forwarding. A separate Adjacency-RIB-OUT table is also created for each established BGP peer
to house the routes that are to be advertised to that peer.
BGP Active Routes

BGP can move only active BGP routes in the routing table into the Adjacency-RIB-OUT tables and
advertise them to BGP peers. In addition, BGP places only the single, best BGP path to each
separate IP route destination in the RIB-LOCAL and Adjacency-RIB-OUT tables.
At times, the best BGP path might not be advertised to a peer because the local routers routing
table rules. For example, if the router knows about a particular route through both IS-IS and BGP, the
IS-IS route will be active in the local routing table because of the default Junos OS protocol
preference values. Therefore, the BGP version of that route is not sent to any peers because BGP
advertises only active routes (routes used by BGP). To override this default action, you can use the
advertise-inactive command. This command always forces the advertisement of the single,
best BGP path to any destination, regardless of whether the route is currently active in the local
routing table.
Chapter 824 BGP
www.juniper.net
Default BGP Advertisement Rules

By default, only active BGP routes are advertised. The slide illustrates the default BGP advertisement
rules. The rules are as follows:
1.
IBGP peers advertise routes received from EBGP peers to other IBGP peers.
2.
EBGP peers advertise routes learned from IBGP or EBGP peers to other EBGP peers.
3.
IBGP peers do not advertise routes received from IBGP peers to other IBGP peers.
The purpose of the advertisement rules is to prevent routing loops on a BGP network.
www.juniper.net
BGP Chapter 825
IBGP Route Propagation

IBGP speakers send routes to their IBGP peers that they received from EBGP peers and routes that
they originated themselves. IBGP speakers never send routes to IBGP peers that they learned from
other IBGP peers. For all IBGP speakers in an AS to have consistent routing information, a full mesh
of IBGP sessions must exist between all BGP speakers. Without this full mesh, some BGP speakers
might not receive all the required routing information.
In the example on the slide, a full mesh of IBGP sessions does not exist. R1 receives the
announcement through an EBGP session. Because it is the best route it has for that prefix, it
propagates the route to its IBGP peer R2. R2 also determines that route to be its best path for the
prefix; however, it does not send the route to its IBGP peer R3. Because it received the route through
IBGP, it cannot send the route to any IBGP peers. Therefore, R3 does not receive or install a route for
the prefix advertised from AS 65502. This situation can be alleviated by adding an IBGP session
between R1 and R3. (Whether the two routers are directly connected is irrelevant.)
If IBGP routers readvertised IBGP routes to other IBGP peers, a loop would form. Because the AS
path is not updated by each router, but rather only when the associated prefix is advertised to an
EBGP peer, the AS path cannot be used to detect loops for BGP routes advertised within an AS. For
this reason, BGP enforces advertisement rules that require the full-mesh peering of IBGP routers to
ensure consistent routing information on all IBGP routers within the AS.
Using route reflectors or confederations can also alleviate this situation, both of which can reduce or
alleviate the full-mesh requirement. Route reflectors and confederations will be covered in a later
chapter of this class.
Chapter 826 BGP
www.juniper.net
Hidden Routes
You might expect all routes received from a BGP peer would be installed in the RIB-LOCAL table and
be visible using the show route protocol bgp command. But hidden BGP routes occur for
several reasons:
The route might be a martian route;
An import policy might exist that prevents the route from being installed; or
The routes protocol next-hop might be unresolvable.
Unresolvable Next-Hop
The most common reason for hidden BGP routes is an unresolvable next-hop. The BGP Update
message contains a protocol next-hop IP address. If the router cannot resolve this address using its
routing table, the route cannot be used and is not installed in the routing table.
The number of hidden routes is always shown in the output of the show route command. To view
why routes are hidden, issue the show route hidden extensive command.
www.juniper.net
BGP Chapter 827
IBGP Next-Hop Propagation

By default, the next-hop attribute attached to a route is unchanged as it passes through an AS.
Because routers can use the BGP routes only if they already have a route to the next hop, you must
either configure the routers to advertise external interfaces through the IGP, or configure the routers
to change the next-hop attribute attached to BGP routes using policy.
When EBGP speakers send routes to a peer, they set the next-hop attribute to the interface they
share with that peer. In this example, R1 receives a route from its EBGP peer with the next-hop
attribute set to 172.24.1.1. R1 sends this route to R2 without changing the next-hop attribute.
Therefore, to use this route, R2 either must know how to reach 172.24.1.1 through the IGP or static
routing, or R1 must send the routes with a different next hop.
You can send the appropriate external routes into the IGP, if wanted; however, using the next-hop
self action in a policy has some advantages. Using the next-hop self action in a policy causes
the router to send BGP routes to its peers using the same IP address it uses to establish that BGP
session. For the BGP session to remain established, the peer must have a route to that IP address.
Therefore, using next-hop self guarantees that a routers peers can reach the next hop of the
routes that router sends, as long as the BGP session remains established.
Chapter 828 BGP
www.juniper.net
BGP Next-Hop Solutions

Numerous ways exist to solve this BGP next-hop reachability problem, and five examples are listed
on the slide. Some of these examples do technically solve the reachability issue but are not best
practices in a networking environment.
The most commonly used (and recommended) solution is next-hop self. With this solution,
when a BGP router advertises an EBGP-learned route to an IBGP peer, it alters the BGP next-hop
attribute. The next-hop attributes IP address of the remote EBGP peer is replaced with the IP
address of the BGP router itself. Because the IBGP session was most likely established using the
peers loopback address, this new BGP next-hop value is reachable, and the advertised BGP route
can be used. We create next-hop self by using a policy to match specific routes with an action
of changing the next-hop attribute value. The Junos OS then applies this policy as an export policy to
any IBGP peers.
The next two options listed (export direct routes and IGP passive) are almost identical in their results.
The difference between the two is in the approach that each takes to provide reachability. With
export direct, the IGP operating in the AS with a routing policy advertises the address assigned to the
point-to-point link between the two EBGP peers to all IBGP peers.
www.juniper.net
BGP Chapter 829
BGP Next-Hop Solutions (contd.)

Export direct uses a Junos OS routing policy to retrieve the subnet information from the local routing
table. Within inet.0, these networks are known as protocol direct. The policy matches these
direct routes and accepts them. The Junos OS then applies this policy as an export policy to the local
IGP.
With IGP passive, the IGP is configured on the inter-AS link and advertises the interface addresses,
but forms no adjacency (it is passive). Both methods inject the interface addresses into the local
routing table for the IGP to use.
An IGP passive interface allows the local IGP to advertise the subnet on a particular interface without
forming an adjacency at the IGP level to the remote EBGP peer, which has the advantage of not using
a policy, but it requires explicit configuration for each interface and subnet address that you want to
advertise.
The last two options listed on the slide (static routes and forming an IGP adjacency relationship with
the remote EBGP router) have some severe disadvantages, but they both work.
Static routes have an inherent scalability problem. You must configure each IBGP router in the
network for a single static route for each remote EBGP peer. The more EBGP peers in the network,
the more static routes required. The more IBGP peers in the AS, the more places that additions and
changes must be made. Clearly, this option is not a real world option.
With regard to the full IGP adjacency between AS networks, although reachability information can be
provided by forming an IGP relationship with the remote EBGP peer, we do not recommend this
practice because of the very trusting nature of the IGP protocols. Once this adjacency is formed, the
protocol accepts any routing information the remote EBGP peer provides. This behavior is very
dangerous because the remote AS might inject bad information into your network. In addition, this
method potentially violates the entire idea of having autonomous (independent of the IGP) systems
in the first place.
Chapter 830 BGP
www.juniper.net
BGP Path Selection Options

www.juniper.net
BGP Chapter 831
Summary of BGP Active Route Selection

Before the router installs a BGP route, it must ensure that the BGP next-hop attribute is reachable
and that no routing loops exist. If the BGP next hop cannot be resolved or if a loop is detected, the
route is not evaluated through the BGP route selection process or installed in the route table.
Before the Junos OS installs a BGP route in the routing table, the route preference is evaluated.
Remember that the route preference can be changed through policy so the route preference can
differ for the same prefix learned through different BGP paths. If the route preference for a BGP
prefix learned through different BGP paths differs, the BGP route with the lower route preference is
selected. Note that this evaluation occurs prior to the BGP selection process outlined on the slide.
When a BGP route is installed in the routing table, it must go through a path selection process if
multiple routes exist to the same destination prefix and the route preference is the same. The BGP
path selection process proceeds in the following order:
1.
The router compares routes for the highest local preference (the only choice based on a
higher, rather than lower, value).
2.
The router evaluates the AS-path attribute next, where a shorter path is preferred. This
attribute is often a common tiebreaker for routes.
3.
The router evaluates the origin code. The lowest origin code is preferred: ( I [IGP] < E
[EGP] < ? [Incomplete]).
Chapter 832 BGP
www.juniper.net
Summary of BGP Active Route Selection (contd.)
www.juniper.net
4.
If any of the remaining routes are advertised from the same neighboring AS, the router
checks the MED attributes for the lowest value. The absence of a MED value is
interpreted as a MED of 0.
5.
If multiple routes remain, the router prefers any routes learned through an EBGP peer
over routes learned through an IBGP peer. If all remaining routes were learned through
EBGP, the router skips to Step 9.
6.
If the remaining routes were learned through IBGP, use the path with the lowest IGP
cost to the IBGP peer. For each IBGP peer, install a physical next hop based on the
following three rules:
a.
BGP examines both the inet.0 and the inet.3 routing tables for the BGP
next-hop value. The physical next hop of the instance with the lowest Junos OS
preference is used, which often means that BGP uses the inet.3 version of the
next hop, through an MPLS LSP.
b.
Should the preference values in the inet.0 and the inet.3 routing tables tie,
the physical next hop of the instance in inet.3 is used.
c.
When a preference tie exists and the instances are in the same routing table, the
number of equal-cost paths of each instance are examined. The physical next
hop of the instance with more paths is installed. This tie might occur when the
traffic-engineering bgp-igp option is used for MPLS.
7.
BGP then uses the route advertised from the peer with the lowest RID (usually the
loopback IP address). When comparing external routes from two distinct neighboring
ASs, if the routes are equal up to the RID comparison step, the currently active route is
preferred. This preference helps prevent issues with MED-related route oscillation. The
external-router-id command overrides this behavior and prefers the external
route with the lowest RID, regardless of which route is currently active.
8.
The router then examines the cluster-list attribute for the shortest length. The cluster list
is similar in function to an AS path.
9.
The router prefers routes from the router with the lowest peer IP address.
BGP Chapter 833
RID and Peer ID Ignored

When you configure multipath on a BGP router, the selection algorithm ignores both the RID and
the peer ID selection criteria. Should multiple copies of a route reach those portions of the route
selection process, BGP installs all copies into the local routing table. Each version is listed in the
table with only one of them marked as active. This active route is the version of the route that would
have been selected by the algorithm had the multipath option not been configured. However, the
next-hop values for the nonactive routes are also listed as valid next hops for the active route. This
listing allows the Junos OS default load-balancing options to be used.
The Junos OS also utilizes the link bandwidth extended community to unequally load-balance traffic
in conjunction with the multipath command. If used, data packet forwarding is performed in a
proportional manner to the bandwidth advertised in the extended community.
The multipath command allows multiple copies of a route from the same remote router. It also
allows multiple copies of a route from two different routers in the same AS (either a local or remote
AS). The entire concept centers around resiliency and redundancy.
Chapter 834 BGP
www.juniper.net
Router ID and Peer ID Ignored (contd.)

The slide shows the R1 router peering with two routers in AS 2R2 and R3. Both of the AS 2 routers
are advertising the same four routes. Currently, the versions of the routes from R2 (10.222.28.2) are
selected and placed into the routing table. We have some clues into this behavior by examining the
output of the show bgp summary command. The route information from R2 shows 4/4/0, which
means that the four received routes are active in the local routing table. R3, on the other hand, has
route information of 0/4/0. Its four advertised routes are not active in the routing table.
www.juniper.net
BGP Chapter 835
Single Next Hop for All Routes

The local routing table of the R1 router is shown on the slide. We see the four routes advertised from
AS 2: 172.16.20.4/30, 172.16.20.8/30, 172.16.20.12/30, and 172.16.20.16/30. Each listing of
the prefix contains two versions of the route. One route is from the R2 router (10.222.28.2), and this
route is marked active. The other version of the route is from the R3 router (10.222.29.2), and it is
marked inactive.
Chapter 836 BGP
www.juniper.net
Configure multipath on R1
The configuration of the R1 router now contains the multipath command within the peer group for
AS 2. After committing the configuration, we examine the contents of the local routing table. We still
see the four routes advertised from AS 2, and each listing of the prefix still contains two versions of
the route. As before, the routes from the R2 router are marked active while the routes from the R3
router are marked inactive.
The effect of the multipath command on the routes from AS 2 is that the next hop for the routes
from R3 (10.222.29.2) are now added to the version of the route from R2. The next-hop information
for the inactive route version does not change in this environment.
Because each active route now has two next hops in the routing table, the default Junos OS
load-balancing process can be used. Each route has a single next hop selected, and this single next
hop is placed into the forwarding table. All traffic for each route uses just that single next hop. The
overall benefit of this system is the total amount of traffic sent from AS 1 to AS 2 can now be
load-balanced over the two inter-AS links. In our small example, just the 172.16.20.16/30 route is
using the 10.222.29.2 next hop, while the other three routes maintained the 10.222.28.2 next hop.
As more routes are announced between the AS networks, the selection of the next hops becomes
more evenly distributed.
Although not shown on the slide, you can also see the effects of using multipath in the output of the
show bgp summary command. The route information from both R2 and R3 now appears as
4/4/0. The routes from R2 are active, while the next-hop values from R3 are also used to forward
user traffic.
www.juniper.net
BGP Chapter 837
BGP Multihop Peering

The default for an EBGP connection is to peer over a single physical hop using the physical interface
address of the peer. In some cases, altering this default, one-hop, physical peering EBGP behavior is
advantageous. One such case is when multiple physical links connect two routers that are to be
EBGP peers. In this case, if one of the point-to-point links fails, reachability on the alternate link still
exists. You must take three extra configuration steps to accomplish a single BGP peering session
across these multiple physical links.
First, each router must establish the peering session with the loopback address of the remote router.
You can configure this session using the local-address command, which alters the peer address
header information in the BGP packets. Second, use the multihop command to alter the default
use of the neighbors physical interface address. In addition, you can also specify a time-to-live (TTL)
value in the BGP packets to control how far they propagate. On the slide, we use a TTL value of 1 to
ensure that the session cannot be established across any other backdoor links in the network. Third,
each router must have IP routing capability to the remote routers loopback address. As the slide
shows, we often accomplish this capability by using a static route to map the loopback address to
the interface physical addresses.
Note that when multihop is configured, the Junos OS sets the TTL value to 64, by default. You can
specify a TTL value explicitly to limit the scope of the EBGP session. Note that a TTL value of 1 is
sufficient to enable an EBGP session to the loopback address of a directly connected neighbor
because the IP TTL is decremented for egress traffic only, and this traffic will be considered destined
for the local Routing Engine.
Chapter 838 BGP
www.juniper.net
Routes with Multiple Next Hops

Within the context of a BGP network, both the multihop and multipath tools can result in a route
being installed in the local routing table with multiple next hops. As we previously discussed, this
route allows the Junos OS to perform per-prefix load balancing as the total amount of traffic sent
towards the destinations is spread across the multiple next hops. However, each route selects a
single next hop for forwarding traffic, which is installed into the forwarding table on the Packet
Forwarding Engine (PFE).
The slide shows the BGP route of 172.16.20.4/30, which is active in the routing table. This route has
two possible next hops it can use to forward traffic10.10.1.1 and 10.10.2.1. It has currently
selected the 10.10.1.1 next hop, which we verify in the forwarding table with the show route
forwarding-table command. The router output shows this single next hop in the table with a
type set to ucst, for unicast transmission.
www.juniper.net
BGP Chapter 839
Load Balancing
You can alter the default behavior of the Junos OS to install a single next hop per route in the
forwarding table with a routing policy. The policy should contain the action of then
load-balance per-packet and be applied as an export policy to the forwarding table within
the [edit routing-options] configuration hierarchy.
After committing the configuration, we see the same 172.16.20.4/30 route in the routing table of
the local router. The same protocol information is displayed and again, a single next hop has been
selected. This selection mechanism is not affected by our load-balancing policy, so we cannot verify
whether it is working by examining the routing table. Instead, a look at the forwarding table shows
the outcome of our policy. Both the 10.10.1.1 and the 10.10.2.1 next hops are listed as valid
outbound interfaces for the 172.16.20.4/30 route. Traffic destined for this route is now forwarded
across both available next hops using a microflow hashing algorithm. The default inputs to the
microflow hash are the incoming router interface, the source IP address, and the destination IP
address. You can modify the inputs to the hashing algorithm at the [edit
forwarding-options hash-key family inet] configuration hierarchy. Specifying the
layer-4 command at this configuration hierarchy incorporates Layer 4 source and destination port
information into the hash key.
Chapter 840 BGP
www.juniper.net
Configuration Options
www.juniper.net
BGP Chapter 841
passive Option
By default, a local router initiates a BGP open message to the remote router to establish the session.
The passive command stops this default action, and no open message is sent. The IP address and
AS of the remote peer are still configured, but the remote router must initiate the BGP session.
allow Option
The related option of allow also stops the sending of a BGP open message to the remote router. In
addition, the allow command also relaxes the requirement of explicitly configuring the remote
routers IP address by allowing you to define a subnet range for connections. BGP processes any
open message received from an IP address within the configured range and initiates a session with
that remote router.
Chapter 842 BGP
www.juniper.net
Limiting the Number of Prefixes Accepted

By default, each BGP router accepts any number of routes sent from each of its peers. You might
want to alter this default setting for either security or memory reasons. You can use the
prefix-limit command to set a limit on the maximum number of routes received from any
individual peer. Use the maximum option to set the total amount of routes able to be received. When
a BGP peer sends more routes than allowed, the peering session is terminated and restarted
immediately with the teardown option. The value that immediately follows the teardown option is
a percentage of routes upon which the router starts to generate system log messages. You can halt
the BGP peering session between the two routers for up to 40 hours by specifying a value (in
minutes) with the idle-timeout option. In addition, you can specify a value of forever. This
value requires you to intervene manually to restart the peering session.
Altering the Session Hold Time

When two BGP peers establish their peering session, they negotiate the hold time for that
relationship. By default, the Junos OS uses a value of 90 seconds to negotiate for the hold time of
the session. The hold-time command allows you to alter this value from as short as 20 seconds to
as long as 65,535 seconds (18 hours, 12 minutes, and 15 seconds).
www.juniper.net
BGP Chapter 843
Disabling Suppression of Route Advertisements

By default, the Junos OS does not advertise the routes learned from an EBGP peer back to the same
EBGP peer. In addition, the software does not advertise those routes back to any EBGP peer that is in
the same AS as the originating peer. You can modify the default behavior with the
advertise-peer-as command. Before Junos OS release 7.0, advertise-peer-as was the
Junos OS default behavior.
Chapter 844 BGP
www.juniper.net
Graceful Restart
Graceful restart (GR) addresses the situation described on the previous slide. GR allows a router
undergoing a restart event, including a restart of the routing protocol daemon (rpd), to inform its
adjacent neighbors and peers of its condition. The restarting router requests a grace period from the
neighbor or peer, which can then cooperate with the restarting router. When a restart event occurs
and GR is enabled, the restarting router can still forward traffic during the restart period, and
convergence in the network is not disrupted. The neighbors or peers of the restarting router, also
known as helper routers, hide the restart event from other devices not directly connected to the
restarting router. In other words, the restart is not visible to the rest of the network, and the
restarting router is not removed from the network topology.
The GR request occurs only if the following conditions are met:
www.juniper.net
The network topology is stable;
The neighbor or peer cooperates;
The restarting router is not already cooperating with another restart already in progress;
and
The grace period does not expire.
BGP Chapter 845
GR Support
As shown on the slide, GR is supported by several standards-based protocols. A number of RFCs and
drafts exist that document the operational details for GR and each of the protocols for which GR is
supported. While these different protocols implement GR slightly differently, the basic concepts and
operations are the same from a high availability point of view.
GR Requirements
Routers must have GR enabled to support both GR router modesthe restarting router mode and
helper router mode. By default, Junos devices can operate as helper routers but not as restarting
routers; restarting router mode functionality must be enabled through configuration. We cover GR
configuration on subsequent slides.
In addition to having the GR functionality enabled, the router must support nonstop forwarding
operations, which simply means the router must be able to continue forwarding traffic during times
of control plane instability. Nonstop forwarding is an inherent attribute of Junos devices because of
the architectural design, which cleanly separates the control and forwarding planes.
Chapter 846 BGP
www.juniper.net
Configuring GR: Part 1

GR helper mode is enabled by default on all Junos devices. You can disable GR helper mode globally
for all supported protocols at the [edit routing-options] hierarchy or on a per-protocol,
per-group, or per-neighbor basis, depending on the specific protocol. The slide illustrates the syntax
required to disable GR helper mode globally, enable GR helper mode for the BGP protocol, and
disable GR for a BGP peer. As with many similar configuration scenarios, the most specific definition
is used.
www.juniper.net
BGP Chapter 847
Configuring GR: Part 2

GRs restarting router mode is not enabled by default. You can enable GR restarting router mode
through configuration at the [edit routing-options] hierarchy. The slide provides a sample
configuration used to enable GRs restarting router mode globally and for all protocols along with a
sample configuration that disables GR for a specific BGP peer.
The following are the available GR configuration options for BGP:
[edit protocols]
user@R1# set bgp graceful-restart ?
Possible completions:
<[Enter]>
Execute this command
+ apply-groups
Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
disable
Disable graceful restart
restart-time
Restart time used when negotiating with a peer (1..600)
stale-routes-time
Maximum time for which stale routes are kept (1..600)
|
Pipe through a command
Chapter 848 BGP
www.juniper.net
Modifying the Local Preference

The Junos OS provides a configuration option within BGP that alters the local preference attribute
value for all advertised routes. You can use the local-preference command at the global,
group, or peer level in the BGP configuration. All advertised routes will inherit this value for the local
preference attribute.
The exception to this rule are any routes whose attributes are modified by an applied routing policy.
These routes abide by the action defined in the policy and take precedence over the configured
value. In other words, the configuration option is applied before the routing policy is applied for all
outbound BGP routes.
www.juniper.net
BGP Chapter 849
Eliminating Private AS Numbers

In spite of the wording in the BGP RFC, many vendors include configuration options in their BGP
implementations that remove information from the AS path, which is technically not allowed. This
removal, however, only operates on specific information in the AS path attribute, and it does not
apply to making arbitrary changes to the actual AS path. Typically, the information removed was
placed there by the AS itself or by other routers within the administrative control of the AS. Thus, one
AS is not trampling on the path information another AS has put into the AS path attribute.
One example of this type of configuration option is the remove-private configuration statement.
This keyword allows an ISP to remove private AS numbers from paths received from BGP customers
when those customers are using private AS numbers. Because the customers are effectively within
the administrative scope of the ISP, the provider is allowed to remove the private AS numbers from
the path.
On the slide, AS 1000 has three different customers connected using BGP. The customers are using
AS 65001, AS 65002, and AS 65003 for the BGP peer communications. Within AS 1000, each of the
BGP routers sees the private AS numbers within the path.
Chapter 850 BGP
www.juniper.net
Eliminating Private AS Numbers (contd.)

The remove-private option is enabled on the R1 router in AS 1000. As BGP advertises the
customer routes out of AS 1000, the private AS numbers are removed from the AS path attribute. In
this case, BGP views all customer networks as having originated within AS 1000.
You should not use this option in a BGP confederation network. We describe why the remove private
option should not be used with BGP confederation in a subsequent chapter.
www.juniper.net
BGP Chapter 851
Modifying the AS Path Attribute: Part 1

Another option for removing AS path attribute information is the local-as configuration statement.
The purpose of the local-as keyword is to aid an ISP in migrating BGP customers to a new AS
number. The following slides display an example of how you can use the local-as option.
Consider the normal BGP AS path operation first. AS 1 has two customers for which it provides
service: AS 222 and AS 333. As AS 1 announces these routes from AS 222 and AS 333 on to the
Internet, AS 1 injects its own AS number (1) into the AS path attribute, as the BGP RFC expects.
So far, nothing is unusual about the AS path operation.
Chapter 852 BGP
www.juniper.net

Next, consider what happens if AS 1 merges with AS 777. This situation is shown on the slide.
Suppose the resulting merged organization decides to use AS 777 as the official AS to represent
both networks on the Internet. To ease in the migration of the customer BGP configurations from
AS 1 to AS 777, the edge routers can use the local-as 1 configuration option.
The effect of this option is that the customer routes within AS 777 see both AS 1 and the customer
AS numbers (AS 222 and AS 333). As AS 777 advertises those routes to the Internet, it prepends its
own value of AS 777 onto each of the routes.
Therefore, even though AS 1 has been merged into AS 777, AS 1 still shows up on the paths sent to
the Internet.
www.juniper.net
BGP Chapter 853

You can use an optional parameter with the local-as configuration statement that actually does
remove AS path information from the BGP AS path attribute. This optional parameter restricts
knowledge of AS 1 to the edge router connected to the customer (AS 222 and AS 333) only. This
situation is shown on the slide.
On the slide, the edge router in the formerly intact AS 1 is configured with the option of local-as
1 private. As the edge router advertises the customer routes into AS 777, AS 1 information is
removed from the AS path attribute, as shown on the slide. At this point, the AS 777 routers, as well
as the Internet, have no knowledge of AS 1.
The local-as 1 private statement now has indeed removed AS path information. Again, this
example applies to a type of special case and should not be used arbitrarily to attempt to change AS
path information received from another AS.
Other options are the following:
Chapter 854 BGP
local-as autonomous-system alias: A BGP peer considers any local AS to

which it is assigned as equivalent to the primary AS number configured for the routing
device. When you use the alias option, only the AS (global or local) used to establish
the BGP session is prepended in the AS path sent to the BGP neighbor.
local-as loops number: Specify the maximum number of times that the local AS
number can appear in an AS path received from a BGP peer. For number, include a
value from 1 through 10.
www.juniper.net
Overriding the Default Prepend Action

In certain situations, the default mechanics of the AS path prepend mechanism might cause routes
to not be received by a peer. One such situation is displayed on the slide.
AS 65432 is providing transit service to AS65022, which peers at two different locations. For
reasons that we do not discuss in this chapter, the two portions of AS 65022 do not have any other
peering links between them. In fact, these two sections of the network rely on AS 65432 for
reachability information to the other half of the AS.
By default, the router on the right side of AS 65432 only prepends its own AS a single time before
advertising the 172.16.10.0/24 route to AS 65022. Unfortunately, this route is never received by the
peering router because of an AS path loop. After all, AS 65022 is already in the AS path. The EBGP
peer in AS 65432 alters its configuration with its peer in AS 65002 to include the as-override
command. This command allows the router in AS 65432 to examine the AS path before advertising
the route and look for any instances of AS 65022 already in the path. Should it find any, they are
replaced with the peers own AS, 65432 in this case. The EBGP peer then performs the default
prepend action before advertising the route. The router in AS 65022 now receives the route without
an AS path loop and installs it in its local routing table.
www.juniper.net
BGP Chapter 855
Allowing AS Paths Loops

The Junos OS allows you to configure your router to accept an AS path loop in certain situations. The
slide once again shows AS 65432 providing transit service to AS65022. As before, the
172.16.10.0/24 route is not accepted by the router in AS 65022 because of an AS path loop.
The configuration option used in this example is performed on the router in AS 65022 itself. The
optional keyword loops is appended to the autonomous-system command within the [edit
routing-options] configuration hierarchy. This keyword allows the local AS number to appear
multiple times in the path. The route can then be received by the router in AS 65022.
This scenario also requires the EBGP peer in AS65432 to be configured with the
advertise-peer-as command. Otherwise, routes learned from one instance of AS 65022 will
not be advertised to the second instance of AS 65022.
Chapter 856 BGP
www.juniper.net
www.juniper.net
Basic BGP operation;
Common BGP attributes;
The route selection process for BGP;
The alteration of the route selection process; and
The configuration of some advanced options for BGP peers.
BGP Chapter 857
Review Questions
1.
2.
3.
4.
5.
Chapter 858 BGP
www.juniper.net
Lab 7: BGP
www.juniper.net
BGP Chapter 859
Chapter 860 BGP
www.juniper.net

Routing
Various BGP attributes in detail and explains the operation of those attributes; and
The manipulation of BGP attributes using routing policy.
Chapter 92 BGP Attributes and PolicyPart 1
www.juniper.net
BGP Policy
www.juniper.net
BGP Attributes and PolicyPart 1 Chapter 93
BGP and Policy Dependency

BGP is a very policy-oriented protocol, in the sense that import and export policies largely determine
BGP behavior. The router can use all the BGP attributes. You can adjust these attributes to influence
the behavior of the local router as well as other routers receiving the route.
You can use each of the BGP attributes as a match criterion for a policy, and you can modify each
attribute using a policy action. You can further decide to act on a BGP attribute based on whether it
is an EBGP or IBGP route. To understand better where BGP import and export policies are applied to
BGP routes, we detail the process of how a router uses BGP routes.
BGP RIB Tables

BGP uses three different storage tables, known as routing information bases (RIBs), as databases to
maintain routing knowledge. A separate RIB-IN exists for each established BGP peer to store all
routes received from that peer. A RIB-LOCAL is where BGP stores routes used for traffic forwarding. A
separate RIB-OUT exists for each established BGP peer to store routes to be advertised to that peer.
www.juniper.net
BGP and Active Routes

Only active BGP routes in the routing table can be moved into the RIB-OUT tables and are advertised
to BGP peers. In addition, only the single best BGP path to each separate IP route destination is
placed in the RIB-LOCAL and RIB-OUT tables.
At times, it is possible that the best BGP path is not advertised to a peer because of the local routers
routing table rules. For example, if the router knows about a particular route through both IS-IS and
BGP, the IS-IS route will be active in the local routing table because of the default Junos OS route
preference values. Therefore, the BGP version of that route will not be sent to any peers because
BGP advertises only active routes (routes used by BGP). To override this default action, you can use
the advertise-inactive command. This command always forces the advertisement of the
single best BGP path to any destination, regardless of whether the route is currently active in the
local routing table.
www.juniper.net
Import Policies and BGP

BGP stores the information about routes received from BGP peers in the RIB-IN table. No policies are
applied yet; all BGP routing information that is received is stored in this table except routes that fail
AS path or cluster-ID sanity checks, as well as VPN routes that do not have a matching target
community.
As BGP moves the routes that it received from peers to the RIB-LOCAL table, the Junos routing policy
framework can apply import policies. These policies can reject (filter) routes or can change attributes
and affect what the BGP route selection process uses to pick the best route.
After the BGP import policy or policies (if any are configured and applied) has filtered and
manipulated the BGP attributes, the BGP decision process chooses the best route to use and installs
that route into the IP routing table. Note that even if no routing policies are configured, the default
(and unseen) BGP import policy is always applied.
www.juniper.net
Sample BGP Import Policy

The slide shows an example of some BGP import policies in action.
Some policies are configured that reject the default route (0/0) if received from AS 1, prefer the AS 1
version of 192.168.14.0/24, and accept all other routes from AS 3. These three policies, which
might be three separate policies or a single policy with three terms, are configured as import policies
for BGP.
Import policy is evaluated as the BGP process attempts to move routes from the RIB-IN table to the
BGP decision process, where the active route is selected.
The result of this policy example is that the forwarding table correctly reflects the users desire to
forward through AS 1 for traffic matching the 192.168.14.0/24 prefix and AS 3 for traffic matching
the 0/0 default route. Note that the routing table (not shown) will contain two entries for the
192.168.14.0/24 prefix, because the 192.168.14.0/24 prefix coming from AS 3 is not filtered in this
example. The AS 1 version of this prefix is preferred and is installed in the forwarding table as a
result. The following list summarizes the overall effects of this policy example:
www.juniper.net
The 0.0.0.0/0:AS1 route is rejected.
The 192.168.14.0/24 route from AS3 is accepted but not preferred.
The 192.168.14.0/24 route from AS1 is accepted and preferred.
All other AS3 routes are accepted.
Export Policies and BGP

BGP stores the information about routes to be advertised to BGP peers in the RIB-OUT table.
As BGP moves the routes from the RIB-LOCAL table to the RIB-OUT table, the Junos routing policy
framework can apply export policies. These policies can reject (filter) routes and affect which BGP
routes are advertised to BGP peers or can change the BGP attributes of advertised routes.
In addition, the Junos OS can inject new routing information into the BGP routing process at this
point.
www.juniper.net
Sample BGP Export Policy

The slide shows an example of some BGP export policies in action.
Some policies are configured that reject the default (0/0) route, do not send some routes to AS 4,
alter a BGP attribute on routes sent to AS 2, and inject new route information into the BGP process.
These four policies, which might be four separate policies or one policy with four terms, are then
configured as export policies within BGP.
As the BGP routing process attempts to move those routes from the RIB-LOCAL table to the RIB-OUT
tables, the Junos OS applies the export policies. The net result of this policy application is shown on
the slide and summarized as follows:
www.juniper.net
The 0.0.0.0/0:AS3 route is rejected and is not advertised.
The 192.168.27.0/24:AS3 route is only sent to AS 2.
The 192.168.14.0/24 route is sent to both AS 2 (with a metric of 10) and AS 4.
The 172.31.10.0/20 aggregate is sent to both AS 2 and AS 4.
Next Hop
www.juniper.net
The Next-Hop BGP Attribute

The next-hop concept in IGPs, such as IS-IS and OSPF, is relatively straightforward. IGPs basically
exist to give adjacent routers next-hop reachability information, which is then flooded (in one form or
another) throughout the AS. However, BGP does not flood BGP peers. And BGP cannot peer unless
an underlying IGP route to the peer exists because BGP requires a TCP session for routes to be
exchanged. Thus, BGP cannot bootstrap its own next hops as an IGP does.
Therefore, a next hop in BGP is more elaborate than in any IGP. The concept of the BGP next-hop
attribute is important. Without reachability to the IP address listed in this BGP attribute, a BGP router
cannot use the advertised route. This situation is a very common problem to be solved in any ISP
network.
www.juniper.net
How BGP Gets Its Next-Hop Information

The default actions for changing the next-hop attribute are detailed below. Subsequent slides
discuss various ways to provide the required reachability.
The BGP next-hop attribute value is only changed when a route is advertised across an EBGP link. In
this situation, the IP address of the advertising router is placed into the attribute. Should the
receiving router choose to advertise this EBGP-learned route to any IBGP peers, it does so without
modifying that IP address value. Thus, the EBGP next hop advertised into a local AS is an address
from the remote AS. How is the local IGP supposed to know how to reach this external address?
When new routing information is injected (or redistributed) into the BGP process, the coding of the
next-hop attribute depends on the specifics of the route being injected. When a redistributed route is
associated with a forwarding next hop, the BGP next-hop attribute is coded with that forwarding next
hop. This behavior accommodates optimal forwarding because it allows a BGP speaker to forward
directly to the source of a particular route, even though that source might not speak BGP. This
behavior is known as a third-party next hop. When a redistributed route is not associated with a
forwarding next hop, such as in the case of a locally defined static route with a reject next hop, the
next-hop attribute is set to the local routers peer ID. For IBGP sessions, the peer ID is typically the
local routers loopback address. For EBGP sessions, the peer ID is usually a peering address
associated with a physical link.
www.juniper.net
Next-Hop BGP Example: Part 1

The next few slides graphically show the default BGP behavior with respect to the next-hop attribute.
The slide shows the physical interface addresses along with the loopback addresses of each router.
The slide shows the details for the R3 router. The R3 router has an EBGP session with the R4 router
using 10.10.1.2.
The output of the show bgp summary command is listed on the slide. The R3 router is receiving
one route from R4 (peer 10.10.1.2) and actively uses that route (last column is 1/1/0).
You can verify this activity with the show route terse output, where 172.19.20.0/24 is listed as
an active route from protocol BGP and a next hop of 10.10.1.2.
www.juniper.net

The slide shows the output from the R1 router. The R1 router has an IBGP session with the R3 router
using R3s loopback address of 192.168.10.1.
The output of the show bgp summary command shows that the R1 router is receiving one route
from the R3 router (peer 192.168.10.1), but it is not used to forward traffic (last column is 0/1/0).
In fact, a look at the show route output does not show 172.19.20.0/24 (the active BGP route on
the R3 router) listed at all. If the 172.19.20.0/24 route is received by the R1 router from the R3
router, then the route should appear as the active route (there is no chance of an AS 1 IGP also
supplying this AS 2 route). What is the problem?
www.juniper.net

You can see the problem with the absent route to 172.19.20.0/24 on the R1 router with the help of
the show route hidden extensive command run on the R1 router.
The output from this command shows the 172.19.20.0/24 route, but the route is hidden. By
examining the output a little more closely, you can determine that the next hop is unusable (Next
hop type: Unusable).
Why is this route unusable? Obviously, connectivity exists from R1 to R3. Notice, however, that the
current BGP next-hop attribute for the 172.19.20.0/24 route is set to 10.10.1.2 (the physical
interface IP address of the R4 router). The R3 router does not change the BGP next-hop attribute
before the route is advertised to the R1 router, which is the default EBGP-to-IBGP behaviornot to
change the advertised next-hop attribute value.
The show route terse output on the previous slide did not show a route to 10.10.1.2. Because
the R1 router does not have reachability to the IP address listed as the BGP next-hop attribute, it
cannot use the received BGP route. On a Juniper Networks router, this type of unusable route is
marked as a hidden route.
www.juniper.net
BGP Next-Hop Solutions

Numerous approaches exist to solve this BGP next-hop reachability problem, and five examples are
listed on the slide. Some of these examples are not best practices in a networking environment but
technically solve the reachability issue. Some are in the category of you can use a hammer to swat a
fly on a window, but you might want to use something else.
Perhaps the most commonly used (and recommended) solution is next-hop self. With this solution,
when a BGP router advertises an EBGP-learned route to an IBGP peer, it alters the BGP next-hop
attribute. The next-hop attributes IP address of the remote EBGP peer is replaced with the IP
address of the BGP router itself. Because the IBGP session was most likely established using the
peers loopback address, this new BGP next-hop value is reachable, and the advertised BGP route
can be used. You create next-hop self by using a policy to match specific routes with an action of
changing the next-hop attribute value. The Junos OS then applies this policy as an export policy to
any IBGP peers.
The next two options listed (export direct routes and IGP passive) are almost identical in their results.
The difference between the two is in the approach that each takes to provide reachability. With
export direct, the IGP operating in the AS with a routing policy advertises the address assigned to the
point-to-point link between the two EBGP peers to all IBGP peers.
www.juniper.net
BGP Next-Hop Solutions (contd.)

Export direct uses a Junos OS routing policy to retrieve the subnet information from the local routing
table. Within inet.0, these networks are known as protocol direct. The policy matches these
direct routes and accepts them. The Junos OS then applies this policy as an export policy to the local
IGP.
With IGP passive, the IGP is configured on the inter-AS link and advertises the interface addresses,
but forms no adjacency (it is passive). Both methods inject the interface addresses into the local
routing table for the IGP to use.
An IGP passive interface allows the local IGP to advertise the subnet on a particular interface without
forming an adjacency at the IGP level to the remote EBGP peer. This option has the advantage of not
using a policy, but it requires explicit configuration for each interface and subnet address that you
want to advertise.
The last two options listed on the slide (static routes and forming an IGP adjacency relationship with
the remote EBGP router) have some severe disadvantages, but they both work.
Static routes have an inherent scalability problem. You must configure each IBGP router in the
network for a single static route for each remote EBGP peer. The more EBGP peers in the network,
the more static routes required. The more IBGP peers in the AS, the more places that additions and
changes must be made. Clearly, this is not a real world option.
With regard to the full IGP adjacency between AS networks, although reachability information can be
provided by forming an IGP relationship with the remote EBGP peer, we do not recommend this
practice because of the very trusting nature of the IGP protocols. Once this adjacency is formed, the
protocol accepts any routing information told to it by the remote EBGP peer. This behavior is very
dangerous because the remote AS might inject bad information into your network. In addition, this
method potentially violates the entire idea of having autonomous (independent of the IGP) systems
in the first place.
www.juniper.net
Example Using Next-Hop Self: Part 1

The next few slides show how the use of next-hop-self in a routing policy provides reachability
for IBGP peers.
The slide details the situation on the R3 router. The R3 router has an EBGP connection to the R4
router using 10.10.1.2 and two IBGP connections to the R2 router and to the R1 router.
The R3 router is now configured with the next-hop-self policy shown on the slide as the output
of the show policy-options configuration command. The policy matches all routes (no from)
and replaces the BGP next-hop attribute (because only BGP has a next-hop attribute) with the value
self (a keyword for the local routers physical interface address on which the route is advertised).
This next-hop-self policy is applied as an export policy to the BGP group int, which includes
the R1 router.
www.juniper.net

This slide shifts the focus of attention to the R1 router.
The output of the show bgp summary command now shows that the R1 router is receiving one
route from the R3 router (192.168.10.1) and that this route is actively used to forward traffic (last
column is 1/1/0).
A look at the show route terse output now shows the 172.19.20.0/24 listed as a BGP route
with a next hop of 10.40.4.1. This next-hop address is the self next-hop address advertised for the
route to the R1 router by the R3 router because the route was advertised on the 10.40.4.1 interface.
www.juniper.net

How do you know that the BGP next-hop attribute was really changed with the policy? To verify that
the policy on the R3 router has indeed changed the BGP next-hop attribute, you can look at the
output of the show route extensive command on the R1 router.
The output lists the BGP next hop for the 172.19.20.0/24 prefix (which is in AS 2) as 192.168.10.1,
the loopback address of the R3 router. Because the R1 router has IGP reachability to the R3 router,
the R1 router also has reachability to the BGP next-hop value and can use the BGP route.
www.juniper.net
Next-Hop Equals Peer Address

The default action of the BGP protocol is for an EBGP-speaking peer to modify the next-hop attribute
prior to advertising a route to peers. The address of the EBGP peering session is the address used
for the next hop.
EBGP Peer Can Alter Attribute

An EGBP peer can alter this default action through the use of a policy or a BGP configuration
statement. The advertised address could be an additional EBGP router on a broadcast network. The
address could be an IBGP router in the sending autonomous system (AS). Problems could arise in
this situation because the advertised next hop might not be reachable by the local router. This
situation would result in the routes being hidden and unusable.
Policy Used to Change Incoming Next Hop

The local router can use an import policy to alter the next-hop attribute to be the address of the
EBGP peer. This address can guarantee that the local router has connectivity to that next hop.
Hence, the advertised routes are usable and active in the inet.0 routing table.
www.juniper.net
Example Using Next-Hop Peer Address: Part 1

The next few slides show how the use of next-hop peer-address in a routing policy corrects
the advertisement of improper addresses.
The slide details the situation on the R1 router. The R1 router has a multihop EBGP connection to the
R2 router using 172.16.20.1.
The R2 router advertises routes to the R1 router with a BGP next hop of 172.16.30.1. Because the
R1 router does not currently have IP reachability to the advertised next-hop address, the received
routes are unusable. The routes then appear as hidden routes within the inet.0 routing table.
www.juniper.net

The slide shows the policy next-hop-to-peer-address on the R1 router. The policy is applied
as an import policy within the peer group for the R2 router.
www.juniper.net

After the configuration on the previous slide is committed, the received routes from the R2 router are
then usable.
On the slide, note that the current Protocol Nexthop is listed as 172.16.20.1, which is the
peering address of the R2 router. This address is then recursively associated with 10.10.1.2, which is
the physical next hop used to reach the R2 routers loopback address.
www.juniper.net
Origin and MED

www.juniper.net
Set by Router Originating the Information

The first router to inject the route into BGP attaches the origin attribute to a prefix (that is, a route).
Other routers can change this value, of course, as the route makes its way through an AS and on to
other ASs.
How Believable Is This Information?

The intent of the origin code is to provide a measure of believability as to the origin of a particular
route. In other words, the intent is to provide a kind of where did you get this from? clue for other
routers seeing the route.
Well-Known Mandatory BGP Attribute

The origin code is a well-known, mandatory BGP attribute (the Type Code is 1), meaning that each
route associated with BGP must have an origin code assigned to it.
www.juniper.net
Internal, External, or Unknown

The values available for the origin attribute are internal, external, and incomplete. The internal (I)
origin is a tag designated for all routes learned through a traditional IGP, such as OSPF, IS-IS, or RIP.
These types of routes were typically seen as best sources of information because of their stability at
the time BGP was created. The external (E) origin is a tag designated for routes learned through the
original Exterior Gateway Protocol (EGP). This protocol was the precursor to BGP but was not as
robust, and it was generally less reliable than the IGP routes. The last origin code of incomplete (?) is
a tag designated for all routes that did not fall into either the internal or external categories.
Internal Better than External Better than Unknown

Each of the origin tags is assigned a value for use in transmitting the attribute to other BGP
speakers. The values are 0 for internal origin (I), 1 for external origin (E), and 2 for unknown
(incomplete) origin (?). A lower value is better, so routes learned from an IGP are preferred over
routes learned from an EGP. EGP routes are better than incomplete routes.
The Junos OS Default Is InternalIGP

Because all routing information eligible to be injected into BGP on a Juniper Networks router resides
in inet.0, the Junos OS sees all possible routes as internal routes. These internal routes all receive a
BGP origin code of internal when placed into BGP.
www.juniper.net
How Origin Is Used

The slide shows the default BGP behavior within the Junos OS with regard to the origin code.
Within the AS shown, the static routes of 10.0.0.0/8, 172.16.0.0/16, and 192.168.27.0/24 exist. An
export policy placed these routes into BGP. A direct route of 192.168.14.0/24 exists that was
exported into BGP. The route to 172.31.0.0/24 was learned from another AS altogether, and this
route contains an origin attribute coded to 2, which indicates an unknown origin. Finally, an
IGP-learned route of 10.20.0.0/16 exists in the network. The router does not know whether this
route is an OSPF route or an IS-IS route, but the route had the appropriate export policy and,
therefore, was placed into BGP.
To the Juniper Networks router, it does not matter that these routes are advertised to another AS
through EBGP; the BGP origin code is not altered as the routes are advertised to an EBGP peer. On
the basis of the origin attribute alone, the 172.31.0/24 prefix appears less attractive to the remote
AS.
www.juniper.net
Example of Origin Attribute Use: Part 1

In the collection of AS networks on the slide, for all routes originated by AS 1, the BGP origin code is
at its default setting of internal. These routes are sent to each of the AS networks on the slide.
How will AS 40 send traffic to AS 1? Through AS 30, or AS 20, or AS 10? Assume that the
local-preference BGP attribute is the default, and that the AS-path BGP attribute accurately reflects
the actual path for the route.
Routers in AS 40 see the AS 1 routes advertised from both AS 20 and AS 10. Because the
local-preference values and AS-path lengths are the same for both sets of routes, the origin code is
examined.
For both sets of routes, the origin code is the same as well. Some other method must be used to
determine which path the AS 40 routers use. Although that determination is outside the scope of this
slide, the important point here is that AS 1 has no way to control how the AS 40 routers reach the
AS 1 networks, based on the default value of the origin code alone.
Other AS Networks
Note that routers in AS 30 use AS 20 to reach the networks in AS 1, because of a shorter AS-path
length through AS 20. Also, routers in AS 20 use AS 2 to reach the networks in AS 1, because of a
shorter AS-path length. Finally, routers in AS 10 use AS 3 to reach the networks in AS 1, because of a
shorter AS-path length. Why should AS 40 be the only AS confused about the best way to reach AS 1?
www.juniper.net
Example of Origin Attribute Use Part 2

On the previous slide, only AS 40 had multiple path options after examining the AS-path length,
because both AS 10 and AS 20 are the same distance away from AS 1. At this point, the value of any
other tiebreakers that AS 40 might use to pick one of those two paths through AS 10 or AS 20 is
unknown to AS 1.
However, perhaps AS 1 now decides that traffic sent to it from AS 40 should use AS 10 rather than
AS 20 (for reasons of economics, politics, or something else). By using a routing policy, AS 1 alters
the BGP origin code to incomplete (?) on all routes advertised to AS 2. Consider the effect of this
policy on AS 40.
Routers in AS 40 still see the AS 1 routes advertised from both AS 20 and AS 10. Because the
local-preference and AS-path lengths are the same for both sets of routes, the origin code is
examined. The routes received by AS 40 from AS 10 have an origin of internal (0) while the routes
received from AS 20 have an origin code of incomplete (2). Internal is better (lower) than incomplete,
so the routes from AS 10 are used to reach the networks in AS 1. By altering the origin code, AS 1
can now influence the routing decisions in AS 40.
www.juniper.net
Other AS Networks
Note that, because of shorter AS-path length, the following occur:
Routers in AS 30 still use AS 20 to reach the networks in AS 1.
Notice also that all the other AS networks on the slide (besides AS 40) still use the AS-path length for
route selection. The origin code is truly only effective when the AS-path lengths are equal.
www.juniper.net
Modifying Origin with a Policy

The slide shows an example of a BGP export policy that changes the origin code. This example finds
all BGP routes and changes the origin code from internal (0) to incomplete (2).
The match criteria for the policy are all active BGP routes that currently have an origin code of
internal. The action for the policy is to change the origin code to incomplete. Once applied as a BGP
export policy and committed, this policy starts altering the origin code for all BGP routes advertised
to all BGP peers.
The Junos OS has specific keywords to represent the different BGP origin codes. They are:
igp: Internal (value 0);
egp: External (value 1); and
incomplete: Incomplete (value 2).
www.juniper.net
MED Is Optional, Nontransitive

The BGP multiple exit discriminator (MED) attribute is an optional, nontransitive attribute of BGP.
Thus, a BGP implementation does not have to understand or use MEDs at all, and a MED is not sent
through one AS and on to another AS. In other words, MEDs are only exchanged between pairs of
directly connected ASs. So, by default, MED values are transmitted along with BGP routes within the
AS where the MED first originated and to all neighboring ASs. The MED travels no further without
some intervention from a policy or alternate configuration.
Used with Multiple Inter-AS Links

The MED is a type of routing metric assigned to BGP routes. The function of the MED is to assist a
neighboring AS to pick which of multiple links connecting the remote AS to the local AS (ingress
paths) to use for traffic to a particular route (prefix).
Seeks to Influence Inbound Traffic

MEDs are an attempt by the local AS to influence the routing decisions in the remote AS for traffic
inbound to the local AS, just like the origin attribute. And just like the origin attribute, MEDs are a
negative-bias mechanism to make some paths look worse than others.
www.juniper.net
Primitive Load Balancing

You can use MED values to perform some form of primitive load balancing between ASs with multiple
links between them. However, the use of MEDs for load balancing is neither efficient nor particularly
effective, compared to more sophisticated mechanisms available.
Usually Taken from IGP Metric

You can set MED values from multiple locations, including administrator configuration or IGP
metrics. However, it is very common to take MED values from the metric values in the IGP.
Effects Not Guaranteed

Despite the best efforts on the part of a local AS to manipulate MED values to influence inbound
traffic flows to the local AS, other ASs can always preempt, or even ignore, the MED. This reaction is
not only because the MED is an optional BGP attribute, but also because several other BGP
attributes are more important than MED in the BGP route selection process. For example, an altered
local-preference attribute always overrides the MED.
www.juniper.net
Simple MED Use

The slide shows a very basic example in the use of the BGP MED attribute to influence inter-AS traffic
flows.
AS 1 assigned its IP address spaces so that it can summarize its network into two major segments.
Furthermore, AS 1 is relatively cleanly divided into networks near the left most router (10.10.0.0/16
networks are nearby) and networks near the right most router (10.20.0.0/16 networks are nearby).
Perhaps the split is between Eastern and Western operations, but there are many other alternatives.
AS 1 has two EBGP sessions to the customer Acme and advertises both the 10.10.0.0/16 and the
10.20.0.0/16 networks to Acme on each EBGP session, as shown on the slide.
Naturally, AS 1 would like Acme to return traffic to the closest point in the network so that timely
packet delivery and low latency can be achieved. Ordinarily, AS 1 would have no real way to convey
this desire to Acme, and Acme would simply send traffic to AS 1 over whichever router Acme decides
to use based on its own routing policies.
However, the MED attribute offers a method for AS 1 to influence the routing policy on Acme for
traffic sent to AS 1. To accomplish this closest point goal, AS 1 alters the MED values on the routes
that it advertises to Acme with a BGP export routing policy.
www.juniper.net
Simple MED Use (contd.)

Both of the networks in AS 1 are advertised across both links for redundancy. All things being equal,
the routers in Acme still see multiple network paths to the routes in AS 1 as the AS 1 routes are
passed along throughout Acme. The Acme routers, however, use the MED values of 10 and 20 (10
being preferred) to choose the BGP path to install in their local routing tables.
Thus, within Acme, traffic to 10.10.0.0/16 networks flows to the left most router and out to AS 1,
while traffic to 10.20.0.0/16 networks flows to the right-most router and out to AS 1. AS 1 influenced
Acme, and, at the same time, achieved a primitive type of load balancing.
www.juniper.net
Sophisticated MED Use

The use of the MED attribute is straightforward when adjacent pairs of ASs are considered. The use
of the MED attribute becomes a little more complicated when more than one AS is involved.
Consider the AS networks on the slide. Both AS 2 and AS 3 advertise the 192.168.13.0/24 route to
AS 1 and want to influence the way AS 1 sends traffic to 192.168.13.0/24. All three of the
advertisements have identical local-preference values, AS-path lengths, and BGP origin codes. The
other IP addresses on the slide represent the router IDs of the three routers in R1, R3, and R4.
The MED value from the AS 2 router is the lowest among the three advertisements. Yet, when the
router in AS 1 chooses the BGP path to use in its local routing table, the AS 1 router most likely
chooses R1 in AS 3. Why should this be?
The problem in this scenario is that the default evaluation of the MED attribute only happens when
route advertisements come from the same neighboring AS. In this scenario, only two of the three
advertisements come from the same AS: those from R3 and R1. Between those two advertisements,
the route from R1 is the best, because of its lower MED value.
www.juniper.net
Sophisticated MED Use (contd.)

The route from R4 in AS 2 cannot be compared to the two routes from AS 3 because it is from a
different AS. At this point, AS 1 is left with the R1 and the R4 routes. The R1 route will most likely be
selected as the active path because this router has a lower router ID than R4.
However, the routers in AS 1 can compare the MED values for all three of these routes with the use of
the always-compare-med configuration statement. With this configuration, the path to
192.168.13.0/24 through R4 should be chosen, based on the lowest MED value.
www.juniper.net
Always Compare MEDs

By default, only the MED values from the same neighboring AS are compared to select a BGP path.
However, the always-compare-med configuration statement allows you to override the default
BGP behavior for MED evaluation.
When configured, all routes that have the shortest AS-path length are compared to each other to
determine the route with the smallest MED value, not just routes from the same AS. The route with
the lowest MED value is then selected as the active BGP path, regardless of the AS the route came
from. The lowest MED value is selected as long as other path selection values for the route, such as
local preference, are the same.
You must be cautious when comparing MED values from different ASs. Some inherent danger exists
when using the always-compare-med configuration option to compare MED values from more
than one AS because every AS in the Internet can set its own good and bad values for MEDs.
One AS might consider a MED of 50 as the best, while another AS might consider a MED of 5 to be
good. To complicate matters further, some AS networks might not set the MED value at all (MEDs are
optional), which essentially sets the MED value to 0.
www.juniper.net
MED Is Metric Applied to BGP

The Junos routing policy framework can use the BGP MED attribute as both a match condition and as
an action. The metric statement applied to BGP indicates the MED value. That is, a policy can
match on a certain MED value or set the MED value to a certain value as an action.
Value Can Be Manipulated Mathematically

Moreover, you can set the MED value not only to a specific value, but you can manipulate it
mathematically (add 100 to MED or subtract 50 from MED).
The example on the slide shows the MED attribute modified for certain routes. As mentioned, the
metric statement represents the MED value. Within a policy, you can set the metric to a value, you
can add to its current value, or you can subtract from its current value.
The policy shown:
Sets the MED to 50 for the 172.31.25.0/24 route;
Increases the current MED value by 50 for all routes within the 192.168.32.0/20
network; and
Decreases the current MED value by 50 for all routes within the 10.124.0.0/16 network
with a mask shorter than /24. Should the current value be less than 50, the result of
this policy action will be a MED value of 0.
www.juniper.net
Setting the MED Directly

The MED value can be set directly using the metric-out statement at the group or neighbor level
of [edit protocols bgp]. The following options are available:
www.juniper.net
Set to a specific value;
Set to the current IGP metric;
Set to the minimum IGP metric ever learned;
Can add or subtract from the IGP metric; and
Can use the statement within a routing policy.
MED and IGP Metrics

MED values do not have to be arbitrary. In many cases, the MED values are coordinated with the
metric values used by an IGP. Thus, BGP can set the MED value on routes advertised based on the
IGP metric leading to the BGP peer from which the route was received.
Use of Metric in a Policy

You can set the MED value to match the internal IGP metric to reach the IBGP peer that advertised
the route. Use the metric igp command to do this. As the IGP metric to this peer changes, the
MED value associated with these routes also changes. You can see this within the term
possible-igp-setting in the policy on the slide.
The MED value changes every time the IGP metric to the peer changes. If this is undesirable, you can
associate the MED to the lowest possible IGP metric ever known for the specific IBGP peer. The MED
might decrease if the IGP metric lowers, but a network failure that increases the IGP cost does not
increase the MED valuethe metric minimum-igp command alters this value. You can see this
setting within the term possible-minimum-igp-setting in the policy on the slide.
Lastly, you can use the addition and subtraction functions used with the add or subtract policy
functions of the metric command in conjunction with both the igp and minimum-igp options. To
alter the MED this way, use the metric igp offset or metric minimum-igp offset
command. You can both add to and subtract from the metric.
www.juniper.net
Aggregates Lose MED Information

MED values have, by default, a limited scope of operation. For example, by default, MED values are
not propagated through one AS and on to another AS (nontransitive). This limiting concept also
applies when route aggregation is examined.
When a new aggregate route is created, any MED values currently assigned to any contributing route
remain only with those routes. The aggregate route has no MED value assigned to it, which is a MED
value of 0. While at first this might seem to be a contradiction, because 0 is a MED, the aggregate
route has no method for determining which one MED value to choose, so a MED value of 0 is used.
No alternative really exists. Because a BGP route can have only one MED value, the aggregate must
choose what that value should be. Should the aggregate take the worst MED value from the
contributors and be conservative? Should the aggregate take the best MED value to not penalize
that contributing route? Should the aggregate average the contributors MED values together? None
of these would adequately represent all the contributing information, so the aggregate route takes
the ultimate conservative approach: MED equals 0, or no MED at all.
www.juniper.net
Default Aggregate MED Behavior

The slide shows the default MED behavior regarding aggregate routes. The router receives the
192.168.17.0/24 route with a MED of 10. You see this from the output of the show route
protocol bgp command, as shown on the slide.
The router has a locally defined aggregate route, which a policy injects into BGP (the policy is not
shown on the slide).
By examining the show route advertising-protocol bgp output, you can see that both
the aggregate route and the more specific, received BGP route are advertised. The 192.168.17.0/24
route maintains its MED of 10, and the aggregate route of 192.168.16.0/20 has no MED value
(MED=0) assigned. Of course, you can always change the MED value on the aggregate with a routing
policy, but this lack of an aggregate MED value is the default behavior.
Thus, it is ironic that MEDs, which are most useful between AS pairs, are useless by default on
aggregates, which are exactly the types of routes you want to send between AS pairs!
www.juniper.net
AS Path
www.juniper.net
The AS-Path Attribute

The AS-path attribute describes the path of autonomous systems that the route has been through
since it was sourced into BGP. When a BGP router receives routes in an update message, the first
action is to examine the current AS path to see if the local AS number (ASN) is in the path. If it is in
the path, it indicates that the route has been through the AS already; accepting the route would
cause a loop. Therefore, BGP drops the route. The Junos OS performs a verification to ensure that
the receiving routers AS number is not listed in the AS path. If the receiving routers AS number is
listed in the AS path, the router does not advertise the route.
By default, the AS-path value is changed as a route transitions between autonomous systems. The
AS-path value is null until the associated route is advertised out of the originating AS. As the route
leaves an AS, the BGP router adds the local AS number to the front of the path before sending it to a
peer. Using routing policy, you can prepend your ASN information to the AS-path attribute. By
prepending your ASN information to the AS-path multiple times, you can affect the routing decision
made by routers in other autonomous systems and discourage those routes from using that path
because of the longer AS-path.
The AS-path attribute is mandatory; thus, it must always be present for all BGP routes.
www.juniper.net
16-bit Autonomous System Numbers

AS numbers are assigned in blocks by the Internet Assigned Numbers Authority (IANA) to Regional
Internet Registries (RIRs). The RIR then assigns AS numbers to entities within its designated area.
RFC 1930 defined 65536 ASNs using 16-bit integers. The ASNs 0, 5632064511, and 65535 are
reserved by the IANA and should not be used in any routing environment. IANA designated AS
numbers 64512 through 65534 to be used for private networks.
32-bit Autonomous System Numbers

RFC 4893 defines 32-bit ASNs. These numbers are written either as simple integers, or in the form
x.y, where x and y are 16-bit numbers. Numbers of the form 0.y are exactly the old 16-bit AS
numbers, 1.y numbers and 65535.65535 are reserved, and the remainder of the space is available
for allocation.
www.juniper.net
Manipulating the AS Path

If the AS-path attribute is changed before the route is readvertised to other BGP routers, a route
through the local AS can look less attractive to another AS. Note that making the route more
attractive by shortening the AS path should not really be possible. However, you can lengthen the
path to make the AS-path attribute another type of negative-bias path selection mechanism. In other
words, unlengthened paths look more attractive for other AS networks to use than artificially
lengthened AS paths.
AS-Path Prepending
The only standard approach to alter the AS-path attribute is to add information to it by prepending.
You can use a routing policy to extend (by prepending) AS-path information artificially onto an existing
AS path. This type of a policy is often an attempt to influence traffic coming into an AS from another
AS.
www.juniper.net
AS-Path Prepending (contd.)

On the slide, AS 1 announces its routes to both AS 2 and AS 3. Using a routing policy, AS 1 prepends
its own AS number four times (shown as 1 1 1 1 1 on the slide) onto all route announcements to
AS 2. This action causes the following:
AS 2 will use AS 20 to forward packets to AS 1;
AS 30 will use AS 40 to forward packets to AS 1; and
AS 40 will use AS 10 to forward packets to AS 1.
Note that this behavior on the part of AS 2 (using AS 20 instead of sending directly to AS 1) is
unexpected and would not occur without the routing policy. This behavior is extended to AS 20 as
well, because AS 2 cannot shorten the AS path advertised by AS 1, even if AS 2 would like to shorten
it.
www.juniper.net
Policy to Prepend AS Path

The slide shows the routing policy AS 1 used in the previous example.
A policy named longer-as-path was created on the AS 1 router. Because no from statement
exists, all candidate routes match the policy. The action taken on all of the matched routes is to add
AS 1 to each route four times. You can use either the as-path-prepend as-number or the
as-path-expand last-as count number policy options to add AS numbers to the AS-path
attribute in an attempt to make a given route appear less desirable. The latter option automatically
locates the most recent AS in the path (the last entry) and prepends it the specified number of times
prior to advertising the route to EBGP peers. This particular action is performed with the
as-path-prepend statement. This routing policy then is applied for routes exported by BGP to the
external BGP peer in AS 2.
www.juniper.net
The Symbol Tells All

A symbol can provide information on an object. For example, when looking at the AS path on a
Juniper Networks router:
Brackets ([ ]): Enclose the local AS number associated with the AS path if more than one
AS number is configured on the router or if the AS number is being prepended.
Braces ({ }): Enclose AS setsgroups of AS numbers in which the order does not matter.
A set commonly results from route aggregation. The numbers in each AS set are
displayed in ascending order.
Parentheses ( ( ) ): Enclose a confederation.
Brackets inside parentheses ( ( [ ] ) ): Enclose a confederation set.
In the output on the slide, you can see four routes with different AS paths. The second route
represents a bracket output, the third route represents an AS set, and the fourth route represents a
confederation.
www.juniper.net
Regular Expressions
Often, administrative BGP routing policies require that route announcements or prefixes be found
and acted on based on the information contained within the AS-path attribute. This requirement
might be to enforce some administrative policy regarding other AS networks. Sometimes, it is just
easier to find routes based on their AS path than by looking for many specific prefixes and routes
individually.
Other Uses
The slide lists some examples of the types of information that must be found in the AS path.
Regular Expressions Can Find Prefixes

Through the use of regular expressions, you can quite easily find this type of information in the
AS-path attribute.
www.juniper.net
Regular Expressions for Pattern Matching

A regular expression (often called regex) is a powerful, pattern-matching tool you can apply in a
routing policy to act on AS-path strings. This pattern-matching engine can find specific strings of text
or textual patterns.
Different from Wildcards

When used in a routing policy, regular expressions work not only on fixed strings, like wildcard
operators such as an asterisk (*), but also on variable patterns of text, through the combination of
basic text patterns and special operators.
Text Plus Operators

Regular expressions are made up of a combination of basic text patterns and special operators.
Context-Sensitive Matching
Regular expressions allow information in a string to be found within a specific context, not just in
isolated instances. You can use regular expressions in conjunction with the BGP AS-path attribute to
match routes within a policy.
www.juniper.net
Configure a Regular Expression

Regular expressions have two main components to themthe term and the operator. These
expressions take the form term operator.
Terms Are AS Numbers in the AS-Path Attribute

The regular expression term is the core matching component to be found by the pattern-matching
engine. The term is a mandatory object, and each regular expression must have at least one term.
Terms identify the AS number. This AS could be a single number (1024), a complete AS path
(1024 2685 3957), or a wildcard character (.) representing any single AS number (1024 . 3957).
Each AS Is an Entity
Within the Junos AS-path regular expression syntax, the term is a complete AS value. You can use the
wildcard character of the dot ( . ) to represent a single AS number as well. Thus, the Junos OS detects
an AS number of 1024 (for example) not as the four character text string of 1, 0, 2, 4, but as the
single entity of 1024. To the Junos OS, AS numbers are not sequences of characters.
www.juniper.net
Regular Expression Operators

All regular expressions take the form term operator. Use of the term is mandatory.
The Operator Is Optional

However, the regular expression operator is an optional component of the pattern-matching engine.
You can associate an operator with a single, regular expression term. If used, the operator appears
immediately after the term on which it is operating.
Two special regular expression operators can appear between regular expression terms. These
special characters are the pipe ( | ) and the dash ( - ). You use the pipe ( | ) operator between terms
to indicate OR (1024 OR 2685 is 1024 | 2685). You use the dash ( - ) operator between terms to
indicate range (1024 through 2685 is 1024-2685).
More Than One

An individual regular expression can contain multiple term-operator pairs.
www.juniper.net
Regex Operators for the AS Path

The table on the slide shows a subset of the possible regular expression operators you can use with
routing policies. Some operators are a shorthand for their longer equivalents.
Of special note is the use of the parentheses. Typically, you use the parentheses ( ) operator to group
multiple terms together in conjunction with an operator. For example, the regular expression (1|2)?
is translated as either AS 1 or AS 2 can be present in the AS path zero times (absent), or at most one
time (this is what the ? operator means).
The parentheses operator also has another special use. When used with no spaces in between,
parentheses represent a null AS-path value. We cover the concept of the null AS path on future
slides.
www.juniper.net
AS-Path Regex Examples

The table on the slide shows some examples of regular expression pattern matching as applied to AS
paths.
The first column shows the AS-path string that the routing policy is trying to match. The second
column shows the regular expression used to match that pattern. The last column shows examples
of values of the BGP AS-path attribute that the regular expression will match. In some cases, the list
is not exhaustive, so more AS paths will match the pattern.
www.juniper.net
More AS-Path Regex Examples

The table on the slide shows more examples of regular expression pattern matching as applied to
AS paths.
As before, the first column shows the AS-path string that the routing policy tries to match. The
second column shows the regular expression used to match that pattern. The last column shows
examples of values of the BGP AS-path attribute that the regular expression will match. In some
cases, the list is not exhaustive, so more AS paths will match the pattern.
www.juniper.net
Regular Expressions and Policies

You can use AS-path regular expressions as the match criteria within a routing policy. This
application of the regular expression is similar in concept to the application of a policy. As such,
AS-path regular expressions follow the Junos abstraction concept of first defining the entity and then
applying the entity.
Format
Both the definition and application of the AS-path regular expressions occurs within the
policy-options configuration hierarchy. The regular expression in proper term operator
format is given a name with the as-path statement.
AS-Path Name
You can reference the regular expression name within a policy.
Spaces Are Allowed

The name can be up to 255 characters long and can even include spaces, as long as the name is
enclosed in double quotation marks. In practice, however, this practice is not common.
Applied After Definition

Once defined, you can apply the AS-path regular expression as a policy match condition.
www.juniper.net
AS-Path Regex Policy Example

The example on the slide shows an AS-path regular expression used as a policy match condition. The
goal is to have a BGP routing policy that accepts only routes with the exact AS path of
1234 56 78 9.
We defined an AS path named digits-route within the double quotation marks. The AS path
contains only terms (no operators) and defines an exact AS-path match of 1234 56 78 9.
We then used the digits-route path definition within the from-digits-route policy to match
routes and accept them. A second term in the policy rejects all other routes.
When you apply this policy as an import BGP policy, only routes matching the AS path defined in
digits-route are accepted. All other routes seen by BGP are rejected.
www.juniper.net
Another AS-Path Regex Policy Example

The example on the slide shows another AS-path regular expression used as a policy match
condition. This time, however, the AS path uses both terms and operators.
The goal this time is to reject routes that either originate in ASs 123125, transited through ASs
123125, or were advertised directly from ASs 123125.
To do this, we defined an AS path named not-a-good-route. The AS path contains both terms
and operators. Thus, not-a-good-route defines an AS-path match as follows:
The AS path starts off with any AS value zero or more times, followed by
Any AS value between 123 and 125, followed by
Any AS value zero or more times.
The not-a-good-route path definition is then used within the from-not-a-good-route

policy to match routes and reject them.
When you apply this policy as an import BGP policy, only routes matching an AS path defined in
not-a-good-route are rejected.
www.juniper.net
Given a Policy
Consider the routing policy shown on the slide.
Look at the Results

Does this policy, when properly applied, accept a route with the path 1024 44 44 2685, given the
as-path statements listed on the slide?
Using the different as-path definitions within the testing-as-paths policy gives the following
results:
.* 1024: Starts with any AS zero or more times, followed by 1024. The route will not
match the term as-paths. This definition does not allow for AS numbers after 1024.
Therefore, it is rejected by the final action.
1024 .*: Starts with 1024, followed by zero or more AS numbers. The route does
match the term as-paths. It is accepted.
.* 1024 .*: Starts with any AS zero or more times, followed by 1024, followed by
zero or more AS numbers. The route does match the term as-paths. It is accepted.
www.juniper.net
Look at the Results (contd.)
www.juniper.net
.* 44{1,2} .*: Starts with any AS zero or more times, followed by 44 once or
twice, followed by zero or more AS numbers. The route does match the term
as-paths. It is accepted.
2685 44{1,3} 1024: Start with AS 2685, followed by 44 one to three times,
followed by 1024. The route does not match the term as-paths. Therefore, it is
rejected by the final action.
1024 44{1,3} 2685: Start with AS 1024, followed by 44 one to three times,
followed by 2685. The route does match the term as-paths. It is accepted.
AS Path Regular Expression Enhancements

The AS-path regular expression examples shown thus far are perfectly workable. However,
circumstances occur where support for as-path-groups can save you some configuration work
and possible mental anguish. AS-path groups allow you to define a list of individual AS-path regular
expressions for evaluation as a logical OR within a policy. The example on the slide shows an AS-path
group named as-group-1, which comprises three individual AS-path regular expressions. The
as-group-1 AS-path group is referenced in the test-as-group policy using a single \
statement. You can specify multiple AS-path groups as part of a single from statement if needed.
Achieving the same result without the as-path-group feature requires that you define three
separate AS-path regular expressions that are evaluated as a logical OR:
[edit policy-options]
user@router# show
policy-statement not-ideal {
from as-path [ path_1 path_2 path_3 ];
}
as-path path_1 ".* 1 .*";
www.juniper.net
AS Path Regular Expression Enhancements (contd.)

Or, achieving the same result without the as-path-group feature requires that you define a
single, and possibly quite long, AS-path regular expression:
[edit policy-options]
user@router# show
policy-statement not-ideal-either {
from as-path customers;
}
as-path customers ".* 1 .*|.* 2 .*|.* 3 .*";
Using the as-path-group feature alleviates both of these issues. The example on the slide is
functionally identical to both of the alternatives shown here.
www.juniper.net
Role of Null AS Path

The concept of the null AS path is quite important for the Internet. Routes originating within a
particular AS have yet to prepend the BGP AS-path attribute. Therefore, no information is contained
in the AS-path attribute for routes originating within the AS, and the AS path is assumed to be null
(empty).
So, how are routes originating within the AS that were advertised with BGP to be found with a routing
policy using an AS-path policy? They are found by creating a match condition based on the null
AS path.
Defining the Null AS Path

To specify the null AS path using a regular expression, use the parentheses with no space in between
them.
In the example on the slide, the router receives four routes from IBGP. By examining the routing table,
you can see that the AS path column is empty (I is for the origin code). Therefore, these routes were
sourced within the routers own AS. The null AS path finds these routes.
www.juniper.net
Finding Local Routes

You can use the null AS path to find routes advertised by BGP that originated within the local
AS path. When would this be helpful? Usually, when one AS path does not want to carry transit traffic
for another AS path.
In the example on the slide, the null AS path is used to halt BGP transit traffic from AS 1 through
AS 2. AS 2 does not want to readvertise the routes from AS 1 to AS 4, which could lead to AS 4
routing traffic for AS 1 through AS 2. However, AS 2 still must advertise its own routes to AS 4 so that
these prefixes are reachable. AS 2 defines an as-path applied as a BGP export policy towards AS 4
that rejects all routes except those with a null AS path.
www.juniper.net
Use of Null AS Path: Part 1

The slide shows an example of null AS path in action.
We applied the not-a-transit policy on the slide as an export policy on R2 towards the EBGP
peer on the right side of the diagram. The policy has a term called accept-my-as that matches
BGP routes with an as-path regular expression of (). The reject-all-else term rejects all
other routes.
www.juniper.net
Use of Null AS Path: Part 2

The slide shows the results of the previously configured and applied policy.
The show route protocol bgp output shows that the router R2 receives five BGP routes from
its IBGP peer R1. One of these routes is from AS 1, and the other four are sourced from within the AS.
The show route advertising-protocol bgp output shows that only the four routes
sourced from within the AS are sent to the EBGP peer. The null AS-path regular expression in the
routing policy rejects transit routes.
www.juniper.net
Various BGP attributes in detail and explained the operation of those attributes; and
How to manipulate BGP attributes using routing policy.
www.juniper.net
Review Questions
1.
2.
3.
4.
www.juniper.net
Lab 8: BGP Attributes: Next-Hop, Origin, MED, and AS Path

This slide provides the objectives for this lab.
www.juniper.net

Routing
The BGP attributes local preference and communities and explains the operation of
those attributes; and
The manipulation of those BGP attributes using routing policy.
www.juniper.net
Local Preference
www.juniper.net
Local-Preference Power
The BGP attribute of local preference is the highest tiebreaker in the BGP path selection process. If a
BGP next hop is reachable, and BGP knows multiple routes, BGP always chooses the route with the
highest local preference. Thus, local preference is the first BGP attribute that favors one path over
another.
Highest Local Preference Wins

Because of the position of the BGP local preference, neither the AS-path length, nor the origin code,
nor the MED value matters. The route with the highest local-preference value is always chosen as the
exit point of the ASthe end.
www.juniper.net
Local-Preference BGP Attribute

Do not confuse the BGP attribute of local preference with the Junos OS concept of route preference.
The Junos OS route preference is local to an individual router and assists the routing table in
choosing the active route among many possible paths.
The BGP local-preference attribute is used only within BGP itself. The BGP routers transmit the local
preference within an AS. If you do not explicitly configure a value for local preference, the default
value used on BGP routes is 100. You can change this value on a per-peer basis using the
local-preference command within the [edit protocols bgp] configuration hierarchy
directory. In addition, you can alter the value using a policy on a per-route basis. The policy action
also uses the local-preference command to alter the attribute value.
Default Local Preference = 100, BGP Preference = 170

The default local preference applied to a BGP route is 100. However, the default route preference
applied to BGP itself is 170. The Junos preference applies to the entire routing protocol. Preference
is also set in the [edit protocols bgp] configuration hierarchy directory, but as
preference, not local-preference (which applies only to BGP).
Pay Attention
When it comes to routing policy configurations, make sure to change local preference on the BGP
routes, not the preference of the BGP protocol as a whole!
www.juniper.net
IBGP Peers Exchange Local Preference

Only IBGP peers exchange the values of the local-preference BGP attribute. EBGP peers never see a
local preference set on route information sent between AS networks.
Sets Exit Point

You typically use the local preference to set the preferred exit point for a particular route from an AS.
This use can be important when several links exist between two ASs.
IBGP Distributes Local-Preference Information

Once the local preference for a route is set, IBGP propagates that information throughout the entire
AS.
www.juniper.net
How to Get to 172.17.2.0/24?

The slide shows the concept of how local preference affects traffic leaving an AS. The administrators
of the AS on the left know that Router B should always be used to reach the 172.17.2.0/24 network
in the AS on the right. Therefore, the administrators of the AS on the left can configure their edge
routers to set the local-preference value higher on the copy of the route received on Router B than
the copy received on Router A. IBGP makes sure that every router in the AS knows that the preferred
exit point for this route is Router B. Note that the AS on the right neither knows nor cares about the
value of the local preference assigned to the route by Router A or Router B.
The AS on the left still has failover capability because it receives the route from the AS on the right
through both routers. Although Router B is the primary exit point for the route, user traffic can use
Router A to reach the AS on the right in the event of a failure.
www.juniper.net
Example of Local-Preference Use

The slide shows an example of local-preference use within an AS.
The network administrators in ISP A decided that the routers in ISP A should use R2 to reach the
192.168.27.0/24 network in ISP C. This decision is because of the greater bandwidth capacity
available on that 10 Gigabit Ethernet link.
To perform this router assignment, the ISP A network administrators set the local preference to 200
on the route to 192.168.27.0/24 advertised to R1 by ISP B, and set the local preference to 300 on
the route to 192.168.27.0/24 advertised to R2 by ISP D.
In contrast to almost every other metric associated with routing protocols, the highest local
preference is better. Thus, for this route, the exit point of the AS is through R2. IBGP makes these
values known to all other routers in ISP A.
The link on R1 can still be used for inbound traffic flows from ISP C and for outbound failover traffic if
the 10 Gigabit Ethernet link is not useable because of a router or link failure.
www.juniper.net
Local AS Only
The slide points out the local nature of local preference. Consider another AS called ISP E linked by
two lower-speed, but equal, links to ISP A. Which link should ISP E use to reach 192.168.27.0/24 in
ISP B?
Because EBGP does not propagate the local-preference values used inside ISP A, the ISP E AS has
no knowledge of the local-preference routing decisions made within ISP A with regard to the
192.168.27.0/24 route. ISP A, of course, still wants traffic from ISP E to flow towards R2 to avoid
shuttling all this traffic across its backbone.
Another Method Needed

However, ISP A cannot accomplish this goal with local preference. ISP A must use other BGP
attributes instead of local preference, such as AS path or MED, to influence ISP Es flow of traffic to
ISP A. This is because of the strictly local nature of the local-preference attribute.
www.juniper.net
Changing Local Preference with a Policy

In many cases, when it comes to local preference, a routing policy does not consider routes in
isolation but considers other BGP attributes, such as the AS path, to select routes for preferred local
handling.
The example on the slide alters the local-preference value for all received routes that match the
AS path of look-for-path. Within the term got-path, we specified an action of
local-preference 200. This action changes the local-preference attribute value for those
routes to 200.
This routing policy does not affect any other received BGP routes.
www.juniper.net
Local Preference and Routing Loops

The case study on the slide provides an interesting look at the operation of BGP in general, and how
BGP uses local preference specifically.
Considering that the local-preference attribute overrides all other BGP attributes in the path
selection process, it might be possible to create a routing loop in BGP. Routing loops are especially
bad because the destination is technically reachable, but some or even all routers within an AS
cannot find the proper path to the destination.
In the example on the slide, both R1 and R2 have an export policy in place that sets the local
preference to 1000 on EBGP routes before these routes are readvertised to IBGP peers. Note that
R1 and R2 have an IBGP peering relationship with each other, which means that both routers also
advertise the route to each other.
Theoretically, both R1 and R2 could see the preferred value of 1000 in the copy of the route they
receive from each other. This information makes each router determine that the IBGP version is
better than the local (EBGP) copy of the route! This determination occurs because the local
preference on the EBGP version of the route that is stored within the router is still set to 100. As a
result, R1 and R2 see each other as the best route to 172.17.0.0/16, and a routing loop occurs as
the two routers shuttle traffic back and forth.
Note that this situation is easily avoided by setting a routes local preference at ingress using an
import policy. In this case, the local copy of the route as received from an EBGP peer will correctly
reflect the local preference modification.
www.juniper.net
Split Horizon for Local Preference

It turns out that BGP is smart in this case. The following chain of events assumes that R2 received
the EBGP route of 172.17.0.0/16 first and advertises the route with a local preference of 1000 to its
IBGP peers. (If R1 accomplishes this first, the roles are easily reversed, but the point is the same.)
First, R2 receives the EBGP route of 172.17.0.0/16 from its peer in the other AS. Because R2 detects
this route as the current best, R2 installs the route in its routing table.
Next, R2 alters the local preference to 1000 and advertises this route to its IBGP peers with this
local-preference value. At this point, both R1 and R3 receive the 172.17.0.0/16 route through IBGP.
R1 then also receives the EBGP route for 172.17.0.0/16 from the other AS. At this point, R1
determines that it already has a route to 172.17.0.0/16 from R2, with a local preference of 1000.
The presence of this route to R2 overrides the EBGP-received route.
Because the current version of the route on R1 is from R2, and because IBGP implements split
horizon, the routing loop never forms. R1 just sends traffic for 172.17.0.0/16 to R2. And because
only active BGP routes are advertised, no confusion develops on R3 with regard to the best path to
reach 172.17.0.0/16R2 is the choice.
www.juniper.net
Communities
www.juniper.net
Optional, but Transitive

The BGP community attribute is an optional attribute, so not all implementations of BGP must
recognize and use communities. However, if BGP communities are associated with a BGP route, the
BGP community attribute must be passed along to all other BGP peers, both within an AS and
between AS networks (transitive).
Routes Having Something in Common

The BGP community attribute is an administrative tag that you can use to associate routes together
that share common properties. The BGP community attribute is not complex. The main role of the
BGP community attribute is to make it easy to group routes that should be treated the same by a
routing policy. BGP communities are very flexible: a BGP route can belong to many BGP communities.
Make Routing Simpler

The attraction of BGP communities is that they can simplify routing policies. BGP communities
identify routes based on the logical boundaries you establish and not what the AS number (too broad
in most cases) or individual IP prefix (too granular in most cases) establishes.
Use with Other BGP Attributes

You can use the community attribute within routing policies to accept or reject routes based on the
values of the BGP community tags. In addition, you can use the community attribute values with
other BGP attributes to implement routing policies that accept, prefer, or advertise BGP routes.
www.juniper.net
Clubs for Routes

BGP communities establish various logical categories for routes (prefixes). Think of BGP
communities as communities of interest or even clubs for routes. And just as people can belong to
more than one club, routes can fit into more than one BGP community.
Can Carry Local-Preference Value Beyond Local AS

The BGP community attribute value often implements policies for customer networks, such as
altering the local-preference attribute on incoming routes.
Goal: Less Work

The community attribute can assist you in the configuration and maintenance of policies. This cuts
down on the time needed for manual reconfiguration and the complexity of the overall maintenance
task.
www.juniper.net
Community Use Example

As an example, consider the addition of a new prefix for a new customer within an AS. If you use
communities to enforce routing for customer networks, and you can place the new prefix into an
existing community, you do not need any changes to overall routing policies. When new customers
are brought into the network, you must only assign the new routes the proper community attribute.
Without the use of communities, you might need to update each policy in the network to include the
new customer information.
Too Many Communities

However, you must be careful when establishing communities for the first time. Too many
communities defeat the whole purpose. Maintenance of the communities then becomes as tedious
as maintaining a whole list of route filters.
Overlapping Communities
You should also avoid having too many overlapping communities. Customer routes belonging to
multiple communities can also be an issue.
When it comes to communities, simplicity is always a worthwhile goal.
www.juniper.net
Well-Known Communities
Certain well-known communities have a global meaning and special purposes. They are defined in
RFC 1997. All BGP implementations that understand communities (communities are optional, but
transitive) must know these communities and respect their functions.
Communities for Local Use

BGP communities that are not well-known are for local use. You must define local-use communities
locally, but because the BGP community attribute follows the BGP route wherever it goes, even
local-use communities are circulated outside the AS. So, you must take care in using BGP community
attribute values arriving from other AS networks. BGP communities are best thought of as a category
for a group of routes (such as, all customers).
Community Format
The BGP community attribute itself is just a list of the individual community attribute values
associated with the route (tags). Because no real limit exists on the number of tags in the list, a route
can belong to many communities. No predefined, upper limit exists on the number of communities
allowed on a route.
www.juniper.net
Community Format (contd.)

The community attribute values themselves are designed so the values can be uniquely assigned in
the global Internet. The BGP community attribute itself is a 32-bit (4-octet) value that has two parts.
The two high-order octets (16 bits) form the first part and are set aside for the AS number of the
network that assigned the community to the route in the first place. The two low-order octets
(16 bits) form the second part and are set aside for use by the specific AS networks. Because the AS
value is included in the community, the value is guaranteed to be unique on the whole Internet.
When written in bits or hexadecimal format, community values can look very odd. Thus, communities
are usually represented in decimal form as AS:number. For example, 200:666 is community 666 in
AS 200. One restriction on possible communities values is that the AS values of 0 and 65535 are
reserved and cannot be assigned to a route. Therefore, in combination, this restriction covers values
0x00000000 to 0x0000FFFF (AS 0) and 0xFFFF0000 to 0xFFFFFFFF (AS 65535).
RFC 4360 provides support for an extended community attribute. An extended community
attribute consists of eight octets. The BGP extended communities attribute format has three fields:
type:administrator:assigned-number.
www.juniper.net
The Three Well-Known Communities

Three community attribute values are designated as well-known communities. These well-known
communities share the AS value of 65535 (0xFFFFxxxx). The three communities are no-export,
no-advertise, and no-export-subconfed.
No-export (0xFFFFFF01): This value tells routers to distribute routes with this
community tag within the confederation or AS, but no farther.
No-advertise (0xFFFFFF02): This value tells routers not to advertise these routes to
other BGP peers at all. (Despite appearances, this BGP community is quite useful.)
No-export-subconfed (0xFFFFFF03): This value tells routers not to distribute routes with
this community tag to external BGP peers (thus, they are confined to the sub-AS).
No-Export
The no-export community typically makes sure that route aggregation is optimal by suppressing more
specific routes. The no-export-subconfed just extends this aggregate concept to the sub-AS.
No-Advertise
The no-advertise community has a very narrow scope. Routes go to a BGP peer and no farther,
usually because peers know the routes through other means. This community is often used in a
LAN-connected router environment or when two BGP peers have multiple links between them.
www.juniper.net
Sample Use of No-Advertise

The slide shows an example of the scope of the no-advertise community. The arrow at the lower right
shows a BGP route with the no-advertise community injected by R1 into an AS with
sub-confederations.
The well-known community attribute value of no-advertise is designed such that a route can be sent
to a single BGP peer and be advertised no farther. Routes are restricted to the next-hop router R2.
www.juniper.net
Sample Use of No-Export-Subconfed

The slide shows an example of the scope of the no-export-subconfed community. The arrow at the
lower right shows a BGP route with the no-export-subconfed community injected by R1 into an AS
with sub-confederations.
The well-known community attribute value of no-export-subconfed is designed such that a route can
be sent into a BGP confederation network and have the information remain with a particular sub-AS.
The routing information is advertised no farther than the sub-AS routers R3 and R4, as shown on the
slide.
www.juniper.net
Sample Use of No-Export

The slide shows an example of the scope of the no-export community. The arrow at the lower right
shows a BGP route with the no-export community injected by R1 into an AS with sub-confederations.
The well-known community attribute value of no-export is designed such that a route can be sent into
a neighboring AS and have the information remain within that neighboring AS. Normally, BGP
communities are transitive and are passed from each AS to all others, even if the router does not
support or use the BGP community option. However, the routing information with the no-export
community tag is not advertised beyond the AS routers R5, R6 and R7, as shown on the slide.
www.juniper.net
No-Export Example
The slide shows a typical use of the BGP no-export community.
AS 1 has multiple BGP sessions to its neighbor, AS 2. AS 1 also uses AS 2 as a transit AS for
connectivity to the Internet. AS 1 wants to advertise 172.17.0.0/16 to the Internet because AS 1
owns that entire address space. In addition, AS 1 also wants to advertise more specific route
information (shown as 172.17.0/17 and 172.17.128/17) only to its peer, AS 2.
Advertising the specifics as well as the aggregate to AS 2 would assist AS 2 to route user traffic into
AS 1 more efficiently because load sharing could be used on the more specific routes, as shown on
the slide. However, why should the whole Internet know or care about these specifics?
To assist AS 2 in finding and rejecting the more specific routes, AS 1 assigns the no-export
community to the 172.17.0.0/17 and the 172.17.128.0/17 routes. The BGP edge routers in AS 2 that
connect to the Internet automatically suppress and do not readvertise the /17 routes. Only the /16
route is readvertised to the Internet.
www.juniper.net
No-Export and Multihoming

The BGP well-known community no-export is also useful when a customer is multihomed to two ISPs.
In the example on the slide, the customer wants to receive Internet traffic through one main ISP but
be able to receive locally originating traffic from the other ISP (perhaps a major trading partner uses
AS 2 as its ISP).
One way to do this (among other ways) is with the BGP no-export community. In this example, the
customer has AS 1 as its main ISP.
Customer AS 20 has address space 172.17.144.0/20, taken from AS 1s address space of
172.16.0.0/16. The 172.17.144.0/20 route is advertised with BGP to both AS 1 and AS 2. Because
AS 2 is not the primary ISP, and only traffic originating in AS 2 should reach AS 20 directly, the route
advertised to AS 2 is given the BGP no-export community. This route goes no farther than AS 2. AS 2
advertises 172.31.0.0/16 to AS 1 and the Internet, but does not advertise 172.17.144.0/20.
AS 1 covers the 172.17.144/20 address space with aggregate 172.17.0.0/16, as shown on the slide.
This is advertised to AS 2 and the Internet. Thus, AS 20 is reachable through AS 1 from the Internet,
but AS 20 is only reachable by local AS 2 users.
A drawback of this scenario is that if the link from AS 20 to AS 1 fails, the 172.17.144.0/20 route is
not reachable from the Internet through AS 2. However, because AS 2 is not the primary ISP for AS
20, this might be acceptable.
www.juniper.net
Transit AS for Backup

One of the most common uses of the BGP community attribute addresses one major limitation of the
BGP local-preference attribute. Local preference is only distributed within an AS, and no
local-preference information is ever sent between two AS networks. Yet, local preference is a
valuable way to establish proper exit points for a route within an AS, especially when the AS has
multiple links. How can another AS be informed of the local preferences of a route learned from
another AS? The most popular way to do this is with BGP communities.
In the example on the slide, the customer AS at the bottom agreed to provide backup transit service
to both AS 1 and AS 2 in case their links to each other are lost. The slide shows the address spaces
used. The customer AS uses 172.17.64.0/18 and 172.20.128.0/18.
The customer wants to make the 172.20.0.0/16 route sent to AS 1 to have a lower local preference
than the default of 100, and to make the 172.17.0.0/16 route sent to AS 2 to have a lower local
preference than the default of 100 there as well.
www.juniper.net
Transit AS for Backup (contd.)

The key to making this work is with the BGP communities on routes sent to AS 1 and AS 2. Route
172.20.0.0/16 sent to AS 1 is tagged as community 1:60. This says to AS 1, AS 1, within your AS,
this route should have a local preference of 60. The route 172.17.0.0/16 sent to AS 2 is tagged as
community 2:70. This says to AS 2, AS 2, within your AS, this route should have a local preference of
70. In this example, AS 1 and AS 2 only advertise aggregate routes to each other and the Internet.
If AS 1 and AS 2 set the local preferences on these routes as requested, the exit points through the
customers AS are only active when there is no normal peering route available (local preference =
100).
Enforcing Communities
Of course, setting local preferences in other AS networks with communities requires all the AS
administrators to cooperate. Nothing makes an AS respect the community attribute value.
www.juniper.net
Policies and Transit AS

The BGP community attribute plays a key role in defining whether an AS is a transit or nontransit
network. A transit AS carries traffic that neither originates in that AS nor is destined for hosts within
the AS. A nontransit AS only carries traffic that has its own addresses appearing as either the source
or the destination. Nontransit AS networks must be careful when advertising BGP routes outside the
AS. A nontransit AS can advertise only local routes.
Communities Can Hold Back Routes

You can use routing policies in combination with BGP communities to make an AS appear to be a
transit AS or a nontransit AS. Communities make it much easier to hold back routes that might be
advertised and attract transit traffic.
Generally, a small ISP must advertise its own local routes but never be a transit AS for larger ISPs.
Such a situation could easily swamp the operation of a small ISP.
The slide shows a small ISP linked to two larger, national ISPs: National ISP #1 and National ISP #2.
As an example of what could happen, consider that National ISP #1 advertises BGP routes to R1 of
the small ISP as shown on the left. R1 advertises not only its own local routes to R2 in the small ISP,
but also National ISP #1s routes, so that all users can reach these routes.
www.juniper.net
Communities Can Hold Back Routes (contd.)

But R2 should never, ever advertise National ISP #1s routes to National ISP #2! R1s and R2s local
routes are okay to send to National ISP #2. However, if R2 ever advertises the National ISP #1 routes
to National ISP #2, and the link (or links) between the two national ISPs ever fail, National ISP #2 will
think that a good way to reach National ISP #1 is through the small ISP! Hence, the small ISP is now
a transit network.
www.juniper.net
Configuring Communities
You configure BGP communities in the Junos OS at the [edit policy-options] CLI hierarchy
level. You simply give the community a name and a number of members in the form of the
community ID. When you define multiple community members, a logical AND is between them. Thus,
a given name represents Community1, AND Community2, AND Community3, and so on.
Community ID Format
The community ID has an as-number:community-value format, with a colon (:) separating the
high-order and low-order octets. You can use the keywords no-export, no-advertise, and
no-export-subconfed to specify the well-known community values.
Can Use in Policy

When used in a routing policy, you can use the community name as a match condition (that is, find
these BGP communities) or as an action. Actions applied to communities include the adding,
deleting, or setting of community attribute values.
www.juniper.net
Add to the Community String

The slide shows the definition and application of a community in a routing policy. This policy leaves
the existing community tags on the route in place but also adds the specified community attribute
value to the route.
Route 192.168.0.0/24 currently has four community tags on the route: 64512:567, 100:20, 50:70,
and 1234:66.
Because the policy community-actions has no from statement, all routes are matched. It is not
necessary to check for just the BGP routes because only BGP has a community attribute to change.
(Including a from protocol bgp statement does not change the action of the routing policy.)
All BGP routes have the community tag test-comm value of 65001:1234 added to the existing
community tags on the route. The action of then community add test-comm performs this
test.
After you correctly apply this routing policy, the 192.168.0.0/24 route has five community tags on
the route: 64512:567, 100:20, 50:70, 1234:66, and the added 65001:1234.
www.juniper.net
Delete from the Community String

This slide also shows a policy that defines and applies a community in a routing policy. This policy
removes only the specified values of the existing community tags and leaves other existing
community tags in place.
Route 192.168.0.0/24 currently has the same four community tags on the route: 64512:567,
100:20, 50:70, and 1234:66.
Because the policy community-actions has no from statement, all routes are matched.
All BGP routes have the community tag test-comm value of 64512:567 deleted from the existing
community tags on the route. The action of then community delete test-comm performs this
task.
After you correctly apply this routing policy, the 192.168.0.0/24 route has only three community tags
on the route: 100:20, 50:70, and 1234:66.
www.juniper.net
Set the Community String

The slide also shows a policy that defines and applies a community in a routing policy. This policy
removes all the values of the existing community tags and adds (that is, sets) the new community tag
(or tags) in place.
Route 192.168.0.0/24 currently has the same four community tags on the route: 64512:567,
100:20, 50:70, and 1234:66.
Because the policy community-actions has no from statement, all routes are matched.
All BGP routes have the community tag test-comm value of 65001:1234 set as the existing
community tag on the route. The action of then community set test-comm performs this task.
After you correctly apply this routing policy, the 192.168.0.0/24 route has only one community tag
on the route: 65001:1234.
www.juniper.net
First Example Using Community

The slide shows a realistic application of the BGP community attribute. The goal is to create a
community named customers. We define the community as having two members: 56:2379 AND
23:46944.
When we use this community in a routing policy to find (that is, match) routes, the community
matches routes that have both 56:2379 AND 23:46944 as a community tag value.
Once found, these routes are assigned a MED value (the BGP metric) of 20 and a local-preference
value of 200 (instead of the default 100).
www.juniper.net
Second Example Using Community

The slide shows another realistic example of a BGP community. The goal is to define and attach a
community named my-accept to routes that are accepted by the policy. In this example, the policy
drops routes that are too specific, based upon the prefixs address class, while tagging all other
routes with the community value of 567:1.
The drop-specifics routing policy accepts the desired routes using a series of route filters that
are based upon address classes (A, B, and C) and the allowed prefix length. The community add
statement attaches the 567:1 community to any existing communities on routes that match the
route filters.
The final reject action serves to reject all routes that are not matched by the previous route filters.
It bears stressing that this reject statement is part of a unnamed term with no match criteria.
Operators often forget that the final term in a policy can be unnamed, and it is easy to mistake the
reject action in this example as belonging to the drop-specifics term if you do not take
careful analysis.
www.juniper.net
Second Example Using Community (contd.)

An equally workable approach that makes use of a single unnamed term is shown here:
[edit policy-options policy-statement drop-specifics]
user@router# show
from {
route-filter 0.0.0.0/1 upto /19 {
community add my-accept;
next policy;
}
next policy;
}
next policy;
}
route-filter 0.0.0.0/1 upto /32;
}
then reject;
In this approach, a series of class-based route filters are added to match on Class A, B, and C
addresses that have prefix lengths longer than 19, 16, and 24 respectively. Note that the final series
of route filters do not have any actions specified in the route filter statement. As a result, traffic that
matches these statements is subjected to the unnamed terms reject action. Some might argue
that this approach is better because the policy's single term means that the J-tree is only evaluated
once. In reality, the performance benefit, if any, is negligible, making both policies equally workable.
www.juniper.net
Routing Policies and Deletions

In contrast to other BGP attributes like AS path, BGP allows you to delete some or all the community
attribute values on a BGP route. In fact, deleting these values is very useful to do at the boundaries
of an AS because there is no guarantee that any other AS understands or respects the values of the
communities established in one AS.
Default Is to Send
If you do not delete community attribute values, by default, all BGP communities are sent to all peers
inside an AS and outside the AS. Why clutter up the routing updates with useless and potentially
harmful information?
To Stop, Use Delete

To stop the community from being advertised beyond the local AS, you must delete the community.
www.juniper.net
Delete All Communities

The slide shows a routing policy that deletes all communities from a BGP route. This example uses
the wildcard asterisk character (*) to match all communities. The action of community delete
wild-match performs this task.
Note that you must apply the wildcard to both halves of the communitythe AS number as well as
the community value. The syntax is therefore *:* to match all communities.
www.juniper.net
Simple Community Regular Expressions

You can use a regular expression (also called, regex), first introduced in an earlier section on AS
paths, also with BGP communities to produce a powerful pattern-matching system for finding
communities that match a given regex. Regular expressions used with communities implement the
full capabilities of a complete regex implementation, unlike the AS-path regex syntax, which used a
subset.
Consider two forms of regular expressions used with routing policies concerned with BGP
communities. These two forms are simple and complex regular expressions. These are informal
terms, defined in this course as follows. Simple community regular expressions contain only the
asterisk (*) or dot (.) wildcard characters separately. Complex community regular expressions can
use the asterisk and dot in conjunction with each other. Further, the complex regex statements can
use additional operator syntax characters.
The asterisk matches any single AS number or community value. The dot matches any single digit
within the AS number or community value. Note that the combination of these characters (.*) is a
complex community regex, which we discuss on a later slide.
www.juniper.net
Examples of Simple Community Regular Expressions

Some examples of simple community regex matches are:
www.juniper.net
*:1000 = Any possible AS number with a value of 1000.
65001:* = AS 65001 with any possible community value.
65001:100. = AS 65001 with community values of 1000, 1001, 1002, 1003, 1004,
1005, 1006, 1007, 1008, or 1009.
11.1:1000 = AS 1101, 1111, 1121,1131, 1141, 1151, 1161, 1171, 1181, or 1191
with a community value of 1000.
Matching the Community: Part 1

You can use standard CLI commands with simple regular expressions to find the routes (if any)
associated with any community. The slide shows a few examples.
To find all routes having a community value of 20, regardless of AS number, use the command show
route community *:20 terse. This command shows the routes but not the complete
community attribute values associated with the routes. To see the communities and more detailed
information, use show route community *:20 detail.
www.juniper.net
Matching the Community: Part 2

In addition to the standard CLI commands seen previously, you can also locate a route using the
name of a community.
The example on the slide shows a community called community-1 defined within [edit
policy-options]. This community represents the value of 1:20. You can use this community
name in the show route community-name community-1 detail command to view all
routes having this community assigned.
www.juniper.net
Complex Community Regular Expressions

You can use more complex regular expressions (regex) with communities. A community regular
expression is character based, unlike the regular expressions used with AS paths, which match
entire AS numbers.
The format for the community regular expression is still term operator as in AS-path regular
expressions, but the application of the term and operator is different.
When formulated for use with communities, the regular expression anchors of start (^) and end ($)
are not required, but these anchors can be helpful to organize and clearly represent the regular
expression.
You can use complex regular expressions in both the show route CLI commands and within a
policy as a match condition.
www.juniper.net
Community Regular Expression Operators

The table on the slide shows a list of the possible regular expression operators you can use with BGP
communities. Some operators are shorthand for their longer equivalents. For example, the plus (+) is
the same as {1,}. Both match one or more repetition of the term preceding the operator.
The square brackets ( [ ] ) match a range ([2-8]) or array ([256]) of numbers. Thus, the first
regular expression in the previous sentence matches 2 through 8, and the second one matches 2 or
5 or 6.
Of special note is the use of the parentheses. Typically, you use the parentheses ( ) operator to group
multiple terms in conjunction with an operator. The parentheses operator also has another special
use. When used with no spaces in between, parentheses represent a null value.
www.juniper.net
Examples of Complex Community Regular Expressions

The slide shows some examples of quite complex regular expressions you can use to match
communities in routing policies.
The first column shows the BGP community string that the routing policy is trying to match. The
second column shows the community regular expression used to match that pattern. The last
column shows examples of values of the BGP community attribute that the regular expression
matches. In some cases, the list is not exhaustive, so more possible communities match the pattern.
Note the presence of the colon (:) to separate the AS number of community value sections of the
community.
www.juniper.net
Complicated Community Regular Expression Example

The answer to the question on the slide is yes, the community regular expression on the slide meets
the criteria outlined. This complex regular expression uses multiple term-operator pairs in its
definition. To understand better how the expression operates, lets reconstruct it from the ground up.
First, we have a basic expression of ^():()$. This part of the expression sets the foundation for the
complete expression. Loosely speaking, we search for an exact match of an AS number followed by a
colon (:), followed by an exact match of a community value.
Next, we assign the AS value. This AS value is actually a regular expression in itself that states the AS
is either 105, 207, or 309. The pipe ( | ) operator separates the three AS numbers into logical OR
groupings. The extra parentheses are used to set aside each AS number explicitly from the pipe
operator. The regular expression now appears as ^((105)|(207)|(309)):()$.
Now we can define the community values. As with the AS numbers, the values can be one of three
separate entities. Again, we use the pipe operator to separate the values and the parenthesis to
define the possible values explicitly. The regular expression is now
^((105)|(207)|(309)):(()|()|())$. Each of the possible community values in this
example is an individual expression itself. Well examine each one in turn.
www.juniper.net
Complicated Community Regular Expression Example (contd.)

The first possible value is a 4- or 5-digit number, where the first character is a 1. Because the
community expressions are a character-based match, the expression starts simply with a 1. The
following characters in the value can be any number, so the wildcard of dot (.) is used to represent
that. Because the total value should be 4 or 5 digits, the wildcard can be operated upon with a
{3,4}, which means at least three instances of any number can appear, but no more than four
instances. Combined with the character of 1 to start the value, the wildcard-operator pair makes the
value a 4- or 5-digit number. The regular expression now appears as:
^((105)|(207)|(309)):((1.{3,4})|()|())$.
The second possible value can be any length, but it must start with either a 2, 5, or 6. Again, the
community expressions are character based, so this value should also start with a character. These
are actually three possible characters in this single position, so the brackets are used ([256]) to
signify a range of possible values. Following that, there can be more characters in the value, or there
could be no characters in the value. To represent this possibility, we once again use the wildcard dot
(.). In this case, the wildcard is operated on by the asterisk (*), which results in a .* notation. This
represents any possible value present zero or more times. Combined with the [256], this
wildcard-operator pair gives any possible value of any length as long as it starts with a 2, 5, or a 6.
The regular expression now appears as:
^((105)|(207)|(309)):((1.{3,4})|([256].*)|())$.
The final possible value can again be any length. This time, it must end with either a 3, 4, 7, or 9. The
logic for this value is exactly the opposite of the logic for the second value, so we can use the same
operators. In this case, the value starts with the .*, which again represents any possible value
present zero or more times. This is followed by the bracket notation of [3479] to represent a single
character in that single position. When combined, the result is any possible value of any possible
length, as long as it ends with a 3, 4, 7, or a 9. The regular expression now appears as:
^((105)|(207)|(309)):((1.{3,4})|([256].*)|(.*[3479]))$.
www.juniper.net
www.juniper.net
The BGP attributes local preference and communities in detail and explained the
operation of those attributes; and
How to manipulate those BGP attributes using routing policy.
Review Questions
1.
2.
3.
4.
www.juniper.net
Lab 9: BGP Attributes: Local Preference and Communities

www.juniper.net
www.juniper.net

Routing
The operation of BGP route reflection;
How to configure a route reflector;
The operation of a BGP confederation;
How to configure confederations; and
Peering relationships in a confederation.
Chapter 112 Route Reflection and Confederations
www.juniper.net
Route Reflection Operation

www.juniper.net
Route Reflection and Confederations Chapter 113
IBGP Full Mesh

Unlike link-state routing protocols, internal BGP (IBGP) does not flood routing updates. Instead, IBGP
uses an explicit peering model that normally results in the exchange of routing information to peers
that are connected in a full mesh. The need for a full-mesh IBGP topology stems from the fact that
BGP uses the AS path attribute to provide loop detection, but IBGP speakers do not add the local AS
number in the updates they send to other IBGP speakers. Lacking AS number based loop detection,
IBGP speakers are normally precluded from readvertising routes to other IBGP speakers when the
route in question was learned from an IBGP speaker. This default IBGP behavior leads to the need for
a full mesh of IBGP peerings.
Requiring that all IBGP peers within an autonomous system (AS) be fully meshed has inherent
scalability problems. For example, every time a new router is added to the AS, each existing IBGP
router must have its configuration updated to include a peering statement for the router that has
been added. This process can become quite an issue when there are 100, 200, or even 1000
routers in an AS. In fact, with only 100 routers in a full IBGP mesh, each router is required to maintain
99 IBGP peering sessions, with the network having to support a total of 4,950 IBGP sessions! Surely
there has to be a better way.
Two Ways to Improve Scalability

The two primary ways to eliminate the need for a full BGP mesh are route reflection, as defined in
RFC 4456, and BGP confederations, as defined in RFC 3065. This chapter explores the configuration
and operation of both mechanisms.
www.juniper.net
IBGP Peers Can Readvertise Routes

BGP route reflection relaxes the restriction that an IBGP peer should not readvertise IBGP-learned
routes to other IBGP speakers. The routers allowed to override this default behavior are known as
route reflectors (RR).
Route Reflector Sends the Active Route

RRs only readvertise the active routes to their clients. You configure an RR by using the cluster
statement within an IBGP peer-group configuration. BGP considers each of the peers configured
within that peer group to be clients of the RR. The RR clients require no configuration changes; they
do not have any knowledge of the presence of the RRthey simply see the RR as an IBGP peer.
IBGP Attributes Not Changed

One of the primary drivers behind requiring the IBGP full mesh in the first place was loop prevention,
because the AS path attribute is not modified within an AS. Route reflection does not change that
behavior. In fact, none of the existing BGP attributes changes, by default, when BGP uses route
reflection in an AS. However, loop prevention is still a critical part of BGP, so new BGP attributes were
introduced to facilitate loop detection in a route reflection network.
www.juniper.net
New BGP Attributes

Two new BGP attributes are defined to support route reflection; these attributes are the cluster list
and the originator ID. An RR creates or modifies these attributes when it readvertises the routes to
both clients and non-clients. The route reflectors cluster ID is added to all routes that the RR
touches, meaning that both clients and non-clients receive the cluster list attribute. This attribute
contains a sequence of all cluster IDs that represent all RRs that have handled the route update.
www.juniper.net
New Cluster Attributes Prevent Loops

Without the new cluster attributes, a loop can be created:
www.juniper.net
1.
Client sends routes to RR1;
2.
RR1 sends routes to all clients and to RR2 and RR3;
3.
Because route reflection allows IBGP peers to send routes to other IBGP peers, RR2
sends the routes to RR3; and
4.
Because RR3 has no way of knowing the routes received from RR2 came from RR1,
RR3 sends them to RR1, forming a loop.
Cluster List
The cluster list attribute is analogous to the AS path attribute and is used to prevent loops. If an RR
receives a route with its own cluster ID in the cluster list, it drops the route. In addition, each router in
the network can use this attribute in the BGP path selection algorithm prior to using the peer IP
address attribute. BGP chooses the route with the shortest cluster list length. This process follows
the same theory as the AS path attribute.
The cluster ID is very similar to an AS number and should be unique within an individual AS. The
cluster ID is added to the cluster list attribute when a route is sent to clients and non-clients.
Originator ID
The originator ID attribute provides the router ID of the first router to advertise the route in the AS. It
also is used for loop prevention in the rare case where the cluster list does not prevent a loop.
www.juniper.net
Configuration and Routing Knowledge

www.juniper.net
Clients in a Peer Group

Within the Junos OS configuration syntax, all clients of an individual route reflector are placed within
a single peer group. This placement allows the route reflector to easily determine which peers are
clients of a particular cluster. No configuration changes are needed in the clients configuration.
Route Reflector Uses the cluster Command

Once the clients are placed into their respective peer groups, use the cluster command to
activate the route reflection process of the route reflector. The cluster command is used to assign
each cluster its cluster ID. This cluster ID is a 32-bit value that uniquely describes the cluster within
the BGP AS. If only a single route reflector exists in the cluster, the router ID of the route reflector is
often used as the cluster ID.
www.juniper.net
Route Reflector Uses the cluster Command (contd.)

The common practice is to configure the same cluster ID on each reflector when more than one
reflector exists within a given cluster. Assigning the same cluster ID has the advantages of reducing
the total number of routes stored, and it tends to make sense when cluster and route reflection
boundaries are graphically depicted. Some people maintain that it is better to assign unique cluster
IDs in these circumstances; the main advantage to unique cluster IDs is that the routes exchanged
between route reflectors in that cluster are now stored because the receiving route reflector does not
detect its own cluster ID. While this approach increases the number of routes being stored, it can
offer increased redundancy in certain situations. The redundancy benefits of assigning unique
cluster IDs are largely made moot by the practice of loopback peering for IBGP sessions, which is why
the assignment of a common cluster ID is generally considered the current best practice.
Clients Peer to Route Reflectors

The clients in the cluster must peer to the route reflector itself. The clients have no knowledge of the
cluster and see the reflector as a regular IBGP peer.
www.juniper.net
Basic Route Reflection

The slide shows an AS network using a typical route reflection topology.
BGP-speaking routers along the edge of the network all have a single peer configured in the form of
the route reflector for the local cluster.
The route reflectors are, in turn, fully meshed using standard IBGP peering procedures. The result is
that all routes received by any BGP router will eventually be seen by all other BGP routers in the AS.
It is a common best practice to have the logical route reflection topology follow the physical topology
of the network.
www.juniper.net
Route Propagation
The next series of slides shows the flow of routing information in a route reflection network using a
basic topology.
We begin with a client in the left-most cluster advertising the 10.10.10.0/24 route to the clusters
route reflector.
The slide details how the 10.10.10.0/24 route is readvertised to all other clients in the cluster as well
as to all non-client IBGP peers of the reflector. This process applies to all other routes the route
reflector receives from a client in its cluster.
This slide shows how the other route reflectors in the network readvertise all routes received from
IBGP peers (the other reflectors in this example) to all of their cluster clients.
www.juniper.net
Dual Route Reflectors in a Cluster

The slide shows a cluster containing two route reflectors. This type of cluster design is popular
because it avoids a single point of network failure. When a cluster has only a single route reflector,
the clients might become segmented from the network in the event of a failure of that RR. A design
that includes two RRs in each cluster ensures that the failure of a single router does not segment the
network.
Each of the client routers simply configure two IBGP peers and forward EBGP-learned routes to both
route reflectors. The route reflectors themselves can peer either within the cluster as clients of each
other or outside of the cluster as normal IBGP peers. Either way, routes from within the cluster are
dropped when advertised between the RRs because of cluster list routing loops.
Each of the route reflectors also establish IBGP peering sessions with the other RRs in the entire AS.
As previously mentioned, a debate exists as to whether each route reflector should be assigned the
same or unique cluster ID. In most cases, using unique cluster IDs is preferred. The drawback is that
using unique cluster IDs requires more BGP route state at the route reflectors. This generally does
not outweigh the advantage of maintaining connectivity.
www.juniper.net
Hierarchical Route Reflection

The slide shows an AS network using a more complex, hierarchical, route reflection topology.
Hierarchical route reflection occurs when the route reflectors for some clusters are themselves
clients in another route reflection cluster. Very often AS networks evolve to this type of setup when
the reflector full mesh shown on a previous slide becomes too large to manage. In this case, the
internal route reflector full mesh might evolve into a route reflection cluster.
www.juniper.net
Clients Can Peer with Other Clients

Clients within a cluster can peer with other clients in a full-mesh environment. This ability does not
change the operation or need for the route reflector. The reflector still sends routes from the clients
to the remainder of the IBGP network and forwards routes from the IBGP network into the cluster.
What the client full mesh does provide is the ability of clients to use other clients routes natively
when logical BGP connectivity exists between the clients.
In this situation, each of the clients receives two versions of the route. One version is from the other
client, and one version is from the route reflector. Because the extra copy of the route from the
reflector is not needed, you can disable the internal cluster readvertisements using the
no-client-reflect command. Once configured, the route reflector only forwards to the clients
routes which arrive from outside of the cluster.
www.juniper.net
Route Reflector Can Modify Attributes

The default operation of a route reflector is to not modify any BGP defaults. However, the Junos OS
does allow an applied routing policy to do just that. The reason for this action is the support of
customer networks. For reasons outside the scope of this course, some network administrators
engineer traffic flows by altering attribute values when the route reflector readvertises routes from a
non-client into the cluster. This alteration is supported through the use of routing policies applied to
the cluster's peer group.
Forwarding Paths Should Be Unaffected

Although a client learns of a route from the clusters route reflector, the route reflector itself does not
have to be in the forwarding path for packets sent from clients towards the route destination. In fact,
often times it is not.
In the example on the slide, the 172.16.2.2 cluster client advertises the 192.168.0.0/16 route to the
clusters RR with the BGP next hop set to its router ID. Because of sloppy next-hop-self policy on the
RR, the BGP next hop is overwritten with the router ID of the RR172.16.1.1. When client 172.16.3.3
receives and installs this route, suboptimal forwarding occurs as packets are sent through the RR
instead of directly to 172.16.2.2. This situation might occur when the route reflector also has EBGP
peering sessions established. Most network designs avoid this problem by placing their route
reflectors within the core of their networks.
www.juniper.net
Forwarding Paths Should Be Unaffected (contd.)

The solution to this problem is a selective next-hop-self policy on the RR that modifies the BGP next
hop for only EBGP-learned routes. This type of policy normally makes use of the from neighbor or
from interface match conditions, as shown here. In this example, the RR has an EBGP peering
session with the 172.16.0.1 address:
[edit policy-options policy-statement selective-nhs]
user@router# show
term only-EBGP-routes {
from {
protocol bgp;
neighbor 172.16.0.1;
}
then {
next-hop self;
}
}
www.juniper.net
BGP Confederations
www.juniper.net
Break Up the Global AS

A confederation takes a global AS and breaks it into smaller subautonomous systems. These sub-AS
networks are connected together to form the unified AS to which all other networks in the Internet
peer.
Within a Sub-AS
The confederation sub-AS networks act just like a real AS; they require a full mesh of IBGP
connectivity within themselves. Should the full mesh of the sub-AS grow too large, route reflection
might be used within a sub-AS to scale the network.
Each sub-AS must have a unique AS number defined, and most administrators use a private AS
number from the 64512 to 65535 range.
www.juniper.net
Between Each Sub-AS

An EBGP-like connection that is often referred to as confederation BGP (CBGP) is used to
interconnect the sub-AS networks. CBGP is a special type of EBGP; certain attributes, such as the
BGP next hop, are handled differently across CBGP sessions.
CBGP peers modify the AS path attribute to include the sub-AS numbers. This modification is
performed to provide loop prevention within only the confederation network. All other BGP attributes,
such as local preference and the BGP next hop, remain unchanged when sent across a CBGP link.
Because the router views connections between the sub-AS networks as being EBGP, some special
configuration might be warranted. The router expects to use the physical address of the CBGP for the
BGP session, but many administrators prefer to peer the CBGP routers using loopback addresses.
This is accomplished through the use of the multihop command.
www.juniper.net
AS Confederation Sequence
As a route is advertised over a CBGP link, BGP modifies the AS path attribute to include the sub-AS
number. BGP places this sub-AS number into an AS confederation sequence, as denoted by
parentheses, within the AS path attribute. The sequence is a new AS path segment attribute with a
type code of 3.
The sub-AS values are sequenced in the order in which the route has traversed the network, with the
primary purpose being loop prevention within the confederation network. The confederation
sequence is not used in the calculation of AS path length for the BGP active route selection
algorithm. For routers within a confederation network, the confederation sequence appears as a
single, internal BGP AS network.
AS Confederation Set
Should some routing aggregation occur within the confederation network, the granularity of the
confederation sequence might be lost. This process is very similar to conventional BGP route
aggregation.
In this situation, the AS confederation sequence becomes an AS confederation set and is denoted by
curly braces within the AS path output. The set is also a new AS path segment attribute with a type
code of 4.
The routers within the confederation view the AS confederation set in the same manner as a
sequence. That is, the set is still used for loop prevention even though the ordering of the sub-AS
numbers is no longer significant.
www.juniper.net
Global AS Appears Whole

The Internet views the confederation as a single autonomous system. The AS path received by other
autonomous systems contains only the globally assigned AS number. The AS path contains only this
number because all sub-AS numbers are removed from the AS path attribute as the route is
advertised to EBGP peers.
To operate a confederation network effectively, all BGP routers in the AS must know the globally
unique AS number as well as all the configured sub-AS numbers. This information is defined using
the confederation command within the routing-options stanza, as shown on the slide.
Confederation Information Removed

At the edge of the confederation network, the routers remove all confederation-related AS numbers,
both sequences and sets, from the AS path attribute of all routes prior to EBGP advertisement. This
removal allows the details of the confederation network to be hidden to all other networks in the
Internet.
Note that the remove-private command is not required to remove sub-AS numbers when you
operate a confederation network. This behavior is the default for a BGP confederation and is
controlled by the confederation command.
www.juniper.net
Confederation Peering
The slide shows an example of a BGP confederation network. The global AS of 201 is split up into five
sub-AS networks65000, 65001, 65002, 65003, and 65004. The sub-AS networks are connected
with EBGP-like connections (sometimes called CBGP). Because the CBGP links behave like EBGP,
there is no need for a full-mesh topology between each sub-AS. Therefore, you can provision CBGP
connections wherever it is logically, or physically, convenient.
Some of the sub-AS networks on the slide are using route reflection within the sub-AS to eliminate
the need for a full IBGP mesh. The combination of BGP confederations and route reflection
simultaneously allows for great flexibility in scaling your AS to hundreds or thousands of routers.
www.juniper.net
Peering Session Configurations

The configuration example on the left side of the slide represents Router 3 in sub-AS 65001. A full
mesh of IBGP peering sessions exist within the sub-AS, as seen in peer group sub-AS-65001. The
remaining peer groups on that router represent CBGP connections to other sub-AS networks in the
confederation. Each group uses a connection type of external, uses the multihop command,
and configures both a peer and local AS value.
The configuration example on the right side of the slide represents Router 1 in sub-AS 65003. This
sub-AS uses route reflection to replace the IBGP full mesh, and Router 1 is the route reflector for the
cluster. This configuration is seen in peer group sub-AS-65003 where the cluster command is
configured. The other peer group on the router represents the CBGP peering connection to
sub-AS 65000.
www.juniper.net
Operation of BGP route reflection;
How to configure a route reflector;
The operation of a BGP confederation;
How to configure BGP confederations; and
Peering relationships in a BGP confederations.
www.juniper.net
Review Questions
1.
2.
3.
4.
5.
6.
www.juniper.net
Lab 10: Scaling BGP

The slide shows the objectives for the lab.
www.juniper.net

Routing
The causes for route instability;
The effect of damping on BGP routing;
The default behavior of damping on links;
How to control damping using routing policy; and
How to view damped routes using command-line interface (CLI) commands.
Chapter 122 BGP Route Damping
www.juniper.net
Route Flap and Damping Overview

www.juniper.net
BGP Route Damping Chapter 123
Routing Is Dynamic
In any real network, routes can appear and disappear rapidly if a link fails and restores itself
repeatedly in a short period of time. This is because any routes (and there could be thousands) that
use the failed interface as a next hop must respond to the failure, and the change in next hop must
propagate to all other routers on the network. This rapid changing of routing next hops is called route
flapping or just flapping as the link flaps up and down.
Update/Withdrawn Pairs
Flapping results in a rapid sequence of BGP update or withdrawn messages. Recall that BGP routers
must maintain separate memory tables for inbound and outbound traffic on a per-peer basis. In
addition, the BGP routing protocol propagates information on an as-needed basis. These two factors
make BGP unstable in the face of a flapping link.
Every BGP router that receives one of these update or withdrawn messages must send this
information on to all its BGP router peers. Much like the link-state IGPs of OSPF and IS-IS, BGP must
also recalculate its routing tables and databases every time a new update is received. If the new
information alters the path selection process, a new route is chosen for the RIB-LOCAL, and the new
route must be sent downstream to all BGP peers.
www.juniper.net
Update/Withdrawn Pairs (contd.)

The effect of route flapping quickly cascades and affects router performance. One intermittently
failing link can adversely affect a whole network. If this type of update or withdrawal occurs on a very
frequent basis, valuable resources in the router, such as processing power normally used to forward
packets, and bandwidth now needed for routing updates, are consumed.
www.juniper.net
Bad Links
Routes in a network can flap for any number of reasons. Quite possibly, the most frequent reason for
a link flap is because of faulty circuit that is on the brink of outright failure. Any link that rapidly
changes from seemingly operational to failing is a potential source of route flapping.
Unstable IGPs
Route flapping is not totally a BGP phenomenon. IGPs that are unstable because of faulty links can
affect BGP when IGP routes are injected into BGP for advertising. BGP stability is always desirable
and can be enhanced with careful use of static definitions and aggregates instead of injecting raw
IGP routes into BGP.
Bad Routing Policy

Human error can cause route flaps as well. An incorrectly configured routing policy, causing routes to
be first rejected, then accepted because of the change on the route, can cause flapping.
www.juniper.net
Congested Links
Link congestion can cause route flaps if the overloaded links drop the BGP sessions that keep the
BGP routes fresh.
Flapping and History

In the past, sometimes the routers themselves contributed to the flapping problem. Older routers
were filled with software bugs (mostly after an upgrade to a new release), had insufficient power (a
busy CPU in a software-based router would drop BGP sessions), and often had insufficient memory
(routing tables must be kept in memory). Sometimes, just adding equipment for routine network
upgrades and maintenance caused route flaps.
www.juniper.net
Route Damping
Because route flapping can be so harmful to BGP, the protocol was extended to support route
damping. RFC 2439, BGP Route Flap Damping (November 1998), defines route damping.
Sometimes the term dampening is seen and used.
No Damping for IBGP

There is a difference between how damping is applied in BGP for internal and external peers. IBGP
sessions ignore damping and flap as they please. There is a very good reason for this IBGP behavior.
IBGP sessions usually peer to loopbacks, so IGP routes must be able to come and go so that IBGP
sessions always have a way to reach the loopback. Recall that BGP has no reachability information of
its own and relies on the IGP to resolve next hops.
EBGP Only
Route damping is only applied to routes received from an EBGP peer. EBGP sessions can carry
information about thousands of routes. Each EBGP session must update or withdraw these routes as
required. Route damping seeks to reward route stabilities while penalizing route flapping. Once
damping is enabled, the router begins to maintain a database of instability. If an EBGP-received
route experiences enough flaps, the local BGP process ignores information about that route. This
reaction results in not including this information in the route selection process and not advertising
route changes to downstream BGP peers. Note that some ISPs no longer use damping.
www.juniper.net
Route Damping Use by ISPs

The slide shows an example of when BGP route damping is useful.
A customer of AS 1 is connected to the AS by a link running EBGP. The customer advertises three
routes: 172.31.0.0/20, 172.31.64.0/20, and 172.31.128.0/20.
AS 1 provides transit service for this customer to the Internet, so the three routes are readvertised
within AS 1 and further to the Internet.
However, look what happens when the 172.31.64.0/20 route starts to experience stability problems,
causing multiple update and withdraw messages to be sent to AS 1 (up/down/up/down, and so on).
Without route damping enabled, this flap action causes the router in AS 1 to send new update
messages to other routers in AS 1. These IBGP peers then also send new update messages to their
Internet peers.
Enabling route damping can halt this wave of instability at the edge of AS 1. Once enabled, the edge
router in AS 1 starts maintaining statistics for the routes received from the customer. Once the
172.31.64.0/20 route is deemed unstable, the AS 1 router stops generating new update messages
to its IBGP peers. The IBGP peers, in turn, also have no need to send update messages to the
Internet. This makes the Internet, as a whole, more stable.
www.juniper.net
Route Damping Parameters

www.juniper.net
Figure of Merit Is a Number

The point at which a route is deemed to be too unstable is calculated by the damping figure of merit.
It might seem more like a figure of demerit but that is the term the RFC uses. In this context, the term
figure means a number, not a picture. The figure of merit is a type of point value given to a route. The
value becomes a penalty if the figure of merit exceeds some predetermined value (that is, the route
is suppressed). It is often said that damping puts a route into a penalty box for a given period of time.
Default Value = 0
When a previously unknown (that is, new) route arrives at a BGP router that has damping enabled,
the new route is assigned a figure of merit value of 0.
www.juniper.net
Event Point Values

Should the route experience any instability, the figure of merit is incremented according to the
following:
As the EBGP peer withdraws the route, the figure of merit is increased by a value of
1000;
As the EBGP peer readvertises the route, the figure of merit is increased by a value of
1000; and
As attributes for the route change through new update messages from the EBGP peer,
the figure of merit is increased by a value of 500.
Point Reduction
The points given to a route decay (that is, reduce in value) at a certain rate, known as the
half-life. As long as points decay faster than they accumulate, the route is not suppressed.
The Cutoff Threshold

Should the figure of merit value increase beyond a configured cutoff (suppress) threshold, the
route is considered unusable, and new information about the route from the EBGP peer is ignored.
The suppress value is configurable, but it must be less than or equal to the merit ceiling value
explained further on this page.
The Reuse Threshold

The route can once again be considered usable after the figure of merit decreases below a
configured threshold. The figure of merit is decreased on a time schedule you set. Should the figure
of merit not decrease below the bottom threshold in a configured amount of time, the route can
automatically be usable again (reuse).
Maximum Suppress Time

The configurable max-suppress parameter establishes the maximum time that a route can be
suppressed. Also, the figure of merit can only increase to the maximum value, called the merit
ceiling. The symbol used for the merit ceiling is c. This maximum value is calculated from a
combination of the components listed above and is determined by the following formula:
c r e(t/)(ln 2)
where r is the figure of merit reuse threshold, t is the maximum suppression (hold-down) time in
minutes, and is the half-life in minutes.
www.juniper.net
Cutoff Threshold
The figure-of-merit value interacts with the damping parameters. The slide lists these parameters.
The suppress variable is the configured threshold where a BGP route is considered unstable and is
not used. This variable represents the value of the penalty that establishes the point at which
damping is initiated. When this value is reached, the route is cutoff (suppressed). The default value
of suppress is 3000. Possible values range from 120000. If changed, this value must be less
than or equal to the merit ceiling c, or damping never occurs.
Reuse Threshold
The reuse variable is the configured threshold where a BGP route is considered usable once again.
This variable is the value to which the penalty must decay before the router considers the route in its
path selection. The default value of the reuse is 750. Possible values range from 120000.
Decay Half-Life
The half-life variable is the rate at which the figure of merit is decreased to half its value once
the value is larger than 0. The default value of the half-life is 15 minutes. Possible values range
from 145 minutes.
www.juniper.net
Maximum Hold-Down Time

The max-suppress variable is the configured maximum amount of time that a BGP route can be
deemed unusable. This variable is the longest time that the route can be suppressed until the route
is given another chance to behave. The default value of the max-suppress is 60 minutes. Possible
values range from 1720 minutes. At the end of the max-suppress interval, all is forgiven and the
route becomes active again.
www.juniper.net
Sample Figure of Merit in Action

The slide shows a graphic representation of the figure of merit in use for a BGP route. The default
values for suppress (3000), reuse (750), and half-life (15 minutes) are used. Note that an
exponential decay occurs on the figure of merit, and a fixed ceiling exists on the figure-of-merit value
(the merit ceiling).
After receiving a new BGP route, the figure of merit is 0 for some period of time. As soon as the route
is withdrawn (or the link is down), the figure of merit increments to 1000. As long as the route stays
down, the figure of merit decays somewhat. As the route is readvertised, the figure of merit is
incremented by another 1000. Again, the figure of merit starts to decay. Now the route is withdrawn
a second time, and again, the figure of merit is increased. Now, when the route is readvertised, the
figure of merit is increased by another 1000. This time, because not enough time has elapsed
between these events in this example, the route is over the suppress limit of 3000 and is
considered unusable. In short order, the route is withdrawn and readvertised, yet again. Each time,
the figure of merit increases 1000 for each action. Notice that the route is still damped and
considered unusable, but the figure of merit still increases and decreases, even while the route is
suppressed.
www.juniper.net
Sample Figure of Merit in Action (contd.)

Whenever the figure of merit is greater than 0, the value is constantly and consistently decayed
using the configured half-life value. The half-life is always configured in increments of
minutes. The purpose of the half-life is to decay exponentially the figure of merit such that the
value from any point in time is reduced by half at the end of the configured half-life (this half-life
behavior is the essence of an exponential decay). The decay is made an exponential process so that
routes can be reused as they gradually cross the reuse threshold and not in large groups as a timer
expires. This has the effect of not overloading BGP routers with large amounts of updates at once,
causing further route damping.
www.juniper.net
Configuring and Monitoring Route Damping

www.juniper.net
Damping Parameters in a Routing Policy

Once damping is enabled within the BGP portion of the Junos OS configuration, the default values
introduced on previous slides are used for figure-of-merit calculations.
To alter these default values, you can create and define a damping profile within the [edit
policy-options] configuration hierarchy.
Applied as Policy Action

Much like the AS-path and community attributes, you name and define a damping profile first. Then
you can use it within a policy as an action. The slide shows the five damping parameters.
The presence of the disable keyword deserves a few words of explanation. You can use the
keyword disable within a damping profile to not have the figure of merit be calculated for certain
routes. This is often useful to exempt certain routes that should never be damped and made
unusable. One good example of these types of routes are the root DNS servers in the Internet. If
these servers become unreachable because of damping, the ISP and its customers experience DNS
lookup failures. For example, DNS routes could have a damping profile of no-damping defined that
contains a single statement: disable.
www.juniper.net
Example of Damping Use: Part 1

The slide shows a fairly sophisticated example of route damping in action.
On the slide, AS 1 wants to enable damping for all its EBGP peers, based on the following
administrative decisions:
AS 1 wants to operate the default damping values for routes from AS 100;
AS 1 does not want to damp any routes from its customer; and
AS 1 wants to damp all routes aggressively from the Internet except for certain prefixes.
The next few slides in this sequence examine how you can implement these damping policies.
The next slide outlines the routing policies you can use to accomplish these goals. We detail the
application of these routing policies on a later slide.
www.juniper.net

This slide shows all the damping profiles and policies to be used in AS 1 in the damping example.
The profile do-not-damp has a variable of disable defined. The profile aggressive-damp
has defined four variables as follows:
suppress is 1500;
reuse is 200;
half-life is 30; and
max-suppress is 120.
A policy named customer-inbound is defined with no from statement, so all possible routes
match the policy. The policy has an action of damping do-not-damp. This action sets the profile of
do-not-damp to all routes.
A policy named internet-inbound is defined with two terms. The let-some-through term
has several route-filter statements with actions defined of damping do-not-damp. This term
further lists an action of then accept. A second term of damp-all-others has no from
statement defined, so all routes are subjected to the damping aggressive-damp action.
Warning: This version of the internet-inbound policy contains a logic flaw and does not work.
Please do not use this policy in your network. A corrected version is presented on a later slide. Can
you spot the flaw?
www.juniper.net

The routers in AS 1 are next updated to apply the policies we created on the previous slide.
Router R1 defines damping in BGP and an import policy of internet-inbound. This
configuration enables damping on the router and applies profile parameters as per the policy. As
mentioned previously, the currently configured policy contains a logic flaw that causes it not to meet
the administrative requirements.
Router R2 simply defines damping within its BGP configuration. This configuration both enables
damping and operates with the default parameters on routes from AS 100. No policy is needed on
this router.
Router R3 defines damping within BGP and an import policy of customer-inbound. This
configuration enables damping on the router and applies profile parameters as per the policy.
www.juniper.net

This slide shows a corrected version of the internet-inbound policy. As mentioned before,
previous versions contained a logic flaw. The flaw is a result of the way that we applied immediate
actions to a route filter.
The issue is the do-not-damp action defined for the route-filter statements. When a
candidate route that matches one of the filters appears, the action of damping do-not-damp is
taken. Because we defined this action within the route-filter statement itself (it is an
immediate action), any further actions on the route specified within a then statement are skipped. In
this case, the then accept is skipped within the let-some-through term. But the
route-filter statements do not also define a terminating action (accept or reject). Thus,
the damping profile is applied, but the route is passed to the next term in the policy for further
evaluation. When the route enters the damp-all-others term, the route matches the term
because we defined no from statement. The route is then applied the damping profile of
aggressive-damp. This causes the specified exempt routes to be damped at the aggressive rate!
This violates the administrative policies of the AS.
To correct the policy, we must remove the damping do-not-damp actions from the individual
route-filter statements and instead place them within the then portion of the term. After
making this change, the exempt routes match the let-some-through term, have the correct
damping profile applied, and are accepted.
www.juniper.net
Damping History
The slide shows the output from the show route damping history command.
Any routes displayed by this command were withdrawn from the router. However, the router retains a
record of these routes should they be readvertised to the local router. Some notable details in the
display include the following:
www.juniper.net
The route is currently hidden. We see this in both the State: <Hidden Ext> field as
well as the Preference: /-101 field. Notice that no Junos OS protocol preference
value is defined.
There is a field (Merit) for the current figure-of-merit value. The two values that follow
list the value after the last BGP update (or withdrawal), and the current value after
experiencing some decay. For this route, the values are Merit: 2777/2454. Thus,
the value at the last update/withdrawal was 2777 (note that this value need not
necessarily exceed the default suppress threshold of 3000), and the current value is
2454.
The default parameters are used (Default damping parameters used). If this
route were evaluated by a policy with a damping action, the new damping profile name
would appear in the output.
Routes with Non-0 Figures of Merit

The slide shows the output from the show route damping decayed command.
Any routes displayed by this command were advertised to the router and are currently usable routes,
but these routes have a figure of merit greater than 0. Some things to note in the display are:
The route is currently active. We see this both by the asterisk (*) in the output as well as
the State: <Active Ext> field.
There is a field (Merit) for the current figure-of-merit value. The two values list the
value after the last update (or withdrawal) and the current value after experiencing
some decay. For this route, the values are Merit: 2000/1954.
The default parameters are used (Default damping parameters used). If a

policy with a damping action evaluated this route, the new damping profile name would
appear in the output.
www.juniper.net
Damped Routes
The slide shows the output from the show route damping suppressed command.
Any routes displayed by this command were advertised to the router, but these routes have a figure
of merit that is currently above the suppress threshold, and the route is unusable.
Manual Clearing
The route remains in this state until the figure of merit crosses below the reuse threshold. A route
can have the figure of merit reduced to 0 administratively by using the clear bgp damping
command.
On the slide, the route 200.200.200.0/24 is currently suppressed and hidden. After we issue the
clear bgp damping command, the route is no longer hidden.
www.juniper.net
The causes of route instability;
The effect that route damping has on BGP routing;
The default behavior of damping on links;
Controlling damping using the routing policy framework; and
Viewing damped routes using CLI commands.
www.juniper.net
Review Questions
1.
2.
3.
4.
5.
www.juniper.net
Lab 11: BGP Route Damping

www.juniper.net
Appendix A: Acronym List

ABR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . area border router
ARP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Resolution Protocol
AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . autonomous system
ASBR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . autonomous system boundary router
BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Border Gateway Protocol
BGP4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Border Gateway Protocol version 4
CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .command-line interface
CLNP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connectionless Network Protocol
CLNS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connectionless Network Service
CSNP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . complete sequence number PDU
DIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . designated intermediate system
DR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .designated router
EGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . exterior gateway protocol
ES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . end system
ES-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . End SystemtoIntermediate System
GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .graphical user interface
IAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Advisory Board
IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Internet Assigned Numbers Authority
IBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . internal BGP
ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Control Message Protocol
IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . interior gateway protocol
IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .IP version 4
IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .IP version 6
IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intermediate System
ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . International Organization for Standardization
ISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet service provider
JNCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Juniper Networks Certification Program
LSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . link-state advertisement
LSDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . link-state database
LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .link-state PDU
MD5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Message Digest 5
MED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . multiple exit discriminator
MOSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Multicast Open Shortest Path First
NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . network entity title
NLPID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . network layer protocol identifier
NLRI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . network layer reachability information
NSSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . not-so-stubby area
OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Systems Interconnection
PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .protocol data unit
PFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Packet Forwarding Engine
PSNP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . partial sequence number PDU
RIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Information Base
RID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . router ID
rpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . routing protocol daemon
SNPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .subnetwork point of attachment
SPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .shortest path first
TED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . traffic engineering database
TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . type/length/value
ToS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . type of service
TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . time-to-live
www.juniper.net
Acronym List Appendix A1
Appendix A2 Acronym List
www.juniper.net
Appendix B: Answer Key

Chapter 1:
Course Introduction
This chapter contains no review questions.
Chapter 2:
OSPF
1.
LSA Type 9 supports graceful restart.
2.
The metric or cost of a routers links can be automatically altered with the reference-bandwidth
command.
3.
The different forms of OSPF authentication include none, simple, and MD5.
Chapter 3:
OSPF Areas
1.
The ABR does not forward Type 4 and Type 5 LSAs into a stub area or NSSA. Type 3 LSAs are also not
forwarded in an OSPF NSSA with no summaries.
2.
You must configure all routers that are in the stub area or NSSA.
3.
The ABR of the stub area can optionally inject a 0.0.0.0/0 default route into the stub area or NSSA.
4.
The backbone area is affected by the area-range command.
Chapter 4:
OSPF Case Studies and Solutions

1.
Although technically you do not need a backbone area, functionally you need one because of the loop
prevention mechanisms in OSPF.
2.
Virtual links would be deployed if two companies were merging their networks together and physical link
connectivity was not an option (for example, because of cost or time constraints).
3.
If the source route has a lower preference, usually no issues are present. If a source route has a higher
preference, suboptimal routing or loops can occur.
Chapter 5:
IS-IS
1.
A PDU is a protocol data unit. It is used to send information about the IS-IS configuration between network
devices.
www.juniper.net
Answer Key Appendix B1
2.
The segments are called type/length/value (TLVs). They describe the originating router.
3.
Because IS-IS is deterministic, the added IS will assume the role of the DIS immediately and flood out new
PDUs to all other ISs on that segment.
4.
Set family iso and net on the physical and loopback interfaces. On the loopback interface, add an IP
address and an ISO address. Ensure that the Area Address portion of the NET is the same. Under
[protocols isis], disable Level 2.
Chapter 6:
Advanced IS-IS Operations and Configuration Options

1.
The maximum default link metric is 63. By default, the Junos OS supports the sending and receiving of
wide metrics. To configure IS-IS to generate only the new pair of TLVs and thus to allow the wider range of
metric values, include the wide-metrics-only statement.
2.
None, simple, and MD5 are the three forms of IS-IS authentication.
3.
Import polices are not allowed for IS-IS, because they could lead to inconsistencies in the LSDB. The
default export policy for IS-IS is to reject everything. IS-IS floods LSPs to announce local routes and any
routes learned by the protocol. Exporting can be used only to announce information from other protocols.
Chapter 7:
Multilevel IS-IS Networks

1.
Areas are segmented in an IS-IS L1/L2 network using L1/L2 ABRs.
2.
An IS-IS L1/L2 network is similar to an OSPF NSSA with the no-summaries and default-metric
options configured.
3.
Route leaking is performed on the L1/L2 ABR. A routing policy is written matching the Level 2 routes to be
leaked. This policy is then applied at the [edit protocols isis] hierarchy.
Summarization is performed on the L1/L2 ABR. An aggregate route encompassing the desired more
specific routes must be defined. Then a routing policy is created matching the aggregate with the to
level 2 and then accept actions. The policy should include a term to reject more specific routes. The
policy is applied at the [edit protocols isis] hierarchy.
Chapter 8:
BGP
1.
Using loopback addresses for peering sessions between IBGP neighbors maintains reachability even when
the physical topology changes as long as a viable path exists.
2.
EBGP-learned routes are advertised to both EBGP and IBGP peers. IBGP-learned routes are advertised to
EBGP peers. However, IBGP-learned routes are not advertised to other IBGP peers to prevent routing
loops.
Appendix B2 Answer Key
www.juniper.net
3.
With Junos OS, all new BGP routes have an origin code of I=Internal.
When you configure multipath on a BGP router, the route selection algorithm ignores both the router ID
and the peer ID selection criteria.
Five approaches can solve the BGP next hop issue: Next-hop self; IGP passive interfaces; Export direct
routes into IGP; Static routes; and IGP adjacency formed on inter-AS links to EBGP peers.
Chapter 9:
BGP Attributes and PolicyPart 1

1.
An import policy operates between the RIB-IN and the RIB-LOCAL. An export policy operates between the
RIB-LOCAL and the RIB-OUT.
2.
The Junos OS sees all possible routes to be injected into BGP as internal routes and sets the origin code
as I=Internal.
3.
Different ASs can set the MED values differently. A good MED value from one AS may be a bad value from
another AS.
The purpose of prepending the AS PATH is to make the route advertisement look undesirable.

1.
Local preference is a BGP attribute that influences traffic flow. Route preference is local to an individual
router and assists the routing table in choosing the active route.
2.
Local preference influences outbound traffic flow.
3.
The well-known communities are: No-export; No-advertise; and No-export-subconfed.
The add community action adds the specified community string to the existing community attribute. The
set community action deletes any existing communities and adds the specified community string.

1.
Cluster ID and Cluster List support route reflection.
2.
The cluster statement is configured only on the route reflector.
3.
No-client-reflect can be used to stop excess advertisements.
An RR readvertises routes received from clients and non-clients, adding the cluster ID and cluster list
attributes.
Loops are prevented by examining the confederation AS sequence or AS set.
4.
Routers in a sub-AS run IBGP. Routers across a confederation boundary run CBGP. Routers external to the
confederations run EBGP.
www.juniper.net
Answer Key Appendix B3

1.
IBGP sessions usually peer to loopbacks, so IGP routes must be able to come and go so that IBGP sessions
always have a way to reach the loopback.
2.
The half-life is the rate at which the figure of merit is decreased to half its value once the value is larger
than 0. The default value of the half-life is 15 minutes.
3.
The max-suppress parameter establishes the maximum time that a route can be suppressed. The default
value is 60 minutes.
If the suppress threshold is set higher than the merit ceiling no damping will occur.
The command shows any routes that were advertised to the router and are currently usable routes, but
have a figure of merit greater than 0.
Appendix B4 Answer Key
www.juniper.net

Advanced Junos Routing

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Advanced Junos Routing

Hochgeladen von

Copyright:

Verfügbare Formate

Advanced Junos Service Provider

Worldwide Education Services

This document is produced by Juniper Networks, Inc.

Chapter 3: OSPF Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

Chapter 4: OSPF Case Studies and Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

Chapter 5: IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

Chapter 6: Advanced IS-IS Operations and Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . .6-1

Chapter 7: Multilevel IS-IS Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1

Chapter 8: BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Chapter 9: BGP Attributes and PolicyPart 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Chapter 10: BGP Attributes and PolicyPart 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Chapter 11: Route Reflection and Confederations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Chapter 12: BGP Route Damping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1

Appendix A: Acronym List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

Describe the various OSPF link-state advertisement (LSA) types.

Explain the flooding of LSAs in an OSPF network.

Describe the shortest-path-first (SPF) algorithm.

List key differences between OSPFv2 and OSPFv3.

Describe OSPF area types and operations.

Configure various OSPF area types.

Summarize and restrict routes.

Explain the concepts and operation of IS-IS.

Describe various IS-IS link-state protocol data unit (PDU) types.

List IS-IS adjacency rules and troubleshoot common adjacency issues.

Configure and monitor IS-IS.

Display and interpret the link-state database (LSDB).

Perform advanced IS-IS configuration options.

Implement IS-IS routing policy.

Explain the default operation in multiarea IS-IS.

Describe IS-IS address summarization methods.

Configure and monitor a multiarea IS-IS network.

Describe basic BGP operation.

List common BGP attributes.

Explain the route selection process for BGP.

Describe how to alter the route selection process.

Configure some advanced options for BGP peers.

Manipulate BGP attributes using routing policy.

Explain the causes for route instability.

Describe the effect of damping on BGP routing.

Explain the default behavior of damping on links.

Describe the operation of BGP route reflection.

Configure a route reflector.

Describe the operation of a BGP confederation.

Describe peering relationships in a confederation.

Control damping using routing policy.

View damped routes using command-line interface (CLI) commands.

Multilevel IS-IS Networks

Course Agenda vii

Most of what you read in the Lab Guide

Exiting configuration mode

GUI text elements:

Select File > Open, and then click

Input Text Versus Output Text

View configuration history by clicking

Text that you must enter.

lab@San_Jose> show route

Defined and Undefined Syntax Variables

Text where variable value is already

Text where the variables value is

Type set policy policy-name.

viii Document Conventions

Click my-peers in the dialog.

About This Publication

Juniper Networks Support