AJER_11.a-R_LGH

Advanced Junos Enterprise Routing 11.a

High-Level Lab Guide

Worldwide Education Services 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA 408-745-2000 www.juniper.net Course Number: EDU-JUN-AJER

This document is produced by Juniper Networks, Inc. This document or any part thereof may not be reproduced or transmitted in any form under penalty of law, without the prior written permission of Juniper Networks Education Services. Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. Advanced Junos Enterprise Routing High-Level Lab Guide, Revision 11.a Copyright © 2012 Juniper Networks, Inc. All rights reserved. Printed in USA. Revision History: Revision 10.a—March 2011. Revision 11.a—April 2012. The information in this document is current as of the date listed above. The information in this document has been carefully verified and is believed to be accurate for software Release 11.4R1.6. Juniper Networks assumes no responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary, incidental, or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.

Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. YEAR 2000 NOTICE Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036. SOFTWARE LICENSE The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should consult the software license for further details.

Contents Lab 1:

Configuring and Monitoring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 Part 1: Configuring and Monitoring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 Part 2: Configuring OSPF Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4 Part 3: Configuring OSPF Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8

Lab 2:

Configuring and Monitoring OSPF Areas and Route Summarization . . . . . . 2-1 Part 1: Configuring a Stub Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2 Part 2: Configuring an NSSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Lab 3:

Configuring and Monitoring Routing Policy and Advanced OSPF Options . . 3-1 Part 1: Establishing the OSPF Adjacencies and Creating a Virtual Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 Part 2: Configuring OSPF Multiarea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4 Part 3: Configuring External Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6

Lab 4:

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

Lab 5:

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

Lab 6:

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

Lab 7:

6-2 6-2 6-4 6-5 6-7 6-7 6-9

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

Lab 8:

5-2 5-2 5-3 5-4 5-5 5-7 5-8

7-2 7-4 7-6 7-8

Implementing SSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1 Part 1: Disabling the Use of RPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2 Part 2: Configuring IGMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3 Part 3: Viewing PIM-SM SSM Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5 Part 4: Configuring an ssm-map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6

www.juniper.net

Contents • iii

Lab 9:

Implementing CoS Features in the Enterprise . . . . . . . . . . . . . . . . . . . . . . . 9-1 Part 1: Loading the Initial Configuration and Accessing the CoS Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2 Part 2: Configuring Traffic Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3 Part 3: Configuring Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4 Part 4: Configuring and Testing Schedulers and Drop Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5 Part 5: Configuring and Testing a Rewrite Marker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8

Lab 10: BGP Route Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1 Part 1: Loading the Initial Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2 Part 2: Verifying Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2 Part 3: Converting to Route Reflectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3 Part 4: Adding a New Router to the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6

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

iv • Contents

www.juniper.net

Course Overview This three-day course is designed to provide students with the tools required for implementing, monitoring, and troubleshooting Layer 3 components in an enterprise network. Detailed coverage of OSPF, BGP, class of service (CoS), and multicast is strongly emphasized. Through demonstrations and hands-on labs, students will gain experience in configuring and monitoring the Junos operating system and in monitoring device and protocol operations.

Objectives After successfully completing this course, you should be able to:

www.juniper.net

•

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

•

Explain the flooding of LSAs in an OSPF network.

•

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

•

Describe OSPF area types and operations.

•

Configure various OSPF area types.

•

Summarize and restrict routes.

•

Identify scenarios that require routing policy or specific configuration options.

•

Use routing policy and specific configuration options to implement solutions for various scenarios.

•

Describe basic BGP operation and common BGP attributes.

•

Explain the route selection process for BGP.

•

Describe how to alter the route selection process.

•

Configure some advanced options for BGP peers.

•

Describe various BGP attributes in detail and explain the operation of those attributes.

•

Manipulate BGP attributes using routing policy.

•

Describe common routing policies used in the enterprise environment.

•

Explain how attribute modifications affect routing decisions.

•

Implement a routing policy for inbound and outbound traffic using BGP.

•

Identify environments that may require a modified CoS implementation.

•

Describe the various CoS components and their respective functions.

•

Explain the CoS processing along with CoS defaults on SRX Series Services Gateways.

•

Describe situations when some CoS features are used in the enterprise.

•

Implement some CoS features in an enterprise environment.

•

Describe IP multicast traffic flow.

•

Identify the components of IP multicast.

•

Explain how IP multicast addressing works.

•

Describe the need for reverse path forwarding (RPF) in multicast.

•

Explain the role of Internet Group Management Protocol (IGMP) and describe the available IGMP versions.

•

Configure and monitor IGMP.

•

Identify common multicast routing protocols.

•

Describe rendezvous point (RP) discovery options.

•

Configure and monitor Physical Interface Module (PIM) sparse modes. Course Overview • v

•

Configure and monitor RP discovery mechanisms.

•

Describe the basic requirements, benefits, and caveats of source-specific multicast (SSM).

•

List the address ranges used for SSM.

•

Illustrate the role of Internet Group Management Protocol version 3 (IGMPv3) and PIM sparse mode (PIM-SM) in an SSM implementation.

•

Configure and monitor SSM.

Intended Audience This course benefits individuals responsible for configuring and monitoring devices running the Junos OS.

Course Level Advanced Junos Enterprise Routing is an advanced-level course.

Prerequisites Students should have basic networking knowledge and an understanding of the Open Systems Interconnection (OSI) model and the TCP/IP protocol suite. Students should also have working experience with basic routing principles. Students should also attend the Introduction to the Junos Operating System (IJOS), Junos Routing Essentials (JRE), and Junos Intermediate Routing (JIR) courses prior to attending this class.

vi • Course Overview

www.juniper.net

Course Agenda Day 1 Chapter 1: Course Introduction Chapter 2: OSPF Lab 1: Configuring and Monitoring OSPF Chapter 3: OSPF Areas Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization Chapter 4: OSPF Case Studies and Solutions Lab 3: Configuring and Monitoring Routing Policy and Advanced OSPF Options

Day 2 Chapter 5: BGP Lab 4: Implementing BGP Chapter 6: BGP Attributes and Policy Lab 5: BGP Attributes Chapter 7:

Enterprise Routing Policies Lab 6: Implementing Enterprise Routing Policies

Day 3 Chapter 8: Introduction to Multicast Chapter 9: Multicast Routing Protocols and SSM Lab 7: Implementing PIM-SM Lab 8: Implementing SSM Chapter 10: Class of Service Lab 9: Implementing CoS Features in the Enterprise Appendix A: BGP Route Reflection Lab 10: BGP Route Reflection (Optional)

www.juniper.net

Course Agenda • vii

Document Conventions CLI and GUI Text Frequently throughout this course, we refer to text that appears in a command-line interface (CLI) or a graphical user interface (GUI). To make the language of these documents easier to read, we distinguish GUI and CLI text from chapter text according to the following table. Style

Description

Usage Example

Franklin Gothic

Normal text.

Most of what you read in the Lab Guide and Student Guide.

Courier New

Console text: •

Screen captures

commit complete

•

Noncommand-related syntax

Exiting configuration mode

GUI text elements: • Menu names • Text field entry

Select File > Open, and then click Configuration.conf in the Filename text box.

Input Text Versus Output Text You will also frequently see cases where you must enter input text yourself. Often these instances will be shown in the context of where you must enter them. We use bold style to distinguish text that is input versus text that is simply displayed. Style

Description

Usage Example

Normal CLI

No distinguishing variant.

Physical interface:fxp0, Enabled

Normal GUI

View configuration history by clicking Configuration > History. CLI Input

Text that you must enter.

lab@San_Jose> show route Select File > Save, and type config.ini in the Filename field.

GUI Input

Defined and Undefined Syntax Variables Finally, this course distinguishes between regular text and syntax variables, and it also distinguishes between syntax variables where the value is already assigned (defined variables) and syntax variables where you must assign the value (undefined variables). Note that these styles can be combined with the input style as well. Style

Description

Usage Example

CLI Variable

Text where variable value is already assigned.

policy my-peers

Text where the variable’s value is the user’s discretion or text where the variable’s value as shown in the lab guide might differ from the value the user must input according to the lab topology.

Type set policy policy-name.

GUI Variable CLI Undefined

GUI Undefined

viii • Document Conventions

Click my-peers in the dialog.

ping 10.0.x.y Select File > Save, and type filename in the Filename field.

www.juniper.net

Additional Information Education Services Offerings You can obtain information on the latest Education Services offerings, course dates, and class locations from the World Wide Web by pointing your Web browser to: http://www.juniper.net/training/education/.

About This Publication The Advanced Junos Enterprise Routing High-Level Lab Guide was developed and tested using software Release 11.4R1.6. Previous and later versions of software might behave differently so you should always consult the documentation and release notes for the version of code you are running before reporting errors. This document is written and maintained by the Juniper Networks Education Services development team. Please send questions and suggestions for improvement to [email protected].

Technical Publications You can print technical manuals and release notes directly from the Internet in a variety of formats: •

Go to http://www.juniper.net/techpubs/.

•

Locate the specific software or hardware release and title you need, and choose the format in which you want to view or print the document.

Documentation sets and CDs are available through your local Juniper Networks sales office or account representative.

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

www.juniper.net

Additional Information • ix

x • Additional Information

www.juniper.net

Lab 1 Configuring and Monitoring OSPF

Overview This lab demonstrates configuration and monitoring of the OSPF protocol. In this lab, you use the command-line interface (CLI) to configure, monitor, and troubleshoot OSPF. The lab is available in two formats: a high-level format designed to make you think through each step and a detailed format that offers step-by-step instructions complete with sample output from most commands. By completing this lab, you will perform the following tasks:

www.juniper.net

•

Configure a multiarea OSPF network.

•

Configure link costs and reference-bandwidth.

•

Overload a router.

•

Configure and troubleshoot OSPF authentication.

Configuring and Monitoring OSPF • Lab 1–1 11.a.11.4R1.6

Advanced Junos Enterprise Routing

Part 1: Configuring and Monitoring OSPF In this lab part, you configure and monitor a multiarea OSPF network. You will first prepare your device by loading a reset config located on your device. Next, you define a router ID for your assigned device. You then configure your device to participate in a multiarea OSPF network and verify operations using CLI operational mode commands. Note

The instructor will tell you the nature of your access and will provide you with the necessary details to access your assigned device. Step 1.1 Ensure that you know to which student device you have been assigned. Check with your instructor if you are not certain. Consult the management network diagram to determine the management address of your student device. Question: What is the management address assigned to your station?

Step 1.2 Access the CLI on your student device using either the console, Telnet, or SSH as directed by your instructor. Refer to the management network diagram for the IP address associated with your student device. The following example uses a simple Telnet access to srxA-1 with the Secure CRT program as a basis:

Step 1.3 Log in to the student device with the username lab using a password of lab123. Note that both the name and password are case-sensitive. Enter configuration mode and load the reset configuration file using the load override /var/home/lab/ajer/reset.config command. After the configuration has been loaded, commit the changes before proceeding.

Lab 1–2 • Configuring and Monitoring OSPF

www.juniper.net


Step 1.4 Navigate to the [edit routing-options] hierarchy and configure the router ID on your router using the IP address assigned to the lo0 interface as the input value. Step 1.5 Navigate to the [edit protocols ospf] hierarchy and configure the interfaces necessary for OSPF Area 0. Refer to the network diagram as needed and remember to include the loopback interface, lo0.0. On the ge-0/0/1 interface, use the interface-type p2p option to speed up its adjacency time. Step 1.6 Activate the configuration and quickly issue the run show ospf neighbor command. Question: Which neighbor states are shown for the listed interfaces and why?

Question: Why did the ge-0/0/1.0 interface form its adjacency more quickly than the ge-0/0/2.0 interface?

Step 1.7 Issue the run show ospf interface command to view the interface states. Question: What are the states of the two ethernet interfaces and what do they mean?

Step 1.8 Issue the run show ospf neighbor command again to verify the current OSPF adjacency details. Question: How many OSPF neighbors exist and what are the states of those adjacencies?

www.juniper.net

Configuring and Monitoring OSPF • Lab 1–3


STOP

Do not proceed until the remote team finishes Part 1.

Part 2: Configuring OSPF Cost In this lab part, you configure OSPF link costs, or metrics, on the student devices and check your changes using CLI operational mode commands. In subsequent steps, the words cost and metric are used interchangeably. Step 2.1 Display routes advertised to and received from OSPF using the run show ospf route command. Question: What is the current metric associated with the displayed OSPF routes?

Question: Why does the output show two entries with the same prefix?

Step 2.2 Associate a metric of 100 with the ge-0/0/2.0 interface. Activate the change and reissue the run show ospf route command. Question: What is the current metric associated with the 172.20.66.0/30 OSPF route?

Question: What was the effect of the increased metric on the route associated with the remote student device’s loopback address?

Step 2.3 Another method to view the metric of an interface is the show ospf interface detail command. Issue a run show ospf interface ge-0/0/2.0 detail command to view its output. Lab 1–4 • Configuring and Monitoring OSPF

www.juniper.net


Step 2.4 Because we are using Gigabit Ethernet interfaces in the network, change the reference-bandwidth to 10g. Activate the change and issue the run show ospf route command to view the changes. Question: What was the effect of setting the reference-bandwidth to 10g?

