Sie sind auf Seite 1von 102

Introduction to Juniper Networks Routers

Introduction to Juniper Networks Routers Release 5.3.1 Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA

Release 5.3.1

Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA

408-745-2000

www.juniper.net

Course Number: EDU-JUN-IJNR3

Lab Guide: Volume 1

This product includes the Envoy SNMP Engine, developed by Epilogue Technology, an Integrated Systems Company. Copyright © 1986–1997, 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 Kirton’s EGP, UC Berkeley’s routing daemon (routed), and DCN’s 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 1—August 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 rights—The 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 Software—Restricted Rights clause at FAR 52.227-19. If the sale is to a Department of Defense agency, the U.S. government’s 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:

Configure, install, and troubleshoot M-series routers;

Perform interface and transmission line troubleshooting;

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:

Personnel who are unfamiliar with Juniper Networks router configuration;

Internet engineers; and

Network operations center engineers.

The secondary audiences for this course include the following:

Juniper Networks and partner sales representatives;

Juniper Networks and partner systems engineers; and

Juniper Networks employees (such as hardware engineers, software engineers, TAC engineers).

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).

Prerequisites

The IJNR Volume 1 prerequisites are:

! TCP/IP basics;

Course Overview

! Link-state routing protocols, including a familiarity with either OSPF or IS-IS;

! Operation of BGP4 and knowledge of the BGP4 mandatory attributes; and

! General interdomain routing issues.

While not required, familiarity with the command-line interface of a routing platform or UNIX system is helpful.

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

Additional Information

Course Overview

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.

Juniper Networks Support

For technical support, contact Juniper Networks at support@juniper.net, or at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the United States).

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

View and interpret CLI error messages

Learn CLI keyboard sequences

Modify the CLI environment

Use CLI features to navigate and search through command output

Use the on-line help features

Perform basic configuration and commit your configuration

Configuration:

Navigate and view the configuration hierarchy

Configure a system service, an interface, and basic OSPF

Run operational commands from within the configuration mode

Commit your candidate configuration and use rollback

Save and load configuration files

Part 1: Entering Commands and getting Context Sensitive Help

Step 1.1

Log in to the router with the username “lab” using a password of “lab”. At the CLI prompt, enter “?”. Some of the following commands should be displayed:

lab@host> ?

Possible completions:

Command Line Interface Introduction

clear

Clear information in the system

configure

Manipulate software configuration information

file

Perform file operations

List a few of the remaining commands below:

Step 1.2

 

Type the following at the CLI prompt:

lab@host> c?

 

Possible completions:

clear

Clear information in the system

configure

Manipulate software configuration information

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

Clear address-resolution information

bgp

Clear BGP information

firewall

Clear firewall counters

List a few of the remaining commands:

Step 1.4

Experiment with command completion by entering the following:

lab@host> show i <enter>

^

'i' is ambiguous.

Possible completions:

.

.

.

.

.

interfaces

Command Line Interface Introduction

Show interface information

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

Interface flags: Hardware-Down SNMP-Traps

: Present Running Down

.

lab@host>

.

.

.

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.

What interfaces are displayed with the show interfaces command?

List some of the specific information displayed for an interface.

Command Line Interface Introduction

Part 2: CLI Error Messages

Step 2.1

Type the following command:

lab@host> clear route

What message does the router display when you enter this command? What do you suppose it means?

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?

Part 3: Keyboard Sequences

Step 3.1

From the CLI prompt, enter the following commands:

lab@host> show interfaces <do not press enter>

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?

Command Line Interface Introduction

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:

Enter <Ctrl-p > twice?

Press <Ctrl-n > twice?

Use the up and down arrows?

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.

Part 4: Modify the CLI Environment

Step 4.1

Using the operational mode set command you can modify the CLI environment for your login session. Enter the following command to view the CLI environment options that can be modified in operational mode:

lab@host> set cli ?

Command Line Interface Introduction

What types of options are displayed?

What CLI command do you think you would use to modify the screen length?

What CLI command do you use to modify the CLI prompt?

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?

Logout and then log back into your router.

Do the arrow keys still function as before?

Note

If the arrow keys are no longer working, it is because the CLI environment setting performed above affected only your session, not the router’s configuration. You will learn how to make the terminal-type setting persistent in a subsequent portion of this lab.

