AJER 11.a LGD

Advanced Junos Enterprise
Routing
11.a
Detailed Lab Guide
Worldwide Education Services
1194 North Mathilda Avenue

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

This document is produced by Juniper Networks, Inc.
This document or any part thereof may not be reproduced or transmitted in any form under penalty of law, without the prior written permission of Juniper Networks
Education Services.
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other
countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered
trademarks, or registered service marks are the property of their respective owners.
Advanced Junos Enterprise Routing Detailed Lab Guide, Revision 11.a
Copyright © 2012 Juniper Networks, Inc. All rights reserved.
Printed in USA.
Revision History:
Revision 10.a—March 2011.
Revision 11.a—April 2012.
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 11.4R1.6. Juniper Networks assumes no
responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary,
incidental, or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.
Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has
no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an
agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and
agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper
Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should
consult the software license for further details.
Contents
Lab 1: Configuring and Monitoring OSPF (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Part 1: Configuring and Monitoring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Part 2: Configuring OSPF Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Part 3: Configuring OSPF Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization

(Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Part 1: Configuring a Stub Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Part 2: Configuring an NSSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Lab 3: Configuring and Monitoring Routing Policy and Advanced OSPF Options
(Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Part 1: Establishing the OSPF Adjacencies and Creating a Virtual Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Part 2: Configuring OSPF Multiarea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Part 3: Configuring External Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
Lab 4: Implementing BGP (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Part 1: Loading the Baseline Interface and OSPF Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Part 2: Configuring IBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
Part 3: Configuring and Monitoring EBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Part 4: Configuring BGP Multipath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21
Part 5: Configuring BGP Multihop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27
Lab 5: BGP Attributes (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Part 1: Loading the Initial Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Part 2: Configuring BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Part 3: Configuring Next-Hop Self Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
Part 4: Using Policy to Avoid Becoming a Transit AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Part 5: Manipulating Attributes with Policy to Influence Inbound Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
Part 6: Manipulating Local Preference with an Import Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15
Part 7: Aggregating Routes and Using Well-Known Communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17
Lab 6: Implementing Enterprise Routing Policies (Detailed) . . . . . . . . . . . . . . . . . . 6-1

Part 1: Loading the Initial Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Part 2: Configuring BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Part 3: Implementing a Strict Primary/Secondary Routing Policy for Outbound Traffic . . . . . . . . . . . . . . . . . 6-5
Part 4: Implementing a Primary/Secondary Routing Policy for Inbound Traffic . . . . . . . . . . . . . . . . . . . . . . . 6-9
Part 5: Implementing a Loose Primary/Secondary Routing Policy for Outbound Traffic . . . . . . . . . . . . . . . 6-13
Part 6: Implementing Per-Prefix Load Sharing Outbound Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15
Part 7: Implementing Per-Prefix Load Sharing for Inbound Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19
Lab 7: Implementing PIM-SM (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Part 1: Loading the Baseline Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Part 2: Configuring IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
Part 3: Configuring PIM-SM with Static RP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
Part 4: Configuring PIM-SM with the BSR mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16
www.juniper.net Contents • iii

Lab 8: Implementing SSM (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
Part 1: Disabling the Use of RPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Part 2: Configuring IGMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4
Part 3: Viewing PIM-SM SSM Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8
Part 4: Configuring an ssm-map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9
Lab 9: Implementing CoS Features in the Enterprise (Detailed) . . . . . . . . . . . . . . . 9-1

Part 1: Loading the Initial Configuration and Accessing the CoS Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Part 2: Configuring Traffic Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
Part 3: Configuring Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8
Part 4: Configuring and Testing Schedulers and Drop Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-11
Part 5: Configuring and Testing a Rewrite Marker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-17
Lab 10: BGP Route Reflection (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Part 1: Loading the Initial Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2
Part 2: Verifying Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3
Part 3: Converting to Route Reflectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6
Part 4: Adding a New Router to the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-14
Appendix A: Lab Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
iv • Contents www.juniper.net
Course Overview
This three-day course is designed to provide students with the tools required for implementing,
monitoring, and troubleshooting Layer 3 components in an enterprise network. Detailed coverage
of OSPF, BGP, class of service (CoS), and multicast is strongly emphasized.
Through demonstrations and hands-on labs, students will gain experience in configuring and
monitoring the Junos operating system and in monitoring device and protocol operations.
Objectives
After successfully completing this course, you should be able to:
• Describe the various OSPF link-state advertisement (LSA) types.
• Explain the flooding of LSAs in an OSPF network.
• Describe the shortest-path-first (SPF) algorithm.
• Describe OSPF area types and operations.
• Configure various OSPF area types.
• Summarize and restrict routes.
• Identify scenarios that require routing policy or specific configuration options.
• Use routing policy and specific configuration options to implement solutions for
various scenarios.
• Describe basic BGP operation and common BGP attributes.
• Explain the route selection process for BGP.
• Describe how to alter the route selection process.
• Configure some advanced options for BGP peers.
• Describe various BGP attributes in detail and explain the operation of those attributes.
• Manipulate BGP attributes using routing policy.
• Describe common routing policies used in the enterprise environment.
• Explain how attribute modifications affect routing decisions.
• Implement a routing policy for inbound and outbound traffic using BGP.
• Identify environments that may require a modified CoS implementation.
• Describe the various CoS components and their respective functions.
• Explain the CoS processing along with CoS defaults on SRX Series Services Gateways.
• Describe situations when some CoS features are used in the enterprise.
• Implement some CoS features in an enterprise environment.
• Describe IP multicast traffic flow.
• Identify the components of IP multicast.
• Explain how IP multicast addressing works.
• Describe the need for reverse path forwarding (RPF) in multicast.
• Explain the role of Internet Group Management Protocol (IGMP) and describe the
available IGMP versions.
• Configure and monitor IGMP.
• Identify common multicast routing protocols.
• Describe rendezvous point (RP) discovery options.
• Configure and monitor Physical Interface Module (PIM) sparse modes.
www.juniper.net Course Overview • v

• Configure and monitor RP discovery mechanisms.
• Describe the basic requirements, benefits, and caveats of source-specific multicast
(SSM).
• List the address ranges used for SSM.
• Illustrate the role of Internet Group Management Protocol version 3 (IGMPv3) and PIM
sparse mode (PIM-SM) in an SSM implementation.
• Configure and monitor SSM.
Intended Audience
This course benefits individuals responsible for configuring and monitoring devices running the
Junos OS.
Course Level
Advanced Junos Enterprise Routing is an advanced-level course.
Prerequisites
Students should have basic networking knowledge and an understanding of the Open Systems
Interconnection (OSI) model and the TCP/IP protocol suite. Students should also have working
experience with basic routing principles.
Students should also attend the Introduction to the Junos Operating System (IJOS), Junos Routing
Essentials (JRE), and Junos Intermediate Routing (JIR) courses prior to attending this class.
vi • Course Overview www.juniper.net

Course Agenda
Day 1
Chapter 1: Course Introduction
Chapter 2: OSPF
Lab 1: Configuring and Monitoring OSPF
Chapter 3: OSPF Areas
Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization
Chapter 4: OSPF Case Studies and Solutions
Lab 3: Configuring and Monitoring Routing Policy and Advanced OSPF Options
Day 2
Chapter 5: BGP
Lab 4: Implementing BGP
Chapter 6: BGP Attributes and Policy
Lab 5: BGP Attributes
Chapter 7: Enterprise Routing Policies
Lab 6: Implementing Enterprise Routing Policies
Day 3
Chapter 8: Introduction to Multicast
Chapter 9: Multicast Routing Protocols and SSM
Lab 7: Implementing PIM-SM
Lab 8: Implementing SSM
Chapter 10: Class of Service
Lab 9: Implementing CoS Features in the Enterprise
Appendix A: BGP Route Reflection
Lab 10: BGP Route Reflection (Optional)
www.juniper.net Course Agenda • vii

Document Conventions
CLI and GUI Text

Frequently throughout this course, we refer to text that appears in a command-line interface (CLI)
or a graphical user interface (GUI). To make the language of these documents easier to read, we
distinguish GUI and CLI text from chapter text according to the following table.
Style Description Usage Example
Franklin Gothic Normal text. Most of what you read in the Lab Guide
and Student Guide.
Courier New Console text:

commit complete
• Screen captures
• Noncommand-related Exiting configuration mode
syntax
GUI text elements:
Select File > Open, and then click
• Menu names Configuration.conf in the
Filename text box.
• Text field entry
Input Text Versus Output Text

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

Enabled
Normal GUI
View configuration history by clicking
Configuration > History.
CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File > Save, and type
config.ini in the Filename field.
Defined and Undefined Syntax Variables

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

assigned.
GUI Variable Click my-peers in the dialog.
CLI Undefined Text where the variable’s value is Type set policy policy-name.
the user’s discretion or text where
ping 10.0.x.y
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.
viii • Document Conventions www.juniper.net

Additional Information
Education Services Offerings

You can obtain information on the latest Education Services offerings, course dates, and class
locations from the World Wide Web by pointing your Web browser to:
http://www.juniper.net/training/education/.
About This Publication
The Advanced Junos Enterprise Routing Detailed Lab Guide was developed and tested using
software Release 11.4R1.6. Previous and later versions of software might behave differently so
you should always consult the documentation and release notes for the version of code you are
running before reporting errors.
This document is written and maintained by the Juniper Networks Education Services development
team. Please send questions and suggestions for improvement to training@juniper.net.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats:
• Go to http://www.juniper.net/techpubs/.
• Locate the specific software or hardware release and title you need, and choose the
format in which you want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or
account representative.
Juniper Networks Support
For technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or
at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the United States).
www.juniper.net Additional Information • ix

x • Additional Information www.juniper.net
Lab 1
Configuring and Monitoring OSPF (Detailed)
Overview
This lab demonstrates configuration and monitoring of the OSPF protocol. In this lab, you
use the command-line interface (CLI) to configure, monitor, and troubleshoot OSPF.
The lab is available in two formats: a high-level format designed to make you think through
each step and a detailed format that offers step-by-step instructions complete with
sample output from most commands.
By completing this lab, you will perform the following tasks:
• Configure a multiarea OSPF network.
• Configure link costs and reference-bandwidth.
• Overload a router.
• Configure and troubleshoot OSPF authentication.
www.juniper.net Configuring and Monitoring OSPF (Detailed) • Lab 1–1

11.a.11.4R1.6
Advanced Junos Enterprise Routing
Part 1: Configuring and Monitoring OSPF
In this lab part, you configure and monitor a multiarea OSPF network. You will first
prepare your device by loading a reset config located on your device. Next, you
define a router ID for your assigned device. You then configure your device to
participate in a multiarea OSPF network and verify operations using CLI operational
mode commands.
Note
The instructor will tell you the nature of your
access and will provide you with the
necessary details to access your assigned
device.
Step 1.1
Ensure that you know to which student device you have been assigned. Check with
your instructor if you are not certain. Consult the management network diagram to
determine the management address of your student device.
Question: What is the management address

assigned to your station?
Answer: The answer varies. The sample hostname

and IP address used in the output examples in this
lab are for srxA-1, which uses 10.210.14.131 as its
management IP address. The actual management
subnet varies between delivery environments.
Step 1.2
Access the CLI on your student device using either the console, Telnet, or SSH as
directed by your instructor. Refer to the management network diagram for the IP
address associated with your student device. The following example uses a simple
Telnet access to srxA-1 with the Secure CRT program as a basis:
Lab 1–2 • Configuring and Monitoring OSPF (Detailed) www.juniper.net

Step 1.3
Log in to the student device with the username lab using a password of lab123.
Note that both the name and password are case-sensitive. Enter configuration mode
and load the reset configuration file using the
load override /var/home/lab/ajer/reset.config command. After
the configuration has been loaded, commit the changes before proceeding.
srxA-1 (ttyu0)
login: lab
Password:
--- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC

lab@srxA-1> configure
Entering configuration mode
[edit]
lab@srxA-1# load override ajer/reset.config
load complete
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
Step 1.4
Navigate to the [edit routing-options] hierarchy and configure the router ID
on your router using the IP address assigned to the lo0 interface as the input value.
[edit]
lab@srxA-1# edit routing-options
[edit routing-options]
lab@srxA-1# set router-id address
lab@srxA-1#
Step 1.5
Navigate to the [edit protocols ospf] hierarchy and configure the interfaces
necessary for OSPF Area 0. Refer to the network diagram as needed and remember
to include the loopback interface, lo0.0. On the ge-0/0/1 interface, use the
interface-type p2p option to speed up its adjacency time.
lab@srxA-1# top edit protocols ospf
[edit protocols ospf]

lab@srxA-1# set area 0 interface lo0.0

lab@srxA-1# set area 0 interface ge-0/0/1.0 interface-type p2p

lab@srxA-1# set area 0 interface ge-0/0/2.0

lab@srxA-1#
Note
Before proceeding, ensure that the remote
student team in your pod finishes the
previous step.
Step 1.6
Activate the configuration and quickly issue the run show ospf neighbor
command.
lab@srxA-1# commit
commit complete

lab@srxA-1# run show ospf neighbor
Address Interface State ID Pri Dead
172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 38
172.20.66.2 ge-0/0/2.0 2Way 192.168.2.1 128 39
Question: Which neighbor states are shown for the

listed interfaces and why?
Answer: The neighbor state for the ge-0/0/1.0

should immediately show Full and the ge-0/0/2.0
interface should be in 2Way or ExStart as shown
in the previous sample output.
Question: Why did the ge-0/0/1.0 interface form its

adjacency more quickly than the ge-0/0/2.0
interface?
Answer: Adding the interface-type p2p

option to a link tells OSPF not to perform a DR/BDR
election on that link. This can save up to 40
seconds of wait time for the adjacency to form.
Another benefit of the interface-type p2p
option is that no Type 3 LSA is generated describing
the multiaccess segment. This can help to reduce
the size of the OSPF link-state database (LSDB).

Step 1.7
Issue the run show ospf interface command to view the interface states.
lab@srxA-1# run show ospf interface
Interface State Area DR ID BDR ID Nbrs
ge-0/0/1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/2.0 BDR 0.0.0.0 192.168.2.1 192.168.1.1 1
lo0.0 DR 0.0.0.0 192.168.1.1 0.0.0.0 0
Question: What are the states of the two ethernet

interfaces and what do they mean?
Answer: The ge-0/0/1.0 interface has a state of

PtToPt because we configured it using the
interface-type p2p option. No OSPF election
occurred on this link, as shown by the 0.0.0.0
values in the DR ID and BDR ID fields. The output
for the ge-0/0/2.0 interface might vary. The
example output shows a state of BDR indicating this
router was elected as the backup designated router
for this segment.
Step 1.8
Issue the run show ospf neighbor command again to verify the current OSPF
adjacency details.
172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 37
172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 37
Question: How many OSPF neighbors exist and what

are the states of those adjacencies?
Answer: You should eventually see two OSPF

neighbors in the Full adjacency state. If you do
not see two OSPF neighbors in the Full adjacency
state, check your configuration and, if necessary,
work with the instructor.

STOP Do not proceed until the remote team finishes Part 1.
Part 2: Configuring OSPF Cost
In this lab part, you configure OSPF link costs, or metrics, on the student devices
and check your changes using CLI operational mode commands. In subsequent
steps, the words cost and metric are used interchangeably.
Step 2.1
Display routes advertised to and received from OSPF using the run show ospf
route command.
lab@srxA-1# run show ospf route
Topology default Route Table:
Prefix Path Route NH Metric NextHop Nexthop

Type Type Type Interface Address/LSP
192.168.2.1 Intra Router IP 1 ge-0/0/1.0 172.20.77.2
ge-0/0/2.0 172.20.66.2
172.20.66.0/30 Intra Network IP 1 ge-0/0/2.0
192.168.1.1/32 Intra Network IP 0 lo0.0
192.168.2.1/32 Intra Network IP 1 ge-0/0/1.0 172.20.77.2
ge-0/0/2.0 172.20.66.2
Question: What is the current metric associated

with the displayed OSPF routes?
Answer: With the exception of the OSPF route for

the local device’s loopback address, all OSPF routes
should show a metric of one (1). The metric for the
locally defined loopback address should be zero (0).

Question: Why does the output show two entries
with the same prefix?
Answer: The two entries with the same prefix

information represent the router ID and IP address
assigned to the remote team device. In the example
shown in the previous output, the 192.168.2.1
Router entry is associated with the router ID,
whereas the 192.168.2.1/32 Network entry is the
IP address assigned to the lo0.0 interface of the
remote team device.
Step 2.2
Associate a metric of 100 with the ge-0/0/2.0 interface. Activate the change and
reissue the run show ospf route command.
lab@srxA-1# set area 0 interface ge-0/0/2.0 metric 100

lab@srxA-1# commit
commit complete


Question: What is the current metric associated

with the 172.20.66.0/30 OSPF route?
Answer: The metric for the referenced prefix should

now show 100; previously, it was 1.

Question: What was the effect of the increased
metric on the route associated with the remote
student device’s loopback address?
Answer: Because the ge-0/0/2.0 interface now has

a higher metric or cost, the route associated with
the remote student device’s loopback lists only the
ge-0/0/1.0 interface as the next-hop interface;
previously, both ge-0/0/1.0 and ge-0/0/2.0 were
next-hops because they had the same metric.
Step 2.3
Another method to view the metric of an interface is the show ospf interface
detail command. Issue a run show ospf interface ge-0/0/2.0
detail command to view its output.
lab@srxA-1# run show ospf interface ge-0/0/2.0 detail
ge-0/0/2.0 BDR 0.0.0.0 192.168.2.1 192.168.1.1 1
Type: LAN, Address: 172.20.66.1, Mask: 255.255.255.252, MTU: 1500, Cost: 100
DR addr: 172.20.66.2, BDR addr: 172.20.66.1, Priority: 128
Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: None
Protection type: None
Topology default (ID 0) -> Cost: 100
Step 2.4
Because we are using Gigabit Ethernet interfaces in the network, change the
reference-bandwidth to 10g. Activate the change and issue the run show
ospf route command to view the changes.
lab@srxA-1# set reference-bandwidth 10g

lab@srxA-1# commit
commit complete



Question: What was the effect of setting the
reference-bandwidth to 10g?
Answer: The ge-0/0/1.0 interface’s metric

increased to 10 (from 1) because of the changes
made to the reference-bandwidth setting.
Question: Why did the metric associated with

ge-0/0/2.0 remain unchanged?
Answer: Recall that we manually set the metric for

the ge-0/0/2.0 interface. Interfaces that have their
metric manually configured are unaffected by
changes made by the reference-bandwidth
setting.
Step 2.5
Configure your assigned device to function as an area border router (ABR), joining
Area 0 with a second area. Refer to the network diagram for the area and interface
details. When complete, activate the configuration changes using the commit
command.
lab@srxA-1# set area area interface ge-0/0/4.unit

lab@srxA-1# commit
commit complete
Step 2.6
Issue the run show ospf neighbor command to verify the current OSPF
adjacency details.
172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 37
172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 37
172.20.111.10 ge-0/0/4.111 Full 192.168.1.2 128 31

Question: How many OSPF neighbors exist and what
are the states of those adjacencies?
Answer: You should now see three OSPF neighbors

and they should each be in the Full adjacency
state. If you do not see three OSPF neighbors in the
Full adjacency state, check your configuration
and, if necessary, work with the instructor.
Step 2.7
Verify reachability to the virtual router attached to your assigned device by pinging
its loopback address. Refer to your network diagram as necessary.
lab@srxA-1# run ping local-vr-loopback rapid
PING 192.168.1.2 (192.168.1.2): 56 data bytes
!!!!!
--- 192.168.1.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.437/4.057/8.057/3.122 ms
Question: Was the ping to your attached virtual

router successful?
Answer: Yes, the ping should be successful. If the

ping is not successful, double-check your
configuration and notify your instructor.
Note

team in your pod finishes the previous step.
Note
The next two lab steps require you to log in

to the virtual router attached to your team’s
device. The virtual routers are logical
devices created on a J Series Services
Router.

Step 2.8
Open a second CLI session to your student device. Log in to this second session to
the student device with the username lab using a password of lab123. Note that
both the name and password are case-sensitive.
srxA-1 (ttyu0)
login: lab
Password:
--- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC

lab@srxA-1>
Step 2.9
From the second CLI session to your student device, telnet to your virtual router’s
loopback address. Log in to the virtual router using the login information shown in
the following table:
Virtual Router Login Details
Student Device Username Password

srxA-1 a1 lab123
srxA-2 a2 lab123
srxB-1 b1 lab123
srxB-2 b2 lab123
srxC-1 c1 lab123
srxC-2 c2 lab123
srxD-1 d1 lab123
srxD-2 d2 lab123
lab@srxA-1> telnet local-vr-loopback

Trying 192.168.1.2...
Connected to 192.168.1.2.
Escape character is '^]'.
This device has been configured to run the AJER course

vr-device (ttyp1)
login: username
Password: password
--- JUNOS 11.4R1.6 built 2011-11-15 11:28:05 UTC
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
You must use 'configure private' to configure this router.

a1@vr-device>
Step 2.10
Verify reachability back to your student device’s loopback address from the remote
virtual router. Be sure to source your ping from the correct virtual router routing
instance. Refer to the following table for your assigned instance name.
Note
Keep in mind that when working with
virtual routers and routing instances,
command syntax is different. If needed,
please reference the Detailed Lab Guide for
sample command syntax for the individual
verification tasks performed within this lab.
Routing Instance Names
Student Device Instance Name

srxA-1 vr111
srxA-2 vr112
srxB-1 vr113
srxB-2 vr114
srxC-1 vr115
srxC-2 vr116
srxD-1 vr117
srxD-2 vr118
a1@vr-device> ping routing-instance instance-name student-device-loopback rapid

PING 192.168.1.1 (192.168.1.1): 56 data bytes
!!!!!

Step 2.11
Issue a show route remote-virtual-router-loopback/32 table
instance-name command to view the route table data of the remote team’s
virtual router’s loopback address. Use the table from the previous step for the
instance name.
a1@vr-device> show route remote-virtual-router-loopback/32 table instance-name
vr111.inet.0: 21 destinations, 28 routes (21 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
192.168.2.2/32 *[OSPF/10] 00:03:39, metric 21

> to 172.20.111.1 via ge-0/0/1.111
Question: What is the OSPF cost to reach the

remote virtual router’s loopback address?
Answer: The cost for this route is 21.
Step 2.12
Return to the CLI session on your SRX Series student device.
On the SRX Series student device, configure your device for OSPF overload mode
and activate the change.
lab@srxA-1# set overload

lab@srxA-1# commit
commit complete
Step 2.13
Return to the CLI session on your virtual router.
On your local virtual router, reissue the show route
remote-virtual-router-loopback/32 table instance-name
command.
a1@vr-device> show route remote-virtual-router-loopback/32 table instance-name
vr111.inet.0: 21 destinations, 28 routes (21 active, 0 holddown, 0 hidden)

192.168.2.2/32 *[OSPF/10] 00:00:39, metric 131071

> to 172.20.111.1 via ge-0/0/1.111
a1@vr-device>

Question: Did the metric change? If so, what did it
change to and why?
Answer: Yes, depending on the remote student

team, you might see the metric change to 65546 or
131071. The metric changes because overloading a
router automatically increases its metric by 65535.
Question: Why would you overload a router?
Answer: The main reason for overloading a router is

to force transit traffic off of it. This could be
because of maintenance or if the router is
experiencing other types of trouble.
Step 2.14
Log out of the vr-device and then log out of student device. You can close this
second window because you will not need it anymore.
a1@vr-device> exit
Connection closed by foreign host.
lab@srxA-1> exit
Step 2.15
On the SRX Series student device, delete the overload setting and activate your
changes.
lab@srxA-1# delete overload

lab@srxA-1# commit
commit complete

Part 3: Configuring OSPF Authentication
In this lab part, you configure OSPF authentication on the link between the student
devices. Initially, only team 1 will modify its device’s current configuration to make it
incompatible with team 2’s router. Then, both teams will enable OSPF traceoptions
to log protocol activity and the associated errors. Finally, team 2 will configure its
router to match team 1’s configuration changes.
Step 3.1
This step is for team 1 only.
Configure the ge-0/0/1.0 interface in Area 0 for OSPF Message Digest 5 (MD5)
authentication. Use a password of juniper and a key-id of 1. Activate your
changes when complete.
lab@srxA-1# set area 0 interface ge-0/0/1.0 authentication md5 1 key juniper

lab@srxA-1# commit
commit complete
Step 3.2
This step is for both teams.
Issue a run show ospf neighbor command.
172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 35
172.20.111.10 ge-0/0/4.111 Full 192.168.1.2 128 33
Question: How many OSPF neighbors does your

assigned device currently have?
Answer: At this point, your device should have only

two neighbors (instead of three). The neighbor
adjacency across the ge-0/0/1 interface should no
longer be in place because of team 1’s recent
configuration change. It might take up to forty
seconds for the ge-0/0/1.0 neighbor to drop
because of the OSPF dead timer.
Step 3.3

Define traceoptions for OSPF so that OSPF errors write to a file named
trace-ospf. Include the detail option with the error flag to capture
additional details of the OSPF errors. Activate the configuration change when
completed.
lab@srxA-1# set traceoptions file trace-ospf

lab@srxA-1# set traceoptions flag error detail

lab@srxA-1# commit
commit complete
Step 3.4
Issue the run show log trace-ospf command to view the contents written to
the trace-ospf trace file.
lab@srxA-1# run show log trace-ospf
Feb 22 21:42:24 trace_on: Tracing to "/var/log/trace-ospf" started
Feb 22 21:42:30.224638 OSPF packet ignored: authentication type mismatch (0)
from 172.20.77.2
from 172.20.77.2
from 172.20.77.2
[...]
Question: Does the generated error in the trace file

explain the current OSPF adjacency issue?
Answer: Yes, based on the contents of the trace file,

an authentication mismatch exists.
Step 3.5
This step is for team 2 only.
Configure the ge-0/0/1.0 interface in Area 0 for OSPF MD5 authentication. Use a
password of juniper and a key-id of 1. Activate the changes when completed.
lab@srxA-2# set area 0 interface ge-0/0/1.0 authentication md5 1 key juniper

lab@srxA-2# commit
commit complete

lab@srxA-2#
Step 3.6
Issue a run show ospf neighbor command.
172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 39
172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 37
172.20.111.10 ge-0/0/4.111 Full 192.168.1.2 128 39

lab@srxA-1#
Question: Did the OSPF adjacency across the

ge-0/0/1.0 interface return to the Full state?
Answer: Yes, you should now see all three neighbors

in the Full adjacency state, as shown in the
previous output.
Step 3.7
Deactivate traceoptions and delete the trace-ospf log file. Activate the
configuration and return to operational mode using the commit and-quit
command.
lab@srxA-1# deactivate traceoptions

lab@srxA-1# run file delete /var/log/trace-ospf

lab@srxA-1# commit and-quit
commit complete
Exiting configuration mode
lab@srxA-1>
Step 3.8
Log out of your assigned device using the exit command.
lab@srxA-1> exit

STOP Tell your instructor that you have completed Lab 1.

Lab 2
Configuring and Monitoring OSPF Areas and Route
Summarization (Detailed)
Overview
This lab configures a stub area and a not-so-stubby (NSSA) area, and performs route
summarization. In addition, the stub area will be converted into a totally stubby area using
the no-summaries option.
• Create a stub area.
• Change the stub area to a totally stubby area.
• Create a not-so-stubby area.
• Perform route summarization.
www.juniper.net Configuring and Monitoring OSPF Areas and Route Summarization (Detailed) • Lab 2–1
11.a.11.4R1.6
Part 1: Configuring a Stub Area
In this lab part, you configure an OSPF stub area. You will first prepare your device by
loading a reset configuration file located on your device. You then configure a new
interface and the stub area. Finally, you reconfigure the stub area as a totally stubby
area. For this lab, you will use the network diagram titled “Lab 2 (Stub Area):
Configuring and Monitoring OSPF Areas and Route Summarization.”
Note
device.
Step 1.1


Step 1.2
Lab 2–2 • Configuring and Monitoring OSPF Areas and Route Summarization (Detailed) www.juniper.net
Step 1.3
load override /var/home/lab/ajer/lab2-start.config command.
After the configuration has been loaded, commit the changes before proceeding.
srxA-1 (ttyu0)
login: lab
Password:
--- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC

[edit]
lab@srxA-1# load override ajer/lab2-start.config
load complete
[edit]
lab@srxA-1# commit
commit complete
Step 1.4
Refer to the network diagram and configure the IP address on the ge-0/0/4.unit
interface for the stub area on your assigned device. Use the logical unit value as the
VLAN-ID value for this interface.
[edit]
lab@srxA-1# edit interfaces ge-0/0/4
[edit interfaces ge-0/0/4]

lab@srxA-1# set unit unit vlan-id vlan-id family inet address address/24

lab@srxA-1# show
vlan-tagging;
unit 111 {
vlan-id 111;
family inet {
address 172.20.111.1/24;
}
}
unit 151 {
vlan-id 151;
family inet {
address 172.20.151.1/24;
}
}

lab@srxA-1#
Step 1.5
Navigate to the [edit protocols ospf] hierarchy and configure the OSPF
stub area. Refer to the network diagram to ensure you use the correct area number
for your device .

lab@srxA-1# set area area stub


lab@srxA-1# show area area
stub;
interface ge-0/0/4.151;

lab@srxA-1#
Step 1.6
Activate the configuration and issue the run show ospf neighbor command.
lab@srxA-1# commit
commit complete

172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 35
172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 35
172.20.111.10 ge-0/0/4.111 Full 192.168.1.2 128 33
172.20.151.10 ge-0/0/4.151 Full 192.168.3.2 128 33
Question: Did the new neighbor come up to a Full

state?
Answer: The neighbor state for the new

ge-0/0/4.unit interface should be Full, as
shown in the previous sample output. If you do not
see the Full state for this interface, check your
configuration and, if necessary, work with the
instructor.
Step 1.7
Issue the run show ospf interface detail | find ge-0/0/4
command to see the difference between the non-stub area interface and the new
stub area interface.
lab@srxA-1# run show ospf interface detail | find ge-0/0/4
ge-0/0/4.111 BDR 0.0.0.1 192.168.1.2 192.168.1.1 1
Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: None
ge-0/0/4.151 BDR 0.0.0.3 192.168.3.2 192.168.1.1 1
Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Stub
Auth type: None
Question: Is the new interface correctly set as

Stub?
Answer: The output shows the new interface set as

Stub (as opposed to Not Stub in the non-stub
area). If you do not see this setting, check your
instructor.
Step 1.8
Issue the run show ospf database area area summary and run show
ospf database area area commands to see how many and what types of
link-state advertisements (LSAs) are contained in the OSPF database for your stub
area. Refer to the network diagram as needed for the correct stub area number.
lab@srxA-1# run show ospf database area area summary
Area 0.0.0.3:
2 Router LSAs
1 Network LSAs
10 Summary LSAs
Externals:
6 Extern LSAs
Interface ge-0/0/1.0:
Area 0.0.0.0:
Area 0.0.0.0:
Area 0.0.0.1:
Area 0.0.0.3:
Interface lo0.0:
Area 0.0.0.0:

lab@srxA-1# run show ospf database area area
OSPF database, Area 0.0.0.3

Type ID Adv Rtr Seq Age Opt Cksum Len
Router *192.168.1.1 192.168.1.1 0x80000004 350 0x20 0xf89c 36
Router 192.168.3.2 192.168.3.2 0x80000007 352 0x20 0xed21 48
Network 172.20.151.10 192.168.3.2 0x80000001 352 0x20 0xf799 32
Summary *172.20.66.0 192.168.1.1 0x80000003 350 0x20 0xd597 28
Summary *172.20.77.0 192.168.1.1 0x80000001 356 0x20 0xd8e5 28
Summary *172.20.111.0 192.168.1.1 0x80000001 356 0x20 0x7326 28
Summary *172.20.112.0 192.168.1.1 0x80000001 356 0x20 0xccc1 28
Summary *172.20.152.0 192.168.1.1 0x80000001 348 0x20 0x1353 28
Summary *192.168.1.1 192.168.1.1 0x80000001 356 0x20 0xc7a0 28
Summary *192.168.1.2 192.168.1.1 0x80000001 356 0x20 0x223b 28
Summary *192.168.2.1 192.168.1.1 0x80000001 356 0x20 0x213c 28
Summary *192.168.2.2 192.168.1.1 0x80000001 356 0x20 0x7bd6 28
Summary *192.168.4.2 192.168.1.1 0x80000001 59 0x20 0x65ea 28
OSPF AS SCOPE link state database
Extern 172.21.0.0 192.168.1.2 0x8000007b 1148 0x22 0x2bde 36
Extern 172.21.1.0 192.168.1.2 0x8000007b 560 0x22 0x20e8 36
Extern 172.21.2.0 192.168.1.2 0x8000007a 1898 0x22 0x17f1 36
Extern 172.22.0.0 192.168.2.2 0x8000007b 1661 0x22 0x18ef 36
Extern 172.22.1.0 192.168.2.2 0x8000007b 940 0x22 0xdf9 36
Extern 172.22.2.0 192.168.2.2 0x8000007b 370 0x22 0x204 36
Question: How many summary LSAs are in your stub

area?
Answer: There are ten summary LSAs, as shown in

the previous sample output.
Step 1.9
Convert your stub area to a totally stubby area using the no-summaries option
and activate your changes.
lab@srxA-1# set area area stub no-summaries

stub no-summaries;

lab@srxA-1# commit
commit complete
Step 1.10
ospf database area area commands again.
Area 0.0.0.3:
2 Router LSAs
1 Network LSAs
Externals:
6 Extern LSAs
Area 0.0.0.0:
Area 0.0.0.0:
Area 0.0.0.1:
Area 0.0.0.3:
Interface lo0.0:
Area 0.0.0.0:


Router *192.168.1.1 192.168.1.1 0x80000006 149 0x20 0xf49e 36
Router 192.168.3.2 192.168.3.2 0x80000009 155 0x20 0xe923 48
Network 172.20.151.10 192.168.3.2 0x80000003 155 0x20 0xf39b 32
Extern 172.21.0.0 192.168.1.2 0x8000007b 1376 0x22 0x2bde 36
Extern 172.21.1.0 192.168.1.2 0x8000007b 788 0x22 0x20e8 36
Extern 172.21.2.0 192.168.1.2 0x8000007b 199 0x22 0x15f2 36
Extern 172.22.0.0 192.168.2.2 0x8000007b 1889 0x22 0x18ef 36
Extern 172.22.1.0 192.168.2.2 0x8000007b 1168 0x22 0xdf9 36
Extern 172.22.2.0 192.168.2.2 0x8000007b 598 0x22 0x204 36
Question: How many summary LSAs are now in your

stub area?
Answer: You should not see any summary LSAs in

your stub area’s database. If you do see summary
LSAs, check your configuration and, if necessary,
work with the instructor.
Question: Why are there no summary LSAs?
Answer: In a totally stubby area, summary LSAs are

not allowed. Reachability to external destinations is
accomplished by injecting a default route into the
area.
Step 1.11
Configure the router to inject a default route into the stub area by using the
default-metric option. Give this route a metric of 10 and activate your
changes.
lab@srxA-1# set area area stub default-metric 10

stub default-metric 10 no-summaries;

lab@srxA-1# commit
commit complete
Step 1.12
ospf database area area commands again.
Area 0.0.0.3:
2 Router LSAs
1 Network LSAs
1 Summary LSAs
Externals:
6 Extern LSAs
Area 0.0.0.0:
Area 0.0.0.0:
Area 0.0.0.1:
Area 0.0.0.3:
Interface lo0.0:
Area 0.0.0.0:

Router *192.168.1.1 192.168.1.1 0x80000007 64 0x20 0xf29f 36
Router 192.168.3.2 192.168.3.2 0x80000009 298 0x20 0xe923 48
Network 172.20.151.10 192.168.3.2 0x80000003 298 0x20 0xf39b 32
Summary *0.0.0.0 192.168.1.1 0x80000001 64 0x20 0xf2d6 28
Extern 172.21.0.0 192.168.1.2 0x8000007b 1519 0x22 0x2bde 36
Extern 172.21.1.0 192.168.1.2 0x8000007b 931 0x22 0x20e8 36
Extern 172.21.2.0 192.168.1.2 0x8000007b 342 0x22 0x15f2 36
Extern 172.22.0.0 192.168.2.2 0x8000007c 54 0x22 0x16f0 36
Extern 172.22.1.0 192.168.2.2 0x8000007b 1311 0x22 0xdf9 36
Extern 172.22.2.0 192.168.2.2 0x8000007b 741 0x22 0x204 36
Question: How many summary LSAs are now in your

stub area?
Answer: You should now see one summary LSA in

your stub area’s database with a value of 0.0.0.0.
This is the default route being injected by the ABR. If
you do not see this LSA, check your configuration
and, if necessary, work with the instructor.
Part 2: Configuring an NSSA
In this lab part, you configure an NSSA and perform route summarization on it. For
the remainder of this lab, please refer to the lab diagram titled “Lab 2 (NSSA Area):
Configuring and Monitoring OSPF Areas and Route Summarization.”
Step 2.1
Refer to the network diagram and configure the IP address on the ge-0/0/4.unit
interface for the NSSA area on your assigned device. Use the logical unit value as
the VLAN-ID value for this interface.
lab@srxA-1# top edit interfaces ge-0/0/4

lab@srxA-1# set unit unit vlan-id vlan-id family inet address address/24

lab@srxA-1# show
vlan-tagging;
unit 111 {
vlan-id 111;
family inet {
address 172.20.111.1/24;
}
}
unit 151 {
vlan-id 151;
family inet {
address 172.20.151.1/24;
}
}
unit 161 {
vlan-id 161;
family inet {
address 172.20.161.0/24;
}
}

lab@srxA-1#
Step 2.2
Navigate to the [edit protocols ospf] hierarchy and configure the NSSA
area. Refer to the network diagram to ensure you use the correct area number for
your device.

lab@srxA-1# set area area nssa


nssa;

lab@srxA-1#
Step 2.3
Activate the configuration and issue the run show ospf neighbor command.
lab@srxA-1# commit
commit complete

172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 33
172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 33
172.20.111.10 ge-0/0/4.111 Full 192.168.1.2 128 39
172.20.151.10 ge-0/0/4.151 Full 192.168.3.2 128 36
172.20.161.10 ge-0/0/4.161 Full 192.168.5.2 128 34
Question: Did the new neighbor come up to a full

state?
Answer: The neighbor state for the new

ge-0/0/4.unit interface should be Full, as
shown in the sample output. If you do not see the
Full state for this interface, check your
instructor.
Step 2.4
Issue the run show ospf interface ge-0/0/4.unit detail command
to verify this interface is set as an NSSA interface.
lab@srxA-1# run show ospf interface ge-0/0/4.unit detail
ge-0/0/4.161 BDR 0.0.0.5 192.168.5.2 192.168.1.1 1
Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Stub NSSA
Auth type: None
Question: Is the new interface correctly set as an

NSSA interface?
Answer: The output shows the new interface set as

Stub NSSA. If you do not see this setting, check
your configuration and, if necessary, work with the
instructor.
Note
Step 2.5
ospf database area area nssa commands to see how many and what types
of LSAs are contained in the OSPF database for your NSSA area.
Area 0.0.0.5:
2 Router LSAs
1 Network LSAs
13 Summary LSAs
4 NSSA LSAs
Externals:
14 Extern LSAs
Area 0.0.0.0:
Area 0.0.0.0:
Area 0.0.0.1:
Area 0.0.0.3:
Area 0.0.0.5:
Interface lo0.0:
Area 0.0.0.0:

lab@srxA-1# run show ospf database area area nssa

NSSA 172.61.0.0 192.168.5.2 0x80000004 76 0x28 0xc31d 36
NSSA 172.61.1.0 192.168.5.2 0x80000003 2474 0x28 0xba26 36
NSSA 172.61.2.0 192.168.5.2 0x80000003 1875 0x28 0xaf30 36
NSSA 172.61.3.0 192.168.5.2 0x80000003 1276 0x28 0xa43a 36
Question: How many NSSA LSAs are in your NSSA

area’s database?
Answer: There should be four NSSA LSAs. If not,

check your configuration and, if necessary, work
with the instructor.
Step 2.6
Issue the run show ospf database external command to see external
LSAs contained in the OSPF database.
lab@srxA-1# run show ospf database external
Extern 172.21.0.0 192.168.1.2 0x8000007b 1941 0x22 0x2bde 36
Extern 172.21.1.0 192.168.1.2 0x8000007b 1353 0x22 0x20e8 36
Extern 172.21.2.0 192.168.1.2 0x8000007b 764 0x22 0x15f2 36
Extern 172.22.0.0 192.168.2.2 0x8000007c 476 0x22 0x16f0 36
Extern 172.22.1.0 192.168.2.2 0x8000007b 1733 0x22 0xdf9 36
Extern 172.22.2.0 192.168.2.2 0x8000007b 1163 0x22 0x204 36
Extern *172.61.0.0 192.168.1.1 0x80000001 165 0x22 0x628e 36
Extern *172.61.1.0 192.168.1.1 0x80000001 165 0x22 0x5798 36
Extern *172.61.2.0 192.168.1.1 0x80000001 165 0x22 0x4ca2 36
Extern *172.61.3.0 192.168.1.1 0x80000001 165 0x22 0x41ac 36
Extern 172.62.0.0 192.168.2.1 0x80000001 203 0x22 0x5c91 36
Extern 172.62.1.0 192.168.2.1 0x80000001 203 0x22 0x519b 36
Extern 172.62.2.0 192.168.2.1 0x80000001 203 0x22 0x46a5 36
Extern 172.62.3.0 192.168.2.1 0x80000001 203 0x22 0x3baf 36
Question: Are the external LSAs that describe the

remote team’s NSSA routes present?
Answer: Yes, they are present. The example output

is from the srxX-1 router, so the remote team’s
NSSA LSAs are the four 172.62.x.x entries. From the
perspective of the srxX-2 router, the remote team’s
NSSA LSAs are the 172.61.x.x entries. Note that no
summary route exists for these networks.
Question: How many external LSAs are present?
Answer: There are 14 external LSAs, as shown in

the example output.
Step 2.7
Each of the external NSSA destinations is represented by a /24 network. Choose
one of the remote team’s destinations and issue a run show route
destination command for that destination.
lab@srxA-1# run show route destination
inet.0: 38 destinations, 38 routes (38 active, 0 holddown, 0 hidden)

172.62.0.0/24 *[OSPF/150] 00:06:01, metric 0, tag 0

> to 172.20.77.2 via ge-0/0/1.0
Step 2.8
You will now summarize your four networks into one /22 network using the
area-range option. Ensure you set this command within the [edit protocols
ospf area area nssa] hierarchy of the configuration. Commit your changes
when completed and exit to operational mode.
lab@srxA-1# set area area nssa area-range summary-address/22

nssa {
area-range 172.61.0.0/22;
}

commit complete
lab@srxA-1>
Note
Step 2.9
Issue the show ospf database external command to view the external LSAs
present in the OSPF database.
lab@srxA-1> show ospf database external
Extern 172.21.0.0 192.168.1.2 0x8000007b 2294 0x22 0x2bde 36
Extern 172.21.1.0 192.168.1.2 0x8000007b 1706 0x22 0x20e8 36
Extern 172.21.2.0 192.168.1.2 0x8000007b 1117 0x22 0x15f2 36
Extern 172.22.0.0 192.168.2.2 0x8000007c 829 0x22 0x16f0 36
Extern 172.22.1.0 192.168.2.2 0x8000007c 251 0x22 0xbfa 36
Extern 172.22.2.0 192.168.2.2 0x8000007b 1516 0x22 0x204 36
Extern *172.61.0.0 192.168.1.1 0x80000002 46 0x22 0x3d21 36
Extern 172.62.0.0 192.168.2.1 0x80000002 30 0x22 0x2a32 36
Question: Were the changes successful? How can
you tell?
Answer: Yes, the changes were successful. Instead

of eight total LSAs representing the 172.6x.x.x
routes, we now have two. This has resulted in a
smaller link-state database and demonstrates one
mechanism you can use to scale OSPF networks.
Step 2.10
Choose one of the remote team’s destinations and issue a show route
destination command for that destination to verify the router is using the /22
summary route instead of the original /24 route.
lab@srxA-1> show route destination

172.62.0.0/22 *[OSPF/150] 00:01:12, metric 1, tag 0

> to 172.20.77.2 via ge-0/0/1.0
Step 2.11
lab@srxA-1> exit
Lab 3
Configuring and Monitoring Routing Policy and Advanced
OSPF Options (Detailed)
Overview
In this lab, you will use the lab diagram titled “Lab 3: Configuring and Monitoring Routing
Policy and Advanced OSPF Options” to establish a multiarea OSPF routing domain. This
lab will require the configuration of a virtual link as backup to the backbone connection
and a multiarea adjacency as outlined in RFC 5185. The final part of this lab will require
routing policy to redistribute and advertise routes being received from a RIP network into
OSPF external link-state advertisements (LSAs).
• Load the default configuration.
• Establish multiple OSPF adjacencies.
• Configure and verify a virtual link.
• Configure and verify a OSPF multiarea adjacency.
• Establish a RIP neighbor peer session.
• Write a routing policy to advertise a default route into RIP.
• Configure prefix-limits in OSPF to prevent excessive external routes.
• Write a routing policy to advertise a RIP summary route into OSPF.
• Write an OSPF import policy to prevent less than optimal routing.
www.juniper.net Configuring and Monitoring Routing Policy and Advanced OSPF Options (Detailed) • Lab 3–1
11.a.11.4R1.6
Part 1: Establishing the OSPF Adjacencies and Creating a Virtual Tunnel
In this lab part, you load the reset configuration for this lab and then establish the
OSPF adjacencies. The virtual router device (vr-device) will provide connectivity for
all three OSPF areas between your student device and your partners.
Note
device.
Step 1.1


Step 1.2
Lab 3–2 • Configuring and Monitoring Routing Policy and Advanced OSPF Options (Detailed) www.juniper.net
Step 1.3
srxA-1 (ttyu0)
login: lab
Password:
--- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC

[edit]
load complete
[edit]
lab@srxA-1# commit
commit complete
Step 1.4
Navigate to the [edit protocols ospf] hierarchy. Establish the OSPF
adjacencies with the P1, P2, and R3 routers attached to your student device.
Configure OSPF Area 10 as a not-so-stubby area (NSSA) and advertise a default
route with a metric of 10. Do not forget the loopback address in Area 0. Commit the
configuration when complete.
[edit]
lab@srxA-1# edit protocols ospf

lab@srxA-1# set area 0 interface lo0.0

lab@srxA-1# set area 0 interface P1-interface

lab@srxA-1# set area 20 interface P2-interface

lab@srxA-1# set area 10 nssa default-lsa default-metric 10

lab@srxA-1# set area 10 interface ge-0/0/14
lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 1.5
Use the run show ospf interface command to verify which interfaces are
participating in OSPF.
ge-0/0/4.1211 BDR 0.0.0.0 192.168.100.1 192.168.1.1 1
lo0.0 DR 0.0.0.0 192.168.1.1 0.0.0.0 0
ge-0/0/14.0 BDR 0.0.0.10 192.168.1.2 192.168.1.1 1
ge-0/0/4.1213 BDR 0.0.0.20 192.168.101.1 192.168.1.1 1
Question: How many interfaces are running OSPF?
Answer: Three transit interfaces and the loopback

interface exist, for a total of four interfaces running
OSPF.
Step 1.6
Use the run show ospf neighbor command to verify the establishment of the
OSPF adjacencies.
172.22.121.2 ge-0/0/4.1211 Full 192.168.100.1 128 33
10.0.10.2 ge-0/0/14.0 Full 192.168.1.2 128 37
172.22.123.2 ge-0/0/4.1213 Full 192.168.101.1 128 35
Question: Are all OSPF adjacencies established and

in the Full state?
Answer: Yes, three OSPF adjacencies should be

established, one in each OSPF area.
Step 1.7
Verify that the routing table has connectivity to all devices in the OSPF domain. Use
the run show route protocol ospf table inet.0 | match /32
command to display only the host addresses.
lab@srxA-1# run show route protocol ospf table inet.0 | match /32
192.168.1.2/32 *[OSPF/10] 00:03:07, metric 1
192.168.2.1/32 *[OSPF/10] 00:02:22, metric 2
192.168.2.2/32 *[OSPF/10] 00:03:07, metric 3
192.168.100.1/32 *[OSPF/10] 00:02:57, metric 1
192.168.101.1/32 *[OSPF/10] 00:02:57, metric 1
192.168.102.1/32 *[OSPF/10] 00:03:07, metric 2
224.0.0.5/32 *[OSPF/10] 00:03:12, metric 1
Question: Is there an entry in the primary routing

table (inet.0) for all six loopback addresses
within the OSPF domain?
Answer: Yes, if your partner has successfully

configured OSPF, six host addresses should exist in
the inet.0 routing table, one for each loopback
address.
Step 1.8
Navigate to the [edit protocols ospf area 0.0.0.0] hierarchy. Create a
virtual link in OSPF Area 0 through Area 20 using the OSPF virtual-link
command. The virtual-link neighbor-id is the loopback address of your
partner’s student device. The virtual link should be used only as a backup in the
event of an P1 failure. This can be accomplished by setting the P2 interface in Area
20 to a metric of 10. Commit this configuration when completed.
lab@srxA-1# edit area 0
[edit protocols ospf area 0.0.0.0]

lab@srxA-1# set virtual-link transit-area 20 neighbor-id address

lab@srxA-1# up

lab@srxA-1# set area 20 interface P2-interface metric 10

lab@srxA-1# commit
commit complete
Step 1.9
Use the run show ospf interface command to verify that the virtual link has
been established and that an adjacency has been formed.
ge-0/0/4.1211 BDR 0.0.0.0 192.168.100.1 192.168.1.1 1
lo0.0 DR 0.0.0.0 192.168.1.1 0.0.0.0 0
vl-192.168.2.1 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/14.0 BDR 0.0.0.10 192.168.1.2 192.168.1.1 1
ge-0/0/4.1213 BDR 0.0.0.20 192.168.101.1 192.168.1.1 1
Question: Which type of interface is created for the

virtual link?
Answer: A point-to-point interface is created for the

virtual link.
Step 1.10
Use the run show ospf neighbor command to verify that the virtual link has
established an adjacency.
172.22.121.2 ge-0/0/4.1211 Full 192.168.100.1 128 33
172.22.124.1 vl-192.168.2.1 Full 192.168.2.1 0 34
10.0.10.2 ge-0/0/14.0 Full 192.168.1.2 128 35
172.22.123.2 ge-0/0/4.1213 Full 192.168.101.1 128 34
Question: What is the adjacency state of the virtual

link interface?
Answer: The state should be Full.
Step 1.11
Use the run show route address/32 table inet.0 command to verify
that your partner’s default loopback address routes through the P1 router and not
through the virtual link. Refer to the network diagram as needed.
lab@srxA-1# run show route address/32 table inet.0

192.168.2.1/32 *[OSPF/10] 00:10:21, metric 2

> to 172.22.121.2 via ge-0/0/4.1211
Question: Does the route to your partner’s loopback
address go through the P1 router or the virtual link?
Answer: Yes, the route to the loopback address of

your partner’s student device should be using the
P1 router and not the virtual link.
Part 2: Configuring OSPF Multiarea
In this lab part, you configure an OSPF multiarea adjacency to provide an alternate
path for OSPF Area 10.
Step 2.1
Navigate to the [edit protocols ospf area 0.0.0.10] hierarchy and
establish an OSPF Area 10 adjacency through the P1 router. You will add the P1
interface to Area 10 with the secondary setting. This will provide a backup path for
Area 10 in the event of a P3 failure. Ensure that this backup path is only used in the
event of a P3 failure. This can be accomplished by setting the newly configured
interface with a higher metric. Commit these changes when completed.
lab@srxA-1# edit area 10

lab@srxA-1# set interface P1-interface secondary

lab@srxA-1# set interface P1-interface metric 10

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 2.2
Use the run show ospf interface command to verify the multiarea
adjacency.
ge-0/0/4.1211 BDR 0.0.0.0 192.168.100.1 192.168.1.1 1
lo0.0 DR 0.0.0.0 192.168.1.1 0.0.0.0 0
vl-192.168.2.1 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/14.0 BDR 0.0.0.10 192.168.1.2 192.168.1.1 1
ge-0/0/4.1211 PtToPt 0.0.0.10 0.0.0.0 0.0.0.0 1
ge-0/0/4.1213 BDR 0.0.0.20 192.168.101.1 192.168.1.1 1
Question: Area 10 now has two interfaces in it.
What is the state for the interface you just added to
Area 10? Why?
Answer: The established interface state for Area 10

is point-to-point. As outlined in RFC 5185, all
secondary multiarea adjacencies will be formed
using a point-to-point interface.
Step 2.3
Use the run show ospf neighbor command to verify the establishment of an
OSPF Area 10 adjacency through the P1 router.
172.22.121.2 ge-0/0/4.1211 Full 192.168.100.1 128 33
Area 0.0.0.0
172.22.124.1 vl-192.168.2.1 Full 192.168.2.1 0 35
Area 0.0.0.0
10.0.10.2 ge-0/0/14.0 Full 192.168.1.2 128 31
Area 0.0.0.10
172.22.121.2 ge-0/0/4.1211 Full 192.168.100.1 128 32
Area 0.0.0.10
172.22.123.2 ge-0/0/4.1213 Full 192.168.101.1 128 39
Area 0.0.0.20
Question: How many OSPF adjacencies exist for

Area 0.0.0.10?
Answer: Two adjacencies have been formed within

OSPF Area 0.0.0.10.
Step 2.4
Verify that the loopback address of your partner’s R3 virtual router is being routed
through the ge-0/0/14.0 interface toward your R3 virtual router. Use the run show
route address/32 table inet.0 command to display the path of the route.

192.168.2.2/32 *[OSPF/10] 00:22:19, metric 3

> to 10.0.10.2 via ge-0/0/14.0
Question: What is the primary path to your partner’s
virtual router’s loopback address?
Answer: The primary path to your partner’s virtual

router’s loopback address is through your R3 virtual
router.
Step 2.5
Navigate to the [edit routing-instances instance-name protocols
ospf] hierarchy. The value of instance-name is the name of your remote virtual
router (either R3-1 or R3-2) depending on your assigned student device. Deactivate
your R3 virtual router’s Area 10 interface connected to the P3 router. Commit the
configuration when completed.
lab@srxA-1# top edit routing-instances instance-name protocols ospf
[edit routing-instances R3-1 protocols ospf]

lab@srxA-1# deactivate area 10 interface R3-to-P3-interface

lab@srxA-1# show
area 0.0.0.10 {
nssa;
inactive: interface ge-0/0/4.1215;
interface lo0.1;
}

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 2.6
Issue the run show route address/32 table inet.0 command again to
verify the route to your partner’s remote virtual router’s loopback address has
converged through the P1 router, thus using the multiarea adjacency.

192.168.2.2/32 *[OSPF/10] 00:00:42, metric 12

> to 172.22.121.2 via ge-0/0/4.1211
Question: Did the route converge through the
multiarea adjacency?
Answer: Yes, the route has now converged through

the backup multiarea adjacency.
Step 2.7
Navigate to the top of the configuration hierarchy. Use the rollback 1 command
to reactivate the interface between your R3 virtual router and the P3 router. Commit
the configuration when complete.
lab@srxA-1# top
[edit]
lab@srxA-1# rollback 1
load complete
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
Step 2.8
Verify that OSPF converged back to the primary path by displaying your partner’s
loopback address using the run show route address/32 table inet.0
command.
[edit]

192.168.2.2/32 *[OSPF/10] 00:00:03, metric 3

> to 10.0.10.2 via ge-0/0/14.0
Question: Did the route converge back to your R3

virtual router?
Answer: Yes, the route has converged back to the

R3 router.
Part 3: Configuring External Reachability
In this lab part, you configure an external connection from the R3 routing instance to
a RIP network. Once established, the RIP routes will be redistributed into OSPF.
Note
In this lab part, you will be configuring and
displaying commands in the virtual routing
instance. When referencing the routing
instance, the commands will include the
routing instance name, R3-N, where N is
the user number (1 or 2). Refer to the lab
diagram for the correct user number to use.
Step 3.1
Navigate to the [edit routing-instances instance-name] hierarchy.
Remove the R3-to-P3 interface from OSPF Area 10 and reconfigure that interface as
a RIP interface. Use a RIP group name of P3. Commit the configuration when
complete.
[edit]
lab@srxA-1# edit routing-instances instance-name
[edit routing-instances R3-1]

lab@srxA-1# delete protocols ospf area 10 interface R3-to-P3-interface

lab@srxA-1# set protocols rip group P3 neighbor R3-to-P3-interface

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 3.2
Use the run show route receive-protocol rip address table
instance-name command to verify that RIP routes are being received from the
P3 router. The address value will be 172.22.125.2 or 172.22.126.2 depending on
your assigned student device. Please refer to the network diagram as needed.
lab@srxA-1# run show route receive-protocol rip address table instance-name
R3-1.inet.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden)

20.20.0.0/21 *[RIP/100] 00:00:40, metric 2, tag 0
> to 172.22.125.2 via ge-0/0/4.1215
20.20.0.0/24 *[RIP/100] 00:00:40, metric 2, tag 0
> to 172.22.125.2 via ge-0/0/4.1215
20.20.1.0/24 *[RIP/100] 00:00:40, metric 2, tag 0
> to 172.22.125.2 via ge-0/0/4.1215
20.20.2.0/24 *[RIP/100] 00:00:40, metric 2, tag 0
> to 172.22.125.2 via ge-0/0/4.1215
20.20.3.0/24 *[RIP/100] 00:00:40, metric 2, tag 0
> to 172.22.125.2 via ge-0/0/4.1215
20.20.4.0/25 *[RIP/100] 00:00:40, metric 2, tag 0
> to 172.22.125.2 via ge-0/0/4.1215
20.20.4.128/25 *[RIP/100] 00:00:40, metric 2, tag 0
> to 172.22.125.2 via ge-0/0/4.1215
20.20.5.0/26 *[RIP/100] 00:00:40, metric 2, tag 0
> to 172.22.125.2 via ge-0/0/4.1215
20.20.5.64/26 *[RIP/100] 00:00:40, metric 2, tag 0
> to 172.22.125.2 via ge-0/0/4.1215
20.20.5.128/26 *[RIP/100] 00:00:40, metric 2, tag 0
> to 172.22.125.2 via ge-0/0/4.1215
20.20.5.192/26 *[RIP/100] 00:00:40, metric 2, tag 0
> to 172.22.125.2 via ge-0/0/4.1215
Question: How many routes are you receiving from

the P3 RIP router?
Answer: You should be receiving 11 routes.
Step 3.3
Use the run show route 0/0 exact table instance-name command to
verify your R3 virtual router has an OSPF default route that routes toward your
assigned student device.
lab@srxA-1# run show route 0/0 exact table instance-name

0.0.0.0/0 *[OSPF/150] 00:30:41, metric 11, tag 0

> to 10.0.10.1 via ge-0/0/15.0
Step 3.4
Navigate to the [edit policy-options policy-statement
export-default] hierarchy. Create a routing policy to advertise the OSPF
default route to the RIP router. Do not commit your changes at this time.
lab@srxA-1# top edit policy-options policy-statement export-default
[edit policy-options policy-statement export-default]
lab@srxA-1# set term 1 from protocol ospf

lab@srxA-1# set term 1 from route-filter 0.0.0.0/0 exact

lab@srxA-1# set term 1 then accept

lab@srxA-1# show
term 1 {
from {
protocol ospf;
route-filter 0.0.0.0/0 exact;
}
then accept;
}

lab@srxA-1#
Note
The next two steps must be coordinated
with your remote team partners.
Step 3.5
This step is to be performed by Team 1 only. Team 2 will perform the same step after
waiting two minutes from the time of this commit.
Apply the policy as an export policy in the P3 RIP group configured previously.
Commit the configuration when complete.
lab@srxA-1# top edit routing-instances instance-name

lab@srxA-1# set protocols rip group P3 export export-default

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 3.6
This step is to be performed by Team 2 only after waiting two minutes from the
commit time of the previous step.
Apply the policy as an export policy in the P3 RIP group configured previously.
Commit the configuration when complete.

lab@srxA-2# set protocols rip group P3 export export-default

lab@srxA-2# commit
commit complete

lab@srxA-2#
Step 3.7
Use the run show route advertising-protocol rip address table
instance-name command to verify that the default route is being advertised to
the P3 router. The address value will be 172.22.125.1 or 172.22.126.1 depending
on your assigned student device. Please refer to the network diagram as needed.
Note
The output from both routers is shown in
the following capture.

lab@srxA-1# run show route advertising-protocol rip address table instance-name

0.0.0.0/0 *[OSPF/150] 00:34:57, metric 11, tag 0

> to 10.0.10.1 via ge-0/0/15.0
..........................................................................

[blank output]
Question: Is the default route being advertised to
R3?
Answer: The answer depends on which router

advertised the default route first. One of the routers
will not be advertising the route because its active
route for the 0/0 default route is a RIP route, not an
OSPF route. This is because the RIP preference of
100 is lower than the OSPF external preference of
150. Recall that the export-default policy you
just applied uses a from protocol ospf in its
term. Policy can only act upon active routes.
Therefore, in the previous output, the R3-2 router
cannot advertise the route. We will demonstrate
this issue and fix it in subsequent steps.
Step 3.8
Display the default route in the R3 routing table using the run show route 0/0
exact table instance-name command.
Note


0.0.0.0/0 *[OSPF/150] 00:35:50, metric 11, tag 0

> to 10.0.10.1 via ge-0/0/15.0
..........................................................................


0.0.0.0/0 *[RIP/100] 00:03:25, metric 2, tag 0

> to 172.22.126.2 via ge-0/0/4.1216
[OSPF/150] 00:35:34, metric 11, tag 0
> to 10.0.20.1 via ge-0/0/15.0
Question: What is the active protocol for the default
route?
Answer: The answer depends on which router

advertised the default route first. Based on the
previous output for the srxA-1 router, the active
protocol for the default route is OSPF. For the srxA-2
router, the active protocol for the default route is
RIP, because the preference of RIP (100) is lower
than the external preference of OSPF (150).
Step 3.9
Using the external-preference option, set the external preference of OSPF to
90 (which is less than the RIP preference of 100) for the R3 virtual router. Commit
the changes when complete.
lab@srxA-1# set protocols ospf external-preference 90

lab@srxA-1# commit
commit complete
Step 3.10
Use the run show route advertising-protocol rip address table
instance-name command to verify that the default route is being advertised to
the P3 router. The address value will be 172.22.125.1 or 172.22.126.1 depending
on your assigned student device. Please refer to the network diagram as needed.
Note


0.0.0.0/0 *[OSPF/90] 00:00:11, metric 11, tag 0

> to 10.0.10.1 via ge-0/0/15.0
..........................................................................

0.0.0.0/0 *[OSPF/90] 00:00:16, metric 11, tag 0

> to 10.0.20.1 via ge-0/0/15.0
Question: Is the route now being advertised to the

RIP network?
Answer: Yes, the lower OPSF preference has made

the default route active under OSPF, which matches
the RIP export policy and allows it to be advertised.
Step 3.11
import-rip-route] hierarchy. Create a policy to accept only the 20.20.0.0/21
RIP summary route from the P3 RIP router.
lab@srxA-1# top edit policy-options policy-statement import-rip-route
[edit policy-options policy-statement import-rip-route]

lab@srxA-1# set term 1 from protocol rip

lab@srxA-1# set term 1 from route-filter 20.20.0.0/21 exact



lab@srxA-1# set term 2 from route-filter 20.20.0.0/21 longer

lab@srxA-1# set term 2 then reject

lab@srxA-1# show
term 1 {
from {
protocol rip;
}
then accept;
}
term 2 {
from {
protocol rip;
route-filter 20.20.0.0/21 longer;
}
then reject;
}

lab@srxA-1#
Step 3.12
Navigate to the [edit routing-instances instance-name] hierarchy and
apply the import-rip-route policy as an import policy under the P3 group in
protocols RIP. Commit the configuration when complete.

lab@srxA-1# set protocols rip group P3 import import-rip-route

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 3.13
Use the run show route receive-protocol rip address table
instance-name command to verify that RIP routes are being received from the
P3 router. The address value will be 172.22.125.2 or 172.22.126.2 depending on
your assigned student device. Verify that only the summary route is now being
received from the P3 RIP router.
lab@srxA-1# run show route receive-protocol rip address table instance-name

20.20.0.0/21 *[RIP/100] 00:10:57, metric 2, tag 0

> to 172.22.125.2 via ge-0/0/4.1215
Question: Is the RIP import policy working?
Answer: Because only the summary route (instead

of the 11 original routes) is being accepted from the
RIP neighbor, it appears that the import policy is
working.
Step 3.14
export-rip-route] hierarchy. Create a routing policy to redistribute the RIP
summary route into OSPF. Do not commit the configuration at this time.
lab@srxA-1# top edit policy-options policy-statement export-rip-route
[edit policy-options policy-statement export-rip-route]



lab@srxA-1# show
term 1 {
from protocol rip;
then accept;
}

lab@srxA-1#
Step 3.15
This step is to be performed by Team 1 only. Team 2 will perform the same step after
waiting two minutes from the time of this commit.
Before applying the policy as an OSPF export policy, protect the network from
unnecessary routes by configuring a prefix export limit of 1 using the
prefix-export-limit command within protocols ospf. Commit the

lab@srxA-1# set protocols ospf prefix-export-limit 1

lab@srxA-1# set protocols ospf export export-rip-route

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 3.16
This step is to be performed by Team 2 only after waiting two minutes from the
commit time of the previous step.
Before applying the policy as an OSPF export policy, protect the network from
unnecessary routes by configuring a prefix export limit of 1 using the
prefix-export-limit command within protocols ospf. Commit the

lab@srxA-2# set protocols ospf prefix-export-limit 1

lab@srxA-2# set protocols ospf export export-rip-route

lab@srxA-2# commit
commit complete

lab@srxA-2#
Step 3.17
Verify connectivity to the RIP network by performing a trace to the RIP router using
the redistributed RIP summary route. Use the run traceroute 20.20.1.1
routing-instance instance-name command to verify connectivity.
Note

lab@srxA-1# run traceroute 20.20.1.1 routing-instance instance-name
traceroute to 20.20.1.1 (20.20.1.1), 30 hops max, 40 byte packets
1 172.22.125.2 (172.22.125.2) 7.667 ms !N 1.380 ms !N 1.467 ms !N
...........................................................................

lab@srxA-2# run traceroute 20.20.1.1 routing-instance instance-name
1 10.0.20.1 (10.0.20.1) 7.970 ms 8.496 ms 8.568 ms
2 172.22.122.2 (172.22.122.2) 1.834 ms 1.904 ms 7.883 ms
3 172.22.121.1 (172.22.121.1) 8.252 ms 8.202 ms 8.604 ms
4 10.0.10.2 (10.0.10.2) 14.501 ms 8.515 ms 8.537 ms
5 172.22.125.2 (172.22.125.2) 2.937 ms !N 2.626 ms !N 2.220 ms !N
Question: What could be causing the suboptimal
path to the RIP network?
Answer: When multiple area border routers (ABRs)

are present in an NSSA area, only the ABR with the
highest router ID will translate the Type 7 LSA to a
Type 5 LSA. This causes the less than optimal
routing we see in this case. We demonstrate how to
find this information in subsequent steps.
Step 3.18
Examine the OSPF Type 7 LSA to Type 5 LSA conversion between the OSPF NSSA
area and the OSPF backbone area. Use the run show ospf database area
10 nssa detail command to display the Type 7 LSAs and the run show ospf
database external detail command to display the Type 5 LSA.
lab@srxA-1# run show ospf database area 10 nssa detail

NSSA *0.0.0.0 192.168.1.1 0x80000002 1621 0x20 0xc8f3 36
mask 0.0.0.0
Topology default (ID 0)
Type: 1, Metric: 10, Fwd addr: 0.0.0.0, Tag: 0.0.0.0
NSSA 0.0.0.0 192.168.2.1 0x80000002 980 0x20 0xc1f9 36
mask 0.0.0.0
NSSA 20.20.0.0 192.168.1.2 0x80000001 164 0x28 0xbfee 36
mask 255.255.248.0

lab@srxA-1# run show ospf database external detail
Extern 20.20.0.0 192.168.100.1 0x80000001 168 0x22 0x84cf 36
mask 255.255.248.0
Question: Which router created the Type 7 LSA for
the 20.20.0.0 prefix? Which ABR created the Type 5
external LSA for the 20.20.0.0 prefix? Why?
Answer: The R3-1 router created the Type 7 LSA.

However, the P1 router created the Type 5 LSA. The
P1 router has the highest router ID between the
three ABRs connected to OSPF NSSA Area 10. It
might not appear that the P1 router is an ABR for
Area 10, but recall the Area 10 multiarea link we
created through P1. This multiarea link is what
allows P1 to be an ABR within Area 10. We will work
around this issue in the next step.
Step 3.19
ospf-import] hierarchy. Create an OSPF import policy to block the RIP summary
route from being installed in the routing table from OSPF.
lab@srxA-1# top edit policy-options policy-statement ospf-import
[edit policy-options policy-statement ospf-import]

lab@srxA-1# set term 1 from route-filter 20.20.0.0/21 orlonger

lab@srxA-1# set term 1 then reject

lab@srxA-1# show
term 1 {
from {
route-filter 20.20.0.0/21 orlonger;
}
then reject;
}

lab@srxA-1#
Step 3.20
Navigate to the [edit routing-instances instance-name] hierarchy and
apply the ospf-import policy as an import policy in OSPF. Commit the changes
when complete and return to operational mode.

lab@srxA-1# set protocols ospf import ospf-import

commit complete
lab@srxA-1>
Step 3.21
Verify that the OSPF import policy is working and that optimal routing is being
performed to the RIP network by using the traceroute 20.20.1.1
routing-instance instance-name command.
lab@srxA-1> traceroute 20.20.1.1 routing-instance instance-name
1 172.22.125.2 (172.22.125.2) 1.539 ms !N 1.358 ms !N 7.054 ms !N
Question: Is the OSPF import policy working?
Answer: Yes, the OSPF import policy is providing an

optimal path to the RIP network.
Step 3.22
lab@srxA-1> exit
Lab 4
Implementing BGP (Detailed)
Overview
In this lab, you will use the Lab 4 network diagrams to establish a BGP network. After
verifying the baseline OSPF topology, a full mesh of internal BGP (IBGP) sessions must be
established between all routers in your autonomous system (AS), AS 64700. The EBGP
neighboring routers are in AS 65510 and AS 65520. You will establish EBGP peering
sessions with the locally connected provider edge (PE) routers.
This lab will require the configuration of both IBGP and EBGP peering sessions.
each step, and a detailed format that offers step-by-step instructions complete with
• Load a baseline configuration.
• Verify OSPF neighbor relationships and Internet reachability.
• Establish IBGP peering sessions.
• Establish EBGP peering sessions with multipath.
• Use policy to summarize IBGP routes.
• Establish an EBGP peering session with multihop.
www.juniper.net Implementing BGP (Detailed) • Lab 4–1

11.a.11.4R1.6
Part 1: Loading the Baseline Interface and OSPF Configuration
In this lab part, you load a baseline configuration that will automatically set up your
router according to the lab diagram labeled “Lab 4: Implementing BGP—Part 1.”
Next, you verify router-to-router connectivity and OSPF operations using the
command-line interface (CLI).
Step 1.1


Step 1.2
Step 1.3
Lab 4–2 • Implementing BGP (Detailed) www.juniper.net

srxA-1 (ttyu0)
login: lab
Password:
--- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC

[edit]
load complete
[edit]
lab@srxA-1# commit
commit complete
Step 1.4
Use the run ping address rapid command to ping the far-end IP address of
each of the five interfaces attached to your student device. This action verifies that
each interface has been configured properly. Refer to your network diagram as
needed.
[edit]
lab@srxA-1# run ping address rapid
PING 172.18.1.1 (172.18.1.1): 56 data bytes
!!!!!
[edit]
PING 172.18.11.1 (172.18.11.1): 56 data bytes
!!!!!
[edit]
PING 172.20.66.2 (172.20.66.2): 56 data bytes
!!!!!
[edit]
PING 172.20.77.2 (172.20.77.2): 56 data bytes
!!!!!

[edit]
PING 172.20.111.10 (172.20.111.10): 56 data bytes
!!!!!
--- 172.20.111.10 ping statistics ---
Question: Were all of the interface IP addresses

reachable?
Answer: Yes, all interface IP addresses should be

reachable. If any of the interface IP addresses were
not reachable, check your interface configuration to
determine whether any mistakes exist. Ask your
instructor for help if needed.
Step 1.5
Use the run show ospf interface and run show ospf neighbor
commands to confirm that OSPF has been configured properly and that adjacencies
have been established between neighboring routers.
[edit]
ge-0/0/1.0 BDR 0.0.0.0 192.168.2.1 192.168.1.1 1
ge-0/0/2.0 BDR 0.0.0.0 192.168.2.1 192.168.1.1 1
ge-0/0/3.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
ge-0/0/4.1121 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
lo0.0 DR 0.0.0.0 192.168.1.1 0.0.0.0 0
ge-0/0/4.111 BDR 0.0.0.1 192.168.1.2 192.168.1.1 1
[edit]
172.20.77.2 ge-0/0/1.0 Full 192.168.2.1 128 36
172.20.66.2 ge-0/0/2.0 Full 192.168.2.1 128 38
172.20.111.10 ge-0/0/4.111 Full 192.168.1.2 128 32
Question: Are the adjacencies established between

your router and the two neighboring routers?
Answer: Yes, you should have three established

adjacencies. If you do not have three adjacencies,
check your configuration to determine whether any
mistakes exist. Ask your instructor for help if
needed.
Part 2: Configuring IBGP
In this lab part, you use the lab diagram called “Lab 4: Implementing BGP—
Parts 2–4” to configure and monitor IBGP. You first define the AS number for your
device. Next, you establish IBGP peering sessions using loopback addresses. You
then monitor the established IBGP peering sessions using CLI operational mode
commands.
Step 2.1
Navigate to the [edit routing-options] hierarchy. Define the AS number
designated for your network. Refer to the network diagram for this lab as necessary.
[edit]
lab@srxA-1# edit routing-options
lab@srxA-1# set autonomous-system 64700
lab@srxA-1#
Step 2.2
Navigate to the [edit protocols bgp] hierarchy. Configure an IBGP group
named my-int-group that includes the three devices within your assigned
network as IBGP peers. Use the loopback address assigned to your device as the
local-address and the remote loopback addresses of the other three devices
within your AS number as the neighbor addresses. When you are satisfied with
the newly defined BGP configuration, issue the commit command to activate the
changes.
lab@srxA-1# top edit protocols bgp
[edit protocols bgp]

lab@srxA-1# set group my-int-group type internal

lab@srxA-1# set group my-int-group local-address local-loopback-address

lab@srxA-1# set group my-int-group neighbor remote-loopback-address



lab@srxA-1# show

group my-int-group {
type internal;
local-address 192.168.1.1;
neighbor 192.168.1.2;
neighbor 192.168.2.1;
neighbor 192.168.2.2;
}

lab@srxA-1# commit
commit complete

lab@srxA-1#
Question: Was the commit operation successful?
Answer: The commit operation should have been

successful. If not, check your configuration to
ensure that you did not make any mistakes. Be sure
that you either specify a session type of internal or
define a peer AS number for the BGP group that
matches the locally defined AS number (64700).
For external peering sessions, you can specify the
external session type and define the remote peer
AS number or, because the system assumes the
external session type by default, simply define the
remote peer AS number.
Note
previous step.
Step 2.3
Issue the run show bgp summary command to view the current BGP summary
information for your device.
lab@srxA-1# run show bgp summary
Groups: 1 Peers: 3 Down peers: 0

Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 6 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn
State|#Active/Received/Accepted/Damped...
192.168.1.2 64700 5 7 0 0 1:52 0/
3/3/0 0/0/0/0
192.168.2.1 64700 2 2 0 0 12 0/
0/0/0 0/0/0/0
192.168.2.2 64700 5 5 0 0 1:44 0/
3/3/0 0/0/0/0
Question: How many BGP neighbors does your

device currently list?
Answer: Your device should list the three IBGP

peers you defined previously in this lab part. If you
do not see three IBGP peers, check your
configuration. If necessary, consult with the remote
team and the instructor.
Question: Has your device received any routes from

its IBGP peers?
Answer: Yes, your device should have received three

BGP routes from each of the virtual routers within
your assigned pod.
Step 2.4
Issue the run show route receive-protocol bgp peer-address
command, where peer-address is the loopback address of each IBGP peer.
lab@srxA-1# run show route receive-protocol bgp peer-address

Prefix Nexthop MED Lclpref AS path
172.21.0.0/24 192.168.1.2 100 I
172.21.1.0/24 192.168.1.2 100 I
172.21.2.0/24 192.168.1.2 100 I




172.22.0.0/24 192.168.2.2 100 I
172.22.1.0/24 192.168.2.2 100 I
172.22.2.0/24 192.168.2.2 100 I
Question: From which IBGP peers are you currently

receiving routes?
Answer: Only the virtual routers in your assigned

pod and AS are currently advertising routes. Note
that these routes are the same routes advertised
through OSPF.
Question: What is the AS path associated with the

received BGP routes?
Answer: The AS path for the received BGP routes is

I, which means the route originated in the local AS.
Once these routes are advertised to a different AS,
the local AS (64700 in this case) will be added to
the AS path list.
Question: What is the local preference of the

received BGP routes?
Answer: All received BGP routes should show a local

preference of 100, which is the default value.
Question: Which routing table group does the

referenced command consult? Which operational
mode command displays BGP routes in the routing
table (RIB-Local)?
Answer: The command referenced in this step

consults the RIB-In routing table. You can issue
the show route protocol bgp operational
mode command to display BGP routes. A sample of
this command is illustrated in the following capture:
lab@srxA-1# run show route protocol bgp

172.21.0.0/24 [BGP/170] 00:06:28, localpref 100, from 192.168.1.2

AS path: I
> to 172.20.111.10 via ge-0/0/4.111
AS path: I
> to 172.20.111.10 via ge-0/0/4.111
AS path: I
> to 172.20.111.10 via ge-0/0/4.111
AS path: I
> to 172.20.77.2 via ge-0/0/1.0
AS path: I
> to 172.20.77.2 via ge-0/0/1.0
AS path: I
> to 172.20.77.2 via ge-0/0/1.0
Step 2.5
Issue the run show route advertising-protocol bgp peer-address
command, where peer-address is the loopback address of each IBGP peer.
lab@srxA-1# run show route advertising-protocol bgp peer-address


Question: Which routing table group does the

command referenced in this step consult?
Answer: The command referenced in this step

consults the RIB-Out routing table.

Question: Is your student device currently
advertising BGP routes to any of its IBGP peers?
Answer: No. As illustrated in the sample output,

your device should not be advertising any BGP
routes at this time. Because BGP routes received
from IBGP peers are not readvertised to other IBGP
peers, it is logical that your device is not advertising
BGP routes at this time.
Part 3: Configuring and Monitoring EBGP
In this lab part, you configure and monitor EBGP. You first establish an EBGP peering
session with your external peers. You then advertise aggregate routes to your EBGP
peer to represent the prefixes reachable from your AS. Finally, you monitor the
established EBGP peering sessions using CLI operational mode commands.
Step 3.1
Refer to the network diagram for this lab and configure two EBGP peering sessions
with the connected AS. Name the associated EBGP group my-ext-group. Once
configured, activate the configuration changes using the commit command.
lab@srxA-1# set group my-ext-group type external

lab@srxA-1# set group my-ext-group peer-as peer-as

lab@srxA-1# set group my-ext-group neighbor peer-address


lab@srxA-1# show
type internal;
neighbor 192.168.1.2;
neighbor 192.168.2.1;
neighbor 192.168.2.2;
}
group my-ext-group {
type external;
peer-as 65510;
neighbor 172.18.1.1;
neighbor 172.18.11.1;
}

lab@srxA-1# commit
commit complete
Note
Before proceeding, ensure the remote
student team in your pod has finished the
previous step.
STOP Do not proceed until the remote team finishes the previous step.
Step 3.2
information.
inet.0 36 10 0 0 0 0
172.18.1.1 65510 12 9 0 0 3:03 10/
10/10/0 0/0/0/0
172.18.11.1 65510 11 8 0 0 2:59 0/
10/10/0 0/0/0/0
192.168.1.2 64700 28 34 0 0 12:38 0/
3/3/0 0/0/0/0
192.168.2.1 64700 31 29 0 0 10:58 0/
10/10/0 0/0/0/0
192.168.2.2 64700 28 33 0 0 12:30 0/
3/3/0 0/0/0/0
Question: How many BGP groups and peers does

your device currently list?
Answer: Your device should now list two BGP groups

and five BGP peers; the IBGP group consists of
three peers and the EBGP group has two peers. If
you do not see five BGP peers, check your
configuration and, if necessary, consult with the
instructor.

Question: Has your device received routes from
both EBGP peers?
Answer: Yes, your device should receive 10 BGP

routes from its EBGP peers. Note that the remote
student device, currently serving as an IBGP peer, is
also advertising 10 BGP routes.
Question: Are all of the routes received from the two

EBGP peers active?
Answer: No, only the routes received from one EBGP

peer are active.
Step 3.3
View all of the routes received from the EBGP peers by issuing the run show
route aspath-regex "peer-as .*" command.
lab@srxA-1# run show route aspath-regex "peer-as .*"

0.0.0.0/0 *[BGP/170] 00:03:32, localpref 100

AS path: 65510 I
> to 172.18.1.1 via ge-0/0/3.0
[BGP/170] 00:03:28, localpref 100
AS path: 65510 I
> to 172.18.11.1 via ge-0/0/4.1121
172.28.102.0/24 *[BGP/170] 00:03:32, localpref 100
AS path: 65510 65515 65519 65534 ?
> to 172.18.1.1 via ge-0/0/3.0
[BGP/170] 00:03:28, localpref 100
AS path: 65510 65515 65519 65534 ?
> to 172.18.11.1 via ge-0/0/4.1121
172.28.103.0/24 *[BGP/170] 00:03:32, localpref 100
AS path: 65510 65515 65519 65534 ?
> to 172.18.1.1 via ge-0/0/3.0
[BGP/170] 00:03:28, localpref 100
AS path: 65510 65515 65519 65534 ?
> to 172.18.11.1 via ge-0/0/4.1121
172.28.104.0/24 *[BGP/170] 00:03:32, localpref 100
AS path: 65510 65515 65519 65534 ?
> to 172.18.1.1 via ge-0/0/3.0

[BGP/170] 00:03:28, localpref 100
AS path: 65510 65515 65519 65534 ?
> to 172.18.11.1 via ge-0/0/4.1121
172.30.1.0/24 *[BGP/170] 00:03:32, localpref 100
AS path: 65510 65515 65516 65517 I
> to 172.18.1.1 via ge-0/0/3.0
[BGP/170] 00:03:28, localpref 100
AS path: 65510 65515 65516 65517 I
> to 172.18.11.1 via ge-0/0/4.1121
172.30.2.0/24 *[BGP/170] 00:03:32, localpref 100
AS path: 65510 65515 65516 65517 I
> to 172.18.1.1 via ge-0/0/3.0
[BGP/170] 00:03:28, localpref 100
AS path: 65510 65515 65516 65517 I
> to 172.18.11.1 via ge-0/0/4.1121
172.30.3.0/24 *[BGP/170] 00:03:32, localpref 100
AS path: 65510 65515 65516 65517 I
> to 172.18.1.1 via ge-0/0/3.0
[BGP/170] 00:03:28, localpref 100
AS path: 65510 65515 65516 65517 I
> to 172.18.11.1 via ge-0/0/4.1121
172.31.10.0/24 *[BGP/170] 00:03:32, localpref 100
AS path: 65510 65515 65531 E
> to 172.18.1.1 via ge-0/0/3.0
[BGP/170] 00:03:28, localpref 100
AS path: 65510 65515 65531 E
> to 172.18.11.1 via ge-0/0/4.1121
172.31.11.0/24 *[BGP/170] 00:03:32, localpref 100
AS path: 65510 65515 65531 E
> to 172.18.1.1 via ge-0/0/3.0
[BGP/170] 00:03:28, localpref 100
AS path: 65510 65515 65531 E
> to 172.18.11.1 via ge-0/0/4.1121
172.31.12.0/24 *[BGP/170] 00:03:32, localpref 100
AS path: 65510 65515 65531 E
> to 172.18.1.1 via ge-0/0/3.0
[BGP/170] 00:03:28, localpref 100
AS path: 65510 65515 65531 E
> to 172.18.11.1 via ge-0/0/4.1121
Question: Are the EBGP peers sending the exact

same routes to your router or are they sending
different routes?
Answer: The EBGP peers are sending the exact

same routes.

Question: Can you think of a reason why your router
is only using the routes received from one EBGP
peer and not the other?
Answer: Anytime a router receives two or more BGP

routes that are exactly the same in prefix and prefix
length, the router must choose one of those routes
as the active route (the route used for forwarding
and readvertisement). The BGP router will go
through the BGP route-selection process to
determine the best route. It will start by looking at
local preference, then AS path, and so on until it
determines the best route.
Step 3.4
Use the run show route 0/0 exact extensive command to look at the
default route received from each EBGP peer to determine why your router is
choosing one of the routes over the other.
lab@srxA-1# run show route 0/0 exact extensive

0.0.0.0/0 (3 entries, 1 announced)
TSI:
KRT in-kernel 0.0.0.0/0 -> {172.18.1.1}
Page 0 idx 0 Type 1 val 162cff8
Nexthop: 172.18.1.1
Localpref: 100
AS path: [64700] 65510 I
Communities:
Path 0.0.0.0 from 172.18.1.1 Vector len 4. Val: 0
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 546
Address: 0x168c8f8
Next-hop reference count: 30
Source: 172.18.1.1
Next hop: 172.18.1.1 via ge-0/0/3.0, selected
State: <Active Ext>
Local AS: 64700 Peer AS: 65510
Age: 5:11
Task: BGP_65510.172.18.1.1+179
Announcement bits (3): 0-KRT 3-BGP_RT_Background 4-Resolve tree 1
AS path: 65510 I
Accepted
Localpref: 100
Router ID: 10.10.10.10

BGP Preference: 170/-101
Next hop type: Router
Address: 0x168d48c
Source: 172.18.11.1
State: <NotBest Ext>
Inactive reason: Not Best in its group - Update source
Age: 5:07
Task: BGP_65510.172.18.11.1+179
AS path: 65510 I
Accepted
Localpref: 100
Router ID: 10.10.10.10
Next hop type: Indirect
Address: 0x168d064
Source: 192.168.2.1
Protocol next hop: 172.18.2.1
Indirect next hop: 16a0570 -
State: <Int Ext>
Inactive reason: Interior > Exterior > Exterior via Interior
Age: 4:42 Metric2: 2
Task: BGP_64700.192.168.2.1+179
AS path: 65520 I
Accepted
Localpref: 100
Router ID: 192.168.2.1
Indirect next hops: 1
Protocol next hop: 172.18.2.1 Metric: 2
Indirect path forwarding next hops: 1
Next hop: 172.20.77.2 via ge-0/0/1.0
172.18.2.0/30 Originating RIB: inet.0
Metric: 2 Node path count: 1
Forwarding nexthops: 1
Nexthop: 172.20.77.2 via ge-0/0/1.0

Question: What did the router use as the reason for
not choosing one of the routes to be active?
Answer: Looking at the output of the command, the

inactive route has an inactive reason of “Not
Best in its group - Update source”.
This means that the router chose not to use the
route based on the peer ID of the EBGP peers. The
lowest peer ID is the most preferred. Notice, in the
example, that the inactive route came from the peer
172.18.11.1, whereas the active route came from
the peer 172.18.1.1.
Question: What is the next hop of the active route?
Answer: The next hop of the active route should be

the IP address of the EBGP peer with the lowest
peer ID.
Question: Is it possible to configure your router to

use both sets of routes from the two EBGP peers
and load-balance between them? How?
Answer: By configuring multipath (one or more

EBGP peers in the same AS as each other) or
multihop (one EBGP peer only), your router can
load-balance traffic for equivalent routes learned
from multiple EBGP sessions. You will configure
both of these load-balancing methods later in this
lab.
Step 3.5
Issue the run show route advertising-protocol bgp peer-address
command, where peer-address is the IP address value assigned to each of your
EBGP peers.


Question: Is your device currently advertising the

BGP routes received from its IBGP peers to its EBGP
peers? If not, explain why.
Answer: No, as illustrated in the sample output,

your device should not currently be advertising BGP
routes to its EBGP peers. Although your device has
received BGP routes from its IBGP peers (the virtual
routers within your AS), those BGP routes are not
active because the same prefixes are also learned
through OSPF, which has a lower and more
preferred route preference (150 versus 170). The
following output illustrates the current status of
those prefixes.

lab@srxA-1# run show route 172.21/16

172.21.0.0/24 *[OSPF/150] 00:27:22, metric 0, tag 0

> to 172.20.111.10 via ge-0/0/4.111
[BGP/170] 00:17:30, localpref 100, from 192.168.1.2
AS path: I
> to 172.20.111.10 via ge-0/0/4.111
172.21.1.0/24 *[OSPF/150] 00:27:22, metric 0, tag 0
> to 172.20.111.10 via ge-0/0/4.111
AS path: I
> to 172.20.111.10 via ge-0/0/4.111
172.21.2.0/24 *[OSPF/150] 00:27:22, metric 0, tag 0
> to 172.20.111.10 via ge-0/0/4.111
AS path: I
> to 172.20.111.10 via ge-0/0/4.111

lab@srxA-1# run show route 172.22/16


172.22.0.0/24 *[OSPF/150] 00:27:47, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
AS path: I
> to 172.20.77.2 via ge-0/0/1.0
172.22.1.0/24 *[OSPF/150] 00:27:47, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
AS path: I
> to 172.20.77.2 via ge-0/0/1.0
172.22.2.0/24 *[OSPF/150] 00:27:47, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
AS path: I
> to 172.20.77.2 via ge-0/0/1.0
Step 3.6
Use the advertise-inactive option to override the default behavior and
advertise BGP routes that are not currently selected as active because of route
preference. Commit the changes when complete.
lab@srxA-1# set advertise-inactive

lab@srxA-1# commit
commit complete
Step 3.7
Once again, issue the run show route advertising-protocol bgp
peer-address command, where peer-address is the IP address value
assigned to each of your EBGP peers, to determine whether your device is
advertising BGP routes to its external BGP peers.

172.21.0.0/24 Self I
172.21.1.0/24 Self I
172.21.2.0/24 Self I
172.22.0.0/24 Self I
172.22.1.0/24 Self I
172.22.2.0/24 Self I


172.21.0.0/24 Self I
172.21.1.0/24 Self I
172.21.2.0/24 Self I
172.22.0.0/24 Self I

172.22.1.0/24 Self I
172.22.2.0/24 Self I
Question: Is your device now advertising the BGP

routes received from its IBGP peers to its EBGP
peers?
Answer: Yes. As illustrated in the sample output,

your device should now be advertising the BGP
routes learned from the two virtual router IBGP
peers to its EBGP peers.
Step 3.8
Navigate to the [edit routing-options] hierarchy and define aggregate
routes that represent the internal prefixes that are part of your AS. You will need to
summarize the 172.21.y.0/24, 172.22.y.0/24, 192.168.y.z/32 prefixes.
lab@srxA-1# top edit routing-options
lab@srxA-1# set aggregate route 172.21.0.0/22
lab@srxA-1# show aggregate
route 172.21.0.0/22;
route 172.22.0.0/22;
route 192.168.1.0/30;
route 192.168.2.0/30;
lab@srxA-1#
Step 3.9
Navigate to the [edit policy-options] hierarchy and define a new policy
named adv-aggregates that includes two terms. Name the first term
match-aggregate-routes. It should match and accept the aggregate routes.
Ensure that you match the aggregate protocol. Name the second term
deny-other. It should reject all other routes.

lab@srxA-1# top edit policy-options
[edit policy-options]
lab@srxA-1# edit policy-statement adv-aggregates
[edit policy-options policy-statement adv-aggregates]

lab@srxA-1# set term match-aggregate-routes from protocol aggregate

lab@srxA-1# set term match-aggregate-routes then accept

lab@srxA-1# set term deny-other then reject

lab@srxA-1# show
term match-aggregate-routes {
from protocol aggregate;
then accept;
}
term deny-other {
then reject;
}

lab@srxA-1#
Step 3.10
Navigate to the [edit protocols bgp] hierarchy and apply the newly defined
policy as an export policy for the external BGP group named my-ext-group.
Commit the changes when complete.

lab@srxA-1# set group my-ext-group export adv-aggregates

lab@srxA-1# show group my-ext-group
type external;
export adv-aggregates;
peer-as 65510;
neighbor 172.18.11.1;

lab@srxA-1# commit
commit complete

lab@srxA-1#

Step 3.11
Verify the effects of the newly defined and applied policy by issuing the run show
route advertising-protocol bgp peer-address command, where
peer-address is the IP address value assigned to each of your EBGP peers.

* 172.21.0.0/22 Self I
* 172.22.0.0/22 Self I
* 192.168.1.0/30 Self I
* 192.168.2.0/30 Self I


* 172.21.0.0/22 Self I
* 172.22.0.0/22 Self I
* 192.168.1.0/30 Self I
* 192.168.2.0/30 Self I
Question: Is your device advertising all of the

expected aggregate prefixes?
Answer: Yes, all aggregates should be advertised at

this time. If not, check your configuration for any
possible mistakes. Ask you instructor for help if
necessary.
Part 4: Configuring BGP Multipath
In this lab part, you configure BGP multipath so that your router load-balances
egress traffic to both of your router’s EBGP peers.
Step 4.1
Use the run show route received-protocol bgp peer-address
command to view the routes being received from the two EBGP peers. Refer to the
network diagram for this lab as necessary.

* 0.0.0.0/0 172.18.1.1 65510 I
* 172.28.102.0/24 172.18.1.1 65510 65515 65519 65534 ?
* 172.28.103.0/24 172.18.1.1 65510 65515 65519 65534 ?
* 172.28.104.0/24 172.18.1.1 65510 65515 65519 65534 ?
* 172.30.1.0/24 172.18.1.1 65510 65515 65516 65517 I
* 172.30.2.0/24 172.18.1.1 65510 65515 65516 65517 I
* 172.30.3.0/24 172.18.1.1 65510 65515 65516 65517 I
* 172.31.10.0/24 172.18.1.1 65510 65515 65531 E
* 172.31.11.0/24 172.18.1.1 65510 65515 65531 E
* 172.31.12.0/24 172.18.1.1 65510 65515 65531 E


0.0.0.0/0 172.18.11.1 65510 I
172.28.102.0/24 172.18.11.1 65510 65515 65519 65534 ?
172.28.103.0/24 172.18.11.1 65510 65515 65519 65534 ?
172.28.104.0/24 172.18.11.1 65510 65515 65519 65534 ?
172.30.1.0/24 172.18.11.1 65510 65515 65516 65517 I
172.30.2.0/24 172.18.11.1 65510 65515 65516 65517 I
172.30.3.0/24 172.18.11.1 65510 65515 65516 65517 I
172.31.10.0/24 172.18.11.1 65510 65515 65531 E
172.31.11.0/24 172.18.11.1 65510 65515 65531 E
172.31.12.0/24 172.18.11.1 65510 65515 65531 E
Question: Again, are the same routes being

received from both the EBGP peers?
Answer: Yes, the same routes are being received

from the EBGP peers.
Step 4.2
Display the 172.28.102.0/24 route using the run show route
172.28.102.0/24 detail command.
lab@srxA-1# run show route 172.28.102.0/24 detail

Address: 0x168c8f8
Source: 172.18.1.1
State: <Active Ext>

Age: 22:54
Task: BGP_65510.172.18.1.1+179
AS path: 65510 65515 65519 65534 ?
Accepted
Localpref: 100
Router ID: 10.10.10.10
Address: 0x168d48c
Source: 172.18.11.1
State: <NotBest Ext>
Inactive reason: Not Best in its group - Update source
Age: 22:50
Task: BGP_65510.172.18.11.1+179
AS path: 65510 65515 65519 65534 ?
Accepted
Localpref: 100
Router ID: 10.10.10.10
Address: 0x168d064
Source: 192.168.2.1
State: <Int Ext>
Inactive reason: Interior > Exterior > Exterior via Interior
Task: BGP_64700.192.168.2.1+179
AS path: 65520 65515 65519 65534 ?
Accepted
Localpref: 100
Router ID: 192.168.2.1
Question: How many advertisements have been

received for this route? Where did they come from?
Answer: The route was received three times. The

route was received from both of the EBGP peers as
well as the from the IBGP peer.

Question: How many next hops are associated with
the active route (denoted by a *)? Why?
Answer: Only one next hop is associated with the

active route. Of the three received advertisements,
by default only one advertisement will be used for
forwarding.
Step 4.3
Use the BGP multipath option to install the EBGP routes with two equal cost
paths. Configure multipath in the my-ext-group BGP group. Commit your
lab@srxA-1# set group my-ext-group multipath

lab@srxA-1# commit
commit complete
Step 4.4
Display the 172.28.102.0/24 route again using the run show route
172.28.102.0/24 detail active-path command.
lab@srxA-1# run show route 172.28.102.0/24 detail active-path

Address: 0x1678010
Source: 172.18.1.1
Next hop: 172.18.1.1 via ge-0/0/3.0
State: <Active Ext>
Age: 24:40
Task: BGP_65510.172.18.1.1+179
AS path: 65510 65515 65519 65534 ?
Accepted Multipath
Localpref: 100
Router ID: 10.10.10.10

Question: How many next hops does the active
route now have installed?
Answer: Two next hops now exist for the

172.28.102.0/24 route.
Step 4.5
Use the run show route forwarding-table destination
172.28.102.0/24 command to view the packet forwarding table.
lab@srxA-1# run show route forwarding-table destination 172.28.102.0/24
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
172.28.102.0/24 user 0 172.18.11.1 ucst 548 7 ge-0/0/4.1121
Routing table: __master.anon__.inet

Internet:
default perm 0 rjct 524 1
Question: Are the two routes to the EBGP peers

installed in the packet forwarding table?
Answer: No. Only one route is installed in the packet

forwarding table. The default forwarding behavior
for two or more equal cost routes is to randomly
pick one to be installed in the forwarding table. In
this example, the route is using the ge-0/0/4.1121
interface for the 172.28.102.0/24 route.
Step 4.6
pfe-load-balance] hierarchy. Under the pfe-load-balance policy, create a
term that only load-balances all BGP routes.
lab@srxA-1# top edit policy-options policy-statement pfe-load-balance
[edit policy-options policy-statement pfe-load-balance]

lab@srxA-1# set term 1 from protocol bgp

lab@srxA-1# set term 1 then load-balance per-packet

lab@srxA-1# show
term 1 {
from protocol bgp;
then {
load-balance per-packet;
}
}

lab@srxA-1#
Step 4.7
After configuring the pfe-load-balance policy, apply it as an export policy under
the [edit routing-options forwarding-table] hierarchy. Commit the
changes.
lab@srxA-1# top edit routing-options forwarding-table
[edit routing-options forwarding-table]

lab@srxA-1# set export pfe-load-balance

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 4.8
172.28.102.0/24 command to verify that the forwarding table now has two
next-hop interfaces for the 172.28.102.0/24 route.
Internet:
172.28.102.0/24 user 0 ulst 262142 12
172.18.1.1 ucst 546 3 ge-0/0/3.0
172.18.11.1 ucst 548 4 ge-0/0/4.1121

Internet:

Question: Is the forwarding table using both
next-hop interfaces to reach the 172.28.102.0/24
route?
Answer: Yes, the forwarding table now has two

next-hop interfaces for the 172.28.102.0/24 route,
one for each EBGP peer.
Part 5: Configuring BGP Multihop
In this lab part, you remove the peering sessions to the two EBGP peers. In their
place, you configure a single BGP multihop session so that your router
load-balances egress traffic across multiple interfaces to a single EBGP peer. Use
the lab diagram called “Lab 4: Implementing BGP—Part 5” for this part of the lab.
Step 5.1
Navigate to the [edit protocols bgp] hierarchy. Delete the two EBGP peers
configured under the my-ext-group BGP group. Make sure to also delete the
multipath statement.

lab@srxA-1# show
advertise-inactive;
type internal;
neighbor 192.168.1.2;
neighbor 192.168.2.1;
neighbor 192.168.2.2;
}
type external;
peer-as 65510;
multipath;
neighbor 172.18.11.1;
}

