Advanced Junos Enterprise Routing: Detailed Lab Guide

Advanced Junos Enterprise Routing
11.a
Detailed 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 Detailed Lab Guide, Revision 11.a Copyright 2012 Juniper Networks, Inc. All rights reserved. Printed in USA. Revision History: Revision 10.aMarch 2011. Revision 11.aApril 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 (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Part 1: Configuring and Monitoring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 Part 2: Configuring OSPF Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6 Part 3: Configuring OSPF Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
Lab 2:
Configuring and Monitoring OSPF Areas and Route Summarization (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Part 1: Configuring a Stub Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2 Part 2: Configuring an NSSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Lab 3:
Configuring and Monitoring Routing Policy and Advanced OSPF Options (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Part 1: Establishing the OSPF Adjacencies and Creating a Virtual Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 Part 2: Configuring OSPF Multiarea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7 Part 3: Configuring External Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
Lab 4:
Implementing BGP (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Part 1: Loading the Baseline Interface and OSPF Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 Part 2: Configuring IBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5 Part 3: Configuring and Monitoring EBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10 Part 4: Configuring BGP Multipath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21 Part 5: Configuring BGP Multihop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27
Lab 5:
BGP Attributes (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

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

Part 1: Loading the Initial Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2 Part 2: Configuring BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 Part 3: Implementing a Strict Primary/Secondary Routing Policy for Outbound Traffic . . . . . . . . . . . . . . . . . 6-5 Part 4: Implementing a Primary/Secondary Routing Policy for Inbound Traffic . . . . . . . . . . . . . . . . . . . . . . . 6-9 Part 5: Implementing a Loose Primary/Secondary Routing Policy for Outbound Traffic . . . . . . . . . . . . . . . 6-13 Part 6: Implementing Per-Prefix Load Sharing Outbound Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15 Part 7: Implementing Per-Prefix Load Sharing for Inbound Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19
Lab 7:
Implementing PIM-SM (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Part 1: Loading the Baseline Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2 Part 2: Configuring IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6 Part 3: Configuring PIM-SM with Static RP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11 Part 4: Configuring PIM-SM with the BSR mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16
www.juniper.net
Contents iii
Lab 8:
Implementing SSM (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Part 1: Disabling the Use of RPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2 Part 2: Configuring IGMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4 Part 3: Viewing PIM-SM SSM Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8 Part 4: Configuring an ssm-map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9
Lab 9:
Implementing CoS Features in the Enterprise (Detailed) . . . . . . . . . . . . . . . 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-8 Part 4: Configuring and Testing Schedulers and Drop Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-11 Part 5: Configuring and Testing a Rewrite Marker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-17
Lab 10: BGP Route Reflection (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Part 1: Loading the Initial Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2 Part 2: Verifying Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3 Part 3: Converting to Route Reflectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6 Part 4: Adding a New Router to the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-14
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 Franklin Gothic Courier New Description Normal text. Console text: Screen captures Noncommand-related syntax commit complete Exiting configuration mode Usage Example Most of what you read in the Lab Guide and Student Guide.
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 Normal CLI Normal GUI Description No distinguishing variant. Usage Example Physical interface:fxp0, Enabled View configuration history by clicking Configuration > History. CLI Input GUI Input Text that you must enter. lab@San_Jose> show route Select File > Save, and type config.ini in the Filename field.
Defined and Undefined Syntax Variables

Finally, this course distinguishes between regular text and syntax variables, and it also distinguishes between syntax variables where the value is already assigned (defined variables) and syntax variables where you must assign the value (undefined variables). Note that these styles can be combined with the input style as well. Style CLI Variable GUI Variable CLI Undefined Description Text where variable value is already assigned. Text where the variables value is the users discretion or text where the variables value as shown in the lab guide might differ from the value the user must input according to the lab topology. Usage Example policy my-peers Click my-peers in the dialog. Type set policy policy-name. ping 10.0.x.y Select File > Save, and type filename in the Filename field.
GUI Undefined
viii Document Conventions
www.juniper.net
Additional Information
Education Services Offerings
You can obtain information on the latest Education Services offerings, course dates, and class locations from the World Wide Web by pointing your Web browser to: http://www.juniper.net/training/education/.
About This Publication

The Advanced Junos Enterprise Routing Detailed 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 training@juniper.net.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats: Go to http://www.juniper.net/techpubs/. Locate the specific software or hardware release and title you need, and choose the format in which you want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or account representative.
Juniper Networks Support

For technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the United States).
www.juniper.net
Additional Information ix
x Additional Information
www.juniper.net
Lab 1
Configuring and Monitoring OSPF (Detailed)
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: Configure a multiarea OSPF network. Configure link costs and reference-bandwidth. Overload a router. Configure and troubleshoot OSPF authentication.
www.juniper.net
Configuring and Monitoring OSPF (Detailed) Lab 11 11.a.11.4R1.6
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?
Answer: The answer varies. The sample hostname and IP address used in the output examples in this lab are for srxA-1, which uses 10.210.14.131 as its management IP address. The actual management subnet varies between delivery environments. 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:
Lab 12 Configuring and Monitoring OSPF (Detailed)
www.juniper.net
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.
srxA-1 (ttyu0) login: lab Password: --- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC lab@srxA-1> configure Entering configuration mode [edit] lab@srxA-1# load override ajer/reset.config load complete [edit] lab@srxA-1# commit commit complete [edit] lab@srxA-1#
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.
[edit] lab@srxA-1# edit routing-options [edit routing-options] lab@srxA-1# set router-id address [edit routing-options] lab@srxA-1#
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.
[edit routing-options] lab@srxA-1# top edit protocols ospf [edit protocols ospf] lab@srxA-1# set area 0 interface lo0.0 [edit protocols ospf] lab@srxA-1# set area 0 interface ge-0/0/1.0 interface-type p2p
www.juniper.net Configuring and Monitoring OSPF (Detailed) Lab 13
[edit protocols ospf] lab@srxA-1# set area 0 interface ge-0/0/2.0 [edit protocols ospf] lab@srxA-1#
Note
Before proceeding, ensure that the remote student team in your pod finishes the previous step. Step 1.6 Activate the configuration and quickly issue the run show ospf neighbor command.
[edit protocols ospf] lab@srxA-1# commit commit complete [edit protocols ospf] lab@srxA-1# run show ospf neighbor Address Interface 172.20.77.2 ge-0/0/1.0 172.20.66.2 ge-0/0/2.0
State Full 2Way
ID 192.168.2.1 192.168.2.1
Pri 128 128
Dead 38 39
Question: Which neighbor states are shown for the listed interfaces and why?
Answer: The neighbor state for the ge-0/0/1.0 should immediately show Full and the ge-0/0/2.0 interface should be in 2Way or ExStart as shown in the previous sample output. Question: Why did the ge-0/0/1.0 interface form its adjacency more quickly than the ge-0/0/2.0 interface?
Answer: Adding the interface-type p2p option to a link tells OSPF not to perform a DR/BDR election on that link. This can save up to 40 seconds of wait time for the adjacency to form. Another benefit of the interface-type p2p option is that no Type 3 LSA is generated describing the multiaccess segment. This can help to reduce the size of the OSPF link-state database (LSDB).
Lab 14 Configuring and Monitoring OSPF (Detailed) www.juniper.net
Step 1.7 Issue the run show ospf interface command to view the interface states.
[edit protocols ospf] lab@srxA-1# run show ospf interface Interface State Area ge-0/0/1.0 PtToPt 0.0.0.0 ge-0/0/2.0 BDR 0.0.0.0 lo0.0 DR 0.0.0.0
DR ID 0.0.0.0 192.168.2.1 192.168.1.1
BDR ID 0.0.0.0 192.168.1.1 0.0.0.0
Nbrs 1 1 0
Question: What are the states of the two ethernet interfaces and what do they mean?
Answer: The ge-0/0/1.0 interface has a state of PtToPt because we configured it using the interface-type p2p option. No OSPF election occurred on this link, as shown by the 0.0.0.0 values in the DR ID and BDR ID fields. The output for the ge-0/0/2.0 interface might vary. The example output shows a state of BDR indicating this router was elected as the backup designated router for this segment. Step 1.8 Issue the run show ospf neighbor command again to verify the current OSPF adjacency details.
[edit protocols ospf] lab@srxA-1# run show ospf neighbor Address Interface 172.20.77.2 ge-0/0/1.0 172.20.66.2 ge-0/0/2.0
State Full Full
ID 192.168.2.1 192.168.2.1
Pri 128 128
Dead 37 37
Question: How many OSPF neighbors exist and what are the states of those adjacencies?
Answer: You should eventually see two OSPF neighbors in the Full adjacency state. If you do not see two OSPF neighbors in the Full adjacency state, check your configuration and, if necessary, work with the instructor.
www.juniper.net
Configuring and Monitoring OSPF (Detailed) Lab 15
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.
[edit protocols ospf] lab@srxA-1# run show ospf route Topology default Route Table: Prefix 192.168.2.1 172.20.66.0/30 172.20.77.0/30 192.168.1.1/32 192.168.2.1/32 Path Route Type Type Intra Router Intra Intra Intra Intra Network Network Network Network NH Type IP IP IP IP IP Metric NextHop Interface 1 ge-0/0/1.0 ge-0/0/2.0 1 ge-0/0/2.0 1 ge-0/0/1.0 0 lo0.0 1 ge-0/0/1.0 ge-0/0/2.0 Nexthop Address/LSP 172.20.77.2 172.20.66.2
172.20.77.2 172.20.66.2
Question: What is the current metric associated with the displayed OSPF routes?
Answer: With the exception of the OSPF route for the local devices loopback address, all OSPF routes should show a metric of one (1). The metric for the locally defined loopback address should be zero (0).
www.juniper.net
Question: Why does the output show two entries with the same prefix?
Answer: The two entries with the same prefix information represent the router ID and IP address assigned to the remote team device. In the example shown in the previous output, the 192.168.2.1 Router entry is associated with the router ID, whereas the 192.168.2.1/32 Network entry is the IP address assigned to the lo0.0 interface of the remote team device. 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.
[edit protocols ospf] lab@srxA-1# set area 0 interface ge-0/0/2.0 metric 100 [edit protocols ospf] lab@srxA-1# commit commit complete [edit protocols ospf] lab@srxA-1# run show ospf route Topology default Route Table: Prefix 192.168.2.1 172.20.66.0/30 172.20.77.0/30 192.168.1.1/32 192.168.2.1/32 Path Type Intra Intra Intra Intra Intra Route Type Router Network Network Network Network NH Type IP IP IP IP IP Metric NextHop Interface 1 ge-0/0/1.0 100 ge-0/0/2.0 1 ge-0/0/1.0 0 lo0.0 1 ge-0/0/1.0 Nexthop Address/LSP 172.20.77.2
172.20.77.2
Question: What is the current metric associated with the 172.20.66.0/30 OSPF route?
Answer: The metric for the referenced prefix should now show 100; previously, it was 1.
www.juniper.net
Question: What was the effect of the increased metric on the route associated with the remote student devices loopback address?
Answer: Because the ge-0/0/2.0 interface now has a higher metric or cost, the route associated with the remote student devices loopback lists only the ge-0/0/1.0 interface as the next-hop interface; previously, both ge-0/0/1.0 and ge-0/0/2.0 were next-hops because they had the same metric. 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.
[edit protocols ospf] lab@srxA-1# run show ospf interface ge-0/0/2.0 detail Interface State Area DR ID BDR ID Nbrs ge-0/0/2.0 BDR 0.0.0.0 192.168.2.1 192.168.1.1 1 Type: LAN, Address: 172.20.66.1, Mask: 255.255.255.252, MTU: 1500, Cost: 100 DR addr: 172.20.66.2, BDR addr: 172.20.66.1, Priority: 128 Adj count: 1 Hello: 10, Dead: 40, ReXmit: 5, Not Stub Auth type: None Protection type: None Topology default (ID 0) -> Cost: 100
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.
[edit protocols ospf] lab@srxA-1# set reference-bandwidth 10g [edit protocols ospf] lab@srxA-1# commit commit complete [edit protocols ospf] lab@srxA-1# run show ospf route Topology default Route Table: Prefix 192.168.2.1 172.20.66.0/30 172.20.77.0/30 192.168.1.1/32 192.168.2.1/32 Path Type Intra Intra Intra Intra Intra Route Type Router Network Network Network Network NH Type IP IP IP IP IP Metric NextHop Interface 10 ge-0/0/1.0 100 ge-0/0/2.0 10 ge-0/0/1.0 0 lo0.0 10 ge-0/0/1.0 Nexthop Address/LSP 172.20.77.2
172.20.77.2
www.juniper.net
Question: What was the effect of setting the reference-bandwidth to 10g?
Answer: The ge-0/0/1.0 interfaces metric increased to 10 (from 1) because of the changes made to the reference-bandwidth setting. Question: Why did the metric associated with ge-0/0/2.0 remain unchanged?
Answer: Recall that we manually set the metric for the ge-0/0/2.0 interface. Interfaces that have their metric manually configured are unaffected by changes made by the reference-bandwidth setting. 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.
[edit protocols ospf] lab@srxA-1# set area area interface ge-0/0/4.unit [edit protocols ospf] lab@srxA-1# commit commit complete
Step 2.6 Issue the run show ospf neighbor command to verify the current OSPF adjacency details.
[edit protocols ospf] lab@srxA-1# run show ospf neighbor Address Interface 172.20.77.2 ge-0/0/1.0 172.20.66.2 ge-0/0/2.0 172.20.111.10 ge-0/0/4.111
State Full Full Full
ID 192.168.2.1 192.168.2.1 192.168.1.2
Pri 128 128 128
Dead 37 37 31
www.juniper.net
Question: How many OSPF neighbors exist and what are the states of those adjacencies?
Answer: You should now see three OSPF neighbors and they should each be in the Full adjacency state. If you do not see three OSPF neighbors in the Full adjacency state, check your configuration and, if necessary, work with the instructor. 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.
[edit protocols ospf] lab@srxA-1# run ping local-vr-loopback rapid PING 192.168.1.2 (192.168.1.2): 56 data bytes !!!!! --- 192.168.1.2 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.437/4.057/8.057/3.122 ms
Question: Was the ping to your attached virtual router successful?
Answer: Yes, the ping should be successful. If the ping is not successful, double-check your configuration and notify your instructor.
Note
Before proceeding, ensure that the remote team in your pod finishes the previous step.
Note
The next two lab steps require you to log in to the virtual router attached to your teams device. The virtual routers are logical devices created on a J Series Services Router.
www.juniper.net
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.
srxA-1 (ttyu0) login: lab Password: --- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC lab@srxA-1>
Step 2.9 From the second CLI session to your student device, telnet to your virtual routers loopback address. Log in to the virtual router using the login information shown in the following table: Virtual Router Login Details Student Device srxA-1 srxA-2 srxB-1 srxB-2 srxC-1 srxC-2 srxD-1 srxD-2 Username a1 a2 b1 b2 c1 c2 d1 d2 Password lab123 lab123 lab123 lab123 lab123 lab123 lab123 lab123
lab@srxA-1> telnet local-vr-loopback Trying 192.168.1.2... Connected to 192.168.1.2. Escape character is '^]'. This device has been configured to run the AJER course
www.juniper.net
vr-device (ttyp1) login: username Password: password --- JUNOS 11.4R1.6 built 2011-11-15 11:28:05 UTC NOTE: This router is divided into many virtual routers used by different teams. Please only configure your own virtual router. You must use 'configure private' to configure this router. a1@vr-device>
Step 2.10 Verify reachability back to your student devices 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 srxA-1 srxA-2 srxB-1 srxB-2 srxC-1 srxC-2 srxD-1 srxD-2 Instance Name vr111 vr112 vr113 vr114 vr115 vr116 vr117 vr118
a1@vr-device> ping routing-instance instance-name student-device-loopback rapid PING 192.168.1.1 (192.168.1.1): 56 data bytes !!!!! --- 192.168.1.1 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 9.884/11.850/18.420/3.300 ms
www.juniper.net
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 teams virtual routers loopback address. Use the table from the previous step for the instance name.
a1@vr-device> show route remote-virtual-router-loopback/32 table instance-name vr111.inet.0: 21 destinations, 28 routes (21 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.2.2/32 *[OSPF/10] 00:03:39, metric 21 > to 172.20.111.1 via ge-0/0/1.111
Question: What is the OSPF cost to reach the remote virtual routers loopback address?
Answer: The cost for this route is 21. 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.
[edit protocols ospf] lab@srxA-1# set overload [edit protocols ospf] lab@srxA-1# commit commit complete
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.
a1@vr-device> show route remote-virtual-router-loopback/32 table instance-name vr111.inet.0: 21 destinations, 28 routes (21 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.2.2/32 *[OSPF/10] 00:00:39, metric 131071 > to 172.20.111.1 via ge-0/0/1.111
a1@vr-device>
www.juniper.net
Question: Did the metric change? If so, what did it change to and why?
Answer: Yes, depending on the remote student team, you might see the metric change to 65546 or 131071. The metric changes because overloading a router automatically increases its metric by 65535. Question: Why would you overload a router?
Answer: The main reason for overloading a router is to force transit traffic off of it. This could be because of maintenance or if the router is experiencing other types of trouble. 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.
a1@vr-device> exit Connection closed by foreign host. lab@srxA-1> exit
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.
[edit protocols ospf] lab@srxA-1# delete overload [edit protocols ospf] lab@srxA-1# commit commit complete
STOP
www.juniper.net
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 devices current configuration to make it incompatible with team 2s 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 1s 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.
[edit protocols ospf] lab@srxA-1# set area 0 interface ge-0/0/1.0 authentication md5 1 key juniper [edit protocols ospf] lab@srxA-1# commit commit complete
Step 3.2 This step is for both teams. Issue a run show ospf neighbor command.
[edit protocols ospf] lab@srxA-1# run show ospf neighbor Address Interface 172.20.66.2 ge-0/0/2.0 172.20.111.10 ge-0/0/4.111
State Full Full
ID 192.168.2.1 192.168.1.2
Pri 128 128
Dead 35 33
Question: How many OSPF neighbors does your assigned device currently have?
Answer: At this point, your device should have only two neighbors (instead of three). The neighbor adjacency across the ge-0/0/1 interface should no longer be in place because of team 1s recent configuration change. It might take up to forty seconds for the ge-0/0/1.0 neighbor to drop because of the OSPF dead timer. Step 3.3 This step is for both teams.
www.juniper.net
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.
[edit protocols ospf] lab@srxA-1# set traceoptions file trace-ospf [edit protocols ospf] lab@srxA-1# set traceoptions flag error detail [edit protocols ospf] lab@srxA-1# commit commit complete
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.
[edit protocols ospf] lab@srxA-1# run show log trace-ospf Feb 22 21:42:24 trace_on: Tracing to "/var/log/trace-ospf" Feb 22 21:42:30.224638 OSPF packet ignored: authentication from 172.20.77.2 Feb 22 21:42:38.426655 OSPF packet ignored: authentication from 172.20.77.2 Feb 22 21:42:38.440217 OSPF packet ignored: authentication from 172.20.77.2 [...]
started type mismatch (0) type mismatch (0) type mismatch (0)
Question: Does the generated error in the trace file explain the current OSPF adjacency issue?
Answer: Yes, based on the contents of the trace file, an authentication mismatch exists. 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.
[edit protocols ospf] lab@srxA-2# set area 0 interface ge-0/0/1.0 authentication md5 1 key juniper [edit protocols ospf] lab@srxA-2# commit commit complete
www.juniper.net
[edit protocols ospf] lab@srxA-2#
Step 3.6 This step is for both teams. Issue a run show ospf neighbor command.
[edit protocols ospf] lab@srxA-1# run show ospf neighbor Address Interface 172.20.77.2 ge-0/0/1.0 172.20.66.2 ge-0/0/2.0 172.20.111.10 ge-0/0/4.111 [edit protocols ospf] lab@srxA-1#
ID 192.168.2.1 192.168.2.1 192.168.1.2
Pri 128 128 128
Dead 39 37 39
Question: Did the OSPF adjacency across the ge-0/0/1.0 interface return to the Full state?
Answer: Yes, you should now see all three neighbors in the Full adjacency state, as shown in the previous output. 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.
[edit protocols ospf] lab@srxA-1# deactivate traceoptions [edit protocols ospf] lab@srxA-1# run file delete /var/log/trace-ospf [edit protocols ospf] lab@srxA-1# commit and-quit commit complete Exiting configuration mode lab@srxA-1>
Step 3.8 Log out of your assigned device using the exit command.
lab@srxA-1> exit
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 (Detailed)
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: Create a stub area. Change the stub area to a totally stubby area. Create a not-so-stubby area. Perform route summarization.
www.juniper.net
Configuring and Monitoring OSPF Areas and Route Summarization (Detailed) Lab 21 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
Lab 22 Configuring and Monitoring OSPF Areas and Route Summarization (Detailed)
www.juniper.net
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.
srxA-1 (ttyu0) login: lab Password: --- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC lab@srxA-1> configure Entering configuration mode [edit] lab@srxA-1# load override ajer/lab2-start.config load complete [edit] lab@srxA-1# commit commit complete
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.
[edit] lab@srxA-1# edit interfaces ge-0/0/4 [edit interfaces ge-0/0/4] lab@srxA-1# set unit unit vlan-id vlan-id family inet address address/24 [edit interfaces ge-0/0/4] lab@srxA-1# show vlan-tagging; unit 111 { vlan-id 111; family inet { address 172.20.111.1/24; } } unit 151 { vlan-id 151; family inet { address 172.20.151.1/24; } } [edit interfaces ge-0/0/4] lab@srxA-1#
www.juniper.net
Configuring and Monitoring OSPF Areas and Route Summarization (Detailed) Lab 23
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 .
[edit interfaces ge-0/0/4] lab@srxA-1# top edit protocols ospf [edit protocols ospf] lab@srxA-1# set area area stub [edit protocols ospf] lab@srxA-1# set area area interface ge-0/0/4.unit [edit protocols ospf] lab@srxA-1# show area area stub; interface ge-0/0/4.151; [edit protocols ospf] lab@srxA-1#
Step 1.6 Activate the configuration and issue the run show ospf neighbor command.
[edit protocols ospf] lab@srxA-1# commit commit complete [edit protocols ospf] lab@srxA-1# run show ospf neighbor Address Interface 172.20.77.2 ge-0/0/1.0 172.20.66.2 ge-0/0/2.0 172.20.111.10 ge-0/0/4.111 172.20.151.10 ge-0/0/4.151
State Full Full Full Full
ID 192.168.2.1 192.168.2.1 192.168.1.2 192.168.3.2
Pri 128 128 128 128
Dead 35 35 33 33
Question: Did the new neighbor come up to a Full state?
Answer: The neighbor state for the new ge-0/0/4.unit interface should be Full, as shown in the previous sample output. If you do not see the Full state for this interface, check your configuration and, if necessary, work with the instructor.
www.juniper.net
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.
[edit protocols ospf] lab@srxA-1# run show ospf interface detail | find ge-0/0/4 ge-0/0/4.111 BDR 0.0.0.1 192.168.1.2 192.168.1.1 Type: LAN, Address: 172.20.111.1, Mask: 255.255.255.0, MTU: 1500, Cost: 10 DR addr: 172.20.111.10, BDR addr: 172.20.111.1, Priority: 128 Adj count: 1 Hello: 10, Dead: 40, ReXmit: 5, Not Stub Auth type: None Protection type: None Topology default (ID 0) -> Cost: 10 ge-0/0/4.151 BDR 0.0.0.3 192.168.3.2 192.168.1.1 Type: LAN, Address: 172.20.151.1, Mask: 255.255.255.0, MTU: 1500, Cost: 10 DR addr: 172.20.151.10, BDR addr: 172.20.151.1, Priority: 128 Adj count: 1 Hello: 10, Dead: 40, ReXmit: 5, Stub Auth type: None Protection type: None Topology default (ID 0) -> Cost: 10
Question: Is the new interface correctly set as Stub?
Answer: The output shows the new interface set as Stub (as opposed to Not Stub in the non-stub area). If you do not see this setting, check your configuration and, if necessary, work with the instructor. 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.
[edit protocols ospf] lab@srxA-1# run show ospf database area area summary Area 0.0.0.3: 2 Router LSAs 1 Network LSAs 10 Summary LSAs Externals: 6 Extern LSAs Interface ge-0/0/1.0: Area 0.0.0.0: Interface ge-0/0/2.0:
www.juniper.net Configuring and Monitoring OSPF Areas and Route Summarization (Detailed) Lab 25
Area 0.0.0.0: Interface ge-0/0/4.111: Area 0.0.0.1: Interface ge-0/0/4.151: Area 0.0.0.3: Interface lo0.0: Area 0.0.0.0: [edit protocols ospf] lab@srxA-1# run show ospf database area area OSPF database, Area 0.0.0.3 Type ID Adv Rtr Router *192.168.1.1 192.168.1.1 Router 192.168.3.2 192.168.3.2 Network 172.20.151.10 192.168.3.2 Summary *172.20.66.0 192.168.1.1 Summary *172.20.77.0 192.168.1.1 Summary *172.20.111.0 192.168.1.1 Summary *172.20.112.0 192.168.1.1 Summary *172.20.152.0 192.168.1.1 Summary *192.168.1.1 192.168.1.1 Summary *192.168.1.2 192.168.1.1 Summary *192.168.2.1 192.168.1.1 Summary *192.168.2.2 192.168.1.1 Summary *192.168.4.2 192.168.1.1 OSPF AS SCOPE link state database Type ID Adv Rtr Extern 172.21.0.0 192.168.1.2 Extern 172.21.1.0 192.168.1.2 Extern 172.21.2.0 192.168.1.2 Extern 172.22.0.0 192.168.2.2 Extern 172.22.1.0 192.168.2.2 Extern 172.22.2.0 192.168.2.2
Seq 0x80000004 0x80000007 0x80000001 0x80000003 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 Seq 0x8000007b 0x8000007b 0x8000007a 0x8000007b 0x8000007b 0x8000007b
Age 350 352 352 350 356 356 356 348 356 356 356 356 59 Age 1148 560 1898 1661 940 370
Opt 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 Opt 0x22 0x22 0x22 0x22 0x22 0x22
Cksum Len 0xf89c 36 0xed21 48 0xf799 32 0xd597 28 0xd8e5 28 0x7326 28 0xccc1 28 0x1353 28 0xc7a0 28 0x223b 28 0x213c 28 0x7bd6 28 0x65ea 28 Cksum Len 0x2bde 36 0x20e8 36 0x17f1 36 0x18ef 36 0xdf9 36 0x204 36
Question: How many summary LSAs are in your stub area?
Answer: There are ten summary LSAs, as shown in the previous sample output. Step 1.9 Convert your stub area to a totally stubby area using the no-summaries option and activate your changes.
[edit protocols ospf] lab@srxA-1# set area area stub no-summaries [edit protocols ospf] lab@srxA-1# show area area stub no-summaries;
Lab 26 Configuring and Monitoring OSPF Areas and Route Summarization (Detailed) www.juniper.net
interface ge-0/0/4.151; [edit protocols ospf] lab@srxA-1# commit commit complete
Step 1.10 Issue the run show ospf database area area summary and run show ospf database area area commands again.
[edit protocols ospf] lab@srxA-1# run show ospf database area area summary Area 0.0.0.3: 2 Router LSAs 1 Network LSAs Externals: 6 Extern LSAs Interface ge-0/0/1.0: Area 0.0.0.0: Interface ge-0/0/2.0: Area 0.0.0.0: Interface ge-0/0/4.111: Area 0.0.0.1: Interface ge-0/0/4.151: Area 0.0.0.3: Interface lo0.0: Area 0.0.0.0: [edit protocols ospf] lab@srxA-1# run show ospf database area area OSPF database, Area 0.0.0.3 Type ID Adv Rtr Router *192.168.1.1 192.168.1.1 Router 192.168.3.2 192.168.3.2 Network 172.20.151.10 192.168.3.2 OSPF AS SCOPE link state database Type ID Adv Rtr Extern 172.21.0.0 192.168.1.2 Extern 172.21.1.0 192.168.1.2 Extern 172.21.2.0 192.168.1.2 Extern 172.22.0.0 192.168.2.2 Extern 172.22.1.0 192.168.2.2 Extern 172.22.2.0 192.168.2.2
Seq 0x80000006 0x80000009 0x80000003 Seq 0x8000007b 0x8000007b 0x8000007b 0x8000007b 0x8000007b 0x8000007b
Age 149 155 155 Age 1376 788 199 1889 1168 598
Opt 0x20 0x20 0x20 Opt 0x22 0x22 0x22 0x22 0x22 0x22
Cksum Len 0xf49e 36 0xe923 48 0xf39b 32 Cksum Len 0x2bde 36 0x20e8 36 0x15f2 36 0x18ef 36 0xdf9 36 0x204 36
Question: How many summary LSAs are now in your stub area?
Answer: You should not see any summary LSAs in your stub areas database. If you do see summary LSAs, check your configuration and, if necessary, work with the instructor.
Question: Why are there no summary LSAs?
Answer: In a totally stubby area, summary LSAs are not allowed. Reachability to external destinations is accomplished by injecting a default route into the area. 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.
[edit protocols ospf] lab@srxA-1# set area area stub default-metric 10 [edit protocols ospf] lab@srxA-1# show area area stub default-metric 10 no-summaries; interface ge-0/0/4.151; [edit protocols ospf] lab@srxA-1# commit commit complete
Step 1.12 Issue the run show ospf database area area summary and run show ospf database area area commands again.
[edit protocols ospf] lab@srxA-1# run show ospf database area area summary Area 0.0.0.3: 2 Router LSAs 1 Network LSAs 1 Summary LSAs Externals: 6 Extern LSAs Interface ge-0/0/1.0: Area 0.0.0.0: Interface ge-0/0/2.0: Area 0.0.0.0: Interface ge-0/0/4.111: Area 0.0.0.1: Interface ge-0/0/4.151: Area 0.0.0.3: Interface lo0.0: Area 0.0.0.0: [edit protocols ospf] lab@srxA-1# run show ospf database area area
www.juniper.net
OSPF database, Area 0.0.0.3 Type ID Adv Rtr Router *192.168.1.1 192.168.1.1 Router 192.168.3.2 192.168.3.2 Network 172.20.151.10 192.168.3.2 Summary *0.0.0.0 192.168.1.1 OSPF AS SCOPE link state database Type ID Adv Rtr Extern 172.21.0.0 192.168.1.2 Extern 172.21.1.0 192.168.1.2 Extern 172.21.2.0 192.168.1.2 Extern 172.22.0.0 192.168.2.2 Extern 172.22.1.0 192.168.2.2 Extern 172.22.2.0 192.168.2.2
Seq 0x80000007 0x80000009 0x80000003 0x80000001 Seq 0x8000007b 0x8000007b 0x8000007b 0x8000007c 0x8000007b 0x8000007b
Age 64 298 298 64 Age 1519 931 342 54 1311 741
Opt 0x20 0x20 0x20 0x20 Opt 0x22 0x22 0x22 0x22 0x22 0x22
Cksum Len 0xf29f 36 0xe923 48 0xf39b 32 0xf2d6 28 Cksum Len 0x2bde 36 0x20e8 36 0x15f2 36 0x16f0 36 0xdf9 36 0x204 36
Question: How many summary LSAs are now in your stub area?
Answer: You should now see one summary LSA in your stub areas database with a value of 0.0.0.0. This is the default route being injected by the ABR. If you do not see this LSA, check your configuration and, if necessary, work with the instructor.
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.
[edit protocols ospf] lab@srxA-1# top edit interfaces ge-0/0/4 [edit interfaces ge-0/0/4] lab@srxA-1# set unit unit vlan-id vlan-id family inet address address/24 [edit interfaces ge-0/0/4] lab@srxA-1# show vlan-tagging; unit 111 { vlan-id 111; family inet {
address 172.20.111.1/24; } } unit 151 { vlan-id 151; family inet { address 172.20.151.1/24; } } unit 161 { vlan-id 161; family inet { address 172.20.161.0/24; } } [edit interfaces ge-0/0/4] lab@srxA-1#
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.
[edit interfaces ge-0/0/4] lab@srxA-1# top edit protocols ospf [edit protocols ospf] lab@srxA-1# set area area nssa [edit protocols ospf] lab@srxA-1# set area area interface ge-0/0/4.unit [edit protocols ospf] lab@srxA-1# show area area nssa; interface ge-0/0/4.161; [edit protocols ospf] lab@srxA-1#
Step 2.3 Activate the configuration and issue the run show ospf neighbor command.
[edit protocols ospf] lab@srxA-1# commit commit complete [edit protocols ospf] lab@srxA-1# run show ospf neighbor
www.juniper.net
Address 172.20.77.2 172.20.66.2 172.20.111.10 172.20.151.10 172.20.161.10
Interface ge-0/0/1.0 ge-0/0/2.0 ge-0/0/4.111 ge-0/0/4.151 ge-0/0/4.161
State Full Full Full Full Full
ID 192.168.2.1 192.168.2.1 192.168.1.2 192.168.3.2 192.168.5.2
Pri 128 128 128 128 128
Dead 33 33 39 36 34
Question: Did the new neighbor come up to a full state?
Answer: The neighbor state for the new ge-0/0/4.unit interface should be Full, as shown in the sample output. If you do not see the Full state for this interface, check your configuration and, if necessary, work with the instructor. 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.
[edit protocols ospf] lab@srxA-1# run show ospf interface ge-0/0/4.unit detail Interface State Area DR ID BDR ID Nbrs ge-0/0/4.161 BDR 0.0.0.5 192.168.5.2 192.168.1.1 1 Type: LAN, Address: 172.20.161.1, Mask: 255.255.255.0, MTU: 1500, Cost: 10 DR addr: 172.20.161.10, BDR addr: 172.20.161.1, Priority: 128 Adj count: 1 Hello: 10, Dead: 40, ReXmit: 5, Stub NSSA Auth type: None Protection type: None Topology default (ID 0) -> Cost: 10
Question: Is the new interface correctly set as an NSSA interface?
Answer: The output shows the new interface set as Stub NSSA. If you do not see this setting, check your configuration and, if necessary, work with the instructor.
Note
Before proceeding, ensure that the remote team in your pod finishes the previous step.
www.juniper.net
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.
[edit protocols ospf] lab@srxA-1# run show ospf database area area summary Area 0.0.0.5: 2 Router LSAs 1 Network LSAs 13 Summary LSAs 4 NSSA LSAs Externals: 14 Extern LSAs Interface ge-0/0/1.0: Area 0.0.0.0: Interface ge-0/0/2.0: Area 0.0.0.0: Interface ge-0/0/4.111: Area 0.0.0.1: Interface ge-0/0/4.151: Area 0.0.0.3: Interface ge-0/0/4.161: Area 0.0.0.5: Interface lo0.0: Area 0.0.0.0: [edit protocols ospf] lab@srxA-1# run show ospf database area area nssa OSPF Type NSSA NSSA NSSA NSSA database, Area 0.0.0.5 ID Adv Rtr 172.61.0.0 192.168.5.2 172.61.1.0 192.168.5.2 172.61.2.0 192.168.5.2 172.61.3.0 192.168.5.2
Seq 0x80000004 0x80000003 0x80000003 0x80000003
Age 76 2474 1875 1276
Opt 0x28 0x28 0x28 0x28
Cksum Len 0xc31d 36 0xba26 36 0xaf30 36 0xa43a 36
Question: How many NSSA LSAs are in your NSSA areas database?
Answer: There should be four NSSA LSAs. If not, check your configuration and, if necessary, work with the instructor. Step 2.6 Issue the run show ospf database external command to see external LSAs contained in the OSPF database.
[edit protocols ospf] lab@srxA-1# run show ospf database external
Lab 212 Configuring and Monitoring OSPF Areas and Route Summarization (Detailed) www.juniper.net
OSPF AS SCOPE link state database Type ID Adv Rtr Extern 172.21.0.0 192.168.1.2 Extern 172.21.1.0 192.168.1.2 Extern 172.21.2.0 192.168.1.2 Extern 172.22.0.0 192.168.2.2 Extern 172.22.1.0 192.168.2.2 Extern 172.22.2.0 192.168.2.2 Extern *172.61.0.0 192.168.1.1 Extern *172.61.1.0 192.168.1.1 Extern *172.61.2.0 192.168.1.1 Extern *172.61.3.0 192.168.1.1 Extern 172.62.0.0 192.168.2.1 Extern 172.62.1.0 192.168.2.1 Extern 172.62.2.0 192.168.2.1 Extern 172.62.3.0 192.168.2.1
Seq 0x8000007b 0x8000007b 0x8000007b 0x8000007c 0x8000007b 0x8000007b 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001
Age 1941 1353 764 476 1733 1163 165 165 165 165 203 203 203 203
Opt 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
Cksum Len 0x2bde 36 0x20e8 36 0x15f2 36 0x16f0 36 0xdf9 36 0x204 36 0x628e 36 0x5798 36 0x4ca2 36 0x41ac 36 0x5c91 36 0x519b 36 0x46a5 36 0x3baf 36
Question: Are the external LSAs that describe the remote teams NSSA routes present?
Answer: Yes, they are present. The example output is from the srxX-1 router, so the remote teams NSSA LSAs are the four 172.62.x.x entries. From the perspective of the srxX-2 router, the remote teams NSSA LSAs are the 172.61.x.x entries. Note that no summary route exists for these networks. Question: How many external LSAs are present?
Answer: There are 14 external LSAs, as shown in the example output. Step 2.7 Each of the external NSSA destinations is represented by a /24 network. Choose one of the remote teams destinations and issue a run show route destination command for that destination.
[edit protocols ospf] lab@srxA-1# run show route destination inet.0: 38 destinations, 38 routes (38 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.62.0.0/24 *[OSPF/150] 00:06:01, metric 0, tag 0 > to 172.20.77.2 via ge-0/0/1.0
www.juniper.net
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.
[edit protocols ospf] lab@srxA-1# set area area nssa area-range summary-address/22 [edit protocols ospf] lab@srxA-1# show area area nssa { area-range 172.61.0.0/22; } interface ge-0/0/4.161; [edit protocols ospf] lab@srxA-1# commit and-quit commit complete Exiting configuration mode lab@srxA-1>
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.
lab@srxA-1> show ospf database external OSPF AS SCOPE link state database Type ID Adv Rtr Extern 172.21.0.0 192.168.1.2 Extern 172.21.1.0 192.168.1.2 Extern 172.21.2.0 192.168.1.2 Extern 172.22.0.0 192.168.2.2 Extern 172.22.1.0 192.168.2.2 Extern 172.22.2.0 192.168.2.2 Extern *172.61.0.0 192.168.1.1 Extern 172.62.0.0 192.168.2.1
Seq 0x8000007b 0x8000007b 0x8000007b 0x8000007c 0x8000007c 0x8000007b 0x80000002 0x80000002
Age 2294 1706 1117 829 251 1516 46 30
Opt 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
Cksum Len 0x2bde 36 0x20e8 36 0x15f2 36 0x16f0 36 0xbfa 36 0x204 36 0x3d21 36 0x2a32 36
www.juniper.net
Question: Were the changes successful? How can you tell?
Answer: Yes, the changes were successful. Instead of eight total LSAs representing the 172.6x.x.x routes, we now have two. This has resulted in a smaller link-state database and demonstrates one mechanism you can use to scale OSPF networks. Step 2.10 Choose one of the remote teams 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.
lab@srxA-1> show route destination inet.0: 36 destinations, 36 routes (36 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.62.0.0/22 *[OSPF/150] 00:01:12, metric 1, tag 0 > to 172.20.77.2 via ge-0/0/1.0
lab@srxA-1> exit
STOP
www.juniper.net
www.juniper.net
Lab 3
Configuring and Monitoring Routing Policy and Advanced OSPF Options (Detailed)
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: 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.
www.juniper.net
Configuring and Monitoring Routing Policy and Advanced OSPF Options (Detailed) Lab 31 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 32 Configuring and Monitoring Routing Policy and Advanced OSPF Options (Detailed)
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.
[edit] lab@srxA-1# edit protocols ospf [edit protocols ospf] lab@srxA-1# set area 0 interface lo0.0 [edit protocols ospf] lab@srxA-1# set area 0 interface P1-interface [edit protocols ospf] lab@srxA-1# set area 20 interface P2-interface [edit protocols ospf] lab@srxA-1# set area 10 nssa default-lsa default-metric 10 [edit protocols ospf] lab@srxA-1# set area 10 interface ge-0/0/14
www.juniper.net
Configuring and Monitoring Routing Policy and Advanced OSPF Options (Detailed) Lab 33
[edit protocols ospf] lab@srxA-1# commit commit complete [edit protocols ospf] lab@srxA-1#
Step 1.5 Use the run show ospf interface command to verify which interfaces are participating in OSPF.
[edit protocols ospf] lab@srxA-1# run show ospf interface Interface State Area ge-0/0/4.1211 BDR 0.0.0.0 lo0.0 DR 0.0.0.0 ge-0/0/14.0 BDR 0.0.0.10 ge-0/0/4.1213 BDR 0.0.0.20
DR ID 192.168.100.1 192.168.1.1 192.168.1.2 192.168.101.1
BDR ID 192.168.1.1 0.0.0.0 192.168.1.1 192.168.1.1
Nbrs 1 0 1 1
Question: How many interfaces are running OSPF?
Answer: Three transit interfaces and the loopback interface exist, for a total of four interfaces running OSPF. Step 1.6 Use the run show ospf neighbor command to verify the establishment of the OSPF adjacencies.
[edit protocols ospf] lab@srxA-1# run show ospf neighbor Address Interface 172.22.121.2 ge-0/0/4.1211 10.0.10.2 ge-0/0/14.0 172.22.123.2 ge-0/0/4.1213
ID 192.168.100.1 192.168.1.2 192.168.101.1
Pri 128 128 128
Dead 33 37 35
Question: Are all OSPF adjacencies established and in the Full state?
Answer: Yes, three OSPF adjacencies should be established, one in each OSPF area. 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.
Lab 34 Configuring and Monitoring Routing Policy and Advanced OSPF Options (Detailed) www.juniper.net
[edit protocols ospf] lab@srxA-1# run show route protocol ospf table 192.168.1.2/32 *[OSPF/10] 00:03:07, metric 192.168.2.1/32 *[OSPF/10] 00:02:22, metric 192.168.2.2/32 *[OSPF/10] 00:03:07, metric 192.168.100.1/32 *[OSPF/10] 00:02:57, metric 192.168.101.1/32 *[OSPF/10] 00:02:57, metric 192.168.102.1/32 *[OSPF/10] 00:03:07, metric 224.0.0.5/32 *[OSPF/10] 00:03:12, metric
inet.0 | match /32 1 2 3 1 1 2 1
Question: Is there an entry in the primary routing table (inet.0) for all six loopback addresses within the OSPF domain?
Answer: Yes, if your partner has successfully configured OSPF, six host addresses should exist in the inet.0 routing table, one for each loopback address. 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 partners 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.
[edit protocols ospf] lab@srxA-1# edit area 0 [edit protocols ospf area 0.0.0.0] lab@srxA-1# set virtual-link transit-area 20 neighbor-id address [edit protocols ospf area 0.0.0.0] lab@srxA-1# up [edit protocols ospf] lab@srxA-1# set area 20 interface P2-interface metric 10 [edit protocols ospf] lab@srxA-1# commit commit complete
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.
[edit protocols ospf] lab@srxA-1# run show ospf interface
www.juniper.net
Interface ge-0/0/4.1211 lo0.0 vl-192.168.2.1 ge-0/0/14.0 ge-0/0/4.1213
State BDR DR PtToPt BDR BDR
Area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.10 0.0.0.20
DR ID 192.168.100.1 192.168.1.1 0.0.0.0 192.168.1.2 192.168.101.1
BDR ID 192.168.1.1 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.1
Nbrs 1 0 1 1 1
Question: Which type of interface is created for the virtual link?
Answer: A point-to-point 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.
[edit protocols ospf] lab@srxA-1# run show ospf neighbor Address Interface 172.22.121.2 ge-0/0/4.1211 172.22.124.1 vl-192.168.2.1 10.0.10.2 ge-0/0/14.0 172.22.123.2 ge-0/0/4.1213
State Full Full Full Full
ID 192.168.100.1 192.168.2.1 192.168.1.2 192.168.101.1
Pri 128 0 128 128
Dead 33 34 35 34
Question: What is the adjacency state of the virtual link interface?
Answer: The state should be Full. Step 1.11 Use the run show route address/32 table inet.0 command to verify that your partners default loopback address routes through the P1 router and not through the virtual link. Refer to the network diagram as needed.
[edit protocols ospf] lab@srxA-1# run show route address/32 table inet.0 inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.2.1/32 *[OSPF/10] 00:10:21, metric 2 > to 172.22.121.2 via ge-0/0/4.1211
www.juniper.net
Question: Does the route to your partners loopback address go through the P1 router or the virtual link?
Answer: Yes, the route to the loopback address of your partners student device should be using the P1 router and not 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.
[edit protocols ospf] lab@srxA-1# edit area 10 [edit protocols ospf area 0.0.0.10] lab@srxA-1# set interface P1-interface secondary [edit protocols ospf area 0.0.0.10] lab@srxA-1# set interface P1-interface metric 10 [edit protocols ospf area 0.0.0.10] lab@srxA-1# commit commit complete [edit protocols ospf area 0.0.0.10] lab@srxA-1#
Step 2.2 Use the run show ospf interface command to verify the multiarea adjacency.
[edit protocols ospf area 0.0.0.10] lab@srxA-1# run show ospf interface Interface State Area ge-0/0/4.1211 BDR 0.0.0.0 lo0.0 DR 0.0.0.0 vl-192.168.2.1 PtToPt 0.0.0.0 ge-0/0/14.0 BDR 0.0.0.10 ge-0/0/4.1211 PtToPt 0.0.0.10 ge-0/0/4.1213 BDR 0.0.0.20
DR ID 192.168.100.1 192.168.1.1 0.0.0.0 192.168.1.2 0.0.0.0 192.168.101.1
BDR ID 192.168.1.1 0.0.0.0 0.0.0.0 192.168.1.1 0.0.0.0 192.168.1.1
Nbrs 1 0 1 1 1 1
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?
Answer: The established interface state for Area 10 is point-to-point. As outlined in RFC 5185, all secondary multiarea adjacencies will be formed using a point-to-point interface. Step 2.3 Use the run show ospf neighbor command to verify the establishment of an OSPF Area 10 adjacency through the P1 router.
[edit protocols ospf area 0.0.0.10] lab@srxA-1# run show ospf neighbor Address Interface 172.22.121.2 ge-0/0/4.1211 Area 0.0.0.0 172.22.124.1 vl-192.168.2.1 Area 0.0.0.0 10.0.10.2 ge-0/0/14.0 Area 0.0.0.10 172.22.121.2 ge-0/0/4.1211 Area 0.0.0.10 172.22.123.2 ge-0/0/4.1213 Area 0.0.0.20
State Full Full Full Full Full
ID 192.168.100.1 192.168.2.1 192.168.1.2 192.168.100.1 192.168.101.1
Pri 128 0 128 128 128
Dead 33 35 31 32 39
Question: How many OSPF adjacencies exist for Area 0.0.0.10?
Answer: Two adjacencies have been formed within OSPF Area 0.0.0.10. Step 2.4 Verify that the loopback address of your partners 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.
[edit protocols ospf area 0.0.0.10] lab@srxA-1# run show route address/32 table inet.0 inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.2.2/32 *[OSPF/10] 00:22:19, metric 3 > to 10.0.10.2 via ge-0/0/14.0
www.juniper.net
Question: What is the primary path to your partners virtual routers loopback address?
Answer: The primary path to your partners virtual routers loopback address is through your R3 virtual router. 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 routers Area 10 interface connected to the P3 router. Commit the configuration when completed.
[edit protocols ospf area 0.0.0.10] lab@srxA-1# top edit routing-instances instance-name protocols ospf [edit routing-instances R3-1 protocols ospf] lab@srxA-1# deactivate area 10 interface R3-to-P3-interface [edit routing-instances R3-1 protocols ospf] lab@srxA-1# show area 0.0.0.10 { nssa; inactive: interface ge-0/0/4.1215; interface ge-0/0/15.0; interface lo0.1; } [edit routing-instances R3-1 protocols ospf] lab@srxA-1# commit commit complete [edit routing-instances R3-1 protocols ospf] lab@srxA-1#
Step 2.6 Issue the run show route address/32 table inet.0 command again to verify the route to your partners remote virtual routers loopback address has converged through the P1 router, thus using the multiarea adjacency.
[edit routing-instances R3-1 protocols ospf] lab@srxA-1# run show route address/32 table inet.0 inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.2.2/32 *[OSPF/10] 00:00:42, metric 12 > to 172.22.121.2 via ge-0/0/4.1211
www.juniper.net
Question: Did the route converge through the multiarea adjacency?
Answer: Yes, the route has now converged through the backup 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.
[edit routing-instances R3-1 protocols ospf] lab@srxA-1# top [edit] lab@srxA-1# rollback 1 load complete [edit] lab@srxA-1# commit commit complete [edit] lab@srxA-1#
Step 2.8 Verify that OSPF converged back to the primary path by displaying your partners loopback address using the run show route address/32 table inet.0 command.
[edit] lab@srxA-1# run show route address/32 table inet.0 inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.2.2/32 *[OSPF/10] 00:00:03, metric 3 > to 10.0.10.2 via ge-0/0/14.0
Question: Did the route converge back to your R3 virtual router?
Answer: Yes, the route has converged back to the R3 router.
www.juniper.net
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.
[edit] lab@srxA-1# edit routing-instances instance-name [edit routing-instances R3-1] lab@srxA-1# delete protocols ospf area 10 interface R3-to-P3-interface [edit routing-instances R3-1] lab@srxA-1# set protocols rip group P3 neighbor R3-to-P3-interface [edit routing-instances R3-1] lab@srxA-1# commit commit complete [edit routing-instances R3-1] lab@srxA-1#
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.
[edit routing-instances R3-1] lab@srxA-1# run show route receive-protocol rip address table instance-name R3-1.inet.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both
www.juniper.net Configuring and Monitoring Routing Policy and Advanced OSPF Options (Detailed) Lab 311
20.20.0.0/21 20.20.0.0/24 20.20.1.0/24 20.20.2.0/24 20.20.3.0/24 20.20.4.0/25 20.20.4.128/25 20.20.5.0/26 20.20.5.64/26 20.20.5.128/26 20.20.5.192/26
*[RIP/100] 00:00:40, metric 2, tag 0 > to 172.22.125.2 via ge-0/0/4.1215 *[RIP/100] 00:00:40, metric 2, tag 0 > to 172.22.125.2 via ge-0/0/4.1215 *[RIP/100] 00:00:40, metric 2, tag 0 > to 172.22.125.2 via ge-0/0/4.1215 *[RIP/100] 00:00:40, metric 2, tag 0 > to 172.22.125.2 via ge-0/0/4.1215 *[RIP/100] 00:00:40, metric 2, tag 0 > to 172.22.125.2 via ge-0/0/4.1215 *[RIP/100] 00:00:40, metric 2, tag 0 > to 172.22.125.2 via ge-0/0/4.1215 *[RIP/100] 00:00:40, metric 2, tag 0 > to 172.22.125.2 via ge-0/0/4.1215 *[RIP/100] 00:00:40, metric 2, tag 0 > to 172.22.125.2 via ge-0/0/4.1215 *[RIP/100] 00:00:40, metric 2, tag 0 > to 172.22.125.2 via ge-0/0/4.1215 *[RIP/100] 00:00:40, metric 2, tag 0 > to 172.22.125.2 via ge-0/0/4.1215 *[RIP/100] 00:00:40, metric 2, tag 0 > to 172.22.125.2 via ge-0/0/4.1215
Question: How many routes are you receiving from the P3 RIP router?
Answer: You should be receiving 11 routes. 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.
[edit routing-instances R3-1] lab@srxA-1# run show route 0/0 exact table instance-name R3-1.inet.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[OSPF/150] 00:30:41, metric 11, tag 0 > to 10.0.10.1 via ge-0/0/15.0
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.
[edit routing-instances R3-1] lab@srxA-1# top edit policy-options policy-statement export-default
www.juniper.net
[edit policy-options policy-statement export-default] lab@srxA-1# set term 1 from protocol ospf [edit policy-options policy-statement export-default] lab@srxA-1# set term 1 from route-filter 0.0.0.0/0 exact [edit policy-options policy-statement export-default] lab@srxA-1# set term 1 then accept [edit policy-options policy-statement export-default] lab@srxA-1# show term 1 { from { protocol ospf; route-filter 0.0.0.0/0 exact; } then accept; } [edit policy-options policy-statement export-default] lab@srxA-1#
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.
[edit policy-options policy-statement export-default] lab@srxA-1# top edit routing-instances instance-name [edit routing-instances R3-1] lab@srxA-1# set protocols rip group P3 export export-default [edit routing-instances R3-1] lab@srxA-1# commit commit complete [edit routing-instances R3-1] lab@srxA-1#
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.
www.juniper.net
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.
[edit policy-options policy-statement export-default] lab@srxA-2# top edit routing-instances instance-name [edit routing-instances R3-2] lab@srxA-2# set protocols rip group P3 export export-default [edit routing-instances R3-2] lab@srxA-2# commit commit complete [edit routing-instances R3-2] lab@srxA-2#
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.

[edit routing-instances R3-1] lab@srxA-1# run show route advertising-protocol rip address table instance-name R3-1.inet.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[OSPF/150] 00:34:57, metric 11, tag 0 > to 10.0.10.1 via ge-0/0/15.0
.......................................................................... [edit routing-instances R3-2] lab@srxA-2# run show route advertising-protocol rip address table instance-name [blank output]
www.juniper.net
Question: Is the default route being advertised to R3?
Answer: The answer depends on which router advertised the default route first. One of the routers will not be advertising the route because its active route for the 0/0 default route is a RIP route, not an OSPF route. This is because the RIP preference of 100 is lower than the OSPF external preference of 150. Recall that the export-default policy you just applied uses a from protocol ospf in its term. Policy can only act upon active routes. Therefore, in the previous output, the R3-2 router cannot advertise the route. We will demonstrate this issue and fix it in subsequent steps. 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

[edit routing-instances R3-1] lab@srxA-1# run show route 0/0 exact table instance-name R3-1.inet.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[OSPF/150] 00:35:50, metric 11, tag 0 > to 10.0.10.1 via ge-0/0/15.0
.......................................................................... [edit routing-instances R3-2] lab@srxA-2# run show route 0/0 exact table instance-name R3-2.inet.0: 29 destinations, 30 routes (29 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[RIP/100] 00:03:25, metric 2, tag 0 > to 172.22.126.2 via ge-0/0/4.1216 [OSPF/150] 00:35:34, metric 11, tag 0 > to 10.0.20.1 via ge-0/0/15.0
www.juniper.net
Question: What is the active protocol for the default route?
Answer: The answer depends on which router advertised the default route first. Based on the previous output for the srxA-1 router, the active protocol for the default route is OSPF. For the srxA-2 router, the active protocol for the default route is RIP, because the preference of RIP (100) is lower than the external preference of OSPF (150). 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.
[edit routing-instances R3-1] lab@srxA-1# set protocols ospf external-preference 90 [edit routing-instances R3-1] lab@srxA-1# commit commit 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

[edit routing-instances R3-1] lab@srxA-1# run show route advertising-protocol rip address table instance-name R3-1.inet.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[OSPF/90] 00:00:11, metric 11, tag 0 > to 10.0.10.1 via ge-0/0/15.0
.......................................................................... [edit routing-instances R3-2] lab@srxA-2# run show route advertising-protocol rip address table instance-name
www.juniper.net
R3-2.inet.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[OSPF/90] 00:00:16, metric 11, tag 0 > to 10.0.20.1 via ge-0/0/15.0
Question: Is the route now being advertised to the RIP network?
Answer: Yes, the lower OPSF preference has made the default route active under OSPF, which matches the RIP export policy and allows it to be advertised. 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.
[edit routing-instances R3-1] lab@srxA-1# top edit policy-options policy-statement import-rip-route [edit policy-options policy-statement import-rip-route] lab@srxA-1# set term 1 from protocol rip [edit policy-options policy-statement import-rip-route] lab@srxA-1# set term 1 from route-filter 20.20.0.0/21 exact [edit policy-options policy-statement import-rip-route] lab@srxA-1# set term 1 then accept [edit policy-options policy-statement import-rip-route] lab@srxA-1# set term 2 from protocol rip [edit policy-options policy-statement import-rip-route] lab@srxA-1# set term 2 from route-filter 20.20.0.0/21 longer [edit policy-options policy-statement import-rip-route] lab@srxA-1# set term 2 then reject [edit policy-options policy-statement import-rip-route] lab@srxA-1# show term 1 { from { protocol rip; route-filter 20.20.0.0/21 exact; } then accept; } term 2 { from { protocol rip;
www.juniper.net Configuring and Monitoring Routing Policy and Advanced OSPF Options (Detailed) Lab 317
route-filter 20.20.0.0/21 longer; } then reject; } [edit policy-options policy-statement import-rip-route] lab@srxA-1#
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.
[edit policy-options policy-statement import-rip-route] lab@srxA-1# top edit routing-instances instance-name [edit routing-instances R3-1] lab@srxA-1# set protocols rip group P3 import import-rip-route [edit routing-instances R3-1] lab@srxA-1# commit commit complete [edit routing-instances R3-1] lab@srxA-1#
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.
[edit routing-instances R3-1] lab@srxA-1# run show route receive-protocol rip address table instance-name R3-1.inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 20.20.0.0/21 *[RIP/100] 00:10:57, metric 2, tag 0 > to 172.22.125.2 via ge-0/0/4.1215
Question: Is the RIP import policy working?
Answer: Because only the summary route (instead of the 11 original routes) is being accepted from the RIP neighbor, it appears that the import policy is working.
www.juniper.net
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.
[edit routing-instances R3-1] lab@srxA-1# top edit policy-options policy-statement export-rip-route [edit policy-options policy-statement export-rip-route] lab@srxA-1# set term 1 from protocol rip [edit policy-options policy-statement export-rip-route] lab@srxA-1# set term 1 then accept [edit policy-options policy-statement export-rip-route] lab@srxA-1# show term 1 { from protocol rip; then accept; } [edit policy-options policy-statement export-rip-route] lab@srxA-1#
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.
[edit policy-options policy-statement export-rip-route] lab@srxA-1# top edit routing-instances instance-name [edit routing-instances R3-1] lab@srxA-1# set protocols ospf prefix-export-limit 1 [edit routing-instances R3-1] lab@srxA-1# set protocols ospf export export-rip-route [edit routing-instances R3-1] lab@srxA-1# commit commit complete [edit routing-instances R3-1] lab@srxA-1#
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.
www.juniper.net
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.
[edit policy-options policy-statement export-rip-route] lab@srxA-2# top edit routing-instances instance-name [edit routing-instances R3-2] lab@srxA-2# set protocols ospf prefix-export-limit 1 [edit routing-instances R3-2] lab@srxA-2# set protocols ospf export export-rip-route [edit routing-instances R3-2] lab@srxA-2# commit commit complete [edit routing-instances R3-2] lab@srxA-2#
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

[edit routing-instances R3-1] lab@srxA-1# run traceroute 20.20.1.1 routing-instance instance-name traceroute to 20.20.1.1 (20.20.1.1), 30 hops max, 40 byte packets 1 172.22.125.2 (172.22.125.2) 7.667 ms !N 1.380 ms !N 1.467 ms !N ........................................................................... [edit routing-instances R3-2] lab@srxA-2# run traceroute 20.20.1.1 routing-instance instance-name traceroute to 20.20.1.1 (20.20.1.1), 30 hops max, 40 byte packets 1 10.0.20.1 (10.0.20.1) 7.970 ms 8.496 ms 8.568 ms 2 172.22.122.2 (172.22.122.2) 1.834 ms 1.904 ms 7.883 ms 3 172.22.121.1 (172.22.121.1) 8.252 ms 8.202 ms 8.604 ms 4 10.0.10.2 (10.0.10.2) 14.501 ms 8.515 ms 8.537 ms 5 172.22.125.2 (172.22.125.2) 2.937 ms !N 2.626 ms !N 2.220 ms !N
www.juniper.net
Question: What could be causing the suboptimal path to the RIP network?
Answer: When multiple area border routers (ABRs) are present in an NSSA area, only the ABR with the highest router ID will translate the Type 7 LSA to a Type 5 LSA. This causes the less than optimal routing we see in this case. We demonstrate how to find this information in subsequent steps. 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.
[edit routing-instances R3-1] lab@srxA-1# run show ospf database area 10 nssa detail OSPF database, Area 0.0.0.10 Type ID Adv Rtr Seq Age NSSA *0.0.0.0 192.168.1.1 0x80000002 1621 mask 0.0.0.0 Topology default (ID 0) Type: 1, Metric: 10, Fwd addr: 0.0.0.0, Tag: 0.0.0.0 NSSA 0.0.0.0 192.168.2.1 0x80000002 980 mask 0.0.0.0 Topology default (ID 0) Type: 1, Metric: 10, Fwd addr: 0.0.0.0, Tag: 0.0.0.0 NSSA 20.20.0.0 192.168.1.2 0x80000001 164 mask 255.255.248.0 Topology default (ID 0) Type: 2, Metric: 2, Fwd addr: 192.168.1.2, Tag: 0.0.0.0 [edit routing-instances R3-1] lab@srxA-1# run show ospf database external detail OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Extern 20.20.0.0 192.168.100.1 0x80000001 168 mask 255.255.248.0 Topology default (ID 0) Type: 2, Metric: 2, Fwd addr: 192.168.1.2, Tag: 0.0.0.0
Opt Cksum Len 0x20 0xc8f3 36
0x20 0xc1f9
36
0x28 0xbfee
36
Opt Cksum Len 0x22 0x84cf 36
www.juniper.net
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?
Answer: The R3-1 router created the Type 7 LSA. However, the P1 router created the Type 5 LSA. The P1 router has the highest router ID between the three ABRs connected to OSPF NSSA Area 10. It might not appear that the P1 router is an ABR for Area 10, but recall the Area 10 multiarea link we created through P1. This multiarea link is what allows P1 to be an ABR within Area 10. We will work around this issue in the next step. 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.
[edit routing-instances R3-1] lab@srxA-1# top edit policy-options policy-statement ospf-import [edit policy-options policy-statement ospf-import] lab@srxA-1# set term 1 from route-filter 20.20.0.0/21 orlonger [edit policy-options policy-statement ospf-import] lab@srxA-1# set term 1 then reject [edit policy-options policy-statement ospf-import] lab@srxA-1# show term 1 { from { route-filter 20.20.0.0/21 orlonger; } then reject; } [edit policy-options policy-statement ospf-import] lab@srxA-1#
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.
[edit policy-options policy-statement ospf-import] lab@srxA-1# top edit routing-instances instance-name [edit routing-instances R3-1] lab@srxA-1# set protocols ospf import ospf-import
Lab 322 Configuring and Monitoring Routing Policy and Advanced OSPF Options (Detailed) www.juniper.net
[edit routing-instances R3-1] lab@srxA-1# commit and-quit commit complete Exiting configuration mode lab@srxA-1>
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.
lab@srxA-1> traceroute 20.20.1.1 routing-instance instance-name traceroute to 20.20.1.1 (20.20.1.1), 30 hops max, 40 byte packets 1 172.22.125.2 (172.22.125.2) 1.539 ms !N 1.358 ms !N 7.054 ms !N
Question: Is the OSPF import policy working?
Answer: Yes, the OSPF import policy is providing an optimal path to the RIP network. Step 3.22 Log out of your assigned device using the exit command.
lab@srxA-1> exit
STOP
www.juniper.net
www.juniper.net
Lab 4
Implementing BGP (Detailed)
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: 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.
www.juniper.net
Implementing BGP (Detailed) Lab 41 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 BGPPart 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?
Lab 42 Implementing BGP (Detailed)
www.juniper.net
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.
[edit] lab@srxA-1# run ping address rapid PING 172.18.1.1 (172.18.1.1): 56 data bytes !!!!! --- 172.18.1.1 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.581/2.595/5.961/1.693 ms [edit] lab@srxA-1# run ping address rapid PING 172.18.11.1 (172.18.11.1): 56 data bytes !!!!! --- 172.18.11.1 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.364/1.555/1.838/0.175 ms [edit] lab@srxA-1# run ping address rapid PING 172.20.66.2 (172.20.66.2): 56 data bytes !!!!! --- 172.20.66.2 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.343/4.010/7.581/2.777 ms [edit] lab@srxA-1# run ping address rapid PING 172.20.77.2 (172.20.77.2): 56 data bytes !!!!! --- 172.20.77.2 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.155/1.348/1.948/0.301 ms
www.juniper.net
Implementing BGP (Detailed) Lab 43
[edit] lab@srxA-1# run ping address rapid PING 172.20.111.10 (172.20.111.10): 56 data bytes !!!!! --- 172.20.111.10 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.586/5.275/7.757/2.816 ms
Question: Were all of the interface IP addresses reachable?
Answer: Yes, all interface IP addresses should be reachable. If any of the interface IP addresses were not reachable, check your interface configuration to determine whether any mistakes exist. Ask your instructor for help if needed. 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.
[edit] lab@srxA-1# run show ospf interface Interface State Area ge-0/0/1.0 BDR 0.0.0.0 ge-0/0/2.0 BDR 0.0.0.0 ge-0/0/3.0 DRother 0.0.0.0 ge-0/0/4.1121 DRother 0.0.0.0 lo0.0 DR 0.0.0.0 ge-0/0/4.111 BDR 0.0.0.1 [edit] lab@srxA-1# run show ospf neighbor Address Interface 172.20.77.2 ge-0/0/1.0 172.20.66.2 ge-0/0/2.0 172.20.111.10 ge-0/0/4.111
DR ID 192.168.2.1 192.168.2.1 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.2
BDR ID 192.168.1.1 192.168.1.1 0.0.0.0 0.0.0.0 0.0.0.0 192.168.1.1
Nbrs 1 1 0 0 0 1
ID 192.168.2.1 192.168.2.1 192.168.1.2
Pri 128 128 128
Dead 36 38 32
Question: Are the adjacencies established between your router and the two neighboring routers?
Answer: Yes, you should have three established adjacencies. If you do not have three adjacencies, check your configuration to determine whether any mistakes exist. Ask your instructor for help if needed.
Lab 44 Implementing BGP (Detailed) www.juniper.net
Part 2: Configuring IBGP

In this lab part, you use the lab diagram called Lab 4: Implementing BGP Parts 24 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.
[edit] lab@srxA-1# edit routing-options [edit routing-options] lab@srxA-1# set autonomous-system 64700 [edit routing-options] lab@srxA-1#
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.
[edit routing-options] lab@srxA-1# top edit protocols bgp [edit protocols bgp] lab@srxA-1# set group my-int-group type internal [edit protocols bgp] lab@srxA-1# set group my-int-group local-address local-loopback-address [edit protocols bgp] lab@srxA-1# set group my-int-group neighbor remote-loopback-address [edit protocols bgp] lab@srxA-1# set group my-int-group neighbor remote-loopback-address [edit protocols bgp] lab@srxA-1# set group my-int-group neighbor remote-loopback-address [edit protocols bgp] lab@srxA-1# show
www.juniper.net
group my-int-group { type internal; local-address 192.168.1.1; neighbor 192.168.1.2; neighbor 192.168.2.1; neighbor 192.168.2.2; } [edit protocols bgp] lab@srxA-1# commit commit complete [edit protocols bgp] lab@srxA-1#
Question: Was the commit operation successful?
Answer: The commit operation should have been successful. If not, check your configuration to ensure that you did not make any mistakes. Be sure that you either specify a session type of internal or define a peer AS number for the BGP group that matches the locally defined AS number (64700). For external peering sessions, you can specify the external session type and define the remote peer AS number or, because the system assumes the external session type by default, simply define the remote peer AS number.
Note
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.
[edit protocols bgp] lab@srxA-1# run show bgp summary Groups: 1 Peers: 3 Down peers: 0
www.juniper.net
Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 6 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.168.1.2 64700 5 7 0 0 1:52 0/ 3/3/0 0/0/0/0 192.168.2.1 64700 2 2 0 0 12 0/ 0/0/0 0/0/0/0 192.168.2.2 64700 5 5 0 0 1:44 0/ 3/3/0 0/0/0/0
Question: How many BGP neighbors does your device currently list?
Answer: Your device should list the three IBGP peers you defined previously in this lab part. If you do not see three IBGP peers, check your configuration. If necessary, consult with the remote team and the instructor. Question: Has your device received any routes from its IBGP peers?
Answer: Yes, your device should have received three BGP routes from each of the virtual routers within your assigned pod. 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.
[edit protocols bgp] lab@srxA-1# run show route receive-protocol bgp peer-address inet.0: 26 destinations, 32 routes (26 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 172.21.0.0/24 192.168.1.2 100 I 172.21.1.0/24 192.168.1.2 100 I 172.21.2.0/24 192.168.1.2 100 I [edit protocols bgp] lab@srxA-1# run show route receive-protocol bgp peer-address inet.0: 26 destinations, 32 routes (26 active, 0 holddown, 0 hidden) [edit protocols bgp] lab@srxA-1# run show route receive-protocol bgp peer-address
www.juniper.net Implementing BGP (Detailed) Lab 47
inet.0: 26 destinations, 32 routes (26 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 172.22.0.0/24 192.168.2.2 100 I 172.22.1.0/24 192.168.2.2 100 I 172.22.2.0/24 192.168.2.2 100 I
Question: From which IBGP peers are you currently receiving routes?
Answer: Only the virtual routers in your assigned pod and AS are currently advertising routes. Note that these routes are the same routes advertised through OSPF. Question: What is the AS path associated with the received BGP routes?
Answer: The AS path for the received BGP routes is I, which means the route originated in the local AS. Once these routes are advertised to a different AS, the local AS (64700 in this case) will be added to the AS path list. Question: What is the local preference of the received BGP routes?
Answer: All received BGP routes should show a local preference of 100, which is the default value. Question: Which routing table group does the referenced command consult? Which operational mode command displays BGP routes in the routing table (RIB-Local)?
Answer: The command referenced in this step consults the RIB-In routing table. You can issue the show route protocol bgp operational mode command to display BGP routes. A sample of this command is illustrated in the following capture:
[edit protocols bgp] lab@srxA-1# run show route protocol bgp inet.0: 26 destinations, 32 routes (26 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.21.0.0/24 [BGP/170] 00:06:28, localpref 100, from AS path: I > to 172.20.111.10 via ge-0/0/4.111 [BGP/170] 00:06:28, localpref 100, from AS path: I > to 172.20.111.10 via ge-0/0/4.111 [BGP/170] 00:06:28, localpref 100, from AS path: I > to 172.20.111.10 via ge-0/0/4.111 [BGP/170] 00:06:20, localpref 100, from AS path: I > to 172.20.77.2 via ge-0/0/1.0 [BGP/170] 00:06:20, localpref 100, from AS path: I > to 172.20.77.2 via ge-0/0/1.0 [BGP/170] 00:06:20, localpref 100, from AS path: I > to 172.20.77.2 via ge-0/0/1.0 192.168.1.2
172.21.1.0/24
192.168.1.2
172.21.2.0/24
192.168.1.2
172.22.0.0/24
192.168.2.2
172.22.1.0/24
192.168.2.2
172.22.2.0/24
192.168.2.2
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.
[edit protocols bgp] lab@srxA-1# run show route advertising-protocol bgp peer-address [edit protocols bgp] lab@srxA-1# run show route advertising-protocol bgp peer-address [edit protocols bgp] lab@srxA-1# run show route advertising-protocol bgp peer-address
Question: Which routing table group does the command referenced in this step consult?
Answer: The command referenced in this step consults the RIB-Out routing table.
www.juniper.net
Question: Is your student device currently advertising BGP routes to any of its IBGP peers?
Answer: No. As illustrated in the sample output, your device should not be advertising any BGP routes at this time. Because BGP routes received from IBGP peers are not readvertised to other IBGP peers, it is logical that your device is not advertising BGP routes at this time.
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.
[edit protocols bgp] lab@srxA-1# set group my-ext-group type external [edit protocols bgp] lab@srxA-1# set group my-ext-group peer-as peer-as [edit protocols bgp] lab@srxA-1# set group my-ext-group neighbor peer-address [edit protocols bgp] lab@srxA-1# set group my-ext-group neighbor peer-address [edit protocols bgp] lab@srxA-1# show group my-int-group { type internal; local-address 192.168.1.1; neighbor 192.168.1.2; neighbor 192.168.2.1; neighbor 192.168.2.2; } group my-ext-group { type external; peer-as 65510; neighbor 172.18.1.1; neighbor 172.18.11.1; }
[edit protocols bgp] lab@srxA-1# commit commit complete

Note
Before proceeding, ensure the remote student team in your pod has finished the previous step.
STOP
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.
[edit protocols bgp] lab@srxA-1# run show bgp summary Groups: 2 Peers: 5 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State inet.0 36 10 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last State|#Active/Received/Accepted/Damped... 172.18.1.1 65510 12 9 0 0 10/10/0 0/0/0/0 172.18.11.1 65510 11 8 0 0 10/10/0 0/0/0/0 192.168.1.2 64700 28 34 0 0 3/3/0 0/0/0/0 192.168.2.1 64700 31 29 0 0 10/10/0 0/0/0/0 192.168.2.2 64700 28 33 0 0 3/3/0 0/0/0/0
Pending 0 Up/Dwn 3:03 10/ 2:59 0/ 12:38 0/ 10:58 0/ 12:30 0/
Question: How many BGP groups and peers does your device currently list?
Answer: Your device should now list two BGP groups and five BGP peers; the IBGP group consists of three peers and the EBGP group has two peers. If you do not see five BGP peers, check your configuration and, if necessary, consult with the instructor.
www.juniper.net
Question: Has your device received routes from both EBGP peers?
Answer: Yes, your device should receive 10 BGP routes from its EBGP peers. Note that the remote student device, currently serving as an IBGP peer, is also advertising 10 BGP routes. Question: Are all of the routes received from the two EBGP peers active?
Answer: No, only the routes received from one EBGP peer are 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.
[edit protocols bgp] lab@srxA-1# run show route aspath-regex "peer-as .*" inet.0: 36 destinations, 62 routes (36 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[BGP/170] 00:03:32, localpref 100 AS path: 65510 I > to 172.18.1.1 via ge-0/0/3.0 [BGP/170] 00:03:28, localpref 100 AS path: 65510 I > to 172.18.11.1 via ge-0/0/4.1121 *[BGP/170] 00:03:32, localpref 100 AS path: 65510 65515 65519 65534 > to 172.18.1.1 via ge-0/0/3.0 [BGP/170] 00:03:28, localpref 100 AS path: 65510 65515 65519 65534 > to 172.18.11.1 via ge-0/0/4.1121 *[BGP/170] 00:03:32, localpref 100 AS path: 65510 65515 65519 65534 > to 172.18.1.1 via ge-0/0/3.0 [BGP/170] 00:03:28, localpref 100 AS path: 65510 65515 65519 65534 > to 172.18.11.1 via ge-0/0/4.1121 *[BGP/170] 00:03:32, localpref 100 AS path: 65510 65515 65519 65534 > to 172.18.1.1 via ge-0/0/3.0
172.28.102.0/24
172.28.103.0/24
172.28.104.0/24
www.juniper.net
172.30.1.0/24
172.30.2.0/24
172.30.3.0/24
172.31.10.0/24
172.31.11.0/24
172.31.12.0/24
[BGP/170] 00:03:28, localpref 100 AS path: 65510 65515 65519 65534 > to 172.18.11.1 via ge-0/0/4.1121 *[BGP/170] 00:03:32, localpref 100 AS path: 65510 65515 65516 65517 > to 172.18.1.1 via ge-0/0/3.0 [BGP/170] 00:03:28, localpref 100 AS path: 65510 65515 65516 65517 > to 172.18.11.1 via ge-0/0/4.1121 *[BGP/170] 00:03:32, localpref 100 AS path: 65510 65515 65516 65517 > to 172.18.1.1 via ge-0/0/3.0 [BGP/170] 00:03:28, localpref 100 AS path: 65510 65515 65516 65517 > to 172.18.11.1 via ge-0/0/4.1121 *[BGP/170] 00:03:32, localpref 100 AS path: 65510 65515 65516 65517 > to 172.18.1.1 via ge-0/0/3.0 [BGP/170] 00:03:28, localpref 100 AS path: 65510 65515 65516 65517 > to 172.18.11.1 via ge-0/0/4.1121 *[BGP/170] 00:03:32, localpref 100 AS path: 65510 65515 65531 E > to 172.18.1.1 via ge-0/0/3.0 [BGP/170] 00:03:28, localpref 100 AS path: 65510 65515 65531 E > to 172.18.11.1 via ge-0/0/4.1121 *[BGP/170] 00:03:32, localpref 100 AS path: 65510 65515 65531 E > to 172.18.1.1 via ge-0/0/3.0 [BGP/170] 00:03:28, localpref 100 AS path: 65510 65515 65531 E > to 172.18.11.1 via ge-0/0/4.1121 *[BGP/170] 00:03:32, localpref 100 AS path: 65510 65515 65531 E > to 172.18.1.1 via ge-0/0/3.0 [BGP/170] 00:03:28, localpref 100 AS path: 65510 65515 65531 E > to 172.18.11.1 via ge-0/0/4.1121
Question: Are the EBGP peers sending the exact same routes to your router or are they sending different routes?
Answer: The EBGP peers are sending the exact same routes.
www.juniper.net
Question: Can you think of a reason why your router is only using the routes received from one EBGP peer and not the other?
Answer: Anytime a router receives two or more BGP routes that are exactly the same in prefix and prefix length, the router must choose one of those routes as the active route (the route used for forwarding and readvertisement). The BGP router will go through the BGP route-selection process to determine the best route. It will start by looking at local preference, then AS path, and so on until it determines the best route.
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.
[edit protocols bgp] lab@srxA-1# run show route 0/0 exact extensive inet.0: 36 destinations, 62 routes (36 active, 0 holddown, 0 hidden) 0.0.0.0/0 (3 entries, 1 announced) TSI: KRT in-kernel 0.0.0.0/0 -> {172.18.1.1} Page 0 idx 0 Type 1 val 162cff8 Nexthop: 172.18.1.1 Localpref: 100 AS path: [64700] 65510 I Communities: Path 0.0.0.0 from 172.18.1.1 Vector len 4. Val: 0 *BGP Preference: 170/-101 Next hop type: Router, Next hop index: 546 Address: 0x168c8f8 Next-hop reference count: 30 Source: 172.18.1.1 Next hop: 172.18.1.1 via ge-0/0/3.0, selected State: <Active Ext> Local AS: 64700 Peer AS: 65510 Age: 5:11 Task: BGP_65510.172.18.1.1+179 Announcement bits (3): 0-KRT 3-BGP_RT_Background 4-Resolve tree 1 AS path: 65510 I Accepted Localpref: 100 Router ID: 10.10.10.10
www.juniper.net
BGP
BGP
Preference: 170/-101 Next hop type: Router Address: 0x168d48c Next-hop reference count: 10 Source: 172.18.11.1 Next hop: 172.18.11.1 via ge-0/0/4.1121, selected State: <NotBest Ext> Inactive reason: Not Best in its group - Update source Local AS: 64700 Peer AS: 65510 Age: 5:07 Task: BGP_65510.172.18.11.1+179 AS path: 65510 I Accepted Localpref: 100 Router ID: 10.10.10.10 Preference: 170/-101 Next hop type: Indirect Address: 0x168d064 Next-hop reference count: 10 Source: 192.168.2.1 Next hop type: Router, Next hop index: 544 Next hop: 172.20.77.2 via ge-0/0/1.0, selected Protocol next hop: 172.18.2.1 Indirect next hop: 16a0570 State: <Int Ext> Inactive reason: Interior > Exterior > Exterior via Interior Local AS: 64700 Peer AS: 64700 Age: 4:42 Metric2: 2 Task: BGP_64700.192.168.2.1+179 AS path: 65520 I Accepted Localpref: 100 Router ID: 192.168.2.1 Indirect next hops: 1 Protocol next hop: 172.18.2.1 Metric: 2 Indirect next hop: 16a0570 Indirect path forwarding next hops: 1 Next hop type: Router Next hop: 172.20.77.2 via ge-0/0/1.0 172.18.2.0/30 Originating RIB: inet.0 Metric: 2 Node path count: 1 Forwarding nexthops: 1 Nexthop: 172.20.77.2 via ge-0/0/1.0
www.juniper.net
Question: What did the router use as the reason for not choosing one of the routes to be active?
Answer: Looking at the output of the command, the inactive route has an inactive reason of Not Best in its group - Update source. This means that the router chose not to use the route based on the peer ID of the EBGP peers. The lowest peer ID is the most preferred. Notice, in the example, that the inactive route came from the peer 172.18.11.1, whereas the active route came from the peer 172.18.1.1. Question: What is the next hop of the active route?
Answer: The next hop of the active route should be the IP address of the EBGP peer with the lowest peer ID. 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?
Answer: By configuring multipath (one or more EBGP peers in the same AS as each other) or multihop (one EBGP peer only), your router can load-balance traffic for equivalent routes learned from multiple EBGP sessions. You will configure both of these load-balancing methods later in this lab.
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.
[edit protocols bgp] lab@srxA-1# run show route advertising-protocol bgp peer-address [edit protocols bgp] lab@srxA-1# run show route advertising-protocol bgp peer-address
Question: Is your device currently advertising the BGP routes received from its IBGP peers to its EBGP peers? If not, explain why.
Answer: No, as illustrated in the sample output, your device should not currently be advertising BGP routes to its EBGP peers. Although your device has received BGP routes from its IBGP peers (the virtual routers within your AS), those BGP routes are not active because the same prefixes are also learned through OSPF, which has a lower and more preferred route preference (150 versus 170). The following output illustrates the current status of those prefixes.
[edit protocols bgp] lab@srxA-1# run show route 172.21/16 inet.0: 36 destinations, 62 routes (36 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.21.0.0/24 *[OSPF/150] 00:27:22, metric 0, tag 0 > to 172.20.111.10 via ge-0/0/4.111 [BGP/170] 00:17:30, localpref 100, from 192.168.1.2 AS path: I > to 172.20.111.10 via ge-0/0/4.111 *[OSPF/150] 00:27:22, metric 0, tag 0 > to 172.20.111.10 via ge-0/0/4.111 [BGP/170] 00:17:30, localpref 100, from 192.168.1.2 AS path: I > to 172.20.111.10 via ge-0/0/4.111 *[OSPF/150] 00:27:22, metric 0, tag 0 > to 172.20.111.10 via ge-0/0/4.111 [BGP/170] 00:17:30, localpref 100, from 192.168.1.2 AS path: I > to 172.20.111.10 via ge-0/0/4.111
172.21.1.0/24
172.21.2.0/24
[edit protocols bgp] lab@srxA-1# run show route 172.22/16 inet.0: 36 destinations, 62 routes (36 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both
www.juniper.net
172.22.0.0/24
172.22.1.0/24
172.22.2.0/24
*[OSPF/150] 00:27:47, metric 0, tag > to 172.20.77.2 via ge-0/0/1.0 [BGP/170] 00:18:22, localpref 100, AS path: I > to 172.20.77.2 via ge-0/0/1.0 *[OSPF/150] 00:27:47, metric 0, tag > to 172.20.77.2 via ge-0/0/1.0 [BGP/170] 00:18:22, localpref 100, AS path: I > to 172.20.77.2 via ge-0/0/1.0 *[OSPF/150] 00:27:47, metric 0, tag > to 172.20.77.2 via ge-0/0/1.0 [BGP/170] 00:18:22, localpref 100, AS path: I > to 172.20.77.2 via ge-0/0/1.0
0 from 192.168.2.2
0 from 192.168.2.2
0 from 192.168.2.2
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.
[edit protocols bgp] lab@srxA-1# set advertise-inactive [edit protocols bgp] lab@srxA-1# commit commit 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.
[edit protocols bgp] lab@srxA-1# run show route advertising-protocol bgp peer-address inet.0: 36 destinations, 62 routes (36 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 172.21.0.0/24 Self I 172.21.1.0/24 Self I 172.21.2.0/24 Self I 172.22.0.0/24 Self I 172.22.1.0/24 Self I 172.22.2.0/24 Self I [edit protocols bgp] lab@srxA-1# run show route advertising-protocol bgp peer-address inet.0: 36 destinations, 62 routes (36 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 172.21.0.0/24 Self I 172.21.1.0/24 Self I 172.21.2.0/24 Self I 172.22.0.0/24 Self I
172.22.1.0/24 172.22.2.0/24
Self Self
I I
Question: Is your device now advertising the BGP routes received from its IBGP peers to its EBGP peers?
Answer: Yes. As illustrated in the sample output, your device should now be advertising the BGP routes learned from the two virtual router 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.
[edit protocols bgp] lab@srxA-1# top edit routing-options [edit routing-options] lab@srxA-1# set aggregate route 172.21.0.0/22 [edit routing-options] lab@srxA-1# set aggregate route 172.22.0.0/22 [edit routing-options] lab@srxA-1# set aggregate route 192.168.1.0/30 [edit routing-options] lab@srxA-1# set aggregate route 192.168.2.0/30 [edit routing-options] lab@srxA-1# show aggregate route 172.21.0.0/22; route 172.22.0.0/22; route 192.168.1.0/30; route 192.168.2.0/30; [edit routing-options] lab@srxA-1#
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.
[edit routing-options] lab@srxA-1# top edit policy-options [edit policy-options] lab@srxA-1# edit policy-statement adv-aggregates [edit policy-options policy-statement adv-aggregates] lab@srxA-1# set term match-aggregate-routes from protocol aggregate [edit policy-options policy-statement adv-aggregates] lab@srxA-1# set term match-aggregate-routes then accept [edit policy-options policy-statement adv-aggregates] lab@srxA-1# set term deny-other then reject [edit policy-options policy-statement adv-aggregates] lab@srxA-1# show term match-aggregate-routes { from protocol aggregate; then accept; } term deny-other { then reject; } [edit policy-options policy-statement adv-aggregates] lab@srxA-1#
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.
[edit policy-options policy-statement adv-aggregates] lab@srxA-1# top edit protocols bgp [edit protocols bgp] lab@srxA-1# set group my-ext-group export adv-aggregates [edit protocols bgp] lab@srxA-1# show group my-ext-group type external; export adv-aggregates; peer-as 65510; neighbor 172.18.1.1; neighbor 172.18.11.1; [edit protocols bgp] lab@srxA-1# commit commit complete [edit protocols bgp] lab@srxA-1#
www.juniper.net
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.
[edit protocols bgp] lab@srxA-1# run show route advertising-protocol bgp peer-address inet.0: 40 destinations, 66 routes (40 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.21.0.0/22 Self I * 172.22.0.0/22 Self I * 192.168.1.0/30 Self I * 192.168.2.0/30 Self I [edit protocols bgp] lab@srxA-1# run show route advertising-protocol bgp peer-address inet.0: 40 destinations, 66 routes (40 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.21.0.0/22 Self I * 172.22.0.0/22 Self I * 192.168.1.0/30 Self I * 192.168.2.0/30 Self I
Question: Is your device advertising all of the expected aggregate prefixes?
Answer: Yes, all aggregates should be advertised at this time. If not, check your configuration for any possible mistakes. Ask you instructor for help if necessary.
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 routers 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.
[edit protocols bgp] lab@srxA-1# run show route receive-protocol bgp peer-address
www.juniper.net
inet.0: 40 destinations, 66 routes (40 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 0.0.0.0/0 172.18.1.1 65510 I * 172.28.102.0/24 172.18.1.1 65510 65515 65519 * 172.28.103.0/24 172.18.1.1 65510 65515 65519 * 172.28.104.0/24 172.18.1.1 65510 65515 65519 * 172.30.1.0/24 172.18.1.1 65510 65515 65516 * 172.30.2.0/24 172.18.1.1 65510 65515 65516 * 172.30.3.0/24 172.18.1.1 65510 65515 65516 * 172.31.10.0/24 172.18.1.1 65510 65515 65531 * 172.31.11.0/24 172.18.1.1 65510 65515 65531 * 172.31.12.0/24 172.18.1.1 65510 65515 65531 [edit protocols bgp] lab@srxA-1# run show route receive-protocol bgp peer-address inet.0: 40 destinations, 66 routes (40 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 0.0.0.0/0 172.18.11.1 65510 I 172.28.102.0/24 172.18.11.1 65510 65515 65519 172.28.103.0/24 172.18.11.1 65510 65515 65519 172.28.104.0/24 172.18.11.1 65510 65515 65519 172.30.1.0/24 172.18.11.1 65510 65515 65516 172.30.2.0/24 172.18.11.1 65510 65515 65516 172.30.3.0/24 172.18.11.1 65510 65515 65516 172.31.10.0/24 172.18.11.1 65510 65515 65531 172.31.11.0/24 172.18.11.1 65510 65515 65531 172.31.12.0/24 172.18.11.1 65510 65515 65531
65534 65534 65534 65517 65517 65517 E E E
? ? ? I I I
65534 65534 65534 65517 65517 65517 E E E
? ? ? I I I
Question: Again, are the same routes being received from both the EBGP peers?
Answer: Yes, the same routes are being received from 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.
[edit protocols bgp] lab@srxA-1# run show route 172.28.102.0/24 detail inet.0: 40 destinations, 66 routes (40 active, 0 holddown, 0 hidden) 172.28.102.0/24 (3 entries, 1 announced) *BGP Preference: 170/-101 Next hop type: Router, Next hop index: 546 Address: 0x168c8f8 Next-hop reference count: 30 Source: 172.18.1.1 Next hop: 172.18.1.1 via ge-0/0/3.0, selected State: <Active Ext>
BGP
BGP
Local AS: 64700 Peer AS: 65510 Age: 22:54 Task: BGP_65510.172.18.1.1+179 Announcement bits (3): 0-KRT 3-BGP_RT_Background 4-Resolve tree 1 AS path: 65510 65515 65519 65534 ? Accepted Localpref: 100 Router ID: 10.10.10.10 Preference: 170/-101 Next hop type: Router Address: 0x168d48c Next-hop reference count: 10 Source: 172.18.11.1 Next hop: 172.18.11.1 via ge-0/0/4.1121, selected State: <NotBest Ext> Inactive reason: Not Best in its group - Update source Local AS: 64700 Peer AS: 65510 Age: 22:50 Task: BGP_65510.172.18.11.1+179 AS path: 65510 65515 65519 65534 ? Accepted Localpref: 100 Router ID: 10.10.10.10 Preference: 170/-101 Next hop type: Indirect Address: 0x168d064 Next-hop reference count: 10 Source: 192.168.2.1 Next hop type: Router, Next hop index: 544 Next hop: 172.20.77.2 via ge-0/0/1.0, selected Protocol next hop: 172.18.2.1 Indirect next hop: 16a0570 State: <Int Ext> Inactive reason: Interior > Exterior > Exterior via Interior Local AS: 64700 Peer AS: 64700 Age: 22:25 Metric2: 2 Task: BGP_64700.192.168.2.1+179 AS path: 65520 65515 65519 65534 ? Accepted Localpref: 100 Router ID: 192.168.2.1
Question: How many advertisements have been received for this route? Where did they come from?
Answer: The route was received three times. The route was received from both of the EBGP peers as well as the from the IBGP peer.
www.juniper.net
Question: How many next hops are associated with the active route (denoted by a *)? Why?
Answer: Only one next hop is associated with the active route. Of the three received advertisements, by default only one advertisement will be used for forwarding. 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.
[edit protocols bgp] lab@srxA-1# set group my-ext-group multipath [edit protocols bgp] lab@srxA-1# commit commit 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.
[edit protocols bgp] lab@srxA-1# run show route 172.28.102.0/24 detail active-path inet.0: 40 destinations, 66 routes (40 active, 0 holddown, 0 hidden) 172.28.102.0/24 (3 entries, 1 announced) *BGP Preference: 170/-101 Next hop type: Router Address: 0x1678010 Next-hop reference count: 20 Source: 172.18.1.1 Next hop: 172.18.1.1 via ge-0/0/3.0 Next hop: 172.18.11.1 via ge-0/0/4.1121, selected State: <Active Ext> Local AS: 64700 Peer AS: 65510 Age: 24:40 Task: BGP_65510.172.18.1.1+179 Announcement bits (3): 0-KRT 3-BGP_RT_Background 4-Resolve tree 1 AS path: 65510 65515 65519 65534 ? Accepted Multipath Localpref: 100 Router ID: 10.10.10.10
www.juniper.net
Question: How many next hops does the active route now have installed?
Answer: Two next hops now exist for the 172.28.102.0/24 route. Step 4.5 Use the run show route forwarding-table destination 172.28.102.0/24 command to view the packet forwarding table.
[edit protocols bgp] lab@srxA-1# run show route forwarding-table destination 172.28.102.0/24 Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif 172.28.102.0/24 user 0 172.18.11.1 ucst 548 7 ge-0/0/4.1121 Routing table: __master.anon__.inet Internet: Destination Type RtRef Next hop default perm 0
Type Index NhRef Netif rjct 524 1
Question: Are the two routes to the EBGP peers installed in the packet forwarding table?
Answer: No. Only one route is installed in the packet forwarding table. The default forwarding behavior for two or more equal cost routes is to randomly pick one to be installed in the forwarding table. In this example, the route is using the ge-0/0/4.1121 interface for the 172.28.102.0/24 route. 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.
[edit protocols bgp] lab@srxA-1# top edit policy-options policy-statement pfe-load-balance [edit policy-options policy-statement pfe-load-balance] lab@srxA-1# set term 1 from protocol bgp [edit policy-options policy-statement pfe-load-balance] lab@srxA-1# set term 1 then load-balance per-packet [edit policy-options policy-statement pfe-load-balance]
lab@srxA-1# show term 1 { from protocol bgp; then { load-balance per-packet; } } [edit policy-options policy-statement pfe-load-balance] lab@srxA-1#
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.
[edit policy-options policy-statement pfe-load-balance] lab@srxA-1# top edit routing-options forwarding-table [edit routing-options forwarding-table] lab@srxA-1# set export pfe-load-balance [edit routing-options forwarding-table] lab@srxA-1# commit commit complete [edit routing-options forwarding-table] lab@srxA-1#
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.
[edit routing-options forwarding-table] lab@srxA-1# run show route forwarding-table destination 172.28.102.0/24 Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif 172.28.102.0/24 user 0 ulst 262142 12 172.18.1.1 ucst 546 3 ge-0/0/3.0 172.18.11.1 ucst 548 4 ge-0/0/4.1121 Routing table: __master.anon__.inet Internet: Destination Type RtRef Next hop default perm 0
www.juniper.net
Question: Is the forwarding table using both next-hop interfaces to reach the 172.28.102.0/24 route?
Answer: Yes, the forwarding table now has two next-hop interfaces for the 172.28.102.0/24 route, one for each EBGP peer.
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 BGPPart 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.
[edit routing-options forwarding-table] lab@srxA-1# top edit protocols bgp [edit protocols bgp] lab@srxA-1# show advertise-inactive; group my-int-group { type internal; local-address 192.168.1.1; neighbor 192.168.1.2; neighbor 192.168.2.1; neighbor 192.168.2.2; } group my-ext-group { type external; export adv-aggregates; peer-as 65510; multipath; neighbor 172.18.1.1; neighbor 172.18.11.1; } [edit protocols bgp] lab@srxA-1# delete group my-ext-group neighbor peer-address [edit protocols bgp] lab@srxA-1# delete group my-ext-group neighbor peer-address [edit protocols bgp] lab@srxA-1# delete group my-ext-group multipath
[edit protocols bgp] lab@srxA-1#
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.
[edit protocols bgp] lab@srxA-1# top edit routing-options [edit routing-options] lab@srxA-1# set static route PE-loopback-address/32 next-hop interface-address [edit routing-options] lab@srxA-1# set static route PE-loopback-address/32 next-hop interface-address [edit routing-options] lab@srxA-1# set static route PE-loopback-address/32 no-readvertise [edit routing-options] lab@srxA-1# show static route 172.31.15.11/32 { next-hop [ 172.18.1.1 172.18.11.1 ]; no-readvertise; } [edit routing-options] lab@srxA-1# commit commit complete [edit routing-options] lab@srxA-1#
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.
[edit routing-options] lab@srxA-1# run ping PE-loopback-address source local-loopback-address rapid PING 172.31.15.11 (172.31.15.11): 56 data bytes !!!!! --- 172.31.15.11 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.697/3.023/7.580/2.283 ms
www.juniper.net
Question: Is the ping successful?
Answer: Yes, the ping should be successful. If it is not successful, verify your configuration and consult with your instructor as needed. 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 routers loopback address as the local-address. Commit your configuration when complete.
[edit routing-options] lab@srxA-1# top edit protocols bgp [edit protocols bgp] lab@srxA-1# set group my-ext-group neighbor PE-loopback-address [edit protocols bgp] lab@srxA-1# set group my-ext-group local-address local-loopback-address [edit protocols bgp] lab@srxA-1# show advertise-inactive; group my-int-group { type internal; local-address 192.168.1.1; neighbor 192.168.1.2; neighbor 192.168.2.1; neighbor 192.168.2.2; } group my-ext-group { type external; local-address 192.168.1.1; export adv-aggregates; peer-as 65510; neighbor 172.31.15.11; } [edit protocols bgp] lab@srxA-1# commit commit complete [edit protocols bgp] lab@srxA-1#
Step 5.5 Check the state of the EBGP session using the run show bgp summary command.
[edit protocols bgp] lab@srxA-1# run show bgp summary Groups: 2 Peers: 4 Down peers: 1 Table Tot Paths Act Paths Suppressed History Damp State inet.0 6 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last State|#Active/Received/Accepted/Damped... 172.31.15.11 65510 0 0 0 0 192.168.1.2 64700 100 109 0 0 3/3/0 0/0/0/0 192.168.2.1 64700 105 104 0 0 0/0/0 0/0/0/0 192.168.2.2 64700 100 107 0 0 3/3/0 0/0/0/0
Pending 0 Up/Dwn 9 Idle 46:12 0/ 44:32 0/ 46:04 0/
Question: What is the state of the EBGP peering session? Why?
Answer: The EBGP peering session is in Idle state. All external BGP peering sessions must be peered with the physical interface or a TCP session will not be established. 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.
[edit protocols bgp] lab@srxA-1# set group my-ext-group multihop [edit protocols bgp] lab@srxA-1# commit commit complete
Step 5.7 Check the status of the EBGP session with the run show bgp summary command.
[edit protocols bgp] lab@srxA-1# run show bgp summary Groups: 2 Peers: 4 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 26 10 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 172.31.15.11 65510 6 4 0 0 22 10/ 10/10/0 0/0/0/0 192.168.1.2 64700 103 116 0 0 47:38 0/ 3/3/0 0/0/0/0
192.168.2.1 10/10/0 192.168.2.2 3/3/0
64700 0/0/0/0 64700 0/0/0/0
112 103
111 114
0 0
0 0
45:58 0/ 47:30 0/
Question: What is the state of the EBGP peering session after the multihop command is configured?
Answer: The EBGP peering session should be established. If the session is not established, check your configuration or consult with your instructor. 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.
[edit protocols bgp] lab@srxA-1# run show route receive-protocol bgp PE-loopback-address inet.0: 41 destinations, 57 routes (41 active, 0 holddown, 1 hidden) Prefix Nexthop MED Lclpref AS path * 0.0.0.0/0 172.31.15.11 65510 I * 172.28.102.0/24 172.31.15.11 65510 65515 65519 * 172.28.103.0/24 172.31.15.11 65510 65515 65519 * 172.28.104.0/24 172.31.15.11 65510 65515 65519 * 172.30.1.0/24 172.31.15.11 65510 65515 65516 * 172.30.2.0/24 172.31.15.11 65510 65515 65516 * 172.30.3.0/24 172.31.15.11 65510 65515 65516 * 172.31.10.0/24 172.31.15.11 65510 65515 65531 * 172.31.11.0/24 172.31.15.11 65510 65515 65531 * 172.31.12.0/24 172.31.15.11 65510 65515 65531
65534 65534 65534 65517 65517 65517 E E E
? ? ? I I I
Question: Are routes being received from the EBGP peering session?
Answer: Yes. Routes are being received from the EBGP router.
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
[edit protocols bgp] lab@srxA-1# run show route 172.28.102.0/24 detail active-path inet.0: 41 destinations, 57 routes (41 active, 0 holddown, 1 hidden) 172.28.102.0/24 (2 entries, 1 announced) *BGP Preference: 170/-101 Next hop type: Indirect Address: 0x168cb58 Next-hop reference count: 30 Source: 172.31.15.11 Next hop type: Router, Next hop index: 262142 Next hop: 172.18.1.1 via ge-0/0/3.0, selected Next hop: 172.18.11.1 via ge-0/0/4.1121 Protocol next hop: 172.31.15.11 Indirect next hop: 16a0570 262143 State: <Active Ext> Local AS: 64700 Peer AS: 65510 Age: 2:07 Metric2: 0 Task: BGP_65510.172.31.15.11+179 Announcement bits (3): 0-KRT 3-BGP_RT_Background 4-Resolve tree 1 AS path: 65510 65515 65519 65534 ? Accepted Localpref: 100 Router ID: 10.10.10.10
Question: How many next hops does the active route have installed?
Answer: Two next hops exist for the 172.28.102.0/24 route. 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.
[edit protocols bgp] lab@srxA-1# run show route forwarding-table destination 172.28.102.0/24 Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif 172.28.102.0/24 user 0 indr 262143 11 ulst 262142 2 172.18.1.1 ucst 546 6 ge-0/0/3.0 172.18.11.1 ucst 548 3 ge-0/0/4.1121 Routing table: __master.anon__.inet Internet: Destination Type RtRef Next hop default perm 0
www.juniper.net
Question: Is the forwarding table using both next-hop interfaces to reach the 172.28.102.0/24 route? Why or why not?
Answer: Yes, the forwarding table has two next-hop interfaces for the 172.28.102.0/24 route, one for each of the equal cost static routes that you added to the forwarding table earlier in the lab. Two next hops exist in the forwarding table because of the load-balancing that was applied earlier in the lab. Step 5.11 Exit configuration mode and log out of your assigned device using the exit command.
[edit protocols bgp] lab@srxA-1# exit configuration-mode Exiting configuration mode lab@srxA-1> exit
srxA-1 (ttyu0) login:
STOP
www.juniper.net
www.juniper.net
Lab 5
BGP Attributes (Detailed)
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: Configure export and import policy. Configure and apply a next-hop self policy. Manipulate BGP path attributes to influence traffic flow.
www.juniper.net
BGP Attributes (Detailed) Lab 51 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?
srxA-1 (ttyu0) login: lab Password: --- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC
Lab 52 BGP Attributes (Detailed) www.juniper.net
lab@srxA-1> configure Entering configuration mode [edit] lab@srxA-1# load override ajer/lab5-start.config load complete [edit] lab@srxA-1# commit commit complete
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.
[edit] lab@srxA-1# show routing-options autonomous-system 64700;
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.
[edit] lab@srxA-1# edit protocols bgp [edit protocols bgp] lab@srxA-1# show group my-int-group { type internal; local-address 192.168.1.1; neighbor 192.168.1.2; neighbor 192.168.2.1; neighbor 192.168.2.2; } [edit protocols bgp] lab@srxA-1#
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.
www.juniper.net
BGP Attributes (Detailed) Lab 53
[edit protocols bgp] lab@srxA-1# set group my-ext-group type external [edit protocols bgp] lab@srxA-1# set group my-ext-group neighbor peer-address [edit protocols bgp] lab@srxA-1# set group my-ext-group peer-as peer-as [edit protocols bgp] lab@srxA-1# show group my-ext-group type external; peer-as 65510; neighbor 172.18.1.1; [edit protocols bgp] lab@srxA-1# commit commit complete
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.
[edit protocols bgp] lab@srxA-1# run show bgp summary Groups: 2 Peers: 4 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State inet.0 22 13 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last State|#Active/Received/Accepted/Damped... 172.18.1.1 65510 46 40 0 0 9/9/0 0/0/0/0 192.168.1.2 64700 42 52 0 0 2/2/0 0/0/0/0 192.168.2.1 64700 53 54 0 0 9/9/0 0/0/0/0 192.168.2.2 64700 42 52 0 0 2/2/0 0/0/0/0
Pending 0 Up/Dwn 16:29 9/ 19:12 2/ 19:12 0/ 19:04 2/
Question: How many BGP routes are you receiving from your EBGP neighbor?
Answer: You should be receiving nine routes from your EBGP neighbor.
Lab 54 BGP Attributes (Detailed)
www.juniper.net
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.
[edit protocols bgp] lab@srxA-1# run show route protocol bgp hidden inet.0: 31 destinations, 40 routes (31 active, 0 holddown, 9 hidden) + = Active Route, - = Last Active, * = Both 4.0.0.0/21 [BGP/170] 01:10:24, localpref 100, from 192.168.2.1 AS path: 65520 I Unusable [BGP/170] 01:10:23, localpref 100, from 192.168.2.1 AS path: 65520 65515 26749 3356 I Unusable [BGP/170] 01:10:23, localpref 100, from 192.168.2.1 AS path: 65520 65515 65510 65510 65510 I Unusable [BGP/170] 01:10:23, localpref 100, from 192.168.2.1 AS path: 65520 65515 I Unusable [BGP/170] 01:10:23, localpref 100, from 192.168.2.1 AS path: 65520 65515 65510 I Unusable [BGP/170] 01:10:23, localpref 100, from 192.168.2.1 AS path: 65520 65515 65510 65510 26749 I Unusable [BGP/170] 01:10:23, localpref 100, from 192.168.2.1 AS path: 65520 65520 I Unusable [BGP/170] 01:10:23, localpref 100, from 192.168.2.1 AS path: 65520 65515 3356 9888 I Unusable [BGP/170] 01:10:23, localpref 100, from 192.168.2.1 AS path: 65520 65520 65520 65520 1123 I Unusable
Note
8.0.0.0/21
11.0.0.0/21
63.14.4.0/22
68.11.8.0/22
77.48.28.0/22
87.47.48.0/22
92.68.12.0/22
158.76.56.0/22
The output will differ depending on the device you are using.
www.juniper.net
Question: Why are these routes hidden?
Answer: The next hop is only updated by the EBGP neighbor. Because the connected route between the ASs is not known internally, the EBGP routes coming from the IBGP neighbor are marked as hidden. 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.
[edit protocols bgp] lab@srxA-1# top edit policy-options [edit policy-options] lab@srxA-1# set policy-statement nhs term 1 then next-hop self [edit policy-options] lab@srxA-1#
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.
[edit policy-options] lab@srxA-1# top edit protocols bgp [edit protocols bgp] lab@srxA-1# set group my-int-group export nhs [edit protocols bgp] lab@srxA-1# show group my-int-group type internal; local-address 192.168.1.1; export nhs; neighbor 192.168.1.2; neighbor 192.168.2.1; neighbor 192.168.2.2; [edit protocols bgp] lab@srxA-1# commit commit complete [edit protocols bgp] lab@srxA-1#
www.juniper.net
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.
[edit protocols bgp] lab@srxA-1# run show route protocol bgp hidden inet.0: 31 destinations, 37 routes (31 active, 0 holddown, 0 hidden)
Question: How many hidden routes are there?
Answer: There should be no hidden routes after committing the nhs policy.
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.
[edit protocols bgp] lab@srxA-1# run show route protocol bgp aspath-regex "()" inet.0: 31 destinations, 37 routes (31 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 67.3.192.0/21 *[BGP/170] 01:52:07, localpref 100, from 192.168.1.2 AS path: I > to 172.20.113.10 via ge-0/0/4.141 *[BGP/170] 01:51:59, localpref 100, from 192.168.2.2 AS path: I > to 172.20.77.2 via ge-0/0/1.0
67.3.200.0/21
www.juniper.net
69.3.176.0/21
69.3.184.0/21
*[BGP/170] 01:52:07, localpref 100, from 192.168.1.2 AS path: I > to 172.20.113.10 via ge-0/0/4.141 *[BGP/170] 01:51:59, localpref 100, from 192.168.2.2 AS path: I > to 172.20.77.2 via ge-0/0/1.0
Question: What does the () aspath-regex value match?
Answer: The () aspath-regex matches a null AS path. 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.
[edit protocols bgp] lab@srxA-1# run show route advertising-protocol bgp peer-address | match
"^\*
* * * * * * * 4.0.0.0/21 67.3.192.0/21 67.3.200.0/21 69.3.176.0/21 69.3.184.0/21 87.47.48.0/22 158.76.56.0/22 65520 65520 1123 I Self Self Self Self Self Self Self 65520 I I I I I 65520 65520 I 65520 65520
Question: How many routes are advertised to your external peer?
Answer: Based on the previous output, you should be sending seven routes. 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.
[edit protocols bgp] lab@srxA-1# top edit policy-options [edit policy-options] lab@srxA-1# set as-path null-as "()" [edit policy-options] lab@srxA-1#
www.juniper.net
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.
[edit policy-options] lab@srxA-1# set policy-statement export-ebgp term local-routes from as-path null-as [edit policy-options] lab@srxA-1# set policy-statement export-ebgp term local-routes from protocol bgp [edit policy-options] lab@srxA-1# set policy-statement export-ebgp term local-routes then accept [edit policy-options] lab@srxA-1# set policy-statement export-ebgp term last then reject [edit policy-options] lab@srxA-1# show as-path null-as "()"; [edit policy-options] lab@srxA-1# show policy-statement export-ebgp term local-routes { from { protocol bgp; as-path null-as; } then accept; } term last { then reject; }
Question: What is the default terminating action for a routing policy in BGP?
Answer: The default action is to accept all BGP routes. 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.
[edit policy-options] lab@srxA-1# top edit protocols bgp
www.juniper.net
[edit protocols bgp] lab@srxA-1# set group my-ext-group export export-ebgp [edit protocols bgp] lab@srxA-1# show group my-ext-group type external; export export-ebgp; peer-as 65510; neighbor 172.18.1.1; [edit protocols bgp] lab@srxA-1# commit commit complete [edit protocols bgp] lab@srxA-1#
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.
[edit protocols bgp] lab@srxA-1# run show route advertising-protocol bgp peer-address | match "^\* * 67.3.192.0/21 Self I * 67.3.200.0/21 Self I * 69.3.176.0/21 Self I * 69.3.184.0/21 Self I
Question: How many routes are you now sending to your EBGP peer?
Answer: After applying the policy, you should only be sending the four routes generated within your AS 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
Advanced Junos Enterprise Routing Note
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.
[edit protocols bgp] lab@srxA-1# top edit policy-options policy-statement export-ebgp [edit policy-options policy-statement export-ebgp] lab@srxA-1# set term origin from route-filter 67.3.200.0/21 exact [edit policy-options policy-statement export-ebgp] lab@srxA-1# set term origin from route-filter 69.3.184.0/21 exact [edit policy-options policy-statement export-ebgp] lab@srxA-1# set term origin then origin incomplete [edit policy-options policy-statement export-ebgp] lab@srxA-1# set term origin then accept [edit policy-options policy-statement export-ebgp] lab@srxA-1# insert term origin before term local-routes [edit policy-options policy-statement export-ebgp] lab@srxA-1# show term origin { from { route-filter 67.3.200.0/21 exact; route-filter 69.3.184.0/21 exact; } then { origin incomplete; accept; } } term local-routes { from { protocol bgp; as-path null-as; } then accept; } term last {
www.juniper.net BGP Attributes (Detailed) Lab 511
then reject; } [edit policy-options policy-statement export-ebgp] lab@srxA-1# commit commit complete [edit policy-options policy-statement export-ebgp] lab@srxA-1#
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.
[edit protocols bgp] lab@srxA-2# top edit policy-options policy-statement export-ebgp [edit policy-options] lab@srxA-2# set term as-prepend from route-filter 67.3.192.0/21 exact [edit policy-options policy-statement export-ebgp] lab@srxA-2# set term as-prepend from route-filter 69.3.176.0/21 exact [edit policy-options policy-statement export-ebgp] lab@srxA-2# set term as-prepend then as-path-prepend "64700 64700" [edit policy-options policy-statement export-ebgp] lab@srxA-2# set term as-prepend then accept [edit policy-options policy-statement export-ebgp] lab@srxA-2# insert term as-prepend before term local-routes [edit policy-options policy-statement export-ebgp] lab@srxA-2# show term as-prepend { from { route-filter 67.3.192.0/21 exact; route-filter 69.3.176.0/21 exact; } then { as-path-prepend "64700 64700"; accept; } } term local-routes { from { protocol bgp; as-path null-as; }
then accept; } term last { then reject; } [edit policy-options policy-statement export-ebgp] lab@srxA-2# commit commit complete [edit policy-options policy-statement export-ebgp] lab@srxA-2#
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.
[edit policy-options policy-statement export-ebgp] lab@srxA-1# run telnet 8.0.0.1 source source-address Trying 8.0.0.1... Connected to 8.0.0.1. Escape character is '^]'. vr-device (ttyp1) login: ispy Password: --- JUNOS 11.4R1.6 built 2011-11-15 11:28:05 UTC NOTE: This router is divided into many virtual routers used by different teams. Please only configure your own virtual router. You must use 'configure private' to configure this router. ispy@vr-device>
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.
www.juniper.net
ispy@vr-device> show route table ispY-X 67.3.192.0/21 ispY-A.inet.0: 20 destinations, 24 routes (20 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 67.3.192.0/21 *[BGP/170] 04:36:27, localpref 100 AS path: 65510 64700 I > to 10.10.1.1 via lt-0/0/0.502 [BGP/170] 00:05:57, localpref 100 AS path: 65520 64700 64700 64700 I > to 10.10.2.1 via lt-0/0/0.504
ispy@vr-device> show route table ispY-X 67.3.200.0/21 ispY-A.inet.0: 20 destinations, 24 routes (20 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 67.3.200.0/21 *[BGP/170] 04:33:06, localpref 100 AS path: 65520 64700 I > to 10.10.2.1 via lt-0/0/0.504 [BGP/170] 00:49:54, localpref 100 AS path: 65510 64700 ? > to 10.10.1.1 via lt-0/0/0.502
Note
The output might differ slightly depending on which device is used. Question: Is the prepend AS path policy working as expected?
Answer: Yes. Routes 67.3.192.0/21 and 69.3.176.0/21 should have an AS path length of 4. Isp Y should prefer the path through AS 65510 for these routes. Question: Is the manipulation of the origin attribute working as expected?
Answer: Yes. Routes 67.3.200.0/21 (and 69.3.184.0/21) should have an origin of incomplete represented by a question mark (?) in the AS path. Isp Y should prefer the path through AS 65520. Step 5.5 Log out of the vr-device.
www.juniper.net
ispy@vr-device> exit Connection closed by foreign host.
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.
[edit policy-options policy-statement export-ebgp] lab@srxA-1# up [edit policy-options] lab@srxA-1# set community peer-local members "65510|65520:1000" [edit policy-options] lab@srxA-1#
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.
[edit policy-options] lab@srxA-1# set policy-statement import-ebgp term peer-local-community from community peer-local [edit policy-options] lab@srxA-1# set policy-statement import-ebgp term peer-local-community then local-preference 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
[edit protocols bgp] lab@srxA-1# set group my-ext-group import import-ebgp [edit protocols bgp] lab@srxA-1# show group my-ext-group type external; import import-ebgp; export export-ebgp; peer-as 65510; neighbor 172.18.1.1; [edit protocols bgp] lab@srxA-1# top show policy-options community peer-local members "65510|65520:1000"; [edit protocols bgp] lab@srxA-1# top show policy-options policy-statement import-ebgp term peer-local-community { from community peer-local; then { local-preference 1000; } } [edit protocols bgp] lab@srxA-1# commit commit complete [edit protocols bgp] lab@srxA-1#
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.
[edit protocols bgp] lab@srxA-1# run show route community "65510|65520:1000" extensive | match "^[0-9]|Localpref" 4.0.0.0/21 (2 entries, 1 announced) Localpref: 1000 11.0.0.0/21 (1 entry, 1 announced) Localpref: 1000 Localpref: 1000 68.11.8.0/22 (1 entry, 1 announced) Localpref: 1000 Localpref: 1000 77.48.28.0/22 (1 entry, 1 announced) Localpref: 1000 Localpref: 1000 87.47.48.0/22 (2 entries, 1 announced) Localpref: 1000 158.76.56.0/22 (2 entries, 1 announced) Localpref: 1000
Question: Are the peers local routes getting the right local preference based on the policy applied in the previous steps?
Answer: Yes, the previous output shows that routes containing community 65510:1000 or 65520:1000 have a local preference of 1000.
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.
[edit protocols bgp]] lab@srxA-1# top edit routing-options [edit routing-options] lab@srxA-1# set aggregate route 69.3.176.0/20 [edit routing-options] lab@srxA-1# set aggregate route 67.3.192.0/20 [edit routing-options] lab@srxA-1# show aggregate route 69.3.176.0/20; route 67.3.192.0/20; [edit routing-options] lab@srxA-1# commit commit complete [edit routing-options] lab@srxA-1#
Step 7.2 For verification, issue a run show route protocol aggregate command and ensure the aggregate routes were created.
www.juniper.net
[edit routing-options] lab@srxA-1# run show route protocol aggregate inet.0: 33 destinations, 39 routes (33 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 67.3.192.0/20 69.3.176.0/20 *[Aggregate/130] 00:04:07 Reject *[Aggregate/130] 00:04:07 Reject
Question: What is the requirement for an aggregate route to become active?
Answer: The router must have more specific routes that fall within that aggregate route. Step 7.3 Navigate to the [edit policy-options] configuration hierarchy. Create a community named no-export containing the well-known no-export community.
[edit routing-options] lab@srxA-1# top edit policy-options [edit policy-options] lab@srxA-1# set community no-export members no-export [edit policy-options] lab@srxA-1#
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.
[edit policy-options] lab@srxA-1# edit policy-statement export-ebgp [edit policy-options policy-statement export-ebgp] lab@srxA-1# set term adv-agg from protocol aggregate [edit policy-options policy-statement export-ebgp] lab@srxA-1# set term adv-agg then accept [edit policy-options policy-statement export-ebgp] lab@srxA-1# set term ne then community add no-export [edit policy-options policy-statement export-ebgp] lab@srxA-1# set term ne then next term
[edit policy-options policy-statement export-ebgp] lab@srxA-1#
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.
[edit policy-options policy-statement export-ebgp] lab@srxA-1# insert term adv-agg before term origin [edit policy-options policy-statement export-ebgp] lab@srxA-1# insert term ne after term adv-agg [edit policy-options policy-statement export-ebgp] lab@srxA-1# show term adv-agg { from protocol aggregate; then accept; } term ne { then { community add no-export; next term; } } term origin { from { route-filter 67.3.200.0/21 exact; route-filter 69.3.184.0/21 exact; } then { origin incomplete; accept; } } term local-routes { from { protocol bgp; as-path null-as; } then accept; } term last {
www.juniper.net BGP Attributes (Detailed) Lab 519
then reject; } [edit policy-options policy-statement export-ebgp] lab@srxA-1# commit and-quit commit complete Exiting configuration mode lab@srxA-1>
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.
[edit policy-options policy-statement export-ebgp] lab@srxA-2# insert term adv-agg before term as-prepend [edit policy-options policy-statement export-ebgp] lab@srxA-2# insert term ne after term adv-agg [edit policy-options policy-statement export-ebgp] lab@srxA-2# show term adv-agg { from protocol aggregate; then accept; } term ne { then { community add no-export; next term; } } term as-prepend { from { route-filter 67.3.192.0/21 exact; route-filter 69.3.176.0/21 exact; } then { as-path-prepend "64700 64700"; accept; } } term local-routes {
from { protocol bgp; as-path null-as; } then accept; } term last { then reject; } [edit policy-options policy-statement export-ebgp] lab@srxA-2# commit and-quit commit complete Exiting configuration mode lab@srxA-2>
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.
lab@srxA-1> show route advertising-protocol bgp peer-address inet.0: 33 destinations, 39 routes (33 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 67.3.192.0/20 Self I * 67.3.192.0/21 Self I * 67.3.200.0/21 Self ? * 69.3.176.0/20 Self I * 69.3.176.0/21 Self I * 69.3.184.0/21 Self ?
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.
lab@srxA-1> telnet 8.0.0.1 source source-address Trying 8.0.0.1... Connected to 8.0.0.1. Escape character is '^]'. vr-device (ttyp1) login: ispy Password:
www.juniper.net
--- JUNOS 11.4R1.6 built 2011-11-15 11:28:05 UTC NOTE: This router is divided into many virtual routers used by different teams. Please only configure your own virtual router. You must use 'configure private' to configure this router. ispy@vr-device>
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).
ispy@vr-device> show route table ispY-X aspath-regex ".*64700$" ispY-A.inet.0: 18 destinations, 20 routes (18 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 67.3.192.0/20 *[BGP/170] 00:11:43, localpref 100 AS path: 65520 64700 I > to 10.10.2.1 via lt-0/0/0.504 [BGP/170] 00:07:32, localpref 100 AS path: 65510 64700 I > to 10.10.1.1 via lt-0/0/0.502 *[BGP/170] 00:11:43, localpref 100 AS path: 65520 64700 I > to 10.10.2.1 via lt-0/0/0.504 [BGP/170] 00:07:32, localpref 100 AS path: 65510 64700 I > to 10.10.1.1 via lt-0/0/0.502
69.3.176.0/20
Question: Why does the number of routes advertised from AS 64700 (6) differ from the amount of routes ISP Y receives (two)?
Answer: The number differs because the directly connected providers honor the no-export well-known community and supress the advertisement of the more-specific routes, exactly how it was crafted in the export policy. Step 7.10 Log out of the vr-device using the exit command.
ispy@vr-device> exit Connection closed by foreign host.
lab@srxA-1> exit
STOP
www.juniper.net
www.juniper.net
Lab 6
Implementing Enterprise Routing Policies (Detailed)
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: The use of private autonomous systems (ASs) to segregate the network. Configuration of the common routing policies for external connectivity.
www.juniper.net
Implementing Enterprise Routing Policies (Detailed) Lab 61 11.a.11.4R1.6

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?
srxA-1 (ttyu0) login: lab Password: --- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC lab@srxA-1> configure
Lab 62 Implementing Enterprise Routing Policies (Detailed) www.juniper.net
Entering configuration mode [edit] lab@srxA-1# load override ajer/lab6-start.config load complete [edit] lab@srxA-1# commit commit complete
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.
[edit] lab@srxA-1# set routing-options autonomous-system 10458
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.
[edit] lab@srxA-1# edit protocols bgp [edit protocols bgp] lab@srxA-1# set group my-int-group type internal [edit protocols bgp] lab@srxA-1# set group my-int-group neighbor remote-loopback-address [edit protocols bgp] lab@srxA-1# set group my-int-group local-address local-loopback-address [edit protocols bgp] lab@srxA-1# show group my-int-group { type internal; local-address 192.168.1.1; neighbor 192.168.2.1; } [edit protocols bgp]
www.juniper.net Implementing Enterprise Routing Policies (Detailed) Lab 63
lab@srxA-1# commit commit complete [edit protocols bgp] lab@srxA-1#
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.
[edit protocols bgp] lab@srxA-1# set group my-ent-group type external [edit protocols bgp] lab@srxA-1# set group my-ent-group peer-as peer-as [edit protocols bgp] lab@srxA-1# set group my-ent-group neighbor address [edit protocols bgp] lab@srxA-1# show group my-ent-group type external; peer-as 65001; neighbor 172.20.113.10; [edit protocols bgp] lab@srxA-1# commit commit complete
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.
[edit protocols bgp] lab@srxA-1# set group my-ext-group type external [edit protocols bgp] lab@srxA-1# set group my-ext-group peer-as peer-as [edit protocols bgp] lab@srxA-1# set group my-ext-group neighbor address [edit protocols bgp] lab@srxA-1# show group my-ext-group type external; peer-as 3356; neighbor 172.18.1.1;
[edit protocols bgp] lab@srxA-1# commit commit complete

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.
[edit protocols bgp] lab@srxA-1# run show bgp summary [...] 172.18.1.1 3356 1506/1506/1506/0 0/0/0/0 172.20.113.10 65001 1/1/0 0/0/0/0 192.168.2.1 10458 113/1521/1521/0 0/0/0/0
22 18 110
11 85 105
0 0 0
0 0 0
45 7:32 1/ 19:04
Question: How many BGP routes are you receiving from your ISP neighbor?
Answer: You should be receiving approximately 1500 routes from your ISP neighbor. Question: Which type of external routing policy is this policy?
Answer: Because no modification to external routes currently exists, this type of policy is topology-driven.
STOP
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.
www.juniper.net
Implementing Enterprise Routing Policies (Detailed) Lab 65
Advanced Junos Enterprise Routing 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.
[edit protocols bgp] lab@srxA-1# top edit policy-options [edit policy-options] lab@srxA-1# set community ispX members 3356:1 [edit policy-options] lab@srxA-1# set community ispZ members 813:1 [edit policy-options] lab@srxA-1#
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.
[edit policy-options] lab@srxA-1# set policy-statement primary-secondary term primary from route-filter 0/0 exact [edit policy-options] lab@srxA-1# set policy-statement primary-secondary term primary from community ispX [edit policy-options] lab@srxA-1# set policy-statement primary-secondary term primary then local-preference 1000 [edit policy-options] lab@srxA-1# set policy-statement primary-secondary term primary then 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.
[edit policy-options] lab@srxA-1# set policy-statement primary-secondary term secondary from route-filter 0/0 exact [edit policy-options] lab@srxA-1# set policy-statement primary-secondary term secondary from community ispZ [edit policy-options] lab@srxA-1# set policy-statement primary-secondary term secondary then accept
Step 3.4 Within the primary-secondary policy, create a third term named reject with an action of reject.
[edit policy-options] lab@srxA-1# set policy-statement primary-secondary term reject then reject [edit policy-options] lab@srxA-1# show policy-statement primary-secondary { term primary { from { community ispX; route-filter 0.0.0.0/0 exact; } then { local-preference 1000; accept; } } term secondary { from { community ispZ; route-filter 0.0.0.0/0 exact; } then accept; } term reject { then reject; } } community ispX members 3356:1; community ispZ members 813:1;
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.
www.juniper.net
[edit protocols bgp] lab@srxA-1# set group my-ext-group import primary-secondary [edit protocols bgp] lab@srxA-1# show group my-ext-group type external; import primary-secondary; peer-as 3356; neighbor 172.18.1.1; [edit protocols bgp] lab@srxA-1# commit commit complete [edit protocols bgp] lab@srxA-1#
Step 3.6 For verification, issue the run show route 0/0 exact command.
[edit protocols bgp] lab@srxA-1# run show route 0/0 exact inet.0: 1520 destinations, 1520 routes (15 active, 0 holddown, 1505 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[BGP/170] 01:44:59, localpref 1000 AS path: 3356 I > to 172.18.1.1 via ge-0/0/4.171
Note
The output will differ depending on the device to which you are assigned.
Note
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?
Answer: The value should be 1000.
Lab 68 Implementing Enterprise Routing Policies (Detailed)
www.juniper.net
Question: Which path does the enterprise prefer now for all external traffic?
Answer: After the import policy is applied, the path toward ISP X through Team 1s SRX Series device is the preferred path 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 (6451265535).
[edit protocols bgp] lab@srxA-1# top edit policy-options [edit policy-options] lab@srxA-1# set as-path private "[64512-65535]" [edit policy-options] lab@srxA-1#
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.
[edit policy-options] lab@srxA-1# set policy-statement ext-ebgp term my-ent-nets from as-path private [edit policy-options] lab@srxA-1# set policy-statement ext-ebgp term my-ent-nets then accept [edit policy-options] lab@srxA-1# set policy-statement ext-ebgp term reject-all then reject [edit policy-options] lab@srxA-1# show policy-statement ext-ebgp term my-ent-nets { from as-path private; then accept; } term reject-all { then reject; }
[edit policy-options] lab@srxA-1# show as-path private "[64512-65535]"; [edit policy-options] lab@srxA-1# commit commit complete
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.
[edit policy-options] lab@srxA-1# top edit protocols bgp [edit protocols bgp] lab@srxA-1# set group my-ext-group export ext-ebgp [edit protocols bgp] lab@srxA-1# show group my-ext-group type external; import primary-secondary; export ext-ebgp; peer-as 3356; neighbor 172.18.1.1; [edit protocols bgp] lab@srxA-1# commit commit complete [edit protocols bgp] lab@srxA-1#
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.
[edit protocols bgp] lab@srxA-1# run show route advertising-protocol bgp ext-peer-address inet.0: 1520 destinations, 1520 routes (15 active, 0 holddown, 1505 hidden) Prefix Nexthop MED Lclpref AS path * 67.3.192.1/32 Self 65001 I * 67.3.200.1/32 Self 65002 I
www.juniper.net
Question: Which routes are you advertising to the external ISP peers?
Answer: You should only be advertising 67.3.192.1/32 and 67.3.200.1/32. 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.
[edit protocols bgp] lab@srxA-1# set group my-ext-group remove-private [edit protocols bgp] lab@srxA-1# show group my-ext-group type external; import primary-secondary; export ext-ebgp; remove-private; peer-as 3356; neighbor 172.18.1.1; [edit protocols bgp] lab@srxA-1# commit commit complete
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.
[edit protocols bgp] lab@srxA-1# run show route advertising-protocol bgp ext-peer-address inet.0: 1520 destinations, 1520 routes (15 active, 0 holddown, 1505 hidden) Prefix Nexthop MED Lclpref AS path * 67.3.192.1/32 Self I * 67.3.200.1/32 Self I
Question: Is the private AS value removed from the advertisements?
Answer: Yes, as shown in the previous capture, the private AS value has been removed from the AS path column.
www.juniper.net
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.
[edit protocols bgp] lab@srxA-2# top edit policy-options [edit policy-options] lab@srxA-2# set policy-statement ext-ebgp term my-ent-nets then as-path-prepend "10458 10458 10458" [edit policy-options] lab@srxA-2# show policy-statement ext-ebgp term my-ent-nets { from as-path private; then { as-path-prepend "10458 10458 10458"; accept; } } term reject-all { then reject; } [edit policy-options] lab@srxA-2# commit commit complete [edit policy-options] lab@srxA-2#
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.
[edit policy-options] lab@srxA-2# run show route advertising-protocol bgp 172.18.2.1
www.juniper.net
inet.0: 1534 destinations, 1535 routes (15 active, 0 holddown, 1519 hidden) Prefix Nexthop MED Lclpref AS path * 67.3.192.1/32 Self 10458 10458 10458 [10458] I * 67.3.200.1/32 Self 10458 10458 10458 [10458] I
Question: Why does AS prepending help the strict primary/secondary network design?
Answer: By prepending the AS toward ISP Z, you are influencing the providers routing decision. The path from ISP X should now look more desirable to the rest of the Internet.
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.
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.
[edit policy-options] lab@srxA-2# set policy-statement primary-secondary term ISPZ-specifics from community ispZ [edit policy-options] lab@srxA-2# set policy-statement primary-secondary term ISPZ-specifics then accept [edit policy-options] lab@srxA-2# insert policy-statement primary-secondary term ISPZ-specifics before term reject
[edit policy-options] lab@srxA-2# show policy-statement primary-secondary term strict { from { community ispX; route-filter 0.0.0.0/0 exact; } then accept; } term secondary { from { community ispZ; route-filter 0.0.0.0/0 exact; } then accept; } term ISPZ-specifics { from community ispZ; then accept; } term reject { then reject; } [edit policy-options] lab@srxA-2# commit commit complete
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.
[edit policy-options] lab@srxA-1# run show route protocol bgp aspath-regex "813$" | no-more inet.0: 1632 destinations, 1632 routes (127 active, 0 holddown, 1505 hidden) + = Active Route, - = Last Active, * = Both 35.0.150.0/24 *[BGP/170] 00:00:58, localpref 100, from 192.168.2.1 AS path: 813 I > to 172.20.77.2 via ge-0/0/1.0
www.juniper.net
35.100.75.0/24
35.100.150.0/24
35.200.75.0/24
35.200.150.0/24
36.0.75.0/24
*[BGP/170] 00:00:58, localpref 100, AS path: 813 I > to 172.20.77.2 via ge-0/0/1.0 *[BGP/170] 00:00:58, localpref 100, AS path: 813 I > to 172.20.77.2 via ge-0/0/1.0 *[BGP/170] 00:00:58, localpref 100, AS path: 813 I > to 172.20.77.2 via ge-0/0/1.0 *[BGP/170] 00:00:58, localpref 100, AS path: 813 I > to 172.20.77.2 via ge-0/0/1.0 *[BGP/170] 00:00:58, localpref 100, AS path: 813 I > to 172.20.77.2 via ge-0/0/1.0
from 192.168.2.1
from 192.168.2.1
from 192.168.2.1
from 192.168.2.1
from 192.168.2.1
[...]
Question: What is the next hop for routes in AS 813?
Answer: All the routes from AS 813 should be pointing to the 172.20.77.2 address on the Team 2 SRX Series device. Question: How does this configuration accomplish a loose primary/secondary design?
Answer: By allowing specific routes from ISP Z and not receiving the announcements from ISP X, the network uses the more specific destinations.
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. 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.
[edit policy-options] lab@srxA-1# top edit protocols bgp [edit protocols bgp] lab@srxA-1# delete group my-ext-group import primary-secondary [edit protocols bgp] lab@srxA-1# show group my-ext-group
type external; export ext-ebgp; remove-private; peer-as 3356; neighbor 172.18.1.1; [edit protocols bgp] lab@srxA-1# commit commit complete [edit protocols bgp] lab@srxA-1#
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.
lab@srxA-1# run show bgp summary Groups: 3 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 3028 1620 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 172.18.1.1 3356 155 143 0 0 1:03:19 1506/1506/1506/0 0/0/0/0 172.20.113.10 65001 494 770 0 0 3:52:19 1/ 1/1/0 0/0/0/0 192.168.2.1 10458 729 720 0 0 4:03:51 113/1521/1521/0 0/0/0/0
Question: How many routes are active from the ISP?
Answer: The answer will vary depending on the device you are using, but there should be approximately 1500 routes 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.
[edit protocols bgp] lab@srxA-1# top edit policy-options
www.juniper.net
[edit policy-options] lab@srxA-1# set policy-statement load-shared term half from route-filter 0.0.0.0/1 orlonger [edit policy-options] lab@srxA-1# set policy-statement load-shared term half then local-preference 1000 [edit policy-options] lab@srxA-1# set policy-statement load-shared term half then accept [edit policy-options] lab@srxA-1#
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.
[edit protocols bgp] lab@srxA-2# top edit policy-options [edit policy-options] lab@srxA-2# set policy-statement load-shared term half from route-filter 128.0.0.0/1 orlonger [edit policy-options] lab@srxA-2# set policy-statement load-shared term half then local-preference 1000 [edit policy-options] lab@srxA-2# set policy-statement load-shared term half then accept [edit policy-options] lab@srxA-2#
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.
[edit policy-options] lab@srxA-1# top edit protocols bgp [edit protocols bgp] lab@srxA-1# set group my-ext-group import load-shared lab@srxA-1# top show policy-options policy-statement load-shared term half { from { route-filter 0.0.0.0/1 orlonger; } then { local-preference 1000;
accept; } } [edit protocols bgp] lab@srxA-1# show group my-ext-group type external; import load-shared; export ext-ebgp; remove-private; peer-as 3356; neighbor 172.18.1.1; [edit protocols bgp] lab@srxA-1# commit commit complete [edit protocols bgp] lab@srxA-1#
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.
Note
The following captures show the outputs from both student devices.
[edit protocols bgp] lab@srxA-1# run show bgp summary Groups: 3 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 2482 1620 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 172.18.1.1 3356 187 177 0 0 1:18:24 645/1506/1506/0 0/0/0/0 172.20.113.10 65001 526 838 0 0 4:07:24 1/ 1/1/0 0/0/0/0 192.168.2.1 10458 820 814 0 0 4:18:56 974/975/975/0 0/0/0/0 ............................................................................... [edit protocols bgp] lab@srxA-2# run show bgp summary Groups: 3 Peers: 3 Down peers: 0
www.juniper.net
Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 2167 1620 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 172.18.2.1 813 187 178 0 0 1:18:06 974/1520/1520/0 0/0/0/0 172.20.114.10 65002 525 884 0 0 4:06:45 1/ 1/1/0 0/0/0/0 192.168.1.1 10458 812 819 0 0 4:18:47 645/646/646/0 0/0/0/0
Question: How many routes are active from your internal peer?
Answer: The answer might vary. Team 1 should have approximately 974 active routes from the internal peer and Team 2 should have approximately 645 active routes from the 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.
[edit protocols bgp] lab@srxA-1# top edit routing-options [edit routing-options] lab@srxA-1# set aggregate route 67.3.192.0/21
[edit routing-options] lab@srxA-1# set aggregate route 67.3.192.0/20 [edit routing-options] lab@srxA-1# show aggregate route 67.3.192.0/21; route 67.3.192.0/20; [edit routing-options] lab@srxA-1# commit commit complete [edit routing-options] lab@srxA-1#
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.
[edit protocols bgp] lab@srxA-2# top edit routing-options [edit routing-options] lab@srxA-2# set aggregate route 67.3.200.0/21 [edit routing-options] lab@srxA-2# set aggregate route 67.3.192.0/20 [edit routing-options] lab@srxA-2# show aggregate route 67.3.200.0/21; route 67.3.192.0/20; [edit routing-options] lab@srxA-2# commit commit complete [edit routing-options] lab@srxA-2#
Step 7.3 For verification, issue the command run show route protocol aggregate to confirm that the aggregate routes have become active.
[edit routing-options] lab@srxA-1# run show route protocol aggregate inet.0: 1634 destinations, 2496 routes (1634 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 67.3.192.0/20 *[Aggregate/130] 00:12:53 Reject
www.juniper.net
67.3.192.0/21
*[Aggregate/130] 00:12:53 Reject
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.
[edit routing-options] lab@srxA-1# top edit policy-options [edit policy-options] lab@srxA-1# set policy-statement export-load-shared term aggregates from protocol aggregate [edit policy-options] lab@srxA-1# set policy-statement export-load-shared term aggregates then accept [edit policy-options] lab@srxA-1# set policy-statement export-load-shared term reject then reject [edit policy-options] lab@srxA-1#
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.
[edit policy-options] lab@srxA-1# top edit protocols bgp [edit protocols bgp] lab@srxA-1# delete group my-ext-group export [edit protocols bgp] lab@srxA-1# set group my-ext-group export export-load-shared [edit protocols bgp] lab@srxA-1# top show policy-options policy-statement export-load-shared term aggregates { from protocol aggregate; then accept; } term reject { then reject; } [edit protocols bgp] lab@srxA-1# show group my-ext-group type external; import load-shared; export export-load-shared;
remove-private; peer-as 3356; neighbor 172.18.1.1; [edit protocols bgp] lab@srxA-1# commit commit complete [edit protocols bgp] lab@srxA-1#
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.
[edit protocols bgp] lab@srxA-1# run show route advertising-protocol bgp ext-peer-address inet.0: 1634 destinations, 2496 routes (1634 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 67.3.192.0/20 Self I * 67.3.192.0/21 Self I
Question: How does this lab part accomplish a load-shared design?
Answer: By advertising a more specific prefix from each edge to each provider, you are influencing the provider to use a longest-prefix routing to load-share traffic. Question: Why is announcing a less specific aggregate important in this design?
Answer: By announcing a less specific aggregate route, you account for a failure in the advertisement on one of the edges. Step 7.7 Exit configuration mode and log out of your assigned device using the exit command.
[edit protocols bgp] lab@srxA-1# exit configuration-mode Exiting configuration mode lab@srxA-1> exit
www.juniper.net
STOP
www.juniper.net
www.juniper.net
Lab 7
Implementing PIM-SM (Detailed)
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: 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.
www.juniper.net
Implementing PIM-SM (Detailed) Lab 71 11.a.11.4R1.6
Part 1: Loading the Baseline Topology

In this lab part, you configure your student devices interfaces according to the lab diagram labeled Lab 7: Implementing PIM-SMParts 13. 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.
srxA-1 (ttyu0) login: lab
Lab 72 Implementing PIM-SM (Detailed) www.juniper.net
Password: --- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC lab@srxA-1> configure Entering configuration mode [edit] lab@srxA-1# load override ajer/lab7-start.config load complete [edit] lab@srxA-1# commit and-quit commit complete Exiting configuration mode lab@srxA-1>
Step 1.4 Use the show configuration interfaces command to determine which interfaces have been preconfigured for you.
lab@srxA-1> show configuration interfaces ge-0/0/0 { description "MGMT Interface - DO NOT DELETE"; unit 0 { family inet { address 10.210.14.131/26; } } } ge-0/0/1 { unit 0 { family inet { address 172.20.77.1/30; } } } ge-0/0/4 { vlan-tagging; unit 0 { vlan-id 121; family inet { address 172.18.121.2/30; } } } ge-0/0/8 { unit 0 { family inet { address 10.1.1.1/30; } } } lo0 { unit 0 {
www.juniper.net Implementing PIM-SM (Detailed) Lab 73
family inet { address 192.168.121.1/32; } } }
Question: Have any interfaces been preconfigured? If so, which interfaces have been preconfigured?
Answer: The ge-0/0/0, ge-0/0/1, ge-0/0/4, ge-0/0/8, and lo0 interfaces have been preconfigured for you. Step 1.5 Use the show configuration protocols command to determine which protocols have been preconfigured for you.
lab@srxA-1> show configuration protocols ospf { area 0.0.0.0 { interface all; interface ge-0/0/8.0 { passive; } interface ge-0/0/0.0 { disable; } } }
Question: Have any protocols been preconfigured? If so, which protocols have been preconfigured?
Answer: The OSPF protocol has been preconfigured, as shown on the lab diagram. Step 1.6 Verify that each interface has been configured properly by attempting to ping each of the locally attached routers and hosts.
lab@srxA-1> ping address rapid PING 172.18.121.1 (172.18.121.1): 56 data bytes !!!!! --- 172.18.121.1 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.393/2.354/4.220/1.019 ms
lab@srxA-1> ping address rapid PING 172.20.77.2 (172.20.77.2): 56 data bytes !!!!! --- 172.20.77.2 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.278/1.971/3.113/0.789 ms lab@srxA-1> ping address rapid PING 10.1.1.2 (10.1.1.2): 56 data bytes !!!!! --- 10.1.1.2 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.217/2.087/4.400/1.172 ms
Question: Were all of the locally attached routers and hosts reachable?
Answer: Yes, all devices should be reachable. If any of the devices were not reachable, check your local interface configuration to determine whether any mistakes exist. Ask your instructor for help if needed. 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.
lab@srxA-1> show ospf interface Interface State Area ge-0/0/1.0 BDR 0.0.0.0 ge-0/0/4.0 DR 0.0.0.0 ge-0/0/8.0 DRother 0.0.0.0 lo0.0 DR 0.0.0.0 sp-0/0/0.0 PtToPt 0.0.0.0 lab@srxA-1> show Address 172.20.77.2 172.18.121.1 ospf neighbor Interface ge-0/0/1.0 ge-0/0/4.0 DR ID 192.168.122.1 192.168.121.1 0.0.0.0 192.168.121.1 0.0.0.0 BDR ID 192.168.121.1 192.168.120.1 0.0.0.0 0.0.0.0 0.0.0.0 Nbrs 1 1 0 0 0
State Full Full
ID 192.168.122.1 192.168.120.1
Pri 128 128
Dead 31 35
www.juniper.net
Implementing PIM-SM (Detailed) Lab 75
Question: Are the adjacencies established between your router and the two neighboring routers?
Answer: Yes, the adjacencies should be established. If any of the devices were not reachable, check your local interface configuration to determine whether any mistakes exist. Ask your instructor for help if needed. 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 devices routing table.
lab@srxA-1> show route 172.18.120/24 inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.18.120.0/30 *[OSPF/10] 03:52:44, metric 2 > to 172.18.121.1 via ge-0/0/4.0
Question: Does the route to the source exist? How was it learned?
Answer: Yes, a route to the source should exist in the routing table. The route was learned from OSPF.
STOP
Part 2: Configuring IGMP

In this lab part, you configure your student devices 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 devices ge-0/0/8 interface to use IGMP version 2 (IGMPv2).
lab@srxA-1> configure Entering configuration mode [edit] lab@srxA-1# edit protocols igmp [edit protocols igmp] lab@srxA-1# set interface ge-0/0/8.0 version 2 [edit protocols igmp] lab@srxA-1#
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.
[edit protocols igmp] lab@srxA-1# set interface ge-0/0/8.0 immediate-leave [edit protocols igmp] lab@srxA-1# commit commit complete
Step 2.3 Issue the run show igmp interface command to determine which interfaces are enabled for IGMP.
[edit protocols igmp] lab@srxA-1# run show igmp interface Interface: ge-0/0/8.0 Querier: 10.1.1.1 State: Up Timeout: None Version: Immediate leave: On Promiscuous mode: Off Passive: Off Configured Parameters: IGMP Query Interval: 125.0 IGMP Query Response Interval: 10.0 IGMP Last Member Query Interval: 1.0 IGMP Robustness Count: 2 Derived Parameters: IGMP Membership Timeout: 260.0 IGMP Other Querier Present Timeout: 255.0
2 Groups:
www.juniper.net
Question: Has the ge-0/0/8 interface been properly enabled for IGMP?
Answer: Yes, the ge-0/0/8 interface should appear as the only interface enabled for IGMP at this point in the lab. If the ge-0/0/8 interface is not listed in the output of the command, check your local interface configuration to determine whether any mistakes exist. Ask your instructor for help if needed. Question: Which router has been elected querier for the Ethernet segment?
Answer: This answer will vary by student. In the example output, 10.1.1.1 (the student device) has been elected as the querier for the segment. Question: Which version of IGMP has been enabled?
Answer: IGMPv2 should be enabled. Question: How many groups have been learned by your student device through the ge-0/0/8 interface?
Answer: This answer will vary by student as well as the lab environment. In the example output, no multicast groups have been learned through the ge-0/0/8 interface. Step 2.4 Issue the run show igmp group command to determine the groups that have been learned from IGMP.
[edit protocols igmp] lab@srxA-1# run show igmp group Interface: local, Groups: 5
Group: 224.0.0.2 Source: 0.0.0.0 Last reported by: Local Timeout: 0 Type: Dynamic ...
Question: Have any groups been learned on your assigned device?
Answer: This answer will vary by student as well as the lab environment. In the example output, 224.0.0.2 has been reported by the attached receiver. This is the All Routers multicast group address. Step 2.5 From your assigned device, log in to the attached receiver using SSH, a username of lab, and a password of lab123.
[edit protocols igmp] lab@srxA-1# run ssh lab@address lab@10.1.1.2's password: Last login: Sun Mar 4 10:13:32 2012 from 10.1.1.1 [lab@CoS1 ~]$
Step 2.6 Analyze the following table to determine the group that you will configure the receiver to join.
Receivers Pod A Pod B Pod C Pod D
Groups 224.7.7.121 224.7.7.123 224.7.7.125 224.7.7.127
www.juniper.net
Question: Which group will you be configuring your receiver to receive?
Answer: This answer will vary by student. For example, the administrator of srxA-1 will configure the attached receiver to receive traffic destined for 224.7.7.121. 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.
[lab@CoS1 ~]$ exit logout Connection to 10.1.1.2 closed. [edit protocols igmp] lab@srxA-1#
Step 2.9 Use the run show igmp group command to verify that your device is receiving IGMP reports from the locally attached receiver.
[edit protocols igmp] lab@srxA-1# run show igmp group Interface: ge-0/0/8.0, Groups: 1 Group: 224.7.7.121 Source: 0.0.0.0 Last reported by: 10.1.1.2 Timeout: 258 Type: Dynamic ...
Lab 710 Implementing PIM-SM (Detailed)
www.juniper.net
Question: Is your router receiving IGMP reports for any new groups? Which groups?
Answer: Yes, your router should be receiving IGMP reports for the new group. For example, the administrator of srxA-1 should see the receipt of IGMP reports from the attached receiver for 224.7.7.121.
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 routers interfaces to run PIM-SM. Do not forget the loopback interface.
[edit protocols igmp] lab@srxA-1# up 1 edit pim [edit protocols pim] lab@srxA-1# set interface ge-0/0/4.0 mode sparse [edit protocols pim] lab@srxA-1# set interface ge-0/0/8.0 mode sparse [edit protocols pim] lab@srxA-1# set interface ge-0/0/1.0 mode sparse [edit protocols pim] lab@srxA-1# set interface lo0.0 mode sparse [edit protocols pim] lab@srxA-1#
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.
www.juniper.net
RP srxA-1 (192.168.121.1) srxB-1 (192.168.121.1) srxC-1 (192.168.121.1) srxD-1 (192.168.121.1)
Group 224.7.7.121 224.7.7.123 224.7.7.125 224.7.7.127
Question: Which router will be the RP in your topology?
Answer: This answer will vary by student. For example, for pod A, srxA-1 will be the RP for the group 224.7.7.121. 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.
[edit protocols pim] lab@srxA-1# set rp local address 192.168.121.1 group-ranges 224/4 [edit protocols pim] lab@srxA-1# commit
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.
[edit protocols pim] lab@srxA-2# set rp static address 192.168.121.1 group-ranges 224/4 [edit protocols pim] lab@srxA-2# commit commit complete
Step 3.5 Verify that the correct interfaces have been configured for PIM-SM by issuing the run show pim interfaces command.
[edit protocols pim] lab@srxA-1# run show pim interfaces Instance: PIM.master
Name address ge-0/0/1.0 172.20.77.2 ge-0/0/4.0 172.18.121.2 ge-0/0/8.0 10.1.1.1 lo0.0 192.168.121.1 ppd0.32769
Stat Mode Up Up Up Up Up Sparse Sparse Sparse Sparse Sparse
IP V State NbrCnt JoinCnt(sg) JoinCnt(*g) DR 4 2 NotDR 4 2 DR 4 2 DR 4 2 DR 4 2 P2P 1 1 0 0 0 0 1 0 0 0 0 0 0 0 0
Question: Do all of the interfaces that you configured for PIM-SM appear in the output of the command?
Answer: Yes, all of the interfaces should be listed in the output. If any interfaces are missing, check your configuration to determine whether any mistakes exist. Ask your instructor for help if needed. 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?
Answer: Yes, you might see a ppd0 or ppe0 interface in the output of the command. These are the PIM encapsulation and decapsulation interfaces. These interfaces are logical interfaces used for the encapsulation (source DR) and decapsulation (RP) of register messages. Step 3.6 Verify that the correct RP has been configured on your router by issuing the run show pim rps command.
[edit protocols pim] lab@srxA-1# run show pim rps Instance: PIM.master Address family INET RP address Type 192.168.121.1 static Address family INET6
Holdtime Timeout Groups Group prefixes 0 None 1 224.0.0.0/4
Question: Is your router aware of any active RPs?
Answer: Yes, there should be a single RP available in the network that has been configured statically. If no active RP exists, check your configuration to determine whether any mistakes exist. Ask your instructor for help if needed. Question: Are there any active groups that your router is associating with the RP? If so, why?
Answer: Yes, there should be an active group associated with this RP. Because a receiver is attached to your router requesting the receipt of multicast traffic, your router is using this RP to gain access to the flow of that multicast traffic. Step 3.7 Issue the run show pim join extensive command to determine the (S,G) and (*,G) states of your router.
[edit protocols pim] lab@srxA-1# run show pim join extensive Instance: PIM.master Family: INET R = Rendezvous Point Tree, S = Sparse, W = Wildcard Group: 224.7.7.121 Source: * RP: 192.168.121.1 Flags: sparse,rptree,wildcard Upstream interface: Local Upstream neighbor: Local Upstream state: Local RP Uptime: 00:02:06 Downstream neighbors: Interface: ge-0/0/1.0 172.20.77.2 State: Join Flags: SRW Timeout: 160 Uptime: 00:01:50 Time since last Join: 00:00:50 Downstream neighbors: Interface: ge-0/0/8.0 10.1.1.1 State: Join Flags: SRW Timeout: Infinity Uptime: 00:02:06 Time since last Join: 00:02:06 Group: 224.7.7.121 Source: 172.18.120.2 Flags: sparse,spt Upstream interface: ge-0/0/4.0
Upstream neighbor: 172.18.121.1 Upstream state: None, Local RP, Join to Source Keepalive timeout: 356 Uptime: 00:02:05 Downstream neighbors: Interface: ge-0/0/1.0 (pruned) 172.20.77.2 State: Prune Flags: SR Timeout: 160 Uptime: 00:01:50 Time since last Prune: 00:00:50 Downstream neighbors: Interface: ge-0/0/8.0 10.1.1.1 State: Join Flags: S Timeout: Infinity Uptime: 00:02:05 Time since last Join: 00:02:05 Instance: PIM.master Family: INET6 R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Question: How many states are associated with your multicast group? Why?
Answer: Two states, (*,G) and (S,G), should be associated with your multicast group. The (S,G) state is being used to deliver the multicast traffic from the existing source to the receivers along the SPT. The (*,G) state, although not currently being used for forwarding, exists for the possibility of future sources that might transmit to the same group. The (*,G) state enables traffic to be delivered to the receivers as well. Question: What are the upstream interfaces associated each state? Are they correct?
Answer: The answer will vary by student. For (*,G) states, the upstream interface should be in the direction of the RP. For (S,G) states, the upstream interface should be in the direction of the source. Question: What are the downstream interfaces associated each state? Are they correct?
Answer: The answer will vary by student. For (*,G) and (S,G) states, the downstream interfaces should be in the direction of the active receivers.
Step 3.8 Verify that multicast traffic is being forwarded by your router by issuing the run show multicast route extensive command.
[edit protocols pim] lab@srxA-1# run show multicast route extensive Instance: master Family: INET Group: 224.7.7.121 Source: 172.18.120.2/32 Upstream interface: ge-0/0/4.0 Downstream interface list: ge-0/0/8.0 Session description: Unknown Statistics: 53 kBps, 101 pps, 16169 packets Next-hop ID: 262143 Upstream protocol: PIM Route state: Active Forwarding state: Forwarding Cache lifetime/timeout: 360 seconds Wrong incoming interface notifications: 1 Uptime: 00:02:55 Instance: master Family: INET6
Question: Is multicast traffic being forwarded by your router? If so, at what rate is being forwarded?
Answer: Yes, your router should be forwarding traffic for your group. In the example output, the traffic is being forwarded at a rate of 101 packets per second (pps).
STOP
Part 4: Configuring PIM-SM with the BSR mechanism

In this lab part, you use the Lab 7: Implementing PIM-SMPart 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.
[edit protocols pim] lab@srxA-1# delete rp [edit protocols pim] lab@srxA-1# commit and-quit commit complete Exiting configuration 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.
lab@srxA-1> ssh lab@address lab@10.1.1.2's password: Last login: Tue Mar 6 06:28:25 2012 from 10.1.1.1 [lab@CoS1 ~]$
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:
[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.
Groups 224.7.7.122 224.7.7.124 224.7.7.126 224.7.7.128
www.juniper.net
Question: Which group will you be configuring your receiver to receive?
Answer: This answer will vary by student. For example, the administrator of srxA-1 will be configuring the attached receiver to receive traffic destined for 224.7.7.122. 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
[lab@CoS1 ~]$ exit logout Connection to 10.1.1.2 closed. lab@srxA-1>
Step 4.8 Using the show igmp group command, verify that your device is receiving IGMP reports from the locally attached receiver.
lab@srxA-1> show igmp group Interface: ge-0/0/8.0, Groups: 1 Group: 224.7.7.122 Source: 0.0.0.0 Last reported by: 10.1.1.2 Timeout: 249 Type: Dynamic ...
Question: Is your router receiving IGMP reports for any new groups? If so, for which groups?
Answer: Yes, your router should be receiving IGMP reports for the new group. For example, the administrator of srxA-1 should see the receipt of IGMP reports from the attached receiver for 224.7.7.122.
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.
RP/BSR srxA-2 (192.168.122.1) srxB-2 (192.168.122.1) srxC-2 (192.168.122.1) srxD-2 (192.168.122.1)
Group 224.7.7.122 224.7.7.124 224.7.7.126 224.7.7.128
Question: Which router will act as the RP and BSR in your topology?
Answer: This answer will vary by student. For example, for group A, srxA-2 will be the RP for the group 224.7.7.122. Also, in the same example srxA-2 will be a candidate BSR as well. 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 steps table. Also, configure the BSR priority to a value of 50. Commit your configuration and exit to operational mode.
lab@srxA-2> configure Entering configuration mode [edit] lab@srxA-2# edit protocols pim [edit protocols pim] lab@srxA-2# set rp local address 192.168.122.1 group-ranges group-address [edit protocols pim] lab@srxA-2# set rp bootstrap-priority 50 [edit protocols pim] lab@srxA-2# commit and-quit commit complete Exiting configuration mode
www.juniper.net
Question: Why do you think that there is no need to add any RP-related configuration to the non-RP and non-BSR routers?
Answer: There is no need for extra configuration because each router is configured for PIM-SM version 2, so each router will learn RP information dynamically from the BSR. 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.

lab@srxA-1> show pim bootstrap Instance: PIM.master BSR 192.168.122.1 None Pri Local address 50 192.168.121.1 0 (null) Pri State Timeout 0 InEligible 127 0 0
Question: Has a BSR been elected in the network?
Answer: Yes, a BSR should have been elected. If no BSR is elected, check your configuration to determine whether any mistakes exist. Ask your instructor for help if needed. Question: What is the IP address of the BSR? Is this expected?
Answer: The IP address of the BSR should be 192.168.122.1. This is expected because it was the only one configured with a priority value. Step 4.12 Verify that the correct RP has been configured on your router by issuing the show pim rps command.
lab@srxA-1> show pim rps Instance: PIM.master Address family INET RP address Type 192.168.122.1 bootstrap Address family INET6
Holdtime Timeout Groups Group prefixes 150 145 1 224.7.7.122/32
Question: Is your router aware of any active RPs?
Answer: Yes, one RP should be available in the network which has been learned through the BSR mechanism. If no active RP exists, check your configuration to determine whether it contains any mistakes. Ask your instructor for help if needed. Step 4.13 Use the show pim join extensive command to determine the (S,G) and (*,G) states of your router.
lab@srxA-1> show pim join extensive Instance: PIM.master Family: INET R = Rendezvous Point Tree, S = Sparse, W = Wildcard Group: 224.7.7.122 Source: * RP: 192.168.122.1 Flags: sparse,rptree,wildcard Upstream interface: ge-0/0/1.0 Upstream neighbor: 172.20.77.2 Upstream state: Join to RP Uptime: 00:00:46 Downstream neighbors: Interface: ge-0/0/8.0 10.1.1.1 State: Join Flags: SRW Timeout: Infinity Uptime: 00:00:46 Time since last Join: 00:00:46 Group: 224.7.7.122 Source: 172.18.120.2 Flags: sparse,spt Upstream interface: ge-0/0/4.0 Upstream neighbor: 172.18.121.1 Upstream state: Join to Source, Prune to RP Keepalive timeout: 354 Uptime: 00:00:46 Downstream neighbors: Interface: ge-0/0/8.0 10.1.1.1 State: Join Flags: S Timeout: Infinity Uptime: 00:00:46 Time since last Join: 00:00:46
www.juniper.net
Instance: PIM.master Family: INET6 R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Question: How many states are associated with your multicast group? Why?
Answer: Two states, (*,G) and (S,G), should be associated with your multicast group. The (S,G) state is being used to deliver the multicast traffic from the existing source to the receivers along the SPT. The (*,G) state, although not currently being used for forwarding, exists for the possibility of future sources that might transmit to the same group. The (*,G) state enables traffic to be delivered to the receivers as well. Question: What are the upstream interfaces associated each state? Are they correct?
Answer: The answer will vary by student. For (*,G) states, the upstream interface should be in the direction of the RP. For (S,G) states, the upstream interface should be in the direction of the source. Question: What are the downstream interfaces associated each state? Are they correct?
Answer: The answer will vary by student. For (*,G) and (S,G) states, the downstream interfaces should be in the direction of the active receivers. Step 4.14 Verify that multicast traffic is being forwarded by your router by issuing the show multicast route extensive command.
lab@srxA-1> show multicast route extensive Instance: master Family: INET Group: 224.7.7.122 Source: 172.18.120.2/32 Upstream interface: ge-0/0/4.0 Downstream interface list:
ge-0/0/8.0 Session description: Unknown Statistics: 53 kBps, 101 pps, 8413 packets Next-hop ID: 262143 Upstream protocol: PIM Route state: Active Forwarding state: Forwarding Cache lifetime/timeout: 360 seconds Wrong incoming interface notifications: 1 Uptime: 00:01:24 Instance: master Family: INET6
Question: Is multicast traffic being forwarded by your router? If so, at which rate is it being forwarded?
Answer: Yes, your router should be forwarding traffic for your group. In the example output, the traffic is being forwarded at a rate of 101 pps. Step 4.15 Log out of your assigned device using the exit command when complete.
lab@srxA-1> exit
STOP
www.juniper.net
www.juniper.net
Lab 8
Implementing SSM (Detailed)
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: 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.
www.juniper.net
Implementing SSM (Detailed) Lab 81 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.
srxA-1 (ttyu0) login: lab Password:
Lab 82 Implementing SSM (Detailed) www.juniper.net
--- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC lab@srxA-1> configure Entering configuration mode [edit] lab@srxA-1# load override ajer/lab8-start.config load complete [edit] lab@srxA-1# commit and-quit commit complete Exiting configuration mode lab@srxA-1>
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 lab@10.1.1.2's password: Last login: Fri Mar 8 07:48:07 2011 from 10.1.1.1 [lab@CoS1 ~]$
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
[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.
www.juniper.net Implementing SSM (Detailed) Lab 83
Step 1.8 Issue the clear igmp statistics and clear igmp membership commands to clear any IGMP-related information from previous labs.
lab@srxA-1> clear igmp statistics lab@srxA-1> clear igmp membership Clearing Group Membership Info for ge-0/0/1.0 Clearing Group Membership Info for ge-0/0/4.0 Clearing Group Membership Info for ge-0/0/8.0
Part 2: Configuring IGMPv3

In this lab part, you configure your student devices 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 devices ge-0/0/8 interface to use IGMPv3. Commit your configuration and exit to operational mode when complete.
lab@srxA-1> configure Entering configuration mode [edit] lab@srxA-1# edit protocols igmp [edit protocols igmp] lab@srxA-1# set interface ge-0/0/8.0 version 3 [edit protocols igmp] lab@srxA-1# commit and-quit commit complete Exiting configuration mode lab@srxA-1>
Step 2.2 Issue the show igmp interface command to determine which interfaces are enabled for IGMP.
lab@srxA-1> show igmp interface Interface: ge-0/0/8.0 Querier: 10.1.1.1 State: Up Timeout: Immediate leave: On Promiscuous mode: Off Passive: Off Interface: ge-0/0/4.0 Querier: 172.18.121.1
Lab 84 Implementing SSM (Detailed)
None Version:
3 Groups:
www.juniper.net
State: Up Timeout: Immediate leave: Off Promiscuous mode: Off Passive: Off Interface: ge-0/0/1.0 Querier: 172.20.77.1 State: Up Timeout: Immediate leave: Off Promiscuous mode: Off Passive: Off
186 Version:
2 Groups:
None Version:
2 Groups:
Configured Parameters: IGMP Query Interval: 125.0 IGMP Query Response Interval: 10.0 IGMP Last Member Query Interval: 1.0 IGMP Robustness Count: 2 Derived Parameters: IGMP Membership Timeout: 260.0 IGMP Other Querier Present Timeout: 255.0
Question: Has the ge-0/0/8 interface been properly enabled for IGMPv3?
Answer: Yes, the ge-0/0/8 interface should appear as the only interface enabled for IGMPv3. If the ge-0/0/8 interface is not listed in the output of the command, check your local interface configuration to determine whether any mistakes exist. Ask your instructor for help if needed. 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.
www.juniper.net
Implementing SSM (Detailed) Lab 85
Receivers Pod A
Source, Groups Any Source, 224.221.1.1 Any Source, 232.221.2.2 172.18.120.2, 232.221.3.3 Any Source, 224.222.1.1 Any Source, 232.222.2.2 172.18.120.6, 232.222.3.3 Any Source, 224.223.1.1 Any Source, 232.223.2.2 172.18.120.10, 232.223.3.3 Any Source, 224.224.1.1 Any Source, 232.224.2.2 172.18.120.14, 232.224.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 lab@10.1.1.2'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 172.18.120.y@232.22z.3.3 1111 rtp& [3] 3793
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>
www.juniper.net
Step 2.7 Issue the show igmp group command to verify that your device is receiving IGMP reports from the locally attached receiver.
lab@srxA-1> show igmp group Interface: ge-0/0/8.0, Groups: 3 Group: 224.0.0.251 Source: 0.0.0.0 Last reported by: 10.1.1.2 Timeout: 206 Type: Dynamic Group: 224.221.1.1 Source: 0.0.0.0 Last reported by: 10.1.1.2 Timeout: 206 Type: Dynamic Group: 232.221.3.3 Group mode: Include Source: 172.18.120.2 Last reported by: 10.1.1.2 Timeout: 206 Type: Dynamic ...
Question: Is your router receiving IGMP reports for all three of the new groups?
Answer: No, the CLI output should show that the router is only receiving a report for two of the source and group combinations. The report for 232.22z.2.2 should be missing. Question: Is this the expected behavior? What could be a possible reason for this behavior?
Answer: This behavior is expected. The report received for 232.22z.2.2 has no source associated with it. A router that supports the SSM model will ignore a report from the 232/8 range when no source is specified. Step 2.8 Issue the show igmp statistics command and determine whether any IGMPv3 report errors have been logged.
lab@srxA-1> show igmp statistics IGMP packet statistics for all interfaces
www.juniper.net
IGMP Message type Received Membership Query 47 V1 Membership Report 0 DVMRP 0 PIM V1 0 Cisco Trace 0 V2 Membership Report 283 Group Leave 0 Mtrace Response 0 Mtrace Request 0 Domain Wide Report 0 V3 Membership Report 63 Other Unknown types IGMP v3 unsupported type IGMP v3 source required for SSM IGMP v3 mode not applicable for SSM IGMP Global Statistics Bad Length Bad Checksum Bad Receive If Rx non-local Timed out Rejected Report Total Interfaces
Sent 113 0 0 0 0 0 0 0 0 0 0
Rx errors 0 0 0 0 0 0 0 0 0 0 0 0 0 31 0
0 0 0 0 9 0 3
Question: Has your router noticed any IGMP report errors? Why or why not?
Answer: Yes, the report that is causing the IGMP v3 source required for SSM error is the one with the source and group combination of Any Source/232.22x.2.2. A report carrying a 232/8 group address must have a source associated with the group address.
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 receivers 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 receivers DR.
lab@srxA-1> show pim join extensive Instance: PIM.master Family: INET R = Rendezvous Point Tree, S = Sparse, W = Wildcard
www.juniper.net
Group: 232.221.3.3 Source: 172.18.120.2 Flags: sparse,spt Upstream interface: ge-0/0/4.0 Upstream neighbor: 172.18.121.1 Upstream state: Join to Source Keepalive timeout: 342 Uptime: 00:59:47 Downstream neighbors: Interface: ge-0/0/8.0 10.1.1.1 State: Join Flags: S Timeout: Infinity Uptime: 00:59:47 Time since last Join: 00:59:47 Instance: PIM.master Family: INET6 R = Rendezvous Point Tree, S = Sparse, W = Wildcard
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?
Answer: Only a single shortest-path tree (SPT) has been formed. A Join message has been sent for the source group combination of 172.18.121.y/ 232.22z.3.3 only. This is expected because, without an RP defined in the network, the receivers DR, in most cases, must learn the source from the receiver. Your router does not know the source for 224.22z.1.1 and 232.22z.2.2.
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.
lab@srxA-1> configure Entering configuration mode [edit] lab@srxA-1# edit policy-options
www.juniper.net
[edit policy-options] lab@srxA-1# set policy-statement ssm-groups term 10 from route-filter 224.22z.1.1 exact [edit policy-options] lab@srxA-1# set policy-statement ssm-groups term 10 from route-filter 232.22z.2.2 exact [edit policy-options] lab@srxA-1# set policy-statement ssm-groups term 10 then accept [edit policy-options] lab@srxA-1#
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.
[edit policy-options] lab@srxA-1# up 1 edit routing-options multicast [edit routing-options multicast] lab@srxA-1# set ssm-map map1 source source-ip-address policy ssm-groups [edit routing-options multicast] lab@srxA-1#
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.
[edit routing-options multicast] lab@srxA-1# top edit protocols igmp [edit protocols igmp] lab@srxA-1# set interface ge-0/0/8.0 ssm-map map1 [edit protocols igmp] lab@srxA-2# commit and-quit commit complete Exiting configuration mode lab@srxA-2>
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.
Lab 810 Implementing SSM (Detailed) www.juniper.net
Issue the show igmp group command to verify that your router is now accepting the IGMP report for 232.22z.2.2.
lab@srxA-1> show igmp group Interface: ge-0/0/8.0, Groups: 4 Group: 224.0.0.251 Source: 0.0.0.0 Last reported by: 10.1.1.2 Timeout: 247 Type: Dynamic Group: 224.221.1.1 Group mode: Include Source: 172.18.120.2 Last reported by: 10.1.1.2 Timeout: 247 Type: Dynamic Group: 232.221.2.2 Group mode: Include Source: 172.18.120.2 Last reported by: 10.1.1.2 Timeout: 247 Type: Dynamic Group: 232.221.3.3 Group mode: Include Source: 172.18.120.2 Last reported by: 10.1.1.2 Timeout: 247 Type: Dynamic ...
Question: Is your router accepting the IGMP reports for 232.22z.2.2?
Answer: Yes, your router should now be accepting the IGMP reports. If you do not see an entry for 232.22z.2.2, please wait up to 60 seconds (rtpquals report interval) and then issue the command again. If, after 60 seconds, you do not see an entry for 232.22z.2.2, notify your instructor. Question: What is the source associated with the 224.22z.1.1 and 232.22z.2.2 groups? Why?
Answer: As a result of configuring the ssm-map, both groups should be associated with the same source as the source of the 232.22z.3.3 traffic. 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.
lab@srxA-1> show pim join extensive Instance: PIM.master Family: INET R = Rendezvous Point Tree, S = Sparse, W = Wildcard Group: 224.221.1.1 Source: 172.18.120.2 Flags: sparse,spt Upstream interface: ge-0/0/4.0 Upstream neighbor: 172.18.121.1 Upstream state: Join to Source Keepalive timeout: 343 Uptime: 00:04:17 Downstream neighbors: Interface: ge-0/0/8.0 10.1.1.1 State: Join Flags: S Timeout: Infinity Uptime: 00:04:17 Time since last Join: 00:04:17 Group: 232.221.2.2 Source: 172.18.120.2 Flags: sparse,spt Upstream interface: ge-0/0/4.0 Upstream neighbor: 172.18.121.1 Upstream state: Join to Source Keepalive timeout: 343 Uptime: 00:03:58 Downstream neighbors: Interface: ge-0/0/8.0 10.1.1.1 State: Join Flags: S Timeout: Infinity Uptime: 00:03:58 Time since last Join: 00:03:58 Group: 232.221.3.3 Source: 172.18.120.2 Flags: sparse,spt Upstream interface: ge-0/0/4.0 Upstream neighbor: 172.18.121.1 Upstream state: Join to Source Keepalive timeout: 343 Uptime: 00:04:17 Downstream neighbors: Interface: ge-0/0/8.0 10.1.1.1 State: Join Flags: S Timeout: Infinity Uptime: 00:04:17 Time since last Join: 00:04:17 Instance: PIM.master Family: INET6 R = Rendezvous Point Tree, S = Sparse, W = Wildcard
www.juniper.net
Question: Have PIM Join messages been sent upstream toward the source for each of the three multicast groups? Is this the expected behavior?
Answer: Yes, PIM Join messages have been sent for all three multicast groups. Yes, this is 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.
lab@srxA-1> show multicast route extensive Instance: master Family: INET Group: 224.221.1.1 Source: 172.18.120.2/32 Upstream interface: ge-0/0/4.0 Downstream interface list: ge-0/0/8.0 Session description: Unknown Statistics: 52 kBps, 98 pps, 30920 packets Next-hop ID: 262143 Upstream protocol: PIM Route state: Active Forwarding state: Forwarding Cache lifetime/timeout: 360 seconds Wrong incoming interface notifications: 0 Uptime: 00:05:16 Group: 232.221.2.2 Source: 172.18.120.2/32 Upstream interface: ge-0/0/4.0 Downstream interface list: ge-0/0/8.0 Session description: Source specific multicast Statistics: 1 kBps, 2 pps, 2671 packets Next-hop ID: 262143 Upstream protocol: PIM Route state: Active Forwarding state: Forwarding Cache lifetime/timeout: 360 seconds Wrong incoming interface notifications: 0 Uptime: 00:04:57 Group: 232.221.3.3 Source: 172.18.120.2/32 Upstream interface: ge-0/0/4.0 Downstream interface list: ge-0/0/8.0
Session description: Source specific multicast Statistics: 50 kBps, 94 pps, 407927 packets Next-hop ID: 262143 Upstream protocol: PIM Route state: Active Forwarding state: Forwarding Cache lifetime/timeout: 360 seconds Wrong incoming interface notifications: 0 Uptime: 00:05:16 Instance: master Family: INET6
Question: Is multicast traffic being forwarded by your router for all three groups?
Answer: Yes, your router should be forwarding traffic for all three groups. Step 4.7 Log out of your assigned device using the exit command when complete.
lab@srxA-1> exit
STOP
www.juniper.net
Lab 9
Implementing CoS Features in the Enterprise (Detailed)
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: Configure multifield and behavior aggregate classifiers. Configure a policer for different traffic classes. Create drop profiles. Configure packet marking.
www.juniper.net
Implementing CoS Features in the Enterprise (Detailed) Lab 91 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 labs 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?
srxA-1 (ttyu0) login: lab
Lab 92 Implementing CoS Features in the Enterprise (Detailed) www.juniper.net
Password: --- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC lab@srxA-1> configure Entering configuration mode [edit] lab@srxA-1# load override ajer/lab9-start.config load complete [edit] lab@srxA-1# commit commit complete
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.
srxA-1 (ttyu0) login: lab Password: --- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC lab@srxA-1> ssh lab@CoS-host-address lab@10.1.1.2's password: Last login: Fri Mar 8 07:48:07 2011 from 10.1.1.1 [lab@CoS1 ~]$
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.
[edit] lab@srxA-1# edit class-of-service
www.juniper.net
Implementing CoS Features in the Enterprise (Detailed) Lab 93
[edit class-of-service] lab@srxA-1# set forwarding-classes queue 4 data [edit class-of-service] lab@srxA-1#
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.
[edit class-of-service] lab@srxA-1# top [edit] lab@srxA-1# set firewall filter MF-class term scp from destination-port 22 [edit] lab@srxA-1# set firewall filter MF-class term scp then forwarding-class data [edit] lab@srxA-1# set firewall filter MF-class term scp then loss-priority low
[edit] lab@srxA-1# set firewall filter MF-class term accept then accept [edit] lab@srxA-1# set interfaces ge-0/0/8 unit 0 family inet filter input MF-class [edit] lab@srxA-1# show firewall filter MF-class { term scp { from { destination-port 22; } then { loss-priority low; forwarding-class data; } } term accept { then accept; } } [edit] lab@srxA-1# show class-of-service forwarding-classes { queue 4 data; }
[edit] lab@srxA-1# show interfaces ge-0/0/8 unit 0 { family inet { filter { input MF-class; } address 10.1.1.1/30; } } [edit] lab@srxA-1# commit commit complete [edit] lab@srxA-1#
Question: How many queues are supported on the SRX Series device?
Answer: An SRX Series device supports eight queues on all interfaces. 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.
[edit] lab@srxA-1# edit class-of-service [edit class-of-service] lab@srxA-1# set classifiers dscp BA-class import default [edit class-of-service] lab@srxA-1#
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.
[edit class-of-service] lab@srxA-1# set classifiers dscp BA-class forwarding-class expedited-forwarding loss-priority low code-points ef [edit class-of-service] lab@srxA-1# set classifiers dscp BA-class forwarding-class expedited-forwarding loss-priority low code-points cs5
www.juniper.net
Question: What is the purpose of the DSCP class selector (CS) per-hop behavior group?
Answer: To maintain backward compatibility with network devices that still use the IP Precedence field, DiffServ defines the 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.
[edit class-of-service] lab@srxA-1# set interfaces ge-* unit * classifiers dscp BA-class [edit class-of-service] lab@srxA-1# show classifiers dscp BA-class { import default; forwarding-class expedited-forwarding { loss-priority low code-points [ ef cs5 ]; } } [edit class-of-service] lab@srxA-1# show interfaces ge-* { unit * { classifiers { dscp BA-class; } } } [edit class-of-service] lab@srxA-1# commit commit complete
Step 2.6 Issue the run clear interfaces statistics all command to clear the statistics for all interfaces.
[edit class-of-service] lab@srxA-1# run clear interfaces statistics all
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 teams 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.
[lab@CoS1 ~]$ scp cosZ:lab7files/smallfile.txt smallfile.txt smallfile.txt 100% 1024KB 341.3KB/s 00:03 [lab@CoS1 ~]$
Step 2.8 On the CoS host, ping the other teams 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 teams assigned host number.
[lab@CoS1 ~]$ ping -Q 184 -c 10 cosZ PING cos2 (20.1.1.2) 56(84) bytes of data. 64 bytes from cos2 (20.1.1.2): icmp_seq=1 ttl=62 time=5.22 ms 64 bytes from cos2 (20.1.1.2): icmp_seq=2 ttl=62 time=1.18 ms 64 bytes from cos2 (20.1.1.2): icmp_seq=3 ttl=62 time=1.28 ms 64 bytes from cos2 (20.1.1.2): icmp_seq=4 ttl=62 time=1.28 ms 64 bytes from cos2 (20.1.1.2): icmp_seq=5 ttl=62 time=1.28 ms 64 bytes from cos2 (20.1.1.2): icmp_seq=6 ttl=62 time=1.36 ms 64 bytes from cos2 (20.1.1.2): icmp_seq=7 ttl=62 time=1.19 ms 64 bytes from cos2 (20.1.1.2): icmp_seq=8 ttl=62 time=1.33 ms 64 bytes from cos2 (20.1.1.2): icmp_seq=9 ttl=62 time=1.18 ms 64 bytes from cos2 (20.1.1.2): icmp_seq=10 ttl=62 time=1.25 ms --- cos2 ping statistics --10 packets transmitted, 10 received, 0% packet loss, time 11807ms rtt min/avg/max/mdev = 1.185/1.659/5.228/1.192 ms
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.
[edit class-of-service] lab@srxA-1# run show interfaces ge-0/0/1 extensive | find "Queue counters" Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 931 931 0 1 expedited-fo 20 20 0 2 assured-forw 0 0 0 3 network-cont 0 0 0 4 data 755 755 0 ...
www.juniper.net
Question: Are there any packets in the data and expedited-forwarding queues?
Answer: Your output might vary, but you should have at least 10 packets in the expedited-forwarding queue and approximately 750 packets in the data queue.
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.
[edit class-of-service] lab@srxA-1# top edit firewall [edit firewall] lab@srxA-1# set policer port80 if-exceeding bandwidth-limit 1m [edit firewall] lab@srxA-1# set policer port80 if-exceeding burst-size-limit 640k [edit firewall] lab@srxA-1# set policer port80 then discard [edit firewall] lab@srxA-1#
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.
[edit firewall] lab@srxA-1# set filter MF-class term http-dst from destination-port 80 [edit firewall] lab@srxA-1# set filter MF-class term http-dst then policer port80
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.
[edit firewall] lab@srxA-1# insert filter MF-class term http-dst before term scp
Lab 98 Implementing CoS Features in the Enterprise (Detailed)
www.juniper.net
[edit firewall] lab@srxA-1# show policer port80 if-exceeding { bandwidth-limit 1m; burst-size-limit 640k; } then discard; [edit firewall] lab@srxA-1# show filter MF-class term http-dst { from { destination-port 80; } then policer port80; } term scp { from { destination-port 22; } then { loss-priority low; forwarding-class data; } } term accept { then accept; } [edit firewall] lab@srxA-1# commit commit complete
Step 3.4 Create a policer named voice-overflow. Set the policers 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.
[edit firewall] lab@srxA-1# set policer voice-overflow if-exceeding bandwidth-limit 3m [edit firewall] lab@srxA-1# set policer voice-overflow if-exceeding burst-size-limit 640k [edit firewall] lab@srxA-1# set policer voice-overflow then forwarding-class best-effort [edit firewall] lab@srxA-1# set policer voice-overflow then loss-priority high
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.
www.juniper.net Implementing CoS Features in the Enterprise (Detailed) Lab 99
[edit firewall] lab@srxA-1# set filter MF-class term voip-limit from dscp ef [edit firewall] lab@srxA-1# set filter MF-class term voip-limit 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.
[edit firewall] lab@srxA-1# insert filter MF-class term voip-limit before term scp [edit firewall] lab@srxA-1# show filter MF-class term http-dst { from { destination-port 80; } then policer port80; } term voip-limit { from { dscp ef; } then policer voice-overflow; } term scp { from { destination-port 22; } then { loss-priority low; forwarding-class data; } } term accept { then accept; } [edit firewall] lab@srxA-1# commit commit complete
Question: Why is it important to rate-limit high-priority traffic on an SRX Series device?
Answer: On SRX Series devices, a high-priority queue starves all other priorities unless it is rate-limited. The same result occurs for medium-high and medium, medium-low and low, and so on down the priority chain.
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.
Name be ef af nc data
Criteria 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 transmit-rate percent 5 priority low transmit-rate percent 20 priority medium-high
[edit firewall] lab@srxA-1# top edit class-of-service schedulers [edit class-of-service schedulers] lab@srxA-1# set be transmit-rate percent 20 [edit class-of-service schedulers] lab@srxA-1# set be priority low [edit class-of-service schedulers] lab@srxA-1# set be drop-profile-map loss-priority high protocol any drop-profile aggressive [edit class-of-service schedulers] lab@srxA-1# set ef priority high [edit class-of-service schedulers] lab@srxA-1# set ef buffer-size percent 20 [edit class-of-service schedulers] lab@srxA-1# set af priority medium-high
[edit class-of-service schedulers] lab@srxA-1# set af transmit-rate percent 20 exact [edit class-of-service schedulers] lab@srxA-1# set nc transmit-rate percent 5 [edit class-of-service schedulers] lab@srxA-1# set nc priority low [edit class-of-service schedulers] lab@srxA-1# set data transmit-rate percent 20 [edit class-of-service schedulers] lab@srxA-1# set data priority medium-high [edit class-of-service schedulers] lab@srxA-1#
Question: What is the meaning of the exact option after the transmit-rate?
Answer: It is used to shape traffic to the configured 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
[edit class-of-service schedulers] lab@srxA-1# up 1 edit drop-profiles
Criteria fill-level 30 drop-probability 40 fill-level 80 drop-probability 60
[edit class-of-service drop-profiles] lab@srxA-1# set aggressive fill-level 30 drop-probability 40 [edit class-of-service drop-profiles] lab@srxA-1# set aggressive fill-level 80 drop-probability 60 [edit class-of-service drop-profiles] lab@srxA-1#
www.juniper.net
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:
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.

[edit class-of-service drop-profiles] lab@srxA-1# up 1 edit scheduler-maps [edit class-of-service scheduler-maps] lab@srxA-1# set my-sched-map forwarding-class best-effort scheduler be [edit class-of-service scheduler-maps] lab@srxA-1# set my-sched-map forwarding-class expedited-forwarding scheduler ef [edit class-of-service scheduler-maps] lab@srxA-1# set my-sched-map forwarding-class assured-forwarding scheduler af [edit class-of-service scheduler-maps] lab@srxA-1# set my-sched-map forwarding-class network-control scheduler nc [edit class-of-service scheduler-maps] lab@srxA-1# set my-sched-map forwarding-class data scheduler data [edit class-of-service scheduler-maps] lab@srxA-1# show my-sched-map { 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; } [edit class-of-service scheduler-maps] lab@srxA-1# top show class-of-service schedulers
be { transmit-rate percent 20; priority low; drop-profile-map loss-priority high protocol any drop-profile aggressive; } ef { buffer-size percent 20; priority high; } af { transmit-rate percent 20 exact; priority medium-high; } nc { transmit-rate percent 5; priority low; } data { transmit-rate percent 20; priority medium-high; } [edit class-of-service scheduler-maps] lab@srxA-1# top show class-of-service drop-profiles aggressive { fill-level 30 drop-probability 40; fill-level 80 drop-probability 60; } [edit class-of-service scheduler-maps] lab@srxA-1# commit commit complete [edit class-of-service scheduler-maps] lab@srxA-1#
Step 4.4 Issue the run clear interfaces statistics all command to clear the statistics for all interfaces.
[edit class-of-service scheduler-maps] lab@srxA-1# run clear interfaces statistics all
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.
[lab@CoS2 ~]$ gendata.sh Please login with USER and PASS. Please login with USER and PASS. Interactive mode off. [lab@CoS2 ~]$
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.
[edit class-of-service scheduler-maps] lab@srxA-1# run show interfaces ge-0/0/1 extensive | find "Queue counters" Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 76652 73184 3468 1 expedited-fo 2941 174 2767 2 assured-forw 10004 10004 0 3 network-cont 11 11 0 4 data 0 0 0 ...
Question: How many drops are in the expedited-forwarding queue?
Answer: You should see more than 2000 drops 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.
[edit class-of-service scheduler-maps] lab@srxA-1# up [edit class-of-service] lab@srxA-1# set interfaces ge-0/0/1 scheduler-map my-sched-map [edit class-of-service] lab@srxA-1# commit commit complete [edit class-of-service] lab@srxA-1#
Step 4.8 Issue the command run clear interfaces statistics all to clear the interface statistics for all interfaces.
[edit class-of-service] lab@srxA-1# run clear interfaces statistics all
www.juniper.net
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.
[lab@CoS2 ~]$ gendata.sh Please login with USER and PASS. Please login with USER and PASS. Interactive mode off. [lab@CoS2 ~]$
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.
[edit class-of-service] lab@srxA-1# run show interfaces ge-0/0/1 extensive | find "Queue counters" Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 77851 71538 6313 1 expedited-fo 2941 2929 12 2 assured-forw 9339 9339 0 3 network-cont 8 8 0 4 data 0 0 0 ...
Question: How many drops do you see in the expedited-forwarding queue now?
Answer: The count might vary, but you should now see less than 50 dropped packets. 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.
[edit class-of-service] lab@srxA-1# run show interfaces queue ge-0/0/1 forwarding-class best-effort Physical interface: ge-0/0/1, Enabled, Physical link is Up Interface index: 135, SNMP ifIndex: 508 Forwarding classes: 8 supported, 5 in use Egress queues: 8 supported, 5 in use Queue: 0, Forwarding classes: best-effort Queued: Packets : 77957 0 pps Bytes : 76001724 0 bps Transmitted: Packets : 71644 0 pps Bytes : 66461740 0 bps Tail-dropped packets : 4634 0 pps
RED-dropped packets Low Medium-low Medium-high High RED-dropped bytes Low Medium-low Medium-high High
: : : : : : : : : :
1679 0 0 0 1679 2538648 0 0 0 2538648
0 0 0 0 0 0 0 0 0 0
pps pps pps pps pps bps bps bps bps bps
Question: How many high-priority random early detection (RED)-dropped packets does the router display?
Answer: The count will vary, but you should see more than 1000 loss-priority high drops. Recall from an earlier task that any expedited forwarding (EF)-marked packets that were over 3 Mbps were sent to the best-effort queue and marked as high loss. The drop-profile aggressive is used for packets marked as high loss in the best-effort queue.
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.
[edit class-of-service] lab@srxA-1# edit rewrite-rules [edit class-of-service rewrite-rules] lab@srxA-1# set dscp dscp-rewrite import default [edit class-of-service rewrite-rules] lab@srxA-1#
Step 5.2 In the dscp-rewrite rewrite rule, configure forwarding-class best-effort with loss-priority low to have a marking of af31.
[edit class-of-service rewrite-rules] lab@srxA-1# set dscp dscp-rewrite forwarding-class best-effort loss-priority low code-point af31
www.juniper.net
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.
[edit class-of-service rewrite-rules] lab@srxA-1# up [edit class-of-service] lab@srxA-1# set interfaces ge-0/0/8 unit 0 rewrite-rules dscp dscp-rewrite [edit class-of-service] lab@srxA-1# show interfaces ge-0/0/8 unit 0 { rewrite-rules { dscp dscp-rewrite; } } [edit class-of-service] lab@srxA-1# show rewrite-rules dscp dscp-rewrite { import default; forwarding-class best-effort { loss-priority low code-point af31; } } [edit class-of-service] lab@srxA-1# commit commit complete [edit class-of-service] lab@srxA-1#
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.
[lab@cos2 ~]$ sudo /usr/sbin/tshark -w icmp.cap -ni eth1 -c 10 dst host srx [sudo] password for lab: Running as user "root" and group "root". This could be dangerous. Capturing on eth1
Step 5.5 Return to the CLI session on your SRX Series student device. On the SRX Series device, ping the other teams 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
[edit class-of-service] lab@srxA-1# run ping peer-CoS-host tos 96 PING 20.1.1.2 (20.1.1.2): 56 data bytes 64 bytes from 20.1.1.2: icmp_seq=0 ttl=63 64 bytes from 20.1.1.2: icmp_seq=1 ttl=63 64 bytes from 20.1.1.2: icmp_seq=2 ttl=63 ...
count 10 time=2.258 ms time=1.803 ms time=1.752 ms
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.
[lab@CoS1 ~]$ sudo /usr/sbin/tshark -r icmp.cap -V | egrep DSCP Running as user "root" and group "root". This could be dangerous. Differentiated Services Field: 0x68 (DSCP 0x1a: Assured Forwarding 0x00) Differentiated Services Field: 0x68 (DSCP 0x1a: Assured Forwarding 0x00) Differentiated Services Field: 0x68 (DSCP 0x1a: Assured Forwarding 0x00) Differentiated Services Field: 0x68 (DSCP 0x1a: Assured Forwarding 0x00) Differentiated Services Field: 0x68 (DSCP 0x1a: Assured Forwarding 0x00) Differentiated Services Field: 0x68 (DSCP 0x1a: Assured Forwarding 0x00) Differentiated Services Field: 0x68 (DSCP 0x1a: Assured Forwarding 0x00) Differentiated Services Field: 0x68 (DSCP 0x1a: Assured Forwarding 0x00) Differentiated Services Field: 0x68 (DSCP 0x1a: Assured Forwarding 0x00) Differentiated Services Field: 0x68 (DSCP 0x1a: Assured Forwarding 0x00)
31; ECN: 31; ECN: 31; ECN: 31; ECN: 31; ECN: 31; ECN: 31; ECN: 31; ECN: 31; ECN: 31; ECN:
www.juniper.net
Question: Is the rewrite configuration working properly?
Answer: Yes, the capture should show AF31 packets that were originally sent as CS3 from the router. Step 5.7 Using the exit command, log out of the CoS host and then log out of your second SRX Series CLI session.
[lab@CoS1 ~]$ exit logout Connection to 10.1.1.2 closed. lab@srxA-1> exit Connection closed by foreign host.
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.
[edit class-of-service] lab@srxA-1# top [edit] lab@srxA-1# load override ajer/reset.config load complete [edit] lab@srxA-1# commit and-quit commit complete Exiting configuration mode lab@srxA-1> exit
STOP
www.juniper.net
Lab 10
BGP Route Reflection (Detailed)
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 ReflectionParts 12, Lab 10: BGP Route ReflectionPart 3, and Lab 10: BGP Route ReflectionPart 4 to configure and monitor BGP route reflection. By completing this lab, you will perform the following tasks: 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.
www.juniper.net
BGP Route Reflection (Detailed) Lab 101 11.a.11.4R1.6

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 12. 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?
srxA-1 (ttyu0) login: lab Password:
Lab 102 BGP Route Reflection (Detailed) www.juniper.net
--- JUNOS 11.4R1.6 built 2011-11-15 12:44:14 UTC lab@srxA-1> configure Entering configuration mode [edit] lab@srxA-1# load override ajer/lab10-start.config load complete [edit] lab@srxA-1# commit commit complete
Part 2: Verifying Topology

In this lab part, you verify router-to-router connectivity and BGP operations using the command-line interface (CLI).
Note
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 partners student device. The remaining two adjacencies are to each of your virtual routers (C1 and C2).
[edit] lab@srxA-1# run show ospf neighbor instance master Address Interface State ID 172.20.1.2 ge-0/0/1.0 Full 192.168.2.1 172.20.3.2 ge-0/0/14.1 Full 192.168.1.2 172.20.4.2 ge-0/0/14.2 Full 192.168.1.3 172.20.2.2 ge-0/0/2.0 Full 192.168.2.1
Pri 128 128 128 128
Dead 36 35 35 39
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.
www.juniper.net BGP Route Reflection (Detailed) Lab 103
lab@srxA-1# run show bgp summary instance master Groups: 1 Peers: 5 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 4 4 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.168.1.2 64700 99 98 0 0 44:07 Establ inet.0: 1/1/1/0 192.168.1.3 64700 100 97 0 0 44:03 Establ inet.0: 1/1/1/0 192.168.2.1 64700 39 39 0 1 17:27 Establ inet.0: 0/0/0/0 192.168.2.2 64700 39 38 0 0 16:45 Establ inet.0: 1/1/1/0 192.168.2.3 64700 39 67 0 0 17:35 Establ inet.0: 1/1/1/0 [edit] lab@srxA-1# run show bgp summary instance C1 Groups: 1 Peers: 5 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending C1.inet.0 3 3 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.168.1.1 64700 132 133 0 2 59:44 Establ C1.inet.0: 0/0/0/0 192.168.1.3 64700 133 131 0 0 59:40 Establ C1.inet.0: 1/1/1/0 192.168.2.1 64700 74 74 0 0 33:20 Establ C1.inet.0: 0/0/0/0 192.168.2.2 64700 74 73 0 0 32:46 Establ C1.inet.0: 1/1/1/0 192.168.2.3 64700 76 74 0 0 33:22 Establ C1.inet.0: 1/1/1/0 [edit] lab@srxA-1# run show bgp summary instance C2 Groups: 1 Peers: 5 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending C2.inet.0 3 3 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.168.1.1 64700 130 134 0 2 59:42 Establ C2.inet.0: 0/0/0/0 192.168.1.2 64700 130 133 0 0 59:42 Establ C2.inet.0: 1/1/1/0 192.168.2.1 64700 73 74 0 0 33:18 Establ C2.inet.0: 0/0/0/0 192.168.2.2 64700 73 72 0 0 32:36 Establ C2.inet.0: 1/1/1/0 192.168.2.3 64700 74 74 0 0 33:20 Establ C2.inet.0: 1/1/1/0
Lab 104 BGP Route Reflection (Detailed)
www.juniper.net
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.
[edit] lab@srxA-1# run show route 200.200/16 table inet.0 inet.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 200.200.1.0/24 *[BGP/170] 01:07:47, AS path: I > to 172.20.3.2 via *[BGP/170] 00:40:25, AS path: I > to 172.20.2.2 via *[BGP/170] 00:47:54, AS path: I > to 172.20.4.2 via *[BGP/170] 00:41:15, AS path: I > to 172.20.2.2 via localpref 100, from 192.168.1.2 ge-0/0/14.1 localpref 100, from 192.168.2.2 ge-0/0/2.0 localpref 100, from 192.168.1.3 ge-0/0/14.2 localpref 100, from 192.168.2.3 ge-0/0/2.0
200.200.2.0/24
200.200.3.0/24
200.200.4.0/24
[edit] lab@srxA-1# run show route 200.200/16 table C1.inet.0 C1.inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 200.200.1.0/24 200.200.2.0/24 *[Static/5] 04:44:08 Reject *[BGP/170] 00:40:54, AS path: I > to 172.20.3.1 via *[BGP/170] 00:47:59, AS path: I > to 172.20.3.1 via *[BGP/170] 00:41:30, AS path: I > to 172.20.3.1 via
localpref 100, from 192.168.2.2 ge-0/0/15.1 localpref 100, from 192.168.1.3 ge-0/0/15.1 localpref 100, from 192.168.2.3 ge-0/0/15.1
200.200.3.0/24
200.200.4.0/24
[edit] lab@srxA-1# run show route 200.200/16 table C2.inet.0 C2.inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 200.200.1.0/24 *[BGP/170] 01:07:52, AS path: I > to 172.20.4.1 via *[BGP/170] 00:40:46, AS path: I > to 172.20.4.1 via localpref 100, from 192.168.1.2 ge-0/0/15.2 localpref 100, from 192.168.2.2 ge-0/0/15.2
BGP Route Reflection (Detailed) Lab 105
200.200.2.0/24
www.juniper.net
200.200.3.0/24 200.200.4.0/24
*[Static/5] 00:48:04 Reject *[BGP/170] 00:41:30, localpref 100, from 192.168.2.3 AS path: I > to 172.20.4.1 via ge-0/0/15.2
Question: How many routes are in each table?
Answer: Each table should have four routes present.
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 ReflectionPart 3 for this section. 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.
[edit] lab@srxA-1# edit protocols bgp [edit protocols bgp] lab@srxA-1# show group my-int-group { type internal; local-address 192.168.1.1; neighbor 192.168.1.2; neighbor 192.168.1.3; neighbor 192.168.2.1; neighbor 192.168.2.2; neighbor 192.168.2.3; } [edit protocols bgp] lab@srxA-1#
www.juniper.net
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 neighborthe other route reflectors loopback address. Do not forget the type and local-address statements.
[edit protocols bgp] lab@srxA-1# delete group my-int-group [edit protocols bgp] lab@srxA-1# edit group my-mesh-group [edit protocols bgp group my-mesh-group] lab@srxA-1# set type internal [edit protocols bgp group my-mesh-group] lab@srxA-1# set local-address loopback-address [edit protocols bgp group my-mesh-group] lab@srxA-1# set neighbor remote-partner-loopback-address [edit protocols bgp group my-mesh-group] lab@srxA-1# show type internal; local-address 192.168.1.1; neighbor 192.168.2.1; [edit protocols bgp group my-mesh-group] lab@srxA-1#
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.
[edit protocols bgp group my-mesh-group] lab@srxA-1# up 1 edit group rr-cluster [edit protocols bgp group rr-cluster] lab@srxA-1# set type internal [edit protocols bgp group rr-cluster] lab@srxA-1# set local-address loopback-address [edit protocols bgp group rr-cluster] lab@srxA-1# set neighbor local-C1-loopback-address [edit protocols bgp group rr-cluster] lab@srxA-1# set neighbor local-C2-loopback-address [edit protocols bgp group rr-cluster] lab@srxA-1#
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.
[edit protocols bgp group rr-cluster] lab@srxA-1# top edit routing-instances C1 protocols bgp [edit routing-instances C1 protocols bgp] lab@srxA-1# show group my-int-group { type internal; local-address 192.168.1.2; export static-to-bgp; neighbor 192.168.1.1; neighbor 192.168.1.3; neighbor 192.168.2.1; neighbor 192.168.2.2; neighbor 192.168.2.3; } [edit routing-instances C1 protocols bgp] lab@srxA-1#
Step 3.5 Within the my-int-group group, delete all neighbors except for the locally attached route-reflector loopback address.
[edit routing-instances C1 protocols bgp] lab@srxA-1# delete group my-int-group neighbor local-C2-loopback-address [edit routing-instances C1 protocols bgp] lab@srxA-1# delete group my-int-group neighbor remote-partner-loopback-address [edit routing-instances C1 protocols bgp] lab@srxA-1# delete group my-int-group neighbor remote-C1-loopback-address [edit routing-instances C1 protocols bgp] lab@srxA-1# delete group my-int-group neighbor remote-C2-loopback-address [edit routing-instances C1 protocols bgp] lab@srxA-1# show group my-int-group { type internal; local-address 192.168.1.2; export static-to-bgp; neighbor 192.168.1.1; }
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.
www.juniper.net
[edit routing-instances C1 protocols bgp] lab@srxA-1# up 3 edit C2 protocols bgp [edit routing-instances C2 protocols bgp] lab@srxA-1# show group my-int-group { type internal; local-address 192.168.1.3; export static-to-bgp; neighbor 192.168.1.1; neighbor 192.168.1.2; neighbor 192.168.2.1; neighbor 192.168.2.2; neighbor 192.168.2.3; } [edit routing-instances C2 protocols bgp] lab@srxA-1#
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.
[edit routing-instances C2 protocols bgp] lab@srxA-1# delete group my-int-group neighbor local-C1-loopback-address [edit routing-instances C1 protocols bgp] lab@srxA-1# delete group my-int-group neighbor remote-partner-loopback-address [edit routing-instances C2 protocols bgp] lab@srxA-1# delete group my-int-group neighbor remote-C1-loopback-address [edit routing-instances C2 protocols bgp] lab@srxA-1# delete group my-int-group neighbor remote-C2-loopback-address [edit routing-instances C2 protocols bgp] lab@srxA-1# show group my-int-group { type internal; local-address 192.168.1.3; export static-to-bgp; neighbor 192.168.1.1; } [edit routing-instances C2 protocols bgp] lab@srxA-1# commit commit complete
Note
Before proceeding, ensure that the remote student team in your pod finishes the previous step.
www.juniper.net
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.
[edit routing-instances C2 protocols bgp] lab@srxA-1# run show route 200.200/16 table inet.0 inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 200.200.1.0/24 *[BGP/170] 00:10:21, AS path: I > to 172.20.3.2 via *[BGP/170] 00:10:17, AS path: I > to 172.20.4.2 via localpref 100, from 192.168.1.2 ge-0/0/14.1 localpref 100, from 192.168.1.3 ge-0/0/14.2
200.200.3.0/24
[edit routing-instances C2 protocols bgp] lab@srxA-1# run show route 200.200/16 table C1.inet.0 C1.inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 200.200.1.0/24 *[Static/5] 06:24:59 Reject
[edit routing-instances C2 protocols bgp] lab@srxA-1# run show route 200.200/16 table C2.inet.0 C2.inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 200.200.3.0/24 *[Static/5] 02:28:56 Reject
Question: Are the 200.200/16 routes being propagated throughout the network? Why or why not?
Answer: No. The 200.200/16 routes are not being propagated throughout the network because of the IBGP rule that precludes an IBGP speaker from readvertising routes learned from another IBGP speaker. 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.
www.juniper.net
[edit routing-instances C2 protocols bgp] lab@srxA-1# top edit protocols bgp group rr-cluster [edit protocols bgp group rr-cluster] lab@srxA-1# set cluster cluster-id [edit protocols bgp group rr-cluster] lab@srxA-1# show type internal; local-address 192.168.1.1; cluster 1.1.1.1; neighbor 192.168.1.2; neighbor 192.168.1.3; [edit protocols bgp group rr-cluster] lab@srxA-1# commit commit complete [edit protocols bgp group rr-cluster] lab@srxA-1#
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.
[edit protocols bgp group rr-cluster] lab@srxA-1# run show route 200.200/16 table inet.0 inet.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 200.200.1.0/24 *[BGP/170] 00:08:51, AS path: I > to 172.20.3.2 via *[BGP/170] 00:08:37, AS path: I > to 172.20.2.2 via *[BGP/170] 00:08:47, AS path: I > to 172.20.4.2 via *[BGP/170] 00:08:33, AS path: I localpref 100, from 192.168.1.2 ge-0/0/14.1 localpref 100, from 192.168.2.1 ge-0/0/2.0 localpref 100, from 192.168.1.3 ge-0/0/14.2 localpref 100, from 192.168.2.1
200.200.2.0/24
200.200.3.0/24
200.200.4.0/24
www.juniper.net
> to 172.20.2.2 via ge-0/0/2.0 [edit protocols bgp group rr-cluster] lab@srxA-1# run show route 200.200/16 table C1.inet.0 C1.inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 200.200.1.0/24 200.200.2.0/24 *[Static/5] 07:10:43 Reject *[BGP/170] 00:08:42, AS path: I > to 172.20.3.1 via *[BGP/170] 00:08:52, AS path: I > to 172.20.3.1 via *[BGP/170] 00:08:38, AS path: I > to 172.20.3.1 via
localpref 100, from 192.168.1.1 ge-0/0/15.1 localpref 100, from 192.168.1.1 ge-0/0/15.1 localpref 100, from 192.168.1.1 ge-0/0/15.1
200.200.3.0/24
200.200.4.0/24
[edit protocols bgp group rr-cluster] lab@srxA-1# run show route 200.200/16 table C2.inet.0 C2.inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 200.200.1.0/24 *[BGP/170] 00:08:58, AS path: I > to 172.20.4.1 via *[BGP/170] 00:08:48, AS path: I > to 172.20.4.1 via *[Static/5] 03:14:41 Reject *[BGP/170] 00:08:44, AS path: I > to 172.20.4.1 via localpref 100, from 192.168.1.1 ge-0/0/15.2 localpref 100, from 192.168.1.1 ge-0/0/15.2
200.200.2.0/24
200.200.3.0/24 200.200.4.0/24
localpref 100, from 192.168.1.1 ge-0/0/15.2
Question: Are the 200.200/16 routes being propagated throughout the network?
Answer: Yes, the 200.200/16 routes are again 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.
[edit protocols bgp group rr-cluster] lab@srxA-1# run show route prefix/24 table C1.inet.0 detail C1.inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) 200.200.3.0/24 (1 entry, 1 announced)
*BGP
Preference: 170/-101 Next hop type: Indirect Address: 0x1660d20 Next-hop reference count: 3 Source: 192.168.1.1 Next hop type: Router, Next hop index: 643 Next hop: 172.20.3.1 via ge-0/0/15.1, selected Protocol next hop: 192.168.1.3 Indirect next hop: 1704e80 262145 State: <Active Int Ext> Local AS: 64700 Peer AS: 64700 Age: 8:06:20 Metric2: 2 Task: BGP_64700.192.168.1.1+61154 Announcement bits (2): 0-KRT 3-Resolve tree 1 AS path: I (Originator) Cluster list: 1.1.1.1 AS path: Originator ID: 192.168.1.3 Accepted Localpref: 100 Router ID: 192.168.1.1
Question: What do you notice about the AS path information?
Answer: Because we are using route reflection, the AS path now contains the two route reflection BGP attributes: Cluster list and Originator ID. 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.
[edit protocols bgp group rr-cluster] lab@srxA-1# run show route prefix/24 table C1.inet.0 detail C1.inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) 200.200.2.0/24 (1 entry, 1 announced) *BGP Preference: 170/-101 Next hop type: Indirect Address: 0x1661a30 Next-hop reference count: 3 Source: 192.168.1.1 Next hop type: Router, Next hop index: 643 Next hop: 172.20.3.1 via ge-0/0/15.1, selected Protocol next hop: 192.168.2.2 Indirect next hop: 1705220 262148 State: <Active Int Ext> Local AS: 64700 Peer AS: 64700 Age: 8:11:52 Metric2: 3 Task: BGP_64700.192.168.1.1+61154 Announcement bits (2): 0-KRT 3-Resolve tree 1 AS path: I (Originator) Cluster list: 1.1.1.1 2.2.2.2 AS path: Originator ID: 192.168.2.2 Accepted
Localpref: 100 Router ID: 192.168.1.1
Question: What is the cluster list value for this route?
Answer: The answer varies depending on your assigned device. In the previous output, the cluster list value is: 1.1.1.1 2.2.2.2 Question: What does this cluster list value tell you about the route?
Answer: The cluster list value acts much like the AS path attribute in that it tells you which clusters the route has transited. In the previous output, the route first transited cluster 2.2.2.2, followed by cluster 1.1.1.1. Your output might vary depending on your assigned student device.
Part 4: Adding a New Router to the Network

Use the lab diagram titled Lab 10: BGP Route ReflectionPart 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.
[edit protocols bgp group rr-cluster] lab@srxA-1# top edit protocols ospf area 0 [edit protocols ospf area 0.0.0.0] lab@srxA-1# set interface ge-0/0/14.3 interface-type p2p [edit protocols ospf area 0.0.0.0] lab@srxA-1# commit commit complete
[edit protocols ospf area 0.0.0.0] lab@srxA-1#
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.
[edit protocols ospf area 0.0.0.0] lab@srxA-1# run show ospf neighbor interface ge-0/0/14.3 Address Interface State ID 172.20.5.2 ge-0/0/14.3 Full 192.168.1.4
Pri 128
Dead 38
Question: Did the interface transition to a Full state?
Answer: Yes. As shown in the previous output, ge-0/0/14.3 is in a Full state. If it did not transition to a Full state, check your configuration and, if necessary, contact your instructor for help. Step 4.3 Verify IGP connectivity by issuing the run ping local-C3-loopback-address rapid command.
[edit protocols ospf area 0.0.0.0] lab@srxA-1# run ping local-C3-loopback-address rapid PING 192.168.1.4 (192.168.1.4): 56 data bytes !!!!! --- 192.168.1.4 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.259/3.589/7.916/2.581 ms
Question: Was the ping successful?
Answer: Yes. As shown in the previous output, the ping was successful. If it was not successful, check your configuration and, if necessary, contact your instructor for help. Step 4.4 Navigate to the [edit protocols bgp group rr-cluster] hierarchy. Add your local C3 routers loopback address as a neighbor in the rr-cluster group.
[edit protocols ospf area 0.0.0.0] lab@srxA-1# top edit protocols bgp group rr-cluster [edit protocols bgp group rr-cluster] lab@srxA-1# set neighbor local-C3-loopback-address
www.juniper.net
[edit protocols bgp group rr-cluster] lab@srxA-1#
Step 4.5 Navigate to the [edit routing-instances C3 routing-options] hierarchy. Configure the AS number as shown on your lab diagram.
[edit protocols bgp group rr-cluster] lab@srxA-1# top edit routing-instances C3 routing-options [edit routing-instances C3 routing-options] lab@srxA-1# set autonomous-system 64700 [edit routing-instances C3 routing-options] lab@srxA-1#
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 reflectors 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.
[edit routing-instances C3 routing-options] lab@srxA-1# up 1 edit protocols bgp [edit routing-instances C3 protocols bgp] lab@srxA-1# set group my-int-group type internal [edit routing-instances C3 protocols bgp] lab@srxA-1# set group my-int-group local-address local-C3-loopback-address [edit routing-instances C3 protocols bgp] lab@srxA-1# set group my-int-group neighbor local-RR-loopback-address [edit routing-instances C3 protocols bgp] lab@srxA-1# set group my-int-group export static-to-bgp [edit routing-instances C3 protocols bgp] lab@srxA-1# show group my-int-group { type internal; local-address 192.168.1.4; export static-to-bgp; neighbor 192.168.1.1; } [edit routing-instances C3 protocols bgp] lab@srxA-1# commit commit complete [edit routing-instances C3 protocols bgp] lab@srxA-1#
www.juniper.net
Step 4.7 Issue the run show bgp summary instance C3 command to verify your new IBGP peering session is established.
[edit routing-instances C3 protocols bgp] lab@srxA-1# run show bgp summary instance C3 Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending C3.mdt.0 0 0 0 0 0 0 C3.inet.0 5 5 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.168.1.1 64700 34 31 0 0 12:47 Establ C3.inet.0: 5/5/5/0
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.
[edit routing-instances C3 protocols bgp] lab@srxA-1# run show route 200.200/16 table C3.inet.0 C3.inet.0: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 200.200.1.0/24 *[BGP/170] 00:16:52, AS path: I > to 172.20.5.1 via *[BGP/170] 00:16:52, AS path: I > to 172.20.5.1 via *[BGP/170] 00:16:52, AS path: I > to 172.20.5.1 via *[BGP/170] 00:16:52, AS path: I > to 172.20.5.1 via *[Static/5] 14:34:35 Reject *[BGP/170] 00:14:52, AS path: I > to 172.20.5.1 via localpref 100, from 192.168.1.1 ge-0/0/15.3 localpref 100, from 192.168.1.1 ge-0/0/15.3 localpref 100, from 192.168.1.1 ge-0/0/15.3 localpref 100, from 192.168.1.1 ge-0/0/15.3
200.200.2.0/24
200.200.3.0/24
200.200.4.0/24
200.200.5.0/24 200.200.6.0/24
localpref 100, from 192.168.1.1 ge-0/0/15.3
www.juniper.net
Question: How many routes are in the C3 routers table?
Answer: As shown in the previous output, six routes should be present in the C3 routers table. This demonstrates that all of the virtual routers routes are being propagated throughout the network. 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.
[edit routing-instances C3 protocols bgp] lab@srxA-1# top [edit] lab@srxA-1# load override ajer/reset.config load complete [edit] lab@srxA-1# commit and-quit commit complete Exiting configuration mode lab@srxA-1> exit
STOP
www.juniper.net

Appendix A: Lab Diagrams
A2 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A3
A4 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A5
A6 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A7
A8 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A9
A10 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A11
A12 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A13
A14 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A15
A16 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A17
A18 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A19
A20 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A21
A22 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A23
A24 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A25
A26 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A27
A28 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A29
A30 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A31
A32 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A33
A34 Lab Diagrams
www.juniper.net
www.juniper.net
Lab Diagrams A35
A36 Lab Diagrams
www.juniper.net

Advanced Junos Enterprise Routing: Detailed Lab Guide

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Advanced Junos Enterprise Routing: Detailed Lab Guide

Transféré par

Droits d'auteur :

Formats disponibles

Advanced Junos Enterprise Routing

Detailed Lab Guide

Worldwide Education Services

Implementing BGP (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

BGP Attributes (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Implementing Enterprise Routing Policies (Detailed) . . . . . . . . . . . . . . . . . . 6-1

Implementing PIM-SM (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Implementing SSM (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Implementing CoS Features in the Enterprise (Detailed) . . . . . . . . . . . . . . . 9-1

Lab 10: BGP Route Reflection (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

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

Course Agenda vii

GUI text elements: Menu names Text field entry

Input Text Versus Output Text

Defined and Undefined Syntax Variables

viii Document Conventions

About This Publication

Juniper Networks Support

Configuring and Monitoring OSPF (Detailed) Lab 11 11.a.11.4R1.6