Part 5: Navigating Command Output

Step 5.1

Command output might exceed one full screen. For example, the show interface detail command displays lots of information about the router’s interfaces:

lab@host> show interfaces detail

What happens when you press the space bar?

What happens when you press the enter key?

Command Line Interface Introduction

What happens when you press the “ b ” key?

What happens when you press the “ u ” key?

Step 5.2

 

While the output is paused at the “more” prompt, try entering “h”.

What type of information is displayed?

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

Are any of your interfaces listed as “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 “|”).

Command Line Interface Introduction

Part 6: Online Documentation

Step 6.1

A large portion of the JUNOS software documentation is available directly from the CLI. High- level topics can be retrieved using the help topic command while detailed configuration related information is made available with the help reference command.

Use the help reference command along with the CLI question-mark operator to find detailed information about interface loopbacks:

What CLI command displays reference information on placing interfaces into loopback?

Part 7: Navigate Configuration Hierarchy and View Candidate Configuration

Step 7.1

Enter configuration mode and view the existing configuration:

lab@host> conf<space>igure

What happened to your prompt?

According to the prompt, what is your position in the configuration hierarchy?

Show the current configuration:

[edit]

lab@host# show

Show only the interface portion of your configuration:

lab@host# show int<space>erfaces

Was only the interface related information shown?

Command Line Interface Introduction

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?

What is the result of a show command now?

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?

Command Line Interface Introduction

Part 8: Configure a System Service, an Interface, and basic OSPF

Step 8.1

 

Position yourself at the root of the configuration hierarchy, and enable the telnet service:

[edit]

 

lab@host# set system services telnet

What other system services can you configure?

Step 8.2

 

Configure a non-existent interface:

[edit]

 

lab@host# edit interfaces ge-0/3/0

[edit interfaces ge-0/3/0]

lab@host# set unit 0 family inet address 10.0.1.100/24

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

[edit interfaces ge-0/3/0]

Command Line Interface Introduction

lab@host# delete unit 0 family inet address 1.<tab>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.

Part 9: Run Operational Mode Commands From Within Configuration

Step 9.1

Try to display the status of chassis alarms with the show chassis alarms operational command while parked at the [edit interfaces ge-0/3/0] hierarchy:

[edit interfaces ge-0/3/0]

lab@host# show chassis

^

syntax error.

Now try preceding the operational command, show chassis alarms with the word “run”.

Are the results any better?

Part 10: Commit Your Candidate Configuration and Use Rollback To Recover From Mistakes

Step 10.1

The changes you have made to the configuration are not yet active. Try to commit your candidate configuration; your results should be similar to the example below:

[edit]

lab@host# commit

Command Line Interface Introduction

Policy error: Policy test referenced but not defined

error: configuration check-out failed

What is preventing your candidate from becoming the active configuration?

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

Are any differences noted?

Step 10.3

Commit your change. You now have a router with no interfaces!

[edit]

lab@host# commit

commit complete

[edit]

lab@host# run show interfaces terse

Command Line Interface Introduction

What command can you enter to quickly recover from such a mistake?

Did you remember to commit the rollback?

Part 11: Save and Load Configuration Files

Step 11.1

 

You will now save a copy of your modified configuration to your home directory. Enter the following command at the [edit] hierarchy:

[edit]

 

lab@host# save file-name

Wrote 82 lines of configuration to 'file-name'

Step 11.2

 

View the saved file:

[edit]

 

lab@host# run file show file-name

What was the purpose of prefacing the command with run?

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?)

Command Line Interface Introduction

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

Has your configuration been restored?

[edit]

lab@host# commit

commit complete

Was there another way you could have restored your deleted candidate config that would not have required the use of load and commit?

would not have required the use of load and commit ? S T O P Tell

STOP Tell your instructor that you have completed lab 1.

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:

Load a factory config

Set the date and time

Set host-name, assign a root password and create a “lab” account

Create a restricted “operator” account

Configure Out Of Band management and enable remote access

Log all CLI commands

Operation:

Use show chassis commands to verify the router’s operation

Use show system commands to determine general system status

Examine the system and chassis logs

Send messages to other users and use the CLI to disconnect them

Restart software processes/reboot the router