lab@srxA-1# delete group my-ext-group neighbor peer-address

lab@srxA-1# delete group my-ext-group neighbor peer-address

lab@srxA-1# delete group my-ext-group multipath


lab@srxA-1#
Step 5.2
Navigate to the [edit routing-options] hierarchy. Configure a static route to
the loopback address of your PE router that includes two next hops. The two next
hops will be the the far-end IP address of each of the two interfaces that connect to
your PE router. Ensure that the route cannot be redistributed into other protocols
and commit the configuration when complete.
lab@srxA-1# set static route PE-loopback-address/32 next-hop interface-address
lab@srxA-1# set static route PE-loopback-address/32 next-hop interface-address
lab@srxA-1# set static route PE-loopback-address/32 no-readvertise
lab@srxA-1# show static
route 172.31.15.11/32 {
next-hop [ 172.18.1.1 172.18.11.1 ];
no-readvertise;
}
lab@srxA-1# commit
commit complete
lab@srxA-1#
Step 5.3
Attempt to ping the loopback address of your PE router. Be sure to source the ping
from the loopback of your student device.
lab@srxA-1# run ping PE-loopback-address source local-loopback-address rapid
PING 172.31.15.11 (172.31.15.11): 56 data bytes
!!!!!
--- 172.31.15.11 ping statistics ---

