JNCIE-SP 10.c SG PDF

JNCIE Service Provider Bootcamp
10.c
Student Guide
Worldwide Education Services
1133 Innovation Way

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Course Number: EDU-JUN-JNCIE-SP

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. the Juniper Networks Logo, Junos. NetScreen. and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and
other countries. All other trademarks, service marks, registered trademarks. or registered service marks are the property of their respective owners.
JNCIE Service Provider Bootcamp • .. • • • ·�- Revision .10.c
Copyright© 2013 Juniper Networks. Inc. All rights reserved.
Printed in USA.
Revision History:
Revision 10.a-September 2011
Revision 10.b-March 2012
Revision 10.c--August 2013
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.3. Juniper Networks assumes no
responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary.
incidental. or consequential damages resulting from any defect or omission in this document. even if advised of the possibility of such damages.
Juniper Networks reserves the right to change. modify, transfer. or otherwise revise this publication without notice.
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has
no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable. in an
agreement executed between you and Juniper Networks. or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and
agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper
Networks software. may contain prohibitions against certain uses. and may state conditions under which the license is automatically terminated. You should
consult the software license for further details.
Contents
Chapter 1: Course Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1
Chapter 2: Exam Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1

Prior to the Exam .............................................................. 2-3
Exam Day .................................................................... 2-7
After the Exam ...............................................................2-13
Chapter 3: Device Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

List of Device Infrastructure Exam Topics .......................................... 3-3
Device Infrastructure Implementation ............................................. 3-5
Sample Task Analysis .........................................................3-12
Lab 1: Implementing Device Infrastructure ........................................3-24
Chapter 4: IGP Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

List of IGP Implementation Exam Topics ..........•..•......•..•................... 4-3
IS-IS Implementation ........................................................... 4-5
OSPF Implementation .........................................................4-12
Lab 2 and Lab 3: IGP Implementation ............................................4-29
Chapter 5: IGP Troubleshooting ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

List of IGP Troubleshooting Exam Topics .......•................................... 5-3
IGP Troubleshooting ........................................................... 5-5
Sample Task Analysis ......................................................... 5-14
Lab 4 and Lab 5: IGP Troubleshooting............................................ 5-22
Chapter 6: BGP Implementation.....................................................6-1

BGP Configuration and Implementation ........................................... 6-3
BGP Routing Policy ...........................................................6-18
Lab 6: BGP Implementation ....................................................6-44
Chapter 7: BGP Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

BGP Troubleshooting with the Junos CU Tools ...................................... 7-3
Time-Saving Tips .............................................................7-20
Lab 7: BGP Troubleshooting ....................................................7-23
Chapter 8: Multicast Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1

PIM Sparse Mode Implementation ................................................ 8-3
MSDP Anycast-RP Implementation ..............................................8-14
Lab 8: Multicast Implementation ................................................8-33
www.juniper.net Contents • iii

Chapter 9: Class of Service Implementation .......................................... 9-1
List of Cos Exam Topics ........................................................ 9-3
cos Processing Refresher ...................................................... 9-6
Caveats, Tips, and Tricks for the Cos Section ....................................... 9-9
Lab 9: Class of Service Implementation and Troubleshooting .........................9-20
Chapter 10: MPLS Implementation .................................................. 10-1

MPLS Implementation .........................................................10-3
Sample Task Analysis ........................................................10-25
Lab 10: MPLS Implementation ...•.............................................10-33
Chapter 11: MPLS VPN Implementation .............................................. 11-1

Layer 3 MPLS VPNs ...........................................................11-3
lnterprovider and Carrie r -o f C
- arrier Layer 3 VPNs ..................................11-19
Layer 2 VPNs and VPLS .......................................................11-25
Sample Task Analysis ........................................................11-38
Lab 11: MPLS VPNs Implementation and Troubleshooting ..........................11-53
Appendix A: Junosphere ............................................................ A-1

Accessing the Junosphere Interface .............................................. A-3
Junosphere Libraries and Topologies ............................................A-10
Acronym List ................................................................... ACR-1
iv • Contents www.juniper.net
Course Overview
This five-day course is designed to serve as the ultimate preparation for the Juniper Networks
Certified Internet Expert-Service Provider (JNCIE-SP) exam. The course focuses on caveats and
tips useful for potential test candidates and emphasizes hands-on practice through a series of
timed lab simulations. On the final day of the course, students are given a six-hour lab simulation
emulating the testing topics and environment from the real exam. All labs in this course are
facilitated by Junosphere virtual lab devices and are available after hours for additional practice
time. This course is based on Junos OS Release 10.3.
Objectives
After successfully completing this course:
Students will be better prepared for success in taking the actual JNCIE-SP exam.
Students will be well-versed in exam topics, environment, and conditions.
Intended Audience
This course benefits individuals who have already honed their skills on service provider
technologies and could use some practice and tips in preparation for the JNCIE-SP exam.
Course Level
JNCIE Service Provider Bootcamp is an advanced-level course.
Prerequisites
Students should have passed the Junipe:, Networks Certified Internet Professional-Service
Provider (JNCIP-SP) written exam or achieved an equal level of expertise through Education
Services courseware and hands-on experience.
www.juniper.net Course Overview • v

Course Agenda
Day 1
Chapter 1: Course Introduction
Chapter 2: Exam Strategies
Chapter 3: Device Infrastructure
Lab 1: Implementing Device Infrastructure
Chapter 4: IGP Implementation
Lab 2 and Lab 3: IGP Implementation
Day2
Chapter 5: IGP Troubleshooting
Lab 4 and Lab 5: IGP Troubleshooting
Chapter 6: BGP Implementation
Lab 6: BGP Implementation
Chapter 7: BGP Troubleshooting
Lab 7: BGP Troubleshooting
Day3
Chapter 8: Multicast Implementation
Lab 8: Multicast Implementation and Troubleshooting and Troubleshooting
Chapter 9: Class of Service Implementation
Lab 9: Class of Service Implementation and Troubleshooting
Day4
Chapter 10: MPLS Implementation
Lab 10: MPLS Implementation and Troubleshooting and Troubleshooting
Chapter 11: MPLS VPN Implementation
Lab 11: MPLS VPNs Implementation and Troubleshooting
Day5
JNCIE-SP Full Lab Simulation
vi • Course Agenda www.juniper.net

Document Conventions
CU and GUI Text

Frequently throughout this course, we refer to text that appears in a command-line interface (CU)
or a graphical user interface (GUI).To make the language of these documents easier to read, we
distinguish GUI and CU 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
Fi1 ename 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.
Normal CLI No distinguishing variant. Physical interface:fxpO,

Enabled
Normal GUI
View configuration history by clicking
Configuration > History.
CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File > Save, and type
config. 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.
CLI Variable Text where variable value is already policy my-peers

assigned.
GUI Variable Click my-peers in the dialog.
CLL Undefined Text where the variable's value is Type set policy policy-name.
the user's discretion or text where
ping 10.0.�
the variable's value as shown in
GU.I 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.
www.juniper.net Document Conventions • vii

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:j/www.juniper.net;training/education/.
About This Publication

The JNCIE Service Provider Bootcamp Student Guide was developed and tested using the Junos
software Release 10.3. Previous and later versions of software might behave differently so you
should always consult the documentation and release notes for the version of code you are
running before reporting errors.
This document is written and maintained by the Juniper Networks Education Services development
team. Please send questions and suggestions for improvement to training@juniper.net.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats:
Go to http:j /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:j /www.juniper.net;customers/support/, or
at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the United States).
viii • Additional Information www.juniper.net

Jun,f�?.�.r
Chapter 1: Course Introduction

Chapter Objectives
• 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
---�;"'to;.,,.,�;,,,;
�UrillPefi
�
WorldwideEducallonServlces """".Jun,pernet I 1-2
-:';;&J �
This Chapter Discusses:

Objectives and course content information;
Additional Juniper Networks, Inc. courses; and
The Juniper Networks Certification Program.
Chapter 1-2 • Course Introduction www.juniper.net

Introductions
• Before we get started ...

•
v
• What is your name?
• Where do you work?
• What is your primary role in your
organization?
• What kind of network experience
do you have?
• When did you certify 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

Course Contents
• Contents:
• Chapter 1: Course Introduction
• Chapter 2: Exam Strategies
• Chapter 3: Device Infrastructure
• Chapter 4: IGP Implementation
• Chapter 5: IGP Troubleshooting
• Chapter 6: BGP Implementation
• Chapter 7: BGP Troubleshooting
• Chapter 8: Multicast Implementation
• Chapter 9: Class of Service Implementation
• Chapter 10: MPLS Implementation
• Chapter 11: MPLS VPN Implementation
..__ • Appendix A Junosphere �-- . ..
WorlJ:lwideEducatlonServices wwwJun,pernet 1
·�-·
1-4
Course Contents
The slide lists the topics we discuss in this course.

Pre equisites
• The prerequisite for this course is JNCIP-SP

certification, or an equal level of expertise through
Education Services courseware and hands-on
experience.
,is�"""""
WorldwideEducationSe111lces wwwJunipo,net 11-s
Pm ;,ju,.
Prerequisites
The slide lists the prerequisites for this course.

Course Administratio11
• The basics:
• Sign-in sheet
• Schedule
• Class times
• Breaks
• Lunch
• Break and restroom facilities
• Fire and safety procedures
• Communications
• Telepl1ones and wireless devices
• Internet access
General Course Administration

The slide documents general aspects of classroom administration.

Education Materials
• 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.ne-Vtraining/technical_education/
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

Additional Resources
• For those who want more:

• Juniper Networks Technical Assistance Center (JTAC)
• http:j/www.juniper.net;support/requesting-support. l1tml
• Juniper Networks books
• http:j/www.juniper.net/training/jnbooks/
• Hardware and software technical
documentation
• Online: http://www.juniper.net/techpubs/
• Image files for offline viewing:
http:j/www.juniper.net;techpubs/resources/cdrom.htm I
• Certification resources
• http:j/www.juniper.net;training/certification/resources.l1tml
Additional Resources
The slide provides links to additional resources available to assist you in the installation,
configuration, and operation of Juniper Networks products.

Satisfaction Feedback
(l'li,
f ,:,r.;,ll,'.i·'I
==
• 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-rnail it to you within two weeks
• Completed surveys help us serve you better!
l wor1JZicie'Education Services """ JUn1per net I 1·9

S:,$J'IZ"�
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 on line 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.

Juniper Networks Education Services

Curriculum
• Formats:
• Classroom-based instructor-led technical courses
• Online instructor-led technical courses
• Hardware installation elearning courses as well as technical
elearning courses
• Courses:
• http://www.juniper.neVtraining/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.
Courses
You can access the latest Education Services offerings covering a wide range of platforms at
http:/ /www.juniper.net/training/technical_education/.

Junos Certifications
Jun1Per
0
;y��!f-
1 ...
JUnlPer
t
(lllllf'!lO
,,«;,r��.o,,.,.,
Jun1Per
ct.>lllt1l0
',:,f"f!A\l�,1
Ct.lfl!>U)
...5.',,0(,,1,ff
Lll!Jr.lmi y •
WorldwideEducationServlces ww�Jun,pe,net 11-11
�.,.,," �« �¥
Juniper Networks Certification Program

A Juniper Networks certification is the benchmark of skills and competence on Juniper Networks
technologies. The available Junos certification tracks are shown on the slide.

Find Us Online
Jnet http//www.juniper.neVjnet
http//www.juniper.neVfacebook
m:;, http://www.juniper.neVyoutube
http//www.juniper.net/twitter
Find Us Online
The slide lists some on line resources to learn and share information about Juniper Networks.

Questions
Worfdwid!EducationServices ww�Jun,p .. not 1 1-13
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-13


Chapter 2: Exam Strategies

Chapter Objectives

able to:
• Prepare for the JNCIE-SP exam
• Describe the environment and testing procedure
• Describe the grading procedure
>- �� ·� lli'd'0"'"" "'

IDrl� W01)(lwideE�c:'�ionServices wwwJun,pornel I 2-2

Preparing for the Juniper Networks Certified Internet Expert (JNCIE) Service Provider
(SP) exam;
The testing center environment and procedure; and
The grading process.
Chapter 2-2 • Exam Strategies www.juniper.net

Agenda: Exam Strategies
7 Prior to the Exam

• Exam Day
• After the Exam
Prior to the Exam

The slide lists the topics we discuss in this chapter. We discuss the highlighted topic first.
www.juniper.net Exam Strategies • Chapter 2-3

Exam Preparation
• Know the topics and objectives

• http/ /www.juniper. net/us/en/training/certification/
resourcesjnciesp.html
• Practice!
• Take notes
• Time yourself
• Resources
• Technical documentation
• Education Services courseware
• On-the-job or hands-on experience
• SRX brancl, devices are not costly: use VRs
• Junosphere
Exam Topics
The JNCIE-SP exam is a challenging full-day, hands-on lab exam and the certification represents the
top experts in SP technologies. This chapter and the rest of this course is designed as a preparatory
tool leading up to the exam. To be successful in obtaining the certification, you must also have had
extensive hands-on practice either through your job role or lab experience and you must have
mastered the various technologies presented throughout the course. To begin your preparation, as
with any Juniper Networks exam, you should identify the exam topics and objectives.
The link on the slide contains the most recent version of exam topics. You can also find out more
information about the exam by visiting the Juniper Networks certification site at
www.juniper.net/certification. Use these topics and objectives as a tool and practice the topics
repeatedly in many variations. Take notes on topics which are difficult for you and time yourself in
repeated simulations. While this course will be very beneficial, you should not rely on it as your single
preparation method.
Exam Resources
Congratulations, by taking this course, you have a tremendous advantage in exam preparation. The
slide lists other vital resources such as technical publications. You should become familiar with the
organization of Juniper Networks technical publications available at www.juniper.net/techpubs
because it is the only resource available to you during the exam. However, hopefully you will not need
to use this resource on exam day because time is already a limited resource.
Continued on the next page.

Exam Resources (contd.)

Juniper Networks Education Services courseware maintains alignment with many of the
certifications including the JNCIE·SP and serves as another great resource for your preparation. You
can find out more about the recommended courseware at
www.juniper.net/training/certification/resources.html.
You will need more hands-on practice than this course provides. You can obtain this from on-the-job
experience and equipment. However, if you do not have access to equipment through your job role,
there are other methods for hands-on practice. Juniper Networks SRX Series branch devices are
relatively inexpensive and can perform most of the same functionality (needed for this exam) as the
larger MX Series devices. Using virtual routing instances (VRs) or logical systems, you can recreate a
large topology with just a couple devices. Juniper Networks also recently launched the cloud-based
Junosphere virtual lab platform. We will be utilizing Junosphere for this course and you can also
purchase Junosphere time as an individual at www.junosphere.net.

JNCIE-SP Sections
• Sections include:
• Device infrastructure
• IGPs
• BGP
• Layer 2 and Layer 3 VPNs
• Multicast
• Class of service
• MPLS
,;, . �l'Jnmv\Wo1l�deEducalionSe1Vices
�&:zy;x�,;,i;,
t:;(!l\."[,;i,,4:t,s,.,
=
wwwJun,pernei 1 2 s-
JNCIE-SP Sections
The slide lists the high-level exam sections covered in the JNCIE-SP exam. We will examine each of
these thoroughly on subsequent chapters. For more information, visit the previously mentioned
resources website.


• Prior to the Exarn
7Exam Day
• A.fter the Exam
Exam Day
The slide lists the topic we discuss next.
www.juniper.net Exam Strategies • Chapter 2- 7

Morning of the Exam
• Exam day
• Make sure you had a good night of rest
• Eat a light breakfast
• Dress comfortably
• Arrive to the testing center early
• Familiarize yourself with tl1e testing facility
• Review your notes
".
Good Morning
Exam day has arrived. Hopefully, you are well-rested and ready for a successful day. To avoid
distractions, you should dress comfortably and eat a light breakfast. Try to keep a typical morning
routine to prolong the onset of stress that is sure to come later.
It is a good idea to arrive at the testing center at least 30 minutes prior to the start of the exam. This
will give you ample time to meet the proctor, familiarize yourself with the facility, and review your
notes.

Exam Tools
• When starting your exam, you will be given:
• Access to terminal with SecureCRT
• Network topology map
• Tables describing network characteristics such as addresses
• List of tasks and associated point values
• Tasks are broken out into sections
• Read all tasks before starting the exam 1
• Access to technical documentation
• Blank sheets of paper and writing tools
• Mark up the topology
• Access to a proctor
• Use to your advantage!
Exam Tools
Your proctor will direct you to your workstation in a quiet, secured area where you will be given a
terminal with access to the certification topology. Most terminals are equipped with SecureCRT and
a local copy of the Juniper Networks technical publications. You will use SecureCRT or a native
terminal emulation client to access your devices' console ports through a terminal server. You can
also access the devices directly using an out-of-band management network.
The proctor will give you a packet containing your network topology, information tables, and a list of
tasks. The tasks will be organized into sections. Each section represents a specific number of points.
The tables will contain information necessary for you to complete your exam such as IP addressing
information. Take some time to read through the task list and review the provided topology. You
might choose to make notes where appropriate or even draw on the topology for your own
clarification. Usually, a writing utensil and spare paper are provided for this purpose.
Once the proctor directs you to begin and notes the official starting time, the proctor will leave the
testing pod but will remain nearby for assistance. Do not be ashamed or embarrassed to approach
the proctor with questions. While proctors cannot give away details of the exam, they can often clarify
items of which you are unsure. One helpful tip to use when asking the proctor for clarification on a
lab task is to not ask the proctor to explain the task, but rather, form your own idea about what the
task entails and ask the proctor if your understanding is correct. Also, you could present the question
in a this-or-that format when appropriate.
It is also important to get the proctor involved quickly if you suspect a hardware problem in your
topology. Hardware issues are not expected and you will be credited for any lost time (within reason).

Exam Infrastructure
• Lab infrastructure consists of:

• 8 MX Series devices (not including connected peer. transit
providers or customer devices)
• Junos OS Release 10.4R3.4
• Various network terminals and servers
Customer?
�
�
??? --
;;;;
Junos· 10.4R3.4
;;;;
;;;; ???
The Lab Topology

Your network, or the devices under your administrative control, will consist of at least eight MX Series
interconnected devices with various external connections to customer devices, peer devices, and
transit provider networks. Some servers or workstations might also be present to emulate multicast
traffic, syslog servers, and so forth. The devices in your administrative control will use Junos OS
Release 10.4R3.4.

Time ..saving Tips
• Eight-hour exam (not including one-hour lunch)

• Keep track of time: take breaks
• Try to allow 1 to 2 hours for verification and troubleshooting
after completing all tasks
• Time-savers
• Cut and paste identical configuration pieces
• Know your keyboard and CLI shortcuts
• Strategic attack
• Pay attention to each sections· point value
• Apply multiple tasks to a device when appropriate
• Skip verification if short on time
Making the Most of Eight Hours

It is a good idea to wear a wristwatch on the day of the exam, if allowed. Keep track of your timing.
You must have a majority of the exam finished by lunch if you plan to allow for extra troubleshooting
and verification.
Time-Saving Tips
Pay attention to configuration snippets which can be shared among devices. These provide a good
opportunity to cut and paste configuration stanzas into multiple devices. It is a good idea to
understand the various load commands and pipe ( [) functionality for command outputs. You
should also learn and take advantage of keyboard shortcuts such as the various Ctrl commands
provided by the Junos OS. You can learn more about these time-savers in the Juniper Networks
technical publications.
One reason for reading through the entire task list before beginning the exam is to strategically plan
your implementation. For example, if you know you are going to enable multiple policy functions from
a device to a peer, it may make sense to implement these at the same time. Note that you should
always attempt at least one task from each section, because completely ignoring an entire section
may result in a failure of the exam.
Although you would prefer time to verify that every nuance of your network is in working order, every
second counts on the JNCIE-SP exam. So if you are running short on time, you might need to skip
some verification steps. You can mark them and revisit the tasks for verification later, if time allows.

f You Have Trouble
• Troubleshooting issues
• Troubleshoot by outputs before inspecting configuration
• Verify that the issue is not hardware related
• Alert the proctor sooner rather than later if a hardware issue is
suspected
• Move on and revisit the issue later when possible
•As a last resort, break the exam rules
• Adding tt,at disallowed static route might help prevent the domino
effect
Troubleshooting Tips
As mentioned previously, time is of the essence during the exam. If you encounter an issue, try to
verify the obvious outputs quickly using show commands. This approach preferred over attempting
to review a configuration which might be rather large.
If at any time you suspect a hardware fault, notify the proctor immediately. You will be credited for
lost time caused by the hardware fault (within reason). However, it is unlikely that you can, for
example, claim two hours lost to a faulty interface card.
Many implementation tasks early in the exam are crucial elements for success in tasks later in the
exam. For example, a link failure in the infrastructure section of the exam will affect IGP adjacencies
and possibly, BGP and MPLS functionality. As a last resort, it might make sense to break an exam
rule that will result in lost points for one task in lieu of losing exam points for multiple tasks.

• Prior to the Exam

• Exam Day
�After the Exam
�ur.ir,.e,fr Wii_rl�wfdeEducationServices
""'- WW.,JUnrpmet I 2-13
After the Exam


Grading
• You will be given a pass or fail report within

15 business days of the exam
• 73% of points needed to pass exam
• Can vary for otl,er exams as determined by statistical analysis
• Failure notifications will contain areas of needed
improvement
Exam Results
The certification team will notify you of your results within 15 business days. For the JNCIE-SP exam,
you must successfully complete enough tasks to be awarded 73% of the available points. The results
come in a basic pass or fail format. However, if the exam was not successful, you will be directed on
areas in need of improvement.

Now What?
• I passed!! ./
• Keep current by recertifying the JNCIP-SP between
18 months and 24 months from pass date
•Show off your accomplishments
• Plaque. logo. resume
• Consider other certification tracks
• Security. enterprise routing. and switching
• I did not pass X
•Schedule your retake
• Must wait 14 calendar days
• Pay close attention to sections in which you had difficulty
�r.
uur.i1Pe WorfdwideEducationServices
"�
WW�Jun,pmet I 2-15
Congratulations Are in Order!

If you pass the JNCIE-SP exam. you are now a JNCIE! Congratulations. but be sure to remain studious
and keep your skills sharpened. You can recertify by successfully passing the Juniper Networks
Certified Internet Professional (JNCIP) SP written exam. You are eligible to recertify in 18 months and
must certify prior to the two-year mark to remain an active JNCIE. If your certification status becomes
inactive, you will have one year to re-activate the certification by passing the JNCIP-SP exam.
However, if you remain inactive for more than one year, your certification will expire. In that case. you
will need to recertify by passing the JNCIE-SP lab exam again. Obviously, it is to your advantage to
recertify as soon as possible.
As a JNCIE, you will be awarded a plaque and a certification number. You will also be entitled to other
items. such as use of the official JNCIE logo.
Keep Trying
If your exam outcome is not successful, you can retake the exam in as little as 14 calendar days. We
recommend you schedule a retake sooner rather than later. The experience of taking the exam the
first time will be more beneficial while it is still fresh in your mind. The exam will also change over
time and different versions of the Junos OS or exam topics will make preparation more difficult. So
now is the time to study and practice. Be sure to spend some extra time on topics listed as areas in
need of improvement.

JNCIE Service Provider Boo tcamp
Summary
• In this chapter, we:
• Reviewed preparatory strategies for the JNCIE-SP exam
• Described the environment and testing procedure
• Described the grading procedure
This Chapter Discussed:

Preparing for the Juniper Networks Certified Internet Expert (JNCIE) Service Provider
(SP) exam;
The testing center environment and procedure; and
The grading process.

Jun112t�,r
Chapter 3: Device Infrastructure

Chapter Objectives

able to:
• Identify device infrastructure subjects for the J NCIE-SP exam
• Explain possible pitfalls of configuring aggregated Ethernet
interfaces
• Explain considerations of configuring VRRP
• Describe considerations of configuring user accounts
• Explain the implementation and troubleshooting of firewall
filters
• Describe the configuration of a router to use commit scripts

Device Infrastructure subjects covered in the JNCIE-SP exam;
The possible challenges of configuring aggregated Ethernet interfaces;
The considerations of configuring VRRP;
The considerations of configuring user accounts;
The implementation and troubleshooting of firewall filters; and
The configuration of a router to use commit scripts.
Chapter 3-2 • Device Infrastructure www.juniper.net

Agenda: Device Infrastructure
7 List of Device Infrastructure Exam Topics

• Device Infrastructure Implementation
• Sample Task Analysis
" -= �'(;; fr==

ijt!Jfll!=lefl Worldwide EducationSe111ices WWW Juniper net I 3-3
� t "s\u:mra;��
List of Device Infrastructure Exam Topics

The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
www.juniper.net Device Infrastructure • Chapter 3-3

Device Infrastructure Topics for the

JNCIE·SP Exam
• High availability features of the Junos OS

• Be familiar with graceful restart. GRES, NSR, and VRRP
• Aggregated Ethernet interfaces
• Understand how LACP and the minimum-links command
function
• Securing and monitoring Junos devices
• Be familiar with firewall filters, syslogging, and user
accounts
• Basic automation implementation and monitoring
• Understand how to configure the router to use scripts
.,....,.,.,.,. .,.,.,._ ", y-0%

JJUOIPefi. Worldwide Education Services _., Juniper net I 3,4
� ti"� -
Device Infrastructure Topics for the JNCIE-SP Exam

A JNCIE-SP candidate is expected to be familiar with the concepts that the Junos operating system
uses to employe high availability features. Know how to configure graceful restart, graceful routing
engine switchover (GRES), non-stop routing (NSR), and virtual redundancy routing protocol (VRRP).
You should also be familiar with how to configure and monitor aggregated Ethernet interfaces. Be
aware of how to use link aggregation control protocol (LACP) and the minimum-links command.
It is important to know how to implement firewall filters, syslogging, and user accounts. Be familiar
with each of these topics.
You will not need to configure any scripts, but you should know how to configure the router to use
scripts. For example, you might be asked to configure a router to retrieve a commit script which is
located on a remote server.

List of Device Infrastructure Exam Topics

II
� Device Infrastructure Implementation

Sample Task Analysis
III
···-
"'�;;,c,_,�f' ,,
\,\'o1dwideEducationServices
..
wwwJunoperne1 1 3-5
Device Infrastructure Implementation


Aggregated Ethernet Considerations
• When configuring aggregated Ethernet interfaces

• Aggregated device count
• Must be greater than tl1e largest configured Aggregate Ethernet
interface number
• LACP
• Active or passive mode
•minimum-links statement
• Must be set on both sides
• Defaults to a value of 1
• Always test Layer 3 connectivity
• LACP migl1t show Layer 2 connectivity but this does not guarantee
Layer 3 functionality
Challenges to Consider with Aggregated Ethernet Interfaces

The first step of configuring aggregated Ethernet interfaces is to define the number of aggregated
devices under the (edit chassis J hierarchy level. This process is straightforward if you must
configure interfaces aeO, ae1, and ae2 on the router. However, if you must configure only interface
ae2 on the local router, the answer is not as simple to ascertain. Although only one aggregated
Ethernet interface now exists, you must set the aggregated device count to 3. This setting enables
the router to create interfaces aeO, ae1, and ae2. Setting the aggregated device count to 1 results in
the creation of interface aeO-interface ae3 is not created.
When adding LACP to an aggregated Ethernet bundle, you must configure at least one side to initiate
the process, which is known as active mode. You can configure both sides to function in active
mode, but you cannot configure both sides to function in passive mode. Be aware that LACP
monitors the bundle to ensure the correct member interfaces are within the correct bundles.
The minimum-links statement monitors the member links in the bundle and takes the entire
bundle down if the operational member links fall below the configured threshold. You must configure
this statement on both ends of the bundle, failure to do so might result in a member interface failure
scenario in which one router considers the bundle to be nonoperational and the other router
considers the bundle to be operational.
When configuring aggregated Ethernet interfaces always test Layer 3 connectivity. If you
inadvertently configure the interface with a duplicate IP address, the Junos OS will not warn you and
the commit will succeed.

VRRP Considerations
• When configuring VRRP

• VRRP default behaviors
• Higher priority member always preempts
• Vi rtua11P address does not respond to requests
• Interface tracking values must not be greater than the
current priority value
• The virtual IP address must be within the same subnet of
the interface address in which it resides
,., .. ,. >-;
LJUri'I�, �,!!dW�d�EducationServices wwwiun1p,rnet 1 3.7
Challenges to Consider with VRRP Configuration

Remembering the defaults of VRRP can save you considerable time and effort. If a task asks you to
ensure preemption occurs, or if a task asks you to ensure the virtual IP address does not respond to
ping requests, then you do not have to configure anything to accomplish that criterion. However, it
does not result in a loss of points to configure a value that is already in place as a default value.
When configuring interface tracking values, keep in mind that the overall values must be less than
the current VRRP priority value. Failing to do so only results in a commit check failure, but valuable
time is lost fixing a problem that you can avoid in the first place.
As with configuring improper interface tracking values, improperly configuring the virtual IP address
results in a commit check error. Ensure that the virtual IP address is in the same subnet as the
interface that it resides in.
www.juniper.net Device Infrastructure • Chapter 3- 7

Configuring User Accounts
• When configuring user accounts

• User templates
• If the RADIUS server is unreachable. configure a local user with the
user template for the user class to test the template
• Regular expressions
• Use to specify which commands to allow or deny
•authentication-order
• [ radius password] verausradius
• Useful commands
•show cli authorization
•load merge terminal relative
".
Considerations When Configuring User Accounts

If a RADIUS server in the exam is not reachable, configure a local user with the class of the recently
configured user template. This configuration allows you to test the user template and ensures that
the correct permissions and authorization is given to users using the template. However, if you
employ this method of testing, remember to set the local user's class back to what it was before.
Failing to do so on the exam results in point loss.
Use regular expressions if an exam task asks you to allow or deny specific commands. This allows
you to specify exactly which commands you want the user to be able, or unable, to issue. Also, if you
are skilled in using regular expressions, it is possible to allow or deny a list of commands with very
little typing.
Understand when the router allows local users to log in to the router. Specifying the
authentication-order radius command, under the [edit system] hierarchy level, only
allows local authentication if the RADIUS server is unreachable, whereas the
authentication-order [ radius password ] command allows users to authenticate
locally with the router, even if the RADIUS server is reachable.
The show cli authorization command displays which permissions the user has and which
commands they can issue. Remember the usefulness of the load merge terminal relative
command. It saves time to configure one router with all the necessary user account information, and
then copy it to the rest of the routers in the topology.

irewall Filter Considerations
• When configuring firewall filters

•Break down the list of tasks
• Individual smaller tasks are easier to handle
• Use of syslog versus log
• Use the log statement to troubleshoot and verify
• prefix-list and apply-path can be used to help
simplify tasks
• Use port names instead of port numbers
• port ssh instead of port 22
• Control plane protection
• Apply firewall filter to the loopback interface
• Implicit deny statement
Ut.:Jnm
tc""<'il"T
W�!!,�ideEducationSe111ices WWWJUnop .. net I 3·9
"t � »
Considerations When Configuring Firewall Filters

Firewall filter tasks might seem daunting at first, but if you break it down into its individual parts. the
task is easier to handle. Each part of the task typically requires you to configure a term that matches
on certain criteria and then performs an action on traffic that matches the term.
Know the difference between the syslog and log statements that the action part of the term
uses. The syslog statement stores information on the traffic that matches the term in a syslog file.
When you store this information locally it is contained in non-volatile memory, if you reboot the router
then the information survives. The log statement stores information on the traffic that matches the
term in volatile memory, if you reboot the router the information is lost.
The log statement can be a very powerful troubleshooting and verification tool. Apply this statement
to firewall filter terms that do not appear to be working correctly. Then you can issue the show
firewall log command to view what traffic is actually matching this term. If you do not see the
traffic that you expect, you can apply the log statement to the last term that accepts or denies all
other traffic. This method can provide insight on which term is processing the traffic, then you can
adjust your firewall filter accordingly.
Using the apply-path statement within a prefix-list can assist in saving time. For example, a
router is configured with hundreds of BGP neighbors that change frequently. Configuring a firewall
filter term that statically lists each BGP neighbor does not scale well. Alternatively, you can configure
a prefix-list with the apply-path statement that dynamically lists each BGP neighbor in the
filter's term.

Considerations When Configuring Firewall Filters (contd.)

Using port names instead of port numbers can save you time and also increases the readability of
your firewall filter. This tactic can come in handy later when you are reviewing your firewall filter to
ensure accuracy, or to troubleshoot an issue with the filter.
When attempting to secure the control plane, always apply the firewall filter to the loopback
interface. This ensures that any traffic traveling to the RE passes through the filter first. It is possible
to attempt to secure the control plane through applying firewall filters to transit interfaces. However,
this method does not scale well and likely will result in lost time and points in the real exam.
Do not forget about the implicit deny statement at the end of every firewall filter in the Junos
OS. This can cause you to lose time attempting to figure out why all other traffic is being lost after you
apply the filter. It might seem like a time saving method not to configure a deny-all term at the end of
a firewall filter, but we recommend that you configure one. Configuring a deny-all term at the end of
the filter allows you to see the deny-all term and it is helpful for troubleshooting purposes. Adding the
log statement to the deny-all term can be very helpful in determining what is happening to traffic
that is not matching a previous term.

Commit Script Considerations
• When configuring commit scripts

• Specify script name
• file script-name
• Script name must also be specified in the source statement
• Remote script retrieval
• HTTP. FTP. or SCP can be used
• Syntax: source
"protocol://username@host:/location/script-name v
•refresh command
• Globally for all commit scripts. or on a per commit script basis
• Configuration mode command t11at acts like an operational mode
command
• Must be performed before a commit is issued
uufilm�-�--
Vi{orldWideEducationServices WW"1JUnrp .. net I J.11
Considerations When Applying Commit Scripts

When applying a commit script to the configuration, you must either manually add the script to the
/var I dbl scripts I comrni t/ or configure the router the retrieve the script from a remote server.
When retrieving the script from a remote server, you must define the script name after the file
command, then issue the source command with the URL of the file location. Remember when
referencing the location of the script, you must also list the script name. Forgetting to do so results in
a failure to retrieve the script.
If you are retrieving the script from a remote server you must issue the refresh command before
committing the configuration. Failure to do so results in a commit check error. The refresh
command is a configuration mode command that acts like an operational mode command.


• List of Device Infrastructure Exam Topics
• Device Infrastructure Implementation
�Sample Task Analysis


Task and Topology
• Task
• High availability is required for the Cirouter connected to
Ri and R2. Configure a VRRP group in which Riis the
master for the 10.30.40.0/24 range. R2 must acquire
mastership if two out of three of R1's internal interfaces fail.
The virtual IP address of 10.30.40.100, that belongs to the
VRRP group, must not respond to any ping requests.
Sample Task and Topology

The slide displays the sample task and topology. We analyze this task in the next set of slides.

What Now?
• What are the required components?

• VRRP must be configured on R1 and R2
• VRRP group number is not specified-it is up to you to cl1oose one
• Interfaces involved are ge-0/0/4 for R1 and ge-0/0/9 for R2
• Address range to work v,;ith is 10.30.40.0/24
• Virtual IP address is 10.30.40.100
• R1 is the master and R2 is the backup
• Interface tracking on R1· s three internal interfaces is required
• lf two of R1. s internal interfaces go down. the interface tracking
values must reduce R1· s priority lower than R2· s priority
• The virtual IP address cannot respond to ping requests-the
accept-data statement must not be configured
� -�-H�., y .3cs--
,« �JUr;11Pefr. WorldwicleEducalionServices WW�Jon,pernef I 31

· 4
"'"' /i:': �� ·�- - � �
Deciphering What Is Really Being Asked

Through examining the sample task and topology, you can determine what the sample task is asking.
The items on the slide list what is required to complete the sample task.

Task Completion (1 of 3)
• Initial verification
• Verify interface state
lab@Rl> show interfaces terse ge-0/0/4
Interface Admin Link Proto Local Remote
ge-0/0/ 4 up up
ge-0/0/ 4.0 up up inet 10 .30.40.1/24
lab@R2> show interfaces ter!:e ge-0/0/9

Interface �.dmin Link Proto Local Remote
ge-0/0/9 up up
ge-0/0/9.0 up up inet 10 .30.40.2/24
LlUfil�t �rld�ide EducationSer11ices •,·w�Juniporn,t 1 3-15
Are the Routers Ready?

The slide shows that the interfaces that are involved in the VRRP group are up and operational.

ask Completion (2 of 3)
• VRRP configuration-R1
[edit intecfaces ge-0/0/4]
lab@Rl# show
unit O {
family inet {
address 10.30.40.1/24
vnp-gcoup 1 {
victual-addcess 10.30.40.100;
pciocity 149;
trnck {
intecface ge-0/0/1 {
pciocity-cost 25;
pciocity-cost 25;
pciocity-cost 25;
(,: I
Configuring R1
The slide shows the configuration of R1 that is necessary to complete this task. Notice how the
interface tracking priority values are set in such a way that the VRRP priority drops below 100 if two
out of three of the interfaces fail.

• VRRP configuration-R2
[edit interfaces ge-0/0/9]
l.ab@R2# show
unit O I
family inet {
address 10.30.40.2/24
v crp-group 1 I
virtual-address 10.30.40.100;
priocity 100;
Configuring R2
The slide shows the configuration of R2 that is necessary to complete this task. Notice how the VRRP
priority is set to 100. In the previous slide, R1's configuration drops its VRRP priority to 99 if two of its
three internal interfaces fail.

Task Verification (1 of 5)
• VRRP verification-R 1
lab@Rl# run show vrrp detail
Physical intecface: ge-0/ 0/4, Unit: 0, Addcess: 10.30.40.1/24
Index: 70, SNMP ifindex: 519, VRRP-Tcaps: disabled
Intecface state: up, Gcoup: 1, State: mastec, VRRP Mode: A ctive
Pciocity: 149, Advectisement intecval: 1, Authentication type: none
Delay thceshold: 100, Computed send cate: 0
Pceempt: yes, Accept-data mode: no, VIP count: 1, VIP: 10.30.40.100
Advectisement Timec: 0. 856s, Mastee coute c: 10. 30.40.1
Victual coutec uptime: 00:03:02, Mastec coutec uptime: 00:01:36
Victual Mac: OO:OO:Se:00:01:01
Tcacking: enabled
Cuccent pciocity: 149, Configuced pciocity: 149
Pciocity hold time: disabled
Intecface tcacking: enabled, Intecface count: 3
Intecface Int state Int speed In cucced pciocity cost
ge-0/0/1.0 up lg
ge-0/0/2.0 up lg
ge-0/0/3.0 up lg
Route tcacking: disabled
- . '�un1per; Worldwide Education Services WWW Jun,per net I 3 18

-
" �� ·�
The VRRP State of R1

This slide shows the current state of VRRP for R1. Notice the interface tracking portion and how each
interface is up and no priority cost has been incurred. Also, note the current priority and
Configured priority fields. The Current priority field will change if a tracked interface
fails.

• VRRP verification-R2
lab@R2# run show vrrp detail
Physical interface: ge-0/0/9, Unit : 0, Address: 10.30.40.2/24
Index: 70, SNMP ifindex: 531, VRRP-Traps: disabled
Interface state: up, Group: 1, State: backup, VRRP Mode: Active
Pr iority : 100, Advertisement interval: 1, Authentication type: none
Delay threshold: 100, Computed send rate: 0
Preempt: yes, Accept-data mode: no, VIP count: 1, VIP: 10.30.40.100
Dead timer: 3.547s, Master priority: 149, Master router: 10.30.40.1
Virtual router uptime: 00:05:02
Tracking: disabled
Ll�8m�w�rldwideEducationServices WO,,VJUOlpornet I 3-19
The VRRP State of R2

This slide shows the current state of VRRP for R2. Notice the State, Master priority, and the
Master router fields which will change in the event of a mastership failover.

ask Verification (3 of 5)
lab@Rl# up 1 set ge-0/0/1 disable

lab@Rl# up 1 set ge-0/0/2 disable

lab@Rl# commit
commit complete

Physical interface: ge-0/0/4, Unit: 0, Address: 10.30.40.1/24
Interface state: up, Group: 1, State: backup, VRRP Mode: Active
Tracking: enabled
Current priority: 99, Configured priority: 149
Priority hold time: disabled
Interface tracking: enabled, Interface count: 3
Interface Int state Int speed Incurred priority cost
ge-0/0/1.0 down O 25
ge-0/0/2 .0 down 25
ge-0/0/3.0 up lg
".
Testing VRRP Failover

By disabling two of the three internal interfaces of R1, a VRRP mastership failover occurs. The slide
shows that R1 is now the backup router and it also displays the incurred priority costs from the two
interfaces going down.

• VRRP verification-R2
lab@R2# run show vrrp detail
Physical intecface: ge-0/0/9, Unit: 0, Addcess: 10.30.40.2/24
Index: 70, SNMP ifindex: 531, VRRP-Tcaps: disabled
Intecface state: up, Gcoup: 1, State: master, VRRP Mode: Active
Pciocity: 100, Advectisement intecval: 1, Authentication type: none
Delay thceshold: 100, Computed send cate: 0
Pceempt: yes, Accept -data mode: no, VIP count: 1, VIP: 10.30.40.100
Advectisement Timer: 0.386s, Master router: 10.30.40.2
Virtual router uptime: 16: 26: 10, Mastec routec uptime: 16: 00:36
Virtual Mac: OO:OO:Se:00:01:01
Tracking: disabled
. �- ...
UU8!�*' �orldwide Education Services
;;:;=�� '
"'"'" ''"P" not 1 3-21
Verifying R2's New VRRP State

You can now see that R2 has acquired mastership for the VRRP group.

Task Verification (S of S)
lab@Rl# up 1 delete ge-0/0/1 disable

lab@Rl# up 1 delete ge-0/0/2 disable

lab@Rl# commit
commit complete

Physical interface: ge-0/0/4, unit: 0, Address: 172.20.20.3/24
Interface state: up, Group: 1, State: master, VRRP Mode: Active
Tracking: enabled
Current priority: 149, configured priority: 149
Priority hold time: disabled
Interface tracking: enabled, Interface count: 3
Interface Int state Int speed Incurred priority cost
ge-0/0/1.0 up lg
ge-0/0/2.0 up lg
ge-0/0/3.0 up lg
Restoring VRRP Mastership Back to R1

After testing the failover capabilities of the VRRP group remember to return it to its previous state.
Failure to do so on the exam might result in point loss.

Summary

• Identified Device Infrastructure subjects for the JNCIE-SP
exam
• Explained possible pitfalls of configuring aggregated
Ethernet interfaces.
• Explained considerations of configuring VRRP.
• Described considerations of configuring user accounts.
• Explained the implementation and troubleshooting of
firewall filters.
• Described the configuration of a router to use commit
scripts.
�1.:Jlillpe'f'i
u,.....,..z'.IM>rldwide Education Services www 1,,,p,. net 1 , 23

Device Infrastructure subjects covered in the JNCIE-SP exam;
The possible challenges of configuring aggregated Ethernet interfaces;
The considerations of configuring VRRP;
The considerations of configuring user accounts;
The Implementation and troubleshooting of firewall filters; and
The configuration of a router to use commit scripts.

• Configure and monitor aggregated Ethernet

interfaces.
• Configure and monitor graceful restart and VRRP.
• Configure and verify user accounts and syslogging.
• Configure, monitor, and verify control plane
protection.
• Apply and use commit scripts.
Note: This lab is a timed simulation. You will

have 1 hour to complete the lab.
0• ;Ufi11Pef';:Worldwide Education Services '""'" jun,pernel I 3-24

t�l �- .,

The slide provides the objectives for this lab.

Jun1f;> �,r
1
Chapter 4: IGP Implementation

Chapter Objectives

able to:
• Identify IGP Implementation subjects for the JNCIE-SP exam
• Explain how to configure and monitor IS-IS
• Explain IS-IS areas and levels
• Describe IS-IS and OSPF route summarization
• Explain IS-IS and OSPF metrics
• Describe IS-IS DIS considerations
• Explain how to configure and monitor OSPF
• Describe OSPF DR and BDR considerations

IGP Implementation subjects covered in the JNCIE-SP exam;
The configuration and monitoring of IS-IS;
IS-IS areas and levels;
IS-IS and OSPF route summarization;
IS-IS and OSPF metrics;
IS-IS DIS considerations;
The configuration and monitoring of OSPF; and
OSPF DR and BDR considerations.
Chapter 4-2 • IGP Implementation www.juniper.net

Agenda: IGP Implementation
�List of IGP Implementation Exam Topics

• IS-IS Implementation
• OSPF Implementation
--��rg.c-r it
ijUfillPet;::WondWideEducationServices wwwJuo,pernet 1 4-3
� �"' =4=' -�
List of IGP Implementation Exam Topics

www.juniper.net IGP Implementation • Chapter 4-3

IGP Implementation Topics for the

JNCIE-SP Exam
• IS-IS areas and adjacencies

• Understand how to configure IS-IS areas and adjacencies
• IS-IS route leaking, DIS, and other IS-IS options
• Understand how to configure IS-IS route leaking. understand
DIS considerations. and other IS-IS options
• OSPF areas and adjacencies
• Understand how to configure OSPF areas and adjacencies
• OSPF route summarization, DR and BDR, and other
OSPF options
• Understand how to configure OSPF route summarization.
understand DR and BDR considerations, and other OSPF
options
LJU!illPer� Worldwide Education Services
�;;u;�,,.-- "
_,, Juniper ne! I 4·4

A JNCIE-SP candidate is expected to be familiar with how to configure IS-IS. You need to understand
which IS-IS levels and area IDs must be used to establish an IS-IS adjacency. You must also
understand the details of IS-IS route summarization, DIS considerations, and other IS-IS options.
You must also be familiar with how to configure OSPF. It is important to know how to establish OSPF
adjacencies, and the differences between the various types of OSPF areas. You must understand the
details of OSPF route summarization, DR and BDR considerations, and other OSPF options.

• List of IGP lrnplementation Topics

� IS-IS Implementation
• OSPF Implementation
�.J""
UL!JlilJ.Eef��w�Worldwide Education Servicas ww" ,unip" net 1 4-6
IS-IS Implementation

IS-IS Considerations
• Configuring IS-IS
• 1Pv4 and 1Pv6 address families supported without explicit
configuration
• family iso is needed on each interface participating in
IS-IS
• You can use apply-groups to speed up tasks
• LSP and hello POU authentication
• Use the overload command to have all transit traffic avoid
a router
• Anytraffic destined to the overloaded router will still reach it
Configuring IS-IS
IS-IS is an interior gateway protocol (IGP) that forwards traffic inside your network. It is an IGP built to
be adaptive in that it supports both 1Pv4 and 1Pv6. In fact, you must explicitly disable 1Pv6 routing
inside of IS-IS if you do not require a router to forward 1Pv6 packets. It is important to note that many
configuration statements that are applied to IS-IS apply to 1Pv4 and 1Pv6. For example, placing an
interface into IS-IS that has 1Pv4 and 1Pv6 enabled on it results in IS-IS passing link-state protocol
data units (PDUs) that contain 1Pv4 and 1Pv6 prefixes.
A very important part, and often overlooked, of enabling IS-IS in your network is applying the
family iso statement to all interfaces that must participate in IS-IS. If you suspect this to be a
problem, issue the show isis interface command. If a particular interface is missing from this
output you have either forgot to place the family iso statement on it, or you did not place the
interface in IS-IS. Remember to apply an ISO address on the loopback interface. Technically, you can
apply this address on any interface, but if you apply it to a transit interface that goes down for any
reason you will lose all IS-IS functionality. To be safe, always apply the ISO address to the loopback
interface.

Configuring IS-IS (contd.)

You can use the apply-groups function to help speed up tasks, such as adding the family iso
statement to interfaces. However, caution is warranted because in doing so it is easy to inadvertently
place interfaces into IS-IS. This issue is particularly true if you configure an IS-IS instance and use
the interface all statement for a given level, which might result in traffic routing over your
management network. If this is the case, you can disable individual interfaces under IS-IS to restrict
this behavior.
IS-IS performs authentication at the LSP and hello levels. You can configure encrypted
authentication using the MD5 hashing algorithm or unencrypted authentication using plain text
authentication. Configuring LSP authentication occurs within Level 1 or Level 2, whereas configuring
hello authentication occurs at the interface hierarchy inside of IS-IS.
Use the overload command to advertise to other routers that transit traffic should avoid the local
router. However, the router maintains all protocol adjacencies and any traffic destined for the RE,
such as Telnet or SSH, arrives as if the router is not overloaded. Note that you can use the timeout
option in conjunction with the overload command. Specifying this option does not immediately put
the router into overloaded mode. Instead, the router enters the overloaded mode only after a reboot
and remains in that mode until the router exceeds the amount of time the timeout option
specifies. The timeout option has the same effect in IS-JS as it does in OSPF.
www.juniper.net IGP Implementation • Chapter 4- 7

IS-IS Level and Area Configuration
• IS-IS adjacencies
• Level 1 adjacencies
• Area and level must match
• Level 2 adjacencies
• Only level must match
• Two adjacencies form by default across a link
• Must disable the unwanted level adjacency
• Routers with Level 1 and Level 2 adjacencies
• Apply area ID of level 1
• Routers vvith only Level 1 or Level 2 adjacencies
• Apply area ID of current area
Configuring IS-IS Levels and Areas

IS-IS adjacencies form as Level 1, Level 2, or both. However, you must control which adjacencies
form over a given link. Be sure to disable the level for an interface that you do not want the link
participating in. Note that certain rules apply when a router is attempting to form an IS-IS adjacency.
All Level 1 adjacencies must have a matching level and area, whereas Level 2 adjacencies only
require the level of the interfaces to match. If you are attempting to connect a Level 1 router with a
Level 2 router that have differing areas, you must configure a Level 2 adjacency. If the areas match,
then a Level 1 adjacency is permitted.
During a lab scenario, you might have to decide which area ID to assign to various routers. If the
router has Level 1 and Level 2 adjacencies, apply the area ID that the Level 1 routers reside in. This
ensures that you can form Level 1 adjacencies across the link. If the router only has Level 1 or Level
2 adjacencies, then assign the current area ID that the topology lists.

Route leaking Considerations
• Route leaking: injecting or restricting routes from

appearing in a level
• Maf\e use of the from level and to level commands
• Use specific IS-IS routes and aggregate routes to create
primary and secondary paths
• Use the tag option when redistributing routes into IS-IS
• Similar to a BG P community
• Allows you to apply routing policy actions based on tag values
IS-IS Route Summarization

Route leaking is the term given to the method of summarizing IS-IS routes from one level to another.
Typically, a router leaks routes from Level 2 down to Level 1, however it might be necessary to leak
routes from Level 1 up to Level 2. For example, by default, IS-IS does not leak Level 1 external routes
into Level 2 areas, unless wide metrics is enabled, and it might be necessary for Level 2 routers to
have this specific routing knowledge. You must configure a routing policy to leak this specific route
into Level 2. Be sure to use the from level and to level statements when configuring your
route leaking policy. This ensures that the routes are leaking into only the levels that are required.
Forgetting to use these statements might result in inefficient LSP flooding and point loss on the real
exam.
If you leak an aggregate route into a level, but also allow the specific routes to be present in that
level, the routers in that level prefer the specific routes over the summary route. The same basic
routing rules of longest prefix match still apply in this scenario. However, this method forces the
routers to use the specific routing information as a primary path and the summary route as a
secondary path.
Using the tag option in a routing policy is a great way to track and manage the routes that your
routers are redistributing into IS-IS. This allows you to apply policies later on using the tag option as
a match criterion, simplifying your route leaking policies.

ms-IS Metrics
• IS-IS metric considerations
• Narrow metrics support a maximum metric value of 63
• Narrow metrics are used by default-can be explicitly configured
using the narrow-metrics-only command
• Wide metrics support a maximum metric value of
16. 777,215
• Configured per level using the wide-metrics-only command
Considerations with IS-IS Metrics

IS-IS supports two forms of metrics; narrow and wide. IS-IS uses narrow metrics by default. You must
explicitly configure a router to use wide metrics if the router must advertise a metric value greater
than 63. Wide and narrow metrics are configured on a per level basis, which means you can
configure a router to advertise narrow metrics for one level and wide metrics for the other level,
narrow metrics for both levels, or wide metrics for both levels.

• IS-IS DIS considerations

• DIS can be eliminated by setting the IS-IS interface in
point-to-point mode
• Hello-interval and hold-time values
• Different for DR and non-DR interfaces
• Non-DR interface values are at the configured levels
• DR interface values are 1/3 of the configured levels
• Configured hello-interval of 1 and hold-time of 3
- Non-DR interfaces = hello-interval of 1 and hold-time of
3
- DR interfaces = hello-interval of .333 and hold-time of 1
Considerations with IS-IS DIS

To reduce the number of adjacencies and LSP flooding on a broadcast segment, each router forms
an adjacency with only the designated intermediate system (DIS). While this works great for a LAN
that has multiple routers running IS-IS on a single broadcast domain, it does not provide any benefit
for most service provider networks in which connections are point-to-point. Note that setting the IS-IS
interface priority to O does not remove the DIS from the broadcast segment. The router with the
higher MAC address wins the DIS election. To correctly remove the DIS, configure the IS-IS interfaces
in point-to-point mode.
You can adjust hello intervals and hold times to help facilitate quick, or slow, failure detection.
However, designated router (DR) and non-DR interfaces calculate these values differently. A non-DR
interface takes the values that you input, whereas a DR interface divides that value by three. This
calculation helps facilitate a quicker failure detection of the DIS.

• List of IGP Implementation Topics

• IS-IS lmplernentation
�OSPF Implementation
OSPF Implementation

OSPF Considerations
• Configuring OSPF
• OSPFv2 only supports 1Pv4
• OSPFv3 supports 1Pv4 and 1Pv6
• IPv4 supported through the use of realms
• Authentication configured at the interface level
• OSPFv2 uses plain text or MD5 aut11entication
• OSPFv3 secures messages using IPsec security associations
• Use the overload command to have all transit traffic avoid
a router
• Any traffic destined to the overloaded router will still reacl1 it
'.
Configuring OSPF
It is important to know the differences between OSPFv2 and OSPFv3 when attempting to configure
them in your network. For example, OSPFv2 only supports 1Pv4, whereas OSPFv3 has support for
1Pv4 and 1Pv6. You can configure OSPFv3 to forward 1Pv4 traffic by enabling the 1Pv4 unicast realm
under the [edit protocols ospf3 J hierarchy level. However, there are some features, such as
plain text and MD5 authentication, traffic engineering, and virtual links, that are not present in the
OSPFv3 1Pv4 unicast realm. Because of the missing features, it is recommended that you configure
OSPFv2 and OSPFv3 to accommodate 1Pv4 and 1Pv6 traffic respectively.
The use of the overload command is similar to what was discussed in the IS-IS section of this
chapter, however, there are some major differences. When a router is overloaded in OSPF it
announces any prefixes that are reachable through it with the maximum possible metric value. If the
only path to a destination is through an OSPF router that is overloaded, the traffic will be forwarded
through the overloaded router. An overloaded IS-IS router cannot forward transit traffic no matter the
circumstance.

OSPF Route Summarization
• Summarizing OSPF routes

• Routes contained in Type 1. Type 2. and Type 7 LSAs can be
summarized
• Routes of Type 1 and Type 2 LSAs are summarized using the
area-rangecommand under the [edit protocols ospf
area x. x. x. XJ stanza. where Xis the area number
• Routes ofType 7 LSAs are summarized using the area-range
command under the [edit protocols ospf area
x. x. x. x nssa J stanza. where Xis the area number
• Routes contained in Type 5 LSAs cannot be summarized
• Verify what the task is asking-do not waste time figuring out
the most specific summary route if it is not required
Considerations When Summarizing OSPF Routes

The purpose of route summarization is to reduce the size of the link state database, which in turn
reduces the number prefixes in the routing tables of your routers. This summarization can only occur
at the area border routers (ABRs) with the area-range command, which means that you must
deploy multi-area OSPF to accomplish any route summarization.
Route summarization can only occur on certain routes. If the prefixes are contained within Type 1,
Type 2, or Type 7 LSAs, then you can summarize the routes. However, keep in mind that prefixes
contained within Type 5 LSAs have an area-wide scope and cannot be summarized. Note that you
can summarize Type 7 LSAs at a different hierarchy level than Type 1 and Type 2 LSAs, as shown on
the slide. Trying to summarize routes that contain Type 7 LSAs directly under the OSPF area hierarchy
level is a futile effort at best.
As with any route summarization task, OSPF or IS-IS, verify what the task is asking. Calculating the
most specific summary route can be time consuming. If the task does not ask for the most specific
summary route then do not take the time to figure it out. However, ensure the summary route you
choose does not interfere with other prefixes within your network.

OSPF Metrics
• OSPF metric considerations
• Bandwidth calculations
• By default every link will have a cost of 1
- Fast Ethernet. gigabit Ethernet. 10 gigabit Ethernet
• Manual cost can be set through the metric command
• Use to adjust unequal interfaces for load balancing
• Not recommended if metrics must be adjusted on every router
• Use the reference-bandwidth command to
automatically calculate link cost for every interface
• Use m and g notations to reference megabit or gigabit
• Type 1 and Type 2 metrics
• Type 1 must be applied through a routing policy
• Type 2 applied to routes by default that are redistributed into OSPF
Considerations with OSPF Metrics

By default, OSPF bandwidth calculations do not provide much benefit. Any link that is 100 Mbps or
faster has a cost value of 1. Two methods enable you to overcome this limitation; manual or
automatic bandwidth calculations. Setting the cost manually, through the metric command,
should be used only if you must fine tune a router's OSPF interface cost. For example, if load
balancing must occur over unequal interfaces. Manual bandwidth adjustment should never be used
to adjust all the cost values in your OSPF domain. Doing so is very time consuming and does not
scale well. To adjust the bandwidth consistently across your network, use the
reference-bandwidth command. This command calculates the cost by dividing the reference
bandwidth by the physical interface bandwidth. Note that this command is also available in IS-IS and
has exactly the same function.
By default, OSPF redistributes routes using a Type 2 metric, which is always less preferred than a
Type 1 metric. Remember that metric types are a great method to provide a primary and a secondary
path to a destination.
The default route that an ABR injects into a stub area has a Type 1 metric. However, you can
configure an ABR to inject a default route with a Type 2 metric instead. Use the default-lsa
command to accomplish this behavior. This method is an effective way to force routers in a stub area
to use one ABR over another.

OSPF DRs and BDRs
• DR and BDR considerations

• The DR and BDR can be removed from a broadcast domain
• It does not make sense to have a DR and BDR on a broadcast link
with only two hosts
• Setting the OSPF interface priority to O makes the router ineligible
to be a DR or BDR
- This only results in the routers being stuck in the 2-Way
adjacency state
• Setting the OSPF interface type to point-to-point is the correct way
to remove a DR and BDR from a broadcast domain
Ul!JQl.i�fr .lJXt1fldwlcle Education Services

a.,-•"""""F�i'
"""" )uo,per nsl 1 4-16
�--.->.<S- �
OSPF DR and BDR Considerations

OSPF DRs and backup designated routers (BDRs) are very similar to an IS-IS DIS. Each OSPF router
participating in a broadcast domain has an adjacency with only the DR and BDR. As with an IS-IS DIS
this concept works well in preventing scaling issues if more than two routers are on a broadcast
segment. However, in most service provider environments, and likely your exam, only two routers are
on every broadcast segment within the core. This makes the concept of a DR and BDR somewhat
pointless in this scenario.
To remove the DR and BDR from a broadcast segment, you might think that you can set the OSPF
priority to O for the interfaces in question. Doing so makes the routers ineligible to become the DR or
BDR for that broadcast segment but the routers still believe a DR and BDR are available. This results
in the two routers on the link becoming stuck in the 2-Way mode, and the OSPF adjacencies cannot
reach the Ful 1 state. The correct method to remove a DR and BDR from a broadcast segment is to
set the OSPF interfaces to point-to-point mode. This setting tells the routers that only two devices are
on the broadcast segment, and the OSPF adjacencies can reach the Full state with no DR or BDR
present.


II
List of IGP lrnplementation Topics
a IS-IS ln1plementation
II
OSPF Implementation


ask and Topology
DC
1010
• Task:
• R1 and R2 are receiving RIP routes from the DC router. The
specific RIP prefixes must not be present in your OSPF
domain. All internal routers. except R2, must use R1 to
reach these destinations. R2 can be used to reach these
destinations only if R1 is unreachable.
-�uo1Peli, _�)t,!�
• ' %!i,,_�.ef "" "'» �,,,m�="""'
©2012J•alRtrN• or!<s,los.A!Jtights,...,,,... "' WorldwideEducationServices www)un,pernef I 4-16
�'"'"" f;,��


What Now?

• Examine the RIP routes being received from the DC router
• Is route summarization required? Yes
• Must it be the most specific route possible? No
• How do you force all other internal routers to use R1 as the
primary path to these destinations?
• Apply a Type 2 metric to the aggregate route that R2 is
redistributing into OSPF
• This criterion does not include R2
• R2 can use its local RIP routes as the primary path to
these destinations
"'loll.�-J\��"C::""
�UnfPefifWorldwide Education Services WWW JUntper net J 4-19
�� "'
"'== y

Through examining the sample task and topology, you can determine what the sample task is asking.
The items on the slide list what is required to complete the sample task.

• Examine R1's RIP routes

lab@Rl> �how route protocol rip
inet.O: 46 destinations, 47 coutes (46 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, � = Both
10.31.1.0/24 *[RIP/100] 05:45:45, metcic 2, tag

> to 172.27.0.101 via ge-0/0/4.0
10 .31.2 .0/24 *[RIP/100] 05:45:45, metcic 2, tag
> to 172.27.0.101 via ge-0/0/4.0
10.31.3.0/24 *[RIP/100] 05:45:45, metcic 2, tag
> to 172.27.0.101 via ge-0/0/4.0
10.31.4.0/24 *[RIP/100] 05:45:45, metcic 2, tag
> to 172.27.0.101 via ge-0/0/4.0
224.0.0.9/32 *[RIP/100] 01:53:12, metcic 1
MultiRecv
"'
�[�� rldwide Education Services ww�Jun,pernet 1 4-20
!
Which RIP Routes Is R1 Receiving?

By examining Rl's routing table, you can determine which RIP routes Rl is receiving from the DC
router. Then you can determine the aggregate route.

• Examine R2's RIP routes

lab@R2> $how route protocol rip
inet.0: 44 destinations, 49 coutes (44 active, 0 hol ddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
10 .31. l. 0/24 '[RIP/100) 05:44:32, metcic 2, tag

> to 172.27.0.101 via ge-0/0/9.0
10.31.2 .0/24 '[RIP/100) 05:44:32, metcic 2, tag
> to 172 .27.0.101 via ge-0/0/9.0
10.31.3 .0/24 '[RIP/100) 05:44:32, metcic 2, tag
> to 172.27.0.101 via ge-0/0/9.0
10.31.4.0/24 *[RIP/100) 05:44:32, metcic 2, tag
> to 172.27.0.101 via ge-0/0/9.0
224.0.0.9/32 *[RIP/100) 05:44:46, metcic 1
MultiRecv
'"�'¥" '""'
UUfi'IISPn WorftlWrde'EducationServices '""'"' JUntper net J 4-21
�J •· '
Which RIP Routes Is R2 Receiving?

From this output. you can determine that R2 is receiving the same RIP routes from the DC router as
Rl.

• Configure an aggregate route, routing policy, and

redistribute the aggregate into OSPF-R1
[edit]
lab@Rl# show routing-options aggregate
t'OUte 10.31.0 .0/16;
[edit]
lab@Rl# show policy-options policy-statement rip-ospf
term agg (
from (
pr.otocol aggregate;
route-filter 10.31.0.0/16 exact;
l
then (
external
type 1;
I
accept;
[edit]
lab@Rl# show protocols ospf export
export rip-ospf;
Configuring R1
The slide displays the necessary configuration on R1 to redistribute the aggregate route that
represents the RIP routes. Notice that the aggregate route is not the most specific summary route
possible for the prefixes. The task does not require you to configure the most specific summary
route, so do not waste time doing so. The metric type is set to a value of 1. which is important
because without specifying this metric value the summary route would be redistributed with a metric
type value of 2.

• Configure an aggregate route, routing policy, and

redistribute the aggregate into OSPF-R2
[edit]
lab@R2# show routing-options aggregate
route 10.31.0.0/16;
[edit]
lab@R2# show policy-options policy-st atement rip-osp£
term agg {
from {
protocol aggregate;
l
then {
external
type 2;
I
accept;
[edit]
lab@R2# show protocols ospf export
expo rt r ip-os pf;
Configuring R2
R2's configuration is similar to Rl's configuration with the only difference being the metric type,
which is set to a value of 2. Technically, this setting is unnecessary because R2 wilt redistribute the
route with a Type 2 metric by default. However, configuring a Type 2 metric helps to visually clarify the
policy. This setting causes Rl's redistributed aggregate route to be more preferred by other routers
in the network.

• Path verification-R3
lab@R3> show route 10.31/16
inet.0: 41 des tinations, 41 routes (41 active, 0 holddown, 0 hidden)

+ = l>.ctive Route, - = Last l>.ctive, " = Both
10.31.0 .0/16 •[OSPF/150] 17:24:05, metric O, tag O

> to 172.27.0.9 via ge-0/0/1.0
lab@R3> show ospf database lsa-id 10.31.0.0 detail

OSPF J'..S SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 10.31.0.0 172.27.255.1 Ox80000002 11 Ox22 Oxcf7e 36
mask 255.255.0.0
Topology default (ID 0)
Type: 1, Metric: U, Fwd addr: 0.0.0.0, Tag: 0.0.0.0
Extern 10.31.0.0 172.27.255.2 Ox8000001d 12 Ox22 Oxed6 36
mask 255.255.0.0
Type: 2, Metric: 0, Fwd addr: 0.0.0.0, Tag: 0.0.0.0
Verifying the Path From R3

From R3's perspective, you can see it prefers the route which leads through R1. By examining the
link state database, you can see both external LSAs coming from R1 and R2. Notice the different
metric type values that each route has.

inet.0: 42 destinations, 42 coutes {42 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * Both
10 .31.0 .0/16 *[OSPF/150] 17:20:32, metcic O, tag

> to 172.27.0.14 via ge-0/0/2.0
lab@R4> show ospf database lsa-id 10 .31 .0.0 detail

OSPF AS SCOPE link state database
T\Jpe ID Adv Rte Seq Ag e Opt Cksum Len
Extecn 10.31. 0.0 172.27 .255 .1 Ox80000002 11 Ox22 Oxcf7e 36
mask 255.25.5.0.0
Type: 1, Metcic: 0' Fwd addc: 0.0 .0. 0, Tag: 0. 0. 0.0
Extern 10.31.0.0 172.27.255.2 Ox8000001d 12 Ox22 Oxed6 36
mask 255.255.0.0
Type: 2, Metcic: 0, Fwd addc: 0.0.0.0, Tag: 0.0.0.0
-ic·--=--�- �,!'�'<'1
UUlilmJ ,W�rldwide Educatlo n Services
'li
ww" ,, n 'P" n ,1 1 •-2s
Verifying the Path From R4

When possible, always verify a task from multiple routers. This ensures that what you see on one
router did not merely happen by chance. The slide shows that R4 prefers the route that it is receiving
from Rl.

• Path verification-R 1
lab@Rl> show route 10.31/16
inet.0: 45 destinations, 47 coutes (45 active, 0 holddown, 0 hidden)

10.31.0 .0/16 *[Aggcegate/130] 00:22:16

Reject
[OSPF/150] 22:17:41, metric 0, tag O
> to 172.27.0.25 via ge-0/0/2.0
10.31.1.0/24 *[RIP/100] 22:19:01, metric 2, tag
> to 172.27.0.101 via ge-0/0/4.0
10.31.2 .0/24 *[RIP/100] 22:19:01, metric 2, tag
> to 172.27.0.101 via ge-0/0/4.0
10.31.3 .0/24 *[RIP/100] 22:19:01, metric 2, tag
> to 172.27.0.101 via ge-0/0/4.0
10.31.4.0/24 *[RIP/100] 22:19:01, metric 2, tag
> to 172.27.0.101 via ge-0/0/4.0
Revisiting R1
After configuring route redistribution, it is always best to revisit the routers that are redistributing the
routes. Having two routers redistribute the same routes can cause unintended results on those
routers. For example, if this task required you to redistribute the specific RIP routes into OSPF, and an
earlier task required you to configure an external OSPF preference of 99, R1 would forward traffic
destined for the DC router towards R2 because R1 would be receiving the specific routes from R2 in
OSPF and they would have a preference of 99. The OSPF routes would be more preferred than the
RIP routes, which have a preference of 100.

Tas Verification (4 of 4)
inet.O: 38 destinations, 39 routes (38 a ctive, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, � = Both
10.31.0 .0/16 *[Aggregate/130] 3d 18:47:53

Reject
[OSPF/150] 00:20:50, metric 50, tag
> to 172.27.0.26 via ge-0/0/3.0
10.31. l.0/24 *[RIP/100] 22:21:39, metric 2, tag
> to 172.27.0.101 via ge-0/0/9.0
10.31.2 .0/24 *[RIP/100] 22:21:39, metric 2, tag
> to 172.27.0.101 via ge-0/0/9.0
10.31.3 .0/24 ·•[RIP/100] 22:21:39, metric 2, tag
> to 172.27.0.101 via ge-0/0/9.0
10.31.4.0/24 *[RIP/100] 22:21:39, metric 2, ta g
> to 172.27.0.101 via ge-0/0/9.0
Revisiting R2
�unm --
wo'rtdwideEducationServlces WWWJun,pernet I 4-27
The recommendation of revisiting R1 is applicable for R2 as well. From the slide shown, you can see
that the correct routing information is present on R2.

Summary
• Identified IGP Implementation subjects for the JNCIE-SP
exam
• Explained how to configure and monitor IS-IS
• Explained IS-IS areas and levels
• Described IS-IS and OSPF route summarization
• Explained IS-IS and OSPF metrics
• Described IS-IS DIS considerations
• Explained how to configure and monitor OSPF
• Described OSPF DR and BDR considerations

IGP Implementation subjects covered in the JNCIE-SP exam;
The configuration and monitoring of IS-IS;
IS-IS areas and levels;
IS-IS and OSPF route summarization;
IS-IS and OSPF metrics;
IS-IS DIS considerations;
The configuration and monitoring of OSPF; and
OSPF DR and BDR considerations.

Lab 2 and ab 3: IGP Implementation
• Lab 2: IS-IS Implementation

• Configure and monitor IS-IS operations.
• Lab 3: OSPF Implementation
• Configure and monitor OSPFv2 and OSPFv3 operations.
Note: These labs are timed simulations. You will

have 1 hour and 15 minutes to complete each lab.
""'""'"""'
WorldwldeEducatfonServices ww.,Junrpo,net 1 4·29
j •,i�Jti � =--
Lab 2 and Lab 3: IGP Implementation
The slide provides the objectives for these lab.


Chapter 5: IGP Troubleshooting

Chapter Objectives

able to:
• Identify IGP implementation subjects for the JNCIE-SP exam
• Explain possible causes of IS-IS and OSPF adjacency
problems
• Describe troubleshooting of IS-IS and OSPF adjacency
problems
• Explain troubleshooting of routing loops
• Explain considerations for overloaded routers
• Describe troubleshooting of route summarization issues

IGP troubleshooting subjects covered in the JNCIE-SP exam;
The possible causes of IS-IS and OSPF adjacency problems;
The troubleshooting of IS-IS and OSPF adjacency problems;
The troubleshooting of routing loops;
The considerations for overloaded routers; and
The troubleshooting of route summarization issues.
Chapter 5-2 • IGP Troubleshooting www.juniper.net

Agenda: IGP Troubleshooting
�List of IGP Troubleshooting Exam Topics

• IGP Troubleshooting
UUr.1ffli ;WorldwideEducatlonServices
��s �
wwwiunipernet 1 5.3
1;1;:::& h--
List of IGP Troubleshooting Exam Topics

www.juniper.net IGP Troubleshooting • Chapter 5-3

IGP Troubleshooting Topics for the

JNCIE-SP Exam
• IGP troubleshooting topics

• IS-IS adjacency issues
• Understand what can cause IS-IS adjacency issues
• Understand how to troublesl1oot IS-IS adjacency issues
• OSPF adjacency problems
• Understand what can cause OSPF adjacency issues
• Understand how to troubleshoot OSPF adjacency issues
• Other troubleshooting scenarios
• Routing loops
• Overloaded routers
• Route summarization issues

A JNCIE-SP candidate is expected to be familiar with how to identify and troubleshoot IS-IS and OSPF
adjacency issues. You must be able to recognize what problems can cause adjacency issues, and
understand what tools you can use to troubleshoot and fix those adjacency problems. Remember, an
adjacency must reach the Up state for IS-IS, or the Full state for OSPF to be considered operational.
You must be able to anticipate other troubleshooting scenarios in which your IGP is not functioning
properly. The scenarios might include, but are not limited to, routing loops, overloaded routers, and
route summarization issues. Be ready to troubleshoot any possible issues that might appear on the
exam.

• List of IGP Troubleshooting Exan, Topics

�IGP Troubleshooting
---�� 's.,,A,1:1!!1 i' -

�Ur.)� WoildwideEducationServices wwwJuniperne1 1 5·5
i&iiltl!li\a
IGP Troubleshooting

IS-IS Adjacency Problems
• Possible causes:
• Mismatched area IDs for Level 1 IS-IS adjacencies
• Duplicate system IDs
• Incorrect IP addressing
• Mismatched subnet masks do not affect IS-IS adjacencies
• Hello authentication mismatch
• LSP authentication problems do not affect IS-IS adjacencies
• Mismatched interface types
• Interfaces missing the family iso statement
• Interfaces that are physically down
• Incorrect IS-IS interface placement
• Low MTU setting-less than
.,
1492 for protocol family ISO
if�= .,•-<WW¥Wf===
G JIJCJW,iWprldwill,eEducalionServices waw1un,peroet I 5-6
,,.,��'U;;;.s!« ««
Possible Causes of IS-IS Adjacency Issues

Troubleshooting IS-IS adjacency issues can be a daunting task. The slide lists some possible reasons
why these adjacency problems can occur.
Remember that Level 1 adjacencies require the interface level and area ID to be the same before an
adjacency can form. If a Level 1 adjacency is required but the routers involved have differing area
IDs, the adjacency cannot form.
Having duplicate system IDs between two routers attempting to form an IS-IS adjacency-Level 1 or
Level 2-is similar to having two routers attempting to form an OSPF adjacency that have duplicate
router IDs (RIDs). The two routers will detect the duplicate system ID and the adjacency cannot form.
Incorrect IP addressing, where one side of the adjacency has an IP address in a differing subnet than
the other side of the adjacency, causes the adjacency to fail. However, if only the subnet masks of
the participating interfaces are mismatched, the adjacency will reach the Up state. For example, if
one interface is using the IP address of 172.11.55.1/30 and the interface on the adjacent router is
using the IP address of 172.11.55.2/24, the IS-IS adjacency can form. IS-IS does not require the
subnet mask to be the same, it only requires that the interfaces can communicate on the link.

Possible Causes of IS-IS Adjacency Issues (contd.)

Hello authentication mismatches will cause IS-IS adjacencies to fail, although an LSP authentication
mismatch will not. Note that if the adjacency reaches the Up state, but the Sys tern field does not
resolve to the host name of the adjacent router, then it is highly probable that an LSP authentication
failure occurred. If an authentication failure is occurring between two routers and plain text
authentication is used, you can acquire the password by using the monitor traffic
interface interface-name detail command. However, if any form of encryption is
required, such as MD5, it is impossible to decipher the authentication key. Change the
authentication key on both routers to establish the adjacency.
By default, all broadcast interfaces (such as gigabit Ethernet interfaces) placed in IS-IS will function
in a broadcast mode, in which a designated intermediate system (DIS) should be present. This
interface mode is incompatible with interfaces placed in the point-to-point mode. If an IS-IS
adjacency has an interface running in broadcast mode and the other interface running in
point-to-point mode, the adjacency will fail.
Every interface that participates in IS-IS must have the family iso statement configured under its
logical unit. If this statement is missing, the interface cannot participate in IS-IS, even if the interface
is configured under the IS-IS protocol. Note that this statement might be applied to the necessary
interfaces through the use of apply-groups. Use the show I display inheritance
command at the [edit interfaces] hierarchy level to view any configuration statements that
are applied through the use of apply-groups.
Anything that restricts communication between the two routers can affect adjacency formation, and
an interface that is physically down stops all communication between two routers. Examine the
interfaces by issuing the show interface terse I match down command if you suspect this
to be a problem.
Be mindful of the IS-IS interface placement when troubleshooting IS-IS adjacencies. An interface
might be configured in the wrong level, in passive mode, or disabled. If any of these conditions exist,
the adjacency will fail.
IS-IS adjacencies can form if an MTU mismatch exists, but if the MTU for the protocol family ISO is
lower than 1492, the IS-IS adjacency will fail. If you suspect this problem with a specific interface,
issue the show interface interface-name I match mtu command, to determine what
MTU values are applied to the interface in question.

OSPF Adjacency Problems

• Possible causes:
• Duplicate RIDs
• Mismatched subnet masks or incorrect IP addressing
• Authentication mismatches
• Mismatched interface types
• OSPF interface priority set to O on both sides
• Interfaces that are physically down
• Mismatched area types or area IDs
• Mismatched hello intervals and dead intervals
• Mismatched MTU settings
• Remember to examine OSPFv2 and OSPFv3 adjacencies
:, . W&��*-''-'"
m:.Jf;l��orl®!ideEducationServices
-�� ""==
WWl'l]unopernet J s-a
Possible Causes of OSPF Adjacency Issues

Troubleshooting OSPF adjacency issues can be a daunting task. The slide lists some possible
reasons why these adjacency problems can occur.
Duplicate RIDs in OSPF are very similar to duplicate system IDs in IS-IS, in which an adjacency
cannot form between two routers with duplicate RIDs. However, in OSPF, the RID is typically acquired
from the primary address on the loopback interface. Having routers that contain a duplicate IP
address on their loopback interfaces can lead to other problems, such as routing loops.
Mismatched subnet masks, or incorrect IP addressing on an interface will cause the OSPF adjacency
to fail. This problem is unlike IS-IS, in which adjacencies will establish even if there is a mismatched
subnet mask.
Authentication mismatches will cause an OSPF adjacency to fail. Similar to IS-IS, if the
authentication method being used is plain text then you can acquire the password by using the
monitor traffic interface interface-name detail command. However, if any form
of encryption is required in the authentication method, then it is impossible to decipher the
authentication key. You must change the authentication key on both routers to establish the
adjacency.

Possible Causes of OSPF Adjacency Issues (contd.)

As with IS-IS, mismatched interface types can cause OSPF adjacency problems, but unlike IS-IS,
some combinations will work. For example, one side of the adjacency can be configured in
point-to-point mode, and the other side of the adjacency can be configured in point-to-multipoint
mode. In this scenario, the OSPF adjacency will reach the Full state. However, if an OSPF adjacency
has one side set to the default broadcast mode, and the other side set to point-to-point mode or
point-to-multipoint mode, the adjacency will fail.
If the OSPF priority is set to O on broadcast interfaces participating in the adjacency that are not in
point-to-point or poin t -to-multipoint mode, the adjacency will become stuck in the 2-Way state. This
occurs because both routers believe that other routers are on the network segment that can act as
the designated router (DR) and backup designated router (BDR). Remember that OSPF routers in a
broadcast domain only form adjacencies with the DR and BDR.
As with IS-IS, blocking communication between the two routers will cause an adjacency to go down. If
you suspect this to be the problem, issue the show interface terse I match down
command.
Mismatched area IDs or mismatched area types will cause an OSPF adjacency to fail. You can
examine which area an interface is participating in by issuing the show ospf interface or
show ospf3 interface commands.
Unlike IS-IS, OSPF adjacencies must have matching hello and dead interval values. The routers do
not negotiate the values and the adjacency is declared down. Hello and dead interval mismatches
can be examined through the use of traceoptions or by using the monitor traffic interface
interface-name detail command.
OSPF is very sensitive to mismatched MTU settings in which, if there is any variance to the family
INET MTU or family INET6 MTU values, the adjacencies will not establish for OSPFv2 or OSPFv3,
respectively. Note that if the logical MTU values are not set for any of the protocol families, then the
family INET MTU and family INET6 MTU values will be 14 bytes below the configured physical MTU
value. For example, if the physical MTU value is set at 1514 bytes, then the family INET MTU and
family INET6 MTU values will be set at 1500 bytes.
Remember that two different protocols must be used to handle 1Pv4 and 1Pv6 traffic with OSPF.
There might be different problems for an OSPFv2 adjacency and an OSPFv3 adjacency over the
same link. Also, traceoptions are configured at different hierarchy levels within the configuration for
OSPFv2 and OSPFv3.

JNCIE Service P rovider Bootcamp
Troubleshooting Adjacency Issues

• Troubleshooting tools
•monitor traffic interface interface-name
detail
• Quick and dirty
• Use the no-resolve option to remove the look up delay
• Traceoptions
• More specific but might cost time deciding wl1ich flags to use
• IS-IS: hello detail and error detail flags
• OSPF: hello detail and error detail flags
• Examine which interfaces are participating in the protocol
• IS-IS: show isis interface
• OSPF: show ospf interface and show ospf3 interface
• Adjacency states might give valuable clues
�wN!!tx ac�ffl\f!:"' ""',s7:
�12J(il� · �!ldJ'l!�e Ei;!ucalionSe,vlces ww" Jun,per nel 1 5·10
,sii!>i>i oili
How to Troubleshoot Adjacency Problems

When there are no obvious reasons for an adjacency issue, you must take a closer look at the
internal workings of the IGP. Using the monitor traffic interface interface-name
detail command is a quick way to examine the interactions between two routers. However, it might
take time to sift through the information presented. When using this command, look for the specific
conversations occurring between two routers. For example, if a problem with OSPFv3 adjacency
occurs between two routers, look for the 1Pv6 packets that are entering and exiting the router.
Using traceoptions is a great method in determining exactly what is wrong with an adjacency. It can
tell you exactly what the problem is. For example, if a hello authentication problem occurs between
two routers attempting to form an IS-IS adjacency, then the traceoptions will record the
authentication failure. Whereas, using the monitor traffic interface interface-name
detail command might only allude to the authentication problem. However, determining which
traceoptions flags to use might prove difficult. Consider using the hello detail and error
detail flags to troubleshoot adjacency issues.
Use the commands shown on the slide to determine which interfaces are participating in the IGP. If
an interface does not appear in this list, and it should be participating in the IGP, the adjacency can
never form. This also helps reveal problems with the interface types, priorities, configured areas, and
so forth.
Examining the adjacency states can provide valuable information for a malfunctioning adjacency. For
example, if one side of an OSPF adjacency is stuck in the Exchange state, and the other side is
stuck in the ExStart state, there is a good possibility that an MTU mismatch is occurring.

Troubleshooting Routing Loops
• What is a routing loop?

• Anytime a packet passes through a routing instance more
than once
• Packets will loop until the TTL expires
• Typically occurs at points of route redistribution
• How to troubleshoot a routing loop
• tracerou te
• Helps to determine where tt1e routing loop is occurring
• Examine routing tables
• Once you have found the point at which the packet loops. the
routing tables on the involved routers can give valuable
information
A Routing Loop Defined

Any time a packet passes through a routing instance, typically the master routing instance, more
than once. a routing loop has formed. Link-state IGPs have mechanisms that make them very
resistant to forming routing loops. Because of the routing loop's resistant behavior of link-state IGPs,
routing loops typically form at points where route redistribution is taking place. The IGP currently
employed in the network is not privy to the routing information contained within another routing
protocol. An unwittingly written routing policy has the ability to inject routing information that causes
a routing loop.
Troubleshooting a Routing Loop

When troubleshooting a routing loop, you must quickly determine where the loop is actually taking
place. Use the traceroute command, from multiple routers if necessary, to help you narrow down
the point at which the loop is occurring. Once you have determined where the routing loop is
occurring, examine the routing tables on those routers. This will provide you with the information that
is necessary to correct the routing loop. Solving a routing loop might require you to change the
preference value of a routing protocol, block a certain route, or change a routing policy.

An Overloaded Router
• What does it mean to have an overloaded router in
IS-IS or OSPF?
• In OSPF, the router advertises the maximum metric for any
routes that will cause the router to forvvard transit traffic
• In IS-IS. the router floods its locally generated LSP. to other
IS-IS routers. with the overload bit set
• Be careful if the overload timeout statement is
configured
• Bouncing the protocol will cause the router to become overloaded
• A router can be configured to be overloaded or can become
overloaded
• If the prefix-export-limit statement is configured and the
router exceeds that limit. it becomes overloaded
An Overloaded Router in Your Network

Remember, when a router is overloaded in OSPF it advertises the maximum metric for any routes
that will cause the router to forward transit traffic. If the only available path leads through an
overloaded router. the traffic will be forwarded through the router. If a router is overloaded in IS-IS
transit traffic cannot be forwarded through it.
A router can become overloaded by explicitly configuring it to be overloaded or through other means,
such as the use of the prefix-export-limit statement. If a router begins exporting more
routes into a protocol than is allowed by the prefix-export-limit statement, it enters the
overloaded mode. This issue is difficult to troubleshoot, but through the use of traceoptions you can
determine if overloading is the problem.
During a lab examination. it is common practice to bounce a protocol by deactivating it, committing
the configuration. activating the protocol, and committing the configuration again. However. be
careful with this troubleshooting method if the overload timeout statement is configured on the
router. Doing so causes the router to enter the overloaded state for the time specified in the
statement. This causes a very unstable network that might cause you to notice temporary problems
that seem like constant issues.
Note that if a router is an OSPF area border router (ABR) for a stub area and it is overloaded, the
overloaded state has no effect on the default route if one is injected into the area. The default route
will contain the metric and metric type values that are set when it is injected into the area. However.
if an L1/l2 IS-IS router is injecting an LSP with the attached bit set. and it becomes overloaded; the
attached bit is removed from the LSP.

Route Summarization Issues
• IS-IS route leaking

• Examine route leaking polices for common issues
• Incorrect criteria: from protocol. from level. and to
level
• Incorrect actions: reject instead of accept
• OSPF area-range statement
• restrict option blocks route propagation into the
backbone area
• Ensure the area-range statement is applied at the
correct hierarchy level
• Directly undert11e area stanza for Type 1 and 2 LSAs
• Directly under tl1e nssa stanza for Type 7 LSAs
UUfillPefi hvorfdvrideEducationSer11lces WW� 1un,per net I 5·13

-� "�;:;;,.,y:,,__
Troubleshooting IS-IS Route Summarization Issues

IS-IS route summarization occurs through route leaking within routing policies. If you suspect a
problem with IS-IS route summarization, examine the L1/L2 router, or routers. Problems with the
route leaking policy might be causing summarization issues.
Troubleshooting OSPF Route Summarization Issues

Route summarization occurs within OSPF through the use of the area-range statement. If the
restrict option is present, any routes that match the prefix listed by the area-range statement
will not be flooded into the backbone area. If the area-range statement is placed in the incorrect
hierarchy level, the route summarization will not occur as expected. If specific routes are present in
the backbone area, which should be summarized, examine where the area-range statement is
applied in the configuration.


II
List of IGP Troubleshooting Exarn Topics
111
IGP Troubleshooting
----� ,--
' .
• un1Per,/{WOrldwideEducalionSe1Vices
� ;;.�"� '-'_;
ww�)<Jn,pernet I 5-14


Task and Topology
• Task:
• The OSPFv2 adjacency between Ri and R2 is currently not
operational. Ensure that the adjacency reaches the Full
state.
!! I

This slide displays the sample task and topology. We analyze this task in the next set of slides.

What Now?
• Must you troubleshoot OSPFv2 and OSPFv3? No
• Only OSPFv2 adjacency establishment is required
• Which troubleshooting tools can you use?
• Examine OSPF adjacencies
• Adjacency states might provide valuable clues
•monitor traffic interface interface-name
detailortraceoptions
• MTU problems
• Hello and dead intervals
• Mismatched subnet masks
• Others

By examining the sample task and topology, you can determine what the sample task is asking. The
items on the slide list what is required to complete the sample task.

• Examine the OSPFv2 adjacency

lab@Rl> �how o�pf neighbor
Addcess In tee face State ID Pei Dead
172.27.0.13 ge-0/0/6 .0 Full 172.27.2 55.3 128 18
172.27.0.2 ge-0/ 0/3 . 0 Exchange 172.27.255.2 128 22
lab@R2> �how o�pf neighbor

Addcess In tee face State ID Pei Dead
172.27.0.1 ge-0/0/3.0 ExStact 172.27.255. l. 128 26
172.27.0.17 ge-0/0/2.0 Full 172.27.255.3 128 18
172.27.0.21 ge-0/0/5 .0 Full 172.27 .255.4 128 17
172.27.0.25 ge-0/0/6.0 rull 172.2 7.255. 5 128 10
11""=
1";;: = ·-
Worldwide Education Services '""'" Juniper net 1 5-17
The Adjacency State Between R1 and R2

Rl displays that it is in the Exchange state when trying to form an adjacency with R2. R2 displays
that it is in the ExStart state when trying to form an adjacency with Rl. These adjacency states
lead us to suspect an MTU problem exists between the two routers.

• Monitor R1's ge-0/0/3 interface

lab@Rl> monitor traffic interface ge-0/0/3 detail no-resolve
Address resolution is OFF.
Listening on ge-0/0/3, capture size 1514 bytes
17:26:41.350994 �(tos OxcO, ttl 1, id 17971, offset 0, flags [none],

prnto: OSPF (89), length: 52) 172.27.0.2 > 224.0.0.5: OSPFv2, Database
Description, length 32
Router-ID 172.27.255.2, Area 0.0.0.0, Authentication Type: none (0)
Options [Opaque], DD Flags [Init, More, Master], !MTV: 1486, !
sequence: Oxac172c39
17:26:41.352069!0ut IP!(tos OxcO, ttl 1, id 41177, offset 0, flag s [none],
proto: OSPF (89), length: 132) 172.27.0.1 > 22 4.0.0.5: OSPFv2, Database
Description, length 112
Router-ID 172.27.255.1, Ar.ea 0.0.0.0, Authentication 1'Jpe: none ( 0)
Options [Opaque], DD Flags [none], !MTV: 1500, !Sequence: Oxac172c39
Advertising Router 172.27.255.1, seq Ox80 000004, age 777s, length 28
Router LSA (1), LSA-ID : 172.27.255.1
Options: [Demand Circuit]
Confirming the MTU Suspicions

By issuingthemonitor traffic interface ge-0/0/3 detail no-resolve command
on Rl, you can see that an MTU issue exists. Rl is sendinga family INET MTU value of 1500 bytes,
whereas R2 is sending a family INET MTU value of 1486 bytes.

• Examine and change the MTU setting on R2's

ge-0/0/3 interface
lab@R2# run show interfaces ge-0/0/3 I match mtu
Link-level tvpe: Ethernet, �TU: 1500, !speed: lOOOmbps, BPDU Error: None,
iProtocol inet,MTU : 14861
Protocol inet6, MTU: 1486
[edit interfaces ge-U/0/3]

lab@R2# set mtu 1514

lab@R2# commit
commit complete

lab@R2# run show interfaces e-0/0/3 I match mtu
1
Link-level type: Ethernet,MTU: 1514,!speed: lOOOmbps, BPDU Error: None,
iPro tocol inet, MTU: 1500!
Protocol inet6,MTU: 1500
Fixing the MTU Problem

By examining R2, you can determine that the physical MTU value for its ge-0/0/3 interface is set to
1500 bytes. This lowers its family INET MTU value to 1486 bytes. Changing the physical interface
value to 1514 bytes resolves the problem. Alternatively, you could delete the physical MTU value
because a gigabit Ethernet interface defaults to a physical MTU value of 1514 bytes.

"'
Task Verif cation
• Examine the OSPFv2 adjacency

lab@Rl> show ospf neighbor
Addr-ess Intei:face State ID Pt:i Dead
172.27.0.13 ge-0/0/6.0 Full 172.27.255 .3 128 18
172.27.0.2 ge-0/0/3 .0 Full 172.27.255.2 128 22
lab@R2> show ospf neighbor

Addt:ess Intei: face State ID Pt:i Dead
172.27 .0.1 ge-0/0/3.0 Full 172.27.255. 1 128 26
172.27.0.17 ge-0/0/2 .0 E'ull 172.27.255.3 128 18
172.27.0.21 ge-0/0/5.0 Full 172.27.255.4 128 17
172 .27.0 .25 ge-0/0/6.0 Full 172.27.255.5 128 10
Verifying the OSPF Adjacency

Issue the show ospf neighbor command on Rl and R2 to verify that the OSPF adjacency has
reached the Full state.

Summary
• Identified IGP implementation subjects for the JNCIE-SP
exam
• Explained possible causes of IS-IS and OSPF adjacency
problems
• Described troubleshooting of IS-IS and OSPF adjacency
problems
• Explained troubleshooting of routing loops
• Explained considerations for overloaded routers
• Described troubleshooting of route summarization issues
�� ..,.....�
WcirldwideEducationServicas ww.,Junope,net I s-21

!GP troubleshooting subjects covered in the JNCIE-SP exam;
The possible causes of IS-IS and OSPF adjacency problems;
The troubleshooting of IS-IS and OSPF adjacency problems;
The troubleshooting of routing loops;
The considerations for overloaded routers; and
The troubleshooting of route summarization issues.
www.juniper.net !GP Troubleshooting • Chapter 5-21

Labs 4 and 5: GP Troubleshooting
• Lab 4: IS-IS Troubleshooting

• Troubleshoot IS-IS adjacency issues.
• Troubleshoot other IS-IS issues.
• Lab 5: OSPF Troubleshooting
• Troubleshoot OSPF adjacency issues.
• Troubleshoot other OSPF issues.
Note: These labs are timed simulations. You

will have 1 hour to complete each lab.
�"'""'""J!s�? "�
��Iii�'Worl!!wide EducalionServ[ces ww" Jun,pernet 1 5·22
Lab 4 and Lab 5: IGP Troubleshooting

The slide provides the objectives for these labs.

JUn!J2{�,r
Chapter 6: BGP Implementation

Chapter Objectives

able to:
• Describe IBGP and EBGP advanced topics
• Implement complex routing policy with 1Pv4 and 1Pv6

Internal BGP (IBGP) and external BGP (EBGP) implementation advanced topics; and
Complex BGP routing policy with IP version 4 (1Pv4) and IP version 6 (1Pv6).
Chapter 6-2 • BGP Implementation www.juniper.net

Agenda: BGP Implementation
� BGP Configuration and Implementation

• BGP Routing Policy
BGP Configuration and Implementation

The slide lists the topics we discuss in this chapter. We discuss the highlighted topic first.
www.juniper.net BGP Implementation • Chapter 6-3

IBGP and EBGP
• IBGP sessions established within an AS

• Usually use loopback addresses-lGP path redundancy
• IBGP sessions cannot relay IBGP-received routing
information
• Full mesh of IBG P sessions in ISP environment
• Can use scaling mecl1anisms sucl1 as route reflection and
confederations
• EBGP sessions established across an AS boundary
• Usually use physical interfaces-IP TTL is 1 by default
• BGP next hop does not change on IBGP by default
• Watch out for BG P next-hop reachability problems
• You can use NHS policy or IG P passive on AS external interface
"' ";JU(;ll�'WorldwideEducationServfces """'''"'P"ne' 1 s-,

t=..arJt=�
IBGP Sessions
BGP sessions fall into one of two categories: IBGP or EBGP.
IBGP sessions usually use loopback addresses because the underlying interior gateway protocol
(IGP) normally provides redundant paths between two BGP speakers. BGP uses the AS path as a loop
detection mechanism. Because the AS path is not changed within an AS, IBGP cannot send updates
received from IBGP neighbors to other IBGP neighbors. This constraint requires that IBGP networks
be designed with a full mesh of IBGP speakers. Configuring and maintaining a full mesh of sessions
poses a challenge in bigger ISP networks. To overcome the problem, Internet service providers (ISPs)
use route reflection, confederations, or a combination of the two scaling methods. In the exam, you
should be ready to configure any of these methods. We discuss them later in this chapter.
EBGP Sessions
EBGP sessions are usually established with directly connected neighbors across an AS boundary.
EBGP takes the IP time to live (TIL) value of 1 by default You can optionally tune up the parameters
of both IBGP and EBGP to establish the sessions as needed.
Upon receiving an update BGP always checks the BGP next hop for reachability. Recall that BGP next
hop is changed over EBGP sessions but not over IBGP sessions. You can either change the next hop
to self with policy at the AS boundary router (ASBR) before sending an update to IBGP neighbors, or
you can configure the ASBR external interface as IGP passive. You should know how to use both
approaches for the exam. We review routing policies later in this chapter.

4=Byte AS Number Concepts

• Minimal changes in BGP operations
• Specified in RFC 4893 and implemented using a new
capability 65
• Two new optional transitive attributes: AS4_PATH and
AS4_AGGREGATOR
• New extended community attributes: 4-byte AS specific
• Compatibility
• 32-bit mode when peering with 32-bit peers
• 16-bit mode when peering with 16-bit peers
• AS 23456 (AS_TRANS) is used as the AS number when a
4-byte AS number must be represented on a router that
does not understand it
4-Byte AS Number Concept

4-byte AS numbers have been created to solve the 2-byte AS number depletion problem. There are
four BGP data entities that carry AS numbers:
AS_PATH attribute;
AGGREGATOR attribute;
COMMUNITIES attribute;
The Open message.
A new capability code 65 is used in the Open message to negotiate support of the 4-byte AS number
between two BGP speakers. Two new optional transitive attributes are added to convey 4-byte AS
number information: AS4_PATH and AS4_AGGREGATOR. BGP communities are supported in 4-byte
AS number environments by using a new Extended Community attribute called the 4-0ctet AS
Specific BGP Extended Community.
4-Byte AS Number Compatibility

A reserved 2-byte AS number, 23456, called AS_TRANS, is used for interoperability with the old BGP
implementations that do not understand the 4-byte AS numbers

4-Byte AS Number Compatibility Example
AS4_PATH 110000 100000 AS4_PATH 110000 100000

AS_PATH 100000
AS_PATH 23456 23456 AS_PATH 65000 23456 23456
AS 100000 AS 110000 AS65000 AS120000
I Peers with AS 23456 AS 120000 reconstructs the AS_P�.TH

AS_PATH 65000 110000 100000
" = �w '%4 " tR

HUO� 'WorldwicleEducalionServlces """"1Junopernel J 6-6
�&--:Eh'£.
4-Byte AS Number Compatibility Example

The slide shows a sample BGP topology with four autonomous systems. One "old" AS 65000 that
does not understand 4-byte AS numbers. Because of that barrier, the ASBRs of the old AS are
configured to peer with AS_TRANS 23456 as a neighboring AS. AS 110000, detecting that the
neighboring AS is the old AS, puts the AS_ TRANS to the AS_PATH as a placeholder for its own AS and
for any other 4-byte AS numbers appearing on the path. AS 120000 uses both AS_PATH and
AS4_PATH attributes to reconstruct the path.
Two configuration methods exist to configure a 4 byte AS number in the Ju nos operating system:
1. AS-plain notation:
[edit routing-options]
user@Rl# show
autonomous-system 100000;
2. AS-dot notation:
[edit routing-options]
user@Rl# show
autonomous-system 1.34464;
Note: We recommend that you use only one method across the domain to avoid confusion.

Connecting 1Pv6 Sites Through an 1Pv4 Core

• 6PE is a technique that provides interconnection of 1Pv6
sites over an 1Pv4 MPLS cloud (RFC 4798)
• ISP core runs 1Pv4 and MPLS
• PEs are dual-stack routers running 1Pv6 towards an 1Pv6 island
and 1Pv4 towards the core
• PEs convey family 1Pv6 labeled unicast between them over 1Pv4
BGP sessions
• P routers are not aware of 1Pv6, they forward MPLS packets
• You must configure appropriate export policies on the PE router to
share route information between BGP and other protocols
/
®--e�0---t®-+-t
PE1 LSP PE2
1Pv6 1Pv6
6� -------------- 6�
1Pv41BGP
��"""'"."¥
WorfdwfdeEducationServices wwwiuniporne1 1 6-7
�"!h,;
·��
ffi
Connecting 1Pv6 Sites Through an 1Pv4 Core Using 6PE

6PE is a technique that provides the interconnection of 1Pv6 sites over an 1Pv4 MPLS cloud. A 6PE
router is an ASBR that is directly connected to an 1Pv6 island. The interface between the edge router
of the 1Pv6 island and the 6PE router is a native 1Pv6 interface. The ISP backbone network is built on
1Pv4 and MPLS technologies. The 6PE concept is relative to the Layer 3 VPN, where customer
packets are transported over the ISP network in MPLS packets.
You can run either LDP or RSVP signalled LSPs in the core. Configure BGP PE to PE sessions as
multiprotocol sessions supporting 1Pv4 and 1Pv6 families. The Junos OS sets the BGP next hop in
1Pv4-mapped 1Pv6 address in the form of ::ffff:172.27.255.1 automatically. You must include 1Pv6
tunneling setting under protocols mpls to enable the Junos OS to populate the inet6. 3 table
with these addresses in addition to the matching 1Pv4 loopback addresses in inet.3 table.
The following configuration example emphasizes the essential steps required to provision the 6PE
service. The ge-0/0/1 is the native 1Pv6 interface that is connected to the 1Pv6 island. All core-facing
interfaces must be configured with family inet. inet6, and MPLS support. In our case, ge-0/0/2 is the
core-facing interface. Protocols MPLS is configured with IPv6-tunneling to make use of the
inet6. 3 table. Finally, BGP is configured to support the inet6 labeled-unicast family. The
labeled-unicast knob makes BGP convey an inner label along with an 1Pv6 route that allows the
advantage of label stacking. Explicit null is mandatory configuration for the 6PE application. This
setting makes BGP always advertise the inner label of 2, which is known as the 1Pv6 explicit null
label.
www.juniper.net BGP Implementation • Chapter 6- 7

Connecting 1Pv6 Sites Through an 1Pv4 Core Using 6PE (contd.)

[edit interfaces]
user@PEl# show
ge-0/0/1 (
unit O (
family inet6 (
address 8001: :2/126;
ge-0/0/2
unit O
family inet
address 10.255.2.1/24;
family inct6;
family mpls;
loO
unit O (
family inet
address 10.255.255.16/32;
[edit protocols]
user@PEl# show
ldp
interface ge-0/0/2.0;
mpls (
ipv6-tunneling;
bgp
group to_PE2 (
type internal;
local-address 10.255.255.16;
family inet6 (
labeled-unicast (
explicit-null;
neighbor 10.255.255.15;
group to_CEl
local-address 8001::2;
family inet6 (
unicast;
peer-as 200;
neighbor 8001::l;

Add.tional 6PE Details
• Next hop self policy is not required on 6PE routers

• Advertising PE router automatically sets BGP next hop
attribute to 1Pv4-mapped 1Pv6 address (RFC 3513)
• Receiving PE automatically puts 1Pv4-mapped 1Pv6
addresses into inet6.3 table when MPLS LSPs are set up
- 'S .....
Worldwide Education Services www J""P" ne1 1 6·9
t
•cl< - -laa.c}c.s,.-,
Additional 6PE Details

You do not need to configure BGP next hop self policy to change the next hop for EBGP-received 1Pv6
routes before sending them to remote 6PE routers-this change is done automatically. The Junos OS
sets the 1Pv4-mapped 1Pv6 address as the next hop.
When the 6PE router receives an update, it checks the BGP next hop in the inet6. 3 table and once
an MPLS LSP is established to the advertising peer, the update is processed.
If the routing between the 6PE ASBR and the 1Pv6 island is not BGP, then you must configure proper
redistribution policy on the 6PE router.

ual Stack Peering Caveats
• MP-BGP requires that a BGP next hop use the same

address family as the NLRI
• When I Pv4 session is used to convey I Pv6 routes, BG P next
hop is encoded in 1Pv4-compatible 1Pv6 address (RFC 3513)
• Make sure that this address is configured and reachable
• If 1Pv6 peering uses link local addresses (FE80:/10),
local interface configuration is required
-· ·=v� N;,m•
�l.:J[l� WJ?,rldwideEducallonServlces ,wmJun,perne! 1 s-10
� �t = �
MP-BGP Next Hop

If you use 1Pv4 BGP session to convey multiprotocol routing information, then according to MP-BGP
specification, BGP next hop is encoded using the same address family as the carried NLRI. To fulfill
the requirement for conveying 1Pv6 network layer reachability information (NLRI), the Junos OS
encodes BGP next hop into 1Pv4-compatible address. This address takes a form of ::17 2.27.255.1.
(::ac1b:ff01) for the matching 17 2.27.255.11Pv4 address. For a BGP-receiving peer to use the next
hop, it must know how to reach it. You must configure both exchanging sides with 1Pv4-compatible
I Pv6 addresses.
1Pv6 Link Local Address Peering

For 1Pv6 native peering, you can use either global addresses or link-local autogenerated addresses if
the neighbor is on the same connected network (EBGP). Note though, that in the latter case, you
must configure local interface in the BGP stanza because the link-local address is unique only on the
link.

BGP Authentication
• BGP exchanges can be authenticated

• By default. authentication is disabled
• You can configure MD5 authentication key or
• You can configure hitless authentication key rollover
• Allows update aut11entication keys wit11out resetting any BG P
peering sessions
• Allows you to choose the aut11entication algoritl1m
• Authentication can be configured under BGP protocol,
group. or neighbor level
'l'li'l\e, '
Worldwide EducatlonSe111ices ww"'J'"P" net I s 11
(H
""• �
BGP Authentication
One possible exam task might be configuring BGP authentication. By default, authentication for BGP
sessions is disabled. There are two approaches to configuring BGP authentication: configuring a
static key or configuring key chains. The latter method allows hitless authentication key rollover
because a key chain can be configured with several keys-each of them having a specified activation
date and time. Key chains also allow you to choose which authentication algorithm to use. If you are
using static key chains, there is only one authentication algorithm-MOS. Hence, you must configure
only one authentication key.
Recall that authentication can be configured under BGP protocol, group, or neighbor level, and the
most specific application overrides those of less specific. The following snippet shows an example
configuration for the MD5 authentication. The authentication key is always shown in the hashed
form, however, you must enter it as a plain text while configuring the key from the keyboard.
[edit protocols bgp]

user@Rl# show
group int-65503
type internal;
authentication-key "$9$cT7SvLbs4aZjNd2aZjkq69AultO"; ## SECRET-DATA
local-address 192.168.100.l;
neighbor 192.168.100.2;

BGP Authentication (contd.)

To enable key chain BGP authentication. you must configure three parts. The following configuration
is an example of enabling key chain BGP authentication. First, you must specify which authentication
algorithm you want to use under the BGP protocol, group, or neighbor level.You can choose md5,
hmac-sha- 1-96, or aes- 128-cmac-96 authentication algorithms. Then, you must reference a key
chain that will be used. Finally, you must configure the key chain under the security
authentication-key-chains hierarchy. Each key in a key chain is identified by its number
from Oto 63, and you must specify a secret and a start-time.
user@Rl# show
group int-65503
type internal;
authentication-algorithm hmac-sha-1-96;
authentication-key-chain my-key-chain;
neighbor 192.168.100.2;
[edit security]
user@Rl# show
authentication-key-chains
key-chain my-key-chain {
key O {
secret "$9$mPz69CulEytuNb2aiHtuOBic"; ## SECRET-DATA
start-time 2011-01-01.06:00:00;
key l {
secret "$9$cHArK8-VYZUHX7UHqmF3Sre"; ## SECRET-DATA
start-time 2011-07-01.06:00:00;

BGP Load Balancing
• Default load balancing

• For IBGP. BGP uses per prefix load balancing
• If multiple prefixes received from the same preferred peer and IGP
ECMP exists to the peer
• For EBGP. BGP algorithm selects exactly one active path (no
load balancing)
• Multihop can be used with EBGP
• Establishes sessions with peers that are more than one hop
away
• Required for loopback EBGP peering
• Over-one-session per prefix balancing. similar to IBGP with IGP
ECMP
• Multipath is used mostly with EBGP for load balancing
• Over-many-sessions per prefix balancing (Up to 16 paths)
�,-.;;�1:
Wort��eEducatlonServices ww.v,un,po,net 1 6-13
Default BGP Load Balancing

For IBGP, if a BGP peer receives more than one copy of the same route from several neighbors, the
BGP algorithm always selects only one best route. For IBGP, if a preferred neighbor advertises more
than one prefix and the path to the preferred neighbor uses IGP with equal-cost multipath (ECMP),
then the Junes OS uses per-prefix load-balancing.
For EBGP, each session is usually associated with one physical path to the neighbor, so for the
EBGP-received prefixes, the algorithm selects only one best path associated with only one physical
next hop for each of the routes.
Load Balancing with Multihop

You might be asked to take advantage of having more than one physical connections between two
EBGP peers. Such a setup provides redundancy as well as the ability to load-balance traffic over
several physical links. To implement the balancing with multihop, you must establish a multihop
EBGP session. Recall that the default IP TIL for EBGP sessions is 1, so explicit multihop
configuration is required. You can adjust the TIL value in the multihop configuration, which by
default is 64. Once the multihop EBGP session is established, when BGP receives updates from an
EBGP neighbor, the BGP next-hop evaluation reveals more than one physical next hop, so BGP
selects among them in the per-prefix manner.

Load Balancing with Multipath (contd.)

Multipath is another way of load-balancing with EBGP. In contrast to multihop, multipath is a
balancing over many sessions. In other words, when a BGP speaker has more than one EBGP
session with a neighboring AS with multipath enabled, the speaker does not compare the router ID
and peer IP address in the BGP route selection algorithm. So, when the same prefix is received from
one of the neighbors configured with multipath, and this prefix is equal from the BGP route selection
algorithm view up to the step comparing router ID, BGP selects one of the updates in a
pseudo-random fashion. If multiple prefixes exist, they are balanced among the sessions and the
corresponding physical next hops in the per-prefix manner.
Note that in both multihop and multipath load-balancing, the balancing type is per-prefix, hence the
kernel puts only one physical next hop for a prefix into the forwarding table. You can extend the
balancing by configuring per-flow load-balancing that makes the kernel list all the physical next hops
in the forwarding table.

IBGP Scaling Using Route Reflection
• Route reflection notes

• Defined in RFC 4456
• Allows route reflector to re-advertise IBGP-learned route to
another IBGP speaker
• RR does not change existing BGP attributes
• Adds two extra BG P attributes to prevent loops
- Cluster list
- Originator ID
• IBGP peers of an RR are divided into two groups:
• Clients
• Non-clients
'.
IBGP Scaling Using Route Reflection

Route reflection network solves the full-mesh IBGP problem by allowing IBGP-learned routes to be
re-advertised to IBGP peers. This re-advertisement is allowed only on route reflectors (RR). Together,
the RR and its peers, called clients, form a cluster. RR does not change any of the BGP attributes and
adds two additional ones: cluster list and originator that are used to prevent loops. Usually in an ISP
environment, the RRs are redundant to protect clients from isolation in case of link failure or router
failure.
In the exam, you might be asked to design your network with route reflection given certain
constraints such as the amount of clusters, the amount of RRs, or the amount of clients within a
single cluster.
From an RR perspective, all the peering sessions fall into one of three categories: client IBGP
sessions, non-client IBGP sessions, and EBGP sessions. Reflectors re-advertise updates that they
receive from clients to other clients, non-clients, and EBGP peers. Reflectors re-advertise updates
received from non-clients to clients and EBGP peers but not to other non-clients. Note that because
of this activity, RRs must be fully meshed.
Clients within a cluster can be fully meshed as well. You can reduce the amount of advertisements
within a cluster where clients are fully meshed by configuring an RR with no-client-reflect knob.
In a redundant cluster with more than one route reflector, the RRs can be either clients or non-clients
to each other. You can configure them both ways in the exam.

IBGP Scaling Using Confederations
• Confederation notes
• Defined in RFC 3065
• Breaks an AS (confederation) into multiple sub-ASs
• Within each sub-AS:
• Use a private AS number
• An I BG P full-mesh topology is required
• Between sub-ASs:
• EBGP-type(CBGP) sessions are required
• Only the AS path attribute is changed
- Prevents loops in t11e network
- Sub-AS numbers are not used when comparing AS path
lengths
• Other BG P attributes are not modified by default
� "''jl!Jffil�� Worldwide EducationServices '""'" Jun,p er net 1 6·16

r -Jx"'":.. •=4
IBGP Scaling Using Confederations

Confederation network is another approach to solving the full-mesh IBGP problem. The
confederation concept is breaking up the network into smaller pieces named sub-ASs. The
connectivity between sub-ASs is maintained using EBGP-type sessions, referred to as confederation
BGP (CBGP) sessions. CBGP peers add their sub-AS number to the AS path, which is used to prevent
loops. When routes are advertised out of the confederation, the ASBRs remove the sub-AS numbers
from the AS_PATH attribute. Other BGP attributes are not modified over the CBGP sessions.
Recall that the sub-AS numbers are not used by BGP route selection algorithm when comparing
AS path lengths.
In the exam, you might be asked to configure a confederation network, providing redundancy to
ensure that none of the routers in the confederation become isolated in case of a single link or
router failure. This requirement forces you to carefully design your network, for instance, with each of
the sub-AS islands connected to other sub-ASs with at least two peering sessions.
To configure confederation, you must specify a router AS as the sub-AS and configure the
confederation by using the confederation keyword with all the sub-ASs listed as members of the
confederation. The CBGP sessions are configured as EBGP sessions. However, CBGP can utilize the
redundant paths of an IGP, similar to IBGP sessions. Normally, you might want to configure the CBGP
sessions with the local-address loopback. Note also that because the CBGP sessions are external,
you must configure multihop.

BGP Implementation Time-Savers
• Before you begin configuring:

• Read all tasks in the section carefully
• Plan your strategy for all tasks
• Resist the keyboard
• Draw out the RR or confederation topology on a map
• Keep in mind requirements for redundant connectivity
• Decompose the 1Pv4 and 1Pv6 tasks
• Think of efficient grouping of BGP peers
• Global. group. or neighbor
• Simplify configuration steps
• Cut and paste commands using the command
show I display set
• Copy and paste with an offline text editor
,�.x��- ��'J'""'
!• JUril!mf�orldwideEducationServices .,,,�,unrpernet 1 6·17

? } "",,., s -
Time-Saving Tips
Read the entire exam, and each scenario task carefully before starting the configurations for the
given scenario to avoid making unnecessary mistakes and having to redo tasks. If you plan well, you
can complete all tasks in the scenario more efficiently, avoiding mistakes.
Using the topology maps provided, or alternatively redrawing the topology and planning the route
reflection or confederation design will make it easier to ensure that the design meets all the exam
criteria in terms of redundancy and so on.
You can consider decomposing the tasks into 1Pv4 and 1Pv6 tasks. For instance, you can configure
your 6PE application as a standalone task. Be careful to properly integrate the tasks.
The Ju nos OS BGP implementation mandates the use of BGP groups for all neighbors. Carefully
consider the efficient grouping of neighbors to apply your policies in more logical manner. Think in
terms of policies.
Consider reusing configurations when possible, using copy and paste. Efficient use of an off-line text
editor such as Notepad can speed up these tasks significantly. Remember that the Ju nos OS has
multiple ways of achieving copy and paste. Take time to explore the benefits of using these different
tools.


• BGP Configuration and lmplen,entation
�BGP Routing Policy
''JUnlPefii,Worldwide
T lC:�� ;tj :.
Education Services '""'� Juniper nel J 6 18
-
'4
BGP Routing Policy

The slide shows the topic we cover next.

Attribute Manipulation with Policy
• You can change any of these BGP attributes with a

routing policy then action:
• Next hop
• Local preference
• Origin
•MED
• AS path
• Cornrnunity
��...
Wof!��e E�ucation Services ww" ,uniper net 1 6-19
Attribute Manipulation with Policy

The Junos OS routing policy language provides a flexible framework for modifying any of the
attributes listed on the slide.

Modifying BGP Attributes
• Reasons for modifying BGP attributes:

• Setting next hop to self can resolve hidden EBGP routes for
other IBGP neighbors
• Changing local preference can influence AS outbound traffic
• Changing origin can negatively influence routing decisions
• Setting MED can influence the AS inbound traffic when the
local AS has multiple links with a neighboring AS
• Prepending or expanding AS number can negatively
influence the AS inbound traffic
Modifying BGP Attributes

Because the default BGP behavior is to leave the BGP next-hop unchanged when re-advertising and
EBGP learned destination to IBGP neighbors, and in the event that this prefix is not reachable within
the AS, routing policy to modify the BGP next-hop will often be used to avoid routes being hidden on
other routers in the same AS. The IP address used will be the address used for the IBGP session.
Use of the Local Preference attribute is commonplace in Service Provider policy deployment, and is
used to determine the exit point from the local AS. The Local Preference attribute cannot be sent to
EBGP neighbors, however is maintained when advertising to CBGP neighbors.
The default value of the Origin attribute is IGP, which is the strongest value. This can be changed in
routing policy to negatively bias the advertisement from the local router in most cases. An interesting
note regarding the Origin attribute is that it can be changed in an export policy to other BGP
speakers, but can also be applied in an import policy to change the local routers perspective on a
better/worse path for the respective destinations.
The MED attribute will most commonly be used to affect the inbound traffic from a neighboring AS
when there are multiple links between the two ASs. Similarly to Origin changing the MED is by default
a negative bias mechanism.
AS path prepending (local AS) or expanding (previous AS) is used to negatively bias the advertised
prefixes.

Attribute Manipulation without Policy
• You can change some BGP attributes by applying

settings directly to BGP protocol, group, or neighbor
level
•as-override (ASpath)
•remove-private(ASpa�)
• metric-out (MED)
•local-preference (local preference)
Attribute Manipulation without Policy

In some circumstances, it might be simpler to apply changes to attributes without requiring policies.
This affects all destinations equally, and of course does not provide the flexibility of the Junos OS
routing policy language.
The as-override option is most commonly used in the Layer 3 VPN environment when the
customer's AS number is the same for different sites in a VPN to avoid the inevitable BGP path loop
detection mechanism.
When private AS numbers are used, they should not be advertised outside of the service provider's
network, and using the remove-private configuration parameter results in any 2-byte AS
numbers in the 64512 through 65534 range being stripped off the AS path attribute.
The metric-out can be configured at the global, group, or neighbor level to affect the MED value
advertised, but can also be parameterised with a value, or derive the value advertised from the IGP
metric. In the event that topological changes result in this value constantly changing, the
minimum-igp parameter is recommended.
Similarly, the local-preference value can be configured globally, at the group level, or for
individual neighbors. Note that this parameter applied to EBGP neighbors will set the local
preference on imported routes before putting the routes into the routing table.

Community Types
• Regular community
• 2-byte-as-number:assigned-number (65003: 1111)
• Well-known communities
• no-export (OxFFFFFFO 1)
• no-advertise (OxFFFFFF02)
• no-export-subconfed (OxFFFFFF03)
• Extended community
• type:administrator:assigned-number
• 2-byte AS specific
• 4-byte AS specific
• 1Pv4 address specific
• I Pv6 address specific
,• JUr:llPen;,.. Worldwide Education Services ww• )un,per nel I 6·22

:......,�,M'!,, '/i(J�A
Regular Community
Regular communities are 32-bit long communities divided into two main sections: first 16 bits to
encode an AS number, last 16 bits to encode a unique number assigned by the AS. Three community
attribute values are designated as well-known communities. The three communities are no-export,
no-advertise, and no-export-subconfed. No-export is used to limit a route propagation scope to a
neighboring AS only. Similarly, no-export-subconfed is used to limit a route propagation scope to a
neighboring sub-AS only. No-advertise is the strictest one, which limits a route propagation scope to
a neighboring router only.
Extended Community
Because regular communities do not provide enough expansion for services such as VPN, Extended
community are used. An extended community is an 8-bytes value divided into two main sections: a
2-bytes type field and a 6-bytes unique set of data in a format defined by the type field. Different
types of extended communities exist, such as 2-byte AS specific, 4-byte AS specific, 1Pv4 address
specific, 1Pv6 address specific communities.

Community Tag and Removal
• You can set, add, and delete communities with a

policy then action
• set overrides the community list with a new list
• add adds a new community list to the existing list
• delete removes communities matching configured pattern
from the existing list
• You can use regex in the community definition
:]\"W.
�on�" WorldwideEducationServices WW�Jun,pernet J 6·23
Community Tag and Removal

The Ju nos OS policy then clause allows multiple actions for the community setting. To overwrite the
community results in all other previously set communities, use the set action. If the desired result is
to not affect other communities, use the add action. To remove all or some communities, use the
delete action in combination with the flexible regular expressions (regex).

Using Regular Expressions
• Using regex simplifies tasks and outputs

• Implement in AS path matching policies
• Definet11e as-path o pti on wi th the regex criteria
• Use the defined as-pa th in a po licy
• Utilize in community matching policies
• Use simple or complex regex definitions
• Use with show commands
• Simplifies o utputs based on the regex definiti on
Using Regex
Regex offer powerful pattern matching capabilities. You can use regex with both AS path and
community BGP attributes in routing policy. The regex format is tenn operator, where the term
represents an AS number in AS path regular expressions.
There are two steps to using the as-path option in the Junos OS routing policy language. The first
involves the definition of the actual regular expressions, which in turn are referenced by a user
defined name.
You can use regular expression with BGP communities to find communities that match a given
pattern. Similarly to the AS path regex discussed, community use in routing policy follows the same
format, requiring the community to first be defined and then referenced in the routing policy. There is
one difference with communities compared to aspath-regex. in that where aspath-regex typically only
gets used as a match condition in a policy, a community not only can be used as a match condition
but also in the action part of a term or policy to either set the community, add the community or
delete the community.
It should be noted that when multiple community definitions are listed in the FROM statement, this
list is evaluated as a logical OR for match purposes. However. listing multiple communities when
defining them results in logical AND functionality.

Using Regex (contd.)

Two forms of regular expressions can be used with communities: simple and complex. Simple
community regex can contain only asterisk"*" or dot"." wildcard characters. The asterisk matches
any single value and the dot matches any single digit.
You can also use complex regular expressions with communities. The complex regex format is tenn
operator. A community regex is character based, unlike the regular expressions used with AS
paths, which match entire AS numbers.
The Junos CLI allows for matching routes that have the respective community by using the
community regex or using the name of a regex configured on the local router.
The CLI show route aspath-regex command is also extremely useful troubleshooting tool and
helpful to quicken your verification steps through the exam
Below is a list of some common regex operators and their definitions.
[m) Matches exactly m instances of the term
{m.J Matches m or more instances of the term
[m,n) Matches at least m and at most n instances of the term
* Matches O or more instances of the term
+ Matches one or more instances of the term
? Matches O or 1 instances of the term
I Matches one of the two terms on either side of the pipe symbol
- Matches an inclusive range of terms
() Matches a null value as a term
[] Matches a range or an array of digits

Remote Triggered Black Hole Concept
• RTBH is a technique for the mitigation of Dos attacks

(RFC 5635)
• Used by ISPs to protect their customers
• Firewall filters (ACLs) can do the same
• But RTBH is more efficient
• Two types of RTBH:
• Destination-based filtering
• Source-based filtering
• Works in combination with unicast RPF
• More flexible than destination-based filtering
Remote Triggered Black Hole Concept

Remote Triggered Black Hole (RTBH) is a technique for the mitigation of denial of service (DoS)
attacks normally used by ISPs to protect their customers. RTBH is based on triggered advertisement
of a route with discard next hop upon detection of DoS attack. This technique allows the DoS traffic
to be discarded.
RTBH filtering is more efficient than firewall filters because routers can forward traffic at a much
higher rate than they can filter with firewall filters.
Two types of RTBH exist: destination-based and source-based.
The destination-based RTBH sets the discard route for the address range of a customer
being attacked. All packets towards this range are dropped.
The source-based RTBH works in combination with unicast RPF. It sets the discard route
for the address ranges where Dos packets are originated. These packets do not pass
the unicast RPF check and are dropped. The source-based RTBH can selectively drop
packets directed to a customer being attacked.

RTBH Sample Topology
AS200 AS300
route 0, NH = discard
Policy
from community RTBH _I/
then NH= 0 uRPF
/1' R2
AS65000
- _____,,,.,,
OoS attack reported
R3
AS100
Customer
..
Lll!.lfi11Pe'"/w-;;'r1t1wide
�:, Education Services "'"'" JUOIP" net I 6-27
RTBH Sample Topology

The slide shows a sample network topology for Remote Triggered Black Hole discussions_ To
implement the RTBH, you must configure several steps:
Configure a trigger router that will generate triggered updates in case of Dos attack
detection. Make sure that the triggered updates will not leave the local AS_
Configure a BGP policy on ASBR so that triggered updates with a chosen community will
have their next hop set to the discard_
If source-based filtering is used, configure unicast RPF on the ASBR's external
interfaces_
www_juniper.net BGP Implementation • Chapter 6-27

TBH Example Configuration (1 of 2)
• Trigger router
[edit couting-options] [edi t policy-option s]
usec@R3# show usec@R3# show
static { ipolicy-statement TRIGGERi{
coute 10.100.1.1/32 teem 1 {
tag 666; from (
ceject; pcotocol static;
tag 666;
then {
local-pcefecence 200;
[edit pcotocols bgp]
usec@R3# show
jcommun1.ty se� RTBH; I
community ad no-expoct;
gcoup IBGP { accept;
type internal;
local-add cess 192.168.100.3;
!expoct TRIGGER; I
neighboc 192.168.100.10; community RTBH membecs 100:666;
community no-expoct membecs no-expoct;
Q �)!Jf;J -- ;;w;;ldwldeEducationServices wwwµ,n,pe,ne< 1 6·28

;.;;.,..,,.,';,.
RTBH Trigger Router Example Configuration

The slide shows a trigger router example configuration. The key point in the configuration is using a
special community defined for RTBH application 100:666. Upon detection of a DoS attack, the
trigger router will advertise a route that has to be black-holed to ASBRs.

RTBH xample Configuration (2 of 2)
• Filtering router [edit interfaces ge-0/0/1]

user@Rl# ,:how
[edit ro uting-options] unit O {
user@Rl# ,:how family inet
foniarding-table { rpf-check;
unicast-reverse-path feasible-paths; address 10.11. 12 .1/2 4;
[edit policy-options]
user@Rl# ,:how
[edit protocols bgp] I pohcy-statement ELACR H6LE fIL!ER jl
user@Rl# ,:how fcom {
group IBGP { protocol bgp;
type inte ma l; as-path LOCP..L-P..S;
local-address 192.168.100.1; community RTBH;
!import BLACK-HOLE-FILTER;!
neighbor 192.168.100.10; then {
next-hop discard;
community RTBH members 100:666;

as-path LOCAL-AS " () ";
-
Worldwide Education Services WW� JUnrpo, net I 6-29
1�1�
RTBH Filtering Router Example Configuration

The slide shows a filtering router (usually an ASBR) example configuration. The filtering router
applies an import policy that sets the next hop to discard for the routes tagged with RTBH
community.

BGP Policy Pitfalls
• Policy creation
• Term order is important
• Understand the default BG P routing policy
• Applying policies
• Ensure you apply the policy
• Directionality is important
• Import or export
• Policy application order is important
Policy Creation
When creating your policies it is very important to consider the order of your terms. As you are aware,
a route can only be accepted or rejected once. If you are not careful you might accept or reject a
route before you get to the term that you created to address this route. Make sure you are aware of
the BGP default policy and which routes are accepted and rejected.
Applying Policies
Make sure you apply the policies you create. It seems very obvious, but it is easily overlooked when
configuring multiple routers and multiple policies. You must also make sure you apply the policy
correctly as an import or export policy. It is also important to keep in mind that the order of your
policies being applied is very important.

BGP Policy Time-Savers

• Read all tasks in the section carefully
• Plan your strategy for all policy tasks
• Resist the keyboard
• Identify tasks that can be combined into a single policy
• Identify whicl1 policies need to be applied on each router
• Reuse policies when possible
• Cut and paste commands using the show I display set
command
• Copy and paste with an offline text editor
�q�/�
uunm::,;:;'o ��deEducatlonServices WW�Jun,pe,net I 6·31
Policy Time-Savers
As mentioned before, read the entire exam, and each scenario task carefully before starting the
configurations for the given scenario to avoid making unnecessary mistakes and having to redo
tasks. If you plan well, you can complete all policy tasks in the exam more efficiently, avoiding costly
mistakes.
Do not just start configuring your policies. Strategically plan which tasks can be combined into a
single policy using separate terms. It might be a good idea to outline which tasks apply to each router
so you know what policies need to be created as you move from router to router during the exam.
Many routers require the same policies. To save crucial time, reuse as many policies and terms that
you can by using some method of copy and paste.

• BGP Configuration and Implementation

• BGP Routing Policy
i
".
't 0sr, @'" ""{M tP{\t �
:)Ufi'l� WorldwideEducationServices wa•Jun,pernet 1 6·32
-,2ci,>Ji -

The slide shows the topic we cover next.

Task and Topology

Core BG.f' Network
AS200
Loop backs Pl----�Rl
Rl - 192.168.1.1
Provider
AS100 0 � �"
,r.,1
�----1c°w'
�Customer-1
AS 700
I�I'
R2 - 192.168.1.2 150150 0/16 2
2002000/16
R3 - 192.168.1.3
R4 - 192.168.1.4
Transit-1 ��3 R4�/

AS500 W
1001000/16
• Task:
• Routes received from the Provider router should not be
advertised to the Transit-1 router or vice versa.


What Now?
• Connectivity
• IBGP neighbors must be established
• EBGP neighbors must be established
• IBGP core must be learning routes from EBGP neighbors
• External routes must be active in IBGP core
• Next hop self policy or external interface in IGP passive
• Unique community must be created for all external peers
• Import policies must be created and applied to tag each
external peer's routes with a unique community
• Export policy must be applied to the appropriate EBGP
peering to reject routes tagged with the defined community
�LlUG'l!EeJ:� '&o;!dwide Education Services
� =��{0.l0i!"" =-='t,y "*,.tti �
ww� Jun,p er n•l 1 6·34

.6- -
What Is Really Being Asked?

The slide illustrates the required steps to accomplish the sample task.

• Step 1: Initial neighborship verification

• Verify connectivity R1
lab@Rl> show bgp summary
Groups: 2 Peers: 4 Down peers: 0
Table Tot Paths Act Paths Suppr:essed Histor:y Damp State Pending
inet.O 30 30 0 0 0 0
inet6.0 0 0 0 0
Peer AS In Pkt Out Pkt OutQ Flaps Last Up/Dwn
Statel#Active/Received/Accepted/Damped ...
172.27.0.30 100 280 283 2:06:39 10/10/10/0
0/0/0/0
192.168 .1.2 200 406 406 3:02:54 10/10/10/0
0/0/ 0/0
192. 168 .1. 3 200 385 385 2:53:17 10/10/10/0
0/0/ 0/0
192.168.1.4 200 369 368 2:46:06 0/0/0/0
0/0/0/0 /1.0
-- ·-�o,�-�-
�Ur.ll�'f''WortdwideEducationServices wwwJun,pornet 1 6·35
bl: �k=="
Verifying BGP Neighborships

Before you start configuring it is important to verify the baseline for the task. You must verify that you
at least have BGP neighbors, both internal and external neighborships. As the slide illustrates, R1
has three internal neighbors and one external neighbor. These neighbors are consistent with the
topology. You may also not that we are learning routes from three of the four neighbors.

• Step 2: Route verification

• Verify external routes on R1
inet.O: 48 destinations, 48 routes (48 active, 0 holddown, 0 hidden)

100.100.0.0/24 *[BGP/170) 02:04:05, localpref 100, !from 192.168.l.3 i

IAS path: 500 I j
> to 1.72.27.0.1.3 via ge-0/0/6.0
inet.0: 48 destinations, -48 coutes (48 active, 0 holddown, 0 hidden)

1.50.1.50 .0. 0/24 • (BGP 170 02: 1.2: 30, localp,·ef 1.00
AS ath: 100 I
> to 1.72.27.0.30 via ge-0/0/1.0

+ � Active Route, - = Last Active, * = Both
200.200 .o.0/24 *[BGP 170 02:09:23, localpref 100,lfrom 192.168.1.21

AS ath: 700 I
> to 1.72.27.0.2 via ge-0/0/3.0
HLJfllPec:� Worldwide Education Services """"-Jun,pernet I 6-36

'J �"' ..;,;,_.;_� ,>
Route Verification
The slide outputs show that there are routes present from each of the external network in Rl's
routing table. This output indicates that we are receiving routes from the external peers. It also
indicates that the next hops for the external routes are being altered within the IBGP network.

• Step 3: Define communities

• Configure communities on R1
lab@Rl# set comnn..m.ity p-:rout;es members,200:150,
lab@Rl# set commu.n.ity c1-:rout;es members,200:7001
le.b@Rl# set community t1-rout;es members,200:5001
• Define the same communities on the other two ASBR

routers (R2 and R3)
• To save time use copy and past to simplify this task
Define the Communities

Define the communities that will be used to differentiate the routes. In our example network we have
separate unique networks to assist with illustrating the behavior. With unique individual network
routes you could easily match on the prefix range and block the routes that way. In the exam you
could see overlapping networks as well as duplicate routes from multiple peers, so we are using
community tags.
It is recommended that you use the same community names throughout your IBGP core to avoid
confusion. This task is a prime example where copy and paste can save you some time.

• Step 4: Define import policies

• Configure import policy on R1
[edit policy-optionslpolicy-statement from-P]I
lab@Rl.# set term.:! :from neighhor 112.2/.0.30
[edit polic -o tions olic· - statement from-P

lab@Rl# set term .:! then comnn.urity add �
[edit policy-options policy-statement from-P]

lab@Rl# set term .:! then accept
[edit policy-options policy-statement fr-om-P)

lab@Rl# show
term 1 {
fr-om n eighbor 172.27.0.30;
then {
corrununity add p- routes;
accept;
• Create similar import policies on the other two ASBR routers

(R2 and R3) to tag the incoming routes
"i � � filt.iiijj> �%xjf&«'"$ s

, Alt{ightrn.. .,.d. •LJL:Jlil� 1WorldWideEducallonServices wwwJun,pernel 1 6-36
Se -..�o-,;. """'""L,a..,.,,
Configure Import Policies

The next step is to create import policy. Creating the import policy to accomplish this task is simple,
but can become complicated when you add additional constraints to incoming routes. Be sure to
account for policy evaluation rules when you are configuring a policy with multiple terms.
As the output indicates, the routes learned from the Provider peer are being tagged with the
p-routes community that was defined in the previous step.
Though not shown here, you must also define similar import policies on the other two ASBR routers.

• Step 5: Define export policies

• Configure an export policy on R1 to reject Transit-1 routes
[edit policy-opt.i.on:::1lpolicy-statement to-P]
lab@Rl# set term � :from proEocol bgp
I
(edit polic -o tions olic -statement to-P
lab@Rl# set term � from conununity t:1-routes
[edit policy-opt.i ons policy-statement to-PJ

lab@Rl# set term l; then reject
[edit policy-options policy-statement to-PJ

lab@Rl# show
term 1 (
fi::om {
protocol bgp;
community tl-routes;
then reject;
• Create a similar export policies on R3 to reject Provider

routes
Configure Export Policies

Next, you should define the export policy. The export policy should block routes learned from the
Transit-1 router from being advertised to the Provider router. This slide provides an example of the
steps to create this policy.
Though not shown here you must also create a similar policy on R3 to block routes learned from the
Provider router from being advertised to the Transit-1 router.

• Step 6: Apply import and export policies to the EBGP

sessions
• Apply the export and import policy on R1
[edit protocol::i bgp}
lab@Rl# set group Provider imp ort L:rom-P
[edit pr-otocol5 bgp]

lab@Rl# set group Provider export t:.o-P

lab@Rl# show group Provider
t e external·
impor.t from-P;
export to-P;
peer-as ;
neighbor 172. 27. 0. 30;
• Apply the import policies to the other two ASBR·s EBG P

sessions
• Remember to apply the export policy on R3's EBGP session
to the Transit-1 router
--#r>;Ust'"' *
LJUlil� Worldwide Education Services """'Jun,pernet I 6-40
� h ... "
Apply Import and Export Policies

The final configuration step is applying the import and export policies to the appropriate EBGP
sessions. Remember to be careful with directionality when applying the policies.
Make sure you also apply to import and export policies on the other ASBRs where applicable.

• Export policy verification on R1 to Provider
lab@Rl> show route advertising-protocol bgp 172.27.0 .30
inet.0: 48 destinations, 48 coutes (48 active, 0 holddown, 0 hidden)

Pcefix Nexthop MED Lclpcef AS ath
* 200.200.0.0/24 Self 700 I
* 200.200.1.0/24 Self 700 I
* 200.200.2.0/24 Self 700
* 200.200.3.0/24 Self 700
* 200.200.4.0/24 Self ·700 I
* 200.200.5.0/24 Self 700 I
* 200.200.6.0/24 Self 700
* 200.200. 7.0/24 Self 700 I
* 200.200.8.0/24 Self 700 I
* 200.200.9.0/24 Self 700 I
-·�·-
�l:Jnffl ,,wo�dwideEducationServices ww..,,un,p..n,t J 641
)M;lJ,a==
Verify Exported Routes on R1

There are many ways to verify this task. The example on the slide is one method. You can see that we
are not advertising any of the 100.100.0/16 routes to the Provider peer. The slide also highlights the
AS paths indicating all routes originated in the Customer-1 AS.

• Export policy verification on R3 to Transit-1
lab@R3> show route advertising-protocol bgp 172.27.0 .58
inet.O: 47 destinations, 47 routes (47 active, 0 holddown, O hidden)

Prefix Nexthop MED Lclpref AS ath
* 200.200.0.0/24 Self 700 I
* 200.200.1.0/24 Self 700
* 200.200.2.0/24 Self 700
* 200.200.3.0/24 Self 700 I
* 200.200. 4.0/24 Self 700 I
* 200.200.5.0/24 Self 700 I
* 200.200.6.0/24 Self 700 I
* zoo.zoo. 7.0/24 Self 700 I
* 200.200.8.0/24 Self 700 I
200.200.9.0/24 Self 700 I
=--=-�"
UUfi'lJ.fz,�fL \A{llr!!fwicle EducalionSe111lces www Jun,per net 1 6 ·42
�k.;';,.,��,.,
Verify Exported Routes on R1

The output on the slide is from the perspective of R3. During the verification phase of your exam, you
should make sure you accomplished the entire task. You can see that we are not advertising any of
the 150.150.0/16 routes to the Provider peer. The slide also highlights the AS paths indicating all
routes originated in the Customer-1 AS.

Summary
• Described IBGP and EBGP advanced topics
• Implemented complex routing policy with 1Pv4 and 1Pv6
, �!:Jfil�,{ W,�rtdwide Education Services ww,viun,pern,t I s 43

f""�-

IBGP and EBGP implementation advanced topics; and
Complex BGP routing policy with 1Pv4 and 1Pv6.

Lab 6: BGP lmplemen ation
• Implement a IBGP core using route reflectors.

• Establish EBGP peerings with external neighbors.
• Apply policies to control routes based on task
restrictions.
• Implement a IBGP core using confederations.

have 2.5 hours to complete this lab.
JUfil�,: Worl�ide Education Services ..,.� lun,per net 1 6-44

�hi.-
Lab 6: BGP Implementation


Junt�j�r
Chapter 7: BGP Troubleshooting

Chapter Objectives

able to:
• Discuss and troubleshoot BGP peering problems with
rnisconfigured peering
• Describe and troubleshoot connectivity caused by routing
policy or fixed by routing policy
• Explain and troubleshoot rnisconfigured BGP settings
;t, -�
l:J(;llDt=lfi. Worldwide Education Services www Jun.pernet 7-2
J
�f ,1��

The troubleshooting of BGP peering problems with misconfigured peering;
The troubleshooting of connectivity issues caused by routing policy; and
The troubleshooting of misconfigured BGP settings.
Chapter 7-2 • BGP Troubleshooting www.juniper.net

Agenda: BGP Troubleshooting
�BGP Troubleshooting with the Junos CLI Tools

• Time-Saving Tips
__ _.,,.,� 1�,� -,-

I
�Ufil� W�rlilwideEducationServices wwwJun,pernet 1 7·3
ill �-�� 1
BGP Troubleshooting with the Junos CLI Tools

www.juniper.net BGP Troubleshooting • Chapter 7 -3

BGP Peering Problems
• Common sources of BGP peering problems

• Connectivity issues
• BGP misconfiguration
• Authentication mismatch
• Firewall filters
• Hardware and software problems are not expected ,n
the exam
,, .
Common Sources of BGP Peering Problems
BGP rides on top of TCP/IP, hence TCP/IP connectivity is crucial in BGP operations. If a BGP session
does not come up the first thing, you should check whether two peers can reach each other using
the session IP address.
If IP reachability is verified, then BGP misconfiguration can lead to the BGP session-stays in Active
or Connect state.
If authentication is configured, an mismatched key will disrupt TCP and so BGP communication.
And last. but not least , incorrectly configured firewall filters blocking BGP TCP port 179 prevent BGP
communication as well.
Hardware and Software Problems

No hardware or software problems are intentionally introduced In the exam. Nevertheless, if you
suspect that the problem is related to hardware or software. notify your proctor immediately.
Chapter 7 -4 • BGP Troubleshooting www.juniper.net

Troubleshooting BGP Peering Problems
• Monitoring BGP-where to start

lab@Rl> show bgp smnmary
Groups: 3 Peers: 3 Do'iNI1 peers: 2
•rable Tot Paths .A.ct Paths Suppressed History Damp State Pending
inet. 0 889 889 0 0 0 0
inet6.0
Peer AS In Pkt Out Pkt OutQ Flaps Last Up/ Own State I
172.27.255.4 3895077211 417 7 0 1 1: 54 889/889/889/0
172.27.255.7 3895077211 0 20:16 Active
20 1.201. 0.1 2087403078 0 13 Idle
• A session stays in Idle state

• BG P cannot even attempt to establish U"le session
• A session bounces between Connect and Active states
• BG P tries to initiate a TCP session or waits for the session to be
initiated by a peer
Monitoring BGP Sessions

To start BGP monitoring, use the show bgp surrunary command. The example on the slide shows
two BGP sessions that stay down: one is in Idle state and another is in Active state.
If a session stays in Idle state, BGP cannot try to establish the session. Possible reasons can be IP
address allocation or TIL on multihop EBGP session.
If a session stays in Active or Connect state, bidirectional BGP communication is not successful.
Numerous reasons can make BGP bounce in these states. Among them are IP reachability, BGP
parameters misconfiguration, authentication, and firewall filters.

BGP Peering Troubles.hooting Checklist
• Verify IP connectivity between BGP peers

• Check the configuration parameters
• Peer and local AS number
• Peer and local IP address
• Check the authentication settings
• Consider temporarily disabling the authentication
• Monitor the syslog file for BGP related messages
• Do firewall filters block the TCP port 179?
• Does the problem still exist?
• Use lraceoptions
IP Connectivity Between two Peers

To verify IP connectivity using the session IP address, use ping utility:
lab@Rl> ping 172.27.255.3 source 172.27.255.1
If the ping fails, check IP routing:
lab@Rl> show route 172.27.255.3
Check BGP Configuration Parameters

Verify the parameter settings using the show protocols bgp group command:
[edit]
lab@Rl# show protocols bgp group IBGP
type internal;
local-address 172.27.255.l;
authentication-key "$9$I56hyKX7V4aUM8aUjH5TRhS"; ## SECRET-DATA
export NHS;
neighbor 172.27.255.3;
neighbor 172.2'/.255.4;
Chapter 7 -6 • BGP Troubleshooting www.juniper.

net
Verify Authentication Settings
Check the authentication settings:
lab@Rl> show bgp neighbor 172.27.255.3
Peer: 172.27.255.3 AS 3895077211 Local: 172.27.255.1 AS 3895077211
Type: Internal State: Active Flags: <>
Last State: Idle Last Event: Start
Last Error: None
Export: [ NHS ]
Options: <Preference LocalAddress AuthKey LogUpDown AddressFamily Refresh>
Authentication key is configured
Address families configured: inet-unicast inet6-labeled-unicast
Local Address: 172.27.255.1 Holdtime: 90 Preference: 170
NLRI inet6-labeled-unicast: ExplicitNull
Number of flaps: 0
Consider temporarily disabling the authentication to eliminate the potential problem.
Monitor the sys log messages File

Syslog can provide an invaluable source of information for troubleshooting.
lab@R4> show log messages I match NOTIFICATION
Jul 29 00:05:29 R4 rpd[1068]: bgp_rt_maxprefixes_check_common:6856: NOTIFICATION
sent to 2008:4498:0:l::2 (External AS 65432): code 6 (Cease) subcode 1 (Maximum
Number of Prefixes Reached) AFI: 2 SAFI: 1 prefix limit 12
Jul 29 00:06:01 RI\ rpd[1068]: bgp__pp_recv:2961: NOTIFICATION sent to
2008:4498:0:1::2+64490 (proto): code 2 (Open Message Error) subcode 5
(authentication failure), Reason: no group for 2008:4498:0:1: :2+641\90 (proto)
from AS 65432 found (peer idled due to prefix-limit violation), dropping him
Check Firewall Filters

In the exam, you might be asked to configure firewall filters. Check the BGP session status after the
filters are implemented to make sure that the filters do not block BGP communication.
Use traceoptions
If you still cannot find the source of problem with BGP, use traceoptions to debug BGP sessions.
lab@R4> show log bgp-trace.log
Feb 11 12:52:31.750571 BGP RECV 201.201.0.1+179 -> 10.0.3.4+3291
Feb 11 12:52:31.750622 BGP RECV message type 1 (Open) length 45
Feb 11 12:52:31.750668 BGP RECV version 4 as 65011 holdtime 90 id 201.201.0.1 parmlen
16
Feb 11 12:52:31.750692 BGP RECV MP capability AFI=l, SAFI=l
Feb 11 12:52:31.750707 BGP RECV Refresh capability, code=128
Feb 11 12:52:31.750718 BGP RECV Refresh capability, code=2
Feb 11 12:52:31.751108 bgp__process_open: NOTIFICATION sent to 201.201.0.1 (External
AS 65010): code 2 (Open Message Error) subcode 2 (bad peer AS nwnber), Reason:
peer 201.201.0.1 (External AS 65010) claims 65011, 65010 configured
Feb 11 12:52:31.751156 bgp_send: sending 21 bytes to 201.201.0.1 (External AS 65010)
Feb 11 12:52:31.751175
Feb 11 12:52:31.751175 BGP SEND 10.0.3.4+3291 -> 201.201.0.1+179
Feb 11 12:52:31.751194 BGP SEND message type 3 (Notification) length 21
Feb ll l? .:52:31.751208 BGP SEND Notification code 2 (Open Message Error) subcode 2
(bad peer AS number)

EBGP Specifics
• Remember the EBGP differences

•multi hop is required for loopback peering
• peer-as configuration
• Troubleshooting can be more difficult because you
cannot usually check peer configuration
• Use traceoptions or traffic monitoring
EBGP Configuration Specifics

Recall that EBGP sessions take TIL value of 1 by default, hence for a loopback-to-loopback peering
session, mul t ihop configuration is mandatory.
Watch for mismatched peer AS configuration.
EBGP Troubleshooting Specifics

EBGP sessions are often harder to troubleshoot because you cannot usually look at the peer router
configuration. Use traceoptions if you cannot find a source of problem by checking your router
configuration. You can also monitor the control traffic using the monitor traffic interface
interface name command.

Route Reflection and Confederation

Specifics
• Route reflection
• The same IBGP sessions
• Note that RRs must be fully meshed
• Confederation
• CBGP sessions are EBGP-like sessions
• Check tl1at multi hop is configured for loopback peering
• Check that peer-as is set properly
• Check that local -address is configured for loopback peering
• Double-check the confederation settings in routing-options
� I -
��nlPer�•WorldwideEducationServices www,un,pm,t 1 7-9
...'!'�,:..-..�,,,-J,,,
Route Reflection Specifics

IBGP sessions in a network designed with route reflection are the same sessions used in regular full
mesh domain_ But note the route reflection specifics: Client routers must peer only with reflectors,
they can optionally peer with each other within the same cluster, and they must be fully meshed
within the same cluster if a reflector is configured with no-client--reflect_
In turn, route reflectors must be fully meshed with each other in addition to peering with clients in
the cluster.
Confederation Specifics
Be careful with CBGP sessions configuration. The sessions are EBGP-like sessions but they are
established within a single confederation AS, usually using loopback peering on top of underlying IGP
infrastructure. Watch out for mul tihop, peer--as and local-address settings. Double check
the confederation configuration in routing-options.
www.juniper.net BGP Troubleshooting • Chapter 7-9

Connectivity Problems
• BGP sessions are established successfully but hosts

cannot communicate
• Routing problems
• Policy misconfiguration
• Forwarding problems
• Firewall filters
• No hardware or software problems in the exam
BGP Routing Problems

The second category of BGP problems is routing problems. If a BGP session is established
successfully but routers or hosts cannot exchange with traffic, it can be related to either routing
issues or forwarding problems.
Most probably the connectivity problems are related to routing issues. BGP is the protocol by which
routing exchanges are completely controlled by an administrative policy. Hence, check your routing
policies.
Forwarding problems are either related to incorrectly applied firewall filters or physical hardware or
software problems. Note, though, that the exam contains no intentional hardware or software
problems.

Policy Misconfiguration
• BGP does not advertise any routes automatically at

the originating point
• Policy is required
• By default, BGP:
• Accepts all BGP routes if BGP next hop is reachable
• Advertises BG P routes that are both best and active
• Co nsiderusingadvertise-inactive if tl1e bestBGP route is
slladowed by a preferred IGP route
• A misconfigured policy can prevent routes from being

received or sent
-�""!!19""" I
1
WorldwldeEducatlonServices 'A'W,VJUnrp .. net I 7-11
' � ..L. ' I
Route Injection into BGP

Recall that BGP does not advertise routes automatically at the originating point. An administrative
policy is required to inject routes into BGP. If you do not see the expected routes in BGP
advertisements, watch for misconfigured policy.
BGP Policy Defaults

Remember BGP default policies. The default import policy accepts all routes if BGP can resolve the
received BGP next hop. The default export policy advertised the best and active BGP routes. If the
BGP route is shadowed by a preferred IGP route, it is set inactive and BGP stops advertising it. You
can use the advertise-inactive statement to make BGP advertise the best-but not active
BGP routes.

Policy Misconfiguration Results

A misconfigured policy can prevent routes from being received or sent. Watch for policy application
points: protocol, group, or neighbor. Recall that the more specific application overrides the less
specific ones. Use show route advertising protocol and show route
receive-protocol commands to verify BGP route exchanges.
lab@Rl> show route advertising-protocol bgp 172.27.0.34 172.27/16

Prefix Nexthop MED Lclpref AS path
* 172.27.0.0/16 Self
lab@R2> show route receive-protocol bgp 172.27.255.3 35/8
inet.0: 917 destinations, 2636 routes (912 active, 0 holddown, 1700 hidden)
* 35.0.0.0/8 172.27.0.34 100 1342930876 8918 237 I

Hidden Routes
• Routes are marked hidden and are not used if
• BGP cannot resolve BGP next hop
• Useshow route hidden
• Useshow route resolution unresolved
• Routes are filtered out by a policy, perhaps intentionally
• Useshow route hidden
Hidden Routes
BGP marks routes as hidden if it either cannot resolve the received BGP next hop or the routes are
filtered out with an import policy. Use the show route hidden command to check whether you
have any hidden routes.
lab@Rl> show route hidden

12.16.126.192/26 [l:lGP 10:17:45, localpref 100

AS path: 1342930876 8918 10578 14325 ?
> to 172.27.0.34 via ge-0/0/2.0
6S.114.168.192/26 [BGP J 10:17:45, localpref 100
AS path: 1342930876 8918 10886 7082 I
> to 172.27.0.34 via ge-0/0/2.0
Use the show route resolution unresolved command to check if any routes are hidden
because BGP cannot resolve their next hop.

BGP Next Hop

• BGP next hop must be reachable for BGP to accept an
update
• Both inet. 0 and inet. 3 (inet6. 0 and inet6. 3 for
1Pv6) tables are used to resolve BGP next hop
• Only inet. 3 (inet6. 3) are used with VPN and 6PE applications
• For IBGP. ensure that you use next-hop-self policy or IGP
passive on the external interface on the AS boundary router
• Watch for BGP next-hop-self on route reflectors
• St1ould be done on EBG P-learned routes only
• If BGP next hop is resolved using a BGP route
received in the same BGP update, the route is
marked hidden
BGP Next Hop

Recall that BGP next hop must be reachable in order BGP to accept and process an update. For
regular IP routing both inet. O and inet. 3 tables are consulted for BGP 1Pv4 next hop reachability
(inet6. O and inet6. 3 tables for BGP 1Pv6 next hop reachability). Note that in VPN scenarios and
6PE, only the tables populated by MPLS protocols-inet. 3 and inet6. 3-are used.
Recall that IBGP does not change BGP next hop by default. You must either apply a next-hop-self
policy or use IGP passive interface.
Watch for BGP next-hop-self policy on route reflectors. Make sure that reflectors only change the next
hop on EBGP-learned routes to avoid suboptimal routing.
BGP Next Hop Double Recursion Problem

Note that if BGP next hop is resolved using a route received in the same BGP update as the next hop,
the route is not used and marked as hidden. This situation can lead to race conditions where, to use
the route, the next hop must be resolved, and for the next hop to be resolved, the route must exist in
the routing table.
This situation can arise if the received route is the more specific one that router already has-for
example, if the router is located in the OSPF stub area.

IGP Routing Troubleshooting Checklist

(1 of 2)
• Is a BGP route in the routing table?

• Check that routes are advertised by a peer
• Does export policy allows them to be advertised?
• Check that routes are received
• Does import policy allows them to be received?
• Verify that routes are not hidden
• Is BG P next hop reachable?
• Does the problem still exist?

• Use traceoptions
� "'"' ��
--Ii.'*'
WorldwldeEducationSer.ices ww�Junipernet J 1-1s
Are BGP Routes in the Routing Table?

Check if BGP routes are put into the routing table.
lab@Rl> show route protocol bgp 35/8 exact

35.0.0.0/8 *[BGP/170] 3d 07:36:48, localpref 100

AS path: 1342930876 8918 237 I
> to 172.27.0.34 via ge-0/0/2.0

Are Routes Advertised By a Peer?

To verify that routes are advertised by the BGP peer, use the show route
advertising-protocol bgp command.
lab@Rl> show route advertising-protocol bgp 172.27.255.3 35/8

* 35.0.0.0/8 Self 100 1342930876 8918 237 I
If you do not see that routes are advertised and you expect them should be double check your export
policy.
Are Routes Being Received?

To verify that routes are received, use the show route receive-protocol bgp command.
lab@R3> show route receive-protocol bgp 172.27.255.1 35/8

* 35.0.0.0/8 172.27.255.1 100 1342930876 8918 237 I
If routes are advertised by a peer but are not received at the local router, check for hidden routes. If
a route is found in the list of hidden routes, ensure that the BGP next hop is reachable, otherwise if
the next hop is reachable but the route is hidden, double check your import policy.

Does the Problem Still Exist?
To further troubleshoot the issue, monitor the details of BGP exchanges using traceoptions.
lab@Rl� show group Tl
type external;
traceoptions {
file bgp-trace.log;
flag update detail;
import from-Tl;
export to-Tl;
peer-as 1342930876;
neighbor 177..27.0.34;
lab@Rl> show log bgp-trace.log I last

Aug 08:24:45.925733 BGP RECV 172.27.0.34+179 -> 172.2'/.0.33+53617
Aug 08:24:45.925753 BGP RECV message type 2 (Update) length 78
Aug 08:24:45.925769 BGP RECV Update PDU length 78
Aug 08:24:45.925784 BGP RECV flags Ox40 code Origin (1): IGP
Aug 08:24:45.925802 BGP RECV flags Ox40 code ASPath(2) length 6: 1342930876
Aug 08:24:45.925817 BGP RECV flags Ox90 code MP_reach(14): AFI/SAFI 2/1
Aug 1 08:7.4:45.925836 BGP RECV nhop ::172.27.0.34 len 32
Aug 1 08:24:45.925853 BGP RECV ::/0
Aug 08:24:45.926028 bgp_nexthop_sanity: peer 172.27.0.34 (External AS 1342930876)
next hop ::172.27.0.34 unexpectedly remote, ignoring routes in this update
Aug 1 08:24:45.926064 bgp_rcv_nlri: ::/0
Aug 08:24:45.926095
�ug 08:24:45.926095 BGP RECV 172.27.0.34+179 -> 172.27.0.33+53617
Aug 1 08:24:45.926114 BGP RECV message type 2 (Update) length 23
Aug 1 08:24:45.926129 BGP RECV End of RIB: AFI 1 SAFI 1
Aug 1 08:24:45.926162
Aug 08:24:45.926162 BGP RECV 172.27.0.34+179 -> 172.27.0.33+53617
Aug 08:24:45.926185 BGP RECV message type 2 (Update) length 30
Aug 08:24:45.926200 BGP RECV Update PDU length 30
Aug 08:24:45.926217 BGP RECV flags Ox90 code MP_unreach(15): AFI/SAFI 2/1
Aug 08:24:45.926233 BGP RECV End of RIB: AFI 2 SAFI 1
Aug 08:24:45.926271 bgp_read_v4_message: done with 172.27.0.34 (External AS
1342930876) received 2617 octets 40 updates 80 routes
j
www.uniper.net BGP Troubleshooting • Chapter 7-17
BGP outing Troubleshooting Checklist

(2 of 2)
• Routing is OK
• Check firewall settings
• Use traceroute to verify that traffic follows the IGP
best path or MPLS LSP as required
,., -
, 1�., •
�Ufil�'l·"':'o�d:ideEducationServices -�Jun,pern,11 7-18
Is Routing OK?
If the examination shows that routing works properly but connectivity problems still exist, the
problem might be related to the firewall settings.
Is the Packet Path Optimal?

An incorrectly applied policy can influence the path that packets take to a destination. For example,
next-hop-self policy on route reflectors can send the packets first to the route reflector instead of to
the originating IBGP peer directly. Use traceroute to make sure that traffic follows either IGP
shortest path or traffic-engineered MPLS LSP, as required.

Important Troubleshooting Commands
• Use the BGP CLI operational-mode commands

• show bgp summary
• show bgp neighbor
• show route advertising-protocol bgp
• show route receive-protocol bgp
• show route protocol bgp
• show route hidden
• show route resolution unresolved
• For debugging. enable trace opt ions then use
• show log filename
•monitor start filename
•monitor stop
Important CU Troubleshooting Commands

The slide shows some important operational mode commands useful for BGP troubleshooting. Note
that taking a look at the configuration often simplifies troubleshooting significantly.
Debugging BGP
For complex problems, use traceoptions.

Agenda: BGIP Troubleshooting
• BGP Troubleshooting with the Junos CU Tools

7 Time-Saving Tips
Time-Saving Tips
The slide highlights the topic we discuss next.

Time-Saving Tips
• The best way to save time is to avoid troubleshooting

altogether
• If you do have to troubleshoot. follow the logical steps:
• Verify that BGP sessions are established
• Check if the configured families are negotiated between peers
• Check whether routes are advertised and received
• Check if unresolved routes exist
• Verify that routes are in the routing tables
• Be specific in show commands and use filters
• For difficult problems. use traceopt ions
• If you get stuck. consider moving on to the next task
• You can then return to the troubleshooting if you have time
�= 'Kn'i:t
�LJn�;WorfdwideEducationServices ww.,Jun,pe,oet 1 7·21
=&°¥= "-"� I
The Best Way to Save Time

Try to avoid self-induced errors while configuring BGP tasks. You can run out of time troubleshooting
multiple problems.
Follow Logical Steps

If you must troubleshoot, follow the logical steps and be consistent.
If You Get Stuck

If you are caught off-guard by an unfamiliar topic, do not let it absorb too much time. Move on, then
perhaps you can return to the task later to complete it.

Summary
• Discussed and troubleshot BGP peering problems with
misconfigured peering
• Described and troubleshot connectivity caused by routing
policy or fixed by routing policy
• Explained and troubleshot misconfigured BGP settings

The troubleshooting of BGP peering problems with misconfigured peering;
The troubleshooting of connectivity caused by routing policy; and
The troubleshooting of misconfigured BGP settings.

La 7: BGP Troubleshooting
• Use operational mode commands to troubleshoot

BGP problems.
• Make configuration changes to resolve identified
issues.
• Verify changes and network stability.

�¥";;�, • I
ijlJfi)IDi::)('i
�
"1i11l wide Educatlo n Services ww,v Ju nrper net 1 7·23
• .# t,__
I
Lab 7: BGP Troubleshooting

The slide provides the objectives for the lab.


Jun,E�J�,r
Chapter 8: Multicast Implementation

Chapter Objectives

able to:
• Explain multicast forwarding
• Describe and configure PIM sparse mode
• Describe and configure intradomain MSDP
-�� "'"" "' � -

fj. � Gl�
UI.LJ WarldwldeEdui:aljonServlces
&or • """"'
"""1.)un,pernet I 6-2

Multicast forwarding;
PIM sparse mode; and
lntradomain MSDP.
Chapter 8-2 • Multicast Implementation www.juniper .net

Agenda: Multicast Implementation
� PIM Sparse Mode Implementation

• MSDP Anycast-RP Implementation
PIM Sparse Mode Implementation

www.juniper.net Multicast Implementation • Chapter 8-3

Multicast Forwarding Overview
• Multicast forwarding overview:

• Unicast forwarding bases decisions on destination IP
address
• Forwards traffic to the next hop of the best route
• Multicast forwarding bases decisions on source IP address
• Forwards traffic away from t11e source along t11e distribution tree
• Forwards only traffic that passes RPF check
• RPF:
• Prevents looped and duplicated multicast packets
• Compares incoming interface of multicast packet with outgoing
next-hop interface of unicast route toward the source of the packet
- If interfaces are the same: passes the RPF check
- If interfaces are different: fails the RPF cl1eck
Multicast Forwarding
When forwarding unicast traffic, the router is primarily concerned with the destination address. The
goal of unicast forwarding is to send the packet in the direction of the destination. A route lookup is
performed to find the best route toward the destination, and the packet is sent in that direction.
Multicast forwarding is not initially concerned about the destination address of a multicast packet.
Multicast forwarding bases its decisions primarily on the source address of the incoming packet. The
goals of multicast forwarding are to make sure traffic sent toward the receivers does not loop in the
network and also to avoid packet duplication. To make sure no loops or duplicated packets exist,
multicast routing sends only a single packet down each branch of the distribution tree.
To determine which incoming packets are sent down the distribution tree, multicast forwarding uses
the reverse path forwarding (RPF) check. The RPF mechanism basically selects packets to forward
down the distribution tree only if the packet was received on the interface that is nearest to the
source.
The RPF check looks into the routing table to determine the best route back to the source. The
next-hop interface of that route must be the incoming interface of the multicast packet. If the
interfaces match, the packet passes the RPF check and can be forwarded down the tree. If the
incoming interface does not match the route back to the source, the RPF check fails and the packet
is discarded.
Chapter 8-4 • Multicast Implementation www.juniper.net

Multicast Forwarding Terms

• Multicast forwarding terms:
• Incoming interface or upstream interface
• Interface on which traffic is received that passes the RPF check
• Interface to which PIM join messages are sent
• Outgoing interface list or downstream interfaces
• Interfaces to which traffic must be forwarded down the distribution
tree
• Forwarding decision is cached in the inet. 1 table
""
� tr""'"'�
�l:Jnm ��orldwideEducationServices www,unopernet I a-s
-..A.-J1�%,
Multicast Forwarding Terminology

The RPF check mechanism is essential in multicast routing. It is used in both the forwarding plane as
well as in the control plane:
Forwarding plane: A successful RPF check allows traffic from an incoming interface to
be forwarded down the distribution tree. The incoming interface is considered the
upstream interface because the source is upstream. The receivers are downstream on
the tree so the interfaces to which the traffic can be forwarded are called downstream
interfaces. The group of interfaces with downstream receivers is called the outgoing
interface list (OIL).
The result of a successful RPF check is cached in table inet. l.
Control plane: The RPF check is also used in the control plane. If a router must receive
traffic because of downstream receivers, it signals only to upstream routers on the
interface that would pass the RPF check. Therefore, join and prune messages are only
exchanged with neighboring routers on the upstream interface.
The receipt of an Internet Group Management Protocol (IGMP) or Protocol Independent Multicast
(PIM) join messages moves those interfaces to the OIL, so packets are forwarded to these interfaces
towards the receivers.

Multicast Routing Tables
• Multicast routing tables:

• inet. 0
• Default table used for RPF check lookups
• inet. l
• Forwarding cache for successful RPF-checked traffic
• inet. 2
• Alternate table for RPF check lookups
• Multicast topology independent from unicast topology
• Use of RIB groups required
Route Tables for Multicast Routing

Multicast forwarding uses multiple route tables related to the RPF check process:
inet. o: The default table used by the RPF check process is the same as the unicast
forwarding table: inet. O. Thus, the unicast topology and multicast topology are
identical.
inet. 1: The results of successful RPF checks for forwarding traffic are cached in a
separate inet. l table.
inet. 2: If you must have a separate topology for multicast forwarding, you can achieve
this separate topology by changing the table the RPF check uses. Therefore, instead of
looking in the default inet. O table, the RPF check can be directed to look in inet. 2.
The inet. 2 table must be filled with routing information to build the alternate topology
used by the RPF check:
Routing protocols like multiprotocol BGP (M-BGP) and multi-topology IS-IS can
place routes into inet. 2 directly; or
Other protocols must use routing information base (RIB) groups to place routes
into inet . 2.
To direct the multicast routing protocols to use inet. 2 for the RPF check, RIB groups are required.

PIM Sparse Mode Overview (1 of 2)
• Sparse mode:
• Assurnes sparse distribution of receivers
• More realistic scenario for most networks
• Explicitjoin rnodel
• Multicast traffic is forwarded only to routers that explicitly
request it
• rvlore cornplicated source discovery rnechanisrn required
• RP is required for source discovery in any source multicast model
• Source-specific multicast does not require RP
- Source discovery become�, an application issue
Sparse Mode Protocol

Sparse mode protocols have the following characteristics:
Assume sparse distribution of receivers: Typically, receivers are not distributed across
all network segments; therefore, all network segments will not need all multicast traffic.
Traffic should be sent only to segments that have specifically asked to receive it.
Uses an explicit join mode/: In sparse mode, routers must explicitly request their
upstream routers to forward traffic for a specific group, which is done by sending a join
message to the upstream router.
Complicated source discovery mechanism is required: The main complication with
sparse mode is that receivers might indicate interest in receiving traffic for a specific
group but they do not know who the sources will be. This complication makes it hard for
the designated router (DR) on the receiver segment to signal to the upstream router,
because it does not know the upstream router for an unknown source.
There are two solutions to this problem:
Use of a rendezvous point (RP) in any-source multicast (ASM). The source will
announce itself when it becomes active. Now the receiver DR can join a shared
tree towards this RP.
Let the receiver signal the source from which it wants to receive traffic, called
source-specific multicast (SSM). The source discovery now becomes an
application issue because it must inform the receiver which sources to use.
www.juniper.net Multicast Implementation • Chapter 8- 7

PIM Sparse Mode Overview (2 of 2)
• Sparse mode:
• Shared tree(*. G)
• Initial forwarding state in routers assumes path through RP
• Potential suboptimal path between source and receivers
• Source-based tree (S,G)
• Router nearest to receiver learns about source when receiving
traffic
• If source is known. the router can switcl1 to shortest path between
source and receiver
Sparse Mode Distribution Trees

In sparse mode, two types of distribution trees are used:
Shared tree or rendezvous point tree (RPT): If the source and receiver do not know each
other's identity, they cannot use the source-based tree. The only option is to meet each
other at the RP, where initial traffic can flow between the source and receiver. The path
between the receiver and the RP is called a shared tree because it is shared for
meeting all sources of a multicast group.
The state for shared tree is described as a *,G state. The asterisk(*) indicates any
source, and G indicates the group.
Source-based tree or shortest path tree (SPT): Once the source is known at the
receiver's DR, it can now set up a more optimal source-based tree toward the source.
The state for source-based tree is described as an S,G state. S indicates the specific
source, and G indicates the group.

PIM Sparse Mode: RP Considerations
• An RP is essential to PIM sparse mode functionality

because it allows messages from the source and the
receiver to meet
• Placement of RP
• Prevent suboptimal routing across SPT
• Redundancy of RP
• Per specific multicast group only 1 RP can be used (different
groups can use different RPs)
• Failover options dependent on RP discovery mechanism
• Tunnel service capabilities reyuired on RP and source DR
• Might require additional hardware on some Junos platforms
• If source DR is also RP. then no tunneling required
%11�"') ;i
LJt.:JfilfPefi
�
oildwideEducationServices
""
wwwiun,porn,1 a-s
J
as ' " s=
PIM Sparse Mode: RP Considerations

The RP is essential to the PIM sparse mode functionality, allowing sources and receivers to meet.
Multiple considerations exist with regards to the RP when using PIM sparse mode:
RP placement: RPs should be located in central high-bandwidth areas of the network.
By default, RPs are used only during initial traffic flows; however, proper placement of
RPs ensures the initial receiver and sources can join the multicast network quickly. The
placement of the RP is even more critical if group traffic flows do not switch to the
source-based tree. You can configure groups to remain on the shared tree to minimize
the state that will be created for those groups.
RP redundancy: Because the source and receiver must meet, they must both use the
same RP. Thus, only one RP can exist for each group, which creates a single point of
failure in the multicast network. Depending on the way the RP information is learned in
the network, different options exist to improve the failover options.
RP hardware requirements: The source DR and the RP must encapsulate and
de-encapsulate the register messages. This packet manipulation is performed by using
the tunneling services of a Junes OS platform. Depending on the platform in use, this
might require additional hardware.

PIM Sparse Mode: RP Discovery
• PIM sparse mode has three ways of discovering the

RP:
• Static RP
• Easiest but by default. no failover
• Auto-RP
• BSR defined in RFC 5059
• Multiple discovery options can be used at the same
time
• Preference is BSR over auto-RP over static
• Anycast-RP can be used with each of these discovery
mechanisms to improve redundancy
• Improves failover times significantly
PIM Sparse Mode: RP Discovery

Routers can learn about the RP information in three ways:
Static RP;
Auto-RP; and
Bootstrap router (BSR).
It is possible to use multiple mechanisms to learn about RP at the same time. In case the RP is
learned from multiple mechanisms, the preferred order is BSR over auto-RP over static RP.
In the next section, we discuss the concept of anycast-RP, which allows enhanced RP redundancy
features. Anycast-RP can work with any of the discovery methods listed but typically static RP is used
in combination with anycast-RP.
Chapter 8-10 • Multicast Implementation www .juniper.net

PIM Sparse Mode: Configuration Basics

• PIM sparse mode configuration is very dependent on
the RP discovery mechanism in use
• RP mechanism determines interface mode:
• Static RP: sparse mode
• Auto-RP: sparse-dense mode
• BSR: sparse mode
• RP-specific configuration items
• Auto-RP:
- Mapping agent and candidate RPs
- Densefloodingfor 224.0.1.39/ 224.0.1.40
• BSR:
- Bootstrap router and candidate RPs
- Works with PIM version 2 only
.,�-:·
Worldwide
• '?.,c;_> Education Services w"� JUOIP er oet I 8·11
PIM Sparse Mode: Configuration Basics

The PIM sparse mode configuration is very dependent on the RP discovery mechanism in use.
The RP mechanism determines the mode for which the interfaces must be configured:
Static RP: Sparse mode;
Auto-RP: Sparse mode or dense mode; or
BSR: Sparse mode.
Each RP discovery mechanism also has its own RP-specific configuration items:
Auto-RP:
Mapping agent and candidate RP roles; and
Dense flooding for 224.0.1.39 (announce) and 224.0.1.40 (discovery) groups;
BSR:
A bootstrap router and at least one candidate RP must be configured; and
PIM version 2 must be configured to allow bootstrap and candidate RP messages
to be forwarded.

P M Sparse Mode: Tunneling Requirements
• Both RP and the source DR need tunneling

capabilities to send and receive register messages
• Not needed if the source DR = RP
• Tunneling capabilities are platform dependent and
additional hardware rnight be needed
• MX Series line cards can be configured to provide
tunneling capabilities
PIM Sparse Mode: Tunneling Requirements

The register message between the source DR and the RP requires the use of tunneling services on
Junos platforms. If no register message is necessary because the source DR is also the RP, then, of
course, no need exists for tunneling services.
Some Ju nos platforms might need additional hardware to be able to provide tunneling capabilities.
For the latest information regarding your platform and tunneling capabilities, please check the
Juniper website or contact Juniper TAC.
MX Series line cards can be configured to provide tunneling capabilities by enabling the tunneling
services through configuration. Different MX Series line cards have different capabilities, so please
check the Juniper website for your specific platform setup.
The software interfaces needed for source DR or RP functionality can be viewed with the show
interfaces terse I match "pdjpe" command.

PIM Sparse Mode: Optional Configuration

• Shortest-path tree cutover control
• Policy applied on the last hop router so that only the RPT is
used
• PIM join load balancing
• Normally if multiple equal-cost paths towards the source
exist, only one will pass the RPF check
• For PIM sparse mode, load sharing can be enabled so that
all equal-cost links can be used on an (S,G) by (S.G) basis
�Ulil!m� Worldwid�EducatlonServices www,unopm,t I e-13

le.·.•• -• -
SPT Cutover Control

By default, traffic moves to the source-based tree as soon as the first packet arrives at the receiver
DR (last hop router) and the source is known. Using a policy allows traffic from a source to a group, to
stay on the shared tree. The reason for keeping traffic on the shared tree is to limit the additional
state that is created when a source-based tree is established, and to limit any possibility of traffic
loss during the cutover. For some multicast applications, it might not be strictly necessary to use a
shortest path because they are not delay sensitive.
PIM Join Load Balancing

In PIM sparse mode, it is possible to load-balance PIM joins between equal-cost next hops. Without
the set protocols pim join-load-balance command, only one interface is used as the
RPF interface towards a source (or RP). By adding this command, multiple equal-cost next hops can
be used on a per S,G-by-S,G basis.
Suppose a source (172.27.0.30) sends traffic to two groups: 224.1.1.1 and 224.3.3.3. If two
equal-cost paths exist back to the source, one group can be forwarded over Interface A, and the
other group can be forwarded over Interface B. The PIM join messages would be sent to the
upstream router on Interface A for group 224.1.1.1 and to the upstream router on Interface B for
group 224.3.3.3.

• PIM Sparse Mode Implementation

� MSDP Anycast-RP Implementation
• Sarnple Task Analysis
MSDP Anycast-RP Implementation


MSDP Overview
• Communicates information about active sources
between RPs
• lnterdomain RPs
• lntradomain RPs
• Anycast-RP uses MSDP to improve failover time
• Typically runs on PIM sparse mode RP routers

• RP learns about the source and establishes a source tree
towards the source if it has any receivers for this group
• When traffic arrives at the receiver router. it establishes its
own source tree back to the source
• MSDP sets up peer relationships using TCP
• Exchange SA messages
Communicates Information About Active Sources

Multicast Source Discovery Protocol (MSDP) shares multicast source information between RPs so
that sources and receivers can meet, even if they have associated with different RPs:
/nterdomain RPs: Enables multicast deployments between different service providers;
and
lntradomain RPs: Improves RP redundancy through anycast-RP feature.
Typically Runs on RP Routers

MSDP is typically configured on RPs, although it is possible to configure MSDP on non-RP routers as
well. In the interdomain multicast setup, domains might exist that never have any sources but still
need MSDP to enable transit multicast traffic across their domain.
Once a remote source for a group is learned on an RP, the RP establishes a source tree back to the
source, assuming the RP has knowledge of the receivers for that group. When the source tree
between the source and the RP is established, traffic starts flowing toward the receiver.
MSDP Peering Uses TCP

The MSDP protocol is similar to BGP peering in that it uses TCP session between peers. The
configuration of MSDP peering sessions is also similar in that the peers must be manually
configured. Once the sessions are established, the source-active (SA) messages can be sent to any
MSDP peer.

MSDP Operation
• MSDP peer states:
• Disabled: Peer is not configured
• Inactive: Peer is configured but not listening or connecting
•Connect: Active peer attempts to initiate TCP session
• Listen: Passive peer is configured and listening on port 639
• Established: TCP session is established
• SA message flooding:
• SA message is sent when the source registers with the RP
• If the source is still active. the RP will resend the SA
message every 60 seconds
• SA messages are cached on receiving peers (inet. 4)
'JUfillPerf. W;rhiwide Education Services

f�•!i;
""':,;,; "':., t,i"' �� "
WW� Jun,pernel 8-16
J
MSDP Peer State

Once the MSDP peers are manually configured , the peer router with the highest IP address remains
passive and listens only to connection attempts from the active peer on TCP port 639.
MSDP peers can go through different connection states. The active peer (lowest IP address) will
normally go into a connect state. In this state, the active peer is trying to set up the peering session
by initiating a TCP three-way handshake. Once the TCP connection is established, the session state
becomes established.
SA Messages
The SA message is sent by an RP with MSDP, when the RP becomes aware of a source through the
incoming register message. The SA message is sent to all the RP's MSDP peers. The SA message is
sent every 60 seconds until the source stops sending multicast traffic.
The receiving MSDP peers store this information in their SA cache, if the message passes the
RPF-peer check. In the Junos operating system, this SA cache is stored in the inet. 4 table. To clear
the MSDP cache information, use the clear msdp cache command.
Any SA message that passes the RPF-peer check is sent to all MSDP peers except the peer where the
SA was received.

MSDP Source·Active Peer-RPF Overview
• MSDP floods SA messages to all peers except the

peer from which it received it
• Duplicate messages might be received from peers
• Peer-RPF check is performed to minimize
unnecessary flooding of SA messages
• Originating RP inside the SA message is basis of RPF check
• RPF peer must be tl1e same as the router that the SA message is
from
• Multiple peer-RPF rules
• First match determines the RPF peer
• Only if peer-RPF check is successful, are SA messages
accepted and forwarded to other peers
�·�v
WorldwideEducationServices WW,VJUn<po,net I 9-17
�ic=-i
MSDP SA Flooding
MSDP floods SA messages normally to all its peers except the peer from which it received the
message. Thus, peers can receive the same SA message from more than one peer. To prevent
unnecessary flooding or looping of these messages, MSDP uses a peer-RPF check.
Peer-RPF Check
When an SA message is received, MSDP performs a peer-RPF check, and only messages that pass
this check can be used (cached locally and forwarded to other peers). The peer-RPF checks to
determine whether the sending peer is on the path towards the originating RP. The concept is similar
to the general multicast RPF check in which traffic is forwarded only away from the source; with
MSDP, SA messages are forwarded only away from the originating RP.
Next, we look at multiple peer-RPF rules.

MSDP Peer-RPF Check Rules

• Peer-RPF succeeds if:
• Originating RP is an MSDP peer of local router. the
originating RP is the sending MSDP peer
• SA message is received from non-originating RP when:
• AdvertisingMSDP peer is BGP next hop for originating RP
• AdvertingMSDP peer's IGP next l1op is the same as the next-hop to
the originator RP
• AdvertisingMSDP peer belongs to last AS listed in the BGP route
path towards the originating RP
• Peer-RPF check is not performed if:
• SA message is received from MSDP peer in mesh group
• SA message is received from default MSDP peer
".
MSDP Peer-RPF Rules

The peer-RPF rules are used in the order presented, and the first match determines the success:
If the advertising MSDP peer is the actual originating RP, then SA message is accepted.
If the advertising MSDP peer is not the actual originating RP, but:
The advertising MSDP peer is the BGP next hop for the originating RP address,
then the SA message is accepted.
The advertising MSDP peer is the advertising router for the route towards the
originating RP, the SA message is accepted.
The advertising MSDP peer belongs to the last AS listed in the BGP route path
towards the originating RP; then the SA message is accepted. If multiple peers
exist from that last AS, SA messages from only the one with the highest IP
address will be accepted.
Peer-RPF Rules Are Not Used

The two exceptions for when the peer-RPF check is not performed, and the SA will be accepted:
SA messages received from an MSDP peer configured in a mesh group.
SA messages received from the configured default MSDP peer. For domains that only
have a single MSDP peer, it is essential that all of the received SA messages are
accepted.

Anycast .. RP Overview (1 of 2)
• PIM sparse mode allows only a single RP per group

• Limits redundancy options for RP
• Failover time is typically high
• Load sharing can be performed only between groups
• Anycast-RP enables multiple RPs per group
• Multiple RPs share an identical IP address (anycast address)
• Sources and receivers use the closest RP determined by unicast
routing table
• Redundancy is significantly better
• Failover time is only dependent on IG P convergence
• Load sharing within a group is now possible
- ,,,!Tr�;u,.. "'
uwnm�. WorltlwideEducationServfces www,un,p,.net I e-19
�;&; =
Single RP for Each Multicast Group

The concept of an RP in PIM sparse mode is that there can be only one RP per multicast group in the
network. This requirement ensures that source and receiver always use the same RP so that they
can connect through it. A single RP per multicast group creates a single point of failure, which is
something to avoid in correctly designed networks. A single RP also limits the options for load
balancing in case of high volume groups.
Anycast-RP Enables Multiple RPs for Each Multicast Group

To allow load balancing within a group and to increase network resiliency, anycast-RP was developed.
The concept of anycast, in general, is to have multiple devices performing the exact same role in the
network, and with the exact same unicast address (anycast address). The clients connect to the
nearest device with the required anycast address. If the nearest device fails, the clients can connect
to other devices that have the same anycast address. As soon as the interior gateway protocol (IGP)
converged, the clients can connect to the (new) nearest anycast device.
Anycast-RP allows for multiple RPs in the network to share a unicast address that every router
associates with the RP. Each router communicates with the nearest RP about source or receiver
information. Of course, this creates a similar problem to the interdomain multicast setup: a source
connects to RP-A and the receiver to RP-B. To let the source and receiver connect across different
RPs, MSDP was originally used.
The main advantage of anycast-RP is that you can have redundant RPs per group, and the
convergence time is much lower in the case of failures.

Anycast·RP Overview {2 of 2)
• Source and receiver can connect to different RPs for

the same multicast group
• Enables load sharing within a specific group
• Need for additional solution to let source and receiver meet
• MSDP: Supports only 1Pv4
• PIM: Supports both 1Pv4 and 1Pv6
0 •
Source and Receiver on Different RPs

The anycast-RP features allows load sharing within a group, which can be useful for bigger
deployments.
To let the source and receiver connect to each other, there must be a way for the RPs to exchange
information about sources, the receivers, or both. As seen previously, MSDP can exchange source
information between RPs and thus can be used for intradomain multicast designs. The
disadvantages of MSDP are that it only supports IP version 4 (1Pv4) and that it requires additional
protocol configuration.
Another more recent option is to use PIM anycast for the exchange of source information. Therefore,
no MSDP is needed for anycast-RP to function. This solution is useful if you must support IP version
6 (1Pv6) or if MSDP is not needed in a 1Pv4 environment (no interdomain multicast).

Basic Anycast-RP Configuration
• Create the unique host address by configuring a

unique IP address on the loopback interface
• Set the primary address flag
• Beware of router ID issues for OSPF, BGP. etc.
• Use tl1e router-id command in [edit routing-options J
to be sure
• Configure the non-unique unicast address used for
anycast-RP on the loopback interface
• Assign this address as the local RP within PIM on the RP
routers
• Non-RP routers can learn the anycast-RP information
using any discovery mechanism (typically static RP)
�!"- ,·
WorldwideEducationServices wwwJunrpornet I a-21
ffl i} -
Unique Host Address

Each RP needs its own unique IP address so that its other protocols function correctly (IGP/BGP). To
ensure that the unique address is used as the primary address on the loopback interface, the
primary option can be added to the address. Another method of ensuring that no duplicate router
IDs are created in the network is to hard-code the router ID on each router to the unique address
using the set routing-options router-id command.
Anycast Address
On each of the RPs, a secondary IP address is used by all RPs to signal the RP role.
Anycast-RP and RP Discovery

All routers must learn what the RP address is in the network. When using anycast-RP, all discovery
mechanisms are possible-static, auto-RP, and BSR-but typically, static RP is used. Static RP is
simple, and, with the addition of anycast-RP, is now also redundant.


• PIM Sparse Mode Implementation
• MSDP Anycast-RP lrnplementation
� Sample Task Analysis


Task and Topology
�D
S1 R3 Rl Reel
giD
37 .6 .21
ge-0/0/2 ge-0/0/1 ge-0/0/4
@ ®
�, � f°/Q/4 �·,:
N
....... .......
0 0
....... .......
o o
Roc2
�� ge-Q/oN��
�ge-0/0/6 �ge·0/0/4
--,,,""',..,..,--
eJ D
ff"'
• Task R4 .14 R2 .57
• R1 and R3 are RPs for the PIM domain, and the RPs must
support load balancing for a given group. The RPs must also
support 1Pv6 for future implementation. Rec2 must always
use the RPT. inet.O cannot be altered. and RIB groups
cannot be used to accomplish this task.
�l!.Jlilm,
ii:��,}---""-�·
Worldwide Education Services WWW ,,nipe, ne1 I 8·23

This slide displays the sample task and topology. We analyze this task in next set of slides.

What Now?
• PIM sparse mode
• The RPs must load balance the same group
• Is PIM anycast-RP required? Yes
• Can MSDP be used for this task? No
• How can you make joins from Rec2 always use the shared
tree and not cutover to the source tree. without altering
inet.O?
• Will altering inet.2 work? Yes, but you are not allowed to
use RIB groups
• Create a policy to not allow the SPT cutover to take place
• Where is the policy applied? R2

By examining the sample task and topology, you can determine what the sample task is asking. The
items on the slide list what is required to complete the sample task.

• Configure PIM sparse mode on all routers
lab@R2> show configuration protocols pim

rp I
static {
address 172.27.255.11;
interface all;
interface ge-0/0/0.0
disable;

rp {
static {
address 172.27.255.11;
interface all;
interface ge-0/0/0.0
disable;
Configure PIM Sparse Mode

The slide displays the configuration for the non-RP routers. PIM sparse mode does not need to be
specifically configured because it is the default PIM mode.

• Configuring PIM anycast-RP

• Make sure to configure a non-unique secondary loO address
lab@R3> show configuration interfaces loO
unit O {
family inet {
address 172.27.255.3/32 {
primary;
}
address 172.27.255.11/32;

rp {
local {
family inet: {
address 172.2 7.255.11;
anycast-pim {
cp-set {
address 172.27 .255.1;
}
RP Configuration
The slide displays the necessary configuration for PIM anycast-RP on R3. Similar configuration is
also needed on R1 (with the correct IP addresses) to complete this part of the task. Make sure to
configure the same secondary loO address on both R1 and R3, and to configure the unique loO
address as primary (best practice to ensure it is used as the router ID). You will notice that the
non-unique loO address is used as the local RP address, and the unique loO address is used for the
anycast configuration.

• Create a policy to not allow the SPT cutover on R2

lab@R2> show configuration policy-options policy-statement rpt-only
tecm 1 {
from {
source-address-filter 172.27.0.38/32 exact;
then accept;
}
term 2 {
then r:eject;

spt-thr:eshold {
infinity r:pt-on ly;
r:p {
static {
addr:ess 172.27 .255.11;
}
inter:face all;
inter:face ge-0/0/0.0
disable;
LJl!.Jn� '°',¥'.';.<'l')l
WortdwideEducatlonServices WW�Jun,po,net I 8-27
" -1als!.0,tL
Policy Creation
The slide displays the required policy to keep group 224.1.1.1 from cutting over to the SPT. The policy
is then applied under PIM as a SPT threshold on the last hop router, R2. The SPT cutover threshold of
infinity applied to a source-group address pair means the last hop routing device never transitions to
a direct SPT.

• Verify PIM neighborship
lab@R3> show pim neighbors

Instance: PIM.master.
B Bidirectional Capable, G Generation Identifier,
H Hello Option Holdtime, L Hello Option LAN Prune Delay,
P Hello Option DR Priority
Interface IP V Mode Option Uptime Neighbor addc
ge-0/0/1.0 4 2 HPLG 01:04:18 172.27.0.1
ge-0/0/4. 0 4 2 HPLG 01:04:18 172.27.0.6
lab@R4> show pim neighbors
Instance: PIM.master.
B Bidire ctional Capable, G Generation Identifier,
H Hello Option Holdtime, L Hello Option LAN Prune Delay,
P Hello Option DR Priority
Interface IP V Mode Option Uptime Neighbor addr

ge·-0/0/3.0 4 2 HPLG 3d 23:00:19 172.27.0.2
ge-0/0/6.0 4 2 HPLG 3d 23:00:11 172.27.0.13
Verify PIM Neighborship

The slide displays the expected PIM neighbors on R3 and R4. You should verify that each router has
the correct PIM neighbors.

Tas Verification (2 of 4)
• Verify PIM anycast-RP configuration
• Make sure both RPs will support the same group range
lab@Rl> show pim rps extensive
Instance: PIM. mastec
:O.ddcess family INET
RP: 172.27 .255.11

Learned via: st atic configucation
Time Active: 00:16:17
Hol d time: 0
Device Index: 130
Subunit : 32769
Intecface: ppd0.32769
Gcoup Ranges:
224.0.0 .0/4
Registec St ate foe RP:
Gcoup Soucce Fiest Hop RP Addcess State
Ti:neout
224.1.1.1 172. 27.0.38 172.27.255.3 172 .27 .255 .11 Receive
132
Anycast PIM cpset:
172.27.255 .3
Anyc ast PIM local addcess used: 172.27.255.1
Addcess family INET6
�Jt" "�
Wor!dwideEducationServices ww.vJunopernet I e-29
; ":i ,._.......,,..
Verify PIM Anycast RP

The slide displays the status of the RPs. From this output you can determine that R3 is the other RP
(PIM rpset), that the group range is all multicast groups, and that R1 is learning about the group
224.1.1.1 from R3.
The status of the RPs on R3:
lab@R3> show pim rps extensive
RP: 112.27.255.11
Learned via: static config uration
Interface: ppd0.32769
Group Ranges:
224.0.0.0/4
Anycast PIM rpset:
172.27.255.1
Anycast PIM local ad d ress used: 172.27.255.3
Anycast PIM Regis te r State:
Group Source Origi n
224.1.1.1 172.27.0.38 DIRECT

• Verify the policy is not allowing SPT cutover

• Only *,G is seen on R2
lab@R2> show pim join extensive

Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W Wildcard
Group: 224.1.1.1
Source: 1::
RP: 172.27.255.11
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/2.0
Upstream neighbor: 172.27.0.18
Upstream state: Join to RP
Downstream neighbors:
Interface: ge-0/0/4.0
172.27.0.58 State: Join Flags: SRW Timeout: 204
Instance: PIM.master Family: INET6
R = Rendezvous Point Tr-ee, s = SpaLse, w = �'Jildcard
Verify That the Policy Is Not Allowing the SPT Cutover

The slide displays that* ,G (RPT) should be seen only for group 224.1.1.1 from the last hop router
(R2), upstream to the RP (R1).

• Multicast traffic is flowing towards Rec2

lab@R2> show multicast usage
Group Soui:ces Packets Bytes
224.1.1.1 1 85 7140
Pi:ef ix /len Gi:oups Packets Bytes

172 . 2 7. 0 .3 8 /32 1 85 7140
lab@R2> show multicast route extensive
Family: INET
Gi:oup: 224.1.1.1
Soui:ce: 172.27.0.38/32
Upsti:eam intei:face: ge-0/0/2.0
Downsti:eam intei:face list:
ge-0/0/4.0
Session desci:iption: ST Multicast Gi:oups
Statistics: 10 kbps, 120 pps, 2929 packets
Next-hop ID: 262142
Upsti:eam pi:otocol: PIM
Route state: Active
Foi:wai:ding state: Foi:wai:ding
Cache lifetime/timeout: 360 seconds
Wi:ong incoming intei:face notifications:
Family: INET6
. ''
Worldwide Education Services ..�� ''"'P" net I 8-31
._;:; ,;J jj.;'�... � -�
MulticastTraffic Is Flowing
The slide displays that the multicast traffic for group 224.1.1.1 is flowing towards Rec2.

Summary
• Explained multicast forwarding
• Described and configured PIM sparse mode
• Described and configured intradomain MSDP
�;'&»if �'°"" -""=

". • t.'!� WorldwideEi:lticationServices
!!QC)JP@fi
,,:,."'=-
""
-�-Jun,pernel I S-32

Multicast forwarding;
PIM sparse mode; and
lntradomain MSDP.

Lab 8: Multicast Implementation and

Troubleshooti g
• Configure PIM sparse mode.

• Configure anycast-PR.
• Configure RIB groups to alter the RPF check.
Note: This lab is a timed simulation. You

will have 1 hour to complete this lab.
WorldwidBEducationSeNlces www 1 unipe,net 1 6·33

"'Ji4�"--"
Lab 8: Multicast Implementation and Troubleshooting



Jun1Per
Chapter 9: Class of Service Implementation

Chapter Objectives

able to:
• Identify Cos subjects for the JNCIE-SP exam
• Explain the Cos process in the Junos OS
• Identify any caveats. tips. and tricks on the Cos section of
the exam
�""��itw� '"'
l!JCllA8(i!kWorldwide Educatio1tServtces ww,• Jun,pernei 1 9-2

� w "' � �

The class of service (CoS) subjects covered in the JNCIE-SP exam;
The CoS process in the Junos operating system; and
Various caveats, tips, and tricks for the CoS section of the exam.
Chapter 9-2 • Class of Service Implementation www.juniper.net

Agenda: Class of Service Implementation
� List of CoS Exam Topics

• CoS Processing Refresher
• Caveats, Tips, and Tricks for the CoS Section
�7"',H<v"
Ull.lfl� wori;,dWld?EducatlonServices WWWJun,pernet I 9-3
,..,mfJdJ;;/S,tt;z
List of Cos Exam Topics

www .juniper.net Class of Service Implementation • Chapter 9-3

Cos Topics for the JNCIE-SP Exam (1 of 2)
• !net-precedence, DSCP, EXP, and 802.ip markings

• Be familiar with the different traffic marking methods
• Behavior aggregate and multifield classification
• Understand the different methods of classification, how they
differ. and the criteria supported for classification
• Drop profiles
• Be familiar with various uses of drop profiles, configuration
options. and where to apply
• Rewrite rules
• Understand remarking concepts and where it happens in
the traffic flow
:Jtlfil!R.err\
' wi':1�;lde Education Services WV"'1 Jun,p,rnet I 9-4
I -•t �
Cos Topics for the JNCIE-SP Exam: Part 1

A JNCIE-SP candidate is expected to be familiar with the concept of packet marking for class of
service purposes. This includes inet-precedence, DSCP, EXP, and 802.lp markings.
You should complement your knowledge of the different types of markings with the different
classification types-behavior aggregate and multifield classification. Understand what fields are
used for classification and how these two methods differ.
You should also understand drop profiles and any configuration options , including the use of loss
priority markings during classification.
You should also be aware of how rewrite rules are used and what verification methods are used to
ensure that the rewrite is working properly.

Cos Topics for the JNCIE-SP Exam (2 of 2)
• Schedulers
• Understand their use and various options and where they
appear in the context of processing
• Tri-colored marking
• Understand what it is. and how it complements
classification and drop profiles
• Policers
• Understand the different methods that are used when
applied and the different traffic actions supported
J:t�
WtirldwldeEducationServices wwwiunipernet 1 9·6
z�
Cos Topics for the JNCIE-SP Exam: Part 2

You should know what a scheduler is and the various options used in a scheduler.
You should understand what tri-colored marking and how is used in relation to loss priority marking.
You should be familiar with policers and the different traffic actions supported.
Generally, you should understand where to apply the configuration for each of these technologies,
and the use of operational commands or other methods of verification.
www.juniper.net Class of Service Implementation • Chapter 9-5

III
List Cos Exam Topics
�Cos Processing Refresher
II
Caveats, Tips, and Tricks for the CoS Section
• Sarnple Task Analysis
Cos Processing Refresher


unos Cos Processing Refresher
Ingress
BA Multifield
Classifier Classifier
Lookup
----i
Egress I WRED/
Drop
I P rofiles
!1
1
-
I -- --------,
-1----------�
Queue/Scheduler
Marker
r---- j
Rewrite/ _ Policing
(Egress)
�----'
, -
Wort wideEducationServlces
' , ti..,..,.,, * =
www,un,pornet 1 9.7
Junos Cos Processing Refresher

The slide diagram is a refresher on where each technology fits in the context of packet processing.
This diagram is useful in understanding various important steps to successfully configure and verify
Cos tasks. For example, with the use of a behavior aggregate, mutlfield classification, and a policing
action manipulating classification of ingress traffic, you should understand any configuration
conflicts and the expected result of such a configuration.
Understanding packet processing would also help you understand where to verify that a
configuration step is working as expected.
www.juniper.net Class of Service Implementation • Chapter 9- 7

Cos Processing Order of Operation
• Ingress CoS operations:

• Behavior aggregate classification
• Multifield classification
• Ingress policing
• Egress CoS operations:
• Egress policing
• Rewrite markers
• Scheduling
• WRED/drop profiles
,,
Cos Processing Order of Operation

For the CoS processing subject in the context of the JNCIE-SP exam, you should be familiar with the
egress and ingress CoS technologies covered in the exam.
The slide shows that the ingress operations are related to classification or policing, which includes
actions to classify traffic if exceeding the traffic rate.
The egress operations include egress policing, rewriting markers, scheduling, and WRED/drop
profiles. Be aware that in the exam, task instructions might purposely be terse, expecting you to
understand where a technology should be implemented.

• List Cos Exarn Topics

II
CoS Processing Refresher
� Caveats, Tips, and Tricks for the CoS Section
Caveats, Tips, and Tricks for the Cos Section


Cos Tasks Caveats, Tips, and Tricks (1 of 3)
• CoS tasks are harder to verify

• Be familiar with operational commands that confirm the
correct configuration
• Trust the configuration. if it is hard for you to verify then it is
probably hard for the proctor to verify as well
• CoS tasks are repetitive
• Utilize the Junos OS features like copy. replace. and so on
• Access to Notepad is provided during the exam-make sure
to utilize it if it improves your efficiency
....-yrn.,.,,,�=� <
�Ufill1�' Worldwide Education Services '""" Jun,per net I s-10
� 'll�W.-\t.i ....
Cos Exam Caveats, Tips, and Tricks: Part 1

Compared to other sections of the JNCIE-SP exam, CoS tasks are harder to verify. You should be
aware of all the operational commands to confirm operation. This expertise can be acquired from
experience, but it most also be practiced during practical studies.
For the most part, Cos tasks tend to be repetitive. This tip is not exclusive for Cos sections but it is
more applicable here. Utilize any Junos features that speed up or enhance configuration steps, such
as the copy, replace, or wildcard commands. Access to Notepad and other programs are provided
during the exam-you should utilize these programs to your advantage.

• CoS section is shorter than other sections of the exam

• A good strategy is to complete easier and shorter tasks for
quick points instead of waiting until the end of the exam
• Understand the more obscure CoS concepts that are
part of the blueprint of the exam
• Closing the knowledge gap on the more obscure concepts
like tri-colored marking, burst-size policer rate calculation.
VPLS Cos options is beneficial in scoring easy points on the
exam
- --fu-
UltlfllPef: WoH�de'EaucationServlces WW,VJUntpecn,t I 9-11

CoS tasks in the JNCIE-SP exam are less dense than other sections of the exam. If you are well
prepared and comfortable with CoS, it could be an advantage to complete the Cos tasks before
starting a more time consuming section or task of the exam. Completing Cos first could earn easier
points that might make the difference in passing the exam.
Closing the gap on the more obscure concepts of the CoS section of the JNCIE-SP exam allows you to
feel more comfortable with the shorter tasks on the exam. A lot of these concepts might appear
intimidating at first, but they are not hard concepts to understand and could make a difference in
scoring points on the exam.

• Make sure to meet the requirements of the CoS tasks

• This advice holds true for any section of the exam. but
because the CoS section can be harder to verify, much of
the effort relies on inspecting the configuration. If you do not
verify your work, it could result in incomplete tasks in a
simpler section of the exam.
r: _.._ '-""''-'i �
h<'1'._
'LJUfillPer. WorldwideEducallonServlces ww,)un,pernet I 9-12
,..,,,..,... ;J,".l',,;,i_, ,

As mentioned in the slide, is very important to complete tasks for any section of the exam. However,
for the CoS section because tasks can be harder to verify, make sure you use all the possible
operational commands and carefully inspect configuration to make sure the task is completed
according to the instructions.

II
List CoS Exam Topics
• CoS Processing Refresher
• Caveats, Tips, and Tricks for the Cos Section
7 Sample Task Analysis


lask and Topology
R4
Customer4
$-
eg _-o_;o_;4
___
$
• Task:
• Create a firewall filter on R4 named R4-police.
Reclassify any traffic to port 80 exceeding 20 Mb from
Customer4 to the best effort queue and mark this traffic
as loss priority high.
�" "='Wl'�".- '%�"' xi

Q
--··
!.).UJR�, ':"'l!:�l?wide E.ducationSel\!ices
... -� Jun,p•rnet J 9-14
Task and Topology

For the sample task, it is asked to configure a policer with the name of R4-police to requeue any
traffic destined to the http port if exceeding 20Mb. The traffic is coming from the Customer4 router
and it is also asked to mark this traffic as loss priority high.

What Now?
• What are the task requirements?
• The task is asking for a policer configuration that matches
destination port of http.
• The task asks to use a narne for the filter. Since the
configuration requires both a policer and filter. we narne
both the sarne way.
• The task does not ask what burst size rate to use we use
15 tirnes the MTU size to be safe.
,u..:-1>"' ,
.Worldwide
, "'
EducationSel'\lices
u ci.c - -
..,,� JUntper net I 9·15
What Now?
The task is asking for a policer that matches destination port of 80 which is also the http port. The
tasks asks to use a name, but since it is required to configure both a policer for the rate limit portion
and a firewall filter to only apply the policer to http traffic, it is recommended the same name is used
on both to make sure the task requirement is met. Since no burst size is given, it is safe to use 15
times the MTU for the burst size.

• Step 1: Pol icer configuration

[edit f ir:e·.iall]
lab@R4# show policer R4-police
if-exceeding {
bandwidth-limit 20m;
bur:st-size-limit 15k;
then (
loss-pr:ior:ity high;
for:war:ding-class b est-effor:t;
}
• Step 2: Firewall configuration

[ed.i t f it:ewall]
lab@R4# show filter R4 -police
ter:m 1 (
fro m (
destination-por:t http;
then policer: R4-police;
ter:m 2 (
then accept;
-
t
. ------
!.)Uf11W'i1 Worldwid11EducalionSe1Vtces
,..it,;sdi ..t.. ,,,. "
..
�
wwwJun,perne• J 9-16
Task Completion: Part 1

Step 1 shows the configuration of the policer using 15k for the size of the burst size, and placing out
of profile traffic in the best-effort queue and loss priority high.
Step 2 shows the configuration of the firewall filter matching the policer configured.

• Step 3: Apply filter to ingress interface and commit
lab@R4# show ge-0 /0 /4
unit O {
descciption Customec4;
family inet {
filtec {
input R4-police;
[edit interfaces]
lab@RIJ# commit
••
IW'f- •
9,1!.lr'l Woffdwid�EducatlonSe111lces WW,VJUOlporoet I 9·17
.m
Task Completion: Part 2

Step 3 the firewall filter is applied as input to the interface facing the Customer4 router.

ask erification
• Step 1: Ensure that the firewall is applied to the

correct interface
lab@R4> show interfaces filters ge-0/0/4 .0
Interface Admin Link eroto Input filter
Output filter
ge-0/0/4.0 up up inet R4-police
-- -""�""W;(t�""-
Q t)Uf:llPefi \�1-0rldwideEducalionServices ww,Junopernel 9-18

·'4j�· -
J
lC"'i'IO'l!O
Task Verification
As mentioned during the tips, tricks and caveats section, CoS tasks are hard to verify, a lot of trust
has to be put in the configuration made. With a policer configuration since is not an option to
generate the amount of traffic needed to trigger the policer. With that said if a quick way to check
that the filter is applied, the show interfaces filters command should satisfy that need.

Summary
• Identified the Cos technologies covered for the JNCIE-SP
exam
• Reviewed the Cos process in a router
• Explained any caveats. tips, and trict\s for the Cos section of
the JNCIE-SP exam
• Walked through a sample task
�UfilRJj �" "' '

WorldwideEducationServices wwwJu"'p"net 1 9·19
-illi;,__ a

The Cos subjects covered in the JNCIE-SP exam;
The Cos process in the Junos operating system; and
Various caveats, tips, and tricks for the Cos section of the exam.

Lab 9: Class of Service Implementation and

roubleshooting
• Configure and verify CoS schedulers.

• Configure and verify multifield classifiers.
• Configure and verify behavior aggregate classifiers.
• Configure and verify ingress policers.
• Work with various marking methods.

have 1 hour to complete this lab.
"""""""
tJUffilf.(;Ji WorldwideEducationServices -�1un1pornet I s-20
�"
Lab 9: Class of Service Implementation and Troubleshooting

The slide lists the objectives of the lab.

Jun1pe_rI ·, - ....,
Chapter 10: MPLS Implementation

Chapter Objectives

able to:
• Explain LOP and RSVP signaling
• Describe CSPF with IS-IS and OSPF
• Explain advanced LOP and RSVP concepts
• Describe LSP path selection using routing policy

LDP and RSVP signaling;
CSPF with IS-IS and OSPF;
Advanced LDP and RSVP concepts; and
LSP path selection using routing policy.
Chapter 10-2 • MPLS Implementation www.juniper.net

Agenda: MPLS Implementation
� MPLS Implementation
MPLS Implementation
www.juniper.net MPLS Implementation • Chapter 10-3

MPLS Overview
• MPLS uses labels to forward traffic

• Label values can be:
• Assigned manually
• Dynamically assigned using label distribution protocols
• Label values are changed at each segment in the path
• The LSR will remove t11e incoming label and replace it with an
outgoing label as traffic traverses
• Labels are only locally significant
• The MPLS family must be enabled on an interface to
send and receive MPLS packets
MPLS Labels
MPLS labels can be either assigned manually or set up by a signaling protocol running in each
label-switching router (LSR) along the path of the label-switched path (LSP). Once the LSP is set up,
the ingress router and all subsequent routers in the LSP do not examine the IP routing information in
the labeled packet-they use the label to look up information in their label forwarding tables.
MPLS label values change at each segment of the LSP. A single router can be part of multiple LSPs.
A router can be the ingress and egress router for one or more LSPs, and it can also be a transit router
of one or more LSPs. The functions that each router supports depend on the network design.
The LSR replaces the old label with a new label in a swap operation and then forwards the packet to
the next router in the path. When the packet reaches the LSP's egress point, it is forwarded again
based on longest-match IP forwarding.
There is nothing unique or special about most of the label values used in MPLS. Labels have local
significance, meaning that a label value of 10254, for example, identifies one LSP on one router, and
the same value can identify a different LSP on another router.
Interface Configuration
The default behavior of an interface is to accept IP packets. In the Junos operating system, this
configuration is done by adding the family inet protocol with an IP address to the interface with
which you are working. For the interface to recognize, accept, and send MPLS packets, you must also
configure the MPLS protocol family under the interfaces participating in your MPLS domain.

Label Distribution Protocols

• LOP
• Follows IGP best path
• No traffic engineering
• Allows extended discovery (LDP tunneling)
• Allows traffic engineering to be applied to LDP traffic
• Must enable loo in LDP on both ends of tunnel
• Configured to signal over specific RSVP LSPs
• RSVP
• Allows for custom EROs
• Allows traffic engineering
• Administrative groups
• Traffic protection
• Priority and preemption
• Bandwidth reservation
LDP
The LDP signaling protocol always establishes LSPs that follow the contours of the interior gateway
protocol's (IGP's) shortest path. LDP supports topology-driven MPLS networks in best-effort,
hop-by-hop implementations. Traffic engineering is not possible with LDP. You can tunnel LDP LSPs
over RSVP-signaled LSPs using label stacking. Tunneling LDP through a RSVP LSP allows you to apply
traffic engineering to the portions of your LDP LSP that are being tunneled. Note that you must
enable LDP on the loO. O interfaces to support extended neighbor discovery needed for this
application. Additionally, you must configure the LSPs over which you want LDP to operate by
including the ldp-tunneling statement.
RSVP
The Junos OS supports the extended version of RSVP as the signaling protocol for traffic engineered
LSPs. RSVP provides a tool that consolidates the signaling procedure for a number of tasks or
objects into a single message exchange. These messages can establish an LSP along an explicit
path using an explicit route object (ERO), distribute label-binding information, provide LSP and traffic
protection features, prioritize LSP establishment, and reserve network resources.

RSVP Path Selection
• Default path selection

• Uses the IGP to determine best path
• Path manipulation using EROs
• Define the path to signal LSPs
• Path can contain strict hops. loose hops. or a combination
• Strict hops specify the exact path
• Loose hops use the IG P to route to the specified hop
".
Default RSVP Path Selection

By default, the path that the MPLS LSP session takes depends on the IGP shortest path calculation.
The default path selection can be altered by defining an ERO.
Using EROS
By adding the ERO to the path message, the ingress LSR can specify a predetermined, explicit path
for the LSP that is independent of the JGP's shortest path perspective. You can define a strict or
loose list of routers that RSVP path messages must visit. The ERO can contain strict hops which
indicate the exact path to use, loose hops which indicate the LSP must traverse this hop before
reaching the egress, or a combination of strict and loose hops in the same ERO.

Traffic Engineering Database
• The traffic engineering database provides CSPF with

up-to-date topology information
• Contains network information
• Current reservable bandwidth
• Populated by IGP advertisements
• OSPF Type 10 LSA
• IS-IS extended TlVs 22 and 135
• IGP must have traffic engineering enabled

• OSPF requires additional configuration for traffic
engineering
• IS-IS has traffic engineering turned on by default
jl-'">� ..�
Worldwide
',J'=
Education Services wwov Juniper net 10-1
J
t - �
Traffic Engineering Database

The traffic engineering database provides the Constrained Shortest Path First (CSPF) with up-to-date
topology information. The information stored in the traffic engineering database includes attributes
associated with the state of network resources (such as total link bandwidth, reserved link
bandwidth, available link bandwidth, and administrative groups).
Both OSPF and IS-IS propagate traffic engineering information through an extension of their link
state protocol. OSPF uses Type 10 opaque link-state advertisements (LSA) to carry traffic
engineering extensions. IS-IS carries extended time/length/value (TLV) information within the
link-state PDU to propagate traffic engineering extensions.
Both OSPF LSAs and IS-IS link-state PDUs have a limited flooding scope confining the traffic
engineering database to a single area or level. This limited flooding scope limits the traffic
engineering database to a single area or single level IGP topology. IS-IS and OSPF basically support
the same traffic engineering parameters including maximum link bandwidth, maximum reservable
link bandwidth, traffic engineering metrics, and administrative group membership.
IGP Traffic Engineering

For the IGP to support traffic engineering, it must be enabled. You must enable traffic engineering for
OSPF through manual configuration. IS-IS has traffic engineering enabled by default.
www.juniper.net MPLS Implementation • Chapter 10- 7

CSPF
• The CSPF algorithm and traffic engineering database
are used to calculate the best path to signal a RSVP
LSP
• CSPF combines the traffic engineering database with user
constraints
• Bandwidth requirements
• EROs
• Prunes non-qualifying paths and performs SPF on remaining
links
• Does not span multi-area (OSPF) or multi-level (IS-IS)
topologies
• Can be turned off using the no-cspf option
• Option available on a per-LSP or global basis
The CSPF Algorithm

The ingress router determines the physical path for the LSP based on a modified shortest path first
algorithm which runs against the traffic engineering database. The database is first modified based
on user constraints including bandwidth requirement, strict or loose transit points, and
administrative groups. These constraints are applied to the traffic engineering database and links
are pruned before running the shortest path first (SPF) calculation. If a valid path is calculated, SPF
will create a strict hop ERO, which is then passed to RSVP for signaling.
The CSPF computation cannot span multiple areas or multiple levels because CSPF relies on the
traffic engineering database to provide user specified constraints. By default, CSPF is enabled in the
Ju nos OS. You might want to disable the CSPF computation when all nodes do not support the
necessary traffic engineering extensions. To disable the CSPF computation, include the no-cspf
statement. You can disable the CSPF computation on a per-LSP or global basis.

Administrative Groups
• Typically named with a color and assigned a 0-32 bit value
• Names are locally significant
• Only bit value is transmitted
• Often referred to as link coloring
• You can choose to include. exclude. or do nothing with links
configured with a particular group narne
• If you include a named group. only those segments are selected
• If you exclude a named group. all segments with that color are
ignored during path selection
• If you do nothing. the metric associated with the named group
determines the patl1 cost for that segment
Administrative Groups
Administrative groups allow you to constrain the routing of an LSP to the set of links that meet the
prescribed administrative groupings. Each interface can support 32 different administrative groups.
The administrative groups associated with each interface is communicated through the extended
IGP for storage in the traffic engineering database.
If you use administrative groups, we recommend that you configure them identically on all routers
participating in an MPLS domain. Great confusion results when a pair of routers do not agree on the
color associated with a mutually attached link. Note that the actual group name is for local reference
only, which means that the exact spelling and case need not be identical between all routers in the
traffic engineering domain because only the bit value is transmitted to the traffic engineering
database. You can assign more than one administrative group to each physical link, or you might opt
to leave one or more links uncolored, by not assigning any administrative group values.
These names are often assigned as colors, but they do not have to be a color; they can be any
descriptive term you want. Each link can have one or more bits enabled, and can therefore be
associated with one or more colors simultaneously. The colors advertised by each link are displayed
in both hexadecimal and in symbolic form in the output of show ted database extensive
command.
You can choose to include, exclude, or do nothing with a particular administrative group. The two
options for including groups in a LSP path computation are include-any, and include-all. If
you omit the include-any, include-all, and exclude statements, the LSP's path calculation
proceeds unchanged, using the default CSPF path selection criteria.

Traffic Protection (1 of 2)
• Multiple manual paths

• Primary path (optional)
• Revertive capabilities (default)
• Secondary path (optional)
• All secondary paths are equal (non-revertive)
• Standby option pre-establishes the secondary path
• Fast reroute
• LSP builds detour paths
• Temporary mechanism to reduce effects caused by a LSP failure
• Requires CSPF on downstream routers
• Detour paths immediately available
• Configured on ingress router only
• Does not honor bandwidth reservations
- --� "'*'�rm
JUCllPer. ,Worldwide Education Services www Jun,per net J 10·10
��. «�:»..
Manually Created Alternative Paths

An individual label-switched path (LSP) can have an optional primary path applied. When it is
configured, only one primary path is permitted and it must be used if available, by default. So, the
LSP will always revert back to the primary path when stable and available. If the primary path fails
and a secondary path is configured, traffic will fail over to the secondary path. Like primary paths,
secondary paths are also optional. By default, a secondary path becomes active when a primary, or
another secondary, physical path fails. Secondary paths are considered equal and are signaled in
the order that they appear in the router configuration. This equality makes secondary paths
non-revertive in nature. You can specify the standby command for a secondary path, which causes
the router to signal the secondary path.
Fast Reroute
The fast reroute operation establishes detour paths within each router of the main LSP to protect
against failure of its next downstream link or router. When a downstream failure is detected by the
upstream router, the router begins forwarding the LSP traffic along the detour path and sends a
Path Err message upstream. The fast reroute detour path serves as an interim transport until a new
LSP can be established. Upon receiving the error message, the ingress router attempts to re-signal
the primary path or moves the LSP traffic to a secondary path, depending on the configuration. Once
a new path has been established by the ingress router, the original LSP along with the detours are
torn down. Each downstream router will use CSPF to calculate its own detour path to the egress
router using only administrative groups as user constraints and does not honor any bandwidth
reservations that might be configured.

Traffic Protection (2 of 2)
• Link protection
• Creates a bypass LSP to protect a downstream link
• Add link protection for the LSP on the ingress router
• Add link protection on all downstream RSVP interfaces to be
protected
• Add user constraints to tl1e bypass LSP like EROs. administrative
groups. and bandwidth reservations
• Node protection
• Creates a bypass LSP to protect a downstream router
• Add link-node protection for the LSP on the ingress router
• Add link protection on the egress RSVP interface before the
downstream router to be protected
• Add user constraints to the bypass LSP like EROs. administrative
groups. and bandwidth reservations
Link Protection
A link protection environment creates a bypass LSP from each router to its immediate downstream
router avoiding the downstream link. The bypass LSP is created as a function of RSVP on each router
where link-protection is configured on the RSVP interface. During a failure, the next upstream router
or the point of local repair will perform a label swap to place the downstream router's label into the
MPLS header. The router then performs a label push operation adding the bypass LSP label as the
outer label, and the packet is forwarded onto the bypass LSP. The penultimate router of the bypass
LSP pops the outer label and the packet is forwarded to the downstream router with the locally
significant label. Link protection must be configured on all the downstream interfaces to be
protected. When configuring link protection on the interfaces you can specify user constraints like
EROs, administrative groups, and bandwidth reservation to be observed when establishing the
bypass LSP.
Node Protection
A node protection environment is similar to the link protection environment in that a bypass LSP is
created to avoid the immediate downstream router. The bypass LSP is created as a function of RSVP
on each router where node-protection is enabled on the RSVP interface. The same swap/push
operation is performed except the label swapped is the label of the next downstream router of the
protected router.
Use the show rsvp interface extensive command to see the presence of a bypass LSP on
the transit node. Note that link protection is an RSVP feature, and as a result, the resulting bypass
LSPs are not listed in the output of show mpls lsp commands.

LSP Priorities and Preemption
• Default priorities prevent preemption

• Priority values range from O (strong) to 7 (weak)
• Default setup priority is 7
• Default hold priority is O
• High priority LSPs are signaled first
• Hold priority must be equal to or stronger than setup priority
LSP Setup and Hold Priorities

RSVP-signaled LSPs support the notion of LSP setup and hold priorities. These priorities work
together to determine the relative priority of a new LSP that must be established versus the hold
priority of existing LSPs. When insufficient resources exist to accommodate all LSPs simultaneously,
an LSP with a strong setup priority preempts-or causes the teardown-of an existing LSP with a
weaker hold priority. At software startup, LSPs are signaled in order from strongest to weakest setup
priority; this behavior ensures that high-priority LSPs are established first and are afforded optimal
paths.
LSP setup and hold priorities range in value from O (the strongest) to 7 (the weakest). The default
settings disable preemption by assigning all LSPs the weakest setup priority (7) and the strongest
hold priority (0). Note that you cannot commit a configuration in which an LSP's hold priority is less
(weaker) than its setup priority because such a configuration can lead to preemption churn. Modified
LSP priority values are displayed in the output of a show mpls lsp extensive command.
In normal operation, a preempted LSP is torn down before a new path is located. During this process,
traffic associated with the preempted LSP can be lost. To avoid traffic loss, the Ju nos OS can specify
soft preemption behavior on a per-L SP basis. Soft preemption attempts to establish a new path for a
preempted LSP before tearing it down.

Bandwidth Reservation
• Configured on a per RSVP LSP basis

• Each router along the path verifies availability of the request
• If any one router cannot support the requested bandwidth. the LSP
creation will fail
• No traffic policing by default with bandwidth reservations
• Firewall policers can be used on the ingress router
• The MPLS auto-policing option can be used on the ingress
router
,,.,..,...
u�nm ,\"[_�rld�ide Education Services
"" ".tr�M.i=.-; �
WWWJunopernet I 10-13
Bandwidth Reservation
You can configure an LSP to reserve bandwidth along the path of the LSP. During the setup process
for an LSP configured for bandwidth, each downstream router will receive a request to reserve
bandwidth for the LSP in the form of the traffic specification (TSpec) object. Each router along the
path will make its own individual decision as whether it has enough available bandwidth on its
egress interface for the LSP. To determine whether enough bandwidth is available, a router will sum
the bandwidth of all LSPs traversing the egress interface and subtract it from the total bandwidth for
the interface. If not enough bandwidth is available, the LSP will fail to be instantiated and the
upstream routers will be informed with a Path Err message. This behavior can be changed by altering
the default setup and hold priorities as mentioned on the previous page.
By default, the bandwidth reservation configured for a LSP is only logical and used for LSP setup . The
amount of traffic that actually traverses an LSP is not enforced. It is possible, however, to override
the default behavior and have the ingress router police the traffic that enters an LSP. This can be
done by configuring MPLS for auto-policing or configuring a firewall filter an applying directly to
the specific LSP. If you have multiple LSPs with bandwidth reservations and you do not want the
auto-policing feature to be applied, you must turn off auto-policing for that specific LSP
using the no-auto-policing option under the LSP policing level.
www .juniper.net MPLS Implementation • Chapter 10-13

Automatic Bandwidth Provisioning
• Network automatically adjusts bandwidth

• Gathers statistics about LSP usage
• Monitors usage every 300 seconds by default
• Re-signals a LSP if necessary over a specified time frame
• Default re-signaling interval is 24 hours
• Uses make-before-break and shared explicit style reservations
Automatic Bandwidth Provisioning

Auto-bandwidth provisioning allows the router to monitor actual traffic usage on each LSP and
reconfigure the bandwidth of a given LSP to support observed traffic levels.
The MPLS statistics feature gathers statistics that are used to support automatic bandwidth
calculations. The router monitors the highest utilization levels for the LSP over a predefined time
period (24 hours by default). At the end of the time period, the existing LSP is resignaled, using
make-before-break and shared explicit (SE)-style reservations to provision a new bandwidth
reservation of the LSP.

Point-to-Multipoint LSPs
• RSVP LSP with one ingress and multiple egress points

• Packet replication happens when packets need to take two
different paths (branches)
• Branches can be added and removed without disrupting
traffic
• Branches can be configured statically. dynamically. or as a
combination
• Supports link protection (no fast-reroute)
,, . u1.:1nmr:-,;, �orl�ide
�ll'jl'�
""" -
Education Services WWW Junop,.n,t I 10-15
A point-to-multipoint MPLS LSP is an RSVP LSP with multiple destinations. By taking advantage of
the MPLS packet replication capability of the network, point-to-multipoint LSPs avoid unnecessary
packet replication at the ingress router.
A point-to-multipoint LSP allows you to use MPLS for point-to-multipoint data distribution. This
functionality is similar to that provided by IP multicast. A branch can be added or removed from the
main point-to-multipoint LSP without disrupting traffic. The unaffected parts of the LSP continue to
function normally. A router can be configured as both a transit and an egress router for different
branch LSPs of the same point-to-multipoint LSP. Link protection can also be used with
point-to-multipoint LSPs. Link protection can provide a bypass LSP for each of the branch LSPs that
make up the LSP. If any of the primary paths fail, traffic can be quickly switched to the bypass.
Point-to-multipoint LSPs can be configured either statically, dynamically, or as a combination of static
and dynamic LSPs.

LSP Authentication
• RSVP
• MD5 authentication available
• Configured at the RSVP interface level
• All RSVP messages are authenticated
• LDP
• MD5 authentication available
• Configured at the session level
• Applies to session messages only. not neighbor discovery
• If authentication is applied to a established session. the session
will reset and resignal
RSVP Authentication
When needed, you can configure Hashed Message Authentication Code (HMAC)-Message Digest 5
(MD5) authentication for RSVP exchanges. RSVP authentication is configured on a per-interface
basis. Once configured, all RSVP messages are authenticated using a message digest based on a
shared secret key. Sequence numbers are added to all messages to prevent replay attacks. Confirm
that authentication is in effect using the show rsvp interface <interface-name>
detail command.
LOP Authentication
You can also configure MD5-based authentication for the TCP transport protocol that supports LOP
sessions. LOP session authentication is configured on a per-session basis. Note that LOP session
authentication does not apply to the UDP-based neighbor discovery mechanism. Thus, mismatched
LOP authentication settings permit LOP neighbor discovery and adjacency formation, but the LOP
session will not establish without compatible authentication values. Also, note that specifying
interface addresses under the session stanza requires the use of transport-address interface for
authentication to be in effect because LOP sessions form between loO addresses by default. If
authentication is applied after a session is already established, the session will be torn down and
reestablished using authentication.

TIL Manipulation
• Two options for TTL manipulation

•no-decrernent-ttl
• Juniper Networks proprietary: all LS Rs must support the option
• RSVP support for individual LSPs or as global MPLS setting
• No support for LOP
•no-propagate-ttl
• Global MPLS setting only
• RSVP and LOP support th is option
• Allows for interoperability with other vendors
�ulilm ,. z;,;,-,_
,o�pwldeEducatlonServices
-iii .
WWWJunopmet I 10·17
TTL Manipulation
By default, the time-to-live (TIL) value in the packet header is decremented by 1 for every hop the
packet traverses in the LSP, thereby preventing loops and allowing topology discovery. If the TIL field
value reaches 0, packets are dropped and an Internet Control Message Protocol (ICMP) error packet
can be sent to the originating router. You might want to disable normal TIL decrementing to make
the MPLS cloud appear transparent. thereby hiding the network topology.
The first option for TIL manipulation is using the no-decrement-ttl statement. The ingress
router negotiates with all downstream routers using a proprietary RSVP object to ensure all routers
are in agreement. This command can also be typed within the primary or secondary path hierarchy. If
negotiation succeeds, the whole LSP appears as two hops for transit IP traffic. Note that the RSVP
object is proprietary to the Ju nos OS and might not work with other vendors. Further. this feature
applies only to RSVP-signaled LSPs, and is not supported on LOP-signaled LSPs. You can apply
no-decrement-ttl on a per-LSP basis under the [edit protocols mpls
label-switched-path lsp-name] hierarchy or globally under the [edit protocols
mpls J hierarchy.
The second option is using the no-propagate-ttl statement at the [edit protocols
mpls J hierarchy level of all routers in the path of the LSP for proper operation, which is in contrast to
the ingress based setting for the no-decrement-ttl option. Note that the no-propagate-ttl
statement applies to all LSPs in a global manner. regardless of whether they are RSVP or LOP
signaled. Once set, all future LSPs traversing through this router behave as a single hop to IP
packets. LSPs established before this statement is committed are not affected.

Route Table Integration and Policy Control
• Only the LSP endpoint's /32 address is added to

inet. 3 by default
• Use the install option to add additional prefixes
• Include the active option to allow t11e prefix to be installed and
used in the inet. O table
• Policies can be used to control LSP selection
• Apply as an export policy to the forwarding table
• Use the action modifier that specifies the next-hop LSP to
install for specific routes
Altering the Default Routing Table Behavior

By default only the /32 prefix associated with the egress point of the label-switched path (LSP) is
installed in the inet.3 routing table. You can add additional prefixes to the inet. 3 routing table by
using the install <prefix> option under the LSP you are configuring. You can also add this
prefix to the inet. 0 routing table by including the active tag. Adding the prefix to inet. O allows
the LSP to be used by BGP as well as the IGP.
Policy Control with LSPs

When multiple equal-cost LSPs to a destination exist, you can use policy to control which LSP is
installed in the forwarding table. This control provides fine-grained engineering of traffic flows across
equal-cost LSPs. Use the install-nexthop lsp lsp-name command as the action in a policy
statement, and then apply the export policy to the forwarding table.

MPLS Load Balancing
• LSP traffic load balancing

• Multiple equal-cost next hops over different interfaces to the
same destination
• Must create a policy to load balance
• Must apply the load balancing as an export policy to the forwarding
table
• The load balancing hash algorithm can be altered to use the first
MPLS label. the first two MPLS labels. the IP payload. or a
combination of these options
• Single next hop over an aggregated interface
• Aggregated interfaces load balance traffic by default
• The load balancing hash algorithm can be altered to use the first
MPLS label. the first two MPLS labels. the IP payload. or a
combination of these options
ijUfill,E,�jf:'wortdwide Education Services www 1, "P" net 1 10-19
"'"' ir..L._ '
LSP Load Balancing

Load balancing is used to evenly distribute traffic when the following conditions apply:
Multiple equal-cost next hops exist over different interfaces to the same destination;
and
A single next hop exists over an aggregated interface.
By default, only a single next hop is selected from the routing table and installed in the forwarding
table. To override the default behavior of the forwarding table, you can configure a load-balancing
policy and export this policy to the forwarding table, which will place the equal cost next hops in the
PFE's forwarding table. When load balancing is used to help distribute traffic, the Ju nos OS employs
a hash algorithm to select a next-hop address to install into the forwarding table. Whenever the set
of next hops for a destination changes in any way, the next-hop address is reselected by means of
the hash algorithm.
You can configure how the hash algorithm is used to load-balance traffic across a set of equal-cost
LSPs. The hash algorithm can be configured to use the first MPLS label, the first two MPLS labels,
the IP payload, or a combination of these options.
With a single next hop over aggregated Ethernet, the traffic is load balanced across all member links
by default, but you can alter the hash algorithm used to influence the actual member link
transporting the traffic. The hash options are the same as the multiple equal cost paths described.

MPLS with BFD
• RSVP
• BFD is configured for a RSVP LSP on the ingress router
• You can enable BFD for all LSPs or for specific LSPs
• BFD sessions originate only at the ingress router and
terminate at the egress router
• LOP
• You can enable BFD for the LDP LSPs associated with a
specific FEC
• You can configure an OAM ingress policy to enable BFD on a
range of FEC addresses
• Simple hello mechanism that detects failures in a network
�µfDm,.�
��«�C@,tl!'=®)
WorldwideEducalionServices wwwlun,pernet 110-2,i

=�-
Using BFD with RSVP

Bidirectional Forwarding Detection (BFD) is used as a periodic Operation, Administration, and
Maintenance (OAM) feature to detect LSP data plane faults. The BFD protocol is a simple hello
mechanism that detects failures in a network. Hello packets are sent at a specified, regular interval.
A neighbor failure is detected when the router stops receiving a reply after a specified interval.
When BFD is configured for an RSVP LSP on the ingress router, it is enabled on the primary path and
on all standby secondary paths for that LSP. You can enable BFD for all LSPs on a router or for
specific LSPs. If you configure BFD for a specific LSP, whatever values configured globally for BFD are
overridden. The BFD sessions originate only at the ingress router and terminate at the egress router.
When a BFD session for an RSVP LSP path goes down, you can configure the Junos OS to re-signal
the LSP path or to simply disable the LSP path. A standby LSP path could be configured to handle
traffic while the primary LSP path is unavailable. The router can automatically recover from LSP
failures that can be detected by BFD. By default, if a BFD session fails, the event is simply logged.
Using BFD with LDP

You can enable BFD for the LOP LSPs associated with a specific forwarding equivalence class (FEC)
by configuring the FEC address using the fee option at the [edit protocols ldp J hierarchy
level. Alternatively, you can configure an OAM ingress policy to enable BFD on a range of FEC
addresses. You cannot enable BFD LOP LSPs unless their equivalent FEC addresses are explicitly
configured or OAM is enabled on the FECs using an OAM ingress policy.

MPLS Pitfalls (1 of 2)
• RSVP
• MPLS family required on the interfaces
• Enabling correct interfaces in RSVP
• Correct LSP names
• LDP
• MPLS family required on the interface
• Correct interfaces in LDP
• CSPF and the traffic engineering database
• Does not work across multi-area or multi-level networks
• Fast reroute, link or node protection. and administrative
groups require CSPF
Common RSVP Pitfalls

You must ensure that you configure the MPLS family on all appropriate interfaces; otherwise, the
MPLS and RSVP messages will not be accepted by the interface. Ensure that you configure all the
correct interfaces under the RSVP protocol hierarchy. This will ensure that LSPs can signal through
the correct interfaces and establish the LSPs to meet the specified requirements. Make sure you
correctly configure the LSP names. When the LSP names are defined on an exam, you must ensure
that you create them as they are defined.
Common LDP Pitfalls

You must ensure that you configure the MPLS family on the appropriate interfaces; otherwise, the
MPLS and LDP messages will not be accepted by the interface. Ensure that you configure all the
correct interfaces under the LDP protocol hierarchy. This must be done correctly for the LDP LSPs to
signal through the correct interfaces and establish the LSPs to meet the specified requirements on
an exam.
Common CSPF and Traffic Engineering Database Pitfalls

Remember the scope of the traffic engineering database and CSPF. Remember that the traffic
engineering database is restricted to a single IS-IS level or OSPF area. Building an LSP through a
multi-level of multi-area network will require the no-cspf option to establish the LSP. However,
some functions require the use of the CSPF algorithm such as fast reroute, link or node protection,
and administrative groups.

MPLS Pitfalls (2 of 2)
• ERO
• Using the loose transit point might result in an invalid path
during network convergence
• If two separate paths are required, ensure that you specify
enough ERO hops to maintain separation
• Fast reroute versus link or node protection
• Understand the complete requirements of the task-fast
reroute does not reserve bandwidth
• Fast reroute creates a detour LSP
• Link or node protection creates a bypass LSP
Common ERO Pitfalls

Remember when building the primary and secondary ERO that a little ERO is good, but more is
better. Using a loose hop might solve the requirement initially, but might fail the requirement during a
network convergence, or not be established at all. When building separate paths for a primary and
secondary LSP path, use strict hops to ensure diversity.
Choosing the Correct Traffic Protection Mechanism

Ensure that you fully understand the requirements of the task when asked to implement traffic
protection. With fast reroute, you implement a temporary detour LSP while the LSP resignals a new
path. Fast reroute attempts to protect the entire path of a given LSP, while link protection and node
protection can be configured on a per-interface basis. You can create a bypass LSP that reserves the
bandwidth to ensure that the LSP still maintains the same reservations despite the failure of a link or
router downstream.

MPLS Time-Savers (1 of 2)

• Read all tasks in the section
• Plan your strategy for all tasks
• Draw your LSPs on the topology
• RSVP or LDP or botl1
• Mentally group tasks that rnakes sense together
• Use groups to apply the MPLS farnily to all sirnilar
interfaces
• Cut and paste cornrnands using the show display
set cornrnand
•protocols mpls interface all
• Remember to disable the management interface
• Use interface all where possible
' -�-,.,....,"'7(; �
JUfilm:.:��dwideEducationServices WWWJunope,net 110·23
Before You Begin Configuring the Router

Before you begin, read through the entire section and plan your strategy to address all tasks that
require configuration, and identify tasks that can be easily combined to save time. Use the network
maps and different colors to design the MPLS topology. This approach will give you a good idea of the
explicit routes required to complete each task-which routers require LOP, RSVP, or both, and which
interfaces must be associated with which protocol.
Simplify Configuration Steps

The initial configuration will require some common setup parameters including the family mpls
option on all of the logical interfaces. This configuration can be done for each logical interface on
each router, or a group can be set up with wildcards. Be careful when using groups; it can cause
problems later in the exam. Sometimes all routers will require MPLS and RSVP prolvcols to be
enabled on all interfaces. Use the interfaces all options when appropriate. Build the protocols
on one of the routers and use the show I display set command to cut and paste into the other
routers to save time.

MPLS Time-Savers (2 of 2)
• Take your time during the configuration phase

• Avoids unnecessary troubleshooting
• Make notes on topology
• Verifying behavior
• Take a structured approach by verifying key commands from
one router at a time
• Some verification commands can often be issued on a
single device to determine behavior for multiple devices
Take Your Time

Do not rush through configuring the tasks. Going too fast could cause you to overlook simple
configuration steps. This misstep can create some unnecessary troubleshooting, which will cost you
valuable time. Make notes on the topology, you should use the topology map to outline tasks and
interfaces required. Sometimes, a visual representation helps you see potential issues.
Verify Behavior
Take a structured and methodical approach to verifying your configuration. It makes sense to begin
with one device and verify that everything looks correct and then move on to the next router. In some
situations you can verify a feature from a single device.

Agenda: MPLS Implementation
• MPLS lmplen,entation
ijl!Jr)m;wJr1dWideEducatfonServices WWWJun<pernet I 10·25

;*4� ;, o»


Task and Topology

Core MPLS Network
C1-1 C3-2
Loopbacks
R1 - 192.168.1.1
R2 - 192.168.1.2
R3 - 192.168.1.3 C2-1 C2-2
R4 - 192.168.1.4
RS - 192.168.1.5 Customer t;$r.,--....__s:::,i.:�--I 1 ---t::J.=--:--,ecustomer
2 2
R6 - 192.168.1. 6
R7 - 192.168.1.7 C3-1
R8 - 192.168.1.8
R9 - 192 168 1 9 Customer@--,.,,·-- .. ..
3 R7
• Task:
• Create a RSVP LSP from R1 named r1-to-r9. that terminates
on R9·s loopback. Ensure that this LSP reserves 2 Mbps of
bandwidth across the network. You must also ensure that
traffic entering the LSP is limited to the bandwidth
reservation amount. All traffic in excess of the reserved
bandwidth should be dropped without using a firewall policer.


What Now?

• Connectivity
• IGP route to egress router's loopback
• MPLS enabled on all interfaces
• Interfaces added to the MPLS protocol
• Interfaces added to the RSVP protocol
• LSP configured that terminates on the egress router's
loopback
• Bandwidth reservation applied to the LSP reserving 2 MB
• All the LSPs path links must have at least 2 MB
unreserved bandwidth
• Apply the au to-pol icing option to the MPLS protocol
"""""'.
LJQr:lm;�:W,orldwide Education Services www Ju nip er net 1 10-21
�.w - ..

The slide illustrates the required steps to accomplish the sample task.

• Step 1: Initial verification

• Verify connectivity
lab@Rl> show route 192 .168.1.9
inet.0: 35 destinations, 35 coutes (35 active, holddown, 0 hidden)
192.168.1.9/32 *[OSPF/10] 00:16:56, metcic 1
> to 172.27.0.9 via ge-0/0/1.0
• Verify interface
[edit]
lab@Rl# show interfaces ge-0/0/1
unit O (
family inet (
addcess 172.27.0.14/30;
family mpls;
• Verify protocol configuration

[edit]
lab@Rl# show protocols mpls
inte cface all;
[edit]
=
lab@Rl# show protocols rsvp
intecface all;
LJL:JQIP8(\;. W?!ldwide EducalionSel\lices
,.< >, "' '-'� ,qf ;--S,,"'::ft'<'z<jc
@2\1;!.Zlonl�•Olel,'!o<ksdni;-l!\llogt,tJ,.,-..,JI www Jun,per net 1 10-2e
Initial Verification
The slide shows the commands and outputs to verify the first few steps.

• Step 1: LSP configuration

[edit pcotocols mpls]
lab@Rl# set label-switched-path rl-to-r9 to 192.168.1.9 bandwidth 2m

lab@Rl# set auto-policing class all drop

lab@Rl# show
auto-po lie ing
class all dcop;
label-switched-path cl-to-c9 {
to 192.168.1.9;
I
ban dwidth 2m; I
intecf ace all;

lab@Rl# commit and-quit
commit complete
Exiting configucation mode
lab@Rl>
Configuration Steps
The slide shows the command to configure the LSP and apply the bandwidth reservation, as well as
the command to configure auto-policing.

• LSP verification
lab@Rl> show mpls lsp name r1-to-r9 detail
Ingress LSP: 1 sessions
192.168 .1. 9
From: 192.168.1.1, !state: Up,! ActiveRoute: 0, LSPname: cl-to-c9
ActivePath: (primacy)
LSPtype: Static Configured
Loa dBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primacy State: Up
Pciocities: 7 0
!Bandwidth: 2Mbps !
SmactOptimizeTimec: 180
Computed ERO ( S [L] denotes stcict [ loose] hops) : (CSPF mete ic: 1)
172.27.0.9 S 172.27.0.22 s
Received RRO (PcotectionFla g l=Available 2=InUse 4=8/W B=Node lO=SoftPceempt
20=Node- ID)
172.27.0.9 172.27.0.22
Total 1 displayed, Up 1, Down O
LSP Verification
The slide displays the status of the LSP that was just created. As you can see, the LSP is up and
functioning. You can also see that 2 Mbps of bandwidth is being reserved.

• Reservation verification
lab@Rl> show rsvp interface
RSVP interface: 7 active
Active Subscr- Static Available Reserved
Highwater
Interface State resv iption BW BW BW mark
ge-0/0/ l. 0 Up 100% lOOOMbps 998Mbps 2Mbps 2Mbps
• Pol icer verification

lab@Rl> show interfaces ge-0/0/1 extensive I match "output bytes"
Output bytes 1539377364 !2103304 bps I
Output bytes 1524736484
Output bytes 31435434
Output bytes 149330105 0 2102392 bps
� �i':""� ·�
. �un1Per,:
,<"' Mt Worldwide Education Services Juniper net I 10-31
�· ->.-;..== WWW
Verify the Reservation

The command shown on the slide can be used to show bandwidth reservations in effect on all RSVP
interfaces.
Verify the Policer

This step cannot be verified without actual traffic traversing the network. This output was taken with
3 Mbps of traffic being sent through the LSP. You can see that the auto policer is dropping excess
traffic at the ingress router and limiting the traffic to the 2 Mbps being reserved.

Summary
• Explained LDP and RSVP signaling
• Described CSPF with IS-IS and OSPF
• Explained advanced LDP and RSVP concepts
• Described LSP path selection using routing policy
".

LDP and RSVP signaling;
CSPF with IS-IS and OSPF;
Advanced LDP and RSVP concepts; and
Label-switched path (LSP) path selection using routing policy.

Lab 10: MPLS Implementation and

Troubleshooting
• Configure and monitor RSVP LSPs.

• Configure and monitor LOP LSPs.
• Configure and verify various traffic engineering
options.

UtJri"!� :��clwideEducationServices wwwJuo,pemt 1 10·33

� 0.:t t: ,.,._; '"'
Lab 10: MPLS Implementation and Troubleshooting



Jun1.�;��r
Chapter 11: MPLS VPN Implementation

Chapter Objectives

able to:
• Demonstrate Layer 3 VPNs
• Explain 1Pv4 and 1Pv6 Layer 3 VPNs
• Explain interprovider Layer 3 VPNs
• Describe carrier-of-carrier Layer 3 VPNs
• Outline BGP or LOP signaled VPLS and Layer 2 VPNs

Layer 3 VPNs;
1Pv4 and 1Pv6 Layer 3 VPNs;
lnterprovider Layer 3 VPNs;
Carrier-of-carrier Layer 3 VPNs; and
BGP or LDP signaled VPLS and Layer 2 VPNs.
Chapter 11-2 • MPLS VPN Implementation www.juniper.net

Agenda: MPLS VPN Implementation
� Layer 3 M PLS VPNs

• lnterprovider and Carrier-of-Carrier Layer 3 VPNs
• Layer 2 VPNs and VPLS
Layer 3 MPLS VPNs

www.juniper.net MPLS VPN Implementation • Chapter 11-3

layer 3 VPN: Terms and Concepts (1 of 2)
• Layer 3 VPNs
• Includes CE devices
• Reside on t11e customer premises
• Includes PE devices
• Maintains VPN-specific forwarding tables
• Exchanges VPN routing information with other PE routers using
BGP
• Uses MPLS LSPs to forward VPN traffic
• Can include P devices
• Forward VPN data transparently over establisl1ed LSPs
• Do not maintain VPN specific routing information
".
Layer 3 VPNs
Customer Edge (CE) routers are located at the customer location and provide access to the
provide r -provisioned VPN (PP-VPN) service. CE routers can interface to Provider Edge (PE) routers
using virtually any Layer 2 technology and routing protocol.
PE routers are located at the edge of the provider's network. They interface to the CE routers on one
side and to the provider's core routers on the other. PE routers maintain site-specific VPN route and
forwarding (VRF) tables. The PE and CE routers function as routing peers, with the PE router
terminating the routing exchange between customer sites and the provider's core. Routes learned
from the CE routers (and stored in the PE router's VRF table) are sent to remote PE routers using
Multiprotocol Border Gateway Protocol (MP-BGP). PE routers use MPLS label-switched paths (LSPs)
when forwarding customer VPN traffic between sites. LSP tunnels in the provider's network separate
VPN traffic in the same fashion as PVCs in a legacy ATM or frame relay network.
Provider (P) routers are located in the provider's core. These routers do not carry VPN customer
routes, nor do they interface in the VPN control and signaling planes. This setup is a key aspect of
the RFC 4364 scalability model; only PE routers are aware of VPN customer routes, and no single PE
router must hold all VPN customer state information. P routers are involved in the VPN forwarding
plane, where they act as label-switching routers (LSRs) performing label swapping (and popping)
operations.

Layer 3 VPN: Terms and Concepts (2 of 2)
• Sites and tables

• VPN sites
• Collection of devices that communicate with each other without
using the service provider backbone
• Each site is mapped to a PE device interface
• VRF table
• Populated with routes received from directly connected CEs. and
routes received from other PE routers with MP-BG P attributes
• Packets from a given site are only matched against the routes in a
site· s corresponding VRFtable
VPN Sites and VRF Tables

A VPN site is a collection of devices that can communicate with each other without the need to
transit the provider's backbone. A site can range from a single location with one router to a network
consisting of many geographically diverse routers.
Each VPN site is attached to at least one PE router and can be dual-homed with multiple connections
to different PE routers. Each site is associated with a site-specific VRF table in the PE routers. The
VRF tables store routes learned from the attached site, as well as routes learned through MP-BGP
interaction with remote PE routers. In the latter case, VPN policy determines which routes are copied
into which VRF tables based on the presence of a VPN-1Pv4 route attribute known as a route target.
When a packet is received from a given site, the PE router performs a longest-match Layer 3 lookup
against only the entries housed in that site's VRF table. This separation permits duplicate addressing
among VPN customers with no chance of routing ambiguity.

PE to PE Exchanges
• MPLS LSPs core
• MP-BGP next-hop attribute
• Must resolve in inet.3 routing table
• Label swap operation
• Layer 3 VPN NLRI
• PE to PE exchanges require the VPN-1Pv4 NLRI
• Mask. MPLS label. route distinguist1er. and 1Pv4 prefix
• Ingress PE router prepends route distinguisher to 1Pv4 prefix
of routes received from each CE device
• VPN-I Pv4 routes are exchanged between PE routers using
MP-BGP
• Egress PE router converts VPN-1Pv4 routes into I Pv4 routes
before inserting into site's routing (VRF) table
MPLS in the Core

All routes received from a VPN MP-IBGP peer must resolve the BGP next-hop attribute in the inet. 3
routing table. If an LSP is not established to the remote PE router, the routes will not be installed in
the bgp. 13vpn table. Entries in the inet.3 table are normally installed by the RSVP or LDP signaling
protocols.
Layer 3 VPN NLRI

A Layer 3 VPN uses a special format for representing customer routes within the provider's network.
The VPN network layer reachability information (NLRI) contains a 24-bit MPLS label, which is
sometimes called a VRF label because the label's function is to associate packets with a particular
VRF instance in the receiving PE router. Once the address VPN family is explicitly configured on a
BGP session, the default 1Pv4 family must also be explicitly configured if the router is expected to
advertise and receive both 1Pv4 and VPN routes. VPN addresses also contain a route distinguisher
field, which is used to disambiguate VPN routes.
Labeled VPN routes are exchanged over the MP-BGP sessions, which terminate on the PE routers.
A 32-bit 1Pv4 prefix combined with the other fields in a VPN-1Pv4 address produce a VPN-1Pv4 prefix
with a mask of 120 bits. The Ju nos operating system only displays the mask for the 1Pv4 prefix
portion of the prefix. Thus, in this case, the operation would see a VPN-1Pv4 prefix with a mask length
of /32.

VRFTables
• Separate customer routing tables

• Local and directly connected routes
• Customer learned routes
• Routes received from other PE sites
• Route distinguisher
• Maintain unique routing information
• Two values are defined for type field: O and 1
• Type O: adm field = 2 bytes. AN field = 4 bytes
• Type 1: adm field = 4 bytes. AN field = 2 bytes
• Route target information
• Extended BGP community
• Import and exporttarget
i--��
l.
..
�WnlPef;' wo'rtdwide Education Services
��-�
....,_ , -
WW�Jun,pe,net I 11-7
Customer VRF Tables

Each local PE router maintains a separate VRF table for each customer connected to it and contains
that customers specific routing knowledge. Customer routes advertised to the PE are placed in the
VRF table. All routes in the customer's VRF table are advertised to remote PE router, which places
them in the appropriate VRF table for advertisement to its locally connected customer.
Route Distinguisher
The route distinguisher is an 8-octet field applied to all customer prefixes before being advertised in
the VPN-1Pv4 NLRI. A unique route distinguisher must be configured within each VRF instance to
maintain customer prefix uniqueness within the network. A global route distinguisher can be
configured in the routing-options hierarchy, and the router will dynamically assign a unique route
distinguisher to each VRF instance. There are two labels used to define the route distinguisher value,
Type O and Type 1. The particulars for each type are outlined on the slide.
Route Target
The extended BGP route-target community is used to accept customer routes into the VRF table from
the bgp .13vpn. O table. Only routes with a route-target community that matches the import
community configured in the VRF instance will be installed in the VRF table. Therefore, routes
advertised from the remote PE router must be tagged with the appropriate extended route-target
information to function correctly. The import and export route-target information can be configured
as a global parameter or through policy.
www.juniper.net MPLS VPN Implementation • Chapter 11- 7

VRF Routing Policy
• Can create VRF import and export policies

• Controls the routes that are sent and accepted in a VPN
• Compares incoming routes against the target community
• Adds the target community to routes before they are advertised
• Can apply the vrf-target option
• Automatically creates an import and export policy based on
the target community specified
• Routing instance auto-export
• Allows communication between VRF tables on the same PE
router by automatically sharing routes
• RIB groups
• Allows communication between VRF tables on the same PE
router by manually sharing routes
VRF Import and Export Policies

A VRF import policy only filters routes learned from remote PE routers through the MP-BGP peering
sessions. Import policies match BGP routes containing the VPN target community string.
A VRF export policy is only used to filter routes being advertised to remote PE routers through the
MP-BGP peering sessions. The policy should match routes learned from the protocol used to route
between the PE and CE. The policy should then add the VPN target community to the route before
accepting it for advertisement to the remote PE routers. Together, the two policies determine which
routes are advertised to remote PEs as well as accepted from remote PEs into the local VRF table.
The vrf-target Option

Using the vrf-target option automatically generates the VRF import and export policies that
accept and tag routes with the specified target community.
Using the auto-export Option

The auto-export option allows you to automatically share routes on the same PE between two
routing instances within the same VPN. This command causes the router to analyze some
combination of the vrf-irnport policy, vrf-export policy, and the vrf-target statements of
each VRF table that has the auto-export command configured. Any routes with the correct target
communities are then copied between these VRF tables.

Using RIB Groups

RIB groups can be used to share routes between routing tables. RIB groups allow users to manually
group one or more routing tables to form a routing table group. A routing protocol can import routes
into all the routing tables in the group and can export routes from a single routing table. Each routing
table group must contain one or more routing tables that the Junos OS uses when importing routes
(specified in the import-rib statement) and optionally can contain one routing table group that
the Ju nos OS uses when exporting routes to the routing protocols (specified in the export-rib
statement).

PE to CE Routing Protocols
• Static routing
• PE and CE routers configured with static routes
• BGP routing
• External BG P peering
• as-override
• origin community
• Internal BGP peering
• independent-domain
• OSPF routing
• Carries OSPF routes across backbone as BGP routes
• Two methods to advertise OSPF routes between sites
• sham-link
• domain-identifier
• RIP routing
��--
x xV�7-.="",,, �,
©��•••l1'•0l•lm\'k>,ln,:;A1Jniatt,,e,.��' •' ':)LJ(']�bWorldwideEducalionServices wwwJun,pernel 1 11-10
PE to CE Protocols: Static Routing

Using static routing to connect the CE to the PE router requires the explicit configuration of routes
with a next hop of the peer interface.
BGP Routing
BGP peering to the customer site from the provider can be an external or internal BGP session.
Using external BGP to connect the customer sites introduces the provider as a BGP hop within the
AS-path. If a customer is using the same autonomous system (AS) number at both sites, a problem
can arise with loop detection. When the as-override option is configured on the PE router, the
customer AS number in the AS-path is replaced with the provider's AS number when the route is
advertised to the customer site. The origin community can be used to avoid routing loops caused
when advertising routes back into a network where the routes were learned through another
connection.
Peering to the customer using IBGP requires a new BGP attribute called the ATIRSET to carry
customer attributes across the provider's network. This independent-domain option effectively
hides the provider's network from the customer by preserving and restoring all customer attributes.

OSPF Routing
Routes learned from the CE router using OSPF are exchanged with the remote PE router using
MP-BGP, requiring redistribution of the OSPF routes. This might not always be desirable because
OSPF external link-state advertisements (LSAs) are domain flooded. An OSPF sham link can be built
between the PE routers to essentially mock an OSPF unnumbered point-to-point link, allowing OSPF
packets to be tunneled and the exchange of LSAs. Although the PE router learns routes from the
remote PE router using OSPF, the OSPF SPF algorithm will not install them. A second method within
OSPF to reduce external LSAs is to setup an extended domain ID community between the PE routers,
allowing the preservation of summary (Type 3) LSAs.
RIP Routing
RIP can also be used to share routes between the PE and CE routers.

PE to CE Policies and Firewalls
• Import and export policies can be applied to VRF

instances for the PE to CE routing protocols
• BGP and RIP allow both import and export policies
• OSPF allows export policies and limits import policies that
set priority or filter OSPF external routes
• Reject action is ignored if applied to a non-external route on an
import policy
• Affects routes being sent and received over the PE-CE link
• Firewall filters can be applied to logical interfaces
PE to CE Routing Policy
In addition to the VRF import and export policies, which control the exchange of routes between PE
routers, you can also use routing policy to control the exchange of routes on the PE-CE routing
instance. Using BGP or RIP as a PE-CE routing protocol permits both import and export policies. OSPF
can also have export policies, but has limited functionality when implementing an import policy. You
can use OSPF import policy only to set priority or to filter OSPF external routes. If an OSPF import
policy is applied that results in a reject terminating action for a non-external route, then the reject
action is ignored and the route is accepted anyway. This behavior prevents traffic black holes-that
is, silently discarded traffic-by ensuring consistent routing within the OSPF domain. Routing policy
applied under the protocols portion of a VRF table only affects the routes being exchanged on the
local PE-CE link. To control the exchange of VPN routes between PE routers, VRF import and export
policies must exist.
PE to CE Firewall Filters
Firewall filters can be applied to the logical interfaces that are participating in a VPN instance. A
firewall filter must be applied to the interface configuration and will be applied to the VPN instance
as long as the interface and unit are defined for that instance.

VPN Considerations (1 of 2)
• Hub-and-spoke
• Reduces the number of BGP sessions and LSPs needed
• Spoke to spoke communication must transit tt1e hub site
• Requires two VRF instances on the hub site
• Requires two interfaces from PE to CE
• Can be logical interfaces on the same pt1ysical interface
• 1Pv6 VPNs
• PE to CE interfaces can be configured for 1Pv6
• Must enable inet6-vpn family for the MP-BG P session
• Must configure BG P. OSPF version 3. or static routes for PE to CE
routing
• Can operate in conjunction with 1Pv4 routing in the same
VPN
• �wnfi:5er:' -Worldwide Education Services

.�... "-�
WWW Ju nope, net I 11-13
Hub-and-Spoke Layer 3 VPNs

Layer 3 VPNs can be deployed in a hub-and-spoke topology in which remote sites communicate
through the hub site CE router. A hub-and-spoke VPN has the added advantage of reducing BGP
peering and LSP requirements in that spoke locations only require a single BGP session and LSP to
the hub site. For proper operation, the hub PE router requires two VRF instances. The spoke instance
receives routes from the spoke locations and conveys them to the hub CE router. The hub instance
receives routes from the hub CE router and redistributes them out to the spoke sites. A separate VRF
interface is required to back up each VRF instance in the hub PE router. In practice, this interface is
normally one physical interface with two logical units.
1Pv6 VPNs
You can configure IP version 6 (1Pv6) between the PE and CE routers of a Layer 3 VPN. The PE router
must have the PE router to PE router BGP session configured with the family inet6-vpn
statement_ The CE router must be capable of receiving 1Pv6 traffic. To support 1Pv6 routes, you must
configure BGP, OSPF version 3, or static routes for the connection between the PE and CE routers in
the Layer 3 VPN_ You can configure BGP to handle just 1Pv6 routes or both IP version 4 (1Pv4) and
1Pv6 routes.

VPN Considerations (2 of 2)
• vrf-table-label option
• Uses LSP sub-interface abstract
• Creates an LSI that maps to each VRFtable
• Supported core-facing interfaces map reserved MPLS labels to
eachVRF LSI
• Caveats:
• Only supported on limited interface types
• Not supported for MP-BG P-labeled routes (interprovider and
carrier-of-carrierVPNs)
• VPN tunnel interface
• Requires a tunnel services PIC
• Causes Internet Processor II lookups on the Egress PE
• Rather than forward tt1e packet directly out the physical VRF
interface. the resulting IP packet from the first lookup is sent to the
tunnel service interface (next hop equals the vt-x/y/ z interface)
Q
Using the vrf-table-label Option

The vrf-table-label feature uses the LSP sub-interface (LSI) abstract that allows an LSP to be
treated as an interface. When you configure the vrf-table-label option under a VRF routing
instance, an LSI is created for that VRF table. Supported core-facing interfaces assign a label from a
special range (currently 1024 through 2 048), which in turn is mapped to the VRF table's LSI. The
input FPC 1/0 Manager ASIC can now associate a packet with the correct VRF table, based on the
label-to-LSl-to-VRF mapping. This association allows the VRF label to be stripped at the egress router,
so that the Internet Processor II can perform a key lookup on the IP packet itself. This key lookup
supports Internet Processor II functions such as ARP generation, rate limiting, and firewall filtering.
The vrf-table-label feature is supported only on certain core-facing interfaces types.
LSI-based labels are not used for MP-BGP labeled routes to avoid operational problems with
carrier-of-carriers and interprovider VPNs.
The VPN Tunnel Interface

You can configure a VPN tunnel interface for the egress VRF table to perform Internet Processor II
functionality. To configure a VPN tunnel interface, a router must have tunnel services enabled. You
can enable tunnel services in simple configuration on an MX Series Ethernet Services Router, while
other routers require either a Tunnel Services or Adaptive Services PIC installed. With a VPN tunnel
interface configured, the PE router pops the label stack as expected. Before passing the remaining
packet to the CE device, as it usually would, the packet is passed through a logical VPN tunnel
interface. The packet is then sent back to the Internet Processor II from the VPN tunnel interface,
where the Internet Processor II performs the functions it could not perform on the first pass.

VPN Scalability
• Route reflection
• Reduces the number of MP-BGP sessions
• Typically configured on a P router
• Requires tl1e NLRI families be configured within t11e cluster
• The bgp .13vpn. inet. 0 table requires PE reachability
through inet. 3
• LDP or RSVP unidirectional full mesh
• Static default route
• Route target filtering
• PE sends a list of route targets locally configured to the
route reflector
• The route-target NLRI must be enabled on MP-BGP sessions
• Route reflector only sends routes with the specified route
targets to PE router
Route Reflection
The use of route reflection in a Layer 3 VPN topology can dramatically reduce the number of MP-BGP
peering sessions on the PE routers. The VPN route reflector requires the configuration of the
VPN-1Pv4 family and automatically keeps all received VPN routes in the bgp. l 3vpn. O table to
provide only control plane function. To install routes into the bgp. 13vpn. O table, the BGP next-hop
attribute must resolve to an LSP with an entry in inet. 3. LSP egress entries can be generated into
the inet. 3 table using the dynamic signaling protocols, LOP or RSVP, but because the route
reflector is not part of the data plane, a static default entry can be placed into the table.
Route Target Filtering

By default, a PE router receives all VPN routes from all BGP peers and ignores those that do not
match the VRF import policy. This filter becomes more pronounced in a route reflection environment
because the route reflector might serve a large number of PE clients. As mentioned before, a route
reflector will accept and install all VPN routes into its bgp. 13vpn. O routing table, which is reflected
to all clients. With route target filtering enabled, the PE routers advertises route target information to
the route reflector and only those routes which match are reflected to the PE router.

Providing VPN Internet Access
• Distributed Internet access

• Option 1: Two separate logical circuits
• One circuit configured in VRF
• One circuit configured for Internet
• Option 2: Two separate logical circuits
• VPN and inbound Internet traffic
• Separate circuit for outbound Internet
• Option 3: Single logical circuit
• All VPN Internet traffic on same interface
Internet Access
In a distributed Internet access model, a PE router provides connectivity to the Internet for its
connected CE router. In this environment, the provider has three main options for forwarding traffic
through the PE router.
The first two options require a separate logical circuit between the PE and the CE routers. In both
options, all VPN traffic is received and transmitted on the same circuit with the only difference being
forwarding of Internet traffic. In Option 1 all Internet traffic is sent and received on the same circuit,
while in Option 2 the Internet traffic is received on the VPN circuit but sent on a different circuit.
The third option uses a single logical circuit for both VPN and Internet traffic. As in Option 2, all
received VPN traffic will be routed to the appropriate PE and all Internet traffic will be routed to the
primary routing instance (inet. O). The primary issue in Option 3 is the return traffic from the
Internet. Because the customer interface is in the VRF routing instance, and the Internet traffic is in
the primary routing instance, routing information must be shared between the two.

ayer 3 VPN Pitfalls
• Common VPN mistakes

• Route target mismatches
• VPN routes received are compared against the local route target in
the import policy
• MP-BGP 1Pv4 families
• Configuring family inet-vpn overrides the default I Pv4 N LRI
(family inet)
• Scalability issues
• Route reflectors
• Route target filters
• MPLS LSPs
• VPN routes must resolve to inet. 3
1-N,:,l?,;<v•""t
UL!Jf:11Pef7.J!.Worldwide Education Services w�w iunipernet 1 11·17
�st- JktL.»-..:= - �
Common Mistakes
Route target import information must match the extended BGP target community in the VPN
advertisement. Use the show route receive-protocol bgp detail and show route
advertising-protocol bgp detail commands to troubleshoot route target mismatches.
The BGP keep-all option will also help by installing all VPN routes in the bgp. 13vpn. O table
regardless of route target information.
VPN routes are advertised using the VPN-1Pv4 NLRI, which must be negotiated between BGP peers
and is configured using the BGP family inet-vpn unicast command. When this family is
configured in BGP it overrides the default behavior of advertising standard 1Pv4 prefixes. If both are
required, they must both be configured.
Scaling IBGP using route reflectors and route target filters can reduce the number of peering
sessions and route advertisements. Route reflectors participate in the VPN control plane which
requires the VPN-1Pv4 NLRI and LSP resolution.
All VPN routes received must resolve to an LSP before they can be installed in the bgp .13vpn. o
table. Verify that the next-hop attribute can resolve to the inet. 3 table.

layer 3 VPN Time..savers
• Plan out your Layer 3 VPN strategy

• Identify the PE routers and verify that the necessary IBGP
neighborships are established
• Verify that MPLS and LSPs are signaled throughout the core
• Build the VRF routing instance
• CE interface configuration
• Route distinguisher and route target information
• CE to PE routing protocol
nServices v,;ww un1pernet I 11·18
Layer 3 Time-Savers: Plan Ahead

Identify the PE routers and verify that the IBGP and MPLS infrastructure is in place. Use the show
bgp sunnnary and show route table inet. 3 commands to verify the configuration. A stable
topology will make the VPN control process easier to troubleshoot if problems occur when
exchanging VRF information.
Build the VRF Tables

Configure the customer interface and establish CE to PE peering using the routing protocol specified
in the VPN task information. Verify customer reachability and routing information in the VRF table.

• Layer 3 M PLS VPNs

� lnterprovider and Carrier-of-Carrier Layer 3 VPNs
II
Layer 2 VPNs and VPLS
lnterprovider and Carrier-of-Carrier Layer 3 VPNs


lnterprovider VPN
• VPN requires two different AS networks

• Customer requires connectivity between two different ISPs
• Several options available:
• Option A: Unlabeled VPN-1Pv4
• Option B: Labeled VPN-1Pv4
• Option C: Multi hop MP-BG P
onServices wwwJunipernet I 11-:20
lnterprovider VPNs
lnterprovider VPNs provide connectivity when a VPN customer's sites are attached to different
service providers. In this environment, the PE routers in each AS connect to the VPN customer site
and an autonomous system boundary router (ASBR) connects the each provider's network. Three
options exist in the interprovider VPN scenario:
Option A describes a back-to-back pairing of ASBR using unlabeled EBGP between VRF
table to VRF table. This option requires a separate logical circuit between the ASBRs for
each VPN connection.
Option B describes a single MP-EBGP session between the ASBRs to exchange labeled
routes across the network boundary. This option requires an end-to-end LSP between
PE routers.
Option C describes an interprovider environment that hides the customer routes from
the provider's ASBR router. This option requires the leaking of the PE loopback address
to form a MP-EBGP session between the PE routers.

lnterprovider VPl'I: Option A and B
• Unlabeled VPN-1Pv4 (Option A)

• Requires a separate VRF table for each VPN
• Each VPN requires a separate routing instance
• PE must carry all customer VPN routes
• Does not scale
• Labeled VPN-1Pv4 (Option B)
• Does not require a separate VRF table for each VPN
• Limited scalability
• Requires the ASBRs carry VPN routes and state for transit MPLS
sessions
....
--·�"'"'�,ft'
fi'l�,i'�orfdwid�EducationServices .,.,w,un,p""'' 111-21
Option A: Unlabeled VPN-1Pv4

Option A is the least scalable of the three options. This option requires that the ASBRs maintain
separate VRFs and store all of the associated routes for every one of its customers. Although this
option is supported by the Junos OS, we do not recommend this solution.
Option B: Labeled VPN-1Pv4

With Option B, the ASBRs do not need to maintain separate VRF instances for each VPN. However,
the ASBR will still have to l<eep VPN routes in a single routing table, bgp .13vpn. O for L3VPN
routes. Through an EBGP session between one another, the ASBRs will then exchange VPN routes as
label routes. The EBGP advertised labels are used to stitch together the LSPs that terminate
between PE and ASBR.

nterprovider VPN: Option C:
• Multihop MP-BGP (Option C)

• ASBR only carries internal routes
• PE loopback addresses are leaked between ASBRs
• ASBRs use labeled-unicast family to assign labels
• ASBRs do not have a VRFtable
• Require a BGP session between PE rnuters
• EBG P sessions requiremul tihop
Option C: Multihop MP-BGP

This option is generally accepted as the most scalable solution for interprovider VPNs. This option
allows the PE routers in different ASs to exchange VPN routes (Layer 3 VPN, BGP Layer 2 VPN, or BGP
VPLS) using a multihop BGP session. The ASBRs do not need to store any VPN routes in this case.
Instead, the ASBRs will exchange the internal networks of each service provider (most importantly
the loop back addresses of the PEs) using labeled 1Pv4 routes. The labels associated with the internal
networks will be used to stitch together the MPLS LSPs that exist between PE and ASBR in the
service provider networks.

Carrier..of.. Carrie1r VPNs
• Carrier-of-carrier
• Generally connects two provider sites within the same AS
through another cari-ier AS
• Carrier PE routers maintain the provider's internal routes
• Carrier PE routers do not maintain customer external routes
• Provider routers maintain internal routes as well as external
customer routes
Carrier-of-Carrier Layer 3 VPNs

This model allows a carrier provider to offer a backbone service to a customer, another service
provider. Assume this customer is a new service provider that has a point of presence (POP) in a few
sparse locations with no backbone network to interconnect those POPs. The customer (the new
service provider) can purcl1ase the carrier-of-carrier service from the carrier provider to interconnect
its sites, making the customer network appear as a single AS without the carrier having to handle the
external routes learned by the provider.
The carrier's PE routers maintain both carrier internal routes and provider (carrier's customer)
internal routes. Customer-specific VRF tables on the carrier PE routers house the provider's internal
routes. These routes normally consist of at least the customer's /32 loopback addresses. The
carriers's PE routers do not carry the provider's external routes, which is critical to the overall
scalability of this model.
The provider's PE routers must maintain the provider's internal and external routes. The provider's
external routes are those learned from downstream subscribers.

lnterprovider Layer 3 VPNs
• Pitfalls
• VPN routes must resolve to inet. 3
• Route target mismatches
• VPN routes received are compared against t11e local route target in
the import policy
• Time-savers
• Identify correct solution
• Ensure reacl1abilitythrough inet. 3 routes
• Build VRF routing instance
• PE to CE interfaces and protocols
• Route target information
lnterprovider Pitfalls
VPN routes are advertised using the VPN-1Pv4 NLRI, which must be negotiated between BGP peers
and is configured using the BGP family inet-vpn unicast command. When this family is
configured in BGP, it overrides the default behavior of advertising standard 1Pv4 prefixes. If both are
required, they must both be configured. Routes sharecl between ASBR must also be present in
inet.3.
Route target import information must match the extended BGP target community in the VPN
advertisement. Use the show route receive-pr,otocol bgp detail and show route
advertising-protocol bgp detail commancls to troubleshoot route target mismatches.
The BGP keep-all option will also help by installing all VPN routes in the bgp .13vpn. o table,
regardless of route target information.
lnterprovider Timesavers
Begin by determining which solution you must implem,�nt. Identify the PE routers and verify that the
IBGP and MPLS infrastructure is in place. Identify ASBRs and which routes must be leaked to peers
with labels. Use the show bgp sununary and show route table inet. 3 commands to verify
the configuration. A stable topology will make the VPN control process easier to troubleshoot if there
are problems exchanging VRF information.
Configure the customer interface and establish CE to PE peering using the routing protocol specified
in the VPN task information. Verify customer reachability and routing information in the VRF table.

Agenda: MPILS Vl'N Implementation

a Layer 3 MPLS VPNs
II
7 Layer 2 VPNs and VPLS

·-"" ·
<! I f:l Woifdwlde'EaucationServices
fil*Jt<-
WWWJunoperoet I 11-25
II
Layer 2 VPNs and VPL.S


Layer 2 Over lv1PLS-Based C:ore
• Layer 2 VPNs
• Layer 2 VPN using BGP signaling (Kornpella)
• Automatically assigns new circuit IDs and labels
• Can use either RSVP or LOP to signal LSPs
• Layer 2 circuit using LOP signaling (Martini)
• Requires manual circuit provisioning
• LOP sessions can be adjacent or extended (ldp-tunneling)
• VPLS
• VPLS using BGP signaling
• Automatic provisioning
• Can use eitl1er RSVP or LOP to signal
• VPLS using LOP signaling
• Must configure a full mesh of LDP session between PE routers
• LOP sessions can be adjacent or extended (ldp-tunneling)
Q
Layer 2 VPNs Over a MPLS-Based Core

The BGP Layer 2 VPN (Kompella) draft describes an algorithm used to auto-provision PE routers
when a new site is added to a PE router. This algorithm automatically assigns new circuit IDs and
labels, notifies other PE routers, and sets up the VPN mesh automatically in all topologies.
LDP Layer 2 circuits (Martini) require manual provisioning in a manner similar to a traditionally
managed frame relay network. Both BGP Layer 2 VPNs and LDP Layer 2 circuits call for the use of the
Martini-style encapsulation. Layer 2 circuits do not support traffic engineering because LDP is used
as the signaling protocol. You can use ldp-tunneling to create an extended LDP session across
a RSVP core if traffic engineering is required.
VPLS Over a MPLS-Based Core

BGP allows for the auto-discovery of new sites as they are added to a VPLS. When a new site is
added to a VPLS, you must only configure the PE router connected to the new site. All other PE
routers discover the new site with the use of the target extended community. Also, BGP is a very
scalable protocol. BGP works well when dealing with large number of routes. Provisioning a VPLS
network in a large provider network can be made easier with the use of route reflectors,
confederations, or both. LSPs can be signaled using either RSVP or LDP.
You can configure LDP as the signaling protocol for a VPLS routing instance. LDP signaling requires
that you configure a full-mesh LDP session between Hie PE routers in the same VPLS routing
instance. Neighboring PE routers are statically configured. You can use LDP tunneling to create an
extended LDP session across a RSVP core if traffic engineering is required.

Layer 2 VPN and VPLS Concepts
• Layer 2 VPN
• Layer 2 VPNs and Layer 2 circuits offer point-to-point
Ethernet, frame relay, ATM. PPP. or Cisco-HDLC services
• Administrator of PE router maps local circuit IDs to remote
sites
• VPLS
• Offers Ethernet-based point-to-multipoint VPNs
• To the customer in a VPLS environment the provider's
network appears to function as a single LAN segment
• Acts similarly to a learning bridge
• No need to map local circuit IDs to remote sites
• PE device learns MAC address from received Layer 2 frames
• MAC addresses are dynamically mapped to outbound MPLS LSPs.
interfaces. or both
--
n�fi �"" ' -
WorldwideEducationServices
""' "":;(�!.... ,..,, W� 'NJUnlpernot 111·27
Layer 2 VPN Concepts

BGP Layer 2 VPNs and LOP Layer 2 circuits are point to point in nature and support Ethernet, frame
relay, Point-to-Point Protocol (PPP), and Cisco's High-Level Data Link Control (Cisco HDLC). Even
though Ethernet media can be used between PE and CE devices, only two CE devices can interact
over a single emulated Layer 2 circuit or virtual LAN (VLAN). In both of the Layer 2 point-to-point VPN
scenarios, you must manually map local Layer 2 circuits on the PE device to the remote sites.This
mapping might be labor intensive and sometimes confusing, especially when designing a full-mesh
network between PE devices.
VPLS Concepts
To the customer, a VPLS appears to be a single LAN segment. In fact, it appears to act similarly to a
learning bridge. That is, wt1en the destination media access control (MAC) address is not known, an
Ethernet frame is sent to all remote sites. If the destination MAC address is known, it is sent directly
to the site that owns it.
When using VPLS, you do not need to map the local circuit to remote sites. In a VPLS, PE devices
learn MAC addresses from the frames that it receives. They will use the source and destination
addresses to dynamically create a forwarding table (vpn-name. vpls) for Ethernet frames. Based
on this table, frames are forwarded out directly connected interfaces or over MPLS LSPs across the
provider core. This behavior allows you to not have to manually map Layer 2 circuits to remote sites.

GP Signaled Layer 2 VPNs

• Layer 2 VPN
• BGP signaling is used to exchange circuit information
• MP-BGP support using family 12vpn
• Site ID. label range. label base
• Import and export target community
• Bidirectional LSPs must be pre-established between PEs
• Can be RSVP or LDP sessions
• VRF table
• Provisioned for each customer site including the site ID.
sub-interface list. encapsulation. and label base
• Uses RFC 4448 encapsulation
onServices \o\lwwJun1pernet I 11·28
BGP Layer 2 VPNs

The Layer 2 VPN utilizes the same BGP infrastructure as the Layer 3 VPN. This means that the PE
routers use MBGP to advertise Layer 2 circuit information known as the NLRI. The NLRI describes the
label information necessary to connect to each customer site. In addition, the MBGP updates
contain route-distinguisher and route target extended community information to enforce the logical
topology of the VPN.
A VRF table is created for each attached customer site and contains the local Layer 2 logical
interfaces and encapsulation provisioned for that site. Using the label-range and label-base assigned
to the customer site, inbound labels are mapped to each logical interface. The VRF table also
contains the outbound labels calculated from the NLRls received from each remote site. The VRF
calculates inbound and outbound labels for each customer interface based on the NLRI information
received from each site. Each site maps to a label switch path providing a double push operation
which includes the outgoing label and the MPLS label (top). As mentioned earlier, the Layer 2
encapsulation for BGP Layer 2 VPNs is based on the RFC 4448.

LDP Signaled ayer 2 Circuit
• Layer 2 circuit
• LOP signaling for peering sessions
• Does not support traffic engineering
• Manually provisioned at both ends of a circuit
• Supports label stacking
• No auto-provisioning of Layer 2 circuits
• No VRFtables
• Configured under protocols 12circui t hierarchy
• BGP is not required
n�¥m�,iLi " ,
--�,,,- ,
WorfdwideEducationServfcas W�WJunop .. n<t 11129
LOP Layer 2 Circuits

The Layer 2 circuit is similar to the original circuit cross-connect (CCC) implementation except the
LSPs are not mapped to t11e customer's interface. The customer circuit information is instead
advertised using the LDP. When an LDP session is established, the peers exchange prefix
information with an MPLS label and circuit-specific information to build a forwarding table. This
forwarding table provides a per circuit user label and label stacking across the MPLS LSP for
improved scalability. Because Layer 2 circuits use LDP signaling, you cannot use traffic engineering,
but you can use LDP tunneling to apply some traffic engineering to the LSPs.
LDP builds the forwarding table, which provides a user label for the remote end of the customer
circuit allowing for label stacking. An ingress packet from the customer's interface has an MPLS
double push operation performed, the inner label is the user label and the outer label is the MPLS
label. A returning packet arrives at the egress router with only the user label, which is mapped to the
customer's interface.
Because signaling is handled by LDP there is no requirement to be running BGP in the core. As with
BGP signaled Layer 2 VPNs, the Layer 2 encapsulation for Layer 2 circuits is based on RFC 4448.

BGP Signaled VPLS
• VPLS with BGP signaling

• BGP signaling is used to exchange circuit information
• MP-BGP support using family 12vpn
• Site ID. label range. label base
• Import and export target community
• Bidirectional LSPs must be pre-established between PEs
• Can be RSVP or LOP sessions
• VRF table
• Provisioned for eacl1 customer site including the site ID.
sub-interface list. encapsulation. and label base
BGP Signaled VPLS

VPLS control information is processed in the same manner as a BGP signaled Layer 2 VPN. VPLS
uses the same MP-BGP NLRI. A VRF is created in the PE router for each attached CE device. The
table contains the local site-id, encapsulation, logical interface, and label base as provisioned by the
customer. You create a VPLS VRF by specifying an ins:tance-type of vpls. The protocol
vpls identifies the local parameter for the connection table. When you configure BGP signaling for
the VPLS routing instance, on each PE router you must configure each VPLS site that has a
connection to the PE router. All the Layer 2 circuits provisioned for a VPLS site are listed as the set of
logical interfaces. You must configure a site name and site identifier for each VPLS site. When you
enable BGP signaling for each VPLS routing instance, you must configure a site range. The site range
specifies the total number of sites in the VPLS. BGP signaled VPLS also uses RFC 4448 as the
standard for its Layer 2 encapsulation.

LDP Signaled VPILS
• VPLS with LOP signaling

• PE router distributes VPLS to label mapping information
using LOP
• Supports FEC 128. Control bit 0. and Etl,ernet pseudowire
• For each VPLS. you must configure a full mesh of LOP LSPs
• PE-1 advertises labels to PE-2: PE-2 uses these labels as the inner
labels when forwarcling traffic to PE-1
• BG Pis not required
mm Wor(dw��.�d�cationServices WWWJun_,pernet I 11·31
LDP Signaled VPLS

LOP signaling requires that you configure a full-mesh LOP session between the PE routers in the
same VPLS routing instance. Neighboring PE routers are statically configured. Tunnels are created
between the neighboring PE routers to aggregate traffic from one PE router to another. Pseudowires
are then signaled to demultiplex traffic between VPLS routing instances. These PE routers exchange
the pseudowire label, the I\/IPLS label that acts as the VPLS pseudowire demultiplexer field, by using
LOP forwarding equivalence classes (FECs).
In operation, a PE router advertises a label for each remote PE configured. To LOP, this label
advertisement is just another FEC. These labels are advertised to targeted peers using extended
LOP sessions.
To configure the VPLS routing instance to use LOP signaling, you must configure the same VPLS
identifier on each PE router participating in the instance. You also must use the neighbor statement
to specify each of the neighboring PE routers that are a part of this VPLS domain.
BGP signaled VPLS also uses RFC 4448 as the standard for its Layer 2 encapsulation.

layer 2 Interface Configurc31tion
• Layer 2 VPN and Layer 2 circuit

• Interfaces require either CCC or TCC encapsulation
• Physical encapsulation and logical encapsulation
• VLAN interfaces must be in the range of 512 through 4094
• Can use extended-vlan encapsulation on the physical interface
to allow the use of VLAN IDs from 1 t1·1rough 4094
•VPLS
• Interfaces require vpls encapsulation
• VLAN interfaces must be in the range of 512 through 4094
• Can use extended-vlan-vpls encapsulation on the physical
interface to allow the use of VLAN IDs from 1 through 4094
• Add family vpls to the interface
Layer 2 VPNs and Layer 2 Circuit Interfaces

The PE routers are responsible for receiving packets from and sending packets to the CE routers. As
such, they also require some special interface configuration to support a Layer 2 VPN. The use of the
CCC encapsulation on the PE routers allows the Layer 2 frames to be placed directly into an MPLS
label switched path for transmission across the network. It also provides the capability for the PE
router to receive an MPLS packet and forward the encapsulated Layer 2 frame to the CE router.
When you enable CCC encapsulation on a VLAN-tagged interface, VLAN IDs from 512 through 4094
are reserved for CCC encapsulation and do not support protocol families. You can enable extended
support to allow the full range of VLAN values.
VPLS Interfaces
You must specify an encapsulation type for each PE to CE interface configured for VPLS. You must
use one of the VPLS encapsulation types as well as specifying the family vpls on the interface.
When you enable VPLS encapsulation on a vlan-tagged interface, VLAN IDs from 512 through 4094
are reserved for VPLS encapsulation. You can enable '"xtended support to allow the use the full
range of VLAN values.

Multihome VPLS (1 of 2)
• Single CE multihomed to multiple PEs

• BGP VPLS solution
• Assign same site ID
• Assign tl1e unique route-distinguisl1er
• Configure multihorning
• Assign a site-preference (higher is more preferred)
• LDP VPLS solution
• Multihoming is not supported usingLDP
• Can create redundant pseudowires to PE routers connected to t11e
same CE site.
• Use backup-nei,ghbor statement to create secondary
neigl1borship
�n"'
ril!W Wo ��eEducationServices ww •NJun,pe,net 111-33
BGP VPLS Multihoming

With VPLS multihoming, you can connect multiple PE router interfaces to one customer site. This
feature provides VPLS redundancy should a PE router or PE router interface fail.
When you have multiple PE routers connecting to a single customer site, you must configure the
same site IDs on all PE routers and router interfaces that are connected to the same customer site.
We recommend that you configure distinct route distinguishers for each multihomed router.
Configuring distinct route distinguishers helps with faster convergence when the connection to a
primary router goes down. It also requires the other PE routers to maintain additional state
information. To connect multiple PE routers to one customer site, you must configure multihoming on
each PE router connected to that site. This will prevent routing loops should BGP connectivity fail.
BGP automatically determines the primary and backup routers. Alternatively, you can statically
configure a primary PE router and backup PE routers for a customer site by specifying the preference
value. BGP uses preference values to determine routing paths.
LDP VPLS Multihoming

VPLS using LDP signalling does not support multihoming, but LDP VPLS does support redundant
pseudowires. A redundant pseudowire can act as a backup connection between PE routers,
maintaining VPLS services after certain types of failures. This feature can help improve the reliability
of certain types of networl{s (metro for example) where a single point of failure could interrupt
service for multiple customers. Redundant pseudowires cannot reduce traffic loss to zero. However,
they provide a way to gracefully recover from pseudowire failures in such a way that service can be
restarted within a known time limit.

Multihome VP S (2 of 2)
• Multiple connections between a single PE and CE

• To prevent loops. you must configure one of the following:
• Primary/backup interfaces (BG P only)
• Link aggregation
• Ethernet ring protection
• A spanning tree protocol
..
Multiple PE to CE interfaces
When connecting a single PE to a single CE using multiple interfaces, you must use one of the loop
prevention mechanisms listed on the slide.

Point-to.. Multipoint SPs for VPLS
• Point-to-multipoint L.SPs can be used instead of

unicast LSPs to forward broadcast, unicast, and
multicast traffic
• Ingress PE no longer has to perform all of the replication of
broadcast. unicast. and multicast traffic
• Can be used in BGP VPLS scenario only
• Point-to-multipoint LSP to VPLS mapping is performed with the
readvertisement of an ingress PE·s label blocks with tl-ie PMSI
Tunnel attribute
Broadcast, unicast with unknown destination, and multicast traffic are replicated and flooded solely
by the ingress PE by default. This behavior can put a tremendous burden on the PE if it happens to
service several hundred Vl'LS instances. Point-to-multipoint LSPs can be used specifically for the
purpose of carrying broadcast, unicast with unknown destination, and multicast traffic. When using
a point-to-multipoint LSP for this purpose, the ingress PE must send only one copy of the broadcast,
unicast with unknown destination, and multicast traffic into the core. The downstream routers along
the LSP will perform replication of the traffic. To notify remote PEs that a point-to-multipoint LSP will
be used for broadcast, unicast with unknown destination, and multicast traffic forwarding, the
ingress PE readvertises all label blocks along with the Provider Multicast Service Interface (PMSI)
Tunnel attribute, which carries the RSVP session identification information.
To allow a PE to flood broadcast, unicast with unknown destination, and multicast traffic using
point-to-multipoint LSP, simply configure an RSVP provider tunnel. You can use the default template,
or you can use a user defined label switched path template.

Layer 2 Pitfalls
• Interface configuration
• Physical and logical interfaces
• Protocol family configured
• Route targets
• VRF import and export policies
• BGP and MPLS configuration
• BGP uses family 12vpn
• Remote PE addresses in inet. 3
...
Layer 2 Pitfalls: Interface Configuration
The PE to CE interface must be configured with the appropriate CCC encapsulation, both on the
physical interface and the logical interface. If either is misconfigured, it looks good but it does not
work. CCC encapsulated interfaces do not support protocol families, including families inherited from
applied groups. It is very common to apply a group to all transit interfaces to support family mpls
or family iso. These families will not be displayed with a simple show interface command,
but must include the I display inheritance option. Any interface configured with a protocol
family and encapsulation CCC will fail the commit check.
Route Targets
The same rules apply to L2VPNs as apply to L3VPNs. The import extended route target community
must match the community received in the MP-IBGP update.
BGP and MPLS Configuration

All of the PE to PE or PE to route reflector connections must support the MP-IBGP L2VPN NLRI.
Remember that configuring the family 12vpn overrides the default family inet. All MP-IBGP
next-hop addresses must resolve to an entry in the inet. 3 table. This requires an active LSP
between PE routes.

Layer 2 Time-Savers
• Plan ahead
• Use topology maps to define PE routers
• Draw out VPNs using different colors
• MPLS transport
• RSVP or LOP
• Configure each VPN router by router
• Use the show I display set command to copy and
paste routing instances and route target policies
Layer 2 Time-Savers: Plan Ahead

As with all of the previous tasks, plan your strategy on the network map before starting the router
configuration. Identify all of the PE routers and use the colored markers to draw the L2VPNs.
MPLS Transport
Most of the MPLS transport should already be in place from the MPLS and L3VPN tasks. Both
protocol mpls and protocol rsvp should be configured on all of the routers. You might need
to configure protocol LDP on some of the routers to support any L2 circuits.
Configure Each VPN

Configure each L2VPN on the PE routers and verify that it is operational. Using the show I
display set option to cut and paste routing-instances and policy-options between
PE routers can save time and typing errors. Normally, this task comes at the end of the day and time
is running short. If a Layer 2 VPN does not come up right away, move on to the next VPN and come
back later, if time permits.

• Layer 3 M PLS VPNs

III
• Layer 2 VPNs and VPLS
""?Sample Task Analysis
·- on Services www Juniper net 1 11-38


Task and Topolo1�Y

Co reMPLS Network
AS 55lOO • '
ft.53895077211
C3·2
Loopbacks i'
C �
u sto mer�
.;,
R ) ..,. ,.. _2 , ,.83
--®
Customer
Rl - 192.168.1.1
\ 3
R2 - 192.168.1.2
'
' 1 651
.,,. / o.o/�·o -- / ,
I / j
0 \
��
$-+---0�
R3 - 192.168.1.3 - - C2-1 C2-2
R4 - 192.168.1.4 ,' \ R4
R5 - 192.168.1.5 Customer ®Cust�mer
R6 - 192.168.1.6 2 I R6
\ ,� _/ IR 5 /
R7 - 192.168.1.7 _/�
'·®--
C3·1 \ Cl-2.,. ,,. - - ,
R8 - 192.168.1.8
R9 - 192.168.1.9 Customer Cl) 'ilj'
R§
� �Customer '\
�
3 R7' --. ...... ,. R9 5 s.1.s.0;3 1 1
_,,..,. \
- - - - - I
'' AS 65100 ;
• Task:
_,,.
• Create a Layer 3 VPN named customer-1. connecting the

C1-1 and C1-2 sites together. The C1-1 and C1-2 are using
EBGPto peer to your· PE router. Ensure that the C E routers
can communicate with the remote. directly connected PE-C E
links.

This slide displays the sample task and topology. We analyze this task in the next set of slides.

What Now?

• Connectivity
• IGP route to egress router's loopback
• BG P neighborship between PE routers
• MPLS LSPs established between the PE loopbacks
• VPN NLRI enabled on IBGP session
• Layer 3 routing instance configuration on both PE routers
•route-distinguisher
•route-target or VRF import and export policies
• PE to CE routing protocols
onServices w•P1wfun1perne1 1 11·40

The slide illustrates the actual steps needed to accomplish the sample task.

• Step 1: Initial verification on R1

• OSPF and MPLS
lab@Rl> show route 192 .168.1.9
inet.O: 23 destinations, 23 routes (23 active, O holddown, O hidden)
192 .168 .1. 9/32 *[OSPF/10] 02:23:48, metric 2
> to 172.27.0.13 via ge-0/0/6.0
192.168 .1.9/32 *[RSVP/7/1] 02:17:49, metric 2
> to 172.27.0.9 via aeO.O, label-switched-path cl-to-c9
• BGP
lab@Rl> show bgp summary
Gcoups: 1 Peers: 8 Down peecs:
Table Tot Paths Act Paths Suppcessed Histocy Damp State Pending
inet. 0 O O O 0 0 0
Peec AS InPk t Out Pkt OutQ Flaps Last Up/Dwn
192 .168 .1.9 3895077211 11 4:10

0/0/ 0/0 0/0/0/0
Initial Verification on R1
The slide shows the commands and outputs to verify the first couple steps on Rl.

ask Completion {2 of 6)
• Step 2: Initial verification on R9

• OSPF and MPLS
lab@R9> show route 192.168.1.1
+ = Active Route, - = Last Active, • = Both
192.168.1.1/32 •[OSPF/10] 02:29:47, metric 2
> to 172.27.0.26 via ge-0/0/1.0
+ = Active Route, - = Last Active, • = Both
192 .168 .1.1/32 •[RSVP/7/1] 02:22:33, metric 2
> to 172.27.0.26 via ge-0/0/1.0, label-switched-path r9-to-rl
[LOP/9] 02:22:33, metric 1
• BGP > to 172 .27.0.26 via ge-0/0/1.0, label-switched-path r9-to-rl
lab@R9> show bgp summary
Groups: 1 Peers: 8 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp S tate Pending
inet.O O O O 0 0 0
Peer AS InPkt OutPkt OutQ flaps Last Up/Own
192.168.1.1 3895077211 2 2 1 2
0/0/0/0 0/0/0/0
Initial Verification on R9
The slide shows the commands and outputs to verify the first couple steps on R9.

• Step 3: NLRI configuration on R1

[edit protocols bgp group internal]
lab@Rl# �how
type intecnal;
local-address 192.168.1.1 ;
family inet {
unicast;
family inet-vpn
unicast;
export. nhs;
neighboc 192.168.1.2;
neighboc 192.168.1.3;
neighboc 192.168.1.4;
neighbor 192.168.1.5;
neighbor 192.168.1.6;
neighbor 192.168.1. 7;
neighbor 192.168.1.8;
neighbor 192.168.1.9;
Configuring the VPN NLRI on R1

The slide shows the configuration for enabling the VPN NLRI as well as still allowing the standard
1Pv4 NLRI route advertisements on R1.

• Step 4: NLRI configuration on R9

(edit protocols bgp group in ternal]
lab@R9# show
type internal;
family inet (
unicast;
family inet-vpn
unicast;
export nhs;
neighbor 192.168.1.1;
neighbor 192.168.1.2;
neighbor 192.168.1.3;
neighbor 192.168 .1.4;
neighbor 192.168.1.5;
neighbor 192.168.1.6;
neighbor 192.168.1. 7;
neighbor 192.168.1.8;
ionServices 1oVwwJun1pernet 1 11-44
Configuring the VPN NLRI on R9

The slide shows the configuration for enabling the VPI� NLRI as well as still allowing the standard
1Pv4 NLRI route advertisements on R9.

• Step 5: VRF instance configuration R 1

[edit]
lab@Rl# show routing-instances customer-1
instance-type vrf;
route-distinguisher 192.168.1.1:1;
vrf-target target:65100:1;
protocols {
bgp {
group customer-1 {
type external;
as-override;
neighbor 65.1.0.2
peer-as 65:.00;
Configuring the Layer 3 VPN Instance

The slide shows the configuration for the customer-1 Layer 3 routing instance on Rl. The sample
configuration also illustrates the PE to CE EBGP configuration, including the as-override
statement. You need this statement because both CE routers are in the same AS.

• Step 6: VRF instance configuration R9

[edit]
lab@R9# show routing-instances customer-1
instance-type vrf;
route-distinguisher 192.168.1.9:1;
vrf-target target:65100:1;
protocols {
bgp {
group customer-1 {
type external;
as-override;
neighbor 65.1.5.2
pe er-as 6510 0;
Q •
Configuring the Layer 3 VPN Instance on R9

The slide shows the configuration for the customer--1 Layer 3 routing instance on R9. The sample
configuration also illustrates the PE to CE EBGP configuration, including the as-override
statement. You need this statement because both CE routers are in the same AS.

• PE to CE routing protocol verification

• R1
lab@Rl> show bgp summary instance customer-l
Groups: 1 Pee r:s: l Down peer:s: 0
Table Tot Paths Act Paths Suppr:essed Histor:y Damp State Pending
custo. inet. 0 14 13 0 0 0 0
custom.mdt.O
Peer: Jl.S In Pkt Out Pkt OutQ E' laps Last Up/Own
65.1.0.2 65100 2678 2674 20:16:56 Establ
customer:-1.inet.O: 6/7/7/0
lab@R9> show bgp summary instance customer-l

Gr:oups: 1 Peer:s: 1 Down peer:s: 0
Table Tot Paths Act Paths Suppr:essed Histor:y Damp State Pen d ing
cust o.inet.0 14 13 0 0 0 0
custom. mdt. 0 0 0
Peer: AS In Pkt Out Pkt OutQ Flaps Last Up/Own
State I #Active/Received/Accept,=d/Damped...
65.1.5.2 65100 2693 2688 20:23:03 Establ
customer:-1.inet.0: 6/7/7/0
PE to CE Routing Verification
The slide shows that the BGP sessions from the PE devices have been established to the CE routers.
You can also see that you are learning routes from each peer.
www.juniper.net MPLS VPN Implementation • Chapter 11-4 7

• VRF table verification on R1

lab@Rl> show route table customer-1.inet.O
customer-1.inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
65.1.5.0/24 *[BGP/170] 20:23:05, localpref 100, from 192.168.1.9
AS path: 65100 I
> to 172.27.0.9 via ae0.0, label-switched-path rl-to-r9
65.1. 5. 0/3 0 *[BGP/170] 20:23:05, localpref 100, ft:om 192.168.1.9
J>.S path: I
> to 172.27.0.9 via aeO.O, label-switched-path rl-to-r9
AS path: 65100 I
65 .1.7 .0/24 *[BGP/170] 20:23:0 5, localpref 100, from 192.168.1.9
AS path: 65100 I
65 .1. 8. 0/2 4 *[BGP/170] 20:23:05, localpref 100, from 192.168.1.9
AS path: 65100 I
65.1.9.0/24 *[BGP/170] 20:23:0 5, localpref 100, from 192.168.1.9
AS path: 65100 I
... ·onServices wwwJun1pernet I 11·46
VRF Table Verification on R1

The output on the slide shows the routes on Rl learned from the R9 MP-BGP peer. The local routes
have been snipped out for brevity. You can also discern from the output that the LSP is up and
functioning correctly, because the rl-to-r9 LSP ha,, been selected as the next-hop for these
routes.

Task Verification1 (3 of 5)
• VRF table verification on R9

lab@R5> ,:how route table c!lstomer-1. inet. O
cu stomer-1.i net.O: 15 destinations , 16 routes (15 active, 0 holddown, 0 hi dden)
AS path: 65100 I
65.1.0.0/30 *[BGP/170] 20:27:55, localpcef 100, from 192.168.1.1
AS path: I
> to 172.27.0.26 via ge -0/0/1.0, label-switched-path r9-to-rl
AS path: 65100 I
AS path: 65100 I
> to 172.27.0.26 via ge-0/0/1.0, label -switched-path r9-to-rl
65 .l. 3 .0/2 4 *[BGP/170] 20:27:55, localpref 100, frnm 192.168.1. 1
AS path: 65100 I
> to 172.27.0.26 via ge-0/0/1.0, label-switc hed-path r9-to-rl
65.1.4.0/24 "[BGP/170] 20:27:55, localpref 100, from 192.168.1.1
AS path: 65100 I
''
VRF Table Verification on R9

The output on the slide shows the routes on R9 learned from the Rl MP-BGP peer. The local routes
have been snipped out for brevity. You can also discern from the output that the LSP is up and
functioning correctly, because the r9-to-rl LSP has been selected as the next-hop for these
routes.

• Verify route-distinguisher values R1

lab@Rl> show route table hgp.l3vpn. 0
bgp .13vpn. 0: 7 destinations, 7 routes (7 active, 0 hold.down, 0 hidden)

192.168.1.9 :1:65.l 5.0/24

*[BGP/170] 20:30:17, localpcef 100, from 192.168.1
.. 9
AS path: 65100 I
> to 172.27.0. 9 via aeO.O, label-s,..,itched-path rl-to-r9
192.168.1.9:1:65.l 5.0/30
*[BGP/170] 20:30:17, localpcef 100, from 192.168.1.9
AS path: I
192.168.1.9:1:65. 1.6.o I 24
AS path: 65100 I
> to 172.27.0.9 via ae0.0, label-s,\Titched-path rl-to-r9
192.168 .1. 9: 1:65.1. 7. 0/24
AS path: 65100 I
> to 172.27.0.9 via aeO.O, labe.l-st'll'itched-path c-1-to-r-9
192.168.1.9: 1:65.1. 8.0/24
AS path: 65100 I
> to 172.27.0.9 via ae0.0, label-st11itched-path rl-to-r9
192.168 1.9:1:65.1.9.0/24
*(BGP/170] 20:30:17, localpcef 100, from 192.168.1.9
AS path: 65100 I
> to 172.27.0.9 via aeO.O, label-switched-path r1.-to-r9
1.92 .168 .1. 9:l:65.1. 255.2/32
'[BGP/170] 20:27:12, localpcef 100, from 192.168.1.9
AS path: 65100 I
> t o 172.27.0. 9 via aeO.O, label-s�dtched-path rl-to-r9
..,,_ _______________ _
�U(il--e·i _, Wor(�ideEducat
'(' =·-»»�-
Reviewing the bgp .13vpn. O table on R1

The output shows the VPN NLRls being received on th,� Rl PE router.You can see that the route
distinguisher for R9 is prepended to 1Pv4 route prefix in the advertisement. This information can be
very useful when determining which routes are being advertised by which PE router in a larger
Layer 3 VPN network.
Chapter 11-50 • MPLS VPN Implementation www .juniper.net

Tas Verification1 (5 of 5)
• Verify route-distinguisher values R9
lab@R9> show route table bgp.1.3vpn.O
bgp.13vpn. 0: 7 destin ations, 7 route3 (7 active, 0 holddow n , 0 hi dden)

+ :;; Active Route, - = Last Act:.ve, * :;; Both
192 .168.1.1: 1:65 .1 0.0/24

*[BGP/170] �'.0:39:20, localpref 100, from 192.168.1.1
AS path: 65100 I
> to 172.2"1.Q.26 via ge-0/0/1 0, label-switched-path r.9-to-rl
192.168.1.1:1:65 1.0.0/30
•[BGP/170] :::o:39:20, localpref 100, from 192.168.l.l
AS path: I
> to 172.27.0.26 via ge-0/0/1.0, label-switched-path r:9-to-rl
192 .168.1.1:1:65.l. l.0/24
•[BGP/170] ,:0:39:20, localpr ef 100, from 192.168.1.1
AS path: 65100 I
> to 172.27.0.26 via ge-0/0/1.0, label-switched-path r-9-to-d
192.168.1.1:l. 65.1.2.0/24
•[BGP/170] ,:0:39:20, localpref 100, from 192.168.1.1
AS path: 65100 I
> to 172.2�'.0.26 via ge-0/0/1.0, label-switched-·path r.9 - to-d.
192.168.1.1:1:65.1. 3. 0/24
*[BGP/170] ,:0:39:20, localpref 100, from 192 ..168.1.1
AS path: 65100 I
> to 172.2�'.0.26 via ge-0/0/1.0, label-switched-path r:9-to-rl
192.168.1.1:1: 65 .1. 4. 0/24
*[BGP/170] ,:0:39:20, localpref 100, from 192.168.1.1
AS path: 65100 I
> to 172.Zi'.0.26 via ge-0/0/1.0, label-switched-path r9- to-t::1
192.168.1. 1:1:65. l. 25 5 .1/32
*[BGP/170] <0:36:15, localpref 100, from 192. 168.1.1
AS path: 65100 I
> t o 1 n..2i.0.26 via ge-0/0/1.0, label-switched-path r9-to-rl
1--------------- _ _ _ . _
Iii
;iW_!lrt<iwt�eEducationServices wwwJun,pe,net I 11·51
J,_ � I
Reviewing the bgp. L3vpn. o Table on R9

The output shows the VPN NLRls being received on the R9 PE router. You can see that the route
distinguisher for R1 is prepended to 1Pv4 route prefix in the advertisement.

Summary
• Demonstrated Layer 3 VPNs
• Explained 1Pv4 and 1Pv6 Layer 3 VPt�s
• Explained interprovider Layer 3 VPNs
• Described carrier-of-carrier Layer 3 VPNs
• Outlined BGP and LOP signaled VPLS and Layer 2 VPNs
onServ[ces \,l\lVWJUl'llf}ernet I 11-52

Layer 3 VPNs;
1Pv4 and 1Pv6 Layer 3 VPNs;
lnterprovider Layer 3 VPNs;
Carrier-of-carrier Layer 3 VPNs; and
BGP or LDP signaled VPLS and Layer 2 VPNs.

Lab 11: MPLS VPIN Implementation and

Troubleshooting
• Configure and monitor a Layer 3 VPN.

• Configure and monitor a VPLS connection.
• Configure and monitor an interprovider VPN.

have 3 hours to complete this lab.
@m v.:.��,;ideEducationServices
�Jdl.j "'""
W�Wjun,po,net I 11-53
Lab 11: MPLS VPNs Implementation and Troubleshooting

The slide provides the objE,ctives for this lab.


Junu2V�Cr
Appendix A: Junosphere
Objectives
• After successfully completing this content, you will be

able to:
• Describe Junosphere architecture
• Utilize Junosphere to perform lab exercises for this content
We Will Discuss:
Junosphere architecture and access; and
The utilization of Junosphere for Education Services labs.
Appendix A-2 • Junosphere www.juniper.net

Agenda:Junosphere
� Accessing the Junosphere Interface
• Accessing Active Topologies
= � =� , "�,a ' I
�umim JAforldwi�e ducatlonServices
�
WWWJUnlpernet I 3
Accessing the Junosphere Interface

The slide lists the topics we will cover. We discuss the highlighted topic first.
www.juniper.net Junosphere • Appendix A-3

What Is Junosphere?
• Junosphere is a virtualized environment where
multiple virtual devices connect to form topologies
1:;J I�)/ Jc./ Jj

�nn�n �1
I]
"· -
L �....,
Classroom Learners SSL\IPN
Internet
SSL\IPN
-
,-.........,
Remote L�ar,:::_J @ VJX 5eries , � Other virtual machines
What Is Junosphere?
Junosphere is a virtualization environment where multiple virtual machines representing network
devices can be connected and configured to create network topologies. For the purposes of
Education Services, the network topologies will be pre-assembled and ready for your use in lab
exercises. Most virtual devices on which you will perform tasks are known as VJX or VSRX Series
devices. Once you are connected to your topology, the experience is almost identical to connecting to
a physical rack of devices.

Accessing Junosphere
• Browse to http://www.junosphere.net
• Your instructor will provide a username and password
Usemame: ,::!:mo
Password:
Tne usernarne or password is 1ncorrec1

b.·
Forgot your password? o�, � 10.H''i'�.I
·�Te.-=� �·�
�t:Jn�
, Vcl
I1
>(;"t"
WorldwideEducatlonS,nvices 5
I� h_ '==
,VWWJUn1pernet [
I
Accessing Junosphere
Access Junosphere with a standard web browser by pointing the browser to
http://www.junosphere.net. The instructor will provide you with your username and password.

Accessing lab Topologies (1 of 2)
• Click the Manage Topologies link

• Provides access to your assigned topologies
�(-r,e '-
-t '.)i-.) ' O
1:n:�:..�,:1 , :; ma:• WELCOME TO JUNOSPHERE
I
Jl.mosohere fac1lrtat1:s: y,:>ur network des19n. testing and tra1rn
you can create and run nt>tworks us1no ·.mtual Junos.
C:��" '."oc,o'o,;r ,.. >.' •:.1or<l
I,
Mo!!,.�;;e i::�� dt:o"'!.
Mtri��e ioPQio,i;:�
.:.c::�s .:.�ta-,t1\:; oo.ocf
Administration
···.!r�;� W.>,s $¥"doextt i L'tx !t' <t-S

:-,b,i�� (�,:.,�...
VPlX
Useful links
t;_q;;f�:ft q-::M !ll.'.}n!J'i1�. f,...,;:Jtrr.r. Qgr,_ �f'hiQ11(fnM l9Qi<" yij;.ij<:;
=mad ]un�_team with :?DY q11c.5prm5
�QOU�...,r cusrrnwr serwp• QC OMO anuooort tlCM.t
Junosphere Lab Topologies

In Junosphere, devices reside in topologies, topologies reside in libraries, libraries reside within
sandboxes, and sandboxes reside within banks. Before the course begins, unique libraries will have
been created, which contain topologies used for the course. Once you are logged in to Junosphere,
navigate to the Tasks pane on the left, and click the Manage Topoloqies link to view the
available topology information.
In some settings, the instructor might set up personal libraries for each user. These personal
libraries can be used to save your work. For example, if you are unable to complete a lab during the
specified time interval, you can save the topology and device configurations in the personal library.
You can then access the partially completed lab during personal lab time or in the evening after
class.

Accessing lab Topologies (2 of 2)
• Click the Bank tab

• Click the bank tab to view the bank's library topologies
• All available library topologies will be displayed
! iil Mlili11.•.f:!=:-.=
••11!1::1J•liililmmm:i:·:.:;, 1;1iimllltii ::::i::: >�tr� -i;.. MILtt:Jii·H:ti;!!) 1E:::!%:'
��, ; - ·Oc,,:e ;r,fr�tr,.;,:;.:r� 0 0
Lo!'2-!'z!S�c'1t�tt°"1 0 (;)
No topology selected
�l.:lnm
- 1'1!,' • '
"'*"'�= ""
yv��deEd\ltationServices ,,_Jun;pern,t J 7
I
Bank and Sandbox Sections
Once you have clicked the Manage Topologies link, then you can view available sandbox and
bank information. As a student, you may not have access to modify the sandbox settings, so the
Sandbox tab might not display any information. If the Sandbox tab is blank, click the Bank tab to
see the bank libraries you have access to. Typically, you will have access to only one bank's set of
library topologies. If the Sandbox tab contains multiple entries, select the one directed by your
instructor, and then click the Bank tab.
www.juniper.net Junosphere • Appendix A- 7

Examining the Junosphere Bank Libraries
• Libraries display lab-specific details
The VM Units
The Name and Des er: iption
field displays the
fields display to which lab the
number of VM devices
topology is associated
used in the lab
...: c:J
.) � ! r..,
DMIAE1Jlifil1;LEM#i1 , 1 • 11111
l d -r�Pn.•:(<'� B<•t)t, dinp HK ir sr n,:wtc. .inip topuk:in�·(, L 1_;NCIE·SP _Eootum:,
@i ;.:,
Lab 1 · Devr:::e Infrastructure
r MVi ti
f,l
Libraries Display Lab-Specific Details

The Bank tab displays details for each available library topology. On the slide, the library is named
JNCIE-SP Boot camp topologies, but this might differ for the library you are working with. Be
sure to check with your instructor for the name of the library you should be accessing. Each
individual topology belongs to a specific lab, and the Name and Description fields indicate the
specific lab for the topology you are accessing. The VM Uni ts field displays the number of VM
devices you will have access to for that topology.

Agenda:Junosphere
II
Accessing the Junosphere Interface
�Accessing Active Topologies
"'m-;t."""
I
-�. ,
�tiff! '!(lnildwldeEdocatlonServfces wwwiunlpernet Is
mt "' I
Accessing Active Topologies


Starting a Topoflogy (1 of 2)
• Select and start the library topology

• Click the checkbox for the topology you want to start
1 ? _ZiCrE,S?_eoo:c<Y'C
�i]£IE-S?_£oat,:�rro
• Click Start to make the topology active
�IJJfilll=?ef.i -�,l�deEducatlonServices
="'le'M ,s,
'cy��"�
Q WWWJUnipernet 110
ct ''"'" == «
Starting a Topology
The slide illustrates how to start a topology, which is accomplished by clicking the checkbox to the
left of the topology and then clicking the Start button. Once you start a topology, it begins to
initialize each device that is contained within the topology.

Starting a Topology (2 of 2)
• Select the sandbox for the topology you are starting

• You might have only one sandbox option depending on
the lab
s,�lect the sandbox 1r >'.·h1ch yo1.., ·:,·ant to start this tooobgy...

Sandbox:�
JNUE-SP Bootcamp · Lab 1 • User l Jhn
JIICIE-SP BootcarnD - Lab 1 · User 2 U
• Then click Start to activate the topology

? x
Select the sandbox. in which YOL: ·.vant to start this tooology...
Sandbox: "' Jl'KIE·SP Bootcamp - Lab 1 · User 1
� Cancel
Select the Topology Sandbox

After you have clicked the Start button, Junosphere will prompt you to select the topology sandbox.
Depending upon the lab and what the instructor has allowed access to, you might only have one
sandbox option in the drop-down menu. Otherwise, you will need to choose which sandbox,
according to the instructor's directions. On the slide, there are two available sandbox options for
Lab 1. Once you have selected the appropriate sandbox, then click Start.
After you have activated the topology, you will receive a message stating that the topology start
process has been initiated successfully. Click OK to close the message box.

Access the Active Topology (1 of 3)
• Click the Access Active Topology link
:-��r ::;:t-�va::.� ,:;

M'-"�·� iO:»�o;-�
Ae:U!S� k.tr.:e iopol09y
::J Administration
• Then click Access to access the topology
".
Access the Active Topology

To view the status of the topology that you just started, click the Active Topology link on the left
hand navigation menu. After clicking the link you will see the Select Active Topology window,
which displays the state of your topology. However, you might need to refresh this information by
clicking the blue Refresh button. To access the topology, make sure the checkbox is selected for
your topology, and click Access.

• Examine the startup messages to verify successful activation

The last message
Click the refresh icon
will indicate that the
if needed to refresh topology has been
the messages
successfully activated
Rt f2 of S VMS} started.
I 7·Jun·201312;21 MDT
! R.2 (3 of S VMs: started.
R.3 (.; of S VMS} S't3r1ed.
R4 (5 of S VMs} started.
RS('> of s VMS) started.
7·Jun·2013 l2;,2 MDT
\fd'i'!\11Cf (7 oi S VMS) start'?d.
c�ntos •:s of s VMs} started.
Step 4 cf 5: Enabling �"ess to the topology.
I7·Juu·2013 12;27 MDT

Step 5 of 5: Svcc�ss: The topology ts no:, actw�.
\'letc�me / .,. lff..,!Ji·-§!!§11
Accessing the Topology

Before accessing the topology devices you must wait for the topology to become fully active. When
you see the message Step 5 of 5: Success: The topology is now active, the
topology is fully active and you can access the topology.

• Join the active topology

• Click Join to join the active topology
• Confirm the join action
Join the Active Topology

Next, you must click the Join button before you can access the topology devices. Clicking ,Join will
initiate the required Network Connect session between your workstation and the Junosphere lab
topology. A dialogue box will open up and will prompt you to confirm the join action. Click Yes to
confirm the action.

ccessing Topology Devices
• While connected to the topology, use a standard

terminal emulation program to connect to devices
• Telnet or SSH
• Use the Virtual Machines tab to view access details
if'j:!4! �
ti lt�mc ...
t··WMPii
UI' WI ,Ml•'I
I .i:•;m.:
IH' in) '/l,:i I
I n··J11v;
l.f! ,,, I ,.
u·
t;f, I ) ,,.
;.u;_:,
�l!.lnmi w;;ridwideEducationServices ""'"JUnlpernet I 15

', sdLc ,,
Accessing the Topology Devices

Once you have joined the topology, you can access the virtual machines directly by using Telnet or
SSH. The information listed under the IP Address field displays the IP address that is applied to
the management port on the virtual machines. You can use a terminal emulation program to Telnet
or SSH directly to these addresses. Alternatively, you can use the information listed in the Console
field to initiate a reverse Telnet session to access the virtual machines through the console port.

Summary
• In this content, we:
• Described Junosphere architecture
• Utilized Junosphere to perform lab exercises for this content
We Discussed:
Junosphere architecture and access; and
The utilization of Junosphere to perform lab exercises for Education Services
courseware.

Acronym List
ABR............................•.................................................... area border router

AFI..... . ..................... .. ............ .......... address family indicator
AS. ............................................................................ autonomous system
ASM ......................................................... .... any-source multicast
ASBR ......•.........•.........•.................................... autonomous system boundary router
BDR ....................................•... ................. ...backup designated router
BFD... ............................... .. .•......... ••.... . . Bidirectional Forwarding Detection protocol
BGP .. ....................................................... .......Border Gateway Protocol
CBGP ........................... . , •...........•....................•...... ..confederation BGP
CCC. ............................................................................ circuit cross-connect
CE.. ..................... , , , ................................ , , ............ customer edge
CLI .. .. _................... ..• ........ ........................ ..command-line interface
cos .. ............. .................................. ... ...........class of service
CSPF.. . .............•.....................•............ Constrained Shortest Path First
DIS ..................................................................... designated intermediate system
DoS.... . ......... ........................ denial of service
DR............ . ...............................................................designated router
EBGP ......... . .......... ........... .............. ..........external BGP
ECMP ...... .........................••................ . equal-cost multipath
ERO... ....................................................................... Explicit Route Object
FEC............•.........•.............. ... forwarding equivalence class
GRES ................................................................. graceful Routing Engine switchover
GUI ............. .... ....................................................graphical user interface
HMAC. ....... ..................................... ....... Hashed Message Authentication Code
IBGP .. ......... ..................................... .............. .... internal BGP
ICMP. ........... ............. .... Internet Control Message Protocol
IGMP.... ......................................... ... Internet Group Management Protocol
IGP .... ............... .......................•...............interior gateway protocol
1Pv4 .................... .•..........•.....................................IP version 4
1Pv6 ......IP version 6
ISP .................................................................. ........ Internet service provider
JNCP. .......•........••........•.........•.........•..............Juniper Networks Certification Program
LACP....................................................................Link Aggregation Control Protocol
LDP. .............. .... Label Distribution Protocol
LSA .. ... link-state advertisement
LSI ........................................... ... LSP sub-interface
LSP .. .. label-switched path
LSR... ........................................................................ label-switching router
MAC .......•... ........... .....•...........•....................media access control
MD5 ... .......................................... ............. Message Digest 5
MP-BGP ................. . .....................•...........•..... Multiprotocol Border Gateway Protocol
NHS . ..... .•.......•. .... ........... .............. ..next-hop server
NLRI ..................................•............................. network layer reachability information
NSR ................•................................nonstop active routing
OAM ............•................................. Operation, Administration, and Maintenance
OIL ....... ...................... ........... .. .. outgoing interface list
PDU ........... ............................ protocol data unit
PE ... ...................................... ............ .............. provider edge
POP.. .....•.... .............. ....... • ..... ......... point of presence
PP-VPN . .......................................................... provider-provisioned VPN
PPP.................... .......................•...... ......................... Point-to-Point Protocol
RID ... .... router ID
regex................... ........ regular expression
RP............ .. rendezvous point
RPF...............................•............................................ reverse path forwarding
www.juniper.net Acronym List • ACR-1

RPL ... .............. ...................... ring protection link
RPT ..... .....•..... ............... ................... rendezvous point tree
RTBH.... ................. ...........•................ remote triggered black hole
SAFI. .............................. . .................... subsequent address family identifier
SE ... ....•••........•.•............ ................. . ........ shared explicit
SPF .. ....•••.... ............•.•... ......•............. shortest path first
SPT .. ........................ ....................... ... ................... shortest path tree
SSM.. .............. . ................................................. source-specific multicast
TLV .... . ............... .......................................... type/length/value
Tspec................................ .......................................... traffic specification
TIL. .... .........••......... ..............•.. ......•........... time to live
TIL. .... ............................. ................................................ time-to-live
uRPF .............•....... .................•.. ........... Unicast RPF
VL AN ........ . ............................ .... .. ............................ ........... virtual LAN
VPL S ............••..... ...•........ ...........•. ............... virtual private LAN service
VRF .....................................................................VPN route and forwarding tables
VRRP............••.... ....••..........••............••............ Virtual Router Redundancy Protocol
WRED ................................................................... weighted random early detection
ACR-2 • A cronym L ist www.juniper.net

JNCIE-SP 10.c SG PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

JNCIE-SP 10.c SG PDF

Caricato da

Copyright:

Formati disponibili

JNCIE Service Provider Bootcamp

Worldwide Education Services

1133 Innovation Way

Course Number: EDU-JUN-JNCIE-SP

Chapter 1: Course Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1

Chapter 2: Exam Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1

Chapter 3: Device Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

Chapter 4: IGP Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

Chapter 5: IGP Troubleshooting ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

Chapter 6: BGP Implementation.....................................................6-1

Chapter 7: BGP Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Chapter 8: Multicast Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1

www.juniper.net Contents • iii

Chapter 10: MPLS Implementation .................................................. 10-1

Chapter 11: MPLS VPN Implementation .............................................. 11-1

Appendix A: Junosphere ............................................................ A-1

Acronym List ................................................................... ACR-1

www.juniper.net Course Overview • v

vi • Course Agenda www.juniper.net

CU and GUI Text

Style Description Usage Example

Courier New Console text:

Input Text Versus Output Text

Style Description Usage Example

Normal CLI No distinguishing variant. Physical interface:fxpO,

Defined and Undefined Syntax Variables

Style Description Usage Example

CLI Variable Text where variable value is already policy my-peers

www.juniper.net Document Conventions • vii

Education Services Offerings

About This Publication

Juniper Networks Support

viii • Additional Information www.juniper.net

Chapter 1: Course Introduction

This Chapter Discusses:

Chapter 1-2 • Course Introduction www.juniper.net

• Before we get started ...

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

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

• The prerequisite for this course is JNCIP-SP

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

General Course Administration

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

• Available materials for classroom-based

Training and Study Materials

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

• For those who want more:

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

• To receive your certificate, you must complete the

l wor1JZicie'Education Services """ JUn1per net I 1·9

www.juniper.net Course Introduction • Chapter 1-9

Juniper Networks Education Services

Juniper Networks Education Services Curriculum

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

Juniper Networks Certification Program

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

Chapter 1-12 • Course Introduction www.juniper.net

Worfdwid!EducationServices ww�Jun,p .. not 1 1-13

www.juniper_net Course Introduction • Chapter 1-13

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

Chapter 2: Exam Strategies

• After successfully completing this chapter, you will be

>- �� ·� lli'd'0"'"" "'