PDF

Advanced Junos Enterprise
Routing
11.a
High-Level 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 High-Level Lab Guide, Revision 11.a
Copyright 2012 Juniper Networks, Inc. All rights reserved.
Printed in USA.
Revision History:
Revision 10.aMarch 2011.
Revision 11.aApril 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Part 1: Configuring and Monitoring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Part 2: Configuring OSPF Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Part 3: Configuring OSPF Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Lab 2:
Configuring and Monitoring OSPF Areas and Route Summarization . . . . . . 2-1

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

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

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

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

Part 1: Loading the Baseline Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 2: Configuring IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 3: Configuring PIM-SM with Static RP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 4: Configuring PIM-SM with the BSR mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lab 8:
5-2
5-2
5-3
5-4
5-5
5-7
5-8
7-2
7-4
7-6
7-8
Implementing SSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Part 1: Disabling the Use of RPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Part 2: Configuring IGMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Part 3: Viewing PIM-SM SSM Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5
Part 4: Configuring an ssm-map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6
www.juniper.net
Contents iii
Lab 9:
Implementing CoS Features in the Enterprise . . . . . . . . . . . . . . . . . . . . . . . 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-4
Part 4: Configuring and Testing Schedulers and Drop Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5
Part 5: Configuring and Testing a Rewrite Marker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8
Lab 10: BGP Route Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Part 1: Loading the Initial Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2
Part 2: Verifying Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2
Part 3: Converting to Route Reflectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3
Part 4: Adding a New Router to the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6
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:
www.juniper.net
Describe the various OSPF link-state advertisement (LSA) types.
Explain the flooding of LSAs in an OSPF network.
Describe the shortest-path-first (SPF) algorithm.
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.

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:
Screen captures
commit complete
Noncommand-related
syntax
Exiting configuration mode
GUI text elements:

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

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

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

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

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

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

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

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

The Advanced Junos Enterprise Routing High-Level 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
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:
www.juniper.net
Configure a multiarea OSPF network.
Configure link costs and reference-bandwidth.
Overload a router.
Configure and troubleshoot OSPF authentication.
Configuring and Monitoring OSPF Lab 11

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?
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:
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.
Lab 12 Configuring and Monitoring OSPF
www.juniper.net
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.
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.
Step 1.6
Activate the configuration and quickly issue the run show ospf neighbor
command.
Question: Which neighbor states are shown for the
listed interfaces and why?
Question: Why did the ge-0/0/1.0 interface form its

adjacency more quickly than the ge-0/0/2.0
interface?
Step 1.7
Issue the run show ospf interface command to view the interface states.
Question: What are the states of the two ethernet
interfaces and what do they mean?
Step 1.8
Issue the run show ospf neighbor command again to verify the current OSPF
adjacency details.
Question: How many OSPF neighbors exist and what
are the states of those adjacencies?
www.juniper.net
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.
Question: What is the current metric associated
with the displayed OSPF routes?
Question: Why does the output show two entries

with the same prefix?
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.
Question: What is the current metric associated
with the 172.20.66.0/30 OSPF route?
Question: What was the effect of the increased

metric on the route associated with the remote
student devices loopback address?
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.
www.juniper.net
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.
Question: What was the effect of setting the
reference-bandwidth to 10g?
Question: Why did the metric associated with

ge-0/0/2.0 remain unchanged?
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.
Step 2.6
Issue the run show ospf neighbor command to verify the current OSPF
adjacency details.
Question: How many OSPF neighbors exist and what
are the states of those adjacencies?
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.
Question: Was the ping to your attached virtual
router successful?
Note
Before proceeding, ensure that the remote

team in your pod finishes the previous step.
www.juniper.net

Note
The next two lab steps require you to log in