Question: Is the ping successful?
Answer: Yes, the ping should be successful. If it is

not successful, verify your configuration and consult
with your instructor as needed.
Step 5.4
Navigate to the [edit protocols bgp] hierarchy. Configure a single EBGP
neighbor under the my-ext-group BGP group using the loopback address of the
PE router as the neighbor and your own router’s loopback address as the
local-address. Commit your configuration when complete.

lab@srxA-1# set group my-ext-group neighbor PE-loopback-address

lab@srxA-1# set group my-ext-group local-address local-loopback-address

lab@srxA-1# show
advertise-inactive;
type internal;
neighbor 192.168.1.2;
neighbor 192.168.2.1;
neighbor 192.168.2.2;
}
type external;
peer-as 65510;
neighbor 172.31.15.11;
}

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 5.5
Check the state of the EBGP session using the run show bgp summary
command.
inet.0 6 0 0 0 0 0
172.31.15.11 65510 0 0 0 0 9 Idle
192.168.1.2 64700 100 109 0 0 46:12 0/
3/3/0 0/0/0/0
192.168.2.1 64700 105 104 0 0 44:32 0/
0/0/0 0/0/0/0
192.168.2.2 64700 100 107 0 0 46:04 0/
3/3/0 0/0/0/0
Question: What is the state of the EBGP peering