Question: Why did the metric associated with ge-0/0/2.0 remain unchanged?

Step 2.5 Configure your assigned device to function as an area border router (ABR), joining Area 0 with a second area. Refer to the network diagram for the area and interface details. When complete, activate the configuration changes using the commit command. Step 2.6 Issue the run show ospf neighbor command to verify the current OSPF adjacency details. Question: How many OSPF neighbors exist and what are the states of those adjacencies?

Step 2.7 Verify reachability to the virtual router attached to your assigned device by pinging its loopback address. Refer to your network diagram as necessary. Question: Was the ping to your attached virtual router successful?

Note

Before proceeding, ensure that the remote team in your pod finishes the previous step.

www.juniper.net


Advanced Junos Enterprise Routing Note

The next two lab steps require you to log in to the virtual router attached to your team’s device. The virtual routers are logical devices created on a J Series Services Router. Step 2.8 Open a second CLI session to your student device. Log in to this second session to the student device with the username lab using a password of lab123. Note that both the name and password are case-sensitive.

Step 2.9 From the second CLI session to your student device, telnet to your virtual router’s loopback address. Log in to the virtual router using the login information shown in the following table: Virtual Router Login Details


Student Device

Username

Password

srxA-1

a1

lab123

srxA-2

a2

lab123

srxB-1

b1

lab123

srxB-2

b2

lab123

srxC-1

c1

lab123

srxC-2

c2

lab123

srxD-1

d1

lab123

srxD-2

d2

lab123

www.juniper.net


Step 2.10 Verify reachability back to your student device’s loopback address from the remote virtual router. Be sure to source your ping from the correct virtual router routing instance. Refer to the following table for your assigned instance name. Note

Keep in mind that when working with virtual routers and routing instances, command syntax is different. If needed, please reference the Detailed Lab Guide for sample command syntax for the individual verification tasks performed within this lab.

Routing Instance Names Student Device

Instance Name

srxA-1

vr111

srxA-2

vr112

srxB-1

vr113

srxB-2

vr114

srxC-1

vr115

srxC-2

vr116

srxD-1

vr117

srxD-2

vr118

Step 2.11 Issue a show route remote-virtual-router-loopback/32 table instance-name command to view the route table data of the remote team’s virtual router’s loopback address. Use the table from the previous step for the instance name. Question: What is the OSPF cost to reach the remote virtual router’s loopback address?

Step 2.12 Return to the CLI session on your SRX Series student device. On the SRX Series student device, configure your device for OSPF overload mode and activate the change.

www.juniper.net



Step 2.13 Return to the CLI session on your virtual router. On your local virtual router, reissue the show route remote-virtual-router-loopback/32 table instance-name command. Question: Did the metric change? If so, what did it change to and why?

Question: Why would you overload a router?

Step 2.14 Log out of the vr-device and then log out of student device. You can close this second window because you will not need it anymore. Step 2.15 Return to the CLI session on your SRX Series student device. On the SRX Series student device, delete the overload setting and activate your changes.

STOP


Part 3: Configuring OSPF Authentication In this lab part, you configure OSPF authentication on the link between the student devices. Initially, only team 1 will modify its device’s current configuration to make it incompatible with team 2’s router. Then, both teams will enable OSPF traceoptions to log protocol activity and the associated errors. Finally, team 2 will configure its router to match team 1’s configuration changes. Step 3.1 This step is for team 1 only. Configure the ge-0/0/1.0 interface in Area 0 for OSPF Message Digest 5 (MD5) authentication. Use a password of juniper and a key-id of 1. Activate your changes when complete. Step 3.2 This step is for both teams. Issue a run show ospf neighbor command. Lab 1–8 • Configuring and Monitoring OSPF

www.juniper.net


Question: How many OSPF neighbors does your assigned device currently have?

Step 3.3 This step is for both teams. Define traceoptions for OSPF so that OSPF errors write to a file named trace-ospf. Include the detail option with the error flag to capture additional details of the OSPF errors. Activate the configuration change when completed. Step 3.4 This step is for both teams. Issue the run show log trace-ospf command to view the contents written to the trace-ospf trace file. Question: Does the generated error in the trace file explain the current OSPF adjacency issue?

Step 3.5 This step is for team 2 only. Configure the ge-0/0/1.0 interface in Area 0 for OSPF MD5 authentication. Use a password of juniper and a key-id of 1. Activate the changes when completed. Step 3.6 This step is for both teams. Issue a run show ospf neighbor command. Question: Did the OSPF adjacency across the ge-0/0/1.0 interface return to the Full state?

Step 3.7 This step is for both teams. Deactivate traceoptions and delete the trace-ospf log file. Activate the configuration and return to operational mode using the commit and-quit command. Step 3.8 Log out of your assigned device using the exit command. www.juniper.net



STOP

Tell your instructor that you have completed Lab 1.


www.juniper.net

Lab 2 Configuring and Monitoring OSPF Areas and Route Summarization

Overview This lab configures a stub area and a not-so-stubby (NSSA) area, and performs route summarization. In addition, the stub area will be converted into a totally stubby area using the no-summaries option. The lab is available in two formats: a high-level format designed to make you think through each step and a detailed format that offers step-by-step instructions complete with sample output from most commands. By completing this lab, you will perform the following tasks:

www.juniper.net

•

Create a stub area.

•

Change the stub area to a totally stubby area.

•

Create a not-so-stubby area.

•

Perform route summarization.

Configuring and Monitoring OSPF Areas and Route Summarization • Lab 2–1 11.a.11.4R1.6


Part 1: Configuring a Stub Area In this lab part, you configure an OSPF stub area. You will first prepare your device by loading a reset configuration file located on your device. You then configure a new interface and the stub area. Finally, you reconfigure the stub area as a totally stubby area. For this lab, you will use the network diagram titled “Lab 2 (Stub Area): Configuring and Monitoring OSPF Areas and Route Summarization.” Note



Step 1.3 Log in to the student device with the username lab using a password of lab123. Note that both the name and password are case-sensitive. Enter configuration mode and load the reset configuration file using the load override /var/home/lab/ajer/lab2-start.config command. After the configuration has been loaded, commit the changes before proceeding.

Lab 2–2 • Configuring and Monitoring OSPF Areas and Route Summarization

www.juniper.net


Step 1.4 Refer to the network diagram and configure the IP address on the ge-0/0/4.unit interface for the stub area on your assigned device. Use the logical unit value as the VLAN-ID value for this interface. Step 1.5 Navigate to the [edit protocols ospf] hierarchy and configure the OSPF stub area. Refer to the network diagram to ensure you use the correct area number for your device . Step 1.6 Activate the configuration and issue the run show ospf neighbor command. Question: Did the new neighbor come up to a Full state?

Step 1.7 Issue the run show ospf interface detail | find ge-0/0/4 command to see the difference between the non-stub area interface and the new stub area interface. Question: Is the new interface correctly set as Stub?

Step 1.8 Issue the run show ospf database area area summary and run show ospf database area area commands to see how many and what types of link-state advertisements (LSAs) are contained in the OSPF database for your stub area. Refer to the network diagram as needed for the correct stub area number. Question: How many summary LSAs are in your stub area?

Step 1.9 Convert your stub area to a totally stubby area using the no-summaries option and activate your changes. Step 1.10 Issue the run show ospf database area area summary and run show ospf database area area commands again. www.juniper.net

Configuring and Monitoring OSPF Areas and Route Summarization • Lab 2–3


Question: How many summary LSAs are now in your stub area?

Question: Why are there no summary LSAs?

Step 1.11 Configure the router to inject a default route into the stub area by using the default-metric option. Give this route a metric of 10 and activate your changes. Step 1.12 Issue the run show ospf database area area summary and run show ospf database area area commands again. Question: How many summary LSAs are now in your stub area?

STOP


Part 2: Configuring an NSSA In this lab part, you configure an NSSA and perform route summarization on it. For the remainder of this lab, please refer to the lab diagram titled “Lab 2 (NSSA Area): Configuring and Monitoring OSPF Areas and Route Summarization.” Step 2.1 Refer to the network diagram and configure the IP address on the ge-0/0/4.unit interface for the NSSA area on your assigned device. Use the logical unit value as the VLAN-ID value for this interface. Step 2.2 Navigate to the [edit protocols ospf] hierarchy and configure the NSSA area. Refer to the network diagram to ensure you use the correct area number for your device. Step 2.3 Activate the configuration and issue the run show ospf neighbor command.


www.juniper.net


Question: Did the new neighbor come up to a full state?

Step 2.4 Issue the run show ospf interface ge-0/0/4.unit detail command to verify this interface is set as an NSSA interface. Question: Is the new interface correctly set as an NSSA interface?

Note

Before proceeding, ensure that the remote team in your pod finishes the previous step. Step 2.5 Issue the run show ospf database area area summary and run show ospf database area area nssa commands to see how many and what types of LSAs are contained in the OSPF database for your NSSA area. Question: How many NSSA LSAs are in your NSSA area’s database?

Step 2.6 Issue the run show ospf database external command to see external LSAs contained in the OSPF database. Question: Are the external LSAs that describe the remote team’s NSSA routes present?

Question: How many external LSAs are present?

www.juniper.net

Configuring and Monitoring OSPF Areas and Route Summarization • Lab 2–5


Step 2.7 Each of the external NSSA destinations is represented by a /24 network. Choose one of the remote team’s destinations and issue a run show route destination command for that destination. Step 2.8 You will now summarize your four networks into one /22 network using the area-range option. Ensure you set this command within the [edit protocols ospf area area nssa] hierarchy of the configuration. Commit your changes when completed and exit to operational mode. Note

Before proceeding, ensure that the remote team in your pod finishes the previous step. Step 2.9 Issue the show ospf database external command to view the external LSAs present in the OSPF database. Question: Were the changes successful? How can you tell?

Step 2.10 Choose one of the remote team’s destinations and issue a show route destination command for that destination to verify the router is using the /22 summary route instead of the original /24 route. Step 2.11 Log out of your assigned device using the exit command.

STOP



www.juniper.net

Lab 3 Configuring and Monitoring Routing Policy and Advanced OSPF Options

Overview In this lab, you will use the lab diagram titled “Lab 3: Configuring and Monitoring Routing Policy and Advanced OSPF Options” to establish a multiarea OSPF routing domain. This lab will require the configuration of a virtual link as backup to the backbone connection and a multiarea adjacency as outlined in RFC 5185. The final part of this lab will require routing policy to redistribute and advertise routes being received from a RIP network into OSPF external link-state advertisements (LSAs). The lab is available in two formats: a high-level format designed to make you think through each step and a detailed format that offers step-by-step instructions complete with sample output from most commands. By completing this lab, you will perform the following tasks:

www.juniper.net

•

Load the default configuration.

•

Establish multiple OSPF adjacencies.

•

Configure and verify a virtual link.

•

Configure and verify a OSPF multiarea adjacency.

•

Establish a RIP neighbor peer session.

•

Write a routing policy to advertise a default route into RIP.

•

Configure prefix-limits in OSPF to prevent excessive external routes.

•

Write a routing policy to advertise a RIP summary route into OSPF.

•

Write an OSPF import policy to prevent less than optimal routing.

Configuring and Monitoring Routing Policy and Advanced OSPF Options • Lab 3–1 11.a.11.4R1.6


Part 1: Establishing the OSPF Adjacencies and Creating a Virtual Tunnel In this lab part, you load the reset configuration for this lab and then establish the OSPF adjacencies. The virtual router device (vr-device) will provide connectivity for all three OSPF areas between your student device and your partners. Note




Lab 3–2 • Configuring and Monitoring Routing Policy and Advanced OSPF Options

www.juniper.net


Step 1.4 Navigate to the [edit protocols ospf] hierarchy. Establish the OSPF adjacencies with the P1, P2, and R3 routers attached to your student device. Configure OSPF Area 10 as a not-so-stubby area (NSSA) and advertise a default route with a metric of 10. Do not forget the loopback address in Area 0. Commit the configuration when complete. Step 1.5 Use the run show ospf interface command to verify which interfaces are participating in OSPF. Question: How many interfaces are running OSPF?

Step 1.6 Use the run show ospf neighbor command to verify the establishment of the OSPF adjacencies. Question: Are all OSPF adjacencies established and in the Full state?

Step 1.7 Verify that the routing table has connectivity to all devices in the OSPF domain. Use the run show route protocol ospf table inet.0 | match /32 command to display only the host addresses. Question: Is there an entry in the primary routing table (inet.0) for all six loopback addresses within the OSPF domain?

Step 1.8 Navigate to the [edit protocols ospf area 0.0.0.0] hierarchy. Create a virtual link in OSPF Area 0 through Area 20 using the OSPF virtual-link command. The virtual-link neighbor-id is the loopback address of your partner’s student device. The virtual link should be used only as a backup in the event of an P1 failure. This can be accomplished by setting the P2 interface in Area 20 to a metric of 10. Commit this configuration when completed. Step 1.9 Use the run show ospf interface command to verify that the virtual link has been established and that an adjacency has been formed. www.juniper.net

Configuring and Monitoring Routing Policy and Advanced OSPF Options • Lab 3–3


Question: Which type of interface is created for the virtual link?

