/

Advanced Junos Enterprise Routing

Troubleshooting
12.b

Student Guide
/

Worldwide Education Services

1133 Innovation Way

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

Course Number: EDU-JUN-AJERT

r
This document is produced by Junlper Networks. Jnc.

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.

Advanced Junos Enterprise Routing Troubleshooting Student Guide. Revision 12.b

Copyright© 2014 Juniper Networks. Inc. All rights reserved.
Printed in USA.
Revision History:
Revision 12.a-June 2013
Revision 12.b--January 2014
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 12.1R5.5 for SRX Series devices. and
Release 12.3Rl. 7 for EX Series switches. 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 Jn 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: IGP Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

OSPF Troubleshooting .......................................................... 2-3
IS-IS Troubleshooting ..........................................................2-28
Troubleshooting IGPs Lab ......................................................2-55

Chapter 3: BGP Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

8GP Overview ................................................................. 3-3
8GP Troubleshooting ..........................................................3-14
8GP Case Study ......................•....................................... 3-31
Troubleshooting 8GP Lab ......................................................3-47

Chapter 4: Policy Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Routing Policy Overview ........................................................ 4-3
Routing Policy Structure ........................................................ 4-6
Using Regex .................................................................4-14
Routing Policy Troubleshooting .....•.......................................... .4-19
Case Study ..................................................................4-31
Troubleshooting Routing Policy Lab ..............................................4-41

Chapter 5: Troubleshooting Advanced Features .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Multicast Troubleshooting....................................................... 5-3
Multicast Case Study .......................................................... 5-29
Cos Troubleshooting ............................•............................. 5-40
Cos Case Study ..............................................................5-55
Troubleshooting Advanced Features Lab .........................................5-66

Appendix A: Additional IGP Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

RIP Troubleshooting ........................................................... A -3
IGP Troubleshooting Case Studies ...............................................A-12
IGP Support for 1Pv6 ..........................................................A-29

Appendix B: Additional Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

8GP Case Study ............................................................... 8-3
Policy Case Study ............................................................8-12

Appendix C: SRX Hardware Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1

General Chassis Components ................................................... C-3
Redundancy ......................•..•.......................................C-18
Hardware Case Study .........................................................C 2
-3

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

www.juniper.net Contents • iii

iv • Contents www.juniper.net
Course Overview

This one-day course is designed to provide students with information about troubleshooting interior
gateway protocols, BGP, routing policy, multicast, and class of service (CoS). Students will gain
experience in monitoring and troubleshooting these topics through demonstration as well as
hands-on labs. The course exposes students to common troubleshooting commands and tools
used to troubleshoot various intermediate to advanced issues.
This course uses Juniper Networks SRX Series Services Gateways for the hands-on component, but
the lab environment does not preclude the course from being applicable to other Juniper hardware
platforms running the Junos OS. This course is based on Junos OS Release 12.1R5.5 for
SRX Series devices, and Release 12.3R1. 7 for EX Series switches.

Objectives
After successfully completing this course, you should be able to:
List common commands used to troubleshoot and verify various interior gateway
protocol (IGP) routing protocols.
Isolate different IGP issues.
List common commands used to troubleshoot and verify BGP.
Isolate different issues with BGP communication and configuration.
Isolate problems relating to routing policy structure and configuration.
Identify common commands for troubleshooting routing policy.
Verify and troubleshoot multicast.
Verify and troubleshoot class of service.
List common commands that are used to troubleshoot and verify the RIP routing
protocol.
Explain IGP support for 1Pv6.
List the general chassis components.
Identify different methods for troubleshooting major chassis components.
Troubleshoot redundant Routing Engine and Control Board communication.

Intended Audience
The primary audience for this course is the following:
Individuals responsible for configuring and monitoring devices running the Junos OS.

Course Level
Advanced Junos Enterprise Routing Troubleshooting is an advanced-level course.

Prerequisites
The following courses are the prerequisites for this course:
Junos Troubleshooting in the NOC (JTNOC); and
Advanced Junos Enterprise Routing (AJER).

www.juniper.net Course Overview • v

Course Agenda

Day 1
Chapter 1: Course Introduction
Chapter 2: IGP Troubleshooting
Troubleshooting IGPs Lab
Chapter 3: BGP Troubleshooting
Troubleshooting BGP Lab
Chapter 4: Policy Troubleshooting
Troubleshooting Routing Policy Lab
Chapter 5: Troubleshooting Advanced Features
Troubleshooting Advanced Features Lab
Appendix A: Additional IGP Troubleshooting
Appendix B: Additional Case Studies
Appendix C: SRX Hardware Troubleshooting

vi • Course Agenda www.juniper.net

Document Conventions

CLI 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
Filename text box.
Text field entry

Input Text Versus Output Text

You will also frequently see cases where you must enter input text yourself. Often these instances
will be shown in the context of where you must enter them. We use bold style to distinguish text
that is input versus text that is simply displayed.

Style Description Usage Example

Normal CLI No distinguishing variant. Physical interface:fxpO,

Enabled
Normal GUI
View configuration history by clicking
Configuration > History.

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

Style Description Usage Example

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

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

CLI Undefined Text where the variable's value is Type set policy policy-name.
the user's discretion or text where
ping 10.0.�
the variable's value as shown in
GUI 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://www.juniper.net/training/education/.

About This Publication

The Advanced Junos Enterprise Routing Troubleshooting Student Guide was developed and tested
using software Release 12.1R5.5 for SRX Series devices, and Release 12.3R1.7 for EX Series
switches. Previous and later versions of software might behave differently so you should always
consult the documentation and release notes for the version of code you are running before
reporting errors.
This document is written and maintained by the Juniper Networks Education Services development
team. Please send questions and suggestions for improvement to [email protected].

Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats:
Go to http://www.juniper.netjtechpubs/.
Locate the specific software or hardware release and title you need, and choose the
format in which you want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or
account representative.

Juniper Networks Support

For technical support, contact Juniper Networks at http://www.juniper.netjcustomers/support/, or
at 1-888-314-JTAC (within the United States) or 408-745-2121 (outside the United States).

viii • Additional Information www.juniper.net

Advanced Junos Enterprise Routing
Troubleshooting

Chapter 1: Course Introduction

Advanced Junos Enterprise Routing Troubleshooting

Objectives
• After successfully completing this content, 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

We Will Discuss:
Objectives and course content information;
Additional Juniper Networks, Inc. courses; and
The Juniper Networks Certification Program.

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

 Advanced Junos Enterprise Routing Troubleshooting

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

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

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

Advanced Junos Enterprise Routing Troubleshooting

Course Contents
• Contents:
• Chapter 1: Course Introduction
• Chapter 2: IGP Troubleshooting
• Chapter 3: BGP Troubleshooting
• Chapter 4: Policy Troubleshooting
• Chapter 5: Troubleshooting Advanced Features
• Appendix A: Additional IGP Troubleshooting
• Appendix B: Additional Case Studies
• Appendix C: SRX Hardware Troubleshooting

Course Contents
The slide lists the topics we discuss in this course.

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

 Advanced Junos Enterprise Routing Troubleshooting

Prerequisites
• The prerequisites for this course are the following:
• Junos Troubleshooting in the NOC (JTNOC)
• Advanced Junos Enterprise Routing (AJER)

Prerequisites
The slide lists the prerequisites for this course.

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

Advanced Junos Enterprise Routing Troubleshooting

Course Administration

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

General Course Administration

The slide documents general aspects of classroom administration.

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

 Advanced Junos Enterprise Routing Troubleshooting

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.netjtraining/technical_education

Training and Study Materials

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

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

Advanced Ju nos Enterprise Routing Troubleshooting

Additional Resources
• For those who want more:
• Juniper Networks Technical Assistance Center {JTAC)
• http//www.juniper.net;support;requesting-support.html
• Juniper Networks books
• http//www.juniper.net;books
• Hardware and software technical documentation
• Online: http//www.juniper.net;techpubs
• Portable libraries: http//www.juniper.net;techpubs/resources
• Certification resources
• http//www.juniper.net;training/certification/resources.html

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

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

 Advanced Junos Enterprise Routing Troubleshooting

Satisfaction Feedback
(ii:1
G.1l Class

E}
G2i Feedback

�
1,21
Gi!l

==
Gi!l

• To receive your certificate, you must complete the

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

Satisfaction Feedback
Juniper Networks uses an electronic survey system to collect and analyze your comments and feedback. Depending on the
class you are taking, please complete the survey at the end of the class, or be sure to look for an e-mail about two weeks
from class completion that directs you to complete an online survey form. (Be sure to provide us with your current e-mail
address.)
Submitting your feedback entitles you to a certificate of class completion. We thank you in advance for taking the time to
help us improve our educational offerings.

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

Advanced Junos Enterprise Routing Troubleshooting

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:j/www.juniper_netjtraining/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.neVtra ining/tech nical_ed ucation/.

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

 Advanced Junos Enterprise Routing Troubleshooting

Juniper Networks Certification Program

• Why earn a Juniper Networks certification?

• Juniper Networks certification makes you stand out
• Unleash your creativity across the entire network

Jun1Per
• Set yourself apart from your peers
• Capitalize on the promise of the New Network '.'\. Ti'> '

• Develop and deploy the services you need CERTIFICATION

PROGRAM
• Lead the way and increase your value
• Unique benefits for certified individuals

Juniper Networks Certification Program

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

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

Advanced Junos Enterprise Routing Troubleshooting

Juniper Networks Certification Path

Juniper Networks Certification Program Overview

The Juniper Networks Certification Program (JNCP) consists of platform-specific, multitiered tracks that enable participants
to demonstrate competence with Juniper Networks technology through a combination of written proficiency exams and
hands-on configuration and troubleshooting exams. Successful candidates demonstrate a thorough understanding of
Internet and security technologies and Juniper Networks platform configuration and troubleshooting skills.
The JNCP offers the following features:
Multiple tracks;
Multiple certification levels;
Written proficiency exams; and
Hand s -on configuration and troubleshooting exams.
Each JNCP track has one to four certification levels-Associate-level, Specialist-level, Professional-level, and Expert-level. The
Associate-level, Specialist-level, and Professional-level exams are computer-based exams composed of multiple choice
questions administered at Pearson VUE testing centers worldwide.
Expert -level exams are composed of hands-on lab exercises administered at select Juniper Networks testing centers. Please
visit the JNCP website at http://www.juniper.netjcertification for detailed exam information, exam pricing, and exam
registration.

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

 Advanced Junos Enterprise Routing Troubleshooting

Certification Preparation

• Training and study resources:

• Juniper Networks Certification Program website:
www_juniper_netjcertification
• Education Services training classes:
www_juniper.netjtraining
• Juniper Networks documentation and white papers:
www_juniper_netjtechpubs
• Community:
• J-Net:
http://forums_juniper.net;t5/Training-Certification-and/
bd-p/Training_and_Certification
• Twitter: @JuniperCertify

Preparing and Studying

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

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

Advanced Junos Enterprise Routing Troubleshooting

Junos Genius: Certification Preparation App

Unlock your Genius...
• Practice for multiple exams in Study Mode
• Hundreds of multiple choice questions and
answer explanations, many with CLI
snapshots
• Simulate an exam in Time Challenge Mode
• Earn device achievements by winning
in Instructor Challenge Mode
• Build a virtual network with device

--
achievements
• Track your results in the app and
Game Center; share your network
through Facebook and Twitter
t••
www_juniper.netjjunosgenius

Junos Genius
The Junos Genius application takes certification exam preparation to a new level. With Junos Genius you can practice for
your exam with flashcards, simulate a live exam in a timed challenge, and even build a virtual network with device
achievements earned by challenging Juniper instructors. Download the app now and Unlock your Genius today!

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

 Advanced Junos Enterprise Routing Troubleshooting

Find Us Online

Jnet J http://www.juniper.net/jnet

http://www.juniper.net/facebook

tl!j http://www.juniper.net/youtube

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

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

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

Advanced Junos Enterprise Routing Troubleshooting

Questions

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.

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

Advanced Junos Enterprise Routing
Troubleshooting

Chapter 2: IGP Troubleshooting

Advanced Junos Enterprise Routing Troubleshooting

Objectives

• After successfully completing this content, 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

We Will Discuss:
Useful commands that can be used to troubleshoot and verify correct operation of OSPF and IS-IS;
Isolating different OSPF issues; and
Isolating different IS-IS issues.

Chapter 2-2 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Agenda: IGP Troubleshooting

70SPF Troubleshooting
• IS-IS Troubleshooting

OSPF Troubleshooting
The slide lists the topics we will discuss. We discuss the highlighted topic first.

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

Advanced Junos Enterprise Routing Troubleshooting

OSPF Overview (1 of 2)
• Link-state IGP
• Establishes adjacencies
• Floods LSAs to populate LSDB
• Runs SPF on the LSDB to calculate the best paths
• Multi-area operations
• Backbone area 0.0.0.0
• Other areas
• Regular. Stub. NSSA
• ABRs provide inter-area reachability
• Generate Type 3 and Type 4 LSAs
• ASBRs inject external routes
• Generate Type 5 or Type 7 (NSSA) LSAs

Link-State IGP
OSPF is an interior gateway protocol (IGP) based on the concept of a link-state database (LSDB). Each OSPF-speaking router
in the network tries to form adjacencies with each neighboring OSPF router. When these adjacencies are formed, each router
generates and floods Link State Advertisements (LSAs) into the network in a reliable manner. LSAs are placed into the LSDB
on each router where the SPF algorithm is calculated to find the best path to each end node in the network.
OSPF dynamically discovers and maintains neighbors through generation of periodic hello packets. OSPF uses sanity checks
that prevent neighbor discovery (and therefore, adjacency formation) when parameters such as the hello time, area type,
maximum transmission unit (MTU), or subnet mask are mismatched. Once the neighbors are discovered, OSPF routers
exchange information with the LSDB which results in LSDB synchronization and Full adjacency.
OSPF advertises and updates prefix information using LSAs, which are sent only upon detection of a change in network
reachability. LSAs are also reflooded periodically to prevent being aged out by other routers. OSPF routers forward all LSAs
through all OSPF-configured interfaces except the one on which an LSA was received. OSPF uses IP protocol number 89 and
the AIISPFRouters multicast address of 224.0.0.5 for protocol messages.
Continued on the next page.

Chapter 2-4 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Link-State IGP (contd.)

On a broadcast segment, OSPF routers elect a single node to represent the segment to the network. The node is called the
designated router, and it is based on the highest priority. The second highest priority router is the backup designated router.
The DRother routers form two adjacencies across the broadcast segment one to the DR and one to the BDR. OSPF uses
224.0.0.6 multicast address for sending messages to DRs.

Multi-Area OSPF Operations

To reduce OSPF database size OSPF network can be designed with using multiple areas. LSA flooding is constrained to a
single area so OSPF behaves as a link-state protocol only within an area. The multi-area network must be built in an
hierarchical fashion with a specially designated backbone area 0.0.0.0 and other areas attached to the backbone. All data
traffic between OSPF areas transits the backbone area.
Routers that connect to multiple areas are called area border routers (ABRs) and maintain an LSDB for each area to which
they are attached. ABRs are responsible for inter-area routing so they inject summary LSAs advertising routes learned by the
ABRs in the attached areas. Any router with an attachment to the backbone area is considered a backbone router. Any router
that has all its interfaces contained within a single area is an internal router. The Autonomous System Boundary Router
(ASBR) is a router that injects external routing information into an OSPF domain.
OSPF non-backbone areas can be configured as Stub or NSSA areas. This allows to further reduce the LSDB size. Stub areas
do not carry AS external advertisements. NSSA areas also do not allow AS external information entering the area but routers
in NSSA area can originate AS externals into OSPF. Other not specifically designated areas are considered regular or transit
areas.
If an area is not directly connected to the backbone area you need to provision a virtual link that connects an isolated ABR to
the backbone. Virtual links are also used to repair the disjointed backbone. Virtual links cannot transit Stub or NSSA area.
Understanding various OSPF LSAs is essential in troubleshooting OSPF networks. The primary LSA types used by OSPF are
as follows:
Type 1 (Router LSA): Generated by all OSPF routers, describes the status and cost of the router's links;
Type 2 (Network LSA): Generated by the DR on a LAN, lists each router connected to the broadcast segment;
Type 3 (Network summary LSA): Generated by ABRs, carry summary route information between OSPF areas;
Type 4 (ASBR summary): Generated by ABRs, carry reachability information about the ASBRs between OSPF
areas;
Type 5 (AS external LSA): Generated by ASBRs, carries information for prefixes that are external to the OSPF
domain; and
Type 7 (NSSA external LSA): Generated by ASBRs in an NSSA, carries information for prefixes that are external
to the OSPF domain.

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

Advanced Junos Enterprise Routing Troubleshooting

OSPF Overview (2 of 2)
• Routing policies
• Default import action is to accept SPF calculated routes
• Default export action-do nothing
• Internal route preference is 10
• External route preference is 150

OSPF Routing Policies

OSPF is a link-state protocol, so routes are delivered to the routing table as a result of SPF calculations. By default, OSPF
accepts all routing information from the SPF process. OSPF does not use export policies in its default operations. The
connected networks are advertised in the Router LSAs as a result of the enabling OSPF protocol on the interfaces. You can,
however, apply an export policy, providing redistribution of other routing protocol information into OSPF. Note that OSPF
native or internal route preference is 10 by default and external routes have a preference of 150.

Chapter 2-6 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

OSPF Generic Topology

ABRs belong to Area 0.0.0.0 and an attached area
Provide interarea connectivity by injecting summary LSAs OSPF backbone area 0.0.0.0

--
Area 0 0.0.
. 0
BGP
....._ --.. ...._. Internal routers have all OSPF links in the same area
ASBRs inject routing information from
outside the OSPF domain Maintain local area routing
Receive summary LSAs for inter-area reachability

OSPF Generic Topology

The slide shows a summary view of a generalized OSPF network.

www.juniper.net IGP Troubleshooting • Chapter 2- 7

Advanced Junos Enterprise Routing Troubleshooting

OSPF Troubleshooting Checklist (1 of 3)

• Adjacency
• Make sure your security policies permit OSPF protocol
messages
• Watch for mismatched parameters: area. netmask,
intervals, options. MTU
• Watch for mismatched IP subnet or the same IP address on
the neighbor interfaces
• Watch for mismatched authentication
• Passive link at both ends
• Point-to-point versus broadcast link

OSPF Adjacency Troubleshooting

OSPF troubleshooting generally falls into one of two categories, adjacency troubleshooting or routing troubleshooting. When
you start troubleshooting OSPF adjacencies make sure that your security policies or firewall filters do not prevent protocol
communications.
Recall that OSPF does not establish adjacencies if OSPF parameters like area, netmask, hello interval, dead interval, or
options do not match. For example, a router in a Stub area would not establish an adjacency with a router that does not have
stub configured because of mismatched options.
Note that the two negotiating routers must have the same MTU on the connecting link. Database description packets signal
the MTU on the local end to ensure that it is safe to establish adjacency so mismatched MTU will cause the routers stuck in
exchange start state. The neighboring routers must also ensure that are on the same IP subnet.
Often to improve efficiency of OSPF operations over Ethernet interfaces connecting just two routers the interfaces are
configured respectively as point-to-point. If the two neighboring routers have mismatched setting of the interface type they
will not be able to establish adjacency.
The mismatched authentication parameters is another possible cause of malfunctioning OSPF neighborship.
Configuration of a passive interface allows OSPF to advertise the IP subnet of the link, however this setting prevents OSPF
communications over the link.

Chapter 2-8 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

OSPF Troubleshooting Checklist (2 of 3)

• LSDB integrity
• Duplicated Router ID's
• Broken area 0.0.0.0 or some areas not connected to area
0.0.0.0
• Virtual links

LSDB Integrity
One of the OSPF network problems that is often hard to troubleshoot is duplicated Router ID. Two neighboring routers will not
establish adjacency if they have an identical Router ID, however if the two routers with the same Router ID are not physically
connected it presents a more difficult problem. You can only detect the failure by monitoring the LSDB and SPF and
discovering regular routing flaps when some routes are continuously recalculated because the routers with the same Router
ID advertise different pieces of routing information. A good indicator of this issue would be continuous SPF runs.
Broken OSPF backbone area or an area that is not connected to the backbone present another issue. OSPF implements an
inter-area loop protection mechanism by ensuring that ABRs do not generate summary LSAs to the backbone area for the
summaries they receive in a non-backbone area. The missing summary routes would break the inter-area communications in
this scenario. To ensure that OSPF backbone area is contiguous and other areas are connected to it you should configure a
virtual link.
[edit]
user@srx# show protocol ospf area O
virtual-link neighbor-id 192.168.1.2 transit-area 0.0.0.10;

www.juniper.net IGP Troubleshooting • Chapter 2-9

Advanced Junos Enterprise Routing Troubleshooting

OSPF Troubleshooting Checklist (3 of 3)

• Routing
• Metric setting and suboptimal routing
• Missing loO.O interface
• Injecting 0/0 into Stub or NSSA area
• Incorrect route summarization
• Export pol icy
• Watch out for multiple redistribution points
• Prefix export limit
• Import policy
• Externals filtering

OSPF Routing Troubleshooting

OSPF routing troubleshooting is often more of an optimization task than failure troubleshooting, as in the case of
adjacencies. For example, routers in your network can use suboptimal routing from the network design perspective. Then you
might want to optimize traffic flows for certain destinations by modifying OSPF interface metrics. Usually, the routers'
loopback reachability is desired, for instance to establish IBGP peering sessions. Failing to configure loO.O interface in OSPF
results in the loopback address missing in the OSPF routing domain. Note that this does not prevent OSPF itself from
operating normally.
ABR route summarization is an optimization task aimed to reduce the LSDB size of the backbone area. The incorrectly
configured summary ranges would result in the more specific routes leakage to the backbone and potentially overloading
the backbone routers databases. The Junos OS allows you to configure restrict option along with a summary range. The
restrict option blocks both the summary route and the more specific routes falling in the summary range.
Continued on the next page.

Chapter 2-10 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

OSPF Routing Troubleshooting (contd.)

Note that in NSSA areas, you can configure summaries for both internal and external routes:
[edit protocols ospf]
user@router# show
area 0.0.0.1 {
area-range 10.1.100.0/20;
nssa {
default-lsa default-metric 10;
area-range 192.168.16.0/20;

interface ge-0/1/1.0;

You can use both import and export policies in OSPF but the use of import policies is restricted to filtering external routes.
Use the import policies with caution because an incorrect policy can result in the black-holing of some traffic.This might
happen because OSPF routers across the domain will keep the external LSAs in their databases and SPF will keep
calculating the best path to those destinations but if a router on the path fails to install the routes in the routing table due to
misconfigured import policy it won't be able to forward the packets.
Be careful when configuring mutual redistribution between OSPF and other IGPs at several routers because it can lead to a
routing loop formation or suboptimal routing.The general guideline is to perform redistribution from a protocol with a lower
(better) preference to a protocol with a higher (worse) preference. If you perform redistribution from a protocol with a higher
preference to a protocol with a lower preference, beware.

www.juniper.net IGP Troubleshooting • Chapter 2-11

Advanced Junos Enterprise Routing Troubleshooting

Useful OSPF Operational Commands (1 of 8)

U
• You want to check that OSPF is operational
� aser@srx> show ospf interface
Interface State Area DR :o BDR ID
ge-0/0/1.0 BDR 0.0.0.0 10.222.1.3 10. 222 .1. 2
ge-0/0/4.301 BDR 0.0.0.0 10.222.1.1 10.222.1.2

I....�������������������������������������
loO.O
ge-01016.0
DR
BDR
0.0.Q.0
0.0.0.1
10.222.1.2
10.222.1. 4
0.0.0.0
10.222.1.2
()
1
r�

user@srx> show ospf statistics

Packet type Total Last 5 seconds

Sent Received Sent Received
Hello 1198 1120 2 2
DbD 13 8 0 0
LSReq 3 0 0
LSUpdate 144 162 0 0
LSAck 153 95 0 0
--- (more) ---
1

Checking OSPF Operational State

Use the show ospf interface command to display OSPF-enabled interfaces and their parameters. This command
allows you to view the OSPF areas on the interfaces, DR and BDR IDs and the number of neighbors discovered on the
interfaces. The detail or extensive version of this command displays various interface parameters such as Hello and
Dead intervals, authentication, and MTU.
The show ospf statistics command display general OSPF protocol statistics. This command is useful in verifying that
OSPF messages are being sent and received.

Chapter 2-12 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful OSPF Operational Commands (2 of 8)

• You want to check OSPF summary

user@srx> show ospf overview
Instance: master
Router ID: 10.222.1.2
Route table i�dex: 0
Area border rJuter
LSA refresh time: SO minutes
Area: 0.0.0.0
Stub type: �ot Stub
Authentication Type: None
Area border routers: 1, AS boundary routers: 0
Neighbors
Up (in full state): 2
--- (more) ---

Displaying OSPF Summary Information

The show ospf overview command displays the OSPF summary information.

www.juniper.net !GP Troubleshooting • Chapter 2-13

Advanced Junos Enterprise Routing Troubleshooting

Useful OSPF Operational Commands (3 of 8)

• You want to check OSPF neighborship

user@srx> show ospf neighbor
Address Interface Sta.te ID Pri Dead
10.222.0.2 ge-0/0/1.0 Full 10.222.1.3 128 33
10.222.0.10 ge-0/0/4.301 Full 10.222.1.1 128 31
10.222.0.6 ge-0/0/6.0 Full 10.222.1.4 128 33

• You want to check that LSDB is consistent

user@srx> show ospf database

OSPF data.base, Area 0.0.0.0

Ty:-,.,.e ID Adv Rtr Seq Age Opt CksumLen
Router 10.222.1.1 10.222.1.1 Ox80000008 1040 Ox22 Ox3837 60
Router •10.222.1.2 10.222.1.2 Ox8000000e 490 Ox22 Oxd6b0 60
3outer 10.222.1.3 10.222.1.3 Ox80000009 496 Ox22 OxS2fS 60
Network 10.222.0.2 10.222.1.3 OxBOOOOOOl 496 Ox22 Ox8804 32
Network 10.222.0.10 10.222.1.1 Ox80000001 1135 Ox22 Ox3058 32
Network 10.222.0.18 10.222.1.l Dx80000001 1045 Ox22 Oxed91 32
Summary •10.222.0.4 10.222.1.2 Qx80000004 1353 Ox22 Oxf969 28
Summary 10.222.0.4 10.222.1.3 Ox80000003 451 Ox22 Oxa57 23
---(more)---

Checking the OSPF Neighborship State

The show ospf neighbor command displays a list of OSPF neighbors. It allows you to view the neighbor addresses and
RIDs, neighbor priorities in the DR elections on broadcast interfaces and the number of seconds until the neighbor becomes
unreachable.
Sometimes it is useful to restart an OSPF neighborship. You can clear an adjacency with the following command:
user@srx clear ospf neighbor address
Note that this command causes a momentary disruption.

Monitoring the Database

Use the show ospf database command to view the contents of the LSDB. The output shows LSA headers including the
LSA type, LSA ID, advertising router, etc. This command allows you to get a summary view of the LSDB so quickly identifying
missing elements.

Chapter 2-14 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful OSPF Operational Commands (4 of 8)

• You want to check OSPF LSDB details
user@srx> show ospf database extensive

OSPF database, Area 0.0.0.0

Type ID Adv Rtr Seq Age Opt Cksun Len
Router lG.222.1.1 10.222.1.1 Ox80000008 1130 Ox22 Ox3337 60
bits OxO, link count 3
id 10.222.0.10, data 10.222.0.10, Type Transit (2)
Topology count: O, Default metric: 1
id 10.222.0.18, data 10.222.0.18, Type Transit (2)
Topology count: O, Default metric: 1
id 10.222.1.1, data 255.255.255.255, Type Stub (3)
Topology count: 0, Default metric: 0
Topology default (ID 0)
Type: Transit, Node ID: 10.222.0.18
Metric: 1, Bidirectional
Type: Transit, Node ID: 10.222.0.10
Metric: 1, Bidirectional
Aging timer 00:41:09
Installed 00:18:47 ago, expires in 00:41:10, sent 00:18:47 ago
Last changed 00:18:47 ago, Change count: 3
---(more)---

LSDB Details
The command on the slide displays extensive output of the OSPF LSDB. It reveals the LSA contents and because LSAs is a
fundamental piece of information that OSPF routing is based on, the command is very important tool in OSPF
troubleshooting. The example on the slide shows a Router LSA Type 1. This LSA advertises 3 links, two of them are broadcast
links with a metric of 1 and one is a stub link with a metric of 0. The newer OSPF implementations support multi-topology
routing hence the LSA also shows the topology ID. The multi-topology routing is beyond the scope of this course.

www.juniper.net IGP Troubleshooting • Chapter 2-15

Advanced Ju nos Enterprise Routing Troubleshooting

Useful OSPF Operational Commands (5 of 8)

• You want to check OSPF SPF events
us-er@srx> show ospf log
I Topology default SPF log:

Last instanc� of each event type

When Type Elapsed

00:07:01
00:07:01 SPF 0.000251
Stub 0.000055
0.000078
External
00:03:10 Interarea
00:03:10 0.000240
00:03:10 NSSA 0.000003
00:03:10 Cleanup 0.000123
---(more)---

Viewing the SPF Log

The show ospf log command displays the entries in the log of SFP calculations. Use this command to verify that you
have a stable OSPF network. Multiple recalculations in a short period of time indicate potential instability.

Chapter 2-16 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful OSPF Operational Commands (6 of 8)

• You want to check SPF calculations result

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

Prefix Path Route NH Metric Next Hop Nexthop

Type Type Type Interface Address/LSP
10.222.1.1 Intra Router IP 1 ge-0/0/4.301 10.222.0.10
10.222.1.3 Intra Area BR IP 1 ge-0/0/1.0 10.222.0.2
10.222.1.4 Intra AS BR IP 1 ge-0/0/6.0 10.222.0.6
10.222.1.5 Intra AS BR IP ge-0/0/6.0 10.222.0.6
10.222.0.0/30 Intra Network IP 1 ge-0/0/1. O
10.222.0.4/30 Intra Network IP 1 ge-0/0/6.0
--- (more) ---

Viewing the SPF Results

The show ospf route command displays the results of the SPF calculations that are passed to the routing table. The use
of additional keywords allows you to display only routes learned by specific LSA type.

www.juniper.net IGP Troubleshooting • Chapter 2-17

Advanced Junos Enterprise Routing Troubleshooting

Useful OSPF Operational Commands (7 of 8)

• You want to check OSPF routes in the routing table
useL@srx> show route protocol osp£

inet.O: 33 destinations, 33 routes (33 active, 0 holddown, 0 hidden}

+ = F...ctive Route, - = Last. Active, * = Both

10.222.0.12/30 *[OSPF/10] 00:31:18, metric 3

> to 10.222.0.6 via ge-0/0/6.D
10.222.0.16/30 *lOSPF/10) 00:16:55, metric 2
> to 10.222.0.2 via ge-0/0/1.0
to 10.222.0.10 via ge-0/0/4.301
10.222.0.20/30 *[OSPF/10] 00:31:18, metric 2
> to 10.222.0.6 via ge-0/0/6.0
---(more)---

Checking the OSPF Routes in the Routing Table

Use the show route protocol ospf command to display routes in the routing table installed by OSPF.

Chapter 2-18 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful OSPF Operational Commands (8 of 8)

• For difficult problems go to debugging:
• Traceoptions
user@srx> show log ospf.log
Mar 13 05:31:31 trace_on: Tracing to "/var/log/ospf.log" started
Mar 13 05:3 1:31.567982 OSPF sent Hello 10.222.0.1 -> 224.0.0.5 (ge-0/0/1.0 IFL 72 area
0.0.0.0)
Mar 13 05:31:31.568052 Version 2, length 48, ID 10. 222.1.2, area 0.0.0.0
Mar 13 05:31:31.568109 mask 255.255.255.252, hello_ivl 10, opts Ox12, prio 128
Mar 13 05:31:31.568202 dead_ivl 40, DR 10.222. 0. 2, BDR 10.222.0.1

• Monitor traffic interface also called tcpdump

user@srx> monitor traffic interface ge-0/0/1 no-resolve detail
Address resolution is OFF.
Listening on ge-0/0/1, capture size 1514 bytes

05:34:31.290257 In IP (tos OxcO, ttl 1, id 44201, offset 0, flags [none], proto: OSPF
(89), length: 80) 10.222.0.2 > 224.0.0.5: OSPFv2, Hello, length 60 [len 48]
Router-ID 10.222.1.3, Backbone Area, Authentication Type: none (0)
Options (External, LLS]
Hello Ti.mer 10s, Dead Timer 40s, Mask 255.255.255.252, Priority 128
Designated Router 10.222.0.2, Backup Desi g nated Router 10.222.0.1
---(more)---

Debugging OSPF
To perform debugging functions of the OSPF routing use the Junos OS traceoptions function.The trace output is sent to a
named log file in /var I log directory.You can define various OSPF parameters to trace in the traceoptions configuration.
You can view the log file by using show log filename command or you can monitor the updates in the log file
dynamically with monitor start filename command. Remember to stop monitoring when you are done with the
monitor stop command.
The sample output on the slide shows a Hello packet received on ge-0/0/1.0 interface from a neighbor at the address
1 0.222. 0.1 with the full packet data.
You might also want to trace the protocol messages on a router interface by using the monitor traffic interface
interface-name command. This command is essentially a front end to a well known tcpdump utility.You can use various
filtering options in this command, for example, to capture only OSPF messages you can use the following filter:
user@srx> monitor traffic interface ge- 0/0/1.0 matching "dst 224.0.0.5"

www.juniper.net IGP Troubleshooting • Chapter 2-19

Advanced Junos Enterprise Routing Troubleshooting

General OSPF Troubleshooting Steps

No f
'OSPFis Check OSPF is enabled
.:,:operationah "- ·

r I"
No Check physical connection
Check security policies
Check settings at both sides
Check authentication �
""
Enable traceopt1ons '?§
'- .I 8
I
Watch for duplicate RID
Watch for flapping link i
/
Check LSDB
"" 8
No
Watch for ABR summaries received over non-
Routes are in -. backbone area
: the-routing table Check 0/0 in Stub and NSSA areas
Watch for prefix export limit
Check import and export policies
'- ,)

General OSPF Troubleshooting Steps

The purpose of the OSPF troubleshooting flowchart shown on the slide is to provide a set of high-level steps designed to get
you started with OSPF fault analysis.
Begin by verifying the OSPF operational state by checking the OSPF-enabled interfaces, which allows you to verify the local
interface settings. Then inspect the OSPF adjacencies. A lack of adjacencies can be the result of multiple causes such as
physical connectivity issues, mismatched OSPF parameters, firewall filter or security policies action denying OSPF messages,
or mismatching authentication parameters. If you ensured that all the parameters match and the security policies allow
OSPF packets, but the adjacency does not come up, it might indicate a software problem. In this case, you should report the
problem to JTAC.
Once OSPF adjacencies are to the full state, monitor the SPF behavior to ensure that the network conditions are stable.
Continuous SPF recalculations indicate network instabilities such as flapping links or duplicated RID.
Finally, check the OSPF routes in the routing table. Missing OSPF external prefixes might indicate of incorrect export or
import policies, or a too strict prefix export limit. You do not expect to see the external routes in OSPF Stub or NSSA areas so
the reachability is provided by injecting the default route into the areas at the ABRs. Note that in the Junos OS, ABRs do not
automatically inject the default route so you must provision it. If you find that inter-area routes are not installed in the routing
table you might want to check that the ABRs accept the summary LSAs Type 3. ABRs do not process the LSAs they receive
over nonbackbone area. In other words you must ensure that all nonbackbone areas are attached to area 0.0.0.0, and that
area 0.0.0.0 is not partitioned.

Chapter 2-20 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

OSPF Case Study: Adjacency Issues

• Topology, symptoms, and relevant information:
• You recently made alterations to your existing OSPF network. You added
a new router (R5) to Area 1. While you are verifying your network. you
notice problems. You find that all adjacencies on R2 are no longer
working and R5 cannot form adjacencies with neighbors. Physical
connections are verified and working fine. These devices are not using
security policies. so no traffic would be impacted.
R1

-�
I

•
Area1 'ge-0/0/6
R4 NSSA
. 5

ge-0/0/12 .

OSPF Case Study: Adjacency Issues

The slide presents a network topology, reported symptoms and description of a case related to OSPF adjacency issues. In
this case study you added a new router to Area 1. The verification showed that the new router does not establish
adjacencies. While you are troubleshooting the issue you find that R2 is no longer reachable. The physical connections have
been verified and showed no issues. You have ensured that the routers do not have any security policies or firewall filters
blocking OSPF.

www.juniper.net IGP Troubleshooting • Chapter 2-21

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting RS Neighborship (1 of 3)

• Check R5 neighborship state

• The ExStart state indicates the most probable MTU issue
user@RS> show ospf neighbor.
Ad.dress Interface State ID Pri Dead
10.222.0.21 ge-0/0/12 .0 ExStart 10.222.1.4 128 32
10.222.0.13 ge-0/0/6.0 Ex Start 10.222.1.3 123 37

• Compare OSPF interface parameters

user@R5> show ospf interface ge-0/0/12.0 detail
n er ace State Area DR ID BDR ID Nbrs
ge-0/0/12.0 BDR 0.0.0.1 10.222.1.4 10.222.1.s 1
Type: LAN, Address: 10.222.0.22, Mask: 255.255.255.252,(MTU: 9178! Cos�: 1
---(more)---

!user@R4>!show ospf interface ge-0/0/12.0 detail

ln�errace State Area DR ID BDR ID Nbrs
ge-0/0/12.0 DR 0.0.0.1 10.222.1.4 10.222.1.5 1
Type: LAN, Address: 10.222.. 0.21, Mask: 255.255.255.252,(MTU: 1sooj Cost:
---{more)---

Check R5 Neighborship State

You begin with checking the R5 neighbors. The show ospf neighbor command indicates that the two neighbors are
stuck in exchange start state.

Verify OSPF Interface Parameters

Use the show ospf interface command to check the interface parameters-the detail option is useful. In your
case, the command displays mismatched MTU values on the R4 and R5 interfaces.

Chapter 2-22 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting RS Neighborship (2 of 3)

• Adjust the MTU settings and check the neighborship

• ge-0/0/6 is still in ExStart
user@R5> show ospf neighbor
Address Interface State ID Pri Dead
10.222.0.21 ge-O/IJ/12.0 Full 10.222.1.4 128 34
10.222.0.13 ge-0/0/6.0 I ExStart I 10.222.1.3 123 31

• Check the interface parameters again

user@R5>1show ospf interface ge-0/0/6.0 detail
Intertace State Area DR ID BDR ID Nbrs
ge-0/0/6.0 BDR 0.0.0.1 10.222.1.3 10.222.1.S 1
Type: LAN, Address: 10.222.0.13, Mask: 255.255.255.252,IMTU: 15001 Cost: 1

user@R3>1show ospf interface ge-0/0/6.0 detail

Intertace State Area DR ID BDR ID Nbrs
ge-0/0/6.0 BDR 0.0.0.1 10.222.1.5 10.222.1.3 1
Type: LAN, Address: 10.222.0.13, Mask: 255.255.255.252,I MTU: 15001 Cost: 1

• Do you see the odd?

Modify the MTU Settings

You modify the interface MTU settings to ensure that they match at all neighboring routers. Then you check the neighborship
again. This time the command output shows that R4 and R5 became fully adjacent but R3 neighborship is still in an
exchange start state.

Check the Interface Parameters

You check the interface parameters again. This time the MTU settings appear to be the same. A careful examination would
reveal that the two neighbors are using the same IP address on their interfaces, but this problem is not always easily
spotted.

www.juniper.net IGP Troubleshooting • Chapter 2-23

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting RS Neighborship (3 of 3)

• Enable traceoptions
I [edit protocols ospf]
user@RS# show
t.racecptions {
file ospf. log;
flag packets;
flag error detail;

• Duplicate IP addresses on ge-0/0/6 interface!

user@RS> show log ospf.log
Jan 31 16:25:56 exl'.-2 clear-log[10835]: logfile cleared
Jan 31 18:25:56.870847 OSPF hello from 10.222.0.13 (IFL 2147404756, area 0.0.0.1) absorbed
Jan 31 18:25:58.152391 OSPF periodic xmit from 10.222.0.13 to 224.0.0.5 (IFL 2147405268
area 0.0.0.1)
Jan 31 18:26:00.979655 OSPF resend last OBD to 10.222.0.13
Jan 31 18:26:00.979832IOSPF sent DbD 10.222.0.13 -> 10.222.0.131 (ge- 0/0/6. 0 IFL 69 area
0.0.0.1)
Jan 31 18:26:00.979862 Version 2, length 32, ID 10.222.1.5, area 0.0.0.1
Jan 31 18:26:00.979857 options OxSO, i 1, m 1, ms 1, r 0, seq Oxadf4b41, mcu 1500
Jan 31 18:26:00.98063410SPF packet ignored: no matching interface from 10.222.0.13, IFL 01
---(more)---

Using Traceoptions to Debug OSPF

For the sake of completeness you enable the traceoptions to debug the protocol operations.
The output of the show log ospf. log command clearly indicates that OSPF database description packet was ignored
with the reason of the router do not have a matching interface.

Chapter 2-24 • !GP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R2 Neighborship (1 of 3)

• Check OSPF interface parameters

user@R2> show ospf interface detail
Interface State Area DR ID BDR ID Mbrs
aeO.O DR 10.222.1.2
0.0.0.0 0.0.0.0 0
Type: LAN, Address: 10.222.0.1, Mask: 255.255.255.252, MTU: 1500, Cost: l
DR addr: 10.222.0.1, Priority: 128
Adj count: 0
.t1e.1.1o: .1u, ueaa: ':l:U, .Keru-n11:.: ::,, .NOL �............,
Auth type: MD 5, Active key ID: 2, Start time: 2013 Mar 13 23:35:00 UTC
--- (more) ---
I
user@R3> show ospf interface detail
Interface Sc.ate Area DR ID BDR ID Nbrs
aeO.O DR 0.0.0.0 10.222.1.3 0.0.0.0 0
Type: LAN, Address: 10.222.0.2, Mask: 255.255.255.252, MTU: 1500, Cost: 1
DR addr: 10.222.0.2, Priority: 128
Adj count: 0
Heiio: iu, Deact: •u, ReXmit: �. Not Stuo
Auth type: MDS, Active key ID: 2, Start time: 2013 Mar 13 23:35:00 UTC
--- (more) ---
I
• Interfaces show matching parameters

Check R2 OSPF Interfaces

Proceed to troubleshooting the R2 adjacencies. You start with inspecting the router and its neighbors' interfaces. The
command on the slide shows the perfectly matching parameters. At the same time, you spot that the interfaces have MD5
authentication configured.

www.juniper.net IGP Troubleshooting • Chapter 2-25

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R2 Neighborship (2 of 3)

• Enable traceoptions
[edit protocols ospfJ
user@R2# show
traceoptions {
file ospf.log;
flag hello detail;
flag erro= detail;

• OSPF log file indicates authentication failure

user@R2> show log ospf. log
I
Mar 13 23:51:28 srxA-1 clear-log[9348]: logfile cleared
Mar 13 23:51:30.029065 OSPF periodic xmit from 10.222.0.9 to 224.0.0.5 (IFL •8 area
0.0.0.0)
Mar 13 23:51:31.000899 OSPF hel:o from 10.222.0.6 (IFL 74, area 0.0.0.1) absorbed
Mar 13 23:51:31.429258 OSPF periodic xmit frcm 10.222.0.5 to 224.0.0.5 (IFL �4 area
0. 0. 0.1)
Mar 13 23:51:35.489116 OSPF packet ignored: authentication failure (bad cksum).
Mar 13 23:51:35.489914 OSPF packet ignored: authentication failure from 10.222.0.2 I

Debugging OSPF at R2
You enable traceoptions to monitor OSPF packet flow. The show log osp£. log command output on the slide indicates
that the router ignores OSPF Hello packets due to authentication failure.

Chapter 2-26 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R2 Neighborship (3 of 3)

• Collected data
• The previously active adjacencies failed all at one time
• Debugging reveals authentication issues
• Interfaces show a new authentication key rollover time
• Authentication issues began after the new key rollover
• Solution
• Make sure that all authentication keys match
• Check neighborship
user@R2> show ospf neighbor
Address Interface State ID Pri Dead
10.222.0.2 ae0.0 Full 10.222 .1.3 128 37
10.222.0.10 ael. 0 Full 10.222.1.l 128 36
10.222.0.6 ge-0/0/6.0 Full 10.222.1.4 128 39

Collected Data
By this time, you know that R2 authentication data does not match that of the R2 neighbors. R2 previously full adjacencies
all failed at one time. The detailed output of the show ospf interface command provides a clue that the
authentication was activated at a certain time.

Solution
Given the information collected you can conclude that R2 OSPF adjacencies fail due to misconfigured authentication
parameters that were activated by accident at the time you were troubleshooting the R5 adjacencies.
After you adjusted the authentication at R2, the new check with the show ospf neighbor command shows that all R2
neighbors are now in full adjacency.

www.juniper.net IGP Troubleshooting • Chapter 2-27

Advanced Junos Enterprise Routing Troubleshooting

Agenda: IGP Troubleshooting

• OSPF Troubleshooting
�IS-IS Troubleshooting

IS-IS Troubleshooting
The slide highlights the topic we discuss next.

Chapter 2-28 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

IS-IS Overview (.1 2)

• Link-state protocol
• Same fundamental principles as OSPF
• Layer 3 protocol independent
• Requires family ISO
• Multi-area two-level operations
• Level centric
• Level 2 is the backbone
• Level 1 areas cannot communicate directly
• L1/L2 BR's provide inter-level reachability
• Attached bit down to Level 1
• Level 1 uses 0/0 for inter-area routing
• Send all internal routes reachability data up to Level 2

Link-State IGP
IS-IS is another interior gateway protocol (IGP) also based on the concept of a link-state database (LSDB). As such, each
IS-IS-speaking router in the network attempts to form an adjacency with each neighboring IS-IS router, builds the database
and runs SPF algorithm to compute the optimal path to each destination.
IS-IS was initially designed for now legacy Connectionless Networking Protocol (CLNP) routing but was later extended to
support IP. This extended IS-IS is referred to as Integrated IS-IS. Routers running the Integrated IS-IS must support IP suit
protocols such as the ARP, and the Internet Control Message Protocol (ICMP).
IS-IS runs directly on the Data Link Layer (Layer 2) and does not need network service access point (NSAP) addresses on
each interface, just on the router itself. The router NSAP address referred to as Network Entity Title (NET) is mandatory and is
required to identify the area the router belongs and to provide identity to the router itself as a unique node in the IS-IS
domain similar to OSPF RID.
IS-IS dynamically discovers and maintains neighbors through generation of periodic Hello PDUs. Despite the fact that IS-IS
runs directly on Layer 2 and as such is Layer 3 independent, IS-IS uses sanity checks that prevent neighbor adjacency
formation when the link IP subnet is mismatched. IS-IS uses three different kinds of Hello PDU including LAN Hello PDU for
Level 1, LAN Hello PDU for Level 2, and point-to-point Hello PDU. Because IS-IS PDUs cannot be fragmented using IP
fragmentation mechanism IS-IS checks that every link on which it floods LSPs can handle PDUs up to at least 1492 bytes.
Continued on the next page.

www.juniper.net IGP Troubleshooting • Chapter 2-29

Advanced Junos Enterprise Routing Troubleshooting

Link-State IGP (contd.)

IS-IS uses two PDUs called the Partial Sequence Number PDU (PSNP) and Complete Sequence Number PDU (CSNP) for
LSDB synchronization and to ensure reliable flooding. CSNPs contain a complete description of all LSPs in the IS-IS database
whereas PSNPs carry only a subset of the LSPs.
IS-IS uses link-state protocol data units (LSP) to describe the network topology. Each IS-IS router generates LSPs that
describe the state of the local router adjacencies, along with IP routes, checksums, and other information, and floods the
LSPs throughout the domain. The IS-IS LSPs are flooded when either a network change occurs or the periodic refresh timer
expires. LSPs, like OSPF LSAs, are the fundamental data units for building LSDB.
IS-IS PDUs use TLV encoding as the basic structure for all routing information. Particularly each individual LSP contains
multiple TLV segments that describe the originating router adjacencies and IP subnets.
Primary TLVs used by LSPs:
Area Addresses TLV (Type 1): Carries a list of all areas of the originating router;
IS Neighbors TLV (Type 2): Describes the originating router's links to neighboring routers and the cost to those
neighbors;
Protocols Supported TLV (Type 129): Carries a list of supported protocols (Junos supports IP and 1Pv6 by
default);
IP Interface Address TLV (Type 132): Carries the IP addresses of the IS-IS interfaces on the originating router;
IP Internal Reachability TLV (Type 128): Lists the IP prefixes directly connected to the originating router, and
their associated metrics;
IP External Reachability TLV (Type 130): Lists the IP prefixes external to the IS-IS domain, and their associated
metrics;
The TLVs that enable wide metrics are:
Extended IS Reachability TLV (Type 22): Similar to the IS Neighbors TLV, wide metrics;
Extended IP Reachability TLV (Type 135): Similar to the IP Internal Reachability TLV, wide metrics.

Multi-Area Two Level Operations

In IS-IS, a single AS can be divided into areas for the purpose of reducing the LSDB size. Routing between areas is organized
hierarchically. IS-IS accomplishes this organization by configuring Level 1 and Level 2.
IS-IS protocol advertises either a Level 1 LSP or a Level 2 LSP for each adjacency formed with a neighbor. IS-IS Level 1 LSP
can be flooded only within a specific area because a Level 1 adjacency cannot form across an area boundary. Level 2 LSPs
include the routing information carried in Level 1 LSPs, which results in the L2 backbone knowing routes for all areas and
levels. In a multi-area IS-IS network, each Level 1 IS-IS router has complete routing knowledge of the routes local to its Level
1 area only. L1/L2 routers do not advertise Level 2 routes into the Level 1 area by default. Level 1 routers reach other IS-IS
destinations by using the default route installed by them to the detection of L1/L2 attached routers. Attached routers are the
L1/L2 routers that have at least one Level 2 adjacency with a router in another area. The attached routers set the attached
bit in Level 1 LSP.
Level 1 routes advertised as external routes into Level 1 are not advertised to any Level 2 routers by default.

Chapter 2-30 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

IS-IS Overview (2 of 2)
• Routing policies
• ASBR's inject external routes
• External reachability TLV's (not used if wide metrics are configured)
• Internal route preference is 15/18 (L1/L2)
• External route preference is 160/165 (L1/L2)
• Default import action is to accept SPF calculated routes
• Cannot be modified
• Default export action is to accept direct routes on IS-IS
enabled links

IS-IS and Routing Policies

Because IS-IS is a link-state protocol, routes are delivered to the routing table as a result of SPF calculations. By default ISIS
accepts all routing information from the SPF process. You cannot alter this behavior. IS-IS does not use any export policies in
its default operations. The connected networks are advertised in IP Internal Reachability TLV or Extended IP Reachability TLV
as a result of enabling IS-IS protocol on the interfaces.
You can apply an export policy to provide redistribution of other routing protocols information into IS-IS. IS-IS uses IP External
Reachability TLV or Extended IP Reachability TLV to advertise the external routes. Note that the use of the
wide-metrics-only configuration leaves only Extended IP Reachability TLV so routes are no longer distinguishable as
being internal or external. The use of wide metrics therefore results in the automatic leaking of all Level 1 routes into Level 2.
Note that IS-IS native or internal route default preference is 15 for Level 1 routes and 18 for Level 2 routes whereas IS-IS
external routes have preference of 160 for Level 1 routes and 165 for Level 2 routes.

www.juniper.net IGP Troubleshooting • Chapter 2-31

Advanced Junos Enterprise Routing Troubleshooting

IS-IS Generic Topology Ll internal routers have all links in the

same l evel

.. .. . � .... '....
'
. �.. Maintain local area r outing
AS65000
Install 0/0 to the L1/L2 attached routers

···...
...·········
·•····.•.
. ....

IS-IS L2 backbone
Receives routing information from
all Level 1 areas

BGP
Ll/�;·;�uters connected to L and L2
ASBRs inject routing information from Set attached bit for inter-area ::J
outside the IS-IS domain connectivity

IS-IS Generic Topology

This slide shows a summary view of a generalized IS-IS network.

Chapter 2-32 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

IS-IS Troubleshooting Checklist (1 of 2)

• Adjacency
• Family ISO missing
• Level 1 area mismatch
• Level 1 versus Level 2 interface
• IP subnet mismatch
• Authentication parameters mismatch
• Minimal MTU cannot accommodate IS-IS messages
• Passive link is configured
• Point-to-point versus Broadcast interface
• LSDB integrity
• Unique NET must be configured at every router

IS-IS Adjacency Troubleshooting

IS-IS troubleshooting generally falls into one of two categories including adjacency troubleshooting and routing
troubleshooting.Recall that IS-IS uses family ISO packets for its PDUs so if you fail to configure family ISO on router interfaces
the router will not establish IS-IS adjacencies.
For Level 1 adjacencies, the routers must be in the same area. Watch for area portion of the NET address. Level 1 routers
will never form an adjacency with a Level 2 router.
IS-IS will not establish an adjacency if IP subnet is different on the neighboring routers' interfaces. This is part of sanity
checks that routers use to ensure that they can forward IP packets on the link.
At the beginning of adjacency formation IS-IS Hello packets are padded to the size of 1492 bytes to ensure that the link can
handle the largest PDU. If a neighboring interface has an MTU lower than 1492 bytes an adjacency is not formed.
The mismatched authentication parameters is another possible cause of malfunctioning IS-IS adjacency.
Configuration of a passive interface allows IS-IS to advertise the IP subnet of the link, however this setting prevents IS-IS
communications over the link.
Often to improve efficiency of IS-IS operations over Ethernet interfaces connecting just two routers the interfaces are
configured respectively as point-to-point. If the two neighboring routers have mismatched setting of the interface type they
will not be able to establish adjacency.
Continued on the next page.

www.juniper.net IGP Troubleshooting • Chapter 2-33

Advanced Junos Enterprise Routing Troubleshooting

LSDB Integrity
One of the IS-IS network problems that is often hard to troubleshoot is duplicated System ID. System ID plays the same role
in IS-IS as Router ID does in OSPF. Recall that the System ID is configured as part of the NET address on the router loopback.
Two neighboring routers will not establish adjacency if they have an identical System ID, however if the two routers with the
same System ID are not physically connected it presents a more difficult problem. You can only detect the failure by
monitoring the LSDB and SPF and discovering regular routing flaps when some routes are continuously recalculated
because the routers with the same System ID advertise different pieces of routing information. A good indicator of this issue
would be continuous SPF runs.

Chapter 2-34 • IGP T roubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

IS-IS Troubleshooting Checklist (2 of 2)

• Routing
• Metrics
• Wide or narrow
• loO.O interface
• Route summarization
• External versus internal
• Route leaking
• Export pol icy
• Watch out for multiple redistribution points
• Prefix export limit

IS-IS Routing Troubleshooting

IS-IS routing troubleshooting is often more an optimization task than complete failure troubleshooting as in the case of
adjacencies. For example routers in your network can use suboptimal routing from the network design perspective. Then you
might want to optimize traffic flows for certain destinations by modifying IS-IS interface metrics. Recall that by default IS-IS
uses metric of 10 for all interfaces irrespective of the interface bandwidth, except of loopback, that has a metric of 0.
Use a consistent approach in implementing wide metrics. If wide-metrics-only is configured on some of the routers but
the other routers are using the narrow metrics, the routers using narrow metrics will consider the wide metrics greater than
63 equal to the maximum value of 63.
Usually the routers' loopback reachability is desired, for instance for establishing IBGP peering sessions. Failing to configure
loO.O interface in IS-IS result in the loopback address missing in the IS-IS routing domain.
Route summarization at the L1/L2 border is an optimization task aimed to reduce the LSDB size of the Level 2 routers. IS-IS
in the Junos OS does not have a built-in configuration to enable summarization, instead a routing policy should be used.
Recall that the use of wide metrics results in the automatic leaking of the external IS-IS routes from Level 1 into Level 2, so in
the policy aimed to summarize the routes you need to consider a reject action for the more specific internal and external
routes.
Continued on the next page.

www.juniper.net IGP Troubleshooting • Chapter 2-35

Advanced Junos Enterprise Routing Troubleshooting

IS-IS Routing Troubleshooting (contd.)

An example of a policy that can be used to summarize either internal or external IS-IS routes at a Ll/L2 router;
[edit policy-options policy-statement Ll-summary-route]
user@srx# show
term local-summary-route {
from {
protocol aggregate;
route-filter 10.0.4.0/22 exact;

to level 2;
then accept;

term suppress-specifics
from {
route-filter 10.0.4.0/22 longer;

to level 2;
then reject;

Be careful when configuring mutual redistribution between IS-IS and other IGPs at several routers because it can lead to a
routing loop formation or suboptimal routing. The general rule of thumb is when redistribution is performed from a protocol
with a lower (better) preference to a protocol with a higher (worse) preference it's not an issue, otherwise if redistribution is
performed from a protocol with a higher preference to a protocol with a lower preference, watch out.

Chapter 2-36 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful IS-IS Operational Commands (1 of 8)

• You want to check that IS-IS is operational
user@srx> show isis interface
IS-IS interface database:
Interface L CirID Level 1 DR Level 2 DR Ll/L2 Met·ric
aeO.O 1 Oxl srxA-2.02 Disabled 10/10
ge-0/0/4.301 1 Ox3 srxA-1.03 Disabled 10/10
ge-0/0/6.0 Ox2 Disabled srx.A-1.02 10/10
loO.O O Oxl Passive Disabled 0/0

user@srx> show isis statistics

IS-IS statistics for srxA-1:
PDU type Received Processed Drops Sent Rexmit
LSP 10 10 0 14 0
IIH 426 13 0 587 0
CSNP 86 86 0 103 0
PSNP 1 1 0 0 0
Unknown 0 0 0 0 0
---(more)---

Checking IS-IS Operational Status

Use the show isis interface command to display the IS-IS parameters associated with an interface. This command is
useful to ensure that IS-IS is configured correctly on the router.
The show isis statistics command displays the counters for various IS-IS PDUs sent and received.

www.juniper.net IGP Troubleshooting • Chapter 2-37

Advanced Junos Enterprise Routing Troubleshooting

Useful IS-IS Operational Commands (2 of 8)

• You want to check IS-IS summary information
user@srx> show isis overview
Instance: master
Router ID: 10.222.1.2
Adjacency holddown: enabled
Maximum �-.reas: 3
LSP life time: 1200
Attached bit evaluation: enabled
SPF delay: 200 rnsec, SPF holddown: 5000 msec, SPF rapid runs: 3
IPv4 is enabled, IPv6 is enabled
Traffic engineering: enabled
--- (more) ---

• You want to check IS-IS adjacency status

user@srx> show isis adjacency
Interface System L State Held (secs) SNPA
aeO.Ci sr_x_.'.\-2 1 Up 7 b0:c6:9a:73:3a:O
ge-0/0/4.301 vr-device Up 25 0:22:83:Sc:21:81
ge-0/0/6.0 exA-1 Up 26 0:19:e2:55:24:89

Displaying IS-IS Summary Information

The show isis overview command displays the IS-IS summary information.
Use the show isis adjacency command to display the status of IS-IS adjacencies. The command output lists the local
router interfaces, neighboring routers by their host names, level, state of adjacency, and remaining hold time.
Sometimes it is useful to restart an IS-IS adjacency. You can clear an adjacency with the following command:
user@srx clear isis adjacency neighbor-name
Note that this command causes a momentary disruption.
You can determine the IS-IS host name database by using the following command:
user@srx> show isis hostname

IS-IS hostname database:

System Id Hostname Type
1921.6800.4201 Rl Dynamic
1921.6800.4202 R2 Dynamic
1921.6800.4203 R3 Dynamic

Chapter 2-38 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful IS-IS Operational Commands (3 of 8)

• You want to check that LSDB is consistent
user@srx> show isis database
IS-IS level 1 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
vr-device.00-00 OxS Ox43c2 479 Ll L2
srxA-1.00-00 Ox4 Ox55ab 1130 Ll L2 Attached
srxA-1. 03-00 Oxl Ox7b23 455 Ll L2
srxA-2.00-00 Ox3 Oxaf2d 479 Ll L2 A1:tached
srxA-2. 02-00 Ox2 Oxeeaa 838 Ll L2
srxA-2.04-00 Oxl Ox9cfd 479 Ll L2
6 LSPs

IS-IS level 2 link-state database:

LSP ID Sequence Checksum Lifetime Attributes
srxA-1.00-00 Ox4 Oxdfl4 460 Ll L2
srxA-1. 02-00 Ox2 Ox5345 1014 Ll L2
exA-1.00-00 Ox4 Ox2f7e 1041 Ll L2
3 LSPs

Viewing the IS-IS Database

The show isis database command displays a brief view of all the LSPs in the I S -IS LSDB. The output shows separate
LSDB entries for Level 1 and Level 2 databases. This view is convenient to quickly discover the missing routers.
Recall that IS-IS LSP ID is encoded in the following format: System ID.Pseudo node ID-LSP number. If the Pseudo node ID is
set to 00 value this indicates that the LSP is generated by a router for itself. Otherwise any other value indicates that the LSP
was generated by a Designated router (DIS) on behalf of a pseudo node it represents on a broadcast segment.

www.juniper.net IGP Troubleshooting • Chapter 2-39

Advanced Junos Enterprise Routing Troubleshooting

Useful IS-IS Operational Commands (4 of 8)

• You want to check the LSDB details

user@srx> show isis database extensive I find TLVs
'TLVs:
Area address: 49.0001 (3)
LSP Buffer Size: 1492
Speaks: IP
Speaks: IPV6
IP router id: 10.222.1.2
IP address: 10.222.1.2
Hostname: srxA-1
IP prefix: 10.222.0.0/30, Incernal, Metric: default 10, Up
IP prefix: 10.222.0.8/30, Internal, Metric: default 10, Up
IP prefix: 10.222.1.2/32, Internal, Me�ric: default O, Up
IP extended pref�x: 10.222.0.0/30 metric 10 up
IP extended prefix: 10.222.0.8/30 metric 10 up
IP extended prefix: 10.222.1.2/32 metric O up
IPv6 prefix: fdcd:aaaa:bbbb:Q:1::2/128 Metric O Up
---{more)---

Displaying Detailed IS-IS Database Information

The show isis database extensive command provides detailed output for the contents of the IS-IS LSDB. This
command is important in IS-IS troubleshooting because is reveals the contents of the LSP TLVs and thus allows the obtain
detailed information on the router neighbors, advertised IP subnets, and other parameters.
The example on the slide shows a number of TLVs in one of the LSPs in the IS-IS database. From this pieces of information
you can see that the advertising router is in the IS-IS area 49.0001, it supports IP and 1Pv6 routing, its loopback address is
10.222.1.2, its host name is srxA-1, and that the router advertises internal IP subnets 10.222.0.0/30, etc. and an 1Pv6 route
of fdcd:aaaa:bbbb:0:1::2/128.

Chapter 2-40 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful IS-IS Operational Commands (5 of 8)

• You want to check SPF events
user@srx> show isis spf log
IS-IS level 1 SPF log:
Start time Elapsed {secs) Count Reason
Thu Mar 14 23:55:36 0.000035 3 Reconfig
Thu Mar 14 23:55:37 0.000093 1 Updated LSP srxA-1.00-00
Thu Mar 14 23:57:27 0.000128 1 Topologies changed for adjacency srxA-2 on aeO.O
Thu Mar 14 23:57:42 0.000425 5 New adjacency srxA-2 on aeO.O
---{more)---

• You want to check SPF results

user@srx> show isis route
IS-IS routing table Current version: Ll: 8 L2: B
IPv4/IPv6 Routes

Prefix L Version Metric Type Interface N;i Via

10.222.0.16i30 1 S 20 int aeO.O IPV4 srxlt-2
ge-0/0/4.301 IPV4 vr-device
10.222.0.20/30 2 a 20 int ge-0/0/6.0 IPV4 exA-1
---{more)---

Viewing the SPF Log

The show isis spf log command displays the entries in the log of SFP calculations. Use this command to verify that
you have a stable IS-IS network. Multiple recalculations in a short period of time indicate potential instability.

Displaying IS-IS Routes

The show isis route command displays the results of the SPF calculations that are passed to the routing table.

www.juniper.net IGP Troubleshooting • Chapter 2-41

Advanced Junos Enterprise Routing Troubleshooting

Useful IS-IS Operational Commands (6 of 8)

• You want to check IS-IS routes in the routing table
user@srx> show route protocol isls

inet..O: 33 destinat.ions, 38 routes (33 a.ctive, 0 holddov..-r1, 0 hidden}

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

10.222.0.16/30 [IS-IS/15] 00:22:50, metric 20

to 10.222.0.2 via aeO.O
> to 10.222.0.10 via ge-0/0/4.301
10. 222. 0. 20/30 [IS-!S/18] 00:27:41, metric 20
> to 10.222.0.6 via ge-0/0/6.0
10. 222.1.1/32 !IS-IS/15j 00:22:50, metric 10
> to 10.222.0.10 via ge-0/0/4.301
---(more)---

Displaying IS-IS Routes in the Routing Table

Use the show route protocol isis command to display routes in the routing table installed by IS-IS.

Chapter 2-42 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful IS-IS Operational Commands (7 of 8)

• For difficult problems go to debugging:

• Traceoptions
user@srx> monitor start isis.log
isis.log ***
Mar 15 00: 37: 53 trace_on: Tracing to '' /var/log/ isis. log" started
Mar 15 00:37:53.125931 Sending Ll LAN IIH on ae0.0
Mar 15 00:37:53.126044 max area O, circuit type 11
Mar 15 00:37:53.126104 hold ti.me 27, priority 64, circuit id srxA-2.02
Mar 15 00:37:53.126196 neighbor b0:c6:Sa:73:3a:O
Mar 15 00:37:53.126246 speaks IP
Mar 15 00:37:53.126308 speaks IPv6
--- (more) ---

user@srx> monitor stop

Debugging IS-IS: Traceoptions

To perform debugging functions of the IS-IS routing use the Junos traceoptions function. The trace output is sent to a named
log file in /var /log directory. You can define various IS-IS parameters to trace in the traceoptions configuration.
You can view the log file by using show log filename command or you can monitor the updates in the log file
dynamically with monitor start filename command. Remember to stop monitoring when you are done with
monitor stop command.
The example output on the slide shows a Hello packet sent out of aeO.O interface with the full packet data.

www.juniper.net IGP Troubleshooting • Chapter 2-43

Advanced Junos Enterprise Routing Troubleshooting

Useful IS-IS Operational Commands (8 of 8)

• For difficult problems go to debugging:
•monitor traf fie interface also known as a
tcpdump

user@srx> monitor tra£fic interface aeO.O no-resolve detail

Address resolution is OFF.
Lis�ening on aeO.O, capture size 1514 bytes

00:33:52.060730 In IS-IS, length 131

Ll CSNP, hlen: 33, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 �0)
source-id: 0102.2200.1003.00, PDU length: 131
start isp-id: 0000.0000.0000.00-00
e�d lsp-id: ffff.ffff.ffff.ff-ff
LSP entries TLV #9, length: 96
lsp-id: 0102.2200.1001.00-00, seq: Ox00000006, lifetime: 356s, chksum:
Ox4lc3
lsp-id: 0102.2200.1002.00-00, seq: Ox00000007, lifetime: 1153s, chksum:

---\more)---

Debugging IS-IS: Monitor Traffic

You might also want to trace the protocol messages on a router interface by using the monitor traffic interface
interface-name command. This command is essentially a front end to a well known tcpdump utility.
The example on the slide shows an IS-IS Level 1 CSNP packet received on ae0.0 interface with the full decode.

Chapter 2-44 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

General IS·IS Troubleshooting Steps

.
- No
F
; · S-IS is I
Check IS-IS is enabled
"O erationalB0 '

.
Check family ISO is enabled
Check settings at both sides
Area. level. interface type, MTU, IP

. subnet

. Check authentication
Enable traceoptions u
....
......

..
.,)

Watch for duplicate NET

u
Watch for flapping link

.,, .
I
' 0
0

.
Check LSDB
Check authentication

. Watch for prefix export limit

Check export policies
Watch for overload state
\..
,

General IS-IS Troubleshooting Steps

The purpose of the IS-IS troubleshooting flowchart shown on the slide is to provide a set of high-level steps designed to get
you started with IS-IS fault analysis.
You begin with verifying of IS-IS operational state by checking the I S -IS-enabled interfaces. This allows you to verify the local
interface settings.
Then you proceed to inspecting IS-IS adjacencies. The lack of adjacencies can be a result of multiple causes such as
physical connectivity issues, missing family ISO, mismatched interface type, mismatched IP subnet, mismatched Level 1
area, or mismatched Hello POU authentication parameters. To monitor IS-IS message exchange you can also enable
traceoptions.
Once IS-IS adjacencies come up you monitor the SPF behavior so that to ensure the network conditions are stable. The
continuous SPF recalculations indicate network instabilities such as flapping links or duplicated System ID. Note that IS-IS
allows you to configure authentication for various PDUs. For example, you can configure authentication for Hello POU and
separately authentication for LSPs. Misconfigured LSP authentication settings will prevent routers from installing the LSP in
the database. A useful command for displaying the IS-IS authentication is show isis authentication.
Finally, you check the IS-IS routes in the routing table. Lack of IS-IS external routes can be a result of incorrect export policies
or too strict prefix export limit. If the export limit is exceeded IS-IS stops the external advertisements and sets the overload
flag. Sometimes you might also want to put a router in the overload state manually, for instance for some maintenance
period. Recall that IS-IS excludes the overloaded router in its SPF calculations.

www.juniper.net IGP Troubleshooting • Chapter 2-45

Advanced Junos Enterprise Routing Troubleshooting

IS-IS Case Study: Adjacency Issues

• Topology, symptoms, and relevant information:

• You recently put a new router (R3) into service. While you are verifying
your network you found that R3 is not able to form adjacencies with
neighbors. Physical connections have been verified and they are working
fine.

Rl Area 49.0001

( '\
I ge-O
I
I
)

IS-IS Case Study: Adjacency Issues

The slide presents a network topology, reported symptoms and description of a case related to IS-IS adjacency issues. In this
case study you recently installed a new router (R3). The verification revealed that R3 does not establish IS-IS adjacencies.
You have checked all physical connections and ensured that they are working fine.

Chapter 2-46 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R3 Adjacencies (1 of 6)

• Check R3 adjacency state

• No adjacencies
j
I user@R3> show isis ad acency

• Check the IS-IS interfaces

• L1 interfaces are area sensitive
user@R3> show i5is .interface
IS-IS interface database:
L CirID Level 1 DR Level 2 DR
I
-r..-.;.-,:,,,..�-::,r,o. Ll/L2 Metric
ae0.0 1 Oxl R3.00 Disabled 10/10
ae2.0 2 Ox1 Point to Point Disabled 10/10
ge-0/0/6.0 2 Oxl Disabled Point to Point 10/10
lo0.0 0 Oxl Passive Disabled 0/0

• Check the R3 area information in Li LSDB

user@R3> show isis database level 1 R3.00 extensive I match "Area address 11
Area address: 49.0002 (3

Check the IS-IS Adjacencies

You start your verifications by inspecting the IS-IS adjacencies at R3. The show isis adjacency command shows that
R3 does not have any.

Check R3 IS-IS Interfaces

- interface settings. The show isis interface command the router has
Then you begin inspecting the local router J S JS
interfaces in both Level 1 and Level 2.

Check R3 IS-IS Area

Because Level 1 adjacencies can only be established in the same JS-IS area, you decide to check the area settings at R3 and
its neighbors. You look up the area addresses TLV of R3 LSP in the JS-JS database by using the command shown on the slide.
Note that you could simply check the NET address on the router loO.O interface but we want to illustrate the power of the
show isis database extensive command. The command revealed that R3 I SIS - area is 49.0002, which is incorrect.

www.juniper.net IGP Troubleshooting • Chapter 2-47

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R3 Adjacencies (2 of 8)

• Fix the issue and check the R3 adjacencies again

user@R3> show isis adjacency
Inter-face System L State Hold (secs) SNPA
ae2.0 Rl 1 Up 20

• Check IS-IS statistics

• The output shows Hello POU drops
use:r:@R3> show isis statistics
rs�rs statistics for R3:
PDU type Received Processed Drops Sent Rexmit
T,ScP 1 i;p 1<.P. 0 240 1
IIH 6231 34 es3 I 16642 0
CSNP 153 153 0 4770 0
PSNP 10 9 1 11 0
---{mere)---

Modify the Area Setting

You fix the area configuration and check the IS-IS adjacencies again. Now R3 has established adjacency with R1. The other
R3 interfaces are configured in Level 2 so the mismatched area cannot be a cause of the malfunctioning adjacencies.

Check the IS-IS Statistics

You then use the show isis statistics command to determine if IS-IS PDUs are being sent and received. The output
of this command indicates that the IS-IS Hello PDU drop counter is incrementing.

Chapter 2-48 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R3 Adjacencies (3 of 6)

• Enable traceoptions
[edit protocols isis]
user@R3# show
traceoptions {
file isis.log;
flag hello detail;
flag error detail;

• Inspect the log file

• Authentication failure
uer@R3> show log isis.log I find error
Mar 15 04:38:49.800297 ERROR: IIH authentication failure
Mar 15 04:38:49.800642 ERROR: IIH from 0102.2200.1005 o ...-g-e--0-/�0-/�6-.-0-f_a_i�l-e-d�au-t�h-e_n_t�i-c-a -ti�.o-n�-i

• Make sure that authentication settings match at R3 and R5

user@R3> show isis adjacency
Interface System L State Hold (secs) SNPA
ae2.0 Rl 1 Up 20
ge-0/0/6.0 RS 2 Up 23

Debugging the IS-IS Operations

You try to find the reason of the Hello drops and enable traceoptions to debug IS-IS.

Examine the Log

The log file examination reveals that IS-IS does not accept IS-IS Hello PDUs from its neighbor 0102.2200.1005 (R5) due to
authentication failure.
You the adjust the authentication settings at both sides and verify the adjacencies again. This time R3 shows two out of
three adjacencies up. The IS-IS neighbor on the aeO.O interface is still missing.

www.juniper.net IGP Troubleshooting • Chapter 2-49

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R3 Adjacencies (4 of 8)
• Check the IS-IS statistics again
• There are still Hello drops
user@R3> clear isis statistics

user@R3> show isis statistics

IS-IS statistics for R3:
PDU type Received Processed Drops Sent Rexmit
- SP 0 0 0 0
IIH
CSNP
6
3
0 2
0
I 6 0
0
PSNP 0 0 0 0
---(more)---

• Take a closer look at the trace log

• It appears that R3 sends Hello but receives nothing from R2
user@R3> show log isis.log I match aeO.O
Mar 15 04:53:37.415805 ISIS L2 periodic xrnit to 01:80:c2:00:00:14 interface aeO.O
Mar 15 04:53:46.084359 ISIS L2 periodic xmit to 01:80:c2:00:00:14 interface aeO.O
---(more)---
�

Check the IS-IS Statistics

You keep monitoring IS-IS statistics and see that there are still Hello PDU drops.

Examine the Log

You look up ae0.0 entries in the traceoptions log file and find out that R3 does not receive Hello PDUs from R2.

Chapter 2-50 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R3 Adjacencies (5 of 6)
• Enable traceoptions at R2 and check the trace log
user@R2> show log isis.log
Mar 15 05:05:53.413277 Sending PTP IIH on ae0.0
Mar 15 05:05:53�413405 max area O, circuit type 11
Mar 15 05:05:53.413476 ptp adjacency tlv length 5
�..ar 15 05:05:53.413527 neighbor state down
---(more)---

• Match it against the R3 trace log data

user@R3> show log isis.log
Mar 15 05: 15: 53. 065303 Sending L2 LAN IIH on aeO. 0
Mar 15 05:15:53.401852 max area 0, circuit type 11
Mar 15 05:15:53.401955 hold time 27, priority 64, circuit id R3.00
Mar 15 05:15:53.402020 speaks IP
Mar 15 05:15:5j.402069 speaks IPv6
---(more)---

• Can you spot the issue?

Debugging IS-IS at R2
You then enable traceoptions on R2 to see if R2 sends the Hello PDUs. The traceoptions log file indicates that R2 does send the
Hello PDUs but they are point-to-point IS-IS Hello PDUs whereas R3 log file shows that R3 sends Level 2 LAN IS-IS PDUs.

www.juniper.net IGP Troubleshooting • Chapter 2-51

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R3 Adjacencies (6 of 6)
• Solution
• Make sure that the aeO.O interface at both R2 and R3 is
configured as either point-to-point or broadcast interface.

Solution
To ensure that the remaining neighbor adjacency is up, you must configure the aeO.O interface at both sides as either
point-to-point or broadcast.

Chapter 2-52 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Summary
• In this content, we:
• Listed useful common commands that are used to
troubleshoot and verify OSPF and IS-IS
• Isolated different OSPF issues
• Isolated different IS-IS issues

We Discussed:
Useful commands that can be used to troubleshoot and verify correct operation of OSPF and IS-IS;
Isolating different OSPF issues; and
Isolating different IS-IS issues.

www.juniper.net IGP Troubleshooting • Chapter 2-53

Advanced Junos Enterprise Routing Troubleshooting

Review Questions
1. Which LSA types are not forwarded into an OSPF
NSSA area with no summaries?
2. Which OSPF parameters must match to ensure
adjacency formation?
3. Why is a partitioned OSPF backbone area disruptive
in a multi-area OSPF network?
4. What are the different forms of IS-IS
authentication?
5. Why is NET uniqueness a mandatory requirement in
IS-IS networks?

Review Questions
1.

2.

3.

4.

5.

Chapter 2-54 • IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting IGPs Lab

• Monitor and troubleshoot the operation of an OSPF
and IS-IS networks with multiple areas and levels.

Troubleshooting IGPs Lab

The slide lists the objective for this lab.

www.juniper.net IGP Troubleshooting • Chapter 2-55

Advanced Junos Enterprise Routing Troubleshooting

Answers to Review Questions

1.
OSPJi LS/\ type 3, 4, and 5 arc not forwarded into an OSPF NSSJ\ area with no-summaries.

2.
OSI'!' area, nctmask, 1 lcllo and Dead intervals, OSP!' options, and interface MTU must match for neighbors to become adjacent.

3.

Partitioned OSPI., backbone area results in areas, attached to the isolated islands of the backbone area, inability to communicate to each
other.

4.
13y default IS-IS PD Us arc not authenticated. IS-IS supports simple text and MDS authentication types. In IS-IS you can explicitly
define which IS-IS PDUs to authenticate.

5.
IS-IS NET provides a router identity in an IS-IS domain. Duplicated NET results in inability of SPF process to correctly identify the
IS-IS node and as a result has a severe im pact on a network.

Chapter 2-56 • IGP Troubleshooting www.juniper.net

Advanced Junos Enterprise Routing
Troubleshooting

Chapter 3: BGP Troubleshooting

Advanced Junos Enterprise Routing Troubleshooting

Objectives
• After successfully completing this content, you will be
able to:
• List common commands used to troubleshoot and verify
BGP
• Isolate different issues with BGP communication and
configuration

We Will Discuss:
Common commands that are used in Border Gateway Protocol (BGP) troubleshooting; and
Isolating different BGP communication and configuration issues.

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

 Advanced Junos Enterprise Routing Troubleshooting

Agenda: BGP Troubleshooting

7BGP Overview
• BGP Troubleshooting
• BGP Case Study

BGP Overview
The slide lists the topics we will discuss. We discuss the highlighted topic first.

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

Advanced Junos Enterprise Routing Troubleshooting

BGP Overview (1 of 3)
• BGP protocol summary
• Path-vector protocol used for interdomain routing
• Views the Internet as a collection of autonomous systems
• Prefers the path with the least number of entries in the AS-Path
• Able to maintain massive amounts of routing data
• Implies careful design and accurate administration
• Establishes neighborship with configured peers
• Uses TCP for reliable transport
• Client;server model, listens to TCP port 179
• Requires underlying routing for the protocol messages delivery
• Recursive route lookup for routes learned from indirect peers

BGP Protocol Review

The BGP is a routing protocol between autonomous systems (ASs) and is sometimes referred to as a path-vector routing
protocol. An AS is defined as a group of IP networks operated by one or more network operators that has a single, clearly
defined routing policy. BGP relies on the uniqueness of AS path numbers for loop prevention.
BGP routing information includes the complete route to each destination. BGP uses the routing information to maintain an
information base of Network Layer reachability information (NLRI), which it exchanges with other BGP systems. The rich set
of supported BGP attributes allows for flexible policy actions. The use of administrative policy is to filter and modify routing
information to select the best route that meets the network operator's defined policy.
BGP routers exchange routing information between peers. BGP requires that all peering sessions be configured explicitly
between BGP neighbors.
BGP uses a reliable Transmission Control Protocol (TCP) transport for its control and update messages. Reliable transport
means there is no need for periodic route updates, which is important given that BGP typically exchanges with hundreds of
thousands of routes. BGP uses TCP port 179.
Because BGP is an application layer protocol it relies on underlying routing for the BGP messages delivery. For the directly
connected peers the peer reachability information is implicitly available, however for the indirect peers either static or
dynamic IGP routing must be provisioned.
Upon receiving a BGP update message carrying NLRls BGP verifies connectivity of a remote peer by examining the BGP
next-hop attribute. The BGP next-hop attribute is an IP address of a BGP peer. Recursive lookups into routing tables
accomplish the peer connectivity.

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

 Advanced Ju nos Enterprise Routing Troubleshooting

BGP Overview (2 of 3)
• BGP routing
• Sends update message that carries NLRI along with BGP
attributes
• Mandatory and optional attributes
• Allows extensive control using policy
• Supports routing for various protocol families
• 1Pv4 unicast only by default
• Session family may differ from NLRI family
• 1Pv4 sessions can be used to convey 1Pv6 NLRls
• BGP next hop must be of the same family as NLRI

BGP Routing
BGP advertises route reachability (NLRI), along with various attributes that describe the path to that prefix. Attributes,
combined with the extensive features of Junos routing policy, provide the ability to build a scalable set of rules that dictate
whether a network wants to filter an incoming route or influence the path of a neighbor.
All BGP route attributes fall into one of the following categories based on whether all BGP speakers are expected to
understand the attribute and whether the attribute has local-AS or end-to-end scope:
Well-known mandatory
Well-known discretionary
Optional transitive
Optional nontransitive
Continued on the next page.

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

Advanced Junos Enterprise Routing Troubleshooting

BGP Routing (contd.)

Primary BGP path attributes include:

Next hop: Well-known mandatory attribute that carries the IP address of a BGP speaker;
Local preference: Well-known discretionary attribute used to influence BGP path selection with regard to the
desired egress point for traffic from within an AS;
AS path: Well-known mandatory attribute that lists the AS numbers that will be crossed when forwarding to the
associated NLRI;
Origin: Well-known mandatory attribute that identifies the original source of a route as being learned from an
IGP, EGP, or unknown source;
Multi-exit discriminator. (Optional) Nontransitive attribute, which is added on updates sent over EBGP links, and
is then advertised by IBGP within the receiving AS to influence its outbound routing;
Community: (Optional) Transitive attribute that allows for the arbitrary grouping of routes that share one or more
characteristics via the addition of a common community tag value.
BGP is the extensible protocol that supports routing for various protocol families, for example 1Pv6 or virtual private network
(VPN) specific families. When you configure 1Pv4 BGP peering, BGP supports 1Pv4 unicast routing only by default. Vise versa
the 1Pv6 BGP sessions support only 1Pv6 unicast routing by default. You can however configure 1Pv4 BGP to enable support
of 1Pv6 routes as shown in the following example:
[edit protocols bgp]
user@srx# show
group ebgp {
family inet
unicast;

family inet6
unicast;

neighbor 10.1.254.1;
}

Note that you must explicitly enable 1Pv4 unicast family if you configure additional families support.
If an 1Pv4 BGP session is used to convey 1Pv6 routes BGP must use the BGP next hop of the same protocol family as the
NLRls for example, 1Pv6. BGP uses an 1Pv4-mapped 1Pv6 address as the BGP next hop in this case for example,
::ffff:192.168.1.1.

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

 Advanced Junos Enterprise Routing Troubleshooting

BGP Overview (3 of 3)
• BGP routing
• Keeps all routes in the routing table
• Active and inactive
• Stores filtered/unresolved routes in a hidden compartment
• Runs elaborate multi-step route selection algorithm
• Advertises only active routes by default
• BGP defaults
• Both IBGP and EBGP default preference is 170
• Default routing policies
• Import action is to accept BGP learned routes
• Export action is to advertise BGP only routes

BGP Overview
BGP uses three different storage tables known as Routing Information Bases (RIBs) to maintain routing knowledge. A
separate Adjacency-RIB-IN exists for each established BGP peer to store all routes received from that peer. RIB-LOCAL is
where BGP stores routes used for traffic forwarding. A separate Adjacency-RIB-OUT table is also created for each established
BGP peer to house the routes that are to be advertised to that peer.
A BGP speaker that is presented with two or more updates, specifying the same prefix, performs a route selection process to
select the best BGP path for that prefix. Once the best path is selected, the route is installed in the route table, where it may
become active if the same prefix is not being learned by a protocol with a better preference, for instance OSPF. BGP can
move only active BGP routes in the routing table into the Adjacency-RIB-OUT tables and advertise them to BGP peers. To
override this default action, you can use the advertise-inactive command.
Some of the routes received by BGP are not installed in the routing table. There are several reasons for this behavior:
Unresolvable BGP next hop;
A route is filtered by an import policy;
A martian route is received.
The Ju nos operating system marks these kinds of routes as hidden and maintains them in an isolated RIB. You can view
the hidden routes by using the show route hidden command.
Continued on the next page.

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

Advanced Junos Enterprise Routing Troubleshooting

BGP Defaults
In the Junos OS, BGP routes have the preference value of 170 regardless of the session type the route was learned from, IBGP
or EBGP.
You can use both import and export policies in BGP to achieve fine-grained control over BGP route selection and propagation.
By default, an implicit BGP import policy accepts all BGP received routes that pass sanity checks of loop prevention and
which BGP next hop is reachable. A BGP implicit export policy advertises all BGP active routes out of the local routing table.

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

 Advanced Junos Enterprise Routing Troubleshooting

BGP Global View

• BGP propagates routing updates over BGP sessions
• EBGP between peers in different Autonomous systems
• IBGP between peers in the same Autonomous system

BGP Global View

The slide shows a global simplified view of the BGP network. BGP sessions are either internal BGP (IBGP) or external BGP
(EBGP) sessions. If the two peers are in the same AS, the BGP session is an IBGP session. If the two peers are in different ASs,
the BGP session is an EBGP session.
For the most part, BGP operation is the same when operating internally to an AS versus externally to a remote AS but there are
some important differences.

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

Advanced Junos Enterprise Routing Troubleshooting

IBGP Overview
• IBGP specifics
• IBGP sessions are usually established between loopback
addresses
• Uses IGP to maintain sessions regardless of physical topology
• BGP speakers do not propagate IBGP-received routes to
other IBGP peers
• Fully meshed IBGP design
• Route reflection or Confederation
• By default, IBGP peers do not change the next hop for routes
received from EBGP peers
• Put external interface in IGP using the passive option. or
• Use next-hop self in a policy to cause the router to use its own
IP address as the next hop

IBGP Overview
IBGP sessions are typically established using loopback interface peering. The IGP is used to maintain reachability between
the loopback addresses regardless of the physical topology, allowing the IBGP sessions to stay up even when the physical
topology changes. The physical topology is relevant in one respect, each router along the path between BGP speakers must
have enough information to make consistent routing decisions about packet forwarding. In many cases, this requirement
means that all routers along all possible physical paths between BGP speakers must run BGP.
IBGP updates do not alter the AS path attribute. Because loops become a concern, BGP speakers never send routes to IBGP
peers that they learned from other IBGP peers. For all lBGP speakers in an AS to have consistent routing information, there
must be a full mesh of IBGP sessions between them.The two primary ways to eliminate the need for a full BGP mesh are
route reflection and BGP confederations.
Route reflection allows a special BGP speaker, route reflector, to re-advertise an IBGP-learned route to another IBGP speaker.
The route reflector does not change the existing BGP attributes but adds two new attributes to IBGP updates to address
concerns about BGP loops that could otherwise occur, given that IBGP updates do not modify the AS path, cluster list, and
originator ID. Route reflection can represent a single point of failure, making it common to add redundancy by deploying
multiple route reflectors. Normally, each route reflector establishes an IBGP session with each client in the cluster, and the
two route reflectors are then joined using a non-client IBGP session.
Confederation use is rare in enterprise networks.
Continued on the next page.

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

 Advanced Junos Enterprise Routing Troubleshooting

IBGP Overview (contd.)

By default, the BGP next-hop attribute is unchanged as it passes through an AS on an IBGP session. Because routers can
use the BGP routes only if they already have a route to the next hop, you must either configure the routers to advertise
external interfaces through the IGP or configure the routers to change the BGP next-hop attribute using policy. Using the
next-hop self action in a policy causes the router to send BGP routes to its peers using the same IP address it uses to
establish that BGP session. For the BGP session to remain established, the peer must have a route to that IP address.
Therefore, using next-hop self guarantees that a router's peers can reach the next hop of the routes that router sends,
as long as the BGP session remains established.

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

Advanced Junos Enterprise Routing Troubleshooting

EBGP Overview
• EBGP specifics
• EBGP sessions are usually established using the IP
addresses of the physically connected interfaces
• Sometimes an indirect peer address session is preferred
• Redundant paths. load sharing
• Use mul tihop configuration to establish EBGP session to indirect
peers
• A static route for the peer address is required
• Per-prefix load sharing can be achieved by enabling
multipath
• Two peering sessions to the same router
• Two peering sessions to different routers in the same neighboring
autonomous system

EBGP Overview
EBGP normally peers to a neighbor using an address on the directly connected link between the routers. As a result, no route
recursion is needed to resolve the BGP peering address to a next hop forwarding address. For security reasons, the TIL for
EBGP sessions is set to 1 by default, which prevents attempts to peer from a remote link. This behavior can be altered by
configuring the multi hop option for the EBGP session.
When multiple physical links connect two routers that are to be EBGP peers the mul tihop configuration provides a
redundant solution. In this case, if one of the point-to-point links fails, reachability on the alternate link still exists. This
approach allows per-prefix load sharing.
For the multihop EBGP session each router must have IP routing capability to the remote router's loopback address. Usually
a static route is used for this purpose. Note that when multi hop is configured, the Junos OS sets the TIL value to 64, by
default.
Multihomed connections from an enterprise network to the ISP provide redundant BGP connectivity. If the paths from both
connections are equal-cost, the default BGP behavior is to select the single best route to a destination. The result is that BGP
uses only one of the links to forward traffic. As long as both links are up, you may want to use both, sharing the traffic
between them to increase the bandwidth. Multipath BGP allows the traffic to be load-balanced across the two links. The
multipath configuration can be used across several peering sessions to the same EBGP peer or different EBGP peers in
the same neighboring autonomous system.

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

 Advanced Junos Enterprise Routing Troubleshooting

BGP Enterprise Specific View

• Complex enterprise topologies usually incorporate
BGP
• Provides diverse administrative control
• Can handle large prefix counts
DMZ

-
a .\
MPLSWAN

----
/fltemet '6>· •• ,·· AS 65003'•,,.
Yl

-
VPN �, ;o
------ . .. . . •"' HQ
···..............·......... . ··
Branch '���
..
Offices

Using BGP in the Enterprise

The slide shows a high-level view at a generalized complex enterprise network.
BGP is a sophisticated routing protocol that can help to optimize an enterprise's routing.
Some of BGP strengths are sophisticated routing policy control, the ability to define network boundaries with Autonomous
systems, which allows a more flexible division of administrative duties to network personnel, and handling large prefix
counts.

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

Advanced Junos Enterprise Routing Troubleshooting

Agenda: BGP Troubleshooting

• BGP Overview
78GP Troubleshooting
• BGP Case Study

BGP Troubleshooting
The slide highlights the topic we discuss next.

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

 Advanced Junos Enterprise Routing Troubleshooting

General IBGP Troubleshooting Steps

. Check security policies

-..,
Check IGP routing

. Check the update source address

Check authentication
Monitor syslog files
J §
. I

. Check for IGP redundant paths availability

Watch for MTU. TCP MSS and fragmentation
�""

I §....
Check export policy �
ti
i
Check inactive routes
N oa
- dvertise community
Check BGP family for the session

I
.
Cl

. Check the BGP Next hop

Check for recursive routing
No

. Check import policy

I

General IBGP Troubleshooting Steps

The purpose of the IBGP troubleshooting flowchart shown on the slide is to provide a set of high-level steps designed to get
you started with IBGP fault analysis.
You begin with verifying of IBGP peering sessions state. If a session does not come up you start examining various
parameters that we have discussed in the previous section, that can affect the session establishment. First, you want to
make sure that your security policies or firewall filters allow BGP protocol messages. For IBGP sessions you verify the remote
peer loopback reachability by inspecting the IGP routing. You may want to check the update source IP address, which is
typically the loopback address. In case if BGP uses authentication you have to make sure that authentication parameters
match at both ends.
For more difficult issues you may want to check the system TCP sockets, monitor the system log files or debug BGP with
traceoptions.
Once the IBGP sessions come up you monitor the session state to ensure that they are stable. For flapping sessions watch
for IGP instabilities, or TCP MSS related issues.
If the IBGP sessions are up and running you proceed to examining BGP routes advertised and received by the router. Lack of
advertised routes may be the indication of incorrect export policy action, presence of inactive routes, lack of configured BGP
family support, or presence of routes tagged with the no-advertise community.
If some routes appear to be hidden, you can suspect the BGP next-hop resolution problem, or the recursive routing failure.
The absence of expected BGP routes in the routing table may be also the indication of incorrect import policy filtering the
routes.

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

Advanced Junos Enterprise Routing Troubleshooting

General EBGP Troubleshooting Steps

( "
y
Check securit policies
Check for multihop settings
Check authentication
Monitor syslog files
No I
Watch for flapping lmk 0
Check the link MTU mismatch
I
r Check export policy 8...
. Check inactive routes
No-advertise. no-€xport communities
u
. Check BGP family for the session
In aggregation check for contributing routes £C)

I
Check for prefix limit

Check import polrcy

I
Check for damping
'\.

General EBGP Troubleshooting Steps

The purpose of the EBGP troubleshooting flowchart shown on the slide is to provide a set of high-level steps designed to get
you started with EBGP fault analysis.
You begin with verifying of EBGP peering sessions state. You generally follow the same procedures as for IBGP session
troubleshooting.
Once the EBGP sessions come up you monitor the session state to ensure that they are stable. For flapping sessions watch
for link behavior, or MTU related issues.
If the EBGP sessions are up and running you proceed to examining BGP routes advertised and received by the router. You
generally follow the same procedures as for IBGP routing troubleshooting. Lack of advertised routes can be the indication of
incorrect export policy action, presence of inactive routes. lack of configured BGP family support, or presence of routes
tagged with the no-advertise or no-export community.
If a router is configured with the BGP prefix limit it might not drop the BGP session depending on the prefix limit settings. by
default, the prefix limit setting does not tear the session down if the limit is reached but just sends a warning message to the
system log.
If some routes appear to be hidden, you can suspect an incorrect import policy filtering the routes or the recursive routing
failure.
If route flap damping is enabled on an BGP ASBR, then some routes can be suppressed by the damping algorithm in case of
the routes oscillation.

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

 Advanced Junos Enterprise Routing Troubleshooting

BGP Troubleshooting Checklist (1 of 4)

• Ensure BGP protocol traffic is being allowed into the

loca I device
• Watch for BGP TCP session issues
• BGP messages use TCP transport
• Often the BGP peering problems occur because the TCP
connection fails

Security Policies Must Allow BGP Communications

BGP troubleshooting generally falls into one of two categories, peering session establishment troubleshooting or routing
troubleshooting. When you troubleshoot BGP peering sessions, make sure that your security policies or firewall filters do not
prevent protocol communications.

TCP Session Establishment

You must establish a TCP connection to exchange traffic using BGP routers. The possible state for the TCP connection is one
of the following
Idle: The initial neighbor state, BGP waits for start event;

Connect: BGP waits for TCP connection to be completed;

Active: TCP timeout has occurred and the TCP session is not established yet. System continues to listen for
completion of TCP session.
When two BGP peers cannot establish a BGP session, the BGP state field in the show bgp summary command is Active
or Connect, indicating that the BGP session is not established. When the BGP state is Idle, the local BGP implementation
cannot try to establish the session.
Session problems often occur because the TCP session between a pair of peers cannot effectively transmit data between
the routers-not because of a problem with BGP itself. When the TCP session fails to work properly, the BGP session times
out, and BGP signals the problem by sending hold-time expired messages to the system log files.

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

Advanced Junos Enterprise Routing Troubleshooting

BGP Troubleshooting Checklist (2 of 4)

• IBGP peering session establishment issues

• Misconfigured peer IP address
• Missing local source IP address
• No route to neighbor
• Large TCP MSS that causes BGP packet fragmentation and
a firewall filter dropping the fragments
• Passive neighbor setting at both ends
• Authentication parameters mismatch

IBGP Peering Troubleshooting

Several reasons can explain why an IBGP session does not come up. Mostly they are related to TCP transport issues. For
example, if you misconfigure an IBGP peer address your router will not be able to deliver the BGP messages to the remote
peer.
IBGP usually uses indirect peering using the routers' loopback interfaces. Hence, BGP relies on underlying IGP protocol for
the remote peer loopback reachability. If the loopback route is missing in the IGP the TCP connection and so BGP session fail
to establish.
When defining a BGP loopback peering session, you need to correctly match the source address used by the local peer to
ensure that it matches the session definition at the remote peer. By default, the router will source traffic from its egress
interface, which will not be the loopback interface, and this can make the incoming connection request appear to come from
an undefined peer. Note that the Junos OS is able to successfully establish a BGP session even if you have one of the two
peers configured without the local�address setting but generally you should avoid these situations.
You can configure a BGP neighbor with passive setting. This configuration will make the local BGP speaker to not try to
initiate the BGP TCP session but instead wait for its peer to send the first TCP syn packet. If the two peers are both
configured with the passive setting the session will not come up.
Continued on the next page.

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

 Advanced Ju nos Enterprise Routing Troubleshooting

IBGP Peering Troubleshooting (contd.)

By default, a BGP TCP session transmits 576 bytes in a single packet to minimize the chances that the packet will be
fragmented at a device along the path to the destination. You can configure the TCP maximum segment size (MSS) to a
higher value in an attempt to optimize delivery of the large BGP packets, typically BGP Update messages. In this scenario if a
link on the path of the BGP messages has an MTU that cannot handle the large TCP segment, the packet will be fragmented.
An issue might arise if you have a firewall filter rejecting the TCP fragments somewhere on the path.
One workaround is to enable path MTU discovery in the BGP configuration. Path MTU discovery, which is disabled by default
in the Junos OS, allows BGP to dynamically determine how large the packets can be in a TCP session without being
fragmented. Note however, that enabling TCP path MTU discovery might create an ICMP vulnerability.
You can configure BGP authentication to guarantee that only trusted routers participate in the AS's routing. The mismatched
authentication parameters will prevent the BGP session establishment. Note that authentication data are included in TCP
segments and are processed by Junos kernel. The mismatched authentication is reported by kernel in the system log file.
user@srx> show log messages
Apr 14 06:22:24 srxA-2 /kernel: tcp_auth_ok: Packet from 10.222.1.2:63028 missing
MDS digest

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

Advanced Junos Enterprise Routing Troubleshooting

BGP Troubleshooting Checklist (3 of 4)

• EBGP peering session establishment issues

• Misconfigured peer IP address
• Misconfigured peer or local AS number
• MTU mismatch
• One hop (default) or multiple hops
• Passive setting at both ends
• Authentication parameters mismatch

EBGP Peering Troubleshooting

EBGP normally peers to a neighbor using an address on the directly connected link between the routers. Misconfigured peer
address will prevent your router from establishing the session.
You can configure a multihop EBGP session. You must take three extra configuration steps to accomplish this. First, each
router must establish the peering session with the loopback address of the remote router. You configure this session using
the local-address command. Second, use the mul tihop command to alter the default TIL of 1 on EBGP sessions.
Third, each router must have IP routing capability to the remote router's loopback address. Fail to configure any of these
parameters results in a BGP session that does not come up.
A typical BGP protocol specific session failure occurs if the neighboring or local autonomous system number do not match
the configuration at the remote peer. BGP detects this problem when it starts exchanging BGP open messages. The BGP
speaker then sends the BGP notification message to its peer reporting the issue.
With directly connected EBGP sessions, TCP uses MTU-sized packets. If there is an MTU mismatch between the two sides of
the TCP connection, the BGP session can be dropped if a large BGP packet, typically BGP update message does not fit the
MTU size. This failure typically occurs in multi-vendor environments where different vendors might handle the interface MTU
differently.
Similarly to the IBGP sessions the mismatched authentication parameters will prevent the BGP session establishment.
The configuration of passive peers at both sides will prevent the session establishment as well.

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

 Advanced Junos Enterprise Routing Troubleshooting

BGP Troubleshooting Checklist (4 of 4)

• BGP routing issues

• Received routes
• BGP next hop is not reachable
• Import filtering policy
• Prefix limit is reached
• Recursive routing failure
• Advertised routes
• Export filtering policy
• Configured aggregation with missing contributing routes
• Inactive routes
• Well-known route advertisement controlling communities are
attached to a route

BGP Routing Troubleshooting

Once BGP peering sessions are established successfully BGP neighbors exchange with BGP update messages advertising
NLRls. In the process of troubleshooting of BGP routing you generally monitor the routing updates flowing in either receive or
send direction.
When BGP router receives a BGP update it first checks that it can reach the BGP next hop. It uses a recursive route lookup to
resolve the loopback peering address to an IP forwarding next hop. This is not an issue in a typical EBGP session using the
physical interface address for the peering session. It might become an issue in an IBGP environment or on the multihop
EBGP sessions.
Recall that BGP default import policy accepts all BGP received routes that pass the sanity checks. If an incorrect filtering
import policy is applied you may end up with filtering good routes. Recall that you can verify that a policy has filtered some
routes by examining the hidden routes.
You can set a limit on the amount of prefixes received from a peer. The prefix limit configuration provides an option of tearing
the session down once the limit is reached along with the holddown timer. If the received prefixes hit the limit the router
ceases the session and sends the BGP notification message reporting the problem. The router then waits for the specified
period before it attempts to re-establish the BGP session.
Continued on the next page.

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

Advanced Junos Enterprise Routing Troubleshooting

BGP Routing Troubleshooting (contd.)

The following example shows the BGP prefix limit configuration:

[edit protocols bgp group ebgp]

user@srx show
family inet {
unicast {
prefix-limit
maximum 25000;
teardown 80 idle-timeout 10;

The recursive routing failure occurs if a BGP router receives a BGP route and the recursive lookup of this route's BGP next
hop results in using the route itself. This failure would result in BGP session failure and constant deletion and reinsertion of
BGP routes into the routing table. The Junos OS performs a sanity check for this kind of failure and if it is detected, it marks
the offending route as hidden, and ignores it.
If routes are not being advertised you might suspect an incorrect export filtering policy. Recall that by default BGP advertises
all active BGP routes to its peers. An incorrect export policy can filter the routes that you want to advertise.
Often BGP ASBRs employ the route aggregation by configuring aggregate or generated routes and exporting these routes to
BGP. Recall that for an aggregate route to be active it must have at least one active contributing route in the routing table.
A BGP route can become inactive if it is shadowed by the same route learned from a protocol with a lower preference. Recall
that you can make BGP advertise the inactive routes by configuring advertise-inactive option.
Some routes might be tagged with one of the well-known communities regulating the route propagation. The no-export,
no-export-subconfed, and no-advertise. are the three well-known community values.
The no-export community tells routers to distribute routes with this community tag within their autonomous system, but
no further. The no-export- subconfed community tells routers not to distribute routes with this community tag to
external BGP peers. The no-advertise community tells routers not to advertise these routes to other BGP peers at all.
If mistakenly configured this communities will set a scope on the BGP route propagation thus preventing the routes
advertisements.

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

 Advanced Junos Enterprise Routing Troubleshooting

Useful BGP Operational Commands (1 of 8)

• Check summary information about BGP peers

user@srx> show bgp summary

G::-oups: 2 Peers: 5 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State .Pending
inet.O
0 0 0 0 0 0
Peer 1'.S InPkt Cut Pkt OutQ Flaps Last Up/Dwn
Statel#Active/Received/Accepted/Da.�ped...
10.1.254.1 100 267 274 0 0 2:03:52 0/0/0/0
0/0/0/0
10.222.1.l 65000 270 276 0 0 2:05:11 0/0/0/0
0/0/0/0
10.222.1.3 65000 315 316 0 0 2:22:40 0/0/0/0
0/0/0/0
---(more)---

Checking BGP Session State

Use the show bgp summary command to view basic information about all BGP neighbors. This command displays the list
of peers along with the peer AS number, the peer statistics and the peer state. The state column displays either the BGP
state or the amount of prefixes received from the neighbor.

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

Advanced Junos Enterprise Routing Troubleshooting

Useful BGP Operational Commands (2 of 8)

• Check summary information about local BGP groups

� user@srx> show bgp group

Group Type: Internal AS: 65000 Local AS: 65000
Name: cbgp Index: 0 Flags: <>
Bcldtime: 0
Total peers: Established:
10. 22 2. 1. 1+51717
10.222.1.3+59820
10.222.1.4+57550
10.222.1.5+56737
inet.O: 0/0/0/0

Group Type: External Local AS: 65000

Name: aslOO Index: Flags: <Export Eval>
Export: [ ebgp-export
Holdtime: 0
Total peers: 1 Established:
10.l.25�.1+50692
inet.O: 0/0/0/0
---(more)---

Viewing BGP Group Parameters

Use the show bgp group command to view the BGP group information. This command displays the established peers
summary per BGP group. It is particularly useful in checking the group applied export policies.

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

 Advanced Ju nos Enterprise Routing Troubleshooting

Useful BGP Operational Commands (3 of 8)

• Check BGP neighbor session details
user@srx> show bgp neighbor 10.1.254.1
Peer: 10.1.254.1+50692 AS 100 Local: 10.1.254.2+179 AS 65000
Type: £xternal State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: Cease
Export: ( ebgp-export j
Options: <Preference Peer�£ Refresh>
Holdtime: 90 Preference: 170
Number of flaps: 1
Last flap event: Stop
Error: •cease' Sent: 1 Recv: 0
Peer ID: 10.1.1.1 Local ID: 10.222.1.2 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
Local Interface: ge-0/0/4.303
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
---(more)---

Checking BGP Neighbor Details

Use the show bgp neighbor command to display the neighbor details.

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

Advanced Junos Enterprise Routing Troubleshooting

Useful BGP Operational Commands (4 of 8)

• Check which routes are being advertised
user@srx> show route advertising-protocol bgp 10.1.254..1

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

P.z:efix Nexthop MED Lclpref AS path
* 10.222.0.0/30 Self
* 10.222.0.4/30 Se.lf
---(more)---

• Check which routes are being received

user@srx> show route receive�protocol bgp 10.1.254.1

inet.O: 52 destinations, 53 routes (52 active, 0 holddcwn, 1 hidden)

Prefix Nexthop MED Lclpref AS path
• 0.0.0.0/0 10.1.254.1 100
• 10.1.100.0/24 10.1.254.1 100
10.1.101.0/24 10.1.254.1 100 I
---(more)---

Displaying BGP Advertised Routes

The show route advertising-protocol bgp neighbor command as it has been prepared for advertisement to
the specified BGP neighbor. The information reflects the routes after the export policy processing. Note that the local AS
number being prepended is not shown in the output.

Displaying BGP Received Routes

The show route receive protocol bgp neighbor command displays the BGP routes received from the specified
BGP neighbor. The information reflects the routes before import policy processing, with the exception of filtered routes.

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

 Advanced Junos Enterprise Routing Troubleshooting

Useful BGP Operational Commands (5 of 8)

• Check BGP routes in the routing table
user@srx> show route protocol bgp

inet.O: 52 destinations, 53 routes (52 active, O holddown, 1 hidden)

+ = Active Route, - = Last Active, Both

0.0.0.0/0 *[BGP/170] 00:20:05, localpref 100

1'.S path: 100 I
> to 10.1.254.1 via ge-0/0/4.303
10 .1.100. 0/24 *[BGP/170] 00:20:05, localpref 100
1'.S path: 100 I
> to 10.1.254.1 via ge-0/0/4.303
10.1. 101. 0/24 *[BGP/170] 00:20:05, localpref 100
A.Spath: 100 I
> to 10.1.254.1 via ge-0/0/4.303
--- (more} ---

Checking the BGP Routes in the Routing Table

Use the show route protocol bgp command to display routes in the routing table installed by BGP. You can use
various filters with this command to display only certain routes. For example, you can view only active or inactive routes, use
source-gateway option to view only routes received from a particular neighbor, filter the routes based on AS path or
community regular expression.

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

Advanced Junos Enterprise Routing Troubleshooting

Useful BGP Operational Commands (6 of 8)

• Check TCP session in-depth details
user@srx> show system connections inet extensive
Active Internet: connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address
(state)
t.cp4 0 0 10.1.254.2.179 10.1.254.1.50692
EST�.BLISHED
sndsbcc: O sndsbmbcnt: O sndsbmbrriax: 131072
sndsblowat: 2048 sndsbhiwat: 16384
r.cvsbcc: O rcvsbmbcnt: O rcvsbmbmax: 131072
rcvsblowat: 1 rcvsbhiwat: 16384
proc id: 1 proc name:
iss: 736518468 sndup: 736522526
snduna: 736522526 sndnxt: 736522526 sndwnd: 16384
snd.111ax: 736522526 sndcwnd: 7240 sndssthresh: 1073725440
irs: 3302125072 rcvup: 3302128689
rcvnxt: 3302128689 rcvadv: 3302145073 rcvwnd: 16384
rtt: 0 srtt: 3359 rttv: 37
rxtcur: 1200 rxtshift: 0 rtseq: 736522507
rttmin: 1000 mss: 1448
flags: REQ_SCALE RCVD SCALE REQ_TSTMP RCVD_TSTMP SACK_PERMIT [0x3e0]
--- (more) ---

Checking System TCP Connections

Use the show system connections command to view the kernel TCP sockets state. Recall that BGP uses TCP transport
so monitoring the system TCP sockets is useful in troubleshooting malfunctioning TCP connections. You might be interested
in looking up BGP specific TCP sessions in the output by matching on the BGP TCP port number 179.
The extensive version of this command displays various low-level debugging information on the TCP connections. For
example, you might want to check the TCP MSS size used by the local router for a given session. Some of the other
interesting pieces of information provided by the command are:
sndcc: Bytes on send buffer. A full send buffer typically means that packets from this host are not being
acknowledged;
rcvcc: Bytes on receive buffer;
snd_wnd: Size of the window advertised by the peer; and
rcv_adv, rcv_nxt: The difference between these two is the size of the window advertised by the local TCP stack.

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

 Advanced Junos Enterprise Routing Troubleshooting

Useful BGP Operational Commands (7 of 8)

• For difficult problems, go to debugging
• Monitor the syslog files
user@srx> show log messages I find notification
Mar 18 02:45:39 srx rpd[1325]: bgp_pp_recv:3286: NOTIFICATION sent to 10.222.1.3
(Internal AS 65000}: code 6 (Cease) subcode 7 (Connection collision resolution), Reason:
dropping 10.222.1.3 (Internal AS 65000), connection collision prefers 10.222.1.3+59820
(proto)
Mar 18 02:45:39 srx rpd[1325]: bgp_pp_recv: dropping 10.222.1.3 (Internal AS 65000),
connection collision prefers 10.222.1.3+59820 (proto)
---{more)---

• Use traceoptions
user@srx> show log bgp.log

Mar 18 04:20:49.434306 bgp_send: sending 59 bytes to 10.1.254.l (External AS 100)

Mar 18 04:20:49.434367
Mar 18 04: 20:49. 434367 BGP SEND 10.1.254.2+55960 -> 10.1.254.1+179
Mar 18 04:20:49.434460 BGP SEND message type 1 (Open) length 59
Mar 18 04:20:49.434523 BGP SEND version 4 as 65000 holdtime 90 id 10.222.1.2 parmlen 30
Mar 18 04:20:49.434598 BGP SEND MP capability AFI=l, SAFI=l
Mar 18 04:20:49.434648 BGP SEND Refresh capability, code = 123
---(more)---

Debugging BGP: Part 1

Various BGP session status messages are reported to the system syslog daemon, which stores them in a system log file,
typically /var I log/ messages. Monitor the log file for BGP related issues.
The example on the slide shows a BGP Notification message that the local BGP speaker sent to the 10.222.1.3 neighbor in
the process of BGP collision resolution.
To perform debugging functions of the BGP routing use the Junos OS traceoptions function. The trace output is sent to a
named log file in /var/log directory. You can define various BGP parameters to trace in the traceoptions configuration.
You can view the log file by using the show log filename command or you can monitor the updates in the log file
dynamically with the monitor start filename command. Remember to stop monitoring when you are done with the
monitor stop command.
The sample output on the slide shows a BGP open message sent by the local BGP speaker to the neighbor 10.1.254.1 with
the full message decode.
Note that you should not normally use traceoptions in a stable production network because the debugging process
consumes additional processing resources.

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

Advanced Junos Enterprise Routing Troubleshooting

Useful BGP Operational Commands (8 of 8)

• For difficult problems, go to debugging
• Monitor traffic interface also called tcpdump
user@srx> monitor traffic interface ge-0/0/4.303 no-resolve detail matching tcp
l Address resolution is OFF.
�is�ening on ge-0/0/4.303, capture size 1514 bytes

I 04:23:22.887679 In IP (cos OxcO, ttl 1, id 34525, offset O, flags (none], proto: TCP
(6), length: 170) 10.1.254.1.179 > 10.1.254.2.57891: P 79:197(118) ack 98 win 16365
<nop,nop,timestamp 834133740 836758381>: BGP, length: 118
Keepalive Message (4), length: 19
Update Message (2), length: 76
origin (1), length: 1, Flags [T]: IGP
AS Path (2), length: 6, Flags [Tl: 100
Next Hop (3), length: 4, Flags [TJ: 10.1.254.1
Updated routes:
10.1.100.0/24
10 .1.101. 0/24
---(more)---

Debugging BGP: Part 2

You might also want to trace the protocol messages on a router interface by using the monitor traffic interface
interface-name command. This command is essentially a front end to a well known tcpdump utility. You can use various
filtering options in this command, for example, to capture only BGP messages you can use the following filter:
user@srx> monitor traffic interface ge-0/0/4.303 matching "tcp and port 179"

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

 Advanced Junos Enterprise Routing Troubleshooting

Agenda: BGP Troubleshooting

• BGP Overview
• BGP Troubleshooting
7 BGP Case Study

BGP Case Study

The slide highlights the topic we discuss next.

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

Advanced Junos Enterprise Routing Troubleshooting

BGP Case Study: Neighborship Issues

• Topology, symptoms, and relevant information:

• Your company established a new branch office that requires redundant
Internet connection with BGP routing. When BGP is configured and
activated on the routers, you find that R1 EBGP session does not come
up and R1 IBGP session with R4 is flapping. Physical connectivity and
IGP routing have been verified and they are working fine. The routers'
security policies are verified and they permit BGP messages.

Ri RR RR R2
.1
ISPA ISPB
222.0.0/30 ·
10.1.2
� ,,, "4.0/30
,1
ft., ,,, .13
AS 100 10. AS� : 102 2012;30 AS 200
....,, .14 I
{
,

'i}AR4
10.222.020/30 �

BGP Case Study: Neighborship Issues

The slide presents a network topology, reported symptoms and description of a case related to BGP peering session issues.
In this case study your company established a new branch office the requires BGP routing. When you configured and
activated BGP on the routers the verification showed that R1 EBGP session does not come up and R1 IBGP session with R4
is flapping. You verified all physical connections and they are working fine. You have also checked the security policies and
have not found any issues.

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

 Advanced Ju nos Enterprise Routing Troubleshooting

Troubleshooting R1 EBGP Session (1 of 2)

• Check the session state
user@Rl> show bgp summary

Peer AS In Pkt OUtPkt OutQ Flaps Last Up/Own

StatelfActivP./ReceivPd'���entP.dlnamned...
10.1.254.1 100 1799 1881 0 15 24 Active I
10.222.1.3 65000 1905 1936 0 3 14:23:07 0/9/9/0
0/0/0/0
---(more)---

• Check the neighbor details

user@Rl> show bgp neighbor 10.1.254.1
Peer: 10.1.254.1 AS 100 Local: 10.1.254.2 AS 65000
Type: External State: Active Flags: <>
Last State: I.:ile Last Event: Start
Last Error: Open Message Error
Export: [ ebgp-export]
Options: <Preference AddressFamily PeerAS Refresh>
Address fa.�ilies configured: inet-unicast inet6-unicast
Holdtime: 90 Preference: ·170
Number of flaps: 15
Last flap event: RecvNot�fv
Error: 'Open Message Error' Sent: 6 Recv: 0 I
Error: 'Cease' Sent: 13 Recv: 2

Check R1 BGP Sessions

You begin with inspecting R1 BGP sessions. You use the show bgp summary command to get a brief summary of all the
sessions. The command shows that R1 EBGP session with the neighbor 10.1.254.1 in Active state.

Check the Neighbor Details

You use the show bgp neighbor command to view the EBGP neighbor details. The output of the command indicates that
there is an active error (Open message error).

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

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R1 EBGP Session (2 of 2)

• Look up the syslog file for BGP errors
ussr@Rl> show log messages I match 11open message n
Mar 19 00:07:31 Rl rpd[1325]: bgp_pp_recv:3124: NOTIFICAT·ION sent to 10.1.254.1+52788
(proto): code 2 (Open Messaae Error) subcode 2 fbad oeer AS number} Reason: no group for
10.1.254.1+52788 (proto)lfrom AS 1000 found (peer as mismatch), dropping hi.ml
I --- (more) ---

• Solution:
• The neighbor in AS 100 should correct their AS number

Check the R1 Syslog File

Because the neighbor session signal the Open message error you decide to look in the syslog file for the open
message entries. The search presents a message pointing out to the source of the problem.

Solution
The neighboring autonomous system is misconfigured. They should correct the setting.

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

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R1-R4 IBGP Session

(1 of 10)

• The session state monitoring indicate a flap every

1:30 minutes
user@Rl> show bgp summary
. . .
Peer AS InPkt Out Pkt OutQ Flaps Last Up/Dwn
Statel#Active/Received/Accepted/Darnped...
...
10.222.1.4 65000 210 223 0 0 1:34:20 0/0/0/0
0/0/0/0
10.222.1. 5
0/0/0/0
65000 216 294 0
I 26 1:29 0/0/0/0
I
user@Rl> show bgp summary
...
Peer AS InPkt Out Pkt OutQ Flaps Last Up/Dwn
StatelfActive/Received/Accepted/Damped...
...
10.222.1.4 65000 201 215 0 0 1:30:21 0/0/0/0
0/0/0/0
10.222.1.5 65000 207 280 0
I 27 4 Active
I

Troubleshooting R1 IBGP Session with R4

You proceed to troubleshooting the R1 IBGP session with R4. A periodic issue of the show bgp summary command
indicates that the session bounces once in about 1:30 minutes.

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

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R1·R4 IBGP Session

(2 of 10)
• The syslog messages shows Hold timer error
user@Rl> show log messages I match notification I match 10.222.1.5
Mar 19 00:38:26 srxA-1 rndf1325�: bao read v4 messaae:10258: NOTIFICATION received from
10.222.1.5 (Internal AS 65000); code 4 {Hold Timer Expired Errorj, socket buffer sndcc:
259 rcvcc: 0 TCP state: 4, snd_una: 567635780 snd_nxt: 567636020 snd_wnd: 16384 rcv_nxt:
3933071576 rcv_adv: 3933087939, hold timer out 90s, hold timer remain 0.002139s
Mar 19 ·00:40:28 s:r:xA-1 rpd[1325}: bgp_read_v4_message:10258; NOTIFICATION received from
10.222.1.5 (Int�rnal AS 65000): code 4 (Hold Timer Expired Error), socket buffer sndcc:
259 rcvcc: 0 TCP state: 4, snd_una: 1364380205 snd_nxt: 1364380464 snd_wnd: 16384 rcv_nxt:
I 261�298917 rcv_adv: 2614315280, hold timer out 9Ds, hold timer remain l:29.999B25s
--- (more) ---

Examine the Syslog File

You decide to examine the syslog file for BGP notification messages. The lookup reveals that the messages file contains
entries for BGP notifications received from R4. The reason for this problem is that the neighbor sends notification messages
indicating the BGP hold timer is expiring.

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

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R1-R4 IBGP Session

(3 of 10)

• Check the failed neighbor details

user@Rl> show bgp neighbor 10.222.1.5
Peer: 10.222.1.5 AS 65000 Local: 10.222.1.2 AS 65000
Type: Internal State: Active (route reflector client)Flags: <>
Last State: Idle Last Event: Start
Last Error: Cease
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 10.222.1.2 Holdtime: 90 Preference: 170
Number of flaps: 34
Last flan event: RecvNotifv
Error: 'Hold Timer Expired Error' Sent: 0 Recv: 33 I
Error: 'Cease' Sent: 1 Recv: u

• Ping just works

user@Rl> ping 10.222.1.5 source 10.222.1.2
PING 10.222.1.5 (10.222.1.5): 56 data bytes
64 bytes from 10.222.1.5: icrnp_ssq=aO ttl=63 time=2.237 ms
64 bytes from 10.222.1.5: icmp_seq=l tt1=63 time=l.850 ms
·c
--- 10.222.1.5 ping statistics ---
2 packets transmitted, 2 packets received 1 0% packet lass
round-trip min/avg/max/stddev = l.850/2.043/2.237/0.194 ms

Check the R4 Neighbor Details

The show bgp neighbor command also shows the Hold Timer Expired Error.

Check the Connectivity

You proceed to monitoring end-to-end connectivity between the two IBGP neighbors. The ping tests and interface checks
have not revealed any issues.

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

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R1·R4 IBGP Session

(4 of 10)
• Tracing at R1 shows regular BGP message exchange
user@Rl> show log bgp. log I match "(BGP SEND) I (BGP RECV)"
Mar 19 02:03:57.497394 BGP SEND 10.222.1.2+57161 -> 10.222.1.5+179
Mar 19 02:03:57.497491 BGP SEND message type 1 (Open) length 59
¥.ar 19 02:03:57.503939 BGP RECV 10.222.1.5+179 -> 10.222.1.2+57161
Mar 19 02:03:57.504067 BGP RECV message type 1 (Open) length 59
Mar 19 02:03:57.504236 BGP SEND 10.222.1.2+57161 -> 10.222.1.5+179
Mar 19 02:03:57.504330 BGP SEND message type 4 (KeepAlive) length 19
Mar 19 02:03:57.507059 BGP RECV 10.222.1.5+179 -> 10.222.1.2+57161
Mar 19 02:03:57.507235 BGP RECV message type 4 (KeepAlive) length 19
Mar 19 02:03:57.512312 BGP SEND 10.222.1.2+57161 -> 10.222.1.5+179
Mar 19 02:03:57.512393 BGP SEND message type 2 (Update) length 83
Mar 19 02:03:57.512939 BGP SEND 10.222.1.2+57161 -> 10.222.1.5+179
---(more)---

Debugging BGP at R1
You then enable the traceoptions at R1 to debug BGP operations. You examine the trace log file for BGP message flow
between the two IBGP neighbors. The debugging shows that the neighbors follow the standard BGP session establishment
rules by exchanging with open messages, then keepalive messages, then update messages.

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

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R1-R4 IBGP Session

(5 of 10)

• R1 advertises routes to R4
user@Rl> show route advertising-protocol bgp 10.222.1.5

inet.O: 52 destinations, 53 routes (52 active, 0 holddown, 1 hidden)

Prefix Nexthop !--lED Lclpref .L_S path
• 0.0.0.0/0 Self 100 100 I
• 10.1.100.0/24 Self 100 100 I
10.1.101.0/24 Self 100 100 I
---(more)---

• But they never make it down to R4

user@R4> show route receive-protocol bgp 10.222.1.2

user@R4> show route hidden

user@R4> show route resolution unresolved

Tree Index 1

Check BGP Advertised Routes at R1

You use the show route advertising-protocol bgp neighbor command on R1 to determine what is being
advertised to R4. The command output shows that R1 advertises certain prefixes it received from the neighboring AS 100.

Check BGP Received Routes at R4

You use the show route receive-protocol bgp neighbor command on R4 to view the routes being received
from R1. The command output shows that R4 does not receive any routes. You check the hidden routes and the routes which
BGP next hop was not resolved but there are none.

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

Advanced Ju nos Enterprise Routing Troubleshooting

Troubleshooting R1·R4 IBGP Session

(6 of 10)
• Enable traceoptions at R4 and watch for BGP Update
messages coming in
• There are none
user@R4> show log bgp.log I match 11 BGP RECV message type 2"

Debugging BGP at R4
You proceed to debugging BGP at R4. You enable traceoptions to trace only BGP update messages. The trace log file lookup
does not show any received BGP update messages.

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

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R1·R4 IBGP Session

(7 of 10)

• Check the path the R1 Update messages take

user@Rl> traceroute 10.222.1.5 souice 10 .222 .1.2
traceroute to 10.222.1.5 (10.222.1.5) from 10.222.1.2, 30 hops max, 40 byte packets
1 10.222.0.6 (10.222.0.6) 2.113 ms 1.645 ms 1.784 ms
10.222.1.5 (10.222.1.5) 1. 7 62 ms 1.858 ms 1. 608 ms

• Check the TCP MSS for the session

user@Rl> show system connections inet extensive I find 10.222.1.5
tcp4 O 202 10.222.1.2.58691 10.222.1.5.179
ESTABLISHED

rttrnin: 10001 mss: 500

flags: REQ_SCALE RCVD SCALE REQ_TSTMP RCVD TSTMP SACK PERMIT [Oxl00003e0]
---(more)---

• Check the path MTU

user@Rl> ping 10.222.1.5 source 10.222.1.2 size 512 do-not-fragment
PING 10.222.1.5 110.222.1.5\: 512 data bvtes
36 bytes from 10.222.0.6: frag needed and DF set (MTU 128)1
Vr HL TOS Len ID Flg off TTL Pro cks Src Ost
5 00 021c 9ad2 2 0000 3f 01 974c 10.222.1.2 10.222.1.5
---(more)---

Check the Route from R1 to R4

You decide to inspect the hop-by-hop BGP update message propagation. You check the path the BGP messages take with
the traceroute command.

Check the TCP Parameters

Then you look up the TCP parameters of the IBGP session by using the show system connection extensive command. You
find out that Rl is using TCP MSS of 500 for this IBGP session.

Check the Path MTU

You test the end-to-end path MTU by generating ping requests with different payload sizes and do-not- fragment option
set. The test revealed that the next hop router (R3) has an interface MTU of 128 so it cannot transmit the larger packets
without fragmenting them.
Note that you rarely encounter the MTU of this size in a real network but the lab simulation is intended to show you the
generic approach to this kind of problem.

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

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R1·R4 IBGP Session

(8 of 10)

• The BGP update messages seem to be rejected by R4

• Is there any firewall filter?
user@R4> show interfaces ge-* detail I match "input filter''

user@R4> show interfaces loO. O detail I match "input filter 11

Input Filters: block-frags
I

Check for Firewall Filters

You then decide to thoroughly examine the firewall filters on the routers along the !GP path from R1 to R4. You find out that
R4 has a firewall filter applied to its loopback interface.

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

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R1-R4 IBGP Session

(9 of 10)

• The BGP Update messages seem to be rejected by R4

user@R4> show configuration firewall family inet filter block-frags
term 1 {
from
is-fragment;

then {
count fragrnencs;
discard;

term 2
then accept;

user@R4> show firewall

Filter: block-frags
Counters:
Name Bytes Packets
fragments 376755 2899

Examine the Firewall Filter

You examine the firewall filter and see that the filter rejects IP fragments.

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

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R1·R4 IBGP Session

(10 of 10)
• Collected data:
• BGP large packets (Updates) are fragmented due to low
MTU on the link between R4 and R5
• R4 firewall filter drops the fragments
• Solution:
• Enable BGP path MTU discovery or
• Make sure that MTU can always house the BGP negotiated
TCP MSS or
• Allow the fragments

Collected Information
You found out that the initial phase of the IBGP session between Rl and R4 is going flawlessly but then when Rl starts
advertising the BGP NLRls in BGP update messages, which are essentially bigger TCP packets, the R3 router on the way of
this messages fragments them due to low MTU on its link to R4. The firewall filter on R4 the drops the fragments.

Solution
You can either configure the BGP path MTU discovery option or set the IP MTU on all the links to a higher value to ensure that
the BGP packets will not be fragmented, or you can modify the firewall filter settings to accept the fragments.

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

 Advanced Junos Enterprise Routing Troubleshooting

Summary
• In this content, we:
• Listed common commands used to troubleshoot and verify
BGP
• Isolated different issues with BGP communication and
configuration

We Discussed:
Common commands used to troubleshoot and verify BGP; and
Isolating different issues with BGP communication and configuration.

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

Advanced Junos Enterprise Routing Troubleshooting

Review Questions

1. What are the default BGP route advertising rules?

2. How does using a route reflectors change the
default BGP route advertising rules?
3. Why can a mismatched MTU break an EBGP
session?
4. How to solve BGP next hop reachability problem?
5. When you issue a show bgp summary command,
what is indicated by the Active state?

Review Questions
1.

2.

3.

4.

5.

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

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting BGP Lab

• Monitor and troubleshoot the operation of a BGP
network.

Troubleshooting BGP Lab

The slide lists the objective for this lab.

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

Advanced Junos Enterprise Routing Troubleshooting

Answers to Review Questions

1.

By default BGP advertises all active BGP routes received from ll3GP peers to EBGP peers only, and all active BGP routes received
from EBGP peers ro both IBGP and EBGP peers.

2.

Route reflectors are allowed to advertise BGP routes learned from ll3GP peers ro other 113GP peers. Route reflectors advertise all
active I BGP routes received from clients to other clients and non-clients, and all active I BGP routes received from non-clients to
clients only.

3.
On directly connected EBGP sessions, TCP uses MTU-sized packets. If there is an MTU mismatch between the two sides of the TCP
connection, large BGP packets cannot be delivered, which tears the BGP session down.

4.
The valid ways to solve the BGP next-hop problem are: Next-hop-self policy; lGP passive interfaces; Export direct routes into IGP;
Static routes.

5.
The router is actively trying to form the BGP session.

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

Advanced Junos Enterprise Routing
Troubleshooting

Chapter 4: Policy Troubleshooting

Advanced Junos Enterprise Routing Troubleshooting

Objectives

• After successfully completing this content, you will be

able to:
• Isolate problems relating routing policy structure and
configuration
• Identify common commands for troubleshooting routing
policy

We Will Discuss:
Isolating problems relating routing policy structure and configuration; and
Identifying common commands for troubleshooting routing policy.

Chapter 4-2 • Policy Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Agenda: Policy Troubleshooting

7 Routing Policy Overview
• Routing Policy Structure
• Using Regex
• Routing Policy Troubleshooting
• Case Study

Routing Policy Overview

The slide lists the topics we will discuss. We discuss the highlighted topic first.

www.juniper.net Policy Troubleshooting • Chapter 4-3

Advanced Junos Enterprise Routing Troubleshooting

Routing Policy Overview (1 of 2)

• Flexible route processing capabilities
• Filter routing information entering or leaving the router
• Modify route attributes
• Policy is the method of route redistribution between routing
protocols
• You can use policies to control forwarding table entries
• Filtering routes exported to the forwarding table
• Per-flow load balancing
• CoS-based forwarding
• Policy is the key element in implementing Remote Triggered
Black Hole (RTBH)
• Provides an efficient way of mitigating Dos attacks at the network
edge

Policy Overview
Policy is a powerful tool that lets you manipulate routes you receive or advertise. Policy can change a router's default
decision process by changing route attributes or by filtering received or advertised routes. Policy is required to control the
routing information redistributed among routing protocols.

You can apply an export policy to routing table information installed in the forwarding table. Some Junos OS features such as
per-flow load balancing and CoS-based forwarding employ this routing policy application.

Another application that relies on routing policy is Remote Triggered Black Hole (RTBH). RTBH is a technique for the
mitigation of denial of service (DoS) attacks. RTBH is based on triggered BGP advertisement of a route, which has to be
blackholed, tagged with a specific community and matching on this community in an import policy, that sets the route next
hop to discard.

[edit policy-options]
user@srx# show
policy-statement black-hole-filter
from {
community rtbh;

then {
next-hop discard;

community rtbh members 100:666;

Chapter 4-4 • Policy Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Routing Policy Overview (2 of 2)

• Policy direction is relative to the routing table
• Import policy
• Applied to the routes received from routing protocols prior to
inclusion in the routing table
• Export policy
• Applied only to active routes in the routing table prior to sending to
routing protocols
• Applied to the routes installed to the forwarding table
Neighbors Import Export
j NeighborsI
Polley #1 ,------, Policy #1
Rollt....
es-·,--,----.i
Protocol Routing 1---+r-- -,.--::Routes
Protocol
Table

! Neighbors!

Policy Direction
All policy processing in the Junos operating system occurs with respect to the routing table. The import policies are applied to
the routes received from routing protocols prior to inclusion in the routing table.
The export policies are applied only to active routes in the routing table. The exception to this rule is the use of the
advertise-inactive option in BGP. This option allows policies to process the best BGP routes even if they are inactive.
You can also apply the export policies to the routes exported to the forwarding table.

www.juniper.net Policy Troubleshooting • Chapter 4-5

Advanced Junos Enterprise Routing Troubleshooting

Agenda: Policy Troubleshootin,g

• Routing Policy Overview
�Routing Policy Structure
• Using Regex
• Routing Policy Troubleshooting
• Case Study

Routing Policy Structure

The slide highlights the topic we discuss next.

Chapter 4-6 • Policy Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Routing PoH Structure (1 of 2)

• A policy consists of one or more terms

• Terms define conditions and actions
• Conditions are defined using the from or to clause
• Actions are proceeded with the then clause
• Terms are evaluated sequentially in the top down direction
• Terminating action in a matching term stops the processing
• A policy can have a single unnamed term
• It is always evaluated last in the terms sequential processing

Policy Structure: Part 1

The basic building block of a policy is a term containing a match and action pair. The from and to sections of the term
configuration make up the match criteria that a route must meet for the action to be taken. The then section of a term
defines an action or multiple actions to take on a route. It is possible to omit the from section in a policy term. When the
from is omitted all possible routes are considered to match the criteria and the specified action is taken.
You can use numerous match criteria in configuration of a policy term. For example, protocol, neighbor address, interface
name, as well as protocol specific information such as OSPF tag, IS-IS level, or BGP AS path, and many others.
You can define multiple match conditions in a single policy term. When multiple match conditions are defined within a term
the Junos OS evaluates all the criteria in a logical AND fashion.
A policy term actions fall into one of the following major categories:
Terminating action - accept or reject a route, halts the policy processing;
Flow control action - next term or next policy, alter the default policy processing;
Modifying action - change a route attributes.
You can define multiple actions in a policy term. The processing of the multiple actions occurs in the top-down fashion. Each
action is taken in turn and if appropriate, the next action is taken until all actions are completed. If you configure no action,
policy processing continues with the next term in the policy.

www.juniper.net Policy Troubleshooting • Chapter 4- 7

Advanced Junos Enterprise Routing Troubleshooting

Routing Policy Structure (2 of 2)

[edit policy-options policy-statement example-policy]
user@srx# show
term 1 {
from { tatic or direct
-­ riterion)
protocol static direct];

then accept;

term 2 {
from
protocol
level 2;

then accept;

from protocol bgp ; __-j The unnamed term

then reject;

Policy Structure: Part 2

You can configure a complex policy that contains multiple terms. The Junos OS evaluates a single multi-term policy in the
top-down fashion as they appear in the configuration. The evaluation begins with the first (topmost) term. The term is
checked for its match criteria. When a match occurs the associated action is taken. If no match exist in the first term the
Junos OS checks the second term, and so on. Note that whenever terminating actions are encountered the Junos OS does
not evaluate the terms that follow.
You can configure a single set of a policy from and then clauses without defining a term. This configuration is referred to as
the final action or unnamed term. Note that such unnamed term is always evaluated last in the terms list.
The code snippet on the slide shows an example of a multi-term policy.

Chapter 4-8 • Policy Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Routing Policy Processing

• You can apply multiple policies in a policy chain

• Evaluated sequentially in the left to right direction
• Terminating action in a matching term of a policy in the chain stops
the processing
• Default policy is always last in a chain
• Applied implicitly
• Protocol dependent
• Use the default-action statement to override the protocol
defaults
• Always completes with a conclusive action

Policy Processing
To solve a complex set of route manipulation tasks you can apply multiple policies to a single protocol application point. This
combination of multiple policies together is referred to as policy chain. The Junos OS evaluates policies in the chain from left
to right based on the order in which they are applied to a routing protocol. The Junos OS checks through each policy term
match criteria and performs the associated action when the match occurs. If the first policy does not match or if the match is
associated with a nonterminating action, the route is evaluated against the next policy in the chain. Policy chain processing
stops once a route meets a terminating action.
The Junos OS ultimately applies the default policy for a given protocol when no terminating actions occur while evaluating
the policy chain. Note that the default policy is different for different protocols. The default policy is always completes with a
conclusive action of either accept or reject. To override the default protocol policy action you can configure a statement
default-action [accept I reject] at any point within a policy.

www.juniper.net Policy Troubleshooting • Chapter 4-9

Advanced Junos Enterprise Routing Troubleshooting

Default Protocol Policies

• RIP
• Import: Accept all routes learned from neighbors
• Export: Reject all routes
• OSPF
• Import: Accept all routes from SPF
• Export: Reject all routes-information is advertised based on
the protocol's configuration
• IS-IS
• Import: Accept all routes from SPF
• Export: Accept the direct routes on the interfaces configured
in IS-IS. Reject all other routes
• BGP
• Import: Accept all routes learned from BGP neighbors
• Export: Send all routes learned from BGP neighbors to all
BGP neighbors. but only the active routes are exported

RIP Default Policies

The default import policy accepts all routes from RIP neighbors and the default export policy does not advertise anything.

OSPF Default Policies

The default import policy accepts all routes that result from SPF computation. You can apply an import policy only to process
the OSPF external routes. The default export policy is to reject all routes. This action is based on premise that OSPF natively
advertises direct routes by flooding router LSAs.

IS-IS Default Policies

The default import policy accepts all routes that result from SPF computation. You cannot apply import policies in IS-IS. The
default export policy is to accept the direct routes on the interfaces configured in IS-IS, and reject all other routes.

BGP Default Policies

The default import policy accepts all routes learned from BGP neighbors, both IBGP and EBGP. The default export policy
accepts all BGP-learned routes but only if the route is active. You can alter this behavior by configuring
advertise-inactive option.

Chapter 4-10 • P olicy Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Matching on Route Filters

• Binary tree evaluation

exact

upto prefix-length-range through

Matching on Route Filters

Use route filters as a match condition in a policy where the goal is to match a particular route or range of routes. Route filters
are defined as a prefix and a match type combination. The Junos OS performs a route filter evaluation by looking up in the
prefix binary tree. The slide shows a portion of the binary tree rooted at the 192.168.0.0/16 node.
The match types define the range of matching prefixes. The slide shows a summary of each of the route filter match types:
exact: Match the specified prefix and mask exactly. No other routes will be included;
or longer: Match the specified prefix and mask exactly. Also match any routes that start with the same prefix
and have longer masks;
longer: Do not match the specified prefix and mask exactly. Match only the routes that start with the same
prefix and have longer masks;
upto: Match the specified prefix and mask exactly. Also match any routes that start with the same prefix and
have a mask no longer than the second value specified;
through: Match the first specified prefix and mask exactly. Match the second specified prefix and mask
exactly. Match all prefixes directly between the two prefixes;
pref ix-length-range: Match only routes that start with the same prefix and have a mask between the two
values specified (inclusive match).
Continued on the next page.

www.juniper.net Policy Troubleshooting • Chapter 4-11

Advanced Junos Enterprise Routing Troubleshooting

Matching on Route Filters (contd.)

You can have multiple route filters in a single policy term. Only one of the route filters will be used as a match criterion in the
term. The Junos OS finds the route filter to be used by performing a longest match lookup. Once the longest match is found,
the Junos OS only evaluates that one route filter to determine a match for the policy term.
You can specify policy actions at the route-filter level in addition to the actions at the term level. When there is an action at
the route-filter level that action takes precedence and the term action is ignored. If the route-filter action is not specified the
Junos OS applies the term action.
[edit policy-options]
user@srx# show
policy-statement good-routes
term 1 {
from {
protocol ospf;
route-filter 192.168.18.0/24 exact reject;
route-filter 192.168.100.0/24 longer {
metric 10;
accept;

route-filter 192.168.0.0/16 orlonger;

then accept;

Chapter 4-12 • Policy Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Prefix L.ists
• Prefix lists notes
• Used as a policy match criterion
• prefix-list is a list of exact matches
• prefix-list-filter allows various match types
• Action applies to all matching prefixes
• Provide efficient way of reusing the code
• Configured under [edit policy-opt ions] hierarchy
fedit policy-options] [edit policy-options)
user@srx show user@srx show
prefiK-list rfc1918 policy-statement rejecc-rfc1918
10.0.0.0/8; from {
172.16.0.0/20; prefix-list-filter rfc1918 crlonger;
192.168.0.0/16;
then {
reject;

Prefix Lists
Prefix lists provide an efficient way of grouping prefixes to simplify policy creation and maintenance. A prefix list is a named
set of routes. You define a prefix list under the [edit policy-options] hierarchy. You can use prefix lists as a policy
match criterion. When a prefix list is referenced in a policy, the policy evaluates the routes in the list as a series of exact route
filter statements. A match on any one route within the prefix list causes the action specified in the then clause to be taken.
The Junos OS allows you to configure a prefix-list-filter as a policy match condition. In this case the policy evaluates the
routes in the list of route filters along with the specified match type.
You can use a prefix list in many policies. This allows you to simplify policy creation and modification by effectively reusing
the same piece of configuration and keep the routes of interest in a single place.

www.juniper.net Policy Troubleshooting • Chapter 4-13

Advanced Ju nos Enterprise Routing Troubleshooting

Agenda: Policy Troubleshooting

• Routing Policy Overview
• Routing Policy Structure
""?Using Regex
• Routing Policy Troubleshooting
• Case Study

Using Regex
The slide highlights the topic we discuss next.

Chapter 4-14 • Policy Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Using Regular Expressions

• Regex is a powerful pattern matching engine
• You can use Regex to match on AS Path or Community
variable patterns
• Take unary term[operator] or binary
term[operator]termform
• Term is either a complete AS number or a single character in a
community string or
• The wildcard dot .. _ .. character to represent any value
• Operator is an optional pattern matching character

Regular Expressions Overview

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 term operator. Note that the operator is an optional component and can be omitted, in
which case a regex takes a form of a fixed string.
You can use an AS path regex as a match condition in a policy, whereas a community regex not only can be used as a match
condition but also in the action part of a term to either set the community, add the community or delete the community.
The term meaning is different in AS path and community regular expressions. In AS path regular expression a term
represents a single AS number, whereas in community regular expression a term is a single character.
There are two steps to using the AS path or community in a policy. First, you define a named AS path or community regular
expression under the [edit pol icy-opt ions] hierarchy. Then you reference the AS path or community in the policy by
the assigned name.
Continued on the next page.

www.juniper.net Policy Troubleshooting • Chapter 4-15

Advanced Junos Enterprise Routing Troubleshooting
Regular Expressions Overview (contd.)
The following table shows the possible regular expression operators that you can use in AS path or community regex
definitions:

Regex Operators

{m,n} Match at least m and at most n repetitions of term

{m} Match exactly m repetitions of term
{m.} Match m or more repetitions of term
* Match O or more repetitions of term, same as {0,}
+ Match 1 or more repetitions of term, same as (1,)
? Match O or 1 repetitions of term, same as {0,1}

I Match one of the two terms on either side of the pipe

- Used to represent a range
" Anchor matching the beginning of regex
$ Anchor matching the end of regex

[) Match range or array of characters

(...). () Used to group term, or indicate null with no space

Chapter 4-16 • Policy Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Regex Examples (1 of 2)
• AS-Path regex examples
• "65001 . 65002"-This regex matches an AS Path with a length of 3 where
the first AS is 65001 and the last AS is 65002. The AS in the middle of the path
can be any single AS number
• "(65001165002) ?"-This regex matches an AS Path with a length of 1. The
AS in the path must be either 65001 or 65002
• "65001 . *"-This regex matches an AS Path with a length of at least 1. The
first AS number must be 65001. and it can be followed by any other AS number
any number of times or no AS numbers. This regex is often used to represent all
BGP routes from a particular neighboring AS network
• ". * 65001"-This regex matches an AS Path with a length of at least 1. The
last AS number must be 65001. and it can be preceded by any other AS number
any number of times or no AS numbers. This regex is often used to represent all
BGP routes that originated from a particular AS network
• "() "-This regex matches an AS Path with a length of 0. The null AS Path
represents all BGP routes native to your local Autonomous system

AS-Path Regex Examples

The slide shows some of the BGP AS-path specific regex expressions.

www.juniper.net Policy Troubleshooting • Chapter 4-17

Advanced Junos Enterprise Routing Troubleshooting

Regex Examples (2 of 2)

• Community regex examples

• "65001: . { 2, 3} "-This regex matches a community value where the AS
number is 65001. The community value is any two- or three-digit number
• "65001: 234?"-This regex matches a community value where the AS number
is 65001. The community value is either 23 or 234
• "6500 [123): 111"-This regex matches a community value where the AS
number is 65001. 65002, or 65003. The community value is 111
• "65001: . *"-This regex matches a community value where the AS number is
65001. The community value is any possible value
• "*: *"-This simple regex matches a community value with any possible AS
number and any possible value. This regex is often used to represent any
community

� ��,;i jl)niper Worldwide Education Services II www,un,pernet I 1B

�� ��£w� �;J... .•

Community Regex Examples

The slide shows some of the BGP community-specific regex expressions.

Chapter 4-18 • Policy Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Agenda: Policy Troubleshooting

• Routing Policy Overview
• Routing Policy Structure
• Using Regex
7Routing Policy Troubleshooting
• Case Study

f �20HJun,pe,Netwo"'5.lflc.AIILgMs,eser.ed
:r . :_,,.. ,, - ' j'
JUntPer
hi.,.....J
Worldwide Education Services ........,un,pe<nel I 19

Routing Policy Troubleshooting

The slide highlights the topic we discuss next.

www.juniper.net Policy Troubleshooting • Chapter 4-19

Advanced Junos Enterprise Routing Troubleshooting

General Policy Troubleshooting Steps

Check for aggregates

Check the export policies
Order. logic. application

Patil sanity clleck failed

Clleck for Martians, BGP next llop.
AS patll loop. cluster loop

Clleck tile import policies

Order. logic. application

Check the forwarding table export policies

General Policy Troubleshooting Steps

The purpose of the policy troubleshooting flowchart shown on the slide is to provide a set of high-level steps designed to get
you started with policy fault analysis.
Note that you do not necessarily follow the order of these troubleshooting steps. The steps shown on the slide use BGP as an
example of policy actions troubleshooting.
You begin with checking that the routes are being advertised. If you do not see the expected routes in the advertised routes
list, then may want to double check your export policies. Evaluate the policy logic, watch for correct term order or order of
policies in the policy chain. Try to deactivate policies to compare the results, use the test policy command.
Check the received routes. If you do not see the expected routes in the received routes list you might want to double check
your import policies. Use the same approach to examining the import policies as that of the export ones.
Finally if you find that the routes are in the routing table but the router fails to forward packets for the routes you may want to
examine the forwarding table entries. If a forwarding table policy is applied look at the policy configuration. Try to deactivate
and the activate the policy to compare the results.
You can use the policy trace utility by configuring traceoptions flag policy under [edit routing-options]
hierarchy, and using the then trace action in your policies to find out which terms are accepting or rejecting routes.
Remember to disable traceoptions once you finished debugging.

Chapter 4-20 • Policy Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Policy Troubleshooting Checklist (1. of 3)

• General policy usage guidelines
• Understand the Junos policy language
• Remember the actions associated with the protocol's
default policy
• Order is important
• Check the evaluation sequence
• Understand the expression logic in policy expressions
• Watch for unnamed terms in multi-term policies
• Term actions can mistakenly be configured there
• Keep it simple
• Chains versus multi-term policies
• Chains versus policy subroutines or expressions
• Avoid using complicated regex expressions

General Policy Design Guidelines: Part 1

The Junos OS policy language in some respects is similar to a programming language, policy processing is regulated by well
defined rules of logic. However the policy flexibility might become a source of confusion to network engineers. To efficiently
use the Junos OS policy framework and avoid the problems related to policy misconfiguration, follow the general policy
design and usage guidelines. You should clearly understand the Junos OS policy language to be able to configure error-free
policies and examine the configured policies. Remember the protocol default actions. Recall that the default policies are
always applied implicitly and evaluated last in a policy chain.
Order of operations is important when a policy is evaluated. Recall that policy terms are evaluated top-down whereas policies
in a policy chain are evaluated from left to right as they applied. If you add a new term to the existing policy the term is added
to the end of the policy. Use the insert command to move policy terms before or after other terms. If a multi-term policy
has an unnamed term, its actions are applied last. Watch out for unconditional unnamed terms. Generally you should avoid
using unnamed terms in multi-term policies. Route filters allow you to configure immediate actions. If a route filter produces
a match and it is configured with the immediate actions the algorithm uses these actions and skips the actions specified in
the then clause. Try to use a consistent approach in action definition.
Policy language provides multiple different ways to achieving your route manipulation goals. For instance, you can configure
a multi-term policy or use policy chain of some simpler policies. The individual policies can be reused in different places,
multi-term policies can be more convenient for specialized tasks. There is no single best approach, though as a rule of
thumb you should try to avoid overcomplicated policy structures.

www.juniper.net Policy Troubleshooting • Chapter 4-21

Advanced Junos Enterprise Routing Troubleshooting

Policy Troubleshooting Checklist (2 of 3)

• General policy usage guidelines

• Keep it tidy and orderly
• Use meaningful policy and term names
• Clean up unused policies
• Check the forwarding table policies
• May filter out valid routes
• Double check the filtering policies
• Verify the latest martians
• Check the RTBH Policies because they can blackhole valid routes
• Watch for well-known communities
• Affects route propagation

General Policy Design Guidelines: Part 2

Periodically clean up the configuration and only keep those policies that you use. Often network administrators configure
some temporary use policies for testing purposes and then forget to remove them. Use meaningful policy names to simplify
policy analysis.
Be careful with your forwarding table export policies. A mistakenly configured filtering action can become difficult to
troubleshoot because you cannot monitor the results of the policy in the routing table.
A good security policy on edge routers that face the Internet is to filter bogons. If you are using private address space inside
your private network, you don't want these addresses to leak out to the public Internet because traffic to or from these
prefixes should not be seen on the public Internet. Also, if your network receives bogons from the Internet, you want to ignore
them. Some common occurrences of bogons on the Internet include spoofed attacks, prefix hijacking, and simple
configuration mistakes.
Remote Triggered Black Hole (RTBH) is another example of filtering policy application. In RTBH a policy is applied that sets
next hop for certain routes to a bit bucket, i.e. the routes are blackholed. Double check your bogon filtering policies and
RTBH policies to ensure that the valid routes do not match the filtering policies conditions.
The well-known communities no-advertise, no-export, and no-export- subconf ed are intended to control route
propagation. The are very useful because they simplify policy administration but if configured and applied incorrectly the
communities can affect route distribution.

Chapter 4-22 • Policy Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Policy Troubleshooting Checklist (3 of 3)

• Use CLI test utility before applying a policy
• Only active routes in the routing table are evaluated
• Default protocol policies are not evaluated
• Default action of the test is accept

Policy Test Utility

The Junos OS provides the test policy command to see how a particular policy handles the prefixes in the routing table. The
test policy command only evaluates active routes in the routing table like a regular policy. Note that the command does not
support all match conditions and is mostly useful for checking policies that use route filters. Note that the default action of the
test policy command is accept. The command takes the following form:

user@srx> test policy reject-unwanted-routes 192.168/16

www.juniper.net Policy Troubleshooting • Chapter 4-23

Advanced Junos Enterprise Routing Troubleshooting

Usef I Policy Troubleshooting Commands

(1 of 7)

• Operational commands are protocol specific

• You want to check BGP received routes prior import
policy application
user@srx> show route receive-protocol bgp 10.1.254.1

inet.0: 61 destinations, 61 routes (53 active, 0 holddown, 8 hidden)

Prefix Nexthop MED Lclpref AS path
* 0.0.0.0/0 10.1.254.1 100 I
* 10.1.100.0/24 10.1.254.1 100 I
---(more)---

• BGP received routes filtered by import policy

user@srx> show route receive-protocol bgp 10 .1. 254 .1 hidden

ine�.O: 61 destinations, 61 routes (53 active, (1 holddown, 8 hidden)

Prefix Nexthop MED Lclpref AS path
10.3.100.0/24 10.1.254.1 100 300 I
10. 3 .101.0/24 10.1.254.1 100 300
---(more)---

Protocol Specific Commands

Because policies take effect on the routing protocols when the applied you use protocol specific commands to verify the policy
results.

Checking BGP Received Routes

Use the show route receive-protocol bgp neighbor command to display routes received by BGP from the
specified peer prior import policy processing.

Checking BGP Filtered Routes

Use the show route receive-protocol bgp neighbor hidden command to display routes filtered by import
policy.

Chapter 4-24 • Policy Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful Policy Troubleshooting Commands

(2 of 7)
• You want to check BGP routes in the routing table
after import policy processing
user@srx> show route protocol bgp source-gateway 10.1.254.1

0.0.0.0/0 •[BGP/170] ld 21:37:46, localpref 200

AS path: 100 I
> to 10.1.254.1 via ge- 0/0/4.303
10.1.100.0/24 *[BGP/170l ld 21:37:46, localpref 200
AS path: 100 I
> to 10.1.254.1 via ge-0/0/4.303
--- (more) ---

• BGP advertised routes after export policy application

user@srx> show route advertising-protocol bgp 10.1.254.1

inet.O: 63 destinations, 63 routes (SS active, O holddown, 8 hidden)

Prefix Nexthop MED Lclpref AS path
* 10.2.100.0/24 Self 200 I
* 10.2.101.0/24 Self 200 I
--- (more) ---

Checking Import Policy Action on BGP Routes

The show route protocol bgp command displays BGP routes in the routing table after import policy processing. The
BGP routes' attributes might have been modified by the import policy. The example command on the slide uses
source-gateway option. The option allows to view BGP routes received from a particular neighbor.

Checking Export Policy Action on BGP Routes

The show route advertising-protocol bgp neighbor command displays BGP routes that are prepared to get
advertised to the specified neighbor after they are processed by export policy.

www.juniper.net Policy Troubleshooting • Chapter 4-25

Advanced Junos Enterprise Routing Troubleshooting

Useful Policy Troubleshooting Commands

(3 of 7)

• You want to check OSPF external routes exported by

export policy
I use,:@srx> show osp£ database external
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum L;;�
Exte�n 20.20.0.0 10.222.1.3 Ox80000060 1758 Ox22 Ox2a23

�������������������������������-
Extern 20.20.1.0 10.222.1.3 Ox80000060 1647 Ox22 Oxlf2d 36
--- (more} ---
......

user@srx> show ospf route extern

Topc·logy default Route Table:

Prefix Path Route NH Metric Next Hop Next hop

Type Type Type Interface Address/LSF
20.20.0.0/24 Ext2 Network IP 2 ge-0/0/6.0 10.222.0.6
20.20.1.0/24 Ext2 Network IP 2 ge-0/0/6.0 10.222.0.6
---{nore)---

Checking OSPF Export Policy Action

Use the show ospf database external command to view the OSPF external LSAs in the LSDB. The show ospf
route extern command displays the SPF computed routes to the external subnets.

Chapter 4-26 • Policy Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful Policy Troubleshooting Commands

(4 of 7)

• You want to check OSPF external routes in the routing

table
user@srx> show route protocol ospf terse I match 110 150"
* 20.20.0.0/24 0 150 2 >10.222.0.6
• 20.20.1.0/24 o 150 2 >10.222.0.6
---(more)---

• IS-IS external routes exported by export policy

• Note: IS-IS does not differentiate between internals and
externals if wide metrics are configured
user@srx> show isis database router-4.00 detail I match external
IP prefix: 20.20.0.0/24 Metric: External Up
IP prefix: 20.20.1.0/24 Metric: 2 External Up
---{more)---

user@srx> show route protocol isis terse I match "I 165 °

20.20.0.0/24 I 165 12 >10.222.0.6
20.20.1.0/24 I 165 12 >10.222.0.6
---(more)---

Checking OSPF External Routes in the Routing Table

The show route protocol ospf command displays OSPF routes in the routing table. The example command on the
slide uses output filter to display OSPF routes that have preference value of 150.

Checking IS-IS Export Policy Action

Use the show isis database detail command to view the IS-IS external routes in IS-IS LSDB. The command show
route protocol isis displays IS-IS routes in the routing table. The example command on the slide uses output filter to
display I S I-S routes that have preference value of 160.
Recall that IS-IS does not differentiate between internal and external routes if wide metrics are configured.

www.juniper.net Policy Troubleshooting • Chapter 4-27

Advanced Junos Enterprise Routing Troubleshooting

Useful Policy Troubleshooting Commands

(5 of 7)

• You want to check routes in the forwarding table

user@srx> sh.ow route forwarding-table destination 10.1 100/24
Routing table: default.inet
Internet:
Destination Type RtRef Nex� hop Type Index NhRef Netif
10. 1.100. 0/24 user O 10.1.254.1 ucst 607 12 ge-0/0/4.303

• Use AS path regex filters in operational command to

filter results returned
• Find all BGP routes that traversed AS 50292 or AS 50293
user@srx> show route protocol bgp aspath-regex ••. * (50292 f 50293) . *"

inet.O: 65 descinations, 83 routes (65 active, Q hclddown, 0 hidden)

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

49.178.152.0/21 *[BGP/170) 00:13:17, localpref 100

AS path: 100 36024 50292 18566 I
> to 10.1.254.1 via ge-0/0/4.303

Viewing Routes in the Forwarding Table

Use the show route forwarding-table command to display routes in the forwarding table after forwarding table
export policy processing. The example command on the slide uses the destination filter to view a particular route in the
forwarding table.

Viewing Routes with AS Path Regex

The show route protocol bgp command can produce a long list of BGP routes in the routing table. Using various
filters allows to display only the routes of interest. The command on the slide uses an AS path regex based filter. The AS path
regex matches the routes with AS path containing AS numbers of 50292 or 50293 somewhere in the AS path.

Chapter 4-28 • Policy Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful Policy Troubleshooting Commands

(6 of 7)
• You want to use community Regex filters in
operational command output
user@srx> show route protocol bgp community ".*:[678)0"

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

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

200.200.0.0/16 *[BGP/170! 00:07:07, localpref 100

AS path: 100 I
> to 10.1.254.1 via ge-0/0/4.303

user@srx> show route 200.200/16 detail I match communities

CcITL�unities: 100:60 36024:70 50292:530

• View the list of all configured policies

user@srx> show policy
Configured policies:
aslOO-only
ebgp-export
ipv6-ebgp-export
ipv6-ebgp-import
nhs
---(more)---

Viewing Routes with Community Regex

The example command on the slide uses a community regex based filter. The community regex matches the routes having
the community AS number field of any value and the community number value of 60, 70, or 80.

Viewing the Configure Policies List

Use the show policy command to display a list of all configured policies.

www.juniper.net Policy Troubleshooting • Chapter 4-29

Advanced Junos Enterprise Routing Troubleshooting

Useful Policy Troubleshooting Commands

(7 of 7)
• You want to run a policy test
r@srx> test policy aslOO-only 10/8
���
l

AS path: 100 I
10.1.106.0/24 *[BGP/170] 02:17:06, localpref 200

> to 10.1.254.1 via ge-0/0/4.303

10.1.107.0/24 •[BGP/170] 02:17:06, localpref 200
AS path: 100 I
> to 10.1.254.1 via ge-0/0/4.303

Policy aslOO-only: 8 prefix accepted, 30 prefix rejected

Running a Policy Test

The test policy command tests the specified policy against the active routes in the routing table in the specified prefix
range.

Chapter 4-30 • Policy Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Agenda: Policy Troubleshooting

• Routing Policy Overview
• Routing Policy Structure
• Using Regex
• Routing Policy Troubleshooting
�Case Study

Case Study
The slide highlights the topic we discuss next.

www.juniper.net Policy Troubleshooting • Chapter 4-31

Advanced Junos Enterprise Routing Troubleshooting

Policy Case Study: Filtering Routes

• Topology, symptoms, and relevant information:
• While deploying BGP in the enterprise new branch office you implemented
several BGP routing policies to control precisely which routing information
your autonomous system will accept. Your goals were:
• Do not accept communities with any:777. any:888
• Replace all incoming communities with 65000:neighbor_AS
• Mark the received routes originated in AS other than neighboring AS with
no-export community
• Soon after the policies were applied testing revealed that none of the goals
is achieved

ISPA ISPB

AS 100 AS200

Worldwide Education Services �-juniper net I 32

��,t-a'!if�i�l::Jf11P€r
�-���J �74
.,;:
I

Policy Case Study: Filtering Routes

The slide presents a network topology, reported symptoms and description of a case related to import policy issues. In this
case study your company deployed BGP in a new branch office. You were asked to implement BGP routing policies to ensure
that only certain routes are received from the upstream ISPs. Your task is to ensure that you do not accept routes tagged
with the communities any:777 or any:888. Replace all other communities with a value of 65000:neighbor_AS. Mark the
received routes originated in an AS other than the neighboring AS with no- export community. When you activated the
configuration with the import policies applied for the first time you found that none of the tasks were accomplished.

Chapter 4-32 • Policy Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Import Policy Troubleshooting (1 of 8)

• Check the received routes for *:777 and *:888
communities
user@Rl> show route receive-protocol bgp 10.1.254.1 community "*: (777) I (888) 11

inet.O: 65 destinations, 82 routes {65 active, 0 holddcwn, 0 hidden)

Prefix Next.hop MED Lclpref AS path
* 10.1.106.0/24 10.1.254.1 100 100 100 I
* 10.1.107.0/24 10.1.254.1 100 100 100 I

• Check the routes in the routing table

user@Rl> show route protocol bgp community "*: (777) I (888)"

A Destination P Prf Metric 1 Metric 2 Next hop AS path

• 10.1.106.0/24 B 170 100 >10.1.254.l 100 100 100 I
* 10.1.107.0/24 B 170 100 >10.1.254.1 100 100 100 I

Check the BGP Received Routes

You begin with checking the BGP routes received from the ISPs. You use the show route receive-protocol bgp
neighbor command with the community regex to filter the output on the routes of interest. The command output shows
that the routes are being received.

Check the Routes in the Routing Table

You check the routes in the routing table and find out that the routes are there.

www.juniper.net Policy Troubleshooting • Chapter 4-33

Advanced Junos Enterprise Routing Troubleshooting

Import Policy Troubleshooting (2 of 6)

• Check that all received routes are marked with
65000:100 community
• None is marked
I user@Rl> show route protocol bgp source-gateway 10.1.254.1 comm.uni.ty-narne a.slOO-comm
I

• Check the no-export community

• All EBGP routes appear to have no-export attached
user@Rl> show route protocol bgp community-name no-export terse

A Dest.ination p Prf Metric 1 Metric 2 Next hep AS pa,:h

* 0.0.0.0/0 B 170 100 >10.1.254.1 100 I
* 10.1.100.0/24 B 170 100 >10.1.254.1 100 100 100 I
I
* 10.1.101. 0/24 B 170 100 >10.1.254.1 100 100 100 I
---{more)---

Check the Received Routes Community

You proceed to inspecting the received routes to ensure that they are tagged with the specified community. You use the
show route protocol bgp command with the community-name filter. The output of the command does not show
any routes.

Check the Received Routes with No-Export Community

You keep inspecting the received routes' communities. Now you look up routes that have no-export community attached.
The output indicates that all routes received from the ISPs have the no-export community attached.

Chapter 4-34 • Policy Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Import Policy Troubleshooting (3 of 8)

• And what is in the configuration?

user@Rl> show configuration policy-options policy-statement ent-i.mport-fi1ter
term 1 {
from community drop-comm;
then reject;

term 2 {
from as-pat� aslOO;
then {
communi�y set aslOO-comm;

term 3
then
community set no-export;

user@Rl> show configuration policy-options I match "'"'community"

co��unity aslOO-comm members 65000:100;
community drop-comm members [ •:777 *:888 J;
community no-export members no-export;

Check the Import Policy

You decide to check the import policy configuration. You first check BGP configuration and find that an import policy named
ent-import-f il ter is applied to the EBGP peer group. You then examine the policy configuration. The policy has three
terms. The first term matches the community regex named drop-comm and rejects the routes. The second term matches
AS path regex named asl 00 and sets a new community called asl 00-comm. The third term is the unconditional term that
sets a community called no-export.

www.juniper.net Policy Troubleshooting • Chapter 4-35

Advanced Junos Enterprise Routing Troubleshooting

Import Policy Troubleshooting (4 of 6)

• Step-by-step analysis of the import policy
• Term 1 demonstrates a common mistake of community
members logical AND for logical OR
• Term 2 replaces all communities only for ISP A originated
routes with 65000:100. The term does not have a
terminating action, which passes processing to the next
term
• Term 3 overwrites all previously set communities on all
routes with a new community no-export

Import Policy Analysis

This slide outlines the import policy errors.

Chapter 4-36 • Policy Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Import Policy Troubleshooting (5 of 6)

• Modify the import policy to accomplish the tasks

user@Rl> show configuration policy-options policy-statement ent-import-filter
term 1 {
from community [ drop-conun-1 drop-comru-2 ];
then reject;

term 2 {
from as-path aslOO;
then {
communi�y set aslOO-comm;
accept;

term 3
then {
cornmuni�y set no-export;
communi�y add aslOO-comm;

user@Rl> show configuration policy-options I match 11 "'com.?O.unity 1•

community drop-comrn-1 me..Wers ""': 777;
community drop-comm-2 members *:888;

Modify the Import Policy Settings

You proceed to modifying the import policy settings. The revised policy is illustrated on the slide.

www.juniper.net Policy Troubleshooting • Chapter 4-37

Advanced Junos Enterprise Routing Troubleshooting

Import Policy Troubleshooting (6 of 6)

• Final checks
• Routes get filtered
user@Rl> show route protocol bgp source-gateway 10.1.254.1 hidden terse

A Destination P Prf Metric 1 Metric 2 Next hop AS path

lD.1.106.0/24 B 100 >10.1.254.1 100 100 100 I
,,___1_0.__ 1_.1 _ ._ _o_J_z_4_______
_ 0_ 7 10
B_____________ >1
_ 0_ _____________ _ _0_. _1_.2_s4.1
__ _ ________10 _ �1�
_ __1_o0
_ 0 00 I

• Routes are marked properly

user@Rl> show route 10 .1 .100/24 detail I match " (communities) I (as path)"
AS path: 100 100 100 I
Communities: 65000:10 0

user@Rl> show route 10. 3. 100/24 detail I match 11 (communities) I (as path) u
AS path: 100 300 I
Communities: 65000:100 no-export

Final Checks
You repeat you verification of the route received from the ISPs. You first check the hidden routes and discover that the BGP
routes tagged with communities *:777 or *:888 are successfully filtered out. Then you check that all received routes are
tagged with community 65000:100. The output confirms this tagging. Finally, you check that the received routes originated
in an AS other than the neighboring AS. The output confirms this as well.

Chapter 4-38 • Policy Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Summary
• In this content, we:
• Isolated problems relating routing policy structure and
configuration
• Identified common commands used for troubleshooting
routing policy

We Discussed:
Isolating problems relating routing policy structure and configuration; and
Identifying common commands used for troubleshooting routing policy.

www.juniper.net Policy Troubleshooting • Chapter 4-39

Advanced Junos Enterprise Routing Troubleshooting

Review Questions
1. If you want to redistribute OSPF routes to BGP, what
kind of policy should you use: import or export, and
which protocol should you apply this policy to?
2. Which routes match the route-filter 192.168.0.0/16
upto /18?
3. What does the "?" character mean in AS-path
regular expressions?
4. How can you test a policy against all the entries in
the routing table?
5. How can you test the results of your BGP export
policy?

Review Questions
1.

2.

3.

4.

5.

Chapter 4-40 • Policy Troubleshooting www.juniper.net

 Advanced Ju nos Enterprise Routing Troubleshooting

Troubleshooting Routing Policy Lab

• Monitor and troubleshoot the IGP and BGP Routing

policy issues.

Troubleshooting Routing Policy Lab

The slide lists the objective for the lab.

www.juniper.net Policy Troubleshooting • Chapter 4-41

Advanced Junos Enterprise Routing Troubleshooting

Answers to Review Questions

1.

You should apply an export policy matching and accepting OSPF routes to protocol BGL�

2.

The routes in the following list match: 192.168.0.0/16, 192.168.0.0/17, 192.168.128/17, 192.168.0.0/18, 192.168.64.0/18,
192.168.128.0/18, and 192.168.192.0/18.
3.
The"?" character is the rcgex operator that matches O or 1 occurrence of an AS number in an AS path.

4.

You use the test policy policy-name O. 0. 0. 0/0 command to test the policy against all the entries in the routing table.

5.
You use the show route advertising-protocol bgp neighbor command to display the routes after export policy
processing.

Chapter 4-42 • Policy Troubleshooting www.juniper.net

Advanced Junos Enterprise Routing
Troubleshooting

Chapter 5: Troubleshooting Advanced Features

Advanced Junos Enterprise Routing Troubleshooting

Objectives

• After successfully completing this content, you will be

able to:
• Verify and troubleshoot multicast
• Verify and troubleshoot Cos

We Will Discuss:
Verifying and troubleshooting multicast; and
Verifying and troubleshooting Class of Service (CoS).

Chapter 5-2 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Agenda:
Troubleshooting Advanced Features

7Multicast Troubleshooting
• Multicast Case Study
• Cos Troubleshooting
• Cos Case Study

Multicast Troubleshooting
The slide lists the topics we will discuss. We discuss the highlighted topic first.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-3

Advanced Junos Enterprise Routing Troubleshooting

Multicast Overview (1. of 2)

• What is multicast?
• One-to-many network-wide delivery to interested receivers
only
• Multicast components:
• Source
• Unicast source address (S,)
• Receivers
• Multicast group address (.G)
• Network
• Multicast-enabled routers running multicast routing protocols
• Forwarding is based on incoming interface and outgoing interface
list

What Is Multicast?
Multicast defines the concept of a one-to-many communications stream. Unlike broadcast traffic that is not forwarded by
routers multicast can operate network-wide. The network is responsible for replicating the data and delivering it only to
listeners that have expressed their interest. Links that connect to uninterested listeners do not carry the traffic. This method
provides efficient use of resources because traffic flows only through links that connect to end hosts that want to receive the
data.

Multicast Components
A multicast source is any device that originates multicast IP packets. In multicast distribution source is associated with a
unicast address.
Multicast packet is a packet with multicast destination address. All multicast 1Pv4 addresses fall in the range of 224.0.0.0
through 239.255.255.255. Multicast addresses do not have a mask length associated with them for forwarding purposes. A
multicast address is also called a multicast group address.
Because there can be multiple receivers, the path that multicast packets take may have several branches. A multicast data
path is known as a distribution tree. Multicast traffic flows through the distribution tree in the downstream direction.
Multicast-enabled routers keep track of the incoming and outgoing interfaces for each group, which is known as multicast
forwarding state.

Chapter 5-4 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Multicast Overview (2 of 2)

• Service model
• Any Source Multicast (ASM)
• Source discovery is a function of the network
• Source Specific Multicast (SSM)
• Out-of-band Source discovery

Multicast Service Model

There are two multicast service models, Any-source multicast (ASM) and Source-specific multicast (SSM).
ASM is the model where receivers join a group without specifying from which source they want to receive traffic, so they
accept it from any source. In ASM model the network is responsible for source discovery. The mechanisms of source
discovery contribute the majority of the complexity of ASM distribution model. ASM supports both one-to-many applications
like Internet Protocol Television (IPTV), as well as many-to-many applications like videoconferencing.
In SSM, the receiver specifies the sources from which it wants to receive the traffic. SSM eliminates the need for network
source discovery, so simplifies the mechanisms needed to deliver multicast. The source discovery becomes an application
function.
SSM makes deployment of multicast less complex and also makes allocating multicast addresses easier. SSM supports only
one-to-many applications.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-5

Advanced Junos Enterprise Routing Troubleshooting

Multicast Routing (1 of 4)

• IGMP
• Network edge, host subscription management
• Version 1, Version 2 (default) - ASM only
• Version 3 is mandatory in SSM model, supports ASM
• Backward compatible with IGMPv1, IGMPv2
• MLD
• 1Pv6 equivalent of IGMP
• MLD version 1. similar to IGMPv2
• MLD version 2, similar to IGMPv3
• A sub-protocol of ICMPv6

IGMP Protocol
Hosts use the Internet Group Membership Protocol (IGMP) to inform routers about which multicast groups they want to join,
and routers use IGMP to verify that a host is still interested in listening to a group. There are three versions of IGMP, all
supported by the Junos OS:
IGMP Version 1 is the original IGMP version. In IGMPv1 if a host wants to leave a group it stops sending report
messages, and after some time, the router assumes the host is no longer interested in the group and stops
forwarding traffic for that group.
IGMP Version 2 (default) adds explicit leave functionality so hosts can report to the router when they are no
longer interested in a group.
IGMP Version 3 adds source filtering so the host can include and exclude specific sources when requesting
multicast packets. Source filtering is required for SSM.
Note that IGMPv1 and IGMPv2 support only ASM model, whereas IGMPv3 supports both ASM and SSM models.
IGMPv3 is backward compatible with earlier IGMP versions. In general, a mix of IGMP versions among hosts on a LAN is
permissible, while a mix of IGMP versions among routers on a LAN is not recommended.
Continued on the next page.

Chapter 5-6 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

MLD Protocol
MLD is the equivalent 1Pv6 protocol for 1Pv4's IGMP. It is used between routers and hosts to signal interest in receiving
specific 1Pv6 multicast sessions.
MLD is a sub-function of the ICMPv6 protocol. Its messages are carried inside ICMPv6, and the next-header value is 58. The
source address for MLD is always a link-local 1Pv6 source address. The MLD packet has a time to live (TIL) of 1 and includes
an 1Pv6 router alert header.

www.juniper.net Troubleshooting Advanced Features • Chapter 5- 7

Advanced Junos Enterprise Routing Troubleshooting

Multicast Routing (2 of 4)

• PIM
• Ensures loop-free forwarding
• RPF check (looks in the inet. O table (default) or in the inet. 2
table)
• Management of distribution trees
• Shortest path tree (SPT)
• Shared or rendezvous point tree (RPT)
• Maintains event-driven, dynamic routes
• Tuples of (S.G) for SPT or (*.G) for RPT
• Stored in the inet. 1 routing table

PIM Protocol
Reverse path forwarding (RPF) is a central concept in multicast routing. Routers set up forwarding state in the opposite
direction of unicast, from receiver to the root of the distribution tree. Routers perform the RPF check to determine the
interface that is topologically closest to the root of the tree. The RPF interface becomes the incoming interface for the group.
By default, the Junos OS uses the inet. o routing table for the RPF check. Thus, the unicast topology and multicast topology
are identical. If you must have a separate topology for multicast forwarding, you can achieve this by changing the table the
RPF check uses. In the Junos OS, the inet. 2 table is reserved for this purpose.
Continued on the next page.

Chapter 5-8 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

PIM Protocol (contd.)

The inet.2 table must be populated with routing information to build the alternate topology used by the RPF check.You
can configure unicast routing protocols like OSPF or BGP to install the routes in the inet. o, inet. 2, or both tables. To use
the inet.2 table, PIM and the other multicast protocols must be configured explicitly. These configurations are based on
the concept of RIB groups. RIB group is a reference to one or several software-defined routing tables.
[edit routing -options]
user@router# show
rib-groups {
ospf-to-both-tables
import -rib [inet.0 inet. 2];

inet2 -rpf
import-rib inet.2;

The RPF check is performed in respect to the root of the distribution tree.There are two types of the multicast distribution
trees: Shortest path tree (SPT) and rendezvous point tree (RPT) also referred to as shared tree.In a shortest path tree (SPT),
the root of the distribution tree is the source. In a shared tree, the root of the distribution tree is a special router somewhere
in the core of a network. This core router is called a rendezvous point (RP). Routers built the RPT when source for a given
group is not known.
In contrast to unicast routing multicast routing is largely event-driven. For example, a join message is generated when a
router wishes to receive multicast traffic for a given group.As a result of this join, a multicast distribution tree is instantiated,
which adds the interface on which the join was received in the outgoing interface list for that group. After some period of
time, lack of continued join activity results in this state timing out, the removal of the distribution tree and the removal of the
interface from the outgoing interface list. In unicast routing, the absence or presence of a route is not a function of an actual
need to use the route, in contrast, a multicast route is a dynamic entry that is based on the presence of an active sender and
at least one interested receiver.
Routers keep the multicast routes or forwarding states in terms of (S,G) and (*,G) state.The "S" refers to the unicast IP
address of the source, the 'G' represents the specific multicast group IP address.The"*' is a wild card used to denote any
source sending to group G. These multicast forwarding states are cached in the inet. 1 routing table.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-9

Advanced Junos Enterprise Routing Troubleshooting

Multicast Routing (3 of 4)

• PIM
• Dense distribution mode
• Flood and prune
• Prune signals no interest in receiving multicast traffic
• Graft overrides previous prune messages
• Sparse distribution mode
• Explicit subscriptions only
• Join signals interest in receiving multicast
• Prune sent to unsubscribe from multicast traffic
• RP is required for source discovery in ASM model

PIM Protocol -Dense and Sparse Modes

PIM supports two multicast distribution modes, dense mode and sparse mode.
In dense mode (PIM-OM), traffic is forwarded to all parts of the network, which is known as flooding. The parts of the network
that are not interested in receiving the traffic send prune messages to their neighboring routers asking them to stop
forwarding traffic. In case a receiver subscribes after sending the prune, the router sends a graft message asking for the
traffic to be forwarded again.
In sparse mode (PIM-SM), traffic is forwarded only into parts of the network with interested receivers. The routers send join
messages to a core router known as the RP in the ASM model or directly to the source in the SSM model to indicate their
willingness to receive traffic. If a receiver is no longer interested, the router sends prune messages asking it to stop
forwarding the traffic.
The main complication with PIM-SM in ASM model is that at least one RP router is required. The RP is the router that is aware
of the active sources. The edge routers of a multicast domain that receive multicast traffic from the multicast sources
register these source at the RP with PIM register messages.
PIM-SM has three ways of discovering the RP:
Statically configured RP;
Auto-RP protocol;
Bootstrap protocol (BSR).
Note that you can enable PIM to use the mixed sparse-dense mode.

Chapter 5-10 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Multicast Routing (4 of 4)

• MSDP
• Communicates information about active sources
• lnterdomain multicast
• Anycast-RP application
• Typically runs on PIM-SM RP routers
• MSDP sets up peer relationships using TCP
• Not included in 1Pv6 multicast stack of protocols

MSDP Protocol
MSDP shares multicast source information between RPs so that sources and receivers can meet, even if they have
associated with different RPs. MSDP-speaking routers form peer relationships, similar to BGP peers, over a TCP connection.
MSDP uses TCP port 639. Two MSDP peers can be in the same PIM-SM domain or in two separate domains.
Within a domain, MSDP enables creation of multiple RPs, facilitating redundancy and load balancing. Anycast RP is the
primary example of intradomain MSDP. The concept of Anycast RP, 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.
Between different domains, MSDP enables RPs to exchange source information from their respective domains, allowing
interdomain source discovery to occur.
MSDP is abandoned in 1Pv6 multicast because it does not scale well enough. Instead two different approaches are used in
intradomain Anycast RP and interdomain multicast.
The Anycast RP in 1Pv6 is based on PIM-Anycast concept. In PIM-Anycast RPs forward PIM register messages they receive
from source aware routers to the other RPs that are explicitly configured in RP-set. Note that you can use this technique with
1Pv4 multicast as well.
To allow interdomain 1Pv6 muticast using the ASM model, the embedded RP solution was developed. The domain owning the
multicast address provides the RP information as part of the complete 1Pv6 group address.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-11

Advanced Junos Enterprise Routing Troubleshooting

Generic Multicast ASM Network (1 of 2)

• Rendezvous point distribution tree

Source S1..G1

R3 R5

LAN 1

IGMPReport
(*.Gi)

Receiver Gl Receiver Gl Receiver G2 Receiver G2

RPT in a PIM-SM ASM Network

This slide shows the initial state of multicast distribution trees in the PIM-SM ASM model. The interested receivers express
their interest in multicast groups G1 and G2 by generating unsolicited IGMPv2 report messages. The LAN designated routers
(DRs) join the RPT by sending PIM join messages out of the RPF interface upstream to the RP. The source-faced DRs
advertise the active sources by sending PIM register messages to the unicast address of the RP. The result of these
exchanges is instantiation of the RPTs.

Chapter 5-12 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Generic Multicast ASM Network (2 of 2)

• Shortest path distribution tree

Source Si,G1 Source S2,G2

R3 R5

IGMP Repo,i IGMPReport

(*,G1) (",G2)

Receiver Gi Receiver Gi Receiver G2 Receiver G2

SPT in a PIM-SM ASM Network

This slide shows the SPT phase of multicast distribution trees in the PIM-SM ASM modeL When the multicast traffic reaches
the LAN DRs the DRs discover the source information. They join the SPT by sending PIM join message out of the RPF
interface upstream to the source. They then send PIM prune message, pruning the (S,G) state out of the RPF interfaces
upstream to the RP. The result of these exchanges is instantiation of the SPTs.
Note that you can configure the PIM routers to not switch over to the SPT and keep using the RPT.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-13

Advanced Junos Enterprise Routing Troubleshooting

Multicast Troubleshooting Checklist (1 of 2)

• General multicast troubleshooting checklist

• Watch out for RPF failures
• RPF is used both at multicast control and data planes
• PIM and network topology inconsistency
• Check that RP information is propagated
• BSR or mapping agents collect the RP announcements
• Bootstrap: RPs learn of the BSR. BSR receives the RP
announcements
• Auto-RP: Auto-RP groups are allowed to flood. MA receives the RP
announcements
• Other routers get the RP mapping
• Source DRs can reach the RPs using unicast routing

Multicast Troubleshooting-Part 1
The most common type of multicast issue is the RPF failure. RPF checks are used both at the control and data plane of
multicast routing. Control plane involves PIM signaling-some PIM messages are subject to RPF checks. For example, PIM
(*,G) joins are sent toward the shortest path to RP, and PIM (S,G) joins are sent toward the shortest path to the source. Next,
the BSR/RP address in the BSR messages is subject to RPF check as well.
Data plane RPF checks are performed every time a multicast data packet is received. The source IP address in the packet
should be reachable through the incoming interface.
One common reason for many issues with multicast routing is the PIM and IGP topology inconsistency. Multicast normally
should be deployed in a single IGP domain with PIM enabled on all links running the IGP. Note that PIM is also required on
the multicast source facing interfaces and the receiver LAN interfaces.
In the Junos OS, IGMPv2 is automatically enabled on the interfaces configured in PIM.
In PIM-SM ASM network distribution of RP information is critical to overall multicast routing.
If BSR RP distribution method is used you need to ensure a Bootstrap router is configured and the other routers aware of its
presence. Check that the Bootstrap router collects and distributes the RP information. Check that other routers receive this
information.
Continued on the next page.

Chapter 5-14 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Multicast Troubleshooting-Part 1 (contd.)

If Auto-RP protocol is used recall that Auto-RP messages are distributed in multicast dense mode to the group addresses of
224.0.1.39 (announce messages) and 224.0.1.40 (discovery messages). Hence, you have to enable sparse-dense mode on
all PIM interfaces across the domain and explicitly define the Auto-RP groups as dense groups on all the routers. Check that
Auto-RP mapping agent collects and distributes the RP information. Check that other routers receive this information.
Recall that source DRs advertise the active sources in PIM register messages that they send to a unicast address of the
learned RP. Check that the source DRs can reach this unicast address.

www.juniper.net Troubleshooting Advanced Features • Chapter 5�15

Advanced Junos Enterprise Routing Troubleshooting

Multicast Troubleshooting Checklist (2 of 2)

• General multicast troubleshooting checklist

• In Anycast RP, verify the RP's exchange of active source
information
• MSDP
• RP-set
• Watch for ASM operation attempts in SSM-only range
• Watch for filtering actions in multicast routing policies
• Watch for security policies blocking control plane messages
or multicast data packets
• Check for multicast scoping

Multicast Troubleshooting-Part 2
In Anycast RP domain make sure that the RPs advertise the active sources they learned from the source DRs to the other
RPs. There are two methods that are used to exchange with the active source messages: MSDP protocol, and configuration
of RP set in PIM on the RPs, which allows the RPs to forward PIM register messages to the other RPs in the set.
If MSDP is used, check that MSDP session is established between the RPs. If the session is established, check that the RPs
generate the source active(SA) messages and these messages are received and not filtered by the other RPs. MSDP allows
you to configure SA message limits. Ensure that theses limits are not exceeded.
Recall that the multicast range of 232.0.0.0/8 is reserved for SSM operations. By default, receiver DRs do not accept(* ,G)
IGMP reports. Recall that IGMPv3 is required for SSM operations. Source DRs do not send PIM register messages for the
groups in SSM range. Should RPs receive the register message for a group in SSM range, it ignores it. All PIM routers do not
send PIM join messages and ignore PIM joins for a group in SSM range. You can override this default behavior in the Junos
configuration.
The Junos OS allows you to apply routing policies to control various multicast protocol messages. Check that the policies do
not prevent normal protocol message flows.
Make sure that your security policies or firewall filters allow both the multicast protocol messages and multicast data
packets.
You can configure multicast scoping to control multicast data traffic distribution. An incorrectly configured multicast scope
will block multicast data on the interfaces where the scope is applied.

Chapter 5-16 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful IWulticast Commands (1 of 10)

• Check that IGMP is operational

user@srx> show igmp inteiface

Interface: ge-0/0/13.0
Querier: 10.222.2.2
State: Up Timeout: None Version: 2 Groups:
Immediate leave: Off
Promiscuous mode: Off
Passive: Off

Configured Par��eters:
IGMP Query Interval: 125.0
IGMP Query Response Interval: 10.0
--- {more) ---

user@srx> show igmp statistics

IGMP packet statistics for all interfaces
IGMP Message type Received Sent Rx errors
Membership Query 152 149
Vl Membership Report 0 0
DVMRP 7 0 0
PIM Vl 0 0
---(moi:e)---

Checking IGMP Operational State

Use the show igmp intei:face command to display a list of interfaces running IGMP and the number of groups currently
active. This command also shows the IGMP timer parameters.
The show igmp statistics command display counters for IGMP messages. This command is useful in verifying that
IGMP messages are being sent and received.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-17

Advanced Junos Enterprise Routing Troubleshooting

Useful Multicast Commands (2 of 10)

• Check the IGMP subscriptions

user@srx> show igmp group
Interface: ge-0/0/13.0, Groups:
Group: 2 2. 4 . 7 . 7 . 7
Source: 0.0.0.0
Last rep:,rted by: 10.222.2.3
Timeout: 152 Type: Dynamic
Group: 239.1.1.1
Source: 0.0.0.0
Last reported by: Local
Timeout: O T�lpe: Static
--- (mere) ---

Checking IGMP Subscriptions

Use the show igmp group command to display the groups joined by directly connected hosts. The example on the slide
shows two (*,G) reports for the groups 224.7.7.7 and 239.1.1.1. The second group was configured statically on the interface
ge-0/0/13.0.
Note that if you explicitly enable IGMP on an interface but fail to enable PIM on this interface the IGMP interface status
shows the up state but the interface is omitted from the output of the show igmp group command.

Chapter 5-18 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful Multicast Commands (3 of 10)

• Check that PIM is operational

user@srx> show p.i.m interfaces
Instance: PIM.master

Name Stat Mode lP v St.ate NbrCnt JoinCnt(sg/*g) DR address

aeO.O Up SD 4 2 NotDR,NotCap 1 2/1 10.222.0.2
ge-0/0/4.301 Up SD 4 NotDR,NotCap 1/0 10.222.0.10
ge-0/0/6.0 Up SD 4 2 NotDR,NotCap 0/0 10.222.0.6
---(more)---

user@srx> show pim statistics

PIM Message type Received Sent Rx er.rors

vz Hello 3468 7551 0
V2 Register 19 0 0
vz Register Stop 0 18 0
--- (more) ---

Checking PIM Operational State

Use the show pim interface command to display a list of interfaces running PIM. This command shows interface PIM
mode, PIM version (PIMv2 is the default one), as well as PIM neighbor count, and the number of PIM join messages received.
In the example on the slide, the aeO.O interface is enabled for PIMv2 sparse-dense mode. It is not DR and does not support
bidirectional PIM.
The show igmp statistics command display counters for IGMP messages. This command is useful in verifying that
IGMP messages are being sent and received.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-19

Advanced Junos Enterprise Routing Troubleshooting

Useful Multicast Commands (4 of 10)

• Check PIM neighborhood

user@srx> show pim neighbors
Instance: PIM.master

Interface IP v Mode Ope ion Uptime Neighbor addr

aeO.O 2 HPLGT 01:57:21 10.222.0.2
ge-0/0/4.301 HPLGT 00:06:30 10.222.0.10
ge-0/0/6.0 2 HPLGT 01:49:53 10.222.0.6

• Check multicast RPF for an address

useI@srx> show multicast rpf 10.222.3.2
Mul�icast RPF table: inet.O , 69 entries

10.222.3.0/24
Protocol: OSPF
Inteiface: ge-0/0/4.301
Neighbor: 10.222.0.10

Checking PIM Neighborhood

Use the show pim neighbors command to display the discovered PIM neighbors and the options supported for each
interface. The options indicate the neighbor capabilities:
B-Bidirectional capable;
G-Generation identifier;
H-Hello option holdtime;
L-Hello option LAN prune delay; and
P-Hello option DR priority.
In PIM-SM, the output of the show pim neighbors detail command also includes information about the PIM join
messages received from specific neighbors.

Checking RPF Routes

Use the show multi cast rpf command to check the RPF result for a specified address.

Chapter 5-20 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful Multicast Commands (5 of 10)

• Check multicast distribution tree state (Join/Prune)

user@srx> show pim join 239.1.1.1 detail

Instance: PIM.master Family: INET
R ; Rendezvous Point Tree, S ; Sparse, W Wildcard

Group: 239.1.1.1
Source: *
RP: 10.222.1.3
Fla.gs: sparse,rptree 1 wildcard
Upstrearn interface: aeO. 0
Downstream neighbors:
Interface: ge-0/0/6.0

Group: 239.1.1.1
Source: 10.222.3.2
Flags: sparse,spt
Upstream int.erface: ge-0/0/4.301
Downstream neighbors:
Interface: ge-0/0/6.D

Checking PIM Join/Prune State

The show pim join command displays the join state for both RPT and SPT. Adding the detail option results in
displaying incoming interface and outgoing interface information. Entries with an asterisk(*) as the source address indicate
a RPT join.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-21

Advanced Junos Enterprise Routing Troubleshooting

Useful Multicast Commands (6 of 10)

• Check multicast route information

user@srx> show multicast route
Instance: master Family; INET

Group: 2 3 9. 1 . 1. 1
Source: 10.222.3.2/32
Upstream interface: ge-0/0/4.301
Do�NUstream interface list:
ge-0/0/6.0

user@srx> show route table inet .1

inet .1: 10 destinaticns, 10 routes (10 active, D holddo·,,;n, 0 hidden}

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

239 .1.1. 0/24 *[Multicast/1&01 00:12:39

HultiResolve
239. l .1.1, 10. 222. 3. 2/32* [PIM/105] 00: 11 :31
Multicast ( IPv4) composite

Viewing Multicast Routes

Use the show multicast route command to display multicast forwarding cache information. The multicast routes are
the tuples in the form of (S,G). It provides information about the source, the group, and the incoming interface and outgoing
interface list. Adding the extensive option allows you to view the traffic statistics and wrong incoming interface
notifications.

You can also find the multicast forwarding information in the inet. 1 table by using the show route table inet .1
command. This command provides essentially the same list of multicast routes as the show multicast route
command, however, the latter produces a more convenient output.

Chapter 5-22 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful Multicast Commands (7 of 10)

• Check multicast source information

user@srx> show pim source
Instance: PIM.master Family: INET

Source 10.222.3.2
Prefix 10.222.3.0/24
Upstream interface ge-0/Q/4.301
Upstream neighbor 10.222.0.10

• Check multicast traffic statistics

[email protected] x> show multicast usage
Group Sources Packets Bytes
239.1.1.1 1549 836460
224.0.1.39 175 8400
224.0.1.40 1 170 8160

Prefix /len Groups Packets Bytes

10.222.3.2 /32 1 1549 836460
10.222.1.3 132 2 286 13728
10.222.1.2 /32 1 59 2832

- - "
- -'
-= M"M'""f,c/j,g'JFif''U11[= ""
" 1'l!l1Pff� www4Urupe,.not I23
" 7;Wo]l��J,!Slm/i!,$
- ----:WlliiE®iLefAJ:filW-jp'x �40,.::: 9%'£ - f - Y

Checking the Multicast Source

Use the show pim source command to display the source address, the source route prefix, and the upstream interface
to the source. Adding the detail switch shows also active groups for each source.

Checking Multicast Data Statistics

Use the show multicast usage command to look at the packet transmission statistics for each group and source.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-23

Advanced Junos Enterprise Routing Troubleshooting

Useful Multicast Commands (8 of 10)

• Check that router learns PIM RPs
user@srx> show pL� rps
Instance: PIM.master
Address family INET
RP address Type Mode Hold time Timeout. Groups Group prefixes
10.222.1.2 bootstrap sparse 150 90 0 224.0.0.0/4
10.222.1.3 bootstrap sparse 150 90 239 .1. 1.0/24
10.222.1.2 auto-rp sparse 150 100 0 224.0.0.0/4
10.222.1.3 auto-rp sparse 150 100 1 239.1.1.0/24
10.222.1.2 static sparse 150 None 0 224.0.0.0/4

• Check that PIM BSR is known to router

user@srx> show pim bootstrap
Instance: PIM.master

BSR
10.222.1.3
.____......._ __
Pri Local address
100 10.222.1.2
Pri State
0 InEligible
Timeout
73
�

Checking PIM Rendezvous Points

The show pim rps command displays the status of RP s configured statically or learned dynamically through the Bootstrap
or Auto-RP protocol. The holdtirne field shows the hold time advertised by the RP, and the timeout field shows the time
remaining to the RP withdrawal from the cache. Adding the detail option provides information on active groups that the RP
serves.
In the example on the slide, the RP with address of 10.222.1.2 was learned from three different sources: BSR, Auto-RP, and
static. Recall that the Junos OS prefers the RP information in order of preference from BSR, then Auto-RP, then static
configuration.

Checking PIM BSR

The show pim bootstrap command shows the active Bootstrap router along with the local router candidate priority in
Bootstrap elections.

Chapter 5-24 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful IVlulticast Commands (9 of 1.0)

• Check RPF path up to the RP or to the source

user@srx> mtrace from-source source 10.222.3.2 group 239.1.1.1

Mtrace from 10.222.3.2 to 10�222.0.9 vi.a group 239.1.1.1
Querying full reverse path.. . -,o; *
0 (10.222.0.9)
-1 ? (10.222.0.10) PIM thresh A
-2 ? (10.222.3.2)
Round trip time 7 ms; total ttl of required.

Waiting to accurn.ulate statistics...Results after 9 seconds:

Source Response Dest Overall Packet Statistics For Traffic Fro.m

10.222.3.2 10.222.G.9 Packet 10.222.3.2 To 239.1.1.1
v / rtt 8 ms Rate Lost/Sent = Pct Rate
10.222.3.1
10.222.0.10
v \ ttl ?/Ci O pps
10.222.0.9 10.222.0.9
Receiver Query Source

Checking RPF Path

Use the mt race command to verify the RPF path between the specified source and the receiver. Note that you can specify
an RP address as the source address to trace the RPF patch up to the RP.
This command performs the reverse path query process. The initiating router generates an a request message with the
source (SJ, destination (D), and group (G) information encapsulated. This request is forwarded to the next upstream router on
the RPF path to the source. Note that this requires PIM to be enabled on the RPF interface, and therefore the mtrace
command is able to detect RPF failures due to PIM/IGP inconsistency. Every next router in turn forwards the request packet
upstream to the source DR or the RP and adds local information, such as multicast routing protocol used, distance from the
requesting router, incoming interface, traffic statistics, and so forth. The first-hop router, which is the request message
receiver, generates a response message, and passes it down to the destination IP address in unicast fashion.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-25

Advanced Junos Enterprise Routing Troubleshooting

Useful Multicast Commands (1.0 of 1.0)

• For difficult problems, go to debugging
• Traceoptions
user@srx> show log pim.log
Mar 25 09:40:02.383781 PIM ae0.0 SENT 10.222.0.1 -> 224.0.0.13 V2 .JoinPrune to 10.222.0.2
holdtime 210 groups 1 sum Oxb726 len 42
Mar 25 09:40:02.389294 group 239.1.1.1 joins 1 prunes 1
Mar 25 09:40:02.389356 join list:
I'1ar 25 09:40:02.390050 source 10.222.1.3 flags sparse,rptree,wildcard
Mar 25 09:40:02.390124 prune list:
Mar 25 09:40:02.390189 source 10.222.3.2 flags sparse,rptre.e
---(more)---

• Monitor traffic interface also called tcpdump

user@srx> monitor traffic interface ge-0/0/4.301 no-resolve detail matching 11 dst
224.0.0.13"

09:43:57.508299 Cut IP {tos OxcO, ttl 1, id 23186, offset 0, flags [none], proto: PIM
(103), length: 54) 10.222.0.9 > 224.0.0.13: 10.222.0.9 > 224.0.0.13:PIMv2, length 34
Hello, cksum Oxb67d {correct)
Hold Time Option (1), length 2, Value: 1m45s
Lfu'{ Prune Delay Option (2}, length 4, Value:
T-bit=l, LAN delay 500ms, Override interval 2000ms
---(more)---

fl-�� lll!ffiS- "\i.:'3J wm":·,�"�onSelllices

'"* " -« "''""'� ,,,_,_.,,,,, �
I www.junlpernet 12$

Debugging PIM
To perform debugging functions of the PIM routing use the Junos traceoptions function. The trace output is sent to a named
log file in /var /log directory. You can define various PIM parameters to trace in the traceoptions configuration.
You can view the log file by using show log filename command or you can monitor the updates in the log file
dynamically with the monitor start filename command. Do not forget to stop monitoring when you are done, using
the monitor stop command.
The example on the slide shows a trace log entry of a PIM join message sent to 10.222.0.2 neighbor with the message
details.
You can trace the protocol messages on a router interface by using the monitor traffic interface
interface-name command. This command is essentially a front end to a well known tcpdump utility. You can use various
filtering options in this command. For example, to capture only PIM messages, you can use the following filter:
user@srx> monitor traffic interface ge-0/0/1.0 matching "dst 224.0.0.13"
The example on the slide shows a captured PIM hello message.

Chapter 5-26 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

General Multicast Troubleshooting Steps

Check the source is generating multicast traffic
Check that PIM is enabled on the source facing

:::::========================::::C::.c ID
interface

e ·-
Check JGMP and PIM are enabled on tl1e receiver B
facing interface
i ,g
:::::::========================:C::.5;::;,'§
Watch for ASM reports in SSM range
Try static lGMP joins !;:: 8.

Check PIM is enabled on all routers

;:::
Check PIM neighbors
Check BSR/MA receive RP announcements ::I
!a, 1/lal
--�------�-��---,r-- � ::,
---------------..r::!a.
Check for the sparse-dense mode in Auto-RP .:::. '-

Check that source DR can reach the RP (.) .:::.

Check the DR generates register messages
In Anycast RP check RP's forward SA messages �
.., U j
--��������--.-8
Check all routers can reach both RP and source
IP addresses
Check the RPF pat11s to the RP and source with
mtrace

General Multicast Troubleshooting Steps

The purpose of the multicast troubleshooting flowchart shown on the slide is to provide a set of high-level steps designed to
get you started with multicast fault analysis.
You begin with verifying that source is sending multicast traffic at the source DR. The lack of multicast traffic may be an
indication that the source does not generate it or the source facing interface is not configured in PIM.
Then you check that the receiver DRs receive the IGMP reports generated by the hosts on LAN. If not, you will need to check
that both IGMP and PIM are enabled on the LAN interface. Next check that your security policies and firewall filters allow
JGMP messages. Make sure that the IGMP (* ,G) reports do not fall in the SSM range. Ensure that the IGMP limit is not
reached if the limits are configured.
In PIM-SM ASM model you have to ensure that RP is configured properly, and the other routers learn the RP information. The
RP information distribution depends on the chosen method of using either BSR, or Auto-RP protocol, or static configuration.
For the BSR operations the verification is mainly consist of checking the PIM availability on all routers in the multicast
domain. The Auto-RP verification is a more complicated task that requires you to additionally ensure that the sparse-dense
mode is enabled across the domain, the dense groups of 224.0.1.39 and 224.0.1.40 are provisioned on all routers and the
group distribution is not limited with a multicast scoping.
Continued on the next page.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-27

Advanced Junos Enterprise Routing Troubleshooting

General Multicast Troubleshooting Steps (contd.)

Then you need to check that active source information reaches the RPs. Normally the RPs receive this information in PIM
register messages. The Anycast RP application might require you to enable MSDP, in which case you check the MSDP
session state and MSDP SA message flow.
Finally if receiver DRs cannot join either RPT or SPTyou check that the DRs have the routes to the source DR and the RP in
their unicast routing tables, and trace the RPF path to the source DR and the RP with mtrace utility.

Chapter 5-28 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Agenda:
Troubleshooting Advanced Features
• Multicast Troubleshooting
�Multicast Case Study
• Cos Troubleshooting
• Cos Case Study

Multicast Case Study

The slide highlights the topic we discuss next.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-29

Advanced Junos Enterprise Routing Troubleshooting

Multicast Case Study: Sparse Mode ASM

• Topology, symptoms, and relevant information:

• Your company decided to implement Anycast RP to ensure multicast
service availability. After Anycast RP was enabled receivers stopped
receiving multicast stream from the source. Currently. no security
policies are implemented across the domain.
Source

10.222.1254 RP ·- _ - __ - . RP 102221.254
.5 MSDP .

r:l
10-222.0.12/30
OSPF .14
131 5
•.21 .22.=-· R
R4 . • Receiver
10.222.0.2G/:,Q .

Multicast Case Study: PIM-SM ASM Issues

This slide presents a network topology, reported symptoms and description of a case related to PIM·SM ASM model issues.
In this case study your company decided to implement Anycast RP to ensure multicast service availability by providing RP
redundancy. After Anycast RP was enabled receivers stopped receiving multicast traffic from the source. You are requested
to troubleshoot the issue. Your initial verifications indicate that the routers do not have configured security policies or firewall
filters preventing multicast data or control plane messages.

Chapter 5-30 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Sparse Mode Troubleshooting (1 of 9)

• Check PIM RP information at the receiver DR
user@RS> show pim rps
Instance: PIM.master

address-family INET
RP address Type Mode Holdtime Timeout Groups Group prefixes
10.222.1.254 bootstrap sparse 150 146 224.0.0.0/4

• Check PIM join state at R5

user@RS> show p.im join
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, s = Sparse, W Wildcar:d

Group: 239.1.1.l
Source: *
RP: 10.222.1.254
Flags: sparse,rptree,wildcard
Upstream in�erface: ge-0/0/12.0

Check the PIM RP at the DR

You begin with checking the PIM RP information at the receiver DR by using the show pim rps command. The command
output indicates that R5 learns an RP with the address of 10.222.1.254 by BSR protocol.

Check PIM Join at the DR

Then you use the show pim join command to check if the DR originated the PIM join message upstream to the RP. The
command output shows that R5 did originate the PIM join for the group 239.1.1.1.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-31

Advanced Junos Enterprise Routing Troubleshooting

Sparse Mode Troubleshooting (2 of 9)

• Check the path to the RP from R5
user@R5> traceroute 10.222.1.254
traceroute to 10.222.1.254 {10.222.1.254), 30 hops max, 40 byte packets
10.222.0.21 110.222.0.21) 1.387 ms 1.308 ms 0.927 ms
2 10.222.1.254 (10.222.1.254) .470 ms 1.349 ms 1.643 ms

user@RS> mtrace from-source source 10.222.1.254 group 239.1.1.1

Mtrace from 10.222.1. 254 to 10.222.0.22 via group 239 .1.1.1
Querying full reverse path ... * *
G (10.222.0.22)
-1 ? (10.222.0.21) PIM threshA r default]
-2 ? (10.222 .0.5) PIM threshft 1 Reached RP/Core(
rtouna trip 1:.1me .j, ms; i:ot::aJ. t..:1. or L requirea.

Waiting to accumulate statistics ... Results after 10 seconds:

Source Response Dest Overall Packet Statistics For Traffic From

10.2 22.0.22 Packet 10.222.1.254 Tc 239.1.1.1
v _/ rtt 3 ms Rate Lost/Sent Pct Rate
10.222.0.5 Reached RP/Core
ttl 0/0 O pps
10.222.0.6
---(more)---

Check the Path to the RP

You proceed to checking the multicast path availability for the PIM join message delivery from R5 to the RP and subsequent
multicast traffic distribution on the RPT. You check the route to the RP address with the traceroute command, and the RPF
path to the RP with the mt race command.The output of the commands ensures that R5 can join the RPT at the RP
configured on R2 router.

Chapter 5-32 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Sparse Mode Troubleshooting (3 of 9)

• Verify PIM join at the RP

user@R2> show pim. join 239 .1.. 1.1
Instance: PIM.master Family: INET
R .;:; Rendezvous Point Tree .,. S :;::; Sparse, N Wildcard

Group: 239.1.1.1
Source: *
RP: 10.222.1.254
Flags: sparse,rptree,wildcard
I Upstream interface: Local I

• Check that the source is active at the source DR

user@Rl> show pim source
Instance: PIM.ajert-vr01-igp Family: INET

Source 10.222.3.2
Prefix 10.222.3.0/24
Upstream interface ge-0/0/1.305
Upstream neighbor Direct

Check the PIM Join at the RP

You check that the PIM join message is received at the R2 RP. You use the show pim join command at R2. The output
indicates that the PIM join originated by R5 has reached R2.

Check the Multicast Source

Next you use the show pim source command to check the multicast source information at the source DR (R1). The
command output shows that the DR has learned an active source at the 10.222.3.2 address on its ge-0/0/1.305 interface.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-33

Advanced Junos Enterprise Routing Troubleshooting

Sparse Mode Troubleshooting (4 of 9)

• Check PIM RP information at the source DR

user@Rl> show pi.m rps
Instance: PIM.ajert-vr01-igp
Address family INET

---
�P address Type Holdtime Timeout Groups Group prefixes
10.222.1.254 bootstrap 150 146 0 224.0.0.0/4
�

• Check the path to the RP at R1

user@Rl> ping 10.222.1.254 count 1 record-route
PING 10.222.1.254 (10.222.1.254): Sc data bytes

__
64 bytes from 10.222 .1. 254: icmp_seq=O ttl=64 time=4. 323 ms
RR: 10.222.1.254
._______ 10.222.0.18
�

• Check that R1 generates Pl M register messages

user@Rl> show pim statistics I match "(PIM Message type) I (V2 Register)"
PIM Message cype Received Sent Rx errors

___

-�'$'��.�
V2 Register O 851 0
V2 Register Stop O O O
.......___ �

c 2014Ja-Netwo,!cs, Inc. All rijJIII,, .....;:!., ��:i'�::Tiffiru� Worldwide Education Services ,1 WWWl\Jn,per net I 34

Check the PIM RP Information at the Source DR

Then you verify that the RP information is known to the source DR. The show pim rps command indicates that R1 has
learned the RP at the 10.222.1.254 address by the BSR protocol.

Check the Route to the RP

You use the ping command with the record-route option to check the route the DR would use to send the PIM register
messages to the RP. The output shows that the route goes to R3.

Check the PIM Register Messages at the Source DR

You use the show pim statistics command to find the counter of PIM register messages. The output shows that the
source DR generates the PIM register messages.
At this point you discovered that R5 joins the RP at R2, whereas R1 registers the active source at the RP configured at R3.

Chapter 5-34 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Sparse Mode Troubleshooting (5 of 9)

• Verify that R3 receives PIM register messages

user@R3> show pi.m statistics I match n (PIM Message type) I (V2 Register)"
PIM Message type Received Sent Rx errors
V2 Register 857 0 0
V2 Register Stop Q 0 0

• Check the MSDP session state

State Last up/down Peer-Group SA Count
Established 02:12:04 an.yeast G/0

• Check MSDP SA messages at R2

• There are none
ser@R2> show msdp sa

Check the PIM Register Messages at R3

You use the show pim statistics command to find the counter of PIM register messages at R3. The command output
shows that the PIM register messages are being received.
You proceed to checking the MSDP session. You use the show msdp command to view the session state. The command
output shows that the two RPs established the MSDP session.

Check the MSDP SA Messages at R2

Next you check that the MSDP SA messages advertising the active source are being received at the R2 RP. The show msdp
sa command reveals that R2 does not receive the SA messages.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-35

Advanced Junos Enterprise Routing Troubleshooting

Sparse Mode Troubleshooting (6 of 9)

• Check that R3 advertises the active source

ist:ic.s I m.,tch '' 'SA mess,,ges sent tt

• Check that R3 knows the active source

• It does not, despite receiving register messages
3> show pim source
.ce: PIM.master Family: INET

Check the MSDP SA Messages at R3

You then decide to check if R3 sends the MSDP SA messages. You use the show msdp statistics command and look
up the SA message counter. The command output shows that R3 does not send the SA messages.

Check the Source Information at R3

You then use the show pim source command to find out if the source is known to R3. The command reveals that no
active sources are learned by R3 despite the fact that R3 is receiving PIM register messages from R1.

Chapter 5-36 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Sparse Mode Troubleshooting (7 of 9}

• Check R3 RP information
user@R3> show pi.rn rps extensive
Instance: PIM�master
Address family INET

RP: 10_222.1.254
Learned via: static configuration I
1"1oae: ::;parse
Time Active: 01:54:45
Holdtime: 0 I
Device Index: 132
Subunit: 32769
Interface: ppeD.32769
Static RP Ove.rr.i..de: Off
---(more)---

Check the R3 RP Information

You keep on troubleshooting and decide to double check the RP details at R3. You use the show pim rps extensive
command to view the details. The command output indicates that the RP information is learned by R3 from static
configuration only.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-37

Advanced Junos Enterprise Routing Troubleshooting

Sparse Mode Troubleshooting (8 of 9)

• Check that Bootstrap router sees candidate RP

advertisement messages from R3
user@R2> show piin statistics I :match 11 (PIM Message type) I (V2 Candidate RP) n
PIM Message type Received Sent Rx errors
V2 Candidate RP 0 0 0

• R3 does not manifest itself as an RP

• Check R3 RP settings
user@R3> show configuration protocols pim rp
static {
address 10.222.1.254;

Check the PIM BSR Candidate RP Messages

You want to ensure that R3 advertises itself as an RP by checking the BSR Candidate RP messages flow. You use show pim
statistics command and look up the candidate RP BSR messages at the Bootstrap router (R2). The command output
reveals that R2 does not receive any candidate RP messages. This might indicate a problem with R3 RP settings.

Check the R3 RP Settings

You check the R3 RP configuration and find out that the RP is configured with static option. However, the local option
required to enable RP functions at the local router is not configured. This explains why R3 does not advertise its RP
capabilities in the BSR candidate RP messages. Besides, R3 does not generate the MSDP SA messages because it ignores
the PIM register messages from Rl as it does not consider itself an RP.

Chapter 5-38 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Sparse Mode Troubleshooting (9 of 9)

• Solution:
• Configure R3 RP as local instead of static
• Check PIM signaling all over again
user@R5> show p.:i.m join

I I
Group: 239.1.1.1
Source: 10. 222. 3. 2
��ags: sparse,sp�
Upstream in-.:erface: ge-0/0/12.D

Solution
You modify the R3 RP settings and run the verification round again. This time R5 successfully joins the SPT and is receiving
multicast traffic for the 239.1.1.1 group.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-39

Advanced Junos Enterprise Routing Troubleshooting

Agenda:
Troubleshooting Advanced Features
1111
Multicast Troubleshooting
1111
Multicast Case Study
7CoS Troubleshooting
1111
Cos Case Study

Cos Troubleshooting
The slide highlights the topic we discuss next.

Chapter 5-40 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Cos Overview (1. of 3)

• CoS provides differentiated treatment to traffic flows

• End-to-end mechanism
• Unidirectional traffic flow processing
• CoS components:
• Traffic classification
• Process traffic at ingress
• Multifield classifiers (Firewall filters)
• Behavior aggregate classifiers

Cos at a Glance
The convergence of voice and data networks is critical to network ability to provide guaranteed service level for the traffic
kinds of different nature. Allowing fair and even competition among the different applications by having no traffic
differentiation does not work because different types of traffic have different requirements. Typically, data packets are large
and utilize large amounts of bandwidth. Besides, the data communication has a bursty nature. In voice communication,
packet transmission is much more sensitive to delay and jitter. Cos provides the ability to treat some packets differently as
they transit a network.
Cos is an end-to-end mechanism, enabling Cos on one router does not provide the entire solution.
If all the nodes in a Cos domain do not implement a common set of CoS processing rules, also known as per hop behavior
(PHB), the end-to-end performance of the network cannot be predicted.

Junos Cos Components

The function of packet classification is to examine traffic as it enters the SRX device. Based on a variety of parameters, the
device can separate the packets into different forwarding classes and assign a packet loss priority value. There are two types
of classifiers: Behavior aggregate (BA) classifiers and multifield classifiers.
Continued on the next page.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-41

Advanced Junos Enterprise Routing Troubleshooting

Junos Cos Components (contd.)

BA classifier is based entirely on existing Cos markings. It assigns all inbound traffic with a given Cos marking to the same
forwarding class and loss priority. BA classifier types typically used in enterprise networks include IP precedence, DSCP, and
Ethernet 802.ip classifiers. BA classifiers are typically used in the network core.
A multifield classifier is essentially a firewall filter used for traffic classification. Multifield classifiers allow you to match
against a variety of fields in a packet header. Multifield classifiers are typically used at the network edge.

Chapter 5-42 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Cos Overview (2 of 3)
• CoS components:
• Policing
• Single-rate two-color policers
• Process traffic at either ingress or egress
• Soft action or hard action policers
• Queuing
• Traffic goes to an outgoing queue based on its classification
• Scheduling
• Define queue processing parameters
• Rewrite rules
• Process traffic at egress
• Mark packet cos fields based on prior classification

Junos Cos Components (contd.)

The function of policing is to provide a first stage of congestion management. With policing, you can condition incoming or
outgoing traffic by applying bandwidth constraints. You can use a firewall or interface-level policer. SRX devices support a
single-rate two-color policers. They consists of one rate threshold, CIR, and one burst size, CBS. When traffic exceeds the
configured bandwidth threshold with a certain amount of burst data, the traffic can be either assigned to a different
forwarding class or loss priority, or dropped.
The queuing stage involves placing packets into the outgoing queue corresponding to a forwarding class the packets are
assigned to by classifiers, where they are serviced by a scheduler.
The function of scheduling is to define the parameters for how queues treat traffic. Scheduling determines the order in which
packets are transmitted, the rate at which packets are transmitted, the queue buffer depth, and the differential treatment of
packets in the event of congestion.
Rewriting the CoS bits in a packet header is the final stage of the Cos process. Once packets have been scheduled for
transmission, the SRX device can mark the header with CoS bits, which then can be used by the next-hop device BA
classifier. The CoS fields in packet headers that are typically marked by rewrite rules in enterprise networks include IP
precedence, DSCP, and Ethernet 802.1p.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-43

Advanced Junos Enterprise Routing Troubleshooting

Cos Overview (3 of 3)
• CoS components
• Forwarding Class is the central component in the Cos
framework
• Defines Per Hop Behavior (PHB)
f
• Classifiers map trafic to a Forwarding Class
• Forwarding Classes are bound to outgoing queues
• Queues are bound to schedulers
• Rewrite rules act on the Forwarding Class classification
• Loss Priority
• Set by classifiers or policers
• Schedulers act on Loss Priority in case of congestion

Junos Cos Components (contd.)

The main function of forwarding classes is to determine the output queue to which a packet is assigned. Forwarding class is
a central component in the Junos CoS framework that ties other component together. As a packet enters a SRX device and
passes through BA or multifield classification, the device assigns it to a forwarding class. The forwarding class is mapped to
an outgoing queue by provisioning. Rewrite rules are applied to a packet according to the packet forwarding class. There are
four software defined forwarding classes in SRXs:
Best effort (BE);
Assured forwarding (AF);
Expedited forwarding (EF); and
Network control (NC).
Note that by default all ingress traffic is classified to either BE forwarding class, that gets 95% of an outgoing interface
throughput or NC forwarding class, that gets 5% of the throughput respectively.
Packet loss priority (PLP), also known as drop precedence, identifies a given packet's drop-eligibility. In other words, it
determines the likelihood that a packet will be dropped under congestion. Note that having a PLP value assigned does not
automatically mean that the packet will be dropped. The value is used by schedulers in conjunction with drop profiles. Drop
profile is a probability of a packet to be dropped as a function of queue fullness. You can assign different drop profiles to
different PLPs.

Chapter 5-44 • Troubleshooting Advanced Features www.juniper.net

 Advanced Ju nos Enterprise Routing Troubleshooting

Cos Processing on SRX Series Devices

Ingress

forwarding Class loss Priority

Egress

Cos Processing in SRX Devices

The slide shows general steps in CoS processing of a packet in an SRX device.
Packets arriving at the router are first subjected to the BA classification. The output of the BA classification function is packet
assignment to a forwarding class and setting the packet PLP.
The next processing stage is multifield classification. Generally you do not use both BA and multifield classifiers on the same
interface. BA classifiers are typically used on core facing interfaces, whereas multifield classifiers are typically used on user
facing interfaces.
When desired, a firewall filter or interface level policer can be applied to limit matching traffic. An interface level policer
processes all traffic entering the interface, whereas a policer called as a result of firewall filter match, processes only the
traffic that produced the match.
Cos forwarding policy provides the ability to select a packet's routing path based on its forwarding class.
After the route lookup, a packet goes to the selected egress interface. The first egress CoS processing state is output
policing.
Then the packet can be inspected and potentially re-classified by an multifield classifier.
Next the packet is placed to an outgoing queue, which is serviced by a scheduler that factors priority and configured weight
to determine when a packet should be sent out from a given queue.
The last step in CoS processing is application of a rewrite marker.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-45

Advanced Ju nos Enterprise Routing Troubleshooting

Cos Troubleshooting Checklist (1 of 2)

• General CoS troubleshooting checklist

• Remember Cos defaults on the SRX
• Queue O (Best effort. 95% transmit rate)
• Queue 3 (Network control. 5% transmit rate)
• Check that Cos parameters are consistent end-to-end
• Check that you applied Cos in both directions for
bidirectional traffic flows
• Watch for Multifield classifiers discard actions
• Check the Policer actions

Cos Troubleshooting Checklist-Part 1

When you begin troubleshooting Cos on SRX devices, remember the default behavior of CoS framework. All traffic entering
an SRX device is classified by the inet-precedence compatibility BA classifier to either BE forwarding class or NC forwarding
class. The BE forwarding class is mapped to the queue number O that has 95% of interface bandwidth. The NC forwarding
class is mapped to the queue number 3 that has 5% of interface bandwidth.
Recall that Cos parameters must be implemented consistently end-to-end. In other words, if a single hop on a packet path is
not configured according to Cos plan or misconfigured the overall Cos structure will not work.
Cos processing is a unidirectional function by its nature, meaning there is an ingress and egress piece in traffic processing.
Traffic is first classified and then put to a queue, where it is processed by a scheduler. To provide bidirectional traffic flows
with Cos treatment you need to ensure that Cos is applied in both directions.
Recall that a multifield classifier is in fact a firewall filter. As with any firewall filter keep in mind that the default filter action
is discard. Double check your firewall filter rules in filters that are used for both protection and Cos classification.
You can configure hard policers or soft policers. The hard policer action is to discard non-conforming packets. Sometimes
the soft policing can be more suitable for your task but a hard policer can be applied. You might want also to check the
policers called by firewall filters. Check the firewall filter match conditions to avoid policing where it is not needed.

Chapter 5-46 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Cos Troubleshooting Checklist (2 of 2)

• General CoS troubleshooting checklist

• Make sure that every Forwarding Class has an associated
Scheduler
• Watch for Strict-high priority queues
• Can starve other lower priority queues

Cos Troubleshooting Checklist-Part 2

Make sure that every forwarding class has an associated scheduler attached. Lack of a scheduler leaves the forwarding
class with no scheduling resources provided. By default the SRX scheduling algorithm will allow the queue without attached
scheduler to transmit but only if there is no packets in the other queues. The buffer depth of such queue will be reduced to
two MTU-sized packets.
You can configure a queue scheduling priority to the strict-high value. Strict-high priority is a special priority level that allows
to designate a queue as low-latency. It has the highest precedence and the queue can use up to the full interface's
bandwidth. Note that the unlimited precedence of strict-high can cause starvation of lower priority queues. You might
consider applying a policer to traffic designated for a strict-high priority queue or use of the queue shaper.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-47

Advanced Junos Enterprise Routing Troubleshooting

Useful Cos Operational Commands (1 of 6)

• You want to check interface Cos information
user@srx> show interfaces ge-0/0/6 extensive I find °CoS information 11
Cos information:
Direction : Cutpu·t
Cos transmit queue Band'..;idth Buffer Priority Limit
% bps % usec
O dat.a r r r 0 low none
voice r r 0 5000 strict-high none
3 nc 5 50000000 5 0 high none
---(more)---

• You want to check interface queue counters

user:@srx> show interfaces ge-0/0/6 extensive I find nQueue counters n
Queue counters: Queued packets Transmitted packets Dropped packets
O data 152813 152813 0
voice 24221 24221 O
2 assured-fcrw O O O
3 nc 237308 237308 0
---{more)---

Viewing Interface Cos Information

The show interface interface-name extensive command produces a massive output displaying various
interface parameters, counters, policies, Cos parameters, and so forth.
Use the command with the find filter to look for the "Cos information" string to display the interface CoS summary
including list of the interface queues and their scheduling parameters.
Use the same command with the find filter to look for the "Queue counters" string to display the list of interface
queues along with the queue counters of queued packets, transmitted packets, and dropped packets.

Chapter 5-48 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful Cos Operational Commands (2 of 8)

• You want to check interface queue details

user@srx> show interfaces queue ge-0/0/6
Physical interface: ge-·0/0/6, Enabled, Physical link is Up
Interface index: 140, SNMP i.findex: 513
Forwarding classes: 8 supported, 4 in use
Egress queues: 3 supported, 4 in use
Queue: O, Forwarding classes: data
Queued:
Packets 152848 0 pps
Bytes 22776646 0 bps
Transmitted:
Packets 152848 G pps
Bytes 2277 664 6 0 bps
Tail-dropped packets 0 0 pps
RED-dropped packets 0 () pps
---(more)---

Viewing Interface Queue Details

The show interface queue interface-name command displays an extensive view of queue counters.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-49

Advanced Junos Enterprise Routing Troubleshooting

Useful Cos Operational Commands (3 of 8)

• You want to check policer drops

•Bya firewall filter policer
user@srx> show firewall

Filter: cos-classifier
Policers:
Name Bytes Packets
vo-policer

•Byan interface policer

user@srx> show policer
Policers:
Name Bytes Packets
ent-policer-ge-0/0/6.0-inet-i

Checking Policer Drops

The show firewall command displays counter and policer statistics for all firewall filters or just the filter named as an
argument of the command.
The show policer command displays a list of all applied interface-level policers. The name of each policer is generated
automatically by the system and consists of policer name, interface where it is applied, protocol family, and direction.

Chapter 5-50 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful Cos Operational Commands (4 of 8)

• You want to check interface CoS settings

user@srx> show class-of-service interface ge-0/0/6
Physical interface; ge-0/0/6, Index: 140
Queues supported: S, -Queues in use: 4
Scheduler map: ent·-schedulers, Index: 53115
Congestion-no�ification: Disabled

Logical interface: ge-0/0/6.0, Index: 74

Object Name Type Index
Rewrite enterprise-cos dscp 8484
Classifier enterprise-cos dscp 8484
Classifier dscp-ipv6�compatibility dscp-ipv6 9

• You want to check forwarding-class to queue mapping

user@srx> show class-of-service forwarding-class

Forwarding class ID Queue Policing priority SPU
priority
data 0 normal low
voice normal low
assured-forwarding 2 2 normal low
nc 3 3 normal low

Checking Interface Cos Settings

Use the show class-of- service interface interface-name command to display CoS parameters provisioned
for the interface specified. The command shows interface queue summary, a scheduler map attached to the interface, and
BA classifiers and rewrite markers configured on the interface logical units.
Note that you can apply the scheduler map at the interface unit level. To do so you first have to configure the
per-unit-scheduler on the interface.
[edit interfaces ge-1/0/0]
user@srx# show
per-unit-scheduler;

www.juniper.net Troubleshooting Advanced Features • Chapter 5-51

Advanced Junos Enterprise Routing Troubleshooting

Useful Cos Operational Commands (!5 of 6)

• You want to check BA classifier parameters

user@srx> show class-of-service classifier name enterprise-cos
Classifier: enterprise-cos, Code point type: dscp, Index: 8484
Cede point Forwarding class Loss priority
000000 data high
101110 voice low
110000 nc low .

• You want to check Rewrite rules' parameters

user@srx> show class-of-service rewrite-rule name enterprise-cos
Rewrite rule: enterpr:ise-cos, Code point type: dscp, Index: 8484
Forwarding class Loss priority Code point
data high 000000
voice low 101110
nc low 110000

!!!% ' "'== '. ' •, • '

' IIO:l"l�ll-,IM- rnJ,1$�, _., - _ '���I'", �O,!!Sel"Yices
! wwwJunlpernet 152

Checking BA Classifiers
The show class-of-service classifier command lists all system BA classifiers. The command takes a classifier
name or classifier type as a filtering argument. The example command on the slide shows a BA classifier of DSCP type called
enterprise-cos.

Checking Rewrite Rules

The show class-of-service rewrite-rule command lists all system rewrite rules. The command takes a rewrite
rule name or classifier type as a filtering argument. The example command on the slide shows a rewrite rule of DSCP type
called enterprise-cos.

Chapter 5-52 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful Cos Operational Commands (6 of 6)

• You want to check Scheduler maps

user@srx> show class-of-service scheduler-map e.nt-schedulers
Scheduler map� �nt-schedulers, Index: 53115

Scheduler: data-scheduler, Forwarding class; data, Index: 3044

Transmit rate: remainder, Rate Limit: none, Buffer size: remainder, Buffer .Limit:
none, Priority: low

Sche.duler: voice-scheduler, Forwarding class: voice, Index: 40418-

Transmit race: unspecified, Rate Lim.it: none, Buffer size: 5000 us, Buffer Limit:
none, Priority: strict-high

Scheduler: nc-scheduler, Fo.r:warding class: nc, Index: 5666

Transmit ra"t:e: 5 percent, Rate Limit: none, Buf£er size: 5 percent, Buffer Lifill.t:
none, Priority: high
---{more)---

CT-.1ill0iS�"��=w t
�
'g"'
JllrnP""� - * · -�m�nServlces -�-
�
www4Ufl,pe1:ne1153
�..,rjf\fyg < """ , x To�

Checking Scheduler Maps

Use the show class-of-service scheduler-map command to display all system scheduler maps along with their
associated schedulers and their parameters. The command takes a scheduler map name as its argument, which allows you
to view only the specified scheduler map.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-53

Advanced Junos Enterprise Routing Troubleshooting

General Cos Troubleshooting Steps

Check firewall filter configuration
Check the policer profile conforms the expected
traffic load

Check multifield and BA classifier settings

Check that interfaces have the required
classifiers applied
Check that rewrite rules mark the packet Cos
fields

Check the interface Cos settings

Check the scheduler parameters
Watch for congestion

Check for the end-to-end consistent Cos

implementation
Check for bidirectiona I Cos
Check for transmission path reliability

General Cos Troubleshooting Steps

The purpose of the CoS troubleshooting flowchart shown on the slide is to provide a set of high-level steps designed to get
you started with Cos fault analysis_
If you notice packet loss you begin with checking the firewall filters and policers_ Watch for misconfigured match conditions
and discard actions_
If you keep detecting packet loss or that Cos treatment does not meet the required parameters you check that packets are
sorted among the queues as required by your Cos design. You check the classifiers, both multifield and BA in hop-by-hop
fashion. If BA classifiers are used you want to make sure that rewrite rules code points match those of BA classifiers_
Next you check interface Cos settings, particularly the attached scheduler map and its associated schedulers. You check if
interface bandwidth is sufficient to accommodate all traffic types or congestion occurs. In later case you have to ensure that
the delay sensitive traffic is put to a higher priority queue with a reduced buffer depth_
Finally you take a network-wide look at the Cos processing. Recall that CoS requires consistent implementation across the
domain. You check that CoS is applied in any direction of traffic flow_ Note that if the transmission path is not stable, traffic
re-routing might happen, which can cause congestion on certain links. If CoS is designed and implemented properly, the
congestion should not affect the high priority traffic_

Chapter 5-54 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Agenda:
Troubleshooting Advanced Features
III
Multicast Troubleshooting
III
Multicast Case Study
III
CoS Troubleshooting
7CoS Case Study

Cos Case Study

The slide highlights the topic we discuss next.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-55

Advanced Junos Enterprise Routing Troubleshooting

CoSCaseStu : VoIP Issues

• Topology, symptoms, and relevant information:

• Your company is operating Cos-enabled network. After inspecting traffic
flows company decided to increase the R2 to R3 link capacity by
replacing existing Gigabit Ethernet connection with Ethernet LAG. Users
are now reporting VoIP quality problems after the changes were
implemented.
Host.A
10222..3.2

18 ge-0/0/2
�22016/30

R2 0
3
2
•
102::� 0;30 R
ge.Q/0/6
OSPF 10.222.0.12/30
.14
.131

''iii'�
.21 ge-0/0/12 .224,�
R4 Host 8
10222.0.20/30
10222.2.2

Cos Case Study: VoIP Issues

This slide presents a network topology, reported symptoms and description of a case related to CoS issues. In this case
study your company is operating COS-enabled network. After inspecting traffic flows company decided to increase the R2 to
R3 link capacity by replacing existing Gigabit Ethernet connection with Ethernet LAG. Users are now reporting VoIP quality
problems after the changes were implemented. You are required to troubleshoot the issue.

Chapter 5-56 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

VoIP Troubleshooting (1 of 7)
• Check the path VoIP packets take
user@host-a> traceroute 10.222.2.2
traceroute to 10.222.2.2 (10.222.2.2) 1 30 hops max, 40 byte packets
1 10.222.3.1 {10.222.3.1) 1.812 ms 1.415 ms 1.339 ms
10.222.0.17 (10.222.0.17) 2.040 ms 1.860 ms 1. 783 ms
3 10.222.0.1 (10.222.0.1) 2.196 ms 2.157 ms 2.091 ms
4 10.222.0.6 (10.222.0.6) 2.301 ms Z.440 ms 2.262 ms
5 10.222.2.2 (10.222.2.2) 2.317 ms 2.388 ms 2.472 ms

• Check the forwarding class the VoIP packets are

mapped to by the multifield classifier at R1
user@Rl> show configuration firewall family inet filter cos-classifier term 2
from {
protocol udp;
port 16000-16500;

then {
policer vo-po.l 1.cer;
I loss-priori�y low;
forwarding-class voice; I
accept;

Check the VoIP Packet Path

You begin with checking the path that the VoIP traffic takes. The traceroute command shows that a packet, which originated
at host-a, goes over Rl-R3-R2-R4-R5 path.

Check the MF Classifier at the Network Edge

You start inspecting the Cos settings hop by hop. The first router on the way is Rl. You check the multifield classifier
configuration. The output on the slide shows that the VoIP traffic is being classified in forwarding class called voice and is
getting low PLP. The VoIP traffic is also a subject of policing, by a policer named vo-policer"

www.juniper.net Troubleshooting Advanced Features • Chapter 5-57

Advanced Junos Enterprise Routing Troubleshooting

VoIP Troubleshooting (2 of 7)
• Check the policer drops
user@Rl> show firewall filter cos-classifier

Fi:�e�: cos-class:fier
Policers:
a s
e P
���� ����� B y _t s c_k et 0
�
e � �
�N-a_m _� � �� �������� -- � �� �� �� - �
vo-pa.licer
_ _ _
�

• Check the voice forwarding class queue mapping

user@Rl> show class-of-service forwarding-class
Forwarding class ID Queue olicing priority
P
normal
SPU
data 0 oI
voice normal
l.OW

low
assur d-forwarding
lo-..; e
2 2 normal

nc 3 3
I low
normal

Check the Policer Drops

You then use the show firewall filter cos-classifier command to view the filter counters. The command
output shows that the policer has not dropped any packets.

Check the VoIP Queue

You use the show class-of-service forwarding-class command to check which outgoing queue the VoIP
packets are placed according their forwarding class assignment. The command shows that the packets go to the queue
number 1.

Chapter 5-58 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

VoIP Troubleshooting (3 of 7)
• Check the VoIP packets queuing and queue drops
user@Rl> show interfaces queue ge-0/0/2 I find 11 Queue: 1 11
Queue: 1, Forwarding classes: voice
Queued:
Packets 121 O pps
Bytes 12342 O bps
Transmitted:
Packets 121 O pps
12342 O bps

I
Bvtes
Tail-dropped packets O pps
RED-dropped packets O pps

• Check that R1 marks the VoIP packets appropriately

user@Rl> show class-of-service rewrite-rule name enterprise-cos
Rewrite rule: e�terprise-cos, Code point type: dscp, Index: 8484
Forwarding class Less priority Code point
data hiah 000000
voice low 101110 I
nc .LOW .l.l.UUUU

Check the VoIP Queue Statistics at R1

Next you check the outgoing interface (ge-0/0/2, which is connected to R3) queue counters. You use the show
interface queue ge-0/0/2 command and look for the "Queue: 1" string. The command output indicates that
there are no queue drops.

Check the VoIP Rewrite Markers

Finally, on R1 you check the rewrite markers used for the VoIP traffic. The show class-of-service rewrite-rule
command displays the VoIP marker, that marks the VoIP packets' DSCP field with EF code point (101110).

www.juniper.net Troubleshooting Advanced Features • Chapter 5-59

Advanced Junos Enterprise Routing Troubleshooting

VoIP Troubleshooting (4 of 7)

• Verify that the next-hop router correctly classifies the

VoIP packets with BA classifier
user@R3> show class-of-service interface ge-0/0/2.0
Logical interface: ge-0/0/2.0, Index: 78
Object Name Type Index
Rewrite enterprise-cos dscp 3484
Classifier enterprise-cos dscp e4e4 I
L.:.1ass1.r.1er ascp 1.pvb compa1..101.11.1.y uscp 1.pvc

user@R3> show class-of-service classifier name enterprise-cos

Class:ifier: enterprise-cos, Code point type: dscp, Index: 8484
Code point Forwarding class .Loss priority

__
000000 data high
101110 voice low I
..t 1vuvu nc .low
....____ �

Check the Next-Hop Router BA Classifier

You proceed to inspecting the next hop router (R3). You use the show class-of-service interface ge-0/0/2
command to view the BA classifiers applied to the ingress interface
(ge-0/0/2). The command output shows a BA classifier of DSCP type called enterprise-cos on the interface.
You then check the classifier parameters using the show class -of-service classifier command. The command
shows that the classifier maps the traffic marked with DSCP code point EF to the forwarding class called voice and sets the
traffic PLP to low.

Chapter 5-60 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

VoIP Troubleshooting (5 of 7)
• Check the VoIP packets queuing and queue drops at
R3
user@R3> show interfaces queue aeO I .find egress
Egress queues: 8 supported, 4 in use
. . .
Queue: 1, Forwarding classes: voice
\.lU0Ueu:
I
Packets : 20000 0 pps
Bytes : 11080000 0 bps
Transmitted:
Packets : 19130 0 p ps
Bytes : 10598020 0 bps
Tail -dropped packets
...� .... -uroppeu paCl'\..SLS
:
:
870
u
I 6 pps
0 pps
---(more)---

Check the VoIP Queue Statistics at R3

You check the outgoing interface (ae0.0) queue counters. The show interfaces queue aeO. o command reveals that
packets are being tail-dropped from the queue 1.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-61

Advanced Junos Enterprise Routing Troubleshooting

VoIP Troubleshooting (6 of 7)
• Check the aeO Cos settings
user@R3> show class-of-service interface aeO
Physical interface: aeO, Index: 156
Queues suooorted: 8, Queues in use: 4
I Scheduler �ap: <default>, Index: 2 I
conges�ion not�rica�ion: uisauLea

Logical interface: aeO.O, Index: 73

Object Name Type Index
Classifier dscp-iov6-comoatibility dscp-ipv6
I
9
I Classifier ipprec-cornpatibility ip 13

user@R3> show class-of-service schedul.er-map

Scheduler map: <default>, Index: 2

Scheduler: <default-be>, Forwarding class: data, Index: 21

Transmit rate: 95 percent, Rate Limit: none, Buffer size: 95 percent, Buffer Limit:
none, Priority: low

Scheduler: <default-nc>, Forwarding class: nc, Index: 23

Transmit rate: 5 percent, Rate Limit: none, Buffer size: 5 percent, Buffer Limit:
none, Priority: :ow
---(more)---

Check the Problem Interface Cos Parameters

You decide to examine the problem interface Cos parameters. You use the show class-of-service interface
aeo. o command to view the interface Cos settings. The command shows that the interface output is controlled by the
schedulers in the default scheduler map.
You check the default scheduler map using the show class-of-service scheduler-map command. The command
shows the default Junos Cos parameters associated with the default schedulers.

Chapter 5-62 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

VoIP Troubleshooting (7 of 7)
• Collected information:
• R3 correctly identifies VoIP packets and puts them into
queue 1 but then some packets get dropped due to the
default scheduler's action
• Solution:
• Configure interface aeO CoS parameters according to the
Cos domain requirements
• Scheduler map. etc.

Collected Information
At this point you can conclude that R3 correctly identifies VoIP packets and puts them into queue 1, but then some packets
get dropped due to the default schedulers applied to the interface.

Solution
You have to configure the aeO.O CoS parameters according to the network requirements and cos design to ensure
consistent Cos processing end-to -end.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-63

Advanced Junos Enterprise Routing Troubleshooting

Summary
• In this content, we:
• Verified and troubleshot multicast
• Verified and troubleshot Cos

We Discussed:
Verifying and troubleshooting multicast; and
Verifying and troubleshooting Cos.

Chapter 5-64 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Review Questions
1. What is the purpose of the RPF check in multicast
routing?
2. Name two specific configuration requirements when
using Auto-RP with PIM sparse mode.
3. Which methods are used to ensure that all RPs
discover active sources in Anycast RP?
4. What is the purpose of the forwarding class in the
Junos OS Cos framework?
5. How much of interface bandwidth is allocated to the
Expedited Forwarding forwarding class by
default?

Review Questions
1.

2.

3.

4.

5.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-65

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting Advanced Features Lab

• Monitor and troubleshoot multicast issues.
• Monitor and troubleshoot CoS issues.

Troubleshooting Advanced Features Lab

The slide lists the objectives for this lab.

Chapter 5-66 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Answers to Review Questions

1.

The R PF check prevents looping and duplication of multicast packets. Lt ensures packets arc forwarded only away from the source
down to the receivers.

2.
For Auto-RP you must enable sparse-dense mode on the interfaces, and you must explicitly configure the Auto-RP dense groups:
224.0.1.39 and 224.0.0.40.

3.
ln an Anycast RP application, all RPs must be aware of active sources. Ln IPv4 multicast the two methods that RPs can use to advertise
the active sources arc MSDP protocol and RP set configuration.

4.
All packets entering an SRX device are classified to a forwarding class. The main function of forwarding classes is to determine the
output queue to which a packet is assigned.

5.
By default, the Expedited Forwarding class does not have an attached scheduler, hence no bandwidth is allocated to it.

www.juniper.net Troubleshooting Advanced Features • Chapter 5-67

Advanced Junos Enterprise Routing Troubleshooting

Chapter 5-68 • Troubleshooting Advanced Features www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Resources to Help You Learn More

I
Resource URL

Pathfinder http://pathfinder.juniper.net
http:j/www.juniper.net;techpubs/content-
Content Explorer
applications/content-explorer
Feature Explorer http:j/pathfinder.juniper.netjfeature-explorer
Learning Bytes www.juniper.net;learningbytes
Installation and
www.juniper.net;courses
configuration courses
http://forums.juniper.netjt5/Training-Certification-
J-Net Forum
and/bd-p/Training_and_Certification
Certification program www.juniper.net;certification
Courses http:j/www.juniper.net;training/technical_education
Translation tools http:j/www.juniper.net;customers/support;#task

Resources to Help You Learn More

The slide lists online resources available to learn more about Juniper Networks and technology.
These resources include the following sites:
Pathfinder: An information experience hub that provides centralized product details.
Content Explorer: Junos OS and ScreenOS software feature information to find the right
software release and hardware platform for your network.
Feature Explorer. Technical documentation for Junos O S b
- ased products by product,
task, and software release, and downloadable documentation PDFs.
Learning Bytes: Concise tips and instructions on specific features and functions of
Juniper technologies.
Installation and configuration courses: Over 60 free Web-based training courses on
product installation and configuration Uust choose elearning under Delivery Modality).
J-Net Forum: Training, certification, and career topics to discuss with your peers.
Juniper Networks Certification Program: Complete details on the certification program,
including tracks, exam details, promotions, and how to get started.
Technical courses: A complete list of instructor-led, hands-on courses and self-paced,
elearning courses.
Translation tools: Several on line translation tools to help simplify migration tasks.

www.juniper.net
Advanced Junos Enterprise Routing Troubleshooting

www.juniper.net
Advanced Junos Enterprise Routing
Troubleshooting

Appendix A: Additional IGP Troubleshooting

Advanced Junos Enterprise Routing Troubleshooting

Objectives
• After successfully completing this content, you will be
able to:
• List common commands that are used to troubleshoot and
verify the RIP routing protocol
• Isolate different IGP issues
• Explain IGP support for 1Pv6

We Will Discuss:
Common commands used to troubleshoot and verify the RIP routing protocol;

Isolating different RIP issues; and

IGP support for 1Pv6.

Appendix A-2 • Additional IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Agenda: Additional IGP Troubleshooting

7RIP Troubleshooting
• IGP Troubleshooting Case Studies
• IGP Support for 1Pv6

RIP Troubleshooting
The slide lists the topics we will discuss. We discuss the highlighted topic first.

www.juniper.net Additional IGP Troubleshooting • Appendix A-3

Advanced Junos Enterprise Routing Troubleshooting

RIP Overview (1 of 2)

• Distance-vector IGP
• Depends on split horizon. timers. and count to infinity to
resolve loops
• Mode and versions
• 1Pv4
• version 1 (legacy) or version 2 (default)
• You can modify send/receive mode
• 1Pv6: RIPng
• Similar in most respects to RIPv2
• Separate configuration hierarchy
• Default RIP preference is 100

Distance-Vector IGP Protocol

RIP is a distance-vector IGP protocol. When determining the best path to a destination RIP uses hop count as the distance.
RIP routers exchange routing information with their neighbors in the form of routing updates. These updates contain the
length of the path to the destination (distance), as well as the address of the next router along the path (vector). The longest
path in RIP network is 15. RIP sends the updates containing all routes known to the RIP router to all its neighbors every 30
seconds by default. RIP also supports triggered updates. RIP uses UDP protocol port 520 for its messages.
RIP is susceptible to routing loops because of the way routing information converges each router knows only its directly
connected links and what its neighbors tell it. To prevent the loops RIP relies on split horizon, counting to infinity and hold
down timers. Split horizon ensures that updates are not sent back to the original sender. Counting to infinity prevents route
circulation for more than 15 times, however it does not prevent loops completely, so it is used together with hold down
timers. The timers dependency makes RIP a slow converging protocol.
Continued on the next page.

Appendix A-4 • Additional IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Mode and Version

Two versions of RIP exists, RIPv1 and RIPv2. The default version in the Junos operating system is RIPv2. RIPv2 uses
multicast address 224.0.0.9 for its messages in contrast to RIPv1 broadcasting. RIPv2 supports variable-length subnet
mask (VLSM) and authentication. Note that RIPv2 is backward compatible with RIPv1. You can configure RIP send and
receive modes in the Junos OS.
1Pv6 requires a new version of RIP referred to as RIPng. In most respects, it is similar to the 1Pv4 RIPv2 protocol on which it is
based. RIPng uses the 1Pv6 multicast address ff02::9/128. It does not support authentication because that is the
responsibility of 1Pv6.
The default RIP preference is 100, which is lower that other \GP external route preferences.

www.juniper.net Additional IGP Troubleshooting • Appendix A-5

Advanced Junos Enterprise Routing Troubleshooting

RIP Overview (2 of 2)

• Default routing policies

• Import action is to accept RIP learned routes
• Export action: Do nothing
• Apply an export policy to advertise routes
• Watch out for multiple redistribution points

RIP and Routing Policies

In the Junos OS, RIP accepts all routes it receives from its neighbors. However, RIP does not advertise any routes, including
the routes learned from RIP. You have to configure a redistribution policy to make RIP advertise routes. Be careful when
configuring mutual redistribution between RIP and other IGPs at several routers because it can lead to a routing loop
formation or suboptimal routing.

Appendix A-6 • Additional IGP Troubleshooting www.juniper.net

 Advanced Ju nos Enterprise Routing Troubleshooting

Useful RIP Operational Commands (1 of 4)

• Check that RIP is operational:

user@srx> show rip neighbor
Local Source Destination Send Receive In
Neighbor
--------
State Address
-----------
Address Mode Mode Met

ge-0/0/13.0 Up 10. 222. 0. 33 224.0.0.9 mcast both

ge-0/0/7.0 Up 10.222.0.26 224.0.0.9 mcast both

user@srx> show rip statistics

RIPv2 info: port 520; holddown 120s.
rts learned rts held down rqsts dropped resps dropped
16 0 0 !)

ge-0/0/13.0: 0 routes learned; 16 routes advertised; timeout 180s; update interval 30s
Counter Total Last 5 min Last minute

Updates Sent 31 Hi 2
Triggered Updates Sent 1 0 0
Responses Sent 0 (j 0
Bad Messages 0
---(more)---

Checking RIP Operational State

The slide shows the commands useful in verifying RIP operational status. You might want to start by looking at the RIP
neighbors. The show rip neighbor command allows to check the interfaces enabled for RIP operations as well as RIP
send and receive mode. The RIP-enabled interfaces are designated as neighbors.
The show rip statistics command display general RIP protocol statistics. This command is useful in verifying that RIP
messages are being sent and received.

www.juniper.net Additional IGP Troubleshooting • Appendix A- 7

Advanced Junos Enterprise Routing Troubleshooting

Useful RIP Operational Commands (2 of 4)

• Check RIP is sending and receiving routes:

• RIP sends routes
I user@srx> show route advertisi.ng-protocol rip 10. 222. 0. 33

inet..O: 38 destinations, 54 routes {38 active, 0 holddcwn, 0 hidden)

+ = Ac�ive Route, - = Last Active, * = 3oth

20.20.0.0/24 *[RIP/100] 00:08:56, m�tric 2, tag O

> to 10.222.0.25 via ge-0/0/7.0
[OSPF/150] 01:09:36, metric 2, tag O
> to 10.222.0.22 via ge-0/0/12.0
---(more)---

• RIP receives routes

user@srx> show route receive-protocol rip 10.222.0.25

inet.O: 38 destin.acions, 54 :routes (38 active, G holddown, 0 hidden)

+ = Active Route, - = Last Active, Both

20.20.0.0/24 *[RIP/100] 00:03:29, metric 2, tag O

> to 10.222.0.25 via ge-0/0/7.0
20.20.1.0/24 *[RIP/100] 00:08:29, metric 2, tag O
> to 10.222.0.25 via ge-0/0/7.0
---{more)---

Advertised and Received RIP Routes

Use the show rip advertising-protocol command to view the routes that are advertised out of a RIP interface as
a result of your RIP export policy. The local interface IP address is used as the command argument.
Use show rip receive-protocol to view the routes being received on a RIP interface. This command takes the
neighbor address as its argument.

Appendix A-8 • Additional IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful RIP Operational Commands (3 of 4)

• Check RIP routes in the routing table:

user@srx> show route protocol rip

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

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

20.20.0.0/24 *[RIP/100] 00:12:36, metric 2, tag O

> to 10.222.0.25 via ge-0/0/7.0
20.20.1.0/24 *{RIP/100] 00:12:36, metric 2, tag O
> to 10.222.0.25 via ge-0/0/7.0
--- (more) ---

Checking RIP Routes in the Routing Table

Use the show route protocol rip command to view RIP routes in the routing table.

www.juniper.net Additional IGP Troubleshooting • Appendix A-9

Advanced Junos Enterprise Routing Troubleshooting

Useful RIP Operational Commands (4 of 4)

• For difficult problems, go to debugging:

• Enable traceoptions
{master:0} [edit protocols rip)
use:r@srx# show
traceoptions {
file rip.log;
flag packets;
flag error;

• Monitor log file

lab@exA-1> show log rip.log
Jan 30 22:24:04.991089 Update job done for nbr ge-0/0/13.0 group: de
Jan 30 22:24:11.811727 Preparing to send RIPv2 updates on nbr ge-0/0/7.0, group: de.
Jan 30 22:24:14.748235 received response: sende� 10.222.0.34, command 2, version 2, mbz:
O; 16 routes.
Jan 30 22:24:14.748342 Inserting RIP peer 10. 222.0. 34 in the CLEANUP queue.
Jan 30 22:24:14.745377 20.20.0.0/0xffffffOO: tag 0, nh 0.(. 0 .0, met 2.
Jan 30 22: 24: 14. 748435 20.20.1. 0/0xffffffOO: tag 0, nh 0. C .0.0, met 2.
Jan 30 22:24:14.748470 20.20.2.0/0xffffffOO: tag 0, nh 0.C. 0.0, met "-·
Jan 30 22:24:14.748505 20.20.3.0/0xffffffOO: cag 0, nh 0.C.0.0, met 2.
---{more}---

Debugging RIP
To perform debugging functions of the RIP routing use the JU NOS traceoptions function. The trace output is sent to a named
log file in /var /log directory.You can define various RIP parameters to trace in the traceoptions configuration.
You can view the log file by using show log filename command or you can monitor the updates in the log file
dynamically with monitor start filename command. Do not forget to stop monitoring when you are done with the
monitor stop command.
The example output on the slide shows a received update message carrying several routes.
Note that you should not normally use traceoptions in a stable production network because the debugging process
consumes additional processing resources.

Appendix A-10 • Additional IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

General RIP Troubleshooting Steps

c:
0
Check configuration ·.;:::;

::::,
'Q.O
;;::
,-����������������---- c:
Check export policy o
O
Enable traceoptions
::,

Check security policies �

�
Check authentication (.)
Check import policy Q)
..c:
Enable traceoptions (.)
Q)
..0
Watch for import policy issues ::::,
0
0

General RIP Troubleshooting Steps

The purpose of the RIP troubleshooting flowchart shown on the slide is to provide a set of high-level steps designed to get
you started with RIP fault analysis.
You generally start troubleshooting RIP by inspecting the RIP operational status at the routers. Check that RIP is enabled on
the router interfaces, monitor RIP statistics for RIP message exchange. Then you check if RIP advertises the routes. If it does
not, you might want to check the export policy configuration.
If RIP does not receive RIP updates this might be a result of a firewall filter or security policy action denying them. Watch also
for authentication mismatch. If you see that RIP updates are being received but the router does not install RIP routes to the
routing table, check the import policy for filtering action.
For difficult problems, you might want to enable traceoptions to debug protocol operations.
If the problem persists it can be related to software problems, in which case you would report the issue to JTAC.

www.juniper.net Additional IGP Troubleshooting • Appendix A-11

Advanced Junos Enterprise Routing Troubleshooting

Agenda: Additional IGP Troubleshooting

• RIP Troubleshooting
7IGP Troubleshooting Case Studies
• IGP Support for 1Pv6

IGP Troubleshooting Case Studies

The slide highlights the topic we discuss next.

Appendix A-12 • Additional IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Case Study: RIP and OSPF Routing Issues

• Topology, symptoms, and relevant information:
• Your IGP network was recently extended by adding a legacy
data center network running RIP_
• You have applied redistribution

=
policies at the network edge but
the testing revealed that RIP

e.
routers cannot reach other IGP
subnets outside of RIP_ 10.2 .OA/30 1.5
.6
• Similarly, the R1 router cannot R4 2110.222.0.20;30 .2

reach the data center subnets_

• The core IGP network
adjacencies are up and running_ RIP

Case Study: RIP and OSPF Routing Issues

This time you are presented with a network topology, reported symptoms and description of a case related to OSPF routing
issues. In this case study your IGP domain was extended by adding a data center network running RIP. You have applied
OSPF-to-RIP and RIP-to-OSPF redistribution policies at R4 and R5 but verification showed that the data center routers cannot
reach subnets outside of RIP. Additionally some of the backbone routers (R1) cannot reach the data center servers.

www.juniper.net Additional IGP Troubleshooting • Appendix A-13

Advanced Junos Enterprise Routing Troubleshooting

Problem with the RIP Routers? (1 of 4)

• Run reachability tests in RIP domain
• Ping
user@RIP> ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
36 bytes from 10.222.0.34:ITime to live exceeded I
Vr HL TOS Len :o Flg orr TTL Pro CKS Src Dst
4 5 00 0054 c619 0 0000 01 01 26f0 10.222.0.25 192.168.1.1
--- (more) ---

• Traceroute
user@RIP> traceroute 192.166.1.1
traceroute to 192.168.1.1 (192.168 .1.1), 30 hops max, 40 byte packets
1 10.222.0.30 (10.222.0.30) 3.394 ms 1. 727 ms 1.557 ms
2 10.222.0.21 (10.222.0.21) 1.807 ms 1.750 ms 1. 727 ms
3 10.222.0.25 (10.222.0.25) 1.699 ms 2.081 ms 1.545 ms
4 10.222.0.30 (10.222.0.30) 1.790 ms 2.010 ms 1.874 ms
5 10.222.0.21 (10.222.0.21) 1. 915 ms 1.947 ms 1.773 ms
--- (more) ---

• Can you spot the issue?

Reachability Tests in the RIP Domain

You begin with checking the remote network reachability in the data center. The ping command on the slide shows that the
packets to 192.168.1.1 cannot reach the destination because their TTL is exceeded. The traceroute command indicates that
the probe packet is circulating between 10.222.0.30, 10.222.0.21, and 10.222.0.25 hops, which is a clear indication of a
routing loop.

Appendix A-14 • Additional IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Problem with the RIP Routers? (2 of 4)

• Check the RIP router routing table
user@RIP> show route 192.168.1.1

inet.O: 23 destinations, 24 routes {23 active, 0 holddown, 0 hidden)

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

0.0.0.0/0 *[RIP/100] 00:19:04, metr�c 2, tag O

> to 10.222.0.30 via ge-0/0/10.0

• Follow the route

• R4 prefers RIP to OSPF
user@RS> show route 192.168.1.1
...
0.0.0.0/0 l*[OSPF/150] 00:16:14, metric 12, tag
> to 10.222.0.21 via ae-0/0/12.0 O I
user@R4> show route 192.168.1.1
...
0.0.0.0/0 l
*[RIP/100] 00:05:23, metric 3, tag 0
> to 10. 222. 0. 25 via oe-0/0/7. 0
[OSPF/150] 00:21:11, metric 11, tag 0
I
> to 10.222.0.5 via ge-0/0/6.0

Monitor the RIP Routes in the Routing Table

You check the route in question in the routing tables of the RIP routers. The show route 192 .168 .1. 1 command output
on the slide shows that the RIP router can reach the destination using the default route.

Following the Path of the Route

Then you examine the routing tables of the next hop routers. Note that R4 and R5 routers are located in the OSPF NSSA
area. The first hop along the path is R5. The show route 192.168.1.1 command at R5 shows that R5 uses the default route
to the destination now learned from OSPF. The next hop of the route is R4.
Inspecting the R4 routing table reveals that R4 also uses the default route to the destination but this time R4 has two
sources of the default route information: OSPF and RIP. R4 prefers the RIP route because of its lower preference. The next
hop for the route is the RIP router.

www.juniper.net Additional IGP Troubleshooting • Appendix A-15

Advanced Junos Enterprise Routing Troubleshooting

Problem with the RIP Routers? (3 of 4}

• Solution
• Make sure that both R4 and R5 do not accept 0/0 from RIP
(edit policy-options] (edit protocols rip]
I user@R4# show user@R�t show
po�icy-statement rip-filter group de {
term 1 { export [ rip-relay ospf-to-rip
from
protocol rip;
I
import rip-filter;!
neighbor ge-0/0/7. i
route-filter 0.0.0.0/0 exact; neighbor ge-0/0/13.0;

then reject;

• Monitor the results

user@R4> show route 192.168.1.1

0.0.0.0/0 *[OSPF/150] 01:59:11, metric 11, tag O

> to 10.222.0.5 via ge-0/0/6.0

Solution: Part 1
The troubleshooting revealed that the routing loop was formed due to the default route redistribution from a protocol with a
higher preference (OSPF external 150) to a protocol with a lower preference (RIP 100) at two routers R4 and R5. One of the
possible solutions to this problem is configuring a RIP import policy filtering the default route from the RIP at R4 and R5.
The slide shows an example of the import policy. You apply the policy and monitor the results. Now R4 shows that it has only
one source of the default route---OSPF.

Appendix A-16 • Additional IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Problem with the RIP Routers? (4 of 4)

• Solution
• Test the RIP router again
user@RIP> ping 192 .168 .1.1
PING 192.168.1.1 (192.165.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=O tt1=63 time=l.429 ms
64 bytes from 192.168.1.1: icmp_seq=l ttl=63 cime= l.333 ms
'C
--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0\ packet loss
round-trip min/avg/max/stddev = 1.333/1.381/1.429/0.048 ms

user@RIP> traceroute 192.168.1.1

traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 40 byte packets
1 10.222.0.30 (10.222.0.30) 2.092 ms 1.775 ms 1.628 ms
2 10.222.0.21 (10.222.0.21) 1.692 ms 1.837 ms 1.625 ms
3 192.168.1.1 (192.168.1.1) 2.054 ms 1.800 ms 2.056 ms

Solution: Part 2
You then run ping and traceroute tests at the RIP router. This time the tests are successful.

www.juniper.net Additional IGP Troubleshooting • Appendix A-17

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R1 Routing (1 of 4)

• Check if the external routes are in the R1 table

useI@Rl> show route 20.20/16

20.20.0.0/24 *!OSPF/150 00:13:41 metric 2 ta O

> to 10.222.0.17 via ge-0/0/1.302
20.20.1.0/24 *[OSPF 1 J 00:13:41, metric ,., tag O
> to 10.222.0.17 via ge-0/0/1.302
---{more}---

• Run reachability tests on R1

user@Rl> ping 20.20.0.1
PING 20.20.0.1 20.20.0.1 : 56 data b tes
36 by"Ces from 10.222.0.17: Destination Net. Unreachable
Vr HL TOS Len ID F g o TTL Pro cks Src Ost
5 00 0054 07af O 0000 40 01 53f6 10.222.0.18 20.20.0.1
---{mere)---

user@Rl> traceroute 20.20.0.1

traceroute to 20.20.0.1 (20.20.0.1), 30 hops max, 40 byte packets
10.222.0.17 (10.222.0.17) 4.522 ms !N 3.400 ms !N 3.581 ms !N

Check the OSPF External Routes at R1

Next you start troubleshooting the Rl router issues. You verify that Rl learned the external routes originated in the RIP
domain. The show route 20. 20/16 command on the slide shows that the routes have been learned. Then you run the
ping test for a destination in the data center. The sample output on the slide shows that Rl receives a notification from the
next hop router that the destination network is unreachable. You also note that the next hop router for this destination is R3.

Appendix A-18 • Additional IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R1 Routing (2 of 4)
• Check the OSPF LSDB
user@R3> show ospf database external
OSPF AS SCOPE link state database
Type ID Adv Rt r Seq Age Opt Cksum Len
Extern 20.20.0.0 110.222.1.31 Ox80000017 512 Ox22 Oxbcd9 36
Extern 20.20 .1.0 10.222.1.3 Ox80000017 512 Ox22 Oxble3 36
Extern 20.20.2.0 10.222.1.3 Ox80000017 512 Ox22 Oxa6ed 36
--- (more) ---

• Check the OSPF external routes at R3

• OSPF learned the RIP routes
user@R3> show ospf route extern
Topology default Route Table:

Prefix Path Route NH Metric NextHop Nexthop

Type Type Type Incerface Address/LSP
20.20.0.0/24 Ext2 Network IP 2 gs-0/0/6.0 10.222.0.14
20.20.1.0/24 Ext2 Network IP 2 ge-0/0/6.0 10.222.0.14
20.20.2.0/24 Ext2 Network IP 2 ge-0/0/6.0 10.222.0.14
---(more)---

Check the OSPF LSDB for External LSAs

You then check the OSPF database for the OSPF external routes received in Type 5 External LSAs. The show ospf
database external command on the slide shows that R3 is the source of the external LSAs.

Check the OSPF Routes at R3

You then check that OSPF SPF calculated the path to the external routes. The sample output of the show ospf route
extern on the slide shows that the SPF at R3 provides the routes for the external destinations.

www.juniper.net Additional IGP Troubleshooting • Appendix A-19

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R1 Routing (3 of 4)

• What about R3 routing table?

I user@R3> show route 20.20/16

• No routes
• Any ideas?

Check the Routing Table

Next you check the contents of the routing table at R3 for the external routes to the data center networks. The result of the
show route command shows that R3 routing table does not have these routes.

Appendix A-20 • Additional IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting R1 Routing (4 of 4)

• An incorrect import policy is applied at R3 OSPF

• Prevents SPF calculated routes to come up to the routing
table
user@R3> show configuration protocols ospf
import ospf-impor�-filter;
--- (more) ---

user@R3> show po1icy ospf-il!l:port-filter

Policy ospf-impcrt -filter:
Term 1:
f:com
route filter:
20.20.0.0/16 orlonger
then reject

• Solution:
• Modify or remove the policy

Incorrect Import Policy

Given the collected information you can conclude that since R3 SPF has provided the routes but the routing table does not
receive them this might be a misconfigured import policy action.

Solution
You must either adjust the import policy settings or completely remove the policy depending on your further goals.

www.juniper.net Additional IGP Troubleshooting • Appendix A-21

Advanced Junos Enterprise Routing Troubleshooting

Case Study: RIP and IS·IS Routing Issues

• Topology, symptoms, and relevant information:
• Your IGP network was recently extended by adding a legacy
data center network running RIP.
• You have applied redistribution policies at the network edge
but the testing revealed that Rl
the core IGP routers use a
suboptimal path to reach the
data center subnets.
• R5's loopback disappeared from I
'I
the routing tables on all routers. ==-r--------n:u-z::'2'.Ql2/301
)
• Adjacency verification proved
that all IS-IS adjacencies are up
and running_ RIP

Case Study: RIP and IS-IS Routing Issues

The slide presents a network topology, reported symptoms and description of a case related to IS-IS routing issues. In this
case study your IGP domain was extended by adding a data center network running RIP. You have applied redistribution
policies at R4 and R5 but verification showed that the IS-IS routers use suboptimal path to reach the data center subnets. At
the same time you notice that R5 loopback address are no longer reachable by other routers. You have verified all IS-IS
adjacencies and ensured that they are up.

Appendix A-22 • Additional IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Suboptimal Routing (1 of 3)
• Test the path to the RIP domain
user@R2> traceroute 20.20.0.1
traceroute to 20.20.0.1 (20.20.0.1), 30 hops max, 40 byte packets
1 10.222.0.2 (10.222.0.2) 6.464 ms 7.586 ms 1.613 ms
2 10.222.0.14 (10.222.0.14) 1.893 ms 2.749 ms 1.846 ms
3 20.20.0.1 (20.20.0.1) 2.240 ms 2.169 ms 2.163 ms

• Check the LSDB

• R4 signals overload
user@R2> show isis database level 2
IS-IS level 2 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
R2.00-00 Ox3d Oxfafa 388 Ll L2
R3.00-00 Ox23 Ox4d9e 784 Ll L2
R4.00-00 Ox35 Oxld4d 486 Ll L2 Overload I
rt�.uu-uu '..lXL.I: VXDba J.VSG LJ. 1,,:
4 LSPs

Check the Path to the RIP Domain

You begin troubleshooting by testing the route the IS-IS routers use to reach the data center subnets with the traceroute
command. The output on the slide shows that R2 uses a route through R3 and R5, whereas a shorter path is available.

Check the IS-IS Database

You use the show isis database command to briefly overview the Level 2 LSPs. The output of this command indicates
that R4 router signals that it is overloaded.

www.juniper.net Additional IGP Troubleshooting • Appendix A-23

Advanced Junos Enterprise Routing Troubleshooting

Suboptimal Routing (2 of 3)

• Check IS-IS LSDB for external routes

• R5 is the only router advertising the RIP routes
user@R2> show isis database level 2 R4 detail I match 20.20

user@R2> show isis database level 2 RS detail I match 20.20

I
___
IP prefix: 20.20.D.0/24 Metric: 2 External Up
IP prefix: 20.20.1.0/24 Metric: 2 External Up
---(more)---
..____ ·�
• Inspect the R4 settings
• No administrative overload settings
user@R4> show configuration protocols isis I match overload

• Looking for export however provides the vital clue

I
user@R4> show configuration protocols isis I match export
export rip-to-isis;
level 2 prefix-export-limit 10;

Check the IS-IS Externals Routes in the Database

You then decide to ensure that the only source of the data center routes in the I S I-S domain is R5. You use the show isis
detail command and look up the RIP routes.

Examine the R4 IS-IS Settings

You proceed by checking the R4 IS-IS setting for overload configuration. In this scenario the overload setting was not
configured. So the next option to check for an overloaded router is its IS-IS export policies. By inspecting the IS-IS
configuration you find out that R4 has an export policy applied. Besides, there is a prefix export limit for only 10 external
routes configured for Level 2.

Appendix A-24 • Additional IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Suboptimal Routing (3 of 3)
• Check the volume of the RIP routes
user@R4> show route sul?lmary I match RIP
RIP: 17 routes, 17 active

• Solution:
• Adjust the prefix export limit setting

Check the RIP Routes at R4

You then use the show route summary command and review the amount of RIP routes in the R4 routing table. The
output shows that R4 has learned 17 RIP routes.

Solution
The prefix export limit threshold is lower than the amount of external routes the R4 IS-IS export policy redistributes. So you
adjust the prefix export limit setting or modify you export policy settings depending on your further goals.

www.juniper.net Additional IGP Troubleshooting • Appendix A-25

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting RS Reachability (1 of 3)
• Test the R5 reachability
user@R2> ping 10.222.1.5
PING 10.222.1.5 (10.222.1.5): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
·c
--- 10.222.1.5 ping statistics
2 packets transmitted, 0 packets received, 100% packet loss

• Look up R5 in the IS-IS LSDB

user@R2> show isis database level 2
IS-IS level 2 link-state database:
LSP IO Sequence Checksum Lifetime Attributes
R2.00-00 Ox43 OxeeOl 965 Ll L2
R3.00-00 Ox28 Ox43a3 459 Ll L2
R4.00-00 Ox3c Ox2923 1021 Ll L2
RS.00-00 Ox34 Oxacac 668 Ll L2 I
q LSPs

Check the RS Loopback Reachability

Next you proceed to troubleshooting the R5 loopback reachability. The ping command on the slide shows that R2 does not
have a route to the R5 loopback.

Overview the IS-IS Database

You then check the IS-IS database to see if R5 LSPs present. The output of the show isis database command shows
that R5 does generate the LSP and the other routers install this LSP in the LSDB.

Appendix A-26 • Additional IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting RS Reachability (2 of 3)

• Check the R5 subnets in the LSDB

user@RS> show isis database level 2 RS.00 detail I match 10.222

• Check interfaces are enabled in IS-IS at R5

user@RS> show isis interface
IS-IS interface database:
Interface L CirlD Level 1 DR Level 2 DR Ll/L2 Metric
ge-0/0/12.0 1 Oxl Point to Point Disabled 10/10
Oxl Disabled Point to Point 10/10
I
ge-0/0/6.0 2
loO.O O Oxl Passive Disabled 010

• Perhaps it is in the Level 1 LSDB?

• The internal IP subnets do not appear in either Level 1 or
Level 2 database
user@RS> show isis database level 1 R5.00 detail I match 10.222

Examine the IS-IS Level 2 Database

You then examine the IS-IS Level 2 LSDB for the routes advertised by R5 in the R5 LSP. The output reveals that R5 does not
advertise any of its directly attached subnets.

Check the IS-IS Interfaces

Use the show isis interface command to check the I S -IS-enabled interfaces. The output indicates that the R5
physical interfaces as well as its loopback are configured for IS-IS.

Examine the IS-IS Level 1 Database

You then examine the IS-IS Level 1 LSDB for the routes advertised by R5. The output reveals that R5 does not advertise any
of its directly attached subnets to the Level 1 either.

www.juniper.net Additional IGP Troubleshooting • Appendix A-27

Advanced Junos Enterprise Routin g Troubleshooting

Troubleshooting RS Reachability (3 of 3}
• Watch for export policy issues
rip-to-isis;
pre ix export-limit 100;

I user@RS> show policy rip-to-isis

Policy rip-tc-isis:
Term l:
from proto RIP
then acce t:
Term 2:
then re'ect

• Solution:
• Delete the second term in the export policy

ml "!;(•
�[.J8JP€f Worldwide Education Services I ,.._;un!J)ernet I 2B
-.-·, """"'f I
,

Examine the Export Policies

You recall that the default IS-IS export policy accepts the direct routes on all IS-IS-enabled interfaces but if you apply an
incorrect export policy this can result in rejecting the direct routes. You check the IS-IS export policy configuration and find
that this policy indeed rejects the direct routes in its second term.

Solution
You then delete the second term in the export policy.

Appendix A-28 • Additional IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Agenda: Additional IGP Troubleshooting

• RIP Troubleshooting
• IGP Troubleshooting Case Studies
7IGP Support for 1Pv6

IGP Support for 1Pv6

The slide highlights the topic we discuss next.

www.juniper.net Additional IGP Troubleshooting • Appendix A-29

Advanced Junos Enterprise Routing Troubleshooting

OSPFv3
• 1Pv6: OSPFv3
• Fundamental mechanics of OSPF unchanged
• Separate router reachability and prefix reachability LSAs
• Relies on IPSec for authentication
• Supports both 1Pv6 and 1Pv4 realms
• Separate configuration stanza

1Pv6 and OSPFv3

OSPF version 3 is a separate protocol designed specially to support 1Pv6 routing. OSPFv3 maintains the fundamental
mechanisms of OSPF. including LSA flooding scopes. areas. DR election. stub areas. NSSAs. and so on. The main differences
in OSPFv3 are as follows:
OSPFv3 establishes a single adjacency per link even if multiple 1Pv6 subnets exist;
Addressing semantics were removed from OSPF headers. and no prefix information is carried in the router LSAs
or network LSAs, which makes OSPFv3 protocol independent. For instance, OSPFv3 supports the 1Pv4 routing
realm;
OSPF packets are sent using the 1Pv6 link-local addressing, and these link-local addresses are also used as
next-hop information during forwarding;
Authentication was removed because it becomes an 1Pv6 layer task; and
The options field was expanded from 8 bits to 24 bits.

Appendix A-30 • Additional IGP Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

IS·IS Support for 1Pv6

• 1Pv6 native support

• No special configuration required

1Pv6 Native Support

IS-IS PDUs use TLV encoding as the basic structure for all routing information. Particularly each individual LSP contains
multiple TLV segments that describe the originating router adjacencies and IP subnets. Primary TLVs used by LSPs include
the following:
Area Addresses TLV (Type 1): Carries a list of all areas of the originating router;
IS Neighbors TLV (Type 2): Describes the originating router's links to neighboring routers and the cost to those
neighbors;
Protocols Supported TLV (Type 129): Carries a list of supported protocols (JUNOS supports IP and 1Pv6 by
default);
IP Interface Address TLV (Type 132) : Carries the IP addresses of the IS-IS interfaces on the originating router;
IP Internal Reachability TLV (Type 128): Lists the IP prefixes directly connected to the originating router, and
their associated metrics;
IP External Reachability TLV (Type 130): Lists the IP prefixes external to the IS-IS domain, and their associated
metrics;
IS-IS natively supports both 1Pv4 and 1Pv6 so no special configuration is required. Note that there is a caveat in running
dual-stack IS-IS. If you fail to configure both families on a router interface IS-IS will still be able to establish adjacency having
only 1Pv4 family. Despite the adjacency is established IS-IS will not be able to use the link for 1Pv6 forwarding.

www.juniper.net Additional IGP Troubleshooting • Appendix A-31

Advanced Junos Enterprise Routing Troubleshooting

Summary
• In this content, we:
• Listed common commands used to troubleshoot and verify
the RIP routing protocol
• Isolated different IGP issues
• Explained IGP support for 1Pv6

We Discussed:
Common commands used to troubleshoot and verify the RIP routing protocol;
Isolating different RIP issues; and
IGP support for 1Pv6.

Appendix A-32 • Additional IGP Troubleshooting www.juniper.net

 Advanced Ju nos Enterprise Routing Troubleshooting

Review Questions
1. Which command is used to view the routes
advertised out of a RIP interface as a result of your
RIP export policy?
2. Which command output displays that an IS-IS
Level 2 router has an overload bit set?
3. What configuration is required for IS-IS to support
1Pv6?

Review Questions
1.

2.

3.

www.juniper.net Additional IGP Troubleshooting • Appendix A-33

Advanced Junos Enterprise Routing Troubleshooting

Answers to Review Questions

l.

You can use the show rip advertising-protocol command to view the routes that arc advertised out of a RIP interface as
a result of your RIP export policy.

2.
You can use the show isis database command to determine that an IS-IS Level 2 router is overloaded.

3.
IS-IS natively supports both 1Pv4 and 1Pv6 so no special configuration is reguired.

Appendix A-34 • Additional IGP Troubleshooting www.juniper.net

Advanced Junos Enterprise Routing
Troubleshooting

Appendix B: Additional Case Studies

Advanced Junos Enterprise Routing Troubleshooting

Objectives
• After successfully completing this content, you will be
able to:
• Isolate different BGP issues
• Isolate different routing policy issues

We Will Discuss:
Isolating different BGP issues; and
Isolating different routing policy issues.

Appendix B-2 • Additional Case Studies www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Agenda: Additional Case Studies

7 BG P Case Study
• Policy Case Study

BGP Case Study

The slide lists the topics we will discuss. We discuss the highlighted topic first.

www.juniper.net Additional Case Studies • Appendix B-3

Advanced Junos Enterprise Routing Troubleshooting

BGP Case Study: Routing Issues

• Topology, symptoms, and relevant information:
• Your company's branch office routers successfully
established both IBGP and EBGP peerings_
• You start monitoring BGP routing flow and detect that R1
forwards packets for ISP B subnets through ISP A, and R2
forwards packets for ISP A subnets through ISP 8-
• To verify redundancy, you temporarily disable one of the
uplinks and note that the Internet bound traffic does not fail
over to a backup ISP_
• Additionally, _1
_ ---- ___ _ '
Ri RR
2
( .RR R2 •
. 2 I ·1
· ;1_ -- ---"'�

_ll
R1 does not ISPA
. 1022200/30 · 102f54013�,
isPs
.. ,
receive I Pv6 AS 100
.s .......... _...... 13 # ..
..

10.222 t.12130 .
AS 200
routes from .... ,, 14
,
.e . /AS 65000',. ·• I I

, ________
IS p A_ l R3 ;21 R4
.2�
I
10.222.0.20/30
.,,.,,

BGP Case Study: Routing Issues

The slide presents a network topology, reported symptoms and description of a case related to 8GP routing issues. In this
case study you are troubleshooting the company's branch office 8GP network. After 8GP sessions were established
successfully you began to verify 8GP routing. The verification showed that Rl AS8R forwards packets for ISP 8 subnets to ISP
A and similarly R2 AS8R forwards packets for ISP A subnets to ISP 8. If you disable one of the uplinks to either ISP A or ISP 8
to check the routing redundancy you see that the Internet traffic does not fail over to the backup ISP.
You also noticed that Rl AS8R does not receive 1Pv6 routes from ISP A, which are being advertised.

Appendix 8-4 • Additional Case Studies www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting 1Pv4 BGP Routing (1 of 4)

• Check the R1 and R2 BGP routes
• ISP B subnets in the R1 routing table
user@Rl> show route protocol bgp 10.2/16

10.2.100.0/24 *[BGP/170] 18:15:37, localpref 100, from 10.222.1.3

ath: 200 I

10. 2. 101. 0/24

AS path: 200 I
> to 10.1.254.1 via ge-0/0/4.303

• ISP A subnets in the R2 routing table

user@R2> show route protocol bgp 10.1/16

10.1.100.0/24 *[BGP/170] 03:31:14, localpref 100, from 10.222.1.2

10 .1.101.0/24
AS path: 100 I
> to 10.2.254.1 via ge-0/0/4.304

Check the BGP Routes at R1 and R2

You proceed to troubleshooting BGP routing. First you decide to check the BGP routes in the R1 and R2 routing tables for ISP
Band ISP A routes respectively. You use the show route protocol bgp command. The output of the command shows
that R1 has the ISP A routes and R2 has the ISP A routes in their routing tables but R1 uses its connection to ISP A as the
forwarding next hop for the ISP Broutes whereas R2 uses its connection to ISP Bas the forwarding next hop for the ISP A
routes.

www.juniper.net Additional Case Studies • Appendix B-5

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting 1Pv4 BGP Routing (2 of 4)

• Check the routes' details

user@Rl> show route 10.2.100/24 detail

inet.0: 52 destinations, 53 routes (52 active, 0 holddown, 1 hidden)

10.2.100.0/24 (1 entry, 1 announced)
'BGP Preference: 170/-101
Next hop type: Indirect
Address: Ox15eda7c
Next-hoo reference count: 24
rsource: 10.222.1.31
Next hop type: Router, Next hop index: 607
Next hop: 10.1.254.1 via ge-0/0/4.303, selected
!Protocol next hop: 10.2.254.1!
---(more)---

user@Rl> show route 10.2.254.1

inet.O: 52 destinations, 53 routes (52 active, 0 holddown, 1 hidden)

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

0.0.0.0/0 *[BGP/170] 03:44:23, localpref 100

AS path: 100 I
> to 10.1.254.1 via ge-0/0/4.303

Check the BGP Route Details

Use the detail option with the show route command to review the ISP routes detailed information. The output of the
command shows that R1 receives the ISP B routes from R2 with the BGP next hop of these routes set to the ISP B EBGP peer
address. Vise versa R2 receives the ISP A routes from R1 with the BGP next hop of those routes set to the ISP A EBGP peer
address.
You then look up the BGP next hop address in the routing table and find out that the ASBRs resolve the BGP next hop using
the default route they receive from their directly connected ISPs.

Appendix B-6 • Additional Case Studies www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting 1Pv4 BGP Routing (3 of 4)

• You seem to have resolved two issues with one fix

• R2 does not change the BGP next hop while advertising ISP
B routes to R1
• There is only one source for 0/0 at R1 (ISP A). but we expect
it to come from ISP B through R2 as well
• Check if 0/0 is being received from R2
user@Rl> show route receive-protocol bgp 10.222.1.3 0/0 exact

user@Rl> show route receive-protocol bgp 10.222.1.3 0/0 exact hidden

inet.O: 52 destinations, 53 routes {52 active, 0 holdda,.-m, 1 hidden)

Prefix MED Lclpref AS path
I
Nexthoo
0.0.0.010 10.2.2s4.1 I 100 200 I

• R1 cannot accept 0/0 from R2 because of recursive routing

failure

Collected Information Analysis

You find that both R1 and R2 do not change the BGP next hop attribute for the external routes they receive from their
upstream ISPs. Both of the routers are only receiving the default route from their directly connected ISP.
You then check why the default route is not being received by the ASBRs from the IBGP peers. You use the show route
receive-protocol bgp command. The command output indicates that the default route received from the IBGP peers
is hidden. The ASBRs do not accept the default route because the route BGP next hop is resolved using the same default
route.

www.juniper.net Additional Case Studies • Appendix B- 7

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting 1Pv4 BGP Routing (4 of 4)

• Solution:
• Make sure that IBGP receivers can resolve BGP next hop
using a specific route
• For example, next-hop-self, IGP passive, and so forth

��lilll!Jilll) ""ft Worldwide Education Services wwwJuntpernet I a

���¥;£¥ I

Solution
You must ensure that the BGP next hop is reachable at both R1 and R2 with a specific route. For that you can either apply a
next-hop-self policy or configure IGP passive interfaces on the connections to the ISP.

Appendix B-8 • Additional Case Studies www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting 1Pv6 BGP Routing (1 of 3)

• Check families negotiated for the EBGP session at R1
user@Rl> show bgp neighbor 10 .1. 254 .1 I find "NLRI _for this session"
NI.RI for this session: inet-unicast inet6-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
---(more)---

• The EBGP neighbor advertises the 1Pv6 routes

user@ISP-A> show route advertising-protocol bgp 10.1.254.2 table inet6.0

inet6.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

Prefix Nexthop MED Lclpref AS path
* fdcd:l:a: :/48 Self I

• But R1 does not receive any

user@Rl> show route receive-protocol bgp 10.1.254.1 table inet6.0

Check the BGP 1Pv6 Family Support at R1

You proceed to checking the EBGP neighbor details at Rl to ensure that the neighbors agreed on using both 1Pv4 and 1Pv6
protocol families. The output of the show bgp neighbor command shows that the two neighbors indeed agreed on
using both families.

Check the 1Pv6 Routes

You ask your ISP to check if they advertise the 1Pv6 routes. The show route advertising-protocol bgp command
issued at the ISP router shows that the router advertises the 1Pv6 routes. You then use the show route
received-protocol bgp command to check if you receive the routes. The command output indicates that you do not
receive any routes.

www.juniper.net Additional Case Studies • Appendix B-9

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting 1Pv8 BGP Routing (2 of 3)

• Enable traceoptions and watch for BGP update
messages coming in
• 1Pv4 BGP uses 1Pv4-mapped 1Pv6 address for the BGP next
hop for 1Pv6 prefixes
user@Rl> show log bgp.log

Mar 19 05:52:43.576090 BGP RECV message type 2 (Update) length 68

Mar 19 05:52:48.575997 BGP RECV 10.1.254.1+179 -> 10.1.254.2+54738

Mar 19 OS:52:48.576143 BGP RECV Update PDU length 68

Mar 19 05:52:48.576212 BGP RECV flags Ox40 code Origin(l): IGP
Mar 19 05:52:48.576277 BGP RECV flags Ox40 code F.SPath (2) length 6: 100
Mar 19 05:52:48.576348 BGP RECV flags Ox90 code MP reach(l4): AFI/SAFI 2/1
Mar 19 05:52:48.576419 BGP RECV nhop ::ffff:10.1.254.1 len 16

Mar 19 05:52:48.577588 bgp_nexthop_sanity: peer 10.1.254.1 (External �..S 100} next hop
Mar 19 05:52:48.576506 BGP RECV fdcd:l:a: :/48

: :ffff:10.1.254.1 unexpectedly remote, ignoring routes in this update

""lar 19 05:52:48.577723 bgp_rcv_nlri: fdcd:l:a: :/48
""lar 19 05:52:48.577798 bgp_rcv_nlri: Uninstall no rou�e fdcd:l:a::/48

C201<1J-lletworle,ln<.Mn.,,..;....,_. ,°
���t!Jnjp� Worldwide Education Services www;un,pornet I 10
��JI. I

Debugging BGP
You then enable traceoption to debug BGP protocol operations. You look up BGP update messages in the trace log file. The
log reveals that R1 does receive the 1Pv6 routes and the BGP next hop of the routes is the 1Pv4-mapped 1Pv6 address.

Appendix B-10 • Additional Case Studies www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting 1Pv6 BGP Routing (3 of 3)

• Check the ISP facing interface
user@Rl> show interfaces terse ge-0/0/4.303

I
Interface Admin Link Proto Local Remote

I
ge-0/0/4.303 up up �in;;,; ;.; a.,,...-..a ;,.;O,.;.. ,;;.1.;.;. ;.;
e t l 2 Sa.,;4.;.. �2/""3:-'0�-- ---,
inet6 fdcd:1:a:O:ffff::2/126 :-,-:":""!'
fe80::b2c6:9a01:2f73:27S4/64

• Solution:
• Configure 1Pv4-mapped 1Pv6 address on the interface or
• Enable accept-remote-nexthop and replace the BGP
next hop with the 1Pv6 address of the connected neighbor
with an import policy

Check the 1Pv6 Address

You check the 1Pv6 address on the ISP-facing interface. The output of the show interface terse command shows that
the interface is configured with a regular 1Pv6 address as well as it has an automatically generated link-local address. The
BGP 1Pv6 next hop is not reachable at Rl.

Solution
You can configure an 1Pv4-mapped 1Pv6 address on the upstream interface to ensure that the router can reach the BGP 1Pv6
next hop, or you can configure Rl to accept remote next hops with the accept-remote-nexthop knob and apply an
import policy replacing the BGP next hop attribute with the EBGP peer 1Pv6 address.

www.juniper.net Additional Case Studies • Appendix B-11

Advanced Junos Enterprise Routing Troubleshooting

Agenda: Additional Case Studies

• BGP Case Study
�Policy Case Study

Policy Case Study

The slide highlights the topic we discuss next.

Appendix B-12 • Additional Case Studies www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Policy Case Study: Advertising Routes

• Topology, symptoms, and relevant information:
• While deploying BGP in the enterprise new branch office you implemented
several BGP routing policies to control precisely the BGP advertisements.
Your goals were to:
• Enforce per-prefix load-sharing for local summary routes
• Suppress local specific routes
• Provide backup transit service only for the routes originated in the neigl1boring ISP As·s
• Soon after the policies were applied testing revealed that none of the goals
is achieved
�--------

I
-�o....
10.1/16 J AS 100
ISPA
' ( '··--------"'<i>'' '
�;_7_;s'pi :io
10.2f20 4/30 I
I .5
., 1022200;30
',,
"-,., .-"
;

I
,�' .1311
102fs4:0/3�

f 1.2/30
ISPB
...-'
AS 200 110.2/16 I
----.I l
!
t 10.222..

1 10 I
,,.,Ji(..._
AS 65000 ....
I .6 ,._ ',, .14
.222/16 ,! ,.
.,,

R3 .,1 R4

________
.,.

1::::· ====1·I 'l........

20.20116
.2L

10.222.0.20/30 J
/

Policy Case Study: Advertising Routes

The slide presents a network topology, reported symptoms and description of a case related to export policy issues. In this
case study your company deployed BGP in a new branch office. You were asked to implement BGP routing policies to ensure
that only certain routes are advertised to the upstream ISPs. Your task is to enforce per-prefix load-sharing of inbound traffic.
You must advertise a summary route representing your autonomous system routes and suppress the more specific routes.
You also need to provide backup transit service for the routes originated in the neighboring ISP autonomous systems. When
you activated the configuration with the export policies applied for the first time you found that none of the tasks have been
accomplished.

www.juniper.net Additional Case Studies • Appendix B-13

Advanced Junos Enterprise Routing Troubleshooting

Export Policy Troubleshooting (1. of 6)

• Check the BGP advertised routes

• No routes
user@R2> show route advertising-protocol bgp 10.2.254.1

• Check the export policies

user@R2> show bgp group as200
Group Type: External Local AS: 65000

__
Name: as200 Index: Flags: <Export Eval>
Export: [ (ent-agg-export && ent-bgp-export) JI
(more)
...._____ �

user@R2> show policy ent-agg-export

Policy ent-agg-export:
Terra 1:
from proto Aggregate
then accept
Term 2:
then reject

Check the Advertised Routes

You begin with checking the routes advertised to the EBGP neighbors. The show route advertising-protocol bgp
command shows that no routes are being advertised.

Check the Export Policies

You decide to check your BGP export policies. You use the show bgp group command to view the applied export policies.
The command output on the slide indicates that a policy logical AND expression is applied to the EBGP peer group.
You inspect the first policy in the expression, the policy named ent-agg-export, which accepts aggregate routes only.

Appendix B-14 • Additional Case Studies www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Export Policy Troubleshooting (2 of 8)

• Check the export policies
user@R2> show policy ent-bgp-export
Policy ent-bgp-export:
Term 1:
from prate BGP
aspath aslOO
then accept
Term 2:
then reject

• Check the aggregate routes

user@R2> show route protocol aggregate terse

A Destination P Prf Metric 1 Metric 2 Next hop AS path

• 10.222.128.0/17 A 130 Reject
• 20.20.128.0/17 A 130 Reject

• Why does the policy expression not work?

Check the Export Policies (contd.)

You inspect the second policy in the expression, the policy named ent-bgp-export. This policy accepts only BGP routes
with the AS path matching AS path regex named asl 00.

Check Aggregate Routes

You proceed to checking the aggregate routes in the routing table. The output of the show route protocol
aggregate command displays active aggregate routes in the routing table.
After checking over the policy expression again, you determine that the expression has a logic flaw. If an aggregate route
matches in the first policy, it will never match in the second. Vise versa, a BGP route cannot match in the first policy. So this
expression will not match any BGP routes.

www.juniper.net Additional Case Studies • Appendix B-15

Advanced Junos Enterprise Routing Troubleshooting

Export Policy Troubleshooting (3 of 8)

• Correct the expression logic
user@R2> show bgp group as200
Group Type: External Local AS: 65000
Name: as200 Index: 2 Flags: <Export Eval>
Expert: [ (ent-agg-export I I ent-bgp-export) ll
,mcreJ

• Check the BGP advertised routes again

• Looks better but we do not advertise ISP A routes yet
user@R2> show route advertising-protocol bgp 10.2.254.1

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

__
Pz:efix Next.hop MED Lclpref AS path
• 10.222.12e.0/17 self 1
* 20.20.128.0/17 Self I
.....____ �

Correct the Policy Expression

You change the policy expression from logical AND to logical OR. Now if an aggregate route matches in the first policy it
guarantees the accept result for the whole expression. Vise versa if a BGP route does not match in the first policy it will match in
the second so the second policy guarantees the expression accept result.

Check the Advertised Routes

You check the advertised routes again and now you see that the aggregate routes are being advertised but the BGP routes
are not.

Appendix B-16 • Additional Case Studies www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Export Policy Troubleshooting (4 of 6)

• Check the ent-bgp-export policy details
user@R2> show policy ent-bgp-export
Policy ent-bgp-export:
Term 1:
from proto BGP
aspath aslOO
then acc�pt

user@R2> show con.figuration polic..-y-options I match oAas-path as100"

as-path aslOO 100;

• Check the ISP A routes matching the AS path 100

user@R2> show route protocol bgp 10.1/16 aspath-regex 100

user@R2> show route protocol bgp 10.1/16 terse

A Destination
* 10.1.100.0/24
• 10 .1.101. 0/24
P Prf
B 170
B 170
Metric 1
100
100
Metric Next hop
>10.222.0.1
>Hi.222.0.1
AS path
100 100 100 I
100 100 100 I
I
---(more)---

Check the BGP Export Policy Details

You previously noticed that one of the match conditions of the ent -bgp-export policy was the AS path. You check the AS
path regex configuration.

Check the ISP A Routes in the Routing Table

You then use the show route protocol bgp command with the AS path regex filter. The output of the command does
not show any routes.
You check all ISP A routes in the routing table by prefix range. This time the command output displays the routes but you
realize that the AS path of the routes was prepended several times and the AS path does not match the regex you
configured.

www.juniper.net Additional Case Studies • Appendix B-17

Advanced Junos Enterprise Routing Troubleshooting

Export Policy Troubleshooting (5 of 8)

• Modify the AS path regex used in the policy

user@R2> show confi ration policy-options I match 11 "as-pat.h as100 11
as-path aslOD 100+;

• Check the BGP advertised routes again

• One element is still missing
user@R2> show route advertising-protocol bgp 10.2.254.1

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

Prefix Nexthop r,,'J_ED Lclpref AS path
* 10.1.100.0/24 Self 100 100 100

* 10.1.107.0/2� Self 100 100 100 I

• 10.222.126.0/1• Self
* 20.20.128.0/17 I Self

• Can you spot the issue?

Modify the AS Path Regex

You modify the AS path regex to ensure that it matches the ISP A routes.

Check the Advertised Routes

You check the advertised routes again. This time both the aggregate routes and the ISP A BGP routes are being advertised.
However the mission is not yet accomplished. You notice that if one of the upstream connections go down half of your
autonomous system routes will become unreachable in the Internet.

Appendix B-18 • Additional Case Studies www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Export Policy Troubleshooting (6 of 6)

• Configure additional aggregate routes to provide
redundancy
user@R2> show route protocol aggregate terse
...
A Destination p Prf Metric 1 Metric 2 Next hop AS path
10.222.0.0/16 IA 130 Reject
• J.v.,:,:,:.Ue.u,.u A 130 Reject
20.20.0.0/16
GV. L..V. L.i.V . V/ .L
IA
A
130
130
Reject
Reject

user@R2> show route advertising-protocol bgp 10.2.254.1

inet.O: 67 destina�ions, 84 routes (67 active, 0 holddown, 0 hidden)

Prefix Nexthcp MED Lclpref AS path

..
* 10 .1.100.0/24 Self 100 100 100 I

.10 .1.107. 0/24 Self 100 100 100 I

.
10.222.0.0/16 Self I
10.222.128.0/17 Self
* 20.20.0.0/16 Self
20.20.128.0/17 Self I

Configure Additional Aggregate Route

You configure summary aggregate routes representing the whole range of your autonomous system routes.
You check the advertised routes again and this time ensure that all the tasks are solved.

www.juniper.net Additional Case Studies • Appendix B-19

Advanced Junos Enterprise Routing Troubleshooting

Summary
• In this content, we:
• Isolated different BGP issues
• Isolated different routing policy issues

We Discussed:
Isolating different BGP issues; and
Troubleshooting different routing policy issues.

Appendix 8-20 • Additional Case Studies www.juniper.net

Advanced Junos Enterprise Routing
Troubleshooting

Appendix C: SRX Hardware Troubleshooting

Advanced Ju nos Enterprise Routing Troubleshooting

Objectives
• After successfully completing this content, you will be
able to:
• List the general chassis components
• Identify different methods for troubleshooting major chassis
components
• Troubleshoot redundant Routing Engine and Control Board
communication

We Will Discuss:
A list the general chassis components;
Identifying different methods for troubleshooting major chassis components; and
Troubleshooting redundant Routing Engine and Control Board communication.

Appendix C-2 • SRX Hardware Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Agenda: SRX Hardware Troubleshooting

7General Chassis Components
• Redundancy
• Hardware Case Study

General Chassis Components

The slide lists the topics we will discuss. We discuss the highlighted topic first.

www.juniper.net SRX Hardware Troubleshooting • Appendix C-3

Advanced Junos Enterprise Routing Troubleshooting

The Juniper Architecture

• Every platform is different, but Juniper Networks
devices typically include these components:
• Host subsystem: Composed of the Routing Engine and
supporting hardware
• PFE boards: Where actual traffic processing takes place
• Midplane: Provides physical connection between different
boards. Often passive. and as such not likely to fail-except
when incorrectly inserting new boards (bent pins)
• Power supplies and cooling subsystems

C 201uu,,.,.. Netwo.ks, ""'-"" rii,ds �-

•
��¥:1driu::>er •
�;;'.,.,���f��
Worldwide Education Services
I
wwwjumpor.net I 4

The Juniper Architecture

Juniper platforms are very diverse, but most of them tend to follow a similar architecture, which includes the following
components:
The host subsystem: This component includes the Routing Engine and its supporting hardware. The Routing
Engine hosts the Junos operating system, manages the router, and runs routing protocols. On platforms with
redundant Routing Engines, the host subsystem contains hardware to handle Routing Engine mastership and
switchover.
The Packet Forwarding Engine boards: As the name implies, this component is where actual forwarding takes
place.
The midp/ane: This component provides physical connection between different boards. Most platform have a
passive midplane, so typically failures are only due to bent pins or other mechanical problems, often caused by
inserting a board without proper care.
Power and cooling subsystems: This component includes power supplies, fan trays, and air filters. These crucial
systems are often neglected, but are absolutely vital for the device's correct operation. Proper cooling and
power can prolong the life of a device and significantly reduce its failure rate. The cooling system is typically very
modular and is designed for ease of maintenance. It also required periodic maintenance (cleaning air filters), at
least on a yearly basis. The hardware guide for each specific platforms lists the suggested maintenance
schedule and actions.

Appendix C-4 • SRX Hardware Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

SRX1400 and SRX3000 Series Hardware

• SRX1400 and SRX3000 Series components overview

• Common form-factor module (CFM) cards
• 1/0 cards (IOCs)
• Network Processing 1/0 Cards (NP-IOCs)
• Services Processing Cards (SPCs)
• Network Processing Cards (NPCs)
• Non common form-factor module cards
• Routing Engine (RE)
• SRX Clustering Module (SCM) (SRX3000 series)
• Switch fabric board (SFB) (SRX3000 series)
• Backplane and System 1/0 card (SRX1400)
• Other components
• Power supplies
• Cooling system

SRX1400 and SRX3000 Series Modules Overview

The following types of modules are available for the SRX1400, SRX3400, and SRX3600 Services Gateways:
//0 cards (IOCs) are common form-factor module (CFM) cards that provide additional physical network
connections to the services gateway to supplement the Ethernet ports on the Switch Fabric Board (SFB). Their
primary function is to deliver data packets arriving on the physical ports to the Network Processing Card (NPC)
and to forward data packets out the physical ports after services processing.
Network processing l/0 cards (NP-IOCs) are IOCs that have their own network processing units (NPUs), so that
traffic traversing the IOC does not have to traverse the services gateway bus to a remote NPC. This feature
makes them well-suited to low-latency applications.
Services processing cards (SPCs) are CFM cards that provide the processing power to run integrated services
such as firewall, IPsec, and IDP. All traffic traversing the services gateway is passed to an SPC to have service
processing applied to it. Traffic is intelligently distributed by NPCs to SPCs for service processing, including
session setup based on policies, fast packet processing for packets that match a session, encryption and
decryption, and IKE negotiation.
Continued on the next page.

www.juniper.net SRX Hardware Troubleshooting • Appendix C-5

Advanced Junos Enterprise Routing Troubleshooting

SRX1400 and SRX3000 Series Hardware (contd.)

NPCs are CFM cards that receive inbound traffic from the IOCs and direct it to the appropriate SPC for
processing. Once services processing is complete, the NPC receives outbound traffic from the SPCs and directs
it back to the appropriate IOC. Additionally, the NPC buffers incoming traffic and queues outgoing traffic, and
also performs advanced traffic management, including denial of service (DoS)/distributed denial of service
(DDoS) protective measures. For example, it can drop traffic to or from a particular IP address, protecting from
ICMP, UDP, and TCP SYN flooding, and buffering bursty traffic to protect the SPC.
The Routing Engine is a PowerPC platform that runs the Junos operating system (Junos OS). Unlike other
modules, the Routing Engine is not in the CFM form factor, and so has an assigned slot within the chassis
(REO). Software processes that run on the Routing Engine maintain the routing tables, manage the routing
protocols used on the services gateway, control the services gateway interfaces, control some chassis
components, and provide the interface for system management and user access to the services gateway.
The SRX Clustering Module (SCM) is a card that you can install in the services gateway to enable the dual
control link feature for chassis cluster supported in Ju nos OS Release 10.2 and later. Unlike other modules, the
SCM is not in the CFM form factor, and so has an assigned slot within the chassis (RE1).
The Switch Fabric Board (SFB) is the data plane for the subsystems in the chassis for the SRX 3000 series. The
SFB performs the following functions: powers the services gateway on and off, controls clocking and
distribution, provides eight copper Gigabit Ethernet ports and four fiber Gigabit Ethernet ports, provides two
high availability (HA) Control ports, provides interconnections to all the IOCs within the chassis through
integrated switch fabrics, handles arbitration among the CFMs, handles switching among multiple SPCs if
present, provides service ports, system LEDs, and operational buttons on the front pane.
The backplane provides the following major functions on the SRX1400 Services gateway: data path for
transferring packets across the backplane between the 1/0 card (IOC) and Network and Services Processing
Card (NSPC) through the System 1/0 card (SYSIOC), power distribution to all of the device components and
signal path to the IOC, Network and Services Processing Card (NSPC), Routing Engine, SYSIOC, and other device
components for monitoring and control of the system.
System l/0 card (SYSIOC) provides fixed 1/0 ports for the base system and are an important element of the data
plane. In addition it performs the following functions: supports the Power button, provides 2 optional chassis
cluster control ports, provides management and console ports, system LEDs, and power buttons on the front
panel and provides data path connectivity between the NSPC and the IOC.
Power supplies
SRX1400 Services Gateway uses either one AC or one DC power supply unit. A second AC or DC power
supply can be used with its matching type of power supply to offer redundancy. The power supplies
connect to the backplane, which distributes 10V main power and 3.3V standby power to the services
gateway components. Each power supply is cooled by its own internal cooling system.
SRX3400 Services Gateway uses one or two power supplies, located at the rear of the chassis in slots
PEMO and PEM1. Each power supply provides power to all components in the services gateway. When
two power supplies are present, they share power almost equally within a fully populated system. The two
power supplies provide full power redundancy. If one power supply fails or is removed, the remaining
power supply redistributes the electrical load without interruption. The services gateway reassesses the
power required to support its configuration and issues errors if the available power is insufficient.
Continued on the next page.

Appendix C-6 • SRX Hardware Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

SRX1400 and SRX3000 Series Hardware (contd.)

SRX3600 Services Gateway can contain two to four power supplies, located at the rear of the chassis in
slots PEMO through PEM3. Each power supply provides power to all components in the services gateway.
When three or four power supplies are present, they share power almost equally within a fully populated
system. The three or four AC power supplies provide full power redundancy. If one power supply fails or is
removed, the remaining power supplies redistributes the electrical load without interruption. The services
gateway reassesses the power required to support its configuration and issues errors if the available
power is insufficient.
For the SRX3000 Series, two types of DC power supply are available. The standard DC power supply has
a maximum power output of 850W. The enhanced DC power supply has a maximum power output of
1200W, and has additional filters required to meet NEBS and ETSI requirements. The two types of DC
power supply are identical in all other respects.
Cooling system
SRX1400 Services Gateway fan tray contains two fans.
SRX3400 Services Gateway tray contains four fans and an air filter.
SRX3600 Services Gateway fan tray contains ten fans and an air filter.
The fans and air filter (SRX3000 series) are responsible to keep all services gateway components within the
acceptable temperature range. The fan tray is hot-insertable and hot-removable.

For further information about supported modules, consult hardware documentation for your specific SRX Series Services
Gateways.

www.juniper.net SRX Hardware Troubleshooting • Appendix C- 7

Advanced Junos Enterprise Routing Troubleshooting

SRXSOOO Series Services Gateway Hardware

• Card overview
• 1/0 cards (IOCs)
• Flex IOCs
•Services Processing Cards (SPCs)
• Switch Control Boards (SCBs)
• Routing Engine
• Major redundant components
•SCBs
• Power supplies
• Cooling system

Notwodc5,1'""Allri!#II$--, • /U��
;)("ii�I
-�rldwfi:leEducatlonSenrices
=
I wwwJunlpernet 18

SRX5000 Series Services Card Overview

The following types of cards are available for the SRX5600 and SRX5800 Services Gateways:
1/0 cards (IOCs) provide additional physical network connections to the services gateway. Their primary function
is to deliver data packets arriving on the physical ports to the Services Processing Cards (SPCs) and to forward
data packets out the physical ports after services processing.
Flex IOCs have two slots for port modules that add additional physical network connections to the services
gateway. Like IOCs, their primary function is to deliver data packets arriving on the physical ports to the SPCs
and to forward data packets out the physical ports after services processing.
Services Processing Cards (SPCs) provide the processing power to run integrated services such as firewall,
IPsec and IDP. All traffic traversing the services gateway is passed to an SPC to have services processing
applied to it.
Continued on the next page.

Appendix C-8 • SRX Hardware Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

SRX5000 Series Services Card Overview (contd.)

Switch Control Boards (SCBs) power on and power off IOCs and SPCs; control clocking and system resets. SCBs
also control booting, monitor, and system functions including fan speed, board power status, PDM status and
control, and the system front panel. In addition it provides interconnections to all the IOCs within the chassis
through the switch fabrics integrated into the SCB. Each SCB has a slot in the front panel for a Routing Engine.
Routing Engines fit into slots in SCBs and maintain the routing tables, manage the routing protocols used on the
device, control the device interfaces and some chassis components, and provide the interface for system
management and user access to the device.

SRX5000 Series Major Redundant Components

SCBs: The host subsystem consists of a Routing Engine installed in an SCB. The device must have one host
subsystem installed. You can install a second SCB for redundancy. If a second SCB is installed, the host
subsystem SCB functions as the master and the other functions as the backup. If the SCB of the host
subsystem fails, the other SCB takes over as the master.
Power supplies:
In the DC configuration, two power supplies are required to supply power to a fully configured services
gateway. One power supply supports approximately half of the components in the services gateway, and
the other power supply supports the remaining components. The addition of two power supplies provides
full power redundancy. If one or two power supplies fail, the remaining power supplies can provide full
power to the services gateway.
In the AC configuration a minimum of three power supplies are required to supply power to a fully
configured services gateway with the exception for SRX5600 high-line (220V) which requires only 2
power supplies. All AC power supplies share the load evenly. All fourth power supplies deployed in the
device provide full power redundancy. If one power supply fails in a redundant configuration, the
remaining power supplies provide full power.
Cooling system: The cooling system has redundant components, which are controlled by the host subsystem. If
one of the fans fails, the host subsystem increases the speed of the remaining fans to provide sufficient cooling
for the services gateway indefinitely.
For further information about supported modules consult hardware documentation for your specific SRX Services Gateways.

www.juniper.net SRX Hardware Troubleshooting • Appendix C-9

Advanced Junos Enterprise Routing Troubleshooting

Junos Chassis Management Architecture

• Junos Chassis
Management Architecture
Power control
• The chassisd process
12c bus
• Runs on the Routing Engine
• Detects insertion/removal
of hardware components
• Monitors environmental Fan
sensors
parameters
Board Board Board
• Controls fan speed µkernel µkernel µkernel

• It can also reset PEM

Board Board Board sensors
and power up or down Sensors Sensors Sensors
hardware components

Junos Chassis Management Architecture

Before entering into the details of the commands used to troubleshoot hardware issues, it is worth reviewing the Junos
hardware management architecture. From the software point of view, hardware is managed by the chassisd process,
running on the master Routing Engine. Its functionalities can be accessed through the CU and the process interfaces with
hardware sensors for board presence detection and environmental monitoring.
The Junos Chassis Management Architecture's responsibilities include, among others:
Detect insertion/removal of hardware components: This detection is typically done through a passive bus (i2c).
This allows it to read serial numbers and board type even if the component is offline.
Monitor each board's environmental parameters: This monitoring includes voltages and temperatures.
Control fan speeds: The chassisd process controls fan speed in case of excessive temperature.
Control power and reset signals for every component: The chassisd can reset and power down other
components; for example, when bringing a FPC offline from the CU.

Appendix C-10 • SRX Hardware Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Useful Commands
• Verifying the operational status and environmental
parameters
show chassis hardware
show chassis environment
show chassis specific-board
• The specific board changes with the platform
• Details are in the CU Reference Guide

Verify the Operational Status and Environmental Parameters

The following standard commands are used to troubleshoot hardware issues:
show chassis hardware
show chassis environment
show chassis specific-board, where the specific board changes with the platform. The Command Line
Interface Reference Guide provides sample platform-specific output. It is also possible to add the detail
modifier to get additional information-typically temperature, voltages, and resource utilization.

A few examples of the command outputs follow:

user@srx> show chassis hardware

Hardware inventory:
Item Version Part number Serial number Description
Chassis JN10B7005AGA SRX 5800
Midplane REV 03 710-013698 TR0779 SRX 5800 Backplane
FPM Board REV 03 710-014974 KC3406 Front Panel Display
PDM Rev 03 740-013110 QCS1122504F Power Distribution Module
PEM 1 Rev 03 740-013683 QCS1134703V DC Power Entry Module
PEM 2 Rev 03 740-013683 QCS1134 700E DC Power Entry Module
Continued on the next page.

www.juniper.net SRX Hardware Troubleshooting • Appendix C-11

Advanced Junos Enterprise Routing Troubleshooting

Verify the Operational Status and Environmental Parameters (contd.)

Routing Engine O REV 06 740-015113 1000696955 RE-S-1300
CB O REV 07 710-013385 JZ3257 SRX5k SCB
FPC 3 BB-P2-39 710-020305 JS4847 SRX5k SPC
CPU REV 06 710-013713 KC1180 DPC PMB
PIC 0 BUILTIN BUILTIN SPU Cp
PIC 1 BUILTIN BUILTIN SPU Flow
FPC 6 REV 03 750-020751 JT0109 SRX5k DPC 4x lOGE
CPU REV 06 710-013713 KC3543 DPC PMB
PIC 0 BUILTIN BUILTIN lx lOGE(LAN/WAN) RichQ
Xcvr 0 NON-JNPR A7COOSY XFP-lOG-SR
PIC 1 BUILTIN BUILTIN lx lOGE(LAN/WAN) RichQ
Xcvr 0 REV 01 740-011571 C728XJ01W XFP-lOG-SR
PIC 2 BUILTIN BUILTIN lx lOGE(LAN/WAN) RichQ
PIC 3 BUILTIN BUILTIN lx lOGE(LAN/WAN) RichQ
Fan Tray 0 REV 04 740-014971 TP1432 Fan Tray
Fan Tray 1 REV 04 740-014971 TP1829 Fan Tray

user@srx> show chassis fpc pie-status

nodeO:

Slot 0 Online FPC

PIC 0 Online 4x GE Base PIC
Slot 3 Online FPC
PIC 0 Online 4x FE
Slot 6 Online FPC
PIC 0 Online 8x GE uPIM
nodel:

Slot O Offline FPC

Slot 3 Offline FPC
Slot 6 Offline FPC

Appendix C-12 • SRX Hardware Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting Hardware Problems

• Hardware problems
• Environmentaljcooling issues
• Fan failures
• Temperature
• Power supply failures
• Hardware component is offline
• Board goes offline
• New board refuses come online
• Hardware online, but reports errors
• Routing engine running from secondary media

Troubleshooting Hardware Problems

Typical hardware issues can be divided among the following categories:
Environmentjcooling issues: This category includes temperature problems, fan failures or power supply
failures. All of these problems typically require on-site work or site inspections.
Hardware component is offline: The main method of troubleshooting these problems is looking at the chassisd
and messages logs. In case of an unresponsive or offline board, a good test is trying to restart it from the
command line while monitoring the chassisd logs. Often it is also needed to connect to the board through the
internal console connection to check why a board cannot boot; but that is typically only done with JTAC
assistance.
Hardware online, but reports errors: These problems are often the hardest to troubleshoot, and the
methodology to follow will depend on the specific component which failed.

www.juniper.net SRX Hardware Troubleshooting • Appendix C-13

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting Temperature Issues

• Temperature issues
• Fan failures
• Fan rotation speed is monitored by chassisd; a fan failure will
trigger an alarm - use show chassis alarms command
• The solution is a straight fan tray replacement - follow HW guide
• Check fan speed temperature thresholds using show
chassis temperature-thresholdscommand
• If fans are ok, but temperature is still high
• Check the airflow and that there is sufficient clearance space
around the intake and exhaust points
• Check and if needed clean or replace air filters
• Finally. if you get high temperatures in daytime. make sure the air
conditioning system is sufficient

Temperature Issues
A fan failure will be noticed by the chassisd process, which will trigger an alarm. Using the show chassis alarm
command will tell you which fan tray must be replaced. Pay special attention when pulling out fan trays; it is very easy to get
your fingers to touch the spinning fan blades. Follow the procedure and the precautions outlined in the hardware guide.

user@srx> show chassis alarms

1 alarms currently active
Alarm time Class Description
2010-11-11 20:27:38 UTC Major Side Fan Tray 7 Failure

Each platform has three fan speed temperature thresholds. The actual values change with every platform. If a fan fails, the
temperature thresholds lower to reflect the reduced cooling capability. A fan failure should be taken very seriously, especially
if the air conditioning at the device site is not optimal because the risk is a complete device shutdown.

user@srx> show chassis temperature-thresholds

Fan speed Yellow alarm Red alarm
(degrees C) (degrees C) (degrees C)
Item Normal High Normal Bad fan Normal Bad fan
Chassis default 48 54 65 55 75 75
Routing Engine 65 70 85 75 95 80

Continued on the next page.

Appendix C-14 • SRX Hardware Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Temperature Issues (contd.)

If the fans are operational, but the temperature is still high, perform the following actions:
Check the airflow: Make sure that there is sufficient clearance space around the intake and exhaust points; the
hardware guide provides the minimum clearance values.
Check and clean or replace the air filters: For environments not perfectly clean this should be done at least
once per year.
Make sure the air conditioning system is sufficient: Even if the cooling system works correctly a high room
temperature can easily push a device beyond the yellow threshold alarms.When external temperatures are
high, the consequence of an air conditioning failure can be serious.

Checking Environmental Values

You can check the temperature reported by every sensor in the router by using the command show chassis
environment. Temperature is available for polling using SNMP using the Juniper Enterprise MIB.For some specific
components (typically power supplies) you can also get additional information, like input voltages, by specifying the
component name.
The following output serves as an example:
user@router> show chassis environment pem
PEM O status:
State Online
Temperature 33 degrees c I 91 degrees F
DC Input: OK
Voltage(V) Current(A) Power(W) Load(%)
INPUT 0 54.625 9.812 535 22
INPUT 1 54.625 10.250 559 23
INPUT 2 55.125 0.125 6 0
INPUT 3 54.500 10.062 548 22
INPUT 4 54.750 9.375 513 21
INPUT 5 54.750 10.187 557 23
DC Output Voltage(V) Current(A) Power(W) Load(%)
FPC O 55.750 10.125 564 37
FPC 1 51.625 0.000 0 0
FPC 2 52.000 0.000 0 0
FPC 3 55.062 10.437 574 38
FPC 4 52.125 0.000 0 0
FPC 5 55.000 9.375 515 34
FPC 6 55.187 9.687 534 35
FPC 7 51.437 0.000 0 0
SCG/CB/SIB 55.375 15.750 872 35
FAN 54.562 14.750 804 42

www.juniper.net SRX Hardware Troubleshooting • Appendix C-15

Advanced Junos Enterprise Routing Troubleshooting

Troubleshooting Power Supplies

• Power supplies
• chassisd process monitors power supply output
• If the output voltage drops an alarm is triggered - use show
chassis alarms command and in addition a SNMP trap is
sent and a message is logged in both the messages and the
chassisd logs
• Check the power supply status and to confirm the problem-use
the show chassis environment command
• Consult the hardware troubleshooting guide

Power Supplies
If a drop in voltage is detected, the chassisd process will assert an alarm.
user@srx> show chassis alarms
1 alarms currently active
Alarm time Class Description
2007-01-10 15:47:18 UTC Major PEM 1 Input Failure
This alarm in turn will cause a SNMP trap to be sent to the network management stations. The failure is also logged to both
messages and chassisd files.
user@srx> show log messages I find failure
Jan 10 15:47:18 srx chassisd[l300]: CHASSISD_PEM_INPUT_BAD· status failure for power
supply 1 (status bits: Ox4e); check circuit breaker
Note that input failure means the power supply detects no input power. This message could mean a hardware failure,
but also a power circuit problem, or an open circuit breaker.
Continued on the next page.

Appendix C-16 • SRX Hardware Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Power Supplies (contd.)

If the output of show chassis environment command confirms the problem, site intervention will be needed. It is
worth while to save a copy of the show chassis hardware command output in case an RMA is needed.
user@srx> show chassis environment
Class Item Status Measurement
Temp PEM O OK 40 degrees C I 104 degrees F
PEM 1 Failed
PEM 2 Absent
PEM 3 Absent
Routing Engine 0 OK 39 degrees c I 102 degrees F
Routing Engine 1 OK 37 degrees c I 98 degrees F
CB 0 Intake OK 36 degrees c I 96 degrees F
CB 0 Exhaust A OK 34 degrees c I 93 degrees F
CB 0 Exhaust B OK 38 degrees c I 100 degrees F
CB 0 ACBC OK 37 degrees c I 98 degrees F
CB 0 SF A OK 49 degrees c I 120 degrees F
The hardware documentation provides very good step-by-step troubleshooting guide for each of the main device
components. We recommend the following steps for this case:
Check that the AC input switch( I ) or DC circuit breaker(-) is in the on position and is receiving power.
Verify that the source circuit breaker has the proper current rating. Each power supply must be connected to a
separate source circuit breaker.
Verify that the AC power cord or DC power cables from the power source to the device are not damaged.
Connect the power supply to a different power source with a new power cord or power cables.
If the power supply status LEDs indicate that the power supply is not operating normally, the power supply is the
source of the problem. Replace the power supply with a spare.

www.juniper.net SRX Hardware Troubleshooting • Appendix C-17

Advanced Junos Enterprise Routing Troubleshooting

Agenda: SRX Hardware Troubleshooting

• General Chassis Components
""?Redundancy
• Hardware Case Study

Redundancy
The slide highlights the topic we discuss next.

Appendix C-18 • SRX Hardware Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Hardware Redundancy
• Most platforms include some form of hardware
redundancy
• Routing Engines
• GRES or NSR
• Control Boards
• Often paired with Routing Engines
• Fabric redundancy
• Power supplies
• Cooling subsystem

Hardware Redundancy
Most platforms include some form of hardware redundancy:
Routing Engines: In Graceful Routing Engine Switchover configuration, only one Routing Engine is running
routing protocol and managing the device. A keepalive mechanism ensures that in the case of failure the
backup Routing Engine will assume mastership. The protocols will go down, but impact to traffic will be limited
or none. In non-stop-routing configuration, both Routing Engines are active at the same time acting as one. The
state is replicated between them, so that in case of a failure all routing protocols will stay up. This is a very
complex feature, and is not supported for all protocols and all hardware configurations yet. Refer to the
technical documentation to understand if its benefits outweigh any potential tradeoff.
Control board: On many platforms, Control Board redundancy is tied to Routing Engine redundancy. It is also
worth noting that on some platforms (most notably several of the MX Series routers) the Control Board also
provide fabric-in other words, a redundant CB also provides redundant fabric.
Continued on the next page.

www.juniper.net SRX Hardware Troubleshooting • Appendix C-19

Advanced Junos Enterprise Routing Troubleshooting

Hardware Redundancy (contd.)

Fabric redundancy: Some platforms, such as T Series routers, can install a spare fabric board (SIB) that will
become active in a failure of any other fabric board. From a troubleshooting point of view, a fabric failure can
cause a reduction of the router throughput. It is also worth mentioning that troubleshooting fabric issues can
sometimes be difficult, but step-by-step guides are available in the Juniper Networks Knowledge Base.
Power supplies and cooling subsystems: Lastly, most platforms can install redundant power supplies and can
keep on operating even if one of the other fails. Similarly, most platforms come by default with redundant
cooling-a fan failure might put more load on the remaining fans, but will not cause the router to overheat.

Appendix C-20 • SRX Hardware Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

SRXSOOO Series Chassis Cluster (1 of 2)

• Replace Routing Engine, SCB, or both on high-end
series chassis cluster
1. On SRX5000 Series: Before powering down the node.
deactivate the fab interfaces in the configuration (This can
be done on either node):
• user@srx# deactivate interfaces fabO
• user@srx# deactivate interfaces fabl
user@srx# commit
Failure to do this will result in some chassis cluster challenges later.
2. Replace the Routing Engine or SCB.
3. Power on the device.

Replace Routing Engine, SCB, or Both on High End Series Chassis Cluster: Part 1
Parts listed below have the chassis cluster-id stored on non-volatile memory (Flash). Replacing them on high end chassis
cluster requires a specific procedure to avoid service impact due to chassis cluster issue. KB19909 contains more details
about the Location of Chassis Cluster ID in SRX High End Series.
SRX5800 and SRX5600: Switch Control Board (SCB) in SCB slot O
SRX3600 and SRX3400:Routing Engine (RE)
SRX1400: Routing Engine (RE)
On High end SRX devices, RMA node replacement requires specific procedure too. The KB21134 describes the procedure in
detail.

www.juniper.net SRX Hardware Troubleshooting • Appendix C-21

Advanced Junos Enterprise Routing Troubleshooting

SRXSOOO Series Chassis Cluster (2 of 2)

• Replace Routing Engine, SCB, or both on high-end

series chassis cluster
4. Enter the cluster ID information using the following
operational mode command:
set chassis cluster cluster-id X node Y reboot
5. The device reboots with the cluster configuration and joins
the cluster.
6. On SRX5000 series once the node is back in the cluster.
activate the fab interfaces:
• user@srx# activate interfaces fabO
user@srx# activate interfaces fabl
user@srx# commit

Replace Routing Engine, SCB, or Both on High End Series Chassis Cluster: Part 2
The slide describes the remainder of the procedure.

Appendix C-22 • SRX Hardware Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Agenda: SRX Hardware Troubleshooting

• General Chassis Components
• Redundancy
�Hardware Case Study

Hardware Case Study

The slide highlights the topic we discuss next.

www.juniper.net SRX Hardware Troubleshooting • Appendix C-23

Advanced Junos Enterprise Routing Troubleshooting

Case Study: Network "Slow-Down" (:I. of 3)

• Data center problem

• Customer reported "network slow-down" problem
• Initial investigation was done on the SRX 5600 device:
• An alarm on the system was raised: 2012-01-20 12: 53: 09
EST Minor Check CB O Fabric Chip 1

DATA CENTER

------..
( Internet)
_..,.
L

Case Study: Data Center Network "Slow Down· Problem-Part 1

The customer reported a problem with their SRX 5600 device deployed at their data center resulting in a network slow down.
They performed initial investigation and saw an alarm "2012-01-20 12:53:09 EST Minor Check CB O Fabric Chip 1" had
been raised on the system.

Appendix C-24 • SRX Hardware Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Case Study: Network "Slow-Down" (2 of 3)

• Data center problem

• Message files contained following entries:
fpcl ICHIP(O)_REG_ERR:Non first cell drops in ichip fi rord: 43
fpcl ichip_f_check_dest_errors: Fabric request time out for plane 2 dest 1 pfe O
fpcl ichip_f_check_dest_errors: Fabric request time out for plane 2 dest 1 pfe O
fpcO ICHIP(l) REG ERR:Non first cell drops in ichip fi rord: 84
alarmd[ll73): Alarm set: CB color =YELLOW, class=CHASSIS, reason=Check CB O Fabric
Chip 1
craftd[ll74): Minor alarm set, Check CB O Fabric Chip 1
fpcl CMXDPC: CRC link error detected for FPC: 1 PFE: O fabric plane 2

• The operational mode command show chassis fabric

fpcs revealed a link error on the FPC1

Case Study: Data Center Network "Slow Down" Problem-Part 2

The messages file did contain the messages shown on the slide multiple times and the operational mode command
revealed a "link error" on the FPC1.
user@srx> show chassis fabric fpcs I no-more
Fabric management FPC state:
FPC 0
PFE #0
Plane 0: Plane enabled
Plane 1: Plane enabled
Plane 2: Plane enabled
Plane 3: Plane enabled
Plane 4: Unused
Plane 5: Unused
Plane 6: Unused
Plane 7: Unused
PFE #1
Plane 0: Plane enabled
Plane 1: Plane enabled
Plane 2: Plane enabled
Plane 3: Plane enabled
Plane 4: Unused
Continued on the next page.

www.juniper.net SRX Hardware Troubleshooting • Appendix C-25

Advanced Junos Enterprise Routing Troubleshooting

Case Study: Data Center Networks "Slow Down" Problem-Part 2 (contd.)

Plane 4: Unused
Plane 5: Unused
Plane 6: Unused
Plane 7: Unused
FPC 1
PFE #0
Plane 0: Plane enabled
Plane 1: Plane enabled
Plane 2: Link error
Plane 3: Plane enabled
Plane 4: Unused
Plane 5: Unused
Plane 6: Unused
Plane 7: Unused
PFE #1
Plane 0: Plane enabled
Plane 1: Plane enabled
Plane 2: Plane enabled
Plane 3: Plane enabled
Plane 4: Unused
Plane 5: Unused
Plane 6: Unused
Plane 7: Unused
PFE #2
Plane 0: Plane enabled
Plane 1: Plane enabled
Plane 2: Plane enabled
Plane 3: Plane enabled
Plane 4: Unused
Plane 5: Unused
Plane 6: Unused
Plane 7: Unused
PFE #3
Plane 0: Plane enabled
Plane 1: Plane enabled
Plane 2: Plane enabled
Plane 3: Plane enabled
Plane 4: Unused
Plane 5: Unused
Plane 6: Unused
Plane 7: Unused
FPC 2
PFE #0
Plane 0: Plane enabled
Plane 1: Plane enabled
Plane 2: Plane enabled
Plane 3: Plane enabled
Plane 4: Unused
Plane 5: Unused
Plane 6: Unused
Plane 7: Unused
PFE #1
Plane 0: Plane enabled
Plane 1: Plane enabled
Plane 2: Plane enabled
Plane 3: Plane enabled
Plane 4: Unused
Plane 5: Unused
Plane 6: Unused
Plane 7: Unused

Appendix C-26 • SRX Hardware Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Case Study: Network "Slow-Down" (3 of 3)

• Data center problem

• The SRX Series device was rebooted
• Problem disappeared but after some time reoccurred
• JTAC suggested following actions for the affected FPC1 to be
executed separately and monitored to check if they resolved
the issue checked
1. Offline and on line the FPC1 via the CLI using the command:
• request chassis fpc slot number offline
• request chassis fpc slot number online
2. Physically offline. remove. and reseat the FPC in the chassis. by
using the chassis FPC offline button. pull the FPC out. reseat it in
the slot. and then use the online button on the chassis.
3. If both previous actions fail RMA for the FPC is needed

Case Study: Data Center Network "Slow Down" Problem-Part 3

The customer rebooted the device which seemed to have solved the problem. But the issue reappeared after some time with
the same symptoms and the same messages. The JTAC suggested multiple actions. Each of the actions should be done only
for the affected FPC1 and executed separately with monitoring the result for some time to determine whether the issue has
been resolved.
Actions one and two had the same effect as the device reboot, the problem was resolved but only for short time. The final
action-RMA-did solve the problem.

www.juniper.net SRX Hardware Troubleshooting • Appendix C-27

Advanced Junos Enterprise Routing Troubleshooting

Summary
• In this content, we:
• Listed the general chassis components
• Identified different methods for troubleshooting major
chassis components
• Troubleshot redundant Routing Engine and Control Board
communication

We Discussed:
A list the general chassis components.
Identifying different methods for troubleshooting major chassis components. and
Troubleshooting redundant Routing Engine and Control Board (CB) communication.

Appendix C-28 • SRX Hardware Troubleshooting www.juniper.net

 Advanced Junos Enterprise Routing Troubleshooting

Review Questions

1. What are the main hardware components of a

Juniper device?
2. What is the Junos process responsible for managing
and monitoring hardware?
3. Which information resources are available to you
when troubleshooting hardware issues?

Review Questions
1.

2.

3.

4.

www.juniper.net SRX Hardware Troubleshooting • Appendix C-29

Advanced Junos Enterprise Routing Troubleshooting
Answers to Review Questions
I.
The host subsystem (Routing Engine and Control Boards), the PFF: boards, the midplane, the power supplies and the cooling
subsystem (fans and air filters) arc the main hardware components of a Juniper router.

2.
The chassisd is responsible for managing and monitoring hardware.

3.
The hardware guide and the Juniper Networks Knowledge Base arc available to you when troubleshooting hardware issues.

4.
PPP can detect an address mismatch on a point-to-point link.

Appendix C-30 • SRX Hardware Troubleshooting www.juniper.net

 Acronym List

3GPP ................................................................ Third-Generation Partnership Project

ADM .................••.......................................................... add/drop multiplexers
API ...............................•.........•..........................application programming interface
ARP...............................•......................................... Address Resolution Protocol
AS..........•..........•..........•..........•.....................................autonomous system
ASBR .............................•.....................•........... Autonomous System Boundary Router
ASIC .................................................................application-specific integrated circuit
ATM..........................................•............................. Asynchronous Transfer Mode
CB...................................................................................... Control Board
CFM ........••..........•..........•........................................ common form-factor module
CLEI ................................•....................••....... Common Language Equipment Identifier
CLI .......•....................................•................................command-line interface
CLNP........••...........•........................................... Connectionless Networking Protocol
Cos ......................•.........••.........••.........••............................ class of service
CSNP .................................................................. Complete Sequence Number PDU
DDoS ....................................................................... distributed denial of service
DoS............•..........•...........•............................................... denial of service
DPC............................................................................ Dense Port Concentrator
FPC...................................•....................................... Flexible PIC Concentrator
GPIM...........•..........•...........•..........•............ Gigabit-Backplane Physical Interface Module
GUI ............................................................................. graphical line interface
HA..................................................................................... high availability
1/0 card .........•...........•........................................................ input/output card
ICMP.......................•......................•.................... Internet Control Message Protocol
IGP ............................................................................ interior gateway protocol
1Pv4 ............•..........•................................................. Internet Protocol version 4
ITU -T..........••..........••........ International Telecommunication Union Telecommunication Standardization
JNCP...............................................................Juniper Networks Certification Program
KB................................................................................... Knowledge Base
MIC............................................................................. Modular Interface Card
LSA............•...........•.....................•...........•................ Link State Advertisement
LSDB .............................................................................. link-state database
Mini-PIM.........••..........•..........•...........•..................... Mini-Physical Interface Modules
MPC ............•......................•..........•...........•.............. Modular Port Concentrator
MTU ........................................................................ maximum transmission unit
NET................................................................................ Network Entity Title
NIC .............•...........•..........•..........••...........•................. network interface card
NLRI................................................................ network layer reachability information
NOC ..........•.............•................................................ network operations center
NPC.............••.........••..........•..........•...........••............... network processing card
NP-IOC ...................................................................... network processing 1/0 card
NPU ...............................................•........................... network processing unit
NSPC .............................................................. Network and Services Processing Card
NTP....................................•..........•..............................Network Time Protocol
PFE........................................................................... Packet Forwarding Engine
PR...............•...........•..........•..........•...........•....................... problem report
PSNP .........................................................•........... Partial Sequence Number PDU
RE..................................................................................... Routing Engine
RFC....................................•..........•...........•................... request for comment
RPM ................................................................... real-time performance monitoring
SCB................................................................................ switch control board
SCM ............................................................................ SRX Clustering Module
SFB.......................••..........•......................•..................... Switch Fabric Board
SFP...........•.......................................................•...... small form-factor pluggable
SIB .................................•......................•................switch interface board spare

www.juniper.net Acronym List • ACR-1

 SPC .....................................••.............•..................... services processing cards
SYSIOC .................•..............................................................system 1/0 card
TFEB ................•••................................................T Series Forwarding Engine Board
ToS ..................................•.................................................type of service
VPN ..............•••............................................................ virtual private network

ACR-2 • Acronym List www.juniper.net