session? Why?
Answer: The EBGP peering session is in Idle state.

All external BGP peering sessions must be peered
with the physical interface or a TCP session will not
be established.
Step 5.6
To relax the EBGP requirement of physical interface peering and make it possible to
EBGP peer between loopback addresses, apply the multihop statement to the
my-ext-group BGP group. Commit your configuration when complete.
lab@srxA-1# set group my-ext-group multihop

lab@srxA-1# commit
commit complete
Step 5.7
Check the status of the EBGP session with the run show bgp summary
command.

inet.0 26 10 0 0 0 0
172.31.15.11 65510 6 4 0 0 22 10/
10/10/0 0/0/0/0
192.168.1.2 64700 103 116 0 0 47:38 0/
3/3/0 0/0/0/0

192.168.2.1 64700 112 111 0 0 45:58 0/
10/10/0 0/0/0/0
192.168.2.2 64700 103 114 0 0 47:30 0/
3/3/0 0/0/0/0
Question: What is the state of the EBGP peering

session after the multihop command is
configured?
Answer: The EBGP peering session should be

established. If the session is not established, check
your configuration or consult with your instructor.
Step 5.8
Now that the EBGP peering session is established, use the run show route
receive-protocol bgp PE-loopback-address command to view the
routes being received from the P3 router.
lab@srxA-1# run show route receive-protocol bgp PE-loopback-address

* 0.0.0.0/0 172.31.15.11 65510 I
* 172.28.102.0/24 172.31.15.11 65510 65515 65519 65534 ?
* 172.28.103.0/24 172.31.15.11 65510 65515 65519 65534 ?
* 172.28.104.0/24 172.31.15.11 65510 65515 65519 65534 ?
* 172.30.1.0/24 172.31.15.11 65510 65515 65516 65517 I
* 172.30.2.0/24 172.31.15.11 65510 65515 65516 65517 I
* 172.30.3.0/24 172.31.15.11 65510 65515 65516 65517 I
* 172.31.10.0/24 172.31.15.11 65510 65515 65531 E
* 172.31.11.0/24 172.31.15.11 65510 65515 65531 E
* 172.31.12.0/24 172.31.15.11 65510 65515 65531 E
Question: Are routes being received from the EBGP

peering session?
Answer: Yes. Routes are being received from the

EBGP router.
Step 5.9
Display the 172.28.102.0/24 route using the run show route
172.28.102.0/24 detail active-path command.

lab@srxA-1# run show route 172.28.102.0/24 detail active-path

Address: 0x168cb58
Source: 172.31.15.11
Next hop: 172.18.11.1 via ge-0/0/4.1121
Indirect next hop: 16a0570 262143
State: <Active Ext>
Task: BGP_65510.172.31.15.11+179
AS path: 65510 65515 65519 65534 ?
Accepted
Localpref: 100
Router ID: 10.10.10.10
Question: How many next hops does the active

route have installed?
Answer: Two next hops exist for the

172.28.102.0/24 route.
Step 5.10
172.28.102.0/24 command to verify that the forwarding table now has two
next-hop interfaces for the 172.28.102.0/24 route.
Internet:
172.28.102.0/24 user 0 indr 262143 11
ulst 262142 2
172.18.1.1 ucst 546 6 ge-0/0/3.0
172.18.11.1 ucst 548 3 ge-0/0/4.1121

Internet:

Question: Is the forwarding table using both

next-hop interfaces to reach the 172.28.102.0/24
route? Why or why not?
Answer: Yes, the forwarding table has two next-hop

interfaces for the 172.28.102.0/24 route, one for
each of the equal cost static routes that you added
to the forwarding table earlier in the lab. Two next
hops exist in the forwarding table because of the
load-balancing that was applied earlier in the lab.
Step 5.11
Exit configuration mode and log out of your assigned device using the exit
command.
lab@srxA-1# exit configuration-mode
lab@srxA-1> exit
srxA-1 (ttyu0)
login:


Lab 5
BGP Attributes (Detailed)
Overview
This lab demonstrates configuration and manipulation of BGP path attributes. In this lab,
you use the command-line interface (CLI) to configure and manipulate BGP attributes.
• Configure export and import policy.
• Configure and apply a next-hop self policy.
• Manipulate BGP path attributes to influence traffic flow.
www.juniper.net BGP Attributes (Detailed) • Lab 5–1

11.a.11.4R1.6
Part 1: Loading the Initial Configuration
In this lab part, you load the initial configuration needed to begin the lab.
Step 1.1


Step 1.2
Step 1.3
srxA-1 (ttyu0)
login: lab
Password:
--- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC
Lab 5–2 • BGP Attributes (Detailed) www.juniper.net

[edit]
load complete
[edit]
lab@srxA-1# commit
commit complete
Part 2: Configuring BGP
In this lab part, you first verify the autonomous system (AS) number internal BGP
(IBGP) group for your device. Next, you configure an EBGP peering session using the
direct addresses for your external peer.
Step 2.1
Using the show routing-options autonomous-system command, verify
that the AS number designated for your network has been configured. Refer to the
network diagram for this lab as necessary.
[edit]
lab@srxA-1# show routing-options autonomous-system
64700;
Step 2.2
Navigate to the [edit protocols bgp] hierarchy. Use the show command to
verify that the my-int-group group has been preconfigured as an IBGP session
with three peers.
[edit]
lab@srxA-1# edit protocols bgp

lab@srxA-1# show
type internal;
neighbor 192.168.1.2;
neighbor 192.168.2.1;
neighbor 192.168.2.2;
}

lab@srxA-1#
Step 2.3
Configure a BGP group named my-ext-group that includes the single device
directly connected in the different AS as an EBGP peer. Use the connected address
of the device as your peering address. When you are satisfied with the newly defined
BGP configuration, issue the commit command to activate the changes.




type external;
peer-as 65510;

lab@srxA-1# commit
commit complete
Note
previous step.
Step 2.4
information for your device.
inet.0 22 13 0 0 0 0
172.18.1.1 65510 46 40 0 0 16:29 9/
9/9/0 0/0/0/0
192.168.1.2 64700 42 52 0 0 19:12 2/
2/2/0 0/0/0/0
192.168.2.1 64700 53 54 0 0 19:12 0/
9/9/0 0/0/0/0
192.168.2.2 64700 42 52 0 0 19:04 2/
2/2/0 0/0/0/0
Question: How many BGP routes are you receiving

from your EBGP neighbor?
Answer: You should be receiving nine routes from

your EBGP neighbor.

Part 3: Configuring Next-Hop Self Policy
In this lab part you monitor received routes and detect next-hop resolution issues.
You will create a policy to correct the next-hop resolution problems and, after the
policy is applied, you will monitor the change and make sure it is working properly.
Step 3.1
Issue a run show route protocol bgp hidden command to view the
current hidden routes on your device.
lab@srxA-1# run show route protocol bgp hidden


AS path: 65520 I
Unusable
AS path: 65520 65515 26749 3356 I
Unusable
AS path: 65520 65515 65510 65510 65510 I
Unusable
AS path: 65520 65515 I
Unusable
AS path: 65520 65515 65510 I
Unusable
AS path: 65520 65515 65510 65510 26749 I
Unusable
AS path: 65520 65520 I
Unusable
AS path: 65520 65515 3356 9888 I
Unusable
AS path: 65520 65520 65520 65520 1123 I
Unusable
Note
The output will differ depending on the
device you are using.

Question: Why are these routes hidden?
Answer: The next hop is only updated by the EBGP

neighbor. Because the connected route between
the ASs is not known internally, the EBGP routes
coming from the IBGP neighbor are marked as
hidden.
Step 3.2
Navigate to the [edit policy-options] configuration hierarchy. Create a
policy named nhs with one term that sets all routes to next-hop self. You can
name this term anything you like.
lab@srxA-1# set policy-statement nhs term 1 then next-hop self
lab@srxA-1#
Step 3.3
Navigate back to the [edit protocols bgp] configuration hierarchy. Apply the
nhs policy to the my-int-group BGP group as an export policy. When you are
satisfied with the newly defined configuration, issue the commit command to
activate changes.

lab@srxA-1# set group my-int-group export nhs

lab@srxA-1# show group my-int-group
type internal;
export nhs;
neighbor 192.168.1.2;
neighbor 192.168.2.1;
neighbor 192.168.2.2;

lab@srxA-1# commit
commit complete

lab@srxA-1#

Note
previous step.
Step 3.4
For verification, issue a run show route protocol bgp hidden command
to view the current status of hidden routes on your device.
lab@srxA-1# run show route protocol bgp hidden
Question: How many hidden routes are there?
Answer: There should be no hidden routes after

committing the nhs policy.
Part 4: Using Policy to Avoid Becoming a Transit AS
In this lab part, you use policy to avoid becoming a transit AS. To accomplish this
task, you configure a policy that matches routes that are generated in your AS,
accept the routes, and reject everything else. You then apply this policy to your EBGP
peers.
Step 4.1
Issue the run show route protocol bgp aspath-regex "()" command
to determine which routes are generated locally in the AS.
lab@srxA-1# run show route protocol bgp aspath-regex "()"

67.3.192.0/21 *[BGP/170] 01:52:07, localpref 100, from 192.168.1.2

AS path: I
> to 172.20.113.10 via ge-0/0/4.141
AS path: I
> to 172.20.77.2 via ge-0/0/1.0

AS path: I
> to 172.20.113.10 via ge-0/0/4.141
AS path: I
> to 172.20.77.2 via ge-0/0/1.0
Question: What does the “()” aspath-regex value

match?
Answer: The “()” aspath-regex matches a null AS

path.
Step 4.2
Issue a run show route advertising-protocol bgp peer-address
| match "^\*” command to count how many routes are advertised to the EBGP
peer.
lab@srxA-1# run show route advertising-protocol bgp peer-address | match
"^\*”
* 4.0.0.0/21 Self 65520 I
* 67.3.192.0/21 Self I
* 67.3.200.0/21 Self I
* 69.3.176.0/21 Self I
* 69.3.184.0/21 Self I
* 87.47.48.0/22 Self 65520 65520 I
* 158.76.56.0/22 Self 65520 65520
65520 65520 1123 I
Question: How many routes are advertised to your

external peer?
Answer: Based on the previous output, you should

