JUNOS Intermediate Routing-11a-Lab Guide PDF

Junos Intermediate 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-JIR

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.
Junos Intermediate Routing High-Level Lab Guide, Revision 11.a
Copyright 2011, Juniper Networks, Inc.
All rights reserved. Printed in USA.
Revision History:
Revision 10.aMay 2010
Revision 10.bDecember 2010
Revision 11.aJune 2011
The information in this document is current as of the date listed above.
The information in this document has been carefully verified and is believed to be accurate for software Release 11.1R1.10. 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: Protocol-Independent Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Part 1: Configuring and Monitoring Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Part 2: Configuring and Monitoring Static and Aggregate Routes . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Part 3: Working with Routing Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Lab 2: Load Balancing and Filter-Based Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Part 1: Configuring and Monitoring Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Part 2: Configuring and Monitoring Filter-Based Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
Lab 3: Open Shortest Path First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Part 1: Configuring and Monitoring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Part 2: Performing Basic OSPF Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Lab 4: Border Gateway Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Part 1: Configuring and Monitoring IBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Part 2: Configuring and Monitoring EBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Part 3: Implementing a next-hop self Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Lab 5: IP Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Part 1: Configuring and Monitoring a GRE Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Part 2: Configuring the GRE Interface to Participate in OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Lab 6: High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Part 1: Configuring and Monitoring Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Part 2: Configuring and Monitoring BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
Part 3: Configuring and Monitoring VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
Lab 7: IPv6 (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Part 1: Configuring and Monitoring Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Part 2: Configuring and Monitoring Static Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4
Part 3: Configuring and Monitoring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
Part 4: Tunneling IPv6 over IPv4 Using GRE Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7
Lab 8: IS-IS (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Part 1: Configuring and Monitoring IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Part 2: Performing Basic IS-IS Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5
Appendix A: Lab Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Contents iii
iv Contents
Course Overview
This two-day course provides students with intermediate routing knowledge and configuration
examples. The course includes an overview of protocol-independent routing features, load
balancing and filter-based forwarding, OSPF, BGP, IP tunneling, and high availability (HA) features.
This course is based on Junos operating system Release 11.1R1.10.
Through demonstrations and hands-on labs, students will gain experience in configuring and
monitoring the Junos OS and monitoring device operations.
Objectives
After successfully completing this course, you should be able to:
Describe typical uses of static, aggregate, and generated routes.
Configure and monitor static, aggregate, and generated routes.
Explain the purpose of Martian routes and add new entries to the default list.
Describe typical uses of routing instances.
Configure and share routes between routing instances.
Describe load-balancing concepts and operations.
Implement and monitor Layer 3 load balancing.
Illustrate benefits of filter-based forwarding.
Configure and monitor filter-based forwarding.
Explain the operations of OSPF.
Describe the role of the designated router.
List and describe OSPF area types.
Configure, monitor, and troubleshoot OSPF.
Describe BGP and its basic operations.
Name and describe common BGP attributes.
List the steps in the BGP route selection algorithm.
Describe BGP peering options and the default route advertisement rules.
Configure and monitor BGP.
Describe IP tunneling concepts and applications.
Explain the basic operations of generic routing encapsulation (GRE) and IP over IP
(IP-IP) tunnels.
Configure and monitor GRE and IP-IP tunnels.
Describe various high availability features supported by the Junos OS.
Configure and monitor some of the highlighted high availability features.
Intended Audience
This course benefits individuals responsible for configuring and monitoring devices running the
Junos OS.
Course Level
Junos Intermediate Routing is an intermediate-level course.
www.juniper.net Course Overview v

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 attend the
Introduction to the Junos Operating System (IJOS) and Junos Routing Essentials (JRE) courses prior
to attending this class.
vi Course Overview www.juniper.net

Course Agenda
Day 1
Chapter 1: Course Introduction
Chapter 2: Protocol-Independent Routing
Lab 1: Protocol-Independent Routing
Chapter 3: Load Balancing and Filter-Based Forwarding
Lab 2: Load Balancing and Filter-Based Forwarding
Chapter 4: Open Shortest Path First
Lab 3: Open Shortest Path First
Day 2
Chapter 5: Border Gateway Protocol
Lab 4: Border Gateway Protocol
Chapter 6: IP Tunneling
Lab 5: IP Tunneling
Chapter 7: High Availability
Lab 6: High Availability
Appendix A: IPv6
Lab 7: IPv6 (Optional)
Appendix B: IS-IS
Lab 8: IS-IS (Optional)
Appendix C: RIP
www.juniper.net Course Agenda vii

Document Conventions
CLI and GUI Text

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

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

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

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

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

already assigned.
GUI Variable
Click my-peers in the dialog.
CLI Undefined Text where the variables value Type set policy policy-name.
is the users discretion and text
ping 10.0.x.y
where the variables value as
GUI Undefined shown in the lab guide might Select File > Save, and type
differ from the value the user filename in the Filename field.
must input.
viii Document Conventions www.juniper.net

Additional Information
Education Services Offerings

You can obtain information on the latest Education Services offerings, course dates, and class
locations from the World Wide Web by pointing your Web browser to:
http://www.juniper.net/training/education/.
About This Publication
The Junos Intermediate Routing High-Level Lab Guide was developed and tested using software
Release 11.1R1.10. 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
Protocol-Independent Routing
Overview
This lab demonstrates configuration and monitoring of protocol-independent features on
devices running the Junos operating system. In this lab, you use the command-line
interface (CLI) to configure and monitor interfaces, static and aggregate routes, and
routing instances.
The lab is available in two formats: a high-level format designed to make you think through
each step and a detailed format that offers step-by-step instructions complete with
sample output from most commands.
By completing this lab, you will perform the following tasks:
Configure and verify proper operation of network interfaces.
Configure and monitor static and aggregate routes.
Configure routing instances and share routes between them using routing
table groups.
www.juniper.net Protocol-Independent Routing Lab 11

11.a.11.1R1.10
Part 1: Configuring and Monitoring Interfaces
In this lab part, you configure network interfaces on your assigned device. You then
verify that the interfaces are operational and that the system adds the
corresponding routing table entries for the configured interfaces.
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 device you are assigned. Check with your instructor if
necessary. Consult the management network diagram, provided by your instructor,
to determine your devices management address.
Question: What is the management address

assigned to your station?
Step 1.2
Access the CLI at your station using either the console, Telnet, or SSH as directed by
your instructor. The following example shows simple Telnet access to srxD-1 using
the Secure CRT program.
Step 1.3
Log in as user lab with the password supplied by your instructor.
Step 1.4
Enter configuration mode and navigate to the [edit interfaces] hierarchy
level.
Lab 12 Protocol-Independent Routing www.juniper.net

Step 1.5
Variable references are used throughout the labs to distinguish various parts of CLI
input. Variable v is used for the vlan-id remainders as per the table in the lab
diagrams. Variable z is used to distinguish IP addresses on the local and remote
devices.
Refer to the network diagram and configure the interfaces for your assigned device.
Use the VLAN-ID as the logical unit value for the tagged interface. Use logical
unit 0 for all other interfaces. Remember to configure the loopback interface!
Step 1.6
Display the interface configuration and ensure that it matches the details outlined
on the network diagram for this lab. When you are comfortable with the interface
configuration, issue the commit-and-quit command to activate the
configuration and return to operational mode.
Step 1.7
Issue the show interfaces terse command to verify the current state of the
recently configured interfaces.
Question: What are the Admin and Link states for

the recently configured interfaces?
Step 1.8
Issue the show route command to view the current route entries.
Question: Does the routing table display an entry for

all local interface addresses and directly connected
networks?
Question: What are the route preferences for the

Local and Direct route entries?
Question: Are any routes currently hidden?

Step 1.9
Use the ping utility to verify reachability to the neighboring devices connected to your
device. If necessary, check with the remote student team and your instructor to
ensure that their devices have the required configuration for the interfaces.
Note
Use Ctrl + c to stop a continuous ping
operation.
Question: Are the ping tests successful?
Part 2: Configuring and Monitoring Static and Aggregate Routes
In this lab part, you configure and monitor static and aggregate routes.
Step 2.1
Refer to the network diagram for this lab and answer the following question.
Question: Based on the network diagram, which IP

address does your device use as a next hop to
reach the Internet host?
Step 2.2
Enter configuration mode and define a default static route. Use the IP address
identified in the last step as the next hop for the default static route.
Step 2.3
Activate the newly added static route and issue the run show route
172.31.15.1 command.
Question: Does the IP address associated with the

Internet host show a valid route entry?
Question: What is the route preference of the

default static route?

Step 2.4
Issue the run ping 172.31.15.1 command to ping the Internet host.
Note
The Internet host should contain the
required routes to send traffic back to the
student devices.
Question: Does the ping operation succeed?
Step 2.5
Use the preference statement to ensure that the default static route maintains
the default route preference of 5, and that all future static routes use a route
preference of 20.
Note
Refer to the network diagram, as
necessary, for the next lab step.
Step 2.6
Add a static route to the loopback address of the directly attached virtual router.
Step 2.7
Activate the configuration and issue the run show route protocol static
command to view all static routes.
Question: Are both static routes active? What is the

route preference of each static route?
Step 2.8
Ping the loopback address of the directly attached virtual router.
Note
The virtual routers have a preconfigured
default static route using their directly
connected student devices as the next hop.
Question: Does the ping operation succeed?

Step 2.9
Add an aggregate route for the 10.1.0.0/16 prefix by issuing the set aggregate
route 10.1.0.0/16 command.
Step 2.10
Activate the newly added aggregate route and issue the run show route
protocol aggregate command.
Question: Is the newly added aggregate route

active? If not, why?
Step 2.11
Delete the 10.1.0.0/16 aggregate route and define a new aggregate route using the
172.20.64.0/18 prefix. Activate the configuration change and issue the run show
route protocol aggregate detail command.
Question: According to the route summary details

for the inet.0 routing table, does your device
currently have any hidden routes?
Question: Is the new aggregate route active? What

is the route preference of this aggregate route?
Question: What are the contributing routes for the

172.20.64.0/18 aggregate route?
Question: Based on the next-hop type associated

with the 172.20.64.0/18 aggregate route, what
action will your device take if it receives a packet
destined for a prefix for which a more specific
routing table entry does not exist?

STOP Before proceeding, ensure that the remote team within your pod is
ready to begin Part 3.
Part 3: Working with Routing Instances
In this lab part, you configure a routing instance and use routing table groups to
share routes between the master routing table and user-defined routing tables.
Step 3.1
Navigate to the [edit routing-instances] hierarchy level.
Step 3.2
Define a routing instance named instance-a that uses the virtual-router
instance type and includes the ge-0/0/1.0 and ge-0/0/2.0 interfaces.
Step 3.3
Define two static routes: the first static route is for the loopback addresses assigned
to the remote teams device and the remote virtual router; the second static route is
for the remote subnet that connects the remote teams device with the remote
virtual router. Both static routes should include two next-hop addresses in the form
of 172.20.66.z and 172.20.77.z, where z is the interface address assigned
to the remote teams device. Refer to the network diagram for this lab as necessary.
Step 3.4
Activate the changes and display the routing tables using the run show route
command.
Question: Which routing tables does the output

display?
Question: Which routes are installed in the new

routing table?
Step 3.5
Verify reachability to the remote student device using the run ping
172.20.66.z command, where z is the host address assigned to the remote
teams device.

Question: Did the ping operation succeed? If not,
why not?
Step 3.6
Add the routing-instance instance-a option to the command referenced
in the previous step.
Question: Did the ping operation succeed?
Step 3.7
Attempt to ping the loopback address of the remote student device. Source the ping
operation from the instance-a routing instance.
Question: Did the ping operation succeed? What do

the results indicate?
Step 3.8
Navigate to the [edit routing-options] hierarchy level.
Step 3.9
Issue the set rib-groups inet.0-to-instance-a import-rib
[inet.0 instance-a.inet.0] command to create a routing table group that
imports routes from inet.0 into instance-a.inet.0.
Step 3.10
Issue the set rib-groups instance-a-to-inet.0 import-rib
[instance-a.inet.0 inet.0] command to create a routing table group that
imports routes from instance-a.inet.0 into inet.0.
Note
Ensure that the remote team finishes the
previous step before proceeding
Step 3.11
Apply the inet.0-to-instance-a routing table group to import interface and
static routes from the inet.0 routing table to the instance-a.inet.0 routing
table. Activate the changes and display the instance-a.inet.0 routing table to
ensure that the routes were properly imported.

Question: Were the interface and static routes from
inet.0 imported into instance-a.inet.0?
Step 3.12
Navigate to the [edit routing-instance instance-a] hierarchy level.
Step 3.13
Apply the instance-a-to-inet.0 routing table group to import interface and
static routes from the instance-a.inet.0 routing table to the inet.0 routing
table.
Step 3.14
Activate the configuration changes and return to operational mode. Next, display the
inet.0 routing table to ensure that the routes were properly imported from the
instance-a.inet.0 routing table.
Question: Were the interface and static routes from

the instance-a.inet.0 routing table imported
into the inet.0 routing table?
Note
Ensure that the remote team finishes the
previous step before proceeding.
Step 3.15
Attempt to ping the loopback address of the remote student device from the master
inet.0 instance and user-defined instance-a instance.
Question: Do the ping operations succeed?
STOP Tell your instructor that you have completed Lab 1.


Lab 2
Load Balancing and Filter-Based Forwarding
Overview
This lab demonstrates configuration and monitoring of load balancing and filter-based
forwarding (FBF) on devices running the Junos operating system. In this lab, you use the
command-line interface (CLI) to configure and monitor load balancing and FBF.
Configure and monitor the effects of a load-balancing policy.
Configure and monitor FBF.
www.juniper.net Load Balancing and Filter-Based Forwarding Lab 21

11.a.11.1R1.10
Part 1: Configuring and Monitoring Load Balancing
In this lab part, you modify your routers configuration in preparation for subsequent
lab tasks. You then verify the default load-balancing behavior. Finally, you configure
and monitor load balancing.
Step 1.1
Enter configuration mode and delete the [edit routing-instances]
hierarchy.
Step 1.2
Navigate to the [edit routing-options] hierarchy level and issue the
delete rib-groups, delete interface-routes, and delete static
rib-group commands to remove the current routing table group definitions and
application.
Step 1.3
devices.
Define two static routes to the loopback addresses of the remote teams device and
the remote virtual router and the remote subnet that connects the remote teams
device and the remote virtual router. Both static routes should include two next hops
in the form of 172.20.66.z and 172.20.77.z, where z is the interface address
assigned to the remote student device. Once you are satisfied with the
configuration, activate the changes and return to operational mode.
Step 1.4
Display the routing table entries for the loopback addresses of the remote teams
device, the remote virtual router, and the remote subnet that connects the remote
teams device and the remote virtual router.
Question: Which next-hop interface was selected for

these two static routes?
Step 1.5
Display the forwarding table entries for the same destination prefixes and answer
the question that follows.
Question: Which next-hop interfaces does the

output list for the specified forwarding entries?
Lab 22 Load Balancing and Filter-Based Forwarding www.juniper.net

Step 1.6
Enter configuration mode and navigate to the [edit policy-options]
hierarchy level.
Step 1.7
Define a load-balancing policy named balance-traffic that will load-balance
traffic over all equal-cost paths.
Step 1.8
Navigate to the [edit routing-options forwarding-table] hierarchy
level and apply the balance-traffic policy as an export policy. Issue the
commit command to activate the configuration change.
Step 1.9
Once again, display the forwarding table entries for the loopback addresses of the
remote teams device and the remote virtual router (192.168.z.0/30) and the
remote subnet that connects the remote teams device and the remote virtual router
(172.20.11v.0/24). Compare this output with the previous output (shown in
Step 1.5) and answer the following question.
Question: Compared with the previous snapshot of

the forwarding table entries for these same
prefixes, what is different with this output?
Step 1.10
Navigate to the [edit forwarding-options] hierarchy level and configure

your device to evaluate Layer 3 and Layer 4 port data when performing the
load-balancing hash operation for IP version 4 (IPv4) traffic. Activate the
configuration changes and return to operational mode.
Step 1.11
Perform a series of traceroute operations (at least three instances) from your
assigned device to the loopback address assigned to the remote virtual router.
Note
The results illustrated in this lab step may
not be the same for all Junos platforms.
Some platforms will not allow this type of
verification and will require you to pass
traffic through the device i.e. not sourced
from the device (as in this step).

Question: Based on the traceroute results, does
your device load-balance the UDP traceroute
packets across both equal-cost paths?
STOP Do not proceed until the remote team finishes Part 1.
Part 2: Configuring and Monitoring Filter-Based Forwarding
In this lab part, you configure and monitor FBF.

Step 2.1
Enter configuration mode and navigate to the [edit firewall family inet]
hierarchy level.
Step 2.2
Issue the edit filter my-fbf-filter command to define a firewall filter
named my-fbf-filter. Create a term named match-172-subnet that
matches and forwards traffic sourced from the local 172.20.11v.0/24 subnet to
a forwarding instance called instance-66. Create a second term named
match-192-subnet that matches and forwards traffic sourced from the local
192.168.z.0/30 subnet to a forwarding instance named instance-77. You
will define the referenced forwarding instances in subsequent lab steps.
Step 2.3
Navigate to the [edit interfaces ge-0/0/4] hierarchy level and apply the
new match filter as an input IPv4 filter to the defined logical 11v interface.
Step 2.4
Navigate to the [edit routing-instances] hierarchy and create a new
instance named instance-66 using the forwarding instance type.
Step 2.5
Define two static routes for instance-66 for the remote 192.168.z.0/30 and
172.20.11v.0/24 subnets. Use the 172.20.66.z address assigned to the
remote student device as the next hop for both static routes.
Step 2.6
Use the copy command to copy the contents defined in the instance-66 routing
instance to a new routing instance named instance-77.

Step 2.7
Issue the edit instance-77 command to navigate to the [edit
routing-instances instance-77] hierarchy level. Next, issue the
replace pattern 66 with 77 command to modify the next-hop addresses
for the static routes.
Step 2.8
Navigate to the [edit routing-options] hierarchy level and define an import
routing table group named fbf-rib-group that includes the inet.0,
instance-66.inet.0, and instance-77.inet.0 routing tables.
Step 2.9
Issue the set interface-routes rib-group inet fbf-rib-group
command to apply the newly defined routing table group to import interface routes
between the master and user-defined routing instances.
Step 2.10
Activate the configuration and issue the run show route command to ensure
that the routing tables for the user-defined routing instances have the required
routing information.
Question: Were the static and interface routes

added to the routing tables for the new instances?
Note
The next 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. Refer to the management network
diagram for the IP address of the virtual
router device.

Step 2.11
Open a separate Telnet session to the virtual router device.
Step 2.12
Log in to the virtual router attached to your teams device 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
Step 2.13
From your assigned virtual router, perform several traceroute operations (at least
three instances) to the loopback address assigned to the remote virtual router.

Note
Remember to reference the appropriate
instance name when sourcing Internet
Control Message Protocol (ICMP) traffic
from a virtual router. The instance names
match the virtual router names listed on
the network diagram for this lab.
Question: Which path did the traceroute packets

take?
Step 2.14
Using your virtual routers loopback address as the source address, perform a new
series of traceroute operations (at least three instances) to the loopback address
assigned to the remote virtual router.
Note
instance name when sourcing traffic from a
virtual router. The instance names match
the virtual router names listed on the
network diagram for this lab.
Question: Which path did the traceroute packets

take?
Step 2.15
Use the ping utility to verify that your assigned virtual router can reach the Internet
host. Remember to reference the appropriate routing instance.
Question: Was the ping test successful? If not, why

not?

Step 2.16
Return to the session opened to your assigned student device. Navigate to the
[edit routing-instances] hierarchy level and define a default static route
that directs matching traffic to the inet.0 routing table for both routing instances.
Activate the configuration change and return to operational mode.
Step 2.17
Issue the show route table instance-66 protocol static command
and ensure that the default static route was installed and directs traffic to the
inet.0 routing table.
Question: Do each of the user-defined instances

now have a default static route installed that directs
matching traffic to the inet.0 routing table?
Step 2.18
Return to the session opened to the virtual router and perform the ping test to the
Internet host again.
Question: Was the ping test successful?

Lab 3
Open Shortest Path First
Overview
This lab demonstrates configuration and monitoring of the Open Shortest Path First
(OSPF) protocol. In this lab, you use the command-line interface (CLI) to configure,
monitor, and troubleshoot OSPF.
Configure and monitor a multi-area OSPF network.
Perform basic OSPF troubleshooting.
www.juniper.net Open Shortest Path First Lab 31

11.a.11.1R1.10
Part 1: Configuring and Monitoring OSPF
In this lab part, you configure and monitor a multi-area OSPF network. You will first
prepare your device by removing all filter-based forwarding (FBF) configuration. Next
you define a router ID for your assigned device. You then configure your device to
participate in a multi-area OSPF network and verify operations using CLI operational
mode commands.
Step 1.1
devices.
Enter configuration mode and delete the configuration defined under the [edit
routing-instances] and [edit firewall] hierarchy levels. Next, remove
the application of the input filter assigned to the ge-0/0/4.11v interface.
Step 1.2
Navigate to the [edit routing-options] hierarchy level and remove the
defined routing table group and the application of that routing table group for
interface routes.
Step 1.3
Define the router ID on your router using the IP address assigned to the lo0 interface
as the input value.
Step 1.4
Navigate to the [edit protocols ospf] hierarchy level and configure OSPF
Area 0. Refer to the network diagram as necessary and remember to include lo0.0.
Step 1.5
Activate the configuration and issue the run show ospf neighbor command.
Question: Which neighbor state is shown for the

listed interfaces?
Question: Which value is listed under the ID

column?
Question: Which value is listed under the Pri

column? What does this value help determine?
Lab 32 Open Shortest Path First www.juniper.net

Step 1.6
Issue the run show ospf interface command to display OSPF interface
details.
Question: Which interfaces are listed in the output?

What are the states of those interfaces?
Step 1.7
Issue the run show ospf database command to display the OSPF database
details.
Question: How many and what types of link-state

advertisements (LSAs) exist in OSPF database?
Step 1.8
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 1.9
Associate a metric of 100 with the ge-0/0/2.0 interface and activate the change.
Question: Based on your change, which interface do

you expect OSPF to choose toward the remote
student device?

Note
Before proceeding, ensure that the remote
team in your pod finishes the previous step.
Step 1.10
Question: Reissue the run show ospf route

command to see your changes.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 remote 192.168.z.1 OSPF routes?
Step 1.11
Issue the run show route protocol ospf command to view OSPF routes
installed in the routing table.
Question: Which OSPF routes exist in the routing

table?
Question: Why are the 172.20.66.0/30 and

172.20.77.0/30 routes not listed in the generated
output?
Step 1.12
Configure your device to function as an area border router (ABR), joining Area 0 with
a second area (either Area 1 or Area 2, depending on your assigned device). Refer to
the network diagram for this lab for the area and interface details. Once it is
configured, activate the configuration changes and return to operational mode.
Step 1.13
Issue the 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 1.14
Issue the show ospf database command to display the current OSPF database.
Question: How many OSPF databases are present

in the output?
Question: Which LSA types are represented in the

current OSPF databases?
Question: Based on the database entries, which

devices are injecting external prefixes in to OSPF?
Question: Which command lists only external

entries in the OSPF database?
Step 1.15
Enter configuration mode and navigate to the [edit policy-options]
hierarchy level.
Step 1.16
Define a new routing policy named inject-default-route. Include a single
term named match-default-route that matches and accepts the default static
route into OSPF.

Step 1.17
Navigate to the [edit protocols ospf] hierarchy and apply the newly defined
policy as an export policy. Next, activate the configuration change using the commit
command.
Step 1.18
Issue the run show ospf database advertising-router self
command to view all OSPF LSAs in the database that the local device originated.
Question: Is a matching LSA entry present for the

recently injected default static route?
Note
student team in your pod finishes the
previous step.
Step 1.19
Issue the run show route 0/0 exact command to view the current routing
table entries for the default route.
Question: Based on the current default route entry,

what would happen if your devices direct
connection to the Internet failed?
Step 1.20
Issue the save /var/tmp/working-ospf.conf command to save the
current OSPF configuration.

Part 2: Performing Basic OSPF Troubleshooting
In this lab part, you perform basic OSPF troubleshooting. First, you modify your
devices current configuration to make it incompatible with the attached virtual
router. You then enable OSPF traceoptions to log protocol activity. Finally, you display
the traceoptions log and the OSPF statistics to view the associated errors.
Step 2.1
Issue the run show ospf statistics to display the current OSPF errors and
statistics.
Question: Does your device show any registered

errors?
Step 2.2
Rename the nonbackbone area (Area 1 or Area 2 depending on your assigned
device) to area 3.
Step 2.3
Activate the configuration change and issue the run show ospf neighbor
command.
Question: How many OSPF neighbors does your

assigned device currently have?
Step 2.4
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 for the OSPF errors. Activate the configuration change using the
commit command.
Step 2.5
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 2.6
Issue the run show ospf statistics command to verify any current error
counters.
Question: Are any error counters listed?
Step 2.7
Rename area 3 back to the correct area number (Area 1 or Area 2 depending on
your assigned device). Next, assign the correct nonbackbone area an area type of
stub and activate the configuration changes.
Step 2.8
Issue the run clear log trace-ospf command to clear the contents of the
defined trace file. Wait a moment, then issue the run show log trace-ospf
command to view any new entries in the trace file.

explain the current OSPF adjacency issue?
Step 2.9
Issue the run show ospf statistics command to verify the current error
counters.
Question: Are any new error counters listed?
Step 2.10
Issue the delete command and confirm the operation to delete the current OSPF
configuration. Next, issue the load merge /var/tmp/working-ospf.conf
command to load the configuration you saved earlier in this lab. Activate the
restored configuration and return to operational mode using the commit
and-quit command.
Step 2.11
Verify that the OSPF neighbor adjacency has returned to the Full state between
your device and the directly attached virtual router.
Question: Did the OSPF adjacency with the directly

attached virtual router return to the Full state?



Lab 4
Border Gateway Protocol
Overview
This lab demonstrates configuration and monitoring of the Border Gateway Protocol
(BGP). In this lab, you use the command-line interface (CLI) to configure and monitor BGP.
Configure and monitor BGP.
Export aggregate routes to an EBGP peer.
Configure and apply a next-hop self policy.
www.juniper.net Border Gateway Protocol Lab 41

11.a.11.1R1.10
Part 1: Configuring and Monitoring IBGP
In this lab part, you configure and monitor internal BGP (IBGP). You first define the
autonomous system (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 1.1
Enter configuration mode and deactivate the OSPF export policy referenced under
the [edit protocols ospf] hierarchy level.
Step 1.2
Navigate to the [edit routing-options] hierarchy level and deactivate the
default static route. Activate the configuration changes using the commit
command.
Step 1.3
Define the AS number designated for your network. Refer to the network diagram for
this lab as necessary.
Step 1.4
devices.
Navigate to the [edit protocols bgp] hierarchy level. Configure a BGP 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 devices within your AS
number as the peer 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? If

not, why not?
Step 1.5
Configure the my-int-group for the internal BGP session type. Next, issue the
commit command to activate the configuration.
Step 1.6
Issue the run show bgp summary command to view the current BGP summary
information for your device.
Lab 42 Border Gateway Protocol www.juniper.net

Question: How many BGP neighbors does your
device currently list?
Question: Has your device received any routes from

its IBGP peers?
Step 1.7
Issue the run show route receive-protocol bgp neighbor command,
where neighbor 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?
Question: Which routing table group does the

referenced command consult? Which operational
mode command displays BGP routes in the routing
table (RIB-Local)?
Step 1.8
Issue the run show route advertising-protocol bgp neighbor
command, where neighbor is the loopback address of each IBGP peer.

Question: Which routing table group does the
command referenced in this step consult?
Question: Is your device currently advertising BGP

routes to any of its IBGP peers?
Part 2: Configuring and Monitoring EBGP
In this lab part, you configure and monitor EBGP. You first establish an EBGP peering
session with the external peer. You then advertise aggregate routes to your EBGP
peer to represent the prefixes reachable from your AS. Finally, you monitor the
established EBGP peering session using CLI operational mode commands.
Step 2.1
Refer to the network diagram for this lab and configure an EBGP peering session
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.
Step 2.2
Issue the run show bgp summary command to view the current BGP summary
information.
Question: How many BGP groups and peers does

your device currently list?
Question: Has your device received any routes from

its EBGP peer?

Step 2.3
Issue the run show bgp neighbor 172.18.z.1 command to view details for
the EBGP peering session. Replace z with the IP address value assigned to your
EBGP peer. Use the generated output to answer the following questions:
Question: What is the current state for this peer?

What was the previous state for this peering
session?
Question: Which values are set for the keepalive

interval and holddown timer?
Question: What is the last recorded event for this

EBGP session?
Question: Which network layer reachability

information (NLRI) is supported for this peering
session?
Step 2.4
Display the BGP routes received from the EBGP peer using the run show route
receive-protocol bgp 172.18.z.1 command, where z is the IP address
value assigned to your EBGP peer.
Question: How many prefixes originated from AS

number 65531?
Question: What do the ?, E, and I indicators within

the AS path represent?

Step 2.5
Issue the run show route advertising-protocol bgp 172.18.z.1
command, where z is the IP address value assigned to your EBGP peer.
Question: Is your device currently advertising the

BGP routes received from its IBGP peers to its EBGP
peer? If not, explain why.
Step 2.6
Issue the set advertise-inactive command to override the default behavior
and advertise BGP routes that are not currently selected as active because of route
preference. Activate the configuration change by issuing the commit command.
Step 2.7
Once again, issue the run show route advertising-protocol bgp
172.18.z.1 command, where z is the IP address value assigned to your EBGP
peer, to determine whether your device is advertising BGP routes to its external BGP
peer.
Question: Is your device now advertising the BGP

routes received from its IBGP peers to its EBGP
peer?
Step 2.8
Navigate to the [edit routing-options] hierarchy and define additional
aggregate routes that represent the remainder of the internal prefixes that are part
of your AS. (Hint: In addition to the current aggregate route, you will need to
summarize the 172.21.z.0/24, 172.22.z.0/24, 192.168.y.z/32 prefixes.)
Step 2.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 defined aggregate
routes. Ensure that you match the aggregate protocol. Name the second term
deny-other. It should reject all other routes.
Step 2.10
Navigate to the [edit protocols bgp] hierarchy level and apply the newly
defined policy as an export policy for the external BGP group named
my-ext-group. Activate the configuration changes using the commit command.

Step 2.11
Verify the effects of the newly defined and applied policy by issuing the run show
route advertising-protocol bgp 172.18.z.1 command, where z is
the IP address value assigned to your EBGP peer.
Question: Is your device advertising all of the

expected aggregate prefixes? If not, which prefix is
not being advertised?
Step 2.12
Examine the routing table entry for the 192.168.z.0/30 aggregate route
representing the loopback addresses for the remote side to determine why it is not
being advertised into BGP.
Question: Based on the contents of the routing

table, can you explain why the 192.168.z.0/30
aggregate route is not currently advertised into
BGP? How might you remedy this situation?
Step 2.13
Decrease the route preference for the aggregate route representing the loopback
addresses of the remote student and virtual router devices to 19. Activate the
change and issue the run show route 192.168.z.0/30 command to verify
that the aggregate route is now active.
Question: Is the aggregated route now active?
Step 2.14
Verify that the effects of the route preference change by issuing the run show
route advertising-protocol bgp 172.18.z.1 command, where z is
the IP address value assigned to your EBGP peer.
Question: Is your device now advertising all of the

expected aggregate prefixes?

Question: Use the summary details of the
generated output to determine whether your device
currently has hidden routes. If so, how many?
Part 3: Implementing a next-hop self Policy
In this lab part, you define and apply a next-hop self policy to alter the next-hop
value associated with routes received from your EBGP peer. You monitor the effects
of this policy.
Note
The following 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. Refer to the management network
router.
Step 3.1
Open a separate Telnet session to the virtual router.

Step 3.2

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
Step 3.3
From your assigned virtual router, issue the show route table
vr11v.inet.0 protocol bgp command, where v is the value assigned to
your virtual router.
Question: How many BGP routes display using the

referenced command?
Question: Does your virtual router currently have

hidden routes?
Step 3.4
View the hidden routes by issuing the show route table vr11v.inet.0
hidden extensive command, where v is the value assigned to your virtual
router.
Question: What are the protocol next-hop values

associated with these hidden routes?

Question: Why are these routes hidden?
Step 3.5
Return to the session opened for your assigned student device and navigate to the
[edit policy-options] hierarchy level. Define a policy named
change-next-hop with no terms and no defined match conditions, which alters
the next-hop value to the local devices IP address used for peering sessions.
Step 3.6
Navigate to the [edit protocols bgp] hierarchy and apply the
change-next-hop policy as an export policy to the my-int-group BGP group.
Activate the changes and return to operational mode using the commit and-quit
command.
Note
previous step.
Step 3.7
Return to the Telnet session opened to the virtual router attached to your assigned
device. Issue the show route table vr11v.inet.0 protocol bgp
extensive command, where v is the value assigned to your virtual router.
Question: What are the protocol next-hop values

associated with the displayed BGP routes?
Question: Are there any hidden routes present on

your assigned virtual router?

Lab 5
IP Tunneling
Overview
This lab demonstrates using the command-line interface (CLI) to configure and monitor a
generic routing encapsulation (GRE) tunnel.
Configure and monitor a GRE tunnel.
Use the defined GRE tunnel to merge two remote OSPF domains.
www.juniper.net IP Tunneling Lab 51

11.a.11.1R1.10
Part 1: Configuring and Monitoring a GRE Tunnel
In this lab part, you configure and monitor a GRE tunnel. Using static routes, you
direct traffic to the remote subnets in your pod through the newly formed GRE
tunnel.
Step 1.1
devices.
Enter configuration mode and navigate to the [edit interfaces] hierarchy
level. Next, disable the ge-0/0/1 and ge-0/0/2 interfaces. Finally, set the mtu of the
ge-0/0/3 interface to 1524.
Question: Why increase the MTU to 1524?
Step 1.2
Define a new GRE interface and tunnel using the IP address assigned to the
loopback interface on your device as the source address and the IP address
assigned to the loopback interface on the remote student device as the destination
address. Use unit 0 for the logical point-to-point interface.
Step 1.3
Activate the changes and issue the run show interfaces terse gr-0/0/0
command to verify the state of the newly defined GRE interface.
Question: What is the current state of the

gr-0/0/0.0 interface?
Step 1.4
Navigate to the [edit routing-options static] hierarchy and modify the
static routes for the subnets associated with the remote team to use only the newly
defined GRE interface. Ensure that you delete the current next-hop values assigned
to those static routes.
Step 1.5
Activate the changes using commit and issue the run show interfaces
terse gr-0/0/0 command several times to monitor the state of the GRE
interface.
Lab 52 IP Tunneling www.juniper.net

Question: What is the state of the gr-0/0/0.0
interface?
Note
In the current state, the routing table
purges the static route for the remote
192.168.z.0/30 prefix when the
gr-0/0/0.0 interface goes down. Once the
192.168.z.0/30 prefix is removed from the
routing table, the remote tunnel endpoint
address is resolved through the default
BGP route received from the EBGP peer.
Once the remote tunnel endpoint address
is resolved through the default BGP route,
the gr-0/0/0.0 interface returns to the up
state and the GRE tunnel re-establishes.
When the GRE tunnel is re-established, the
static route for the remote 192.168.z.0/30
prefix is added back to the routing table, at
which time the same problem repeats. This
cycle continues until corrective action is
taken. You will correct this issue in a
subsequent step.
Step 1.6
Define a new static route for the remote tunnel endpoint address (the loopback
address of the remote student device) using the 172.18.y.1 address as the next
hop, where yis the value assigned to your WAN connection. Issue the commit
command to activate the changes.
Step 1.7
Issue the run show interfaces terse gr-0/0/0 command several times
to monitor the state of the GRE interface.

Step 1.8
Use the routing table to determine the next hop associated with the remote
172.20.11v.0/24 subnet.

Question: What is the next hop associated with the
route for the remote 172.20.11v.0/24 subnet?
Note
previous step.
Step 1.9
Use the ping utility to verify reachability to the remote virtual router. Use a
destination host address of 172.20.11v.10, where v is the value assigned to the
remote subnet between the remote student device and the virtual router. Use a
source host address of 172.20.11v.1, where v is the value assigned to the local
subnet between your device and the virtual router. Refer to the network diagram for
this task as necessary.
Question: Is the ping operation successful? What

does this ping test indicate?
Part 2: Configuring the GRE Interface to Participate in OSPF
In this lab part, you configure the GRE interface to participate in OSPF, thus allowing
the GRE tunnel to merge the two remote OSPF domains back to a single OSPF
domain. You will then re-enable the ge-0/0/1 and ge-0/0/2 interfaces and ensure
that the gr-0/0/0.0 interface serves as the backup link for OSPF area 0.
Step 2.1
Verify the current state of the OSPF neighbors using the run show ospf
neighbor command.

assigned device currently show?
Step 2.2
Navigate to the [edit protocols ospf] hierarchy level and add the
gr-0/0/0.0 interface under OSPF Area 0.0.0.0.

Note
previous step.
Step 2.3
Activate the configuration change by issuing the commit command and then issue
the run show ospf neighbor command several times to verify that a new
OSPF neighbor was added and that the new neighbor session is stable.
Question: Has a new neighbor been detected and, if

so, is the associated neighbor session stable?
Question: Based on the generated output, what is

the address of the newly detected OSPF neighbor?
Question: Other than through the OSPF protocol,

how is your device learning the route for the
address of the remote student devices loopback
interface?
Question: What is the route preference currently

assigned to the static route for the remote devices
loopback interface address? How might the current
route preference for this route be contributing to the
unstable OSPF session?
Step 2.4
Navigate to the [edit routing-options static] hierarchy and modify the
route preference of the static route for the remote devices loopback interface
address to a value of 5. Activate the configuration change and return to operational
mode using the commit and-quit command.

Note

previous step.
Step 2.5
Issue the show route 192.168.z.1 command, where z represents the value
assigned to the loopback interface address of the remote student device.
Question: From which sources does your device

learn the referenced prefix? Which source is
selected as active and why?
Step 2.6
Issue the show ospf neighbor command several times to verify that the new
OSPF neighbor has been added and that the new neighbor session is stable.

assigned device currently show? Are the detected
OSPF sessions stable?
Step 2.7
Enter configuration mode and re-enable the ge-0/0/1 and ge-0/0/2 interfaces.
Activate the changes using the commit command.
Step 2.8
Ensure that the remote team in your pod has finished the previous task, then issue
the run show ospf neighbors command.

assigned device currently show?
Step 2.9
Add a metric value of 200 to the gr-0/0/0.0 interface under the [edit
protocols ospf area 0.0.0.0] hierarchy to ensure that the tunnel serves
as a backup path when the ge-0/0/1.0 and ge-0/0/2.0 interfaces are operational.
Activate the configuration change using the commit command.

Step 2.10
Issue the run show ospf route command to confirm that OSPF routes are not
currently using the gr-0/0/0.0 interface.
Question: Are any of the OSPF routes using

gr-0/0/0.0?
Step 2.11
Disable the ge-0/0/1 and ge-0/0/2 interfaces once again. Commit your changes
and issue the run show ospf route command to confirm that the remote OSPF
routes are now learned through the gr-0/0/0 interface.
Question: Are the OSPF routes associated with the

remote side of your assigned pod using gr-0/0/0.0?
Step 2.12
Re-enable the ge-0/0/1 and ge-0/0/2 interfaces. Activate the configuration
changes and return to operational mode using the commit and-quit command.


Lab 6
High Availability
Overview
This lab demonstrates how to configure and monitor some high availability (HA) features
using the command-line interface (CLI).
Configure and monitor graceful restart.
Configure and monitor the Bidirectional Forwarding Detection (BFD) protocol.
Configure and monitor the Virtual Router Redundancy Protocol (VRRP).
www.juniper.net High Availability Lab 61

11.a.11.1R1.10
Part 1: Configuring and Monitoring Graceful Restart
In this lab part, you configure and monitor graceful restart. Before enabling graceful
restart, you perform some verification tasks using the directly attached virtual
router. You then enable graceful restart and perform the same verification tasks to
determine the impact that graceful restart can have in a network. You should refer to
the diagram for this lab part for topological details.
Note
This lab part requires you to log in to the
virtual router attached to your teams
device. Refer to the management network
router.
Step 1.1
Lab 62 High Availability www.juniper.net

Step 1.2

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
Step 1.3
devices.
Initiate a continuous ping from your assigned virtual router to the loopback address
of the remote virtual router. Refer to the network diagram for this lab part as
necessary.
Note
instance name when sourcing Internet
Control Message Protocol (ICMP) traffic
Step 1.4
On your assigned student device, restart the routing process while the ping
operation initiated on the directly attached virtual router continues.
Step 1.5
Return to the session opened to the attached virtual router and monitor the ping
operation for a moment. Next, type Ctrl + c to stop the continuous ping operation.

Question: Did a disruption occur to the packet
forwarding operation through your assigned student
device?
Step 1.6
On your assigned student device, enter configuration mode and navigate to the
[edit routing-options] hierarchy level.
Step 1.7
Enable graceful restart and activate the change using the commit command.
Note
previous step.
Step 1.8
Return to the session opened with the directly attached virtual router and initiate a
continuous ping from your assigned virtual router to the loopback address of the
remote virtual router.
Note
instance name when sourcing ICMP traffic
Step 1.9
On your assigned student device, issue the run restart routing command to
restart the routing process once again while the ping operation on the attached
virtual router continues.
Step 1.10
Return to the session opened to the attached virtual router and monitor the ping
operation for a moment. Next, type Ctrl + c to stop the continuous ping operation.
Question: Did a disruption occur to the packet

forwarding operation through your assigned student
device with graceful restart enabled?

Step 1.11
Return to your student device and issue the run show bgp neighbor
172.18.z.1 command, where z represents the value assigned to the EBGP peer
connected to your student device.
Question: In the generated output, which evidence

indicates that graceful restart is enabled for this
EBGP peering session?
Step 1.12
Navigate to the [edit protocols bgp] hierarchy level and disable graceful
restart for the EBGP neighbor defined under the my-ext-group BGP group.
Step 1.13
Activate the configuration change and issue the run show bgp neighbor
172.18.z.1 command once again, where z represents the value assigned to the
EBGP peer connected to your student device.
Question: In the generated output, which evidence

indicates that graceful restart is now disabled for
this EBGP peering session?
Step 1.14
Re-enable graceful restart for the EBGP peering session. Issue the commit
command to activate the change.
Step 1.15
Navigate to the [edit protocols ospf] hierarchy and enable traceoptions to
track graceful restart operations for OSPF. Use a file name of trace-GR and
enable the graceful-restart flag with the detail option. Activate the
configuration changes using the commit command.
Step 1.16
Issue the run restart routing command. After a moment, issue the run
show log trace-GR command to display the contents of the log file.
Question: Did the restart events write to the log file?

Part 2: Configuring and Monitoring BFD
In this lab part, you configure and monitor BFD. You should refer to the diagram for
this lab part for topological details.
Step 2.1
Issue the run show bfd session command to determine whether your student
device has any active BFD sessions.
Question: Does your student device currently have

any active BFD sessions?
Step 2.2
Enable BFD on the interfaces participating in OSPF (except lo0.0). Use 300 ms as
the minimum transmit and receive interval value. Activate the configuration changes
using the commit command.
Note
previous step.
Step 2.3
Issue the run show bfd session command to determine whether your student
device has any active BFD sessions.
Question: Does your student device currently have

any active BFD sessions?
Question: What are the current transmit intervals?

Do all of these values match the values you
defined? If not, explain why.

Question: Based on the BFD session details, how
many BFD hellos must be missed before one of the
established sessions goes down?
Step 2.4
Issue the run show bgp neighbor 172.18.z.1 command, where z
represents the value assigned to the EBGP peer connected to your student device.
Question: Does the output clearly indicate whether

BFD is enabled for this EBGP peering session?
Step 2.5
Navigate to the [edit protocols bgp] hierarchy and enable BFD for the EBGP
peering session. Use a minimum interval value of 300 ms for this BFD session and
activate the change using the commit command.
Step 2.6
Issue the run show bgp neighbor 172.18.z.1 command once again,
where z represents the value assigned to the EBGP peer connected to your student
device.
Question: Does the output clearly indicate whether

BFD is enabled for this EBGP peering session?
Question: What would be the effects of a firewall

filter inadvertently blocking BFD hello packets?
Part 3: Configuring and Monitoring VRRP
In this lab part, you configure and monitor VRRP. You should refer to the diagram for
this lab part for topological details. Note that the lab diagram used for this lab part is
different than the lab diagram used for the previous parts of this lab.

Step 3.1
Navigate to the [edit interfaces ge-0/0/4] hierarchy and define two new
logical interfaces using the details provided on the network diagram for this lab part.
Step 3.2
Activate the configuration change and ensure that you can ping the remote student
device and the virtual routers. Note that each of the defined subnets has an
assigned virtual router.
Question: Can you ping the remote student device

and virtual routers?
Step 3.3
Configure VRRP on the newly defined logical interfaces. Associate the new logical
interface with the lower VLAN-ID with vrrp-group 1z and the new logical
interface with the higher VLAN-ID with vrrp-group 2z. Refer to the network
diagram associated with this lab part for all interface and VRRP configuration
variables for your assigned pod and device.
Question: Based on the newly defined VRRP

configuration, which VRRP state should each
participating interface assume?
Note
previous step.
Step 3.4
Activate the configuration changes using the commit command then issue the run
show vrrp command to determine the current VRRP state for each VRRP group.
Question: Which VRRP state has each participating

interface assumed within its respective VRRP
group?

Step 3.5
Step 3.6

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
Step 3.7
From the virtual routers associated with your pod, ping the Internet host listed on the
network diagram. Note that each virtual router used in this lab part has a default
static route with the virtual IP (VIP) address associated with each respective subnet
as the gateway address.

Note
Question: Do the ping operations succeed?
Step 3.8
From the virtual routers associated with your pod, ping the gateway address for each
virtual routers respective subnet.
Note
Question: Do the ping operations succeed? If not,

explain why not.
Step 3.9
Return to your assigned student device and enable the accept-data
configuration option for both VRRP groups. Activate the configuration changes using
the commit command.
Step 3.10
From the virtual routers associated with your pod, ping the gateway address for each
virtual routers respective subnet once again.
Note


Question: Do the ping operations now succeed?
Step 3.11
Return to the console session opened for your assigned student device. Enable the
interface tracking option for the VRRP group for which your device is currently
functioning as master VRRP router. Track the ge-0/0/3.0 interface and reduce the
priority value by 101 if the tracked interface goes down. Activate the configuration
change and return to the root of the configuration hierarchy.
Note
If you are assigned srxX-1, you should
enable interface tracking only for
vrrp-group 1z. If you are assigned
srxX-2, you should enable interface
tracking only for vrrp-group 2z. Refer
to the network diagram for this lab part for
the z values.
Step 3.12
Disable the ge-0/0/3.0 interface and activate the change using the commit
command.
Step 3.13
Issue the run show vrrp track command to view the current interface
tracking details.
Question: According to the output, what is the

current interface state of the tracked interface?
Also, what is the current VRRP state and priority
value for the associated VRRP group?
Step 3.14
Re-enable the ge-0/0/3.0 interface and activate the change by using the commit
command.
Step 3.15
Verify the current status of the tracked interface and its associated VRRP group by
issuing the run show vrrp track command.

Question: What is the current status of the tracked
interface? Which VRRP state and priority value are
now assigned to the VRRP interface?
Step 3.16
Reload the reset configuration by issuing the load override /var/tmp/
reset.conf command. Activate the reset configuration and return to operational
mode using the commit and-quit command. Log out of all open sessions.

Lab 7
IPv6 (Optional)
Overview
This lab demonstrates configuration and monitoring of IP version 6 (IPv6) interfaces on
devices running the Junos operating system. In this lab, you use the command-line
interface (CLI) to configure and monitor interfaces, static routing, basic OSPF, and generic
routing encapsulation (GRE) tunnels.
Configure and verify proper operation of IPv6 network interfaces.
Configure and monitor static IPv6 routing.
Configure and monitor OSPF with IPv6 interfaces.
Configure a GRE interface to tunnel IPv6 traffic over an IP version 4 (IPv4)
network.
www.juniper.net IPv6 (Optional) Lab 71

11.a.11.1R1.10
Part 1: Configuring and Monitoring Interfaces
In this lab part, you will configure network interfaces on your assigned device. You
will then verify that the interfaces are operational and that the system adds the
corresponding route table entries for the configured interfaces.
Note
Depending on the class, the lab equipment
used might be remote from your physical
location. The instructor will inform you as to
the nature of your access and will provide
you with the details needed to access your
assigned device.
Step 1.1
Ensure that you know to which device you are assigned. Check with your instructor if
you are unsure. Consult the management network diagram, provided by your
instructor, to determine your devices management address.
Question: What is the management address

assigned to your station?
Step 1.2
Access the CLI at your station using either the console, Telnet, or SSH as directed by
your instructor. The following example shows simple Telnet access to srxA-1 using
the Secure CRT program
Step 1.3
Log in as user lab with the password supplied by your instructor.
Step 1.4
Enter configuration mode and load the reset configuration by issuing the load
override /var/tmp/reset.conf command.
Lab 72 IPv6 (Optional) www.juniper.net

Step 1.5
Enable IPv6 on the router using the set security forwarding-options
family inet6 mode packet-based command. Activate the configuration
and return to operational mode using the commit and-quit command.
Step 1.6
Issue the show route table inet6 to display the contents of the IPv6 route
table.
Question: Are any routes shown?
Step 1.7
input. Variable z is used to distinguish IP addresses on the local and remote devices.
Refer to the network diagram and configure the interfaces for your assigned device.
Use logical unit 0 for all interfaces. Remember to configure the loopback
interface!
Step 1.8
Display the interface configuration and ensure that it matches the details outlined
on the network diagram for this lab. When you are comfortable with the interface
configuration, issue the commit-and-quit command to activate the
configuration and return to operational mode.
Step 1.9
Issue the show interfaces terse command to verify the current state of the
recently configured interfaces.
Question: How many IPv6 addresses are associated

with each one of your interfaces?
Question: How are the other addresses created on

the router?
Step 1.10
Issue the show route table inet6 command to view the current IPv6 route
entries.

Question: How many routes were installed for each
one of the configured interfaces?
Question: Are any routes currently hidden?
Step 1.11
Use the ping utility to verify reachability to the neighboring devices connected to your
device. If needed, check with the remote student team and your instructor to ensure
that their devices have the required configuration for the interfaces.
Note
The first ping of the twenty-five may be lost
and show up as a . (period).
Step 1.12
Issue the show ipv6 neighbors command.
STOP Before continuing, ensure that the remote team in your pod is ready to
proceed.
Part 2: Configuring and Monitoring Static Routing
In this lab part, you will configure and monitor a default static IPv6 route.
Step 2.1
Attempt to ping the Internet host referenced on the network diagram for this lab.
Note
Use Ctrl+c to stop a continuous ping

operation.
Question: What does the result from the ping

operation indicate?

Question: Based on the network diagram, which IP
address would your device use as a next hop to
reach the Internet host?
Step 2.2
Enter configuration mode and define a default static route. Use the IP address
identified in the last step as the next hop for the default static route.
Step 2.3
Activate the newly added static route and return to operational mode. Issue the
show route 2001:172:31:15::1 command.
Question: Does the IPv6 address associated with

the Internet host now show a valid route entry?
Question: What is the route preference of the

default static route?
Step 2.4
Issue the ping 2001:172:31:15::1 command to ping the Internet host.
Note
The Internet host should contain the
required routes to send traffic back to the
student devices.
Question: Does the ping operation succeed this

time?
STOP Notify your instructor that you have finished Part 2. Before proceeding,
ensure that the remote team within your pod is ready to continue on to
Part 3.

Part 3: Configuring and Monitoring OSPF
In this lab part, you will configure and monitor an IPv6 interface in OSPF. You will
configure a single OSPF Area 0 based on the network diagram for this lab. Finally,
you will perform some verification tasks to ensure that OSPF works properly.
Note
RIP and OSPF both require new versions to
support IPv6. These new versions are
known as RIPng and OSPFv3. No changes
are necessary for IS-IS because it supports
IPv6 natively.
Step 3.1
Define OSPF Area 0 and include the internal interface that connects to the remote
teams device. Ensure that you also include the lo0 interface. Also, recall that only
OSPF version 3 supports IPv6. Issue the show command to view the resulting
configuration.
Note
Remember to specify the appropriate
logical interface! If the logical unit is not
specified, the Junos OS assumes a logical
unit of zero (0).
Question: With the OSPF configuration in place, how

many OSPF neighbor adjacencies should form?
Step 3.2
Activate the candidate configuration using the commit and-quit command to
return to operational mode. Issue the show ospf3 neighbor command to verify
OSPF neighbor adjacency state information.
Note
The OSPF adjacency state for each
neighbor is dependent on that neighbors
configuration. Ensure that the neighboring
team has added the required OSPF
configuration and committed the changes.
The virtual routers contain preconfigured
settings added by your instructor.
Question: Which state do the OSPF neighbor

adjacencies show?

Question: Why does the neighbor ID show as an
IPv4 address?
Step 3.3
Issue the show route protocol ospf3 to view the active OSPF routes in your
devices route table.
Question: What is the ff02::5/128 address?
Part 4: Tunneling IPv6 over IPv4 Using GRE Encapsulation
In this lab part, you configure a GRE tunnel to carry IPv6 traffic over IPv4. You should
refer to the diagram for this lab part for topological details. Note that the lab diagram
used for this lab part is slightly different from the lab diagram used for the previous
parts of this lab.
Step 4.1
First, delete the protocols and routing-options stanzas. Second, delete
interfaces ge-0/0/2, ge-0/0/3 and the loopback interface.
Step 4.2
Configure IPv4 addressing as per the lab diagram on your devices loopback and
ge-0/0/3 interfaces. Finally, using the ge-0/3/0 address as a next-hop, configure a
static route to the remote student devices loopback.
Step 4.3
Display your changes and ensure they match the details outlined on the network
diagram for this lab. When you are comfortable with the interface configuration,
issue the commit-and-quit command to activate the configuration and return to
operational mode.
Step 4.4
At this point, you now have a basic IPv4 network. Test the reachability of the remote
student devices loopback using the ping command. Be sure to source the ping from
your devices loopback.

Step 4.5
Define a new GRE interface and tunnel using the IP address assigned to the
loopback interface on your device as the source address and the IP address
assigned to the loopback interface on the remote student device as the destination
address. Use unit 0 for the logical point-to-point interface.
Step 4.6
Activate the changes and issue the run show interfaces terse gr-0/0/0
command to verify the state of the newly defined GRE interface.

Step 4.7
Configure an IPv6 address on your tunnel interface. Refer to the lab diagram for the
IPv6 address to use. When you are satisfied, activate your changes with the commit
command.
Step 4.8
Verify you can reach the remote student devices IPv6 tunnel address using the ping
command.
Question: How is the IPv6 traffic forwarded across

the tunnel?
Step 4.9
Issue a run show route 2001:c0ff:ee:100::z command to show that the
IPv6 destination is, indeed, the tunnel interface.
Step 4.10
Issue a run show interfaces gr-0/0/0.0 command. Note the IP-Header
line.
Question: What does the IP Header line tell you?

Question: What does the number 47 in the IP
Header line signify?
Step 4.11
Issue a run show route 192.168.z.1 command to see how our
encapsulated IPv6 packets are leaving the router.
Question: What have these outputs proven?
STOP
Tell your instructor that you have completed Lab 7.


Lab 8
IS-IS (Optional)
Overview
This lab demonstrates configuration and monitoring of the IS-IS protocol. In this lab, you
use the command-line interface (CLI) to configure, monitor, and troubleshoot IS-IS.
Configure and monitor a multi-level IS-IS network.
Perform basic IS-IS troubleshooting.
www.juniper.net IS-IS (Optional) Lab 81

11.a.11.1R1.10
Part 1: Configuring and Monitoring IS-IS
In this lab part, you configure and monitor a multi-level IS-IS network. You will first
prepare your device by removing all filter-based forwarding (FBF) configuration. Next
you define a router ID for your assigned device. You then configure your device to
participate in a multi-level IS-IS network and verify operations using CLI operational
mode commands.
Step 1.1
Enter configuration mode and delete the configuration defined under the [edit
routing-instances] and [edit firewall] hierarchy levels. Next, remove
the application of the input filter assigned to the ge-0/0/4.11v interface.
Step 1.2
Navigate to the [edit routing-options] hierarchy level and remove the
defined routing table group and the application of that routing table group for
interface routes.
Step 1.3
devices.
Define the router ID on your router using the IP address assigned to the lo0 interface
as the input value.
Step 1.4
Navigate to the [edit interfaces] hierarchy level and add family ISO and the
Network Entity Title (NET) address to the lo0 interface. Pad each octet of the router
ID with leading zeros to form the system ID portion of the NET address. For instance,
if the routers lo0 address is 192.168.1.1, the system ID portion of the net address
will be 1921.6800.1001. The N-selector (SEL) field is 00.
Step 1.5
Add family iso to the transit interfaces.
Step 1.6
Navigate to the [edit protocols isis] hierarchy level and configure IS-IS
levels. Make interfaces lo0, ge-0/0/1 and ge-0/0/2 level 2 only. Refer to the
network diagram as necessary and remember to include lo0.0.
Step 1.7
Activate the configuration and issue the run show isis adjacency command.
Question: Which neighbor state is shown for the

listed interfaces?
Lab 82 IS-IS (Optional) www.juniper.net

Question: Which value is listed under the L (Level)
column?
Step 1.8
Issue the run show isis interface command to display IS-IS interface
details.
Question: Which interfaces are listed in the output?
Step 1.9
Issue the run show isis database command to display the IS-IS database
details.
Question: How many link-state protocol data units

(LSPs) exist in the IS-IS database?
Step 1.10
Display routes advertised to and received from IS-IS using the run show isis
route command.
Note
team in your pod finishes the previous step.
Step 1.11
Issue the run show route protocol isis command to view IS-IS routes
installed in the routing table.
Question: Which IS-IS routes exist in the routing

table?

Question: Why are the 172.20.66.0/30 and
172.20.77.0/30 routes not listed in the generated
output?
Step 1.12
Configure your device with a level 1 adjacency to the virtual router. Refer to the
network diagram for this lab for the area and interface details. Once it is configured,
activate the configuration changes and return to operational mode.
Step 1.13
Issue the show isis adjacency command to verify the current IS-IS adjacency
details.
Question: How many IS-IS adjacencies exist and

what are the states of those adjacencies?
Step 1.14
Issue the show isis database command to display the current IS-IS database.
Question: How many link-state protocol data units

(LSPs) exist in the IS-IS database now?
Question: Which command lists only level 2 entries

in the IS-IS database?
Step 1.15
Enter configuration mode and navigate to [edit protocols isis]. Issue the
save /var/tmp/working-isis.conf command to save the current IS-IS
configuration.

Part 2: Performing Basic IS-IS Troubleshooting
In this lab part, you perform basic IS-IS troubleshooting. First, you modify your
devices current configuration to make it incompatible with the attached virtual
router. You then enable IS-IS traceoptions to log protocol activity. Finally, you display
the traceoptions log to view the associated errors.
Step 2.1
Modify the ISO NET address to cause a mismatch with the virtual router.
Step 2.2
Activate the configuration change and issue the run show isis adjacency
command.
Question: How many IS-IS adjacencies does your

assigned device currently have?
Step 2.3
Navigate to [edit protocols isis] and define traceoptions for IS-IS so that
IS-IS errors write to a file named trace-isis. Include the detail option with the
error flag to capture additional details for the ISIS errors. Activate the
configuration change using the commit command.
Step 2.4
Issue the run show log trace-isis command to view the contents written to
the trace-isis trace file.

explain the current IS-IS adjacency issue?
Step 2.5
Navigate to [edit interfaces lo0 unit 0] and delete the incorrect NET
address and activate the correct address. Configure IS-IS Level 1 for simple
authentication with juniper as the password.
Step 2.6
Issue the run clear log trace-isis command to clear the contents of the
defined trace file. Wait a moment, then issue the run show log trace-isis
command to view any new entries in the trace file.

explain the current IS-IS adjacency issue?
Step 2.7
Issue the delete command and confirm the operation to delete the current IS-IS
configuration. Next, issue the load merge /var/tmp/working-isis.conf
command to load the configuration you saved earlier in this lab. Activate the
restored configuration and return to operational mode using the commit
and-quit command.
Step 2.8
Verify that the IS-IS adjacencies have returned to the Up state between your device
and the directly attached virtual router.
Question: Did the IS-IS adjacency with the directly

attached virtual router return to the Up state?

Appendix A: Lab Diagrams

A2 Lab Diagrams www.juniper.net

www.juniper.net Lab Diagrams A3






JUNOS Intermediate Routing-11a-Lab Guide PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

JUNOS Intermediate Routing-11a-Lab Guide PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Junos Intermediate Routing

High-Level Lab Guide

Worldwide Education Services

1194 North Mathilda Avenue

Course Number: EDU-JUN-JIR

Lab 2: Load Balancing and Filter-Based Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Lab 3: Open Shortest Path First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Lab 4: Border Gateway Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Lab 5: IP Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Lab 6: High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Lab 7: IPv6 (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Lab 8: IS-IS (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

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

www.juniper.net Course Overview v

vi Course Overview www.juniper.net

www.juniper.net Course Agenda vii

CLI and GUI Text

Style Description Usage Example

Courier New Console text:

Input Text Versus Output Text

Style Description Usage Example

Normal CLI No distinguishing variant. Physical interface:fxp0,

Defined and Undefined Syntax Variables

Style Description Usage Example

CLI Variable Text where variable value is policy my-peers

viii Document Conventions www.juniper.net

Education Services Offerings

www.juniper.net Additional Information ix

www.juniper.net Protocol-Independent Routing Lab 11

Part 1: Configuring and Monitoring Interfaces

Question: What is the management address

Lab 12 Protocol-Independent Routing www.juniper.net

Question: What are the Admin and Link states for

Question: Does the routing table display an entry for

Question: What are the route preferences for the

Question: Are any routes currently hidden?

www.juniper.net Protocol-Independent Routing Lab 13

Question: Are the ping tests successful?

Part 2: Configuring and Monitoring Static and Aggregate Routes

Question: Based on the network diagram, which IP

Question: Does the IP address associated with the

Question: What is the route preference of the

Lab 14 Protocol-Independent Routing www.juniper.net

Question: Does the ping operation succeed?

Question: Are both static routes active? What is the

Question: Does the ping operation succeed?

www.juniper.net Protocol-Independent Routing Lab 15

Question: Is the newly added aggregate route

Question: According to the route summary details

Question: Is the new aggregate route active? What

Question: What are the contributing routes for the

Question: Based on the next-hop type associated

Lab 16 Protocol-Independent Routing www.juniper.net

Part 3: Working with Routing Instances

Question: Which routing tables does the output

Question: Which routes are installed in the new

www.juniper.net Protocol-Independent Routing Lab 17

Question: Did the ping operation succeed?

Question: Did the ping operation succeed? What do

Lab 18 Protocol-Independent Routing www.juniper.net

Question: Were the interface and static routes from

Question: Do the ping operations succeed?

STOP Tell your instructor that you have completed Lab 1.