JUNOS Intermediate Routing-11a-Lab Guide PDF
JUNOS Intermediate Routing-11a-Lab Guide PDF
11.a
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
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.
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
Franklin Gothic Normal text. Most of what you read in the Lab Guide
and Student Guide.
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.
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.
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.
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.
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.
Step 1.8
Issue the show route command to view the current route entries.
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.
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.
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.
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.
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.
STOP Before proceeding, ensure that the remote team within your pod is
ready to begin Part 3.
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.
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.
Step 3.6
Add the routing-instance instance-a option to the command referenced
in the previous step.
Step 3.7
Attempt to ping the loopback address of the remote student device. Source the ping
operation from the instance-a routing instance.
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.
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.
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.
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.
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 monitor the effects of a load-balancing policy.
Configure and monitor FBF.
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
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.
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.
Step 1.5
Display the forwarding table entries for the same destination prefixes and answer
the question that follows.
Step 1.10
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).
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.12
Log in to the virtual router attached to your teams device using the login information
shown in the following table:
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.
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
Remember to reference the appropriate
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.
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.
Step 2.18
Return to the session opened to the virtual router and perform the ping test to the
Internet host again.
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.
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 monitor a multi-area OSPF network.
Perform basic OSPF troubleshooting.
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
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.
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.
Step 1.7
Issue the run show ospf database command to display the OSPF database
details.
Step 1.8
Display routes advertised to and received from OSPF using the run show ospf
route command.
Step 1.9
Associate a metric of 100 with the ge-0/0/2.0 interface and activate the change.
Note
Before proceeding, ensure that the remote
team in your pod finishes the previous step.
Step 1.10
Step 1.11
Issue the run show route protocol ospf command to view OSPF routes
installed in the routing table.
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.
Step 1.14
Issue the show ospf database command to display the current 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.
Note
Before proceeding, ensure that the remote
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.
Step 1.20
Issue the save /var/tmp/working-ospf.conf command to save the
current OSPF configuration.
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.
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.
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.
Step 2.6
Issue the run show ospf statistics command to verify any current error
counters.
www.juniper.net Open Shortest Path First Lab 37
Junos Intermediate Routing
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.
Step 2.9
Issue the run show ospf statistics command to verify the current error
counters.
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.
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.
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 monitor BGP.
Export aggregate routes to an EBGP peer.
Configure and apply a next-hop self policy.
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
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.
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.
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.
Step 1.7
Issue the run show route receive-protocol bgp neighbor command,
where neighbor is the loopback address of each IBGP peer.
Step 1.8
Issue the run show route advertising-protocol bgp neighbor
command, where neighbor is the loopback address of each IBGP peer.
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.
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.
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.
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.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.
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.
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.
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
diagram for the IP address of the virtual
router.
Step 3.1
Open a separate Telnet session to the virtual router.
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.
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.
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
Before proceeding, ensure that the remote
student team in your pod finishes the
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.
Overview
This lab demonstrates using the command-line interface (CLI) to configure and monitor a
generic routing encapsulation (GRE) tunnel.
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 monitor a GRE tunnel.
Use the defined GRE tunnel to merge two remote OSPF domains.
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
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.
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.
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.
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.
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.
Note
Before proceeding, ensure that the remote
student team in your pod finishes the
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.
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.
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
Before proceeding, ensure that the remote
student team in your pod finishes the
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.
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.
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.
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.
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.
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.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.
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.
Overview
This lab demonstrates how to configure and monitor some high availability (HA) features
using the command-line interface (CLI).
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 monitor graceful restart.
Configure and monitor the Bidirectional Forwarding Detection (BFD) protocol.
Configure and monitor the Virtual Router Redundancy Protocol (VRRP).
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
diagram for the IP address of the virtual
router.
Step 1.1
Open a separate Telnet session to the virtual router.
Step 1.3
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.
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
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.
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.
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
Before proceeding, ensure that the remote
student team in your pod finishes the
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
Remember to reference the appropriate
instance name when sourcing ICMP traffic
from a virtual router. The instance names
match the virtual router names listed on
the network diagram for this lab.
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.
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.
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.
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.
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
Before proceeding, ensure that the remote
student team in your pod finishes the
previous step.
Step 2.3
Issue the run show bfd session command to determine whether your student
device has any active BFD sessions.
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.
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.
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.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.
Note
Before proceeding, ensure that the remote
student team in your pod finishes the
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.
Step 3.6
Log in to the virtual router attached to your teams device using the login information
shown in the following table:
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
Remember to reference the appropriate
instance name when sourcing ICMP traffic
from a virtual router. The instance names
match the virtual router names listed on
the network diagram for this lab.
Step 3.8
From the virtual routers associated with your pod, ping the gateway address for each
virtual routers respective subnet.
Note
Remember to reference the appropriate
instance name when sourcing ICMP traffic
from a virtual router. The instance names
match the virtual router names listed on
the network diagram for this lab.
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
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.
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.
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.
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.
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 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.
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.
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.
Step 1.7
Variable references are used throughout the labs to distinguish various parts of CLI
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.
Step 1.10
Issue the show route table inet6 command to view the current IPv6 route
entries.
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.
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
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.
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.
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.
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).
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.
Step 3.3
Issue the show route protocol ospf3 to view the active OSPF routes in your
devices route table.
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.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.
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.
Step 4.11
Issue a run show route 192.168.z.1 command to see how our
encapsulated IPv6 packets are leaving the router.
STOP
Tell your instructor that you have completed Lab 7.
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.
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 monitor a multi-level IS-IS network.
Perform basic IS-IS troubleshooting.
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
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.
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.
Step 1.8
Issue the run show isis interface command to display IS-IS interface
details.
Step 1.9
Issue the run show isis database command to display the IS-IS database
details.
Step 1.10
Display routes advertised to and received from IS-IS using the run show isis
route command.
Note
Before proceeding, ensure that the remote
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.
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.
Step 1.14
Issue the show isis database command to display the current 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.
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.
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.
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.
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.