Upgrade/downgrade JUNOS software (optional)

Handle core files for submission to JTAC (optional)

Restore and commit the default reset file

Initial Configuration and Platform Troubleshooting

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 set’s “reset” file when complete so that subsequent exercises are not adversely impacted.

Part 1: Loading the Factory Default Configuration

Step 1.1

Log in to the router with the username “lab” using a password of “lab”. Enter configuration mode and enter the following command to load a default configuration:

[edit]

lab@host# load override /packages/mnt/jbase/sbin/install/default- juniper.conf

load complete

[edit]

lab@host# show

system {

syslog {

user * {

any emergency;

}

file messages {

any notice;

authorization info;

}

}

}

Your configuration should now be similar to the example shown above.

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

Initial Configuration and Platform Troubleshooting

Commit your new candidate configuration. (You may need to exit operational mode.)

[edit]

lab@host# commit and-quit

lab@host> exit

login:

Part 2: Configure Host-name, Root Password and “lab” Account

Step 2.1

 

Log into the router as “root”, and start the CLI:

host (ttyd0)

login: root

Last login: Fri Jul 27 23:50:57 on ttyd0

--- JUNOS 5.0R1.4 built 2001-08-14 23:14:13 UTC

Terminal type? [vt100] <enter>

root@host% cli

root@host>

Step 2.2

 

Set the system’s 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]

Initial Configuration and Platform Troubleshooting

root@host# set root-authentication plain-text-password

New password: <password>

Retype new password: <password>

[edit system]

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@router>

Part 3: Create a Restricted User Account

Initial Configuration and Platform Troubleshooting

Step 3.1

 

Enter the following commands to create a restricted user account with view permissions only:

[edit system]

lab@host# set login user restricted class view-only

[edit system]

lab@host# set login user restricted authentication plain-text- password

New password: <lab>

Retype new password: <lab>

[edit system]

lab@host# set login class view-only permissions view

Step 3.2

 

Show the router’s 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?

Part 4: Configure OOB Management and Remote Access

Step 4.1

Log back in as user “lab”, and enable the telnet service:

[edit]

Initial Configuration and Platform Troubleshooting

lab@host# set system services telnet

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 no- readvertise

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

Initial Configuration and Platform Troubleshooting

Part 5: Set the System Date and Time and View Your Initial Configuration

Step 5.1

 

Using the operational mode set command configure the system’s date and time:

lab@router> set date ?

Possible completions:

<time>

New date and time (YYYYMMDDhhmm.ss)

lab@router> set date 200108281720

Tue Aug 28 17:20:00 UTC 2001

 

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

Part 6: Log All CLI Commands

Step 6.1

Set the system log to log all CLI commands and commit your changes:

[edit system syslog]

lab@router# set file cli interactive-commands any

[edit system syslog]

lab@router# commit and-quit

You will examine the contents of the “cli” log in subsequent lab steps.

Initial Configuration and Platform Troubleshooting

Part 7: Use Show Commands To Verify Proper Operation

Step 7.1

Note

Olives do not support any of the following show chassis commands. If you are using an Olive you should refer back to the class handouts for example screen captures of the following commands and skip to the next part.