to the virtual router attached to your teams
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.
Step 2.9
From the second CLI session to your student device, telnet to your virtual routers
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
www.juniper.net
Step 2.10
Verify reachability back to your student devices 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
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 teams
virtual routers loopback address. Use the table from the previous step for the
instance name.
Question: What is the OSPF cost to reach the
remote virtual routers loopback address?
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.
www.juniper.net
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.
Question: Did the metric change? If so, what did it
change to and why?
Question: Why would you overload a router?
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.
Step 2.15
On the SRX Series student device, delete the overload setting and activate your
changes.
STOP
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 devices current configuration to make it
incompatible with team 2s 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 1s 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.
Step 3.2
This step is for both teams.
Issue a run show ospf neighbor command.
www.juniper.net
Question: How many OSPF neighbors does your

assigned device currently have?
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.
Step 3.4
Issue the run show log trace-ospf command to view the contents written to
the trace-ospf trace file.
Question: Does the generated error in the trace file
explain the current OSPF adjacency issue?
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.
Step 3.6
Issue a run show ospf neighbor command.
Question: Did the OSPF adjacency across the
ge-0/0/1.0 interface return to the Full state?
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.
Step 3.8
Log out of your assigned device using the exit command.
www.juniper.net
STOP
Tell your instructor that you have completed Lab 1.
www.juniper.net
Lab 2
Configuring and Monitoring OSPF Areas and Route
Summarization
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.
www.juniper.net
Create a stub area.
Change the stub area to a totally stubby area.
Create a not-so-stubby area.
Perform route summarization.
Configuring and Monitoring OSPF Areas and Route Summarization Lab 21

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
Step 1.3
load override /var/home/lab/ajer/lab2-start.config command.
After the configuration has been loaded, commit the changes before proceeding.
Lab 22 Configuring and Monitoring OSPF Areas and Route Summarization
www.juniper.net
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.
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 .
Step 1.6
Activate the configuration and issue the run show ospf neighbor command.
Question: Did the new neighbor come up to a Full
state?
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.
Question: Is the new interface correctly set as
Stub?
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.
Question: How many summary LSAs are in your stub
area?
Step 1.9
Convert your stub area to a totally stubby area using the no-summaries option
and activate your changes.
Step 1.10
ospf database area area commands again.
www.juniper.net
Question: How many summary LSAs are now in your

stub area?
Question: Why are there no summary LSAs?
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.
Step 1.12
ospf database area area commands again.
Question: How many summary LSAs are now in your
stub area?
STOP
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.
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.
Step 2.3
Activate the configuration and issue the run show ospf neighbor command.
www.juniper.net
Question: Did the new neighbor come up to a full

state?
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.
Question: Is the new interface correctly set as an
NSSA interface?
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.
Question: How many NSSA LSAs are in your NSSA
areas database?
Step 2.6
Issue the run show ospf database external command to see external
LSAs contained in the OSPF database.
Question: Are the external LSAs that describe the
remote teams NSSA routes present?
Question: How many external LSAs are present?
www.juniper.net
Step 2.7
Each of the external NSSA destinations is represented by a /24 network. Choose
one of the remote teams destinations and issue a run show route
destination command for that destination.
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.
Note

Step 2.9
Issue the show ospf database external command to view the external LSAs
present in the OSPF database.
Question: Were the changes successful? How can
you tell?
Step 2.10
Choose one of the remote teams 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.
Step 2.11
STOP
www.juniper.net
Lab 3
Configuring and Monitoring Routing Policy and Advanced
OSPF Options
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).
www.juniper.net
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.
Configuring and Monitoring Routing Policy and Advanced OSPF Options Lab 31
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
Step 1.3
Lab 32 Configuring and Monitoring Routing Policy and Advanced OSPF Options
www.juniper.net
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.
Step 1.5
Use the run show ospf interface command to verify which interfaces are
participating in OSPF.
Question: How many interfaces are running OSPF?
Step 1.6
Use the run show ospf neighbor command to verify the establishment of the
OSPF adjacencies.
Question: Are all OSPF adjacencies established and
in the Full state?
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.
Question: Is there an entry in the primary routing
table (inet.0) for all six loopback addresses
within the OSPF domain?
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
partners 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.
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.
www.juniper.net
Question: Which type of 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.
Question: What is the adjacency state of the virtual
link interface?
Step 1.11
Use the run show route address/32 table inet.0 command to verify
that your partners default loopback address routes through the P1 router and not
through the virtual link. Refer to the network diagram as needed.
Question: Does the route to your partners loopback
address go through the P1 router or 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.
Step 2.2
Use the run show ospf interface command to verify the multiarea
adjacency.
www.juniper.net
Question: Area 10 now has two interfaces in it.