Step 1.10 Use the run show ospf neighbor command to verify that the virtual link has established an adjacency. Question: What is the adjacency state of the virtual link interface?

Step 1.11 Use the run show route address/32 table inet.0 command to verify that your partner’s default loopback address routes through the P1 router and not through the virtual link. Refer to the network diagram as needed. Question: Does the route to your partner’s loopback address go through the P1 router or the virtual link?

Part 2: Configuring OSPF Multiarea In this lab part, you configure an OSPF multiarea adjacency to provide an alternate path for OSPF Area 10. Step 2.1 Navigate to the [edit protocols ospf area 0.0.0.10] hierarchy and establish an OSPF Area 10 adjacency through the P1 router. You will add the P1 interface to Area 10 with the secondary setting. This will provide a backup path for Area 10 in the event of a P3 failure. Ensure that this backup path is only used in the event of a P3 failure. This can be accomplished by setting the newly configured interface with a higher metric. Commit these changes when completed. Step 2.2 Use the run show ospf interface command to verify the multiarea adjacency.


www.juniper.net


Question: Area 10 now has two interfaces in it. What is the state for the interface you just added to Area 10? Why?

Step 2.3 Use the run show ospf neighbor command to verify the establishment of an OSPF Area 10 adjacency through the P1 router. Question: How many OSPF adjacencies exist for Area 0.0.0.10?

Step 2.4 Verify that the loopback address of your partner’s R3 virtual router is being routed through the ge-0/0/14.0 interface toward your R3 virtual router. Use the run show route address/32 table inet.0 command to display the path of the route. Question: What is the primary path to your partner’s virtual router’s loopback address?

Step 2.5 Navigate to the [edit routing-instances instance-name protocols ospf] hierarchy. The value of instance-name is the name of your remote virtual router (either R3-1 or R3-2) depending on your assigned student device. Deactivate your R3 virtual router’s Area 10 interface connected to the P3 router. Commit the configuration when completed. Step 2.6 Issue the run show route address/32 table inet.0 command again to verify the route to your partner’s remote virtual router’s loopback address has converged through the P1 router, thus using the multiarea adjacency. Question: Did the route converge through the multiarea adjacency?

Step 2.7 Navigate to the top of the configuration hierarchy. Use the rollback 1 command to reactivate the interface between your R3 virtual router and the P3 router. Commit the configuration when complete. www.juniper.net



Step 2.8 Verify that OSPF converged back to the primary path by displaying your partner’s loopback address using the run show route address/32 table inet.0 command. Question: Did the route converge back to your R3 virtual router?

STOP


Part 3: Configuring External Reachability In this lab part, you configure an external connection from the R3 routing instance to a RIP network. Once established, the RIP routes will be redistributed into OSPF. Note

In this lab part, you will be configuring and displaying commands in the virtual routing instance. When referencing the routing instance, the commands will include the routing instance name, R3-N, where N is the user number (1 or 2). Refer to the lab diagram for the correct user number to use. Step 3.1 Navigate to the [edit routing-instances instance-name] hierarchy. Remove the R3-to-P3 interface from OSPF Area 10 and reconfigure that interface as a RIP interface. Use a RIP group name of P3. Commit the configuration when complete. Step 3.2 Use the run show route receive-protocol rip address table instance-name command to verify that RIP routes are being received from the P3 router. The address value will be 172.22.125.2 or 172.22.126.2 depending on your assigned student device. Please refer to the network diagram as needed. Question: How many routes are you receiving from the P3 RIP router?


www.juniper.net


Step 3.3 Use the run show route 0/0 exact table instance-name command to verify your R3 virtual router has an OSPF default route that routes toward your assigned student device. Step 3.4 Navigate to the [edit policy-options policy-statement export-default] hierarchy. Create a routing policy to advertise the OSPF default route to the RIP router. Do not commit your changes at this time. Note

The next two steps must be coordinated with your remote team partners. Step 3.5 This step is to be performed by Team 1 only. Team 2 will perform the same step after waiting two minutes from the time of this commit. Navigate to the [edit routing-instances instance-name] hierarchy. Apply the policy as an export policy in the P3 RIP group configured previously. Commit the configuration when complete. Step 3.6 This step is to be performed by Team 2 only after waiting two minutes from the commit time of the previous step. Navigate to the [edit routing-instances instance-name] hierarchy. Apply the policy as an export policy in the P3 RIP group configured previously. Commit the configuration when complete. Step 3.7 Use the run show route advertising-protocol rip address table instance-name command to verify that the default route is being advertised to the P3 router. The address value will be 172.22.125.1 or 172.22.126.1 depending on your assigned student device. Please refer to the network diagram as needed. Note

The output from both routers is shown in the following capture. Question: Is the default route being advertised to R3?

www.juniper.net



Step 3.8 Display the default route in the R3 routing table using the run show route 0/0 exact table instance-name command. Note

The output from both routers is shown in the following capture. Question: What is the active protocol for the default route?

Step 3.9 Using the external-preference option, set the external preference of OSPF to 90 (which is less than the RIP preference of 100) for the R3 virtual router. Commit the changes when complete. Step 3.10 Use the run show route advertising-protocol rip address table instance-name command to verify that the default route is being advertised to the P3 router. The address value will be 172.22.125.1 or 172.22.126.1 depending on your assigned student device. Please refer to the network diagram as needed. Note

The output from both routers is shown in the following capture. Question: Is the route now being advertised to the RIP network?

Step 3.11 Navigate to the [edit policy-options policy-statement import-rip-route] hierarchy. Create a policy to accept only the 20.20.0.0/21 RIP summary route from the P3 RIP router. Step 3.12 Navigate to the [edit routing-instances instance-name] hierarchy and apply the import-rip-route policy as an import policy under the P3 group in protocols RIP. Commit the configuration when complete.


www.juniper.net


Step 3.13 Use the run show route receive-protocol rip address table instance-name command to verify that RIP routes are being received from the P3 router. The address value will be 172.22.125.2 or 172.22.126.2 depending on your assigned student device. Verify that only the summary route is now being received from the P3 RIP router. Question: Is the RIP import policy working?

Step 3.14 Navigate to the [edit policy-options policy-statement export-rip-route] hierarchy. Create a routing policy to redistribute the RIP summary route into OSPF. Do not commit the configuration at this time. Step 3.15 This step is to be performed by Team 1 only. Team 2 will perform the same step after waiting two minutes from the time of this commit. Navigate to the [edit routing-instances instance-name] hierarchy. Before applying the policy as an OSPF export policy, protect the network from unnecessary routes by configuring a prefix export limit of 1 using the prefix-export-limit command within protocols ospf. Commit the configuration when complete. Step 3.16 This step is to be performed by Team 2 only after waiting two minutes from the commit time of the previous step. Navigate to the [edit routing-instances instance-name] hierarchy. Before applying the policy as an OSPF export policy, protect the network from unnecessary routes by configuring a prefix export limit of 1 using the prefix-export-limit command within protocols ospf. Commit the configuration when complete. Step 3.17 Verify connectivity to the RIP network by performing a trace to the RIP router using the redistributed RIP summary route. Use the run traceroute 20.20.1.1 routing-instance instance-name command to verify connectivity. Note

The output from both routers is shown in the following capture.

www.juniper.net



Question: What could be causing the suboptimal path to the RIP network?

Step 3.18 Examine the OSPF Type 7 LSA to Type 5 LSA conversion between the OSPF NSSA area and the OSPF backbone area. Use the run show ospf database area 10 nssa detail command to display the Type 7 LSAs and the run show ospf database external detail command to display the Type 5 LSA. Question: Which router created the Type 7 LSA for the 20.20.0.0 prefix? Which ABR created the Type 5 external LSA for the 20.20.0.0 prefix? Why?

Step 3.19 Navigate to the [edit policy-options policy-statement ospf-import] hierarchy. Create an OSPF import policy to block the RIP summary route from being installed in the routing table from OSPF. Step 3.20 Navigate to the [edit routing-instances instance-name] hierarchy and apply the ospf-import policy as an import policy in OSPF. Commit the changes when complete and return to operational mode. Step 3.21 Verify that the OSPF import policy is working and that optimal routing is being performed to the RIP network by using the traceroute 20.20.1.1 routing-instance instance-name command. Question: Is the OSPF import policy working?

Step 3.22 Log out of your assigned device using the exit command.

STOP



www.juniper.net

Lab 4 Implementing BGP

Overview In this lab, you will use the Lab 4 network diagrams to establish a BGP network. After verifying the baseline OSPF topology, a full mesh of internal BGP (IBGP) sessions must be established between all routers in your autonomous system (AS), AS 64700. The EBGP neighboring routers are in AS 65510 and AS 65520. You will establish EBGP peering sessions with the locally connected provider edge (PE) routers. This lab will require the configuration of both IBGP and EBGP peering sessions. The lab is available in two formats: a high-level format designed to make you think through each step, and a detailed format that offers step-by-step instructions complete with sample output from most commands. By completing this lab, you will perform the following tasks:

www.juniper.net

•

Load a baseline configuration.

•

Verify OSPF neighbor relationships and Internet reachability.

•

Establish IBGP peering sessions.

•

Establish EBGP peering sessions with multipath.

•

Use policy to summarize IBGP routes.

•

Establish an EBGP peering session with multihop.

Implementing BGP • Lab 4–1 11.a.11.4R1.6


Part 1: Loading the Baseline Interface and OSPF Configuration In this lab part, you load a baseline configuration that will automatically set up your router according to the lab diagram labeled “Lab 4: Implementing BGP—Part 1.” Next, you verify router-to-router connectivity and OSPF operations using the command-line interface (CLI). Step 1.1 Ensure that you know to which student device you have been assigned. Check with your instructor if you are not certain. Consult the management network diagram to determine the management address of your student device. Question: What is the management address assigned to your station?


Step 1.3 Log in to the student device with the username lab using a password of lab123. Note that both the name and password are case-sensitive. Enter configuration mode and load the reset configuration file using the load override /var/home/lab/ajer/lab4-start.config command. After the configuration has been loaded, commit the changes before proceeding. Step 1.4 Use the run ping address rapid command to ping the far-end IP address of each of the five interfaces attached to your student device. This action verifies that each interface has been configured properly. Refer to your network diagram as needed.

Lab 4–2 • Implementing BGP

www.juniper.net


Question: Were all of the interface IP addresses reachable?

Step 1.5 Use the run show ospf interface and run show ospf neighbor commands to confirm that OSPF has been configured properly and that adjacencies have been established between neighboring routers. Question: Are the adjacencies established between your router and the two neighboring routers?

Part 2: Configuring IBGP In this lab part, you use the lab diagram called “Lab 4: Implementing BGP— Parts 2–4” to configure and monitor IBGP. You first define the AS number for your device. Next, you establish IBGP peering sessions using loopback addresses. You then monitor the established IBGP peering sessions using CLI operational mode commands. Step 2.1 Navigate to the [edit routing-options] hierarchy. Define the AS number designated for your network. Refer to the network diagram for this lab as necessary. Step 2.2 Navigate to the [edit protocols bgp] hierarchy. Configure an IBGP group named my-int-group that includes the three devices within your assigned network as IBGP peers. Use the loopback address assigned to your device as the local-address and the remote loopback addresses of the other three devices within your AS number as the neighbor addresses. When you are satisfied with the newly defined BGP configuration, issue the commit command to activate the changes. Question: Was the commit operation successful?

www.juniper.net

Implementing BGP • Lab 4–3


Before proceeding, ensure that the remote student team in your pod finishes the previous step. Step 2.3 Issue the run show bgp summary command to view the current BGP summary information for your device. Question: How many BGP neighbors does your device currently list?

Question: Has your device received any routes from its IBGP peers?

Step 2.4 Issue the run show route receive-protocol bgp peer-address command, where peer-address is the loopback address of each IBGP peer. Question: From which IBGP peers are you currently receiving routes?

Question: What is the AS path associated with the received BGP routes?

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


www.juniper.net


Question: Which routing table group does the referenced command consult? Which operational mode command displays BGP routes in the routing table (RIB-Local)?

Step 2.5 Issue the run show route advertising-protocol bgp peer-address command, where peer-address is the loopback address of each IBGP peer.

Question: Which routing table group does the command referenced in this step consult?

Question: Is your student device currently advertising BGP routes to any of its IBGP peers?

Part 3: Configuring and Monitoring EBGP In this lab part, you configure and monitor EBGP. You first establish an EBGP peering session with your external peers. You then advertise aggregate routes to your EBGP peer to represent the prefixes reachable from your AS. Finally, you monitor the established EBGP peering sessions using CLI operational mode commands. Step 3.1 Refer to the network diagram for this lab and configure two EBGP peering sessions with the connected AS. Name the associated EBGP group my-ext-group. Once configured, activate the configuration changes using the commit command. Note

Before proceeding, ensure the remote student team in your pod has finished the previous step.

STOP

www.juniper.net

Do not proceed until the remote team finishes the previous step.



Step 3.2 Issue the run show bgp summary command to view the current BGP summary information. Question: How many BGP groups and peers does your device currently list?

Question: Has your device received routes from both EBGP peers?

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