The JUNOS software CLI working in conjunction with the various daemons that reside in the system’s 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: (Don’t forget that many have optional <detail> and/or <extensive> switches.

lab@router> show chassis ?

Possible completions:

alarms

Show alarm status

cos

Show CoS information

environment

Show environmental status

firmware

Show firmware version information

fpc

Show flexible port concentrator status

hardware

Show hardware inventory information

mac-addresses

Show MAC addresses

routing-engine

Show Routing Engine status

Are any alarms active?

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?

How can you tell if your router is running hot?

Initial Configuration and Platform Troubleshooting

Part 8: Use Show System Commands

Step 8.1

The JUNOS software CLI can display a wealth of information about the state of the JUNOS software environment. Issue each of the following commands and take a moment to analyze the resulting output:

lab@router> show system ?

Possible completions:

audit

Show filesystem MD5 hash & permissions

boot-messages

Show boot time messages

buffers

Show buffer statistics

connections

Show system connection activity

processes

Show the process table

reboot

Show any pending halt/reboot requests

software

Show loaded JUNOS extensions

statistics

Show protocol statistics

storage

Show local storage data

uptime

Show time since system and processes started

users

Show users currently logged into the system

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?

Initial Configuration and Platform Troubleshooting

What is the device name of your router’s 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

Are you low on disk space?

Part 9: Analyze System Logs

Step 9.1

 

Display the system log file, and jump to the end by using <cntl-e>:

lab@host> show log messages

Does the log contain anything interesting?

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.

Initial Configuration and Platform Troubleshooting

Were log messages displayed on your screen?

Turn off log file monitoring:

lab@host> monitor stop

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 now- hitting 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?

Part 10: Send Messages And Disconnect Users

Step 10.1

Send a message to all users currently logged into your router:

lab@router> request message all

Enter message [Use ^D to end the message]

<Sample message>

Did you receive your message?

Initial Configuration and Platform Troubleshooting

Step 10.2

Determine who is logged in, and use the CLI to disconnect them:

lab@router> show system users

11:49AM up 4:06, 1 user, load averages: 0.02, 0.03, 0.00

USER

TTY

FROM

LOGIN@ IDLE WHAT

lab

d0

-

10:41AM - -cli

Now, disconnect yourself:

lab@router> request system logout ?

Possible completions:

<[Enter]>

Execute this command

pid

Management (MGD) process id for user

terminal

Terminal user is on

user

User to logout

|

Pipe through a command

lab@router> request system logout terminal d0 user lab

Did you get logged out?

Part 11: Restart Software Processes and Reboot The Router

Step 11.1

Use the CLI to restart various software processes:

lab@router> restart ?

Possible completions:

gracefully

Gracefully restart the daemon

immediately

Immediately restart (SIGKILL) the daemon

interface-control

Interface process

mib-process

SNMP MIB-II process

remote-operations

Remote operations process

Initial Configuration and Platform Troubleshooting

routing

Routing protocol process

sampling

Traffic sampling control process

snmp

SNMP process

soft

Soft reset (SIGHUP) the daemon

lab@router> restart routing

Routing protocol daemon started, pid 845

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

shutdown: [pid 988]

Shutdown NOW!

How would you have shut the router down so that it could be safely powered off?

Part 12: Upgrade JUNOS software Using Jbundle (Optional)

Step 12.1

 

Your instructor will inform you as to whether you should perform this step. If told to do so, enter the following commands using the jbundle specified by your instructor:

lab@router> request system software add <bundle-name> reboot

Step 12.2

Use the show version command after the reboot to confirm the new ‘bits” have been correctly installed.

Initial Configuration and Platform Troubleshooting

Part 13: Handle Core Files For Submission To JTAC (optional)

Step 13.1

 

Enter the following command to look for daemon related core files:

lab@Denver> file list /var/tmp detail total 186468

.

.

.

-rw-rw----

1 root

field

2023424 May 17 1999 rpd.core.0 1536000 May 17 1999 rpd.core.1 2781184 May 29 1999 rpd.core.2 1507328 Jul 31 16:28 rpd.core.3 8548352 Dec 28 2000 sampled.core.0 8511488 Dec 28 2000 sampled.core.1 8511488 Dec 28 2000 sampled.core.2 8511488 Dec 28 2000 sampled.core.3 8511488 Dec 29 2000 sampled.core.4

-rw-rw----

1 root

field

-rw-rw----

1 root

field

-rw-rw----

1 root

field

-rw-rw----

1 root

field

-rw-rw----

1 root

field

-rw-rw----

1 root

field

-rw-rw----

1 root

field

-rw-rw----

1 root

field

.

.

.

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 written when the system dump-on-panic and chassis dump-on-panic options are configured 1 :

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

5 Aug 14 23:30 minfree

Your display should be similar to the example shown above. In this case, no RE or PFE core files are present.

1 These are hidden commands, so they must be entered manually.

Initial Configuration and Platform Troubleshooting

Are there any RE or PFE core files present on your router?

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.

lab@router> start shell

% cd /var/tmp

% ls

harry123

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

Initial Configuration and Platform Troubleshooting

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)

Part 14: Restore and Commit The Standard Reset File

Step 14.1

Your must now restore and commit the lab set’s default reset file to ensure that your station is ready to complete the remaining labs:

[edit]

lab@router# load override reset

[edit]

lab@router# commit and-quit