What is the state for the interface you just added to
Area 10? Why?
Step 2.3
Use the run show ospf neighbor command to verify the establishment of an
OSPF Area 10 adjacency through the P1 router.
Question: How many OSPF adjacencies exist for
Area 0.0.0.10?
Step 2.4
Verify that the loopback address of your partners 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.
Question: What is the primary path to your partners
virtual routers loopback address?
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 routers Area 10 interface connected to the P3 router. Commit the
configuration when completed.
Step 2.6
Issue the run show route address/32 table inet.0 command again to
verify the route to your partners remote virtual routers loopback address has
converged through the P1 router, thus using the multiarea adjacency.
Question: Did the route converge through the
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.
www.juniper.net
Step 2.8
Verify that OSPF converged back to the primary path by displaying your partners
loopback address using the run show route address/32 table inet.0
command.
Question: Did the route converge back to your R3
virtual router?
STOP
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.
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.
Question: How many routes are you receiving from
the P3 RIP router?
www.juniper.net
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.
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.
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.
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.
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.
Question: Is the default route being advertised to
R3?
www.juniper.net
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

Question: What is the active protocol for the default
route?
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.
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

Question: Is the route now being advertised to the
RIP network?
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.
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.
www.juniper.net
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.
Question: Is the RIP import policy 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.
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
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
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

www.juniper.net
Question: What could be causing the suboptimal

path to the RIP network?
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.
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?
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.
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.
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.
Question: Is the OSPF import policy working?
Step 3.22
STOP
www.juniper.net
Lab 4
Implementing BGP
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
www.juniper.net
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.
Implementing BGP Lab 41

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 BGPPart 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
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.
Lab 42 Implementing BGP
www.juniper.net
Question: Were all of the interface IP addresses

reachable?
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.
Question: Are the adjacencies established between
your router and the two neighboring routers?
Part 2: Configuring IBGP

In this lab part, you use the lab diagram called Lab 4: Implementing BGP
Parts 24 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.
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.
Question: Was the commit operation successful?
www.juniper.net

Note

student team in your pod finishes the
previous step.
Step 2.3
Issue the run show bgp summary command to view the current BGP summary
information for your device.
Question: How many BGP neighbors does your
device currently list?
Question: Has your device received any routes from

its IBGP peers?
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.
Question: From which IBGP peers are you currently
receiving routes?
Question: What is the AS path associated with the

received BGP routes?
Question: What is the local preference of the

received BGP routes?
www.juniper.net
Question: Which routing table group does the

referenced command consult? Which operational
mode command displays BGP routes in the routing
table (RIB-Local)?
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.
Question: Which routing table group does the

command referenced in this step consult?
Question: Is your student device currently

advertising BGP routes to any of its IBGP peers?
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.
Note
Before proceeding, ensure the remote

student team in your pod has finished the
previous step.
STOP
www.juniper.net
Do not proceed until the remote team finishes the previous step.
Step 3.2
information.
Question: How many BGP groups and peers does
your device currently list?
Question: Has your device received routes from

both EBGP peers?
Question: Are all of the routes received from the two

EBGP peers 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.
Question: Are the EBGP peers sending the exact
same routes to your router or are they sending
different 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?
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.
www.juniper.net
Question: What did the router use as the reason for