Step 3.3 View all of the routes received from the EBGP peers by issuing the run show route aspath-regex "peer-as .*" command. Question: Are the EBGP peers sending the exact same routes to your router or are they sending different routes?

Question: Can you think of a reason why your router is only using the routes received from one EBGP peer and not the other?

Step 3.4 Use the run show route 0/0 exact extensive command to look at the default route received from each EBGP peer to determine why your router is choosing one of the routes over the other.


www.juniper.net


Question: What did the router use as the reason for not choosing one of the routes to be active?

Question: What is the next hop of the active route?

Question: Is it possible to configure your router to use both sets of routes from the two EBGP peers and load-balance between them? How?

Step 3.5 Issue the run show route advertising-protocol bgp peer-address command, where peer-address is the IP address value assigned to each of your EBGP peers.

Question: Is your device currently advertising the BGP routes received from its IBGP peers to its EBGP peers? If not, explain why.

Step 3.6 Use the advertise-inactive option to override the default behavior and advertise BGP routes that are not currently selected as active because of route preference. Commit the changes when complete. Step 3.7 Once again, issue the run show route advertising-protocol bgp peer-address command, where peer-address is the IP address value assigned to each of your EBGP peers, to determine whether your device is advertising BGP routes to its external BGP peers.

www.juniper.net



Question: Is your device now advertising the BGP routes received from its IBGP peers to its EBGP peers?

Step 3.8 Navigate to the [edit routing-options] hierarchy and define aggregate routes that represent the internal prefixes that are part of your AS. You will need to summarize the 172.21.y.0/24, 172.22.y.0/24, 192.168.y.z/32 prefixes. Step 3.9 Navigate to the [edit policy-options] hierarchy and define a new policy named adv-aggregates that includes two terms. Name the first term match-aggregate-routes. It should match and accept the aggregate routes. Ensure that you match the aggregate protocol. Name the second term deny-other. It should reject all other routes. Step 3.10 Navigate to the [edit protocols bgp] hierarchy and apply the newly defined policy as an export policy for the external BGP group named my-ext-group. Commit the changes when complete. Step 3.11 Verify the effects of the newly defined and applied policy by issuing the run show route advertising-protocol bgp peer-address command, where peer-address is the IP address value assigned to each of your EBGP peers. Question: Is your device advertising all of the expected aggregate prefixes?

Part 4: Configuring BGP Multipath In this lab part, you configure BGP multipath so that your router load-balances egress traffic to both of your router’s EBGP peers. Step 4.1 Use the run show route received-protocol bgp peer-address command to view the routes being received from the two EBGP peers. Refer to the network diagram for this lab as necessary.


www.juniper.net


Question: Again, are the same routes being received from both the EBGP peers?

Step 4.2 Display the 172.28.102.0/24 route using the run show route 172.28.102.0/24 detail command. Question: How many advertisements have been received for this route? Where did they come from?

Question: How many next hops are associated with the active route (denoted by a *)? Why?

Step 4.3 Use the BGP multipath option to install the EBGP routes with two equal cost paths. Configure multipath in the my-ext-group BGP group. Commit your configuration when complete. Step 4.4 Display the 172.28.102.0/24 route again using the run show route 172.28.102.0/24 detail active-path command. Question: How many next hops does the active route now have installed?

Step 4.5 Use the run show route forwarding-table destination 172.28.102.0/24 command to view the packet forwarding table. Question: Are the two routes to the EBGP peers installed in the packet forwarding table?

www.juniper.net



Step 4.6 Navigate to the [edit policy-options policy-statement pfe-load-balance] hierarchy. Under the pfe-load-balance policy, create a term that only load-balances all BGP routes. Step 4.7 After configuring the pfe-load-balance policy, apply it as an export policy under the [edit routing-options forwarding-table] hierarchy. Commit the changes. Step 4.8 Use the run show route forwarding-table destination 172.28.102.0/24 command to verify that the forwarding table now has two next-hop interfaces for the 172.28.102.0/24 route. Question: Is the forwarding table using both next-hop interfaces to reach the 172.28.102.0/24 route?

Part 5: Configuring BGP Multihop In this lab part, you remove the peering sessions to the two EBGP peers. In their place, you configure a single BGP multihop session so that your router load-balances egress traffic across multiple interfaces to a single EBGP peer. Use the lab diagram called “Lab 4: Implementing BGP—Part 5” for this part of the lab. Step 5.1 Navigate to the [edit protocols bgp] hierarchy. Delete the two EBGP peers configured under the my-ext-group BGP group. Make sure to also delete the multipath statement. Step 5.2 Navigate to the [edit routing-options] hierarchy. Configure a static route to the loopback address of your PE router that includes two next hops. The two next hops will be the the far-end IP address of each of the two interfaces that connect to your PE router. Ensure that the route cannot be redistributed into other protocols and commit the configuration when complete. Step 5.3 Attempt to ping the loopback address of your PE router. Be sure to source the ping from the loopback of your student device. Question: Is the ping successful?


www.juniper.net


Step 5.4 Navigate to the [edit protocols bgp] hierarchy. Configure a single EBGP neighbor under the my-ext-group BGP group using the loopback address of the PE router as the neighbor and your own router’s loopback address as the local-address. Commit your configuration when complete. Step 5.5 Check the state of the EBGP session using the run show bgp summary command. Question: What is the state of the EBGP peering session? Why?

Step 5.6 To relax the EBGP requirement of physical interface peering and make it possible to EBGP peer between loopback addresses, apply the multihop statement to the my-ext-group BGP group. Commit your configuration when complete. Step 5.7 Check the status of the EBGP session with the run show bgp summary command. Question: What is the state of the EBGP peering session after the multihop command is configured?

Step 5.8 Now that the EBGP peering session is established, use the run show route receive-protocol bgp PE-loopback-address command to view the routes being received from the P3 router. Question: Are routes being received from the EBGP peering session?

Step 5.9 Display the 172.28.102.0/24 route using the run show route 172.28.102.0/24 detail active-path command.

www.juniper.net



Question: How many next hops does the active route have installed?

Step 5.10 Use the run show route forwarding-table destination 172.28.102.0/24 command to verify that the forwarding table now has two next-hop interfaces for the 172.28.102.0/24 route. Question: Is the forwarding table using both next-hop interfaces to reach the 172.28.102.0/24 route? Why or why not?

Step 5.11 Exit configuration mode and log out of your assigned device using the exit command.

STOP



www.juniper.net

Lab 5 BGP Attributes

Overview This lab demonstrates configuration and manipulation of BGP path attributes. In this lab, you use the command-line interface (CLI) to configure and manipulate BGP attributes. The lab is available in two formats: a high-level format designed to make you think through each step and a detailed format that offers step-by-step instructions complete with sample output from most commands. By completing this lab, you will perform the following tasks:

www.juniper.net

•

Configure export and import policy.

•

Configure and apply a next-hop self policy.

•

Manipulate BGP path attributes to influence traffic flow.

BGP Attributes • Lab 5–1 11.a.11.4R1.6


Part 1: Loading the Initial Configuration In this lab part, you load the initial configuration needed to begin the lab. Step 1.1 Ensure that you know to which student device you have been assigned. Check with your instructor if you are not certain. Consult the management network diagram to determine the management address of your student device. Question: What is the management address assigned to your station?



Part 2: Configuring BGP In this lab part, you first verify the autonomous system (AS) number internal BGP (IBGP) group for your device. Next, you configure an EBGP peering session using the direct addresses for your external peer. Step 2.1 Using the show routing-options autonomous-system command, verify that the AS number designated for your network has been configured. Refer to the network diagram for this lab as necessary. Lab 5–2 • BGP Attributes

www.juniper.net


Step 2.2 Navigate to the [edit protocols bgp] hierarchy. Use the show command to verify that the my-int-group group has been preconfigured as an IBGP session with three peers. Step 2.3 Configure a BGP group named my-ext-group that includes the single device directly connected in the different AS as an EBGP peer. Use the connected address of the device as your peering address. When you are satisfied with the newly defined BGP configuration, issue the commit command to activate the changes. Note

Before proceeding, ensure that the remote student team in your pod finishes the previous step. Step 2.4 Issue the run show bgp summary command to view the current BGP summary information for your device. Question: How many BGP routes are you receiving from your EBGP neighbor?

STOP


Part 3: Configuring Next-Hop Self Policy In this lab part you monitor received routes and detect next-hop resolution issues. You will create a policy to correct the next-hop resolution problems and, after the policy is applied, you will monitor the change and make sure it is working properly. Step 3.1 Issue a run show route protocol bgp hidden command to view the current hidden routes on your device. Note

The output will differ depending on the device you are using. Question: Why are these routes hidden?

www.juniper.net

BGP Attributes • Lab 5–3


Step 3.2 Navigate to the [edit policy-options] configuration hierarchy. Create a policy named nhs with one term that sets all routes to next-hop self. You can name this term anything you like. Step 3.3 Navigate back to the [edit protocols bgp] configuration hierarchy. Apply the nhs policy to the my-int-group BGP group as an export policy. When you are satisfied with the newly defined configuration, issue the commit command to activate changes. Note

Before proceeding, ensure that the remote student team in your pod finishes the previous step. Step 3.4 For verification, issue a run show route protocol bgp hidden command to view the current status of hidden routes on your device. Question: How many hidden routes are there?

STOP


Part 4: Using Policy to Avoid Becoming a Transit AS In this lab part, you use policy to avoid becoming a transit AS. To accomplish this task, you configure a policy that matches routes that are generated in your AS, accept the routes, and reject everything else. You then apply this policy to your EBGP peers. Step 4.1 Issue the run show route protocol bgp aspath-regex "()" command to determine which routes are generated locally in the AS. Question: What does the “()” aspath-regex value match?

Step 4.2 Issue a run show route advertising-protocol bgp peer-address | match "^\*” command to count how many routes are advertised to the EBGP peer. Lab 5–4 • BGP Attributes

www.juniper.net


Question: How many routes are advertised to your external peer?

Step 4.3 Navigate to the [edit policy-options] hierarchy and create an AS path regular expression named null-as that matches the null aspath-regex value. Step 4.4 Create a policy named export-ebgp. This policy will contain two terms. Name the first term local-routes and have it accept BGP routes that match the aspath-regex named null-as created previously. Name the second term last and set it to reject everything else. Question: What is the default terminating action for a routing policy in BGP?

Step 4.5 Navigate to the [edit protocols bgp] hierarchy. Apply the export-ebgp policy as an export policy to the my-ext-group BGP group. When you are satisfied with the newly defined policy configuration, issue the commit command to activate the changes. Step 4.6 Issue a run show route advertising-protocol bgp peer-address | match "^\*” command to determine which routes are advertised to the EBGP peer after applying the export policy. Question: lHow many routes are you now sending to your EBGP peer?

STOP


Part 5: Manipulating Attributes with Policy to Influence Inbound Traffic In this lab part, you configure a policy to manipulate BGP attributes to influence inbound traffic. Policy is used to change the AS path value and origin values on outgoing advertisements. Refer to the network diagram provided. To optimize routing back to the network, you will manipulate outgoing advertisements to enhance the routes closer to the exit point.

www.juniper.net



You will be working with an exclusive set of instructions depending on your assigned device. Step 5.1 This step is to be performed by Team 1 only. Navigate to the [edit policy-options policy-statement export-ebgp] hierarchy. Configure a term named origin that matches routes 67.3.200.0/21 and 69.3.184.0/21. Modify the origin of these routes using the incomplete option and accept them. Insert the origin term before the local-routes term. When you are satisfied with the newly defined policy configuration, issue the commit command to activate the changes. Step 5.2 This step is to be performed by Team 2 only. Navigate to the [edit policy-options policy-statement export-ebgp] hierarchy. Configure a term named as-prepend that matches routes 67.3.192.0/21 and 69.3.176.0/21. Using the as-path-prepend option, change the AS path of these routes to prepend the local AS two times and then accept the routes. Insert this term before the local-routes term.When you are satisfied with the newly defined policy configuration, issue the commit command to activate the changes. Note

Before proceeding, ensure that the remote student team in your pod finishes the previous step. Step 5.3 Using the run telnet 8.0.0.1 source source-address command, telnet to the ISP Y router to confirm the routes that were manipulated in the previous step. Team 1 will use a source address of 67.3.192.1. Team 2 will use a source address of 67.3.200.1. The user is ispy and the password is lab123. Step 5.4 From the ISP Y router, issue the show route table ispY-X 67.3.192.0/21 and show route table ispY-X 67.3.200.0/21 commands, where X is the pod letter you are using (A,B,C, or D). Note

Feel free to inspect the other BGP routes in table ispY on the vr-device.

Lab 5–6 • BGP Attributes

www.juniper.net


The output might differ slightly depending on which device is used. Question: Is the prepend AS path policy working as expected?

Question: Is the manipulation of the origin attribute working as expected?

Step 5.5 Log out of the vr-device.

STOP