load override reset [edit] lab@router# commit and-quit S T O P Tell your instructor that you

STOP Tell your instructor that you have completed lab 2.

Lab 3

Interface Configuration and Troubleshooting

Overview

In this lab you will configure and test the operation of your router’s interfaces.

By completing this lab you will perform the following tasks:

Configuration:

Determine IP addressing and interface specifics

Configure a variety of interface types for IP support

Operation:

Use ping and traceroute to verify interface operation

Use show and monitor commands to determine interface status

Analyze logs for interface state transitions

Perform loopback testing (optional)

Test and ATM network with the atm-ping command (Optional)

Perform BERT testing (Optional demonstration)

Part 1: Determine Addressing and Interface Specifics

Step 1.1

Refer to the lab diagram handout to determine the interface types and addressing specifics for your station. All physical interfaces use 10.0.x/24 addressing while loopback interfaces will use 192.168.x/24 addresses. Use the table below to assist you in determining the types of interfaces installed in your router:

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.

Interface Configuration and Troubleshooting

Classroom interface name

Interface type

Olive

Mxx

 

router

fxp0,

fxp0

10/100-Mbps Ethernet (Note: fxp interfaces support transit traffic on Olives)

fxp1,

fxp2

 
 

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

ATM (SONET OC-3)

gre, ipip,

gre, ipip,

Internal interfaces used by the Juniper routers for Generic Route Encapsulation, IP inside of IP tunneling, loopback and Protocol Independent Multicast encapsulations. All internal interfaces except the loopback interface can be safely ignored for now.

lo0, pime

lo0,

pime

What are the names and types of interfaces installed in your router?

Part 2—Configure your Interfaces

Step 2.1

Make sure that you have restored and committed the lab set’s default reset file to ensure that your station is ready to begin this lab:

[edit]

lab@router# load override reset

[edit]

lab@router# commit

Configure the physical and logical properties of your router’s interfaces:

Ethernet and SONET interfaces only!

While at the [edit interfaces] hierarchy, type the following command to configure the ethernet or SONET interfaces on your router (the loopback address should not be set at this time):

[edit interfaces]

Interface Configuration and Troubleshooting

user@host# set interface-name unit 0 family inet address 10.0.x.x/24

ATM interfaces only!

While at the [edit interfaces] hierarchy, type the following command to configure the ATM interfaces on 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 router’s 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;

}

}

Interface Configuration and Troubleshooting

Step 2.4

}

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;

}

}

}

When you are satisfied with your interface configuration, commit your changes and exit configuration mode.

Part 3: Verify IP Connectivity To Neighboring Routers

Step 3.1

Test your interfaces using the CLI’s ping command. The ping command bounces packets off of a remote address and tells you how long it took them to make the round trip. Ping each of your neighboring routers; the lack of an IGP will prevent pings to non-directly connected neighbors (including loopback addresses).

user@host> ping <directly-connected-ip-address>

PING x.x.x.x (x.x.x.x): 56 data bytes

64 bytes from x.x.x.x: icmp_seq=0 ttl=255 time=0.330 ms

Interface Configuration and Troubleshooting

64

bytes from x.x.x.x: icmp_seq=1 ttl=255 time=0.270 ms

64

bytes from x.x.x.x: icmp_seq=2 ttl=255 time=0.283 ms

64

bytes from x.x.x.x: icmp_seq=3 ttl=255 time=0.287 ms

<Ctrl-c>[abort]

If you can ping your neighbors on all your directly connected interfaces, you should consider saving the router configuration so this basic configuration can be recalled at any time. You should name you configuration “station-name-base”.

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.

Part 4: Use Show Commands To Verify Interface Status

Step 4.1

 

Display the summary status of your interfaces:

