junipe

NETWORKS

Advanced Junos Service Provider

Routing

STUDENT GUIDE Revision TO.a

Education Services Courseware

Advanced Junos Service Provider
Routing
lO.a

Student Guide

juniper
-
/ NETWORKS
5

i
Worldwide Education Services

1194 North Mathilda Avenue

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net

Course Number: EDU-JUN-AJSPR :

; Isi.niJ. .
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 Semce Provider Routing Student Guide, Revision lO.a
Copyright © 2011 Juniper Networks, inc. All rights reserved,
Printed in USA.

Revision History:
Revision lO.a - March 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.3R1.9. 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 iicense 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-11
Stub Area Configuration 3-18
NSSA Operation 3-21
NSSA Configuration 3-26
Route Summarization 3-30
Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization 3-37

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

 Chapters: 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 Policy-Part 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-74

Chapter 10: BGP Attributes and Policy-Part 2 10-1

Local Preference 10-3
Communities 10-14
Lab 9: BGP Attributes: Local Preference and Communities 10-50

Chapter 11: BGP Route Damping 11-1

Route Flap and Damping Overview 11-3
Route Damping Parameters 11-10
Configuring and Monitoring Route Damping 11-17
Lab 10: BGP Route Damping 11-28

Chapter 12: Route Reflection and Confederations 12-1

Route Reflection Operation 12-3
Configuration and Routing Knowledge 12-9
BGP Confederations 12-19
Lab 11: Scaling BGP 12-28

Appendix A: Acronym List A-l

Appendix B: Answer Key B-l

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 Junes operating system and in monitoring device and protocol
operations. This course is based on the Junos OS Release 10.3R1.9.

Objectives
After successfully completing this course, you should be able to:

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 OSPFvS.

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 (LSP) 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.

Control damping using routing policy.

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

www.juniper.net Course Overview . v

 .
Describe the operation of BGP route refiection.
.
Configure a route refiector.
.
Describe the operation of a BGP confederation.

Configure confederations.

Describe peering relationships in a confederation.

Intended Audience

This course benefits Individuals responsible for Implementing, monitoring, and troubleshooting
Layer 3 components of a service provider's network.

Course Level

Advanced Junos Service Provider Routing (AJSPR) 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.

vl . Course Overview www.Junlper.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
Chapters: 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 Policy-Part 1

Lab 8: BGP Attributes: Next-Hop, Origin, MED, and AS Path

Day 4
Chapter 10: BGP Attributes and Policy-Part 2
Lab 9: BGP Attributes: Local Preference and Communities

Chapter 11: BGP Route Damping

Lab 10: BGP Route Damping

Chapter 12: Route Reflection and Confederations

Lab 11: Scaling BGP

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

commit complete
.
Screen captures
. Noncommand-related Exiting configuration mode
syntax

GUI text elements:

Select File > Open, and then click
.
Menu names Configuration.conf in the
Filename text box.
.
Text field entry

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 interf ace: fxpO,

n t t ~r~ Enabled
Normal GUI
View configuration history by clickini
Configuration > History.

CLI input Text that you must enter. lab@San _

jose> show route

GDI input Select File > Save, and type

conf ig, ini in the Filename field.

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 policy my-peers

GUI Variable assigned. Click my~peers in the dialog.

CLI Undefined Text where the variable's value is Type set policy policy-name.
the user's discretion or text where
ping IQ.O.x.y
the variable's value as shown in
GOT Undefined the lab guide might differ from the Select File > Save, and type
value the user must input filename in the Filename field.
according to the lab topology.

viii . Document Conventions 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 AJSPR Student Guide was developed and tested using software Release 10.3R1.9. 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 [email protected].
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

Additional Information www.juniper.net
juniperNETWORKS

Advanced Junos Service Provider

Routing

Chapter 1: Course Introduction

Add CourseTitle Here with CourseTitle Variable

After successfully completing this chapter, you will be

able to:
. Get to know one another
.
Identify the objectives, prerequisites, facilities, and
materials used during this course
.
Identify additional Education Services courses at
Juniper Networks
.
Describe the Juniper Networks Certification Program

{ |j| 01
: 'A urldwicie lilucalion Ser.ices

This Chapter Discusses:

Objectives and course content information;
.
Additionai Juniper Networks, Inc. courses; and
.
The Juniper Networks Certification Program.

Chapter 1-2 . Course Introduction www.Juniper.net

 Add CourseTitle Here with CourseTitle Variable

Introductions

Before we get started...

.
What is your name?
.
Where do you work?
.
What is your primary role in your
organization?
.
What kind of network experience
do you have?
*
Are you certified on Juniper Networks?
.
What is the most important thing for
you to learn in this training session?

Introductions

The slide asks several questions for you to answer during class introductions.

www.juniper.net Course Introduction . Chapter 1-3

Add CourseTitle Here with CourseTitle Variable

Contents:
.
Chapter 1: Course Introduction
.
Chapter 2: OSPF
.
Chapters: OSPF Areas
.
Chapter 4: OSPF Case Studies and Solutions
.
Chapters: IS-IS
.
Chapter 6: Advanced IS-IS Operations and Configuration Options
.
Chapter?: Multilevel IS-IS Networks
.
Chapters: BGP
.
Chapter 9: BGP Attributes and Policy-Part One
.
Chapter 10: BGP Attributes and Policy-Part Two
.
Chapter 11: BGP Route Damping
.
Chapter 12: Route Reflection and Confederations

JUniPSf WorklwitleEtlucationSetvioes

Course Contents

The slide lists the topics we discuss in this course.

Chapter 1-4 . Course Introduction www.juniper.net

 Add CourseTitle Here with CourseTitle Variable

Prerequisites

The prerequisites for this course are the following:

.
Intermediate network knowledge
.
Understanding of the OSI model and TCP/IP
.
Completion of the following Juniper Networks courses:
.
Introduction to the Junos Operating System (1JOS)
.
Junos Routing Essentials (JRE)
.
Junos Intermediate Routing(i\R)

Prerequisites
The slide lists the prerequisites for this course.

www.juniper.net Course Introduction . Chapter 1-5

Add CourseTitle Here with CourseTitle Variable

The basics:
.
Sign-in sheet
. Schedule
. Class times

. Breaks
. Lunch

. Break and restroom facilities

.
Fire and safety procedures
. Communications
.
Telephonesand wireless devices
.
Internet access

V. urUlvmlu (iJucatrun Ser.ir;RS

General Course Administration

The slide documents general aspects of classroom administration.

Chapter 1-6 . Course Introduction www.juniper.net

 Add CourseTitle Here with CourseTitle Variable

Available materials for classroom-based

and instructor-led online classes:
. Lecture material
.
Lab guide
.
Lab equipment
Self-paced online courses also available
.
http://www.juniper.net/training/technicaLeducation/

lillillllfl
,

Training and Study Materials

The slide describes Education Services materials that are available for reference both in the
classroom and online.

www.juniper.net Course Introduction . Chapter 1-7

Add CourseTitle Here with CourseTitle Variable

itial Resources

For those who want more:

.
Juniper Networks Technical Assistance Center (JTAC)
.
http://www.j u n i per. n et/su p po rt/ req u esti n g-s u p po it. htm I
.
Juniper Networks books r~F=
.
http://www.j u n i per. net/tra i n i ng/j n books/
. Hardware and software technical
documentation
.
Online: http://www.juniper.net/techpubs/
.
Imagefiles for offline viewing:
http://www.juniper.net/techpubs/resources/cdrom.html
. Certification resources
.
http://www.juniper.net/training/certlficatlon/resources.html

Additional Resources

The slide provides links to additional resources available to assist you in the installation,
configuration, and operation of Juniper Networks products.

Chapter 1-8 . Course Introduction www.juniper.net

 Add CourseTitle Here with CourseTitle Variable

Satisfaction

Ell
Class
Feedback
m

m imii
PS

13

To receive your certificate, you must complete the

survey
.
Either you will receive a survey to complete at the end of
class, or we will e-mail it to you within two weeks
.
Completed surveys help us serve you better!

Mr

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 Course Introduction . Chapter 1-9

Add CourseTitle Here with CourseTitle Variable

Curriculum

Formats:
. Classroom-based instructor-led technical courses
. Online instructor-led technical courses
.
Hardware installation eLearning courses as well as technical
eLearning courses
Complete list of courses:
.
http://www.juniper.nel/training/technical education/ _

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/.
_

Chapter 1-10 . Course Introduction www.juniper.net

 Add CourseTitle Here with CourseTitle Variable

Why earn a Juniper Networks certification?

.
Juniper Networks certification makes you stand out
Unleash your creativity across the
entire network jumper CERTIFICATION
PROGRAM

Deliver your vision, design, and

architecture
.
Sets you apart from your peers
Capitalize on the promise of the
New Network
.
Develop and deploy the services
you need
.
Lead the way and increase your value
Unique benefits for certified individuals

Sf WorWwitle Ettucatlon Services

Juniper Networks Certification Program

A Juniper Networks certification is the benchmark of skills and competence on Juniper Networks
technologies.

www.juniper.net Course Introduction . Chapter 1-11

Add CourseTitle Here with CourseTitle Variable

11 juniper
LL 1 I .J

junipec

jumper

juniper

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 levels-Associate-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.

Chapter 1-12 . Course Introduction www.Juniper.net

 Add CourseTitle Here with CourseTitle Variable

Ce

Training and study resources:

.
Juniper Networks Certification Program Web site
www. i u ni pe r.n et/ ce rtifi ca ti o n
.
Education Services training classes
www. i u n i pe r.n et/tra i n i n g
.
Juniper Networks documentation and white papers
www Juniper.n et/tech pubs
Preparing for practical exams requires a lot of
hands-on practice:
.
On-the-job experience
.
Education Services training classes
.
Equipment access

Preparing and Studying

The slide lists some options for those interested in preparing for Juniper Networks certification.

www.junlper.net Course Introduction . Chapter 1-13

Add CourseTitle Here with CourseTitle Variable

,
J is Oniln ie

j-net | http://www.juniper.net/jnet

m http://www.juniper.net/facebook

IDii t
mj http://www.juniper.net/youtube

Q http://www.juniper.net/twitter

JUniPGr ".O-tWwWeEclUGatlonServices wwioiiiptrnst : 1-14

Find Us Online

The slide lists some online resources to learn and share information about Juniper Networks.

Chapter 1-14 . Course Introduction www.juniper.net

 Add CourseTitle Here with CourseTitle Variable

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 Course Introduction . Chapter 1-15

Add CourseTitle Here with CourseTitle Variable

Chapter 1-16 . Course Introduction www.juniper.net

juniperNETWORKS

Advanced Junes Service Provider

touting

Chapter 2: OSPF
Advanced Junos Service Provider Routing

After successfully completing this chapter, you will be

able to:
.
Describe the various OSPF LSA types
.
Explain the flooding of LSAs In an OSPF network
.
Describe the SPF algorithm

fide Education Setvices

This Chapter Discusses:

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 OSPFvS.

Chapter 2-2 . OSPF www.juniper.net

 Advanced Junos Service Provider Routing

>0SPFv2 Review
Link-State Advertisements

Protocol Operations
OSPF Authentication

si V orlit.viile tduratum Services

.

OSPFv2 Review

The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.juniper.net OSPF . Chapter 2-3

Advanced Junes Service Provider Routing

OSFFv2 Mmlew (1 of 3)

OSPF is a link-state IGP used within an AS

Neighbors use hello packets to form adjacencies
OSPF floods link-state advertisements
.
OSPF routers use the received LSAs to create a complete
database of the network
.
OSPF uses the shortest-path-first algorithm to calculate the
best path to each destination network
Hierarchical design uses areas connected to a
backbone
Routers on a broadcast segment elect a designated
router
.
Point-to-point option

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 AIISPFRouters multicast address of 224.0.0.5 to flood
link-state advertisements. 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 which forms the topology map of the network.
The SPF algorithm is run to determine the shortest path to each destination subnet.

Continued on the next page.

Chapter 2-4 . OSPF www.juniper.net

 Advanced Junos Service Provider Routing

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. This eliminates the need for a DR
election. Use the interface-type p2p command to change the default interface type.

www.juniper.net OSPF . Chapter 2-5

Advanced Junes Service Provider Routing

:w (2 of 3)

All OSPF routers maintain a copy of the database

.
Database contents consist of information learned through
LSAs and must match on all routers within an area
.
SPF algorithm uses the contents of the LSDB as input data
to calculate network paths

R2
Rl

R4

The Link-State Database

In addition to discovering neighbors and fiooding LSAs, a third major task of the OSPF protocol is to
create and maintain the LSDB. The link-state, ortopological, database stores the LSAs as a series of
records. The contents stored within the LSDB include details such as the advertising router's 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 router's routing table for the actual
forwarding of data packets.

Chapter 2-6 . OSPF www.Juniper.net

 Advanced Junos Service Provider Routing

V m is of

OSPF uses five packet types:

.
Hello-Type 1
.
Database description-Type 2
.
Link-state request-Type 3
.
Link-state update-Type 4
.
Link-state acknowledgment-Type 5

Packet Types
Every OSPF router uses a specific set of packets to perform its functions. The packet types include
the following:

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 neighbor's 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.

www.Juniper.net OSPF . Chapter 2-7

Advanced Junos Service Provider Routing

Backbone
(Area 0 or 0.0.0.0)

/
/

\
/
\
A \/
/
\
Area 1 Area 2 \ Area 3

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 LSAsthat represent the
backbone routes and injecting those into its attached area.

Chapter 2-8 . OSPF www.juniper.net

 Advanced Junes Service Provider Routing

:
. r:::--."A::-.::.vr.,.:.:A::.
. ;-. .-

ABRs belongto Area 0.0.0.0 and Backbone routers have at

an attached area. least one link in OSPF Area
0000
. . .

AS 65415

Area 0.0.0.0 Area 0.0

ASBRs inject routing Internal routers have all

information from outside the OSPF links in the same
OSPF domain. area.

vurldwiiiu Education Se

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:
.
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 ABR depending on whether it has links to other,
nonbackbone areas.

.
Internal router. An internal router is an OSPF router with ail 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 . Chapter 2-9

Advanced Junos Service Provider Routing

i
.
I i I r urat

Configured at the [edit protocols ospf

hierarchy level
List the interfaces associated with the area:

[edit protocols]
usergrouterf show
ospf {
area <area-id> {
<area opt±om>;
interface <interface~name> {
<interface option3>;
/

}
}

'
iunrfernet 1 2-10

Single Area Configuration Exampie

The slide illustrates the basic hierarchy and syntax used to configure 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 2-10 . OSPF www.juniper.net

 Advanced Junos Service Provider Routing

I Itlarea OSFF Configuration

Configured at the [edit protocols ospf ]
hierarchy level
Each area is listed along with the interfaces
associated with that area:

protocols {
ospf {
area area-id {
interface interface-name;
interface interface-name;
interface interface-name;

}
area area-id {
interface interface-name;
}
area area-id {
interface interface-name;
}
}
}
. interface-name can be IP address
Worldwide EciUGcrt id it Services

Multiarea Configuration Example

The siide illustrates the basic hierarchy and syntax used to configure the 0SPFv2 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 2-11

Advanced Junes Service Provider Routing

OSPFvS Protocol Higiligits

OSPFvS is a modified version of OSPF that supports

IP version 6 (IPv6) addressing
Some of the ways OSPFvS differs from 0SPFv2:
.
The protocol runs per link rather than per subnet
.
Router and network LSAs do not carry prefix information
.
Two new LSA types: link-LSAand intra-area-prefix-LSA
.
Flooding scopes are link-local, area, and AS
.
Link-local addresses are used for all neighbor exchanges
except virtual links
*
Two new option bits are included; R and V6
Beyond the scope of this course

juniper w mmv Education Services

OSPFvS Protocol Highlights

OSPFv3 is to IPv6 what OSPFv2 is to IPv4. OSPFv3 is defined in RFC 5340 and supports IPv6
addressing.

OSPFvS vs. 0SPFv2

OSPFvS and OSPFv2 have much in common but there are 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 OSPFvS is beyond the scope of this course.

Chapter 2-12 . OSPF www.juniper.net

 Advanced Junos Service Provider Routing

Agenias ©SPF

0SPFv2 Review
-
>Link-State Advertisements

Protocol Operations
OSPF Authentication

& .
.
. H', i-jf. i.' i Je -.or:--., lr. *,|. rv: t- t -j 1 JUn PG( vV'irlHv/iilt: tUllCaliun

Link-State Advertisements

The slide highlights the topic we discuss next.

www.junlper.net OSPF . Chapter 2-13

Advanced Junos Service Provider Routing

Carry one or more link-state advertisements

Packets consist of:
.
(24-byte) OSPF header
.
(4-byte) Number of advertisements
.
(Variable) Link-state advertisements
1 1 2 4 4 2 2 a Variable
,

in bytes
Version Packet Check- Authent-
Type RouterlD Area ID Authentication Data
ication
number length sum
type

4-- -
20 20 Va ria ble
Va ria ble

1 # of LSAs LSA Header LSA Data LSA Header LSA Data

fllPSr Worldwids Education Services

Multiple LSAs in a Single Update

Each link-state update packet sent into the network by an OSPF-speaking router can carry multiple
different link-state advertisements. 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 format.

Chapter 2-14 . OSPF www.juniper.net

 Advanced Junos Service Provider Routing

LSA Types

Link-state advertisement types:

.
Router LSAs-Type 1
.
Network LSAs-Type 2
.
Summary LSAs-Type 3 and Type 4
.
AS external LSAs-Type 5
.
Group membership LSAs-Type 6
*
NSSA LSAs-Type 7
.
External attributes LSAs-Type 8
.
Opaque LSAs-Type 9, Type 10, and Type 11
*
Each LSAtype describes a portion of the OSPF routing
domain

Type 6, Type 8, and Type 11 are not supported

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 designated router on the broadcast network.

Summary LSA: Sent by an area border router (ABR) to describe routes or other
information from one area into another.

.
AS external LSA: Sent by an autonomous system boundary router (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.
Continued on the next page.

www.juniper.net OSPF . Chapter 2-15

Advanced Junos Service Provider Routing

LSA Functions

Each of the LSA types iisted previously has a specific function within the OSPF domain. They each
describe a portion of the topology used by the Dijkstra (SPF) aigorithm 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 LSA types llsted here. These LSAs are the group
membership (Type 6), external attributes (Type 8), and the domain-scope opaque (Type 11)
advertisements.

Chapter 2-16 . OSPF www.Juniper.net

 Advanced Junos Service Provider Routing

LSA

20 bytes of information that identify the LSA uniquely

and consist of:
.
(2-byte) LS age
.
(1-byte) Options
.
(1-byte) LS type
.
(4-byte) Link-state ID
.
(4-byte) Advertising router
.
(4-byte) LS sequence number
.
(2-byte) LS checksum
.
(2-byte) Length

m
_

LSA Header

The following list details the information contained in the LSA header:

LS age (2 bytes): Measured in seconds, the LS age is the time since the LSA was first
originated. Each router increments this field prior to refloodingthe 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 OxVFFFFFFF.

LS c/iecteum (2 bytes): The checksum of the entire LSA contents, minus the LS 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.

www.juniper.net OSPF . Chapter 2-17

Advanced Junes Service Provider Routing

>ar LSI (Type 1)

Originated by each router in an area

.
Has area scope
. Describes the state and cost of the router's interfaces
.
Consists of the standard LSA header plus:
.
(l-byte) Five 0 bits followed by the V. E. and B bits
.
(l-byte) Reserved (set to 0)
.
(2-byte) Number of links
.
(4-byte)LinklD
.
(4-byte) Link data
.
(l-byte) Link type
.
(l-byte) Number of ToS metrics (set to 0)
.
(2-byte) Metric
.
(4-byte) Additional ToS data (not used)

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:
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 what the far side of the link is connected to. It Is
used in conjunction with the link type field.
.
Link data (4 bytes): This field represents what the nearside of the link is connected to.
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 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.

Chapter 2-18 . OSPF www.juniper.net

 Advanced Junos Service Provider Routing

Interpretation depends on value of the link type field

; Link Type Link ID Umi- ea-f

Point-to-point Neighbor's Local router's

(Type 1) router ID interface IP address

Transit DRs Local router's

(Type 2) interface IP address interface IP address

Stub Network number Subnet mask

(Type 3)
Virtual link Neighbor's Local router's
(Type 4) router ID interface IP address

Wurltiwidu EduiJation Services

Link ID and Link Data Fields

The information in the router LSA's link iD and link data fields is associated with the type of link OSPF
is operating. The following link types are supported:
Point-to-point (Type 1): On a poinMo-point interface, an OSPF router always forms an
adjacency with its peer over an unnumbered connection. As such, the link ID field
contains the neighbor s 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 segment's 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 neighbor's router ID,
and the link data field contains the interface IP address of the local router.

www.juniper.net OSPF . Chapter 2-19

Advanced Junes Service Provider Routing

IMA Examp
u3er@Rl> show ospf database router extensive

OSPF database. Area 0.0.0.0

Type ID Adv Rtr 3sq Age Opt CksLim len

Router 1*192.168.20.1 | 192.168,20.1 0x80000336 161 0x22 0xcc47 60
bits 0x3, Ixnk count 3
id 192.168.100.1. data 172.22.121.1, Type PointToPoint (1)
Topology count: 0, Default metric: 1
id 172.22.121.0, data 255.255.255.0, Type Stub (3)
Topology count: 0, Default metric: 1
id 192.168.20.1, data 255.255.255.255, Type Stub (3)
Topology count: 0, Default metric: 0
Topology default (ID 0)
Type: PointToPoint, Node ID: 192.168.100.1
Metric: 1, Bidirectional
Gen timer 00:30:45
Aging timer 00:57:13
Installed 00:02:41 ago, expires in 00:57:19, sent 00:02:41 ago
'

Last changed 00:02:41 ago. Change count: 10, i Ours jj

Router 192.168.21.1 192.168.21.1 OxSO TOSi6
'

346 0x22 OxleOl 60

bits 0x3, link count 3
id 192.168.100.1, data 172.22.122.1, Type PointToPoint (1)
Topology count: Q, Default metric: 1
id 172.22.122.0, data 255.255.255.0, Type Stub (3)
Topology count: 0, Default metric: 1
id 192.168.21.1, data 255.25S.255.255, Type Stub (3)
Topology count: 0, Default metric: Q
Topology default (ID 0)
Type: PointToPoint, Mode ID: 192.163.100.1
Metric: 1, Bidirectional

Aging timer 00:54:13

Installed 00:02:41 ago, expires in 00:54:14
Last changed 00:02:41 ago. Change count: 1

[ Worldwide Education Services w w junipernei i 2 20

Router LSA Example

You can see the detaiis of the router 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 detaiis about the
local router by examining the LSA closely:

This router is both an ABR as well as an ASBR. We see this 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 (Oxl) 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.

Continued on the next page.

Chapter 2-20 . OSPF www.juniper.net

 Advanced Junos Service Provider Routing

Router LSA Example (contd.)

The router LSA will be regenerated in 30 minutes and 45 seconds as indicated by the
Gen timer. The OSPF standard requires that every link-state advertisement (LSA) be
refreshed every 30 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 oi 192.168 .20.1. Also note that
the last line of the capture states that this LSA is Ours.

The router LSA was installed 2 minutes and 41 seconds ago. If not refreshed, the LSA
will expire in 57 minutes and 19 seconds when its 3600 second maximum age is
exceeded, and the LSA was last flooded 2 minutes and 41 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.

www.juniper.net OSPF . Chapter 2-21

Advanced Junes Service Provider Routing

Type 1 ;4

Area 0

192.168.100.1

192.168,20,1 192,168,21.1

172,22,121,0/24 R2 172,22,122,0/24

ri

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:

We know of three routers within area 0.0.0.0-192.168.20.1 (the local router),

192.168.100.1, and 192.168.21.1;

.
Two point-to-point subnets connect the three routers-172.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.

Chapter 2-22 . OSPF www.juniper.net

 Advanced Junos Service Provider Routing

LSA 2}

Originated by designated routers

.
Has area scope
.
Describes all routers attached to a network segment
.
Consists of the standard LSA header plus:
.
(4-byte) Network mask
.
(4-byte) Attached router

Network LSA

Each OSPF router elected to be the designated router (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:

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.

www.juniper.net OSPF . Chapter 2-23

Advanced Junos Service Provider Routing

f©rlc;.:

user@R4> shovj ospf database network, extensive

OSPF database. Area 0.0.0.10

Type ID """
Adv Rtr Seq Age Opt Cksum Len
Network 110 0 12 l ] 192.168 .20. 2 0x80000001 2765 0x22 0x8 cla 32
mask 255.255.255.0
attached router 192.168.20.2
attached router 192.168.20.1
Topology default (id 0)
Type: Transit, Mode ID: 192.168.20.1
Metric: 0, Bidirectional
Type: Transit, Mode ID: 192.168.20.2
Metric: 0, Bidirectional

Aging timer 00:13:55

Installed 00:46:04 ago, expires in 00:13:55
Last changed 00:46:04 ago. Change count: 1

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:

The designated router for this network Is 10.0.12.1, which you can determine by
'

examining the link-state ID field. This field lists the DR s 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.1.

Chapter 2-24 . OSPF www.juniper.net

 Advanced Junes Service Provider Routing

Bur atwo ! 2 LSA

Area 0
192,168.100.1

192.168,20,1 192.168,21.1

172,22,121.0/24 172.22.122,0/24

Rl P3

R4

192,168,20.2 192,168,20,4

10.0.12.0/24

Area 10

Add Type 2 LSAs to an OSPF Network

Using the information in the network LSA, we can add information to our OSPF network map.
Remember that aii information is from the perspective of the 192.168.20.1 router.

We know of two routers within area 0.0.0.1-192.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.2 and its interface address is
10.0.12.1.

www.juniper.net OSPF . Chapter 2-25

Advanced Junes Service Provider Routing

mmm

Originated by ABRs
.
Has area scope
. Describes networks external to the area
.
Consists of the standard LSA header plus:
.
(4-byte) Network mask
.
(1-byte) Reserved (set to 0)
.
(3-byte) Metric
.
(1-byte)ToS (not used)
.
(3-byte)ToS metric (not used)

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 refiooded 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:
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 type of service information encoded
within the network described. The Junos OS does not use this field.

ToS metric f3 bytes ): This field is not used.

,

Chapter 2-26 . OSPF www.juniper.net

 Advanced Junes Service Provider Routing

Summary LSI Example

user@Rl> show ospf database netsummary extensive

OSPF database. Area 0.0.0.0

Type ID Adv Rtr Seq Age Opt Cksum Len

Summary *10.0.10.0 192.168.20.1 0x80000003 242 0x22 0xffa7 28
mask 255.255.255.0

Topology default (ID 0) -> Metric: 1

Gen timer 00:45:58
Aging timer 00:55:58
Installed 00:04:02 ago, expires in 00:55:58, sent 00:04:00 ago "

Last changed 00:04: 06 ago. Change count: 1, [Ours ]

Summary *10 .0.12.0 192.168 .20.1 0x80000001 242 0x22 0xf7ae 28
mask 255.255.255.0

Topology default (ID 0) -> Metric: 2

Gen timer 00:45:58
Aging timer 00:55:58
Installed 00: 04:02 ago, expires in 00:55:58, sent 00 : 04 :02 ago "

Last changed 00:04: 02 ago. Change count: 1, lours ]

Summary 10.0.14.0 192.168.21.1 0x80000002 90 0x22 0xced4 28
mask 255.255.255.0
Topology default (ID 0) -> Metric: 1
Aging timer 00:58:29
Installed 00:01:28 ago, expires in 00:58:30
Last changed 00:01:28 ago. Change count: 1

Summary LSA Example

You can see the details of the summary 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 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
there is an asterisk (*) 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 2-27

Advanced Junos Service Provider Routing

AreaO

l V 'fH 100.1
.

2 c-'* -» .2

192.16S.20.1 192.168.21.1
1
172.22.121,0/24 172.22.122.0/24

Rl

1D.0.10.
10.0.14.0/24 \

nr. ( 192.168.20.4 i
192.168.20.2

1 .
i .
2

10.0.12.0/24
192.168.21.2

Area 10
Area ?

Add Type 3 LSAs to an OSPF Network

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:
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 it-192.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; and

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.

Chapter 2-28 . OSPF www.juniper.net

 Advanced Junos Service Provider Routing

ASBfR S ary LSA (If;', ,

Originated s
by ABRs
.
Has area scope
. Describes ASBRs external to the area

.
Consists of the standard LSA header plus:
.
(4-byte) Network mask
.
(1-byte) Reserved (set to 0)
-
(3-byte)Metric
.
(1-byte) ToS
.
(3-byte)ToS metric

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;

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 C3 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.

www.Juniper.net OSPF . Chapter 2-29

Advanced Junes Service Provider Routing

user@Rl> show ospf database asbrsummary extensive

OSPF database, Area 0.0.0.0

Type ID Adv Rtr Seq Age Opt Cksura Len

ASBRSum 192.168.21.2 192.168.21.1 0x80000001 374 0x22 0x3209 28
mask 0.0.0.0

Topology default (ID 0) -> Metric: 1

Aging timer 00:53:45
Installed 00:06:12 ago, expires in 00:53 :46

Last changed 00:06:12 ago. Change count: 1

ASBRSum *192.168.20.4 192.168.20.1 0x80000001 14 0x22 0x3703 28
mask 0.0.0.0
Topology default (ID 0) -> Metric: 2
Gen timer 00:49:46
Aging timer 00:59:46
Installed 00:00:14 ago, expires in 00:59:46, sent 00:00:14 ago
Last changed 00:00:14 ago. Change count: 1, Ours

Worldwide Education Services

ASBR Summary LSA Example

You can see the details of the ASBR summary 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 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,
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 there is an
asterisk (*) 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.

Chapter 2-30 . OSPF www.juniper.net

 Advanced Junos Service Provider Routing

Area 0

192.1 r)'. km I

.
2 *a m. ;:

192.168.21.1 y
R2 172 22.122.0/24
.

10.0.14.0/24

192.168.20.2

1 .2
R6

10.0.12.0/24 192,103 21.2

Area 1
Area ?

Add Type 4 LSAs to an OSPF Network

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:

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.

www.juniper.net OSPF . Chapter 2-31

Advanced Junos Service Provider Routing

xtema

Originated by ASBRs
.
Has domain scope
. Describes networks external to the OSPF domain
.
Consists of the standard LSA header plus:
.
(4-byte) Network mask
.
(1-byte) E-bit followed by seven 0 bits-default Is E2
.
(3-byte) Metric
.
(4-byte) Forwarding address
.
(4-byte) External route tag
.
(4-byte) Optional ToS fields

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:

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.

Chapter 2-32 . OSPF www.juniper.net

 Advanced Junes Service Provider Routing

Kmim

u3er@Rl> show ospf database external extensive

OSPF A3 SCOPE link state database
Type ID Adv Rtc Seq Age Opt Gksum Len
Extern *Z0.20.1.0 19Z.168.20.1 0x80000003 20 0x22 0x5dab 36
mask 255.255.255.0

Topology default (ID 0)

Type: 2, Metric: 0, Fwd addr: 0.0.0.0, Tag: 0.0.0.0
Gen timer 00:30:20
Aging timer 00:59:39
Installed 00:00:20 ago, expires in 00:59:40. sent 00:00:16 ago
last changed 00:01:19 ago. Change count: 2, Qur£J
Extern 20.20.3.0 192.168.21.1 0x80000002 81 0x22 0x42o4 36
mask 255.255.255.0
Topology default (ID 0)
Type: 2, Metric: 0, Fwd addr; 0.0.0.0, Tag: 0.0.0.0
Aging timer 00:58:38
Installed 00:00:20 ago, expires in 00:58:39
Last changed 00:00:20 ago. Change count: 1
Extern 20.Z0.S.0 192.168.20.4 0x80000002 83 0x22 OxZlel 36
mask 255.255.255.0

Topology default (ID 0)

Type: 2, Metric: 0, Fwd addr; 0.0.0.0, Tag: 0.0.0.0
Aging timer 00:58:36
Installed 00:00;20 ago, expires in 00:58:37
Last changed 00:00:20 ago. Change count; 1
Extern 20.20.6.0 192.163.21.2 0x80000002 82 0x22 0xlbe7 36
mask 255.255.255,0
Topology default (ID 0)
Type: 2, Metric: 0, Fwd addr: 0.0.0.0, Tag: 0,0.0.0
Aging timer 00:58:37
Installed 00:00:20 ago, expires in 00:58:38
Last changed 00:00:20 ago. Change count; 1

AS External LSA Example

You can see the details of the AS external 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 the
local router by examining the LSA closely:

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,

www.Juniper.net OSPF . Chapter 2-33

Advanced Junos Service Provider Routing

] mmm

Area 0

192.168,100.1

192.168,20.1 i92.iea.2ii
L 20,20,3.0/24
R2
20,20,1.0/24 172,22,121,0/24 172,22,122,0/24

Rl

R-1 RE 10,0,14.0/24

192,168,20,2 192,168,20,4
20,20.5,0/24

\ 10,0,12,0/24 192,168,21.2
20,20,6,0/24
\
Area 1

ij!

Add Type 5 LSAs to an OSPF Network

The addition of AS externai LSAs to our network map displays the external routes being advertised
into the network:

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.

Chapter 2-34 . OSPF www.juniper.net

 Advanced Junes Service Provider Routing

NSf; eternal LSA.

Originated by ASBR within the NSSA

.
Has same format as an AS external LSA (Type 5)
.
Has area scope
. Describes networks external to the OSPF domain

Translated into an AS external LSA (Type 5) by the

ABRatthe NSSA border
.
The propagate bit in the options field indicates whether
translation should take place
.
A value of 1 means translate and propagate
.
A value of 0 means do not translate

.
When multiple ABRs exist, the ABR with the highest RID
performs the translation

NSSA External LSA Origination

Each ASBR within the not-so-stubby area (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.

Continued on the next page.

www.juniper.net OSPF . Chapter 2-35

Advanced Junos Service Provider Routing

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 probiem 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 2-36 . OSPF www.juniper.net

 Advanced Junes Service Provider Routing

a3er@R6> show ospf database nssa extensive

OSPF database. Area 0.0.0.20

Type ID Adv Rtr Seq Age Opt Cksum Len

HSSA 20.20.3.0 192.168.21.1 0x80000001 IBS 0x20 0x46cl 35
mask 255.255.255.0

Topology default (ID 0)

Type: 2, Metric: 0, Fwd addr: 0.0.0.0, Tag: 0.0.0.0
Aging timer 00:56:53
Installed 00:03:04 ago, expires in 00:56:54
Last changed 00:03:04 ago, Change count: 1
WSSA *20.20.6.0 192.168.21.2 0x80000001 185 0x28 0x576 36
mask 255.255.255.0
Topology default (ID 0)
Type: 2, Metric: 0, Fwd addr: 192.168.21.2, Tag: 0.0.0.0
Gen timer 00:46:54
Aging timer 00:56:54
Installed 00:03:05 ago, expires in 00:56:55, sent 00:03:04 ago
Last changed 00:03:05 ago. Change count: 1, Ours

NSSA External LSA Example

You can see the details of the NSSA external LSAs in the example on the slide. 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:

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 O 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.

www.juniper.net OSPF . Chapter 2-37

Advanced Junes Service Provider Routing

Area 0

102168.100.1

192.168.20.1 192.168,21.1
P2 20.20.3.0/24
172 22,121,0/24 172.22,122.0/24
20,20,1,0/24

10,010,0/24
\
R4 Kb 10,0,14,0/24 \

192,168,20,2 192,168,20,4 20,20,5,0/24

I RR

10,222,1,0/24
20,20,6,0/24
Area 20 /
Area 10
NSSA

Add Type 7 LSAs to an OSPF Network

When we focus our attention on the 192.168.21.1 ABR, we now get some added information about
the network composition:

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.

Chapter 2-38 . OSPF www.juniper.net

 Advanced Junos Service Provider Routing

Opa LSA 11)

Allows for the future extensibility of OSPF

.
The Junos OS uses Type 9 for graceful restart capability
.
The Junos OS uses Type 10 for MPLS traffic engineering
.
Type 11 is currently not supported

The difference is in flooding scope

.
Type 9 has link-local scope
.
Type 10 has area scope
.
Type 11 has domain scope
Consist of a standard LSA header followed by
application-specific information
.
OSPF or other applications can use information field directly
A'ojWwitls Eiiucatiun Servtos
: - .- ---. :- .... iiWWSmm mmmlfMK B nK n

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
0-127 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 0 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 2-39

Advanced Junos Service Provider Routing

0SPFv2 Review

Link-State Advertisements
-

> Protocol Operations

OSPF Authentication

JfTPG'' W.irlriv.'iilMLiluraliunSRrviues

Protocol Operations
The slide highlights the topic we discuss next.

Chapter 2-40 . OSPF www.Juniper.net

 Advanced Junos Service Provider Routing

A Floodmg
External
Routes
AreaO Bach hone
Area 0 Area 0
n d n ni Injected
LSA 2 LSAS
LSA1 Area3
LSAS
Area 1 Area 2 Area 3 Area 3
LSAS LSAS i LSAS LSA 4

x
Area 1 Area 2 Area 3 Area 3
/ Area 1
LSA1 LSA 2 LSA1 3A 2 LSA1 LSA 2
. -

Area 0 Area 0 ' Area 0 Area 0 Area 0 Area

LSAS LSA 4 LSAS LSA 4 LSA 4 3

Area 2 Area 1 Area 3

Area 3 Area 1
LSAS LSA o
LSA 4 l :a 3
LSA 4 LSAS .
,

Area 3 AreaS
LSAS LSAS

Area 0 Area 3
LSA 5 LSA 5 V Injected
Area 1
VArea 2

LSA Flooding Scopes

As discussed in previous slides, each LSA in the OSPF protocol has a specific scope within which it
can be flooded. The 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 2-41

Advanced Junes Service Provider Routing

a Database

user@touter> show ospf database

OSPF link state database, area 0.0.0.0

Type ID Adv Rtr Seq Age Opt Cksum Len
Router *
192.168.16.1 192.168.16.1 0x80000004 177 0x2 0xd45b 60
Router 192.168.36.1 192.168.36.1 0x80000005 305 0x2 0xda47 60

Summary 10.222.1.0
*
192.168.16.1 0x80000002 412 0x2 Oxfafa 28
Summary *
10.222 .29.0 192.168.16.1 0x80000002 631 0x2 Oxbblf 28
Summary
*
192.168 .20.1 192.168.16.1 0x80000001 412 0x2 0x87c6 28
ASBRSum 192.168.32.1 192.168.36.1 0x80000001 240 0x2 0x3b07 28

OSPF link state database, area 0.0.0 1

Type ID Adv Rtr Seq Age Opt Cksum Len
Router *
192.168.16.1 192.168.16.1 0x80000007 39 0x2 0xcc62 60
Router 192.168.20.1 192.168.20.1 0x80000002 415 0x2 0xd7d9 48
Network 10.222.1.1 192.168 .20.1 0x80000001 418 0x2 0x6a75 32
Summary
*
192.168.32.1 192.168.16.1 0x80000001 238 0x2 0xe96b 28
Summary
*
192.168.36.1 192.168 .16.1 0x80000002 631 0x2 0xbl9f 28
ASBRSum *
192.168.32.1 192.168.16.1 0x80000001 238 0x2 0xdb78 28
ASBRSum *
192.168.36.1 192.168.16.1 0x80000001 574 0x2 0xa5ab 28
OSPF external link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern *
192.168.17.0 192.168.16.1 0x80000001 631 0x2 0x3812 36
Extern 192.168.21.0 192.168.20.1 0x80000001 420 0x2 0x8693 36
Extern 192.168.33.0 192.168.32.1 0x80000001 590 0x2 0x1713 36
Extern 192.168.37.0 192.163.36.1 0x80000001 576 0x2 0xce53 36

Wo rltlwitie Education Services Mtw.juntpernei ] 2-'!?

.
.

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:
.
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 ISA within the Area O.O.O.l
database. The link-state ID is 10.222.1.1, the DR's 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 ISA 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
000
. . . 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.

Chapter 2-42 . OSPF www.juniper.net

 Advanced Junos Service Provider Routing

"

, . Ion

Limits the number of LSAs not generated by the local

router in a given OSPF routing instance
Protects the LSDB from being flooded with excessive
LSAs

Useful if VPN routing and forwarding is configured on

your provider edge and customer edge routers are
using OSPF as the routing protocol

[edit protocols ospf]

user§router# set database-protection maximum-lsa 1000

OSPF Database Protection

This feature limits the number of LSAs that were not generated by the local router. This protects the
LSDB from being flooded with excessive LSAs. This is a very useful feature if a VPN routing and
forwarding (VRF) instance is configured to use OSPF between the PE and CE routers.

www.Juniper.net OSPF . Chapter 2-43

Advanced Junes Service Provider Routing

Based on the Dijkstra algorithm

. Link-state database
. Candidate database
. Tree database

Run on a per-area basis on each router

.
Independent calculation of the topology
Result is passed to the Junos OS routing table
.
The route selection algorithm (route preference value)
determines whether the route is marked active

I Of IT orlrlwiclc f (luuimionSori.iccs

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 databases-the 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, cost), which describe each link in the network.
1 . Evaluate 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. Return to Step 1.

Continued on the next page.

Chapter 2-44 . OSPF www.juniper.net

 Advanced Junos Service Provider Routing

Dijkstra Algorithm (contd.)

When the aigorithm operates, the iocal router moves its own iocal 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 entry s neighbor ID into the candidate database.

Run on a Per-Area Basis

The router calculates the Dijkstra algorithm for each LSDB present on the iocal 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 routes-those learned from Type 5
and Type 7 LSAs-from 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 2-45

Advanced Junes Service Provider Routing

11 w

Link-State
RTR-A
(A, A. 0)

A i
(A, B. 1)
(A, C. 2)
(B.A. 3)
(B. D, 3)
RTR-B TR-C (C,A. 4)
(C. D. 4)
(D.B, 1)
RTR-D (D,C. 2)

11
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 a SPF calculation to
determine the shortest path to each node in the network.

Chapter 2-46 . OSPF www.juniper.net

 Advanced Junes Service Provider Routing

lm (2

Link-State Candidate Tree

(A, A. 0 LS Entry Cost to Root (A. A. 0) - 0

(A. B, 1) (A. A. 0)
(A, C. 2)
(B, A. 3)
B . D, 3) RTR-A
(CA, 4)
(C. D. 4)
(D.B. 1)
(D.C,2)

SPF Calculation Example: Part 2

RTR-A begins by moving is own locai database tupie (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, tupie in the candidate database is moved to the tree database and RTR-A
places itself on the network map.

www.juniper.net OSPF . Chapter 2-47

Advanced Junos Service Provider Routing

Link-State Candidate Tree

[A. A. 0) LS Entry Cost to Root (A, A. 0) - 0

(A. B. 1) (A. A. 0) (A, B. 1) -1 I
(A. B. 1'
(B, A, 3) (A, C. 2
(B.D, 3) RTR-A
(C.A. 4)
(CD, 4)
(D, B, 1)
(D.C. 2)

RTR-B

JUR P.Cjr Woilriwhle ( ducationSL-c\ices

SPFCalculation Example: Parts

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-A's 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-AOto reach itself and Ito
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 2-48 . OSPF www.juniper.net

 Advanced Junes Service Provider Routing

ixamp

Link-State Candidate Tree

LS Entry Cost to Root; (A. A. 0)- 0

(A. D. 1) (A. A. 0) -
e
-

(A. B, 1) - 1
(A, C. 2) (A. D. 1) (A. C. 2) 2

(D.A. 3) (A. C. 2)
(B.D. 3) (D.A. 3)
RTR-A
(C.A, 4) (B.D, 3)
IIIIVJL~1
(C D.4) mjrM
(D, B, 1)
(D.C. 2)

RTR-B RTR-C

SPF Calculation Example: Part 4

RTR-B is the most recent entry to the tree database, so ail RTR-B's 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.

The candidate database is not empty, so the algorithm continues.

www.juniper.net OSPF . Chapter 2-49

Advanced Junes Service Provider Routing

"

. . {S of 0)
Link-State Candidate Tree

(A. A. 0) ! LS Entry Cost to Root (A. A, 0) - 0

(A. B. 1) (A, B, 1) -1
(A, C, 2) (A, 0.2)-2
(B,D. 3)-4
(B.A. 3)
(B.D. 3) ! (U n, J)
. =f-r
RTR-A
(CA. 4)
(C. D. 1)
! (D.B. 1) (CD, 4) 6 '

1 2

(D.C. 2)

RTR-B\3 RTR-C

®
RTR-D

HMBMMMWMI
Worldwide Education Services

SPF Calculation Example: Part 5

As RTR-C is the most recent entry to the tree database, 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,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.

The candidate database is not empty, so the algorithm continues.

Chapter 2-50 . OSPF www.juniper.net

 Advanced Junes Service Provider Routing

Link-State Candidate Tree

LS Entry Cost to Root (A. A, 0) - 0

(A. A, 0)
(A. B. 1) (A. B. 1) . 1
(A. C. 2) (A. O. 1) (A. C. 2) - 2
o i (B, D. 3) 4 -

(B.A. 3) tA - *-)

(B. D. 3) RTR-A
(C. A. 4)
(C. D. 1) 1 (0. n, 4)
(D. D. 1)
(U, R
D, H 5
(D.C, 2) ! ±j

| (U. il)
1 RTR-E a RTR-C

RTR-D

Worldwide EducationServiEes

SPF Calculation Example: Part 6

RTR-D, via 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 Junes routing table for its use.

www.juniper.net OSPF . Chapter 2-51

Advanced Junes Service Provider Routing

Three consecutive SPF runs can occur before a

mandatory hold-down occurs
.
Keeps the network stable during change
.
5-seoond timer is now configurable
.
Possible values range from 2000 to 20,000 ms
Default 200 ms delay between a topology change and
running the SPF algorithm
.
Altered with the spf-options delay command
.
Possible values range from 50 to 8000 ms
[edit protocols ospf]
user@router# set spf-options delay 100

LOPPr Worldv/iUeEiiucritionSer ices

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 hog the CPU 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; you can alter it with the spf-delay statement. The spf-delay statement is
supported both at the global OSPF configuration hierarchy and within an OSPF routing instance.
Delay values ranging from 50 milliseconds to 1000 milliseconds (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 today's networking environment is setting the spf-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 spf-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 2-52 . OSPF www.juniper.net

 Advanced Junes Service Provider Routing

Cost, or metric, of an interface indicates the overhead

required to send packets out a particular interface
Default OSPF cost for all links is 108/bandwidth (bps)
.
Links with a bandwidth > 100 Mbps have a cost of 1
.
If cost calculation results in a value <1, it is rounded up
Cost can be set on a per-interface basis
[edit protocols ospf]
user@router# show
area 0.0.0.0 {
interface so-0/0/0.0 {
metric 12;

}
interface at-1/0/1.100 {
metric 73;

Worltlwiilu Erfudatitm Services

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 vaiues in its router LSAs, each router can determine the totai cost (or
metric) to reach any destination in the network.

OSPF Default Cost

Each router uses an algorithm to determine the cost of each interface-the 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), ail interfaces operating at a faster bandwidth have their calculated
cost less than 1, which becomes rounded up to 1.

Set on a Per-lnterface Basis

If you want to alter the automatic cost calculated by the formula above, 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 2-53

Advanced Junos Service Provider Routing

You can change the 108 value in the cost calculation

.
Automatically alters the cost of interfaces
.
Allows for a consistent change across all interfaces
Use the reference-bandwidth command
Overridden by metric command
[edit protocols ospf]
usergrouter! set reference-bandwidth 10g

[edit protocols ospf]

user@routerf show
'

Ir eFer n e-bandwidth IQgTj

area 0.0.0.0 {
interface so-0/0/0.0 {
metric 12;

}
interface at-1/0/1.100;
}

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 alterthe 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 2-54 . OSPF www.juniper.net

 Advanced Junos Service Provider Routing

Metric values are advertised in Type 1 or Type 2 LSAs

and populate LSDB
As each router runs the SPF algorithm, each LSA is
examined individually for the cost of the outgoing
interface
. The final metric calculation uses that cost

Routers can disagree about the cost on a network link

.
Can result in asymmetric routing in the network
. Rl sees a cost of 45 to reach the R4 router
. R4 sees a cost of 60 to reach the Rl router

io Mim is 20 Mim 25 30

Rl R2 R3 R4

WuriifamU? Eidacailori Services

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 Caiculations

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, it is possible for two routers on
either side of a link to 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
Rl 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 Rl 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 troubleshootthe network.

www.junlper.net OSPF . Chapter 2-55

Advanced Junos Service Provider Routing

Used for transit traffic only if no other path is available

. Sets metric to 65,535 in router LSA on all transit links
.
Flooding of changed LSA causes SPF calculations in network
Can be set permanently or with a timeout value
. Timer is between 60 and 1800 seconds
.
Timer only runs after rpd starts
[edit protocols ospf]
userSrouterf show
ioverloadTI
area 0.0.0.0 {
interface so-0/0/0.0;
interface ge-0/1/0.0;
}
user@router> show ospf database router extensive
OSPF link state database, area 0.0.0.3
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 192.168.56.1 192.168.56.1 0x80000005 71 0x2 0x540b 60
id 192.168.48.1, data 10.222.61.1, type PointToPoint (1)
TOS count 0, TOS 0| metric 655351

JLiniPET WorldwifJe EducationServiDes MWMjuniper.nti i 2-B6

Avoid Transit Traffic

OSPF borrows the overtoad 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 situations-when 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 60-1800 seconds. When the timer expires, the metrics return to
normal in the router LSAs, but the configuration still contains the overload option.

Chapter 2-56 . OSPF www.juniper.net

 Advanced Junes Service Provider Routing

Overioaci

Case study assumptions:

.
We have a meshed network with multiple paths
. R2 is scheduled for maintenance
.
Overload is configured on R2 during the maintenance
*
Transit traffic is routed around R2

R2

Rl \gT / R4
Rl R4

R3

Case Study
Service provider networks are typically built with multiple paths from ingress and egress points for
redundancy. During maintenance operations on a router, it can be beneficial to prevent the router
from receiving and forwarding transit traffic. 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 2-57

Advanced Junos Service Provider Routing

osw mmwx hi

Each OSPF router selects a 32-bit value to use as its router ID

.
Populated within the LSAs sent out by each router
.
Uniquely identifies the router within the network
.
Used by the LSDB to run SPF
"
When rpd initiates, the primary interface of the router is
chosen as the source of the router ID
.
Normally the loopback interface when a non-Martian route IPv4 address
is configured
You can set the RID explicitly within [edit routing-
options ]
.
Stub route to RID is no longer advertised by default
[edit routing-options]
user@router# set router-id 192.168.1.1

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 router's 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 no non-127/8 address is configured, the
interface uses the first available IP address on the router.

Continued on the next page.

Chapter 2-58 . OSPF www.Juniper.net

 Advanced Junes Service Provider Routing

Router ID Is the Primary Interface (contd.)

Because the OSPF routing process uses the primary router interface 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 router's primary interface value is not used.

www.Juniper.net OSPF . Chapter 2-59

Advanced Junos Service Provider Routing

Loo

Your loopback address is likely equal to your router ID

.
Occurs when a non-127/8 address is configured
As of Junos OS Release 8.5, the Junos OS no longer
automatically advertises the loopback address into
the LSDB
.
When interface loO is not configured within OSPF, it is
no longer advertised
.
When interface loO is configured in a specific area, it
is advertised in the router LSA of that area

-UK mrtti.-'i Up i\ , fi'k ' r'- - ., JUfllPE r WoHdWldR EducatiOfi Services. . . ... . wwwjuniperri&t f 2-60

Loopback Is Often the Router ID

In 99.9% of the networks using OSPF, the routers have unique loopback IP addresses configured. 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 version 8.5, the Junos OS no longer automatically advertises your loopback IP address, which
may also be your RID, into the network. However, there are several important points to keep in mind
when configuring your router.

If you do not configure interface loO . 0 within an OSPF area, the loopback IP address will be
not be advertised. Thus, the loopback address will not be reachable.

When you configure interface loO . 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 2-60 . OSPF www.Juniper.net

 Advanced Junos Service Provider Routing

Agenda: OSPF

0SPFv2 Review

Link-State Advertisements

Protocol Operations
-
>OSPF Authentication

- - ..
.
. . - -
.

.. |
OSPF Authentication

The slide highlights the topic we discuss next.

www.juniper.net OSPF . Chapter 2-61

Advanced Junos Service Provider Routing

Three types of authentication are supported: none,

simple, and MD5
.
IPsecalso supported from Junos OS Release 8.3
By default, the authentication type is set to none
.
Effectively means no authentication is performed
Type simple uses a plain-text password
[edit protocols ospf]
user@router# show
area 0.0.0.20 {
interface fe-0/0/2.0 {
| a uthe nti cation { |
| simPle~PasswQ1:d "$9?Yxr8X-Djqz39524ZDjf 5"; ## SECRET-DATA
}
}
}

Authentication

The three different forms of authentication that the Junos OS supports are none, simple, and MD5.
As of Junos version 8.3, IPsec was added. IPsec is configured atthe [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 2-62 . OSPF www.juniper.net

 Advanced Junos Service Provider Routing

Includes an encrypted checksum with ail packets

.
Provides better security than simple type
Each interface requires an authentication key
.
Multiple interfaces can use the same key
.
Keys are always encrypted in the configuration
Each key requires a key ID value ranging from 0-255
[edit protocols ospf]
user@router# show
area 0.0.0.20 {
Interface fe-0/0/2.0 {
authentication {
mdS 30
""
key "$9$wc24ZzF/01h";
'
## SECRET-DATA
}
}
}

Encrypted Checksum
To provide better security in an OSPF network, we recommend that you use an authentication type of
MDS. MDS includes an encrypted checksum in all OSPF packets instead of a simple-text password.
Each OSPF-speaking router uses the same MDS 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 2-63

Advanced Junos Service Provider Routing

MD5 authentication allows for multiple key ID values

Highestvalue used by default
For easy transition, assign each key ID a start time

[edit protocols ospf area 0.0.0.1]

userSrouterf show
interface fe-0/0/0.0 {
authentication {
md5 1 key "$9$fOF/SyK7-w" ; ## SECRET-DATA
[md5 2 key "$9$f0z69CuBRS" start-time 2006-7-4.17:07:06; ## SECRET-DATA
} "

Woridwirie Education Services W'r; jiinipsr ne!. | 2-64

.

Multiple Key Values

When configuring muitipie key vaies 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 in the slide displays the format of the start-time command. When the local router s
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 2-64 . OSPF www.juniper.net

 Advanced Junes Service Provider Routing

Ver a

Authentication information available with the show

ospf interface detail command
.
Type of authentication is displayed
.
Key ID values shown if appropriate
userSroutes show ospf interface detail
Interface state Area DR id bdr ID Wbrs

fe-0/0/2.0 DR 0.0.0.0 192.168.36.1 192.168.24.1 1

Type LAM, address 10.222.4.2, mask 255.255.255.0, MTU 1500, cost 1
DR addr 10.222.4.2, BDR addr 10.222.4.1, adj count 1, priority 128
Hello 10, Dead 40, ReXmit 5, Mot Stub

Auth type MD5, Active key id 4, Start time 20 03 Apr 14 11:05:00 UTC
"*

fe-0/0/3.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0

Type LAM, address 1.1.1.2, mask 2 55.255.255.0, MTU 1500, cost 1
adj count 0, priority 128
Hello 10, Dead 40, ReXmit 5, Not Stub

[Auth type Password]

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 2-65

Advanced Junes Service Provider Routing

Use traceoptions to look for an authentication

mismatch

user@router> show log ospf.log

Dec 1 04:04:58 trace on: Tracing to '7 var/log/ospf. log" started
_

Dec 1 04:04:58.291934 OSPF sent Hello 172.20.77.2 -> 224.0.0.5 (ge-0/0/l.D IFL S5 area 0.0.0.0)
Dec 1 04:04:58.291985 Version 2, length 44, ID 192.168.2.1, area 0.0.0.0
Dec 1 04:04:58.292047 mask 255.255.255.252, hello ivl 10, opts 0x2, prio 128
_

Dec 1 04:04:58.292094 dead ivl 40, DR 172.20.77.2, BDR 0.0.0.0

_

Dec 1 04:04:58.292730 OSPF DR is 192.168.2.1, BDR is 0.0.0 0

Dec 1 04:04:59.756848 OSPF packet ignored: [authentication type mismatch |(21 from 172.20.77.1
Dec 1 04:05:08.197177 OSPF periodic xmit from 172.20.77.2 to 224.0.0.5 (IFL 65 area 0.0.0.0)
Dec 1 04:05:09.047239 OSPF packet ignored: fauthiTjtication tvoe mismatch] (2) from 172.20.77.1

Ib ( ducatiun Seruoes

Authentication Mismatch

OSPF routers must agree on the authentication method to be neighbors. Use the traceoptions
commands if you suspect there may be an authentication mismatch.

The log shows that the iocai 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 2-66 . OSPF www.juniper.net

 Advanced Junos Service Provider Routing

In this chapter, we:

.
Described the various OSPF LSA types
.
Explained the flooding of LSAs in an OSPF network
.
Described the SPF algorithm
.
Listed key differences between OSPFv2 and OSPFvS

This Chapter Discussed:

OSPF LSAs;

The flooding of LSAs throughout the network; and

The SPF algorithm.

www.juniper.net OSPF . Chapter 2-67

Advanced Junes Service Provider Routing

1 . What LSA is used to support graceful restart?

2 . How can you automatically alter the metric of the
'
router s links?

3 .
What are the different forms of OSPF
authentication?

irlifv.lil.' I dm .ii
. Sciviixs

Review Questions
i.

Chapter 2-68 . OSPF www.juniper.net

 Advanced Junos Service Provider Routing

Lab 1: OSPF iia!tiar®a Networks

Configure, monitor, and troubleshoot the operation of

an OSPF network using multiple areas.
Alter metrics, configure overload, and configure
authentication.

Lab 1: OSPF Multiarea Networks

The slide lists the objectives for this lab.

www.juniper.net OSPF . Chapter 2-69

Advanced Junos Service Provider Routing

Chapter 2-70 . OSPF www.juniper.net

junipe NETWORKS

Advanced Junos Service Provider

Chapter 3: OSPF Areas

Advanced Junes Service Provider Routing

iectives

After successfully completing this chapter you will be ,

able to;
.
Describe OSPF area types and operations
.
Configure various OSPF area types
. Summarize and restrict routes

Sf WDrldwitteEdMcalionServices

This Chapter Discusses:

OSPF area types and operations;

The configuration of various OSPF area types; and

The summarization and restriction of routes.

Chapter 3-2 . OSPF Areas www.juniper.net

 Advanced Junes Service Provider Routing

> Review of OSPF Areas

Stub Area Operation

Stub Area Configuration
NSSA Operation
NSSA Configuration
Route Summarization

Review of OSPF Areas

The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.juniper.net OSPF Areas . Chapter 3-3

Advanced Junos Service Provider Routing

mam mmmm

Problem: As OSPF networks grow, so does the size of

the LSDB, which can overload resources

c AreaO

***
**
i

Solution: Implement OSPF areas to shrink the size of

the LSDB

®
AreaO

Area 1 Area 0 Area 2

'
orltlwicle Eciucation Services

OSPF Scalability
With a iink-state protocol, flooding link-state update packets and runningthe shortest-path-first (SPF)
algorithm consume 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 runningthe 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.

Chapter 3-4 . OSPF Areas www.juniper.net

 Advanced Junes Service Provider Routing

Area 0.0.0.0 serves as backbone area

and distributes routing information
between attached areas.
AS 65415

Area 0.0.01 Area 0.0.0.0 Area 0.0.0 2

Areas
.
An AS can be divided into smaller groups called areas
.
LSAflooding can be constrained to an area, which
effectively reduces the size of the LSDB
.
All routers maintain an identical copy of the LSDB on a
per-area basis

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 aiter 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 Areas . Chapter 3-5

Advanced Junos Service Provider Routing

ABRs belongto Area 0.0.0.0 and an Backbone routers have at least

attached area, one link in OSPF Area 0.0.0.0

RIP :

Area 0 0.0.1 Area 0.0.0.0 Area 0.0.0.2

ASBRs inject routinginformation Internal routers have all OSPF

from outside the OSPF domain. links in the same area.

'
orldwiiJe Education Serviues

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.

Chapter 3-6 . OSPF Areas www.juniper.net

 Advanced Junes Service Provider Routing

Does not carry external

Special stub area that Intra-Area Routes routes and cannot
Stub Area
allows external routes to contain ASBRs
be advertised from the
area but not received from Stub area that receives
another area only a default route from
the backbone
Interarea Routes
(Summary Routes) Stub no-summaries
Area
Not-SoStubbyArea

Backbone

(0.0.0.0)

Default Route
External Routes

OSPF Area Types

This siide introduces some OSPF area types and iiiustrates 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.

Continued on the next page.

www.juniper.net OSPF Areas . Chapters-?

Advanced Junos Service Provider Routing

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-summarles 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.)

Chapter 3-8 » OSPF Areas www.junlper.net

 Advanced Junos Service Provider Routing

Router Links Network Links

Typel Type 2

Originated for multi-access segments with more thanone

Describe the state a nd cost of the router's attached router Describe all routers attached to the
inks(interfaces)to thearea (Intra-area) specific segment. Originated bya designated router (DR),

Summary Links External Links NSSA External Links

Type 3 and Type4 Type5 Type?
/' SsA
*
x
\

f
\J\
ASBR ASBR \
-
ABR
\
Originated by ABRs, Describe networks in
the AS butoutsideof area (interarea). Originated byan ASBR. Describe externa Used by not-so-stubby a reas to import
Also describe the location of the ASBR. destination prefixesora defaultroute. external routes intoa stubarea,

'orlclwitie EtltiDation Sarvi

An Overview of the LSA Types

The slide highlights the LSA types used in modern OSPF networks. These LSAs each represent a
portion of the OSPF network and are flooded into the AS based on the function of the router.

We highlight some key details for these LSA packet types:

Router (Type 1): Router LSAs describe the interfaces and neighbors of each OSPF router
to all other OSPF routers within the same area (intra-area).
.
Network (Type 2): Network LSAs describe an Ethernet segment. These LSAs are sent by
the designated router to other OSPF routers within the same area (intra-area).
.
Summary (Type 3): Summary LSAs describe IP prefixes learned from router and network
LSAs. These LSAs are sent by the ABR attached to the area from where the prefix
Information was learned and sent to other OSPF areas (interarea). Note that as
summary LSAs are re-injected into different areas, the LSA type never changes, but the
cost and advertising router details do change.

ASBR Summary (Type 4): ASBR Summary LSAs describe the router-id of ASBR routers
located in remote areas. These LSAs are sent by the ABR attached to the area in which
the ASBR is located to other OSPF areas (interarea). Note that as ASBR summary LSAs
are re-injected into different areas, the LSA type never changes, but the cost and
advertising router details do change.

Continued on the next page.

www.juniper.net OSPF Areas . Chapter 3-9

Advanced Junos Service Provider Routing

An Overview of LSA Packet Types (contd.)

External (Type 5): External LSAs describe IP prefixes redistributed from other routing
protocols, such as RIP, BGP, or even static routes. These LSAs are sent by ASBRs
Injecting the external routes into OSPF. By default, the Junos OS marks these LSAs with
the Type 2 designation, which means the cost of the associated OSPF route is not
added. You can alter this default behavior and mark these external prefixes with the
Type 1 designation, which means the cost to the ASBR will be included. External LSAs
are flooded to all OSPF areas except areas defined as stub areas.

NSSA External (Type 7): NSSA External LSAs are similar to External LSAs (Type 5)
because they describe IP prefixes redistributed from other routing protocols, such as
RIP, BGP, or even static routes. These LSAs are sent by ASBRs In NSSA areas. These
LSAs are translated to Type 5 LSAs by the ABR attached to NSSA area in which the Type
7 LSAs originate.

In addition to the LSA types already discussed, the OSPF specification also Includes the following LSA
types:
Type 6: Multicast OSPF LSA;

Type 8: External attributes LSA;

.
TyP6 9: Opaque LSA (link scope);

Type 10: Opaque LSA (area scope-used for traffic engineering); and

Type 11: Opaque LSA (AS scope).

Chapter 3-10 . OSPF Areas www.Juniper.net

 Advanced Junes Service Provider Routing

Jlgsnias OSPF Areas

Review of OSPF Areas

-

> Stub Area Operation

Stub Area Configuration
NSSA Operation
NSSA Configuration
Route Summarization

Stub Area Operation

The siide highlights the topic we discuss next.

www.Juniper.net OSPF Areas . Chapter 3-11

Advanced Junos Service Provider Routing

External
Routes

Area 0
Backbone Injected
(0,0.0.0) Area 0
LSA1 LSA2
LSA5
Area r
LSAS

Area 1 Area 2 Area 3

lSA 3 LSA3 LSA 4

/ Area 1 Area 1 Area 2 Area 2

Area 3
LSA1
Area 3
LSA 2

/
i Area 0
.
dA i LSA 2 LSA1

Area 0
LSA 2

f Area 0 Area 0
Area 0
LSA 3 LSA 3 LSA 4 LSA 3
LSA 41 ; LSA 4

Area 2 A:eu 1 Area 1 Area 2

Area 3 Area 3
LSAS LSA 3 LSAS LSA 3
LSA 4 LSA 4

Area 3 Area 3
LSAS LSAS
/
Area 0
LSAS
Area 3
LSA h
X Area 0
LSAn
Areas /External
LSAS
Houtes
1

\
AreaO
LSA c
__
Area 3
LSA 5
I
\ IArea 1 Area 2
Injected Vl 3 /

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.

Chapter 3-12 . OSPF Areas www.juniper.net

 Advanced Junos Service Provider Routing

OSPF Stub Areas

Reduces the size of the LSDB

.
ABR does not inject Type 4 LSA into area
.
ABR does not flood Type 5 LSA into area
Reachability for routes external to OSPF is achieved
using a 0/0 default route injected by the ABR
.
Manual configuration step for added administrator control
ASBR in a stub area cannot flood LSAs for external
routes

Virtual links cannot transit a stub area

Reduce Link-State Database Size

The operation of an OSPF stub area reduces the size of the link-state database within that area by
'

eliminating AS external routing information. When all of an area s 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 due to 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; this 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.
Continued on the next page.

www.juniper.net OSPF Areas . Chapter 3-13

Advanced Junos Service Provider Routing

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.

Chapter 3-14 « OSPF Areas www.Juniper.net

 Advanced Junos Service Provider Routing

ea External
Routes
Backbone
Area 0 Area 0 Injected
(0,0.0.0) AreaO
LSA1 LSA 2

Area
/An 1
LSA1

Area 0
LSA 3 LSA 4 LSA 3
LSA 3 LSA 3 LSA 4

Area 1 Area 1 Area 2

Area 3 AreaS
LSAS LSAS LSAS
LSAS LSA 4

Area 3
LSAS

No

Type 5
\ Area 0
LSA 5
Area -
LSA 5 External
Area 3
LSA 5
/
Stub LSAs Alca A
Routes Area S

here! Injected

Stub Area Flooding Scopes

In this example, Area 1 is now configured as a stub area. This 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 OSPF Areas . Chapter 3-15

Advanced Junos Service Provider Routing

Further reduces the size of the link-state database

.
ABR does not inject Type 3 LSA into area
.
ABR does not inject Type 4 LSA into area
.
ABR does not flood Type 5 LSA into area

Reachability for external routes is available using a

0/0 default route injected by the ABR
.
Again, a manual configuration step exists for administrator
control

ASBR in a no-summaries area cannot flood LSAs

for external routes

Virtual links cannot transit a no-summaries area

JUfllpef WaridwWw EiluunUun Smii:es

Further Reduces Link-State Database Size

The operation of an OSPFstub area with no summaries further reduces the size of the LSDB within
that area by aiso omitting Type 3 summary LSAs. This behavior has the effect of the routers within
the area oniy 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.

ABR Provides Reachability

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.

Chapter 3-16 . OSPF Areas www.juniper.net

 Advanced Junes Service Provider Routing

External
Routes
Backbone
Area 0 AreaO
Injected
LSA2
(0.0.0.0)
LSAl
LSAS

Area 1 Area 2 R2 Area 3

LSA 3 LSAS LSA 3 No Type 5
V
or Type 3
/ \ LSAs!
R4 \
f Area 1 Area 1 Area 2 Area 2 Area 3 Area 3
/ LSA1 LSA 2 LSAl LSA 2 LSAl LSA 2
F

Area 0 Area 2 Area 0 Area 0

LSA 3 LSA 3 LSA 3 LSA 4

Area 3
i f -
1I
Area 1
LSAS
Area 3
LSAS

R7
Area 0 Areas
/Type 5 LSAS Stub With
/ LSAs / External- Mo Summaries

Area 1 from Area Routes

Stub Area 2
Oonly! Injected

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 3's 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 router's 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 OSPF Areas . Chapter 3-17

Advanced Junes Service Provider Routing

Review of OSPF Areas

Stub Area Operation

Stub Area Configuration
NSSA Operation
NSSA Configuration
Route Summarization

Stub Area Configuration

The slide highlights the topic we discuss next.

Chapter 3-18 . OSPF Areas www.juniper.net

 Advanced Junes Service Provider Routing

Area ©nfiguration

All routers in a stub area must be configured as

stub routers
The ABR injects a default route when the
default-metric statement is added
.
A default route is not automatically generated!
[edit protocols ospf]
user@area-l-router# set area 1 stub
user@area-l-router# show
area O.O.Q.1 {
FstuFn
interface so-0/0/0.0;
}

[edit protocols ospf]

user@area-l-abr# set area 1 stub default-metric 10
user@area-l-abr# show
area Q.0.0.1 {
stub I default-metr j _
lb j
J

interface so-0/1/1.0;
}

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 £ 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 match-hence, 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 OSPF Areas . Chapter 3-19

Advanced Junes Service Provider Routing

mmm:;m Area

Only ABRs are configured to support stub areas

with no summaries

The ABR can inject a default route when the

default-metric statement is included
. Like a conventional stub area, the default route is not
generated automatically
[edit protocols ospf]
user@area-l-abr# set area 1 stub no-summaries
user@area-l-abr# show
area 0.Q.Q.I {
[stub default-metric 10 no-suimnaries;
interface so-Q/1/1.0;
}

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 area's 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.

ABR Injects a Default Route

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.

Chapter 3-20 . OSPF Areas www.juniper.net

 Advanced Junos Service Provider Routing

PF Areas

Review of OSPF Areas

Stub Area Operation

Stub Area Configuration
-

>NSSA Operation
NSSA Configuration
Route Summarization

Worldwide EducationServiees uuvi"; juniper ne? [

NSSA Operation
The slide highlights the topic we discuss next.

www.Juniper.net OSPF Areas . Chapter 3-21

Advanced Junos Service Provider Routing

Not itiiiibfAirdaa

Allows a stub area to contain external routing

information from a local ASBR
.
ASBR injects Type 7 LSAs into NSSA
.
ABR converts Type 7 LSAs into Type 5 LSAs and floods them
into the backbone

Reachability for other external routes is available

through a 0/0 default route injected by the ABR
.
Manual configuration step for administrator control
.
Advertised in a Type 7 LSA (Type 3 with no-summaries)
Virtual links cannot transit an NSSA

_ ; \

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.

ABR Provides Reachability

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-suiranaries 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.

Chapter 3-22 . OSPF Areas www.juniper.net

 Advanced Junes Service Provider Routing

LSA Fl h and r External

Routes
Backbone
Area 0 Area 0 Injected
(0.0.0.0) Area 0
LSA 5

Area 3
LSA 5

Area 1 Area 2 Area 3 AreaS

LSA 3 LSA 3 LSA 4 - Ndlrype 5s,
New Type 7
LSAs!
Area 1 Area 1 Area 3
LSA : LSA 2

Area 0
Area 0 Area 3 LSA 3 Area 0 Area 1
LSAS LSAS LSA 4 LSAS
Area 1
Area 2
Area 2 LSAS Area 3
LSAS
LSAS LSA 4
Area 3
LSA 3
R7
Area 3
Area 3 Area 0
LSA 7
'
External
Area 1 Area 3
oType 5 or Routes .

Area 2 ISSA
Type 7 LSAs! Injected

nde Educat onServioes

NSSA Flooding Scopes

Area 3 now is 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 OSPF Areas . Chapter 3-23

Advanced Junos Service Provider Routing

no-summaries

Behaves like a stub area with no-summaries

.
ABR does not inject Type 3 LSAfrom backbone into area
.
ASBR injects Type 7 LSAs into NSSA
»ABR converts Type 7 to Type 5 and floods into backbone
Reachability for other external routes is available
through a 0/0 default route injected by the ABR
.
Again, a manual configuration step for administrator control
.
A Type 3 summary LSA is the default
Virtual links cannot transit an NSSA with
no - s ummari e s

Qf Wntlclwicls Education Services

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.

ABR Provides Reachability

The routers within the NSSA with no summaries might require IP reachability to routes they no longer
have intheir databases. A 0.0.0.0/0 Type 3 LSA is generated by theABRsto 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.

Chapter 3-24 . OSPF Areas www.juniper.net

 Advanced Junes Service Provider Routing

External
Routes
Backbone
Area 0 Area 0 Injected
(0.0.0,0) Area 0
LSA2

Area 3
LSA5

Area 1 Area 2 Area3 Area 3

LSA3 LSA3 LSA4
Intra-Area
LSAsOnly!
area 3 . Area 3
Area 1 Area 2 Area 2
LSA1 LSA 2
LSA 2

Area 0 Area 0
Area 0 Area 2 LSA 4
LSA 3

Area 1 Area 3
Area 3 Area 3
LSA 3 LSA 4
LSA 3 LSA 7

Area3

Area 3
Area 3 Area 0 NSbA
External
LSA 5 LSA 5
Area 1 Routes Summaries
Stub Area 2
LSAs!
Injected

NSSA with No Summaries Flooding Scopes

Area 3 is now configured as a not-so-stubby area with no summaries. In addition to the functionality
described on a previous slide, the ABR of Area 3 stops generating Type 3 summary LSAsfrom Area 0.

www.Juniper.net OSPF Areas . Chapter 3-25

Advanced Junes Service Provider Routing

Agenda: OSPF Areas

Review of OSPF Areas

Stub Area Operation

Stub Area Configuration
NSSA Operation
-

>NSSA Configuration
Route Summarization

.-. -

NSSA Configuration
The slide highlights the topic we discuss next.

Chapter 3-26 . OSPF Areas www.juniper.net

 Advanced Junos Service Provider Routing

NS - 1 m

You must configure each router in the area as an

NSSA router

The ABR can inject a default route when the

default-metric statement is added
.
Specified within the default-lsa configuration hierarchy

[edit protocols ospf area 0.0.0.1]

user@area-l-router# show
nssa

interface so-0/0/0.0;

[edit protocols ospf area 0.0.0.1]

user@area-l-abr# show
_____
j.
default-lsa default-metric 10;
}
interface so-0/1/1.0;

j
Configuration on All Routers
To operate an OSPF NSSA successfully, you must configure each routerto 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
match-hence, the requirement that all routers perform the configuration.

ABR Injects a Default Route

The ABR of the NSSA can optionally inject a 0.0.0.0/0 default route into the area. Within the
def ault-lsa configuration hierarchy, the def ault-metric command accomplishes this. The
command causes the ABR to generate a Type 7 NSSA External Links LSAto 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 OSPF Areas . Chapter 3-27

Advanced Junos Service Provider Routing

Only the ABR is configured to support a

no-s-uiranaries area

The ABR can inject a default route when the

default-metrie statement is included
.
Specified within the default-lsa configuration hierarchy
Default behavior generates a Type 3 summary LSA
.
External Type 1 NSSA changed to external Type 2 with
metric-type keyword

[edit protocols ospf]

user@area-l-abr# show
area 0.0.0.1 {
nssa {
default-lsa {
default-metric 10;
metric-type 2;

no-summaries;

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 piace only on this routerto 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.

ABR Injects a Default Route

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. This 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.

Continued on the next page.

Chapter 3-28 . OSPF Areas www.juniper.net

 Advanced Junos Service Provider Routing

Type 3 LSA Generated by Default (contd.)

The Type 7 LSA is advertised using a External Type 1 (El) 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 def ault-lsa hierarchy. The Type 7 LSA is then
advertised using a External Type 2 (E2) metric, which means that each area router uses only the
advertised metric of the route.

www.juniper.net OSPF Areas . Chapter 3-29

Advanced Junos Service Provider Routing

Agenda;; \ .

*
Review of OSPF Areas

Stub Area Operation

Stub Area Configuration
NSSA Operation
NSSA Configuration
-
> Route Summarization

Route Summarization

This slide highlights the topic we discuss next.

Chapter 3-30 . OSPF Areas www.juniper.net

 Advanced Junes Service Provider Routing

By default, all local area routes are forwarded to the

backbone
.
Stub setting only changes what enters an area, not what
leaves that area

Use the area-range command to summarize

routing information
.
Can result in a single Type 3 LSA injected into the backbone
.
Configured on the ABRs only
[edit protocols ospf]
user@router# set area 1 area-range 192.168.16/20

[edit protocols ospf]

user@router# show
area 0.0.0.1 {
jjarea-range 192.168.16.0/2 0; j
interface at-1/0/1.100;
}

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 land 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. This 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 OSPF Areas . Chapter 3-31

Advanced Junos Service Provider Routing

Summarizing Routes for NSSA

The Junos OS forwards all ASBR Type 7 routes to the

backbone by default
Use the area-range command within the NSSA
configuration to summarize routing information
.
Injects a Type 5 LSA into the backbone
.
Configured on ABRs only
[edit protocols ospf]
user@router# set area 1 nssa area-range 192.168.16/20

[edit protocols ospf]

user@router# show
area 0.0.0.1 {
nssa {
default-lsa default-metric 10;
Tarea-range192Tl68]16.0/2 0T1
}
interface so-O/l/l.O;
}

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 here is specific to the NSSA configuration
hierarchy and only affects 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.

Chapter 3-32 . OSPF Areas www.juniper.net

 Advanced Junos Sen/ice Provider Routing

lestricting Blocks cf Routes

Adding the restrict keyword to the area-range

command stops routes in that range from entering
the backbone
.
No Type 3 LSA will be injected into the backbone
.
Configured on the ABRs only
.
Allows greater control over what routes are advertised to
other areas
.
Can support security or policy based routing applications
[edit protocols ospf]
user@router# set area 1 area-range 192.168.16/20 restrict

[edit protocols ospf]

user@router# show
area 0.0.0.1 {
area-range 192.168.16.0/20 restrict
interface at-1/0/1.100;
}

WarldwklB Education Services

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 fails 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 OSPF Areas . Chapter 3-33

Advanced Junes Service Provider Routing

orgies r

Adding the restrict keyword to the area-range

command stops routes in that range from entering
the backbone
.
No Type 5 LSA is injected into the backbone
.
Configured on ABRs only
[edit protocols ospf]
useE@router# set area 1 nssa area-range 192.168.16/20 restrict

[edit protocols ospf]

user@router# show
area 0.0.0.1 {
nssa {
default-lsa default-metric 10;
area-range 192.168.16.0/20 [restrict}
}
interface so-0/1/1.0;
}

ILJl |!P( 1 rt'orldwido I clui I Services

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.

Chapter 3-34 . OSPF Areas www.juniper.net

 Advanced Junes Service Provider Routing

Summary

In this chapter, we:

.
Described OSPF area types and operations
.
Configured various OSPF area types
. Learned to summarize and restrict routes

This Chapter Discussed:

.
OSPF area types and operations;

The configuration of various OSPF area types; and

The summarization and restriction of routes.

www.juniper.net OSPF Areas . Chapter 3-35

Advanced Junes Service Provider Routing

Review Questions

1 . Which LSA types are not forwarded into an OSPF

stub area or NSSA? Which router accomplishes this
action? Which LSA types are not forwarded into an
OSPF NSSA with no summaries?

2 . Which routers must you configure to support a stub

area or NSSA?

3 .
How do routers in a stub area or NSSA reach
addresses outside of the OSPF domain?

4 .
Which OSPF areas see the effect of the
area-range command?

Review Questions
i .

Chapter 3-36 . OSPF Areas www.juniper.net

 Advanced Junos Service Provider Routing

Lab 2s CoifIgurlng ar. toring OSPF

Areas and M Sum 1 ization

Configure, monitor, and troubleshoot the operation of

OSPF stub areas.

Configure, monitor, and troubleshoot the operation of

an OSPF network using not-so-stubby areas.
*
Configure monitor, and troubleshoot address
,

summarization with and without restrictions.

Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization

The siide provides the objectives for this lab.

www.Juniper.net OSPF Areas . Chapter 3-37

Advanced Junos Service Provider Routing

Chapter 3-38 . OSPF Areas www.juniper.net

jumper NETWORKS

Advanced Junos Service Provider

Routing

Chapter 4: OSPF Case Studies and Solutions

Advanced Junes Service Provider Routing

lm Objectives

After successfully completing this chapter, you will be

able to:
.
Configure OSPF virtual links
.
Configure OSPF multiarea adjacency
.
Explain OSPF external reachability

This Chapter Discusses:

Configuring OSPF virtual links;
.
Configuring OSPF multiarea adjacencies; and

OSPF external reachability.

Chapter 4-2 . OSPF Case Studies and Solutions www.junlper.net

 Advanced Junos Service Provider Routing

>Virtual Links

OSPF Multiarea Adjacencies

External Reachability

Virtual Links

The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.juniper.net OSPF Case Studies and Solutions . Chapter 4-3

 Advanced Junes Service Provider Routing

fschnical OSPF (1 of 5)

Area border router

.
Connects multiple OSPF areas

R4
ri -10.200.1.1
: :
-

R2 - 10.200.1.2
R3 - 10.200.1.3 Area 1 fc t-J Area 2

R4 - 10.200.1.4 R5

R5 - 10.200.1.5

. Is R3 an area border router?

1 de Education Servioes
L _

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?

Chapter 4-4 . OSPF Case Studies and Solutions www.juniper.net

 Advanced Junes Service Provider Routing

fee : mm 3

The Type 1 router LSA provides the answer

. The ABR bit is set

ri -10.200.1.1 Ri

R2 - 10.200.1.2
R3 - 10.200.1.3 Area 1 Area 2

R4 - 10.200.1.4 R2

R5 - 10.200.1.5

[edit]
use3:@R3# show ospf database
OSPF link state database. Area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10.200.1.3 10.200.1.3 0x80000004 326 0x22 0xl2f8 60
jbits 0x1, j link count 3
id 10.200.11.1, data 10.200.11.2, Type Transit (2)
TOS count 0, TOS 0 metric 1
id 10.200.12.1, data 10.200.12.2, Type Transit (2)
TOS count 0, TOS 0 metric 1
id 10.200.1.3, data 255.255.255.255, Type Stub (3)
TOS count 0, TOS 0 metric 0

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 router (ASBR) routers.

www.juniper.net OSPF Case Studies and Solutions . Chapter 4-5

Advanced Junos Service Provider Routing

cal

All routers have connectivity through the Type 3

summary LSA created by the ABR
Rl - 10.200.1.1 i

R2 - 10.200.1.2
R3 - 10.200.1.3 Area 1 Area 2

R4 - 10.200.1.4
R5
R5 - 10.200.1.5

usei:@R5> sliow route protocol ospf

inet.O: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)

+ - Active Route, - - Last Active, * = Both

10.2GQ.1.1/32 *[OSPP/10] 00:08:20, metric 2

> to 10.200.14.2 via £b-0/0/0.224
10.200.1.2/32 '[OSEF/ID] 00:08:20, metric 2
> to 10.200.14.2 via £e-Q/0/0.224
10.200.1.3/32 *[OSPF/10] 00:08:20, metric 1
> to 10.200.14.2 via fe-0/0/0.Z24
10.200.1.4/32 *[OSEF/lD] 00:07:50, metric 1
> to 10.200.15.1 via fe-0/0/0.225

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.

Chapter 4-6 . OSPF Case Studies and Solutions www.juniper.net

 Advanced Junos Service Provider Routing

Technical OSFF (4 of S)

Now connect R5 into OSPF Area 0

Rl - 10.200.1.1
R2 - 10.200.1.2
R3 - 10.200.1.3
R4 - 10.200.1.4
R5 - 10.200.1.5

useriaR5> show route protocol ospf

inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)

+ = Active Route, - - Last Active, * = Both

ID.200.1.4/32 *[OSEF/10] 00:28:34, metric 1

> to 10.200.IS.1 via fe-0/0/0.225
10.200.1.6/32 *[OSPF/10] 00:01:45, metric 1
> to 10.200.IS.Z via fe-0/0/0.22S

What happened to the routes to Rl and R2?

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 Rland R2 disappear from the routing
table.

www.juniper.net OSPF Case Studies and Solutions . Chapter 4-7

Advanced Junes Service Provider Routing

Technical OSFF (S of S)

The summary LSAs are in the database

userl3R5> show ospf database netsummary axea 0.0.0.2

OSPF link state database, Acea 0.0.0.2

Type ID Adv Rtr Seq Age Opt Cksum Len

Summary 10.200 1 1
. 10.200.1.3 0x80000002 1083 0x22 0xd6b8 28

Sunmiacy 10.200 1 2
. 10.200.1.3 0x80000002 876 0x22 Oxcccl 28

Summary 10.200 1 3
. 10.200.1.3 0x80000002 148 3 0x22 0xi)8d5 28
*
Summary 10.200 1 6
. 10.200.1.5 0x80000001 272 0x22 OxSaee 28

Summary 10.200 10.0 10.200.1.3 0x80000002 783 0x22 0xS7fe 28

Summary 10.zoo 11.0 10.200.1.3 0x80000003 1383 0x22 0x7015 28
Summary 10.200 12.0 10.200.1.3 0x80000003 117 6 0x22 0xS51t 28
Summary 10.zoo IS. D 10.200.1.5 0x80000002 272 0x22 0x2f50 ZS

However, SPF is not installing them

u3er(3R5> show ospf iroute

Prefix Path Route NH Metric Nexthop Nexthop

Type Type Type Interface addr/label
10.200 1 3
.
Intra Area BR IP 1 fe-0/0/0.224 10.200.14.Z
10.200 1 4
.
Intra Router IP 1 fe-O/0/0.225 ID.200.15.1
10.200 1 6
.
Intra Router IP 1 fe-0/0/0.226 10.200.15.2
10.200 1 4/32
.
Intra Network IP 1 fe-0/0/0.225 10.200.15.1
10.200 1 5/32
. Intra Network IP 0 loO.O
10.200 1 S/32
. Intra Network IP 1 fe-0/0/0.226 10.200.16.Z

B Educations

Summary LSAs Are Still Present

Buiiding on the previous slide and issuing a show ospf database netsuiranary command, the
summary LSAs are present on R5 for Rl 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 LSA's are present in the OSPF database, a show ospf route command does
not show the routes to Rland R2. The SPF calculation Is removing those entries in its decision tree.
The loop detection mechanism in OSPF causes this action. Essentiaiiy, 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 Rl and R2, it ignores the summary LSA.

Chapter 4-8 . OSPF Case Studies and Solutions www.juniper.net

 Advanced Junes Service Provider Routing

Wmmmvmm )

Technical OSPF
« An ABR not connected to Area 0

No loop detection mechanism

.
SPFwill process all LSAsin all areas
Functional OSPF
.
The ABR must be connected to Area 0
.
SPFwill process all LSAs in the area 0 database
.
SPF will only process Type 1 and Type 2 LSAs in all other areas
attached to the ABR

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 ail attached areas and will run SPF for
"
each area. (Section 3.3)

Technically, you can create 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 OSPF Case Studies and Solutions . Chapter 4-9

Advanced Junes Service Provider Routing

Company acquisitions and mergers

.
Integrating multiple OSPF networks
.
OSPF requires a stable contiguous backbone
-

Unpredictable results
-

Loops
-

Missing routes
.
Can require temporary solutions
-
Virtual tunnels
. Permanentsolutions
-

Physical connectivity

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 O s together to form a single contiguous backbone. The
easiest solution will be new physical connections between the routers in each company. However,
this Is often easier said then done, and time can be a deciding factor. For these cases, a temporary
solution such as virtual tunnels or virtual links can be deployed.

Chapter 4-10 . OSPF Case Studies and Solutions www.junlper.net

 Advanced Junos Service Provider Routing

Wtym

Corporate
Headquarters Service
0315
Center
Distribution
Center
I
: OSPF OSPF
Area 0 Area 20

V Training ISPB
iit;i
Corpora
Net-vo Sales Off 7
o
OSPF
Area 0
Center

Dlstributiid
Distrib ution
.

Center
Center
"

OSPF
rea 100

Sale; Frame Relay Sales/Sen/ice

Center
Office OSPF
OSPF
Area 10 OSPF
Sa les/Service Area 400
Area 200
Center OSPF
Area 300
Sales/Service
ISP A Center
beiYice Sales/Semoe
Center

Case Study
in this case study, Petroleum Inc. (ISP A) acquires Bob's Oil and Gas (ISP B). Both networks are
running muitiarea OSPF, and they must get the two networks communicating quickly.

www.junlper.net OSPF Case Studies and Solutions . Chapter 4-11

Advanced Junos Service Provider Routing

Case Study is Virtual; is it of 4)

ISP A has made an offer for ISP B

.
An integration team has been formed
.
Study corporate philosophies
. Consolidate distribution centers
.
Integrate sales and service centers
.
Initial focus will require network connectivity
.
Corporate office interoperability
.
Physical connectivity is not an option
-

Fundingwill not be available until acquisition is complete

.
Physical locations of existing network components
-

A distribution center and sales/service center are co-located

«(l8 Education Services :

. wwwjunlper.net j 41

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. During the examination, it was determined that
connecting the two Area 0 networks together with physical connections was not a short term option,
due to the cost of the additional links as well as the time constraints of the project. An alternative
solution had to be found.

Chapter 4-12 . OSPF Case Studies and Solutions www.juniper.net

 Advanced Junos Service Provider Routing

Corporate
Io0i72 lh :n :-;
Headquarter
Data 100172.16.10.1 csn
Center
Distribution
Center
OSPF OSPF
Area 0 Area 20
ISPB
Corporate
Office
Sales
Network "

an n Office
-

Operation Center
Io0172?i6
Distributioh-
Cepter
Area 100 12
.

Frame Relay
Office DSP
Sales/Sen/ice OSPF Area 400
Center Area 200/ qSPF Sa les/Beivice
Cente

ISPA Sen/ice Center

s-ales/Sen/ice
loO 172.16.20.3 Center
Center

Wor dw t e Educat on Sen. ces

Initial Physical Connection

The first step is to establish some physical connectivity between the two companies. In this case,
they chose to connect a service center and a sales center.

www.Juniper.net OSPF Case Studies and Solutions . Chapter 4-13

Advanced Junes Service Provider Routing

Case Study Is Virtual Links (4 of 4)

Technical OSPF provides connectivity

.
The sales office has connectivity
taob@Aus-tin> ping 172.16.10.1 rapid
PING 172.IS.10.1 (172.16.10.1): 56 data bytes
! ! ! ! !
172 16.10.1 ping statistics
.

5 packets tcansmitted, 5 packets received, OS packet loss

round-trip min/avg/max/stddev = 2.7 97/3.123/3.904/0.400 ms

bota@Austin> ping 192.168.1.1 rapid

PIMS 192.168.1.1 (192.168.1.1); 56 data bytes
11 11!
192 168.1.1 ping statistics
.

5 packets transmitted, 5 packets received, OS packet loss

round-trip min/avg/max/stddev = 4.869/5.131/5.873/0.378 ma
.
The corporate offices, however, cannot connect
bob@Corporate> ping 172.16.10.1
PING 172.16.10.1 (172.16.10.1): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host

Connectivity Issues
As soon as the physical connection is created, limited connectivity is achieved. For example, the
'
sales office at Bob s (ISP B) can reach the neighbor router, but the corporate routers cannot. The
cause of this limited connectivity is the lack of a contiguous Area 0 backbone.

Chapter 4-14 . OSPF Case Studies and Solutions www.juniper.net

 Advanced Junes Service Provider Routing

Virtual funnel (1 of 2)

Virtual link
.
Provides a logical connection
.
Used for areas not physically connected to Area 0
.
Usedto connecta discontiguous Area 0
.
Tunnels OSPF packets through a transit area
. Creates a virtual ABRto remote routers
.
Configuration on both ends of the tunnel
.
Control plane only
.
SPFwill calculate the shortest path to all routes

Virtual Tunnels

One soiution 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. SPFwill still calculate the shortest
physical path between two points, which might not be the same path as the virtual tunnel. This could
create some confusion when troubleshooting, which is one of the primary reasons virtual tunnels are
not considered long term solutions.

www.juniper.net OSPF Case Studies and Solutions . Chapter 4-15

Advanced Junos Service Provider Routing

of

Corporate
100172.16.10.3
Headquarters Sewice
Cc.rci [00172.18.10.1 nter
Center
Distribution
v
Uonter

OSPF OSPF
Area 0 Area 20
ISPB
Corporate
Offi
TrainingCenter Sales oO 192.168.1
Networ PR
Off!
Operation Center 100172.16.10.2 Area 0 ;

!00172.16.10.4 \
Distribution Center
Z Distribution
oO 172.16.20 Center
OSPF les/Setvice
A -ea 10 Center S 100192.168.1.2

Saies Frame Relav

Office
100172.16.20.2 OSPF
Area 400
Area 200 OSPF
Area 300
ioO 192.168.10.1

ISPAi .... Sen/ice Cen

ivice Center
IoO 172.16.20,3 Sa ies/Service Sa les/Sen/ice
Center Center

rie Education Services i,w>tunipernci i 4-is

Virtual Link Established

In this case, a virtual link is established between ABRs in each company. These ABRs must be
attached to Area 0.

Chapter 4-16 . OSPF Case Studies and Solutions www.juniper.net

 Advanced Junos Service Provider Routing

Configure a virtual link in Area 0

bobi3CorpoEate# show protocol ospf
ospf i
area 0.0.0.0 {
virtual-link neighbor-id 172.16.10.2 transit-area 0.0.0.10;
interface loO.0;
interface fe-0/0/0.101;
interface fe-0/0/0.103;
)
area 0.0.0.10 {
interface tl-O/Q/2.0;
}

Verify the virtual link

bota@Gorporate> show ospf interface
Interface State Area DR ID BDR ID Wbrs
loO.O DR 0 0 0 0
. . .
192.169.1.1 0 0 . D O
.
0

fe-0/0/0.1Dl BDR 0 0 0 0
. . . 192.168.1.2 192 168.1 1 1
BDR 0 0 0 0
. . . 192.168.1.3 192 168.1 1 1

|vl-172.16.10.2| PtToPt 0 0 0 0
. . .
0 0 0 0
. . .
0 0 .
0 0
.
1
tl-0/O/Z.O PtToPt 0 0 0 10
. . .
0 0 0 0
. . . 0 0 .
0 0
.
1

bob@Corporate> show ospf neighbor

Address Interface State ID Pri Dead
192.168.3.6 fB-0/0/0.101 Full 192 168.1.2 128 34
192.168.3.10 fe-0/0/0.103 Full 192 168.1.3 128 34
172.16.11.1 | vl-172.16.10.2 Full 172 16.10.2 0 34
192.16B.3.2 Full 192 168.10.1 128 32

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 OSPF Case Studies and Solutions . Chapter 4-17

Advanced Junes Service Provider Routing

Mmk urat

Contiguous Area 0
.
Type 1 LSAs are exchanged over the tunnel
bob8Corporate> show ospf clatatoase

OSPF link staCe database,. Area 0.0.0.0

Type IC JLdv Rtr Seq Age Opt Cksum Len
Roucer 172.16.10.1 172 .
16.10.1 0x80000129 1721 0x22 0xd61f 48
Router 172.16.10.2 172 . 16.10.2 0x80000102 2116 0x22 0x4c43 60
Router 172.16.10.3 172 . 16.10.3 OxSOOOOOcd 1991 0x22 0xb891 48
Router 172.16.10.4 172 .
16.10.4 OxOOOOOOob 1986 0x22 0xd077 4G
Router ' 192.168.1.1 192 .
168.1.1 0x8000016e 2115 0x22 0xc83e 72
Router 192.158.1.2 192 . 168.1.2 OxSOOOOOcd 2117 0x22 0x7bac 60
Router 192.168.1.3 192 . 168.1.3 0x80000289 355 0x22 0x92cd 60

.
Routes are installed in the routing table
bob@CorpDi:ate> show route protocol ospf

inet-.O: 25 destinations, 2 6 routes (25 active, 0 holddown, 0 hidden)

f = Active Route, - = Last- Active, * = Both

172.16.10.1/32 *[03PF/10J 01:31:28, metric 68

> via tl-O/D/2.0
172.16.10.2/32 *[OSPF/10] 01:31:28, ntetric 57
> via tl-0/0/2.0
172.16.10.3/32 -[OSPF/10] 01:31:28, metric 68
> via tl-0/0/2.0
172.16.10.4/32 *[03PF/10] 01:31:28, metric 68
> via tl-0/0/2.

; Education Services

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.

Chapter 4-18 . OSPF Case Studies and Solutions www.juniper.net

 Advanced Junes Service Provider Routing

Agenda: OSPF Case Studies ami Solutions

Virtual Links
-

>OSPF Multiarea Adjacencies

External Reachability

OSPF Multiarea Adjacencies

The slide highlights the topic we discuss next.

www.juniper.net OSPF Case Studies and Solutions . Chapter 4-19

Advanced Junes Service Provider Routing

Multiple adjacencies belonging to different areas

.
Configured on the ABR
.
Each multiarea adjacency is announced in the Type 1 LSA as a
point-to-point link
.
No Type 3 link (stub) is advertised for multiarea adjacency
.
Control plane path for multiarea adjacency

ivotlilwide [ din
.
ii .iii Services

Multiarea Adjacencies
RFC 5185 defines muitiarea OSPF adjacencies as the following:
"

Multi-area adjacencies are configured between two routers having a common

interface. On point-to-point interfaces, there is no need to configure the neighbor's
address since there can be only one neighbor. For all other network types, the neighbor
address of each multi-area adjacency must be configured as a point-to-point interfaces.
OSPF control packets are sent to the AIISPFRouters address. For all other network
types, OSPF control packets are unicasttothe remote neighbor's IP address."

Chapter 4-20 . OSPF Case Studies and Solutions www.juniper.net

 Advanced Junos Service Provider Routing

mwm :ency (1 m

Case study topology

c Ri
SPF Area 0
PS

Traffic to
loO.O 192.163.10.2
loO.O 192.168.10.1

OSPF Area 100

Rl
Rl -- R2:
R2: 10.:
10.200,1/24
Rl
Rl -- R3:
R3: 10.:
10.200.2/24
Rl
Rl -- R4: 10.:
R4: 10.200.3/24 R

R2 - R3: 10.:
10.200.4/24
R2
R2 -- R4:
R4: 10.:
10,200.5/24
loO.O 10.200.0.1 loO.O 10.200.0.2

Case Study
The slide displays the case study topology.

www.juniper.net OSPF Case Studies and Solutions . Chapter 4-21

Advanced Junes Service Provider Routing

Case if 2: < . rf.;i f (2 of 3)

Traffic flow with a link failure

OSPFArea
Traffic to
loO.O 192,168,10,2
10.200,0.1
loO.O 192,16810,1

Rl - R2: 10,200.1/24
Rl - R3; 10.200,2/24
Rl - R4: 10,200,3/24
R2 - R3: 10,200,4/24
R2 - R4: 10.200.5/24
ioO.O 10.200.0.1 loO.O 10,200,0,2

i < Worldwide Etiuuation Services

Link Failure

In normal operation, if a link failure occurred between Rl and R3, traffic from Rl to R3 would flow
from R4to R2 and then to R3.This creates three hops to reach a router that was previously one hop
away.

Chapter 4-22 . OSPF Case Studies and Solutions www.juniper.net

 Advanced Junos Service Provider Routing

Multiarea adjacency

=
Rl .2
OSPFArea 0
Traffic to 1 1
ioO 0 192.168.10.2
wmor
loO.O 192.168.10.1

OSPFArea 100

Rl - R2:
R2; 10.;
10.200.1/24
Rl - R3: 10.:
10.200.2/24
10.; R3 R
Rl - R4; 10.200.3/24
R2 - R3;
R3: 10.:
10.200.4/24
R2 - R4; 10.200.5/24
10.;

loOO 10,200.0.1 loO.O 10.200.0.2

Link Faiiure with Multiarea Adjacency

With multiarea adjacency configured, a hop to reach R3 is eliminated.

www.juniper.net OSPF Case Studies and Solutions . Chapter 4-23

Advanced Junos Service Provider Routing

Configuring j- ~ r1 v_' f (iof 4]

Verify that the OSPF adjacencies are in full state

user@Rl> show ospf neighbor

Address Interface State ID Pri Dead

ID.200.1.2 ge-1/0/4. 1100 Full 192.1S8.10.2 12 8 33
10.200.2.2 ge-1/0/4. 1101 Full 10.200.0.1 12 8 36
10.200.3.2 ge-1/0/4. 1102 Full 10.200.0.2 128 33

"

user@R2> show ospf neighbor

Address Interface State ID Pri Dead

10.200.1.1 ge-1/1/4. 110 0 Full 192.168.10.1 128 32
10.200.4.2 ge-1/0/4. 1103 Full 10. 200. 0. 1 128 35
10.200.5.2 ge-1/0/4. 1104 Full 10.200.0.2 128 35

Trace 10.200.0.1 from the Rl router

userSRl> traceroute 10.200.0,1

traceroute to 10.200.0.1 (10.200.0.1), 30 hops man, 40 byte packets

1 10.200.0.1 (10.200.0.1) 0.S33 ms 0.376 ms 0.346 ms

Worldwide Education Servides

Adjacency Verification
Verify adjacencies with the show ospf neighbor command.

Normal Trace

For the case study, Rl is one hop away from R3.

Chapter 4-24 . OSPF Case Studies and Solutions www.juniper.net

 Advanced Junos Service Provider Routing

lultiarea Adjacency (2 of 4)

Disable the interface between Rl and R3

user@Rl> show ospf neighbor

Address Interface State ID Pra Dead

10.200.1.2 ge-1/0/4.1100 Full 192.168.10.2 128 35
10.200.3.2 ge-l/G/4. 1102 Full 10.200.0.2 128 33

Again, trace to 10.200.0.1

user@Rl> traceroute 10.200.0.1

traceroute to 10.200.0.1 (10.200.0.1), 30 hops max, 40 byte packets

1 10.200.3.2 (10.200.3.2) 0.462 ms 0.293 ms 0.288 ras
2 10.200.5.1 (10.200.5.1) 0.297 ms 0.295 ms 0.295 ms
3 10.200.0.1 (10.200.0.1) 0.385 ms 0.376 ms 0.368 ms

.
The trace takes the R4 - R2 - R3 path

if Worldwide Education Services

Disable the Interface

To test normal operations, disable the interface between Rl and R3.

Trace Under Link Failure

The trace from Rl to R3 now takes a 3 hop path.

www.juniper.net OSPF Case Studies and Solutions . Chapter 4-25

Advanced Junos Service Provider Routing

Configure the interface between Rl and R2 in

Area 100 as a secondary interface
[edit]
user@Rl# show protocols ospf
ospf (
area D . 0. 0 . 0 {
interface loO.0;
interface gs-1/0/4.1100;
i
area 0 . 0. Q . 100 (
interface ge-l/0/4.1101;
interface ge-l/0/4.1102;
interface ge-l/0/4.1100 (
secondary;

A point-to-point interface is established for Area 100

user@Rl> show ospf interface

Interface State Area DR ID BDR ID Nbrs

ge-l/0/4.1100 BDR 0.0.0.0 192.168.10.2 192.168.10.1 1
loO. 0 DR 0 0 0 0
. . . 132.168.10.1 0 0 0 0
. . .
0
_
""

ge-l/0/4. 1100 ptToPtt 0.0.0.100 0 0 0 0

. . . 0 0 0 0
. . .
1
- -

ge-l/0/4.1102 DR 0 0 0 100
. . . 192.168.10.1 10.200.0.2 1

uildwiilu I Uiicalion Services

Multiarea Adjacency Configuration

To configure multiarea adjacency in the Junos operating system, configure a secondary logica
interface for an OSPF area using the secondary statement. Any iogicai 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 oniy 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.

Chapter 4-26 . OSPF Case Studies and Solutions www.junlper.net

 Advanced Junos Service Provider Routing

Ccinfiguriag Multiare Jacency (4 of 4)

An adjacency is also formed over the point-to-point

interface for Area 100
usereRl> show ospf neighbor

Address Interface State ID Pri Dead

10.200.1. 2 ge-1/0/4.1100 Pull 192.168.10.2 12 8 37
Area 0. 0 0 0
. .

10.200.1. 2 ge-1/0/4. 1100 Full 192.168.10.2 128 37

Area 0. 0 0.100
.

10.200.3. 2 ge-1/0/4. 1102 Full 10.200.0.2 128 37

Area 0. 0 0.100
.

Another trace to 10.200.0.1

user0Rl> traoeroute 10,200.0,1

traceroute to 10,200.0.1 (10.200.0.1), 3D hops max, 40 byte packets

1 10.200.1.2 (10.200.1.2) 0,417 ms 0.295 ms 0.285 ms
2 10.200.0.1 (10.200.0.1) 0.372 ms 0.363 ras 0.350 ms

The trace now takes the R2 - R3 path

if Worldwide Education Setvices

Adjacency Is Formed
Two adjacencies are now formed over ge-i/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 OSPF Case Studies and Solutions . Chapter 4-27

Advanced Junes Service Provider Routing

Virtual Links

OSPF IViultiarea Adjacencies

-

>External Reachability

Qf Wnrltlwide EctuoatiotiServices
_

External Reachability
The slide highlights the topic we discuss next.

Chapter 4-28 . OSPF Case Studies and Solutions www.juniper.net

 Advanced Junes Service Provider Routing

m React

Routes are not redistributed by default

Route redistribution requires an export policy
.
Configured at OSPF global configuration level
.
Type 5 External LSA-Type 1 or Type 2 (default)
[edit]
userQrouterS show policy-options
policy-statement redistribute-statics {
term static-routes {
from protocol static;
then {
external type 1;
accept;
(
)
)
)
[edit]
usergrouter# show protocols ospf
export redistribute-statics;
(

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

In order 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 OSPF Case Studies and Solutions . Chapter 4-29

Advanced Junos Service Provider Routing

Mutual redistribution
.
Redistribution from multiple routers
.
Redistribution from multiple protocols
. Redistribution rule
.
Source route has a lower preference
-

No problem
.
Source route has a higher preference
-

Sub-optimal routing
-

Routing loops

Mutual Redistribution

Special care must be taken when redistribution is configured in a networks 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.

Chapter 4-30 . OSPF Case Studies and Solutions www.junlper.net

 Advanced Junos Service Provider Routing

v eternal Routes (1 of

Case study topology

R5
10010.200.0.3
fe-0/0/1110 , .10010 200 loO 19,200.0.5

OSPFArea 100
SPFArea 0
Not-So-Stubbv-Area

R4 3
10.200.0 loO 10.200.0.4

orlrtv/iileEduciitiunSemccs
-

Case Study Topology

The slide displays the case study topology that will be use in subsequent slides. Rl, R2 and Host A
are all running RIP.

www.Juniper.net OSPF Case Studies and Solutions . Chapter 4-31

Advanced Junes Service Provider Routing

Case study background

.
The RIP router is advertising routes
.
Redistribute a single RIP route into OSPF
-

Advertisethe 20.20.1.0/24 RIP route

. The Rl and R2 routers have an OSPF default route
.
Default route is generated by the ABR
-

A Type 7 LSA is created

. Redistributethe default route into RIP

Worlilwiilu tiluration Sur.iuiis

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.

Chapter 4-32 . OSPF Case Studies and Solutions www.juniper.net

 Advanced Junos Service Provider Routing

Sti- m

Redistribute the RIP route into OSPF

[edit]
userORli show policy-statement redist.ribute-rip
term 1 {
from {
protocol rip;
route-filter 20.20.1.0/24 exact;
)
then accept;
i

A Type 7 LSA is created for the RIP route

user@Rl> show ospf database nssa

MSSA *20.20.1.0 10.200.0.1 Ok80000001 35 0k28 0xe7f0 36

mask 255.255.255.0
Type 2, TOS 0x0, metric 2, fwd addr 10.200.0.1, tag 0.0.0.0

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 iogicai AND. This policy will be applied to both Rl 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 associated with the
RIP route.

www.juniper.net OSPF Case Studies and Solutions . Chapter 4-33

Advanced Junes Service Provider Routing

V tudy xter t

The R4 ABR converts the Type 7 to a Type 5

useir0R4> show ospf database external

OSPF AS SCOPE link state database

Type ID Adv Rtr Seq Age Opt Cksum Len
EHtern *20.20.1. 0 10.200.0.4 0x80000002 1773 0x22 0H4a92 36
mask 255.255.255.0

Type 2, TOS 0x0, metric 2, |fwd addr 10. 200. 0. 1,[ tag 0.0.0.0
The Rl ASBR address is advertised in the forwarding
address of the Type 5 LSA
A Type 4 LSA is created in the Area 0 database
user@Rl> show ospf database asbrsiumnary

OSPP link stats database. Area 0.0.0.0

Type ID Adv Rtr Seq Age Opt Cksum Len
ASBRSum * 10. 2 0 0. 0.1 10.200.0.3 0x80000001 545 0x22 0xdcb4 28
mask 0.0.0.0
TOS 0x0, metric 1
ASBRSum 10.200.0.1 10.200.0.4 0x80000001 546 0x22 0x63eb 26
mask 0.0.0.0
TOS 0x0, metric 66

Wnrldwicle kflucalionSmices

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 ASBR's 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 ABR also create a Type 4 LSA to represent the ASBR to other areas.

Chapter 4-34 . OSPF Case Studies and Solutions www.juniper.net

 Advanced Junos Service Provider Routing

Case Jy Ss External Routes (5 of S)

Redistribute the default route from OSPF into RIP
.
High preference 150 to low preference 100
user@R2> show route 0/0

inat.O: 35 destinations, 38 routes (35 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

0 0 0
. . . 0/0 * [RIB/100] 00:03:18, metric 2, tag 0
> to 10.200.5.2 via fe-0/0/1.210
[OSBE/150] 00:24:48, metric 11, tag 0
> to 10.200.62.9 via fe-0/0/0.221

. The RIP route is the active route

.
Modify the OSPF external preference to 90
[edit]
user@R2# show policy-statement rip-prefexeuce
term 1 (
from (
protocol rip;
route-filter 0.0. 0.0/0 exact;
)
then (
preference 90;
accept;

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 OSPF Case Studies and Solutions . Chapter 4-35

Advanced Junes Service Provider Routing

©as# Stiiiiy m Emmmsi MmAmm ft wf i|

Mutual redistribution
. The default route has been fixed
.
The RIP route is now a higher preference (100) than the
external OSPF preference (90)
usereR2> show route 0/0

inet.O; 35 destinations, 38 routes (35 active, 0 hoiddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

20. 20. 1. 0/24 *

[OSPF/90] 00:03:09, metric Z, tag 0
> via tl-0/0/3. 0
[RIP/100] 00:19:40, metric 2, tag 0
> to 10.200.5.3 via fe-O/D/1.210

The Result

The result of the preference change is now a default that points properly to the ABRs in the NSSA.

Chapter 4-36 . OSPF Case Studies and Solutions www.juniper.net

 Advanced Junes Service Provider Routing

ase Stud IFF Import Policy (1 of 2)

The process of building OSPF routes in the routing

table
.
Based on a modified Dijkstra algorithm
. Link-state database
.
Candidate database
.
Tree database

8 The results of the SPF calculation is in the tree database

user@Rl> show ospf route
Topology default Route Table:

Prefi-K Path Route NH Metric NentHop Nexthop

Type Type Type Interface addr/label
10.200.D.1/32 Intra Network IP 0 loO. 0
10.200.0.2/32 Intra Network IP 65 tl-0/0/3.0
10.200.0.3/32 Inter Network IE 1 fe-0/0/0. 221 10. 200. 62. 9
10.200.0.4/32 Inter Network IP 2 fe-0/D/0.221 10.200. 62. g
10.2DG.D.S/32 Inter Network IP 2 f6-0/0/0.221 10.200.62.9
10.20 0.0.6/32 Inter Network IP 3 fe-G/a/Q.Z21 10.200.62.9
20.20.1.0/24 EKt2 Network IP 2 tl-0/0/3. 0

WprlcJw t)6 Educat ionServices

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.

During the course of this calculation, the algorithm uses three databases-the 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, cost), which describe each link In the network.

www.juniper.net OSPF Case Studies and Solutions . Chapter 4-37

Advanced Junos Service Provider Routing

Case- . F Import Policy (2 of 2)

Import policy is applied between the tree database
and inet.O
.
Can only filter on external routes
[edit]
user(3Eauter# show pplxcy-options
policy-statement ospf-itnport-policy {
term 1 {
f cam {
coute-fliter 2Q.20.1.0/24 exact;
}
then reject;
)
1
)
[edit]
usertSrouterS show protocols
Spf {
external-prefecence 90;
export redistribute-rip;
import ospf-impoct-policy;

user@couter> show route 20.20/16

inet.O: 35 destinations, 37 coutes (35 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active
,
* = Both

20.20.1.0/24 *[RZP/1D0] 00:32:38, metric 2, tag 0

> to 10.200.5.3 via fe-0/0/1.210

'
Sf WoridwtUeEUucationServices wwwiuniperiitt i 4-33

Import Policy
An import policy can be applied between the tree database and the routing table. This 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.

Chapter 4-38 . OSPF Case Studies and Solutions www.juniper.net

 Advanced Junos Service Provider Routing

Protection against flooding too many external routes

.
Type 5 LSA is domain flooded within OSPF
.
One Type 5 LSA per external route
.
Redistribution requires an export policy
.
An incorrect OSPF export policy can inadvertently inject many
external routes
.
The RIP router can suddenly advertise more routes than expected

Worldwide Educatiun Services

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 as 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 export-prefix-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 OSPF Case Studies and Solutions . Chapter 4-39

Advanced Junos Service Provider Routing

Modify the OSPF export policy

[edit]
user@E:out.er# show policy-options
policy-statement redistribute-rip {
term 1 {
from protocol rip;
then accept;

All RIP routes are being redistributed

usergrouter> show ospf database area 0,0.0.2

OSBF li nk state dat< base.

.
Area 0.0.0.2
Type ID Adv Rtr Seq Age Opt Cksum Len
NSSA 0 0 0 0
. . . 10. 200. 0.3 0K80000003 1402 0x20 0x2d24 36
NSSA 0 0 0 0
. . .
10. 200. 0. 4 0x80000003 1453 0x20 0x2729 36
*20.20.0.0
NSSA 10.200. 0. 1 0K8OQ00OO1 10 0x28 0xe7f0 36
*
NSSA 20.20. 1. 0 10.200. 0. 1 0x80000001 1324 0x28 Oxdcfa 36
*
NSSA 2D.20.2.0 10. 200.0.1 0x80000001 10 0x28 OxdlOS 36
*
NSSA 20.20.3. 0 10.200.0.1 0x80000001 10 0x28 0xc60f 36
*
NSSA 20.20. 4. 0 10.200. 0. 1 0x80000001 10 0x28 Dxbbl9 36
*
NSSA 20.20.5. 0 10.200. 0.1 0x80000001 10 0x28 0xb023 36
*
NSSA 20. 20. 6. 0 10.200.0.1 0x80000001 10 0x28 0xa52d 36
NSSA * 20.20.7. 0 10. 200. 0. 1 0x80000001 10 0x28 Qx9a37 36

'
orldwirie Education Services

Modify Policy
To see prefix iimits in action, a policy is modified to send ali RIP routes into OSPF.

RIP Redistribution

This policy causes aii RIP routes to be sent into OSPF.

Chapter 4-40 . OSPF Case Studies and Solutions www.juniper.net

 Advanced Junes Service Provider Routing

An OSPF prefix-limit is configured

[edit]
user@router# show protocols
ospf {
prefiK-eKport-limit 0;
external-preference 90;
export tredistribute-rip;
import ospf-import-policy;

No RIP routes are redistributed

user@routei:> show ospf database area 0,0,0,2

OSPF link state database. Area 0.0.0.2

Type ID Adv Rtr Seq Age Opt Cksum Len
NSSA 0.0.0.0 10.200.0.3 Ok800Q0003 1593 0x20 0K2d24 36
NSSA 0.0.0.0 10.200.0.4 OkSOOOOOOS 1644 0k20 0k2729 36

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 OSPF Case Studies and Solutions . Chapter 4-41

Advanced Junos Service Provider Routing

Summary

In this chapter, we:

.
Configured OSPF virtual links
.
Configured OSPF multiarea adjacency
.
Explained OSPF external reachability

lUflPgr VVorlHwiUetrlu cation Servmes «w..jniprcn.l I 4-42

This Chapter Discussed:

.
Configuring OSPF virtual iinks;
Configuring OSPF multiarea adjacencies; and

OSPF external reachability.

Chapter 4-42 . OSPF Case Studies and Solutions www.Juniper.net

 Advanced Junos Service Provider Routing

Review Questions

1 . Why must you have a backbone OSPF area?

2 . List reasons why you would deploy virtual links.
3 .
What is the default rule for route redistribution?

Review Questions
i .

www.juniper.net OSPF Case Studies and Solutions . Chapter 4-43

Advanced Junos Service Provider Routing

AdvaBicect OSPF Options and touting Policy ,

8 Configure a virtual link .

Configure multiarea adjacencies.

Examine prefix limits.

tut* NeM,i-i..
.
. n< -i. r.-v . r .. JUH PSf WiuliKviile tiluudlion Ser.iues vww mnipernef i 4-44

Lab 3: Advanced OSPF Options and Policy

The slide provides the objectives for this lab.

Chapter 4-44 . OSPF Case Studies and Solutions www.juniper.net

juniper NETWORKS

Advanced Junos Service Provider

Chapter 5: IS-IS
Advanced Junos Service Provider Routing

actives

After successfully completing this chapter, you will be

able to:
.
Explain the concepts and operation of IS-IS
.
Describe various IS-IS link-state PDU types
.
List IS-IS adjacency rules and troubleshoot common
adjacency issues
.
Configure and monitor IS-IS

f.
>» orldv/iile Edutation Smices

This Chapter Discusses:

iS-iS operation;
IS-IS areas and levels;

Configuring IS-IS in the Junos operating system;

Using operational-mode commands to monitor and troubleshoot IS-IS; and

Displaying and interpreting the IS-IS link-state database (LSDB).

Chapter 5-2 . IS-IS www.Juniper.net

 Advanced Junos Service Provider Routing

Agenda: IS-IS
-
>Overview of IS-IS
IS-IS PDUs

Neighbors and Adjacencies

Configuring and Monitoring IS-IS

Wo rlciwi tie fc ducat i o n$e rvi ce s

Overview of IS-IS

The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.Juniper.net IS-IS . Chapter 5-3

Advanced Junes Service Provider Routing

Overview of IS-IS

An interior gateway protocol based on the SPF

algorithm
.
Uses link-state information to make routing decisions

111 Developed for routing ISO CLNP packets

. IP was added later
.
Defined in ISO/IEC 10589, RFC 1142 RFC 1195. and ,

RFC2763

The IS-IS Protocol

The IS-IS protocol is an IGPthat uses link-state information to make routing decisions. It also uses an
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 OSI suite.

Chapter 5-4 . IS-IS www.Juniper.net

 Advanced Junes Service Provider Routing

Integrated IS-IS

M Series, MX Series, and T Series platforms do not

support native CLNP/CLNS routing
.
SRXSeries and J Series platforms do support CLNP/CLNS
routing
Implementation of IS-IS for routing IP in addition to
CLNS, also called dual IS-IS
All routers run a single routing algorithm
IS-IS routers exchange link-state protocol data units
.
Similar to OSPF LSAs/link-state update packets
.
IS-IS PDUs are the packets used by the protocol to transmit
the information-not IP
.
IP reachability information is included in the updates

Voridwide Education Services

.
ww jnipernei | s-s

CNLS

Connectionless Network Service (CLNS) is the service that Connectionless Network Protocol (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.

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/1P setting.

Single Algorithm
Like all integrated routing protocols. Integrated IS-IS requires that all routers run a single routing
algorithm. Link-state protocol data units (PDUs) 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 Address Resolution Protocol (ARP), Internet Control Message
Protocol (ICMP) for IP, and the End System-to-lntermediate System (ES-IS) protocol for CLNP.

Continued on the next page.

www.juniper.net IS-IS . Chapter 5-5

Advanced Junes Service Provider Routing

Link-State PDUs

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.

Junos Support
M Series and MX Series Multiservice Edge Routers and T Series Core Routers only support IP routing
with IS-IS. They do not support CLNP or CLNS routing. SRX Series Services Gateways and J Series
Services Routers do support full IS-IS CLNP routing, including ES-IS routing.

Chapter 5-6 . IS-IS www.juniper.net

 Advanced Junos Service Provider Routing

Li '

IS-IS network is a single autonomous system

.
End systems: Network entities (that is, hosts) that send and
receive packets
.
Intermediate systems: Network entities (that is routers) that ,

send and receive packets and relay (that is forward) packets ,

.
PDUs: Protocol data units: term for IS-IS packets
A single AS can be divided into smaller groups called
areas, which are organized hierarchically
.
Level 1 intermediate systems route within an area or toward
a Level 2 system
. Attached bit
.
Level 2 intermediate systems route between areas and
toward other ASs

Worldwicie Education Serviees

Operation of IS-IS
An IS-IS network is a single AS, also called a routing domain, that consists of end systems (ESs) and
intermed/ate systems (ISs). End systems are network entities that send and receive packets.
Intermediate systems-which Is the OSI term for a router-send and receive packets and relay, or
forward, packets. IS-IS packets are called protocol data units (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 Levell/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) Levell/Level2-attached router.

www.juniper.net IS-IS . Chapters-?

Advanced Junes Service Provider Routing

ntity fltte
NET = 49.0001.1921.6801.6001.00

\ NET = 49.0002,1921.6802.4001.00

/ \
/\ 1

Area System (D Selector

/ \/ :

NET = 49.0002.1921.6803.6001.00

Area 49.0001 Area 49.0002

Network Entity Title

The slide displays a sample IS-IS network with two distinct areas configured-49.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-declmal 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 5-8 . IS-IS www.juniper.net

 Advanced Junos Service Provider Routing

IS-I$ and m

Both IS-IS and OSPF:

. Maintain link-state databases and construct a shortest
path tree
.
Dijkstra algorithm
*
Use hello packets to form and maintain adjacencies
.
Use a two-level hierarchy
. Provide for address summarization between areas
.
Elect a designated router
.
Have authentication capabilities

Vorldwide EiJurjaliun Services

IS-IS and OSPF Common Features

The slide lists the commonalities between IS-IS and OSPF.

www.juniper.net IS-IS . Chapter 5-9

Advanced Junes Service Provider Routing

0 1

In IS-IS, links
separate areas
/
LI

Ll L1/L2
Ll

0
L1/L2
L2

Ll

L1/L2 L2

Ll

IS-IS Areas

IS IS and OSPF are link-state routing protocols with many similarities. Differences exist between
them as well. 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).

Chapter 5-10 . IS-IS www.junlper.net

 Advanced Junes Service Provider Routing

? ms

In OSPF, routers
separate areas

ABR

\
N .
/ ABRJ
ABR

OSPF Areas

The slide shows the same network as the previous slide, only configured with OSPF instead of IS-IS.
Compare the two slides to identify the similarities and differences. OSPF area borders are marked by
routers. 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.

www.juniper.net IS-IS . Chapter 5-11

Advanced Junos Service Provider Routing

Overview of IS-IS
-
>IS-IS PDUs

Neighbors and Adjacencies

Configuring and Monitoring IS-IS

Mifil Worldwide Eduoation Services

IS-IS PDUs

The siide highlights the topic we discuss next.

Chapter 5-12 . IS-IS www.juniper.net

 Advanced Junos Service Provider Routing

LSP Format

Describes the state of adjacencies in neighboring

IS-IS routers

Flooded periodically throughout a level

Contains multiple TLV segments
Field length. 1 1 1 1 1 1 1 1 Va ria ble

In bytes [ PDU
Maximum
1 Protocol Header
Version
ID PDU
Headers
Version Reserved Area
1 Identifier Length Length Type
Addresses andTLVs

a 4 2 1 Va ia ble

r
PDU Remaining LSP ID
! Sequence Checksum
ATT OL, a nd
,
TLVs
Length Lifetime | Number IS Type Bits

Describes Adjacency State

The link-state PDU (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 operating system
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
0x01-the current version of the protocol.

Continued on the next page.

www.juniper.net IS-IS . Chapter 5-13

Advanced Junes Service Provider Routing

Flooded Periodically
The IS-IS link-state PDUs are flooded when either a network change occurs or often enough to keep
the database from having stale information. Each link-state PDU has a 2-byte field named the
remaining lifetime. Each IS-IS router initializes this field to a certain value when the link-state PDU is
created. By default, this timer value is set to 1200 seconds, or 20 minutes. Each router takes this
value and begins a countdown towards 0. Before the timer expires (at approximately 317 seconds),
the originating system regenerates the link-state PDU and floods it to all of its neighbors.

Contains TLV Segments

Each Individual link-state PDU contains multiple TLV segments that describe the originating router.
Many possible TLVs can be sent, but each system only sends those which 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), 3 0:30:30:30:30:30 > 30:30:30:30:30:30, hlen: 27, v: 1,
sys-id-len: 5 (0), max-area: 3 (0), L2 LSP
Isp-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
Default Metric: 10, Internal, Distribution: up
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
Metric: 10, Distribution: up, no sub-TLVs present
IPv4 External reachability TLV #130, length: 12
IPv4 prefix: 192.168.49.0/24
Default Metric: 00, Internal, Distribution: up
Extended IPv4 reachability TLV #135, length: 8
IPv4 prefix: 192.168.49.0/24
Metric: 0, Distribution: up, no sub-TLVs present
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.2 001.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 5-14 . IS-IS www.juniper.net

 Advanced Junos Service Provider Routing

LSP Notes

PDU type field denotes an Level 1 or Level 2 PDU

. Level 1 PDU = 18
. Level 2 PDU = 20

LSP ID field provides uniqueness in the domain

Attached (ATT) bit is set if the IS is connected to
another area

Overload (OL) bit is set if the link-state database is

overloaded

IS type bits determine a Level 1 or Level 2 router

. Level 1 router = 0x1
. Level 2 router = 0x3

PDU Type
The 1-byte PDU type field denotes whether this is a Levei 1 or a 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.

Link-State PDU ID Field

The ID of the link-state PDU uniquely identifies it within the IS-IS domain. The 8-octet field is
'

comprised of the router s 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 link-state PDU. The initial link-state PDU receives a value of
0x00, and it is incremented by Ifor each following fragment.
The circuit ID field helps distinguish link-state PDUs advertised from a single router. By default, all
link-state PDUs representing the router as a node use a value of 0x00 for the circuit ID field. When a
router is operating as a DIS, it places the value of the circuit ID into this field and generates a
separate link-state PDU 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 Oxff.

Continued on the next page.

www.juniper.net IS-IS . Chapter 5-15

Advanced Junos Service Provider Routing

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 link-state PDU. 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 today s 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 only support Level 1 routing. A value of 11 (0x03), however, means that the local router
can support both Level land Level 2 routing. These settings are the only two settings possible for
these bits.

Chapter 5-16 . IS-IS www.juniper.net

 Advanced Junes Service Provider Routing

Hel ! mm

The hello mechanism for neighbor discovery is used

to build and maintain adjacencies
. Similar to the hello mechanism in OSPF

Separate hellos for:

. Broadcast networks
Weil-known multicast address used for Level 1 and Level 2 hellos
.

.
Point-to-point networks
IS-IS transmits hello PDUs at regular intervals
Hello PDUs:
.
Identify the device
.
Describe its capabilities
.
Describe the parameters of the interface

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
designated intermediate system (DIS) router sends hello packets every 3 seconds, and a non-DIS
router sends hello packets every 9 seconds.

Continued on the next page.

www.Juniper.net IS-IS . Chapter 5-17

Advanced Junes Service Provider Routing

PDU Fields

The following list provides the details of the PDU fields:

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.

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.

Chapter 5-18 . IS-IS www.juniper.net

 Advanced Junes Service Provider Routing

Link-state PDUs
. Used to build the link-state database
. Similar to LSAs in OSPF
.
Separate LSPs for:
.
Level 1 systems
.
Level 2 systems
.
Sent as a result of a network change, during adjacency
formation, and in response to a sequence number PDU
(described on the next slide)
. Link-state PDUs:
.
Identifyan IS's adjacencies
*
Describe the state of Its adjacencies
.
Describe its reachable address prefixes (routes)

WofWWida Education Services

IS-IS Link-State PDUs

IS-IS sends link-state PDUs at regular intervals and when an IS discovers that:

Its link to a neighbor is down;

It has a new neighbor; and

The cost of a link to an existing neighbor has changed.

Once link-state PDUs 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 link-state
PDUs 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 5-19

Advanced Junes Service Provider Routing

ice K :m PDUs

Partial sequence number PDU

. Used to:
.
Maintain the LSDB synchronization
.
Acknowledge LSPs from a neighbor on a point-to-point network
.
Requesta copy of a missing LSP on a broadcast network
.
Separate type for Level 1 and 2 systems
.
Contains specific header information for a particular LSP
being acknowledged or requested
Complete sequence number PDUs
.
Used to maintain the LSDB synchronization
.
Sent periodically by all ISson point-to-point networks
.
OnlysentbyDISon broadcast networks
.
Separate type for Level 1 and 2 systems
. Contain header information for all LSPs in the IS's LSDB

Partial Sequence Number PDUs

A receiver muiticasts partiai sequence number PDUs (PSNPs) when it detects that it is missing an
link-state PDU or when its iink-state PDU 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 link-state PDU be transmitted. That router, in turn, forwards the missing link-state PDU to
the requesting router.

Complete Sequence Number PDUs

CSNPs contain a complete description of all link-state PDUs 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 link-state PDU databases. The DIS router muiticasts CSNPs on broadcast links in
place of sending explicit acknowledgments for each link-state PDU.

Chapter 5-20 . IS-IS www.juniper.net

 Advanced Junes Service Provider Routing

IS-IS information objects

8 Each piece of IS-IS information is defined as an object with
three attributes:
.
Oibjecttype: The predefined code for the type of Information
contained in the object
.
Object length: The length of the information (allows for variable-
length objects)
.
Object va/ue: The actual information defined by the type attribute
.
TLVs are the building blocks of IS-IS PDUs, which are used
for information exchange
.
Some TLVs are used in multiple PDUs
.
Some TLVs are PDU-specific
.
Similar to OSPF packet-specific and LSA-specific fields

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 5-21

Advanced Junes Service Provider Routing

TLV Code Defined in Used for

1 ISO 10589 Area addresses

2 ISO 10589 IS neighbor metrics

6 ISO 10589 Neighbor LAN ID
8 ISO 10589 Padding
9 ISO 10589 LSP entries

10 ISO 10589 Authentication

22 RFC 5029 Extended IS reachability

128 RFC 1195 IP prefix, mask, and metrics
129 RFC 1195 Protocols supported

41 MtVot-i. 'Dtltfwide Education Services

TLV Variables: Parti

The following list provides the details of several of the TLVs:

TLV 1 (Area address): Provides the area address encoded within the IS-IS NET on the
loopback 0 (loO) interface.

TLV2 (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 router sinterfaces capable of supporting IPv4 traffic.
.
TLV 129 (Protocols supported): Informs other routers in the network which Layer 3
protocols the local router supports. By default, the Junes OS supports both IPv4 and
IPv6. On the J Series Services Router and the SRX Series Services Gateways, you can
also use the Junos OS to support CLNS.

Chapter 5-22 . IS-IS www.juniper.net

 Advanced Junos Service Provider Routing

TLV Examp m

i TLV Code Defined in Used for

130 RFC 1195 IP external information

132 RFC 1195 IP interface address

135 RFC 3784 Extended IP reachability

137 RFC 2763 Dynamic hostname mapping
222 RFC 5311 Multipletopologies (routing instances)
229 RFC 5311 Multiple topologies (routing instances)
232 RFC 5308 IPv6 support
235 RFC 3784 Multiple topologies (routing instances)
236 RFC 5308 IPv6 support

I :

TLVVariables: Part2

The foliowing 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 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.

Continued on the next page.

www.juniper.net IS-IS . Chapter 5-23

Advanced Junes Service Provider Routing

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.
TLV235 (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:

TLV 232 (IPv6 interface address): Advertises the IPv6 interface address for those
interfaces that support iPv6 traffic.

TLV 236 C/Pv6 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.

Chapter 5-24 . IS-IS www.juniper.net

 Advanced Junes Service Provider Routing

TLV t-Area Address

Advertises the area ID of the originating router

.
(l-byte) TLV type
.
(l-byte) TLV length
.
(l-byte) Area length
.
Repeated for each configured area
.
(Variable) Area ID
.
Ranges from Ito 13 bytes
.
Repeated for each configured area

Area Address TLV

Each IS-IS router sends this TLV in both its Level 1 and its Level 2 link-state PDUs. Up to three area
addresses are configurable per system, so the area ID field Is repeated for each unique area
address. The area address TLV contains the following fields:

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.

www.Juniper.net IS-IS . Chapter 5-25

Advanced Junos Service Provider Routing

TLV 1 3 J

Describes the IS neighbors of the local router

.
Metric cost to each neighbor is advertised
.
Metric and neighbor ID fields are repeated for each neighbor
.
(l-byte)TLV type
.
(l-byte)TLV length
.
(l-byte)Virtual flag
.
(l-byte) R (Reserved) bit. I/E bit, default metric
.
(l-byte)S (Supported) bit. I/E bit, delay metric
.
(l-byte)S (Supported) bit. I/E bit. expense metric
.
(l-byte)S (Supported) bit, I/E bit, error metric
.
(7-byte) Neighbor ID

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 type IbyteJ: The type of the TLV is encoded in this field with a constant value of 2.

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.

Continued on the next page.

Chapter 5-26 . iS-IS www.juniper.net

 Advanced Junes Service Provider Routing

IS Reachability TLV (contd.)

Default metric (1 byte): The first bit in this fieid 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 l/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. TheS bit is set to a constant value of 1 (not supported), while the 1/
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. TheS bit is set to a constant value of 1 (not supported), while the l/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 l/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 fieid. It is

comprised of the 6-byte system ID and the 1-byte circuit ID of the neighbor.

www.Juniper.net IS-IS . Chapter 5-27

Advanced Junos Service Provider Routing

Encodes authentication data to ensure that only

trusted information is placed into the LSDB
.
(l-byte) TLV type
.
(1-byte) TLV length
.
(1-byte) Authentication type
.
(Variable) Password

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:
.
TLV type (1 byte): The type of the TLV is encoded in this field with a constant value of 10.

TLV length (1 byte): The length of the remaining fields in the TLV is placed in this field.
Authentication type (1 byte): The specific form of authentication is encoded in this field.
Plain-text authentication uses a value of 1, while 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.

Chapter 5-28 . IS-IS www.juniper.net

 Advanced Junos Service Provider Routing

TLV 2 leniei IS it© 1 litf

Advertises additional capabilities and information

about IS neighbors
.
Larger metric values
.
Traffic engineering parameters
.
Information repeated for each neighbor (system ID)
.
(l-byte) TLV type
.
(l-byte)TLV length
.
(7-byte)System ID
.
(3-byte)Wlde metric
.
(l-byte)Sub-TLV length
.
(Variable)Sub-TLVs

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:

71V type (1 byte): The type of the TLV is encoded in this field with a constant value of 22.

TLV length (1 byte): The length of the remaining fields in the TLV is placed in this field.
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 l-byte circuit ID of the neighbor.

Wide metric (3 bytes): The metric cost to reach the adjacent neighbor is encoded in this
field.

Continued on the next page.

www.juniper.net IS-IS . Chapter 5-29

Advanced Junos Service Provider Routing

Extended IS Reachability TLV (contd.)

The following list is a continuation of the fields contained in the extended IS reachability TLV:

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:

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).

Chapter 5-30 . IS-IS www.juniper.net

 Advanced Junos Service Provider Routing

8-1 Roac' 1

Describes the internal IP information of the local

router
.
IP prefix and metric advertised
.
Information repeated for each prefix
*
(l-byte) TLV type
.
(l-byte)TLV length
.
(l-byte) U/D bit, l/E bit. default metric
.
(l-byte)S (Supported) bit, R (Reserved) bit. delay metric
.
(l-byte)S (Supported) bit. R (Reserved) bit. expense metric
.
(l-byte)S (Supported) bit, R (Reserved) bit, error metric
.
(4-byte)IP address
*
(4-byte)Subnet mask

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 (sma/( metrics). The IP internal reachability TLV contains the following fields:

TLV type fl bytej: The type of the TLV is encoded in this field, which holds a constant
value of 128.

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 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 l/E bit for TLV 128, the current release ignores this bit upon reception
and treats all prefixes as internal. The final 6 bits representthe metric cost to reach the
advertised prefix.

Continued on the next page.

www.juniper.net IS-IS . Chapter 5-31

Advanced Junos Service Provider Routing

IP Internal Reachability TLV (contd.)

The following list details the remaining fields in the IP internal reachability TLV:
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.

Expense 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.

Error 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.

Chapter 5-32 . IS-IS www.Juniper.net

 Advanced Junes Service Provider Routing

TLV .
iportei

Describes the Layer 3 protocols supported by the

local router
.
(l-byte) TLV type
.
(1-byte) TLV length
.
(1-byte) Network Layer Protocol ID
Repeated for each supported protocol

/ :
-

Protocols Supported TLV

Every IS-IS router sends this TLV in all link-state PDUs. 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:
TLV type (1 byte): The type of the TLV is encoded in this field. A constant value of 129 is
placed in this field.
.
TLV length (1 byte): The length of the remaining fields in the TLV 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-blt NLPID is placed within this field. By default,
the Junes OS supports both IPv4 (OxCC) and IPv6 (OxSE) and encodes those values in
this TLV. On J Series routers and SRX Series devices, you can also configure the Junes
OS to support the GLIMS protocol by configuring clns-routing at the [edit
protocols isis] configuration hierarchy.

www.juniper.net IS-IS . Chapter 5-33

Advanced Junes Service Provider Routing

Describes the external IP information of the local

router
.
IP prefix and metric advertised
.
Information repeated for each prefix
.
(l-byte)TLVtype
.
(l-byte)TLV length
.
(l-byte)U/D bit. I/E bit. default metric
.
(l-byte)S (Supported) bit. R (Reserved) bit, delay metric
.
(l-byte)S (Supported) bit. R (Reserved) bit. expense metric
.
(l-byte)S (Supported) bit. R (Reserved)bit. error metric
.
(4-byte)IP address
.
(4-byte) Subnet mask

rldwicle Education Services

IP External Reachability TLV

Each iS-IS router advertises prefixes that are nativeiy 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 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 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 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 Junes OS versions made use of the l/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.

Continued on the next page.

Chapter 5-34 . IS-IS www.Juniper.net

 Advanced Junos Service Provider Routing

IP External Reachability TLV (contd.)

The foilowing list details the fields remaining in the IP external reachability TLV:
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.

.
Expense 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.

Error 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.

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

www.juniper.net IS-IS . Chapter 5-35

Advanced Junes Service Provider Routing

TLV 132-1? Interface Address

Advertises the IP address of the local router's

interface
.
IPv4 address field is repeated for each advertised address
.
(l-byte)TLV type
.
(l-byte)TLV length
.
(4-byte)IPv4 address

IP Interface Address TLV

iS-IS routers send this TLV in all link-state PDUs, 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 JunosOS encodes the router ID of the local system in this TLV. This router
ID is often the same as the primary address of the router's loO. 0 interface. The IP interface
address TLV contains the following fields:

TLV type (1 byte): The type of the TLV is encoded in this field with a constant value of
132.

.
TLV length (1 byte): The length of the remaining fields in the TLV is placed in this field.
This length allows a router to determine the number of addresses encoded within the
TLV.

/Pv4 address (4 bytes): The local router's interface address is placed in this field.

Chapter 5-36 . IS-IS www.juniper.net

 Advanced Junos Service Provider Routing

TLV OH

Advertises the traffic engineering router ID of the local

router
.
(1-byte) TLV type
.
(1-byte) TLV length
.
(4-byte) Router ID

TE IP Router ID TLV

Aii routers configured to support traffic engineering, which is the Junos OS default setting, generate
this TLV. The router ID of the local router is placed in this field for use in the TED. The TE IP router ID
TLV contains the following fields:

71V type {1 byte): The type of the TLV is encoded in this field with a constant value of
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.

/Pv4 address (4 bytes): The router ID of the local router is placed in this field.

www.juniper.net IS-IS . Chapter 5-37

Advanced Junes Service Provider Routing

Advertises information about the local router's IP

reachability
.
Larger metric values
.
Information repeated for each prefix
.
(l-byte)TLVtype
.
(l-byte)TLV length
.
(4-byte) Metric
.
(1-byte) Up/Down bit. Sub bit. and prefix length
.
(Variable) Prefix
.
(1-byte) Optional sub-TLV type
.
(1-byte) Optional sub-TLV length
.
(Variable)Optional sub-TLV

'ofldwitle Education Semces

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:

TLV type (1 byte): The type of the TLV is encoded in this field with a constant value of
135.

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 prefixes advertised within the
TLV.

Metric (4 bytes): The metric of the advertised prefix is encoded in this field.

Continued on the next page.

Chapter 5-38 . IS-IS www.juniper.net

 Advanced Junes Service Provider Routing

Extended IP Reachability TLV (contd.)

Thefoliowing iist details the remaining fields of the extended IP reachability TLV:

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
Junes 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.

www.juniper.net IS-IS . Chapter 5-39

Advanced Junos Service Provider Routing

TLV UI-Ofiif. jstname

Advertises the ASCII hostname of the router to the

network
.
fl-byte) TLV type
.
(l-byte)TLV length
.
(Variable) Hostname

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:

TLV type (1 byte): The type of the TLV is encoded in this field with a constant value of
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.

Chapter 5-40 . IS-IS www.juniper.net

 Advanced Junes Service Provider Routing

Il3er@ll0st> show isis database extensive [ find TLV

Area address: 49.0001

TLV 134
Speaks:
Speaks:
IP
IPv6 } TLV 129

TLV 132
IP router id: 192.168.48.1
IP address; 192.168.48.1
TLV 137 TLV2sma//
Hostname: SaoPaulo
metrics
IS neighbor: Sydney.00, Internal, Metric: default 1
IS extended neighbor: Sydney.00, Metric: rtffmlt: M
IP address: 10.222.60.2 4 subTLV 6
TLV 22 wide metrics
Neighbor's IP address: 10.222.60.1 subTLV 8

IP prefix: 192.168.48.1/32, Internal, Metric :

"

icf.r. it 0, Op
'

TLV 128 smsli

metrics
IP prefix: 10. 222 . 60.0/2-1, Internal, Metric: default 10, Up
IP extended prefix: 192.168.48.1/32 metric 0 up
TLV 135 wide metrics
IP extended prefix: 10.222.60.0/24 metric 10 up
IP external prefix: 192.168.49.0/24, Internal, Metric: default 0, Up
IP extended prefix: 192.168.49.0/24 metric 0 up
*~-"-
\
17 bytes
,

Authentication data; ~~
;
-

I TLV 135 TLV 130

No queued transmissions TLV 10

. -

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 router's RID is 192.168.48.1. This information is available in the IP router
id field and TLV 134.

The link-state PDU 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 router's interface towards 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.

Continued on the next page.

www.junlper.net IS-IS . Chapter 5-41

Advanced Junes Service Provider Routing

Level 2 PDU TLVs Example (contd.)

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

Chapter 5-42 . IS-IS www.juniper.net

 Advanced Junes Service Provider Routing

Agenda; IS-IS

Overview of IS-IS

IS-IS PDUs
-

Neighbors and Adjacencies

Configuring and Monitoring IS-IS

Neighbors and Adjacencies

The slide highlights the topic we discuss next.

www.juniper.net IS-IS . Chapter 5-43

Advanced Junes Service Provider Routing

jacencl-

IS-IS adjacency rules: L2

. Level 1 routers never form Level 2 Hello

an adjacency with a
Level 2 router L2

. The reverse is also true

LI
.
For Level 1 adjacencies,
area IDs must be the
same Li

.
For Level 2 adjacencies, Level 1 Hello
area IDs can be different

uoallon Services
'

www-.juntp er.net i. 5-44:.

Neighbors and Adjacencies

The slide lists the rules Level land Level 2 routers must follow when forming an adjacency.

Chapter 5-44 . IS-IS www.junlper.net

 Advanced Junes Service Provider Routing

ated intermeiiate System

IS-IS elects a DIS on broadcast/multi-access networks
.
In a priority tie, the system with the highest SNPA/MAC
address wins the DIS election
Separate DIS is elected for LI and L2 (could be the same
.

router)
The IS-IS network is considered a router-called a
pseudo-node
.
Each router advertises a single link to the pseudo-node,
including the DIS
.
Each router forms an adjacency with each of its neighbors on a
broadcast, multi-access network
DIS characteristics:
.
DIS acts as representative of the pseudo-node and advertises
the pseudo-node to all attached routers
.
Mo backup DIS in IS-IS immimiw

Designated Intermediate System 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 Junes OS uses a default priority of 64
for both levels. The router advertises its priority in the hello PDUs sent from each interface. The LI
priority is advertised in LI 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.

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 router-a 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 ail of the attached routers.

Continued on the next page.

www.juniper.net IS-IS . Chapter 5-45

Advanced Junes Service Provider Routing

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
link-state PDUs to all of its neighbors, and the DIS uses a system of PDUs-called sequence number
PDUs-to ensure that the flooding of link-state PDUs is reliable. Also unlike OSPF, no election of a
backup designated router occurs in IS-IS. If the IS-IS DIS falls, 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 link-state PDUs must be flooded.

Chapter 5-46 . IS-IS www.juniper.net

 Advanced Junos Service Provider Routing

If no adjacency exists, check for:

.
Physical Layer and Data Link Layer connectivity
.
Mismatched areas (if Li router) and levels
.
Failure to support minimum protocol MTU of 1492
.
Lack of IP configuration on interfaces
. Lack of, or malformed, ISO-NET
.
No NET configured
. Failure to include loO as an IS-IS interface

VVnrWv/Ule WnrationSmices

IP Configuration Necessary
When establishing adjacencies in OSPF, 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.

Troubleshooting No Adjacency
The slide provides a checklist to use when troubleshooting IS-IS adjacency problems.

www.juniper.net IS-IS . Chapter 5-47

Advanced Junes Service Provider Routing

Overview of IS-IS

IS-IS PDUs

Neighbors and Adjacencies

-

>Configuring and Monitoring IS-IS

Pf tt'orltlwide I iluraliun Ser.ii es

Configuring and Monitoring IS-IS

The slide highlights the topic we discuss next.

Chapter 5-48 . IS-IS www.Juniper.net

 Advanced Junos Sen/ice Provider Routing

You must include the ISO family on all interfaces on

which you want to run IS-IS and a NET on one of the
'
router s interfaces (usually loO)
[edit]
user@router# show interfaces
ge-0/1/0 {
unit 0 {
family iso;
family inet {
address 10.0.24.1/24;
}
}
}
loO {
unit 0 {
family inet {
address 192.168.2.1/32;
}
family iso {
address 4 9.0001.0192.0168.0201.00;
}
}

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
,

'
router s interfaces (preferably the loopback Interface, loO), 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 router's loopback interface. Such
a configuration might prove helpful when migrating two previously independent IS-IS domains into a
single routing domain.

www.Junlper.net IS-IS . Chapter 5-49

Advanced Junos Service Provider Routing

iirin S s m 2)
[edit protocols]
user8router# set isis interface ge-0/0/0.0 level 1 disable

[edit protocols]
user@router# set isis interface at-0/1/1.100 level 2 disable

[edit protocols]
user@router# show

isis {
interface ge-0/0/0.0 {
level 1 disable;

interface at-0/1/1.100 {
level 2 disable;

interface loO.O {
level 2 disable;

1p#

Configuring IS-IS: Part 2

By default, all IS-IS interfaces are Level i 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 5-50 . IS-IS www.juniper.net

 Advanced Junes Service Provider Routing

IS-IS Metric

Metric of an interface indicates the overhead required

to send packets out a particular interface
Default IS-IS metric for all links is 10
.
Includes passive interfaces
.
Exception is the loopback interface
. Default metric isO

Can set metric on a per-interface basis

. Each level on an interface can also have a different metric

[edit protocols]
userSrouter# show
isis {
interface so-0/0/0.0 {
level 2 metric 10;
level 1 metric 20;
}
interface ge-0/1/0.0 {
level 2 metric 5;
}
}

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 costvaiues 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 cost 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 cost of 0.

When you configure an IS-IS interface to operate in passive mode, the default metric cost is still set
to a value of 10. This default Is different from the operation of other router vendors, so be careful in
a multlvendor environment to ensure a consistent metric calculation.

Set on a Per-lnterface 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 5-51

Advanced Junes Service Provider Routing

You can change the interface cost to use the formula

reference-bandwidth/ba ndwidth
.
Automatically alters the cost of interfaces
.
Allows for a consistent change across all interfaces
Use the reference-bandwidth command within
the [edit protocols isis] hierarchy
[edit protocols isis]
user@router# set reference-bandwidth Igr

[edit protocols isis]

user8router# show
isis {
reference-bandwidth lg;
interface so-0/0/0.0;
interface ge-0/1/0.0 {
level 2 metric 10;
}

H P8f Worldwhlu Education Survices

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 value-the reference bandwidth-and 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 5-52 . IS-IS www.juniper.net

 Advanced Junes Service Provider Routing

P#ration
.
Various show commands exist to provide detailed
information on the operation of IS-IS
. show isis interface

8 show isis adjacency

.
show isis spf log
. show isis statistics

.
show isis route

8 show isis database extensive

:
.
orldvmlp I .Jin .iiiun Ser ir.es

Monitoring IS-IS Operation

This slide lists the show commands discussed on the following pages.

www.juniper.net IS-IS . Chapter 5-53

Advanced Junes Service Provider Routing

Use the show isis interface command to

display the IS-IS parameters associated with an
interface

user@router> show isis interface ?

Possible completions:
<[Enter]> Execute this command
<interface-name> Interface name
brief Show brief status
detail Show detailed status

user@router> show isis interface

IS-IS interface database:
Interface L CirlD Level 1 DR Level 2 DR L1/L2 Metric
loO.O 0 0x1 Disabled Passive 0/0
so-0/1/0.0 1 0x1 Disabled Point to Point 10/10
so-0/1/1.0 2 0x1 Disabled Point to Point 10/10
so-0/1/2.0 3 0x1 Disabled Point to Point 10/10

Level 3 is both Level 1 and Level 2

Worldwide EducationSorvioes

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 Junes 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 1-Level 1
only, 2-Level 2 only, or 3-Level 1 and Level 2.

lsp interval (detail output only): Displays the interface's 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.

Continued on the next page.

Chapter 5-54 . IS-IS www.juniper.net

 Advanced Junes Service Provider Routing

Displaying Interface Status (contd.)

Level 1 DR/Level 2 DR (brief output only): Displays the Level 1 or Level 2
designated intermediate system.
L1/L2 Metric: Displays the interface's 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 interface's hello interval.

Hold (s) (detail output only): Displays the interface's hold time.

www.Juniper.net IS-IS . Chapter 5-55

Advanced Junos Service Provider Routing

Use the show isis adjacency command to

display IS-IS parameters adjacency status
user@router> show isis adjacency ?
Possible completions:
<[Enter]> Execute this command
brief Show brief status
detail Show detailed status
system-id Display entries for specified system

user(arouter> show isis adjacency

IS-IS adjacency database:
Interface System L State Hold (sees) SNPA
so-0/1/2.0 Denver 2 Up 24
so-0/1/3.0 SanFran 2 Up 28
so-0/2/2.0 Toronto 2 Up 23
so-0/2/3.0 Amsterdam 2 Up 26

t
Expires in

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:

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 1-Level 1 only; 2-Level 2 only;
or 3-Level 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 (sees) (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).

Chapter 5-56 . IS-IS www.juniper.net

 Advanced Junes Service Provider Routing

'

: ;/ing Detailed Adjacency Information

Display detailed IS-IS adjacency information with the

detail switch

user&router> show isis adjacency detail

IS-IS adjacency database:

Denver

Interface: so-0/1/2.0, Level: 2, State: Up, Expires in

25 sees

Priority: 0, Up/Down transitions: 1, Last transition:

00:15:27 ago
Circuit type: 2, Speaks: IP
IP addresses: 10.0.18.2

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:
.
Expires in (detail output only): Displays how long until the adjacency expires, in
seconds.

Priority (detail output only): Displays the priority to become the designated
intermediate system.
.
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 1-Level 1 router, 2-Level 2 router, or 1/2-both Level 1 and Level 2
routers.

Speaks (detail output only): Displays the protocols supported by this neighbor.

IP addresses (detail output only): Displays the IP address of this neighbor.

www.Juniper.net IS-IS . Chapter 5-57

Advanced Junos Service Provider Routing

Display information about SPF operation with the

show isis spf log command
user@router> show isis spf log
IS-IS level 1 SPF log:
Start time Elapsed (sees) Count Reason
Tue Apr 17 16:13:26 0.000039 1 Reconfig
Tue Apr 17 16:13:32 0.000062 1 Updated LSP
host.00-00
Tue Apr 17 16:28:26 0.000064 1 Periodic SPF

IS-IS level 2 SPF log:

Start time Elapsed (sees) Count Reason
Tue Apr 17 16:13:26 0 000025 1 Reconfig
Tue Apr 17 16:13:32 0 000051 1 Updated LSP
host.00-00
Tue Apr 17 16:13:57 0.000087 2 New adj acency
Denver on so-0/1/2.0
Tue Apr 17 16:14:03 0.000241 6 Updated LSP
Atlanta.0 0-00
Tue Apr 17 16:26:38 0.000298 1 Periodic SPF

deEtiucationServic

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:

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.

Reason (log output only): Displays the reason that the SPF computation was
completed.

Chapter 5-58 . IS-IS www.juniper.net

 Advanced Junes Service Provider Routing

Display : i-IS Statistics

Display various IS-IS statistics information with the

show isis statistics command

user@router> show isis statistics

IS-IS statistics for host:
PDU type Received Processed Drops Sent Rexmit
LSP 17 17 0 2 0
IIH 190 190 0 571 0
CSNP 99 99 0 294 0
PSNP 3 3 0 12 0
Unknown 0 0 0 0 0
Totals 309 309 0 879 0

Total packets received: 309 Sent: 879

SNP queue length: 0 Drops: 0

LSP queue length: 0 Drops: 0
SPF runs: 17
Fragments rebuilt: 5
LSP regenerations: 2
Purges initiated: 0

WorltKvule Education Services Mww.junlper.net

Displaying IS-IS Statistics

The show isis statistics command displays statistics about IS-IS traffic. The output fields of
this command are:

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
statistics were zeroed.

Rexmit: Displays the number of PDUs retransmitted since IS-IS started or since the
statistics were zeroed.

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.

Continued on the next page.

www.juniper.net IS-IS . Chapter 5-59

Advanced Junes Service Provider Routing

Displaying IS-IS Statistics (contd.)

lsp queue length: Displays the number of iink-state PDUs sitting on the iink-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 nearingthe 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.

Chapter 5-60 . IS-IS www.junlper.net

 Advanced Junes Service Provider Routing

Displaying IS-IS T
user@router> show isis route
IPv4/IPv6 Routes

IS-IS routing table Current version: LI: 3 L2: 5

Prefix L Version Metric Type Interface Via
10.0.0.0/24 2 5 20 int so-0/1/2.0 Denver
10.0.1.0/24 2 5 20 int so-0/1/2.0 Denver
10.0.2.0/24 2 5 30 int so-0/1/2.0 Denver
10.0.8.0/24 2 5 30 int so-0/1/2.0 Denver

user@host> show route protocol isis

inet.0: 64 destinations, 54 routes (64 active, 0 holddown, 0

hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.0/24 MIS-IS/IS] 00:00:59, metric 30

> to 10.0.21.1 via fe-0/0/2.0
10.0.1.0/24 *
[IS-IS/18] 00:00:59, metric 30
> to 10.0.21.1 via fe-0/0/2.0
10.0.2.0/24 *
[IS-IS/IS] 00:00:59, metric 40
to 10.0.21.1 via fe-0/0/2.0
> to 10.0.22.2 via so-0/1/1.0

Wo ridwi d a E ducatto n S e rvices

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:

Current version: Displays the number of the current version of the IS-IS routing
table.

Ll: Displays the version of Level 1SPF 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 1-Level 1 only; 2-Level 2 only; and 3-Level 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.

www.juniper.net IS-IS . Chapter 5-61

Advanced Junos Service Provider Routing

user@router> show isis database extensive

IS-IS level 1 link-state database:

Tokyo.00-00 Sequence: 0x1, Checksum: 0xlc90, Lifetime: 364 sees

IP prefix: 192.168.20.0/24 Metric: 0 External Up
IP prefix: 192.168.21.0/24 Metric: 0 External Up
IP prefix: 192.168.22.0/24 Metric: 0 External Up
IP prefix: 200.0.0.0/24 Metric: 0 External Up

Header: LSP ID: Tokyo.00-00, Length: 140 bytes

Allocated length: 1492 bytes, Router ID: 192.168.20.1
Remaining lifetime: 864 sees. Level: 1, Interface: 0
Estimated free bytes: 1352, Actual free bytes: 1352
Aging timer expires in: 864 sees
Protocols: IP, IPv6

Packet: LSP ID: Tokyo.00-00, Length: 140 bytes. Lifetime : 1200 sees
Checksum: OxlcSO, Sequence: 0x1, Attributes: 0x3 <L1 L2>
NLPID: 0x83, Fixed length: 27 bytes. Version: 1, Sysid length: 0 bytes
Packet type: 18, Packet version: 1, Max area: 0

TLVs:
Area address: 49.0001 (3)
Speaks: IP
Speaks: IPv6
IP router id: 192 . 38.20 .1
IP address: 192.1( .
20.1
Hostname: Tokyo
IP external prefix: 192.168.2 0.0/24, Internal, Metric: default 0, Up

deEducationServiGes

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 link-state PDU (LSP) identifier.

Sequence: Displays the sequence number of the link-state PDU.

.
Checksum; Displays the checksum value of the link-state PDU.

Lifetime (in seconds): Displays the remaining lifetime of the link-state PDU, in
seconds.

IP prefix (detail and extensive output only): Displays the prefix advertised by this
link-state PDU.

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 5-62 . IS-IS www.juniper.net

 Advanced Junos Service Provider Routing

SUK','

In this chapter, we:

.
Explained the concepts and operation of IS-IS
.
Described various IS-IS LSP types
e Listed IS-IS adjacency rules and how to troubleshoot
common adjacency issues
.
Configured and monitored IS-IS

©jai.i)gt n.!iNeHrefi.:, iri.!.iyiri.-!tf;!Ki>«!(i. JUflipSf WorldwideEdncationServices - mmw** I 5*3

This Chapter Discussed:

IS-IS operation;

IS-IS areas and levels;

Configuring IS-IS in the Junos OS;

.
Using operational-mode commands to monitor and troubleshoot IS-IS; and
Displaying and interpreting the IS-IS LSDB.

www.juniper.net IS-IS . Chapter 5-63

Advanced Junes Service Provider Routing

Review Questions

1 What is a PDU and what is its purpose?

.

2 . The LSP contains multiple segments. What are they

called and what do they do?
3 . What happens if an IS-IS enabled router with a
higher priority than all other routers is added to a
broadcast network?

4 . How would you configure only a Level 1 adjacency

'
on a Junos device s interface?

Review Questions
i .

2 .

3 .

Chapter 5-64 . IS-IS www.juniper.net

 Advanced Junos Service Provider Routing

Lai 4s IS-IS Configuration and Monitoring

Configure, monitor, and troubleshoot the operation of

an IS-IS network using multiple levels.

Worldwide Education Services

Lab 4: IS-IS Configuration and Monitoring

The slide provides the objective for this iab.

www.juniper.net IS-IS . Chapter 5-65

Advanced Junos Service Provider Routing

Chapter 5-66 . 1S-IS www.Juniper.net

jumper NETWORKS

Advanced Junos Service Provider

Routing

Chapter 6: Advanced IS-IS Operations and

Configuration Options
Advanced Junos Service Provider Routing

After successfully completing this chapter, you will be

able to:
*
Display and interpret the LSDB
.
Perform advanced IS-IS configuration options
.
Implement IS-IS routing policy

orldvvidii tiUuocrtion Services

This Chapter Discusses:

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 6-2 . Advanced IS-IS Operations and Configuration Options www.juniper.net

 Advanced Junos Service Provider Routing

IS-lt tmmmmmm mm
0%

IS-IS Operations
IS-IS Configuration Options
IS-IS Routing Policy

IS-IS Operations
The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.juniper.net Advanced IS-IS Operations and Configuration Options . Chapter 6-3

Advanced Junos Service Provider Routing

External
Routes
Injected

L1L2 Lll 2

/ \
L1L2
/ L1L2

mjF Area 49,1111 1 Area 49.1111 Area 49.1111

L2PDU L2PDU L2 PDU

Area 49.2222 Area 49.2222 Area 49.2222

L2PDU L2 PDU L2 PDU
L1L2 L1L2 L1L2

Area 49.3333 Area 49.3333 Area 49.3333

L2PDU L2 PDU L2 PDU

i
Area 49.1111 Area 49.2222 Area 49.3333
LI PDU LI PDU LI PDU

Area 49.1111 Area 49.2222 Area 49.3333

/

L1L2 = interface configuration

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.

Chapter 6-4 . Advanced IS-IS Operations and Configuration Options www.juniper.net

 Advanced Junes Service Provider Routing

userGrouteo show isis database

IS-IS level link-state database:

LSP ID Sequence Checksum Lifetime
Rl.00-00 0x8 0xcc42 957 LI
R2.00-00 0x9 Oxbdfa 1055 LI
R3.00-00 0x7 0x54d2 500 LI
R3.02-00 0x4 Oxdddb 677 LI
4 LSPS

IS-IS level 2 link-state database:

LSP ID Sequence Checksum Lifetime
Rl.00-00 0x6 0xa5al 1102 LI
R4.00-00 0x9 0xc92f 909 Ll
R5.00-00 0x6 0xd7d2 1109 LI
3 LSPs

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 eKtensive keyword. Now, let s take a step back
and examine the database as a whole. You can gather details by examining the database closely:

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, Rl 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 Ll 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.

www.juniper.net Advanced IS-IS Operations and Configuration Options . Chapter 6-5

Advanced Junos Service Provider Routing

1 mi
'

Based on the Dijkstra algorithm

. Link-state database
. Candidate database

.
Tree database

Runs on a per-level basis on each router

.
Independent calculation of the topology
Result is passed to the Junos OS routing table
. Decision as to whether the route is marked active is made
by the routing table

Dijkstra Algorithm
After a router receives a new link-state PDU 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.

During the course of this calculation, the algorithm uses three databases-the LSDB, the candidate
database, and the tree database. Remember that the link-state database is the total compilation of
routing knowledge in the network. Conceptually, it consists of multiple tuples In the form of (router
ID, neighbor ID, 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. 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 entry s neighbor ID Into the candidate database.

Continued on the next page.

Chapter 6-6 . Advanced IS-IS Operations and Configuration Options www.junlper.net

 Advanced Junes Service Provider Routing

Dijkstra Algorithm (contd.)

3 . Evaluate 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. Return to Step 1 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 link-state PDU
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.

I
:

'

www.juniper.net Advanced IS-IS Operations and Configuration Options . Chapter 6-7

Advanced Junos Service Provider Routing

Link-State
RTR-A
(A. A. 0)

A (A. B. 1)
(A. C. 2)
(B.A. 3)
(B.D. 3)
rtr-b\
RTR-B RTR-C (C,A. 4)
(C D, 4)
(D.B. 1)
(D.C. 2)
RTR-D

SPF Calculation Example: Part 1

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.

Chapter 6-8 . Advanced IS-IS Operations and Configuration Options www.Juniper.net

 Advanced Junos Service Provider Routing

Link-State Candidate Tree

(A. A. 0) LS Entry Cost to Root (A. A, 0) - 0

(A. B, 1) (A. A. 0) -
6 -

(A. C. 2)
(B, A, 3)
(B. D, 3) RTR-A
(C,A, 4)
(C. D, 4)
{D.B. 1)
(D.C, 2)

WoiMwitls EducationSerwces

SPF Calculation Example: Part 2

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 Advanced IS-IS Operations and Configuration Options . Chapter 6-9

Advanced Junos Service Provider Routing

7 Calculation Example (3 of 6)

Link-State Candidate Tree

(A. A. 0) LS Entry Cost to Root {A, A, 0) - 0

-
fArSHt}- (A. A, 0) e- (A. B, 1) -1
A G. 2)
.
(A. D. 1)
(B. A. 3) (A. C. 2)
B D. 3) RTR-A
.

(CA, 4)
(C. D. 4
(D,B, 1)
'D C, 2)
,

RTR-B

Worldwide Etiuuation Services

SPF Calculation Example: Part 3

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-A's 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-AOto reach itself and Ito
reach RTR-B, so the total cost to RTR-B is 1. The same calculation Is done for RTR-C, and the totai
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 6-10 . Advanced IS-iS Operations and Configuration Options www.junlper.net

 Advanced Junes Service Provider Routing

Link-State Candidate Tree

LS Entry Cost to Root (A. A. 0) - 0

(A. A. 0)
(A. B. 1) -1

(A, C. 2) (A. B. 1) (A, C, 2) - 2

P .
A. 3
D D 3 (B. A. 3)
. .
RTR-A
(C, A, 4) (B. D, 3

(CD. 4)
(D, B, 1)
(D.C. 2)

RTR-B RTR-C

Wo rldvrfitle Educatio n Services

SPF Calculation Example: Part 4

RTR-B is the most recent entry to the tree database, so all RTR-B's 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. 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.

The candidate database is not empty, so the algorithm continues.

www.Juniper.net Advanced IS-IS Operations and Configuration Options . Chapter 6-11

Advanced Junes Service Provider Routing

,
of S)

Link-State Candidate Tree

1
(A. A, 0) LS Entry Cost to Root (A.A,0)-0
(A. D. 1) i (A. A, 0) 0 (A. B. 1) -1

(A. C 2) (A. D. 1) L
_
(A. C. 2) - 2
(B.D. 3)-4 I
(B.A, 3) (A. C. 2)
(B.D. 3) (D.A. 3)
RTR-A
(C. A. 4) (D. D. 3)
(C. D. 1) (G, A. 4)
(D,B. 1) (C. D. 4)
(D,C. 2)

rtr-bV RTR-C

RTR-D

A orlriwiile bducatiunSnr.iiss

SPF Calculation Example: Part 5

Because RTR-C is the most recent entry to the tree database, 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,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.

The candidate database is not empty, so the algorithm continues.

Chapter 6-12 . Advanced IS-IS Operations and Configuration Options www.juniper.net

 Advanced Junes Service Provider Routing

SPF Calcuia'; u. ~ r }le(0 of S)

Link-State Candidate Tree

LS Entry Cost to Root

(A. A, Q) (A.A.O)- 0
(A. D. 1) (A, B. 1) 1
(A. C. 2) (f\ a. ±) (A. C. 2) - 2
IK p -n (B, D, 3) 4
(D.A. 3)
A
(B.D. 3)
RTR-A
fR r> A
(C. A, 4) (D.U, Of
\ /r* n. a\ «
(C. D. 1)
(D.D. 1)
(B.C. 2) ! fD B 11 R

RTR-BVa

RTR-D

SPF Calculation Example: Part 6

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 Advanced IS-IS Operations and Configuration Options . Chapter 6-13

Advanced Junos Service Provider Routing

Cm !

Three consecutive SPF runs can occur before a

mandatory hold-down occurs
.
Keeps the network stable during change
.
5-second hold-down timer is not configurable
A 200-millisecond delay is preconfigured between the
back-to-back SPFs
.
Altered with the spf-delay parameter
.
Supports values that range from 50 to 1000 ms

[edit protocols isis]

user@router# set spf-delay 100

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, 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 milliseconds to 1000 milliseconds (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 ail routers before the SPF calculation begins.

Chapter 6-14 . Advanced IS-IS Operations and Configuration Options www.juniper.net

 Advanced Junos Service Provider Routing

on

Full SPF calculation is run in two stages:

.
Build a shortest-path tree to each IS in the network
.
Calculate the best path to the IP reachability information
advertised by each IS
Only recalculates the IP reachability information
.
Received LSPs are examined for changes
Automatically enabled by default
.
Not configurable using the CLI

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 treefor 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, there is no need 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 Advanced IS-IS Operations and Configuration Options . Chapter 6-15

Advanced Junos Service Provider Routing

ced is

urat mm

IS-IS Operations
-

> IS-IS Configuration Options

IS-IS Routing Options

Education Services

IS-IS Configuration Options

The slide highlights the topic we discuss next.

Chapter 6-16 . Advanced IS-IS Operations and Configuration Options www.juniper.net

 Advanced Junos Service Provider Routing

IS-IS Wide Metrics

TLVs 2, 128, and 130 use 6 bits for metric values
. Maximum metric for an interface is 63
.
Configured metrics larger than the maximum value are
advertised as 63
.
Both TLVs are sent by default
TLVs 22 and 135 use larger metric spaces
. Maximum value for an interface is now 16,777,215
.
Both TLVs are sent by default
Router can be configured to only use the wide metrics
of TLVs 22 and 135
.
Configured for an entire level
.
Only these TLVs are sent in the LSP
.
Removes external route distinction: results in automatic leaking of
redistributed routes from Level Ito Level 2
[edit protocols isis]
user@router# set level 2 wide-metrics-only

Small Metric TLVs

The iS-IS protocol uses 6 bits in type/length/values (TLVs)-2, 128, and 130-to 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.

Continued on the next page.

www.juniper.net Advanced IS-IS Operations and Configuration Options . Chapter 6-17

Advanced Junes Service Provider Routing

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 externa
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.

Chapter 6-18 . Advanced IS-IS Operations and Configuration Options www.juniper.net

 Advanced Junes Service Provider Routing

V; j rr . Ties Operr ,

.
: >f 3)

10 f'
i
mio 10, 10

If fe-O/Q/O.O
Rl iO-22.60/24 R2

user@Rl> show route 192.168.48.1 terse

inet.O: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination P Prf Metric 1 Metric 2 Hext hop AS path

*
192.168.48.1/32 I 18 10 >10.222.60.2

user@Rl> show isis database extensive Rl.00-00 I find TLV

TLVs:

IP prefix: 192.168.52.1/32, Internal, Metric: default 0

IP prefix: 10.222.5.0/24, internal. Metric: default 10
IP prefix: 10.222.60.0/24, Internal, Metric: default 10
IP extended prefix: 192.168.52.1/32 metric 0 up
IP extended prefix: 10.222.5.0/24 metric 0 up
IP extended prefix: 10.222.60.0/24 metric 10 up
(information aeieten for brevity)

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 router's loopback address of 192.168.48.1/32 is 10. This
accounts for the cost to reach R2 over the fe-0/0/0.0 interface (10.222.60.0/24) on Rl in addition
to the metric advertised by R2 for its loopback address (0 by default). A look at the LSDB information
advertised by Rl shows that both TLV 128 (IP prefix) and TLV 135 (IP extended prefix) are being sent
to announce the IP prefixes available on Rl.

www.juniper.net Advanced IS-IS Operations and Configuration Options . Chapter 6-19

Advanced Junes Service Provider Routing

10.000 10 Jl Hi 10
fe-0 /0/0 0
,
.
9
Rl 10.22.50/24 R2

USer@Rl> show route 192.168.48.1 terse

inet.O: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination P Prf Metric 1 Metric 2 Mext hop AS path

*
192.168.48.1/32 I 18 63 >10.222.60.2

user@Rl> show isis database extensive Rl.00-00 | find TLV

TLVs:

IP prefix: 192.168.52.1/32, Internal, Metric: default 0

IP prefix: 10.222.5.0/2 4, Internal, Metric: default 10
IP prefix: 10.222.60.0/24, Internal, Metric: default 63
IP extended prefix: 192.168.52.1/32 metric 0 up
IP extended prefix: 10.222.5.0/24 metric 10 up
IP extended prefix: 10.222.60.0/24 metric 63 up
(Information d&etea for brevity)

Workfwide Education Services

Wide Metrics Operation: Part 2

The Rl router has configured a metric vaiue of 10,000 on its interface towards R2. After committing
the configuration, we see that the metric cost to reach R2's 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.

Chapter 6-20 . Advanced IS-IS Operations and Configuration Options www.juniper.net

 Advanced Junos Service Provider Routing

Wide Metrics Operation (3 of 3)

Tkio.ooo io
4]ljic
V|||r fe-Q/Q/O.O lilF
_

Rl 10.22.60/24 R2
(Wide Metrics Only)
user@Rl> show route 192.168.48.1 terse

inet.O: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

A Destination P Prf Metric 1 Metric 2 Next hop AS path

*
192.168.48.1/32 I 18 10000 >10.222.60.2

user8Rl> show isis database extensive Rl.00-00 | find TLV

TLVs:

IP extended prefix: 192.168.52.1/32 metric 0 up

IP extended prefix: 10.222.5.0/24 metric 10 up
IP extended prefix: 10.222.60.0/24 metric 10000 up
(Informationdeieteafor brevity)

Wide Metrics Operation: Part 3

Sydney has now configured its Level 2 operation to use only wide metrics through the
'

wide-metrics-only command. The metric cost to R2 s 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 Advanced IS-IS Operations and Configuration Options . Chapter 6-21

 Advanced Junos Service Provider Routing

Fecte

The TLV values within an LSP advertise the metric

values , which populate the LSDB
As each router runs the SPF algorithm, each LSP is
examined individually for cost of the outgoing interface
. Thefinal metric calculation uses this cost

Routers can disagree about the cost on a network link

. Rl router sees a cost of 45 to reach R4 router
. R4 router sees a cost of 60 to reach Rl router

10 15 20
® 25 30

Rl R2 R3 R4

JLiniPer Worldwide EducationSemccs

L _

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 link-state PDU 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 Rl
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 Rl 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. This might cause response delays for some end
users and make It challenging for network administrators to troubleshoot the network.

Chapter 6-22 . Advanced IS-IS Operations and Configuration Options www.junlper.net

 Advanced Junos Service Provider Routing

IS-IS Authentication

Authentication can occur within multiple places

. Level 1
. Level 2

. Interface

Three authentication types are supported

.
None (default)
.
Simple
. MD5

MD5 includes an encrypted checksum with all

packets
.
Provides better security than simple type

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 packets-not 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 Advanced IS-IS Operations and Configuration Options . Chapter 6-23

Advanced Junes Service Provider Routing

Level authentication affects all IS-IS PDUs

.
Link-state, sequence number, and hello
Per-interface authentication affects hello PDUs only
and takes precedence over per-level settings
[edit protocols isis]
user@router# show
level 1 {
authentication-key "$9$bssYomPQ69pkq39puhc8X7V2a"; # SECRET-DATA
authentication-type md5;
}
level 2 {
authentication-key "$9$dXVYQDjqQ39gomTz6CAvW8X-ViHmFnCDilh"; # SECRET-DATA
authentication-type simple;
}
interface fe-0/0/0.D (
level 2 {
hello-authentication-key "?9?lsBEclw4JH-d2oGq.CtpOlh7NbgaU"; # SECRET-DATA
hello-authentication-type md5;
}

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 helio
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.

Continued on the next page.

Chapter 6-24 . Advanced IS-IS Operations and Configuration Options www.juniper.net

 Advanced Junos Service Provider Routing
Per-lnterface 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-O/O/0.0 on the slide has MD5 authentication configured for helio PDUs sent at Level 2
using the hello-authentication commands. This hello authentication will be used only on
that specific interface.

www.juniper.net Advanced IS-IS Operations and Configuration Options . Chapter 6-25

Advanced Junos Service Provider Routing

Authentication Control

Level 1 or Level 2 authentication can be disabled for

specific PDUs
. Hello PDUs
. no-hello-authentication

.
Complete sequence number PDUs
.
no-csnp-authentication
.
Partial sequence number PDUs
.
no-psnp-authentication

Stop verifying authentication on all PDUs with the

no-authentication-check command
.
Useful for migration purposes

Selectively Disable Authentication

For easier interoperability with other vendor's implementations 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 18-18 for the specific PDUs
configured.

No Authentication Verification on Received PDUs

To aid you duringa migration period orfortroubleshootingan 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.

Chapter 6-26 . Advanced IS-IS Operations and Configuration Options www.Juniper.net

 Advanced Junes Service Provider Routing

Mesi Groups

IS-IS floods LSPs to all neighbors by default

Certain physical topologies make this flooding
unnecessary
.
R4 router will receive three copies of the same LSP
Once configured, the group members do not reflood
LSPs within the group R2

Rl R4

R3

Default IS-IS Flooding

As mentioned on previous slides, the default IS-IS operation is to flood all link-state PDUs to any
adjacent router for a configured level.

Full-Mesh Topologies
There are times when 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 a LSP generated from the Rl 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 Rl router.

www.juniper.net Advanced IS-IS Operations and Configuration Options . Chapter 6-27

Advanced Junos Service Provider Routing

tCOv -1

Each interface is configured with a group number

.
32-bit numbers can be different on separate interfaces
To prevent an interface from flooding any LSPs, you
can use the blocked keyword

[edit protocols]
user@router# show
isis {
interface ge-0/0/0.0 {
mesh-group 2;
}
interface ge-0/1/0.0 {
mesh-group 1;
}
interface ge-0/2/0.100 {
mesh-group blocked;
}
}

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.

Chapter 6-28 . Advanced IS-IS Operations and Configuration Options www.Juniper.net

 Advanced Junos Service Provider Routing

Ovarfoad. ;

Allows advertisement of routing information to

neighbors while indicating the node should not be
used for transit traffic
.
Other routers Ignore the LSP during SPF calculation
. Turns off the attached bit

Can be set permanently or with a timeout value

. Timer is between 60 and 1800 seconds
.
Timer only runs after rpd starts
[edit protocols]
user@router# show
isis {
overload;
interface so-0/0/0.0;
interface ge-0/1/0.0;

u3er@router> show isis database

IS-IS level 2 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
Router-1.00-00 0x36f 0x8cf7 1007 LI L2
Router-2.00-00 0x37f 0x4c3a 1067 LI L2 Overload

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 situations-first, 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 overioad 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 Advanced IS-IS Operations and Configuration Options . Chapter 6-29

Advanced Junes Service Provider Routing

DIS router sends CSNP packets on a LAN interface

every 10 seconds
Can be altered on a per-interface basis
. Value can be between 1 and 65,535 seconds
[edit]
user@router# run show isis interface detail
IS-IS interface database:
ge-0/2/0.0
Index: 3, State: 0x6, Circuit id: 0x2, Circuit type: 2
LSP interval: 100 ms, CSNP interval: 10 s
Level Adjacencies Priority Metric Hello (s) Hold (s) Designated Router
2 1 64 10 3 9 R1.02 (us)

[edit]
user@router# set protocols isis interface ge-0/2/0 csnp-interval 40

[edit]
user@router# run show isis interface detail
IS-IS interface database;
ge-0/2/0.0
Index: 3, State: 0x6, circuit id: 0x2, Circuit type: 2
LSP interval: 100 ms, CSNP interval: 40 s
Level Adjacencies Priority Metric Hello (s) Hold (s) Designated Router
2 1 64 10 3 9 R1.02 (us)

' o rldwirie Bducation Services :

wvvwjuniper.rief | S-SO;

CSNP Packets on a LAN Interface

By default, each 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 qulcktimer 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 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 eras long as 65,535
seconds.

Chapter 6-30 . Advanced IS-IS Operations and Configuration Options www.juniper.net

 Advanced Junos Service Provider Routing

.
alias Adva&iceci IS
Hons

IS-IS Operations
IS-IS Configuration Option?
-

>IS-IS Routing Policy

WoHriwide BEtucationServiGes

IS-IS Routing Policy

The slide highlights the topic we discuss next.

www.juniper.net Advanced IS-IS Operations and Configuration Options . Chapter 6-31

Advanced Junes Service Provider Routing

User-defined import policies are allowed

.
Could impair the completeness of the LSDB
IS-IS route information in an LSP is populated from
the configuration within [edit protocols is is
.
Subnets are placed into an LSP for advertisement into the
network
.
Can block internal and external subnets in export policy
. Different behavior than OSPF

Worldwicls Education Services

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
link-state PDU (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 only affects external subnets.

Chapter 6-32 . Advanced IS-IS Operations and Configuration Options www.juniper.net

 Advanced Junos Service Provider Routing

'
111

Route redistribution requires an export policy at the

global IS-IS level
.
Routes from other IGPs (RIP or OSPF)
.
Routes from other protocols (static or aggregate)
Beware of routing loops
.
When multiple redistribution points exist
.
Route table preference values can cause redistributed routes to be
preferred

[edit policy-options]
userSrouterf show
policy-statement redistribute-routes-into-isis {
term find-other-igp-routes {
from protocol [rip ospf];
then accept;
}
}

Route Redistribution in IS-IS

You can add routes to an advertised LSP through an export poiicy. A new TLV is added to the update
for each route accepted by the poiicy. 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 Advanced IS-IS Operations and Configuration Options . Chapter 6-33

Advanced Junes Service Provider Routing

IS-IS [ iiutes on Ex .

Change metric values for IS-IS routes

.
Use the metric keyword in a policy
.
Configured value placed in appropriate LSP for that level
Administrative marking for policy matching
.
Use the tag keyword in a policy
. Allows other routers to match on the defined value
. Useful for selective redistribution

[edit policy-options]
policy-statement example-isis-policy-l {
term set-static-metric {
from protocol static;
then {
metric 40;
tag 68;
accept;
}

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.

Chapter 6-34 . Advanced IS-IS Operations and Configuration Options www.junlper.net

 Advanced Junos Service Provider Routing

Case study topology

Rl R3
r%loO 10.200.0.3
lU. UU.U.d

RIP

RIP S- SArea 49 1111

.
IS-IS Area 49.2222

V
\ l-:;
:
FM Rt:
loO 10.200.0.2 oO 10.200.0.4 0010.200,0,6

. .

Case Study Topology

The slide displays the case study topology that will be use in subsequent slides. Rl, R2 and the host
all run RIP.

www.junlper.net Advanced IS-IS Operations and Configuration Options . Chapter 6-35

Advanced Junos Service Provider Routing

Case Study? . tes (2 of S|

Case study background

*
The RIP router is advertising routes
.
Redistribute a single RIP route into IS-IS
-

Advertisethe 20.20.1.0/24 RIP route

. The Rl and R2 routers have an IS-IS default route
.
Default route is generated by the attached bit
. Redistributethe default route into RIP

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.

Chapter 6-36 . Advanced IS-IS Operations and Configuration Options www.juniper.net

 Advanced Junos Service Provider Routing

[edit]
Redistribute the RIP userSRl* show polloy-statement redlstrlbnte-rip
term 1 {
route into IS-IS from {
protocol rip;
route-filter 20.20.1.0/24 enact;
>
then accept;
}
[edit]
user@Rl# show protocols
isis {
export redistribute-rip;
)

[edit]
Redistribute the IS-IS user9R2# show policy-statement redlstribute-default
term 1 {
route into RIP from {
protocol isis;
route-filter 0.0.0.0/0 exact;
}
then accept;
)
[edit]
user@R2# show protocols
rip {
export redistribute-default;
>

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 nnatch conditions
were used, creating a logical AND. This policy will then be applied under [edit protocols
isis] by performing a set protocols isis export redistribute-rip command.

Redistribution of Default Route

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 Advanced IS-IS Operations and Configuration Options . Chapter 6-37

Advanced Junes Service Provider Routing

Redistribute the default route from IS-IS into RIP

.
High preference 160 to low preference 100
usergR2 show route 0/0

inet.0: 35 destinations, 38 routes (35 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

0 0 0
. . 0/0
. *[RIP/10 0] 00:03:18, metric 2
> to 10.200.5.2 via fe-0/0/1. 210
[1SIS/160] 00:24:48, metric 11
> to 10.200. 62. 9 via fe-0/0/0.221
*
The RIP route is the active route

.
Modify the IS-IS external preference to 90
[edit]
user@R2# show policy-statement rip-prefejreuce
term 1 {
from {
protocol rip;
route-filter 0.0.0.0/0 exact;
}
then {
preference 90;
accept;

iViitldwicluEducatitmServiGes Mcwjiiniper ntt

. I 6-33

Redistribution of Default Route

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.

Chapter 6-38 . Advanced IS-IS Operations and Configuration Options www.Juniper.net

 Advanced Junes Service Provider Routing

Case Study: External Routes (5 of S)

Mutual redistribution
. The default route has been fixed
.
The RIP route is now a higher preference 100 then the
external IS-IS preference 90
user@R2> show route 0/0

inet.O: 35 destinations, 38 routes (35 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

0 0 0 0/0
. . . [ISlS/90] 00:03:09,
*
metric Z
> via ge-O/O/ 0. 0
[RIP/100] 00: 19:40,metric 2
> to 10.200.5.3 via ge-0/0/1.210

The Result

The result of the preference change is now a default that points properly to the IS-IS router.

www.Juniper.net Advanced IS-IS Operations and Configuration Options . Chapter 6-39

Advanced Junos Service Provider Routing

The Junos OS is built to handle a large numbers of

external routes
.
You often do not place Internet routes into IS-IS
» Usually occurs because of a configuration mistake
.
Can leave a portion of your network unusable
Limit can be placed on the number of routes allowed
using a routing policy
. When the limit is reached:
External routing information no longer transmitted in LSPs
. Overload state Initiated
.
Requires a manual step to fix the problem
[edit protocols isis]
user(arouter# show
level 1{

j e Ix eKport'-lxmit J jj
level 2{

ucation Services

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 as 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 link-state PDUs. The external routing information is no longer transmitted in
the link-state PDUs as well. The local router remains in this state until the number of external routes
returns to a level below the configured limit. This 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.

Chapter 6-40 . Advanced IS-IS Operations and Configuration Options www.juniper.net

 Advanced Junos Service Provider Routing

Summary

In this chapter, we:

.
Displayed and interpreted the IS-IS LSDB
.
Performed advanced IS-IS configuration options
.
Implemented IS-IS routing policy

www.jon iper.net, | 6-41

This Chapter Discussed:

The display and interpretation of the IS-IS LSDB;

Advanced IS-IS configuration options; and

.
The implementation of IS-IS routing policy.

www.Juniper.net Advanced IS-IS Operations and Configuration Options . Chapter 6-41

Advanced Junes Service Provider Routing

Heview Questiogis

1 .
What is the maximum default IS-IS link metric? Can
this be changed? How?
2 .
What are the different forms of IS-IS authentication?

3 . What are the default policies for IS-IS?

Review Questions
i.

2 .

3.

Chapter 6-42 . Advanced IS-IS Operations and Configuration Options www.Juniper.net

 Advanced Junes Service Provider Routing

Lai Ss Aiwancei . |i8ration

Options and Routing Pcillcy

Configure, monitor, and troubleshoot the operation of

an IS-IS network. Additionally, configure interface
metrics, wide metrics, and authentication.

Configure routing policies to redistribute routes

between interior gateway protocols.

Lab 5: Advanced IS-IS Configuration Options and Routing Policy

The siide provides the objectives for this lab.

www.juniper.net Advanced iS-IS Operations and Configuration Options . Chapter 6-43

Advanced Junos Service Provider Routing

Chapter 6-44 . Advanced IS-IS Operations and Configuration Options www.juniper.net

juniperNETWORKS

Advanced Junos Service Provider

Routing

Chapter 7: Multilevel IS-iS Networks

Advanced Junos Service Provider Routing

After successfully completing this chapter, you will be

able to:
.
Explain the default operation in a multilevel IS-IS network
. Describe IS-IS address summarization methods
.
Configure and monitor a multilevel IS-IS network

Worldwide Education Services

This Chapter Discusses:

.
The default operation in a multilevel IS-IS network;
IS-IS address summarization methods; and

Configuration and monitoring of a multilevel IS-IS network.

Chapter 7-2 . Multilevel IS-IS Networks www.juniper.net

 Advanced Junos Service Provider Routing

level IS-IS Networks

> Level 1 and Level 2 Operations

Multilevel Configuration

Level 1 and Level 2 Operations

The slide lists the topics we cover in this chapter. We discuss the highiighted topic first.

www.juniper.net Multilevel IS-IS Networks . Chapter 7-3

Advanced Junes Service Provider Routing

L2
-
2
/
® Area 49,1111
L2PDU
L2
L2

Area 49.2222
L2PDU
L2 L2
12 Area 49.3333 Area 49,1111
L2 PDU Area 49.1111
L2PDU
L2PDU
Area 49,2222
L2 Area 49,2222
2 L2PDU :

L2PDU
/
-

Area 49,3333

\ L2 PDU
Ai'os 49 333:-;
L2PDU
\
Area 49,1111
\ Area 49.2222 Area 49,3333
\

L2 = Interface configuration

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 ail 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.

Chapter 7-4 . Multilevel IS-IS Networks www.juniper.net

 Advanced Junos Service Provider Routing

Area 49,4444
LI PDU

Area 49.4444

LI = interface configuration

Worldwide Educati

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 IS4Sarea (49.4444). Level 1 LSPfloodingwill reach all routers in the network due to
the presence of a single area.

www.juniper.net Multilevel IS-IS Networks . Chapter 7-5

Advanced Junos Service Provider Routing

i :
iiJ

/
L2
LI

L2 LI
/
2
LI
LI
L2 L2
Area 49.5555
LI PDU
Area 49.5555
L2PDU Area 49.7777
LI PDU
Area 49.8666
LI i L2PDU L2 Li
L2
I Area
Area 49.7777
L2 PDU

Area 49.5555 Area 49.6666 Area 49.7777

-

LI or 12 = Interface configuration

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.

Chapter 7-6 . Multilevel IS-IS Networks www.juniper.net

 Advanced Junos Service Provider Routing

Operat
An L1/L2 IS-IS network operates in a similar fashion
to an OSPF NSSA with no summaries
. Local LI routes are advertised into Level 2
. External routes can be advertised into an LI area

The LI/12 border is a natural route boundary

s L2 routes are not advertised into LI areas by default
.
External LI routes are not advertised to Level 2 by default
.
Route leaking policies are used to modify this default behavior
.
Using only wide metrics eliminates internal/external distinction
L1/L2 attached routers set the attached bit in their
11 LSPs
.
Ll routers install a locally generated 0/0 default route to
the closest L2 attached router
.
Disable with ignore-attached-bit command

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 Ll/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 i routes into Level 2, as they will all appear to be internal routes.
Continued on the next page.

www.Junlper.net Multilevel IS-IS Networks . Chapter 7-7

Advanced Junes Service Provider Routing

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-attaohed-bit
statement at the [edit protocols isis] configuration hierarchy.

Chapter 7-8 . Multilevel IS-IS Networks www.juniper.net

 Advanced Junos Service Provider Routing

A tac

Level 2 to Level 1 route leaking policy in place

.
Limited LSP flooding scope provides some protection from
software or network faults
.
Default route unnecessary

L2
e \

Ll
2

ignore-attached-bit
12
Ll

1
.

?
.

L2

Area 49.6666 Area 49.7777

V

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 route 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 IS-IS Networks . Chapter 7-9

Advanced Junes Service Provider Routing

Level i and Level 2 Operations

Multilevel Configuration

mm

Multilevel Configuration
The siide highlights the topic we discuss next.

Chapter 7-10 . MultilevellS-IS Networks www.juniper.net

 Advanced Junos Service Provider Routing

Each IS-IS interface operates at both Level 1 and

Level 2, by default
.
Disable a specific level to not have the interface operate at
that level
.
loO interface will be passive at both levels in this example
.
Disable at a particular level to prevent loO address advertisement
in that level

protocols {
isis {
interface so-O/O/O.0 {
level 1 disable;
}
interface ge-0/1/0.0 {
level 2 disable;
}
interface loO.O;
}
}

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 ail
neighbors. If an adjacency can be formed between two routers, it will. One consequence of this
default, however, is that you might form both an Level 1 and 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 loO . 0 interface within the IS-IS protocol, even when
the router's 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 loO interface
will not be advertised in TLV128 orTLV 135, making the loopback address unreachable. Note that in
most oases you must run the IS-IS protocol on the loO interface for proper operation because the
'
router s NET is normally assigned to loopback Interface for resiliency reasons.

Continued on the next page.

www.juniper.net Multilevel IS-IS Networks . Chapter 7-11

Advanced Junos Service Provider Routing

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 router s
loopback address in a particular level by disabling that level in the loO. 0 statement in the isis
stanza.

Chapter 7-12 . Multilevel IS-IS Networks www.juniper.net

 Advanced Junes Service Provider Routing

Case Study: Ron - i ing

R3 R5

Lv
/

11

Area 49.0001

Level 2 routes are to be advertised into Area 49.0001

*
Requires routing policy on L1/L2 area border router R3
.
Use the from level 2/to level 1 syntax

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 R3, the L1/L2 area border router (ABR), specifying that the
matching routes are Level 2 and will be advertised in Levell.

www.juniper.net Multilevel IS-IS Networks . Chapter 7-13

Advanced Junes Service Provider Routing

Case Sim " 'its Leaking Policy

Use a policy to advertise (leak) routes across an

11/12 area border
Routes advertised from an L2 area into an LI area
have the up/down bit set to down
. Ensures that another L2 router will not re-advertise the
route back Into an L2 area to avoid routing loops
[edit policy-options]
user@router# show
policy-statement route-leak {
term L2-to-Ll {
from {
protocol isis;
level 2;
route-filter 192.168.16.0/20 orlonger;
}
to 1eve1 1;
then accept;

WftrliUvnli; Education Services

Policy Used to Advertise Routes

Because the L1/L2 border router naturaliy stops the transmission of Level 2 routes into a Level i
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 allow granular control about the desired direction of route leaking.

Once the routing policy is applied to the IS-IS protocol using the export route-leak command,
the Level 2 routes are inserted into the Level 1LSP 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 using an export command, the
external routes are included in the Level 2 LSPs.

Continued on the next page.

Chapter 7-14 . Multilevel IS-IS Networks www.juniper.net

 Advanced Junes Service Provider Routing

Up/Down Bit Prevents Looping

Previous siides described the default action of an 11/12 router with regards 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 where both router Rl and router R2 are L1/L2 routers in IS-IS area
49.1111. If Rl has a policy to advertise Level 2 routes into Level 1, then Rl will include the Level 2
routes in its Level 1 LSP. As this LSP is flooded throughout area 49.1111 it eventually arrives at R2.
The default action for R2 is to take ali information from its Level 1 database and advertise it into the
backbone using its Level 2 LSP. If R2 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.

www.juniper.net Multilevel IS-IS Networks . Chapter 7-15

Advanced Junos Service Provider Routing

The L1/L2 area border is a natural place to

summarize routing information
.
Override the default route flooding between the areas with a
routing policy
Create aggregate routes in local routing table
.
Policy required to advertise aggregate routes into another
level-use from /to level for maximum control
[edit policy-options]
user@router* show policy-statement extexnal-Ll-sirnmary-route
term on-the-LlL2-router {
from {
protocol aggregate;
route-filter 172.16.20.0/22 exact;
}
to level 2;

then accept;
}
- r:r
-

l vVorlclvvide! [lucaliuii Services

Summarize Routes at the L1/L2 Router

Routes that are naturally bound by the Li/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 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 Li/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.

Chapter 7-16 . Multilevel IS-IS Networks www.juniper.net

 Advanced Junes Service Provider Routing

tudy
i oute mmmmmmmmm.

R3 RL
10.0.4.0/22
L2

LI

Rl

LI

Area 49.0001 Area 49.0002

Internal Level 1 routes can be summarized

.
Requires routing policy and a local aggregate route
.
For example, suppress specific routes in the 10.0.4.0/22
block and advertise a single 10.0.4.0/22 summary route

Internal Level 1 Route Summarization

Internal Level 1 routes are automatically advertised in a Level 2 LSP into the Level 2 backbone. The
Junes 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 R5, as shown in the following
output:

user@R5# 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 *[IS-IS/18] 00:28:50, metric 20

> to 10.0.2.2 via at-0/2/1 0 .

10.0.5.0/24 *[IS-IS/18] 00:28:50, metric 30

> to 10 0 2 2
. . . via at-0/2/1.0
10.0.6.1/32 *[IS-IS/18] 00:28:50, metric 20
> to 10.0.2.2 via at-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 R3.

www.juniper.net Multilevel IS-IS Networks . Chapter 7-17

Advanced Junos Service Provider Routing

Sample policy for summarizing internal Level 1 routes

.
Requires local 10.0.4.0/22 aggregate definition on R3
.
Use of to ensures that summary route is not injected into
the Level 1 area
[edit]
user@R3# show policy-options policy-statement internal-LI-summary-route
term local-sunimary-route {
from {
protocol aggregate;
route-filter 10.0.4.0/22 exact;
}
to level 2;
then accept;
}
term suppress-specifics {
from {
route-filter 10.0.4.0/22 longer;
}
to level 2;
then reject;
}

Worldwitio EtluoationServiues

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 R3 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 R5 in the Level 2 LSP generated by
R3.

After applying the internal-Ll-summary-route policy asan export policy in R3's IS-IS
instance, we can confirm its success on R5:

user@R5# 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 MIS-IS/165] 00:00:20, metric 20

> to 10.0.2.2 via at-0/2/1.0

Chapter 7-18 . Multilevel IS-IS Networks www.Juniper.net

 Advanced Junes Service Provider Routing

Apply IS-IS policies at the global level of the isis

stanza
.
Multiple export polices can be applied, or a single policy with
multiple terms can be used
[edit protocols isis]
user@R3# show

export [ external-Ll-sumraary-route internal-Ll-summary-route ] r

interface at-0/2/0.0 {
level 1 disable;

}
interface at-0/2/1.0 {
level 2 disable;

}
interface loO.O;

Apply Export Policy at Global Level of the IS-IS Instance

One or more export poiicies can be appiied at the globai levei of an IS-IS instance, as shown on the
slide. Both the external-Ll-summary-route and internal-Ll-suramarY-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 rej ect action.

www.juniper.net Multilevel IS-IS Networks . Chapter 7-19

Advanced Junos Service Provider Routing

mMmmmry

In this chapter, we:

.
Examined the default operation of a multilevel IS-IS network
. Described IS-IS summarization methods
.
Learned to configure and monitor a multilevel IS-IS network

Worldwide Education Services

This Chapter Discussed:

The default operation of a multilevel IS-IS network;
IS-IS summarization methods; and

.
Configuration and monitoring a multilevel IS-IS network.

Chapter 7-20 . Multilevel IS-IS Networks www.Juniper.net

 Advanced Junos Service Provider Routing

Review Questions

1 . How are areas segmented in an IS-IS L1/L2

network?

2 . An IS-IS L1/L2 network is similar what type of OSPF

environment?

3 .
Where is IS-IS route leaking performed? What steps
are needed to accomplish this leaking?
4 . Where is IS-IS route summarization performed?
How is this route summarization accomplished?
What types of routes can be summarized?

i
,
/:
- . .

Review Questions
i .

2 .

3 .

www.juniper.net Multilevel IS-IS Networks . Chapter 7-21

Advanced Junos Service Provider Routing

Configure, monitor, and troubleshoot the operation of

a multilevel IS-IS network.

Once operational, configure route leaking and

address summarization.

Lab 6: Configuring a Multilevel IS-IS Network

The slide provides the objectives for this lab.

Chapter 7-22 . Multilevel iS-IS Networks www.juniper.net

jumper NETWORKS

Advanced Junos Service Provider

Chapter 8: BGP
Advanced Junos Service Provider Routing

Chapfer Objectives

After successfully completing this chapter, you will be

able to:
.
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

jrldwitjy Education Services wwjiuniperneH Q*-

This Chapter Discusses:

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.

Chapter 8-2 . BGP www.juniper.net

 Advanced Junos Service Provider Routing

-
>Review of BGP

BGP Operations
BGP Path Selection and Options
Configuration Options

Review of BGP

The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.Juniper.net BGP . Chapter 8-3

Advanced Junos Service Provider Routing

mmmM

BGP is the core routing protocol within the Internet

BGP is a path-vector BGPviewsthe Internet as a
protocol used for collection of autonomous
interdomain routing. systems.
AS 65502

1
!

BdP AS 65504
S
!

&

1 AS 65503

Note: BGP Is an IETF standard defined in RFC 4271 (supersedes RFC 1771).

WprldWiUe Education ServMitis

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
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 8-4 . BGP www.juniper.net

 Advanced Junes Service Provider Routing

mm: m©

BGP is typically used in large enterprise environments

where multiple ISP connections exist, and in all service
provider environments
ISP A

AS 65502
CustomerA
Single-homed customers
typically use a default route
BGP to the Internet.
AS 6550]

Customer B
s

/
Static Routing
AS 65503

Multihomed customers use

BGPto control inbound and
ISPB
outbound traffic

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 customer's addresses to the customer. Normally, a single-homed
'

network uses addresses assigned by the provider from the provider s 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. BGP s policy controls provide the ability to optimize inbound and outbound traffic flows
based on a network's 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 8-5

Advanced Junes Service Provider Routing

V .
I

BGP peers can reside in different ASs or the same AS

.
Peers in different ASs use the external session type (EBGP)
.
Peers In the same AS use the internal session type (IBGP)
AS 65502
IBGP is not used
IBGP is used because
because a single BGP
speaker exists. IGP
multiple BGP speakers
IBGP exist.

i
IGP ® EBGP IGP
1

AS 65501 AS 65504
IGP
IBGP

AS 65503

'

: : ,; ; .

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 AS's topology). BGP uses the loopback
interfaces for stability reasons-these 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. BGP s TCP session is established using regular routing tables.

Chapter 8-6 . BGP www.juniper.net

 Advanced Junos Service Provider Routing

BGP peering sessions are manually defined and rely

on TCP connections
.
No automatic neighbor discovery

BGPNeighborStates
TCP Connectivity
Idle OpenSent
Connect OpenConfinn
Active Established

Rl R2

m -
TCP Connectivity

BGP Connectivity V
'

EsS biiihedNei

'

PGf lAorlriviiiletiliic-iiioriScriioei

BGP Peering Sessions

Uniike 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 ail 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.
Continued on the next page.

www.juniper.net BGP . Chapters-?

Advanced Junes Service Provider Routing

BGP Peering Sessions (contd.)

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
'

system s 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 OpenConflrm 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.

Chapter 8-8 . BGP www.juniper.net

 Advanced Junos Service Provider Routing

mm:-

BGP messages are used to establish and maintain

BGP peering sessions
.
All BGP messages use a common header

BGP Mess age Types

Open Keepalive
Update Notification

Refresh

Rl R2

© -
TCP Connectivity

BGP Connectivity V
V

Establ ished Neigh bors

Worlthvtile Eti'iualiun Scn-ices

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 device s routing policy, this routing information is
either added to the routing table or ignored.
Keepalive: BGP does not use keepalives at the Transport Layer-TCP fills this need.
Instead, peers exchange keepalives as often as needed to ensure that the hold timer
does not expire.

Continued on the next page.

www.juniper.net BGP . Chapter 8-9

Advanced Junes Service Provider Routing

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 acknowiedged (using TCP). The route refresh message supports
soft clearing of BGP sessions by ailowinga 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 8-10 . BGP www.juniper.net

 Advanced Junos Service Provider Routing

BGP update messages include path advertisements

and their associated attributes
.
Can also list withdrawn routes that are no longer reachable

Ro ute r co m pa res attri b utes

associated with update
messages to select the best path

e
Rl RouteX R2 RouteX fo

© Wished Neiehbors stabUshed N9:eht>.>

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 8-11

Advanced Junes Service Provider Routing

BGP attributes are included in the update messages

and describe the BGP prefixes received from a peer
.
Attributes are used to select the best path

Route X
e RouteX
Rl R3
R2

Jf-. -J O(UF>'i f\'

<Esigblished NeighbCTs> < teblished rfei ibore>-
Some common examples include:

Common BGP Attributes

Next Hop Local Preference AS Path

Origin j MED Community

Ettucaf ion Services

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 route s 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 8-12 . BGP www.Juniper.net

 Advanced Junes Service Provider Routing

ligh- '

"

ISP A ISPC
(AS 65001) (AS 65003)
V

Static default
route to ISP A
Static route to Customer A

v
..
....

Customer A is single-homed to ISP A and CustomerB \

Customer A uses 172.20.21,0/24 subnet which was
,
(AS 65501)
assigned by ISP A
V

11 1 1 orlrtwicle I (liuuiliun Sur.luBS

.

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
'
A s prefix.

www.juniper.net BGP . Chapter 8-13

Advanced Junes Service Provider Routing

A9 s ¥mmmm

0 I can reach

16
172.20.0.0/16
'

r
:
R3

Hi :

ISP A R4

(AS 65001)
V I

X
/

Rl

CustomerA lean reach

:
Static route for 172,20.21.0/24 172.20.210/24
to Customer A
..
.... ..

Note: All BGP routes start as somethingotherthan BGP routes.

Wnrltlvvitlfi Education Services

ISP A's Network

The slide highlights a portion of ISP A's 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 A s 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 8-14 . BGP www.juniper.net

 Advanced Junos Service Provider Routing

ISP A's Aggregate

172.20.0.0/16 is reachable throug
AS 65002 and AS 65001

172,20.0.0/16 is reachable
172.20,0.0/16 is reachable through AS 65003, AS 65002
ISPB and AS 65001
through AS 65001
(AS 65002)
AN

ISP A ISPC

\ (AS 65001) (AS 65003) 1

.
A

ISP A advertises an aggregate

A
of 172.20.0.0/16 through
.

BGPto ISP B
rx
CustomerB
Custom erA
(AS 65501)

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 ISPC. 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.Junlper.net BGP . Chapter 8-15

Advanced Junos Service Provider Routing

172.31.128.0/20 is reachable through A3

65002, AS 65003 and AS 65501

172.31.128.0/20 is reachable
ISPB through AS 65003 and AS
(AS 65002) 65501

ISP A ISPC
(AS 65001) (AS 65003)

172.31.128.0/20 is
\\ reachable through AS
.
A
Defaultstatic route 65501
A
.

Customer B advertises its

Customer B
Customer A 172.31.128.0/20 network (AS 65501)
through BGPto ISPC

Wprldwicle EducatlonServio

Customer B's Aggregate

Customer B is currently a single-homed network but is planni ng 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 B's 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 8-16 . BGP www.juniper.net

 Advanced Junes Service Provider Routing

Cus
ISP B chooses the best path and
advertises only that path

172,31.128.0/20 is reachable 172.31.128.0/20 is reachable

through AS 65002 and AS 65501 ISPB through AS 65003 and AS 65501
(AS 65002)

A
.

ISPC

(AS 650O1) (AS 65003)

Ts 172.31.128.0/20 is
w \\ reachable through
AS 65501
Default static route

\ %
Customer B advertises its f CustomerB
Customer A
172.31.128.0/20 network (AS 65501)
through BGP to ISP B and ISP C

6f i\orlilwicle tlo

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 B's prefix both
from ISPC 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 B's 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 A's 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 8-17

Advanced Junos Service Provider Routing

IBGP sessions are usually established between

loopback addresses
.
Uses IGPto maintain sessions regardless of physical topology
EBGP sessions are usually established using the IP
addresses of the physically connected interfaces

v AS 65503
I

AS 65502 ge-O/O/l O, S 0/0/1 £ R2

/(.I) 172.24.10/30 (.2)

IGP . / / .

\ ibgpV1
If failure occurs, loopback-
| based IBGP sessions stay up
over workinglinks

Wurldwlile Education Sen.ices

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 ASs. 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 8-18 . BGP www.juniper.net

 Advanced Junos Service Provider Routing

! ' - .'IP

[edit]
user@router# show routing-options
router-id 192 168 .100 .1;
autonomous-system |65503?| *--- Device s assigned AS number

[edit]
user@router# show protocols bgp
group jint-essoTI { BGPgroup names are user-defined
type [internai; |
local-address 192.168.100.1;

neighbor 192.168.100.2;
BGP session type determines if the
group ext-65501 { peeringsession is IBGP or EBGP
type laxternalTI
peer-as |65501; | EBGP peer s assigned AS number
neighbor 172.30.1.2;

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 system s router identifier (RID) and the local AS
number. Optionally, you can configure the system's 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 peer s loopback address. The local-address is the local device's 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.

Continued on the next page.

www.juniper.net BGP . Chapter 8-19

Advanced Junes Service Provider Routing

Configuring BGP (contd.)

As mentioned on the slide, the session type determines if 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 orthe
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 xlOO {
neighbor 10.1.1.1;
)

[edit protocols bgp]

user@Rl# commit
[edit protocols]
bgp'
'

Error in neighbor 10.1.1.1 of group xlOO:

peer AS number must be configured for an external peer
error: configuration check-out failed

Chapter 8-20 . BGP www.juniper.net

 Advanced Junos Service Provider Routing

z mm

BGP protocol exchanges can be MD5 authenticated

Hitless key rollover is an option
[edit]
u5ec@Eoutec# show protocols bgp
[authentication-key juniper; | Global Level
gcoup mt-eSSDS {
| authentication-key junlperT] *-
Group Level
'~"

type internal;
local-address 192.168.100.1;
neighbor 192.168.100.2;
(
group ext-655 01 (
type external;
peer-as 65501;
neighbor 172 .30 .1.2 (
jauthentication-key juniper; Neighbor Level
)
>

BGP Authentication

All BGP protocol exchanges can be authenticated to guarantee that only trusted routing devices
'

participate in the AS s routing. By default, authentication is disabled. You can configure IV1D5
authentication. The IVID5 algorithm creates an encoded checksum that is included in the transmitted
packet. The receiving routing device uses an authentication key (password) to verify the packet's
MD5 checksum.

Hitless Key Roiiover

Hitless authentication key roiiover 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.
[edit protocols bgp]
authentication-key-chain "bgp key chain"
group int-65503 {
type internal;
local-address 192.168.100.1;
neighbor 192.168.100.2
}

Continued on the next page.

www.Juniper.net BGP . Chapter 8-21

Advanced Junos Service Provider Routing

Hitless Key Rollover (contd.)

[edit security]
authentication-key-chains {
key-chain "bgp key chain" {
key 1 {
secret juniperl;
start-time 2011-03-01.02:00:00;
}
key 2 {
secret juniper2;
start-time 2011-04-01.02:00:00;
}
)
)

Chapter 8-22 . BGP www.juniper.net

 Advanced Junos Service Provider Routing

ISP

Review of BGP
-

>BGP Operations
BGP Path Selection and Options
Configuration Options

BGP Operations
The slide highlights the topic we discuss next.

www.juniper.net BGP . Chapter 8-23

Advanced Junos Service Provider Routing

BGP stores routes in three main routing information

base memory tables
.
Adjacency-RIB-IN: Contains all received routes from each
peer
. RIB-LOCAL; Contains routes the local router uses to forward
traffic
.
Adjacency-RIB-OUT: Contains all advertised routes sent to
each peer
Only active BGP routes in the local routing table can
be advertised to peers
.
Single, best BGP path is advertised
. Can use advertise-inactive when BGP route is not
active, but only the single, best, inactive BGP path is
advertised

BGP Route Tables

BGP uses three different storage tables known as routing information bases (RIB) 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 router's routing
table rules. For example, if the router knows about a particular route through both 1S-IS and BGP, the
IS-IS route will be active in the local routing table because of the default Junos OS protoco
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 8-24 . BGP www.juniper.net

 Advanced Junos Service Provider Routing

BGP

1 IBGP advertises routes

.
2 EBGP advertises routes
.

learned from EBGP, and... learned from IBGP or EBGP, but.,

AS 65501
AS 65510
RouteX

BGP

, y igp v.
-

BGP

AS 65502 AS 65503

3 IBGP does not advertise

.

any routes learned from IBGP

"

if Worldwide Education Services

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 8-25

Advanced Junes Service Provider Routing

GP Route Propagation

To avoid loops, BGP speakers do not propagate

IBGP-received routes to other IBGP peers
.
Afull mesh is required to ensure all IBGP speakers have
consistent BGP routing information
Rule prohibits R2
from advertising
AS 65503 route X to R3
RouteX RouteX

AS 65502 l A

Solution is to have Rl and R3

become IBGP neighbors

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, afull 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. Rl 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 Rl and R3. (It is irrelevant whether the two routers are directly connected.)

If IBGP routers readvertise 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 8-26 . BGP www.juniper.net

 Advanced Junes Service Provider Routing

mmmm

Reasons routes might not be installed in the

RIB-LOCAL:
. Martian
.
Import policy
.
Unresolvable next-hop
Number one reason: Unresolvable next hop
user@routei:> show route hidden extensive
inet.O: 24 destinations, 24 routes (23 active, 0 holddown, 1 hidden)
172.19.20.0/24 (1 entry, 0 announced)
BOB Preference: 17 0/-101
Next hop type: Unusable
I State: <Hidden Int Ext>
Local AS: 1 Peer AS: 1
Age: 13:53 Metric2: 0
Task: BGP _
1 192.168.10.1+179
.

AS path: 2 I
BGP next hop: 10. 10. 1. 2
Localpref: 10 0
Router ID: 192.168.10.1

Hidden Routes

You might expect ail 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 route's 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 8-27

Advanced Junes Service Provider Routing

By default, IBGP peers do not change the next hop for

routes received from EBGP peers
j By default, the next-hop valuefor the route
X advertisement remains 172.24.1.1
Howclolgetto
AS 65503
172.241,1?
Route X RouteX
AS 65502

®/{I} 172.24.1.0/30

urlfivvitle Educalion Sor.iixs

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, Rl receives a route from its EBGP peer with the next-hop
attribute set to 172.24.1.1. Rl 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 Rl 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 router's peers can reach the next hop of the
routes that router sends, as long as the BGP session remains established.

Chapter 8-28 . BGP www.juniper.net

 Advanced Junos Sen/ice Provider Routing

lap mmMmnem

BGP next-hop solutions:

»Next-hop self
.
Usea policy to alter the next-hop value
.
Change the BGP next hop to be the address of the IBGP peer
.
Exportdirect routes into the IGP
.
Use a policy to advertise external interface prefixes to IBG P peers
Adds external interface prefixes to the IGP routing tables
.
IGP passive interface
.
IGP advertises external interface prefixes to IBGP peers.
no adjacency formed
.
Adds external interface prefixes to the IGP routing tables
. Static routes
.
IGP adjacency formed on inter-AS links to EBGP peers
5

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 attribute s 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
'

peer s 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 vaiue. 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.

Continued on the next page.

www.juniper.net BGP . Chapter 8-29

Advanced Junes Service Provider Routing

BGP Next-Hop Solutions (contd.)

Export direct uses a Junes 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 Junes 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 IGPto use.

An IGP passive interface allows the local IGPto advertise the subnet on a particular interface without
forming an adjacency at the IGP level to the remote EBGP peer. This 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 notareal 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 8-30 . BGP www.juniper.net

 Advanced Junos Service Provider Routing

Agetida

Review of BGP

BGP Operations
-

>BGP Path Selection and Options

Configuration Options

BGP Path Selection Options

The slide highlights the topic we discuss next.

www.juniper.net BGP . Chapter 8-31

Advanced Junos Service Provider Routing

Once BGP verifies next-hop reachability and that no

loops exist, it selects the active route as follows:
BGP Route Selection Summary
1. Preferthe path with the higher local- 6 . Prefer path whose next-hop is resolved
preference bylGP route with lowest IGP metric
2 Preferthe route with the shortest AS-
.
7 . For EBGP-received routes, preferthe
path length current active route: otherwise, prefer
routes from the peer with lowest RID
3. Preferthe route with the lowerorigin 8 Prefer routes with the shortest cluster
.

code list length

4. Preferthe path with the lowestMED 9 . Prefer routes from the peerwith the
metric lowest peer IP address
5 Prefer routes learned from an EBGP peer
.

overan IBGP peer

UniPe" VmlrlwideEclui
uDation Services

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/i/ghest 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]).

Continued on the next page.

Chapter 8-32 . BGP www.Juniper.net

 Advanced Junes Service Provider Routing

Summary of BGP Active Route Selection (contd.)

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 hops 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 hops of the instance with the lowest Junos OS
preference is used. Often, this 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 hops 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
hops 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 router ID (usually the
loopback IP address). When comparing external routes from two distinct neighboring
ASs, if the routes are equal up to the router ID 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 router ID, 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.

www.Juniper.net BGP . Chapter 8-33

Advanced Junos Service Provider Routing

BGP can ignore both router ID and peer ID comparisons

when multipath is configured within BGP
. Can use:
.
Two peering sessions to the same router
.
Two peering sessions to different routers in the same AS
R2
10.222.28.1/24 10.222.28.2/24
Rl (AS 2)
(ASl)
10.222.29.1/24 Ml R3

10.222.29.2/24 (AS 2)

[edit protocols bgp group ent-peers]

type external;
peer-as 2;
neighbor ID.222.28.2;
neighbor 10.222.2S.2;

user@Rl> show bgp suimnary

Peer AS InBkt OutPkt OutQ Flaps Last Up/Dwn State I#Active/Rec
10.222.28.2 2 7 7 0 0 00:00:02 4/4/0
10.222.29.2 2 8 10 0 0 00:00:06 0/4/0

Si vVnrlilwule E tiui Hliun Ssnices

Router ID and Peer ID Ignored

When you configure multipath on a BGP router, the selection algorithm ignores both the router ID
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.

Continued on the next page.

Chapter 8-34 . BGP www.juniper.net

 Advanced Junos Service Provider Routing

Router ID and Peer ID Ignored (contd.)

The slide shows the Rl router peering with two routers in AS 2~R2 and R3. Both of the AS 2 routers
are advertisingthe 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 8-35

Advanced Junes Service Provider Routing

Routes from each peer contain a single next hop

user@Rl> show route protocol bgp terse

inet.O: 15 destinations, 19 routes (15 active, 0 holddown, 0 hidden)

+ = Active Route, -
= Last Active, * = Both

A Destination P Prf Metric 1 Metric 2 Next hop AS path

* 100
172.16.20.4/30 E 170 >10.222 28 2 2 I

B 170 100 XL0.222 29 .

2 2 I

* 100
172.16.20.8/30 B 170 >10.222 28 2 2 I

B 170 100 >10.222 29 2 2 I

* 100 2
172.16.20.12/30 B 170 >10.222 28 . 2 I

B 170 100 >10.222 29 .

2 2 I

* 170 100
172.16. 20.16/ 30 B >10.222 28 .2 2 I

B 170 100 >10.222 29 2 2 I

PGi VvOrld'WiJe Etkication Services

Single Next Hop for All Routes

The local routing table of the Rl 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 8-36 . BGP www.juniper.net

 Advanced Junos Service Provider Routing

1:- iiraytipatli

Peer group on Rl configured with multipath

.
Active route receives two next hops
.
Forwarding table still maintains a single next hop per route

user(3Rl> show route protocol bgp terse

inet.O: 15 destinations, 19 routes (15 active, 0 holddown, 0 hidden)
f = Active Route, - = Last Active, * = Both

A Destination B Ptrf Metric 1 Metric 2 Next hop AS path

*
172.16.20.4/30 B 170 100 >10. 222 26 2 2 I
10.222 29 2
B 170 100 >10.222 29 2 2 I
*
172. 16. 20. B/30 B 170 100 >10.222 2B 2 2 I
ID. 222 29 2
B 170 100 >10.222 29 2 2 I
*
172.16.20.12/30 E 170 100 >10.222 28 2 2 I
ID.222 29 2
B 170 100 >10.222 29 2 2 I
*
172.16.20.16/30 B 170 100 10.222 28 2 2 r
>10.222 29 2
B 170 100 >10.222 29 2 2 i

Configure multipath on Rl
The configuration of the Rl router now contains the multipath command within the peer group for
AS 2. After committing the configuration, we examine the contents of the locai 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.

As 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 Ito 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 8-37

Advanced Junes Service Provider Routing

EBGP sessions can peer with nonphysical addresses

loO: 192,168.3,4 loO: 172,16,128,1

1 I
Rl jtff*. 10,10,1,2/24 10,10,1,1/24 Jgflh R2
(AS1) (AS 2)
10,10 2,2/24 10,10,2,1/24

[edit protocols bgp group ext-peers] ATTL value of 1 accommodates

type external;
peeringto a loopback address on a
local-address 4-
192.168.3.4; *
« Step 1
neighbor 172.16.128.1 {
| directly connected peer-higher
values are needed for peers that
multihop ttl 1; * Step 2
(are not directly connected
}
[edit routing-options]
static {
route 172.16.128.1 next-hop [ 10.10.1.1 10.10.2.1 ] .
Step 3
}

Aorldwide Education Smices

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, it is advantageous to alter this default, one-hop, physical peering
EBGP behavior. 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 peeringsession 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 neighbor's 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 router s 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 Junes 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 RE.

Chapter 8-38 . BGP www.junlper.net

 Advanced Junos Service Provider Routing

mmm 1

Both multihop and multipath create routes with

multiple next hops in the routing table
.
Use a routing policy to forward traffic on both next hops

user@router> show route 172,16.20.4/30 terse

inet.O: 15 destinations, 19 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination P Prf Metric 1 Metric 2 Next hop AS path

*
172.16.20.4/30 B 170 100 XLO.lQ.l.l 2 I
10.10.2.1

B 170 100 >10.10.2.1 2 1

user@router> show route forwarding-table matching 172,16.20.4/30

Routing table: inet
Internet:

Destination Type RtRef Next hop Type Index NhRef Netif

172.16.20.4/30 user 0 indr 106 4
10.10.1.1 ucst 47 4 fe-0/0/0.0

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 traffic-10.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
f orwarding-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 8-39

Advanced Junes Service Provider Routing

user@router> shear configuration policy-options policy-statement load-bctlance

then {
load-balance per-packet;
)
user@router> show configirration routing-options forwarding-table
export load-balance;

user9router> show route 172.16.20.4/30 terse

inet.O: 15 destinations, 19 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination P Prf Metric 1 Metric 2 Next hop AS path

*
172. 16.20. 4/30 B 170 100 >10. 10. 1.1 2 1
10. 10.2. 1

B 170 100 >10.10.2.1 2 I

user8router> show route forwarding-t.able matching 172.16.20.4/30

Routing table: inet
Internet:

Destination Type RtRef Next hop Type Index NhRef Net if

172.16.20.4/30 user 0 ulst 108 4

indr 106 2
10. 10. 1. 1 ucst 47 4 fe-0/0/0. 0
indr 107 2

10. 10. 2. 1 ucst 99 4 ge-0/1/0. 0

f Wo rldwide Education Services

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 if
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 f orwarding-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 8-40 . BGP www.juniper.net

 Advanced Junos Service Provider Routing

: W

Review of BGP

BGP Operations
BGP Path Selection and Options
Configuration Options

Configuration Options
The slide highlights the topic we discuss next.

www.junlper.net BGP . Chapter 8-41

Advanced Junos Service Provider Routing

'

¥m : " .j 7 j<r c -

ptions(1 of S)

passive keeps BGP from sending an open message

[edit protocols bgp]
group ext~peers {
type external;
peer-as 2;
neighbor 10.10.10.1 {
passive;

allow accepts open messages from any peer within

the configured IP address range
[edit protocols bgp]
group ent-peers {
type eKternal;
peer-as 65000;
allow 10.10/16;

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
'
router s 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 8-42 . BGP www.juniper.net

 Advanced Junes Service Provider Routing

urat fi ]

prefix-limit allows a specified amount of

prefixes to be received
[edit protocols bgp]
group ext-peers {
type external;
peer-as 2;
family inet {
unicast {
prefiK-iimit {
maximum 25000;
teardown 80 idle-timeout 10;
}
}
}
neighbor 10.10.10.1;
}

hold-time alters the value used in the session

negotiation process
[edit protocols bgp]
group ext~peers {
type external;
hold-time 45;
peer-as 2;
neighbor 10.10.10.1;
}

Limiting the Number of Prefixes Accepted

By defauit, 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 Junes 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 8-43

Advanced Junos Service Provider Routing

advertise-peer-as disables suppression of route

advertisements
.
Routes learned from an EBGP peer are advertised back to
the same EBGP peer
.
Routes learned from an EBGP peer are advertised to EBGP
peers In the same AS as the originating peer

[edit protocols bgp]

group ext-peers {
advertise-peer-as;
peer-as 2;
neighbor 10.10.10.1;

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 peerthat 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 8-44 . BGP www.Juniper.net

 Advanced Junos Service Provider Routing

firacsffai l#©tart

GR allows a router undergoing a restart event to inform

its neighbors and request a grace period during which it
can recover from that restart event
.
Forwarding through existing paths can continue during restart
Rlinformsall neighbors of a restart
event. Rl is known as the restarting
router in G R term Inology.
R1 R

m
R3and R6are notawarea
restart event occurred.

Pi's neighbors hide the failure

from other routers in the network.
R2. R4, and R5are known as
Once Rl recovers from the restart event, Ri synchronizes
helper routers in G R term inology.
with Its neighbors without disrupting packet forwarding,

Graceful Restart

Graceful restart (GR) addresses the situation described on the previous siide. GR allows a router
undergoing a restart event, including a restart of the routing protocol process (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 graceful restart request occurs only if the following conditions are met:
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.

www.juniper.net BGP . Chapter 8-45

Advanced Junos Service Provider Routing

Routers (restarting and helper routers) must have GR

enabled and be able to support nonstop forwarding
End-of-RIB markers sent for each NLRI
.
Notifies the neighbor that all current routing information
was sent

.
Local router defers path selection algorithm until the
marker is received

Configured globally within the [edit routing-

options] hierarchy
Duringa restart event, forwarding continues
Control Plane Routing Engine based on existing forwarding table entries,

ForwaidingPlane
-

Packets In PacketsOut
Packet Forwarding Engine

) rldvvlrie Eduoation Services

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 modes-the 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 8-46 . BGP www.juniper.net

 Advanced Junos Service Provider Routing

Conf m i1 A I
GR helper mode is enabled by default
.
You can disable GR helper mode globally at
the [edit routing-options] hierarchy or on a
per-protocol, per-group, or per-neighbor basis
(depending on the protocol)
[edit]
user@Rl# show routing-options
graceful-restart (
disable; « Disables helper mode globally for
) all protocols that support GR

[edit]
user@Rl# show protocols bgp
graceful-restart; « Enables helper mode for BGP
group my-group {
type internal;
local-address 192.168.1.1;
Note: The most specific application is preferred,
neighbor 192.168.1.2;
neighbor 192.168.2.2 (
graceful-restart {
disable; < Disables GR for BGP peer
}
)
)

Worltteide Ectucaliim Services

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 8-47

Advanced Junes Service Provider Routing

GR restarting router mode is not enabled by default

.
You can enable this mode at the [edit routing-
options] hierarchy and disable it on a per-protocol, per-
group, or per-neighbor basis (depending on the protocol)
.
Configuration options vary between
the supported protocols [edit]
user(aRl# show routing-options
graceful-restart;

[edit]
Liser@Rl# show protocols bgp
Enables restarting router mode for all g race ful-re sta rt;
protocols that support GR group my-group {
type internal;
local-address 192.168.1.1;
neighbor 192. 168. 1.2;
neighbor 192. 168. 2.2 (
graceful-restart {
>- disable;
Disables GR for BGP peer
}

Configuring GR: Part 2

GR's 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 GR s 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@Rl# 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
res tart-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 8-48 . BGP www.juniper.net

 Advanced Junos Service Provider Routing

AS 65002
AS 65003
192.168.19.0/24

Rl

100=192.168.40.1
Local preference

user@R2> show route advertising-protocol bgp 192.168.40.1

inet.D: 14 destinations, 15 routes (14 active, 0 holddown, 0 hidden)
Restart Complete
Prefix Nexthop MED iLclpref AS path
*
192.168.19.0/24 Self 0 100 65003 1

[edit]
user@R2# set protocols bgp group int-peers local-preference 300

userSR2> show route advertlsing-protoool bgp 192,168.40.1

inet.O: 14 destinations, IS routes (14 active, 0 holddown, 0 hidden)
Restart Complete
Prefix Nexthop MED Lclpref AS path
192.168.19.0/24 Self 0 300 65003 I

I'orldwicIeEducattonServices wwjjumper.nst [ s-4

Modifying the Local Preference

The Junos OS provides a configuration option within BGP that alters the local preference attribute
value for ail 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 8-49

Advanced Junes Service Provider Routing

; remove-private

192.168.17.0/24: 1000
192.16818.0/24: 1000
192.168.19.0/24: 1000
Internet

® remove-private

AS 1000

192.168,17.0/24: 65001 192.168,19,0/24: 65003

192 168,18.0/24: 65002
/
AS 65001 AS 65002 AS 65003
192.168.17,0/24 192,168,18.0/24 192,168,19.0/24

IPef Work

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, it is
not a question of one AS trampling on the path information another AS has put into the AS path
attribute.

One example of this type of configuration option is the remo-ve-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.

In 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.

Continued on the next page.

Chapter 8-50 . BGP www.juniper.net

 Advanced Junes Service Provider Routing

Eliminating Private AS Numbers (contd.)

The remove-private option is enabied on the edge router in AS 1000 that faces the Internet or
other EBGP peers. 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 8-51

Advanced Junos Service Provider Routing

. - Path: 1 , ,

Internet
172.16.10.0/24: 1222

172.16.12.0/24: 1333

AS1

172.16.10.0/24: 222
172.16.12.0/24: 333

AS 222 6333

172.16.10 0.224 2 . 16.12.0/24

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, there is nothing unusual about the AS path operation.

Chapter 8-52 . BGP www.juniper.net

 Advanced Junos Service Provider Routing

AS 777

172.16.10.0/24: 1222

172.16.12.0/24; 1333
172.16.10.0/24: 777 1 222

172.16.12 0/24; 777 1333

local-as 1

Mr

Internet
172.16.10.0/24; 222
172.16.12.0/24; 333

AS 222 AS 333

172.16.10.0/24 172.16.12.0/24

Modifying the AS Path Attribute: Part 2

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 8-53

Advanced Junes Service Provider Routing

.
-

as (3 of 3)

AS 777

172.16.10-0/24
172.16.12.0/24: 333
172.16.10.0/24; 777 222

172.16.12.0/24: 777 333

local-as 1 private

r
Internet
172.16.10.0/24; 222 :

172.16.12.0/24: 333

AS 22 A3 333

172.16.10.0/24 172.16.12.0/24

JfMS:

Modifying the AS Path Attribute: Part 3

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:

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.

Chapter 8-54 . BGP www.Juniper.net

 Advanced Junos Service Provider Routing

as-override

172.16.10,0/24: 65022 172.16.10.0/24: 65432 65432

10,222,4,2
AS 65022
10,222,4,1
172.16,10.0/24
AS 65432 AS 65022
/ ,.
.
-

as-override

user@AS65432> show route advertising-protocol bgp 10.222.4,2

inet.Q: 8 destinationsf 8 routes (8 active, 0 holdclown, 0 hidden)
Prefix NeKthop MED Lclpref AS path
*
172. 16. 10. D/24 Self 65022 I

usergAS65D22> show route reoeive-protoool bgp 10.222.4.1

inet.O: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)

[edit]
user@AS65432# set protocols bgp group AS-65022 as-override

user@AS65432> show route advertising-protocol bgp 10.222,4.2

inet.O: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
Prefix Mexthop MED Lclpref AS path
*
172.16.10.0/24 Self 65022 I

user@AS65 022> show route receive-protoool bgp 10.222,4.1

inet.O: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
*
172.16.10.0/24 10.222.4.1 65432 65432 I

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 in the slide.

AS 65432 is providing transit service to AS65022, which peers at two different locations. For
reasons that we do not discuss here, 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-hand 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 peer's 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 8-55

Advanced Junos Service Provider Routing

: S Path: loops

172.1610.0/24: 65022 172.16.10.0/24: 65432 65022

AS 65022
AS 65432
172.16.10.0/24
AS 65022

usergAS6S022> show route reoeive-protoool bgp 10.222.4.1

inet.O: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)

[edit]
user(?AS65 022# s&t routing-options autonomous-system 65022 loops 2

user@AS65022> show route reoeive-protoool bgp 10.222.4.1

inet.O: 8 destinations, 8 routes (B active, Q holddown, 0 hidden)

Prefix NeHthop MED Lclpref AS path
172. 16. 10. 0/2(1 10.222.4.1 65 432 65 022 I

Allowing AS Paths Loops

The Junos OS ailows 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 8-56 . BGP www.juniper.net

 Advanced Junes Service Provider Routing

mmmmfsf

In this chapter, we:

.
Described basic BGP operation
. Listed common BGP attributes

.
Explained the route selection process for BGP
.
Described how to alter the route selection process
.
Configured some advanced options for BGP peers

This Chapter Discussed:

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.

www.juniper.net BGP . Chapter 8-57

Advanced Junos Service Provider Routing

Review Questions

1 .
What are the advantages of loopback peering for
IBGP sessions?

2 . What are the default BGP route advertising rules?

3 . Within the Junos OS, all new BGP routes get which
origin code?
4 . How does multipath affect route selection?
5 . What are valid ways for BGP to resolve a next hop?

Review Questions
i.

2 .

3.

4 .

5 .

Chapter 8-58 . BGP www.juniper.net

 Advanced Junos Service Provider Routing

Configure and monitor IBGP and EBGP.

Worldwide Education Services

Lab 7: BGP

The slide provides the objective for this lab.

www.juniper.net BGP . Chapter 8-59

Advanced Junos Service Provider Routing

Chapter 8-60 . BGP www.Juniper.net

jumper NETWORKS

Advanced Junos Service Provider

Chapter 9: BGP Attributes and Policy-Part 1

Advanced Junos Service Provider Routing

After successfully completing this chapter, you will be

able to:
.
Describe various BGP attributes in detail and explain the
operation of those attributes
« Manipulate BGP attributes using routing policy

lion Service

This Chapter Discusses:

Various BGP attributes in detail and explains the operation of those attributes; and
.
The manipulation of BGP attributes using routing policy.

Chapter 9-2 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junes Service Provider Routing

>BGP Policy
Next Hop
Origin and MED
AS Path

BGP Policy
The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.juniper.net BGP Attributes and Policy--Part 1 . Chapter 9-3

Advanced Junos Service Provider Routing

BGP behavior can be influenced by policy

.
BGP attributes can be matched or changed
. Can differentiate between IBGP or EBGP routes

BGP stores routes in three main RIB memory tables

. RIB-IN: Stores all received routes
.
RIB-LOCAL: Stores routes the local router uses to forward
traffic
. RIB-OUT: Stores all advertised routes

Only active BGP routes in the local routing table can

be advertised to peers
.
Single best BGP path is advertised

urlilv/iili! trJiiL-iitiuii Smices

BGP and Policy Dependency

BGP is a very poiicy-oriented protocoi, in the sense that import and export poiicies iargeiy determine
BGP behavior. The router can use ali the BGP attributes. You can adjust these attributes to influence
the behavior of the locai router as weil 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 poiicy 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.

Continued on the next page.

Chapter 9-4 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junes Service Provider Routing
BGP and Active Routes

Oniy 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 router's
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 BGP Attributes and Policy-Parti . Chapter 9-5

Advanced Junos Service Provider Routing

art

Import policies are enforced between the RIB-IN and

RIB-LOCAL tables

Peers

Flltermgand
Choice of
attribute
best route
manipulation

Routes from Import f Routes

RIB-IN Decisions
BGP peers policy \ used

IP routing
table

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.

Chapter 9-6 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junes Service Provider Routing

'

, : Policy ,

Import policies:
1) Reject 0.0.0.0/0 from AS 1
000
. 0/0
. .
2) Prefer 192.168.14.0/24 from AS 1
192.168.14.0/24 3) Accept all routes from AS 3
AS i

Filteringand
attribute
manipulation Choice of best route

Routes from Import Routes'

RIB-IN Decisions
BGP peers policy used .

000 0/0 :AS1

. . .

Forwarding
000
. 0/0 :AS3
. .
table
192.16814.0/24 :AS1 000
. 0/0 :AS3
. .

AS 3
192.168.14.0/24 ASS 172.31.10.0/24 :Local
000
. 0/0. .

192.168.27.0/24 :AS3 192.168.14.0/24 :AS1

192.168.14.0/24
192.168.27.0/24 192.168.27.0/24 :AS3

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 user's 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:
The 0.0.0.0/0:ASl 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 ASS routes are accepted.

www.Juniper.net BGP Attributes and Policy-Part 1 . Chapter 9-7

Advanced Junes Service Provider Routing

X 3 ml

Export policies are enforced between the RIB-LOCAL

and RIB-OUT tables

Peers

Filterinaand
Choice of
attribute
best route
manipulation
'

Routes Export
RIB-OUT Routes sent to
used policy BGP peers

IP routing
table
Peers

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 Junes 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 Junes OS can inject new routing Information Into the BGP routing process at this
point.

Chapter 9-8 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Export policies:
172.31.10.0/20
1) Do not send 0.0.0.0/0
192.16814.0/24
2) Send 192.168.14.0/24 to AS 2 with a metric of 10
3) Do not send 192.168.27.0/24 to AS 4
AS 4
4) Send aggregate for local routes
Fliteringand Choiceof
attribute best route
manipulation

Routes I Export
RIB-OUT Routes sent to
used
1 policy BGP peers

IP routing
table

0 0 0 0/0
. . . ASS
172.31.10.0/20
172.31.10.0/20 :Local Aggregate
192.168.14.0/24
192.168.14.0/24 :AS1
(metric = 10)
192.168.27.0/24 ASS
192.168.27.0/24
'orldwitle EtJucation Services

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:

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.

www.juniper.net BGP Attributes and Policy-Part 1 . Chapter 9-9

Advanced Junos Service Provider Routing

Elites and Policy-l art i

BGP Policy
-

>Next Hop
Origin and MED
AS Path

ducalion Services i
TWjunrpcr net \ 9-10
.

Next Hop
The slide highlights the topic we discuss next.

Chapter 9-10 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

He "jP Uses Next Hop

Next-hop concept in IGPs is straightforward-BGP

next-hop is more elaborate
Default forms of BGP next-hop information:
.
EBGPsessions: Next hop is the IP address of the neighbor
that announced the route
. IBGP sessions-three scenarios:
.
For routes originating inside the AS with a forwarding next hop. the
next hop is set to that forwarding address (third-party next hop)
.
For routes originating inside the AS with reject or discard next
hop. the next hop is the session address associated with the BG P
speaker
.
For routes injected into the AS using EBGP. the EBG P next hop is
advertised unchanged into IBGP

The Next-Hop BGP Attribute

The nexthop 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.

Continued on the next page.

www.juniper.net BGP Attributes and Policy-Part 1 . Chapter 9-11

Advanced Junos Service Provider Routing

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 router's peer ID. For IBGP sessions, the peer ID is typically the
local router's loopback address. For EBGP sessions, the peer ID is usually a peering address
associated with a physical link.

Chapter 9-12 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junes Service Provider Routing

172.19.20.0/24
R2
192.168.10,2/32

R4 AS 2

Rl
192.168.10.3/32 30.3/24 lO-nv/v.1
10.10,1/24
10.40.4/24
R3
192.168.10.1/32

user@R3> show bgp summary

Peer AS InBkt OutPkt OutQ Flaps Last Up/Dwn State | #Active/Rec.
192.168.10.2 1 10 12 0 0 4: 13 0/0/0
192.168.10.3 1 2 4 0 0 14 0/0/0
10.10.1.2 2 18 20 0 0 8:23 1/1/0

u3er@R3> show route terse

inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
A Destination P Prf Metric 1 Metric 2 Next hop AS path
*
172.19.20.0/24 B 170 100 >10.10.1.2 2 I
*
192.168.10.2/32 1 18 10 >10.20.2.2
* 192.168.10.3/32 I 18 10 >10.40.4.2

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 BGP Attributes and Policy-Part 1 . Chapter 9-13

Advanced Junes Service Provider Routing

R2 172.19,20,0/24

.
168.10.2

Rl
192,168,10,3/32 10,20,2/24
10,30,3/24

10,10,1/24
10,40,4/24
R3
192,168,10.1/32

user@Rl> show bgp sununary

Peer AS InPkt OutBkt OutQ Flaps Last Up/Own State | #Active/Rec...
192.168.10.1 1 20 21 0 0 9:04 0/ 1/0
192.168.10.2 1 IB 20 0 0 9:00 0/0/0

user@Rl> show route terse

inet.Q: 24 destinations, 24 routes (23 active, 0 holddown, 1 hidden)
Destination Prf Metric 1 Metric 2 Next hop AS path
10.20.2.0/24 18 20 10.30.3.2
>! .40.4.1
192.16B.10.1/32 >10.40.4.1
192.168.10.2/32 >10.30.3.2

Next-Hop BGP Example: Part 2

The siide shows the output from the Rl router. The Rl router has an IBGP session with the R3 router
'

using R3 s loopback address of 192.168.10.1.

The output of the show bgp summary command shows that the Rl 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 Rl router from the R3
router, then the route should appear as the active route (there is no chance of an AS 1IGP also
supplying this AS 2 route). What is the problem?

Chapter 9-14 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Hop
R2 172,19.20.0/24

AS 1 192.168.10.2/32 \
R4
AS 2

Rl
192.168.10.3/32 10.20.2/24
10.30.3/24

1 10,10.1/24
10 40,4/24
R3
i
192,168,10,1/32
user@Rl> show route hidden extensive
inet.O: 24 destinations, 24 routes (23 active, 0 holddown, 1 hidden)
172.19.20.0/24 (1 entry, 0 announced)
BGP Preference: 170/-1D1
Next hop type: Unusable
State: <Hidden Int Ext>
Local AS: 1 Peer AS: 1

Age: 13:53 Metric2: 0

Task: BGP 1 192.168.10.1+179
.
_

AS path: 2 I
BGP next hop: 10. ID. 1.2
Localpref: 100
Router ID: 192.168.10.1

Next-Hop BGP Example: Part 3

You can see the problem with the absent route to 172.19.20.0/24 on the Rl router with the help of
the show route hidden extensive command run on the Rl 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 Rlto 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 Rl router, which is the default EBGP-to-IBGP behavior-notto
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 Rl 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 Attributes and Policy-Part 1 . Chapter 9-15

Advanced Junos Service Provider Routing

BGP next-hop solutions:

.
Next-hop self
.
Exportdirect routes into the IGP
.
IGP passive interface
«Static routes
.
IGP adjacency formed on inter-AS links to EBGP peers

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 attribute s 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
'

peer s 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 d/'rect 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.

Continued on the next page.

Chapter 9-16 . BGP Attributes and Policy-Part 1 www.Juniper.net

 Advanced Junos Service Provider Routing

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 BGP Attributes and Policy-Part 1 . Chapter 9-17

Advanced Junos Service Provider Routing

mmm H
R2 172.19.20.0/24
192.168.10.2/32
AS 1
R4

AS 2
Rl
10.20.2/24
192.168.10.3/32 10.30.3/24

10.10.1/24
10.40,4/24

1 R3
usergR3# show policy-options
policy-statement neirt-hop-self { 192.168.10.1/32
then i

next-hop self;
I

[edit]
user@R3# show protocols bgp
group int {
type internal;
local-address 192.168.10.1;
export neKt-hop-self;
neighbor 192.16B.10.2;
neighbor 192.168.10.3;

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 Rl 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 router s 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 Rl router.

Chapter 9-18 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junes Service Provider Routing

R2 20.0/24

192.168,10.2/32

Rl
192,168.10.3/32 10,20,2/24
30,3/24

1 /10,10,1/24
10,40,4/24
R3
192,168.10.1/32

user0Rl> show bgp summary

Peer A3 InPkt OutPkt OutQ Flaps Last Up/Dwn State I #Active/Rec
192.168. 10. 1 1 67 67 0 0 32:25 1/1/0
192.168 10.2 1 65 67 0 D 32:21 0/0/0

user@Rl> show route terse

inet.O: 24 destinations, 24 routes (23 active, 0 holddown, 1 hidden)
Destination Prf Metric 1 Metric 2 Next hop AS path
10.20.2.0/24 13 20 10.30.3.2
>10. 40. 4.1
172.19.20.0/24 B 170 100 >10. 40. 4.1 2 1
192.168.10.1/32 18 10 >10. 40. 4.1
192.168.10.2/32 IB 10 >10.30.3.2

Tirlilwittu tilucdliun Services

II
Example Using Next-Hop Self: Part 2
This slide shifts the focus of attention to the Rl router.

The output of the show bgp summary command now shows that the Rl 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 Rl router by the R3 router because the route was advertised on the 10.40.4.1 interface.

www.juniper.net BGP Attributes and Policy-Part 1 . Chapter 9-19

Advanced Junos Service Provider Routing

Hop to Self (3 of 3)
R2 /172.19.20.0/24
192.168.10.2/32
AS 1

Rl
192.168.10.3/32 10.20.2/24
10.30,3/24

10.10,1/24
10,40.4/24
R3
user@Rl> show route extensive 192.168.10,1/32
inet.O: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden)
172.19.2D.0/24 (1 entry, 1 announced)
*
BGP Preference: 170/-101
Source: 192.168.10.1
Nexthop: 10.40.4.1 via so-0/0/2.0, selected
State: <Active Int EKt>
Local AS: 1 Peer AS: 1
Age: 4:16 Metric2: 10
Task: BGBJL. 192. 163. 10. 1+179
Announcement bits (2): 0-KRT 4-BGS Sync Any
_ _

AS path: 2 I
BGP next hop: 192.168.10.1
Localpref: 10 0
Router ID: 192.168.10.1

.
'
f orltlwiUc I ducotion Sumces jijiiiper.nei, i ,3-20

Example Using Next-Hop Self: Part 3

How do you know that the BGP next-hop attribute was realiy 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 Rl 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 Rl router has IGP reachability to the R3 router,
the Rl router also has reachability to the BGP next-hop value and can use the BGP route.

Chapter 9-20 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Chang axt Hop to Pec

By default, EBGP-received routes have a next hop of

the neighbor's address
Peer can alter the next-hop attribute using policy prior
to announcing routes
Can configure local router with an import policy to
force the next hop to be the neighbor's address

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 BGP Attributes and Policy-Part 1 . Chapter 9-21

Advanced Junes Service Provider Routing

AS 1 AS 2
Rl Ml 10.10.1/24
-1 R2
192.168.10.1/32
And 172.16.20.1/32

Rl and R2 routers are EBGP peers using multihop

.
R2 router alters the next-hop attribute causing hidden
routes on the Rl router

user@Rl> show route receive-protocol bgp 172.16.20.1 hidden

inet.O: 9 destinations, 9 routes (6 active, 0 holddown, 3 hidden)

+ = Active Route, - = Last Active, * = Both

10.100.100.0/24
172.16.30 .1 2
.
I
10.101.101.0/24
172.16.30.1 2 I
10.102.102.0/24
172.16.30.1 2 I

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 Rl router. The Rl router has a multihop EBGP connection to the
R2 router using 172.16.20.1.
The R2 router advertises routes to the Rl router with a BGP next hop of 172.16.30.1. Because the
Rl 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.

Chapter 9-22 . BGP Attributes and Policy-Part 1 www.Juniper.net

 Advanced Junes Service Provider Routing

'

?mm'Mtbmm fm:xMm fl-eB p/1£ off V

AS1 AS 2
Rl 10.10.1/24 R2
192.168.10.1/32 172.16.20.1/32

[edit]
ussr0Rl# show policy-options
policy-statement neKt-hop-to-peer~address
tem all-bgp-routes {
then (
neKt-hop peer-address;
i
i

[edit]
ussr(?Rl# show protocols
bgp (
group ent {
type external;
multihop {
ttl 2;
>
local-address 192.16B.10.1;
import next-hop-to-peer-address;
peer-as 2;
neighbor 172.16.2D.1;

Worltivvidn Eiclucation Survicus

Example Using Next-Hop Peer Address: Part 2

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

www.juniper.net BGP Attributes and Policy-Part 1 . Chapter 9-23

Advanced Junes Service Provider Routing

Peer : i>Iicy (3 of 3)
user@Rl> show route protoctol bgp extensive

inet.O: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)

10.100.100.0/24 (1 entry, 1 announced)
TSI:

KRT in-kernel 10.100.100.0/24 -> (indirect (21) )

Page 0 idx 0 Type 1 val 83de310
Nexthop: Self
AS path: 2 I
Communities;
Path 10.1D0.100.0 from 172.16.20.1 Vector len 4. Val: 0
*
BGP Preference: 170/-101
Source: 172.16.20.1

Nexthop: 10.10.1.2 via ge-0/2/0.0, selected

Protocol Nexthop: 172.16.20.1 Indirect nexthop: SSeOOOO 21
State: <Active Ext>
Local AS: 1 Peer AS: 2

Age: 6:5 6 Metric2: 0

Task; BGP 2 172. 16. 20. 1+2122
.
_

Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 2-Resolve inet.O

AS path: 2 I
Localpref: 100
Router ID: 172.16.20.1

Indi rectnexthopsj 1

[ §° ?.c°j!:...1? £*:ll'.op: 172 16 ' '20 ! illndirocL. nexthop: 83*0000 21

Indirect path forwarding nexthops: 1
Nexthop: 10.10.1.2 via ge-0/2/0.0

Wotlriwiilt EtiucatiDii Sc - .

. Junipff.nei f 3-24

Example Using Next-Hop Peer Address: Part 3

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
peeringaddressof 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 router's loopback address.

Chapter 9-24 . BGP Attributes and Policy-Part 1 www.Juniper.net

 Advanced Junes Service Provider Routing

BGP Policy
Next Hop
-

>Origin and MED

AS Path

Origin and MED

The slide highlights the topic we discuss next.

www.Juniper.net BGP Attributes and Policy-Part 1 . Chapter 9-25

Advanced Junos Service Provider Routing

Installed by the originating router for the prefix (route)

A tag of believability as to the origin of the route
information (Where did you get it from?)
BGP origin code is a well-known, mandatory attribute
Origin can be internal, external, or unknown
.
I: Internal (0)-Learned from an IGP
.
E: External (1)-Learned from EGP
.
?: Incomplete (2)-NLRI found by some other means
I (0) is better than E (1), which is better than ? (2)
All Junos OS BGP routes have origin IGP by default

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.

Weil-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.

Continued on the next page.

Chapter 9-26 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junes Service Provider Routing
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 Internal-IGP

Because all routing information eligible to be injected into BGP on a Juniper Networks router resides
in inet.O, 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 BGP Attributes and Policy-Part 1 . Chapter 9-27

Advanced Junos Service Provider Routing

Export Direct:
192.168.14.0/24

Export Statics:
10,0.0.0/8
172.16.0.0/16
192.168.27.0/24 Export IGP: To other AS:

10.20.0.0/16
10.0.0.0/8; Origin IGP
10.20.0.0/16 [Origin IGP
172.16.0.0/16 : Origin IGP
172.31.0.0/24: Origin ?
From other AS 192.168.14.0/24: Origin IGP
192.168.27.0/24: Origin IGP
172.31.0.0/24: Origin ?
WorldwUle bilucHliuiiSorvinfib

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.

Chapter 9-28 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junes Service Provider Routing

©f

Using the defaults, how does AS 40 reach AS 1?

Using the defaults, how do the other remote networks
reach AS 1?
AS 40
5) V ,
AS 10

AS 3
AS 30
)

AS1
AS 20 AS 2

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, due to a shorter AS-path length
through AS 20. Also, routers in AS 20 use AS 2 to reach the networks in AS 1, due to a shorter
AS-path length. Finally, routers in AS 10 use AS 3 to reach the networks in AS 1, due to 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 BGP Attributes and Policy-Part 1 . Chapter 9-29

Advanced Junos Service Provider Routing

Clrlgil iMlliiiilltgi |2 mf 1|
AS 1 sends origin ? to AS 2
. How does AS 40 reach AS 1 now?

How do the other remote networks reach AS 1 after

this attribute change?
AS 40
AS 10

AS 30 AS 3

5
:

AC 1
ASl
AS 20 AS 2

Example of Origin Attribute Use Part 2

On the previous siide, 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.

Continued on the next page.

Chapter 9-30 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junes Service Provider Routing

Other AS Networks

Note that routers in AS 30 stiil use AS 20 to reach the networks in AS 1, due to a shorter AS-path
length. Routers in AS 20 still use AS 2 to reach the networks in AS 1, due to a shorter AS-path length.
Routers in AS 10 still use AS 3 to reach the networks in AS 1, due to a shorter AS-path length.

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 BGP Attributes and Policy-Part 1 . Chapter 9-31

Advanced Junos Service Provider Routing

In Cc

Find IGP origin codes and change these origin codes

to incomplete
[edit policy-options]
policy-statement change-all-igps {
term igp-to-incomplete {
from {
protocol bgp;
origin igp;
}
then origin incomplete;
}
1

[edit protocols]
bgp {
export change-all-igps;
}

Modifying Origin with a Policy

The siide 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).

Chapter 9-32 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Multiple Exit Discriminator

An optional, nontransitive attribute, MED is never

passed through one AS to another AS
A neighboring AS can use MED to prefer one of
several paths to the local AS
Informs neighboring AS which ingress path to use to
reach the local AS in an attempt to influence inbound
traffic

Can perform some primitive load balancing

MED values are often translated from IGP metric

Other AS networks can always preempt MED with

other BGP attributes
A iuldwiile tiliiualiun Servir.es

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
/nboundto 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.

Continued on the next page.

www.juniper.net BGP Attributes and Policy-Part 1 . Chapter 9-33

Advanced Junes Service Provider Routing

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.

Chapter 9-34 . BGP Attributes and Policy-Part 1 www.Juniper.net

 Advanced Junes Service Provider Routing

1 .

AS1

(10.10.0.0/16 nearby) (10.20.0.0/16 nearby)

Rl R2

10.10.0.0/16 MED=10 10.10.0.0/16 MED=20

10.20.0.0/16 MED=20 10.20.0.0/16 IV1ED=10

R3 Acme

\
Traffic for 10.10.0.0/16

Traffic for 10.20.0.0/16

/
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 t/'me/y
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.

Continued on the next page.

www.juniper.net BGP Attributes and Policy-Part 1 . Chapter 9-35

Advanced Junes Service Provider Routing

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.

Chapter 9-36 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junes Service Provider Routing

lore Co:' Use e

Both AS 2 and AS 3 want to influence AS 1 traffic

'
ASl AS 2 "
v

@ ,,)MED'50 @
R2
R4
30.30.30.1
20.20.20.1
.

MED=200
192.168.13.0/24 advertised
MED=120
from all three routers

R3

LO.10.10.1
10.10.10.2

Choice of Rl. R3. or R4 to reach 192.168.13.0 is up to AS 1.

Chances are that Rl will be picked. Why?
Touse R4. AS 1 should use always-compare-med path selection.
Mjrldwids EducationServices

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 Rl, 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 Rl 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 Rl. Between those two advertisements,
the route from Rl is the best, because of its lower MED value.

Continued on the next page.

www.Junlper.net BGP Attributes and Policy-Part 1 . Chapter 9-37

Advanced Junos Service Provider Routing

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 Rl and the R4 routes. The Rl 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.

Chapter 9-38 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Selection and I: :

By default, the Junos OS uses a deterministic MED

comparison scheme for routes from the same AS
always-compare-med compares MED values,
regardless of whether the neighboring AS is the same
.
Use with caution-every network has a different
interpretation of a good MED
cisco-non-deterministic compares paths
based on when they are received
.
Not recommended for use in your network
. Can cause Incorrect route selections
[edit]
user@router# set protocols bgp path-selection ?
Possible completions:
always-compare-med Always compare MED values, regardless of neighbor AS
cisco-non-deterministic Use Cisco IOS nondeterministic path selection algorithm

Always Compare MEDs

By default, only the MED values from the same neighboring AS are compared to select a BGP path.
However, the always-oompare-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 BGP Attributes and Policy-Part 1 . Chapter 9-39

Advanced Junos Service Provider Routing

The action of metric corresponds to the MED value

Can set value to a number or can add to or subtract
from it
[edit policy-options]
policy-statement change-the-MED {
term set-the-med {
from route-filter 172.31.25.0/2 4 exact;
then metric 5 0;

term add-to-med {
from route-filter 192.168.32.0/20 orlonger;
then metric add 50;
}
term subtract-from-med {
from route-filter 10.124.0.0/16 upto /24;
then metric subtract 50;
}

s 1 I -

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.

Chapter 9-40 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junes Service Provider Routing

i mm4

Use the metric-out command with a group or

neighbor
* Can be set to:
.
A specific value
. The current IGP metric
. The minimum IGP metric ever learned
. Can add to or subtract from the IGP metric
.
Can also modify using policy
[edit protocols bgp]
group as-100-peers {
type external;
peer-as 100;
neighbor 192.168.2.2 metric-out 10;
neighbor 192.168.3.3 metric-out igp;
neighbor 192.168.4.4 metric-out minimum-igp;
neighbor 192.168.5.5 metric-out igp 5;

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:

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.

www.juniper.net BGP Attributes and Policy-Part 1 . Chapter 9-41

Advanced Junes Service Provider Routing

Ics wi

BGP can set the MED value on route announcements

based on the IGP metric to the peer from which the
route was received
Use the metric command with a policy
. Can set it to the current IGP metric
. Can set it to the minimum IGP metric ever learned
. Can add it to or subtract it from the IGP or minimum IGP
metric
[edit policy-options policy-statement alter-metries]
term possible-igp-setting {
then {
metric igp offset;
}
}
term possible-minimum-igp-setting {
then {
metric minimum-igp offset;
}
}

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 value-the 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.

Chapter 9-42 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junes Service Provider Routing

s a iv ates

When route aggregation occurs, the MED values

associated with the more granular routes are no
longer available

172.17.63/24 MED=100

172.17.3/24 MED=150 172.17/16 MED=0

172.17.4/24 MED= 160

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 BGP Attributes and Policy-Part 1 . Chapter 9-43

Advanced Junos Service Provider Routing

m m nm ates

192.168.16.0/20 MED=0
192.168.17.0/24 MED=10
192.168.17.0/24 MED=5

userSrouteo show route protocol bgp

inet.O: 31 destinations, 31 routes (31 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

192.168.17.0/24 *[BGP/1701 00:20:36, MED 10, localpref 100, from 192.168.48.1

AS path: (65001) 1 I
> to 10.40.40.1 via so-0/0/0.0

user@router> show route advertising-protocol bgp 10.222.11.1

inet.O: 31 destinations, 31 routes (31 active, 0 holddown, 0 hidden)

Prefix Mexthop MED Lclpref AS path
192.168.16.0/20 Self 100 65001 1 I
192.168.17.0/24 192.168.0.1 10 100 65001 1 I

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!

Chapter 9-44 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junes Service Provider Routing

Agendas Ibutes and Policf-Part 1

BGP Policy
Next Hop
Origin and MED
-
>AS Path

rVpi?'" '.Vorltteiilul ductition

AS Path

The slide highlights the topic we discuss next.

www.juniper.net BGP Attributes and Policy-Part 1 . Chapter 9-45

Advanced Junes Service Provider Routing

m Pmm Smiles

BGP AS Path is a well-known , mandatory attribute

'

81 Used to indicate path back to the route s source and to prevent

routing loops
.
Each EBGP router prepends its AS numberto the AS Path
.
Routes with the receiving router's AS number in the AS path are
considered looped and not advertised

Route X Route X Route X

AS 501 AS 645 AS 452 AS 521

# -©
Route X

Each router on the edge of the AS adds; AS Path =452645 501

AS Path = 645 501 .
its AS number to the front of Hie path

nrldwiiti1 F iltu iitiiin Serviiies

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 Junes OS performs a verification to ensure that
the receiving router's AS number is not listed In the AS path. If the receiving router's 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 numberto 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.

Chapter 9-46 . BGP Attributes and Policy-Part 1 www.junlper.net

 Advanced Junes Service Provider Routing

Autonomous System Nutnliers

RFC 1930 defined ASNs as 16-bit integers

.
65536 ASNs available (some reserved by IANA)
.
Private range is 64512-65534
RFC 4893 defines 32-bit ASNs
.
Written as two 16-bit numbers: x.y
.
Old ASNs written as O.y
.
l.y and 65535.65535 are reserved

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, 56320-64511, 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
where x and y are 16-bit numbers. Numbers of the form O.y are exactly the old 16-bit AS
x.y,

numbers, l.y numbers and 65535.65535 are reserved, and the remainder of the space is available
for allocation.

www.juniper.net BGP Attributes and Policy-Part 1 . Chapter 9-47

Advanced Junos Service Provider Routing

i mm Path P d

Manipulating the AS-path attribute is a major way to

favor or disfavor BGP routes

AS 1 prepends its AS number four times to AS 2

. How does AS 40 reach AS 1?

. How about the other remote networks?

AS 40
AS 10

AS 30 AS 3

AS1
AS 20 AS 2

miaat

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 it should not really be possible
to make the route more attractive by shortening the AS path. 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.

Continued on the next page.

Chapter 9-48 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

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 11111 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 10 will use AS 3 to forward packets to AS 1;

AS 20 will use AS 10 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 BGP Attributes and Policy-Part 1 . Chapter 9-49

Advanced Junos Service Provider Routing

Path rrepeni 1

[edit routing-options]
autonomous-system 1;

[edit protocols]
bgp {
group peer-AS2 {
type external;
export longer-as-path;
peer-as 2;
neighbor 10.10.10.2;
}
}

[edit policy-options]
policy-statement longer-as-path {
then as-path-prepend "111 1";
}

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, ail candidate routes match the policy. The action taken on all of the matched routes is to add
AS 1 to each route four times. This 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.

Chapter 9 50 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Path leal aiaiflflpiii

AS 2000

192.168.18.0/24: 1000 5000 192.168,18.0/24: 1000 5000 5000 5000

AS 1000 AS 3000

s
:
-
P
192.168.18.0/24: 5000 192.168.18.0/24: 5000 5000 5000

AS 5000
192.168.18.0/24

SIS

Expanding a Customer AS into the Path

in certain situations, a customer might want to prepend its AS number in the AS Path attribute which
,

ailows the customer to influence traffic flows into its AS from neighboring peers.
On the slide, the customer in AS 5000 has connections to AS 1000 and AS 3000. AS 5000 would
prefer to receive traffic from AS 2000 through the connection to AS 1000. This example uses
AS-path prependingto achieve this goal.

You can use either the as-path-prepend as-nimberorthe 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 prepend action is in addition to the normal prepend of AS 5000 into the path. The
slide shows how the 192.168.18.0/24 prefix Is advertised with the default AS path to AS 1000 while
two additional AS numbers are prepended in its advertisement to AS 3000.

www.juniper.net BGP Attributes and Policy-Part 1 . Chapter 9-51

Advanced Junes Service Provider Routing

[edit routing-options]
autonomous-system 5000;

[edit protocols]
bgp {
group out-to-Internet-peer {
type external;
export lengthen-as-path;
peer-as 3000;
neighbor 172.16.32.2;

[edit policy-options]
policy-statement lengthen-as-path {
then as-path-prepend u5000 5000";
}

Worldwiile fcrluL-ation Ser.iues "

i;vv~ v ;
. . ur,ipt-rne' |' S-

Policy to Expand Customer AS

The siide shows the routing poiicy AS 5000 used in the previous example.

You created a policy named lengthen-as-path on the AS 5000 router. Because no from
statement exists, all candidate routes match the policy. The action taken on all the matched routes is
to prepend the most recent AS twice. You do this with an as-path-prepend "5000 5000"
directive in the lengthen-as-path policy.
Finally, you apply the lengthen-as-path routing policy to the peer in AS 3000 so that it can take
effect.

Chapter 9-52 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Output of show route displays various outputs in

AS path
. Brackets enclose the local AS number
. Braces enclose AS sets
. Parentheses enclose a confederation

user@router> show route protocol bgp terse

inet.D: 42 destinations, 42 routes (42 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

A Destination P Prf Metric 1 Metric 2 Nent hop AS path

*
64.16B.48.0/24 B 170 100 5 >10.222. 9.1 3944 2222 I
*
64. 168. 49. 0/24 B 170 100 5 >10.222.9.1 7777 7777 [7777] 1
*
64. 16B.S0. 0/24 B 170 100 5 >10.222.9.1 (444 5S5 7777} I
*
64.168.51.0/24 B 17 D 10 0 10 >10.Z22.3.1 (65009 65003 65000) 111 I

The Symbol Tells All

A symboi 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 sets-groups 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 BGP Attributes and Policy-Part 1 . Chapter 9-53

Advanced Junes Service Provider Routing

; ir Expressio , s

Often, BGP policy relies on finding prefixes based on

their AS-path information
.
Used to enforce administrative policy
.
Sometimes easier than looking for specific prefixes
Common policy requirements;
.
Find all routes originating in AS 1
. Find all routes that transited AS 100
.
Find all the routes originating in my own AS
AS-path regular expressions allow the selection of the
proper prefixes

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.

Chapter 9-54 . BGP Attributes and Policy-Part 1 www.Juniper.net

 Advanced Junes Service Provider Routing

A powerful pattern-matching engine

Work not only on fixed strings (as do wildcards), but
on variable patterns of text
Combination of text and special operators
Allow for things to be found in context, not as isolated
instances

Regular Expressions for Pattern Matching

A reguiar expression (often cailed regex) is a powerful, pattern-matching tool you can apply in a
routing policy to acton 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 BGP Attributes and Policy-Part 1 . Chapter 9-55

Advanced Junos Service Provider Routing

teg pression Terms

Regular expressions take the form term operator

Terms are mandatory and identify the AS number:
.
Can be a single AS number
.
For example. 1024
.
Can be a complete AS path
.
For example. 1024 2685 3957
.
Can be a wildcard dot character ( . ), which represents a
single AS
.
For example. 1024 . 3957

Each AS number (not a character) represents a single

entity to the regular expression parser

Configure a Regular Expression

Regular expressions have two main components to them-the 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.

Chapter 9-56 . BGP Attributes and Policy-Part 1 www.Juniper.net

 Advanced Junos Service Provider Routing

legular Expression Operators

Regular expressions take the form term opera tor

The operator is an optional pattern-matching
character that applies to a single term
.
Operators immediately follow the term referenced
.
For example. 1024? 2685
.
The pipe ( j ) operator is used between terms
.
For example. 1024 | 2685
.
The dash (-) operator is used between terms
.
For example. 1024-2685

One or more term-operator pairs can appear in an

AS-path regular expression

Wnrlrlwldu tcfucation Services

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 BGP Attributes and Policy-Part 1 . Chapter 9-57

Advanced Junos Service Provider Routing

Match at least m and at most n repetitions of term

Match exactly m repetitions of term
Match m or more repetitions of term
Match 0 or more repetitions of term, same as {0,}
Match 1 or more repetitions of term, same as {1,}
Match 0 or 1 repetitions of term, same as {0,1}
Match one of the two terms on either side of the pipe
Used to represent a range
Used to group terms, or indicate null with no space

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 lor 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 nullAS-path value. We cover the concept of the null AS path on future
slides.

Chapter 9-58 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junes Service Provider Routing

Ixpression i
'

: AS-path pattern to match: Regex: Sample matches;

Exactly one instance of AS 1 ?34 1234 1934

0 or more instance of AS 1234 1234* 1234,1234 1234. etc..

or null AS path
0 or 1 instance of AS 1934 1234? 1234

null AS path
Ito 4 instances of AS 1234 1234{1.4} 1234.1234 1934.1234 1
19341234.
1234 1234 1234 1234

Ito 3 instances of AS 1 ? followed by 12(1.3} 34 12 34. 12 12 34.

1 instance of AS 34 12 12 12 34

Range of AS numbers to match a 123 - 125 123 or 124 or 195

single AS

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 BGP Attributes and Policy-Part 1 . Chapter 9-59

Advanced Junos Service Provider Routing

More Regex Examples

: AS-path pattern to match: Regex: Sample matches:
Second AS must be 56 or 78 . (56|7S) 1?34 56.
34 78

Second AS might be 56 or 78 . (56|78)? 1234.1234 56. 34 78

All paths from neighbor AS 1234 1234.* 1234.1234 5678,

12345 678

1 followed by 2. followed by one or 12 3+ 12 3. 123 3.

more instance of 3 12 3 3 3. etc.

One or more instance of 1, then 2. 1+2+ 3+ 12 3. 112 3,

then 3 1122 3. 11223 3.
etc.
*
Any length path that contains the list .
456.* 123456.
4 5. 6 in it anywhere
, 12345678 9.
456789

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.

Chapter 9-60 . BGP Attributes and Policy-Part 1 www.junlper.net

 Advanced Junes Service Provider Routing

AS regular expressions are defined at the

policy-opt ions hierarchy level
[edit policy-options]
user@user# set as-path name regular-expression
Format;
.
name identifies the regular expression
*
regular-expression consists of the pattern to match In
term opera tor format
The name can be up to 255 characters long
To include spaces in the name, enclose the entire name
in double quotation marks
Can use the defined AS-path regex as a policy match
condition

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 Junes 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 BGP Attributes and Policy-Part 1 . Chapter 9-61

Advanced Junes Service Provider Routing

Accept only routes with the exact AS path of

1234 56 78 9
[edit policy-options]
as-path digits-route "
123 4 5 6 7 8 9"

policy-statement from-digits-route {
term digits {
from as-path digits-route;
then accept;

term reject-others {
then reject;
}
}

[edit protocols]
bgp {
import from-digits-route;

t
1

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
containsonly 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 f rom-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. Ail other routes seen by BGP are rejected.

Chapter 9-62 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Reject any routes with AS 123, 124, or 125 anywhere

in the AS path
[edit policy-options]
"
as-path not-a-good-route 123-125 .*

policy-statement from-not-a-good-route {
term not-good {
from as-path not-a-good-route;
then reject;
}
}

[edit protocols]
bgp {
import from-not-a-good-route;
}

Vo rldwicleEdiicjtion Services

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 123-125, transited through ASs
123-125, or were advertised directly from ASs 123-125.

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 BGP Attributes and Policy-Part 1 . Chapter 9-63

Advanced Junes Service Provider Routing

Consider this policy statement:

policy-statement testing-as-paths {
term as-paths {
from as-path testing-1-2-3;
then accept;
}
then reject;

Will the router accept a route with the path 102 4 4 4

44 2 685, given the following as-path statements?
9 set as -

path testing- 1 -
2 3
-
102 4"
"
8 set as -

path testing- 1 -

2 3
-
1024 .*"
. set as -

path testing- 1 -
2 3
-
1024 .*"
. set as -

path testing- 1 -

2 -

3 44{1,2} .*"
"
. set as -

path testing- 1 -
2 3
-

2685 44{1,3}
1024"
-
. set as -

path testing- 1 -
2 3
-

1024 44{1,3}
2685"
Wsrldwide Education Services

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.

Continued on the next page.

Chapter 9-64 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Look at the Results (contd.)

.
».* 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} 2 685": 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.

www.juniper.net BGP Attributes and Policy-Part 1 . Chapter 9-65

Advanced Junes Service Provider Routing

mmmmmts

Support for as -path-group

.
Simplifies AS path-related policy in situations where:
.
You have a large number of individual AS-path regular expressions
that are evaluated as a logical OR
.
You have a single large AS-path regular expression that is difficult
to understand because of its size
[edit policy-options]
userSrouterl show
policy-statement test-as-group {
term 1 {
from as-path-group as-group-1;
then accept;
}
term 2 {
then reject;
}
}
as~path-group as-group-1 {
as-path path l ".* 1 .*;"; _

as-path path 2 ".* 2 .*;"; _

as-path path 3 ".* 3 .*;";

_

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 l path 2 path 3
_ _ _
] ,-
}
as-path path l _
".* 1 .*";
as-path path 2 _
11 . * 2 .*";
as-path path 3 _
".* 3 . *";

Continued on the next page.

Chapter 9-66 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junes Service Provider Routing

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 BGP Attributes and Policy-Part 1 . Chapter 9-67

Advanced Junos Service Provider Routing

Routes that originated in your own AS have no AS

numbers in the path yet
To reference the null AS path within a policy, use
parentheses {with no space) regular expression
192.168.48,0/24
192.168.49.0/24 IBGP
192.168,50,0/24
192.168.51.0/24

usGr@router> show route protocol bgp terse

inet.D: 42 destinations 42 routes (42 active, 0 holddoww 0 hidden)

f = Active Route, - = Last Active, * = Both

A Destination P Prf Metric 1 Metric 2 Nent hop AS

192.168.48.0/24 B 170 10 0 5 >10.222.9 1 I

192.168.49.0/24 B 170 100 5 >10.222. 9 1 I

192.168.50.0/24 B 170 100 5 >10.222.9 1 T

192.168.51.0/24 B 170 10 0 ID >10.222. 9 1 1

..
. tiunSfirvircs
.

Role of Null AS Path

The concept of the nuli 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 originatingwithin 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 router s own AS. The null AS path finds these routes.

Chapter 9-68 . BGP Attributes and Policy-Part i www.juniper.net

 Advanced Junes Service Provider Routing

Ml ft ft Path
.
Stop fti

AS 2 does not want to provide transit service to AS 1

10.200.0,0/16
172.31.0.0/16; 1
172.31,0.0/16; 1 AS 2
192,168,14/24; 1 192,168,14/24: 1

AS1
AS 4

172,31,0.0/16: 1
10.100,0,0/16: 3
192,168,14/24: 1
10,100.0,0/16 172,31,0,0/16: 3 1
AS 3 172.31.0.0/16: 1 192,168,14/24: 3 1
192.168.14/24: 1

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 BGP Attributes and Policy-Part 1 . Chapter 9-69

Advanced Junes Service Provider Routing

AS Path In Action (1 of 2)

AS 1
192.168.48.0/24
192.168.17.0/24 IBGP
192.168.49.0/24
192.168.50,0/24
EBGP
192.168.51.0/24 pA
\ EBGP
policy-options {
policy-statement not-a-transit {
term accept-my-as {
from { 10,222. 11,1 \
protocol bgp;
as-path my-own-as;
)
then accept;
}
term reject-all-else {
then reject;

>

"
as-path my-own-as () ";

enport not~a~transit;

\Vorldvvidrtf duodtion StTiiuns mjuniper.net ] 3-70

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.

Chapter 9-70 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junes Service Provider Routing

: Path in Action (2 of 2)

ASl
192.168.48.0/24
192.168.17.0/24 192.168.49.0/24 iBGP

192.168,50.0/24
EBGP
Rl 192.168.51.0/24

EBGP
user@R2> show route protoc;ol bgp terse
inet.O: 43 destinationsf 43 routes (43 active, 0 holddown, 0 hidden) 10.222.11.1

A Destination P Prf Metric 1 Metric 2 Next hop AS path

*
192.168.17.0/24 B 170 100 5 >10. 40. 40. 1 1 I /
192.168.48.0/24 B 170 100 5 >10. 40. 40. 1
I 1
192.160.49.0/24 B 170 100 5 >10. 40. 40. 1 I \
* 192.168.50.0/24 B 170 100 S >10. 40. 40. 1 I
*
192.168.51.0/24 B 170 100 10 >10. 40. 40. 1 I

usergR2> show route advertIsing-protoool bgp 10.222.11.1

inet.O: 43 destinations, 43 routes (43 active, 0 holddown, 0 hidden)

Prefix Hexthop MED Lclpref AS path
192.168. 48. 0/24 192.168.48.1 5 100 I
192.168.49.0/24 192.168.48.1 5 100 I
192.168.SO.0/24 192.168.48.1 5 100 I
192.16B.51.0/24 192.168.48.1 10 100 1

Worldwide EciucationServis s m juniperinst I 9-71

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 Rl. One of these routes is from AS 1, and the other four are souroed 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 BGP Attributes and Policy-Part 1 . Chapter 9-71

Advanced Junes Service Provider Routing

Sue

In this chapter, we:

.
Described various BGP attributes in detail and explained the
operation of those attributes
.
Manipulated BGP attributes using routing policy

Wo ridwi c! e Eciucatio n Servi gb s w

.
-

.
juniper n&f j 9-T2

This Chapter Discussed:

Various BGP attributes in detail and explained the operation of those attributes; and

How to manipulate BGP attributes using routing policy.

Chapter 9-72 . BGP Attributes and Policy-Part 1 www.juniper.net

 Advanced Junos Service Provider Routing

Review Questions

1 . Between which two RIBs does an import policy

operate? What about an export policy operate?
2 .
Why does Junos OS set all origin codes to internal,
regardless of actual source of the route?
3 . Why is the default not to compare MEDs that come
from two different ASs?

4 .
What is the intent of prepending a local AS number
multiple times to all BGP routes?

Review Questions
i .

www.juniper.net BGP Attributes and Policy-Part 1 . Chapter 9-73

Advanced Junos Service Provider Routing

Repair unusable routes.

Influence routing using the origin, MED, and AS path
attributes.

VVotlclwiile i diicalicin Smii;i.;s

Lab 8: BGP Attributes: Next-Hop, Origin, MED, and AS Path

This slide provides the objectives for this lab.

Chapter 9-74 . BGP Attributes and Poiicy-Part 1 www.juniper.net

juniperNETWORKS

Advanced Junos Service Provider

Routing

Chapter 10: BGP Attributes and Policy-Part 2

Advanced Junos Service Provider Routing

Chapter Objectives

After successfully completing this chapter, you will be

able to:
.
Describe the BGP attributes local preference and
communities in detail and explain the operation of those
attributes
.
Manipulate those BGP attributes using routing policy

This Chapter Discusses:

The BGP attributes local preference and communities and explains the operation of
those attributes; and

The manipulation of those BGP attributes using routing policy.

Chapter 10-2 . BGP Attributes and Policy-Part 2 www.Juniper.net

 Advanced Junes Service Provider Routing

Agenda: BGP Attributes and Policy-Part 2

-
> Local Preference
Communities

orlrivmle EduCcUiuti Services

Local Preference

The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.Juniper.net BGP Attributes and Policy-Part 2 . Chapter 10-3

Advanced Junes Service Provider Routing

The Power of Lr reference

Local preference is the first BGP attribute used to

favor one route over another

A route with higher local preference always wins-

regardless of the AS-path length

Local Preference
AS Path

Origin
I MED

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 AS-the end.

Chapter 10-4 . BGP Attributes and Policy-Part 2 www.Juniper.net

 Advanced Junos Service Provider Routing

- reference is Not ¥ Preference

Local preference is a priority applied within BGP itself

.
If you set no local preference for a route, a default value of
100 Is used
.
Set local preference in [edit protocols bgp]
.
Change local preference with local -preference in a
routing policy
Preference is a priority applied to routing protocols
themselves
.
For example, the BGP preference is 170
.
Set preference in [edit protocols bgp]
.
Change preference with preference in a routing policy

Make sure to change local preference, not route

preference!
_

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 locahpreference 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 BGP Attributes and Policy-Part 2 . Chapter 10-5

Advanced Junes Service Provider Routing

Exchanged by IBGP peers only

Usually used to set the exit point from an AS
IBGP propagates information throughout the AS
Which router to reach 172.17.2.0?
Using Router B
makes sense

172.17.2.0/24

IBGP makes sure each peer

knows to use Router B This AS neither knows nor cares about
the other AS's local preference
through local preference

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.

Continued on the next page.

Chapter 10-6 . BGP Attributes and Policy-Part 2 www.juniper.net

 Advanced Junos Sen/ice Provider Routing

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 BGP Attributes and Policy-Part 2 . Chapter 10-7

Advanced Junos Service Provider Routing

Applenet wants to use 0C-12c outbound but have

0C-3c available for inbound traffic and backup
outbound traffic -
Zebranet * ( 192.168.27.0/24

/ \
Banana net '. Coco net

192.168.27.0/24 192.168.27.0/24
10 GE
1GE

Rl
IBGP

Local Preference = 200 Local Preference = 300

Applenet

Example of Local-Preference Use

The slide shows an example of local-preference use within an AS.

The network administrators in Applenet decided that the routers in Applenet should use R2 to reach
the 192.168.27.0/24 network in Zebranet. This decision is because of the greater bandwidth
capacity available on that link: an OC-120 runs at 622 Mbps, while an 0C-3c runs at 155 Mbps.

To do this, the Applenet network administrators set the local preference on the route to
192.168.27.0/24 advertised to Rl by Banananetto 200, and set the local preference on the route to
192.168.27.0/24 advertised to R2 by Coconet to 300.
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 Applenet.
The link onRl can still be used for inbound traffic flows from Zebranet and for outbound failover
traffic if the OC-12c is not useable because of a router or link failure.

Chapter 10-8 . BGP Attributes and Policy-Part 2 www.juniper.net

 Advanced Junes Service Provider Routing

Local preference is not propagated to Pearnet

Pearnet must rely on other BGP attributes to make a
path determination
Zebranet 192.168.27.0/24

Banananet Coconet

192.168.27.0/24
192.168
27-0/24\ lGE 10 GE

0
WW.W....Ji!!-'F «.!!lWafi

Applenet

Tl/El Tl/El
192.168.27.0/24 192.16S.27.0/24

Pearnet

urldv/iilc tducaiionSvniees

Local AS Only
The slide points out the local nature of local preference. Consider another AS called Pearnet linked
by two lower-speed, but equal, links to Applenet. Which link should Pearnet use to reach
192.168.27.0/24 in Zebranet?

Because EBGP does not propagate the local-preference values used inside Applenet, the Pearnet AS
has no knowledge of the local-preference routing decisions made within Applenet with regard to the
192.168.27.0/24 route. Applenet, of course, still wants traffic from Pearnet to flow towards R2 to
avoid shuttling all this traffic across its backbone.

Another Method Needed

However, Applenet cannot accomplish this goal with local preference. Applenet must use other BGP
'

attributes instead of local preference, such as AS path or MED, to influence Pearnet s flow of traffic
to Applenet. This is because of the strictly local nature of the local-preference attribute.

www.juniper.net BGP Attributes and Policy-Part 2 . Chapter 10-9

Advanced Junes Service Provider Routing

Pre ncs mmmmm

Summary:
.
Determines outbound AS traffic flow towards the highest
local-preference exit point
.
Most powerful BGP attribute
.
Very common usage within an AS
.
Should be applied consistently at AS borders

Summary of Local-Preference Points

This slide summarizes the important points with regard to the local-preference attribute:
It is a guarantee of outbound traffic flows. In fact, little else can be done with BGP to
establish an exit point for an AS.

It is the most powerful BGP path selector and is commonly used to override other BGP
attributes in the path selection process. Local preference selects a BGP route
regardless of the values of AS path, origin, or MED.

It is very commonly used within an AS, but it is local to the AS only. The local preference
is never sent to another AS with EBGP.

It should be applied consistently at the edge of the AS for maximum efficiency. That is,
the local preference should be set on a route advertised from another AS at the border
router and not changed haphazardly within the AS.

Chapter 10-10 . BGP Attributes and Policy-Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Change the local preference of routes with an AS path

of 124 44 13 to 200 {instead of the default 100)

[edit policy-options]
as-path look-for-path "124 44 13"
policy-statement check-the-patli {
term got-path {
from as-path look-for-path;
then {
local-preference 200;
accept;
}
}
}

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 BGP Attributes and Policy-Part 2 . Chapter 10-11

Advanced Junos Service Provider Routing

Because local preference overrides all other attributes,

can a routing loop be created in your network?
.
Both Rl and R2 set local preference to 1000 to all IBGP
peers (including each other) using export policy
.
Does Rl and R2 see each other as the best way to get to the
remote network and thus form a loop?

172.17/16

; 172.17/16
172.17/16
! LP=1000
LP - 1000

172.17/16
LP - 100C
172.17/16

Worldwide E

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 Rl 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
Rl and R2 have an IBGP peering relationship with each other, which means that both routers also
advertise the route to each other.

Theoretically, both Rl 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, Rl 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 route's 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.

Chapter 10-12 . BGP Attributes and Policy-Part 2 www.juniper.net

 Advanced Junes Service Provider Routing

No Loop in Hiis Case

IBGP sessions implement split horizon, so only Rl or
R2 sends out local-preference values
«Assume R2sets local preference to 1000 first
. Rl installs the R2 routes as active and does not advertise those
routes back to R2
.
A routing loop is not formed in this particular case

172.17/16 Rl
17217/16
LP = 1000

172.17/16
LP - 1000

Hi

17217/16
R2
LP = 1000

172.17/16

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 Rl 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, Router 2 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
locaLpreference value. At this point, both Rl and R3 receive the 172.17.0.0/16 route through IBGP.

Rl then also receives the EBGP route for 172.17.0.0/16 from the other AS. At this point, Rl
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-recelved route.

Because the current version of the route on Rl is from R2, and because IBGP Implements split
horizon, the routing loop never forms. Rl 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/16-R2 Is the choice.

www.Junlper.net BGP Attributes and Policy-Part 2 . Chapter 10-13

Advanced Junos Service Provider Routing

Agenia; i©P Atl trlbui tes an i Policy-Part 2

Local Preference

Communities

Communities

The slide highlights the topic we discuss next.

Chapter 10-14 . BGP Attributes and Policy-Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

BGP attribute (optional) passed along to other BGP

peers (transitive)
A group of destinations that share a common property
Simplify routing policies by identifying routes based
on logical bounds you establish
.
AS number is very broad (lots of routes)
.
IP prefix is very granular (route filter for each route?)
Used with other attributes to accept, prefer, or
advertise BGP routes

Optional, but Transitive

The BGP community attribute is an optional attribute so not ali 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 BGP Attributes and Policy-Part 2 . Chapter 10-15

Advanced Junes Service Provider Routing

Notes on Communities (1 of 2)

Establishes categories for routes and prefixes

Often sets local preference for a group
Cuts down on manual reconfiguration and complexity
of maintenance

If a new prefix can be placed in a community, no other

changes to routing policy are necessary
Too many communities require more manual
maintenance

Too many overlapping communities can be a

nightmare

Clubs for Routes

BGP communities establish various logical categories for routes (prefixes). Think of BGP
communities as communff/es 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.

Continued on the next page.

Chapter 10-16 . BGP Attributes and Policy-Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

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 Inciude 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 BGP Attributes and Policy-Part 2 . Chapter 10-17

Advanced Junos Service Provider Routing

Notes 011 f nitles (2 of 2)

Well-known communities have a global meaning

Must define local-use communities

Community attribute is a list of four-octet, individual

community attribute values associated with a route
.
Route can belong to many communities
.
Two high-order octets represent an AS number
.
Two low-order octets represent a value unique to that AS
*
Represented in decimal form of AS:number (for example,
200:666)
*
All values in AS 0 and 65535 are reserved: 0x00000000 to
OxOOOOFFFFand OxFFFFOOOO to OxFFFFFFFF

Weil-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.

Continued on the next page.

Chapter 10-18 . BGP Attributes and Policy-Part 2 www.juniper.net

 Advanced Junes Service Provider Routing

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 OxOOOOFFFF (AS 0) and OxFFFFOOOO to OxFFFFFFFF (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.-ac(m/n;strator;ass;gned-number.

www.juniper.net BGP Attributes and Policy-Part 2 . Chapter 10-19

Advanced Junes Service Provider Routing

II® i4Ci: mm mmm m m m Smni

Three standard values:

*
No-export (OxFFFFFFOl): These routes must be distributed
within the confederation (or AS), but no farther
.
No-advertise (0xFFFFFF02): These routes must not be
advertised to other BGP peers
.
No-export-subconfed (OxFFFFFFOS): These routes must not
be advertised to external BGP peers (confined to sub-AS)
No-export typically keeps aggregation optimal
.
No-export-subconfed extends this to the sub-AS

No-advertise has narrower scope

. Often used when dual links exist between two routers

The Three Well-Known Communities

Three community attribute values are designated as weli-known communities. These well-known
communities share the AS value of 65535 (OxFFFFxxxx). The three communities are no-export,
no-advertise, and no-export-subconfed.

No-export (OxFFFFFFOl): This value tells routers to distribute routes with this
community tag within the confederation or AS, but no farther.

No-advertise (OxFFFFFFOl): This value tells routers not to advertise these routes to
other BGP peers at ali. (Despite appearances, this BGP community is quite useful.)

No-export-subconfed (OxFFFFFFOS): 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.

Chapter 10-20 . BGP Attributes and Policy-Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Routes go no further than the next hop

AS1
:

AS 65000

AS2
-

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 into an AS with subconfederations.

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.

www.juniper.net BGP Attributes and Policy-Part 2 . Chapter 10-21

Advanced Junos Service Provider Routing

Routes go no farther than the sub-AS

AS 65000

AS2

JUmPS' WortcMcle Cdiiciitiun Smira 5

Sample Use of No-Export-Subconfed

The siide 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 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, as shown on the slide.

Chapter 10-22 . BGP Attributes and Policy-Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Export

Routes go no farther than the entire AS

ASl

\
/
AS 65000 -

AS2

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 into an AS with subconfederations.
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, as shown on the slide.

www.juniper.net BGP Attributes and Policy-Part 2 . Chapter 10-23

Advanced Junes Service Provider Routing

AS 2 should use load sharing, but why should the

Internet know or care about the /17 routes?
.
Advertise both the /16 and the/ll routes and use
no-exporton /17s
172,17/16
172.17.0/17 (No-export)

172.17.0/17

Internet
172.17/16 \

172.17.128/17
172,17/16
172.17,128/17 (No-export)

A'otltlwiele EciuoatlonSetvioes
I

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 readvertlse the /17 routes. Only the /16
route Is readvertised to the Internet.

Chapter 10-24 . BGP Attributes and Policy-Part 2 www.juniper.net

 Advanced Junes Service Provider Routing

nternet
172.17/16
172.31/16

172,17/16 172,31/16

172,17/16 172,31/16
172,17,144/20
172.17/16 172,31/16
172.17.144/20
AS1 AS 2 -

Customer

172,17.144/20
AS 20
172.17.144/20 No-Export

172.17.144/20

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 I nternet 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 65000 has address space 172.17.144.0/20, taken from AS 1's 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 65000 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 65000 is reachable through AS 1 from the
Internet, but AS 65000 is only reachable by local AS 2 users.

A drawback of this scenario is that if the link from AS 65000 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
65000, this might be acceptable.

www.juniper.net BGP Attributes and Policy-Part 2 . Chapter 10-25

Advanced Junos Service Provider Routing

Customer agrees to provide backup transit service to

AS 1 and AS 2
Requires agreement between all the networks to play
nicely with the values
Internet
172.17/16
172.20/16

172.17/16 172.20/16

172.17/16 172.20/16

Cudomer
AS1
AS 2

172.17.64/18 172.17/16 2:70

172.20/16 1:60 I .
172.17,64/18
172.20.128/18 172.17.64/18 f 172.20,128/18
172.20.128/18
1:60 = Local preference of 60 2:70 = Local preference of 70

iDiPGr Worltlwiile 1 ducal Servici s

Transit AS for Backup

One of the most common uses of the BGP community attribute addresses one major iimitation of the
BGP iocai-preference attribute. Locai 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.

Continued on the next page.

Chapter 10-26 . BGP Attributes and Policy-Part 2 www.Juniper.net

 Advanced Junes Service Provider Routing

Transit AS for Backup (contd.)

The key to making this work is with the BGP communities on routes sent to AS land 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
'
customer s 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 mates an AS respect the community attribute value.

www.juniper.net BGP Attributes and Policy-Part 2 . Chapter 10-27

Advanced Junos Service Provider Routing

Can use policies in BGP to make an AS appear as a

transit AS or nontransit AS for a route

Communities make it easier to hold back routes that

might be used to transit an AS
National ISP #2

National SP#1

National #1 routes; NO
Small ISP's local routes: YES
National #1 routes

National #1 routes
R2 Small ISP
Small ISP's local routes

Sma///SP needs to advertise its own routes, but never be transit AS!

Vorldwide Education Service

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 Rl of
the small ISP as shown on the left. Rl advertises not only its own local routes to R2 In the small ISP,
but also National ISP #l's routes, so that all users can reach these routes.

Continued on the next page.

Chapter 10-28 . BGP Attributes and Policy-Part 2 www.Juniper.net

 Advanced Junos Service Provider Routing

Communities Can Hold Back Routes (contd.)

But R2 should never, ever advertise National ISP #l's routes to National ISP #2! Rl's and R2,s 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 BGP Attributes and Policy-Part 2 . Chapter 10-29

Advanced Junos Service Provider Routing

iring IP Community

Configure at [edit policy-options] hierarchy

level
.
Multiple community-ids mean a logical AND
[edit policy-options]
community name members [community-ids];

Community ID format:

.
Community ID can also be:
.
no-export
. no-advertise
.
no-export-subconfed

Use in a policy as a match condition or an action

.
Actions include add, delete, and set

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 Communi tyl, AND Communi ty2, AND Communi ty3, and so on.

Community ID Format
The community ID has an as-number: communi ty-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-subconf ed 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.

Chapter 10-30 . BGP Attributes and Policy-Part 2 www.juniper.net

 Advanced Junes Service Provider Routing

Leave existing communities alone and add in the

specified value
user@router> show route 182.168.0/24
192.168.0.0/24 (2 entries, 1 announced)
Communities: 64512:567 100:20 50:70 1234:66

[edit policy-options]
policy-statement community-actions {
term add-a-community
then community add test-comm;
}
}
community test-comm members 65001:1234;

user@router> show route 182.168.0/24

192.168.0.0/24 (2 entries, 1 announced)
Communities: 64512:567 100:20 50:70 1234:66 55001:1234

"

aotlilrtiilutclucallfinSii

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 cowmuni ty-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 acfefeef 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 BGP Attributes and Policy-Part 2 . Chapter 10-31

Advanced Junes Service Provider Routing

0111 .y Actions: Peletg

Remove only the specified values and leave other

existing communities alone
user8router> show route 182.168.0/24
192.168.0.0/24 (2 entries, 1 announced) "

Communities: j64512: 567 ]l00 : 20 50:70 1234: 66

[adit policy-options]
policy-statement community-actions {
term add-a-community
then community delete test-comm;
}
}
community test-comm members 64512:567;

192.168.0.0/24 {2 entries, 1 announced)

Communities: 100:20 50:70 1234:66

'
. . :::;--/!-:
-

-
:
:
-

.
; '
'
. rldviik' EUuCiiliun Six.ices

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.

Chapter 10-32 . BGP Attributes and Policy-Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Commun lid

Remove ALL existing communities and add the

specified values
user@router> show route 182.168.0/24
192.168.0.0/24 (2 entries, 1 announced)
Communities: 64512:567 100:20 50:70 1234:66

[edit policy-options]
policy-statement community-actions {
term add-a-community
then community set test-comm;
}
}
community test-comm members 65001:1234;

192.168.0.0/24 (2 entries, 1 announced)

Communities: 165001:1234

Woridwicie Eduoalicn Services : .

www juniper net \ 10-33

Set the Community String

The slide also shows a policy that defines and applies a community in a routing policy. This policy
removes a//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 communi ty-actions has no from statement, all routes are matched.

All BGP routes have the community tag tes t-comm value of 65001:1234 set as the existing
communitytagontheroute. 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 BGP Attributes and Policy-Part 2 . Chapter 10-33

Advanced Junos Service Provider Routing

Create and apply a community named customeri

. Set MED to 20

.
Set BGP local preference to 200 (instead of 100)

[edit policy-options]
community customers members [56:2379 23:46944];
policy-statement from-customers {
from community customers;
then {
metric 20;
local-preference 200;
next policy;
}
}

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).

Chapter 10-34 . BGP Attributes and Policy-Part 2 www.juniper.net

 Advanced Junes Service Provider Routing

Create and apply a community named my-accept

.
Reject routes more specific than /19 for Class A, /16 for
Class B, and /24 for Class C
[edit policy-options]
community my-accept members 567:1;
policy-statement drop-specifics {
term drop-specifics {
from {
route-filter 0.0.0.0/1 upto /19 {
community add my-accept;
next policy;
}
route-filter 128.0.0.0/2 upto /16 {
community add my-accept;
next policy;
}
route-filter 19 2.0.0.0/3 upto /24 {
community add my-accept;
next policy;
}
}
}
then reject;
}

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 prefix's 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 rej act 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.

Continued on the next page.

www.Juniper.net BGP Attributes and Policy-Part 2 . Chapter 10-35

Advanced Junos Service Provider Routing

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;
}
route-filter 128.0.0.0/2 upto /16 {
community add my-accept;
next policy;
}
route-filter 192.0.0.0/3 upto /24 {
community add my-accept;
next policy;
}
route-filter 0.0.0.0/1 upto /32;
route-filter 128.0.0.0/2 upto /32;
route-filter 192.0.0.0/3 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 term's re j ect 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.

Chapter 10-36 . BGP Attributes and Policy-Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

Communities in Routing Policy

Some routing policies delete communities, which

might be useful at AS boundaries
By default, communities are sent to peers
To stop community advertising, delete the community
This policy deletes all communities-the asterisk ( * )
wildcard matches any possible value
[edit policy-options]
community wild-match members

policy-statement delete-all-communities {
term all-gone {
then community delete wild-match;
}
}

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.

Continued on the next page.

www.Junlper.net BGP Attributes and Policy-Part 2 . Chapter 10-37

Advanced Junos Service Provider Routing
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 community-the AS number as well as
the community value. The syntax is therefore " * : *" to match all communities.

Chapter 10-38 . BGP Attributes and Policy-Part 2 www.Juniper.net

 Advanced Junes Service Provider Routing

Regex and Ooinin&ifMties

Simple community regex expressions can use wildcard values

of asterisk (*) or dot (.)
.
The asterisk matches any single AS number or community value
.
The dot matches any single digit within the AS or community value
.
Thecombinationof these wildcards (. *) means somethingdifferent and
is considered a complex community regex
Examples of simple community regex matches:
.
All communities from particular AS: as-number: *
.
Forexample, 600:* matches all AS 600 communities
*
Ail AS networks with the same value: * : coicmunity-value
.
Forexample, *: 20 matches value 20 from all AS areas
.
All community values where the 3rd digit is any number
.
Forexample, 1111:50 . 0 matches 5000. 5010, 5020. etc. up to 5090
from AS 1111

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 ccmplex 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,
Continued on the next page.

www.Junlper.net BGP Attributes and Policy-Part 2 . Chapter 10-39

Advanced Junos Service Provider Routing

Examples of Simple Community Regular Expressions

Some examples of simple community regex matches are:
*
: 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.

Chapter 10-40 . BGP Attributes and Policy-Part 2 www.juniper.net

 Advanced Junes Service Provider Routing

,
' (1 of 2)

user8router> show route communitY *:20 terse

inet.O: 123 destinations, 123 routes (123 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

A Destination P Prf Metric 1 Metric 2 Hext hop AS path

*
192.168.128.0/24 S 5 5 Reject

user@router> show route community *:20 detail

inet.O: 123 destinations, 123 routes (123 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

192.168.128.0/24 (1 entry, 1 announced)

*
Static Preference: 5
Next hop type: Reject
State: <Active Int Ext>
Age: 3d 6:07:37 Metric: S
Task: RT

Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 5-Aggregate

AS path: I
Communities: 1:20

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 BGP Attributes and Policy-Part 2 . Chapter 10-41

Advanced Junes Service Provider Routing

'

ty tch 2

user@router> show configuration policy-options

policy-options {
community community-l members 1:20;
}

user@router> show route community-name community-l detail

inet.O: 123 destinations, 123 routes (123 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

192.168.128.0/24 (1 entry, 1 announced)

*
Static Preference: 5

Next hop type: Reject

State: <Active Int Ext>
Age: 3d 6:07:37 Metric: 5
Task: RT

Announcement bits (3): 0-KRT 1-EGP.0 .0.0.0+179 5-Aggregate

AS path: I
Communities: 1:20

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-l defined within [edit
pel icy-opt ions]. This community represents the value of 1:20. You can use this community
name in the show route conununity-name comraunity-l detail command to view all
routes having this community assigned.

Chapter 10-42 . BGP Attributes and Policy-Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

More -'G,j£>ic-;"

Can use more complex regular expressions with

communities
.
Community regex is character based (not like AS path)
.
Format is still term operator
.
Regexanchors (A) and ($) are not required, but can be
helpful
.
Used in both show route and within a policy as a match
condition
.
show route community regex
.
community match-this members regex

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 BGP Attributes and Policy-Part 2 . Chapter 10-43

Advanced Junos Service Provider Routing

{m,n} Match a least m and at most n repetitions of term

{m} Match exactly m repetitions of term
'

{m } . Match m or more repetitions of term

Match 0 or more repetitions of term same as {0,} ,

+ Match 1 or more repetitions of term same as {IJ ,

? Match 0 or 1 repetitions of term, same as {0 1} ,

Match one of the two terms on either side of the pipe

"
Match character at start of community
$ Match character at end of community
[] Match range or array of letters or digits
( ) () Used to group terms, or indicate null with no space
WotldwitlBEtlucation Services

Community Regular Expression Operators

The tabie on the siide 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.

Chapter 10-44 . BGP Attributes and Policy-Part 2 www.Juniper.net

 Advanced Junes Service Provider Routing

,
. \ jgen Examples

; Community pattern
u 4
' Regex: Matches:
to match: .

,
: .
:
- } .
[ J .. .

AS is 56 or 78 -
((56)|(78)):(.*)$" 56:1000.
78:65000

AS is 56 and value starts with a 2 A56;(2.*)$" 56:234.56:2,

.

56:222
"

AS can be anything and value %*):( *[579])$"

.
1 ?34:5.
ends with either a 5. 7, or 9 78:2357.
34:65005

AS is 56 or 78. value starts with a A((56)|(78)):(2.*[2-8])$"

.

56:22,
2 and ends with any value 56:21197,
between 2 and 8 78:2678

1
'

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 BGP Attributes and Policy-Part 2 . Chapter 10-45

Advanced Junes Service Provider Routing

Test Your Knowledge

Does the following community regex meet the

criteria?
. The AS can be either 105, or 207, or 309
.
The value must be a 4- or 5-digit number starting with a 1
. Or, the value must start with a 2 5, or 6 ,

. Or, the value must end with a 3 4, 7, or 9 ,

,,
A ( (105) | (207) j (309) ) : ( (1. {3, 4} ) j ( [256] .*)
*
( . [3479] ) )$"

liiiii
Complicated Community Reguiar 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 temvoperator pairs in its
definition. To understand better how the expression operates, let's 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) j (207) j (309)) : (() j () j ())$. Each of the possible community values in this
'

example is an individual expression itself. We ll examine each one In turn.

Continued on the next page.

Chapter 10-46 . BGP Attributes and Policy-Part 2 www.juniper.net

 Advanced Junos Service Provider Routing

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:
M (105) | (207) j (309) ) : ( (1. {3,4}) I ( [256] .*) I ( .*[3479] ) ) $.

www.Juniper.net BGP Attributes and Policy-Part 2 . Chapter 10-47

Advanced Junos Service Provider Routing

B In this chapter we: ,

. Described the BGP attributes Local Preference and

Communities in detail and explained the operation of those
attributes
.
Manipulated those BGP attributes using routing policy

This Chapter Discussed:

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.

Chapter 10-48 . BGP Attributes and Poiioy-Part 2 www.juniper.net

 Advanced Junes Service Provider Routing

Review Questions

1 . What is the difference between local preference

and route preference?
2 . Does local preference affect inbound or outbound
traffic?

3 .
What are the well-known communities?

4 .
What is the difference between the add and set
community actions?

i I ,1 .
.
.
. i ,. ; i - .

Review Questions
i .

www.juniper.net BGP Attributes and Policy-Part 2 . Chapter 10-49

Advanced Junos Service Provider Routing

Lab 9: k mtmst
Local Preference and Coin in unities

Influence routing using the local preference attribute.

Influence routing using the community attribute.

VvorldwidB Education Servipes

Lab 9: BGP Attributes: Local Preference and Communities

The slide provides the objectives for this lab.

Chapter 10-50 . BGP Attributes and Policy-Part 2 www.juniper.net

juniperNETWORKS

Advanced Junos Service Provider

Chapter 11: BGP Route Damping

Advanced Junos Service Provider Routing

Ohaptei" stives

After successfully completing this chapter, you will be

able to:
*
Explain the causes for route instability
.
Describe the effect of damping on BGP routing
.
Explain the default behavior of damping on links
.
Control damping using routing policy
.
View damped routes using CLI commands

This Chapter Discusses:

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 11-2 . BGP Route Damping www.juniper.net

 Advanced Junos Service Provider Routing

Route Flap and Damping Overview

Route Damping Parameters
Configuring and Monitoring Route Damping

Worltlvmlc EUuoaiion Si:n.inps

Route Flap and Damping Overview

The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.juniper.net BGP Route Damping . Chapter 11-3

Advanced Junos Service Provider Routing

oute mmm

Routes can appear and disappear rapidly

.
Called route flapping or just flapping
Rapid sequence of update and withdrawn BGP
messages
.
Every BGP router that gets an update or withdrawn message
must propagate it to its peers
.
Effects quickly cascade and affect router performance
.
Consumes processing power and bandwidth
.
Damping tells a router to ignore changes that occur too
frequently
.
Reduced processor and protocol churn in the face of flapping
routes

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 lapping as the link flaps up and down.
f

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.

Continued on the next page.

Chapter 11-4 . BGP Route Damping www.juniper.net

 Advanced Junes Service Provider Routing

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. Damping tells a router to ignore routes that are changing state (flapping) too
often to prevent protocol churn on a global basis.

www.juniper.net BGP Route Damping . Chapter 11-5

Advanced Junos Service Provider Routing

Causes of Route Instability

Faulty circuits (most common)

IGP instability
Dynamic injection of IGP routes into BGP (static definition
.

and aggregation helps)

Human error
Incorrect routing policy
.

Link congestion
.
Overloaded links drop BGP sessions
In the past some routers have had problems
,

.
Software problems (bugs, especially after upgrades)
.
Insufficient power (for example, busy CPU drops BGP
sessions)
.
Insufficient memory (tables are kept in memory)
.
Network upgrades and maintenance (adding equipment)

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.

Continued on the next page.

Chapter 11-6 . BGP Route Damping www.juniper.net

 Advanced Junos Service Provider Routing

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.junlper.net BGP Route Damping . Chapter 11-7

Advanced Junos Service Provider Routing

1©P Sta 7 Features

Route damping is the main BGP mechanism to control

the route flapping effects
.
Defined in RFC 2439, BGP Route Flap Damping (November
1998)

Damping is ignored on IBGP sessions

Damping applies to EBGP sessions
.
EBGPsessions can carry thousands of routes
*
EBGP must update or withdraw these routes as required

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.

Chapter 11-8 . BGP Route Damping www.juniper.net

 Advanced Junes Service Provider Routing

ami mm n

Route damping is enabled in AS 1 cloud:

Internet

172.31.0/20-up
AS1 172.31.128/20-up

172.31.0/20-up
172.31,128/20-up S

*R1
..
. ..

172.31.0/20-up
172.31.64/20-up/down/up/down
Customer 172.31.128/20-up

Route Damping Use by ISPs

The siide 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 BGP Route Damping . Chapter 11-9

Advanced Junes Service Provider Routing

Route Flap and Damping Overview

-

>Route Damping Parameters

Configuring and Monitoring Route Damping

. ini oatiorirServiKes
.

Route Damping Parameters

The slide highlights the topic we discuss next.

Chapter 11-10 . BGP Route Damping www.juniper.net

 Advanced Junes Service Provider Routing

Figure of Merit

Type of point value given to a route that becomes a

penalty if it exceeds some value (suppress)
New route gets a figure of merit of 0
Point value of given incidents:
.
1000 points when route Is withdrawn
.
1000 points when route is readvertised
.
500 points when the path attribute is changed
Points decay (reduce) at a certain rate (half-life)
If points exceed cutoff (suppress) threshold, route
is suppressed (must be less than or equal to merit
ce/7/ng value)
When points fall below certain value (reuse), route is
used again
Maximum penalty imposed by max-suppress value
m img Mi
.

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 clement but that iss 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.

DefaultValue = 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.

Continued on the next page.

www.juniper.net BGP Route Damping . Chapter 11-11

Advanced Junos Service Provider Routing
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 ce/7/ng 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 ec. This maximum value is calculated from a
combination of the components listed above and is determined by the following formula:

ec<gre(ta)(ln2)
where er is the figure of merit reuse threshold, t is the maximum suppression (hold-down) time in
minutes, and k is the half-life in minutes.

Chapter 11-12 . BGP Route Damping www.juniper.net

 Advanced Junes Service Provider Routing

suppress: Cutoff (suppression) threshold

.
Value of penalty when damping is initiated
.
Default value 3000 (if changed, must be less than or equal to
merit ceiling value sr or no damping occurs)
reuse: Reuse threshold
.
Value to which penalty must decay for route to be used
again
. Default threshold is 750

half-life: Decay half-life, in minutes

.
Time it takes to reduce damping penalty by half
. Default is 15 minutes

max-suppress: Maximum hold-down time, in

minutes
.
Longest time to suppress the route activity
. Default is 60 minutes

Cutoff Threshold

The f igure-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 1-20000. If changed, this value must be less
than or equal to the merit ceiling ec, 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 1-20000.

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 1-45 minutes.

Continued on the next page.

www.Juniper.net BGP Route Damping . Chapter 11-13

Advanced Junes Service Provider Routing

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 1-720 minutes. At the end of themax-suppress interval,all is forgiven and the
route becomes active again.

Chapter 11-14 . BGP Route Damping www.Juniper.net

 Advanced Junes Service Provider Routing

Exponential decay, and there is a fixed ceiling

Incidents
increase
points

Down Decay rate determined

Suppress Up IN by half-life (15 minutes)
threshold
(3000) Down

Down

WorMwUie Education Services 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.

Continued on the next page.

www.juniper.net BGP Route Damping . Chapter 11-15

Advanced Junos Service Provider Routing

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.

Chapter 11-16 . BGP Route Damping www.juniper.net

 Advanced Junos Service Provider Routing

Route Flap and Damping Overview

Route Damping Parameters
Configuring and Monitoring Route Damping

Configuring and Monitoring Route Damping

The slide highlights the topic we discuss next.

www.juniper.net BGP Route Damping . Chapter 11-17

Advanced Junes Service Provider Routing

Damping parameters are defined within [policy

options] hierarchy
Can use as a policy action
.
half-life: 1-45 minutes, default 15
.
max-suppress: 1-720 minutes, default 60
. reuse: 1-20000. default 750
.
suppress: 1-20000, default 3000
.
disable = do not damp
[edit policy-options]
damping name {
half-life minutes;
max-suppress minutes;
reuse number;
suppress number;
disable;

Damping Parameters in a Routing Policy

Once damping is enabied 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.

Chapter 11-18 . BGP Route Damping www.juniper.net

 Advanced Junos Service Provider Routing

Internet

AS 100
AS1
Per-prefix
Aggressive
Default Dampin Damping

No Dampin

Customer

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 BGP Route Damping . Chapter 11-19

Advanced Junos Service Provider Routing

[edit policy-options]
policy-statement customer-inbound
then damping do-not-damp;
}
policy-statement internet-inbound
term let-some-through {
from {
route-filter 192.168.10.0/24 orlonger damping do-not-damp;
route-filter 172.16.240.0/24 orlonger damping do-not-damp;
route-filter 172.27.3 2.64/26 orlonger damping do-not-damp;
route-filter 192.168.100.0/24 orlonger damping do-not-damp;
}
then accept;
}
term damp-all-others {
then damping aggressive-damp;
}
}
damping do-not-damp {
disable; Is my policy correct?
}
damping aggressive-damp
half-life 30;
reuse 200;
suppress 1500;
max-suppress 120;
}

Sf 'A u rlrtwicle [.rJiicalionSmioes

Example of Damping Use: Part 2

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?

Chapter 11-20 . BGP Route Damping www.junlper.net

 Advanced Junes Service Provider Routing

R2:

[edit protocols]
Internet
bgp {
damping;
AS 100

R3:

[edit protocols
bgp {
damping; Rl:
import customer-inbound; [edit protocols]
bgp {
damping;
import internet-inbound;
Customer }

Worldwide EducaticmServices

Example of Damping Use: Part 3

The routers in AS 1 are next updated to apply the policies we created on the previous slide.

Router Rl 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 BGP Route Damping . Chapter 11-21

Advanced Junos Service Provider Routing

Amm :6

[edit policy-options]
policy-statement internet-inbound {
term let-some-through {
from {
route-filter 192.168.10.0/24 orlonger;
route-filter 172.16.2 40.0/2 4 orlonger;
route-filter 172.27.32.64/2S orlonger;
route-filter 192.168.100.0/24 orlonger;
}
then {
damping do-not-damp;
accept;
}
}
term damp-all-others {
then damping aggressive-damp;
}
}

UCatiohSerVIGes. : . ww.juruper nef-|

. 11-22-

Example of Damping Use: Part 4

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-througrh 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.

Chapter 11-22 . BGP Route Damping www.Juniper.net

 Advanced Junos Service Provider Routing

Viewing I' Irawn Routes

show route damping history displays

withdrawn routes having a figure of merit:
user@router> show route damping history extensive
inet.O: 15 destinations, 15 routes (14 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

200.200.200.0/24 (1 entry, 0 announced)

BGP Preference: /-101
Kexthop: 172.16.10.1 via fe-0/0/0.0, selected
j State":<Hiaden j!;xt> |
Local AS: 2 Peer AS: 1

AS path: 1 I
Localpref: 100
Router ID: 192 . 168.1. 1

Merit (last update/now): 2777/2454

Default damping parameters used
Last update: 00 : 02:45
First update: 00:04:35
Flaps: 3
History entry. Expires in: 00:54:20

Worldwide EttucatitmServices wwHjunipeuBi | n-is

Damping History
The slide shows the outputfrom 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:
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 Meri t: 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.

www.juniper.net BGP Route Damping . Chapter 11-23

Advanced Junes Service Provider Routing

Decav 1 oute

show route damping decayed displays active

routes having a figure of merit:
user@router> show route damping decayed extensive
inet.O: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

200.200.200.0/24 (1 entry, 1 announced)

*
BGP Preference: 170/-101
Mexthop: 172.16.10.1 via fe-0/0/0.0, selected
State: <Active Ext>
Local AS: 2 Peer AS: 1
AS path: 1 I
Localpref: 100
Router ID: 192.168.1.1
Merit (last update/now) : 2000/1954
Default damping parameters used
Last update: 00:00:35
First update: 00:00:40
Flaps: 2

Routes with Non-0 Figures of Merit

The siide 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 afield (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: 2 000/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.

Chapter 11-24 . BGP Route Damping www.juniper.net

 Advanced Junes Service Provider Routing

Viewing Suppressed Routes

show route damping suppressed displays

routes that were damped due to the figure of merit
clear bgp damping
.
Suppressed routes can have the figure of merit reduced to 0
.
All routes (as well as individual routes) can be cleared

user@router> show route damping suppressed

inet.O: 15 destinations, 15 routes (14 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

200.200.200.0/24 [BGP] 00:01:21, localpref 100

AS path: 1 I
> to 172.16.10.1 via fe-0/0/0.0

user@router> clear bgp damping

inet.O: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

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 BGP Route Damping . Chapter 11-25

Advanced Junos Service Provider Routing

In this chapter, we:

.
Explained the causes for route instability
.
Described the effect of damping on BGP routing
.
Explained the default behavior of damping on links
.
Controlled damping using the routing policy framework
.
Viewed damped routes using CLI commands

This Chapter Discussed:

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.

Chapter 11-26 . BGP Route Damping www.Juniper.net

 Advanced Junos Service Provider Routing

Ri $view Questions

1 . Why is damping ignored on IBGP routes?

2 . What is the half-life as this term applies to route
damping?
3 . What is the function of the max-suppress
parameter?
4 . What happens if the suppress threshold is set
higher than the merit ceiling?
5 .
What kind of routes are shown with the show
route damping decayed command?

Review Questions
i.

2.

3.

4 .

www.juniper.net BGP Route Damping . Chapter 11-27

Advanced Junos Service Provider Routing

Configure and monitor route damping.

WoHciwide Education Services

Lab 10: BGP Route Damping

The slide provides the objective for this lab.

Chapter 11-28 . BGP Route Damping www.juniper.net

juniperNETWORKS

Advanced Junos Service Provider

Routing

Chapter 12: Route Reflection and Confederations

Advanced Junos Service Provider Routing

After successfully completing this chapter, you will be

able to;
.
Describe the operation of BGP route reflection
.
Configure a route reflector
.
Describe the operation of a BGP confederation
*
Configure confederations
.
Describe peering relationships in a confederation

rlrlwicle [ cliicjtion Servii es

This Chapter Discusses:

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 12-2 . Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

mimic
and

> Route Reflection Operation

Configuration and Routing Knowledge
BGP Confederations

Route Reflection Operation

The slide lists the topics we cover In this chapter. We discuss the highlighted topic first.

www.juniper.net Route Reflection and Confederations . Chapter 12-3

Advanced Junes Service Provider Routing

IBGP full-mesh peer requirement has an n2 problem

.
Addition of a new router requires new peering with all
current IBGP speakers
.
Current IBGP speakers must update their configurations
18 Two primary scaling mechanisms:
.
Route reflection (RFC 4456)
.
Confederations (RFC 3065)

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.

Chapter 12-4 . Route Reflection and Confederations www.juniper.net

 Advanced Junes Service Provider Routing

Route Reflectlosi Concepts

Allows an IBGP speaker to re-advertise an

IBGP-learned route to another IBGP speaker
Route reflector only re-advertises the active route to
clients

Route reflector does not, by default, change existing

IBGP attributes

Two new BGP attributes to prevent loops:

. Cluster list
. Containsone or more cluster ID values

.
Originator ID

WorldwideEduGBthmSeivics! i«wiunip«r.Mt i 12-6

IBGP Peers Can Readvertlse Routes

BGP route reflection relaxes the restriction that an IBGP peer should not readvertlse 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 Acctive Route

RRs only readvertlse 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 RR-they 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.

Continued on the next page.

www.Juniper.net Route Reflection and Confederations . Chapter 12-5

Advanced Junes Service Provider Routing

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 reflector's cluster ID is added to ali 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.

Chapter 12-6 . Route Reflection and Confederations www.juniper.net

 Advanced Junes Service Provider Routing

tes Loops

Steps:
1 .
Client sends routes to RR
2 ,
RR sends routes to all clients in the cluster and all RRs
3 . Those RRs send the routes to all their peers forming a
loop

10.10.10,0/24

RR1 ri'R2
RRd

Clients \ 10.10.1C
10.10.10.0/24
Clients
'

ft Clients

New Cluster Attributes Prevent Loops

Without the new cluster attributes, a loop can be created:
1 .
Client sends routes to RRi;

2 .
RRI sends routes to all clients and to RR2 and RRS;

3 . Because route reflection allows IBGP peers to send routes to other IBGP peers, RR2
sends the routes to RRS; and

4 .
Because RRS has no way of knowing the routes received from RR2 came from RRI,
RRS sends them to RRI, forming a loop.

www.juniper.net Route Reflection and Confederations . Chapter 12-7

Advanced Junos Service Provider Routing

"

,
- ;fi@ tl©h - ~

Cluster list:
.
Operates like an AS path, used by RR for loop prevention
.
Also used in the route selection algorithm
.
Contains a sequence of cluster IDs
.
Cluster ID represents each RR cluster in the network
.
RR drops routes that have already transited the cluster
. Added to the cluster list when a RR touches a route

Originator ID:
.
Identifies the first router to inject a route in an RR network

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 router ID
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.

Chapter 12-8 . Route Reflection and Confederations www.juniper.net

 Advanced Junes Service Provider Routing

Route Reflection and Confedera ,

Route Reflection Operation

Configuration and Routing Knowledge
BGP Confederations

Configuration and Routing Knowledge

The slide highlights the topic we discuss next.

www.juniper.net Route Reflection and Confederations . Chapter 12-9

Advanced Junos Service Provider Routing

oute Clew f mm

Route reflector clients are configured in a separate

peer group
Each peer group uses the cluster keyword
.
Cluster ID uses unique 32-bit number
. Often the router ID of the RR is used
[edit protocols bgp]
group int-peers {
type internal;
local-address 172.16.1.1;
Icluster 172.16.1.1; I
'
neignbor rTTTTETTTT;
neighbor 172.16.3.3;
neighbor 172.16.4.4;

Clients only peer to their route reflectors

[edit protocols bgp]
group int-peers {
type internal;
local-address 172.16.2.2;
neighbor 172.16.1.1;

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 client s 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.

Continued on the next page.

Chapter 12-10 . Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

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 Route Reflection and Confederations . Chapter 12-11

Advanced Junes Service Provider Routing

Client > RR > Clients and Nonclients

Nonclient > RR > Clients Only

.
.
.
Client Client ..'* Client

RR

© .
.
.
t
Client X :
Client

IBGP Full Mesh

® Between Route
Reflectors
Client
Client i RR
I

RR
Client Client

Client Client
'
Client

Worldwide Education Services

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.

Chapter 12-12 - Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

on

Steps:
1 . Client sends routes to all peers (route reflector)
2 Route reflector sends routes to all clients in the cluster and
.

all peers
3 . Route reflector sends routes from peers to all clients in the
cluster

10.10.10.0/24

10.10.10.0/24

RR

Clients
Clients

C lents

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 cluster's
route reflector.

The slide details how the 10.10.10.0/24 route is readvertlsed to ail other clients in the cluster as well
as to ail 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 Route Reflection and Confederations . Chapter 12-13

Advanced Junes Service Provider Routing

[edit protocols bgp]

user@RRl# show Client > RR > Clients and Nonclients
group int-peers {
type internal; Nonclient > RR > Clients Only
local-address 172.16.1.1;
cluster 172. 16. 1. 1;
RR1 RR2

neighbor 172.16.2.2;
neighbor 172.16.3.3;
)
'

.
-
.
4 k
[edit protocols bgp]
user9RR2# show
group int-peers { *

>
*

type internal;
local-address 172.16.1.2;
cluster 172. 16. 1.2; .
c

neighbor 172.16.2.2;
neighbor 172.IS.3.3;
>

[edit protocols bgp]

user@client1# show
group int-peers {
type internal;
local-address 172.16.2.2;
Clientl Cljent2 Clients
neighbor 172.16.1. 1;
neighbor 172.16.1.2;
1

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-leamed 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.

Chapter 12-14 . Route Reflection and Confederations www.juniper.net

 Advanced Junes Service Provider Routing

mmm Mm. mm mmmm

Ciient > RR > Ciients and Nonciients

Nonciient > RR > Ciients Onij

m Ciient and RR Ciient and RR Ciientand RR

Ciient Ciient Ciient Ciient Client Client Client Client Client

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 Route Reflection and Confederations . Chapter 12-15

Advanced Junes Service Provider Routing

4 ent me

Clients can also peer with other members of the RR

cluster
.
To stop unnecessary advertisements, configure the RR with
the no-client-reflect command

[edit protocols bgp]

user@rr-client-l# show
group int-peers { [edit protocols bgp]
type internal; user@route-reflector# show
local-address 172.16.2.2;
group int-peers {
neighbor 172.16.1.1; type internal;
neighbor 172.16.3.3; local-address 172.16.1.1;
} cluster 172.16.1.1;
no-client-reflect;
[edit protocols bgp] neighbor 172.16.2.2;
usGr@rr~client-2# show
neighbor 172.16.3.3;
group int-peers { }
type internal;
local-address 172.16.3.3;
neighbor 172.16.1.1;
neighbor 172.16.2.2;
}

4 :

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 reflectoronlyforwards to the clients
routes which arrive from outside of the cluster.

Chapter 12-16 . Route Reflection and Confederations www.junlper.net

 Advanced Junos Service Provider Routing

RR
172.16.1.1

192.168.0.0/16 192.168.0.0/16
BNH = 172.16.2.2 NH = 172.16.1.1

Client '/1BGP\, Client

Sessions '
172.16.2.2 172.16.3.3

Route reflector can modify any BGP attribute using a

routing policy
Presence of RRs should not affect forwarding paths
.
Use of next-hop self can result in inefficient forwarding
paths
.
In this example, the RR Incorrectly overwrites the BGP next
hop for the 192.168.0.0/16 route
.
Packets are now forwarded through the reflector instead of directly
between the clients

Route Reflector Can Modify Attributes

The defauit operation of a route reflector is to not modify any BGP defauits. 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-ciient 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 cluster's 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.

i n the example on the slide, the 172.16.2.2 ci uster client advertises the 192.168.0.0/16 route to the
'
cluster s RR with the BGP next hop set to its router ID. Because of sloppy next-hop-seif policy on the
RR, the BGP next hop Is overwritten with the router ID of the RR-172.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.

Continued on the next page.

www.juniper.net Route Reflection and Confederations . Chapter 12-17

Advanced Junes Service Provider Routing

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;
}
}

Chapter 12-18 ° Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

oute eflection Cor )rat tmm

"
Route Reflection Operation
Configuration and Routing Knowledge
-

>BGP Confederations

BGP Confederations

The slide highlights the topic we discuss next.

www.juniper.net Route Reflection and Confederations . Chapter 12-19

Advanced Junos Service Provider Routing

Breaks a global AS into multiple pieces (sub-AS)

Within each sub-AS:
.
Use private AS numbers
.
An IBGP full-mesh topology is still required
Between each sub-AS:
.
EBGP-type configurations are required
(multihop, and so forth)
.
Only the AS path attribute is changed
.
Prevents loops in the network
.
Sub-AS networksare not used when comparing AS path lengths
.
Other BGP attributes are not modified by default
.
Next hop. local preference, and MED are all unaffected

Vvurtdwkk Education Survioes

Break Up the Global AS

A confederation takes a giobal 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.
Continued on the next page.

Chapter 12-20 . Route Reflection and Confederations www.juniper.net

 Advanced Junes Service Provider Routing
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 themultihop command.

www.juniper.net Route Reflection and Confederations . Chapter 12-21

Advanced Junes Service Provider Routing

Path me

AS confederation sequence:
.
Each sub-AS is added to the AS path attribute
.
(65000 65001 65002) 100 200 shows a sequence
.
Used for loop prevention only
.
Sequence values are not counted as AS hops

AS confederation set is used when an aggregated

route loses the granularity of the sequence:
.
192.168.24.0/24(65000 65001) 100
.
192.168.100.0/24(65000 65002) 100
.
192.168.0.0/16 ( {65000 65001 65002}) 100

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.

Chapter 12-22 . Route Reflection and Confederations www.juniper.net

 Advanced Junes Service Provider Routing

Confederation Con ' ration

The global AS appears as a whole network when

viewed externally by peer networks
All routers remove all confederation information at the

edge of the global AS

.
Other AS peers do not see the details of the confederation
.
No need for remove-private

[edit routing-options]
u3er@router# show
autonomous-system 650 0 0;
confederation 201 members [ 65000 65001 65002 65003 65004 ];

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 ail 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 Route Reflection and Confederations . Chapter 12-23

Advanced Junos Service Provider Routing

Cor
< -
Rl
.

CBGP
RR \
/ RR
= AS 65003
,
!AS 65000 . AS 201 .

i
CBGP

AS 65002 \ \ s
/

CBGP I v.
.
CBGP

'AS 65001 .»
AS 65004 .

v
CBGP

:© 3
UBGP

Ifi

Confederation Peering
The slide shows an example of a BGP confederation network. The global AS of 201 is split up into five
sub-AS networks-65000, 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.

Chapter 12-24 . Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

[edit]
[edit]
user@AS65001-R3# show protocols bgp
user@AS65003-Rl# show protocols bgp
group sub-AS-65001 {
group sub-AS-65000 {
type internal;
local-address 192.168.1.3;
type external;
multihop;
neighbor 192.168.1.1;
local-address 192.168.3,1;
neighbor 192.168.1.2;
neighbor 192.168.1.4; peer-as 65000;
} neighbor 19 2.168.0.1;
group sub-AS-65000 { }
type external; group sub-AS-65003 {
multihop; type internal;
local-address 192.168.1.3; local-address 192.168.3.1;

peer-as 65000; cluster 192.168.3.1;

neighbor 192.168.0.3; neighbor 192.168.3.2;
} neighbor 192.168.3.3;
group sub-AS-65002 { neighbor 192.168.3.4;
type external;
multihop;
local-address 192.168.1.3;
peer-as 65002;
neighbor 19 2.168.2.4;

aHdwirieEteatUmServices v junipernet \ 12-25

Peering Session Configurations

The configuration exampie 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 IBGPfull 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 Route Reflection and Confederations . Chapter 12-25

Advanced Junos Service Provider Routing

summary

In this chapter, we:

.
Described the operation of BGP route reflection
» Learned how to configure a route reflector
.
Described the operation of a BGP confederation
.
Learned how to configure BGP confederations
9 Described peering relationships in a BGP confederation

This Chapter Discussed:

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.

Chapter 12-26 . Route Reflection and Confederations www.juniper.net

 Advanced Junos Service Provider Routing

Review Questions

i . Which two BGP attributes support route reflection?

2 . How is a cluster configured in the Junos OS?
3 . In a fully-meshed cluster, which command can you use to
stop excess advertisements?
4 .
What does a BGP route reflector do with BGP routes received
from clients and nonclients?
5 . How are loops prevented in a confederation network?
6 .
Which form of BGP is run between:
. Routerswithina sub-AS?
.
Routers across a confederation boundary?
.
Routers external to the confederation?

Review Questions

4 .

5 .

6.

www.Juniper.net Route Reflection and Confederations . Chapter 12-27

Advanced Junos Service Provider Routing

Configure and monitor route reflection.

Configure and monitor confederations.

JUniPSr WorldwideEducatioiiServiees

Lab 11: Scaling BGP

The slide shows the objectives for the lab.

Chapter 12-28 . Route Reflection and Confederations www.juniper.net

 Appendix A: Acronym List

ABR area border router

autonomous system
ASBR autonomous system boundary router
BGP
Border Gateway Protocol
BGP4 Border Gateway Protocol version 4
CBGP Confederation BGP
CLI command-line interface
CI-N|D Connectionless Network Protocol
CLNS Connectionless Network Service
tuP|e complete sequence number PDU
Dls designated intermediate system
DR
designated router
EGP
exterior gateway protocol
ES end system
GUI
graphical user interface
IANA
Internet Assigned Numbers Authority
IBGP internal BGP
IGP
interior gateway protocol
Intermediate System
ls s Intermediate System-to-lntermediate System
130 International Organization for Standardization
lsp
Internet service provider
JNCP
Juniper Networks Certification Program
l SA
-

link-state advertisement
L 305
-

link-state database
LSP link-state PDU
M0SPF
Multicast Open Shortest Path First
Nl-PID network layer protocol identifier
Nl-Rl network layer reachability information
NSSA
not-so-stubby area
PDU
protocol data unit
PSNP
partial sequence number PDU
RID router ID
routing protocol daemon
RR route reflector
SPF
shortest path first
T,-v
type/length/value
ToS
type of service
time-to-live

www.juniper.net Acronym List . Appendix A-l

Appendix A-2 . Acronym List www.juniper.net
 Appendix B: Answer Key

Chapter 1: Course Introduction

This chapter contains no review questions.

Chapter 2: OSPF
i.

LSA Type 9 supports graceful restart.

2.

The metric or cost of a router's 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

i .

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

i .

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. This could be due to cost or time constraints.
3 .

If the source route has a lower preference there usually are no issues. If a source route has a higher
preference, suboptimal routing or loops can occur.

Chapter 5: IS-IS
l .

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 B-l

 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

l .

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, as this could lead to inconsistencies in the LSDB. The default
export policy for IS-IS is to reject everything. IS-IS floods link-state PDUs 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

l .

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 not-so-stubby-area (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
l .

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 B-2 . Answer Key www.juniper.net

 3 .

With Junos OS, all new BGP routes have an origin code of Hnternal.
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 Policy-Part 1

i .

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 Hnternal.

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.

Chapter 10: BGP Attributes and Policy-Part 2

i .

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.

Chapter 11: BGP Route Damping

i .

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.

www.juniper.net Answer Key . Appendix B-3

Chapter 12: Route Reflection and Confederations
i.

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.

Appendix B-4 . Answer Key www.Juniper.net