Part 6: Manipulating Local Preference with an Import Policy In this lab part, you manipulate the local preference attribute based on incoming community. Referring to your lab diagram, ISP X and ISP Z are advertising their local customer routes with a community containing their AS number and the number 1000, regardless of AS path length. You will create a policy that optimizes outbound traffic to use your peers local routes. Step 6.1 Navigate to the [edit policy-options] configuration hierarchy. Create a BGP community named peer-local that matches either 65510:1000 or 65520:1000. Step 6.2 Create a policy named import-ebgp with a term named peer-local-community that matches the community named peer-local and sets the local preference to 1000. Step 6.3 Navigate to the [edit protocols bgp] configuration hierarchy. Apply the policy named import-ebgp to the my-ext-group BGP group as an import policy. Issue the commit command to activate the changes.

www.juniper.net



Step 6.4 For verification, issue a run show route community "65510|65520:1000" extensive | match "^[0-9]|Localpref" command and ensure the correct routes get tagged with the correct local preference value. Question: Are the peer’s local routes getting the right local preference based on the policy applied in the previous steps?

STOP


Part 7: Aggregating Routes and Using Well-Known Communities In this lab part, you create two aggregate routes for the local AS. The more specific routes will be known by your immediate peers, but we want to supress advertisements beyond that. You will use a well-known community for this task. Step 7.1 Navigate to the [edit routing-options] configuration hierarchy. Create two aggregate routes that overlap the networks in our local AS. When you are satisfied with the newly defined configuration, issue the commit command to activate the changes. Step 7.2 For verification, issue a run show route protocol aggregate command and ensure the aggregate routes were created. Question: What is the requirement for an aggregate route to become active?

Step 7.3 Navigate to the [edit policy-options] configuration hierarchy. Create a community named no-export containing the well-known no-export community. Step 7.4 Navigate to the [edit policy-options policy-statement export-ebgp] configuration hierarchy. Create two new terms. Name one of the terms adv-agg; it should match the aggregate routes and accept them. Name the second term ne to set the community to the no-export community you created previously. Using the then next term option, set an additional action in the ne term.


www.juniper.net


Step 7.5 This step is to be performed by Team 1 only. Insert the adv-agg term before the term named origin. Insert the ne term after the adv-agg term. When you are satisfied with the newly defined configuration, issue the commit and-quit command to activate the changes and exit to operational mode. Note

Make sure to perform the previous step in the order given. If it is not performed in the order given, your policy will not work as expected. Step 7.6 This step is to be performed by Team 2 only. Insert the adv-agg term before the term named as-prepend. Insert the ne term after the adv-agg term. When you are satisfied with the newly defined configuration, issue the commit and-quit command to activate the changes and exit to operational mode. Note

Make sure to perform the previous step in the order given. If it is not performed in the order given, your policy will not work as expected. Step 7.7 For verification, issue the show route advertising-protocol bgp peer-address command to determine which routes you are advertising to your EBGP peer. Refer the lab diagram as needed. Note

The previous output might differ depending on which device you are using, but you will be advertising six routes. Step 7.8 Using the telnet 8.0.0.1 source source-address command, telnet to the ISP Y router to confirm the routes that were manipulated in the previous step. Team 1 will use a source address of 67.3.192.1. Team 2 will use a source address of 67.3.200.1. The user is ispy and the password is lab123.

www.juniper.net



Step 7.9 From the vr-device, verify the routes originated from your local AS (64700) by issuing a show route table ispY-X aspath-regex ".*64700$" command, where X is the pod letter you are using (A,B,C, or D). Question: Why does the number of routes advertised from AS 64700 (6) differ from the amount of routes ISP Y receives (two)?

Step 7.10 Log out of the vr-device using the exit command. Step 7.11 Log out of your assigned device using the exit command.

STOP



www.juniper.net

Lab 6 Implementing Enterprise Routing Policies

Overview This lab demonstrates implementation of enterprise routing policies. In this lab you will be using BGP as a policy tool to achieve the goals of the lab. In this lab, you use the command-line interface (CLI) to configure and manipulate configuration. The lab is available in two formats: a high-level format designed to make you think through each step and a detailed format that offers step-by-step instructions complete with sample output from most commands. By completing this lab, you will perform the following tasks:

www.juniper.net

•

The use of private autonomous systems (ASs) to segregate the network.

•

Configuration of the common routing policies for external connectivity.

Implementing Enterprise Routing Policies • Lab 6–1 11.a.11.4R1.6


Part 1: Loading the Initial Configuration In this lab part, you load the initial configuration needed to begin the lab. Step 1.1 Ensure that you know to which student device you have been assigned. Check with your instructor if you are not certain. Consult the management network diagram to determine the management address of your student device. Question: What is the management address assigned to your station?



Part 2: Configuring BGP In this lab part, you configure BGP. You first define the AS number for your device. Next, you establish IBGP peering sessions using loopback addresses for your internal peers. Finally, you will create two different EBGP peering groups, one for your internal enterprise sites and one for your external ISP provider. You will use direct addresses for your external peers. Step 2.1 Define the AS number designated for your network. Refer to the network diagram for this lab as necessary. Lab 6–2 • Implementing Enterprise Routing Policies

www.juniper.net


Step 2.2 Navigate to the [edit protocols bgp] hierarchy. Configure a BGP group named my-int-group that includes the other SRX Series device within your AS as an internal BGP (IBGP) peer. Use the loopback address assigned to your device as the local address and the remote loopback address of the remote device as the neighbor address. When you are satisfied with the newly defined BGP configuration, issue the commit command to activate the changes. Step 2.3 Refer to the lab diagram and find your directly connected enterprise peer. Configure a BGP group named my-ent-group that includes this single device. Using the connected address of the device as your peering address, configure this device as an EBGP peer. Do not forget to set the correct peer AS (either 65001 or 65002, depending on your assigned device). When you are satisfied with the newly defined BGP configuration, issue the commit command to activate the changes. Step 2.4 Refer to the lab diagram and find your directly connected external peer. Configure a BGP group named my-ext-group that includes this single device. Using the connected address of the device as your peering address, configure this device as an EBGP peer. Do not forget to set the correct peer AS (either 3356 or 813, depending on your assigned device). When you are satisfied with the newly defined BGP configuration, issue the commit command to activate the changes. Note

Before proceeding, ensure that the remote student team in your pod finishes the previous step. Step 2.5 Issue the run show bgp summary command to view the current BGP peering status for your device. Question: How many BGP routes are you receiving from your ISP neighbor?

Question: Which type of external routing policy is this policy?

STOP

www.juniper.net


Implementing Enterprise Routing Policies • Lab 6–3


Part 3: Implementing a Strict Primary/Secondary Routing Policy for Outbound Traffic In this lab part, you implement a strict primary/secondary routing policy for your external connections. ISP X and ISP Z are sending a full view of the Internet table. Note

This is a hypothetical full view of the Internet routing table. Lab resources are limited, thus we can only generate a limited number of routes. In addition, ISP X is sending a default route and customer routes with community tag 3356:1. ISP Z is also sending a default route and customer routes with community tag 813:1. Step 3.1 Navigate to the [edit policy-options] hierarchy and create two communities, one named ispX with 3356:1 as the member and the other named ispZ with 813:1 as the member. Step 3.2 Create a policy named primary-secondary. In this policy, create a term named primary that matches a default route (0.0.0.0/0) and community ispX. Set the action for this term to raise the local preference to 1000 and accept. Step 3.3 Within the primary-secondary policy, create a second term named secondary that matches a default route (0.0.0.0/0) and community ispZ. Set the action for this term to accept. Step 3.4 Within the primary-secondary policy, create a third term named reject with an action of reject. Step 3.5 Navigate back to the [edit protocols bgp] hierarchy. Set the policy primary-secondary as an import policy for the my-ext-group group. When you are satisfied with the newly defined BGP configuration, issue the commit command to activate the changes. Step 3.6 For verification, issue the run show route 0/0 exact command. Note

The output will differ depending on the device to which you are assigned.

Lab 6–4 • Implementing Enterprise Routing Policies

www.juniper.net


Before proceeding, ensure that the remote student team in your pod finishes the previous step. Question: What is the local-preference value of the default route?

Question: Which path does the enterprise prefer now for all external traffic?

Part 4: Implementing a Primary/Secondary Routing Policy for Inbound Traffic In this lab part, you implement a primary/secondary routing policy for inbound traffic using routing policy. You also implement a policy to keep the enterprise from becoming a transit AS. Step 4.1 Navigate to the [edit policy-options] hierarchy and create an AS path regular expression named private that matches the entire private AS range (64512–65535). Step 4.2 Create a policy named ext-ebgp. In this policy, create a term named my-ent-nets that matches the as-path of private and has an action to accept. Create a second term named reject-all with an action to reject. When you are satisfied with the newly defined policy configuration, issue the commit command to activate the changes. Step 4.3 Navigate back to the [edit protocols bgp] hierarchy. Set the policy ext-ebgp as an export policy for the my-ext-group group. When you are satisfied with the newly defined BGP configuration, issue the commit command to activate the changes. Step 4.4 Issue the run show route advertising-protocol bgp ext-peer-address command to verify you are only advertising the two enterprise routes to your external ISP peers. Question: Which routes are you advertising to the external ISP peers?

www.juniper.net



Step 4.5 Remove the private AS when advertising the enterprise routes to the ISP. Use the remove-private command under the my-ext-group. When you are satisfied with the newly defined BGP configuration, issue the commit command to activate the changes. Step 4.6 Issue the run show route advertising-protocol bgp ext-peer-address command to verify that no private AS numbers exist in the AS path. Question: Is the private AS value removed from the advertisements?

Step 4.7 Note

You will be working with an exclusive set of instructions depending on your assigned device. This step is to be performed by Team 2 only. Navigate to the [edit policy-options] hierarchy. In the ext-ebgp policy, add an action to the my-ent-nets term that prepends the AS number 10458 three times. When you are satisfied with the newly defined policy configuration, issue the commit command to activate the changes. Step 4.8 This step is to be performed by Team 2 only. Issue the run show route advertising-protocol bgp 172.18.2.1 command to verify the policy is prepending the AS three times. Question: Why does AS prepending help the strict primary/secondary network design?

Note

Changing attributes before advertising to the provider does not always guarantee the desired result, because you have no control over the routing policy of other networks.


www.juniper.net


STOP


Part 5: Implementing a Loose Primary/Secondary Routing Policy for Outbound Traffic In this lab part, you implement a loose primary/secondary routing policy. This action allows you to prefer the secondary ISP for selected prefixes. Step 5.1 This step is to be performed by Team 2 only. Within the primary-secondary policy, create a new term named ISPZ-specifics that matches the ispZ community created previously and accepts the routes. Insert this term before the term reject in the primary-secondary policy. When you are satisfied with the newly defined policy configuration, issue the commit command to activate the changes. Note

Before proceeding, ensure that Team 2 in your pod finishes the previous step. Step 5.2 This step is to be performed by Team 1 only. Issue the command run show route protocol bgp aspath-regex "813$" | no-more. This action allows you to view routes originated from ISP Z. Note

The command will have approximately 100 routes to display. It might take a couple of seconds to complete. Question: What is the next hop for routes in AS 813?

Question: How does this configuration accomplish a loose primary/secondary design?

Part 6: Implementing Per-Prefix Load Sharing Outbound Traffic In this lab part, you implement per-prefix load sharing for outbound traffic. This allows the network to use different providers for a given set of prefixes.

www.juniper.net



Step 6.1 Navigate to the [edit protocols bgp] hierarchy. Remove the import policy named primary-secondary from the BGP group my-ext-group. When you are satisfied with the newly defined BGP configuration, issue the commit command to activate the changes. Note

Before proceeding, ensure that the remote student team in your pod finishes the previous step. Step 6.2 To view the amount of routes active in the table from the peers, issue a run show bgp summary command. Question: How many routes are active from the ISP?

Step 6.3 This step is to be performed by Team 1 only. Navigate to the [edit policy-options] hierarchy. Create a policy named load-shared. In this policy, create a term named half that matches all prefixes within 0.0.0.0/1 or longer. Set the action for the term half to raise the local preference to 1000 and accept. Step 6.4 This step is to be performed by Team 2 only. Navigate to the [edit policy-options] hierarchy. Create a policy named load-shared. In this policy, create a term named half that matches all prefixes within 128.0.0.0/1 or longer. Set the action for the term half to raise the local preference to 1000 and accept. Step 6.5 Navigate back to the [edit protocols bgp] hierarchy. Apply the load-shared policy as an import policy to the BGP group my-ext-group. Note

Before proceeding, ensure that the remote student team in your pod finishes the previous step. Step 6.6 For verification, issue a run show bgp summary command to view how many routes are active from each peer.


www.juniper.net


The following captures show the outputs from both student devices. Question: How many routes are active from your internal peer?

Note

The policy configured in the previous steps should give a good start for a load-shared design. However, maintaining parity for outbound traffic for various providers requires policy adjustment based on constant monitoring of traffic patterns.

STOP