lab@router> show interfaces terse

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/*

What type of interfaces installed in which FPC are displayed?

Use the pipe function to match on particular interfaces types that are physically down:

lab@router> show interfaces so-* | match "Physical link is Down"

Add a count function:

lab@router> show interfaces so-* | match "Physical link is Down" | count

Interface Configuration and Troubleshooting

Step 4.3

 

Display more information about your interfaces:

lab@router> show interfaces brief

Do any interfaces indicate a looped condition?

Step 4.4

 

Reset interface statistics:

lab@router> clear interfaces statistics all

Display detailed interface information:

lab@router> show interfaces detail

Are your interface packet and byte counters incrementing?

Step 4.5

 

Display extensive interface information:

lab@router> show interfaces extensive

Are there any input or output error counters incrementing?

Are any media specific alarms present?

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 VT-

100

lab@router> monitor interface traffic

Interface Configuration and Troubleshooting

According to this display, what is the busiest interface on your router?

Monitor a specific interface:

lab@router> monitor interface <interface-name>

Are any alarms or errors being displayed?

♦ Are any alarms or errors being displayed? S T O P You should pause at

STOP You should pause at this point and wait for all students to complete the previous steps.

Part 5: Monitor System Logs for Interface Related Information

Step 5.1

Monitor the system log and look for interface related entries. During this time the instructor will disconnect various cables:

lab@router> monitor start messages

What type of information can you glean from the following log message?

*** messages ***

Aug 31 10:14:35 router mib2d[555]: SNMP_TRAP_LINK_DOWN: ifIndex 13, ifAdminStatus up(1), ifOperStatus down(2), ifName fe-0/0/0

Aug 31 10:14:35 router mib2d[555]: SNMP_TRAP_LINK_DOWN: ifIndex 15, ifAdminStatus up(1), ifOperStatus down(2), ifName fe-0/0/2

What about these log entries?

Aug 31 10:16:12 router mib2d[555]: SNMP_TRAP_LINK_DOWN: ifIndex 21, ifAdminStatus up(1), ifOperStatus down(2), ifName so-0/1/1

Aug 31 10:16:12 router mib2d[555]: SNMP_TRAP_LINK_DOWN: ifIndex 20, ifAdminStatus up(1), ifOperStatus down(2), ifName so-0/1/0

Interface Configuration and Troubleshooting

Aug 31 10:16:13 router mib2d[555]: SNMP_TRAP_LINK_DOWN: ifIndex 25, ifAdminStatus up(1), ifOperStatus down(2), ifName so-0/1/0.0

Aug 31 10:16:16 router /kernel: so-0/1/1: Asserting SONET alarm(s) LOS

Aug 31 10:16:17 router /kernel: so-0/1/0: Asserting SONET alarm(s) LOS

Aug 31 10:16:17 router /kernel: so-0/1/0: Asserting SONET alarm(s) LOL

Aug 31 10:16:17 router /kernel: so-0/1/1: Asserting SONET alarm(s) LOL

.

.

.

Aug 31 10:19:08 router /kernel: so-0/1/1: Clearing SONET alarm(s) LOL LOS

Aug 31 10:19:08 router /kernel: so-0/1/0: Clearing SONET alarm(s) LOL LOS

Step 5.2

Search through your system log for all messages related to a particular interface:

lab@router> show log message | match <interface-name>

How could you count the number of physical transitions on a SONET interface?

Part 6: Perform Loopback Testing (Optional)

Step 6.1

This portion of the lab is optional. Your instructor will inform you if the classroom equipment can support loopback testing. If the classroom equipment supports only fast ethernet interfaces, this section should be skipped. Based on the number of POS/ATM interfaces available, you may have to coordinate access with other classmates.

Unlike some vendors, JUNOS software does not send pings addressed to a local WAN interface out that interface. In other words, pinging the local address of a WAN interface does not generate traffic on the line. Many technicians have become accustomed to “testing the WAN link” by issuing such a ping. The following steps will illustrate how similar results can be achieved using a Juniper Networks router.

In order to succeed, the interface must stay “up” in the presence of the loopback. This requires that you use cisco-hdlc, frame-relay, or AAL 5 encapsulation and, that you

Interface Configuration and Troubleshooting

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 {

Step 6.2

loopback remote;

}

unit 0 {

family inet {

address 10.0.8.2/24;

}

}

We will now confirm that Denver’s 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. test:

lab@Denver> ping 10.0.8.1 count 2

PING 10.0.8.1 (10.0.8.1): 56 data bytes

Now for a local ping

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

Do the pings to Denver’s local address work as expected?

Interface Configuration and Troubleshooting

And now for the remote ping that is intended to test the transmission facility:

lab@Denver> ping 10.0.8.2 count 2

PING 10.0.8.2 (10.0.8.2): 56 data bytes

36 bytes from 10.0.8.1: Time to live exceeded

Vr HL TOS

Len

ID Flg

off TTL Pro

cks

Src

Dst

4

5

00 0054 406d

0 0000

01 01 553a 10.0.8.1

10.0.8.2

36

bytes from 10.0.8.1: Time to live exceeded

 

Vr HL TOS

Len

ID Flg

off TTL Pro

cks

Src

Dst

4 5

00 0054 406f

0 0000

01

01 5538 10.0.8.1

10.0.8.2

--- 10.0.8.2 ping statistics ---

2 packets transmitted, 0 packets received, 100% packet loss

Do these results strike you as unexpected?

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.

Part 7: Test An ATM Network With The atm-ping Command (Optional)

Step 7.1

This portion of the lab is optional. Your instructor will inform you if the classroom equipment can support atm-ping testing. If the classroom equipment supports only fast ethernet interfaces, this section should be skipped. Depending on the number of ATM interfaces available, you may have to coordinate access with other classmates.

You will now use the atm-ping command to validate an ATM transmission facility without requiring or relying on IP related parameters. This test makes use of ATM F5 (VCI level) OAM cells.

In this example, we will focus on an ATM link between Denver and Montreal. We start by looking at the at-0/2/0 interface configuration on Montreal:

[edit interfaces at-0/2/0]

lab@Montreal# show

atm-options {

vpi 0 maximum-vcs 256;

}

unit 0 {

vci 0.100;

Interface Configuration and Troubleshooting

}

It should be noted that Montreal’s ATM interface is devoid of any IP related configuration.

Step 7.2

Denver’s 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-to- end F5 OAM cells?

Interface Configuration and Troubleshooting

Part 8: Run BERT Tests (Optional Demonstration)

Step 8.1

 

Certain Juniper Networks PICs contain built in test pattern generation designed to provide Bit Error Rate Test (BERT) capabilities. PICs that support BERT testing would include T1, E1, T3, and E3 interfaces. Your instructor will inform you if such interfaces are available in the classroom, and if desired will conduct a BERT testing demonstration.

A typical BERT test configuration would look similar to this example:

[edit]

lab@Denver# show interfaces t3-0/1/2

disable;

t3-options {

bert-algorithm pseudo-2e20-o151;

bert-error-rate 6;

bert-period 60;

}

unit 0 {

family inet {

address 10.0.2.4/24;

}

}

The interface must be disabled before the BERT test can be started. This example will inject errors at a rate of 1X10 -6 to validate the results. The test will run for 60 seconds, and we assume there is a remote loopback in place.

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.

the results can be displayed using show interface . S T O P Tell your instructor

STOP Tell your instructor that you have completed lab 3.

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:

Create static routes

Configure RIP version 2

Operation:

Use show commands to verify and troubleshoot RIP operation

Part 1: Create Static Routes For Use With RIP

Step 1.1

You will begin by defining the static routes associated with your station. Since “you” own these routes in the classroom, the only valid next hops are discard or reject. In the field, static routes such as these would normally point towards a customer edge router as the next hop. Repeat the following command for each of your static routes, and do not forget the single 200.0.x/24 static route assigned to each station:

[edit routing-options]

lab@denver# set static route 192.168.x/24 discard

When done, your routing-options stanza should be similar to this example taken from Denver:

[edit routing-options]

lab@denver# show

static {

route 192.168.5.0/24 discard;

route 192.168.6.0/24 discard;

route 192.168.7.0/24 discard;

Routing Information Protocol

route 200.0.6.0/24 discard;

}

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

Are your static routes active?

Part 2—Configure RIP

Step 2.1

 

In this step you will configure RIP Version 2 on all interfaces that have neighboring routers. Repeat the following commands for each of your interfaces with attached neighbors:

[edit protocols]

 

lab@denver# set rip group name neighbor <interface-name.unit>

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

Broadcast RIPv2 packets (RIPv1 compatible)

multicast

Multicast RIPv2 packets

none

Do not send RIP updates

version-1

Broadcast RIPv1 packets

 

What command would you use to modify RIP’s 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@router# set group name ?

Possible completions:

Routing Information Protocol

 

<[Enter]>

Execute this command

+

apply-groups

Groups from which to inherit configuration

data

+

export

Export policy

metric-out

Default metric of exported routes (1 15)

> neighbor

Neighbor configuration

preference

Preference of routes learned by this group

|

Pipe through a command

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.

Part 3: Use Operational Commands To Verify RIP Operation

Step 3.1

Confirm you are running RIP on the correct interfaces. Your display should be similar to this example taken from Denver:

lab@denver> show rip neighbor Source

Destination

Send

Receive

In

Routing Information Protocol

Neighbor

State Address

Address

Mode

Mode

Met

--------

----- -------

-----------

----

------- ---

so-0/1/1.0

Up 10.0.2.2

224.0.0.9

mcast

both

1

so-0/1/0.0

Up 10.0.0.2

224.0.0.9

mcast

both

1

fe-0/0/1.0

Up 10.0.8.1

224.0.0.9

mcast

both

1

Are the correct interfaces listed as “up”?

Can you tell from this display that the router is running RIP Version 2?

What metric is associated with each of your interfaces?

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: port 520; update interval 30s; holddown 180s; timeout

120s.

rts learned rts held down rqsts dropped resps dropped

0

0

0

0

so-0/1/1.0: 0 routes learned; 0 routes advertised

Counter

Total

Last 5 min

Last minute

-------

----------- ----------- -----------

Updates Sent

0

0

0

Triggered Updates Sent

0

0

0

Responses Sent

0

0

0

.

.

.

Have any routes been learned? Are updates being sent?

Routing Information Protocol

Based on these results, does RIP appear to be working?

Step 3.3

 

Determine if RIP routes are present:

lab@denver> show route protocol rip

inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both

 

224.0.0.9/32

*[RIP/100] 00:09:20, metric 1

 

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>

Were any routes displayed?

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

Routing Information Protocol

Commit your changes and monitor the trace file.

lab@denver> monitor start rip

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.

Can you think of what could account for these symptoms?

Part 5: The Problem

Step 5.1

The problem here does not relate to RIP, so much as the lack of routing rules, which tell RIP what it should do. The default behavior of RIP is to accept all RIP routes, but send nothing (not even RIP routes). Without the application of routing policy to override this default, we can never hope for a happy ending to this lab.

You will write and apply routing policy to your RIP configuration in the next lab.

routing policy to your RIP configuration in the next lab. S T O P Tell your

STOP Tell your instructor that you have completed lab 4.

Lab 5

Overview

Routing Policy

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:

Write a single term policy

Write a multiple term policy

Manipulate and rename terms in a policy

Write a RIP export policy

Apply your policy to RIP

Operation:

Use show commands to verify the operation of your RIP policy

Part 1: Write a Single Term Policy to Redistribute Static and Aggregate Routes

Step 1.1

In this step you will create a single term policy that will redistribute your static and aggregate

routes. Position yourself at the [edit policy-options policy-name] portion hierarchy, and enter the following commands to create your from condition:

2

of the

[edit policy-options policy-statement policy-name]

lab@denver# set from ?

lab@denver# set from protocol ?

2 This act will create an empty policy statements called “policy-name”

Routing Policy

[edit policy-options policy-statement policy-name] lab@denver# set from protocol static

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?

Step 1.4

Modify your policy to also accept aggregate routes:

Routing Policy

[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.

Part 2: Write A Multi-Term Policy

Step 2.1

 

In many cases it is necessary to write complex policy rules. While one could write, and then apply, a series of individual policies, it is sometimes easier to write a set of rules and actions using a single policy with multiple terms.

The use of terms in policies provides the additional benefit of supporting adds, moves, and changes to your policy. In this example you will write a policy that would advertise static routes with a metric of 20 and your aggregate routes with a metric of 10 while rejecting all other routes.

Position yourself at the [edit policy-options new-policy-name] portion of the hierarchy, and enter the following commands to create your first term:

[edit policy-options policy-statement new-policy-name]

lab@denver# set term 1 from protocol static

[edit policy-options policy-statement new-policy-name]

lab@denver# set term 1 then metric 20

[edit policy-options policy-statement new-policy-name]

lab@denver# set term 1 then accept

Show your first term:

[edit policy-options policy-statement new-policy-name]

lab@denver# show

Step 2.2

Create your policy’s 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-stateme