be sending seven routes.
Step 4.3
Navigate to the [edit policy-options] hierarchy and create an AS path
regular expression named null-as that matches the null aspath-regex value.
lab@srxA-1# set as-path null-as "()"
lab@srxA-1#

Step 4.4
Create a policy named export-ebgp. This policy will contain two terms. Name the
first term local-routes and have it accept BGP routes that match the
aspath-regex named null-as created previously. Name the second term last
and set it to reject everything else.
lab@srxA-1# set policy-statement export-ebgp term local-routes from as-path
null-as
lab@srxA-1# set policy-statement export-ebgp term local-routes from protocol
bgp
lab@srxA-1# set policy-statement export-ebgp term local-routes then accept
lab@srxA-1# set policy-statement export-ebgp term last then reject
lab@srxA-1# show as-path null-as
"()";
lab@srxA-1# show policy-statement export-ebgp
term local-routes {
from {
protocol bgp;
as-path null-as;
}
then accept;
}
term last {
then reject;
}
Question: What is the default terminating action for

a routing policy in BGP?
Answer: The default action is to accept all BGP

routes.
Step 4.5
Navigate to the [edit protocols bgp] hierarchy. Apply the export-ebgp
policy as an export policy to the my-ext-group BGP group. When you are satisfied
with the newly defined policy configuration, issue the commit command to activate
the changes.

lab@srxA-1# set group my-ext-group export export-ebgp

type external;
export export-ebgp;
peer-as 65510;

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 4.6
Issue a run show route advertising-protocol bgp peer-address
| match "^\*” command to determine which routes are advertised to the EBGP
peer after applying the export policy.
lab@srxA-1# run show route advertising-protocol bgp peer-address | match "^\*”
* 67.3.192.0/21 Self I
* 67.3.200.0/21 Self I
* 69.3.176.0/21 Self I
* 69.3.184.0/21 Self I
Question: How many routes are you now sending to

your EBGP peer?
Answer: After applying the policy, you should only be

sending the four routes generated within your AS to
your EBGP peer.
Part 5: Manipulating Attributes with Policy to Influence Inbound Traffic
In this lab part, you configure a policy to manipulate BGP attributes to influence
inbound traffic. Policy is used to change the AS path value and origin values on
outgoing advertisements.
Refer to the network diagram provided. To optimize routing back to the network, you
will manipulate outgoing advertisements to enhance the routes closer to the exit
point.

Note
You will be working with an exclusive set of
instructions depending on your assigned
device.
Step 5.1
This step is to be performed by Team 1 only.
export-ebgp] hierarchy. Configure a term named origin that matches routes
67.3.200.0/21 and 69.3.184.0/21. Modify the origin of these routes using the
incomplete option and accept them. Insert the origin term before the
local-routes term. When you are satisfied with the newly defined policy
configuration, issue the commit command to activate the changes.
lab@srxA-1# top edit policy-options policy-statement export-ebgp
[edit policy-options policy-statement export-ebgp]

lab@srxA-1# set term origin from route-filter 67.3.200.0/21 exact

lab@srxA-1# set term origin from route-filter 69.3.184.0/21 exact

lab@srxA-1# set term origin then origin incomplete

lab@srxA-1# set term origin then accept

lab@srxA-1# insert term origin before term local-routes

lab@srxA-1# show
term origin {
from {
}
then {
origin incomplete;
accept;
}
}
term local-routes {
from {
protocol bgp;
as-path null-as;
}
then accept;
}
term last {

then reject;
}
lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 5.2
export-ebgp] hierarchy. Configure a term named as-prepend that matches
routes 67.3.192.0/21 and 69.3.176.0/21. Using the as-path-prepend option,
change the AS path of these routes to prepend the local AS two times and then
accept the routes. Insert this term before the local-routes term.When you are
satisfied with the newly defined policy configuration, issue the commit command to
activate the changes.
lab@srxA-2# top edit policy-options policy-statement export-ebgp
lab@srxA-2# set term as-prepend from route-filter 67.3.192.0/21 exact

lab@srxA-2# set term as-prepend from route-filter 69.3.176.0/21 exact

lab@srxA-2# set term as-prepend then as-path-prepend "64700 64700"

lab@srxA-2# set term as-prepend then accept

lab@srxA-2# insert term as-prepend before term local-routes

lab@srxA-2# show
term as-prepend {
from {
}
then {
as-path-prepend "64700 64700";
accept;
}
}
term local-routes {
from {
protocol bgp;
as-path null-as;
}

then accept;
}
term last {
then reject;
}
lab@srxA-2# commit
commit complete

lab@srxA-2#
Note
previous step.
Step 5.3
Using the run telnet 8.0.0.1 source source-address command,
telnet to the ISP Y router to confirm the routes that were manipulated in the previous
step. Team 1 will use a source address of 67.3.192.1. Team 2 will use a source
address of 67.3.200.1. The user is ispy and the password is lab123.
lab@srxA-1# run telnet 8.0.0.1 source source-address
Trying 8.0.0.1...
vr-device (ttyp1)
login: ispy
Password:
--- JUNOS 11.4R1.6 built 2011-11-15 11:28:05 UTC
ispy@vr-device>
Step 5.4
From the ISP Y router, issue the show route table ispY-X 67.3.192.0/21
and show route table ispY-X 67.3.200.0/21 commands, where X is the
pod letter you are using (A,B,C, or D).
Note
Feel free to inspect the other BGP routes in
table ispY on the vr-device.

ispy@vr-device> show route table ispY-X 67.3.192.0/21
ispY-A.inet.0: 20 destinations, 24 routes (20 active, 0 holddown, 0 hidden)

67.3.192.0/21 *[BGP/170] 04:36:27, localpref 100

AS path: 65510 64700 I
> to 10.10.1.1 via lt-0/0/0.502
[BGP/170] 00:05:57, localpref 100
AS path: 65520 64700 64700 64700 I
> to 10.10.2.1 via lt-0/0/0.504
ispy@vr-device> show route table ispY-X 67.3.200.0/21

67.3.200.0/21 *[BGP/170] 04:33:06, localpref 100

AS path: 65520 64700 I
> to 10.10.2.1 via lt-0/0/0.504
[BGP/170] 00:49:54, localpref 100
AS path: 65510 64700 ?
> to 10.10.1.1 via lt-0/0/0.502
Note
The output might differ slightly depending
on which device is used.
Question: Is the prepend AS path policy working as

expected?
Answer: Yes. Routes 67.3.192.0/21 and

69.3.176.0/21 should have an AS path length of 4.
Isp Y should prefer the path through AS 65510 for
these routes.
Question: Is the manipulation of the origin attribute

working as expected?
Answer: Yes. Routes 67.3.200.0/21 (and

69.3.184.0/21) should have an origin of
incomplete represented by a question mark (?) in
the AS path. Isp Y should prefer the path through
AS 65520.
Step 5.5
Log out of the vr-device.

ispy@vr-device> exit
Part 6: Manipulating Local Preference with an Import Policy
In this lab part, you manipulate the local preference attribute based on incoming
community.
Referring to your lab diagram, ISP X and ISP Z are advertising their local customer
routes with a community containing their AS number and the number 1000,
regardless of AS path length. You will create a policy that optimizes outbound traffic
to use your peers local routes.
Step 6.1
Navigate to the [edit policy-options] configuration hierarchy. Create a BGP
community named peer-local that matches either 65510:1000 or 65520:1000.
lab@srxA-1# up
lab@srxA-1# set community peer-local members "65510|65520:1000"
lab@srxA-1#
Step 6.2
Create a policy named import-ebgp with a term named
peer-local-community that matches the community named peer-local
and sets the local preference to 1000.
lab@srxA-1# set policy-statement import-ebgp term peer-local-community from
community peer-local
lab@srxA-1# set policy-statement import-ebgp term peer-local-community then
local-preference 1000
Step 6.3
Navigate to the [edit protocols bgp] configuration hierarchy. Apply the policy
named import-ebgp to the my-ext-group BGP group as an import policy.
Issue the commit command to activate the changes.

lab@srxA-1# set group my-ext-group import import-ebgp

type external;
import import-ebgp;
export export-ebgp;
peer-as 65510;

lab@srxA-1# top show policy-options community peer-local
members "65510|65520:1000";

lab@srxA-1# top show policy-options policy-statement import-ebgp
term peer-local-community {
from community peer-local;
then {
local-preference 1000;
}
}

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 6.4
For verification, issue a run show route community
"65510|65520:1000" extensive | match "^[0-9]|Localpref"
command and ensure the correct routes get tagged with the correct local preference
value.
lab@srxA-1# run show route community "65510|65520:1000" extensive | match
"^[0-9]|Localpref"
Localpref: 1000
11.0.0.0/21 (1 entry, 1 announced)
Localpref: 1000
Localpref: 1000
68.11.8.0/22 (1 entry, 1 announced)
Localpref: 1000
Localpref: 1000
77.48.28.0/22 (1 entry, 1 announced)
Localpref: 1000
Localpref: 1000
Localpref: 1000
Localpref: 1000

Question: Are the peer’s local routes getting the
right local preference based on the policy applied in
the previous steps?
Answer: Yes, the previous output shows that routes

containing community 65510:1000 or 65520:1000
have a local preference of 1000.
Part 7: Aggregating Routes and Using Well-Known Communities
In this lab part, you create two aggregate routes for the local AS. The more specific
routes will be known by your immediate peers, but we want to supress
advertisements beyond that. You will use a well-known community for this task.
Step 7.1
Navigate to the [edit routing-options] configuration hierarchy. Create two
aggregate routes that overlap the networks in our local AS. When you are satisfied
with the newly defined configuration, issue the commit command to activate the
changes.
[edit protocols bgp]]
route 69.3.176.0/20;
route 67.3.192.0/20;
lab@srxA-1# commit
commit complete
lab@srxA-1#
Step 7.2
For verification, issue a run show route protocol aggregate command
and ensure the aggregate routes were created.

lab@srxA-1# run show route protocol aggregate

67.3.192.0/20 *[Aggregate/130] 00:04:07

Reject
69.3.176.0/20 *[Aggregate/130] 00:04:07
Reject
Question: What is the requirement for an aggregate

route to become active?
Answer: The router must have more specific routes

that fall within that aggregate route.
Step 7.3
Navigate to the [edit policy-options] configuration hierarchy. Create a
community named no-export containing the well-known no-export community.
lab@srxA-1# set community no-export members no-export
lab@srxA-1#
Step 7.4
export-ebgp] configuration hierarchy. Create two new terms. Name one of the
terms adv-agg; it should match the aggregate routes and accept them. Name the
second term ne to set the community to the no-export community you created
previously. Using the then next term option, set an additional action in the ne
term.
lab@srxA-1# edit policy-statement export-ebgp

lab@srxA-1# set term adv-agg from protocol aggregate

lab@srxA-1# set term adv-agg then accept

lab@srxA-1# set term ne then community add no-export

lab@srxA-1# set term ne then next term

lab@srxA-1#
Step 7.5
Insert the adv-agg term before the term named origin. Insert the ne term after
the adv-agg term. When you are satisfied with the newly defined configuration,
issue the commit and-quit command to activate the changes and exit to
operational mode.
Note
Make sure to perform the previous step in
the order given. If it is not performed in the
order given, your policy will not work as
expected.

lab@srxA-1# insert term adv-agg before term origin

lab@srxA-1# insert term ne after term adv-agg

lab@srxA-1# show
term adv-agg {
then accept;
}
term ne {
then {
community add no-export;
next term;
}
}
term origin {
from {
}
then {
origin incomplete;
accept;
}
}
term local-routes {
from {
protocol bgp;
as-path null-as;
}
then accept;
}
term last {

then reject;
}

commit complete
lab@srxA-1>
Step 7.6
Insert the adv-agg term before the term named as-prepend. Insert the ne term
after the adv-agg term. When you are satisfied with the newly defined
configuration, issue the commit and-quit command to activate the changes
and exit to operational mode.
Note
Make sure to perform the previous step in
the order given. If it is not performed in the
order given, your policy will not work as
expected.

lab@srxA-2# insert term adv-agg before term as-prepend

lab@srxA-2# insert term ne after term adv-agg

lab@srxA-2# show
term adv-agg {
then accept;
}
term ne {
then {
community add no-export;
next term;
}
}
term as-prepend {
from {
}
then {
as-path-prepend "64700 64700";
accept;
}
}
term local-routes {

from {
protocol bgp;
as-path null-as;
}
then accept;
}
term last {
then reject;
}

commit complete
lab@srxA-2>
Step 7.7
For verification, issue the show route advertising-protocol bgp
peer-address command to determine which routes you are advertising to your
EBGP peer. Refer the lab diagram as needed.
lab@srxA-1> show route advertising-protocol bgp peer-address

* 67.3.192.0/20 Self I
* 67.3.192.0/21 Self I
* 67.3.200.0/21 Self ?
* 69.3.176.0/20 Self I
* 69.3.176.0/21 Self I
* 69.3.184.0/21 Self ?
Note
The previous output might differ depending
on which device you are using, but you will
be advertising six routes.
Step 7.8
Using the telnet 8.0.0.1 source source-address command, telnet to
the ISP Y router to confirm the routes that were manipulated in the previous step.
Team 1 will use a source address of 67.3.192.1. Team 2 will use a source address of
67.3.200.1. The user is ispy and the password is lab123.
lab@srxA-1> telnet 8.0.0.1 source source-address
Trying 8.0.0.1...
vr-device (ttyp1)
login: ispy
Password:

--- JUNOS 11.4R1.6 built 2011-11-15 11:28:05 UTC
ispy@vr-device>
Step 7.9
From the vr-device, verify the routes originated from your local AS (64700) by issuing
a show route table ispY-X aspath-regex ".*64700$" command,
where X is the pod letter you are using (A,B,C, or D).
ispy@vr-device> show route table ispY-X aspath-regex ".*64700$"

67.3.192.0/20 *[BGP/170] 00:11:43, localpref 100

AS path: 65520 64700 I
> to 10.10.2.1 via lt-0/0/0.504
[BGP/170] 00:07:32, localpref 100
AS path: 65510 64700 I
> to 10.10.1.1 via lt-0/0/0.502
69.3.176.0/20 *[BGP/170] 00:11:43, localpref 100
AS path: 65520 64700 I
> to 10.10.2.1 via lt-0/0/0.504
[BGP/170] 00:07:32, localpref 100
AS path: 65510 64700 I
> to 10.10.1.1 via lt-0/0/0.502
Question: Why does the number of routes

advertised from AS 64700 (6) differ from the
amount of routes ISP Y receives (two)?
Answer: The number differs because the directly

connected providers honor the no-export
well-known community and supress the
advertisement of the more-specific routes, exactly
how it was crafted in the export policy.
Step 7.10
Log out of the vr-device using the exit command.
ispy@vr-device> exit

Step 7.11
lab@srxA-1> exit



Lab 6
Implementing Enterprise Routing Policies (Detailed)
Overview
This lab demonstrates implementation of enterprise routing policies. In this lab you will be
using BGP as a policy tool to achieve the goals of the lab. In this lab, you use the
command-line interface (CLI) to configure and manipulate configuration.
• The use of private autonomous systems (ASs) to segregate the network.
• Configuration of the common routing policies for external connectivity.
www.juniper.net Implementing Enterprise Routing Policies (Detailed) • Lab 6–1

11.a.11.4R1.6
In this lab part, you load the initial configuration needed to begin the lab.
Step 1.1


Step 1.2
Step 1.3
srxA-1 (ttyu0)
login: lab
Password:
--- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC

Lab 6–2 • Implementing Enterprise Routing Policies (Detailed) www.juniper.net
[edit]
load complete
[edit]
lab@srxA-1# commit
commit complete
Part 2: Configuring BGP
In this lab part, you configure BGP. You first define the AS number for your device.
Next, you establish IBGP peering sessions using loopback addresses for your
internal peers. Finally, you will create two different EBGP peering groups, one for
your internal enterprise sites and one for your external ISP provider. You will use
direct addresses for your external peers.
Step 2.1
Define the AS number designated for your network. Refer to the network diagram for
this lab as necessary.
[edit]
lab@srxA-1# set routing-options autonomous-system 10458
Step 2.2
Navigate to the [edit protocols bgp] hierarchy. Configure a BGP group
named my-int-group that includes the other SRX Series device within your AS
as an internal BGP (IBGP) peer. Use the loopback address assigned to your device
as the local address and the remote loopback address of the remote device as the
neighbor address. When you are satisfied with the newly defined BGP configuration,
issue the commit command to activate the changes.
[edit]



lab@srxA-1# set group my-int-group local-address local-loopback-address

lab@srxA-1# show
type internal;
neighbor 192.168.2.1;
}

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 2.3
Refer to the lab diagram and find your directly connected enterprise peer. Configure
a BGP group named my-ent-group that includes this single device. Using the
connected address of the device as your peering address, configure this device as
an EBGP peer. Do not forget to set the correct peer AS (either 65001 or 65002,
depending on your assigned device). When you are satisfied with the newly defined
lab@srxA-1# set group my-ent-group type external

lab@srxA-1# set group my-ent-group peer-as peer-as

lab@srxA-1# set group my-ent-group neighbor address

lab@srxA-1# show group my-ent-group
type external;
peer-as 65001;
neighbor 172.20.113.10;

lab@srxA-1# commit
commit complete
Step 2.4
Refer to the lab diagram and find your directly connected external peer. Configure a
BGP group named my-ext-group that includes this single device. Using the
connected address of the device as your peering address, configure this device as
an EBGP peer. Do not forget to set the correct peer AS (either 3356 or 813,
depending on your assigned device). When you are satisfied with the newly defined


lab@srxA-1# set group my-ext-group neighbor address

type external;
peer-as 3356;


lab@srxA-1# commit
commit complete
Note
previous step.
Step 2.5
Issue the run show bgp summary command to view the current BGP peering
status for your device.
[...]
172.18.1.1 3356 22 11 0 0 45
1506/1506/1506/0 0/0/0/0
172.20.113.10 65001 18 85 0 0 7:32 1/
1/1/0 0/0/0/0
192.168.2.1 10458 110 105 0 0 19:04
113/1521/1521/0 0/0/0/0
Question: How many BGP routes are you receiving

from your ISP neighbor?
Answer: You should be receiving approximately

1500 routes from your ISP neighbor.
Question: Which type of external routing policy is

this policy?
Answer: Because no modification to external routes

currently exists, this type of policy is
topology-driven.
Part 3: Implementing a Strict Primary/Secondary Routing Policy for Outbound Traffic
In this lab part, you implement a strict primary/secondary routing policy for your
external connections. ISP X and ISP Z are sending a full view of the Internet table.

Note
This is a hypothetical full view of the
Internet routing table. Lab resources are
limited, thus we can only generate a limited
number of routes.
In addition, ISP X is sending a default route and customer routes with community tag
3356:1. ISP Z is also sending a default route and customer routes with community
tag 813:1.
Step 3.1
Navigate to the [edit policy-options] hierarchy and create two
communities, one named ispX with 3356:1 as the member and the other named
ispZ with 813:1 as the member.
lab@srxA-1# set community ispX members 3356:1
lab@srxA-1# set community ispZ members 813:1
lab@srxA-1#
Step 3.2
Create a policy named primary-secondary. In this policy, create a term named
primary that matches a default route (0.0.0.0/0) and community ispX. Set the
action for this term to raise the local preference to 1000 and accept.
lab@srxA-1# set policy-statement primary-secondary term primary from
route-filter 0/0 exact
lab@srxA-1# set policy-statement primary-secondary term primary from community
ispX
lab@srxA-1# set policy-statement primary-secondary term primary then
local-preference 1000
lab@srxA-1# set policy-statement primary-secondary term primary then accept
Step 3.3
Within the primary-secondary policy, create a second term named
secondary that matches a default route (0.0.0.0/0) and community ispZ. Set
the action for this term to accept.

lab@srxA-1# set policy-statement primary-secondary term secondary from
route-filter 0/0 exact
lab@srxA-1# set policy-statement primary-secondary term secondary from
community ispZ
lab@srxA-1# set policy-statement primary-secondary term secondary then accept
Step 3.4
Within the primary-secondary policy, create a third term named reject with
an action of reject.
lab@srxA-1# set policy-statement primary-secondary term reject then reject
lab@srxA-1# show
policy-statement primary-secondary {
term primary {
from {
community ispX;
}
then {
accept;
}
}
term secondary {
from {
community ispZ;
}
then accept;
}
term reject {
then reject;
}
}
community ispX members 3356:1;
community ispZ members 813:1;
Step 3.5
Navigate back to the [edit protocols bgp] hierarchy. Set the policy
primary-secondary as an import policy for the my-ext-group group. When
you are satisfied with the newly defined BGP configuration, issue the commit
command to activate the changes.

lab@srxA-1# set group my-ext-group import primary-secondary

type external;
import primary-secondary;
peer-as 3356;

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 3.6
For verification, issue the run show route 0/0 exact command.
lab@srxA-1# run show route 0/0 exact
0.0.0.0/0 *[BGP/170] 01:44:59, localpref 1000

AS path: 3356 I
> to 172.18.1.1 via ge-0/0/4.171
Note
The output will differ depending on the
device to which you are assigned.
Note
previous step.
Question: What is the local-preference value of the

default route?
Answer: The value should be 1000.

Question: Which path does the enterprise prefer
now for all external traffic?
Answer: After the import policy is applied, the path

toward ISP X through Team 1’s SRX Series device is
the preferred path for all external traffic.
Part 4: Implementing a Primary/Secondary Routing Policy for Inbound Traffic
In this lab part, you implement a primary/secondary routing policy for inbound
traffic using routing policy. You also implement a policy to keep the enterprise from
becoming a transit AS.
Step 4.1
Navigate to the [edit policy-options] hierarchy and create an AS path
regular expression named private that matches the entire private AS range
(64512–65535).
lab@srxA-1# set as-path private "[64512-65535]"
lab@srxA-1#
Step 4.2
Create a policy named ext-ebgp. In this policy, create a term named
my-ent-nets that matches the as-path of private and has an action to accept.
Create a second term named reject-all with an action to reject. When you are
satisfied with the newly defined policy configuration, issue the commit command to
lab@srxA-1# set policy-statement ext-ebgp term my-ent-nets from as-path private
lab@srxA-1# set policy-statement ext-ebgp term my-ent-nets then accept
lab@srxA-1# set policy-statement ext-ebgp term reject-all then reject
lab@srxA-1# show policy-statement ext-ebgp
term my-ent-nets {
from as-path private;
then accept;
}
term reject-all {
then reject;
}

lab@srxA-1# show as-path private
"[64512-65535]";
lab@srxA-1# commit
commit complete
Step 4.3
Navigate back to the [edit protocols bgp] hierarchy. Set the policy
ext-ebgp as an export policy for the my-ext-group group. When you are
satisfied with the newly defined BGP configuration, issue the commit command to

lab@srxA-1# set group my-ext-group export ext-ebgp

type external;
export ext-ebgp;
peer-as 3356;

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 4.4
Issue the run show route advertising-protocol bgp
ext-peer-address command to verify you are only advertising the two
enterprise routes to your external ISP peers.
lab@srxA-1# run show route advertising-protocol bgp ext-peer-address
* 67.3.192.1/32 Self 65001 I
* 67.3.200.1/32 Self 65002 I

Question: Which routes are you advertising to the
external ISP peers?
Answer: You should only be advertising

67.3.192.1/32 and 67.3.200.1/32.
Step 4.5
Remove the private AS when advertising the enterprise routes to the ISP. Use the
remove-private command under the my-ext-group. When you are satisfied
with the newly defined BGP configuration, issue the commit command to activate
the changes.
lab@srxA-1# set group my-ext-group remove-private

type external;
export ext-ebgp;
remove-private;
peer-as 3356;

lab@srxA-1# commit
commit complete
Step 4.6
Issue the run show route advertising-protocol bgp
ext-peer-address command to verify that no private AS numbers exist in the AS
path.
* 67.3.192.1/32 Self I
* 67.3.200.1/32 Self I
Question: Is the private AS value removed from the

advertisements?
Answer: Yes, as shown in the previous capture, the

private AS value has been removed from the
AS path column.

Step 4.7
Note
You will be working with an exclusive set of
instructions depending on your assigned
device.

Navigate to the [edit policy-options] hierarchy. In the ext-ebgp policy,
add an action to the my-ent-nets term that prepends the AS number 10458
three times. When you are satisfied with the newly defined policy configuration,
lab@srxA-2# set policy-statement ext-ebgp term my-ent-nets then as-path-prepend
"10458 10458 10458"
lab@srxA-2# show policy-statement ext-ebgp
term my-ent-nets {
from as-path private;
then {
as-path-prepend "10458 10458 10458";
accept;
}
}
term reject-all {
then reject;
}
lab@srxA-2# commit
commit complete
lab@srxA-2#
Step 4.8
Issue the run show route advertising-protocol bgp 172.18.2.1
command to verify the policy is prepending the AS three times.
lab@srxA-2# run show route advertising-protocol bgp 172.18.2.1

* 67.3.192.1/32 Self 10458 10458
10458 [10458] I
* 67.3.200.1/32 Self 10458 10458
10458 [10458] I
Question: Why does AS prepending help the strict

primary/secondary network design?
Answer: By prepending the AS toward ISP Z, you are

influencing the provider’s routing decision. The path
from ISP X should now look more desirable to the
rest of the Internet.
Note
Changing attributes before advertising to
the provider does not always guarantee the
desired result, because you have no control
over the routing policy of other networks.
Part 5: Implementing a Loose Primary/Secondary Routing Policy for Outbound Traffic
In this lab part, you implement a loose primary/secondary routing policy. This action
allows you to prefer the secondary ISP for selected prefixes.
Step 5.1
Within the primary-secondary policy, create a new term named
ISPZ-specifics that matches the ispZ community created previously and
accepts the routes. Insert this term before the term reject in the
primary-secondary policy. When you are satisfied with the newly defined policy
configuration, issue the commit command to activate the changes.
lab@srxA-2# set policy-statement primary-secondary term ISPZ-specifics from
community ispZ
lab@srxA-2# set policy-statement primary-secondary term ISPZ-specifics then
accept
lab@srxA-2# insert policy-statement primary-secondary term ISPZ-specifics
before term reject
lab@srxA-2# show policy-statement primary-secondary
term strict {
from {
community ispX;
}
then accept;
}
term secondary {
from {
community ispZ;
}
then accept;
}
term ISPZ-specifics {
from community ispZ;
then accept;
}
term reject {
then reject;
}
lab@srxA-2# commit
commit complete
Note
Before proceeding, ensure that Team 2 in
your pod finishes the previous step.
Step 5.2
Issue the command run show route protocol bgp aspath-regex
"813$" | no-more. This action allows you to view routes originated from ISP Z.
Note
The command will have approximately 100
routes to display. It might take a couple of
seconds to complete.
lab@srxA-1# run show route protocol bgp aspath-regex "813$" | no-more

AS path: 813 I
> to 172.20.77.2 via ge-0/0/1.0

AS path: 813 I
> to 172.20.77.2 via ge-0/0/1.0
AS path: 813 I
> to 172.20.77.2 via ge-0/0/1.0
AS path: 813 I
> to 172.20.77.2 via ge-0/0/1.0
AS path: 813 I
> to 172.20.77.2 via ge-0/0/1.0
AS path: 813 I
> to 172.20.77.2 via ge-0/0/1.0
[...]
Question: What is the next hop for routes in

AS 813?
Answer: All the routes from AS 813 should be

pointing to the 172.20.77.2 address on the Team 2
SRX Series device.
Question: How does this configuration accomplish a

loose primary/secondary design?
Answer: By allowing specific routes from ISP Z and

not receiving the announcements from ISP X, the
network uses the more specific destinations.
Part 6: Implementing Per-Prefix Load Sharing Outbound Traffic
In this lab part, you implement per-prefix load sharing for outbound traffic. This
allows the network to use different providers for a given set of prefixes.
Step 6.1
Navigate to the [edit protocols bgp] hierarchy. Remove the import policy
named primary-secondary from the BGP group my-ext-group. When you
are satisfied with the newly defined BGP configuration, issue the commit command
to activate the changes.

lab@srxA-1# delete group my-ext-group import primary-secondary

type external;
export ext-ebgp;
remove-private;
peer-as 3356;

lab@srxA-1# commit
commit complete

lab@srxA-1#
Note
previous step.
Step 6.2
To view the amount of routes active in the table from the peers, issue a run show
bgp summary command.
inet.0 3028 1620 0 0 0 0
172.18.1.1 3356 155 143 0 0 1:03:19
1506/1506/1506/0 0/0/0/0
172.20.113.10 65001 494 770 0 0 3:52:19 1/
1/1/0 0/0/0/0
192.168.2.1 10458 729 720 0 0 4:03:51
113/1521/1521/0 0/0/0/0
Question: How many routes are active from the ISP?
Answer: The answer will vary depending on the