not choosing one of the routes to be active?
Question: What is the next hop of the active route?
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?
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.
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.
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.
www.juniper.net
Question: Is your device now advertising the BGP

routes received from its 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.
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.
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.
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.
Question: Is your device advertising all of the
expected aggregate prefixes?
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 routers 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.
www.juniper.net
Question: Again, are the same routes being

received from both 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.
Question: How many advertisements have been
received for this route? Where did they come from?
Question: How many next hops are associated with

the active route (denoted by a *)? Why?
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
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.
Question: How many next hops does the active
route now have installed?
Step 4.5
Use the run show route forwarding-table destination
172.28.102.0/24 command to view the packet forwarding table.
Question: Are the two routes to the EBGP peers
installed in the packet forwarding table?
www.juniper.net
Step 4.6
pfe-load-balance] hierarchy. Under the pfe-load-balance policy, create a
term that only load-balances all BGP routes.
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.
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.
Question: Is the forwarding table using both
next-hop interfaces to reach the 172.28.102.0/24
route?
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 BGPPart 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.
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.
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.
Question: Is the ping successful?
www.juniper.net
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 routers loopback address as the
local-address. Commit your configuration when complete.
Step 5.5
Check the state of the EBGP session using the run show bgp summary
command.
Question: What is the state of the EBGP peering
session? Why?
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.
Step 5.7
Check the status of the EBGP session with the run show bgp summary
command.
Question: What is the state of the EBGP peering
session after the multihop command is
configured?
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.
Question: Are routes being received from the EBGP
peering session?
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.
www.juniper.net
Question: How many next hops does the active

route have installed?
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.
Question: Is the forwarding table using both
next-hop interfaces to reach the 172.28.102.0/24
route? Why or why not?
Step 5.11
Exit configuration mode and log out of your assigned device using the exit
command.
STOP
www.juniper.net
Lab 5
BGP Attributes
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.
www.juniper.net
Configure export and import policy.
Configure and apply a next-hop self policy.
Manipulate BGP path attributes to influence traffic flow.
BGP Attributes Lab 51

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
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.
Lab 52 BGP Attributes
www.juniper.net
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.
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.
Note

previous step.
Step 2.4
information for your device.
Question: How many BGP routes are you receiving
from your EBGP neighbor?
STOP
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.
Note
The output will differ depending on the

device you are using.
Question: Why are these routes hidden?
www.juniper.net
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.
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.
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.
Question: How many hidden routes are there?
STOP
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.
Question: What does the () aspath-regex value
match?
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.
www.juniper.net
Question: How many routes are advertised to your

external peer?
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.
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.
Question: What is the default terminating action for
a routing policy in BGP?
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.
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.
Question: lHow many routes are you now sending
to your EBGP peer?
STOP
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.
www.juniper.net

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.
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.
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.
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.
www.juniper.net

Note
The output might differ slightly depending

on which device is used.
Question: Is the prepend AS path policy working as
expected?
Question: Is the manipulation of the origin attribute

working as expected?
Step 5.5
Log out of the vr-device.
STOP
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.
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.
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.
www.juniper.net
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.
Question: Are the peers local routes getting the
right local preference based on the policy applied in
the previous steps?
STOP
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.
Step 7.2
For verification, issue a run show route protocol aggregate command
and ensure the aggregate routes were created.
Question: What is the requirement for an aggregate
route to become active?
Step 7.3
Navigate to the [edit policy-options] configuration hierarchy. Create a
community named no-export containing the well-known no-export community.
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.
www.juniper.net
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.
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.
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.
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.
www.juniper.net
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).
Question: Why does the number of routes
advertised from AS 64700 (6) differ from the
amount of routes ISP Y receives (two)?
Step 7.10
Log out of the vr-device using the exit command.
Step 7.11
STOP
www.juniper.net
Lab 6
Implementing Enterprise Routing Policies
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.
www.juniper.net
The use of private autonomous systems (ASs) to segregate the network.
Configuration of the common routing policies for external connectivity.
Implementing Enterprise Routing Policies Lab 61

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
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.
Lab 62 Implementing Enterprise Routing Policies
www.juniper.net
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.
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
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
Note