Part 7: Implementing Per-Prefix Load Sharing for Inbound Traffic In this lab part, you implement per-prefix load sharing for inbound traffic. This allows the external networks to use longest-match routing to reach your networks. Step 7.1 This step is to be performed by Team 1 only. Navigate to the [edit routing-options] hierarchy. Create aggregate routes of 67.3.192.0/21 and 67.3.192.0/20. When you are satisfied with the newly defined configuration, issue the commit command to activate the changes. Step 7.2 This step is to be performed by Team 2 only. Navigate to the [edit routing-options] hierarchy. Create aggregate routes of 67.3.200.0/21 and 67.3.192.0/20. When you are satisfied with the newly defined configuration, issue the commit command to activate the changes. Step 7.3 For verification, issue the command run show route protocol aggregate to confirm that the aggregate routes have become active. Step 7.4 Navigate to the [edit policy-options] hierarchy. Create a new policy named export-load-shared. In this policy, create a new term named aggregates that matches all aggregate routes. Set the action of this term to accept. Create a second term named reject that rejects everything else. www.juniper.net



Step 7.5 Navigate to the [edit protocols bgp] hierarchy. Remove the export policy from the my-ext-group BGP group. Set the export-load-shared policy as an export policy for the my-ext-group BGP group. When you are satisfied with the newly defined configuration, issue the commit command to activate the changes. Step 7.6 For verification, issue the command run show route advertising-protocol bgp ext-peer-address to view the routes advertised to the ISP. Question: How does this lab part accomplish a load-shared design?

Question: Why is announcing a less specific aggregate important in this design?

Step 7.7 Exit configuration mode and log out of your assigned device using the exit command.

STOP



www.juniper.net

Lab 7 Implementing PIM-SM

Overview This lab demonstrates configuration and monitoring of Internet Group Management Protocol (IGMP) and Protocol Independent Multicast Sparse Mode (PIM-SM) on devices running the Junos operating system using the any-source multicast (ASM) model. In this lab, you use the command-line interface (CLI) to configure and monitor IGMP and PIM-SM. The lab is available in two formats: a high-level format designed to make you think through each step and a detailed format that offers step-by-step instructions complete with sample output from most commands. By completing this lab, you will perform the following tasks:

www.juniper.net

•

Configure and monitor IGMP.

•

Configure and monitor static rendezvous point (RP) configuration.

•

Configure and monitor the bootstrap router mechanism (BSR).

•

Configure and monitor PIM-SM using the ASM model.

•

Verify the flow of multicast traffic through the network.

Implementing PIM-SM • Lab 7–1 11.a.11.4R1.6


Part 1: Loading the Baseline Topology In this lab part, you configure your student device’s interfaces according to the lab diagram labeled “Lab 7: Implementing PIM-SM—Parts 1–3.” Next, you will verify the topology using the CLI. Step 1.1 Ensure that you know to which student device you have been assigned. Check with your instructor if you are not certain. Consult the management network diagram to determine the management address of your student device. Question: What is the management address assigned to your station?


Step 1.3 Log in to the student device with the username lab using a password of lab123. Note that both the name and password are case-sensitive. Enter configuration mode and load the reset configuration file using the load override /var/home/lab/ajer/lab7-start.config command. After the configuration has been loaded, commit the changes and return to operational mode before proceeding. Step 1.4 Use the show configuration interfaces command to determine which interfaces have been preconfigured for you.

Lab 7–2 • Implementing PIM-SM

www.juniper.net


Question: Have any interfaces been preconfigured? If so, which interfaces have been preconfigured?

Step 1.5 Use the show configuration protocols command to determine which protocols have been preconfigured for you. Question: Have any protocols been preconfigured? If so, which protocols have been preconfigured?

Step 1.6 Verify that each interface has been configured properly by attempting to ping each of the locally attached routers and hosts. Question: Were all of the locally attached routers and hosts reachable?

Step 1.7 Use the show ospf interface and show ospf neighbor commands to confirm that OSPF has been configured properly and that adjacencies have been established between neighboring routers. Question: Are the adjacencies established between your router and the two neighboring routers?

Step 1.8 To forward traffic from any given source in a PIM-SM network, each router must have a route in its routing table associated with the source. Use the show route 172.18.120/24 command to determine whether a route to the source exists in your device’s routing table. Question: Does the route to the source exist? How was it learned?

www.juniper.net

Implementing PIM-SM • Lab 7–3


STOP


Part 2: Configuring IGMP In this lab part, you configure your student device’s ge-0/0/8 interface to run the IGMP protocol. Next, you will log in to the locally attached receiver and configure it to send IGMP reports. Finally, you will verify, with show commands, that your student device is receiving the IGMP reports generated by the receiver. Step 2.1 Enter configuration mode and navigate to the [edit protocols igmp] hierarchy. Configure your device’s ge-0/0/8 interface to use IGMP version 2 (IGMPv2). Step 2.2 Because only one locally connected receiver is on the ge-0/0/8 interface, configure your device to immediately remove any multicast groups when a leave group message is received from the receiver. Commit your configuration when complete. Step 2.3 Issue the run show igmp interface command to determine which interfaces are enabled for IGMP. Question: Has the ge-0/0/8 interface been properly enabled for IGMP?

Question: Which router has been elected querier for the Ethernet segment?

Question: Which version of IGMP has been enabled?

Question: How many groups have been learned by your student device through the ge-0/0/8 interface?


www.juniper.net


Step 2.4 Issue the run show igmp group command to determine the groups that have been learned from IGMP. Question: Have any groups been learned on your assigned device?

Step 2.5 From your assigned device, log in to the attached receiver using SSH, a username of lab, and a password of lab123. Step 2.6 Analyze the following table to determine the group that you will configure the receiver to join.

Receivers

Groups

Pod A

224.7.7.121

Pod B

224.7.7.123

Pod C

224.7.7.125

Pod D

224.7.7.127

Question: Which group will you be configuring your receiver to receive?

Step 2.7 Using the rptqual application, configure your receiver to generate IGMP reports for the group listed in the table. Use the following example from srxA-1 as a guide: [lab@CoS1 ~]$ ./rtpqual group-address 1111 rtp& [1] 16231 [lab@CoS1 ~]$

Step 2.8 Log out of the receiver and return to the operational mode prompt of your student device. Step 2.9 Use the run show igmp group command to verify that your device is receiving IGMP reports from the locally attached receiver. www.juniper.net



Question: Is your router receiving IGMP reports for any new groups? Which groups?

Part 3: Configuring PIM-SM with Static RP In this lab part, you configure your student device to run the PIM-SM protocol using the ASM model. Next, you will statically configure the RP for the network. Finally, you will verify, with show commands, that your the network has built both a rendezvous-point tree (RPT) and a shortest-path tree (SPT) from source to receiver. Step 3.1 In the previous lab part, you configured the receiver to inform the network, using IGMP, that it wishes to receive multicast traffic. However, IGMP only operates between the receiver and the locally connected IGMP querier (router). To allow for the rest of the network to know of the these locally attached receivers, a multicast routing protocol must be enabled throughout the network of routers. Navigate to the [edit protocols pim] level of the hierarchy. Configure each of your router’s interfaces to run PIM-SM. Do not forget the loopback interface. Step 3.2 One requirement of a PIM-SM network is that at least one RP must exist in the network. Analyze the following table to determine the RP for your multicast group.

Receivers

RP

Group

Pod A

srxA-1 (192.168.121.1)

224.7.7.121

Pod B

srxB-1 (192.168.121.1)

224.7.7.123

Pod C

srxC-1 (192.168.121.1)

224.7.7.125

Pod D

srxD-1 (192.168.121.1)

224.7.7.127

Question: Which router will be the RP in your topology?

Step 3.3 This step is to be performed by Team 1 only. Configure your device to be the RP for all multicast groups (224/4) using the loopback address for the RP address. Commit your configuration when complete.


www.juniper.net


Step 3.4 This step is to be performed by Team 2 only. Configure your device to use a static RP using the srxX-1 loopback address. Ensure that srxX-1 will be the RP for all group addresses (224/4). Commit your configuration when complete. Step 3.5 Verify that the correct interfaces have been configured for PIM-SM by issuing the run show pim interfaces command. Question: Do all of the interfaces that you configured for PIM-SM appear in the output of the command?

Question: Do any interfaces that were not configured for PIM-SM appear in the output of the command? If so, what is the purpose of these extra interfaces?

Step 3.6 Verify that the correct RP has been configured on your router by issuing the run show pim rps command. Question: Is your router aware of any active RPs?

Question: Are there any active groups that your router is associating with the RP? If so, why?

Step 3.7 Issue the run show pim join extensive command to determine the (S,G) and (*,G) states of your router. Question: How many states are associated with your multicast group? Why?

www.juniper.net



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

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

Step 3.8 Verify that multicast traffic is being forwarded by your router by issuing the run show multicast route extensive command. Question: Is multicast traffic being forwarded by your router? If so, at what rate is being forwarded?

STOP


Part 4: Configuring PIM-SM with the BSR mechanism In this lab part, you use the “Lab 7: Implementing PIM-SM—Part 4” diagram. You will configure your student device to run the PIM-SM protocol using the ASM model, but this time you will use the BSR mechanism to dynamically learn the RP. Next, you will verify with show commands that your the network has built both an RPT and an SPT from source to receiver. Step 4.1 Delete any RP configuration that currently exists. Commit your configuration and exit to operational mode. Step 4.2 From your assigned device, log in to the attached receiver using SSH, a username of lab, and a password of lab123. Step 4.3 Issue the ps -ef | grep rtpqual command to determine the process ID (PID) of the rtpqual application used in the previous steps. Use the following example as a guide:


www.juniper.net


[lab@CoS1 ~]$ ps -ef | grep rtpqual lab 3286 1 0 05:35 ? lab 3569 3536 0 07:49 pts/2

00:00:02 ./rtpqual 224.7.7.125 1111 rtp 00:00:00 grep rtpqual

Step 4.4 Issue the kill -9 pid command to kill the PID of the rtpqual application. Use the following example as a guide: [lab@CoS1 ~]$ kill -9 3286

Step 4.5 Analyze the following table to determine the new group that you will configure the receiver to join.

Receivers

Groups

Pod A

224.7.7.122

Pod B

224.7.7.124

Pod C

224.7.7.126

Pod D

224.7.7.128

Question: Which group will you be configuring your receiver to receive?

Step 4.6 Using the rtpqual application, configure your receiver to generate IGMP reports for the group listed in the table. Use the following example from srxA-1 as a guide: [lab@CoS1 ~]$ ./rtpqual group-address 1111 rtp& [1] 3572

Step 4.7 Log out of the receiver and return to the operational mode prompt of your student device. Step 4.8 Using the show igmp group command, verify that your device is receiving IGMP reports from the locally attached receiver. Question: Is your router receiving IGMP reports for any new groups? If so, for which groups?

www.juniper.net



Step 4.9 One requirement of a PIM-SM network with a BSR is that at least one RP and at least one BSR must exist in the network. Analyze the following table to determine the RP and BSR for your multicast group.

Receivers

RP/BSR

Group

Pod A

srxA-2 (192.168.122.1)

224.7.7.122

Pod B

srxB-2 (192.168.122.1)

224.7.7.124

Pod C

srxC-2 (192.168.122.1)

224.7.7.126

Pod D

srxD-2 (192.168.122.1)

224.7.7.128

Question: Which router will act as the RP and BSR in your topology?

Step 4.10 This step is to be performed by Team 2 only. Enter configuration mode and navigate to the [edit protocols pim] hierarchy. Using the srxX-2 loopback address for the RP address, configure srxX-2 to be the RP and BSR for your multicast group only as indicated in the previous step’s table. Also, configure the BSR priority to a value of 50. Commit your configuration and exit to operational mode. Question: Why do you think that there is no need to add any RP-related configuration to the non-RP and non-BSR routers?

Step 4.11 Verify that a BSR has been elected using the show pim bootstrap command. Note

It might take a minute for the BSR to be elected. Question: Has a BSR been elected in the network?


www.juniper.net


Question: What is the IP address of the BSR? Is this expected?

Step 4.12 Verify that the correct RP has been configured on your router by issuing the show pim rps command. Question: Is your router aware of any active RPs?

Step 4.13 Use the show pim join extensive command to determine the (S,G) and (*,G) states of your router. Question: How many states are associated with your multicast group? Why?

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

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

Step 4.14 Verify that multicast traffic is being forwarded by your router by issuing the show multicast route extensive command. Question: Is multicast traffic being forwarded by your router? If so, at which rate is it being forwarded?

www.juniper.net



Step 4.15 Log out of your assigned device using the exit command when complete.

STOP



www.juniper.net

Lab 8 Implementing SSM

Overview This lab demonstrates configuration and monitoring of Internet Group Management Protocol (IGMP) and Protocol Independent Multicast Sparse Mode (PIM-SM) on devices running the Junos operating system using the source-specific multicast (SSM) model. In this lab, you use the command-line interface (CLI) to configure and monitor IGMP, PIM-SM, and general SSM behavior. The lab is available in two formats: a high-level format designed to make you think through each step and a detailed format that offers step-by-step instructions complete with sample output from most commands. By completing this lab, you will perform the following tasks:

www.juniper.net

•

Configure and monitor IGMP version 3 (IGMPv3).

•

Disable the use of rendezvous points (RPs) in the PIM-SM network.

•

Verify the flow of multicast traffic through the SSM modeled network using various group addresses.

Implementing SSM • Lab 8–1 11.a.11.4R1.6


Part 1: Disabling the Use of RPs In this lab part, you load a reset configuration file and then stop any leftover rtpqual processes on your attached receiver. Step 1.1 Ensure that you know to which student device you have been assigned. Check with your instructor if you are not certain. Consult the management network diagram to determine the management address of your student device. Question: What is the management address assigned to your station?