device you are using, but there should be
approximately 1500 routes active from the ISP.
Step 6.3
Navigate to the [edit policy-options] hierarchy. Create a policy named
load-shared. In this policy, create a term named half that matches all prefixes
within 0.0.0.0/1 or longer. Set the action for the term half to raise the local
preference to 1000 and accept.

lab@srxA-1# set policy-statement load-shared term half from route-filter
0.0.0.0/1 orlonger
lab@srxA-1# set policy-statement load-shared term half then local-preference
1000
lab@srxA-1# set policy-statement load-shared term half then accept
lab@srxA-1#
Step 6.4
Navigate to the [edit policy-options] hierarchy. Create a policy named
load-shared. In this policy, create a term named half that matches all prefixes
within 128.0.0.0/1 or longer. Set the action for the term half to raise the local
preference to 1000 and accept.
lab@srxA-2# set policy-statement load-shared term half from route-filter
128.0.0.0/1 orlonger
lab@srxA-2# set policy-statement load-shared term half then local-preference
1000
lab@srxA-2# set policy-statement load-shared term half then accept
lab@srxA-2#
Step 6.5
Navigate back to the [edit protocols bgp] hierarchy. Apply the
load-shared policy as an import policy to the BGP group my-ext-group.

lab@srxA-1# set group my-ext-group import load-shared
lab@srxA-1# top show policy-options policy-statement load-shared

term half {
from {
route-filter 0.0.0.0/1 orlonger;
}
then {
accept;
}
}

type external;
import load-shared;
export ext-ebgp;
remove-private;
peer-as 3356;

lab@srxA-1# commit
commit complete

lab@srxA-1#
Note
previous step.
Step 6.6
For verification, issue a run show bgp summary command to view how many
routes are active from each peer.
Note
The following captures show the outputs
from both student devices.

inet.0 2482 1620 0 0 0 0
172.18.1.1 3356 187 177 0 0 1:18:24
645/1506/1506/0 0/0/0/0
172.20.113.10 65001 526 838 0 0 4:07:24 1/
1/1/0 0/0/0/0
192.168.2.1 10458 820 814 0 0 4:18:56
974/975/975/0 0/0/0/0
...............................................................................


inet.0 2167 1620 0 0 0 0
172.18.2.1 813 187 178 0 0 1:18:06
974/1520/1520/0 0/0/0/0
172.20.114.10 65002 525 884 0 0 4:06:45 1/
1/1/0 0/0/0/0
192.168.1.1 10458 812 819 0 0 4:18:47
645/646/646/0 0/0/0/0
Question: How many routes are active from your

internal peer?
Answer: The answer might vary. Team 1 should have

approximately 974 active routes from the internal
peer and Team 2 should have approximately 645
active routes from the internal peer.
Note
The policy configured in the previous steps
should give a good start for a load-shared
design. However, maintaining parity for
outbound traffic for various providers
requires policy adjustment based on
constant monitoring of traffic patterns.
Part 7: Implementing Per-Prefix Load Sharing for Inbound Traffic
In this lab part, you implement per-prefix load sharing for inbound traffic. This allows
the external networks to use longest-match routing to reach your networks.
Step 7.1
Navigate to the [edit routing-options] hierarchy. Create aggregate routes
of 67.3.192.0/21 and 67.3.192.0/20. When you are satisfied with the newly
defined configuration, issue the commit command to activate the changes.


route 67.3.192.0/21;
route 67.3.192.0/20;
lab@srxA-1# commit
commit complete
lab@srxA-1#
Step 7.2
Navigate to the [edit routing-options] hierarchy. Create aggregate routes
of 67.3.200.0/21 and 67.3.192.0/20. When you are satisfied with the newly
defined configuration, issue the commit command to activate the changes.
route 67.3.200.0/21;
route 67.3.192.0/20;
lab@srxA-2# commit
commit complete
lab@srxA-2#
Step 7.3
For verification, issue the command run show route protocol aggregate
to confirm that the aggregate routes have become active.
lab@srxA-1# run show route protocol aggregate

67.3.192.0/20 *[Aggregate/130] 00:12:53

Reject

67.3.192.0/21 *[Aggregate/130] 00:12:53
Reject
Step 7.4
Navigate to the [edit policy-options] hierarchy. Create a new policy named
export-load-shared. In this policy, create a new term named aggregates
that matches all aggregate routes. Set the action of this term to accept. Create a
second term named reject that rejects everything else.
lab@srxA-1# set policy-statement export-load-shared term aggregates from
protocol aggregate
lab@srxA-1# set policy-statement export-load-shared term aggregates then accept
lab@srxA-1# set policy-statement export-load-shared term reject then reject
lab@srxA-1#
Step 7.5
Navigate to the [edit protocols bgp] hierarchy. Remove the export policy
from the my-ext-group BGP group. Set the export-load-shared policy as
an export policy for the my-ext-group BGP group. When you are satisfied with the
newly defined configuration, issue the commit command to activate the changes.

lab@srxA-1# delete group my-ext-group export

lab@srxA-1# set group my-ext-group export export-load-shared

lab@srxA-1# top show policy-options policy-statement export-load-shared
term aggregates {
then accept;
}
term reject {
then reject;
}

type external;
import load-shared;
export export-load-shared;

remove-private;
peer-as 3356;

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 7.6
For verification, issue the command run show route
advertising-protocol bgp ext-peer-address to view the routes
advertised to the ISP.

* 67.3.192.0/20 Self I
* 67.3.192.0/21 Self I
Question: How does this lab part accomplish a

load-shared design?
Answer: By advertising a more specific prefix from

each edge to each provider, you are influencing the
provider to use a longest-prefix routing to
load-share traffic.
Question: Why is announcing a less specific

aggregate important in this design?
Answer: By announcing a less specific aggregate

route, you account for a failure in the advertisement
on one of the edges.
Step 7.7
Exit configuration mode and log out of your assigned device using the exit
command.
lab@srxA-1# exit configuration-mode
lab@srxA-1> exit



Lab 7
Implementing PIM-SM (Detailed)
Overview
This lab demonstrates configuration and monitoring of Internet Group Management
Protocol (IGMP) and Protocol Independent Multicast Sparse Mode (PIM-SM) on devices
running the Junos operating system using the any-source multicast (ASM) model. In this
lab, you use the command-line interface (CLI) to configure and monitor IGMP and PIM-SM.
• Configure and monitor IGMP.
• Configure and monitor static rendezvous point (RP) configuration.
• Configure and monitor the bootstrap router mechanism (BSR).
• Configure and monitor PIM-SM using the ASM model.
• Verify the flow of multicast traffic through the network.
www.juniper.net Implementing PIM-SM (Detailed) • Lab 7–1

11.a.11.4R1.6
Part 1: Loading the Baseline Topology
In this lab part, you configure your student device’s interfaces according to the lab
diagram labeled “Lab 7: Implementing PIM-SM—Parts 1–3.” Next, you will verify the
topology using the CLI.
Step 1.1


Step 1.2
Step 1.3
After the configuration has been loaded, commit the changes and return to
operational mode before proceeding.
srxA-1 (ttyu0)
login: lab
Lab 7–2 • Implementing PIM-SM (Detailed) www.juniper.net

Password:
--- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC

[edit]
load complete
[edit]
commit complete
lab@srxA-1>
Step 1.4
Use the show configuration interfaces command to determine which
interfaces have been preconfigured for you.
lab@srxA-1> show configuration interfaces
ge-0/0/0 {
description "MGMT Interface - DO NOT DELETE";
unit 0 {
family inet {
address 10.210.14.131/26;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 172.20.77.1/30;
}
}
}
ge-0/0/4 {
vlan-tagging;
unit 0 {
vlan-id 121;
family inet {
address 172.18.121.2/30;
}
}
}
ge-0/0/8 {
unit 0 {
family inet {
address 10.1.1.1/30;
}
}
}
lo0 {
unit 0 {

family inet {
address 192.168.121.1/32;
}
}
}
Question: Have any interfaces been preconfigured?

If so, which interfaces have been preconfigured?
Answer: The ge-0/0/0, ge-0/0/1, ge-0/0/4,

ge-0/0/8, and lo0 interfaces have been
preconfigured for you.
Step 1.5
Use the show configuration protocols command to determine which
protocols have been preconfigured for you.
lab@srxA-1> show configuration protocols
ospf {
area 0.0.0.0 {
interface all;
interface ge-0/0/8.0 {
passive;
}
interface ge-0/0/0.0 {
disable;
}
}
}
Question: Have any protocols been preconfigured?

If so, which protocols have been preconfigured?
Answer: The OSPF protocol has been preconfigured,

as shown on the lab diagram.
Step 1.6
Verify that each interface has been configured properly by attempting to ping each of
the locally attached routers and hosts.
lab@srxA-1> ping address rapid
PING 172.18.121.1 (172.18.121.1): 56 data bytes
!!!!!
--- 172.18.121.1 ping statistics ---

PING 172.20.77.2 (172.20.77.2): 56 data bytes
!!!!!

PING 10.1.1.2 (10.1.1.2): 56 data bytes
!!!!!
Question: Were all of the locally attached routers

and hosts reachable?
Answer: Yes, all devices should be reachable. If any

of the devices were not reachable, check your local
interface configuration to determine whether any
needed.
Step 1.7
Use the show ospf interface and show ospf neighbor commands to
confirm that OSPF has been configured properly and that adjacencies have been
established between neighboring routers.
lab@srxA-1> show ospf interface
ge-0/0/1.0 BDR 0.0.0.0 192.168.122.1 192.168.121.1 1
ge-0/0/4.0 DR 0.0.0.0 192.168.121.1 192.168.120.1 1
ge-0/0/8.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
lo0.0 DR 0.0.0.0 192.168.121.1 0.0.0.0 0
sp-0/0/0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 0
lab@srxA-1> show ospf neighbor

172.20.77.2 ge-0/0/1.0 Full 192.168.122.1 128 31
172.18.121.1 ge-0/0/4.0 Full 192.168.120.1 128 35

Question: Are the adjacencies established between
your router and the two neighboring routers?
Answer: Yes, the adjacencies should be

established. If any of the devices were not
reachable, check your local interface configuration
to determine whether any mistakes exist. Ask your
Step 1.8
To forward traffic from any given source in a PIM-SM network, each router must have
a route in its routing table associated with the source. Use the show route
172.18.120/24 command to determine whether a route to the source exists in
your device’s routing table.
lab@srxA-1> show route 172.18.120/24

172.18.120.0/30 *[OSPF/10] 03:52:44, metric 2

> to 172.18.121.1 via ge-0/0/4.0
Question: Does the route to the source exist? How

was it learned?
Answer: Yes, a route to the source should exist in

the routing table. The route was learned from OSPF.
Part 2: Configuring IGMP
In this lab part, you configure your student device’s ge-0/0/8 interface to run the
IGMP protocol. Next, you will log in to the locally attached receiver and configure it to
send IGMP reports. Finally, you will verify, with show commands, that your student
device is receiving the IGMP reports generated by the receiver.
Step 2.1
Enter configuration mode and navigate to the [edit protocols igmp]
hierarchy. Configure your device’s ge-0/0/8 interface to use IGMP version 2
(IGMPv2).

[edit]
lab@srxA-1# edit protocols igmp
[edit protocols igmp]

lab@srxA-1# set interface ge-0/0/8.0 version 2

lab@srxA-1#
Step 2.2
Because only one locally connected receiver is on the ge-0/0/8 interface, configure
your device to immediately remove any multicast groups when a leave group
message is received from the receiver. Commit your configuration when complete.
lab@srxA-1# set interface ge-0/0/8.0 immediate-leave

lab@srxA-1# commit
commit complete
Step 2.3
Issue the run show igmp interface command to determine which interfaces
are enabled for IGMP.
lab@srxA-1# run show igmp interface
Interface: ge-0/0/8.0
Querier: 10.1.1.1
State: Up Timeout: None Version: 2 Groups: 0
Immediate leave: On
Promiscuous mode: Off
Passive: Off
Configured Parameters:
IGMP Query Interval: 125.0
IGMP Query Response Interval: 10.0
IGMP Last Member Query Interval: 1.0
IGMP Robustness Count: 2
Derived Parameters:
IGMP Membership Timeout: 260.0
IGMP Other Querier Present Timeout: 255.0

Question: Has the ge-0/0/8 interface been properly
enabled for IGMP?
Answer: Yes, the ge-0/0/8 interface should appear

as the only interface enabled for IGMP at this point
in the lab. If the ge-0/0/8 interface is not listed in
the output of the command, check your local
interface configuration to determine whether any
needed.
Question: Which router has been elected querier for

the Ethernet segment?
Answer: This answer will vary by student. In the

example output, 10.1.1.1 (the student device) has
been elected as the querier for the segment.
Question: Which version of IGMP has been

enabled?
Answer: IGMPv2 should be enabled.
Question: How many groups have been learned by

your student device through the ge-0/0/8
interface?
Answer: This answer will vary by student as well as

the lab environment. In the example output, no
multicast groups have been learned through the
ge-0/0/8 interface.
Step 2.4
Issue the run show igmp group command to determine the groups that have
been learned from IGMP.
lab@srxA-1# run show igmp group
Interface: local, Groups: 5

Group: 224.0.0.2
Source: 0.0.0.0
Last reported by: Local
Timeout: 0 Type: Dynamic
...
Question: Have any groups been learned on your

assigned device?
Answer: This answer will vary by student as well as

the lab environment. In the example output,
224.0.0.2 has been reported by the attached
receiver. This is the All Routers multicast group
address.
Step 2.5
From your assigned device, log in to the attached receiver using SSH, a username of
lab, and a password of lab123.
lab@srxA-1# run ssh lab@address
lab@10.1.1.2's password:
Last login: Sun Mar 4 10:13:32 2012 from 10.1.1.1
[lab@CoS1 ~]$
Step 2.6
Analyze the following table to determine the group that you will configure the
receiver to join.
Receivers Groups
Pod A 224.7.7.121
Pod B 224.7.7.123
Pod C 224.7.7.125
Pod D 224.7.7.127

Question: Which group will you be configuring your
receiver to receive?
Answer: This answer will vary by student. For

example, the administrator of srxA-1 will configure
the attached receiver to receive traffic destined for
224.7.7.121.
Step 2.7
Using the rptqual application, configure your receiver to generate IGMP reports for
the group listed in the table. Use the following example from srxA-1 as a guide:
[lab@CoS1 ~]$ ./rtpqual group-address 1111 rtp&
[1] 16231
[lab@CoS1 ~]$
Step 2.8
Log out of the receiver and return to the operational mode prompt of your student
device.
[lab@CoS1 ~]$ exit
logout
Connection to 10.1.1.2 closed.

lab@srxA-1#
Step 2.9
Use the run show igmp group command to verify that your device is receiving
IGMP reports from the locally attached receiver.
lab@srxA-1# run show igmp group
Interface: ge-0/0/8.0, Groups: 1
Group: 224.7.7.121
Source: 0.0.0.0
Last reported by: 10.1.1.2
...

Question: Is your router receiving IGMP reports for
any new groups? Which groups?
Answer: Yes, your router should be receiving IGMP

reports for the new group. For example, the
administrator of srxA-1 should see the receipt of
IGMP reports from the attached receiver for
224.7.7.121.
Part 3: Configuring PIM-SM with Static RP
In this lab part, you configure your student device to run the PIM-SM protocol using
the ASM model. Next, you will statically configure the RP for the network. Finally, you
will verify, with show commands, that your the network has built both a
rendezvous-point tree (RPT) and a shortest-path tree (SPT) from source to receiver.
Step 3.1
In the previous lab part, you configured the receiver to inform the network, using
IGMP, that it wishes to receive multicast traffic. However, IGMP only operates
between the receiver and the locally connected IGMP querier (router). To allow for
the rest of the network to know of the these locally attached receivers, a multicast
routing protocol must be enabled throughout the network of routers.
Navigate to the [edit protocols pim] level of the hierarchy. Configure each of
your router’s interfaces to run PIM-SM. Do not forget the loopback interface.
lab@srxA-1# up 1 edit pim
[edit protocols pim]

lab@srxA-1# set interface ge-0/0/4.0 mode sparse



lab@srxA-1# set interface lo0.0 mode sparse

lab@srxA-1#
Step 3.2
One requirement of a PIM-SM network is that at least one RP must exist in the
network. Analyze the following table to determine the RP for your multicast group.

Receivers RP Group
Pod A srxA-1 (192.168.121.1) 224.7.7.121
Pod B srxB-1 (192.168.121.1) 224.7.7.123
Pod C srxC-1 (192.168.121.1) 224.7.7.125
Pod D srxD-1 (192.168.121.1) 224.7.7.127
Question: Which router will be the RP in your

topology?

example, for pod A, srxA-1 will be the RP for the
group 224.7.7.121.
Step 3.3
Configure your device to be the RP for all multicast groups (224/4) using the
loopback address for the RP address. Commit your configuration when complete.
lab@srxA-1# set rp local address 192.168.121.1 group-ranges 224/4

lab@srxA-1# commit
Step 3.4
Configure your device to use a static RP using the srxX-1 loopback address. Ensure
that srxX-1 will be the RP for all group addresses (224/4). Commit your
lab@srxA-2# set rp static address 192.168.121.1 group-ranges 224/4

lab@srxA-2# commit
commit complete
Step 3.5
Verify that the correct interfaces have been configured for PIM-SM by issuing the
run show pim interfaces command.
lab@srxA-1# run show pim interfaces
Instance: PIM.master

Name Stat Mode IP V State NbrCnt JoinCnt(sg) JoinCnt(*g) DR

address
ge-0/0/1.0 Up Sparse 4 2 NotDR 1 0 0
172.20.77.2
ge-0/0/4.0 Up Sparse 4 2 DR 1 1 0
172.18.121.2
ge-0/0/8.0 Up Sparse 4 2 DR 0 0 0
10.1.1.1
lo0.0 Up Sparse 4 2 DR 0 0 0
192.168.121.1
ppd0.32769 Up Sparse 4 2 P2P 0 0 0
Question: Do all of the interfaces that you

configured for PIM-SM appear in the output of the
command?
Answer: Yes, all of the interfaces should be listed in

the output. If any interfaces are missing, check your
configuration to determine whether any mistakes
exist. Ask your instructor for help if needed.
Question: Do any interfaces that were not

configured for PIM-SM appear in the output of the
command? If so, what is the purpose of these extra
interfaces?
Answer: Yes, you might see a ppd0 or ppe0

interface in the output of the command. These are
the PIM encapsulation and decapsulation
interfaces. These interfaces are logical interfaces
used for the encapsulation (source DR) and
decapsulation (RP) of register messages.
Step 3.6
Verify that the correct RP has been configured on your router by issuing the run
show pim rps command.
lab@srxA-1# run show pim rps
Address family INET
RP address Type Holdtime Timeout Groups Group prefixes
192.168.121.1 static 0 None 1 224.0.0.0/4
Address family INET6

Question: Is your router aware of any active RPs?
Answer: Yes, there should be a single RP available

in the network that has been configured statically. If
no active RP exists, check your configuration to
Question: Are there any active groups that your

router is associating with the RP? If so, why?
Answer: Yes, there should be an active group

associated with this RP. Because a receiver is
attached to your router requesting the receipt of
multicast traffic, your router is using this RP to gain
access to the flow of that multicast traffic.
Step 3.7
Issue the run show pim join extensive command to determine the (S,G)
and (*,G) states of your router.
lab@srxA-1# run show pim join extensive
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Group: 224.7.7.121
Source: *
RP: 192.168.121.1
Flags: sparse,rptree,wildcard
Upstream interface: Local
Upstream neighbor: Local
Upstream state: Local RP
Uptime: 00:02:06
Downstream neighbors:
172.20.77.2 State: Join Flags: SRW Timeout: 160
Uptime: 00:01:50 Time since last Join: 00:00:50
10.1.1.1 State: Join Flags: SRW Timeout: Infinity
Group: 224.7.7.121
Source: 172.18.120.2
Flags: sparse,spt
Upstream interface: ge-0/0/4.0

Upstream neighbor: 172.18.121.1
Upstream state: None, Local RP, Join to Source
Keepalive timeout: 356
Uptime: 00:02:05
Interface: ge-0/0/1.0 (pruned)
172.20.77.2 State: Prune Flags: SR Timeout: 160
Uptime: 00:01:50 Time since last Prune: 00:00:50
10.1.1.1 State: Join Flags: S Timeout: Infinity
Instance: PIM.master Family: INET6

Question: How many states are associated with your

multicast group? Why?
Answer: Two states, (*,G) and (S,G), should be

associated with your multicast group. The (S,G)
state is being used to deliver the multicast traffic
from the existing source to the receivers along the
SPT. The (*,G) state, although not currently being
used for forwarding, exists for the possibility of
future sources that might transmit to the same
group. The (*,G) state enables traffic to be
delivered to the receivers as well.
Question: What are the upstream interfaces

associated each state? Are they correct?
Answer: The answer will vary by student. For (*,G)

states, the upstream interface should be in the
direction of the RP. For (S,G) states, the upstream
interface should be in the direction of the source.
Question: What are the downstream interfaces


and (S,G) states, the downstream interfaces should
be in the direction of the active receivers.

Step 3.8
Verify that multicast traffic is being forwarded by your router by issuing the run
show multicast route extensive command.
lab@srxA-1# run show multicast route extensive
Instance: master Family: INET
Group: 224.7.7.121
Source: 172.18.120.2/32
Downstream interface list:
ge-0/0/8.0
Session description: Unknown
Statistics: 53 kBps, 101 pps, 16169 packets
Next-hop ID: 262143
Upstream protocol: PIM
Route state: Active
Forwarding state: Forwarding
Cache lifetime/timeout: 360 seconds
Wrong incoming interface notifications: 1
Uptime: 00:02:55
Instance: master Family: INET6
Question: Is multicast traffic being forwarded by

your router? If so, at what rate is being forwarded?
Answer: Yes, your router should be forwarding traffic

for your group. In the example output, the traffic is
being forwarded at a rate of 101 packets per
second (pps).
Part 4: Configuring PIM-SM with the BSR mechanism
In this lab part, you use the “Lab 7: Implementing PIM-SM—Part 4” diagram. You will
configure your student device to run the PIM-SM protocol using the ASM model, but
this time you will use the BSR mechanism to dynamically learn the RP. Next, you will
verify with show commands that your the network has built both an RPT and an SPT
from source to receiver.
Step 4.1
Delete any RP configuration that currently exists. Commit your configuration and exit
to operational mode.

lab@srxA-1# delete rp

commit complete
Step 4.2
From your assigned device, log in to the attached receiver using SSH, a username of
lab, and a password of lab123.
lab@srxA-1> ssh lab@address
Last login: Tue Mar 6 06:28:25 2012 from 10.1.1.1
[lab@CoS1 ~]$
Step 4.3
Issue the ps -ef | grep rtpqual command to determine the process ID (PID)
of the rtpqual application used in the previous steps. Use the following example as a
guide:
[lab@CoS1 ~]$ ps -ef | grep rtpqual
lab 3286 1 0 05:35 ? 00:00:02 ./rtpqual 224.7.7.125 1111 rtp
lab 3569 3536 0 07:49 pts/2 00:00:00 grep rtpqual
Step 4.4
Issue the kill -9 pid command to kill the PID of the rtpqual application. Use the
following example as a guide:
[lab@CoS1 ~]$ kill -9 3286
Step 4.5
Analyze the following table to determine the new group that you will configure the
receiver to join.
Receivers Groups
Pod A 224.7.7.122
Pod B 224.7.7.124
Pod C 224.7.7.126
Pod D 224.7.7.128

Question: Which group will you be configuring your
receiver to receive?

example, the administrator of srxA-1 will be
configuring the attached receiver to receive traffic
destined for 224.7.7.122.
Step 4.6
Using the rtpqual application, configure your receiver to generate IGMP reports for
the group listed in the table. Use the following example from srxA-1 as a guide:
[lab@CoS1 ~]$ ./rtpqual group-address 1111 rtp&
[1] 3572
Step 4.7
device.
[lab@CoS1 ~]$ exit
logout
lab@srxA-1>
Step 4.8
Using the show igmp group command, verify that your device is receiving IGMP
reports from the locally attached receiver.
lab@srxA-1> show igmp group
Group: 224.7.7.122
Source: 0.0.0.0
...

any new groups? If so, for which groups?
Answer: Yes, your router should be receiving IGMP

reports for the new group. For example, the
administrator of srxA-1 should see the receipt of
IGMP reports from the attached receiver for
224.7.7.122.

Step 4.9
One requirement of a PIM-SM network with a BSR is that at least one RP and at
least one BSR must exist in the network. Analyze the following table to determine
the RP and BSR for your multicast group.
Receivers RP/BSR Group

Pod A srxA-2 (192.168.122.1) 224.7.7.122
Pod B srxB-2 (192.168.122.1) 224.7.7.124
Pod C srxC-2 (192.168.122.1) 224.7.7.126
Pod D srxD-2 (192.168.122.1) 224.7.7.128
Question: Which router will act as the RP and BSR in

your topology?

example, for group A, srxA-2 will be the RP for the
group 224.7.7.122. Also, in the same example
srxA-2 will be a candidate BSR as well.
Step 4.10
Enter configuration mode and navigate to the [edit protocols pim]
hierarchy. Using the srxX-2 loopback address for the RP address, configure srxX-2 to
be the RP and BSR for your multicast group only as indicated in the previous step’s
table. Also, configure the BSR priority to a value of 50. Commit your configuration
and exit to operational mode.
[edit]
lab@srxA-2# edit protocols pim

lab@srxA-2# set rp local address 192.168.122.1 group-ranges group-address

lab@srxA-2# set rp bootstrap-priority 50

commit complete

Question: Why do you think that there is no need to
add any RP-related configuration to the non-RP and
non-BSR routers?
Answer: There is no need for extra configuration

because each router is configured for PIM-SM
version 2, so each router will learn RP information
dynamically from the BSR.
Step 4.11
Verify that a BSR has been elected using the show pim bootstrap command.
Note
It might take a minute for the BSR to be
elected.
lab@srxA-1> show pim bootstrap

BSR Pri Local address Pri State Timeout

192.168.122.1 50 192.168.121.1 0 InEligible 127
None 0 (null) 0 0
Question: Has a BSR been elected in the network?
Answer: Yes, a BSR should have been elected. If no

BSR is elected, check your configuration to
Question: What is the IP address of the BSR? Is this

expected?
Answer: The IP address of the BSR should be

192.168.122.1. This is expected because it was the
only one configured with a priority value.
Step 4.12
Verify that the correct RP has been configured on your router by issuing the show
pim rps command.

lab@srxA-1> show pim rps
Address family INET
RP address Type Holdtime Timeout Groups Group prefixes
192.168.122.1 bootstrap 150 145 1 224.7.7.122/32
Address family INET6
Question: Is your router aware of any active RPs?
Answer: Yes, one RP should be available in the

network which has been learned through the BSR
mechanism. If no active RP exists, check your
configuration to determine whether it contains any
mistakes. Ask your instructor for help if needed.
Step 4.13
Use the show pim join extensive command to determine the (S,G) and
(*,G) states of your router.
lab@srxA-1> show pim join extensive
Group: 224.7.7.122
Source: *
RP: 192.168.122.1
Flags: sparse,rptree,wildcard
Upstream state: Join to RP
Uptime: 00:00:46
10.1.1.1 State: Join Flags: SRW Timeout: Infinity
Group: 224.7.7.122
Source: 172.18.120.2
Flags: sparse,spt
Upstream state: Join to Source, Prune to RP
Uptime: 00:00:46


Question: How many states are associated with your

multicast group? Why?
Answer: Two states, (*,G) and (S,G), should be

associated with your multicast group. The (S,G)
state is being used to deliver the multicast traffic
from the existing source to the receivers along the
SPT. The (*,G) state, although not currently being
used for forwarding, exists for the possibility of
future sources that might transmit to the same
group. The (*,G) state enables traffic to be
delivered to the receivers as well.
Question: What are the upstream interfaces


states, the upstream interface should be in the
direction of the RP. For (S,G) states, the upstream
interface should be in the direction of the source.
Question: What are the downstream interfaces


and (S,G) states, the downstream interfaces should
be in the direction of the active receivers.
Step 4.14
Verify that multicast traffic is being forwarded by your router by issuing the show
multicast route extensive command.
lab@srxA-1> show multicast route extensive
Group: 224.7.7.122
Source: 172.18.120.2/32