previous step.
Step 2.5
Issue the run show bgp summary command to view the current BGP peering
status for your device.
Question: How many BGP routes are you receiving
from your ISP neighbor?
Question: Which type of external routing policy is

this policy?
STOP
www.juniper.net
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.
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.
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.
Step 3.4
Within the primary-secondary policy, create a third term named reject with
an action of reject.
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.
Step 3.6
For verification, issue the run show route 0/0 exact command.
Note
The output will differ depending on the

device to which you are assigned.
www.juniper.net

Note

previous step.
Question: What is the local-preference value of the
default route?
Question: Which path does the enterprise prefer

now 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
(6451265535).
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
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
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.
Question: Which routes are you advertising to the
external ISP peers?
www.juniper.net
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.
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.
Question: Is the private AS value removed from the
advertisements?
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,
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.
Question: Why does AS prepending help the strict
primary/secondary network design?
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.
www.juniper.net
STOP
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.
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.
Question: What is the next hop for routes in
AS 813?
Question: How does this configuration accomplish a

loose primary/secondary design?
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.
www.juniper.net
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.
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.
Question: How many routes are 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.
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.
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.
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.
www.juniper.net

Note
The following captures show the outputs

from both student devices.
Question: How many routes are active from your
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.
STOP
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.
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.
Step 7.3
For verification, issue the command run show route protocol aggregate
to confirm that the aggregate routes have become active.
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.
www.juniper.net
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.
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.
Question: How does this lab part accomplish a
load-shared design?
Question: Why is announcing a less specific

aggregate important in this design?
Step 7.7
Exit configuration mode and log out of your assigned device using the exit
command.
STOP
www.juniper.net
Lab 7
Implementing PIM-SM
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.
www.juniper.net
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.
Implementing PIM-SM Lab 71

11.a.11.4R1.6
Part 1: Loading the Baseline Topology

In this lab part, you configure your student devices interfaces according to the lab
diagram labeled Lab 7: Implementing PIM-SMParts 13. 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.
Step 1.4
Use the show configuration interfaces command to determine which
interfaces have been preconfigured for you.
Lab 72 Implementing PIM-SM
www.juniper.net
Question: Have any interfaces been preconfigured?

If so, which interfaces have been preconfigured?
Step 1.5
Use the show configuration protocols command to determine which
protocols have been preconfigured for you.
Question: Have any protocols been preconfigured?
If so, which protocols have been preconfigured?
Step 1.6
Verify that each interface has been configured properly by attempting to ping each of
the locally attached routers and hosts.
Question: Were all of the locally attached routers
and hosts reachable?
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.
Question: Are the adjacencies established between
your router and the two neighboring routers?
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 devices routing table.
Question: Does the route to the source exist? How
was it learned?
www.juniper.net
STOP
Part 2: Configuring IGMP

In this lab part, you configure your student devices 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 devices ge-0/0/8 interface to use IGMP version 2
(IGMPv2).
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.
Step 2.3
Issue the run show igmp interface command to determine which interfaces
are enabled for IGMP.
Question: Has the ge-0/0/8 interface been properly
enabled for IGMP?
Question: Which router has been elected querier for

the Ethernet segment?
Question: Which version of IGMP has been

enabled?
Question: How many groups have been learned by

your student device through the ge-0/0/8
interface?
www.juniper.net
Step 2.4
Issue the run show igmp group command to determine the groups that have
been learned from IGMP.
Question: Have any groups been learned on your
assigned device?
Step 2.5
From your assigned device, log in to the attached receiver using SSH, a username of
lab, and a password of lab123.
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?
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.
Step 2.9
Use the run show igmp group command to verify that your device is receiving
IGMP reports from the locally attached receiver.
www.juniper.net
Question: Is your router receiving IGMP reports for