Step 1.3 Log in to the student device with the username lab using a password of lab123. Note that both the name and password are case-sensitive. Enter configuration mode and load the reset configuration file using the load override /var/home/lab/ajer/lab8-start.config command. After the configuration has been loaded, commit the changes and return to operational mode before proceeding. Step 1.4 From your device, log in to the attached receiver using SSH with a username of lab and a password of lab123. lab@srxA-1> ssh lab@receiver-ip-address [email protected]'s password: Last login: Fri Mar 8 07:48:07 2011 from 10.1.1.1 [lab@CoS1 ~]$

Lab 8–2 • Implementing SSM

www.juniper.net


Step 1.5 Issue the ps -ef | grep rtpqual command to determine the process ID (PID) of any rtpqual instances that might still exist from the previous lab or classes. Use the following example as a guide: [lab@CoS1 ~]$ ps -ef | grep rtpqual lab 3572 1 0 07:50 ? lab 3714 3683 0 08:47 pts/0

00:00:16 ./rtpqual 224.7.7.126 1111 rtp 00:00:00 grep rtpqual

Step 1.6 Issue the kill -9 pid command to kill all of the PIDs of any currently running rtpqual application instances. Use the following example as a guide: [lab@CoS1 ~]$ kill -9 3572

Step 1.7 Log out of the receiver and return to the operational mode prompt of your student device. [lab@CoS1 ~]$ exit logout Connection to 10.1.1.2 closed. lab@srxA-1> Note

Before proceeding, ensure that the remote student team in your pod finishes the previous step. Step 1.8 Issue the clear igmp statistics and clear igmp membership commands to clear any IGMP-related information from previous labs.

Part 2: Configuring IGMPv3 In this lab part, you configure your student device’s ge-0/0/8 interface to run the IGMPv3 protocol. Next, you will log in to the locally attached receiver and configure it to send IGMP reports for three different multicast groups. Finally, you will verify, with show commands, that your student device is receiving the IGMP reports generated by the receiver. Step 2.1 Enter configuration mode and navigate to the [edit protocols igmp] hierarchy. Configure your device’s ge-0/0/8 interface to use IGMPv3. Commit your configuration and exit to operational mode when complete. Step 2.2 Issue the show igmp interface command to determine which interfaces are enabled for IGMP. www.juniper.net

Implementing SSM • Lab 8–3


Question: Has the ge-0/0/8 interface been properly enabled for IGMPv3?

Step 2.3 Analyze the following table to determine the source and group combinations that you will configure your receiver to join. You might find it beneficial to write your values down because you will refer to them several times over the following steps.

Receivers

Source, Groups

Pod A

Any Source, 224.221.1.1 Any Source, 232.221.2.2 172.18.120.2, 232.221.3.3

Pod B


Pod C


Pod D


Step 2.4 From your device, log in to the attached receiver using SSH with a username of lab and a password of lab123. lab@srxA-1> ssh lab@receiver-ip-address [email protected]'s password: Last login: Fri Mar 18 07:48:07 2011 from 10.1.1.1 [lab@CoS1 ~]$

Step 2.5 Using the rtpqual application, configure your receiver to generate IGMP reports for the source and group combinations listed in the table. Use the following example as a guide: [lab@CoS1 ~]$ ./rtpqual 224.22z.1.1 1111 rtp& [1] 3789 [lab@CoS1 ~]$ ./rtpqual 232.22z.2.2 1111 rtp& [2] 3792 [lab@CoS1 ~]$ ./rtpqual [email protected] 1111 rtp& [3] 3793


www.juniper.net


Step 2.6 Log out of the receiver and return to the operational mode prompt of your student device. You might see output streaming from the rtpqual application. This is okay; simply issue the exit command and press the Enter key. [lab@CoS1 ~]$ exit Connection to 10.1.1.2 closed. lab@srxA-1>

Step 2.7 Issue the show igmp group command to verify that your device is receiving IGMP reports from the locally attached receiver. Question: Is your router receiving IGMP reports for all three of the new groups?

Question: Is this the expected behavior? What could be a possible reason for this behavior?

Step 2.8 Issue the show igmp statistics command and determine whether any IGMPv3 report errors have been logged. Question: Has your router noticed any IGMP report errors? Why or why not?

Part 3: Viewing PIM-SM SSM Behavior In this lab part, you use CLI commands to determine how PIM-SM is reacting to the IGMP reports that are being received by the receiver’s designated router (DR). Step 3.1 Issue the show pim join extensive command to determine the (S,G) state of your router, which is the receiver’s DR.

www.juniper.net



Question: Have PIM Join messages been sent upstream toward the source for each of the three IGMP reports that have been received? Is this the expected behavior?

Part 4: Configuring an ssm-map In this lab part, you create an ssm-map and apply it to IGMP on the receiver-facing interface. The purpose of the ssm-map will be to statically assign a source to the two groups (224.22z.1.1 and 232.22z.2.2). This feature allows you to support IGMPv1 and IGMPv2 in an SSM-modeled network (it also works for IGMPv3). Refer to the table in the previous section as needed. Step 4.1 Enter configuration mode and navigate to the [edit policy-options] hierarchy. Create a policy called ssm-groups that uses route filters to match on 224.22z.1.1 and 232.22z.2.2. Step 4.2 Navigate to the [edit routing-options multicast] hierarchy and configure an ssm-map named map1. Configure the ssm-map to associate a specific source to any IGMP message that reports membership to 224.22z.1.1 and 232.22z.2.2 by applying the ssm-groups policy to the ssm-map. Use the same source IP address that is being used for the 232.22z.3.3 group. Step 4.3 Navigate to the [edit protocols igmp] hierarchy and apply the map1 ssm-map to the ge-0/0/8 interface. Commit your configuration and exit to operational mode when complete. Step 4.4 In previous steps you noticed that your router was ignoring IGMP reports for 232.22z.2.2. In this step, you verify that your router is now accepting the IGMP reports for 232.22z.2.2. However, because rtpqual sends reports every 60 seconds, you might have to wait up to 60 seconds for your router to receive the next IGMP report for 232.22z.2.2. Issue the show igmp group command to verify that your router is now accepting the IGMP report for 232.22z.2.2. Question: Is your router accepting the IGMP reports for 232.22z.2.2?


www.juniper.net


Question: What is the source associated with the 224.22z.1.1 and 232.22z.2.2 groups? Why?

Step 4.5 Issue the show pim join extensive command, verify that an SPT has been built from source to receiver for all three multicast groups. Question: Have PIM Join messages been sent upstream toward the source for each of the three multicast groups? Is this the expected behavior?

Step 4.6 Issue the show multicast route extensive command to determine whether multicast data is being forwarded by your router for all three multicast groups. Question: Is multicast traffic being forwarded by your router for all three groups?

Step 4.7 Log out of your assigned device using the exit command when complete.

STOP

www.juniper.net





www.juniper.net

Lab 9 Implementing CoS Features in the Enterprise

Overview This lab demonstrates the implementation and testing of various class-of-service (CoS) components in a network. In this lab, you use the CLI to configure and manipulate configuration. The lab is available in two formats: a high-level format designed to make you think through each step and a detailed format that offers step-by-step instructions complete with sample output from most commands. By completing this lab, you will perform the following tasks:

www.juniper.net

•

Configure multifield and behavior aggregate classifiers.

•

Configure a policer for different traffic classes.

•

Create drop profiles.

•

Configure packet marking.

Implementing CoS Features in the Enterprise • Lab 9–1 11.a.11.4R1.6


Part 1: Loading the Initial Configuration and Accessing the CoS Host In this lab part, you use two CLI sessions to accomplish the lab’s goals. You will first log in to your assigned SRX Series student device in the same manner as for previous labs. Next, you will open a second session to your assigned student device and then SSH from there to the CoS end-host device. Step 1.1 Ensure that you know to which student device you have been assigned. Check with your instructor if you are not certain. Consult the management network diagram to determine the management address of your student device. Question: What is the management address assigned to your station?


Step 1.3 Log in to the student device with the username lab using a password of lab123. Note that both the name and password are case-sensitive. Enter configuration mode and load the reset configuration file using the load override /var/home/lab/ajer/lab9-start.config command. After the configuration has been loaded, commit the changes before proceeding. Step 1.4 Open a second session to your assigned student device and log in with the username lab using a password of lab123. From that session, log in to the attached CoS host using SSH with a username of lab and a password of lab123. Refer to the lab diagram as needed.

Lab 9–2 • Implementing CoS Features in the Enterprise

www.juniper.net


Note

You will use the CoS host for the remainder of the lab. If you have any problems accessing the host, please see the instructor.

Part 2: Configuring Traffic Classification In this lab part, you configure traffic classification with a multifield classifier and a behavior aggregate. Once complete, you will use the CoS host to test your configuration. Step 2.1 Return to the CLI session on your SRX Series student device. On the SRX Series device, navigate to the [edit class-of-service] configuration hierarchy. Assign forwarding-class queue 4 with a class-name data. Step 2.2 Navigate to the top of the configuration hierarchy. Create a firewall filter named MF-class. In this firewall filter, create a term named scp that matches traffic from destination-port 22. Set the action for term scp to forwarding-class data and loss-priority low. Create a second term named accept, with an action to accept. Apply the firewall filter MF-class as an input filter to the ge-0/0/8.0 interface. When complete, issue the commit command to activate the changes. Question: How many queues are supported on the SRX Series device?

Step 2.3 Navigate to the [edit class-of-service] configuration hierarchy. Create a DiffServ code point (DSCP) behavior aggregate classifier named BA-class. In this classifier, import the default DSCP classification. Step 2.4 Within the BA-class classifier created in the previous step, match on code points ef and cs5 for forwarding-class expedited-forwarding. Set the loss priority to low. Question: What is the purpose of the DSCP class selector (CS) per-hop behavior group?

Step 2.5 Apply the BA-class behavior aggregate classifier to all gigabit interfaces on your assigned student device. When complete, issue the commit command to activate the changes. www.juniper.net

Implementing CoS Features in the Enterprise • Lab 9–3


Step 2.6 Issue the run clear interfaces statistics all command to clear the statistics for all interfaces. Step 2.7 Return to the CLI session on your CoS host. On the CoS host, secure copy (scp) a file named smallfile.txt in a folder called lab7files from the other team’s host to your local directory. Use the scp cosZ:lab7files/smallfile.txt smallfile.txt command, where Z is the number (1 or 2) of the other team, to complete this step. Note

The hosts are predefined with key authentication; thus a password should not be needed. If prompted for a password, use lab123. Step 2.8 On the CoS host, ping the other team’s host 10 times with a type of service (ToS) value of 184. Use the ping -Q 184 -c 10 cosZ command for this task, where Z is the other team’s assigned host number. Step 2.9 Return to the CLI session on your SRX Series student device. On the SRX Series device, issue a run show interfaces ge-0/0/1 extensive | find "Queue counters" command and inspect the queue counters. Question: Are there any packets in the data and expedited-forwarding queues?

Part 3: Configuring Policers In this lab part, you configure policers and apply them using firewall filters. Different policer actions are applied in this lab part. Step 3.1 Navigate to the [edit firewall] configuration hierarchy. Create a policer named port80 that discards traffic when the bandwidth exceeds 1 megabit. In addition, set a burst size limit of 640 kilobytes for this policer. Step 3.2 Create a new term named http-dst in the firewall filter MF-class. This new term should match traffic destined to port 80. Set the action of the term to then policer port80. Lab 9–4 • Implementing CoS Features in the Enterprise

www.juniper.net


Step 3.3 Insert the new http-dst term before the term scp in the MF-class filter. When complete, issue the commit command to activate the changes. Step 3.4 Create a policer named voice-overflow. Set the policer’s action to forwarding-class best-effort and loss-priority high if the bandwidth exceeds 3 megabits. In addition, set a burst size limit of 640 kilobytes for this policer. Step 3.5 Within the MF-class firewall filter, create a new term named voip-limit that matches traffic with the DSCP class ef. Set the action of the term to then policer voice-overflow. Step 3.6 Insert the new voip-limit term before the term scp in the MF-class filter. When complete, issue the commit command to activate the changes. Question: Why is it important to rate-limit high-priority traffic on an SRX Series device?

Part 4: Configuring and Testing Schedulers and Drop Profiles In this lab part, you configure and test schedulers and drop profiles. Step 4.1 Navigate to the [edit class-of-service schedulers] configuration hierarchy. Create the following five schedulers with the criteria listed in the table.

www.juniper.net



Name

Criteria

be

ef

af

nc

data

•

transmit-rate percent 20

•

priority low

•

drop-profile-map loss-priority high protocol any drop-profile aggressive

•

priority high

•

buffer-size percent 20

•

transmit-rate percent 20 exact

•

priority medium-high

•


•

priority low

•


•

priority medium-high

Question: What is the meaning of the exact option after the transmit-rate?

Step 4.2 Navigate to the [edit class-of-service drop-profiles] configuration hierarchy. Create a drop profile named aggressive with the criteria listed in the following table:

Drop-Profile aggressive

Criteria •

fill-level 30 drop-probability 40

•