ge-0/0/8.0
Next-hop ID: 262143
Route state: Active
Uptime: 00:01:24

your router? If so, at which rate is it being
forwarded?

for your group. In the example output, the traffic is
being forwarded at a rate of 101 pps.
Step 4.15
Log out of your assigned device using the exit command when complete.
lab@srxA-1> exit
srxA-1 (ttyu0)
login:


Lab 8
Implementing SSM (Detailed)
Overview
This lab demonstrates configuration and monitoring of Internet Group Management
Protocol (IGMP) and Protocol Independent Multicast Sparse Mode (PIM-SM) on devices
running the Junos operating system using the source-specific multicast (SSM) model. In
this lab, you use the command-line interface (CLI) to configure and monitor IGMP,
PIM-SM, and general SSM behavior.
• Configure and monitor IGMP version 3 (IGMPv3).
• Disable the use of rendezvous points (RPs) in the PIM-SM network.
• Verify the flow of multicast traffic through the SSM modeled network using
various group addresses.
www.juniper.net Implementing SSM (Detailed) • Lab 8–1

11.a.11.4R1.6
Part 1: Disabling the Use of RPs
In this lab part, you load a reset configuration file and then stop any leftover rtpqual
processes on your attached receiver.
Step 1.1


Step 1.2
Step 1.3
After the configuration has been loaded, commit the changes and return to
operational mode before proceeding.
srxA-1 (ttyu0)
login: lab
Password:
Lab 8–2 • Implementing SSM (Detailed) www.juniper.net

--- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC

[edit]
load complete
[edit]
commit complete
lab@srxA-1>
Step 1.4
From your device, log in to the attached receiver using SSH with a username of lab
and a password of lab123.
lab@srxA-1> ssh lab@receiver-ip-address
Last login: Fri Mar 8 07:48:07 2011 from 10.1.1.1
[lab@CoS1 ~]$
Step 1.5
Issue the ps -ef | grep rtpqual command to determine the process ID (PID)
of any rtpqual instances that might still exist from the previous lab or classes. Use
the following example as a guide:
[lab@CoS1 ~]$ ps -ef | grep rtpqual
lab 3572 1 0 07:50 ? 00:00:16 ./rtpqual 224.7.7.126 1111 rtp
lab 3714 3683 0 08:47 pts/0 00:00:00 grep rtpqual
Step 1.6
Issue the kill -9 pid command to kill all of the PIDs of any currently running
rtpqual application instances. Use the following example as a guide:
[lab@CoS1 ~]$ kill -9 3572
Step 1.7
device.
[lab@CoS1 ~]$ exit
logout
lab@srxA-1>
Note
previous step.

Step 1.8
Issue the clear igmp statistics and clear igmp membership
commands to clear any IGMP-related information from previous labs.
lab@srxA-1> clear igmp statistics
lab@srxA-1> clear igmp membership

Clearing Group Membership Info for ge-0/0/1.0
Part 2: Configuring IGMPv3
In this lab part, you configure your student device’s ge-0/0/8 interface to run the
IGMPv3 protocol. Next, you will log in to the locally attached receiver and configure it
to send IGMP reports for three different multicast groups. Finally, you will verify, with
show commands, that your student device is receiving the IGMP reports generated
by the receiver.
Step 2.1
Enter configuration mode and navigate to the [edit protocols igmp]
hierarchy. Configure your device’s ge-0/0/8 interface to use IGMPv3. Commit your
configuration and exit to operational mode when complete.
[edit]
lab@srxA-1# edit protocols igmp

lab@srxA-1# set interface ge-0/0/8.0 version 3

commit complete
lab@srxA-1>
Step 2.2
Issue the show igmp interface command to determine which interfaces are
enabled for IGMP.
lab@srxA-1> show igmp interface
Querier: 10.1.1.1
Immediate leave: On
Passive: Off
Querier: 172.18.121.1

State: Up Timeout: 186 Version: 2 Groups: 0
Immediate leave: Off
Passive: Off
Querier: 172.20.77.1
Immediate leave: Off
Passive: Off
Configured Parameters:
IGMP Query Interval: 125.0
IGMP Query Response Interval: 10.0
IGMP Last Member Query Interval: 1.0
IGMP Robustness Count: 2
Derived Parameters:
IGMP Membership Timeout: 260.0
IGMP Other Querier Present Timeout: 255.0
Question: Has the ge-0/0/8 interface been properly

enabled for IGMPv3?
Answer: Yes, the ge-0/0/8 interface should appear

as the only interface enabled for IGMPv3. If the
ge-0/0/8 interface is not listed in the output of the
command, check your local interface configuration
to determine whether any mistakes exist. Ask your
Step 2.3
Analyze the following table to determine the source and group combinations that
you will configure your receiver to join. You might find it beneficial to write your
values down because you will refer to them several times over the following steps.

Receivers Source, Groups

Pod A Any Source, 224.221.1.1
Any Source, 232.221.2.2
172.18.120.2, 232.221.3.3
Pod B Any Source, 224.222.1.1
Any Source, 232.222.2.2
172.18.120.6, 232.222.3.3
Pod C Any Source, 224.223.1.1
Any Source, 232.223.2.2
172.18.120.10, 232.223.3.3
Pod D Any Source, 224.224.1.1
Any Source, 232.224.2.2
172.18.120.14, 232.224.3.3
Step 2.4
From your device, log in to the attached receiver using SSH with a username of lab
and a password of lab123.
lab@srxA-1> ssh lab@receiver-ip-address
[lab@CoS1 ~]$
Step 2.5
Using the rtpqual application, configure your receiver to generate IGMP reports
for the source and group combinations listed in the table. Use the following example
as a guide:
[lab@CoS1 ~]$ ./rtpqual 224.22z.1.1 1111 rtp&
[1] 3789
[lab@CoS1 ~]$ ./rtpqual 232.22z.2.2 1111 rtp&
[2] 3792
[lab@CoS1 ~]$ ./rtpqual 172.18.120.y@232.22z.3.3 1111 rtp&
[3] 3793
Step 2.6
device. You might see output streaming from the rtpqual application. This is okay;
simply issue the exit command and press the Enter key.
[lab@CoS1 ~]$ exit
lab@srxA-1>

Step 2.7
Issue the show igmp group command to verify that your device is receiving IGMP
reports from the locally attached receiver.
Group: 224.0.0.251
Source: 0.0.0.0
Group: 224.221.1.1
Source: 0.0.0.0
Group: 232.221.3.3
Group mode: Include
Source: 172.18.120.2
...

all three of the new groups?
Answer: No, the CLI output should show that the

router is only receiving a report for two of the source
and group combinations. The report for
232.22z.2.2 should be missing.
Question: Is this the expected behavior? What could

be a possible reason for this behavior?
Answer: This behavior is expected. The report

received for 232.22z.2.2 has no source associated
with it. A router that supports the SSM model will
ignore a report from the 232/8 range when no
source is specified.
Step 2.8
Issue the show igmp statistics command and determine whether any
IGMPv3 report errors have been logged.
lab@srxA-1> show igmp statistics
IGMP packet statistics for all interfaces

IGMP Message type Received Sent Rx errors
Membership Query 47 113 0
V1 Membership Report 0 0 0
DVMRP 0 0 0
PIM V1 0 0 0
Cisco Trace 0 0 0
Group Leave 0 0 0
Mtrace Response 0 0 0
Mtrace Request 0 0 0
Domain Wide Report 0 0 0
Other Unknown types 0
IGMP v3 unsupported type 0
IGMP v3 source required for SSM 31
IGMP v3 mode not applicable for SSM 0
IGMP Global Statistics

Bad Length 0
Bad Checksum 0
Bad Receive If 0
Rx non-local 0
Timed out 9
Rejected Report 0
Total Interfaces 3
Question: Has your router noticed any IGMP report

errors? Why or why not?
Answer: Yes, the report that is causing the “IGMP

v3 source required for SSM” error is the one
with the source and group combination of
Any Source/232.22x.2.2. A report carrying a
232/8 group address must have a source
associated with the group address.
Part 3: Viewing PIM-SM SSM Behavior
In this lab part, you use CLI commands to determine how PIM-SM is reacting to the
IGMP reports that are being received by the receiver’s designated router (DR).
Step 3.1
Issue the show pim join extensive command to determine the (S,G) state of
your router, which is the receiver’s DR.

Group: 232.221.3.3
Source: 172.18.120.2
Flags: sparse,spt
Upstream state: Join to Source
Uptime: 00:59:47

Question: Have PIM Join messages been sent

upstream toward the source for each of the three
IGMP reports that have been received? Is this the
expected behavior?
Answer: Only a single shortest-path tree (SPT) has

been formed. A Join message has been sent for the
source group combination of 172.18.121.y/
232.22z.3.3 only. This is expected because,
without an RP defined in the network, the receiver’s
DR, in most cases, must learn the source from the
receiver. Your router does not know the source for
224.22z.1.1 and 232.22z.2.2.
Part 4: Configuring an ssm-map
In this lab part, you create an ssm-map and apply it to IGMP on the receiver-facing
interface. The purpose of the ssm-map will be to statically assign a source to the
two groups (224.22z.1.1 and 232.22z.2.2). This feature allows you to support
IGMPv1 and IGMPv2 in an SSM-modeled network (it also works for IGMPv3). Refer
to the table in the previous section as needed.
Step 4.1
Enter configuration mode and navigate to the [edit policy-options]
hierarchy. Create a policy called ssm-groups that uses route filters to match on
224.22z.1.1 and 232.22z.2.2.
[edit]
lab@srxA-1# edit policy-options

lab@srxA-1# set policy-statement ssm-groups term 10 from route-filter
224.22z.1.1 exact
lab@srxA-1# set policy-statement ssm-groups term 10 from route-filter
232.22z.2.2 exact
lab@srxA-1# set policy-statement ssm-groups term 10 then accept
lab@srxA-1#
Step 4.2
Navigate to the [edit routing-options multicast] hierarchy and
configure an ssm-map named map1. Configure the ssm-map to associate a
specific source to any IGMP message that reports membership to 224.22z.1.1 and
232.22z.2.2 by applying the ssm-groups policy to the ssm-map. Use the same
source IP address that is being used for the 232.22z.3.3 group.
lab@srxA-1# up 1 edit routing-options multicast
[edit routing-options multicast]

lab@srxA-1# set ssm-map map1 source source-ip-address policy ssm-groups

lab@srxA-1#
Step 4.3
Navigate to the [edit protocols igmp] hierarchy and apply the map1
ssm-map to the ge-0/0/8 interface. Commit your configuration and exit to
operational mode when complete.
lab@srxA-1# top edit protocols igmp

lab@srxA-1# set interface ge-0/0/8.0 ssm-map map1

commit complete
lab@srxA-2>
Step 4.4
In previous steps you noticed that your router was ignoring IGMP reports for
232.22z.2.2. In this step, you verify that your router is now accepting the IGMP
reports for 232.22z.2.2. However, because rtpqual sends reports every 60
seconds, you might have to wait up to 60 seconds for your router to receive the next
IGMP report for 232.22z.2.2.

Issue the show igmp group command to verify that your router is now accepting
the IGMP report for 232.22z.2.2.
Group: 224.0.0.251
Source: 0.0.0.0
Group: 224.221.1.1
Group mode: Include
Source: 172.18.120.2
Group: 232.221.2.2
Group mode: Include
Source: 172.18.120.2
Group: 232.221.3.3
Group mode: Include
Source: 172.18.120.2
...
Question: Is your router accepting the IGMP reports

for 232.22z.2.2?
Answer: Yes, your router should now be accepting

the IGMP reports. If you do not see an entry for
232.22z.2.2, please wait up to 60 seconds
(rtpqual’s report interval) and then issue the
command again. If, after 60 seconds, you do not
see an entry for 232.22z.2.2, notify your instructor.
Question: What is the source associated with the

224.22z.1.1 and 232.22z.2.2 groups? Why?
Answer: As a result of configuring the ssm-map,

both groups should be associated with the same
source as the source of the 232.22z.3.3 traffic.
Step 4.5
Issue the show pim join extensive command, verify that an SPT has been
built from source to receiver for all three multicast groups.

Group: 224.221.1.1
Source: 172.18.120.2
Flags: sparse,spt
Uptime: 00:04:17
Group: 232.221.2.2
Source: 172.18.120.2
Flags: sparse,spt
Uptime: 00:03:58
Group: 232.221.3.3
Source: 172.18.120.2
Flags: sparse,spt
Uptime: 00:04:17


Question: Have PIM Join messages been sent
upstream toward the source for each of the three
multicast groups? Is this the expected behavior?
Answer: Yes, PIM Join messages have been sent for

all three multicast groups. Yes, this is the expected
behavior.
Step 4.6
Issue the show multicast route extensive command to determine
whether multicast data is being forwarded by your router for all three multicast
groups.
lab@srxA-1> show multicast route extensive
Group: 224.221.1.1
Source: 172.18.120.2/32
ge-0/0/8.0
Next-hop ID: 262143
Route state: Active
Uptime: 00:05:16
Group: 232.221.2.2
Source: 172.18.120.2/32
ge-0/0/8.0
Session description: Source specific multicast
Next-hop ID: 262143
Route state: Active
Uptime: 00:04:57
Group: 232.221.3.3
Source: 172.18.120.2/32
ge-0/0/8.0

Session description: Source specific multicast
Next-hop ID: 262143
Route state: Active
Uptime: 00:05:16

your router for all three groups?

for all three groups.
Step 4.7
Log out of your assigned device using the exit command when complete.
lab@srxA-1> exit
srxA-1 (ttyu0)
login:

Lab 9
Implementing CoS Features in the Enterprise (Detailed)
Overview
This lab demonstrates the implementation and testing of various class-of-service (CoS)
components in a network. In this lab, you use the CLI to configure and manipulate
configuration.
• Configure multifield and behavior aggregate classifiers.
• Configure a policer for different traffic classes.
• Create drop profiles.
• Configure packet marking.
www.juniper.net Implementing CoS Features in the Enterprise (Detailed) • Lab 9–1

11.a.11.4R1.6
Part 1: Loading the Initial Configuration and Accessing the CoS Host
In this lab part, you use two CLI sessions to accomplish the lab’s goals. You will first
log in to your assigned SRX Series student device in the same manner as for
previous labs. Next, you will open a second session to your assigned student device
and then SSH from there to the CoS end-host device.
Step 1.1


Step 1.2
directed by your instructor. Refer to the management network diagram for the
IP address associated with your student device. The following example uses a
simple Telnet access to srxA-1 with the Secure CRT program as a basis:
Step 1.3
srxA-1 (ttyu0)
login: lab
Lab 9–2 • Implementing CoS Features in the Enterprise (Detailed) www.juniper.net

Password:
--- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC

[edit]
load complete
[edit]
lab@srxA-1# commit
commit complete
Step 1.4
Open a second session to your assigned student device and log in with the
username lab using a password of lab123. From that session, log in to the
attached CoS host using SSH with a username of lab and a password of lab123.
Refer to the lab diagram as needed.
srxA-1 (ttyu0)
login: lab
Password:
--- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC

lab@srxA-1> ssh lab@CoS-host-address
[lab@CoS1 ~]$
Note
You will use the CoS host for the remainder
of the lab. If you have any problems
accessing the host, please see the
instructor.
Part 2: Configuring Traffic Classification
In this lab part, you configure traffic classification with a multifield classifier and a
behavior aggregate. Once complete, you will use the CoS host to test your
configuration.
Step 2.1
On the SRX Series device, navigate to the [edit class-of-service]
configuration hierarchy. Assign forwarding-class queue 4 with a class-name data.
[edit]
lab@srxA-1# edit class-of-service

[edit class-of-service]
lab@srxA-1# set forwarding-classes queue 4 data
lab@srxA-1#
Step 2.2
Navigate to the top of the configuration hierarchy. Create a firewall filter named
MF-class. In this firewall filter, create a term named scp that matches traffic from
destination-port 22. Set the action for term scp to forwarding-class data and
loss-priority low. Create a second term named accept, with an action to accept.
Apply the firewall filter MF-class as an input filter to the ge-0/0/8.0 interface.
When complete, issue the commit command to activate the changes.
lab@srxA-1# top
[edit]
lab@srxA-1# set firewall filter MF-class term scp from destination-port 22
[edit]
lab@srxA-1# set firewall filter MF-class term scp then forwarding-class data
[edit]
lab@srxA-1# set firewall filter MF-class term scp then loss-priority low
[edit]
lab@srxA-1# set firewall filter MF-class term accept then accept
[edit]
lab@srxA-1# set interfaces ge-0/0/8 unit 0 family inet filter input MF-class
[edit]
lab@srxA-1# show firewall
filter MF-class {
term scp {
from {
destination-port 22;
}
then {
loss-priority low;
forwarding-class data;
}
}
term accept {
then accept;
}
}
[edit]
lab@srxA-1# show class-of-service
forwarding-classes {
queue 4 data;
}

[edit]
lab@srxA-1# show interfaces ge-0/0/8
unit 0 {
family inet {
filter {
input MF-class;
}
address 10.1.1.1/30;
}
}
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
Question: How many queues are supported on the

SRX Series device?
Answer: An SRX Series device supports eight

queues on all interfaces.
Step 2.3
Navigate to the [edit class-of-service] configuration hierarchy. Create a
DiffServ code point (DSCP) behavior aggregate classifier named BA-class. In this
classifier, import the default DSCP classification.
[edit]
lab@srxA-1# edit class-of-service
lab@srxA-1# set classifiers dscp BA-class import default
lab@srxA-1#
Step 2.4
Within the BA-class classifier created in the previous step, match on code points
ef and cs5 for forwarding-class expedited-forwarding. Set the loss priority to low.
lab@srxA-1# set classifiers dscp BA-class forwarding-class expedited-forwarding
loss-priority low code-points ef
lab@srxA-1# set classifiers dscp BA-class forwarding-class expedited-forwarding
loss-priority low code-points cs5

Question: What is the purpose of the DSCP class
selector (CS) per-hop behavior group?
Answer: To maintain backward compatibility with

network devices that still use the IP Precedence
field, DiffServ defines the CS per-hop behavior
group.
Step 2.5
Apply the BA-class behavior aggregate classifier to all gigabit interfaces on your
assigned student device. When complete, issue the commit command to activate
the changes.
lab@srxA-1# set interfaces ge-* unit * classifiers dscp BA-class
lab@srxA-1# show classifiers
dscp BA-class {
import default;
forwarding-class expedited-forwarding {
loss-priority low code-points [ ef cs5 ];
}
}
lab@srxA-1# show interfaces
ge-* {
unit * {
classifiers {
dscp BA-class;
}
}
}
lab@srxA-1# commit
commit complete
Step 2.6
Issue the run clear interfaces statistics all command to clear the
statistics for all interfaces.
lab@srxA-1# run clear interfaces statistics all
Step 2.7
Return to the CLI session on your CoS host.
On the CoS host, secure copy (scp) a file named smallfile.txt in a folder called
lab7files from the other team’s host to your local directory. Use the scp
cosZ:lab7files/smallfile.txt smallfile.txt command, where Z is
the number (1 or 2) of the other team, to complete this step.
Note
The hosts are predefined with key
authentication; thus a password should not
be needed. If prompted for a password, use
lab123.
[lab@CoS1 ~]$ scp cosZ:lab7files/smallfile.txt smallfile.txt

smallfile.txt 100% 1024KB 341.3KB/s 00:03
[lab@CoS1 ~]$
Step 2.8
On the CoS host, ping the other team’s host 10 times with a type of service (ToS)
value of 184. Use the ping -Q 184 -c 10 cosZ command for this task, where
Z is the other team’s assigned host number.
[lab@CoS1 ~]$ ping -Q 184 -c 10 cosZ
PING cos2 (20.1.1.2) 56(84) bytes of data.
64 bytes from cos2 (20.1.1.2): icmp_seq=1 ttl=62 time=5.22 ms
--- cos2 ping statistics ---

10 packets transmitted, 10 received, 0% packet loss, time 11807ms
rtt min/avg/max/mdev = 1.185/1.659/5.228/1.192 ms
Step 2.9
On the SRX Series device, issue a run show interfaces ge-0/0/1
extensive | find "Queue counters" command and inspect the queue
counters.
lab@srxA-1# run show interfaces ge-0/0/1 extensive | find "Queue counters"
Queue counters: Queued packets Transmitted packets Dropped packets
0 best-effort 931 931 0
1 expedited-fo 20 20 0
2 assured-forw 0 0 0
3 network-cont 0 0 0
4 data 755 755 0
...

Question: Are there any packets in the data and
expedited-forwarding queues?
Answer: Your output might vary, but you should have

at least 10 packets in the expedited-forwarding
queue and approximately 750 packets in the data
queue.
Part 3: Configuring Policers
In this lab part, you configure policers and apply them using firewall filters. Different
policer actions are applied in this lab part.
Step 3.1
Navigate to the [edit firewall] configuration hierarchy. Create a policer
named port80 that discards traffic when the bandwidth exceeds 1 megabit. In
addition, set a burst size limit of 640 kilobytes for this policer.
lab@srxA-1# top edit firewall
[edit firewall]
lab@srxA-1# set policer port80 if-exceeding bandwidth-limit 1m
[edit firewall]
lab@srxA-1# set policer port80 if-exceeding burst-size-limit 640k
[edit firewall]
lab@srxA-1# set policer port80 then discard
[edit firewall]
lab@srxA-1#
Step 3.2
Create a new term named http-dst in the firewall filter MF-class. This new term
should match traffic destined to port 80. Set the action of the term to then
policer port80.
[edit firewall]
lab@srxA-1# set filter MF-class term http-dst from destination-port 80
[edit firewall]
lab@srxA-1# set filter MF-class term http-dst then policer port80
Step 3.3
Insert the new http-dst term before the term scp in the MF-class filter. When
complete, issue the commit command to activate the changes.
[edit firewall]
lab@srxA-1# insert filter MF-class term http-dst before term scp

[edit firewall]
lab@srxA-1# show policer port80
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 640k;
}
then discard;
[edit firewall]
lab@srxA-1# show filter MF-class
term http-dst {
from {
}
then policer port80;
}
term scp {
from {
}
then {
loss-priority low;
}
}
term accept {
then accept;
}
[edit firewall]
lab@srxA-1# commit
commit complete
Step 3.4
Create a policer named voice-overflow. Set the policer’s action to
forwarding-class best-effort and loss-priority high if the bandwidth exceeds
3 megabits. In addition, set a burst size limit of 640 kilobytes for this policer.
[edit firewall]
lab@srxA-1# set policer voice-overflow if-exceeding bandwidth-limit 3m
[edit firewall]
lab@srxA-1# set policer voice-overflow if-exceeding burst-size-limit 640k
[edit firewall]
lab@srxA-1# set policer voice-overflow then forwarding-class best-effort
[edit firewall]
lab@srxA-1# set policer voice-overflow then loss-priority high
Step 3.5
Within the MF-class firewall filter, create a new term named voip-limit that
matches traffic with the DSCP class ef. Set the action of the term to then
policer voice-overflow.

[edit firewall]
lab@srxA-1# set filter MF-class term voip-limit from dscp ef
[edit firewall]
lab@srxA-1# set filter MF-class term voip-limit then policer voice-overflow
Step 3.6
Insert the new voip-limit term before the term scp in the MF-class filter.
[edit firewall]
lab@srxA-1# insert filter MF-class term voip-limit before term scp
[edit firewall]
lab@srxA-1# show filter MF-class
term http-dst {
from {
}
then policer port80;
}
term voip-limit {
from {
dscp ef;
}
then policer voice-overflow;
}
term scp {
from {
}
then {
loss-priority low;
}
}
term accept {
then accept;
}
[edit firewall]
lab@srxA-1# commit
commit complete
Question: Why is it important to rate-limit

high-priority traffic on an SRX Series device?
Answer: On SRX Series devices, a high-priority

queue starves all other priorities unless it is
rate-limited. The same result occurs for
medium-high and medium, medium-low and low,
and so on down the priority chain.

Part 4: Configuring and Testing Schedulers and Drop Profiles
In this lab part, you configure and test schedulers and drop profiles.
Step 4.1
Navigate to the [edit class-of-service schedulers] configuration
hierarchy. Create the following five schedulers with the criteria listed in the table.
Name Criteria
be • transmit-rate percent 20
• priority low
• drop-profile-map loss-priority high
protocol any drop-profile aggressive
ef • priority high
• buffer-size percent 20
af • transmit-rate percent 20 exact
• priority medium-high
nc • transmit-rate percent 5
• priority low
data • transmit-rate percent 20
• priority medium-high
[edit firewall]
lab@srxA-1# top edit class-of-service schedulers
[edit class-of-service schedulers]

lab@srxA-1# set be transmit-rate percent 20

lab@srxA-1# set be priority low

lab@srxA-1# set be drop-profile-map loss-priority high protocol any
drop-profile aggressive

lab@srxA-1# set ef priority high

lab@srxA-1# set ef buffer-size percent 20

lab@srxA-1# set af priority medium-high


lab@srxA-1# set af transmit-rate percent 20 exact

lab@srxA-1# set nc transmit-rate percent 5

lab@srxA-1# set nc priority low

lab@srxA-1# set data transmit-rate percent 20

lab@srxA-1# set data priority medium-high

lab@srxA-1#
Question: What is the meaning of the exact option

after the transmit-rate?
Answer: It is used to shape traffic to the configured

transmit-rate.
Step 4.2
Navigate to the [edit class-of-service drop-profiles] configuration
hierarchy. Create a drop profile named aggressive with the criteria listed in the
following table:
Drop-Profile Criteria
aggressive • fill-level 30 drop-probability 40
• fill-level 80 drop-probability 60

lab@srxA-1# up 1 edit drop-profiles
[edit class-of-service drop-profiles]

lab@srxA-1# set aggressive fill-level 30 drop-probability 40

lab@srxA-1# set aggressive fill-level 80 drop-probability 60

lab@srxA-1#

Step 4.3
Navigate to the [edit class-of-service scheduler-maps] configuration
hierarchy. Create a scheduler-map named my-sched-map with the mappings
listed in the following table:
Scheduler-Map Mappings
my-sched-map • forwarding-class best-effort
scheduler be
• forwarding-class
expedited-forwarding scheduler ef
• forwarding-class assured-forwarding
scheduler af
• forwarding-class network-control
scheduler nc
• forwarding-class data scheduler data

lab@srxA-1# up 1 edit scheduler-maps
[edit class-of-service scheduler-maps]

lab@srxA-1# set my-sched-map forwarding-class best-effort scheduler be

lab@srxA-1# set my-sched-map forwarding-class expedited-forwarding scheduler ef

lab@srxA-1# set my-sched-map forwarding-class assured-forwarding scheduler af

lab@srxA-1# set my-sched-map forwarding-class network-control scheduler nc

lab@srxA-1# set my-sched-map forwarding-class data scheduler data

lab@srxA-1# show
my-sched-map {
forwarding-class best-effort scheduler be;
forwarding-class expedited-forwarding scheduler ef;
forwarding-class assured-forwarding scheduler af;
forwarding-class network-control scheduler nc;
forwarding-class data scheduler data;
}

lab@srxA-1# top show class-of-service schedulers
be {
transmit-rate percent 20;
priority low;
drop-profile-map loss-priority high protocol any drop-profile aggressive;
}
ef {
buffer-size percent 20;
priority high;
}
af {
transmit-rate percent 20 exact;
priority medium-high;
}
nc {
priority low;
}
data {
priority medium-high;
}

lab@srxA-1# top show class-of-service drop-profiles
aggressive {
fill-level 30 drop-probability 40;
fill-level 80 drop-probability 60;
}

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 4.4
Issue the run clear interfaces statistics all command to clear the
statistics for all interfaces.
Step 4.5
On the CoS host, run the gendata.sh command. The shell script will run for a few
minutes. Please allow it to finish before proceeding.
.
Note
gendata.sh is a shell script made for this
lab that generates different types of data
transfers, populating all the queues.

[lab@CoS2 ~]$ gendata.sh
Please login with USER and PASS.
Interactive mode off.
[lab@CoS2 ~]$
Step 4.6
On the SRX Series device, issue the run show interfaces ge-0/0/1
extensive | find "Queue counters" command to view the current queue
counters.
0 best-effort 76652 73184 3468
1 expedited-fo 2941 174 2767
2 assured-forw 10004 10004 0
4 data 0 0 0
...
Question: How many drops are in the

expedited-forwarding queue?
Answer: You should see more than 2000 drops in

