Professional Documents
Culture Documents
Routers
Release 5.3.1
This product includes the Envoy SNMP Engine, developed by Epilogue Technology, an Integrated Systems Company. Copyright 19861997,
Epilogue Technology Corporation. All rights reserved. This program and its documentation were developed at private expense, and no part of
them is in the public domain.
This product includes memory allocation software developed by Mark Moraes, copyright 1988, 1989, 1993, University of Toronto.
This product includes FreeBSD software developed by the University of California, Berkeley, and its contributors. All of the documentation and
software included in the 4.4BSD and 4.4BSD-Lite Releases is copyrighted by The Regents of the University of California. Copyright 1979,
1980, 1983, 1986, 1988,1989, 1991, 1992, 1993, 1994. The Regents of the University of California. All rights reserved.
GateD software copyright 1995, The Regents of the University. All rights reserved. Gate Daemon was originated and developed through
release 3.0 by Cornell University and its collaborators. Gated is based on Kirtons EGP, UC Berkeleys routing daemon (routed), and DCNs
HELLO routing protocol. Development of Gated has been supported in part by the National Science Foundation. Portions of the GateD software
copyright 1988, Regents of the University of California. All rights reserved. Portions of the GateD software copyright 1991, D. L. S.
Associates.
This product includes software developed by Maker Communications, Inc., Copyright 1996, 1997, Maker Communications, Inc.
Juniper Networks is a registered trademark of Juniper Networks, Inc. Broadband Cable Processor, ERX, ESP,G10, Internet Processor, JUNOS,
JUNOScript, M5, M10, M20, M40, M40e, M160, MRX, M-series, NMC-RX, SDX, ServiceGuard, T320, T640, T-series, UMC, and Unison are
trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks may be the
property of their respective owners. All specifications are subject to change without notice.
Introduction to Juniper Networks Routing, Student Guide Volume 1, Release 5.3
Copyright 2002, Juniper Networks, Inc.
All rights reserved. Printed in USA.
Revision History
Revision 1August 2002
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. 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
software 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
Please read these terms and conditions carefully before using the software. By using this software, you agree to be bound by the terms and
conditions of this license. If you do not agree with the terms of this license, promptly return the unused software, manual, and related
equipment and hardware (with proof of payment) to the place of purchase for a full refund.
Juniper Networks, Inc., and its suppliers grant to Customer a nonexclusive and nontransferable license to use the Juniper Networks software in
object code form solely on a single central processing unit owned or leased by Customer or otherwise embedded in equipment provided by
Juniper Networks. Customer may make one (1) archival copy of the software provided Customer affixes to such copy all copyright,
confidentiality, and proprietary notices that appear on the original. Except as expressly authorized above, Customer shall not copy, in whole or
in part, software or documentation; modify the software; reverse compile or reverse assemble all or any potion of the software; or rent, lease,
distribute, sell, or create derivative works of the software.
Customer agrees that the aspects of the licensed materials, including the specific design and structure of individual programs, constitute trade
secrets and copyright material of Juniper Networks. Customer agrees not to disclose, provide, or otherwise make available such trade secrets or
copyrighted material in any form to any third part without the prior written consent of Juniper Networks. Customer agrees to implement
reasonable security measures to protect such trade secrets and copyrighted material. Title to Software and documentation shall remain solely
with Juniper Networks.
This license is effective until terminated. Customer may terminate this license at any time by destroying all copies of Software, including any
documentation. This license will terminate immediately without notice from Juniper Networks if Customer fails to comply with any provision of
this license. Upon termination, Customer must destroy all copies of Software.
Software, including technical data, is subject to U.S. export control laws, including the U.S. Export Administration Act and its associated
regulations, and may be subject to export or import regulations in other countries. Customer agrees to comply strictly with all such regulations
and acknowledges that they have the responsibility to obtain licenses to export, re -export, or import Software.
This license shall be governed by and construed in accordance with the laws of the State of California, United States of America, as if performed
wholly within the state and without giving effect to the principles of conflict of law. If any portion hereof is found to be void or unenforceable, the
remaining provisions of this license shall remain in full force and effect. This license constitutes the entire license between the parties with
respect to the use of the Software.
Restricted rightsThe Juniper Networks software is provided to non-Department of Defense agencies with restricted rights, and its supporting
documentation is provided with limited rights. Use, duplicating, or disclosure by the U.S. government is subject to the restrictions as set forth in
subparagraph C of the Commercial Computer SoftwareRestricted Rights clause at FAR 52.227-19. If the sale is to a Department of Defense
agency, the U.S. governments rights in software, supporting documentation, and technical data are governed by the restrictions in the technical
data commercial items clause at DFARS 252.227-7015, and DFARS 227.7202.
Contents
Lab 1: Command-Line Interface Introduction
Lab 2: Initial Configuration and Platform Troubleshooting
Lab 3: Interface Configuration and Troubleshooting
Lab 4: RIP
Lab 5: Routing Policy
Lab 6: OSPF
Lab 7: IS-IS
Lab 8: BGP
Course Overview
The Internet Introduction to Juniper Networks Routers class is an instructor-led course
that covers the configuration and support of the protocols and features available on the
Juniper Networks platforms. This class is a combination of lecture and lab to allow
ample time for some good hands-on exposure to the JUNOS software configuration and
operational mode troubleshooting.
Objectives
After successfully completing this course, you should be able to:
Describe the basic functionality of the RIP routing protocol and how to configure it
on a Juniper Networks router;
Use the routing policy within JUNOS to control routes within the routing and
forwarding tables;
Describe the basic functionality of the OSPF routing protocol and how to configure it
on a Juniper Networks router;
Describe the basic functionality of the IS-IS routing protocol and how to configure it
on a Juniper Networks router; and
Describe the basic functionality of the BGP routing protocol and how to configure it
on a Juniper Networks router.
Intended Audience
The primary audiences for this course include the following:
Course Level
The Introduction to Juniper Network Routers (IJNR) class is an intermediate-level
course designed to provide a strong product knowledge foundation, and to prepare
students for the more advanced courses available in the Juniper Networks training
curriculum. Taking the IJNR-3 class is the preferred way of meeting the prerequisites
for the follow-on, IJNR-2 class (part number EDU-JUN-IJNR2).
Course Overview
Prerequisites
The IJNR Volume 1 prerequisites are:
!
TCP/IP basics;
While not required, familiarity with the command-line interface of a routing platform or
UNIX system is helpful.
IJNR-3 v
Course Overview
Course Agenda
Day 1
Product Positioning and Hardware Operation
JUNOS Software Architecture
The JUNOS Software CLI
Installation, Initial Configuration and Platform Troubleshooting
Overview of Interface Diagnostics and Troubleshooting
Day 2
Protocol Independent Routing Properties
RIP
Routing Policy
Day 3
OSPF Operation, Configuration, and Troubleshooting
IS-IS
BGP
vi IJNR-3
Course Overview
Additional Information
Technical Publications
You can print technical manuals and release notes directly from the Internet in a
variety of formats.
1. Go to http://www.juniper.net/.
2. On the left side of the page, click the Technical Documentation drop-down box
and click Software or Hardware.
3. Locate the specific 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.
IJNR-3 vii
Lab 1
Command Line Interface Introduction
Overview
In this lab you will be introduced to various CLI operational and configuration mode features
and capabilities.
By completing this lab you will perform the following tasks:
Operational:
Issue various operational mode CLI commands and use context sensitive help
Configuration:
clear
configure
file
Step 1.2
Type the following at the CLI prompt:
lab@host> c?
Possible completions:
clear
configure
What command could be used from the operational mode to display all show commands that
start with c?
Step 1.3
Type the following command at the CLI prompt:
lab@host> clear ?
Possible completions:
alarm
arp
bgp
firewall
Step 1.4
Experiment with command completion by entering the following:
lab@host> show i <enter>
^
'i' is ambiguous.
Possible completions:
. . . . .
interfaces
What other commands starting with i are listed when you type the above command?
Step 1.5
Type the following at the CLI prompt:
lab@host> show int<space>erfaces
Physical interface: fe-0/0/0, Enabled, Physical link is Down
Interface index: 9, SNMP ifIndex: 13
Link-level type: Ethernet, MTU: 1514, Speed: 100mbps, Loopback:
Disabled,
Source filtering: Disabled, Flow control: Enabled
Device flags
____________________________ Note__________________________
The use of Olives in the classroom might cause some of the interface related displays to
differ from those produced by M-series routers. We will point out these differences when
they are significant.
__________________________________________________________________
Verify that the CLI will not let you complete invalid commands by trying to enter the following
command:
lab@host> show ip interface brief
What happens when you try to enter this command? Where is the first syntax problem
detected?
Press <Ctrl-b>.
What happens to the cursor when you enter this keyboard sequence?
Press <Ctrl-f>.
What happens to the cursor when you enter this keyboard sequence?
Press <Ctrl-a>.
What happens to the cursor when you press this keyboard sequence?
Press <Ctrl-e>.
What happens to the cursor when you press this keyboard sequence?
Step 3.2
Enter the following commands:
lab@host> show interfaces | no-more
lab@host> show route
lab@host> show system users
These three commands are now stored in the CLI history buffer.
What happens when you:
If the arrow keys do not behave as expected, it is because the default ANSI terminal type
does not recognize the VT-100 sequences. This will be corrected in upcoming steps.
What CLI command do you think you would use to modify the screen length?
Step 4.2
Change the cli terminal type to vt100.
Does this have any effect on your ability to use the keyboard arrow keys to edit command
lines and to display your command history?
____________________________ Note__________________________
If the arrow keys are no longer working, it is because the CLI environment setting
performed above affected only your session, not the routers configuration. You will learn
how to make the terminal-type setting persistent in a subsequent portion of this lab.
_________________________________________________________________
Step 5.2
While the output is paused at the more prompt, try entering h.
What key would you enter to search the results of a command with multiple screen
output?
Step 5.3
Use the | and match functions to list all interfaces that are physically down:
lab@host> show interfaces extensive | match down
Can you think of a way to have JUNOS software count the number of interfaces that are
physically down? (As a hint, remember that the results of one pipe can be used as input
to another |).
What CLI command displays reference information on placing interfaces into loopback?
Step 7.2
Position yourself at the [edit interfaces fxp0] hierarchy:
[edit]
lab@host# edit interfaces fxp0
[edit interfaces fxp0]
lab@host#
Does the banner correctly indicate your new position in the hierarchy?
Step 7.3
Move to the [edit protocols ospf] portion of the hierarchy. This requires that you first
visit the root of the hierarchy, as you cannot jump directly between branches:
[edit interfaces fxp0]
lab@host# top
[edit]
lab@host# edit protocols
[edit protocols]
lab@host# edit ospf
[edit protocols ospf]
lab@host#
What commands could you now enter to reposition yourself at the [edit protocols]
portion of the hierarchy?
Step 8.2
Configure a non-existent interface:
[edit]
lab@host# edit interfaces ge-0/3/0
What command would you enter to enable flow control on this interface?
What would you now enter to display only the configuration of this interface?
____________________________ Note__________________________
It is a nice feature to be able to harmlessly configure an interface you have not yet
installed. Such configuration will not have any effect until the corresponding interfaces is
installed into the chassis.
_________________________________________________________________
Step 8.3
Add another address to the same logical unit, and use the tab-based auto-completion of
variables feature to easily remove it:
[edit]
[edit interfaces ge-0/3/0]
lab@host# set unit 0 family inet address 1.1.1.1/32
Step 8.4
Configure basic OSPF by entering the following commands at the [edit] hierarchy:
[edit]
lab@host# set protocols ospf area 0 interface all
[edit]
lab@host# set protocols ospf export test
This command has associated an export policy called test with the OSPF process. The
purpose of this step will become evident in subsequent lab steps.
Step 10.2
The candidate configuration will not commit as an undefined policy test is being referenced.
Remove the reference to this policy, and all should be well:
[edit]
lab@host# delete protocols ospf export
Once again try to commit your candidate configuration:
[edit]
lab@host# commit
commit complete
Step 10.2
Make a serious mistake:
[edit]
lab@host# delete interfaces
Now use the compare function to display differences between the active and candidate
configurations:
[edit]
lab@host# show | compare
Step 10.3
Commit your change. You now have a router with no interfaces!
[edit]
lab@host# commit
commit complete
[edit]
What command can you enter to quickly recover from such a mistake?
Step 11.2
View the saved file:
[edit]
lab@host# run file show file-name
Step 11.3
Load and commit the saved configuration file. Start by deleting your entire configuration:
[edit]
lab@host# delete
Delete everything under this level? [yes,no] (no) yes
[edit]
lab@host# show
What has happened to your configuration? Is the router still operating? (Hint: have you
committed this change yet?)
Now, save the day by loading and committing your saved configuration file:
[edit]
lab@host# load override file-name
load complete
[edit]
lab@host# show
[edit]
lab@host# commit
commit complete
STOP
Was there another way you could have restored your deleted candidate config that would
not have required the use of load and commit?
Lab 2
Initial Configuration and Platform Troubleshooting
Overview
In this lab you will load a factory default config and perform a typical initial system installation
configuration. You will then use various show commands to monitor the operation of the
router.
By completing this lab you will perform the following tasks:
Configuration:
Operation:
Send messages to other users and use the CLI to disconnect them
____________________________ Note__________________________
During the course of this lab you may disrupt the training centers existing Out Of Band
(OOB) network. It is imperative that you load and commit the lab sets reset file when
complete so that subsequent exercises are not adversely impacted.
_________________________________________________________________
____________________________ Note__________________________
The path shown is valid for JUNOS software version 5.0 and higher. If you router is
running 4.x, try using /etc/default.conf
_________________________________________________________________
What is the only thing configured on a Juniper Networks router when received from the
factory?
Step 1.2
Commit your new candidate configuration. (You may need to exit operational mode.)
[edit]
lab@host# commit and-quit
lab@host> exit
login:
root@host% cli
root@host>
Step 2.2
Set the systems host-name based on the label attached to your station:
[edit]
lab@host# set system host-name <name>
[edit]
lab@host#
______________________________Note _________________________
Until the router is rebooted it will retain the last host name committed. You may assume
that the router would have no host name if you took the time to reboot it.
__________________________________________________________________
Step 2.3
Assign the root password:
[edit]
root@host# edit system
[edit system]
Juniper Networks, Inc.
Step 2.4
Create an account for user lab and associate this user with the superuser (wheel) class:
[edit system]
root@host# set login user lab class superuser
[edit system]
root@host# set login user lab authentication plain-text-password
New password: lab
Retype new password: lab
[edit system]
Step 2.5
You may have noticed that your keyboard arrow keys no longer function. If you prefer the use
of arrow keys to the default Emacs key sequences, configure the console port to operate in
vt100 mode:
[edit system]
lab@host# set ports console type vt100
_____________________________ Note__________________________
As a result of this change, you will automatically be logged out on your next commit. This
will only happen once.
_________________________________________________________________
Step 2.6
You should now commit your changes, log out (if required), and then log back in as lab:
[edit system]
root@host# commit and-quit
commit complete
Exiting configuration mode
root@host> quit
root@host% exit
logout
host (ttyd0)
login: lab
Password:
Last login: Thu Jul 19 22:37:58 from 10.0.1.100
Lab 24 V5.3R1 Introduction to Juniper Networks Routers
. . .
lab@router>
Step 3.2
Show the routers system related configuration, commit the candidate configuration, and
return to operational mode:
[edit system]
lab@host# show
[edit system]
lab@host# commit and-quit
Step 3.3
Log out and then back in as the restricted user.
Are you able to enter configuration mode when logged in as this user?
Step 4.2
Configure fxp0 address properties:
[edit]
lab@host# edit interfaces fxp0
[edit interfaces fxp0]
lab@host# set unit 0 family inet address 10.0.1.x/24
_____________________________ Note__________________________
This configuration will not actually be used outside of this lab, so it does not really matter
what address you assign in this step. There is a slight chance that a duplicate addresses
will be detected, so be creative when you assign numeric values to the x variables in the
above step!
_________________________________________________________________
Step 4.3
Create a default route for the OOB network and ensure it is not installed in the forwarding
table or advertised by routing protocols. Use 10.0.1.254 as the next hop for this default
route:
lab@host# top
[edit]
lab@host# edit routing-options
[edit routing-options]
lab@host# set static route default next-hop 10.0.1.254 no-install noreadvertise
Step 4.4
Configure a backup-router to be used before the routing protocol daemon actually starts
(useful for catching SNMP sys-up traps after a reboot, for example). Once again, use
10.0.1.254 as the next hop for the default route and commit changes when done:
[edit routing-options]
lab@host# top
[edit]
lab@host# edit system
[edit system]
lab@host# set backup-router destination default 10.0.1.254
lab@host# commit
Part 5: Set the System Date and Time and View Your Initial Configuration
Step 5.1
Using the operational mode set command configure the systems date and time:
lab@router> set date ?
Possible completions:
<time>
____________________________ Note__________________________
You may find that an error is returned, even though the date is correctly set. This is the
result of the NTP Sever being unable to locate a local IP address. This error will not occur
if at least one operational interface, such as lo0, has an IP address assigned.
__________________________________________________________________
Step 5.2
Confirm that the date is correct, and review the entire configuration. Please ask the instructor
if you have any questions.
Verify that the date and time are correct:
lab@router> show system uptime
Review your configuration:
lab@router> show configuration
The JUNOS software CLI working in conjunction with the various daemons that reside in the
systems PFE can provide detailed information ranging from the chassis temperature to the
firmware and serial number of virtually all FRUs. Issue each of the following show chassis
commands and take a moment to interpret their output: (Dont forget that many have optional
<detail> and/or <extensive> switches.
cos
environment
firmware
fpc
hardware
mac-addresses
routing-engine
Are the FPCs listed as being on-line? What types of PICs are installed in your router?
What type of M-series router are you using? How much memory does the RE have?
boot-messages
buffers
connections
processes
reboot
software
statistics
storage
uptime
users
How many users are logged into your router? What are they doing?
Is your router providing any FTP services? Does it have any active TCP connections?
Have you discarded any ICMP packets due to fxp1 rate policing?
How long since your router was last rebooted? Who was the last person to have
configured it?
What is the device name of your routers flash memory? What about the rotating media?
____________________________ Note__________________________
If you are on an Olive, there is no flash memory so the / and /var devices will be
separate partitions on the same device
_________________________________________________________________
Try piping the result to match while searching for fail or down:
lab@host> show log messages | match fail
Step 9.2
Monitor the log in real-time: (Hint: use escape then q keys to suspend and resume console
output.)
lab@host> monitor start messages
In order to see some events that will be logged to the messages file, you can enter
configuration mode and issue a commit and-quit. The commit is not required to trigger
the monitor start command; it is used here to generate log activity.
Step 9.3
Examine the chassis log:
lab@host> show log chassisd
Step 9.4
Examine the cli log:
lab@router> monitor start cli
lab@router> show route
Was the CLI command correctly logged? (You may want to turn off the file monitor nowhitting the escape key followed by the q key will suspend the annoying screen output, or
you can issue a monitor stop)
Step 9.5
Determine what other log files exist:
lab@host> show log ?
What other logs does JUNOS software keep around for your reading pleasure?
Step 10.2
Determine who is logged in, and use the CLI to disconnect them:
lab@router> show system users
11:49AM
up
USER
TTY
FROM
lab
d0
LOGIN@
IDLE WHAT
10:41AM - -cli
pid
terminal
Terminal user is on
user
User to logout
immediately
interface-control
Interface process
mib-process
remote-operations
routing
sampling
snmp
SNMP process
soft
____________________________ Note__________________________
Restarting routing is rarely necessary, and it affects all routing protocols. If you are
experiencing a problem with a single protocol, it is better to try deactivating that protocol,
committing, and then doing a rollback 1. This will limit the effects to just the protocol
suspected of having problems.
__________________________________________________________________
Step 11.2
Reboot the router, and observe the boot sequence:
lab@router> request system reboot
Reboot the system ? [yes,no] (no) yes
How would you have shut the router down so that it could be safely powered off?
Step 12.2
Use the show version command after the reboot to confirm the new bits have been
correctly installed.
1 root
field
2023424 May 17
1999 rpd.core.0
-rw-rw----
1 root
field
1536000 May 17
1999 rpd.core.1
-rw-rw----
1 root
field
2781184 May 29
1999 rpd.core.2
-rw-rw----
1 root
field
-rw-rw----
1 root
field
8548352 Dec 28
2000 sampled.core.0
-rw-rw----
1 root
field
8511488 Dec 28
2000 sampled.core.1
-rw-rw----
1 root
field
8511488 Dec 28
2000 sampled.core.2
-rw-rw----
1 root
field
8511488 Dec 28
2000 sampled.core.3
-rw-rw----
1 root
field
8511488 Dec 29
2000 sampled.core.4
. . .
Your display should be similar to the example shown above, and here we can see that rpd
and sampled have both left core files.
Are there any core files on your router? Based on the dates, do these cores appear to be
recent?
Step 13.2
Enter the following command to look for RE and PFE related core files. These files are only
1
written when the system dump-on-panic and chassis dump-on-panic options are configured :
lab@Denver> file list /var/crash detail
total 6
drwxr-x---
2 root
wheel
512 Mar 23
1999 ./
drwxr-xr-x
21 root
wheel
512 Mar 23
1999 ../
-rw-r--r--
1 root
wheel
Your display should be similar to the example shown above. In this case, no RE or PFE core
files are present.
__________________________________________________________________
Step 13.3
Force RPD to dump a core.
The following is a hidden command so auto-completion will not kick in. By using the running
switch we do not cause rpd to shutdown.
We are doing this for demonstration purposes; you should first contact JTAC before issuing
this command on a production system:
lab@denver> request system core-dump routing running
Generating core dump for routing process using running method
Step 13.4
Escape to a shell and compress the core file:
____________________________ Note__________________________
Note: Exiting to the BSD shell is generally only performed under the guidance of JTAC;
serious damage can be done to your system if you make a mistake. The shell is not an
officially supported JUNOS software feature.
__________________________________________________________________
rpd.core.0
instmp.LXaFOZ
sampled.pkts
jbundle-5.0B2.1-domestic.tgz
vi.recover
preinstall
% gzip ./rpd.core.0
% ls
harry123
rpd.core.0.gz
instmp.LXaFOZ
sampled.pkts
jbundle-5.0B2.1-domestic.tgz
vi.recover
preinstall
Step 13.5
Return to the CLI, and FTP the core file to the Juniper Networks FTP server:
____________________________ Note__________________________
The following command will not complete successfully unless your station has a live
Internet connection with access to the Juniper Networks FTP server.
_________________________________________________________________
% exit
lab@denver> file copy /var/tmp/rpd.core.0.gz
ftp://ftp.juniper.net/1999-0101-001-rpd.core.0.gz
Sending ftp://10.0.1.100/1999-0101-001-rpd.core (90976 bytes): 100%
90976 bytes transferred in 0.0 seconds (8.78 MBps)
STOP
Lab 3
Interface Configuration and Troubleshooting
Overview
In this lab you will configure and test the operation of your routers interfaces.
By completing this lab you will perform the following tasks:
Configuration:
Operation:
____________________________ Note__________________________
The screen captures embedded in the labs are to be used as guides only. You should
always refer to the classroom specific lab diagrams for accurate information on the
specific interface types and router names deployed in class.
__________________________________________________________________
Classroom interface
name
Interface type
Olive
Mxx
router
fxp0,
fxp1,
fxp2
fxp0
ge-x/x/x
Gigabit Ethernet
fe-x/x/x
Fast Ethernet
mps0
so-x/x/x
SONET OC-3
en0
at-x/x/x
gre, ipip,
lo0, pime
gre, ipip,
lo0,
pime
What are the names and types of interfaces installed in your router?
____________________________ Note__________________________
All stations should use a VPI/VCI pair of 0.100 for all ATM interfaces in this lab.
__________________________________________________________________
[edit interfaces]
user@host# set interface-name atm-options vpi 0 maximum-vcs 200
user@host# set interface-name encapsulation atm-pvc
user@host# set interface-name unit 100 point-to-point
user@host# set interface-name unit 100 family inet address
10.0.x.x/24
user@host# set interface-name unit 100 vci 0.100
Step 2.2
Configure your routers lo0 interface:
While at the [edit interfaces] hierarchy, type the following command to configure the
loopback interface on your router:
[edit interfaces]
user@host# set lo0 unit 0 family inet address 192.168.x.x/32
Step 2.3
Check your work. Your configuration should be similar to this example taken from San Jose,
which is a M20 router:
[edit interfaces]
lab@SJ# show
at-0/2/0 {
atm-options {
vpi 0 maximum-vcs 200;
}
unit 100 {
vci 0.100;
family inet {
address 10.0.0.1/24;
}
}
Juniper Networks, Inc.
}
so-2/0/0 {
unit 0 {
family inet {
address 10.0.1.2/24;
}
}
}
ge-2/2/0 {
unit 0 {
family inet {
address 10.0.16.2/24;
}
}
}
. . .
lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
}
}
Step 2.4
When you are satisfied with your interface configuration, commit your changes and exit
configuration mode.
Step 3.2
If your pings are failing, check with the other team to see if they have finished their interface
configuration. Please notify the instructor if you are unable to ping all directly connected
neighbors.
Are all interfaces in use listed as both administratively and logically up?
Step 4.2
Use wildcard to display only interfaces of a certain type that are installed in a particular FPC:
lab@router> show interfaces fe-0/*
Use the pipe function to match on particular interfaces types that are physically down:
Step 4.3
Display more information about your interfaces:
lab@router> show interfaces brief
Step 4.4
Reset interface statistics:
lab@router> clear interfaces statistics all
Step 4.5
Display extensive interface information:
lab@router> show interfaces extensive
Step 4.6
Monitor real time traffic loads. During this step you may want to have a neighboring router
issue pings on your behalf, or open a telnet session to a neighboring router and do this
yourself:
____________________________ Note__________________________
The following commands will only function if your terminal session is configured for VT100
_________________________________________________________________
Lab 36 V5.3R1 Introduction to Juniper Networks Routers
STOP
You should pause at this point and wait for all students to complete the
previous steps.
What type of information can you glean from the following log message?
Step 5.2
Search through your system log for all messages related to a particular interface:
How could you count the number of physical transitions on a SONET interface?
disable keep-alives. PPP encapsulation will not work, even with keep-alives disabled, as the
IPCP and NCP protocols will fail to initialize resulting in the interface being declared down.
The following example is based on a POS link between Denver and Sao Paulo using
addresses 10.0.8.1 and 10.0.8.2 respectively and has Sao Paulo providing the remote
loopback.
We begin with the so-0/1/0 configuration from Sao Paulo:
[edit interfaces so-0/1/0]
lab@saopaulo# show
no-keepalives;
encapsulation cisco-hdlc;
sonet-options {
loopback remote;
}
unit 0 {
family inet {
address 10.0.8.2/24;
}
}
Step 6.2
We will now confirm that Denvers so-2/2/0 is still up, and verify the operation of the WAN by
pinging the remote address:
lab@Denver> show interfaces terse | match so-2/2/0
so-2/2/0
up
up
so-2/2/0.0
up
up
inet
10.0.8.1/24
Good, the interface is up, despite the remote loopback on Sao Paulo. Now for a local ping
test:
lab@Denver> ping 10.0.8.1 count 2
PING 10.0.8.1 (10.0.8.1): 56 data bytes
64 bytes from 10.0.8.1: icmp_seq=0 ttl=255 time=0.579 ms
64 bytes from 10.0.8.1: icmp_seq=1 ttl=255 time=0.449 ms
--- 10.0.8.1 ping statistics --2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.449/0.514/0.579/0.065 ms
And now for the remote ping that is intended to test the transmission facility:
Len
ID Flg
00 0054 406d
0 0000
01
cks
Src
01 553a 10.0.8.1
Dst
10.0.8.2
Len
ID Flg
00 0054 406f
0 0000
01
cks
Src
01 5538 10.0.8.1
Dst
10.0.8.2
--- 10.0.8.2 ping statistics --2 packets transmitted, 0 packets received, 100% packet loss
In fact, these are the expected results. The local ping never left the chassis, while the ping to
the far end is getting looped back and re-routed back out the so-2/2/0 interface until its TTL
finally expires. With the default TTL of 255, each one of these TTL expiration messages
indicates 254 or so successful line-rate receptions of this packet.
atm-options {
vpi 0 maximum-vcs 256;
}
unit 0 {
vci 0.100;
}
It should be noted that Montreals ATM interface is devoid of any IP related configuration.
Step 7.2
Denvers at-0/2/1 interface is also lacking IP related configuration:
[edit interfaces at-0/2/1]
lab@Denver# show
atm-options {
vpi 0 maximum-vcs 200;
}
unit 100 {
vci 0.100;
}
We now issue the atm-ping to validate the underlying ATM transmission facility:
lab@Denver> ping atm interface at-0/2/1 vci 100 segment count 5
53 byte oam cell received on (vpi=0 vci=100): seq=1
53 byte oam cell received on (vpi=0 vci=100): seq=2
53 byte oam cell received on (vpi=0 vci=100): seq=3
53 byte oam cell received on (vpi=0 vci=100): seq=4
53 byte oam cell received on (vpi=0 vci=100): seq=5
--- atmping statistics --5 cells transmitted, 5 cells received, 0% cell loss
In this example we used segment level F5 OAM cells. Considering that there is no ATM
switch between Denver and Montreal, would there have been any reason to use end-toend F5 OAM cells?
Step 8.2
To start the test, we issue the operational mode test command as shown:
lab@Denver> test interface t3-0/1/2 t3-bert-start
Once the test completes, the results can be displayed using show interface.
STOP
Lab 4
Routing Information Protocol
Overview
In this lab you will configure and monitor the operation of RIP version 2. You will start by
defining your stations static and aggregate routes.
By completing this lab you will perform the following tasks:
Configuration:
Operation:
Step 1.2
Commit your changes, and verify that the static routes are active:
lab@router# commit
[edit routing-options]
lab@denver# run show route protocol static
Step 2.2
By default JUNOS software enables RIP version 2. Enter the following command to display
the options available for RIP messages sent by your router:
[edit protocols]
lab@denver# set rip send ?
Possible completions:
broadcast
multicast
none
version-1
What command would you use to modify RIPs send behavior only for members of a
specific group?
Step 2.3
Issue the following command to display RIP group level options:
[edit protocols rip]
Lab 42 V5.3R1 Introduction to Juniper Networks Routers
+ apply-groups
data
+ export
Export policy
metric-out
> neighbor
Neighbor configuration
preference
What command could be used to set the metric of redistributed routes from the default
value of 1?
What command could be used to modify the default metric of 1 that is normally added to
received RIP routes?
Step 2.4
Your RIP configuration should be similar to this example taken from Denver:
[edit protocols]
lab@denver# show rip
group my-rip-group {
neighbor fe-0/0/1.0;
neighbor so-0/1/0.0;
neighbor so-0/1/1.0;
}
When satisfied with your RIP configuration, commit your changes and exit configuration mode.
Destination
Send
Receive
In
Neighbor
State
Address
Address
Mode
Mode
Met
--------
-----
-------
-----------
----
-------
---
mcast
both
so-0/1/1.0
Up
10.0.2.2
224.0.0.9
so-0/1/0.0
Up
10.0.0.2
224.0.0.9
mcast
both
fe-0/0/1.0
Up
10.0.8.1
224.0.0.9
mcast
both
Can you tell from this display that the router is running RIP Version 2?
Step 3.2
Display RIP statistics. Your display should be similar to the example from Denver shown
below:
lab@denver> show rip statistics
RIP info:
120s.
rts learned
rqsts dropped
resps dropped
so-0/1/1.0:
Counter
Total
Last 5 min
Last minute
-------
-----------
-----------
-----------
Updates Sent
Responses Sent
. . .
Step 3.3
Determine if RIP routes are present:
lab@denver> show route protocol rip
224.0.0.9/32
The one route listed is the multi-cast group address associated with RIP version 2.
Step 3.4
Confirm whether you are sending RIP routes to your neighbors:
lab@denver> show route advertising-protocol rip <your-ip-address>
Step 3.5
Configure RIP tracing and monitor the activity:
[edit protocols rip]
lab@denver# set traceoptions file rip
[edit protocols rip]
lab@denver# set traceoptions flag update detail
[edit protocols rip]
lab@denver# set traceoptions flag general detail
[edit protocols rip]
lab@denver# set traceoptions flag error detail
[edit protocols rip]
lab@denver# set traceoptions flag route detail
Is there any tracing activity? What does this output tell you?
It would seem from the tracing that RIP is processing send updates that result in nothing to
do and, that your router is not receiving any updates from neighbors.
STOP
Lab 5
Routing Policy
Overview
In this lab you will lean to write and manipulate JUNOS software routing policy. You will
complete this lab by writing and applying a policy to the RIP configuration left in place from the
last lab.
By completing this lab you will perform the following tasks:
Configuration:
Operation:
Routing Policy
Are there a large number of possible match conditions available for the from statement?
Step 1.2
Show your partially completed policy, and add the then action:
[edit policy-options policy-statement policy-name]
lab@denver# show
from protocol static;
[edit policy-options policy-statement policy-name]
lab@denver# set then ?
[edit policy-options policy-statement policy-name]
lab@denver# set then accept
Step 1.3
Display your completed policy. It should be similar to this example:
[edit policy-options policy-statement send-statics]
lab@denver# show
from protocol static;
then accept;
What would happen if you applied this policy as export to a routing protocol such as RIP?
Why would the same policy when applied as an import policy have no affect?
What would you have to do to make this policy also advertise your aggregate route?
Routing Policy
Step 1.4
Modify your policy to also accept aggregate routes:
[edit policy-options policy-statement policy-name]
lab@denver# set from protocol aggregate
Display your modified policy, and take note of how the static and aggregate protocols are
treated as a logical OR in this case.
Step 2.2
Create your policys second term:
[edit policy-options policy-statement new-policy-name]
lab@denver# set term 2 from protocol aggregate
[edit policy-options policy-statement new-policy-name]
lab@denver# set term 2 then metric 10
[edit policy-options policy-statement new-policy-name]
lab@denver# set term 2 then accept
Routing Policy
Step 2.3
Now to finish our policy with a third reject all term:
[edit policy-options policy-statement new-policy-name]
lab@denver# set term else-reject then reject
Step 2.4
Show your multi-term policy. It should be similar to this example:
[edit policy-options policy-statement new-policy]
lab@denver# show
term 1 {
from protocol static;
then {
metric 20;
accept;
}
}
term 2 {
from protocol aggregate;
then {
metric 10;
accept;
}
}
term else-reject {
then reject;
}
If you applied only this policy to BGP, what routes would your router be sending to your
peers? Would any BGP routes ever be sent?
Routing Policy
Step 3.2
After committing your changes, it is observed that BGP routes are still not being sent.
Why do you think your new term 3 is not having any effect?
Step 3.3
The problem is the ordering of your terms, and the fact that all routes are being rejected
before they can be evaluated by term 3. In this case we will use insert to place term 3
before term else-reject. Enter the following commands to resequence the order of the
terms in your policy:
[edit policy-options policy-statement new-policy-name]
lab@denver# insert term 3 before term else-reject
Once again view your policy. Does it now seem that BGP routes will be accepted?
Routing Policy
Step 3.4
Rename the last term in your multi-term policy to term 4:
[edit policy-options policy-statement new-policy-name]
lab@denver# rename term else-reject to term 4
Step 3.5
Copy your multi-term policy to a new name. The following command is entered at the [edit
policy-options] hierarchy:
[edit policy-options]
lab@denver# copy policy-statement new-policy-name to policy-statement
new
Display your policy stanza using show.
Step 3.6
Delete all policy statements:
[edit policy-options]
lab@denver# delete
Delete everything under this level? [yes,no] (no) yes
Reject your 192.168.x/24 static routes that do not encompasses your routers lo0
address
Step 4.2
Enter the following commands at the [edit policy-options policy-statement rip]
hierarchy to create the first term (accept direct routes)
[edit policy-options policy-statement rip]
Routing Policy
Step 4.3
Enter the following commands at the [edit policy-options policy-statement rip]
hierarchy to create the second term (accept RIP routes):
[edit policy-options policy-statement rip]
lab@denver# set term 2 from protocol rip
[edit policy-options policy-statement rip]
lab@denver# set term 2 then accept
Step 4.4
Enter the following commands at the [edit policy-options policy-statement rip]
hierarchy to create the third term (accept your 200.0.x/24 static route and your 192.168.x/24
static route that encompasses your routers lo0 address):
[edit policy-options policy-statement rip]
lab@denver# set term 3 from route-filter 200.0.x/24 exact accept
Step 4.5
Display your completed policy. It should now be similar to this example taken from Denver:
[edit policy-options policy-statement rip]
lab@denver# show
term 1 {
from protocol direct;
then accept;
}
term 2 {
from protocol rip;
then accept;
}
term 3 {
from {
route-filter 200.0.6.0/24 exact accept;
Routing Policy
Nowhere in the policy does it explicitly state that static routes should be rejected. What is
the default export policy for RIP with regard to static routes?
Are you now sending routes out your RIP interfaces? (Did you remember to commit your
changes?)
Step 6.2
Verify that you are now receiving RIP routes:
lab@router> show route protocol rip
Routing Policy
Step 6.3
Once again, monitor your RIP trace file:
lab@denver> monitor start rip
Do the results now show that routing updates are being sent and received?
Step 6.4
Verify that your policy meets all specified requirements. The following example shows the
result of Denvers policy in the absence of received RIP routes from other stations:
lab@denver> show route advertising-protocol rip 10.0.8.1
10.0.0.0/24
*[Direct/0] 02:59:25
> via fe-0/0/0.0
10.0.2.0/24
*[Direct/0] 02:59:25
> via fe-0/0/2.0
192.168.5.0/24
*[Static/5] 18:20:18
Discard
192.168.5.1/32
*[Direct/0] 01:00:46
> via lo0.0
200.0.6.0/24
*[Static/5] 03:16:40
Discard
Are there any 192.168.x/24s that do not encompass a given routers lo0 address?
Currently, there is a PR open regarding the show route receive-protocol rip not working (PR 17500)
Routing Policy
STOP
Could you have achieved the same results with 4 individual single term policies? Which
way do you feel is best?
How would you modify your policy so that the 200.0.x/24 static route was advertised with
a RIP metric that differed from the 192.168.x/24 static route?
Lab 6
OSPF
Overview
In this lab you will configure and monitor the operation of OSPF in both a single and multi-area
topology.
By completing this lab you will perform the following tasks:
Configuration part 1:
Operation part 1:
Use show commands to verify and troubleshoot OSPF single area operation
Configuration part 2:
Operation part 2:
OSPF
____________________________ Note__________________________
You must be careful to include the correct unit number for any interface that is not using
the default unit number of 0 (such as your ATM interfaces).
_________________________________________________________________
Obtain context sensitive help:
[edit protocols]
lab@router# set ospf area 0 interface <interface-name.unit> ?
Based on the resulting help screen, what command would you enter to set the metric of
an OSPF interface to 10?
Step 2.2
Your OSPF configuration should be similar to this example taken from Denver, which is a
Fast Ethernet equipped M5:
[edit protocols]
lab@denver# show ospf
area 0.0.0.0 {
interface fe-0/0/0.0;
interface fe-0/0/1.0;
interface fe-0/0/2.0;
}
When satisfied with your OSPF configuration, commit your changes and return to operational
mode.
As a shortcut you can specify, interface all, but you must be careful to go back and disable a M-series routers OOB
interface so it does not end up running OSPF inadvertently.
OSPF
What OSPF metric is associated with each of your interfaces? <Hint: you may need to use
the detail switch>
What hello and dead intervals are being used by your OSPF interfaces?
Step 3.2
Display OSPF adjacency status. Your display should be similar to this example taken from
Denver:
lab@Denver> show ospf neighbor
Address
Interface
State
ID
Pri
Dead
10.0.0.1
fe-0/0/0.0
Full
192.168.0.1
128
34
10.0.8.2
fe-0/0/1.0
Full
192.168.12.1
128
33
10.0.2.1
fe-0/0/2.0
Full
192.168.2.1
128
37
For a given Ethernet interface, can you determine if your router is the DR, BDR, or
DRother?
OSPF
Step 3.3
Examine the OSPF link state database (LSDB):
lab@router> show ospf database
In a nine node, single area network, how many router LSAs (type 1) should you have in
your database?
Do you see any Network, Network Summary or AS-External LSAs? Considering the
topology in use, Is this normal?
Step 3.4
5
Find your stations router LSA, and determine if all interfaces are being correctly reported :
lab@router> show ospf database router advertising-router <your-RID>
detail
Are all your OSPF interfaces being reported? Why is your lo0 address present when you
are not running OSPF on that interface?
Step 3.5
Determine the number of Designated Routers (DRs):
lab@router> show ospf database network
LSAs generated by your own station show an * when displayed in the database.
OSPF
For each LAN segment, there should be a DR. Based on the number of Network LSAs in
your database, how many LAN segments are in use in the lab?
Step 3.6
Display OSPF routes, and verify connectivity to all loopback addresses:
lab@router> show route protocol ospf
Or
lab@router> show route protocol ospf 192.168/16
Is there any tracing activity? What does this output tell you?
OSPF
Step 4.2
Clear your adjacencies and examine the system log:
Does anything get written to the main system log when OSPF adjacencies are cleared?
How might the previous command prove helpful when troubleshooting an intermittent
circuit problem?
Step 4.3
Flush the LSDB and watch as other routers refresh their entries. For best results, you should
enter the second multiple times (you may want to disable monitor output so you can watch the
LSAs get refreshed in peace):
lab@router> clear ospf database purge
lab@router> show ospf database
STOP
You should pause here and wait for all student teams to complete the
preceding steps.
OSPF
is still considered to be an OSPF interface, but no attempt will be made to establish and OSPF
adjacency.
Delete your existing single area OSPF configuration:
[edit protocols]
lab@router# delete ospf
Step 5.2
Configure multi-area OSPF by placing each of your interfaces into the correct area:
[edit protocols]
lab@router# set ospf area n interface <interface-name.unit>
Step 5.3
Mark interfaces that connect to routers in other areas (the skull and crossbones links) as
passive:
[edit protocols]
lab@router# set ospf area n interface <interface-name.unit> passive
Step 5.4
Obtain context sensitive help:
[edit protocols]
lab@router# set ospf area n ?
What command would you enter to configure an area so that the area functions as a stub
area?
OSPF
Step 6.2
Now apply your policy as export to OSPF:
[edit protocols]
lab@router# set ospf export policy-name
When done, your configuration should be similar to this example taken from a Fast Ethernet
equipped Denver:
[edit protocols]
lab@denver# show
ospf {
export stat;
area 0.0.0.3 {
interface fe-0/0/1.0;
}
area 0.0.0.0 {
interface fe-0/0/2.0;
interface fe-0/0/0.0;
}
}
Make sure to commit your changes when you are satisfied with your multi-area OSPF
configuration.
OSPF
Step 7.2
Display OSPF adjacency status:
lab@router> show ospf neighbor
Step 7.3
Examine the OSPF link state database (LSDB):
lab@router> show ospf database
Do you now see Summary LSAs? What type of router generates these?
Are AS-External LSAs now present? What type of router generates these?
Step 7.4
Display OSPF routes, and verify connectivity to all loopback addresses:
lab@router> show route protocol ospf
Or
lab@router> show route protocol ospf 192.168/16
OSPF
Step 7.5
Telnet to one of the ABRs and view the structure of its LSDB:
Explain why the ABRs indicate that they have generated multiple router LSAs?
What could be done to areas 1, 2, and 3 that would allow them to still generate ASexternal LSAs with out their having to receive AS-Externals LSAs generated in other
areas?
Step 7.6
Experiment with the remaining OSPF operational commands:
STOP
You should pause here and wait for all student teams to complete the
preceding steps.
STOP
Lab 7
IS-IS
Overview
In this lab you will configure and monitor the operation of IS-IS in single area Level 2 topology.
By completing this lab you will perform the following tasks:
Configuration part 1:
Configuration part 2:
Operation:
Use show commands to verify and troubleshoot IS-IS single area operation
IS-IS
____________________________ Note__________________________
Be careful to include the correct unit number for each of your interfaces.
_________________________________________________________________
Step 1.2
Configure your routers NET on the lo0 interface. Refer to the table below to obtain the correct
values for your station. In this lab we are basing the System ID portion of the NET on the
routers IP loopback address:
Router Name
Amsterdam
49.0001.0192.0168.2401.00
Denver
49.0001.0192.0168.0501.00
Hong Kong
49.0001.0192.0168.1601.00
London
49.0001.0192.0168.2801.00
Montreal
49.0001.0192.0168.0201.00
San Jose
49.0001.0192.0168.0001.00
Sao Paulo
49.0001.0192.0168.1201.00
Sydney
49.0001.0192.0168.0801.00
Tokyo
49.0001.0192.0168.2001.00
[edit interfaces]
lab@router# set lo0 unit 0 family iso address <iso-net-address>
Step 2.2
Obtain context sensitive help:
[edit protocols]
lab@router# set isis interface <interface-name.unit> level 2 ?
IS-IS
Based on the resulting help screen, what command would you enter to set the metric of a
level 2 IS-IS interface to 10?
Step 2.3
Your IS-IS configuration should now be similar to this example taken from Denver, which is
equipped with Fast Ethernet interfaces. Note that Denver is also configured to run OSPF area
0 on all of its interfaces. The reason for running OSPF and IS-IS simultaneously will become
evident in future lab steps. It should be noted that lo0 configuration is not required for OSPF,
but is necessary for proper IS-IS operation:
lab@denver# show
isis {
interface fe-0/0/0.0 {
level 1 disable;
}
interface fe-0/0/1.0 {
level 1 disable;
}
interface fe-0/0/2.0 {
level 1 disable;
}
interface lo0.0 {
level 1 disable;
}
}
ospf {
area 0.0.0.0 {
interface fe-0/0/0.0;
interface fe-0/0/1.0;
interface fe-0/0/2.0;
}
}
IS-IS
[edit]
lab@router# set protocols isis export policy-name
When satisfied with your IS-IS configuration, commit your changes and return to operational
mode.
For a given Ethernet interface, can you determine which router is the DIS?
What is the IS-IS hello and hold interval? <Hint: you might want to use the detail switch>
Step 4.2
Display your IS-IS adjacency status. Your display should be similar to the this example taken
from Denver:
lab@denver> show isis adjacency
IS-IS adjacency database:
Interface
System
L State
fe-0/0/0.0
SJ
2 Up
0:d0:b7:3f:b5:c
IS-IS
fe-0/0/1.0
SP
2 Up
20
0:d0:b7:3f:af:75
fe-0/0/2.0
MO
2 Up
0:d0:b7:3f:b4:ce
Step 4.3
Examine the IS-IS link state database (LSDB):
lab@router> show isis database
Some routers have generated multiple LSPs. What is the significance of the entries that
use a non-zero Pseudo node ID ? Hint: Value follows host name
Why do you see a single Level 1 LSP in the database generated by your own router,
didnt you disable IS-IS Level 1 on all your interfaces?
The single Level 1 LSP results from the fact that you disabled IS-IS Level 1 on the routers
interfaces, but not on the router itself. This LSP can never leave your router as a Level 1 LSP
since it can only be sent out a Level 1 interface. If its presence conflicts with the purest in
you, you can disable IS-IS level 1 on the router with the following command:
[edit]
lab@router# set protocols isis level 1 disable
Step 4.4
Find your stations LSP, and determine if all attached interfaces are correctly reported:
lab@router> show isis database <your-system-name.00-00> detail
JUNOS software supports dynamic hostname to ISO NET mapping using TLV 137 (defined in RFC 2763).
IS-IS
Step 4.5
Display only LSPs generated by Designated Intermediate Systems (DIS):
lab@router> show isis database | except 00-00
For each LAN segment, there should be a DIS. Based on the number of pseudonode
LSPs in your database, how many LAN segments are in use in the lab?
In a large network, you might find the following command easier than manually tabulating the
results of the last command:
lab@router> show isis database | except 00-00 | match -00 | count
Step 4.7
Display IS-IS routes, and verify connectivity to all loopback addresses:
lab@router> show route protocol isis
Or
lab@router> show route protocol isis 192.168/16
But wait, what route did your pings actually use, OSPF or IS-IS?
Because of global preference, the OSPF routes are preferred over the IS-IS routes. In the
previous command you should have seen that two routes exist to each remote loopback, and
that the OSPF route is preferred. This will be addressed in the next step.
IS-IS
192.168.12.1/32
Step 5.2
Set the preference of OSPF to 19 so that IS-IS Level 2 routes are preferred. Since all routers
should now have both OSPF and ISIS routes, this process should be non-disruptive and can
be performed incrementally.
If you have telnet access to the routers, you may want to open a separate telnet window and
perform remote ping testing while the cutover is made. There should be no disruption.
The follow configuration command is issued at the [edit] portion of the hierarchy:
[edit]
lab@router# set protocols ospf preference 19
Step 5.3
Commit your changes, and verify that IS-IS routes are now active:
lab@router> show route 192.168/16
IS-IS
Is there any tracing activity? What does this output tell you?
Step 6.2
Clear your IS-IS adjacencies:
lab@router> clear isis adjacency
Step 6.3
Rebuild the IS-IS Link State Database (LSDB):
lab@router> clear isis database
Step 6.4
Parse the system log for IS-IS related adjacency changes:
lab@router> show log messages | match "IS-IS Lost"
Are log entries written when an IS-IS adjacency changes state to down?
IS-IS
STOP
IS-IS
Lab 8
BGP
Overview
In this lab you will configure and monitor the operation of both IBGP and EBGP. You will also
write and apply routing policy to control the routes advertised by BGP.
By completing this lab you will perform the following tasks:
Configuration part 1:
Configure the IGP within your AS (either single area OSPF or Level 2 IS-IS)
Operation part 1:
Configuration part 2:
Operation part 2:
BGP
____________________________ Note__________________________
You must be careful to include the correct unit number for any interface that is not using
the default unit number of 0 (such as your ATM interfaces).
_________________________________________________________________
____________________________ Note__________________________
You must be careful to include the correct unit number for any interface that is not using
the default unit number of 0 (such as your ATM interfaces).
_________________________________________________________________
BGP
Step 2.4
Your IGP configuration should be similar to this example taken from Denver, which is a Fast
Ethernet equipped M5 configured for OSPF:
[edit protocols ospf]
lab@denver# show
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
interface fe-0/0/1.0 {
disable;
}
}
Note that the operator in this example has started with all interfaces in area 0, and has
specifically disabled the interfaces that should not be running OSPF. In this example, this
would be fxp0 and fe-0/0/1, as the former is the OOB management port and the latter is the
external interface that connects to AS 3.
Step 3.2
Configure IBGP peering sessions between loopback interfaces. The following commands are
entered at the [edit protocols bgp] hierarchy. You will begin by defining the ibgp peer
group:
[edit protocols bgp]
lab@router# set group ibgp type internal
Step 3.3
Now define each of your internal neighbors. The following command is repeated for each
IBGP neighbor:
[edit protocols bgp]
Juniper Networks, Inc.
BGP
Step 3.4
When complete, your IBGP peering configuration should be similar to this example taken from
Denver in AS 10:
Step 4.2
Now define each of your external neighbors. The following command is repeated for each
EBGP neighbor:
[edit protocols bgp]
lab@router# set group ebgp neighbor 10.0.x.x peer-as <as-#>
Step 4.3
When complete, your EBGP peer group should be similar to this example taken from
Amsterdam. Note that this station has two EBGP peers and that the peer-as has been
specified for each neighbor using a single EBGP group. If desired, the EBGP neighbors may
be placed into separate groups
[edit protocols bgp]
lab@amsterdam# show group ebgp
type external;
7
For stations with multiple EBGP peers, i.e., Hong Kong, you may define two separate EBGP peer groups, or use a
single peer group with neighbor specific peer-as configuration. The steps here illustrate the single peer group approach.
BGP
neighbor 10.0.24.1 {
peer-as 10;
}
neighbor 10.0.31.2 {
peer-as 3;
}
STOP
You should wait here until all student teams have completed the previous
configuration steps.
Step 5.2
Confirm that you have routes to all the loopback addresses within your AS:
lab@router> show route 192.168/16
Are all the loopback addresses for the routers in your AS listed?
____________________________ Note__________________________
Because your IBGP sessions rely on a functional IGP, you should not proceed until you
have confirmed that your AS IGP is operational. Please check with the instructor if you
are experiencing IGP problems.
__________________________________________________________________
BGP
Tot Paths
Pending
inet.0
inet.2
Peer
AS
InPkt
State|#Active/Received/Damped...
OutPkt
OutQ
192.168.0.1
0/0/0
10
11
13
5:16 0/0/0
192.168.2.1
0/0/0
10
2:36 0/0/0
51 0/0/0
10.0.8.2
0/0/0
For each BGP session, you should see an indication that 0 routes have been received, that 0
routes are active, and that 0 routes have been suppressed due to damping. This is indicated
by the 0/0/0 entries in the example shown above. In essence this indicates that you have
established BGP sessions, but that you are not receiving any NLRI over them.
Step 6.2
Confirm whether any BGP routes exist:
lab@router> show route protocol bgp
BGP
Thinking back on the default policy for BGP, should this be the expected result? Why or
why not?
Step 6.3
Show BGP group related information:
lab@router> show bgp group
How many BGP sessions have been established in each of your groups?
Step 6.4
Show BGP neighbor specific information:
lab@router> show bgp neighbor
What NLRI has been negotiated for this session? Does the peer support BGP refresh?
For a particular neighbor, can you tell which peer initiated the TCP connection?
BGP
Step 7.2
Commit your changes, return to operational mode, and monitor the BGP trace file:
[edit protocols bgp]
lab@router# commit and-quit
commit complete
lab@router> monitor start bgp
Step 7.3
Perform a soft clear on one of your IBGP sessions:
lab@router> clear bgp neighbor 192.168.x.x soft
The soft clear uses the BGP refresh capability to request that a peer readvertise all of its
NLRI without tearing down the BGP connection.
According to the tracing output, did the soft clear tear down the BGP session?
Step 7.4
Clear an IBGP session:
lab@router> clear bgp neighbor 192.168.x.x
Lab 88 V5.3R1 Introduction to Juniper Networks Routers
BGP
You will need to monitor the trace output for at least 30 seconds before proceeding.
Step 8.2
Now apply your policy as export to the IBGP peer group:
[edit]
lab@router# set protocols bgp group ibgp export static-policy-name
Send a single aggregate for all the 192.168.x/24 prefixes owned by your AS
Redistribute OSPF or IS-IS routes (to allow inter-AS traceroutes between lo0
addresses)
Your policy should not alter the default BGP policy for route advertisements received
from neighboring ASs, and no /32 interface routes owned by your AS should be
leaked.
BGP
You will begin defining a single aggregate that represents all the 192.168.x/24 addresses
8
assigned to your AS :
[edit routing-options]
lab@router# set aggregate route 192.168.x/21
Step 9.2
Now write one or more policies that will achieve the requirements listed above. There are
numerous ways to meet these requirements using routing policy. This example policy from
Denver, which is configured with OSPF as the IGP, is just one possible solution.
It should be noted that because this policy does not advertise direct routes, inter-Autonomous
System traceroutes that are sourced from physical interface may fail and/or display hop timeouts. It is therefore required that inter-AS traceroutes be conducted between lo0 addresses
through the use of the source option. Also, the OSPF (or IS-IS) routes that are present in
one router will be direct routes in the routers that source the OSPF advertisements, so you
should not expect to see the same OSPF (IS-IS) routes advertised by all stations within your
AS:
lab@router# show policy-options policy-statement ebgp
term 1 {
from {
route-filter 192.168.0.0/21 longer;
}
then reject;
}
term 2 {
from protocol aggregate;
then accept;
}
term 3 {
from {
protocol static;
route-filter 200.0.6.0/24 exact;
}
then accept;
}
term 4 {
from {
protocol ospf;
}
8
All networks in this lab should configure a 192.168.x/21 aggregate, with x being the numerically lowest 192.168
addresses assigned to your AS.
BGP
then accept;
}
Step 9.3
When done with your EBGP policy, apply it as export policy to the EBGP peer group:
[edit]
lab@router# set protocols bgp group ebgp export policy-name
Step 10.2
Verify the IBGP export policy of your IBGP peers:
lab@router> show route receive-protocol bgp 192.168.x.1
Or
lab@router> show route protocol bgp aspath-regex "()"9
Are you receiving the /24 static routes from all your internal peers?
Are your IBGP peers sending you any aggregate or 10.0.x/24 routes?
Step 10.3
Verify your EBGP export policy:
9
By searching for BGP routes with an empty AS-path, you will display only those routes learned within your own
autonomous system.
BGP
Nexthop
MED
Lclpref AS path
10.0.1.0/24
self
192.168.0.0/21
Self
200.0.3.0/24
Self
200.0.4.0/24
Self
200.0.6.0/24
Self
____________________________ Note__________________________
Note that Denver is not advertising the 10.0.0/24 and 10.0.2/24 subnets because these
are considered direct routes on Denver. In contrast, Montreal should learn the 10.0.0/24
route through OSPF, and should therefore be sending this prefix in its EBGP
advertisements to Amsterdam.
_________________________________________________________________
Are you sending any 192.168.x/24 routes that are owned by your AS?
Is there a single aggregate for the 192.168.x/24 address block assigned to your AS?
Are the 200.0.x/24 static routes associated with the routers in your AS present?
Are the 10.0.x/24 OSPF (or IS-IS) routes in your router being sent?
BGP
Step 10.4
Verify your neighbors EBGP export policy:
lab@router> show route receive-protocol bgp 10.0.x.x
____________________________ Note__________________________
If you have detected problems with your policy, please correct them before proceeding.
Ask the instructor for assistance with your policy as needed.
__________________________________________________________________
Step 10.5
Examine BGP routes in your routing table:
lab@router> show route protocol bgp
Use the detail and extensive switches to display additional information such as the
presence of communities:
lab@router> show route protocol bgp detail
Do any of the routes have community information? Has the MED been set?
Step 10.6
Verify proper BGP operation by conducting inter-Autonomous System traceroutes to the
loopback addresses of remote routers. You must source the traceroutes from your routers lo0
address:
lab@router> traceroute 192.168.xx.1 source 192.168.xx.1
You may find that some traceroutes work, while others return errors like the one shown below:
lab@denver> traceroute 192.168.24.1
traceroute to 192.168.24.1 (192.168.24.1), 30 hops max, 40 byte
packets
traceroute: sendto: No route to host
1 traceroute: wrote 192.168.24.1 40 chars, ret=-1
BGP
These reachability problems will be resolved in the next part of this lab.
STOP
You should pause here and wait for all student teams to complete the
preceding steps.
Why do you think they are hidden? Hint: Use the detail switch for additional information.
Step 11.2
The routes are being hidden, because the advertised next hop is considered unreachable by
your router. This is a very common problem, and the two most common fixes are:
Either of these approaches will work for us; the former involves modification of your IBGP
export policy while the latter involves modification to your IGP (either IS-IS or OSPF in this
case).
It is up to you to decide which approach you want to use. An example IBGP export policy that
sets next-hop-self is shown below for your reference.
lab@denver# show
policy-statement stat {
term 1 {
from protocol static;
then accept;
}
term 2 {
then {
Lab 814 V5.3R1 Introduction to Juniper Networks Routers
BGP
next-hop self;
}
}
Step 11.3
Verify that all routes are now usable:
Step 11.4
Observe the effects of the JUNOS software BGP active route selection process by locating a
BGP route that has at least two valid paths:
lab@router> show route protocol bgp detail
STOP
Based on the information displayed, can you explain why the active path was chosen over
an alternative path?
BGP