fill-level 80 drop-probability 60

Step 4.3 Navigate to the [edit class-of-service scheduler-maps] configuration hierarchy. Create a scheduler-map named my-sched-map with the mappings listed in the following table:


www.juniper.net


Scheduler-Map my-sched-map

Mappings •

forwarding-class best-effort scheduler be

•

forwarding-class expedited-forwarding scheduler ef

•

forwarding-class assured-forwarding scheduler af

•

forwarding-class network-control scheduler nc

•

forwarding-class data scheduler data

When complete, issue the commit command to activate the changes. Step 4.4 Issue the run clear interfaces statistics all command to clear the statistics for all interfaces. Step 4.5 Return to the CLI session on your CoS host. On the CoS host, run the gendata.sh command. The shell script will run for a few minutes. Please allow it to finish before proceeding. . Note

gendata.sh is a shell script made for this lab that generates different types of data transfers, populating all the queues. Step 4.6 Return to the CLI session on your SRX Series student device. On the SRX Series device, issue the run show interfaces ge-0/0/1 extensive | find "Queue counters" command to view the current queue counters. Question: How many drops are in the expedited-forwarding queue?

Step 4.7 Navigate to the [edit class-of-service] configuration hierarchy. Apply the scheduler-map my-sched-map to interface ge-0/0/1. Issue the commit command to activate the changes. www.juniper.net



Step 4.8 Issue the command run clear interfaces statistics all to clear the interface statistics for all interfaces. Step 4.9 Return to the CLI session on your CoS host. On the CoS host, run the gendata.sh command again. As before, allow the script to finish before proceeding. Step 4.10 Return to the CLI session on your SRX Series student device. On the SRX Series device, issue the run show interfaces ge-0/0/1 extensive | find "Queue counters" command to view the current queue counters. Question: How many drops do you see in the expedited-forwarding queue now?

Step 4.11 Issue the run show interfaces queue ge-0/0/1 forwarding-class best-effort command to view details about the best-effort queue. Question: How many high-priority random early detection (RED)-dropped packets does the router display?

Part 5: Configuring and Testing a Rewrite Marker In this lab part, you configure and test a rewrite marker. Step 5.1 Navigate to the [edit class-of-service rewrite-rules] configuration hierarchy. Create a DSCP rewrite-rule named dscp-rewrite. In this rewrite rule, import the default markings. Step 5.2 In the dscp-rewrite rewrite rule, configure forwarding-class best-effort with loss-priority low to have a marking of af31. Step 5.3 Navigate to the [edit class-of-service] configuration hierarchy. Apply the dscp-rewrite rewrite rule to the ge-0/0/8 unit 0 interface. When complete, issue the commit command to activate the changes.


www.juniper.net


Step 5.4 Return to the CLI session on your CoS host. On the CoS host, issue the sudo /usr/sbin/tshark -w icmp.cap -ni eth1 -c 10 dst host srx command. Use lab123 for a password when prompted. Let the command run, and proceed to the next step. Step 5.5 Return to the CLI session on your SRX Series student device. On the SRX Series device, ping the other team’s CoS host from your SRX Series device. Set the ToS byte to 96 and only send 10 pings. Refer to the network diagram as needed. Note

When using the ToS byte option when pinging, it accounts for the entire 8 bit ToS field of the IP header. The following is a table representing AF31 and CS3 DSCP class selectors in decimal, accounting for 6 and 8 bits: CS3: ToS = 96 DSCP = 24 AF31 ToS = 104 DSCP = 26 Step 5.6 Return to the CLI session on your CoS host. On the CoS host, the tshark command should have finished. Read the icmp.cap output file matching for the DSCP field. Use the command sudo /usr/sbin/tshark -r icmp.cap -V | egrep DSCP for this task. If prompted for a password, use lab123. Question: Is the rewrite configuration working properly?

Step 5.7 Using the exit command, log out of the CoS host and then log out of your second SRX Series CLI session. Step 5.8 Return to the CLI session on your SRX Series student device. On the SRX Series device, navigate to the top hierarchy and issue the load override ajer/reset.config command to load the reset configuration file. Commit the changes, return to operational mode, and then log out of your assigned device. www.juniper.net



STOP



www.juniper.net

Lab 10 BGP Route Reflection

Overview Within a local autonomous system (AS) topology, the internal BGP (IBGP) peers are fully meshed to prevent routing loops from forming. A fully meshed network inherently has scalability issues, which include the explicit configuration of all IBGP peer with the addition of a new router. One method to alleviate the full mesh requirement and still ensure a loop-free BGP topology is route reflection. Route reflection provides a loop-detection mechanism within IBGP to allow IBGP routes to be readvertised to other IBGP peers. In this lab, you use the lab diagrams titled “Lab 10: BGP Route Reflection—Parts 1–2,” “Lab 10: BGP Route Reflection—Part 3,” and “Lab 10: BGP Route Reflection—Part 4” to configure and monitor BGP route reflection. By completing this lab, you will perform the following tasks:

www.juniper.net

•

Load the extended topology.

•

Verify standard IBGP behavior.

•

Configure route reflection.

•

Examine the reflected routes.

•

Add a third client router.

•

Verify routes on a third client router.

BGP Route Reflection • Lab 10–1 11.a.11.4R1.6


Part 1: Loading the Initial Configuration In this lab part, you load a baseline configuration that automatically configures your router according to the lab diagram labeled “Lab 10: BGP Route Reflection— Parts 1–2.” Step 1.1 Ensure that you know to which student device you have been assigned. Check with your instructor if you are not certain. Consult the management network diagram to determine the management address of your student device. Question: What is the management address assigned to your station?



Part 2: Verifying Topology In this lab part, you verify router-to-router connectivity and BGP operations using the command-line interface (CLI).

Lab 10–2 • BGP Route Reflection

www.juniper.net


The lab topology makes extensive use of virtual routing instances configured on the SRX Series student device. When using certain show commands, you must use the instance option and include the routing instance name (master, C1, C2, or C3). Furthermore, you must also use the table option to display routing table information specific to the routing instance with which you are working. Step 2.1 To verify your IGP is working properly on your student device, issue the run show ospf neighbor instance master command. You should have four OSPF adjacencies in the Full state. Two adjacencies are to your remote partner’s student device. The remaining two adjacencies are to each of your virtual routers (C1 and C2). Step 2.2 To verify your network has a full mesh of IBGP peers, issue the run show bgp summary instance instance-name command three times, once each where the instance name is master, C1, and C2. Your student device, and each of the two virtual routers, should each have five established BGP peers at this time, one to each of the other routers in the network. Step 2.3 Each virtual router is advertising a different route in the 200.200/16 space. To verify these routes are being propagated throughout the network, issue the run show route 200.200/16 table table-name command three times, once each where the table name is inet.0, C1.inet.0, and C2.inet.0. Question: How many routes are in each table?

Part 3: Converting to Route Reflectors To this point, we have verified that our fully meshed IBGP network is working properly. All the 200.200/16 routes are being propagated throughout the network. Now, imagine a scenario in which you need to add a new router to your network. To maintain the BGP requirement of a full mesh, you would have to configure six IBGP peering sessions on the new router, one for each of the existing routers. Furthermore, you would have to configure this new router as an IBGP peer on every other router in the network. What if you had 50 routers? 100? You can quickly see that the BGP requirement of a full mesh does not scale well. In this lab part, you reconfigure your current network into a route-reflected network. Use the lab diagram title “Lab 10: BGP Route Reflection—Part 3” for this section. www.juniper.net

BGP Route Reflection • Lab 10–3


Step 3.1 Navigate to the [edit protocols bgp] hierarchy and issue the show command to view the current BGP configuration for your student device. Step 3.2 Delete the my-int-group group and create a new group named my-mesh-group. Configure the my-mesh-group group as a standard IBGP session with only one neighbor—the other route reflector’s loopback address. Do not forget the type and local-address statements. Step 3.3 Navigate to the [edit protocols bgp group rr-cluster] hierarchy. Configure the rr-cluster group as an IBGP group that includes the loopback addresses of your two locally attached virtual routers as neighbors. Do not forget the type and local-address statements. However, do not include the cluster statement at this time. Step 3.4 Navigate to the [edit routing-instances C1 protocols bgp] hierarchy. Issue the show command to view the current BGP configuration for the C1 virtual router. Step 3.5 Within the my-int-group group, delete all neighbors except for the locally attached route-reflector loopback address. Step 3.6 Navigate to the [edit routing-instances C2 protocols bgp] hierarchy. Issue the show command to view the current BGP configuration for the C2 virtual router. Step 3.7 Within the my-int-group group, delete all neighbors except for the locally attached route-reflector loopback address. Refer to your lab diagram as needed. When complete, issue the commit command to activate your changes. Note

Before proceeding, ensure that the remote student team in your pod finishes the previous step. Step 3.8 Issue the run show route 200.200/16 table table-name command three times, once each where the table name is inet.0, C1.inet.0, and C2.inet.0.


www.juniper.net


Question: Are the 200.200/16 routes being propagated throughout the network? Why or why not?

Step 3.9 Navigate to the [edit protocols bgp group rr-cluster] hierarchy. Use the cluster statement to configure the cluster ID as shown on your lab diagram. When complete, issue the commit command to activate your changes. Note

Before proceeding, ensure that the remote student team in your pod finishes the previous step. Step 3.10 Issue the run show route 200.200/16 table table-name command three times, once each where the table name is inet.0, C1.inet.0, and C2.inet.0. Note

It might take a few moments for the routes to propagate and populate the tables. Question: Are the 200.200/16 routes being propagated throughout the network?

Step 3.11 Issue a run show route prefix/24 table C1.inet.0 detail command, where prefix is the route advertised from your local C2 virtual router. Question: What do you notice about the AS path information?

Step 3.12 Issue a run show route prefix/24 table C1.inet.0 detail command, where prefix is the route advertised from the remote C1 virtual router. Question: What is the cluster list value for this route?

www.juniper.net



Question: What does this cluster list value tell you about the route?

Part 4: Adding a New Router to the Network Use the lab diagram titled “Lab 10: BGP Route Reflection—Part 4” for the remainder of this lab. In this lab part, both teams add a new virtual router to the network. Refer to the lab diagram for your locally attached C3 virtual router. Now that we have a working, route-reflector setup, adding a new router is quickly and easily accomplished. Your local C3 router has been partially configured for you. On your assigned student device, you first add the necessary configuration to bring up the new router in OSPF. Next, you add this new router to your route-reflector cluster. Finally, you configure BGP on the C3 virtual router and verify it is receiving routes from the other virtual routers. Step 4.1 Navigate to the [edit protocols ospf area 0.0.0.0] hierarchy. Add the ge-0/0/14.3 interface to Area 0 with the interface-type p2p option. When complete, issue the commit command to activate your changes. Step 4.2 Issue the run show ospf neighbor interface ge-0/0/14.3 command to verify OSPF is working correctly on the new interface. Question: Did the interface transition to a Full state?

Step 4.3 Verify IGP connectivity by issuing the run ping local-C3-loopback-address rapid command. Question: Was the ping successful?

Step 4.4 Navigate to the [edit protocols bgp group rr-cluster] hierarchy. Add your local C3 router’s loopback address as a neighbor in the rr-cluster group. Step 4.5 Navigate to the [edit routing-instances C3 routing-options] hierarchy. Configure the AS number as shown on your lab diagram.


www.juniper.net


Step 4.6 Navigate to the [edit routing-instances C3 protocols bgp] hierarchy. Create an IBGP group named my-int-group. This group should contain a single neighbor of your locally attached route reflector’s loopback address. A policy named static-to-bgp has been preconfigured for you. Export this policy in your my-int-group. Also, do not forget the type and local-address statements. When complete, issue the commit command to activate your changes. Step 4.7 Issue the run show bgp summary instance C3 command to verify your new IBGP peering session is established. Note

Before proceeding, ensure that the remote student team in your pod finishes the previous step. Step 4.8 Issue the run show route 200.200/16 table C3.inet.0 command to verify your C3 router is receiving routes from the other virtual routers in the network. Question: How many routes are in the C3 router’s table?

Step 4.9 Navigate to the top hierarchy level and issue the load override /var/home/lab/ajer/reset.config command to load the reset configuration file. Commit the changes, return to operational mode, and then log out of your assigned device.

STOP

www.juniper.net





www.juniper.net

Advanced Junos Enterprise Routing Appendix A: Lab Diagrams


A–2 • Lab Diagrams

www.juniper.net


www.juniper.net

Lab Diagrams • A–3



www.juniper.net


www.juniper.net




www.juniper.net


www.juniper.net




www.juniper.net


www.juniper.net




www.juniper.net


www.juniper.net




www.juniper.net


www.juniper.net




www.juniper.net


www.juniper.net




www.juniper.net


www.juniper.net




www.juniper.net


www.juniper.net




www.juniper.net


www.juniper.net




www.juniper.net


www.juniper.net




www.juniper.net


www.juniper.net




www.juniper.net


www.juniper.net




www.juniper.net


www.juniper.net




www.juniper.net


www.juniper.net




www.juniper.net


www.juniper.net




www.juniper.net


www.juniper.net




www.juniper.net

AJER_11.a-R_LGH

Recommend Documents