the expedited-forwarding queue.
Step 4.7
Navigate to the [edit class-of-service] configuration hierarchy. Apply the
scheduler-map my-sched-map to interface ge-0/0/1. Issue the commit
command to activate the changes.
lab@srxA-1# up
lab@srxA-1# set interfaces ge-0/0/1 scheduler-map my-sched-map
lab@srxA-1# commit
commit complete
lab@srxA-1#
Step 4.8
Issue the command run clear interfaces statistics all to clear the
interface statistics for all interfaces.

Step 4.9
On the CoS host, run the gendata.sh command again. As before, allow the script
to finish before proceeding.
[lab@CoS2 ~]$ gendata.sh
Interactive mode off.
[lab@CoS2 ~]$
Step 4.10
On the SRX Series device, issue the run show interfaces ge-0/0/1
extensive | find "Queue counters" command to view the current queue
counters.
0 best-effort 77851 71538 6313
1 expedited-fo 2941 2929 12
2 assured-forw 9339 9339 0
4 data 0 0 0
...
Question: How many drops do you see in the

expedited-forwarding queue now?
Answer: The count might vary, but you should now

see less than 50 dropped packets.
Step 4.11
Issue the run show interfaces queue ge-0/0/1 forwarding-class
best-effort command to view details about the best-effort queue.
lab@srxA-1# run show interfaces queue ge-0/0/1 forwarding-class best-effort
Physical interface: ge-0/0/1, Enabled, Physical link is Up
Interface index: 135, SNMP ifIndex: 508
Forwarding classes: 8 supported, 5 in use
Egress queues: 8 supported, 5 in use
Queue: 0, Forwarding classes: best-effort
Queued:
Packets : 77957 0 pps
Bytes : 76001724 0 bps
Transmitted:
Packets : 71644 0 pps
Bytes : 66461740 0 bps
Tail-dropped packets : 4634 0 pps

RED-dropped packets : 1679 0 pps
Low : 0 0 pps
Medium-low : 0 0 pps
Medium-high : 0 0 pps
High : 1679 0 pps
RED-dropped bytes : 2538648 0 bps
Low : 0 0 bps
Medium-low : 0 0 bps
Medium-high : 0 0 bps
High : 2538648 0 bps
Question: How many high-priority random early

detection (RED)-dropped packets does the router
display?
Answer: The count will vary, but you should see

more than 1000 loss-priority high drops. Recall
from an earlier task that any expedited forwarding
(EF)-marked packets that were over 3 Mbps were
sent to the best-effort queue and marked as high
loss. The drop-profile aggressive is used for
packets marked as high loss in the best-effort
queue.
Part 5: Configuring and Testing a Rewrite Marker
In this lab part, you configure and test a rewrite marker.

Step 5.1
Navigate to the [edit class-of-service rewrite-rules] configuration
hierarchy. Create a DSCP rewrite-rule named dscp-rewrite. In this rewrite rule,
import the default markings.
lab@srxA-1# edit rewrite-rules
[edit class-of-service rewrite-rules]

lab@srxA-1# set dscp dscp-rewrite import default

lab@srxA-1#
Step 5.2
In the dscp-rewrite rewrite rule, configure forwarding-class best-effort with
loss-priority low to have a marking of af31.
lab@srxA-1# set dscp dscp-rewrite forwarding-class best-effort loss-priority
low code-point af31

Step 5.3
Navigate to the [edit class-of-service] configuration hierarchy. Apply the
dscp-rewrite rewrite rule to the ge-0/0/8 unit 0 interface. When complete,
lab@srxA-1# up
lab@srxA-1# set interfaces ge-0/0/8 unit 0 rewrite-rules dscp dscp-rewrite
lab@srxA-1# show interfaces ge-0/0/8
unit 0 {
rewrite-rules {
dscp dscp-rewrite;
}
}
lab@srxA-1# show rewrite-rules
dscp dscp-rewrite {
import default;
forwarding-class best-effort {
loss-priority low code-point af31;
}
}
lab@srxA-1# commit
commit complete
lab@srxA-1#
Step 5.4
On the CoS host, issue the sudo /usr/sbin/tshark -w icmp.cap -ni
eth1 -c 10 dst host srx command. Use lab123 for a password when
prompted.
Let the command run, and proceed to the next step.
[lab@cos2 ~]$ sudo /usr/sbin/tshark -w icmp.cap -ni eth1 -c 10 dst host srx
[sudo] password for lab:
Running as user "root" and group "root". This could be dangerous.
Capturing on eth1
Step 5.5
On the SRX Series device, ping the other team’s CoS host from your SRX Series
device. Set the ToS byte to 96 and only send 10 pings. Refer to the network diagram
as needed.

Note
When using the ToS byte option when
pinging, it accounts for the entire 8 bit ToS
field of the IP header. The following is a
table representing AF31 and CS3 DSCP
class selectors in decimal, accounting for 6
and 8 bits:
CS3: ToS = 96 DSCP = 24
AF31 ToS = 104 DSCP = 26
lab@srxA-1# run ping peer-CoS-host tos 96 count 10
PING 20.1.1.2 (20.1.1.2): 56 data bytes
64 bytes from 20.1.1.2: icmp_seq=0 ttl=63 time=2.258 ms
...
Step 5.6
On the CoS host, the tshark command should have finished. Read the icmp.cap
output file matching for the DSCP field. Use the command
sudo /usr/sbin/tshark -r icmp.cap -V | egrep DSCP for this task.
If prompted for a password, use lab123.
[lab@CoS1 ~]$ sudo /usr/sbin/tshark -r icmp.cap -V | egrep DSCP
Running as user "root" and group "root". This could be dangerous.
Differentiated Services Field: 0x68 (DSCP 0x1a: Assured Forwarding 31; ECN:
0x00)
0x00)
0x00)
0x00)
0x00)
0x00)
0x00)
0x00)
0x00)
0x00)

Question: Is the rewrite configuration working
properly?
Answer: Yes, the capture should show AF31 packets

that were originally sent as CS3 from the router.
Step 5.7
Using the exit command, log out of the CoS host and then log out of your second
SRX Series CLI session.
[lab@CoS1 ~]$ exit
logout
lab@srxA-1> exit

Step 5.8
On the SRX Series device, navigate to the top hierarchy and issue the load
override ajer/reset.config command to load the reset configuration file.
Commit the changes, return to operational mode, and then log out of your assigned
device.
lab@srxA-1# top
[edit]
load complete
[edit]
commit complete
lab@srxA-1> exit
srxA-1 (ttyu0)
login:

Lab 10
BGP Route Reflection (Detailed)
Overview
Within a local autonomous system (AS) topology, the internal BGP (IBGP) peers are fully
meshed to prevent routing loops from forming. A fully meshed network inherently has
scalability issues, which include the explicit configuration of all IBGP peer with the
addition of a new router. One method to alleviate the full mesh requirement and still
ensure a loop-free BGP topology is route reflection. Route reflection provides a
loop-detection mechanism within IBGP to allow IBGP routes to be readvertised to other
IBGP peers.
In this lab, you use the lab diagrams titled “Lab 10: BGP Route Reflection—Parts 1–2,”
“Lab 10: BGP Route Reflection—Part 3,” and “Lab 10: BGP Route Reflection—Part 4” to
configure and monitor BGP route reflection.
• Load the extended topology.
• Verify standard IBGP behavior.
• Configure route reflection.
• Examine the reflected routes.
• Add a third client router.
• Verify routes on a third client router.
www.juniper.net BGP Route Reflection (Detailed) • Lab 10–1

11.a.11.4R1.6
In this lab part, you load a baseline configuration that automatically configures your
router according to the lab diagram labeled “Lab 10: BGP Route Reflection—
Parts 1–2.”
Step 1.1


Step 1.2
directed by your instructor. Refer to the management network diagram for the
IP address associated with your student device. The following example uses a
simple Telnet access to srxA-1 with the Secure CRT program as a basis:
Step 1.3
srxA-1 (ttyu0)
login: lab
Password:
Lab 10–2 • BGP Route Reflection (Detailed) www.juniper.net

--- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC
[edit]
load complete
[edit]
lab@srxA-1# commit
commit complete
Part 2: Verifying Topology
In this lab part, you verify router-to-router connectivity and BGP operations using the
command-line interface (CLI).
Note
The lab topology makes extensive use of
virtual routing instances configured on the
SRX Series student device. When using
certain show commands, you must use the
instance option and include the routing
instance name (master, C1, C2, or C3).
Furthermore, you must also use the table
option to display routing table information
specific to the routing instance with which
you are working.
Step 2.1
To verify your IGP is working properly on your student device, issue the run show
ospf neighbor instance master command. You should have four OSPF
adjacencies in the Full state. Two adjacencies are to your remote partner’s student
device. The remaining two adjacencies are to each of your virtual routers (C1 and
C2).
[edit]
lab@srxA-1# run show ospf neighbor instance master
172.20.1.2 ge-0/0/1.0 Full 192.168.2.1 128 36
172.20.3.2 ge-0/0/14.1 Full 192.168.1.2 128 35
172.20.4.2 ge-0/0/14.2 Full 192.168.1.3 128 35
172.20.2.2 ge-0/0/2.0 Full 192.168.2.1 128 39
Step 2.2
To verify your network has a full mesh of IBGP peers, issue the run show bgp
summary instance instance-name command three times, once each where
the instance name is master, C1, and C2. Your student device, and each of the two
virtual routers, should each have five established BGP peers at this time, one to
each of the other routers in the network.

lab@srxA-1# run show bgp summary instance master
inet.0 4 4 0 0 0 0
192.168.1.2 64700 99 98 0 0 44:07 Establ
inet.0: 1/1/1/0
192.168.1.3 64700 100 97 0 0 44:03 Establ
inet.0: 1/1/1/0
192.168.2.1 64700 39 39 0 1 17:27 Establ
inet.0: 0/0/0/0
192.168.2.2 64700 39 38 0 0 16:45 Establ
inet.0: 1/1/1/0
192.168.2.3 64700 39 67 0 0 17:35 Establ
inet.0: 1/1/1/0
[edit]
lab@srxA-1# run show bgp summary instance C1
C1.inet.0 3 3 0 0 0 0
192.168.1.1 64700 132 133 0 2 59:44 Establ
C1.inet.0: 0/0/0/0
192.168.1.3 64700 133 131 0 0 59:40 Establ
C1.inet.0: 1/1/1/0
192.168.2.1 64700 74 74 0 0 33:20 Establ
C1.inet.0: 0/0/0/0
192.168.2.2 64700 74 73 0 0 32:46 Establ
C1.inet.0: 1/1/1/0
192.168.2.3 64700 76 74 0 0 33:22 Establ
C1.inet.0: 1/1/1/0
[edit]
C2.inet.0 3 3 0 0 0 0
192.168.1.1 64700 130 134 0 2 59:42 Establ
C2.inet.0: 0/0/0/0
192.168.1.2 64700 130 133 0 0 59:42 Establ
C2.inet.0: 1/1/1/0
192.168.2.1 64700 73 74 0 0 33:18 Establ
C2.inet.0: 0/0/0/0
192.168.2.2 64700 73 72 0 0 32:36 Establ
C2.inet.0: 1/1/1/0
192.168.2.3 64700 74 74 0 0 33:20 Establ
C2.inet.0: 1/1/1/0

Step 2.3
Each virtual router is advertising a different route in the 200.200/16 space. To
verify these routes are being propagated throughout the network, issue the run
show route 200.200/16 table table-name command three times, once
each where the table name is inet.0, C1.inet.0, and C2.inet.0.
[edit]
lab@srxA-1# run show route 200.200/16 table inet.0


AS path: I
> to 172.20.3.2 via ge-0/0/14.1
AS path: I
> to 172.20.2.2 via ge-0/0/2.0
AS path: I
> to 172.20.4.2 via ge-0/0/14.2
AS path: I
> to 172.20.2.2 via ge-0/0/2.0
[edit]
lab@srxA-1# run show route 200.200/16 table C1.inet.0
C1.inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)

200.200.1.0/24 *[Static/5] 04:44:08

Reject
AS path: I
> to 172.20.3.1 via ge-0/0/15.1
AS path: I
> to 172.20.3.1 via ge-0/0/15.1
AS path: I
> to 172.20.3.1 via ge-0/0/15.1
[edit]


AS path: I
> to 172.20.4.1 via ge-0/0/15.2
AS path: I
> to 172.20.4.1 via ge-0/0/15.2
200.200.3.0/24 *[Static/5] 00:48:04
Reject
AS path: I
> to 172.20.4.1 via ge-0/0/15.2
Question: How many routes are in each table?
Answer: Each table should have four routes

present.
Part 3: Converting to Route Reflectors
To this point, we have verified that our fully meshed IBGP network is working
properly. All the 200.200/16 routes are being propagated throughout the network.
Now, imagine a scenario in which you need to add a new router to your network. To
maintain the BGP requirement of a full mesh, you would have to configure six IBGP
peering sessions on the new router, one for each of the existing routers.
Furthermore, you would have to configure this new router as an IBGP peer on every
other router in the network. What if you had 50 routers? 100? You can quickly see
that the BGP requirement of a full mesh does not scale well.
In this lab part, you reconfigure your current network into a route-reflected network.
Use the lab diagram title “Lab 10: BGP Route Reflection—Part 3” for this section.
Step 3.1
Navigate to the [edit protocols bgp] hierarchy and issue the show
command to view the current BGP configuration for your student device.
[edit]

lab@srxA-1# show
type internal;
neighbor 192.168.1.2;
neighbor 192.168.1.3;
neighbor 192.168.2.1;
neighbor 192.168.2.2;
neighbor 192.168.2.3;
}

lab@srxA-1#

Step 3.2
Delete the my-int-group group and create a new group named
my-mesh-group. Configure the my-mesh-group group as a standard IBGP
session with only one neighbor—the other route reflector’s loopback address. Do not
forget the type and local-address statements.
lab@srxA-1# delete group my-int-group

lab@srxA-1# edit group my-mesh-group
[edit protocols bgp group my-mesh-group]

lab@srxA-1# set type internal

lab@srxA-1# set local-address loopback-address

lab@srxA-1# set neighbor remote-partner-loopback-address

lab@srxA-1# show
type internal;
neighbor 192.168.2.1;

lab@srxA-1#
Step 3.3
Navigate to the [edit protocols bgp group rr-cluster] hierarchy.
Configure the rr-cluster group as an IBGP group that includes the loopback
addresses of your two locally attached virtual routers as neighbors. Do not forget the
type and local-address statements. However, do not include the cluster
statement at this time.
lab@srxA-1# up 1 edit group rr-cluster
[edit protocols bgp group rr-cluster]

lab@srxA-1# set type internal

lab@srxA-1# set local-address loopback-address

lab@srxA-1# set neighbor local-C1-loopback-address


lab@srxA-1#

Step 3.4
Navigate to the [edit routing-instances C1 protocols bgp] hierarchy.
Issue the show command to view the current BGP configuration for the C1 virtual
router.
lab@srxA-1# top edit routing-instances C1 protocols bgp
[edit routing-instances C1 protocols bgp]

lab@srxA-1# show
type internal;
export static-to-bgp;
neighbor 192.168.1.1;
neighbor 192.168.1.3;
neighbor 192.168.2.1;
neighbor 192.168.2.2;
neighbor 192.168.2.3;
}

lab@srxA-1#
Step 3.5
Within the my-int-group group, delete all neighbors except for the locally
attached route-reflector loopback address.
lab@srxA-1# delete group my-int-group neighbor local-C2-loopback-address

lab@srxA-1# delete group my-int-group neighbor remote-partner-loopback-address

lab@srxA-1# delete group my-int-group neighbor remote-C1-loopback-address


lab@srxA-1# show
type internal;
neighbor 192.168.1.1;
}
Step 3.6
Issue the show command to view the current BGP configuration for the C2 virtual
router.

lab@srxA-1# up 3 edit C2 protocols bgp

lab@srxA-1# show
type internal;
neighbor 192.168.1.1;
neighbor 192.168.1.2;
neighbor 192.168.2.1;
neighbor 192.168.2.2;
neighbor 192.168.2.3;
}

lab@srxA-1#
Step 3.7
Within the my-int-group group, delete all neighbors except for the locally
attached route-reflector loopback address. Refer to your lab diagram as needed.
When complete, issue the commit command to activate your changes.
lab@srxA-1# delete group my-int-group neighbor local-C1-loopback-address

lab@srxA-1# delete group my-int-group neighbor remote-partner-loopback-address



lab@srxA-1# show
type internal;
neighbor 192.168.1.1;
}
lab@srxA-1# commit
commit complete
Note
previous step.

Step 3.8
Issue the run show route 200.200/16 table table-name command
three times, once each where the table name is inet.0, C1.inet.0, and
C2.inet.0.


AS path: I
> to 172.20.3.2 via ge-0/0/14.1
AS path: I
> to 172.20.4.2 via ge-0/0/14.2


200.200.1.0/24 *[Static/5] 06:24:59

Reject


200.200.3.0/24 *[Static/5] 02:28:56

Reject
Question: Are the 200.200/16 routes being

propagated throughout the network? Why or why
not?
Answer: No. The 200.200/16 routes are not being

propagated throughout the network because of the
IBGP rule that precludes an IBGP speaker from
readvertising routes learned from another IBGP
speaker.
Step 3.9
Navigate to the [edit protocols bgp group rr-cluster] hierarchy. Use
the cluster statement to configure the cluster ID as shown on your lab diagram.

lab@srxA-1# top edit protocols bgp group rr-cluster

lab@srxA-1# set cluster cluster-id

lab@srxA-1# show
type internal;
cluster 1.1.1.1;
neighbor 192.168.1.2;
neighbor 192.168.1.3;

lab@srxA-1# commit
commit complete

lab@srxA-1#
Note
previous step.
Step 3.10
Issue the run show route 200.200/16 table table-name command
three times, once each where the table name is inet.0, C1.inet.0, and
C2.inet.0.
Note
It might take a few moments for the routes
to propagate and populate the tables.



AS path: I
> to 172.20.3.2 via ge-0/0/14.1
AS path: I
> to 172.20.2.2 via ge-0/0/2.0
AS path: I
> to 172.20.4.2 via ge-0/0/14.2
AS path: I

> to 172.20.2.2 via ge-0/0/2.0


200.200.1.0/24 *[Static/5] 07:10:43

Reject
AS path: I
> to 172.20.3.1 via ge-0/0/15.1
AS path: I
> to 172.20.3.1 via ge-0/0/15.1
AS path: I
> to 172.20.3.1 via ge-0/0/15.1



AS path: I
> to 172.20.4.1 via ge-0/0/15.2
AS path: I
> to 172.20.4.1 via ge-0/0/15.2
200.200.3.0/24 *[Static/5] 03:14:41
Reject
AS path: I
> to 172.20.4.1 via ge-0/0/15.2
Question: Are the 200.200/16 routes being

propagated throughout the network?
Answer: Yes, the 200.200/16 routes are again

being propagated throughout the network.
Step 3.11
Issue a run show route prefix/24 table C1.inet.0 detail
command, where prefix is the route advertised from your local C2 virtual router.
lab@srxA-1# run show route prefix/24 table C1.inet.0 detail

200.200.3.0/24 (1 entry, 1 announced)

Address: 0x1660d20
Source: 192.168.1.1
Indirect next hop: 1704e80 262145
State: <Active Int Ext>
Age: 8:06:20 Metric2: 2
Task: BGP_64700.192.168.1.1+61154
Announcement bits (2): 0-KRT 3-Resolve tree 1
AS path: I (Originator) Cluster list: 1.1.1.1
AS path: Originator ID: 192.168.1.3
Accepted
Localpref: 100
Router ID: 192.168.1.1
Question: What do you notice about the AS path

information?
Answer: Because we are using route reflection, the

AS path now contains the two route reflection BGP
attributes: Cluster list and Originator ID.
Step 3.12
Issue a run show route prefix/24 table C1.inet.0 detail
command, where prefix is the route advertised from the remote C1 virtual router.
lab@srxA-1# run show route prefix/24 table C1.inet.0 detail

200.200.2.0/24 (1 entry, 1 announced)
Address: 0x1661a30
Source: 192.168.1.1
Indirect next hop: 1705220 262148
State: <Active Int Ext>
Age: 8:11:52 Metric2: 3
Task: BGP_64700.192.168.1.1+61154
Announcement bits (2): 0-KRT 3-Resolve tree 1
AS path: I (Originator) Cluster list: 1.1.1.1 2.2.2.2
AS path: Originator ID: 192.168.2.2
Accepted
Localpref: 100
Router ID: 192.168.1.1
Question: What is the cluster list value for this

route?
Answer: The answer varies depending on your

assigned device. In the previous output, the cluster
list value is: 1.1.1.1 2.2.2.2
Question: What does this cluster list value tell you

about the route?
Answer: The cluster list value acts much like the AS

path attribute in that it tells you which clusters the
route has transited. In the previous output, the
route first transited cluster 2.2.2.2, followed by
cluster 1.1.1.1. Your output might vary depending
on your assigned student device.
Part 4: Adding a New Router to the Network
Use the lab diagram titled “Lab 10: BGP Route Reflection—Part 4” for the remainder
of this lab.
In this lab part, both teams add a new virtual router to the network. Refer to the lab
diagram for your locally attached C3 virtual router. Now that we have a working,
route-reflector setup, adding a new router is quickly and easily accomplished.
Your local C3 router has been partially configured for you. On your assigned student
device, you first add the necessary configuration to bring up the new router in OSPF.
Next, you add this new router to your route-reflector cluster. Finally, you configure
BGP on the C3 virtual router and verify it is receiving routes from the other virtual
routers.
Step 4.1
Navigate to the [edit protocols ospf area 0.0.0.0] hierarchy. Add the
ge-0/0/14.3 interface to Area 0 with the interface-type p2p option. When
complete, issue the commit command to activate your changes.
lab@srxA-1# top edit protocols ospf area 0

lab@srxA-1# set interface ge-0/0/14.3 interface-type p2p

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 4.2
Issue the run show ospf neighbor interface ge-0/0/14.3 command
to verify OSPF is working correctly on the new interface.
lab@srxA-1# run show ospf neighbor interface ge-0/0/14.3
172.20.5.2 ge-0/0/14.3 Full 192.168.1.4 128 38
Question: Did the interface transition to a Full

state?
Answer: Yes. As shown in the previous output,

ge-0/0/14.3 is in a Full state. If it did not
transition to a Full state, check your configuration
and, if necessary, contact your instructor for help.
Step 4.3
Verify IGP connectivity by issuing the
run ping local-C3-loopback-address rapid command.
lab@srxA-1# run ping local-C3-loopback-address rapid
PING 192.168.1.4 (192.168.1.4): 56 data bytes
!!!!!
Question: Was the ping successful?
Answer: Yes. As shown in the previous output, the

ping was successful. If it was not successful, check
your configuration and, if necessary, contact your
instructor for help.
Step 4.4
Navigate to the [edit protocols bgp group rr-cluster] hierarchy. Add
your local C3 router’s loopback address as a neighbor in the rr-cluster group.
lab@srxA-1# top edit protocols bgp group rr-cluster


lab@srxA-1#
Step 4.5
Navigate to the [edit routing-instances C3 routing-options]
hierarchy. Configure the AS number as shown on your lab diagram.
lab@srxA-1# top edit routing-instances C3 routing-options
[edit routing-instances C3 routing-options]

lab@srxA-1# set autonomous-system 64700

lab@srxA-1#
Step 4.6
Create an IBGP group named my-int-group. This group should contain a single
neighbor of your locally attached route reflector’s loopback address. A policy named
static-to-bgp has been preconfigured for you. Export this policy in your
my-int-group. Also, do not forget the type and local-address statements.
lab@srxA-1# up 1 edit protocols bgp


lab@srxA-1# set group my-int-group local-address local-C3-loopback-address

lab@srxA-1# set group my-int-group neighbor local-RR-loopback-address

lab@srxA-1# set group my-int-group export static-to-bgp

lab@srxA-1# show
type internal;
neighbor 192.168.1.1;
}

lab@srxA-1# commit
commit complete

lab@srxA-1#

Step 4.7
Issue the run show bgp summary instance C3 command to verify your new
IBGP peering session is established.
C3.mdt.0 0 0 0 0 0 0
C3.inet.0 5 5 0 0 0 0
192.168.1.1 64700 34 31 0 0 12:47 Establ
C3.inet.0: 5/5/5/0
Note
previous step.
Step 4.8
Issue the run show route 200.200/16 table C3.inet.0 command to
verify your C3 router is receiving routes from the other virtual routers in the network.


AS path: I
> to 172.20.5.1 via ge-0/0/15.3
AS path: I
> to 172.20.5.1 via ge-0/0/15.3
AS path: I
> to 172.20.5.1 via ge-0/0/15.3
AS path: I
> to 172.20.5.1 via ge-0/0/15.3
200.200.5.0/24 *[Static/5] 14:34:35
Reject
AS path: I
> to 172.20.5.1 via ge-0/0/15.3

Question: How many routes are in the C3 router’s
table?
Answer: As shown in the previous output, six routes

should be present in the C3 router’s table. This
demonstrates that all of the virtual routers’ routes
are being propagated throughout the network.
Step 4.9
Navigate to the top hierarchy level and issue the
load override /var/home/lab/ajer/reset.config command to load
the reset configuration file. Commit the changes, return to operational mode, and
then log out of your assigned device.
lab@srxA-1# top
[edit]
load complete
[edit]
commit complete
lab@srxA-1> exit
srxA-1 (ttyu0)
login:

Advanced Junos Enterprise
Routing
Appendix A: Lab Diagrams

A–2 • Lab Diagrams www.juniper.net

www.juniper.net Lab Diagrams • A–3


































AJER 11.a LGD

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

AJER 11.a LGD

Загружено:

Авторское право:

Доступные форматы

Advanced Junos Enterprise

Detailed Lab Guide

Worldwide Education Services

1194 North Mathilda Avenue

Course Number: EDU-JUN-AJER

Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization

Lab 4: Implementing BGP (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Lab 5: BGP Attributes (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Lab 6: Implementing Enterprise Routing Policies (Detailed) . . . . . . . . . . . . . . . . . . 6-1

Lab 7: Implementing PIM-SM (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

www.juniper.net Contents • iii

Lab 9: Implementing CoS Features in the Enterprise (Detailed) . . . . . . . . . . . . . . . 9-1

Lab 10: BGP Route Reflection (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Appendix A: Lab Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

www.juniper.net Course Overview • v

vi • Course Overview www.juniper.net

www.juniper.net Course Agenda • vii

CLI and GUI Text

Style Description Usage Example

Courier New Console text:

Input Text Versus Output Text

Style Description Usage Example

Normal CLI No distinguishing variant. Physical interface:fxp0,

Defined and Undefined Syntax Variables

Style Description Usage Example

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

viii • Document Conventions www.juniper.net

Education Services Offerings

www.juniper.net Additional Information • ix

www.juniper.net Configuring and Monitoring OSPF (Detailed) • Lab 1–1

Part 1: Configuring and Monitoring OSPF

Question: What is the management address

Answer: The answer varies. The sample hostname

Lab 1–2 • Configuring and Monitoring OSPF (Detailed) www.juniper.net

--- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC

[edit protocols ospf]

[edit protocols ospf]

www.juniper.net Configuring and Monitoring OSPF (Detailed) • Lab 1–3

[edit protocols ospf]

[edit protocols ospf]

Question: Which neighbor states are shown for the

Answer: The neighbor state for the ge-0/0/1.0

Question: Why did the ge-0/0/1.0 interface form its

Answer: Adding the interface-type p2p

Lab 1–4 • Configuring and Monitoring OSPF (Detailed) www.juniper.net

Question: What are the states of the two ethernet

Answer: The ge-0/0/1.0 interface has a state of

Question: How many OSPF neighbors exist and what

Answer: You should eventually see two OSPF

www.juniper.net Configuring and Monitoring OSPF (Detailed) • Lab 1–5

STOP Do not proceed until the remote team finishes Part 1.

Part 2: Configuring OSPF Cost

Prefix Path Route NH Metric NextHop Nexthop

Question: What is the current metric associated

Answer: With the exception of the OSPF route for

Lab 1–6 • Configuring and Monitoring OSPF (Detailed) www.juniper.net

Answer: The two entries with the same prefix

[edit protocols ospf]

[edit protocols ospf]

Prefix Path Route NH Metric NextHop Nexthop

Question: What is the current metric associated

Answer: The metric for the referenced prefix should

www.juniper.net Configuring and Monitoring OSPF (Detailed) • Lab 1–7