any new groups? Which groups?
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 routers interfaces to run PIM-SM. Do not forget the loopback interface.
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?
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.
www.juniper.net
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
Step 3.5
Verify that the correct interfaces have been configured for PIM-SM by issuing the
run show pim interfaces command.
Question: Do all of the interfaces that you
configured for PIM-SM appear in the output of the
command?
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?
Step 3.6
Verify that the correct RP has been configured on your router by issuing the run
show pim rps command.
Question: Is your router aware of any active RPs?
Question: Are there any active groups that your

router is associating with the RP? If so, why?
Step 3.7
Issue the run show pim join extensive command to determine the (S,G)
and (*,G) states of your router.
Question: How many states are associated with your
multicast group? Why?
www.juniper.net
Question: What are the upstream interfaces

associated each state? Are they correct?
Question: What are the downstream interfaces

Step 3.8
Verify that multicast traffic is being forwarded by your router by issuing the run
show multicast route extensive command.
Question: Is multicast traffic being forwarded by
your router? If so, at what rate is being forwarded?
STOP
Part 4: Configuring PIM-SM with the BSR mechanism

In this lab part, you use the Lab 7: Implementing PIM-SMPart 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.
Step 4.2
From your assigned device, log in to the attached receiver using SSH, a username of
lab, and a password of lab123.
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:
www.juniper.net
[lab@CoS1 ~]$ ps -ef | grep rtpqual

lab
3286
1 0 05:35 ?
lab
3569 3536 0 07:49 pts/2
00:00:02 ./rtpqual 224.7.7.125 1111 rtp

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?
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.
Step 4.8
Using the show igmp group command, verify that your device is receiving IGMP
reports from the locally attached receiver.
any new groups? If so, for which groups?
www.juniper.net
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?
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 steps
table. Also, configure the BSR priority to a value of 50. Commit your configuration
and exit to operational mode.
Question: Why do you think that there is no need to
add any RP-related configuration to the non-RP and
non-BSR routers?
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.
Question: Has a BSR been elected in the network?
www.juniper.net
Question: What is the IP address of the BSR? Is this

expected?
Step 4.12
Verify that the correct RP has been configured on your router by issuing the show
pim rps command.
Question: Is your router aware of any active RPs?
Step 4.13
Use the show pim join extensive command to determine the (S,G) and
(*,G) states of your router.
Question: How many states are associated with your
multicast group? Why?
Question: What are the upstream interfaces

Question: What are the downstream interfaces

Step 4.14
Verify that multicast traffic is being forwarded by your router by issuing the show
multicast route extensive command.
your router? If so, at which rate is it being
forwarded?
www.juniper.net
Step 4.15
Log out of your assigned device using the exit command when complete.
STOP
www.juniper.net
Lab 8
Implementing SSM
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.
www.juniper.net
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.
Implementing SSM Lab 81

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.
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
lab@10.1.1.2's password:
Last login: Fri Mar 8 07:48:07 2011 from 10.1.1.1
[lab@CoS1 ~]$
Lab 82 Implementing SSM
www.juniper.net
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 ?
lab
3714 3683 0 08:47 pts/0
00:00:16 ./rtpqual 224.7.7.126 1111 rtp

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
Connection to 10.1.1.2 closed.
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.
Part 2: Configuring IGMPv3

In this lab part, you configure your student devices 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 devices ge-0/0/8 interface to use IGMPv3. Commit your
configuration and exit to operational mode when complete.
Step 2.2
Issue the show igmp interface command to determine which interfaces are
enabled for IGMP.
www.juniper.net
Question: Has the ge-0/0/8 interface been properly

enabled for IGMPv3?
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@10.1.1.2's password:
Last login: Fri Mar 18 07:48:07 2011 from 10.1.1.1
[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
www.juniper.net
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
Connection to 10.1.1.2 closed.
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.
all three of the new groups?
Question: Is this the expected behavior? What could

be a possible reason for this behavior?
Step 2.8
Issue the show igmp statistics command and determine whether any
IGMPv3 report errors have been logged.
Question: Has your router noticed any IGMP report
errors? Why or why not?
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 receivers 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 receivers DR.
www.juniper.net
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?
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.
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.
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.
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.
Question: Is your router accepting the IGMP reports
for 232.22z.2.2?
www.juniper.net
Question: What is the source associated with the

224.22z.1.1 and 232.22z.2.2 groups? Why?
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.
Question: Have PIM Join messages been sent
upstream toward the source for each of the three
multicast groups? Is this 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.
your router for all three groups?
Step 4.7
Log out of your assigned device using the exit command when complete.
STOP
www.juniper.net
www.juniper.net
Lab 9
Implementing CoS Features in the Enterprise
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.
www.juniper.net
Configure multifield and behavior aggregate classifiers.
Configure a policer for different traffic classes.
Create drop profiles.
Configure packet marking.
Implementing CoS Features in the Enterprise Lab 91

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 labs 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
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.
Lab 92 Implementing CoS Features in the Enterprise
www.juniper.net
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.
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.
Question: How many queues are supported on the
SRX Series device?
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.
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.
Question: What is the purpose of the DSCP class
selector (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.
www.juniper.net
Step 2.6
Issue the run clear interfaces statistics all command to clear the
statistics for all interfaces.
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 teams 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.
Step 2.8
On the CoS host, ping the other teams 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 teams assigned host number.
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.
Question: Are there any packets in the data and
expedited-forwarding queues?
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.
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.
www.juniper.net
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.
Step 3.4
Create a policer named voice-overflow. Set the policers 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.
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.
Step 3.6
Insert the new voip-limit term before the term scp in the MF-class filter.
Question: Why is it important to rate-limit
high-priority traffic on an SRX Series device?
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.
www.juniper.net
Name
Criteria
be
ef
af
nc
data
transmit-rate percent 20
priority low
drop-profile-map loss-priority high

protocol any drop-profile aggressive
priority high
buffer-size percent 20
transmit-rate percent 20 exact
priority medium-high
priority low
priority medium-high
Question: What is the meaning of the exact option

after the 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
aggressive
Criteria
fill-level 30 drop-probability 40
fill-level 80 drop-probability 60
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:
www.juniper.net
Scheduler-Map
my-sched-map
Mappings
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

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.
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.
Question: How many drops are 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.
www.juniper.net
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.
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.
Question: How many drops do you see in the
expedited-forwarding queue now?
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.
Question: How many high-priority random early
detection (RED)-dropped packets does the router
display?
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.
Step 5.2
In the dscp-rewrite rewrite rule, configure forwarding-class best-effort with
loss-priority low to have a marking of 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,
www.juniper.net
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.
Step 5.5
On the SRX Series device, ping the other teams 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
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.
Question: Is the rewrite configuration working
properly?
Step 5.7
Using the exit command, log out of the CoS host and then log out of your second
SRX Series CLI session.
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.
www.juniper.net
STOP
www.juniper.net
Lab 10
BGP Route Reflection
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 ReflectionParts 12,
Lab 10: BGP Route ReflectionPart 3, and Lab 10: BGP Route ReflectionPart 4 to
configure and monitor BGP route reflection.
www.juniper.net
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.
BGP Route Reflection Lab 101

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 12.
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
Part 2: Verifying Topology

In this lab part, you verify router-to-router connectivity and BGP operations using the
command-line interface (CLI).
Lab 102 BGP Route Reflection
www.juniper.net

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 partners student
device. The remaining two adjacencies are to each of your virtual routers (C1 and
C2).
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.
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.
Question: How many routes are in each table?
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 ReflectionPart 3 for this section.
www.juniper.net
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.
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 neighborthe other route reflectors loopback address. Do not
forget the type and local-address statements.
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.
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.
Step 3.5
Within the my-int-group group, delete all neighbors except for the locally
attached route-reflector loopback address.
Step 3.6
Issue the show command to view the current BGP configuration for the C2 virtual
router.
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.
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.
www.juniper.net
Question: Are the 200.200/16 routes being

propagated throughout the network? Why or why
not?
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.
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.
Question: Are the 200.200/16 routes 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.
Question: What do you notice about the AS path
information?
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.
Question: What is the cluster list value for this
route?
www.juniper.net
Question: What does this cluster list value tell you

about the route?
Part 4: Adding a New Router to the Network

Use the lab diagram titled Lab 10: BGP Route ReflectionPart 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.
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.
Question: Did the interface transition to a Full
state?
Step 4.3
Verify IGP connectivity by issuing the
run ping local-C3-loopback-address rapid command.
Question: Was the ping successful?
Step 4.4
Navigate to the [edit protocols bgp group rr-cluster] hierarchy. Add
your local C3 routers loopback address as a neighbor in the rr-cluster group.
Step 4.5
Navigate to the [edit routing-instances C3 routing-options]
hierarchy. Configure the AS number as shown on your lab diagram.
www.juniper.net
Step 4.6
Create an IBGP group named my-int-group. This group should contain a single
neighbor of your locally attached route reflectors 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.
Step 4.7
Issue the run show bgp summary instance C3 command to verify your new
IBGP peering session is established.
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.
Question: How many routes are in the C3 routers
table?
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.
STOP
www.juniper.net
www.juniper.net
Advanced Junos Enterprise

Routing
Appendix A: Lab Diagrams
A2 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A3
A4 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A5
A6 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A7
A8 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A9
A10 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A11
A12 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A13
A14 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A15
A16 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A17
A18 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A19
A20 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A21
A22 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A23
A24 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A25
A26 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A27
A28 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A29
A30 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A31
A32 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A33
A34 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A35
A36 Lab Diagrams
www.juniper.net

PDF

Загружено:

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

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

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

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

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

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

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

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

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

PDF

Загружено:

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

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

Advanced Junos Enterprise

High-Level Lab Guide

Worldwide Education Services

This document is produced by Juniper Networks, Inc.

Configuring and Monitoring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Configuring and Monitoring OSPF Areas and Route Summarization . . . . . . 2-1

Implementing BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

BGP Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Implementing Enterprise Routing Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Implementing PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Implementing SSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Implementing CoS Features in the Enterprise . . . . . . . . . . . . . . . . . . . . . . . 9-1

Lab 10: BGP Route Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Appendix A: Lab Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

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

Explain the flooding of LSAs in an OSPF network.

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

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.

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.

Manipulate BGP attributes using routing policy.

Describe common routing policies used in the enterprise environment.

Explain how attribute modifications affect routing decisions.

Identify environments that may require a modified CoS implementation.

Describe the various CoS components and their respective functions.

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.

Configure and monitor IGMP.

Identify common multicast routing protocols.

Describe rendezvous point (RP) discovery options.

Configure and monitor Physical Interface Module (PIM) sparse modes.

Configure and monitor RP discovery mechanisms.

Describe the basic requirements, benefits, and caveats of source-specific multicast

List the address ranges used for SSM.

Configure and monitor SSM.

Enterprise Routing Policies

Course Agenda vii

Most of what you read in the Lab Guide

Exiting configuration mode

GUI text elements:

Select File > Open, and then click

Input Text Versus Output Text

View configuration history by clicking

Text that you must enter.

lab@San_Jose> show route

Defined and Undefined Syntax Variables

Text where variable value is already

Text where the variables value is

Type set policy policy-name.

viii Document Conventions

Click my-peers in the dialog.

About This Publication

Juniper Networks Support

Configure a multiarea OSPF network.

Configure link costs and reference-bandwidth.